Ceph часть #1 - Ceph для взрослых: что это такое, как работает и зачем вам это нужно

Почему Ceph, а не просто NAS или SAN?

Представьте ситуацию: у вас 50 серверов, каждый с несколькими терабайтами данных, виртуальные машины, S3-хранилище для бэкапов, общий файловый ресурс для кластера Kubernetes — и всё это нужно хранить надёжно, быстро и так, чтобы смерть одного (или нескольких) серверов не привела к потере данных и даунтайму.

Традиционные решения здесь ломаются. NAS — единая точка отказа. SAN — дорого, сложно, проприетарно. RAID — не масштабируется за пределы одной машины. Ceph решает эту задачу радикально иначе: он распределяет данные по всем дискам всех серверов одновременно, и любой узел может умереть прямо сейчас, пока вы это читаете, — вы ничего не потеряете.

Ceph используют CERN (те самые, что ищут бозон Хиггса), крупнейшие облачные провайдеры, Proxmox, OpenStack — в общем, люди, которым нельзя терять данные. Давайте разберёмся, как это устроено.

Три уровня хранения в одном кластере

Ceph — это не одна технология, это три совершенно разных интерфейса хранения, построенных поверх одного движка:

┌─────────────────────────────────────────────────┐
│              Приложения и клиенты               │
├──────────────┬──────────────┬───────────────────┤
│   RBD        │   CephFS     │   RGW (S3/Swift)  │
│  Блочное     │  Файловая    │  Объектное         │
│  хранилище   │  система     │  хранилище         │
├──────────────┴──────────────┴───────────────────┤
│                    RADOS                        │
│        (Reliable Autonomic Distributed          │
│              Object Store)                      │
├─────────────────────────────────────────────────┤
│         OSD OSD OSD OSD OSD OSD OSD             │
│         (физические диски/SSD/NVMe)             │
└─────────────────────────────────────────────────┘

RBD (RADOS Block Device) — виртуальный блочный диск. С точки зрения виртуальной машины или Kubernetes pod — это просто диск. Внутри он разбит на объекты по 4 МБ (по умолчанию) и размазан по всему кластеру. Размер — до 16 эксабайт.

CephFS — POSIX-совместимая распределённая файловая система. Монтируется как обычная папка, понимает права доступа, символические ссылки, всё как у людей. Метаданные хранит отдельно от данных через специальный демон MDS.

RGW (RADOS Gateway) — HTTP-интерфейс объектного хранилища, совместимый с Amazon S3 и OpenStack Swift. Загружаете файлы через API, получаете бакеты, версионирование, lifecycle-политики — всё как в S3.

Самое красивое: всё три интерфейса используют один и тот же кластер RADOS. Вы можете одновременно монтировать CephFS на NFS-сервере, раздавать RBD-диски виртуалкам Proxmox и гонять бэкапы в RGW — и все они делят одни и те же физические диски.

Архитектура: четыре типа демонов

Ceph-кластер — это набор демонов, каждый со своей ролью. Никаких монолитов, никакого единого «сервера хранилища».

MON — Monitor (мозг кластера)

MON1  MON2  MON3
  \     |     /
   \    |    /
    кластерная карта
    (cluster map)

Мониторы хранят карту кластера — полное описание топологии: какие OSD существуют, где они физически расположены, здоровы ли они. Это не данные, это метаданные. Мониторы работают по протоколу Paxos и требуют кворума: нужно нечётное число, минимум 3 в продакшне.

Без кворума мониторов — нет записи (но чтение может работать). Мониторы не хранят пользовательские данные вообще — они лёгкие, их можно держать даже на небольших VM.

OSD — Object Storage Daemon (мышцы кластера)

Один OSD = один физический диск (или раздел). OSD хранит данные, обслуживает запросы чтения/записи, участвует в репликации, сам находит соседей для репликации по карте кластера.

Типичный сервер в кластере: 12 дисков = 12 OSD-процессов + небольшой SSD для BlueStore WAL/DB.

OSD общаются напрямую — без центрального сервера хранения. Если клиент пишет данные в pool с репликацией 3x, primary OSD сам синхронно реплицирует на двух соседей и только потом отвечает клиенту «записано».

MDS — Metadata Server

Нужен только для CephFS. Хранит иерархию директорий и метаданные файлов (права, размеры, время). Данные файлов хранятся в обычных RADOS-объектах — MDS только помогает по пути /my/dir/file.txt найти нужные объекты.

Можно запустить несколько MDS для параллелизма — активный-активный режим (multi-MDS).

MGR — Manager

Менеджер собирает статистику, запускает модули (dashboard, prometheus-экспортер, балансировщик), обрабатывает оркестровку через cephadm. Нужно минимум 2 для отказоустойчивости (один active, один standby).

