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 tempdb dados e os arquivos de log no volume D: SSD local ao implantar uma nova máquina virtual ou depois de instalar manualmente o SQL Server. A extensão do Agente de IaaS do SQL processa a pasta e as permissões necessárias no momento do novo provisionamento.
• 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 do 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).
• Se a carga de trabalho exigir mais de 160.000 IOPS, use o SSD Premium v2 ou o Azure Ultra Disks.
• 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 o padrão é D:\) 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 as FCI, (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 os 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.
• Ao migrar várias cargas de trabalho diferentes para a nuvem, o Azure Elastic SAN pode ser uma solução de armazenamento consolidada econômica. No entanto, ao usar o Azure Elastic SAN, a obtenção das IOPS e da taxa de transferência desejadas para cargas de trabalho do SQL Server geralmente requer capacidade de superprovisionamento. Embora normalmente não seja apropriado para cargas de trabalho únicas do SQL Server, você pode obter uma solução econômica ao combinar cargas de trabalho de baixo desempenho com o SQL Server.
• 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 do 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.
• Redimensione o pool de armazenamento adequadamente.

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. Se a carga de trabalho exigir mais de 160.000 IOPS, considere usar o SSD Premium v2 ou o Ultra Disks.

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 de sistema operacional é um disco VHD que pode ser arrancado e montado como uma versão ativa de um sistema operacional e está identificado 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á-lo para extensões do pool de buffers, 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. Se a carga de trabalho exigir mais de 160.000 IOPS, considere usar o SSD Premium v2 ou o Ultra Disks.

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.

SAN Elástico do Azure

O Azure Elastic SAN é uma oferta de NAS que fornece aos clientes uma solução flexível e escalável com o potencial para reduzir custos por meio da consolidação de armazenamento. O Azure Elastic SAN oferece uma solução de armazenamento em bloco econômica, com desempenho superior e confiável que se conecta a uma variedade de serviços de computação do Azure via 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 ser dimensionada para milhões de IOPS, dois dígitos de GB/s de taxa de transferência e latências baixas de um dígito de milissegundos, com resiliência integrada para minimizar o tempo de inatividade. Use o Azure Elastic SAN se precisar consolidar o armazenamento, trabalhar com vários serviços de computação ou tiver cargas de trabalho que exijam altos níveis de taxa de transferência ao direcionar o armazenamento pela largura de banda da rede. No entanto, como alcançar a IOPS/taxa de transferência desejada para cargas de trabalho do SQL Server geralmente requer capacidade de superprovisionamento, normalmente não é apropriado para cargas de trabalho individuais do SQL Server. Para obter a solução mais econômica com o Elastic SAN, considere usá-la como armazenamento para várias cargas de trabalho do SQL Server ou uma combinação de SQL Server e outras cargas de trabalho de baixo desempenho.

Considere colocar cargas de trabalho do SQL Server na SAN Elástica para melhorar a eficiência de custo, a consolidação do armazenamento, o compartilhamento dinâmico de desempenho e aumentar a taxa de transferência de armazenamento.

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 a 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, os dados.

A IOPS e a taxa de transferência provisionadas por disco que é usada como parte do pool de armazenamento. As capacidades combinadas de IOPS e de taxa de transferência dos discos representam a capacidade máxima, respeitando 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.

Escalar 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 lidem com uma demanda maior sem depender de explosão de disco.

Utilize o desempenho máximo durante o tempo necessário, onde a cobrança é ajustada para corresponder ao nível de desempenho do 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.

Discos rígidos padrão e SSDs padrão

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 o 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 alcançar 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 em cache e sem cache.

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

O limite máximo de taxa de transferência para armazenamento em cache e temporário é distinto do limite de taxa de transferência sem 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 máquinas virtuais podem ultrapassar os limites de IOPS e taxa de transferência das VMs que não utilizam armazenamento remoto em cache.

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 oferece 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 3.174 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 armazenada em cache da VM quando hospedado na unidade efêmera.

Importante

A alteração das configurações de cache de um disco do Azure desconecta e reconecta o disco de destino. Ao alterar a configuração de cache para um disco que hospeda dados, log ou arquivos de aplicativo do SQL Server, pare o serviço SQL Server junto com qualquer outro serviço relacionado para evitar corrupção de dados e garantir a integridade dos dados.

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 obter mais informações, consulte Tamanhos de VM.

Adicione mais discos de dados e use a distribuição de disco para alcançar 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, veja Distribuição de disco.

Utilização do limite em 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 limitação, utilize o armazenamento em cache ou ajuste o aplicativo para que seja necessária uma taxa de transferência menor.

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 do limite em disco e como usar o cache para evitar a utilização do limite, veja Utilização do limite na E/S de disco.

Observação

Um pouco da utilização do limite em 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	oito	10.000
M64ms, M64ls, M64s	oito	10.000
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.

Redimensionar conjuntos de armazenamento adequadamente

No Azure, quando você quiser redimensionar um pool de armazenamento, faça isso alterando o número de discos no pool, em vez de modificar o tamanho dos discos que já estão no pool. Alterar os tamanhos dos discos virtuais ou físicos em um pool de armazenamento não aumenta o espaço disponível do volume quando ele está dentro do pool de armazenamento, de modo que o espaço em disco aumentado seja não utilizado e desperdiçado.

Quanto ao SQL Server nas VMs do Azure implantadas do Azure Marketplace usando o SSD Premium (v1), os discos são adicionados automaticamente ao pool de armazenamento e você pode usar o Painel de armazenamento do recurso de máquinas virtuais SQL no portal do Azure para redimensionar os discos no pool de armazenamento.

Quanto às imagens do SQL Server no Marketplace da VM do Azure que usam discos SSD Premium v2 ou Discos Ultra, ou máquinas virtuais com instâncias auto-instaladas do SQL Server, modifique manualmente o número de discos no pool de armazenamento para alterar o tamanho do volume.

Por exemplo, siga estas etapas para expandir um pool de armazenamento:

1. Adicione um novo disco:
   1. Anexar um disco gerenciado no portal do Azure
   2. Anexar um disco gerenciado com o PowerShell
   3. Anexar um disco não gerenciado com o PowerShell
2. Conecte-se à máquina virtual.
3. Adicione os discos ao pool de armazenamento a partir do Gerenciador de Servidores> Serviços de Arquivos e Armazenamento > Volumes > Pools de Armazenamento. Use Tarefas para selecionar a opção Adicionar Disco Físico .
4. Depois que o disco for adicionado, clique com o botão direito do mouse no disco virtual de destino e selecione Estender disco virtual.
5. Abra o Gerenciamento de Disco, clique com o botão direito do mouse no volume de destino e selecione Estender Volume.

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 Disk Read Bytes/sec e Disk Write Bytes/sec do Monitor de Desempenho. Armazenamento de dados é otimizado para maximizar a taxa de transferência em relação aos 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 inestimáveis para identificar limitações no nível da VM e do disco, bem como o consumo e a saúde 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.

Monitorar o crescimento do log de transações

Como um log de transações completo pode causar problemas de desempenho e interrupções, é importante monitorar o espaço disponível no log de transações, bem como o espaço em disco utilizado da unidade que contém o log de transações. Resolva os problemas do log de transações antes que eles afetem sua carga de trabalho.

Veja Solução de problemas de um log de transações completo se o log ficar cheio.

Se você precisar estender seu disco, poderá fazê-lo no painel Armazenamento do recurso de máquinas virtuais SQL se tiver implantado uma imagem do SQL Server do Azure Marketplace ou no painel Discos para sua máquina virtual do Azure e o SQL Server autoinstalado.

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.