DNS del servidor de borde planificación avanzada para Skype para Business Server 2015

 

**Última modificación del tema:**2018-02-15

Resumen: revise escenarios para las opciones de implementación de Skype Empresarial Server 2015. Tanto si desea un único servidor como si prefiere un grupo de servidores con DNS o HLB, este tema puede ayudarle.

Cuando se trata de planificar el Sistema de nombres de dominio (DNS) de Skype Empresarial Server 2015, hay una gran cantidad de factores que pueden desempeñar un papel 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

  • Split-brain DNS

  • Automatic configuration without split-brain DNS

  • DNS disaster recovery

  • DNS load balancing

Walkthrough of Skype for Business clients locating services

Los clientes de Skype Empresarial son similares a las versiones anteriores de clientes de Lync en la manera en la que buscan y obtienen acceso a servicios en Skype Empresarial Server 2015. Esta sección contiene información sobre el proceso de ubicación del servidor.

  1. lyncdiscoverinternal.<dominio>

    Es un registro de host A para el servicio Detección automática en los servicios web internos.

  2. lyncdiscover.<dominio>

    Es un registro de host A para el servicio Detección automática en los servicios web externos.

  3. _sipinternaltls._tcp.<dominio>

    Es un registro SRV para las conexiones TLS internas.

  4. _sip._tls.<dominio>

    Es un registro SRV para las conexiones TLS externas.

  5. sipinternal.<dominio>

    This is an A host record for the Grupo de servidores front-end or Director, resolvable only on the internal network.

  6. sip.<dominio>

    This is an A host record for the Grupo de servidores front-end or Director, resolvable only on the internal network.

  7. sipexternal.<dominio>

    This is an A host record for the Servidor perimetral de acceso, when the client is external.

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 está dispuesto a hacerlo, 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 usar la detección automática en contraposición con la detección manual, pero si está solucionando problemas o realizando alguna prueba, la configuración manual puede ser muy ú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.

Esto presenta algunos desafíos. El más importante es que DNS de horizonte 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).

