1. Максимальное число дисков.
На сервере, выбранном под тесты, (какая-то достаточно старая Supermicro 2U, материнскую плату попозже посмотрю) можно было поставить всего 6 NVME дисков. Это лучше, чем у меня было в 2021 году, тогда на сервере было всего по два слота на панели под NVME, остальные SAS. Или же было всего 4, то есть по 2 на сокет? Не помню.
На новых серверах, скорее всего это будут Supermicro Hyper SuperServer SYS-221H-TN24R, заявлено 24 front hot-swap 2.5" NVMe*/SAS*/SATA* drive bays. Надо будет еще раз посмотреть и посчитать, стоит ли оно того.
Ирония ситуации в том, что, может быть, нам больше 150-200k IOPS блоком 4k и не надо, а с этим справится и младшая Huawei Dorado 5000 v6, даже не v7. Которых (v7) то даже нам пока не поставляют. Пока писалась статья, может уже и стали поставлять, давно не спрашивал.
2. Огромное число вариантов тестов, комбинаторный взрыв.
Настройки BIOS, варианты прошивок, настройки OS, настройки тестов. Все вместе, порой, вызывает больше вопросов, чем дает ответов.
3. RAID и новый вариант проблемы Read–modify–write
Когда-то давно все диски были с разметкой 512 (иногда 520), и проблемы с тем, что блок меньшего размера пишется в страйп большего размера, были не так значимы. Была проблема с выравнивание разделов, но ее решили (starting offset - Disk performance may be slower than expected when you use multiple disks)
Зато теперь есть проблема с Write amplification.
Теперь же оптимизация 512-4096-512 плюс файловая система может дать, в кривых руках (например, моих), Raid write penalty не 4, как положено по написанному в середене нулевых калькулятору, а x4x4, то есть x16.
4. Прочие не заданные вопросы.
Почему не Linstor? Потому что Linstor, прежде всего, нужно долго тестировать в разных сценариях поверх дисков. Это на всяких SMM помойках в зоне ру пишут «мы запустили русский HGUI к Linstor, аналоговнет» - но нам работать надо, причем в сценариях, когда отказать может не один диск, и даже не один сервер, а стойка целиком. На метрокластер фирма пока не заработала, хотя уже приценивается. Отсюда обязательные требования по MPIO, причем не с переключением за 2 минуты, и отработка сценариев отказов. Что там у Linstor с MPIO?
FC в топку, Cisco Nesux, особенно с Fabric Extenders (FEX) – на помойку, глючное под нагрузкой. Juniper у меня и не было.
Arista топ.
Но, посмотрим. Соседний отдел уже полгода мотает от «хотим Linstor» до «SupremeRAID купите позязя». Потом они пойдут смотреть на weka, vastdata (Cosmos), vast.ai.
Разные ОС по разному работают с дисками. Поскольку Broadcom ESXi стал не просто дорого, а очень дорого, то выбор остался между Microsoft Hyper-V (но нужно сразу считать стоимость DC лицензии, плюс лицензии SCOM, SCVMM) и Proxmox. Итогом, понятно, будет гибридная инфраструктура – часть в облаке, часть на Proxmox, часть на Windows. У нас тут без предрассудков.
Почему не чистый, ванильный KVM? Не знаю, как-то не рассматривали этот вариант.
Закончим с теорией, перейдем к практике.
Использовались: Micron 7450 SSD Gen4 pro по 3840 Gb. Спецификация: Micron 7450 SSD Series Technical Product Specification
Заявлено:
- Random 4KB READ: Up to 1,000,000 IOPS
- Random 4KB WRITE: Up to 400,000 IOPS
Точнее данные описаны в таблице 1: Table 1: Drive Performance – PRO
И начинаются фокусы.
Во первых, для разных емкостей и моделей заявлена разная производительность.
Во вторых, для разных тестов использована разная глубина очереди:
• Sequential workloads measured using FIO with a queue depth of 32
• Random READ workloads measured using FIO with a queue depth of 256
• Random WRITE workloads measured using FIO with a queue depth of 128
или:
Latency values measured under the following configuration:
• Random workloads using FIO with 4KB transfers and a queue depth of 1
Особо надо обратить внимание на питание и охлаждение.
3. Power limiting is configured through Set/Get Features Power Management.
4. Power consumption measurements are for reference only; actual workload power consumption will vary
Указано, что в среднем диски выдают до 15 ватт тепла, но в пике указано потребление до 2 ампер по линии 12 вольт, то есть 24 ватта на диск. На 6 дисков это плюс 150 ватт. Проблема не в блоках питания, а в том, что диски стоят спереди, и процессоры «за ними» обдуваются весьма горячим воздухом. В теории у нас на входе +20, а на процессоры приходит воздух уже +30, а то и +35, и на выходе получаем и +70..+80 на самих процессорах, и обдув памяти с ее нагревом. Поэтому не забывайте сразу настроить мониторинг CPU \ RAM temp, через IPMI – iBMC – iDRAC – iLO, или что там у вас.
И, само собой, не забывайте считать пределы отведения по теплу, иначе получите, рано или поздно, что ваше охлаждение из N+1 превратилось в N+0.
Еще немного теории, теперь про DiskSPD.
У DiskSPD есть несколько критичных параметров. Это:
Измененная методика работы в последней версии, цитата:
Previously Diskspd would issue the requested number of I/Os (T0), then receive and record one I/O at a time (T1)
С рекомендацией:
Since these changes can be so dramatic, you should re-baseline your storage performance using the latest version of Diskspd.
To keep pace with the advances in disk speeds and the improvements in Windows Server 2025, we’ve made investments in our storage performance benchmark tool to get you an accurate measure of latency.
Кстати, я там плакал, что нет экспорта в XML? Он есть:
-R[text|xml] Display test results in either text or XML format (default: text).
Никогда не ходил в эту секцию библиотеки, а, видимо, придется: Event Tracing for Windows (ETW) parameters
Всплыли некоторые неочевидные (если не читать) подробности, например, конфликтующие параметры:
-F<count> Total number of threads. Conflicts with -t, the option to set the number of threads per file.
-t<count> Number of threads per target. Conflicts with -F, which specifies the total number of threads.
Поэтому, если вы используете несколько целевых файлов, и ключ –t – как в примере:
diskspd [options] target1 [ target2 [ target3 ...]
То у вас число потоков (тредов, нитей) будет расти с ростом числа файлов. Что надо было бы мне учесть перед тестами, но я, конечно, не учел.
Еще немного теории, уже почти все.
В школе всех учили и учат, что есть один путь решения и одно правильное решение. Поезда встречаются на определенном полустанке, машина из А в Б приедет за 5 часов 55 минут, итд.
В техническом институте учат, что все ваши измерения – фигня полная. Не бывает ровно 28 сантиметров, ровно 22 секунды. Бывает 28 сантиметров плюс минус погрешность инструмента, плюс минус погрешность методики, плюс минус систематическая и так далее, поэтому «примерно 24-29 см» приемлемый результат. Хотите большей точности – работайте с ошибками и инструментами.
Курса со второго (иногда с первого) учат, что ошибка – это нормально. Лучше, конечно, не делать грубых ошибок, но умеренно ошибаться при опытах и постановке опыта «тоже сойдет». Грубых ошибок делать не надо, ТБ нарушать не надо. Там же учат иногда подгонять ответ под требуемый результат, и оценивать результат с точностью до порядка.
Так что полученные ниже результаты – повод для обсуждения, где именно можно улучшить методику, какие параметры покрутить. Или же все переписать и переделать.
Windows Server 2019 и 2022: сопоставимые результаты.
Хотя, еще как посмотреть, насколько сопоставимые, и в каких сценариях. Например ResiliencySettingName: Parity в Server 2019 работало с багами, до какого-то очередного фикса.
Тесты существенно округлены в основном в меньшую сторону, то есть 142к > округлено вверх до 150к, 139к округлено куда получится.
Number of threads per target: 10
Number of outstanding I/O requests per-target per-thread: 16
target:1
Кеширование: выключено
Тип пула (New-StoragePool): LogicalSectorSizeDefault: по умолчанию.
Типы дисков: New-Volume ProvisioningType: Thin, Fixed. Результаты сопоставимы для обоих типов дисков (что очень странно для поклонников старой школы), поэтому приводятся без разбивки.
Форматирование: NTFS 4k
ResiliencySettingName: Mirror
Чтение блоком 4к: 600к IOPS
Запись блоком 4к: 250к IOPS
Чтение блоком 64к: 450к IOPS
Запись блоком 64к: 100к IOPS
Number of threads per target: 15
Number of outstanding I/O requests per-target per-thread: 16
Targets:4
ResiliencySettingName: Mirror
Чтение блоком 4к: 2500к IOPS
Запись блоком 4к: 900к IOPS
Чтение блоком 64к: 650к IOPS
Запись блоком 64к: 150к IOPS
Следующий вариант тестов:
Number of threads per target: 15
Number of outstanding I/O requests per-target per-thread: 16
Targets:4
ResiliencySettingName: Parity. Важно: я с этой настройкой не экспериментировал, хотя в 1 и 2 частях написано про важность грамотной настройки именно в этой части. Поэтому производительность в Parity на запись, при настройках по умолчанию, будет отвратительной.
Чтение блоком 4к: 2800к IOPS (внезапно для меня, чтение для Parity работает отлично)
Запись блоком 4к: 45к IOPS. Да, просадка с 900k до 45k. Не в 4 раза, и даже не в 10. Выглядит, как результат все той же проблемы – read-modify-write, когда из страйпа читается один блок, изменяется и перезаписывается.
Чтение блоком 64к: 650к IOPS
Запись блоком 64к: 20к IOPS
Огромная просадка по записи. Просто чудовищная.
При этом, я смотрю на среднее отклонение, и вижу в нем какие-то всплески на 10-20% . Что это было? Меня на повторное проведение лабораторных работ в институте отправляли и за меньшие отклонения и нарушения.
Видимо, придется все переделывать.
Windows Server 2025.
В 2025 сервере обещали улучшить, углубить, итд. Посмотрим
Number of threads per target: 15
Number of outstanding I/O requests per-target per-thread: 16
Targets:4
ResiliencySettingName: Mirror
Чтение блоком 4к: было 2500к IOPS, стало: почти 3000к IOPS
Запись блоком 4к: было 900к IOPS, стало почти 1000 к IOPS. Опять наблюдается разброс в скорости между тонкими и фиксированными дисками, что говорит о том, что надо проводить не 2 теста по 5 минут, а 6 тестов по 10 минут и смотреть среднее, да и на задержки поглядывать.
Чтение блоком 64к: 650к IOPS. Без существенных изменений.
Запись блоком 64к: 150к IOPS. Без существенных изменений.
Следующий вариант тестов:Number of threads per target: 15
Number of outstanding I/O requests per-target per-thread: 16
Targets:4
ResiliencySettingName: Parity. Важно: я с этой настройкой не экспериментировал, хотя в 1 и 2 частях написано про важность грамотной настройки именно в этой части. Поэтому производительность в Parity на запись, при настройках по умолчанию, будет отвратительной.
Чтение блоком 4к: было 2800к IOPS, стало почти 3000к IOPS.
Запись блоком 4к: было 45к IOPS, стало 80к IOPS.
Чтение блоком 64к: было 650к IOPS. Без существенных изменений.
Запись блоком 64к: было 20к IOPS. Стало 30 к IOPS.
Тестирование только DiskSPD или FIO показывает некие повторяемые цифры, которые напрямую не конвертируются в ответ «будет ли работать SQL быстрее, и, если да, то насколько».
Подойти ближе к ответу позволяют:
SQLIOSim
SQL Query Stress Tool
HammerDB
И прочие инструменты.
Stay tuned
PS.
Особенно меня радует отсутствие экспертов (ТМ) в комментариях.
Уровень комментаторов и так упал ниже уровня Хабра, хотя, казалось бы, что может быть более днищевым, чем редакция Хабра и активно ими создаваемые аккаунты с активной гражданской позицией из одного комментария.
Комментарии про «СХД OceanStore 2288» умиляют глубиной безграмотности.
Ирония в том, что технике, лишенной духа машины, не скажешь «ну, надо».
3rd: Sentience is the ability to learn the Value of Knowledge.
4th: Intellect is the Understanding of Knowledge.
