[ASR] Proteger máquinas administradas con Hyper-V - Parte 5

Entradas de esta serie:

Proteger máquinas administradas con Hyper-V - Preparar la infraestructura
Proteger máquinas administradas con Hyper-V - Replicación inicial
Proteger máquinas administradas con Hyper-V - Conmutación por error de prueba
Proteger máquinas administradas con Hyper-V - Conmutación por error planeada
Proteger máquinas administradas con Hyper-V - Conmutación por recuperación (failback)

CONMUTACIÓN POR RECUPERACIÓN - FAILBACK

Hemos llegado a la parte final de esta serie, en la entrega anterior ejecutamos una conmutación por error planeada, lo cual significa que trabajamos directamente en la máquina creada en Azure, y la máquina en el entorno local fue apagada, ahora después de haber hecho cambios en la base de datos SQL en Azure llegó la hora de volver a poner nuestro entorno local productivo, lo cual se conoce como failback, durante este proceso todos los cambios hechos en la máquina en Azure serán replicados hacia el entorno local, veamos el proceso completo.

Nótese que la dirección de la replicación ahora tiene como origen Microsoft Azure y como destino On-premises

En Data Sync hemos seleccionado minimizar tiempo de inactividad, donde el proceso que se realiza es el siguiente:

1. Crea un snapshot de la máquina virtual en Azure y lo copia al Hyper-V del entorno on-premises, pero la máquina sigue en ejecución en Azure.
2. Se apaga la máquina virtual en Azure (inicio del tiempo de inactividad), por lo cual no se aceptarán más cambios, y se envían los últimos cambios (delta) a la máquina virtual en Hyper-V

Si deseamos podemos marcar la casilla de verificación para crear la máquina virtual en el entorno local en caso de que no exista.

Después de hacer clic en Aceptar veamos a nivel de Hyper-V lo que está ocurriendo.

Hacemos clic derecho sobre la máquina replicada y seleccionamos View Replication Health

Podemos observar en el estado que la operación de failback está en progreso

Desde la misma consola de Hyper-V podemos ver el avance de la operación.

Una vez se terminen de enviar los datos se solicitará la intervención del usuario para iniciar el tiempo de inactividad, que es cuando se apagará la máquina en Azure.

Hacemos clic en la parte superior en Completar conmutación por error planeada nos saldrá un mensaje solicitando confirmación, hacemos clic en Sí

En este instante se apagará la máquina en Azure, se enviarán los cambios pendientes al entorno local y por último se iniciará la máquina en Hyper-V

Al finalizar, veremos todas las tareas ejecutadas, y como último paso ya debe estar encendida la máquina virtual en Hyper-V y apagada la máquina en Azure.

Estado de la máquina en Azure:

Estado de la máquina on-premises en Hyper-V:

Ahora vamos a verificar la base de datos en la máquina recién iniciada en Hyper-V, debería estar el registro que agregamos en la base de datos cuando la máquina estaba operando en Azure.

Como podemos apreciar en la imagen anterior, están los dos registros, el segundo fue el que agregamos cuando hicimos la conmutación por error planeada e iniciamos la máquina en Azure.

Una vez hemos verificado que la máquina se encuentra en el estado que necesitamos, podemos regresar al portal de Azure y confirmar la conmutación por recuperación (failback).

Está operación una vez confirmamos no podemos dar marcha atrás.

Esperamos a que el proceso finalice.

Una vez finalice el proceso debemos habilitar la replicación inversa, es decir, que ya no estamos replicando desde Azure hacia el entorno local, sino que ahora vamos a replicar desde el entorno local hacia Azure.

Hacemos clic en Aceptar para iniciar la replicación inversa

Una vez finalizado el proceso, la replicación ya quedó funcionando como al principio, desde nuestro entorno local hacia Azure, y de esta forma hemos finalizado el proceso de failback.

