Compartilhar via

Melhores práticas de opções de montagem do NFS no Linux para o Azure NetApp Files

  • Artigo

Este artigo ajuda você a entender as opções de montagem e as práticas recomendadas para usá-las com o Azure NetApp Files.

Nconnect

O uso da opção de montagem nconnect permite que você especifique o número de conexões (fluxos de rede) que devem ser estabelecidas entre o cliente NFS e o ponto de extremidade NFS até um limite de 16. Tradicionalmente, um cliente NFS usa uma só conexão entre si mesmo e o ponto de extremidade. Aumentar o número de fluxos de rede aumenta significativamente os limites superiores de E/S e taxa de transferência. O teste considerou que nconnect=8 teve o melhor desempenho.

Ao preparar um ambiente do SAS GRID de vários nós para produção, você pode observar uma redução repetida de 30% no runtime, de 8 a 5,5 horas:

Opções de montagem Runtimes do trabalho
Nenhum nconnect 8 horas
nconnect=8 5,5 horas

Os dois conjuntos de testes usaram a mesma máquina virtual E32-8_v4 e o RHEL 8.3, com a leitura antecipada definida como 15 MiB.

Ao usar nconnect, mantenha as seguintes regras em mente:

  • Há suporte para nconnect no Azure NetApp Files em todas as principais distribuições do Linux, mas somente nas versões mais recentes:

    Versão do Linux NFSv3 (versão mínima) NFSv4.1 (versão mínima)
    Red Hat Enterprise Linux RHEL8.3 RHEL8.3
    SUSE SLES12SP4 ou SLES15SP1 SLES15SP2
    Ubuntu Ubuntu 18.04

    Observação

    O SLES15SP2 é a versão mínima do SUSE na qual nconnect é compatível com o Azure NetApp Files para NFSv4.1. Todas as outras versões especificadas são as primeiras versões que apresentaram o recurso nconnect.

  • Todas as montagens de um só ponto de extremidade herdam a configuração nconnect da primeira exportação montada, conforme mostrado nos seguintes cenários:

    Cenário 1: nconnect é usado pela primeira montagem. Portanto, todas as montagens no mesmo ponto de extremidade usam nconnect=8.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.10.10.10:/volume2 /mnt/volume2
    • mount 10.10.10.10:/volume3 /mnt/volume3

    Cenário 2: nconnect não é usado pela primeira montagem. Portanto, nenhuma montagem no mesmo ponto de extremidade usa nconnect, embora nconnect possa ser especificado nele.

    • mount 10.10.10.10:/volume1 /mnt/volume1
    • mount 10.10.10.10:/volume2 /mnt/volume2 -o nconnect=8
    • mount 10.10.10.10:/volume3 /mnt/volume3 -o nconnect=8

    Cenário 3: as configurações de nconnect não são propagadas em pontos de extremidade de armazenamento separados. nconnect é usado pela montagem proveniente de 10.10.10.10, mas não pela montagem proveniente de 10.12.12.12.

    • mount 10.10.10.10:/volume1 /mnt/volume1 -o nconnect=8
    • mount 10.12.12.12:/volume2 /mnt/volume2

  • nconnect pode ser usado para aumentar a simultaneidade de armazenamento de qualquer cliente específico.

Para obter detalhes, confira Melhores práticas de simultaneidade do Linux para o Azure NetApp Files.

Considerações sobre Nconnect

Não é recomendável usar as opções de montagem nconnect e sec=krb5* juntas. Foi observada uma degradação do desempenho ao usar as duas opções em combinação.

A GSS-API (Interface de Programação de Aplicativo de Padrão de Segurança Genérico) fornece uma maneira de os aplicativos protegerem os dados enviados para aplicativos pares. Esses dados podem ser enviados de um cliente em um computador para um servidor em outro computador. 

Quando nconnect é usado no Linux, o contexto de segurança do GSS é compartilhado entre todas as conexões nconnect com um servidor específico. O TCP é um transporte confiável que dá suporte à entrega de pacotes fora de ordem para lidar com pacotes fora de ordem em um fluxo GSS, usando uma janela deslizante de números de sequência. Quando pacotes que não estão na janela de sequência são recebidos, o contexto de segurança é descartado, e um novo contexto de segurança é negociado. Todas as mensagens enviadas no contexto agora descartado não são mais válidas, o que exige que as mensagens sejam enviadas novamente. Um número maior de pacotes em uma instalação nconnect causa frequentes pacotes fora da janela, disparando o comportamento descrito. Nenhum percentual de degradação específico pode ser declarado com esse comportamento.

Rsize e Wsize

Exemplos nesta seção fornecem informações sobre como abordar o ajuste de desempenho. Talvez seja necessário fazer ajustes para atender às suas necessidades específicas do aplicativo.

