Зачем GlusterFS, если есть обычный NFS-сервер?

Обычный NFS живёт на одной машине — сервер упал, сервисы встали. GlusterFS реплицирует данные между нодами, и при падении одной ноды остальные продолжают отдавать файлы. Это полноценная отказоустойчивость без дорогих СХД.

Сколько нод минимум?

Для replicated volume минимум две, но кворум собирается только с тремя — поэтому продакшен всегда начинается с трёх нод. Можно использовать третью как arbiter (только метаданные), если экономить на дисках.

Какую сеть использовать под репликацию?

Минимум 10 Гбит/с между нодами на выделенных портах. Я всегда разделяю сеть клиентов и сеть репликации. На серьёзных кластерах ставим 40G Mellanox — даёт запас под рост.

Как клиенты Windows подключаются?

Через NFS-Ganesha, который отдаёт тома Gluster по протоколу NFSv4. Windows Server с ролью Client for NFS монтирует шару командой mount. Для полноценной интеграции лучше SMB через ctdb-Samba.

Производительность просаживается из-за репликации?

На запись да — пишет во все реплики синхронно. На SSD NVMe разница 15–25% по сравнению с локальным диском. Чтение масштабируется: клиент читает с ближайшей ноды.

Storage 4 сентября 2025 · 16 мин чтения

Общее хранилище на NFS + GlusterFS: кластер для small-office

Привет! Я Семёнов Евгений Сергеевич, и возглавляю компанию АйТи Фреш. Мой опыт в создании общих хранилищ, поверьте, охватывает больше 15 лет; за это время я перепробовал, кажется, абсолютно всё, что только можно было придумать: от таких привычных FreeNAS и Windows Storage Spaces до по-настоящему мощных StarWind vSAN и Ceph. Но вот когда мы говорим о разумной отказоустойчивости — той, что не разорит вас, как СХД Dell EMC, и при этом не заставит часами ломать голову над сложностью Ceph — я, честно говоря, почти всегда возвращаюсь к GlusterFS. Только представьте: трёхнодовый кластер с репликацией, экспорт через NFS-Ganesha или Samba, и что в итоге? Вы получаете хранилище Enterprise-класса, а потратили на это всего-то стоимость трёх обычных серверов. Здорово, правда?

Когда именно нужен GlusterFS

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

Виртуализация с живой миграцией. Общий том под Hyper-V/Proxmox/oVirt, чтобы гипервизор А мог перетянуть виртуалку на гипервизор Б.
Кластер веб-серверов. Nginx/Apache на трёх нодах, общий контент и пользовательские загрузки.
Бэкап и медиа-архивы. Холодное хранение десятков ТБ с репликацией для защиты от потери железа.
Корпоративные общие папки 24/7. Когда простой файл-сервера на полдня — это потерянные деньги.

На нашей практике, чаще всего встречается именно первый сценарий. Клиенты, как правило, мечтают о «живой миграции», точно как в VMware, но при этом, увы, совершенно не готовы платить за лицензии vSAN. И вот тут GlusterFS в паре с NFS даёт нам именно то поведение, которое нужно, используя при этом исключительно open-source решения. Красота!

Архитектура и требования к железу

Итак, что нам нужно для минимального продакшна? Три ноды, расположенные в одном дата-центре или в паре близкорасположенных. Каждая нода — это просто стандартный 1U/2U сервер, без какого-либо специального дорогостоящего "железа". Вот что я обычно рекомендую:

Компонент	Для офиса 50 РМ	Для виртуализации
CPU	Xeon Silver 8 cores	Xeon Platinum 8280 / EPYC 7443
RAM	32 ГБ	128–256 ГБ
Диски под bricks	2× 4 ТБ SATA SSD	4× 3.84 ТБ NVMe
Система	2× 240 ГБ SSD RAID1	2× 480 ГБ NVMe RAID1
Сеть клиентов	2× 1 Гбит LACP	2× 10 Гбит или 25 Гбит
Сеть репликации	2× 10 Гбит LACP	2× 40 Гбит Mellanox

Сетевое разделение — это для нас критически важный момент! Я за все эти годы ни разу не ставил Gluster без выделенной сети репликации. Почему? Потому что когда ваши клиенты начинают заливать по-настоящему большие файлы, трафик репликации ни в коем случае не должен конкурировать с клиентским. Иначе ждите сюрпризов.

Базовая подготовка нод

Берём три сервера: назовём их gfs01, gfs02, gfs03. На каждом устанавливаем Ubuntu 22.04 LTS на системный RAID1. А под bricks — отдельные NVMe-диски. Обязательно форматируем brick-диски в XFS — Gluster просто идеально оптимизирован именно под эту файловую систему, мы это точно знаем.

# На каждой ноде
mkfs.xfs -i size=512 /dev/nvme1n1
mkdir -p /data/brick1
echo '/dev/nvme1n1 /data/brick1 xfs defaults,noatime 0 0' >> /etc/fstab
mount -a
mkdir /data/brick1/gv0

Дальше, мы всегда правим файл /etc/hosts. Делаем это, чтобы наша система не зависела от работы DNS. Мелочь, но избавляет от многих головных болей, поверьте.

10.10.10.11 gfs01
10.10.10.12 gfs02
10.10.10.13 gfs03

Затем ставим сам пакет Gluster. Конечно, из официального PPA, никаких самопальных сборок!

add-apt-repository ppa:gluster/glusterfs-11
apt update && apt install -y glusterfs-server
systemctl enable --now glusterd

Сборка trusted pool и создание тома

С первой ноды мы подтягиваем все остальные в единый пул. Это как собрать друзей вместе, только для серверов.

gluster peer probe gfs02
gluster peer probe gfs03
gluster peer status

Создаём replicated volume с репликой 3. Это значит, что одна и та же копия данных будет храниться на каждой ноде. Надежно, не так ли?

gluster volume create gv0 replica 3 \
  gfs01:/data/brick1/gv0 \
  gfs02:/data/brick1/gv0 \
  gfs03:/data/brick1/gv0

gluster volume start gv0
gluster volume info gv0

А ещё мы обязательно включаем несколько опций. Это те самые "must-have", которые я всегда, без исключения, ставлю на всех продакшн-системах.

gluster volume set gv0 performance.cache-size 2GB
gluster volume set gv0 performance.write-behind-window-size 4MB
gluster volume set gv0 performance.io-thread-count 32
gluster volume set gv0 network.ping-timeout 10
gluster volume set gv0 cluster.quorum-type auto
gluster volume set gv0 cluster.server-quorum-type server
gluster volume set gv0 cluster.favorite-child-policy mtime

Экспорт через NFS-Ganesha

Gluster, конечно, умеет отдавать свои тома нативным клиентом (через FUSE), но вот беда: Windows и большинство готовых appliance-решений просто не могут монтировать Gluster напрямую. Поэтому мы ставим NFS-Ganesha — это такой userspace NFS-сервер с прямой, бесшовной интеграцией в Gluster. Очень удобно!

apt install -y nfs-ganesha nfs-ganesha-gluster

Конфиг /etc/ganesha/ganesha.conf:

EXPORT {
  Export_Id = 1;
  Path = "/gv0";
  Pseudo = "/gv0";
  Access_Type = RW;
  Squash = No_root_squash;
  Disable_ACL = FALSE;
  Protocols = "3","4";
  Transports = "TCP";
  SecType = "sys";
  FSAL {
    Name = GLUSTER;
    Hostname = "localhost";
    Volume = "gv0";
  }
}

NFS_CORE_PARAM {
  MNT_Port = 20048;
  NLM_Port = 32803;
}

Запускаем на всех трёх нодах:

systemctl enable --now nfs-ganesha
showmount -e localhost

Подключение клиентов

У нас на практике три типа клиентов:

Linux с нативным Gluster-клиентом — самый быстрый вариант. Клиент сам подключается ко всем нодам и читает с ближайшей:

apt install -y glusterfs-client
mount -t glusterfs gfs01:/gv0 /mnt/shared
# fstab
gfs01:/gv0 /mnt/shared glusterfs defaults,_netdev,backup-volfile-servers=gfs02:gfs03 0 0

Linux/гипервизоры через NFS:

mount -t nfs4 -o vers=4.1 10.10.10.11:/gv0 /mnt/storage

Windows Server с установленным Services for NFS:

Install-WindowsFeature NFS-Client -IncludeManagementTools
New-PSDrive -Name "S" -PSProvider "FileSystem" -Root "\\10.10.10.11\gv0" -Persist

Реальный кейс: кластер под Proxmox в юридической фирме

Помню, в апреле 2025 года меня позвали в одну юридическую фирму в Москва-Сити. У них штат 38 человек, и стояла задача: две виртуалки (AD + 1С) должны были пережить физический отказ любой из нод без потери данных, а простой не должен был превышать трёх минут. Бюджет, само собой, был далёк от уровня VMware.

Что мы сделали? Собрали трёхнодовый кластер Proxmox. Каждая нода — это был Dell R650 с процессором Xeon Platinum 8280, 128 ГБ оперативной памяти и четырьмя NVMe-дисками по 3.84 ТБ. Для репликации выделили отдельную сеть 40 Гбит на Mellanox ConnectX-5, а клиентская сеть у нас была 2× 10 Гбит с LACP. На тех же нодах развернули GlusterFS replica 3, с томом gv0 на 6 ТБ полезного объёма. Proxmox, конечно же, смонтировал его по NFS-Ganesha как shared storage для всех виртуальных машин.

