Moviendo nuestros servicios y máquinas virtuales a Azure (Parte V) – Parte II

En ocasiones nos puede suceder que hemos movido algún servidor a Azure y no hemos cumplido todos los requisitos previos, lo que se traduce en que tenemos algún problema de conexión con dicho servidor. O  bien, en un determinado momento tenemos algún problema con algún servidor que ya tenemos en Azure, y como no tenemos acceso por “consola”, no podemos conectarnos al servidor y solventar el problema. En este caso, tenemos varias opciones:

• Descargarnos el VHD de la máquina virtual (AZCopy y PowerShell) y crear una máquina virtual en Hyper-V en On-Premises utilizando dicho disco y que que ocurre. Una vez corregido el problema, debemos volver a subir el VHD e iniciar el servidor
• Crear una máquina virtual en Azure con el rol de Hyper-V y crear una máquina virtual utilizando el VHD del servidor que tenemos con problemas (Nested virtualization in Azure)

La primera opción es viable, pero teniendo ahora (desde julio de 2017) la posibilidad de tener un servidor virtual en Azure con el rol de Hyper-V, creo que es la mejor solución, por lo menos la más rápida. Claramente no todas las máquinas de Azure soportan Nested Virtualization (virtualización anidada), aquí os dejo las máquinas que están disponibles en Azure para poder habilitar el rol de Hyper-V:

• D2-64 v3 instances are the latest generation of General Purpose Instances. D2-64 v3 instances are based on the 2.3 GHz Intel XEON ® E5-2673 v4 (Broadwell) processor and can achieve 3.5GHz with Intel Turbo Boost Technology 2.0. D2-64 v3 instances offer the combination of CPU, memory, and local disk for most production workloads.
• E2-64 v3 instances are the latest generation of Memory Optimized Instances. E2-64 v3 instances are based on the 2.3 GHz Intel XEON ® E5-2673 v4 (Broadwell) processor and can achieve 3.5GHz with Intel Turbo Boost Technology 2.0. E2-64 v3 instances are ideal for memory-intensive enterprise applications.

Debemos cumplir los siguientes requisitos cuando queremos utilizar la anidación de virtualización para gestión de problemas:

• La máquina virtual de recuperación debe estar en la misma ubicación que la máquina virtual con problemas.
• La máquina virtual de recuperación debe estar en el mismo grupo de recursos que la máquina virtual con problemas.
• La máquina virtual de recuperación debe usar el mismo tipo de cuenta de almacenamiento (Estándar o Premium) que la máquina virtual con problemas.

Y luego a nivel del servidor que tendrá el rol de Hyper-V, estos son los requisitos:

• La máquina virtual de recuperación debe estar en la misma ubicación que la máquina virtual con problemas.
• La máquina virtual de recuperación debe estar en el mismo grupo de recursos que la máquina virtual con problemas.
• La máquina virtual de recuperación debe usar el mismo tipo de cuenta de almacenamiento (Estándar o Premium) que la máquina virtual con problemas

Con estos principios ya claros, ahora nos toca empezar con el proceso de configuración del entorno. En mi caso, he tenido un problema con un Windows Server 2003 que he subido a Azure, utilizando el método explicado en el artículo: Moviendo nuestros servicios y máquinas virtuales a Azure (Parte V). El problema, es que no me podía conectar al servidor virtual una vez configurado e iniciado. Desde Azure veía que tenía asociado su tarjeta, su dirección IP Privada y Pública (para conectarme a ella) y no había manera de conectarse. En la configuración del servidor virtual, veía que tenía tráfico de entrada en la interface de red, pero no de salida, por lo que parecía algo relacionado con las interfaces de red.

Pues lo primero es crear nuestro servidor Dv3 o Ev3, para ello nos vamos a la web de Azure y desde ahí empezamos con la creación de un nuevo servidor con Windows Server 2016:

Aquí es como siempre, cubrimos todos los campos en función de nuestros requisitos. Comentar, que en mi caso veis que tengo puesto en ubicación Norte de Europa, pero es porque no tengo otra captura, porque realmente he tenido que cambiar la ubicación y elegir Oeste de Europa, porque es donde están disponibles este tipo de servidor. Aquí os muestro la disponibilidad geográfica de estos servidores:

• US
  • West 2
  • East
• Europe
  • West
• Asia Pacific
  • Southeast

Aclarado esto, recordad que he elegido Oeste de Europa:

Ahora elijo el tamaño del servidor, en este caso una D4S_v3, que aunque tiene un coste mensual importante yo sólo la utilizaré durante una hora más o menos:

Como he elegido Oeste de Europa y ahí no tengo ubicada mi red virtual, voy a dejar por defecto la creación de la máquina en una subred que me propone por defecto (la cual luego borraré). 

Una vez que ya tenemos todo listo, el último paso es un resumen de la máquina que se procederá a crear y pulsamos en Crear

Como yo tengo todo en la región del Norte de Europa y la máquina virtual que estoy creando en el Oeste de Europa, tengo que mover el VHD de una cuenta de almacenamiento a otra para que esté en la misma zona que el servidor que estoy creando. Recordad que esto es un requisito, por lo que estoy copiando el VHD de mi “servidor con problemas” hacia la cuenta de almacenamiento donde tengo el VHD del servidor que estamos creando. Este proceso de copiado podemos hacerlo también con AZCopy, por lo que es lo que he utilizado:

