Armazenamento: melhores práticas de desempenho do SQL Server nas VMs do Azure

Aplica-se a:SQL Server na VM do Azure

Este artigo fornece diretrizes e melhores práticas de armazenamento para otimizar o desempenho dos SQL Server em VMs (Máquinas Virtuais) do Azure.

Normalmente, há uma compensação entre a otimização de custos e a otimização de desempenho. Esta série de melhores práticas de desempenho tem como foco obter o melhor desempenho do SQL Server em VMs do Azure. Se a sua carga de trabalho tem menos demanda, talvez você não precise realizar todas as otimizações recomendadas. Considere suas necessidades de desempenho, custos e padrões de carga de trabalho ao avaliar essas recomendações.

Para saber mais, confira os outros artigos desta série: Lista de verificação, tamanho da VM, Segurança, Configuração de HADR e Coletar linha de base.

Lista de verificação

Examine a seguinte lista de verificação para obter uma breve visão geral das melhores práticas de armazenamento abordadas mais detalhadamente no restante do artigo:

• Monitore o aplicativo e determine os requisitos de largura de banda e latência de armazenamento para os arquivos de dados, log e tempdb do SQL Server antes de escolher o tipo de disco.
• Se disponível, configure os tempdbarquivos de log e dados no volume SSD local D:. A extensão do Agente de IaaS do SQL administra a pasta e as permissões necessárias no reprovisionamento.
• Para otimizar o desempenho de armazenamento, planeje obter a IOPS mais alta não armazenada em cache disponível e use o cache de dados como um recurso de desempenho para leituras de dados, evitando a utilização de limite em discos e na máquina virtual.
• Ao usar as VMs do SQL Server das séries Ebdsv5 ou Ebsv5, use o SSD Premium v2 para obter o melhor desempenho de preço. Você pode implantar sua VM do SQL Server com o SSD Premium v2 usando o portal do Azure (atualmente em versão prévia).
• Considere usar o Azure Elastic SAN para cargas de trabalho do SQL Server para melhorar o custo-benefício devido à consolidação de armazenamento, ao desempenho dinâmico compartilhado e à capacidade de gerar maior produtividade de armazenamento sem a necessidade de atualizar uma VM.
• Coloque os arquivos de dados, log e tempdb em unidades separadas.
  • Na unidade de dados, use discos P30 e P40 premium ou menores para garantir a disponibilidade do suporte de cache. Ao usar a série de VMs Ebdsv5, use o SSD Premium v2, que fornece melhor relação preço/desempenho para cargas de trabalho que exigem alta taxa de transferência de E/S e IOPS.
  • Para a unidade de log, planeje o desempenho de capacidade e teste em relação ao custo ao avaliar os discos SSD Premium v2 ou SSD Premium P30 – P80
    • Se uma latência de armazenamento inferior a um milissegundo for necessária, use os discos SSD Premium v2 ou Discos Ultra do Azure para o log de transações.
    • Para implantações de máquinas virtuais da série M, considere usar o acelerador de gravação, em vez dos discos ultra do Azure.
  • Coloque tempdb no disco temporário (o disco temporário é efêmero e assume D:\ como padrão) para a maioria das cargas de trabalho do SQL Server que não fazem parte de uma FCI (instância de cluster de failover) depois de escolher o tamanho ideal da VM.
    • Se a capacidade da unidade local não for suficiente para tempdb, considere aumentar o tamanho da VM. Confira Políticas de cache de arquivo de dados para obter mais informações.
  • Para FCIs (instâncias de cluster de failover), coloque tempdb no armazenamento compartilhado.
    • Se a carga de trabalho da FCI for altamente dependente do desempenho do disco tempdb, usando uma configuração avançada coloque tempdb na unidade SSD efêmera local (D:\ padrão), que não faz parte do armazenamento da FCI. Essa configuração precisa de monitoramento e ação personalizados para garantir que a unidade SSD efêmera local (D:\ padrão) esteja disponível o tempo todo, pois as falhas dessa unidade não disparam uma ação da FCI.
• Distribua vários discos de dados do Azure usando Espaços de Armazenamento para aumentar a largura de banda de E/S até os limites da IOPS e de taxa de transferência da máquina virtual de destino.
• Defina o cache do host como somente leitura para discos de arquivo de dados.
• Defina o cache do host como nenhum para discos de arquivo de log.
  • Não habilite o cache de leitura/gravação em discos que contêm dados ou arquivos de log do SQL Server.
  • Sempre interrompa o serviço do SQL Server antes de alterar as configurações de cache do disco.
