Vamos a iniciar una serie de artículos sobre la implentación de Lync Server 2013 en Alta Disponibilidad, me gustaría comenzar por la configuración de la replicación (mirroring) de las bases de datos. En principio el escenario más básico sería algo parecido a lo que os muestro en este esquema:

 

2. Configuraciones

Sí ya estáis trabajando con Lync y todos los servicios configurados correctamente, esto es lo único que debéis hacer para configura vuestras bases de datos de Lync en Alta Disponibilidad. Si estáis creado una nueva topología, en el mismo proceso de configuración inicial tenéis la posibilidad de configurar el reflejo de la base de datos. En este artículo yo lo voy a configurar después de tener todo correctamente funcionando:

• 1 pool de dos Front-END
• 1 Mediation Server
• 1 Chat Persistente
• 1 Edge
• 1 WAC
• 1 Exchange 2013

Lo primero que haremos será comprobar que tenemos dos servidores de SQL Server con una versión de SQL Server 2008 R2 o superior, y que además tienen la misma revisión de actualizaciones instaladas. Para ello abrimos el Management Studio y nos conectamos a ambos servidores para comprobar las versiones de ambos servidores:

El servidor primario es el SQL-SQL00 y tiene la versión 10.50.2550, y el que recibirá la réplica será el SRV-SQL2 con una versión 10.50.1617 por lo que primero toca actualizar la versión de SQL de SRV-SQL2 (este paso lo omito). Una vez que lo hemos actualizado, volvemos a verificar que están ambos servidores con la misma versión:

Ahora que tenemos ambos servidores con la misma versión de SQL Server, vamos comprobar que el puerto 5022 está activo en ambos servidores y que desde su opuesto podemos conectarnos. Para ello primero utilizaremos el siguiente comando: netstat -an | find ":5022". Como podemos observar el puerto 5022 está a la escucha (Listening), listo para recibir conexiones por el puerto 5022 en TCP. Esto mismo debemos comprobarlo en ambos servidor, para verificar que el servicio está activo y disponible

Que el puerto esté disponible, no quiere decir que ambos servidores tengan visibilidad del mismo en el otro servidor. Vamos, que podemos tener un Firewall/Router u otro dispositivo de seguridad que esté filtrando este puerto, evitando que se puedan comunicar entre ellos. Una prueba que podemos hacer muy sencilla, es ejecutar un telnet hacia la IP del otro servidor y especificando el puerto 5022: telnet IP/FQDN_SRV_SQL 5022

Si la comunicación se establece sin problemas, veremos una ventana similar a esta (cursor fjo)

En el caso de que no se pueda conectar, por el motivo que sea (resolución DNS, Firewall, etc..), la ventana que nos mostraría sería algo parecido a esto:

Dando por hecho que la conexión entre ambos servidores se ha completado correctamente, vamos a empezar con la configuración del reflejo de la base de datos. Para ello debemos abrir el Generador de Topologías y editamos nuestro pool de servidores Front-END y pulsamos en Editar propiedades …

Marcamos la casilla  Habilitar la creación de reflejos de almacén de SQL Server

Sino tenemos un almacén de SQL Server diferente al almacén de SQL principal, debemos pulsar en nuevo para crearlo

Completamos los cuadros correspondientes: FQDN de SQL Server (servidor de reflejo (secundario)) y Número de puerto de reflejo (lo dejamos por defecto (recomendado), en caso contrario debemos modificar el puerto en el SQL Server), pulsamos en Aceptar

Sí ahora nos vamos a la opción de Componentes Compartidos – Almacenes de SQL Server en el Generador de Topologías ya tendremos disponible este nuevo almacén que utilizaremos para el reflejo

Ahora nos queda publicar la topología, pero antes de esto vamos a crear el recurso compartido con los permisos correspondientes. Creamos una carpeta en algún servidor de SQL Server u otro servidor disponible, y asignamos como permisos de Lectura/Escritura a los usuarios asignados a los servicios de SQL Server. Cuando el SQL Server inicie el reflejo de las bases de datos, las credenciales que presentará serán las que tiene asignadas en el servicio de SQL Server. Para verificar que usuario tiene asignado el servicio, abrimos la consola de Servicios (Inicio – Ejecutar – Services.msc)

Servidor: SRV-SQL00, Usuario: SQLServicio

Servidor: SRV-SQL2, Usuario: SQLSrv

Creamos una carpeta en el serivdor SRV-SQL2 (por ejemplo) y la compartimos con los siguientes permisos:

Permisos de Carpeta Compartida

