En un entorno onpremise cuando planteamos soluciones ante desastres geográficos normalmente la opción más habitual es el log shipping. La utilización de database mirroring asíncrono o grupos de disponibilidad con réplicas asíncronas es también habitual, pero incluye un riesgo adicional que no suele contemplarse. Nos referimos a la “velocidad” con la que los cambios se transfieren, básicamente tan rápidamente como la red y el sistema destino nos permita. Esto hace que cuando el desastre tiene origen humano, un error importante, cuando nos percatemos de éste ya tendremos dicho error replicado y aplicado. Obviamente una mejor solución sería combinar ambas opciones, que no son excluyentes, con lo que cubriríamos más escenarios de desastre aumentando el coste de la solución.

Otra alternativa habitual en entornos onpremise virtualizados (o físicos también) es utilizar alguna herramienta/solución que nos permita tener snapshots de nuestras máquinas replicados geográficamente. En el caso de un entorno cloud en Azure podemos implementar esta funcionalidad fácilmente mediante Azure Site Recovery (ASR). En este post vamos a mostrar el funcionamiento de esta tecnología como alternativa al uso de log shipping pensando en aquellos casos donde no queremos tener que mantener manualmente los N logshippings que podemos necesitar para una instancia SQL Server o donde queramos contener aún más el coste de la solución.

Para este ejemplo vamos a crear un par de grupos de recursos, uno en el norte de europa y otro en el oeste de europa:


En el grupo del norte de europa tenemos desplegada una máquina virtual con SQL Server 2016 con todos los recursos asociados de disco, red, etc.

En el oeste de europa crearemos un Recovery Services vault donde se almacenarán los backups y configuraciones de disaster recovery que realicemos:

Para proteger nuestra máquina el proceso es muy sencillo, tan solo tenemos que irnos a las propiedades de la máquina y seleccionar dentro de la categoría de operaciones la opción “Disaster recovery”:

En la siguiente pantalla de configuración en nuestro caso únicamente modificaremos el resource group destino, que utilizaremos el que hemos creado previamente para el vault:

Si nos fijamos podemos ver que podemos configurar algunas opciones en esta pantalla que pueden ser de utilidad. Por ejemplo, podemos cambiar el tipo de almacenamiento, y utilizar discos no Premium en el entorno de DR:

También podemos configurar la política de replicación. Por defecto tenemos únicamente una política creada, con 24h de retención, pero podemos crear una personalizada que se ajuste mejor a nuestras necesidades.

Cuando lancemos el proceso de replicación podremos ver en un mapa de forma gráfica el proceso:

Tengamos en cuenta que este proceso puede llevar un tiempo en función del tamaño de la máquina y la configuración pendiente de realizar. En nuestro caso la configuración tardó unos 10 minutos:

Una vez realizada la configuración podemos ver en la máquina el progreso de la replicación a nivel global:

Además, también tendremos información a nivel de disco individual, donde destacaríamos el dato de cuantos cambios pendientes existen en origen que aún no han sido replicados:


Finalmente, cuando la replicación termine el estado cambiará “Protected” y se nos indicará el RPO, el cual irá cambiando en función del tiempo transcurrido desde el último snapshot:


Desde el punto de vista de SQL Server, por defecto, se procesarán los backups vía VDI:

Esto tiene las mismas implicaciones que cuando se utiliza cualquier sistema basado en esta tecnología. El principal inconveniente es que el backup que se realiza nos invalidará la cadena diferencial desde el último backup realizado por nosotros, por lo que si intentamos lanzar un backup diferencial nos encontraremos con un error como si no existiera un backup completo válido.

