суббота, 12 мая 2012 г.

Proxmox VE 2 cluster with DRBD (HA, Fencing)


Возникла небольшая задача по созданию бюджетного отказоустойчивого кластера виртуалок. Мучился до 3х ночи, но решил.
И так, задача:
Есть 2 двухголовых сервера, на них нужно развернуть: файерволл и маршрутизатор на 2-х провайдеров, сервер телефонии Asterisk, комплекс 1С:Предприятие (клиент-сервер) и хранилище документов. Нагрузка по итогу не очень большая, можно было бы развернуть по отдельности поделив нагрузку, но есть второе требование: обеспечение резерва и высокой доступности, при полном отсутствии доп.финансирования
Посидев, подумав, было решено все это виртуализировать и кластеризировать.
Изучив предложения быстро понял, что единственным вариантом сделать все это является гипервизор kvm в дистрибутиве Proxmox VE, благо уже вышла версия 2.1 и основные косяки поправлены.
Поводом же написать сообщения явилось то, что полной пошаговой инструкции для развертывания такого кластера с использованием fencing нет в интернете, абзац в одном месте, кусок кода в другом месте, объяснение почему вообще на немецком.



Итак 2 сервера с 2-мя сетевыми картами. Первые из них втыкаем в свитч, вторые соединяем шнурком. Если используются raid, их нужно сконфигурировать по вкусу. Основная задача создать минимум 2 массива - один для самого proxmox, второй под общее хранилище. Параметры общего хранилища должны быть одинаковы.
Подготовка закончена.
Устанавливаем дистрибутив. Установка стандартна - лицензия, далее, ОК, выбрать часовой пояс, указать пароль root, электронную почту, выбрать диск для установки, забить настройки сетевого интерфейса.
Сеть настраивается только на статику (и это правильно для такой задачи) и только для первого интерфейса. Плюс к этому сетевое имя обязательно с указанием домена (fqdn).
Возьмем для примера:
первый узел - node01.loc
ip - 192.168.0.100
mask - 255.255.255.0
gateway - 192.168.0.1
dns - 192.168.0.1

Аналогично второй узел - node02.loc
ip - 192.168.0.200
mask - 255.255.255.0
gateway - 192.168.0.1
dns - 192.168.0.1

Все, на этом установка системы заканчивается, начинается работа.

Перво-наперво синхронизировать время. Если есть в сети сервер точного времени (контроллер домена например) указываем его и синхронизируемся. Если его нет, то вся надежда на pool.ntp.org
На обоих узлах:
echo "server ntp.company.lan" >> /etc/ntp.conf
/etc/init.d/ntp restart
ntpdc -p


# Правим /etc/hosts


для node01 добавляем строчку:
10.10.10.2 node02 node02.loc
для node02
10.10.10.1 node01 node01.loc


# Обновляемся
aptitude update && aptitude full-upgrade


