Налаштування GlusterFS: розподілене сховище для production

Відзначимо: коли дані зростають до десятків терабайт, а число паралельних запитів NFS-сервера перевищує 50–100, традиційні NAS впираються в пропускну здатність одного контролера. Ще гірше — єдина точка відмови: збій контролера знеструмлює все сховище. GlusterFS вирішує обидві проблеми: будується на звичайних x86-серверах без дорогих SAN-контролерів, а розподілена архітектура усуває single point of failure (NoSPOF). Ми впроваджуємо GlusterFS для проєктів, де потрібна надійність при економії до 70% на обладнанні порівняно з пропрієтарними SAN. Середня вартість розгортання кластера з 4 нод — 1500 євро. Надаємо гарантію 12 місяців на конфігурацію; всі інженери сертифіковані за програмою Red Hat. GlusterFS обробляє запити на 50% швидше, ніж традиційний NFS при 100+ паралельних з'єднаннях.

Як вибрати тип тому 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 недоступний, клієнт отримає конфігурацію тому з резервних серверів. Без цього параметра при недоступності першого сервера монтування впаде навіть якщо інші ноди живі.

   Моніторинг та відновлення реплік (self-heal)

   GlusterFS автоматично відновлює репліки після повернення ноди в стрій (self-heal). Процес контролюється: 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 дні

   Вартість розраховується індивідуально після аудиту інфраструктури. Оцінимо проєкт — зв'яжіться з нами, підберемо оптимальну конфігурацію.