• Para cargas de trabalho de desenvolvimento e teste e arquivamento de backup de longo prazo, considere o uso do armazenamento padrão. Não recomendamos o uso do HDD/SSD Standard para cargas de trabalho de produção.
• O bursting de disco baseado em crédito (P1-P20) só deve ser considerado para cargas de trabalho de desenvolvimento/teste menores e sistemas departamentais.
• Para otimizar o desempenho de armazenamento, planeje obter a IOPS mais alta não armazenada em cache disponível e use o cache de dados como um recurso de desempenho para leituras de dados, evitando a limitação/utilização de limite em discos e na máquina virtual.
• Formate o disco de dados para usar o tamanho da unidade de alocação de 64 KB para todos os arquivos de dados colocados em uma unidade que não seja a unidade D:\ temporária (que tem um padrão de 4 KB). As VMs do SQL Server implantadas por meio do Azure Marketplace são fornecidas com discos de dados formatados com o tamanho da unidade de alocação e a intercalação para o pool de armazenamento definido como 64 KB.
• Configure a conta de armazenamento na mesma região da VM do SQL Server.
• Desabilite o armazenamento com redundância geográfica (replicação geográfica) do Azure e use o LRS (armazenamento com redundância local) na conta de armazenamento.
• Habilite a Avaliação de Melhores Práticas do SQL para identificar possíveis problemas de desempenho e avaliar se a sua VM do SQL Server está configurada para seguir as melhores práticas.
• Examine e monitore os limites de disco e da VM usando as Métricas de utilização de E/S de armazenamento.
• Exclua arquivos do SQL Server da verificação de software antivírus, incluindo arquivos de dados, arquivos de log e arquivos de backup.

Para comparar a lista de verificação de armazenamento com as outras melhores práticas, confira a Lista de verificação de melhores práticas de desempenho completa.

Visão geral

Para encontrar a configuração mais eficaz para cargas de trabalho do SQL Server em uma VM do Azure, comece medindo o desempenho de armazenamento do seu aplicativo de negócios. Quando os requisitos de armazenamento forem conhecidos, selecione uma máquina virtual que dê suporte à taxa de transferência e à IOPS necessárias com a proporção apropriada de memória para vCore.

Escolha um tamanho de VM com escalabilidade de armazenamento suficiente para a sua carga de trabalho e uma combinação de discos (geralmente em um pool de armazenamento) que atenda aos requisitos de capacidade e desempenho da sua empresa.

O tipo de disco depende do tipo de arquivo hospedado no disco e dos requisitos de desempenho de pico.

Dica

O provisionamento de uma VM do SQL Server por meio do portal do Azure ajuda a orientar você pelo processo de configuração de armazenamento e implementa a maioria das melhores práticas de armazenamento, como a criação de pools de armazenamento separados para os arquivos de dados e de log, o direcionamento de tempdb para a unidade D:\ e a habilitação da política de cache ideal. Para obter mais informações sobre como provisionar e configurar o armazenamento, confira Configuração de armazenamento da VM do SQL.

Tipos de disco da máquina virtual

Você tem uma opção de nível de desempenho para seus discos. Os tipos de discos gerenciados disponíveis como armazenamento subjacente (listados por funcionalidades de desempenho em ordem crescente) são HDDs (unidades de disco rígido) Standard, SSDs (unidades de estado sólido) Standard, SSDs Premium, SSDs Premium v2 e Discos Ultra.

Para HDDs Standard, SSDs Standard e SSDs Premium, o desempenho do disco aumenta com o tamanho dele, agrupado por rótulos de disco Premium, como P1 com 4 GiB de espaço e 120 IOPS para P80 com 32 TiB de armazenamento e 20.000 IOPS. O armazenamento Premium dá suporte a um cache de armazenamento que ajuda a aprimorar o desempenho de leitura e gravação para algumas cargas de trabalho. Para obter mais informações, confira Visão geral do Managed Disks.

O desempenho do SSD Premium v2 e dos Discos Ultra pode ser alterado independentemente do tamanho do disco. Para obter detalhes, confira Desempenho dos Discos Ultra e Desempenho do SSD Premium v2.

Também há três funções de discos principais a serem consideradas para o SQL Server na VM do Azure: um disco do SO, um disco temporário e os discos de dados. Escolha cuidadosamente o que é armazenado na unidade (C:\) do sistema operacional e na unidade temporária efêmera (D:\).

Disco do sistema operacional

Um disco do SO é um VHD que pode ser inicializado e montado como uma versão em execução de um sistema operacional e é rotulado como a unidade C:\. Quando você cria uma máquina virtual do Azure, a plataforma anexa, no mínimo, um disco à VM para o disco do SO. A unidade C:\ é a localização padrão para as instalações de aplicativo e a configuração de arquivo.

Para ambientes de produção do SQL Server, não use o disco do SO para arquivos de dados, arquivos de log e logs de erros.

Disco temporário

Muitas VMs do Azure contêm outro disco chamado disco temporário (rotulado como a unidade D:\). Dependendo da série e do tamanho da VM, a capacidade do disco poderá variar. O disco temporário é efêmero, o que significa que o armazenamento em disco é recriado (como em, ele é desalocado e alocado novamente), quando a VM é reiniciada ou movida para um host diferente (para a recuperação de serviço, por exemplo).

A unidade de armazenamento temporário não é persistida no armazenamento remoto e, portanto, não deve armazenar arquivos de banco de dados de usuário, arquivos de log de transações ou qualquer item que precise ser preservado. Por exemplo, você pode usá-la para extensões de pool de buffer, o arquivo de paginação e tempdb.

Coloque tempdb na unidade SSD D:\ temporária local para cargas de trabalho do SQL Server, a menos que o consumo do cache local seja uma preocupação. Se você está usando uma VM que não tem um disco temporário, recomendamos colocar tempdb em um disco isolado próprio ou no pool de armazenamento com o cache definido como somente leitura. Para saber mais, confira Políticas de cache de dados do tempdb.

Discos de dados

Em geral, os discos de dados são discos de armazenamento remoto criados em pools de armazenamento para exceder a capacidade e o desempenho que qualquer disco individual poderá oferecer à VM.

Anexe o número mínimo de discos que atendam aos requisitos de IOPS, taxa de transferência e capacidade da carga de trabalho. Não exceda o número máximo de discos de dados da menor VM que você pretende redimensionar.

Coloque os arquivos de dados e de log em discos de dados provisionados para atender melhor aos requisitos de desempenho.

Formate o disco de dados para usar o tamanho da unidade de alocação de 64 KB para todos os arquivos de dados colocados em uma unidade que não seja a unidade D:\ temporária (que tem um padrão de 4 KB). As VMs do SQL Server implantadas por meio do Azure Marketplace são fornecidas com discos de dados formatados com o tamanho da unidade de alocação e a intercalação para o pool de armazenamento definido como 64 KB.

Observação

Também é possível hospedar seus arquivos de banco de dados SQL Server diretamente no Armazenamento de Blobs do Azure ou no armazenamento SMB, como o compartilhamento de arquivos Premium do Azure, mas é recomendável usar o Azure Managed Disks para obter o melhor desempenho, confiabilidade e disponibilidade de recursos.

SSD Premium v2

Você deve usar discos SSD Premium v2 ao executar cargas de trabalho SQL Server em regiões com suporte, se as limitações atuais forem adequadas para seu ambiente. Dependendo de sua configuração, o SSD Premium v2 pode ser mais barato que os SSDs Premium, além de fornecer aprimoramentos de desempenho. Com o SSD Premium v2, você pode ajustar individualmente sua taxa de transferência ou IOPS independentemente do tamanho do disco. Ser capaz de ajustar individualmente as opções de desempenho permite essa maior economia de custos e permite que você crie scripts de alterações para atender aos requisitos de desempenho durante períodos de necessidade previstos ou conhecidos.

É recomendável usar o SSD Premium v2 ao usar a série de máquinas virtuais Ebdsv5 ou Ebsv5, pois ela é uma solução mais econômica para esses computadores com alta taxa de transferência de E/S.

Você pode implantar suas VMs do SQL Server com o SSD Premium v2 usando o portal do Azure (atualmente em versão prévia).

Se você estiver implantando a VM do SQL Server usando o portal do Azure e quiser usar o SSD Premium v2, atualmente estará restrito às máquinas virtuais das séries Ebdsv5 ou Ebsv5. No entanto, se você criar manualmente a VM com armazenamento SSD Premium v2 e depois instalar manualmente o SQL Server na VM, poderá usar qualquer série de VM que ofereça suporte ao SSD Premium v2. Certifique-se de registrar sua VM do SQL Server com a extensão SQL IaaS Agent para poder aproveitar todos os benefícios fornecidos pela extensão.

Azure Elastic SAN

