Aprimorar o desempenho de compartilhamentos de arquivos NFS do Azure

Aplica-se a: ✔️ Compartilhamentos de arquivos NFS

Este artigo apresenta várias formas de melhorar o desempenho dos compartilhamentos de arquivos Azure do sistema de arquivos de rede (NFS). Os tópicos incluem configurar o parâmetro do kernel do Linux read_ahead_kb para obter melhor vazão de leitura sequencial, usar a opção de montagem nconnect para aumentar a vazão com menos máquinas cliente e colocar sua conta de armazenamento na mesma zona de disponibilidade que os clientes para reduzir a latência.

Aumentar o tamanho de leitura antecipada para aprimorar a taxa de transferência de leitura

O parâmetro do kernel read_ahead_kb no Linux representa a quantidade de dados que deve ser "lida antecipadamente" ou pré-buscada durante uma operação de leitura sequencial. As versões do kernel do Linux anteriores à 5.4 definem o valor de leitura antecipada como o equivalente a 15 vezes o rsize do sistema de arquivos montado que representam a opção de montagem do lado do cliente para o tamanho do buffer de leitura. Isso define um valor suficientemente alto de leitura antecipada para aprimorar a taxa de transferência de leitura sequencial do cliente na maioria dos casos.

No entanto, começando com o kernel do Linux versão 5.4, o cliente NFS do Linux usa um valor padrão read_ahead_kb de 128 KiB. Esse valor menor pode reduzir a quantidade de throughput de leitura para arquivos grandes. Usuários que fazem upgrade de versões Linux com maior valor de leitura antecipada para versões com padrão de 128 KiB podem experimentar uma queda no desempenho de leitura sequencial.

Para kernels do Linux 5.4 ou posteriores, defina persistentemente read_ahead_kb para 15 MiB para obter melhor desempenho.

Para alterar esse valor, defina o tamanho de leitura antecipada adicionando uma regra no udev, um gerenciador de dispositivos do kernel do Linux. Siga estas etapas:

1. Em um editor de texto, crie o arquivo /etc/udev/rules.d/99-nfs.rules inserindo e salvando o seguinte texto:

   SUBSYSTEM=="bdi" \
   , ACTION=="add" \
   , PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
   , ATTR{read_ahead_kb}="15360"
   

2. Em um console, aplique a regra udev executando o comando udevadm como um superusuário e recarregando os arquivos de regras e outros bancos de dados. Você só precisa executar esse comando uma vez para alertar o udev sobre o novo arquivo.

   sudo udevadm control --reload
   

nconnect do NFS

NFS nconnect é uma opção de montagem do lado do cliente para compartilhamentos de arquivos NFS que você usa para criar múltiplas conexões TCP entre o cliente e seu compartilhamento de arquivos NFS. É particularmente útil para cargas de trabalho em grande escala onde uma única conexão TCP se torna um gargalo.

Benefícios do nconnect

Com o nconnect, você pode aumentar o desempenho em escala usando menos computadores cliente para reduzir o TCO (custo total de propriedade). O recurso nconnect aumenta o desempenho usando vários canais TCP em um ou mais NICs, usando um ou vários clientes. Sem o nconnect, você precisa de cerca de 20 máquinas clientes para atingir os limites de largura de banda (10 GiB/s) oferecidos pelo maior tamanho de provisionamento de compartilhamento de arquivos SSD. Com o nconnect, você pode atingir esses limites usando apenas 6 a 7 clientes, reduzindo os custos de computação em quase 70% ao mesmo tempo em que fornece melhorias significativas nas operações de E/S por segundo (IOPS) e na taxa de transferência em escala. Confira a tabela a seguir.

Pré-requisitos do nconnect

• As distribuições mais recentes do Linux dão suporte total à nconnect. Para distribuições mais antigas do Linux, verifique se a versão do kernel do Linux é 5.3 ou superior.
• Só há suporte para a configuração por montagem quando um compartilhamento de arquivo individual é usado por conta de armazenamento em um ponto de extremidade privado.

Impacto sobre o desempenho

Os seguintes resultados de desempenho foram medidos usando a opção de montagem nconnect com compartilhamentos de arquivos NFS Azure em clientes Linux em larga escala. Para mais informações sobre como esses resultados foram alcançados, veja configuração do teste de desempenho.

Recomendações de nconnect

Siga estas recomendações para obter os melhores resultados do nconnect.

Pôr nconnect=4

Embora o Arquivos do Azure suporte configurar nconnect até a configuração máxima de 16, configure as opções de montagem com a configuração ótima de nconnect=4. Atualmente, não há ganhos além de quatro canais para a implementação do nconnect nos Arquivos do Azure. Na verdade, exceder quatro canais para um único compartilhamento de arquivos do Azure de um único cliente pode afetar negativamente o desempenho devido à saturação de rede TCP.

Dimensionar máquinas virtuais cuidadosamente

Dependendo dos requisitos de carga de trabalho, é importante dimensionar corretamente as VMs (máquinas virtuais) do cliente para evitar ser restringida pela largura de banda de rede esperada. Você não precisa de várias controladores de interface de rede (NICs) para obter a taxa de transferência de rede esperada. Embora seja comum usar VMs de uso geral com Arquivos do Azure, vários tipos de VM estão disponíveis dependendo das suas necessidades de carga de trabalho e da disponibilidade da região. Para obter mais informações, confira Seletor da VM do Azure.

