Implementação multirregional no Compute Engine

Last reviewed 2025-08-11 UTC

Este documento fornece uma arquitetura de referência para uma aplicação de vários níveis que é executada em VMs do Compute Engine em várias regiões no Google Cloud. Pode usar esta arquitetura de referência para realoojar (mover e alterar) de forma eficiente aplicações no local para a nuvem com alterações mínimas às aplicações. O documento também descreve os fatores de design que deve considerar quando cria uma arquitetura multirregional para as suas aplicações na nuvem. O público-alvo pretendido para este documento são arquitetos da nuvem.

Arquitetura

O diagrama seguinte mostra uma arquitetura para uma aplicação que é executada no modo ativo-ativo em pilhas isoladas implementadas em duas Google Cloud regiões. Em cada região, a aplicação é executada de forma independente em três zonas. A arquitetura está alinhada com o Google Cloud arquétipo de implementação multirregional, o que garante que a sua Google Cloud topologia é robusta contra falhas de zonas e regiões, e que oferece baixa latência aos utilizadores da aplicação.

Arquitetura multirregional com um balanceador de carga global

A arquitetura baseia-se no modelo de nuvem de infraestrutura como serviço (IaaS). Aprovisiona os recursos de infraestrutura necessários (computação, rede e armazenamento) no Google Cloude mantém o controlo total e a responsabilidade pelo sistema operativo, middleware e camadas superiores da pilha de aplicações. Para saber mais sobre a IaaS e outros modelos na nuvem, consulte o artigo PaaS vs. IaaS vs. SaaS vs. CaaS: How are they different?

O diagrama anterior inclui os seguintes componentes:

Componente Purpose
Balanceador de carga externo global

O balanceador de carga externo global recebe e distribui pedidos de utilizadores para a aplicação. O balanceador de carga externo global anuncia um único endereço IP anycast, mas é implementado como um grande número de proxies nos front-ends da Google (GFEs). Os pedidos do cliente são direcionados para o GFE mais próximo do cliente.
Grupos de instâncias geridas (GIGs) regionais para a camada Web

A camada Web da aplicação é implementada em VMs do Compute Engine que fazem parte de GIGs regionais. Estes MIGs são os back-ends do balanceador de carga global.

Cada MIG contém VMs do Compute Engine em três zonas diferentes. Cada uma destas VMs aloja uma instância independente da camada Web da aplicação.
Balanceadores de carga internos regionais

O balanceador de carga interno em cada região distribui o tráfego das VMs da camada Web para as VMs da camada de aplicação nessa região.
Grupos de instâncias geridos regionais para o nível da aplicação

A camada de aplicação é implementada em VMs do Compute Engine que fazem parte de GIGs regionais. O MIG em cada região é o back-end do balanceador de carga interno nessa região.

Cada MIG contém VMs do Compute Engine em três zonas diferentes. Cada MV aloja uma instância independente da camada de aplicação.
Base de dados de terceiros implementada em VMs do Compute Engine

A arquitetura neste documento mostra uma base de dados de terceiros (como o PostgreSQL) implementada em VMs do Compute Engine nas duas regiões. Pode configurar a replicação entre regiões para as bases de dados e configurar a base de dados em cada região para comutar para a base de dados na outra região em caso de falha. As capacidades de replicação e de comutação por falha dependem da base de dados que usa.

A instalação e a gestão de uma base de dados de terceiros envolvem um esforço adicional e um custo operacional para a replicação, a aplicação de atualizações, a monitorização e a garantia da disponibilidade. Pode evitar a sobrecarga da instalação e gestão de uma base de dados de terceiros e tirar partido das funcionalidades de alta disponibilidade (HA) incorporadas usando uma base de dados totalmente gerida, como uma instância do Spanner de várias regiões.
Rede de nuvem virtual privada e sub-redes

Todos os Google Cloud recursos na arquitetura usam uma única rede VPC que tem sub-redes em duas regiões diferentes.

Consoante os seus requisitos, pode optar por criar uma arquitetura que use várias redes VPC e sub-redes. Para mais informações, consulte o artigo Decidir se deve criar várias redes VPC.
Contentores de Cloud Storage de região dupla

As cópias de segurança da base de dados são armazenadas em contentores do Cloud Storage de dupla região. Em alternativa, pode usar o serviço de cópia de segurança e recuperação de desastres para criar, armazenar e gerir as cópias de segurança da base de dados.

Produtos usados

Esta arquitetura de referência usa os seguintes produtos Google Cloud :

  • Compute Engine: um serviço de computação seguro e personalizável que lhe permite criar e executar VMs na infraestrutura da Google.
  • Cloud Load Balancing: um portefólio de balanceadores de carga globais, escaláveis e de elevado desempenho, bem como balanceadores de carga regionais.
  • Cloud Storage: um serviço de armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acedidos a partir do interior e do exterior Google Cloud, e são replicados em várias localizações para redundância.
  • Nuvem virtual privada (VPC): um sistema virtual que oferece funcionalidade de rede global e escalável para as suas Google Cloud cargas de trabalho. A VPC inclui o intercâmbio da rede da VPC, o Private Service Connect, o acesso a serviços privados e a VPC partilhada.

Exemplos de utilização

Esta secção descreve exemplos de utilização para os quais uma implementação multirregional no Compute Engine é uma escolha adequada.

Migração eficiente de aplicações nas instalações

Pode usar esta arquitetura de referência para criar uma Google Cloud topologia para retransmitir (lift and shift) aplicações no local para a nuvem com alterações mínimas às aplicações. Todos os níveis da aplicação nesta arquitetura de referência estão alojados em VMs do Compute Engine. Esta abordagem permite-lhe migrar aplicações locais de forma eficiente para a nuvem e tirar partido das vantagens de custo, fiabilidade, desempenho e simplicidade operacional que o Google Cloud oferece.

Alta disponibilidade para utilizadores geograficamente dispersos

Recomendamos uma implementação multirregional para aplicações que sejam essenciais para o negócio e onde a alta disponibilidade e a robustez contra interrupções da região sejam essenciais. Se uma região ficar indisponível por qualquer motivo (mesmo uma interrupção em grande escala causada por um desastre natural), os utilizadores da aplicação não sofrem qualquer tempo de inatividade. O tráfego é encaminhado para a aplicação nas outras regiões disponíveis. Se os dados forem replicados de forma síncrona, o objetivo de tempo de recuperação (RTO) é quase zero.

Latência baixa para utilizadores da aplicação

Se os seus utilizadores estiverem numa área geográfica específica, como um continente, pode usar uma implementação multirregional para alcançar um equilíbrio ideal entre a disponibilidade e o desempenho. Quando uma das regiões tem uma indisponibilidade, o balanceador de carga global envia pedidos originários dessa região para outra região. Os utilizadores não percebem um impacto significativo no desempenho porque as regiões estão dentro de uma área geográfica.

Design alternativo

A arquitetura anterior usa um balanceador de carga global, que suporta determinadas funcionalidades para melhorar a fiabilidade das suas implementações, como o armazenamento em cache na extremidade através do Cloud CDN. Esta secção apresenta uma arquitetura alternativa que usa equilibradores de carga regionais e o Cloud DNS. Esta arquitetura alternativa suporta as seguintes funcionalidades adicionais:

  • Encerramento do Transport Layer Security (TLS) em regiões específicas.
  • Capacidade de publicar conteúdo a partir da região que especificar. No entanto, essa região pode não ser a região com melhor desempenho num determinado momento.
  • Uma gama mais ampla de protocolos de ligação se usar um equilibrador de carga de rede de encaminhamento.

Para mais informações sobre as diferenças entre os balanceadores de carga regionais e globais, consulte os artigos Balanceamento de carga global versus regional e Modos de funcionamento.

Arquitetura multirregional que usa balanceadores de carga regionais e DNS.

A arquitetura alternativa no diagrama anterior é robusta contra falhas de zonas e regiões. Uma zona pública do Cloud DNS encaminha os pedidos dos utilizadores para a região adequada. Os balanceadores de carga externos regionais recebem pedidos dos utilizadores e distribuem-nos pelas instâncias da camada Web da aplicação em cada região. Os outros componentes nesta arquitetura são idênticos aos componentes na arquitetura baseada no balanceador de carga global.

Considerações de design

Esta secção fornece orientações para ajudar a usar esta arquitetura de referência para desenvolver uma arquitetura que cumpra os seus requisitos específicos de design do sistema, segurança, fiabilidade, eficiência operacional, custo e desempenho.

Quando cria uma arquitetura para a sua carga de trabalho, considere as práticas recomendadas e as recomendações na Google Cloud framework Well-Architected.

Design do sistema

Esta secção fornece orientações para ajudar a escolher Google Cloud regiões para a sua implementação multirregional e a selecionar Google Cloud serviços adequados.

Seleção de região

