Настройка отказоустойчивого кластера NFS с DRBD и Pacemaker для HA-сервисов: пошаговое руководство на 2026 год

Высокодоступный NFS-сервер на базе DRBD и Pacemaker - это проверенное решение для критически важных сервисов, где нулевое время простоя и целостность данных не подлежат обсуждению. Это руководство предоставляет полный комплект рабочих конфигураций и команд, протестированных в реальной среде. Вы получите готовую архитектуру, которая автоматически переключает ресурсы при сбое узла, сохраняя доступ к данным через единый виртуальный IP-адрес.

Зачем нужен кластерный NFS и как работает решение с DRBD и Pacemaker

Традиционный NFS-сервер представляет собой единую точку отказа. Его выход из строя останавливает все сервисы, зависящие от общих файловых ресурсов: веб-приложения, системы управления контентом, базы данных, работающие с файлами блобов, виртуальные машины. Простой означает прямые финансовые потери и нарушение бизнес-процессов.

Архитектура на основе DRBD и Pacemaker устраняет эту уязвимость. Она обеспечивает два ключевых свойства: целостность данных и доступность сервиса.

Проблема: NFS как единая точка отказа в критических сервисах

Сервисы, которые часто зависят от общего файлового хранилища NFS:

Веб-серверы, развернутые в кластере, с общим каталогом для загрузок или сессий.
Системы управления базами данных (например, PostgreSQL с табличными пространствами на NFS).
Репозитории исходного кода или бинарных артефактов сборки (Git, Nexus).
Домашние каталоги пользователей в корпоративной среде.

Отказ единственного NFS-сервера приводит к невозможности записи или чтения данных, что вызывает каскадные сбои в приложениях. Восстановление после такого инцидента требует времени, в течение которого бизнес не функционирует.

Решение: DRBD + Pacemaker - синхронная репликация и интеллектуальное управление ресурсами

Решение строится на двух основных технологиях, каждая из которых решает свою задачу.

DRBD (Distributed Replicated Block Device) работает как "сетевой RAID-1". Он синхронно реплицирует данные на уровне блоков с одного физического диска (узла Primary) на другой (узел Secondary). Запись на диск считается успешной только после подтверждения от обоих узлов. Это гарантирует, что в момент сбоя на standby-узле находится точная, консистентная копия данных. Протокол репликации «C» (synchronous) обеспечивает максимальную надежность, что критично для файловых систем.

Pacemaker выступает в роли оркестратора кластера. В паре с низкоуровневым демоном Corosync он отслеживает состояние узлов (жив/мертв) через heartbeat-сообщения. Его задача - управлять набором кластерных ресурсов и поддерживать их работу на активном узле. В нашем сценарии Pacemaker управляет:

Состоянием ресурса DRBD (Promote/Demote).
Монтированием файловой системы (ext4, xfs) с реплицированного блочного устройства.
Запуском и остановкой демона NFS-сервера.
Назначением виртуального IP-адреса (VIP) на активный узел.

Виртуальный IP-адрес (VIP) - это ключевой элемент для клиентов. Они подключаются не к физическому адресу сервера, а к постоянному VIP. Pacemaker привязывает этот адрес к активному узлу. При его отказе VIP за несколько секунд мигрирует на резервный узел, и клиенты автоматически получают доступ к сервису, часто даже не замечая переключения.

Архитектура кластера из двух узлов выглядит так: два сервера (Node1 и Node2) с идентичными дисками. DRBD создает из них одно логическое устройство (/dev/drbd0). Pacemaker на активном узле монтирует это устройство, запускает NFS и поднимает VIP. Весь трафик клиентов идет через VIP на активный узел, а данные синхронно копируются на standby-узел.

Предварительные требования и подготовка среды

Перед началом развертывания убедитесь, что ваша инфраструктура соответствует минимальным требованиям. Работа инструкции проверена для следующих дистрибутивов: Ubuntu 22.04 LTS, CentOS 7 / RHEL 8 и их производных. Для других версий могут потребоваться корректировки команд.

Минимальные требования к серверам и сети

Два физических или виртуальных сервера с одинаковой версией ОС.
Выделенные диски или разделы одинакового размера на каждом узле для DRBD. На дисках не должно быть данных, которые важно сохранить.
Статические IP-адреса для каждого узла в основной сети.
Выделенный сетевой интерфейс или VLAN для трафика репликации DRBD (рекомендуется для production). Это предотвращает конкуренцию трафика репликации и клиентского NFS-трафика за полосу пропускания.
Открытые порты для кластерного взаимодействия: TCP 5404, 5405 (Corosync), TCP 2224 (Pacemaker), а также порты для DRBD (по умолчанию 7788–7799).
Отключенный или корректно настроенный межсетевой экран (firewalld, iptables) на обоих узлах для указанных портов и протоколов.
Отключенный SELinux (в режиме permissive) или настроенные политики для DRBD, Pacemaker и NFS. Для тестовой настройки проще временно отключить: setenforce 0.