Manter a profundidade da fila menor ou igual a 64

Profundidade da fila é o número de solicitações de E/S pendentes às quais um recurso de armazenamento pode atender. Não recomendamos exceder a profundidade ideal da fila de 64 porque você não verá mais ganhos de desempenho. Para obter mais informações, confira Profundidade da fila.

Configuração por montagem

Se uma carga de trabalho exigir montar múltiplos compartilhamentos com uma ou mais contas de armazenamento com diferentes configurações de nconnect a partir de um único cliente, as configurações não têm garantia de persistir ao montar sobre o endpoint público. Configuração por montagem suporta apenas um único compartilhamento de arquivos Azure por conta de armazenamento sobre o endpoint privado, conforme descrito no Cenário 1.

Cenário 1: configuração por montagem no ponto de extremidade privado com várias contas de armazenamento (com suporte)

• StorageAccount.file.core.windows.net = 10.10.10.10
• StorageAccount2.file.core.windows.net = 10.10.10.11
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Cenário 2: configuração por montagem no ponto de extremidade público (sem suporte)

• StorageAccount.file.core.windows.net = 52.239.238,8
• StorageAccount2.file.core.windows.net = 52.239.238,7
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount2.file.core.windows.net:/StorageAccount2/FileShare1

Cenário 3: configuração por montagem no ponto de extremidade privado com vários compartilhamentos em uma só conta de armazenamento (sem suporte)

• StorageAccount.file.core.windows.net = 10.10.10.10
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare1 nconnect=4
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare2
  • Mount StorageAccount.file.core.windows.net:/StorageAccount/FileShare3

Configuração de teste de desempenho

Para alcançar e medir os resultados apresentados neste artigo, utilize os seguintes recursos e ferramentas de benchmarking.

• Cliente único: VM do Azure (Série DSv4) com NIC único
• SO: Linux (Ubuntu 20.04)
• Armazenamento NFS: compartilhamento de arquivos SSD (provisionado 30 TiB, definido nconnect=4)

Ferramentas e testes de parâmetros de comparação

Esses testes utilizam o Flexible I/O Tester (FIO), uma ferramenta gratuita e de código aberto de I/O de disco, usada tanto para benchmarking quanto para verificação de estresse ou hardware. Para instalar o FIO, veja a seção Pacotes Binários no arquivo FIO README e siga as instruções da plataforma que você escolher.

Embora esses testes se concentrem em padrões de acesso de E/S aleatórios, você obtém resultados semelhantes ao usar E/S sequencial.

IOPS alta: leituras de 100%

Tamanho de E/S de 4k – Leitura aleatória – Profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Tamanho de E/S de 8k – leitura aleatória – profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Alta taxa de transferência: leituras de 100%

Tamanho de E/S de 64 KiB – Leitura aleatória – Profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

Tamanho de E/S de 1.024 KiB – 100% de leitura aleatória – Profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randread --group_reporting --ramp_time=300

IOPS alta: gravações de 100%

Tamanho de E/S de 4 KiB – 100 % de gravação aleatória – Profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=4k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Tamanho de E/S de 8 KiB – 100 % de gravação aleatória – Profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=8k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Alta taxa de transferência: 100% de gravações

Tamanho de E/S de 64 KiB – 100 % de gravação aleatória – Profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=64k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Tamanho de E/S de 1024 KiB – 100 % de gravação aleatória – Profundidade da fila de 64

fio --ioengine=libaio --direct=1 --nrfiles=4 --numjobs=1 --runtime=1800 --time_based --bs=1024k --iodepth=64 --filesize=4G --rw=randwrite --group_reporting --ramp_time=300

Considerações de desempenho para nconnect

Ao usar a opção de montagem do nconnect, você deve avaliar de perto as cargas de trabalho que têm as seguintes características:

• Cargas de trabalho de gravação sensíveis à latência que têm thread único e/ou usam uma profundidade de fila baixa (menos de 16)
• Cargas de trabalho de leitura sensíveis à latência que têm thread único e/ou usam uma profundidade de fila baixa em combinação com tamanhos menores de E/S

Nem todas as cargas de trabalho exigem IOPS em alta escala ou desempenho de throughput. Para cargas de trabalho menores, nconnect pode não ser benéfico. Use a tabela a seguir para decidir se o nconnect será vantajoso para sua carga de trabalho. Cenários realçados em verde são recomendados, enquanto os realçados em vermelho não são. Os cenários realçados em amarelo são neutros.

Usar o posicionamento zonal

Para compartilhamentos de arquivos clássicos criados com o provedor de recursos Microsoft.Storage, é recomendável usar o posicionamento zonal para selecionar a zona de disponibilidade específica na qual sua conta de armazenamento reside. Isso permite que você coloque suas VMs na mesma zona de disponibilidade do armazenamento, o que pode reduzir a latência em até 30%. No momento, esse recurso está disponível apenas para contas de armazenamento SSD usando LRS (armazenamento com redundância local) em regiões com suporte.

Confira também

• Montar compartilhamento de arquivos NFS no Linux
• Lista de opções de montagem
• Entender o desempenho dos Arquivos do Azure