Enumeraremos aquí los registros DNS para las zonas internas y externas, pero puede encontrar ejemplos detallados en la sección de requisitos del entorno 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 A y AAAA (si está usando el direccionamiento IPv6) de DNS para el nombre del Grupo de servidores front-end, del Grupo de directores o del Grupo de directores y todos los servidores internos que ejecutan Skype Empresarial Server 2015 en la red de su organización.

    • Registros A y AAAA (si está usando el direccionamiento IPv6) de DNS para su Interfaz interna perimetral para cada Servidor perimetral de Skype Empresarial Server 2015 en su red perimetral.

    • Registros A y AAAA (si está usando el direccionamiento IPv6) de DNS para la interfaz interna de cada servidor de proxy inverso de la red perimetral (que es opcional en la administración de un proxy inverso).

    • Registros A y AAAA (si está usando el direccionamiento IPv6) de DNS y registros SRV para la configuración automática del cliente Skype Empresarial Server 2015 interno (que es opcional ).

    • Registros A y AAAA (si está usando direccionamiento IPv6) de DNS o registros CNAME para la detección automática de servicios web de Skype Empresarial Server 2015 (que es opcional ).

  • Todos los Interfaces perimetrales internos de Skype Empresarial Server 2015 en la red perimetral usan esta zona DNS interna para resolver consultas a contoso.com.

  • Todos los servidores que ejecutan Skype Empresarial Server 2015 y los clientes que ejecutan Skype Empresarial Server 2015 en la red corporativa apuntan a servidores DNS internos para resolver consultas a contoso.com, o usan el archivo del host en cada Servidor perimetral y enumeran registros A y AAAA (si está usando el direccionamiento IPv6) para el servidor del próximo salto (específicamente para el Director o Grupo de directores VIP, Grupo de servidores front-end 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:

    • Registros A y AAAA (si está usando direccionamiento IPv6) de DNS o registros CNAME para la detección automática de servicios web de Skype Empresarial Server 2015. Es para usar con movilidad.

    • Registros A y AAAA (si está usando el direccionamiento IPv6) de DNS y registros SRV de la Interfaz externa perimetral de cada Servidor perimetral de Skype Empresarial Server 2015 o con equilibrio de carga de hardware (HLB) VIP en el red perimetral.

    • Registros A y AAAA (si está usando el direccionamiento IPv6) de DNS y registros SRV para la interfaz externa del servidor de Proxy inverso o (VIP para un grupo de servidores de Proxy inverso), en el red perimetral.

    • Registros A y AAAA (si está usando el direccionamiento IPv6) de DNS y registros SRV para la configuración automática del cliente Skype Empresarial Server 2015 ( opcional ).

Configuración automática sin DNS de horizonte dividido

Si no usa DNS de horizonte dividido, la configuración automática interna de los clientes que ejecutan Skype Empresarial no funcionará a menos que use una de las soluciones alternativas que le mostramos aquí. ¿Por qué no? Porque Skype Empresarial Server 2015 requiere que el URI del SIP del usuario coincida con el dominio del Grupo de servidores front-end designado para la configuración automática. Esta no ha cambiado de 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

    If a user signs in as bob@contoso.com, this record would work for automatic configuration, as the user's SIP domain matches the domain of the Grupo de servidores front-end (contoso.com).

  • _sipinternaltls._tcp.fabrikam.com. 86400 IN SRV 0 0 5061 pool01.fabrikam.com

    If a user signs in as alice@fabrikam.com, this record would work for automatic configuration of the second domain, again because the SIP domain matches the Grupo de servidores front-end for that domain.

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 iniciando 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 esto, si necesita requisitos automáticos para los clientes de Skype Empresarial sin DNS de horizonte 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 el DNS interno que coincida con la zona DNS externa (por ejemplo, contoso.com) y después crear registros A y AAAA (si está usando el direccionamiento IPv6) de DNS que se correspondan con el grupo de servidores de Skype Empresarial Server 2015 usado 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 llamada contoso.com y dentro de ella tiene que crear un registro A (y AAAA si usa el direccionamiento IPv6) de DNS 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 es contoso.com y tiene un Grupo de servidores front-end denominado pool01 que contiene dos Servidores front-end, necesitará los siguientes registros A y zonas de punto de anclaje en el 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.
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 son iguales. Esto se debe a que los usuarios que inician 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 que redirija el tráfico web de Skype Empresarial Server 2015 a los sitios de recuperación ante desastres (DR) y conmutación por error, tiene que usar un proveedor de DNS que admita GeoDNS. Puede configurar los registros DNS para admitir la recuperación ante desastres, de modo que las características que usan servicios web continúen incluso si un Grupo de servidores front-end deja de funcionar completamente. Esta característica de DR es compatible con la detección automática, las reuniones y las direcciones URL sencillas de 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 en un grupo de servidores conectándose a una de las direcciones IP obtenidas a raíz de la consulta del registro A y AAAA (si se usa el direccionamiento IPv6) de DNS para el FQDN del grupo de servidores.

Por ejemplo, si hay tres Servidores front-end en un grupo de servidores denominado pool01.contoso.com, pasará lo siguiente:

  • Los clientes que ejecutan Skype Empresarial consultan el DNS 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 intenta todas las entradas copiadas en caché sin establecer una conexión correctamente, el usuario recibe una notificación de que en ese momento no hay disponible ningún servidor que ejecute Skype Empresarial Server 2015.

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:

  • Equilibrar la carga de SIP de servidor a servidor con 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).

  • Equilibrar la carga de todo el tráfico de cliente a servidor entre los clientes y los Servidores perimetrales.

No puede usar el equilibrio de carga de DNS para:

  • Tráfico web de cliente a servidor para los Servidores front-end o un Director.

Para profundizar algo más sobre cómo se selecciona un registro SRV de DNS cuando una consulta devuelve varios registros de DNS, el Servidor perimetral de acceso siempre selecciona el registro con la prioridad numérica más baja y, de ser necesario un factor de desempate, el peso numérico más alto. Esto es coherente con la documentación de Internet Engineering Task Force.

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 Servidor perimetral de acceso elegirá el registro SRV que obtuvo del servidor DNS en primer lugar.