ZFS, Ceph и GlusterFS: сравнение программных систем хранения и выбор под задачу

Что такое программные системы хранения и зачем сравнивать ZFS, Ceph и GlusterFS

Программные системы хранения (software-defined storage, SDS) работают на обычных серверах: избыточность, снапшоты и распределение данных обеспечивает софт, а не аппаратный контроллер. Вы покупаете диски, сеть и вычислительные узлы, а поведение хранилища описываете конфигурацией. Отсюда три следствия: рост ёмкости стоит как стоимость дисков, а не как новый модуль расширения у вендора; замена отказавшего узла не привязана к совместимости с прошивкой контроллера; один кластер обслуживает разные типы доступа.

ZFS, Ceph и GlusterFS рассматривают вместе, потому что все три ставятся на собственное железо, бесплатны в базовой поставке и умеют хранить данные с избыточностью. Уровень абстракции у них разный. ZFS - локальная файловая система и менеджер томов с контролем целостности. Ceph - распределённый кластер, который отдаёт объектное, блочное и файловое хранилище. GlusterFS - распределённая сетевая файловая система без центрального сервера метаданных.

Прямой ответ для тех, кто выбирает прямо сейчас. Один сервер или несколько независимых узлов, где важнее всего защита от порчи данных - ZFS. Единое пространство имён для блочных устройств виртуальных машин, S3-совместимого объектного хранилища и файловых шар - Ceph. Распределённый файловый сервер, который поднимается за вечер и масштабируется добавлением узлов при умеренной нагрузке - GlusterFS. Обратные утверждения тоже справедливы: Ceph избыточен для одного узла, ZFS не станет распределённой системой без внешних надстроек, а GlusterFS проигрывает на миллионах мелких файлов.

Тип доступа определяет протокол и архитектуру кластера, и путать их дорого. Чем объектное хранилище отличается от блочного и файлового, разобрано в отдельной статье про объектное, блочное и файловое хранилище: от этого зависит выбор между S3, iSCSI, NFS и SMB.

Архитектурные различия: как устроены ZFS, Ceph и GlusterFS

ZFS: пулы, наборы данных и целостность

ZFS строится вокруг пула (zpool), который объединяет диски в vdev-группы: зеркала или RAID-Z. Блоки записываются по принципу copy-on-write, каждый блок получает контрольную сумму, и при чтении ZFS сверяет её с содержимым. Если диск вернул битый блок, а в vdev есть избыточность, система восстанавливает данные из копий и перезаписывает повреждённый сектор. Так закрывается «тихое» повреждение данных, которое обычный RAID-контроллер не замечает.

Практические числа для планирования. Zpool из шести дисков в RAID-Z2 переживает отказ любых двух дисков, третий отказ до замены разрушит пул. Наборы данных (dataset) настраиваются отдельно: recordsize по умолчанию 128 КБ, для баз данных его снижают до 16 КБ; сжатие lz4 включают почти везде; снапшоты занимают место только под изменённые блоки. ARC кэширует чтения в оперативной памяти, и для массива на 100 ТБ разумно выделить 64-128 ГБ RAM. L2ARC на NVMe ускоряет повторные чтения, SLOG на быстром SSD снимает задержку синхронной записи с 5-10 мс до сотен микросекунд.

Ограничения тоже конкретны. Пул нельзя уменьшить, а расширение долго работало только добавлением целых vdev. В OpenZFS 2.3 появилось расширение raidz добавлением одного диска, но операция идёт часами под нагрузкой и требует резервной копии. Горизонтального масштабирования из коробки нет: ZFS остаётся локальным слоем, а распределённость даёт репликация через zfs send и recv. Сравнение ZFS с XFS и Btrfs по целостности, снапшотам и требованиям к ресурсам собрано в материале про файловые системы для СХД.

Ceph: RADOS, CRUSH и единый кластер

Ядро Ceph - RADOS, объектное хранилище, поверх которого работают интерфейсы: RBD для блочных устройств, RGW для S3-совместимого доступа, CephFS для файловых шар. Компоненты: OSD (по одному на физический диск, обычно BlueStore на сыром устройстве), MON (кворум мониторов), MGR (метрики, дашборд, модули), MDS (метаданные CephFS, активный и резервный). Раскладку объектов по OSD считает CRUSH-карта, поэтому добавление диска автоматически меняет распределение данных без ручных таблиц.

