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

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

Siguiendo con la idea de ir migrando todas nuevas máquinas virtuales a Azure, nos toca el paso de mover nuestros servidores físicos hacia la nube de Microsoft. Muchos de nosotros seguramente tenemos servidores con más de 4 años en nuestra empresa, los cuales no hemos querido actualizar por una u otra razón, pero al final los seguimos teniendo en producción y representan un riesgo importante para nuestra. Es por ello que, nos planteemos en algún momento virtualizarlo y llevarlo a Azure, pero esto también puede ser un problema, puesto que tampoco queremos adquirir recursos para ello. Por lo que, Azure tiene una solución ideal para este tipo de situaciones: Azure Site Recovery

Azure

Esto suele ser muy común, además de que es una solución de Site Recovery muy barata, tanto en tiempo de puesta en marcha (coste personal) como en coste de Azure. Aquí os dejo el coste de tener una máquina replicada en Azure, bien sea una máquina física o virtual de On-Premises:

Pues ya veis, por 20€/Mes/Servidor podemos tener nuestras máquinas replicadas en Azure, además, sea cual sea el tamaño de la máquina. Cuando se ejecute el proceso de failover, es cuando entonces se os cobrará por el tipo de servidor que hayáis escogido. Otra cosa muy interesantes, es la infraestructura que necesitamos tener en On-Premises es simplemente un servidor con Windows Server 2012 R2 o 2016, importante, en inglés. Lo que si tenemos que tener muy en cuenta, son los requisitos que debemos cumplir para poner en marcha un Site Recovery: Matriz de compatibilidad de Azure Site Recovery para la replicación de Azure a Azure. Aquí os voy a poner las versiones de sistemas operativos de las máquinas virtuales que queremos replicar:

Windows

  • Windows Server 2016 (Server Core y Server con Experiencia de escritorio)
  • Windows Server 2012 R2
  • Windows Server 2012
  • Windows Server 2008 R2 con al menos SP1

Linux

  • Red Hat Enterprise Linux 6.7, 6.8, 6.9, 7.0, 7.1, 7.2, 7.3
  • CentOS 6.5, 6.6, 6.7, 6.8, 6.9, 7.0, 7.1, 7.2, 7.3
  • Servidor Ubuntu 14.04 LTS (versiones de kernel admitidas)
  • Servidor Ubuntu 16.04 LTS (versiones de kernel admitidas)
  • Debian 7
  • Debian 8
  • Oracle Enterprise Linux 6.4 y 6.5, en ejecución en el kernel compatible de Red Hat o Unbreakable Enterprise Kernel Release 3 (UEK3)
  • SUSE Linux Enterprise Server 11 SP3
  • SUSE Linux Enterprise Server 11 SP4

Hay más detalles que debéis tener en cuenta, como el tamaño máximo del disco duro de sistema (2TB), tamaño máximo del disco de datos (4TB) y el número de discos duros de datos podemos replicar (64). Ahora vamos a ver la arquitectura que necesitamos disponer para empezar a replicar nuestras máquinas físicas o virtuales en Azure:

Aunque parezca algo bastante complejo, la realidad es que necesitamos un servidor físico o virtual con la instalación de Microsoft Azure Site Recovery Unified, un software que nos descargaremos en el proceso de configuración del Site Recovery en Azure. Este software necesita instalase en un Windows Server 2012 R2, como os comentaba, en una versión en inglés sino no se instalará. La instalación de este software, convertirá a este servidor en el servidor de configuración y de proceso:

  • Servidor de configuración: El servidor de configuración coordina la comunicación entre el entorno local y Azure, además de administrar la replicación de datos.
  • Servidor de proceso: Actúa como puerta de enlace de replicación. Recibe datos de replicación, los optimiza con almacenamiento en caché, compresión y cifrado y los envía al almacenamiento de Azure. El servidor de procesos también instala Mobility Service en los servidores que desee replicar. A medida que crece la implementación, puede agregar más servidores de procesos independientes para controlar mayores volúmenes de tráfico de replicación.

