Cerrar
InicioComunicaciones UnificadasLync ServerLync Server 2013: Configuración de Alta Disponibilidad (SQL Server Mirroring)

Lync Server 2013: Configuración de Alta Disponibilidad (SQL Server Mirroring)

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:

Lync_HA_SQL.jpg
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 con lectura/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:

Lync_2013_HA_SQL_1.png

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:

Lync_2013_HA_SQL_7.png
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

Lync_2013_HA_SQL_25.png

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

Lync_2013_HA_SQL_26.png

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

Lync_2013_HA_SQL_27.png

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:Lync_2013_HA_SQL_28.png

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 …

Lync_2013_HA_SQL_2.png

Marcamos la casilla  Habilitar la creación de reflejos de almacén de SQL Server
Lync_2013_HA_SQL_3.png
Sino tenemos un almacén de SQL Server diferente al almacén de SQL principal, debemos pulsar en nuevo para crearloLync_2013_HA_SQL_4.png

Lync_2013_HA_SQL_5.png

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

Lync_2013_HA_SQL_6.png

Sí ahora nos vamos a la opción de Componentes CompartidosAlmacenes de SQL Server en el Generador de Topologías ya tendremos disponible este nuevo almacén que utilizaremos para el reflejoLync_2013_HA_SQL_9.png

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

Lync_2013_HA_SQL_14.png

Servidor: SRV-SQL2, Usuario: SQLSrv

Lync_2013_HA_SQL_29.png

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:

Lync_2013_HA_SQL_17.png

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

Lync_2013_HA_SQL_10.png

Pulsamos en Siguiente

Lync_2013_HA_SQL_11.png

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

Lync_2013_HA_SQL_12.png

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

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

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

Lync_2013_HA_SQL_20.png

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

Lync_2013_HA_SQL_21.png

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.

Lync_2013_HA_SQL_22.png

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
Lync_2013_HA_SQL_23.png

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.Lync_2013_HA_SQL_24.png

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

Lync_2013_HA_SQL_30.png

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….

Lync_2013_HA_SQL_31.png

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:

Lync_HA_SQL_Testigo.jpg
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!!!

Test-CsComputer: Tes
Actualización Lync

sbuytrago@asirsl.com

5 COMENTARIOS

DEJA UN COMENTARIO

Este sitio web utiliza cookies. Si continúas navegando, consideramos que aceptas su uso. Puedes obtener más información en nuestra política de cookies. ACEPTAR

Aviso de cookies
Share This