Lista de verificação: melhores práticas do SQL Server nas VMs do Azure

  • Artigo

Aplica-se a:SQL Server na VM do Azure

Este artigo fornece uma lista de verificação rápida com algumas melhores práticas e diretrizes para otimizar o desempenho do SQL Server em VMs (Máquinas Virtuais) do Azure.

Para obter detalhes abrangentes, confira os outros artigos desta série: Tamanho da VM, Armazenamento, Segurança, Configuração do HADR, Linha de base de coleta.

Habilite Avaliação do SQL para o SQL Server em VMs do Azure e seu SQL Server será avaliado em relação a melhores práticas conhecidas com resultados na página de gerenciamento de VMs do SQL do portal do Azure.

Para vídeos sobre os recursos mais recentes para otimizar o desempenho da VM do SQL Server e automatizar o gerenciamento, examine os seguintes vídeos sobre dados expostos:

Visão geral

Durante a execução do SQL Server em máquinas virtuais do Azure, continue usando as mesmas opções de ajuste de desempenho de banco de dados aplicáveis ao SQL Server em ambientes de servidor local. No entanto, o desempenho de um banco de dados relacional em uma nuvem pública depende de muitos fatores, como o tamanho da máquina virtual e a configuração dos discos de dados.

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 Máquinas Virtuais 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.

Tamanho da VM

A lista de verificação nesta seção aborda as melhores práticas de tamanhos de VMs para SQL Server em VMs do Azure.

  • A nova série Ebdsv5 fornece a maior taxa de transferência de E/S para vCore no Azure, juntamente com uma taxa de memória para vCore de 8. Essa série oferece o melhor desempenho de preço para cargas de trabalho do SQL Server em VMs do Azure. Considere essa série primeiro para a maioria das cargas de trabalho do SQL Server.
  • Use tamanhos de VM com 4 ou mais vCPUs como E4ds_v5 ou superior.
  • Use tamanhos de máquina virtual com otimizado para memória para obter o melhor desempenho das cargas de trabalho do SQL Server.
  • As séries Edsv5, M- e Mv2- oferecem a proporção ideal de memória para vCore necessária para cargas de trabalho OLTP.
  • As VMs da série M oferecem a maior taxa de memória para vCore no Azure. Considere essas VMs para cargas de trabalho críticas de missão e data warehouse.
  • Use as imagens do Azure Marketplace para implantar suas máquinas virtuais do SQL Server, já que as configurações e opções de armazenamento do SQL Server estão configuradas para um desempenho ideal.
  • Colete as características de desempenho da carga de trabalho de destino e use-as para determinar o tamanho apropriado da VM para a sua empresa.
  • Use a ferramenta de recomendação de SKU e o Assistente de Migração de Dados para encontrar o tamanho certo de VM para a sua carga de trabalho do SQL Server.
  • Use o Azure Data Studio para migrar para o Azure.

Armazenamento

A lista de verificação nesta seção aborda as melhores práticas de armazenamento para SQL Server em VMs do Azure.

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

Segurança

A lista de verificação nesta seção aborda as melhores práticas de segurança para SQL Server em VMs do Azure.

