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

Aplica-se a:SQL Server em 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. Saiba como selecionar os tipos de disco corretos, configurar pools de armazenamento e implementar estratégias de cache para maximizar o desempenho do banco de dados.

Normalmente, há um compromisso entre otimizar os custos e otimizar o desempenho. Esta série de práticas recomendadas de desempenho concentra-se 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 HADRe Linha de base de recolha.

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 a aplicação e determine os requisitos de largura de banda e latência de armazenamento para os dados, logs e tempdb ficheiros do SQL Server antes de escolher o tipo de disco.
• Se disponível, configure os dados e os tempdb arquivos de log no volume SSD D: local quando implantar uma nova máquina virtual ou depois de instalar o SQL Server manualmente. A extensão do SQL IaaS Agent lida com a pasta e as permissões necessárias no momento do reprovisionamento.
• Para otimizar o desempenho do armazenamento, planeie atingir as IOPS mais altas disponíveis sem cache e utilize a cache de dados como um recurso de desempenho para leituras de dados, evitando a limitação de máquinas virtuais e discos.
  • Defina a cache do host para somente leitura nos discos de arquivos de dados.
  • Defina cache do host para nenhum para discos de log.
    • Não habilite o cache de leitura/gravação em discos que contenham dados ou arquivos de log do SQL Server.
    • Sempre pare o serviço SQL Server antes de alterar as configurações de cache do disco.
• Ao usar as VMs do SQL Server série Ebdsv5 ou Ebsv5, use SSD Premium v2 para obter o melhor desempenho de preço. Você pode implantar sua VM do SQL Server com SSD Premium v2 usando o portal do Azure (atualmente em visualização).
• Se a sua carga de trabalho exigir mais de 160.000 IOPS, use SSD Premium v2 ou Azure Ultra Disks.
• Coloque dados, log e arquivos tempdb em unidades separadas.
  • Para a unidade de dados, use P30 e P40 premium ou discos menores para garantir a disponibilidade do suporte de cache. Ao usar a série de VMs Ebdsv5, utilize o SSD Premium v2, que oferece melhor relação custo-desempenho para cargas de trabalho que exigem alta IOPS e largura de banda de E/S.
  • Para o plano de capacidade e desempenho de teste do drive de log versus custo, ao avaliar os discos SSD Premium v2 ou SSD Premium P30 - P80
    • Se for necessária uma latência de armazenamento de submilissegundos, utilize 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 o acelerador de gravação em vez de usar 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. Para obter mais informações, consulte Políticas de cache de arquivos de dados.
  • Para instâncias de cluster de failover (FCI), coloque tempdb no armazenamento compartilhado.
    • Se a carga de trabalho da FCI depender muito do desempenho do disco tempdb, então, como configuração avançada, coloque tempdb na unidade SSD temporário local (D:\padrão), que não faz parte do armazenamento 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 qualquer falha dessa unidade não acionará a ação da FCI.
