Ceph Nautilus в production: встроенный Dashboard и прирост IOPS на BlueStore без замены железа

Nautilus - четырнадцатая версия Ceph, вышедшая в GA в начале апреля - это первый релиз, где Dashboard вырос из категории «игрушка» во что-то реально пригодное для ежедневной работы. Мы обновили один из production-кластеров и фиксируем результаты по горячим следам.

Кластер под управлением managed-инфраструктуры - три узла с NVMe для BlueStore, порядка десяти клиентских сервисов, смесь RBD и CephFS. Решение обновляться пришло не внезапно: Mimic (13.2) работал стабильно, но накопился ряд мелких раздражителей, и Nautilus обещал их закрыть.

Зачем вообще обновлялись

Главный раздражитель - мониторинг. У нас был самописный bash-скрипт, который парсил вывод ceph status и ceph osd df, кормил метрики в Prometheus через textfile collector, а результаты рисовал в Grafana. Скрипт работал, но это именно тот случай, когда поддерживать становилось дороже, чем написать заново. Каждый раз при изменении формата вывода - а в Luminous и Mimic формат менялся - скрипт ломался в каком-нибудь углу.

В Mimic появился Dashboard как mgr-плагин, но он требовал отдельных паролей, работал через HTTP без TLS из коробки и выдавал read-only доступ к базовой статистике. Скорее proof-of-concept, чем инструмент.

Nautilus переписал Dashboard с нуля. Теперь это полноценный Angular-фронтенд с бэкендом на Python в mgr-плагине, с поддержкой TLS, ролевой моделью, управлением пулами, OSD, RBD-образами и CephFS прямо из интерфейса. Prometheus-метрики из нативного mgr-плагина prometheus тоже переработаны - количество метрик выросло, и они нормально совместимы с Grafana.

Процесс обновления

Обновляли последовательно: сначала monitors, потом managers, потом OSDs группами. Официальная документация на этот раз подробная - Nautilus требует, чтобы перед переходом кластер был в состоянии HEALTH_OK, без каких-либо предупреждений. Пришлось заранее разобраться с одним mds up:standby-replay предупреждением, которое висело несколько недель и на которое никто не обращал внимания.

Миграция BlueStore - отдельный пункт. У нас все OSD уже были на BlueStore (переходили ещё при Luminous), поэтому этот шаг пропустили. Те, кто ещё держит FileStore - в Nautilus это последний шанс спокойно мигрировать, потому что FileStore помечен deprecated.

Само обновление через ceph-ansible заняло несколько часов. Из неожиданного: после обновления mgr понадобилось явно включить модуль Dashboard через ceph mgr module enable dashboard и создать пользователя. Это не произошло автоматически - вероятно, особенность нашей конфигурации ceph-ansible.

Dashboard: что реально работает

Скрипт мониторинга мы отключили на второй день. Dashboard закрыл все сценарии, которые были реализованы через него:

• Текущий статус кластера - HEALTH, распределение данных, recovery progress при ребалансировке.
• Детализация по OSD - состояние, latency, использование по каждому диску. Раньше это был ceph osd df через терминал.
• RBD-образы - список, размер, провижн. Управлять ими прямо из интерфейса - это неожиданно удобно для операций, которые раньше требовали rbd из командной строки.
• Prometheus-интеграция - mgr-плагин prometheus теперь экспортирует метрики на отдельном порту, и они нормально подцепились к существующей Prometheus/Thanos-схеме.

Grafana-дашборды пришлось переделать под новые имена метрик - часть метрик из самописного скрипта называлась иначе, чем нативные. Час работы, зато теперь без самописной прослойки.

Чего нет - тонкой настройки алертов из интерфейса. Для этого всё равно идём в Alertmanager. Dashboard показывает текущие алерты Ceph, но настраивать правила через него нельзя. Не критично, но стоит знать.

BlueStore и производительность

Это честно говоря стало приятным сюрпризом. Nautilus принёс несколько оптимизаций BlueStore: улучшенный кэш объектов, изменения в механизме deferred writes, настройки для NVMe-дисков.

Мы не проводили формального бенчмарка до/после - это production-кластер, а не стенд. Но есть метрики Prometheus за несколько недель до обновления и после. Пиковые IOPS на RBD-пулах выросли примерно на 15% при том же профиле нагрузки от клиентских сервисов. Средняя latency на операциях записи чуть снизилась.

Точные цифры приводить не будем - слишком много переменных в production. Но тенденция чёткая и воспроизводится несколько дней после обновления, не списать на артефакт.

Отдельно: в Nautilus появилась поддержка bluestore_cache_autotune - автоматическая подстройка кэша под доступную память. Включили, наблюдаем. По ощущениям, OSD стали меньше жаловаться на давление памяти в часы пиковой нагрузки.

Итог на сейчас

Переход с Mimic на Nautilus прошёл без деградации сервиса и убрал самую раздражающую часть операционки - самописный скрипт мониторинга. Dashboard в нынешнем виде - полноценный инструмент, а не демонстрация возможностей.

По производительности результат лучше, чем ожидали. «15% IOPS без замены железа» - это формулировка, которую приятно писать в отчёт клиенту, хотя и с оговорками про production-специфику.

Следующий шаг - смотрим на rbd mirroring в Nautilus, там тоже заявлены улучшения для geo-репликации. Пока это в планах, но не в production.