Comments 21
Да, используем.
Смотря на такие схемы, быстро понимаешь, что ceph, далеко не на 3 хоста и далеко не для 1-3 админов
Когда я использовал, была ситуация, когда ssd в ноль почти убился, естественно что там в итого с данными...., благо реплика была postgresql. У ssd 70% места было мертво, но система не видела проблем.
Ну такой вот опыт у нас…
Раньше везде ставили flashcache, но он, во-первых, уже не поддерживается нормально, во-вторых, хотелось кешировать запись, в том числе и последовательную. Мне у bcache очень нравится алгоритм сброса грязных блоков. Если дать постоянную нагрузку на запись, график утилизации/iops кешируемого диска выглядит как график затухающих колебаний и в итоге спрямляется. Ещё нет такой проблемы, как вытесняющий промах за счёт того как он хранит данные в кеше. Вообще удается все данные сначала залить в кеш, при этом сзади у него здоровенный hdd. На критичные баги не напарывались, в рассылках видел жуткие истории про потерю данных на последней Федоре, с ядром собранном на какой-то конкретной версии gcc.
Мне у bcache очень нравится алгоритм сброса грязных блоков. Если дать постоянную нагрузку на запись
А мне наоборот не нравится.
Где вы видели постоянную нагрузку? Кэш нам нужен, чтобы сглаживать пики нагрузки (+элеватор).
Напрашивается взять ssd побольше, чтобы хватило на день работы, а ночью скинуть на hdd. Что делает bcache? Ровно обратное — при росте нагрузки начинает сильнее нагружать диск, при падении — снижает темп записи.
Мне кажется, что зачастую более логичным целевым параметром был бы не количество грязных данных в кэше, а задержка ввода/вывода на hdd.
при росте нагрузки начинает сильнее нагружать диск, при падении — снижает темп записи.
Ну он это делает не сразу и достаточно плавно. В каком-то из более-менее свежих ядер алгоритм, кстати, изменили и он стал менее агрессивным.
Мне кажется, что зачастую более логичным целевым параметром был бы не количество грязных данных в кэше, а задержка ввода/вывода на hdd.
Смотреть на латенси кешируемого девайса было бы интересно, да, но наверное сильно бы усложнило логику. Отталкиваются от объема кэша, потому что если он переполнится грязными блоками — всё очень резко станет плохо.
А какое решение вы рассматриваете как более приемлемое?
извиняюсь, как-то просмотрел ваш ответ.
А какое решение вы рассматриваете как более приемлемое?
да в общем-то давно уже прикрутили сброс кэша на максимальной скорости в моменты простоя, всё не так уж и плохо — можно задать высокий целевой уровень заполнения кэша и будет примерно так, как хотелось (есть нагрузка — пишем в кэш, нет нагрузки — сбрасываем кэш на hdd).
меня смущает, что при тестировании я находил какие-то странности в поведении (банально запускал fio со случайной записью — и через некоторое время массив начинал тормозить, при этом тормоза не проходили и после очистки кэша). надо будет проверить пофиксили или нет.
плюс автор забросил эту игрушку, и активно пилит bcachefs (которая грозит стать очередной райзерфс).
и да, где гарантии того, что так же быстро он не найдёт потом новое увлечение и bcachefs будет забыта?
Сбор денег на патреоне. Он завязан на ее обслуживание.
Сейчас его уже починили. Вернее как починили: при n-ном количестве бакетов с грязными блоками теперь увеличивается скорость врайтбэка.
А зачем в stop проверка метки времени после поиска в таблице?
data != 0 && data->ts > 0) {
Скажите, а у вас CEPH на bluestore или filestore?
И если на bluestore — почему bcache вместо штатной возможности CEPH вынести WAL на SSD?
От High Ceph Latency к Kernel Patch с помощью eBPF/BCC