Xen поверх DRBD

Автор: Игорь Чубин

Короткий URL: xen/drbd

Здесь описывается каким образом можно построить распределённую отказоустойчивую платформу, предназначенную для исполнения множества виртуальных систем, объединённых в сеть произвольной топологии. Описано специальное программное обеспечение (скрипты xen-drbd), которое предназначено для упрощения развёртывания кластера и управления им.

[править] Задача

Создать распределённую систему виртуализации повышенной отказоустойчивости, обеспечивающую работу виртуальной сети. Сеть объединяет виртуальные машины, работающие под управлением разнообразных операционных систем, и может иметь произвольную топологию. Система должна полностью сохранить свою работоспособность (с допустимой потерей производительности) в случае выхода из строя одной из своих частей.

[править] Решение

Компоненты:

• Xen — монитор виртуальных машин (VMM, Virtual Machine Monitor) или гипервизор (hypervisor) с поддержкой паравиртуализации (para-virtualization) для процессоров x86 архитектуры, распространяющийся с открытым исходным кодом (opensource). Xen может организовать совместное безопасное исполнение нескольких виртуальных машин на одной физической системе с производительностью близкой к непосредственной (native).
• LVM (Logical Volume Manager) — менеджер логических томов операционной системы Linux. LVM предоставляет дополнительный уровень абстракции между физическими/логическими дисками и файловой системой.
• DRBD (Distributed Replicated Block Device) — система репликации блочных устройств, предназначенная для online-репликации дисков в операционной системе Linux. DRBD занимается полным отражением (mirroring) по сети всех операций с блочным устройством. Можно считать, что DRBD это сетевой RAID-1.
• xen-drbd — специальные скрипты, предназначенные для управления совокупностью узлов как единым целом, и упрощающие развёртывание связки, подготовку файловых систем виртуальных машин, создание виртуальной сети и связанное управление виртуальными доменами Xen и состоянием блочных устройств DRBD.

Терминология:

• узел или хост — физический сервер, на котором исполняются виртуальные машины;
• DRBD-устройство — блочное устройство, базирующееся на дисковом разделе или логическом томе LVM, синхронизирующееся со своей копией при помощи DRBD;
• домен — работающая виртуальная машина Xen;
• кластер или связка — два узла, которые имеют общие DRBD-устройства, поверх которых выполняются общие домены Xen.

Физически кластер представляет собой два или более сервера, на которых работают виртуальные машины. Для простоты будем считать, что в связку объединяются два узла, но вообще количество узлов может быть больше.

Виртуальные машины организованы в сеть произвольной топологии. С точки зрения внешнего наблюдателя не имеет значения, на каком из узлов кластера в настоящий момент выполняется виртуальная машина. Виртуальные машины могут быть произвольно распределены по узлам кластера.

Узлы могут работать все (нормальный режим) или частично (аварийный режим или режим обслуживания).

При плановом выведении узла из эксплуатации, машины, работающие на нём, мигрируют на второй узел кластера. Это совершенно незаметно с точки зрения внешнего наблюдателя.

При внезапной остановке одного из узлов, машины, работавшие на нём, запускаются на втором узле. С точки зрения внешнего наблюдателя, работавшего с виртуальной машиной, которая исполнялась на внезапно выключившемся узле, это выглядит как перезагрузка машины. Данные, находящиеся на жёстких дисках виртуальных систем, полностью синхронизированы, поэтому при исчезновении одного из узлов работа виртуальных машин на втором продолжается безболезненно.

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

1. Узел видит, что он изолирован (то есть, не видит не только свою вторую половину, но и вообще никого). В этом случае он выключает все домены.
2. Узел видит, что проблема с его второй половиной (то есть вторая половина не видится, но все остальные контрольные точки сети доступны). В этом случае он запускает у себя все недостающие домены.

С точки зрения внешнего наблюдателя это происходит незаметно, для машин уцелевшего узла, и это выглядит как перезагрузка машины, для машин, которые остались на потерянном узле.

Далее подробно описывается как построена дисковая и сетевая подсистемы виртуальных машин, после чего рассматривается как выполнять инсталляцию и дальнейшее использование кластера.

[править] Диски

В качестве дисковых устройств для виртуальных машин Xen, использовать DRBD-устройства. DRBD-устройства в свою очередь размещаются поверх LVM-томов машин входящих в кластер. DRBD отвечает за полную синхронизацию операций с дисковыми системами, выполняющимися доменами Xen.

