Cerrar
InicioAzureMoviendo nuestros servicios y máquinas virtuales a Azure (Parte V)

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

En el artículo IV de esta serie (Moviendo nuestros servicios y máquinas virtuales a Azure (Parte IV)), hemos visto como implementar un ASR (Azure Site Recovery), el cual podemos utilizar bien para tener nuestros servidores físicos o virtuales replicados en Azure o para mover nuestros servidores en producción en On-Premises y subirlos a Azure para tenerlos también en producción sin parada de servicio. Por lo que, es tan bien una forma de mover nuestro CPD hacia Azure, pero también podemos ir moviendo nuestras máquinas virtuales o plantillas de servidores de forma “manual”.  Cuando digo de forma manual, me refiero a subir los VHD de nuestras máquinas virtuales y luego configurar el servidor en función de nuestras necesidades. De esta forma, nos llevamos el servidor virtual hacia Azure, lo iniciamos y en cuestión de minutos tenemos nuestros servicios operativos.

En este artículo voy a mostraros como podemos llevar vuestros servidores hacia Azure sin utilizar ASR, utilizando AZCopy. Aquí os dejo el esquema para este artículo, en donde muestro como los VHD de los servidores locales los voy moviendo hacia Azure a través de la línea de Backup de la empresa:

MOVIENDO NUESTROS SERVICIOS Y SERVIDORES A AZURE

Ahora que ya sabemos que lo que queremos es mover los servidores de On-Premises hacia Azure vía AZCopy, veamos cuales son los requisitos principales para cumplir para poder subir nuestros servidores virtuales a Azure: Preparación de un VHD o un VHDX de Windows antes de cargarlo en Azure. Yo os voy a comentar las básicas que debéis cumplir y que os permitirán subir vuestras máquinas Windows sin problema:

  • Habilitar el servicio de escritorio remoto
  • Deshabilitar el Firewall de Windows o habilitar la excepción para el RDS
  • Habilitar el servicio Cliente DHCP
  • El VHD debe ser un disco fijo no dinámico, si está como dinámico debéis convertirlo previamente (Convert-VHD) y debe ser VHD no VDHX
  • La máquina virtual debe de ser de Generación 1 (no sirven de Generación 2)

Además, debemos tener en cuenta que servicios estamos ejecutando en dichos servidores, puesto que no todos los servicios son soportados en Azure: Soporte técnico del software de servidor de Microsoft para máquinas virtuales de Microsoft Azure. De los  que personalmente más me han “fastidiado” no poder configurar es DirectAccess, pero hay más como os muestro a continuación por lo que a servicios de Windows se refiere:

  • Cifrado de unidad de BitLocker (en el disco duro del sistema operativo, se puede usar en discos de datos)
  • Servidor de nombres de almacenamiento de Internet
  • E/S de múltiples rutas
  • Equilibrio de carga de red
  • Protocolo de resolución de nombres de mismo nivel
  • RRAS
  • DirectAccess
  • Servicios SNMP
  • Administrador de almacenamiento para redes SAN
  • Servicio de nombres Internet de Windows
  • Servicio WLAN

En cuanto a roles que no podemos implementar son los siguientes:

  • Servidor de Protocolo de configuración dinámica de host
  • Hyper-V (el rol Hyper-V se admite solamente en máquinas virtuales de Azure de las series Ev3 y Dv3) (De este os hablaré en los próximos artículos, puesto que he tenido que tirar de este recurso)
  • Rights Management Services
  • Servicios de implementación de Windows

Bueno, pues dicho todo esto vamos a empezar por convertir nuestros discos VHDX a VDH y de dinámico a fijo. El proceso es muy sencillo, tiramos de PowerShell: Convert-VHD –Path <ruta VHD o VHDX a convertir> –DestinationPath <ruta VHD convertido> -VHDType Fixed, no voy a poner capturas de pantalla al respecto, porque la verdad no tiene nada más que ejecutar el cmdlet y esperar a que finalice el proceso. Entiendo que no hace falta explicar que la máquina virtual tiene que estar apagada para poder convertir el disco, en mi caso como mis máquinas no sufrirán actualizaciones y las aplicaciones que corren dentro de las máquinas virtuales se conectan con un servidor SQL, lo que he hecho es apagar los servidores, copiar el VHD a otra ubicación, iniciar el servidor y mientras convertir el VDH que había copiado. De esta forma los usuarios pueden seguir trabajando mientras nosotros convertimos el VHD y lo subimos a un blob de Azure, lo que llevará unas horas dependiendo de las líneas de datos con la que contemos.

