Estruture as suas cargas de trabalho

Last reviewed 2024-07-24 UTC

Este documento ajuda a conceber cargas de trabalho de forma a minimizar o impacto de uma expansão futura e da 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 estiver a planear realizar alguma destas atividades ou se estiver a avaliar a oportunidade de o fazer no futuro e quiser explorar como poderá ser o trabalho.

Este documento faz parte de uma série:

As orientações desta série também são úteis se não tiver planeado uma migração entre regiões ou uma expansão para várias regiões antecipadamente. Neste caso, pode ter de despender mais esforços para preparar a sua infraestrutura, cargas de trabalho e dados para a migração entre regiões e para a expansão para várias regiões.

Este documento ajuda a fazer o seguinte:

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

Prepare a zona de destino

Esta secção foca-se nas considerações que tem de fazer para expandir uma zona de destino (também denominada base na nuvem) quando migra entre regiões.

O primeiro passo é reavaliar os diferentes aspetos de qualquer zona de aterragem existente. Antes de poder migrar qualquer carga de trabalho, já tem de ter uma zona de destino implementada. Embora já possa ter uma zona de destino implementada para a região que aloja as cargas de trabalho, a zona de destino pode não suportar a implementação de cargas de trabalho numa região diferente, pelo que tem de ser expandida para a região de destino. Algumas zonas de destino já implementadas podem ter um design que suporte outra região sem uma reformulação significativa da zona de destino (por exemplo, gestão de identidade e acesso ou gestão de recursos). No entanto, fatores adicionais, como a rede ou os dados, podem exigir algum planeamento para a extensão. O processo de reavaliação deve ter em conta os principais requisitos das suas cargas de trabalho para lhe permitir configurar uma base genérica que pode ser especializada mais tarde durante a migração.

Considerações empresariais

No que diz respeito a aspetos como as normas da indústria e governamentais, os regulamentos e as certificações, a mudança de cargas de trabalho para outra região pode ter requisitos diferentes. As cargas de trabalho executadas em regiões da Google localizadas fisicamente em diferentes países têm de cumprir as leis e os regulamentos desse país. Além disso, diferentes normas da indústria podem ter requisitos específicos para cargas de trabalho executadas no estrangeiro (especialmente em termos de segurança). Uma vez que Google Cloud as regiões são criadas para executar recursos num único país, por vezes, as cargas de trabalho são migradas de outra região da Google para esse país para cumprir regulamentos específicos. Quando faz estas migrações "no país", é importante reavaliar os dados executados no local para verificar se a nova região permite a migração dos seus dados para Google Cloud.

Gestão de identidade e de acesso

Quando planeia uma migração, provavelmente não tem de planear muitas alterações de identidade e acesso para regiões que já estão no Google Cloud. As decisões de identidade sobre Google Cloud e o acesso aos recursos baseiam-se normalmente na natureza dos recursos e não na região onde os recursos estão a ser executados. Seguem-se algumas considerações que pode ter de fazer:

  • Conceção de equipas: algumas empresas estão estruturadas para ter diferentes equipas a gerir diferentes recursos. Quando uma carga de trabalho é migrada para outra região, devido à alteração na estrutura dos recursos, uma equipa diferente pode ser o melhor candidato para ser responsável por determinados recursos. Neste caso, os acessos devem ser ajustados em conformidade.
  • Convenções de nomenclatura: embora as convenções de nomenclatura possam não ter qualquer impacto técnico nas funcionalidades, pode ser necessária alguma consideração se existirem recursos definidos com convenções de nomenclatura que se refiram à 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 têm o nome da região como prefixo, por exemplo, europe-west1-backend-1. Durante o processo de migração, para evitar confusões ou, pior, interromper pipelines que dependem de uma convenção de nomenclatura específica, é importante alterar os nomes para refletir a nova região.

Conetividade e redes

A arquitetura da sua rede afeta vários aspetos da forma como a migração é executada, pelo que é importante abordar esta arquitetura antes de planear como mover as cargas de trabalho.

Tenha em atenção que a conetividade no local com Google Cloud é um dos fatores que tem de reavaliar na migração, uma vez que pode ser concebida para ser específica da região. Um exemplo deste fator é o Cloud Interconnect, que está ligado ao Google Cloud através de uma associação de VLAN a regiões específicas. Tem de alterar a região onde a associação de VLAN está ligada antes de rejeitar essa região para evitar o tráfego de região para região. Outro fator a ter em conta é que, se estiver a usar o Partner Interconnect, a migração da região pode ajudar a selecionar uma localização física diferente à qual anexar as suas associações de VLAN Google Cloud. Esta consideração também é relevante se usar uma Cloud VPN e decidir alterar os endereços das sub-redes na migração: tem de reconfigurar os routers para refletirem a nova rede.

