En la actualidad, un reto para cualquier compañía es protegerse ante una contingencia en sus sistemas de información. Con Site Recovery, herramienta que nos ofrece la Cloud de Azure, podemos tener un plan de recuperación ante desastres de una forma sencilla y fiable.

Con el siguiente artículo, vamos a mostrar paso a paso como activar esta protección para nuestros sistemas. En concreto para máquinas virtuales que corran en Azure y no dispongan o puedan disponer de un sistema de HA mediante balanceo de carga.

How to

Realizaremos este laboratorio para un servidor Apache, que corre en una VM Linux, independiente en Azure.

Indicar que este mismo servicio de Azure lo podemos aplicar para servidores OnPremise, físicos o virtualizados. En este caso debemos desplegar elementos sobre la infraestructura local, para poder procesar los datos antes de enviarlos a Azure.

Recovery Service Vault (RSV) 

Hacemos login en el portal de Azure y creamos un “Recovery Service Vault”: 

Ponemos un nombre al recurso y seleccionamos un grupo de recursos, o creamos uno nuevo si fuera necesario. Pulsamos sobre el botón de “create”: 

Nota: Sería recomendable ubicar el RSV en una región de Azure diferente al de la VM de origen, para poder protegernos ante la contingencia regional del algún servicio del fabricante. 

Replication 

Habilitamos la replicación para la VM. En nuestro caso, para la máquina virtual que tiene el servidor apache: 

Vamos a establecer la réplica en la región de “North Europe”, seleccionamos el grupo de recursos y la red de destino y pulsamos sobre “Enable Replication”: 

Nota: Si deseamos asignar una configuración específica para el grupo de recursos y la red, debemos crearlas previamente a este paso. 

El propio trabajo crea todos los recursos del destino (política, grupo de recursos, red, discos…) y hace un mapeo de las 2 redes, para poder habilitar el failover: 

Una vez que se hayan completado las tareas correctamente, recibiremos el ok del portal: 

Ahora, debemos esperar a que se complete la primera replicación. Esta será, lógicamente, la más de más duración, ya que debe transferir todos los datos:

Una vez terminado este primer trabajo tendremos la VM protegida y podremos realizar la conmutación:

Configure target Resources 

Una vez finalizada la primera replicación, podemos editar ciertos parámetros de la VM de destino, como por ejemplo el tamaño de la VM de destino y la dirección IP: 

Failover 

Se está prestando el servicio desde la VM original en el Oeste de Europa:

Simulamos una contingencia apagando la VM de origen:

Procedemos a activar la conmutación para que entre en producción el servidor de réplica. Para ello accedemos al RSV y seleccionamos el elemento replicado correspondiente:

Como podemos observar, el elemento se encuentra en Warning ya que detecta que la VM de origen no está funcionando. Seleccionamos la opción de Failover: 

NOTA: Si no hemos ejecutado ningún test de fallo, nos aparecerá una advertencia como que nunca la hemos ejecutado. Debemos marcar el check de que hemos entendido la advertencia y continuar:

Escogemos el punto de recuperación, dentro de los disponibles, con el que queremos que la máquina de destino arranque. Aquí tenemos varias opciones: 

  • Latest (Low RPO): se inicia el trabajo procesando primero todos los datos que se han enviado al servicio de Site Recovery. El procesamiento de los datos crea un punto de recuperación para la máquina virtual. Esta opción ofrece el objetivo de punto de recuperación (RPO) mínimo, ya que la máquina virtual creada después de la conmutación por error tiene todos los datos que se han replicado en el servicio Site Recovery cuando se desencadenó la conmutación por error. 
  • Latest processed (Low RTO): esta opción conmuta por error la máquina virtual al punto de recuperación más reciente que el servicio Site Recovery haya procesado. Como no se emplea ningún tiempo en procesar los datos sin procesar, esta es una opción de conmutación por error tiene un objetivo de tiempo de recuperación más bajo.  
  • Latest app-consistent (Más reciente coherente con la aplicación): esta opción conmuta por error la máquina virtual del plan de recuperación al último punto de recuperación coherente con la aplicación que haya procesado el servicio Site Recovery 

En nuestro caso escogemos la opción de Last RTO, ya que sabemos que no ha sufrido cambios la VM y así acortamos el tiempo de puesta en marcha:

Una vez la conmutación ha finalizado: 

Accedemos a la VM en el destino, para asignarle una IP pública y poder recuperar el servicio:

Asignamos un nombre DNS:

Y cambiamos el DNS público para que apunte al nuevo servidor de Apache, bajando lo máximo posible el TTL para que el cambio se replique rápidamente. 

Ya estamos dando servicio de nuevo:

En este punto de la conmutación tenemos varias opciones: 

  • Cambiar el punto de recuperación 
  • Confirmar el punto de recuperación
  •  Re-proteger 

 

Change Recovery Point 

Podemos modificar el punto de recuperación por si, por ejemplo, necesitamos cubrir un borrado accidental en el origen o un ataque de ramsonware, y necesitamos ir más atrás en el tiempo:

Perderemos momentáneamente el servicio de nuevo, ya que se tienen que aplicar los cambios para ir al punto elegido en esta ocasión. 

Commit 

Una vez hayamos comprobado que la VM recuperada es la correcta, confirmaremos la conmutación con el botón de commit. 

Ahora debemos ir al siguiente punto “Re-protect” para volver a proteger nuestro entorno. 

Re-protect 

Esta opción la podemos seleccionar antes o después de hacer el commit. De esta manera invertiremos el sentido de la replicación, para volver a crear un entorno de protección antes desastres.  

Por defecto, los datos se enviarán al grupo de recursos y red del que provienen los datos originalmente:

NOTA: Es posible que sea necesario un reinicio de la VM tras reactivar la protección, ya que deben realizarse algunos cambios en el agente de movilidad.

About Rubén Muñoz

Rubén Muñoz. Continuity Services Expert. Rubén is Senior Technician in Telecommunications and computer systems, and he has these certifications: AWS Certified Solutions Architect, Veeam Certified Engineer, Certified SonicWALL Security Administrator, and 535 Exam: Architecting Microsoft Azure Solutions. He has worked as Systems Technician during fice years, at Bilbomática and Grupo Gesfor. He worked at ESABE Informática Distribuida for 9 years, as Systems Administrator and Angineering and Systems Manager. In 2016 he joined Enimbos as Continuity Services Expert, with functions like pre-sales support and Delivery Manager.