Xen поверх DRBD
Материал из Xgu.ru
- Автор: Игорь Чубин
- Короткий 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.
Физически кластер представляет собой два или более сервера, на которых работают виртуальные машины. Для простоты будем считать, что в связку объединяются два узла, но вообще количество узлов может быть больше.
Виртуальные машины организованы в сеть произвольной топологии. С точки зрения внешнего наблюдателя не имеет значения, на каком из узлов кластера в настоящий момент выполняется виртуальная машина. Виртуальные машины могут быть произвольно распределены по узлам кластера.
Узлы могут работать все (нормальный режим) или частично (аварийный режим или режим обслуживания).
При плановом выведении узла из эксплуатации, машины, работающие на нём, мигрируют на второй узел кластера. Это совершенно незаметно с точки зрения внешнего наблюдателя.
При внезапной остановке одного из узлов, машины, работавшие на нём, запускаются на втором узле. С точки зрения внешнего наблюдателя, работавшего с виртуальной машиной, которая исполнялась на внезапно выключившемся узле, это выглядит как перезагрузка машины. Данные, находящиеся на жёстких дисках виртуальных систем, полностью синхронизированы, поэтому при исчезновении одного из узлов работа виртуальных машин на втором продолжается безболезненно.
|
|
При внезапном выключении одного из узлов, домены исполнявшиеся на нём теряются и запускаются снова на втором узле. Это выглядит как перезагрузка доменов. Полная отказоустойчивость системы (то есть, когда домены даже не будут перезагружаться), вероятно, будет возможна с выходом Kemari или что более вероятно Remus |
При разрыве связи между узлами каждый узел определяет, по какой причине он не видит второй узел. Здесь возможны два варианта:
- Узел видит, что он изолирован (то есть, не видит не только свою вторую половину, но и вообще никого). В этом случае он выключает все домены.
- Узел видит, что проблема с его второй половиной (то есть вторая половина не видится, но все остальные контрольные точки сети доступны). В этом случае он запускает у себя все недостающие домены.
С точки зрения внешнего наблюдателя это происходит незаметно, для машин уцелевшего узла, и это выглядит как перезагрузка машины, для машин, которые остались на потерянном узле.
Далее подробно описывается как построена дисковая и сетевая подсистемы виртуальных машин, после чего рассматривается как выполнять инсталляцию и дальнейшее использование кластера.
[править] Диски
В качестве дисковых устройств для виртуальных машин Xen, использовать DRBD-устройства. DRBD-устройства в свою очередь размещаются поверх LVM-томов машин входящих в кластер. DRBD отвечает за полную синхронизацию операций с дисковыми системами, выполняющимися доменами Xen.
DRBD-устройство на узле находится в состоянии primary, если на этом узле исполняется виртуальная машина, использующая его. Если виртуальная машина исполняется на другом узле, соответствующие её дискам устройства на этом узле находятся в состоянии вспомогательном (secondary). В ходе миграции виртуальной машины с одного узла на другой, DRBD-устройства находятся на обоих узлах в состоянии primary.
[править] Виртуальная сеть
Можно рассматривать связку физических узлов, как единое целое, которое обеспечивает работу виртуальной сети произвольной топологии.
Здесь рассматривается случай, когда связка состоит из двух узлов, однако в действительности их может быть и больше (об этом ниже).
Виртуальная сеть состоит из доменов и соединяющих их виртуальных мостов. Домен в любой момент времени присутствует только на одном узле кластера. Для виртуальных мостов, наоборот, на каждом узле кластера существует по одному экземпляру.
Одноимённые виртуальные мосты, представленные на разных узлах, являются частью одного широковещательного сегмента, и поэтому топологически равнозначны. Это означает, что не имеет значения на каком узле будет находиться домен и через какой из экземпляров мостов он будет подключён к сети.
Виртуальные мосты называются на всех узлах одинаково. На каждом узле трафик каждого моста тегируется и передаётся на внешний интерфейс (таких интерфейсов может быть и больше, они объединяются с целью повышения отказоустойчивости; см. ниже). Узлы соединены между собой коммутируемой сетью, которая передаёт тегированный по стандарту 802.1Q трафик.
- Виртуальная сеть состоит из четырёх виртуальных машин (dom1, dom2, dom3 и dom4), работающих на кластере из двух физических узлов.
- Виртуальные машины соединены при помощи мостов br1, br2, br3
- Трафик виртуальных мостов отражается на тегированный трафик VLAN'ов 101, 102 и 103 соответственно
- Снаружи сеть видна как сеть с звездообразной топологией
- Не имеет значения, где сейчас физически исполняется какой домен. Например, dom1, dom3 и dom4 исполняются на host1, а dom2 на host2
- В ходе работы системы домены могут незаметно для пользователей мигрировать между узлами (например, сейчас будет мигрировать dom1)
[править] Резервирование коммутаторов и сетевых адаптеров
[править] Использование агрегированных каналов
Сетевые адаптеры узлов могут быть зарезервированы путём агрегирования каналов, соединяющих узел с коммутатором.
В каждом сервере должно быть по два сетевых адаптера, каждый из которых подключается к коммутатору. Они работают как единое целое, то есть два канала выглядят как один агрегированный.
При пропадании одного из соединений (это может быть связано с неполадками адаптера, соединительного кабеля или порта коммутатора) система продолжает работу на оставшемся. В системном журнале появляется сообщение о возникшей проблеме.
Для работы агрегированного канала необходима поддержка со стороны коммутатора:
- он должен поддерживать агрегированные каналы;
- он должен быть настроен соответствующим образом.
При подключении к двум коммутаторам:
[править] Использование виртуального моста и STP
Можно отказаться от использования агрегированного канала и с некоторой потерей функциональности перейти на использование протокола STP и виртуального моста. Это позволит сделать резервирование коммутатора, однако- у такого решения есть недостаток: в отдельно взятый момент времени будет работать один из каналов.
Соединения с коммутаторами происходят не напрямую а через виртуальных мост (linux bridge) внутри хоста. Этот мост поддерживает протокол STP и в этом контексте может рассматриваться как обычный коммутатор, который не может выйти из строя (точнее, может, но только вместе с хостом, внутри которого он работает).
Соединение двух коммутаторов и двух узлов выглядит так
(соединения heartbeat может и не быть, в этом случае
в качестве heartbeat-канала будут использоваться
основные соединения):
[править] Расширение кластера xen-drbd
Система в начальной конфигурации состоит из двух одинаковых узлов, которые используются как для хранения данных, так и для исполнения доменов. Со временем, по мере того как нагрузка на систему возрастает, и ресурсов связки начинает не доставать, возникает необходимость в включении в кластер новых узлов и распределении нагрузки на них.
Основные ограниченные ресурсы:
- Процессорная мощность;
- ОЗУ;
- Объём дискового пространства;
- Пропускная способность дисковой подсистемы;
- Пропускная способность сети.
Перечисленные ресурсы можно разбить на две категории. Назовём их условно так:
- Вычислительные ресурсы (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 имеют собственные идентификаторы, и автоматически передаваться между парами они не могут. |
Что происходит с родными доменами xen-drbd узлов?
Если интенсивность дисковых операций не очень велика,
можно предоставлять им доступ к диску не напрямую к DRBD,
а через экспортирующий домен по AOE/iSCSI (при этом используется
только виртуальная сеть; данные по настоящей сети не передаются).
С одной стороны работа по передаче данных возрастает в два раза,
с другой -- домен полностью отвязывается от этой пары узлов
и может мигрировать по кластеру в любом направлении.
[править] Инсталляция и управление кластером
Для инсталляции и последующего управления связкой узлов был разработан специальный набор скриптов, получивший название xen-drbd.
Скрипты xen-drbd автоматизируют решение нескольких задач, связанных с совместной эксплуатацией системы виртуализации Xen и системы репликации блочных устройств DRBD. Основные задачи:
- Подготовка дисковых систем для доменов (логические тома, их привязка к DRBD, наполнение);
- Построение основы для виртуальной сетевой топологии (виртуальные мосты и их привязка к физическим интерфейсам);
- Координирование действий Xen и DRBD (переключение состояния устройств при миграции и старте; автоматическая миграция при выключении и включении узла и проч.).
Все эти операции могут быть выполнены вручную, но xen-drbd существенно экономит время.
[править] Подготовка узлов
- Основная страница: xen-drbd-install
Скрипт xen-drdb-install предназначен для облегчения рутинных операций, выполняющихся при инсталляции нового кластера виртуализации с повышенной отказоустойчивостью, построенного на основе Xen и DRBD.
В результате работы xen-drbd-install создаётся сценарий командного интерпретатора, который выполняет такие действия:
- Подготовка LVM томов;
- Настройка DRBD-устройств;
- Наполнение файловых систем доменов.
Полученный сценарий может быть доработан вручную, а может использоваться непосредственном в том виде, как его сгенерирует 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:
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",
}
[править] Использование
При старте узлов на каждом из них запускаются домены, закреплённые в переменной domain_home.
Ручной запуск машин.
Запуск машины:
%# xen-drbd start dns
Запуск всех машин:
%# xen-drbd start-all
Запуск машин, закреплённых за этим хостом (см. domain_home):
%# xen-drbd start-my-domains
Миграция машин.
Миграция машины dns на другой узел:
%# xen-drbd migrate-out dns
Миграция всех машин на второй узел:
%# xen-drbd migrate-out-all
Миграция обратно машин, закреплённых за этим хостом (см. domain_home):
%# xen-drbd migrate-my-domains-home
При выключении узла, домены можно смигрировать на другой узел:
%# xen-drbd migrate-out-all
Или, если такое действие указано в /etc/default/xen:
%# /etc/init.d/xen-drbd stop
Это действие вызывается автоматически при останове узла.
Подробнее об этих и других командах: xen-drbd
[править] Отдельные вопросы эксплуатации xen-drbd
[править] Создание новых устройств DRBD
При синхронизации множества отдельных томов с помощью DRBD нужно обратить внимание на следующее:
- Количество синхронизируемых устройств DRBD ограничено (<=255);
- Для синхронизации отдельных устройств DRBD используются отдельные TCP-порты. При добавлении нового DRBD-устройства обратите внимание на то, что бы порт, который вы назначаете ему для синхронизации, уже не был занят.
- Используйте внешние метадиски, поскольку в случае когда метадиск является внутренним, поведение DRBD при изменении размера логического тома может оказаться неожиданным.
[править] Множество DRBD-устройств
Количество синхронизируемых устройств DRBD ограничено. Максимальное количество используемых одновременно DRBD-устройств задаётся в качестве параметра minor_count модуля ядра drbd при его загрузке. Этот параметр не может превышать 255.
$ sudo modinfo drbd filename: /lib/modules/2.6.18-4-xen-686/kernel/drivers/block/drbd.ko author: Philipp Reisner <phil@linbit.com>, Lars Ellenberg <lars@linbit.com> description: drbd - Distributed Replicated Block Device v8.0.1 license: GPL alias: block-major-147-* vermagic: 2.6.18-4-xen-686 SMP mod_unload 686 REGPARM gcc-4.1 depends: cn parm: trace_devs:int parm: trace_type:int parm: trace_level:int parm: fault_count:int parm: fault_rate:int parm: enable_faults:int parm: allow_oos:DONT USE! (bool) parm: minor_count:Maximum number of drbd devices (1-255) (int)
[править] Сетевые порты DRBD
Для синхронизации отдельных устройств DRBD используются отдельные TCP-порты. При добавлении нового DRBD-устройства обратите внимание на то, что бы порт, который вы назначаете ему для синхронизации, уже не был занят.
Кроме того, нужно обратить внимание на то, чтобы доступ к этим портам для парного узла не был ограничен брандмауэром.
В примере конфигурационного файла drbd.conf, приведённом ниже, есть строка:
address 192.168.1.190:7792;
она показывает, что синхронизация ресурса выполняется с узлом 192.168.1.190 и для синхронизации используется порт 7792.
[править] Метадиск
Лучше не использовать внутренний метадиск (meta-disk internal), особенно если вы собираетесь менять размеры соответствующих томов и файловых систем на них.
Нужно создать отдельный том для- meta-disk'ов DRBD и задать его размер равным 128MB x количество устройств.
В пример конфигурационного файла drbd.conf, приведённом ниже,
meta-disk /dev/XEN/meta[1];
Она говорит о том, что мета-информация об DRBD-устройстве, к которому относится эта строка, должна находится в мета-диске 1 (нумерация с нуля) на томе /dev/XEN/meta. Подготовка этого тома не выполняется каким-то особенным образом — в данном случае это обычный логический том LVM, но вообще это может быть любое блочное устройство достаточного объёма.
Если метадиск создаётся на отдельном логическом томе LVM, то его можно расширять. Расширять метадиск нужно в том случае, когда количество DRBD-устройств, использующих его, превышает допустимое. Это число можно найти, разделив размер метадиска на объём, необходимый для каждого DRBD-устройства (в настоящий момент 128MB).
[править] Пример секции файла drbd.conf
resource dns {
protocol C;
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;
}
syncer {
rate 5M;
}
on dom0
{
device /dev/drbd1;
disk /dev/XEN/dns;
address 192.168.1.190:7792;
meta-disk /dev/XEN/meta[1];
}
on dom0m
{
device /dev/drbd1;
disk /dev/XEN/dns;
address 192.168.1.191:7792;
meta-disk /dev/XEN/meta[1];
}
}
[править] Расширение диска DRBD
DRBD-устройство может менять свои размеры. Это возможно в том случае, если меняют размер (как правило, расширяются) устройства на которых базируется DRBD. Когда DRBD работает поверх логических томов LVM, желание расширение DRBD-устройства выглядит весьма естественно, поскольку изменение размеров LVM-томов является вполне простой и часто использующейся операцией; хочется, чтобы то, что работает поверх логического тома LVM, могло отреагировать на изменение размеров.
Расширение DRBD-устройства и файловой системы, находящейся на нём, состоит из следующих шагов:
- Расширение логического тома, на котором базируется DRBD-устройство на обоих узлах;
- Отражение изменений в метадиске;
- Перезагрузка домена Xen, использующего это устройство;
- Расширение файловой системы на primary-устройстве;
- Проверка правильности выполнения.
Например, пусть:
- хост называются primary и secondary;
- с помощью DRBD синхронизируется логический том /dev/TURBO/lv0;
- размер тома увеличивается на 2G;
- на томе создана файловая система ext2/ext3;
Все указанные параметры являются необязательными и приведены для удобства повествования.
1) Измените размер тома на обоих машинах.
primary# lvresize -L +2048M /dev/TURBO/lv0 secondary# lvresize -L +2048M /dev/TURBO/lv0
2) Вызовите команду перестроения размера DRBD-устройства на обоих машинах:
primary# drbdadm resize all #(вместо all может быть указан только интересующий диск) secondary# drbdadm resize all
3)
3.1) Если домен не запущен. На primary-устройстве измените размер файловой системы,
расположенной на DRBD-устройстве:
primary# ext2resize /dev/drbd0 # (или другое устройство)
3.2) Если домен, использующий устройство, запущен. Перезагрузите домен, для того чтобы он увидел изменения в размере. После этого выполните ext2resize внутри домена.
|
|
Указать домену Xen, использующему DRBD-устройство, что оно изменило размер, в настоящий момент, к сожалению, невозможно. В будущем, сообщить об изменении конфигурации дискового устройства домена будет можно, предположительно, с помощью команды xm block-configure. |
4) Проверьте, что изменение размера прошло успешно.
primary# df -h /dev/drbd0
Проверка с помощью df возможна только в том случае, если /dev/drbd0 смонтировано в настоящий момент.
Если расширение происходит внутри домена, то проверять наличие свободного места нужно тоже внутри домена.
Размер несмонтированной файловой системы можно тоже посмотреть, но только не в байтах, а в блоках. Для файловых систем ext2/ext3:
%# dumpe2fs /dev/drbd0 | grep ^Block dumpe2fs 1.40-WIP (14-Nov-2006) Block count: 979933 Block size: 1024 Blocks per group: 8192
[править] Выключение после синхронизации
Пара DRBD-устройств может находиться в трёх состояниях:
- Синхронизированном;
- Синхронизирующемся.
- Несинхронизирующемся.
В первом случае на обеих частях DRBD-диска находятся одинаковые данные.
Во втором случае правильные данные находятся на одном узле, и они переписываются на второй узел. При этом со временем пара должна прийти к первому состоянию.
В третьем случае неизвестно где именно находятся правильные данные. Для того чтобы решить это требуется административное вмешательство. После того как выяснилось, на каком из узлов данные верны, начинается синхронизация.
Каждый узел при этом характеризуется двумя параметрами:
- Первичность -- Primary/Secondary;
- Верность данных -- Inconsistent/Up-to-date.
Первый параметр говорит о том, могут ли записываться данные на этот узел (primary), или он получает данные со второго узла (secondary).
Второй параметр говорит о том, находятся ли на этом диске актуальные данные, или их нужно обновить.
Важно то, что первый параметр не определяет второй и наоборот. Диск может находиться в состоянии secondary и при этом хранить актуальные данные, и наоборот.
В случае когда диск находится в состоянии primary, но при этом состоянии inconsistent, обязательно должно существовать состояние между двумя устройствами. При обращении к Primary-диску DRBD заботится о том чтобы узнать на второй половине актуальные данные и предоставить их. Снаружи это выглядит абсолютно прозрачно. Пользователь работает с DRBD-устройством, не ведая при этом, что данные сейчас синхронизируются между дисками (причём, возможно даже, копируются на тот узел, где DRBD-диск находится в состоянии primary).
Пока оба узла работают, всё в порядке. Проблема возникает, если есть узел находящийся в состоянии secondary/up-to-date, и он выключается.
Необходимо предусмотреть такую возможность, чтобы миграция доменов xen-drbd при выключении производилась только когда синхронизация завершена.
Рекомендуется для этого ввести действия xen-drbd:
- migrate-out-after-sync domain
- migrate-out-after-sync-all
Миграция домена в этом случае будет выполняться только после того, как все используемые им устройства полностью синхронизированы. До этого момента команда будет находиться в состоянии ожидания.
Если использовать действие migrate-out-after-sync-all при выключении узла, узел завершит свою работу, только после того как все диски, использующиеся в его доменах, завершат синхронизацию, а домены отмигрируют.
[править] Взаимный контроль узлов с помощью heartbeat
Кластер функционален уже — без настройки и использования heartbeat, однако функциональность его частична: при выходе из строя одного из узлов кластера, доступными останутся только те домены, которые исполнялись на нём в момент выхода из строя второго узла. Оставшиеся домены можно будет поднять, но только вручную. Нужно же, чтобы каждый из узлов имел возможность определить, что его напарник пропал и запустить все недостающие домены. При этом особенно важно избежать случая, когда каждый узел ошибочно решит, что его напарник выключился, в то время как оба они будут работать, но по какой-то причине перестанут видеть друг друга. В этом случае может наступить опасная ситуация, касающаяся взаимной противоречивости данных на DRBD-устройствах, и названная split-brain.
[править] Благодарности
- Олександру Юдіну и Олегу Дорохину — за помощь при разработке и тестировании и ценные идеи
[править] См. также
 |
|
|---|
