Utilizar o DISKSPD para testar o desempenho do armazenamento da carga de trabalho

Artigo
11/23/2024

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

Importante

O Azure Stack HCI agora faz parte do Azure Local. A renomeação da documentação do produto está em andamento. No entanto, as versões mais antigas do Azure Stack HCI, por exemplo 22H2, continuarão a fazer referência ao Azure Stack HCI e não refletirão a alteração de nome. Mais informações.

Este tópico fornece orientação sobre como usar o DISKSPD para testar o desempenho do armazenamento de carga de trabalho. Tem um cluster do Azure Stack HCI, tem tudo pronto. Ótimo, mas como sabe se está a obter as métricas de desempenho prometidas, seja ao nível da latência, débito ou IOPS? É aqui que deve recorrer ao 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?

DISKSPD é uma ferramenta de linha de comando geradora de E/S para microbenchmarking. Ótimo, então o que significam todos esses termos? Qualquer pessoa que configure um cluster HCI do Azure Stack ou um servidor físico 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 – é aqui que o DISKSPD entra.

O 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 dá a você a liberdade de configurar e ajustar os parâmetros para criar um cenário específico que se assemelha à sua carga de trabalho real. O DISKSPD pode fornecer um vislumbre do que seu sistema é capaz de fazer antes da implantação. Em sua essência, o DISKSPD simplesmente emite um monte de operações de leitura e gravação.

Agora você já sabe o que é DISKSPD, mas quando você 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 seu PC de gestão e, em seguida, siga estes passos:

Para baixar e expandir o arquivo ZIP para a 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 à variável $PATH 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 comando de exemplo que você pode executar:
```
diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Nota

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 ficar específico. No entanto, foi utilizado o seguinte conjunto de parâmetros basais:

Nota

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

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

-o32: Isso 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 estressar a CPU.

-b4K: indica o tamanho do bloco em bytes, KiB, MiB ou GiB. Neste caso, o tamanho do bloco 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 4K byte foi usado para alinhar corretamente com o tamanho do bloco.

-w0: Especifica a percentagem de operações que são pedidos de escrita (-w0 é equivalente a 100% de leitura). Neste caso, foram utilizadas 0% de escrita para efeitos de um teste simples.

-d120: Especifica a duração do ensaio, não incluindo arrefecimento ou aquecimento. O valor padrão é 10 segundos, mas recomendamos o uso de pelo menos 60 segundos para qualquer carga de trabalho séria. Neste caso, foram utilizados 120 segundos para minimizar eventuais valores anómalos.

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

-D: Captura estatísticas 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. Pode ser definido em bytes, KiB, MiB, GiB ou blocos. Neste caso, foi utilizado um ficheiro de destino de 5 GB.

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

Compreender o ambiente

O desempenho depende muito do seu ambiente. Então, qual é o nosso ambiente? Nossa especificação envolve um cluster HCI do Azure Stack com pool de armazenamento e Storage Spaces Direct (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. Dentro de cada nó, existem 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 sob o namespace unificado que o Volume Compartilhado do Cluster (CSV) fornece (C:\ClusteredStorage) para usar todo o pool de unidades.

Nota

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

Como você verá, é totalmente possível atingir de forma independente o IOPS ou o limite de largura de banda no limite da VM ou da unidade. Por isso, é 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 o tamanho apropriado para sua carga de trabalho, consulte os seguintes recursos:

Compreenda 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 quiser visualizar graficamente o total de IOPS, use o Windows Admin Center ou o 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 da unidade.

Agora que você já entendeu visualmente, 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. Neste caso, há dois núcleos de CPU que tiveram em média cerca de 4,67% de uso.
E/S totais

Esta secção tem três subsecções. A primeira seção destaca os dados gerais de desempenho, incluindo operações de leitura e gravação. A segunda e 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. De informações anteriores, sabemos que as IOPS de 1953,30 estão próximas 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, descobrirá que os resultados ainda estão limitados a esse número.

As três últimas colunas mostram o desvio padrão da 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 estivesse limitado pela SSD em vez da VM, poderia ter tirado partido de até 20000 IOPS (4 unidades * 5000) abrangendo o ficheiro 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 alguns relacionamentos importantes para ajudá-lo a considerar as compensações:

A segunda relação na figura é importante, e às vezes é referida como Lei de Little. A lei introduz a ideia de que existem três características que regem 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 percentis de latência

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

Esta secção é importante porque determina a "qualidade" das suas 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 "nove" referem-se ao número de nove. Por exemplo, "3-nove" é equivalente ao percentil 99. 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 os valores de latência a sério. Nesse caso, você pode ver que os valores de latência permanecem constantes após "4-nove". Neste ponto, o valor de latência é baseado em apenas uma operação de E/S fora das operações de 234408.

Aspectos a considerar

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

DISKSPD vs. mundo real

O teste artificial do DISKSPD oferece 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 seu 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 mergulha 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 do armazenamento é algo delicado. 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, destacamos algumas das variáveis que afetam o desempenho, embora não seja uma lista abrangente:

Largura de banda de rede
Escolha de resiliência
Configuração do disco de armazenamento: NVME, SSD, HDD
Memória intermédia de E/S
Cache
Configuração RAID
Lúpulos de rede
Velocidades do eixo do disco rígido

Propriedade do CSV

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

Da mesma forma, um Volume Compartilhado de Cluster (CSV) também tem um "proprietário". No entanto, um CSV é "dinâmico" no sentido de que ele irá pular e mudar de propriedade toda vez que você reiniciar o sistema (RDP). Como resultado, é importante confirmar se o DISKSPD é executado a partir do 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 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 é 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 "testar o desempenho do armazenamento".

Se o seu objetivo no mundo real é testar o desempenho da cópia de arquivo, então essa pode ser uma razão perfeitamente válida para usar esse método. No entanto, se o seu objetivo 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 usar a 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 estiver 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 é multi-threaded. Por estas razões, é importante entender se as implicações do teste são o que você está procurando.
Cada cópia tem dois lados. Quando você copia e cola um arquivo, você pode estar usando dois discos: o disco de origem e o disco de destino. Se um é mais lento do que o outro, você essencialmente mede 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 cópia de arquivo para medir o desempenho do armazenamento.

Experiências e cargas de trabalho comuns

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

Confirmando o nó coordenador

Como mencionado anteriormente, se a VM que você está testando atualmente 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, as operações de gravação sempre fazem um salto de rede porque precisa armazenar dados em todas as unidades nos três nós. Portanto, as operações de gravação fazem um salto de rede independentemente disso. No entanto, se você usar uma estrutura de resiliência diferente, isso pode mudar.

Eis um exemplo:

Em execução 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

Neste 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 (Online Transaction Processing)

As consultas de carga de trabalho OLTP (Atualizar, Inserir, Excluir) concentram-se em tarefas orientadas a transações. Em comparação com o OLAP (Online Analytical Processing), 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 projetar um teste de carga de trabalho OLTP para se concentrar no desempenho de E/S aleatório e pequeno. Para esses testes, concentre-se em até onde você pode empurrar a taxa de transferência, mantendo latências aceitáveis.

A escolha de design básico 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% Leitura, 30% Gravação => assemelha-se ao comportamento OLTP típico

Carga de trabalho OLAP (Online Analytical Processing)

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 a fila 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 projetar 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 em vez do número de IOPS. Os requisitos de latência também são menos importantes, mas isso é subjetivo.