Далее настраиваем сеть на вторых интерфейсах серверов. Это можно сделать как из терминала, так и из веб-интерфейса proxmox ( https://192.168.0.100:8006 для node01 и https://192.168.0.200:8006 для node02 соответственно). Заходим с логином root  и паролем, указанным при установке, слева выбираем имя ноды, в главном окне вкладку Network, выделяем интерфейс eth1, Edit. Указываем адрес 10.10.10.1, маску 255.255.255.252, ставим галку на Autostart. Для второго узла повторяем процесс с ip 10.10.10.2

Перезагружаемся. Логинимся. Проверяем, что узлы видят друг друга
# на первом узле
ping node02
# на втором
ping node01

Если возникли проблемы, проверяем настройки сети, меняем патчкорд и т.д.

Создаем кластер
На узле node01:
pvecm create cluster01 #cluster01 - имя кластера, поменять потом невозможно!
pvecm status # проверяем, что все хорошо
На узле node02:
pvecm add 10.10.10.1 # добавляем node2 в наш кластер

Кластер создан.

Беремся за drbd (к примеру наше хранилище будет располагаться на /dev/sdb:
На обоих узлах:
fdisk /dev/sdb
n -> p -> 1 -> enter -> enter
t -> 8e
w

Раздел мы создали.
Можно ставить drbd8-utils, но не тут то было. Версия drbd в ядре 8.3.10, а в репозитории drbd8-utils версии 8.2.7, что очень не хорошо. Будем компелять, благо это недолго:
cd ~
apt-get install git-core git-buildpackage fakeroot debconf-utils docbook-xml docbook-xsl dpatch xsltproc autoconf flex
mkdir drbd
cd drbd
git clone http://git.drbd.org/drbd-8.3.git
cd drbd-8.3
git checkout drbd-8.3.10
dpkg-buildpackage -rfakeroot -b -uc
cd ..
dpkg -i drbd8-utils_8.3.10-0_amd64.deb

На один установили. Можно повторить на втором, или перетащить полученный пакет и просто его установить. Решать Вам.
Разбираемся с конфигами drbd:
На обоих:
nano /etc/drbd.d/global_common.conf
Все удаляем и пишем:
global { usage-count no; }
common { syncer { rate 30M; } }


nano /etc/drbd.d/r0.res
resource r0 {
     protocol C;
     startup {
             wfc-timeout 0; # non-zero might be dangerous
             degr-wfc-timeout 60;
             become-primary-on both;
     }
     net {
             cram-hmac-alg sha1;
             shared-secret "oogh2ouch0aitahNBLABLABLA";
             allow-two-primaries;
             after-sb-0pri discard-zero-changes;
             after-sb-1pri discard-secondary;
             after-sb-2pri disconnect;
     }
     on node01 {
             device /dev/drbd0;
             disk /dev/sdb1;
             address 10.10.10.1:7788;
             meta-disk internal;
     }
     on node02 {
             device /dev/drbd0;
             disk /dev/sdb1;
             address 10.10.10.2:7788;
             meta-disk internal;
     }
}

Стартуем на обоих узлах drbd
/etc/init.d/drbd start
drbdadm create-md r0
drbdadm up r0

!!! Только на одном узле (node01):  !!!
drbdadm -- --overwrite-data-of-peer primary r0

watch cat /proc/drbd #наблюдаем пока синхронизируются узлы до Primary/Primary UpToDate/UpToDate

На обоих узлах:
nano /etc/lvm/lvm.conf
# Меняем строчку filter = [ "a/.*/" ] на
filter = [ "r|^/dev/sdb1|", "a|^/dev/sd|", "a|^/dev/drbd|" ,"r/.*/" ]

!!! Только на одном узле (node01):  !!!
pvcreate /dev/drbd0
pvscan # in order to check
vgcreate drbdvg /dev/drbd0 # имя drbdvg можете поставить свое

Далее идем в интерфейс proxmox
Data Center > Storage > Add > LVM group
ID: drbd
Volume group: drbdvg
Shared: yes

ID выбираете сами, поменять невозможно.

Уже можно создавать виртуальные машинки (обязательно в закладке hdd укажите storage: drbdvg).

Можно запускать и наслаждаться миграцией.

Если Вам этого достаточно, дальше можно не читать.
Но мне необходим был HA, поэтому мучения продолжаются.

Создаем конфиг кластера (node01):
cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new

я привел его к такому виду:

cat /etc/pve/cluster.conf
<?xml version="1.0"?>
<cluster config_version="10" name="cluster">
  <cman expected_votes="1" keyfile="/var/lib/pve-cluster/corosync.authkey" two_node="1"/>
  <fencedevices>
    <fencedevice agent="fence_manual" name="human"/>
  </fencedevices>
  <clusternodes>
    <clusternode name="node01" nodeid="1" votes="1">
      <fence>
        <method name="single">
          <device name="human" nodename="node01"/>
        </method>
      </fence>
    </clusternode>
    <clusternode name="node02" nodeid="2" votes="1">
      <fence>
        <method name="single">
          <device name="human" nodename="node02"/>
        </method>
      </fence>
    </clusternode>
  </clusternodes>
</cluster>


# config_version="10" обязательно увеличиваем каждый раз, когда меняем содержимое

Что мы здесь видим:
Устройство fence - ручной переключатель (возможны другие варианты, от упса до коммутатора).
Fence - в общем это такой механизм, который гарантированно вырубит отвалившийся узел, чтобы не допустить возможности их параллельной работы (что в случае drbd однозначно приведет к поломке синхронизации дисков и ручного разгребания каши на них).
В этом примере гарантом изоляции является человек, что тоже не очень, но оставим это на будущее.

Идем в интерфейс и применяем настройки кластера: Datacenter -> HA -> Activate

Правим, удалив комментарий в последней строчке на обоих узлах:
nano /etc/default/redhat-cluster-pve
выполним на обоих узлах:
fence_tool join
Наш домен fence готов.

Если есть вирт.машинка подключаем ее к HA кнопкой add (указываем id машинки). Если нет, создаем и подключаем.
Почти все. Идем в сервер(node01) -> Services запускаем службу RGManager. Должна запуститься наша машинка. Повторяем запуск RGManager на node02.
Все. Можем гасить node01 машинка переберется на node02.

!!! Обязательно !!!
Если у вас к vm подключен инсталяционный cd, или подключена консоль, отключитесь, иначе кина не будет.

P.S.
Для ручного fencin-га:
Запускаем vn на node01
Гасим node01
Идем на node02
Говорим, что 100% уверены, что узел 1 не работает: fence_ack_manual node01
Говорим, что на 1000500% уверены введя "absolutely"
машинка заведется на node02

Материал собрал из:
http://www.helplinux.ru/wiki/en:kb:proxmox-drbd-cluster
http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
http://forum.proxmox.com/threads/7059-Update-DRBD-userland-to-8.3.10-to-match-kernel-in-1.9?p=40033#poststop
http://forum.proxmox.com/threads/8623-Proxmox-2-node-cluster-fencing-device
http://pve.proxmox.com/wiki/Fencing#Enable_fencing_on_all_nodes

39 комментариев:

  1. спасибо за статью. очень своевременно. как раз сейчас занимаюсь изучением систем виртуализации и в частности proxmox v2. поднял систему с двумя нодами и общим хранилищем на openfiler. повертел кластер, захотелось HA. построил систему по вашей статье и wiki, но в результате возникло несколько вопросов. и главный из них, при внезапном аварийном выходе из строя одной ноды (не shutdown, а просто отключение питания) поднимется ли на второй виртуальная машина, которая ранее крутилась на умершей ноде? у меня так не получилось.

    ОтветитьУдалить
  2. и в вдогонку по постскриптуму. после шага "гасим ноду1" по идее ВМ автоматически перейдёт на ноду2. зачем тогда давать команду fence_ack_manual node01?

    ОтветитьУдалить
    Ответы
    1. Если мы в HA используем Fencing по устройству human, автоматической миграции виртуальных машин не будет, пока мы сам, вручную, не укажем, что пострадавшая машина надежно изолирована. Можно это делать автоматически, если есть железо поддерживаемое fencing-агентами, или использовать скрипты, которые проверят изоляцию машины и исключат ее.

      Удалить
    2. то есть если я правильно понимаю, при наличии аппаратного fencing-а, если один из серверов выйдет из строя (сгорит БП, сдохнет матплата и т.д.), на второй ноде все ВМ автоматически поднимутся? для меня это важно, т.к. пока верчу всю систему на паре простых системников и надо хорошо с этим разобраться прежде чем заказывать сервера.

      Удалить
    3. Можете привести пример баш скрипта, для переключения между машинами.

      Удалить
    4. Пример то могу, но вот что вы хотите получить в итоге не могу понять. Уточните пожалуйста что должен делать скрипт.

      Удалить
  3. вопрос снят. немного подумал и понял, что неправильно моделировал аварийный отказ ноды. в результате просто выдернул шнурок из ноды1, на второй ноде дал команду fence_ack_manual и на ней поднялась тестовая ВМ.

    ОтветитьУдалить
    Ответы
    1. Это просто замечательно, что есть возможность самому подумать и найти причину. Уважаю )

      Удалить
  4. алаверды, Антон =) если бы не эта нагугленная запись в блоге, я бы забросил изучение темы HA кластер в proxmox, т.к. в официальном wiki нет упоминания о таком fencing девайсе как human (manual fencing). а без него при отсутствии серверных карт или apc свича нет возможности даже потестить эту технологию. так что как говорится thanks for sharing. тем более, что доков очень мало, а технология перспективная. успехов!

    ОтветитьУдалить
  5. Юзал fence_manual, только у меня 3 ноды бло, запустил виртуальну машину на 1 ноде, потом зашел на нее и сделал init 0, автоматом перепрыгнула вируальная машина на вторую ноду, почему мне не потребовалось сделать fence_ack_manual node01 ????

    И еще знаю что в Редхате юзают iscsi как fence device , есть пример как тут так же изспользовать можно ? маленький примет можете дать ?

    ОтветитьУдалить
    Ответы
    1. iscsi есть такой агент. Пример не дам, проверить в данный момент не на чем.
      У меня тоже было так с fence manual, но при тестировании на виртуалках. В продакшене ведет себя как положено, только после ручного указания. Возможно есть разница в настройках fencing, но проверить не могу, снес виртуалки. На живом точно не буду тестить)

      Удалить
    2. Возможно смогу дать примеры на след. неделе. Буду запускать новый кластер, будет время поиграться.

      Удалить
  6. Отличная статейка. Как раз мучаюсь с нодами, то одна ошибка вываливается, то другая! Оочень своевременно статейка! Особенно на русском!

    ОтветитьУдалить
  7. Маленький вопросик все же меня беспокоит... без lvm можно ли обойтись? у меня мультипач сторадж и хотелось бы не только машинки на qemu переносить, но и образа openvz. Т.Е. делаю огромный каталог, в котором располагаются соответствующие папки для бекапов, образов и т.д. Он будет фенситься?
    Из-за того что openvz контейнеры потребляют мало ресурсов хотелось бы и для них перенос с ноды на ноду оформить.

    ОтветитьУдалить
    Ответы
    1. На вики proxmox есть статья, в которой рассказано, как немного допилить OpenVZ для работы с HA (там на самом деле не так все плохо).
      Ссылка для начала:
      http://www.nedproductions.biz/wiki/configuring-a-proxmox-ve-2.x-cluster-running-over-an-openvpn-intranet/configuring-a-proxmox-ve-2.x-cluster-running-over-an-openvpn-intranet-part-3#----making-the-replicated-storage-available-for-openvz-as-well

      Удалить
  8. Люди, для тех у кого ручной вариант не получается, можно подсмотреть в сторону создания drbd0 у программулинки http://lcmc.sourceforge.net/

    После 2 недель ручных мучений стал искать ошибки, после сравнения файлов отпишусь.

    ОтветитьУдалить
  9. Спасибо за отличную статью. Один вопрос,если можно: с кворум диском не заморачивались? Без него нормально работает?

    ОтветитьУдалить
  10. Отличная работа, большое спасибо. Proxmox сам неплохо гоняет под серверами виртуальных машин. Подниму как нить две штуки у себя на домашнем и попробую объединить их.

    ОтветитьУдалить
    Ответы
    1. У меня сейчас в эксплуатации есть такой кластер на drbd, все замечательно работает и выдержало уже внеплановые отключения без простоя. Поднялся сам и работает. Пойду дерево поищу что-ли.

      Удалить
  11. Доброй ночи! Есть маленький вопросик. Создал ВМ поклал диск на ДРБД, на первой ноде стопаю RGmanager виртуалка прекрасно переносится на вторую ноду, но не может нормально стартануть потому что у нее нет диска
    http://screencast.com/t/qqm2wCx0Zn26

    ОтветитьУдалить
    Ответы
    1. Добро. Могу только предположить, что вы, при создании хранилища в pve, не поставили галочку shared.

      Удалить
    2. Все нормально, даже пересоздал лвм, но на другую ноду вируталка переходит без винта (((

      http://screencast.com/t/0NhnJdkcgCI

      Удалить
  12. А вместе с DRBD нужно поднимать кворум? можно посмотреть ваш cluster.conf ?

    ОтветитьУдалить
  13. Поднимаю proxmox только без DRBD а с внешним хранилищем, проблема при миграции

    Executing HA migrate for VM 100 to node node2
    Trying to migrate pvevm:100 to node2...Target node dead / nonexistent
    TASK ERROR: command 'clusvcadm -M pvevm:100 -m node2' failed: exit code 244

    Помогите разобраться

    ОтветитьУдалить
    Ответы
    1. Из того, что вижу node2 не в кластере. Может на ней остановлена кластерная служба? Проблемы с сетью? Слишком мало информации.

      Удалить
  14. Антон, здравствуйте! Если ситуация будет следущая...одна нода умерла окончательно, кластер с одной нодой работает, виртуалки перенеслись, как поднимать новую ноду в кластере? ведь drbd развалиться, какие действия нужно провести в новой ноде для присоединения к кластеру? чтобы и кластер восстановился и drbd на новой ноде

    ОтветитьУдалить
    Ответы
    1. Вначале переведите все ресурсы drbd в режим мастера, удалите записи о рухнувших ресурсах. потом на новой ноде создайте такие-же разделы и настройте drbd, синкните drbd. Потом занимаемся удалением старой ноды из кластера proxmox, добавляем новую ноду. сторадж появится сам. распределяем виртуалки.

      Удалить
    2. Спасибо за статью! Если три нода то тогда fence manual работает автоматом?

      Удалить
  15. Спасибо за статью! Настраиваю как написано, шаг за шагом, но на этапе drbdadm -- --overwrite-data-of-peer primary r0 вылетает в ошибку r0: State change failed: (-2) Need access to UpToDate data
    Command 'drbdsetup primary r0' terminated with exit code 17
    и ещё, в выводе /etc/init.d/drbd status как то странно Started DRBD -- please disable. Unless you are NOT using a cluster manager..
    а в journalctl -xn вылетает Mar 14 11:52:00 B2B-HA-1 kernel: drbd r0: State change failed: Need access to UpToDate data
    Mar 14 11:52:00 B2B-HA-1 kernel: drbd r0: Failed: role( Secondary -> Primary )

    Подскажите, в чем проблемма может быть!?

    ОтветитьУдалить
    Ответы
    1. Проверьте, чтоб время было синхронизировано на обеих машинах

      Удалить
    2. секунда в секунду, синхронизированы на одном NTP

      Удалить
    3. в этом не может быть проблемы!?
      root@B2B-HA-1:~# cat /proc/drbd
      version: 9.0.6-1 (api:2/proto:86-112)
      GIT-hash: 08cda190c4f544a0c4e15ba792bbf47c69707b42 build by root@nora, 2017-03-09 12:25:26
      Transports (api:15): tcp (1.0.0)
      root@B2B-HA-1:~# drbdadm -V
      DRBDADM_BUILDTAG=GIT-hash:\ c0fb2d367b8be5e9f53919f88a8c344dc8c61fe9\ debian/changelog\ debian/compat\ debian/control\ debian/control.ubuntu-precise\ debian/copyright\ debian/drbd-utils.bash-completion\ debian/drbd-utils.config\ debian/drbd-utils.postrm\ debian/drbd-utils.prerm\ debian/rules\ debian/watch\ build\ by\ root@elsa\,\ 2016-09-07\ 17:49:09
      DRBDADM_API_VERSION=2
      DRBD_KERNEL_VERSION_CODE=0x090006
      DRBDADM_VERSION_CODE=0x080908
      DRBDADM_VERSION=8.9.8

      Удалить
    4. Я подозреваю что вы ставите 4 версию проксмокса? с 2012 многое поменялось, скорее всего и drbd тоже.
      Какая версия у вас стоит?

      Удалить
    5. да, последняя версия PVE
      #1 SMP PVE 4.4.44-84 (Thu, 9 Mar 2017 12:06:34 +0100)

      Удалить
    6. Тогда зря вы drbdadm компиляли. он старее чем в пакете.

      Удалить
    7. Вот тут свежие инструкции по 9 версии drbd
      https://www.drbd.org/doc/users-guide-90/ch-admin-manual#s-first-time-up

      Удалить
    8. на просторах почитал, говорят что в последних версиях PVE в связке с DRBD много глюков. Посоветуйте какую из версий PVE посвежее тогда устанавливать.!?

      Удалить
    9. Огромнейшее человеческое спасибо за своевременный пинок в нужное направление!!! Действительно синтаксис команды другой, а именно drbdadm primary --force r0

      Удалить
  16. Глюков достаточно в любой версии. Я и со второй версией накушался. главное правило быстрый и стабильный линк между машинами по выделенному интерфейсу. Тем более что в 9 версии протокол обмена оптимизировали. (посмотрите по ссылке)
    Кластер теперь инициализируется с ключом force (на главной ноде)
    drbdadm primary --force r0

    ОтветитьУдалить