Arquitetar suas cargas de trabalho

Last reviewed 2024-07-24 UTC

Este documento ajuda você a projetar cargas de trabalho de forma a minimizar o impacto de uma expansão e migração futuras para outras regiões do Google Cloudou de uma migração 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 será o trabalho.

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 suas 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 a desativação do 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 na nuvem) ao migrar entre regiões.

A primeira etapa é reavaliar os diferentes aspectos de uma zona de destino atual. Antes de migrar qualquer carga de trabalho, você precisa ter uma zona de destino em vigor. Embora você já tenha uma zona de destino para a região que hospeda as cargas de trabalho, ela pode não ser compatível com a implantação de cargas de trabalho em outra região. Por isso, ela precisa ser estendida para a região de destino. Algumas landing zones já implementadas podem ter um design que suporta outra região sem um retrabalho significativo (por exemplo, gerenciamento de identidade e acesso ou gerenciamento de recursos). No entanto, outros fatores, como rede ou dados, podem exigir planejamento para a extensão. Seu processo de reavaliação precisa considerar os principais requisitos das cargas de trabalho para permitir que você configure uma base genérica que pode ser especializada mais tarde durante a migração.

Considerações empresariais

Quando se trata de aspectos como padrões, regulamentações e certificações do setor e do governo, a movimentação de cargas de trabalho para outra região pode ter requisitos diferentes. As cargas de trabalho executadas em regiões do Google localizadas fisicamente 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 específicos 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 em execução 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 não é necessário planejar muitas mudanças de identidade e acesso para regiões que já estão no Google Cloud. As decisões de identidade no Google Cloud e o acesso aos recursos geralmente são baseados na natureza dos recursos, e não na região em que eles estão sendo executados. Algumas considerações que você pode precisar fazer são as seguintes:

  • Design de equipes: algumas empresas são estruturadas para ter equipes diferentes que lidam 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 impacto técnico nas funcionalidades, talvez seja necessário considerar algo se houver 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ão ou, pior, 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. Por isso, é importante resolver esse design antes de planejar como mover as cargas de trabalho.

Lembre-se de que a conectividade local com Google Cloud é um dos fatores que precisam ser reavaliados na migração, já que ela pode ser projetada para ser específica da região. Um exemplo desse fator é o Cloud Interconnect, que está conectado a Google Cloud por um anexo da VLAN a regiões específicas. Mude 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 considerar é que, se você estiver usando a Interconexão por parceiro, a migração da região poderá ajudar a selecionar um local físico diferente para conectar seus anexos da VLAN ao 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) no Google Cloud sejam recursos globais, as sub-redes únicas estão sempre vinculadas a uma região. Isso significa que não é possível usar a mesma sub-rede para as cargas de trabalho após a migração. Como as sub-redes não podem ter IPs sobrepostos, crie uma nova VPC para manter os mesmos endereços. Esse processo é simplificado se você estiver usando o Cloud DNS, que pode aproveitar recursos como o peering de DNS para rotear o tráfego das cargas de trabalho migradas antes de descartar a região antiga.

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

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

Se você estiver configurando sua infraestrutura no Google Cloud e planeja migrar para outra região mais tarde, ou se já estiver no 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 da topologia de rede específica. OGoogle Cloud oferece diferentes produtos que podem ajudar você a desacoplar sua configuração de rede atual dos recursos que usam essa rede. Um exemplo desse produto é o Cloud DNS, que permite desacoplar os IPs de sub-rede internos das VMs.
  • Configure produtos que oferecem suporte a configurações multirregionais ou globais. 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 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 serviços do Google Cloud foram projetados para oferecer suporte a implantações multirregionais ou implantação global. 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:

  • Verifique 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 a todos os serviços de computação Google Cloud . Algumas regiões novas podem não ter serviços como Cloud Run ou 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 balanceamento de carga e 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 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.
  • Use 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.
  • Use o mesmo modelo de grupos gerenciados de instâncias (MIGs): o Compute Engine permite criar MIGs regionais que provisionam automaticamente máquinas virtuais em várias zonas de uma região. Se você estiver usando um modelo na 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. Ao adotar o Cloud Service Mesh para seu cluster, você tem 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. Use 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 testar a nova implantação e ter a opção de fazer o rollback editando o roteamento da 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. Você pode usar essa função do Config Sync para replicar a configuração do cluster atual no cluster da nova região e 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, é possível 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 no Google Cloud. O ambiente do VMware é executado nativamente na infraestrutura bare metal doGoogle Cloud nos locais do Google Cloud , 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.

Ao planejar a migração, considere também o DNS e o balanceamento de carga nos ambientes do Compute Engine. O VMware Engine usa o Cloud DNS do Google, um serviço gerenciado de hospedagem de DNS que fornece hospedagem de DNS autoritativa publicada na Internet pública, zonas particulares visíveis para redes VPC e encaminhamento e peering de DNS para gerenciar a resolução de nomes em redes VPC. Seu plano de migração do
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á no Google Cloud simplifica a migração, porque implica que uma solução para hospedá-los sem qualquer transformação existe ou pode ser hospedada no 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 em recuperação de desastres (DR). Por isso, 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:

Este documento pressupõe que as soluções de armazenamento usadas são instâncias regionais localizadas com recursos de computação.

Cloud Storage

O Cloud Storage oferece o Storage Transfer Service, 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 réplica principal. Use esse recurso para criar uma réplica de leitura na segunda região e promovê-la à 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, facilitando a criação de uma réplica na nova região durante a migração.

Outra maneira de lidar com a migração é usar o Database Migration Service, que permite migrar bancos de dados SQL de diferentes fontes para o Google Cloud. Entre as fontes compatíveis, há também outra instância do Cloud SQL, com a única limitação de que é possível 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 migrações de região para região.

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. Assim como no Filestore, esse recurso pode ser usado 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, que poderão ser importados para a 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, seu banco de dados do Firestore será considerado multirregional.

Se você tiver um local regional e quiser migrar para outro local, 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 simples do que importar e exportar.

Preparar a desativação do ambiente de origem

É preciso se preparar antes de desativar o ambiente de origem e mudar para o novo.

Em geral, considere o seguinte antes de desativar o ambiente de origem:

  • Testes de novo ambiente: antes de mudar 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 são preservadas.
  • Planejamento de tempo de inatividade: se você selecionar uma estratégia de migração como azul-verde, em que o tráfego é alternado de um ambiente para outro, considere a adoção de um tempo de inatividade planejado. O tempo de inatividade permite que a transição seja melhor monitorada e evita erros imprevisíveis no lado do cliente.
  • Reversão: dependendo das estratégias adotadas para migrar o tráfego, talvez seja necessário implementar uma reversão em caso de erros ou configuração incorreta do novo ambiente. Para fazer o rollback do ambiente, você precisa ter uma infraestrutura de monitoramento para detectar o status do novo ambiente.

Só é possível encerrar os serviços na primeira região depois de realizar testes extensivos na nova região e entrar em produção 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.

Considere também se você quer promover a região antiga para um site de recuperação de desastres, supondo que ainda não haja uma solução em vigor. Essa abordagem requer 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: