Google Cloud oferece ferramentas, produtos, orientações e serviços profissionais para migrar máquinas virtuais (VMs) e os respectivos dados do Amazon Elastic Compute Cloud (Amazon EC2) para o Compute Engine. Neste documento, mostraremos como projetar, implementar e validar um plano para migrar do Amazon EC2 para o Compute Engine.
A discussão neste documento é destinada a administradores de nuvem que querem detalhes sobre planejar e implementar um processo de migração. Ela também é destinada a tomadores de decisão que estão avaliando a oportunidade de migrar e que querem explorar uma migração.
Este documento faz parte de uma série com várias partes sobre a migração da AWS para Google Cloud que inclui os seguintes documentos:
- Primeiros passos
- Migrar do Amazon EC2 para o Compute Engine (este documento)
- Migrar do Amazon S3 para o Cloud Storage
- Migrar do Amazon EKS para o Google Kubernetes Engine
- Migrar do Amazon RDS e do Amazon Aurora para MySQL para o Cloud SQL para MySQL
- Migrar do Amazon RDS e do Amazon Aurora para PostgreSQL para o Cloud SQL para PostgreSQL e o AlloyDB para PostgreSQL
- Migrar do Amazon RDS para SQL Server para o Cloud SQL para SQL Server
- Migrar da AWS Lambda para o Cloud Run
Para essa migração para Google Cloud, recomendamos que você siga o framework de migração descrito em Migrar para Google Cloud: primeiros passos.
No diagrama a seguir, veja o caminho da sua jornada de migração.
É possível migrar do seu ambiente de origem para o Google Cloud em uma série de iterações. Por exemplo, é possível migrar algumas cargas de trabalho primeiro e outras mais tarde. Para cada iteração de migração separada, siga as fases do framework de migração geral:
- Avaliar e descobrir suas cargas de trabalho e seus dados.
- Planejar e criar uma base em Google Cloud.
- Migre suas cargas de trabalho e seus dados para o Google Cloud.
- Otimize o Google Cloud ambiente.
Para mais informações sobre as fases desse framework, consulte Migrar para o Google Cloud: primeiros passos.
Para elaborar um plano de migração eficaz, recomendamos que você valide cada etapa do plano e use uma estratégia de reversão. Para ajudar você a validar o plano de migração, consulte Migrar para o Google Cloud: práticas recomendadas para validar um plano de migração.
Avaliar o ambiente de origem
Na fase de avaliação, você determina os requisitos e as dependências para migrar o ambiente de origem para Google Cloud.
A fase de avaliação é fundamental para o sucesso da migração. Você precisa ter um excelente conhecimento das cargas de trabalho que quer migrar, dos requisitos, das dependências e do ambiente atual. Você precisa entender seu ponto de partida para planejar e executar uma migração do Google Cloud.
A fase de avaliação consiste nas tarefas a seguir:
- Criar um inventário abrangente das suas cargas de trabalho.
- Catalogar suas cargas de trabalho de acordo com as propriedades e dependências delas.
- Treine e instrua suas equipes sobre Google Cloud.
- Crie experimentos e provas de conceito no Google Cloud.
- Calcule o custo total de propriedade (TCO) do ambiente de destino.
- Escolha a estratégia de migração para suas cargas de trabalho.
- Escolha as ferramentas de migração.
- Defina o plano e o cronograma de migração.
- Valide seu plano de migração.
Para mais informações sobre a fase de avaliação e essas tarefas, consulte Migrar para o Google Cloud: avaliar e descobrir cargas de trabalho. As seções a seguir são baseadas nas informações desse documento.
Criar um inventário das suas instâncias do Amazon EC2
Para definir o escopo da migração, crie um inventário das suas instâncias do Amazon EC2. É possível usar o inventário para avaliar os processos operacionais e de implantação para implantar cargas de trabalho nessas instâncias.
Para criar o inventário das instâncias do Amazon EC2, recomendamos que você use a Central de migração, a plataforma unificada doGoogle Cloudque ajuda a acelerar sua jornada completa na nuvem do ambiente atual para Google Cloud. A Central de migração permite importar dados do Amazon EC2 e de outros recursos da AWS. Em seguida, a Central de migração recomenda serviços Google Cloud relevantes para os quais você pode migrar.
Depois de avaliar seu ambiente usando a Central de migração, recomendamos que você gere um relatório de avaliação de migração técnica usando a CLI do discovery client da Central de migração. Para mais informações, consulte Coletar dados de convidados das instâncias do Amazon EC2 para avaliação off-line.
Os dados fornecidos pela Central de migração e pela CLI do discovery client da Central de migração podem não capturar totalmente as dimensões em que você tem interesse. Nesse caso, é possível integrar esses dados aos resultados de outros mecanismos de coleta de dados criados com base em APIs e ferramentas de desenvolvedor da AWS e na interface de linha de comando da AWS.
Além dos dados recebidos da Central de migração e da CLI do discovery client da Central de migração, considere os seguintes pontos de dados para cada instância do Amazon EC2 que você quer migrar:
- Região e zona da implantação.
- Tipo e tamanho da instância.
- A Amazon Machine Image (AMI) que executa a instância.
- O nome do host da instância e como outras instâncias e cargas de trabalho o usam para se comunicar com a instância.
- As tags de instância, os metadados e os dados do usuário.
- O tipo de virtualização da instância.
- A opção de compra da instância, como compra sob demanda ou compra pontual.
- Como a instância armazena dados, como o uso de repositórios de instâncias e volumes do Amazon EBS.
- A configuração de locação da instância.
- Se a instância está em um grupo de posições específico.
- Se a instância está em um grupo de escalonamento automático específico.
- Os grupos de segurança aos quais a instância pertence.
- Qualquer configuração de firewall de rede da AWS que envolva a instância.
- Se as cargas de trabalho executadas na instância são protegidas pelo AWS Shield e pelo AWS WAF.
- Se você está controlando o estado do processador da instância e como as cargas de trabalho executadas nela dependem do estado do processador.
- A configuração do programador de E/S da instância.
- Como você está expondo as cargas de trabalho executadas na instância para clientes executados no ambiente da AWS (como outras cargas de trabalho) e para clientes externos.
Avaliar os processos operacionais e de implantação
É fundamental ter um entendimento claro de como seus processos operacionais e de implantação funcionam. Eles são parte fundamental das práticas que preparam e mantêm o ambiente de produção e as cargas de trabalho executadas nele.
Os processos operacionais e de implantação podem criar os artefatos necessários para as cargas de trabalho funcionarem. Portanto, colete informações sobre cada tipo de artefato. Por exemplo, um artefato pode ser um pacote de sistema operacional, um pacote de implantação de aplicativo, uma imagem do sistema operacional, uma imagem de contêiner ou qualquer outra coisa.
Além do tipo de artefato, considere como você conclui as seguintes tarefas:
- Desenvolva seus workloads. Avalie os processos que as equipes de desenvolvimento têm para criar suas cargas de trabalho. Por exemplo, como suas equipes de desenvolvimento projetam, codificam e testam suas cargas de trabalho?
- Gerar os artefatos implantados no ambiente de origem. Para implantar as cargas de trabalho no ambiente de origem, você pode gerar artefatos implantáveis, como imagens de contêiner ou do sistema operacional, ou personalizar artefatos existentes, como imagens de sistema operacional de terceiros, instalando e configurando software. A coleta de informações sobre como você gera esses artefatos ajuda a garantir que os artefatos gerados sejam adequados para implantação no Google Cloud.
Armazene os artefatos. Se você produzir artefatos armazenados em um registro de artefatos no ambiente de origem, será necessário disponibilizá-los no ambiente Google Cloud . Para fazer isso, use estratégias como as seguintes:
- Estabeleça um canal de comunicação entre os ambientes: torne os artefatos no ambiente de origem acessíveis pelo ambiente de destino Google Cloud .
- Refatorar o processo de compilação do artefato: conclua uma pequena refatoração do ambiente de origem para que seja possível armazenar artefatos nos ambientes de origem e de destino. Essa abordagem oferece suporte à migração por meio da criação de uma infraestrutura como um repositório de artefatos antes da implementação dos processos de build de artefatos no ambiente de destino. Google CloudÉ possível implementar essa abordagem diretamente ou aproveitar a abordagem anterior de estabelecer um canal de comunicação primeiro.
Ter artefatos disponíveis nos ambientes de origem e de destino permite que você se concentre na migração sem precisar implementar processos de criação de artefatos no ambiente de destino Google Cloud como parte da migração.
Ler e assinar o código. Como parte dos processos de build de artefatos, você pode usar a verificação de código para se proteger contra vulnerabilidades comuns e exposição não intencional à rede, além de assinar o código para garantir que apenas códigos confiáveis sejam executados nos seus ambientes.
Implante artefatos no ambiente de origem. Depois de gerar artefatos implantáveis, você pode implantá-los no ambiente de origem. Recomendamos que você avalie cada processo de implantação. A avaliação ajuda a garantir que os processos de implantação sejam compatíveis com Google Cloud. Isso também ajuda você a entender o esforço necessário para refatorar os processos. Por exemplo, se os processos de implantação funcionarem apenas com o ambiente de origem, talvez seja necessário refatorá-los para segmentar o ambiente Google Cloud .
Injetar a configuração do ambiente de execução. Talvez você esteja injetando a configuração do ambiente de execução para clusters, ambientes de execução ou implantações de carga de trabalho específicos. A configuração pode inicializar variáveis de ambiente e outros valores de configuração, como segredos, credenciais e chaves. Para garantir que os processos de injeção de configuração do ambiente de execução funcionem no Google Cloud, recomendamos que você avalie como está configurando as cargas de trabalho executadas no ambiente de origem.
Geração de registros, monitoramento e criação de perfis. Avalie os processos de registro, monitoramento e criação de perfil que você tem para monitorar a integridade do ambiente de origem, as métricas de interesse e como você consome os dados fornecidos por esses processos.
Autenticação. Avalie como você está fazendo a autenticação no seu ambiente de origem.
Provisione e configure seus recursos. Para preparar o ambiente de origem, é possível que você tenha projetado e implementado processos que provisionem e configurem recursos. Por exemplo, você pode usar o Terraform com ferramentas de gerenciamento de configuração para provisionar e configurar recursos no ambiente de origem.
Planejar e criar sua base
Na fase de planejamento e criação, você provisiona e configura a infraestrutura para fazer o seguinte:
- Ofereça suporte às cargas de trabalho no Google Cloud ambiente.
- Conecte o ambiente de origem e o Google Cloud para concluir a migração.
A fase de criação e planejamento é composta pelas seguintes tarefas:
- Crie uma hierarquia de recursos.
- Configure o Identity and Access Management (IAM) do Google Cloud.
- Configure o faturamento.
- Configurar a conectividade de rede.
- Aumentar sua segurança.
- Configurar a geração de registros, o monitoramento e os alertas.
Para mais informações sobre cada uma dessas tarefas, consulte Migrar para o Google Cloud: planeje e crie sua base.
Migre suas cargas de trabalho
Para migrar as cargas de trabalho do Amazon EC2 para o Compute Engine, faça o seguinte:
- Migre VMs do Amazon EC2 para o Compute Engine.
- Migre os discos da VM para o Persistent Disk.
- Exponha aos clientes as cargas de trabalho executadas no Compute Engine.
- Refatore os processos operacionais e de implantação para que tenham como destino Google Cloud em vez de o Amazon EC2.
As seções a seguir fornecem detalhes sobre cada uma dessas tarefas.
Migrar VMs para o Compute Engine
Para migrar VMs do Amazon EC2 para o Compute Engine, recomendamos usar o Migrate to Virtual Machines, que é um serviço totalmente gerenciado. Para mais informações, consulte Jornada de migração com o Migrate to VMs.
Como parte da migração, o Migrate for VMs migra as instâncias do Amazon EC2 no estado atual, além das alterações de configuração necessárias. Se as instâncias do Amazon EC2 executam AMIs personalizadas do Amazon EC2, o Migrate for VMs migra essas personalizações para as instâncias do Compute Engine. No entanto, se você quiser tornar a infraestrutura reproduzível, talvez seja necessário aplicar personalizações equivalentes criando imagens do sistema operacional do Compute Engine como parte dos processos operacionais e de implantação, conforme explicado mais adiante neste documento. Também é possível importar as AMIs do Amazon EC2 para o Compute Engine.
Migrar os discos da VM para o Persistent Disk
Também é possível usar o Migrate to VMs para migrar discos das VMs do Amazon EC2 de origem para o Persistent Disk, com interrupções mínimas nas cargas de trabalho que estão sendo executadas nas VMs do Amazon EC2. Para mais informações, consulte Migrar discos de VM e anexá-los a uma nova VM.
Por exemplo, é possível migrar um disco de dados anexado a uma VM do Amazon EC2 para o Persistent Disk e anexá-lo a uma nova VM do Compute Engine.
Expor cargas de trabalho executadas no Compute Engine
Depois de migrar suas instâncias do Amazon EC2 para as instâncias do Compute Engine, talvez seja necessário provisionar e configurar o ambiente do Google Cloud para expor as cargas de trabalho aos clientes.
OGoogle Cloud oferece serviços e produtos seguros e confiáveis para expor suas cargas de trabalho aos clientes. Para cargas de trabalho executadas nas instâncias do Compute Engine, configure recursos para as seguintes categorias:
- Firewalls
- Balanceamento de carga de tráfego
- Nomes, zonas e registros DNS
- Proteção contra DDoS e firewalls de aplicativos da Web
Para cada uma dessas categorias, comece implementando uma configuração de valor de referência semelhante à configuração dos serviços e recursos da AWS na categoria equivalente. Em seguida, é possível iterar a configuração e usar outros recursos fornecidos pelos serviços Google Cloud .
As seções a seguir explicam como provisionar e configurar recursosGoogle Cloud nessas categorias e como eles são associados a recursos da AWS em categorias semelhantes.
Firewalls
Se você tiver configurado grupos de segurança e políticas e regras de firewall de rede da AWS, será possível configurar Políticas e regras do Cloud Firewall de última geração. Também será possível provisionar regras do VPC Service Controls para regular o tráfego de rede na VPC. Use o VPC Service Controls para controlar o tráfego de saída das instâncias do Compute Engine e ajudar a reduzir o risco de exfiltração de dados.
Por exemplo, se você usar grupos de segurança da AWS para permitir ou negar conexões com as instâncias do Amazon EC2, será possível configurar regras de firewall de nuvem privada virtual (VPC) semelhantes que se apliquem às instâncias do Compute Engine.
Se você usa protocolos de acesso remoto, como SSH ou RDP, para se conectar às suas VMs do Amazon EC2, é possível remover o endereço IP público da VM e se conectar a ela remotamente com o Identity-Aware Proxy (IAP). O encaminhamento de TCP do IAP permite estabelecer um túnel criptografado. Você pode usar o túnel para encaminhar SSH, RDP e outros tráfegos da Internet para VMs sem atribuir endereços IP públicos a elas. Como as conexões do serviço do IAP são originadas de um intervalo de endereço IP público reservado, é necessário criar regras de firewall da VPC correspondentes. Se você tiver VMs baseadas no Windows e tiver ativado o Firewall do Windows, verifique se ele não está configurado para bloquear conexões RDP do IAP. Para mais informações, consulte Solução de problemas do RDP.
Balanceamento de carga de tráfego
Se você tiver configurado o Elastic Load Balancing (ELB) no ambiente da AWS, será possível configurar o Cloud Load Balancing para distribuir o tráfego de rede e melhorar a escalonabilidade das cargas de trabalho no Google Cloud. O Cloud Load Balancing é compatível com vários produtos de balanceamento de carga globais e regionais que funcionam em diferentes camadas do modelo OSI, como na camada de transporte e na camada do aplicativo. É possível escolher um produto de balanceamento de carga adequado aos requisitos das suas cargas de trabalho.
O Cloud Load Balancing também oferece suporte à configuração do Transport Layer Security (TLS) para criptografar o tráfego de rede. Ao configurar o TLS para o Cloud Load Balancing, é possível usar certificados TLS autogerenciados ou gerenciados pelo Google, dependendo dos seus requisitos.
Nomes, zonas e registros DNS
Se você usa o Amazon Route 53 no seu ambiente da AWS, é possível usar o seguinte em Google Cloud:
- Cloud Domains para registrar os domínios DNS.
- Cloud DNS para gerenciar as zonas DNS públicas e privadas e os registros DNS.
Por exemplo, se você registrou um domínio usando o Amazon Route 53, é possível transferir o registro do domínio para o Cloud Domains. Da mesma forma, se você configurou zonas DNS públicas e privadas usando o Amazon Route 53, é possível migrar essa configuração para o Cloud DNS.
Proteção contra DDoS e firewalls de aplicativos da Web
Se você configurou o AWS Shield e o AWS WAF no ambiente da AWS, use o Google Cloud Armor para ajudar a proteger suas cargas de trabalho do Google Cloud contra ataques DDoS e explorações comuns.
Refatorar os processos operacionais e de implantação
Depois de refatorar as cargas de trabalho, refatore os processos operacionais e de implantação para fazer o seguinte:
- Provisione e configure recursos no ambiente Google Cloud , em vez de provisionar recursos no ambiente de origem.
- Crie e configure cargas de trabalho e implante-as no Google Cloud em vez de implantá-las no ambiente de origem.
Você coletou informações sobre esses processos durante a fase de avaliação anterior.
O tipo de refatoração que você precisa considerar para esses processos depende de como você os projetou e implementou. A refatoração também depende do estado final desejado para cada processo. Por exemplo, considere o seguinte:
- Talvez você tenha implementado esses processos no ambiente de origem e queira projetar e implementar processos semelhantes no Google Cloud. Por exemplo, é possível refatorar esses processos para usar o Cloud Build, o Cloud Deploy e o Infrastructure Manager.
- Talvez você tenha implementado esses processos em outro ambiente de terceiros fora do ambiente de origem. Nesse caso, é necessário refatorar esses processos para definir como destino o ambiente Google Cloud em vez do ambiente de origem.
- Uma combinação das abordagens anteriores.
A refatoração de processos operacionais e de implantação pode ser complexa e exigir um esforço significativo. Se você tentar realizar essas tarefas como parte da migração de carga de trabalho, a migração de carga de trabalho poderá se tornar mais complexa e expor você a riscos. Depois de avaliar os processos operacionais e de implantação, você provavelmente entenderá o design e a complexidade deles. Se você acredita que requer um esforço significativo para refatorar seus processos operacionais e de implantação, recomendamos considerar a refatoração desses processos como parte de um projeto dedicado e separado.
Para mais informações sobre como projetar e implementar processos de implantação no Google Cloud, consulte:
- Migrar para o Google Cloud: implantar suas cargas de trabalho
- Migrar para Google Cloud: migrar de implantações manuais para implantações automatizadas e conteinerizadas
Este documento se concentra nos processos de implantação que produzem os artefatos a serem implantados e os implantam no ambiente de execução de destino. A estratégia de refatoração depende muito da complexidade desses processos. A lista a seguir descreve uma possível estratégia geral de refatoração:
- Provisione repositórios de artefatos em Google Cloud. Por exemplo, é possível usar o Artifact Registry para armazenar artefatos e criar dependências.
- Refatore seus processos de build para armazenar artefatos no ambiente de origem e no Artifact Registry.
- Refatore os processos de implantação para implantar cargas de trabalho no ambiente de destino Google Cloud . Por exemplo, você pode começar implantando um pequeno subconjunto das suas cargas de trabalho em Google Cloud, usando artefatos armazenados no Artifact Registry. Em seguida, aumente gradualmente o número de cargas de trabalho implantadas no Google Cloudaté que todas as cargas de trabalho a serem migradas sejam executadas no Google Cloud.
- Refactorize seus processos de build para armazenar artefatos apenas no Artifact Registry.
- Se necessário, migre versões anteriores dos artefatos a serem implantado dos repositórios no ambiente de origem para o Artifact Registry. Por exemplo, é possível copiar imagens de contêiner para o Artifact Registry.
- Desative os repositórios no ambiente de origem quando não precisar mais deles.
Para facilitar as revisões devido a problemas inesperados durante a migração, é possível armazenar imagens de contêiner nos repositórios de artefatos atuais em Google Cloud enquanto a migração para Google Cloud está em andamento. Por fim, como parte da desativação do ambiente de origem, é possível refatorar os processos de criação de imagens de contêiner para armazenar artefatos apenas no Google Cloud .
Embora não seja crucial para o sucesso de uma migração, talvez seja necessário migrar as versões anteriores dos artefatos do ambiente de origem para os repositórios de artefatos no Google Cloud. Por exemplo, para oferecer suporte ao reversão de cargas de trabalho para pontos arbitrários no tempo, talvez seja necessário migrar versões anteriores dos artefatos para o Artifact Registry. Para mais informações, consulte Migrar imagens de um registro de terceiros.
Se você estiver usando o Artifact Registry para armazenar artefatos, recomendamos que configure controles para ajudar a proteger seus repositórios de artefatos, como controle de acesso, prevenção de exfiltração de dados, verificação de vulnerabilidade e autorização binária. Para mais informações, consulte Controlar o acesso e proteger artefatos.
Otimizar o Google Cloud ambiente
A otimização é a última fase da migração. Nesta fase, você repete as tarefas de otimização até que o ambiente de destino atenda aos requisitos de otimização. As etapas de cada iteração são as seguintes:
- Avaliar o ambiente, as equipes e o ciclo de otimização atuais.
- Estabeleça suas metas e requisitos de otimização.
- Otimize o ambiente e as equipes.
- Ajustar o loop de otimização.
Repita essa sequência até alcançar suas metas de otimização.
Para mais informações sobre como otimizar o ambiente do Google Cloud , consulte Migrar para Google Cloud: otimizar o ambiente e Framework de arquiteturaGoogle Cloud : otimização de performance.
A seguir
- Leia sobre outras jornadas de migração da AWS para o Google Cloud .
- Saiba como comparar os serviços da AWS e do Azure com o Google Cloud.
- Saiba quando buscar ajuda para suas migrações.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.
Colaboradores
Autor: Marco Ferrari | Arquiteto de soluções na nuvem