Compartilhar via

Reconhecimento e otimização do desempenho do compartilhamento de arquivo do Azure

  • Artigo

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

Aplica-se a

Tipo de compartilhamento de arquivos SMB NFS
Compartilhamentos de arquivos padrão (GPv2), LRS/ZRS Sim Não
Compartilhamentos de arquivos padrão (GPv2), GRS/GZRS Sim Não
Compartilhamento de arquivos premium (FileStorage), LRS/ZRS Sim Sim

Glossário

Antes de você ler este artigo, é útil entender alguns termos básicos relacionados ao desempenho do armazenamento:

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

    O 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 do Arquivos do Azure.

  • 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 muito pequenos, como 4 KiB, a tamanhos muito 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 é sinônimo de atraso e geralmente é medida em ms (milissegundos). 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.

Como escolher um nível de desempenho com base nos padrões de uso

Os Arquivos do Azure fornecem uma variedade de camadas de armazenamento que ajudam a reduzir os custos, permitindo que você armazene dados no nível apropriado de desempenho e preço. No nível mais alto, os Arquivos do Azure oferecem dois níveis de desempenho: Standard e Premium. Os compartilhamentos de arquivos Standard são hospedados em um sistema de armazenamento apoiado por HD (unidades de disco rígido), enquanto os compartilhamentos de arquivos Premium são apoiados por SSD (unidades de estado sólido) para aprimorar o desempenho. Os compartilhamentos de arquivos Standard contêm várias camadas de armazenamento (otimizadas para transações, quentes e frias), entre as quais você pode alternar perfeitamente para maximizar os preços da transação e do armazenamento dos dados inativos. No entanto, não é possível mover entre as camadas Standard e Premium sem migrar fisicamente os dados entre contas de armazenamento diferentes.

Ao escolher entre compartilhamentos de arquivos Standard e Premium, é importante entender os requisitos do padrão de uso esperado que você pretende 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, deverá escolher os compartilhamentos de arquivos Premium do Azure.

A tabela a seguir resume as metas de desempenho esperadas entre o Standard e o Premium. Para obter detalhes, confira Metas de desempenho e escalabilidade dos Arquivos do Azure.

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

Os compartilhamentos de arquivos Premium oferecem 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. Os créditos de intermitência se acumulam em um bucket de intermitência sempre que o tráfego para o compartilhamento de arquivo está abaixo da IOPS de linha de base. Os créditos ganhos são usados posteriormente para habilitar a intermitência quando as operações excederiam a IOPS de linha de base.

Capacidade (GiB) IOPS de linha de base IOPS de intermitência Créditos de intermitência Taxa de transferência (entrada + saída)
100 3.100 Até 10.000 24.840.000 110 MiB/s
500 3\.500 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

Lista de verificação de desempenho

Se você estiver avaliando os requisitos de desempenho para uma carga de trabalho nova ou existente, entender seus padrões de uso ajudará você a obter um desempenho previsível. Consulte seu administrador de armazenamento ou o desenvolvedor de aplicativos para determinar os padrões de uso a seguir.

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

  • Requisitos de IOPS e taxa de transferência: o compartilhamento de arquivos Premium dá suporte a IOPS e limites de taxa de transferência maiores que o do compartilhamento de arquivos padrão. Confira metas e tamanhos do 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 de desempenho superiores dos compartilhamentos de arquivos Standard em comparação com as cargas de trabalho de execução longa e frequente. Em compartilhamentos de arquivos Premium, a duração da carga de trabalho é útil ao determinar o perfil de desempenho correto a ser usado de acordo com o tamanho do provisionamento. Dependendo do tempo que a carga de trabalho precisa para ficar intermitente e do tempo que ela gasta abaixo da IOPS de linha de base, você poderá determinar se está acumulando créditos de intermitência suficientes para atender consistentemente à sua carga de trabalho nos horários de pico. Encontrar o equilíbrio correto reduzirá os custos em comparação com o superprovisionamento do compartilhamento de arquivo. Um erro comum é executar testes de desempenho por apenas alguns minutos, o que geralmente é enganoso. Para ter uma visão realista do desempenho, faça testes em uma frequência e uma duração suficientemente altas.

  • Paralelização da carga de trabalho: para cargas de trabalho que executam operações em paralelo, como, por exemplo, por meio de diversos threads, processos ou instâncias de aplicativo no mesmo cliente, o compartilhamento de arquivos Premium oferece uma vantagem clara sobre o compartilhamento de arquivos padrão, SMB Multichannel. Para saber mais, confira Aprimorar o desempenho do compartilhamento de arquivos do Azure no SMB.

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

