Построение SAN для Xen на основе DRBD, LVM и GNBD
Материал из Xgu.ru
Оригинал: [1]
Перевод: Игорь Чубин
Правильная ссылка: [2]
Задача.
Хочется:
- надёжное дисковое решения для резервных копий
- большое хранилище, изменяющегося размера для виртуальных машин;
- доступ к жёсткому диску одной машин с другой машины;
- быстрая замена аппаратного обеспечения в случае сбоя.
Не хочется:
- тратить много времени на настройку системы в случае полного сбоя, и необходимости настройки системы с нуля;
- тратить много денег на специализированное программное обеспечение и железо.
Решение.
Есть два компьютера. Можно поставить в эти компьютеры диски и отзеркалировать их по сети. Вместо того чтобы выделять отдельный файл-сервер с RAID1, мы как бы добавляем всю систему в RAID-массив. Если что-то сломается на одном из компьютеров, службы этого компьютера смогут продолжить работать, а данные останутся неповреждёнными, за исключением тех, что были в оперативной памяти.
Для выполнения зеркалирования устройств используется DRBD. DRBD это специальное блочное устройство, которое разрабатывалось для HA-кластеров. В DRBD работа с блочным устройством зеркалируется по сети на другой диск. Можно сказать, RAID1 через сеть. Позволяет строить что-то наподобие shared storage devices на SAN, но без специального оборудования.
Linux Logical Volume Management (LVM) -- это популярный инструмент, который позволяет гибко управлять дисковым пространством. Вместо того чтобы просто нарезать диск на разделы фиксированного размера, с помощью LVM можно добиться управления логическими разделами, поддерживающими изменение размера, создание снимков (snapshots), включая постоянные снимки (persistent snapshots) и изменения к ним (diffs), добавления нескольких дисков в группу томов по мере необходимости (логический раздел может находиться на нескольких физических). Каждый логический раздел в LVM форматируется под свою собственную файловую систему.
Но как удалённо получить доступ к этим устройствам? Конечно, можно использовать сетевые файловые системы, наподобие NFS. Но это решение нам не очень подходит. Лучше попробовать экспортировать по сети блочное устройство непосредственно. Для этого используется GNBD (Global Network Block Device).
Один узел экспортирует том LVM через GNBD, а второй импортирует его и делает его доступным для использования. В частности, для монтирования в файловую иерархию. Похоже на iSCSI, только быстрее в настройке и использовании. (похожих результатов можно добиться с помощью ATA over Ethernet).
И если другой узел это домен 0 Xen, устройство можно использовать в качестве образа виртуальной машины. Так как если бы это был обычный раздел на узле.
Пример строки конфигурации Xen, где используется импортированное блочное устройство:
disk = [ ‘phy:/dev/gnbd/vmimage001,sda1,w’]
Гостевая система может вообще ничего не знать обо всех этих инструментах. Она просто видит sda1 и монтирует его как и любой другой аппаратный раздел.
Вместо того чтобы просто использовать файловое хранилище для резервных копий, можно использовать его при работе служб таких как web, сервер инкрементального резервного копирования, media-сервер и так далее.
Во-первых, это позволяет организовывать резерв сетевых служб без всякого специализированного программного обеспечения. (также мы избегаем Парадокса Рассела в этой ситуации).
Во-вторых, тот факт, что службы, требующие много времени на настройку, находятся в виртуальных машинах, даёт возможность быстро менять оборудование, возможно даже компьютеры целиком. Всё что нужно установить и настроить это Linux, DRBD, LVM и GNBD на файл-сервере, и Linux и Xen на сервере виртуализации.
До тех пор пока задержка передачи не высокая (меньше 1мс), не имеет принципиального значения, является ли диск локальным или удалённым. Виртуальная машина в любом случае реагирует быстро.
(Замечание: можно убрать GNBD и запустить машины на хостах A и B, если Xen был там проинсталлирован)
Ещё один плюс: используя GNBD, можно выполнять живую миграцию машин на любой узел, который может импортировать GNBD. DRBD и GNBD обладают характеристиками, позволяющими строить отказоустойчивые бесшовные системы (seamless failover).
Подробнее об этом можно почитать здесь:
В данном случае у нас есть две одноранговые машины, которые следят друг за другом.
Обязательно нужно выделять master и slave системы с точки зрения DRBD. Пусть на одной системе: A будет DRBD-master и B - DRBD-slave, а на другой наоборот -- A -- DRBD-slave, а B -- DRBD-master. Виртуальные машины будут запускаться с раздела DRBD-master.
Предположим, вы разделяете четыре службы по четырём виртуальным машинам и размещаете виртуальные машины по две на каждом физическом узле.
Что произойдёт в случае выхода одного из узлов из строя?
- Один из физических узлов выходит из строя.
- Это замечает процесс мониторинга.
- Скрипт heartbeat делает так чтобы узел, с которым всё в порядке, стал DRBD-мастером для обоих разделов: A и B.
- После этого он загружает виртуальные машины, которые раньше работали на сломавшемся узле, на новом узле.
- Количество оперативной памяти, выделенной виртуальным машинам, при этом меняется так чтобы одновременно могли работать все четыре машины.
- Приложения в виртуальных машинах восстанавливаются
как после обычной внезапной перезагрузки (их сетевые адреса могут оставаться неизменными, поскольку новый хост-узел физически находится в той же сети).
Как только администратор получит оповещение о выходе из строя системы, и восстановит её, специальный скрипт выполняет синхронизацию DRBD. Затем виртуальные машины мигрируют на своё место.
[править] Дополнительная информация
- (Xen-devel) xen+drbd (partial?) success story -- сообщение об успешном использовании Xen и DRBD
