Ceph 18 Reef: обновляем production-кластер с Quincy и меряем прирост на SSD

Ceph 18 Reef получил статус GA в середине августа. Мы с этим релизом пересеклись вовремя: как раз вели плановое расширение Ceph-кластера у клиента на управляемой инфраструктуре, и апгрейд с Quincy до Reef встал в план естественным образом. Заодно решили потестировать обновлённый процесс через cephadm - сообщество его существенно переработало.

Что нас привлекло в Reef

Changelog у Ceph традиционно длинный. Три вещи, ради которых мы реально двигались:

• Новый балансировщик OSD (upmap-read). Quincy умел балансировать запись, но read-нагрузка распределялась менее равномерно на кластерах с асимметричным железом. Reef добавил балансировщик, который учитывает и чтение. У клиента как раз смешанный кластер: часть OSD на NVMe, часть на SATA SSD, и перекос читающей нагрузки на NVMe был виден в метриках.
• RBD fast-diff улучшения. Клиент активно использует RBD для снапшотов виртуальных дисков zVirt. В Quincy fast-diff иногда давал ложные miss при работе с глубокими цепочками снапшотов. В Reef это переработано.
• RGW S3 Select. Есть второй клиент с объектовым хранилищем поверх Ceph RGW. Возможность делать S3 Select прямо в RGW без выгрузки объектов - это запрос, который давно висел в бэклоге.

Схема кластера перед апгрейдом

Кластер на восьми нодах: три MON/MGR, пять OSD-нод с двумя NVMe и четырьмя SATA SSD на каждой. Версия Quincy 17.2.6 на Debian 11. cephadm-оркестровка включена с момента установки кластера - это важно для того, что будет дальше.

Под нагрузкой: RBD-пулы для виртуалок (replication 3), RGW для объектов (erasure 4+2), несколько CephFS-томов под сборочные артефакты.

Процесс апгрейда через cephadm

В Reef команда Ceph существенно улучшила upgrade-путь через cephadm. В Quincy процесс тоже был, но документация была разрозненная, и несколько шагов требовали ручного вмешательства. Сейчас - заметно чище.

Апгрейд запускается одной командой:

ceph orch upgrade start --image quay.io/ceph/ceph:v18.2.0

cephadm сам перекатывает демоны по одному, дожидается HEALTH_OK после каждого шага и не двигается дальше при проблемах. На нашем кластере полный апгрейд занял около трёх часов - без единой паузы IO на клиентах.

Прогресс смотрели через:

ceph orch upgrade status

Пара замечаний по процессу:

• Pre-upgrade checks теперь блокирующие. Если кластер не полностью здоров - апгрейд не стартует. Это правильно, хотя один раз нас это остановило из-за одного OSD в состоянии nearfull - пришлось сначала разобраться с этим. Не жалуемся: лучше так, чем апгрейд посреди деградации.
• Порядок апгрейда зафиксирован. MON -> MGR -> OSD -> MDS -> RGW -> RBD Mirror. cephadm соблюдает этот порядок автоматически, вручную управлять очерёдностью не нужно.
• CephFS требует отдельного шага. Перед апгрейдом MDS нужно включить allow_standby_replay и убедиться, что есть standby MDS. Если забыть - cephadm предупредит, но только в момент перехода к MDS-демонам.

Что реально изменилось на SSD-тире

После апгрейда включили новый балансировщик:

ceph balancer mode upmap-read
ceph balancer on

Дали несколько часов поработать на реальной нагрузке и сравнили метрики из Prometheus/Grafana.

Распределение read-IOPS между OSD стало заметно равномернее - те NVMe-диски, которые раньше брали на себя непропорциональную долю чтения, немного разгрузились. Конкретные цифры зависят от профиля нагрузки и топологии CRUSH, так что давать универсальные проценты не будем - результат будет разным на каждом кластере. Но на нашей конфигурации с асимметричным железом эффект виден невооружённым глазом в дашборде.

Latency на read-запросах к RBD-пулам немного снизилась в пиках. Объяснение простое: нагрузка перестала концентрироваться на двух-трёх OSD и размазалась по всем тридцати.

RBD fast-diff проверили на цепочке из двенадцати снапшотов - проблема с ложными miss, которую видели в Quincy, не воспроизвелась. Это хорошо, потому что задача инкрементальных бэкапов виртуальных дисков у клиента использует fast-diff как основу.

RGW S3 Select - первые впечатления

Включается на уровне конфигурации RGW:

rgw_enable_static_website = true
rgw_s3select_enabled = true

Протестировали на небольших CSV-файлах (десятки МБ). Запросы типа SELECT * FROM S3Object WHERE field > value уходят на стороне RGW, клиент получает только отфильтрованные строки. Работает. Для больших объектов - интересно, но там нужен отдельный тест под нагрузкой, пока только убедились, что функционально включается корректно.

Итог

Апгрейд с Quincy на Reef через cephadm прошёл без неожиданностей - пожалуй, самый гладкий мажорный апгрейд Ceph из тех, что мы делали. Новый балансировщик работает и даёт реальный эффект на асимметричных кластерах. RBD fast-diff исправлен в том месте, где мы спотыкались.

Что осталось открытым: RGW S3 Select проверили только в лёгком режиме - нужен тест под реальной нагрузкой на больших объектах, прежде чем рекомендовать в продакшн. Планируем закрыть это в следующем спринте.