Quando escolher as Google Cloud regiões onde as suas aplicações têm de ser implementadas, considere os seguintes fatores e requisitos:

  • Disponibilidade de Google Cloud serviços em cada região. Para mais informações, consulte Produtos disponíveis por localização.
  • Disponibilidade dos tipos de máquinas do Compute Engine em cada região. Para mais informações, consulte o artigo Regiões e zonas.
  • Requisitos de latência do utilizador final.
  • Custo dos Google Cloud recursos.
  • Custos de transferência de dados entre regiões.
  • Requisitos regulamentares.

Alguns destes fatores e requisitos podem envolver compromissos. Por exemplo, a região mais rentável pode não ter a menor pegada de carbono. Para mais informações, consulte o artigo Práticas recomendadas para a seleção de regiões do Compute Engine.

Infraestrutura de computação

A arquitetura de referência neste documento usa VMs do Compute Engine para determinados níveis da aplicação. Consoante os requisitos da sua aplicação, pode escolher entre outros Google Cloud serviços de computação:

  • Contentores: pode executar aplicações em contentores em clusters do Google Kubernetes Engine (GKE). O GKE é um motor de orquestração de contentores que automatiza a implementação, o dimensionamento e a gestão de aplicações contentorizadas.
  • Sem servidor: se preferir concentrar os seus esforços de TI nos dados e nas aplicações em vez de configurar e operar recursos de infraestrutura, pode usar serviços sem servidor, como o Cloud Run.

A decisão de usar VMs, contentores ou serviços sem servidor envolve uma troca entre a flexibilidade da configuração e o esforço de gestão. As VMs e os contentores oferecem mais flexibilidade de configuração, mas é responsável pela gestão dos recursos. Numa arquitetura sem servidor, implementa cargas de trabalho numa plataforma pré-configurada que requer um esforço de gestão mínimo. Para mais informações sobre a escolha de serviços de computação adequados para as suas cargas de trabalho no Google Cloud, consulte Alojamento de aplicações no Google Cloud.

Serviços de armazenamento

As arquiteturas apresentadas neste documento usam volumes de discos persistentes regionais para todos os níveis. Os Persistent Disks oferecem replicação síncrona de dados em duas zonas numa região.

O Hyperdisk do Google Cloud oferece melhor desempenho, flexibilidade e eficiência do que o disco persistente. Com o Hyperdisk Balanced, pode aprovisionar IOPS e débito separadamente e de forma dinâmica, o que lhe permite ajustar o volume a uma grande variedade de cargas de trabalho.

Para armazenamento de baixo custo replicado em várias localizações, pode usar contentores regionais, de duas regiões ou multirregionais do Cloud Storage.

  • Os dados em contentores regionais são replicados de forma síncrona nas zonas da região.
  • Os dados em contentores de duas regiões ou multirregiões são armazenados de forma redundante em, pelo menos, duas localizações geográficas separadas. Os metadados são escritos de forma síncrona em todas as regiões, e os dados são replicados de forma assíncrona. Para contentores de dupla região, pode usar a replicação turbo, que garante que os objetos são replicados em pares de regiões, com um objetivo de ponto de recuperação (RPO) de 15 minutos. Para mais informações, consulte o artigo Disponibilidade e durabilidade dos dados.

Para armazenar dados partilhados por várias VMs numa região, como todas as VMs na camada Web ou na camada de aplicação, pode usar uma instância regional do Filestore. Os dados que armazena numa instância regional do Filestore são replicados de forma síncrona em três zonas na região. Esta replicação garante a alta disponibilidade e a robustez contra falhas de zonas. Pode armazenar ficheiros de configuração partilhados, ferramentas e utilitários comuns, e registos centralizados na instância do Filestore e montar a instância em várias VMs. Para garantir a robustez contra interrupções regionais, pode replicar uma instância do Filestore para uma região diferente. Para mais informações, consulte o artigo Replicação de instâncias.

Se a sua base de dados for o Microsoft SQL Server, recomendamos que use o Cloud SQL para SQL Server. Em cenários em que o Cloud SQL não suporta os seus requisitos de configuração ou se precisar de acesso ao sistema operativo, pode implementar uma instância de cluster de failover (FCI) do Microsoft SQL Server. Neste cenário, pode usar os volumes do Google Cloud NetApp totalmente geridos para fornecer armazenamento SMB de disponibilidade contínua (CA) para a base de dados.

Quando cria armazenamento para as suas cargas de trabalho, tenha em conta as características funcionais, os requisitos de resiliência, as expetativas de desempenho e os objetivos de custo. Para mais informações, consulte o artigo Crie uma estratégia de armazenamento ideal para a sua carga de trabalho na nuvem.

