Storage · 16 мин чтения

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

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

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

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

В моей практике самый распространённый сценарий — первый. Клиенты хотят VMware-подобную живую миграцию, но без лицензий vSAN. GlusterFS + NFS отдаёт такое поведение на open-source стеке.

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

Минимальный продакшн — три ноды в одном дата-центре или в двух близкорасположенных. Каждая нода — обычный 1U/2U сервер, без специального hardware. Я рекомендую:

КомпонентДля офиса 50 РМДля виртуализации
CPUXeon Silver 8 coresXeon Platinum 8280 / EPYC 7443
RAM32 ГБ128–256 ГБ
Диски под bricks2× 4 ТБ SATA SSD4× 3.84 ТБ NVMe
Система2× 240 ГБ SSD RAID12× 480 ГБ NVMe RAID1
Сеть клиентов2× 1 Гбит LACP2× 10 Гбит или 25 Гбит
Сеть репликации2× 10 Гбит LACP2× 40 Гбит Mellanox

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

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

Три сервера: gfs01, gfs02, gfs03. Ubuntu 22.04 LTS на системном RAID1, отдельные NVMe под bricks. Форматируем 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

Включаем обязательные опции, которые я всегда ставлю на продакшн:

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С) должны переживать физический отказ любой из нод без потери данных и с простоем не более 3 минут. Бюджет — не VMware уровня.

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

Тестировали отказ: выключил ноду 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

На мониторинг я ставлю Prometheus с gluster_exporter и Grafana. Ключевые метрики: число файлов в heal pending, latency операций, свободное место на bricks, состояние peers. Алерты — на split-brain, более 50 файлов в heal pending в течение 15 минут, падение ноды.

Раз в квартал — учения: плановое выключение одной ноды, проверка что self-heal срабатывает. Никогда не полагайтесь на то, что «оно само работает» — проверяйте.

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

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

Я лично проектирую кластеры 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% по сравнению с локальным диском. Чтение масштабируется: клиент читает с ближайшей ноды.

Подпишитесь на рассылку ITfresh

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

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

ООО «АЙТИ-ФРЕШ», ИНН 7719418495, КПП 771901001. Юридический адрес: 105523, г. Москва, Щёлковское шоссе, д. 92, корп. 7. Контакт: info@itfresh.ru, +7 903 729-62-41. Оператор обрабатывает e-mail подписчика в целях рассылки информационных и рекламных материалов до момента отзыва согласия.