Mientras vamos convirtiendo los discos de nuestros servidores, vamos a ir creando las cuentas de almacenamiento que vamos a necesitar para subir nuestros VHD y luego utilizarlos con la máquina virtual que vayamos creando. Esto es como siempre, si tenemos un grupo de recursos ya creado para las cuentas de almacenamiento la podemos utilizar, sino es así, lo primero es crearnos nuestro grupo de recursos. Cómo en mi caso ya tengo el grupo de recursos, ya directamente accedo a él y pulsamos en Agregar para empezar a crear recursos:

Bien, como queremos crear una cuenta de almacenamiento, lo primero es filtrar la búsqueda de recursos disponibles, por lo que en la casilla de filtrado escribimos storage y una vez aplicado el filtro elegimos Cuenta de almacenamiento:blob, archivo, tabla, cola:

Pulsamos en Crear

Este es un paso muy importante, porque vamos a especificar el tipo de almacenamiento que vamos a escoger:  Estándar o Premium (Acerca del almacenamiento de discos para máquinas virtuales Windows en Azure). Si necesitáis un almacenamiento rápido para vuestro servidor debemos elegir Premium, como será mi caso. No quiero replicación geográfica (cuestión de costes) y el tipo de cuenta elijo general (Introducción a Microsoft Azure Storage) y el resto de opciones son  triviales:

Una vez creado nuestra cuenta de almacenamiento accedemos a ella y nos vamos a la sección de Información General, a la derecha se nos muestra diferentes opciones, pero yo quiero crear un nuevo Contenedor para albergar mis VHD, para ello pulsamos en + Contenedor:

Especificamos un nombre y el nivel de acceso público, en mi caso VHDS y acceso privada:

Pues ya tenemos nuestro almacenamiento y contenedor preparados para subir nuestros VHD

si nos vamos a la sección de Configuración podemos ver las características del almacenamiento que hemos contratado:

En la sección de Claves de acceso veremos el conjunto de claves que utilizaremos para autenticarnos en dicha cuenta de almacenamiento y poder así subir nuestros VHD, además se nos muestra el nombre de la cuenta. Si pulsamos en las carpetitas que están e la derecha de cada clave las podemos copiar, es un guid bastante largo, por lo que mejor copiarlo al portapapeles desde ahí. Esto lo haremos ya, puesto que luego lo vamos a tener que utilizar a la hora de subir los VHD.

Si nos vamos a la sección de Firewall y redes virtuales (vista previa), podemos configurar el filtrado desde donde vamos a permitir conectarse a esta cuenta de almacenamiento. Esto está en versión preview, pero bueno, es completamente utilizable y nos permite un plus de seguridad a la hora de definir desde donde vamos a permitir las conexiones a esta cuenta de almacenamiento.

Para poder subir los VHDs vamos a necesitar conocer la URL del contenedor, por lo que volvemos a la sección de Información general, pulsamos en el contenedor VHDs que hemos creado antes y pulsamos en las propiedades del contenedor y se nos abrirán una serie de opciones en la parte derecha del navegador, pues hacemos lo mismo que con las claves anteriormente, pulsamos en el icono de marco en verde y nos lo copiamos al portapapeles (o a un notepad para luego recuperarlo):

Ahora que ya tendremos el fichero VHD convertido a disco fijo, lo que nos toca es subir el VHD al contenedor vhds que nos hemos creado en nuestra cuenta de almacenamiento. Yo utilizo AZCopy, pero podéis hacerlo vía PowerShell sin problema. En mi caso he jugado con ambas cosas, pero realmente lo subo con AZCopy. Para los que no sepáis que es AZCopy, aquí os dejo un enlace interesante: Transferencia de datos con AzCopy en Windows, básicamente es una utilidad de línea de comandos para subir ficheros a un blob de Azure desde Windows o Linux. Pues lo primero es instalaros AZCopy, aquí tenéis la ruta de descarga de dicha herramienta: AzCopy en Windows. Yo suelo poner en el path del sistema la ruta del ejecutable de AZCopy, de tal forma que luego lo puedo llamar en cualquier momento desde una línea de comandos sin tener que hacerlo desde la ruta absoluta del fichero. Una vez que tenemos esto listo, he preparado un pequeño script que os muestro a continuación para subir el fichero:

