Ceph Luminous GA: переводим тестовый кластер с FileStore на BlueStore

В апреле мы смотрели на Luminous в dev-preview и фиксировали что Ceph даёт заметный прирост на случайной записи. Тогда же сказали: подождём RC, потом переводим клиентские кластеры. Luminous 12.2 RC2 вышел - и мы сразу взялись за тестовый кластер, чтобы отработать процедуру миграции до того как делать это с реальными данными клиентов.

Что появилось в RC2 относительно preview

Несколько вещей стали ощутимо другими.

BlueStore по умолчанию. При добавлении нового OSD без явного указания бекенда Ceph теперь выберет BlueStore. Звучит как мелочь, но это сигнал: команда готова нести ответственность за этот код в продакшне, а не только на стендах энтузиастов.

Erasure coding с overwrites. В предыдущих RC это работало, но с оговорками. В RC2 поддержка overwrites на BlueStore стабилизирована. RBD поверх erasure pool без ограничений на перезапись - это уже что-то реальное, не просто демо.

Встроенный дашборд. Ceph получил собственный веб-интерфейс - базовый, но рабочий. Можно посмотреть на состояние кластера без Calamari или ручной возни с Grafana для быстрой диагностики. Мы его включили, посмотрели, оценили как «полезно для первого взгляда, для серьёзного мониторинга всё равно Prometheus + Grafana». Но то что это есть из коробки - хорошо.

CRUSH device classes. Новый механизм: можно пометить OSD как hdd, ssd, nvme и строить правила placement на основе класса, а не ручного управления CRUSH-картой. Раньше приходилось делать это через кастомные bucket-ы, теперь есть официальный путь.

Апгрейд кластера с Jewel

Наш тестовый кластер жил на Jewel 10.2 с начала года. Апгрейд до Luminous - стандартный rolling update: monitors сначала, потом OSD по одному, MGR добавляется как новый тип демона (в Luminous появился ceph-mgr как отдельный компонент, он нужен обязательно).

Проблем с апгрейдом не было. Кластер в HEALTH_OK всё время, данные целы, клиенты не заметили ничего. Это та часть Ceph которую хочется хвалить: rolling upgrade между мажорными версиями работает.

Один нюанс с ceph-mgr: он новый, про него можно забыть. Если не поднять хотя бы один MGR - кластер работает, но некоторые команды начинают ругаться, а дашборд не включишь. Поставили MGR на два монитора, для отказоустойчивости.

Миграция OSD с FileStore на BlueStore

Вот здесь основная история. Апгрейд версии Ceph и переход OSD на BlueStore - это две отдельные операции. После апгрейда до Luminous все OSD остаются на FileStore - они никуда не перемигрируют сами по себе.

Механика миграции OSD такая: для каждого диска нужно вывести OSD из кластера, дать кластеру перебалансировать данные, дождаться HEALTH_OK, потом очистить диск и ввести новый OSD уже с BlueStore. По одному. С паузами.

На тестовом кластере (три ноды, двенадцать OSD) это заняло около полутора дней - с учётом ожидания восстановления после каждого шага. Алгоритм для одного OSD:

1. ceph osd out <id> - объявляем OSD out, кластер начинает перераспределять данные
2. Ждём ceph status показывает HEALTH_OK, recovery завершён
3. Останавливаем демон, удаляем OSD из кластера (ceph osd rm, ceph auth del)
4. Размонтируем FileStore раздел, очищаем диск (ceph-volume lvm zap)
5. Добавляем обратно как BlueStore (ceph-volume lvm create --bluestore)
6. Проверяем что новый OSD in и up, ждём балансировки

В продакшн-кластере с реальными данными ждать придётся дольше - зависит от объёма и скорости дисков. На больших кластерах это может быть часами на каждый OSD. Автоматизировать через Ansible можно, но с обязательными паузами и проверкой статуса между шагами - не просто «прогнать плейбук и уйти».

Один OSD мы попробовали перевести ускоренно, не дождавшись полного HEALTH_OK. Кластер справился, но на мониторинге это выглядело некрасиво - одновременно несколько OSD вышли и вернулись, балансировка шла в несколько потоков. На тестовом стенде с тестовыми данными - ладно. В продакшне - нет.

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

После полной миграции всех двенадцати OSD прогнали те же fio-тесты что в апреле - уже на полностью BlueStore-кластере против FileStore-бейзлайна с апреля.

Картина соответствует ожиданиям.

Случайная запись 4K - главный сценарий где была разница. Прирост заметный и стабильный: не на отдельных замерах, а на прогоне. В апреле на смешанном стенде (половина OSD BlueStore, половина FileStore) результат был смазан - пул всё равно ходил в FileStore-OSD в части операций. Теперь весь кластер на BlueStore и цифры чище.

Latency на записи - 99-й перцентиль стал ровнее. Характерные «пики» которые были на FileStore из-за fsync в journal - исчезли. Это видно на графиках Prometheus и приятно выглядит.

Sequential write/read - разница минимальная в обе стороны, как и ожидали. Здесь FileStore не имел структурного недостатка.

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

Erasure coding: пощупали, пока оставляем в стороне

Поверх BlueStore-кластера подняли erasure pool с k=4, m=2 и погоняли несколько RBD-томов. Работает. Overwrites работают. CPU под нагрузкой заметно выше чем на replicated pool - кодирование при каждой записи не бесплатное.

Для резервных копий и cold storage это направление интересное: 50% overhead вместо 200% при трёхкратной репликации - это реальная разница в стоимости хранения. Но для горячих данных с произвольным чтением-записью пока остаётся вопросом - нужно больше нагрузки и профилирования CPU чтобы понять реальную цену.

Что дальше

Тестовый кластер теперь полностью на Luminous + BlueStore. Следующий шаг - клиентские managed-кластеры: составляем план миграции для каждого с учётом объёма данных, графика обслуживания и допустимого времени балансировки.

Процедура отработана, грабли понятны. Главное правило которое вынесли: не торопиться и не делать два OSD одновременно - кластер справится, но нервов это не стоит.