‘Disaster Recovery Scenary’ con Microsoft Azure (II)

Como ya os contamos en el anterior artículo, ahora vamos a explicaros de manera simplificada cómo montar y activar un centro de respaldo en el datacenter de Ámsterdam partiendo de una infraestructura implementada en el datacenter de Microsoft en Dublín.

El primer paso es crear mi “datacenter”. Para ello, en la suscripción de Azure crearé un primer Resource Group (RG) que llamaré DRTEST:

Este GR, como puede verse, está implementado en North Europe (Dublín). En el desplegaré una infraestructura compuesta por los siguientes elementos:

Una red virtual DRTEST-Vnet con cuatro subredes:
- Front-End
- Back-End
- ADSubnet
- GatewaySubnet con su correspondiente Virtual Gateway
Cuatro servidores Windows básicos:
- Un controlador de Dominio ubicado en la subnet “ADSubnet”: DRTESTAD01li
- Dos servidores IIS ubicados en la subnet ”Front-End”, que tienen fija su IP interna: DRTESTIIS01 y DRTESTIIS02
- Un Load Balancer DRTEST-LB asociado a dichos servidores (o viceversa).
- Un servidor de Base de Datos ubicado en la subnet “Back-End”: DRTESTDB01

Una vez que la infraestructura está preparada (el proceso no lo describo, entendiendo que quien esté interesado en este artículo, sabe de qué estamos hablando¹ ), el resultado final es que tengo mis máquinas:

Que corresponde a este diagrama de red:

Implementado el entorno que llamaremos “de producción”, como es lógico el siguiente paso es protegerlo. O más correctamente, porque en realidad es de lo que se trata, el siguiente paso es proteger nuestro negocio frente a una situación catastrófica que pudiera producirse en la ubicación de nuestras infraestructuras.

Los siguientes pasos no conforman un procedimiento, y en muchas ocasiones no voy a describirlos completamente puesto que Microsoft proporciona una información más exhaustiva y correcta de lo que yo puedo hacerlo, y que como mucho sería una copia de aquella.

Lo que si haré, si procede, es incluir los links que lleven al procedimiento descrito por la compañía de Redmond. Como decía, el siguiente paso en proceso de crear nuestra solución de DR es decidir la ubicación de nuestra infraestructura de respaldo.

Desde mi punto de vista, para abaratar costes en las comunicaciones y evitar tener que pensar en problemas legales en cuanto a temas de protección de datos, lo óptimo es hacerlo en la misma zona (Europa). Hasta hace bien poco solo se contaba con datacenter en Dublín y Ámsterdam, pero actualmente las opciones se han ampliado.

No obstante, yo voy a utilizar estas ubicaciones, y dado que mi “datacenter” lo he instalado en North Europe (Dublín), el de respaldo lo desplegaré en West Europe (Ámsterdam).

El primer paso es, por tanto, crear un Resource Group (RG) que llamare DRTEST-asr:

Con esto ya he asegurado que cualquier recurso que coloque en él, estará por defecto en un datacenter diferente.

A continuación creare un Recovery Services vault²,que alojaré en el nuevo RG. Esto no es estrictamente necesario, pero dado que lo que estoy haciendo es tratar de proteger mi negocio de una caída catastrófica de las infraestructuras de Dublín, tiene un cierto sentido colocarlo en Ámsterdam, aunque solo sea por coherencia.

A partir de este elemento podré crear una réplica de la infraestructura sita en North Europe, en la nueva ubicación.

Esto me proporcionará, en la nueva ubicación una réplica exacta de la red virtual, que no incorporará, como es lógico, el Gateway que yo tengo y que necesitaré crear de nuevo. Una cuenta de almacenamiento nueva réplica de la que tengo en mi ubicación actual (a la que Azure nombra de la misma manera agregando “asr” al final), y algunos elementos más que puedo o no tener (como grupos de afinidad).

Asimismo Azure genera una política de replicación que es configurable pero que por defecto ofrece los siguientes valores:

Name: 24-hour-retention-policy
Recovery point retention: 24 hour(s)
App consistent snapshot frequency: 4 hour(s)

Es interesante detenerse en el hecho de que el último punto básicamente es el que fija el valor de Recovery Point Objective (RTO), al establecer el plazo máximo de datos que podríamos perder. El motivo de esto es que una vez hecha la primera replicación, Azure realizará un snapshot de los elementos de nuestra infraestructura cada vez que se cumple el periodo fijado en este valor. Eso significa que si tenemos que volver atrás en un momento dado, o bien levantamos la infraestructura de respuesta a un desastre, nuestra perdida de información será como mucho de 4 horas (en el ejemplo).

Si se piensa fríamente, esto es una baza estupenda ante un ataque exitoso de un ransomware.

Estos valores pueden modificarse en los siguientes rangos:

Recovery point retention: entre 0 y 72 horas
App consistent snapshot frequency: entre 1 y 12 horas

En el ejemplo se puede ver que he cambiado la política para que este valor sea de 12 horas.

Llegados a este punto, Azure en primer lugar crea una réplica de la red virtual y de las cuentas de almacenamiento, y a lo largo de las siguientes horas comienza a crear toda la replicación de la infraestructura en el entorno de Disaster Recovery.

A continuación se lanzaran todos los procesos de replicación de nuestro “datacenter”, que llevarán un tiempo de proceso importante:

Finalmente, al cabo de unas horas, en que se ha realizado la replicación, tenemos el entorno salvaguardado y preparado para responder ante una eventualidad. Un detalle interesante es el que en la imagen siguiente podemos ver el valor de nuestro RPO. En un siguiente capítulo buscaremos la forma testear y de sacarle partido a esta funcionalidad.

Una de las ventajas de esta solución es que a clientes de pequeñas dimensiones se les puede proporcionar una herramienta a la que de otra manera no podrían acceder y con una seguridad que jamás abrían soñado, ya que tener su infraestructura totalmente replicada, en tanto no la levanten, solo les cuesta el precio del almacenamiento utilizado, que no es muy significativo.

En conclusión: Azure cada vez tiene y ofrece más herramientas. No son perfectas, definitivas, ni únicas, pero nos permiten empezar a trabajar en la protección total de las infraestructuras que protegen nuestro negocio a un coste bastante más bajo que el necesario al implicar una solución tradicional.

Referencias |

¹Para el que quiera crearse algo parecido:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/tutorial-manage-vm

²Para crear un Recovery Services Vault y seguir paso a paso el proceso de replicación, consultar:

https://docs.microsoft.com/en-us/azure/site-recovery/azure-to-azure-tutorial-enable-replication

Borja Cabellos