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

Neste módulo, discutimos as opções de montagem e as configurações de VM cliente que melhoram o desempenho quando você executa aplicativos HPC ou EDA em Arquivos NetApp do Azure.

Use as opções de montagem actimeo e nocto para melhorar o desempenho

Você pode usar as seguintes opções de montagem para melhorar o desempenho em conjuntos de dados relativamente estáticos e cenários de leitura massiva:

• actimeo: Controla os atributos de cache do cliente NFS de um diretório. Se você não especificá-lo, o cliente NFS usará um máximo padrão de 60 segundos.
• nocto: refere-se a "no close-to-open", o que significa que um ficheiro pode ser fechado antes que uma gravação termine, para economizar tempo. Por padrão, nocto não está definido nas opções de montagem NFS. Isso significa que todos os arquivos aguardam para concluir as 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 mudam com frequência). Nesse caso, você pode usar nocto e actimeo para reduzir getattr ou acessar operações de armazenamento, o que pode ajudar a acelerar o aplicativo.

Por exemplo, recomendamos definir "nocto,actimeo=600" (600 segundos ou 10 minutos) para ferramentas EDA e volumes de biblioteca. Como esses arquivos não estão mudando, não há coerência de cache para manter. Definir essas opções de montagem reduz as chamadas de metadados, o que melhora o desempenho geral.

Ajuste os parâmetros do sistema para um desempenho ideal

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

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

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

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

#
# 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 NFS nconnect tornou-se disponível de forma geral no kernel Linux 5.3 ou posterior. Para verificar o kernel Linux da VM cliente, execute:

uname -r

O objetivo do 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 para montagens NFS.

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

Como os Arquivos NetApp do Azure permitem um máximo de 128 solicitações simultâneas em voo por conexão TCP antes que uma limitação seja incorrida (onde novas solicitações são enfileiradas até que os recursos sejam disponibilizados), nconnect pode ajudar a estender o número de solicitações em voo permitidas aumentando as conexões TCP disponíveis por ponto de montagem. Por exemplo, se nconnect estiver definido para usar oito conexões TCP, 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 potencialmente invadir a fila de solicitações em voo disponível 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 orientação.

Use NFSv3 em vez de NFSv4.1 quando estiver considerando apenas o desempenho

O NFSv3 é um protocolo sem monitoração de 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 antigos e devem ser removidos manualmente. Os bloqueios só são estabelecidos 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 cliente, IDs de estado, IDs de sessão, estados de bloqueio, etc. para acompanhar, o NFSv3 tende a ter um desempenho um pouco melhor do que o NFSv4.1 em algumas cargas de trabalho - particularmente em cargas de trabalho de alta contagem de arquivos/metadados altos, como EDA e desenvolvimento de software.

O NFSv4.1 controla os estados dos ficheiros, incluindo bloqueios. Quando muitos arquivos estão em uso ao mesmo tempo no NFSv4.1, cada arquivo recebe um ID de estado e recebe um bloqueio. Ser stateful 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 veem degradação de desempenho ao usar o NFSv4.1 e podem até se beneficiar das operações compostas usadas pelo protocolo.

Os Arquivos NetApp do Azure dão suporte a NFSv3 e NFSv4.1. Você deve validar qual versão sua aplicação requer, comparando as semelhanças e diferenças entre as versões NFS (bem como realizando testes) e criando o seu volume usando a versão correta. Se necessário, os volumes dos Arquivos NetApp do Azure 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 enviados entre o cliente NFS e o servidor para cada pacote enviado. Por exemplo, definir rsize ou wsize para 65.536 significa que até 64 K de dados podem ser enviados por pacote. Se um aplicativo envia dados em partes menores (como 8 K), a quantidade de dados enviados depende das opções de montagem usadas (como sync).

A prática recomendada para os Arquivos NetApp do Azure é definir rsize e wsize com o mesmo valor. Geralmente, recomendamos que você defina os valores rsize e wsize como 262144 (256 K) nas opções de montagem.