Serviços de bases de dados

A arquitetura de referência neste documento usa uma base de dados de terceiros implementada em VMs do Compute Engine. A instalação e a gestão de uma base de dados de terceiros implicam esforço e custos para operações como a aplicação de atualizações, a monitorização e a garantia da disponibilidade, a realização de cópias de segurança e a recuperação de falhas.

Pode evitar o esforço e o custo de instalar e gerir uma base de dados de terceiros usando um serviço de base de dados totalmente gerido como o Cloud SQL, o AlloyDB para PostgreSQL, o Bigtable, o Spanner ou o Firestore. Estes Google Cloud serviços de base de dados oferecem contratos de nível de serviço (SLAs) de tempo de atividade e incluem capacidades predefinidas de escalabilidade e observabilidade.

Se a sua carga de trabalho precisar de uma base de dados Oracle, pode implementar a base de dados numa VM do Compute Engine ou usar o Oracle Database@Google Cloud. Para mais informações, consulte o artigo Cargas de trabalho da Oracle no Google Cloud.

Quando escolher e configurar a base de dados para uma implementação multirregional, considere os requisitos da sua aplicação para a consistência dos dados entre regiões e tenha em atenção as soluções de compromisso ao nível do desempenho e dos custos.

  • Se a aplicação exigir uma forte consistência (todos os utilizadores têm de ler os mesmos dados em todos os momentos), os dados têm de ser replicados de forma síncrona em todas as regiões na arquitetura. No entanto, a replicação síncrona pode gerar um custo mais elevado e um desempenho inferior, uma vez que todos os dados escritos têm de ser replicados em tempo real nas regiões antes de estarem disponíveis para operações de leitura.
  • Se a sua aplicação puder tolerar a consistência eventual, pode replicar os dados de forma assíncrona. Isto pode ajudar a melhorar o desempenho porque os dados não precisam de ser replicados de forma síncrona em todas as regiões. No entanto, os utilizadores em diferentes regiões podem ler dados diferentes porque os dados podem não ter sido totalmente replicados no momento do pedido.

Design de rede

Escolha um design de rede que cumpra os seus requisitos empresariais e técnicos. Pode usar uma única rede VPC ou várias redes VPC. Para mais informações, consulte a seguinte documentação:

Segurança, privacidade e conformidade

Esta secção descreve os fatores que deve considerar quando usa esta arquitetura de referência para conceber e criar uma topologia multirregional no Google Cloud que cumpre os requisitos de segurança, privacidade e conformidade das suas cargas de trabalho.Google Cloud

Proteção contra ameaças externas

Para proteger a sua aplicação contra ameaças como ataques de negação de serviço distribuída (DDoS) e scripting entre sites (XSS), pode usar as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que devem ser avaliadas e ações a tomar quando as condições são cumpridas. Por exemplo, uma regra pode especificar que, se o endereço IP de origem do tráfego de entrada corresponder a um endereço IP específico ou a um intervalo CIDR, o tráfego tem de ser recusado. Também pode aplicar regras de firewall de app Web (WAF) pré-configuradas. Para mais informações, consulte a Vista geral da política de segurança.

Acesso externo para VMs

Na arquitetura de referência descrita neste documento, as VMs do Compute Engine não precisam de acesso de entrada a partir da Internet. Não atribua endereços IP externos às VMs. Google Cloud Os recursos que têm apenas um endereço IP interno e privado podem continuar a aceder a determinadas APIs e serviços Google através do Private Service Connect ou do acesso privado à Google. Para mais informações, consulte Opções de acesso privado para serviços.

Para ativar ligações de saída seguras a partir de Google Cloud recursos que têm apenas endereços IP privados, como as VMs do Compute Engine nesta arquitetura de referência, pode usar o proxy Web seguro ou o Cloud NAT.

Privilégios da conta de serviço

Para as VMs do Compute Engine na arquitetura, em vez de usar as contas de serviço predefinidas, recomendamos que crie contas de serviço dedicadas e especifique os recursos aos quais a conta de serviço pode aceder. A conta de serviço predefinida tem uma vasta gama de autorizações, incluindo algumas que podem não ser necessárias. Pode personalizar contas de serviço dedicadas para terem apenas as autorizações essenciais. Para mais informações, consulte o artigo Limite os privilégios da conta de serviço.

Segurança SSH

Para melhorar a segurança das ligações SSH às VMs do Compute Engine na sua arquitetura, implemente o Identity-Aware Proxy (IAP) e a API Cloud OS Login. O IAP permite-lhe controlar o acesso à rede com base na identidade do utilizador e nas políticas de gestão de identidade e de acesso (IAM). A API Cloud OS Login permite-lhe controlar o acesso SSH do Linux com base na identidade do utilizador e nas políticas de IAM. Para mais informações sobre a gestão do acesso à rede, consulte as Práticas recomendadas para controlar o acesso ao início de sessão SSH.

Encriptação de disco

Por predefinição, os dados armazenados em volumes de discos persistentes são encriptados através da Google-owned and Google-managed encryption keys. Como camada adicional de proteção, pode optar por encriptar os dados de conversão usando chaves que detém e gere no Cloud Key Management Service (Cloud KMS). Google-owned and managed key Para mais informações, consulte Acerca da encriptação de disco para volumes do Hyperdisk e Encriptar dados com chaves de encriptação geridas pelo cliente.

Segurança de redes

Para controlar o tráfego de rede entre os recursos na arquitetura, tem de configurar as políticas da firewall de nova geração (NGFW) do Google Cloud adequadas.

Considerações sobre a residência dos dados

Pode usar balanceadores de carga regionais para criar uma arquitetura multirregional que ajude a cumprir os requisitos de residência dos dados. Por exemplo, um país na Europa pode exigir que todos os dados do utilizador sejam armazenados e acedidos em centros de dados localizados fisicamente na Europa. Para cumprir este requisito, pode usar a arquitetura baseada no equilibrador de carga regional. Nessa arquitetura, a aplicação é executada em Google Cloud regiões na Europa e usa o Cloud DNS com uma política de encaminhamento com geolimites para encaminhar o tráfego através de equilibradores de carga regionais. Para cumprir os requisitos de residência de dados para o nível da base de dados, use uma arquitetura fragmentada em vez da replicação entre regiões. Com esta abordagem, os dados em cada região estão isolados, mas não pode implementar a elevada disponibilidade e a comutação por falha entre regiões para a base de dados.

Mais considerações de segurança

Quando criar a arquitetura para a sua carga de trabalho, considere as práticas recomendadas e as recomendações de segurança ao nível da plataforma fornecidas no projeto de base empresarial e na Google Cloud estrutura bem arquitetada: segurança, privacidade e conformidade.

Fiabilidade

Esta secção descreve os fatores de design que deve considerar quando usa esta arquitetura de referência para criar e operar uma infraestrutura fiável para as suas implementações multirregionais no Google Cloud.

Robustez contra interrupções de infraestruturas

Numa arquitetura de implementação multirregional, se qualquer componente individual na pilha de infraestrutura falhar, a aplicação pode processar pedidos se existir, pelo menos, um componente funcional com capacidade adequada em cada nível. Por exemplo, se uma instância do servidor Web falhar, o equilibrador de carga encaminha os pedidos dos utilizadores para as outras instâncias do servidor Web disponíveis. Se uma VM que aloja uma instância de servidor Web ou de servidor de apps falhar, o MIG recria a VM automaticamente.

Se ocorrer uma indisponibilidade de zona, o balanceador de carga não é afetado, porque é um recurso regional. Uma indisponibilidade de zona pode afetar VMs do Compute Engine individuais. No entanto, a aplicação permanece disponível e reativa porque as VMs estão num MIG regional. Um MIG regional garante que são criadas automaticamente novas VMs para manter o número mínimo configurado de VMs. Depois de a Google resolver a indisponibilidade da zona, tem de verificar se a aplicação é executada conforme esperado em todas as zonas onde está implementada.

Se todas as zonas numa das regiões tiverem uma indisponibilidade ou se ocorrerem indisponibilidades ao nível da região, a aplicação na outra região permanece disponível e reativa. O balanceador de carga externo global direciona o tráfego para a região que não é afetada pela indisponibilidade. Depois de a Google resolver a indisponibilidade da região, tem de validar se a aplicação é executada conforme esperado na região que teve a indisponibilidade.

Se ambas as regiões nesta arquitetura tiverem interrupções, a aplicação fica indisponível. Tem de aguardar que a Google resolva a indisponibilidade e, em seguida, verificar se a aplicação funciona conforme esperado.

Escala automática do MIG

Quando executa a sua aplicação em vários GIGs regionais, a aplicação permanece disponível durante interrupções isoladas de zonas ou interrupções de regiões. A capacidade de dimensionamento automático dos MIGs sem estado permite-lhe manter a disponibilidade e o desempenho da aplicação a níveis previsíveis.

Para controlar o comportamento de escalamento automático dos MIGs sem estado, pode especificar métricas de utilização alvo, como a utilização média da CPU. Também pode configurar o ajuste de escala automático baseado em programação para MIGs sem estado. Não é possível ajustar automaticamente a escala dos MIGs com estado. Para mais informações, consulte o artigo Grupos de escalamento automático de instâncias.

Limite de tamanho do MIG

Quando decidir o tamanho dos seus MIGs, considere os limites predefinidos e máximos no número de VMs que podem ser criadas num MIG. Para mais informações, consulte o artigo Adicione e remova VMs de um MIG.

Autorreparação de VMs

Por vezes, as VMs que alojam a sua aplicação podem estar em execução e disponíveis, mas podem existir problemas com a própria aplicação. A aplicação pode ficar bloqueada, falhar ou não ter memória suficiente. Para verificar se uma aplicação está a responder conforme esperado, pode configurar verificações de funcionamento baseadas em aplicações como parte da política de autocorreção dos seus MIGs. Se a aplicação numa determinada VM não estiver a responder, o GIG faz a autorrecuperação (repara) da VM. Para mais informações sobre a configuração da autocorreção, consulte Acerca da reparação de VMs para alta disponibilidade.

Posicionamento de VMs

Na arquitetura descrita neste documento, a camada de aplicação e a camada Web são executadas em VMs do Compute Engine distribuídas por várias zonas. Esta distribuição garante que a sua aplicação é robusta contra interrupções de zonas.

Para melhorar a robustez da arquitetura, pode criar uma política de posicionamento disperso e aplicá-la ao modelo MIG. Quando o MIG cria VMs, coloca-as em diferentes servidores físicos (denominados anfitriões) em cada zona, para que as VMs sejam robustas contra falhas de anfitriões individuais. Para mais informações, consulte o artigo Crie e aplique políticas de posicionamento disperso a VMs.

Planeamento de capacidade de VMs

Para garantir que a capacidade das VMs do Compute Engine está disponível quando as VMs precisam de ser aprovisionadas, pode criar reservas. Uma reserva oferece capacidade garantida numa zona específica para um número especificado de VMs de um tipo de máquina à sua escolha. Uma reserva pode ser específica de um projeto ou partilhada em vários projetos. Para mais informações sobre reservas, consulte o artigo Escolha um tipo de reserva.

Armazenamento com estado

Uma prática recomendada no design de aplicações é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, pode configurar os discos persistentes para serem com estado, de modo a garantir que os dados são preservados quando as VMs são reparadas ou recriadas. No entanto, recomendamos que mantenha os discos de arranque sem estado para que os possa atualizar para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte o artigo Configurar discos persistentes com estado em MIGs.

Durabilidade dos dados

Pode usar o Backup and DR para criar, armazenar e gerir cópias de segurança das VMs do Compute Engine. A cópia de segurança e a RD armazenam dados de cópia de segurança no formato original legível pela aplicação. Quando necessário, pode restaurar as suas cargas de trabalho para produção usando diretamente dados do armazenamento de cópias de segurança a longo prazo e evitar a necessidade de preparar ou mover dados.

O Compute Engine oferece as seguintes opções para ajudar a garantir a durabilidade dos dados armazenados em volumes de discos persistentes:

Disponibilidade da base de dados

Para implementar a comutação por falha entre zonas para uma base de dados implementada numa VM do Compute Engine, precisa de um mecanismo para identificar falhas da base de dados principal e um processo para comutar por falha para a base de dados em espera. As especificidades do mecanismo de comutação por falha dependem da base de dados que usa. Pode configurar uma instância de observador para detetar falhas da base de dados principal e orquestrar a comutação por falha. Tem de configurar as regras de alternativa adequadamente para evitar uma situação de cérebro dividido e impedir a alternativa desnecessária. Para ver exemplos de arquiteturas que pode usar para implementar a comutação por falha para bases de dados PostgreSQL, consulte o artigo Arquiteturas para alta disponibilidade de clusters PostgreSQL no Compute Engine.

Mais considerações de fiabilidade

Quando criar a arquitetura de nuvem para a sua carga de trabalho, reveja as práticas recomendadas e as recomendações relacionadas com a fiabilidade que são fornecidas na seguinte documentação:

Otimização de custos

Esta secção fornece orientações para otimizar o custo de configuração e funcionamento de uma topologia Google Cloud multirregional que cria através desta arquitetura de referência.

Tipos de máquinas de VMs

Para ajudar a otimizar a utilização de recursos das suas instâncias de VM, o Compute Engine oferece recomendações de tipo de máquina. Use as recomendações para escolher tipos de máquinas que correspondam aos requisitos de computação da sua carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, pode personalizar o tipo de máquina de acordo com as suas necessidades e poupar dinheiro usando tipos de máquinas personalizados.

Modelo de aprovisionamento de VMs

Se a sua aplicação for tolerante a falhas, as VMs do Spot podem ajudar a reduzir os custos do Compute Engine para as VMs nas camadas de aplicação e Web. O custo das VMs do Spot é significativamente inferior ao das VMs normais. No entanto, o Compute Engine pode parar ou eliminar preventivamente VMs do Spot para reaver capacidade.

As VMs do Spot são adequadas para tarefas de lotes que podem tolerar a preempção e não têm requisitos de alta disponibilidade. As VMs do Spot oferecem os mesmos tipos de máquinas, opções e desempenho que as VMs normais. No entanto, quando a capacidade de recursos numa zona é limitada, os GIGs podem não conseguir ser expandidos (ou seja, criar VMs) automaticamente para o tamanho alvo especificado até que a capacidade necessária fique novamente disponível.

Utilização de recursos da VM

A capacidade de escala automática dos GIGs sem estado permite que a sua aplicação lide facilmente com aumentos no tráfego e ajuda a reduzir os custos quando a necessidade de recursos é baixa. Não é possível ajustar automaticamente a escala dos MIGs com estado.

Licenciamento de terceiros

Quando migra cargas de trabalho de terceiros para o Google Cloud, pode reduzir os custos usando as suas próprias licenças (BYOL). Por exemplo, para implementar VMs com o Microsoft Windows Server, em vez de usar uma imagem premium que incorre em custos adicionais para a licença de terceiros, pode criar e usar uma imagem BYOL do Windows personalizada. Depois, paga apenas pela infraestrutura de VM que usa no Google Cloud. Esta estratégia ajuda a continuar a obter valor dos seus investimentos existentes em licenças de terceiros. Se decidir usar a abordagem BYOL, as seguintes recomendações podem ajudar a reduzir o custo:

  • Aprovisione o número necessário de núcleos da CPU de computação independentemente da memória através de tipos de máquinas personalizados. Ao fazê-lo, limita o custo de licenciamento de terceiros ao número de núcleos do CPU de que precisa.
  • Reduza o número de vCPUs por núcleo de 2 para 1 desativando o multithreading simultâneo (SMT).

Se implementar uma base de dados de terceiros, como o Microsoft SQL Server, em VMs do Compute Engine, tem de considerar os custos de licença do software de terceiros. Quando usa um serviço de base de dados gerido, como o Cloud SQL, os custos da licença da base de dados estão incluídos nos encargos do serviço.

Mais considerações sobre o custo

Quando criar a arquitetura para a sua carga de trabalho, considere também as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Well-Architected Framework: otimização de custos.

Eficiência operacional

Esta secção descreve os fatores que deve considerar quando usa esta arquitetura de referência para conceber e criar uma topologia multirregional Google Cloud que pode operar de forma eficiente.

Atualizações da configuração de VMs

Para atualizar a configuração das VMs num GIG (como o tipo de máquina ou a imagem do disco de arranque), crie um novo modelo de instância com a configuração necessária e, em seguida, aplique o novo modelo ao GIG. O MIG atualiza as VMs através do método de atualização que escolher: automático ou seletivo. Escolha um método adequado com base nos seus requisitos de disponibilidade e eficiência operacional. Para mais informações sobre estes métodos de atualização do MIG, consulte o artigo Aplique novas configurações de VMs num MIG.

Imagens de VMs

Para as suas VMs, em vez de usar imagens públicas fornecidas pela Google, recomendamos que crie e use imagens de SO personalizadas que contenham as configurações e o software que as suas aplicações requerem. Pode agrupar as suas imagens personalizadas numa família de imagens personalizadas. Uma família de imagens aponta sempre para a imagem mais recente nessa família, para que os seus modelos de instâncias e scripts possam usar essa imagem sem ter de atualizar as referências a uma versão de imagem específica. Tem de atualizar regularmente as suas imagens personalizadas para incluir as atualizações e os patches de segurança fornecidos pelo fornecedor do SO.

Modelos de instância determinísticos