DRBD-устройство на узле находится в состоянии primary, если на этом узле исполняется виртуальная машина, использующая его. Если виртуальная машина исполняется на другом узле, соответствующие её дискам устройства на этом узле находятся в состоянии вспомогательном (secondary). В ходе миграции виртуальной машины с одного узла на другой, DRBD-устройства находятся на обоих узлах в состоянии primary.

[править] Виртуальная сеть

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

Здесь рассматривается случай, когда связка состоит из двух узлов, однако в действительности их может быть и больше (об этом ниже).

Виртуальная сеть состоит из доменов и соединяющих их виртуальных мостов. Домен в любой момент времени присутствует только на одном узле кластера. Для виртуальных мостов, наоборот, на каждом узле кластера существует по одному экземпляру.

Одноимённые виртуальные мосты, представленные на разных узлах, являются частью одного широковещательного сегмента, и поэтому топологически равнозначны. Это означает, что не имеет значения на каком узле будет находиться домен и через какой из экземпляров мостов он будет подключён к сети.

Виртуальные мосты называются на всех узлах одинаково. На каждом узле трафик каждого моста тегируется и передаётся на внешний интерфейс (таких интерфейсов может быть и больше, они объединяются с целью повышения отказоустойчивости; см. ниже). Узлы соединены между собой коммутируемой сетью, которая передаёт тегированный по стандарту 802.1Q трафик.

[править] Резервирование коммутаторов и сетевых адаптеров

[править] Использование агрегированных каналов

Сетевые адаптеры узлов могут быть зарезервированы путём агрегирования каналов, соединяющих узел с коммутатором.

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

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

Для работы агрегированного канала необходима поддержка со стороны коммутатора:

• он должен поддерживать агрегированные каналы;
• он должен быть настроен соответствующим образом.

При подключении к двум коммутаторам:

[править] Использование виртуального моста и STP

Можно отказаться от использования агрегированного канала и с некоторой потерей функциональности перейти на использование протокола STP и виртуального моста. Это позволит сделать резервирование коммутатора, однако- у такого решения есть недостаток: в отдельно взятый момент времени будет работать один из каналов.

Соединения с коммутаторами происходят не напрямую а через виртуальных мост (linux bridge) внутри хоста. Этот мост поддерживает протокол STP и в этом контексте может рассматриваться как обычный коммутатор, который не может выйти из строя (точнее, может, но только вместе с хостом, внутри которого он работает).

Соединение двух коммутаторов и двух узлов выглядит так (соединения heartbeat может и не быть, в этом случае в качестве heartbeat-канала будут использоваться основные соединения):

[править] Расширение кластера xen-drbd

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

Основные ограниченные ресурсы:

1. Процессорная мощность;
2. ОЗУ;
3. Объём дискового пространства;
4. Пропускная способность дисковой подсистемы;
5. Пропускная способность сети.

Перечисленные ресурсы можно разбить на две категории. Назовём их условно так:

• Вычислительные ресурсы (1,2,5);
• Ресурсы хранения данных (3,4,5).

Сетевой ресурс является в некотором смысле исключением; как будет видно ниже, частично он может быть отнесён и к первой, и ко второй группе.

Редко бывает, что все ресурсы заканчиваются одновременно. Как правило, сначала начинает не хватать чего-то одного.

Расширение вычислительной возможности кластера достигается следующим образом.

В кластер добавляются новые два узла, без дисковой подсистемы (или она используется только для начальной загрузки). В действительности это может быть и один узел, и три, и вообще число узлов может быть любым, однако для того чтобы сохранить свойство катастрофоустойчивости, необходимо чтобы число узлов было чётным, и они были территориально распределены. Выясняется какие домены должны быть перенесены на новые узлы. Эти домены будут работать как и раньше, только с той разницей, что доступ к своим блочным устройствам они будут получать не напрямую через DRBD, а через iSCSI или AOE.

 Было:
 domU -- DRBD -- disk
 |------ host ------|

 Стало:
 domU -- iSCSI -- iSCSI-domU -- DRBD -- disk
 |-- host1 --||----------- host2 ------------| 

Обратите внимание, что экспорт диска по AoE/iSCSI выполняется не из домена 0 системы, в которой работает DRBD, а из специального гостевого домена. Это сделано для того, чтобы экспортируемое устройство было доступно по неизменному идентификатору, вне зависимости от того, с какого узла связки оно экспортируется, первого или второго. Если экспорт выполнять из домена 0, то при переходе на другой узел связки необходимо во всех гостевых доменах, использующих его, переключаться на устройство с другим идентификатором или изменять идентификатор экспортирующего домена. При использовании же специального экспортирующего домена для переключения на другой хост, достаточно выполнить его миграцию.

