Prácticas recomendadas para migrar máquinas virtuales a Compute Engine

En este artículo se proporcionan directrices y prácticas recomendadas para migrar cargas de trabajo de recursos informáticos a Google Cloud Platform (GCP).

Cuando migras una carga de trabajo a la nube, es muy importante que tengas en cuenta cómo vas a administrar los distintos componentes de tu infraestructura. La metodología para trasladar datos no es la misma que la empleada para trasladar bases de datos, que es distinta también de la utilizada para trasladar recursos informáticos.

Al evaluar una migración a la nube, muchos clientes dan prioridad a los costes. Gracias a los descuentos por uso continuado (SUD) de las máquinas virtuales de Google Compute Engine, los costes se pueden reducir considerablemente con respecto a la administración de hardware o de máquinas virtuales en un centro de datos tradicional. Puedes aprovechar esta ventaja cuando realices la migración de otro servicio en la nube a Cloud Platform.

No obstante, la principal ventaja que obtienen casi todos los clientes es la agilidad, ya que pueden crear máquinas virtuales casi al instante y sin tener que esperar a que se adquieran y aprovisionen los recursos. Las máquinas virtuales en la nube permiten que las empresas creen nuevas aplicaciones rápidamente, experimenten con ellas y las desactiven cuando sea necesario. Esta capacidad para experimentar, identificar fallos y descubrir qué funciona y qué no en poco tiempo es un gran punto a favor. También ayuda a reducir el coste de la innovación. Los diferentes grupos de tu empresa no tienen que preocuparse de comprar y utilizar la infraestructura para un pequeño experimento. Aunque hayan utilizado otros proveedores de servicios en la nube, los clientes pueden ver las ventajas de una red ágil y mundial, así como disfrutar de rápidos tiempos de inicio en máquinas virtuales.

Por último, muchos clientes aprovechan la posibilidad de consolidar los gastos generales. Los centros de datos suelen exigir establecer relaciones con distintos proveedores, cada uno con sus propios contratos y modelo de facturación. La transición a la nube puede reducir significativamente esos costes. Los empleados ya no tendrán que ocuparse de las tareas generales de administración que conlleva gestionar un centro de datos. En su lugar, pueden concentrarse en las actividades que hacen prosperar a tu empresa.

La mayoría de las cargas de trabajo técnicas requieren recursos informáticos y, por ese motivo, este artículo se centra en las prácticas recomendadas y las tareas que se deben realizar para migrar máquinas virtuales. Sin embargo, como los recursos informáticos son esenciales para casi todas las cargas de trabajo, hay que tener en cuenta otros elementos que permiten que las aplicaciones funcionen, como las bases de datos, los mensajes y las analíticas.

El proceso de migración no consiste en un solo paso con el que se cambia todo. En las siguientes secciones se describen los pasos recomendados.

Calcular los costes

Antes de trasladar cualquier máquina virtual, el primer paso es calcular el coste del proceso. Es decir, evaluar el coste de lo que se está ejecutando actualmente en tus centros de datos. No solo incluye las máquinas físicas, sino también el equipo de red, la electricidad, la refrigeración, el personal y el alquiler de los centros de datos.

Una vez que hayas calculado esos costes, necesitas un modelo de costes para la nube. Ten en cuenta lo siguiente:

  • ¿Qué sistema operativo vas a utilizar? ¿Requiere licencia?
  • ¿Qué tipos de máquinas virtuales vas a utilizar? Las hay de distintos tamaños y cada una tiene un coste. También deberías tener una idea general de las características de rendimiento de tus aplicaciones.
  • Además de máquinas virtuales, ¿qué otros servicios requiere tu aplicación y cuánto valen?
  • ¿Estas aplicaciones requieren software con licencia? ¿Cuánto cuesta? ¿Está disponible en la nube?

Te recomendamos que te plantees estas preguntas antes de trasladar máquinas virtuales. Tu equipo de ventas de Cloud Platform puede ayudarte a evaluar y calcular estos costes.

