En su momento había publicado un artículo de como configurar un entorno de Alta Disponibilidad utilizando la replicación de las BBDD de Lync (Lync Server 2013: Configuración de Alta Disponibilidad (SQL Server Mirroring))​, pero lo había configurado sin un failover automático. En esta ocasión vamos a configurar un tercer servidor de SQL Server que hará de testigo, que permitirá disponer de un sistema de failover automático en caso de que el servidor de SQL declarado como "principal" esté caido o desconectado.  Este sería el esquema básico de sistema de mirroring con un testigo:

Invoke-CsDatabaseFailover -DatabaseType <Application | Archiving | Monitoring | User | Provision | CentralAdmin | Lyss | Registrar | Edge | PersistentChat | PersistentChatCompliance | CentralMgmt> -NewPrincipal <Primary | Mirror> -PoolFqdn <Fqdn> [-Confirm [<SwitchParameter>]] [-ExcludeDatabaseList <String[]>] [-Force <SwitchParameter>] [-LocalStore <SwitchParameter>] [-Report <String>] [-WhatIf [<SwitchParameter>]]

 

Antes de ejecutar los siguientes cmdlets, debemos ejecutar Get-CsService –CentralManagement que nos devolverá que servidor está como principal y como reflejado:

De esta forma podremos comprobar que servidor tiene que rol en este momento, entonces en función del estado de los servidores podremos ejecutar los siguiente cmdlets en función de la necesidad de cada escenario y en cada momento concreto. Veamos estos dos ejemplos:

 

Ejemplo 1: cuando queremos que el servidor de base de datos activo sea el reflejado (SRV-SQL01)

• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType User –NewPrincipal mirror
• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType App –NewPrincipal mirror
• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType CentralMgmt –NewPrincipal mirror
• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType Monitoring –NewPrincipal mirror

Ejemplo 1: cuando queremos que el servidor de base de datos activo sea el principal (SRV-SQL00)

• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType User –NewPrincipal primary
• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType App –NewPrincipal primary
• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType CentralMgmt –NewPrincipal primary
• Invoke-CsDatabaseFailover –PoolFQDN pool.asirsl.com –DatabaseType Monitoring –NewPrincipal primary

Este proceso manual, tendrá un tiempo objetivo de recueración (RTO) de 5 min, pero el usuario no tendrá una experiencia completa hasta pasados unos 30 minutos. Durante este tiempo los usuarios estarán conectados pero no podrá utilizar ciertos servicios, como por ejemplo agregar usuarios, etc…. estarán en modo de resistencia (la traducción se las trae …). Ahora bien, esto lo podemos solventar y tener un sistema de failover automático y que los usuarios no tengan corte alguno. Para ello, debemos implementar un tercer servidor que nos haga de "testigo", básicamente sabrá que servidor está como primario y reflejado y los intercambiará en función de su disponibilidad. Esto nos permitirá que los usuarios no se vean afectados por la no disponibilidad de uno de los servidores y además la conmutación sea transparente también para el administrador. La configuración del mirroring tenía los siguientes requisitos en cuanto a las versiones de SQL Server se refiere: 

• Lync Server Enterprise
• Dos Servidores de SQL Server con la misma versión de SQL (Versión 2008 R2 o superior)
• Una excepción de Firewall de Windows (o el que tengáis) para el puerto 5022 en TCP IN/OUT (utilizado por el mirroring)
• Una carpeta compartida para el proceso de volcado iniciado de la base de datos desde el SQL Primario al receptor de la copia o secundario, esta carpeta compartida se puede borrar una vez que se haya completado la publicación
• Establecer los permisos sobre la carpeta compartida, de tal forma que los usuarios asignados a los servicios de ambos SQL Server tengan acceso a la carpeta compartida con lectura/escritura

Pero si queremos añadir un tercer servidor que realice las funciones de testigo, no tiene porque tener la misma versión de SQL Server y además puede ser un SQL Server EXPRESS. Esto desde luego ayuda mucho a abaratar los costes de una solución de alta disponibilidad como esta. Una vez comentado esto, veamos como podemos configurarlo puesto que podemos realizar su configuración en mismo momento que configuramos el mirroring o a posteriori. En nuestro caso, como ya tenemos el mirroring de las BBDD de Lync completado (*), vamos a ver como implementarlo a posteriori. 

(*) Nota: Si queremos configurar un testigo y ya tenemos el morroring configurado, debemos primero deshacer el mirroring con el siguiente cmdlet primero y luego desde el generador de topologías

Uninstall-CsMirrorDatabase -SqlServerFqdn <SQLServer FQDN> [-SqlInstanceName <SQLServer instance name>] -DatabaseType <Application | Archiving | CentralMgmt | Monitoring | User | BIStaging | PersistentChat | PersistentChatCompliance> [-DropExistingDatabasesOnMirror] [-Verbose]

Con el modificador -DropExistingDatabasesOnMirror eliminará las BBDD del servidor reflejado, pero esto no siempre funciona bien  por lo que es posible que tengáis que eliminarlas de forma manual.

Como ya tenemos las BBDD en Mirroring, lo que haremos ahora será instalar un SQL Server 2012 en su versión EXPRESS para configurarlo como testigo. Para ello debemos descarganos los binarios necesarios (Download SQL Server 2012 Express with SP1) e iniciar su instalación:

Si queremos podemos crear una instancia dedicada, pero no es obligatorio, si queréis podéis elegir la instancia predeterminada

Ahora que hemos finalizado la instalación podemos iniciar el Microsoft SQL Server Management Studio y vemos la instancia LYNC que hemos creado previamente

Ahora lo que debemos hacer es permitir las conexiones remotas, que por defecto en las versiones EXPRESS viene deshabilitado por defecto. Si queréis verificarlo, podéis iniciar el Microsoft SQL Server Management Studio desde otro servidor y tratar de conectaros a la instancia que hayáis configurado y veréis que no tenéis acceso:

Una vez dentro, nos vemos a la instancia de Lync que hemos creado anteriormente en el proceso de instalación dentro de la opción Configuración de red de SQL Server y habilitamos las Canalizaciones con nombre y TCP/IP

Por último, vamos a habilitar el servicio de SQL Server Browser y lo haremos desde las propiedades del servicio, cambiando el Modo de Inicio de Deshabilitado a Automático

Y una vez que hemos complido los requisitos necesarios, abrimos el Generador de Topologías de Lync Server, editamos nuestro pool de servidores Front-END y habilitamos la casilla Usar el testigo de creación de reflejo de SQL Server para habilitar la conmutación tras fallo automático

Si previamente no hemos configurado ningún testigo, debemos pulsar en Nuevo y cubrimos los siguientes datos para dar de alta un testigo

Una vez que hemos creado nuestro testigo, pulsamos en Aceptar y publicamos nuestra topología, con esto ya tenemos nuestros servidores de SQL Server con sus BBDD en Mirroring y el SQL Server EXPRESS como testigo. Para ello nos vamos al servidor BBDD principal y nos vamos a las propiedades de una de las BBDD reflejadas y vemos que ya tenemos el testigo configurado y preparado para establecer el servidor de SQL activo cuando sea necesario:

Espero que os sea de utilidad!!!