Os sinalizadores rsize e wsize definem o tamanho máximo de transferência de uma operação NFS. Se rsize ou wsize não for especificado na montagem, o cliente e o servidor negociarão o maior tamanho compatível com os dois. Atualmente, as distribuições modernas do Linux e o Azure NetApp Files dão suporte a tamanhos de leitura e gravação que chegam a 1.048.576 bytes (1 MiB). No entanto, para obter a melhor taxa de transferência e latência geral, o Azure NetApp Files recomenda definir rsize e wsize com, no máximo, 262.144 bytes (256 K). Você pode observar um aumento da latência e uma redução da taxa de transferência durante o uso de rsize e wsize com um valor maior que 256 KiB.

Por exemplo, o artigo Implantar um sistema de expansão SAP HANA com o nó em espera em VMs do Azure usando o Azure NetApp Files no SUSE Linux Enterprise Server mostra o número máximo de rsize e wsize de 256 KiB desta forma:

sudo vi /etc/fstab
# Add the following entries
10.23.1.5:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.6:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0
10.23.1.4:/HN1-shared/shared /hana/shared  nfs   rw,vers=4,minorversion=1,hard,timeo=600,rsize=262144,wsize=262144,noatime,_netdev,sec=sys  0  0

Por exemplo, o SAS Viya recomenda tamanhos de leitura e gravação de 256 KiB, e o SAS GRID limita o r/wsize a 64 KiB, elevando o desempenho da leitura com o aumento da leitura antecipada nas montagens do NFS. Confira Práticas recomendadas de leitura antecipada do NFS para o Azure NetApp Files a fim de obter detalhes.

As seguintes considerações se aplicam ao uso de rsize e wsize:

  • Os tamanhos de operação de E/S aleatórios são geralmente menores do que as opções de montagem rsize e wsize. Como tal, eles não são restrições.
  • Quando o cache do sistema de arquivos for usado, a E/S sequencial ocorrerá no tamanho previsto pelas opções de montagem rsize e wsize, a menos que o tamanho do arquivo seja menor que rsize e wsize.
  • As operações que ignoram o cache do sistema de arquivos, embora ainda restritas pelas opções de montagem rsize e wsize, não são tão grandes quanto o máximo especificado por rsize ou wsize. Essa consideração é importante quando geradores de carga de trabalho que têm a opção directio são usados.

Como uma melhor prática com o Azure NetApp Files, para obter as melhores taxa de transferência e latência gerais, defina rsize e wsize com, no máximo, 262.144 bytes.

Consistência de fechamento para abertura e temporizadores de atributo de cache

O NFS usa um modelo de consistência flexível. A consistência é flexível porque o aplicativo não precisa acessar o armazenamento compartilhado e buscar dados todas as vezes para usá-lo, um cenário que teria um impacto considerável no desempenho do aplicativo. Há dois mecanismos que gerenciam esse processo: temporizadores de atributo de cache e consistência de fechamento para abertura.

Se o cliente tiver propriedade total dos dados, ou seja, se eles não forem compartilhados entre vários nós ou sistemas, haverá consistência garantida. Nesse caso, você pode reduzir as operações de acesso getattr ao armazenamento e acelerar o aplicativo desativando a consistência de fechamento para abertura (cto) (nocto como uma opção de montagem) e aumentando os tempos limite para o gerenciamento de cache de atributo (actimeo=600 como uma opção de montagem altera o temporizador para 10 min em relação aos padrões acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). Em alguns testes, nocto reduz aproximadamente 65 a 70% das chamadas de acesso a getattr, e o ajuste de actimeo reduz essas chamadas em outros 20 a 25%.

Como funcionam os temporizadores de cache de atributos

Os atributos acregmin, acregmax, acdirmin e acdirmax controlam a coerência do cache. Os dois primeiros atributos controlam o tempo durante o qual os atributos de arquivos são confiáveis. Os dois últimos atributos controlam o tempo durante o qual os atributos do próprio arquivo de diretório são confiáveis (tamanho, propriedade e permissões do diretório). Os atributos min e max definem a duração mínima e máxima em que os atributos de um diretório, os atributos de um arquivo e o conteúdo de cache de um arquivo são considerados confiáveis, respectivamente. Entre min e max, um algoritmo é usado para definir o tempo durante o qual uma entrada armazenada em cache é confiável.

Por exemplo, considere os valores padrão acregmin e acregmax, 3 e 30 segundos, respectivamente. Por exemplo, os atributos são avaliados repetidamente para os arquivos em um diretório. Após 3 segundos, o serviço do NFS é consultado quanto à atualização. Se os atributos forem considerados válidos, o cliente dobrará o tempo confiável para 6 segundos, 12 segundos, 24 segundos e o número máximo será definido como 30, 30 segundos. Desse ponto em diante, até que os atributos armazenados em cache sejam considerados desatualizados (ponto em que o ciclo inicia), a confiabilidade é definida como 30 segundos sendo o valor especificado por acregmax.