Se os modelos de instância que usa para os seus MIGs incluírem scripts de arranque para instalar software de terceiros, certifique-se de que os scripts especificam explicitamente parâmetros de instalação de software, como a versão do software. Caso contrário, quando o MIG cria as VMs, o software instalado nas VMs pode não ser consistente. Por exemplo, se o modelo de instância incluir um script de arranque para instalar o Apache HTTP Server 2.0 (o pacote apache2), certifique-se de que o script especifica a versão exata do apache2 que deve ser instalada, como a versão 2.4.53. Para mais informações, consulte o artigo Modelos de instâncias determinísticos.

Mais considerações operacionais

Quando cria a arquitetura para a sua carga de trabalho, considere as práticas recomendadas gerais e as recomendações para a eficiência operacional descritas no Google Cloud Well-Architected Framework: excelência operacional.

Otimização do desempenho

Esta secção descreve os fatores que deve considerar quando usa esta arquitetura de referência para conceber e criar uma topologia multirregional que cumpra os requisitos de desempenho das suas cargas de trabalho.Google Cloud

Desempenho de computação

O Compute Engine oferece uma ampla gama de tipos de máquinas predefinidos e personalizáveis para as cargas de trabalho que executa em VMs. Escolha um tipo de máquina adequado com base nos seus requisitos de desempenho. Para mais informações, consulte o recurso de famílias de máquinas e o guia de comparação.

Vários threads da VM

Cada CPU virtual (vCPU) que atribui a uma VM do Compute Engine é implementada como um único multithread de hardware. Por predefinição, duas vCPUs partilham um núcleo da CPU físico. Para aplicações que envolvem operações altamente paralelas ou que realizam cálculos de vírgula flutuante (como a análise de sequências genéticas e a modelagem de risco financeiro), pode melhorar o desempenho reduzindo o número de threads que são executados em cada núcleo da CPU física. Para mais informações, consulte o artigo Defina o número de threads por núcleo.

A multithreading de VMs pode ter implicações de licenciamento para algum software de terceiros, como bases de dados. Para mais informações, leia a documentação de licenciamento do software de terceiros.

Níveis de serviço de rede

Os níveis de serviço de rede permitem otimizar o custo e o desempenho da rede das suas cargas de trabalho. Pode escolher o nível Premium ou o nível Standard. O nível Premium fornece tráfego na infraestrutura global da Google para alcançar uma perda de pacotes mínima e uma latência baixa. O nível padrão fornece tráfego através de intercâmbio de tráfego, fornecedores de serviços de Internet (ISP) ou redes de trânsito num ponto de presença (PoP) periférico mais próximo da região onde a sua Google Cloud carga de trabalho é executada. Para otimizar o desempenho, recomendamos que use o nível Premium. Para otimizar os custos, recomendamos que use o nível padrão.

Desempenho da rede

Para cargas de trabalho que precisam de baixa latência de rede entre VMs nas camadas da aplicação e Web, pode criar uma política de posicionamento compacta e aplicá-la ao modelo de MIG usado para essas camadas. Quando o MIG cria VMs, coloca-as em servidores físicos próximos uns dos outros. Embora uma política de posicionamento compacta ajude a melhorar o desempenho da rede entre VMs, uma política de posicionamento dispersa pode ajudar a melhorar a disponibilidade das VMs, conforme descrito anteriormente. Para alcançar um equilíbrio ideal entre o desempenho da rede e a disponibilidade, quando cria uma política de posicionamento compacta, pode especificar a distância entre as VMs. Para mais informações, consulte a vista geral das políticas de posicionamento.

O Compute Engine tem um limite por VM para a largura de banda da rede de saída. Este limite depende do tipo de máquina da VM e se o tráfego é encaminhado através da mesma rede VPC que a VM de origem. Para VMs com determinados tipos de máquinas, para melhorar o desempenho da rede, pode obter uma largura de banda de saída máxima mais elevada ativando a rede de nível 1.

A colocar em cache

Se a sua aplicação publicar recursos de Websites estáticos e a sua arquitetura incluir um Application Load Balancer externo global, pode usar o Cloud CDN para colocar em cache conteúdo estático acedido regularmente mais perto dos seus utilizadores. A RFC pode ajudar a melhorar o desempenho para os seus utilizadores, reduzir a utilização de recursos de infraestrutura no back-end e reduzir os custos de entrega de rede. Para mais informações, consulte o artigo Desempenho Web mais rápido e proteção Web melhorada para o equilíbrio de carga.

Mais considerações sobre o desempenho

Quando criar a arquitetura da sua carga de trabalho, considere as práticas recomendadas gerais e as recomendações fornecidas no Google Cloud Well-Architected Framework: otimização do desempenho.

O que se segue?

Colaboradores

Autores:

Outros colaboradores: