Armazenamento: práticas recomendadas de desempenho para o SQL Server em VMs do Azure

Aplica-se a:SQL Server na VM do Azure

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

Normalmente, há um compromisso entre otimizar para custos e otimizar para desempenho. Esta série de práticas recomendadas de desempenho se concentra em obter o melhor desempenho para o SQL Server em VMs do Azure. Se sua carga de trabalho for menos exigente, talvez você não precise de 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, consulte os outros artigos desta série: Lista de verificação, tamanho da VM, Segurança, Configuração HADR e Coletar linha de base.

Lista de Verificação

Analise a lista de verificação a seguir para obter uma breve visão geral das práticas recomendadas de armazenamento abordadas com mais detalhes no restante do artigo:

• Monitore o aplicativo e determine os requisitos de largura de banda de armazenamento e latência para dados, log e tempdb arquivos do SQL Server antes de escolher o tipo de disco.
• Se disponível, configure os dados e os tempdbarquivos de log no volume SSD D: local. A extensão do SQL IaaS Agent lida com a pasta e as permissões necessárias durante o reprovisionamento.
• Para otimizar o desempenho do armazenamento, planeje as IOPS sem cache mais altas disponíveis e use o cache de dados como um recurso de desempenho para leituras de dados, evitando a limitação de máquinas virtuais e discos.
• Considere o uso do Azure Elastic SAN para cargas de trabalho do SQL Server para obter melhor eficiência de custos devido à consolidação do armazenamento, ao desempenho dinâmico compartilhado e à capacidade de gerar uma taxa de transferência de armazenamento mais alta sem a necessidade de atualizar uma VM.
• Coloque dados, log e tempdb arquivos em unidades separadas.
  • Para a unidade de dados, use discos premium P30 e P40 ou menores para garantir a disponibilidade do suporte de cache. Ao usar a série de VMs Ebdsv5, use o SSD Premium v2, que oferece melhor desempenho de preço para cargas de trabalho que exigem alta IOPS e taxa de transferência de E/S.
  • Para o plano de drive de log para capacidade e desempenho de teste versus custo ao avaliar discos SSD Premium v2 ou SSD Premium P30 - P80
    • Se a latência de armazenamento de submilissegundos for necessária, use o SSD Premium v2 ou os discos Ultra do Azure para o log de transações.
    • Para implantações de máquina virtual da série M, considere o acelerador de gravação usando 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 tempdbo , considere dimensionar a VM. Para obter mais informações, consulte Políticas de cache de arquivos de dados.
  • Para FCI, coloque tempdb no armazenamento compartilhado.
    • Se a carga de trabalho FCI depender fortemente do desempenho do disco, então como um local tempdb de configuração avançada na unidade SSD efêmera local (padrãoD:\), que não faz parte do tempdb armazenamento FCI. Essa configuração precisa de monitoramento e ação personalizados para garantir que a unidade SSD efêmera local (padrão D:\) esteja disponível o tempo todo, pois qualquer falha dessa unidade não desencadeará a 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 de IOPS e taxa de transferência da máquina virtual de destino.
• Defina o cache do host como somente leitura para discos de arquivos de dados.
• Defina o cache do host como nenhum para discos de arquivo de log.
  • Não ative a colocação em cache de leitura/escrita em discos que contêm dados ou ficheiro de registo do SQL Server.
  • Pare sempre o serviço SQL Server antes de alterar as definições de cache do disco.