Необходимые пакеты (имена могут отличаться в зависимости от дистрибутива): drbd-utils, drbd-km или drbd-modules, pacemaker, corosync, pcs, nfs-utils.

Начальная подготовка узлов кластера

Выполните эти команды на обоих серверах, предварительно заменив node1 и node2 на имена или IP-адреса ваших узлов.

1. Установите необходимые пакеты.

Для RHEL/CentOS/Rocky:

yum install -y epel-release
yum install -y drbd-utils drbd-km pacemaker corosync pcs nfs-utils

Для Ubuntu/Debian:

apt update
apt install -y drbd-utils drbd-modules pacemaker corosync pcs nfs-kernel-server

2. Настройте имена узлов и добавьте их в файл /etc/hosts для гарантированного разрешения.

# На node1
hostnamectl set-hostname node1

# На node2
hostnamectl set-hostname node2

Отредактируйте /etc/hosts на обоих узлах, добавив строки:

192.168.1.10 node1
192.168.1.20 node2
# А также адреса для сети репликации DRBD, если она отдельная
10.0.0.1 node1-drbd
10.0.0.2 node2-drbd

3. Проверьте сетевое соединение между узлами.

ping -c 3 node2  # с node1
ping -c 3 node1  # с node2

4. Настройте синхронизацию времени (NTP). Расхождение во времени более чем на несколько секунд может нарушить работу Corosync.

timedatectl set-ntp true
systemctl enable chronyd --now  # или systemctl enable ntp

5. Создайте пароль для пользователя hacluster (требуется для pcs). На обоих узлах задайте одинаковый пароль.

echo 'your_secure_password' | passwd --stdin hacluster

6. Разрешите сервисам запускаться после перезагрузки и запустите их.

systemctl enable pcsd
systemctl start pcsd

Пошаговое развертывание кластера: от DRBD до Pacemaker

Следуйте инструкциям последовательно. Все команды, кроме явно оговоренных, выполняются от пользователя root или через sudo.

Конфигурация и запуск DRBD для синхронной репликации диска

1. Определите устройство для репликации на каждом узле (например, /dev/sdb1). Убедитесь, что разделы не смонтированы и не используются.

2. Создайте конфигурационный файл DRBD /etc/drbd.d/nfs.res на обоих узлах.

resource nfs {
    protocol C;                     # Синхронная репликация. Запись подтверждается после сохранения на обоих дисках.
    startup {
        wfc-timeout 30;            # Время ожидания подключения второго узла при старте.
        degr-wfc-timeout 15;       # Время ожидания, если второй узел "отстающий".
        become-primary-on both;    # Разрешить любому узлу стать primary (управляется Pacemaker).
    }
    net {
        cram-hmac-alg sha1;        # Алгоритм аутентификации сетевого трафика.
        shared-secret "secret-phrase"; # Секретная фраза для аутентификации.
        after-sb-0pri discard-zero-changes;
        after-sb-1pri discard-secondary;
        after-sb-2pri disconnect;
        max-buffers 36k;
        max-epoch-size 20k;
        sndbuf-size 1024k;
        rcvbuf-size 2048k;
    }
    syncer {
        rate 100M;                 # Ограничение скорости синхронизации (Мбит/с). Настройте под свою сеть.
        verify-alg sha1;           # Алгоритм проверки целостности данных.
    }
    on node1 {                     # Имя первого узла (должно совпадать с выводом `uname -n`).
        device /dev/drbd0;         # Создаваемое блочное устройство DRBD.
        disk /dev/sdb1;            # Физический диск или раздел на этом узле.
        address 10.0.0.1:7789;     # IP-адрес и порт для подключения (используйте сеть репликации).
        meta-disk internal;        # Метаданные хранятся на том же диске.
    }
    on node2 {
        device /dev/drbd0;
        disk /dev/sdb1;
        address 10.0.0.2:7789;
        meta-disk internal;
    }
}

3. Инициализируйте метаданные DRBD и запустите ресурс.

Выполните на обоих узлах:

drbdadm create-md nfs
drbdadm up nfs

4. На одном из узлов (например, node1) выполните принудительное назначение роли Primary и начните начальную синхронизацию.

drbdadm primary nfs --force

5. Проверьте статус синхронизации. Дождитесь состояния UpToDate/UpToDate.

drbdadm status nfs
# cat /proc/drbd

6. На активном узле (node1) создайте файловую систему на устройстве DRBD. Используйте XFS для больших томов или ext4 для стандартных случаев.

mkfs.ext4 /dev/drbd0
# или
# mkfs.xfs /dev/drbd0

Настройка кластера Pacemaker с Corosync

