Há cerca de 7 anos, os primeiros projetos migraram para a nossa nuvem de forma simples e despretensiosa. Imagens de máquinas virtuais foram carregadas em um servidor FTP ou entregues em discos rígidos. Depois, através de um servidor de importação especial, as VMs foram carregadas na nuvem.
Se não for problema para o cliente desligar a máquina virtual por um ou dois dias (ou não houver outras opções), isso pode ser feito. Mas se o tempo de inatividade for de no máximo uma hora, esse método não funcionará. Hoje vou contar quais ferramentas irão ajudá-lo a migrar para a nuvem com o mínimo de tempo de inatividade e como funciona o nosso processo de migração em si.
Migração com 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 migração entre nossos sites e para transportar clientes da virtualização privada para nossa nuvem. As máquinas virtuais do cliente são replicadas em nosso vCenter, após o que o engenheiro as adiciona ao vCloud Director.
A replicação primária ocorre em uma máquina virtual ligada. No horário combinado, a máquina do lado do cliente é desligada. A replicação é executada novamente para transferir as alterações ocorridas desde a primeira replicação. Depois disso, a máquina virtual inicia em nossa nuvem.
Normalmente, desde o momento em que a máquina é desligada na infraestrutura do cliente até o momento em que é ligada em nossa nuvem, não passa mais de meia hora, mas sim de 15 a 20 minutos.
Neste caso, a máquina virtual original permanece no site do cliente. Se de repente algo der errado, você sempre poderá reverter e ligá-lo. Este método também é conveniente para o cliente, pois não exige que ele tenha Veeam.
Caso 1
O cliente possuía infraestrutura virtual própria baseada em VMware - 40 VMs com capacidade de 30 TB. Os equipamentos nos quais o cluster foi implantado já estavam desatualizados e o cliente decidiu não se preocupar em adquirir novos e migrou para a nuvem pública. O requisito de tempo de inatividade para sistemas críticos não era superior a uma hora. Veeam Replication foi escolhido como ferramenta. Outra vantagem foi a presença do provedor de Internet do cliente em nosso data center, o que possibilitou organizar um bom canal. A migração durou cerca de um mês, o tempo de inatividade durante a troca foi de até 30 minutos por grupo de máquinas virtuais.
Migre com o Veeam Cloud Connect
Veeam Cloud Connect é uma ferramenta que ajuda você a configurar a replicação de máquinas virtuais e lançar réplicas na nuvem do provedor de serviços. Depois de atualizar para ano, tornou-se possível replicar máquinas virtuais diretamente para o vCloud Director. A única condição é que no lado do cliente o Veeam Backup and Replication seja implantado pelo menos na versão 9. Resumindo (versão detalhada ), então todo o processo fica assim.
No vCloud Director, uma organização é criada com os recursos e redes necessários. No Veeam Cloud Connect, criamos uma conta, o cliente se conecta a ela a partir de seu Veeam B&R, seleciona um provedor e uma organização 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 de forma alguma do suporte técnico do provedor e gerencia todo o processo de forma independente: cria tarefas de replicação, a própria replicação, desliga as máquinas e as inicia no novo site.
Caso 2
A infraestrutura do cliente, de onde foi planeada a migração, estava localizada na Bielorrússia. Foi necessário transportar 90 VMs com um volume total de 27 TB, apesar do canal de Internet ser de 100 Mbit/seg. Se você fizer um backup e carregá-lo imediatamente para nossa nuvem, para algumas VMs isso levará vários dias. Durante esse período, um grande delta teria crescido na VM e isso poderia ter um impacto negativo no desempenho das máquinas ou, pior ainda, o espaço no armazenamento de dados teria acabado. Procedemos da seguinte forma: primeiro, o cliente fez um backup completo local e transferiu uma cópia dele para nossa nuvem via Veeam Cloud Connect. Depois fiz e transferi o incremento para a nuvem. A máquina virtual original continuou a funcionar. Após desligar a VM, o cliente fez outro incremento e também transferiu para a nuvem. Do nosso lado, implantamos uma máquina virtual a partir de um backup completo e, em seguida, implementamos dois incrementos nela. Em última análise, este esquema permitiu minimizar o tempo de inatividade para 2 horas ao mudar para o nosso site.
Migração com disponibilidade de VMware vCloud
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 stands de virtualização de clientes privados para a nuvem (vCenter - vCloud Director). A principal comodidade é a integração com a interface do vCloud Director. Isso simplifica bastante o processo de gerenciamento de replicação e minimiza o tempo de inatividade durante as alternâncias.
Usando esta ferramenta, migramos um dos clientes da nossa nuvem em Moscou para a nossa nuvem em São Petersburgo. Foi necessário transportar 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 organizadas. Em seguida, a partir da interface do vCloud Director, o cliente acessou as configurações de disponibilidade do vCloud, criou trabalhos de replicação e mudou para o site de São Petersburgo em um momento conveniente para ele. O tempo de inatividade durante a troca foi de 12 minutos.
Esquema de migração entre nuvens DataLine em São Petersburgo e Moscou.
O vCloud Availability possui um mecanismo para migrar VMs do site do cliente para nossa nuvem. Para fazer isso, um aplicativo especial do vCloud Availability é implantado no vCenter do cliente. Após a configuração simples, você se conecta à nuvem e configura as tarefas de migração. O cliente também gerencia todo o processo de forma independente e o tempo de migração é reduzido ao mínimo.
Esquema de 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-se para a migração
Para escolher uma ferramenta e realmente começar a migrar, você precisa decidir sobre os seguintes pontos:
De onde migramos? Se você estiver migrando de uma solução privada, terá total liberdade na escolha das ferramentas. Se você se afastar do seu provedor, será mais complicado. Muito provavelmente, ligar as infraestruturas de dois fornecedores e simplesmente arrastar e largar uma VM não funcionará por razões de segurança. Às vezes, o fornecedor que o cliente está prestes a recusar começa a ser travesso e ganha tempo. Você pode se afastar do provedor à moda antiga: fazendo upload de VMs para discos e FTP ou migrando no nível do aplicativo. O nome deste último é condicional e se parece com isto.
Caso 3
Foi necessária a migração do sistema SAP do cliente de um provedor europeu: 34 VMs com capacidade de 54 TB. O cliente recebeu recursos alocados em nossa nuvem. A conectividade de rede foi organizada entre nós e a infraestrutura do fornecedor europeu. Os servidores de aplicativos foram reimplantados, com as configurações necessárias refeitas. Grandes bancos de dados foram migrados através do upload de backups para nossa nuvem. Em seguida, a replicação foi configurada entre os bancos de dados do nosso site e do site original. No horário combinado, mudamos para bancos de dados em nossa nuvem.
Volume de dados e canal de Internet. Normalmente pedimos ao cliente que forneça um upload por sistema com parâmetros de memória, CPU e disco. Avaliamos se o canal é suficiente para enviar diretamente réplicas ou backups de máquinas virtuais.
Tempo de inatividade aceitável. Para diferentes sistemas e, consequentemente, máquinas virtuais, pode ser diferente dependendo da criticidade do negócio. Normalmente, o cliente vem com requisitos prontos para tempo de inatividade durante a migração e, com base nisso, selecionamos a ferramenta e o plano de migração apropriados. Tentamos agendar a transição final para a noite ou nos finais de semana para que mesmo pequenos períodos de inatividade não sejam percebidos pelos usuários finais do cliente.
Com base nesses dados, você pode selecionar uma ferramenta e iniciar a migração propriamente dita. 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. As máquinas virtuais serão copiadas nesta rede. Se o Veeam Backup and Replication for usado, então este é um canal dedicado, menos frequentemente um canal VPN. Se for Veeam Cloud Connect, tudo acontece pela Internet ou pelo mesmo canal dedicado.
Em seguida, a rede é configurada para a VM na nuvem. Os carros costumam circular em grupos e por mais de um dia. Depois que as VMs são trazidas até nós e lançadas, elas devem se comunicar com as máquinas que ainda permanecem no site original.
- Cronograma de migração. Quando há muitos carros, faz sentido dividi-los em grupos e transportá-los em lotes. Juntamente com o cliente, acordamos um plano no qual especificamos quando e quais máquinas serão movidas e quando será realizada a replicação final e a mudança para o novo local.
- Migração de teste. 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, etc. Este teste ajuda a evitar problemas na fase de migração de combate.
Isso é tudo para mim. Nos comentários, tire dúvidas e conte-nos sobre sua experiência de migração.
Fonte: habr.com