Hai uns 7 anos, os primeiros proxectos trasladáronse á nosa nube de forma sinxela e sen pretensións. As imaxes de máquinas virtuais subíronse a un servidor FTP ou entregáronse en discos duros. Despois, a través dun servidor de importación especial, as máquinas virtuales subíanse á nube.
Se non é un problema para o cliente apagar a máquina virtual durante un día ou dous (ou non hai outras opcións), entón pódese facer. Pero se o tempo de inactividade debe ser dun máximo dunha hora, entón este método non funcionará. Hoxe vouche dicir cales son as ferramentas que che axudarán a migrar á nube cun tempo de inactividade mínimo e como funciona o noso propio proceso de migración.
Migración con Veeam Backup and Replication
Todo o mundo coñece a Veeam Backup and Replication como unha ferramenta para crear copias de seguridade e réplicas. Usámolo para a migración entre os nosos sitios e para transportar clientes desde a virtualización privada á nosa nube. As máquinas virtuais do cliente replícanse no noso vCenter, despois de que o enxeñeiro engádeas a vCloud Director.
A replicación primaria prodúcese nunha máquina virtual encendida. Á hora acordada, a máquina do cliente está desactivada. A replicación execútase de novo para trasladar os cambios que se produciron desde a primeira replicación. Despois diso, a máquina virtual comeza na nosa nube.
Normalmente, desde o momento en que a máquina se apaga na infraestrutura do cliente ata o momento en que se acende na nosa nube, non pasa máis de media hora, senón de 15 a 20 minutos.
Neste caso, a máquina virtual orixinal permanece no sitio do cliente. Se de súpeto algo sae mal, sempre podes retroceder e acendelo. Este método tamén é conveniente para o cliente xa que non esixe que teña Veeam.
Caso 1
O cliente tiña a súa propia infraestrutura virtual baseada en VMware: 40 máquinas virtuales cunha capacidade de 30 TB. Os equipos nos que se despregou o clúster xa estaban desactualizados e o cliente decidiu non molestarse en comprar outros novos e pasou á nube pública. O requisito de tempo de inactividade dos sistemas críticos non superaba unha hora. Elixiuse Veeam Replication como ferramenta. Outra vantaxe foi que o provedor de Internet do cliente estaba presente no noso centro de datos, o que permitiu organizar unha boa canle. A migración levou aproximadamente un mes, o tempo de inactividade durante o cambio foi de ata 30 minutos por grupo de máquinas virtuais.
Migra con Veeam Cloud Connect
Veeam Cloud Connect é unha ferramenta que che axuda a configurar a replicación de máquinas virtuais e lanzar réplicas na nube do provedor de servizos. Despois de actualizar a ano, fíxose posible replicar máquinas virtuais directamente en vCloud Director. A única condición é que no lado do cliente, Veeam Backup and Replication deba implantarse polo menos a versión 9. En resumo (versión detallada ), entón todo o proceso é así.
En vCloud Director, créase unha organización cos recursos e redes necesarios. En Veeam Cloud Connect, creamos unha conta, o cliente conéctase a ela desde o seu Veeam B&R, selecciona un provedor e organización de DataLine e configura tarefas para a replicación. Ademais de que durante esa migración, o tempo de inactividade será de 15 a 20 minutos, o cliente non depende de ningún xeito do soporte técnico do provedor e xestiona todo o proceso de forma independente: crea tarefas de replicación, a propia replicación desactívase. as máquinas e iníciaas no novo sitio.
Caso 2
A infraestrutura do cliente, desde onde se planeou a migración, estaba situada en Bielorrusia. Foi necesario transportar 90 máquinas virtuales cun volume total de 27 TB, a pesar de que a canle de Internet era de 100 Mbit/s. Se fai unha copia de seguranza e a carga inmediatamente na nosa nube, algunhas máquinas virtuales tardarían varios días. Durante este tempo, crecería un gran delta na VM, e isto podería ter un impacto negativo no rendemento das máquinas ou, peor aínda, esgotaríase o espazo no almacén de datos. Procedemos do seguinte xeito: primeiro, o cliente fixo unha copia de seguridade completa local e transferiu unha copia dela á nosa nube a través de Veeam Cloud Connect. Despois fixen e transferín o incremento á nube. A máquina virtual orixinal continuou a funcionar. Despois de apagar a máquina virtual, o cliente fixo outro incremento e tamén o trasladou á nube. Pola nosa banda, implantamos unha máquina virtual a partir dunha copia de seguridade completa e, a continuación, introducimos nela dous incrementos. Este esquema permitiu, finalmente, minimizar o tempo de inactividade a 2 horas ao cambiar ao noso sitio.
Migración con VMware vCloud Availability
En marzo deste ano, VMware lanzou vCloud Availability 3.0, que permite migrar máquinas virtuais entre diferentes nubes (vCloud Director - vCloud Director) e desde soportes de virtualización de clientes privados á nube (vCenter - vCloud Director). A principal comodidade é a integración coa interface de vCloud Director. Isto simplifica moito o proceso de xestión da replicación e minimiza o tempo de inactividade durante os cambios.
Usando esta ferramenta, migramos un dos clientes da nosa nube de Moscova á nosa nube de San Petersburgo. Foi necesario transportar 18 máquinas virtuais cunha capacidade total de 14 TB. Creouse unha organización para o cliente na nube de San Petersburgo e organizáronse as redes necesarias. A continuación, desde a interface de vCloud Director, o cliente pasou á configuración de dispoñibilidade de vCloud, creou traballos de replicación e cambiou ao sitio de San Petersburgo nun momento conveniente para el. O tempo de inactividade durante o cambio foi de 12 minutos.
Esquema de migración entre as nubes DataLine en San Petersburgo e Moscova.
vCloud Availability ten un mecanismo para migrar máquinas virtuales do sitio do cliente á nosa nube. Para iso, implícase unha aplicación especial de dispoñibilidade de vCloud no vCenter do cliente. Despois dunha simple configuración, conéctate á nube e configura as tarefas de migración. O cliente tamén xestiona todo o proceso de forma independente e o tempo de migración redúcese ao mínimo.
Esquema para migrar máquinas virtuais dunha instalación privada á nube.
A dispoñibilidade de VMware vCloud ten moitos outros casos de uso; en breve falaremos deles nun artigo separado.
Preparación para a migración
Para escoller unha ferramenta e comezar a migrar, debes decidir sobre os seguintes puntos:
De onde migramos? Se estás migrando desde unha solución privada, tes total liberdade para escoller ferramentas. Se te afastas do teu provedor, entón é máis complicado. O máis probable é que ligar as infraestruturas de dous provedores e simplemente arrastrar e soltar unha máquina virtual non funcione por razóns de seguridade. Ás veces, o provedor que o cliente está a piques de rexeitar comeza a ser travieso e detén o tempo. Podes afastarte do provedor á antiga usanza: cargando máquinas virtuales a discos e FTP ou migrando a nivel de aplicación. O nome deste último é condicional, e parece algo así.
Caso 3
Foi necesario migrar o sistema SAP do cliente desde un provedor europeo: 34 máquinas virtuales cunha capacidade de 54 TB. Ao cliente asignáronse recursos na nosa nube. A conectividade de rede organizouse entre nós e a infraestrutura do provedor europeo. Os servidores de aplicacións volvéronse a implantar, trasladando as configuracións necesarias. As grandes bases de datos migráronse mediante a carga de copias de seguridade na nosa nube. A continuación, configurouse a replicación entre as bases de datos dos nosos sitios e os orixinais. No momento acordado, cambiamos ás bases de datos na nosa nube.
Volume de datos e canle de Internet. Normalmente pedimos ao cliente que proporcione unha carga por sistema con parámetros de memoria, CPU e disco. Avaliamos se a canle é suficiente para enviar directamente réplicas ou copias de seguridade de máquinas virtuais.
Tempo de inactividade aceptable. Para diferentes sistemas e, en consecuencia, máquinas virtuais, pode ser diferente dependendo da súa criticidade empresarial. Normalmente o cliente vén con requisitos preparados para o tempo de inactividade durante a migración, e en función diso seleccionamos a ferramenta e o plan de migración adecuados. Tentamos programar o cambio final pola noite ou os fins de semana para que os usuarios finais do cliente non noten nin un tempo de inactividade menor.
En base a estes datos, pode seleccionar unha ferramenta e comezar a propia migración. Aquí tes o que sucede a continuación.
- Configurando a conectividade de rede. Organizamos a conectividade de rede entre a nosa nube e a infraestrutura do cliente. As máquinas virtuais copiaranse nesta rede. Se se usa Veeam Backup and Replication, esta é unha canle dedicada, con menos frecuencia unha canle VPN. Se Veeam Cloud Connect, todo pasa por Internet ou pola mesma canle dedicada.
A continuación, a rede está configurada para a máquina virtual na nube. Os coches adoitan moverse en grupos e durante máis dun día. Unha vez que as máquinas virtuales son traídas e lanzadas, deben comunicarse coas máquinas que aínda permanecen no sitio orixinal.
- Calendario de migración. Cando hai moitos coches, ten sentido dividilos en grupos e transportalos por lotes. Conxuntamente co cliente, acordamos un plan no que especificamos cando e que máquinas se moverán e cando se realizará a replicación final e o cambio ao novo sitio.
- Proba de migración. Migramos a máquina virtual de proba e comprobamos se todo está configurado correctamente: conectividade de rede entre sitios, dispoñibilidade da máquina virtual para máquinas do sitio de orixe, dereitos de conta, etc. Esta proba axuda a evitar problemas na fase de migración do combate.
Iso é todo para min. Nos comentarios, fai preguntas e cóntanos sobre a túa experiencia de migración.
Fonte: www.habr.com