| Предыдущая версия справа и слева
Предыдущая версия
Следующая версия
|
Предыдущая версия
|
xen_pacemaker_cluster [2013/06/11 17:04]
metallic [Pacemaker] |
xen_pacemaker_cluster [2022/03/25 17:00] (текущий)
|
| ====== Кластер виртуальных машин XEN ====== | ====== Кластер виртуальных машин с XEN, DRBD и Pacemaker ====== |
| ===== Введение ===== | ===== Введение ===== |
| Задача: организовать двухузловый кластер виртуальных машин с распределением нагрузки. Т.е. допустим есть у нас две виртуальные машины с Windows 2012 Server на борту(Win2012 и Win2012-2), в штатном режиме Win2012 должна работать первом узле, а Win2012-2 на втором узле. В случае сбоя одного из узлов кластера, либо выполнении запланированных сервисных работ, второй узел должен забирать все роли проблемного узла себе. Понятное дело, аппаратные возможности обоих узлов должны позволять выполнять все роли одновременно в один момент времени, т.к. если это не так, кластера не получится. | Задача: организовать двухузловый кластер виртуальных машин с распределением нагрузки. Т.е. допустим есть у нас две виртуальные машины с Windows 2012 Server на борту(Win2012 и Win2012-2), в штатном режиме Win2012 должна работать первом узле, а Win2012-2 на втором узле. В случае сбоя одного из узлов кластера, либо выполнении запланированных сервисных работ, второй узел должен забирать все роли проблемного узла себе. Понятное дело, аппаратные возможности обоих узлов должны позволять выполнять все роли одновременно в один момент времени, т.к. если это не так, кластера не получится. |
| |
| ===== Подготовка системы ===== | ===== Подготовка системы ===== |
| Устанавливаем ядро XEN с утилитами, модуль DRBD и утилиты для управления сетевыми мостами: | Устанавливаем ядро XEN с утилитами, модуль DRBD, утилиты для управления сетевыми мостами и систему кластеризации: |
| |
| # apt-get install xen-linux-system-amd64 xen-tools bridge-utils drbd8-utils | # apt-get install xen-linux-system-amd64 xen-tools bridge-utils drbd8-utils pacemaker |
| | |
| После установки у нас в загрузчике появится вариант загрузки XEN Dom0, на нужно сделать, чтобы он грузился по-умолчанию: | После установки у нас в загрузчике появится вариант загрузки XEN Dom0, на нужно сделать, чтобы он грузился по-умолчанию: |
| # crm configure property no-quorum-policy=ignore | # crm configure property no-quorum-policy=ignore |
| |
| Меняем липкость ресурсов по-умолчанию с 0 на -1000, это значит, что ресурсы не очень-то будут держаться за тот узел, на котором сейчас они выполняются, а будут стремится вернуться на свое желаемое место дислакации, если это возможно(в случаях, когда они отттуда переезали из-за сбоя узла или из-за административных задач). | Меняем липкость ресурсов по-умолчанию с 0 на -1000, это значит, что ресурсы не очень-то будут держаться за тот узел, на котором сейчас они выполняются, а будут стремится вернуться на свое желаемое место дислакации, если это возможно(в случаях, когда они оттуда переехали из-за сбоя узла или из-за выполнения административных задач). |
| |
| # crm configure property default-resource-stickiness="-1000" | # crm configure property default-resource-stickiness="-1000" |
| Таким образом, мы получаем конфигурацию в которой есть два узла кластера и по одной виртуальной машине на каждом(реально может быть по десятку или больше на каждом). В случае недоступности одного из узлов по каким-либо причинам, все его виртуалки переездают на живой узел. После его восстановления, его виртуалки возращаются. Это не всегда может быть приемлемо, особенно в рабочее время, поэтому в зависимости от ситуации, можно, либо повысить липкость ресурсов, чтобы они не возвращались на свои любимые места дислакации, либо настроить правила, по которым липкость ресурсов будет регулироваться в зависимости от времени суток. | Таким образом, мы получаем конфигурацию в которой есть два узла кластера и по одной виртуальной машине на каждом(реально может быть по десятку или больше на каждом). В случае недоступности одного из узлов по каким-либо причинам, все его виртуалки переездают на живой узел. После его восстановления, его виртуалки возращаются. Это не всегда может быть приемлемо, особенно в рабочее время, поэтому в зависимости от ситуации, можно, либо повысить липкость ресурсов, чтобы они не возвращались на свои любимые места дислакации, либо настроить правила, по которым липкость ресурсов будет регулироваться в зависимости от времени суток. |
| |
| | ===== Дополнительная информация ===== |
| | ==== 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]) |
| | |
| | ==== Полезные ссылки ==== |
| | * [[http://publications.jbfavre.org/virtualisation/cluster-xen-corosync-pacemaker-drbd-ocfs2.en|Xen Cluster with Debian GNU/Linux, DRBD, Corosync and Pacemaker]] |
| | * [[http://theclusterguy.clusterlabs.org/post/178680309/configuring-heartbeat-v1-was-so-simple|Configuring Heartbeat v1 Was So Simple]] |
| | * [[http://habrahabr.ru/post/108833/|Настройка Active/Passive PostgreSQL Cluster с использованием Pacemaker, Corosync, и DRBD]] |
| | * [[http://zeldor.biz/2011/03/pacemaker-fix-timeout-warnings/|Pacemaker: fix timeout warnings]] |