Цифры для продакшна. Минимум: три узла и три MON, на практике чаще пять узлов, число мониторов всегда нечётное. Ёмкость планируют из расчёта 4 ГБ RAM на каждый OSD плюс 1 ГБ на терабайт данных. Репликация size=3 оставляет 33% полезной ёмкости от сырой, erasure coding 4+2 даёт около 67% и защищает от двух потерь, но требует больше CPU и хуже работает на мелких случайных операциях. Кластер из пяти узлов по десять OSD на каждом при size=3 переживает отказ целого узла и сам восстанавливает копии. Сеть 10/25 Гбит/с, отдельные public и cluster сети, задержка между узлами до 1 мс.

GlusterFS: bricks, volumes и эластичное хеширование

Brick - это каталог на локальном диске (на практике XFS), volume - объединение bricks. Типы томов: distributed (файлы разложены по bricks), replicated (каждый файл в двух или трёх копиях), dispersed (аналог erasure coding), arbiter (данные плюс два арбитра, которые не хранят полезную нагрузку и защищают от split-brain). Сервера метаданных нет: клиент и узлы вычисляют положение файла эластичным хешированием (DHT), поэтому единой точки отказа не возникает и кластер расширяется добавлением bricks.

Обратная сторона децентрализации: листинг каталога с сотнями тысяч файлов и работа с мелкими файлами идут медленно, а рассинхронизацию копий лечит self-heal, за которым нужно следить. В реплицированном томе при потере связи обе половины могут счесть себя главными, и появляется split-brain: конфликтный файл требует ручного разбора. Кворум серверов и arbiter-тома убирают большую часть таких случаев. Коммерческую сборку сняли с поддержки в конце 2024 года, community-проект развивается, но для новых инсталляций GlusterFS выбирают осознанно, преимущественно под файловый доступ.

Отказоустойчивость и сохранность данных: что выбрать для критичных систем

Разница проявляется на трёх уровнях: диск, узел, стойка.

Отказ диска. ZFS закрывает его внутри vdev: RAID-Z2 или зеркало возвращают данные без простоя, а повреждённый сектор перезаписывается на лету. Ceph при size=3 теряет одну копию объекта из трёх и сразу запускает backfill на другие OSD. GlusterFS при реплике 2 восстанавливает копию через self-heal, который запускают вручную или по расписанию.

Отказ узла. ZFS его не переживёт без внешнего слоя: пул на отказавшем сервере недоступен, пока диски не перенесут в другой корпус, а репликация через zfs send даёт копию с задержкой и без автоматического переключения. Ceph с size=3 и раскладкой по разным узлам продолжает работу, клиенты потери не замечают. GlusterFS с репликой 3 и bricks на трёх узлах тоже продолжает отдавать файлы.

Отказ стойки. Здесь решает домен отказа. В Ceph его задают в CRUSH-карте, и при домене уровня rack две копии объекта не окажутся в одной стойке. В GlusterFS реплики разносят по узлам вручную, иначе отказ стойки убьёт том целиком. ZFS на одном сервере закрывает такой сценарий только репликацией на второй сервер.

Что проверить до продакшна: сетевая избыточность (Ceph и GlusterFS зависят от сети сильнее, чем ZFS от локальных дисков), мониторинг состояния (статус пула, состояние томов, карта кластера) и хотя бы одно реальное восстановление на стенде. Непроверенное восстановление не работает. Для критичных распределённых данных ставьте Ceph, для локального хранилища с максимальной целостностью - ZFS, для файловых шар с умеренными требованиями хватает GlusterFS.

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

ZFS на одном узле обгоняет распределённые системы, и упирается всё в количество vdev. Один RAID-Z2 из восьми HDD даёт ориентировочно 500-900 IOPS случайного чтения блоками 4 КБ, зеркала на NVMe выдают десятки и сотни тысяч IOPS при задержке в доли миллисекунды. Повторные чтения снимает ARC, поэтому рабочие наборы, которые помещаются в память, почти не нагружают диски. Синхронная запись без SLOG ограничена задержкой диска, с SLOG на NVMe она падает до сотен микросекунд.

Ceph добавляет сетевой круг: клиент ждёт подтверждения от нужного числа копий, поэтому задержка выше, чем у локального массива. Кластер из пяти узлов с NVMe OSD и сетью 25 Гбит/с показывает тысячи и десятки тысяч IOPS при задержке 1-3 мс; на HDD раскладке речь идёт о сотнях и тысячах IOPS. Erasure coding нагружает CPU и увеличивает задержку. Для мелких случайных операций на HDD критично вынести WAL и DB на отдельные NVMe, иначе каждый OSD будет упираться в собственный медленный диск.

GlusterFS силён на последовательном доступе: несколько bricks на 10/25 Гбит/с выдают гигабайты в секунду при чтении и записи крупных файлов, что подходит для медиа и архивов. Мелкие файлы, метаданные и параллельные клиенты - слабое место: операции листинга блокирующие, а тысячи клиентов конкурируют за одни и те же bricks. Кэш на клиенте и read-ahead помогают, но перестраивают не всю картину.

Ориентиры для выбора под нагрузку: база данных на одном узле - ZFS с recordsize 16 КБ и SLOG; виртуальные машины, блочные тома и общая распределённая ёмкость - Ceph RBD; файловые архивы, медиатека, бэкапы - GlusterFS или CephFS.

Сложность внедрения и сопровождения: сколько ресурсов потребуется

ZFS осваивают за часы: создать пул, наборы данных, включить NFS или SMB, настроить снапшоты по расписанию. Основное время уходит на планирование vdev и тюнинг ARC, а диагностика сводится к чтению pool status и логов slow I/O. Порог входа минимальный из трёх.

Ceph требует дней или недель: разложить OSD, настроить сети, CRUSH-карту, пулы, аутентификацию, мониторинг (обычно Prometheus с Grafana и дашборд модуля mgr). Диагностика сложнее: degraded placement groups, slow ops, близкие к заполнению OSD, отстающие backfill. Для продакшн-кластера нужен минимум один инженер с опытом Linux-сетей и хранения, лучше отдельная команда.

GlusterFS поднимается за вечер: bricks, тома, монтирование на клиентах. Проблемы начинаются в эксплуатации: split-brain, отстающий self-heal, провалы производительности на мелких файлах, а понятных сообщений об ошибках меньше, чем хотелось бы. Документация community покрывает типовые случаи, но нюансы репликации и кворума приходится собирать из практики.

Вывод по ресурсам: небольшая команда без выделенного инженера по хранению берёт ZFS или GlusterFS. Крупная инфраструктура с несколькими стойками и требованием к единому API выбирает Ceph и планирует его сопровождение как отдельную зону ответственности.

Сценарии применения: от домашней лаборатории до продакшн-кластера

Домашняя лаборатория. TrueNAS или Proxmox с ZFS, четыре-восемь дисков, RAID-Z2, 32-64 ГБ RAM, сеть 1 Гбит/с. Хранилище отдаёт SMB и NFS, снапшоты защищают от случайного удаления, места хватает под media-сервер, бэкапы и виртуальные машины. Распределённость здесь лишняя: Ceph на одном узле не даёт отказоустойчивости, которую от него ждут.

Небольшой офис. Файловый сервер на GlusterFS с реплицированным томом из двух-трёх bricks закрывает общие документы и профили, а отдельный сервер с ZFS держит бэкапы. Такой набор стоит дешевле кластера Ceph и не требует сетевой инфраструктуры 25 Гбит/с.

Продакшн-кластер виртуализации. Три-пять узлов Proxmox с Ceph RBD дают живую миграцию и работу при отказе узла; гиперконвергентная схема убирает отдельную СХД, но требует NVMe и сети 10/25 Гбит/с. VMware подключают к Ceph через iSCSI или к ZFS-серверу томами zvol, что проще в обслуживании и дешевле по железу при умеренных объёмах.

Kubernetes. Ceph через Rook работает как блочный и файловый провайдер (RBD и CephFS) и закрывает требования StatefulSet. Для локальных томов с быстрым доступом берут ZFS через local-path или OpenEBS, помня, что узел остаётся доменом отказа. Решения GlusterFS для Kubernetes не развиваются, поэтому для новых кластеров их не рассматривают.

Объектное хранилище. S3-совместимый доступ закрывает Ceph RGW; альтернатива - готовое облако, если администрировать кластер некому. Например, Timeweb Cloud даёт серверы, базы данных, хранилище и Kubernetes, и часть задач дешевле вынести туда, чем собирать пять узлов ради объектного бакета.

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