O Azure Elastic SAN oferece uma solução de armazenamento em bloco altamente escalável, econômica, de desempenho superior e confiável que se conecta a uma variedade de serviços de computação do Azure pelo protocolo iSCSI. O Elastic SAN permite uma transição perfeita de um ambiente de armazenamento SAN existente para a nuvem sem a necessidade de refatorar a arquitetura de aplicativos do cliente. Essa solução pode alcançar uma escala vertical massiva: capacidade para milhões de IOPS por segundo, taxa de transferência de GB/s de dois dígitos e latências de milissegundos de um dígito, além de contar com resiliência interna para minimizar períodos de inatividade. Isso a torna uma ótima opção para clientes que desejam consolidar o armazenamento, clientes que trabalham com vários serviços de computação ou aqueles que têm cargas de trabalho que exigem altos níveis de taxa de transferência para administrar o armazenamento pela largura de banda de rede. 

Observação

• O dimensionamento de VM com o Elastic SAN deve acomodar os requisitos de taxa de transferência de rede de produção (VM para VM) junto com a taxa de transferência de armazenamento.

Considere colocar cargas de trabalho do SQL Server no Elastic SAN para obter melhor eficiência de custos porque:

• Consolidação de armazenamento e compartilhamento dinâmico de desempenho: normalmente para cargas de trabalho de VM do SQL Server no Azure, o armazenamento em disco é provisionado para cada VM com base na capacidade do cliente e nos requisitos de desempenho máximo para essa VM. Esse desempenho superprovisionado está disponível quando necessário, mas o desempenho não utilizado não pode ser compartilhado com cargas de trabalho em outras VMs. O Elastic SAN, semelhante a um SAN local, permite consolidar as necessidades de armazenamento de várias cargas de trabalho, tanto SQL quanto não SQL, para obter uma economia maior. Além disso, ele oferece a capacidade de compartilhar dinamicamente o desempenho provisionado entre os volumes provisionados para essas diferentes cargas de trabalho com base nas demandas de E/S. Por exemplo, imagine que na região Leste dos EUA você tenha 10 cargas de trabalho que requerem 2 TiB de capacidade e 10 mil IOPS cada uma, mas coletivamente elas não precisam de mais de 60 mil IOPS em nenhum momento. Você pode configurar um Elastic SAN com 12 unidades base (1 unidade base = US$ 0,08 por GiB/mês) que lhe darão 12 TiB de capacidade e as 60 mil IOPS necessárias, e 8 unidades somente de capacidade (1 unidade somente de capacidade = US$ 0,06 por GiB/mês), que lhe darão a capacidade restante de 8 TiB a um preço mais barato. Essa configuração otimizada de armazenamento fornece melhor custo-benefício e, ao mesmo tempo, garante o desempenho necessário (10 mil IOPS) para cada uma dessas cargas de trabalho. Para obter mais informações sobre a base do Elastic SAN e unidades de provisionamento somente de capacidade, acesse Planejar um Azure Elastic SAN e, para ver os preços, acesse Azure Elastic SAN: preços.
• Para alcançar uma taxa de transferência de armazenamento mais alta: em implantações do SQL Server em VMs do Azure, ocasionalmente é necessário o superprovisionamento de recursos para uma VM devido aos limites de taxa de transferência de disco para essa VM. Isso pode ser evitado com o Elastic SAN, já que com ele você gera maior taxa de transferência de armazenamento sobre a largura de banda da rede de computação com o protocolo iSCSI. Por exemplo, a taxa de transferência de disco/armazenamento de uma VM Standard_E32bds_v5 (SCSI) é limitada a 88 mil IOPS e 2.500 MBps, mas ela pode alcançar até um máximo de 16 mil MBps de taxa de transferência de rede. Se o requisito de taxa de transferência de armazenamento para sua carga de trabalho for maior que 2.500 MBps, você não precisará atualizar a VM com uma SKU mais alta, uma vez que agora ela aceita até 16 mil MBps utilizando o Elastic SAN.

SSD Premium

Use SSDs Premium para arquivos de dados e de log para cargas de trabalho de produção do SQL Server. A IOPS e a largura de banda dos SSDs Premium variam de acordo com o tamanho e o tipo do disco.

Para cargas de trabalho de produção, use os discos P30 e/ou P40 para arquivos de dados do SQL Server a fim de garantir o suporte de cache e P30-P80 para arquivos de log de transações do SQL Server. Para obter o melhor custo total de propriedade, comece com P30s (5000 IOPS/200 MBPS) para arquivos de dados e de log e só escolha capacidades mais altas quando precisar controlar a contagem de discos da VM. Para sistemas de desenvolvimento/teste ou pequenos, você pode optar por usar tamanhos menores que P30, pois eles dão suporte ao cache, mas não oferecem preços reservados.