Al final no deja de ser un servidor, el cual recibirás las replicaciones que enviará al vault de Azure, por lo que será dicho servidor el que enviará a Azure únicamente la réplica de las máquinas físicas o virtuales, como si fuera un “proxy”.  De tal forma, todas las máquinas a replicar en Azure, enviarán mediante un agente (Mobility Service) las sincronizaciones hacia el servidor de configuración, y luego el servidor de configuración a Azure. Pues sin más vamos a ello, lo primero que tenemos que hacer es crear nuestro recurso de Site Recovery, por lo que nos vamos a Azure y nos vamos a la sección de Almacenes de Recovery Site …

Si ya tenemos un almacén podemos utilizarlo, pero en mi caso voy a crear un nuevo almacén, para ello pulsamos en Agregar

Escribimos nombre, elegimos la suscripción, el grupo de recursos (yo lo voy a crear) y pulsamos en Crear

En cuestión de segundos ya tenemos nuestro nuevo almacén

Ahora accedemos al nuevo almacén, nos mostrará la consola de administración con la que debemos estar muy familiarizados:

Lo primero que debemos hacer ahora, es preparar la infraestructura, así que vamos a ello. Nos vamos a la sección de Site Recovery y pulsamos en Preparar infraestructura y empezamos con la configuración de “verdad”:

  • ¿Dónde están ubicadas las máquinas?: Indicaremos donde tenemos las máquinas que queremos replicar en Azure, y por lo tanto son las que tenemos en On-Premises, por lo que elegimos Local
  • ¿A donde quiere replicar las máquinas?: Lógicamente queremos replicarlas en Azure, por lo que elegimos Azure
  • ¿Las máquinas están virtualizadas?: En nuestro caso NO, así que debemos elegir No virtualizado/Otro

Como podemos apreciar, básicamente es información relativa desde donde y a donde vamos a replicar nuestros servidores, una vez que hemos cubierto todas las opciones, pulsamos en Aceptar

Ahora nos indica que seleccionemos nuestro Configuration Server, esto es esencial, sin él no podemos replicar nuestras máquinas (físicas o virtuales), recordad  que es nuestro “proxy” entre las máquinas a replicar en On-Premises y Azure. Pues como no lo tenemos, tenemos que agregarlo y lo podemos hacer desde aquí, por lo que pulsamos en + Configuration Server

Nos llevará a la siguiente pantalla, en donde nos descargaremos el software que instalaremos en nuestro servidor (físico o virttual) para que haga de Configuration Server, así que pulsamos en Descargar el Microsoft Azure Site Recovery Unified Setup 

A continuación nos descargamos la clave de registro del almacén, que será lo que nos permita registrar nuestro Configuración Server en Azure

Ahora en el servidor que hará de Configuration Server iniciamos el proceso de instalación del Microsoft Azure Site Recovery Unified Setup y, aquí os muestro lo que ocurriría si lo instalamos en un Windows Server en Español por ejemplo, por lo que tocará tenerlo en Inglés: 

Pues una vez que lo instalamos en un Windows Server 2012 R2 o 2016 en inglés, se inicia el proceso sin problema. Los requisitos previos para el Configuration Server son los siguientes:

  • CPU: 8
  • RAM: 12GB
  • Disco: 600GB libres

Hay más requisitos, pero como básicos a nivel de servidor de configuration server son los comentados, pero luego se requieren una serie de conexiones libres a internet, etc… aquí tenéis toda la información al respecto: https://docs.microsoft.com/es-es/azure/site-recovery/site-recovery-vmware-to-azure-manage-configuration-server

Si es nuestra primera instalación del Configuration Server and Process Server, elegiremos la primera opción, si quisiéramos agregar un nuevo servidor para tener balando de carga para este proceso, elegiríamos la segunda opción. Lo dicho, elegimos la primera opción y pulsamos en Next

Aceptamos el contrato de licencia y pulsamos en Next

Ahora tenemos que elegir la clave para registrar el servidor en Azure, la cual habíamos descargado desde Azure, simplemente la elegimos y pulsamos en Next

Elegimos el tipo de conexión que tiene nuestro servidor hacia internet, en mi caso conexión directa y pulsamos en Next

