Partilhar via

Melhorar o desempenho para compartilhamentos de arquivos do Azure NFS

  • Artigo

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

Aplica-se a

Tipo de partilhas de ficheiros SMB NFS
Partilhas de ficheiros Standard (GPv2), LRS/ZRS Não, este artigo não se aplica a compartilhamentos de arquivos padrão do Azure SMB LRS/ZRS. Os compartilhamentos NFS só estão disponíveis em compartilhamentos de arquivos premium do Azure.
Partilhas de ficheiros Standard (GPv2), GRS/GZRS Não, este artigo não se aplica a compartilhamentos de arquivos padrão do Azure SMB GRS/GZRS. O NFS só está disponível em compartilhamentos de arquivos premium do Azure.
Partilhas de ficheiros Premium (FileStorage), LRS/ZRS Não, este artigo não se aplica a compartilhamentos de arquivos premium do Azure SMB. Sim, este artigo se aplica a compartilhamentos de arquivos premium do Azure NFS.

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 read-ahead para o equivalente a 15 vezes o valor do sistema rsizede 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 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 versões 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 (Transmission Control Protocol) entre o cliente e o serviço Arquivos Premium do Azure para NFSv4.1.

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 a 7 clientes, reduzindo os custos de computação em quase 70% e, ao mesmo tempo, fornecendo melhorias significativas nas operações de E/S por segundo (IOPS) e na taxa de transferência em escala. Consulte a seguinte 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.

Captura de tela mostrando a melhoria média no IOPS ao usar nconnect com compartilhamentos de arquivos do Azure NFS.

Captura de tela mostrando a melhoria média na taxa de transferência ao usar nconnect com compartilhamentos de arquivos do Azure NFS.

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 virtuais (VMs) cliente para evitar ser restringido 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.

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: nconnect configuração por montagem sobre ponto final 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: nconnect configuração por 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

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: nconnect configuração por montagem sobre ponto de extremidade privado com vários compartilhamentos em uma única conta de armazenamento (não suportada)

  • 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: VM 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 16 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 é 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.

Captura de tela mostrando vários cenários de E/S de leitura e gravação com latência correspondente para indicar quando o nconnect é aconselhável.

Consulte também