Con esta última entrega hemos finalizado esta serie sobre protección de máquinas virtuales administradas con Hyper-V utilizando Azure Site Recovery. Espero que la información aquí plasmada sea de su utilidad. 

Un abrazo!

[ASR] Proteger máquinas administradas con Hyper-V - Parte 4

Entradas de esta serie:

Proteger máquinas administradas con Hyper-V - Preparar la infraestructura
Proteger máquinas administradas con Hyper-V - Replicación inicial
Proteger máquinas administradas con Hyper-V - Conmutación por error de prueba
Proteger máquinas administradas con Hyper-V - Conmutación por error planeada
Proteger máquinas administradas con Hyper-V - Conmutación por recuperación (failback)

CONMUTACIÓN POR ERROR PLANEADA

En la entrada anterior vimos cómo ejecutar una conmutación por error de prueba, lo cual es bastante útil en los momentos en que deseemos ver si nuestro DRP funciona tal como esperamos que lo haga, también puede ser ejecutado con fines de auditoría, con ello existe la posibilidad de que deseemos ejecutar la conmutación por error y que la infraestructura de Azure pase a ser el entorno productivo, a esto se le conoce como conmutación por error planeada, lo cual significa que la infraestructura on-premises dejará de estar operativa y en su lugar se activará la réplica en Azure, pueden existir varias razones para hacerlo, una de ellas puede ser que necesitamos realizar alguna actividad de mantenimiento en la infraestructura on-premises y debemos apagar los servidores de virtualización,  por ello "planeamos" conmutar por error a nuestro sitio alterno que en este caso se trata de Azure, y precisamente de eso se trata esta cuarta entrega.

El proceso para ejecutar la conmutación por error planeada es similar al que realizamos para ejecutar la conmutación por error de prueba, y básicamente lo que debemos hacer es ingresar al elemento protegido desde el portal de Azure y hacer clic en Conmutación por error planeada

En la dirección de la conmutación por error se puede apreciar que es desde On-premises hacia Microsoft Azure.

Una vez inicie el proceso de conmutación por error, si verificamos el estado de replicación desde Hyper-V veremos que el estado es Prepared for planed failover

A diferencia de la conmutación por error de prueba, en la planeada la máquina de origen se apaga una vez se replica el delta de los cambios.

Solo resta esperar a que el proceso finalice, podemos ver el progreso desde el portal.

Como se puede apreciar en la imagen anterior, la última parte del proceso es iniciar la máquina virtual replicada, ahora la máquina no se acompaña de la palabra "test" al final del nombre como ocurre con la conmutación por error de prueba.

En mi caso le asignaré una dirección IP pública para tener acceso a la misma y revisarla, pero bien se puede tener acceso a través de una VPN que tengamos establecida o incluso usando Azure Bastion.

Ahora que tengo acceso a la máquina voy a ingresar un registro en la base de datos Usuarios

Ahora en mi base de datos de prueba tengo dos registros.

Una vez que hemos probado que nuestra aplicación, base de datos o lo que sea que hayamos replicado está funcionando como debe ser, podemos "confirmar" ese punto de restauración, de no ser así podemos cambiar a otro punto de restauración, si vemos que todo luce bien hacemos clic en Confirmar

Nos pide confirmación, ya que el punto de restauración no se podrá cambiar una vez confirmado.

Una vez confirmado el punto de restauración también lo podremos ver en el estado.

Con esto hemos finalizado la conmutación por error de prueba, en la próxima entrada veremos cómo realizar el failback desde Azure hacia el entorno on-premises.

Continúa en: Proteger máquinas administradas con Hyper-V - Conmutación por recuperación (failback)

[ASR] Proteger máquinas administradas con Hyper-V - Parte 3

Entradas de esta serie:

Proteger máquinas administradas con Hyper-V - Preparar la infraestructura
Proteger máquinas administradas con Hyper-V - Replicación inicial
Proteger máquinas administradas con Hyper-V - Conmutación por error de prueba
Proteger máquinas administradas con Hyper-V - Conmutación por error planeada
Proteger máquinas administradas con Hyper-V - Conmutación por recuperación (failback)

