Ceph 17 Quincy в продакшне: обновление с Pacific и конфигурация BlueStore под NVMe

Ceph 17 Quincy вышел в апреле 2022 - примерно через полтора года после Pacific. Мы примерно такой же паузой и воспользовались, чтобы обновить первый боевой кластер с Pacific до Quincy. Спойлер: обошлось одним рестартом MON, что по меркам распределённых хранилищ можно считать почти идиллией. Но интересного хватило - об этом ниже.

Quincy: что изменилось по существу

Список изменений в Quincy большой, но для нас в эксплуатации важны три вещи.

cephadm стал значительно зрелее. В Pacific cephadm был технически работающим, но оркестрация нескольких операций одновременно иногда вела себя непредсказуемо. Quincy довёл до ума работу с placement-спецификациями, улучшил обработку ситуации когда daemon не отвечает, и в целом команды типа ceph orch apply теперь вызывают значительно меньше сюрпризов. На практике это ощущается именно как зрелость инструмента, а не смена версии.

BlueStore получил новые дефолты. Под NVMe-накопители Quincy меняет настройки по умолчанию для параметров bluestore_cache_size_hdd и bluestore_cache_size_ssd, а также оптимизирует поведение блочных аллокаций под более предсказуемые латентности флеша. Это не магия - на старом железе разница может быть незаметна - но под NVMe разница ощутима. Подробнее про конфиг ниже.

RGW multi-site переработан. Для объектного хранилища с репликацией между зонами теперь доступна синхронизация через специализированный механизм «sync policy», который позволяет задавать правила репликации на уровне bucket-а, а не только зоны. Это снимает несколько неприятных ограничений Pacific. Нас это касается у одного клиента с geo-распределённой инсталляцией - будем пробовать отдельно.

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

Кластер - семь узлов: три MON+MGR, четыре OSD с NVMe. Всё развёрнуто через cephadm на AlmaLinux 8.5. Ceph Pacific 16.2.x - последняя стабильная точка перед Quincy.

Перед обновлением сделали стандартную процедуру: убедились что кластер HEALTH_OK, нет отстающих PG, все OSD up и in. Потом выставили ceph osd set noout - это гарантирует, что OSD не начнут помечаться как out если в процессе что-то подвиснет.

Само обновление через cephadm:

ceph orch upgrade start --image quay.io/ceph/ceph:v17.2.0

cephadm поднимает контейнеры с новой версией последовательно, daemon за daemon. MGR обновляются первыми, потом MON, потом OSD. На третьем MON (один был временно в состоянии перезапуска от предыдущего шага) произошёл кратковременный failover - кластер на несколько секунд потерял кворум, потом восстановил. Это и был тот самый «один рестарт MON».

Пока MON выбирал нового лидера, ceph status вернул HEALTH_WARN 1 mon down. Через 15 секунд всё встало на место, OSD не tipped, данные на месте. Но если смотреть на мониторинг в этот момент - алёрты летели. Предупреждаем клиентов заранее.

Обновление OSD прошло без инцидентов. ceph osd unset noout после финала, проверяем ceph -s - HEALTH_OK.

Конфигурация BlueStore под NVMe

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

Что мы ставим для кластера на NVMe:

[osd]
# Размер кеша под SSD/NVMe - в байтах
bluestore_cache_size_ssd = 4294967296   # 4 GiB на OSD

# Более агрессивный deferred write threshold на NVMe - нет смысла буферить
bluestore_max_deferred_txc = 32

# RocksDB настройки для WAL и DB на том же NVMe
bluestore_rocksdb_options = compression=kNoCompression,max_write_buffer_number=8,min_write_buffer_number_to_merge=4

# Отключаем сжатие для горячих данных - процессор дороже на нашем профиле нагрузки
bluestore_compression_mode = none

Кеш в 4 GiB на OSD - это под NVMe немного, можно давать больше если ОЗУ позволяет. Но у нас профиль нагрузки такой, что cache hit rate на объектном хранилище невысокий - большие объекты, некешируемые запросы. Поэтому 4 GiB - рабочий компромисс. Для блочного RBD-хранилища с повторяющимися read-паттернами кеш стоит поднять до 8-16 GiB.

bluestore_compression_mode = none - осознанное решение. Клиентские данные уже сжаты на прикладном уровне (архивы, бэкапы), двойное сжатие только тратит CPU без пользы. На кластерах с несжатыми данными (логи, метрики TSDB) aggressive или auto дадут выигрыш по месту.

Про cephadm и почему мы на него перешли

Исторически кластеры поднимали через ceph-deploy, потом через ручную оркестрацию Ansible-ролями. cephadm появился в Octopus и в Pacific уже был основным путём, но первые версии были сыроваты.

Quincy - первый релиз, где мы готовы рекомендовать cephadm для новых инсталляций без оговорок. Контейнерная модель упрощает обновления (именно это мы только что прошли), изолирует версии демонов от системных пакетов, и оркестрация через ceph orch читается значительно лучше, чем ручной Ansible с большим количеством edge cases.

Минус один: cephadm требует, чтобы на хосте был рабочий Docker или Podman. На AlmaLinux 8 ставим Podman - он там идёт из базовых репозиториев и работает без демона. На практике это нормально, но это дополнительная зависимость, про которую нужно помнить при планировании инфраструктуры.

Где сейчас

Первый кластер на Quincy работает несколько дней - рано делать выводы по стабильности, но первые впечатления хорошие. Метрики BlueStore в норме, latency на NVMe чуть ниже чем на Pacific при той же нагрузке - возможно эффект новых дефолтов, возможно просто разброс.

Для managed-инфраструктуры Quincy становится нашим стандартом для всех новых Ceph-инсталляций. Pacific-кластеры будем обновлять по мере плановых работ - процедура понятная, рисков меньше, чем мы ожидали.

RGW multi-site с новой sync policy - следующий эксперимент, но это уже отдельная история на другом кластере.