Microsoft Lync Server 2013: 配置SQL见证服务器数据分发
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:
En Lync 2010 esta configuración era un poco diferente, porque necesitabas tener un SQL Enterprise Clúster. En Lync 2013 utilizaremos SQL Server Mirroring, lo que nos facilitará mucho las cosas, además de que en Lync 2013 no está soportado el clúster en SQL. Con este mini introducción, vamos a ver qué pasos tenemos que dar para configurar nuestras BBDD de Lync en Alta Disponibilidad:
1. Requisitos
- 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 conlectura/escritura
2. Configuraciones
- Habilitar creación de reflejos de almacén de SQL Server en el Generador de Topologías de Lync
- Publicar topología
- Verificación del mirroring
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
Usuarios: SQLSrv, SQLServicio
Permisos: Cambiar
Permisos NTFS
Usuarios: SQLSrv, SQLServicio
Permisos: Modificar
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:
En los siguientes artículos iremos analizando como configurar otros roles en Alta Disponibilidad, y veremos cosas muy interesantes
Espero que os sea de utilidad!!!