Embora as nuvens virtuais privadas (VPCs) no Google Cloud sejam recursos globais, as sub-redes únicas estão sempre associadas a uma região, o que significa que não pode usar a mesma sub-rede para as cargas de trabalho após a migração. Uma vez que as sub-redes não podem ter IPs sobrepostos, para manter os mesmos endereços, deve criar uma nova VPC. Este processo é simplificado se estiver a usar o Cloud DNS, que pode explorar funcionalidades como o peering de DNS para encaminhar o tráfego para as cargas de trabalho migradas antes de rejeitar a região antiga.

Para mais informações sobre como criar uma base no Google Cloud, consulte o artigo Migre para o Google Cloud: planeie e crie a sua base.

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

Quer esteja a configurar a sua infraestrutura no Google Cloud e planeie migrar posteriormente para outra região, ou já esteja no Google Cloude precise de migrar para outra região, tem de se certificar de que as suas cargas de trabalho podem ser migradas da forma mais simples para reduzir o esforço e minimizar os riscos. Para ajudar a garantir que todas as cargas de trabalho estão num estado que permite um caminho para a migração, recomendamos que siga a seguinte abordagem:

  • Prefira designs de rede facilmente replicáveis e pouco acoplados à topologia de rede específica. Google Cloud oferece diferentes produtos que podem ajudar a desassociar a configuração da rede atual dos recursos que usam essa rede. Um exemplo de um produto deste tipo é o Cloud DNS, que lhe permite desassociar os IPs de sub-rede internos das VMs.
  • Configure produtos que suportam configurações globais ou de várias regiões. Os produtos que suportam uma configuração que envolve mais do que uma região, normalmente, simplificam o processo de migração para outra região.
  • Considere serviços geridos com réplicas entre regiões geridas para dados. Conforme descrito nas secções seguintes deste documento, alguns serviços geridos permitem-lhe criar uma réplica numa região diferente, normalmente para fins de cópia de segurança ou alta disponibilidade. Esta funcionalidade pode ser importante para migrar dados de uma região para outra.

Alguns Google Cloud serviços foram concebidos para suportar implementações em várias regiões ou implementação global. Não precisa de migrar estes serviços, embora possa ter de ajustar algumas configurações.

Prepare os seus recursos de computação

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

Este documento foca-se nos seguintes Google Cloud produtos informáticos:

Compute Engine

O Compute Engine é um serviço da Google CloudGoogle Cloud que fornece VMs aos clientes.

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

Recomendamos que faça o seguinte:

  • Verifique os recursos de computação: uma das primeiras limitações que pode encontrar ao alterar a região de alojamento de uma VM é a disponibilidade da plataforma de CPU na nova região de destino. Se tiver de alterar uma série de máquinas durante a migração, verifique se o sistema operativo da VM atual é suportado para a série. Geralmente, este problema pode ser estendido a todos os Google Cloud serviços de computação (algumas novas regiões podem não ter serviços como o Cloud Run ou o Cloud GPU). Por isso, antes de planear a migração, certifique-se de que todos os serviços de computação de que precisa estão disponíveis na região de destino.
  • Configure o balanceamento de carga e a escalabilidade: o Compute Engine suporta o balanceamento de carga do tráfego entre instâncias do Compute Engine e a escala automática para adicionar ou remover automaticamente máquinas virtuais de GIGs, de acordo com a procura. Recomendamos que configure o equilíbrio de carga e o dimensionamento automático para aumentar a fiabilidade e a flexibilidade dos seus ambientes, evitando o encargo de gestão das soluções autogeridas. Para mais informações sobre a configuração do equilíbrio de carga e do escalonamento para o Compute Engine, consulte Equilíbrio de carga e escalonamento.
  • Use nomes DNS zonais: para mitigar o risco de indisponibilidades entre regiões, recomendamos que use nomes DNS zonais para identificar exclusivamente as máquinas virtuais através de nomes DNS nos seus ambientes.O Google Cloud usa nomes DNS zonais para máquinas virtuais do Compute Engine por predefinição. Para mais informações sobre o funcionamento do DNS interno do Compute Engine, consulte o artigo Vista geral do DNS interno. Para facilitar uma futura migração entre regiões e tornar a sua configuração mais fácil de manter, recomendamos que considere os nomes DNS zonais como parâmetros de configuração que pode alterar no futuro.
  • Use o mesmo modelo de grupos de instâncias geridas (GIGs): o Compute Engine permite-lhe criar GIGs regionais que aprovisionam automaticamente máquinas virtuais em várias zonas numa região. Se estiver a usar um modelo na sua região antiga, pode usar o mesmo modelo para implementar os MIGs na nova região.

