Armazenamento premium do Azure: conceção para elevado desempenho

Aplica-se a: ✔️ VMs do Windows VMs ✔️ do Linux Conjuntos ✔️ de dimensionamento ✔️ flexíveis Conjuntos de dimensionamento uniformes

Este artigo fornece diretrizes para criar aplicações de alto desempenho com o Azure Armazenamento Premium. Pode utilizar as instruções fornecidas neste documento em conjunto com as melhores práticas de desempenho aplicáveis às tecnologias utilizadas pela sua aplicação. Para ilustrar as diretrizes, utilizámos SQL Server em execução no Armazenamento Premium como exemplo ao longo deste documento.

Embora abordemos os cenários de desempenho da camada armazenamento neste artigo, terá de otimizar a camada da aplicação. Por exemplo, se estiver a alojar um Farm do SharePoint no Azure Armazenamento Premium, pode utilizar os exemplos de SQL Server deste artigo para otimizar o servidor de bases de dados. Além disso, otimize o servidor Web e o servidor de Aplicações do SharePoint Farm para obter o maior desempenho.

Este artigo ajudará a responder às seguintes perguntas comuns sobre a otimização do desempenho da aplicação no Azure Armazenamento Premium,

  • Como medir o desempenho da sua aplicação?
  • Por que motivo não está a ver o elevado desempenho esperado?
  • Que fatores influenciam o desempenho da sua aplicação no Armazenamento Premium?
  • Como é que estes fatores influenciam o desempenho da sua aplicação no Armazenamento Premium?
  • Como pode otimizar para IOPS, Largura de Banda e Latência?

Fornecemos estas diretrizes especificamente para Armazenamento Premium porque as cargas de trabalho em execução no Armazenamento Premium são altamente sensíveis ao desempenho. Fornecemos exemplos sempre que adequado. Também pode aplicar algumas destas diretrizes a aplicações em execução em VMs IaaS com discos de Armazenamento Standard.

Nota

Por vezes, o que parece ser um problema de desempenho do disco é, na verdade, um estrangulamento de rede. Nestas situações, deve otimizar o desempenho da rede.

Se pretender fazer uma referência ao disco, veja os nossos artigos sobre o benchmarking de um disco:

Se a VM suportar redes aceleradas, deve certificar-se de que está ativada. Se não estiver ativado, pode ativá-lo em VMs já implementadas no Windows e linux.

Antes de começar, se não estiver familiarizado com Armazenamento Premium, leia primeiro o artigo Selecionar um tipo de disco do Azure para VMs IaaS e Metas de escalabilidade para contas de armazenamento de blobs de páginas premium.

Indicadores de desempenho da aplicação

Avaliamos se uma aplicação está a ter um bom desempenho ou não a utilizar indicadores de desempenho, como a rapidez com que uma aplicação está a processar um pedido de utilizador, a quantidade de dados que uma aplicação está a processar por pedido, quantos pedidos é um processamento de aplicações num determinado período de tempo, quanto tempo um utilizador tem de esperar para obter uma resposta depois de submeter o pedido. Os termos técnicos para estes indicadores de desempenho são IOPS, Débito ou Largura de Banda e Latência.

Nesta secção, vamos abordar os indicadores de desempenho comuns no contexto da Armazenamento Premium. Na secção seguinte, Recolha de Requisitos de Aplicação, irá aprender a medir estes indicadores de desempenho para a sua aplicação. Mais tarde, em Otimizar o desempenho da aplicação, ficará a saber mais sobre os fatores que afetam estes indicadores de desempenho e recomendações para os otimizar.

IOPS

IOPS, ou Operações de Entrada/saída Por Segundo, é o número de pedidos que a sua aplicação está a enviar para os discos de armazenamento num segundo. Uma operação de entrada/saída pode ser lida ou escrita, sequencial ou aleatória. As aplicações OLTP (Online Transaction Processing), como um site de revenda online, têm de processar imediatamente muitos pedidos de utilizador simultâneos. Os pedidos de utilizador são inseridos e atualizam transações de bases de dados intensivas, que a aplicação tem de processar rapidamente. Por conseguinte, as aplicações OLTP necessitam de IOPS muito elevado. Estas aplicações processam milhões de pedidos de E/S pequenos e aleatórios. Se tiver essa aplicação, tem de estruturar a infraestrutura da aplicação para otimizar o IOPS. Em Otimizar o desempenho da aplicação, discutimos em detalhe todos os fatores que tem de considerar para obter IOPS elevada.

Quando anexa um disco de armazenamento premium à sua VM de grande escala, o Azure aprovisiona um número garantido de IOPS de acordo com a especificação do disco. Por exemplo, um disco P50 aprovisiona 7500 IOPS. Cada tamanho de VM de grande escala tem também um limite de IOPS específico que pode sustentar. Por exemplo, uma VM GS5 Standard tem um limite de 80 000 IOPS.

Débito

Débito ou largura de banda é a quantidade de dados que a sua aplicação está a enviar para os discos de armazenamento num intervalo especificado. Se a sua aplicação estiver a realizar operações de entrada/saída com grandes tamanhos de unidades de E/S, é necessário um débito elevado. As aplicações do armazém de dados tendem a emitir operações intensivas de análise que acedem a grandes porções de dados de cada vez e geralmente realizam operações em massa. Por outras palavras, essas aplicações requerem um débito mais elevado. Se tiver essa aplicação, tem de estruturar a respetiva infraestrutura para otimizar o débito. Na secção seguinte, vamos abordar detalhadamente os fatores que tem de ajustar para o conseguir.

Quando anexa um disco de armazenamento premium a uma VM de alta escala, o Azure aprovisiona o débito de acordo com essa especificação de disco. Por exemplo, um disco P50 aprovisiona um débito de disco de 250 MB por segundo. Cada tamanho de VM de grande escala tem também um limite de débito específico que pode sustentar. Por exemplo, uma VM Standard GS5 tem um débito máximo de 2000 MB por segundo.

Existe uma relação entre o débito e o IOPS, conforme mostrado na fórmula abaixo.

Relação de IOPS e débito

Por conseguinte, é importante determinar os valores de débito e IOPS ideais necessários para a sua aplicação. À medida que tenta otimizar uma, a outra também é afetada. Em Otimizar o desempenho da aplicação, iremos abordar mais detalhes sobre a otimização de IOPS e Débito.

Latência

