Reconhecimento e otimização do desempenho do compartilhamento de arquivo do Azure

✔️ Aplica-se a: compartilhamentos de arquivos SMB e NFS clássicos criados com o provedor de recursos Microsoft.Storage

✔️ Aplica-se a: Compartilhamentos de arquivos criados com o provedor de recursos Microsoft.FileShares

Os Arquivos do Azure podem atender aos requisitos de desempenho da maioria dos aplicativos e dos casos de uso. Este artigo explica os diferentes fatores que afetam o desempenho do compartilhamento de arquivos e como otimizar o desempenho de Arquivos do Azure para sua carga de trabalho.

Glossário de desempenho de armazenamento

Antes de você ler este artigo, é útil entender alguns termos básicos relacionados ao desempenho do armazenamento:

  • Operação de E/S por segundo (IOPS)

    O IOPS, ou operações de entrada/saída por segundo, mede o número de operações do sistema de arquivos por segundo. Na documentação do Arquivos do Azure, o termo "E/S" é usado de forma intercambiável com os termos "operação" e "transação".

  • Tamanho de E/S

    O tamanho de E/S, às vezes chamado de tamanho de bloco, é o tamanho da solicitação que um aplicativo usa para executar uma operação individual de E/S (entrada/saída) no armazenamento. Dependendo do aplicativo, o tamanho de E/S pode variar de tamanhos pequenos, como 4 KiB a tamanhos maiores. O tamanho de E/S desempenha um papel importante na taxa de transferência alcançável.

  • Taxa de transferência

    A taxa de transferência mede o número de bits lidos ou gravados no armazenamento por segundo e é medida em MiB/s (mebibytes por segundo). Para calcular a taxa de transferência, multiplique a IOPS pelo tamanho da E/S. Por exemplo, 10.000 IOPS × tamanho de E/S de 1 MiB = 10 GiB/s, enquanto 10.000 IOPS × tamanho de E/S de 4 KiB = 38 MiB/s.

  • Latência

    A latência é um sinônimo de atraso e é medida em milissegundos (ms). Há dois tipos de latência: latência de ponta a ponta e latência de serviço. Para obter mais informações, confira Latência.

  • Profundidade da fila

    Profundidade da fila é o número de solicitações de E/S pendentes que um recurso de armazenamento pode processar a qualquer momento. Para obter mais informações, confira Profundidade da fila.

Escolhendo uma camada de mídia com base em padrões de uso

Arquivos do Azure fornece duas camadas de mídia de armazenamento que você pode usar para balancear o desempenho e o preço: SSD e HDD. Selecione a camada de mídia para o compartilhamento de arquivos no nível da conta de armazenamento. Depois de criar uma conta de armazenamento em uma determinada camada de mídia, você não poderá mover para a outra camada de mídia sem migrar manualmente para um novo compartilhamento de arquivos.

Ao escolher entre compartilhamentos de arquivos SSD e HDD, considere os requisitos do padrão de uso esperado que você planeja executar no Arquivos do Azure. Se você precisar de grandes quantidades de IOPS, velocidades rápidas de transferência de dados ou baixa latência, escolha compartilhamentos de arquivos SSD.

A tabela a seguir resume as metas de desempenho esperadas entre compartilhamentos de arquivos SSD e HDD. Para obter detalhes, confira Metas de desempenho e escalabilidade dos Arquivos do Azure.

Requisitos de padrão de uso SSD HDD
Latência de gravação (milissegundos de dígito único) Sim Sim
Latência de leitura (milissegundos de dígito único) Sim Não

Os compartilhamentos de arquivos SSD usam um modelo de provisionamento que garante o perfil de desempenho a seguir com base no tamanho do compartilhamento. Para obter mais informações, veja o modelo v1 provisionado.

Práticas recomendadas de desempenho

