Инструменты пользователя
Это старая версия документа!
Кластер виртуальных машин XEN
Введение
Задача: организовать двухузловый кластер виртуальных машин с распределением нагрузки. Т.е. допустим есть у нас две виртуальные машины с 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
После установки у нас в загрузчике появится вариант загрузки 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
<note important>disable_sendpage параметр доступен начиная с версии 8.3.2</note>
После перезагрузки модуль должен быть загружен:
# 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;
}
}
Эти конфиги полностью одинаковый для обоих узлов.
<note>В данном случае используем single-primary режим, это значит, что мастером может быть только один узел в определенный момент времени. Кластер будет сам повышать уровень ресурса на нужном узле, не забудьте убрать из автозагрузки скрипт /etc/init.d/drbd Также, в связи с режимом single-primary, не будет доступна живая миграция для виртуальных машин, но об этом позже.</note>
Инициализируем ресурсы:
# 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-----
<note tip> Можно обойтись без синхронизации, если диски пустые или имеют одинаковый набор данных:
# drbdadm -- --clear-bitmap new-current-uuid Win2012
После выполнения этой команды ресурс на обоих узлах сразу перейдет в состояние UpToDate без синхронизации. </note>
Инструменты страницы
