Grupo de disponibilidade AlwaysOn do Microsoft SQL Server no Google Cloud

Last reviewed 2026-08-12 UTC

Este documento fornece uma arquitetura de referência para implantar bancos de dados do Microsoft SQL Server de alta disponibilidade (HA) em Google Cloud usando um grupo de disponibilidade Always On. O documento também inclui considerações de design para alta disponibilidade (HA) e recuperação de desastres (DR), opções de implantação, recomendações de automação e orientações para operações de backup e DR. Este documento é destinado a profissionais técnicos que estão avaliando o Google Cloud como uma plataforma para executar bancos de dados do SQL Server. Ele pressupõe que você tenha conhecimentos básicos do Compute Engine e do SQL Server.

Google Cloud oferece soluções econômicas, confiáveis, seguras e de alto desempenho para executar bancos de dados do SQL Server. Para uma visão geral das soluções compatíveis do SQL Server no Google Cloud, consulte SQL Server no Google Cloud.

Para operar uma implantação não de desenvolvimento do SQL Server no Google Cloud, use uma das seguintes opções de licenciamento:

A seção Implantação deste documento fornece recursos para ajudar você a implantar essa arquitetura de referência.

Arquitetura

O diagrama a seguir mostra uma arquitetura de referência para uma implantação do SQL Server configurada para alta disponibilidade em Google Cloud:

Uma arquitetura que mostra uma implantação do SQL Server com um grupo de disponibilidade Always On que abrange VMs do Compute Engine em diferentes zonas e regiões.

A arquitetura anterior mostra um grupo de disponibilidade AlwaysOn com três nós em um cluster de failover do Windows Server (WSFC). Cada nó é uma VM do Compute Engine que executa o SQL Server.

Um grupo de disponibilidade Always On é um padrão de implantação do setor para alcançar objetivos de confiabilidade em bancos de dados do SQL Server essenciais para a missão. Os grupos de disponibilidade Always On oferecem alta disponibilidade local (failover em uma região) e failover entre regiões para DR. Esse padrão de implantação é uma alternativa de nível empresarial ao espelhamento de banco de dados. Um grupo de disponibilidade Always On oferece os seguintes benefícios:

  • Não há necessidade de componentes de infraestrutura especializados: o SQL Server gerencia a replicação em todas as réplicas de banco de dados configuradas.
  • Configuração de SLA mais alta para o SQL Server: objetivo de tempo de recuperação (RTO) de menos de um minuto e objetivo de ponto de recuperação (RPO) próximo de zero.
  • Capacidade de descarregar cargas de trabalho somente leitura para réplicas secundárias: dimensione com eficiência sua implantação para análises e outros casos de uso comuns.
  • Nós em regiões adicionais para DR: implante uma réplica principal e até oito réplicas secundárias.
  • Implantação no Windows e no Linux: é possível usar uma ferramenta de terceiros, como o Pacemaker como gerenciador de cluster para implantações do Linux.

Na arquitetura anterior, os nós primário e secundário do SQL Server estão em zonas separadas dentro de uma região. O nó de DR está em uma região geograficamente remota. Os dados do nó principal são replicados de forma síncrona para o nó secundário e de forma assíncrona para o nó de DR.

Para distribuir o tráfego da camada de aplicativo para os nós de banco de dados primário e secundário em uma região, use uma destas abordagens:

Produtos usados

A arquitetura usa os seguintes produtos e componentes da Google Cloud e da Microsoft.

Google Cloud produtos

  • Compute Engine: um serviço de computação seguro e personalizável que permite criar e executar VMs na infraestrutura do Google.
  • Google Cloud Hyperdisk: um serviço de armazenamento em rede que pode ser usado para provisionar e escalonar dinamicamente volumes de armazenamento em blocos com desempenho configurável e previsível.
  • Nuvem privada virtual (VPC): um sistema virtual que oferece funcionalidade de rede global e escalonável para suas cargas de trabalho do Google Cloud . A VPC inclui peering de rede VPC, Private Service Connect, acesso a serviços particulares e VPC compartilhada.
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.

Produtos e componentes da Microsoft

Os seguintes componentes estão incluídos ou ativados nos nós do SQL Server:

  • Windows Server (versão 2019 ou mais recente).
  • WSFC: Um grupo de instâncias do SQL Server instaladas em vários nós de cluster do Windows Server ou em várias sub-redes.
  • Grupo de disponibilidade Always On: uma alternativa de HA e DR de nível empresarial ao espelhamento de banco de dados.
  • Listener do grupo de disponibilidade: um nome de rede virtual (VNN, na sigla em inglês) que os clientes podem usar para acessar um banco de dados em uma réplica primária ou secundária de um grupo de disponibilidade Always On. Os clientes não precisam saber o nome da instância física das réplicas. Como o listener roteia o tráfego, a string de conexão do cliente não precisa ser modificada após um failover.

Os seguintes componentes adicionais são necessários para implantar essa arquitetura:

Considerações sobre o design

Nesta seção, descrevemos fatores de design, práticas recomendadas e recomendações de design que você precisa considerar ao usar essa arquitetura de referência para desenvolver uma topologia que atenda aos seus requisitos de confiabilidade, eficiência operacional, segurança, custo e desempenho.

Confiabilidade

Nesta seção, descrevemos considerações e recomendações de design para criar e operar uma infraestrutura confiável para sua implantação do SQL Server emGoogle Cloud.

Escolher uma estratégia de HA e DR

Para implantar bancos de dados confiáveis do SQL Server em Google Cloud, você precisa de uma estratégia que combine a infraestrutura robusta do Google Cloud com os recursos de alta disponibilidade e recuperação DR do SQL Server. Essa combinação protege seus bancos de dados contra falhas que vão desde interrupções zonais até desastres regionais.

Ao projetar a estratégia de HA e DR para sua implantação do SQL Server, considere os seguintes fatores:

  • RPO: qual é a perda de dados aceitável em caso de falha?
  • RTO: depois de uma falha, em quanto tempo o banco de dados precisa voltar a funcionar?
    • Para ter um RTO baixo, use um grupo de disponibilidade Always On.
    • Se algum tempo de inatividade for aceitável, restaure os bancos de dados usando backups ou use o envio de registros com failover manual.
  • Orçamento: considere as vantagens e desvantagens entre custo e confiabilidade.
    • Alto custo, mas confiável: use um grupo de disponibilidade Always On com replicação assíncrona para nós adicionais em uma região de DR. Planeje infraestrutura e licenças redundantes.
    • Custo médio: implemente a replicação assíncrona de disco em outra região ou use o serviço de backup e DR.
    • Baixo custo, mas alto tempo de recuperação: faça backup dos bancos de dados em um bucket multirregional do Cloud Storage.
  • Tipos de falhas: quais tipos de falhas você precisa processar?
    • Para lidar com falhas no nível do hardware, da instância e da zona, use grupos de disponibilidade.
    • Para se recuperar de interrupções ou desastres em todo o site, é necessário uma solução DR geograficamente dispersa, como o envio de registros ou grupos de disponibilidade Always On com replicação assíncrona de banco de dados.
  • Criticidade comercial: qual é a importância do aplicativo para sua empresa?
    • Os aplicativos essenciais precisam de uma estratégia que ofereça o mais alto nível de disponibilidade, perda mínima de dados e recuperação rápida.
    • Para sistemas menos críticos, considere uma estratégia que pressuponha um tempo de inatividade aceitável ou alguma perda de dados.

Use o questionário de fluxo de decisão a seguir para escolher uma estratégia de confiabilidade ideal para seu banco de dados do SQL Server. As opções de estratégia variam de um grupo de disponibilidade AlwaysOn que oferece perda de dados quase nula a um backup externo econômico.

  1. Os backups externos atendem ao seu RPO e RTO?
    • Sim: use backups externos ou envio de registros.
    • Não: vá para a próxima pergunta.
  2. Seu RTO ou RPO é menor que um minuto?
    • Sim (RPO quase zero): use um grupo de disponibilidade Always On do SQL Server com uma réplica de banco de dados de DR.
    • Não: vá para a próxima pergunta.
  3. Qual é seu RTO?
    • Menos de cinco minutos: use um grupo de disponibilidade Always On do SQL Server com uma réplica de disco assíncrona.
    • Uma hora ou mais: vá para a próxima pergunta.
  4. Qual é seu RPO?
    • Menos de duas horas: use um grupo de disponibilidade Always On do SQL Server com o serviço de backup e DR.
    • Oito horas ou mais: use backups externos ou envio de registros.

Escolher as opções de backup adequadas

Se a sua estratégia de confiabilidade incluir backups de banco de dados, escolha um método que atenda aos seus requisitos.O Google Cloud oferece as seguintes opções flexíveis e prontas para empresas de backup de bancos de dados do SQL Server:

  • Backup direto para um bucket do Cloud Storage: grave backups de banco de dados diretamente no Cloud Storage usando o comando BACKUP TO URL e o conector S3 no SQL Server (versão 2022 ou mais recente). Para ambientes de produção, use uma chave de acesso de código de autenticação de mensagem baseada em hash (HMAC). Essa opção de backup oferece proteção econômica para bancos de dados e registros sem a necessidade de armazenamento local intermediário.
  • Snapshots instantâneos do Compute Engine: capture snapshots simultâneos em vários discos (por exemplo, em discos Hyperdisk Balanced) em menos de um segundo usando operações de congelamento e descongelamento do Transact-SQL (T-SQL) combinadas com grupos de consistência do Compute Engine. Essa opção permite backups de alto desempenho no nível da VM para bancos de dados de vários discos e tem um requisito de congelamento de gravação quase zero.
  • Backup e DR: orquestre snapshots consistentes de aplicativos usando provedores Microsoft VSS e grupos de consistência. Essa opção de backup é adequada quando você precisa de uma recuperação pontual (PITR) granular e de vários bancos de dados, além da capacidade de usar registros para encaminhar bancos de dados.
  • Google Cloud NetApp Volumes: crie snapshots instantâneos e backups assíncronos em vaults remotos usando o mecanismo de armazenamento ONTAP. Recomendamos o NetApp Volumes para aplicativos empresariais sensíveis à latência que precisam de mitigação rápida de ransomware e clones com uso eficiente de espaço.

Para implantações híbridas e multicloud que precisam de políticas unificadas de proteção de dados, escolha um produto de backup de terceiros, como Veeam, Veritas NetBackup ou Cohesity.

Operações

Para ajudar a garantir a alta disponibilidade e o desempenho ideal dos bancos de dados do SQL Server implantados em VMs do Compute Engine, configure um sistema abrangente de monitoramento e alertas usando o Cloud Monitoring e o Cloud Logging.

  • Acompanhe continuamente as métricas dos recursos principais, como utilização da CPU e carga de memória. Configure alertas de valor de referência para detectar pressão nos recursos antes que as consultas comecem a apresentar falhas.
  • Para evitar interrupções na gravação do banco de dados, observe continuamente a utilização do espaço em disco. Monitore o status geral do serviço e configure alertas para receber notificações quando os bancos de dados pararem inesperadamente.
  • Para implantações de alta disponibilidade, acompanhe todos os failovers não planejados e garanta visibilidade completa durante eventos automatizados de recuperação de desastres.
  • Além da telemetria no nível do sistema,o Google Cloud fornece um conjunto extenso de métricas específicas do banco de dados, como limites de conexão de usuários ativos, atraso de replicação e taxas de transação. Acompanhe essas métricas para monitorar a disponibilidade e o desempenho dos seus bancos de dados SQL Server.
  • Para capturar erros no nível do aplicativo, como deadlocks, corrupção de banco de dados e falhas de jobs do agente diretamente dos registros de erros do SQL Server, configure alertas personalizados baseados em registros no Logging.

Segurança

Esta seção descreve considerações e recomendações de design para projetar uma implantação do SQL Server em Google Cloud que atenda aos requisitos de segurança da sua carga de trabalho.

Segurança e isolamento de rede

  • Para evitar a exposição externa dos bancos de dados, implante as instâncias do SQL Server com endereços IP particulares em uma VPC. Use o acesso a serviços particulares para rotear o tráfego internamente. Essa abordagem ajuda a garantir que o tráfego do banco de dados nunca passe pela Internet pública.
  • Restrinja ainda mais o acesso aos bancos de dados configurando regras estritas de firewall da VPC que permitem o tráfego apenas de sub-redes de aplicativos autorizadas ou blocos CIDR específicos.
  • Para proteger os dados em trânsito contra escutas e interceptações, implemente conectividade criptografada aplicando TLS/SSL a todas as conexões de banco de dados.

Criptografia e controle de chaves

  • Por padrão, o Google Cloud usa chaves AES-256 gerenciadas pelo Google para criptografar automaticamente todos os dados em repouso em discos de banco de dados, arquivos temporários e backups. Para atender aos ambientes de compliance, é possível implementar a criptografia no nível do banco de dados usando o recurso de criptografia de dados transparente (TDE) do SQL Server.
  • Para ajudar a garantir a soberania dos dados, use as chaves de criptografia gerenciadas pelo cliente (CMEK) no Cloud Key Management Service. As CMEKs oferecem controle criptográfico total. Você gerencia os ciclos de vida das chaves, define programações de rotação automática e revoga instantaneamente o acesso ao banco de dados e aos backups dele quando necessário.

