Azure NetApp Files benchmarks de desempenho de grande volume para Linux
Este artigo descreve os recursos de desempenho testados de um único volume grande do Azure NetApp Files no que diz respeito a casos de uso do Linux. Os testes exploraram cenários para cargas de trabalho de leitura e gravação em expansão e expansão, envolvendo uma e várias máquinas virtuais (VMs). Conhecer o envelope de desempenho de grandes volumes ajuda a facilitar o dimensionamento de volumes.
Resumo dos testes
O recurso de grandes volumes do Azure NetApp Files oferece três níveis de serviço, cada um com limites de taxa de transferência. Os níveis de serviço podem ser aumentados ou reduzidos sem interrupções à medida que o desempenho precisa mudar.
- Nível de serviço ultra: 12.800 MiB/s
- Nível de serviço premium: 6.400 MiB/s
- Nível de serviço padrão: 1.600 MiB/s
O nível de serviço Ultra foi usado nesses testes.
Gravações sequenciais: gravações 100% sequenciais atingiram o máximo de ~8.500 MiB/segundo nesses benchmarks. (A taxa de transferência máxima de um único volume grande é limitada a 12.800 MiB/segundo pelo serviço, portanto, mais taxa de transferência potencial é possível.)
Leituras sequenciais: leituras 100% sequenciais atingiram o máximo de ~12.761 MiB/segundo nestes benchmarks. (A taxa de transferência de um único volume grande é limitada a 12.800 MiB/segundo. Esse resultado está próximo da taxa de transferência máxima alcançável no momento.)
E/S aleatórias: O mesmo grande volume fornece mais de 700.000 operações por segundo.
Cargas de trabalho pesadas de metadados são vantajosas para grandes volumes do Arquivo NetApp do Azure devido ao maior paralelismo do grande volume. Os benefícios de desempenho são percetíveis em cargas de trabalho pesadas na criação, desvinculação e renomeação de arquivos, como típico em aplicativos VCS e cargas de trabalho EDA onde há altas contagens de arquivos presentes. Para obter mais informações sobre o desempenho de cargas de trabalho de metadados altos, consulte Benefícios do uso de arquivos NetApp do Azure para automação de projeto eletrônico.
FIO, um gerador de carga de trabalho sintético projetado como um teste de estresse de armazenamento, foi usado para conduzir esses resultados de teste. Existem fundamentalmente dois modelos de teste de desempenho de armazenamento:
- Computação em expansão, que se refere ao uso de várias VMs para gerar a carga máxima possível em um único volume de Arquivos NetApp do Azure.
- Computação de expansão, que se refere ao uso de uma VM grande para testar os limites superiores de um único cliente em um único volume de Arquivos NetApp do Azure.
Teste de expansão do Linux
Os testes observaram limiares de desempenho de um único grande volume no scale-out e foram conduzidos com a seguinte configuração:
Componente | Configuração |
---|---|
Tamanho da VM do Azure | E32s_v5 |
Limite de largura de banda de saída da VM do Azure | 2000MiB/s (2GiB/s) |
Sistema operativo | RHEL 8,4 |
Tamanho de grande volume | 101 TiB Ultra (taxa de transferência de 12.800 MiB/s) |
Opções de montagem | hard,rsize=65536,wsize=65536,vers=3 NOTA: O uso do 262144 e do 65536 teve resultados de desempenho semelhantes. |
Cargas de trabalho sequenciais de 256 KiB (MiB/s)
O gráfico representa uma carga de trabalho sequencial de 256 KiB usando 12 máquinas virtuais lendo e gravando em um único grande volume usando um conjunto de trabalho de 1 TiB. O gráfico mostra que um único volume grande de Arquivos NetApp do Azure pode lidar com aproximadamente 8.518 MiB/s gravações sequenciais puras e 12.761 MiB/s leituras sequenciais puras.
Carga de trabalho aleatória (IOPS) de 8 KiB
O gráfico representa uma carga de trabalho aleatória de 8 KiB e um conjunto de trabalho de 1 TiB. O gráfico mostra que um grande volume de Arquivos NetApp do Azure pode lidar com aproximadamente 474.000 gravações aleatórias puras e aproximadamente 709.000 leituras aleatórias puras.
Testes de scale-up do Linux
Enquanto os testes de expansão são projetados para encontrar os limites de um único grande volume, os testes de expansão são projetados para encontrar os limites superiores de uma única instância em relação a esse grande volume. O Azure coloca limites de saída de rede em suas VMs; para armazenamento conectado à rede, isso significa que a largura de banda de gravação é limitada por VM. Esses testes de expansão demonstram recursos dado o grande limite de largura de banda disponível e com processadores suficientes para impulsionar essa carga de trabalho.
Os testes nesta seção foram executados com a seguinte configuração:
Componente | Configuração |
---|---|
Tamanho da VM do Azure | E104id_v5 |
Limite de largura de banda de saída da VM do Azure | 12.500MiB/s (12,2GiB/s) |
Sistema operativo | RHEL 8,4 |
Tamanho de grande volume | 101 TiB Ultra (taxa de transferência de 12.800 MiB/s) |
Opções de montagem | hard,rsize=65536,wsize=65536,vers=3 NOTA: A utilização do 262144 e do 65536 teve resultados de desempenho semelhantes |
Os gráficos nesta seção mostram os resultados para a opção de montagem do lado do cliente de nconnect
com NFSv3. Para obter mais informações, consulte Práticas recomendadas de opções de montagem do Linux NFS para o Arquivo NetApp do Azure.
Os gráficos a seguir comparam as vantagens de nconnect
com um volume montado em NFS sem nconnect
. Nos testes, o FIO gerou a carga de trabalho de uma única instância E104id-v5 na região do Azure Leste dos EUA usando uma carga de trabalho sequencial de 64 KiB; um tamanho de 256 I/0 foi usado, que é o maior tamanho de E/S recomendado pelos Arquivos NetApp do Azure, resultando em números de desempenho comparáveis. Para obter mais informações, consulte rsize
e wsize
.
Taxa de transferência de leitura do Linux
Os gráficos a seguir mostram leituras sequenciais de 256 KiB de aproximadamente 10.000 M iB/s com nconnect
, o que é aproximadamente dez vezes a taxa de transferência alcançada sem nconnect
.
Observe que 10.000 MiB/s é aproximadamente a taxa de linha da placa de interface de rede de 100 Gbps conectada ao E104id_v5.
Taxa de transferência de gravação do Linux
Os gráficos a seguir mostram gravações sequenciais. O uso nconnect
fornece benefícios observáveis para gravações sequenciais a 6.600 MiB/s, aproximadamente quatro vezes mais do que montagens sem nconnect
.
IOPS de leitura do Linux
Os gráficos a seguir mostram leituras aleatórias de 8 KiB de ~426.000 IOPS lidas com nconnect
, aproximadamente sete vezes o que é observado sem nconnect
.
IOPS de gravação Linux
Os gráficos a seguir mostram gravações aleatórias de 8 KiB de ~405.000 IOPS de gravação com nconnect
, aproximadamente 7,2 vezes o que é observado sem nconnect
.