Implementación de un Sistema de Alta Disponibilidad en SQL Server 2012 con AlwaysOn

  • Artículo

Autor***:* Enrique Catala Bañuls es mentor en el área relacional de la empresa SolidQ. Es MCT, MCITP, MCTS, MAP desde 2010 (Microsoft Active Professional) y Microsof Technical Ranger. Centrado profesionalmente en bases de datos SQL Server, durante los últimos 8 años tiene su foco principal de operación en solución de problemas de rendimiento, escalabilidad, migraciones y alta disponibilidad. Además de impartir cursos oficiales de Microsoft, ha participado como speaker en eventos de lanzamiento de Microsoft España (Microsoft SQL Server 2008), ponente habitual en SQL PASS Latam, y SQL PASS Spain, así como SQLServerSaturday. Es ponente habitual de sesiones dentro del SolidQ Summit Madrid.

Contenidos

  • Introducción
  • Análisis de Necesidades de Disponibilidad
  • Diseño de la solución
  • Implementación de la solución
    • Configuración de WSFC
    • Activar Availability Groups a nivel de instancia
    • Configuración de AlwaysOn
  • Como actuar en caso de catástrofe
    • ¿Qué es un FAILOVER?
    • Como realizar conmutación por error manual (controlado).
    • Como realizar una conmutación por forzado de servicio (emergencia)
    • Como eliminar un AlwaysOn
  • APENDICE
    • Conectividad entre sites
    • Monitor de grupos de disponibilidad AlwaysOn
    • Política de copias de seguridad

Introducción

El objetivo de este documento es el de ayudar a implementar un sistema de Alta Disponibilidad en SQL Server 2012 para asegurar la continuidad de las aplicaciones en caso de caída del servidor principal mediante la tecnología AlwaysOn.
Este documento está centrado en documentar la implementación de AlwaysOn en una arquitectura idónea para esta tecnología. Se asume por parte del lector que cada tecnología de alta disponibilidad tiene su ámbito de aplicación y que por tanto no debe tomarse este documento para forzar una implementación mediante AlwaysOn en cualquier escenario. Además, este documento debe tomarse como una guía rápida de implementación, teniéndose en cuenta que la documentación más detallada puede encontrarse siempre en los libros en pantalla de SQL Server 2012.
Para la elaboración de esta arquitectura de ejemplo contamos con los siguientes elementos:

Windows Server 2012 como host para montar infraestructura virtualizada de pruebas

Hyper-V como sistema de virtualización

SQL Server 2012 x64 Enterprise Edition SP1 como versión de motor relacional.

Windows Server 2008 R2 como OS de la plataforma a simular.

  • Se ha escogido especialmente puesto que se pretende explícitamente demostrar que es tan idóneo para trabajar como lo pueda ser en Windows Server 2012

Máquinas virtuales para simular un entorno formado por 2 CPD geográficamente dispersos

Virtual Windows Server 2008 R2 como domain controller

  • A su vez actúa como servidor de enrutamiento entre las subredes de ambos CPD (no es una buena práctica pero se entiende que es con fines didácticos)

2 CPD geográficamente disperses simulados

Utilizan almacenamiento no replicado

Utilizan subredes diferentes

W2k8r2_Nodo1

  • Simula nodo1 del Cluster AlwaysOn dentro del CPD1
  • Windows Server 2008 R2
  • Alberga la instancia W2K8R2N1\SQL2012_HADR1

W2k8r2_Nodo2

  • Simula nodo 2 del Cluster AlwaysOn dentro del CPD1
  • Windows Server 2008 R2
  • Alberga la instancia W2K8R2N2\SQL2012_HADR2
  •  

W2k8r2_Nodo1Multisite

  • Simula nodo 1 del Cluster AlwaysOn dentro del CPD2
  • Windows Server 2008 R2
  • Alberga la instancia W2K8R2MS1\SQL2012

Análisis de Necesidades de Disponibilidad

