Ceph 15 Octopus GA: разворачиваем через cephadm и смотрим на dashboard для OSD latency

Ceph 15 Octopus вышел в GA в конце марта, но у нас руки дошли до полноценного разворачивания тестового кластера только сейчас - когда стабилизировались точечные патчи 15.2.x и появилось время нормально поковыряться. Главная история релиза - это смена инструмента развёртывания: ceph-deploy официально уступил место cephadm. Посмотрели на практике что это значит.

Зачем вообще менять ceph-deploy

ceph-deploy живёт в репозитории Ceph уже много лет и в принципе работает - мы им пользовались для нескольких небольших кластеров. Но при этом он работает примерно как набор оберток над SSH-командами: зашёл на ноду, поставил пакеты, положил конфиг, запустил демон. Хрупкая конструкция, сильно зависящая от версий Python, путей к бинарям и настроений systemd.

cephadm подходит к задаче иначе: он разворачивает каждый демон Ceph (mon, mgr, osd, mds, rgw) как контейнер - podman или docker - и управляет ими через orchestrator API. Конфиг хранится в самом кластере Ceph (в базе данных mon), а не в файлах на хостах. Добавление ноды - это ceph orch host add, а не ручные манипуляции на новой машине.

Установка: как это выглядит сейчас

На тестовом стенде - три ноды Ubuntu 20.04, по одному NVMe-диску для OSD на каждой. Начало:

curl --silent --remote-name --location \
  https://github.com/ceph/ceph/raw/octopus/src/cephadm/cephadm
chmod +x cephadm
./cephadm add-repo --release octopus
./cephadm install

Затем bootstrap на первой ноде:

cephadm bootstrap --mon-ip <IP первой ноды>

Это один шаг, который поднимает контейнер с mon и mgr, генерирует ключи, инициализирует кластер и открывает dashboard на порту 8443. Раньше мы бы делали примерно то же самое в 5-7 отдельных шагов через ceph-deploy mon create и далее по списку.

После bootstrap добавляем остальные ноды:

ssh-copy-id -f -i /etc/ceph/ceph.pub root@node2
ssh-copy-id -f -i /etc/ceph/ceph.pub root@node3
ceph orch host add node2
ceph orch host add node3

OSD на всех дисках:

ceph orch apply osd --all-available-devices

Оркестратор сам нашёл свободные блочные устройства и начал развёртывание. Без ceph-disk и ceph-volume в ручном режиме. Это приятно.

Общее ощущение: инсталляция стала существенно короче по числу ручных действий. Контейнерная модель добавляет свои сложности (нужен работающий podman или docker, нужен доступ к реестру образов), но для стандартной установки с публичным реестром это не проблема.

Dashboard: смотрим на OSD-level latency

Новый mgr dashboard в Octopus - это React-приложение, которое по ощущениям сделано более серьёзно чем то что было раньше. Нас интересовал конкретный вопрос: можно ли смотреть на latency на уровне отдельных OSD без Prometheus/Grafana.

Зашли в раздел OSDs -> OSD Performance. Там есть метрики: commit latency и apply latency в разбивке по OSD-ам. Данные обновляются в реальном времени, можно выбрать конкретный OSD и смотреть на его историю в рамках сессии.

Несколько наблюдений:

• Разброс latency между OSD. На одинаковых дисках мы увидели не идеальную картину - один OSD стабильно давал commit latency в полтора раза выше двух других. Покопались: очередь записи на хосте была занята фоновым scrub'ом. Dashboard это не объясняет, но сам факт аномалии увидели быстро.
• Глубина истории минимальная. Dashboard показывает последние минуты, не часы. Для понимания тренда за смену - нужен Prometheus. Встроенного долгосрочного хранения метрик нет.
• Алертов из dashboard нет. Всё визуальное, без thresholds и нотификаций. Мониторить 24/7 через браузер - не вариант.

Вывод: dashboard полезен для быстрой диагностики в моменте и для обучения - удобно видеть что происходит с кластером без CLI. Для production-мониторинга он дополняет, но не заменяет стек с Prometheus и Grafana.

Crimson OSD: смотрели, не трогали

В Octopus есть предварительная версия Crimson OSD - переписанного OSD-демона на базе Seastar/DPDK, который нацелен на работу с NVMe без блокирующих syscall'ов. Концептуально интересно: классический OSD в Ceph имеет много мест где он блокируется на I/O, Crimson должен с этим разобраться через async I/O на уровне фреймворка.

На практике в Octopus это developer preview. Собирается отдельно, не входит в стандартные пакеты, документация скудная. Мы посмотрели на соответствующие страницы в вики и решили не рисковать тестовой средой ради чего-то что само авторами обозначено как экспериментальное. Это разумная граница.

Текущее состояние

Тестовый кластер работает, развёртывание через cephadm оставило хорошее впечатление по сравнению с тем что было. В managed-сопровождение интегрируем опыт с оговоркой: для production-кластеров ещё хочется понаблюдать за поведением cephadm при добавлении/удалении нод под нагрузкой - в тестовой среде нагрузки не было. Следующий шаг - нагрузочный тест с fio и замер латентности при параллельном scrub.