A latência é o tempo que uma aplicação demora a receber um único pedido, a enviá-la para os discos de armazenamento e a enviar a resposta para o cliente. Esta é uma medida crítica do desempenho de uma aplicação, além de IOPS e Débito. A Latência de um disco de armazenamento premium é o tempo necessário para obter as informações de um pedido e comunicá-la de volta à sua aplicação. Armazenamento Premium fornece latências baixas consistentes. Os Discos Premium foram concebidos para fornecer latências de milissegundos de um dígito para a maioria das operações de E/S. Se ativar a colocação em cache do anfitrião ReadOnly em discos de armazenamento premium, pode obter uma latência de leitura muito inferior. Abordamos a Colocação em Cache de Discos mais detalhadamente na colocação em cache de discos.

Quando estiver a otimizar a sua aplicação para obter IOPS e Débito mais elevados, isso afetará a latência da sua aplicação. Depois de otimizar o desempenho da aplicação, avalie sempre a latência da aplicação para evitar um comportamento inesperado de latência elevada.

As seguintes operações do plano de controlo no Managed Disks podem envolver a movimentação do Disco de uma localização de Armazenamento para outra. Esta ação é orquestrada através da cópia em segundo plano dos dados que podem demorar várias horas a concluir, normalmente menos de 24 horas, consoante a quantidade de dados nos discos. Durante esse período, a sua aplicação pode ter uma latência de leitura superior ao habitual, uma vez que algumas leituras podem ser redirecionadas para a localização original e podem demorar mais tempo a concluir. Não há qualquer impacto na latência de escrita durante este período.

  • Atualize o tipo de armazenamento.
  • Desanexe e anexe um disco de uma VM a outra.
  • Crie um disco gerido a partir de um VHD.
  • Criar um disco gerido a partir de um instantâneo.
  • Converter discos não geridos em discos geridos.

Lista de Verificação de Aplicações de Desempenho para discos

O primeiro passo para conceber aplicações de alto desempenho em execução no Azure Armazenamento Premium é compreender os requisitos de desempenho da sua aplicação. Depois de reunir os requisitos de desempenho, pode otimizar a sua aplicação para alcançar o desempenho mais ideal.

Na secção anterior, explicámos os indicadores de desempenho comuns, IOPS, Débito e Latência. Tem de identificar qual destes indicadores de desempenho é fundamental para a sua aplicação para proporcionar a experiência de utilizador pretendida. Por exemplo, o IOPS elevado é mais importante para as aplicações OLTP que processam milhões de transações num segundo. Enquanto que o débito elevado é fundamental para Data Warehouse aplicações que processam grandes quantidades de dados num segundo. A Latência extremamente baixa é crucial para aplicações em tempo real, como sites de transmissão em fluxo de vídeo em direto.

Em seguida, meça os requisitos máximos de desempenho da sua aplicação ao longo da sua duração. Utilize a lista de verificação de exemplo abaixo como um início. Registe os requisitos máximos de desempenho durante os períodos normais, de pico e de carga de trabalho fora do horário de expediente. Ao identificar os requisitos para todos os níveis de cargas de trabalho, poderá determinar o requisito de desempenho geral da sua aplicação. Por exemplo, a carga de trabalho normal de um site de comércio eletrónico serão as transações que serve durante a maioria dos dias num ano. A carga de trabalho de pico do site serão as transações que serve durante a época festiva ou eventos especiais de venda. Normalmente, a carga de trabalho de pico é experimentada durante um período limitado, mas pode exigir que a sua aplicação dimensione duas ou mais vezes o seu funcionamento normal. Descubra os requisitos de percentil 50, 90 percentil e 99 percentil. Isto ajuda a filtrar todos os valores atípicos nos requisitos de desempenho e pode concentrar os seus esforços na otimização dos valores certos.

Lista de verificação dos requisitos de desempenho da aplicação

Requisitos de desempenho 50 Percentil Percentil 90 99 Percentil
Um máximo de Transações por segundo
% de operações de leitura
% de operações de escrita
% de operações aleatórias
% de operações sequenciais
Tamanho do pedido de E/S
Débito Médio
Um máximo de Débito
Mín. Latência
Latência Média
Um máximo de CPU
CPU média
Um máximo de Memória
Memória Média
Profundidade da Fila

Nota

Deve considerar dimensionar estes números com base no crescimento futuro esperado da sua aplicação. É uma boa ideia planear o crescimento com antecedência, uma vez que poderá ser mais difícil alterar a infraestrutura para melhorar o desempenho mais tarde.

Se tiver uma aplicação existente e quiser mudar para Armazenamento Premium, crie primeiro a lista de verificação acima para a aplicação existente. Em seguida, crie um protótipo da sua aplicação no Armazenamento Premium e crie a aplicação com base nas diretrizes descritas em Otimizar o desempenho da aplicação. O próximo artigo descreve as ferramentas que pode utilizar para recolher as medições de desempenho.

Contadores para medir os requisitos de desempenho da aplicação

A melhor forma de medir os requisitos de desempenho da sua aplicação é utilizar as ferramentas de monitorização de desempenho fornecidas pelo sistema operativo do servidor. Pode utilizar o PerfMon para Windows e iostat para Linux. Estas ferramentas capturam contadores correspondentes a cada medida explicada na secção acima. Tem de capturar os valores destes contadores quando a sua aplicação estiver a executar as cargas de trabalho normais, de pico e fora de horas.

Os contadores PerfMon estão disponíveis para processador, memória e cada disco lógico e disco físico do servidor. Quando utiliza discos de armazenamento premium com uma VM, os contadores de disco físico são para cada disco de armazenamento premium e os contadores de discos lógicos são para cada volume criado nos discos de armazenamento premium. Tem de capturar os valores dos discos que alojam a carga de trabalho da aplicação. Se existir um mapeamento de um para um entre discos lógicos e físicos, pode consultar contadores de discos físicos; caso contrário, veja os contadores de discos lógicos. No Linux, o comando iostat gera um relatório de utilização da CPU e do disco. O relatório de utilização do disco fornece estatísticas por dispositivo físico ou partição. Se tiver um servidor de base de dados com os respetivos dados e registos em discos separados, recolha estes dados para ambos os discos. A tabela abaixo descreve os contadores para discos, processadores e memória:

Contador Description PerfMon iostat
IOPS ou Transações por segundo Número de pedidos de E/S emitidos para o disco de armazenamento por segundo. Leituras/seg do Disco
Escritas de Disco/seg
tps
r/s
w/s
Leituras e Escritas do Disco % das operações de Leitura e Escrita realizadas no disco. % de Tempo de Leitura do Disco
% de Tempo de Escrita do Disco
r/s
w/s
Débito Quantidade de dados lidos ou escritos no disco por segundo. Bytes/seg de Leitura do Disco
Bytes/seg de Escrita do Disco
kB_read/s
kB_wrtn/s
Latência Tempo total para concluir um pedido de E/S do disco. Média de Disco seg/Leitura
Média de segundos/escrita do disco
await
svctm
Tamanho de E/S O tamanho dos pedidos de E/S para os discos de armazenamento. Média de Bytes de Disco/Leitura
Média de Bytes de Disco/Escrita
avgrq-sz
Profundidade da Fila Número de pedidos de E/S pendentes à espera de serem lidos ou escritos no disco de armazenamento. Comprimento da Fila de Disco Atual avgqu-sz
Um máximo de Memória Quantidade de memória necessária para executar a aplicação sem problemas % dos Bytes Consolidados em Utilização Utilizar o vmstat
Um máximo de CPU Quantidade de CPU necessária para executar a aplicação sem problemas % de tempo do processador %util

Saiba mais sobre iostat e PerfMon.

Otimizar o desempenho da aplicação

Os principais fatores que influenciam o desempenho de uma aplicação em execução no Armazenamento Premium são a Natureza dos pedidos de E/S, o tamanho da VM, o Tamanho do disco, o Número de discos, a colocação em cache do disco, a multithreading e a profundidade da fila. Pode controlar alguns destes fatores com botões fornecidos pelo sistema. A maioria das aplicações pode não lhe dar uma opção para alterar diretamente o tamanho de E/S e a Profundidade da Fila. Por exemplo, se estiver a utilizar SQL Server, não pode escolher o tamanho de E/S e a profundidade da fila. SQL Server escolhe o tamanho ideal de E/S e os valores de profundidade da fila para obter o maior desempenho. É importante compreender os efeitos de ambos os tipos de fatores no desempenho da aplicação, para que possa aprovisionar recursos adequados para satisfazer as necessidades de desempenho.

Ao longo desta secção, veja a lista de verificação de requisitos de aplicação que criou para identificar o quanto precisa para otimizar o desempenho da sua aplicação. Com base nisso, poderá determinar quais os fatores desta secção que terá de otimizar. Para testemunhar os efeitos de cada fator no desempenho da sua aplicação, execute ferramentas de benchmarking na configuração da aplicação. Veja o artigo Benchmarking, ligado no final, para obter passos para executar ferramentas de benchmarking comuns em VMs do Windows e Linux.

Otimizar rapidamente o IOPS, o débito e a latência

A tabela abaixo resume os fatores de desempenho e os passos necessários para otimizar o IOPS, o débito e a latência. As secções que se seguem a este resumo descreverão cada fator com muito mais profundidade.

Para obter mais informações sobre os tamanhos de VM e sobre o IOPS, débito e latência disponíveis para cada tipo de VM, veja Tamanhos para máquinas virtuais no Azure.

IOPS Débito Latência
Cenário de Exemplo A aplicação OLTP empresarial requer transações muito elevadas por segunda taxa. Aplicação de armazenamento de dados empresariais que processa grandes quantidades de dados. Aplicações quase em tempo real que requerem respostas instantâneas a pedidos de utilizador, como jogos online.
Fatores de desempenho      
Tamanho de E/S O tamanho de E/S mais pequeno gera IOPS mais elevado. Tamanho de E/S maior para obter um débito mais elevado.  
Tamanho da VM Utilize um tamanho de VM que ofereça IOPS superior ao requisito da sua aplicação. Utilize um tamanho de VM com um limite de débito superior ao requisito da sua aplicação. Utilize um tamanho de VM que ofereça limites de dimensionamento superiores aos requisitos da sua aplicação.
Tamanho do disco Utilize um tamanho de disco que ofereça IOPS superior ao requisito da sua aplicação. Utilize um tamanho de disco com limite de débito superior ao requisito da aplicação. Utilize um tamanho de disco que ofereça limites de dimensionamento superiores aos requisitos da aplicação.
Limites de Dimensionamento de VMs e Discos O limite de IOPS do tamanho da VM escolhido deve ser superior ao total de IOPS impulsionado pelos discos de armazenamento ligados ao mesmo. O limite de débito do tamanho da VM escolhido deve ser superior ao débito total impulsionado pelos discos de armazenamento premium ligados ao mesmo. Os limites de dimensionamento do tamanho da VM escolhido têm de ser superiores aos limites de dimensionamento totais dos discos de armazenamento premium anexados.
Colocação em Cache do Disco Ative a Cache ReadOnly em discos de armazenamento premium com operações pesadas de leitura para obter IOPS de Leitura superior.   Ative a Cache ReadOnly em discos de armazenamento premium com operações pesadas de Leitura para obter latências de leitura muito baixas.
Repartição de Discos Utilize vários discos e junte-os para obter um limite de IOPS e Débito superior combinado. O limite combinado por VM deve ser superior aos limites combinados dos discos premium anexados.    
Tamanho da Faixa Tamanho de faixa mais pequeno para padrão de E/S pequeno aleatório visto em aplicações OLTP. Por exemplo, utilize o tamanho de faixa de 64 KB para SQL Server aplicação OLTP. Tamanho de faixa maior para padrão de E/S grande sequencial visto em aplicações Data Warehouse. Por exemplo, utilize o tamanho de faixa de 256 KB para SQL Server aplicação armazém de dados.  
Multithreading Utilize multithreading para emitir um número mais elevado de pedidos para Armazenamento Premium que levará a IOPS e Débito mais elevados. Por exemplo, no SQL Server definir um valor MAXDOP elevado para alocar mais CPUs a SQL Server.    
Profundidade da Fila Maior Profundidade de Fila gera IOPS mais elevados. A Profundidade de Fila Maior gera um débito mais elevado. A Profundidade da Fila Mais Pequena gera latências mais baixas.

Natureza dos pedidos de E/S