• Para cargas de trabalho de desenvolvimento e teste e arquivamento de backup de longo prazo, considere o uso de armazenamento padrão. Não é recomendado o uso de HDD/SSD padrão para cargas de trabalho de produção.
• O Disk Bursting 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 do armazenamento, planeje as IOPS sem cache mais altas disponíveis e use o cache de dados como um recurso de desempenho para leituras de dados, evitando a limitação/limitação de máquinas virtuais e discos.
• Formate seu 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 diferente da unidade temporária D:\ (que tem um padrão de 4 KB). As VMs do SQL Server implantadas por meio do Azure Marketplace vêm com discos de dados formatados com tamanho de unidade de alocação e intercalação para o pool de armazenamento definido como 64 KB.
• Configure a conta de armazenamento na mesma região que a VM do SQL Server.
• Desative o armazenamento com redundância geográfica do Azure (replicação geográfica) e use o LRS (armazenamento redundante local) na conta de armazenamento.
• Habilite a Avaliação de Práticas Recomendadas do SQL para identificar possíveis problemas de desempenho e avaliar se sua VM do SQL Server está configurada para seguir as práticas recomendadas.
• Revise e monitore os limites de disco e VM usando 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 práticas recomendadas, consulte a lista de verificação abrangente de práticas recomendadas de desempenho.

Descriçã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 ofereça suporte às IOPS e à taxa de transferência necessárias com a relação memória/vCore apropriada.

Escolha um tamanho de VM com escalabilidade de armazenamento suficiente para sua carga de trabalho e uma mistura de discos (geralmente em um pool de armazenamento) que atendam aos requisitos de capacidade e desempenho de sua empresa.

O tipo de disco depende do tipo de arquivo hospedado no disco e dos seus requisitos de desempenho máximo.

Gorjeta

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

Tipos de disco de VM

Você pode escolher o nível de desempenho dos seus discos. Os tipos de discos geridos disponíveis como armazenamento subjacente (listados de acordo com as capacidades de desempenho crescentes) são unidades de disco rígido (HDD) padrão, unidades de estado sólido (SSD) padrão, SSDs Premium, SSD Premium v2 e Ultra Disks.

Para HDDs padrão, SSDs padrão e SSDs premium, o desempenho do disco aumenta com o tamanho do disco, agrupado por rótulos de disco premium como o P1 com 4 GiB de espaço e 120 IOPS para o P80 com 32 TiB de armazenamento e 20.000 IOPS. O armazenamento Premium suporta um cache de armazenamento que ajuda a melhorar o desempenho de leitura e gravação para algumas cargas de trabalho. Para obter mais informações, consulte Visão geral de discos gerenciados.

O desempenho dos discos Premium SSD v2 e Ultra pode ser alterado independentemente do tamanho do disco, para obter detalhes, consulte Desempenho do disco Ultra e Desempenho do SSD Premium v2.

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

Disco do sistema operativo

Um disco do sistema operacional é um VHD que pode ser inicializado e montado como uma versão em execução de um sistema operacional e é rotulado como a C:\ unidade. Quando cria uma VM do Azure, a plataforma anexa, pelo menos, um disco à VM para o disco do sistema operativo. A C:\ unidade é o local padrão para instalações de aplicativos e configuração de arquivos.

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

Disco temporário

Muitas VMs do Azure contêm outro tipo de disco chamado disco temporário (rotulado como unidade D:\ ). Dependendo da série VM e do tamanho, a capacidade deste disco varia. 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 recuperação de serviço, por exemplo).

A unidade de armazenamento temporário não é mantida para o armazenamento remoto e, como tal, não deve armazenar ficheiros da base de dados de utilizador, ficheiros de registo de transações ou qualquer item que deva ser preservado.

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

Discos de dados

Os discos de dados são discos de armazenamento remoto que geralmente são criados em pools de armazenamento para exceder a capacidade e o desempenho que qualquer disco único poderia oferecer à VM.

Anexe o número mínimo de discos que satisfaça os requisitos de IOPS, taxa de transferência e capacidade da sua carga de trabalho. Não exceda o número máximo de discos de dados da menor VM para a qual você planeja redimensionar.

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

Formate seu 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 diferente da unidade temporária D:\ (que tem um padrão de 4 KB). As VMs do SQL Server implantadas por meio do Azure Marketplace vêm com discos de dados formatados com tamanho de unidade de alocação e intercalação para o pool de armazenamento definido como 64 KB.

