В продолжение статьи «Кластерное хранилище Pacemaker + DRBD (Dual primary) + ctdb» представляю полностью готовый и рабочий вариант HA кластера файловой шары на 2-4 ноды для centos 6 и centos 7. Если вы хотите реализовать такое, вы либо извращенец, либо вам не дали никакого выбора, и реализовать надо хоть как-то.
Я просто опишу слоёный пирог, который мы будем собирать:
На блочном устройстве создаём таблицу gpt => один раздел на всё пространство под лвм => группу томов лвм на всё доступное пространство => лвм том на всё доступное пространство => drbd устройство => dlm => размечаем как физический том лвм на всё доступное пространство => на него кластерную группу томов лвм => лвм том на всё доступное пространство => размечаем фс gfs2 => подключаем в точку монтирования.
И рулить всем этим будет pacemaker c virtual ip адресом.
Если вы ещё хотите продолжать, читайте дальше под катом.
По условиям нам дали 2 виртуальные машины и на этом всё. Ceph для корректной работы лучше ставить на 6 нодах, минимум 4, плюс было бы неплохо иметь какой-нибудь опыт работы с ним, а то получится как у cloudmouse. Gluster для сотен тысяч мелких файлов по производительности не пройдёт, это обмусолено на просторах хабра много раз. ipfs, lustre и тому подобные имеют такие же требования как у ceph или даже больше.
1) Pacemaker версии 1.1 не работает с ip корректно, поэтому для надёжности добавляем в /etc/hosts записи:
2) В стандартных репозиториях DRBD нет, поэтому надо подключить сторонний.
3) Устанавливаем drbd версии 8.4
4) Активируем и включаем в автозагрузку модуль ядра drbd
5) Создаём раздел диска и настраиваем лвм
6) Создаем конфигурационный файл ресурса drbd /etc/drbd.d/r0.res
7) Убираем сервис drbd из авозагрузки (позже его за него будет отвечать pacemaker), создаем метаданные для диска drbd, поднимаем ресурс
8) На первой ноде делаем ресурс первичным
9) Ставим pacemaker
10) Устанавливаем пароль для пользователя hacluster для авторизации на нодах
11) Запускаем pcsd на обоих нодах
12) Авторизуемся в кластере. C этого этапа делаем все на одной ноде
13) Создаем кластер с именем samba_cluster
14) активируем ноды и добавляем сервисы в автозагрузку и запускаем их
15) Так как в качестве серверов у нас выступают виртуальные машины, то отключаем механизм STONITH, так как мы не имеем никаких механизмов для управления ими. Так же у нас машин всего 2, поэтому кворум тоже отключаем, он работает только при 3х и более машинах.
16) Создаем VIP
17) Создаем ресурс drbd
18) Устанавливаем необходимые пакеты для clvm и подготавливаем clvm
19) Добавляем ресурс dlm и clvd в pacemaker
20) Запрещаем LVM писать кэш и очищаем его. На обоих нодах
21) Создаем CLVM раздел. Делаем только на одной ноде
22) Размечаем раздел в gfs2, здесь важно чтобы таблица блокировок имела тоже имя что и наш кластер в peacemaker. Делаем только на одной ноде
23) Дальше добавляем монтирование этого раздела в pacemaker и говорим ему грузиться после clvmd
24) Теперь наcтал черед ctdb, который будет запускать samba
25) Правим конфиг /etc/ctdb/ctdbd.conf
26) Создаем файл со списком нод /etc/ctdb/nodes
ВНИМАНИЕ! После каждого адреса в списке должен присутствовать перевод строки. Иначе нода не будет включаться при инициализации.
27) И наконец создаем ресурс ctdb
28) Задаем очередь загрузки и зависимости ресурсов для запуска
29) Задаем очередь остановки ресурсов, без этого ваша машина может зависнуть на моменте выключения
Сама шара может быть и на nfs, и на samba, но подключение к ним fail-over по IP, хотя само хранилище HA. Если вы хотите полный HA, то вместо samba и nfs вам надо ставить iSCSI и подключать через multipath. К тому же можно получить splitbrain в случае если одна из нод умрёт, а когда поднимется мастера не будет. Я проверил, что если ОС корректно выключается, то после поднятия ноды, когда мастера нет, она переходит в режим out-of-date и не становится мастером во избежание сплит брейна. Варианты с кворумом(DRBD и\или pacemaker) и любые извращения из каскадных конструкций DRBD после вашей настройки несостоятельны по причине высокой сложности, другой админ будет долго разбираться. Хотя с тем, что я написал не лучше, не делайте так.
Ссылки:
Здесь есть похожая инструкция с синтаксисом под pacemaker 1.0.
Я просто опишу слоёный пирог, который мы будем собирать:
На блочном устройстве создаём таблицу gpt => один раздел на всё пространство под лвм => группу томов лвм на всё доступное пространство => лвм том на всё доступное пространство => drbd устройство => dlm => размечаем как физический том лвм на всё доступное пространство => на него кластерную группу томов лвм => лвм том на всё доступное пространство => размечаем фс gfs2 => подключаем в точку монтирования.
И рулить всем этим будет pacemaker c virtual ip адресом.
Если вы ещё хотите продолжать, читайте дальше под катом.
Из исходных нам необходимо следующее:
Процессор 1 ядро
1 Гб минимум оперативной памяти
15 Гб диск + место на котором вы будете хранить данные
Дисков может быть сколько угодно, даже один.
Если у вас один диск, то лучше размечать его следующим образом:
Таблица разделов gpt => раздел 200 Мб для efi (опционально) => раздел 1Гб для /boot => всё остальное место под лвм.
На лвм томе вам необходимо создать 2 группы томов. Первая группа томов под ОС размером 10 Гб + удвоенному размеру оперативной памяти, но не более 4 Гб.
Кто бы, что не говорил, но подкачка иногда очень выручает, поэтому на лвм группе создаём лвм раздел для подкачки равный удвоенному размеру оперативной памяти, но не более 4 Гб и оставшееся место отводим под корень ОС.
Вторая группа лвм под хранение данных. Создаём лвм раздел на всё оставшееся место.
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-utils4) Активируем и включаем в автозагрузку модуль ядра 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 r09) Ставим pacemaker
yum install -y pacemaker corosync pcs resource-agents fence-agents-all10) Устанавливаем пароль для пользователя 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 node214) активируем ноды и добавляем сервисы в автозагрузку и запускаем их
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/r023) Дальше добавляем монтирование этого раздела в pacemaker и говорим ему грузиться после clvmd
pcs resource create fs ocf:heartbeat:Filesystem device="/dev/cl_vg/r0" directory="/mnt" fstype="gfs2" clone interleave=true24) Теперь наcтал черед ctdb, который будет запускать samba
yum install -y samba ctdb cifs-utils25) Правим конфиг /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.
amarao
pacemaker с отключенным stonith — неподдерживаемая конфигурация (и потенциально, неопределённое поведение).
AlexGluck Автор
Если вы знаете как с 2мя виртуалками без возможности управления сделать STONIT, расскажите, вы спасёте этим много молодых голов.
vesper-bot
Надо три поднять, и на третьей держать только pacemaker. В худшем случае просто кластер остановится. Вот если есть только два хоста… тогда поинтереснее. А по мне, если возникла нужда в drbd+HA, проще взять NAS и поднять на нем айскази-таргет, ибо так или иначе точка отказа сеть.
AlexGluck Автор
По условиям у вас есть только 2 виртуалки, никаких NAS и дополнительных виртуалок нет и не будет год-полтора. Как сделать по уму, так это поставить ceph или другую кластерную фс. Но уж точно не одинокий NAS стОящий денег и ограничивающий вас.
amarao
Для арбитража split brain'а, кстати, есть такой грязный хак, как «reachability».
Если у нас есть третий узел в сети (а он есть — роутер, как минимум), то кто пинги от соседа не видит, а роутера видит — того и тапки. Предполагается, что если до роутера и до пира не допинговаться, то надо сидеть на попе ровно и считать себя трупом.
vesper-bot
Как-то раз очень клево у меня поломалась сеть, ошибка в работе свитча привела к тому, что оба гипера видели роутер, но не видели друг друга. ВМ на гиперах также видели роутер, но не видели ВМ на соседнем гипере. От такой ситуации даже reachability не спасет.
AlexGluck Автор
Увы это ненадёжный метод как указали ниже, поэтому я и написал, что не надо так делать.
amarao
Ключевое слово — виртуалки. У них есть гипервизор, у гипервизора есть команда «умри эту VM». (например, virsh destroy). Отличный stonith, между прочим.
vesper-bot
А дальше при разрыве сети и доступности управляющих интерфейсов гипера запускается stonith deathmatch. Неприятно, мягко скажем. Ну или ничего недоступно, тогда и stonith бесполезен.
amarao
Из чего мы делаем вывод, что нельзя разделить 3 нацело честно.
Вообще, вся это double primary drbd так воняет, что слов нет.
PS С точки зрения CAP-теоремы, если в случае проблем все ноды умрут, кластер останется highly available.
AlexGluck Автор
Когда нет выбора, надо делать шлёп-шлёп и в продакшен.
vesper-bot
В такой ситуации я бы реализовывал VM replication между гиперами и одну ВМ для хранения данных. Так или иначе шлеп-шлеп получается, репликация хотя бы может обеспечить более-менее быстрый возврат в работу при отказе гипервизора.
AlexGluck Автор
По условиям у вас нет доступа к гиперу, дома и в деве мы можем крутить, что хотим, но когда архитектор заложил неверно структуру, мы уже не в состоянии это поменять.
vesper-bot
Тогда жопа, и я бы делал тогда одну ВМ вообще
AlexGluck Автор
Вам дали задачу сделать HA кластер самбы и 2 виртуалки. Больше никого не волнует ничего. Только нас, когда мы в углах по ночам плачем от таких задач.
kvaps
Вообще если очень хочется в fencing, то можно использовать softdog method, он не идеален но предоставляет хоть какие-то гарантии, при этом не требуя никакого доступа к внешним устройствам или гипервизору.
Проблема в том, что для восстановления по прежнему необходим кворум и хотя бы три виртуалки.
AlexGluck Автор
Вам не дали такого интерфейса или вы не можете его во вменяемые сроки реализовать.
amarao
Вы, в 2019, не можете выключить виртуалку через API? Мне стыдно спросить, что за систему виртуализации вы используете. Неужели, higan?
AlexGluck Автор
Можете погадать, вам всё равно не ответят или не дадут доступа к управлению через апи.
amarao
В этой ситуации лучше иметь primary + secondary и переключать руками. Оператор будет выступать в качестве арбитра и у вас будет консистентность.
Я не понимаю людей, которые уверены, что именно у них в этой конфигурации split brain никогда не настанет.
gecube
Полностью согласен насчёт Сплита. Пускай тогда будет «горячий» резерв, но вводить — только руками оператора
AlexGluck Автор
Хорошая идея и конкурсы интересные) Только доступ оператора на закрытую площадку это 2 рабочих дня) А уж как узнать о том что там что-то сломалось, так это вообще песня.
gecube
Доступ оператора — имеется в виду ssh. Этого достаточно, чтобы привести систему в разумное состояние, но уже без отказоустойчивости. А если есть iLo и пр… ну, тогда можно вообще никуда не ездить.
AlexGluck Автор
ILO нет, ссш нет, доступ только через физическое пристутствие в цоде.
amarao
А от кого вы про split brain узнавать будете? Кластер-то тоже встанет, только в более плохую позу.
AlexGluck Автор
Вся суть в том, что от какого нибудь случайного пользователя, потому что иных путей нет. Идиотизм процветает.