Ceph 20 Squid: обновляем production-кластер и смотрим на latency RBD поверх NVMe

Ceph 20 Squid вышел в сентябре прошлого года, и с тех пор выходят точечные релизы. У нас на нескольких клиентах стоят кластеры на Squid, и раз уж накопились исправления в части RBD - решили обновиться и заодно замерить, что изменилось по latency. Тем более что на одном из стендов бэкенд - NVMe-диски в OSD, и там каждая миллисекунда заметна.

Кластер - не игрушечный: три узла MON, шесть узлов OSD по восемь NVMe-дисков в каждом, пул RBD для блочных томов Kubernetes. Клиент - из категории, которая болезненно реагирует на просадки производительности хранилища: платёжная инфраструктура, latency напрямую влияет на UX транзакций. Поэтому обновление делали осторожно - с замерами, откатным планом и узким maintenance-окном.

Что появилось в точечных релизах Squid

Основное, что нас интересовало в части RBD:

Исправления в librbd при параллельных операциях. В первых Squid-релизах были жалобы на деградацию при высоком параллелизме на клоны и snapshots. В последних точечных релизах это частично адресовано - конкретно в части блокировок при операциях с snapshot-цепочками.

Улучшения в bluestore кэшировании на NVMe. В bluestore поправили несколько мест, где кэш не утилизировал NVMe-скорость эффективно из-за синхронных сбросов там, где они необязательны. Это не революция, но на быстрых дисках разница должна быть заметна.

Стабилизация работы mclock-планировщика. mclock по умолчанию включён начиная с Ceph 17, и в Squid его продолжают дорабатывать. Несколько исправлений касаются честного распределения IOPS между пулами при смешанной нагрузке - RBD и RGW одновременно.

Это не полный список - release notes объёмные, но мы фокусировались именно на RBD и bluestore.

Как мерили latency

Прежде чем обновляться, сняли базовый профиль. Инструментарий простой: fio на RBD-устройстве в Linux (через librbd напрямую, не через ядерный rbd), плюс ceph tell osd.* perf dump для метрик со стороны OSD.

Сценарии для fio:

• randread 4K, queue depth 1 - чистая latency без параллелизма
• randread 4K, queue depth 32 - latency под нагрузкой
• randwrite 4K, queue depth 1 - то же для записи
• mixed 70/30 read/write, queue depth 16 - ближе к реальной нагрузке

Тест гоняли по 5 минут каждый, три прогона, смотрели на p50/p99/p999. Данные за 15 минут на каждый сценарий - достаточно, чтобы исключить случайный выброс.

До обновления картина была такая: на randread 4K QD1 p99 latency около 400-450 мкс, на QD32 p99 чуть выше 2 мс. Для записи хуже - p99 на QD1 около 700 мкс, что для NVMe-бэкенда ощущалось как многовато. Сетка между узлами 25GbE, так что сеть не узкое место.

Само обновление

Обновляли по одному узлу OSD за раз через ceph orch upgrade. Перед стартом убедились что PG all active+clean, min_size пулов позволяет пережить вывод одного узла без degraded. Монитор ceph dashboard держали открытым рядом.

MON обновились первыми без сюрпризов. OSD-узлы - последовательно, между ними ждали ceph health HEALTH_OK и полного rebalance. На шести узлах это заняло около трёх часов с небольшим - дольше, чем хотелось бы, но торопить rebalance не стали.

Один момент, который отметим: при обновлении первого OSD-узла ceph dashboard на несколько минут показал предупреждение про slow ops. Это ожидаемо - OSD перезапускаются, нагрузка перераспределяется. Но заказчик дёрнулся - пришлось заранее объяснить что это норма. Формально всё шло правильно, просто метрика в dashboard выглядит тревожно если не ждёшь этого.

Что увидели после

После обновления прогнали те же fio-сценарии. Изменения есть, но разные по сценариям.

Randread QD1 - p99 latency упала с ~430 до ~370 мкс. Около 14% на p99. P50 почти не изменился. Это ожидаемо: bluestore-оптимизации влияют больше на хвост распределения, чем на медиану.

Randread QD32 - p99 улучшился примерно на 10-12%. p999 - заметнее, здесь была деградация на длинных хвостах при высоком параллелизме, и патчи по librbd её подрезали.

Randwrite QD1 - здесь скромнее. P99 около 650 мкс против 700 до обновления. Разница в пределах погрешности измерений, но стабильно воспроизводится на всех трёх прогонах. Будем считать небольшим улучшением.

Mixed 70/30 - p99 заметно лучше: около 15% по latency. Вот здесь mclock-исправления, видимо, дали эффект.

Ничего из ряда вон, но и не плацебо. На NVMe-бэкенде, где сами диски дают субмиллисекундную latency, улучшения в 10-15% на p99 - это ощутимо именно потому, что оверхед Ceph становится заметной долей общей картины.

Текущий статус

Кластер работает на обновлённом Squid уже несколько дней. Никаких аномалий, HEALTH_OK, реальная нагрузка ведёт себя ровно. Метрики Prometheus показывают чуть более ровный профиль latency по сравнению с тем, что было до обновления.

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

Если у вас Ceph-кластер на Squid и NVMe-диски в OSD - обновиться до свежего точечного релиза имеет смысл, но с замерами до и после. Просто обновить и надеяться - не наш метод. В рамках managed-сопровождения мы такие обновления делаем именно так: сначала базовый профиль, потом окно, потом верификация.