Изменения

Перейти к: навигация, поиск

Производительность Ceph

2809 байтов добавлено, 23:24, 15 февраля 2019
Нет описания правки
* Задержка однопоточной транзакционной записи мелкими блоками (4-8 Кб) — обычно последовательной, как в журнал СУБД, но в один поток это обычно слабо отличается от случайной
Задержки часто обычно важнее простой пиковой производительности случайного чтения/записи, так как далеко не каждое приложение может загрузить диск при большом параллелизме / глубокой очереди (32-128 запросов).
Ceph — это SDS, его задержки всегда выше, чем у устройств при прямом доступе, и от этого никуда не денешься. В интернете есть доклад Nick Fisk «Low-Latency Ceph», в его исполнении Low latency это 0.7ms, то есть на лучший результат рассчитывать особенно не приходится. 0.7ms — это всего лишь примерно ~1500 iops в 1 поток (хорошая новость — другие SDS и просто SAN-ы тоже тормозят :)).
 
=== Тестирование дисков ===
Сначала прогоните fio на голом диске:
 
{{Box|[[Файл:Warning icon.svg|32px]] {{red|ВНИМАНИЕ!}} Для тех, кто в танке — fio-тест записи на диск ДЕСТРУКТИВНЫЙ. Не вздумайте запускать его на дисках/разделах, на которых есть нужные данные… например, журналы OSD (был прецедент).}}
* Перед тестированием отключите кэш записи диска: {{Cmd|hdparm -W 0 /dev/sdX}} (SATA-диски через SATA или HBA), {{Cmd|1=sdparm --set WCE=0 /dev/sdX}} (SAS-диски). Не совсем ясно, почему, но эта операция на серверных SSD может увеличить IOPS-ы на 2 порядка. Также см.ниже [[#Картина маслом «Тормозящий кэш»]].
* Линейное чтение: {{Cmd|1=fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=read -runtime=60 -filename=/dev/sdX}}
* Линейная запись: {{Cmd|1=fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=32 -rw=write -runtime=60 -filename=/dev/sdX}}
* Задержка случайного чтения: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX}}
* Пиковые IOPS случайного чтения: {{Cmd|1=fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randread -runtime=60 -filename=/dev/sdX}}
* Задержка случайного чтения: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randread -runtime=60 -filename=/dev/sdX}}
* Пиковые IOPS случайной записи: {{Cmd|1=fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=60 -filename=/dev/sdX}}
* Задержка записи в журнал: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=write -runtime=60 -filename=/dev/sdX}}
* Задержка случайной записи: {{Cmd|1=fio -ioengine=libaio -sync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=60 -filename=/dev/sdX}}
* Пиковые IOPS случайной записи: {{Cmd|1=fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=60 -filename=/dev/sdX}}
«А почему так мало…» — см.ниже.
 
=== Тестирование кластера Ceph ===
Как тестировать Ceph после сборки:
* Полученный результат, в частности, может помочь выявить отдельную тупящую OSD
== Производительность случайной О транзакционности записи ==
{{[[Файл:Warning}} Сначала плохая icon.svg|32px]] Плохая новость!
Важная особенность 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 порядка меньшепроизводительность последовательного коммита операций по одной).
{{Box|1Другие почти идентичные варианты: fdatasync={{Note}} Старый FileStore на плохих дисках быстрее BlueStore где-то в 1.5 раза; хорошие он лучше утилизирует в один поток, то есть, у него меньше задержки. Но это не значит, что его надо использовать — по остальным параметрам FileStore устарел. Например, снапшоты там работают со скоростью снапшотов LVM (очень медленно), нет частичной перезаписи объектов в EC-пулах, нет контрольных сумм (вследствие чего вообще нельзя использовать size=2). Также CPU filestore жрёт сильнее и пиковые параллельные IOPS-ы у него хуже bluestore.}} В общем, чтобы понять, сколько у вас будет 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тестом журнала.
== Конденсаторы! ==
Нас спасёт такое чудо инженерной мысли, как '''SSD с конденсаторами''' (точнее, обычно суперконденсаторами — ионисторами). Которые на M.2 SSD, кстати, прекрасно видны невооружённым глазом:
И ещё один вариант — Intel Optane. Это тоже SSD, но они основаны не на Flash памяти (не NAND и не NOR), а вообще на другой технологии, называющейся 3D XPoint. Хз, как она работает, но заявляются 550000 iops при полном отсутствии необходимости в стирании блоков, кэше и конденсаторах. Но а) в применении к Ceph — нужно проверять — не факт, что Ceph вообще сможет выжать из них их iops-ы б) вариант дорогой, раза в 3 дороже типичной SSD (1500$ за 960 гб, 500$ за 240 гб).
 
== BlueStore vs FileStore ==
 
Хоть BlueStore и считается «новым» бэкендом хранилища, есть очень популярное мнение, что он тормозит и поэтому не нужен.
 
После долгого ковыряния в проблеме разъясняю: нет, BlueStore не тормозит «в целом». В частности:
 
* BlueStore в 2 раза быстрее FileStore при линейной записи (можно считать, что всегда), так как в нём крупные блоки пишутся 1 раз — сразу на устройство, а не 2 (в журнал и потом на устройство).
* BlueStore примерно равен FileStore по производительности случайной записи и latency в All-Flash кластерах. Пиковая производительность при этом обычно немного выше, однопоточная — немного ниже. Жор CPU тоже немного меньше. Всё это варьируется, но по крайней мере блюстор здесь не хуже.
 
ОДНАКО! BlueStore без дополнительных ухищрений действительно ХУЖЕ FileStore в популярной конфигурации HDD + журнал на SSD:
 
* Условно, собрав небольшой кластер на BlueStore, в 1 поток на HDD+SSD вы получите ~100 иопс на запись, а в FileStore ~500.
* Почему? Потому, что BlueStore очень часто делает сброс данных из очереди отложенной записи на HDD (каждые 32 операции, deferred_batch_ops) и при сбросе тормозит все последующие операции.
* В итоге случайная запись ждёт окончания записи не только на SSD, а также и на HDD.
* Ждёт оно так не каждую операцию, поэтому iops-ы лучше, чем просто на HDD. Но всё-таки ждёт, поэтому iops-ы хуже, чем в FileStore.
 
Как это полечить?
 
* Либо вместо журнала (или рядом с журналом) сделать на SSD bcache для HDD.
* Либо использовать HDD с 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).
== Контроллеры ==

Навигация