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

Artigo
02/26/2024

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

Este tópico fornece orientações sobre como utilizar DISKSPD para testar o desempenho do armazenamento de cargas 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, saberá como executar DISKSPD, compreender um subconjunto de parâmetros, interpretar a saída e obter uma compreensão geral das variáveis que afetam o desempenho do armazenamento de cargas de trabalho.

O que é DISKSPD?

DISKSPD é uma ferramenta de linha de comandos geradora de E/S para micro-benchmarking. Ótimo, então o que significam todos estes termos? Qualquer pessoa que configure um cluster ou servidor físico do Azure Stack HCI tem um motivo. Pode ser configurar um ambiente de alojamento Web ou executar ambientes de trabalho virtuais para funcionários. Seja qual for o caso de utilização do mundo real, é provável que pretenda simular um teste antes de implementar a sua aplicação real. No entanto, testar a sua aplicação num cenário real é muitas vezes difícil– é aqui que entra DISKSPD.

DISKSPD é uma ferramenta que pode personalizar para criar as suas próprias cargas de trabalho sintéticas e testar a sua aplicação antes da implementação. O melhor da ferramenta é que lhe 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. DISKSPD pode dar-lhe um vislumbre do que o seu sistema é capaz antes da implementação. Na sua essência, DISKSPD simplesmente emite várias operações de leitura e escrita.

Agora sabe o que é DISKSPD, mas quando deve utilizá-lo? DISKSPD tem dificuldade em emular cargas de trabalho complexas. Mas DISKSPD é ótimo quando a carga de trabalho não é aproximadamente aproximada por uma cópia de ficheiro de thread único e precisa de uma ferramenta simples que produz resultados de linha de base aceitáveis.

Início rápido: instalar e executar DISKSPD

Sem mais demoras, vamos começar:

A partir do PC de gestão, abra o PowerShell como administrador para ligar ao computador de destino que pretende testar com DISKSPD e, em seguida, escreva o seguinte comando e prima Enter.
```
Enter-PSSession -ComputerName <TARGET_COMPUTER_NAME>
```
Neste exemplo, estamos a executar uma máquina virtual (VM) chamada "node1".

Para transferir a ferramenta DISKSPD, escreva os seguintes comandos e prima Enter:

$client = new-object System.Net.WebClient

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

Utilize o seguinte comando para deszipar o ficheiro transferido:

Expand-Archive -LiteralPath <ENTERPATH>\DiskSpd-2.1.zip -DestinationPath C:\DISKSPD

Altere o diretório para o diretório DISKSPD e localize o ficheiro executável adequado para o sistema operativo Windows que o computador de destino está a executar.

Neste exemplo, estamos a utilizar a versão amd64.

Nota

Também pode transferir a ferramenta DISKSPD diretamente a partir do repositório do GitHub que contém o código open source e uma página wiki que detalha todos os parâmetros e especificações. No repositório, em Versões, selecione a ligação para transferir automaticamente o ficheiro ZIP.

No ficheiro ZIP, verá três subpastas: amd64 (sistemas de 64 bits), x86 (sistemas de 32 bits) e ARM64 (sistemas ARM). Estas opções permitem-lhe executar a ferramenta em todas as versões de cliente ou servidor do Windows.
Execute DISKSPD com o seguinte comando do PowerShell. Substitua tudo dentro dos parênteses retos, incluindo os próprios parênteses pelas suas definições adequadas.
```
 .\[INSERT_DISKSPD_PATH] [INSERT_SET_OF_PARAMETERS] [INSERT_CSV_PATH_FOR_TEST_FILE] > [INSERT_OUTPUT_FILE.txt]
```
Eis um comando de exemplo que pode executar:
```
 .\diskspd -t2 -o32 -b4k -r4k -w0 -d120 -Sh -D -L -c5G C:\ClusterStorage\test01\targetfile\IO.dat > test01.txt
```
Nota

Se não tiver um ficheiro de teste, utilize o parâmetro -c para criar um. Se utilizar este parâmetro, certifique-se de que inclui o nome do ficheiro de teste quando definir o seu caminho. Por exemplo: [INSERT_CSV_PATH_FOR_TEST_FILE] = C:\ClusterStorage\CSV01\IO.dat. No comando de exemplo, IO.dat é o nome do ficheiro de teste e test01.txt é o nome do ficheiro de saída DISKSPD.

Especificar parâmetros-chave

Bem, foi simples, certo? Infelizmente, há mais do que isso. Vamos descompactar o que fizemos. Em primeiro lugar, existem vários parâmetros com os quais pode trabalhar e este pode ser específico. No entanto, utilizámos o seguinte conjunto de parâmetros de linha de base:

Nota

Os parâmetros DISKSPD são sensíveis às maiúsculas e minúsculas.

-t2: indica o número de threads por ficheiro de destino/teste. Este número baseia-se frequentemente no número de núcleos de CPU. Neste caso, foram utilizados dois threads para realçar todos os núcleos da CPU.

-o32: indica o número de pedidos de E/S pendentes por destino por thread. Isto também é conhecido como a profundidade da fila e, neste caso, foram utilizados 32 para realçar a CPU.

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

-r4K: isto indica a E/S aleatória alinhada com o tamanho especificado em bytes, KiB, MiB, Gib ou blocos (substitui o parâmetro -s ). O tamanho de byte 4K comum foi utilizado para se 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 escritas para efeitos de um teste simples.

-d120: especifica a duração do teste, não incluindo o arrefecimento ou o aquecimento. O valor predefinido é de 10 segundos, mas recomendamos que utilize, pelo menos, 60 segundos para qualquer carga de trabalho grave. Neste caso, foram utilizados 120 segundos para minimizar os valores atípicos.

-Suw: desativa a colocação em cache de escrita de software e hardware (equivalente a -Sh).

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

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

-c5g: define o tamanho do ficheiro de exemplo utilizado 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 dos parâmetros, veja o repositório do GitHub.

Compreender o ambiente

O desempenho depende muito do seu ambiente. Então, qual é o nosso ambiente? A nossa especificação envolve um cluster do Azure Stack HCI com agrupamento de armazenamento e Espaços de Armazenamento Direto (S2D). Mais especificamente, existem cinco VMs: DC, nó1, nó2, nó3 e o nó de gestão. O cluster em si é um cluster de três nós com uma estrutura de resiliência espelhada de três vias. Por conseguinte, são mantidas três cópias de dados. Cada "nó" no cluster é uma VM Standard_B2ms com um limite máximo de IOPS de 1920. Em cada nó, existem quatro unidades SSD P30 premium com um limite máximo de IOPS de 5000. Por fim, cada unidade SSD tem 1 TB de memória.

Irá gerar o ficheiro de teste no espaço de nomes unificado que o Volume Partilhado de Cluster (CSV) fornece (C:\ClusteredStorage) para utilizar todo o conjunto de unidades.

Nota

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

Como verá, é totalmente possível atingir de forma independente o limite de IOPS ou largura de banda na VM ou no limite de unidades. Por isso, é importante compreender o tamanho e o tipo de unidade da VM, porque ambos têm um limite máximo de IOPS e um limite de largura de banda. Este conhecimento ajuda a localizar estrangulamentos e a compreender os resultados de desempenho. Para saber mais sobre que tamanho pode ser adequado para a carga de trabalho, veja os seguintes recursos:

Compreender a saída

Munido da sua compreensão dos parâmetros e do ambiente, está pronto para interpretar a saída. Primeiro, o objetivo do teste anterior era atingir o limite máximo de IOPS sem ter em conta a latência. Desta forma, pode ver visualmente se atinge o limite de IOPS artificial no Azure. Se quiser visualizar graficamente o total de IOPS, utilize o Windows Admin Center ou o Gestor de Tarefas.

O diagrama seguinte mostra o aspeto do processo DISKSPD no nosso ambiente de exemplo. Mostra um exemplo de uma operação de escrita de 1 MiB a partir de um nó não coordenador. A estrutura de resiliência tridirecional, juntamente com a operação de um nó não coordenador, leva a dois saltos de rede, diminuindo o desempenho. Se quer saber o que é um nó de coordenador, não se preocupe! Irá saber mais sobre o mesmo na secção Coisas a considerar . Os quadrados vermelhos representam a VM e os estrangulamentos de unidade.

Agora que já tem uma compreensão visual, vamos examinar as quatro secções principais da saída do ficheiro .txt:

Definições de entrada

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

Esta secção realça 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, existem dois núcleos de CPU que têm uma média de cerca de 4,67% de utilização.
E/S total

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

Neste exemplo, 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 o débito foi de 7,63 MiB/s. A partir de informações anteriores, sabemos que o IOPS 1953.30 está próximo da limitação de IOPS de 1920 para a nossa VM Standard_B2ms. Não acredita? Se voltar a executar este teste com parâmetros diferentes, como aumentar a profundidade da fila, verá que os resultados ainda estão limitados a este 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 ficheiro.

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

No final, tem de decidir que valores são aceitáveis para a sua carga de trabalho específica. A figura seguinte mostra algumas relações importantes para o ajudar a considerar as desvantagens:

A segunda relação na figura é importante, e às vezes é referida como Little's Law. A lei introduz a ideia de que existem três características que regem o comportamento do processo e que só precisa de alterar uma para influenciar as outras duas e, portanto, todo o processo. Por isso, se não estiver satisfeito com o desempenho do seu sistema, terá três dimensões de liberdade para o influenciar. A Lei de Little dita que, no nosso exemplo, IOPS é o "débito" (operações de saída de entrada por segundo), a latência é o "tempo da fila" e a profundidade da fila é o "inventário".
Análise do percentil de latência

Esta última secçã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" do seu IOPS. Revela quantas operações de E/S conseguiram obter um determinado valor de latência. Cabe-lhe a si decidir a latência aceitável para esse percentil.

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

Aspetos a considerar

Agora que começou a utilizar DISKSPD, existem vários aspetos a considerar para obter resultados de testes do mundo real. Estes incluem prestar muita atenção aos parâmetros que definiu, ao estado de funcionamento e às variáveis do espaço de armazenamento, à propriedade CSV e à diferença entre DISKSPD e cópia de ficheiros.

DISKSPD vs. real-world

O teste artificial do DISKSPD dá-lhe resultados relativamente comparáveis para a carga de trabalho real. No entanto, tem de prestar muita atenção aos parâmetros que definiu e se correspondem ao seu cenário real. É importante compreender que as cargas de trabalho sintéticas nunca representarão perfeitamente a carga de trabalho real da sua aplicação durante a implementação.

Preparação

Antes de executar um teste DISKSPD, existem algumas ações recomendadas. Estes incluem verificar o estado de funcionamento do espaço de armazenamento, verificar a utilização de recursos para que outro programa não interfira com o teste e preparar o gestor de desempenho se quiser recolher dados adicionais. No entanto, uma vez que o objetivo deste tópico é colocar rapidamente DISKSPD em execução, não aborda as especificidades destas ações. Para saber mais, veja Test Espaços de Armazenamento Performance Using Synthetic Workloads in Windows Server (Testar o Desempenho Espaços de Armazenamento Com Cargas de Trabalho Sintéticas no Windows Server).

Variáveis que afetam o desempenho

O desempenho do armazenamento é uma coisa delicada. Ou seja, existem muitas variáveis que podem afetar o desempenho. E assim, é provável que encontre um número inconsistente com as suas expectativas. O seguinte realça 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
Saltos de rede
Velocidades do eixo do disco rígido

Propriedade 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). A cada volume padrão é atribuído um nó e os outros nós podem aceder a este volume padrão através de saltos de rede, o que resulta num desempenho mais lento (latência superior).

Da mesma forma, um Volume Partilhado de Cluster (CSV) também tem um "proprietário". No entanto, um CSV é "dinâmico" no sentido em que irá saltar e alterar a propriedade sempre que reiniciar o sistema (RDP). Como resultado, é importante confirmar que DISKSPD é executado a partir do nó coordenador que detém o CSV. Caso contrário, poderá ter de alterar manualmente a propriedade do CSV.

Para confirmar a propriedade do CSV:

Verifique a propriedade ao executar o seguinte comando do PowerShell:
```
 Get-ClusterSharedVolume
```
Se a propriedade do CSV estiver incorreta (por exemplo, se estiver no Node1, mas o Node2 for proprietário do CSV), mova o CSV para o nó correto ao executar o seguinte comando do PowerShell:
```
 Get-ClusterSharedVolume <INSERT_CSV_NAME> | Move-ClusterSharedVolume <INSERT _NODE_NAME>
```

Cópia de ficheiro vs. DISKSPD

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

Se o seu objetivo real for testar o desempenho da cópia de ficheiros, esta pode ser uma razão perfeitamente válida para utilizar este método. No entanto, se o seu objetivo for medir o desempenho do armazenamento, recomendamos que não utilize este método. Pode considerar o processo de cópia de ficheiros como utilizando um conjunto diferente de "parâmetros" (como fila, paralelização, etc.) que é específico dos serviços de ficheiros.

O resumo breve seguinte explica por que motivo a utilização da cópia de ficheiros para medir o desempenho do armazenamento pode não fornecer os resultados que procura:

As cópias de ficheiros podem não estar otimizadas, Existem dois níveis de paralelismo que ocorrem, um interno e outro externo. Internamente, se a cópia do ficheiro for destinada a um destino remoto, o motor CopyFileEx aplica alguma paralelização. Externamente, existem diferentes formas de invocar o motor CopyFileEx. Por exemplo, as cópias de Explorador de Ficheiros são de thread único, mas o Robocopy tem vários threads. Por estas razões, é importante compreender se as implicações do teste são as que procura.
Cada cópia tem dois lados. Quando simplesmente copia e cola um ficheiro, pode estar a utilizar dois discos: o disco de origem e o disco de destino. Se um for mais lento do que o outro, mede essencialmente o desempenho do disco mais lento. Existem outros casos em que a comunicação entre a origem, o destino e o motor de cópia pode afetar o desempenho de formas exclusivas.

Para saber mais, veja Utilizar a cópia de ficheiros para medir o desempenho do armazenamento.

Experimentações e cargas de trabalho comuns

Esta secção inclui outros exemplos, experimentações e tipos de carga de trabalho.

Confirmar o nó de coordenação

Conforme mencionado anteriormente, se a VM que está atualmente a testar não for proprietária do CSV, verá uma queda de desempenho (IOPS, débito e latência) em vez de testá-la quando o nó detém o CSV. Isto acontece porque sempre que emite uma operação de E/S, o sistema efetua um salto de rede para o nó coordenador para executar essa operação.

Para uma situação espelhada tridirecional de três nós, as operações de escrita fazem sempre um salto de rede, porque precisam de armazenar dados em todas as unidades nos três nós. Por conseguinte, as operações de escrita fazem um salto de rede, independentemente disso. No entanto, se utilizar uma estrutura de resiliência diferente, isto pode mudar.

Segue-se um exemplo:

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

Neste exemplo, pode ver claramente nos resultados da figura seguinte que a latência diminuiu, o IOPS aumentou e o débito aumentou quando o nó coordenador é proprietário do CSV.

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

As consultas de carga de trabalho do Processamento Transacional Online (OLTP) (Atualizar, Inserir, Eliminar) concentram-se em tarefas orientadas para transações. Em comparação com o Processamento Analítico Online (OLAP), o OLTP depende da latência de armazenamento. Uma vez que cada operação emite pouca E/S, o que lhe interessa é o número de operações por segundo que pode suportar.

Pode criar um teste de carga de trabalho OLTP para se concentrar no desempenho de E/S aleatório e pequeno. Para estes testes, concentre-se na distância em que pode emitir o débito e manter latências aceitáveis.

A opção de conceção básica para este teste de carga de trabalho deve, no mínimo, incluir:

Tamanho do bloco de 8 KB => assemelha-se ao tamanho da página que SQL Server utiliza para os respetivos ficheiros de dados
70% de Leitura, 30% de Escrita => assemelha-se a comportamento OLTP típico

Carga de trabalho de Processamento Analítico Online (OLAP)

As cargas de trabalho OLAP focam-se na obtenção e análise de dados, permitindo que os utilizadores realizem consultas complexas para extrair dados multidimensionais. Ao contrário do OLTP, estas cargas de trabalho não são sensíveis à latência de armazenamento. Enfatizam a colocação em fila de muitas operações sem se preocuparem muito com a largura de banda. Como resultado, as cargas de trabalho OLAP resultam frequentemente em tempos de processamento mais longos.

Pode criar um teste de carga de trabalho OLAP para se concentrar no desempenho de E/S sequencial e grande. Para estes 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 isto é subjetivo.