Se você estiver avaliando os requisitos de desempenho para uma carga de trabalho nova ou existente, entender seus padrões de uso ajuda você a alcançar um desempenho previsível.

  • Sensibilidade de latência: As cargas de trabalho que são sensíveis à latência de leitura e têm alta visibilidade para os usuários finais são mais adequadas para compartilhamentos de arquivos SSD, que podem fornecer latência de milissegundo único para operações de leitura e gravação (menos de 2 ms para tamanho pequeno de E/S).

  • Requisitos de IOPS e taxa de transferência: Os compartilhamentos de arquivos SSD dão suporte a IOPS e limites de taxa de transferência maiores do que os compartilhamentos de arquivos HDD. Para obter mais informações, consulte destinos de escala de compartilhamento de arquivos.

  • Duração e frequência da carga de trabalho: Cargas de trabalho curtas (minutos) e pouco frequentes (por hora) são menos propensas a atingir os limites de desempenho superiores dos compartilhamentos de arquivos HDD em comparação com cargas de trabalho de execução longa e frequente. Em compartilhamentos de arquivos SSD, a duração da carga de trabalho ajuda a determinar o perfil de desempenho correto a ser usado com base no armazenamento provisionado, IOPS e taxa de transferência. Um erro comum é executar testes de desempenho por apenas alguns minutos, o que geralmente é enganoso. Para ter uma visão realista do desempenho, certifique-se de testar com frequência e duração suficientemente altas.

  • Paralelização da carga de trabalho: Para cargas de trabalho que executam operações em paralelo, como por meio de vários threads, processos ou instâncias de aplicativo no mesmo cliente, os compartilhamentos de arquivos SSD fornecem uma clara vantagem sobre os compartilhamentos de arquivos HDD: SMB Multichannel. Para obter mais informações, consulte Melhorar o desempenho do compartilhamento de arquivos SMB do Azure.

  • Distribuição da operação de API: cargas de trabalho pesadas de metadados, como cargas de trabalho que executam operações de leitura em um grande número de arquivos, são mais adequadas para compartilhamentos de arquivos SSD. Para obter mais informações, consulte Metadados ou carga de trabalho intensa no namespace.

  • Posicionamento zonal: use o posicionamento zonal para selecionar a zona de disponibilidade específica na qual sua conta de armazenamento reside. Esse recurso permite que você coloque suas VMs na mesma zona de disponibilidade que o 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.

Latência

Quando você pensa em latência, primeiro entenda como Arquivos do Azure determina a latência. As medidas mais comuns são a latência associada às métricas latência de ponta a ponta e latência de serviço. Usar essas métricas de transação pode ajudá-lo a identificar problemas de latência e rede do lado do cliente mostrando quanto tempo o tráfego do aplicativo passa em trânsito de e para o cliente.

  • A latência de ponta a ponta (SuccessE2ELatency) é o tempo total necessário para que uma transação execute uma viagem de ida e volta completa do cliente, pela rede, até o serviço Arquivos do Azure e de volta para o cliente.

  • A latência do serviço (SuccessServerLatency) é o tempo necessário para uma transação percorrer o trajeto de ida e volta apenas no Arquivos do Azure. Essa medida não inclui nenhuma latência de rede ou cliente.

    Diagrama com uma comparação entre a latência do cliente e a latência do serviço nos Arquivos do Azure.

A diferença entre os valores SuccessE2ELatency e SuccessServerLatency é a latência provavelmente causada pela rede e/ou pelo cliente.

É comum confundir a latência do cliente com a latência do serviço (nesse caso, o desempenho dos Arquivos do Azure). Por exemplo, se a latência do serviço relatar baixa latência e a latência de ponta a ponta relatar latência muito alta para solicitações, todo o tempo será gasto em trânsito de e para o cliente e não no serviço do Arquivos do Azure.

Além disso, como ilustra o diagrama, quanto mais longe você estiver do serviço, mais lento será a experiência de latência e mais difícil será atingir limites de escala de desempenho com qualquer serviço de nuvem. Essa condição é especialmente verdadeira ao acessar Arquivos do Azure do local. Embora opções como Azure ExpressRoute sejam ideais para locais, elas ainda não correspondem ao desempenho de um aplicativo (computação + armazenamento) que está sendo executado exclusivamente na mesma região Azure.