Um pedido de E/S é uma unidade de operação de entrada/saída que a sua aplicação irá realizar. Identificar a natureza dos pedidos de E/S, aleatórios ou sequenciais, de leitura ou escrita, pequenos ou grandes, irá ajudá-lo a determinar os requisitos de desempenho da sua aplicação. É importante compreender a natureza dos pedidos de E/S, tomar as decisões certas ao conceber a sua infraestrutura de aplicações. As IOs têm de ser distribuídas uniformemente para alcançar o melhor desempenho possível.

O tamanho de E/S é um dos fatores mais importantes. O tamanho de E/S é o tamanho do pedido de operação de entrada/saída gerado pela sua aplicação. O tamanho de E/S tem um impacto significativo no desempenho, especialmente na IOPS e largura de banda que a aplicação consegue alcançar. A fórmula seguinte mostra a relação entre IOPS, tamanho de E/S e Largura de Banda/Débito.
Um diagrama que mostra a equação I O P S vezes tamanho I O é igual a Débito.

Algumas aplicações permitem-lhe alterar o respetivo tamanho de E/S, enquanto algumas aplicações não. Por exemplo, SQL Server determina o tamanho ideal de E/S e não fornece aos utilizadores botões para alterá-lo. Por outro lado, o Oracle fornece um parâmetro chamado DB_BLOCK_SIZE com o qual pode configurar o tamanho do pedido de E/S da base de dados.

Se estiver a utilizar uma aplicação, que não lhe permite alterar o tamanho de E/S, utilize as diretrizes neste artigo para otimizar o KPI de desempenho mais relevante para a sua aplicação. Por exemplo,

  • Uma aplicação OLTP gera milhões de pedidos de E/S pequenos e aleatórios. Para lidar com estes tipos de pedidos de E/S, tem de estruturar a sua infraestrutura de aplicação para obter IOPS mais elevado.
  • Uma aplicação de armazenamento de dados gera pedidos de E/S grandes e sequenciais. Para lidar com estes tipos de pedidos de E/S, tem de estruturar a sua infraestrutura de aplicação para obter uma largura de banda ou Débito mais elevados.

Se estiver a utilizar uma aplicação, que lhe permite alterar o tamanho de E/S, utilize esta regra de polegar para o tamanho de E/S para além de outras diretrizes de desempenho,

  • Tamanho de E/S mais pequeno para obter IOPS mais elevado. Por exemplo, 8 KB para uma aplicação OLTP.
  • Tamanho de E/S maior para obter largura de banda/Débito mais elevado. Por exemplo, 1024 KB para uma aplicação de armazém de dados.

Eis um exemplo de como pode calcular o IOPS e o Débito/Largura de Banda da sua aplicação. Considere uma aplicação com um disco P30. O IOPS máximo e Débito/Largura de Banda que um disco P30 pode alcançar é 5000 IOPS e 200 MB por segundo, respetivamente. Agora, se a sua aplicação precisar do IOPS máximo do disco P30 e utilizar um tamanho de E/S menor como 8 KB, a largura de banda resultante que conseguirá obter será de 40 MB por segundo. No entanto, se a sua aplicação exigir o Débito/Largura de Banda máximo do disco P30 e utilizar um tamanho de E/S maior como 1024 KB, o IOPS resultante será menor, 200 IOPS. Por conseguinte, ajuste o tamanho de E/S de modo a cumprir o requisito de IOPS e Débito/Largura de Banda da sua aplicação. A tabela seguinte resume os diferentes tamanhos de E/S e os respetivos IOPS e Débito correspondentes para um disco P30.

Requisito da Aplicação Tamanho de E/S IOPS Débito/Largura de Banda
IOPS Máximo 8 KB 5000 40 MB por segundo
Débito Máximo 1024 KB 200 200 MB por segundo
Débito Máximo + IOPS elevado 64 KB 3,200 200 MB por segundo
Máximo de IOPS + Débito Elevado 32 KB 5000 160 MB por segundo

Para obter IOPS e Largura de Banda superiores ao valor máximo de um único disco de armazenamento premium, utilize vários discos premium recortados em conjunto. Por exemplo, liste dois discos P30 para obter um IOPS combinado de 10 000 IOPS ou um Débito combinado de 400 MB por segundo. Conforme explicado na secção seguinte, tem de utilizar um tamanho de VM que suporte o IOPS e o Débito do disco combinados.

Nota

À medida que aumenta o IOPS ou o Débito, o outro também aumenta, certifique-se de que não atinge os limites de débito ou IOPS do disco ou da VM ao aumentar um dos dois.

Para testemunhar os efeitos do tamanho de E/S no desempenho da aplicação, pode executar ferramentas de referência na VM e nos discos. Crie várias execuções de teste e utilize um tamanho de E/S diferente para cada execução para ver o impacto. Para obter mais detalhes, veja o artigo Benchmarking (Referência), ligado no final.

Tamanhos de VMs de alta escala

Quando começar a criar uma aplicação, uma das primeiras coisas a fazer é escolher uma VM para alojar a sua aplicação. Armazenamento Premium inclui tamanhos de VM de Alta Escala que podem executar aplicações que requerem uma maior potência de computação e um elevado desempenho de E/S do disco local. Estas VMs fornecem processadores mais rápidos, uma proporção de memória para núcleo mais elevada e uma unidade de Solid-State (SSD) para o disco local. Exemplos de VMs de Alta Escala que suportam Armazenamento Premium são as VMs da série DS e GS.

As VMs de Alta Escala estão disponíveis em tamanhos diferentes com um número diferente de núcleos de CPU, memória, SO e tamanho de disco temporário. Cada tamanho de VM também tem o número máximo de discos de dados que pode anexar à VM. Por conseguinte, o tamanho da VM escolhida afetará a quantidade de processamento, memória e capacidade de armazenamento disponível para a sua aplicação. Também afeta o custo de Computação e Armazenamento. Por exemplo, abaixo encontram-se as especificações do maior tamanho de VM numa série DS e numa série GS:

Tamanho da VM Núcleos de CPU Memória Tamanhos dos discos da VM Um máximo de discos de dados Tamanho da cache IOPS Limites de E/S da Cache de Largura de Banda
Standard_DS14 16 112 GB SO = 1023 GB
Local SSD = 224 GB
32 576 GB 50 000 IOPS
512 MB por segundo
4000 IOPS e 33 MB por segundo
Standard_GS5 32 448 GB SO = 1023 GB
Local SSD = 896 GB
64 4224 GB 80 000 IOPS
2000 MB por segundo
5000 IOPS e 50 MB por segundo

Para ver uma lista completa de todos os tamanhos de VMs do Azure disponíveis, veja Tamanhos de máquinas virtuais no Azure. Escolha um tamanho de VM que possa cumprir e dimensionar para os requisitos de desempenho da aplicação pretendidos. Além disso, tenha em conta as considerações importantes ao escolher tamanhos de VM.

Limites de Dimensionamento
Os limites máximos de IOPS por VM e por disco são diferentes e independentes uns dos outros. Confirme que a aplicação está a conduzir IOPS dentro dos limites da VM, bem como dos discos premium ligados à mesma. Caso contrário, o desempenho da aplicação sofrerá limitação.

Por exemplo, suponha que um requisito de aplicação é um máximo de 4000 IOPS. Para tal, aprovisione um disco P30 numa VM DS1. O disco P30 pode fornecer até 5000 IOPS. No entanto, a VM DS1 está limitada a 3200 IOPS. Consequentemente, o desempenho da aplicação será restringido pelo limite de VM em 3200 IOPS e haverá um desempenho degradado. Para evitar esta situação, escolha uma VM e um tamanho de disco que cumpram ambos os requisitos da aplicação.

Custo da Operação
Em muitos casos, é possível que o custo geral da operação com Armazenamento Premium seja inferior à utilização do Armazenamento Standard.

Por exemplo, considere uma aplicação que requer 16 000 IOPS. Para alcançar este desempenho, precisará de um Standard_D14 VM IaaS do Azure, que pode fornecer um IOPS máximo de 16 000 através de 32 discos de 1 TB de armazenamento padrão. Cada disco de armazenamento standard de 1 TB pode atingir um máximo de 500 IOPS. O custo estimado desta VM por mês será de 1570 $. O custo mensal de 32 discos de armazenamento standard será de $1.638. O custo total mensal estimado será de 3.208 $.

No entanto, se tiver alojado a mesma aplicação no Armazenamento Premium, precisará de um tamanho de VM mais pequeno e menos discos de armazenamento premium, reduzindo assim o custo global. Uma VM Standard_DS13 pode cumprir o requisito de 16 000 IOPS com quatro discos P30. A VM DS13 tem um IOPS máximo de 25 600 e cada disco P30 tem um IOPS máximo de 5000. No geral, esta configuração pode atingir 5000 x 4 = 20 000 IOPS. O custo estimado desta VM por mês será de 1003 $. O custo mensal de quatro discos de armazenamento premium P30 será de 544,34 $. O custo total mensal estimado será de $1.544.

A tabela abaixo resume a discriminação de custos deste cenário para Standard e Armazenamento Premium.

  Standard Premium
Custo da VM por mês $1.570.58 (Standard_D14) $1.003.66 (Standard_DS13)
Custo dos Discos por mês $1.638,40 (32 x discos de 1 TB) $544,34 (4 x discos P30)
Custo Global por mês $3.208.98 $1.544.34

Distribuições do Linux

Com o Azure Armazenamento Premium, obtém o mesmo nível de Desempenho para VMs com Windows e Linux. Suportamos vários tipos de distribuições do Linux. Para obter mais informações, veja Distribuições linux aprovadas no Azure. É importante ter em atenção que as diferentes distribuições são mais adequadas para diferentes tipos de cargas de trabalho. Verá diferentes níveis de desempenho consoante a distribuição em que a carga de trabalho está a ser executada. Teste as distribuições do Linux com a sua aplicação e escolha a que funciona melhor.

Ao executar o Linux com Armazenamento Premium, verifique as atualizações mais recentes sobre os controladores necessários para garantir um elevado desempenho.

Tamanhos do disco de armazenamento Premium

O Azure Armazenamento Premium oferece uma variedade de tamanhos para que possa escolher um que melhor se adeque às suas necessidades. Cada tamanho de disco tem um limite de dimensionamento diferente para IOPS, largura de banda e armazenamento. Escolha o Armazenamento Premium Tamanho do disco certo consoante os requisitos da aplicação e o tamanho da VM de alta escala. A tabela abaixo mostra os tamanhos dos discos e as respetivas capacidades. Atualmente, os tamanhos P4, P6, P15, P60, P70 e P80 só são suportados para Managed Disks.

Tamanhos SSD Premium P1 P2 P3 P4 P6 P10 P15 P20 P30 P40 P50 P60 P70 P80
Tamanho do disco no GiB 4 8 16 32 64 128 256 512 1,024 2048 4,096 8,192 16 384 32 767
IOPS aprovisionado por disco 120 120 120 120 240 500 1100 2300 5000 7.500 7.500 16 000 18 000 20 000
Débito Aprovisionado por disco 25 MB/seg 25 MB/seg 25 MB/seg 25 MB/seg 50 MB/seg 100 MB/seg 125 MB/seg 150 MB/seg 200 MB/seg 250 MB/seg 250 MB/seg 500 MB/seg 750 MB/seg 900 MB/seg
IOPS de rajada máxima por disco 3500 3500 3500 3500 3500 3500 3500 3500 30,000* 30,000* 30,000* 30,000* 30,000* 30,000*
Débito máximo de expansão por disco 170 MB/seg 170 MB/seg 170 MB/seg 170 MB/seg 170 MB/seg 170 MB/seg 170 MB/seg 170 MB/seg 1000 MB/seg* 1000 MB/seg* 1000 MB/seg* 1000 MB/seg* 1000 MB/seg* 1000 MB/seg*
Duração máxima da rajada 30 min 30 min 30 min 30 min 30 min 30 min 30 min 30 min Ilimitado* Ilimitado* Ilimitado* Ilimitado* Ilimitado* Ilimitado*
Elegível para reserva No No No No No No No No Sim, até um ano Sim, até um ano Sim, até um ano Sim, até um ano Sim, até um ano Sim, até um ano

*Aplica-se apenas a discos com expansão a pedido ativada.

O número de discos que escolher depende do tamanho do disco escolhido. Pode utilizar um único disco P50 ou vários discos P10 para cumprir os requisitos da sua aplicação. Tenha em conta as considerações listadas abaixo ao fazer a escolha.

Limites de Dimensionamento (IOPS e Débito)
Os limites de IOPS e Débito de cada tamanho de disco Premium são diferentes e independentes dos limites de dimensionamento da VM. Certifique-se de que o total de IOPS e Débito dos discos está dentro dos limites de dimensionamento do tamanho da VM escolhido.

