Grupo de disponibilidade Always On do Microsoft SQL Server no Google Cloud

Last reviewed 2026-08-12 UTC

Neste documento, apresentamos uma arquitetura de referência para implantar bancos de dados do Microsoft SQL Server de alta disponibilidade (HA) no Google Cloud usando um grupo de disponibilidade Always On. O documento também inclui considerações de design para 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.

OGoogle 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 do SQL Server compatíveis com o Google Cloud, consulte SQL Server no Google Cloud.

Para operar uma implantação de não 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 no 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 sempre ativado 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 padrão do setor para atingir objetivos de confiabilidade para bancos de dados do SQL Server de missão crítica. 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) quase zero.
  • Capacidade de descarregar cargas de trabalho somente leitura para réplicas secundárias: escalone sua implantação de maneira eficiente para análises e outros casos de uso comuns.
  • Nós em outras regiões para DR: implante uma réplica primária e até oito réplicas secundárias.
  • Implantável no Windows e no Linux: é possível usar uma ferramenta de terceiros, como o Pacemaker, como o gerenciador de clusters 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 do aplicativo para os nós de banco de dados primário e secundário em uma região, use uma das seguintes abordagens:

Produtos usados

A arquitetura usa os seguintes produtos e componentes do 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 para o 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 sempre ativado. 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 esta arquitetura:

Considerações sobre o design

Nesta seção, descrevemos os fatores de design, as práticas recomendadas e as 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 as considerações e recomendações de design para criar e operar uma infraestrutura confiável para sua implantação do SQL Server no Google Cloud.

Escolher uma estratégia de HA e DR

Para implantar bancos de dados confiáveis do SQL Server no 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 de interrupções zonais a desastres regionais.

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

  • RPO: quanta perda de dados é aceitável em caso de falha?
  • RTO: após uma falha, em quanto tempo o banco de dados precisa voltar a funcionar?
    • Para conseguir um RTO baixo, use um grupo de disponibilidade Always On.
    • Se algum tempo de inatividade for aceitável, restaure os bancos de dados de backups ou use o envio de registros com failover manual.
  • Orçamento: considere as vantagens e desvantagens entre custo e confiabilidade.
    • Custo alto, 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 uma infraestrutura e licenças redundantes.
    • Custo médio: implemente a replicação assíncrona de disco para outra região ou use o Backup e DR.
    • Baixo custo, mas alto tempo de recuperação: faça backup dos bancos de dados em um bucket do Cloud Storage multirregional.
  • 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, você precisa de uma solução de DR geograficamente dispersa, como envio de registros ou grupos de disponibilidade Always On com replicação de banco de dados assíncrona.
  • Importância para os negócios: 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 assuma um tempo de inatividade aceitável ou alguma perda de dados.

Use o seguinte questionário de fluxo de decisão 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 Always On, que oferece perda de dados quase zero, 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: prossiga 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 Backup e DR.
    • Oito horas ou mais: use backups externos ou envio de registros.

Escolher as opções de backup adequadas

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

  • Backup direto em um bucket do Cloud Storage: grave backups de banco de dados diretamente no Cloud Storage usando o comando BACKUP TO URL e o conector do S3 no SQL Server (versão 2022 ou posterior). Para ambientes de produção, use uma chave de acesso de código de autenticação de mensagem baseado 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 do Google Cloud 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 com o aplicativo usando provedores do Microsoft VSS e grupos de consistência. Essa opção de backup é adequada quando você precisa de uma recuperação pontual (PITR) granular de vários bancos de dados e da capacidade de usar registros para avançar 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 eficientes em termos 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 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 de 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 se degradar.
  • Para evitar interrupções na gravação do banco de dados, observe continuamente o uso 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 oferece 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 bancos de dados do SQL Server.
  • Para capturar erros no nível do aplicativo, como impasses, corrupção de banco de dados e falhas de jobs do agente diretamente dos registros de erros do SQL Server, configure alertas personalizados com base em registros no Logging.

Segurança