• Fragmentar 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.
• Ao migrar várias cargas de trabalho diferentes para a nuvem, do Azure Elastic SAN pode ser uma solução de armazenamento consolidado econômica. No entanto, ao usar o Azure Elastic SAN, alcançar IOPS/taxa de transferência desejada para cargas de trabalho do SQL Server geralmente requer capacidade de provisionamento excessivo. 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 de armazenamento padrão. Não é recomendado o uso de HDD/SSD padrão para cargas de trabalho de produção.
• Disk Bursting baseado em crédito (P1-P20) só deve ser considerado para cargas de trabalho de desenvolvimento/teste menores e sistemas departamentais.
• 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 de D:\ temporária (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 a sua VM do SQL Server está configurada para aderir às melhores práticas.
• Revise os limites de disco e VM e monitore-os 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 práticas recomendadas, consulte a lista de verificação abrangente de práticas recomendadas de desempenho do .

Visão geral

Para encontrar a configuração mais eficaz para cargas de trabalho do SQL Server em uma VM do Azure, comece por 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.

Tipos de disco 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 etiquetas 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 do SSD Premium v2 e Ultra Disks pode ser alterado independentemente do tamanho do disco, para obter detalhes, consulte de desempenho do disco Ultra e de desempenho do SSD Premium v2. Se a sua carga de trabalho exigir mais de 160.000 IOPS, considere usar SSD Premium v2 ou Ultra Disks.

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

Disco do sistema operacional

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 unidade C:\. Quando você cria uma VM do Azure, a plataforma anexa pelo menos um disco à VM para o disco do sistema operacional. A unidade C:\ é 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 (ou seja, é desalocado e alocado novamente) quando a VM é reiniciada ou movida para um anfitrião diferente (para, por exemplo, a cura de serviço ).

A unidade de armazenamento temporário não é mantida para armazenamento remoto e, portanto, não deve armazenar arquivos de banco de dados do usuário, arquivos de log de transações ou qualquer coisa que deva ser preservada. Por exemplo, pode usá-lo para extensões do buffer pool, do ficheiro de paginação e tempdb.

Coloque tempdb na unidade de D:\ SSD temporária local para cargas de trabalho do SQL Server, a menos que o consumo de cache local seja uma preocupação. Se estiver a usar uma VM que não tenha um disco temporário, então é recomendável colocar tempdb no seu próprio disco isolado ou pool de armazenamento com a cache definida para 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 de D:\ temporária (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.

SSD Premium v2

Você deve usar SSD Premium v2 discos 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 máquinas virtuais Ebdsv5 ou Ebsv5 pois é uma solução mais econômica para essas máquinas de alto rendimento de E/S. Se a sua carga de trabalho exigir mais de 160.000 IOPS, considere usar SSD Premium v2 ou Ultra Disks.

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

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

Azure Elastic SAN

Azure Elastic SAN é uma oferta de armazenamento conectado à rede que oferece aos clientes uma solução flexível e escalável com o potencial de reduzir custos por meio da consolidação de armazenamento. O Azure Elastic SAN oferece uma solução de armazenamento em bloco econômica, eficiente 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 ser dimensionada para milhões de IOPS, GB/s de taxa de transferência de dois dígitos e latências baixas na ordem de milissegundos de um dígito, 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 ter 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 sobredimensionar a capacidade, normalmente não é apropriado para uma única carga de trabalho de SQL Server. Para obter a solução mais econômica com o Elastic SAN, considere usá-lo como armazenamento para várias cargas de trabalho do SQL Server ou uma combinação do SQL Server e outras cargas de trabalho de baixo desempenho.

Considere colocar cargas de trabalho do SQL Server em SAN elástica para obter melhor eficiência de custos, consolidação de armazenamento, compartilhamento dinâmico de desempenho e aumentar a taxa de transferência de armazenamento.

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 com base no tamanho do disco e no tipo.

Para cargas de trabalho de produção, utilize os discos P30 e/ou P40 para os ficheiros de dados do SQL Server para garantir suporte de cache, e utilize discos de P30 até P80 para os ficheiros de log de transações do 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 nos 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, adapte a taxa de transferência de destino utilizando as cargas de trabalho nos horários de pico e no 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. Caso não esteja a usar segmentação de disco, use dois discos SSD premium atribuídos a unidades separadas, sendo que uma unidade contém o ficheiro de registo e a outra contém os dados.

O IOPS provisionado e a taxa de transferência por disco que são usados como parte do pool de armazenamento. As capacidades combinadas de IOPS e taxa de transferência dos discos são a capacidade máxima até aos 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.

Dimensionar 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 de disparos de disco.

Utilize o desempenho superior pelo tempo necessário onde a faturação é concebida para satisfazer o 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 sub-milissegundos com latência reduzida, considere usar o Azure ultra disk para o disco de log do SQL Server ou até mesmo para o disco de dados em aplicações 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

HDDs padrão e SSDs têm latências e largura de banda variáveis e são recomendadas apenas 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 VM e usar distribuição de disco com espaços de armazenamento para obter o melhor desempenho.

Armazenamento 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 é contabilizada nos limites de taxa de transferência de disco sem 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.

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. Este limite aplica-se apenas a E/S em unidades de dados remotamente ligadas à VM, não à E/S local contra a unidade temporária (unidadeD:\) ou a unidade de SO.

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 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 de cache e não-cache.

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

O limite máximo de largura de banda para armazenamento em cache e temporário é distinto do limite de largura de banda não armazenada 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 (unidadeD:\) dentro da VM também está hospedada neste SSD local.

O limite máximo da taxa de transferência de armazenamento temporário e em cache controla a E/S no disco temporário local (discoD:\) e no BlobCache do Azure , somente se o cache de host estiver habilitado.

Quando o cache está ativado no armazenamento premium, as VMs podem ser dimensionadas além das limitações do armazenamento remoto em relação aos IOPS não armazenados em cache e aos 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 série M indica que tanto a capacidade de armazenamento premium, como a capacidade de cache de armazenamento premium, são suportadas.

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 3.174 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:

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 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 discos 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 em faixas de discos, consulte distribuição em faixas de discos.

Limitação de 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.

As aplicações que consomem recursos além desses limites serão restringidas (também conhecidas como limitadas). Selecione uma VM e um tamanho de disco em uma faixa de disco que atenda aos requisitos da aplicação e não enfrente limitações. 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 não armazenado em cache de 20.000 IOPS e 500 MBps.
• Utilize a técnica de striping em três discos P30 para fornecer 15.000 IOPS e uma taxa de transferência de 600 MB/s.
• Use uma VM Standard_M16ms e use o caching do host para utilizar o cache local em vez de consumir largura de banda.

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 capping de disco e uso de cache para evitar limitação, consulte o ede limite de E/S de disco.

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 escritas no Armazenamento Premium do Azure quando for necessário obter latência de E/S de apenas um dígito devido a cargas de trabalho OLTP de missão crítica de elevado 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:

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 Escrita em discos ultrarrápidos para o disco de registo 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.

Redimensione os pools 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, portanto, o espaço em disco aumentado não é utilizado e desperdiçado.

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

Para imagens do SQL Server no Azure VM Marketplace que usam discos SSD Premium v2, ou Ultra Disks, ou máquinas virtuais com instâncias do SQL Server autoinstaladas, 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 do Servidor> Serviços de Arquivo 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.

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 (Entrada/Saída por segundo) é o número de solicitações que o aplicativo está fazendo ao armazenamento por segundo. Meça IOPS usando contadores do Monitor de Desempenho Disk Reads/sec e Disk Writes/sec. OLTP (processamento de transações on-line) aplicativos precisam gerar IOPS mais altos 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.

Taxa de transferência é o volume de dados que está a ser enviado para o armazenamento subjacente, geralmente medido em megabytes por segundo. Meça a taxa de transferência com os contadores do Monitor de Desempenho Disk Read Bytes/sec e Disk Write Bytes/sec. Armazenamento de dados é otimizado para maximizar a taxa de transferência em relação ao 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 as suas aplicações.

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.

Monitorar o crescimento do log de transações

Como um log de transações completo pode levar a 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.

Revise Solucionar problemas de um log de transações completo se o log estiver cheio.

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

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

• Coletar 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.

• Consulte outros artigos sobre Máquinas Virtuais do SQL Server em Visão geral do SQL Server em Máquinas Virtuais do Azure. Se você tiver dúvidas sobre máquinas virtuais do SQL Server, consulte o Perguntas freqüentes.