Partilhar via

Práticas recomendadas de simultaneidade do Linux para Arquivos NetApp do Azure - Slots de sessão e entradas de tabela de slots

  • Artigo

Este artigo ajuda você a entender as práticas recomendadas de simultaneidade para slots de sessão e entradas de tabela de slots do protocolo NFS do Azure NetApp Files.

NFSv3

O NFSv3 não tem um mecanismo para negociar simultaneidade entre o cliente e o servidor. O cliente e o servidor definem cada um o seu limite sem consultar o outro. Para obter o melhor desempenho, você deve alinhar o número máximo de entradas da tabela de slots do lado sunrpc do cliente com as suportadas sem pushback no servidor. Quando um cliente sobrecarrega a capacidade da pilha de rede do servidor de processar uma carga de trabalho, o servidor responde diminuindo o tamanho da janela para a conexão, o que não é um cenário de desempenho ideal.

Por padrão, os kernels Linux modernos definem o tamanho sunrpc.tcp_max_slot_table_entries de entrada da tabela de slot por conexão sunrpc como suportando 65.536 operações pendentes, conforme mostrado na tabela a seguir.

Servidor NFSv3 de Arquivos NetApp do Azure
Contextos de execução máximos por conexão		 Cliente Linux
Entradas padrão da tabela de slots máximos sunrpc por conexão
128 65 536

Essas entradas da tabela de slots definem os limites da simultaneidade. Valores tão altos são desnecessários. Por exemplo, usando uma teoria de fila conhecida como Lei de Littles, você descobrirá que a taxa de E/S é determinada por simultaneidade (ou seja, E/S pendente) e latência. Como tal, o algoritmo prova que 65.536 slots são ordens de magnitude superiores ao necessário para conduzir mesmo cargas de trabalho extremamente exigentes.

Littles Law: (concurrency = operation rate × latency in seconds)

Um nível de simultaneidade tão baixo quanto 155 é suficiente para atingir 155.000 operações Oracle DB NFS por segundo usando o nconnect Oracle Direct NFS, que é uma tecnologia semelhante em conceito à opção de montagem:

  • Considerando uma latência de 0,5 ms, é necessária uma simultaneidade de 55 para atingir 110.000 IOPS.
  • Considerando uma latência de 1 ms, é necessária uma simultaneidade de 155 para atingir 155.000 IOPS.

Oracle DNFS latency curve

Consulte Desempenho do banco de dados Oracle em volumes únicos dos Arquivos NetApp do Azure para obter detalhes.

O sunrpc.tcp_max_slot_table_entries ajustável é um parâmetro de ajuste no nível de conexão. Como prática recomendada, defina esse valor para 128 ou menos por conexão, não ultrapassando 10.000 slots em todo o ambiente.

Exemplos de contagem de faixas horárias com base na recomendação de simultaneidade

Exemplos nesta seção demonstram a contagem de slots com base na recomendação de simultaneidade.

Exemplo 1 – Um cliente NFS, 65.536 sunrpc.tcp_max_slot_table_entriese não nconnect para uma simultaneidade máxima de 128 com base no limite do lado do servidor de 128

O Exemplo 1 é baseado em uma única carga de trabalho de cliente com o valor padrão sunrpc.tcp_max_slot_table_entry de 65.536 e uma única conexão de rede, ou seja, sem nconnect. Neste caso, uma simultaneidade de 128 é alcançável.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • O cliente, em teoria, não pode emitir mais de 65.536 solicitações em voo para o servidor por conexão.
      • O servidor não aceitará mais de 128 solicitações em voo a partir desta única conexão.

Exemplo 2 – Um cliente NFS, 128 e não nconnect para uma simultaneidade máxima de 128 sunrpc.tcp_max_slot_table_entries

O Exemplo 2 é baseado em uma única carga de trabalho de cliente com um sunrpc.tcp_max_slot_table_entry valor de 128, mas sem a nconnect opção de montagem. Com essa configuração, uma simultaneidade de 128 é possível a partir de uma única conexão de rede.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • O cliente emitirá no máximo 128 solicitações em voo para o servidor por conexão.
      • O servidor não aceitará mais de 128 solicitações em voo a partir desta única conexão.

Exemplo 3 – Um cliente NFS, 100 e nconnect=8 para uma simultaneidade máxima de 800 sunrpc.tcp_max_slot_table_entries

