Ceph: распределённое хранилище для серьёзной корпоративной инфраструктуры

Я, Семёнов Евгений Сергеевич, директор ITFresh, могу вам точно сказать: Ceph — это просто бомба! Почему? Это единственная система хранения, которая не только даёт одновременно блочный, файловый и объектный доступ, но и при этом легко масштабируется до петабайтов, причём совершенно бесплатно. У меня лично в дата-центре МТС Москва сейчас работают целых три таких кластера, и каждый из них занят своим делом. Один, например, мы используем для клиентских виртуальных машин (это RBD). Второй заточен под CephFS, чтобы наши инженеры могли удобно работать с файловыми шарами. А третий, RGW, полностью S3-совместимый, служит для бэкапов. За все пять лет, пока они у нас в эксплуатации, мы не потеряли ни байта данных! И я с огромной радостью готов поделиться нашим богатым опытом по их развёртыванию.

Архитектура Ceph — ключевые компоненты

Как же это работает? Всё довольно хитро, но эффективно. Сначала данные делятся на отдельные объекты, затем эти объекты раскидываются по PG — Placement Groups. А уж потом, согласно уникальной CRUSH-карте, PG распределяются по OSD, то есть по вашим дискам. Что здесь главное? Клиент обращается к монитору (MON) за актуальной картой всего один раз, а дальше работает напрямую с OSD. Никаких центральных прокси, никаких узких мест — просто прямой, быстрый доступ.

Подбор железа

Вот тут кроется один из самых важных этапов, и его нельзя игнорировать! Ceph, конечно, неприхотлив к топологии вашей сети. Но зато он очень, очень требователен к качеству дисков и стабильности самой сети. Не экономьте на этом — Ceph не прощает небрежности.

• Ноды. Минимум 5 однотипных серверов — так проще балансировать и обслуживать. У меня в основном кластере стоят 5 × Dell Xeon Platinum 8280 с 384 ГБ RAM.
• Диски OSD. Enterprise-NVMe (Intel D7, Samsung PM9A3) или гибрид NVMe+HDD с BlueStore WAL/DB на NVMe.
• Сеть. 2 × 40G Mellanox на ноде (бонд LACP), отдельные VLAN для public и cluster.
• RAM. 1 ГБ на каждый ТБ OSD минимум, рекомендую 2 ГБ.
• CPU. 1-2 ядра на OSD; для NVMe OSD — 2-4 ядра на диск.

Подготовка нод

# На каждой ноде (Debian 12 или Rocky 9)
apt install -y podman lvm2 chrony

# Настройка времени (критично для MON-консенсуса)
systemctl enable --now chrony

# Настройка /etc/hosts (если нет DNS)
cat >> /etc/hosts << 'EOF'
10.10.10.11  ceph01
10.10.10.12  ceph02
10.10.10.13  ceph03
10.10.10.14  ceph04
10.10.10.15  ceph05
EOF

# Отключаем swap (важно для OSD)
swapoff -a
sed -i 's|^/swap|#/swap|' /etc/fstab

# Тюнинг sysctl
cat >> /etc/sysctl.d/99-ceph.conf << 'EOF'
kernel.pid_max = 4194303
fs.file-max = 26234859
vm.swappiness = 1
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
EOF
sysctl --system

Развёртывание через cephadm

Мы предпочитаем использовать cephadm — это наш современный и, прямо скажем, самый удобный способ развёртывания кластеров через контейнеры. С чего начинаем? Устанавливаем его на первую ноду, как показано далее.

# Bootstrap на ceph01
apt install -y cephadm
cephadm bootstrap --mon-ip 10.10.10.11 \
  --cluster-network 10.20.20.0/24 \
  --initial-dashboard-user admin \
  --initial-dashboard-password TempPass123

# Вывод — адрес дашборда, пароль, cephadm shell alias
cephadm install ceph-common
ceph -s   # HEALTH_WARN пока нет OSD — нормально

Добавляем остальные ноды в оркестратор:

# SSH-ключ cephadm-а раздаём на все хосты
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph02
ssh-copy-id -f -i /etc/ceph/ceph.pub root@ceph03
# ... и так далее

# Добавляем ноды
ceph orch host add ceph02 10.10.10.12
ceph orch host add ceph03 10.10.10.13
ceph orch host add ceph04 10.10.10.14
ceph orch host add ceph05 10.10.10.15

