Implantação multirregional no Compute Engine

Neste documento, apresentamos uma arquitetura de referência para um aplicativo de várias camadas executado em VMs do Compute Engine em várias regiões no Google Cloud. É possível usar essa arquitetura de referência para re-hospedar (migração lift-and-shift) de aplicativos locais para a nuvem de maneira eficiente com alterações mínimas nos aplicativos. O documento também descreve os fatores de design que você precisa considerar ao criar uma arquitetura multirregional para seus aplicativos na nuvem. Os arquitetos de nuvem são o público-alvo deste documento.

Arquitetura

O diagrama a seguir mostra uma arquitetura para um aplicativo que é executado no modo ativo-ativo em pilhas isoladas implantadas em duas Google Cloud regiões. Em cada região, o aplicativo é executado em três zonas. A arquitetura está alinhada ao Google Cloud arquétipo de implantação multirregional. Isso garante que sua topologia do Google Cloud seja robusta em relação a interrupções de zona e região e que forneça baixa latência para usuários de aplicativos.

Arquitetura multirregional usando um balanceador de carga global

A arquitetura é baseada no modelo de nuvem infraestrutura como serviço (IaaS). Você provisiona os recursos de infraestrutura necessários (computação, rede e armazenamento) no Google Cloude mantém total controle e responsabilidade pelo sistema operacional, middleware e camadas superiores da pilha de aplicativos. Para saber mais sobre IaaS e outros modelos de nuvem, consulte PaaS x IaaS x SaaS x CaaS: qual é a diferença entre eles?

O diagrama anterior inclui os seguintes componentes:

Componente Purpose
Balanceador de carga externo global

O balanceador de carga externo global recebe e distribui solicitações de usuários para o aplicativo. O balanceador de carga externo global anuncia um único endereço IP anycast, mas é implementado como um grande número de proxies no Google Front Ends (GFEs). As solicitações são direcionadas para o GFE mais próximo do cliente.
Grupos gerenciados de instâncias (MIGs) regionais para o nível da Web

A camada da Web do aplicativo é implantada nas VMs do Compute Engine que fazem parte de MIGs regionais. Esses 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 dessas VMs hospeda uma instância independente do nível da Web do aplicativo.
Balanceadores de carga internos regionais

O balanceador de carga interno em cada região distribui o tráfego das VMs de nível da Web para as VMs de nível de aplicativo nessa região.
MIGs regionais para o nível do aplicativo

O nível do aplicativo é implantado nas VMs do Compute Engine que fazem parte de MIGs 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 VM hospeda uma instância independente do nível do aplicativo.
Banco de dados de terceiros implantado nas VMs do Compute Engine

A arquitetura neste documento mostra um banco de dados de terceiros (como o PostgreSQL) implantado em VMs do Compute Engine nas duas regiões. É possível configurar a replicação entre regiões para os bancos de dados e configurar o banco de dados em cada região para fazer o failover para o banco de dados na outra região. Os recursos de replicação e failover dependem do banco de dados usado.

A instalação e o gerenciamento de um banco de dados de terceiros envolve mais esforço e custos operacionais para aplicar atualizações, monitorar e garantir a disponibilidade. Evite a sobrecarga de instalar e gerenciar um banco de dados de terceiros e aproveitar os recursos integrados de alta disponibilidade (HA) usando um banco de dados totalmente gerenciado, como um banco de dados multirregional. instância do Spanner.
Rede de nuvem privada virtual e sub-redes

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

Dependendo dos seus requisitos, é possível criar uma arquitetura que use várias redes VPC e sub-redes. Para mais informações, consulte Como decidir se você quer criar várias redes VPC.
Buckets birregionais do Cloud Storage

Os backups de banco de dados são armazenados em buckets birregionais do Cloud Storage. Como alternativa, é possível usar o Serviço de backup e DR para criar, armazenar e gerenciar os backups do banco de dados.

