Хочете мати спільну папку, яка не падає навіть коли один вузол вийшов з ладу? Зберемо високодоступний NFS‑кластер на Debian з DRBD для реплікації блочного пристрою і Pacemaker/Corosync для автоматичного перемикання. Покажу основні linux команди, налаштування і як безпечно протестувати фейловер 🙂

Передумови і схема

Маємо два вузли Debian 12: nfs1 (10.0.0.11) і nfs2 (10.0.0.12), та віртуальний IP 10.0.0.10 для клієнтів. На обох вузлах є додатковий диск /dev/sdb (або розділ /dev/sdb1). DRBD дзеркалить дані, Pacemaker керує ролями та ресурсами, NFS віддає шаринг. Це класичний сценарій для сервер Linux із вимогами до безперервності.

Кроки налаштування (How‑to)

1) Встановлення пакетів

Запустіть на ОБОХ вузлах (через SSH або локально в термінал Linux):

sudo apt update
sudo apt install -y drbd-utils pacemaker corosync crmsh resource-agents nfs-kernel-server

2) DRBD: реплікація блочного пристрою

Підготуйте розділ (на кожному вузлі). Якщо /dev/sdb вільний:

sudo parted -s /dev/sdb mklabel gpt mkpart primary 1MiB 100%

Створіть конфіг DRBD на обох вузлах:

sudo mkdir -p /etc/drbd.d
sudo tee /etc/drbd.d/r0.res >/dev/null <<'EOF'
resource r0 {
  protocol C;
  on nfs1 {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.11:7789;
    meta-disk internal;
  }
  on nfs2 {
    device /dev/drbd0;
    disk /dev/sdb1;
    address 10.0.0.12:7789;
    meta-disk internal;
  }
}
EOF
sudo modprobe drbd
sudo drbdadm create-md r0
sudo drbdadm up r0

Зробіть один вузол первинним (ЛИШЕ на nfs1), дочекайтеся синхронізації:

sudo drbdadm primary --force r0
watch -n2 cat /proc/drbd

Коли статус Synced, ініціалізуємо ФС, створюємо каталог і відмонтовуємо (монтувати буде кластер):

sudo mkfs.ext4 -L nfsdata /dev/drbd0
sudo mkdir -p /srv/nfs/data
sudo mount /dev/drbd0 /srv/nfs
sudo mkdir -p /srv/nfs/data
sudo umount /srv/nfs

Примітка: не додавайте експорт у /etc/exports — цим керуватиме Pacemaker ресурс exportfs.

3) Corosync/Pacemaker: запуск кластера

Ініціалізуйте кластер (на nfs1), потім приєднайте nfs2:

# На nfs1
sudo crm cluster init -n nfs-cluster -y
# На nfs2
sudo crm cluster join -c nfs1 -y
# Запуск демона на обох
sudo systemctl enable --now corosync pacemaker

Спрощені властивості для лабораторії (у проді обов'язково вмикайте STONITH):

sudo crm configure property stonith-enabled=false
sudo crm configure property no-quorum-policy=ignore
sudo crm configure property cluster-recheck-interval=2min

4) Ресурси в Pacemaker: DRBD, ФС, VIP, NFS

Створюємо майстер-слейв для DRBD, монтуємо ФС, додаємо VIP і експорт NFS:

sudo crm configure <<'EOF'
primitive p_drbd ocf:linbit:drbd \
  params drbd_resource="r0" \
  op monitor interval="15s" role="Master" timeout="30s" \
  op monitor interval="30s" role="Slave" timeout="30s"
ms ms_drbd p_drbd \
  meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"
primitive fs_data ocf:heartbeat:Filesystem \
  params device="/dev/drbd0" directory="/srv/nfs" fstype="ext4" \
  op monitor interval="20s"
primitive vip ocf:heartbeat:IPaddr2 \
  params ip="10.0.0.10" cidr_netmask="24" nic="eth0"
primitive nfs_server ocf:heartbeat:nfsserver \
  params nfs_shared_infodir="/var/lib/nfs/shared" \
  op monitor interval="30s"
primitive export_data ocf:heartbeat:exportfs \
  params directory="/srv/nfs/data" clientspec="10.0.0.0/24" options="rw,sync,no_root_squash" \
  op monitor interval="30s"
# Порядок і колокації
colocation col_fs_on_drbd inf: fs_data ms_drbd:Master
colocation col_nfs_on_fs   inf: nfs_server fs_data
colocation col_exp_on_nfs  inf: export_data nfs_server
colocation col_vip_on_nfs  inf: vip nfs_server
order o1 inf: ms_drbd:promote fs_data:start
order o2 inf: fs_data:start nfs_server:start
order o3 inf: nfs_server:start export_data:start
order o4 inf: nfs_server:start vip:start
commit
EOF