Autenticação e autorização

  • Integre seu banco de dados ao Microsoft Active Directory ou centralize o gerenciamento de identidades nos bancos de dados do SQL Server e em outros recursos doGoogle Cloud usando o Identity and Access Management (IAM).
  • Depois que as identidades forem estabelecidas, aplique o princípio de privilégio mínimo para que os usuários e as contas de serviço do aplicativo tenham apenas as permissões necessárias para realizar as funções. Mapear identidades para funções granulares do banco de dados do SQL Server.

Otimização de custos

Nesta seção, você encontra orientações para otimizar o custo de configuração e operação de uma implantação do SQL Server criada usando essa arquitetura de referência. A otimização de custos ajuda a garantir que a implantação atenda aos requisitos de confiabilidade e desempenho da sua carga de trabalho dentro das restrições de orçamento.

Considere as seguintes recomendações:

  • Desative a multissegmentação simultânea (SMT): ao desativar a SMT, é possível reduzir em 50% a contagem de núcleos informada para fins de licenciamento. Ao superprovisionar as CPUs em 20% e desativar a SMT, é possível economizar bastante nos custos de licenciamento sem sacrificar o desempenho. Para mais informações, consulte Definir o número de linhas de execução por núcleo.
  • Use o SQL Server Standard Edition: dependendo dos seus requisitos de HA e DR, é possível reduzir o custo de licenciamento usando o SQL Server Standard Edition em vez do Enterprise Edition. Para mais informações, consulte Edições e recursos compatíveis do SQL Server.
  • Otimizar o armazenamento: o Hyperdisk oferece diferentes opções de disco que podem ser escolhidas com base nas necessidades da sua implantação do SQL Server. O Hyperdisk Balanced oferece um equilíbrio entre custo e desempenho. É possível escalonar a capacidade de processamento e as operações de entrada/saída por segundo (IOPS) de forma independente para que o gasto com infraestrutura corresponda exatamente às necessidades da carga de trabalho. Para mais informações, consulte a seção Escolher um tipo de disco de armazenamento adequado.

Otimização de desempenho

Esta seção descreve considerações e recomendações de design para uma implantação do SQL Server que atenda aos seus requisitos de desempenho.

Ao implantar o SQL Server em VMs do Compute Engine, você tem controle total do banco de dados e da infraestrutura subjacente. O desempenho da sua carga de trabalho depende da infraestrutura escolhida. Para equilibrar desempenho, custo e confiabilidade, é preciso tomar decisões embasadas sobre a família de máquinas da VM e o tipo de disco para os nós do banco de dados.

Escolher uma família de máquinas de VM adequada

A família de máquinas escolhida para as VMs do Compute Engine determina a capacidade de processamento (vCPU) e a memória (RAM) disponíveis para os nós do SQL Server. Esses recursos afetam a performance dos seus bancos de dados.

Escolha uma família de máquinas de VM que resolva seu principal gargalo de performance. Por exemplo, se o banco de dados do SQL Server estiver constantemente com uso alto de CPU, escolha um tipo de máquina da família otimizada para computação. Se o banco de dados do SQL Server mostrar leituras lentas do disco, escolha um tipo de máquina com otimização de memória.

A tabela a seguir compara as famílias de máquinas de VM fornecidas pelo Compute Engine, o caso de uso principal de cada família e o impacto na performance dos bancos de dados do SQL Server:

Família e série de máquinas Caso de uso principal Impacto no desempenho do SQL Server
Uso geral (série de máquinas N4) Equilíbrio entre preço e desempenho Use essa família de máquinas como ponto de partida para a maioria das cargas de trabalho. A série de máquinas N4 oferece um equilíbrio ideal de CPU e memória para bancos de dados de uso misto, aplicativos da Web e ambientes de desenvolvimento ou teste.
Otimização para computação (séries de máquinas C3 ou C4) Maior desempenho por núcleo Use essa família de máquinas para cargas de trabalho vinculadas à CPU. Para bancos de dados que executam consultas complexas, processam grandes volumes de dados ou atendem a um grande número de operações de processamento de transações on-line (OLTP), use as séries de máquinas C3 e C4. Os tipos de máquina dessas séries ajudam a reduzir significativamente o tempo de execução da consulta.
Otimização de memória (série de máquinas M3 ou M4) Proporções grandes de memória para vCPU Essa família de máquinas é ideal para aplicativos com uso intensivo de memória. O SQL Server armazena em cache dados e planos de execução na memória, o que oferece um desempenho maior do que a leitura de discos. Com bancos de dados ou data warehouses muito grandes para processamento analítico on-line (OLAP), as consultas geralmente verificam tabelas e conjuntos de dados grandes. Para esses casos de uso, uma memória maior ajuda a melhorar o desempenho.