Como estamos copiando entre entornos de Azure, no nos impacta a nosotros, pero ya veis que en 30 minutos se ha copiado un VHD de 60GB

Mientras tanto, el nuevo servidor ya se ha creado y lo que tenemos que hacer ahora, es conectar el VHD que hemos copiado a dicho servidor virtual. Para ello, desde la sección de Discos del servidor que utilizaremos para instalar el rol de Hyper-V, pulsamos en Agregar disco de datos

Escribimos un nombre para el disco, el tipo de Origen elegimos de un Blob existente y pulsamos en Examinar para buscarlo en la cuenta de almacenamiento y seleccionarlo:

Ahora ya lo tenemos conectado, elegimos que esté habilitado para Lectura/Escritura sino no podemos trabajar sobre él  Ahora nos conectamos al servidor virtual que hemos creado para la recuperación de nuestro otro servidor, y en el administrador de discos ya lo vemos conectado, lo tenemos que dejar en estado Offline (el espacio no disponible es el propio VHD por si necesito ampliar el disco)

Para instalar el rol de Hyper-V lo podemos hacer de forma tradicional con el asistente o bien vía PowerShell, en mi caso lo haremos por PowerShell: Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart. Una vez instalado y reiniciado el servidor, iniciamos la consola de Hyper-V para iniciar la creación de nuestro servidor virtual con el VHD del servidor que queremos recuperar. Pulsamos con el botón secundario del ratón sobre el nombre del HOST de virtualización y nos vamos a New – Virtual Machine

Pulsamos en Next

Escribimos un nombre para el servidor virtual  y pulsamos en Next 

Indicamos Generación 1 y pulsamos en Next

Le asignamos una cantidad de ram que consideremos que se puede iniciar y trabajar con el servidor virtualizado sin problemas, y pulsamos en Next

Elegimos el virtual switch que tenemos configurado en Hyper-V y pulsamos en Next

Ahora le indicamos que añadiremos un disco más tarde, así que elegimos la opción Attach a virtual disk later y pulsamos en Next

Ahora nos muestra un resumen de la configuración de nuestro servidor virtual, si todo está correcto, pulsamos en Finish para iniciar la creación de nuestro servidor virtual

Como no le hemos puesto el VHD en el asistente porque no podíamos, ahora nos vamos a la configuración del servidor virtual, a la sección de IDE Controller 0, seleccionamos Hard Drive y pulsamos en Add

Paso importante, de ahí también lo de dejar Offline el VHD conectado previamente al servidor virtual donde ahora con el rol de Hyper-V instalado estamos configurado otro servidor utilizando dicho disco. Pues bien, aquí debemos elegir la opción de Physical hard disk y elegimos del desplegable el disco que habiamos dejado en Offline y pulsamos en OK

Ahora si ya tenemos todo listo, simplemente nos queda iniciar nuestro servidor virtual y ver cual es el problema de este servidor

Como os había comentado, en mi caso tenía claro que el problema que tenía era relacionado con la interface de red, por lo que es lo primero que he visto tan pronto he podido iniciar sesión en el servidor virtual.  La tarjeta de red virtual se había instalado, tengo conexión pero lo que no tengo es direccionamiento IP:

Como en Azure todo va por DHCP, aunque luego desde el portal de Azure podamos asignar IP fijas, pero los servidores/equipos deben estar configurados de forma dinámica. Lo primero que he hecho es ver si tenía el servicio de Cliente DHCP habilitado y  .. sorpresa, en este servidor me había olvidado de dejarlo habilitado:

Una vez habilitado, lo que haré será apagar el servidor virtual que tenemos dentro del servidor de Azure. Luego, eliminar el servidor virtual que hemos creado para instalar el rol de Hyper- V, ya no lo necesitamos (además así nos ahorramos unos € importantes)

Recordad, como en mi caso estoy en regiones diferentes, me toca volver a copiar el VHD de vuelta a su ruta original, así que nuevamente utilizo AZCopy:

Una vez copiado el VHD, como la ubicación y el nombre del fichero no ha cambiado, inicio el servidor virtual que ya tenía creado y al cual no me podría conectar, y fijaros que ya tengo tráfico de salida en la interface de red, por lo que pinta bien:

Y listo, me conecto por la IP Públida (o privada en mi caso porque tengo VPN con mi CPD desde Azure), y como vemos ya tengo acceso a mi servidor virtual:

En mi caso el problema de mi servidor era sencillo de solucionar, pero bueno, el proceso para otros servidores que no os inician o tienen problemas, es el mismo. Además, una vez en el Hyper-V del servidor que creamos para virtualizar en Azure, ya es una conexión por consola como si lo tuviéramos en On-Premises, por lo que si tenéis que reinstalar u otros diagnósticos podrías sin problema.

Este proceso es muy útil tenerlo en cuenta, sino sería muy complejo (en tiempo o esfuerzos) de recuperar algún servidor que tengamos en Azure. Nunca estamos libres de tener algún contratiempo con algún servidor, por lo que debemos tener siempre presentes este tipo de procesos para saber que podemos tener un plan B para recuperar nuestras máquinas.

Como todos los artículos sobre esta serie van relacionados, aquí os dejo los artículos anteriores:

• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte I)
• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte II)
• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte III)
• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte IV)
• Moviendo nuestros servicios y máquinas virtuales a Azure (Parte V)

Espero que os sea de utilidad!!!