Parâmetros de comparação de desempenho de volume regular do Azure NetApp Files para Linux

Este artigo descreve os parâmetros de comparação de desempenho fornecidos ao Linux pelo Azure NetApp Files com um volume regular.

Cargas de trabalho inteiras de streaming de arquivos (testes de parâmetro de comparação de expansão)

A intenção de um teste de expansão é mostrar o desempenho de um volume do Azure NetApp Files ao expandir (ou aumentar) o número de clientes que geram carga de trabalho simultânea para o mesmo volume. Esses testes geralmente são capazes de enviar um volume para a borda de seus limites de desempenho e são indicativos de cargas de trabalho, como renderização de mídia, IA/ML e outras cargas de trabalho que utilizam grandes farms de computação para executar o trabalho.

Configuração de parâmetro de comparação de expansão de I/OP alta

Esses parâmetros de comparação usam o seguinte:

• Um único volume regular do Azure NetApp Files 100-TiB com um conjunto de dados de 1 TiB usando o nível de desempenho Ultra
• FIO (com e sem definir randrepeat=0)
• Tamanhos de bloco de 4 KiB e 8 KiB
• 6 máquinas virtuais D32s_v5 que executam o RHEL 9.3
• NFSv3
• QoS manual
• Opções de montagem: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configuração de parâmetro de comparação de expansão de taxa de transferência alta

Esses parâmetros de comparação usam o seguinte:

• Um único volume regular do Azure NetApp Files com um conjunto de dados de 1 TiB usando o nível de desempenho Ultra FIO (com e sem definir randrepeat=0)
• FIO (com e sem definir randrepeat=0)
• Tamanhos de bloco de 64 KiB e 256 KiB
• 6 máquinas virtuais D32s_v5 que executam o RHEL 9.3
• NFSv3
• QoS manual
• Opções de montagem: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Configuração de parâmetro de comparação de conexão de rede paralela (nconnect)

Esses parâmetros de comparação usam o seguinte:

• Um único volume regular do Azure NetApp Files com um conjunto de dados de 1 TiB usando o nível de desempenho Ultra
• FIO (com e sem definir randrepeat=0)
• 4-KiB e 64-KiB wsize/rsize
• Uma única máquina virtual D32s_v4 executando o RHEL 9.3
• NFSv3 com e sem nconnect
• Opções de montagem: rw,nconnect=8,hard,rsize=262144,wsize=262144,vers=3,tcp,bg

Testes de parâmetro de comparação de escala vertical

A intenção do teste de escala vertical é mostrar o desempenho de um volume do Azure NetApp Files ao escalar verticalmente (ou aumentar) o número de trabalhos que geram carga de trabalho simultânea em várias conexões TCP em um único cliente para o mesmo volume (como com nconnect).

Sem nconnect, essas cargas de trabalho não podem efetuar push dos limites de desempenho máximo de um volume, pois o cliente não pode gerar E/S ou taxa de transferência de rede suficiente. Esses testes geralmente são indicativos de qual experiência de um único usuário pode estar em cargas de trabalho, como renderização de mídia, bancos de dados, IA/ML e compartilhamentos gerais de arquivos.

Parâmetros de comparação de expansão de I/OP alta

Os parâmetros de comparação a seguir mostram o desempenho obtido para o Azure NetApp Files com uma carga de trabalho de I/OP alta usando:

• 32 clientes
• Leituras e gravações aleatórias de 4 KiB e 8 KiB
• Conjunto de dados de 1 TiB
• Taxas de leitura/gravação da seguinte maneira: 100%:0%, 90%:10%, 80%:20%, e assim por diante
• Com e sem cache de sistema de arquivos envolvido (usando randrepeat=0 no FIO)

Para obter mais informações, confira Metodologia do teste.

Resultados: 4 KiB, aleatório, cache de cliente incluído

Neste parâmetro de comparação, o FIO foi executado sem a opção randrepeat para colocar os dados em aleatório. Assim, uma quantidade indeterminada de cache entrou em jogo. Essa configuração resulta em números de desempenho gerais ligeiramente melhores do que os testes executados sem o cache com toda a pilha de E/S sendo utilizada.

No gráfico a seguir, os testes mostram que um volume regular do Azure NetApp Files pode lidar entre aproximadamente 130.000 gravações aleatórias puras de 4 KiB e aproximadamente 460.000 leituras aleatórias puras de 4 KiB durante esse parâmetro de comparação. Combinação de leitura/gravação para a carga de trabalho ajustada em 10% para cada execução.

À medida que a combinação de I/OP de leitura/gravação aumenta para gravação pesada, o total de IOPS diminui.

Resultados: 4 KiB, aleatório, cache de cliente excluído

Neste parâmetro de comparação, o FIO foi executado com a configuração randrepeat=0 para colocar os dados em aleatório, reduzindo a influência de cache no desempenho. Isso resultou em uma redução de aproximadamente 8% no IOPS de gravação e uma redução de aproximadamente 17% no IOPS de leitura, mas exibe números de desempenho mais representativos do que o armazenamento pode realmente fazer.

No gráfico a seguir, os testes mostram que um volume regular do Azure NetApp Files pode lidar entre aproximadamente 120.000 gravações aleatórias puras de 4 KiB e aproximadamente 388.000 leituras aleatórias puras de 4 KiB. Combinação de leitura/gravação para a carga de trabalho ajustada em 25% para cada execução.

À medida que a combinação de I/OP de leitura/gravação aumenta para gravação pesada, o total de IOPS diminui.

Resultados: 8 KiB, aleatório, cache de cliente excluído

Tamanhos maiores de leitura e gravação resultarão em menos IOPS totais, pois mais dados podem ser enviados com cada operação. Um tamanho de leitura e gravação de 8 KiB foi usado para simular com mais precisão o que a maioria dos aplicativos modernos usa. Por exemplo, muitos aplicativos EDA utilizam leituras e gravações de 8 KiB.

Nesse parâmetro de comparação, o FIO foi executado com randrepeat=0 para colocar os dados em aleatório para que o impacto do cache do cliente fosse reduzido. No gráfico a seguir, os testes mostram que um volume regular do Azure NetApp Files pode lidar entre aproximadamente 111.000 gravações aleatórias puras de 8 KiB e aproximadamente 293.000 leituras aleatórias puras de 8 KiB. Combinação de leitura/gravação para a carga de trabalho ajustada em 25% para cada execução.

À medida que a combinação de I/OP de leitura/gravação aumenta para gravação pesada, o total de IOPS diminui.

Comparações lado a lado

Para ilustrar como o cache pode influenciar os testes de parâmetro de comparação de desempenho, o gráfico a seguir mostra o total de IOPS para testes de 4 KiB com e sem mecanismos de cache em vigor. Conforme mostrado, o cache fornece um leve aumento de desempenho para tendências de IOPS bastante consistentes.

Deslocamento específico, streaming de cargas de trabalho aleatórias de leitura/gravação: testes de escala vertical usando conexões de rede paralelas (nconnect)

Os testes a seguir mostram um parâmetro de comparação de I/OP alto usando um único cliente com cargas de trabalho aleatórias de 4 KiB e um conjunto de dados de 1 TiB. A combinação de carga de trabalho gerada usa uma profundidade de E/S diferente a cada vez. Para aumentar o desempenho de uma carga de trabalho de um único cliente, a opção de montagem nconnect foi usada para melhorar o paralelismo em comparação com as montagens do cliente sem a opção de montagem nconnect.

Ao usar uma conexão TCP padrão que fornece apenas um único caminho para o armazenamento, menos operações totais são enviadas por segundo do que quando uma montagem é capaz de aproveitar mais conexões TCP (como com nconnect) por ponto de montagem. Ao usar nconnect, a latência total para as operações geralmente é menor. Esses testes também são executados com randrepeat=0 para evitar intencionalmente o cache. Para obter mais informações sobre essa opção, confira Metodologia do teste.

Resultados: 4 KiB, aleatório, com e sem nconnect, cache excluído

Os gráficos a seguir mostram uma comparação lado a lado de leituras e gravações de 4 KiB com e sem nconnect para realçar as melhorias de desempenho vistas ao usar nconnect: IOPS geral mais alta, latência mais baixa.

Parâmetros de comparação de alta taxa de transferência

Os parâmetros de comparação a seguir mostram o desempenho obtido para o Azure NetApp Files com uma carga de trabalho de taxa de transferência alta.

Cargas de trabalho de alta taxa de transferência são mais sequenciais por natureza e geralmente são pesadas de leitura/gravação com poucos metadados. A taxa de transferência geralmente é mais importante do que o IOPS. Essas cargas de trabalho normalmente aproveitam tamanhos maiores de leitura/gravação (64K a 256 K), que geram latências mais altas do que tamanhos menores de leitura/gravação, uma vez que cargas maiores naturalmente levarão mais tempo para serem processadas.

Exemplos de cargas de trabalho de alta taxa de transferência incluem:

• Repositórios de mídia
• Computação de alto desempenho
• IA/ML/LLP

Os testes a seguir mostram um parâmetro de comparação de alta taxa de transferência usando cargas de trabalho sequenciais de 64 KiB e 256 KiB e um conjunto de dados de 1 TiB. A combinação de carga de trabalho gerado diminui um percentual definido de cada vez e demonstra o que você pode esperar ao usar diferentes taxas de leitura/gravação (por exemplo, 100%:0%, 90%:10%, 80%:20%, e assim por diante).

Resultados: E/S sequencial de 64 KiB, cache incluído

Nesse parâmetro de comparação, o FIO foi executado usando a lógica de loop que preencheu o cache de forma mais agressiva, de modo que uma quantidade indeterminada de cache influenciava os resultados. Isso resulta em números de desempenho gerais ligeiramente melhores do que os testes executados sem cache.

No gráfico abaixo, o teste mostra que um volume regular do Azure NetApp Files pode lidar entre aproximadamente 4.500 MiB/s leituras sequenciais puras de 64 KiB e aproximadamente 1.600 MiB/s gravações sequenciais puras de 64 KiB. A combinação de leitura/gravação para a carga de trabalho foi ajustada em 10% para cada execução.

Resultados: E/S sequencial de 64 KiB, cache excluído

Neste parâmetro de comparação, o FIO foi executado usando a lógica de loop que preencheu o cache de forma menos agressiva. O cache do cliente não influenciou os resultados. Essa configuração resulta em números de desempenho de gravação ligeiramente melhores, mas números de leitura mais baixos do que testes sem cache.

No gráfico a seguir, o teste demostra que um volume regular do Azure NetApp Files pode lidar entre aproximadamente 3.600 MiB/s leituras sequenciais puras de 64 KiB e aproximadamente 2.400 MiB/s gravações sequenciais puras de 64 KiB. Durante os testes, uma combinação de 50/50 mostrou a taxa de transferência total no mesmo nível de uma carga de trabalho de leitura sequencial pura.

A combinação de leitura/gravação para a carga de trabalho foi ajustada em 25% para cada execução.

Resultados: E/S sequencial de 256 KiB, cache excluído

Neste parâmetro de comparação, o FIO foi executado usando a lógica de loop que preencheu o cache de forma menos agressiva, então o cache não influenciou os resultados. Essa configuração resulta em números de desempenho de gravação ligeiramente menores do que testes de 64 KiB, mas números de leitura mais altos do que os mesmos testes de 64 KiB executados sem cache.

No gráfico abaixo, o teste mostra que um volume regular do Azure NetApp Files pode lidar entre aproximadamente 3.500 MiB/s leituras sequenciais puras de 256 KiB e aproximadamente 2.500 MiB/s gravações sequenciais puras de 256 KiB. Durante os testes, uma combinação de 50/50 mostrou a taxa de transferência total mais alta do que uma carga de trabalho de leitura sequencial pura.

A combinação de leitura/gravação para a carga de trabalho foi ajustada em incrementos de 25% para cada execução.

Comparação lado a lado

Para demonstrar melhor como o cache pode influenciar os testes de parâmetro de comparação de desempenho, o gráfico a seguir mostra o total de MiB/s para testes de 64 KiB com e sem mecanismos de cache em vigor. O cache fornece um pequeno aumento de desempenho inicial para o total de MiB/s, pois o cache geralmente melhora as leituras mais do que as gravações. À medida que a combinação de leitura/gravação é alterada, a taxa de transferência total sem cache excede os resultados que utilizam o cache do cliente.

Comparar conexões de rede (nconnect)

Os testes a seguir mostram um parâmetro de comparação de I/OP alto usando um único cliente com cargas de trabalho aleatórias de 64 KiB e um conjunto de dados de 1 TiB. A combinação de carga de trabalho gerada usa uma profundidade de E/S diferente a cada vez. Para aumentar o desempenho de carga de trabalho de um único cliente, a opção de montagem nconnect foi usada para melhorar o paralelismo em comparação com as montagens do cliente que não usaram a opção de montagem nconnect. Esses testes foram executados apenas com o cache excluído.

Resultados: 64 KiB, sequencial, cache excluído, com e sem nconnect

Os resultados a seguir mostram os resultados de um teste de escala vertical ao ler e gravar em partes de 4 KiB em uma montagem NFSv3 em um único cliente com e sem paralelização de operações (nconnect). Os gráficos mostram que, à medida que a profundidade de E/S aumenta, o IOPS também aumenta. No entanto, ao usar uma conexão TCP padrão que fornece apenas um único caminho para o armazenamento, menos operações totais são enviadas por segundo do que quando uma montagem é capaz de aproveitar mais conexões TCP por ponto de montagem. Além disso, a latência total para as operações geralmente é menor ao usar nconnect.

Comparação lado a lado (com e sem nconnect)

Os gráficos a seguir mostram uma comparação lado a lado de leituras e gravações sequenciais de 64 KiB com e sem nconnect para realçar as melhorias de desempenho vistas ao usar nconnect: taxa de transferência geral mais alta, latência mais baixa.

Mais informações

• Metodologia de teste