Para mais informações, consulte o Guia de comparação e recursos para famílias de máquinas.

Escolher um tipo de disco de armazenamento adequado

O desempenho do disco é um fator significativo para a capacidade de resposta do banco de dados, que é fundamental para o desempenho do aplicativo. Para os tipos de disco que o Google Cloudoferece, as capacidades de desempenho são indicadas usando as seguintes métricas:

  • IOPS: o número de solicitações de leitura e gravação que um disco pode processar por segundo. O IOPS é fundamental para cargas de trabalho de OLTP que envolvem muitas operações pequenas e aleatórias de leitura e gravação, como atualizar registros de clientes ou processar pedidos.
  • Capacidade de processamento: a quantidade total de dados que podem ser movidos para ou do disco por segundo. A capacidade de processamento é essencial para cargas de trabalho OLAP que envolvem a verificação de grandes quantidades de dados, como a execução de relatórios, o armazenamento em data warehouse ou a realização de backups.

A tabela a seguir compara os Google Cloud tipos de disco que você pode escolher:

Tipo de disco Características de desempenho Adequação da carga de trabalho
Disco permanente SSD (pd-ssd) Desempenho médio a alto, dependendo do tipo de máquina da VM e do tamanho do disco Cargas de trabalho que exigem escalonamento de desempenho com o tamanho do disco e as vCPUs da VM. Para mais informações, consulte Visão geral da performance do Persistent Disk.
Hiperdisco equilibrado Alto desempenho com IOPS e capacidade de processamento configuráveis Arquivos de dados e de registros do SQL Server de produção. Com o Hyperdisk equilibrado, é possível configurar IOPS e capacidade de processamento de forma independente do tamanho do disco e com base nas necessidades da carga de trabalho.
Hiperdisco extremo Desempenho muito alto com IOPS configuráveis Cargas de trabalho de OLTP essenciais e sofisticadas que precisam de IOPS máximos e da menor latência, como sistemas financeiros ou de e-commerce em grande escala.
SSD local Maior IOPS e capacidade de processamento em comparação com os outros tipos de disco Dados temporários que não precisam da durabilidade dos discos permanentes. Para dados como o banco de dados do sistema tempdb e o arquivo de paginação do Windows, os SSDs locais oferecem a menor latência porque estão anexados fisicamente às VMs.

Correlacionar a infraestrutura aos requisitos de performance

Escolha tipos de máquina e disco de VM com base nos requisitos de desempenho da carga de trabalho. A tabela a seguir recomenda configurações de infraestrutura para diferentes cenários de carga de trabalho:

Cenário Requisitos de desempenho Tipo de máquina e configuração de disco recomendados
Banco de dados de e-commerce de alta transação para OLTP IOPS altas para processar milhares de leituras e gravações pequenas e simultâneas

Tipo de máquina da VM: escolha um tipo de máquina otimizado para computação (por exemplo, da série de máquinas C4) para processar transações com eficiência.

Discos de dados e de registros: use discos balanceados de hiperdisco. Provisione um alto nível de IOPS para atender à demanda transacional. Use discos separados para dados e registros.

tempdb: use discos SSD locais para descarregar operações temporárias e maximizar o desempenho.
Data warehouse da empresa para OLAP Alta capacidade de processamento para verificar e agregar terabytes de dados para geração de relatórios

Tipo de máquina da VM: escolha um tipo de máquina com otimização de memória (por exemplo, da série M4) para armazenar em cache o máximo possível do conjunto de dados grande.

Disco de dados: use discos Hyperdisk Balanced. Provisione um alto nível de capacidade de processamento para acelerar verificações de dados grandes.
Servidor de desenvolvimento ou de teste Relação custo-benefício em vez de desempenho máximo

Tipo de máquina da VM: escolha um tipo de máquina de uso geral com um tamanho pequeno das séries E2 ou N4.

Discos: use o disco permanente equilibrado (pd-balanced) para todos os arquivos de banco de dados e alcançar um desempenho aceitável a um baixo custo.

Implantação

Para implantar essa arquitetura de referência, use um dos seguintes recursos:

A seguir

Colaboradores

Autores:

Outro colaborador: Kumar Dhanagopal | Desenvolvedor de soluções com vários produtos