Práticas recomendadas de opções de montagem do Linux NFS para Arquivos NetApp do Azure

Este artigo ajuda a compreender as opções de montagem e as práticas recomendadas para as utilizar com os Ficheiros NetApp do Azure.

Nconnect

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

Ao preparar um ambiente SAS GRID de vários nós para produção, pode notar uma redução repetível de 30% no tempo de execução, passando de 8 horas para 5,5 horas:

Opção de montagem de volume Tempos de execução da tarefa
Não nconnect 8 horas
nconnect=8 5,5 horas

Ambos os conjuntos de testes usaram a mesma máquina virtual E32-8_v4 e RHEL8.3, com leitura antecipada definida para 15 MiB.

Ao usar nconnecto , tenha em mente as seguintes regras:

  • nconnect é suportado pelos Arquivos NetApp do Azure em todas as principais distribuições Linux, mas apenas em versões mais recentes:

    Versão 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

    Nota

    SLES15SP2 é a versão mínima do SUSE na qual nconnect é suportada pelo Azure NetApp Files para NFSv4.1. Todas as outras versões, conforme especificado, são as primeiras versões que introduziram o nconnect recurso.

  • Todas as montagens de um único ponto de extremidade herdam a configuração nconnect do primeiro export montado, conforme mostrado nos seguintes cenários:

    Cenário 1: nconnect é usado pelo primeiro mount. Portanto, todas as montagens contra o 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 pelo primeiro mount. Portanto, nenhuma montagem no mesmo endpoint utiliza nconnect, embora nconnect possa ser especificado no mesmo.

    • 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: nconnect as configurações não são propagadas entre pontos de extremidade de armazenamento separados. nconnect é usado pelo suporte proveniente de 10.10.10.10 , mas não pelo suporte 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, consulte Práticas recomendadas de concorrência do Linux para Azure NetApp Files.

Nconnect considerações

Não é recomendado usar as opções de montagem nconnect e sec=krb5* em conjunto. Usar essas opções juntas pode causar degradação do desempenho.

A GSS-API (Generic Security Standard Application Programming Interface) fornece uma maneira de as aplicações protegerem os dados enviados para aplicações pares. Esses dados podem ser enviados de um cliente em uma máquina para um servidor em outra máquina. 

Quando nconnect é usado no Linux, o contexto de segurança GSS é compartilhado entre todas as nconnect conexões com um determinado servidor. O TCP é um transporte fiável que lida com pacotes fora de ordem num 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, exigindo que as mensagens sejam enviadas novamente. Um número maior de pacotes numa configuração nconnect causa pacotes frequentes fora da janela, acionando o comportamento descrito. Nenhuma porcentagem de degradação específica pode ser declarada com esse comportamento.

Rsize e Wsize

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

Os rsize sinalizadores e wsize definem o tamanho máximo de transferência de uma operação NFS. Se rsize ou wsize não forem especificados ao montar, o cliente e o servidor negociarão o maior tamanho suportado pelos dois. Atualmente, o Azure NetApp Files e as distribuições Linux modernas oferecem suporte a tamanhos de leitura e gravação tão grandes quanto 1.048.576 Bytes (1 MiB). No entanto, para uma melhor taxa de transferência geral e latência, os Arquivos NetApp do Azure recomendam definir ambos rsize e wsize não maiores que 262.144 Bytes (256 K). Você pode observar que tanto aumentou a latência quanto diminuiu a taxa de transferência ao usar rsize e wsize maiores que 256 KiB.

Por exemplo, Implementar um sistema SAP HANA em scale-out com nó de espera em VMs do Azure usando Arquivos NetApp do Azure no SUSE Linux Enterprise Server mostra o máximo de 256 KiB rsizewsize da seguinte 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 r/wsize a 64 KiB enquanto aumenta o desempenho de leitura com maior avanço de leitura para as montagens NFS. Consulte Práticas recomendadas de leitura antecipada do NFS para Azure NetApp Files para obter detalhes.

As seguintes considerações aplicam-se à utilização de rsize e wsize:

  • Os tamanhos de operação de E/S aleatória geralmente são menores do que as opções de montagem rsize e wsize. Como tal, não são restrições.
  • Ao usar a cache do sistema de ficheiros, a E/S sequencial ocorrerá no tamanho determinado pelas opções de montagem rsize e wsize, a menos que o tamanho do ficheiro seja inferior a rsize e wsize.
  • As operações que ignoram o cache do sistema de ficheiros, embora ainda sejam restringidas 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 usa geradores de carga de trabalho que têm a opção directio.

Como prática recomendada com os Arquivos NetApp do Azure, para melhor taxa de transferência geral e latência, defina rsize e wsize para não serem maiores que 262.144 Bytes.

Consistência close-to-open e temporizadores de atributos da cache

O NFS usa um modelo de consistência flexível. A consistência é fraca porque a aplicação não precisa ir para o armazenamento partilhado e buscar dados sempre que precisa de os usar, um cenário que teria um grande impacto no desempenho da aplicação. Há dois mecanismos que gerem esse processo: temporizadores de atributo de cache e consistência close-to-open.

Se o cliente tiver a propriedade total dos dados, ou seja, eles não forem compartilhados entre vários nós ou sistemas, há consistência garantida. Nesse caso, pode reduzir as getattr operações de acesso ao armazenamento e acelerar a aplicação 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 atributos (actimeo=600 como uma opção de montagem altera o temporizador para 10m em comparação com os padrões acregmin=3,acregmax=30,acdirmin=30,acdirmax=60). Em alguns testes, nocto reduz aproximadamente 65-70% das getattr chamadas de acesso, e ajustar actimeo reduz essas chamadas em outros 20-25%.

Como funcionam os temporizadores da cache de atributos

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

Por exemplo, considere os valores predefinidos acregmin e acregmax, 3 e 30 segundos, respetivamente. Por exemplo, os atributos são repetidamente avaliados para os arquivos em um diretório. Após 3 segundos, o serviço NFS é consultado quanto ao estado de atualização. Se os atributos forem considerados válidos, o cliente duplica o tempo de confiança para 6 segundos, 12 segundos, 24 segundos e, como o máximo está definido para 30, 30 segundos. A partir desse ponto, até que os atributos armazenados em cache sejam considerados desatualizados (momento em que o ciclo recomeça), a fiabilidade é definida como sendo de 30 segundos, 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 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 aplicativos que usam grades de clientes como EDA, hospedagem na Web e renderização de filmes e têm conjuntos de dados relativamente estáticos (ferramentas ou bibliotecas EDA, conteúdo da Web, dados de textura), o comportamento típico é que o conjunto de dados é em grande parte armazenado em cache nos clientes. Há poucas leituras e nenhuma gravação. Há muitas chamadas getattr/access a regressar ao armazenamento. Estes conjuntos de dados são geralmente atualizados através da montagem dos sistemas de ficheiros por outro cliente e do envio periódico de atualizações de conteúdo.

Nesses casos, há um atraso conhecido na captação de novos conteúdos e o aplicativo ainda funciona com dados potencialmente desatualizados. Nesses casos, nocto e actimeo podem ser usados para controlar o período em que a data desatualizada pode ser gerida. Por exemplo, em ferramentas e bibliotecas EDA, actimeo=600 funciona bem porque esses dados são normalmente atualizados com pouca frequência. Para pequenas hospedagens na web, onde os clientes precisam ver suas atualizações de dados em tempo hábil enquanto editam seus sites, actimeo=10 pode ser aceitável. Para sites de grande escala onde há conteúdo enviado para vários sistemas de arquivos, actimeo=60 pode ser aceitável.

O uso dessas opções de montagem reduz significativamente a carga no armazenamento nesses casos. (Por exemplo, uma utilização recente de EDA reduziu as IOPs para o volume da ferramenta de >150 K para ~6 K.) As aplicações podem ser executadas significativamente mais rápido porque podem confiar nos dados na memória. (O tempo de acesso à memória é de nanossegundos vs. centenas de microssegundos por getattr/acesso numa rede rápida.)

Consistência entre o fecho e a abertura

A consistência do fecho à abertura (a opção de montagem cto) garante que, independentemente do estado da cache, ao abrir, os dados mais recentes de um ficheiro são sempre apresentados à aplicação.

  • Quando um diretório é rastreado (ls, ls -l por exemplo), um determinado conjunto de RPCs (chamadas de procedimento remoto) é emitido. O servidor NFS partilha a sua visão do sistema de ficheiros. Desde que cto seja usado por todos os clientes NFS que acedem a uma determinada exportação NFS, todos os clientes verão a mesma lista de ficheiros e diretórios nela. A validade dos atributos dos ficheiros no diretório é controlada pelos temporizadores de cache de atributos. Em outras palavras, enquanto cto for usado, os ficheiros aparecerão aos clientes remotos assim que o ficheiro for criado e for armazenado no armazenamento.
  • Quando um arquivo é aberto, o conteúdo do arquivo está garantidamente atualizado da perspetiva do servidor NFS. Se houver uma condição de corrida em que o conteúdo não tenha terminado de ser descarregado da Máquina 1 quando um ficheiro for aberto na Máquina 2, a Máquina 2 só receberá os dados presentes no servidor no momento da abertura. Nesse caso, a Máquina 2 não recupera mais dados do ficheiro até que o temporizador acreg seja atingido, e a Máquina 2 verifica novamente a coerência da sua cache no servidor. Este cenário pode ser observado usando o comando tail -f da Máquina 2 quando o ficheiro ainda está a ser escrito a partir da Máquina 1.

Sem consistência de fecho para abertura

Quando nenhuma consistência close-to-open (nocto) é usada, o cliente confia na atualidade da sua vista atual do ficheiro e do diretório até expirarem os temporizadores de atributos da cache.

  • Quando um diretório é rastreado (ls, ls -l por exemplo), um determinado conjunto de RPCs (chamadas de procedimento remoto) é emitido. O cliente só emite uma chamada para o servidor para obter uma lista atual de ficheiros quando o valor do acdir temporizador de cache foi ultrapassado. Nesse caso, os arquivos e diretórios criados recentemente não aparecem. Arquivos e diretórios removidos recentemente aparecem.

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

Próximos passos

  • Última atualização a