Перевірте статус:

crm_mon -1Arf

5) Клієнт і тест фейловеру

На клієнті (Debian/Ubuntu) змонтуйте експорт (NFSv4):

sudo apt install -y nfs-common
sudo mkdir -p /mnt/nfs
sudo mount -t nfs -o vers=4 10.0.0.10:/srv/nfs/data /mnt/nfs
# Перевірка запису
sudo sh -c 'echo hello > /mnt/nfs/ok.txt'

Тест відмови: зупиніть Pacemaker на активному вузлі і спостерігайте перенесення:

# На активному вузлі (де Master DRBD)
sudo systemctl stop pacemaker
# На другому вузлі
watch -n2 crm_mon -Arf

Файл /mnt/nfs/ok.txt має бути доступним під час фейловеру. Повернути вузол назад:

sudo systemctl start pacemaker

Альтернативні способи

  • CephFS або GlusterFS — розподілені ФС без єдиної точки збою, але складніші в розгортанні.
  • ZFS з реплікацією (zfs send/receive) + Pacemaker — альтернатива DRBD.
  • iSCSI + multipath з двома таргетами — варіант для блокового доступу з боку клієнтів.

GUI-спосіб (обмежений)

Повноцінного зручного GUI саме для Pacemaker на Debian небагато. Але можна:

  • Встановити Cockpit для моніторингу сервісів і журналів:
sudo apt install -y cockpit
sudo systemctl enable --now cockpit
# Далі у браузері: https://<IP-вузла>:9090
  • Використати Webmin для керування NFS‑експортами (але експортами у кластері все одно має керувати Pacemaker).

Для власне ресурсо‑менеджменту все ще зручніше користуватися crmsh — це швидко і надійно, а мережеві налаштування і перевірки видно одразу в терміналі ⚠️

FAQ

Які порти відкрити у firewall?

Для NFSv4 достатньо 2049/tcp. Також дозвольте corosync (5405/udp за замовч.), DRBD (7789/tcp). Приклад з UFW:

sudo ufw allow 2049/tcp
sudo ufw allow 5405/udp
sudo ufw allow 7789/tcp
sudo ufw reload

Чи потрібен STONITH (fencing)?

Так, у продакшені обов'язково. Тут ми вимкнули для лабораторії, інакше Pacemaker може блокувати промоут DRBD. На Debian доступні fence‑agents; оберіть варіант під ваше обладнання (IPMI, iDRAC, iLO тощо).

NFSv3 чи NFSv4?

NFSv4 простіший для firewall і безпечніший. Використовуйте v4, якщо немає спадкових обмежень. Клієнтське монтування як у прикладі з опцією -o vers=4.

Що робити при split‑brain у DRBD?

Зупиніть IO, визначте «правильного» первинного, а потім використовуйте процедури відновлення DRBD (наприклад, drbdadm secondary/primary, drbdadm connect, та відкидання застарілої копії з --discard-my-data на хибному вузлі). Обов'язково майте робоче резервне копіювання системи.

Як підвищити продуктивність?

  • Увімкніть jumbo‑frames (MTU 9000) на окремій мережі реплікації DRBD.
  • Налаштуйте швидкість синхронізації DRBD (параметр syncer rate) і TCP‑параметри.
  • Використовуйте XFS для великих файлів та послідовного IO.

Чому мій експорт не монтується клієнтом?

Перевірте, що ресурс exportfs запущений, клієнт у підмережі, та монтуєте саме шлях, який експортує exportfs (у нашому випадку 10.0.0.10:/srv/nfs/data). Також гляньте журнали: journalctl -u pacemaker -u nfs-server.

Чи можна автоматизувати це скриптом?

Так, більшість кроків легко загорнути у bash скрипти або Ansible. Для постійних змін у кластері бажана Git‑історія конфігів.

Порада від Kernelka

Перед великими оновленнями ядра або пакетів на кластерних вузлах робіть снапшоти/бекапи і тестовий фейловер у робочий час вікна. Так ви перевірите, що ваш сервер Linux переживе перезапуск без сюрпризів 😉

Підсумок

  • DRBD забезпечує синхронну реплікацію блочного пристрою між двома вузлами.
  • Pacemaker/Corosync керує ролями, ФС, віртуальним IP і експортами NFS.
  • Фейловер прозорий для клієнтів: точка монтування лишається доступною.
  • Для продакшену додайте STONITH, ретельно продумайте мережеві налаштування і політики резервне копіювання системи.
  • Командний підхід через crmsh і чіткі linux команди — найнадійніший шлях до стабільного HA.