Что такое Ceph и когда он действительно нужен
Ceph собирает диски нескольких серверов в единое отказоустойчивое хранилище и отдаёт данные через три интерфейса: блочный, файловый и объектный. Отказ диска, сервера или целой стойки не останавливает сервис: кластер продолжает обслуживать запросы, а недостающие копии данных восстанавливаются на оставшихся узлах автоматически.
Дорогостоящие СХД с двумя контроллерами и полками расширения здесь не требуются. Роль контроллеров берут обычные серверы с локальными накопителями, объединённые сетью 10 GbE и быстрее. Единица масштабирования - один диск: добавили сервер с 12 накопителями, получили 12 новых OSD и прирост ёмкости без остановки кластера.
Ceph оправдан, когда нужно единое хранилище для Kubernetes или OpenStack, объём начинается с десятков терабайт, а простой при потере узла недопустим. Он избыточен там, где есть один сервер, до 10-20 ТБ данных и задача сводится к файловому шарингу. В таких случаях ZFS с NFS или SMB закрывает потребность дешевле и предсказуемее. Отдельно учтите: Ceph требует сопровождения, то есть мониторинга, плановых обновлений и контроля заполнения пулов.
Ключевые свойства: отказоустойчивость, масштабирование, самовосстановление
RAID защищает от отказа накопителя внутри одного сервера. Ceph идёт дальше: копии объекта раскладываются по разным хостам, а при правиле с доменами отказа - по разным стойкам. Потеря целого сервера означает потерю одного экземпляра данных, два других остаются доступны клиентам.
Уровень защиты задаёт пул. Репликация с размером 3 хранит три полные копии и позволяет потерять два узла без остановки записи. Erasure coding делит объект на k фрагментов и добавляет m проверочных: схема 8+3 занимает 11 дисковых блоков на 8 блоков данных, то есть около 37% накладных расходов против 200% у тройной реплики. Плата за экономию места - больше вычислений на CPU и заметно слабее производительность на мелких операциях ввода-вывода.
Восстановление запускается само. После выхода узла из строя кластер пересчитывает размещение и переливает недостающие копии (backfill) на живые OSD. Процесс идёт по сети и нагружает диски, поэтому в часы пик его притормаживают параметрами osd_max_backfills и osd_recovery_max_active. Запас свободного места под восстановление обязателен: при реплике 3 держите не менее 20-30% ёмкости сверху, иначе первый же отказ приведёт к переполнению пулов.
Когда Ceph избыточен: типичные ошибки выбора
- Один или два сервера. Кворум мониторов требует трёх узлов; при меньшем числе кластер либо не поднимется, либо теряет смысл, потому что отказ любого хоста останавливает работу.
- Объём до 10-20 ТБ и нетребовательность к доступности. ZFS с NFS или SMB на одном сервере даст больше скорости за меньшие деньги.
- Нужно только объектное хранилище на одной машине. MinIO проще в настройке и обслуживании.
- Нужны блочные устройства без распределённости. Локального RAID с кэшем на батарейке достаточно.
- Нет команды, готовой сопровождать распределённую систему: обновления, разбор деградации, контроль PG.
Минимальный осмысленный кластер: 3 узла с мониторами и минимум 6-9 OSD плюс выделенная сеть 10 GbE. На одном хосте с несколькими OSD распределённость не проверяется: падение машины уносит всё сразу. Как разные системы хранения ведут себя на одинаковых задачах, разобрано в практическом сравнении TrueNAS, Ceph, ZFS и других систем хранения.
Архитектура Ceph: как из дисков получается отказоустойчивое хранилище
Ядро системы - RADOS, распределённое объектное хранилище. Этот слой хранит данные, считает контрольные суммы и следит за целостностью копий. Поверх RADOS работают три клиента: librbd, libcephfs и RADOS Gateway. Все три могут обслуживать один кластер одновременно, делить между собой ёмкость и не мешать друг другу.
Данные лежат в пулах. Пул делится на placement groups (PG), а каждую PG алгоритм CRUSH раскладывает по OSD. Центрального сервера метаданных нет: клиент сам вычисляет, на каких дисках лежит нужный объект, и обращается напрямую к этим OSD. Так снимается узкое место классических СХД, и кластер растёт до тысяч узлов без отдельного каталога. Общие принципы построения таких систем разобраны в материале про архитектуру кластерных систем хранения.
MON, MGR и OSD: кто за что отвечает
MON (monitor) хранит карту кластера: список OSD, пулов, правил CRUSH и состояние самих мониторов. Работает кворумом из 3 или 5 узлов, число всегда нечётное. Пока кворум есть, кластер принимает запросы и меняет карту. Потеря большинства мониторов переводит систему в режим только для чтения, поэтому мониторы ставят на отдельные надёжные хосты и не смешивают с тяжёлой нагрузкой.
MGR (manager) собирает метрики, отдаёт веб-дашборд и запускает модули. Balancer выравнивает заполнение OSD, pg_autoscaler подбирает число PG, модуль prometheus публикует метрики для внешнего мониторинга. Клиентские операции через MGR не идут, его падение данные не теряет, но управляемость падает. Держат два экземпляра: active и standby.
OSD (object storage daemon) - рабочий процесс на каждый диск. Внутри работает BlueStore: он пишет данные напрямую на блочное устройство, а метаданные складывает в RocksDB на отдельном разделе или SSD. OSD обслуживает чтения и записи, реплицирует объекты, участвует в восстановлении и проверяет контрольные суммы при scrubbing. Основную часть CPU и RAM кластера съедают именно OSD, они же определяют ёмкость: 12 дисков в сервере, 12 OSD.
CRUSH-карта и пулы: как Ceph решает, где хранить данные
CRUSH - детерминированный алгоритм размещения. Он берёт идентификатор объекта, карту кластера и правило, после чего вычисляет список OSD. Таблиц вида «где что лежит» не существует: любой клиент и любой OSD получают одинаковый ответ при одинаковых входных данных.
Карта описывает иерархию и домены отказа: root, rack, host, osd. Правило «три копии в трёх разных стойках» записывается строкой правил, и CRUSH гарантирует, что копии не окажутся в одном домене. Веса OSD задают долю данных: диск на 16 ТБ получает вес вдвое больше восьмитерабайтного, и кластер заполняет их пропорционально.
Пул задаёт политику хранения:
| Параметр | Что делает | Типичное значение |
|---|---|---|
| size | число копий объекта | 3 |
| min_size | минимум копий для записи | 2 |
| pg_num | число PG в пуле | 100-200 на OSD |
| crush rule | правило размещения | по стойкам или хостам |
Число PG - классическая точка ошибки новичка. Мало PG: объекты ложатся неравномерно, отдельные OSD перегружены. Много: растут расход памяти и время peering. Ориентир - 100-200 PG на один OSD, а подбор значения лучше отдать pg_autoscaler, который пересчитывает его по мере роста кластера. Текущее состояние смотрят командами ceph df, ceph osd tree и ceph osd pool autoscale-status.
MDS и CephFS: зачем нужен отдельный демон
MDS (metadata server) нужен только для CephFS. Он держит дерево каталогов, права, блокировки и кэш метаданных, а содержимое файлов остаётся в OSD. Один активный MDS обслуживает кластер, второй находится в режиме standby и подхватывает работу при отказе. Для деревьев с миллионами файлов настраивают несколько активных MDS с разделением по поддеревьям.
Для RBD и объектного хранилища MDS не требуется. Это меняет расчёт ресурсов: кластер без CephFS экономит один-два хоста или как минимум не выделяет им быстрые SSD под метаданные.
Три интерфейса доступа: RBD, CephFS и объектное хранилище
Поверх RADOS Ceph отдаёт три типа доступа. Выбор зависит от задачи: виртуальной машине нужен блочный диск, группе серверов - общая файловая система, приложению с S3 SDK - бакеты.
| Интерфейс | Что даёт | Типичные задачи |
|---|---|---|
| RBD | блочное устройство | диски ВМ, PersistentVolume в Kubernetes, базы данных |
| CephFS | POSIX-ФС для множества клиентов | общие данные, бэкапы, домашние каталоги |
| RGW | S3 и Swift API | резервные копии, статический контент, приложения с S3 SDK |
RBD: блочное хранилище для виртуальных машин и Kubernetes
RBD (RADOS Block Device) - образ, который подключается к серверу как обычный диск: через модуль ядра krbd или библиотеку librbd. Образ собирается из объектов RADOS размером 4 МБ, поэтому поддержаны тонкое выделение, снапшоты и клоны на запись. В Proxmox VE и KVM диски виртуальных машин лежат на RBD, а в Kubernetes PersistentVolume создаёт CSI-драйвер Ceph.
Ограничение важное: один RBD-образ монтируют на один хост в режиме чтения и записи. Совместный доступ нескольких серверов требует кластерной файловой системы (CephFS, GFS2, OCFS2) либо приложения с собственной логикой распределённого доступа. Для консистентного бэкапа виртуальной машины снимают снапшот тома и уже из него читают данные.
CephFS: распределённая файловая система
CephFS - POSIX-совместимая файловая система, которую монтируют сотни клиентов одновременно. Данные лежат в пуле данных, метаданные - в отдельном пуле на SSD или NVMe. Монтирование идёт через клиент ядра (максимальная производительность) или через ceph-fuse: второй вариант выручает на старых ядрах и в контейнерах без нужных модулей.
На практике CephFS даёт квоты на каталоги, снапшоты файловой системы и несколько активных MDS для крупных деревьев. Слабое место - операции с метаданными. Тысячи мелких файлов, создаваемых параллельно, упираются в MDS, и наращивание OSD здесь не помогает. Планируйте метаданные на быстрых дисках и следите за задержкой MDS.
RGW и S3-совместимый API: объектное хранилище
RADOS Gateway (RGW) публикует S3 и Swift API поверх RADOS. Бакет превращается в набор объектов RADOS, а индекс бакета держится в отдельном пуле. Пользователи, ключи доступа и политики создаются через radosgw-admin. Поддержаны версионирование объектов, жизненные циклы (перевод в другой класс хранения или удаление по возрасту), мультитенантность и geo-репликация между площадками.
Инстансы RGW масштабируются независимо от OSD: десяток шлюзов за балансировщиком даёт высокую пропускную способность на HTTP-операциях. Совместимость проверяется любым S3-клиентом: aws-cli, s3cmd, MinIO Client, SDK для Python и Go. Это рабочий способ заменить публичное облако своим S3 без переписывания кода приложений. Различия моделей доступа подробно разобраны в статье про объектное, блочное и файловое хранилище.
Минимальные требования к железу и сети
Требования зависят от того, для чего собирается кластер. Ниже ориентиры для типовых конфигураций с HDD под данные и SSD под журналы и метаданные.
Тестовый кластер: минимум для знакомства
- Три виртуальные машины по 4 vCPU, 8 ГБ RAM и 2-3 диска каждая, либо три старых сервера.
- Развёртывание через cephadm: bootstrap поднимает первый монитор и менеджер, дальше узлы добавляют командой ceph orch host add.
- Одна сеть на стенде допустима, но помните: на виртуалках вы изучаете логику системы, а не её производительность. Поведение при отказе диска тоже отличается от железа.
- Не собирайте стенд на одной машине с несколькими OSD: распределённость исчезает, а проверяете вы именно её.
Для тестового стенда достаточно трёх облачных серверов: Timeweb Cloud даёт VDS с настраиваемыми ресурсами и дополнительными дисками, так что RBD, CephFS и RGW можно разобрать без покупки железа.
Продуктивный кластер: планирование ресурсов
CPU: 4-8 ядер на узел как старт. Erasure coding 8+3 считает контрольные суммы при каждой записи и восстановлении, для таких пулов берите ядра с запасом.
RAM: не менее 4 ГБ на каждый OSD плюс примерно 1 ГБ на 1 ТБ данных кластера. BlueStore держит в памяти кэш, структуры RocksDB и очередь восстановления, экономия здесь оборачивается провалами по задержке.
Диски: одинаковые по размеру и производительности внутри одного пула, иначе CRUSH разложит данные по весам и медленные накопители станут тормозом для всех. Отдельный SSD или NVMe под WAL и DB заметно ускоряет HDD-пулы. RAID-контроллер переводите в режим JBOD или HBA: аппаратный RAID прячет физические диски и мешает Ceph работать с ними напрямую.
Сеть: минимум 10 GbE, для кластеров на NVMe - 25 или 40 GbE. Public network несёт клиентский трафик, cluster network - репликацию и восстановление. Разделение по VLAN обязательно, иначе backfill съест пропускную способность приложений. Jumbo frames с MTU 9000 дают прирост на больших последовательных чтениях.
Узлы: от 5 штук для комфортной отказоустойчивости при реплике 3, чтобы потеря сервера вместе с плановым обслуживанием не оставляла кластер без запаса. Мониторинг: Prometheus и Grafana через модуль prometheus в MGR, алерты на заполнение 85% (nearfull) и 95% (full), на долгий peering PG и на количество degraded-объектов.
Как понять, что Ceph оправдан: критерии выбора
Пройдитесь по шести вопросам. Положительный ответ на большинство означает, что распределённое хранилище закрывает реальную задачу, а не создаёт новую.
- Есть потребность в едином хранилище для нескольких сервисов: виртуальных машин, Kubernetes, бэкапов, объектных бакетов.
- Нужна отказоустойчивость на уровне узла и стойки, а не отдельного диска.
- Готовы выделить 3-5 серверов и сеть 10 GbE минимум.
- Есть команда, способная обслуживать кластер: обновления, мониторинг, разбор деградации.
- Требуется S3-совместимый API или блочные тома для Kubernetes.
- Объём данных измеряется десятками терабайт и будет расти.
Если половина ответов отрицательная, смотрите в сторону альтернатив. GlusterFS проще в базовых сценариях файлового шаринга, но не даёт блочного и объектного доступа из коробки и хуже ведёт себя на мелких файлах. ZFS с NFS или SMB выигрывает на одном узле. MinIO закрывает объектные задачи без распределённого ядра. Ceph хорошо ложится в инфраструктуру с Kubernetes через Rook и в OpenStack, где он исторически основной бэкенд. Как выбирать между классами СХД с учётом расчёта IOPS и резервирования, описано в обзоре систем хранения данных в 2026 году.
Ceph - долгосрочная инвестиция. Быстрым способом получить «просто хранилище» он не становится: первые месяцы уходят на освоение CRUSH, пулов и диагностики.
С чего начать изучение и внедрение
Последовательность, которая экономит недели проб и ошибок:
- Прочитайте официальную документацию по архитектуре: RADOS, карта кластера, пулы, PG, CRUSH.
- Поднимите тестовый кластер на трёх виртуальных машинах через cephadm и убедитесь, что здоровье кластера в норме по ceph -s.
- Создайте пул и попробуйте все три интерфейса: подключите RBD-образ, смонтируйте CephFS, настройте пользователя RGW и загрузите объект любым S3-клиентом.
- Сломайте стенд специально: выключите один узел, посмотрите на деградацию PG, дождитесь восстановления и оцените нагрузку на сеть.
- Настройте мониторинг и дашборд, добавьте алерты на nearfull и degraded.
- Изучите правила CRUSH и pg_autoscaler, затем повторите шаги на конфигурации, близкой к продакшену.
Рабочие инструменты диагностики: ceph -s и ceph health detail для общего состояния, ceph osd tree для раскладки дисков по хостам, ceph df для ёмкости, ceph osd pool autoscale-status для числа PG, ceph orch ps для списка демонов. Готовые конфигурации и порядок развёртывания кластера на нескольких узлах приведены в руководстве по построению SDS-кластера на Ceph и GlusterFS.
Частые ошибки новичков: малое или неверно подобранное число PG, экономия на сети, RAID-контроллер без JBOD, отсутствие мониторинга, запуск продакшена на трёх узлах без запаса по ёмкости. Каждая из них приводит к деградации в самый неподходящий момент.
Начните с трёх виртуальных машин и одного пула. Если после недели работы с кластером вы понимаете, где лежат объекты, как ведёт себя восстановление и сколько ресурсов съедает RADOS, решение о продакшене будет опираться на факты, а не на маркетинг.