Lync Server soporta la configuración de equilibrio de carga vía DNS para el tráfico SIP y de Medios, pero para los servicios HTTPs debemos implementar alguna de las soluciones de hardware existentes en el mercado. Podemos utilizar el equilibrio de carga vía DNS para los Director, Front-End, Mediation Server y Edge (con excepciones) para para el tráfico SIP y Media, para los servicios web (HTTP/(S)) debemos adquirir un balanceador vía hardware. Voy a tratar de comentar un poco cuales son los pasos a seguir para montar un sistema de balanceo vía DNS, para ello he creado este pequeño esquema que espero que os ayude a haceros una composición de lugar:
-
Pool de Servidores Front-END
-
Pool de Servidores Director
-
Pool de Servidores de Mediación
-
Pool de Servidores EDGE
-
Dos conexiones de Internet con un Firewall para cada conexión, en alta disponibilidad, y cada Firewall tienen un pool de 4 IPs públicas
(pulsar en la imagen para ver el esquema a tamaño real)
Veamos cuales son las configuraciones a llevar a cabo en cada caso:- Pool de Front-END y/o Directores
Debemos tener dos FQDN, uno que se corresponde con el nombre del pool y otro con los servicios web. Debemos crear el FQDN del pool con la IP de cada uno de los servidores del pool, en el ejemplo del esquema serían de la siguiente forma:
Registro DNS Tipo A para el FQDN pool.dominio.com con las IPs de los servidores del pool: 192.168.0.10 y 192.168.0.11
Registro DNS Tipo A para el FQDN del servicio Web lync. Dominio apuntando a la IP virtual del grupo de servidores. Aquí debemos tener en cuenta que debemos activar la casilla Reemplazar FQDN interno del grupo de servidores de servicios web internos y debemos escribir las URL para los servicios web
Debemos tener en cuenta que si tenemos más de un pool de servidores Front-END o Directores, debemos tener nombres diferentes tanto para los pool como para los servicios web. El balanceo vía DNS solo es efectivo para el tráfico SIP y de media, para el tráfico web debemos configurar balanceadores vía hardware. Debemos crear el registro para el FQDN de los servicios Web con la IP del balanceador:
Servidores Front-END:
- Registro DNS Tipo A para el FQDN meet.dominio.com con las IPs de los servidores del pool: 192.168.0.16
- Registro DNS Tipo A para el FQDN dialin.dominio.com con las IPs de los servidores del pool: 192.168.0.16
- Registro DNS Tipo A para el FQDN lyncdiscoverinternal.dominio.com con las IPs de los servidores del pool: 192.168.0.16
- Registro DNS Tipo A para el FQDN lync.dominio.com con las IPs de los servidores del pool: 192.168.0.16
Servidores Directores (publicación mediante reverse-proxy):
- Registro DNS Tipo A para el FQDN meet.dominio.com con las IPs de los servidores del pool: 192.168.0.17
- Registro DNS Tipo A para el FQDN dialin.dominio.com con las IPs de los servidores del pool: 192.168.0.17
- Registro DNS Tipo A para el FQDN lync.dominio.com con las IPs de los servidores del pool: 192.168.0.17
- Registro DNS Tipo A para el FQDN lync.dominio.com con las IPs de los servidores del pool: 192.168.0.17
Las peticiones provienen de internet y se publican mediante un reverse-proxy hacia el balanceador hardware que luego distribuirá la peticiones hacia los Directores
- Servidores de Mediación
Debemos crear un registro DNS con el nombre del grupo de servidores y con cada IP de cada servidor de mediación.
Registro DNS Tipo A para el FQDN poolms.dominio.com con las IPs de los servidores del pool: 192.168.0.12 y 192.168.0.13
- Servidores EDGE
El rol del EDGE es algo más particular, porque no podemos utilizar el balanceo de carga vía DNS en los siguientes escenarios:
- Federación con organizaciones que ejecutan versiones de Office Communications Server anteriores a Lync Server 2010.
- Intercambio de mensajes instantáneos con usuarios de servicios de mensajería instantánea (MI) pública, como Windows Live, AOL y Yahoo!, además de servidores y proveedores basados en XMPP, como Google Talk.
Esto funcionará adecuadamente si todos los servidores EDGE del pool están funcionando correctamente, pero si uno de ellos no está funcionando todas las solicitudes hacia ese servidor no serán enviadas a otro servidor del pool. Esto es un problema y muy importante a tener en cuenta, para que esto funcione de forma adecuada debemos implementar un balanceador de hardware. He creado el siguiente esquema de como podríamos implementar un sistema de balanceo vía DNS para toda la infraestructura a excepción de los servidores EDGE que utilizarán balanceadores hardware para las conexiones internas y externas:
(pulsar en la imagen para ver el esquema a tamaño real)
Si aún con estos condicionantes debemos configurar el balanceo vía DNS debemos configurar los siguientes registros DNS internos y externos:-
Registros Internos
Registro DNS Tipo A para el FQDN edge.dominio.com con las IPs de los servidores del pool: 192.168.10.3 y 192.168.10.4
-
Registros Externos (las direcciones IP Públicas son inventadas)
Registro DNS Tipo A para el servicio de acceso (sip.dominio.com) con las IPs de dos conexiones a internet diferentes (alta disponibilidad a nivel de las conexiones de datos)
- Conexión 1: 222.222.222.1
- Conexión 2: 222.222.222.4
Registro DNS Tipo A para el servicio de A/V (av.dominio.com) con las IPs de dos conexiones a internet diferentes (alta disponibilidad a nivel de las conexiones de datos)
- Conexión 1: 222.222.222.2
- Conexión 2: 222.222.222.5
Registro DNS Tipo A para el servicio de conferencia (webconf.dominio.com) con las IPs de dos conexiones a internet diferentes (alta disponibilidad a nivel de las conexiones de datos)
- Conexión 1: 222.222.222.3
- Conexión 2: 222.222.222.6
Otra cosa que debemos tener en cuenta si utilizamos el balanceo de cargar vía DNS es el problema con la mensajería instantánea de Exchange con los usuarios remotos:
- Reproducir el correo de voz de Enterprise Voice en el teléfono
- Transferir llamadas de un operador automático de la mensajería unificada de Exchange
El resto de servicios de la mensajería unificada funcionarán sin problema, pero es algo a tener en cuenta. Y por último debemos implementar el mismos sistema de balanceo de carga para las interfaces externas e internas, o utilizamos DNS o balanceadores vía hardware.
Si bien, ahora queremos implementar el balanceo vía hardware, los FQDN con las IPs externas quedarían exactamente igual pero el FQDN e IP del registro interno deberá apuntar a la VIP (Virtual IP) del balanceador:
Registro DNS Tipo A para el FQDN edge.dominio.com con las IPs de los servidores del pool: 192.16810.1
Otra es que las conexiones desde el exterior pasarían por los firewall perimetrales y se enviarían directamente al balanceador (y no a los EDGE directamente) a cada una de las VIP (Virutal IP) para cada servicio que enviará a los EDGE de forma balanceada:
- Servicio de Acceso: 192.168.15.1
- Servicio de A/V: 192.168.15.2
- Servicio de Conferencia: 192.168.15.3
Ahora por parte del cliente Lync, tanto en la versión 2010 como 2013 utilizarán el balanceo de carga vía DNS sin problema. Como sabéis cuando un cliente se conecta a un grupo de servidores Front-END, lo primero es realizar una consulta al DNS para saber que servidor están configurados, si no consigue conectarse con uno de los servidores tratará de conectarse con alguno de los otros servidores del grupo. Los clientes anteriores a 2010, utilizarán al balanceo de carga vía DNS, pero si no le conecta el primer servidor al que se intenta conectar, no tratará de conectarse a otro servidor del grupo.
Este mismo proceso se consigue cuando es un usuario externo, aquí os muestro un resumen de las consultas DNS que debe realizar para iniciar sesión y utilizar los distintos servicios (Acceso, A/V, Conferencia Web):
Por último y por aclarar que el balanceo de carga podemos utilizarlo para el tráfico SIP y de Medios, pero para los servicios web (Front-END o Director) debemos utilizar un balanceador vía hardware. Si queremos implementar balanceo de carga a nivel de EDGE, igualmente debemos utilizar balanceadores hardware para mantener siempre la disponibilidad en caso de algún fallo en alguno de los servidores EDGE.
Espero que os sea de utilidad!!!