Produtos usados

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

  • Compute Engine: um serviço de computação seguro e personalizável que permite criar e executar VMs na infraestrutura do Google.
  • Cloud Load Balancing: um portfólio de balanceadores de carga globais, regionais, escalonáveis, globais e de alto desempenho.
  • Cloud Storage: um armazenamento de objetos de baixo custo e sem limite para diversos tipos de dados. Os dados podem ser acessados de dentro e fora Google Cloude são replicados entre locais para redundância.
  • Nuvem privada virtual: 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.

Casos de uso

Nesta seção, descrevemos os casos de uso em que uma implantação multirregional no Compute Engine é uma escolha apropriada.

Migração eficiente de aplicativos no local

É possível usar essa arquitetura de referência para criar uma topologia do Google Cloud para re-hospedar (migração lift-and-shift) aplicativos locais na nuvem com alterações mínimas nos aplicativos. Todos os níveis do aplicativo nesta arquitetura de referência são hospedados em VMs do Compute Engine. Essa abordagem permite que você migre aplicativos no local de maneira eficiente para a nuvem e aproveite os benefícios de custo, confiabilidade, desempenho e simplicidade operacional que o Google Cloud oferece.

Alta disponibilidade para usuários dispersos geograficamente

Recomendamos uma implantação multirregional para aplicativos essenciais para os negócios em que a alta disponibilidade e a robustez para enfrentar interrupções na região são essenciais. Se uma região ficar indisponível por qualquer motivo (mesmo uma interrupção em grande escala causada por um desastre natural), os usuários do aplicativo não terão tempo de inatividade. O tráfego é encaminhado para o aplicativo nas outras regiões disponíveis. Se os dados forem replicados de maneira síncrona, o objetivo de tempo de recuperação (RTO) será próximo de zero.

Baixa latência para usuários de aplicativos

Se os usuários estiverem em uma área geográfica específica, como um continente, use uma implantação multirregional para alcançar um equilíbrio ideal entre disponibilidade e desempenho. Quando uma das regiões tem uma interrupção, o balanceador de carga global envia as solicitações originadas nessa região para outra. Os usuários não percebem um impacto significativo no desempenho porque as regiões estão dentro de uma área geográfica.

Alternativa de design

A arquitetura anterior usa um balanceador de carga global, que oferece suporte a determinados recursos para melhorar a confiabilidade das suas implantações, como armazenamento em cache de borda usando o Cloud CDN. Nesta seção, apresentamos uma arquitetura alternativa que usa balanceadores de carga regionais e o Cloud DNS. Essa arquitetura alternativa é compatível com os seguintes recursos extras:

  • Encerramento do Transport Layer Security (TLS) em regiões especificadas.
  • Capacidade de exibir conteúdo da região especificada. No entanto, essa região pode não ser a de melhor desempenho em um determinado momento.
  • Um intervalo mais amplo de protocolos de conexão se você usar um balanceador de carga de rede de passagem.

Para mais informações sobre as diferenças entre balanceadores de carga regionais e globais, consulte Balanceamento de carga global ou regional e Modos de operação.

Arquitetura multirregional usando balanceadores de carga regionais e DNS.

A arquitetura alternativa no diagrama anterior é robusta contra interrupções de zona e região. Uma zona pública do Cloud DNS encaminha as solicitações do usuário para a região apropriada. Esses balanceadores recebem solicitações de usuários e as distribuem entre as instâncias do nível da Web do aplicativo em cada região. Os outros componentes dessa arquitetura são idênticos aos componentes da arquitetura baseada no balanceador de carga global.

Considerações sobre o design

Nesta seção, você encontra orientações sobre como usar essa arquitetura de referência para desenvolver uma arquitetura que atenda aos requisitos específicos de projeto, segurança, confiabilidade, eficiência operacional, custo e desempenho do sistema.

Ao criar uma arquitetura para sua carga de trabalho, considere as práticas recomendadas e as recomendações do Google Cloud Well-Architected Framework.

design do sistema

Nesta seção, fornecemos orientações para ajudar você a escolher Google Cloud regiões para sua implantação multirregional e selecionar os serviços Google Cloud adequados.

Seleção da região

