ZFS и Ceph на своём железе: требования к дискам, памяти и сети

Коротко: ZFS — файловая система с менеджером томов для одного сервера: она сама собирает диски в пулы (mirror, RAIDZ1/2/3), проверяет контрольные суммы и делает снапшоты, поэтому ей нужен HBA без аппаратного RAID, ECC-память от 16 ГБ и SSD с защитой от потери питания для журнала. Ceph — распределённое хранилище из нескольких серверов: блочный доступ (RBD), файловый (CephFS) и объектный S3 (RGW). Минимальный кластер Ceph — 3 узла, на каждый OSD-диск закладывают около 4–5 ГБ RAM, а сеть — не меньше 10 GbE, для NVMe — 25 GbE и выше. ZFS проще и быстрее в пределах одного сервера, Ceph масштабируется горизонтально и переживает отказ целого узла.

Что такое ZFS и Ceph и чем они различаются

ZFS (сейчас развивается как OpenZFS) объединяет менеджер томов и файловую систему. Диски собираются в группы vdev (mirror или RAIDZ), из групп — пул, на пуле создаются файловые системы и блочные тома (zvol). Принцип copy-on-write — новые данные пишутся на новое место — даёт мгновенные снапшоты, репликацию zfs send/receive и защиту от повреждения данных при сбое питания. Каждый блок проверяется по контрольной сумме, а при избыточности повреждённый блок восстанавливается автоматически.

Ceph распределяет данные по множеству серверов алгоритмом CRUSH. Каждый диск обслуживает процесс OSD (Object Storage Daemon), карту кластера хранят мониторы MON, метрики и модули управления — MGR, метаданные CephFS — MDS, S3-шлюз — RGW. Данные защищаются репликацией (обычно 3 копии на разных узлах) или erasure coding (например, 4+2). Кластер растёт добавлением серверов без остановки.

Сравнение ZFS и Ceph

Параметр	ZFS	Ceph
Масштаб	1 сервер плюс полки JBOD	от 3 до сотен узлов
Отказоустойчивость	к отказу дисков; к отказу сервера — через репликацию на второй сервер	к отказу дисков и целых узлов, при правильном домене отказа — стоек
Доступ	NFS, SMB, iSCSI, локально	RBD (блоки), CephFS, S3/Swift через RGW
Задержки	низкие, локальный ввод-вывод	выше, каждая запись идёт по сети на несколько узлов
Эффективность ёмкости	RAIDZ2 из 8 дисков — около 75% полезной	реплика 3 — 33%, EC 4+2 — около 67%
Минимум железа	один сервер, HBA, ECC RAM	3 узла (лучше 4–5), выделенная сеть 10/25 GbE
Сложность эксплуатации	умеренная	высокая, нужны компетенции по кластеру
Типичные платформы	TrueNAS, Proxmox VE, Linux, FreeBSD	Proxmox VE, cephadm, Rook в Kubernetes

Диски и контроллеры: почему нужен HBA

И ZFS, и Ceph сами управляют избыточностью, поэтому им нужен прямой доступ к каждому диску. Аппаратный RAID-контроллер скрывает от ОС реальные ошибки, держит данные в собственном кэше и мешает самовосстановлению. Используйте HBA (Host Bus Adapter) или RAID-контроллер, переведённый в режим HBA/IT/JBOD. Типичный выбор — адаптеры на чипах Broadcom (LSI) SAS3008, SAS3408/3416 и новее. Подробнее о режимах — в статье RAID-контроллеры.

Требования к дискам:

HDD — только CMR, серверные или NAS-серии 7200 об/мин. SMR-диски при перестроении (resilver в ZFS, recovery в Ceph) работают крайне медленно. Подробнее — в статье о серверных HDD.
SSD — корпоративные модели с PLP (Power Loss Protection, конденсаторы для сброса кэша при пропадании питания). Ceph и синхронная запись ZFS постоянно отправляют команды flush, и потребительские SSD без PLP на таких операциях проседают до сотен IOPS.
Одинаковые модели и ёмкости внутри одной vdev или одного класса OSD.

Память и процессор: сколько нужно

ZFS использует оперативную память как кэш чтения ARC. Известное правило «1 ГБ RAM на 1 ТБ дисков» — ориентир для файловых серверов с большим числом пользователей, а не жёсткое требование. Практичные цифры: от 16 ГБ для небольшого NAS, 64–256 ГБ для хранилища под виртуализацию. Дедупликация — исключение: её таблице нужно порядка нескольких гигабайт RAM на терабайт данных, поэтому включают её только при доказанной выгоде. Память — только ECC, чтобы ошибки RAM не попадали в записанные данные.

Ceph для каждого OSD по умолчанию держит целевой объём памяти osd_memory_target = 4 ГБ. С запасом закладывают 5–6 ГБ на HDD-OSD и 6–8 ГБ на NVMe-OSD, плюс память под ОС, MON, MGR и при необходимости MDS (от 4–8 ГБ на демон). Процессор: ориентир 1–2 ядра на HDD-OSD и 4 и больше потоков на NVMe-OSD, иначе быстрые накопители упираются в CPU.

Конфигурация узла Ceph	OSD на узел	RAM, ориентир	Ядра CPU, ориентир
12 × HDD + 2 NVMe под DB/WAL	12	96–128 ГБ	16–24
8 × NVMe	8	96–128 ГБ	32 и больше
4 × SATA SSD (небольшой кластер)	4	32–64 ГБ	8–16

Ускорители ZFS: SLOG, L2ARC, special vdev

SLOG — отдельное устройство для журнала намерений ZIL. Ускоряет только синхронную запись: NFS для гипервизоров, базы данных, iSCSI с sync=always. Нужен небольшой (16–64 ГБ полезного объёма достаточно) очень износостойкий SSD с PLP, желательно зеркало из двух.
L2ARC — кэш чтения второго уровня на SSD. Помогает, когда рабочий набор данных больше RAM, но меньше SSD. Сначала добавьте память: каждая запись L2ARC тоже занимает немного RAM.
special vdev — SSD-зеркало для метаданных и мелких блоков. Ускоряет работу с большим числом файлов на HDD-пуле. Потеря special vdev означает потерю пула, поэтому только зеркало, лучше тройное.

Из параметров пула важны ashift=12 под 4K-сектор (задаётся при создании и не меняется), recordsize — 1M для больших файлов и бэкапа, 16–64K для баз и ВМ, сжатие lz4 или zstd. С версии OpenZFS 2.3 поддерживается расширение RAIDZ добавлением диска в существующую группу.

Ceph: DB/WAL, репликация и erasure coding

В BlueStore — штатном формате хранения Ceph — каждый OSD держит метаданные в RocksDB. На HDD-кластерах эти метаданные (block.db и WAL) выносят на NVMe: это в разы снижает задержки записи. Ориентир по размеру block.db — 1–4% от ёмкости OSD (ближе к 4% для объектного хранилища RGW). Один NVMe обычно обслуживает 4–6 HDD-OSD. При его отказе теряются все привязанные OSD, поэтому NVMe должен быть корпоративным, с PLP и запасом по ресурсу.

Защита данных задаётся в пуле. Реплика size=3, min_size=2 — стандарт для RBD под виртуальные машины. Erasure coding k+m (например, 4+2 или 8+3) экономит ёмкость, но требует узлов не меньше k+m (лучше k+m+1) и больше нагружает процессор. Чаще всего EC применяют для объектного хранилища и архивов.

Актуальные стабильные версии Ceph — Reef (18), Squid (19) и Tentacle (20). Развёртывание — через cephadm или встроенный механизм Proxmox VE.

Сеть для Ceph и репликации ZFS

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

Минимум — 2 × 10 GbE на узел для HDD-кластера, рекомендуется 2 × 25 GbE, для NVMe — 25/100 GbE.
Разделите public network (клиенты и MON) и cluster network (репликация и восстановление) — физически или VLAN-ами на разных портах.
Jumbo frames (MTU 9000) на всех узлах и коммутаторах одинаково, иначе возможны трудноуловимые сбои.
Два коммутатора с MLAG или стеком и LACP-агрегирование портов, чтобы отказ коммутатора не останавливал кластер. Требования к коммутаторам разобраны в статье как выбрать коммутатор.

Для ZFS сеть важна при раздаче по NFS, SMB или iSCSI и при репликации снапшотов на второй сервер. Для хранилища под виртуализацию с несколькими гипервизорами — от 10 GbE, для бэкап-сервера зачастую достаточно 10 GbE.

Типовые схемы под задачи

Задача	Схема	Железо
Файловый сервер, NAS офиса	ZFS, RAIDZ2 из 6–8 HDD	1U/2U сервер на 8–12 LFF, HBA, 32–64 ГБ ECC, 10 GbE
Хранилище бэкапов	ZFS, 2 × RAIDZ2 по 8–10 дисков, recordsize 1M	2U на 12 LFF или полка JBOD, 64 ГБ ECC, 10/25 GbE
NFS или iSCSI для гипервизоров	ZFS, зеркала из SSD или HDD плюс SLOG	2U на 24 SFF, 128–256 ГБ ECC, 2 SSD с PLP под SLOG, 25 GbE
Гиперконвергенция на 3–5 узлах	Proxmox VE плюс Ceph RBD, реплика 3	одинаковые серверы, 4–8 NVMe или SSD на узел, 2 × 25 GbE
Объектное хранилище S3	Ceph RGW, EC 4+2 или 8+3	от 6–12 узлов по 12 и больше HDD, NVMe под DB/WAL, 25 GbE
Общая файловая система для кластера	CephFS	как для RBD плюс 2 узла или процесса MDS, SSD-пул под метаданные

Для гиперконвергенции на двух узлах Ceph не подходит: нужен третий узел хотя бы как монитор. В небольших инсталляциях часто разумнее ZFS с репликацией между двумя серверами. Сравнение подходов SAN, NAS и DAS — в статье SAN, NAS и DAS.

Как выбрать между ZFS и Ceph и спланировать железо

Определите масштаб и рост. До 100–200 ТБ на одной площадке и без требования переживать отказ сервера — ZFS. Если нужна горизонтальная масштабируемость и работа при отказе узла — Ceph.
Определите протокол доступа: NFS/SMB, блочный доступ для ВМ, S3.
Посчитайте полезную ёмкость с учётом избыточности и запаса: ZFS-пул держат заполненным не больше чем на 80%, кластер Ceph — на 70–75%, чтобы данным отказавшего узла было где восстановиться.
Выберите накопители: HDD CMR для объёма, SSD или NVMe с PLP для производительности и метаданных.
Подберите контроллер — HBA или RAID в режиме HBA, без кэша записи на уровне контроллера.
Посчитайте RAM и CPU по ориентирам выше.
Спроектируйте сеть: скорости портов, раздельные сети для Ceph, резервирование коммутаторов.
Предусмотрите резервное копирование. Ни ZFS, ни Ceph не заменяют бэкап. Схема описана в статье резервное копирование по правилу 3-2-1.

Типичные ошибки

ZFS или Ceph поверх аппаратного RAID-массива — теряется самовосстановление, ошибки маскируются.
Потребительские SSD без PLP под SLOG, DB/WAL или OSD.
Ceph на двух узлах или на одном гигабитном интерфейсе.
Реплика 2 (size=2, min_size=1) в production — высокий риск потери данных при одновременных сбоях.
Пул ZFS, заполненный на 90% и выше: резко падает скорость записи.
Разные модели дисков и узлы разной конфигурации в одном кластере без учёта весов CRUSH.
Память без ECC в хранилище.
Ожидание от Ceph задержек локального NVMe: распределённая запись всегда медленнее локальной.

Б/у серверы под ZFS и Ceph

Программно-определяемые хранилища хорошо работают на серверах прошлых поколений: отказ отдельного компонента не критичен, если избыточность рассчитана правильно. Распространённый вариант — 2U-серверы на 12 LFF-отсеков (например, Dell PowerEdge R730xd и R740xd, HPE ProLiant DL380 Gen9 и Gen10) с HBA и сетевыми картами 10/25 GbE. Для Ceph важно, чтобы узлы были одинаковыми.

При покупке б/у проверьте, что штатный контроллер переводится в HBA-режим (у части моделей потребуется замена на HBA-адаптер), есть ли салазки на все отсеки, исправен ли backplane и поддерживает ли он нужный интерфейс дисков. Наработку и ошибки SMART проверяйте у каждого диска.

Что учесть при закупке

Для заявки подготовьте: модель серверов и их количество, тип и число дисков на узел, модель HBA или требование «контроллер в режиме HBA», объём и тип памяти (RDIMM ECC), SSD с PLP под журнал или DB/WAL, сетевые адаптеры и трансиверы под ваши коммутаторы. Укажите партномера, если расширяете существующий кластер: однотипность узлов упрощает эксплуатацию.

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

Смотреть схд и nas в наличии →

Вопросы по теме

Можно ли использовать ZFS с аппаратным RAID-контроллером?

Технически можно, но так теряются главные преимущества ZFS: самовосстановление по контрольным суммам и корректная обработка ошибок дисков. Контроллер нужно перевести в режим HBA/JBOD или заменить на HBA. Для Ceph требование то же.

Сколько памяти нужно для ZFS?

Для небольшого NAS достаточно 16–32 ГБ ECC, для хранилища под виртуализацию — 64–256 ГБ, потому что вся свободная память работает как кэш чтения ARC. Правило «1 ГБ на 1 ТБ» — ориентир, а не обязательное требование. Исключение — дедупликация: ей нужно значительно больше памяти.

Какое минимальное количество узлов для Ceph?

Минимум три узла: мониторам нужен кворум, а реплике 3 — три разных сервера. На практике рекомендуют 4–5 узлов, чтобы после отказа одного данные было куда восстановить. Для erasure coding нужно не меньше k+m узлов.

Нужна ли сеть 25 GbE для Ceph?

Для HDD-кластера можно начать с 2 × 10 GbE на узел, но при восстановлении после отказа сеть станет узким местом. Для SSD и NVMe рекомендуют 25 GbE и выше. Публичную и кластерную сети лучше разделить.

Что такое SLOG и нужен ли он?

SLOG — отдельное быстрое устройство для журнала синхронной записи ZFS. Он нужен, когда клиенты пишут синхронно: NFS для гипервизоров, базы данных, iSCSI. Для асинхронной нагрузки вроде файлового сервера или бэкапа SLOG почти ничего не даёт.

Почему нужны SSD с защитой от потери питания?

ZFS при синхронной записи и Ceph постоянно требуют подтверждения сохранности данных. SSD с PLP может подтвердить запись из кэша, потому что конденсаторы гарантируют сброс данных. Потребительские SSD на таких операциях работают в десятки раз медленнее и рискуют потерять данные при сбое питания.

Что выбрать для двух серверов виртуализации?

Ceph на двух узлах не работает корректно. Обычно выбирают ZFS на каждом узле с репликацией снапшотов (например, встроенной в Proxmox VE) или внешнюю СХД. Третий небольшой узел позволяет перейти к Ceph или кластеру с кворумом.

Подходят ли б/у серверы для Ceph?

Да, если узлы однотипные, контроллеры работают в режиме HBA, а сеть рассчитана правильно. Ceph изначально рассчитан на отказы отдельных компонентов. Проверьте диски по SMART и заложите запас ёмкости на восстановление.

Заменяют ли снапшоты ZFS и реплики Ceph резервное копирование?

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