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

Ссылки сюда (2) →

Бенчмаркинг

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

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

Сначала прогоните 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 драйвер работает в один поток. Соответственно вы, скорее всего, не увидите 100 % утилизации дисков на хостах.
• Производительность может отличаться на заполненном и незаполненном RBD-образе

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

Сначала плохая новость.

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

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

Это приводит к тому, что типичная настольная SSD-шка при обычном использовании выдаёт 20000 iops на запись, а в Ceph — обычно от 500 до 2000, то есть минимум на порядок меньше. Всё съедают запросы синхронизации. В более старом filestore iops-ов чуть больше, чем в bluestore, так как он реже делает fsync. Но filestore — не выход, так как, например, снапшоты там работают со скоростью снапшотов LVM [очень медленно].

Однако есть и хорошая новость!

Инженерная мысль придумала такое чудо, как SSD-шки с (супер)конденсаторами, которые позволяют успеть сбросить кэш во флеш-память при потере питания — и просто игнорировать запросы fsync.

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

Отсюда вытекает несколько ВАЖНЫХ вещей:

• Чтобы понять, сколько у вас будет IOPS-ов на запись, диски под Ceph нужно тестировать с опцией fsync=1. Или fdatasync=1, если тестируете поверх ФС. Или можно sync=1 iodepth=1, эффект обычно почти тот же, что от fsync=1.
• Лучше SATA SSD с конденсаторами, чем NVMe без. Обычная NVMe-шка будет точно так же тормозить при синхронизации.