Para cargas de trabalho OLTP, combina a IOPS de destino por disco (ou o pool de armazenamento) com seus requisitos de desempenho usando cargas de trabalho em horários de pico e os contadores de desempenho Disk Reads/sec + Disk Writes/sec. Para cargas de trabalho de data warehouse e relatórios, combine a taxa de transferência de destino usando cargas de trabalho em horários de pico e o Disk Read Bytes/sec + Disk Write Bytes/sec.

Use os Espaços de Armazenamento para obter um desempenho ideal e configure dois pools, um para os arquivos de log e outro para os arquivos de dados. Se você não estiver usando distribuição de disco, use dois discos SSD Premium mapeados para unidades separadas, em que uma unidade contém o arquivo de log e a outra contém os dados.

A IOPS e a taxa de transferência provisionadas por disco que é usada como parte do pool de armazenamento. As funcionalidades combinadas de IOPS e taxa de transferência dos discos são a capacidade máxima até os limites de taxa de transferência da VM.

A melhor prática é usar o menor número de discos possíveis atendendo aos requisitos mínimos da IOPS (e da taxa de transferência) e à capacidade. No entanto, o equilíbrio entre o preço e o desempenho tende a ser melhor com um número grande de discos pequenos, em vez de um número pequeno de discos grandes.

Dimensionar discos premium

O tamanho do SSD Premium determina o nível de desempenho inicial do disco. Designe o nível de desempenho na implantação ou altere-o posteriormente, sem alterar o tamanho do disco. Se a demanda aumentar, você poderá aumentar o nível de desempenho de acordo com suas necessidades comerciais.

A alteração do nível de desempenho permite que os administradores se preparem e atendam a uma demanda mais alta sem depender do bursting de disco.

Use o desempenho mais alto durante o tempo necessário, em que a cobrança é projetada para o nível de desempenho de armazenamento. Atualize a camada para que ela corresponda aos requisitos de desempenho sem aumentar a capacidade. Volte à camada original quando o desempenho extra não for mais necessário.

Essa expansão econômica e temporária do desempenho é um caso de uso eficaz para eventos direcionados, como compras, testes de desempenho, eventos de treinamento e outras janelas curtas, em que um desempenho mais alto é necessário apenas por um curto período.

Para obter mais informações, confira Níveis de desempenho dos discos gerenciados.

Disco ultra do Azure

Se houver a necessidade de tempos de resposta inferiores a um milissegundo com latência reduzida, considere o uso do disco ultra do Azure na unidade de log do SQL Server ou, até mesmo, na unidade de dados para aplicativos que são extremamente sensíveis à latência de E/S.

O disco ultra pode ser configurado quando a capacidade e a IOPS podem ser escaladas de modo independente. Com os administradores do disco ultra, é possível provisionar um disco com os requisitos de capacidade, IOPS e taxa de transferência de acordo com as necessidades do aplicativo.

Não há suporte para o disco ultra em todas as séries de VMs, e há outras limitações, como disponibilidade de região, redundância e suporte para o Backup do Azure. Para saber mais, confira Como usar os discos ultra do Azure para obter uma lista completa das limitações.

HDDs e SSDs Standard

Os SSDs e os HDDs Standard têm largura de banda e latências variáveis e só são recomendados para cargas de trabalho de desenvolvimento/teste. As cargas de trabalho de produção devem usar o SSD Premium v2 ou SSDs Premium. Se você estiver usando SSD Standard (cenários de desenvolvimento/teste), a recomendação será adicionar o número máximo de discos de dados com suporte no tamanho da VM e usar a distribuição de disco com os Espaços de Armazenamento para obter o melhor desempenho.

Cache

As VMs que dão suporte ao cache de armazenamento Premium podem aproveitar um recurso adicional chamado BlobCache do Azure ou cache do host para estender as funcionalidades de IOPS e taxa de transferência de uma VM. As VMs habilitadas para o armazenamento Premium e o cache de armazenamento Premium têm esses dois limites diferentes de largura de banda de armazenamento que podem ser usados em conjunto para aprimorar o desempenho de armazenamento.

A taxa de transferência de IOPS e MBps sem o cache é contada em relação aos limites de taxa de transferência de disco não armazenados em cache de uma VM. Os limites máximos armazenados em cache fornecem um buffer adicional para leituras que ajudam a lidar com o crescimento e picos inesperados.