Ahora el asistente chequeará los requisitos del servidor donde se está instalando, si alguno no cumple os mostrará una alerta al respecto:

Ahora debemos especificar una contraseña para el MySQL que se instalará en este proceso, la escribimos cumpliendo los requisitos indicamos en pantalla y pulsamos en Next

En mi caso como no voy a proteger máquinas virtuales de VMware, elijo No y pulsamos en Next

Dejamos el directorio de instalación por defecto y pulsamos en Next

Si tenemos más de una tarjeta de red, podemos elegir la interface que utilizarán los servidores que vamos a replicar para conectarse con el Configuration Server and Process Server. El puerto por defecto es el 9443, no se recomienda cambiarlo, pero si fuese así, luego los clientes deberíais configurarlos con el puerto que habéis especificado aquí.

Ahora nos muestra un resumen de la instalación que se iniciará a continuación, si todo está correcto, pulsamos en Next

Ahora es cuestión de esperar …

Si todo ha ido bien, esta es la pantalla que debéis ver, ahora sólo toca finalizar la instalación por lo que pulsamos en Finish

Ahora nos indica que ha generado un clave, la cual se utilizará para que los agentes utilicen para autenticarse con el Configuration Server y así poder conectarse y empezar a replicar. Como vemos, la tenemos en el porta papeles, pero sino queremos guardarla ahora, luego la podemos volver a genera en cualquier momento.

Lo suyo ahora sería instalar el cliente Mobility Service en los servidores que queremos replicar, aquí os dejo la instrucciones de instalación del agente: https://docs.microsoft.com/es-es/azure/site-recovery/site-recovery-vmware-to-azure-install-mob-svc El proceso es muy sencillo, si lo hacéis desde una línea de comandos, esto es lo que tenéis que hacer:

1. Copie el instalador en una carpeta local (por ejemplo, C:\Temp) del servidor que desea proteger. Ejecute los siguientes comandos como administrador en un símbolo del sistema:

cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted.

2. Para instalar Mobility Service, ejecute el siguiente comando:

UnifiedAgent.exe /Role “MS” /InstallLocation “C:\Program Files (x86)\Microsoft Azure Site Recovery” /Platform “VmWare” /Silent

3. Ahora el agente debe registrarse en el servidor de configuración

cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe” /CSEndPoint <CSIP> /PassphraseFilePath <PassphraseFilePath>

El instalador copiado en el punto número 1 del proceso de proceso de instalación mediante cli, está en el Configuration Server en la siguiente ubicación: %ProgramData%\ASR\home\svsystems\pushinstallsvc\repository. Para generar la key utilizadad en el paso número tres, lo haremos desde el Configuration Server con el siguiente comando:

Ahora ya tenemos nuestro Configuration Server and Process Server y el servidor a replicar con el Mobility Service instalado, por lo que ya podemos volver a Azure y continuar con la configuración del entorno de replicación. Volvemos a iniciar el proceso de configuración desde la poción de Preparar infraestructura, la primera opción de Objetivo de protección ya lo habíamos hecho antes, por lo que ya no repito los pasos previos. Ahora nos tocará la segunda opción, que es elegir el Configuration Server el cual hemos instalado y registrado ahora mismo, por lo que ya debería aparecernos. Sino aparece, debemos esperar unos minutos, pero de todas formas es bastante rápido este proceso, por lo que ya deberíais poder elegir vuestro Configuration Server:

Ahora tenemos que preparar el destino, que se corresponde con las cuentas de almacenamiento y suscripción que debemos tener en Azure y sino las tenemos las crearemos. Debemos ir cubriendo las diferentes opciones:

  • Suscripción: elegiremos la suscripción donde queremos que MSFT nos facture
  • Seleccionar el modelo de implementación que se usará después de la conmutación por error: elegimos Administrador de recursos
  • Cuenta de Almacenamiento: como yo no tenía ninguna, pulsamos en + Cuenta de Almacenamiento

Ahora nos llevará al asistente de creación de la cuenta de almacenamiento, pulsamos en Crear nueva