Os recursos e capacidades do SQL Server fornecem um método de segurança no nível de dados e é como você obtém defesa profunda no nível de infraestrutura para soluções híbridas e baseadas em nuvem. Além disso, com as medidas de segurança do Azure, é possível criptografar seus dados confidenciais, proteger máquinas virtuais contra vírus e malware, proteger o tráfego de rede, identificar e detectar ameaças, atender aos requisitos de conformidade e fornecer um único método de administração e relatórios para qualquer necessidade de segurança na nuvem híbrida.

  • Use o Microsoft Defender para Nuvem para avaliar e tomar medidas a fim de aprimorar a postura de segurança do ambiente de dados. Recursos como a ATP (proteção avançada contra ameaças) do Azure podem ser aproveitados em suas cargas de trabalho híbridas para melhorar a avaliação de segurança e dar a capacidade de reagir aos riscos. O registro da VM do SQL Server com a extensão do Agente de IaaS do SQL mostra as avaliações do Microsoft Defender para Nuvem no recurso de máquina virtual SQL do portal do Azure.
  • Use o Microsoft Defender para SQL para descobrir e atenuar possíveis vulnerabilidades de banco de dados, bem como detectar atividades anormais que possam indicar uma ameaça à sua instância do SQL Server e à camada do banco de dados.
  • A avaliação de vulnerabilidade é uma parte do Microsoft Defender para SQL que pode descobrir e ajudar a corrigir riscos potenciais em seu ambiente de SQL Server. Ela fornece visibilidade sobre o estado de segurança e inclui etapas acionáveis para resolver problemas de segurança.
  • Use as VMs confidenciais do Azure para reforçar a proteção dos dados em uso e dos dados inativos contra o acesso do operador do host. As VMs confidenciais do Azure permitem que você armazene com confiança os dados confidenciais na nuvem e atenda a requisitos rígidos de conformidade.
  • Se você está no SQL Server 2022, considere usar a autenticação do Microsoft Entra para se conectar à instância do SQL Server.
  • O Assistente do Azure analisa a telemetria de uso e a configuração do recurso e, depois, recomenda soluções que podem ajudar você a melhorar a economia, o desempenho, a alta disponibilidade e a segurança de seus recursos do Azure. Aproveite o Assistente do Azure na máquina virtual, no grupo de recursos ou no nível de assinatura para ajudar a identificar e aplicar as melhores práticas para otimizar as implantações do Azure.
  • Use o Azure Disk Encryption quando as necessidades de conformidade e segurança exigirem que você criptografe os dados de ponta a ponta usando suas chaves de criptografia, incluindo a criptografia do disco efêmero (localmente conectado temporariamente).
  • Managed Disks são criptografados no modo inativo por padrão, usando a Criptografia do Serviço de Armazenamento do Azure, em que as chaves de criptografia são chaves gerenciadas pela Microsoft armazenadas no Azure.
  • Para obter uma comparação das opções de criptografia de disco gerenciado, consulte o gráfico de comparação de criptografia de disco gerenciado
  • As portas de gerenciamento devem ser fechadas em suas máquinas virtuais – abrir as portas de gerenciamento remoto expõe sua VM a um alto nível de risco de ataques baseados na Internet. Estes ataques tentam obter credenciais por força bruta para obter acesso de administrador à máquina.
  • Ativar o acesso JIT (just-in-time) para máquinas virtuais do Azure
  • Use o Azure Bastion em protocolo RDP (Área de Trabalho Remota).
  • Bloqueie as portas e permita apenas o tráfego de aplicativos necessários usando o Firewall do Azure, que é um firewall gerenciado como serviço (FaaS) que concede/nega acesso ao servidor com base no endereço IP de origem.
  • Use os NSGs (grupos de segurança de rede) para filtrar o tráfego de rede de e para recursos do Azure em redes virtuais do Azure
  • Aproveite os Grupos de Segurança de Aplicativos para agrupar servidores com requisitos de filtragem de porta semelhantes, com funções semelhantes, como servidores Web e servidores de banco de dados.
  • Para servidores Web e de aplicativos, aproveite a proteção contra DDoS (negação de serviço distribuído) do Azure. Ataques de DDoS são projetados para sobrecarregar e esgotar recursos de rede, tornando os aplicativos lentos ou sem resposta. É comum que ataques de DDos sejam direcionados a interfaces do usuário. A proteção contra DDoS do Azure corrige o tráfego de rede indesejado, antes de impactar a disponibilidade do serviço
  • Use as extensões de VM para ajudar a lidar com antimalware, estado desejado, detecção de ameaças, prevenção e correção, a fim de resolver ameaças no sistema operacional, no computador e na rede:
  • Use o Azure Policy para criar regras de negócios que possam ser aplicadas ao seu ambiente. As políticas do Azure avaliam os recursos do Azure comparando as propriedades desses recursos em relação às regras definidas no formato JSON.
  • O Azure Blueprints permite que arquitetos de nuvem e grupos centrais de tecnologia da informação definam um conjunto repetível de recursos do Azure que implementa e adere aos padrões e requisitos de uma organização. Os Azure Blueprints são diferentes das políticas do Azure.

recursos do SQL Server

Confira uma lista de verificação rápida das práticas recomendadas para definições de configuração do SQL Server ao executar suas instâncias do SQL Server em uma máquina virtual do Azure em produção:

do Windows Azure

Confira uma lista de verificação rápida de melhores práticas para diretrizes específicas do Azure ao executar seu SQL Server na VM do Azure:

Configuração do HADR

A lista de verificação nesta seção aborda as melhores práticas de HADR para SQL Server em VMs do Azure.

Os recursos de HADR (alta disponibilidade e recuperação de desastre), como o Grupos de Disponibilidade AlwaysOn e a instância de cluster de failover, dependem da tecnologia subjacente de cluster de failover do Windows Server. Examine as melhores práticas para modificar as configurações do HADR para dar melhor suporte ao ambiente de nuvem.

Para o seu cluster do Windows, considere estas práticas recomendadas:

  • Implante suas VMs do SQL Server em várias sub-redes sempre que possível para evitar a dependência de um Azure Load Balancer ou um DNN (nome de rede distribuída) para rotear o tráfego para a solução de HADR.
  • Altere o cluster para parâmetros menos agressivos para evitar interrupções inesperadas devido a falhas de rede transitórias ou manutenção da plataforma do Azure. Para saber mais, confira configurações de pulsação e limite. Para o Windows Server 2012 e versões posteriores, use os seguintes valores recomendados:
    • SameSubnetDelay: 1 segundo
    • SameSubnetThreshold: 40 pulsações
    • CrossSubnetDelay: 1 segundo
    • CrossSubnetThreshold: 40 pulsações
  • Coloque suas VMs em um conjunto de disponibilidade ou em zonas de disponibilidade diferentes. Para saber mais, confira configurações de disponibilidade da VM.
  • Use uma única NIC por nó de cluster.
  • Configure a votação de quorum do cluster para usar um número ímpar de três votos ou mais. Não atribua votos a regiões de DR.
  • Monitore cuidadosamente os limites de recursos para evitar reinicializações ou failovers inesperados devido a restrições de recursos.
    • Verifique se o sistema operacional, drivers de SO e SQL Server estão nos builds mais recentes.
    • Otimize o desempenho para SQL Server em VMs do Azure. Examine as outras seções deste artigo para saber mais.
    • Reduza ou distribua a carga de trabalho para evitar limites de recursos.
    • Mova para uma VM ou disco com limites mais altos para evitar restrições.

Para seu grupo de disponibilidade SQL Server ou instância de cluster de failover, considere estas melhores práticas:

  • Se você estiver enfrentando falhas inesperadas frequentes, siga as melhores práticas de desempenho descritas no restante deste artigo.
  • Se a otimização do desempenho da VM do SQL Server não resolver os failovers inesperados, considere reduzir o monitoramento do grupo de disponibilidade ou da instância de cluster de failover. No entanto, isso pode não tratar da origem subjacente do problema e pode mascarar os sintomas ao reduzir a probabilidade de falha. Talvez você ainda precise investigar e resolver a causa raiz subjacente. Para o Windows Server 2012 ou superior, use os seguintes valores recomendados:
    • Tempo limite de concessão: use essa equação para calcular o valor máximo de tempo limite de concessão:
      Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay).
      Comece com 40 segundos. Se você estiver usando os valores SameSubnetThreshold e SameSubnetDelay reduzidos recomendados anteriormente, não exceda 80 segundos no valor de tempo limite de concessão.
    • Máximo de falhas em um período especificado: defina esse valor como 6.
  • Ao usar o VNN (nome da rede virtual) e um Azure Load Balancer para se conectar à solução de HADR, especifique MultiSubnetFailover = true na cadeia de conexão, mesmo que o cluster abranja apenas uma sub-rede.
    • Se o cliente não der suporte a MultiSubnetFailover = True, poderá ser necessário definir RegisterAllProvidersIP = 0 e HostRecordTTL = 300 para armazenar as credenciais do cliente em cache em caso de durações mais curtas. No entanto, isso pode causar consultas adicionais ao servidor DNS.
  • Para se conectar à sua solução de HADR usando o nome de rede distribuída (DNN), considere o seguinte:
    • Você deve usar um driver de cliente que dê suporte ao MultiSubnetFailover = True e esse parâmetro deve estar na cadeia de conexão.
    • Use uma porta DNN exclusiva na cadeia de conexão ao conectar-se ao ouvinte DNN para um grupo de disponibilidade.
  • Use uma cadeia de conexão de espelhamento de banco de dados para um grupo de disponibilidade básico para ignorar a necessidade de um balanceador de carga ou DNN.
  • Valide o tamanho do setor de seus VHDs antes de implantar sua solução de alta disponibilidade para evitar ter E/Ss desalinhadas. Confira KB3009974 para saber mais.
  • Se o mecanismo de banco de dados do SQL Server, o ouvinte do grupo de disponibilidade Always On ou a investigação de integridade da instância de cluster de failover estiver configurado para usar uma porta entre 49.152 e 65.536 (o intervalo de portas dinâmicas padrão para TCP/IP), adicione uma exclusão para cada porta. Isso impedirá que outros sistemas sejam atribuídos dinamicamente à mesma porta. O exemplo a seguir cria uma exclusão para a porta 59999:
    netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

Solucionar problemas de desempenho

A seguir, temos uma lista dos recursos que ajudam você a solucionar problemas de desempenho do SQL Server.

Conteúdo relacionado

Considere habilitar aAvaliação do SQL para SQL Server nas VMs do Azure.

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.