GKE

O Google Kubernetes Engine (GKE) ajuda a implementar, gerir e dimensionar cargas de trabalho em contentores no Kubernetes.

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

  • Cloud Service Mesh: Uma implementação gerida da malha Istio. A adoção da malha de serviços na nuvem para o seu cluster permite-lhe ter um maior nível de controlo sobre o tráfego de rede no cluster. Uma das principais funcionalidades da Cloud Service Mesh é que lhe permite criar uma service mesh entre dois clusters. Pode usar esta funcionalidade para planear a migração de uma região para outra criando o cluster do GKE na nova região e adicionando-o à malha de serviços. Ao usar esta abordagem, é possível começar a implementar cargas de trabalho no novo cluster e encaminhar o tráfego para elas gradualmente, o que lhe permite testar a nova implementação e ter a opção de reverter a implementação editando o encaminhamento da malha.
  • Config Sync: um serviço GitOps criado com base num núcleo de código aberto que permite aos operadores de clusters e aos administradores da plataforma implementar configurações a partir de uma única origem. O Config Sync pode suportar um ou vários clusters, o que lhe permite usar uma única fonte de informações fidedignas para configurar os clusters. Pode usar esta função Config Sync para replicar a configuração do cluster existente no cluster para a nova região e, potencialmente, personalizar um recurso específico para a região.
  • Cópia de segurança do GKE: esta funcionalidade permite-lhe fazer cópias de segurança dos dados persistentes do cluster periodicamente e restaurar os dados no mesmo cluster ou num novo.

Cloud Run

O Cloud Run oferece uma abordagem simples para implementar contentores 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 se encontram. Quando implementa um serviço do Cloud Run, pode escolher uma região onde implementar a instância e, em seguida, usar esta funcionalidade para implementar a carga de trabalho numa região diferente.

VMware Engine

O Google Cloud VMware Engine é um serviço totalmente gerido que lhe permite executar a plataforma VMware no Google Cloud. O ambiente VMware é executado nativamente na Google Cloud infraestrutura bare metal em Google Cloud localizações incluindo vSphere, vCenter, vSAN, NSX-T, HCX e ferramentas correspondentes.

Para migrar instâncias do VMware Engine para uma região diferente, deve criar a sua nuvem privada na nova região e, em seguida, usar as ferramentas VMware para mover as instâncias.

Também deve considerar o DNS e o equilíbrio de carga em ambientes do Compute Engine quando planear a migração. O VMware Engine usa o Google Cloud DNS, que é um serviço de alojamento DNS gerido que fornece alojamento DNS autoritário publicado na Internet pública, zonas privadas visíveis para redes VPC e encaminhamento e peering DNS para gerir a resolução de nomes em redes VPC. O seu
plano de migração pode suportar testes de equilíbrio de carga em várias regiões e configurações de DNS.

Prepare os recursos de armazenamento de dados

Esta secção fornece uma vista geral dos recursos de armazenamento de dados no Google Cloud e os princípios básicos sobre 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 existe uma solução para os alojar sem qualquer transformação ou que podem ser alojados no Google Cloud.

A capacidade de copiar dados da base de dados para uma região diferente e restaurar os dados noutro local é um padrão comum na recuperação de desastres (RD). Por este motivo, alguns dos padrões descritos neste documento baseiam-se em mecanismos de DR, como a cópia de segurança e a recuperação de bases de dados.

Os seguintes serviços geridos estão descritos neste documento:

Este documento pressupõe que as soluções de armazenamento que está a usar são instâncias regionais localizadas juntamente com os recursos de computação.

Cloud Storage

O Cloud Storage oferece o Serviço de transferência de armazenamento, que automatiza a transferência de ficheiros de diferentes sistemas para o Cloud Storage. Pode ser usado para replicar dados para uma região diferente para fins de cópia de segurança e também para migração entre regiões.

Cloud SQL