При переходе от DRBD-устройств к AoE/iSCSI-устройствам ничего внутри гостевых доменов не меняется. Единственное изменение, которое нужно сделать -- в конфигурационном файле домена указать, что теперь в качестве backend-устройств для дисков используются другие блочные устройства.

Дальнейшее расширение кластера вычислительными узлами выполняется очень легко и ничего не меняет по сути. Новые узлы точно также как и предыдущие могут импортировать блочные устройства по AoE/iSCSI и исполнять их.

Когда заканчиваются ресурсы второй группы (дисковая подсистема), необходимо расширять кластер узлами с дисками и DRBD. Их конфигурация, фактически, повторяет конфигурацию самых первых узлов. Данные синхронизируются при помощи DRBD и экспортируются при помощи специальных доменов. Далее можно использовать экспортированные устройства как и обычно, в гостевых доменах, исполняющихся на любом узле кластера.

Что происходит с родными доменами xen-drbd узлов? Если интенсивность дисковых операций не очень велика, можно предоставлять им доступ к диску не напрямую к DRBD, а через экспортирующий домен по AOE/iSCSI (при этом используется только виртуальная сеть; данные по настоящей сети не передаются). С одной стороны работа по передаче данных возрастает в два раза, с другой -- домен полностью отвязывается от этой пары узлов и может мигрировать по кластеру в любом направлении.

[править] Инсталляция и управление кластером

Для инсталляции и последующего управления связкой узлов был разработан специальный набор скриптов, получивший название xen-drbd.

Скрипты xen-drbd автоматизируют решение нескольких задач, связанных с совместной эксплуатацией системы виртуализации Xen и системы репликации блочных устройств DRBD. Основные задачи:

1. Подготовка дисковых систем для доменов (логические тома, их привязка к DRBD, наполнение);
2. Построение основы для виртуальной сетевой топологии (виртуальные мосты и их привязка к физическим интерфейсам);
3. Координирование действий Xen и DRBD (переключение состояния устройств при миграции и старте; автоматическая миграция при выключении и включении узла и проч.).

Все эти операции могут быть выполнены вручную, но xen-drbd существенно экономит время.

[править] Подготовка узлов

Основная страница: xen-drbd-install

Скрипт xen-drdb-install предназначен для облегчения рутинных операций, выполняющихся при инсталляции нового кластера виртуализации с повышенной отказоустойчивостью, построенного на основе Xen и DRBD.

В результате работы xen-drbd-install создаётся сценарий командного интерпретатора, который выполняет такие действия:

1. Подготовка LVM томов;
2. Настройка DRBD-устройств;
3. Наполнение файловых систем доменов.

Полученный сценарий может быть доработан вручную, а может использоваться непосредственном в том виде, как его сгенерирует xen-drbd-install.

Также xen-drbd-install создаёт виртуальные мосты и ссылки на DRBD-устройства (которые могут использоваться для обращения к DRBD-устройствам по именам).

[править] Управление узлами

Основная страница: xen-drbd

Скрипт xen-drbd обеспечивает взаимное соответствие состояния DRBD-устройств и доменов Xen, использующих их. Он следит за тем, чтобы при выполнении таких операций как запуск и миграция доменов, используемые DRBD-устройства переключались в основное (primary) или резервное (secondary) состояние в зависимости от точки запуска домена или направления миграции.

Он также следит за тем, чтобы один и тот же домен нельзя было запустить на разных узлах кластера несколько раз.

Кроме этого, xen-drbd контролирует процесс запуска и останова узлов: он инициирует миграцию доменов с одного узла на другой в случае останова первого; и обратную миграцию при запуске узла.

[править] Пример

Ниже рассматривается пример, в котором вся серверная инфраструктура предприятия размещена внутри кластера виртуализации xen-drbd.

Описана физическая конфигурация систем, представлена схема виртуальной сети, запущенной в кластере, и конфигурационный файл xen-drbd, который используется для запуска этой сети.

[править] Физическая конфигурация

Система работает поверх двух физических серверов.

Конфигурация физического узла (хост-системы):

