Práticas recomendadas da migração de máquinas virtuais para o Compute Engine

Neste artigo, encontre as orientações e práticas recomendadas da migração de cargas de trabalho de computação para o Google Cloud Platform.

Quando você migra uma carga de trabalho para a nuvem, é importante pensar em como lidar com os diferentes componentes da sua infraestrutura. As metodologias usadas para mover dados e bancos de dados são diferentes e, por sua vez, também são diferentes da usada para mover recursos de computação.

Ao avaliar uma migração para a nuvem, vários clientes encaram os custos como um fator importante. Com os descontos por uso prolongado (SUD, na sigla em inglês) das máquinas virtuais (VMs) do Google Compute Engine, os custos podem ficar muito mais baixos do que os do gerenciamento do hardware ou das máquinas virtuais de um data center tradicional. Ao migrar de uma outra nuvem para o Cloud Platform, você tira proveito dessas mesmas vantagens no preço.

Entretanto, o ganho mais perceptível para os clientes é a agilidade. Você cria máquinas virtuais quase instantaneamente, sem precisar esperar que os recursos sejam adquiridos e provisionados. Com as VMs na nuvem, é rápido colocar novos aplicativos em funcionamento na empresa, testá-los e desativá-los conforme necessário. Essa capacidade de testar, verificar as falhas e descobrir o que funciona em tão pouco tempo é uma enorme vantagem. Ela reduz o custo da inovação. Os vários grupos da sua empresa não precisam se preocupar em comprar e usar uma infraestrutura só para fazer um pequeno teste. Mesmo depois de usar diversos provedores de nuvem, os clientes logo percebem os benefícios de ter uma rede global e ágil, além de um tempo de inicialização rápido nas VMs.

Por fim, muitos clientes tiram proveito da possibilidade de consolidar as despesas indiretas. Geralmente, data centers requerem diversos fornecedores, cada um com os próprios contratos, relacionamento e modelo de faturamento. Você reduz de modo significativo as despesas indiretas quando muda para a nuvem. Sua equipe não precisa mais lidar com os custos de gerenciamento de um data center. Em vez disso, todos os funcionários se concentram no sucesso do negócio.

Uma vez que a maioria das cargas de trabalho técnicas requerem recursos de computação ou compute, este artigo se concentra nas tarefas necessárias para a migração das VMs e nas práticas recomendadas. Entretanto, como a computação é essencial para a maior parte das cargas de trabalho, é necessário discutir outros assuntos relacionados ao funcionamento dos aplicativos, por exemplo, bancos de dados, mensagens e análise.

O processo não se resume a uma única etapa gigante. Nas seções a seguir, veja a descrição das etapas recomendadas.

Como calcular os custos

A primeira etapa, antes de mover as VMs, é calcular o custo da mudança. Isso significa avaliar o que você está executando atualmente nos data centers. Não é apenas o custo das máquinas físicas. Ele também inclui a estrutura da rede, energia, refrigeração, equipe e leasing dos data centers.

Ao calcular esses custos, você precisa ter um modelo para a nuvem. Considere essas questões:

  • Qual tipo de sistema operacional você usará? Ele requer uma licença?
  • Quais tipos de máquinas virtuais você usará? Há uma variedade de tamanhos e custos. Você precisa ter uma ideia dos requisitos de desempenho do seu aplicativo.
  • Além das máquinas virtuais, quais outros serviços são necessários para seu aplicativo e quanto eles custam?
  • Esses aplicativos requerem software licenciado? Quanto isso custará? Ele está disponível na nuvem?

Essas são todas as questões relacionadas ao custo que precisam ser planejadas antes de mover uma única VM. A equipe de vendas do Cloud Platform pode ajudá-lo a avaliar e calcular esses custos.