Básicamente tengo una serie de variables que luego llamo en la última línea con el AZCopy,  el cual se pondrá a subir el fichero al contenedor que hemos creado previamente (vhds). Las dos primeras variables son las que comentaré, porque creo que el resto es sencillo de interpretar:

  • $StoreAzure: esa la URL del contenedor donde vamos a copiar el VHD, esta es la URL que os había comentador copiar
  • $KeyStoreAzure: esta es una de las dos claves que tenemos en el store para autenticarnos y así poder copiar los ficheros

Una vez que termine de copiar, si nos vamos a la contenedor vhds veremos que ya tenemos el fichero subido, el cual ya podríamos utilizar para crear nuestra máquina virtual:

Como siempre, cuando estamos utilizando las conexiones de datos, debemos tener en cuenta que durante la subida o descarga de información de Azure, el uso de Internet ser verá claramente afectado.  Aquí os muestro varias capturas del router estamos utilizando para la subida de este VHD, el cual destaco en el esquema de red expuesto en este artículo. Como se aprecia, desde las 10:00 hasta las 12:00 la conexión se está utilizando de forma intensiva, superando los 40Mbps.

 

Esto siempre lo recuerdo, cuidado con ejecutar este tipo de procesos durante las horas de producción de la empresa, puesto que degradaremos claramente la línea de datos que estemos utilizando. Si tenemos varias líneas, es recomendable utilizar alguna de las que tengamos menos saturadas o de backup.

Con el modificador /V: hemos habilitado el log de la transferencia de datos, aquí tenéis un ejemplo:

Una vez finalizada la transferencia del vhd, nos mostrará una ventana similar a esta, en función de si ha tenido éxito o no la transferencia, nos lo indicará:

Yo he subido todos los ficheros que tenía en la carpeta local D:\VHDAZURE, pero si tuviera más fichero se subirían igualmente. En la ayuda de AZCopy veréis todos los modificadores que podéis utilizar, porque podéis subir ficheros específicos, por extensiones, etc…

Ahora lo primero que haremos será copiar la URL del VHD que hemos subido, la cual vamos a necesitar cuando creemos nuestra máquina virtual utilizando dicho VHD. Para ello, nos vamos al contenedor vhds que habíamos creado y vamos a las propiedades del vhd recientemente subido y copiamos la URL:

Ahora vamos a crear un nuevo recursos y en el filtro escribimos Template y de las sugerencias que nos muestra elegimos Templates deployment:

Pulsamos en crear

Lo que haremos será utilizar plantillas que tenemos disponibles para crear una máquina virtual, en mi caso voy a elegir la 201-vm-specialized-vhd-existing-vnet. Esta plantilla nos permitirá crear una máquina virtual (Linux o Windows) y utilizando la red virtual que ya hemos creado con anterioridad, por lo que la buscamos en el seleccionador de plantillas y pulsamos Seleccionar plantilla

Ahora tenemos que cubrir todas las opciones disponibles:

  • Suscripción: elegimos la suscripción donde queremos colocar esta máquina virtual
  • Grupo de Recursos: elegimos o creamos el grupos de recursos donde ubicar la máquina virtual
  • Vm Name: nombre de la máquina virtual a crear
  • Os Type: en mi caso he elegido Linux porque el VHD era un Linux, pero tenéis la opción de Windows disponible
  • Os Disk Vhd Uri: aquí pegamos la URL del VHD que hemos subido al contenedor vhds que previamente hemos ido creando y subiendo respectivamente
  • Vm Size: debemos escribir el tipo de máquina que queremos crear, aquí os dejo un enlace donde podéis encontrar los nombres de las diferentes máquinas virtuales disponibles: Tamaños de máquina virtual de uso general
  • Existing Virtual Network Name: nombre de la red virtual que tengamos o queramos ubicar la máquina virtual
  • Existing Virtual Network Resource Group: nombre del grupo de recuersos donde tenemos la red virtual
  • Subnet Name: nombre de la subred donde vamos a ubicar la máquina virtual
  • Dns Name For Public IP: nombre FQDN para asociar a la IP Pública que tenga la máquina virtual, este registro DNS debe ser único en vuestra suscripción y será un prefijo este FQDN northeurope.cloudapp.azure.com, claramente lo de northeurope es por la ubicación de mi suscripción, cada uno donde las tenga ubicadas tendrá un registro DNS u otro. Si por ejemplo elegimos para la máquina virtual el nombre linuxtest, el FQDN sería linuxtest.northeurope.cloudapp.azure.com.

