Cada nó de storage NetApp AFX fornece uma quantidade específica de throughput para leituras e gravações. À medida que nós são adicionados ao cluster, eles aumentam linearmente esse desempenho, conforme abordado na seção "Escalamento linear do desempenho do nó" deste documento.

Atualmente, os tipos de nós são "AFX 1K" e fornecem taxas de transferência para leitura e gravação aproximadamente nos valores abaixo. À medida que novos hardwares forem disponibilizados para NetApp AFX, esses limites poderão ser alterados. NOTA: O desempenho máximo foi alcançado utilizando vários clientes lendo e gravando vários arquivos, conforme mostrado na seção "Resultados do benchmark" abaixo.

Estimativas de desempenho por nó

Cada prateleira contém módulos de prateleira de alto desempenho com 16 portas Ethernet de 100 GB que utilizam a comunicação RoCEv2 para interação de storage de alta largura de banda com os nós de computação no cluster. Como qualquer recurso físico, essas prateleiras têm máximos que podem ser alcançados – principalmente porque NetApp AFX pode apresentar vários nós apontando para o mesmo conjunto de discos. A tabela a seguir mostra o desempenho máximo estimado de leitura e gravação para uma única prateleira para unidades TLC e QLC. Para obter mais informações sobre as diferenças entre TLC e QLC, consulte "TLC vs. QLC".

Estimativas de desempenho por prateleira

Desacoplar os nós de storage dos shelves na arquitetura ONTAP desagregada permite que mais nós direcionem o tráfego para menos shelves, o que ajuda a reduzir a área total do datacenter necessária para obter o máximo desempenho com apenas a capacidade de que você precisa.

Esse conceito de "densidade de desempenho" permite que os administradores de storage aproveitem ao máximo o hardware disponível, sem precisar superdimensionar o ambiente de storage.

Por exemplo, em um cluster ONTAP unificado, como cada nó possui seu próprio conjunto de discos, o desempenho é direcionado apenas aos discos pertencentes ao nó e, como apenas um nó pode acessar um conjunto de discos, ele não pode necessariamente saturar os discos disponíveis e atingir seu desempenho máximo.

Unified ONTAP – Como o desempenho é distribuído

NetApp AFX agrupa todos os discos em uma única Storage Availability Zone, permitindo que todos os nós utilizem todos os discos. E como os discos e os nós são independentes, você não precisará de tantas shelves para obter o mesmo desempenho. Isso condensa o desempenho e maximiza o potencial máximo de desempenho da shelf.

NetApp AFX – densidade de desempenho

Os nós Unified ONTAP exigem pelo menos um conjunto de discos por nó e podem ter várias gavetas conectadas a um único nó. Consequentemente, podem ocorrer gargalos de desempenho no nó individual, que pode não ser capaz de saturar seus próprios discos.

NetApp AFX apresenta todos os gabinetes de discos a todos os nós. Cada gabinete contém módulos com 16 x 100GB interfaces compatíveis com RoCE para aumentar a quantidade total de desempenho permitida por gabinete. Devido a isso, você pode saturar um único gabinete com vários nós que estarão lendo e gravando no mesmo conjunto de discos.

A partir do ONTAP 9.19.1, a proporção de saturação nó:prateleira é de aproximadamente 4:1.

A seção a seguir aborda os resultados de benchmark usando um cluster AFX NetApp com os seguintes parâmetros de configuração.

A configuração acima atingiu um valor muito próximo do máximo de leituras disponível para o cluster de 4 nós (~134GB/s) e ficou exatamente no limite máximo de gravações permitidas por nó (40GB/s).

NetApp AFX – ElBencho desempenho de leitura, 4 nós

NetApp AFX – ElBencho desempenho de gravação, 4 nós

Em fluxos de trabalho de streaming de mídia, um filme 4K é frequentemente dividido em dezenas de milhares de arquivos, cada um com tamanho típico entre 50 MB e 250 MB. Cada arquivo representa um quadro, e o aplicativo lê um quadro inteiro em uma única solicitação. Para manter um fluxo contínuo e sem interrupções, sem buffering visível, essas leituras de quadros devem ser concluídas sem perdas.

ONTAP oferece uma opção em nível de volume (-aggressive-readahead-mode para otimizar essas cargas de trabalho. A partir do ONTAP 9.19.1, um novo cross_file_sequential_read modo para leitura antecipada agressiva foi introduzido no AFX para acelerar cargas de trabalho com padrões de E/S previsíveis em tipos de arquivo semelhantes (por exemplo, renderização e streaming de mídia).

A função cross_file_sequential_read prevê o próximo arquivo a ser lido com base em seu nome e inicia a leitura antecipada desses arquivos antes que o cliente emita a chamada de leitura. A lógica de previsão pressupõe que todos os arquivos em um diretório seguem um padrão de nomenclatura com um sufixo numérico crescente (por exemplo, arquivo1, arquivo2, arquivo3). Todos os arquivos no diretório devem seguir esse padrão, usando numeração decimal ou hexadecimal. Os nomes de arquivo podem ter até 255 caracteres. A lógica é independente da extensão e gera o próximo conjunto de nomes de arquivo no diretório atual com base apenas no nome do arquivo atual. Se um nome de arquivo gerado anteriormente usando numeração em base 10 não existir no diretório, os nomes são regenerados usando numeração hexadecimal. Se nenhum dos nomes de arquivo gerados existir, nenhuma pré-busca é emitida para esse conjunto. A pré-busca é retomada quando a próxima leitura do cliente é emitida.

Com essas opções ativadas, "teste de quadro" benchmarks de desempenho conseguiram ler 30.000 quadros 4K a 30 quadros por segundo com 30 clientes (NFSv3 e SMB3) e 34 clientes (NFSv4.1), sem nenhuma perda de quadro.

Embora a leitura sequencial entre arquivos seja projetada principalmente para cargas de trabalho de mídia, outras cargas de trabalho com grande volume de leitura e padrões de acesso e nomes de arquivos previsíveis - como treinamento e inferência de IA - também podem se beneficiar.

A versão de NFS 3 tem sido um padrão de excelência para aplicações NFS por décadas – desde 1995, quando foi oficialmente lançada. Sua combinação de desempenho e resiliência tornou difícil considerar a migração para versões mais recentes de NFS, e com razão.

No entanto, o NFSv3 não está isento de limitações. A ausência de estado no protocolo, embora excelente para o desempenho e para minimizar interrupções em caso de failover de storage, não é tão boa para consistência de dados e gerenciamento de bloqueios. Um servidor NFS não mantém um registro dos estados de bloqueio, então, se ocorrer uma falha, o servidor NFS pode ou não liberar os bloqueios, e o cliente NFS pode não saber se um arquivo está bloqueado ou não.