Por exemplo, se um requisito de aplicação for um débito máximo de 250 MB/seg e estiver a utilizar uma VM DS4 com um único disco P30. A VM DS4 pode ceder até 256 MB/seg Débito. No entanto, um único disco P30 tem um limite de Débito de 200 MB/seg. Consequentemente, a aplicação será limitada a 200 MB/seg devido ao limite do disco. Para ultrapassar este limite, aprovisione mais de um disco de dados para a VM ou redimensione os discos para P40 ou P50.

Nota

As leituras servidas pela cache não estão incluídas no IOPS do disco e no Débito, pelo que não estão sujeitas a limites de disco. A cache tem o respetivo limite de IOPS e Débito separado por VM.

Por exemplo, inicialmente as suas leituras e escritas são 60 MB/seg e 40 MB/seg, respetivamente. Com o tempo, a cache aquece e serve cada vez mais das leituras da cache. Em seguida, pode obter um débito de escrita mais elevado a partir do disco.

Número de Discos
Determine o número de discos de que precisará ao avaliar os requisitos da aplicação. Cada tamanho de VM também tem um limite no número de discos que pode anexar à VM. Normalmente, este é o dobro do número de núcleos. Certifique-se de que o tamanho da VM que escolher pode suportar o número de discos necessários.

Nota: os Discos de armazenamento Premium têm maiores capacidades de desempenho face aos Discos de armazenamento Standard. Por conseguinte, se estiver a migrar a sua aplicação da VM IaaS do Azure com o Armazenamento Standard para Armazenamento Premium, provavelmente precisará de menos discos premium para alcançar o mesmo ou maior desempenho para a sua aplicação.

Colocação em cache do disco

As VMs de alta escala que tiram partido do Azure Armazenamento Premium têm uma tecnologia de colocação em cache de várias camadas chamada BlobCache. O BlobCache utiliza uma combinação da RAM de anfitrião e do SSD local para colocação em cache. Esta cache está disponível para os discos persistentes Armazenamento Premium e os discos locais da VM. Por predefinição, esta definição de cache está definida como Leitura/Escrita para discos do SO e ReadOnly para discos de dados alojados no Armazenamento Premium. Com a colocação em cache do disco ativada nos discos Armazenamento Premium, as VMs de alta escala podem alcançar níveis de desempenho extremamente elevados que excedem o desempenho do disco subjacente.

Aviso

A Colocação em Cache do Disco não é suportada para discos de 4 TiB e maiores. Se estiverem ligados vários discos à VM, cada disco que seja mais pequeno do que 4 TiB suporta a colocação em cache.

Alterar a definição de cache de um disco do Azure desanexa e anexa o disco de destino. Se for o disco do sistema operativo, a VM será reiniciada. Pare todas as aplicações/serviços que possam ser afetadas por esta interrupção antes de alterar a definição da cache do disco. Não seguir estas recomendações pode levar a danos nos dados.

Para saber mais sobre como funciona o BlobCache, consulte a mensagem de blogue Dentro do Azure Armazenamento Premium.

É importante ativar a cache no conjunto de discos correto. Se deve ou não ativar a colocação em cache do disco num disco premium, depende do padrão de carga de trabalho que o disco irá processar. A tabela abaixo mostra as definições de cache predefinidas para discos de SO e Dados.

Tipo de disco Predefinição da cache
Disco do SO ReadWrite
Disco de dados ReadOnly

Seguem-se as definições de cache de disco recomendadas para discos de dados,

Definição de colocação em cache do disco recomendação sobre quando utilizar esta definição
Nenhuma Configure a cache de anfitrião como Nenhum para discos só de escrita e de escrita pesada.
ReadOnly Configure a cache de anfitrião como ReadOnly para discos só de leitura e leitura-escrita.
ReadWrite Configure a cache do anfitrião como ReadWrite apenas se a sua aplicação processar corretamente a escrita de dados em cache em discos persistentes quando necessário.

ReadOnly
Ao configurar a colocação em cache ReadOnly em discos de dados Armazenamento Premium, pode obter baixa latência de Leitura e obter IOPS de Leitura e Débito de Leitura muito elevados para a sua aplicação. Isto deve-se a duas razões,

  1. As leituras realizadas a partir da cache, que se encontra na memória da VM e no SSD local, são muito mais rápidas do que as leituras do disco de dados, que se encontra no armazenamento de blobs do Azure.
  2. Armazenamento Premium não conta as Leituras servidas a partir da cache, em direção ao IOPS do disco e Débito. Por conseguinte, a sua aplicação consegue obter um IOPS e Débito totais mais elevados.

ReadWrite
Por predefinição, os discos do SO têm a colocação em cache ReadWrite ativada. Adicionámos recentemente suporte para colocação em cache readWrite em discos de dados. Se estiver a utilizar a colocação em cache ReadWrite, tem de ter uma forma adequada de escrever os dados da cache em discos persistentes. Por exemplo, SQL Server processa a escrita de dados em cache nos discos de armazenamento persistentes. A utilização da cache ReadWrite com uma aplicação que não processa a persistência dos dados necessários pode levar à perda de dados, se a VM falhar.

Nenhuma
Atualmente, Nenhum só é suportado em discos de dados. Não é suportado em discos do SO. Se definir Nenhum num disco do SO, este irá substituir isto internamente e defini-lo como ReadOnly.

Por exemplo, pode aplicar estas diretrizes a SQL Server em execução no Armazenamento Premium ao fazer o seguinte:

  1. Configure a cache "ReadOnly" em discos de armazenamento premium que alojam ficheiros de dados.
    a. As leituras rápidas da cache reduzem o tempo de consulta SQL Server, uma vez que as páginas de dados são obtidas muito mais rapidamente a partir da cache em comparação com diretamente dos discos de dados.
    b. Ao servir leituras da cache, significa que existe débito adicional disponível a partir de discos de dados premium. SQL Server pode utilizar este Débito adicional para obter mais páginas de dados e outras operações, como cópia de segurança/restauro, carregamentos em lotes e recompilações de índices.
  2. Configure a cache "None" em discos de armazenamento premium que alojam os ficheiros de registo.
    a. Os ficheiros de registo têm principalmente operações de escrita intensiva. Por conseguinte, não beneficiam da cache ReadOnly.

Otimizar o desempenho em VMs do Linux

