Partilhar via

Compreender e otimizar o desempenho do compartilhamento de arquivos do Azure

  • Artigo

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 podem afetar o desempenho do compartilhamento de arquivos e como otimizar o desempenho dos compartilhamentos de arquivos do Azure para sua carga de trabalho.

Aplica-se a

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

Glossário

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. O termo "IO" é intercambiável com os termos "operação" e "transação" na documentação dos Arquivos do Azure.

  • 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 muito pequenos, como 4 KiB, a tamanhos muito maiores. O tamanho da E/S desempenha um papel importante na taxa de transferência alcançável.

  • Débito

    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 tamanho de E/S MiB = 10 GiB/s, enquanto 10.000 IOPS * 4 KiB tamanho de E/S = 38 MiB/s.

  • Latência

    Latência é sinônimo de atraso e geralmente é 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 desempenho com base em padrões de uso

O Azure Files fornece uma variedade de camadas de armazenamento que ajudam a reduzir custos, permitindo que você armazene dados no nível apropriado de desempenho e preço. No nível mais alto, o Azure Files oferece duas camadas de desempenho: padrão e premium. As partilhas de ficheiros padrão são alojadas num sistema de armazenamento suportado por unidades de disco rígido (HDD), enquanto as partilhas de ficheiros premium são apoiadas por unidades de estado sólido (SSD) para um melhor desempenho. Os compartilhamentos de arquivos padrão têm vários níveis de armazenamento (transação otimizada, quente e legal) entre os quais você pode se mover perfeitamente para maximizar o armazenamento de dados em repouso e os preços de transação. No entanto, você não pode alternar entre os níveis padrão e premium sem migrar fisicamente seus dados entre diferentes contas de armazenamento.

Ao escolher entre compartilhamentos de arquivos padrão e premium, é importante entender os requisitos do padrão de uso esperado que você planeja executar nos Arquivos do Azure. Se você precisar de grandes quantidades de IOPS, velocidades de transferência de dados extremamente rápidas ou latência muito baixa, escolha compartilhamentos de arquivos premium do Azure.

A tabela a seguir resume as metas de desempenho esperadas entre padrão e premium. Para obter detalhes, consulte Metas de desempenho e escalabilidade dos Arquivos do Azure.

Requisitos de padrão de uso Standard Premium
Latência de gravação (milissegundos de um dígito) Sim Sim
Latência de leitura (milissegundos de um dígito) Não Sim

Os compartilhamentos de arquivos premium oferecem um modelo de provisionamento que garante o seguinte perfil de desempenho com base no tamanho do compartilhamento. Para obter mais informações, consulte Modelo provisionado. Os créditos de intermitência se acumulam em um bucket de intermitência sempre que o tráfego para seu compartilhamento de arquivos está abaixo do IOPS da linha de base. Os créditos ganhos são usados posteriormente para permitir o bursting quando as operações excedem o IOPS de linha de base.

Capacidade (GiB) IOPS inicial IOPS de intermitência Créditos de explosão Taxa de transferência (entrada + saída)
100 3,100 Até 10.000 24,840,000 110 MiB/s
500 3500 Até 10.000 23,400,000 150 MiB/s
1,024 4,024 Até 10.000 21,513,600 203 MiB/s
5,120 8,120 Até 15.360 26,064,000 613 MiB/s
10,240 13,240 Até 30.720 62,928,000 1.125 MiB/s
33,792 36,792 Até 100.000 227,548,800 3.480 MiB/s
51,200 54,200 Até 100.000 164,880,000 5.220 MiB/s
102,400 100.000 Até 100.000 0 10.340 MiB/s