O Exemplo 3 é baseado em uma única carga de trabalho de cliente, mas com um valor menor sunrpc.tcp_max_slot_table_entry de 100. Desta vez, a opção de montagem usada distribui a nconnect=8 carga de trabalho por 8 conexões. Com essa configuração, uma simultaneidade de 800 é alcançável espalhada pelas 8 conexões. Este montante é a simultaneidade necessária para atingir 400.000 IOPS.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP), Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)… Connection 8 (10.10.10.10:2049, 10.10.10.11:7321,TCP)
    • Conexão 1
      • O cliente emitirá no máximo 100 solicitações em voo para o servidor a partir dessa conexão.
      • Espera-se que o servidor não aceite mais de 128 solicitações em fuga do cliente para essa conexão.
    • Conexão 2
      • O cliente emitirá no máximo 100 solicitações em voo para o servidor a partir dessa conexão.
      • Espera-se que o servidor não aceite mais de 128 solicitações em fuga do cliente para essa conexão.
    • …
    • …
    • Conexão 8
      • O cliente emitirá no máximo 100 solicitações em voo para o servidor a partir dessa conexão.
      • Espera-se que o servidor não aceite mais de 128 solicitações em fuga do cliente para essa conexão.

Exemplo 4 – 250 clientes NFS, 8 sunrpc.tcp_max_slot_table_entriese não nconnect para uma simultaneidade máxima de 2000

O Exemplo 4 usa o valor reduzido por cliente sunrpc.tcp_max_slot_table_entry de 8 para um ambiente EDA de 250 contagens de máquinas. Nesse cenário, uma simultaneidade de 2000 é atingida em todo o ambiente, um valor mais do que suficiente para gerar 4.000 MiB/s de uma carga de trabalho EDA de back-end.

  • NFS_Server=10.10.10.10, NFS_Client1=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • O cliente emitirá no máximo 8 solicitações em voo para o servidor por conexão.
      • O servidor não aceitará mais de 128 solicitações em voo a partir desta única conexão.
  • NFS_Server=10.10.10.10, NFS_Client2=10.10.10.12
    • Connection (10.10.10.10:2049, 10.10.10.12:7820,TCP)
      • O cliente emitirá no máximo 8 solicitações em voo para o servidor por conexão.
      • O servidor não aceitará mais de 128 solicitações em voo a partir desta única conexão.
  • …
  • …
  • NFS_Server=10.10.10.10, NFS_Client250=10.10.11.13
    • Connection (10.10.10.10:2049, 10.10.11.13:4320,TCP)
      • O cliente emitirá no máximo 8 solicitações em voo para o servidor por conexão.
      • O servidor não aceitará mais de 128 solicitações em voo a partir desta única conexão.

Ao usar o NFSv3, você deve manter coletivamente a contagem de slots de ponto de extremidade de armazenamento em 10.000 ou menos. É melhor definir o valor por conexão para sunrpc.tcp_max_slot_table_entries menos de 128 quando um aplicativo é expandido em muitas conexões de rede (nconnect e HPC em geral, e EDA em particular).

Como calcular o melhor sunrpc.tcp_max_slot_table_entries

Usando a Lei de Littles, você pode calcular a contagem total necessária de entradas na tabela de slots. Em geral, considere os seguintes fatores:

  • As cargas de trabalho de expansão são muitas vezes de natureza sequencial predominantemente grande.
  • As cargas de trabalho de banco de dados, especialmente OLTP, geralmente são aleatórias por natureza.

A tabela a seguir mostra um estudo de exemplo de simultaneidade com latências arbitrárias fornecidas:

Tamanho de E/S Latência E/S ou taxa de transferência Simultaneidade
8 KiB 0,5 ms 110.000 IOPS | 859 MiB/s 55
8 KiB 2 ms 400.000 IOPS | 3.125 MiB/s 800
256 KiB 2 ms 16.000 IOPS | 4.000 MiB/s 32
256 KiB 4 ms 32.000 IOPS | 8.000 MiB/s 128

Como calcular configurações de simultaneidade por contagem de conexões

Por exemplo, se a carga de trabalho for um farm EDA e 1.250 clientes levarem a carga de trabalho para o mesmo ponto final de armazenamento (um ponto final de armazenamento é um endereço IP de armazenamento), calcule a taxa de E/S necessária e divida a simultaneidade pelo farm.

Suponha que a carga de trabalho é de 4.000 MiB/s usando um tamanho médio de operação de 256 KiB e uma latência média de 10 ms. Para calcular a simultaneidade, use a seguinte fórmula:

(concurrency = operation rate × latency in seconds)

O cálculo traduz-se numa simultaneidade de 160:

(160 = 16,000 × 0.010)

Dada a necessidade de 1.250 clientes, você pode definir sunrpc.tcp_max_slot_table_entries com segurança 2 por cliente para atingir os 4.000 MiB/s. No entanto, você pode decidir construir um espaço extra definindo o número por cliente para 4 ou até 8, mantendo-se bem abaixo do teto de 10.000 slots recomendado.

Como definir sunrpc.tcp_max_slot_table_entries no cliente

  1. Adicione sunrpc.tcp_max_slot_table_entries=<n> ao /etc/sysctl.conf arquivo de configuração.
    Durante o ajuste, se um valor inferior a 128 for considerado ideal, substitua 128 pelo número apropriado.
  2. Execute o seguinte comando:
    $ sysctl -p
  3. Monte (ou remonte) todos os sistemas de arquivos NFS, pois o ajuste se aplica somente a montagens feitas após o ajuste ter sido definido.

NFSv4.1

No NFSv4.1, as sessões definem a relação entre o cliente e o servidor. Se os sistemas de arquivos NFS montados ficam em cima de uma conexão ou de muitas (como é o caso com nconnect), as regras para a sessão se aplicam. Na configuração da sessão, o cliente e o servidor negociam o máximo de solicitações para a sessão, estabelecendo o menor dos dois valores suportados. Os Arquivos NetApp do Azure dão suporte a 180 solicitações pendentes e os clientes Linux usam como padrão 64. A tabela a seguir mostra os limites da sessão:

Azure NetApp Files NFSv4.1 servidor
Máximo de comandos por sessão		 Cliente Linux
Comandos máximos padrão por sessão		 Comandos máximos negociados para a sessão
180 64 64

Embora os clientes Linux tenham como padrão 64 solicitações máximas por sessão, o valor de max_session_slots é ajustável. É necessária uma reinicialização para que as alterações entrem em vigor. Use o comando para ver o systool -v -m nfs máximo atual em uso pelo cliente. Para que o comando funcione, pelo menos uma montagem NFSv4.1 deve estar no lugar:

$ systool -v -m nfs
{
Module = "nfs"
...
  Parameters:
...
    max_session_slots   = "64"
...
}

Para ajustar max_session_slotso , crie um arquivo de configuração em /etc/modprobe.d como tal. Certifique-se de que não há "aspas" para a linha no arquivo. Caso contrário, a opção não terá efeito.

$ sudo echo “options nfs max_session_slots=180” > /etc/modprobe.d/nfsclient.conf $ sudo reboot

O Azure NetApp Files limita cada sessão a 180 comandos máximos. Como tal, considere 180 o valor máximo atualmente configurável. O cliente não poderá obter uma simultaneidade maior que 128, a menos que a sessão seja dividida em mais de uma conexão, pois os Arquivos NetApp do Azure restringem cada conexão a 128 comandos NFS máximos. Para obter mais de uma conexão, a nconnect opção de montagem é recomendada, e um valor de duas ou mais é necessário.

Exemplos de máximos de simultaneidade esperados

Os exemplos nesta seção demonstram os máximos de simultaneidade esperados.

Exemplo 1 – 64 max_session_slots e não nconnect

O Exemplo 1 baseia-se na configuração padrão de 64 max_session_slots e no nconnect. Com essa configuração, uma simultaneidade de 64 é possível, tudo a partir de uma única conexão de rede.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • O cliente emitirá no máximo 64 solicitações em voo para o servidor para a sessão.
      • O servidor não aceitará mais de 64 solicitações em fuga do cliente para a sessão. (64 é o valor negociado.)

Exemplo 2 – 64 max_session_slots e nconnect=2

O exemplo 2 é baseado em 64 max session_slots , mas com a opção de montagem adicionada de nconnect=2. Uma simultaneidade de 64 é alcançável, mas dividida em duas conexões. Embora várias conexões não tragam maior simultaneidade nesse cenário, a diminuição da profundidade da fila por conexão tem um impacto positivo na latência.