En el supuesto de escenario del que partimos para este documento, se han acotado las siguientes necesidades:

  1. Requerida la mayor transparencia y facilidad de mantenimiento posible
  2. 0 pérdida de datos
  3. Posibilidad de reutilizar las réplicas para aprovechar al máximo la plataforma y ROI
  4. El modelo de alta disponibilidad debe funcionar entre entornos geográficamente dispersos
  5. El modelo de alta disponibilidad debe soportar mínima parada
  6. El modelo de alta disponibilidad debe permitir caídas del servidor secundario o de la red, sin verse afectado

La solución final propuesta en la mayoría de escenarios del mundo real consta de la mezcla de dos tecnologías, que aportan entre sí, la solución final de alta disponibilidad requerida:

  • Clustering

La solución principal de alta disponibilidad viene dada por WSFC (Windows Server Failover Clustering) por las siguientes razones:

  • Redundancia total de la instancia, no solo a nivel de base de datos
  • Failover automático con 0 pérdida de datos
  • Imposibilidad de errores-despistes relativos a todo lo relacionado con software externo o configuraciones a nivel de instancia u otros servicios de la máquina

AlwaysOn

AlwaysOn aporta numerosas mejoras a la solución basada en Failover Clustering:

Proporciona redundancia de base de datos

  • Failover Clustering no posee redundancia de BBDD

Permite reutilizar las réplicas secundarias para solo lectura:

  • Para lanzar informes
  • Para realizar cargas hacia cubos sin impacto en producción
  • Para realizar backups
  • Para realizar chequeos de consistencia
  • …

Proporciona abstracción para la aplicación cliente mediante ODBC utilizando el driver de conexión nativo a SQL Server

  • La aplicación automáticamente redirige las conexiones de solo lectura a replicas secundarias si así se desea

Garantiza sincronización completa entre todas las réplicas (si se configuran como síncronas y hasta un máximo de 3)

Permite balanceo controlado entre el principal y secundario

Tiempo de parada sustancialmente inferior que Failover Clustering

Transparente para aplicaciones

NOTA: En este documento vamos a omitir instancias SQL Server en WSFC simplemente por centrarnos en la tecnología de grupos de disponibilidad AlwaysOn, pero recordamos que son perfectamente complementarios.

Diseño de la solución

Para la solución final propuesta en este documento se dispone de 3 nodos, estando 2 de los cuales en el CPD1 y el otro en el CPD2. Entre ambos CPD existe una configuración de red independiente lo que lo convierte en un entorno multi-site y sobre el que vamos a montar una infraestructura de alta disponibilidad AlwaysOn.

En esta arquitectura por lo tanto existirá un Windows Server Failover Cluster (WSFC a partir de ahora) que albergará el multi-site formado por CPD1 y CPD2, de forma que el site de CPD1 contendrá dos instancias de SQL Server 2012 llamadas W2K8R2N1\SQL2012_HADR1 y W2K8R2N2\SQL2012_HADR2 mientras que el site de CPD2 poseerá una instancia de SQL Server 2012 llamada W2K8R2MS1\SQL2012

A su vez, queremos que las instancias W2K8R2N1\SQL2012_HADR1 y W2K8R2N2\SQL2012_HADR2 se encuentren funcionando de forma síncrona, mientras que la instancia W2K8R2MS1\SQL2012 funcione de manera asíncrona.

La razón de ello es que como ya hemos introducido al inicio del documento, la instancia W2K8R2MS1\SQL2012 se encuentra en un site diferente (CPD2), y en un escenario típico, el aumento de lag que añadiríamos a la solución podría dañar el feedback percibido por los usuarios de la aplicación.

A modo de breve introducción, tengamos en cuenta que las réplicas de base de datos se crean mediante la restauración (modo no-recovery) de una copia de seguridad de la base de datos principal. Una vez hecho esto se puede elegir el modo de disponibilidad pertinente permitiendo incluso que se posea acceso de solo lectura a las réplicas secundarias.

La parte de gestión de disponibilidad para la configuración AlwaysOn recae toda sobre la Failover clúster de Windows, ya que es una tecnología totalmente probada y robusta. Esta es la razón por la que montamos una infraestructura WSFC.

Cada nueva réplica es actualizada  de forma constante utilizando un canal TCP/IP que se abrirá entre todas las instancias SQL Server que forman parte de la configuración AlwaysOn. Dicho canal es el que configuraremos nosotros al crear el ENDPOINT.

Por lo tanto existen dos modos de funcionamiento, que pueden coexistir en una infraestructura AlwaysOn:

  • Modo Síncrono:

Se confirma transacción en Principal sólo cuando la transacción es registrada en todas las réplicas secundarias:

  • Requerido para balanceos con seguridad
  • 0 perdida de datos
  • Impone dependencia de comunicación mutua

Modo Asíncrono

Se confirma la transacción en Principal según es registrada

  • No espera confirmación en la réplica asíncrona
  • Permite independencia entre servidores

Podemos perder transacciones que estaban en el principal
Un diagrama del proceso de COMMIT de una transacción bajo las tres configuraciones posibles es el siguiente:

  • Síncrono

  • Asíncrono

NOTA: Como se puede apreciar, el proceso es idéntico a database mirroring, de hecho, es una evolución del mismo

Implementación de la solución

Partimos de la base de encontrar la mejor alta disponibilidad que en muchas ocasiones viene uniendo WSFC a AlwaysOn. En este escenario, solo recordar que AlwaysOn no necesita de instancias clusterizadas y así hemos plasmado a modo de ejemplo. En un entorno real se podría configurar exactamente igual mediante instancias clusterizadas.

Configuración de WSFC

AlwaysOn corre bajo el servicio de Failover Cluster de Windows, es por ello que lo que primero debemos configurar es dicho servicio. Para poder comenzar lo importante es conocer qué requisitos se nos van a pedir y para ello se recomienda leer y cumplir la lista de requisitos siguiente:  https://msdn.microsoft.com/es-es/library/ff878487.aspx 
Una vez superados todos los requisitos, lo primero es crear la configuración de WSFC sobre la que va a ir montada toda la solución. Se entiende que el lector conoce el funcionamiento de un WSFC y por tanto vamos a obviar la parte de creación paso a paso de dicho WSFC.

NOTA: Información sobre creación de WSFC https://technet.microsoft.com/library/cc754482.aspx

En el ejemplo de este artículo hemos configurado nuestro WSFC utilizando la siguiente información:

Información sobre nuestros 2 CPD y 3 equipos :

CPD1

Subred 10.1.1.X

Contiene los equipos

W2k8r2_Nodo1

  • Alberga la instancia W2K8R2N1\SQL2012_HADR1

W2k8r2_Nodo2

  • Alberga la instancia W2K8R2N2\SQL2012_HADR2

CPD2

Subred **10.2.**1.X

Contiene los equipos

W2k8r2_Nodo1Multisite

  • Alberga la instancia W2K8R2MS1\SQL2012

Configuración de enrutamiento para conectividad entre los sites CPD1 y CPD2

El nombre de nuestro WSFC será W2K8R2CLU.SOLID.LOCAL

Nuestro WSFC tras configurarlo tendrá entonces este aspecto:

  • Nuestros 3 nodos (recordamos que W2K8R2ms1 forma parte del CPD2):

Y vemos en propiedades de la red  ambos segmentos dedicados a los nodos del CPD1 y del CPD2
Para el CPD1:

Para el CPD2:

Activar Availability Groups a nivel de instancia

Para que una instancia pueda formar parte de AlwaysOn hay que activarle dicha característica a nivel de configuración de instancia. Para ello la máquina debe estar unida a un Failover Cluster (en nuestro caso está unida a W2K8R2CLU.solid.local) y tras ello, desde “SQL Server Configuration Manager” debemos activar la configuración de AlwaysOn Availability Groups:

Configuración de AlwaysOn

Una vez tenemos nuestras instancias con “AlwaysOn Availiability Groups” activo, el siguiente paso es crear un “ENDPOINT” entre las instancias de SQL Server 2012, que recordemos que son:

  • W2K8R2N1\SQL2012_HADR1
  • W2K8R2N2\SQL2012_HADR2
  • W2K8R2MS1\SQL2012

