Ceph 19.2 Squid: тестируем crimson OSD на NVMe под резервное копирование

Ceph 19.2 Squid вышел в GA. Для нас это не абстрактное событие в release notes - у нас под сопровождением несколько кластеров Ceph разного возраста, и на одном из них мы уже прошли через обновление до Squid. Главный интерес - crimson OSD, альтернативная реализация слоя хранения, которую команда Ceph разрабатывала несколько лет. Проверяли на рабочей нагрузке: резервное копирование виртуальных машин через RGW с S3-интерфейсом.

Что нового в Squid

Релиз объёмный, но из практически интересного нас зацепили три вещи.

Crimson OSD - новая реализация OSD-демона. Это не патч поверх существующего кода - это переписанный OSD, построенный на фреймворке Seastar с моделью async I/O без блокировок. Классический bluestore OSD использует thread-per-core и блокирующие операции; crimson пытается избавиться от контекстных переключений и добиться лучшей утилизации NVMe-дисков, которые способны обслуживать очереди глубиной в сотни операций.

Улучшения RGW для S3-совместимости. В Squid исправлен ряд кейсов, где Ceph RGW расходился с поведением AWS S3 - в основном это multipart-загрузки и обработка некоторых заголовков. Для нас это важно: несколько систем резервного копирования взаимодействуют с RGW именно через S3-совместимый API, и раньше на ряде операций приходилось выставлять специфические флаги совместимости.

Новый балансировщик CRUSH-трафика. Изменения в алгоритме балансировки нагрузки между OSD - в теории это должно выровнять заполнение дисков при неоднородном распределении объектов.

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

Кластер, на котором проводили тест - восемь узлов хранения, каждый с четырьмя NVMe-дисками Samsung PM9A3 и двумя 25G-портами. Всего 32 OSD. Нагрузка - резервное копирование через Veeam с S3-совместимым RGW как целевым хранилищем, плюс несколько внутренних CephFS-томов.

Обновление с предыдущей версии до Squid шло через стандартный cephadm-процесс. Никаких сюрпризов при самом обновлении не было - cephadm прокатил demote/promote OSD корректно, кластер не терял доступность. Примерно три часа от начала до момента, когда все OSD отрапортовали up+active.

Crimson OSD в Squid всё ещё помечен как experimental и включается явным флагом на уровне конфигурации. Мы перевели на crimson четыре OSD из восьми на двух узлах хранения - ровно половину пула, который обслуживает S3-бакеты резервных копий. Остальные четыре OSD на этих же узлах оставили на bluestore. Это позволило наблюдать обе реализации под одной нагрузкой на одном железе.

Что получилось на нагрузке резервного копирования

Задача резервного копирования - специфичная: большие последовательные записи, размер объектов от нескольких сотен мегабайт до десятков гигабайт. Мультипарт-загрузка через RGW, очереди параллельных потоков от нескольких агентов Veeam одновременно.

Пропускная способность записи. На crimson OSD пиковая пропускная способность при параллельной записи оказалась выше - примерно на 15-20% при глубоких очередях. Это согласуется с тем, что мы ожидали от async-модели: NVMe-диски при такой нагрузке действительно работают эффективнее без блокировок на уровне OSD.

Латентность одиночных операций. Здесь картина неоднозначная. Медианная латентность на crimson чуть ниже, но хвосты (p99, p999) ведут себя менее предсказуемо. На bluestore p99 стабильнее. Для задачи резервного копирования это не критично - там важнее суммарный throughput, а не хвосты латентности. Но для других нагрузок это нужно иметь в виду.

Потребление CPU. crimson OSD на пиковой нагрузке ел CPU заметно меньше - одно ядро на OSD против полутора-двух у bluestore при сопоставимом трафике. На восемь NVMe это даёт ощутимую разницу в доступных ресурсах на узле.

Стабильность. За три недели тестирования один OSD на crimson ушёл в crash с дампом ядра. Bluestore-OSD за тот же период - ноль инцидентов. Это не приговор технологии, но crimson с пометкой experimental на prod-нагрузке требует готовности к таким сюрпризам.

RGW и S3-совместимость

Улучшения в RGW заметны практически. Несколько граничных кейсов с multipart-загрузкой, которые в предыдущей версии требовали обходных путей на стороне клиента, теперь работают корректно без дополнительных флагов. Veeam отрабатывает без ошибок на стандартной конфигурации.

Один кейс остался неисправленным: при abort multipart upload на очень большом объекте (50+ GB) Ceph RGW иногда медленнее возвращает ответ, чем клиент ожидает по таймауту. Это не новая проблема Squid, но и не исправленная. Решение то же: увеличить таймаут на стороне клиента.

Где мы сейчас

Crimson OSD на половине пула работает третью неделю. Обратно откатываться не планируем - производительность на нашей нагрузке устраивает, crash был единичным. Но переводить всё хранилище на crimson раньше чем он уйдёт из статуса experimental - не будем. Пусть сначала устоится в более широкой эксплуатации.

Новый балансировщик пока наблюдаем - заполнение OSD выравнивается медленнее, чем хотелось бы после ребаланса, но это может быть просто особенностью нашего распределения объектов.

Общее ощущение от Squid - релиз зрелый. Обновляться с предыдущих версий стоит, хотя crimson лучше трогать только если есть конкретный интерес и готовность мониторить внимательно.