Se você já está usando um provedor de nuvem, esses cálculos podem ser diferentes. Por exemplo, você não precisa considerar o custo de leasing do data center. Mas os requisitos ainda são os mesmos. Antes de fazer a migração, é importante entender as diferenças entre os modelos de faturamento do provedor atual e do Google. Caso esteja migrando do Amazon Web Services (AWS), veja uma avaliação de preços das máquinas virtuais no blog do Cloud Platform.

Como avaliar os itens a serem migrados

Depois de avaliar o custo da mudança, comece a verificar o que será migrado. Nas empresas modernas, há vários tipos de aplicativos como os aplicativos voltados ao cliente, back office, ferramentas de desenvolvimento e experimentais. Fazer a migração de todos eles ao mesmo tempo e da mesma maneira não faz sentido.

Recomendamos classificar os aplicativos em três grandes repositórios:

  • Aplicativos fáceis de mover: eles têm menos dependências, são mais recentes, foram desenvolvidos internamente, ou seja, não têm licenças a serem consideradas, e são mais flexíveis em relação ao escalonamento e a outros padrões de nuvem.
  • Aplicativos difíceis de mover: eles têm muitas dependências, são menos flexíveis em relação ao escalonamento ou têm requisitos complexos de licenciamento.
  • Aplicativos que não podem ser movidos: alguns aplicativos que talvez não sejam bons candidatos para a migração são executados em hardware especializado ou mais antigo, têm requisitos regulatórios ou de negócio específicos que torna necessário mantê-los no seu data center ou têm requisitos complexos de licenciamento que não permitem movê-los para a nuvem.

Esses são apenas alguns exemplos de cada um desses três repositórios, mas é provável que haja mais fatores a serem considerados para essa decisão. A equipe de vendas do Cloud Platform pode ajudá-lo.

Todas essas considerações se aplicam à migração de um data center ou de outro provedor de nuvem.

Quando concluir esse trabalho, selecione os primeiros aplicativos a serem migrados. É altamente recomendável que você migre poucos aplicativos no início. Os primeiros servirão não somente como um modelo para as futuras migrações, mas também ajudarão você a definir os processos.

Como definir a migração

Ao decidir quais aplicativos mover, você antes precisa definir como será o ambiente da nuvem. A primeira etapa é descobrir como é o ambiente atual e compará-lo com o Cloud Platform. Na tabela a seguir, você tem uma visão geral da comparação:

Tipo de serviço Data center Google Cloud Platform
Computação Hardware físico, hardware virtual (VMWare ESXi, Hyper-V, KVM, XEN) Google Compute Engine
Armazenamento SAN, NAS, DAS Disco permanente, Google Cloud Storage
Rede MPLS, VPN, balanceamento de carga de hardware, DNS VPN do Google Cloud, Google Cloud Interconnect, balanceamento de carga do Compute Engine, Google Domains, Google Cloud DNS
Segurança Firewalls, NACLs, tabelas de roteamento, criptografia, IDS, SSL Firewalls, criptografia, IDS, SSL do Compute Engine
Identidade Active Directory, LDAP IAM, GCDS, LDAP
Gerenciamento Serviços de configuração, ferramentas de CI/CD Deployment Manager, serviços de configuração, ferramentas de integração/entrega contínuas (CI/CD, na sigla em inglês)

Caso esteja migrando do AWS, para comparar os serviços dele com o Cloud Platform, use o guia de comparação.

Após comparar os diversos serviços e compreender o que os seus aplicativos precisam e usam, comece a planejar como o ambiente precisa ficar no Cloud Platform.

Antes de migrar as VMs, você precisa criar o ambiente para o aplicativo. Nas seções a seguir, veja as etapas recomendadas.

Como definir a governança

Estabeleça quem na sua empresa tem permissão para criar, acessar, modificar e remover os recursos da nuvem. Além disso, determine como os recursos serão pagos. Encontre as orientações na documentação de práticas recomendadas do IAM.

