Ceph Luminous preview: BlueStore в продакшн и первые замеры против FileStore

Когда в августе прошлого года мы тестировали BlueStore в Jewel, он был помечен «технологическим превью» - трогать интересно, в продакшн не класть. В Luminous картина меняется: BlueStore становится рекомендуемым бекендом по умолчанию, а команда Ceph заявляет кратный прирост производительности против FileStore на одинаковом железе. Мы подняли тестовый стенд на dev-preview чтобы посмотреть что из этого правда.

Почему BlueStore это важно

FileStore живёт с Ceph с самого начала. Его механика понятна и проверена, но у неё есть врождённый изъян: каждая запись происходит дважды. Сначала объект уходит в journal (обязательно fsync), потом переносится в основное хранилище. Это двойная запись, это дополнительная latency, это необходимость держать отдельный SSD под journal если хочется нормальных IOPS на произвольной записи.

BlueStore работает по-другому: пишет напрямую в блочное устройство, journal как отдельной сущности нет. Есть WAL и небольшая metadata-база на RocksDB, которую можно вынести на SSD - но это другой масштаб, не сравнить с тем что FileStore съедал под journal. Архитектурно это выглядит честнее.

Что за стенд

Тот же тестовый кластер что работал на Jewel: три OSD-ноды, по четыре SATA-диска, SSD на каждой ноде. Luminous dev-preview поставили параллельно - отдельный кластер, чтобы не рисковать тестовыми данными. Ядро Ceph 12.0.x, собранное из dev-ветки.

Для сравнения на новом кластере развернули половину OSD с BlueStore, половину с FileStore - на одинаковом железе и одинаковых дисках. fio с профилями random write 4K, random read 4K, sequential write/read, глубина очереди 32.

Что показали замеры

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

Случайная запись 4K - это главная история. BlueStore-OSD показывают заметный прирост, разрыв с FileStore ощутимый. Утверждения о двукратном превосходстве выглядят реалистично для этого сценария на нашем железе. Объяснение простое: FileStore здесь плохо, потому что упирается в двойную запись, BlueStore её убрал.

Случайное чтение 4K - разрыв есть, но скромнее. Тут FileStore не был так ограничен по архитектуре, поэтому эффект меньше.

Sequential - разница минимальная в обоих направлениях. Последовательные паттерны FileStore обрабатывал нормально, здесь BlueStore не даёт такого отрыва как на random write.

Latency - вот где BlueStore убедителен независимо от режима. 99-й перцентиль latency на записи у FileStore хуже из-за периодических fsync-ов в journal. BlueStore ровнее.

Итог: для нагрузок с произвольной записью разница существенная. Для чисто последовательных паттернов - несущественная.

Erasure coding с overwrites

Отдельная вещь в Luminous - erasure coding получает поддержку overwrites. В Jewel erasure coding работал только на append: можно дописывать, перезаписывать нельзя. Это ограничивало применимость - RBD поверх erasure pool в продакшне был неудобен.

Luminous снимает это ограничение. Erasure coding с k=4, m=2 на BlueStore - это теоретически полноценный путь к более дешёвому хранению при тех же гарантиях: вместо тройной репликации (300% от объёма) получаем 150%. Мы погоняли небольшой тест, это работает. Но это именно dev-preview - без CPU-профилирования под нагрузку выводы делать рано.

Нюансы миграции OSD

Один момент, который в документации упоминается вскользь: перевести существующий OSD с FileStore на BlueStore нельзя на месте. Это другой формат данных на диске, миграция требует вывода OSD из кластера, вычистки диска и ввода заново уже как BlueStore.

Для тестового стенда это просто - вывел, очистил, ввёл. Для продакшн-кластера с реальными данными это операция с осторожностью: нужно понимать текущее состояние кластера, иметь достаточную избыточность, делать по одному OSD с паузами. На кластере с репликацией 3x и нормальным здоровьем это выполнимо - Ceph умеет в rolling-апгрейд. Но автоматически при апгрейде Luminous этого не произойдёт, это сознательный шаг руками.

Второй момент: BlueStore требует от ядра определённых версий для нормальной работы async discard. На устаревших ядрах это может сказаться на производительности на SSD. Актуальный CentOS 7.3 с kernel 3.10 - граничный случай, лучше смотреть на 4.x.

Где мы сейчас

Luminous dev-preview - это именно dev. Для клиентских managed-кластеров мы ждём RC, а лучше GA. Но картина уже достаточно понятная: BlueStore с Luminous - это реальное улучшение, не только маркетинг. Разрыв на random write существенный, latency ровнее, архитектура без journal проще в эксплуатации.

Практический план: когда выйдет Luminous GA, клиентские кластеры на Jewel будем апгрейдить и планомерно переводить OSD на BlueStore - по одному, с наблюдением. Это займёт время, но направление выбора нет.

Erasure coding с overwrites пока остаётся в зоне «интересно, но рано». Хотим увидеть это в стабильном релизе и почитать production-отчёты от других команд прежде чем что-то рекомендовать.