Para el puerto de nuestro Endpoint vamos a elegir como puerto de comunicaciones el 5022 (por ejemplo)

NOTA: Pese a la posibilidad de configuración mediante la GUI de SQL Server Management Studio, la configuración de nuestro AlwaysOn se va a mostrar mediante scripts T-SQL para facilitar la labor del administrador de base de datos, ya que de esta forma se puede repetir-controlar el proceso de una forma más eficaz.

El siguiente proceso detalla los pasos a seguir:

Paso 1: Validaciones iniciales

La primera tarea consiste en validar que las instancias de SQL Server 2012 cumple los siguientes requisitos:

Conocemos los siguientes datos (se nos pedirán a lo largo de la configuración):

Nombre para nuestro AlwaysOn:

  • En nuestro caso “AlwaysOn (SQL2012)”

Puerto destinado al ENDPOINT de comunicación de AlwaysOn

  • 5022

Nombre para el listener de AlwaysOn

  • En nuestro caso “HADR_2012w2k8r2”

Puerto para el listener AlwaysOn

  • En nuestro caso 5678

IP para el listener AlwaysOn

  • En nuestro caso 10.1.1.85 y 10.2.1.85
  • Al estar en dos segmentos de red distintos, necesitaremos responder por 2 IP diferentes (recordemos CPD1 y CPD2)

Las instancias son levantadas por una cuenta de dominio (no es requisito pero sí que facilita mucho las tareas de creación del Endpoint)

  • SQL Server browser se encuentra activo

Verificar que todos los nodos se encuentran por su nombre DSN en ambos sentidos

  • Usar ping para ello o abrir una consulta de SSMS entre ambos equipos, por ejemplo

Verificar que el puerto elegido (el 5022 en nuestro caso) se encuentra abierto entre los nodos de nuestro AlwaysOn

Verificar que el puerto elegido para el listener se encuentra abierto (el 5678 en nuestro ejemplo)

Verificar que tenemos la configuración de Availability Groups habilitada en todas las instancias de nuestro futuro AlwaysOn

Paso 2: Creación y activación del Endpoint de comunicación

Creación del Endpoint de comunicación entre los servidores que formarán parte de AlwaysOn. El siguiente código debe lanzarse en todos los nodos que formen parte de nuestro AlwaysOn:

Para validar que la configuración ha sido realizada correctamente, la mejor prueba es lanzar un telnet al puerto entre ambos servidores (desde el A hacia el B y viceversa)

Si conecta correctamente en todos los sentidos (entre las 3 instancias), podremos concluir que se ha realizado correctamente.

NOTA: Si por el contrario diera error, hay que validar que no existen bloqueos por parte de ningún firewall.

Finalmente, para concluir con la creación del Endpoint, hay que activarlo y darle permisos al usuario que levanta el servicio de SQL Server, únicamente permisos de conexión al endpoint. Para ello hay que lanzar el siguiente script:

NOTA: Para que funcione debemos asegurarnos que hemos activado SQLCMD en SQL Server Management Studio tal como vemos en la siguiente imagen

Paso 3: Preparación de réplicas para AlwaysOn

En este paso, vamos a preparar una nueva réplica (o la primera) en AlwaysOn. Para ello lo que vamos a hacer a grandes rasgos es realizar un backup completo y de la cola del log de transacciones de aquellas bases de datos que queramos configurar en espejo, y vamos a restaurarlas en modo “NO RECOVERY” en el/los servidores que actúen como réplica.
El primer paso por tanto es obtener copia de seguridad completa y tras ella, del log de transacciones. Para realizarlo rápidamente, utilizar el siguiente script contra el servidor principal:

NOTA: Es muy importante que se deshabilite cualquier job de backup durante todo el proceso ya que corremos el riesgo de no estar copiando los últimos ficheros conteniendo el backup y obviamente no funcionará

Una vez realizados los backups, hay que llevárselos al servidor secundario y restaurarlos. Para ello, lanzar el siguiente script contra el servidor secundario:

