Melhorar o desempenho do compartilhamento de arquivos do Azure NFS

Este artigo explica como você pode melhorar o desempenho para compartilhamentos de arquivos do Azure NFS.

Aplica-se a

Tipo de partilhas de ficheiros	SMB	NFS
Partilhas de ficheiros Standard (GPv2), LRS/ZRS
Partilhas de ficheiros Standard (GPv2), GRS/GZRS
Partilhas de ficheiros Premium (FileStorage), LRS/ZRS

Aumente o tamanho da leitura antecipada para melhorar a taxa de transferência de leitura

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

No entanto, a partir da versão 5.4 do kernel Linux, o cliente NFS 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 maior valor de leitura antecipada para aqueles com o padrão de 128 KiB podem experimentar uma diminuição no desempenho de leitura sequencial.

Para kernels Linux 5.4 ou posteriores, recomendamos definir persistentemente o para 15 MiB para melhorar o read_ahead_kb desempenho.

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

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 este comando uma vez, para tornar o udev ciente do novo arquivo.

   sudo udevadm control --reload
   

Nconnect

Nconnect é uma opção de montagem Linux do lado do cliente que aumenta o desempenho em escala, permitindo que você use mais conexões TCP entre o cliente e o serviço Azure Premium Files para NFSv4.1, mantendo a resiliência da plataforma como serviço (PaaS).

Benefícios da nconnect

Com nconnecto , você pode aumentar o desempenho em escala usando menos máquinas cliente para reduzir o custo total de propriedade (TCO). Nconnect aumenta o desempenho usando vários canais TCP em uma ou mais NICs, usando um ou vários clientes. Sem nconnecto , você precisaria de cerca de 20 máquinas 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 nconnecto , você pode atingir esses limites usando apenas 6-7 clientes. Isso representa uma redução de quase 70% no custo de computação, ao mesmo tempo em que fornece melhorias significativas para IOPS e taxa de transferência em escala (veja a tabela).

Métrica (operação)	Tamanho de E/S	Melhoria do desempenho
IOPS (gravação)	64K, 1024K	3x
IOPS (ler)	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 mais recentes distribuições Linux suportam totalmente o nconnect. Para distribuições Linux mais antigas, certifique-se de que a versão do kernel Linux é 5.3 ou superior.
• A configuração por montagem só é suportada 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 nconnect opção de montagem com compartilhamentos de arquivos do Azure NFS em clientes Linux em escala. Para obter mais informações sobre como obtivemos esses resultados, consulte Configuração do teste de desempenho.

Recomendações para nconnect

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

Conjunto nconnect=4

Embora os Arquivos do Azure ofereçam suporte à configuração nconnect máxima de 16, recomendamos configurar as opções de montagem com a configuração ideal de nconnect=4. Atualmente, não há ganhos além de quatro canais para a implementação do Azure Files 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 da rede TCP.

Dimensione máquinas virtuais com cuidado

Dependendo dos requisitos de carga de trabalho, é importante dimensionar corretamente as máquinas clientes para evitar ser restringido pela largura de banda de rede esperada. Você não precisa de várias NICs para atingir 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, consulte Azure VM Seletor.

Manter a profundidade da fila menor ou igual a 64

A profundidade da fila é o número de solicitações de E/S pendentes que um recurso de armazenamento pode atender. Não recomendamos exceder a profundidade ideal da fila de 64. Se o fizer, não verá mais ganhos de desempenho. Para obter mais informações, consulte Profundidade da fila.

Nconnect configuração por montagem

Se uma carga de trabalho exigir a montagem de vários compartilhamentos com uma ou mais contas de armazenamento com configurações diferentes nconnect de um único cliente, não podemos garantir que essas configurações persistirão durante a montagem sobre o ponto de extremidade público. A configuração por montagem só é suportada 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 (suportada) nconnect sobre ponto de extremidade privado com várias contas de armazenamento

• 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 (não suportada) nconnect sobre ponto de extremidade público

• 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

Nota

Mesmo que a conta de armazenamento seja resolvida para um endereço IP diferente, não podemos garantir que esse 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 (não suportada) nconnect sobre ponto de extremidade privado com vários compartilhamentos em uma única conta de armazenamento

• 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

Utilizamos os seguintes recursos e ferramentas de benchmarking para alcançar e medir os resultados descritos neste artigo.

• Cliente único: Máquina Virtual do Azure (DSv4-Series) com NIC única
• SO: Linux (Ubuntu 20.40)
• Armazenamento NFS: compartilhamento de arquivos premium do Azure Files (provisionado 30 TiB, definido nconnect=4)

Tamanho	vCPU	Memória	Armazenamento temporário (SSD)	Máximo de discos de dados	Máximo de NICs	Largura de banda da rede esperada
Standard_D16_v4	17	64 GiB	Apenas armazenamento remoto	32	8	12.500 Mbps

Ferramentas e testes de avaliação comparativa

Usamos o Flexible I/O Tester (FIO), uma ferramenta de E/S de disco gratuita e de código aberto usada tanto para benchmark quanto para verificação de estresse/hardware. Para instalar o FIO, siga a seção Pacotes binários no arquivo FIO README para instalar na 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 alto: 100% de leituras

Tamanho de E/S 4k - leitura aleatória - profundidade da fila 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: 100% leituras

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 aleatória de 100% - 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: 100% gravações

Tamanho de E/S 4k - gravação 100% aleatória - profundidade da fila 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% 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 nconnect opção de montagem, 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 são de thread único e/ou usam uma profundidade de fila baixa (menos de 16)
• Cargas de trabalho de leitura sensíveis à latência que são de thread único e/ou usam uma profundidade de fila baixa em combinação com tamanhos de E/S menores

Nem todas as cargas de trabalho exigem IOPS de alta escala ou durante todo o desempenho. Para cargas de trabalho de menor escala, nconnect pode não fazer sentido. Use a tabela a seguir para decidir se nconnect será vantajoso para sua carga de trabalho. Cenários destacados em verde são recomendados, enquanto aqueles destacados em vermelho não são. Os destacados a amarelo são neutros.

Consulte também

• Para obter instruções de montagem, consulte Montar compartilhamento de arquivos NFS no Linux.
• Para obter uma lista abrangente de opções de montagem, consulte a página do manual do Linux NFS.
• Para obter informações sobre latência, IOPS, taxa de transferência e outros conceitos de desempenho, consulte Compreender o desempenho dos Arquivos do Azure.