Si todos los datos ya están cubiertos, pulsamos en Adquirir y se pondrá a crear la máquina virtual con los datos que le hemos indicado:

El proceso tardará apenas un minuto y ya tendremos nuestra máquina virtual disponible:

Una vez completado el proceso, nos vamos  a la sección de Máquinas Virtuales y veremos allí nuestro servidor virtual: 

Con todas las características que le hemos indicado a la hora de su creación:

Dentro de la máquina virtual, si nos vamos a la sección Redes vemos que tenemos las direcciones IP asignadas (privada y pública), pero no tenemos los grupos de seguridad, este debemos crearlo nosotros de forma manual. Los grupos de seguridad de red nos permite definir filtrados de paquetes hacia y desde las interfaces de red de los servidores virtual, aquí os dejo más información al respecto: Filtrado del tráfico de red con grupos de seguridad de red

Sino los creamos, la máquina virtual quedaría expuesta vía la IP Pública a internet con todos los servicios disponibles que tengamos en el servidor virtual, dicho esto, lo primero que hare será crear mi grupo de seguridad para mi servidor. Esto podemos hacerlo desde varios sitios, yo lo que he hecho es  habilitar como favorito la sección de Grupos de seguridad de red en Azure, así que una vez dentro y viendo que como era mi primer servidor virtual en la suscripción no tengo ningún grupo de seguridad, por lo que vamos a crearlo, para ello pulsamos en Agregar

Esto es lo de siempre que creamos un nuevo recurso:

  • Nombre: nombre del grupo de recursos de red, como será para el servidor que he creado, lo nombraré de tal forma que sea descriptivo y fácil de asociar sólo viendo su nombre. Os recuerdo que los grupos de seguridad también se pueden aplicar a nivel de subnet, de ahí que os comente que este será para el servidor que he creado y de ahí su nombre
  • Suscripción: elegimos la suscripción donde se nos facturará dicho recurso
  • Grupo de recursos: como siempre, si ya tenemos uno lo podemos elegir y así ubicará este recurso a crear dentro del mismo y sino nos lo creamos
  • Ubicación: claramente en la ubicación donde está la máquina virtual

Si hemos cubierto todo los campos, pulsamos en Crear

El proceso durará unos segundos, y si volvemos a la sección de Grupos de Seguridad de Red ya vemos que tenemos nuestro primer grupo de seguridad creado:

Si accedemos a él, vemos que ya tenemos algunas reglas por defecto creadas:

Ahora el por defecto es que entre redes se tenga acceso, y luego tenemos una regla que deniega todo el tráfico (como en cualquier firewall, la regla de denegación siempre al final). Pensad que esto es como un firewall para nuestra máquinas virtuales, se leen de forma secuencial  en función de la prioridad que le asignemos a cada regla, pero nunca podemos tocar la regla por defecto que deniega todo el tráfico. Insisto, esto es como un firewall sencillo donde permitimos o denegamos puertos hacia un equipo de nuestra red local, ahora si queremos por ejemplo permitir conexiones al servidor virtual al servicio web que tenemos corriendo dentro del servidor tenemos que crear una nueva regla.

Podemos crear reglas de entrada y salida a la interfaces de red, para ello en la sección de configuración tenemos las siguientes opciones.

  • Reglas de seguridad de entrada: las conexiones hacia el servidor o subred IP, viéndolo desde cualquier origen (otros servidores internos o si tenemos una IP Pública asignada, pues desde internet)
  • Reglas de seguridad de salida: conexiones salientes desde el servidor o subred IP a la que asignaremos este grupo de seguridad

Dicho esto, yo quiero permitir las conexiones al puerto 8080 hacia mi servidor, pues como es una regla de entrada, nos vamos a la sección Configuración  – Reglas de seguridad de entrada y pulsamos en agregar:

Las reglas ya veis que son muy sencillas, creo que no tiene sentido explicar paso a paso cada cuadro a cubrir. Podemos filtrar las conexiones por el origen y destino, por lo que si queremos publicar un puerto para una IP de origen en concreto, lo especificamos y listo:

De momento sólo tenemos las reglas creadas, pero el grupo de seguridad no está asociado a ninguna subred ni máquina virtual, para ello en la sección de  configuración nos vamos a Interface de Red y pulsamos en Asociar

Ahora nos mostrará las interfaces de red que tengamos en nuestra suscrición para asociar el grupo de seguridad, como sólo tenia un servidor virtual, sólo tengo una interfaces de red y será la que seleccione y pulsamos en Aceptar

Si este grupo de seguridad de red lo quisiéramos asociar a una subred, en la sección de configuración nos vamos a la opción de Subredes y pulsamos en asociar:

Lo primero será elegir la red virtual donde se encuentra la subred IP a la cual queremos asociarle este grupo de seguridad de red:

Ahora nos mostrará las subredes que tenemos en dicha red virtual, elegimos la subred que queramos 

Ahora que ya tenemos todo listo, pulsamos en Aceptar y desde ese momento el grupo de seguridad de red está aplicado y operativo:

Si ahora nos vamos al servidor virtual, podemos ver que en la sección de Configuración – Redes ya tenemos nuestro grupo de seguridad de red (NSG-AVG):

Con esto ya tenemos el proceso inicial 100% completo, si ya tenemos la VPN implementada  entre Azure y On-Premises con cambiar el registro DNS que apuntaba al servidor virtual de On-Premises hacia la IP Privada del servidor virtual en Azure, los usuarios ya se podrán conectar a nuestro servidor.

Como veis el proceso es muy sencillo, el cual resumo a continuación:

  • Convertir vuestros discos VHD(x) a VHD como discos fijos
  • Subir el fichero VHD a un blob de Azure
  • Crear la máquina virtual utilizando la plantilla 201-vm-specialized-vhd-existing-vnet
  • Crear y asignar grupos de seguridad de red

En el próximo artículo subiré una máquina con Windows  2003 y utilizaremos otra máquina virtual con Hyper-V habilitado en Azure para diagnosticar el problema que tiene y que hace que no me pueda conectar al servidor una vez subido e iniciado en Azure.

Con este articulo ya hemos visto como subir máquinas a Azure, en el articulo sobre ASR (Azure Site Recovery) también se muestra otro proceso para subir nuestras máquinas virtuales a Azure. El resultado es el mismo, pero con procesos diferentes y con disponibilidades de servicios diferentes. La opción de ASR nos permite seguir utilizando en producción los servicios, con unos RTO y RPO definidos, en donde podemos mover nuestras cargas de trabajo de forma así transparente para el usuario (en función de la ventana de trabajo que hayamos buscado para hacer el corte). Claramente, tenemos que tener todo bien orquestado y configurado (VPN, DNS, etc..), pero si lo hacemos bien, como os digo es casi transparente para los usuarios y el negocio.

Por otro lado, el subir los ficheros VHD de forma “manual”, siempre tiene un corte de servicio (en función del tipo de servicio que tengáis en vuestros servidores).

Consejo rápido (y obvio): si tenéis que subir servidores de aplicaciones y de bases de datos, hacerlo en el mismo proceso. Sino queréis tener problemas de rendimiento, debéis tener ambos servidores en la misma red virtual. Porque si tenéis el servidor de aplicaciones en Azure y el de Base de Datos en On-Premises, es muy probable que estés penalizando el rendimiento porque la conexión sería vía VPN, Internet (No recomendado) o ExpressRoute. Si tenéis un ExpressRoute es muy probable que el rendimiento no se vea tan penalizado, pero si queréis bueno rendimiento debéis tener ambos servidores lo más cerca posible entre si.

Por si no habéis visto alguno de los artículos anteriores de esta serie, aquí os dejo los enlaces, en donde se voy comentando los diferentes servicios que vamos implementando (VPN, Blob, ASR, etc..)

Espero que os sea de utilidad!!!

Reenviar Correos de
Moviendo nuestros se
NO HAY COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This