Compreender e otimizar o desempenho do compartilhamento de arquivos do Azure

✔️ Aplica-se a: Partilhas clássicas de ficheiros SMB e NFS criadas com o fornecedor de recursos do Microsoft.Storage

✔️ Aplica-se a: Partilhas de ficheiros criadas com o fornecedor de recursos Microsoft.FileShares

Os Arquivos do Azure podem satisfazer os requisitos de desempenho para a maioria dos aplicativos e casos de uso. Este artigo explica os diferentes fatores que afetam o desempenho da partilha de ficheiros e como otimizar o desempenho do Ficheiros do Azure para a sua carga de trabalho.

Glossário de desempenho de armazenamento

Antes de ler este artigo, é útil entender alguns termos-chave relacionados ao desempenho do armazenamento:

• Operações de E/S por segundo (IOPS)

  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 Ficheiros do Azure, o termo "IO" é intercambiável com os termos "operação" e "transação".

• Tamanho de E/S

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

• Vazão

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

• Latência

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

• Profundidade da fila

  A 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, consulte Profundidade da fila.

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

O Ficheiros do Azure oferece dois níveis de suporte de armazenamento que pode usar para equilibrar desempenho e preço: SSD e HDD. Seleciona o nível de media para a partilha de ficheiros ao nível da conta de armazenamento. Depois de criar uma conta de armazenamento numa determinada camada de meios, não pode passar para a outra camada de media sem migrar manualmente para uma nova partilha de ficheiros.

Ao escolher entre partilhas de ficheiros SSD e HDD, considere os requisitos do padrão de utilização esperado que planeia executar no Ficheiros do Azure. Se precisares de grandes quantidades de IOPS, velocidades rápidas de transferência de dados ou baixa latência, escolhe partilhas de ficheiros SSD.

A tabela seguinte resume os objetivos de desempenho esperados entre as partilhas de ficheiros SSD e HDD. Para obter detalhes, consulte Metas de desempenho e escalabilidade dos Arquivos do Azure.

Requisitos de padrão de uso	Disco de Estado Sólido	HDD
Latência de gravação (milissegundos de um dígito)	Sim	Sim
Latência de leitura (milissegundos de um dígito)	Sim	Não

As partilhas de ficheiros SSD utilizam um modelo de provisionamento que garante o seguinte perfil de desempenho com base no tamanho da partilha. Para obter mais informações, consulte o modelo v1 provisionado.

Práticas recomendadas de desempenho

Quer esteja a avaliar os requisitos de desempenho para uma carga de trabalho nova ou existente, compreender os seus padrões de utilização ajuda-o a alcançar um desempenho previsível.

• Sensibilidade à latência: Cargas de trabalho sensíveis à latência de leitura e com elevada visibilidade para os utilizadores finais são mais adequadas para partilhas de ficheiros SSD, que podem fornecer latência de um milissegundo tanto para operações de leitura como de escrita (menos de 2 ms para pequenas E/S).

• Requisitos de IOPS e de taxa de transferência: As partilhas de ficheiros SSD suportam limites de IOPS e de débito mais elevados do que as partilhas de ficheiros HDD. Para mais informações, consulte alvos de escala de partilha de ficheiros.

• Duração e frequência da carga de trabalho: Cargas de trabalho curtas (minutos) e infrequentes (a cada hora) têm menos probabilidade de atingir os limites superiores de desempenho das partilhas de ficheiros HDD em comparação com cargas de trabalho de longa duração e ocorrência frequente. Em partilhas de ficheiros SSD, a duração da carga de trabalho ajuda a determinar o perfil de desempenho correto a utilizar com base no armazenamento provisionado, IOPS e throughput. Um erro comum é executar testes de desempenho apenas durante alguns minutos, o que muitas vezes é enganador. Para obter uma visão realista do desempenho, certifique-se de que testa com frequência e duração suficientemente elevadas.

• Paralelização da carga de trabalho: Para cargas de trabalho que executam operações em paralelo, como através de vários threads, processos ou instâncias de aplicações no mesmo cliente, as partilhas de ficheiros SSD proporcionam uma clara vantagem em relação às partilhas de ficheiros HDD: SMB Multichannel. Para mais informações, consulte Melhorar o desempenho da partilha de ficheiros SMB Azure.

• Distribuição de operações de API: Cargas de trabalho com muitos metadados, como cargas que realizam operações de leitura contra um grande número de ficheiros, são mais adequadas para partilhas de ficheiros SSD. Para mais informações, consulte Carga de trabalho intensiva de metadados ou de namespaces.

• Colocação zonal: Use a colocação zonal para selecionar a zona de disponibilidade específica onde a sua conta de armazenamento se encontra. Esta funcionalidade permite-lhe colocar as suas VMs na mesma zona de disponibilidade do seu 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.

Latência

Quando pensas em latência, primeiro percebe como o Ficheiros do Azure determina a latência. As medições mais comuns são a latência associada às métricas de latência de ponta a ponta e de latência do serviço. A utilização destas 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 da sua aplicação demora em trânsito de e para o cliente.

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

• A latência de serviço (SuccessServerLatency) é o tempo que uma transação demora a fazer ida e volta apenas dentro do Ficheiros do Azure. Esta medição não inclui qualquer latência do cliente ou da rede.

  

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

É comum confundir latência do cliente com latência do serviço (neste caso, o desempenho dos Arquivos do Azure). Por exemplo, se a latência do serviço indica uma latência baixa e a latência de ponta a ponta indica uma latência muito elevada para os pedidos, todo o tempo é despendido no trânsito de e para o cliente, e não no serviço Ficheiros do Azure.

Além disso, como o diagrama ilustra, quanto mais longe estiver do serviço, mais lenta é a experiência de latência e mais difícil é atingir limites de escala de desempenho com qualquer serviço cloud. Esta condição é especialmente verdadeira ao aceder ao Ficheiros do Azure a partir das instalações. Embora opções como o Azure ExpressRoute sejam ideais para instalações locais, ainda assim não correspondem ao desempenho de uma aplicação (computação + armazenamento) que está a correr exclusivamente na mesma região Azure.

Sugestão

Usar uma VM no Azure para testar o desempenho entre o local e o Azure é uma maneira eficaz e prática de fazer a linha de base dos recursos de rede da conexão com o Azure. Circuitos de Rota Expressa ou gateways VPN subdimensionados ou roteados incorretamente podem tornar significativamente mais lentas as cargas de trabalho em execução nos Arquivos do Azure.

Profundidade da fila

A profundidade da fila é o número de solicitações de E/S pendentes que um recurso de armazenamento pode atender. À medida que os discos usados pelos sistemas de armazenamento evoluíram de spindles HDD (IDE, SATA, SAS) para dispositivos de estado sólido (SSD, NVMe), também evoluíram para suportar maior profundidade de fila. Uma carga de trabalho que consiste em um único cliente que interage em série com um único arquivo dentro de um grande conjunto de dados é um exemplo de baixa profundidade da fila. Em contraste, uma carga de trabalho que suporta paralelismo com vários encadeamentos e vários ficheiros pode facilmente alcançar alta profundidade de fila. Porque o Ficheiros do Azure é um serviço de ficheiros distribuído que abrange milhares de nós de cluster Azure e foi concebido para executar cargas de trabalho em escala, construir e testar cargas com grande profundidade de fila.

Pode atingir uma elevada profundidade da fila de várias formas. Para determinar a profundidade da fila para a sua carga de trabalho, multiplique o número de clientes pelo número de ficheiros pelo número de threads (clientes × ficheiros × threads = profundidade da fila).

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

Clientes	Ficheiros	Tópicos	Profundidade da fila
1	1	1	1
1	1	2	2
1	2	2	4
2	2	2	8
2	2	4	16
2	4	4	32
1	8	8	64
4	4	2	32

Sugestão

Para atingir níveis máximos de desempenho, certifique-se de que a sua carga de trabalho ou o seu teste de benchmark utiliza vários threads e vários ficheiros.

Aplicações monothread versus aplicações multithread

O Ficheiros do Azure funciona melhor com aplicações multissequenciais. A forma mais fácil de compreender o impacto no desempenho que o multithreading tem numa carga de trabalho é analisar o cenário do ponto de vista da E/S. No exemplo seguinte, tens uma carga de trabalho que precisa de copiar 10.000 ficheiros pequenos o mais rapidamente possível para ou a partir de uma partilha de ficheiros do Azure.

Esta tabela detalha o tempo necessário (em milissegundos) para criar um único arquivo de 16 KiB em um compartilhamento de arquivos do Azure, com base em um aplicativo de thread único que está gravando em tamanhos de bloco de 4 KiB.

Operação de E/S	Criar	4 KiB gravação	4 KiB gravação	4 KiB gravação	4 KiB gravação	Fechar	Total
Tópico 1	3 ms	2 ms	2 ms	2 ms	2 ms	3 ms	14 ms

Neste exemplo, demora aproximadamente 14 ms a criar um único ficheiro de 16 KiB a partir das seis operações. Se uma aplicação single-threaded quiser mover 10.000 ficheiros para uma partilha de ficheiros Azure, essa operação traduz-se em 140.000 ms (14 ms × 10.000) ou 140 segundos, porque cada ficheiro é movido sequencialmente, um de cada vez. O tempo para atender cada pedido é determinado principalmente pela proximidade entre o cálculo e o armazenamento, conforme discutido na secção anterior.

Ao usar oito threads em vez de um, pode reduzir a carga de trabalho anterior de 140.000 ms (140 segundos) para 17.500 ms (17,5 segundos). Como mostra a tabela seguinte, ao mover oito ficheiros em paralelo em vez de um de cada vez, pode mover a mesma quantidade de dados em 87,5% menos tempo.

Operação de E/S	Criar	4 KiB gravação	4 KiB gravação	4 KiB gravação	4 KiB gravação	Fechar	Total
Tópico 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

Consulte também

• Resolver problemas de desempenho das partilhas de ficheiros do Azure
• Monitorização dos Ficheiros do Azure
• Planear uma implementação de Ficheiros do Azure
• Noções básicas sobre a cobrança dos Arquivos do Azure
• Preços dos Arquivos do Azure