Com o ainda em 64 mas nconnect=2, observe que o max_session_slots número máximo de solicitações é dividido entre as conexões.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • Conexão 1
      • O cliente emitirá no máximo 32 solicitações em voo para o servidor a partir desta conexão.
      • Espera-se que o servidor não aceite mais de 32 solicitações em fuga do cliente para essa conexão.
    • Conexão 2
      • O cliente emitirá no máximo 32 solicitações em voo para o servidor a partir desta conexão.
      • Espera-se que o servidor não aceite mais de 32 solicitações em fuga do cliente para essa conexão.

Exemplo 3 – 180 max_session_slots e não nconnect

O Exemplo 3 descarta a nconnect opção mount e define o max_session_slots valor como 180, correspondendo à simultaneidade máxima de sessão NFSv4.1 do servidor. Nesse cenário, com apenas uma conexão e dada a operação máxima pendente dos Arquivos NetApp do Azure 128 por conexão NFS, a sessão é limitada a 128 operações em voo.

Embora max_session_slots tenha sido definido como 180, a conexão de rede única é limitada a 128 solicitações máximas como tal:

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection (10.10.10.10:2049, 10.10.10.11:6543,TCP)
      • O cliente emitirá no máximo 180 solicitações em voo para o servidor para a sessão.
      • O servidor não aceitará mais de 180 solicitações em fuga do cliente para a sessão.
      • O servidor não aceitará mais de 128 solicitações em voo para a conexão única.

Exemplo 4 – 180 max_session_slots e nconnect=2

O Exemplo 4 adiciona a nconnect=2 opção de montagem e reutiliza o valor 180 max_session_slots . Como a carga de trabalho geral é dividida em duas conexões, 180 operações pendentes são alcançáveis.

Com duas conexões em jogo, a sessão suporta a alocação total de 180 solicitações pendentes.

  • NFS_Server=10.10.10.10, NFS_Client=10.10.10.11
    • Connection 1 (10.10.10.10:2049, 10.10.10.11:6543,TCP) && Connection 2 (10.10.10.10:2049, 10.10.10.11:6454,TCP)
    • Conexão 1
      • Espera-se que o cliente não mantenha mais de 90 solicitações em voo para o servidor a partir da conexão um.
      • Espera-se que o servidor não mantenha mais de 90 solicitações em fuga do cliente para essa conexão dentro da sessão.
    • Conexão 2
      • Espera-se que o cliente não mantenha mais de 90 solicitações em voo para o servidor a partir da conexão um.
      • Espera-se que o servidor não mantenha mais de 90 solicitações em fuga do cliente para essa conexão dentro da sessão.

Nota

Para simultaneidade máxima, defina max_session_slots igual a 180, que é a simultaneidade máxima de nível de sessão suportada pelos Arquivos NetApp do Azure atualmente.

Como verificar o máximo de solicitações pendentes para a sessão

Para ver os session_slot tamanhos suportados pelo cliente e servidor, capture o comando mount em um rastreamento de pacote. Procure a chamada e CREATE_SESSION responda, conforme mostrado no exemplo a CREATE_SESSION seguir. A chamada originou-se do cliente e a resposta originou-se do servidor.

Use o seguinte tcpdump comando para capturar o comando mount:

$ tcpdump -i eth0 -s 900 -w /tmp/write.trc port 2049

Usando o Wireshark, os pacotes de interesse são os seguintes:

Screenshot that shows packets of interest.

Dentro desses dois pacotes, observe o max_reqs campo dentro da seção do meio do arquivo de rastreamento.

  • Sistema de arquivos de rede
    • Operações
      • Opcode
        • csa_fore_channel_attrs
        • max reqs

O pacote 12 (solicitações máximas do cliente) mostra que o cliente tinha um max_session_slots valor de 64. Na próxima seção, observe que o servidor suporta uma simultaneidade de 180 para a sessão. A sessão acaba por negociar o menor dos dois valores previstos.

Screenshot that shows max session slots for Packet 12.

O exemplo a seguir mostra Packet 14 (solicitações máximas do servidor):

Screenshot that shows max session slots for Packet 14.

Próximos passos