Usar o DISKSPD para testar o desempenho de armazenamento da carga de trabalho

Artigo
10/31/2024

Aplica-se a: Azure Stack HCI, versões 22H2 e 21H2; Windows Server 2022, Windows Server 2019

Este tópico fornece diretrizes sobre como usar o DISKSPD para testar o desempenho do armazenamento de carga de trabalho. Você tem uma configuração de cluster do Azure Stack HCI, tudo pronto para uso. Ótimo, mas como você sabe se está obtendo as métricas de desempenho prometidas, se é latência, taxa de transferência ou IOPS? Isso ocorre quando você quer voltar para o DISKSPD. Depois de ler este tópico, você saberá como executar o DISKSPD, entender um subconjunto de parâmetros, interpretar a saída e obter uma compreensão geral das variáveis que afetam o desempenho do armazenamento da carga de trabalho.

O que é DISKSPD?

O DISKSPD é uma ferramenta de linha de comando geradora de E/S para microbenchmarking. Ótimo, então o que todos esses termos significam? Qualquer pessoa que configure um cluster ou servidor físico do Azure Stack HCI tem um motivo. Pode ser para configurar um ambiente de hospedagem na web ou executar desktops virtuais para funcionários. Seja qual for o caso de uso do mundo real, você provavelmente deseja simular um teste antes de implantar seu aplicativo real. No entanto, testar seu aplicativo em um cenário real geralmente é difícil – é aí que entra o DISKSPD.

DISKSPD é uma ferramenta que você pode personalizar para criar suas próprias cargas de trabalho sintéticas e testar seu aplicativo antes da implantação. O legal da ferramenta é que ela te dá a liberdade de configurar e ajustar os parâmetros para criar um cenário específico que se assemelhe à sua carga de trabalho real. O DISKSPD pode fornecer uma ideia do que seu sistema é capaz antes da implantação. Em sua essência, o DISKSPD simplesmente emite várias operações de leitura e gravação.

Agora você sabe o que é DISKSPD, mas quando deve usá-lo? O DISKSPD tem dificuldade em emular cargas de trabalho complexas. Mas o DISKSPD é ótimo quando sua carga de trabalho não é aproximada por uma cópia de arquivo de thread único e você precisa de uma ferramenta simples que produza resultados de linha de base aceitáveis.

Início rápido: instalar e executar o DISKSPD

Para instalar e executar o DISKSPD, abra o PowerShell como administrador no computador de gerenciamento e siga estas etapas:

Para baixar e expandir o arquivo ZIP da ferramenta DISKSPD, execute os seguintes comandos:

# 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

Para adicionar o diretório DISKSPD à sua $PATH variável de ambiente, execute o seguinte comando:

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

Execute DISKSPD com o seguinte comando do PowerShell. Substitua os colchetes pelas configurações apropriadas.
```
diskspd [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Aqui está um exemplo de comando que você pode executar:
```
diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Observação

Se você não tiver um arquivo de teste, use o parâmetro -c para criar um. Se você usar esse parâmetro, certifique-se de incluir o nome do arquivo de teste ao definir seu caminho. Por exemplo: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. No comando de exemplo, IO.dat é o nome do arquivo de teste e test01.txt é o nome do arquivo de saída DISKSPD.

Especificar parâmetros-chave

Bem, isso foi simples, certo? Infelizmente, há mais do que isso. Vamos descompactar o que fizemos. Primeiro, existem vários parâmetros que você pode mexer e pode ser específico. No entanto, usamos o seguinte conjunto de parâmetros de linha de base:

Observação

Os parâmetros DISKSPD diferenciam maiúsculas de minúsculas.

-t2: indica o número de threads por arquivo de destino/teste. Esse número geralmente é baseado no número de núcleos da CPU. Nesse caso, dois threads foram usados para tensionar todos os núcleos da CPU.

-o32: indica o número de solicitações de E/S pendentes por destino por thread. Isso também é conhecido como profundidade da fila e, neste caso, 32 foram usados para sobrecarregar a CPU.

-b4K: Indica o tamanho do bloco em bytes, KiB, MiB ou GiB. Nesse caso, o tamanho do bloco de 4K foi usado para simular um teste de E/S aleatório.

-r4K: Indica a E/S aleatória alinhada ao tamanho especificado em bytes, KiB, MiB, Gib ou blocos (Substitui o parâmetro -s ). O tamanho comum de bytes de 4K foi usado para alinhar corretamente com o tamanho do bloco.

-w0: especifica a porcentagem de operações que são solicitações de gravação (-w0 é equivalente a 100% de leitura). Nesse caso, 0% de gravações foram usadas para fins de um teste simples.