Habilite o cache Premium sempre que a opção tiver suporte para aprimorar significativamente o desempenho de leituras na unidade de dados sem custo adicional.

As leituras e as gravações no BlobCache do Azure (IOPS e taxa de transferência armazenadas em cache) não são contadas em relação aos limites de taxa de transferência e IOPS não armazenados em cache da VM.

Observação

Não há suporte para o cache de disco em discos de 4 TiB e maiores (P50 e superior). Se vários discos estiverem anexados à sua VM, cada disco com menos de 4 TiB dará suporte ao cache. Para obter mais informações, confira Cache de disco.

Taxa de transferência não armazenada em cache

A quantidade máxima de IOPS e taxa de transferência de disco não armazenadas em cache é o limite máximo de armazenamento remoto que a VM pode processar. Esse limite é definido na VM e não é um limite do armazenamento em disco subjacente. Ele só se aplica à E/S em unidades de dados anexadas remotamente à VM, não à E/S local na unidade temporária (unidade D:\) ou na unidade do sistema operacional.

A quantidade de IOPS e taxa de transferência não armazenadas em cache disponível para uma VM pode ser verificada na documentação da VM.

Por exemplo, a documentação da série M mostra que a quantidade máxima de taxa de transferência não armazenada em cache para a VM Standard_M8ms é de 5.000 IOPS e 125 Mbps de taxa de transferência de disco não armazenada em cache.

Da mesma forma, você pode ver que a Standard_M32ts dá suporte a 20.000 IOPS de disco não armazenada em cache e 500 MBps de taxa de transferência de disco não armazenada em cache. Esse limite é regido no nível da VM, independentemente do armazenamento em disco Premium subjacente.

Para obter mais informações, confira Limites armazenados e não armazenados em cache.

Taxa de transferência de armazenamento temporário e armazenado em cache

O limite máximo de taxa de transferência de armazenamento em cache e temporário é um limite separado do limite de taxa de transferência não armazenado em cache na VM. O BlobCache do Azure consiste em uma combinação da memória de acesso aleatório do host da VM e do SSD anexado localmente. A unidade temporária (unidade D:\) na máquina virtual também é hospedada nesse SSD local.

O limite máximo de taxa de transferência de armazenamento em cache e temporário controla a E/S em relação à unidade temporária local (unidade D:\) e ao BlobCache do Azure somente se o cache do host está habilitado.

Quando o cache está habilitado no armazenamento Premium, as VMs podem ser escaladas além dos limites de taxa de transferência e IOPS da VM não armazenadas em cache do armazenamento remoto.

Somente algumas VMs dão suporte ao armazenamento Premium e ao cache de armazenamento Premium (que precisa ser verificado na documentação da máquina virtual). Por exemplo, a documentação da série M indica que há suporte para o armazenamento Premium e o cache de armazenamento Premium:

Os limites do cache variam de acordo com o tamanho da VM. Por exemplo, a VM Standard_M8ms dá suporte a 10000 IOPS de disco armazenada em cache e 1000 MBps de taxa de transferência de disco armazenada em cache com um tamanho total de cache de 793 GiB. Da mesma forma, a VM Standard_M32ts dá suporte a 40000 IOPS de disco armazenada em cache e 400 MBps de taxa de transferência de disco armazenada em cache com um tamanho total de cache de 3174 GiB.

Você pode habilitar o cache do host manualmente em uma VM existente. Interrompa todas as cargas de trabalho do aplicativo e os serviços SQL Server antes que as alterações sejam feitas na política de cache da VM. A alteração de uma das configurações de cache da VM resulta na desanexação e na nova anexação do disco de destino após a aplicação das configurações.

Políticas de cache de arquivo de dados

A política de cache de armazenamento varia dependendo do tipo de arquivos de dados do SQL Server hospedados na unidade.

A seguinte tabela fornece um resumo das políticas de cache recomendadas com base no tipo de dados do SQL Server:

