Управление разделами при использовании Xen.

Виртуализация с помощью Xen - крайне удобный способ консолидации серверов и упрощения управления ими. Тем не менее, для оптимального (или близкого к оптимальному) управления виртуальными системами необходимо грамотно подходить к архитектуре решения. Рассмотрим управление дисками и разделами для виртуальных серверов.

Варианты использования

На первый взгляд, существует по крайней мере четыре способа управления храением данных.

1. Выделение отдельного диска или массива под каждую виртуальную машину.
2. Выделение одной или нескольких партиций диска под виртуальную машину.
3. Выделение одного или нескольких логических томов (LVM) под каждую виртуальную машину.
4. Хранение фалов-образов виртуальных машин на файловой системе Dom0.

При этом, конечно, хочется добиться максимальной гибкости, а также не потерять в производительности. В качестве типовых будем рассматривать три типичные задачи:

1. Увеличение количества виртуальных машин.
   
2. Резервное копирование виртуальных машин.
3. Расширение дискового пространства виртуальных машин.
4. Перемещение работающей виртуальной машины между дисками.

Отдельный диск под каждую виртуальную машину

Хотя этот способ многим покажется оптимальным, в реальной жизни не все получается гладко. Недостаток номер один - во многих существующих системах просто невозможно выделить отдельный массив (скажем Raid1) под каждую виртуальную машину. Причем невозможно просто физически, например в 2U корпус просто зачастую не влезает более 6 HDD. В этом случае количество виртуальных систем было бы ограничено тремя.
При проведении резервного копирования виртуальных систем мы можем получить доступ к LVM гостевой системы, причем этот доступ мы будем получать каждый раз при загрузке Dom0. При резервном копировании нам придется использовать эксключивную блокировку snapshot логического тома.
Расширение дискового пространства виртуальных машин, по описанным выше причинам, не позволит вам сохранить парадигму уравления хранением данных. Потребности виртуальных систем в дисковом пространстве могут сильно отличаться, в то время как объемы и количество дисков остаются неизменными.
Перемещение работающей виртуальной машины между дисками - операция достаточно рутинная, заключающаяся в подсоединении нового жесткого диска коммандой

[root@dom0 ~]# xm block-attach domu phy:/dev/sdXY xvdb w

После чего перемещением Расширением LVM и переносом physical extents на новый физический том.

[root@domu ~]# pvcreate /dev/xvdb
[root@domu ~]# vgextend vg00 /dev/xvdb
[root@domu ~]# pvmove vgo0 /dev/xvda /dev/xvdb
[root@domu ~]# vgreduce vgo0 /dev/xvda

За чем следут отсоединение старого блочного устройства из Dom0.

[root@dom0 ~]# xm block-list domu
xm Vdev  BE handle state evt-ch ring-ref BE-path
51712    0    0     4      8      8     /local/domain/0/backend/tap/5/51712
....
[root@dom0 ~]# xm block-detach domu 51712

Выделение одной или нескольких партиций диска под DomU

Этот способ по сути повторяет предыдущий. Исключение:

1. Партиций можно завести гораздо больше, чем физических дисков.

Из этого напрямую следуют недостатки этого метода:

1. После нескольких переразметок дискового пространства может случиться так, что партиции будут фрагментированы по диску, так что вы не всегда сможете создать партицию необходимого размера.
2. DomU во время установки все равно "захочет" разметить то блочное устройство, которое ему отдадут. Получим "вложенные" таблицы разделов.

Выделение нескольких LV под DomU

В этом сценарии при установке DomU создается LVM. Несколько LV из этого LVM экспортируются в DomU. DomU размечает предоставленные ему устройства и создает на них свой LVM. Для того, чтобы их различать, далее будет обозначать LVM0 - LVM в Dom0, а LVMU - LVM в DomU.
В случае увеличения объема дискового простанства, мы не можем просто увеличить объем логического тома в LVM0. В DomU не будет сгенерировано событие Hotplug, и DomU будет по прежнему использовать старую геометрию виртуального диска. Вместо этого мы выделим еще один логический том в Domo, экспортируем его в DomU и "растянем" LVMU.

[root@dom0 ~]# lvcreate -n domu-newlv -L 10G hostvg
[root@dom0 ~]# xm block-attach domu  phy:/dev/hostvg/domu-newlv xvdb w

Создадим на диске единственную партицию (можно обойтись и без этого) и "растянем" vg00, логический том и фаловую систему. Напомним, что уже довольно давно ext3 поддерживает online-resize.

[root@dom0 ~]# pvcreate /dev/xvdb1
[root@dom0 ~]# vgextend vg00 /dev/xvdb1
[root@dom0 ~]# lvextend -l+100%FREE /dev/vg00/lv
[root@dom0 ~]# resize2fs /dev/vg00/lv

Для резервного копирования виртуальных машин можно сделать snapshot логических томов LVM0, на которых распогалаются данные domu. После чего можно получить средствами device-mapper доступ к вложенным партициям, собрать из них в Dom0 копию LVM гостевой машины и получить доступ к "снимку" данных виртуальной системы без боязни его повредить.
Делается следующим образом.

[root@dom0 ~]# lvcreate -s -n domulv-snapshot -L 5G /dev/hostlv/domulv
[root@dom0 ~]# kpartx /dev/hostlv/domulv-snapshot
[root@dom0 ~]# pvs; vgs; vgchange -ay

При этом мы получаем моментальный снимок даных, формируем из него копию LVMU, делаем с ней что хотим, после чего уничтожаем snapshot.
Осуществление перемещения между дисками осуществляется аналогично расширению пространства, за исключением того, что мы отключаем старый LV от DomU. При этом мы можем уничтожить LV в LVM0, не чтрадая при этом от фрагментирования.
Количество логических томов, которые мы можем выделить виртуальным машинам ограничено только здравым смыслом. =)

Файлы-образы

Все операции здесь абсолютно аналогичны операциям с партициями кроме того, что мы экспортируем не блочное устройство через петлевой драйвер, а файл в режиме эмуляции блочного устройства.

Резюме

В любом случае найдется достаточно людей с разнями воззрениями, чтобы реализовать все описанные методы. Тем не менее, о результатам лично я буду польоваться способом №3, когда содается "двухслойный" LVM.