Si ya tienes un proveedor de servicios en la nube, estos cálculos pueden variar. Por ejemplo, no será necesario que tengas en cuenta el coste de alquilar tu propio centro de datos, pero seguirá siendo un requisito calcular estos costes. Antes de comenzar la migración, es importante comprender las diferencias entre el modelo de facturación de tu proveedor actual y el de Google. Por ejemplo, si vas a realizar la migración desde Amazon Web Services (AWS), puedes echar un vistazo a una evaluación de precios de máquinas virtuales en el blog de Cloud Platform.

Evaluar los elementos que se van a migrar

Después de evaluar el coste del traslado, puedes empezar a pensar qué se va a migrar. En las empresas modernas hay muchos tipos de aplicaciones: las de los clientes, internas, de desarrollo y experimentales, entre otras. No tendría sentido trasladar todas estas aplicaciones al mismo tiempo y de la misma manera.

Recomendamos clasificar las aplicaciones en tres categorías generales:

  • Aplicaciones fáciles de trasladar. Estas aplicaciones tienen menos dependencias, son más recientes, se desarrollan de forma interna (por lo que no hay que tener en cuenta las licencias) y muestran más tolerancia al escalado y otros patrones de la nube.
  • Aplicaciones difíciles de trasladar. Estas aplicaciones tienen más dependencias, menos tolerancia al escalado o requisitos de licencia complejos.
  • Aplicaciones imposibles de trasladar. Algunas aplicaciones no son buenas candidatas para migrarse porque se ejecutan en hardware especializado o antiguo, tienen requisitos comerciales o normativos que obligan a mantenerlas en el centro de datos o cuenta con requisitos de licencia complejos que impiden trasladarlas a la nube.

Estos son solo algunos ejemplos de cada una de estas tres categorías. Es probable que tus aplicaciones tengan muchos más factores decisivos. Si necesitas ayuda, habla con tu equipo de ventas de Cloud Platform.

Ten presente esta información tanto si el traslado se realiza desde un centro de datos como desde un proveedor de servicios en la nube.

Una vez hecho esto, puedes elegir la primera aplicación (o aplicaciones) que vas a migrar. Te recomendamos encarecidamente que migres un número reducido de aplicaciones al principio. Así contarás con una plantilla para futuras migraciones y podrás definir tus procesos de migración.

Diseñar la migración

Cuando hayas decidido qué aplicaciones vas a trasladar, debes diseñar el entorno en la nube antes de continuar con el proceso. Lo primero es comparar tu entorno actual con GCP. En la siguiente tabla tienes un resumen de la comparación:

Tipo de servicio Centro de datos Google Cloud Platform (GCP)
Recursos informáticos Hardware físico, hardware virtualizado (VMware ESXi, Hyper-V, KVM, XEN) Google Compute Engine
Almacenamiento SAN, NAS, DAS Persistent Disk, Google Cloud Storage
Red MPLS, VPN, balanceo de carga de hardware, DNS Google Cloud VPN, Google Cloud Interconnect, balanceo de carga de Compute Engine, Google Domains, Google Cloud DNS
Seguridad Cortafuegos, NACLs, tablas de enrutamiento, encriptado, IDS, SSL Cortafuegos de Compute Engine, encriptado, IDS, SSL
Identidad Active Directory, LDAP IAM, GCDS, LDAP
Administración Servicios de configuración, herramientas de integración y distribución continuas (CI/CD) Deployment Manager, servicios de configuración, herramientas de CI/CD

Si vas a migrar una máquina virtual desde AWS, puedes usar la guía de comparación para contrastar los servicios de AWS y Cloud Platform.

Después de comparar los distintos servicios para saber qué necesitan y qué utilizan tus aplicaciones, puedes comenzar a planificar tu entorno en Cloud Platform.

Antes de migrar ninguna máquina virtual, debes diseñar el entorno de la aplicación. En las siguientes secciones encontrarás los pasos recomendados.

Asignar permisos

Decide qué personas de tu empresa van a tener permisos para crear, consultar, modificar y destruir recursos en la nube. También tienes que pensar cómo se pagarán los recursos. Si necesitas información sobre este tema, consulta la documentación de prácticas recomendadas para la gestión de identidades y accesos (IAM).