Ao escolher as Google Cloud regiões em que seus aplicativos precisam ser implantados, considere os seguintes fatores e requisitos:

  • Disponibilidade dos serviços do Google Cloud em cada região. Para mais informações, consulte Produtos disponíveis por local.
  • Disponibilidade de tipos de máquina do Compute Engine em cada região. Para mais informações, consulte Regiões e zonas.
  • Requisitos de latência do usuário final.
  • Custo dos recursos Google Cloud .
  • Custos da transferência de dados entre regiões.
  • Requisitos regulatórios.

Alguns desses fatores e requisitos podem envolver compensações. Por exemplo, a região mais econômica pode não ter a menor pegada de carbono. Para mais informações, consulte 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 do aplicativo. Dependendo dos requisitos do aplicativo, é possível escolher outros serviços de computação do Google Cloud :

  • Contêineres: é possível executar aplicativos conteinerizados nos clusters do Google Kubernetes Engine (GKE). O GKE é um mecanismo de orquestração de contêineres que automatiza a implantação, o escalonamento e o gerenciamento de aplicativos em contêineres.
  • Sem servidor: se você preferir concentrar as iniciativas de TI nos dados e aplicativos em vez de configurar e operar recursos de infraestrutura, use serviços sem servidor, como o Cloud Run.

A decisão de usar VMs, contêineres ou serviços sem servidor envolve uma troca entre flexibilidade de configuração e esforço de gerenciamento. As VMs e os contêineres oferecem mais flexibilidade de configuração, mas você é responsável por gerenciar os recursos. Em uma arquitetura sem servidor, as cargas de trabalho são implantadas em uma plataforma pré-configurada que requer esforço mínimo de gerenciamento. Para mais informações sobre como escolher serviços de computação adequados para suas cargas de trabalho no Google Cloud, consulte Hospedagem de aplicativos no Google Cloud.

Serviços de armazenamento

As arquiteturas mostradas neste documento usam volumes regionais do Persistent Disk em todos os níveis. Os discos permanentes oferecem replicação síncrona de dados em duas zonas dentro de uma região.

O Google Cloud Hyperdisk oferece melhor desempenho, flexibilidade e eficiência do que o Persistent Disk. Com o Hyperdisk Balanced, é possível provisionar IOPS e capacidade de processamento separada e dinamicamente, o que permite ajustar o volume a uma grande variedade de cargas de trabalho.

Para ter um armazenamento de baixo custo replicado em vários locais, use buckets regionais, birregionais ou multirregionais do Cloud Storage.

  • Os dados em buckets regionais são replicados de forma síncrona nas zonas da região.
  • Os dados em buckets birregionais ou multirregionais são armazenados de maneira redundante em pelo menos dois locais geográficos diferentes. Os metadados são gravados de modo síncrono em todas as regiões e replicados de maneira assíncrona. Nos buckets birregionais, use a replicação turbo, que garante que os objetos sejam replicados em pares de regiões, com um objetivo do ponto de recuperação (RPO, na sigla em inglês) de 15 minutos. Para mais informações, consulte Disponibilidade e durabilidade dos dados.

Para armazenar dados compartilhados entre várias VMs em uma região, como em todas as VMs no nível da Web ou do aplicativo, use uma instância regional do Filestore. Os dados armazenados em uma instância regional do Filestore são replicados de maneira síncrona em três zonas na região. Essa replicação garante alta disponibilidade e robustez contra interrupções dos serviços da zona. É possível armazenar arquivos de configuração compartilhados, ferramentas e utilitários comuns e registros centralizados na instância do Filestore e ativá-la em várias VMs. Para ter robustez contra interrupções regionais, é possível replicar uma instância do Filestore em outra região. Para mais informações, consulte Replicação de instâncias.

Se o banco de dados for o Microsoft SQL Server, recomendamos o uso do Cloud SQL para SQL Server. Nos cenários em que o Cloud SQL não for compatível com os requisitos de configuração ou se você precisar de acesso ao sistema operacional, implante uma instância de cluster de failover (FCI) do Microsoft SQL Server. Nesse cenário, é possível usar o Google Cloud NetApp Volumes para fornecer armazenamento SMB de disponibilidade contínua (CA) para o banco de dados.

