Ceph 15 Octopus в dev: смотрим на cephadm как замену ansible-ceph для раскатки кластеров

Ceph 15 Octopus пока в разработке - GA не объявлен, но dev-версии уже достаточно вменяемые, чтобы их можно было покрутить в лабораторных условиях. Мы подняли небольшой стенд и посмотрели на то, что действительно интересно: cephadm как новый способ раскатывать кластеры. Спойлер: в продакшне остаёмся на Nautilus, но кое-что зафиксировать уже есть.

Клиентские managed-кластеры у нас сейчас на Nautilus (14.x). Он вышел в марте прошлого года, к этому моменту уже достаточно обкатан. Смотреть на Octopus мы начали не потому что жмёт, а потому что главная тема нового релиза - cephadm-оркестратор - затрагивает то, как мы вообще ставим и обслуживаем кластеры.

Как раскатываем сейчас

У нас ansible-ceph - это ceph-ansible от Red Hat. Работает, роли известные, поведение предсказуемое. Написали поверх свои обёртки под конкретные конфигурации клиентов: выбор OSD-бекенда, настройка CRUSH-правил, интеграция с мониторингом.

Проблема не в том, что ansible-ceph плохой. Проблема в том, что он про деплой, но не про операционную жизнь кластера. Добавить OSD, вывести ноду, обновить - всё это требует отдельных плейбуков, отдельной логики, ручного контроля состояния. Оркестратор который знает про внутреннее состояние Ceph - это другая история.

Что такое cephadm

Cephadm появился ещё в Nautilus как технологическое превью, но в Octopus это становится основным способом управления кластером. Идея: оркестратор живёт прямо внутри Ceph (через ceph-mgr), умеет разворачивать демоны через контейнеры (systemd + podman или docker), и знает про состояние кластера нативно - не через SSH и инвентори, как Ansible.

Раскатка нового кластера через cephadm выглядит так: ставишь пакет на первую ноду, делаешь cephadm bootstrap, дальше кластер через ceph orch принимает спецификации где что должно жить. OSD по дискам, MON по хостам, MDS - всё через ceph orch apply.

Мы прогнали это на трёхнодовом лабораторном стенде. Первичный bootstrap - быстро, без неожиданностей. Добавление второй и третьей ноды через ceph orch host add - тоже без танцев с инвентори.

Где начинаются вопросы:

• Кастомные конфигурации - в ansible-ceph у нас накоплено несколько нестандартных сценариев: разные CRUSH-иерархии для разных клиентов, OSD с ручным маппингом WAL/DB на NVMe. В cephadm это выражается через yaml-спецификации, и документация по краевым случаям пока скудная. Не невозможно, но требует разбора.
• Идемпотентность - ansible-плейбук можно запустить повторно и он ничего не сломает. У cephadm свой подход к идемпотентности, и на dev-версии пара граничных ситуаций дала неожиданный результат. Это dev, претензий нет.
• Интеграция с существующими инструментами - у нас Prometheus + Grafana для мониторинга всего, включая Ceph. cephadm умеет разворачивать Prometheus и Grafana самостоятельно, прямо внутри кластера. Это удобно для чистой установки, но у нас уже есть внешний мониторинг. Как они уживаются - отдельный вопрос, пока не копали.

Dashboard v2

В Nautilus появился встроенный dashboard, в Octopus его переписывают серьёзнее. Angular-приложение с более полным охватом операций: управление OSD, pool, RBD-томами, NFS прямо через UI.

Мы посмотрели и честно признаем - для клиентов которым нужно что-то видеть и иногда делать простые операции без SSH это может быть удобно. Для ежедневной работы мы всё равно смотрим в Grafana, там нагляднее с историей метрик. Dashboard - это скорее консоль управления, не мониторинг.

BlueStore improvements

В Octopus идут оптимизации BlueStore: улучшенная работа с metadata, снижение write amplification на NVMe. На dev-версии гонять нагрузочные тесты и делать выводы - занятие неблагодарное. Зафиксируем как направление, вернёмся к замерам на GA.

На продакшн-кластерах у нас BlueStore с Nautilus работает нормально. Luminous к Nautilus мы перевели год назад - и это был осознанный апгрейд с реальным эффектом на latency. Octopus в этом смысле не революция, а эволюция.

Что из этого следует

Менять ansible-ceph на cephadm прямо сейчас - нет. Не потому что cephadm плохой, а потому что:

• Octopus ещё не в GA, и менять инструмент раскатки на dev-версии - это осознанный риск.
• У нас накоплено несколько сотен строк ролей и плейбуков под конкретные конфигурации клиентов. Переехать за неделю не получится.
• Поведение cephadm на нестандартных конфигурациях нужно сначала проверить, а потом переносить.

Что будем делать: дождёмся GA Octopus, прочитаем release notes по cephadm, возможно поднимем один новый кластер через него и посмотрим в реальных условиях. Миграцию существующих кластеров с ansible-ceph не планируем - это работа без очевидного выигрыша для уже работающих установок.

Nautilus в продакшне остаётся. Он стабильный, мы его знаем, клиентские кластеры на нём работают без вопросов. Смотреть на Octopus интересно - но смотреть и ехать это разные истории.