Treinamento
Módulo
Saiba como aprimorar o desempenho do Azure NetApp Files em aplicativos de EDA e HPC usando as melhores práticas.
Não há mais suporte para esse navegador.
Atualize o Microsoft Edge para aproveitar os recursos, o suporte técnico e as atualizações de segurança mais recentes.
Este artigo descreve os parâmetros de comparação de desempenho fornecidos ao Linux pelo Azure NetApp Files com um volume regular.
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.
Esses parâmetros de comparação usam o seguinte:
Esses parâmetros de comparação usam o seguinte:
Esses parâmetros de comparação usam o seguinte:
nconnect
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.
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:
randrepeat=0
no FIO)Para obter mais informações, confira Metodologia do teste.
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.
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.
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.
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.
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.
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.
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:
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).
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.
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.
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.
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.
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.
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
.
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.
Treinamento
Módulo
Saiba como aprimorar o desempenho do Azure NetApp Files em aplicativos de EDA e HPC usando as melhores práticas.