Ao projetar o armazenamento para suas cargas de trabalho, considere as características funcionais, os requisitos de resiliência, as expectativas de desempenho e as metas de custo. Para mais informações, consulte Criar uma estratégia de armazenamento ideal para sua carga de trabalho na nuvem.

Serviços de banco de dados

A arquitetura de referência neste documento usa um banco de dados de terceiros implantado em VMs do Compute Engine. A instalação e o gerenciamento de um banco de dados de terceiros envolve esforço e custo para operações como aplicação de atualizações, monitoramento e garantia de disponibilidade, realização de backups e recuperação de falhas.

Para evitar o esforço e o custo de instalação e gerenciamento de um banco de dados de terceiros, use um serviço de banco de dados totalmente gerenciado, como Cloud SQL, AlloyDB para PostgreSQL, Cloud Bigtable, Cloud Spanner ou Firestore. Esses Google Cloud serviços de banco de dados oferecem contratos de nível de serviço (SLAs) de tempo de atividade e incluem recursos padrão para escalonabilidade e observabilidade.

Se a carga de trabalho precisar de um banco de dados Oracle, implante o banco de dados em uma VM do Compute Engine ou use o Oracle Database@Google Cloud. Para mais informações, consulte Cargas de trabalho do Oracle no Google Cloud.

Ao escolher e configurar o banco de dados para uma implantação multirregional, considere os requisitos do aplicativo quanto à consistência de dados entre regiões e esteja ciente das compensações de desempenho e custo.

  • Se o aplicativo exigir consistência forte, ou seja, todos os usuários precisam ler os mesmos dados o tempo todo, eles precisam ser replicados de maneira síncrona em todas as regiões da arquitetura. No entanto, a replicação síncrona pode levar a custos mais altos e desempenho reduzido, porque todos os dados gravados precisam ser replicados em tempo real nas regiões antes de ficarem disponíveis para operações de leitura.
  • Se o aplicativo puder tolerar a consistência posterior, será possível replicar dados de maneira assíncrona. Isso ajuda a melhorar o desempenho, já que os dados não precisam ser replicados de maneira síncrona entre as regiões. No entanto, usuários em regiões distintas podem ler dados diferentes, porque eles podem não ter sido totalmente replicados no momento da solicitação.

Design de rede

Escolha um design de rede que atenda aos seus requisitos comerciais e técnicos. É possível usar uma ou várias redes VPC. Para mais informações, consulte a seguinte documentação:

segurança, privacidade e conformidade

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia multirregional noGoogle Cloud que atenda aos requisitos de segurança, privacidade e conformidade das suas cargas de trabalho.

Proteção contra ameaças externas

Para proteger o aplicativo contra ameaças como ataques distribuídos de negação de serviço (DDoS) e scripting em vários locais (XSS), use as políticas de segurança do Google Cloud Armor. Cada política é um conjunto de regras que especifica determinadas condições que precisam ser avaliadas e ações a serem tomadas quando as condições são atendidas. 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 ou intervalo CIDR específico, o tráfego precisará ser negado. Também é possível aplicar regras pré-configuradas de firewall de aplicativos da Web (WAF). Para mais informações, consulte Visão 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 da Internet. Não atribua endereços IP externos às VMs.Os recursos do Google Cloud que têm apenas um endereço IP interno privado ainda podem acessar determinadas APIs e serviços do Google usando o Private Service Connect ou o Acesso privado do Google. Para mais informações, consulte Opções de acesso privado para serviços.

Para ativar conexões de saída seguras de recursos do Google Cloud que têm apenas endereços IP privados, como as VMs do Compute Engine nessa arquitetura de referência, use o Secure Web Proxy 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 padrão, recomendamos criar contas de serviço dedicadas e especificar os recursos a que elas podem acessar. A conta de serviço padrão tem uma ampla variedade de permissões, incluindo algumas que podem não ser necessárias. É possível personalizar contas de serviço dedicadas para ter apenas as permissões essenciais. Para mais informações, consulte Limitar os privilégios da conta de serviço.

Segurança SSH

Para aumentar a segurança das conexões SSH com as VMs do Compute Engine na sua arquitetura, implemente o Identity-Aware Proxy (IAP) e a API Cloud OS Login. Com o IAP, é possível controlar o acesso à rede com base na identidade do usuário e nas políticas do Identity and Access Management (IAM). A API Cloud OS Login permite controlar o acesso SSH do Linux com base na identidade do usuário e nas políticas do IAM. Para mais informações sobre como gerenciar o acesso à rede, consulte Práticas recomendadas para controlar o acesso de login SSH.

Criptografia de disco

Por padrão, os dados armazenados em volumes de Persistent Disk são criptografados usando Google-owned and Google-managed encryption keys. Como uma camada extra de proteção, é possível criptografar o Google-owned and managed key usando chaves que você tem e gerencia no Cloud Key Management Service (Cloud KMS). Para mais informações, consulte Sobre a criptografia de disco para volumes do Hyperdisk e Criptografar dados com chaves de criptografia gerenciadas pelo cliente.

Segurança de rede

Para controlar o tráfego de rede entre os recursos na arquitetura, é preciso configurar as políticas do Cloud Next Generation Firewall (NGFW) adequadas.

Considerações sobre a residência de dados

É possível usar balanceadores de carga regionais para criar uma arquitetura multirregional que ajuda a atender aos requisitos de residência de dados. Por exemplo, um país na Europa pode exigir que todos os dados do usuário sejam armazenados e acessados em data centers localizados fisicamente dentro da Europa. Para atender a esse requisito, use a arquitetura baseada no balanceador de carga regional. Nessa arquitetura, o aplicativo é executado nas Google Cloud regiões da Europa e você usa o Cloud DNS com uma política de roteamento por fronteira geográfica virtual para encaminhar o tráfego por meio de balanceadores de carga regionais. Para atender aos requisitos de residência de dados para a camada de banco de dados, use uma arquitetura fragmentada em vez de replicação entre regiões. Com essa abordagem, os dados em cada região ficam isolados, mas não é possível implementar alta disponibilidade entre regiões e failover para o banco de dados.

Mais considerações sobre a segurança

Ao criar a arquitetura para a carga de trabalho, considere as práticas recomendadas de segurança no nível da plataforma e as recomendações fornecidas no Blueprint de bases empresariais e no Framework doGoogle Cloud Well-Architected: segurança, privacidade e conformidade.

Confiabilidade

Nesta seção, descrevemos os fatores de design que você precisa considerar ao usar essa arquitetura de referência para criar e operar uma infraestrutura confiável para implantações multirregionais no Google Cloud.

Robustez contra interrupções de infraestrutura

Em uma arquitetura de implantação multirregional, se algum componente individual na pilha de infraestrutura falhar, o aplicativo poderá processar solicitações se houver pelo menos um componente em funcionamento com capacidade adequada em cada nível. Por exemplo, se uma instância do servidor da Web falhar, o balanceador de carga encaminhará as solicitações do usuário para as outras instâncias disponíveis do servidor. Se uma VM que hospeda um servidor da Web ou uma instância do servidor de apps falhar, o MIG recriará a VM automaticamente.

Se ocorrer uma interrupção da zona, o balanceador de carga não será afetado, porque é um recurso regional. Uma falha temporária de zona pode afetar VMs individuais do Compute Engine. Mas o aplicativo permanece disponível e responsivo porque as VMs estão em um MIG regional. Um MIG regional garante que novas VMs sejam criadas automaticamente para manter o número mínimo configurado de VMs. Depois que o Google resolver a falha temporária, verifique se o aplicativo é executado conforme o esperado em todas as zonas em que está implantado.

Se todas as zonas em uma das regiões tiverem uma interrupção ou se ocorrer uma interrupção em toda a região, o aplicativo na outra região vai permanecer disponível e responsivo. O balanceador de carga externo global direciona o tráfego para a região que não é afetada pela interrupção. Depois que o Google resolver a falha temporária na região, verifique se o aplicativo é executado conforme o esperado na região em que ela ocorreu.

Se as duas regiões desta arquitetura tiverem interrupções, o aplicativo não estará disponível. Aguarde até que o Google resolva a interrupção e verifique se o aplicativo funciona conforme o esperado.

Escalonamento automático de MIG

Quando você executa seu aplicativo em vários MIGs regionais, ele permanece disponível durante interrupções de zona isoladas ou interrupções de região. A capacidade de escalonamento automático de MIGs sem estado permite manter a disponibilidade e o desempenho do aplicativo em níveis previsíveis.

Para controlar o comportamento de escalonamento automático de seus MIGs sem estado, é possível especificar métricas de utilização de destino, como a utilização média da CPU. Também é possível configurar o escalonamento automático baseado em programação para MIGs sem estado. MIGs com estado não podem ser escalonados automaticamente. Para mais informações, consulte Escalonamento automático de grupos de instâncias.

Limite de tamanho do MIG

Ao decidir o tamanho dos seus MIGs, considere os limites padrão e máximo no número de VMs que podem ser criadas em um MIG. Para mais informações, consulte Adicionar e remover VMs de um MIG.

Recuperação automática de VM

Às vezes, as VMs que hospedam o aplicativo podem estar em execução e disponíveis, mas pode haver problemas com o próprio aplicativo. O aplicativo pode congelar, falhar ou não ter memória suficiente. Para verificar se um aplicativo está respondendo conforme o esperado, configure verificações de integridade baseadas em aplicativo como parte da política de recuperação automática dos seus MIGs. Se o aplicativo em uma VM específica não estiver respondendo, o MIG vai recuperar (reparar) automaticamente a VM. Para mais informações sobre como configurar a recuperação automática, consulte Como reparar VMs para alta disponibilidade.

Posicionamento da VM

Na arquitetura descrita neste documento, a camada do aplicativo e da Web são executadas nas VMs do Compute Engine distribuídas por várias zonas. Essa distribuição garante que o aplicativo seja robusto contra interrupções de zona.

Para melhorar a robustez da arquitetura, crie uma política de posicionamento distribuído e aplique-a ao modelo do MIG. Quando o MIG cria VMs, ele as coloca dentro de cada zona em diferentes servidores físicos (chamados de hosts), de modo que suas VMs sejam resistentes contra falhas de hosts individuais. Para mais informações, consulte Criar e aplicar políticas de posicionamento distribuído às VMs.

Planejamento de capacidade de VM

Para garantir que a capacidade de VMs do Compute Engine esteja disponível quando elas precisarem ser provisionadas, crie reservas. Uma reserva oferece capacidade garantida em uma zona específica para um número específico de VMs de um tipo de máquina escolhido por você. Uma reserva pode ser específica para um projeto ou compartilhada entre vários projetos. Para mais informações sobre reservas, consulte Escolher um tipo de reserva.

Armazenamento com estado

Uma prática recomendada ao projetar aplicativos é evitar a necessidade de discos locais com estado. No entanto, se o requisito existir, é possível configurar os discos permanentes com estado para garantir que os dados sejam preservados quando as VMs forem reparadas ou recriadas. No entanto, recomendamos que você mantenha os discos de inicialização sem estado para atualizá-los para as imagens mais recentes com novas versões e patches de segurança. Para mais informações, consulte Como configurar discos permanentes com estado em MIGs.

Durabilidade dos dados

É possível usar backup e DR para criar, armazenar e gerenciar backups das VMs do Compute Engine. O backup e a DR armazenam os dados de backup no formato original legível pelo aplicativo. Quando necessário, é possível restaurar as cargas de trabalho para produção usando diretamente os dados do armazenamento de backup de longo prazo e evitar a necessidade de preparar ou mover dados.

O Compute Engine oferece as opções a seguir para ajudar a garantir a durabilidade dos dados armazenados nos volumes do Persistent Disk:

Disponibilidade do banco de dados

Para implementar o failover entre zonas para um banco de dados implantado em uma VM do Compute Engine, é necessário ter um mecanismo para identificar falhas do banco de dados primário e um processo para fazer failover no banco de dados em espera. As especificidades do mecanismo de failover dependem do banco de dados que você usa. É possível configurar uma instância do observador para detectar falhas do banco de dados primário e orquestrar o failover. Você precisa configurar as regras de failover corretamente para evitar uma situação de dupla personalidade e evitar o failover desnecessário. Para ver exemplos de arquiteturas que podem ser usadas para implementar o failover para bancos de dados do PostgreSQL, consulte Arquiteturas para alta disponibilidade de clusters do PostgreSQL no Compute Engine.

Mais considerações sobre confiabilidade

Ao criar a arquitetura de nuvem para sua carga de trabalho, analise as práticas recomendadas e as recomendações relacionadas à confiabilidade fornecidas na documentação a seguir:

Otimização de custos

Nesta seção, você encontra orientações para otimizar o custo de configuração e operação de uma topologia multirregional Google Cloud criada usando essa arquitetura de referência.

Tipos de máquina de VM

Para ajudar você a otimizar a utilização de recursos das instâncias de VM, o Compute Engine fornece recomendações de tipo de máquina. Use as recomendações para escolher os tipos de máquina que atendem aos requisitos de computação da carga de trabalho. Para cargas de trabalho com requisitos de recursos previsíveis, é possível personalizar o tipo de máquina de acordo com suas necessidades e economizar dinheiro usando tipos de máquinas personalizados.

Modelo de provisionamento de VM

Se o aplicativo for tolerante a falhas, as VMs spot podem ajudar a reduzir os custos do Compute Engine para as VMs nos níveis do aplicativo e da Web. O custo das VMs spot é significativamente menor do que as VMs regulares. No entanto, o Compute Engine pode interromper ou excluir antecipadamente as VMs spot para recuperar a capacidade.

As VMs spot são adequadas para jobs em lote que toleram preempção e não têm requisitos de alta disponibilidade. As VMs spot oferecem os mesmos tipos de máquina, opções e desempenho que as VMs regulares. No entanto, quando a capacidade de recursos em uma zona é limitada, os MIGs podem não conseguir fazer o escalonamento horizontal (ou seja, criar VMs) automaticamente para o tamanho de destino especificado até que a capacidade necessária fique disponível novamente.

Utilização de recursos da VM

O recurso de escalonamento automático dos MIGs sem estado permite que seu aplicativo processe aumentos no tráfego de maneira eficiente, além de ajudar a reduzir o custo quando a necessidade de recursos for baixa. MIGs com estado não podem ser escalonados automaticamente.

Licenciamento de terceiros

Ao migrar cargas de trabalho de terceiros para o Google Cloud, você pode reduzir os custos trazendo suas próprias licenças (BYOL, na sigla em inglês). Por exemplo, para implantar VMs do Microsoft Windows Server, em vez de usar uma imagem Premium que gera mais custos com a licença de terceiros, é possível criar e usar uma imagem personalizada BYOL do Windows. Você paga apenas pela infraestrutura de VM usada no Google Cloud. Essa estratégia ajuda você a manter o valor dos seus investimentos em licenças de terceiros. Se você decidir usar a abordagem BYOL, as recomendações a seguir poderão ajudar a reduzir o custo:

  • Provisione o número necessário de núcleos de CPU de computação, independentemente da memória, usando tipos de máquina personalizados. Ao fazer isso, você limita o custo do licenciamento de terceiros ao número de núcleos de CPU necessários.
  • Reduza o número de vCPUs por núcleo de 2 para 1 desativando a multissegmentação simultânea (SMT).

Se você implantar um banco de dados de terceiros, como o Microsoft SQL Server, em VMs do Compute Engine, considere os custos da licença do software de terceiros. Quando você usa um serviço de banco de dados gerenciado, como o Cloud SQL, os custos da licença de banco de dados são incluídos nas cobranças do serviço.

Mais considerações sobre custo

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

Eficiência operacional

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia multirregional Google Cloud que possa ser operada de maneira eficiente.

Atualizações de configuração da VM

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

Imagens de VM

Para suas VMs, em vez de usar imagens públicas fornecidas pelo Google, recomendamos que você crie e use imagens de SO personalizadas que contenham as configurações e o software que seus aplicativos exigem. É possível agrupar suas imagens personalizadas em uma família de imagens personalizadas. Uma família de imagens sempre indica a imagem mais recente que ela contém, permitindo que seus modelos e scripts de instâncias usem essa imagem sem precisar atualizar as referências para uma versão específica de imagem. É necessário atualizar regularmente as imagens personalizadas para incluir as atualizações e os patches de segurança fornecidos pelo fornecedor do SO.

