Migrando de Azure Classic (ASM) a Azure Resource Manager (ARM)

Aunque esta publicación la materializa servidor, he de comentar que es un trabajo del equipo completo de Enterprise IT de Plain Concepts, donde todos y cada uno de nosotros estuvimos involucrados con las distintas tareas que voy a comentar aquí.

Llevamos ya unos cuántos meses contándoos la potencia y enormes ventajas del nuevo modelo de recursos de Azure, que cambia nuestra forma de entender y trabajar con la plataforma… y lo hace para muy bien. Sin embargo, hacemos una confesión pública en estas líneas: el core de la infraestructura de Plain Concepts aún se encontraba en el modelo clásico. Y es que aunque seguimos totalmente un modelo customer first, lo coherente es predicar con el ejemplo, mas sea dicho que estábamos ansiosos de disponer de todas las ventajas de ARM en nuestro entorno productivo.

No queriendo dilatar más la situación planificamos la migración de toda la infraestructura. ¿Cómo procedimos a ello? Es justamente lo que os voy a contar en esta publicación.

¿Qué servicios necesitan migrarse?

Los servicios sobre los que vamos a tener que trabajar son sobre todo los basados en IaaS y todos los que de alguna manera estén relacionados con los mismos. A continuación os voy a enumerar los más importantes:

• Storage Accounts.
• Virtual Machines.
• Virtual Networks, incluyendo gateways, network security groups, reservas de direcciones IP, etc…
• Cloud Services. Cuidado aquí, porque si estáis utilizando máquinas virtuales auto-escaladas debéis pasar a utilizar los Azure VM Scale-Sets, que quedan fuera del ámbito de este artículo.
• Traffic Manager.
• Backup.

La mayor parte de los servicios basados en PaaS no necesitan atención alguna, ya que automáticamente pasan a beneficiarse del modelo ARM. Entre estos servicios encontramos App Service o SQL Database.

También es interesante mencionar servicios que de momento sólo funcionan en el modo clásico, como StorSimple o Azure Site Recovery.

Estrategias de migración

Muchos ya habréis adivinado lo que voy a comentar a continuación: no hay un botón mágico ni una forma automatizada de mover servicios entre ASM (modo clásico) y ARM. Por tanto, cuando afrontamos un movimiento implica crear de nuevo el servicio en ARM y mover toda la información en un proceso bastante manual.

Hay dos formas de afrontar la migración:

• Utilizar los scripts de PowerShell de FullScale180 que Microsoft menciona en su documentación oficial. Estos se encuentran en un repositorio de GitHub, justamente aquí.
• Preparar nosotros mismos un proceso adaptado a las necesidades del entorno.

Después de examinar los scripts y reconocer el enorme trabajo que se llevó a cabo con los mismos, decidimos que era mejor optar por llevar a cabo el proceso de forma manual, fundamentalmente motivados por tener un mayor control.  Los scripts migran una única máquina virtual por ejecución y realizan una serie de asunciones sobre las redes virtuales, los network security groups y los discos que preferíamos tener más controlados. ¡No obstante no dejes de echarles un vistazo por si se adaptan a tus necesidades y te ahorran mucho trabajo!

Para nuestra migración nos marcamos una serie de requisitos:

• Copiar el entorno 1:1, es decir un clon idéntico del que tenemos en ASM. Esto implica que no vamos a redesplegar y reconfigurar servicios.
• Como consecuencia del punto anterior, debe mantener el mismo direccionamiento IP y subredes que ya teníamos definidas en la red virtual de ASM.
• Como no podía ser de otra forma, también debemos tener una configuración similar en la puerta de enlace VPN que creemos en el servicio.

Estos requisitos nos llevan a una estrategia de irremediable corte de servicio, planificado a una hora fuera de oficina. Con otro tipo de requisitos podríamos hacer el movimiento sin prácticamente ningún corte. Y con estos puntos en mente ya podíamos elaborar nuestro backlog particular.

El backlog

Que a alto nivel consistía en lo siguiente:

1. Asegurarnos de que tenemos acceso administrativo a Azure y Office 365 sin necesidad de ADFS. Dado que nuestros ADFS se encuentran en Azure y ASM, siendo parte de la infraestructura que vamos a migrar, sería muy divertido apagarlos y que se nos cierre o caduque la sesión que tenemos abierta.
2. Crear el o los grupos de recursos de ARM donde vamos a alojar todos los nuevos elementos de nuestra infraestructura.
3. Crear las Storage Account necesarias en ARM, tanto las estándar como las premium.
4. Crear la red virtual en ARM y configurarle el direccionamiento análogo al que ya teníamos en ASM.
5. Realizar el corte de servicio fuera de oficina y comenzar con la intervención oficial.
6. Copiar todos los VHDs de las máquinas virtuales existentes de las Storage Account ASM a ARM.
7. Crear en ARM las máquinas virtuales utilizando los discos que hemos copiado en el paso 6.
8. Crear los balanceadores de carga internos y externos.
9. Restablecer las conexiones Site to Site con las distintas localizaciones on-premises de Plain Concepts.
10. Realizar los cambios DNS oportunos.
11. Comprobar el funcionamiento del entorno.

Copiando VHDs entre ASM y ARM

La primera tarea es una de las más triviales, pero quizás la que más dolor de cabeza nos dio. Consiste en copiar los VHDs de las máquinas virtuales de una Storage Account basada en ASM a otra que lo esté en ARM. Ambas cuentas de almacenamiento operan de forma indistinta y por tanto se utilizan igual. La herramienta altamente recomendada para esta tarea es AzCopy, que realiza una copia asíncrona entre las cuentas sin necesidad de descargárnosla a nuestra máquina. Su sintaxis es extremadamente simple:

¿Qué nos dio dolor de cabeza? Que la copia fue más lenta de lo que habíamos estimado originalmente, cosa que no nos ocurrió con todas nuestras Storage Account. Es posible, que tal y como advierte TheCodeJunkie es este post, estuviéramos trabajando sobre una Storage Account muy antigua que no tenía ciertas capacidades, pero es un tema en el que no entramos en profundidad. Nos tocó ser pacientes sin más.

Como detalle recordad que copiamos discos y no plantillas de máquinas virtuales. No se trata de imágenes con sysprep aplicado.

Creando máquinas virtuales con nuestro disco como disco del sistema

Cuando ya tenemos nuestros discos en la Storage Account ARM, podemos proceder a crear las máquinas virtuales. Sin embargo, lo primero con lo que nos encontramos es que a día de hoy no hay ninguna opción en el portal para crear una máquina virtual ARM utilizando un disco existente en lugar de las plantillas de la galería. Afortunadamente, la capacidad sí que se encuentra ahí y podemos utilizarla, sólo que para ello tendremos que utilizar una plantilla JSON.

Si vamos al repositorio GitHub de la Azure Quickstart Templates, encontraremos una que nos llama mucho la atención: 101-vm-from-user-image. ¡Justo lo que necesitamos! Si examinamos la plantilla veremos que promete, pero que se nos queda corta para nuestras necesidades debido a que:

• Está preparada para crear una máquina virtual desde una imagen con sysprep a modo de plantilla, no una VM ya existente.
• Crea una red virtual por cada máquina que creemos.
• No especifica dirección IP privada para la máquina.
• No especifica Storage Account para los diagnósticos.
• No especifica grupo de disponibilidad.
• Los nombres de los recursos no se adaptan a nuestra nomeclatura.

¡Pero esto no es ningún problema! La plantilla nos da un estupendo punto de partida para modificarla y adaptarla a nuestras necesidades, que tras pasar por nuestro particular taller quedó así:

ATENCIÓN: Esta plantilla está preparada para máquinas de un solo disco (el del sistema). Necesita una ligera adaptación muy trivial para máquinas donde se usa más de un disco para que estos se desplieguen junto con el resto. ¿Y no nos valdría esta plantilla y ya adjuntamos el resto de discos después? La respuesta es NO. La razón es que al introducir la plantilla en Azure y ejecutarla, este aprovisiona la VM y la arranca. Si al arrancar el sistema no encuentra las unidades donde espera encontrar datos –como por ejemplo, las bases de datos de un controlador de dominio-, la máquina se puede volver inconsistente, pudiendo llegar a perderla.

Aplicando plantillas JSON en Azure

Nada más sencillo que acudir al portal y buscar el elemento Template deployment.

Tras lo cual copiamos y pegamos nuestra plantilla en el editor de texto:

Tras guardar la plantilla, Azure comprobará que la sintaxis JSON es correcta y en caso afirmativo, nos permitirá pasar a los parámetros. Que quedan tal y como hemos definido:

Y tras ello Azure comenzará con el trabajo de implementación de la máquina. Como comentamos en otra ocasión, la potencia de ARM nos permitirá guardar la plantilla que generamos para futuros usos. Es importante reseñar que pueden producirse errores de ejecución en la plantilla, que solo veremos al aplicarla (ej: nombres de recursos que ya se encuentran en uso). Si tenemos el infortunio de caer en esta situación, no tendremos más remedio que eliminar manualmente los elementos creados (o bien el grupo de recursos si trabajábamos de nuevas con él) y comenzar de nuevo.

Conclusiones

Mover infraestructura de ASM a ARM no es a día de hoy un trabajo automático y requiere de un extenso análisis y elaboración de estrategia en función del tamaño y la criticidad del entorno. Las ventajas del movimiento a ARM son evidentes y hacen que en la mayoría de los casos compense el esfuerzo. Por otro lado y desde el punto de vista de seguridad, dado que nunca eliminamos en el entorno original de ASM, siempre existe la posibilidad de hacer rollback si las cosas llegasen a ponerse muy feas durante el proceso.

¿Te ha resultado interesante? ¡Déjanos un comentario si nos quieres decir algo!

Happy ARMing!