Ceph-кластер в среднем бизнесе: когда он оправдан и как его собрать без боли

Здравствуйте! Я Евгений Семёнов, директор ITFresh. Сегодня расскажу вам одну историю, которая случилась в октябре 2025 года. Наш клиент — крупная логистическая компания с 80 сотрудниками и собственным дата-центром под Москвой — оказался в очень непростой ситуации. Представьте: у них внезапно закончилась поддержка дорогостоящего хранилища NetApp FAS2750. Мало того, что годовое продление стоило бы сумасшедшие 720 тысяч рублей, так ещё и запчасти пришлось бы ждать 6-8 недель! Можете себе представить такой простой? Им срочно нужно было мощное альтернативное распределённое хранилище на сотни терабайт. Главная задача: обеспечить работу виртуальных машин на Proxmox и, конечно, их корпоративных файловых шар. Мы нашли выход: развернули Ceph-кластер на пяти узлах. В итоге получили 76 ТБ доступной ёмкости, и всё это обошлось в 3.4 миллиона рублей. Хотите знать, кому Ceph подходит идеально и как мы его внедряем? Об этом сейчас и поговорим.

Когда Ceph оправдан, а когда нет

Ceph — это не просто, система действительно сложная. И, честно говоря, все инвестиции в неё — это и время админа, и затраты на сеть, и само железо — окупаются только при очень конкретных условиях. Вот моё главное правило:

Ceph нужен, если одновременно:

• Итак, у вас уже есть четыре или даже больше физических серверов, которые готовы стать частью вашего хранилища.
• При этом объем ваших данных стартует от 20 ТБ и стабильно растет на внушительные 30% или даже больше ежегодно.
• Вам нужна серьезная отказоустойчивость, способная выдержать одновременный выход из строя сразу двух узлов или нескольких дисков.
• Ваша инфраструктура требует как минимум двух типов доступа к данным: например, VM-диски через RBD плюс файловая шара (CephFS) или объектное хранилище S3 (RGW).
• В вашей команде есть толковый администратор с серьезным опытом работы с Linux, который готов погрузиться в изучение Ceph? Это отличный старт.

Ceph НЕ нужен, если:

• Если у вас всего один-два VM-сервера и требуется пространство для 10-15 виртуальных машин, то, пожалуй, ZFS с репликацией будет намного дешевле и проще в настройке.
• В офисе у вас стоит всего один сервер? Ceph не запустится — ему минимум три узла подавай.
• Отсутствует выделенная сеть 10G+? На 1G Ceph будет работать просто невыносимо медленно, это факт.
• Если бюджета на выделенного Linux-админа нет, помните: даже с аутсорсинговой поддержкой Ceph будет требовать минимум 4-8 часов ежемесячного внимания.

Архитектурные блоки Ceph

На одном сервере иногда прекрасно уживаются сразу несколько ролей Ceph. Обычно мы делаем так: на первых трёх узлах ставим MON, MGR и OSDs вместе. А остальные узлы уже используем чисто под OSD — для хранения данных.

Типовая конфигурация 5-узлового кластера

Какое железо мы подбираем, когда работаем с клиентом, у которого примерно 50-100 рабочих мест? Вот наш типовой набор:

Каждый узел (5 шт):
  Supermicro SuperServer 2U б/у
  2 × Intel Xeon Silver 4316 (20 core total)
  128 ГБ DDR4 ECC
  2 × 480 ГБ SSD (ZFS mirror для ОС)
  2 × 1.92 ТБ NVMe U.2 (Samsung PM9A3) — для WAL+DB
  10 × 12 ТБ HDD SAS 12G 7200rpm — OSD-данные
  2 × 25G Mellanox ConnectX-5 (public+cluster сеть)
  Redundant PSU 1000W
  Total raw: 600 ТБ × 5 узлов = 3 ПБ
  Usable at size=3: ~1 ПБ
  Usable at EC 4+2: ~2 ПБ

