Распределённые и кластерные файловые системы в 2026 году: Ceph, GlusterFS, Lustre - архитектура, сравнение и выбор

Выбор между Ceph, GlusterFS и Lustre сводится к трём вопросам: какой доступ нужен приложению (POSIX, блочное устройство или S3), сколько узлов планируется и кто будет сопровождать систему. Короткий ответ для 2026 года: Ceph закрывает большинство задач, включая Kubernetes, объектное хранилище и общие файловые данные; Lustre берут там, где нужна предельная пропускная способность на крупных файлах и параллельный доступ; GlusterFS остаётся вариантом для небольших кластеров, где важнее простота развёртывания.

Различие лежит в архитектуре. В Ceph клиент не ищет данные через таблицу метаданных: место объекта вычисляет алгоритм CRUSH, поэтому узла-каталога не существует. В GlusterFS распределением управляет клиент по хешу от пути, серверов метаданных нет вообще. В Lustre метаданные обслуживают выделенные MDS/MDT, а данные разложены по OST, что даёт параллельный доступ к одному файлу с сотен клиентов одновременно.

Ниже разобраны архитектуры трёх систем, модели избыточности, эксплуатационная стоимость и сценарии Kubernetes, big data и HPC. Числа и требования дают ориентиры для планирования; перед закупкой сверяйте их с документацией конкретной версии и анонсами вендора: состав релизов и сроки поддержки меняются быстрее, чем архитектура.

Что такое распределённая и кластерная файловая система

Распределённая файловая система хранит данные на нескольких узлах, а клиенту показывает их как одно дерево каталогов. Кластерная ФС добавляет параллельный доступ: один файл читают и пишут несколько узлов одновременно. Термины часто смешивают, потому что Ceph, GlusterFS и Lustre совмещают оба свойства.

Чем распределённая ФС отличается от локальной и сетевой

Разница видна по трём признакам: где физически лежат блоки, сколько узлов обслуживают запросы и есть ли единое пространство имён.

Локальная ФС вроде ext4 или XFS не знает о сети: её можно экспортировать через NFS или SMB, но отказоустойчивости это не добавит. NAS-решение (NFS, SMB) удобно для общих каталогов, SAN (iSCSI, Fibre Channel) отдаёт блочные LUN под файловые системы виртуальных машин. У обоих классов ёмкость и производительность упираются в контроллер и его сеть.

Ключевой признак распределённой системы - данные распределены по узлам, а доступ идёт к единому пространству имён. Именно поэтому NFS поверх двух серверов с ручной синхронизацией остаётся сетевым решением, а не распределённым.

Ключевые свойства: масштабируемость, отказоустойчивость, единое пространство имён

• Масштабируемость. Горизонтальная модель добавляет узлы: OSD в Ceph, brick в GlusterFS, OST в Lustre. Каждый новый узел приносит диски, IOPS и сетевые порты. Вертикальная модель ограничена слотом и шиной одного сервера.
• Отказоустойчивость. Репликация или erasure coding плюс self-healing: вернувшийся в строй узел догоняет данные автоматически. Настройка failure domain определяет, переживёт ли массив отказ стойки, а не только диска.
• Единое пространство имён. Клиент видит один каталог независимо от того, на каком узле лежат блоки. В Ceph за файловый доступ отвечает MDS, в Lustre и GlusterFS метаданные распределены иначе.
• Параллельный доступ. Несколько клиентов читают один файл одновременно. Без этого невозможны MPI-IO и часть задач машинного обучения на кластере.

Распределённая ФС оправдана, когда одновременно выполняются три условия: данных больше, чем влезает в один сервер; нужна отказоустойчивость уровня стойки; нагрузка приходит с десятков клиентов. Материал ниже описывает архитектурные модели и типовые конфигурации: параметры конкретного стенда проверяйте на своём оборудовании, потому что поведение системы заметно зависит от дисков, сети и профиля ввода-вывода.