Neste momento, determine também quem tem contas na nuvem. Talvez não seja necessário que todos da empresa, ou mesmo todos os desenvolvedores, tenham acesso direto. Estabeleça antecipadamente as contas e a política de criação e exclusão delas.

Como criar uma rede

Antes de mover as VMs, é preciso que a rede de destino exista. Da mesma forma que as permissões e contas, é importante criar essa rede antecipadamente, porque estabelecer procedimentos depois que os aplicativos estão em uso pode ser difícil.

Ao definir uma rede, saiba que ela não está sendo criada somente para um aplicativo, mas ela servirá como um padrão a ser seguido pela empresa. Responda as seguintes perguntas:

  • Você terá uma rede para cada aplicativo ou para cada ambiente?
  • Como os serviços compartilhados serão acessados pelos aplicativos?
  • Você usará um modelo hub e spoke ou uma malha completa de redes?
  • Como as várias redes serão conectadas?
  • Você usará uma conexão VPN entre elas ou uma Rede de projetos cruzados?

Com essa variedade de opções e as diferenças entre as empresas, é difícil prescrever um modelo que funcione para todas as situações. Nós apenas recomendamos que você avalie as necessidades e escolha uma estratégia antes de implantar os aplicativos.

A segunda metade da definição da rede é decidir como conectar os recursos existentes. O Google fornece várias opções diferentes de conexão, de acordo com as suas necessidades.

No mais básico, você cria uma conexão VPN entre os recursos existentes e o Google. Com este serviço, crie rotas estáticas ou dinâmicas entre os locais.

Se você precisa de uma conexão mais rápida, entre em contato com os parceiros do Cloud Interconnect. Eles ajudarão você a criar uma linha dedicada direta com o Google.

Por fim, uma opção é criar um link direto com o Google por meio de um dos vários locais de peering direto.

Como planejar as operações

Quando você tem aplicativos em execução na nuvem, é preciso monitorá-los, reter os registros e gerenciá-lo operacionalmente, como em qualquer sistema. Pense nessas operações como parte do seu planejamento.

Há várias ferramentas de configuração de terceiros disponíveis. Programas como Chef, Puppet e outros podem ajudá-lo. Se você já usa essas ferramentas, continue com elas no ambiente do Cloud Platform. Se esse não for o caso, é altamente recomendável avaliar o que funcionará melhor para você, de acordo com a maneira como os desenvolvedores e engenheiros operacionais trabalham. Elas trabalham e complementam o Google Cloud Deployment Manager, que nós recomendamos incorporar ao gerenciamento de implantação e operacional.

Uma decisão semelhante precisa ser tomada para o monitoramento e a geração de registros. Há várias ferramentas de terceiros que funcionam bem com o Cloud Platform. Se já você já usa uma ou mais delas, continue com elas. Caso contrário, considere uma variedade de ferramentas, incluindo o Google Stackdriver. Ele integra monitoramento, geração de registros e alertas em um único serviço.

Como iniciar a migração

Finalmente, migre seu primeiro aplicativo. A primeira migração servirá de modelo para as futuras migrações. Esse processo com certeza será refinado à medida que você fizer outras, mas é importante registrar tudo o que é feito especificamente nessa primeira vez.

Na seção a seguir, as arquiteturas em alto nível e as etapas necessárias para fazer a migração em cada cenário serão descritas.

Arquiteturas de migração

Em termos gerais, há três tipos de arquiteturas de migração que podem ser seguidas para cada aplicativo.

A primeira é refazer completamente o projeto de um aplicativo para a nuvem. Ainda que essa opção seja viável, ela está fora do escopo deste artigo, já que, essencialmente, ela corresponde ao caminho seguido para criar um novo aplicativo na nuvem.

Nas seções a seguir, a segunda e a terceira abordagens serão descritas.

Migração lift-and-shift

Essa abordagem geralmente é a maneira mais fácil de começar, uma vez que ela é a que requer menos alterações no aplicativo. Neste cenário, é preciso encerrar o aplicativo e copiar os dados e máquinas virtuais para a nuvem.