Permisos NTFS

Podemos verificar que el recurso está accesible desde la red tratando de acceder a la ruta UNC \\nombre_servidor\Recurso_Compartido, siempre y cuando tengamos permisos con el usuario que tratamos de conectarnos sobre el recurso. Yo lo he hecho con una cuenta que pertenece al grupo Admins. del Dominio y en la carpeta compartida este grupo también le he configurado los permisos necesarios. Con esto verificamos que el Firewall del equipo u otro dispositivo de seguridad no impide la conexión al recurso compartido, y desde luego si con una cuenta con permisos se puede acceder con las cuentas de servicios también:

Una vez que hemos compartido, vamos a continuar con la publicación de la topología

Pulsamos en Siguiente

Se nos alerta de que no tenemos configurado el recurso compartido que se utilizará para la primera sincronización del mirroring

Pulsamos en Configuración y escribimos la ruta de destino de la carpeta compartida y pulsamo en Aceptar

Ahora que ya no tenemos ninguna advertencia pulsamos en Siguiente para completar la  publicación de la topología

Mientras se publica la topología y se crea la base de datos de reflejo, podemos observar como se copian los ficheros de la base de datos del servidor principal al recurso compartido que utilizará para restaurarlo en el servidor secundario

Una vez que finalice la publicación  de forma correcta, pulsamos en Finalizar y se ha completado la configuración de Alta Disponibilidad en cuanto a las bases de datos de Back-End de nuestra Topología

Si queremos comprobar que se están replicando correctamente, nos vamos al Managmegent Studio del SQL Server del servidor de destino (secundario) de la réplica y vemos las bases de datos con el estado de Reflejando, Sincronizando/Restaurando, por lo que está funcionando correctamente.

Si volvemos a ejecutar el comando netstat -an | findstr ":5022" vemos que tiene conexiones establecidas entre ambos servidor de SQL, lo que indica que la replicación a nivel de comunicaciones está activa

Como os comentaba al principio, la carpeta compartida solo la necesitamos para la primera sincronización entre servidores de SQL Server, después podemos descompartirla y borrar su contenido. Aquí os muestro una captura de pantalla 10 minutos después de configurar el reflejo de las bases de datos, como veis la última fecha/hora de actualización de los ficheros desde las 15:46 no se han vuelto a tocar.

En Lync Server 2013 como veis esto se ha simplificado bastante, y no tenéis que disponer de conocimientos de DBA para configurar un sistema en Alta Disponibilidad. Esta configuración de Alta Disponibilidad no es automática, vamos que si el servidor de SQL Server Primario tiene algún problema, el segundo servidor no se pondrá como activo de forma automática, debemos configurarlo nosotros mediante PowerShell. El cmdlet para

Sintaxis: Invoke-CSDatabaseFailover -PoolFQDN fqdn_pool_servidores_front-end -DatabaseType User -NewPrincipal fqdn_servidor_secundario -verbose

Ejemplo: Invoke-CSDatabaseFailover -PoolFQDN pool.asirsl.com -DatabaseType User -NewPrincipal srv-sql2.asirsl.com -verbose

Este cmdlet nos sirve para posteriormente volver a poner como servidor de base de datos principal al servidor que se nos había caído inicialmente, pero si antes queremos verificar quien está actuando como servidor primario y secundario tenemos el siguiente cmdlet:

Sintaxis: Get-CsDatabaseMirrorState -PoolFQDN fqdn_pool_servidores_front-end -DatabaseType User

Ejemplo: Get-CsDatabaseMirrorState -PoolFQDN pool.asirsl.com -DatabaseType User

Si queremos que esto sea un proceso automático, para que en cuanto el servidor principal esté caído se configure como principal el que está recibiendo la réplica debemos configurar un tercer servidor que haga de testigo. Este servidor debe tener la misma versión SQL Server, y para habilitarlo debemos hacerlo desde el Generador de Topologías y marcar las casilla Usar el testigo de creación de reflejo de SQL Server para habilitar la conmutación tras fallo automática. Esto evitará que tengamos que manualmente realizar dicho cambio, claramente recomendado. La configuración es muy similar al del SQL Server de reflejo, tenemos que dar de alta el almacén de SQL Server para el testigo, etc….

El servidor que hará de testigo utilizará el puerto 7022 en TCP, podemos utilizar el mismo procedimiento para verificar si está a la escucha y disponible que para el puerto 5022 en TCP.  Este sería el esquema básico del entorno de Mirroring con Testigo:

Espero que os sea de utilidad!!!