Melhores práticas de simultaneidade do Linux para o Azure NetApp Files – Slots de sessão e entradas da tabela de slots

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

NFSv3

O NFSv3 não tem um mecanismo para negociar a simultaneidade entre o cliente e o servidor. O cliente e o servidor definem o próprio limite sem consultar o outro. Para obter o melhor desempenho, alinhe o número máximo de entradas da tabela de slots sunrpc do lado do cliente com aquelas compatíveis sem recusa no servidor. Quando um cliente sobrecarrega a capacidade da pilha de rede do servidor de processar uma carga de trabalho, o servidor responde a isso diminuindo o tamanho da janela para a conexão, o que não é um cenário de desempenho ideal.

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

Servidor Azure NetApp Files NFSv3 Número máximo de contextos de execução por conexão	Cliente Linux Número máximo de entradas da tabela de slots sunrpc padrão por conexão
128	65.536

Essas entradas da tabela de slots definem os limites de simultaneidade. Valores altos como esses são desnecessários. Por exemplo, usando uma teoria de colocação na fila conhecida como a Lei de Little, você descobrirá que a taxa de E/S é determinada pela simultaneidade (ou seja, a E/S pendente) e pela latência. Assim, o algoritmo prova que 65.536 slots são ordens de magnitude maiores do que o necessário para conduzir mesmo cargas de trabalho com extrema demanda.

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

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

• Considerando uma latência de 0,5 ms, uma simultaneidade igual a 55 é necessária para alcançar 110 mil IOPS.
• Considerando uma latência de 1ms, uma simultaneidade igual a 155 é necessária para alcançar 155 mil IOPS.

Confira Desempenho de Oracle Database em volumes individuais do Azure NetApp Files para obter detalhes.

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

Exemplos de contagem de slots baseado na recomendação de simultaneidade

Os exemplos desta 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_entries e nenhum nconnect para uma simultaneidade máxima igual a 128 com base no limite do lado do servidor de 128

O exemplo 1 baseia-se em uma só carga de trabalho de cliente com o valor padrão sunrpc.tcp_max_slot_table_entry igual a 65.536 e uma conexão de rede individual, ou seja, nenhum nconnect. Nesse caso, uma simultaneidade igual a 128 é viá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)
    • Em teoria, o cliente pode emitir, no máximo, 65.536 solicitações em versão piloto para o servidor por conexão.
    • O servidor não aceitará mais de 128 solicitações em versão piloto dessa única conexão.

Exemplo 2 – Um cliente NFS, 128 sunrpc.tcp_max_slot_table_entries e nenhum nconnect para uma simultaneidade máxima igual a 128

O exemplo 2 baseia-se em uma só carga de trabalho de cliente com um valor sunrpc.tcp_max_slot_table_entry igual a 128, mas sem a opção de montagem nconnect. Com essa configuração, uma simultaneidade igual a 128 pode ser obtida em uma conexão de rede individual.

• 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 versão piloto para o servidor por conexão.
    • O servidor não aceitará mais de 128 solicitações em versão piloto dessa única conexão.

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

O exemplo 3 baseia-se em uma só carga de trabalho de cliente, mas com um valor sunrpc.tcp_max_slot_table_entry inferior igual a 100. Desta vez, a opção de montagem nconnect=8 usou a distribuição da carga de trabalho entre oito conexões. Com essa configuração, uma simultaneidade igual a 800 pode ser obtida com a distribuição entre as oito conexões. Esse valor é a simultaneidade necessária para obter 400 mil 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 trânsito para o servidor nessa conexão.
    • Espera-se que o servidor aceite, no máximo, 128 solicitações em versão piloto do cliente para essa conexão.
  • Conexão 2
    • O cliente emitirá, no máximo, 100 solicitações em trânsito para o servidor nessa conexão.
    • Espera-se que o servidor aceite, no máximo, 128 solicitações em versão piloto do cliente para essa conexão.
  • …
  • …
  • Conexão 8
    • O cliente emitirá, no máximo, 100 solicitações em trânsito para o servidor nessa conexão.
    • Espera-se que o servidor aceite, no máximo, 128 solicitações em versão piloto do cliente para essa conexão.

Exemplo 4 – 250 clientes NFS, oito sunrpc.tcp_max_slot_table_entries e nenhum nconnect para uma simultaneidade máxima igual a dois mil

O exemplo 4 usa o valor sunrpc.tcp_max_slot_table_entry reduzido por cliente igual a 8 para um ambiente de EDA com uma contagem de 250 computadores. Nesse cenário, uma simultaneidade igual a dois mil é obtida em todo o ambiente, um valor mais do que suficiente para conduzir quatro mil MiB/s de uma carga de trabalho de 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, oito solicitações em versão piloto para o servidor por conexão.
    • O servidor não aceitará mais de 128 solicitações em versão piloto dessa ú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, oito solicitações em versão piloto para o servidor por conexão.
    • O servidor não aceitará mais de 128 solicitações em versão piloto dessa ú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, oito solicitações em versão piloto para o servidor por conexão.
    • O servidor não aceitará mais de 128 solicitações em versão piloto dessa única conexão.

Ao usar o NFSv3, você deve manter coletivamente a contagem de slots do ponto de extremidade de armazenamento como 10 mil ou menos. É melhor definir o valor por conexão de sunrpc.tcp_max_slot_table_entries como inferior a 128 quando um aplicativo é escalado em várias conexões de rede (nconnect e HPC em geral e EDA em particular).

Como calcular a melhor sunrpc.tcp_max_slot_table_entries

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

• Em geral, as cargas de trabalho de escala horizontal são sequenciais dominantemente grandes por natureza.
• As cargas de trabalho de banco de dados, especialmente o OLTP, costumam ser aleatórias por natureza.

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

Tamanho de E/S	Latency	E/S ou taxa de transferência	Simultaneidade
8 KiB	0,5ms	110 mil IOPS | 859 MiB/s	55
8 KiB	2 ms	400 mil IOPS | 3.125 MiB/s	800
256 KiB	2 ms	16 mil IOPS | 4 mil MiB/s	32
256 KiB	4 ms	32 mil IOPS | 8 mil MiB/s	128

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

Por exemplo, se a carga de trabalho for um farm de EDA e todos os 1.250 clientes a conduzirem para o mesmo ponto de extremidade de armazenamento (consiste em um endereço IP de armazenamento), você irá calcular a taxa de E/S necessária e dividirá a simultaneidade no farm.

Suponha que a carga de trabalho seja de quatro mil MiB/s com 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 é convertido em uma simultaneidade igual a 160:

(160 = 16,000 × 0.010)

Considerando a necessidade de 1.250 clientes, você pode definir sunrpc.tcp_max_slot_table_entries como dois por cliente com segurança para obter os quatro mil MiB/s. No entanto, você pode decidir criar uma reserva dinâmica adicional definindo o número por cliente como quatro ou, até mesmo, oito, o que o mantém abaixo do limite de slot recomendado de 10 mil.

Como definir sunrpc.tcp_max_slot_table_entries no cliente

1. Adicione sunrpc.tcp_max_slot_table_entries=<n> ao arquivo de configuração /etc/sysctl.conf.
   Durante o ajuste, se um valor inferior a 128 for considerado ideal, substitua 128 pelo número apropriado.
2. Execute o comando a seguir:
   $ sysctl -p
3. Monte (ou remonte) todos os sistemas de arquivos NFS, pois o ajustável se aplica somente às montagens feitas depois que o ajustável é 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 residirem em uma conexão ou em várias (como é o caso com nconnect) depende das regras da sessão aplicáveis. Na configuração da sessão, o cliente e o servidor negociam o número máximo de solicitações para a sessão, estabelecendo o menor dos dois valores compatíveis. O Azure NetApp Files dá suporte a 180 solicitações pendentes, e os clientes Linux usam 64 como padrão. A seguinte tabela mostra os limites da sessão:

Servidor Azure NetApp Files NFSv4.1 Número máximo de comandos por sessão	Cliente Linux Número máximo de comandos padrão por sessão	Número máximo de comandos negociados para a sessão
180	64	64

Embora os clientes Linux usem como padrão o número máximo de 64 solicitações por sessão, o valor de max_session_slots é ajustável. Uma reinicialização é necessária para que as alterações entrem em vigor. Use o comando systool -v -m nfs para ver o número máximo atual em uso pelo cliente. Para que o comando funcione, no mínimo, uma montagem do NFSv4.1 precisa estar em vigor:

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

Para ajustar max_session_slots, crie um arquivo de configuração em /etc/modprobe.d, desta forma. Verifique se há "aspas" na linha do arquivo. Caso contrário, a opção não entrará em vigor.

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

O Azure NetApp Files limita cada sessão a, no máximo, 180 comandos. Assim, considere 180 o valor máximo configurável no momento. 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 o Azure NetApp Files restringe cada conexão a, no máximo, 128 comandos do NFS. Para obter mais de uma conexão, a opção de montagem nconnect é recomendada e um valor igual a dois ou mais é necessário.

Exemplos de números máximos de simultaneidade esperados

