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.

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. Em compartilhamentos de arquivos provisionados, um teste curto pode medir IOPS em rajada baseada 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 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.

Intermitências

Compartilhamentos de arquivos que utilizam o modelo de faturamento provisionado v2 ou provisionado v1 suportam o bursting baseado em crédito. O bursting baseado em crédito permite que um compartilhamento de arquivos use mais IOPS do que foi provisionado por um tempo limitado. O bursting baseado em crédito é uma característica do compartilhamento de arquivos. Tráfego em rajadas é um padrão de carga de trabalho com picos curtos no IOPS ou na taxa de transferência. O bursting baseado em crédito pode absorver picos curtos de IOPS causados por ráfagas de tráfego.

O bursting baseado em crédito está incluído no custo do compartilhamento de arquivos provisionado e não adiciona cobranças à sua conta. O bursting baseado em créditos se aplica somente a IOPS. Não aumenta a taxa de transferência acima da capacidade provisionada.

Bursting não se aplica a compartilhamentos de arquivos pay-as-you-go. Compartilhamentos clássicos que fazem burst ainda estão sujeitos aos limites IOPS da conta de armazenamento. Para mais informações, veja Limites do plano de dados do compartilhamento de arquivos clássico. Para informações sobre como o bursting afeta o custo, veja Entender o faturamento do Arquivos do Azure.

Explosão v2 provisionada

O intermitência de IOPS baseado em crédito proporciona flexibilidade adicional em torno do uso de IOPS. Use essa flexibilidade como um buffer em relação a picos de E/S não previstos. Para padrões de E/S estabelecidos, provisione para picos de E/S.

Os créditos de IOPS de intermitência são acumulados sempre que o tráfego para seu compartilhamento de arquivo é menor do que o IOPS provisionado (linha de base). Sempre que o uso de IOPS de um compartilhamento de arquivos exceder o IOPS provisionado e houver créditos de IOPS de burst disponíveis, o compartilhamento de arquivos poderá estourar até o limite máximo de IOPS de burst permitido. Os compartilhamentos de arquivos podem continuar fazer intermitência 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. Após todos os créditos serem consumidos, a ação retorna ao IOPS provisionado. IOPS contra o compartilhamento de arquivos não precisam fazer nada especial para usar bursting. O bursting opera com base no melhor esforço.

Os créditos de compartilhamento têm três status:

• Acumulando: quando o compartilhamento de arquivos está usando menos do que o IOPS provisionado.
• Em declínio: quando o compartilhamento de arquivos está usando mais do que o IOPS provisionado e no modo de intermitência.
• Constante, quando o compartilhamento de arquivos está usando exatamente o IOPS provisionado e não há créditos acumulados ou usados.

Um novo compartilhamento de arquivos começa com o número completo de créditos em seu bucket de intermitência. Os créditos de intermitência não são acumulados se o IOPS compartilhado cair abaixo do limite provisionado devido à limitação do 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 arquivo:

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

Explosão v1 provisionada

O modelo provisionado v1 suporta dois tipos de bursting: bursting baseado em crédito, que é incluído sem custo adicional, e bursting pago, que você pode opcionalmente habilitar para permitir IOPS e throughput acima do valor providenciado para cobranças baseadas em uso.

Intermitência baseada em crédito v1 provisionada

O intermitência de IOPS baseado em crédito proporciona flexibilidade adicional em torno do uso de IOPS. Use essa flexibilidade como um buffer em relação a picos de E/S não previstos. Para padrões de E/S estabelecidos, provisione para picos de E/S.

Os créditos IOPS de intermitência se acumulam sempre que o tráfego para o compartilhamento de arquivos clássico for menor que o IOPS provisionado (linha de base). Sempre que o uso de IOPS de um compartilhamento de arquivos clássico excede o provisionado e há créditos de IOPS para intermitência disponíveis, o compartilhamento de arquivos clássico pode aumentar até o limite máximo de IOPS de intermitência permitido. 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 que todos os créditos forem consumidos, o compartilhamento de arquivos clássico retorna aos IOPS provisionados. O IOPS no compartilhamento de arquivos clássico não precisa fazer nada de especial para usar bursting. O bursting opera com base no melhor esforço.

Os créditos de compartilhamento têm três status:

• Acumulando, quando o compartilhamento de arquivos clássico está utilizando menos do que o IOPS provisionado.
• Em declínio, quando o compartilhamento de arquivos clássico está usando mais do que o IOPS provisionado e no modo bursting.
• Constante, quando o compartilhamento de arquivos clássico está usando exatamente o IOPS provisionado 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 intermitência não são acumulados se o IOPS compartilhado cair abaixo do limite provisionado devido à limitação do 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 arquivo clássico:

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

Provisionamento de intermitência paga v1

O estouro pago é um recurso avançado do modelo v1 provisionado projetado para dar suporte a clientes que nunca desejam ser limitados. O bursting pago adiciona cobrança extra baseada em uso para qualquer quantidade de IOPS ou taxa de transferência acima do armazenamento provisionado. Esse recurso é distinto do bursting baseado em créditos, que está incluído sem custo adicional como parte do armazenamento provisionado. Embora o estouro pago possa adicionar poderosa flexibilidade à forma como você provisiona seu compartilhamento de arquivos clássico, ele também pode levar a cobranças inesperadas se usado incorretamente.

Como o bursting baseado em crédito, o bursting pago não é um substituto para o provisionamento da quantidade correta de IOPS e taxa de transferência. Em vez disso, ele fornece proteção adicional contra limitação, se houver uma demanda inesperada. Se você tiver um nível consistente de uso de IOPS ou taxa de transferência, será mais barato provisionar IOPS e taxa de transferência suficientes (por meio do provisionamento de armazenamento) para atender à demanda do que depender do bursting pago.

O bursting pago é desabilitado por padrão, mas você pode habilitá-lo seguindo as instruções para modificar as características de custo e desempenho de um compartilhamento de arquivos clássico v1 provisionado (somente PowerShell e CLI). Se você habilitar o bursting pago, monitore o uso de IOPS e da taxa de transferência usando as seguintes métricas disponíveis por meio do Azure Monitor:

• IOPS provisionado de compartilhamento de arquivos
• Largura de banda provisionada para compartilhamento de arquivo em MiB/s (taxa de transferência)
• Transações por IOPS máximo
• Largura de Banda por Max MiB/seg (taxa de transferência)
• Créditos de intermitência para IOPS (intermitência baseada em crédito)
• IOS (IOs) de intermitência paga
• Largura de banda de intermitência paga

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.

  

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.

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.

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.

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.

Confira também

• Solucionar problemas de desempenho no compartilhamento de arquivos do Azure
• Monitoramento dos Arquivos do Azure
• Planejando uma implantação de Arquivos do Azure
• Compreendendo a cobrança dos Arquivos do Azure
• Preços dos Arquivos do Azure