Ceph 18 Reef GA: планируем апгрейд с Quincy и смотрим на RGW и BlueStore

Ceph 18 Reef официально вышел в GA в мае 2023. У нас есть тестовый кластер на Quincy (17.x), который мы держим для нескольких клиентских S3-нагрузок и как площадку для экспериментов. Reef - следующий major-релиз и начало нового LTS-цикла, так что вопрос «когда апгрейдить» стал актуальным. Смотрим, что изменилось, и описываем, как собираемся проходить апгрейд без катастроф.

Что нас интересует в Reef

Changelog у Ceph традиционно объёмный, но в нашем случае два изменения стоят внимания сразу.

Первое - улучшения RGW (RADOS Gateway) для S3-нагрузки. В Reef переработан механизм multipart upload: переиндексация неполных загрузок стала менее агрессивной в отношении OSD I/O, что должно снизить конкуренцию при параллельных крупных заливках. Добавлен также улучшенный контроль lifecycle policy - noncurrent version transitions теперь работают более предсказуемо при большом количестве версионированных объектов. У нас один из клиентов держит версионированный bucket с ротацией логов - именно то место, где старый Ceph периодически удивлял нас просадками при lifecycle-прогоне.

Второе - компрессия данных на уровне BlueStore. В Quincy компрессия уже была, но в Reef её переработали: алгоритм snappy теперь включается более гибко по policy (можно задать min_alloc_size ниже которого компрессию не применять - уменьшает overhead на мелких объектах), а lz4 получил обновление. В документации обещают меньший CPU-overhead при включённой компрессии на смешанных рабочих нагрузках.

Оба пункта звучат актуально для наших сценариев: S3-endpoint для бэкапов и объектного хранилища с неравномерным размером объектов.

Что за кластер

Тестовый стенд - три OSD-ноды, каждая с несколькими NVMe, плюс отдельные MON/MGR/RGW-ноды. Развёрнуто через cephadm, версия сейчас 17.2.6 (Quincy). Объём данных умеренный - это именно тестовая площадка, не продакшн-кластер клиента. Принципиально: апгрейд мы проходим здесь, а не на клиентском кластере, где сейчас тоже Quincy, но это решение на потом - после того как посмотрим, как Reef ведёт себя на нагрузке.

План апгрейда

cephadm упрощает апгрейд до команды ceph orch upgrade start --image <reef-image>, но это не означает «нажал кнопку и забыл». Наш план выглядит так:

• Подготовка: обновить cephadm до версии, которая умеет управлять Reef, проверить CRUSH-карту и состояние PG - никаких degraded или misplaced перед стартом.
• Порядок компонентов: MON -> MGR -> OSD -> MDS (если есть) -> RGW. cephadm по умолчанию соблюдает этот порядок, но мы хотим пройти его контролируемо: обновить один MON, убедиться что quorum держится, потом следующий.
• OSD: rolling upgrade поочерёдно, между нодами - пауза и проверка ceph health и ceph osd stat. В тестовом кластере нет клиентских данных под риском, но именно так мы потренируемся для боевого апгрейда.
• RGW: последним, после того как хранилище стабильно на Reef.
• Включение BlueStore-компрессии: это отдельный шаг после апгрейда. Компрессия на существующих объектах не применяется ретроактивно - только на новых записях. Планируем тест на отдельном пуле.

Отдельный пункт - проверка CRUSH compatibility. В Reef изменилось поведение некоторых CRUSH-алгоритмов, и если у вас кастомная CRUSH-карта (у нас - есть, для разделения SSD и NVMe пулов), это надо проверить явно перед апгрейдом.

Что хотим замерить

После апгрейда и до - прогоняем стандартный набор:

• RGW throughput: s3cmd в несколько потоков, multipart upload крупных файлов, параллельная запись мелких объектов. Интересует именно сравнение до/после, а не абсолютные цифры.
• BlueStore компрессия: создаём пул с compression_mode = aggressive, алгоритм snappy, заливаем типичные бэкапы (смесь tar.gz и сырых дампов баз). Смотрим на ceph df и ceph osd pool stats для оценки реального коэффициента сжатия.
• CPU overhead: у нас не очень мощные OSD-ноды в тестовом стенде - важно понять, не съедает ли компрессия процессор на фоновых операциях вроде scrub.

Это не академический бенчмарк, это ответы на практические вопросы: стоит ли рекомендовать апгрейд клиентам с похожими нагрузками, и когда включать компрессию по умолчанию.

Почему не откладывать

Ceph работает по модели LTS-релизов с циклом ~2 года. Quincy поддерживается, никакого срочного конца жизни нет. Но Reef - начало нового цикла, и чем позже начать его осваивать, тем меньше времени на спокойное изучение до следующего major-релиза. Кроме того, улучшения RGW в Reef закрывают несколько неприятных паттернов, которые мы наблюдали в Quincy при специфических сценариях с lifecycle и параллельными multipart - это сам по себе аргумент.

Клиентский кластер трогать не будем, пока тестовый не отходит несколько недель под нагрузкой. Это стандартная механика для любого major-апгрейда распределённого хранилища - торопиться незачем.

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