Partilhar via

Compreender e otimizar o desempenho do compartilhamento de arquivos do Azure

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

Modelo de gestão Modelo de faturação Nível de média Redundância SMB NFS
Microsoft.Armazenamento Provisionado v2 SSD (de qualidade superior) Localização (LRS) Não Sim
Microsoft.Armazenamento Provisionado v2 SSD (de qualidade superior) Zona (ZRS) Não Sim
Microsoft.Armazenamento Provisionado v2 HDD (padrão) Localização (LRS) Sim Não
Microsoft.Armazenamento Provisionado v2 HDD (padrão) Zona (ZRS) Sim Não
Microsoft.Armazenamento Provisionado v2 HDD (padrão) Geo (GRS) Sim Não
Microsoft.Armazenamento Provisionado v2 HDD (padrão) GeoZona (GZRS) Sim Não
Microsoft.Armazenamento Provisionado v1 SSD (de qualidade superior) Localização (LRS) Sim Sim
Microsoft.Armazenamento Provisionado v1 SSD (de qualidade superior) Zona (ZRS) Sim Sim
Microsoft.Armazenamento Pagamento conforme o consumo HDD (padrão) Localização (LRS) Sim Não
Microsoft.Armazenamento Pagamento conforme o consumo HDD (padrão) Zona (ZRS) Sim Não
Microsoft.Armazenamento Pagamento conforme o consumo HDD (padrão) Geo (GRS) Sim Não
Microsoft.Armazenamento Pagamento conforme o consumo HDD (padrão) GeoZona (GZRS) Sim Não

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 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 _ 4 KiB tamanho de E/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

Os Arquivos do Azure fornecem duas camadas de mídia de armazenamento que permitem equilibrar desempenho e preço: SSD e HDD. Você escolhe a camada de mídia do compartilhamento de arquivos no nível da conta de armazenamento e, depois de criar uma conta de armazenamento em uma camada de mídia específica, não pode mover para a outra sem migrar manualmente para um novo compartilhamento de arquivos.

Ao escolher entre compartilhamentos de arquivos SSD e HDD, é 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 rápidas de transferência de dados ou baixa latência, então você deve escolher compartilhamentos de arquivos 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

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

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 ajuda-o a alcançar um desempenho previsível.

  • Sensibilidade à latência: 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 um milissegundo para operações de leitura e gravação (< 2 ms para tamanho de E/S pequeno).

  • 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. Consulte objetivos de escala para partilhas de ficheiros para obter mais informações.

  • Duração e frequência da carga de trabalho: É menos provável que cargas de trabalho curtas (minutos) e pouco frequentes (por hora) atinjam os limites superiores de desempenho das partilhas de ficheiros HDD em comparação com cargas de trabalho de longa duração e frequentes. Em compartilhamentos de arquivos SSD, a duração da carga de trabalho é útil ao 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 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 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. Consulte Melhorar o desempenho do compartilhamento de arquivos do Azure SMB para obter mais informações.

  • Distribuição de operações 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. Consulte Trabalho pesado 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 às métricas de latência de ponta a ponta e 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.

  • A Latência do Serviço (SuccessServerLatency) é o tempo necessário para uma transação de ida e volta apenas dentro do Azure Files. 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 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 indicando baixa latência e o end-to-end estiver relatando latência muito alta para solicitações, isso indica que todo o tempo é gasto na transferência 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.

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 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 encadeamentos e vários ficheiros 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 (clients _ files _ threads = queue depth).

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 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 64

Sugestão

Para atingir limites superiores de desempenho, certifique-se de que a sua carga de trabalho ou teste de benchmarking esteja configurado para ser multi-threaded, utilizando vários arquivos.

Aplicações de thread único versus multi-thread

O Azure Files é mais adequado para aplicativos multi-threaded. A maneira mais fácil de compreender o impacto no desempenho que a multi-threading tem numa carga de trabalho é analisar o cenário com base em entrada/saída. 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 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, 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 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

  • Last updated on