Архитектура Ceph: RADOS, CRUSH и компоненты кластера

Ceph строится на объектном хранилище RADOS, поверх которого работают три интерфейса доступа. Единого сервера метаданных для данных нет: место объекта вычисляется на клиенте. Подробный разбор компонентов и интерфейсов есть в отдельной статье Ceph как распределённая система хранения: вводное руководство.

RADOS и CRUSH: как данные распределяются по кластеру

RADOS (Reliable Autonomic Distributed Object Store) хранит объекты фиксированного размера, обычно 4 МиБ, внутри пулов. Объект попадает в placement group (PG), а PG раскладывается по OSD согласно CRUSH-карте. PG - единица балансировки и восстановления: чем их больше, тем ровнее нагрузка, но выше накладные расходы на отслеживание состояния. Рабочий ориентир - около 100 PG на один OSD с включённым автоскейлером.

CRUSH - детерминированная функция хеширования, а не таблица соответствий. Клиент сам вычисляет, какие OSD держат объект, поэтому при выходе узла из строя перераспределяется только его доля. В карте задают иерархию: root, rack, host, OSD. Если указать failure domain на уровне host, все копии окажутся в разных серверах, но могут лежать в одной стойке. Для отказоустойчивости уровня стойки или дата-центра иерархию расширяют до rack и datacenter.

Любое изменение карты запускает перебалансировку. Массовая миграция PG конкурирует с рабочей нагрузкой за сеть, поэтому операции с CRUSH-картой планируют на окно обслуживания и ограничивают скорость восстановления параметрами кластера.

Компоненты: MON, OSD, MDS, MGR и их роли

• MON хранит карты кластера (monitor, osd, pg) и держит кворум. Нужно нечётное число: 3 для теста и небольших установок, 5 для продакшена, распределённых по разным стойкам. Потеря кворума останавливает изменение карт, клиентские записи блокируются.
• OSD - демон плюс диск. Хранит объекты, реплицирует их, выполняет scrub для проверки контрольных сумм, участвует в восстановлении. Минимум для репликации 3 - три OSD на трёх разных узлах.
• MDS обслуживает метаданные CephFS. Схема active/standby даёт переключение без простоя; несколько активных MDS распределяют нагрузку на каталоги.
• MGR собирает метрики, отдаёт дашборд и запускает модули вроде балансировщика PG.

Состояние кластера проверяют одной командой:

ceph -s
ceph osd tree
ceph osd df tree
ceph pg stat

Минимальная рабочая конфигурация: 3 узла с MON, на каждом по 4-8 OSD, отдельная сеть для репликации. Плавный рост даёт 10 и более OSD на узел с NVMe-дисками и сетевыми картами 25 Гбит/с.

Интерфейсы Ceph: RBD, CephFS, RGW

RBD экономит на слое метаданных и даёт снапшоты и тонкое выделение места. CephFS добавляет полноценную POSIX-семантику, но требует минимум одного MDS с резервом. RGW превращает кластер в объектное хранилище: снаружи это S3-совместимый endpoint, за которым стоят пулы RADOS, а балансировкой трафика занимаются HAProxy или keepalived.

Архитектура GlusterFS: децентрализованный подход и томы

GlusterFS не использует сервер метаданных. Все узлы равноправны и знают друг о друге через glusterd, а клиент обращается к данным напрямую, чаще всего через FUSE. Распределение файлов вычисляется по хешу от пути: каталог или файл целиком лежит на одном brick, поэтому масштабирование идёт по числу кирпичей, а не по числу серверов метаданных.

Типы томов: distributed, replicated, dispersed

• Distributed. Файлы разложены по кирпичам, избыточности на уровне GlusterFS нет. Даёт ёмкость и суммарную пропускную способность, но отказ кирпича означает потерю части данных.
• Replicated. Каждая копия размещается на отдельном узле. Набор из двух или трёх реплик переживает отказ узла и лечится командой heal.
• Dispersed. Erasure coding: данные и контрольные блоки раскладываются по кирпичам, например 4+2. Экономит место по сравнению с тройной репликацией, но требует больше вычислений и сетевых обменов.
• Distributed-replicated. Комбинация: несколько наборов реплик, между которыми файлы распределяются по хешу.

