Aprimorar o desempenho de compartilhamentos de arquivos NFS do Azure

Este artigo explica como você pode melhorar o desempenho dos compartilhamentos de arquivos do sistema de arquivos de rede (NFS) do Azure.

Aplica-se a

Tipo de compartilhamento de arquivos	SMB	NFS
Compartilhamentos de arquivos padrão (GPv2), LRS/ZRS
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS

Aumentar o tamanho de leitura antecipada para melhorar 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 melhorar 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 pequeno valor pode reduzir a quantidade de taxa de transferência de leitura para arquivos grandes. Os clientes que atualizam de versões do Linux com o valor de leitura antecipada maior para versões com o padrão de 128 KiB podem experimentar uma diminuição no desempenho da leitura sequencial.

Para kernels do Linux 5.4 ou posterior, recomendamos definir persistentemente o read_ahead_kb para 15 MiB para melhorar o 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 tornar o udev ciente do novo arquivo.

   sudo udevadm control --reload
   

Nconnect

Nconnect é uma opção de montagem do Linux do lado do cliente que aumenta o desempenho em escala, permitindo que você use mais conexões TCP (Transmission Control Protocol) entre o cliente e o serviço arquivos Premium do Azure para NFSv4.1.

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). Nconnect aumenta o desempenho usando vários canais TCP em uma ou mais NICs, usando um ou vários clientes. Sem o nconnect, você precisaria de cerca de 20 computadores cliente para atingir os limites de escala de largura de banda (10 GiB/s) oferecidos pelo maior tamanho de provisionamento de compartilhamento de arquivos premium do Azure. Com 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 taxa de transferência em escala. Confira a tabela a seguir.

Métrica (operação)	Tamanho de E/S	Aprimoramento do desempenho
IOPS (gravação)	64K, 1024K	3x
IOPS (leitura)	Todos os tamanhos de E/S	2-4x
Taxa de transferência (gravação)	64K, 1024K	3x
Taxa de transferência (leitura)	Todos os tamanhos de E/S	2-4x

Pré-requisitos

• As distribuições mais recentes do Linux dão suporte total a nconnect. Para distribuições mais antigas do Linux, verifique se a versão do kernel do Linux é 5.3 ou superior.
• A configuração por montagem só tem suporte quando um único compartilhamento de arquivos é usado por conta de armazenamento em um ponto de extremidade privado.

Impacto no desempenho de nconnect

Obtivemos os seguintes resultados de desempenho ao usar a opção nconnect de montagem com compartilhamentos de arquivos NFS do Azure em clientes Linux em escala. Para obter mais informações sobre como alcançamos esses resultados, confira Configuração de teste de desempenho.

Recomendações para nconnect

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

Defina nconnect=4

Embora os Arquivos do Azure deem suporte à configuração nconnect até a configuração máxima de 16, recomendamos definir as opções de montagem com a configuração ideal do nconnect=4. Atualmente, não há ganhos além de quatro canais para a implementação Arquivos do Azure do nconnect. 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 máquinas virtuais (VMs) computadores cliente para evitar a restrição 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 do Nconnect

Se uma carga de trabalho exigir a montagem de vários compartilhamentos com uma ou mais contas de armazenamento com configurações diferentes do nconnect de um único cliente, não podemos garantir que essas configurações persistirão ao montar sobre o ponto de extremidade público. A configuração por montagem só tem suporte quando um único compartilhamento de arquivos do Azure é usado por conta de armazenamento no ponto de extremidade privado, conforme descrito no Cenário 1.

Cenário 1: configuração por montagem do nconnect 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 do nconnect 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

Observação

Mesmo que a conta de armazenamento seja resolvida para um endereço IP diferente, não podemos garantir que o endereço persistirá porque os pontos de extremidade públicos não são endereços estáticos.

Cenário 3: configuração por montagem do nconnect no ponto de extremidade privado com vários compartilhamentos em uma única 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

Usamos os recursos e as ferramentas de parâmetro de comparação a seguir para obter e medir os resultados descritos neste artigo.

• Cliente único: VM do Azure (Série DSv4) com NIC único
• OS: Linux (Ubuntu 20.40)
• Armazenamento NFS: Compartilhamento de arquivos premium dos Arquivos do Azure (30 TiB provisionado, definido nconnect=4)

Tamanho	vCPU	Memória	Armazenamento temporário (SSD)	Discos de dados máximos	Máximo de NICs	Largura de banda da rede esperada
Standard_D16_v4	16	64 GiB	Somente Armazenamento Remoto	32	8	12,500 MBps

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

Usamos o FIO (Testador de E/S Flexível), uma ferramenta de E/S de disco gratuita e de código aberto usada para verificação de estresse/hardware e comparação. Para instalar o FIO, siga a seção "Pacotes binários" no arquivo LEIAME do FIO para instalar a plataforma de sua escolha.

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 64k – 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 1024k – leitura 100% 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 alto: gravações de 100%

Tamanho de E/S de 4k – gravação 100% 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 8k – gravação 100% 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 64k – gravação 100% 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 1024k – gravação 100% 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 de alta escala ou todo o desempenho. O nconnect pode não fazer sentido para cargas de trabalho de menor escala. 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.

Confira também

• Montar um compartilhamento de arquivo NFS para Linux
• Lista de opções de montagem
• Entender o desempenho dos Arquivos do Azure