# Проверка
ceph orch host ls

Разворачиваем MON и MGR

# 5 MON с меткой для автопривязки
ceph orch apply mon --placement="5 ceph01 ceph02 ceph03 ceph04 ceph05"
ceph orch apply mgr --placement="2 ceph01 ceph02"

ceph -s
# Должно стать mons: 5 daemons, mgrs: 2 daemons

Добавляем OSD

А дальше cephadm всё сделает за вас: он сам быстро найдёт все неиспользованные диски.

# Посмотреть доступные диски
ceph orch device ls

# Добавить все подходящие автоматически
ceph orch apply osd --all-available-devices

# Или вручную по конкретным дискам
ceph orch daemon add osd ceph01:/dev/nvme0n1
ceph orch daemon add osd ceph01:/dev/nvme1n1
ceph orch daemon add osd ceph02:/dev/nvme0n1
# ...

# Статус
ceph osd tree
ceph df

Пулы и replication

# Replication pool size=3, min_size=2
ceph osd pool create vms 128 128 replicated
ceph osd pool set vms size 3
ceph osd pool set vms min_size 2
rbd pool init vms

# EC pool 4+2 (для холодных данных/бэкапов)
ceph osd erasure-code-profile set ec42 \
  k=4 m=2 crush-failure-domain=host
ceph osd pool create cold_backup 128 128 erasure ec42
ceph osd pool set cold_backup allow_ec_overwrites true

RBD — блочное хранилище для гипервизоров

# Создание образа
rbd create --size 100G vms/vm-web01
rbd info vms/vm-web01

# Маппинг на клиенте (Linux)
rbd map vms/vm-web01 --name client.admin
mkfs.xfs /dev/rbd0
mount /dev/rbd0 /mnt/data

# В Proxmox Datacenter -> Storage -> Add -> RBD
# Указываем ID, Pool, Monitor Host, keyring

CephFS — файловая система

# Два пула — под метаданные и данные
ceph osd pool create cephfs_data 64 64
ceph osd pool create cephfs_metadata 32 32
ceph fs new officefs cephfs_metadata cephfs_data

# Разворачиваем MDS
ceph orch apply mds officefs --placement="2 ceph01 ceph02"

# Клиент (Linux)
mount -t ceph 10.10.10.11:6789:/ /mnt/officefs \
  -o name=admin,secretfile=/etc/ceph/admin.key

RGW — S3-совместимый API

# Развёртывание RGW
ceph orch apply rgw default --placement="2 ceph03 ceph04"

# Создание пользователя
radosgw-admin user create --uid=backup --display-name="Backup User"
# Сохраняем access_key и secret_key

# Проверка с AWS CLI
aws --endpoint-url http://ceph03:7480 s3 mb s3://bareos-daily
aws --endpoint-url http://ceph03:7480 s3 ls

Реальный кейс: 5-нодовый кластер на 120 ТБ

Возьмём недавний пример: в июне 2024 года мы запускали кластер для одного клиента — это крупный ИТ-интегратор с собственным облаком. Задача была очень конкретной: обеспечить 120 ТБ полезного пространства под VMware/Proxmox. Помимо этого, им нужен был S3-совместимый доступ для бэкапов их собственных клиентов, а также CephFS для файловой шары разработчиков. И, конечно, строгие требования к доступности: SLA 99.95%, а RTO после сбоя одной ноды — не более 30 минут. Вызов, не правда ли?

Что касается железа, то мы всегда выбираем только проверенные решения. В этом проекте мы использовали пять серверов Dell PowerEdge R750. Каждый из них оснащён по последнему слову техники: 10 × 15.36 ТБ NVMe Intel D7, две сетевые карты Mellanox 40G и целых 384 ГБ оперативной памяти. Наша сеть, в свою очередь, построена на выделенных MLAG-свитчах Mellanox SN2410. Всё это внушительное «добро» размещается в нашем собственном дата-центре МТС Москва. А там, к слову, предусмотрены дизельные генераторы и батареи, обеспечивающие до шести часов полной автономии в случае непредвиденных ситуаций.

Само развёртывание у наших инженеров заняло ровно 4 рабочих дня. А потом ещё 3 дня мы кропотливо настраивали пулы и все клиентские шлюзы. В итоге? Мы получили следующую финальную конфигурацию, которая идеально подошла под запросы клиента.