Что касается сети: мы используем 25G LACP, завязанный на два коммутатора Mikrotik CRS520 с MLAG. И очень важный момент — обязательно разделяем трафик: отдельные VLAN идут для 'public' (это всё, что касается клиентских данных) и для 'cluster' (для репликации между OSD, чтобы ничего не мешало друг другу).

Установка через cephadm

Начиная с версии Quincy (вышла в 2022 году), процесс установки Ceph стал гораздо проще. Теперь всё делается через cephadm, а все компоненты упакованы в containerd. Это прямо сильно облегчило нам жизнь при развёртывании!

# На первом узле
apt install cephadm
cephadm bootstrap --mon-ip 10.30.0.11 --initial-dashboard-user admin
# Получаем URL dashboard + пароль

# На других узлах — устанавливаем SSH-ключ от bootstrap-узла
ssh-copy-id root@10.30.0.12
ssh-copy-id root@10.30.0.13
ssh-copy-id root@10.30.0.14
ssh-copy-id root@10.30.0.15

# Добавляем в кластер
ceph orch host add node02 10.30.0.12 _admin
ceph orch host add node03 10.30.0.13 _admin
ceph orch host add node04 10.30.0.14
ceph orch host add node05 10.30.0.15

# MON на первых трёх + MGR
ceph orch apply mon 3
ceph orch apply mgr 2

# Добавляем OSD (все свободные диски)
ceph orch apply osd --all-available-devices

Через 10-20 минут кластер готов. Проверяем ceph -s — должно быть HEALTH_OK.

BlueStore: правильное размещение WAL+DB

BlueStore — это наш стандартный движок хранения. Если вам нужна высокая производительность, жизненно важно вынести WAL и DB на быстрые NVMe-диски. А основные данные, конечно, можно оставить на обычных HDD. Наша рекомендация здесь простая:

• WAL — 1 ГБ на OSD.
• База данных (DB) занимает примерно 4% от объема OSD. Для примера: если у вас 12 ТБ HDD, то DB потребует 480 ГБ.
• Отсюда вывод: одного NVMe-диска на 1.92 ТБ будет достаточно, чтобы обслужить сразу четыре HDD. Ведь 480 ГБ, умноженные на четыре, дают 1920 ГБ.

Команда создания:

ceph orch daemon add osd node01:data_devices=/dev/sda,db_devices=/dev/nvme0n1
# повторить для каждой связки HDD+NVMe

Иначе, поверьте, всё будет работать в разы медленнее! Запись на HDD, особенно случайная, просто убивает производительность, а WAL как раз требует невероятной скорости. Так что, пожалуйста, не экономьте на NVMe — оно того стоит.

Пулы и размеры репликации

Создаём пулы под разные задачи:

# Для VM-дисков Proxmox — реплика 3, быстрый
ceph osd pool create rbd-vm 128 128 replicated
ceph osd pool set rbd-vm size 3
ceph osd pool set rbd-vm min_size 2
ceph osd pool application enable rbd-vm rbd

# Для бэкапов — Erasure Coding 4+2 (5 узлов достаточно)
ceph osd erasure-code-profile set ec42 k=4 m=2 crush-failure-domain=host
ceph osd pool create backup-ec 64 64 erasure ec42
ceph osd pool set backup-ec allow_ec_overwrites true

# Для файловой шары — реплика 3, CephFS
ceph fs volume create corpfs

Для виртуальных машин мы всегда используем replicated size=3. Да, это расходует больше места, но зато работает значительно быстрее, чем Erasure Coding. А вот для архивов и бэкапов, где важна экономия, а скорость не так критична, идеально подходит EC 4+2 или 8+2. Это позволяет сэкономить от 33% до 50% дискового пространства, хоть и работает немного медленнее.

RBD для Proxmox

Интегрировать Ceph с Proxmox — проще простого! Заходите в GUI: Datacenter, потом Storage, затем Add, и выбираете RBD.