Nota

Também é possível hospedar seus arquivos de banco de dados do SQL Server diretamente no armazenamento de Blob do Azure ou no armazenamento SMB, como o compartilhamento de arquivos premium do Azure, mas recomendamos o uso de discos gerenciados do Azure 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 do SQL Server em regiões com suporte, se as limitações atuais forem adequadas para seu ambiente. Dependendo da sua configuração, o SSD Premium v2 pode ser mais barato do que os SSDs Premium, ao mesmo tempo que proporciona melhorias de desempenho. Com o SSD Premium v2, você pode ajustar individualmente sua taxa de transferência ou IOPS independentemente do tamanho do seu 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 antecipados ou conhecidos. Recomendamos o uso do SSD Premium v2 ao usar a série de VMs Ebdsv5, pois é uma solução mais econômica para essas máquinas de alto rendimento de E/S. Atualmente, o SSD Premium v2 não suporta cache de host, portanto, é recomendável escolher um tamanho de VM com alta taxa de transferência não armazenada em cache, como as VMs da série Ebdsv5.

Atualmente, os discos SSD premium v2 não são suportados pelas imagens da galeria do SQL Server, mas podem ser usados com o SQL Server em VMs do Azure quando configurados manualmente.

Azure Elastic SAN

O Azure Elastic SAN oferece uma solução de armazenamento em bloco massivamente escalável, econômica, de alto desempenho e confiável que se conecta a uma variedade de serviços de computação do Azure por meio do protocolo iSCSI. O Elastic SAN permite uma transição perfeita de um conjunto de armazenamento SAN existente para a nuvem sem a necessidade de refatorar a arquitetura de aplicativos do cliente. Essa solução pode atingir uma escala massiva - até milhões de IOPS, GB/s de taxa de transferência de dois dígitos e latências de milissegundos de um dígito baixas com resiliência integrada para minimizar o tempo de inatividade. Isso o torna uma ótima opção para clientes que desejam consolidar 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 throughput alcançados ao impulsionar o armazenamento pela largura de banda da rede. 

Nota

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

Considere colocar cargas de trabalho do SQL Server na SAN elástica para obter melhor eficiência de custos porque:

