Ceph в маленьком кластере: честно о сложности

MAATRIX

Рано или поздно в обсуждении отказоустойчивого хранилища для Proxmox всплывает Ceph — «правильное» решение, которое рекомендуют статьи, доклады и сам Proxmox в документации. И вы задаётесь вопросом: если у меня 3-5 узлов, а не дата-центр, стоит ли вообще связываться? Короткий честный ответ — не всегда, и в этой статье разберём почему, без маркетинга и без запугивания.

Что Ceph действительно даёт

Начнём с того, что Ceph — не миф и не переоценённая технология. Это работающая распределённая система хранения, и на своём масштабе она решает реальные задачи, которые больше никто так не решает.

Во-первых, это отсутствие единой точки отказа на уровне хранилища. Данные разбиваются на объекты и реплицируются между узлами (обычно 3 копии), поэтому выход из строя одного узла или одного диска не означает потерю данных и не останавливает виртуальные машины — Ceph продолжает отдавать данные с оставшихся реплик.

Во-вторых, это автоматическая репликация и самовосстановление. Если узел падает, кластер сам начинает пересобирать недостающие копии данных на оставшихся узлах (rebalancing), без ручного вмешательства администратора. Если диск деградирует, Ceph замечает это через собственные механизмы мониторинга и может вывести его из эксплуатации до того, как он полностью откажет.

В-третьих — интеграция с Proxmox VE «из коробки». Через pveceph кластер разворачивается прямо из веб-интерфейса или CLI, RBD (RADOS Block Device) подключается как storage backend без дополнительных прослоек, живая миграция VM работает без общего NFS/iSCSI сервера сбоку. Формально это выглядит как идеальное решение: одна технология, полная интеграция, никаких костылей.

Проблема в том, что все эти преимущества считаются в предположении «десятки-сотни узлов, много дисков, много трафика». На масштабе 3-5 узлов картина куда сложнее.

Почему Ceph спроектирован не под ваш масштаб

Ceph изначально создавался под задачи вроде CERN и крупных облачных провайдеров — тысячи OSD (объектов хранения, по сути отдельных дисков), сотни узлов, петабайты данных. Вся архитектура — CRUSH-алгоритм распределения данных, множество placement groups, иерархия monitor/manager/OSD демонов — рассчитана на то, что случайность и статистика на большом числе устройств сглаживают неравномерность нагрузки и риски.

На 3-5 узлах эта статистика не работает. Если у вас 3 узла и на каждом по 2-3 диска, вы получаете 6-9 OSD — и большая часть архитектурных плюсов Ceph, связанных именно с масштабом (равномерное распределение нагрузки по сотням дисков, устойчивость к одновременному выходу из строя нескольких узлов, эффективное использование erasure coding), либо не проявляется вообще, либо проявляется в урезанном виде.

При этом вся операционная сложность — три типа демонов на каждом узле (mon, mgr, OSD, опционально MDS для CephFS), собственная файловая структура, собственный набор команд для диагностики (ceph -s, ceph osd tree, ceph health detail, rados df и десяток других) — остаётся ровно такой же, как в кластере на 100 узлов. Ceph не становится «проще», если вы используете его на скромном железе — сложность фиксирована архитектурой, а не масштабом развёртывания.

Грубая аналогия: вы не покупаете дата-центровый маршрутизатор на 48 портов ради домашней сети из 4 устройств только потому, что «это правильное enterprise-решение». Технически он справится, но обслуживание и порог входа несопоставимы с задачей.

Требования к сети — то, что чаще всего недооценивают

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

Официальные рекомендации Ceph говорят о выделенной сети от 10GbE для продакшена, а для тяжёлых нагрузок — о раздельных сетях: одна для клиентского трафика (public network), другая для репликации между OSD (cluster network). На практике многие небольшие развёртывания делаются на обычной 1GbE сети — просто потому что это то, что есть на арендованном сервере или в домашней лаборатории.

На 1GbE вы упираетесь в пропускную способность практически сразу. Одна гигабитная линия — это теоретический потолок около 125 МБ/с, и это без учёта накладных расходов протокола, конкуренции с клиентским трафиком VM и того, что при записи данные должны уйти на 2-3 узла одновременно. Задержка сети (latency) здесь важнее пропускной способности: каждая запись ждёт подтверждения от реплик, и лишние доли миллисекунды сетевой задержки умножаются на каждую операцию.

Результат — производительность Ceph на маленьком кластере с обычной сетью часто оказывается заметно ниже, чем интуитивно ожидает администратор, привыкший к цифрам локального NVMe или даже простого RAID. Это не значит, что Ceph "сломан" — это значит, что архитектура спроектирована под сеть, которой у вас, вероятно, нет.

Что реально стоит проверить перед внедрением:

# базовая проверка задержки между узлами кластера
ping -c 20 10.0.0.12

# проверка реальной пропускной способности (iperf3 нужно поставить на оба узла)
# на одном узле:
iperf3 -s
# на другом:
iperf3 -c 10.0.0.12 -t 30

Если у вас в результате задержка нестабильна или пропускная способность едва достигает паспортного 1Gbps, добавление отдельной сети для Ceph (даже 2.5GbE/10GbE, отдельным адаптером) — не опциональная оптимизация, а по сути условие, при котором Ceph вообще имеет смысл рассматривать.

Кривая обучения и эксплуатация

Разница между «настроить Ceph один раз» и «эксплуатировать Ceph» — огромная, и именно она чаще всего недооценивается на этапе планирования.

Первичная настройка через pveceph действительно относительно проста:

# на первом узле
pveceph init --network 10.0.0.0/24
pveceph mon create
pveceph mgr create

# на каждом узле с дисками под OSD
pveceph osd create /dev/sdb

Дальше создаётся pool, RBD-хранилище подключается в Proxmox — и первое время всё работает. Проблемы начинаются, когда что-то идёт не так, а идёт не так у Ceph по-своему, не так, как у привычных систем.

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

• Кластер уходит в HEALTH_WARN и стоит на месте. Причин может быть с десяток: не хватает places groups, не сошёлся crush map после смены диска, clock skew между узлами (Ceph чувствителен к рассинхронизации времени), забитый диск под 85% (Ceph сам блокирует запись, чтобы не потерять данные). Диагностика требует понимания внутренней модели, а не просто перезагрузки сервиса.
• Один упавший диск подвешивает производительность всего пула. Пока Ceph пересобирает недостающие копии (backfill/recovery), кластер отдаёт часть пропускной способности сети и дисков именно на этот процесс — и на маленьком кластере с 1GbE это заметно просаживает работу всех VM, а не проходит незаметно, как в большом кластере с запасом ресурсов.
• Неверный размер placement groups, выбранный на старте, аукается позже — увеличение или уменьшение PG на живом кластере с данными — операция, требующая аккуратности и времени, а не изменение одной настройки.
• CephFS и RBD — разные вещи с разной сложностью. Если вам нужна не только блочная подсистема для дисков VM (RBD), а ещё и общая файловая система (CephFS), это отдельный набор демонов (MDS) и отдельный набор проблем.

Ничего из этого не является багом Ceph — это следствие того, что вы управляете распределённой системой, а не локальным RAID-массивом. Но именно это качество — «нужно понимать, что происходит внутри» — и есть та самая скрытая цена, которая не видна на этапе «давайте попробуем, выглядит несложно».

Сравнение честности ожиданий и реальности для кластера 3-5 узлов:

Когда Ceph всё же оправдан на маленьком масштабе

Нечестно было бы сказать, что Ceph никогда не подходит для маленьких кластеров. Есть конкретные ситуации, где выбор оправдан:

• У вас уже есть или планируется рост за пределы 5 узлов, и вы сознательно закладываете архитектуру на вырост, а не под текущий момент.
• Вам нужна именно распределённая отказоустойчивость на уровне хранилища без внешнего NAS/SAN — например, инфраструктура территориально распределена или требования безопасности/комплаенса исключают единую точку отказа даже ценой сложности.
• В команде уже есть опыт эксплуатации Ceph (не «читали статью», а реально администрировали) — тогда порог входа не является барьером.
• Есть возможность выделить отдельную сеть 10GbE+ под кластерный трафик, и это не разовая настройка, а часть бюджета на инфраструктуру.
• Задача принципиально не решается через RBD/CephFS альтернативы — например, нужен единый объектный сторедж (S3-совместимый через RGW) для приложений, а не только диски VM.

Если хотя бы 2-3 пункта из списка про вас — Ceph имеет смысл рассматривать всерьёз, и тогда стоит закладывать время на обучение как часть проекта, а не как непредвиденный риск.

Честная альтернатива для действительно маленького кластера

Если ваш случай — это 3-5 узлов, без чёткого плана расти в ближайший год, без выделенной команды под хранилище, и единственная причина рассмотреть Ceph — «это правильная enterprise-технология, все рекомендуют», — стоит сначала честно взвесить более простые варианты.

NFS-сервер. Один выделенный сервер (или пара с репликацией) с NFS-экспортом, подключённым в Proxmox как shared storage. Настройка — на порядок проще, диагностика — понятная и знакомая почти любому линукс-администратору, отказоустойчивость ниже (единая точка отказа на самом NFS-сервере, если не резервировать), но для многих сценариев этого достаточно. Подробнее про то, какие типы хранилищ в Proxmox когда уместны, разобрано в статье про хранилища в Proxmox: local, LVM-thin, ZFS, NFS.

ZFS с репликацией. Локальный ZFS на каждом узле плюс встроенная в Proxmox репликация снапшотов между узлами (pvesr) — не даёт мгновенного failover как Ceph (при падении узла нужно вручную или полуавтоматически поднимать VM на другом узле из последнего снапшота), зато радикально проще в эксплуатации, не требует отдельной быстрой сети и полностью укладывается в штатные средства Proxmox без дополнительной системы поверх.

Обе альтернативы не дают того, что даёт Ceph — синхронной репликации без потери данных при живом сбое узла. Это осознанный компромисс: вы платите некоторой доступностью и автоматизмом ради простоты эксплуатации. Для 3-5 узлов без выделенного специалиста по хранилищам это чаще разумный компромисс, чем нет.

Кстати, если рассматриваете кластер именно из 2 узлов — там отдельная проблема с кворумом, из-за которой такая конфигурация вообще плохо подходит для отказоустойчивости независимо от выбора хранилища: смотрите разбор в статье про кластер Proxmox из двух узлов и про кворум и зачем нужен третий узел.

Частые вопросы