данной инструкции рассматривается создание отказоустойчивого хранилища для директории /var/www с защитой от ситуации Split-Brain.
Наша архитектура (3 ноды):
Node 1 (Web1): 10.10.1.42 — Хранение реальных данных
Node 2 (Web2): 10.10.1.41 — Хранение реальных данных
Node 3 (ISPConfig): 10.10.1.43 — Arbiter (хранит только метаданные для кворума, диск может быть маленьким: 5–10 ГБ).
ШАГ 1. Подготовка LVM на нодахВыполняется на всех нодах, где выделен отдельный диск (например, /dev/sdb).
1.1. Создаем Physical Volume (PV):
pvcreate /dev/sdb1.2. Создаем Volume Group (VG):
vgcreate vg_gluster /dev/sdb1.3. Создаем Logical Volume (LV) на всю доступную емкость:
lvcreate -l 100%FREE -n lv_gluster vg_glusterШАГ 2. Форматирование и монтированиеВыполняется на всех нодах. GlusterFS рекомендует использовать файловую систему XFS.
2.1. Форматируем созданный том:
mkfs.xfs /dev/vg_gluster/lv_gluster2.2. Создаем точку монтирования:
mkdir -p /data/gluster2.3. Добавляем запись в /etc/fstab для автозапуска при загрузке (одной командой):
echo "/dev/vg_gluster/lv_gluster /data/gluster xfs defaults,noatime 0 0" | sudo tee -a /etc/fstab2.4. Монтируем диск:
systemctl daemon-reload
mount -aПроверяем
lsblkШАГ 3. Создание кирпича (Brick) — Важный нюанс!Выполняется на всех нодах.
ВНИМАНИЕ: Никогда не делайте корневую папку монтирования (/data/gluster) самим бриком. Запишите данные строго в подпапку.
3.1. Создаем подпапку под кирпич:
mkdir -p /data/gluster/brick13.2. Выставляем корректные права:
chown -R root:root /data/gluster
chmod -R 755 /data/glusterШАГ 4. Установка GlusterFSВыполняется на всех трех нодах.
apt update && apt install -y glusterfs-server
systemctl enable --now glusterdШАГ 5. Объединение нод в доверенный пул (Cluster)Выполняется строго только на первой ноде (10.10.1.42).
5.1. Добавляем вторую и третью ноды в кластер:
gluster peer probe 10.10.1.41
gluster peer probe 10.10.1.435.2. Проверяем статус подключения (статус должен быть Peer in Cluster (Connected)):
gluster peer status
ШАГ 6. Создание тома с типом ArbiterВыполняется на первой ноде (10.10.1.42).
ПРАВИЛО ОЧЕРЕДНОСТИ:
В схеме replica 3 arbiter 1 арбитром автоматически становится ПОСЛЕДНИЙ указанный в команде brick. Проверьте правильность IP-адресов перед запуском!
6.1. Создаем том webdata:
gluster volume create webdata replica 3 arbiter 1 10.10.1.42:/data/gluster/brick1 10.10.1.41:/data/gluster/brick1 10.10.1.43:/data/gluster/brick1 force6.2. Обязательно проверяем, что третья нода определилась именно как арбитр:
gluster volume infoВ выводе вы должны увидеть отметку: Brick3: 10.10.1.43:/data/gluster/brick1 (arbiter)
6.3. Запускаем созданный том:
gluster volume start webdata6.4. Проверяем рабочий статус тома:
gluster volume status
ШАГ 7. Монтирование тома на Web-ноды
Выполняется только на Web-нодах (10.10.1.42 и 10.10.1.41). На ISPConfig (ноде-арбитре) монтировать не нужно.
7.1. Создаем целевую директорию для сайтов:
mkdir -p /var/www7.2. Монтируем сетевую файловую систему GlusterFS:
mount -t glusterfs 10.10.1.42:/webdata /var/www7.3. Прописываем автоматическое монтирование после старта сети в /etc/fstab:
echo "10.10.1.42:/webdata /var/www glusterfs defaults,_netdev,backupvolfile-server=10.10.1.41:10.10.1.43 0 0" | sudo tee -a /etc/fstab
ШАГ 8. Тюнинг производительности для Web-окруженияВыполняется на первой ноде для оптимизации работы с мелкими файлами скриптов.
gluster volume set webdata performance.cache-size 256MB
gluster volume set webdata performance.write-behind on
gluster volume set webdata network.ping-timeout 5
ШАГ 9. Проверка репликации (Тест)На Node 1 создаем тестовый файл:
echo "GlusterFS Cluster Works" > /var/www/test.txtНа Node 2 проверяем его наличие и содержимое:
cat /var/www/test.txtЕсли текст отобразился — ваш отказоустойчивый кластер настроен правильно!
🛠 Возможные проблемы и их решениеОшибка:
Host 10.10.1.41 is not in 'Peer in Cluster' stateПричина:
Вы пытаетесь создать Volume до того, как ноды успешно установили связь друг с другом.
Решение: См. ШАГ 5.
Проверьте вывод
gluster peer status.
Если соединение отсутствует, убедитесь, что порты GlusterFS (24007, 49152 и далее) не заблокированы брандмауэром (ufw/iptables).
Ошибка:
Перепутали порядок нод при создании Volume (арбитром стала не та нода).
Решение: Пересоздайте том заново, выполнив команды:
gluster volume stop webdatagluster volume delete webdataПосле чего повторите ШАГ 6 с правильным порядком IP-адресов.
📊 Статус кластера и нод (Peers)
Посмотреть состояние подключений других нод к текущему серверу:gluster peer statusВывести список всех серверов, входящих в доверенный пул (включая локальный):
gluster pool listУдалить ноду из кластера (перед этим на ней нужно остановить все брики):
gluster peer detach [IP_или_ИМЯ_НОДЫ]
📂 Управление томами (Volumes)
Вывести список имен всех созданных томов:gluster volume listПоказать подробную конфигурацию тома (тип репликации, список кирпичей, опции):
gluster volume info [ИМЯ_ТОМА]Показать текущий статус тома (онлайн ли кирпичи, PID процессов, порты):
gluster volume status [ИМЯ_ТОМА]Остановить работу тома (необходимо перед удалением тома):gluster volume stop [ИМЯ_ТОМА]Полностью удалить том из системы (данные на дисках при этом не стираются автоматически):
gluster volume delete [ИМЯ_ТОМА]
🧱 Управление кирпичами (Bricks / "Дисками")
Посмотреть детальную информацию по дискам конкретного тома (размер, свободное место, inode):
gluster volume status [ИМЯ_ТОМА] detailЗаменить вышедший из строя или старый кирпич на новый без остановки кластера:
gluster volume replace-brick [ИМЯ_ТОМА] [СТАРЫЙ_IP:/путь] [НОВЫЙ_IP:/путь] commit forceОчистить расширенные атрибуты (xattrs) на директории кирпича, если вы принудительно пересоздаете заваленный том на старом месте:
setfattr -x trusted.glusterfs.volume-id /data/gluster/brick1setfattr -x trusted.gfid /data/gluster/brick1rm -rf /data/gluster/brick1/.glusterfs
📈 Мониторинг и диагностика (Профайлинг)Включить сбор статистики производительности для конкретного тома:gluster volume profile [ИМЯ_ТОМА] startПосмотреть текущую статистику (количество операций ввода-вывода, latency, чтение/запись):
gluster volume profile [ИМЯ_ТОМА] infoОстановить сбор статистики:
gluster volume profile [ИМЯ_ТОМА] stopПосмотреть информацию о заблокированных файлах (полезно при зависании процессов):
gluster volume statedump [ИМЯ_ТОМА]Файл дампа сохранится в директорию /var/run/gluster/ или /var/log/glusterfs/
🪵 Логи системыGlusterFS пишет детальные логи для каждого компонента отдельно. Найти их можно в системной директории:
Главный лог демона управления (ошибки подключения нод, создание томов):
tail -f /var/log/glusterfs/glusterd.logЛог конкретного кирпича (замените путь на ваш, точки заменяются дефисами):
tail -f /var/log/glusterfs/bricks/data-gluster-brick1.logЛог клиента на стороне монтирования (ошибки со стороны Web-нод):
tail -f /var/log/glusterfs/var-www.log
⚙️ Сброс настроек (Если всё сломалось)
Команда для принудительного снятия опций тюнинга и возврата к стандартным значениям:
gluster volume reset [ИМЯ_ТОМА] [НАЗВАНИЕ_ОПЦИИ]
Автоматическое восстановление данных (Self-Heal)
в GlusterFSВ реплицируемых томах (включая схемы с Arbiter) GlusterFS умеет автоматически восстанавливать согласованность данных. Если одна из нод уходила в офлайн (перезагрузка, сбой сети), а затем вернулась, механизм Self-Heal Daemon (shd) обнаружит разницу в метаданных и синхронизирует файлы.
ШАГ 1. Проверка статуса автоматического лечения
Выполняется на любой рабочей ноде.
По умолчанию в современных версиях GlusterFS функция лечения включена. Проверить её состояние можно командой:gluster volume info webdata
В выводе найдите строку cluster.self-heal-daemon. Она должна иметь значение on или enable.Если по какой-то причине демон выключен, включите его принудительно:
gluster volume set webdata cluster.self-heal-daemon on
ШАГ 2. Мониторинг процесса восстановленияЧтобы узнать, есть ли прямо сейчас файлы, ожидающие синхронизации (очередь на лечение), выполните:[
code]gluster volume heal webdata info[/code]
Интерпретация вывода:Если для каждого кирпича (Brick) написано Number of entries: 0 — все данные полностью синхронны, кластер здоров.Если число больше нуля — эти файлы прямо сейчас находятся в очереди на копирование.Посмотреть список файлов, которые заблокированы из-за критического рассинхрона (Split-Brain):
gluster volume heal webdata info split-brain
ШАГ 3. Ручной запуск лечения (Если нужно срочно)GlusterFS проверяет файлы при обращении к ним (клиентский self-heal) или по таймеру демона. Если вы только что включили упавшую ноду и хотите немедленно запустить полную проверку и синхронизацию всего тома, выполните:[
code]gluster volume heal webdata[/code]
Чтобы проверить состояние запущенного вручную процесса:
gluster volume heal webdata info healedШАГ 4. Тюнинг производительности леченияВыполняется на первой ноде.
Если на серверах хранятся миллионы мелких файлов (что часто бывает в /var/www у CMS вроде WordPress или Bitrix), стандартная скорость проверки может замедлять дисковую систему, либо наоборот — лечить слишком медленно.Регулировка количества потоков лечения (по умолчанию 1).
Увеличение ускорит синхронизацию, но поднимет нагрузку на CPU и диски:
gluster volume set webdata cluster.healer-count 4Включение ускоренного сканирования мелких файлов:
gluster volume set webdata performance. those-readdir-ahead on
🚨 Что делать, если файл попал в Split-Brain?Если две ноды одновременно записывали данные в один файл, пока связь между ними была разорвана, арбитр может не справиться, и файл заблокируется (ошибка ввода-вывода при попытке открыть).
Самый простой и безопасный способ решить это — сказать GlusterFS, какая из нод (выбираем по IP) содержит правильную/свежую версию файла, чтобы затереть устаревшую на другой ноде:
gluster volume heal webdata split-brain favorite-child-replica 10.10.1.42 /test.txtГде 10.10.1.42 — IP ноды с актуальными данными, а /test.txt — путь к проблемному файлу относительно корня тома.