Ceph 21: EC 4+2 на NVMe-oF и что это меняет для бэкапного tier

Ceph 21 вышел на прошлой неделе. Самые заметные изменения в релизе - переработанный erasure coding plugin и нативная поддержка NVMe-oF targets прямо из ceph-osd. Мы подняли тестовый кластер и потратили несколько дней, чтобы понять: это что-то реальное для production, или очередная фича в changelog, которая красиво выглядит в бенчмарках и сложно работает в жизни.

Коротко: EC 4+2 на NVMe-oF - это реально, но сценарий применения очень специфичный.

Что изменилось в EC

В старых версиях Ceph erasure coding работал через jerasure и ISA-L плагины с довольно ограниченными возможностями конфигурации. Ceph 21 существенно переработал clay-based EC plugin - добавил поддержку partial reads при декодировании и переработал внутреннюю механику распределения данных по OSD.

Практический эффект от partial reads ощущается на EC-пулах с большими объектами. При чтении части объекта (а это типичная операция для RGW с range request-ами) старый EC тащил все чанки с разных OSD и собирал на клиенте. Новый plugin умеет вычислять, каких именно OSD достаточно для конкретного диапазона, и не дёргает лишних. На нашем тесте с 4+2 профилем и объектами по несколько гигабайт read latency на случайных range request-ах снизилась заметно - примерно в полтора раза по сравнению с Ceph 18 на том же железе.

NVMe-oF targets: зачем это в Ceph

NVMe-oF поддержку в Ceph добавляли давно и итерациями, но до 21-й версии это был отдельный сервис поверх librbd с кучей ручной настройки. В Ceph 21 NVMe-oF target интегрирован как модуль ceph-mgr: вы создаёте gateway-группу, назначаете subsystem-ы к RBD image-ам, и клиенты подключаются по NVMe/TCP.

Это меняет картину для одного конкретного кейса: если у вас есть кластер с NVMe OSD и вы хотите предоставлять блочное хранилище гипервизорам по NVMe-oF вместо iSCSI или librbd, это теперь делается без дополнительных прокси-сервисов. В том же Proxmox VE 9.0, о котором мы писали недавно, NVMe-oF plugin стал вполне рабочим - и Ceph 21 с его стороны теперь закрывает вторую половину уравнения.

EC 4+2 + NVMe-oF: что получается по цифрам

Конкретная конфигурация, которую мы гоняли: 12-нодовый кластер, по 4 NVMe OSD на ноду, EC 4+2 профиль через новый clay plugin. RBD image на EC-пуле, экспортированный через NVMe-oF gateway.

Плотность хранения - вот где EC реально выигрывает. Replicated pool с factor 3 оставляет треть ёмкости, то есть на 48 NVMe вы получаете эффективно 16 дисков. EC 4+2 - это overhead 1.5x, то есть 32 диска эффективной ёмкости. Разница примерно 40% в пользу EC. Это не магия и не новость, так erasure coding работал всегда - просто раньше за это нужно было платить очень высокой latency на записи.

Latency на записи - исторически больное место EC в Ceph. В нашем тесте средняя write latency на EC 4+2 через NVMe-oF оказалась примерно в 1.8-2 раза выше, чем на replicated pool с тем же железом. Это честная цена за EC: каждая запись требует кодирования и распределения по 6 OSD против 3 при replication. При этом для бэкапного tier с последовательной записью крупными блоками - а именно так работает Veeam и большинство бэкап-инструментов - это приемлемо.

Latency на чтении - интереснее. При нормальном состоянии кластера (все OSD online) EC 4+2 на read в нашем тесте был на 15-25% медленнее replicated pool. Это нюанс clay plugin с partial reads: прирост виден именно на range request-ах к объектному хранилищу через RGW, а не на блочном RBD.

Когда это выгодно

Мы смотрим на это как на специализированный инструмент, а не на замену replicated pool во всех сценариях.

Имеет смысл применять EC 4+2 через NVMe-oF если:

• это бэкапный tier с преимущественно последовательной записью и редким random-read
• кластер достаточно большой (минимум 6 нод, лучше 12+) чтобы распределение по fault domain работало правильно
• NVMe-ёмкость дорогая и плотность хранения важна

Не имеет смысла для:

• primary storage под СУБД или виртуальные машины с OLTP-нагрузкой
• малых кластеров, где EC профиль нельзя нормально распределить по нодам
• случаев, когда операционная сложность восстановления после сбоя OSD критична

Операционная сложность

Один момент, который стоит отдельного абзаца: восстановление EC-пула после потери OSD - это не то же самое, что replicated. При потере одного OSD в EC 4+2 кластер должен перестроить данные со всех оставшихся, и этот процесс создаёт значительно большую нагрузку на сеть и I/O, чем recovery в replicated пуле. На NVMe это быстрее, чем на HDD, но всё равно: окно деградации в production-кластере с EC длиннее, и если второй OSD падает во время recovery первого - ситуация становится напряжённой (при EC 4+2 два одновременных отказа ещё допустимы, три - уже потеря данных).

Для бэкапного tier, где RTO не часы, а дни, это допустимый компромисс. Для primary storage - нет.

Где мы сейчас

Результаты тестового кластера выглядят убедительно для сценария бэкап-хранилища. На одном из клиентских проектов с managed-сопровождением как раз стоит вопрос расширения бэкап-хранилища - EC 4+2 профиль на Ceph 21 мы рассматриваем как вариант. Но это проект на несколько месяцев с нормальной миграцией, а не «поставили и забыли».

Ceph 21 в плане EC и NVMe-oF - это релиз, где фичи доехали до состояния «можно пробовать в production при наличии понимания, что делаешь». Это нормально.