1. Аутентифицируйте узлы в кластере. Выполните на любом узле (например, node1).

pcs host auth node1 node2 -u hacluster -p 'your_secure_password'

2. Создайте и запустите кластер.

pcs cluster setup my-nfs-cluster node1 node2 --force
pcs cluster start --all
pcs cluster enable --all

3. Отключите ненужные функции STONITH (отключение "зависшего" узла) и Quorum (принятие решений большинством голосов) для тестовой конфигурации из двух узлов. В production STONITH обязателен.

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

4. Проверьте состояние кластера.

pcs status

Вы должны увидеть, что оба узла онлайн.

Добавление и настройка ресурсов кластера в правильном порядке

Ресурсы добавляются с учетом зависимостей. Файловая система не может смонтироваться, пока нет устройства DRBD. NFS-сервер не запустится без смонтированной файловой системы. VIP должен быть на том же узле, где работает NFS.

1. Создайте ресурс для устройства DRBD. Pacemaker будет управлять его ролью (Promote/Demote).

pcs resource create drbd_nfs ocf:linbit:drbd drbd_resource=nfs \
    op monitor interval=15s role=Master \
    op monitor interval=30s role=Slave

2. Создайте мастер/слейв ресурс из ресурса DRBD. Это позволит Pacemaker понимать, на каком узле устройство в режиме Primary (Master).

pcs resource master ms_drbd_nfs drbd_nfs \
    master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true

3. Создайте ресурс для монтирования файловой системы. Укажите точку монтирования, например, /mnt/nfs_share.

pcs resource create nfs_fs ocf:heartbeat:Filesystem \
    device=/dev/drbd0 directory=/mnt/nfs_share fstype=ext4 \
    op monitor interval=20s

4. Создайте ресурс для демона NFS-сервера.

pcs resource create nfs_server ocf:heartbeat:nfsserver \
    nfs_shared_infodir=/mnt/nfs_share/nfsinfo \
    op monitor interval=30s

5. Создайте ресурс виртуального IP-адреса. Используйте адрес из вашей клиентской сети.

pcs resource create vip_nfs ocf:heartbeat:IPaddr2 \
    ip=192.168.1.100 cidr_netmask=24 \
    op monitor interval=10s

6. Настройте зависимости и порядок запуска ресурсов. Это самая важная часть конфигурации.

# Файловая система зависит от мастер-ресурса DRBD
pcs constraint order promote ms_drbd_nfs then start nfs_fs
pcs constraint colocation add nfs_fs with ms_drbd_nfs INFINITY

# NFS-сервер зависит от смонтированной файловой системы
pcs constraint order start nfs_fs then start nfs_server
pcs constraint colocation add nfs_server with nfs_fs INFINITY

# VIP зависит от работающего NFS-сервера
pcs constraint order start nfs_server then start vip_nfs
pcs constraint colocation add vip_nfs with nfs_server INFINITY

7. Настройте NFS-экспорт. Создайте файл /etc/exports на обоих узлах. Содержимое должно быть идентичным.

/mnt/nfs_share 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

8. Проверьте конфигурацию всех ресурсов.

pcs status resources
pcs status

Все ресурсы должны быть запущены на одном узле (Master). Второй узел будет в состоянии Slave для DRBD и остановлен для остальных ресурсов.

Для глубокого понимания принципов работы кластера и управления ресурсами рекомендуем наше подробное руководство «Построение отказоустойчивого кластера на Linux с Corosync и Pacemaker». В нем разобраны тонкости настройки, мониторинга и устранения типичных проблем.

Проверка работы кластера и тестирование отказоустойчивости

Перед вводом кластера в эксплуатацию необходимо убедиться в его корректной работе и отработать сценарий переключения.

Базовые команды для проверки состояния кластера

Используйте эти команды для оперативного мониторинга:

pcs status - общий статус кластера, узлов и ресурсов.
pcs resource status - детальный статус каждого ресурса.
drbdadm status nfs - статус репликации DRBD (должно быть UpToDate/UpToDate).
mount | grep drbd - проверка, что файловая система смонтирована.
showmount -e 192.168.1.100 - проверка списка экспортов через виртуальный IP. Выполните с клиентской машины.
systemctl status nfs-server - статус службы NFS на активном узле.

Сценарий тестирования: имитация сбоя узла и проверка переключения

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

Шаг 1: Определение активного узла и подготовка.

pcs status | grep -A1 "Node List"

Запомните, какой узел отмечен как онлайн и на нем запущены ресурсы (Master). Предположим, это node1.

Шаг 2: Проверка доступности NFS с клиента.

С клиентской машины в сети 192.168.1.0/24 выполните:

mkdir -p /mnt/test_nfs
mount -t nfs 192.168.1.100:/mnt/nfs_share /mnt/test_nfs
touch /mnt/test_nfs/test_file_$(date +%s).txt
df -h /mnt/test_nfs

Убедитесь, что монтирование прошло успешно и файл создан.

Шаг 3: Имитация сбоя активного узла.

На активном узле (node1) выполните команду, которая заставит Pacemaker считать узел недоступным:

pcs cluster stop node1
# Или более жесткий вариант (симуляция полного падения):
# systemctl stop pacemaker corosync

Шаг 4: Наблюдение за автоматическим переключением.

Немедленно перейдите на второй узел (node2) и начните мониторить статус:

watch -n 1 pcs status

В течение 30-60 секунд вы должны увидеть, что:

Узел node1 переходит в состояние offline.
Ресурс DRBD на node2 переходит в роль Master (Promoted).
Последовательно запускаются ресурсы Filesystem, nfsserver и VIP на node2.

Проверьте статус репликации на node2: drbdadm status nfs (должно быть Primary/Unknown).

Шаг 5: Проверка доступности NFS после переключения.

Не размонтируя папку на клиенте, проверьте, что тестовый файл на месте и доступен для записи:

ls -la /mnt/test_nfs/
touch /mnt/test_nfs/another_file_after_failover.txt

Клиент должен продолжить работу. Кратковременная пауза (stall) во время переключения возможна, но соединение не должно разрываться при использовании опции hard mount (по умолчанию).

Шаг 6: Восстановление исходного узла и проверка реинтеграции.

Запустите кластерные службы на node1:

pcs cluster start node1

Pacemaker должен обнаружить, что узел вернулся в строй. Ресурс DRBD на node1 перейдет в роль Secondary, и начнется синхронизация изменений, произошедших на node2. Проверьте статус синхронизации: drbdadm status nfs на любом узле.

После успешного теста размонтируйте ресурс на клиенте: umount /mnt/test_nfs.

Этот сценарий подтверждает, что кластер выполняет свою основную функцию: обеспечивает непрерывную доступность сервиса. Для построения более сложных распределенных систем хранения, таких как Ceph или GlusterFS, которые также обеспечивают отказоустойчивость и масштабируемость, изучите наше руководство по программно-определяемому хранилищу (SDS).

Резюме и рекомендации для продакшн-среды

Вы развернули отказоустойчивый кластер NFS, который гарантирует целостность данных через синхронную репликацию DRBD и доступность сервиса через автоматическое переключение ресурсов Pacemaker. Клиенты получают доступ к данным через единый виртуальный IP-адрес, что упрощает конфигурацию инфраструктуры.

Для эксплуатации в production-среде примите во внимание следующие рекомендации:

Включите STONITH. В рабочем кластере обязательна настройка STONITH (Shoot The Other Node In The Head) для гарантированного отключения "зависшего" узла и предотвращения split-brain ситуации. Используйте аппаратные средства управления (IPMI, iDRAC) или агенты для гипервизоров (например, fence_vmware_soap).
Настройте мониторинг. Интегрируйте кластер в систему мониторинга (Zabbix, Prometheus). Отслеживайте ключевые метрики: статус ресурсов Pacemaker (pcs status), состояние репликации DRBD, использование дискового пространства, доступность NFS-экспортов.
Планируйте нагрузку. Убедитесь, что standby-узел имеет достаточные ресурсы (CPU, RAM, IOPS) для работы всей нагрузки после переключения. В идеале архитектура должна быть Active-Passive.
Регулярно тестируйте отказоустойчивость. Проводите плановые учения по переключению (failover) в maintenance-окна, чтобы убедиться в работоспособности процедуры и подготовить персонал.
Документируйте конфигурацию. Сохраните все конфигурационные файлы (DRBD, Pacemaker, exports) в системе контроля версий. Задокументируйте IP-адреса, пароли (в secure store) и процедуры восстановления.
Резервное копирование. Несмотря на репликацию, реализуйте регулярное резервное копирование данных с NFS-шары на независимое хранилище. Репликация защищает от сбоя оборудования, но не от логических ошибок (удаление файлов, ransomware).

Данное решение идеально подходит для обеспечения высокой доступности файловых сервисов в рамках одной площадки. Для построения географически распределенных кластеров или реализации аварийного восстановления (Disaster Recovery) между дата-центрами потребуются дополнительные технологии, такие как асинхронная репликация. Основы проектирования таких систем и стратегии аварийного переключения (failover) подробно разобраны в нашей статье об аварийном переключении (failover) на 2026 год.

Для автоматизации рутинных задач настройки и интеграции различных сервисов в вашей инфраструктуре вы можете использовать единый API-доступ к современным языковым моделям через сервис AiTunnel. Он позволяет быстро генерировать скрипты, проверять конфигурации или получать консультации по сложным сценариям, используя модели GPT, Gemini и другие.