Para todos os SSDs premium ou discos ultra, poderá desativar "barreiras" para sistemas de ficheiros no disco para melhorar o desempenho quando se sabe que não existem caches que possam perder dados. Se a colocação em cache do disco do Azure estiver definida como ReadOnly ou None, pode desativar as barreiras. No entanto, se a colocação em cache estiver definida como ReadWrite, as barreiras devem permanecer ativadas para garantir a durabilidade da escrita. Normalmente, as barreiras são ativadas por predefinição, mas pode desativar as barreiras através de um dos seguintes métodos, dependendo do tipo de sistema de ficheiros:

  • Para reiserFS, utilize a opção de montagem barrier=none para desativar as barreiras. Para ativar explicitamente barreiras, utilize barrier=flush.
  • Para ext3/ext4, utilize a opção de montagem barrier=0 para desativar as barreiras. Para ativar explicitamente barreiras, utilize barrier=1.
  • Para XFS, utilize a opção de montagem nobarrier para desativar as barreiras. Para ativar explicitamente barreiras, utilize a barreira. A partir da versão 4.10 do kernel linux mainline, a estrutura do sistema de ficheiros XFS garante sempre durabilidade. Desativar barreiras não tem efeito e a opção "nobarrier" foi preterida. No entanto, algumas distribuições do Linux podem ter suportado as alterações a uma versão de distribuição com uma versão de kernel anterior. Verifique junto do fornecedor de distribuição o estado na distribuição e versão que está a executar.

Repartição de discos

Quando uma VM de alta escala é anexada a vários discos persistentes de armazenamento premium, os discos podem ser recortados em conjunto para agregar os IOPs, a largura de banda e a capacidade de armazenamento.

No Windows, pode utilizar Espaços de Armazenamento para recorar discos em conjunto. Tem de configurar uma coluna para cada disco num conjunto. Caso contrário, o desempenho geral do volume recortado pode ser inferior ao esperado, devido à distribuição desigual do tráfego nos discos.

Importante: ao utilizar Gestor de Servidor IU, pode definir o número total de colunas até 8 para um volume listrado. Ao anexar mais de oito discos, utilize o PowerShell para criar o volume. Com o PowerShell, pode definir o número de colunas igual ao número de discos. Por exemplo, se existirem 16 discos num único conjunto de faixas; especifique 16 colunas no parâmetro NumberOfColumns do cmdlet Do PowerShell New-VirtualDisk .

No Linux, utilize o utilitário MDADM para riscar discos em conjunto. Para obter passos detalhados sobre a repartição de discos no Linux, veja Configurar o RAID de Software no Linux.

Tamanho da Faixa
Uma configuração importante na repartição de discos é o tamanho da faixa. O tamanho ou tamanho do bloco de faixas é o menor segmento de dados que a aplicação pode abordar num volume remisso. O tamanho das faixas que configura depende do tipo de aplicação e do respetivo padrão de pedido. Se escolher o tamanho de faixa errado, tal pode levar a um desalinhamento de E/S, o que leva a um desempenho degradado da sua aplicação.

Por exemplo, se um pedido de E/S gerado pela sua aplicação for maior do que o tamanho das faixas do disco, o sistema de armazenamento escreve-o em vários limites de unidades em mais do que um disco. Quando chegar a altura de aceder a esses dados, terá de procurar em mais do que uma unidade de faixa para concluir o pedido. O efeito cumulativo de tal comportamento pode levar a uma degradação substancial do desempenho. Por outro lado, se o tamanho do pedido de E/S for menor do que o tamanho da faixa e se for aleatório por natureza, os pedidos de E/S poderão ser adicionados no mesmo disco, causando um estrangulamento e, em última análise, degradando o desempenho de E/S.

Consoante o tipo de carga de trabalho que a sua aplicação está a executar, escolha um tamanho de faixa adequado. Para pedidos de E/S pequenos aleatórios, utilize um tamanho de faixa mais pequeno. Enquanto que para pedidos de E/S sequenciais grandes, utilize um tamanho de faixa maior. Descubra as recomendações de tamanho de faixa para a aplicação que irá executar no Armazenamento Premium. Para SQL Server, configure o tamanho das faixas de 64 KB para cargas de trabalho OLTP e 256 KB para cargas de trabalho de armazenamento de dados. Veja Melhores práticas de desempenho para SQL Server em VMs do Azure para saber mais.

Nota

Pode juntar um máximo de 32 discos de armazenamento premium numa VM da série DS e 64 discos de armazenamento premium numa VM da série GS.

Multi-threading

O Azure concebeu Armazenamento Premium plataforma para ser extremamente paralela. Por conseguinte, uma aplicação com vários threads obtém um desempenho muito superior ao de uma aplicação de thread único. Uma aplicação com vários threads divide as suas tarefas em vários threads e aumenta a eficiência da sua execução ao utilizar a VM e os recursos de disco até ao máximo.

Por exemplo, se a sua aplicação estiver em execução numa VM de núcleo único com dois threads, a CPU pode alternar entre os dois threads para obter eficiência. Enquanto um thread aguarda a conclusão de uma E/S de disco, a CPU pode mudar para o outro thread. Desta forma, dois threads podem conseguir mais do que um único thread. Se a VM tiver mais do que um núcleo, diminui ainda mais o tempo de execução, uma vez que cada núcleo pode executar tarefas em paralelo.

Poderá não conseguir alterar a forma como uma aplicação fora da prateleira implementa threading único ou multi-threading. Por exemplo, SQL Server é capaz de processar várias CPUs e multi-núcleos. No entanto, SQL Server decide em que condições irá tirar partido de um ou mais threads para processar uma consulta. Pode executar consultas e criar índices com vários threads. Para uma consulta que envolva associar tabelas grandes e ordenar dados antes de regressar ao utilizador, SQL Server provavelmente utilizará vários threads. No entanto, um utilizador não consegue controlar se SQL Server executa uma consulta com um único thread ou vários threads.

Existem definições de configuração que pode alterar para influenciar este processamento paralelo ou multi-threading de uma aplicação. Por exemplo, no caso de SQL Server é a configuração máxima do Grau de Paralelismo. Esta definição denominada MAXDOP permite-lhe configurar o número máximo de processadores SQL Server pode utilizar durante o processamento paralelo. Pode configurar MAXDOP para consultas individuais ou operações de índice. Isto é vantajoso quando quer equilibrar os recursos do seu sistema para uma aplicação crítica de desempenho.

