Compartilhar via

Lista de verificação: práticas recomendadas para SQL Server em VMs Azure

Applies to:SQL Server em Azure VM

Este artigo fornece listas de verificação como parte de uma série de práticas recomendadas e diretrizes para otimizar o desempenho de suas VMs (SQL Server on Azure Virtual Machines). Use este guia para melhorar a configuração da VM, a configuração de armazenamento, a postura de segurança e solucionar problemas comuns de desempenho.

As listas de verificação neste artigo fornecem uma breve visão geral dos detalhes mais abrangentes encontrados nos seguintes artigos desta série:

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

Para obter vídeos sobre os recursos mais recentes para otimizar o desempenho da VM do SQL Server e automatizar o gerenciamento, confira os seguintes vídeos da série Data Exposed:

Visão geral

Durante a execução SQL Server on Azure Virtual Machines, continue usando as mesmas opções de ajuste de desempenho de banco de dados aplicáveis a 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. Essa série de práticas recomendadas de desempenho é focada em obter o melhor desempenho para o SQL Server em Máquinas Virtuais do Azure.

Próximos passos: Comece com a seção de recomendações de tamanho de VM, em seguida, prossiga pelas seções de armazenamento, segurança e recursos do SQL Server para uma abordagem completa de otimização.

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.

Instalar manualmente SQL Server em uma VM Azure

Se você planeja instalar manualmente SQL Server em uma VM Azure, siga estas etapas essenciais para evitar problemas comuns de configuração:

  • Verifique se você tem uma chave do produto pronta para sua instalação.
  • Evite configurações sem suporte , como:
    • Mais de 64 vCores por nó NUMA.
    • Armazenamento com tamanho de setor de 8 KB.
    • Conjuntos de Dimensionamento de Máquinas Virtuais do Azure.
  • Se eles ainda não existirem, crie as pastas para a instalação do SQL Server e arquivos de dados antes de iniciar a instalação a partir da mídia.
  • Copie a mídia de instalação para uma unidade local em vez de instalar diretamente do ISO montado.
  • Após a instalação, registre sua VM SQL Server com a SQL Server Extensão do Agente IaaS para automatizar tarefas de gerenciamento.
  • Coloque o tempdb banco de dados no armazenamento efêmero do SSD local quando possível.

Tamanho da VM

Aviso

Não há suporte para colocar tempdb no disco temporário local para imagens de VM Azure com discos efêmeros não inicializados, como o FXmdsv2. Esse problema afeta apenas Azure Virtual Machines com a nova interface NVMe que também tem armazenamento efêmero local. Essas implantações por meio do portal Azure podem falhar e SQL Server podem falhar ao iniciar. Use uma série de VM diferente ou coloque tempdb no armazenamento não efêmero ao implantar a imagem SQL Server por meio do portal Azure e quando você instala SQL Server manualmente. Para saber mais sobre o problema e também ver uma lista de VMs afetadas, examine falhas na implantação de VMs e do SQL Server.

A lista de verificação nesta seção aborda as práticas recomendadas de tamanho VM para SQL Server em VMs Azure.

  • Antes de escolher um tamanho de VM, configure seu armazenamento. Colete uma linha de base do seu ambiente de origem sob as condições de estresse mais altas e configure seu armazenamento com base nas necessidades de IOPS e taxa de transferência de sua carga de trabalho com um buffer de 20% para crescimento futuro.
  • Identifique as características de desempenho da carga de trabalho (OLTP vs OLAP, tamanho da carga de trabalho) para determinar o tamanho apropriado da VM para sua empresa.
  • Se você estiver migrando para o Azure, avalie a prontidão para migração para encontrar o tamanho certo da VM para sua carga de trabalho de SQL Server existente e, em seguida, migre com o Azure Database Migration Service.
  • Use imagens do Azure Marketplace para implantar suas VMs SQL Server enquanto as configurações do SQL Server e as opções de armazenamento estão configuradas para desempenho ideal.
  • Utilize tamanhos de VM que tenham 4 ou mais vCores.
  • Use tamanhos de máquina virtual com otimização de memória para obter o melhor desempenho de cargas de trabalho SQL Server.
    • A série Mbdsv3 oferece o melhor desempenho geral para cargas de trabalho críticas de OLTP e data warehouse.
    • O Ebdsv5-series fornece o melhor preço-desempenho para a maioria das cargas de trabalho de SQL Server de produção.
    • As séries Easv7 e Msv3/Mdsv3 são otimizadas para cargas de trabalho com uso intensivo de memória.
    • A família da série M oferece as configurações de memória mais altas em Azure para as maiores cargas de trabalho.
  • Inicie ambientes de desenvolvimento com a Série D de camada inferior ou Série B e aumente seu ambiente ao longo do tempo.
  • Verifique Suporte da VM para evitar configurações sem suporte.
  • Use VM vCore customization para alocar adequadamente vCPUs para sua carga de trabalho e VM e reduzir os custos de licenciamento do SQL Server, bem como desabilitar as configurações de SMT/hiperthreading para o desempenho ideal do SQL Server.

