Ceph Luminous + BlueStore в продакшне: год на клиентских кластерах и Kubernetes PV

Год назад мы отработали процедуру миграции OSD с FileStore на BlueStore на тестовом кластере и зафиксировали: прирост на случайной записи есть, latency ровнее, идём в продакшн. С тех пор все клиентские managed-кластеры прошли через это. Накопилось достаточно реального опыта, чтобы рассказать не только про процедуру, но и про то, что это даёт в контексте Kubernetes.

Что изменилось за год в Ceph Luminous

Когда мы делали первую миграцию в июле 2017-го, Luminous только вышел в GA. С тех пор вышли 12.2.1, 12.2.2 и 12.2.4 - патчи в основном по стабильности и по MGR-плагинам. BlueStore за эти релизы подтянулся: в 12.2.1 были фиксы по corruption в edge-кейсах с OSD crash, в 12.2.2 улучшили поведение WAL при высокой нагрузке. Мы держали кластеры в актуальном патч-уровне, и это было правильным решением - не стоило оставаться на 12.2.0 дольше пары недель.

ceph-mgr освоился как постоянный участник инфраструктуры. На каждом клиентском кластере держим его на двух нодах: один active, один standby. Пару раз MGR падал при обновлении, и standby подхватывал без какого-либо эффекта на данные - всё работало как должно.

Kubernetes PV: почему Ceph здесь важен

Большинство клиентских кластеров в нашем managed - это Kubernetes поверх виртуальных машин или bare-metal, с Ceph в качестве хранилища для Persistent Volumes. RBD-провайдер в Kubernetes создаёт PVC как блочные устройства поверх Ceph RBD-пула, и StatefulSet-ы пишут туда напрямую.

До перехода на BlueStore периодически видели неприятную картину: при отказе OSD-ноды кластер уходил в HEALTH_WARN с recovery в фоне, и в этот момент latency на RBD-томах начинала вести себя непредсказуемо. Pod с базой данных мог замереть на 30-60 секунд, пока Ceph восстанавливал placement groups. Не потеря данных, но приложение переставало отвечать.

После полного перехода на BlueStore картина стала заметно другой. Тот же сценарий - отказ ноды, recovery, HEALTH_WARN - проходит без заметных пауз на RBD-клиентах. Объяснение в архитектуре: BlueStore без двойной записи дает меньшее давление на диски во время recovery, и параллельная запись прикладного трафика и восстановительного меньше друг другу мешают.

Что показали цифры на клиентских кластерах

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

IOPS на случайной записи вырос примерно в полтора раза относительно FileStore на том же железе. Это видно на графиках Grafana до и после миграции последнего OSD - разрыв устойчивый, не разовый всплеск.

p99 latency на записи стал заметно ровнее. Характерных выбросов, которые с FileStore появлялись при fsync в journal, нет. На кластерах где journal жил на том же диске что и данные - разница особенно ощутима: FileStore там был медленный по архитектурным причинам, а не из-за конкретного железа.

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

Одно наблюдение, которого не было в прошлогодних тестах: потребление CPU на OSD-нодах незначительно выросло. BlueStore использует RocksDB для метаданных и WAL, это небольшая, но не нулевая нагрузка. На кластерах с нормальным запасом по CPU - незаметно. На кластерах где ноды были нагружены под завязку - стоит смотреть отдельно.

Как проходила миграция в продакшне

Механика та же что в прошлом году на тестовом стенде: OSD по одному, с паузами, с ожиданием HEALTH_OK после каждого шага. Разница в том, что теперь делали это на живых кластерах с клиентским трафиком.

Для Kubernetes-кластеров добавилось одно требование: перед выводом OSD-ноды на техобслуживание нужно убедиться что поды не имеют PVC с единственной копией данных на этой ноде. Стандартный ceph osd out и ожидание HEALTH_OK перед остановкой ноды - этого достаточно, Ceph успевает перенести данные до того как нода уходит. Но делать это без предварительной проверки состояния кластера не стоит.

Один раз в процессе миграции OSD столкнулись с тем, что recovery шёл медленнее ожидаемого - на конкретном кластере была нетипично фрагментированная CRUSH-карта, и часть PG распределилась неоптимально. Решили перебалансировкой CRUSH-правил перед продолжением. Урок: перед миграцией продакшн-кластера - проверить CRUSH-карту и убедиться что distribution нормальный, а не только статус кластера.

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

Год без потери данных на отказе узла

Это, пожалуй, главное наблюдение. За год эксплуатации на всех клиентских кластерах, полностью переведённых на BlueStore + Luminous, ни одного инцидента с потерей данных при отказе OSD-ноды. Отказы были - железо есть железо. Но каждый раз кластер восстанавливался штатно, PVC в Kubernetes оставались консистентными.

Это не значит что Ceph FileStore терял данные - с правильно настроенной репликацией он тоже этого не делал. Разница в том, что с BlueStore recovery проходит быстрее и с меньшим давлением на оставшиеся ноды, а значит окно повышенного риска (когда данные временно в состоянии деградации) меньше.

Что дальше

Erasure coding с overwrites в Luminous работает, мы его пробовали на стендах. Для cold storage и бэкапов - интересное направление: 150% overhead вместо 300% при тройной репликации. Для горячих PVC в Kubernetes пока не рекомендуем - CPU overhead при перезаписи ощутимый, и поведение при recovery отличается от replicated pool. Но посмотрим.

Следующее обновление Ceph - Mimic (13.x). Пока смотрим на release notes и ждём патч-версий с устоявшимися отзывами, прежде чем планировать апгрейд продакшн-кластеров.