Melhorar o desempenho para compartilhamentos de arquivos do Azure NFS

Aplica-se a: ✔️ partilhas de ficheiros NFS

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

Aumente o tamanho da leitura antecipada para melhorar o desempenho 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 read-ahead como equivalente a 15 vezes o valor do rsize sistema de arquivos montado, que representa a opção de montagem do lado do cliente para o tamanho do buffer de leitura. Isso define o valor de leitura antecipada alto o suficiente para melhorar o desempenho 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. Este valor mais pequeno pode reduzir a quantidade de rendimento de leitura para ficheiros grandes. Utilizadores que atualizam de versões Linux com maior valor de leitura antecipada para versões com o padrão de 128 KiB podem experienciar uma diminuição no desempenho da leitura sequencial.

Para kernels do Linux 5.4 ou posterior, defina persistentemente 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 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. Só precisas de executar este comando uma vez para que o udev saiba do novo ficheiro.

   sudo udevadm control --reload
   

NFS nconnect [en]

NFS nconnect é uma opção de montagem do lado do cliente para partilhas de ficheiros NFS que utilizas para criar múltiplas ligações TCP entre o cliente e a tua partilha de ficheiros NFS. É particularmente útil para cargas de trabalho em grande escala onde uma única ligação TCP se torna um gargalo.

Benefícios do nconnect

Com o nconnect, você pode aumentar o desempenho em escala usando menos máquinas cliente para reduzir o custo total de propriedade (TCO). O recurso nconnect aumenta o desempenho usando vários canais TCP em uma ou mais NICs, usando um ou vários clientes. Sem o nconnect, são necessárias cerca de 20 máquinas cliente para atingir os limites de escala da largura de banda (10 GiB / s) oferecidos pela maior dimensão de aprovisionamento da partilha de ficheiros SSD. Com o nconnect, você pode atingir esses limites usando apenas 6 a 7 clientes, reduzindo os custos de computação em quase 70% enquanto fornece melhorias significativas nas operações de E/S por segundo (IOPS) e na taxa de transferência em escala. Consulte a seguinte tabela.

Pré-requisitos nconnect

• As mais recentes distribuições Linux suportam totalmente 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 uma única partilha de ficheiros é usada por cada conta de armazenamento num ponto de extremidade privado.

Impacto no desempenho

Os seguintes resultados de desempenho foram medidos com recurso à opção de montagem nconnect em partilhas de ficheiros NFS do Azure, em implementações em grande escala com clientes Linux. Para mais informações sobre como estes resultados foram alcançados, consulte configuração do teste de desempenho.

Recomendações nconnect

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

Conjunto nconnect=4

Embora o Ficheiros do Azure suporte definir o nconnect até ao valor máximo de 16, configure as opções de montagem com o valor ideal de nconnect=4. Atualmente, não há ganhos além de quatro canais para a implementação do nconnect no Ficheiros 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 da rede TCP.

Dimensione máquinas virtuais com cuidado

Dependendo dos requisitos de carga de trabalho, é importante dimensionar corretamente as máquinas virtuais (VMs) cliente para evitar restrições pela largura de banda de rede esperada. Você não precisa de vários controladores de interface de rede (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 de fila ideal de 64 porque você não verá mais ganhos de desempenho. Para obter mais informações, consulte Profundidade da fila.

Por configuração de montagem

Se uma carga de trabalho exigir a montagem de várias partilhas com uma ou mais contas de armazenamento com diferentes definições de nconnect num único cliente, não é garantido que as definições persistam ao montar através do ponto final público. Cada configuração de montagem suporta apenas uma única partilha de ficheiros do Azure por conta de armazenamento através do ponto final privado, conforme descrito no Cenário 1.

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

• 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: por configuração de montagem sobre ponto de extremidade público (não suportado)

• 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 em cada ponto de extremidade privado com várias partilhas numa única conta de armazenamento (não suportado)

• 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 (DSv4-Series) com NIC única
• SO: Linux (Ubuntu 20.04)
• Armazenamento NFS: Partilha de ficheiros SSD (atribuído 30 TiB, configuração nconnect=4)

Ferramentas e testes de avaliação comparativa

Estes testes utilizam o Flexible I/O Tester (FIO), uma ferramenta de I/O de disco gratuita e de código aberto, utilizada tanto para benchmarking como para verificação de stress ou hardware. Para instalar o FIO, consulte a secção Pacotes Binários no ficheiro FIO README e siga as instruções da plataforma que 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 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 de 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 capacidade: 100% leitura

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% leitura aleatória - profundidade da fila 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

Elevado IOPS: 100% de gravações

Tamanho de E/S de 4 KiB - 100% escrita aleatória - profundidade de 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 entrada/saída de 8 KiB - 100% escrita aleatória - profundidade de 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% escritas

Tamanho de E/S de 64 KiB - escrita aleatória% 100 - profundidade de 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% escrita aleatória - profundidade de fila 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 monothread e/ou usam uma profundidade de fila baixa (inferior a 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 requerem IOPS de alta escala ou desempenho em throughput. Para cargas de trabalho de menor escala, nconnect pode não ser benéfico. Use a tabela a seguir para decidir se nconnect é vantajoso para sua carga de trabalho. Cenários realçados em verde são recomendados, enquanto cenários realçados em vermelho não são. Os cenários destacados a amarelo são neutros.

Utilizar a disposição zonal

Para partilhas de ficheiros clássicas criadas com o fornecedor de recursos Microsoft.Storage, recomendamos usar a colocação zonal para selecionar a zona de disponibilidade específica onde a sua conta de armazenamento reside. Isto permite-lhe colocar as suas VMs na mesma zona de disponibilidade do armazenamento, o que pode reduzir a latência até 30 por cento. Esta funcionalidade está atualmente disponível apenas para contas de armazenamento SSD que utilizam armazenamento localmente redundante (LRS) em regiões suportadas.

Consulte também

• Montar partilha de ficheiros NFS para Linux
• Lista de opções de montagem
• Compreender o desempenho dos Arquivos do Azure