gluster volume create gv0 replica 3 node1:/data/brick1 node2:/data/brick1 node3:/data/brick1
 gluster volume start gv0
 gluster volume status
 gluster volume heal gv0 info

Профиль нагрузки определяет тип тома. Для небольшого кластера с требованием отказоустойчивости подходит replicated, для архивов и больших объёмов - dispersed. Split-brain возникает, когда реплики одного набора расходятся и обе считают себя актуальными: лечится выбором источника через heal, а предотвращается кворумом узлов и запретом отключать больше одной реплики в наборе одновременно.

Отсутствие метаданных-сервера: плюсы и минусы

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

Разница с альтернативами проявляется на метаданных. В Ceph файловые метаданные обслуживает MDS, который можно масштабировать отдельно от OSD. В Lustre под это выделен MDT с быстрыми дисками. GlusterFS такой возможности не даёт, поэтому миллионы мелких файлов и высокая частота создания и удаления - не его сценарий. Клиент через FUSE добавляет заметные накладные расходы на каждую операцию по сравнению с ядерным клиентом Lustre.

Архитектура Lustre: параллельный доступ и HPC-ориентированность

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

Компоненты Lustre: MGS, MDS, OSS, клиенты

• MGS хранит конфигурацию файловой системы, из которой клиенты и серверы получают параметры при подключении. Часто совмещён с MDS на одном сервере.
• MDS и MDT обслуживают метаданные: имена, права, размещение полос, блокировки. MDT размещают на быстрых SSD или NVMe, потому что метаданные чувствительны к задержке.
• OSS и OST хранят данные. Каждый OST - отдельная файловая система под управлением сервера объектов; один OSS обслуживает несколько OST.
• Клиент Lustre - модуль ядра, подключаемый к файловой системе через LNet. Клиентов могут быть тысячи.

Схема с одним MDS уязвима: его отказ останавливает обращения к метаданным. В продакшене применяют резервирование MDS с кластерным менеджером и fencing, а также распределённые метаданные (DNE) с несколькими MDT, когда каталогов и файлов много. Минимальная тестовая конфигурация включает MGS+MDS, один OSS и одного-двух клиентов; для реальной работы OST поднимают на RAID-массивах, чтобы отказ диска не приводил к потере полос файла.

Параллельный доступ и striping: как Lustre достигает высокой производительности

Файл разбивается на полосы и записывается на несколько OST одновременно. Число полос (stripe count) и их размер (stripe size) задаются при создании файла или наследуются от каталога. Файл размером 1 ГиБ при stripe count 4 раскладывается на четыре OST, и читающая сторона получает суммарную пропускную способность всех четырёх.

lfs setstripe -c 4 /mnt/lustre/project/dataset
 lfs getstripe /mnt/lustre/project/dataset/file001
 lfs df -h

Параметры подбирают под профиль данных. Для крупных последовательных файлов выгодны 4-8 полос и размер полосы в диапазоне 1-4 МиБ: точное значение по умолчанию зависит от версии и настраивается на уровне файловой системы. Для миллионов мелких файлов лишние полосы вредят, и разумнее оставить stripe count равным 1. Это ключевая причина, по которой Lustre и аналитика мелких объектов плохо сочетаются.

Отказоустойчивость и модели хранения данных: репликация, erasure coding, self-healing

Репликация vs erasure coding: что выбрать

Ceph поддерживает оба механизма: replicated-пулы для задержко-чувствительных задач и erasure-coded пулы для объектных и файловых нагрузок. GlusterFS даёт выбор между replicated и dispersed томами. В Lustre избыточность строят на уровне RAID под каждым OST и на резервировании OSS и MDS, поэтому колонка про erasure coding к нему относится лишь косвенно - как к схеме хранения под файловой системой.

