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

Версия 00:43, 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 на плохих дисках раза в 1.5 быстрее, чем BlueStore, так как он реже делает fsync. Но это не значит, что его надо использовать — по остальным параметрам FileStore устарел. Например, снапшоты там работают со скоростью снапшотов LVM (очень медленно), нет частичной перезаписи объектов в EC-пулах, нет контрольных сумм (вследствие чего вообще нельзя использовать size=2).

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

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

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

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

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

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

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

Это и является главным отличием серверных SSD от настольных. Обычному пользователю транзакции нужны редко — а вот на серверах живут СУБД, которым транзакции как раз нужны позарез.

То есть, под 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 раз.