Escribimos un nombre para la cuenta de almacenamiento, elegimos el rendimiento y si queremos replicación local o geográfica. Aquí cada uno elegirá lo que considere en función de sus necesidades, las mías son las que estáis viendo en las opciones que he elegido:

Ahora ya podemos elegir la cuenta de almacenamiento que hemos creado y ya elegiremos la red virtual que tengamos disponible y pulsamos en Aceptar

Este también es un paso fundamental, es elegir la directiva de replicación o crearla, en mi caso vamos a crearla y pulamos en + Crear y Asociar 

Debemos cubrir las siguientes opciones:

  • Nombre: nombre de la directiva, que sea descriptivo y corto a ser posible
  • Umbral de RPO en minutos:  Este valor especifica la frecuencia con que se crean puntos de recuperación de datos. Se genera una alerta cuando la replicación continua supera este límite.
  • Retención de puntos de recuperación en horas: Las máquinas virtuales replicadas se pueden recuperar a cualquier momento de un período. Se admite una retención de hasta 24 horas para máquinas replicadas en Premium Storage y 72 horas para almacenamiento estándar.
  • Frecuencia de instantáneas coherente con la aplicación en minutos: La frecuencia (en minutos) con la que se crearán puntos de recuperación que contengan las instantáneas coherentes con la aplicación.

Son parámetros sencillo de entender, pero sino es así, aquí os dejo un enlace para que ampliéis info: https://docs.microsoft.com/es-es/azure/site-recovery/site-recovery-setup-replication-settings-vmware. Si ya tenemos todo listo, pulsamos en Aceptar y empezará a crear y asignar la directiva de replicación:

Le llevará unos minutos completar la tarea, es cuestión de esperar a que finalice el proceso:

Una vez creada, la asignará y si tuviéramos más directivas pues sería cuestión de elegir la que hayáis creado para este proceso y pulsamos en Aceptar

Aquí nos da la posibilidad de descargarnos una utilidad para realizar un cálculo de ancho de banda, almacenamiento y otras opciones que necesitamos ajustar para que no tengamos problemas en nuestra red o que la replicación se vea degradada:

Con esto ya hemos finalizado la preparación del entorno, por lo que pulsamos en Aceptar

Aún no hemos finalizado el proceso en Azure, así que ahora debemos continuar y vamos a la sección de Para máquinas locales y máquinas virtuales …  y nos vamos al Paso 1: Replicar la aplicación, ahora debemos ir completando las tres fases del paso 1. El primero paso será configurar el Origen, por lo que pulsamos en la opción 1 Origen Configurar

Tenemos que elegir el origen de la replicación, claramente es de On-Premises a Azure, por lo que elegimos Local. La ubicación de origen se refiere al Configuration Server, el cual hemos instalado y configurado previamente. El tipo de máquina en mi caso elijo máquinas físicas, porque es lo que quiero replicar y por último, elegimos el servidor de procesos, en mi caso es único y el mismo que el Configuration Server, ahora pulsamos en Aceptar

Ahora debemos establecer la configuración del destino de la máquina replicada, creo que a estas alturas ya no tengo que comentar nuevamente todas las opciones. Aquí como diferente es indicarle la vNet y subred donde vamos a situar el servidor cuando hagamos un failover, una vez elegidos todas las opciones, pulsamos en Aceptar

En este momento debemos agregar el servidor físico que queremos replicar, para ello en el paso número 3 pulsamos en + Máquina física

Ahora escribimos el nombre del servidor, la dirección IP y el tipo de sistema operativo del servidor, pulsamos en Aceptar 

Ahora ya lo(s) tenemos disponible(s), pulsamos en Aceptar:

El paso número 4 también es muy interesante, porque nos permite definir opciones de configuración de las máquinas a replicar:

Al tener el Mobility Service instalado el servidor que vamos a replicar, nos permite elegir los discos duros a replicar, que pueden no ser necesarios todos y sólo queremos algunos de los discos. Una vez seleccionados los discos a replicar, pulsamos en Aceptar 

En el paso número 5 elegimos la directiva de replicación y pulsamos en Aceptar 

Ahora si que si, hemos finalizado, sólo queda apretar el botón y … a replicar nuestra máquina de On-Premises, venga pulsamos Habilitar replicación

En cuestión de minutos, veremos desde las sección de Elementos replicados las máquinas que se están replicando, en mi caso el servidor físico

Si ahora pulsamos encima del servidor replicado, podemos ver las propiedades y características asociadas a este servidor replicado. Por defecto, en función del origen, Azure ya elige el servidor que necesitaríamos contratar cuando lanzásemos el failover:

Si vamos a la sección de Proceso y red podemos ver las características de la máquina virtual y las interfaces de red

Por último, si vamos a la sección de discos veremos los que tenemos replicados (finalmente no he replicado más que el disco de sistema):

Por cierto, la máquina virtual no se creará hasta que no lancemos un failover, de ahí que no veáis ningún servidor virtual creado en vuestro Azure aunque tengáis el Site Recovery implementado:

Por último, comentaros que si tenéis problemas con la generación de puntos de restauración, podéis encontraros con un advertencia como esta:

Si vamos a ver el detalle de la misma, pulsamos en Advertencia

Vemos las causas que pueden estar ocasionando dicho problema, la máquina virtual ya está replicada, pero tiene un desfase en este caso de 240 minutos, pero esta alerta saldría igualmente a los 60 minutos que es lo que hemos establecido en la directiva de replicación:

Si todo está funcionando  bien en vuestro caso, en cuanto  red, conexión de datos (internet), etc.. la solución pasaría por tener una tarea programada en el servidor a replicar ejecutado el proceso vacp.exe con el modificador -systemlevel.

La herramienta vacp.exe es la que se encarga de crear instantáneas para luego enviarlas al Configuration Server y este a Azure, evitando así puntos de incoherencia. El error que os había mostrado, es tal cual, por alguna razón el servidor no es capaz de generarlos de forma automática, por lo que con una tarea programa con la misma frecuencia que el RPO (60 minutos), se ha solventado y funciona perfecto. Ahora ya veo el servidor replicado sin ninguna incidencia:

Nota: Esta solución me ha la dado el soporte de Azure, porque realmente he tenido el problema que os comento y la gente de soporte es lo primero que ha probado y comentado.

Por último, comentar que no necesitamos una VPN configurada entre Azure y On-Premises (Moviendo nuestros servicios y máquinas virtuales a Azure (Parte II)), estos son los requisitos de comunicaciones nuestra infraestructura:

  • Configuration Server: únicamente necesitamos permitir en nuestros firewalls la conexiones al puerto 443 (canal de control) hacia cualquier destino o si queremos filtrarlo, hacia estos destinos:
    •  *.accesscontrol.windows.net
    •  *.backup.windowsazure.com
    •  *.store.core.windows.net
    •  *.blob.core.windows.net
    •  *.hypervrecoverymanager.windowsazure.com
    •  https://cdn.mysql.com/archives/mysql-5.5/mysql-5.5.37-win32.msi (no es necesario para servidores de procesos de escalado horizontal)
    • time.nist.gov
      time.windows.com
  • Servidores Replicados (Mobility Agent): necesitan tener conexión con el Configuration Server en los puerto 443 (canal de control) y 9443 (Transporte de datos)

En el esquema inicial, así lo reflejo:

Si bien es cierto que no hace falta VPN para replicar, si es recomendable si queréis tener un failover y que el servidor se pueda poner en contacto con las redes On-Premises. Esto es algo normal, puesto que entiendo que son servidores que están detrás de los firewalls corporativos y que queremos seguir protegiéndolos aún estando en Azure, así que una vez iniciados en Azure queremos seguir accediendo de forma segura. Sólo volver a recalcar, que no hace falta vpn para repliar las máquinas físicas o virtuales, únicamente para tener acceso seguro desde las oficinas remotas.

Hasta aquí este artículo, en los siguiente documentaré un failover para ver como se tiene que realizar y cuales son la implicaciones a tener en cuenta.

Espero que os sea de utilidad!!

Moviendo nuestros se
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