O servidor de metadados no pNFS é estabelecido quando um cliente inicia uma montagem usando NFSv4.1 ou posterior, com o pNFS habilitado no servidor NFS. Quando isso é feito, todo o tráfego de metadados é enviado por meio dessa conexão e permanece nela durante todo o período de montagem, mesmo que a interface seja migrada para outro nó.

O suporte a pNFS é determinado durante a chamada de montagem, especificamente nas chamadas EXCHANGE_ID. Isso pode ser visto em uma captura de pacotes abaixo das operações NFS como um indicador. Quando os sinalizadores pNFS EXCHGID4_FLAG_USE_PNFS_DS e EXCHGID4_FLAG_USE_PNFS_MDS Se o parâmetro estiver definido como 1, a interface estará apta para operações de dados e metadados no pNFS.

Os metadados no NFS geralmente consistem em atributos de arquivos e pastas, como identificadores de arquivos, permissões, horários de acesso e modificação e informações de propriedade. Os metadados também podem incluir a criação e exclusão de chamadas, a vinculação e desvinculação de chamadas e renomeações.

Em pNFS, existe também um subconjunto de chamadas de metadados específicas para o recurso pNFS, que são abordadas com mais detalhes em "RFC 5661". Essas chamadas são usadas para ajudar a determinar dispositivos elegíveis para pNFS, mapeamentos de dispositivos para conjuntos de dados e outras informações necessárias. A tabela a seguir mostra uma lista dessas operações de metadados específicas do pNFS.

Após o servidor de metadados ser estabelecido e as operações de dados começarem, o ONTAP inicia o rastreamento dos IDs de dispositivo elegíveis para operações de leitura e gravação pNFS, bem como os mapeamentos de dispositivo, que associam os volumes no cluster às interfaces de rede locais. Esse processo ocorre quando uma operação de leitura ou gravação é realizada no ponto de montagem. Chamadas de metadados, como GETATTR. não acionará esses mapeamentos de dispositivos. Assim sendo, executar um ls O comando executado dentro do ponto de montagem não atualizará os mapeamentos.

Os dispositivos e mapeamentos podem ser visualizados usando a CLI do ONTAP com privilégios avançados, conforme mostrado abaixo.

Quando um cliente tenta ler ou gravar em um arquivo localizado em um nó remoto em relação à conexão com o servidor de metadados, o pNFS negocia os caminhos de acesso apropriados para garantir a localidade dos dados nessas operações, e o cliente é redirecionado para o dispositivo pNFS anunciado, em vez de tentar percorrer a rede do cluster para acessar o arquivo. Isso ajuda a reduzir a sobrecarga da CPU e a latência da rede.

Além dos metadados e dos dados presentes no pNFS, existe também um caminho de controle do pNFS. O caminho de controle é usado pelo servidor NFS para sincronizar as informações do sistema de arquivos. Em um cluster ONTAP , a rede de backend do cluster replica periodicamente para garantir que todos os dispositivos pNFS e seus mapeamentos estejam sincronizados.

A seguir, descrevemos como um dispositivo pNFS é populado no ONTAP depois que um cliente faz uma solicitação para ler ou gravar um arquivo em um volume.

Os volumes FlexGroup no ONTAP apresentam o armazenamento como componentes de FlexVol volume que abrangem vários nós em um cluster, o que permite que uma carga de trabalho aproveite vários recursos de hardware, mantendo um único ponto de montagem. Como vários nós com múltiplas interfaces de rede interagem com a carga de trabalho, é natural que o tráfego remoto atravesse a rede do cluster de backend no ONTAP.

Ao utilizar o pNFS, o ONTAP rastreia os layouts de arquivo e volume do volume FlexGroup e os mapeia para as interfaces de dados locais no cluster. Por exemplo, se um volume constituinte que contém um arquivo sendo acessado reside no nó 1, o ONTAP notificará o cliente para redirecionar o tráfego de dados para a interface de dados no nó 1.

O pNFS também permite a apresentação de caminhos de rede paralelos para arquivos a partir de um único cliente, algo que o NFSv4.1 sem pNFS não oferece. Por exemplo, se um cliente quiser acessar quatro arquivos simultaneamente a partir do mesmo ponto de montagem usando NFSv4.1 sem pNFS, o mesmo caminho de rede será utilizado para todos os arquivos e o cluster ONTAP enviará solicitações remotas para esses arquivos. O caminho de montagem pode se tornar um gargalo para as operações, já que todas seguem um único caminho e chegam a um único nó, além de também atender operações de metadados juntamente com as operações de dados.

Quando o pNFS é usado para acessar simultaneamente os mesmos quatro arquivos a partir de um único cliente, o cliente e o servidor negociam caminhos locais para cada nó com os arquivos e usam múltiplas conexões TCP para as operações de dados, enquanto o caminho de montagem atua como o local para todas as operações de metadados. Isso proporciona benefícios em termos de latência, utilizando caminhos locais para os arquivos, mas também pode adicionar benefícios de taxa de transferência por meio do uso de múltiplas interfaces de rede, desde que os clientes possam enviar dados suficientes para saturar a rede.

A seguir, são apresentados os resultados de um teste simples executado em um único cliente RHEL 9.5, onde quatro arquivos de 10 GB (todos residentes em volumes constituintes diferentes em dois nós de cluster ONTAP ) são lidos em paralelo usando o comando dd. Para cada arquivo, o rendimento geral e o tempo de conclusão foram melhorados ao usar o pNFS. Ao usar o NFSv4.1 sem pNFS, a diferença de desempenho entre arquivos locais no ponto de montagem e arquivos remotos foi maior do que com pNFS.