И серьезно стал вопрос о выборе нового гипервизора. Реально имеем две альтернативы - Xen (Citrix и XCP) и RHEV (KVM). Свое мнение про них и сравнительный анализ я напишу позже, когда все эксперименты закончатся и будет сделан выбор.
Пока в данной статье я опишу "кусочек" экспериментов. Мне понадобилось изменить размер shared SAN partition на Citrix Xen 5.6 FP1 - на раздел не помещаются снапшоты, а без снапшотов нормально бекап не провести - нужно останавливать виртуалку, что неприемлемо.
Разумеется, изменение размера нужно делать "на лету". Забегая немного вперед, отмечу, что мне удалось сделать это, даже не останавливая виртуалку, запущенную на этом томе!. Честно говоря, дисковой активности в виртуалке не было, т.е. эксперимент не совсем "чистый". И Citrix честно предупреждают, что рекомендуют все-таки виртуалку останавливать "во избежании". Полагаю, что все-таки можно производить ресайз раздела и без остановки, если активность диска низкая. Как-нибудь при возможности попробую провести эксперимент.
Но вернемся к задаче.
Итак, формулировка: Есть shared storage, расположенный на SAN. К стораджу, разумеется, подключаемся двумя адаптерами и multipath включен (мы же все-таки enterprise ;) ). Имеем два XenServer'а в пуле. На разделе расположена виртуальная машина (запущенная). Задача - увеличить размер раздела без перезагрузки Xen-серверов (и желательно без остановки виртуалки). 100% рабочего алгоритма, как обычно, в инете я не нашел. Пришлось компилить из разных источников :)
Последовательность действий:
- логинимся на один из Xen-серверов.
- смотрим статус multipath:
# mpathutil status
3600508b40010525700011000228f0000 dm-1 HP,HSV210
[sizе=17G ][features=1 queue_if_no_path][hwhandler=0 ][rw ]
\_ round-robin 0 [prio=200][enabled]
\_ 2:0:6:1 sdm 8:192 [active][ready]
\_ 2:0:4:1 sdi 8:128 [active][ready]
\_ 1:0:6:1 sde 8:64 [active][ready]
\_ 1:0:4:1 sda 8:0 [active][ready]
\_ round-robin 0 [prio=40][enabled]
\_ 2:0:7:1 sdo 8:224 [active][ready]
\_ 2:0:5:1 sdk 8:160 [active][ready]
\_ 1:0:7:1 sdg 8:96 [active][ready]
\_ 1:0:5:1 sdc 8:32 [active][ready]
Вместо mpathutil status можно воспользоваться командой multipath -l - это одно и то же.
Нас интересует две вещи: WWID тома и имена scsi устройств, через которых работает dev-mapper - смотрим uuid тома, который нам нужно ресайзить. Вообще-то можно обойтись и без него, зная только WWID - задача заключается в идентификации тома в LVM (чуть дальше), но может не сработать при отсуствии multipath (не проверял, негде :)):
# xe sr-list name-label=STORAGE
uuid ( RO) : 62cf6e68-40ff-bd54-4089-5c8e3a55162a
name-label ( RW): STORAGE
name-description ( RW): Hardware HBA SR [HP - /dev/sde [sdg] [sda] [sdc] [sdm] [sdo] [sdi] [sdk]]
host ( RO): <shared>
type ( RO): lvmohba
content-type ( RO): - смотрим состояние тома в lvm:
# pvs | grep 62cf6e68-40ff-bd54-4089-5c8e3a55162a
/dev/mapper/3600508b40010525700011000228f0000 VG_XenStorage-62cf6e68-40ff-bd54-4089-5c8e3a55162a lvm2 a- 16.99G 0.94G
Тут мы видим, что устройство размером в 17 гиг, свободно почти гиг - пора ресайзить раздел со стороны SAN. Делаем это через интерфейс управления стораджем, увеличивая, например, до 30Gb
- возвращаемся в консоль XenServer. Даем команду FC адаптерам пересканировать сторадж. У меня Emulex, поэтому я приведу команды для него. Для других адаптеров команда рескана может отличаться!
# echo "- - -" > /sys/class/scsi_host/host0/rescan
# echo "- - -" > /sys/class/scsi_host/host1/rescan
Как легко заметить, команды ничем не отличается от рескана для RHEL. Не удивительно - Citrix Xen базируется именно на RHEL :) - теперь нужно пересканировать каждое из scsi устройств (дисков), через которые работает dev-mapper. Фокус с удалением дисков (как я использовал ранее при рескане) нас не устраивает - том не должен потеряться, у нас же там живая виртуалка продолжает работать! Делаем это командами:
# echo 1 > /sys/block/sda/device/rescan
# echo 1 > /sys/block/sde/device/rescan
# echo 1 > /sys/block/sdi/device/rescan
# echo 1 > /sys/block/sdm/device/rescan
# echo 1 > /sys/block/sdo/device/rescan
# echo 1 > /sys/block/sdk/device/rescan
# echo 1 > /sys/block/sdg/device/rescan
# echo 1 > /sys/block/sdc/device/rescan
Вот где нам пригодились имена дисков! Мы ресканим последовательно все. - на всякий случай проверяем, что размер ресканированніх дисков изменился:
# fdisk -l /dev/sda
Disk /dev/sda: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Disk /dev/sda doesn't contain a valid partition table
Замечательно, то, что нам нужно! - Но это еще не все. Осталось всего два этапа: сообщить multipath и lvm об изменениях. Для multipath это делается командой:
# multipathd -k"resize map 3600508b40010525700011000228f0000"
ok
Вот тут нам и пригодился WWID. - проверяем, изменился ли размер:
# multipath -l
3600508b40010525700011000228f0000 dm-1 HP,HSV210
[sizе=30G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=0][enabled]
\_ 2:0:6:1 sdm 8:192 [active][undef]
\_ 2:0:2:1 sdi 8:128 [active][undef]
\_ 1:0:6:1 sde 8:64 [active][undef]
\_ 1:0:4:1 sda 8:0 [active][undef]
\_ round-robin 0 [prio=0][enabled]
\_ 2:0:7:1 sdo 8:224 [active][undef]
\_ 2:0:5:1 sdk 8:160 [active][undef]
\_ 1:0:5:1 sdc 8:32 [active][undef]
\_ 1:0:7:1 sdg 8:96 [active][undef]
Отлично, все получилось! - теперь завершающий этап - ресайз lvm:
# pvresize /dev/mapper/3600508b40010525700011000228f0000
Physical volume "/dev/mapper/3600508b40010525700011000228f0000" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
И проверяем:# pvs | grep 62cf6e68-40ff-bd54-4089-5c8e3a55162a
/dev/mapper/3600508b40010525700011000228f0000 VG_XenStorage-62cf6e68-40ff-bd54-4089-5c8e3a55162a lvm2 a- 29.99G 13.94G
Все получилось! Теперь на всех серверах пула повторяем процедуру, за исключением ресайза тома на SAN и ресайза LVM. Очевидно, что серверам нужно сообщить об изменениях, но повторно ресайзить не нужно.
Теперь запускаем XenCenter и проверяем, что SR виден нового размера. Если виден старого размера, нужно выбрать SR в дереве слева, перейти на закладку Storage и нажать Rescan.
Все, задача выполнена. Дальнейшее увеличение размера и/или добавление диска(ов) для виртуалки внутри Xen - тривиальная задача, особенно с помощью XenCenter.
Немає коментарів:
Дописати коментар