CONMUTACIÓN POR ERROR DE PRUEBA

En esta entrega vamos a ver cómo se realiza una conmutación por error de prueba, esto significa que podemos probar la máquina que tenemos replicada en Azure sin necesidad de afectar nuestro entorno local, la máquina en Hyper-V seguirá operando normalmente mientras que en Azure se creará una nueva máquina utilizando la réplica exacta de nuestra máquina en el sitio local, esto nos permite realizar pruebas y verificar que todo funcione de forma correcta para que en caso de un evento de fallo real en el entorno local estemos tranquilos de que la réplica que tenemos en la nube funcionará como esperamos.

Ya que tenemos un elemento replicado, al ingresar al mismo podemos ver su estado y también encontramos las opciones para ejecutar la conmutación por error, es importante recordar que la conmutación por error no es automática, por lo que si sucede algo en nuestro entorno de producción local debemos iniciar de forma manual la conmutación por error.

Existen 3 formas de conmutar por error: Conmutación por error de prueba (la que veremos en esta entrega), Conmutación por error planeada (sin pérdida de datos), y conmutación por error, que es la que debemos activar en caso de una falla real. En la parte superior tenemos todas las opciones, veamos ahora cómo funciona la conmutación por error de prueba.

Como podemos ver en la siguiente imagen se observa en primer lugar la dirección de la conmutación por error, donde el origen es On-premises y el destino es Azure, también podemos elegir desde cuál punto de recuperación vamos a restaurar la máquina, en este caso dejamos el más reciente, y por último seleccionamos la red virtual en Azure, la cual ya hemos creado previamente ASR-VNet. 

Solo resta esperar hasta que la máquina se cree en Azure utilizando el disco que ya tenemos replicado desde nuestro entorno local y que ya se encuentra en una cuenta de almacenamiento en Azure, una vez la máquina haya sido creada se unirá a la red que definimos. Al tratarse de una conmutación por error de prueba, a la máquina virtual creada se le adicionará la palabra "test" al final del nombre, en mi caso la máquina se llama SQL01 una vez creada se llamará SQL01-Test como se muestra a continuación.

Una vez crear la máquina, la podemos encontrar en Máquinas virtuales, solo nos resta iniciar y verificar que todo funciona de manera correcta. Vamos a iniciar nuestro servidor e iniciar el SQL Server Management Studio y ver que en efecto tenemos acceso al motor y a nuestra base de datos.

Una vez probemos la máquina y verifiquemos que todo está bien, podemos dar por finalizada la conmutación por error de prueba. En el estado se indicará que está pendiente la limpieza, esto significa que los recursos creados serán eliminados una vez hemos finalizado con las pruebas.

Al hace clic en el enlace, nos lleva al blade donde realizamos lo siguiente para finalizar:

1. Notas: Aquí simplemente documentamos el resultado de las pruebas, si todo salió bien o si hay algo que se deba corregir.
2. Si marcamos esta casilla estamos indicando que se eliminen las máquinas creadas.
3. Hacemos clic en Aceptar para finalizar

De esta forma hemos terminado con la conmutación por error de prueba, en la próxima entrega veremos cómo ejecutar una conmutación por error planeada.

Continuúa en: Proteger máquinas administradas con Hyper-V - Conmutación por error planeada

[ASR] Proteger máquinas administradas con Hyper-V - Parte 2

Entradas de esta serie:

Proteger máquinas administradas con Hyper-V - Preparar la infraestructura
Proteger máquinas administradas con Hyper-V - Replicación inicial
Proteger máquinas administradas con Hyper-V - Conmutación por error de prueba
Proteger máquinas administradas con Hyper-V - Conmutación por error planeada
Proteger máquinas administradas con Hyper-V - Conmutación por recuperación (failback)


REPLICACIÓN INICIAL

Ya que hemos preparado la infraestructura para Azure Site Recovery, ya estamos listos para iniciar la replicación de las máquinas virtuales.

En el almacén de Recovery Services bajo Elementos protegidos seleccionamos Elementos replicados

Ahora hacemos clic en Replicar en la parte superior.

Completamos los siguientes pasos:

1. Origen: Seleccionamos Local
2. ¿Va a realizar una migración? como ya mencioné en la parte 1 de esta serie, no se trata de una migración sino de una replicación con fines de recuperación de desastres.
3. Ubicación de origen: Seleccionamos nuestro sitio de Hyper-V On-premises
4. Hacemos clic en Aceptar

Ahora vamos a configurar el destino:

1. Grupo de recursos posterior a la conmutación por error: Seleccionamos el grupo de recursos donde nuestras máquinas se crearán cuando ejecutemos la conmutación por error, este caso tenemos el grupo de recursos llamado WACResourceGroup
2. Modelo de implementación posterior a la conmutación por error: Resource Manager
3. Cuenta de almacenamiento: Seleccionamos la cuenta de almacenamiento que creamos previamente asrstorage2019
4. Red de Azure: Seleccionamos la red virtual previamente creada ASR-VNet
5. Hacemos clic en Aceptar

En el siguiente paso vamos a seleccionar las máquinas virtuales que vamos a replicar, en este caso voy a seleccionar una máquina que tiene SQL Server instalado llamada SQL01 en mi Hyper-V local. Hacemos clic en Aceptar

En el paso 4 Configurar propiedades podemos seleccionar el tipo de sistema operativo, el disco del sistema operativo y los discos de datos.

Por último en el paso número 5, debemos seleccionar la directiva de replicación, la cual previamente ya hemos creado con nombre ASRPolicy. Hacemos clic en Aceptar

Con todos los pasos finalizados solo nos resta hacer clic en el botón Habilitar replicación

Ahora solo debemos esperar a que finalice la replicación inicial.

Solo restar esperar hasta que el proceso de replicación inicial llegue al 100%

Al finalizar el estado pasará a ser Protegido

Desde el portal de Azure tenemos la posibilidad de ver el diagrama de la infraestructura.

Con esto hemos finalizado esta parte de la serie, en la próxima entrega veremos cómo ejecutar una conmutación por error de prueba.

Continúa en : Proteger máquinas administradas con Hyper-V - Conmutación por error de prueba

[ASR] Proteger máquinas administradas con Hyper-V - Parte 1

Entradas de esta serie:

Proteger máquinas administradas con Hyper-V - Preparar la infraestructura
Proteger máquinas administradas con Hyper-V - Replicación inicial
Proteger máquinas administradas con Hyper-V - Conmutación por error de prueba
Proteger máquinas administradas con Hyper-V - Conmutación por error planeada
Proteger máquinas administradas con Hyper-V - Conmutación por recuperación (failback)


En esta serie de post vamos a ver cómo proteger con Azure Site Recovery las máquinas virtuales que tenemos en nuestras instalaciones locales (on-premises) virtualizadas con Hyper-V. Si lo que deseas es proteger máquinas virtuales que se encuentren protegidas con System Center Virtual Machine Manager te recomiendo revisar la siguiente serie de posts en los cuales explico cómo hacerlo: Recuperación de VMs de Hyper-V administradas con Virtual Machine Manager.


A continuación el diagrama de arquitectura utilizado para replicar máquinas desde Hyper-V hacia Azuere sin utilizar VMM

Nota: En los pasos que se describen a continuación se asume que ya se cuenta con un almacén de Recovery Services.

PREPARAR INFRAESTRUCTURA

Al ingresar al almacén de Recovery Services, en la parte de introducción, hacemos clic en Site Recovery y luego en Preparar infraestructura

