Ceph Jewel 10.2: тестируем BlueStore и пересчитываем iron-серверы

В апреле вышел Ceph Jewel - 10.2, первый релиз с пометкой LTS. Мы наблюдали за ним три месяца со стороны, читали чужие отчёты и ждали пока пропатчат самое очевидное. В конце июля решили что пора - и перевели наш тестовый кластер с Hammer на Jewel.

Главный повод был конкретным: BlueStore. Новый бэкенд хранения объектов заявлен как более быстрый на произвольных записях - именно то место, где FileStore с его двойной записью через journal всегда выглядел не очень убедительно.

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

Тестовый стенд у нас живёт уже полтора года. Три OSD-ноды, по четыре SATA-диска на каждой, SSD под журналы. CephFS поверх, несколько RBD-томов для виртуалок. Всё это на Hammer 0.94, то есть предыдущем LTS. Нагрузка тестовая, но приближенная к реальной: fio в разных режимах плюс несколько виртуалок с нормальной операционной жизнью.

Апгрейд прошёл в штатном режиме - rolling update, один демон за раз, кластер в HEALTH_OK всё время. Это хорошо, потому что апгрейд Ceph между мажорными релизами умеет быть внезапно болезненным. Здесь обошлось.

BlueStore: что показало fio

BlueStore в Jewel помечен как «технологическое превью» - то есть не рекомендован для продакшн без понимания рисков. Мы это понимаем и специально выделили два OSD под него, оставив остальные на FileStore. Это позволило сравнить напрямую на одном железе.

Результаты fio на random write 4K:

• FileStore OSD (SSD journal) - примерно тот же уровень что был на Hammer, ожидаемо.
• BlueStore OSD - прирост по IOPS заметный, в полтора раза на произвольной записи. На sequential - разница меньше, там FileStore и так был неплохой.

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

Что это значит для расчётов

Вот где становится интересно. У нас несколько клиентских проектов, где мы считаем хранилище под виртуализацию - dedicated-серверы с Ceph поверх локальных дисков. Стандартная схема под Hammer предполагала определённое количество SATA-дисков плюс обязательно SSD под журналы, потому что без SSD-журнала FileStore на случайных записях грустный.

BlueStore меняет эту логику. Журнал как отдельная сущность исчезает. SSD нужен иначе - либо под WAL/DB часть BlueStore (и его нужно меньше), либо не нужен вовсе если цель просто получить разумный IOPS на SATA. Это меняет стоимость конфигурации, иногда заметно.

Конкретно: в одном из расчётов, который мы сейчас делаем для клиента, SSD под журналы съедали значимую долю бюджета. Если BlueStore ведёт себя на продакшн так же как на тестовом стенде - схема пересматривается.

Erasure coding

Помимо BlueStore в Jewel стабилизировали erasure coding. В Hammer это тоже было, но с оговорками. Мы немного поигрались с профилем k=4, m=2 - это означает что данные разбиваются на 4 чанка плюс 2 чанка чётности, кластер переживает потерю любых двух OSD без потери данных при накладных расходах 50% вместо 200% у трёхкратной репликации.

На тех же шести OSD схема k=4, m=2 смотрится разумно для холодных данных - резервные копии, архивы. Для горячих данных с произвольным чтением erasure coding всё равно дороже по CPU, чем репликация - кодирование/декодирование при каждом чтении даром не даётся.

Что с мониторингом

Отдельный момент - метрики. Ceph сам по себе умеет в Graphite/InfluxDB через плагин, но в Jewel это наконец заработало без ручной возни. Мы подключили к Prometheus через ceph-exporter - работает, основные метрики по OSD, pool-ам и latency видны.

Где сейчас

Тестовый стенд на Jewel работает уже несколько недель. BlueStore-OSD живут без происшествий, данные читаются корректно. Тем не менее на клиентские продакшн-кластеры Jewel мы пока не переводим - LTS-статус это хорошо, но три месяца с релиза для production-хранилища недостаточно. Ещё немного понаблюдаем.

BlueStore в технологическом превью - это отдельная осторожность. Пока он живёт только на тестовом стенде, и переводить клиентские данные на него до GA-статуса не планируем.

Но расчёты по железу уже пересматриваем. Если характеристики подтвердятся - конфигурации станут дешевле при том же IOPS, и это аргумент в разговоре с клиентами про managed-инфраструктуру.