En este momento ya tenemos la instancia con el endpoint creado y activo y la BBDD que formará parte de nuestro grupo de disponibilidad preparada.

NOTA: Este proceso de restauración hay que repetirlo en todas las instancias que queramos que formen parte de nuestro grupo de disponibilidad. En nuestro ejemplo lo haremos también para una BBDD llamada “tpch”

Paso 4: Creación del grupo de disponibilidad

Una vez se han restaurado las BBDD en nuestro servidor de réplica debemos especificar qué BBDD y réplicas formaran parte de momento en nuestro grupo de disponibilidad de AlwaysOn.
Para ello nos conectamos al servidor que queremos que empiece siendo réplica principal y lanzamos la creación del Availability Group así como de su listener de comunicaciones:

Una vez hecho esto, deberemos ver cómo en nuestro panel de configuración de WSFC aparece nuestra aplicación “AlwaysOn (sql2012)” y su recurso de red de doble IP:

No vamos a entrar en detalles internos sobre su implementación, pero es interesante conocer que si balanceamos entre sites CPD1 al CPD2, lo que ocurrirá realmente es que la IP de cada site automáticamente será apagada-iniciada según convenga para nuestro escenario. Esto se realiza mediante la creación automática (nosotros no hacemos nada aquí) de un recurso de red de tipo “OR”, que será gestionado mediante el propio grupo de disponibilidad AlwaysOn desde SQL Server.

¿Qué hacemos si da error el paso anterior?

El error más común a la hora de lanzar este script es que hubiéramos realizado alguno de los pasos anteriores mal. Como resultado, el error que nos arrojará SQL Server más común es este:

Como vemos, nos está diciendo que la BBDD no está configurado para mirroring de base de datos.
Razones más comunes:

  • No existe conectividad entre los equipos en el puerto elegido a la hora de configurar el endpoint
  • El dominio de active directory no es capaz de validar el usuario al que le hemos dado permisos de conexión para el endpoint
  • Hemos configurado mal el nombre de los equipos o del puerto de comunicaciones
  • Nos hemos equivocado en el nombre de alguna de las BBDD al inicializarlas

Una vez detectado el problema, se debe volver a reintentar según el paso en el que nos encontremos.

Paso 5: Activación del grupo de disponibilidad

Por último para la activación del grupo de disponibilidad nos queda únicamente conectarnos a las réplicas que estemos configurando y unirlas a nuestro grupo de disponibilidad, así como activar el mismo, dando como resultado el funcionamiento en modo AlwaysOn del grupo de disponibilidad Adventureworks (en este caso). Para ello, nos conectamos a la instancia que va a actuar como réplica en la configuración AlwaysOn en cuestión y lanzamos el siguiente script:

Finalmente nuestra configuración de grupos de disponibilidad AlwaysOn está finalizada y así deberíamos verlo en nuestro SSMS bajo el nodo “Availability Groups”:

Podemos además, dar un vistazo con el monitor de grupos de disponibilidad para ver su estado.

Paso 6: Transferencia de logins

Llegados a este punto, las BBDD ya están configuradas en grupo de disponibilidad y su funcionamiento es el correcto de no haber ocurrido ningún error de configuración. En este punto lo único que falta es realizar una transferencia de logins del servidor principal al espejo.
Para transferir los logins, ejecutar el siguiente script en el servidor principal. Al ejecutarlo, en  estaña “Messages” de SQL Server Management Studio, aparecerán las sentencias CREATE LOGIN … necesarias a ejecutar en el servidor espejo.

NOTA: Obviamente los logins con ## y que ya existiesen en el servidor espejo no harían falta

Como actuar en caso de catástrofe

En este punto vamos a relatar las acciones más comunes en caso de catástrofe del entorno.

¿Qué es un FAILOVER?

Un FAILOVER es una conmutación de funciones. Es cuando un grupo de disponibilidad pasa de ser PRINCIPAL a SECUNDARIO o viceversa.
En AlwaysOn hay tres tipos de conmutación de funciones: conmutación por error automática, conmutación por error manual y servicio forzado (con posible pérdida de datos). La compatibilidad con cada forma depende del modo operativo de la sesión.

  • Conmutación por error manual