-d120: Especifica a duração do teste, sem incluir resfriamento ou aquecimento. O valor padrão é 10 segundos, mas recomendamos usar pelo menos 60 segundos para qualquer carga de trabalho séria. Nesse caso, 120 segundos foram usados para minimizar quaisquer valores discrepantes.

-Suw: Desativa o cache de gravação de software e hardware (equivalente a -Sh).

-D: captura estatísticas de IOPS, como desvio padrão, em intervalos de milissegundos (por thread, por destino).

-L: Mede estatísticas de latência.

-c5g: Define o tamanho do arquivo de amostra usado no teste. Ele pode ser definido em bytes, KiB, MiB, GiB ou blocos. Nesse caso, foi utilizado um arquivo de destino de 5 GB.

Para obter uma lista completa de parâmetros, consulte o repositório GitHub.

Entenda o ambiente

O desempenho depende muito do seu ambiente. Então, qual é o nosso ambiente? Nossa especificação envolve um cluster do Azure Stack HCI com pool de armazenamento e Espaços de Armazenamento Diretos (S2D). Mais especificamente, há cinco VMs: DC, node1, node2, node3 e o nó de gerenciamento. O cluster em si é um cluster de três nós com uma estrutura de resiliência espelhada de três vias. Portanto, três cópias de dados são mantidas. Cada "nó" no cluster é uma VM Standard_B2ms com um limite máximo de IOPS de 1920. Em cada nó, há quatro unidades SSD P30 premium com um limite máximo de IOPS de 5000. Finalmente, cada unidade SSD tem 1 TB de memória.

Você gera o arquivo de teste no namespace unificado que o CSV (Volume Compartilhado Clusterizado) fornece (C:\ClusteredStorage) para usar todo o pool de unidades.

Observação

O ambiente de exemplo não tem Hyper-V ou uma estrutura de virtualização aninhada.

Como você verá, é totalmente possível atingir independentemente o teto de IOPS ou largura de banda no limite de VM ou unidade. Portanto, é importante entender o tamanho da VM e o tipo de unidade, pois ambos têm um limite máximo de IOPS e um teto de largura de banda. Esse conhecimento ajuda a localizar gargalos e entender seus resultados de desempenho. Para saber mais sobre qual tamanho pode ser apropriado para sua carga de trabalho, consulte os seguintes recursos:

Como entender a saída

Armado com sua compreensão dos parâmetros e do ambiente, você está pronto para interpretar a saída. Primeiro, o objetivo do teste anterior era maximizar o IOPS sem levar em conta a latência. Dessa forma, você pode ver visualmente se atinge o limite de IOPS artificial no Azure. Se você quiser visualizar graficamente o total de IOPS, use Windows Admin Center ou Gerenciador de Tarefas.

O diagrama a seguir mostra a aparência do processo DISKSPD em nosso ambiente de exemplo. Ele mostra um exemplo de uma operação de gravação de 1 MiB de um nó não coordenador. A estrutura de resiliência de três vias, juntamente com a operação de um nó não coordenador, leva a dois saltos de rede, diminuindo o desempenho. Se você está se perguntando o que é um nó coordenador, não se preocupe! Você aprenderá sobre isso na seção Coisas a considerar . Os quadrados vermelhos representam a VM e os gargalos de unidade.

Agora que você tem uma compreensão visual, vamos examinar as quatro seções principais da saída do arquivo .txt:

Configurações de entrada

Esta seção descreve o comando executado, os parâmetros de entrada e detalhes adicionais sobre a execução do teste.
Detalhes de utilização da CPU

Esta seção destaca informações como o tempo de teste, o número de threads, o número de processadores disponíveis e a utilização média de cada núcleo de CPU durante o teste. Nesse caso, existem dois núcleos de CPU com média de uso de cerca de 4,67%.
E/S total

Esta seção tem três subseções. A primeira seção destaca os dados gerais de desempenho, incluindo operações de leitura e gravação. A segunda e a terceira seções dividem as operações de leitura e gravação em categorias separadas.

Neste exemplo, você pode ver que a contagem total de E/S foi 234408 durante a duração de 120 segundos. Assim, IOPS = 234408 /120 = 1953,30. A latência média foi de 32,763 milissegundos e a taxa de transferência foi de 7,63 MiB/s. Com base em informações anteriores, sabemos que o IOPS de 1953,30 está próximo da limitação de IOPS de 1920 para nossa VM Standard_B2ms. Não acredita? Se você executar novamente esse teste usando parâmetros diferentes, como aumentar a profundidade da fila, verá que os resultados ainda estão limitados a esse número.

As últimas três colunas mostram o desvio padrão de IOPS em 17,72 (do parâmetro -D), o desvio padrão da latência em 20,994 milissegundos (do parâmetro -L) e o caminho do arquivo.