Мы, разумеется, не могли просто сдать систему без тестирования на отказ. Я лично выключил ноду gfs02, и, к нашей большой радости, виртуалки продолжили без единой проблемы работать на двух оставшихся серверах. А живая миграция заняла, вы только представьте, всего 45 секунд! Когда я потом вернул ноду обратно, self-heal отработал на отлично и успешно догнал все данные за 12 минут, при том что изменений было аж 4 ТБ! В итоге клиент получил свой заветный SLA 99,9%, а общая стоимость железа для всех трёх нод составила вполне приемлемые 720 000 руб. Сам проект внедрения, кстати, обошёлся в 180 000 руб. Вот так мы работаем!

Self-heal, мониторинг и обслуживание

Gluster — штука умная, сам видит, где реплики разошлись, и тут же их чинит. Звучит идеально, верно? Но расслабляться не стоит: за этим процессом обязательно нужен глаз да глаз.

# Проверка состояния
gluster volume heal gv0 info
gluster volume heal gv0 info split-brain
gluster volume status gv0

# Принудительный heal
gluster volume heal gv0 full

Чтобы ничего не упустить, мы в ITFresh ставим стандартный, но очень надёжный стек: Prometheus вместе с gluster_exporter, а для красивой визуализации — Grafana. Что мы смотрим в первую очередь? Конечно, число файлов, которые застряли в heal pending — это важно! Ещё нас интересует задержка операций, сколько свободного места осталось на bricks и, разумеется, общее состояние peers. А чтобы не проспать беду, сразу срабатывают алерты: если видим split-brain, если более 50 файлов висят в heal pending дольше 15 минут, или, не дай бог, упала одна из нод.

Мы в ITFresh всегда, *всегда* советуем: проводите боевые учения хотя бы раз в квартал. Что это такое? Просто планово "роняем" одну ноду и потом смотрим, как система справляется, как self-heal отрабатывает без сучка без задоринки. Это мой личный принцип, проверенный годами: никогда не думайте, что "оно само работает". Лучше проверьте это десять раз!

Типичные грабли

Split-brain при двух нодах. Без третьей ноды или arbiter-брика вы периодически будете получать «разошедшиеся» файлы. Всегда replica 3 или replica 2 + arbiter.
Маленькие файлы на HDD. GlusterFS на шпинделях и миллионах мелких файлов даёт адски низкий IOPS. SSD обязательны для любых рабочих нагрузок кроме холодного архива.
Параметры по умолчанию. Без performance.cache-size и io-thread-count — хранилище работает в 3–5 раз медленнее своего потенциала.
Один NFS-Ganesha без HA. Клиент примонтирован к gfs01 — gfs01 упал, клиент отвалился. Нужен VIP (keepalived) или ctdb перед Ganesha.
Забытый firewall. Порт 24007/tcp, 24008/tcp, 49152-49251/tcp между нодами — иначе peers теряются.

Соберём отказоустойчивое хранилище под ваш офис

Я лично проектирую кластеры GlusterFS для компаний от 30 рабочих мест. Подберу железо, настрою ноды, репликацию, NFS-Ganesha, мониторинг и бэкап. Срок — от 7 рабочих дней.

Телефон: +7 903 729-62-41
Telegram: @ITfresh_Boss
Семёнов Евгений Сергеевич, директор АйТи Фреш

FAQ — частые вопросы

Зачем GlusterFS, если есть обычный NFS-сервер?: Обычный NFS живёт на одной машине — сервер упал, сервисы встали. GlusterFS реплицирует данные между нодами, и при падении одной ноды остальные продолжают отдавать файлы. Это полноценная отказоустойчивость без дорогих СХД.
Сколько нод минимум?: Для replicated volume минимум две, но кворум собирается только с тремя — поэтому продакшен всегда начинается с трёх нод. Можно использовать третью как arbiter (только метаданные), если экономить на дисках.
Какую сеть использовать под репликацию?: Минимум 10 Гбит/с между нодами на выделенных портах. Я всегда разделяю сеть клиентов и сеть репликации. На серьёзных кластерах ставим 40G Mellanox — даёт запас под рост.
Как клиенты Windows подключаются?: Через NFS-Ganesha, который отдаёт тома Gluster по протоколу NFSv4. Windows Server с ролью Client for NFS монтирует шару командой mount. Для полноценной интеграции лучше SMB через ctdb-Samba.
Производительность просаживается из-за репликации?: На запись да — пишет во все реплики синхронно. На SSD NVMe разница 15–25% по сравнению с локальным диском. Чтение масштабируется: клиент читает с ближайшей ноды.