Использование DISKSPD для тестирования производительности хранилища рабочей нагрузки

Статья
02/26/2024

Область применения: Azure Stack HCI версий 22H2 и 21H2; Windows Server 2022, Windows Server 2019

В этом разделе содержатся рекомендации по использованию DISKSPD для тестирования производительности хранилища рабочей нагрузки. Кластер Azure Stack HCI настроен и готов к работе. Отлично, однако как узнать, будете ли вы получать обещанные метрики производительности, будь то задержка, пропускная способность или операции ввода-вывода в секунду? Именно сейчас можно обратиться к DISKSPD. Прочитав этот раздел, вы узнаете, как запустить DISKSPD, понять подмножество параметров, интерпретировать выходные данные и получить общее представление о переменных, влияющих на производительность хранилища рабочих нагрузок.

Что такое DISKSPD?

DISKSPD — это средство командной строки для создания операций ввода-вывода для микро-тестирования производительности. Отлично, так что все эти термины означают? У всех, кто настраивает кластер Azure Stack HCI или физический сервер, есть причина. Это может быть настройка среды веб-размещения или запуск виртуальных рабочих столов для сотрудников. Каким бы ни был реальный вариант использования, скорее всего, вам потребуется смоделировать тест перед развертыванием фактического приложения. Однако тестирование приложения в реальном сценарии зачастую бывает сложной задачей— именно в этом случае используется DISKSPD.

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

Теперь вы знаете, что такое DISKSPD, но когда его следует использовать? DISKSPD трудно эмулировать сложные рабочие нагрузки. Но DISKSPD отлично подходит, когда рабочая нагрузка не приблизилась к однопоточной копии файла, и вам нужно простое средство, которое дает приемлемые базовые результаты.

Краткое руководство. Установка и запуск DISKSPD

Без лишних слов, давайте приступим к работе:

На компьютере управления откройте PowerShell от имени администратора, чтобы подключиться к целевому компьютеру, который требуется протестировать с помощью DISKSPD, а затем введите следующую команду и нажмите клавишу ВВОД.
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
В этом примере мы запускаем виртуальную машину с именем node1.

Чтобы скачать средство DISKSPD, введите следующие команды и нажмите клавишу ВВОД:

$client = new-object System.Net.WebClient

$client.DownloadFile("https://github.com/microsoft/diskspd/releases/download/v2.1/DiskSpd.zip","<ENTER_PATH>\DiskSpd-2.1.zip")

Чтобы распаковать скачанный файл, используйте следующую команду:
```
Expand-Archive -LiteralPath <ENTERPATH>\DiskSpd-2.1.zip -DestinationPath C:\DISKSPD
```
Перейдите в каталог DISKSPD и найдите соответствующий исполняемый файл для операционной системы Windows, на котором работает целевой компьютер.

В этом примере мы используем версию amd64.

Примечание

Вы также можете скачать средство DISKSPD непосредственно из репозитория GitHub , содержащего код с открытым кодом, и вики-страницы со всеми параметрами и спецификациями. В репозитории в разделе Выпуски выберите ссылку, чтобы автоматически скачать ZIP-файл.

В ZIP-файле вы увидите три вложенные папки: amd64 (64-разрядные системы), x86 (32-разрядные системы) и ARM64 (системы ARM). Эти параметры позволяют запускать средство в каждой версии клиента или сервера Windows.
Запустите DISKSPD с помощью следующей команды PowerShell. Замените все, что находится в квадратных скобках, включая сами скобки, соответствующими параметрами.
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Ниже приведен пример команды, которую можно выполнить:
```
 .\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Примечание

Если у вас нет тестового файла, создайте его с помощью параметра -c . Если вы используете этот параметр, обязательно укажите имя тестового файла при определении пути. Например: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. В примере команды IO.dat — имя тестового файла, а test01.txt — имя выходного файла DISKSPD.

Указание ключевых параметров

Ну, это было просто так? К сожалению, это не все. Давайте распакуем то, что мы сделали. Во-первых, есть различные параметры, с которыми можно возиться, и они могут получить конкретные. Однако мы использовали следующий набор базовых параметров:

Примечание

Параметры DISKSPD чувствительны к регистру.

-t2: указывает количество потоков для каждого целевого или тестового файла. Это число часто зависит от количества ядер ЦП. В этом случае для нагрузки на все ядра ЦП использовались два потока.

-o32: указывает количество невыполненных запросов ввода-вывода для каждого целевого объекта на поток. Это также называется глубиной очереди, и в данном случае 32 использовались для загрузки ЦП.

-b4K: указывает размер блока в байтах, КиБ, МиБ или ГиБ. В этом случае размер блока 4K использовался для имитации теста случайного ввода-вывода.

-r4K: указывает на случайный ввод-вывод , выровненный по указанному размеру в байтах, КиБ, МиБ, Gib или блоках (переопределяет параметр -s). Общий размер 4 КБ использовался для правильного согласования с размером блока.

-w0: указывает процент операций, которые являются запросами на запись (-w0 эквивалентно 100 % чтения). В этом случае для простого теста использовалось 0 % операций записи.

-d120: указывает продолжительность теста, не включая охлаждение или разминки. Значение по умолчанию — 10 секунд, но мы рекомендуем использовать не менее 60 секунд для любой серьезной рабочей нагрузки. В этом случае для минимизации выбросов использовалось 120 секунд.

-Suw: отключает кэширование программной и аппаратной записи ( эквивалентно -Sh).

-D: записывает статистику операций ввода-вывода в секунду, например стандартное отклонение, с интервалами в миллисекундах (на поток, на целевой объект).

-L: измеряет статистику задержки.

-c5g: задает размер файла образца, используемого в тесте. Его можно задать в байтах, КиБ, МиБ, ГиБ или блоках. В этом случае использовался целевой файл размером 5 ГБ.

Полный список параметров см. в репозитории GitHub.

Общие сведения о среде

Производительность в значительной степени зависит от среды. Итак, что такое наша окружающая среда? Наша спецификация включает кластер Azure Stack HCI с пулом носителей и Локальные дисковые пространства (S2D). В частности, существует пять виртуальных машин: DC, node1, node2, node3 и узел управления. Сам кластер представляет собой кластер с тремя узлами с трехсторонней зеркальной структурой устойчивости. Таким образом, сохраняются три копии данных. Каждый узел в кластере является Standard_B2ms виртуальной машиной с максимальным числом операций ввода-вывода в секунду 1920. На каждом узле имеется четыре диска SSD P30 ценовой категории "Премиум" с максимальным ограничением операций ввода-вывода в секунду 5000. Наконец, каждый SSD-диск имеет 1 ТБ памяти.

Вы создаете тестовый файл в едином пространстве имен, которое предоставляет общий том кластера (CSV) (C:\ClusteredStorage), чтобы использовать весь пул дисков.

Примечание

В примере среды нет Hyper-V или вложенной структуры виртуализации.

Как вы увидите, можно независимо достичь предела пропускной способности или количества операций ввода-вывода в секунду на виртуальной машине или на диске. Поэтому важно понимать размер виртуальной машины и тип диска, так как они имеют максимальное ограничение операций ввода-вывода в секунду и потолок пропускной способности. Эти знания помогают найти узкие места и понять результаты производительности. Дополнительные сведения о том, какой размер может подходить для вашей рабочей нагрузки, см. в следующих ресурсах:

Общие сведения о выходных данных

Имея представление о параметрах и среде, вы готовы интерпретировать выходные данные. Во-первых, целью предыдущего теста было максимальное количество операций ввода-вывода в секунду без учета задержки. Таким образом, вы сможете визуально увидеть, достигли ли вы предела искусственного ввода-вывода в секунду в Azure. Если вы хотите графически визуализировать общее количество операций ввода-вывода в секунду, используйте Windows Admin Center или диспетчер задач.

На следующей схеме показано, как выглядит процесс DISKSPD в нашем примере среды. В ней показан пример операции записи 1 МиБ из узла без координатора. Трехсторонняя структура устойчивости, а также операция с узла без координатора приводит к двум прыжкам сети, снижая производительность. Если вам интересно, что такое узел-координатор, не волнуйтесь! Вы узнаете об этом в разделе Вещи, которые следует учитывать . Красные квадраты представляют узкие места виртуальной машины и диска.

Теперь, когда у вас есть представление о визуальных элементах, давайте рассмотрим четыре main раздела выходных данных файла .txt:

Входные параметры

В этом разделе описывается выполненная команда, входные параметры и дополнительные сведения о тестовом запуске.
Сведения об использовании ЦП

В этом разделе рассматриваются такие сведения, как время тестирования, количество потоков, количество доступных процессоров и среднее использование каждого ядра ЦП во время теста. В этом случае есть два ядра ЦП, которые в среднем используют около 4,67 %.
Всего операций ввода-вывода

Этот раздел состоит из трех подразделов. В первом разделе рассматриваются общие данные о производительности, включая операции чтения и записи. Во втором и третьем разделах операции чтения и записи разделяются на отдельные категории.

В этом примере видно, что общее число операций ввода-вывода было 234408 в течение 120-секундного периода. Таким образом, число операций ввода-вывода в секунду = 234408 /120 = 1953,30. Средняя задержка составила 32,763 миллисекунд, а пропускная способность — 7,63 МиБ/с. Из более ранних сведений мы знаем, что 1953,30 операций ввода-вывода в секунду приближается к ограничению 1920 операций ввода-вывода в секунду для нашей Standard_B2ms виртуальной машины. Не верите? При повторном запуске этого теста с использованием других параметров, таких как увеличение глубины очереди, вы обнаружите, что результаты по-прежнему будут ограничены этим числом.

Последние три столбца показывают стандартное отклонение операций ввода-вывода в секунду в 17,72 (от параметра -D), стандартное отклонение задержки в 20,994 миллисекундах (от параметра -L) и путь к файлу.

На основе результатов можно быстро определить, что конфигурация кластера ужасна. Вы увидите, что для виртуальной машины превышено ограничение 1920 до ограничения SSD 5000. Если бы вы были ограничены SSD, а не виртуальной машиной, вы могли бы воспользоваться преимуществами до 20 000 операций ввода-вывода в секунду (4 диска * 5000), растянув тестовый файл на несколько дисков.

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

Вторая связь в фигуре важна, и это иногда называют законом Литтла. Закон вводит идею о том, что есть три характеристики, которые управляют поведением процесса, и что вам нужно изменить только один, чтобы повлиять на два других, и, следовательно, на весь процесс. Таким образом, если вы недовольны производительностью вашей системы, у вас есть три измерения свободы влияния на нее. Закон Литла предписывает, что в нашем примере число операций ввода-вывода — это пропускная способность (количество операций ввода-вывода в секунду), задержка — это время очереди, а глубина очереди — «инвентаризация».
Анализ процентилей задержки

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

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

Кроме того, "девятки" относятся к числу девятки. Например, "3-девятки" эквивалентно 99-му процентилям. Число девятки указывает, сколько операций ввода-вывода было выполнено на этом процентиле. В конечном итоге вы достигнете точки, когда больше не имеет смысла серьезно относиться к значениям задержки. В этом случае можно увидеть, что значения задержки остаются постоянными после "4-девятки". На этом этапе значение задержки основано только на одной операции ввода-вывода из 234408 операций.

Полезная информация

Теперь, когда вы начали использовать DISKSPD, необходимо учесть несколько моментов, чтобы получить реальные результаты тестов. К ним относятся пристальное внимание к заданным параметрам, работоспособности и переменным дискового пространства, владению CSV, а также различиям между DISKSPD и копированием файлов.

СРАВНЕНИЕ DISKSPD и реального мира

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

Подготовка

Перед запуском теста DISKSPD рекомендуется выполнить несколько действий. К ним относятся проверка работоспособности дискового пространства, проверка использования ресурсов, чтобы другая программа не мешала тесту, и подготовка диспетчера производительности для сбора дополнительных данных. Однако, поскольку цель этого раздела — быстро запустить DISKSPD, в нем не подробно описаны особенности этих действий. Дополнительные сведения см. в статье Тестирование производительности дисковые пространства с помощью искусственных рабочих нагрузок в Windows Server.

Переменные, влияющие на производительность

Производительность хранилища — это деликатная вещь. Это означает, что существует множество переменных, которые могут повлиять на производительность. Поэтому, скорее всего, вы столкнетесь с числом, которое не соответствует вашим ожиданиям. Ниже перечислены некоторые переменные, влияющие на производительность, хотя это и не полный список:

Пропускная способность сети
Выбор устойчивости
Конфигурация диска хранилища: NVME, SSD, HDD
Буфер ввода-вывода
Кэш
Конфигурация RAID
Сетевые прыжки
Скорость шпинделя жесткого диска

Владение CSV-файлом

Узел называется владельцем тома или узлом-координатором (узел без координатора будет узлом, не владеющим определенным томом). Каждому стандартному тому назначается узел, и другие узлы могут обращаться к этому стандартному тому через сетевые прыжки, что приводит к снижению производительности (более высокая задержка).

Аналогичным образом, общий том кластера (CSV) также имеет "владельца". Однако CSV-файл является "динамическим" в том смысле, что он будет прыгать и менять владельца при каждом перезапуске системы (RDP). Поэтому важно убедиться, что DISKSPD выполняется с узла-координатора, которому принадлежит CSV-файл. В противном случае может потребоваться вручную изменить владельца CSV- файла.

Чтобы подтвердить владение CSV, выполните приведенные далее действия.

Проверьте владение, выполнив следующую команду PowerShell:
```
 Get-ClusterSharedVolume