Há outros casos que podem se beneficiar de um conjunto semelhante de opções de montagem, mesmo quando não há nenhuma propriedade completa pelos clientes, por exemplo, se os clientes usam os dados como somente leitura e a atualização de dados é gerenciada por outro caminho. Para os aplicativos que usam grades de clientes como o EDA, a hospedagem na Web e a renderização de filmes e que têm conjuntos de dados relativamente estáticos (bibliotecas ou ferramentas do EDA, conteúdo da Web e dados de textura), o comportamento típico é que o conjunto de dados é amplamente armazenado em cache nos clientes. Há poucas leituras e nenhuma gravação. Há muitas chamadas de getattr/acesso voltadas para o armazenamento. Esses conjuntos de dados são normalmente atualizados por meio de outro cliente montando os sistemas de arquivos e enviando por push atualizações de conteúdo periodicamente.

Nesses casos, há um retardo conhecido na separação de novo conteúdo, e o aplicativo ainda funciona com os dados potencialmente desatualizados. Nesses casos, nocto e actimeo podem ser usados para controlar o período em que a data de desatualização pode ser gerenciada. Por exemplo, em ferramentas e bibliotecas do EDA, actimeo=600 funciona bem porque esses dados normalmente são atualizados com pouca frequência. Para a hospedagem pequena na Web, em que os clientes precisam ver as atualizações de dados em tempo hábil, conforme eles editam os respectivos sites, actimeo=10 pode ser aceitável. Para sites de grande escala em que há um conteúdo enviado por push para vários sistemas de arquivos, actimeo=60 pode ser aceitável.

Nesses casos, o uso dessas opções de montagem reduz significativamente a carga de trabalho para o armazenamento. (Por exemplo, uma experiência recente com o EDA reduziu a IOPS para o volume da ferramenta de >150 K para cerca de 6 K.) Os aplicativos podem ser executados significativamente com mais rapidez, pois eles podem confiar nos dados em memória. (O tempo de acesso à memória é de nanossegundos em comparação a centenas de microssegundos para getattr/acesso em uma rede rápida.)

Consistência de fechamento para abertura

A consistência de fechamento para abertura (a opção de montagem cto) garante que, não importa o estado do cache, na abertura, os dados mais recentes de um arquivo sempre sejam apresentados ao aplicativo.

  • Quando um diretório é populado (ls, ls -l por exemplo), um conjunto especificado de PRCs (chamadas de procedimento remoto) é emitido. O servidor NFS compartilha a respectiva exibição do sistema de arquivos. Desde que cto seja usado por todos os clientes NFS que acessam uma exportação do NFS específica, todos os clientes verão a mesma lista de arquivos e diretórios nela. A atualização dos atributos dos arquivos no diretório é controlada pelos temporizadores do cache de atributos. Em outras palavras, desde que cto seja usado, os arquivos são exibidos para os clientes remotos assim que o arquivo é criado e o arquivo chega no armazenamento.
  • Quando um arquivo é aberto, o conteúdo do arquivo é garantido como novo da perspectiva do servidor NFS. Se houver uma condição de corrida em que o conteúdo não concluiu a liberação do Computador 1 quando um arquivo for aberto no Computador 2, o Computador 2 receberá apenas os dados presentes no servidor no momento da abertura. Nesse caso, o Computador 2 não irá recuperar mais dados do arquivo até que o temporizador acreg seja atingido, e o Computador 2 verifique a coerência do cache do servidor novamente. Esse cenário pode ser observado com o uso de uma parte final -f do Computador 2 quando o arquivo ainda está sendo gravado no Computador 1.

Sem consistência de fechamento para abertura

Quando nenhuma consistência de fechamento para abertura (nocto) for usada, o cliente confiará na atualização da exibição atual do arquivo e do diretório até que os temporizadores de atributo de cache tenham sido violados.

  • Quando um diretório é populado (ls, ls -l por exemplo), um conjunto especificado de PRCs (chamadas de procedimento remoto) é emitido. O cliente irá emitir apenas uma chamada ao servidor para obter uma lista atual de arquivos quando o valor acdir do temporizador de cache tiver sido violado. Nesse caso, os arquivos e diretórios criados recentemente não aparecem. Os arquivos e diretórios removidos recentemente aparecem.

  • Quando um arquivo é aberto, desde que o arquivo ainda esteja no cache, o conteúdo armazenado em cache (se houver) é retornado sem validar a consistência com o servidor NFS.

Próximas etapas