Изменения

* С дефолтными опциями qemu подключает RBD, увы, криво.* Криво — это значит, что а) используется медленная эмуляция lsi-контроллера б) используется режим с кэшированием чтения, но без кэширования записи.* Кэш в qemu регулируется опцией, собственно, cache. Бывает <не указано>, writethrough, writeback, none, unsafe, directsync. С RBD эта опция регулирует работу rbd cache, то есть кэша на стороне клиентской библиотеки Ceph (librbd).* Но cache=unsafe с RBD не работает, операции записи всё равно ждут подтверждения. А writethrough, <не указано> и directsync, по сути, эквивалентны.* RBD cache сильно помогает на HDD, но на SSD-кластере наоборот вносит заметное торможение. Что-то там сделано с блокировками, что-то там однопоточное, всё это оптимизируют, но пока не оптимизировали.* Есть следующие способы эмуляции дисков: lsi (самый медленный), virtio-scsi (достаточно быстрый), virtio (самый быстрый, но до QEMU 4.0 не умел TRIM). Вообще virtio-scsi умеет multiqueue и поэтому на быстром хранилище (например, при прямом доступе к локальной NVMe) должен быть быстрее virtio — но в случае с Ceph multiqueue, по-видимому, значения не имеет.* А ещё тормозит файловая система! Конкретно, если у вас не включена опция lazytime, то при каждой мелкой записи ФС обновляет mtime, то есть время модификации inode-а. Так как это метаданные, а ФС журналируемые — это изменение журналируется. Из-за этого при тесте <tt>fio -sync=1 -iodepth=1 -direct=1</tt> поверх ФС без lazytime iops-ы уменьшаются в 3-4 раза.* А если у вас (не дай бог) внутри Oracle, то ему надо обязательно поставить опцию FILESYSTEMIO_OPTIONS=SETALL.* Производительность случайной записи в CephFS почти не отличается от RBD* Производительность случайной записи в CephFS через mount -t cephfs и через ceph-fuse… при iodepth=1 почти не отличается. А вот при iodepth=128 ядерный клиент ведёт себя нормально, а ceph-fuse выдаёт столько же, сколько при iodepth=1 (то есть на порядок/порядки меньше, чем ядерный клиент).

ПоэтомуКриво — это значит, что:: а) используется медленная эмуляция lsi-контроллера: б) неправильно настроен кэш TL;DR, как всё исправить:* Для HDD / SSD+HDD крайне желательно на уровне виртуалок включать опцию ceph.conf [global]: '''rbd cache writethrough until flush = false'''* qemu : '''bus=virtio cache=writeback'''. Этот режим безопасныйЕсли у вас SSD, так как fsync-СУБД и от гостевых нужны random iops - то '''bus=virtio cache=none'''.* Внутри ВМ заставляют : '''mount -o lazytime''' === Драйвер виртуального диска и ФС === В qemu сбрасывать кэш в Ceph. То естьследующие способы эмуляции дисков:* lsi - самый медленный* virtio - самый быстрый, транзакционно записываемые данные но до QEMU 4.0 не теряютсяумел TRIM. Юзать надо его.* Для SSDvirtio-only лучше выключать кэш вообще scsi - достаточно быстрый. На самом деле, умеет multiqueue и поэтому на быстром хранилище (например, при прямом доступе к локальной NVMe) должен быть быстрее virtio — но в случае с Ceph это не так, т.к. multiqueue бессмыслен === cache=writeback === Кэш дисков в qemu регулируется опцией, собственно, cache. Бывает <не указано>, writethrough, writeback, none), максимальные параллельные iops unsafe, directsync. С Ceph RBD эта опция регулирует работу rbd cache, то есть кэша на запись от этой процедуры растут стороне клиентской библиотеки Ceph (librbd). RBD cache маленький (32 МБ) и является аналогом буфера записи на HDD, то есть, предназначен исключительно для группировки операций записи перед, собственно, отправкой их в хранилище. Режимы writethrough, <не указано> и directsync с примерно 11000 до ~25000RBD, по сути, эквивалентны и означают отсутствие кэширования записи (каждая операция отправляется сразу в Ceph).* Лучше всего использовать драйвер virtioРежим writeback означает "честное" (безопасное) кэширование записи. Как всё это настраивается То есть, операции записи без fsync ложатся в вашем GUI кэш и отправляются оттуда либо раз в rbd_cache_max_dirty_age (по умолчанию 1 сек), либо когда ВМ просит fsync. Режим unsafe означает "нечестное" (чреватое потерей данных) кэширование записи. Операции записи также ложатся в кэш, но fsync от ВМ игнорируются. Транзакционность в виртуалке отсутствует, но и производительность повышается. Использовать этот режим можно только для виртуалок , не содержащих ценные данные (Proxmoxнапример, Opennebulaдля каких-нибудь тестов или CI) — отдельная песня . При среднем применении правильный режим - '''cache=writeback'''. Грубо говоря, cache=writeback увеличивает результат следующего теста:  fio -name=test -ioengine=libaio -direct=1 -bs=4k -iodepth=1 -rw=randwrite -filename=/dev/vdb # без -fsync и без -sync ...примерно приводя его к результату того же теста с <tt>iodepth=32</tt>. {{Note}} ОДНАКО, есть НЮАНСЫ (как всегда с цефом...) в опеннебуле сделано довольно: * Если RBD-образ пустой и при этом на нём включён object-map (по умолчанию включён, см. <tt>rbd info <pool>/<image></tt>), то сброс кэша становится однопоточным И ФИГ ВЫ ВИДИТЕ улучшение результата fio.* Если опция rbd_cache_writethrough_until_flush равна true (так по умолчанию), то до первого fsync кэш не работает. То есть, если вы монтируете к виртуалке диск и сразу тестируете его вышеприведённой командой - вы опять-таки через жопуне увидите хороших результатов.* Обязательно используйте Из-за той же опции, стоящей в true, cache=unsafe не работает вообще. В Proxmox включен патч, который заставляет qemu ставить эту опцию монтирования автоматически. Если у вас не Proxmox - опцию нужно прописать в конфиг глобально: rbd_cache_writethrough_until_flush=false.* Сам кэш может являться тормозом в SSD-кластерах. Что-то там сделано с блокировками, что-то там однопоточное, всё это оптимизируют, но пока не оптимизировали. Например, 4K randwrite Q128 с rbd_cache=false может достигать 20000 iops, а с rbd_cache=true - только 11000 iops. Для говнософта, который пишет на диск абы как, это торможение оправдано, а для, например, СУБД - нет. Поэтому в случае, если у вас SSD и вам нужны в первую очередь random iops, то правильный режим - '''cache=none'''. === ФС === А ещё тормозит файловая система! Конкретно, если у вас не включена опция <tt>mount -o lazytime</tt>, то при каждой мелкой записи ФС обновляет mtime, то есть время модификации inode-а. Так как это метаданные, а ФС журналируемые — это изменение журналируется. Из-за этого при тесте <tt>fio -sync=1 -iodepth=1 -direct=1</tt> поверх ФС без lazytime iops-ы уменьшаются в 3-4 раза. Для неё lazytime нужны свежие ядра: с ext4 — ext4 — хотя бы 4.0, с XFS — XFS — хотя бы 4.17. Также нужны соответствующие (свежие) util-linux (подсказка: в протухшей 7-й центоси их нет, поставить можно только из исходников). А если у вас (не дай бог) внутри Oracle, то ему надо обязательно поставить опцию FILESYSTEMIO_OPTIONS=SETALL. Производительность случайной записи в CephFS почти не отличается от RBD. Производительность случайной записи в CephFS через mount -t cephfs и через ceph-fuse… при iodepth=1 почти не отличается. А вот при iodepth=128 ядерный клиент ведёт себя нормально, а ceph-fuse выдаёт столько же, сколько при iodepth=1 (то есть на порядок/порядки меньше, чем ядерный клиент).