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

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

Important

Azure Stack HCI теперь является частью Azure Local. Однако старые версии Azure Stack HCI, например 22H2, будут продолжать ссылаться на Azure Stack HCI и не отражают изменение имени. Дополнительные сведения.

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

Что такое DISKSPD?

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

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

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

Быстрый старт: установка и запуск DISKSPD

Чтобы установить и запустить DISKSPD, откройте PowerShell в качестве администратора на компьютере управления, а затем выполните следующие действия.

Чтобы скачать и развернуть ZIP-файл для средства DISKSPD, выполните следующие команды:

# Define the ZIP URL and the full path to save the file, including the filename
$zipName = "DiskSpd.zip"
$zipPath = "C:\DISKSPD"
$zipFullName = Join-Path $zipPath $zipName
$zipUrl = "https://github.com/microsoft/diskspd/releases/latest/download/" +$zipName

# Ensure the target directory exists, if not then create
if (-Not (Test-Path $zipPath)) {
New-Item -Path $zipPath -ItemType Directory | Out-Null
}
# Download and expand the ZIP file
Invoke-RestMethod -Uri $zipUrl -OutFile $zipFullName
Expand-Archive -Path $zipFullName -DestinationPath $zipPath

Чтобы добавить каталог DISKSPD в $PATH переменную среды, выполните следующую команду:

$diskspdPath = Join-Path $zipPath $env:PROCESSOR_ARCHITECTURE
if ($env:path -split ';' -notcontains $diskspdPath) {
$env:path += ";" + $diskspdPath
}

Запустите DISKSPD с помощью следующей команды PowerShell. Замените квадратные скобки соответствующими параметрами.
```
diskspd [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
```
Note

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

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

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

Note

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

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

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

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

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

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

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

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

-D: собирает статистику IOPS, например стандартное отклонение, с интервалом в миллисекунды (для каждого потока, для каждого целевого объекта).

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

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

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

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

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

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

Note

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

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

Понять выходные данные

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

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

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

Параметры ввода

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

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

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

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

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

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

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

Вторая связь на рисунке важна, и иногда это называется "Маленький закон". Закон вводит идею о том, что существует три характеристики, которые управляют поведением процесса, и что вам нужно только изменить один, чтобы повлиять на остальные два, и таким образом весь процесс. И поэтому, если вы недовольны производительностью вашей системы, у вас есть три измерения свободы влиять на него. Закон Little определяет, что в нашем примере операции ввода-вывода — это "пропускная способность" (входные выходные операции в секунду), задержка — это "время очереди", а глубина очереди — "инвентаризация".
Анализ процентиля задержки

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

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

Кроме того, «девятки» обозначают количество девяток. Например, «три девятки» соответствует 99-му процентилю. Число девяток показывает, сколько операций ввода-вывода было выполнено на этом уровне процентиля. В конечном итоге вы достигнете точки, где больше не имеет смысла принимать значения задержки серьезно. В этом случае видно, что значения задержки остаются постоянными после уровня «четыре девятки». На этом этапе значение задержки основано только на одной операции ввода-вывода из 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

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

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

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

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

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

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

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

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

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

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

Приведем пример:

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

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

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

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

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

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

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

Рабочая нагрузка по оперативной аналитической обработке (OLAP)

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

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