Microsoft Lync Server
Header

Lync Server 2013: Configuración de Alta Disponibilidad en los servidores de Back-END (SQL Server) con un Testigo en SQL Server 2012 Express

julio 3rd, 2014 | Posted by Santiago Buitrago in Lync Server

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:

Lync_HA_SQL_Testigo.jpg
Como os había comentado en el artículo anterior (Lync Server 2013: Configuración de Alta Disponibilidad (SQL Server Mirroring)), si hemos configurado nuestras BBDD de Lync con mirroring, tenemos un sistema de alta disponibilidad pero no un failover automático. En el caso de que el servidor principal de SQL Server no se encuentre disponible, tenemos que ejecutar el siguiente cmdlet para establecer como servidor activo el segundo servidor:
 
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:
Publicar_Topología_Error_Testigo_1.png
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:

Publicar_Topología_Error_Testigo_11.png

 

Publicar_Topología_Error_Testigo_12.png
Publicar_Topología_Error_Testigo_13.png
Publicar_Topología_Error_Testigo_14.png
Publicar_Topología_Error_Testigo_15.png

 

 

Si queremos podemos crear una instancia dedicada, pero no es obligatorio, si queréis podéis elegir la instancia predeterminadaPublicar_Topología_Error_Testigo_17.png
Publicar_Topología_Error_Testigo_20.png
Publicar_Topología_Error_Testigo_23.png
Publicar_Topología_Error_Testigo_24.png
Publicar_Topología_Error_Testigo_25.png
Publicar_Topología_Error_Testigo_26.png

 

Ahora que hemos finalizado la instalación podemos iniciar el Microsoft SQL Server Management Studio y vemos la instancia LYNC que hemos creado previamentePublicar_Topología_Error_Testigo_33.png

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:

 

Publicar_Topología_Error_Testigo_32.png
 
Para poder habilitar las conexiones remotas debemos configurarlo desde el Administrador de configuración de SQL Server
Publicar_Topología_Error_Testigo_27.png

 

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

 

Publicar_Topología_Error_Testigo_28.png
Pulsamos con el botón secundario del ratón en cada uno de los protocolos y pulsamos en Habilitar
Publicar_Topología_Error_Testigo_29.png
 
Para que los cambios se hagan efectivos, debemos reiniciar los servicios del SQL Server EXPRESS una vez que hayamos habiiltado ambos protocolos
Publicar_Topología_Error_Testigo_30.png
El reinicio de los servicios podemos hacerlo directamente desde esta misma consola desde la opción de Servicio de SQL Server

 

Publicar_Topología_Error_Testigo_31.png

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

 

Publicar_Topología_Error_Testigo_35.png
 
Iniciamos el servicio y una vez que el SQL Server y el Browser estén en ejecució y el modo de inicio en automático, ya podemos continuar con el resto de configuraciones de Lync

 

 

Publicar_Topología_Error_Testigo_34.png
Como sabéis, el testio uitlizará el puerto 7022 en TCP para conectarse con los servidores de SQL que tienen las BBDD en Mirroring, por lo que debemos crear una excepción en el firewall local  (o dispositivo de seguridad que fuese necesario). Esta configuración sería más recomendado hacerla por GPO, pero como es un LAB lo haremos de forma manual creando una excepción del puerto 7022 en TCP en el Firewall Local del servidor de SQL Server EXPRESS que hará de testigo para los servidores de BBDD de Lync:

 

Publicar_Topología_Error_Testigo_4.png

Publicar_Topología_Error_Testigo_5.png

Publicar_Topología_Error_Testigo_6.png

 

Como mi servidor que hará de testigo está unido al mismo dominio que el resto de servidores, solo habilito esta excepción para la red de dominio
Publicar_Topología_Error_Testigo_7.png

 

Publicar_Topología_Error_Testigo_8.png

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

Publicar_Topología_Error_Testigo_2.png

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

Publicar_Topología_Error_Testigo_3.png

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:

 

Publicar_Topología_Error_Testigo_43.png

 

Ahora cuando uno de los dos servidores SQL no esté disponible por la razón que sea, el testigo cambiará a principal en el mirroring el servidor que esté activo. Si queremos hacer una simulación solo debemos parar el servicio de SQL Server del servidor principal y veremos como  el servidor reflejado será el principal y el principal el reflejado. Esta configuración nos permitirá tener en Alta Disponibilidad con recuperación automática nuestros servidores de Back-END.
 
De todas formas, como os comentaba al inicio si queréis hacer el failover manual tenemos los siguientes cmdets:
 
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
Como esto podemos configurar quien es el servidor principal y quien el reflejado por cada BBDD.

Espero que os sea de utilidad!!!

You can follow any responses to this entry through the RSS 2.0 You can leave a response, or trackback.

Leave a Reply

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *