Os servidores de dados são clusters do ONTAP especialmente construídos para o Novus. Eles implementam o plano de dados do Novus, armazenam dados de arquivos e os disponibilizam para os clientes NFS. Um namespace do Novus pode distribuir seus dados de arquivos por vários clusters do ONTAP; um cluster pode atender a muitos namespaces diferentes. Essa flexibilidade permite que a capacidade e o desempenho cresçam com a adição de servidores de dados conforme necessário.

Os clientes acessam os servidores de dados ONTAP usando um cliente NFS padrão, sem necessidade de software personalizado da NetApp. Depois que um cliente obtém um layout de arquivo do Novus Data Director, ele pode ler e gravar dados de arquivo diretamente nos servidores de dados ONTAP por NFSv3 e, opcionalmente, por RDMA. Os dados em massa nunca passam pelo Novus Data Director, portanto o tráfego de dados segue em paralelo entre os servidores de dados.

Os servidores de dados não participam do gerenciamento do namespace. Eles armazenam os dados de cada arquivo como arquivos de suporte em volumes do ONTAP. Um servidor de dados do ONTAP não mantém os metadados do namespace do Novus, como a árvore de diretórios ou como os arquivos são distribuídos entre os servidores de dados.

O AFF A90 para NetApp Novus é uma versão do AFF A90 desenvolvida para o Novus executando ONTAP. Suas características incluem:

Os clusters padrão do ONTAP não podem ser usados como servidores de dados Novus; somente plataformas criadas especificamente para Novus são suportadas.

O Novus Data Director (NDD) é uma implementação da função de servidor de metadados (MDS) na arquitetura pNFS e fornece o plano de metadados do Novus. Um host MDS é um servidor físico que executa Linux, além dos serviços de protocolo MDS e dos repositórios de metadados.

O NDD apresenta cada namespace aos clientes como um único sistema de arquivos. Ele é proprietário dos metadados do namespace: arquivos e diretórios, atributos de arquivo, o mapa de onde os dados de cada arquivo estão armazenados e o estado do protocolo necessário para coordenar o acesso do cliente. Os clientes montam um namespace por meio de seu endereço IP virtual e se comunicam com o NDD usando NFSv4.2 com parallel NFS (pNFS). O NDD gerencia todas as operações de metadados, como pesquisas, criação de arquivos e alterações de atributos. Quando um cliente abre um arquivo, o NDD fornece a ele um layout Flexible File do pNFS, que informa ao cliente quais servidores de dados armazenam os dados do arquivo. O cliente pode então realizar suas leituras e gravações diretamente com os servidores de dados do ONTAP; o NDD está no caminho de metadados, mas não no caminho de dados.

O NDD é implementado como um software que roda em um cluster de pelo menos três servidores dedicados. Ele combina os processos do servidor de metadados com um banco de dados replicado e distribuído que armazena os metadados do namespace em storage local criptografado. Cada namespace executa seus próprios processos do servidor de metadados em vários desses servidores. Todos os servidores íntegros anunciam o endereço IP virtual do namespace, o que distribui a carga do cliente e permite que os clientes façam failover sem remontar. Como os metadados autoritativos ficam no banco de dados replicado, um servidor pode falhar e reiniciar sem perder o estado do namespace.

O posicionamento dos dados nos clusters ONTAP é controlado pelo NDD. Ele mantém um registro dos servidores de dados, garante que cada servidor de dados esteja disponível usando sondagens NFS leves e monitora a capacidade livre em cada um. Quando um arquivo é criado, o NDD escolhe os servidores de dados, cria os arquivos de suporte por NFS e registra seus locais. Se um servidor de dados ficar indisponível, o NDD para de colocar novos dados nele e revoga os layouts de cliente que apontam para ele.

A figura a seguir ilustra uma implementação típica do Novus em alto nível. Os aspectos notáveis incluem um único namespace com vários Novus Data Directors e nós de servidor de dados do ONTAP. Essa arquitetura proporciona alta disponibilidade e baixa latência para dar suporte aos servidores GPU de backend.