Llegados a este punto, también debes determinar quién va a tener cuentas en la nube. Puede que no sea necesario que todas las personas de tu empresa tengan acceso directo, ni siquiera todos los desarrolladores. Asigna las cuentas y establece la política para crearlas y eliminarlas desde el primer momento.

Crear una red

Antes de trasladar ninguna máquina virtual, debe existir la red a la que se van a migrar. Al igual que en el caso de los permisos y las cuentas, es importante crear esta red con antelación, ya que establecer procedimientos con las aplicaciones en marcha puede resultar complicado.

Al diseñar una red, debes tener en cuenta que no será para una única aplicación, sino que será un patrón que deberá seguir toda la empresa. Plantéate lo siguiente:

  • ¿Habrá una red para cada aplicación o para cada entorno?
  • ¿Cómo accederán las aplicaciones a los servicios compartidos?
  • ¿Utilizarás un modelo de redes de concentrador y radio, o bien una red en malla completa?
  • ¿Cómo conectarás las distintas redes?
  • ¿Utilizarás una conexión VPN entre ellas o una red multiproyecto?

Dada la variedad de opciones y las diferencias entre empresas, es difícil ofrecer consejos prescriptivos para absolutamente todas las situaciones. Te recomendamos que evalúes tus necesidades y elijas una estrategia antes de empezar a desplegar aplicaciones.

La segunda parte del diseño de la red consiste en decidir cómo conectarse a los recursos actuales. Google te proporciona varias opciones de conexión en función de tus necesidades.

Lo más sencillo es crear una conexión VPN entre los recursos actuales y Google. Este servicio te permite crear rutas estáticas o dinámicas entre ambas ubicaciones.

Si necesitas una conexión más rápida con Google, puedes ponerte en contacto con los partners de Cloud Interconnect, que te ayudarán a crear una línea alquilada directa a Google.

Por último, puedes optar por crear un enlace directo a Google en una de nuestras numerosas ubicaciones de emparejamiento directo.

Planificar las operaciones

Cuando tienes aplicaciones ejecutándose en la nube, tienes que supervisarlas, conservar registros y administrar su funcionamiento, tal y como lo harías en cualquier otro sistema. Estas operaciones deben formar parte de tu planificación avanzada.

Existen varias herramientas de configuración de terceros, como el software de Chef y Puppet, entre otros, que pueden serte útiles. Si ya utilizas estas herramientas, deberías seguir haciéndolo en tu entorno de Cloud Platform. En caso contrario, te recomendamos evaluarlas para comprobar cuál se adapta mejor a tus necesidades según la forma de trabajar de tus desarrolladores e ingenieros de operaciones. Estas herramientas pueden funcionar con Google Cloud Deployment Manager y complementarlo. Te recomendamos que las incorpores al despliegue y a la gestión operativa.

También debes tomar una decisión similar para las funciones de supervisión y registro. Hay varias herramientas de terceros que funcionan bien en Cloud Platform. Si ya utilizas una o varias de ellas, deberías seguir haciéndolo. En caso contrario, existen varias herramientas para estas funciones, entre ellas Google Stackdriver, que integra supervisión, registro y alertas en un solo servicio.

Comenzar la migración

Ha llegado el momento de migrar la primera aplicación. Esto te servirá como plantilla para futuras migraciones. El proceso irá mejorando a medida que realices otras migraciones, pero es especialmente importante que registres todo lo que hagas en la primera.

En la siguiente sección se explican las arquitecturas de migración de alto nivel y los pasos necesarios para migrar en cada situación.

Arquitecturas de migración

A grandes trazos, hay tres tipos de arquitecturas de migración que puedes utilizar para cada aplicación.

La primera consiste en rediseñar completamente una aplicación para la nube. Aunque se trata de una opción viable, no se aborda en este artículo, ya que el proceso es similar al de crear una nueva aplicación en la nube.

En las siguientes secciones se explican las otras dos estrategias.

Migrar mediante lift-and-shift