Como mover os dados

A primeira etapa de um lift-and-shift é mover os dados necessários para executar o aplicativo. Normalmente, eles são provenientes de banco de dados, mas também incluem recursos estáticos que podem ser movidos de um SAN para o armazenamento de objetos do Cloud Storage. Além disso, é necessário mover os dados locais usados pelo aplicativo para o Cloud Storage, para que o download deles seja feito nos discos permanentes do Compute Engine quando as máquinas virtuais são inicializadas.

Como mover as VMs

A próxima etapa é mover as VMs. Há várias maneiras de fazer isso. O Google fornece a documentação sobre como importar imagens manualmente. Também é possível usar um serviço de parceiro terceirizado, como o CloudEndure. Consulte Como usar o CloudEndure para saber mais informações.

Como testar o aplicativo

Depois de colocar os dados e as VMs no Cloud Platform, execute o aplicativo em modo de teste para garantir que ele tenha o comportamento esperado. Nesse teste, as métricas de desempenho precisam ser atendidas e o aplicativo verificado em relação à implantação, ao monitoramento e à geração de registros.

Como mover para a produção

A duração dessa etapa depende da natureza do aplicativo. A troca para o local onde o aplicativo da produção é executado quase sempre requer um período de inatividade dele. O método para que isso seja feito sem deixar o aplicativo off-line, do ponto de vista do usuário, está fora do escopo deste guia de práticas recomendadas.

Dois fatores determinam a duração:

  • Quanto tempo faz que você importou os dados originais?
  • Quanto tempo demora para as entradas de DNS serem atualizadas no front end do seu aplicativo?

Geralmente, você tem muito mais controle sobre o primeiro. Se é necessário que a janela de tempo para mover para a produção seja pequena, faça isso assim que possível após a importação dos dados.

Depois de determinar uma janela aceitável, siga estas etapas:

  1. Informe os usuários sobre a janela de manutenção.
  2. Encerre o aplicativo do local atual.
  3. Importe os dados ausentes para os locais apropriados no Cloud Platform.
  4. Troque as entradas DNS e ative o aplicativo na nuvem.

Se tudo funcionar, o aplicativo estará completamente migrado e os usuários conseguirão usá-lo novamente.

Migração híbrida

A terceira abordagem de arquitetura é a migração híbrida. Nesse caso, somente parte do aplicativo é movido para a nuvem, geralmente o front end e, possivelmente, a lógica do aplicativo. O back-end e os serviços associados permanecem com os outros recursos existentes. Essa migração é uma variação do lift-and-shift. Ela é útil para quando o aplicativo pode ser movido para a nuvem, mas alguns serviços de back-end não, e requer menos etapas que a lift-and-shift. Por exemplo, nessa arquitetura, o armazenamento de dados não seria movido para a nuvem.

Como determinar a conexão de rede

A primeira etapa é criar uma conexão rápida o suficiente entre os recursos existentes e o Cloud Platform. A maneira como essa conexão precisa ser depende inteiramente do perfil do aplicativo. Em alguns casos, uma VPN talvez atenda as necessidades. Em outros, uma linha dedicada e de alta velocidade pode ser necessária.

Como migrar as VMs

A próxima etapa é migrar as imagens da VM, de maneira semelhante ao cenário lift-and-shift. Novamente, neste momento, você precisa testar o aplicativo para verificar se ele tem o comportamento esperado na nuvem e se vincula novamente aos recursos existentes.

Como mover para a produção

Por fim, a janela de manutenção é muito menor neste caso, porque você não precisa migrar os dados. As seguintes etapas ainda são necessárias:

  1. Informar os usuários sobre a janela de manutenção.
  2. Desativar o aplicativo existente.
  3. Trocar as entradas DNS.
  4. Ativar o aplicativo na nuvem.

Se tudo funcionar, o aplicativo estará em execução no Cloud Platform. Nesse momento, os usuários poderão acessá-lo novamente.

Como usar o CloudEndure

CloudEndure é uma cadeia de ferramentas e um serviço on-line que facilita a migração de máquinas de uma plataforma para outra, com um tempo mínimo de inatividade e replicação contínua. A solução tem como base os seguintes pilares tecnológicos:

  • Agente de replicação contínua em nível de bloco: a metodologia do agente permite a migração de qualquer máquina física, virtual ou baseada em nuvem, independentemente da infraestrutura de origem. Com a metodologia no nível de bloco, tudo é movido, incluindo os dados do SO, patches, configurações, aplicativos, bancos de dados e assim por diante, além de eliminar os riscos envolvidos, por erro humano, de ausência de componentes importantes. Essa abordagem tem uma taxa extremamente alta de sucesso da migração para qualquer SO compatível, sem considerar o aplicativo. A replicação contínua garante que os dados estejam sempre sincronizados em tempo real, o que reduz as janelas de cutover, porque não é necessário verificar as alterações de dados periodicamente.
  • Mecanismo automatizado de conversão do sistema: permite que qualquer sistema de origem seja automática e rapidamente convertido para o formato do Cloud Platform durante a inicialização. Isso elimina o tempo significativo de inatividade envolvido na preparação manual dos sistemas para a migração. Com o mecanismo de conversão do CloudEndure, você garante que a máquina esteja pronta para o Compute Engine em questão de minutos, e ela é reativada no estado de replicação mais atualizado.
  • Orquestração automatizada de pilha do aplicativo: permite que os engenheiros do projeto de migração definam, com antecedência, para quais zonas e regiões cada máquina precisa ser migrada, bem como as quantidades de CPU e RAM necessárias para atender a essa carga de trabalho. No CloudEndure, as redes e discos em preparação para a migração também são pré-configurados.

Esses pilares reduzem os riscos principais e o tempo de inatividade envolvido nos projetos típicos de migração. Com eles, você executa o projeto com rapidez, confiança e segurança.

No CloudEndure, o processo de migração das máquinas virtuais envolvem estas etapas:

  1. Executar o agente do CloudEndure nas máquinas de origem.
  2. Monitorar o painel do CloudEndure até que a replicação seja concluída.
  3. Desativar a carga de trabalho nas máquinas de origem.
  4. Executar uma última sincronização incremental dos dados que podem ter sido alterados.
  5. Migrar os pontos de extremidade do serviço para as máquinas de destino recém-provisionadas no Compute Engine.

Para detalhes sobre como fazer uma migração de VM, consulte o tutorial Como migrar VMs para o Compute Engine.

Exemplos de casos de uso

Nesta seção, você encontra cinco maneiras que os clientes usaram para migrar rapidamente a carga de trabalho com o CloudEndure e tirar proveito do Compute Engine.

Como migrar várias cargas de trabalho em paralelo

Uma empresa de varejo foi adquirida e precisava mover toda a carga de trabalho para o Cloud Platform. O grupo de máquinas baseadas em Linux estava distribuído entre data centers locais e vários provedores de nuvem. A migração de algumas máquinas seria fácil, mas eles sabiam que mover o banco de dados e os dispositivos SAN com um tempo mínimo de inatividade seria um desafio. Cada minuto representaria perda de receita.

Com o CloudEndure, foi possível replicar continuamente todo o grupo em paralelo e fazer o upgrade dos kernels do Linux nas VMs de destino do Compute Engine. Eles migraram os volumes de armazenamento SAN diretamente para os discos permanentes do Compute Engine. Quando toda a replicação foi concluída, a janela de cutover tinha se reduzido a alguns minutos.

Como migrar cargas de trabalho do Windows em execução no VMWare

Uma empresa com vários data centers na Ásia tinha uma grande estrutura de máquinas virtuais do Windows em execução no VMware. Eles precisavam mover os servidores com Windows Server 2008 R2 e Windows Server 2012 R2 para o Cloud Platform, com um tempo mínimo de inatividade para os serviços críticos como o Active Directory e o Exchange.

Mesmo com a variedade de aplicativos e a mistura de versões do Windows, eles conseguiram usar a replicação no nível de disco do CloudEndure para aplicar a mesma abordagem de migração em todos os sistemas.

Como migrar um aplicativo grande de várias camadas

Uma empresa com um aplicativo grande de várias camadas queria migrar os servidores do data center para a nuvem. 90% da carga de trabalho local era virtual, e o cliente conhecia ferramentas que permitiriam mover, pouco a pouco, instantâneos dos discos virtuais para a nuvem e depois fazer modificações manuais no sistema para disponibilizar as máquinas na nuvem. Ainda que não fosse o ideal, porque o tempo de inatividade necessário para o cutover seria significativo, era possível. Entretanto, 10% da carga de trabalho era executada em servidores físicos que hospedavam bancos de dados críticos. Isso se mostrou um grande problema para a migração, porque o cliente não poderia usar metodologias baseadas em hipervisor para migrar esses servidores.

Com o agente agnóstico de infraestrutura e o mecanismo de conversão automatizada de máquinas do CloudEndure, o cliente conseguiu mover os servidores físicos e virtuais para a nuvem, usando o mesmo processo e ferramentas. Além disso, a abordagem de replicação no nível de disco do CloudEndure deixa o processo de migração idêntico entre todas as camadas do aplicativo. Com a replicação no nível de bloco, o tempo de inatividade do cutover foi reduzido a minutos, em vez de várias horas.

Como migrar um aplicativo atualizado com frequência

Uma empresa com uma carga de trabalho de aplicativo atualizada com frequência queria migrar para a nuvem. Inicialmente, o cliente configurou sistemas predefinidos e em espera na nuvem e tentou mover os dados do aplicativo de origem para esses sistemas de destino. Eles planejavam promover os aplicativos em estado de espera a primários posteriormente. Entretanto, mover os dados e mantê-los sincronizados se mostrou um desafio que consumia muito tempo, porque o aplicativo de origem e o SO continuavam a ser atualizados com frequência. A preocupação do cliente aumentou porque alguns patches e alterações no aplicativo não seriam aplicados durante a fase de cutover, causando uma interrupção.

Com a abordagem de replicação no nível de bloco do CloudEndure, esse problema foi solucionado. No CloudEndure, todos os blocos de disco são replicados de modo consistente. Isso significa que os discos de destino ficariam não somente com os dados mais atualizados do aplicativo, mas também os patches do SO, as atualizações, a configuração do aplicativo e outros permaneceriam intactos.

Como migrar de vários data centers

Uma empresa com vários data centers, tanto locais quanto compartilhados, precisava consolidar todos eles como parte de uma migração para a nuvem. Junto com os desafios típicos de mover aplicativos de uma infraestrutura para outra, o cliente também precisava se preocupar com a rede. Alguns aplicativos usavam um espaço de IPs privados e idênticos em várias redes separadas, o que resultaria em conflitos quando fossem migrados para uma única rede consolidada e baseada em nuvem. Estava claro que algumas alterações de rede seriam necessárias na nuvem antes da migração. Era crítico fazer e testar essas alterações de maneira fácil, sem interrupções.

Com o mecanismo de blueprint da máquina de destino do CloudEndure, o cliente definiu e redefiniu, tanto quanto necessário, como as configurações de rede do servidor de destino seriam provisionadas na nuvem. Após cada iteração de configuração de blueprint, o cliente conseguiu testar ativamente os servidores de destino em uma rede isolada da nuvem, e verificou o comportamento deles sem causar impactos nos servidores de origem. Quando todos os critérios foram atendidos, a janela do cutover foi programada e ele foi executado com alta previsibilidade e baixo risco.

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…