Performance checklist (Lista de verificação do 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 ajudá-lo-á a alcançar um desempenho previsível. Consulte o administrador de armazenamento ou o desenvolvedor de aplicativos para determinar os seguintes padrões de uso.

  • Sensibilidade à latência: os usuários estão abrindo arquivos ou interagindo com áreas de trabalho virtuais executadas em Arquivos do Azure? Estes são exemplos de cargas de trabalho que são sensíveis à latência de leitura e também têm alta visibilidade para os usuários finais. Esses tipos de cargas de trabalho são mais adequados para compartilhamentos de arquivos premium do Azure, que podem fornecer latência de um milissegundo para operações de leitura e gravação (< 2 ms para tamanho de E/S pequeno).

  • Requisitos de IOPS e taxa de transferência: os compartilhamentos de arquivos Premium suportam IOPS maiores e limites de taxa de transferência do que os compartilhamentos de arquivos padrão. Consulte Destinos de escala de compartilhamento de arquivos para obter mais informações.

  • Duração e frequência da carga de trabalho: Cargas de trabalho curtas (minutos) e pouco frequentes (por hora) terão menos probabilidade de atingir os limites superiores de desempenho de compartilhamentos de arquivos padrão em comparação com cargas de trabalho de longa duração e que ocorrem com frequência. Em compartilhamentos de arquivos premium, a duração da carga de trabalho é útil ao determinar o perfil de desempenho correto a ser usado com base no tamanho do provisionamento. Dependendo de quanto tempo a carga de trabalho precisa estourar e quanto tempo ela passa abaixo do IOPS de linha de base, você pode determinar se está acumulando créditos de intermitência suficientes para satisfazer consistentemente sua carga de trabalho nos horários de pico. Encontrar o equilíbrio certo reduzirá os custos em comparação com o provisionamento excessivo do compartilhamento de arquivos. Um erro comum é executar testes de desempenho por apenas alguns minutos, o que muitas vezes é enganoso. Para obter uma visão realista do desempenho, certifique-se de testar em uma 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 aplicativos no mesmo cliente, os compartilhamentos de arquivos premium oferecem uma clara vantagem sobre os compartilhamentos de arquivos padrão: SMB Multichannel. Consulte Melhorar o desempenho do compartilhamento de arquivos do Azure SMB para obter mais informações.

  • Distribuição de operações de API: os metadados da carga de trabalho são pesados com operações de abertura/fechamento de arquivos? Isso é comum para cargas de trabalho que estão executando operações de leitura em um grande número de arquivos. Consulte Carga de trabalho pesada de metadados ou namespace.

Latência

Ao pensar em latência, é importante primeiro entender como a latência é determinada com os Arquivos do Azure. As medições mais comuns são a latência associada à latência de ponta a ponta e às métricas de latência do serviço. O uso dessas métricas de transação pode ajudar a identificar problemas de latência e/ou rede do lado do cliente, determinando quanto tempo o tráfego do aplicativo gasta 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.

  • Latência de Serviço (SuccessServerLatency) é o tempo que leva para uma transação de ida e volta somente dentro do serviço Arquivos do Azure. Isso não inclui nenhum cliente ou latência de rede.

    Diagrama comparando a latência do cliente e a latência do serviço para 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 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 estiver relatando baixa latência e o end-to-end estiver relatando latência muito alta para solicitações, isso sugere que todo o tempo é gasto em trânsito de e para o cliente, e não no serviço Arquivos do Azure.

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

Gorjeta

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. Muitas vezes, uma carga de trabalho pode ser retardada por um circuito de Rota Expressa ou gateway VPN subdimensionado ou roteado incorretamente.

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 utilizados pelos sistemas de armazenamento evoluíram de eixos HDD (IDE, SATA, SAS) para dispositivos de estado sólido (SSD, NVMe), também evoluíram para suportar uma 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 threads e vários arquivos pode facilmente alcançar 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 escala, recomendamos criar e testar cargas de trabalho com alta profundidade de fila.

A alta profundidade da fila pode ser alcançada de várias maneiras diferentes em combinação com clientes, arquivos e threads. Para determinar a profundidade da fila para sua carga de trabalho, multiplique o número de clientes pelo número de arquivos pelo número de threads (clientes * arquivos * threads = profundidade da fila).

A tabela abaixo ilustra as várias combinações que você pode usar para obter maior profundidade de fila. Embora você possa exceder a profundidade de fila ideal de 64, não recomendamos isso. 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 5 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 64

Gorjeta

Para atingir limites superiores de desempenho, certifique-se de que sua carga de trabalho ou teste de benchmarking seja multi-threaded com vários arquivos.

Aplicativos de thread único versus multithread

O Azure Files é mais adequado para aplicativos multi-threaded. A maneira mais fácil de entender o impacto no desempenho que o multithreading tem em uma carga de trabalho é percorrer o cenário por E/S. No exemplo a seguir, temos uma carga de trabalho que precisa copiar 10.000 arquivos pequenos o mais rápido possível de ou para um compartilhamento de arquivos 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 escrever 4 KiB escrever 4 KiB escrever 4 KiB escrever Fechar Total
Tópico 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Neste exemplo, seriam necessários aproximadamente 14 ms para criar um único arquivo de 16 KiB a partir das seis operações. Se um aplicativo de thread único quiser mover 10.000 arquivos para um compartilhamento de arquivos do Azure, isso se traduzirá em 140.000 ms (14 ms * 10.000) ou 140 segundos porque cada arquivo é movido sequencialmente, um de cada vez. Lembre-se de que o tempo para atender cada solicitação é determinado principalmente pela proximidade entre a computação e o armazenamento, conforme discutido na seção anterior.

Usando oito threads em vez de um, a carga de trabalho acima pode ser reduzida de 140.000 ms (140 segundos) para 17.500 ms (17,5 segundos). Como mostra a tabela abaixo, quando você está movendo oito arquivos em paralelo em vez de um arquivo de cada vez, você pode mover a mesma quantidade de dados em 87,5% menos tempo.

Operação de E/S Criar 4 KiB escrever 4 KiB escrever 4 KiB escrever 4 KiB escrever 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