| Предыдущая версия справа и слева
Предыдущая версия
Следующая версия
|
Предыдущая версия
|
xen_pacemaker_cluster [2013/06/11 17:39]
metallic [Подготовка системы] |
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 на втором узле. В случае сбоя одного из узлов кластера, либо выполнении запланированных сервисных работ, второй узел должен забирать все роли проблемного узла себе. Понятное дело, аппаратные возможности обоих узлов должны позволять выполнять все роли одновременно в один момент времени, т.к. если это не так, кластера не получится. |
| |
| ===== Дополнительная информация ===== | ===== Дополнительная информация ===== |
| | ==== 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 в режиме dual primary и пользоваться живой миграцией виртуальных машин(кластер это поддерживает). На практике у меня возникли некоторые мелкие проблемы с этим(сбои миграции, обвал из-за этого виртуалок и т.д.), поэтому я отказался от этой идеи, т.к. для меня этот функционал не критичен, а вообще если понадобится - можно добить. Ниже некоторые наброски с минимальными пояснениями(предполагает, что в XEN миграция включена). |
| |
| ==== Ручное восстановление split brain ==== | ==== Ручное восстановление 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]] |