Por exemplo, digamos que a aplicação que utiliza SQL Server está a executar uma consulta grande e uma operação de índice ao mesmo tempo. Vamos supor que queria que a operação de índice fosse mais eficaz em comparação com a consulta grande. Nesse caso, pode definir o valor MAXDOP da operação de índice como superior ao valor MAXDOP da consulta. Desta forma, SQL Server tem mais processadores que pode tirar partido para a operação de índice em comparação com o número de processadores que pode dedicar à consulta grande. Lembre-se de que não controla o número de threads SQL Server utilizará para cada operação. Pode controlar o número máximo de processadores dedicados para multi-threading.

Saiba mais sobre Graus de Paralelismo no SQL Server. Descubra estas definições que influenciam o multi-threading na sua aplicação e as respetivas configurações para otimizar o desempenho.

Profundidade da fila

A profundidade da fila, o comprimento da fila ou o tamanho da fila é o número de pedidos de E/S pendentes no sistema. O valor da profundidade da fila determina quantas operações de E/S a sua aplicação pode alinhar, que discos de armazenamento irão processar. Afeta todos os três indicadores de desempenho de aplicações que abordámos neste artigo viz., IOPS, débito e latência.

A Profundidade da Fila e a multi-threading estão intimamente relacionadas. O valor Profundidade da Fila indica a quantidade de threads múltiplos que a aplicação pode alcançar. Se a Profundidade da Fila for grande, a aplicação pode executar mais operações em simultâneo, ou seja, mais multi-threading. Se a Profundidade da Fila for pequena, apesar de a aplicação ter vários threads, não terá pedidos suficientes alinhados para execução simultânea.

Normalmente, as aplicações fora da prateleira não lhe permitem alterar a profundidade da fila, uma vez que, se definida incorretamente, causará mais danos do que bons. As aplicações irão definir o valor certo da profundidade da fila para obter o desempenho ideal. No entanto, é importante compreender este conceito para que possa resolver problemas de desempenho com a sua aplicação. Também pode observar os efeitos da profundidade da fila ao executar ferramentas de benchmarking no seu sistema.

Algumas aplicações fornecem definições para influenciar a Profundidade da Fila. Por exemplo, a definição MAXDOP (grau máximo de paralelismo) no SQL Server explicada na secção anterior. MAXDOP é uma forma de influenciar a Profundidade da Fila e o multi-threading, embora não altere diretamente o valor profundidade da fila de SQL Server.

Profundidade de fila elevada
Uma profundidade de fila elevada alinha mais operações no disco. O disco conhece o próximo pedido na fila com antecedência. Consequentemente, o disco pode agendar operações antecipadamente e processá-las numa sequência ideal. Uma vez que a aplicação está a enviar mais pedidos para o disco, o disco pode processar E/S mais paralelas. Em última análise, a aplicação conseguirá obter IOPS mais elevado. Uma vez que a aplicação está a processar mais pedidos, o débito total da aplicação também aumenta.

Normalmente, uma aplicação pode alcançar o débito máximo com mais de 8-16 E/S pendentes por disco anexado. Se uma profundidade de fila for uma, a aplicação não está a emitir E/S suficientes para o sistema e processará menos quantidade num determinado período. Por outras palavras, menos Débito.

Por exemplo, no SQL Server, definir o valor MAXDOP de uma consulta como "4" informa SQL Server que pode utilizar até quatro núcleos para executar a consulta. SQL Server determinará qual é o melhor valor de profundidade da fila e o número de núcleos para a execução da consulta.

Profundidade ideal da fila
O valor de profundidade da fila muito elevado também tem as suas desvantagens. Se o valor de profundidade da fila for demasiado elevado, a aplicação tentará conduzir IOPS muito elevado. A menos que a aplicação tenha discos persistentes com IOPS aprovisionado suficiente, isto pode afetar negativamente as latências da aplicação. A fórmula seguinte mostra a relação entre a IOPS, a latência e a profundidade da fila.
Um diagrama que mostra a equação I O P S times latency é igual a Profundidade da Fila.

Não deve configurar a Profundidade da Fila para qualquer valor elevado, mas para um valor ideal, que pode fornecer IOPS suficiente para a aplicação sem afetar as latências. Por exemplo, se a latência da aplicação precisar de ser de 1 milissegundos, a Profundidade da Fila necessária para alcançar 5000 IOPS é, QD = 5000 x 0,001 = 5.

Profundidade da Fila para o Volume Listrado
Para um volume listrado, mantenha uma profundidade de fila suficientemente alta para que cada disco tenha uma profundidade de fila de pico individualmente. Por exemplo, considere uma aplicação que emita uma profundidade de fila de 2 e existem quatro discos na faixa. Os dois pedidos de E/S irão para dois discos e os dois discos restantes ficarão inativos. Por conseguinte, configure a profundidade da fila de modo a que todos os discos possam estar ocupados. A fórmula abaixo mostra como determinar a profundidade da fila de volumes listrados.
Um diagrama que mostra a equação Q D por Disco vezes o número de colunas por volume é igual a Q D do Volume Listrado.

Limitação

O Azure Armazenamento Premium aprovisiona o número especificado de IOPS e Débito consoante os tamanhos de VM e tamanhos de disco que escolher. Sempre que a sua aplicação tentar impulsionar o IOPS ou o Débito acima destes limites do que a VM ou o disco consegue processar, Armazenamento Premium irá limitá-lo. Isto manifesta-se na forma de desempenho degradado na sua aplicação. Isto pode significar latência mais elevada, débito inferior ou IOPS mais baixo. Se Armazenamento Premium não limitar, a sua aplicação poderá falhar completamente ao exceder o que os seus recursos são capazes de alcançar. Assim, para evitar problemas de desempenho devido à limitação, aprovisione sempre recursos suficientes para a sua aplicação. Tenha em consideração o que discutimos nas secções Tamanhos de VM e Tamanhos do disco acima. O benchmarking é a melhor forma de descobrir que recursos precisará para alojar a sua aplicação.

Passos seguintes

Se pretender fazer uma referência ao disco, veja os nossos artigos sobre o benchmarking de um disco:

Saiba mais sobre os tipos de disco disponíveis:

Para SQL Server utilizadores, leia artigos sobre Melhores Práticas de Desempenho para SQL Server: