BlueStore в первом продакшн-кластере: +40% throughput и меньше CPU

В июле прошлого года мы отработали миграцию OSD на тестовом кластере и сказали: следующий шаг - клиентские продакшн-кластеры. На дворе март, Luminous 12.2 накатал несколько минорных обновлений и выглядит стабильно. Мы взяли первый кандидат из списка и перевели. Рассказываем как прошло.

Почему именно этот кластер первым

Выбор кластера для пионерского прохода был осознанным. Критерии: относительно небольшой объём данных (чуть меньше 20 ТБ), репликация 3x, нагрузка преимущественно - произвольная запись небольшими блоками (несколько виртуальных машин через RBD), есть нормальное окно обслуживания по ночам. Плюс клиент технически грамотный и понимает что происходит - не будет паниковать при виде временного HEALTH_WARN в 3 ночи.

На больших кластерах с более строгими SLA - пусть этот сначала отработает.

Апгрейд с Jewel до Luminous

Этот кластер ещё жил на Jewel 10.2. Сначала - rolling upgrade до Luminous, только потом миграция OSD. Смешивать это в один проход не стоит.

Апгрейд прошёл по тому же сценарию что на тестовом стенде: мониторы первыми, потом ceph-mgr как новый демон (его надо явно поставить - без MGR Luminous работает, но ругается и дашборд недоступен), потом OSD по одному. Кластер не выходил из HEALTH_OK ни разу, клиентские машины ничего не заметили. Это приятная часть Ceph - rolling upgrade между мажорными версиями реально работает.

Миграция OSD: сколько это занимает в реальности

На тестовом стенде с двенадцатью небольшими OSD полный проход занял полтора дня. На продакшне с реальными данными картина другая.

На кластере 18 OSD по 4 ТБ каждый. Алгоритм для каждого - без изменений относительно тестового прогона:

• ceph osd out - объявляем OSD out, ждём начала ребалансировки
• Ждём HEALTH_OK и нулевое значение degraded в ceph status
• Останавливаем демон, удаляем OSD из кластера
• Очищаем диск через ceph-volume lvm zap
• Вводим обратно как BlueStore: ceph-volume lvm create --bluestore
• Ждём пока новый OSD войдёт in и up, балансировка завершится

На каждый OSD с учётом ожидания ребалансировки уходило от 40 минут до полутора часов - зависело от того сколько данных уехало на соседние OSD и какой в этот момент был фоновый трафик от клиентов. Итого: 18 OSD за пять ночных окон, по 3-4 OSD за ночь. Спешить не стоит.

Один раз мы попробовали делать два OSD параллельно: ceph osd out на оба и ждать. Кластер не возражал, но время ребалансировки выросло непропорционально, и на один момент статус показывал degraded больше ожидаемого. Вернулись к одному за раз.

Что с производительностью

Замеры делали до миграции и через неделю после - когда всё устаканилось и видно нормальный рабочий профиль, а не артефакты ребалансировки.

Throughput на запись - прирост около 40% на том же железе при той же рабочей нагрузке. Это измерение по метрикам с клиентских машин, не синтетика: MB/s в хранилище за одинаковые временные окна с аналогичной нагрузкой. Разрыв устойчивый и воспроизводится день за днём.

Нагрузка на CPU OSD-нод - снизилась заметно. На FileStore с journal'ом значительная часть CPU уходила на fsync и journal-операции. BlueStore убрал этот слой, и OSD-процессы стали дышать свободнее. По top на OSD-нодах - sys time снизился ощутимо.

Latency - 99-й перцентиль на записи стал ровнее. Характерные пики которые раньше коррелировали с journal-flush на FileStore - исчезли. Это видно в Prometheus / Grafana без специальных усилий.

Цифру 40% называем осторожно: нагрузка не идеально воспроизводима день в день, и это наблюдение на одном конкретном кластере с конкретным профилем нагрузки. На кластерах с другим соотношением random write / sequential / read результат будет другим. Но порядок величины - не маркетинговый.

Что неожиданного

Ничего катастрофического - тестовый прогон в июле хорошо подготовил. Но пара вещей требовала внимания.

RocksDB на BlueStore съедает место на метадата-разделе. Для OSD без выделенного SSD под WAL и DB - BlueStore выделяет 1% от объёма диска под RocksDB-базу метаданных внутри самого BlueStore-устройства. На 4 ТБ дисках это около 40 ГБ. Сюрприза нет - это в документации написано - но стоит иметь в виду при планировании полезной ёмкости.

ceph-volume lvm zap иногда требует явного --destroy. На нескольких дисках при zap без флага оставались старые LVM-метки и ceph-volume lvm create ругался. Флаг --destroy решал вопрос, но надо знать что он полностью уничтожает все LVM-структуры на устройстве - проверяй что нет ничего лишнего.

Мониторинг на период миграции. Grafana-дашборды по Ceph показывали периодические скачки latency и throughput в момент когда OSD уходил и возвращался - это нормально и ожидаемо, но если смотришь без контекста, выглядит тревожно. Предупредили клиента заранее и добавили аннотации на дашборды с отметками каждого шага миграции.

Где стоим

Первый продакшн-кластер на BlueStore работает десять дней - стабильно. Прирост производительности реальный и держится. Клиент доволен.

На managed-инфраструктуре у нас ещё несколько кластеров на Jewel и на Luminous с FileStore. Следующий в очереди - кластер побольше, объём под 50 ТБ. Там план миграции будет тщательнее: больше времени на каждый OSD, более строгий мониторинг degraded во время ребалансировки, заложим больше ночных окон.

Erasure coding поверх BlueStore пока не трогаем - хотим сначала набрать статистику по нескольким кластерам только на replicated pool. По одному шагу за раз.