O Cloud SQL oferece um serviço de base de dados relacional para alojar diferentes tipos de bases de dados. O Cloud SQL oferece uma funcionalidade de replicação entre regiões que permite replicar os dados da instância numa região diferente. Esta funcionalidade é um padrão comum para a cópia de segurança e o restauro de instâncias do Cloud SQL, mas também lhe permite promover a segunda réplica na outra região para a réplica principal. Pode usar esta funcionalidade para criar uma réplica de leitura na segunda região e, em seguida, promovê-la a réplica principal assim que migrar as cargas de trabalho. Em geral, para bases de dados, os serviços geridos 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 forma de processar a migração é usar o serviço de migração de bases de dados, que lhe permite migrar bases de dados SQL de diferentes origens para o Google Cloud. Entre as origens suportadas, existe também outra instância do Cloud SQL, com a única limitação de que pode migrar para uma região diferente, mas não para um projeto diferente.

Filestore

Conforme explicado anteriormente neste documento, a funcionalidade de cópia de segurança e restauro do Filestore permite-lhe criar uma cópia de segurança de uma partilha de ficheiros que pode ser restaurada para outra região. Esta funcionalidade pode ser usada para fazer a migração de uma região para outra.

Bigtable

Tal como o Cloud SQL, o Bigtable suporta a replicação. Pode usar esta funcionalidade para replicar o mesmo padrão descrito. Verifique na lista de localizações do Bigtable se o serviço está disponível na região de destino.

Além disso, tal como o Filestore, o Bigtable suporta a cópia de segurança e o restauro. Tal como com o Filestore, pode usar esta funcionalidade para implementar a migração criando uma cópia de segurança e restaurando-a noutra instância na nova região.

A última opção é exportar tabelas, por exemplo, no Cloud Storage. Estas exportações alojam dados noutro serviço e, em seguida, os dados ficam disponíveis para importação para a instância na região.

Firestore

As localizações do Firestore podem estar associadas à presença do App Engine no seu projeto, o que, em alguns cenários, força a instância do Firestore a ser multirregião. Nestes cenários de migração, também é necessário ter em conta o App Engine para conceber a solução certa para o Firestore. Na verdade, se já tiver uma app do App Engine com uma localização de us-central ou
europe-west, a sua base de dados do Firestore é considerada multirregional.

Se tiver uma localização regional e quiser migrar para uma localização diferente, o serviço de exportação e importação gerido permite-lhe importar e exportar entidades do Firestore através de um contentor do Cloud Storage. Este método pode ser usado para mover instâncias de uma região para outra. A outra opção é usar a funcionalidade de cópia de segurança e restauro do Firestore. Esta opção é menos dispendiosa e mais simples do que a importação e a exportação.

Prepare-se para a desativação do ambiente de origem

Tem de se preparar antecipadamente antes de desativar o ambiente de origem e mudar para o novo.

A um nível elevado, deve considerar o seguinte antes de desativar o ambiente de origem:

  • Novos testes de ambiente: antes de mudar o tráfego do ambiente antigo para o novo ambiente, pode fazer testes para validar a correção das aplicações. Além dos testes de integração e de unidades clássicos que podem ser feitos em aplicações recém-migradas, existem diferentes estratégias de testes. 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 os testes A/B usados para validação. Outra abordagem é replicar o tráfego recebido no ambiente de origem e no novo ambiente para verificar se as funções são preservadas.
  • Planeamento de tempo de inatividade: se selecionar uma estratégia de migração, como a estratégia azul-verde, em que muda o tráfego de um ambiente para outro, considere a adoção de tempo de inatividade planeado. O tempo de inatividade permite monitorizar melhor a transição e evitar erros imprevisíveis do lado do cliente.
  • Reversão: consoante as 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 poder reverter o ambiente, tem de ter uma infraestrutura de monitorização implementada para detetar o estado do novo ambiente.

Só é possível encerrar os serviços na primeira região depois de realizar testes alargados na nova região e entrar em produção na nova região sem erros. Recomendamos que mantenha cópias de segurança da primeira região durante um período limitado até ter a certeza de que não existem problemas na região recém-migrada.

Também deve considerar se quer promover a região antiga para um site de recuperação de desastres, partindo do princípio de que ainda não existe uma solução implementada. Esta abordagem requer um design adicional para garantir que o site é fiável. Para mais informações sobre como conceber e planear corretamente a recuperação de desastres, consulte o Guia de planeamento de recuperação de desastres.

O que se segue

Colaboradores

Autor: Valerio Ponza | Technical Solution Consultant

Outros colaboradores: