Arquitetar suas cargas de trabalho

Last reviewed 2024-07-24 UTC

Este documento ajuda você a projetar cargas de trabalho de modo a minimizar o impacto de uma expansão futura e a migração de cargas de trabalho para outras Google Cloud regiões ou o impacto de uma migração de cargas de trabalho entre regiões. Este documento é útil se você planeja realizar alguma dessas atividades ou se está avaliando a oportunidade de fazer isso no futuro e quer saber como o trabalho será.

Este documento faz parte de uma série:

A orientação desta série também é útil se você não planejou uma migração entre regiões ou uma expansão para várias regiões com antecedência. Nesse caso, talvez seja necessário gastar mais esforço para preparar a infraestrutura, as cargas de trabalho e os dados para a migração entre regiões e a expansão para várias regiões.

Este documento ajuda você a fazer o seguinte:

  1. Preparar a zona de destino
  2. Preparar as cargas de trabalho para uma migração entre regiões
  3. Preparar seus recursos de computação
  4. Preparar seus recursos de armazenamento de dados
  5. Preparar-se para desativar o ambiente de origem

Preparar a zona de destino

Esta seção se concentra nas considerações que você precisa fazer para estender uma zona de destino (também chamada de base da nuvem) ao migrar entre regiões.

A primeira etapa é reavaliar os diferentes aspectos de qualquer zona de destino. Antes de migrar qualquer carga de trabalho, você precisa ter uma zona de destino. Embora você já tenha uma zona de destino para a região que hospeda as cargas de trabalho, ela pode não oferecer suporte à implantação de cargas de trabalho em uma região diferente. Portanto, ela precisa ser estendida para a região de destino. Algumas landing pages já implementadas podem ter um design que pode oferecer suporte a outra região sem retrabalho significativo na landing page (por exemplo, gerenciamento de identidade e acesso ou gerenciamento de recursos). No entanto, outros fatores, como rede ou dados, podem exigir que você planeje a extensão. O processo de reavaliação precisa levar em conta os principais requisitos das cargas de trabalho para que você possa configurar uma base genérica que poderá ser especializada mais tarde durante a migração.

Considerações empresariais

No que diz respeito a aspectos como padrões, regulamentações e certificações do setor e do governo, a migração de cargas de trabalho para outra região pode ter requisitos diferentes. As cargas de trabalho executadas em regiões do Google que estão fisicamente localizadas em países diferentes precisam seguir as leis e regulamentações desse país. Além disso, diferentes padrões do setor podem ter requisitos especiais para cargas de trabalho executadas no exterior (principalmente em termos de segurança). Como as regiões Google Cloud são criadas para executar recursos em um único país, às vezes as cargas de trabalho são migradas de outra região do Google para esse país para obedecer a regulamentações específicas. Ao realizar essas migrações "no país", é importante reavaliar os dados executados no local para verificar se a nova região permite a migração dos dados para Google Cloud.

Gerenciamento de identidade e acesso

Ao planejar uma migração, provavelmente você não precisa planejar muitas mudanças de identidade e acesso para regiões que já estão em Google Cloud. As decisões de identidade em Google Cloud e o acesso aos recursos geralmente são baseadas na natureza dos recursos, e não na região em que eles estão sendo executados. Considere o seguinte:

  • Design de equipes: algumas empresas são estruturadas para ter equipes diferentes para lidar com recursos diferentes. Quando uma carga de trabalho é migrada para outra região devido a uma mudança na estrutura dos recursos, uma equipe diferente pode ser a melhor candidata para ser responsável por determinados recursos. Nesse caso, os acessos precisam ser ajustados de acordo.
  • Convenções de nomenclatura: embora as convenções de nomenclatura não tenham nenhum impacto técnico nas funcionalidades, pode ser necessário considerar alguns recursos definidos com convenções de nomenclatura que se referem à região específica. Um exemplo típico é quando já existem várias regiões replicadas, como máquinas virtuais (VMs) do Compute Engine, que são nomeadas com a região como prefixo, por exemplo, europe-west1-backend-1. Durante o processo de migração, para evitar confusões ou, pior ainda, interromper pipelines que dependem de uma convenção de nomenclatura específica, é importante mudar os nomes para refletir a nova região.

Conectividade e rede

O design da rede afeta vários aspectos da execução da migração. Portanto, é importante abordar esse design antes de planejar como mover as cargas de trabalho.

