Migração para o Google Cloud: práticas recomendadas para validar um plano de migração

Last reviewed 2023-11-29 UTC

Neste documento, descrevemos as práticas recomendadas para validar o plano a fim de migrar suas cargas de trabalho para o Google Cloud. Neste documento, não listamos todas as possíveis práticas recomendadas para validar um plano de migração, nem fornecemos garantias de sucesso. Em vez disso, ele ajuda a estimular discussões sobre possíveis alterações e melhorias no plano de migração.

Este documento é útil se você estiver planejando uma migração de um ambiente local, de um ambiente de hospedagem particular ou de outro provedor de nuvem para o Google Cloud. Este documento também é útil se você estiver avaliando a oportunidade de migrar e quiser saber como funciona esse processo.

Este documento faz parte da série de várias partes a seguir sobre a migração para o Google Cloud:

Avaliação

Realizar uma avaliação completa das cargas de trabalho e dos ambientes ajuda a garantir uma compreensão profunda das cargas de trabalho e dos ambientes. Desenvolver esse entendimento ajuda a minimizar os riscos dos problemas que ocorrem durante e após a migração para o Google Cloud.

Fazer uma avaliação completa

Antes de prosseguir para as etapas que seguem a fase de avaliação, conclua a avaliação das cargas de trabalho e dos ambientes. Para fazer uma avaliação completa, considere os seguintes itens, que geralmente são ignorados:

  • Inventário: verifique se o inventário das cargas de trabalho a serem migradas está atualizado e se você concluiu a avaliação. Por exemplo, pense em como os dados de origem são atualizados e confiáveis para sua avaliação e quais lacunas podem existir nos dados.

  • Inatividade: avalie quais cargas de trabalho podem ter um tempo de inatividade e o período máximo de tempo que essas inatividades podem ter. A migração de cargas de trabalho com zero ou quase zero inatividade é mais difícil do que migrar cargas de trabalho que podem oferecer inatividade. Para concluir uma migração sem inatividade, é necessário projetar e implementar redundância para cada carga de trabalho a ser migrada. Você também precisa coordenar essas instâncias redundantes.

    Ao avaliar o tempo de inatividade de uma carga de trabalho, avalie se o benefício comercial de uma migração sem inatividade é maior do que a complexidade de migração adicionada. Sempre que possível, evite criar um requisito de inatividade zero para uma carga de trabalho.

  • Clustering e redundância: avalie quais cargas de trabalho são compatíveis com clustering e redundância. Se uma carga de trabalho for compatível com clustering e redundância, é possível implantar várias instâncias dessa carga de trabalho, mesmo em diferentes ambientes, como o ambiente de origem e o de destino. As implantações em cluster e redundantes podem simplificar a migração porque essas cargas de trabalho se comunicam entre si com intervenção limitada.

  • Atualizações de configuração: avalie como atualizar a configuração das cargas de trabalho. Por exemplo, considere como você fornece atualizações para a configuração de cada carga de trabalho que quer migrar. Essa consideração é fundamental para o sucesso da migração, porque talvez seja necessário atualizar a configuração das cargas de trabalho enquanto as migra para o ambiente de destino.

  • Gere vários relatórios de avaliação: durante a fase de avaliação, pode ser útil gerar mais de um relatório para considerar diferentes cenários. Por exemplo, é possível gerar relatórios para considerar diferentes perfis de carga para suas cargas de trabalho, como horários de pico e sem pico.

Avaliar os modos de falha suportados por suas cargas de trabalho

Saber como as cargas de trabalho se comportam em circunstâncias excepcionais ajuda a garantir que você não as exponha às condições em que não é possível recuperá-las. Como parte da avaliação, colete informações sobre os modos de falha e os efeitos deles que são compatíveis com as cargas de trabalho e que podem ser recuperados automaticamente e quais modos de falha precisam da sua intervenção. Por exemplo, comece considerando perguntas sobre possíveis modos de falha, como:

  • O que acontece se uma carga de trabalho perder a conectividade com a rede?
  • Uma carga de trabalho pode retomar o trabalho de onde parou depois de ser interrompida?
  • O que acontece se o desempenho de uma carga de trabalho ou das dependências dela for inadequado?
  • O que acontece se houver duas cargas de trabalho com o mesmo identificador na arquitetura?
  • O que acontece se uma tarefa programada não for executada?
  • O que acontece quando duas cargas de trabalho processam a mesma solicitação?

Outra fonte de modos de falha incompatíveis é o próprio plano de migração. Determine se o plano de migração inclui etapas que dependem do sucesso de uma condição específica e se ela inclui contingências caso a condição não seja atendida. Um plano que inclui esses tipos de condições pode indicar que o próprio plano pode falhar ou que componentes individuais podem falhar durante a migração.

Depois de avaliar esses modos de falha e os efeitos deles, valide suas descobertas em um ambiente não crítico simulando falhas e injetando falhas que emulem esses modos de falha. Por exemplo, se uma carga de trabalho for projetada para ser recuperada automaticamente após uma perda de conectividade de rede, valide a recuperação automática interrompendo de forma forçada a conectividade e restaurando-a posteriormente.

Avaliar os pipelines de processamento de dados

A avaliação da carga de trabalho precisará responder às seguintes perguntas:

  • Os recursos são dimensionados corretamente para a migração?
  • Quanto tempo é necessário para migrar os dados necessários para suas cargas de trabalho?
  • O ambiente de destino pode acomodar o volume total de dados?
  • Como suas cargas de trabalho se comportam quando precisam acomodar picos de demanda ou picos na quantidade de dados que produzem em uma determinada janela de tempo?
  • Se houver picos de demanda ou na quantidade de dados produzidos pelas cargas de trabalho, haverá algum efeito adverso, como aumento de latência ou atrasos nas respostas?
  • Após o início das cargas de trabalho, elas precisam de tempo para alcançar os níveis de desempenho esperados?

Os resultados dessa avaliação costumam ser modelos da demanda que as cargas de trabalho satisfazem e os dados que as cargas de trabalho produzem em uma determinada janela de tempo. Ao reunir pontos de dados para produzir esses modelos, lembre-se de que esses pontos de dados podem variar significativamente entre as janelas de horário de pico e sem pico. Para mais informações sobre como e o que monitorar, consulte Objetivos de nível de serviço no manual de engenharia de confiabilidade do site.

Atualizar e implantar cada carga de trabalho para migrar

Durante a migração, talvez seja necessário atualizar algumas das cargas de trabalho que você está migrando. Por exemplo, talvez seja necessário implantar uma correção para um problema ou reverter uma alteração recente que esteja causando um problema. Para cada carga de trabalho que você está migrando, verifique se é possível aplicar e implantar as alterações. Por exemplo, se você estiver migrando uma carga de trabalho para a qual tem o código-fonte, verifique se é possível acessar o código-fonte e criar, empacotar e implantar o código-fonte como necessário.

A migração pode incluir cargas de trabalho que não é possível aplicar e implantar alterações (como software reservado). Nesse cenário, refatore o plano de migração para considerar mais esforços para reduzir os problemas que podem ocorrer após a migração dessas cargas de trabalho.

Avaliar a infraestrutura da sua rede

Uma infraestrutura de rede funcional é fundamental para a migração. É possível usar a infraestrutura de rede como parte das ferramentas de migração. Por exemplo, é possível usar balanceadores de carga e servidores DNS para direcionar o tráfego de acordo com o plano de migração.

Para evitar problemas durante a migração, é importante avaliar sua infraestrutura de rede e avaliar até que ponto ela pode ser compatível com a migração. Por exemplo, comece considerando perguntas sobre a infraestrutura de balanceamento de carga, como as seguintes:

  • O que acontece quando você reconfigura seus balanceadores de carga?
  • Quanto tempo leva para que a configuração atualizada seja aplicada?
  • Na migração sem inatividade, o que acontece se você receber um pico de tráfego antes que a configuração atualizada esteja em vigor?

Depois de considerar as perguntas sobre a infraestrutura do balanceamento de carga, considere as perguntas sobre a infraestrutura do DNS, como as seguintes:

  • Quais registros DNS você precisa atualizar para apontá-los para o ambiente de destino e quando eles precisam ser atualizados?
  • Quais clientes estão usando esses registros DNS?
  • Como é configurado o time to live (TTL) dos registros DNS a serem atualizados?
  • É possível definir o TTL do registro DNS para o mínimo durante a migração?
  • Seus clientes DNS respeitam o TTL dos registros DNS a serem atualizados? Por exemplo, seus aplicativos têm cache de DNS do lado do cliente que ignora o TTL configurado para a migração?

Planejamento de migração

Planejar cuidadosamente a migração ajuda a evitar problemas durante e após a migração. O planejamento também ajuda a evitar o esforço para lidar com tarefas inesperadas.

Desenvolver uma estratégia de reversão para cada etapa do plano de migração

Durante a migração, qualquer etapa do plano de migração que você executar pode resultar em problemas inesperados. Para garantir que você possa se recuperar desses problemas, prepare uma estratégia de reversão para cada etapa do plano de migração. Para evitar perder tempo durante uma interrupção, faça o seguinte:

  • Verifique se suas estratégias de reversão funcionam analisando e testando periodicamente cada estratégia de reversão.
  • Defina o tempo máximo de execução permitido para cada etapa da migração. Depois que esse tempo de execução permitido expirar, suas equipes começarão a reverter a etapa de migração.

Mesmo que você tenha estratégias de reversão prontas para cada etapa do plano de migração, algumas delas ainda podem ser prejudiciais. Uma etapa potencialmente disruptiva pode causar algum tipo de perda, mesmo que você a reverta, como a perda de dados. Avalie quais etapas do plano de migração são potencialmente disruptivas.

Se você automatizou qualquer etapa do plano de migração, certifique-se de ter um procedimento pré-planejado para cada etapa automatizada, se houver uma falha na automação. Assim como acontece com as estratégias de reversão, analise e teste periodicamente cada procedimento planejado.

Se você configurar canais de comunicação como parte da migração, para garantir que o acesso ao ambiente não seja bloqueado, provisione canais de backup que possam ser usados para se recuperar de uma falha. Por exemplo, se você estiver configurando a Interconexão por parceiro, durante a migração, também poderá configurar um acesso de backup pela Internet pública, caso haja algum problema durante o provisionamento e a configuração.

Planejar lançamentos e implantações graduais

Para reduzir o escopo dos problemas que podem ocorrer durante a migração, evite alterações em grande escala e crie seu plano de migração para implantar as alterações de modo gradual. Por exemplo, planeje implantações graduais e mudanças de configuração.

Se você planeja lançamentos graduais, para diminuir o risco de problemas inesperados causados pela aplicação das alterações, minimize o número e o tamanho dessas alterações. Depois de identificar e resolver problemas na primeira implementação pequena, faça os lançamentos subsequentes para alterações semelhantes em escalas maiores.

Equipes de desenvolvimento e operações de alertas

Para reduzir o impacto dos problemas que podem ocorrer durante uma migração, alerte as equipes responsáveis por qualquer carga de trabalho a ser migrada. Além disso, alerte as equipes que são responsáveis pela infraestrutura dos ambientes de origem e de destino.

Se suas equipes trabalham em fusos horários diferentes, verifique o seguinte:

  • As equipes abrangem corretamente esses fusos horários e abrangem vários turnos consecutivos, porque podem não conseguir resolver problemas durante um único turno.
  • Suas equipes estão preparadas para coletar informações detalhadas sobre os problemas que elas podem enfrentar. Esta coleção fornece aos engenheiros no próximo turno o entendimento completo do que o turno anterior fez e porquê.
  • Pessoas específicas das suas equipes são responsáveis por qualquer turno.

Remover recursos de prova de conceito do ambiente de produção de destino

Como parte da avaliação, talvez você tenha usado o ambiente de destino para hospedar experimentos e provas de conceito. Antes da migração, remova todos os recursos que você criou durante esses experimentos e provas de conceito da área de produção do ambiente de destino.

É possível manter recursos em uma área que não seja de produção do ambiente de destino enquanto a migração estiver em andamento. Isso pode ajudar a coletar informações sobre qualquer problema que possa surgir durante a migração. Por exemplo, para diagnosticar problemas que afetam as cargas de trabalho de produção após a migração, compare os registros de configuração e de dados da carga de trabalho com os registros de configuração e de dados das provas de conceito e experimentos.

Depois de concluir a migração e validar se o ambiente de destino funciona conforme o esperado, é possível excluir os recursos na área de não produção do ambiente de destino.

Definir critérios para desativar o ambiente de origem com segurança

Para evitar o custo de executar dois ambientes indefinidamente, defina quais condições precisam ser atendidas para que você desative o ambiente de origem com segurança, como:

  • Todas as cargas de trabalho, incluindo os backups e os mecanismos de alta disponibilidade e recuperação de desastres, são migrados para o ambiente de destino.
  • Os dados migrados no ambiente de destino são consistentes, acessíveis e utilizáveis.
  • A precisão e a integridade dos dados migrados atendem ao padrão definido.
  • Os recursos que permanecem no ambiente de origem não são dependências de cargas de trabalho fora do escopo de migração.
  • O desempenho das cargas de trabalho no ambiente de destino atende às metas de SLA.
  • Os sistemas de monitoramento informam que não há tráfego de rede para o ambiente de origem que precisa ser direcionado para o ambiente de destino.
  • Depois que as cargas de trabalho estiverem em execução sem problemas no ambiente de destino por um período definido, você estará confiante de que não precisará mais da capacidade de voltar ao ambiente de origem.

Operações

Para gerenciar com eficiência o ambiente de origem e o ambiente de destino durante a migração, também é necessário criar os processos operacionais.

Monitorar os ambientes

Para observar como os ambientes de origem e de destino estão se comportando e ajudar a diagnosticar problemas conforme eles ocorrem, configure o seguinte:

  • Um sistema de monitoramento para coletar métricas úteis para seu cenário.
  • Um sistema de geração de registros para observar o fluxo de operações executado pelas cargas de trabalho e outros componentes dos ambientes.
  • Um sistema de alerta que avisa antes que ocorra um evento problemático.

O Google Cloud Observability é compatível com monitoramento, geração de registros e alertas integrados para o ambiente do Google Cloud.

Como uma carga de trabalho e as dependências dela abrangem vários ambientes, talvez seja necessário considerar o uso de várias ferramentas de monitoramento e alerta para diferentes ambientes. Considere o momento em que você migra as políticas de monitoramento e alerta compatíveis com as cargas de trabalho. Por exemplo, se o ambiente de origem estiver configurado para alertar quando um determinado servidor estiver inativo, o alerta será acionado quando você desativar esse servidor intencionalmente. O gatilho de alerta é esperado, mas não é um comportamento útil. Como parte da migração, você precisa ajustar continuamente os alertas para o ambiente de origem e reconfigurá-los para o ambiente de destino.

Gerenciar a migração

Para gerenciar a migração, analise o desempenho dela para coletar informações que podem ser usadas como retrospectiva após a conclusão. Depois de coletar informações, use-as para analisar o desempenho da migração e preparar pontos de dados sobre possíveis melhorias nos ambientes.

Por exemplo, para começar a planejar a migração, considere as seguintes perguntas:

  • Quanto tempo cada etapa do plano de migração levou?
  • Alguma etapa do plano de migração levou mais tempo para ser concluída do que o previsto?
  • Há etapas ou verificações que estavam faltando?
  • Ocorreram eventos adversos durante a migração?

A seguir