Latency

Ao pensar em latência, é importante, primeiro, entender como a latência é determinada com os Arquivos do Azure. 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. O uso destas métricas de transação pode ajudar a identificar problemas de latência e/ou de rede do lado do cliente determinando quanto tempo o tráfego do aplicativo passa em trânsito bidirecionalmente no 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 de serviço (SuccessServerLatency) é o tempo necessário para uma transação fazer uma viagem de ida e volta somente no serviço Arquivos do Azure. Isso não inclui nenhuma latência de cliente ou de rede.

    Diagrama com uma comparação entre a latência do cliente e a latência do serviço nos 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 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 está sendo relatada como baixa e a de ponta a ponta está sendo relatada como muito alta para solicitações, isso sugere que todo o tempo é gasto em trânsito bidirecionalmente no cliente, 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á alcançar os limites de escala de desempenho com qualquer serviço de nuvem. Isso é especialmente verdadeiro quando os Arquivos do Azure são acessados no local. Embora opções como o ExpressRoute 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.

Dica

O uso de uma VM no Azure para testar o desempenho entre o local e o Azure é uma forma eficaz e prática de criar uma linha de base das funcionalidades de rede da conexão com o Azure. Geralmente, uma carga de trabalho pode ser desacelerada por um circuito do ExpressRoute ou um gateway de VPN subdimensionado ou roteado incorretamente.

Profundidade da fila

Profundidade da fila é o número de solicitações de E/S pendentes às quais um recurso de armazenamento pode atender. Como os discos usados pelos sistemas de armazenamento evoluíram de eixos HD (IDE, SATA e SAS) para dispositivos de estado sólido (SSD e NVMe), eles também evoluíram para dar suporte a uma profundidade de fila maior. 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. Por outro lado, uma carga de trabalho que dá suporte ao paralelismo com vários threads e vários arquivos pode com facilidade alcançar uma alta profundidade da fila. Como os Arquivos do Azure são 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 uma alta profundidade da fila.

A alta profundidade da fila pode ser obtida de várias maneiras diferentes em combinação com clientes, arquivos e threads. Para determinar a profundidade da fila da 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 abaixo ilustra as várias combinações que você pode usar para obter maior profundidade da fila. Embora você possa exceder a profundidade ideal da fila de 64, não recomendamos fazer isso. 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.

Clientes Arquivos Threads 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

Dica

Para atingir limites de desempenho superiores, verifique se a carga de trabalho ou o teste de parâmetro de comparação é multithread com vários arquivos.

Aplicativos de thread único ou multithread

Os Arquivos do Azure é mais adequado para aplicativos multithread. A maneira mais fácil de entender o impacto no desempenho que o multithreading causa em uma carga de trabalho é acompanhar o cenário por E/S. No exemplo a seguir, temos uma carga de trabalho que precisa copiar 10 mil arquivos pequenos o mais rápido possível em um compartilhamento de arquivo do 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.

Operação de E/S Criar Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Fechar Total
Thread 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 arquivo individual de 16 KiB das seis operações. Se um aplicativo de thread único quiser mover 10 mil arquivos para um compartilhamento de arquivo do Azure, isso será convertido em 140.000 ms (14 ms * 10.000) ou 140 segundos, porque cada arquivo é movido sequencialmente um de cada vez. Tenha em mente que o tempo necessário para atender a cada solicitação é determinado principalmente pela proximidade do local da computação e do armazenamento entre si, 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). Conforme mostra a tabela abaixo, ao mover oito arquivos em paralelo em vez de um arquivo por vez, você pode mover o mesmo volume de dados em 87,5% menos tempo.

Operação de E/S Criar Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Gravação de 4 KiB Fechar Total
Thread 1 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 2 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 3 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 4 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 5 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 6 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 7 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms
Thread 8 3 ms 2 ms 2 ms 2 ms 2 ms 3 ms 14 ms

Confira também