Armazenamento

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

  • Monitore o aplicativo e determine os requisitos de largura de banda e latência de armazenamento para dados, logs e arquivos do SQL Server antes de escolher o tipo de disco.
  • Se disponível, configure os arquivos de dados e log tempdb no volume D: SSD local ao implantar uma nova máquina virtual ou depois de ter instalado o SQL Server manualmente. 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.
    • 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 os dados ou os arquivos de log do SQL Server.
      • Sempre interrompa o serviço SQL Server antes de alterar as configurações de cache do disco.
  • Ao usar a série Ebdsv5 ou Ebsv5 SQL Server VMs, use Premium SSD v2 para obter o melhor desempenho de preço. Você pode implantar sua VM SQL Server com o SSD Premium v2 usando o portal Azure (atualmente em versão prévia).
  • Se sua carga de trabalho exigir mais de 160.000 IOPS, use Premium SSD v2 ou 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 a latência de armazenamento de submilissegundos for necessária, use Premium SSD v2 ou Azure Ultra Disks para o log de transações.
      • Para implantações de máquinas virtuais da série M, considere write accelerator em vez de usar Azure Ultra Disks.
    • Coloque tempdb no disco temporário (o disco temporário é efêmero e usa como padrão D:\) para a maioria das cargas de trabalho 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 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 requer monitoramento e ação personalizados para garantir que a unidade SSD efêmera local, padrão (D:\), esteja sempre disponível, já que falhas dessa unidade não acionam nenhuma ação pela FCI.
  • Intercale vários discos de dados do Azure usando Storage Spaces 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, Azure Elastic SAN pode ser uma solução de armazenamento consolidada econômica. No entanto, ao usar Azure Elastic SAN, alcançar a IOPS/taxa de transferência desejada para cargas de trabalho SQL Server geralmente requer capacidade de superprovisionamento. Embora normalmente não seja apropriado para cargas de trabalho de SQL Server único, você pode obter uma solução econômica ao combinar cargas de trabalho de baixo desempenho com 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.
  • 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). SQL Server VMs implantadas por meio de 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 SQL Server.
  • Desabilite Azure armazenamento com redundância geográfica (replicação geográfica) e use LRS (armazenamento com redundância local) na conta de armazenamento.
  • Habilite o SQL Best Practices Assessment para identificar possíveis problemas de desempenho e avaliar que sua VM SQL Server está configurada para seguir as práticas recomendadas.
  • Examine e monitore os limites de disco e da VM usando as Métricas de utilização de E/S de armazenamento.
  • Excluir arquivos 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.

Segurança

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

SQL Server recursos e capacidades fornecem métodos de segurança de dados no nível do banco de dados que podem ser combinados com recursos de segurança no nível da infraestrutura. Juntos, esses recursos fornecem defesa detalhada no nível de infraestrutura para soluções híbridas e baseadas em nuvem. Além disso, com Azure medidas de segurança, é 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 para administração e relatórios para qualquer necessidade de segurança na nuvem híbrida.

  • Use Microsoft Defender for Cloud para avaliar e tomar medidas para melhorar a postura de segurança do ambiente de dados. Recursos como Azure Advanced Threat Protection (ATP) podem ser usados em suas cargas de trabalho híbridas para melhorar a avaliação de segurança e dar a capacidade de reagir aos riscos. Registrar sua VM SQL Server com a extensão SQL IaaS Agent torna visíveis as avaliações do Microsoft Defender para Nuvem no recurso de máquina virtual do SQL do portal Azure.
  • Use Microsoft Defender para SQL para descobrir e reduzir possíveis vulnerabilidades de banco de dados, bem como detectar atividades anômalas que possam indicar uma ameaça à instância SQL Server e à camada de banco de dados.
  • Vulnerability Assessment faz parte do Microsoft Defender para SQL que podem descobrir e ajudar a corrigir possíveis riscos para seu ambiente SQL Server. Ela fornece visibilidade sobre o estado de segurança e inclui etapas acionáveis para resolver problemas de segurança.
  • Use VMs confidenciais do Azure para reforçar a proteção de seus dados em processamento e dados armazenados contra o acesso do operador host. Azure VMs confidenciais permitem que você armazene com confiança seus dados confidenciais na nuvem e atenda a requisitos estritos de conformidade.
  • Se você estiver usando o SQL Server 2022, considere usar a autenticação Microsoft Entra para se conectar à sua instância de SQL Server.
  • Azure Advisor analisa sua telemetria de uso e configuração de recursos e, em seguida, recomenda soluções que podem ajudá-lo a melhorar a eficiência, o desempenho, a alta disponibilidade e a segurança de seus recursos de Azure. Use Azure Advisor no nível de máquina virtual, grupo de recursos ou assinatura para ajudar a identificar e aplicar práticas recomendadas para otimizar suas implantações de Azure.
  • Use Azure Disk Encryption quando sua conformidade e segurança precisarem que você criptografe os dados de ponta a ponta usando suas chaves de criptografia, incluindo a criptografia do disco efêmero (temporário conectado localmente).
  • Managed Disks são criptografados em repouso por padrão usando Azure Storage Service Encryption, em que as chaves de criptografia são chaves gerenciadas pela Microsoft armazenadas em Azure.
  • Para obter uma comparação das opções de criptografia de disco gerenciado, examine 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.
  • Ative Acesso JIT (just-in-time) para máquinas virtuais do Azure.
  • Use Azure Bastion em vez de Protocolo de Área de Trabalho Remota (RDP).
  • Bloqueie as portas e permita apenas o tráfego de aplicativo necessário usando Azure Firewall que é um FaaS (Firewall como Serviço) gerenciado que concede/nega acesso ao servidor com base no endereço IP de origem.
  • Use Network Security Groups (NSGs) para filtrar o tráfego de rede para e de recursos Azure em redes virtuais Azure.
  • Use 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, use Proteção contra DDoS do Azure (Negação de Serviço Distribuída). Ataques de DDoS são projetados para sobrecarregar e esgotar recursos de rede, tornando os aplicativos lentos ou sem resposta. É comum que os DDos sejam direcionados às interfaces do usuário. Azure proteção contra DDoS higieniza o tráfego de rede indesejado antes de afetar 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 Azure Policy para criar regras de negócios que podem ser aplicadas ao seu ambiente. As políticas do Azure avaliam os recursos do Azure comparando as propriedades desses recursos com as regras definidas no formato JSON.
  • Azure Blueprints permite que arquitetos de nuvem e grupos centrais de tecnologia da informação definam um conjunto repetível de recursos Azure que implementa e adere aos padrões, padrões e requisitos de uma organização. Azure Blueprints são diferentes de Azure Policies.
  • Use Windows Server 2019 ou Windows Server 2022 para ser FIPS compatível com SQL Server em VMs Azure.
  • Trate a restauração de backups como uma operação de alto risco e nunca restaure um backup de uma fonte não confiável.

recursos de SQL Server

Veja a seguir uma lista de verificação rápida das práticas recomendadas das configurações do SQL Server ao executar suas instâncias de SQL Server em uma máquina virtual do Azure em ambiente de produção.

recursos de Azure

Veja a seguir uma lista de verificação rápida das práticas recomendadas para diretrizes específicas de Azure ao executar seu SQL Server na VM Azure:

Configuração do HADR

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

Recursos de alta disponibilidade e recuperação de desastres (HADR), como o grupo de disponibilidade Always On e a instância de cluster de failover, dependem da tecnologia subjacente 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 cluster Windows, considere estas práticas recomendadas:

  • Implante suas VMs SQL Server em várias sub-redes sempre que possível para evitar a dependência em um Azure Load Balancer ou um DNN (nome de rede distribuída) para rotear o tráfego para sua solução HADR.
  • Altere o cluster para configurações menos agressivas para evitar interrupções inesperadas devido a falhas transitórias de rede ou à manutenção da plataforma Azure. Para saber mais, confira configurações de pulsação e limite. Para Windows Server 2012 e posterior, use os seguintes valores recomendados:
    • SameSubnetDelay: 1 segundo
    • SameSubnetThreshold: 40 pulsos
    • CrossSubnetDelay: 1 segundo
    • CrossSubnetThreshold: 40 pulsos
  • 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 seu sistema operacional, drivers e SQL Server estão nos builds mais recentes.
    • Otimizar o desempenho para SQL Server em VMs 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 que tenha limites mais altos para evitar restrições.

Para o seu grupo de disponibilidade do SQL Server ou instância de cluster de failover, considere as seguintes práticas recomendadas:

  • 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 no SQL Server não resolver seus failovers inesperados, considere relaxar o monitoramento para o grupo de disponibilidade ou a instância do 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 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 à sua solução HADR, especifique MultiSubnetFailover = true no connection string, mesmo que o cluster abrange 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 cliente que dê suporte a MultiSubnetFailover = True e esse parâmetro deve estar no connection string.
    • Use uma porta exclusiva de DNN na cadeia de conexão ao se conectar 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 dispensar 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 SQL Server, o receptor do grupo de disponibilidade Always On ou a sonda de integridade da instância do cluster de failover estiverem configurados 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

Ao encontrar SQL Server problemas de desempenho, use esses recursos de diagnóstico para identificar e resolver problemas específicos:

Conteúdo relacionado

Para obter diretrizes detalhadas sobre cada área de otimização:

Ferramenta recomendada:Habilitar Avaliação SQL para SQL Server em VMs do Azure para avaliar automaticamente sua configuração em relação a essas melhores práticas.

Confira outros artigos de Máquinas Virtuais do SQL Server em SQL Server on Azure Virtual Machines Overview. Se você tiver dúvidas sobre máquinas virtuais do SQL Server, consulte as Perguntas Frequentes.

  • Last updated on