Настройка GlusterFS: распределённое хранилище для production-кластеров

Отметим: когда данные растут до десятков терабайт, а число параллельных запросов NFS-сервера превышает 50–100, традиционные NAS упираются в пропускную способность одного контроллера. Ещё хуже — единая точка отказа: сбой контроллера обесточивает всё хранилище. GlusterFS решает обе проблемы: строится на обычных x86-серверах без дорогих SAN-контроллеров, а распределённая архитектура устраняет single point of failure. Мы внедряем GlusterFS для проектов, где нужна надёжность при экономии до 70% на оборудовании по сравнению с проприетарными SAN. Свяжитесь с нами — мы спроектируем кластер под ваши задачи.

Как выбрать тип тома GlusterFS?

Это самое важное решение при настройке GlusterFS. Неправильный тип тома — переделывать всё с нуля.

Replicated — каждая запись копируется на N нод. Подходит для небольших кластеров где важна надёжность. При двух нодах — полное зеркало. При трёх нодах — replica 3, что позволяет выйти одной ноде без потери доступа.

Distributed — файлы распределяются между нодами по хэшу. Масштабирует пространство, но при отказе ноды теряются файлы, которые на ней хранились. Без репликации — только для некритичных данных.

Distributed-Replicated — комбинация: файлы распределяются по группам нод, внутри группы — реплицируется. Стандартный выбор для production-кластеров от 4 нод. В сравнении с чистым Distributed этот тип тома обеспечивает отказоустойчивость в 2 раза лучше (replica 2) или в 3 раза (replica 3), хотя требует вдвое или втрое больше дискового пространства.

Почему Distributed-Replicated — стандарт для production?

Для production-кластеров от 4 нод Distributed-Replicated даёт баланс между ёмкостью и надёжностью. В отличие от чистого Distributed, потеря ноды не приводит к потере данных — реплика внутри группы сохраняет копии. Риск потери данных снижается в 2 раза (replica 2), а пропускная способность растёт линейно с числом нод: добавление 4 нод увеличивает производительность I/O на 200% при правильном rebalance. Закажите развёртывание GlusterFS под ключ — мы настроим тома с учётом ваших нагрузок.

gluster volume create vol-data \
  replica 2 \
  server1:/data/brick1 \
  server2:/data/brick1 \
  server3:/data/brick1 \
  server4:/data/brick1

Подготовка нод и установка

1. На каждом сервере установите glusterfs-server:

   apt install glusterfs-server systemctl enable --now glusterd 

2. Кирпич (brick) должен быть на отдельном разделе — не на системном диске:

   mkfs.xfs -i size=512 -n size=8192 /dev/sdb1
   mkdir -p /data/brick1
   echo '/dev/sdb1 /data/brick1 xfs defaults,noatime,inode64 0 0' >> /etc/fstab
   mount -a

3. Связываем ноды в кластер и создаём том с оптимизациями:

   gluster peer probe server2
   gluster peer probe server3
   gluster peer probe server4
   gluster peer status
   gluster volume create vol-data replica 2 transport tcp \
       server1:/data/brick1/vol-data \
       server2:/data/brick1/vol-data \
       server3:/data/brick1/vol-data \
       server4:/data/brick1/vol-data
   gluster volume set vol-data auth.allow '192.168.10.*'
   gluster volume set vol-data performance.cache-size 1GB
   gluster volume set vol-data performance.io-thread-count 32
   gluster volume set vol-data network.ping-timeout 10
   gluster volume set vol-data cluster.heal-timeout 300
   gluster volume start vol-data

   performance.cache-size 1GB — кэш метаданных, io-thread-count 32 — параллельные потоки I/O. Для серверов с медленными дисками уменьшайте, для NVMe-массивов увеличивайте.

   Как монтировать том на клиентах с отказоустойчивостью?

   Нативный GlusterFS-клиент предпочтительнее NFS:

   apt install glusterfs-client
   # В /etc/fstab server1:/vol-data /mnt/gluster glusterfs defaults,_netdev,backup-volfile-servers=server2:server3 0 0
   

   backup-volfile-servers — если server1 недоступен, клиент получит конфигурацию тома с резервных серверов. Без этого параметра при недоступности первого сервера монтирование упадёт даже если остальные ноды живы.

   Мониторинг и восстановление реплик

   GlusterFS автоматически восстанавливает реплики после возвращения ноды в строй. Процесс контролируется: gluster volume heal vol-data info, gluster volume heal vol-data info split-brain, gluster volume status vol-data detail и gluster volume profile vol-data start. Как указано в официальном руководстве GlusterFS, split-brain возникает, когда реплики расходятся и система не может определить правильную версию файла. Лечится вручную: gluster volume heal vol-data split-brain source-brick server1:/data/brick1/vol-data /path/to/file. Для мониторинга в Prometheus используйте gluster_exporter. Для развёртывания в Kubernetes можно применить Helm 3.

   Дополнительные настройки производительности

   Для больших кластеров оптимизируйте сетевые параметры: увеличьте network.ping-timeout до 30 и настройте performance.parallel-reads и performance.write-behind. При использовании NVMe установите performance.io-thread-count до 64. Эти параметры могут увеличить пропускную способность до 15%.

   Что входит в работу?

   • Аудит текущей инфраструктуры и проектирование топологии кластера
   • Развёртывание нод, настройка бриков, создание томов
   • Настройка мониторинга (Prometheus + Grafana с готовыми дашбордами)
   • Интеграция с существующей системой CI/CD и Ansible-плейбуки для воспроизводимости
   • Документация по обслуживанию и восстановлению
   • Обучение инженеров заказчика

   Наша команда имеет 5+ лет опыта внедрения GlusterFS в продакшене, реализовано 30+ проектов. Средний срок развёртывания кластера из 4 нод — 3 дня. Обеспечиваем 24/7 поддержку на всех этапах. GlusterFS обходится в 3-5 раз дешевле коммерческих SAN-решений при сопоставимой производительности. Получите консультацию — оценим проект.

   Проблемы и их решения

   После добавления нод обязательно запустите rebalance, иначе производительность не вырастет. Используйте gluster volume rebalance vol-data start. Если клиент не может смонтировать том после перезагрузки, несмотря на _netdev, добавьте в systemd unit монтирования параметры After=network-online.target и Wants=network-online.target.

   Сроки

   Сценарий	Время
   Кластер 2-3 ноды, базовая настройка	1-2 дня
   Кластер 4+ нод с мониторингом	2-3 дня
   Миграция данных на существующий кластер	+1-2 дня

   Стоимость рассчитывается индивидуально после аудита инфраструктуры. Для типового кластера из 4 нод стоимость начинается от $2.2k–3.2k. Оценим проект — свяжитесь с нами, подберём оптимальную конфигурацию.