En general, esta estrategia es la más sencilla para empezar, ya que es la que requiere hacer menos cambios en las aplicaciones. Solo hay que cerrar la aplicación actual y copiar los datos y las máquinas virtuales a la nube.

Transferir los datos

El primer paso en una migración mediante lift-and-shift es transferir los datos necesarios para ejecutar la aplicación. Estos datos suelen estar en una base de datos, pero también pueden incluir elementos estáticos que se pueden transferir de una SAN al almacenamiento de objetos de Cloud Storage. También se transfieren los datos que necesita la aplicación de forma local a Cloud Storage para descargarlos a los discos persistentes de Compute Engine cuando se inician las máquinas virtuales.

Trasladar las máquinas virtuales

El siguiente paso es trasladar las máquinas virtuales. Esto se puede hacer de varias maneras. Google proporciona documentación sobre cómo importar imágenes de forma manual, aunque también puedes utilizar el servicio de un partner externo como CloudEndure. Consulta el apartado Utilizar CloudEndure para obtener más información.

Probar la aplicación

Cuando los datos y las máquinas virtuales estén ejecutándose en Cloud Platform, debes ejecutar la aplicación en modo de prueba para asegurarte de que funciona correctamente. Debes comprobar, entre otros aspectos, si se cumplen las métricas de rendimiento y si la aplicación se despliega, supervisa y registra correctamente.

Pasar al entorno de producción

La duración de este paso depende del tipo de aplicación. Para cambiar al lugar donde se ejecuta la aplicación en producción, esta casi siempre se debe desconectar durante un tiempo. Las pautas para pasar al entorno de producción sin desconectar una aplicación, desde la perspectiva del usuario, no se abordan dentro de estas prácticas recomendadas.

Hay dos factores que determinan la duración de este paso:

  • El tiempo que ha pasado desde la importación original de los datos
  • El tiempo que tardará el DNS en actualizar las entradas del frontend de la aplicación

Por norma general, tienes mucha más capacidad de decisión sobre el primer factor. Si necesitas que el intervalo de tiempo para pasar al entorno de producción sea más corto, tendrás que actuar lo antes posible después de importar los datos.

Cuando hayas establecido un intervalo de tiempo aceptable, haz lo siguiente:

  1. Informa a los usuarios sobre la ventana de mantenimiento.
  2. Retira la aplicación de su ubicación actual.
  3. Importa los datos que faltan a las ubicaciones apropiadas de Cloud Platform.
  4. Cambia las entradas de DNS y activa la aplicación en la nube.

Si todo va bien, la aplicación debería haberse migrado por completo y los usuarios podrán volver a utilizarla.

Migración híbrida

La tercera estrategia de arquitectura se denomina migración híbrida. En este caso, solo una parte de la aplicación se traslada a la nube. Suele ser el frontend y, posiblemente, la lógica de la aplicación. El backend y los servicios asociados permanecen con los demás recursos actuales. La migración híbrida es una variación de la migración mediante lift-and-shift. Resulta muy útil cuando la aplicación se puede trasladar a la nube, pero no algunos servicios de backend. Este tipo de migración consta de menos pasos que la migración mediante lift-and-shift. Por ejemplo, el almacenamiento de datos no se traslada a la nube en esta arquitectura.

Determinar la conexión de red

El primer paso es crear una conexión lo suficientemente rápida entre los recursos actuales y Cloud Platform. Las características de esta conexión dependen por completo del perfil de la aplicación. En algunos casos, puede bastar con una VPN. En otros, hará falta una línea de alta velocidad exclusiva.

Migrar las máquinas virtuales

El siguiente paso es migrar las imágenes de las máquinas virtuales, de forma similar a como se hace al migrar mediante lift-and-shift. Llegados a este punto, hay que probar la aplicación para asegurarse de que funciona de la forma esperada en la nube y se vincula a los recursos actuales.

Pasar al entorno de producción

La ventana de mantenimiento es mucho más reducida en este caso porque no hay que migrar los datos. Aun así, tienes que hacer lo siguiente:

  1. Informa a los usuarios sobre la ventana de mantenimiento.
  2. Desactiva la aplicación actual.
  3. Cambia las entradas de DNS.
  4. Activa la aplicación en la nube.