A conectividade local com Google Cloud é um dos fatores que você precisa reavaliar na migração, já que ela pode ser projetada para ser específica da região. Um exemplo desse fator é o Cloud Interconnect, que é conectado a Google Cloud por um anexo da VLAN a regiões específicas. Você precisa mudar a região em que o anexo da VLAN está conectado antes de dispensar essa região para evitar o tráfego entre regiões. Outro fator a ser considerado é que, se você estiver usando a Interconexão por parceiro, a migração da região pode ajudar a selecionar um local físico diferente para conectar os anexos da VLAN a Google Cloud. Essa consideração também é relevante se você usa uma Cloud VPN e decide mudar os endereços de sub-rede na migração: é necessário reconfigurar os roteadores para refletir a nova rede.

Embora as nuvens privadas virtuais (VPCs) sejam recursos globais, as sub-redes individuais são sempre vinculadas a uma região, o que significa que você não pode usar a mesma sub-rede para as cargas de trabalho após a migração. Google Cloud Como as sub-redes não podem se sobrepor a IPs, para manter os mesmos endereços, crie uma nova VPC. Esse processo é simplificado se você estiver usando o Cloud DNS, que pode usar recursos como o peering de DNS para rotear o tráfego das cargas de trabalho migradas antes de dispensar a região antiga.

Para mais informações sobre como criar uma base no Google Cloud, consulte Migrar para o Google Cloud: planejamento e elaboração da base.

Preparar as cargas de trabalho para uma migração entre regiões

Se você estiver configurando sua infraestrutura em Google Cloud e planeja migrar para outra região mais tarde ou já estiver em Google Cloude precisar migrar para outra região, verifique se as cargas de trabalho podem ser migradas da maneira mais simples para reduzir o esforço e minimizar os riscos. Para garantir que todas as cargas de trabalho estejam em um estado que permita um caminho para a migração, recomendamos a seguinte abordagem:

  • Prefira designs de rede que sejam facilmente replicáveis e acoplado com flexibilidade à topologia de rede específica. OGoogle Cloud oferece produtos diferentes que podem ajudar a desacoplar a configuração de rede atual dos recursos que usam essa rede. Um exemplo desse produto é o Cloud DNS, que permite desacoplar IPs de sub-redes internas de VMs.
  • Configurar produtos com suporte a configurações multirregionais ou globais. Os produtos que oferecem suporte a uma configuração que envolve mais de uma região geralmente simplificam o processo de migração para outra região.
  • Considere usar serviços gerenciados com réplicas gerenciadas entre regiões para dados. Conforme descrito nas seções a seguir deste documento, alguns serviços gerenciados permitem criar uma réplica em uma região diferente, geralmente para fins de backup ou alta disponibilidade. Esse recurso pode ser importante para migrar dados de uma região para outra.

Alguns Google Cloud serviços foram projetados para oferecer suporte a implantações multirregionais ou implantações globais. Não é necessário migrar esses serviços, mas talvez seja necessário ajustar algumas configurações.

Preparar seus recursos de computação

Esta seção fornece uma visão geral dos recursos de computação em Google Cloud e princípios de design para se preparar para uma migração para outra região.

Este documento se concentra nos seguintes produtos de computação Google Cloud :

Compute Engine

O Compute Engine é o serviço do Google Cloudque fornece VMs aos clientes.

Para migrar recursos do Compute Engine de uma região para outra, é necessário avaliar diferentes fatores, além das considerações de rede.

Portanto, recomendamos que você faça o seguinte:

  • Verificar os recursos de computação: uma das primeiras limitações que você pode encontrar ao mudar a região de hospedagem de uma VM é a disponibilidade da plataforma de CPU na nova região de destino. Se você precisar mudar uma série de máquinas durante a migração, verifique se o sistema operacional da sua VM atual é compatível com a série. Em geral, esse problema pode ser estendido para todos os serviços de computação Google Cloud . Algumas regiões novas podem não ter serviços como o Cloud Run ou o Cloud GPU. Portanto, antes de planejar a migração, verifique se todos os serviços de computação necessários estão disponíveis na região de destino.
  • Configurar o balanceamento de carga e o escalonamento: o Compute Engine oferece suporte ao tráfego de balanceamento de carga entre instâncias do Compute Engine e ao escalonamento automático para adicionar ou remover automaticamente máquinas virtuais de MIGs, de acordo com a demanda. Recomendamos que você configure o balanceamento de carga e o escalonamento automático para aumentar a confiabilidade e a flexibilidade dos ambientes, evitando o fardo de gerenciamento de soluções autogerenciadas. Para mais informações sobre como configurar o balanceamento de carga e o escalonamento para o Compute Engine, consulte Balanceamento de carga e escalonamento.
  • Usar nomes DNS zonais: para reduzir o risco de interrupções entre regiões, recomendamos o uso de nomes DNS zonais para identificar exclusivamente máquinas virtuais que usam nomes DNS nos seus ambientes. Google Cloud usa nomes DNS zonais para máquinas virtuais do Compute Engine por padrão. Para mais informações sobre como o DNS interno do Compute Engine funciona, consulte Visão geral do DNS interno. Para facilitar uma migração futura nas regiões e tornar sua configuração mais sustentável, recomendamos que você considere os nomes DNS zonais como parâmetros de configuração que podem ser alterados no futuro.
  • Usar o mesmo modelo de grupos de instâncias gerenciadas (MIGs): o Compute Engine permite criar MIGs regionais que provisionam automaticamente máquinas virtuais em várias zonas em uma região. Se você estiver usando um modelo na sua região antiga, poderá usar o mesmo modelo para implantar os MIGs na nova região.

GKE

O Google Kubernetes Engine (GKE) ajuda você a implantar, gerenciar e escalonar cargas de trabalho conteinerizadas no Kubernetes.

Para preparar as cargas de trabalho do GKE para uma migração, considere os seguintes pontos de design e recursos do GKE:

  • Cloud Service Mesh: uma implementação gerenciada da malha do Istio. A adoção do Cloud Service Mesh para seu cluster permite que você tenha um nível maior de controle sobre o tráfego de rede no cluster. Um dos principais recursos do Cloud Service Mesh é que ele permite criar uma malha de serviço entre dois clusters. É possível usar esse recurso para planejar a migração de uma região para outra criando o cluster do GKE na nova região e adicionando-o à malha de serviço. Ao usar essa abordagem, é possível começar a implantar cargas de trabalho no novo cluster e rotear o tráfego para elas gradualmente, permitindo que você teste a nova implantação e tenha a opção de reversão editando o roteamento de malha.
  • Config Sync: um serviço do GitOps criado com base em um núcleo de código aberto que permite que operadores de cluster e administradores de plataforma implantem configurações de uma única fonte. O Config Sync pode oferecer suporte a um ou vários clusters, permitindo que você use uma única fonte de verdade para configurar os clusters. É possível usar essa função do Config Sync para replicar a configuração do cluster atual no cluster para a nova região e, possivelmente, personalizar um recurso específico para a região.
  • Backup para GKE: com esse recurso, é possível fazer backup dos dados persistentes do cluster periodicamente e restaurar os dados para o mesmo cluster ou para um novo.

Cloud Run

O Cloud Run oferece uma abordagem leve para implantar contêineres no Google Cloud. Os serviços do Cloud Run são recursos regionais e são replicados em várias zonas na região em que estão. Ao implantar um serviço do Cloud Run, você pode escolher uma região para implantar a instância e usar esse recurso para implantar a carga de trabalho em outra região.

VMware Engine

O Google Cloud VMware Engine é um serviço totalmente gerenciado que permite executar a plataforma VMware em Google Cloud. O ambiente do VMware é executado de forma nativa na Google Cloud infraestrutura bare metal em Google Cloud locais incluindo vSphere, vCenter, vSAN, NSX-T, HCX e ferramentas correspondentes.

Para migrar instâncias do VMware Engine para outra região, crie sua nuvem privada na nova região e use as ferramentas do VMware para mover as instâncias.

Também é necessário considerar o DNS e o balanceamento de carga nos ambientes do Compute Engine ao planejar a migração. O VMware Engine usa o Google Cloud DNS, que é um serviço de hospedagem DNS gerenciado que fornece hospedagem DNS autoritativa publicada na Internet pública, zonas privadas visíveis para redes VPC e encaminhamento e peering DNS para gerenciar a resolução de nomes em redes VPC. Seu
plano de migração pode oferecer suporte a testes de balanceamento de carga multirregional e configurações de DNS.

Preparar seus recursos de armazenamento de dados

Esta seção fornece uma visão geral dos recursos de armazenamento de dados no Google Cloud e os princípios básicos de como se preparar para uma migração para outra região.

A presença dos dados já em Google Cloud simplifica a migração, porque implica que uma solução para hospedá-los sem nenhuma transformação existe ou pode ser hospedada em Google Cloud.

A capacidade de copiar dados de banco de dados para uma região diferente e restaurar os dados em outro lugar é um padrão comum na recuperação de desastres (DR, na sigla em inglês). Por esse motivo, alguns dos padrões descritos neste documento dependem de mecanismos de DR, como backup e recuperação de banco de dados.

Os seguintes serviços gerenciados são descritos neste documento:

Neste documento, presumimos que as soluções de armazenamento que você está usando são instâncias regionais que estão localizadas com recursos de computação.

Cloud Storage

O Cloud Storage oferece o Serviço de transferência do Storage, que automatiza a transferência de arquivos de diferentes sistemas para o Cloud Storage. Ele pode ser usado para replicar dados em uma região diferente para backup e também para migração de região para região.

Cloud SQL

O Cloud SQL oferece um serviço de banco de dados relacional para hospedar diferentes tipos de bancos de dados. O Cloud SQL oferece uma funcionalidade de replicação entre regiões que permite que os dados da instância sejam replicados em uma região diferente. Esse recurso é um padrão comum para backup e restauração de instâncias do Cloud SQL, mas também permite promover a segunda réplica na outra região para a principal. Use esse recurso para criar uma réplica de leitura na segunda região e, em seguida, promova-a para a réplica principal depois de migrar as cargas de trabalho. Em geral, para bancos de dados, os serviços gerenciados simplificam o processo de replicação de dados para facilitar a criação de uma réplica na nova região durante a migração.

Outra maneira de lidar com a migração é usando o Database Migration Service, que permite migrar bancos de dados SQL de diferentes origens para o Google Cloud. Entre as origens com suporte, há também outra instância do Cloud SQL, com a única limitação de que você pode migrar para uma região diferente, mas não para um projeto diferente.

Filestore

Conforme explicado anteriormente neste documento, o recurso de backup e restauração do Filestore permite criar um backup de um compartilhamento de arquivos que pode ser restaurado em outra região. Esse recurso pode ser usado para realizar a migração de uma região para outra.

Bigtable

Assim como o Cloud SQL, o Bigtable oferece suporte à replicação. Você pode usar esse recurso para replicar o mesmo padrão descrito. Verifique na lista de locais do Bigtable se o serviço está disponível na região de destino.

Além disso, assim como o Filestore, o Bigtable oferece suporte a backup e restauração. Esse recurso pode ser usado, assim como no Filestore, para implementar a migração criando um backup e restaurando-o em outra instância na nova região.

A última opção é exportar tabelas, por exemplo, no Cloud Storage. Essas exportações vão hospedar dados em outro serviço, e os dados estarão disponíveis para importação na instância na região.

Firestore

Os locais do Firestore podem estar vinculados à presença do App Engine no projeto, o que, em alguns cenários, força a instância do Firestore a ser multirregional. Nesses cenários de migração, também é necessário considerar o App Engine para projetar a solução certa para o Firestore. Na verdade, se você já tiver um app do App Engine com um local us-central ou
europe-west, o banco de dados do Firestore será considerado multirregional.

Se você tiver um local regional e quiser migrar para outro, o serviço gerenciado de exportação e importação permite importar e exportar entidades do Firestore usando um bucket do Cloud Storage. Esse método pode ser usado para mover instâncias de uma região para outra. A outra opção é usar o recurso de backup e restauração do Firestore. Essa opção é mais barata e direta do que importar e exportar.

Preparar-se para desativar o ambiente de origem

Você precisa se preparar com antecedência antes de desativar o ambiente de origem e mudar para o novo.

Em um nível alto, considere o seguinte antes de desativar o ambiente de origem:

  • Testes de novo ambiente: antes de transferir o tráfego do ambiente antigo para o novo, é possível fazer testes para validar a correção dos aplicativos. Além dos testes de unidade e integração clássicos que podem ser feitos em aplicativos recém-migrados, há diferentes estratégias de teste. O novo ambiente pode ser tratado como uma nova versão do software, e a migração de tráfego pode ser implementada com padrões comuns, como testes A/B, usados para validação. Outra abordagem é replicar o tráfego de entrada no ambiente de origem e no novo ambiente para verificar se as funções foram preservadas.
  • Planejamento de inatividade: se você selecionar uma estratégia de migração, como azul-verde, em que você alterna o tráfego de um ambiente para outro, considere a adoção de inatividade planejada. O tempo de inatividade permite que a transição seja melhor monitorada e evite erros imprevisíveis no lado do cliente.
  • Reversão: dependendo das estratégias adotadas para migrar o tráfego, pode ser necessário implementar uma reversão em caso de erros ou configuração incorreta do novo ambiente. Para reverter o ambiente, é necessário ter uma infraestrutura de monitoramento em vigor para detectar o status do novo ambiente.

Só é possível encerrar os serviços na primeira região depois de realizar testes estendidos na nova região e colocá-la no ar sem erros. Recomendamos que você mantenha backups da primeira região por um período limitado, até ter certeza de que não há problemas na região recém-migrada.

Você também precisa considerar se quer promover a região antiga para um site de recuperação de desastres, supondo que ainda não haja uma solução. Essa abordagem exige um design adicional para garantir que o site seja confiável. Para mais informações sobre como projetar e planejar corretamente a DR, consulte o Guia de planejamento de recuperação de desastres.

A seguir

Colaboradores

Autor: Valerio Ponza | Consultor de soluções técnicas

Outros colaboradores: