Disaster Recovery Scenary with Microsoft Azure: rompiendo cosas

Pongámonos en situación: el punto de partida es una infraestructura virtual implementada en mi subscripción de Azure, instalada sobre dos grupos de recursos creados al efecto. Estos dos grupos de recursos están ubicados en lugares diferentes de la Zona Europea.

El primero DRTEST, ubicado en North Europe (Dublín) es nuestro entorno de producción en el que tendremos las Máquinas Virtuales, la red Virtual, Availability Sets, etc¹ .

El segundo DRTEST-asr, ubicado en West Europe (Ámsterdam) es nuestro entorno de Disaster Recovery, y en el encontramos réplicas de algunos elementos del primero.

Se puede ver que el sistema al crearlos ha añadido el sufijo “-asr” a sus nombres originales, pero también se puede observar si nos metemos a indagar en unos y otros de cuales son réplica. Un ejemplo es que si comparamos la red Virtual del entorno de producción con la del entorno de DR, veremos que tienen las mismas subredes con idéntico direccionamiento IP.

Solo cambia el numero de direcciones disponibles, por que en la red de producción ya las tengo en uso. Si revisamos el Recovery Service Vault que cree en su momento, se veremos que cuenta con 4 elementos replicados, que corresponden a las cuatro máquinas virtuales que forman mi infraestructura: El controlador de Dominio, el servidor de Base de Datos y los dos IIS frontales.

Probando nuevas herramientas

El siguiente paso es empezar a romper, pero como estamos en la nube lo podemos hacer virtualmente. Para ello trabajaremos sobre el grupo de recursos DRTEST-asr.

El primer paso sería probar individualmente cada máquina y ver que la replicación funciona correctamente. Para ello, antes de nada, en mi grupo de recursos DRTEST-asr voy a crear una nueva red virtual, que llamare TESTdelTEST. La razón es que es una recomendación de Microsoft:

Más claro, el agua, y como cada vez que he tratado de saltarme este tipo de recomendaciones me ha pasado “algo”, pues toca seguirlas. Una vez creada dicha red virtual para pruebas de failover, procedo con ello². En mi DRTESTRecoveryTestVault, puedo ver, en la zona etiquetada “Site Recovery”, los “Replicated Items”, y al hacer click sobre este area accedo a la lista de las cuatro máquinas virtuales de las que estoy hablando continuamente, que forman mi infraestructura critica.

Es posible, en el listado, ver que en cada máquina,hay un icono de atención con el que se avisa que nunca se ha probado esta funcionalidad con ninguna de ellas. Ademas lo pone en un clarísimo inglés: “Never done”:

Seleccionando una de las máquinas, en concreto el servidor de BBDD DRTESTDB01, ya que esta prueba es individual para cada máquina (y deberían hacerse todas), se nos despliega un menú en el que se nos permitirá bien lanzar un proceso de “Failover” o bien un proceso de “Test Failover”, siendo este segundo el que me interesa realmente.

Al pulsar con el ratón sobre la opción de “Test Failover” se nos presentan algunas informaciones y elecciones. Por un lado es posible ver que la replicación tendrá lugar desde North Europa a West Europa.

En segundo lugar se presenta la elección del punto al que queremos retornar. En mi caso hay tres, pero supongo que es posible encontrar tantos como puntos de replicación tengamos almacenados (por cierto que este es un tema sobre el que será necesario volver más adelante).

Finalmente me aparece la opción de escoger la red virtual sobre la que quiero hacer la prueba, y es el punto clave, porque consultando la documentación de Microsoft al respecto, el aviso que mostraba antes, “The virtual machine will be connected to this network after failover. The network will only be used for this test failover”, no aparece por ningún lugar, y por tanto la posibilidad de cometer un error, si no se lee el aviso desplegable es enorme.

Una vez realizadas mis elecciones, lanzo el test y no hago nada hasta que este termine. Sabremos que el proceso está terminado porque al hacerlo se activará una opción que antes no lo estaba “Cleanup test failover”, que es la que permite la vuelta atrás.

Revisando mi entorno puedo ver que ha aparecido una nueva máquina virtual llamada DRTESTDB01-test, que se encuentra en el grupo de recursos DRTEST-asr, que está asociada a la red virtual TESTdelTEST y que tiene el mismo tamaño que la original.

Por tanto el proceso de prueba ha funcionado correctamente, se ha creado una maquina igual que la mía y se ha levantado. Ya puedo pulsar sobre “Cleanup test failover” indicando que el sistema vuelva al estado original y haga desaparecer esa máquina de prueba.

Una vez probado que la teoría funciona es el momento de proteger todo nuestro entorno. Para ello, en mi DRTESTRecoveryTestVault, puedo ver, en la zona etiquetada “Recovery plans” que no tengo ningún plan de recuperación. Y esto hay que cambiarlo.

Al hacer click sobre este area accedo a un entorno, vacío, en el que se me va a permitir definir mi plan de recuperación que afectará a todas las máquinas que conforman mi infraestructura crítica.

Hay una nota muy clara y explicativa en este punto: “To failover virtual machines individually , go to Replicated Items. To failover multiples virtual machines together, create un Recovery plan”.

Para crear un recovery plan empezaremos por poner un nombre a este: RDTESTRecoveryPlan. A continuación definiremos la zona de origen de mi infresatructura, la zona de destino y los elementos que queremos proteger, que en mi caso son todos.

Finalmente lanzamos la creación de dicho plan.

Logicamente, el siguiente paso es probar el plan completo, lo cual podemos hacer, tal y como hicimos con una maquina individual, si hacemos click sobre […] y seleccionamos la opción “Test Failover”.

En este punto cruzamos los dedos.

Una vez que ha sido exitosa la prueba, como indica el resultado del test podemos deshacer todo lo agregado seleccionande en […] la opcion “Cleanup Test Failover”.