Si deseamos evitar este problema debemos hacer un cambio en el registro de Windows de forma que se utilice VSS por parte del Agente de backup de Azure (https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-troubleshoot#troubleshoot-vm-snapshot-issues y https://docs.microsoft.com/en-us/azure/backup/backup-azure-vms-introduction#windows-vm ):

Desde el punto de vista de la consistencia tenemos realmente dos puntos a tener en cuenta. Uno es el “crash-consistent” y el otro es “app-consistent”:

El App-Consistent es el que utilizaría VSS antes tal y como hemos comentado, teniendo una foto consistente del operativo y todos los servicios compatibles con VSS instalados en el servidor. Sin embargo, el crash-consistent básicamente lo que obtiene es el mismo resultado que tendríamos si se aplicara un “hard reset” a un servidor. Los snapshots App-Consistent pueden programarse con una frecuencia mínima de 1 hora. Debemos tener en cuenta que si restauramos un crash-consistent recovery point podemos tener algunos problemas en aplicaciones que no estén preparadas para ello. En el caso de SQL Server no debería ser un problema debido a que el propio proceso de recovery de bases de datos de SQL Server podrá gestionar esta situación sin problemas.

También debemos pensar en que ASR es mucho más que un “silo” para backups y ofrece también soluciones de DR para entornos virtuales VMWare, Hyper-V, etc. por lo que puede ser un buen aliado en general para nuestra estrategia de DR a nivel corporativo:

Una vez que la replicación ha finalizado llega el momento de la verdad, el testear que realmente podemos levantar la máquina virtual en west europe en caso de caída. Para ello vamos a conectar a la máquina original y vamos a crear un proceso que realice inserciones en una tabla cada minuto. De esta forma podremos verificar cómo de “fresco” está el dato una vez restauremos el entorno de DR. El siguiente script crea una base de datos con una tabla e inserta un registro cada minuto:

create database testASR
go
use testASR
go
CREATE table test (fecha datetime)
go
while (1=1)
begin
insert into test values (getdate())
waitfor delay '00:01:00'
end
go

Obtendremos los últimos registros insertados para tenerlos como referencia:


El siguiente paso será realizar un testeo del failover que básicamente realizará las mismas acciones que el failover, levantará las nuevas máquinas, etc. pero sin afectar a la actual replicación que seguirá en marcha de forma independiente. Podremos seleccionar el punto de recuperación que deseemos siendo el último de ellos el que menor RPO implicará:


Los pasos que se seguirán serán dependientes del entorno protegido, pero en este caso consisten básicamente en crear una nueva máquina virtual clon de la anterior y encenderla. En esta prueba el tiempo total necesario ha sido menos de 4 minutos:


Conectaremos a la máquina creada por el failover test:

Y lanzaremos la consulta para comprobar los últimos registros insertados:

Podemos ver que en este caso hemos perdido únicamente una inserción, por lo que el RPO real habrá sido mayor de 60 segundos, pero menor de 120 segundos. Una vez hemos testeado que podemos levantar y acceder a la máquina de DR completaremos el proceso realizando la limpieza del test:

El proceso de limpieza también es bastante rápido en este caso, menos de 5 minutos:

En resumen, hemos comprobado cómo podemos proteger una máquina virtual SQL Server en Azure ante un desastre replicando desde la región del norte de europa hasta europa oeste. El proceso de test del entorno de DR es muy sencillo y rápido gracias a la automatización que Azure nos proporciona para ello. La protección de una única máquina tan solo es un pequeño paso dentro de una estrategia de DR a nivel corporativo, que debe tener en cuenta muchos más factores, así como las dependencias entre los distintos recursos, servicios, etc.

Rubén Garrigós

Rubén Garrigós is an expert in high-availability enterprise solutions based on SQL Server design, tuning, and troubleshooting. Over the past fifteen years, he has worked with Microsoft data access technologies in leading companies around the world. He currently is a Microsoft SQL Server and .NET applications architect with SolidQ. Ruben is certified by Microsoft as a Solution Expert on the Microsoft Data Platform (MSCE: Data Platform) and as a Solution Expert on the Microsoft Private Cloud (MSCE: Private Cloud). As a Microsoft Certified Trainer (MCT), Ruben has taught multiple official Microsoft courses as well as other courses specializing in SQL Server. He has also presented sessions at official events for various Microsoft technologies user groups.