Partilhar via

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

  • Artigo

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

Nconnect

O uso da nconnect opção mount permite especificar 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 única conexão entre ele e o ponto de extremidade. O aumento do número de fluxos de rede aumenta significativamente os limites superiores de E/S e taxa de transferência. Os testes revelaram-se nconnect=8 os mais eficientes.

Ao preparar um ambiente SAS GRID de vários nós para produção, você 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 Tempos de execução do trabalho
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 (liberação mínima) NFSv4.1 (versão mínima)
    Redhat 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 pelos Arquivos NetApp do Azure 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 nconnect configuração 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 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 primeira montagem. Portanto, nenhuma montagem contra o mesmo uso nconnect de ponto final, 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: 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 de qualquer cliente.

Para obter detalhes, consulte Práticas recomendadas de simultaneidade do Linux para arquivos NetApp do Azure.

Nconnect Considerações

Não é recomendado usar nconnect e sec=krb5* montar opções juntas. A degradação do desempenho foi observada ao usar as duas opções em combinação.

A GSS-API (Generic Security Standard Application Programming Interface) fornece uma maneira de os aplicativos protegerem os dados enviados para aplicativos 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 servidor específico. O TCP é um transporte confiável que suporta a 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, exigindo que as mensagens sejam enviadas novamente. Um número maior de pacotes em uma nconnect configuração causa pacotes fora da janela frequentes, 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 forem ou wsize não especificados na montagem, o cliente e o servidor negociarão o maior tamanho suportado pelos dois. Atualmente, os Arquivos NetApp do Azure 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 maior que 256 KiB.

Por exemplo, Implantar um sistema de expansão SAP HANA 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 rsize da wsize seguinte maneira:

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 a 64 KiB enquanto aumenta o r/wsize desempenho de leitura com maior avanço de leitura para as montagens NFS. Consulte Práticas recomendadas de leitura antecipada do NFS para Arquivos NetApp do Azure 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 rsize opções de montagem e wsize montagem. Como tal, não são constrangimentos.
  • Ao usar o cache do sistema de arquivos, a E/S sequencial ocorrerá no tamanho predicado pelas opções e wsize montagem, a menos que o rsize tamanho do arquivo seja menor que rsize e wsize.
  • As operações que ignoram o cache do sistema de arquivos, embora ainda sejam restringidas rsize pelas opções e wsize montagem, 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 directio opção.

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

Temporizadores de atributos de cache e consistência próxima da abertura

O NFS usa um modelo de consistência flexível. A consistência é frouxa porque o aplicativo não precisa ir para o armazenamento compartilhado e buscar dados toda vez para usá-lo, um cenário que teria um tremendo impacto no desempenho do aplicativo. Há dois mecanismos que gerenciam esse processo: temporizadores de atributo de cache e consistência próxima à abertura.

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, você pode reduzir as getattr operações de acesso ao armazenamento e acelerar o aplicativo desativando a consistência de fechar para abrir (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 chamadas de acesso, e o getattr ajuste actimeo reduz essas chamadas em outros 20-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 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 confiáveis (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 arquivo e conteúdo de cache de um arquivo 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 o padrão acregmin e acregmax os valores, 3 e 30 segundos, respectivamente. 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 à frescura. Se os atributos forem considerados válidos, o cliente dobra o tempo confiável para 6 segundos, 12 segundos, 24 segundos, então como o máximo é definido como 30, 30 segundos. A partir desse ponto, até que os atributos armazenados em cache sejam considerados desatualizados (quando o ciclo recomeça), 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á 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 escrita. Há muitas getattrchamadas /access voltando para o armazenamento. Esses conjuntos de dados geralmente são atualizados por meio de outro cliente, montando os sistemas de arquivos e enviando periodicamente 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 pode ser usado para controlar o período em que a desatualização de dados pode ser gerenciada. 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 de trabalho para armazenamento nesses casos. (Por exemplo, uma experiência recente da EDA reduziu as IOPs para o volume da ferramenta de >150 K para ~6 K.) Os aplicativos podem ser executados significativamente mais rápido porque podem confiar nos dados na memória. (O tempo de acesso à memória é de nanossegundos vs. centenas de microssegundos para getattr/access em uma rede rápida.)

Consistência próxima da abertura

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

  • Quando um diretório é rastreado (ls, ls -l por exemplo), um determinado conjunto de RPCs (chamadas de procedimento remoto) é emitido. O servidor NFS compartilha sua visão do sistema de arquivos. Desde que seja usado por todos os clientes NFS que cto acessam uma determinada exportação NFS, 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 de cache de atributos. Em outras palavras, enquanto cto for usado, os arquivos aparecerão para clientes remotos assim que o arquivo for criado e o arquivo pousar no armazenamento.
  • Quando um arquivo é aberto, o conteúdo do arquivo é garantido fresco da perspetiva do servidor NFS. Se houver uma condição de corrida em que o conteúdo não tenha terminado de ser liberado da Máquina 1 quando um arquivo 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 arquivo até que o temporizador seja atingido e a acreg Máquina 2 verifica sua coerência de cache do servidor novamente. Esse cenário pode ser observado usando uma cauda -f da Máquina 2 quando o arquivo ainda está sendo gravado na Máquina 1.

Sem consistência próxima da abertura

Quando nenhuma consistência próxima à abertura (nocto) é usada, o cliente confia na atualização de sua exibição atual do arquivo e do diretório até que os temporizadores do atributo cache tenham sido violados.

  • 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 arquivos quando o valor do acdir temporizador de cache foi violado. 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