Приступим. У нас есть две виртуальные машины на CentOS 7.
1) Для надежности знакомим их в /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
rpm -Uvh https://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
3) Устанавливаем drbd версии 8.4 (у меня не получилось завести 9.0 в режиме dual primary )
yum install -y kmod-drbd84 drbd84-utils
4) Активируем и включаем в автозагрузку модуль ядра drbd
modprobe drbd
echo drbd > /etc/modules-load.d/drbd.conf
5) Создаем конфигурационный файл ресурса drbd /etc/drbd.d/r0.res
resource r0 {
protocol C;
device /dev/drbd0;
meta-disk internal;
disk /dev/sdb;
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";
}
on node1 {
address 192.168.0.1:7788;
}
on node2 {
address 192.168.0.2:7788;
}
6) Отключаем юнит drbd (позже его за него будет отвечать pacemaker), создаем метаданные для диска drbd, поднимаем ресурс
systemctl disable drbd
drbdadm create-md r0
drbdadm up r0
7) На первой ноде делаем ресурс первичным
drbdadm primary --force r0
8) Ставим pacemaker
yum install -y pacemaker pcs resource-agents
9) Устанавливаем пароль для пользователя hacluster для авторизации на нодах
echo CHANGEME | passwd --stdin hacluster
10) Запускаем pacemaker на обоих нодах
systemctl enable pcsd
systemctl start pcsd
11) Авторизуемся в кластере. C этого этапа делаем все на одной ноде
pcs cluster auth node1 node2 -u hacluster
12) Создаем кластер с именем samba_cluster
pcs cluster setup --force --name samba_cluster node1 node2
13) активируем ноды
pcs cluster enable --all
pcs cluster start --all
14) Так как в качестве серверов у нас выступают виртуальные машины, то отключаем механизм STONITH
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore
15) Создаем VIP
pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=192.168.0.10 cidr_netmask=24 op monitor interval=60s
16) Создаем ресурс drbd
pcs cluster cib drbd_cfg
pcs -f drbd_cfg resource create DRBD ocf:linbit:drbd drbd_resource=r0 op monitor interval=60s
pcs -f drbd_cfg resource master DRBDClone DRBD master-max=2 master-node-max=1 clone-node-max=1
clone-max=2 notify=true interleave=true
pcs cluster cib-push drbd_cfg
17) Устанавливаем необходимые пакеты для clvm и подготавливаем clvm
yum install -y lvm2-cluster gfs2-utils
/sbin/lvmconf --enable-cluster18) Добавляем ресурс dlm и clvd в pacemaker
pcs resource create dlm ocf:pacemaker:controld op monitor interval=30s on-fail=fence clone interleave=true ordered=true
pcs resource create clvmd ocf:heartbeat:clvm op monitor interval=30s on-fail=fence clone interleave=true ordered=true
pcs constraint colocation add clvmd-clone with dlm-clone19) На это этапе запуск clvmd и dlm должен выдать ошибку. Заходим на веб интерфейс pacemaker 192.168.0.1:2224. Если кластер не появился, то добавляем его «Edd existing». Далее переходим Resources — dlm — optional arguments и выставляем значение allow_stonith_disabled = true
20) Задаем очередь загрузки ресурсов
pcs constraint order start DRBDClone then dlm-clone
pcs constraint order start dlm-clone then clvmd-clone
21) Запрещаем LVM писать кэш и очищаем его. На обоих нодах
sed -i 's/write_cache_state = 1/write_cache_state = 0/' /etc/lvm/lvm.conf
rm /etc/lvm/cache/*
22) Редактируем /etc/lvm/lvm.conf чтоб lvm не видел /dev/sdb. На обоих нодах
# This configuration option has an automatic default value.
# filter = [ "a|.*/|" ]
filter = [ "r|^/dev/sdb$|" ]
23) Создаем CLVM раздел. Делаем только на одной ноде
$ vgcreate -Ay -cy cl_vg /dev/drbd0
Physical volume "/dev/drbd0" successfully created.
Clustered volume group "cl_vg" successfully created
$ lvcreate -l100%FREE -n r0 cl_vg
Logical volume "r0" created.
24) Размечаем раздел в gfs2
mkfs.gfs2 -j2 -p lock_dlm -t drbd-gfs2:r0 /dev/cl_vg/r0
25) Дальше добавляем монтирование этого раздела в pacemaker и говорим ему грузиться после clvmd
pcs resource create fs ocf:heartbeat:Filesystem device="/dev/cl_vg/r0" directory="/mnt/" fstype="gfs2" --clone
pcs constraint order start clvmd-clone then fs-clone
26) Теперь наcтал черед ctdb, который будет запускать samba
yum install -y samba ctdb cifs-utils
27) Правим конфиг /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
28) Создаем файл со списком нод. ВНИМАНИЕ! После каждого айпишника в списке нод, должен присутствовать перевод строки. Иначе нода будет фэйлится при инициализации.
cat /etc/ctdb/nodes
192.168.0.1
192.168.0.2
29) Добавляем к конфигу /etc/samba/smb.conf
[global]
clustering = yes
private dir = /mnt/ctdb
lock directory = /mnt/ctdb
idmap backend = tdb2
passdb backend = tdbsam
[test]
comment = Cluster Share
path = /mnt
browseable = yes
writable = yes
30) И наконец создаем ресурс ctdb и указываем, что он должен грузиться после
pcs constraint order start fs-clone then samba
А теперь о проблеме, которую я пока не решил. Если ребутнуть ноду, то вся связка рушится, так как drbd нужно время чтобы активировать /dev/drbd0. DLM не видит раздела, так как он еще не активирован и не стартует и т.д. Временное решение — активировать раздел вручную и перезапустить ресурсы pacemaker
vgchage -a y
pcs resource refresh
Комментарии (24)
crazylh
13.01.2019 18:43А чем не подошли нативные кластерные FS?
datacompboy
14.01.2019 02:35а какие кластерные фс работают на 3-5 хостов?
crazylh
14.01.2019 03:18Смотря что имеется в виду под «работают». Ceph, gfs2, elliptics — смотря какие задачи стоят
datacompboy
14.01.2019 10:26DRBD мультимастер через набор разных разделов, каждый который сингл мастер дает R=2 (N+1) на 2-5 нодах лишь с небольшим геморроем и почти нулевым оверхедом.
Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?crazylh
14.01.2019 10:29Руками разруливать сплит-брейн с ненулевым шансом дропнуть латест дата — это называется небольшой гемморой???
datacompboy
14.01.2019 11:09стоп-стоп-стоп. я предлагаю мультимастер как два синглмастера, а не один блокдевайс на оба тазика в мастере.
небольшой геморрой — в создание пар.
gecube
14.01.2019 10:37Вы не думаете, что в старом DRDB мультимастер с набором разных разделов — это скорее оверинжиниринг и костыли, чем production решение?
Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?
Что значит «значительный оверхед»? Понятно, что чудес нет. И выигрывая в надежности, мы теряем в скорости. Но, извините, возможность сплит-брейна — это вообще отсутствие надежности, т.е. бинарная опция, а не какой-то параметр, который мы можем выразить непрерывной величиной (числом в диапазоне 0...max)datacompboy
14.01.2019 11:12я спрашиваю про решение на три-пять тазиков.
На дрбд это:
M1 S1 --
-- M2 S2
S3 -- M3
и у нас N+1, никакого брейнсплита, есть кворум, все три мастера, при сдыхании один бурет роль двух мастеров пока не заменим/починим.
кластерные фс они от 10 хостов реально начинают работать с хорошим эффектом. но до 10 хостов надо еще дорасти…gecube
14.01.2019 11:15есть кворум, все три мастера, при сдыхании один бурет роль двух мастеров пока не заменим/починим.
Это, по-моему, только в drdb9 только появилось? Прошу поправить, если неправ.
Касательно указанного конфига — glusterfs (я его ОЧЕНЬ не люблю), но нормально на трех ведрах работает.datacompboy
14.01.2019 11:21почему? это и на 8м собирается. как три независимых раздела.
хмм… помню что-то было не то с глустером у меня. с него грузиться ось умеет?gecube
14.01.2019 11:24хмм… помню что-то было не то с глустером у меня. с него грузиться ось умеет?
это зачем?
я спрашиваю про решение на три-пять тазиков.
На дрбд это:
M1 S1 — -- M2 S2
S3 — M3
я не понимаю и как это решает проблему сплита?
было
M1 S1 --
-- M2 S2
S3 -- M3
средний узел сепарировался
M1 M1 --
-- M2 M2
S3 -- M3
потом сплит пропал.
конфликт отдельно по блоку 1, отдельно по блоку 2.
Или Вы планируете решение конфликта оставить на стороне приклада?datacompboy
14.01.2019 11:32три хоста = кворум. если второй отсплитился, его кластером уводим в слейв, да хоть и коросинком с пейсмейкером. чем угодно.
если все три изолироавлись — все в слейвах до ручного вмешательства.
а грузиться — это для VM с доступом к файлу, а не просто файл-образ держать.gecube
14.01.2019 11:43три хоста = кворум. если второй отсплитился, его кластером уводим в слейв, да хоть и коросинком с пейсмейкером. чем угодно.
понял мысль. Т.е. внешними приблудами. Но это все равно опасно. Например, у нас сеть не стартанула, или сервис-арбитр, или еще что-то. И знаете, хуже даже не сплит сам. А когда был сплит, потом пошла синхронизация данных, а потом второй, но уже по второму месту и… приплыли.
Да, я только теоретизирую )
а грузиться — это для VM с доступом к файлу, а не просто файл-образ держать.
т.е. DRDB ВНУТРИ виртуалок?datacompboy
14.01.2019 11:49да, есть варианты когда совсем нерешаемо. но это решаемо! :D
уровень такого сплита сопоставим просто со смертью дисков разом — поднимать бакапы и/или допустимые потери.
просто других способов наращивать мощность по одному в малых масштабов я пока не нашел, вот и спрашиваю всегда…
нет, drbd не внутри. но вопрос как поднимать на файлах, а не на файле-образе. помнится записи в файл-образ реплицируются на кластерных фс не моментльно (файл же не закрыт, а синк не всегда требует успешной репликации иначе все дико тормозит).gecube
14.01.2019 11:54Я все-таки не понимаю, прошу прощения, какую задачу Вы решаете с помощью DRDB. Т.е. синхронизация файлов stateless приложений между VM, синхронизация образов VM между различными нодами с гипервизором… или что происходит?
datacompboy
14.01.2019 12:03дрбд обеспечивает реалтайм репликацию между нодами. на мастере смонтировно в фс, с фс запущены контейнеры.
мастер-слейв, монтирование и запуск контейнеров в кластерменеджере
AlexGluck
14.01.2019 16:21На 2х хостах, это всё, что есть. На этом надо сделать HA решение.
gecube
14.01.2019 17:13на 2-х принципиально нельзя, иначе роете себе яму. Как минимум нужно 3. Это теория.
datacompboy
14.01.2019 18:41на двух потребуется человек-арбитр для переброса, во избежание сплита.
но система вполне работаетAlexGluck
14.01.2019 19:45В случае сплита, действительно оператор исправит запуск второго мастера, но шанс такого поведения у нас мал. Даже в случае сплита, один мастер будет работать и мы получим деградацию в производительности, которой можно пренебречь. Во всех остальных случаях мы получим high availability решение.
OasisInDesert
14.01.2019 12:59Спасибо за материал.
Небольшое замечание по терминологии
развернуть отказоустойчивое High Available хранилище
Если не ошибаюсь для термина «Отказоустойчивый» в английском языке соответствует «Fault Tolerant», а для термина «Высокой Доступности» = «High Available».
gecube
Задачу какую решали?
Вы же понимаете, что мастер-мастер в теории не работают?
split brain, все дела.
Как минимум, нужно три узла и программные средства, которые умеют в кворум/консенсус