Назад | Перейти на главную страницу

Бенчмаркинг FIO - непоследовательно и медленнее, чем ожидалось: мои RAID настроены неправильно?

TL; DR: У меня проблемы с производительностью гипервизора. вот несколько результатов тестов от fio. Перейти к Results раздел, чтобы прочитать о них и увидеть мои вопросы.

Резюме

Я недавно купил R730xd, поэтому перед тем, как перейти на него, я хотел убедиться, что хранилище работает оптимально. Я провел несколько тестов с фио и обнаружили некоторые тревожные результаты. Используя комбинацию этих результатов и фио-сюжет, Я собрал довольно большую коллекцию графиков и диаграмм, которые демонстрируют проблемы в моих различных серверных модулях хранения.

Однако мне сложно превратить его в пригодный для использования Информация потому что мне не с чем сравнивать. И я думаю, что у меня очень странные проблемы с производительностью.

Конфигурация диска

Вот четыре типа хранилищ, доступных моему гипервизору (Proxmox):

╔═══════════╦════════════════════════════════╦═════════════╦════════════════════════════╗
║  Storage  ║            Hardware            ║ Filesystem  ║        Description         ║
╠═══════════╬════════════════════════════════╬═════════════╬════════════════════════════╣
║ SATADOM   ║ 1x Dell K9R5M SATADOM          ║ LVM/XFS     ║ Hypervisor filesystem      ║
║ FlashPool ║ 2x Samsung 970 EVO M.2 SSD     ║ ZFS RAID 1  ║ Hypervisor Compute Storage ║
║ DataPool  ║ 6x HGST 7200RPM HDD            ║ ZFS RAID 10 ║ Redundant Data Storage     ║
║ RAIDPool  ║ 6x Seagate/Hitachi 7200RPM HDD ║ HW RAID 10  ║ General Purpose Storage    ║
╚═══════════╩════════════════════════════════╩═════════════╩════════════════════════════╝

Детали хранения

Вот более подробная разбивка по каждому бэкэнду хранилища:

САТАДОМ: The SATADOM управляется Proxmox напрямую через LVM. Вот это результат lvdisplay pve. SATADOM подключается к серверу через внутренний порт SATA DVD-ROM, так как он не используется в R730xd модель.
FlashPool: The FlashPool представляет собой простой ZFS RAID 1, состоящий из двух твердотельных накопителей NVMe. Цель состоит в том, чтобы использовать это в качестве резервного хранилища для моих виртуальных машин. Вот выходы для:
```
 zpool list  
 zpool status  
 zfs get all
```
Каждый из SSD в FlashPool подключены к серверу через PCI-E -> адаптеры M.2 устанавливается в слоты x16 PCIe. Я понимаю, что это адаптеры x4 PCIe. Однако я почти уверен, что NVMe работает только на этой скорости, поэтому более быстрые адаптеры не производятся.
DataPool: The DataPool - единственный ранее существовавший набор данных. Ему пару лет, и ранее он использовался как для хранения данных, так и для виртуальных машин в ущерб производительности. Он также управляется Proxmox как ZFS RAID 10.

Первоначально он состоял из 6x 4TB HGST Ultrastar 7K4000 7200RPM диски. Однако, когда они начали выходить из строя, я решил заменить их дисками с большей плотностью. В результате теперь массив состоит из:
```
 2x 6TB HGST Ultrastar He6 7200RPM  
 4x 4TB HGST Ultrastar 7K4000 7200RPM 
```
Очевидно, я намерен в конечном итоге полностью перейти на диски 6 ТБ, поскольку старые продолжают выходить из строя. Вот являются выходными данными для тех же команд, указанных выше для FlashPool.

Эти 6 дисков подключены к серверу через первые 6 отсеков на объединительной плате. Эта объединительная плата подключена к RAID-контроллеру Dell H730 Mini PERC.
RAIDPool: The RAIDPool это экспериментальный бэкэнд хранилища. Я никогда раньше не работал с аппаратным RAID, поэтому я был очень рад возможности теперь, когда у меня есть правильный RAID-контроллер. Подобно DataPoolэти диски устанавливаются в последние 6 отсеков объединительной платы. Однако вместо того, чтобы проходить через Proxmox, они управляются PERC. Они представляются Proxmox как один диск, который затем управляется LVM и представляется операционной системе через логические тома как файловые системы XFS. Вот это результат lvdisplay RAIDPool.

Конфигурация RAID-контроллера

Итак, вы, возможно, только что заметили, что оба DataPool и RAIDPool устанавливаются и управляются RAID-контроллером H730. Однако DataPool управляется Proxmox через ZFS и RAIDPool управляется фактическим контроллером.

Вот это скриншот топологии физических дисков. H730 может передавать диски напрямую в ОС и одновременно управлять другими дисками. Как видите, первые 6 дисков настроены в Non-RAID режим и последние 6 дисков настраиваются в Online Режим.

Вот являются настроенными свойствами для контроллера из пользовательского интерфейса iDRAC.
Дисковый кэш включен как для обратной записи, так и для опережающего чтения на виртуальном диске (RAIDPool). Поскольку это настроено специально для виртуального диска, это не должно влиять на диски ZFS.
Dick Cache для не-RAID диски (ZFS DataPool) установлен на Disable.
В Скорость соединения для всех дисков установлено значение auto.

Кроме того, после повторного прохождения всех настроек я включил Write Cache для встроенного контроллера SATA. Таким образом, это может улучшить производительность на SATADOM из того, что видно в тестах ниже.

Бенчмаркинг:

Я протестировал все эти серверные модули хранения двумя способами. Для обоих тестов я провел серию fio-plot команды в небольшой сценарий оболочки это сбросило результаты в несколько папок.

Если вы сошли с ума и хотите самостоятельно проанализировать необработанные результаты, они здесь. Вам нужно будет немного помассировать мои сценарии для повторного запуска, так как я переместил структуру каталогов, чтобы организовать ее перед загрузкой.

Вкратце, они провели серию тестов для каждого бэкэнда хранилища, которые оценили его СЛУЧАЙНЫЙ пропускная способность, количество операций ввода-вывода в секунду и задержка. Затем он нанес эти результаты на графики. Некоторые графики сравнивают несколько бэкэндов. На других графиках просто показаны результаты отдельных серверных ВМ. Я не выполнял никаких ПОСЛЕДОВАТЕЛЬНЫЙ тесты. Во всех случаях для теста использовался размер блока по умолчанию.

Тест 1) Изнутри Proxmox я смонтировал все серверные модули хранения в /mnt каталог. Пул ZFS был просто импортирован в ОС, а пул RAIDPool и SATADOM были представлены в ОС через LVM. У каждого был логический том, отформатированный как раздел XFS, который использовался для тестирования. ПРИМЕЧАНИЕ. Я запускал эти тесты в реальной ОС, поэтому производительность SATADOM будут затронуты соответственно.

Файлы журнала были созданы с помощью следующих команд:

./bench_fio --target /mnt/SATADOM_Data/bm --type directory --size 450M --mode randread randwrite --output SATADOM
./bench_fio --target /mnt/RAIDPool_Data/bm --type directory --size 1G --mode randread randwrite --output RAIDPOOL
./bench_fio --target /mnt/DataPool/bm/ --type directory --size 1G --mode randread randwrite --output DATAPOOL
./bench_fio --target /mnt/FlashPool/bm/ --type directory --size 1G --mode randread randwrite --output FLASHPOOL

Тест 2) Я создал три виртуальные машины в Proxmox. Каждый из них использовал другое резервное хранилище из FlashPool, DataPool, и RAIDPool. В FlashPool и виртуальные машины DataPool работали в собственном наборе данных ZFS. В RAIDPool ВМ работала на собственном логическом томе с толстым выделением ресурсов. Всем трем виртуальным машинам было предоставлено 4 виртуальных ЦП и 40 ГБ памяти.

Файлы журнала были созданы с помощью следующих команд:

./bench_fio     --target /fio     --type file     --size 1G     --mode randread randwrite     --duration 600     --output DATAPOOL_VM
./bench_fio     --target /fio     --type file     --size 1G     --mode randread randwrite     --duration 600     --output RAIDPOOL_VM
./bench_fio     --target /fio     --type file     --size 1G     --mode randread randwrite     --duration 600     --output FLASHPOOL_VM

Полученные результаты:

Графики в приведенных выше ссылках на Imgur должны быть в одном порядке. Результаты двух тестов немного отличаются. Но этого следовало ожидать, если учесть накладные расходы от виртуализации. Я НЕ ожидаю, что все они будут вести себя примерно одинаково.

Например, этот график показывает, что когда fio был запущен из виртуальной машины, средняя пропускная способность записи была где-то около 125 МБ / с. Разве два твердотельных накопителя NVMe в RAID 1 (FlashPool) МАССИВНО превосходит SATADOM? Вместо этого вы можете видеть, что FlashPool Виртуальной машине потребовалось НАИБОЛЬШЕЕ количество времени для завершения теста и самая низкая средняя пропускная способность записи. Такая же ситуация наблюдается для Написать IOPS для сравнения - среднее значение IOPS было около 3000, а FlashPool VM выполняла тест дольше всех!
Отойдя от тестов, взятых из ВНУТРИ виртуальной машины, и вместо этого посмотрев на тесты, полученные при прямом взаимодействии с хранилищем из гипервизора, мы можем увидеть несколько иное поведение. Например, в этом тесте пропускная способность записи для FlashPool и DataPool достигала 400 МБ / с. Однако производительность для RAIDPool в среднем около 10 МБ / с. Который по совпадению был примерно таким же, как и SATADOM? Конечно, RAIDPool должен был работать совместим с, если не лучше, чем DataPool? Учитывая, что они состоят из одинаковых дисков, присутствующих в одном RAID-контроллере? Как и выше, Написать IOPS покажите ту же причудливую историю.
Задержка записи из тестов гипервизора тоже кажется необычным. В RAIDPool задержка в десять раз хуже, чем у пулов ZFS? Однако если вы перейдете на Тесты ВМ, задержка для трех серверных модулей хранения, похоже, составляет около 300 мкс. Что очень похоже на то, что мы видели в НАИЛУЧШИХ актерах для RAIDPool. Почему возникает этот плавный эффект задержки записи, когда тесты запускаются с виртуальных машин вместо гипервизора? Почему задержка для пулов ZFS внезапно стала намного хуже и сравнима с задержкой RAIDPool?
Если посмотреть на пропускную способность чтения, количество операций ввода-вывода в секунду и задержку, можно увидеть аналогичную картину. Все показатели одинаково медленные, несмотря на сильно различающиеся конфигурации оборудования при тестировании из виртуальной машины. Однако после тестирования гипервизора пулы ZFS внезапно значительно превосходят все остальное?

Вопросы:

Эти результаты ненормальные ... не так ли? это эталон от этот веб-сайт показывает, что 970 EVO достигает скорости произвольной записи более 900 МБ / с. Почему мои приходят только в 150 МБ / с на гипервизоре и 10 МБ / с в виртуальной машине? Почему эти скорости так различаются при тестировании на гипервизоре и на виртуальной машине?
Почему RAIDPool вдруг стал ненормально медленным при тестировании из гипервизора? Вот мы видим, что пропускная способность чтения в виртуальной машине составляет в среднем 20 МБ / с. Однако из гипервизор, вместо этого он сообщает 4 МБ / с. Как и в тестовых тестах, которые я показал в вопросе 1, разве эти скорости чтения не должны быть ближе к 900 МБ / с?
Почему пулы ZFS внезапно работают значительно хуже при тестировании из виртуальной машины, а не из гипервизора? Например, Вот мы видим, что среднее количество операций ввода-вывода в секунду при чтении составляет около 200 000, а задержка - менее 650 мкс. Однако при сравнении с внутри ВМ, мы можем внезапно увидеть, что среднее значение IOPS при чтении составляет около 2500, а задержка увеличилась более чем в четыре раза? Разве производительность в обеих ситуациях не должна быть примерно одинаковой?

При тестировании пулов ZFS вам необходимо понимать, как кэширование и запись взаимодействуют с вашими рабочими нагрузками:

ваш fio команды не пропускают кэш страниц linux (нет --direct=1 вариант), ни ZFS ARC. Однако из-за разного режима работы между ними вы можете отказаться от предпочтения простой файловой системы (XFS) по сравнению с ZFS или наоборот. Чтобы смягчить эффект кэширования, я предлагаю вам выполнить сравнительный анализ с файлом, в 2 раза превышающим значение вашего ОЗУ (то есть: если у вас 24 ГБ ОЗУ, используйте файл 48 ГБ). Делать не эталонный тест ZFS с отключенным кешированием (т.е. primarycache=none), как файловая система CoW потребности высокая частота попаданий в кеш для обеспечения хорошей производительности (особенно при записи блоков размером меньше записей, как вы можете прочитать ниже);
ZFS серьезно повлияет на ваши случайные IOP чтения / записи и производительность мышления. recordsize свойство, поскольку ZFS обычно передает полные блоки с записью (за исключением небольших файлов, где "маленький" означает <размер записи). Другими словами, пока fio читает / записывает блоки размером 4 КБ, ZFS на самом деле читает / записывает блоки размером 32 КБ для каждого блока 4K запрошенный fio. Кэширование может (и будет) изменить это общее правило, но суть остается в силе: при большом размере записи может возникнуть насыщение пропускной способности. Обратите внимание, что я не заявить, что размер записи 32 КБ является необоснованным (хотя я бы, вероятно, использовал 16 КБ, чтобы ограничить износ SSD); однако вы должны учитывать это при оценке результатов теста;
Я бы снова включил кэш физического диска для дисков прямого доступа, поскольку ZFS знает, как очистить их изменчивый кеш. Однако вам необходимо убедиться, что ваш H730P поддерживает ATA FLUSHes / FUA для проходных дисков (это должен передать синхронизацию, но ее руководство по этому поводу неясно, и у меня нет реального оборудования, чтобы попробовать);
ваш RAIDPool массив состоит из механических жестких дисков, поэтому его производительность при случайном чтении будет низкой (кеш контроллера не поможет вам при случайном чтении).

При всем уважении, я не считаю ваши результаты ненормальными; скорее, они не представляют собой действительную рабочую нагрузку и частично неправильно интерпретируются. Если вы действительно хотите сравнить ZFS и HWRAID + XFS, я предлагаю вам протестировать фактическую ожидаемую рабочую нагрузку (то есть: виртуальные машины базы данных + приложения, выполняющие некоторые полезные действия), в то же время обязательно использовать ThinLVM (а не классический LVM), чтобы иметь, по крайней мере, возможность быстрого создания снимков, несколько сопоставимую с собственными функциями снимков / клонов ZFS.

Но в некотором смысле вы можете избежать этих тестов просто потому, что результат будет довольно предсказуемым:

простая установка HWRAID + LVM + XFS будет быстрее для произвольного чтения / записи наборов данных, которые вписываются в кэш страниц Linux: не подверженный влиянию CoW, он требует гораздо меньших накладных расходов, чем ZFS;
установка ZFS будет быстрее в реальных сценариях, где устойчивая к сканированию природа ARC гарантирует, что наиболее часто используемые данные всегда будут кэшироваться. Более того, сжатие и контрольная сумма - две смертоносные функции (чтобы иметь аналогичные функции из HWRAID, вам нужно использовать сложенный dm-integrity + vdo + thinlvm setup, что само по себе приводит к значительному снижению производительности).

В качестве ориентира я недавно заменил Dell R720xd с дисками H710P + 12 10K RPM SAS на гораздо более дешевый SuperMicro 5029WTR с 2x SSD (для загрузки и L2ARC) + 1x NVMe Optane (для SLOG) и 6x 7.2K RPM SATA-дисками. . Система SuperMicro, имея только 1/3 номинальной производительности произвольного чтения, чем система Dell, работает намного лучше благодаря ARC / L2ARC и сжатию.

В конце концов, хотя я полностью понимаю мотивы использования классической системы HWRAID + LVM + XFS, я бы не стал снова использовать ее вместо ZFS для голого компьютера в качестве гипервизора (если не нацелен на конкретные рабочие нагрузки, которые действительно плохо работают с слой CoW между ними или когда требуются экстремальная скорость и DirectIO - см. XFS dax вариант).