Opções de montagem e configurações da VM do cliente

Concluído

Neste módulo, discutiremos as opções de montagem e as configurações de VM do cliente que aprimoram o desempenho quando você executa aplicativos de HPC ou EDA no Azure NetApp Files.

Observação

As melhores práticas para clientes NFS dependem dos aplicativos que estão sendo usados. As sugestões a seguir não são absolutas e podem ser substituídas por recomendações de aplicativo ou por testes de carga de trabalho. Recomendamos expressamente testar essas práticas antes de implantá-las em produção.

Usar opções de montagem actimeo e nocto para aprimorar o desempenho

Use as seguintes opções de montagem para aprimorar o desempenho em conjuntos de dados relativamente estáticos e cenários de leitura em massa:

• actimeo: controla os atributos de cache do cliente NFS de um diretório. Se você não especificar, o cliente NFS usará um máximo padrão de 60 segundos.
• nocto: é acrônimo de "no close-to-open", o que significa que um arquivo pode ser fechado antes da conclusão de uma gravação para economizar tempo. Por padrão, nocto não está definido nas opções de montagem do NFS. Isso significa que todos os arquivos aguardam a conclusão das gravações antes de permitir um fechamento.

A maioria dos aplicativos HPC, incluindo EDA em nosso cenário, tem conjuntos de dados relativamente estáticos (o que significa que os dados não são alterados com frequência). Nesse caso, é possível usar nocto e actimeo para reduzir getattr ou operações de acesso ao armazenamento, o que pode ajudar a acelerar o aplicativo.

Por exemplo, recomendamos a configuração "nocto,actimeo=600" (600 segundos ou 10 minutos) para ferramentas EDA e volumes de biblioteca. Como esses arquivos não serão alterados, não haverá nenhuma coerência de cache a ser mantida. A definição dessas opções de montagem reduz as chamadas de metadados, o que melhora o desempenho geral.

Ajustar os parâmetros do sistema para obter o desempenho ideal

Tuned é um daemon que pode ser usado para monitorar e configurar dispositivos conectados em clientes Linux. Na maioria dos casos, o tuned está instalado por padrão. Se não estiver instalado, ele poderá ser adicionado e habilitado para simplificar os parâmetros de ajuste do lado do cliente com modelos padrão internos.

Execute os seguintes comandos para aplicar o ajuste básico do servidor e o ajuste típico de latência para suas VMs do cliente:

sudo systemctl enable --now tuned
sudo tuned-adm profile latency-performance

Alguns ou todos os parâmetros do sistema a seguir (/etc/sysctl.conf) podem ser úteis em VMs do cliente Linux para atingir um desempenho ideal. Se você tiver VMs do cliente com grandes quantidades de RAM ou uma largura de banda de rede maior como o InfiniBand, o ideal será definir alguns valores ainda maiores do que os mostrados no exemplo a seguir.

#
# Recommended client tuning 
#
# For more information, see sysctl.conf(5) and sysctl.d(5)
# Network parameters, in units of bytes
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.ipv4.tcp_rmem = 1048576 8388608 16777216
net.ipv4.tcp_wmem = 1048576 8388608 16777216
net.core.optmem_max = 2048000
net.core.somaxconn = 65535
#
# These settings are in 4-KiB chunks, in bytes:
# Min=16MiB, Def=350MiB, Max=16GiB
# In units of 4K pages
net.ipv4.tcp_mem = 4096 89600 4194304
#
# Miscellaneous network options and flags
#
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_sack = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_low_latency = 1
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_slow_start_after_idle = 0
net.core.netdev_max_backlog = 300000
#
# Various file system and page cache options
#
vm.dirty_expire_centisecs = 100
vm.dirty_writeback_centisecs = 100
vm.dirty_ratio = 20
vm.dirty_background_ratio = 5
#
# Recommended by: https://cromwell-intl.com/open-source/performance-tuning/tcp.html
#
net.ipv4.tcp_sack = 0
net.ipv4.tcp_dsack = 0
net.ipv4.tcp_fack = 0

