Ceph Pacific -> Quincy: замеряем IOPS на NVMe-полке и смотрим что изменилось

Quincy (17.2) вышел в апреле стабильным, и мы несколько месяцев смотрели на него с интересом. В changelog одним из пунктов шли улучшения BlueStore на быстрых NVMe - именно такой стек стоит у одного из наших клиентов. Виртуализационный кластер, 12 серверов, полка из NVMe SSD, никаких ротационных дисков вообще. Pacific работал нормально, но «нормально» - это не повод не обновляться, если апстрим говорит что стало лучше.

В начале сентября нашли окно для обновления. Что получилось - ниже.

Контекст: что было до

Кластер на Pacific 16.2.10, поднят примерно год назад. BlueStore везде, OSD на NVMe, WAL и DB тоже на NVMe - выделенные разделы, не на том же устройстве. Репликация 3x для основного пула, 2x для тестового. Управление - сервисные файлы и ручные команды через ceph-deploy поколения до cephadm.

Производительность по результатам rbd bench при первоначальной настройке была приличная, но с тех пор нагрузка выросла, и несколько раз появлялись жалобы на latency при одновременных снапшотах. Не катастрофа, но неприятно.

Что обещает Quincy по BlueStore

В release notes основные BlueStore-изменения касаются нескольких вещей:

• Оптимизация работы с RocksDB. BlueStore хранит метаданные в RocksDB; в Quincy переработан ряд path-ов записи, которые при высоком IOPS создавали contention на уровне WAL.
• Улучшенный throttling. В Pacific при резких всплесках записи throttle иногда работал слишком агрессивно и задирал latency на чтение. В Quincy логика пересмотрена.
• mclock scheduler по умолчанию. Новый QoS-шедулер для OSD-операций вместо WeightedPriorityQueue. Обещает более предсказуемое разделение между клиентскими операциями, recovery и scrub.

Звучит хорошо. Насколько это ощутимо в реальности на конкретном железе - другой вопрос.

Обновление: cephadm вместо ручного управления

Кластер исходно не на cephadm. Миграцию на cephadm откладывали, но Quincy фактически подталкивает к ней - старые инструменты поддерживаются формально, а cephadm является де-факто стандартным способом управления начиная с Octopus.

Сделали в два этапа: сначала переключились на cephadm-управление (процедура cephadm adopt для каждого демона), потом уже обновляли версию. Это добавило несколько часов к процессу, но в итоге всё управление через ceph orch - читается и аудируется значительно лучше, чем набор разрозненных systemd-юнитов и конфигов в разных местах.

Обновление Rolling Upgrade прошло без сюрпризов: MGR первым, потом MON, потом OSD по одному. Кластер не уходил в HEALTH_ERR ни разу, только HEALTH_WARN во время rebalance после смены версии OSD. Всё как написано в документации, что само по себе приятно.

Измерения: что реально поменялось

После обновления прогнали стандартный rbd bench на тестовом пуле: sequential write, sequential read, random 4K write, random 4K read. Нагрузка на кластер в момент теста - фоновая, без продакшн-операций.

Sequential read/write - изменений почти не заметно. Ожидаемо: на последовательных операциях BlueStore упирается в сеть и CPU значительно раньше, чем в диск. Quincy здесь ничего не обещал.

Random 4K read - небольшой прирост, в пределах 10-15%. Воспроизводимо при нескольких прогонах, но с оговоркой: тест гоняли в разное время суток, фоновый scrub мог вносить шум. Не стали бы утверждать что это именно Quincy, а не удачная разница в фоновой нагрузке.

Random 4K write - вот здесь интереснее. При высоком параллелизме (несколько потоков одновременно) latency стала стабильнее. Пиковые значения latency p99 снизились заметно. IOPS в среднем примерно на том же уровне, но хвост распределения стал короче. Это похоже на действие нового throttling - меньше резких проседаний.

mclock scheduler включили, но отдельно его влияние не мерили - нет контрольного запуска с WeightedPriorityQueue на той же версии. В планах провести более аккуратный AB-тест.

Про жалобы на снапшоты

Проверили сценарий, который исходно беспокоил: одновременное создание снапшотов на нескольких RBD-образах под нагрузкой. Снапшоты на клиентских машинах сами по себе быстрые, а вот latency на RBD при их создании в Pacific иногда подскакивала. В Quincy этот сценарий субъективно стал менее болезненным - latency не исчезает совсем, но пика в несколько секунд, который изредка наблюдался, не воспроизвели. Для уверенных выводов нужна более длительная работа под реальной нагрузкой.

Где сейчас

Кластер работает на Quincy вторую неделю. Жалоб от клиента нет, мониторинг в managed-контракте не показывает ничего нового. cephadm после перехода заметно упрощает рутинные операции - добавление OSD, обновление конфигов, проверка состояния.

Ожидания от обновления были умеренными, результат примерно им соответствует. Не «вдвое быстрее», а «немного лучше там где было хуже всего» - собственно, так и должна работать минорная оптимизация в зрелом storage-стеке. На NVMe-полке с правильно настроенным Pacific разница не такая, чтобы срочно планировать обновление только ради IOPS. Но Quincy достаточно стабильный и cephadm того стоит - мотивация обновиться есть даже без измеримого прироста производительности.