CRUSH: как Ceph решает, куда положить данные

Вот где начинается самое интересное. В обычном RAID контроллер знает: «диск 1, 2, 3». В Ceph нет центрального индекса «где лежит файл» — это было бы узким местом в огромном кластере.

Вместо этого используется алгоритм CRUSH (Controlled Replication Under Scalable Hashing). Зная только имя объекта и карту кластера, CRUSH детерминированно вычисляет, на каких OSD хранить данные — без запросов к какому-либо серверу метаданных.

object "my_file_chunk_0042" 
    │
    ▼
pg_id = hash(object_name) % pg_count
    │
    ▼
CRUSH(pg_id, crush_map) → [OSD.7, OSD.23, OSD.41]

Когда приходит запрос «где лежит объект X» — любой клиент, зная карту кластера, сам вычисляет ответ и идёт напрямую к нужному OSD. Без промежуточных серверов. Это и есть причина масштабируемости.

Placement Groups (PG): промежуточный уровень

Объектов в кластере могут быть миллиарды. Если бы каждый объект CRUSH маппил напрямую на OSD — карта кластера была бы гигантской. Поэтому объекты сначала группируются в Placement Groups (PG), а уже PG маппятся на OSD.

Объект → PG (группа объектов) → OSD

Число PG на pool — важный параметр настройки. Слишком мало — неравномерное распределение, узкое место. Слишком много — накладные расходы. Золотое правило: ~100 PG на OSD в pool.

CRUSH Map: физическая топология

CRUSH знает физику вашего датацентра:

datacenter DC1
├── rack Rack-A
│   ├── host server-01
│   │   ├── osd.0 (weight 1.0)
│   │   ├── osd.1 (weight 1.0)
│   │   └── osd.2 (weight 1.0)
│   └── host server-02
│       ├── osd.3
│       └── osd.4
└── rack Rack-B
    └── host server-03
        ├── osd.5
        └── osd.6

Правило репликации может звучать так: «три копии, каждая на отдельном rack'е». Тогда при смерти целого стойки ни одна PG не потеряет больше одной копии данных.

BlueStore: почему Ceph не использует ext4 или XFS

До Ceph 12 OSD хранил данные на обычной файловой системе (FileStore). Это работало, но было медленно: каждая запись проходила через XFS/ext4 со всеми их накладными расходами, двойным кешированием, лишними syscall'ами.

С Ceph 12 появился BlueStore — кастомный бэкенд хранения, который работает напрямую с блочным устройством, минуя файловую систему. FileStore официально удалён начиная с Reef (18.x).

Архитектура BlueStore

OSD Process
├── BlueStore
│   ├── RocksDB (метаданные объектов, omap)
│   │   └── хранится на быстром SSD/NVMe (BlueFS)
│   ├── WAL (write-ahead log)
│   │   └── тоже лучше на SSD
│   └── данные объектов
│       └── на основном диске (HDD или SSD)
└── BlueFS (микрофайловая система для RocksDB)

В Tentacle (20.x) BlueStore получил улучшенное сжатие и новый, более быстрый WAL — это не маркетинг, а реальные измеримые улучшения для workload'ов с частой записью.

Ключевые преимущества BlueStore:

• Полный контроль над I/O без лишних слоёв

• Атомарные транзакции без двойного буферирования

• Встроенное сжатие (zlib, snappy, zstd, lz4)

• Checksums для данных и метаданных (обнаружение битрот)

• Эффективный omap для небольших значений ключ-значение

Репликация vs. Erasure Coding: выбираем стратегию

Репликация (Replication)

Простейший вариант: каждый объект хранится в N копиях на N разных OSD.

Запись "hello.txt":
    [OSD.5 — первичная копия]
        ├── реплицирует → [OSD.12 — копия 2]
        └── реплицирует → [OSD.31 — копия 3]

Плюсы: простота, низкая latency, любой OSD может обслужить чтение. Минусы: 3x overhead по дисковому пространству.

Для продакшна стандарт — size=3, min_size=2. Это значит: нормальный режим — 3 копии, деградированный (когда один OSD умер) — 2 копии, меньше 2 — запись заблокирована.

Erasure Coding (EC)

EC — это как RAID 5/6, но распределённый. Данные разбиваются на K кусков, добавляются M паритетных кусков. Всего K+M кусков на K+M OSD. Для восстановления нужно любые K из K+M кусков.

Пример EC 4+2:
  chunk0 chunk1 chunk2 chunk3 | parity0 parity1
   OSD.1  OSD.2  OSD.3  OSD.4    OSD.5   OSD.6