Nesta seção, descrevemos as considerações e recomendações de design para projetar uma implantação do SQL Server no Google Cloud que atenda aos requisitos de segurança da 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 privados 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 atravesse a Internet pública.
  • Restrinja ainda mais o acesso aos bancos de dados configurando regras rígidas de firewall da VPC que permitam o tráfego apenas de sub-redes de aplicativos autorizadas ou blocos CIDR específicos.
  • Para proteger os dados em trânsito contra espionagem e interceptação, implemente a 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 ajudar a atender aos ambientes de conformidade, é possível implementar a criptografia no nível do banco de dados usando o recurso de criptografia de dados transparente (TDE, na sigla em inglês) do SQL Server.
  • Para ajudar a garantir a soberania de dados, use 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 identidade 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 de aplicativos tenham apenas as permissões necessárias para executar as funções deles. Mapeie identidades para papéis 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 carga de trabalho dentro das restrições de orçamento.

Recomendações:

  • Desativar a multissegmentação simultânea (SMT, na sigla em inglês): 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 muito nos custos de licenciamento sem sacrificar o desempenho. Para mais informações, consulte Configurar o número de linhas de execução por núcleo.
  • Use o SQL Server Standard Edition: dependendo dos requisitos de alta disponibilidade e DR, é possível reduzir o custo de licenciamento usando a edição Standard do SQL Server em vez da Enterprise. Para mais informações, consulte Edições e recursos compatíveis do SQL Server.
  • Otimizar o armazenamento: o Google Cloud Hyperdisk oferece diferentes opções de disco que podem ser escolhidas com base nas necessidades da 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 os gastos com infraestrutura correspondam 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

Nesta seção, descrevemos as considerações de design e as recomendações 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 carga de trabalho depende da infraestrutura escolhida. Para equilibrar o desempenho com o custo e a confiabilidade, é preciso tomar decisões informadas 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 o desempenho dos bancos de dados.

Escolha uma família de máquinas de VM que resolva o principal gargalo de desempenho. Por exemplo, se o banco de dados do SQL Server estiver constantemente com alto uso de CPU, escolha um tipo de máquina da família de máquinas com otimização 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 principal caso de uso de cada família de máquinas e o impacto no desempenho em 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.
Otimizado para computação (série 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 realizam consultas complexas, processam grandes volumes de dados ou atendem a um alto 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.
Com 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 intenso de memória. O SQL Server armazena em cache dados e planos de execução na memória, o que oferece um desempenho melhor do que a leitura de discos. Com bancos de dados ou data warehouses muito grandes para processamento analítico on-line (OLAP), as consultas normalmente 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 Cloud oferece, os recursos de desempenho são indicados usando as seguintes métricas:

  • IOPS: o número de solicitações de leitura e gravação que um disco pode processar por segundo. As IOPS são essenciais para cargas de trabalho 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 pode ser movida 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 tipos de disco do Google Cloud 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 que o desempenho seja escalonado de acordo com o tamanho do disco e as vCPUs da VM. Para mais informações, consulte Visão geral do desempenho do disco permanente.
Hiperdisco equilibrado Alto desempenho com IOPS e capacidade de processamento configuráveis Arquivos de registro e dados do SQL Server de produção. O Hyperdisk Balanced permite configurar IOPS e capacidade de processamento independentemente do tamanho do disco e com base nas necessidades da carga de trabalho.
Google Cloud Hyperdisk Extreme Desempenho muito alto com IOPS configuráveis Cargas de trabalho OLTP sofisticadas e essenciais que precisam de IOPS máximo e da menor latência, como sistemas financeiros ou de e-commerce em grande escala.
SSD local IOPS e capacidade de processamento mais altas 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 fornecem a menor latência porque estão fisicamente anexados às VMs.

Adequar a infraestrutura aos requisitos de desempenho

Escolha os tipos de máquina de VM e de disco com base nos requisitos de desempenho da sua 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 lidar com milhares de leituras e gravações simultâneas pequenas

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 de forma eficiente.

Discos de dados e de registro: use discos do Hyperdisk Balanced. 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 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 de máquinas 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 as verificações de dados grandes.
Servidor de desenvolvimento ou de preparo 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 da série de máquinas E2 ou da série de máquinas N4.

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

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