• Мы создали Replication pool с параметром size=3 специально для горячих VM-образов. Это обеспечило клиенту 40 ТБ максимально доступного и быстрого пространства.
• Для бэкапов и так называемых «холодных» данных мы настроили EC 4+2. Такое решение позволило получить 60 ТБ полезной ёмкости, оптимально сбалансировав надёжность и эффективность хранения.
• Разработчики клиента получили CephFS с двумя активными MDS. Это дало им в распоряжение 20 ТБ быстрого, высокодоступного файлового хранилища для всех их проектов.
• Для RGW, нашего S3-совместимого объектного хранилища, мы использовали HAProxy. Нагрузка балансируется сразу на два инстанса, что обеспечивает высокую доступность и отказоустойчивость сервиса.

Стоимость всех работ по развёртыванию и интеграции составила 420 000 рублей. Хотите знать, как система повела себя на деле? Через три месяца после запуска упал один SSD на ноде ceph03. Что произошло? Всего 45 минут, и recovery прошёл полностью автоматически, при этом без малейшего простоя сервисов. Разве это не показатель надёжности? Сейчас клиент использует 68% доступной ёмкости, а мы, конечно, продолжаем полное сопровождение кластера.

Мониторинг и алерты

# Встроенный dashboard
ceph dashboard set-login-credentials admin StrongPass
# Открываем https://ceph01:8443

# Prometheus-модуль
ceph mgr module enable prometheus
# На :9283 метрики, цепляем внешний Prometheus

# Ключевые метрики для алертов
ceph_health_status           # 0=OK, 1=WARN, 2=ERR
ceph_osd_up / ceph_osd_in
ceph_pg_active               # Должно совпадать с ceph_pg_total
ceph_cluster_total_used_bytes / ceph_cluster_total_bytes

Эксплуатационные правила

• И запомните, пожалуйста, это как аксиому: никогда, слышите, никогда не запускайте Ceph-кластер в продакшене с параметрами size=2 и min_size=1! Иначе 'split-brain' вам просто гарантирован, и решать его будет очень непросто и болезненно.
• Знаете, какой лимит мы всегда советуем держать? Никогда не занимайте больше 75% ёмкости вашего хранилища. Почему так? Потому что после 80% производительность начинает деградировать настолько заметно, что это моментально сказывается на работе всей системы. Берегите свои ресурсы!
• Для расчёта PG count по каждому пулу мы всегда используем одну и ту же проверенную формулу: количество OSDs умножаем на 100, а затем делим на replication_size. Очень важный момент: итоговое число всегда округляем строго до ближайшей степени двойки. Иначе будут сюрпризы.
• Если вы ещё не используете NTP, сделайте это прямо сейчас! Он просто *обязателен*. Наша практика показывает: консенсус ваших MON-узлов крайне чувствителен к расхождению времени. Достаточно смещения (skew) всего на 50 мс, и стабильность кластера окажется под угрозой. Зачем рисковать?
• Есть отличный способ поддерживать порядок с PG? Конечно! Мы всегда советуем: обязательно включайте ceph balancer. Эта штука сама следит за равномерным распределением ваших placement groups, снимая с вас лишнюю головную боль. Просто активируйте его — и забудьте о ручной балансировке.
• Бэкап MON-карты: ceph mon getmap -o monmap.bin раз в сутки в отдельное место.

FAQ — частые вопросы о Ceph

Сколько минимум нод нужно для продакшн Ceph?

Три ноды — минимум для replication size=3. Для production с erasure coding рекомендую пять нод.

Какую сеть закладывать под Ceph?

Минимум 10 GbE, рекомендовано 25-40 GbE для кластерной сети. Боевые кластеры работают на 40G Mellanox — комфортный запас под recovery.

Replication vs Erasure Coding — что выбрать?

Replication (size=3) — быстрее, проще в эксплуатации, но 33% usable. EC 4+2 даёт 66% usable, но медленнее на random write. Для горячих данных — replication, для холодных — EC.

Какие диски ставить под OSD?

Enterprise-класс с Power Loss Protection. Идеально — NVMe Intel/Samsung DC-серии. Консьюмерские SSD под Ceph НЕ ставить.

Как подключить Ceph к Proxmox или OpenStack?

Proxmox имеет встроенную интеграцию RBD. OpenStack — через cinder-volume с RBD backend. VMware — через iSCSI-шлюз.