Производительность Ceph — различия между версиями

Версия 00:37, 9 августа 2018

Бенчмаркинг

Основные направления тестирования:

• Линейное чтение/запись (большими блоками)
• Случайное чтение/запись (транзакционное и мелкими блоками)
• Однопоточная нагрузка
• Параллельная нагрузка

Сначала прогоните fio на голом диске:

• Линейное чтение: fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=16 -rw=read -runtime=60 -filename=/dev/sdX
• Линейная запись: fio -ioengine=libaio -fdatasync=1 -direct=1 -invalidate=1 -name=test -bs=4M -iodepth=16 -rw=write -runtime=60 -filename=/dev/sdX
• IOPS-ы случайной записи: fio -ioengine=libaio -fdatasync=1 -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=16 -rw=randwrite -runtime=60 -filename=/dev/sdX

«А почему так мало…» — см.ниже.

После сборки Ceph можно тестировать так:

• IOPS через rados bench в режиме, соответствующем RBD (4 Кб блоки в 4 Мб объектах) и 16 одновременно запущенных виртуалок:
  rados bench -p ваш_пул -t 16 -b 4096 -o $((4096*1024)) 60 write
• Цифру 16 можно менять, скажем, от 1 до 128 (1 — 4 — 16 — 64 — 128), чтобы понять, как меняются IOPS-ы при разной степени параллелизма
• Тем же самым fio через ioengine=rbd (здесь fdatasync не нужен): fio -ioengine=rbd -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=16 -rw=randwrite -pool=rpool_hdd -runtime=60 -rbdname=testimg
• В несколько потоков — добавить к fio опцию `-jobs=N`
• Можно тестировать и fio изнутри виртуалки, НО в этом случае помните, что параллельной нагрузки она не создаст — qemu rbd драйвер работает в один поток.
• Производительность может отличаться на заполненном и незаполненном RBD-образе.
• При тестировании случайной записи в один поток вы фактически всё время тестируете ОДИН диск. То есть, всё время тестируются разные диски, но в каждый отдельный момент времени запрос идёт только к одной placement group (тройке-четвёрке-пятёрке дисков).
• Соответственно, вы не увидите 100 % утилизации дисков на хостах при тестировании в один поток. Однопоточная нагрузка не может полностью загрузить кластер.

Производительность случайной записи

Warning: Сначала плохая новость!

Важная особенность Ceph — вся запись, даже та, для которой никто этого явно не просит, ведётся транзакционно. То есть, никакая операция записи не завершается, пока она не записана в журналы всех OSD и не сделан fsync() диска. Так сделано, чтобы предотвращать RAID WRITE HOLE-подобные ситуации рассинхронизации данных между репликами при отключении питания, потере сети и т.п…

Сама запись на устройство и репликация с других OSD происходит отложенно и асинхронно, но какая разница — она все равно создаёт дополнительную нагрузку на устройства и притормаживает последующие запросы.

Всё это приводит к тому, что типичная настольная SSD-шка в Ceph выдаёт неприлично низкие IOPS-ы — обычно от 500 до 2000. И это при том, что при обычном тестировании почти любая SSD выдаёт > 20000 iops. Даже самый паршивый китайский noname выдаёт не менее 10000 iops. NVMe легко выжимает 150000 и больше. Но стоит начать использовать fsync… и та же NVMe выдаёт 600 iops (на 2.5 порядка меньше).

Старый FileStore выдаёт чуть больше iops-ов на плохих дисках, чем bluestore, так как он реже делает fsync. Но это не значит, что надо его использовать — по остальным параметрам он устарел. Например, снапшоты там работают со скоростью снапшотов LVM (очень медленно).

В общем, чтобы понять, сколько у вас будет IOPS-ов на запись в Ceph, диски под него нужно тестировать с опцией fio fsync=1. Или fdatasync=1, если тестируете поверх ФС. Или можно sync=1 iodepth=1, эффект обычно почти тот же, что от fsync=1. Разница между опциями (см. man fio):

• fsync=1 синхронизирует данные и метаданные тестируемого файла после каждой операции записи. Именно так работает BlueStore. Именно поэтому мы будем использовать именно эту опцию.
• fdatasync=1 синхронизирует только данные (но не метаданные) тестируемого файла после каждой операции записи. Соответственно, от fsync=1 это отличается, только если тестируется файл в ФС, а не блочное устройство.
• sync=1 использует синхронный ввод/вывод, то есть, каждая операция начинается после завершения предыдущей. Но штука в том, что почти все движки fio при этом открывают файл с O_SYNC. А вот O_SYNC уже означает, что каждая операция записи внутри сопровождается аналогом fsync. Но при этом если iodepth > 1, то в очередь диска до синхронизации «пролезает» несколько операций и IOPS-ы растут, тест перестаёт быть эквивалентным записи с fsync=1.

fdatasync=1 надо использовать, когда на диске уже есть ФС, а прогнать тест хочется. Результаты будут достаточно корректными.

Конденсаторы!

Нас спасёт такое чудо инженерной мысли, как SSD с конденсаторами (точнее, обычно суперконденсаторами — ионисторами). Которые на M.2 SSD, кстати, прекрасно видны невооружённым глазом:

Конденсаторы работают фактически как встроенный в SSD ИБП и позволяют SSD успеть сбросить кэш во флеш-память при потере питания. Таким образом кэш становится «энергонезависимым» — и таким образом SSD может просто игнорировать запросы fsync, так как точно знает, что данные из кэша в любом случае доедут до постоянной памяти.

При этом IOPS-ы транзакционной записи становятся равны IOPS-ами нетранзакционной.

Конденсаторы в официальных описаниях SSD-шек обычно называются «enhanced/advanced power loss protection». Этой характеристикой обладают почти только «серверные» SSD, да и то не все. Например, в Intel DC S3100 конденсаторов нет, а в Intel DC S4600 есть.

То есть, под Ceph следует закупать только такие SSD…

…Даже если рассматривать NVMe. NVMe без конденсаторов хуже, чем SATA с.

Пример теста

3 ноды по 3 SATA 7200rpm HDD, 10 гигабит ethernet. Ceph 13.2.1, bluestore.

rados bench EC-пула в 1/16/64/128 потоков:

• Журналы на HDD: 40/100/350/450 iops
• Журналы вынесены на старые серверные SSD (выдающие 22000 iops каждая): 170/620/720/940 iops

Итого при высокопараллельной нагрузке быстрее в 2 раза, при низкопараллельной в 4-6 раз.