• Consolidação de armazenamento e compartilhamento dinâmico de desempenho: normalmente para cargas de trabalho do SQL Server em VM do Azure, o armazenamento em disco é provisionado por VM com base na capacidade do cliente e nos requisitos de desempenho máximo para essa VM. Esse desempenho provisionado em excesso está disponível quando necessário, mas o desempenho não utilizado não pode ser compartilhado com cargas de trabalho em outras VMs. A SAN elástica, semelhante à SAN local, permite consolidar as necessidades de armazenamento de várias cargas de trabalho SQL e não SQL para obter melhor eficiência de custos, com 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, no Leste dos EUA, se você tiver 10 cargas de trabalho que exigem capacidade de 2 TiB e IOPS de 10K cada, mas coletivamente elas não precisam de mais de 60K IOPS em nenhum momento. Você pode configurar uma SAN elástica com 12 unidades básicas (1 unidade base = US$ 0,08 por GiB/mês) que lhe dará capacidade de 12 TiB e as IOPS de 60K necessárias, e 8 unidades somente de capacidade (1 unidade somente 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 de armazenamento ideal oferece melhor eficiência de custos e, ao mesmo tempo, fornece o desempenho necessário (IOPS de 10K) para cada uma dessas cargas de trabalho. Para obter mais informações sobre unidades de provisionamento de base e capacidade do Elastic SAN, visite Planning for an Azure Elastic SAN e, para obter preços, visite Azure Elastic SAN - Pricing.
• Para aumentar a taxa de transferência de armazenamento: as implantações de VM do SQL Server no Azure ocasionalmente exigem o superprovisionamento de uma VM devido aos limites de taxa de transferência de disco para essa VM. Você pode evitar isso com o Elastic SAN, uma vez que gera uma taxa de transferência de armazenamento mais alta na largura de banda da rede de computação com o protocolo iSCSI. Por exemplo, uma VM Standard_E32bds_v5 (SCSI) é limitada a 88.000 IOPS e 2.500 MBps para taxa de transferência de disco/armazenamento, mas pode atingir até um máximo de 16.000 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, não será necessário atualizar a VM para uma SKU mais alta, pois ela agora pode suportar até 16.000 MBps usando a SAN elástica.

SSD Premium

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

Para cargas de trabalho de produção, use os discos P30 e/ou P40 para arquivos de dados do SQL Server para garantir suporte ao cache e use os arquivos de log de transações P30 até P80 para SQL Server. Para obter o melhor custo total de propriedade, comece com P30s (5000 IOPS/200 MBPS) para dados e arquivos de log e escolha apenas 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 suportam cache, mas eles não oferecem preços reservados.

Para cargas de trabalho OLTP, combine as IOPS de destino por disco (ou pool de armazenamento) com seus requisitos de desempenho usando cargas de trabalho em horários de pico e os contadores de Disk Reads/sec + Disk Writes/sec desempenho. Para cargas de trabalho de data warehouse e relatórios, corresponda à 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 o desempenho ideal, configure dois pools, um para o(s) arquivo(s) de log e outro para os arquivos de dados. Se você não estiver usando striping de disco, use dois discos SSD premium mapeados para unidades separadas, onde uma unidade contém o arquivo de log e a outra contém os dados.

As IOPS provisionadas e a taxa de transferência por disco que são usadas como parte do pool de armazenamento. Os recursos combinados 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 prática recomendada é usar o menor número de discos possível e, ao mesmo tempo, atender aos requisitos mínimos de IOPS (e taxa de transferência) e capacidade. No entanto, o equilíbrio entre preço e desempenho tende a ser melhor com um grande número de discos pequenos em vez de um pequeno número de discos grandes.

Dimensione discos premium

O tamanho do SSD Premium determina a camada de desempenho inicial do disco. Designe a camada de desempenho na implantação ou altere-a posteriormente, sem alterar o tamanho do disco. Se a demanda aumentar, você pode aumentar o nível de desempenho para atender às necessidades do seu negócio.

A alteração da camada de desempenho permite que os administradores se preparem e atendam a uma demanda maior sem depender do estouro de disco.

Use o desempenho mais alto pelo tempo necessário quando o faturamento for projetado para atender ao nível de desempenho de armazenamento. Atualize a camada para atender aos requisitos de desempenho sem aumentar a capacidade. Retorne à camada original quando o desempenho extra não for mais necessário.

Essa expansão temporária e econômica do desempenho é um forte caso de uso para eventos direcionados, como compras, testes de desempenho, eventos de treinamento e outras janelas breves em que um maior desempenho é necessário apenas para um curto prazo.

Para obter mais informações, consulte Camadas de desempenho para discos gerenciados.

Azure ultra disk

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

O disco Ultra pode ser configurado onde a capacidade e o IOPS podem ser dimensionados de forma independente. Com ultra disco, os administradores podem provisionar um disco com os requisitos de capacidade, IOPS e taxa de transferência com base nas necessidades do aplicativo.

O Ultra Disk não é suportado em todas as séries de VM e tem outras limitações, como disponibilidade de região, redundância e suporte para o Backup do Azure. Para saber mais, consulte Usando discos ultra do Azure para obter uma lista completa de limitações.

HDDs e SSDs padrão

As HDD e SSD padrão têm latências e largura de banda variáveis e só são recomendadas para cargas de trabalho de desenvolvimento/teste. As cargas de trabalho de produção devem usar SSD Premium v2 ou SSDs Premium. Se você estiver usando SSD padrão (cenários de desenvolvimento/teste), a recomendação é adicionar o número máximo de discos de dados suportados pelo tamanho da VM e usar o striping de disco com espaços de armazenamento para obter o melhor desempenho.

Colocação em cache

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

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

Habilite o cache premium sempre que a opção for suportada para melhorar significativamente o desempenho de leituras na unidade de dados sem custo extra.

As leituras e gravações no BlobCache do Azure (IOPS e taxa de transferência em cache) não contam para as IOPS não armazenadas em cache e os limites de taxa de transferência da VM.

Nota

O cache de disco não é suportado para discos de 4 TiB e maiores (P50 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. Para obter mais informações, consulte Cache de disco.

Taxa de transferência não armazenada em cache

O máximo de IOPS e taxa de transferência de disco sem cache é o limite máximo de armazenamento remoto que a VM pode manipular. Esse limite é definido na VM e não é um limite do armazenamento em disco subjacente. Esse limite se aplica apenas à E/S em unidades de dados conectadas remotamente à VM, não à E/S local contra a unidade temporária (D:\ unidade) ou a unidade do sistema operacional.

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

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

Da mesma forma, você pode ver que o Standard_M32ts suporta 20.000 IOPS de disco sem cache e taxa de transferência de disco não cache de 500 MBps. Esse limite é controlado no nível da VM, independentemente do armazenamento em disco premium subjacente.

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

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

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 conectado localmente. A unidade temporária (D:\ unidade) dentro da VM também está hospedada neste SSD local.

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

Quando o cache está habilitado no armazenamento premium, as VMs podem ser dimensionadas além das limitações do armazenamento remoto, IOPS de VM não armazenadas em cache e limites de taxa de transferência.

Apenas algumas VMs oferecem 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 o armazenamento premium e o cache de armazenamento premium são suportados:

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

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

Políticas de cache de arquivos de dados

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

A tabela a seguir 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 Read-only o cache 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. IOPS e taxa de transferência não armazenadas em cache, além de IOPS e taxa de transferência em cache produzem o desempenho total possível disponível da 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 acertos do 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 um ou Read-only Read/Write o cache habilitado na unidade de log pode degradar o desempenho das gravações em relação à unidade e diminuir a quantidade de cache disponível para leituras na unidade de dados.
Disco do SO operacional	A política de cache padrão é Read/write para a unidade do sistema operacional. Não é recomendado alterar o nível de cache da unidade do sistema operacional.
tempdb	Se tempdb não puder ser colocado na unidade efêmera devido a motivos de capacidade, redimensione a VM para obter uma unidade efêmera maior ou coloque tempdb em uma unidade D:\ de dados separada com Read-only cache configurado. O cache da VM e a unidade efêmera usam o SSD local, portanto, tenha isso em mente ao dimensionar, pois tempdb a E/S contará em relação aos limites de IOPS e taxa de transferência da VM em cache quando hospedados na unidade efêmera.

Importante

Alterar a definição de cache de um disco do Azure desanexa e anexa novamente o disco de destino. Ao alterar a configuração de cache de um disco que hospeda dados, log ou arquivos de aplicativo do SQL Server, certifique-se de interromper o serviço do SQL Server junto com quaisquer outros serviços relacionados para evitar corrupção de dados.

Para saber mais, consulte Cache de disco.

Distribuição de disco

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

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

Para configurar a distribuição de discos, consulte Distribuição de discos.

Limitação do disco

Há limites de taxa de transferência no nível de disco e VM. Os limites máximos de IOPS por VM e por disco diferem e são independentes uns dos outros.

Os aplicativos que consomem recursos além desses limites serão limitados (também conhecidos como limitados). Selecione uma VM e um tamanho de disco em uma distribuição de disco que atenda aos requisitos do aplicativo e não enfrente limitações de limitação. Para resolver o limite máximo, use o 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:

• Use o Standard_M32ms, que tem uma taxa de transferência máxima de disco sem cache de 20.000 IOPS e 500 MBps.
• Distribua três discos P30 para fornecer 15.000 IOPS e taxa de transferência de 600 MB/s.
• Use uma Standard_M16ms VM e use o cache do host para utilizar o cache local sobre o consumo de taxa de transferência.

As VMs configuradas para aumentar a escala durante períodos de alta utilização devem provisionar o armazenamento com IOPS e taxa de transferência suficientes para suportar o tamanho máximo da VM, mantendo o número total de discos menor ou igual ao número máximo suportado pela menor SKU de VM direcionada a ser usada.

Para obter mais informações sobre limitações de limitação de disco e uso de cache para evitar limitações, consulte Limite de E/S de disco.

Nota

Algumas tampas de disco ainda podem resultar em desempenho satisfatório para os usuários; ajuste e mantenha cargas de trabalho em vez de redimensionar para uma VM maior para equilibrar o gerenciamento de custos e desempenho para os negócios.

Aceleração de escrita

A aceleração de gravação é um recurso de disco que só está disponível para as VMs da série M. O objetivo da Aceleração de Escrita é melhorar a latência de E/S das gravações no Armazenamento Premium do Azure quando precisar de latência de E/S de um dígito devido a cargas de trabalho OLTP de missão crítica de alto volume ou ambientes de armazém de dados.

Use a aceleração de gravação para melhorar 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.

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

A tabela a seguir descreve o número de discos de dados e IOPS suportados por VM:

SKU da VM	# Discos do Acelerador de Gravação	IOPS de disco do acelerador de gravação por VM
M416ms_v2, M416s_v2	16	20 000
M128ms, M128s	16	20 000
M208ms_v2, M208s_v2	8	10000
M64ms, M64ls, M64s	8	10000
M32ms, M32ls, M32ts, M32s	4	5000
M16ms, M16s	2	2500
M8ms, M8s	1	1250

Há várias restrições para usar a Aceleração de Gravação. Para saber mais, consulte Restrições ao usar o Acelerador de Gravação.

Comparar com o disco ultra do Azure

A maior diferença entre a Aceleração de Escrita e os discos Ultra do Azure é que a Aceleração de Escrita é uma funcionalidade de VM disponível apenas para os discos da Série M e os ultradiscos do Azure são uma opção de armazenamento. A Aceleração de Gravação é um cache otimizado para gravação com suas próprias limitações com base 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 discos ultra para o disco de log de transações. Para 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.

Monitore o desempenho do armazenamento

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

IOPS (Input/Output per second) é o número de solicitações que o aplicativo está fazendo para armazenamento por segundo. Meça IOPS usando contadores do Monitor de Disk Reads/sec Desempenho e Disk Writes/sec. Os aplicativos OLTP (processamento de transações on-line) precisam gerar IOPS mais altas para alcançar o desempenho ideal. Aplicações como sistemas de processamento de pagamentos, compras online e sistemas de ponto de venda de retalho são exemplos de aplicações OLTP.

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

Os tamanhos das unidades de E/S influenciam as IOPS e os recursos de taxa de transferência, pois tamanhos menores de E/S geram IOPS mais altas e tamanhos maiores de E/S geram maior taxa de transferência. O SQL Server escolhe o tamanho ideal de E/S automaticamente. Para obter mais informações sobre, consulte Otimizar IOPS, taxa de transferência e latência para seus aplicativos.

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

Nota

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

Próximos passos

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

• Lista de verificação rápida

• Tamanho da VM

• Segurança

• Configurações de HADR

• Recolher linha de base

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

• Para obter testes detalhados do desempenho do SQL Server em VMs do Azure com benchmarks TPC-E e TPC_C, consulte o blog Otimizar o desempenho OLTP.

• Analise outros artigos da Máquina Virtual do SQL Server em Visão geral do SQL Server on Azure Virtual Machines. Se tiver dúvidas sobre máquinas virtuais do SQL Server, veja as Perguntas Mais Frequentes.