Cerca de 7 anos atrás, os primeiros projetos foram movidos para a nossa nuvem de maneira simples e despretensiosa. Imagens de máquinas virtuais foram carregadas em um servidor FTP ou trazidas para discos rígidos. Em seguida, por meio de um servidor de importação especial, as VMs foram carregadas na nuvem.
Se não for um problema para o cliente desligar a máquina virtual por um dia ou dois (ou não outras opções), é possível. Mas se o tempo de inatividade for de no máximo uma hora, esse método não funcionará. Hoje, mostrarei quais ferramentas o ajudarão a migrar para a nuvem com um tempo de inatividade mínimo e como o processo de migração funciona conosco.
Migrando com o Veeam Backup and Replication
Todo mundo conhece o Veeam Backup and Replication como uma ferramenta para criar backups e réplicas. Nós o usamos para a migração entre nossos sites e para transportar clientes com virtualização privada para nossa nuvem. As máquinas virtuais clientes são replicadas no vCenter, após as quais o engenheiro as adiciona ao vCloud Director.
A replicação primária é realizada em uma máquina virtual ativada. No 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. Depois disso, a máquina virtual já inicia em nossa nuvem.
Normalmente, a partir do momento em que a máquina é desligada na infraestrutura do cliente e até o momento em que é ligada, não mais de meia hora, mas 15 a 20 minutos, passam em nossa nuvem.
Ao mesmo tempo, a máquina virtual original permanece no site do cliente. Se de repente algo der errado, você sempre poderá reverter e ligá-lo. Para o cliente, esse método também é conveniente, pois não exige dele o Veeam.
Caso 1
O cliente tinha sua própria infraestrutura virtual baseada no VMware - 40 VMs com capacidade de 30 TB. O equipamento no qual o cluster foi implantado já está desatualizado e o cliente decidiu não se envolver na compra de um novo e migrar para uma nuvem pública. O requisito para o tempo de inatividade de sistemas críticos não passava de uma hora. A Veeam Replication foi escolhida como ferramenta. A vantagem também foi que o provedor de Internet do cliente estava presente em nosso data center, o que nos permitiu organizar um bom canal. A migração levou cerca de um mês, enquanto a troca era simples, levou até 30 minutos para um grupo de máquinas virtuais.Migrar com o Veeam Cloud Connect
O Veeam Cloud Connect é uma ferramenta que ajuda a configurar a replicação da máquina virtual e executar réplicas na nuvem do provedor de serviços. Após a atualização em
2019 , tornou-se possível replicar máquinas virtuais diretamente no vCloud Director. A única condição é que, no lado do cliente, o Veeam Backup and Replication deva ser implantado pelo menos na versão 9. Em resumo (uma versão detalhada está
aqui ), todo o processo é o seguinte.
O VCloud Director cria uma organização com os recursos e redes necessários. No Veeam Cloud Connect, criamos uma conta, o cliente se conecta a ela no Veeam B&R, seleciona o provedor e a organização do DataLine e configura tarefas para replicação. Além do fato de que durante 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 gerencia todo o processo de forma independente: ele cria tarefas de replicação, a replicação em si, desliga as máquinas e inicia o início em um novo site.
Caso 2
A infraestrutura do cliente de onde a migração foi planejada estava localizada na Bielorrússia. Era necessário transportar 90 VMs com um volume total de 27 TB, apesar do canal da Internet ter 100 Mbps. Se você fizer um backup e enviá-lo imediatamente para a nossa nuvem, em algumas VMs, isso levará vários dias. Durante esse período, um grande delta aumentaria na VM e isso já poderia afetar adversamente o desempenho das máquinas ou, pior ainda, o local no armazenamento de dados se esgotou. Eles agiram da seguinte maneira: primeiro, o cliente fez um backup completo local e nos transferiu uma cópia para nós na nuvem via Veeam Cloud Connect. Então ele fez e jogou o incremento na nuvem. A máquina virtual original continuou a funcionar. Depois de desligar a VM, o cliente fez outro incremento e também o transferiu para a nuvem. Do nosso lado, implantamos uma máquina virtual a partir de um backup completo e, em seguida, fizemos dois incrementos nela. Esse esquema nos permitiu minimizar o tempo de inatividade para 2 horas ao mudar para o nosso site.Migração com disponibilidade do VMware vCloud
Em março deste ano, a VMware lançou o vCloud Availability 3.0, que permite a migração de máquinas virtuais entre nuvens diferentes (vCloud Director - vCloud Director) e da virtualização de cliente privado para a nuvem (vCenter - vCloud Director). A principal conveniência é a integração com a interface do vCloud Director. Isso simplifica bastante o gerenciamento de replicação e minimiza o tempo de inatividade ao alternar.
Usando essa ferramenta, migramos um dos clientes da nossa nuvem de Moscou para a nossa nuvem em São Petersburgo. Era necessário transportar 18 máquinas virtuais com uma capacidade total de 14 TB. Para o cliente, uma organização foi criada na nuvem de São Petersburgo e as redes necessárias foram organizadas. Em seguida, na interface do vCloud Director, o cliente mudou para as configurações de disponibilidade do vCloud, criou tarefas de replicação e mudou para o site de São Petersburgo em um momento conveniente. O tempo de inatividade quando a troca foi de 12 minutos.
O esquema de migração entre as nuvens do DataLine em São Petersburgo e Moscou.O VCloud Availability possui um mecanismo para migrar VMs de um site cliente para nossa nuvem. Para fazer isso, um aplicativo especial de disponibilidade do vCloud é implantado no cliente vCenter. Após uma configuração simples, você está conectado à nuvem e as tarefas de migração são configuradas. O cliente também gerencia independentemente todo o processo e o tempo de migração é minimizado.
Um diagrama da migração de máquinas virtuais de uma instalação privada para a nuvem.O VMware vCloud Availability tem muitos outros casos de uso; falaremos sobre eles em um artigo separado em breve.
Preparando para a migração
Para selecionar uma ferramenta e realmente prosseguir com a migração, você precisa decidir sobre os seguintes pontos:
De onde estamos migrando. Se você estiver migrando de uma solução privada, terá total liberdade na escolha de ferramentas. Se você sair do provedor, é mais difícil. Provavelmente, conectar a infraestrutura dos dois provedores e simplesmente arrastar a VM falhará por motivos de segurança. Às vezes, o provedor, que o cliente recusará, começa completamente a ser prejudicial e leva tempo. Você pode deixar o provedor à moda antiga: fazendo o upload da VM para discos e FTP ou migrando no nível do aplicativo. O nome deste último é arbitrário e se parece com isso.
Caso 3
Era necessário migrar o sistema SAP do cliente de um provedor europeu: 34 VMs com um volume de 54 Tb. Os recursos foram alocados para o cliente em nossa nuvem. Entre nós e a infraestrutura do provedor europeu estava organizada a conectividade de rede. Os servidores de aplicativos foram reimplantados, com o roll-up das configurações necessárias. Grandes bancos de dados migrados através do upload de backups para a nossa nuvem. Em seguida, a replicação entre os bancos de dados em nossos sites e nos sites de origem foi configurada. No horário combinado, mudamos para os bancos de dados em nossa nuvem.A quantidade de dados e o canal da Internet. Normalmente, solicitamos ao cliente que forneça descarga nos sistemas com parâmetros de memória, CPU, discos. Estimamos se o canal é suficiente para enviar diretamente réplicas ou backups de máquinas virtuais.
Simples válido. Para sistemas diferentes e, consequentemente, máquinas virtuais, pode ser diferente dependendo da sua importância para os negócios. Normalmente, um 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 certos. Tentamos planejar a mudança final para noite ou fim de semana, para que até um pequeno tempo de inatividade não seja perceptível para os usuários finais do cliente.
Com base nesses dados, você pode escolher uma ferramenta e prosseguir com a migração. Aqui está o que acontece a seguir.
- Configurando a conectividade de rede. Organizamos a conectividade de rede entre nossa nuvem e a infraestrutura do cliente. Máquinas virtuais serão copiadas nesta rede. Se o Veeam Backup and Replication for usado, esse será um canal dedicado, menos comumente um canal VPN. Se o Veeam Cloud Connect, tudo passa pela Internet ou pelo mesmo canal dedicado.
Em seguida, a rede está configurada para a VM na nuvem. Carros geralmente se movem em grupos e mais de um dia. Depois que as VMs foram transferidas para nós e lançadas, elas devem interagir com as máquinas que ainda permanecem no local de partida. - Agenda de migração. Quando há muitos carros, é razoável dividi-los em grupos e transportá-los em lotes. Juntamente com o cliente, concordamos com um plano no qual prescrevemos quando e quais máquinas serão movidas e quando a replicação final e a mudança para um novo site serão executadas.
- Teste a migração. Migramos a máquina virtual de teste e verificamos se tudo está configurado corretamente: conectividade de rede entre sites, disponibilidade da máquina virtual para máquinas no site de origem, direitos de conta e muito mais. Esse teste ajuda a evitar problemas durante a fase de migração de combate.
Isso é tudo para mim. Faça perguntas nos comentários e fale sobre sua experiência de migração.