```
Если владение CSV неправильным (например, вы находитесь на Node1, но Node2 владеет CSV), переместите CSV-файл на правильный узел, выполнив следующую команду PowerShell:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Копирование файлов и DISKSPD

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

Если ваша реальная цель заключается в тестировании производительности копирования файлов, это может быть вполне веской причиной для использования этого метода. Однако если ваша цель заключается в измерении производительности хранилища, мы не рекомендуем использовать этот метод. Процесс копирования файлов можно рассматривать как использование другого набора "параметров" (например, очереди, параллелизации и т. д.), характерных для файловых служб.

В следующей краткой сводке объясняется, почему использование копирования файлов для измерения производительности хранилища может не предоставить нужные результаты:

Возможно, копии файлов не оптимизированы. Существует два уровня параллелизма: внутренний и внешний. Если копия файла направляется к удаленному целевому объекту, подсистема CopyFileEx применяет некоторую параллелизацию. С внешней стороны существуют различные способы вызова обработчика CopyFileEx. Например, копии из проводник являются однопоточными, а Robocopy — многопоточными. По этим причинам важно понимать, являются ли последствия теста тем, что вы ищете.
Каждая копия имеет две стороны. При простом копировании и вставки файла могут использоваться два диска: исходный и целевой. Если один из них медленнее другого, вы, по сути, измеряете производительность более медленного диска. Существуют и другие случаи, когда обмен данными между источником, назначением и подсистемой копирования может уникальным образом повлиять на производительность.

Дополнительные сведения см. в статье Использование копирования файлов для измерения производительности хранилища.

Эксперименты и распространенные рабочие нагрузки

Этот раздел содержит несколько других примеров, экспериментов и типов рабочих нагрузок.

Подтверждение узла-координатора

Как упоминалось ранее, если тестируемая виртуальная машина не владеет CSV-файлом, вы увидите снижение производительности (операции ввода-вывода в секунду, пропускная способность и задержка), а не тестирование, когда узел владеет CSV. Это связано с тем, что каждый раз при выполнении операции ввода-вывода система выполняет сетевой прыжок к узлу-координатору для выполнения этой операции.

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

Вот пример:

Выполняется на локальном узле: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Выполняется на нелокальном узле: .\DiskSpd-2.0.21a\amd64\diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

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

Рабочая нагрузка "Обработка транзакций по сети" (OLTP)

Запросы рабочей нагрузки оперативной обработки транзакций (OLTP) (Обновление, вставка, удаление) ориентированы на задачи, ориентированные на транзакции. По сравнению с оперативной аналитической обработкой (OLAP), OLTP зависит от задержки хранилища. Так как каждая операция выполняет мало операций ввода-вывода, вас интересует, сколько операций в секунду можно поддерживать.

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

Базовый вариант проектирования для этого теста рабочей нагрузки должен включать как минимум:

Размер блока 8 КБ => напоминает размер страницы, который SQL Server использует для файлов данных.
70 % чтение, 30 % запись => напоминает типичное поведение OLTP

Рабочая нагрузка OLAP

Рабочие нагрузки OLAP сосредоточены на извлечении и анализе данных, позволяя пользователям выполнять сложные запросы для извлечения многомерных данных. В отличие от OLTP, эти рабочие нагрузки не чувствительны к задержке хранилища. Они подчеркивают постановку в очередь большого количества операций, не заботясь о пропускной способности. В результате рабочие нагрузки OLAP часто приводят к большему времени обработки.

Вы можете разработать тест рабочей нагрузки OLAP, чтобы сосредоточиться на последовательной высокой производительности операций ввода-вывода. Для этих тестов основное внимание уделяется объему обрабатываемых данных в секунду, а не количеству операций ввода-вывода в секунду. Требования к задержке также менее важны, но это является субъективным.