Planeamiento avanzado de DNS del servidor perimetral para Skype Empresarial Server
Resumen: Revise los escenarios para ver Skype Empresarial Server opciones de implementación. Tanto si desea un único servidor como si prefiere un grupo de servidores con DNS o HLB, este tema debería ayudarle.
En lo que respecta a la planificación del Sistema de nombres de dominio (DNS) para Skype Empresarial Server, muchos factores pueden jugar en su decisión. Si la estructura del dominio de su organización ya está en el lugar correcto, puede ser una cuestión de revisar la manera en la que va a continuar. Comenzaremos con los temas que se encuentran a continuación:
Walkthrough of Skype for Business clients locating services
Skype Empresarial clientes son similares a las versiones anteriores de los clientes de Lync en la forma en que encuentran y obtienen acceso a los servicios en Skype Empresarial Server. Esta sección contiene información sobre el proceso de ubicación del servidor.
lyncdiscoverinternal.<Dominio>
Es un registro de host A para el servicio Detección automática en los servicios web internos.
lyncdiscover.<Dominio>
Es un registro de host A para el servicio Detección automática en los servicios web externos.
_sipinternaltls._tcp.<Dominio>
Este es un registro SRV para conexiones TLS internas.
_sip._tls.<Dominio>
Este es un registro SRV para conexiones TLS externas.
sipinternal.<Dominio>
Se trata de un registro de host para el grupo de servidores front-end o director, que solo se puede resolver en la red interna.
Sip.<Dominio>
Se trata de un registro de host para el grupo de servidores front-end o director, que solo se puede resolver en la red interna.
sipexternal.<Dominio>
Se trata de un registro de host para el servicio perimetral de acceso, cuando el cliente es externo.
El servicio Detección automática es siempre el favorito, ya que es el método preferido para la ubicación del servicio y los demás son métodos reserva.
Nota
Al crear registros SRV, es importante recordar que tienen que señalar a un registro A de DNS (y AAAA si está usando el direccionamiento IPv6) en el mismo dominio en el que se ha creado el registro de DNS SRV. Por ejemplo, si el registro SRV está en contoso.com, el registro A (y AAAA) al que señala no puede encontrarse en fabrikam.com.
Si lo desea, puede configurar su dispositivo móvil para la detección manual de servicios. Si es lo que quiere hacer, cada usuario tiene que configurar los parámetros del dispositivo móvil con las URL internas y externas completas del servicio Detección automática, incluyendo el protocolo y la ruta de acceso, de la manera siguiente:
Para el acceso externo: https://< ExtPoolFQDN>/Autodiscover/autodiscoverservice.svc/Root
Para el acceso interno: https://< IntPoolFQDN>/AutoDiscover/AutoDiscover.svc/Root
Le recomendamos que use la detección automática en lugar de la detección manual. Sin embargo, si estás haciendo algunas pruebas o solución de problemas, la configuración manual puede ser útil.
DNS de horizonte dividido
Se trata de una configuración de DNS en la que tiene dos zonas de DNS con el mismo espacio de nombres. La primera zona DNS trata solicitudes internas, mientras que la segunda zona DNS trata las solicitudes externas.
¿Por qué haría esto una compañía? Puede que tengan un requisito de usar el mismo espacio de nombres internamente y externamente, pero, por supuesto esto llevará a muchos SRV de DNS y registros A únicos en una zona u otra, y donde hay duplicación, las direcciones IP asociadas con estos registros serían únicas.
Esta situación presenta algunos desafíos. El más importante es que el DNS de cerebro dividido no es compatible con la movilidad. Esto se debe a los registros DNS LyncDiscover y LyncDiscoverInternal (LyncDiscover tiene que definirse en el servidor DNS externo, mientras que LyncDiscoverInternal tiene que definirse en el servidor DNS interno).
Aquí mostraremos los registros DNS para las zonas internas y externas, pero puede encontrar ejemplos detallados en la sección Requisitos ambientales del servidor perimetral.
DNS interno
Contiene una zona DNS llamada (por ejemplo) contoso.com, para la que es relevante.
Esta contoso.com interna contiene:
Registros DNS A y AAAA (si usa el direccionamiento IPv6) para el grupo de servidores front-end, el grupo de directores o el nombre del grupo de directores, y todos los servidores internos que ejecutan Skype Empresarial Server en la red de su organización.
Registros A y AAAA de DNS (si usa el direccionamiento IPv6) para la interfaz interna de Edge para cada Skype Empresarial Server servidor perimetral de la red perimetral.
Dns A y AAAA (si usa el direccionamiento IPv6) registros para la interfaz interna de cada servidor proxy inverso de la red perimetral (que es opcional para la administración de un proxy inverso).
DNS A y AAAA (si usa el direccionamiento IPv6) y registros SRV para la configuración automática del cliente de Skype Empresarial Server interna (que es opcional).
DNS A y AAAA (si usa direcciones IPv6) o registros CNAME para la detección automática de Skype Empresarial Server Servicios Web (que es opcional).
Todas las interfaces perimetrales internas de Skype Empresarial Server de la red perimetral usan esta zona DNS interna para resolver consultas a contoso.com.
Todos los servidores que ejecutan Skype Empresarial Server y los clientes que ejecutan Skype Empresarial Server en la red corporativa, apuntan a servidores DNS internos para resolver consultas a contoso.com o usan el archivo Host en cada servidor perimetral y muestran los registros A y AAAA (si usa el direccionamiento IPv6) para el servidor del próximo salto (específicamente para el director o grupo de directores VIP, front-end pool VIP o servidor Standard Edition).
DNS externo
Contiene una zona DNS llamada (por ejemplo) contoso.com, para la que es relevante.
Esta contoso.com externa contiene:
DNS A y AAAA (si usa el direccionamiento IPv6), o registros CNAME, para la detección automática de Skype Empresarial Server servicios web. Es para usar con movilidad.
DNS A y AAAA (si usa direcciones IPv6) y registros SRV para la interfaz externa perimetral de cada Skype Empresarial Server VIP de carga equilibrada de hardware o servidor perimetral (HLB) en la red perimetral.
DNS A y AAAA (si usa direcciones IPv6) y registros SRV para la interfaz externa del servidor proxy inverso o (VIP para un grupo de servidores proxy inversos), en la red perimetral.
DNS A y AAAA (si usa direcciones IPv6) y registros SRV para Skype Empresarial Server configuración automática del cliente ( opcional ).
Configuración automática sin DNS de horizonte dividido
Si no usa DNS de cerebro dividido, la configuración automática interna de los clientes que ejecutan Skype Empresarial no funcionará a menos que esté usando una de las soluciones alternativas que tenemos aquí. ¿Por qué no? Porque Skype Empresarial Server requiere que el URI de SIP del usuario coincida con el dominio del grupo de servidores front-end designado para la configuración automática. Esto no ha cambiado de las versiones anteriores de Lync Server.
Por lo tanto, si tiene dos dominios SIP en uso, necesitará estos registros SRV de DNS:
_sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com
Si un usuario inicia sesión como bob@contoso.com, este registro funcionará para la configuración automática, ya que el dominio SIP del usuario coincide con el dominio del grupo de servidores front-end (contoso.com).
_sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Si un usuario inicia sesión como alice@fabrikam.com, este registro funcionará para la configuración automática del segundo dominio, de nuevo porque el dominio SIP coincide con el grupo de servidores front-end de ese dominio.
Para llevar el ejemplo más allá, esto no funcionaría:
_sipinternaltls._tcp.litwareinc.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com
Un usuario que inicie sesión como tim@litwareinc.com no funcionará para la configuración automática, porque su dominio SIP (litwareinc.com) no coincide con el dominio del grupo (fabrikam.com).
Ahora que sabemos todo eso, si necesita requisitos automáticos para sus clientes de Skype Empresarial sin DNS de cerebro dividido, tiene estas opciones:
Objetos de directiva de grupo
Puede usar objetos de directiva de grupo (GPO) para rellenar los valores de servidor correctos.
Nota
Esta opción no habilita la configuración automática, pero automatiza la configuración manual. Si se usa este enfoque, los registros SRV asociados con la configuración automática no son obligatorios.
Correspondencia de zona interna
Tendrá que crear una zona en su DNS interno que coincida con su zona DNS externa (por ejemplo, contoso.com) y, a continuación, crear registros DNS A (y AAAA si usa el direccionamiento IPv6) que se correspondan con el grupo de Skype Empresarial Server utilizado para la configuración automática.
Por ejemplo, si tiene un usuario alojado en pool01.contoso.net, pero inicia sesión en Skype Empresarial como bob@contoso.com, cree una zona DNS interna denominada contoso.com y, dentro de ella, debe crear un registro A (y AAAA de DNS si se usa la dirección IPv6) para pool01.contoso.com.
Zona interna de punto de anclaje
Si crear una zona entera en el DNS interno no es una opción, puede crear zonas de punto de anclaje (dedicadas) que se correspondan con los registros SRV necesarios para la configuración automática y rellenar esas zonas con dnscmd.exe. Dnscmd.exe es obligatorio porque la interfaz de usuario de DNS no admite la creación de zonas de punto de anclaje.
Por ejemplo, si su dominio SIP está contoso.com y tiene un grupo de servidores front-end denominado pool01 que contiene dos servidores front-end, necesitará las siguientes zonas de puntos pin y registros A en su DNS interno:
dnscmd . /zoneadd _sipinternaltls._tcp.contoso.com. /dsprimary dnscmd . /recordadd _sipinternaltls._tcp.contoso.com. @ SRV 0 0 5061 pool01.contoso.com. dnscmd . /zoneadd pool01.contoso.com. /dsprimary dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.90 dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address> dnscmd . /recordadd pool01.contoso.com. @ A 192.168.10.91 dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>Puede que tenga un segundo dominio SIP en su entorno. En ese caso, necesitará los siguientes registros A y zonas de punto de anclaje en el DNS interno:
dnscmd . /zoneadd _sipinternaltls._tcp.fabrikam.com. /dsprimary dnscmd . /recordadd _sipinternaltls._tcp.fabrikam.com. @ SRV 0 0 5061 pool01.fabrikam.com. dnscmd . /zoneadd pool01.fabrikam.com. /dsprimary dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.90 dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address> dnscmd . /recordadd pool01.fabrikam.com. @ A 192.168.10.91 dnscmd . /recordadd pool01.contoso.com. @ AAAA <IPv6 address>
Nota
Verá que el FQDN del grupo de servidores front-end aparece dos veces, pero con dos direcciones IP diferentes. Esto se debe a que se usa el equilibrio de carga de DNS. Si se usa HLB, solo habría una única entrada del grupo de servidores front-end.
Nota
Además, los valores fqdn del grupo de servidores front-end cambian entre los ejemplos de contoso.com y fabrikam.com, pero las direcciones IP siguen siendo las mismas. Esto se debe a que los usuarios que inicien sesión desde cualquiera de los dominios SIP usarán el mismo grupo de servidores front-end para la configuración automática.
Recuperación ante desastres de DNS
Para configurar dns para redirigir Skype Empresarial Server tráfico web a los sitios de recuperación ante desastres (DR) y conmutación por error, debe usar un proveedor de DNS compatible con GeoDNS. Puede configurar los registros DNS para que admitan la recuperación ante desastres, de modo que las características que usan servicios web continúen incluso si un grupo front-end completo desaparece. Esta característica de recuperación ante desastres admite las direcciones URL sencillas de detección automática, reunión y acceso telefónico local.
Puede definir y configurar registros A de host de DNS adicionales (AAAA si usa IPv6) para la resolución interna y externa de servicios web en su proveedor de GeoDNS. La siguiente información asume grupos emparejados, dispersos geográficamente y que el GeoDNS que admite su proveedor tanto tiene DNS round robin como está configurado para usar Pool1 como principal y conmutar por error a Pool2 en caso de cualquier pérdida de comunicación o error de alimentación.
Todos los registros DNS en esta tabla son ejemplos.
| Registro de GeoDNS | Registros del grupo | CNAME records | Configuración de DNS (seleccione una opción) |
|---|---|---|---|
| Meet-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Meet.contoso.com a Pool1InternalWebFQDN.contoso.com Alias Meet.contoso.com a Pool2InternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
| Meet-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Meet.contoso.com a Pool1ExternalWebFQDN.contoso.com Alias Meet.contoso.com a Pool2ExternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
| Dialin-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Dialin.contoso.com a Pool1InternalWebFQDN.contoso.com Alias Dialin.contoso.com a Pool2InternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
| Dialin-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Dialin.contoso.com a Pool1ExternalWebFQDN.contoso.com Alias Dialin.contoso.com a Pool2ExternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
| Lyncdiscoverint-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Lyncdiscoverinternal.contoso.com a Pool1InternalWebFQDN.contoso.com Alias Lyncdiscoverinternal.contoso.com a Pool2InternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
| Lyncdiscover-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Lyncdiscover.contoso.com a Pool1ExternalWebFQDN.contoso.com Alias Lyncdiscover.contoso.com a Pool2ExternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
| Scheduler-int.geolb.contoso.com |
Pool1InternalWebFQDN.contoso.com Pool2InternalWebFQDN.contoso.com |
Alias Scheduler.contoso.com a Pool1InternalWebFQDN.contoso.com Alias Scheduler.contoso.com a Pool2InternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
| Scheduler-ext.geolb.contoso.com |
Pool1ExternalWebFQDN.contoso.com Pool2ExternalWebFQDN.contoso.com |
Alias Scheduler.contoso.com a Pool1ExternalWebFQDN.contoso.com Alias Scheduler.contoso.com a Pool2ExternalWebFQDN.contoso.com |
Round robin entre grupos O bien Usa el primario, se conecta al secundario en caso de error |
Equilibrio de carga de DNS
El equilibrio de carga de DNS suele implementarse en el nivel de la aplicación. La aplicación (por ejemplo, un cliente que ejecuta Skype Empresarial), intenta conectarse a un servidor de un grupo mediante la conexión a una de las direcciones IP devueltas de la consulta de registro DNS A y AAAA (si se usa la dirección IPv6) para el FQDN del grupo.
Por ejemplo, si hay tres servidores front-end en un grupo denominado pool01.contoso.com, ocurriría lo siguiente:
Clientes que ejecutan Skype Empresarial DNS de consulta para pool01.contoso.com. La consulta devuelve tres direcciones IP y las copia en caché tal como se muestra a continuación (en algún orden):
pool01.contoso.com 192.168.10.90 pool01.contoso.com 192.168.10.91 pool01.contoso.com 192.168.10.92 El cliente intenta establecer una conexión TCP con una de las direcciones IP. Si se genera un error, lo intentará con la siguiente dirección IP copiada en caché de esa lista.
Si la conexión TCP se establece correctamente, el cliente negocia con el TLS para conectarse con el registrador principal en pool01.contoso.com.
Si el cliente prueba todas las entradas almacenadas en caché sin una conexión correcta, el usuario recibirá una notificación de que no hay servidores que ejecuten Skype Empresarial Server estén disponibles en este momento.
Nota
El equilibrio de carga basado en DNS es distinto al round robin de DNS (DNS RR), que normalmente hace referencia al equilibrio de carga usando el DNS para darle un orden distinto de direcciones IP para los servidores del grupo de servidores. Por lo general, DNS RR habilita la distribución de carga, pero no le permitirá habilitar la conmutación por error. Por ejemplo, si la conexión con la dirección IP devuelta por la consulta de DNS A (o AAAA en un escenario IPv6) provoca un error, esa conexión dará error. Esto hace que el DNS RR sea menos fiable que el equilibrio de carga basado en DNS. Todavía puede usar el DNS RR en combinación con el equilibrio de carga basado en DNS si lo necesita.
Usa el equilibrio de carga de DNS para:
Equilibrio de carga sip de servidor a servidor en los servidores perimetrales.
Equilibrar la carga de aplicaciones de servicios de aplicaciones de comunicaciones unificadas (UCAS) como Operador automático de conferencia, Grupo de respuesta y Estacionamiento de llamadas.
Impedir el establecimiento de nuevas conexiones con aplicaciones UCAS (también conocido como purga).
Equilibrio de carga todo el tráfico de cliente a servidor entre clientes y servidores perimetrales.
No puede usar el equilibrio de carga de DNS para:
- Tráfico web de cliente a servidor a los servidores front-end o a un director.
Para ir un poco más detallado sobre cómo se selecciona un registro SRV de DNS cuando una consulta devuelve varios registros DNS, el servicio perimetral de acceso siempre selecciona el registro con la prioridad numérica más baja y, si se necesita un desempate, el peso numérico más alto. Esto es coherente con la documentación del grupo de tareas de ingeniería de Internet.
Por tanto, por ejemplo, si el primer registro SRV de DNS tiene un peso de 20 y una prioridad de 40 y el segundo registro SRV de DNS tiene un peso de 10 y una prioridad de 50, se elegirá el primer registro porque tiene la prioridad más baja, 40. La prioridad siempre va primero y es el host que un cliente elegirá primero. ¿Qué ocurre si hay dos destinos con la misma prioridad?
En ese caso, el peso entra en consideración. Un mayor peso tendrá una probabilidad alta, en esta circunstancia, de ser seleccionado. Los administradores de DNS deben usar peso 0 cuando no hay ninguna selección de servidor. En la presencia de registros con peso mayor que 0, los registros con peso 0 tienen una probabilidad muy pequeña de ser seleccionados.
Por lo tanto, ¿qué sucede si se devuelven varios registros SRV de DNS con la misma prioridad y el mismo peso? En esta situación, el servicio perimetral de acceso elegirá primero el registro SRV que obtuvo del servidor DNS.