Бюджет и совокупная стоимость владения

Все три системы бесплатны в базовой поставке, поэтому TCO определяют железо, сеть, накладные расходы ёмкости и часы инженеров. Возьмём цель в 300 ТБ полезного пространства.

• ZFS: два сервера с 12 дисками по 16 ТБ (или один сервер плюс второй для репликации), 128 ГБ RAM и парой NVMe под SLOG. Сырой ёмкости нужно примерно 400 ТБ, полезной выходит около 300 ТБ.
• Ceph: пять узлов по 12 дисков 16 ТБ, это 960 ТБ сырой ёмкости и около 320 ТБ полезной при size=3. Добавьте коммутаторы 25 Гбит/с и NVMe под WAL и DB.
• GlusterFS: четыре узла, реплика 2 плюс arbiter, около 600 ТБ сырой ёмкости и те же 300 ТБ полезной. Сеть 10 Гбит/с почти всегда достаточна.

По железу кластер Ceph дороже одиночного сервера с ZFS в 1,5-2 раза при равной полезной ёмкости: треть дисков уходит в избыточность, нужны минимум три узла и сетевое оборудование. Эксплуатация добавляет 0,3-0,5 ставки инженера против нескольких часов в месяц для ZFS. Коммерческие подписки на Ceph существуют и стоят как отдельная строка бюджета, поддержку коммерческой сборки GlusterFS закрыли. Разбор TCO аппаратных и программных СХД с чек-листом на восемь шагов собран в статье аппаратная или программная СХД.

Как выбрать: алгоритм принятия решения

Ответьте на шесть вопросов по порядку, и круг вариантов сузится до одного.

1. Нужна распределённая система или хватит одного узла? Один узел выводит из списка Ceph и GlusterFS.
2. Какой тип доступа требуется: файловый, блочный, объектный или все три сразу? Все три закрывает Ceph.
3. Сколько данных и как быстро они растут? До 100 ТБ обычно достаточно ZFS, свыше 300 ТБ распределённые системы выигрывают по стоимости роста.
4. Какой профиль нагрузки: мелкие случайные операции, базы данных, виртуальные машины или крупные файлы?
5. Есть ли в команде инженер, готовый заниматься кластером постоянно?
6. Какой простой допустим и есть ли бюджет на сеть 25 Гбит/с?

Комбинировать технологии можно, но не в тех местах, где это ломает поддержку. Ceph рекомендует BlueStore на сырых устройствах, а ZFS-OSD добавляет лишний слой и не поддерживается в типовых схемах; GlusterFS официально советует XFS для bricks, а не ZFS. Зато распределение ролей работает: ZFS отвечает за локальное хранилище и бэкапы, Ceph за общую кластерную ёмкость, тома zvol через iSCSI отдают блочные устройства VMware. Перед закупкой соберите пилотный стенд на трёх узлах и прогоните на нём профиль своей нагрузки: цифры из документации и реальные показатели расходятся заметно.

Типичные ошибки и рекомендации по внедрению

ZFS. Недооценка требований к памяти: пул на 200 ТБ с 16 ГБ RAM работает, но ARC почти не кэширует, и чтения упираются в диски. Сборка пула из одного vdev на 12 дисков: пул переживёт два отказа, зато восстановление после замены диска займёт сутки и больше. Отсутствие снапшотов и расписания scrub. Заполнение пула выше 90%, что бьёт по записи и фрагментации. Для баз данных забывают про recordsize 16 КБ и SLOG, получая синхронную запись в диск.

Ceph. Запуск на трёх OSD вместо полноценных узлов: данные есть, отказоустойчивости нет. Ручное вмешательство в CRUSH-карту без понимания весов устройств приводит к перекосам заполнения. Игнорирование сетевых задержек: кластер на 1 Гбит/с уходит в degraded при любом backfill. Отсутствие мониторинга, из-за которого кластер узнаёт о сбое от пользователей. Заполнение выше 85%, после которого запись блокируется. Erasure coding для блочных томов виртуальных машин без оценки задержек.

GlusterFS. Репликация в два узла без arbiter и кворума, что рано или поздно даёт split-brain. Отсутствие контроля self-heal: копии расходятся, и расхождение обнаруживается при чтении. Использование для баз данных и миллионов мелких файлов. Отсутствие документации по конфигурации томов, из-за чего восстановление превращается в гадание.

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