Modelos deterministas de instância

Se os modelos de instância que você usa para seus MIGs incluírem scripts de inicialização para instalar software de terceiros, verifique se os scripts especificam explicitamente os parâmetros de instalação de software, como a versão do software. Caso contrário, quando o MIG criar as VMs, o software instalado nelas poderá não ser consistente. Por exemplo, se o modelo de instância incluir um script de inicialização para instalar o Servidor HTTP Apache 2.0 (o pacote apache2), verifique se o script especifica a versão exata do apache2 que precisa ser instalada como a versão 2.4.53. Para mais informações, consulte Modelos deterministas de instâncias.

Mais considerações operacionais

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

Otimização de desempenho

Nesta seção, descrevemos os fatores que você precisa considerar ao usar essa arquitetura de referência para projetar e criar uma topologia multirregional noGoogle Cloud que atenda aos requisitos de desempenho das suas cargas de trabalho.

Desempenho de computação

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

Várias linhas de execução de VM

Cada CPU virtual (vCPU) alocada para uma VM do Compute Engine é implementada como um multithread de hardware único. Por padrão, duas vCPUs compartilham um núcleo físico da CPU. Para aplicativos que envolvem operações altamente paralelas ou que realizam cálculos de ponto flutuante, como análise de sequência genética e modelagem de risco financeiro, é possível melhorar o desempenho reduzindo o número de linhas de execução executadas em cada núcleo de CPU física. Para ver mais informações, consulte Definir número de linhas de execução por núcleo.

O multithreading de VMs pode ter implicações de licenciamento para alguns softwares de terceiros, como bancos de dados. Para saber mais, 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 de rede e o desempenho das suas cargas de trabalho. É possível escolher o nível Premium ou Standard. O nível Premium oferece tráfego no backbone global do Google para minimizar a perda de pacotes e a latência. O nível Standard entrega tráfego usando peering, provedores de serviços de Internet (ISP) ou redes de trânsito em um ponto de presença (PoP) de borda mais próximo da região em que sua Google Cloud carga de trabalho é executada. Para otimizar o desempenho, recomendamos usar o nível Premium. Para otimizar custos, recomendamos o uso do nível Standard.

Desempenho da rede

Para cargas de trabalho que precisam de baixa latência de rede entre VMs nas camadas de aplicativo e da Web, crie uma política de posicionamento compacto e aplique-a ao modelo do MIG usado para essas camadas. Quando o MIG cria VMs, ele as coloca em servidores físicos próximos uns dos outros. Embora uma política de posicionamento compacto ajude a melhorar o desempenho da rede entre VMs, uma política de posicionamento distribuído pode ajudar a melhorar a disponibilidade da VM, conforme descrito anteriormente. Para alcançar um equilíbrio ideal entre o desempenho e a disponibilidade da rede, ao criar uma política de posicionamento compacto, é possível especificar a distância entre as VMs. Para mais informações, consulte Visão geral das políticas de posicionamento.

O Compute Engine tem um limite por VM para a largura de banda de rede de saída. Esse limite depende do tipo de máquina da VM e se o tráfego é roteado pela mesma rede VPC da VM de origem. Para VMs com determinados tipos de máquinas, é possível melhorar o desempenho da rede e aumentar a largura de banda máxima de saída ativando a rede Tier_1.

Armazenamento em cache

Se o aplicativo disponibilizar recursos estáticos de site e a arquitetura incluir um balanceador de carga de aplicativo externo global, use o Cloud CDN para armazenar em cache o conteúdo estático acessado com frequência mais próximo dos seus usuários. O Cloud CDN pode ajudar a melhorar o desempenho para seus usuários, reduzir o uso de recursos de infraestrutura no back-end e reduzir os custos de entrega de rede. Para mais informações, consulte Desempenho da Web mais rápido e proteção aprimorada para balanceamento de carga.

Mais considerações de desempenho

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

A seguir

Colaboradores

Autores:

Outros colaboradores: