== Bluestore vs Filestore ==
Блюстор — «новое» хранилище. От «нового» хранилища честно ожидаешь лучшей или хотя бы не худшей производительности в любых во всех сценариях. Однако это, увы, не совсем так.
И таки да, при линейной записи Bluestore фактически в 2 раза быстрее Filestore — двойную запись там честно ликвидировали, крупные блоки пишутся только 1 раз — сразу на устройство, а не 2 (в журнал и потом на устройство). Но вот со случайной записью всё не так однозначно. * В HDD-only конфигурациях («ручник» уже сняли, фикс влит) по random 4k write iops Bluestore тоже в честных 2 раза быстрее, чем Filestore.*: Фактически можно сказать, что для HDD и плохих SSD схема записи Bluestore по-настоящему оптимальна и выжимает максимум, который возможно выжать из диска в транзакционном режиме* В HDD+SSD кластерах производительность у Bluestore идеально стабильная, но сильно меньшая, чем у Filestore в пике. От блюстора невозможно добиться «сглаживания пиков» случайной записи через SSD-журнал. Он устроен так, что отказывается писать быстрее, чем в среднем может писать HDD. То есть даже с SSD-журналом вы получите лишь 100—200 iops с 1 диска — в то время, как в Filestore, пока в журнале есть место, можно иметь 1000—2000 iops.*: И проблема не только в том, что параметры по умолчанию — deferred_batch_ops и max_deferred_txc — задают частый сброс операций на медленный диск (раз в 64 операции). Проблема ещё в том, что в Bluestore отсутствуют механизмы фоновой очистки «журнала» (очереди отложенной записи). Поэтому, когда очередь забивается, производительность просто падает до HDD-шной до перезапуска OSD. Ну и сама очередь находится в RocksDB, поэтому сильно поднимать её размер, по идее, неполезно.* В All-Flash кластерах (то есть, на быстрых дисках) Bluestore латентнее Filestore, возможно, на 30-50 %. Однако эти 30-50 % относятся к latency именно самого блюстора, в абсолютном выражении составляют ~0.1 мс и на фоне общей задержки Ceph-а практически не заметны. Кроме того, latency ничего не говорит о параллельной пиковой пропускной способности, а она по крайней мере не хуже, чем в Filestore (обычно чуть лучше, +5..10 %). Жор CPU тоже чуть меньше.* Жор памяти у Bluestore ощутимо больше, потому что RocksDB и потому что кэш у него собственный вместо использования системного page cache-а, как в Filestore. Как полечить высокие задержки на SSD+HDD? * Либо вместо журнала (или рядом с журналом) сделать на SSD bcache для HDD.* Либо использовать HDD с SSD Cache, Media Cache или аналогом (перманентным кэшем случайной записи на пластинах). Например, в старых дисках HGST это включается при отключении волатильного кэша командой `hdparm -W 0 /dev/sdXX`. В новых, похоже, включено всё время. Также BlueStore делает огромное количество fsync-ов (что очень смешно — даже больше, чем запросов записи), из-за чего не терпит десктопных SSD под журналом. Но FileStore работает похоже, и кардинальных различий производительности это не вносит. Ну и ещё FileStore отстаёт от BlueStore по функциональности:* Снапшоты там работают со скоростью LVM, то есть, при записи 4 кб после снятия снапшота копируется весь 4 Мб объект. То есть, после снятия снапшота RBD ВМ тормозят.* Плюс отсутствуют некоторые другие фичи BlueStore: нет частичной перезаписи в EC-пулах (соответственно, EC нельзя использовать под CephFS и RBD), нет сжатия (не всегда нужно, но вещь прикольная), нет контрольных сумм (и из-за их отсутствия пул с size=2 может не вылечиться при сбое сам). Итого, что Что лучше в Bluestore?
* Ликвидирована двойная запись при линейной записи. Линейная запись быстрее в честных 2 раза практически в любых конфигурациях.
* Это не так критично, но в Bluestore есть поддержка сжатия и контрольных сумм данных.
А что хуже?В целом, претензии сводятся к производительности:
* Гораздо хуже производительность случайной записи на SSD+HDD, SSD-раздел не работает как буфер для быстрой записи. Bluestore не пишет быстрее, чем может в среднем сам HDD. То есть, в с SSD+HDD конфигурации без bcache с -журналом и Filestore будет 1000—2000 иопс случайной записи, а с Bluestore — Bluestore (и без bcache) — 200—300. 1000-2000, конечно, упадёт до 100 или даже ниже, когда у Filestore забьётся журнал и его придётся сбрасывать - но тем не менее, "буфер" для сглаживания пиков Filestore предоставляет. А Bluestore - нет.*: И проблема не только в том, что параметры по умолчанию — deferred_batch_ops и max_deferred_txc — задают частый сброс операций на медленный диск (раз в 64 операции). Проблема ещё в том, что в Bluestore отсутствуют механизмы фоновой очистки «журнала» (очереди отложенной записи). Поэтому, когда очередь забивается, производительность просто падает до HDD-шной до перезапуска OSD. Ну и сама очередь находится в RocksDB, поэтому сильно поднимать её размер, по идее, неполезно.
* До 1.5-2 раз хуже latency случайной записи на SSD/NVMe, ибо накладных расходов на каждую операцию записи у Bluestore больше.
* Жор памяти больше. Да, у Filestore много занимал pagecache, но Bluestore меньше 2 ГБ памяти не жрёт вообще никогда. Причиной тому - RocksDB (одни только memtable-ы с дефолтными настройками съедают 1 ГБ памяти) и собственный кэш метаданных и данных (Bluestore не может использовать pagecache).* Фрагментация приводит к снижению скорости чтения. Также BlueStore делает огромное количество fsync-ов (что очень смешно — даже больше, чем запросов записи), из-за чего не терпит десктопных SSD под журналом. Но FileStore работает похоже, и кардинальных различий производительности это не вносит. Как полечить высокие задержки на SSD+HDD? * Либо вместо журнала (или рядом с журналом) сделать на SSD bcache для HDD.* Либо использовать HDD с SSD Cache, Media Cache или аналогом (перманентным кэшем случайной записи на пластинах). Например, в старых дисках HGST это включается при отключении волатильного кэша командой `hdparm -W 0 /dev/sdXX`. В новых, похоже, включено всё время.
=== Тест на 1 NVMe ===