La conmutación por error manual es útil para realizar fines administrativos tales como instalación de Service Packs, actualizaciones de Windows,…que puedan implicar reinicio de servidor y que requieran un mínimo tiempo de parada.

  • Conmutación por error automática

Únicamente posible cuando las instancias no están instaladas en modo cluster. Básicamente quiere decir que el entorno automáticamente balanceará al mejor nodo cuando se detecten problemas en el servidor principal.

  • Forzar servicio (con posible pérdida de datos)

Se permite forzar el servicio para que actúe como instancia principal. Si se cae un CPD completo, por ejemplo el CPD1, se puede poner online como principal al servidor de otro CPD forzándole su puesta en marcha incluso si está funcionado en modo asíncrono. En el caso de que estemos en modo asíncrono, debemos asumir una cierta pérdida de datos que dependerá siempre de como de de-sincronizado estuviera el grupo de disponibilidad en dicho servidor. .

NOTA: Este modo es el último recurso y solo debe realizarse en caso de catástrofe del CPD principal

Recordemos además, que debido a que los grupos de disponibilidad de AlwaysOn solo realiza espejo de objetos y datos pertenecientes a las BBDD configuradas, tendremos que asegurarnos de crear los trabajos de copias de seguridad y alertas de servidor en todas las réplicas y que estos se activen en el momento de que la instancia espejo asuma el rol de principal. De no ser así, dichos procesos no se llevarán a cabo hasta que el servidor primario asuma de nuevo el rol de PRINCIPAL.

NOTA: Para más información https://msdn.microsoft.com/es-es/library/hh213151.aspx

Como realizar conmutación por error manual (controlado)

Para realizar esta acción, la instancia a la que pasar a modo principal debe estar sincronizada. De no estarlo, deberemos configurarla como modo síncrono y esperar a que lo esté

Pasar a modo síncrono

Esta acción no conlleva parada y es inmediata…pero hay que esperar a que finalice la sincronización para el siguiente paso:

  • Por interfaz

  • Por código

Balancear

  • Por interfaz

  • Por código

Hay que lanzar el siguiente código conectado a la instancia que queremos que asuma el rol principal

 

Como realizar una conmutación por forzado de servicio (emergencia)

ADVERTENCIA: OPERACIÓN PARA CASOS DE EMERGENCIA ÚNICAMENTE. NUNCA LANZAR SI EL PRINCIPAL TODAVIA FUNCIONA

Si el CPD que alberga al servidor que actúa como principal sufre algún problema grave y deja de responder, los pasos a seguir son:

Conectarse desde SQL Server Management Studio al servidor secundario que queremos activar como principal

  • En este caso sería a la instancia W2K8R2MS1\SQL2012 que está en el CPD2

Ejecutar el script que produce un Forzado de Servicio para que las BBDD asuman el rol principal

  • El driver de conexión automáticamente conectará contra el servidor que ahora ha asumido el rol de principal

Es tarea de la aplicación gestionar entonces el error de conectividad puntual

  • Solo si es necesario

Comprobar que los trabajos de copias de seguridad del nuevo servidor están activos, para que las políticas de copias de seguridad siguen efectuándose

El estado que veremos tras realizar una acción como la anterior sería esto (si miramos el dashboard)

Veremos por tanto el grupo de disponibilidad activo pero se nos indicará que las instancias anteriores están sin sincronización y activas (en nuestro caso imaginemos que hemos puesto de nuevo en marcha las máquinas del AlwaysOn y no está caído completamente el entorno).
Suponiendo una vez restaurado y arreglado el problema que existiera en CPD principal, éste no asume de nuevo el rol principal por lo que si queremos que suceda hay que realizar un FAILOVER manual siguiendo los pasos:

  • Realizar resume del grupo de disponibilidad base de datos a base de datos (hacer el forzado lo pausa)