Практическое правило: случайные операции по 4 КиБ и очереди на запись выигрывают от репликации, последовательное чтение больших файлов и архивы выигрывают от erasure coding. Восстановление после отказа в erasure coding требует чтения и пересчёта блоков с множества узлов, что заметнее нагружает сеть.

Failure domain и кворум: как избежать потери данных

Failure domain задаёт границу, в которой допускается только одна копия. Если копии лежат на разных дисках одного сервера, отказ блока питания уносит данные целиком. В Ceph домен задаётся в CRUSH-карте на уровнях host, rack и datacenter; в GlusterFS реплики набора размещают на отдельных узлах и включают кворум серверов; в Lustre применяют пары failover и fencing для узлов метаданных.

Кворум определяет минимальное число узлов, при котором система продолжает работу. У Ceph три MON дают кворум из двух голосов. GlusterFS использует серверный кворум: если выжило меньше половины узлов, том переходит в режим только для чтения, что защищает от расхождения реплик. Split-brain, то есть одновременное изменение расходящихся копий, предотвращают кворумом, fencing и размещением реплик на разных стойках. Общая механика шардирования, репликации и проверки отказоустойчивости разобрана в материале Кластерные системы хранения и поиска данных: архитектура и примеры реализации.

Сложность развёртывания и эксплуатационные затраты

Ceph: cephadm, rook и порог входа

Официальный путь - cephadm: он запускает демоны в контейнерах, поэтому не требует ручной установки пакетов на каждый узел.

cephadm bootstrap --mon-ip 10.0.0.11
 ceph orch host add node2 10.0.0.12
 ceph orch apply osd --all-available-devices

Для Kubernetes применяют Rook: оператор создаёт кластер Ceph по манифесту и отдаёт CSI-драйверы для RBD и CephFS. Порог входа высокий: нужно понимать пулы, PG, CRUSH-карту и разницу между public-сетью и сетью репликации. Типичные ошибки новичков - один OSD на узел, отсутствие отдельной сети для репликации, выключенный автоскейлер PG и failure domain ниже уровня хоста. Тестовый кластер из трёх узлов поднимают за день-два, продакшн с нагрузочными испытаниями и прогоном отказов занимает недели.

GlusterFS: простота vs ограничения

Развёртывание проще: пакеты, запуск glusterd, добавление узлов в пул, создание тома. Опытный администратор собирает первый том за несколько часов, а полноценный стенд с проверкой отказов - за несколько дней. Ограничения проявляются позже: производительность на мелких файлах, медленный листинг больших каталогов, особенности POSIX-семантики при работе через FUSE. Отдельный вопрос - статус проекта и доступность пакетов в выбранном дистрибутиве.

Lustre: требования к инфраструктуре и персоналу

Lustre собирают вручную: форматируют MGT, MDT и OST, поднимают серверы, монтируют клиентов, настраивают LNet. Для работы нужны выделенные серверы метаданных, быстрые диски под MDT, избыточные массивы под OST и сеть с малой задержкой. На больших кластерах это InfiniBand или Ethernet 100 Гбит/с; на 10 и 25 Гбит/с получают скромные по меркам HPC результаты. Сопровождение требует отдельной экспертизы, поэтому многие организации покупают поддержку у вендора. Реалистичный срок запуска продакшн-инсталляции - недели и месяцы.

Сеть задаёт потолок для всех трёх систем. Ceph выигрывает от отдельной сети репликации на 25 Гбит/с и больше: восстановление после отказа OSD прокачивает объём данных, сопоставимый с диском. GlusterFS на 10 Гбит/с обслуживает небольшие кластеры, но распределённые тома с интенсивным обменом упираются в тот же лимит. Lustre требует низкой задержки, потому что метаданные и полосы файлов согласуются между MDS, OSS и клиентами. Детальное сравнение трёх систем по TCO и сложности сопровождения приведено в статье ZFS, Ceph и GlusterFS: сравнение программных систем хранения и выбор под задачу.

