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.

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. Em partilhas de ficheiros provisionadas, um teste curto pode medir o burst IOPS baseado em crédito em vez de IOPS provisionado. Para mais informações, veja Bursting.

• 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.

Expansão

Partilhas de ficheiros que utilizam o modelo de faturação provisionado v2 ou provisionado v1 suportam o bursting IOPS baseado em crédito. O bursting baseado em crédito permite que uma partilha de ficheiros use mais IOPS do que tem aprovisionado durante um tempo limitado. O bursting baseado em crédito é uma funcionalidade da partilha de ficheiros. O tráfego em rajadas é um padrão de carga de trabalho com picos curtos no IOPS ou no débito. O bursting baseado em crédito pode absorver picos curtos de IOPS devido a um burst de tráfego.

O bursting baseado em crédito está incluído no custo da partilha de ficheiros provisionada e não acrescenta encargos à sua fatura. O bursting baseado em créditos aplica-se apenas ao IOPS. Não aumenta o débito acima do débito provisionado.

O bursting não se aplica a partilhas de ficheiros pay-as-you-go. Partilhas de ficheiros clássicas que fazem burst continuam sujeitas aos limites IOPS da conta de armazenamento. Para mais informações, veja Limites clássicos do plano de dados de partilha de ficheiros. Para informações sobre como o bursting afeta o custo, veja Compreender a faturação do Ficheiros do Azure.

v2 provisionado para bursting

A explosão de IOPS baseada em crédito oferece uma flexibilidade adicional no uso de IOPS. Use esta flexibilidade como um amortecedor contra picos de IO inesperados. Para padrões de E/S estabelecidos, provisão para picos de E/S.

Os créditos de IOPS de intermitência se acumulam sempre que o tráfego para seu compartilhamento de arquivos é menor do que as IOPS provisionadas (linha de base). Sempre que a utilização de IOPS de um compartilhamento de arquivos ultrapassa os IOPS provisionados e há créditos disponíveis para IOPS de explosão, o compartilhamento de arquivos pode atingir até o limite máximo permitido de IOPS de explosão. Os compartilhamentos de arquivos podem continuar a estourar enquanto houver créditos restantes, com base no número de créditos de intermitência acumulados. Cada IO além dos IOPS provisionados consome um crédito. Depois de consumidos todos os créditos, a ação regressa ao IOPS provisionado. IOPS relativamente ao compartilhamento de arquivos não precisam fazer nada de específico para usar bursting. O "bursting" opera com base no melhor esforço.

Os créditos de participação têm três estados:

• Acumulando, quando o compartilhamento de arquivos está usando menos do que as IOPS provisionadas.
• Declining, quando a partilha de ficheiros está a usar mais do que as IOPS provisionadas e no modo de explosão.
• Constante, quando a partilha de ficheiros está a usar exatamente o IOPS provisionado e não há créditos acumulados ou utilizados.

Um novo partilha de ficheiros começa com o número total de créditos no seu balde de explosão. Os créditos de burst não se acumulam se as IOPS partilhadas caírem abaixo do limite provisionado devido à limitação imposta pelo servidor. As fórmulas a seguir são usadas para determinar o limite de IOPS de intermitência e o número de créditos possíveis para um compartilhamento de arquivos:

A tabela a seguir ilustra alguns exemplos dessas fórmulas para vários valores de IOPS provisionados:

Capacidade de pico v1 provisionada

O modelo provisionado v1 suporta dois tipos de bursting: bursting baseado em crédito, que está incluído sem custo adicional, e bursting pago, que pode opcionalmente ativar para permitir IOPS e throughput acima do valor provisionado para encargos baseados no uso.

Bursting v1 baseado em crédito provisionado

A explosão de IOPS baseada em crédito oferece uma flexibilidade adicional no uso de IOPS. Use esta flexibilidade como um amortecedor contra picos de IO inesperados. Para padrões de E/S estabelecidos, provisão para picos de E/S.

Os créditos de IOPS de rajada acumulam-se sempre que o tráfego para o seu compartilhamento clássico de arquivos é menor do que as IOPS provisionadas (linha de base). Sempre que o uso de IOPS de uma partilha de ficheiros clássica exceder as IOPS provisionadas e houver créditos de IOPS de rajada disponíveis, a partilha de ficheiros clássica poderá explodir até ao limite máximo permitido de IOPS de rajada. Os compartilhamentos de arquivos clássicos podem continuar a estourar enquanto houver créditos restantes, com base no número de créditos de intermitência acumulados. Cada IO além dos IOPS provisionados consome um crédito. Depois de consumidos todos os créditos, a partilha clássica de ficheiros retorna ao IOPS provisionado. IOPS em relação ao compartilhamento de arquivos clássico não precisam fazer nada de especial para usar o bursting. O "bursting" opera com base no melhor esforço.

Os créditos de participação têm três estados:

• Acumulando, quando o compartilhamento de arquivos clássico está usando menos do que as IOPS provisionadas.
• Declinando, quando a partilha de ficheiros clássica está a usar mais do que as IOPS provisionadas e no modo de explosão.
• Constante, quando o compartilhamento de arquivos clássico está usando exatamente as IOPS provisionadas e não há créditos acumulados ou usados.

Um novo compartilhamento de arquivos clássico começa com o número total de créditos em seu bucket de intermitência. Os créditos de burst não se acumulam se as IOPS partilhadas caírem abaixo do limite provisionado devido à limitação imposta pelo servidor. As fórmulas a seguir são usadas para determinar o limite de IOPS de intermitência e o número de créditos possíveis para um compartilhamento de arquivos clássico:

A tabela a seguir ilustra alguns exemplos dessas fórmulas para os tamanhos provisionados:

Provisão v1 expansiva paga

O bursting pago é um recurso avançado do modelo v1 provisionado projetado para dar suporte a clientes que não querem ser restringidos. O bursting pago adiciona cobrança extra baseada no uso para qualquer quantidade de IOPS ou taxa de transferência acima do armazenamento provisionado. Esta funcionalidade é distinta do bursting baseado em créditos, que é incluído gratuitamente como parte do armazenamento provisionado. Embora o bursting pago possa adicionar uma flexibilidade poderosa à forma como provisiona seu compartilhamento de arquivos clássico, ele também pode levar a cobranças inesperadas se usado incorretamente.

Tal como o bursting baseado em crédito, o bursting pago não é um substituto para o provisionamento da quantidade correta de IOPS e de taxa de transferência. Em vez disso, ele fornece mais proteção contra a limitação se você se deparar com uma demanda inesperada. Se tiveres um nível consistente de IOPS ou utilização de throughput, é mais barato provisionar IOPS e throughput suficientes (através do provisionamento de armazenamento) para cobrir a procura em vez de depender do bursting pago.

O bursting pago está desativado por defeito, mas pode ativá-lo seguindo as instruções para alterar o custo e as características de desempenho de uma partilha de ficheiros clássica v1 provisionada (apenas PowerShell e CLI). Se ativar o bursting pago, monitorize a utilização de IOPS e da taxa de débito utilizando as seguintes métricas disponíveis no Azure Monitor:

• IOPS provisionadas para partilha de ficheiros
• MiB/s de largura de banda provisionada para partilha de ficheiros (taxa de transferência)
• Transações por IOPS máximo
• Largura de banda por MiB/seg máximo (taxa de transferência)
• Créditos de Explosão para IOPS (explosão baseada em crédito)
• Explosão Paga de IOS (IOs)
• Largura de banda em rajadas paga

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.

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.

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.

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.

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