Процессоры: 2 процессора Dual-Core AMD Opteron 2218
ОЗУ: 8Гб памяти 
Диски: 4 SATA-диска (объединённые в программный RAID по 2)

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

[править] Схема виртуальной сети

Здесь:

• красные коммутаторы -- точки выхода в реальную сеть;
  • lan -- локальная сеть предприятия;
  • inet1 -- канал связи с одним интернет-провайдером;
  • inet2 -- канал связи со вторым интернет-провайдером.

Два интернет-провайдера используются для повышения отказоустойчивости системы. Это делается не средствами xen-drbd, а другими (см. например, страницы Маршрут по умолчанию, Два шлюза в Интернет и OpenVPN).

Мост tagged0 передаёт тегированный трафик прямо внутрь доменов, которые к нему подключены (igw и samba). Таким образом, домены видят трафик не только одного VLANа, а всех. Домен igw выполнят роль маршрутизатора и фильтра трафика между VLANами.

Напомним, что виртуальная сеть исполняется на двух физических узлах, которые могут быть территориально распределены. В этом случае inet1, inet2 и lan должны бы равнозначными в точках включения серверов. Фактически это означает что одноимённые точки подключения должны быть в одинаковых сетях канального уровня.

[править] Конфигурационный файл xen-drbd

Файл /etc/xen/network: <python/> node1='host1' node2='host2'

from socket import gethostname; i_am=gethostname() if i_am != node1 and i_am != node2:

 raise ValueError, "My hostname (%s) should be equal to node1 (%s) or node2 (%s)" % (i_am, node1, node2)

ip_address = {

 node1: '10.0.0.1',
 node2: '10.0.0.2',

}

node1_ip=ip_address[node1] node2_ip=ip_address[node2]

domains= [ 'dns', 'gw', 'igw', 'pgw', 'ldap', 'mail', 'vpn', 'uucp', 'apt', 'dozor', 'ftp', 'ocs',\

 'proxy', 'vvidd', 'samba', 'appserv3', 'nod32', 'liga', 'appserv1', 'jbr', 'appserv2']

domain_types= [ 'linux', 'linux', 'linux', 'linux', 'linux', 'linux', 'linux', 'linux', 'linux', 'linux', 'linux', 'linux',\

'linux', 'linux', 'linux', 'linux', 'hvm', 'hvm', 'linux', 'linux', 'linux']

domain_home = {

 node1 : ['dns', 'gw', 'igw', 'pgw', 'ldap', 'mail', 'vpn', 'uucp', \
 'dozor', 'ftp', 'ocs', 'proxy', 'vvidd', 'samba','appserv1'],
 node2 : ['apt', 'nod32', 'appserv3', 'liga', 'jbr', 'appserv2'],
 }

kernel = "/boot/vmlinuz-2.6.18-4-xen-686" ramdisk = "/boot/initrd.img-2.6.18-4-xen-686-domU"

mem_table={

 'dns'  :64,
 'gw'  :64,
 'igw'  :64,
 'pgw'  :64,
 'ldap'  :64,
 'mail'  :384,
 'vpn'  :192,
 'uucp'  :128,
 'apt'  :128,
 'dozor' :256,
 'ftp'  :128,
 'ocs'  :256,
 'proxy' :256,
 'vvidd' :128,
 'samba' :512,
 'appserv3' :3072,
 'nod32' :96,
 'liga'  :256,
 'appserv1' :512,
 'jbr'  :384,
 'appserv2'  :1024,

}

vcpus_table={

 'dns'  :1,
 'gw'  :1,
 'igw'  :1,
 'pgw'  :1,
 'ldap'  :1,
 'mail'  :2,
 'vpn'  :2,
 'uucp'  :2,
 'apt'  :2,
 'dozor' :2,
 'ftp'  :1,
 'ocs'  :2,
 'proxy' :2,
 'vvidd' :1,
 'samba' :2,
 'appserv3' :2,
 'nod32' :1,
 'liga'  :1,
 'appserv1' :1,
 'jbr'  :2,
 'appserv2'  :2,

}

lvm_vg_name="TURBO" lvm_pv_names="/dev/md2" lvm_lv_drbd_meta_name="meta" lvm_lv_drbd_meta_size="5G" mkfs_options="-m1"

