18.02.2008

Управление разделами при использовании 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.

05.02.2008

Производительность открытых LDAP серверов

В январе этого года состоялся релиз Fedora Directory Server 1.1. Буквально на следующий день был выпущен аналогичный поддерживаемый продукт Red Hat Directory Server 8.0. Это, а также реакция на наши завления о том, что Red Hat Directory Server производительнее OpenLDAP сподвигли нас на проведение теста.

Методика тестирования

Мы сосредоточились на задачах, которые занимают 90+% всех операций, выполняемых с LDAP-серверами, а именно - операциях одиночного чтения. Под одиночным чтением подразумевается соединение клиента и сервера, аутентификация клиента на сервере, считывание одной записи о отсоединение.
Для этого были сгенерировано плоское дерево, моделирующее простую структуру с большим количеством "пользователей" Иначе говоря, мы сделали N записей вида

dn: uid=user00000,ou=People,dc=example,dc=com
objectClass: account
objectClass: posixAccount
uid: user00000
cn:User User
loginShell: /bin/bash
uidNumber: 100000
gidNumber: 100000
homeDirectory: /home/user00000
gecos: User Userovich 00000

После этого мы измеряли на одной и той же системе, в которой запущен только LDAP-сервер время выполнения 1000 последовательных единичных чтений. При этом мы использовали чтения по RDN (аналог primary key в DBMS), по атрибуту, по которому построен индекс, а также по атрибуту, по которому индекс не построен. При этом оба сервера были настроены использовать одинаковую структуру индексов и одинаковый backend (LDBM).

Для произведения 1000 случайных чтений мы предварительно генерировали последовательность псевдослучайных чисел в необходимом диапазоне, после чего утилитой time измеряли время произведения 1000 вызовов ldapsearch по заданному файлу с последовательностью.

Поскольку мы меняли сервера на одной системе, а также для увеличения репрезантативности тестов, тесты прогонялись 20 раз подряд на разных последовательностях, после чего усреднялись результаты последних 10. Первые 10 прогонов симулировали "разогрев" сервера после перезапуска.

Результаты тестов приведены ниже.

Результаты тестов

Итак, результаты тестов. для начала 1000 четний по RDN и по индексу. Мы представляем результаты единым графиком и таблицей потому, что они все равно получились очень близкие, что неудивительно. Расхождение между этими двумя тестами не превышает погрешности наших измерений.

1000 чтений по RDN/индексу
## записей FDS OpenLDAP
1000 4,39 4,8
5000 4,46 4,85
10000 4,54 4,89
50000 4,65 4,91

Теперб результаты 1000 чтений по атрибуту, индекс по которому не построен. В нашем случае мы использовали атрибут homeDirectory. Предвидя скептические возгласы, скажу, что подобные вещи (поиск по атрибуту без индекса) не должны встречаться в хорошо спланированном LDAP-дереве. Тем не менее результаты вполне имеют право на жизнь, а также наглядно иллюстрируют пользу индексов.
1000 чтений без индекса
## записей FDS OpenLDAP
1000 11,82 25,25
5000 92,99 124,63
10000 232 303
50000 340 1047
Ну и наконец, тест времени заполнения базы. Это есть непосредственно время выполнения ldapadd для файла, содержавшего нашу базу переменного размера. Если помните, LDAP не гарантирует транзакционности, а также неэффективен при операциях на запись. Некоторые люди поэтому предпочитают иметь DBMS (например PostgreSQL) для хранения данных, а LDAP используют для создания копии, которая работает только на чтение.
Добавление записей
## записей FDS OpenLDAP
1000 2,09 20,96
5000 10,9 216,08
10000 23,56 440
50000 183 1181
Ну и наконец мы провели еще один тест. Дождавшись таки пока OpenLDAP импортирует базу в 100 000 записей, мы провели тест на 1000 произвольных чтений по индексу при 200 параллеьно работающих потоках. Для этого мы запустили 200 потоков предыдущих тестов, измеряя прохождение одного из них. Результаты получились следующие:
Red Hat Directory Server - 772 секунды
OpenLDAP - 996 секунд

Выводы


Выводы из этих тестов достаточно очевидны. На небольших базах (до 50 000 записей) и при небольшом количестве параллельных запросов FDS/RHDS и OpenLDAP ведут себя очень схоже. Разница в производительности не дает о себе знать, если грамотно использовать индексы. Однако, OpenLDAP начинает серьезно отставать от конкурента по времени добавления записей, при неструктурированном поиске, а также при увеличении параллелизма. Именно поэтому мы остановились на 50 000 записей - OpenLDAP о-о-очень долго их импортировал.

В качестве вывода можно сказать следующее - для простых и небольших баз OpenLDAP хорошо справляется со своей работой. Тем не менее, для более масштабных и загруженных LDAP серверов FDS подходит лучше, особенно учитывая его богатый функционал, отсутствующий у OpenLDAP, а именно
  • Возможность поддержания нескольких партиций LDAP-каталога на одном сервере
  • Мультимастеринг (говорят, в devel ветке openldap он тоже есть, тем не менее мы используем стабильную версию)
  • Более гибкие возможности репликации
  • Репликацию с AD