Задача: организовать двухузловый кластер виртуальных машин с распределением нагрузки. Т.е. допустим есть у нас две виртуальные машины с 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, в него будем подключать наших гостей, на нем же висит локальный адрес узла для взаимодействия внутри локальной сети.

В 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>

Теперь на любом из узлов(на том, на котором ресурсы находятся в состоянии 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'

Редактируем /etc/corosync/corosync.conf, параметры по-умолчанию вполне приемлемы, редактируем только секцию interface:

interface {
        ringnumber: 0

        # Тут указывается адрес сети, а не IP-адрес! (сеть, через которую будет взаимодействовать кластер)
        bindnetaddr: 192.168.1.0

        # Широковещательный адрес
        mcastaddr: 226.94.1.1
        mcastport: 5405
}

<note>В данном мануале, для простоты настройки, используется конфигурация без авторизации узлов кластера(secauth: off), в боевых условиях такое можно использовать только если канал связи, использующийся для взаимодействия узлов доступен только им, но не публичной локальной сети.</note>

Ну и теперь в /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 ]

Заключительный этап. К текущему моменту у нас должны быть две рабочие виртуалки, работающие поверх 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-подключений используется 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 и на обоих узлах DRBD-ресурс перешел в состояние StandAlone(если оба узла обнаружили split brain) или один в StandAlone, а другой в WConnection (когда один узел обнаружил split brain). План действий такой:

1. Останавливаем все ресурсы pacemaker(командой crm resource stop [res]), которые связаны с проблемным DRBD-ресурсом(как правило XEN виртуалки и сам DRBD-ресурс)
2. На обоих узлах DRBD-ресурсы должны деактивироваться, активируем их вручную(drbdadm up [res])
3. Переводим на обоих узлах ресурс в автономный режим(drbdadm disconnect [res])
4. Переводим на обоих узлах ресурс в secondary режим (drbdadm secondary [res])
5. Выбираем один из узлов в качестве жертвы, т.е. его изменения будут перезаписаны(для версии 8.4: drbdadm connect –discard-my-data [res] для версии 8.3: drbdadm – –discard-my-data connect [res])
6. Второй узел(источник репликации) переводим в режим подключения(drbdadm connect [res])
7. Дожидаемся завершения синхронизации
8. Деактивируем ресурс на обоих узлах(drbdadm down [res])
9. Теперь можно запустить все ресурсы pacemaker в нужном порядке(crm resource start [res])

• Xen Cluster with Debian GNU/Linux, DRBD, Corosync and Pacemaker
• Configuring Heartbeat v1 Was So Simple
• Настройка Active/Passive PostgreSQL Cluster с использованием Pacemaker, Corosync, и DRBD
• Pacemaker: fix timeout warnings