Ceph 19 Squid: обновили несколько кластеров с Quincy без остановки сервиса

Ceph 19 Squid вышел в начале мая. Мы не стали ждать, пока дистрибутивы подтянут пакеты через пару месяцев, и обновили несколько кластеров Ceph с Quincy (17.x) до Squid на этой же неделе. Результатами делимся сразу, пока впечатления живые.

Что изменилось в Squid

Три вещи в релизе сразу привлекли внимание.

Новый балансировщик CRUSH. В Quincy балансировка pg-распределения по OSD была достаточно предсказуемой, но на кластерах с SSD и HDD OSD вперемешку периодически давала неравномерное распределение, которое приходилось корректировать вручную через ceph osd reweight-by-utilization. В Squid переработан алгоритм: балансировщик учитывает фактическую утилизацию OSD агрессивнее и делает это без ручного вмешательства.

Оптимизации BlueStore. Главным образом касаются компрессии и управления кешем метаданных RocksDB. На SSD-тирах, где BlueStore работает без сжатия, прирост должен быть от оптимизаций в work queue и writeback-логике. На бумаге выглядит скромно, но на практике - интересно.

RBD mirroring. Улучшили асинхронную репликацию между кластерами: меньше lag на сценариях с интенсивной записью, переработан механизм журналирования снепшотов. Для нас это актуально в проектах с geo-redundancy.

Как обновляли

Обновляли три кластера - два продакшн, один staging. Все три - bare-metal, Quincy 17.2.x, смешанные тиры (SSD + HDD OSD), поверх работает Ceph RBD для виртуализации.

Процедура rolling upgrade в Ceph - это последовательное обновление компонентов без остановки кластера: MON, MGR, OSD, MDS (если есть), RGW (если есть). Ceph допускает работу в смешанном состоянии - часть демонов на старой версии, часть на новой - на протяжении всего обновления.

Порядок был такой:

• Обновить пакеты на нодах, начиная с мониторов.
• Рестартовать ceph-mon поочерёдно, дождаться кворума.
• Перейти к MGR - здесь важно, что ceph -s должен показывать HEALTH_OK или максимум HEALTH_WARN с понятной причиной перед каждым шагом.
• OSD обновляли по одной ноде за раз. После рестарта OSD на ноде - смотреть на ceph -s, убедиться, что все PG активны, нет degraded выше ожидаемого при перебалансировке.
• Финальный шаг - обновить ceph osd require-osd-release squid для включения новых возможностей протокола.

Staging прошёл за несколько часов без инцидентов. Продакшн-кластеры обновляли в рабочее время - с мониторингом на экране и коллегой рядом.

Что получилось по факту

На обоих продакшн-кластерах rolling upgrade прошёл без остановки сервисов. ВМ, которые смотрят на RBD-пулы, не увидели никакого перебоя. Это, собственно, и должно быть нормой для Ceph - но всё равно приятно убедиться, что на Squid это работает как заявлено.

По новому балансировщику CRUSH: заметный эффект проявился достаточно быстро. На одном из кластеров было несколько OSD, которые в Quincy постоянно держались выше среднего по утилизации - мы периодически вручную делали reweight. После перехода на Squid балансировщик сам выровнял загрузку за несколько часов. Это не мгновенно (перебалансировка идёт постепенно, чтобы не создавать лишний трафик), но работает.

По BlueStore: на SSD-тире наблюдаем снижение p99-латентности при блочных операциях. Насколько это от Squid, а насколько от того, что балансировка выровнялась - честно разделить сложно. Скорее всего, оба фактора вместе.

По RBD mirroring: здесь тестировали только на staging с искусственной нагрузкой. Lag при интенсивной записи действительно стал ниже по сравнению с Quincy. Реальный продакшн-тест будет позже, когда включим асинхронную репликацию на одном из клиентских кластеров.

Что стоит учесть перед обновлением

Несколько практических моментов, которые выяснились в процессе.

Проверить минимальную версию клиентов. Squid ужесточил требования к версии librbd и ядерному rbd-драйверу на клиентах. Если где-то живут ноды с ядром 4.x и старым rbd-клиентом - могут быть проблемы после включения новых возможностей протокола. У нас все ноды были на 5.x, вопрос не встал, но проверить заранее стоит.

BlueStore требования к osd_memory_target. В Squid изменилось поведение кеша RocksDB под нагрузкой. Если у вас OSD настроены с жёстким ограничением памяти на уровне systemd или cgroups - после обновления возможны OOM на нодах с плотным заполнением. Рекомендуют пересмотреть osd_memory_target в сторону увеличения, особенно на HDD-нодах с большим количеством PG.

Обновление cephadm. Если управляете кластером через cephadm - сначала обновить orchestrator, потом кластер. В обратном порядке можно попасть в ситуацию, когда cephadm не понимает часть новых конфигурационных ключей Squid.

Для кластеров, которые обслуживаем в рамках managed-сопровождения, обновление провели в плановом режиме. Клиенты не ощутили ничего, кроме улучшения метрик.