Содержание
Кластер виртуальных машин с XEN, DRBD и Pacemaker
Введение
Задача: организовать двухузловый кластер виртуальных машин с распределением нагрузки. Т.е. допустим есть у нас две виртуальные машины с Windows 2012 Server на борту(Win2012 и Win2012-2), в штатном режиме Win2012 должна работать первом узле, а Win2012-2 на втором узле. В случае сбоя одного из узлов кластера, либо выполнении запланированных сервисных работ, второй узел должен забирать все роли проблемного узла себе. Понятное дело, аппаратные возможности обоих узлов должны позволять выполнять все роли одновременно в один момент времени, т.к. если это не так, кластера не получится.
В качестве системы виртуализации используется XEN, в качестве Dom0 - GNU/Debian 7.0. Общее хранилище - DRBD, система кластеризации - pacemaker. Все действия выполняются на обоих узлах, если это не так - указывается явно на каком узле это необходимо выполнить.
Подготовка системы
Устанавливаем ядро XEN с утилитами, модуль DRBD, утилиты для управления сетевыми мостами и систему кластеризации:
# apt-get install xen-linux-system-amd64 xen-tools bridge-utils drbd8-utils pacemaker
После установки у нас в загрузчике появится вариант загрузки XEN Dom0, на нужно сделать, чтобы он грузился по-умолчанию:
# mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen # update-grub
Перезагружаемя, теперь мы в Dom0, проверить это можно так:
# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 3996 2 r----- 578.7
Если команда выполнилась без ошибки - значит все нормально.
Дальше настроим сетевой мост. Предполагается, что гостевые системы будут работать в локальной сети, поэтому в сетевой мост включаем интерфейс, который смотрит в локальную сеть, в моем случае eth0. Правим конфиг /etc/network/interfaces
allow-hotplug eth0
iface eth0 inet manual
pre-up ifconfig $IFACE up
pre-down ifconfig $IFACE down
auto br0
iface br0 inet static
bridge_ports eth0
address 192.168.1.1
netmask 255.255.255.0
После перезагрузки у нас должен появится сетевой мост br0, в него будем подключать наших гостей, на нем же висит локальный адрес узла для взаимодействия внутри локальной сети.
Настройка DRBD
В Debian модуль ядра уже есть, нужно сделать, чтобы модуль грузился автоматически, также при использовании DRBD совместно с ядром XEN рекомендуется использовать опцию disable_sendpage. Создаем drbd.conf в каталоге /etc/modprobe.d с таким содержимым:
options drbd disable_sendpage=1
После перезагрузки модуль должен быть загружен:
# lsmod | grep drbd drbd 313707 5
Теперь нужно выделить два любых блочных устройства(диск, raid-массив, lvm volume) для виртуальных машин. В моем случае это будет lvm volume /dev/virtuals/win2012 и /dev/virtuals/win2012-2
Редактируем /etc/drbd.conf, это основной конфигурационный файл, но удобнее его разбить на несколько секций, что и делаем:
include "/etc/drbd.d/global_common.conf"; include "/etc/drbd.d/*.res";
Редактируем общие параметры для всех ресурсов(эти параметры потом можно переопределить для каждого ресурса индивидуально), файл /etc/drbd.d/global_common.conf (почти все по-умолчанию):
global {
# Запрещаем посылать через интернет разработчикам информацию о версии DRBD (для статистики)
usage-count no;
# minor-count dialog-refresh disable-ip-verification
}
common {
# Синхронный протокол синхронизации
protocol C;
handlers {
# The following 3 handlers were disabled due to #576511.
# Please check the DRBD manual and enable them, if they make sense in your setup.
# pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
# pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
# local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
# fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
# split-brain "/usr/lib/drbd/notify-split-brain.sh root";
# out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
# before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
# after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
}
startup {
# wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb
}
options {
# cpu-mask on-no-data-accessible
}
net {
# sndbuf-size rcvbuf-size timeout connect-int ping-int ping-timeout max-buffers
# max-epoch-size ko-count allow-two-primaries cram-hmac-alg shared-secret
# after-sb-0pri after-sb-1pri after-sb-2pri data-integrity-alg no-tcp-cork
}
syncer {
# rate after al-extents use-rle cpu-mask verify-alg csums-alg
# Максимальная скорость синхронизации(МБ/сек)
rate 100M;
}
}
Теперь создаем конфигурационные файлы ресурсов /etc/drbd.d/Win2012.res:
# Имя ресурса
resource Win2012 {
# Эти обработчики событий нужны для корректной работы с pacemaker
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
disk {
# Это тоже для pacemaker
fencing resource-only;
}
syncer {
# Алгоритм проверки целостности данных
verify-alg md5;
}
# Разрешаем автоматический split brain recovery. На первом этапе, если есть узел с нулевыми изменениями,
# выбираем его жертвой. На втором этапе выбираем жертвой вторичный узел. Ну а если так случилось, что
# оба узла стали мастерами и внесли изменения на ресурс(третий уровень), тот тут лучше выполнить split brain recovery
# в ручном режиме, чтобы не затереть случайно нужные данные, поэтому указываем, что нужно отключаться.
net {
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
# DRBD-устройство
device /dev/drbd1;
# Путь к блочному устройству, которое будем синхронизировать
disk /dev/virtuals/Win2012;
# Метаданные будем хранить на самом устройстве
meta-disk internal;
# Далее указываем адреса и порты обоих узлов
on node1 {
address 192.168.1.1:7900;
}
on node2 {
address 192.168.1.2:7900;
}
}
Ну и конфиг второго ресурса, он почти полностью идентичен /etc/drbd.d/Win2012.res-2:
# Имя ресурса
resource Win2012-2 {
# Эти обработчики событий нужны для корректной работы с pacemaker
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
disk {
# Это тоже для pacemaker
fencing resource-only;
}
syncer {
# Алгоритм проверки целостности данных
verify-alg md5;
}
# Разрешаем автоматический split brain recovery. На первом этапе, если есть узел с нулевыми изменениями,
# выбираем его жертвой. На втором этапе выбираем жертвой вторичный узел. Ну а если так случилось, что
# оба узла стали мастерами и внесли изменения на ресурс(третий уровень), тот тут лучше выполнить split brain recovery
# в ручном режиме, чтобы не затереть случайно нужные данные, поэтому указываем, что нужно отключаться.
net {
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
# DRBD-устройство
device /dev/drbd2;
# Путь к блочному устройству, которое будем синхронизировать
disk /dev/virtuals/Win2012-2;
# Метаданные будем хранить на самом устройстве
meta-disk internal;
# Далее указываем адреса и порты обоих узлов
on node1 {
address 192.168.1.1:7800;
}
on node2 {
address 192.168.1.2:7800;
}
}
Эти конфиги полностью одинаковый для обоих узлов.
Инициализируем ресурсы:
# drbdadm create-md Win2012 Writing meta data... initializing activity log NOT initializing bitmap New drbd meta data block successfully created. # drbdadm create-md Win2012-2 Writing meta data... initializing activity log NOT initializing bitmap New drbd meta data block successfully created.
Запускаем ресурсы:
# drbdadm up Win2012 # drbdadm up Win2012-2
Смотрим их состояние(на любом узле):
# cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: 41C52C8CD882E47FB5AF767
1: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:5242684
Сейчас они на обоих узлах в состоянии Secondary и данные имеют статус Inconsistent, т.к. синхронизации еще не было, самое время ее выполнить. На узле, который будет на текущий момент мастером выполняем:
# drbdadm -- --overwrite-data-of-peer primary Win2012 # drbdadm -- --overwrite-data-of-peer primary Win2012-2
Эта команда переведет узел, на котором была выполнена, в режим мастер и начнет синхронизировать данные со слейвом. В зависимости от скорости каналов связи, скорости дисковой подсистемы и размеров ресурса, это может занять некоторое время. Наблюдать за процессом можно также:
# cat /proc/drbd
version: 8.3.11 (api:88/proto:86-96)
srcversion: 41C52C8CD882E47FB5AF767
1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:412672 nr:0 dw:0 dr:417432 al:0 bm:24 lo:3 pe:1 ua:5 ap:0 ep:1 wo:b oos:4831036
[>...................] sync'ed: 7.9% (4716/5116)M
finish: 0:01:10 speed: 68,608 (68,608) K/sec
По окончании синхронизации ресурс должен получить следующий статус:
cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
# drbdadm -- --clear-bitmap new-current-uuid Win2012
После выполнения этой команды ресурс на обоих узлах сразу перейдет в состояние UpToDate без синхронизации.
Установка виртуальных машин XEN
Теперь на любом из узлов(на том, на котором ресурсы находятся в состоянии primary) устанавливаем виртуальные машины с Windows 2012 Server(или с любой другой нужной ОС). Подробно это описывать не буду, в интернете есть полно документации по XEN. Приведу только пример конфигурационного файла для hvm-виртуалки:
kernel = "/usr/lib/xen-4.1/boot/hvmloader" builder='hvm' memory = 2048 name = "Win2012" vcpus=1 acpi=1 apic=1 device_model = '/usr/lib/xen-4.1/bin/qemu-dm' vif = [ 'type=ioemu, bridge=br0' ] disk = [ 'phy:/dev/drbd/by-res/Win2012,ioemu:hda,w', 'file:/home/WindowsServer2012_RU_STD_TRIAL.ISO,hdc:cdrom,r'] # boot on floppy (a), hard disk (c) or CD-ROM (d) boot="cd" usbdevice='tablet' vnc=1 vncunused=0 vnclisten = '127.0.0.1' vncdisplay=0 vncconsole=0 vncpasswd='passw0rd' sdl=0 vncviewer=0 stdvga=0 serial='pty' ne2000 = "0" on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart'
Настройка кластера
Corosync
Редактируем /etc/corosync/corosync.conf, параметры по-умолчанию вполне приемлемы, редактируем только секцию interface:
interface {
ringnumber: 0
# Тут указывается адрес сети, а не IP-адрес! (сеть, через которую будет взаимодействовать кластер)
bindnetaddr: 192.168.1.0
# Широковещательный адрес
mcastaddr: 226.94.1.1
mcastport: 5405
}
Ну и теперь в /etc/default/corosync
START=yes
Проверяем чтобы corosync был в автозагрузке и запускаем его
# /etc/init.d/corosync start
Запускам монитор и проверяем, что оба узла запустились корректно и готовы к работе:
# crm_mon -1 ============ Last updated: Tue Jun 11 18:54:10 2013 Last change: Tue Jun 11 16:34:29 2013 via crm_resource on node1 Stack: openais Current DC: node1 - partition with quorum Version: 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff 2 Nodes configured, 2 expected votes 0 Resources configured. ============ Online: [ node2 node1 ]
Pacemaker
Заключительный этап. К текущему моменту у нас должны быть две рабочие виртуалки, работающие поверх DRBD. Теперь нужно на обоих узлах остановить виртуалки и ресурсы DRBD:
# drbdadm down Win2012 # drbdadm down Win2012-2
Также не забываем запретить автозагрузку виртуалок и ресурсов XEN. Ну и, понятное дело, на обоих узлах кластера должно быть все необходимое для запуска обоих виртуалок, т.е. конфиги XEN, образы cdrom и т.д.
Приступаем к настройке кластера, на текущий момент в конфигурации нет ни одного ресурса, есть только два узла и параметры кластера:
# crm configure show
node node1
node node2
property $id="cib-bootstrap-options" \
dc-version="1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff" \
cluster-infrastructure="openais" \
expected-quorum-votes="2"
Выключаем stonith и задаем политику поведения при отсутсвии кворума(Pacemaker, теория):
# crm configure property stonith-enabled=false # crm configure property no-quorum-policy=ignore
Меняем липкость ресурсов по-умолчанию с 0 на -1000, это значит, что ресурсы не очень-то будут держаться за тот узел, на котором сейчас они выполняются, а будут стремится вернуться на свое желаемое место дислакации, если это возможно(в случаях, когда они оттуда переехали из-за сбоя узла или из-за выполнения административных задач).
# crm configure property default-resource-stickiness="-1000"
Создаем ресурсы кластера для управления ресурсами DRBD:
# crm configure crm(live)configure# primitive DRBDWin2012 ocf:linbit:drbd params drbd_resource="Win2012" op monitor interval="20" role="Master" timeout="20" op monitor interval="30" role="Slave" timeout="20" meta target-role="started" crm(live)configure# primitive DRBDWin2012-2 ocf:linbit:drbd params drbd_resource="Win2012-2" op monitor interval="20" role="Master" timeout="20" op monitor interval="30" role="Slave" timeout="20" meta target-role="started" crm(live)configure# ms ms_DRBDWin2012 DRBDWin2012 meta master-max="1" notify="true" master-node-max="1" clone-max="2" clone-node-max="1" interleave="true" crm(live)configure# ms ms_DRBDWin2012-2 DRBDWin2012-2 meta master-max="1" notify="true" master-node-max="1" clone-max="2" clone-node-max="1" interleave="true" crm(live)configure# commit crm(live)configure# quit
Некоторые параметры:
- master-max - максимальное кол-во копий данного мультистейтового ресурса, которое может функционировать в режиме master, в конкретном случае указывается, что всего может быть только один мастер
- master-node-max - максимальное кол-во master-сущностей(копий мультистейтового ресурса), которое может функционировать на одном узле, в конкретном случае указывается, что на одном узле не может работать больше одного мастера
- clone-max - максимальное кол-во копий данного мультистейтового ресурса во всем кластере, т.е. в данном случае, всего может быть две сущности во всем кластере
- clone-node-max - максимальное кол-во копий данного мультистейтового ресурса, которое может выполняться на одном узле, в конкретном случае указывается, что нельзя запускать больше одной сущности на одном узле кластера
В итоге получается, что всего в кластере может быть две сущности одного ресурса, по одной сущности на каждом узле и при этом на одном узле будет мастер, т.е. то что нужно нам для DRBD-ресурса.
Теперь создаем ресурсы виртуалок, указываем зависимости(виртуалок от их DRBD-ресурсов) и порядок запуска:
# crm configure crm(live)configure# primitive XENWin2012 ocf:heartbeat:Xen params xmfile="/etc/xen/virtuals/Win2012.hvm" op monitor interval="10s" meta target-role="started" allow-migrate="false" crm(live)configure# colocation Win2012-on-DRBD inf: XENWin2012 ms_DRBDWin2012:Master crm(live)configure# order Win2012AfterDRBD inf: ms_DRBDWin2012:promote XENWin2012:start crm(live)configure# primitive XENWin2012-2 ocf:heartbeat:Xen params xmfile="/etc/xen/virtuals/Win2012-2.hvm" op monitor interval="10s" meta target-role="started" allow-migrate="false" crm(live)configure# colocation Win2012-on-DRBD-2 inf: XENWin2012-2 ms_DRBDWin2012-2:Master crm(live)configure# order Win2012AfterDRBD-2 inf: ms_DRBDWin2012-2:promote XENWin2012-2:start crm(live)configure# commit crm(live)configure# quit
В зависимостях(colocation) указывается, что виртуальная машина XENWin2012 зависит от мультистейт ресурса ms_DRBDWin2012, но не от любой его части, а требуется именно тот узел, на котором этот ресурс функционирует в режиме Master. В порядке запуска также указывается, что мудьтистейт ресурс надо вначале повысить до master(операция promote), а сам ресурс виртуалки должен быть запущен(start).
К текущему моменту у нас уже должны запуститься виртуалки, но запускаются они где вздумается кластеру, поэтому укажим свои предпочтения. Например мы хотим чтобы в штатном режиме виртуалка XENWin2012 работала на первом узле, а XENWin2012-2 на втором узле.
# crm configure crm(live)configure# location XENWin2012-node1-loc XENWin2012 1000: node1 crm(live)configure# location XENWin2012-node2-loc XENWin2012 -1000: node2 crm(live)configure# location XENWin2012-2-node1-loc XENWin2012-2 -1000: node1 crm(live)configure# location XENWin2012-2-node2-loc XENWin2012-2 1000: node2 crm(live)configure# commit crm(live)configure# quit
Т.е. указываем, что желательно, чтобы XENWin2012 запускалась на первом узле(цифра - насколько желательно) и не желательно, чтобы на втором узле. Аналогично с XENWin2012-2, только наоборот. Вместо цифры можно указать inf и -inf, тогда это будет обозначать не желательно, а обязательно.
Таким образом, мы получаем конфигурацию в которой есть два узла кластера и по одной виртуальной машине на каждом(реально может быть по десятку или больше на каждом). В случае недоступности одного из узлов по каким-либо причинам, все его виртуалки переездают на живой узел. После его восстановления, его виртуалки возращаются. Это не всегда может быть приемлемо, особенно в рабочее время, поэтому в зависимости от ситуации, можно, либо повысить липкость ресурсов, чтобы они не возвращались на свои любимые места дислакации, либо настроить правила, по которым липкость ресурсов будет регулироваться в зависимости от времени суток.
Дополнительная информация
VNC для виртуалок
В мануале выше, в качестве адреса для удаленных VNC-подключений используется 127.0.0.1, что не очень удобно, лучше бы использовать какой-нибудь локальный адрес, доступный в локальной сети, например 192.168.1.3, но проблема в том, что наши виртуалки имеют способность перемещаться между узлами нашего кластера, а это значит, что этот адрес должен быть доступен на обоих узлах. Об этом может позаботится кластер. Ниже пример, в котором созается примитив, который будет управлять IP-адресом и настраиваются зависимости и порядок запуска на примере Win2012:
# crm configure crm(live)configure# primitive Win2012-VNC-IP ocf:heartbeat:IPaddr2 params ip=192.168.1.3 cidr_netmask=16 op monitor interval=30s crm(live)configure# colocation Win2012-on-DRBD inf: Win2012-VNC-IP XENWin2012 ms_DRBDWin2012:Master crm(live)configure# order Win2012AfterDRBD inf: Win2012-VNC-IP ms_DRBDWin2012:promote XENWin2012:start crm(live)configure# commit crm(live)configure# quit
Теперь виртуалка будет перемещаться по кластеру вместе с IP-адресом для VNC-консоли.
Живая миграция
Теоретически(и по идее практически) можно настроить DRBD в режиме dual primary и пользоваться живой миграцией виртуальных машин(кластер это поддерживает). На практике у меня возникли некоторые мелкие проблемы с этим(сбои миграции, обвал из-за этого виртуалок и т.д.), поэтому я отказался от этой идеи, т.к. для меня этот функционал не критичен, а вообще если понадобится - можно добить. Ниже некоторые наброски с минимальными пояснениями(предполагает, что в XEN миграция включена).
Конфиг DRBD-ресурса для живой миграции:
resource Win2012 {
handlers {
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
disk {
fencing resource-only;
}
syncer {
verify-alg md5;
}
net {
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
device /dev/drbd2;
disk /dev/virtuals/win2012;
meta-disk internal;
on node1 {
address 192.168.1.1:7789;
}
on node2 {
address 192.168.1.2:7789;
}
startup {
become-primary-on both;
}
}
Конфигурация кластера:
crm configure primitive DRBDWin2012 ocf:linbit:drbd params drbd_resource="Win2012" op monitor interval="20" role="Master" timeout="20" op monitor interval="30" role="Slave" timeout="20" meta target-role="started" crm configure ms ms_DRBDWin2012 DRBDWin2012 meta master-max="2" notify="true" interleave="true" crm configure primitive XENWin2012 ocf:heartbeat:Xen params xmfile="/etc/xen/virtuals/Win2012.hvm" op monitor interval="10s" meta target-role="started" allow-migrate="true" crm configure colocation Win2012-on-DRBD inf: XENWin2012 ms_DRBDWin2012:Master crm configure order Win2012AfterDRBD inf: ms_DRBDWin2012:promote XENWin2012:start crm configure primitive DRBDWin2012-2 ocf:linbit:drbd params drbd_resource="Win2012-2" op monitor interval="20" role="Master" timeout="20" op monitor interval="30" role="Slave" timeout="20" meta target-role="started" crm configure ms ms_DRBDWin2012-2 DRBDWin2012-2 meta master-max="2" notify="true" interleave="true" crm configure primitive XENWin2012-2 ocf:heartbeat:Xen params xmfile="/etc/xen/virtuals/Win2012-2.hvm" op monitor interval="10s" meta target-role="started" allow-migrate="true" crm configure colocation Win2012-on-DRBD-2 inf: XENWin2012-2 ms_DRBDWin2012-2:Master crm configure order Win2012AfterDRBD-2 inf: ms_DRBDWin2012-2:promote XENWin2012-2:start
Ручное восстановление split brain
Ситуация с возникновением в нормальных условиях достаточно редкая, но все же лучше знать как ее решать до того, как такая ситуация возникнет. Допустим случился split brain и на обоих узлах DRBD-ресурс перешел в состояние StandAlone(если оба узла обнаружили split brain) или один в StandAlone, а другой в WConnection (когда один узел обнаружил split brain). План действий такой:
- Останавливаем все ресурсы pacemaker(командой crm resource stop [res]), которые связаны с проблемным DRBD-ресурсом(как правило XEN виртуалки и сам DRBD-ресурс)
- На обоих узлах DRBD-ресурсы должны деактивироваться, активируем их вручную(drbdadm up [res])
- Переводим на обоих узлах ресурс в автономный режим(drbdadm disconnect [res])
- Переводим на обоих узлах ресурс в secondary режим (drbdadm secondary [res])
- Выбираем один из узлов в качестве жертвы, т.е. его изменения будут перезаписаны(для версии 8.4: drbdadm connect –discard-my-data [res] для версии 8.3: drbdadm – –discard-my-data connect [res])
- Второй узел(источник репликации) переводим в режим подключения(drbdadm connect [res])
- Дожидаемся завершения синхронизации
- Деактивируем ресурс на обоих узлах(drbdadm down [res])
- Теперь можно запустить все ресурсы pacemaker в нужном порядке(crm resource start [res])