¿Necesitas mover aplicaciones legacy con sistemas operativos en fin de vida a Google Cloud? Este artículo es para ti. Repasamos las opciones para importar a Google Compute Engine tus máquinas virtuales con SO en EOL.
La realidad de las aplicaciones legacy en fin de vida
En DoiT International nos encontramos con clientes en distintas etapas de su camino a la nube. Algunos ya son nativos de la nube y aún no arrastran demasiada deuda técnica; otros conservan aplicaciones legacy por distintos motivos. Algunos procuran mantenerlas al día y otros terminan siendo el caso del que trata este artículo: alojan aplicaciones legacy olvidadas sobre sistemas operativos en fin de vida (EOL). Si tienes aplicaciones así y quieres llevarlas a Google Cloud, este artículo es para ti. Conocerás las opciones disponibles y, con suerte, te ayudará a tomar las decisiones acertadas para tus workloads.
La idea de este artículo surgió al ver a varios clientes evaluando Google Cloud VMware Engine (GCVE) para correr sus aplicaciones legacy en Google Cloud. Como por dentro es VMware, GCVE resulta una excelente forma de ejecutar ciertas VMs, incluidas las que tienen sistemas operativos en EOL. El problema es que GCVE no escala bien hacia abajo para workloads pequeños y solo es una opción rentable cuando se aprovechan los recursos en la configuración mínima disponible.
Aunque GCVE es sin duda una alternativa para correr tus aplicaciones legacy en Google Cloud, no la recomendaría como primera opción a menos que tus workloads exijan ese nivel de escala. Más adelante volvemos sobre esto.
Investigué por qué los clientes concluían que necesitaban GCVE para ejecutar sus aplicaciones legacy en EOL y me topé con varios obstáculos:
Primero, vi a clientes intentando crear máquinas virtuales nuevas a partir de sistemas operativos en EOL, como CentOS 6. Pronto te darás cuenta de que la imagen ya no figura entre las imágenes públicas de Google. Bien, ¿y entonces?
El siguiente paso fue probar la función de importación de Google Compute Engine, que realiza importaciones ad hoc de imágenes de VM. Uno esperaría que funcionara con versiones anteriores del SO, pero al intentar importar un SO en EOL —CentOS 6 en este ejemplo— recibí malas noticias:
$ gcloud compute instances import centos-6 --source-uri=gs://eol-migration1322/centos6 --zone=us-central1-a
WARNING: Importing OVF. This may take 40 minutes for smaller OVFs and up to a couple of hours for larger OVFs.
Created [https://cloudbuild.googleapis.com/v1/projects/johnd-test-01/locations/us-central1/builds/0e67bbb8-3389-4a34-adae-5f5566732085].
Logs are available at [https://console.cloud.google.com/cloud-build/builds;region=us-central1/0e67bbb8-3389-4a34-adae-5f5566732085?project=306419495665].
starting build "0e67bbb8-3389-4a34-adae-5f5566732085"
[import-ovf]: 2022-07-05T21:25:20Z Starting OVF import workflow.
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6.ovf
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6-disk1.vmdk
[import-ovf]: 2022-07-05T21:25:21Z Didn't find valid OS info in OVF descriptor. OS will be detected from boot disk.
[import-ovf]: 2022-07-05T21:25:21Z Will create instance of `g1-small` machine type.
[import-disk-1]: 2022-07-05T21:25:22Z Inspecting the image file...
[import-disk-1]: 2022-07-05T21:28:26Z Inspecting disk for OS and bootloader
[import-disk-1]: 2022-07-05T21:30:05Z Inspection result=os_release:{cli_formatted:"centos-6" distro:"centos" major_version:"6" minor_version:"10" architecture:X64 distro_id:CENTOS} elapsed_time_ms:98933 os_count:1
[import-ovf]: 2022-07-05T21:30:06Z Cleaning up.
[import-ovf]: 2022-07-05T21:30:06Z os `centos-6` is invalid. Allowed values: [centos-7 centos-8 debian-10 debian-11 debian-8 debian-9 opensuse-15 rhel-6 rhel-6-byol rhel-7 rhel-7-byol rhel-8 rhel-8-byol rocky-8 sles-12 sles-12-byol sles-15 sles-15-byol sles-sap-12 sles-sap-12-byol sles-sap-15 sles-sap-15-byol ubuntu-1404 ubuntu-1604 ubuntu-1804 ubuntu-2004 windows-10-x64-byol windows-10-x86-byol windows-2008r2 windows-2008r2-byol windows-2012 windows-2012-byol windows-2012r2 windows-2012r2-byol windows-2016 windows-2016-byol windows-2019 windows-2019-byol windows-2022 windows-2022-byol windows-7-x64-byol windows-7-x86-byol windows-8-x64-byol windows-8-x86-byol]
ERROR
ERROR: build step 0 "us-central1-docker.pkg.dev/compute-image-tools/wrappers/gce_ovf_import:release" failed: step exited with non-zero status: 1
ERROR: (gcloud.compute.instances.import) build 0e67bbb8-3389-4a34-adae-5f5566732085 completed with status "FAILURE"Resulta entonces que la importación de imágenes solo admite ciertos SO y versiones, y CentOS 6 no es uno de ellos. Lo hagas desde la consola de Google Cloud o desde la línea de comandos, el resultado es el mismo. Eso le cierra la puerta al "botón fácil" de importar las imágenes de disco directamente a Google Compute Engine (GCE).
En este punto, alguien podría descubrir GCVE y comprobar que sigue corriendo cualquier cosa que VMware sea capaz de ejecutar. Se levanta y configura un clúster, se importan las VMs, igual que on-prem. Listo, ¡genial! ¿O no?
Estado actual del soporte de Google Cloud para imágenes de SO en EOL
Buena parte de la documentación de soporte de Google sobre sistemas operativos en EOL se concentra en recomendar primero actualizar el sistema operativo. Es una buena práctica, sin duda, pero no todos pueden hacerlo. Quizá los desarrolladores de la aplicación ya no estén disponibles, existan dependencias de ciertas librerías o sencillamente falten recursos para actualizarla.
Opciones para importar a GCE tus máquinas virtuales con SO en EOL
Estas son las opciones disponibles, sin un orden particular. Cada una tiene sus pros y sus contras.
Opción 1: Reinstalar la aplicación legacy usando una imagen pública de GCE marcada como deprecated
Como decía antes, he visto a clientes que intentaron usar imágenes nativas de Google Cloud y al principio no encontraron ninguna. Resulta que Google sigue conservando las imágenes; lo que pasa es que no las muestra a la vista. Al revisar parte de la documentación de soporte para imágenes en EOL, descubrí que las imágenes están disponibles, pero marcadas como deprecated. Aquí tienes documentación de muestra para CentOS 6.
En la consola de GCE, dentro de Imágenes, hay un interruptor que muestra las imágenes deprecated. Actívalo y, voilà, aparece la lista de todas las imágenes anteriores de GCE:
Filtra por lo que necesitas —en mi caso, imágenes de CentOS 6—, elige la que quieras usar y crea una instancia de GCE a partir de ella.
Desde la línea de comandos consigues lo mismo con:
gcloud compute images list --show-deprecated
La ventaja de esta opción es que partes de una imagen original de Google con herramientas como el os-agent y los ajustes a nivel de SO ya aplicados para que el sistema corra en Compute Engine. Si tu aplicación es fácil de reinstalar y solo tienes unas pocas instancias por mover, puede ser una opción atractiva.
Opción 2: Convertir manualmente tu imagen de VM a un formato compatible con GCE e importarla a mano
Google tiene documentación de soporte para importar imágenes manualmente y luego aplicar los ajustes correspondientes a las imágenes importadas para que funcionen bien en GCE. Este proceso puede ser útil si tienes appliances de VM a medida o solo unos pocos servidores con volúmenes únicos por migrar a GCE. Al ser manual, abre la puerta a errores.
Estos son los pasos básicos, siguiendo con el ejemplo de CentOS 6:
Planifica el camino. Vas a necesitar almacenar una imagen exportada desde tu entorno de origen y una forma de iniciarla para hacerle cambios y luego convertirla a un formato compatible con GCE. Asegúrate de tener suficiente espacio en disco para la imagen, la imagen comprimida y un poco de margen, para no toparte con errores por falta de espacio.
Haz una copia de la imagen, iníciala en el entorno de origen y aplica los cambios necesarios al SO antes de convertirla, por ejemplo:
Edita el archivo de configuración de arranque de Linux —en nuestro ejemplo, /etc/grub.conf— y elimina la línea que configura el spashimage de arranque. Quita también los parámetros del kernel rhgb y quiet. Agrega console=ttyS0,38400n8d a los parámetros del kernel.
Confirma que puedas iniciar sesión por consola con usuario y contraseña. Te puede salvar si la interfaz de red no levanta correctamente al arrancar en GCE.
Asegúrate también de tener una llave ssh para acceder a la imagen, por las dudas.
Verifica que tus repos de CentOS sigan funcionando. En mi caso tuve que apuntar los repos de CentOS a vault.centos.org.
Actualiza la configuración de la interfaz de red predeterminada. En centos-6 era /etc/sysconfig/network-scripts/ifcfg-eth0. Quita las líneas HW_ADDR y UUID y agrega ONBOOT=yes y MTU=1460 al archivo.
Desinstala las herramientas de VMware o de cualquier otro hipervisor.
Copia la imagen a un lugar desde donde puedas ejecutar los siguientes pasos.
Convierte la imagen a un formato que GCE acepte.
La forma más sencilla que encontré para convertir una imagen fue con la utilidad qemu-img. Instala qemu.
En este ejemplo tomo un archivo .vmdk de VMware y lo convierto a formato raw, que es lo que GCE requiere:
qemu-img convert -f vmdk -O raw PATH/TO/VM.VMDK PATH/TO/disk.raw
Una vez convertido el .VMDK a .raw, hay que empaquetarlo con tar en formato oldgnu:
tar –format=oldgnu -Sczf compressed-image.tar.gz disk.raw- Sube el archivo compressed-image.tar.gz a un bucket de Google Cloud Storage (GCS):
gsutil cp compressed-image.tar.gz gs://BUCKET\_NAMEPor último, crea la imagen de GCE:
gcloud compute images create IMAGE_NAME --source-uri \ gs://BUCKET_NAME/compressed-image.tar.gz
Crea una VM a partir de la imagen resultante, instala el os-agent de Google y aplica los cambios que hagan falta.
Crea una VM a partir de la imagen resultante del paso 3e.
gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME
Inicia sesión en la imagen con la llave ssh sugerida en el paso 2c.
Si no logras iniciar sesión en tu instancia, lo más probable es que se haya detectado una nueva interfaz de red al arrancar. Entra a tu instancia por la consola serial con usuario y contraseña, y ajusta la interfaz de red según lo detectado.
Ya dentro, instala el os-agent de Google.
Si estas instrucciones te parecen demasiado, quizá la siguiente opción sea para ti. Te recomiendo leer la documentación de soporte de Google sobre importar imágenes manualmente y luego ajustar las imágenes importadas. Arriba dejé los pasos básicos y algunos de los inconvenientes con los que me crucé. Hay varios requisitos y limitaciones, así que conviene revisarla.
Opción 3: Usar Migrate to Virtual Machines si tienes varias VMs por llevar a GCE
Migrate to Virtual Machines (antes Migrate for GCE) es una herramienta de migración pensada para hacer lift and shift de servidores on-prem a GCE. La última versión está enfocada en migraciones desde VMware. Si tus aplicaciones legacy ya corren sobre VMware, esta puede ser tu mejor opción. Usar Migrate to Virtual Machines requiere algo de configuración inicial, pero, una vez listo, puedes migrar muchas máquinas virtuales de forma sencilla, confiable y con un downtime mínimo.
Migrate to Virtual Machines funciona instalando un appliance de migración en tu entorno VMware existente. Ese appliance conecta Google Cloud con tu vSphere on-prem para que Migrate to Virtual Machines pueda ver tu entorno vSphere, seleccionar las VMs a migrar, configurar la replicación de datos y luego gestionar las clonaciones para pruebas o cutovers cuando estés listo para mover tus aplicaciones a Google Cloud.
Creo que esta opción será la más atractiva para la mayoría. A diferencia del proceso manual de la opción 2, automatiza buena parte de los pasos y, por mi experiencia, migra las imágenes de manera confiable. Si tienes más que un puñado de servidores por mover, esta es la vía más rápida. Migrate to Virtual Machines también soporta varios sistemas operativos actuales y legacy.
Migrate to Virtual Machines requiere que el migrate connector pueda comunicarse directamente con las APIs de Google, ya sea por internet o a través de la conectividad privada que tengas entre tu entorno VMware y Google Cloud. Esta página de soporte repasa las opciones.
Los pasos básicos para usar Migrate to Virtual Machines son:
- Configura los prerrequisitos: habilita las APIs de Google Cloud asociadas y define qué proyectos y permisos IAM vas a usar.
- Instala, configura y registra el migrate connector en tu entorno VMware existente.
- Comienza a migrar VMs. El proceso de migración se divide en estos pasos:
- Incorpora las VMs a Migrate to Virtual Machines.
- Inicia la replicación, ya sea de VMs específicas o de todas. La replicación puede hacerse mientras tus VMs de origen siguen en marcha.
- Configura los detalles de la VM destino: tipo de instancia, configuración de red, etc.
- Si quieres, prueba una migración con la función de clonación. Te recomiendo hacerlo en un entorno destino aislado. Tus imágenes de origen seguirán corriendo en VMware.
- Cutover. Esto apaga la VM de origen, hace una replicación final y luego provisiona las VMs destino. Este paso implica downtime. En las imágenes que probé observé alrededor de 15 minutos de downtime entre que se apagaba la imagen de origen y la nueva instancia quedaba arriba en Google Cloud. La mayor parte de ese tiempo fue procesamiento de la imagen, así que el tamaño puede modificar la duración.
- Limpieza.
Opción 4: Usar Google Cloud VMware Engine para alojar aplicaciones legacy grandes o numerosas
Google Cloud VMware Engine es por donde veo que arranca la mayoría, simplemente porque las otras opciones no están tan difundidas. GCVE es un excelente producto en los casos de uso adecuados, pero correr unas pocas máquinas virtuales en un clúster de GCVE puede salir caro.
La configuración mínima de GCVE es un clúster de 3 nodos. Cada nodo es una instancia ve1-standard-72, es decir, 72 cores con hyperthreading (36 físicos), 768 GB de RAM y más de 20 TB de SSD. Cada nodo en On-Demand cuesta $9.29/hora, así que el clúster mínimo de 3 nodos sale en $20,345.10 al mes. Los descuentos por commitments de 1 y 3 años pueden bajar bastante ese precio.
Google ofrece una configuración de 1 nodo, que reduce algo el precio y los recursos, pero la limita a 60 días, ya que está pensada sobre todo para POC. Por favor, no corras tus workloads de producción en esa configuración.
GCVE sigue siendo una opción viable para correr aplicaciones legacy en fin de vida, siempre que tus requerimientos de recursos lo justifiquen, que tus workloads tengan licenciamiento poco compatible con la nube (Windows Server, Oracle, etc.) o que ya uses VMware on-prem de manera intensiva y quieras seguir haciéndolo para ciertos workloads para conservar tus inversiones en herramientas u operaciones.
Opción extra 5: Usar Migrate to Containers para containerizar ciertas aplicaciones legacy
La herramienta Migrate to Containers de Google Cloud puede ser una opción para ciertos workloads. Si ya te sientes cómodo corriendo contenedores y no buscas sumar más máquinas virtuales en GCE, Migrate to Containers puede ser una alternativa viable. La herramienta analiza tus workloads y, si son aptos para containerizar, genera un contenedor a partir de tu workload basado en VM para usarlo en plataformas como Google Kubernetes Engine y Cloud Run.
Una salvedad: no todos los workloads se prestan a la conversión. Google muestra ejemplos de workloads que son buenos candidatos y los que no. También existe una herramienta de análisis que ayuda a determinarlo. Es posible que necesites hacer algunos ajustes. Hay soporte para varios sistemas operativos actuales y legacy.
¿Qué te conviene para tu aplicación legacy olvidada?
Por lo que he visto con los clientes, creo que Migrate to Virtual Machines es la mejor solución integral: ofrece un buen equilibrio entre el esfuerzo necesario, la automatización, la confiabilidad y el menor downtime para workloads con estado.
Si tienes 1 o 2 imágenes que atender, reinstalar la app sobre una imagen de Google Cloud marcada como deprecated o hacer una conversión manual puede implicar menos esfuerzo para poner una máquina virtual en marcha en GCE. Eso sí, estas opciones tampoco son ideales para migrar workloads con estado que no toleren mucho downtime.
Si ya corres apps containerizadas, estás dispuesto a hacer ajustes a tus workloads cuando haga falta y prefieres no sumar máquinas virtuales a la mezcla, Migrate to Containers puede ser una alternativa interesante. La contra es que no todos los workloads se prestan a este proceso y tus aplicaciones podrían requerir algunas modificaciones.
Por último, si tienes necesidades a gran escala —sobre todo con entornos VMware existentes que pueden tener complicaciones de licenciamiento en la nube—, GCVE te permite preservar parte de tus acuerdos de licenciamiento actuales que no admiten correr ciertos workloads de forma rentable en GCE, además de aprovechar las habilidades y herramientas que ya tengas. Dicho esto, GCVE no suele ser una solución rentable para apenas unas pocas aplicaciones pequeñas.