Lo cual nos llevará de manera guiada sobre cada una de las actividades que debemos realizar para proteger las máquinas, a continuación veamos cada una de las 5 tareas que debemos ejecutar:

El primer paso se llama Objetivo de protección y es donde decimos desde dónde y hacía dónde vamos a replicar, los detalles a continuación:

1.  ¿Dónde están ubicadas las máquinas? aquí tenemos dos opciones: Local o Azure, ya que no solo tenemos la posibilidad de proteger máquinas que se encuentren en el entorno local sino dentro de Azure podemos proteger máquinas por ejemplo en otra región, en este caso al tratarse de una implementación de Hyper-V local vamos a seleccionar la opción Local
2. ¿A dónde quiere replicar las máquinas? podemos replicar las máquina no solamente en Azure sino por ejemplo a otro centro de datos nuestro fuera de Azure, en este caso vamos a replicar hacia Azure así que seleccionamos Para Azure
3. ¿Va a realizar una migración? esta parte es importante, ya que anteriormente Microsoft recomendaba utilizar Site Recovery para hacer migraciones, si bien aún se puede hacer, Microsoft ahora recomienda usar Site Recovery solo para recuperación de desastres y sugiere utilizar su herramienta Azure Migrate para hacer migraciones, de hecho si esta opción seleccionamos Sí nos saldrá la recomendación, en nuestro caso no se trata de una migración, así que seleccionamos No
   
4. ¿Las máquinas están virtualizadas? Tenemos la posibilidad de proteger máquinas virtualizadas con Hyper-V, VMWare e incluso servidores físicos, en esta ocasión estamos trabajando con Hyper-V así que seleccionamos Sí, con Hyper-V
5. ¿Está usando System Center VMM para administrar los host de Hyper-V? Seleccionamos No, si sus máquinas de Hyper-V sí están siendo administradas con VMM, puedes leer esta serie de artículos que escribí al respecto.

PLANEAMIENTO DE IMPLEMENTACIÓN

En este paso se nos sugiere descargar la herramienta de planeamiento, mediante la cual podemos calcular los recursos que necesitamos en Azure para que nuestra solución funcione de manera óptima como por ejemplo almacenamiento, ancho de banda, entre otros e incluso podemos ver cuál sería el precio aproximado de estos recursos, si se trata de una puesta en producción es altamente recomendable hacer este ejercicio para evitar futuros dolores de cabeza, para nuestro caso al tratarse de un ejercicio didáctico indicaremos: Lo haré más tarde

ORIGEN

Este paso se compone de dos tareas: vamos a crear un sitio de Hyper-V y luego agregamos los servidores de Hyper-V, primero hacemos clic en  + Sitio de Hyper-V

Nos solicita un nombre para el sitio (puedes elegir cualquiera) en mi caso lo llamé On-premises

Ahora ejecutamos la segunda tarea que es agregar el servidor de Hyper-V

A continuación vamos a registrar los servidores de Hyper-V, para ello debemos asegurarnos de que las indicaciones 1 y 2 de la siguiente imagen se cumplan, es decir; que los host sean Windows Server 2012 R2 o superior  y en caso de utilizar proxy establecerlo para poder obtener acceso a las direcciones URL del servicio.

Cumpliendo lo anterior, podemos ir directamente al tercer paso que es descargar el instalador del proveedor de Azure Site Recovery (el cual debemos instalar en cada uno de los hosts).

Una vez descargado el instalador procedemos con su instalación en cada uno de los hosts de Hyper-V

Dejamos habilitadas las actualizaciones a través de Microsoft Update y hacemos clic en Next

Seleccionamos la ruta donde se instalará tanto el proveedor con el agente de Recovery Services y hacemos clic en Install

Una vez finalice la instalación de los componentes debemos registrar el servidor en el almacén de Site Recovery, para ello hacemos clic en el botón Register

Pero antes de de continuar el registro, debemos ir al portal de Azure y descargar la clave de registro, que es la tarea número 4 después de instalar el agente, esta clave la utilizaremos a continuación:

En Key file hacemos clic en Browse y seleccionamos el archivo con la clave que hemos descargado previamente desde el portal, el resto de datos son cargados de forma automática desde el archivo de registro. Hacemos clic en Next para continuar.

Indicamos que nos vamos a conectar sin usar proxy, y hacemos clic en Next

Y esperamos hasta que finalice el registro:

Por último, hacemos clic en Finish para terminar.

De esta forma ya tenemos registrado nuestro host con el almacén de Site Recovery. Ahora debemos volver al portal para seguir con la preparación.

Podemos notar que ya hemos realizado las dos tareas del paso 3, hacemos clic en Aceptar para concluir para ir al siguiente paso.

DESTINO

Aquí básicamente vamos a preparar en Azure lo necesario para que las máquinas se puedan replicar y funcionar sin problemas, esto incluye la creación de una cuenta de almacenamiento donde se guardarán los discos de las máquinas y por supuesto la red virtual que utilizarán las máquinas en el momento que se realice la conmutación por error (failover).

Como vemos en la siguiente imagen se indica que debe haber una cuenta de almacenamiento compatible, en caso de no existir podemos crearla desde aquí mismo, como haremos a continuación.

Hacemos clic en Crear nueva

Le ponemos un nombre único, elegimos el tipo de cuenta, el rendimiento que puede ser estándar o premium y por último si queremos replicar localmente o en otra región.

Una vez creada la cuenta, podemos seleccionarla para que sea usada para albergar los discos de las máquinas replicadas.

Lo mismo debemos hacer ahora para la red virtual a la cual se conectarán las máquinas durante la conmutación por error, si no tienes una red previamente creada desde aquí mismo es posible crearla, como se puede ver en la siguiente imagen.

Donde hemos creado una red 10.5.0.0./16 de nombre ASR-VNet y hemos definido una subred llamada default la cual tiene el segmento 10.5.47.0./24

Una vez tengamos listo el almacenamiento y la red virtual, hacemos clic en Aceptar

Con esto hemos finalizado con el paso 4. Con esto nos vamos directamente al último paso de preparación que es configurar una directiva de replicación.

CONFIGURACIÓN DE REPLICACIÓN

En este último paso es donde definimos con qué frecuencia se replicarán los cambios en nuestras máquinas locales, el tiempo que se retendrán los puntos de recuperación y cuándo iniciaremos la réplica inicial, veamos cómo crear y asociar la directiva de replicación:

1. Nombre: Ponemos un nombre a la directiva de replicación, en este caso: ASRPolicy
2. Frecuencia de copia: Es la frecuencia con la cual se replicarán los cambios después de la replicación inicial, por defecto es cada 5 minutos
3. Retención de puntos de recuperación en horas: El tiempo que se conservarán los puntos de restauración, por defecto 2 horas
4. Frecuencia de instantáneas coherente con la replicación en horas: El tiempo en horas que se guardarán las instantáneas coherentes con la aplicación.
5. Hora de inicio de la replicación inicial: No hace falta explicar, lo deje Inmediatamente

Al terminar hacemos clic en Aceptar.

Una vez creada se asocia a nuestro sitio On-premises, hacemos clic en Aceptar para terminar con la creación y respectiva asociación.

Con esto hemos finalizado la preparación de la infraestructura, podemos ver los cinco pasos marcados como completos.

Ahora podemos ver el estado del host de Hyper-V, para ellos vamos al almacén de Recovery Services y seleccionamos  Infraestrutura de Site Recovery

Y luego Hosts de Hyper-V bajo el apartado Para sitios de Hyper-V

Y veremos que el host se encuentra conectado y respondiendo.

Con esto finalizamos esta primer parte, en las siguientes entregas veremos cómo replicar las máquinas y cómo hacer pruebas de conmutación por error.

Continúa en: Proteger máquinas administradas con Hyper-V - Replicación inicial