Pool:         rbd-vm
Monitor(s):   10.30.0.11,10.30.0.12,10.30.0.13
User:         admin
KeyringFile:  /etc/pve/priv/ceph/rbd-vm.keyring

Как только всё настроено, вы можете создавать диски для своих виртуальных машин прямо на Ceph-пуле. А знаете, что самое крутое? Live migration между узлами Proxmox работает просто мгновенно! Диск при этом никуда не перемещается, двигается только сам процесс виртуальной машины.

CephFS для файловых шар

CephFS — это полноценная файловая система, она полностью совместима с POSIX и, конечно, работает прямо поверх Ceph. Её можно без проблем смонтировать на любой Linux-машине, используя либо FUSE, либо нативный kernel-client. А для тех, кому нужно работать с Windows, мы настраиваем Samba Gateway.

# На Linux-клиенте
mount -t ceph 10.30.0.11:6789:/ /mnt/corp \
  -o name=admin,secret=AQCTxAlnwsw6CRAA...

# Либо через fstab
10.30.0.11,10.30.0.12,10.30.0.13:/ /mnt/corp ceph \
  name=admin,secretfile=/etc/ceph/admin.secret,_netdev 0 2

Для Windows-клиентов мы делаем так: ставим Samba вместе с ceph-volume, а затем экспортируем SMB-шару, используя CephFS как бэкенд.

RGW как S3-совместимый объектный storage

И, конечно, Ceph отлично подходит для бэкапов — будь то Veeam или Proxmox PBS. А ещё он идеален для хранения объектов различных приложений. В общем, вариантов масса:

ceph orch apply rgw corp --port=7480
# Создаём пользователя
radosgw-admin user create --uid=backup --display-name="Backup User"
# Получаем access_key и secret_key

Дальше в Veeam или Proxmox PBS указываем endpoint http://ceph-rgw.example.ru:7480 и полученные ключи.

Кейс: миграция логистической компании с NetApp

Хронология проекта (32 рабочих дня):

1. **Недели 1-2:** Начинаем с детального аудита вашего NetApp (напомним, там занято 36 ТБ). Одновременно проектируем будущий Ceph-кластер, который будет состоять из пяти узлов.
2. **Недели 3-4:** Приступаем к закупке: пять б/у серверов Supermicro, 25G-коммутатор Mikrotik, плюс все нужные кабели DAC. После этого сразу монтируем оборудование в стойку и настраиваем сеть.
3. **Недели 5-6:** Это уже кульминация! Устанавливаем Debian 12, настраиваем cephadm bootstrap. Далее — самое интересное: поднимаем наш новенький 5-узловой Ceph-кластер и создаем все необходимые пулы.
4. На седьмой неделе, когда пришло время проверять систему на прочность, мы взялись за тестирование производительности. Работали с `fio` и `rados bench` – всё по классике. Представляете, на RBD-пуле удалось выжать 38 000 IOPS при случайном чтении 4K блоков! А последовательная скорость? Целых 2.4 ГБ/с. Вот это мощь!
5. На протяжении восьмой и девятой недель мы решали непростую задачу: мигрировали 24 виртуальные машины. Переезд был с Proxmox+NetApp на новенькую связку Proxmox+Ceph. И что самое интересное? Всё это происходило в онлайне, не останавливая работу! Мы применяли `qm move-disk`, и на каждую VM уходило от получаса до полутора часов. По-моему, отличный результат.
6. Десятая неделя была целиком посвящена миграции файловых шар. Как их перенести надежно и безболезненно? Мы решили использовать проверенную комбинацию: `robocopy` для копирования, а затем подключили SMB Gateway, чтобы всё легло ровненько на CephFS. Работа на удивление быстро завершилась.
7. На одиннадцатой неделе мы подключили RGW и сразу же интегрировали его с Proxmox PBS. Знаете, что это дало? Бэкапы всех виртуальных машин теперь просто летят в Ceph-S3! Забудьте о медленных сохранениях, с этим решением процесс стал молниеносным.
8. И вот двенадцатая, финальная неделя! Здесь мы доводили всё до идеала. Настроили полный мониторинг: `Prometheus` вместе с `Grafana` и, конечно же, `CephExporter`. Разработали удобные дашборды, чтобы вся картина была на виду. Затем что? Обучили администратора клиента, подробно показав, как управлять новой системой. И, разумеется, передали все доступы и необходимую документацию. Клиент теперь полностью в курсе!

Давайте посчитаем бюджет. Железо (мы использовали б/у, что очень выгодно) обошлось в 2.4 млн рублей, сеть — 580 тысяч, а наши услуги — 460 тысяч. Итого, общая сумма составила 3.44 млн рублей. А теперь сравните: годовое продление того самого NetApp стоило 720 тысяч, а новая аналогичная система от NetApp вытянула бы 9-11 миллионов! Выгода очевидна, верно? Наше решение окупилось для клиента уже в первый год.

Мониторинг и ежедневная эксплуатация

• ceph -s — общий статус, должно быть HEALTH_OK или HEALTH_WARN с причиной.
• ceph osd tree — карта OSD по узлам.
• ceph df — размер каждого пула и usage.
• ceph osd perf — latency каждого OSD.
• Для мониторинга мы выстроили чёткую цепочку: `Prometheus` собирает все метрики через `ceph-exporter`. А затем данные красиво ложатся в `Grafana`, где мы используем официальный дашборд. Максимальная наглядность, что тут говорить!
• Конечно, куда же без алертов? Мы настроили самые важные: оповещение при падении OSD дольше 5 минут, при появлении неактивного PG, когда кластер приближается к заполнению (больше 80% — `near-full`), и если восстановление занимает больше 24 часов. Мы ведь не хотим пропустить что-то серьезное, верно?

FAQ — Ceph для бизнеса

Ceph — это сложно. Нужен ли он среднему бизнесу?

Нужен, если одновременно: 1) виртуалок 20+; 2) нужна отказоустойчивость без простоя (SSD и HDD disks fail); 3) рост объёма данных прогнозируется 30-50% в год. Для офиса 20-30 мест со статичной нагрузкой и ZFS-репликацией Ceph — overkill. Для 50+ мест с растущими VM, S3-бэкапами, файловыми шарами — оправдан.

Сколько минимум узлов для прод-Ceph?

Три — минимум для кворума monitor и для size=3 репликации. Но при этом вы теряете только один узел безопасно. Оптимум — 4-5 узлов: можно потерять два одновременно без потери данных. Каждый узел: 2 CPU / 32 ГБ RAM / 4-8 OSD (SSD или NVMe). Сеть — обязательно 25G или 10G минимум.

BlueStore или FileStore?

BlueStore — начиная с Luminous (2017) это дефолт. FileStore уже deprecated. В 2026 году никаких FileStore — всегда BlueStore. WAL и DB на NVMe, основные данные на SSD/HDD. Для HDD-only нужны отдельные NVMe-диски для WAL+DB, иначе производительность будет в разы хуже.

Ceph vs NetApp/EMC для МСБ?

NetApp/Dell EMC — коробочное решение с техподдержкой, 'просто работает'. Стоимость — 3-8 млн руб за начальный уровень + 400-900 тыс руб/год поддержка. Ceph — open source, стоит сэкономленных денег, но требует админа с опытом. Для компании, которая может себе позволить Ceph-админа (своего или через аутсорс), Ceph даёт 2-3x экономии.

Сколько стоит развёртывание Ceph-кластера на 50 ТБ usable?

5 серверов Supermicro с 10× 12ТБ HDD + 2× 1.92ТБ NVMe каждый (для WAL+DB) — около 2.4-2.8 млн руб б/у. Сеть 25G (коммутатор + карты) — 600-900 тыс руб. Работа под ключ (установка, настройка, обучение администратора) — от 420 тыс руб. Итого ~3.5-4 млн руб против 8-12 млн за NetApp-аналог.