Важная особенность Ceph — ''вся запись, даже та, для которой никто этого явно не просит, ведётся транзакционно''. То есть, никакая операция записи не завершается, пока она не записана в журналы всех OSD и не сделан fsync() диска. Так сделано, чтобы предотвращать RAID WRITE HOLE-подобные ситуации рассинхронизации данных между репликами при отключении питания, потере сети и т.п…
При этом оптимизацией транзакций тамЭто приводит к тому, похоже, вообще никто нормально не занимался (все используют хорошие серверные что типичная настольная SSDпод журналом в Ceph выдаёт '''неприлично низкие IOPS-ы''' — обычно от 500 до 2000. И это при том, которые болт клали на fsync) и поэтому что при работе OSD sync-ов обычном тестировании почти любая SSD выдаёт > 20000 iops. Даже самый паршивый китайский noname выдаёт не то что столько менее 10000 iops. NVMe легко выжимает 150000 и больше. Но стоит начать использовать fsync… и та же, сколько запросов записи — их даже БОЛЬШЕ NVMe выдаёт 600 iops (смешно, дана 2.5 порядка меньше). В таких условиях «deferred» операции превращаются не в deferred, а непонятно во что, поэтому понятия «асинхронности» там фактически никакого нет.
Всё это приводит к томуВ общем, что типичная настольная SSD чтобы понять, сколько у вас теоретически может быть IOPS-ов на запись в Ceph выдаёт , диски под него нужно тестировать с опциями fio '''неприлично низкие IOPS-ыsync=1 iodepth=1''' — обычно от 500 до 2000. И это при том, что при обычном тестировании почти любая SSD выдаёт > 20000 iops. Даже самый паршивый китайский noname выдаёт не менее 10000 iops. NVMe легко выжимает 150000 и больше. Но стоит начать использовать fsync… и та же NVMe выдаёт 600 iops Это даст "журнальные" иопсы (на 2.5 порядка меньшепроизводительность последовательного коммита операций по одной).
В общем, чтобы понять, сколько у вас теоретически может быть IOPS-ов на запись в Ceph, диски под него нужно тестировать с опцией fio '''Другие почти идентичные варианты: fdatasync=1'''. Либо можно fsync=1, но (в файле поверх ФС будут различия, ) либо можно syncfsync=1 iodepth=1 — почти то же самое, но чуть с другого бока(на голом девайсе). Разница между опциями (см. man fio):* fsync=1 синхронизирует данные и метаданные тестируемого файла отдельным запросом после каждой операции записи. Именно так Так работает BlueStore. Именно поэтому мы будем использовать именно эту опцию.
* fdatasync=1 синхронизирует только данные (но не метаданные) тестируемого файла после каждой операции записи. Соответственно, от fsync=1 это отличается, только если тестируется '''файл в ФС''', а не блочное устройство.<br /> {{Note}} fdatasync=1 надо использовать, когда на диске уже есть ФС, а прогнать тест хочется. Результаты будут достаточно корректными.
* sync=1 использует O_SYNC и синхронный ввод/вывод, то есть, каждая операция начинается только после завершения предыдущей. Но штука в том, что почти все движки fio при этом открывают файл с O_SYNC. А вот O_SYNC уже означает, что каждая операция записи внутри сопровождается аналогом fsyncТак работает FileStore. *: Но при этом если ещё нужна опция iodepth > =1, то иначе в очередь диска до синхронизации «пролезает» несколько операций и IOPS-ы растут, тест перестаёт быть эквивалентным записи с fsync=1тестом журнала.
== Конденсаторы! ==