При смерти OSD.2 и OSD.5 — данные восстанавливаются из оставшихся 4 из 6.

Плюсы: экономия места. EC 4+2 даёт overhead 1.5x против 3x для репликации. Минусы: сложнее, выше latency, CPU overhead на кодирование/декодирование.

EC оптимально для холодного хранилища, S3-бэкапов, больших объектов. Для горячих IOPS-нагруженных данных (БД, VM) — репликация.

FastEC в Tentacle: революция для Erasure Coding

В Ceph Tentacle (20.2.0) появилась долгожданная функция FastEC — принципиально новая реализация I/O для EC пулов с поддержкой partial reads и partial writes.

До FastEC: запись небольшого объекта в EC-пул требовала читать все K кусков, обновлять данные, пересчитывать все паритеты и писать всё обратно. Это называется Read-Modify-Write (RMW) — катастрофа для производительности при мелких записях.

FastEC оптимизирует именно этот случай. По словам разработчиков и независимым тестам, на определённых workload'ах FastEC обгоняет даже репликацию 3x по производительности — при вдвое меньшем расходе места.

Важно: FastEC включается явно на уровне пула командой allow_ec_optimizations:

ceph osd pool set mypool allow_ec_optimizations true

Существующие пулы можно мигрировать без пересоздания данных — достаточно обновить OSD и MON до Tentacle.

Что нового в Ceph Tentacle (20.2.0)

Tentacle вышел 18 ноября 2025 года и является 20-м стабильным релизом Ceph. Это значительный релиз, не косметический. Вот главное:

FastEC — новый движок Erasure Coding

Уже разобрали выше. Переключение плагина по умолчанию с устаревшего Jerasure на ISA-L (Intel ISA-L library) — более быстрый, активно поддерживаемый. Jerasure больше не обслуживается авторами.

SMB-поддержка через Ceph

Ceph теперь умеет создавать SMB-шары прямо из кластера через новый модуль mgr. Технически это Samba поверх CephFS с автоматическим управлением через cephadm. Поддерживает Active Directory и standalone. Работает в кластерном режиме через CTDB.

ceph smb cluster create mysmb active-directory DC=corp,DC=example,DC=com \
  --domain-realm corp.example.com

mgmt-gateway: единая точка входа для управления

Новый сервис mgmt-gateway — nginx reverse proxy с TLS, который объединяет Dashboard, Prometheus, Grafana, Alertmanager под одним адресом. Никаких «зайди на порт 8443 для дашборда, 9090 для Prometheus, 3000 для Grafana».

Плюс интеграция с OAuth 2.0/OIDC для SSO. Настраивается через cephadm в пару команд.

certmgr: автоматические TLS-сертификаты

Подсистема управления сертификатами. Ceph теперь сам выступает корневым CA, выпускает сертификаты для своих сервисов, обновляет их автоматически, предупреждает об истечении. Никаких самоподписанных сертификатов вручную.

Data Availability Score

Новая команда для мониторинга доступности данных:

ceph osd pool availability-status

Показывает «score» для каждого пула — сколько данных доступно прямо сейчас. Пул считается недоступным если любая PG не в состоянии active или есть unfound объекты.

Crimson OSD + SeaStore (Tech Preview)

Crimson — полностью переписанный OSD на основе Seastar (асинхронный, без блокирующих операций). В Tentacle к нему добавили развёртывание SeaStore — нового бэкенда хранения рядом с Crimson. Это всё ещё tech preview, в продакшне не используем — но прогресс виден.

Удаление устаревших модулей

Модули mgr/restful и mgr/zabbix официально удалены. Они были deprecated с 2020 года и имели уязвимости в зависимостях (CVE-2023-46136). Переходите на Dashboard API и Prometheus.

Когда Ceph — правильный выбор

Ceph имеет смысл когда у вас:

• Минимум 3 физических сервера (иначе нет смысла в распределённости)

• Объём данных от нескольких терабайт

• Потребность в нескольких типах хранилища одновременно (block + object + file)

• Нужна горизонтальная масштабируемость: добавил серверы → ёмкость и производительность выросли

• Нужна отказоустойчивость без дорогого проприетарного железа

Когда Ceph — не правильный выбор:

• Один сервер или только два — берите ZFS/BTRFS

• Небольшой проект: overhead на управление не окупится

• Нужна очень низкая latency (< 1ms) для транзакционной БД — NVMe All-Flash Array или local SSD в приоритете

Итог: ключевые концепции для запоминания

В следующей статье мы разворачиваем реальный кластер с нуля через cephadm, настраиваем пулы и подключаем RBD к Proxmox.

Далее читай - Часть #2