Partilhar via

Benchmarks de desempenho de volume regulares do Azure NetApp Files para Linux

  • Artigo

Este artigo descreve os benchmarks de desempenho que o Azure NetApp Files oferece para Linux com um volume regular.

Cargas de trabalho de streaming de arquivos inteiros (testes de benchmark de expansão)

A intenção de um teste de expansão é mostrar o desempenho de um volume de Arquivo NetApp do Azure ao dimensionar (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 empurrar um volume para o limite 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 trabalho.

Configuração de benchmark de expansão de E/OP alta

Estes parâmetros de referência utilizaram o seguinte:

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

Configuração de benchmark de expansão de alto rendimento

Estes parâmetros de referência utilizaram o seguinte:

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

Configuração de benchmark de conexão de rede paralela (nconnect)

Estes parâmetros de referência utilizaram o seguinte:

  • Um único volume regular dos Arquivos NetApp do Azure com um conjunto de dados de 1 TiB usando a camada 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 benchmark de scale-up

A intenção do teste de expansão é mostrar o desempenho de um volume de Arquivo NetApp do Azure ao dimensionar (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 nconnecto , essas cargas de trabalho não podem ultrapassar os limites do desempenho máximo de um volume, uma vez que o cliente não pode gerar E/S ou taxa de transferência de rede suficiente. Esses testes geralmente são indicativos de como a experiência de um único usuário pode ser em cargas de trabalho como renderização de mídia, bancos de dados, IA/ML e compartilhamentos de arquivos em geral.

Benchmarks de expansão de E/OP elevados

Os benchmarks a seguir mostram o desempenho alcançado para os Arquivos NetApp do Azure com uma alta carga de trabalho de E/S usando:

  • 32 clientes
  • 4-KiB e 8-KiB leituras e gravações aleatórias
  • Conjunto de dados de 1 TiB
  • Rácios de leitura/escrita da seguinte forma: 100%:0%, 90%:10%, 80%:20% e assim por diante
  • Com e sem cache do sistema de arquivos envolvido (usando randrepeat=0 em FIO)

Para obter mais informações, consulte Metodologia de teste.

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

Neste benchmark, o FIO funcionou sem a randrepeat opção de randomizar dados. Assim, uma quantidade indeterminada de cache entrou em jogo. Essa configuração resulta em números de desempenho geral ligeiramente melhores do que os testes executados sem cache com toda a pilha de E/S sendo utilizada.

No gráfico a seguir, o teste mostra que um volume regular do Azure NetApp Files pode lidar com aproximadamente 130.000 gravações aleatórias puras de 4 KiB e aproximadamente 460.000 leituras aleatórias puras de 4 KiB durante esse benchmark. Combinação de leitura-gravação para a carga de trabalho ajustada em 10% para cada execução.

À medida que a combinação de E/P de leitura-gravação aumenta para gravação pesada, o total de E/OPS diminui.

Diagrama de testes de benchmark com 4 KiB, aleatório, cache de cliente incluído.

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

Neste benchmark, o FIO foi executado com a configuração randrepeat=0 de randomizar dados, reduzindo a influência do cache no desempenho. Isso resultou em uma redução de aproximadamente 8% nas E/S de gravação e uma redução de aproximadamente 17% nas E/S de leitura, mas exibe números de desempenho mais representativos do que o armazenamento pode realmente fazer.

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

À medida que a combinação de E/P de leitura-gravação aumenta para gravação pesada, o total de E/OPS diminui.

Diagrama de testes de benchmark com 4 KiB, aleatório, cache de cliente excluído.

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

Tamanhos maiores de leitura e gravação resultarão em menos E/S 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 as aplicações mais modernas usam. Por exemplo, muitos aplicativos EDA utilizam leituras e gravações de 8 KiB.

Neste benchmark, o FIO executou para randomizar dados para randrepeat=0 que o impacto do cache do cliente fosse reduzido. No gráfico a seguir, o teste mostra que um volume regular do Azure NetApp Files pode lidar com aproximadamente 111.000 gravações aleatórias puras de 8 KiB e aproximadamente 293.000 leituras aleatórias puras de 8 KiB. Combinação leitura-gravação para a carga de trabalho ajustada em 25% para cada execução.

À medida que a combinação de E/P de leitura-gravação aumenta para gravação pesada, o total de E/OPS diminui.

Diagrama de testes de benchmark com 8 KiB, aleatório, cache de cliente excluído.

Comparações lado a lado

Para ilustrar como o cache pode influenciar os testes de benchmark de desempenho, o gráfico a seguir mostra o total de E/S para testes de 4 KiB com e sem mecanismos de cache em vigor. Como mostrado, o cache fornece um ligeiro aumento de desempenho para tendências de I/OPS bastante consistentes.

Diagrama comparando testes de referência de 4 KiB.

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

Os testes a seguir mostram um alto benchmark de E/OP 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 cliente único, a nconnect opção de montagem foi usada para melhorar o paralelismo em comparação com montagens de cliente sem a nconnect opção de montagem.

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 nconnecto , a latência total para as operações é geralmente menor. Esses testes também são executados para randrepeat=0 evitar intencionalmente o armazenamento em cache. Para obter mais informações sobre essa opção, consulte Metodologia de teste.

Resultados: 4 KiB, aleatórios, com e sem nconnect, caching 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 destacar as melhorias de desempenho observadas ao usar nconnect: maior E/S geral, menor latência.

Diagrama de desempenho de leitura de 4 KiB.

Diagrama de desempenho de escrita de 4-KiB.

Benchmarks de alto rendimento

Os benchmarks a seguir mostram o desempenho alcançado para os Arquivos NetApp do Azure com uma carga de trabalho de alta taxa de transferência.

As cargas de trabalho de alta taxa de transferência são mais sequenciais por natureza e geralmente são pesadas em leitura/gravação com poucos metadados. A taxa de transferência é geralmente mais importante do que a I/OPS. Essas cargas de trabalho normalmente aproveitam tamanhos maiores de leitura/gravação (64K a 256K), que geram latências mais altas do que tamanhos menores de leitura/gravação, já que cargas úteis 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 elevado desempenho
  • AI/ML/LLP

Os testes a seguir mostram uma referência 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 gerada diminui uma porcentagem definida de cada vez e demonstra o que você pode esperar ao usar taxas de leitura/gravação variáveis (por exemplo, 100%:0%, 90%:10%, 80%:20% e assim por diante).

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

Nesse benchmark, o FIO era executado usando a lógica de looping que preenchia o cache de forma mais agressiva, de modo que uma quantidade indeterminada de cache influenciava os resultados. Isso resulta em números de desempenho geral 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 com aproximadamente 4.500 MiB/s de leituras sequenciais puras de 64 KiB e aproximadamente 1.600 MiB/s de gravações sequenciais puras de 64 KiB. A combinação leitura-gravação para a carga de trabalho foi ajustada em 10% para cada execução.

Diagrama de testes de benchmark de 64 KiB com E/S sequencial e cache incluídos.

Resultados: E/S sequencial de 64 KiB, leituras vs. gravação, linha de base sem cache

Neste benchmark de linha de base, o teste demonstra que um volume regular do Azure NetApp Files pode lidar com aproximadamente 3.600 MiB/s de leituras sequenciais puras de 64 KiB e aproximadamente 2.400 MiB/segundo de gravações sequenciais puras de 64 KiB. Durante os testes, uma mistura de 50/50 mostrou uma taxa de transferência total equivalente a uma carga de trabalho de leitura sequencial pura.

Com relação à leitura pura, a linha de base de 64 KiB teve um desempenho ligeiramente melhor do que a linha de base de 256 KiB. Quando se trata de gravação pura e todas as cargas de trabalho mistas de leitura/gravação, no entanto, a linha de base de 256 KiB superou 64 KiB, indicando que um tamanho de bloco maior de 256 KiB é mais eficaz em geral para cargas de trabalho de alta taxa de transferência.

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

Diagrama de testes de benchmark de 64 KiB com E/S sequencial, cache excluído.

Resultados: E/S sequenciais de 256 KiB sem cache

Nos dois benchmarks de linha de base a seguir, o FIO foi usado para medir a quantidade de E/S sequencial (leitura e gravação) que um único volume regular nos Arquivos NetApp do Azure pode fornecer. Para produzir uma linha de base que reflita a verdadeira largura de banda que uma carga de trabalho de leitura totalmente sem cache pode alcançar, o FIO foi configurado para ser executado com o parâmetro randrepeat=0 para geração de conjunto de dados. Cada iteração de teste foi compensada pela leitura de um conjunto de dados grande completamente separado que não faz parte do benchmark para limpar qualquer cache que possa ter ocorrido com o conjunto de dados de benchmark.

Neste gráfico, o teste mostra que um volume regular dos Arquivos NetApp do Azure pode lidar com aproximadamente 3.500 leituras sequenciais puras de 256 KiB e aproximadamente 2.500 MiB/s de gravações sequenciais puras de 256 KiB. Durante os testes, uma mistura de 50/50 mostrou um pico de rendimento total maior do que uma carga de trabalho de leitura sequencial pura.

Diagrama de testes de referência sequenciais de 256 KiB.

Conexões de rede paralelas (nconnect)

Os testes a seguir mostram um benchmark de E/P 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 uma carga de trabalho de cliente único, a opção de montagem foi aproveitada nconnect para um melhor paralelismo em comparação com montagens de cliente que não usavam a nconnect opção de montagem. Esses testes foram executados apenas com cache excluído.

Resultados: E/S sequencial de 64 KiB, comparação de cache de taxa de transferência de leitura

Para demonstrar como o cache influencia os resultados de desempenho, o FIO foi usado na seguinte comparação de micro benchmark para medir a quantidade de E/S sequencial (leitura e gravação) que um único volume regular nos Arquivos NetApp do Azure pode fornecer. Esse teste contrasta com os benefícios que uma carga de trabalho parcialmente armazenável em cache pode proporcionar.

No resultado sem cache, o teste foi projetado para mitigar qualquer cache que ocorra conforme descrito nos benchmarks de linha de base acima. No outro resultado, o FIO foi usado em volumes regulares do Azure NetApp Files sem o randrepeat=0 parâmetro e usando uma lógica de iteração de teste de looping que preencheu lentamente o cache ao longo do tempo. A combinação desses fatores produziu uma quantidade indeterminada de cache, aumentando a taxa de transferência geral. Essa configuração resultou em números de desempenho de leitura geral ligeiramente melhores do que os testes executados sem cache.

Os resultados do teste exibidos no gráfico exibem a comparação lado a lado do desempenho de leitura com e sem a influência do cache, onde o cache produziu até ~4500 MiB/segundo de taxa de transferência de leitura, enquanto nenhum cache atingiu cerca de ~3600 MiB/segundo.

Diagrama de comparação de taxas de transferência de leituras sequenciais de 64 KiB com base em cache.

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 destacar as melhorias de desempenho observadas ao usar nconnect: maior taxa de transferência geral, menor latência.

Diagrama de comparação de leituras e gravações sequenciais de 64 KiB.

Mais informações