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

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

Use a opção de montagem nconnect para especificar o número de conexões (fluxos de rede) entre o cliente NFS e o endpoint NFS, até 16. Tradicionalmente, um cliente NFS usa uma só conexão entre ele e o endpoint. Aumentar significativamente o número de fluxos de rede eleva significativamente os limites superiores de E/S e throughput. Para encontrar a configuração ideal para o seu ambiente específico, teste várias configurações para nconnect antes de colocar sua aplicação em produção, se possível. Na maioria dos ambientes, o resultado ótimo é nconnect=4.

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

Opção de montagem Tempos de execução 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 pré-leitura 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 Ubuntu18.04

    Observação

    O SLES15SP2 é a versão mínima do SUSE na qual nconnect é suportado pelo 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 do primeiro export montado, conforme mostrado nos seguintes cenários:

    Cenário 1: nconnect é usado pela primeira montagem. Portanto, todos os mounts no mesmo endpoint 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 montagem inicial. Portanto, nenhuma montagem no mesmo endpoint usa nconnect, embora nconnect possa ser especificado nesse endpoint.

    • 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 pelo mount proveniente de 10.10.10.10, mas não pelo mount 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 a partir de qualquer cliente.

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

Nconnect considerações

Não é recomendável usar as opções de montagem nconnect e sec=krb5* juntas. Usar essas opções juntas pode causar degradação de desempenho.

A GSS-API (Interface de Programação de Aplicações de Padrão de Segurança Genérico) fornece uma maneira de os aplicativos protegerem os dados enviados para aplicações homólogas. 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 para um determinado servidor. O TCP é um transporte confiável que lida 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 maior número de pacotes em uma instalação nconnect causa pacotes frequentes 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 ao montar, 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 tanto um aumento da latência quanto uma redução da taxa de transferência ao usar rsize e wsize maiores que 256 KiB.

Por exemplo, o artigo Implantar um sistema scale-out do SAP HANA com nó de 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 pré-leitura nas montagens do NFS. Confira Práticas recomendadas de leitura antecipada do NFS para o Azure NetApp Files a fim de obter detalhes.

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

  • Os tamanhos de operação de E/S aleatórias são geralmente menores do que os tamanhos especificados pelas opções de montagem rsize e wsize. Portanto, 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 você usa geradores de carga de trabalho que têm a opção directio.

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 close-to-open e temporizadores de atributo de cache

O NFS usa um modelo de consistência fraca. A consistência é menos rigorosa 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 close-to-open consistency.

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 close-to-open (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 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 ao estado atual. Se os atributos forem considerados válidos, o cliente dobrará o tempo confiável para 6 segundos, 12 segundos, 24 segundos e, como o máximo é 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 sendo 30 segundos, 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á propriedade total dos 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 computadores cliente, como EDA, hospedagem na Web e renderização de filmes, e que têm conjuntos de dados relativamente estáticos (ferramentas ou bibliotecas de EDA, conteúdo da Web e dados de textura), o comportamento típico é que o conjunto de dados fica amplamente armazenado em cache nos clientes. Há poucas leituras e nenhuma gravação. Há muitas chamadas de getattr/acesso retornando ao 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 detecçã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 fora de vigência 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 real, 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 no armazenamento. (Por exemplo, uma experiência recente com o EDA reduziu as IOPs no 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 fechado para aberto

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 é percorrido (ls, ls -l por exemplo), um conjunto especificado de RPCs (chamadas de procedimento remoto) é emitido. O servidor NFS compartilha sua visã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 validade 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 atualizado da perspectiva do servidor NFS. Se houver uma condição de corrida em que o conteúdo não concluiu a gravaçã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, a Máquina 2 não irá recuperar mais dados do arquivo até que o temporizador acreg seja atingido e a Máquina 2 verifique novamente com o servidor a coerência do seu cache. Esse cenário pode ser observado com o uso de tail -f do Computador 2 quando o arquivo ainda está sendo gravado no Computador 1.

Sem consistência entre fechamento e abertura

Quando nenhuma consistência de fechamento para abertura (nocto) for usada, o cliente confiará na atualidade de sua visão atual do arquivo e do diretório até que os temporizadores de atributo de cache tenham expirado.

  • Quando um diretório é percorrido (ls, ls -l por exemplo), um determinado conjunto de RPCs (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 expirado. Nesse caso, os arquivos e diretórios criados recentemente não aparecem. Os arquivos e diretórios removidos recentemente não 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

  • Última atualização em