GlusterFS — распределённая файловая система, которая собирает каталоги-«кирпичи» с нескольких серверов в один общий том. Клиенты монтируют его как обычную сетевую папку, а данные раскладываются по узлам без выделенного сервера метаданных. Здесь нет объектов и отдельного слоя блочных устройств: всё строится вокруг файлов и каталогов. Разберём установку, типы томов, монтирование, самовосстановление и диагностику.

Что даёт GlusterFS

Том выглядит как обычный каталог. Клиент обращается к любому узлу, а тот по хешу имени файла определяет, где хранятся данные. Метаданных нет, поэтому отказ сервера не блокирует доступ к файлам на других узлах.

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

Red Hat завершила коммерческую поддержку Gluster Storage в конце 2024 года, но community-проект жив, а пакеты есть в Debian, Ubuntu и AlmaLinux. Для нового проекта сравните решение с Ceph; для готового файлового сервера GlusterFS остаётся рабочим.

Кирпичи и типы томов

Единица хранения — brick: обычный каталог на файловой системе сервера, например /data/gluster/brick1. Из кирпичей собирают том. Базовая раскладка — distributed: файлы просто распределяются по кирпичам, избыточности нет, отказ узла означает потерю части данных.

Для отказоустойчивости используют replica: каждый файл хранится в трёх копиях. Полезная ёмкость при этом равна объёму одного кирпича из трёх. Есть dispersed — аналог RAID6 на уровне файлов, он экономит место, но требует больше процессора и памяти.

  • distributed — максимум места, без резервирования;
  • replicated — копии, простое восстановление, цена в кратном запасе дисков;
  • dispersed — эффективнее по ёмкости, сложнее в обслуживании;
  • distributed-replicated — несколько наборов реплик, ёмкость растёт наборами.

Подготовка узлов

Возьмите три сервера с одинаковыми путями и версиями. Имена должны резолвиться через DNS или /etc/hosts, время — синхронизироваться. Откройте порты 24007–24008 и диапазон 49152–49251 для кирпичей; в облаке разрешите этот трафик только между узлами.

sudo apt install glusterfs-server
sudo systemctl enable --now glusterd
sudo gluster peer probe node2
sudo gluster peer probe node3

После добавления проверьте gluster peer status: все узлы должны быть Peer in Cluster. Если узел disconnected, смотрите /var/log/glusterfs/glusterd.log — обычно виноваты firewall, разные версии или совпавший UUID после клонирования ВМ.

Создание тома

Кирпичи создаются на каждом сервере отдельно, затем том собирается одной командой. Для реплики три число кирпичей должно быть кратно трём.

sudo mkdir -p /data/gluster/brick1
sudo gluster volume create gv0 replica 3 \
  node1:/data/gluster/brick1 node2:/data/gluster/brick1 \
  node3:/data/gluster/brick1
sudo gluster volume start gv0
sudo gluster volume info gv0

Параметр force нужен, только если кирпич не пуст; применять его без причины опасно. После старта проверьте gluster volume status: все кирпичи должны быть Online, процессы запущены.

Задайте таймаут и владельца файлов, чтобы клиенты быстрее замечали обрыв.

sudo gluster volume set gv0 network.ping-timeout 10
sudo gluster volume set gv0 storage.owner-uid 1000
sudo gluster volume set gv0 storage.owner-gid 1000
sudo gluster volume get gv0 all

Монтирование на клиентах

Клиент — любой Linux с пакетом glusterfs-client. Точка монтирования указывает на имя тома, а резервные серверы перечисляются в опциях, чтобы обрыв узла не ронял доступ.

sudo apt install glusterfs-client
sudo mkdir -p /mnt/gv0
sudo mount -t glusterfs node1:/gv0 /mnt/gv0
findmnt -t fuse.glusterfs

В /etc/fstab добавьте _netdev и backup-volfile-servers, иначе том будет монтироваться до поднятия сети и загрузка зависнет.

node1:/gv0 /mnt/gv0 glusterfs _netdev,backup-volfile-servers=node2:node3 0 0
sudo mount -a
df -h /mnt/gv0

FUSE-клиент совместим почти везде, но не монтируйте один том сотнями хостов ради мелких операций: нагрузка на кирпичи растёт. Для веб-приложений с общими файлами иногда разумнее NFS-Ganesha поверх тома.

Самовосстановление и замена кирпича

После возврата узла в строй его данные могут отставать. Демон self-heal сверяет копии, очередь видна в heal info; при большом объёме лечение идёт часами, поэтому его планируют на окно обслуживания.

sudo gluster volume heal gv0 info
sudo gluster volume heal gv0 info summary
sudo gluster volume heal gv0 full
sudo gluster volume heal gv0 statistics

Замена диска — replace-brick: новый кирпич принимает данные, затем фиксируется. Добавление ёмкости — add-brick, число новых кирпичей кратно числу реплик.

sudo gluster volume replace-brick gv0 node1:/data/gluster/brick1 node4:/data/gluster/brick1 commit force
sudo gluster volume add-brick gv0 replica 3 node5:/data/gluster/brick1 node6:/data/gluster/brick1 node7:/data/gluster/brick1
sudo gluster volume rebalance gv0 start
sudo gluster volume rebalance gv0 status

Rebalance после add-brick не обязателен: новые файлы пойдут на новые кирпичи по хешу. Он нужен лишь для выравнивания заполнения. После replace-brick дождитесь завершения и только потом удаляйте диск.

Диагностика и split-brain

Самая частая авария в реплике — split-brain: копии файла разошлись, и том блокирует доступ, чтобы не отдать противоречивые данные. Нужно решить, какая копия верная; автоматически выбирать «последнюю» нельзя.

sudo gluster volume heal gv0 info split-brain
sudo getfattr -d -m . -e hex /data/gluster/brick1/file.txt
sudo gluster volume heal gv0 split-brain source-brick node2:/data/gluster/brick1
sudo gluster volume heal gv0 info

Второй набор проблем — производительность. Включите профилирование, снимите статистику, затем выключите: постоянный сбор данных создаёт нагрузку.

sudo gluster volume profile gv0 start
sudo gluster volume profile gv0 info
sudo gluster volume status gv0 detail
sudo gluster volume profile gv0 stop

Если узкое место в мелких файлах, помогает кэш и отключение лишних опций, но сначала проверьте сеть и диск. Следите за заполнением кирпичей: переполнение одного останавливает запись во весь том.

Чек-лист

  • Три и более узла, одинаковые версии и пути кирпичей.
  • Синхронизация времени, DNS и порты 24007–24008, 49152–49251 открыты.
  • Том replicated с числом кирпичей, кратным трём.
  • На клиентах указаны backup-volfile-servers и _netdev.
  • Настроен мониторинг heal info и свободного места.
  • Проверено восстановление после отключения узла.
  • Есть регламент действий при split-brain.

Итог

GlusterFS даёт общий файловый том из обычных серверов и не требует слоя метаданных. Начните с трёх узлов и replicated-тома, проверьте отключение одного сервера, затем настройте контроль heal. Главные риски — split-brain, переполнение кирпича и медленное восстановление; они лечатся регламентом, а не магической настройкой. Для новых инсталляций сравните решение с Ceph, но GlusterFS по-прежнему уместен.

Насколько публикация полезна?

Нажмите на звезду, чтобы оценить!

Средняя оценка 0 / 5. Количество оценок: 0

Оценок пока нет. Поставьте оценку первым.

Поделиться: Telegram ВКонтакте