En nuestro ejemplo de la imagen, deliberadamente tenemos más de 1 BBDD y al lanzar sobre dicha BBDD (alter database adventureworks set hadr resume) vemos como comienza a sincronizarse (en la imagen no hemos lanzado la misma operación sobre tpch). Además, debemos lanzarlo sobre todas las instancias secundarias.

  • Dado que en el CPD secundario teníamos configurado el modo asíncrono, debemos reconfigurarlo en modo síncrono

  • Failover controlado hacia el servidor principal que estaba caído y ya no

Como eliminar un AlwaysOn

En el caso de que por cualquier razón se desee destruir la configuración AlwaysOn, se puede hacer fácilmente siguiendo los siguientes pasos:

PRECAUCIÓN: No hay vuelta atrás

Por código

Por interfaz gráfica

APENDICE

Conectividad entre sites

Los sites CPD1 y CPD2 de este artículo se simulan mediante un WSFC multi-site. En ese escenario, los equipos de CPD1 y CPD2 se encuentran en segmentos de red diferentes de forma que por defecto no existe comunicación entre ellos.
Obviamente nosotros deberemos tener un nexo común en nuestra arquitectura por donde pasará la comunicación entre dichos sites y configurar las tablas de enrutamiento para que podamos ver los diferentes segmentos de red. Para ello hemos optado por utilizar el “Servicio de enrutamiento y acceso remoto” de Windows Server, que hemos alojado en la misma máquina que hace de Domain Controller.

NOTA: No es una buena práctica configurar el servicio de enrutamiento en la misma máquina que hace de Domain Controller pero se entiende que es por fines didácticos

Monitor de grupos de disponibilidad AlwaysOn

Como parte de la monitorización de escenarios de alta disponibilidad que incluyan AlwaysOn, se incluye un monitor. Esta aplicación es bastante simple pero efectiva y nos da de un vistazo rápido el estado actual de nuestras configuraciones AlwaysOn. Para lanzarlo es tan sencillo como abrirlo desde SSMS:

De toda la información que presenta el formulario anterior, lo que realmente debe centrar nuestra atención es la parte relativa al estado de sincronización y el estado de Availability Group State.
Parece que se trata de un informe sencillo pero realmente esconde la validación de numerosas reglas de políticas de administración declarativa. Internamente dicho formulario está realizando las validaciones que tenemos aquí:

Por lo tanto, se están realizando validaciones del estado de la réplica, de su sincronización, de su conectividad,…

Política de copias de seguridad

Pese a que se desea implementar un sistema de alta disponibilidad geográficamente disperso mediante AlwaysOn, se recomienda siempre realizar una política correcta de base de datos puesto que cuanta más seguridad mejor.
Habitualmente es una buena estrategia generar una política de copias de seguridad que cubra un escenario de pérdida de datos de hasta 15 minutos en el peor de los casos (siempre que los ficheros sean movidos fuera del servidor caído y puedan recuperarse).
Este escenario solo se necesitará en el caso de caída completa de ambos CPD, cosa muy improbable pero que no por ello debamos evitar de contemplar.

NOTA: Recordar que siempre se podrá balancear failover cluster o AlwaysOn y que por tanto estamos cubiertos por redundancia de máquina y de BBDD real. Este apartado es un extra de seguridad

En el caso de tener que cubrir un escenario de restauración completo, recordar que la estrategia debe ser (en orden):

  • Restaurar el último backup completo
  • Restaurar el último backup diferencial tras el último completo
  • Restaurar todos y cada uno de los backups de log de transacciones tras el último diferencial restaurado que se tenga

De esta forma, según el diagrama anterior:

Si se rompe el servidor a las 11:29

  • Restauramos el backup full de la 1
  • Restauramos el diferencial de las 5:30
  • Restauramos el log de las 6:30 y luego el de las 8:30 (en orden)

Si se rompe el servidor a las 21:32

  • Restauramos el backup full de la 1
  • Restauramos el diferencial de las 21:30

Además de esto, en una configuración con grupos de disponibilidad se puede incluso configurar los nodos secundarios para realizar los backups y así liberar carga del nodo principal en entornos 24x7. Para ello se recomienda visitar el siguiente enlace https://msdn.microsoft.com/es-es/library/hh245119.aspx