Para tornar esses ajustes persistentes, execute:

sudo sysctl -P

Use a opção de montagem nconnect para expandir as conexões de rede, quando aplicável

A opção de montagem nconnect do NFS entrou em disponibilidade geral no kernel 5.3 ou posterior do Linux. Para verificar o kernel do Linux da VM do cliente, execute:

uname -r

A finalidade de nconnect é fornecer várias conexões de transporte por conexão TCP ou pontos de montagem em um cliente. Essa técnica ajuda a aumentar o paralelismo e o desempenho das montagens NFS.

Quanto menor o número de clientes, mais valor o nconnect oferece para ajudar a aumentar o desempenho, pois ele pode utilizar toda a largura de banda de rede disponível. Seu valor diminui gradualmente quando o número de clientes aumenta; há apenas uma certa quantidade de largura de banda no total para ser utilizada, e o número máximo de conexões TCP pode se esgotar mais rapidamente, o que pode resultar em negação de serviço até que as conexões TCP sejam liberadas.

Como o Azure NetApp Files permite um máximo de 128 solicitações simultâneas em andamento por conexão TCP antes que ocorra uma restrição (em que novas solicitações são enfileiradas até que os recursos sejam disponibilizados), nconnect pode ajudar a estender o número de solicitações em andamento permitidas aumentando as conexões TCP disponíveis por ponto de montagem. Por exemplo, se nconnect for definido para usar oito conexões TCP, então 1.024 (8x128) solicitações estarão potencialmente disponíveis para o cliente.

Os clientes Linux modernos permitem até 65.535 solicitações por conexão (um valor dinâmico). Isso pode sobrecarregar a fila de solicitações disponíveis em voo de um volume do Azure NetApp Files e levar a resultados de desempenho indesejáveis, em que os clientes enviam mais solicitações do que podem ser atendidas em um determinado momento. Para reduzir o risco de impacto no desempenho devido a esse comportamento, considere definir sunrpc.tpc_max_slot_table_entries=256 ou 512 se estiver usando nconnect=8 ou 16 para um valor estático mais baixo. Use a tabela a seguir como guia.

Observação

Diferentes tipos de SO cliente Linux podem ter métodos diferentes para definir esse valor. Consulte a documentação do SO para obter detalhes.

nconnect valor	Entradas recomendadas da tabela de slots máximos de TCP
0-1	128
2 a 4	256
6-8	512
>8	Nenhuma alteração necessária

Observação

A opção nconnect está disponível apenas para as VMs com kernel 5.3 e posterior no Linux. Talvez seja necessário reiniciar a VM ao atualizar o kernel. Isso significa que ele pode não ser aplicável a alguns casos.

Use o NFSv3 em vez do NFSv4.1 quando considerar apenas o desempenho

O NFSv3 é um protocolo sem estado, o que significa que o cliente e o servidor não se comunicam entre si sobre os arquivos em uso. O bloqueio é realizado fora da pilha de protocolos pelo Network Lock Manager (NLM), o que apresenta alguns desafios quando os bloqueios se tornam obsoletos e precisam ser limpos manualmente. Os bloqueios são estabelecidos somente mediante solicitação do aplicativo, portanto, pode haver cenários em que os bloqueios não precisem ser negociados. Como não há IDs de clientes, IDs de estados, IDs de sessões, estados de bloqueios etc. para controlar, o NFSv3 tende a ter um desempenho um pouco melhor do que o NFSv4.1 em algumas cargas de trabalho, principalmente em cargas de trabalho com alto número de arquivos/alto número de metadados, como EDA e desenvolvimento de software.

O NFSv4.1 mantém o controle dos estados dos arquivos, incluindo bloqueios. Quando muitos arquivos estão em uso ao mesmo tempo no NFSv4.1, para cada arquivo é atribuído uma ID de estado e o recebimento um bloqueio. O fato de ser estado adiciona sobrecarga ao desempenho da carga de trabalho, pois cada estado e bloqueio deve ser processado pelo servidor NFS. Em algumas cargas de trabalho (como EDA), o desempenho do NFSv4.1 pode ser afetado de 25% a 75%. Outras cargas de trabalho, como arquivos grandes, E/S de streaming ou bancos de dados, não sofrem degradação de desempenho ao usar o NFSv4.1 e podem até se beneficiar das operações compostas usadas pelo protocolo.

