13 494
правки
Изменения
Нет описания правки
* Также жор CPU — одна из причин НЕ делать из Ceph «гиперконвергентное облако» (в котором совмещены узлы хранения и запуска виртуальных машин)
* Ещё можно отключить все mitigation-ы аппаратных уязвимостей: noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier
== Настройка виртуалок ==
* С дефолтными опциями qemu подключает RBD, увы, криво
* Криво — это значит, что а) используется медленная эмуляция lsi-контроллера б) используется режим с кэшированием чтения, но без кэширования записи
* Опция cache диска qemu автоматически влияет на включение RBD cache в клиентской библиотеке Ceph (librbd)
* Однако RBD cache сам по себе вносит небольшое торможение, заметное в случае SSD. Что-то там сделано с блокировками, что-то там однопоточное, всё это оптимизируют, но пока не оптимизировали.
* Есть следующие способы эмуляции дисков: lsi (самый медленный), virtio-scsi (достаточно быстрый), virtio (самый быстрый, но до QEMU 4.0 не умеет TRIM). Вообще virtio-scsi умеет multiqueue и поэтому на быстром хранилище должен быть быстрее virtio — но в случае с Ceph multiqueue, по-видимому, значения не имеет.
Поэтому:
* Для HDD / SSD+HDD крайне желательно на уровне виртуалок включать опцию qemu cache=writeback. Этот режим безопасный, так как fsync-и от гостевых ВМ заставляют qemu сбрасывать кэш в Ceph. То есть, транзакционно записываемые данные не теряются.
* Для SSD-only лучше выключать кэш вообще (cache=none), максимальные параллельные iops на запись от этой процедуры растут с примерно 11000 до ~25000.
* Лучше всего использовать драйвер virtio. Как всё это настраивается в вашем GUI виртуалок (Proxmox, Opennebula) — отдельная песня :) в опеннебуле сделано довольно-таки через жопу.
== Оценка производительности кластера ==
* Оценка производительности кластера просто по спецификациям входящих в него SSD не совсем верна (точнее, скорее совсем не верна), причём в обе стороны:
** Bluestore, видимо, за счёт параллелизма, выдаёт чуть больше iops-ов даже на SSD без конденсаторов, чем просто те же ssd могут выдать с fsync — я лично смог добиться от тестового пула на 3-х Intel SSDSC2KW256G8 8000 iops (случайная запись), хотя сами ssd с fsync выдают примерно 5500
** И обратно, даже если SSD мегабыстрая, цеф — это огромный оверхед, он жрёт проц и никаких 220000 iops из одной SSD не выжмет. См. ниже [[#Пример теста от Micron]] — там в суперкрутом сетапе у них вышло всего 8750 iops в пересчёте на 1 NVMe (но это у них без SPDK/DPDKпосле небольшого тюна они улучшили результат до ~12000 iops на 1 NVMe).
* Можно считать, что лимит iops-ов в пересчёте на одну SSD/NVMe находится на уровне ~10000-15000.
* Большой разницы между хорошей SATA SSD и даже NVMe в цефе — нет.
* отключили чексуммы мессенджера (ms_crc_data=false) и чексуммы блюстора (bluestore_csum_type=none)
* затюнили rocksdb: <tt>bluestore_rocksdb_options = compression=kNoCompression,max_write_buffer_number=64,min_write_buffer_number_to_merge=32,recycle_log_file_num=64,compaction_style=kCompactionStyleLevel,<br />write_buffer_size=4MB,target_file_size_base=4MB,max_background_compactions=64,level0_file_num_compaction_trigger=64,level0_slowdown_writes_trigger=128,<br />level0_stop_writes_trigger=256,max_bytes_for_level_base=6GB,compaction_threads=32,flusher_threads=8,compaction_readahead_size=2MB</tt>
** 64x32x4 MB memtable (number x merge x size) вместо стандартных 4x1x256 MB. Скорее всего, это и сыграло основную роль. Эффект от этой процедуры не совсем очевиден, вроде и compaction-ы вряд ли сильно быстреено, и нагрузка вероятно, это снижает нагрузку на CPU не факт, потому что меньшепоиск в 64 маленьких memtable быстрее, чем поиск в 1 (или 4) больших.
** сильно изменён max_bytes_for_level_base — с 256 мб он поднят до 6 гб!
** добавлены потоки compaction-а.