Si todo va bien, la aplicación se ejecutará en Cloud Platform, y los usuarios podrán volver a acceder a ella.

Utilizar CloudEndure

CloudEndure es una cadena de herramientas y un servicio online que facilita la migración de máquinas de una plataforma a otra, con un periodo de inactividad mínimo y replicación continua. La solución se compone de las siguientes bases tecnológicas:

  • Agente de replicación continua por bloques. La metodología del agente permite migrar cualquier máquina física, virtual o en la nube independientemente de la infraestructura de la máquina de origen. La metodología por bloques traslada todo, incluidos los datos del sistema operativo, los parches, las configuraciones, las aplicaciones y las bases de datos. También elimina los riesgos asociados a los componentes clave que faltan debido a errores humanos. Esta estrategia tiene un porcentaje de éxito en la migración muy elevado con cualquier sistema operativo compatible, independientemente de la aplicación. La replicación continua se ocupa de que los datos estén siempre sincronizados en tiempo real, lo que reduce los periodos de transición al eliminar la necesidad de ponerse al día con los cambios periódicos de datos.
  • Motor de conversión de sistemas automatizado. Permite que cualquier sistema de origen se convierta de forma automática y rápida al formato de Cloud Platform en el momento del lanzamiento. Esto elimina el importante periodo de inactividad que implica la preparación de los sistemas para la migración de forma manual. El motor de conversión de CloudEndure se encarga de que la máquina esté lista para Compute Engine en cuestión de minutos y la activa con el estado replicado más reciente.
  • Orquestación de pila de aplicaciones automatizada. Permite que los ingenieros del proyecto de migración definan de antemano a qué zonas y regiones se deben migrar las máquinas, además de la cantidad de CPU y RAM que necesitan para su carga de trabajo. CloudEndure también preconfigura redes y discos de cara a la migración.

Estas bases reducen los riesgos principales y el periodo de inactividad asociados a los proyectos de migración típicos, lo que te permite ejecutar tu proyecto de migración de forma rápida, segura y fiable.

Así es el proceso de migración de máquinas virtuales con CloudEndure:

  1. Ejecuta el agente CloudEndure en las máquinas de origen.
  2. Supervisa el panel de CloudEndure mientras se completa la replicación.
  3. Pon en pausa la carga de trabajo en las máquinas de origen.
  4. Ejecuta una última sincronización incremental de cualquier dato que pueda haber cambiado.
  5. Migra tus puntos de conexión del servicio a las máquinas de destino recién aprovisionadas en Compute Engine.

Para obtener más información sobre cómo realizar la migración de máquinas virtuales, consulta el tutorial sobre cómo migrar máquinas virtuales a Compute Engine.

Ejemplos de casos prácticos

En esta sección se describen cinco maneras de migrar rápidamente las cargas de trabajo con CloudEndure que han utilizado los clientes para beneficiarse de Compute Engine.

Migrar muchas cargas de trabajo en paralelo

Tras su adquisición, una empresa minorista necesitaba trasladar todas sus cargas de trabajo a Cloud Platform. Sus máquinas, basadas en Linux, estaban repartidas entre varios centros de datos in situ y diferentes proveedores de servicios en la nube. Aunque el traslado de algunas máquinas era sencillo, sabían que tendrían dificultades para trasladar su base de datos y sus dispositivos de SAN con un periodo de inactividad mínimo. Cada minuto de inactividad supondría una pérdida de ingresos para este comercio.

CloudEndure pudo replicar de forma continua todas sus máquinas en paralelo, mientras actualizaba sus kernels de Linux en las máquinas virtuales de destino de Compute Engine. Migraron los volúmenes de almacenamiento SAN directamente a los discos persistentes de Compute Engine. Cuando se completó la replicación, el periodo de transición se había reducido a solo unos minutos.

Migrar cargas de trabajo de Windows que se ejecutan en VMware

Una empresa con varios centros de datos en Asia tenía una gran infraestructura de máquinas virtuales Windows que se ejecutaban en VMware. Necesitaban trasladar sus servidores Windows Server 2008 R2 y Windows Server 2012 R2 a Cloud Platform con un periodo de inactividad mínimo en sus servicios esenciales, como Active Directory y Exchange.

A pesar de la diversidad de aplicaciones y la mezcla de versiones de Windows, pudieron usar la replicación en el nivel de disco de CloudEndure para seguir la misma estrategia de migración en todos sus sistemas.

Migrar una aplicación grande de varios niveles

Una empresa con una gran carga de trabajo de aplicaciones de varios niveles quería migrar sus servidores de su centro de datos a la nube. El 90 % de su carga de trabajo in situ era virtual, y el cliente sabía que había herramientas pensadas para enviar lentamente capturas de discos virtuales a la nube y realizar modificaciones manuales en el sistema con el objetivo de preparar las máquinas para la nube. Aunque no era una solución ideal, sobre todo porque haría falta un periodo de inactividad significativo durante la transición, era posible. No obstante, el 10 % de la carga de trabajo se ejecutaba en servidores físicos que alojaban bases de datos esenciales. Esto planteó un problema de migración muy importante porque el cliente no podía usar ninguna metodología basada en hipervisores para migrar estos servidores físicos tan cruciales.

Gracias al agente de CloudEndure, apto para cualquier infraestructura, y a su motor de conversión automática de máquinas, el cliente pudo trasladar los servidores físicos y los virtuales a la nube con el mismo proceso y las mismas herramientas. Además, la estrategia de replicación de discos de CloudEndure posibilitó que se pudiera usar un proceso de migración idéntico para todos los niveles de las aplicaciones. Gracias a la replicación por bloques, el periodo de inactividad de la transición no duró muchas horas, sino tan solo unos minutos.

Migrar una aplicación que se actualiza con frecuencia

Una empresa con una carga de trabajo de una aplicación que se actualizaba con frecuencia quería migrar a la nube. Al principio, el cliente preparó sistemas en espera preconfigurados en la nube e intentó trasladar los datos de la aplicación de origen a los sistemas en espera de destino. La idea era convertir las aplicaciones en espera en aplicaciones principales más adelante. Sin embargo, trasladar los datos y mantenerlos sincronizados resultó ser una tarea lenta durante la cual la aplicación de origen y el sistema operativo se seguían actualizando con frecuencia. Con el tiempo, el cliente empezó a preocuparse de que algunos parches o cambios en la aplicación no se transfirieran durante la etapa de transición, lo cual podría provocar una interrupción del servicio.

La estrategia de replicación por bloques de CloudEndure resolvió el problema. Gracias a CloudEndure, todos los bloques de disco se replicarían en un estado coherente. Los discos de destino no solo mantendrían los datos reales de la aplicación con su estado más actualizado, sino que los parches del sistema operativo, las actualizaciones, la configuración de la aplicación y otros elementos se mantendrían también intactos.

Migrar desde varios centros de datos

Una empresa con varios centros de datos in situ y en instalaciones de colocación necesitaba consolidarlos como parte de una migración a la nube. Además de los desafíos habituales de trasladar aplicaciones de una infraestructura a otra, el cliente también se enfrentaba a problemas con las redes. Algunas aplicaciones utilizaban el mismo espacio de IPs privado en redes separadas, lo que podría provocar conflictos una vez migradas a una única red consolidada en la nube. Estaba claro que sería necesario hacer cambios de red en la nube para poder poner en marcha la migración. Era fundamental poder hacer esos cambios y probarlos fácilmente y sin provocar interrupciones.

El mecanismo de CloudEndure, con el que se puede diseñar la máquina de destino, permitió al cliente definir cómo se aprovisionaría la configuración de red del servidor de destino en la nube tantas veces como fue necesario. Después de cada iteración de la configuración del diseño, el cliente pudo probar la puesta en marcha de los servidores de destino en una red en la nube aislada y verificar su comportamiento sin que afectara a los servidores de origen. Cuando se cumplieron todos los criterios de la prueba, se programó el periodo de transición para la migración y se ejecutó de forma predecible y sin apenas riesgos.

Siguientes pasos

¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...