Кластерное хранилище Pacemaker + DRBD (Dual primary) + samba

  • Tutorial
В продолжение статьи «Кластерное хранилище Pacemaker + DRBD (Dual primary) + ctdb» представляю полностью готовый и рабочий вариант HA кластера файловой шары на 2-4 ноды для centos 6 и centos 7. Если вы хотите реализовать такое, вы либо извращенец, либо вам не дали никакого выбора, и реализовать надо хоть как-то.

Я просто опишу слоёный пирог, который мы будем собирать:

На блочном устройстве создаём таблицу gpt => один раздел на всё пространство под лвм => группу томов лвм на всё доступное пространство => лвм том на всё доступное пространство => drbd устройство => dlm => размечаем как физический том лвм на всё доступное пространство => на него кластерную группу томов лвм => лвм том на всё доступное пространство => размечаем фс gfs2 => подключаем в точку монтирования.
И рулить всем этим будет pacemaker c virtual ip адресом.


Если вы ещё хотите продолжать, читайте дальше под катом.

Из исходных нам необходимо следующее:
Процессор 1 ядро
1 Гб минимум оперативной памяти
15 Гб диск + место на котором вы будете хранить данные
Дисков может быть сколько угодно, даже один.

Если у вас один диск, то лучше размечать его следующим образом:
Таблица разделов gpt => раздел 200 Мб для efi (опционально) => раздел 1Гб для /boot => всё остальное место под лвм.

На лвм томе вам необходимо создать 2 группы томов. Первая группа томов под ОС размером 10 Гб + удвоенному размеру оперативной памяти, но не более 4 Гб.

Кто бы, что не говорил, но подкачка иногда очень выручает, поэтому на лвм группе создаём лвм раздел для подкачки равный удвоенному размеру оперативной памяти, но не более 4 Гб и оставшееся место отводим под корень ОС.

Вторая группа лвм под хранение данных. Создаём лвм раздел на всё оставшееся место.

По условиям нам дали 2 виртуальные машины и на этом всё. Ceph для корректной работы лучше ставить на 6 нодах, минимум 4, плюс было бы неплохо иметь какой-нибудь опыт работы с ним, а то получится как у cloudmouse. Gluster для сотен тысяч мелких файлов по производительности не пройдёт, это обмусолено на просторах хабра много раз. ipfs, lustre и тому подобные имеют такие же требования как у ceph или даже больше.

Начнём сражение! У меня было две виртуальные машины на CentOS 7 с 2мя дисками.


1) Pacemaker версии 1.1 не работает с ip корректно, поэтому для надёжности добавляем в /etc/hosts записи:

192.168.0.1 node1
192.168.0.2 node2

2) В стандартных репозиториях DRBD нет, поэтому надо подключить сторонний.

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
yum localinstall -y http://ftp.nluug.nl/os/Linux/distr/elrepo/elrepo/el7/x86_64/RPMS/$(curl -s http://ftp.nluug.nl/os/Linux/distr/elrepo/elrepo/el7/x86_64/RPMS/ | grep -oP ">elrepo-release.*rpm" | cut -c 2-)

3) Устанавливаем drbd версии 8.4

yum install -y kmod-drbd84 drbd84-utils

4) Активируем и включаем в автозагрузку модуль ядра drbd

modprobe drbd
echo drbd > /etc/modules-load.d/drbd.conf

5) Создаём раздел диска и настраиваем лвм

echo -e "g\nn\n\n\n\nt\n8e\nw\n" | fdisk /dev/sdb
vgcreate drbd_vg /dev/sdb1
lvcreate -l +100%FREE --name r0 drbd_vg

6) Создаем конфигурационный файл ресурса drbd /etc/drbd.d/r0.res

resource r0 {
  protocol C;
  device /dev/drbd1;
  meta-disk internal;
  disk /dev/mapper/drbd_vg-r0;
  net {
    allow-two-primaries;
  }
  disk {
    fencing resource-and-stonith;
  }
  handlers {
    fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
    after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
  }
  startup { 
    become-primary-on both;
  }
  on node1 {
    address 192.168.0.1:7788;
  }
  on node2 {
    address 192.168.0.2:7788;
  }

7) Убираем сервис drbd из авозагрузки (позже его за него будет отвечать pacemaker), создаем метаданные для диска drbd, поднимаем ресурс

systemctl disable drbd
drbdadm create-md r0
drbdadm up r0

8) На первой ноде делаем ресурс первичным

drbdadm primary --force r0

9) Ставим pacemaker

yum install -y pacemaker corosync pcs resource-agents fence-agents-all

10) Устанавливаем пароль для пользователя hacluster для авторизации на нодах

echo CHANGEME | passwd --stdin hacluster 

11) Запускаем pcsd на обоих нодах

systemctl enable pcsd
systemctl start pcsd

12) Авторизуемся в кластере. C этого этапа делаем все на одной ноде

pcs cluster auth node1 node2 -u hacluster -p CHANGEME --force 

13) Создаем кластер с именем samba_cluster

pcs cluster setup --force --name samba_cluster node1 node2

14) активируем ноды и добавляем сервисы в автозагрузку и запускаем их

pcs cluster enable --all
pcs cluster start --all
systemctl start corosync pcsd pacemaker
systemctl enable corosync pcsd pacemaker

15) Так как в качестве серверов у нас выступают виртуальные машины, то отключаем механизм STONITH, так как мы не имеем никаких механизмов для управления ими. Так же у нас машин всего 2, поэтому кворум тоже отключаем, он работает только при 3х и более машинах.

pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

16) Создаем VIP

pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=192.168.0.10 cidr_netmask=32 nic=eth0 clusterip_hash=sourceip-sourceport op monitor interval=1s

17) Создаем ресурс drbd

pcs resource create DRBD1 ocf:linbit:drbd drbd_resource=r0 op monitor interval=60s master master-max=2 master-node-max=1 clone-node-max=1 clone-max=2 notify=true op start interval=0s timeout=240 promote interval=0s timeout=130 monitor interval=150s role=Master monitor interval=155s role=Slave

18) Устанавливаем необходимые пакеты для clvm и подготавливаем clvm

yum install -y lvm2-cluster gfs2-utils
/sbin/lvmconf --enable-cluster

19) Добавляем ресурс dlm и clvd в pacemaker

pcs resource create dlm ocf:pacemaker:controld allow_stonith_disabled=true clone meta interleave=true
pcs resource create clvmd ocf:heartbeat:clvm clone meta interleave=true

20) Запрещаем LVM писать кэш и очищаем его. На обоих нодах

sed -i 's/write_cache_state = 1/write_cache_state = 0/' /etc/lvm/lvm.conf
rm /etc/lvm/cache/*


21) Создаем CLVM раздел. Делаем только на одной ноде
vgcreate -A y -c y cl_vg /dev/drbd1
lvcreate -l 100%FREE -n r0 cl_vg

22) Размечаем раздел в gfs2, здесь важно чтобы таблица блокировок имела тоже имя что и наш кластер в peacemaker. Делаем только на одной ноде

mkfs.gfs2 -j 2 -p lock_dlm -t samba_cluster:r0 /dev/cl_vg/r0

23) Дальше добавляем монтирование этого раздела в pacemaker и говорим ему грузиться после clvmd

pcs resource create fs ocf:heartbeat:Filesystem device="/dev/cl_vg/r0" directory="/mnt" fstype="gfs2" clone interleave=true

24) Теперь наcтал черед ctdb, который будет запускать samba

yum install -y samba ctdb cifs-utils

25) Правим конфиг /etc/ctdb/ctdbd.conf

CTDB_RECOVERY_LOCK="/mnt/ctdb/.ctdb.lock"
CTDB_NODES=/etc/ctdb/nodes 
CTDB_MANAGES_SAMBA=yes
CTDB_LOGGING=file:/var/log/ctdb.log
CTDB_DEBUGLEVEL=NOTICE

26) Создаем файл со списком нод /etc/ctdb/nodes
ВНИМАНИЕ! После каждого адреса в списке должен присутствовать перевод строки. Иначе нода не будет включаться при инициализации.

192.168.0.1
192.168.0.2

27) И наконец создаем ресурс ctdb

pcs resource create samba systemd:ctdb clone meta interleave=true

28) Задаем очередь загрузки и зависимости ресурсов для запуска

pcs constraint colocation add dlm-clone with DRBD1-master
pcs constraint colocation add clvmd-clone with dlm-clone
pcs constraint colocation add fs-clone with clvmd-clone
pcs constraint colocation add samba-clone with fs-clone
pcs constraint colocation add virtual_ip with samba-clone
pcs constraint order promote DRBD1-master then dlm-clone
pcs constraint order start dlm-clone then clvmd-clone
pcs constraint order start clvmd-clone then fs-clone
pcs constraint order start fs-clone then samba-clone

29) Задаем очередь остановки ресурсов, без этого ваша машина может зависнуть на моменте выключения

pcs constraint order stop fs-clone then stop clvmd-clone
pcs constraint order stop clvmd-clone then stop dlm-clone
pcs constraint order stop dlm-clone then stop DRBD1-master
pcs constraint order stop samba-clone then stop fs-clone

P.S.


Сама шара может быть и на nfs, и на samba, но подключение к ним fail-over по IP, хотя само хранилище HA. Если вы хотите полный HA, то вместо samba и nfs вам надо ставить iSCSI и подключать через multipath. К тому же можно получить splitbrain в случае если одна из нод умрёт, а когда поднимется мастера не будет. Я проверил, что если ОС корректно выключается, то после поднятия ноды, когда мастера нет, она переходит в режим out-of-date и не становится мастером во избежание сплит брейна. Варианты с кворумом(DRBD и\или pacemaker) и любые извращения из каскадных конструкций DRBD после вашей настройки несостоятельны по причине высокой сложности, другой админ будет долго разбираться. Хотя с тем, что я написал не лучше, не делайте так.

Ссылки:

Здесь есть похожая инструкция с синтаксисом под pacemaker 1.0.

Комментарии 26

    0
    pacemaker с отключенным stonith — неподдерживаемая конфигурация (и потенциально, неопределённое поведение).
      +1
      Если вы знаете как с 2мя виртуалками без возможности управления сделать STONIT, расскажите, вы спасёте этим много молодых голов.
        0
        Надо три поднять, и на третьей держать только pacemaker. В худшем случае просто кластер остановится. Вот если есть только два хоста… тогда поинтереснее. А по мне, если возникла нужда в drbd+HA, проще взять NAS и поднять на нем айскази-таргет, ибо так или иначе точка отказа сеть.
          +2
          По условиям у вас есть только 2 виртуалки, никаких NAS и дополнительных виртуалок нет и не будет год-полтора. Как сделать по уму, так это поставить ceph или другую кластерную фс. Но уж точно не одинокий NAS стОящий денег и ограничивающий вас.
            +2
            Для арбитража split brain'а, кстати, есть такой грязный хак, как «reachability».

            Если у нас есть третий узел в сети (а он есть — роутер, как минимум), то кто пинги от соседа не видит, а роутера видит — того и тапки. Предполагается, что если до роутера и до пира не допинговаться, то надо сидеть на попе ровно и считать себя трупом.
              0
              Как-то раз очень клево у меня поломалась сеть, ошибка в работе свитча привела к тому, что оба гипера видели роутер, но не видели друг друга. ВМ на гиперах также видели роутер, но не видели ВМ на соседнем гипере. От такой ситуации даже reachability не спасет.
                0
                Увы это ненадёжный метод как указали ниже, поэтому я и написал, что не надо так делать.
              0
              Ключевое слово — виртуалки. У них есть гипервизор, у гипервизора есть команда «умри эту VM». (например, virsh destroy). Отличный stonith, между прочим.
                0
                А дальше при разрыве сети и доступности управляющих интерфейсов гипера запускается stonith deathmatch. Неприятно, мягко скажем. Ну или ничего недоступно, тогда и stonith бесполезен.
                  +1
                  Из чего мы делаем вывод, что нельзя разделить 3 нацело честно.

                  Вообще, вся это double primary drbd так воняет, что слов нет.

                  PS С точки зрения CAP-теоремы, если в случае проблем все ноды умрут, кластер останется highly available.
                    +1
                    Когда нет выбора, надо делать шлёп-шлёп и в продакшен.
                      0
                      В такой ситуации я бы реализовывал VM replication между гиперами и одну ВМ для хранения данных. Так или иначе шлеп-шлеп получается, репликация хотя бы может обеспечить более-менее быстрый возврат в работу при отказе гипервизора.
                        0
                        По условиям у вас нет доступа к гиперу, дома и в деве мы можем крутить, что хотим, но когда архитектор заложил неверно структуру, мы уже не в состоянии это поменять.
                          0
                          Тогда жопа, и я бы делал тогда одну ВМ вообще
                            0
                            Вам дали задачу сделать HA кластер самбы и 2 виртуалки. Больше никого не волнует ничего. Только нас, когда мы в углах по ночам плачем от таких задач.
                            0
                            Вообще если очень хочется в fencing, то можно использовать softdog method, он не идеален но предоставляет хоть какие-то гарантии, при этом не требуя никакого доступа к внешним устройствам или гипервизору.

                            Проблема в том, что для восстановления по прежнему необходим кворум и хотя бы три виртуалки.
                    0
                    Вам не дали такого интерфейса или вы не можете его во вменяемые сроки реализовать.
                      0
                      Вы, в 2019, не можете выключить виртуалку через API? Мне стыдно спросить, что за систему виртуализации вы используете. Неужели, higan?
                        0
                        Можете погадать, вам всё равно не ответят или не дадут доступа к управлению через апи.
                          0
                          В этой ситуации лучше иметь primary + secondary и переключать руками. Оператор будет выступать в качестве арбитра и у вас будет консистентность.

                          Я не понимаю людей, которые уверены, что именно у них в этой конфигурации split brain никогда не настанет.
                            0
                            Полностью согласен насчёт Сплита. Пускай тогда будет «горячий» резерв, но вводить — только руками оператора
                              0
                              Хорошая идея и конкурсы интересные) Только доступ оператора на закрытую площадку это 2 рабочих дня) А уж как узнать о том что там что-то сломалось, так это вообще песня.
                                0
                                Доступ оператора — имеется в виду ssh. Этого достаточно, чтобы привести систему в разумное состояние, но уже без отказоустойчивости. А если есть iLo и пр… ну, тогда можно вообще никуда не ездить.
                                  0
                                  ILO нет, ссш нет, доступ только через физическое пристутствие в цоде.
                                  0
                                  А от кого вы про split brain узнавать будете? Кластер-то тоже встанет, только в более плохую позу.
                                    0
                                    Вся суть в том, что от какого нибудь случайного пользователя, потому что иных путей нет. Идиотизм процветает.

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

                  Самое читаемое