Фрагментация базы RocksDB в условиях высоконагруженного Ceph кластера: причины, последствия и пути решения

Базы данных и системы хранения

Отказоустойчивость
Распределенные системы
Управление инцидентами
Облака

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

Инженеры эксплуатации Ceph, особенно работающие с S3/RGW, SRE и инженеры распределённых хранилищ, отвечающие за latency и SLA, а также все, кто работает с RocksDB и другими LSM-движками под delete-heavy нагрузкой.

Тезисы

Удаление объектов в S3 кажется дешёвой операцией, но в Ceph оно бьёт по KV-метаданным RocksDB на OSD. При больших объёмах lifecycle-удалений LSM накапливает tombstone'ы, чтение index и omap дорожает, и пока compaction не разгребёт слои, latency S3 растёт – при формально здоровом кластере. В докладе я расскажу, как мы прошли путь от непонятных симптомов до рабочей модели: чем дебажить, когда прямой метрики «деградации LSM» не существует; почему важно не путать два разных слоя – фрагментацию свободного места в BlueStore и толстые слои LSM в RocksDB; и какой комплекс мер лечит проблему. Отдельно подсвечу про мониторинг и runbook, которые мы собрали уже после инцидента, чтобы видеть деградацию заранее.

Работаю облачным инженером 4 года, своей основной нишей выбрала распределнные хранилища, углубленно работаю с высоконагруженными Ceph кластерами.
Когда ceph отпускает люблю заниматься разными активностями, кататься на лошадях, зимой на сноуборде, люблю проводить время со своей собакой

Видео

Другие доклады секции

Базы данных и системы хранения