Dica

O uso de uma VM no Azure para testar o desempenho entre o local e o Azure é uma forma eficaz e prática de criar uma linha de base das funcionalidades de rede da conexão com o Azure. Circuitos do ExpressRoute ou gateways de VPN subdimensionados ou roteados incorretamente podem reduzir significativamente as cargas de trabalho em execução nos Arquivos do Azure.

Profundidade da fila

Profundidade da fila é o número de solicitações de E/S pendentes às quais um recurso de armazenamento pode atender. À medida que os discos usados pelos sistemas de armazenamento evoluíram de eixos HDD (IDE, SATA, SAS) para dispositivos de estado sólido (SSD, NVMe), eles também evoluíram para dar suporte a maior profundidade da fila. Uma carga de trabalho que consiste em um só cliente que interage serialmente com um arquivo individual em um grande conjunto de dados é um exemplo de baixa profundidade da fila. Em contraste, uma carga de trabalho que suporta paralelismo com vários threads e vários arquivos pode facilmente atingir alta profundidade de fila. Como o Arquivos do Azure é um serviço de arquivo distribuído que abrange milhares de nós de cluster do Azure e foi projetado para executar cargas de trabalho em grande escala, crie e teste cargas de trabalho com alta profundidade de fila.

Você pode obter uma profundidade de fila alta de várias maneiras diferentes. Para determinar a profundidade da fila para sua carga de trabalho, multiplique o número de clientes pelo número de arquivos e pelo número de threads (clientes × arquivos × threads = profundidade da fila).

A tabela a seguir ilustra as várias combinações que você pode usar para obter maior profundidade da fila. Embora você possa ultrapassar a profundidade ideal de fila de 64, não é recomendável. Você não verá mais ganhos de desempenho se fizer isso e correrá o risco de aumentar a latência devido à saturação de TCP.

Clientes Arquivos Threads Profundidade da fila
1 1 1 1
1 1 2 2
1 2 2 4
2 2 2 oito
2 2 4 16
2 4 4 32
1 oito oito 64
4 4 2 32

Dica

Para atingir os limites máximos de desempenho, garanta que a carga de trabalho ou o teste de benchmark seja multithread com vários arquivos.

Aplicações de thread única versus aplicações multithread

Arquivos do Azure funciona melhor com aplicativos multithreaded. A forma mais fácil de entender o impacto do multithreading no desempenho de uma carga de trabalho é analisar o cenário sob a perspectiva de E/S. No exemplo a seguir, você tem uma carga de trabalho que precisa copiar 10.000 arquivos pequenos o mais rápido possível para ou de um compartilhamento de arquivos Azure.

Esta tabela divide o tempo necessário (em milissegundos) para a criação de um só arquivo de 16 KiB em um compartilhamento de arquivo do Azure, com base em um aplicativo de thread único que faz gravações em tamanhos de bloco de 4 KiB.

Operação de E/S Criar Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Fechar Total
Thread 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Neste exemplo, leva aproximadamente 14 ms para criar um único arquivo de 16 KiB a partir de seis operações. Se um aplicativo de thread única quiser mover 10.000 arquivos para um compartilhamento de arquivos do Azure, essa operação equivale a 140.000 ms (14 ms × 10.000) ou 140 segundos, porque cada arquivo é movido sequencialmente, um de cada vez. O tempo para atender a cada solicitação é determinado principalmente pelo quão perto a computação e o armazenamento estão localizados entre si, conforme discutido na seção anterior.

Usando oito threads em vez de um, você pode reduzir a carga de trabalho anterior de 140.000 ms (140 segundos) para 17.500 ms (17,5 segundos). Como mostra a tabela a seguir, ao mover oito arquivos em paralelo em vez de um arquivo por vez, você pode mover a mesma quantidade de dados em 87,5% menos tempo.

Operação de E/S Criar Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Fechar Total
Thread 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tópico 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tópico 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tópico 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tópico 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tópico 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tópico 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Tópico 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Confira também