From: Игорь Чубин <http://xgu.ru/>
Date: Mon, 31 Jul 2007 14:31:37 +0000 (UTC)
Subject: Использование доменов Xen поверх DRBD-устройств
Оригинал: http://xgu.ru/wiki/xen/drbd
Содержание
1 Идея
2 Реализация
2.1 Скрипт xen-drbd
2.2 Конфигурационные файлы
2.3 Подготовка узлов
3 Сеть
4 Взаимный контроль узлов с помощью heartbeat
5 Вопросы эксплуатации xen-drbd
5.1 Создание новых устройств DRBD
5.1.1 Множество DRBD-устройств
5.1.2 Метадиск
5.2 Расширение диска DRBD
5.3 Разрыв линка во время миграции
5.4 Проверка DRBD перед стартом виртуальной машины
6 Дополнительные вопросы
6.1 Организация дисковой подсистемы: DRBD поверх томов LVM
6.2 LVM поверх DRBD или DRBD поверх LVM?
6.3 Миграция доменов Xen, работающих поверх DRBD
6.4 Отказоустойчивость сети в связке xen-drbd
Идея
Компоненты:
* Xen -- это монитор виртуальных машин (VMM, Virtual Machine
Monitor) или гипервизор (hypervisor) с поддержкой
паравиртуализации (para-virtualization) для процессоров x86
архитектуры, распространяющийся с открытым исходным кодом
(opensource). Xen может организовать совместное безопасное
исполнение нескольких виртуальных машин на одной физической
системе с производительностью близкой к непосредственной (native).
* LVM (Logical Volume Manager) -- менеджер логических томов
операционной системы Linux. LVM предоставляет собой дополнительный
уровень абстракции между физическими/логическими дисками и
файловой системой.
* DRBD (Distributed Replicated Block Deice) -- это блочное
устройство, предназначенное для построения отказоустойчивых
кластерных систем на операционной системе Linux. DRBD занимается
полным отражением (mirroring) по сети всех операций с блочным
устройством. Можно считать, что DRBD это сетевой RAID-1.
Терминология:
* узел -- физический сервер, на котором исполняются виртуальные
машины;
* DRBD-устройство -- дисковый раздел или логический том LVM,
синхронизируемый с помощью DRBD;
* домен -- работающая виртуальная машина Xen;
* кластер -- два узла, которые имеют общие DRBD-устройства, поверх
которых выполняются общие домены Xen.
Идея заключается в том, чтобы в качестве дисковых устройств для
виртуальных машин Xen, использовать DRBD-устройства. DRBD устройства в
свою очередь размещаются поверх LVM томов машин входящих в кластер.
DRBD отвечает за полную синхронизацию операций с дисковыми системами,
выполняющимися доменами Xen.
С точки зрения внешнего наблюдателя не имеет значения, на каком из
узлов кластера в настоящий момент выполняется виртуальная машина.
При плановом выведении узла из эксплуатации, машины, работающие на нём
мигрируют на второй узел кластера. Это совершенно незаметно с точки
зрения внешнего наблюдателя.
При внезапной остановке одного из узлов машины, работавшие на нём,
запускаются на втором узле. С точки зрения внешнего наблюдателя,
работавшего с виртуальной машиной, которая исполнялась на внезапно
выключившемся узле, это выглядит как перезагрузка машины.
Виртуальные машины могут быть произвольно распределены по узлам
кластера.
Реализация
Скрипт xen-drbd предназначен для управления доменами Xen и
используемыми ими DRBD-устройствами.
create domain [host]
Создать домен domain на хосте host, если он указан. Если host
не указан, создать домен domain, на том хосте, за которым он
закреплён.
destroy domain [host]
Закрыть (мгновенно завершить) домен domain на хосте host, если
хост указан, и домен работает на этом хосте. Если хост не
указан, завершить домен там где он работает. Если домен не
работает на указанном хосте или, если хост не указан, не
работает вообще, игнорировать команду.
shutdown domain [host]
То же, что и destroy, только выполнить корректное завершение
домена.
destroy-all-on host
Закрыть все домены, выполняющиеся на хосте host.
shutdown-all-on host
Корректно завершить все домены, выполняющиеся на хосте host.
migrate domain [host]
Выполнить живую миграцию домена на хост host или, если он не
указан, хост противоположный тому, на котором домен сейчас
выполняется.
migrate-all-from host
Выполнить живую миграцию всех доменов, выполняющихся на хосте
host, на противоположный.
list [host]
Показать список доменов, выполняющихся в настойщий момент на
указанном host'е или, если host не указан, на обоих хостах.
info [host]
Показать информацию о доменах, настроенных на указанном host'е
или, если host не указан, на обоих хостах. В числе прочего
должна быть показана информация об именах DRBD-устройств,
использующихся машинами.
Конфигурационные файлы
Конфигурация xen-drbd описывается несколькими файлами:
* /etc/xen/* -- конфигурация xend и доменов Xen;
* /etc/drbd.conf -- конфигурация DRBD, описывает все DRBD-устройства
в системе;
* /etc/xen-drbd.conf -- конфигурация xen-drbd, описывает
распределение доменов по узлам при старте.
Эти конфигурационные файлы должны быть одинаковы на обоих узлах
кластера.
Кластер функционален уже -- без настройки и использования heartbeat,
однако функциональность его частична: при выходе из строя одного из
узлов кластера, доступными останутся только те домены, которые
исполнялись на нём в момент выхода из строя второго узла. Оставшиеся
домены можно будет поднять, но только вручную. Нужно же, чтобы каждый
из узлов имел возможность определить, что его напарник пропал и
запустить все недостающие домены. При этом особенно важно избежать
ситуации, когда каждый узел ошибочно решит, что его напарник
выключился, когда оба они будут работать, просто по какой-то причине
перестанут видеть друг друга. В этом случае может наступить опасная
ситуация, касающаяся взаимной противоречивости данных на
DRBD-устройствах, и названная split-brain.
Вопросы эксплуатации xen-drbd
Создание новых устройств DRBD
При синхронизации множества отдельных томов с помощью DRBD нужно
обратить внимание на следующее:
* Количество синхронизируемых устройств DRBD ограничено.
Максимальное допустимое число задаётся как параметр модуля ядра
drbd при его загрузке. Это число должно быть меньше или равно 255.
* Для синхронизации отдельных устройств DRBD используются отдельные
TCP-порты. При добавлении нового DRBD-устройства обратите внимание
на то, что бы порт, который вы назначаете ему для синхронизации,
уже не был занят.
* Используйте внешние метадиски, поскольку в случае когда метадиск
является внутренним, поведение DRBD при изменении размера
логического тома может оказаться неожиданным.
Множество DRBD-устройств
Максимальное количество используемых одновременно DRBD-устройств
задаётся в качестве параметра minor_count модуля ядра drbd при его
загрузке. Этот параметр не может превышать 255.
Лучше не использовать meta-disk internal, особенно если вы собираетесь
делать ext2resize и LVM.
Нужно создать отдельный том для- meta-disk'ов DRBD и задать его размер
равным 128MB x количество устройств.
Если метадиск создаётся на отдельном логическом томе LVM, то его можно
расширять. Расширять метадиск нужно в том случае, когда количество
DRBD-устройств, использующих его, превышает допустимое. Это число
можно найти, разделив размер метадиска на объём, необходимый для
каждого DRBD-устройства (в настоящий момент 128MB).
Расширение диска DRBD
DRBD-устройство может менять свои размеры. Это возможно в том случае,
если меняют размер (как правило, расширяются) устройства на которых
базируется DRBD. Когда DRBD работает поверх логических томов LVM,
желание расширение DRBD-устройства выглядит весьма естественно,
поскольку изменение размеров LVM-томов является вполне простой и часто
использующейся операцией; хочется, чтобы то, что работает поверх
логического тома LVM могло отреагировать на изменение размеров.
Расширение DRBD-устройства и файловой системы, находящейся на нём,
состоит из следующих шагов:
1. Расширение логического тома, на котором базируется DRBD-устройство
на обоих узлах.
2. Отражение изменений в метадиске.
3. Расширение файловой системы на primary-устройстве.
4. Проверка правильности выполнения.
Например, пусть:
* машины называются primary и secondary
* с помощью DRBD синхронизируется логический том /dev/TURBO/lv0
* размер тома увеличивается на 2G
* на томе создана файловая система ext2/ext3
Все указанные параметры являются необязательными и приведены для
удобства повествования.
Указать домену Xen, использующему DRBD-устройство, что оно изменило
размер, в настоящий момент, к сожалению, невозможно.
В будущем, сообщить об изменении конфигурации дискового устройства
домена будет можно, предположительно, с помощью команды xm
block-configure.
Разрыв линка во время миграции
запускаю миграцию "рву" линк, по которому идет миграция на машине с
которой
eb@chubix:~$ sudo xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 256 2 r----- 8465.5
migrating-dhcp0 12 1024 2 -b---- 11.2
eb@chubix:~$
на машине, на которую
eb@chub:~$ sudo xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 256 4 r----- 10752.2
dhcp0 12 1024 1 --p--- 0.0
eb@chub:~$
"замерзло" так же выполнение
eb@chubix:~$ time sudo xm migrate --live dhcp0 192.168.0.2
и стоять так может наверное "до конца".
виртуалка в это время работает.
через 15 минут восстанавливаю линк. sudo xm migrate --live dhcp0
192.168.0.2 разморозилось. но xm list остались в тех же позах.
eb@chub:~$ sudo xm destroy dhcp0
eb@chub:~$ sudo xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 256 4 r----- 10827.0
Zombie-dhcp0 12 1024 1 --p--d 0.0
eb@chub:~$ sudo xm destroy Zombie-dhcp0
eb@chub:~$ sudo xm lis
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 256 4 r----- 10875.5
Zombie-dhcp0 12 1024 1 --p--d 0.0
eb@chub:~$
Проверка DRBD перед стартом виртуальной машины
Можно сделать так, чтобы виртуальная машина вообще не стартовала до
тех пор, пока соответствующее DRBD-устройство не будет переведено в
состояние primary. (на устройстве в состоянии secondary она может
начать работать, но, когда внутреняя операционная система дойдёт до
момента монтирования корневой файловой системы, загрузка прекратится).
Предположим, машина использует в качестве своего хранилища устройство
/dev/drbd4. В таком случае, проверка будет выглядеть так:
import os
if os.system("grep '4:.*Primary/Secondary' /proc/drbd") != 0:
print "DRBD for this virtual machine not in primary state."
print "Exiting."
exit(1)
Эти строки нужно добавить в конфигурационный файл соответствующего
домена Xen.
Пример использования:
eb@debian:~$ sudo drbdadm secondary vpn
eb@debian:~$ sudo xm create -c vpn
Using config file "/etc/xen/vpn".
DRBD for this virtual machine not in primary state.
Exiting.
Error: 'str' object is not callable
eb@debian:~$ sudo drbdadm primary vpn
eb@debian:~$ sudo xm create -c vpn
Using config file "/etc/xen/vpn".
4: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
Started domain vpn
Linux version 2.6.18-4-xen-686 (Debian 2.6.18.dfsg.1-11)
(waldi@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21)) #1 SMP Wed Feb 21 20:46:15 UTC 2007
BIOS-provided physical RAM map:
Xen: 0000000000000000 - 0000000004800000 (usable)
0MB HIGHMEM available.
72MB LOWMEM available.
.......
Когда DRBD-устройство vpn было в состоянии secondary, создать домен не
удалось.
После того как устройство было переведено в состояние primary, домен
успешно стартанул.
Дополнительные вопросы
Организация дисковой подсистемы: DRBD поверх томов LVM
DRBD и LVM могут работать совместно. Причем в любом взаимном
расположении друг относительно друга:
Во втором случае на каждом из узлов на физических дисковых устройствах
создаются логические тома LVM, поверх которых создаются
DRBD-устройства.
Когда DRBD используется с виртуальными машинами последний вариант
является предпочтительным. Его основное преимущество:
* Различные тома могут быть находиться в состоянии primary и
secondary. В случае с гигантским DRBD-устройством всё устройство
должно быть или в Primary или в Secondary.
Это позволяет сделать выполнять одни виртуальные домены на одном
сервере, а вторые на втором. В том случае, когда используется одного
гигантское DRBD устройство, это невозможно -- все виртуальные домены
должны выполняться на том сервере, где DRBD-устройство сейчас активно.
LVM поверх DRBD или DRBD поверх LVM?
о "зло"...
net { allow-two-primaries;
after-sb-0pri discard-least-changes;
after-sb-1pri call-pri-lost-after-sb;
after-sb-2pri call-pri-lost-after-sb;
}
так работает... но не совсем так, как нам хотелось бы. у нас, на
обеих половинках кластера lvm start... запомните ieто. кладем линк
создаем дисковую активность поднимаем линк drbd отрабатiiвает и видит,
что кому-то надо "догнаться"... но!! похоже, что ieтот кто-то может
догнаться только в положении secondary. а в положение secondary он
может стать только если никто не держить его устройство... т.е.
отмонтировано и затушен lvm. поieтому получаем Mar 5 10:59:41 chub
kernel: drbd0: I shall become SyncTarget, but I am primary!
если на "отставшем" не держать устройство на момент синка после
восстановления линка, то "догонка" +проходит нормально. и догнавшийся
остается в положении secondary, что логично.
Да, это они хорошо придумали. В принципе, было бы хуже, если бы было
не так.
На отдельные DRBD устройства нужно разделять не гигантские физические
тома LVM, а наоборот - синхронизировать с помощью DRBD отдельные
логические LVM-тома.
Мы это уже обсуждали.
Теперь, рассмотрим отдельный логический том LVM. Пусть на этом томе
работает одна какая-то виртуальная машина.
Зачем вообще держать том всё время в состоянии primary? Чтобы ОБА тома
находились в состоянии primary, нужно только на этапе живой миграции.
Всё остальное время можно чтобы primary был только тот, где живая
машина.
То есть, получается так:
|
| ------------------------------------------
| Хост1 Хост2 ВМ на
| ------------------------------------------
| primary secondary хост1
|
| primary primary миграция
|
| secondary primary хост2
| ------------------------------------------
|
V
время
Самый страшный момент это момент миграции, поскольку и до этого, и
после этого у нас вообще всё хорошо: данные живут там, где живёт
машина; если линк и порвался, то просто отключился secondary. А машина
продолжает себе спокойненько жить со своими данными.
Что же произойдёт, если линк порвётся в момент миграции? Это интерсно
даже и не в случае с DRBD, а при самой обычной миграции Xen. Я думаю
(и это был бы самый лучший вариант), что система просто посчитает, что
миграция не завершилась, и сделает так будто бы она и не начиналась. В
этом случае, мы просто должны перевести на хосте2 раздел в режим
secondary и засинкать его с primary, когда линк восстановится.
В общем, интересно, что происходит с мигрирующей машиной, если в этот
момент линк обрывается.
думаю, что будет не так. ситуация конечно не один в однин, но. когда
занимался ping-pong, два раза получалась ситуация, когда во время
миграции domU зависала в непонятной позе. на принимающей стороне она
уже dhcp0, а на стороне отправки она migrating-dhcp0. опции,
показiiвающие состояние не помню.
Кроме того нужно будет написать скрипт обвязки, который будет
переводить режимы работы устройств исходя из состояния (в том числе
миграции) машин.
Есть ещё две проблемы, которые возникают при переходе на
индивидуальные DRBD-устройства для виртуальных машин. Я о них уже
говорил.
1) С LVM-томами работать приятнее. В частности, имена томов намного
удобнее чем номера устройств. Но, в принципе, это не вопрос. Проблема
лечится символическими ссылками, если очень уж захочется.
2) Количество независимых DRBD устройств на одной машине ограничено.
Судя по сообщения в списках рассылки, ограничение не такое уж и
большое. Нужно будет провести эксперимент. Если получится засинкать,
скажем, 64 независимых устройства, то это уже неплохо. На ближайшее
время хватит.
Но вообще, такой подход имеет и несколько неоспоримых преимуществ
тоже. О них я уже говорил. И, на мой взгляд, он является более
правильным.
Что думаете по поводу этого всего?
Миграция доменов Xen, работающих поверх DRBD
Задача:
Пусть есть домен Xen, работающий поверх DRBD-устройств, присутствующих
на двух хостах: host1 и host2. Необходимо организовать простую
возможность живой миграции этого домена между хостами.
Процедура миграции:
1. Домен выполняется на хосте host1. Соответствующие DRBD-устройства
находятся на хосте host1 в состоянии PRIMARY. А на хосте host2 --
в состоянии SECONDARY.
2. Выполняется перевод в состояние PRIMARY используемых доменом
DRBD-дисков на хосте host2. На обоих хостах DRBD-устройства домена
должны быть в состоянии PRIMARY.
3. Выполняется живая миграция домена
4. Выполняется перевод в состояние SECONDARY используемых доменом
DRBD-дисков на хосте host1.
|
| ------------------------------------------
| host1 host2 ВМ работает на
| ------------------------------------------
| primary secondary host1
|
| primary primary миграция
|
| secondary primary host2
| ------------------------------------------
|
V
время
Для того чтобы скрипт выполнялся, необходимо организовать беспарольный
доступ по ssh пользователя root одного хоста к другому и наоборот. Это
можно сделать с помощью [60]host-based аутентификации или с помощью
аутентификации пользователя с помощью открытых ключей. Нужно настроить
двухстороннюю аутентификацию!
Необходимо организовать беспарольный доступ по ssh пользователя root
одного хоста к другому и наоборот.
Процедура реализована с помощью скрипта migrate-drbd-domain. СКРИПТ
Имя скрипта: migrate-drbd-domain
Путь: /usr/local/sbin/migrate-drbd-domain
Назначение скрипта: Скрипт для выполнения живой миграции доменов Xen,
работающих поверх DRBD-устройств
xm list | awk '{print $1}' | egrep -vx 'Name|Domain-0'
| while read domain
do
migrate-drbd-domain ${domain} debian | sh -s && echo $domain
done
Отказоустойчивость сети в связке xen-drbd
> > >
> >
> > Фигня очень простая.
> > В каждый сервер втыкается по две сетевые карты,
> > которые двумя шнурками подключаются
> > к коммутатору.
>
> именно так я и подумал.
>
> >
> > Они работают как единое целое, то есть два канала
> > выглядят как один аггрегированный.
> > При пропадении одного из линков/портов/адаптеров
> > работает на одном без всякой перестройки.
> > Просто в syslog падает алерт.
> >
> > Требует поддержки со стороны коммутатора,
> > то есть на обычном surecom'е так работать не будет.
>
> можно такое сделать через два коммутатора? т.е. с одной сдвоенной картii
> шнурки вiiходят на два коммутатора. защитится от вiiлета одного из
> коммутаторов.
>
Насколько я понимаю, можно но только если коммутаторы в стеке. Просто
на два независимых коммутатора нельзя.
Правда, на два независимых коммутатора можно сделать не
аггрегированный канал, а два канала и использовать на них STP. От
вылета это должно защитить. Но трафик объединяться не будет. В
отдельно взятый момент времени будет работать один из каналов.
Делается это с помощью виртуального бриджа в Linux.
Конфигурируется интерфейс veth0, и работа вся ведётся с ним.
Не знаю, стоит ли городить такой огород.
Но с другой стороны мы всё равно будем городить огород для сети внутри
Xen.
Ещё раз хочу подчеркнуть минусы этого решения по сравнению с
аггрегированными каналами:
1. Каналы не объединияются, а используются попеременно.
2. Переключение с одного канала на другой происходит достаточно долго
. При дефолтных настройках коммутатора это может занять до минуты
. Это связано с работой STP. В RSTP было бы быстрее, но RSTP Linux
Bridge пока не поддерживает.
Плюсы:
1. От коммутаторов ничего не требуется кроме поддержки STP
2. Можно подключаться к двум независимым коммутаторам
3. Не требуется никакая дополнительная настройка коммутаторов
Vova
