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

Доброго времени суток, хабровчане. Поступила задача — развернуть отказоустойчивое High Available хранилище по средствам pacamaker + drbd (в режиме dual primary) + clvmd + ctdb, которое будет монтироваться на сервер. Оговорюсь, что со всеми этими инструментами я сталкиваюсь впервые и буду рад критике и дополнениям\исправлениям. В интернете инструкций конкретно по этой связке либо нет, либо информация устарела. Эта рабочая на данный момент, но есть одна проблема, решение которой, я надеюсь найти в ближайшее время. Все действия нужно выполнять на обоих нодах, если не указано обратное.

Приступим. У нас есть две виртуальные машины на 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-cluster

18) Добавляем ресурс 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-clone

19) На это этапе запуск 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
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 24

    +2
    Задачу какую решали?
    Вы же понимаете, что мастер-мастер в теории не работают?
    split brain, все дела.
    Как минимум, нужно три узла и программные средства, которые умеют в кворум/консенсус
      +1

      А чем не подошли нативные кластерные FS?

        0
        а какие кластерные фс работают на 3-5 хостов?
          0
          Смотря что имеется в виду под «работают». Ceph, gfs2, elliptics — смотря какие задачи стоят
            0
            DRBD мультимастер через набор разных разделов, каждый который сингл мастер дает R=2 (N+1) на 2-5 нодах лишь с небольшим геморроем и почти нулевым оверхедом.
            Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?
              +2
              Руками разруливать сплит-брейн с ненулевым шансом дропнуть латест дата — это называется небольшой гемморой???
                0
                стоп-стоп-стоп. я предлагаю мультимастер как два синглмастера, а не один блокдевайс на оба тазика в мастере.
                небольшой геморрой — в создание пар.
                0
                Вы не думаете, что в старом DRDB мультимастер с набором разных разделов — это скорее оверинжиниринг и костыли, чем production решение?
                Кто из вышеозначенных позволяет создать отказоустойчивую (durable) сборку без значительного оверхеда, и так чтоб любая машина была умираема?

                Что значит «значительный оверхед»? Понятно, что чудес нет. И выигрывая в надежности, мы теряем в скорости. Но, извините, возможность сплит-брейна — это вообще отсутствие надежности, т.е. бинарная опция, а не какой-то параметр, который мы можем выразить непрерывной величиной (числом в диапазоне 0...max)
                  0
                  я спрашиваю про решение на три-пять тазиков.
                  На дрбд это:
                  M1 S1 --
                  -- M2 S2
                  S3 -- M3

                  и у нас N+1, никакого брейнсплита, есть кворум, все три мастера, при сдыхании один бурет роль двух мастеров пока не заменим/починим.

                  кластерные фс они от 10 хостов реально начинают работать с хорошим эффектом. но до 10 хостов надо еще дорасти…
                    0
                    есть кворум, все три мастера, при сдыхании один бурет роль двух мастеров пока не заменим/починим.

                    Это, по-моему, только в drdb9 только появилось? Прошу поправить, если неправ.
                    Касательно указанного конфига — glusterfs (я его ОЧЕНЬ не люблю), но нормально на трех ведрах работает.
                      0
                      почему? это и на 8м собирается. как три независимых раздела.

                      хмм… помню что-то было не то с глустером у меня. с него грузиться ось умеет?
                        0
                        хмм… помню что-то было не то с глустером у меня. с него грузиться ось умеет?

                        это зачем?
                        я спрашиваю про решение на три-пять тазиков.
                        На дрбд это:
                        M1 S1 — -- M2 S2
                        S3 — M3

                        я не понимаю и как это решает проблему сплита?

                        было
                        M1 S1 --
                        -- M2 S2
                        S3 -- M3

                        средний узел сепарировался
                        M1 M1 --
                        -- M2 M2
                        S3 -- M3

                        потом сплит пропал.
                        конфликт отдельно по блоку 1, отдельно по блоку 2.
                        Или Вы планируете решение конфликта оставить на стороне приклада?
                          0
                          три хоста = кворум. если второй отсплитился, его кластером уводим в слейв, да хоть и коросинком с пейсмейкером. чем угодно.

                          если все три изолироавлись — все в слейвах до ручного вмешательства.

                          а грузиться — это для VM с доступом к файлу, а не просто файл-образ держать.
                            0
                            три хоста = кворум. если второй отсплитился, его кластером уводим в слейв, да хоть и коросинком с пейсмейкером. чем угодно.

                            понял мысль. Т.е. внешними приблудами. Но это все равно опасно. Например, у нас сеть не стартанула, или сервис-арбитр, или еще что-то. И знаете, хуже даже не сплит сам. А когда был сплит, потом пошла синхронизация данных, а потом второй, но уже по второму месту и… приплыли.

                            Да, я только теоретизирую )

                            а грузиться — это для VM с доступом к файлу, а не просто файл-образ держать.

                            т.е. DRDB ВНУТРИ виртуалок?
                              0
                              да, есть варианты когда совсем нерешаемо. но это решаемо! :D
                              уровень такого сплита сопоставим просто со смертью дисков разом — поднимать бакапы и/или допустимые потери.
                              просто других способов наращивать мощность по одному в малых масштабов я пока не нашел, вот и спрашиваю всегда…

                              нет, drbd не внутри. но вопрос как поднимать на файлах, а не на файле-образе. помнится записи в файл-образ реплицируются на кластерных фс не моментльно (файл же не закрыт, а синк не всегда требует успешной репликации иначе все дико тормозит).
                                0
                                Я все-таки не понимаю, прошу прощения, какую задачу Вы решаете с помощью DRDB. Т.е. синхронизация файлов stateless приложений между VM, синхронизация образов VM между различными нодами с гипервизором… или что происходит?
                                  0
                                  дрбд обеспечивает реалтайм репликацию между нодами. на мастере смонтировно в фс, с фс запущены контейнеры.
                                  мастер-слейв, монтирование и запуск контейнеров в кластерменеджере
              0
              На 2х хостах, это всё, что есть. На этом надо сделать HA решение.
                0
                на 2-х принципиально нельзя, иначе роете себе яму. Как минимум нужно 3. Это теория.
                  0
                  на двух потребуется человек-арбитр для переброса, во избежание сплита.
                  но система вполне работает
                    0
                    В случае сплита, действительно оператор исправит запуск второго мастера, но шанс такого поведения у нас мал. Даже в случае сплита, один мастер будет работать и мы получим деградацию в производительности, которой можно пренебречь. Во всех остальных случаях мы получим high availability решение.
              +1
              Вся эта конструкция рассыпется при первом сплитбрейне
                0
                Какие же вы невнимательные, clvm не даст писать если кластер развалится, это одна из проблем при старте второго мастера после его отключения.
                0
                Спасибо за материал.
                Небольшое замечание по терминологии
                развернуть отказоустойчивое High Available хранилище

                Если не ошибаюсь для термина «Отказоустойчивый» в английском языке соответствует «Fault Tolerant», а для термина «Высокой Доступности» = «High Available».

                Only users with full accounts can post comments. Log in, please.