Disco do SQL Server	Recomendação
Disco de dados	Habilite o cache Read-only para os discos que hospedam arquivos de dados do SQL Server. As leituras do cache serão mais rápidas do que as leituras não armazenadas em cache do disco de dados. A IOPS e a taxa de transferência não armazenadas em cache, além da IOPS e da taxa de transferência armazenadas em cache geram o desempenho total possível disponível na VM dentro dos limites das VMs, mas o desempenho real varia com base na capacidade da carga de trabalho de usar o cache (taxa de ocorrências no cache).
Disco de log de transações	Defina a política de cache como None para discos que hospedam o log de transações. Não há nenhum benefício de desempenho em habilitar o cache para o disco de log de transações e, na verdade, ter o cache Read-only ou Read/Write habilitado na unidade de log pode prejudicar o desempenho das gravações na unidade e diminuir a quantidade de cache disponível para leituras na unidade de dados.
Disco do SO	A política de cache padrão é Read/write para a unidade do sistema operacional. Não recomendamos alterar o nível de cache da unidade do sistema operacional.
tempdb	Se tempdb não puder ser colocado na unidade efêmera D:\ por motivos de capacidade, redimensione a VM para obter uma unidade efêmera maior ou coloque tempdb em uma unidade de dados separada com o cache Read-only configurado. Tanto o cache da VM quanto a unidade efêmera usam o SSD local. Portanto, tenha isso em mente ao fazer o dimensionamento, pois a E/S de tempdb será contabilizada em relação aos limites de taxa de transferência e IOPS armazenados em cache da VM quando hospedado na unidade efêmera.

Importante

A alteração da configuração de cache de um disco do Azure desanexa e anexa novamente o disco de destino. Ao alterar a configuração de cache para um disco que hospeda SQL Server de dados, log ou arquivos de aplicativo, pare o serviço SQL Server com os outros serviços relacionados para evitar dados corrompidos.

Para saber mais, confira Cache de disco.

Distribuição de discos

Analise a taxa de transferência e a largura de banda necessárias para seus arquivos de dados SQL a fim de determinar o número de discos de dados, incluindo o arquivo de log e o tempdb. Os limites de taxa de transferência e largura de banda variam de acordo com o tamanho da VM. Para saber mais, confira Tamanho da VM

Adicione discos de dados extras e use a distribuição de disco para obter uma taxa de transferência maior. Por exemplo, um aplicativo que precisa de 12.000 IOPS e 180 MB/s de taxa de transferência pode usar três discos P30 distribuídos para fornecer 15.000 IOPS e 600 MB/s de taxa de transferência.

Para configurar a distribuição de disco, confira Distribuição de disco.

Utilização de limite no disco

Há limites de taxa de transferência no nível do disco e da VM. Os limites máximos de IOPS por VM e por disco são diferentes e independentes um do outro.

Os aplicativos que consomem recursos além desses limites serão limitados. Selecione uma VM e um tamanho do disco em uma distribuição de disco que atenda aos requisitos do aplicativo e que não terá limitações de utilização. Para solucionar a utilização de limite, use o cache ou ajuste o aplicativo para que uma taxa de transferência menor seja necessária.

Por exemplo, um aplicativo que precisa de 12.000 IOPS e 180 MB/s pode:

• Usar a Standard_M32ms, que tem uma taxa de transferência máxima de disco não armazenada em cache de 20.000 IOPS e 500 Mbps.
• Distribua três discos P30 para fornecer uma taxa de transferência de 15.000 IOPS e 600 MB/s.
• Use uma VM Standard_M16ms e use o cache do host para utilizar o cache local em vez da taxa de transferência de consumo.

As VMs configuradas para serem escaladas verticalmente durante os tempos de alta utilização devem provisionar o armazenamento com IOPS e taxa de transferência suficientes para dar suporte ao tamanho máximo de VM, mantendo o número total de discos inferior ou igual ao número máximo com suporte no menor SKU de VM destinado a ser usado.

Para obter mais informações sobre as limitações da utilização de limite no disco e como usar o cache para evitar a utilização de limite, confira Utilização de limite na E/S de disco.

Observação

Um pouco da utilização de limite de disco ainda poderá resultar em um desempenho satisfatório para os usuários: ajuste e mantenha cargas de trabalho em vez de fazer o redimensionamento para uma VM maior a fim de equilibrar o gerenciamento de custo e desempenho para os negócios.

Aceleração de gravação

A aceleração de gravação é um recurso de disco disponível somente para VMs da série M. A finalidade da aceleração de gravação é aprimorar a latência de E/S das gravações no Armazenamento Premium do Azure quando você precisa de latência de E/S de dígito único devido a cargas de trabalho OLTP críticas de alto volume ou ambientes de data warehouse.

Use a aceleração de gravação para aprimorar a latência de gravação na unidade que hospeda os arquivos de log. Não use a aceleração de gravação para arquivos de dados do SQL Server.

