Cerca de 7 anos atrás, os primeiros projetos eram migrados para nossa nuvem de forma simples e direta. As imagens das máquinas virtuais eram carregadas em um servidor FTP ou trazidas em discos rígidos. Depois, através de um servidor de importação especial, as VMs eram carregadas na nuvem.
Se para o cliente não for um problema desligar a virtualização por um ou dois dias (ou se não houver outras opções), então pode-se fazer assim. Mas se o tempo de inatividade deve ser no máximo uma hora, esse método não é adequado. Hoje vou falar sobre as ferramentas que ajudam a migrar para a nuvem com o mínimo de downtime e sobre como funciona o próprio processo de migração conosco.
Migração com Veeam Backup and Replication
Veeam Backup and Replication é conhecido por todos como uma ferramenta para criar backups e réplicas. Nós o utilizamos para migração entre nossas plataformas e para trazer clientes da virtualização privada para nossa nuvem. As máquinas virtuais dos clientes são replicadas em nosso vCenter e, em seguida, o engenheiro as adiciona ao vCloud Director.
A replicação inicial é realizada com a máquina virtual ligada. Em um horário combinado, a máquina do lado do cliente é desligada. A replicação é iniciada novamente para transferir as alterações que ocorreram desde a primeira replicação. Após isso, a máquina virtual inicia na nossa nuvem.
Geralmente, desde o momento em que a máquina é desligada na infraestrutura do cliente até o momento em que é iniciada na nossa nuvem, não passa de meia hora, e sim, em média, de 15 a 20 minutos.
Nesse meio tempo, a máquina virtual original permanece na infraestrutura do cliente. Se, por acaso, algo der errado, sempre é possível reverter e ligá-la novamente. Para o cliente, essa abordagem também é conveniente, pois não requer a presença do Veeam.
Caso 1
O cliente tinha sua própria infraestrutura virtual baseada em VMware – 40 VMs com um total de 30 TB. O equipamento em que o cluster estava implantado já estava obsoleto, e o cliente decidiu não se envolver na compra de novo hardware e migrar para a nuvem pública. A exigência para o downtime dos sistemas críticos era de no máximo uma hora. Como ferramenta, escolheram o Veeam Replication. Outro ponto positivo foi que o provedor de internet do cliente estava presente em nosso data center, o que possibilitou a organização de um bom canal. A migração levou cerca de um mês, e o downtime durante a troca foi de até 30 minutos para um grupo de máquinas virtuais.
Migração usando Veeam Cloud Connect
Veeam Cloud Connect – uma ferramenta que ajuda a configurar a replicação de máquinas virtuais e a iniciar réplicas na nuvem do provedor de serviços. Após a atualização em ano, passou a ser possível replicar máquinas virtuais diretamente para o vCloud Director. A única condição é que o cliente deve ter sua própria Veeam Backup and Replication instalada na versão 9 ou superior. Em resumo (versão detalhada ), todo o processo é o seguinte.
No vCloud Director, cria-se uma organização com os recursos e redes necessários. No Veeam Cloud Connect, criamos uma conta, o cliente se conecta a ela a partir do seu Veeam B&R, escolhe o provedor DataLine e a organização, e configura as tarefas de replicação. Além de que, com essa migração, o tempo de inatividade será de 15 a 20 minutos, o cliente não depende do suporte técnico do provedor e controla todo o processo de forma autônoma: cria tarefas de replicação, realiza a replicação, desliga as máquinas e inicia suas operações na nova plataforma.
Caso 2
A infraestrutura do cliente, de onde a migração estava planejada, estava localizada na Bielorrússia. Era necessário transferir 90 VMs com um volume total de 27 TB, sendo que a conexão de internet era de 100 Mbit/s. Se fizesse um backup e imediatamente o carregasse em nossa nuvem, para algumas VMs isso levaria vários dias. Nesse tempo, a VM teria uma grande delta, o que poderia afetar negativamente o desempenho das máquinas ou, pior ainda, esgotar o espaço no datastore. Procedemos da seguinte forma: primeiro, o cliente fez um backup completo local e transferiu uma cópia para nossa nuvem através do Veeam Cloud Connect. Depois fez e transferiu um incremental para a nuvem. A máquina virtual original continuou funcionando. Após desligar a VM, o cliente fez mais um incremental e também transferiu para a nuvem. Do nosso lado, implantamos uma máquina virtual a partir do backup completo e depois implementamos os dois incrementais. Este esquema permitiu, ao final, minimizar a inatividade para 2 horas durante a transição para nossa plataforma.
Migração usando VMware vCloud Availability
Em março deste ano, a VMware lançou o vCloud Availability 3.0, que permite migrar máquinas virtuais entre diferentes nuvens (vCloud Director – vCloud Director) e de ambientes de virtualização privados dos clientes para a nuvem (vCenter – vCloud Director). A principal conveniência é a integração com a interface do vCloud Director. Isso simplifica significativamente o processo de gerenciamento de replicação e minimiza o tempo de inatividade durante a troca.
Com essa ferramenta, migramos um de nossos clientes da nossa nuvem em Moscovo para nossa nuvem em São Petersburgo. Precisávamos transferir 18 máquinas virtuais com capacidade total de 14 TB. Uma organização foi criada para o cliente na nuvem de São Petersburgo e as redes necessárias foram estabelecidas. Em seguida, através da interface do vCloud Director, o cliente acessou as configurações do vCloud Availability, criou tarefas de replicação e, no momento conveniente, fez a troca para a localização de São Petersburgo. O tempo de inatividade durante a troca foi de 12 minutos.
Diagrama de migração entre as nuvens DataLine em São Petersburgo e Moscovo.
No vCloud Availability, existe um mecanismo para migrar VMs do ambiente do cliente para a nossa nuvem. Para isso, um appliance específico do vCloud Availability é implantado no vCenter do cliente. Após uma configuração simples, a conexão com a nuvem é realizada e as tarefas de migração são configuradas. O cliente também gerencia todo o processo de forma independente, e o tempo de migração é reduzido ao mínimo.
Diagrama de migração de máquinas virtuais de uma instalação privada para a nuvem.
O VMware vCloud Availability possui muitos outros cenários de uso; em breve contaremos mais sobre eles em um artigo separado.
Preparação para a migração
Para escolher a ferramenta e realmente iniciar a migração, é preciso definir os seguintes pontos:
De onde estamos migrando. Se você está migrando de uma solução privada, tem total liberdade na escolha das ferramentas. Se estiver saindo de um provedor, a situação é mais complicada. Muito provavelmente, não será possível conectar as infraestruturas de dois provedores e simplesmente transferir a VM por questões de segurança. Às vezes, o provedor do qual o cliente está tentando sair começa a dificultar as coisas e a arrastar o tempo. Sair de um provedor pode ser feito da maneira tradicional: por meio da exportação da VM para discos e FTP, ou migrar no nível de aplicação. O nome deste último é provisório, e se parece mais ou menos assim.
Caso 3
Era necessário migrar o sistema SAP do cliente de um provedor europeu: 34 VMs com um volume de 54 TB. Foram alocados recursos em nossa nuvem para o cliente. Uma conectividade de rede foi estabelecida entre nós e a infraestrutura do provedor europeu. Os servidores de aplicativos foram reimplantados, com as configurações necessárias aplicadas. Grandes bancos de dados foram migrados através do envio de backups para nossa nuvem. Em seguida, foi configurada a replicação entre os bancos de dados em nossa e na origem. No horário acordado, fizemos a transição para os bancos de dados em nossa nuvem.
Volume de dados e canal de internet. Normalmente, pedimos ao cliente que forneça uma extração dos sistemas com parâmetros de memória, CPU e discos. Avaliamos se o canal é suficiente para enviar diretamente as réplicas ou backups das máquinas virtuais.
Tempo de inatividade aceitável. Para diferentes sistemas e, consequentemente, máquinas virtuais, esse tempo pode variar dependendo da criticidade para os negócios. Geralmente, o cliente vem com requisitos prontos para o tempo de inatividade durante a migração, e com base nisso escolhemos a ferramenta e o plano de migração adequados. Tentamos agendar a transição final para a noite ou fins de semana, para que até mesmo um pequeno tempo de inatividade não seja perceptível para os usuários finais do cliente.
Com base nesses dados, podemos escolher a ferramenta e iniciar a migração. Aqui está o que acontece a seguir.
- Configuração da conectividade de rede. Organizamos a conectividade de rede entre nossa nuvem e a infraestrutura do cliente. É através dessa rede que as máquinas virtuais serão copiadas. Se for utilizado o Veeam Backup and Replication, trata-se de um canal dedicado, raramente um canal VPN. Se estiver usando o Veeam Cloud Connect, tudo acontece pela internet ou pelo mesmo canal dedicado.
Em seguida, a rede para as VMs na nuvem é configurada. As máquinas geralmente são transferidas em grupos e não em um único dia. Após as VMs serem transferidas para nós e iniciadas, elas devem interagir com as máquinas que ainda permanecem na origem.
- Cronograma de migração. Quando há muitas máquinas, é sensato dividi-las em grupos e transportá-las em lotes. Em conjunto com o cliente, acordamos um plano detalhado, no qual especificamos quando e quais máquinas serão transferidas e quando a replicação final e a transição para a nova localização serão realizadas.
- Migração de teste. Estamos migrando a máquina virtual de teste e verificando se tudo está configurado corretamente: conectividade de rede entre as plataformas, acessibilidade da máquina virtual para as máquinas na plataforma de origem, permissões da conta e outras configurações. Este teste ajuda a evitar atrasos na fase de migração ao vivo.
Isso é tudo por agora. Deixe suas perguntas nos comentários e compartilhe sua experiência de migração.
Fonte: habr.com
