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, cache excluído

Nesse benchmark, o FIO era executado usando a lógica de looping que preenchia 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 menores do que os testes sem cache.

No gráfico a seguir, 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/s 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.

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 sequencial de 256 KiB, cache excluído

Nesse benchmark, o FIO era executado usando uma lógica de looping que preenchia o cache de forma menos agressiva, de modo que o cache não influenciava os resultados. Essa configuração resulta em números de desempenho de gravação um pouco menores do que os 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 com aproximadamente 3.500 MiB/s de 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.

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

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

Comparação lado a lado

Para mostrar melhor como o cache pode influenciar os testes de benchmark 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 ligeiro aumento inicial de desempenho para o total de MiB/s porque o cache geralmente melhora mais as leituras do que as gravações. À medida que a combinação de leitura/gravação muda, a taxa de transferência total sem cache excede os resultados que utilizam o cache do cliente.

Diagrama comparando testes de 64 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: 64 KiB, sequencial, cache excluído, com e sem nconnect

Os resultados a seguir mostram os resultados de um teste de expansão ao ler e gravar em blocos 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 cresce, a E/S também aumenta. Mas 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 das operações é geralmente menor ao usar nconnecto .

Diagrama comparando testes de 64 KiB sem nconnect ou cache.

Diagrama de testes de 64 KiB com nconnect, mas sem 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