Compreender as opções de sincronização e montagem assíncrona

Se sync for usado, cada chamada de WRITE será enviada com um comando FILE_SYNC. Isso significa que cada WRITE deve ser reconhecido pelo servidor e confirmado no disco antes que o próximo WRITE possa ocorrer. Sync é usado quando um aplicativo deve garantir que todos os dados sejam confirmados no disco. WRITE chamadas enviam apenas a quantidade de dados especificada pelo tamanho do bloco do aplicativo, o que significa que tamanhos de bloco menores geram mais tráfego NFS, independentemente dos valores de wsize e rsize da montagem, causando um impacto no desempenho.

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

Por exemplo, num teste em que um arquivo de 1 GiB foi criado usando um tamanho de bloco de 8 K gerou 262.144 WRITE chamadas e respostas e terminou em 70 segundos ao usar a opção de montagem sync. A mesma criação de ficheiro, utilizando um tamanho de bloco de 8K e a opção de montagem async, enviou apenas 16.384 chamadas e respostas WRITE, concluindo-se em seis segundos.

Os Arquivos NetApp do Azure usam 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 dados, como o evento improvável de um datacenter do Azure perder energia. A combinação da resiliência de dados dos Arquivos NetApp do Azure e o impacto no desempenho da utilização da opção de montagem sync torna a opção assíncrona a escolha preferida em quase todos os casos de uso.

Compreender o impacto dos valores de wsize e rsize

Ao montar através de NFS, os valores wsize e rsize determinam quanta informação pode ser enviada por chamada NFS para um servidor NFS. Se não especificado nas opções de montagem, os valores são definidos para o que o servidor NFS foi configurado. Os Arquivos NetApp do Azure usam um tamanho máximo de transferência para wsize e rsize de 1 MB (1048576). Esse valor não pode ser alterado nos Arquivos NetApp do Azure. Isso significa que, se as montagens NFS não especificarem os valores de wsize e rsize, o padrão será de 1 MB. Os valores de wsize e rsize recomendados para montagens NFS em cargas de trabalho EDA são 256 KB.

Se um aplicativo precisar criar um arquivo de 1 GiB em uma montagem NFS do Azure NetApp Files, ele precisará gravar 1048.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 o wsize estiver definido como 64 K, o número de operações/pacotes necessários para gravar o arquivo de 1 GiB será 1048576/64=16384.
• Se o wsize estiver definido como 256 K, o número de operações/pacotes necessários para gravar o arquivo de 1 GiB será 1048576/256=4096.

Menos pacotes/operações significam latência de rede (o que afeta o RTT) e menos impacto nas cargas de trabalho, o que pode ser crítico em implantações em nuvem. No entanto, se o aplicativo grava arquivos menores do que os valores wsize/rsize, os valores de wsize/rsize maiores não têm efeito sobre o desempenho.

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

A prática recomendada para os Arquivos NetApp do Azure é definir rsize e wsize com o mesmo valor. É recomendável definir os valores rsize e wsize como 262144 (256K) nas opções de montagem. Essa configuração abrange uma matriz de valores de tamanho de leitura e gravação do aplicativo.

Escolha as configurações adequadas para as opções de montagem rígida, suave e intr.

As opções de montagem hard e soft especificam se o programa que está usando um arquivo que usa 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 apresenta-se como um ponto de montagem no cliente, mas garante que as operações em voo não sejam perdidas em caso de interrupções na rede. Em vez disso, o cliente continua tentando novamente a solicitação até que o servidor esteja disponível ou até que o aplicativo atinja o tempo limite.
• Comunicar um erro (soft). Os dispositivos de montagem não falham, mas as operações em curso podem ser perdidas.

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

Considere não mudar os MTUs

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

Exemplo de montagem

O código de exemplo a seguir montaria um volume de Arquivos NetApp do Azure usando as práticas recomendadas anteriores para actimeo, nocto, NFSv3, nconnect, rsize, wsize, hard, intr, tcpe 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