A partir dos resultados, você pode determinar rapidamente que a configuração do cluster é terrível. Você pode ver que ele atingiu a limitação de VM de 1920 antes da limitação de SSD de 5000. Se você estivesse limitado pelo SSD em vez da VM, poderia ter aproveitado até 20000 IOPS (4 unidades * 5000) abrangendo o arquivo de teste em várias unidades.

No final, você precisa decidir quais valores são aceitáveis para sua carga de trabalho específica. A figura a seguir mostra algumas relações importantes para ajudá-lo a considerar as compensações:

A segunda relação na figura é importante e às vezes é chamada de Lei de Little. A lei introduz a ideia de que existem três características que governam o comportamento do processo e que você só precisa mudar uma para influenciar as outras duas e, portanto, todo o processo. E assim, se você está insatisfeito com o desempenho do seu sistema, você tem três dimensões de liberdade para influenciá-lo. A Lei de Little determina que, em nosso exemplo, IOPS é a "taxa de transferência" (operações de entrada e saída por segundo), latência é o "tempo de fila" e profundidade da fila é o "inventário".
Análise de percentil de latência

Esta última seção detalha as latências percentuais por tipo de operação de desempenho de armazenamento, do valor mínimo ao valor máximo.

Esta seção é importante porque determina a "qualidade" do seu IOPS. Ele revela quantas das operações de E/S foram capazes de atingir um determinado valor de latência. Cabe a você decidir a latência aceitável para esse percentil.

Além disso, os "noves" referem-se ao número de noves. Por exemplo, "3-noves" é equivalente ao 99º percentil. O número de noves expõe quantas operações de E/S foram executadas nesse percentil. Eventualmente, você chegará a um ponto em que não faz mais sentido levar a sério os valores de latência. Nesse caso, você pode ver que os valores de latência permanecem constantes após "4-noves". Neste ponto, o valor de latência é baseado em apenas uma operação de E/S das operações 234408.

Aspectos a considerar

Agora que você começou a usar o DISKSPD, há várias coisas a serem consideradas para obter resultados de teste do mundo real. Isso inclui prestar muita atenção aos parâmetros definidos, integridade e variáveis do espaço de armazenamento, propriedade do CSV e a diferença entre DISKSPD e cópia de arquivo.

DISKSPD vs. mundo real

O teste artificial do DISKSPD fornece resultados relativamente comparáveis para sua carga de trabalho real. No entanto, você precisa prestar muita atenção aos parâmetros definidos e se eles correspondem ao seu cenário real. É importante entender que as cargas de trabalho sintéticas nunca representarão perfeitamente a carga de trabalho real do aplicativo durante a implantação.

Preparação

Antes de executar um teste DISKSPD, há algumas ações recomendadas. Isso inclui verificar a integridade do espaço de armazenamento, verificar o uso de recursos para que outro programa não interfira no teste e preparar o gerenciador de desempenho se você quiser coletar dados adicionais. No entanto, como o objetivo deste tópico é executar rapidamente o DISKSPD, ele não se aprofunda nas especificidades dessas ações. Para saber mais, consulte Testar o desempenho de espaços de armazenamento usando cargas de trabalho sintéticas no Windows Server.

Variáveis que afetam o desempenho

O desempenho de armazenamento é uma coisa delicada. Ou seja, existem muitas variáveis que podem afetar o desempenho. E assim, é provável que você encontre um número inconsistente com suas expectativas. A seguir, destacam-se algumas das variáveis que afetam o desempenho, embora não seja uma lista abrangente:

Largura de banda da rede
Escolha de resiliência
Configuração do disco de armazenamento: NVME, SSD, HDD
Buffer de E/S
Cache
Configuração RAID
Saltos de rede
Velocidades do eixo do disco rígido

Propriedade do CSV

Um nó é conhecido como proprietário do volume ou nó coordenador (um nó não coordenador seria o nó que não possui um volume específico). Cada volume padrão recebe um nó e os outros nós podem acessar esse volume padrão por meio de saltos de rede, o que resulta em desempenho mais lento (maior latência).

Da mesma forma, um CSV (Volume Compartilhado Clusterizado) também tem um "proprietário". No entanto, um CSV é "dinâmico" no sentido de que ele pulará e mudará de propriedade toda vez que você reiniciar o sistema (RDP). Como resultado, é importante confirmar se o DISKSPD é executado no nó coordenador que possui o CSV. Caso contrário, talvez seja necessário alterar manualmente a propriedade do CSV.

Para confirmar a propriedade do CSV:

Verifique a propriedade executando o seguinte comando do PowerShell:
```
 Get-ClusterSharedVolume
```
Se a propriedade do CSV estiver incorreta (por exemplo, você está no Node1, mas o Node2 possui o CSV), mova o CSV para o nó correto executando o seguinte comando do PowerShell:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Cópia de arquivo vs. DISKSPD

Algumas pessoas acreditam que podem "testar o desempenho do armazenamento" copiando e colando um arquivo gigantesco e medindo quanto tempo esse processo leva. A principal razão por trás dessa abordagem é provavelmente porque ela é simples e rápida. A ideia não está errada no sentido de que testa uma carga de trabalho específica, mas é difícil categorizar esse método como "teste de desempenho de armazenamento".

Se o seu objetivo real é testar o desempenho da cópia de arquivo, esse pode ser um motivo perfeitamente válido para usar esse método. No entanto, se sua meta for medir o desempenho do armazenamento, recomendamos não usar esse método. Você pode pensar no processo de cópia de arquivo como usando um conjunto diferente de "parâmetros" (como fila, paralelização e assim por diante) que é específico para serviços de arquivo.

O breve resumo a seguir explica por que o uso da cópia de arquivo para medir o desempenho do armazenamento pode não fornecer os resultados que você está procurando:

As cópias de arquivo podem não ser otimizadas, há dois níveis de paralelismo que ocorrem, um interno e outro externo. Internamente, se a cópia do arquivo for direcionada para um destino remoto, o mecanismo CopyFileEx aplicará alguma paralelização. Externamente, há diferentes maneiras de invocar o mecanismo CopyFileEx. Por exemplo, as cópias do Explorador de Arquivos são de thread único, mas o Robocopy é de vários threads. Por esses motivos, é importante entender se as implicações do teste são o que você está procurando.
Cada cópia tem dois lados. Ao copiar e colar um arquivo, você pode estar usando dois discos: o disco de origem e o disco de destino. Se um for mais lento que o outro, você mede essencialmente o desempenho do disco mais lento. Há outros casos em que a comunicação entre a origem, o destino e o mecanismo de cópia pode afetar o desempenho de maneiras exclusivas.

Para saber mais, consulte Usando a cópia de arquivo para medir o desempenho do armazenamento.

Experimentos e cargas de trabalho comuns

Esta seção inclui alguns outros exemplos, experimentos e tipos de carga de trabalho.

Confirmando o nó coordenador

Conforme mencionado anteriormente, se a VM que você está testando no momento não possuir o CSV, você verá uma queda de desempenho (IOPS, taxa de transferência e latência) em vez de testá-la quando o nó possuir o CSV. Isso ocorre porque toda vez que você emite uma operação de E/S, o sistema faz um salto de rede para o nó coordenador para executar essa operação.

Para uma situação espelhada de três nós e três vias, as operações de gravação sempre fazem um salto de rede porque precisam armazenar dados em todas as unidades nos três nós. Portanto, as operações de gravação fazem um salto de rede independentemente. No entanto, se você usar uma estrutura de resiliência diferente, isso poderá mudar.

Veja um exemplo:

Executando no nó local: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat
Em execução no nó não local: diskspd.exe -t4 -o32 -b4k -r4k -w0 -Sh -D -L C:\ClusterStorage\test01\targetfile\IO.dat

A partir deste exemplo, você pode ver claramente nos resultados da figura a seguir que a latência diminuiu, o IOPS aumentou e a taxa de transferência aumentou quando o nó coordenador possui o CSV.

Carga de trabalho OLTP (Processamento de Transações Online)

As consultas de carga de trabalho OLTP (Processamento Transacional Online) (Atualizar, Inserir, Excluir) concentram-se em tarefas orientadas a transações. Em comparação com o OLAP (Processamento Analítico Online), o OLTP depende da latência de armazenamento. Como cada operação emite pouca E/S, o que importa é quantas operações por segundo você pode sustentar.

Você pode criar um teste de carga de trabalho OLTP para se concentrar no desempenho de E/S pequeno e aleatório. Para esses testes, concentre-se em até onde você pode empurrar a taxa de transferência, mantendo latências aceitáveis.

A escolha básica de design para este teste de carga de trabalho deve incluir, no mínimo:

Tamanho do bloco de 8 KB => semelhante ao tamanho da página que o SQL Server usa para seus arquivos de dados
70% de leitura, 30% de gravação => assemelha-se ao comportamento típico do OLTP

Carga de trabalho OLAP (Processamento Analítico Online)

As cargas de trabalho OLAP se concentram na recuperação e análise de dados, permitindo que os usuários executem consultas complexas para extrair dados multidimensionais. Ao contrário do OLTP, essas cargas de trabalho não são sensíveis à latência de armazenamento. Eles enfatizam o enfileiramento de muitas operações sem se importar muito com a largura de banda. Como resultado, as cargas de trabalho OLAP geralmente resultam em tempos de processamento mais longos.

Você pode criar um teste de carga de trabalho OLAP para se concentrar no desempenho de E/S sequencial e grande. Para esses testes, concentre-se no volume de dados processados por segundo, e não no número de IOPS. Os requisitos de latência também são menos importantes, mas isso é subjetivo.