O Azure NetApp Files dá suporte ao NFSv3 e ao NFSv4.1. Você deve validar qual versão seu aplicativo requer, comparando as semelhanças e diferenças entre as versões do NFS (bem como testando) e criando seu volume usando a versão apropriada. Se necessário, os volumes do Azure NetApp Files podem ser configurados para uma versão de protocolo diferente após a criação.

Escolha os valores adequados para as opções de montagem rsize e wsize

As opções de montagem rsize (tamanho de leitura) e wsize (tamanho de gravação) determinam a quantidade de dados que é enviada entre o cliente e o servidor NFS para cada pacote enviado. Por exemplo, definir rsize ou wsize como 65.536 significa que até 64 K de dados podem ser enviados por pacote. Se um aplicativo enviar dados em blocos menores (como 8 K), a quantidade de dados enviada dependerá das opções de montagem usadas (como sync).

A melhor prática para o Azure NetApp Files é definir rsize e wsize com o mesmo valor. Geralmente, recomendamos definir os valores de rsize e wsize como 262144 (256 K) nas opções de montagem.

Entenda as opções de montagem síncrona e assíncrona

Se sync for usado, cada chamada WRITE será enviada com um comando FILE_SYNC. Isso significa que cada GRAVAÇÃO deve ser reconhecida pelo servidor e confirmada no disco antes que a próxima WRITE possa ocorrer. Sync é usado quando um aplicativo precisa garantir que todos os dados sejam confirmados no disco. As chamadas WRITE enviam somente a quantidade de dados especificada pelo tamanho do bloco do aplicativo, o que significa que blocos de tamanho menor geram mais tráfego NFS, independentemente dos valores wsize e rsize da montagem, causando impacto no desempenho.

Se você usar a operação de montagem async (padrão), um cliente poderá enviar várias chamadas WRITE por NFS com o comando UNSTABLE. Nesse cenário, os dados são descarregados no disco após um período de tempo limite. Como o cliente NFS não está sempre esperando que o servidor confirme os dados no disco antes de iniciar a próxima GRAVAÇÃO, o tempo de conclusão do trabalho para gravações em montagens assíncronas é muito menor do que com a síncrona. Quando tamanhos de bloco menores são usados com valores rsize e wsize maiores, as chamadas WRITE enviam o máximo de dados permitido em uma única chamada NFS. Por exemplo, se forem usados tamanhos de bloco de 8 K com 64 K wsize/rsize, cada chamada de GRAVAÇÃO do NFS enviará oito blocos por pacote (64 K/8 K). Quando a gravação é descarregada no disco, o servidor NFS envia uma resposta FILE_SYNC de volta ao cliente NFS. Isso reduz o número total de chamadas WRITE e respostas em uma rede necessárias para concluir um trabalho, o que melhora o desempenho.

Por exemplo, em um teste em que um arquivo de 1 GB foi criado usando um tamanho de bloco de 8 K, foram geradas 262.144 chamadas e respostas WRITE e o trabalho foi concluído em 70 segundos com o uso da opção de montagem sync. A mesma criação de arquivo usando um tamanho de bloco de 8 K e a opção de montagem async enviou apenas 16.384 chamadas e respostas de GRAVAÇÃO, concluindo em seis segundos.

O Azure NetApp Files usa o armazenamento NVRAM com bateria como um cache de buffer para gravações NFS de entrada. Os dados na NVRAM são liberados para o disco a cada 10 segundos ou até que o cache do buffer seja preenchido (o que ocorrer primeiro). Como a NVRAM é apoiada por uma bateria, ela pode sobreviver a interrupções inesperadas por um mínimo de 72 horas enquanto retém os dados, como no caso improvável de um data center do Azure ficar sem energia. A combinação da resiliência de dados do Azure NetApp Files com o impacto no desempenho do uso da opção de montagem sync faz com que a assíncrona seja a escolha preferida em quase todos os casos de uso.