Todos os discos do Acelerador de Gravação compartilham o mesmo limite IOPS que a VM. Os discos anexados não podem exceder o limite de IOPS do Acelerador de Gravação para uma VM.

A seguinte tabela descreve o número de discos de dados e IOPS com suporte por VM:

SKU da VM	Nº de discos do Acelerador de Gravação	IOPS de disco do Acelerador de Gravação por VM
M416ms_v2, M416s_v2	16	20000
M128ms, M128s	16	20000
M208ms_v2, M208s_v2	8	10000
M64ms, M64ls, M64s	8	10000
M32ms, M32ls, M32ts, M32s	4	5.000
M16ms, M16s	2	2500
M8ms, M8s	1	1250

Há várias restrições ao uso da aceleração de gravação. Para saber mais, confira Restrições no uso do Acelerador de Gravação.

Comparar com o disco ultra do Azure

A maior diferença entre a aceleração de gravação e os discos ultra do Azure é que a aceleração de gravação é um recurso de VM disponível somente para a série M e os discos ultra do Azure são uma opção de armazenamento. A aceleração de gravação é um cache otimizado para gravação com limitações próprias baseadas no tamanho da VM. Os discos ultra do Azure são uma opção de armazenamento em disco de baixa latência para VMs do Azure.

Se possível, use a aceleração de gravação em vez dos discos ultra para o disco de log de transações. Para as VMs que não dão suporte à aceleração de gravação, mas exigem baixa latência para o log de transações, use os Discos Ultra do Azure.

Monitorar o desempenho de armazenamento

Para avaliar as necessidades de armazenamento e determinar o desempenho de armazenamento, você precisa entender o que medir e o que esses indicadores significam.

IOPS (Entrada/Saída por segundo) é o número de solicitações que o aplicativo faz para o armazenamento por segundo. Meça a IOPS usando os contadores Disk Reads/sec e Disk Writes/sec do Monitor de Desempenho. Os aplicativos OLTP (processamento de transações online) precisam gerar uma IOPS mais alta para obter um desempenho ideal. Aplicativos como sistemas de processamento de pagamento, compras online e sistemas de ponto de venda de varejo são exemplos de aplicativos OLTP.

A taxa de transferência é o volume de dados enviado para o armazenamento subjacente, geralmente medido em megabytes por segundo. Meça a taxa de transferência com os contadores do Disk Read Bytes/sec e Disk Write Bytes/sec do Monitor de Desempenho. O data warehouse é otimizado em relação à maximização da taxa de transferência em IOPS. Aplicativos como armazenamentos de dados para análise, relatórios, fluxos de trabalho de ETL e outros destinos de business intelligence são exemplos de aplicativos de data warehouse.

Os tamanhos da unidade de E/S influenciam as funcionalidades de IOPS e taxa de transferência, pois tamanhos menores de E/S geram uma IOPS mais alta e tamanhos maiores de E/S geram uma taxa de transferência mais alta. O SQL Server escolhe o tamanho de E/S ideal automaticamente. Para obter mais informações sobre, confira Otimizar a IOPS, a taxa de transferência e a latência para seus aplicativos.

Há métricas específicas do Azure Monitor que são úteis para descobrir a utilização de limite no nível da VM e do disco, bem como o consumo e a integridade do cache do AzureBlob. Para identificar os principais contadores a serem adicionados à sua solução de monitoramento e ao painel do portal do Azure, confira Métricas de utilização de armazenamento.

Observação

Atualmente, o Azure Monitor não oferece métricas no nível do disco para a unidade temporária efêmera (D:\). O Percentual Consumido de IOPS Armazenada em Cache da VM e o Percentual Consumido de Largura de Banda Armazenada em Cache da VM refletirão a IOPS e a taxa de transferência da unidade temporária efêmera (D:\) e do cache do host juntos.

Próximas etapas

Para saber mais, confira os outros artigos desta série de melhores práticas:

• Lista de verificação rápida

• Tamanho da VM

• Segurança

• Configurações de HADR

• Coletar linha de base

• Para obter as melhores práticas de segurança, confira Considerações sobre segurança para o SQL Server em Máquinas Virtuais do Azure.

• – Para obter testes detalhados de desempenho do SQL Server em VMs do Azure com avaliações de desempenho de TPC-E e TPC_C, veja o blog Otimizar o desempenho de OLTP.

• Revise outros artigos sobre Máquinas Virtuais do SQL Server em Visão geral do SQL Server nas Máquinas Virtuais do Azure. Em caso de dúvidas sobre máquinas virtuais do SQL Server, consulte as Perguntas frequentes.