Сценарии применения: Kubernetes, big data, HPC

Kubernetes: Ceph Rook vs GlusterFS vs Lustre

Ceph через Rook и CSI закрывает оба профиля доступа: RBD для томов ReadWriteOnce и CephFS для ReadWriteMany. Оператор берёт на себя создание пулов, секретов и StorageClass, а кластер получает динамическое выделение томов и снапшоты. GlusterFS в Kubernetes опирается на CSI-плагин, но динамическое выделение исторически требовало Heketi, развитие которого остановлено; перед использованием проверяйте актуальное состояние драйвера. Для Lustre существуют CSI-реализации, но в типовых кластерах Kubernetes их почти не встречается из-за сложности сопровождения клиента на каждом узле.

Big data: Ceph RGW, GlusterFS и Lustre

Аналитические движки обычно работают с объектным хранилищем по S3 API: Ceph RGW понимает S3 и Swift, поддерживает мультитенантность и версионирование. GlusterFS годится для общих данных и промежуточных результатов, но не для сценариев с миллионами мелких объектов. Lustre применяют там, где аналитика идёт через MPI-IO и требует параллельного чтения крупных наборов. Практика разбиения больших массивов на слои и выбора хранилища под нагрузку разобрана в руководстве Хранение больших данных и массивов: технологии, сбор и миграция.

HPC: Lustre vs CephFS vs GlusterFS

Lustre остаётся рабочей лошадкой вычислительных центров: параллельный доступ, агрегированная пропускная способность в сотни гигабайт в секунду и проверенные схемы резервирования. Долю Lustre среди систем в рейтинге TOP500 стоит сверять с актуальной публикацией рейтинга, а не с пересказами. CephFS выступает альтернативой там, где нужна универсальность и один кластер под файловые, блочные и объектные задачи; метаданные при этом обслуживает MDS, и на миллионах файлов он требует горизонтального масштабирования. GlusterFS в HPC встречается редко из-за производительности на мелких файлах.

Когда распределённая ФС не нужна: локальные решения с репликацией

Распределённая система требует минимум трёх узлов, быстрой сети и человека, который будет её сопровождать. Если данных меньше десятка терабайт, а простой допустим в пределах часов, сложность не окупается.

Локальная ФС с репликацией: ZFS, DRBD, rsync

• ZFS. Снапшоты и отправка инкрементальных потоков через zfs send и zfs recv дают реплику без потери целостности. Контрольные суммы и scrub ловят битые блоки, снапшоты дают откат.
• DRBD. Репликация блочного уровня между двумя узлами. Синхронный режим подтверждает запись только после записи на обе стороны, поэтому задержка сети напрямую влияет на отклик.
• rsync. Простая периодическая копия. Даёт минимальные трудозатраты, но точка восстановления зависит от расписания: данные между копиями теряются.

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

NAS/SAN: NFS, iSCSI и их ограничения

NFS и SMB дают общий доступ к файлам с любого клиента, но упираются в производительность контроллера и остаются единой точкой отказа, если не предусмотрен резерв. iSCSI и Fibre Channel отдают блочные устройства для виртуальных машин и баз данных. Оба варианта не умеют восстанавливаться сами: реплика настраивается отдельным средством, а переключение часто требует вмешательства администратора. Для общих конфигураций, бэкапов и небольшого числа клиентов этого достаточно; при росте до десятков терабайт и требований по времени простоя выгоднее перейти на распределённую систему.

Практические критерии выбора и план внедрения

Чек-лист: как выбрать ФС под вашу задачу

1. Тип доступа: POSIX, блочное устройство или S3-совместимый API. Это первый фильтр: Lustre не даёт S3, GlusterFS не даёт блочных томов.
2. Профиль файлов: размер и количество. Миллионы мелких файлов исключают GlusterFS и требуют быстрых метаданных в Lustre или CephFS.
3. Объём и рост: сколько терабайт сейчас и через два года, сколько узлов придётся добавить.
4. Целевые метрики: задержка случайных операций, пропускная способность последовательного чтения, требуемые IOPS.
5. Восстановление: допустимое время простоя и точка восстановления. Они определяют схему избыточности и число реплик.
6. Сеть и железо: минимум 10 Гбит/с для небольшого кластера, 25 Гбит/с и отдельная сеть репликации для Ceph, InfiniBand или 100 Гбит/с для Lustre.
7. Люди: кто будет разбираться с CRUSH-картой, лечить split-brain в GlusterFS или сопровождать клиентов Lustre.
8. Поддержка: наличие вендорского сопровождения и план развития проекта, который нужно сверять с актуальными анонсами.
9. Интеграция: CSI для Kubernetes, S3A для Spark и Hadoop, MPI-IO для расчётов.

Быстрые выводы из этого списка: Kubernetes плюс S3 плюс отказоустойчивость уровня стойки означает Ceph; HPC с MPI-IO и крупными файлами означает Lustre; небольшой кластер с простыми требованиями означает GlusterFS или локальную ФС с репликацией.

Пилотный проект и нагрузочное тестирование

Пилот строят на минимальной конфигурации, но с реальными дисками и сетью. Порядок работ:

1. Сформулировать метрики успеха: IOPS и задержка на 4 КиБ случайного доступа, пропускная способность на 1 МиБ последовательного чтения, время восстановления после отказа узла.
2. Развернуть стенд: для Ceph три узла с 4-6 OSD, для GlusterFS три узла с replicated-томом, для Lustre MGS+MDS и один OSS.
3. Прогнать нагрузку: fio на случайный и последовательный ввод-вывод, mdtest или iozone для метаданных, mpirun для проверки параллельного доступа в Lustre.
4. Проверить отказы: выключить OSD, узел, диск и измерить, как проседает производительность и сколько занимает восстановление.
5. Настроить мониторинг: метрики кластера, задержки дисков, заполнение пулов, состояние кворума.
6. Зафиксировать план отката и порядок обновлений.

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

Актуальность и развитие технологий в 2026 году

Архитектура трёх систем меняется медленно, а состав релизов, сроки поддержки и доступность пакетов в дистрибутивах - быстро. Точные номера версий и даты окончания поддержки сверяйте в официальной документации проектов и анонсах вендоров: в этом материале они не приводятся как единственно верные.

Ceph: активное развитие и сообщество

Ceph выпускает крупные релизы примерно раз в год и поддерживает длительные ветки, поэтому для новых проектов выбирают версию с долгосрочной поддержкой. Экосистема шире, чем у конкурентов: cephadm для развёртывания без Kubernetes, Rook для кластеров, CSI-драйверы, интеграция с OpenStack. Практический вывод: Ceph - безопасный выбор для новых проектов, если в команде есть человек, готовый разобраться с пулами и CRUSH-картой.

GlusterFS: снижение поддержки и будущее

GlusterFS развивается усилиями сообщества: коммерческая поддержка крупного вендора была свёрнута, о чём стоит уточнять в актуальных анонсах. Пакеты для дистрибутивов выходят, исправления безопасности публикуются, но рассчитывать на быстрое закрытие сложных инцидентов по подписке не приходится. Практический вывод: GlusterFS разумно использовать, если система уже в эксплуатации или требования скромные, а команда знакома с технологией. Для новых проектов с высокими требованиями логичнее смотреть на Ceph.

Lustre: развитие в HPC и вендорская поддержка

Lustre развивается при участии вендоров, которые поставляют готовые системы и сопровождение, и остаётся основой вычислительных центров. Версии, поддерживаемые ветки и совместимость с сетями стоит проверять в документации проекта и у поставщика. Практический вывод: Lustre берут, когда нужна максимальная производительность на крупных файлах и есть бюджет на экспертизу; для Kubernetes и объектных хранилищ он не подходит.

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