Entenda o impacto dos valores wsize e rsize

Ao montar por NFS, os valores wsize e rsize determinam a quantidade de dados que pode ser enviada por chamada NFS para um servidor NFS. Se não forem especificados nas opções de montagem, os valores serão definidos de acordo com o que o servidor NFS tiver sido configurado. O Azure NetApp Files usa um tamanho máximo de transferência para wsize e rsize de 1 MB (1.048.576). Esse valor não pode ser alterado no Azure NetApp Files. Isso significa que, se as montagens NFS não especificarem os valores wsize e rsize, o padrão das montagens será 1 MB. Os valores wsize e rsize recomendados para montagens NFS em cargas de trabalho EDA são 256 K.

Se um aplicativo precisar criar um arquivo de 1 GB em uma montagem NFS do Azure NetApp Files, ele precisará gravar 1.048.576 KiB no armazenamento. Um exercício de matemática pode mostrar por que o desempenho pode melhorar com valores wsize ou rsize mais eficientes.

• Se wsize for definido como 64 K, o número de operações/pacotes necessários para gravar o arquivo de 1 GB será 1.048.576/64=16.384.
• Se wsize for definido como 256 K, o número de operações/pacotes necessários para gravar o arquivo de 1 GB será 1.048.576/256=4.096.

Menos pacotes/operações significam que a latência da rede (que afeta o RTT) tem menos impacto sobre as cargas de trabalho, o que pode ser fundamental em implantações de nuvem. No entanto, se o aplicativo gravar arquivos menores que os valores wsize/rsize, os valores maiores wsize/rsize não afetarão o desempenho.

Partes maiores de dados significam mais ciclos de processamento no cliente e no servidor, mas a maioria das CPUs modernas está suficientemente equipada para lidar com essas solicitações de forma eficiente.

A melhor prática para o Azure NetApp Files é definir rsize e wsize com o mesmo valor. Recomenda-se que você defina os valores rsize e wsize como 262.144 (256K) nas opções de montagem. Essa configuração abrange uma matriz de valores de tamanho de leitura e gravação de aplicativos.

Escolha as configurações adequadas para as opções de montagem hard, soft e intr

As opções de montagem hard e soft especificam se o programa que está usando um arquivo que usa o NFS deve executar uma das seguintes ações:

• Pare e aguarde (hard) para que o servidor volte a ficar online se o servidor NFS não estiver disponível. Essa opção aparece como uma pendência de montagem no cliente, mas garante que as operações em andamento não sejam perdidas no caso de interrupções na rede. Em vez disso, o cliente continua repetindo a solicitação até que o servidor esteja disponível ou até o aplicativo atingir o tempo limite.
• Relate um erro (soft). As montagens não ficam pendentes, mas as operações em andamento podem ser perdidas.

A opção de montagem intr permite que os processos NFS sejam interrompidos quando uma montagem é especificada como hard (como CTRL+C). Recomendamos o uso de intr com montagens hard quando aplicável para obter a melhor combinação de confiabilidade de dados e capacidade de gerenciamento.

Não considere nenhuma mudança de MTUs

As MTUs (unidades máximas de transmissão) padrão para as VMs do Azure são de 1.500 bytes. Não incentivamos os clientes a aumentar as MTUs das VMs para quadros jumbo.

Exemplo de montagem

O seguinte código de exemplo monta um volume do Azure NetApp Files usando as melhores práticas anteriores para actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcp e MTUs padrão (1.500):

sudo mount -t nfs -o rw,nconnect=16,nocto,actimeo=600,hard,intr,rsize=262144,wsize=262144,vers=3,tcp 10.1.x.x:/ultravol ultravol

Observação

Async não é especificado, pois as montagens NFS têm como padrão async.