Os exemplos desta seção demonstram os números máximos de simultaneidade esperados.

Exemplo 1 – 64 max_session_slots e nenhum nconnect

O exemplo 1 baseia-se na configuração padrão de 64 max_session_slots e nenhum nconnect. Com essa configuração, uma simultaneidade igual a 64 pode ser obtida, tudo isso com uma só 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 versão piloto para o servidor da sessão.
    • O servidor aceitará, no máximo, 64 solicitações em versão piloto do cliente para a sessão. (64 é o valor negociado.)

Exemplo 2 – 64 max_session_slots e nconnect=2

O exemplo 2 baseia-se no número máximo de 64 session_slots, mas com a opção de montagem adicionada de nconnect=2. Uma simultaneidade igual a 64 pode ser obtida, mas dividida em duas conexões. Embora o uso de várias conexões não traga uma simultaneidade maior nesse cenário, a profundidade da fila reduzida por conexão tem um impacto positivo na latência.

Com os max_session_slots ainda em 64, mas nconnect=2, observe que o 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 trânsito para o servidor nessa conexão.
    • Espera-se que o servidor aceite, no máximo, 32 solicitações em versão piloto do cliente para essa conexão.
  • Conexão 2
    • O cliente emitirá, no máximo, 32 solicitações em trânsito para o servidor nessa conexão.
    • Espera-se que o servidor aceite, no máximo, 32 solicitações em versão piloto do cliente para essa conexão.

Exemplo 3 – 180 max_session_slots e nenhum nconnect

O exemplo 3 remova a opção de montagem nconnect e define o valor max_session_slots como 180, correspondendo à simultaneidade da sessão do NFSv4.1 máxima do servidor. Nesse cenário, com apenas uma conexão e com a operação pendente máxima de 128 do Azure NetApp Files fornecida por conexão NFS, a sessão é limitada a 128 operações em versão piloto.

Embora max_session_slots tenha sido definido como 180, a conexão de rede individual é limitada a, no máximo, 128 solicitações, desta forma:

• 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 versão piloto para o servidor da sessão.
    • O servidor aceitará, no máximo, 180 solicitações em versão piloto do cliente para a sessão.
    • O servidor não aceitará mais de 128 solicitações em versão piloto da única conexão.

Exemplo 4 – 180 max_session_slots e nconnect=2

O exemplo 4 adiciona a opção de montagem nconnect=2 e reutiliza o valor max_session_slots 180. Como a carga de trabalho geral é dividida em duas conexões, 180 operações pendentes podem ser obtidas.

Com duas conexões em execução, a sessão dá suporte à alocação completa 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 mantenha, no máximo, 90 solicitações em versão piloto para o servidor da conexão um.
    • Espera-se que o servidor mantenha, no máximo, 90 solicitações em versão piloto do cliente para essa conexão dentro da sessão.
  • Conexão 2
    • Espera-se que o cliente mantenha, no máximo, 90 solicitações em versão piloto para o servidor da conexão um.
    • Espera-se que o servidor mantenha, no máximo, 90 solicitações em versão piloto do cliente para essa conexão dentro da sessão.

Observação

Para a simultaneidade máxima, defina max_session_slots como 180, que é a simultaneidade máxima no nível de sessão atualmente compatível com o Azure NetApp Files.

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

Para ver os tamanhos session_slot compatíveis com o cliente e o servidor, capture o comando de montagem em um rastreamento de pacote. Procure a chamada CREATE_SESSION e a resposta CREATE_SESSION, conforme mostrado no exemplo a seguir. A chamada foi originada do cliente, e a resposta, do servidor.

Use o seguinte comando tcpdump para capturar o comando de montagem:

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

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

Nesses dois pacotes, examine o campo max_reqs na seção intermediária do arquivo de rastreamento.

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

O Pacote 12 (número máximo de solicitações do cliente) mostra que o cliente tinha um valor max_session_slots igual a 64. Na próxima seção, observe que o servidor dá suporte a uma simultaneidade igual a 180 para a sessão. A sessão acaba negociando o valor inferior dos dois valores fornecidos.

O seguinte exemplo mostra o Pacote 14 (número máximo de solicitações do servidor):

Próximas etapas

• Práticas recomendadas de E/S direta do Linux para o Azure NetApp Files
• Práticas recomendadas de cache do sistema de arquivos do Linux para o Azure NetApp Files
• Melhores práticas de opções de montagem do NFS no Linux para o Azure NetApp Files
• Práticas recomendadas de leitura antecipada do Linux NFS
• Práticas recomendadas de SKUs de máquina virtual do Azure
• Parâmetros de comparação de desempenho para o Linux