disk_table={

 'gw'  : ['drbd1:gw:2G'],
 'igw'  : ['drbd2:igw:2G'],
 'dns'  : ['drbd3:dns:2G'],
 'vpn'  : ['drbd4:vpn:2G'],
 'apt'  : ['drbd5:apt:10G'],
 'proxy'  : ['drbd6:proxy:5G'],
 'pgw'  : ['drbd7:pgw:2G'],
 'ldap'  : ['drbd8:ldap:4G'],
 'mail'  : ['drbd10:mail:4G','drbd12:maildir:150G'],
 'uucp'  : ['drbd11:uucp:4G'],
 'samba'  : [
 'drbd18:samba:3G',
 'drbd13:samba-home:150G',
 'drbd14:samba-share1:80G',
 'drbd15:samba-share2:20G',
 'drbd16:samba-share3:130G',
 'drbd17:samba-profiles:120G',
 ],
 'dozor'  : ['drbd19:dozor:20G'],
 'vvidd'  : ['drbd20:vvidd:3G'],
 'ocs'  : ['drbd21:ocs:5G'],
 'ftp'  : ['drbd23:ftp:20G'],
 'appserv3'  : ['drbd22=hda:appserv3:200G'],
 'nod32'  : ['drbd25:nod32:2G'],
 'liga'  : ['drbd26:liga:10G'],
 'appserv1'  : ['drbd27=hda:appserv1:10G'],
 'jbr'  : ['drbd28=hda:jbr:15G'],
 'appserv2'  : [
 'drbd29=hda1:appserv2:10G',
 'drbd30=hdb:appserv2-raw:50G',
 ],

}

trunk='eth0' management_interface='bridge1' management_ip=ip_address[i_am] management_gw='10.0.1.253' management_netmask='255.255.255.0'

bridges=['tagged0', 'bridge1', 'bridge6', 'bridge5', 'bridge3', 'bridge4', 'bridge7'] vlans= ['tagged', 1, 256, 257, 3, 4, 501 ]

vbridges_table={

 'dns'  : ['bridge3'],
 'gw'  : ['bridge7', 'bridge6', 'bridge5'],
 'igw'  : ['tagged0','bridge3'],
 'pgw'  : ['bridge3','bridge7'],
 'ldap'  : ['bridge3'],
 'mail'  : ['bridge3'],
 'samba'  : ['tagged0'],
 'vpn'  : ['bridge3'],
 'apt'  : ['bridge3'],
 'proxy'  : ['bridge3'],
 'uucp'  : ['bridge3'],
 'dozor'  : ['bridge3'],
 'vvidd'  : ['bridge3'],
 'ocs'  : ['bridge3'],
 'ftp'  : ['bridge3'],
 'appserv3'  : ['bridge1'],
 'nod32'  : ['bridge3'],
 'liga'  : ['bridge3'],
 'appserv1'  : ['bridge3'],
 'jbr'  : ['bridge1'],
 'appserv2'  : ['bridge1'],

}

if domain == 'appserv1':

 del kernel, ramdisk
 bootloader='/usr/lib/xen-3.2-1/bin/pygrub'

if domain == 'liga':

 localtime='2'

debian_release="lenny" debian_mirror="http://apt.example.com.ua:9999/debian" apt_get_install="less tcpdump dnsutils vim ntp screen snmpd libc6-xen openssh-server" apt_get_install_table={

 "dns"  :"bind9",
 "vpn"  :"openvpn",
 "ldap"  :"slapd ldap-utils",
 "mail"  :"sendmail dovecot-imapd solid-pop3d libpam-ldap libnss-ldap",
 "uucp"  :"uucp mgetty ppp socat",
 "samba" :"samba samba-common smbldap-tools libpam-ldap libnss-ldap",
 "igw"  :"dhcp3-server",
 "jabber":"ejabberd libpam-ldap libnss-ldap",
 "gw"  :"redir pppoe",

}

ip_network="10.0.1" ip_netmask="255.255.255.224" domain_name="example.com" ip_nameserver="10.0.1.4" ip_gateway="10.0.1.6"

ip_address_table={

 "dns"  :"10.0.1.4",
 "gw"  :"10.0.1.254",
 "igw"  :"10.0.1.3",
 "pgw"  :"10.0.1.6",
 "ldap"  :"10.0.1.11",
 "mail"  :"10.0.1.9",
 "samba" :"10.0.1.1",
 "vpn"  :"10.0.1.5",
 "apt"  :"10.0.1.7",
 "uucp"  :"10.0.1.12",
 "dozor" :"10.0.1.14",
 "vvidd" :"10.0.1.15",
 "ocs"  :"10.0.1.16",
 "ftp"  :"10.0.1.18",

}