xen/drbd/мысли
Материал из Xgu.ru
< xen/drbd
Здесь находятся необработанные записки и фрагменты переписок. Они в конце концов должны быть обработаны и перенесены в xen/drbd. Тогда эту страницу можно будет стереть.
Содержание |
[править] Дополнительные вопросы
[править] Организация дисковой подсистемы: DRBD поверх томов LVM
DRBD и LVM могут работать совместно. Причем в любом взаимном расположении друг относительно друга:
(1) LVM поверх DRBD-устройства
+-------------------+ | | LVM | | +-------------------+ +-------------------+ | DRBD | +-------------------+
(2) DRBD устройства поверх томов LVM
+---++--------++----+ | || DRBD || | +---++--------++----+ +-------------------+ | | LVM | | +-------------------+
В первом случае DRBD-устройство является физическим томом, на котором создаются логические тома LVM.
%# pvcreate /dev/drbd0 %# vgcreate TURBO /dev/drbd0 %# lvcreate -L 2048M -n lv0 /dev/TURBO
Во втором случае на каждом из узлов на физических дисковых устройствах создаются логические тома 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... запомните єто. кладем линк создаем дисковую активность поднимаем линк drbd отрабатівает и видит, что кому-то надо "догнаться"... но!! похоже, что єтот кто-то может догнаться только в положении secondary. а в положение secondary он может стать только если никто не держить его устройство... т.е. отмонтировано и затушен lvm. поєтому получаем 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, когда линк восстановится.
В общем, интересно, что происходит с мигрирующей машиной, если в этот момент линк обрывается.
(OYu)
думаю, что будет не так.
ситуация конечно не один в однин, но. когда занимался ping-pong, два
раза получалась ситуация, когда во время миграции domU зависала в
непонятной позе. на принимающей стороне она уже dhcp0, а на стороне
отправки она migrating-dhcp0. опции, показівающие состояние не помню.
(/OYu)
Кроме того нужно будет написать скрипт обвязки, который будет переводить режимы работы устройств исходя из состояния (в том числе миграции) машин.
Есть ещё две проблемы, которые возникают при переходе на индивидуальные DRBD-устройства для виртуальных машин. Я о них уже говорил.
1) С LVM-томами работать приятнее. В частности, имена томов намного удобнее чем номера устройств. Но, в принципе, это не вопрос. Проблема лечится символическими ссылками, если очень уж захочется.
2) Количество независимых DRBD устройств на одной машине ограничено. Судя по сообщения в списках рассылки, ограничение не такое уж и большое. Нужно будет провести эксперимент. Если получится засинкать, скажем, 64 независимых устройства, то это уже неплохо. На ближайшее время хватит.
Но вообще, такой подход имеет и несколько неоспоримых преимуществ тоже. О них я уже говорил. И, на мой взгляд, он является более правильным.
Что думаете по поводу этого всего?
[править] Миграция доменов Xen, работающих поверх DRBD
Задача:
Пусть есть домен Xen, работающий поверх DRBD-устройств, присутствующих на двух хостах: host1 и host2. Необходимо организовать простую возможность живой миграции этого домена между хостами.
+---++--------++----+ | || DRBD || | +---++--------++----+
Решение:
Процедура миграции:
- Домен выполняется на хосте host1. Соответствующие DRBD-устройства находятся на хосте host1 в состоянии PRIMARY. А на хосте host2 — в состоянии SECONDARY.
- Выполняется перевод в состояние PRIMARY используемых доменом DRBD-дисков на хосте host2. На обоих хостах DRBD-устройства домена должны быть в состоянии PRIMARY.
- Выполняется живая миграция домена
- Выполняется перевод в состояние SECONDARY используемых доменом DRBD-дисков на хосте host1.
|
| ------------------------------------------
| host1 host2 ВМ работает на
| ------------------------------------------
| primary secondary host1
|
| primary primary миграция
|
| secondary primary host2
| ------------------------------------------
|
V
время
Для того чтобы скрипт выполнялся, необходимо организовать беспарольный доступ по ssh пользователя root одного хоста к другому и наоборот. Это можно сделать с помощью host-based аутентификации или с помощью аутентификации пользователя с помощью открытых ключей. Нужно настроить двухстороннюю аутентификацию!
|
|
Необходимо организовать беспарольный доступ по ssh пользователя root одного хоста к другому и наоборот. |
Процедура реализована с помощью скрипта migrate-drbd-domain.
СКРИПТ
Имя скрипта: migrate-drbd-domain
Путь: /usr/local/sbin/migrate-drbd-domain
Назначение скрипта: Скрипт для выполнения живой миграции доменов Xen, работающих поверх DRBD-устройств
<perl/>
<sh/>
xm list | awk '{print $1}' | egrep -vx 'Name|Domain-0' \ | while read domain do migrate-drbd-domain ${domain} debian | sh -s && echo $domain done
[править] Проверка 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.
Пример использования:
%$ sudo drbdadm secondary vpn %$ 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 %$ sudo drbdadm primary vpn %$ 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), домен был успешно запущен.
|
|
Если для управления доменами Xen используется скрипт xen-drbd, то эту проверку выполнять не нужно. Она автоматически выполняется скриптом. |
