Requisitos de DNS para Skype Empresarial Server

Skype for Business Server 2015
 

Última modificación del tema:2016-12-20

Resumen: revise las consideraciones de DNS en este tema antes de implementar Skype Empresarial Server 2015.

Para implementar Skype Empresarial Server, tiene que crear registros del Sistema de nombres de dominio (DNS) que permitan la detección de clientes y servidores y, opcionalmente, si la organización así lo desea, la compatibilidad con el inicio de sesión automático de los clientes.

Skype Empresarial Server usa el DNS de las siguientes maneras:

  • Para detectar los servidores o grupos de servidores internos para las comunicaciones de servidor a servidor.

  • Para permitir a los clientes detectar el Grupo de servidores front-end o el Servidor Standard Edition que se usa para diversas transacciones SIP.

  • Para permitir que los dispositivos de comunicaciones unificadas (UC) que no se hayan registrado detecten el Grupo de servidores front-end o el Servidor Standard Edition que ejecuta el Servicio web de actualización de dispositivos, obtengan las actualizaciones y envíen los registros.

  • Para permitir a los clientes y a los servidores externos conectarse a los Servidores perimetrales o al proxy inverso HTTP para la mensajería instantánea (MI) o las conferencias.

  • Para permitir que los dispositivos externos de comunicaciones unificadas se conecten al Servicio web de actualización de dispositivos a través de los Servidores perimetrales o del proxy inverso HTTP, y obtengan actualizaciones.

  • Para permitir que los clientes móviles detecten automáticamente recursos de servicios web sin que los usuarios tengan que escribir manualmente las direcciones URL en la configuración del dispositivo.

Use el diagrama de flujo siguiente para determinar los requisitos del Sistema de nombres de dominio (DNS).

importantImportante:
Skype Empresarial Server admite el uso del direccionamiento IPv6. Para usar direcciones IPv6, también necesita proporcionar compatibilidad para DNS IPv6 y configurar registros AAAA de host DNS (conocidos como “cuádruple A”). En implementaciones en las que se están usando IPv4 e IPv6, es mejor configurar y mantener registros A de host para IPv4 y AAAA de host para IPv6. Aunque su implementación haya realizado una transición completa a IPv6, los registros de host DNS IPv4 todavía pueden ser necesarios cuando los usuarios externos estén usando todavía IPv4.

Diagrama de flujo para determinar los requisitos de DNS

Diagrama de flujo de DNS - menos cerebro dividido
importantImportante:
De manera predeterminada, el nombre de equipo de un equipo que no está unido a un dominio es un nombre de host, en lugar de un nombre de dominio completo (FQDN). El Generador de topologías utiliza nombres de dominio completos, en vez de nombres de host. Así pues, necesita configurar un sufijo de DNS en el nombre del equipo para poder implementarlo como servidor perimetral no incorporado a un dominio. Utilice únicamente caracteres estándares (como A–Z, a–z, 0–9 y guiones) cuando asigne los FQDN a sus servidores con Skype Empresarial Server en ejecución. No utilice caracteres Unicode ni guiones bajos. Por lo general, los DNS externos y las entidades de certificación (CA) públicas no admiten caracteres que no sean estándares en un FQDN (es decir, cuando el FQDN se necesita asignar al nombre de sujeto en el certificado). Para más información, consulte Configurar registros de host DNS para Lync Server 2013.

Skype Empresarial y Lync 2013 son similares en el modo en que el cliente encuentra y obtiene acceso a los servicios de Skype Empresarial Server. La excepción más destacada es la Aplicación de la Tienda Windows de Lync, que usa un proceso de ubicación del servicio distinto. En esta sección se describen dos escenarios en los que los clientes localizan servicios: el primero es el método tradicional que usa una serie de SRV y registros de host A y el segundo usa únicamente los registros del servicio de detección automática. Para todos los clientes, el proceso de consulta de DNS continúa hasta que se devuelve una consulta con éxito o hasta que se agota la lista de posibles registros de DNS y se devuelve un error final al cliente.

Para todos los clientes, excepto para la Aplicación de la Tienda Windows de Lync, durante la búsqueda de DNS, los registros SRV se consultan y se devuelven al cliente en el orden siguiente:

  1. lyncdiscoverinternal. <domain> Registro A (host) para el servicio de detección automática en los servicios web internos

  2. lyncdiscoverinternal. <domain> Registro A (host) para el servicio de detección automática en los servicios web externos

  3. _sipinternaltls._tcp. <domain> Registro SRV (localizador de servicios) para conexiones TLS internas

  4. _sipinternal._tcp. <domain> Registro SRV (localizador de servicios) para conexiones TCP internas (solo si se permite TCP)

  5. _sip._tls. <domain> Registro SRV (localizador de servicios) para conexiones TLS externas

  6. sipinternal. <domain> Registro A (host) para el Grupo de servidores front-end o el Director, que se puede resolver solo en la red interna

  7. sip. <domain> Registro A (host) para el Grupo de servidores front-end o el Director en la red interna, o el Servidor perimetral de acceso cuando el cliente es externo

  8. sipexternal. <domain> Registro A (host) para el Servidor perimetral de acceso cuando el cliente es externo

La Aplicación de la Tienda Windows de Lync cambia el proceso completamente porque usa dos registros:

  1. lyncdiscoverinternal. <domain> Registro A (host) para el servicio de detección automática en los servicios web internos

  2. lyncdiscoverinternal. <domain> Registro A (host) para el servicio de detección automática en los servicios web externos

No hay reserva para los otros tipos de registros.

La diferencia entre los métodos usados para los clientes más recientes en comparación con los clientes más antiguos es que el servicio de detección automática se convierte en el método preferido para localizar todos los servicios.

Cuando una conexión es correcta, el servicio de detección automática devuelve todas las direcciones URL de los servicios web del grupo de servidores principales del usuario, incluidas las direcciones URL del servicio de movilidad (conocido como Mcx por el directorio virtual creado por el servicio en IIS), de Microsoft Lync Web App y del programador web. Pero, la dirección URL interna del servicio de movilidad y la dirección URL externa del servicio de movilidad se asocian al FQDN externo de los servicios web. Por lo tanto, independientemente de si un dispositivo móvil es interno o externo a la red, el dispositivo siempre se conecta al servicio de movilidad de forma externa a través del proxy inverso.

El servicio de detección automática también devuelve referencias a Internos/UCWA, Externos/UCWA y UCWA. Estas entradas hacen referencia al componente web de la API web de comunicaciones unificadas (UCWA). Actualmente solo se usa la entrada de UCWA y proporciona una referencia a una URL para el componente web. Los clientes móviles de Skype Empresarial utilizan UCWA, en vez del servicio de movilidad Mcx que utilizan los clientes de Lync 2010 Mobile.

noteNota:
A la hora de crear registros SRV, es importante recordar que necesitan señalar a un registro A y AAAA (si está usando direccionamiento IPv6) de DNS del mismo dominio donde se crea el registro SRV de DNS. Por ejemplo, si el registro SRV se encuentra en contoso.com, el registro A y AAAA (si se está usando direccionamiento IPv6) al que señala no pueden encontrarse en fabrikam.com.
tipSugerencia:
La configuración predeterminada dirige todo el tráfico de clientes móviles a través del sitio externo. Puede cambiar la configuración para devolver solamente la dirección URL interna, si esto se adapta más a sus requisitos. Con esta configuración, los usuarios pueden usar aplicaciones móviles de Skype Empresarial en sus dispositivos móviles solo cuando están dentro de la red corporativa. Para definir esta configuración, use el cmdlet Set-CsMcxConfiguration .
noteNota:
Aunque las aplicaciones móviles también pueden conectarse a otros servicios de Skype Empresarial Server, como el servicio de la libreta de direcciones, las solicitudes web de aplicaciones móviles internas se dirigen al FQDN web externo solamente para el servicio de movilidad. Otras solicitudes de servicios, como las solicitudes de la libreta de direcciones, no requieren esta configuración.

Los dispositivos móviles admiten la detección manual de servicios. En este caso, cada usuario necesita configurar los parámetros del dispositivo móvil con los URI internos y externos completos del servicio de detección automática, incluso el protocolo y la ruta de acceso, de la manera siguiente:

  • https:// <ExtPoolFQDN> /Autodiscover/autodiscoverservice.svc/Root para el acceso externo

  • https:// <IntPoolFQDN> /AutoDiscover/AutoDiscover.svc/Root para el acceso interno

Recomendamos que use la detección automática, en lugar de la detección manual. Pero, la configuración manual puede ser útil para solucionar problemas de conectividad de los dispositivos móviles.

El término DNS de horizonte dividido se conoce con varios nombres, por ejemplo, DNS dividido o DNS de partición de red. Sencillamente describe una configuración de DNS en la que existen dos zonas de DNS con el mismo espacio de nombre, pero una zona de DNS procesa solo las solicitudes internas y la otra solo las externas. Pero, muchos de los registros SRV y los registros A de DNS que contiene el DNS interno no se incluirán en el DNS externo, y viceversa. Además, en los casos en que el mismo registro de DNS existe tanto en el DNS interno como en el externo (por ejemplo, www.contoso.com), la dirección IP devuelta será distinta, en función de dónde (en el interior o en el exterior) se realice la consulta de DNS.

importantImportante:
Actualmente, el DNS de horizonte dividido no es compatible con la movilidad o, más concretamente, con los registros de DNS LyncDiscover y LyncDiscoverInternal. LyncDiscover tiene que definirse en un servidor DNS externo y LyncDiscoverInternal tiene que definirse en un servidor DNS interno.

Aquí se utilizará el término DNS de horizonte dividido.

Si va a configurar DNS de horizonte dividido, en la siguiente área interna y externa encontrará un resumen de los tipos de registros de DNS necesarios para cada zona. Para más información, consulte Escenarios para el acceso de usuarios externos en Lync Server 2013.

DNS interno:

  • Contiene una zona de DNS llamada contoso.com sobre la que es autoritativo

  • La zona contoso.com interna contiene:

    • Registros SRV, AAAA (si está usando direccionamiento IPv6) y A de DNS para la configuración automática interna de clientes de Skype Empresarial Server (opcional)

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

    • Registros A y AAAA (si está usando direccionamiento IPv6) de DNS para el nombre del grupo de servidores front-end, el nombre del grupo de director o el director y todos los servidores internos que ejecutan Skype Empresarial Server en la red corporativa

    • Registros A y AAAA (si está usando direccionamiento IPv6) de DNS para la interfaz interna perimetral de cada servidor perimetral de Skype Empresarial Server en la red perimetral

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

    • Todas las interfaces perimetrales internas del Servidor perimetral de Skype Empresarial Server en la red perimetral utilizan la zona de DNS interna para la resolución de consultas de contoso.com

    • Todos los servidores que ejecutan Skype Empresarial Server y los clientes que ejecutan Skype Empresarial en la red corporativa apuntan a los servidores DNS internos para la resolución de consultas de contoso.com, o utilizan un archivo de HOST en cada registro de la lista A y AAAA (si está usando direccionamiento IPv6) y del servidor perimetral para el servidor del próximo salto, especialmente el director, el VIP del director, el VIP del grupo de servidores front-end o el servidor Standard Edition

DNS externo:

  • Contiene una zona de DNS llamada contoso.com sobre la que es autoritativo

  • La zona contoso.com externa contiene:

    • Registros SRV, A y AAAA (si está usando direccionamiento IPv6) de DNS para la configuración automática de clientes de Skype Empresarial Server (opcional)

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

    • Registros SRV, A y AAAA (si está usando direccionamiento IPv6) de DNS para la interfaz externa perimetral de cada dirección IP virtual (VIP) de Skype Empresarial Server, del servidor perimetral o del equilibrador de carga de hardware en la red perimetral

    • Registros A y AAAA (si está usando direccionamiento IPv6) de DNS para la interfaz externa del servidor proxy inverso o VIP para un grupo de servidores proxy inversos en la red perimetral

Si usa DNS de horizonte dividido, un usuario de Skype Empresarial Server que inicia sesión de forma interna puede aprovechar la configuración automática, siempre que la zona de DNS interna contenga un registro SRV _sipinternaltls._tcp para cada dominio SIP en uso. De lo contrario, 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 se implemente una de las soluciones alternativas descritas más adelante en esta sección. Esto es 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. Lo mismo sucedía en versiones anteriores de Communicator.

Por ejemplo, si tiene dos dominios SIP en uso, se necesitarán los registros de servicio DNS (SRV) siguientes:

  • Si un usuario inicia sesión como bob@contoso.com, el registro SRV siguiente funcionará para la configuración automática porque el dominio SIP del usuario (contoso.com) coincide con el dominio del grupo de servidores front-end de configuración automática:

    _sipinternaltls._tcp.contoso.com. 86400 IN SRV 0 0 5061 pool01.contoso.com

  • Si un usuario inicia sesión como alice@fabrikam.com, el siguiente registro SRV de DNS funcionará para la configuración automática del segundo dominio SIP.

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

En cambio, si un usuario inicia sesión como tim@litwareinc.com, el siguiente registro SRV de DNS no funcionará para la configuración automática, porque el dominio SIP del cliente (litwareinc.com) no coincide con el dominio donde se encuentra el grupo de servidores (fabrikam.com):

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

Si es necesaria la configuración automática para clientes que ejecutan Skype Empresarial, seleccione una de las opciones siguientes:

  • Objetos de directiva de grupo Use los objetos de directiva de grupo (GPO) para rellenar los valores del servidor correctos.

    noteNota:
    Esta opción no habilita la configuración automática, pero automatiza el proceso de configuración manual, de modo que si se usa este enfoque, no se requerirán los registros SRV asociados con la configuración automática.
  • Zona interna coincidente Cree una zona en el DNS interno que coincida con la zona de DNS externa (por ejemplo, contoso.com) y cree registros A y AAAA (si está usando direccionamiento IPv6) de DNS que se correspondan con el grupo de Skype Empresarial Server usado para la configuración automática. Por ejemplo, si un usuario está hospedado en pool01.contoso.net, pero inicia sesión en Skype Empresarial como bob@contoso.com, cree una zona de DNS interna llamada contoso.com y dentro de ella, cree un registro A y AAAA (si está usando direccionamiento IPv6) de DNS para pool01.contoso.com.

  • Zona interna designada Si crear una zona entera en el DNS interno no es una opción, puede crear zonas designadas (es decir, dedicadas) que correspondan a los registros SRV que son necesarios para la configuración automática y rellene dichas zonas con dnscmd.exe. Dnscmd.exe es necesario porque la interfaz de usuario de DNS no admite la creación de zonas designadas. Por ejemplo, si el dominio SIP es contoso.com y dispone de un grupo de servidores front-end llamado pool01 que contiene dos servidores front-end, necesitará los siguientes registros A y las siguientes zonas designadas 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>
    

    Si su entorno contiene un segundo dominio SIP (por ejemplo, fabrikam.com), necesitará los siguientes registros A y las siguientes zonas designadas 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>
    
noteNota:
El FQDN del grupo de servidores front-end aparece dos veces, pero con dos direcciones IP distintas. Esto es porque que se usa el equilibrio de carga de DNS, pero si se usara el equilibrio de carga de hardware, solo habría una única entrada de grupo de servidores front-end. Asimismo, los valores de FQDN del grupo de servidores front-end cambian entre el ejemplo de contoso.com y el ejemplo de fabrikam.com, pero las direcciones IP permanecen iguales. Esto es porque los usuarios que inician sesión desde cualquiera de los dominios SIP usan el mismo grupo de servidores front-end para la configuración automática.

Para obtener más información, consulte el artículo de blog DMTF, "Communicator automática configuración y Split-Brain DNS", en https://go.microsoft.com/fwlink/p/?linkId=200707. A pesar de que este artículo se refiere a Office Communicator, los detalles se aplican por igual a Skype Empresarial Server.

noteNota:
El contenido de los blogs y sus URL están sujetos a cambios sin previo aviso.

Para configurar el DNS para redirigir el tráfico web de Skype Empresarial Server a los sitios de recuperación ante desastres y de conmutación por error, necesita usar un proveedor de DNS que admita el uso de GeoDNS para que se resuelva, en lo posible, en un servidor con proximidad geográfica, o en uno lejano si es necesario. Puede configurar los registros de DNS para la web a fin de admitir la recuperación ante desastres y, de esta manera, que las características que usan los servicios web continúen aunque un Grupo de servidores front-end completo deje de estar disponible. Esta característica de recuperación ante desastres admite direcciones URL sencillas de detección automática (URL de Lyncdiscover), de reunión y de acceso telefónico.

Los registros de host DNS adicionales (A y AAAA si se usa IPv6) se definen y se configuran para la resolución interna y externa de servicios web en su proveedor de GeoDNS. En la información siguiente se presupone que su proveedor admite grupos emparejados, geográficamente dispersos, y GeoDNS con round robin de DNS o configurados para usar Pool1 como grupo principal y conmutar por error a Pool2 en caso de pérdida de comunicaciones o error de hardware.

 

Registro de GeoDNS (ejemplo) Registros del grupo (ejemplo) Registros CNAME (ejemplo) 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

Usa el principal; 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

Usa el principal; 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

Usa el principal; 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

Usa el principal; 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

Usa el principal; 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

Usa el principal; 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

Usa el principal; 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

Usa el principal; se conecta al secundario en caso de error

El equilibrio de carga de DNS suele implementarse en la aplicación. La aplicación (por ejemplo, un cliente que ejecuta Skype Empresarial), intenta conectarse a un servidor en un grupo 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 nombre de dominio completo (FQDN) del grupo.

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

  • Los clientes que ejecutan Skype Empresarial envían una consulta al DNS para pool01.contoso.com y esta obtendrá como resultado tres direcciones IP que almacenará en caché de la forma siguiente (no necesariamente en este orden):

    pool01.contoso.com 192.168.10.90

    pool01.contoso.com 192.168.10.91

    pool01.contoso.com 192.168.10.92

  • Luego, el cliente intenta establecer una conexión del Protocolo de control de transmisión (TCP) con una de las direcciones IP. Si no funciona, lo intenta con la siguiente dirección IP almacenada en caché.

  • 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 almacenadas en caché sin establecer una conexión correctamente, se notifica al usuario que en ese momento no hay disponible ningún servidor que ejecute Skype Empresarial Server.

noteNota:
El equilibrio de carga basado en DNS es distinto al round robin de DNS (RR de DNS), que normalmente hace referencia al equilibrio de carga usando el DNS para proporcionar un orden distinto de direcciones IP correspondientes a los servidores de un grupo de servidores. Por lo general, RR de DNS solo habilita la distribución de carga, pero no habilita la conmutación por error. Por ejemplo, si no se consigue establecer la conexión con una de las direcciones IP devueltas por la consulta A y AAAA (si está usando el direccionamiento IPv6) de DNS, la conexión será errónea. Por tanto, el round robin de DNS por sí solo es menos fiable que el equilibrio de carga basado en DNS. Puede usar el round robin de DNS junto con el equilibrio de carga de DNS.

El equilibrio de carga de DNS se usa para lo siguiente:

  • Equilibrar la carga 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 (proceso también conocido como "purga").

  • Equilibrar la carga de todo el tráfico desde el servidor al cliente entre clientes y servidores perimetrales

El equilibrio de carga de DNS no puede usarse para:

  • Tráfico web de cliente a servidor al director o a los servidores front-end

Equilibrio de carga de DNS y tráfico federado:

Si una consulta SRV de DNS devuelve varios registros de DNS, el servicio perimetral de acceso siempre selecciona el registro SRV de DNS con la prioridad numérica más baja y con el peso numérico más alto. El documento de Internet Engineering Task Force "A DNS RR for specifying the location of services (DNS SRV)" https://www.ietf.org/rfc/rfc2782.txt especifica que si hay varios SRV de DNS registros definidos, prioridad se utiliza en primer lugar, luego peso. Por ejemplo, el registro A de SRV de DNS tiene un peso de 20 y una prioridad de 40, y el registro B de SRV de DNS tiene un peso de 10 y una prioridad de 50. Se seleccionará el registro A de SRV de DNS con una prioridad de 40. Las siguientes reglas se aplican a la selección de registros SRV de DNS:

  • La prioridad se considera primero. Un cliente TIENE QUE intentar contactar con el host de destino definido por el registro SRV de DNS con la menor prioridad numerada que pueda alcanzar. Los destinos con la misma prioridad NECESITAN intentarse siguiendo el orden definido por el campo de peso.

  • El campo de peso especifica un peso relativo para las entradas que tienen la misma prioridad. Es PRECISO que a los pesos más grandes se les otorgue una probabilidad proporcionalmente mayor para ser seleccionados. Los administradores de DNS TIENEN QUE usar el peso 0 cuando no hay ninguna selección de servidor que hacer. Cuando existen registros con pesos superiores a 0, los registros con peso 0 necesitan tener una oportunidad muy pequeña de ser elegidos.

Si se devuelven varios registros SRV de DNS con la misma prioridad y el mismo peso, el servicio perimetral de acceso seleccionará el registro SRV que se haya obtenido en primer lugar del servidor DNS.

En esta sección se describen los registros del Sistema de nombres de dominio (DNS) necesarios para implementar grupos de servidores front-end.

La tabla siguiente especifica los requisitos de DNS para una implementación de un grupo de servidores front-end de Skype Empresarial Server.

Requisitos de DNS para un grupo de servidores front-end

Escenario de implementación Requisito de DNS

Grupo de servidores front-end con varios servidores front-end y un equilibrador de carga de hardware (independientemente de si el equilibrio de carga de DNS también está implementado en este grupo)

Al usar tanto el equilibrio de carga de DNS como un equilibrador de carga de hardware, se necesitan crear registros de host A. Cree un registro A interno para cada servidor front-end que se resuelva en el nombre de dominio completo (FQDN) del grupo de servidores front-end para el equilibrio de carga de DNS. Cree un registro de host A interno para los servicios web internos que apunte a la dirección IP virtual (VIP) del equilibrador de carga. Necesita usar el nombre de servicios web internos definido en el Generador de topologías.

Si, por ejemplo, usa tanto el equilibrio de carga de DNS como el equilibrio de carga de hardware, tendrá un registro A por cada Servidor front-end de un grupo para el equilibrio de carga de DNS, así como un registro A para los servicios web internos que apuntan a la IP virtual del equilibrador de carga de hardware:

  • Equilibrio de carga de DNS: Pool01.contoso.net Dirección IP del grupo 10.10.10.5

    warningAdvertencia:
    Cada Servidor front-end tendrá también un registro A distinto:
    1. FE01.contoso.net 10.10.10.1

    2. FE02.contoso.net 10.10.10.2

    3. FE03.contoso.net 10.10.10.3

    4. FE04.contoso.net 10.10.10.4

  • Equilibrio de carga de hardware: WebInternal.contoso.net Dirección IP de HLB VIP 192.168.10.5

Todo el tráfico, excepto el tráfico HTTP/HTTPS, usará el registro Pool01.contoso.net. El tráfico HTTP/HTTPS utilizará la dirección definida de los servicios web internos, 192.168.10.5.

Grupo de servidores front-end con equilibrio de carga de DNS implementado

Un conjunto de registros A internos que resuelven el FQDN del grupo para la dirección IP de cada uno de los servidores del grupo. Tiene que haber un registro A para cada servidor del grupo. Para más detalles, consulte Equilibrio de carga de DNS en Lync Server 2013 en la documentación de planeación.

   

Un grupo de servidores front-end con un solo servidor front-end y una base de datos back-end dedicada sin equilibrador de carga

Un registro A interno que resuelve el FQDN del grupo de servidores front-end para la dirección IP del único servidor front-end Enterprise Edition.

Inicio de sesión de clientes automático

Por cada dominio SIP admitido, un registro SRV para _sipinternaltls._tcp.<dominio> en el puerto 5061 que se asigna al FQDN del grupo de servidores front-end que autentica y redirige las solicitudes de los clientes para el inicio de sesión. Para más detalles, consulte Requisitos DNS para inicio de sesión automática del cliente en Lync Server 2013.

Detección del servicio web de actualización de dispositivos por los dispositivos de comunicaciones unificadas (UC)

Un registro A interno con el nombre ucupdates-r2.<dominio SIP> que se resuelve en la dirección IP del grupo de servidores front-end que hospeda el servicio web de actualización de dispositivos. En caso de que se active un dispositivo de UC en el que nunca ningún usuario inició sesión, el registro A permite al dispositivo detectar el grupo de servidores front-end que hospeda el servicio web de actualización de dispositivos y obtener actualizaciones. De lo contrario, los dispositivos obtienen esta información a través del aprovisionamiento en banda la primera vez que un usuario inicia sesión.

importantImportante:
Si cuenta con una implementación existente del servicio web de actualización de dispositivos en Lync Server 2010, ya habrá creado un registro A interno con el nombre ucupdates. <SIP domain> . Para Microsoft Office Communications Server 2007 R2, necesita crear otro registro A de DNS con el nombre ucupdates-r2. <SIP domain> .

Un proxy inverso compatible con el tráfico HTTP

Un registro A externo que resuelve el FQDN externo de la granja de servidores web en la dirección IP externa del proxy inverso. Los clientes y los dispositivos de UC usan este registro para conectarse al proxy inverso. Para más detalles, consulte Determinar los requisitos DNS para Lync Server 2013 en la documentación de planeación.

La tabla siguiente muestra un ejemplo de los registros de DNS necesarios para el FQDN interno de la granja de servidores web.

Ejemplo de los registros de DNS para el FQDN interno de la granja de servidores web

FQDN interno de la granja de servidores web FQDN del grupo de servidores Registro(s) A de DNS

webcon.contoso.com

ee-pool.contoso.com

Registro A de DNS para ee-pool.contoso.com que se resuelve en la dirección VIP del equilibrador de carga que usan los servidores front-end.

Registro A de DNS para webcon.contoso.com que se resuelve en la dirección VIP del equilibrador de carga que usan los servidores front-end.

ee-pool.contoso.com

ee-pool.contoso.com

Registro A de DNS para ee-pool.contoso.com que se resuelve en la dirección IP virtual (VIP) del equilibrador de carga que usan los servidores front-end Enterprise Edition en el grupo de servidores front-end.

Tenga en cuenta que si usa el equilibrio de carga de DNS en este grupo, su grupo de servidores front-end y la granja de servidores web internos no podrán tener el mismo FQDN.

En esta sección se describen los registros del sistema de nombres de dominio (DNS) necesarios para la implementación de servidores Standard Edition.

En la siguiente tabla se especifican los requisitos de DNS para implementar un servidor de Skype Empresarial Server Standard Edition.

Requisitos de DNS para un servidor Standard Edition

Escenario de implementación Requisito de DNS

Servidor Standard Edition

Un registro A interno que resuelve el nombre de dominio completo (FQDN) del servidor en su dirección IP.

Inicio de sesión de clientes automático

Para cada dominio SIP admitido, un registro SRV para _sipinternaltls._tcp. <domain> por el puerto 5061 que asigna el FQDN del servidor Standard Edition que autentica y redirige las solicitudes de inicio de sesión del cliente. Para más detalles, consulte Requisitos DNS para inicio de sesión automática del cliente en Lync Server 2013.

Detección del servicio web de actualización de dispositivos por los dispositivos de comunicaciones unificadas (UC)

Un registro A interno con el nombre ucupdates-r2. <SIP domain> que se resuelve en la dirección IP del servidor Standard Edition que hospeda el servicio web de actualización de dispositivos. En una situación en la que un dispositivo de comunicaciones unificadas esté activado, pero en el que nunca un usuario inició sesión, el registro A permite al dispositivo detectar el servidor que hospeda el servicio web de actualización de dispositivos y obtener actualizaciones. De lo contrario, los dispositivos obtienen la información del servidor a través del aprovisionamiento en banda la primera vez que un usuario inicia sesión.

Un proxy inverso compatible con el tráfico HTTP

Un registro A externo que resuelve el FQDN externo de la granja de servidores web en la dirección IP externa del proxy inverso. Los clientes y los dispositivos de UC usan este registro para conectarse al proxy inverso. Para más detalles, consulte Determinar los requisitos DNS para Lync Server 2013 en la documentación de planeación.

Skype Empresarial Server admite direcciones URL sencillas, lo que facilita que los usuarios se unan a reuniones y que los administradores tengan acceso a herramientas administrativas de Skype Empresarial Server. El dominio URL sencilla no tiene que coincidir con ningún dominio SIP. Para más detalles sobre las URL sencillas, consulte Planeación de las direcciones URL simples en Lync Server 2013.

Skype Empresarial Server admite las tres direcciones URL sencillas siguientes: de reunión, de acceso telefónico y de administrador. Es necesario que configure las direcciones URL sencillas de reunión y de acceso telefónico; la dirección URL sencilla del administrador es opcional. Los registros del sistema de nombres de dominio (DNS) necesarios para admitir direcciones URL sencillas varían en función de la forma en que se hayan definido dichas direcciones URL sencillas y de si desea admitir la recuperación ante desastres para las direcciones URL sencillas.

En la opción 1, se crea una dirección URL base para cada dirección URL sencilla.

noteNota:
Cuando un usuario hace clic en un vínculo de reunión de dirección URL sencilla, el servidor en el que se resuelve el registro A de DNS determina el software cliente correcto para iniciarlo. Una vez iniciado, el software cliente se comunica automáticamente con el grupo de servidores en el que se hospeda la conferencia. De este modo, los usuarios se dirigen al servidor adecuado para el contenido de la reunión, independientemente del servidor o del grupo de servidores en el que se resuelvan los registros A de DNS de la dirección URL sencilla.

Opción 1 de dirección URL sencilla

Dirección URL sencilla

Ejemplo

Reunión

https://meet.contoso.com, https://meet.fabrikam.com, etc. (una por cada dominio SIP de la organización)

Acceso telefónico

https://dialin.contoso.com

Administrador

https://admin.contoso.com

Si usa la opción 1, necesita definir lo siguiente:

  • Para cada URL sencilla de reunión, necesita un registro A de DNS que resuelva la dirección URL en la dirección IP del director, si se ha implementado uno. En caso contrario, necesita resolverse en la dirección IP del equilibrador de carga de un grupo de servidores front-end. Si no ha implementado un grupo de servidores y se usa una implementación de servidor Standard Edition, el registro A de DNS necesita resolverse en la dirección IP de un servidor Standard Edition de su organización.

    Si dispone de más de un dominio SIP en la organización y usa esta opción, necesita crear direcciones URL sencillas de reunión para cada dominio SIP y se necesita un registro A de DNS para cada dirección URL sencilla de reunión. Por ejemplo, si tiene contoso.com y fabrikam.com, creará registros A de DNS para https://meet.contoso.com y para https://meet.fabrikam.com.

    Asimismo, si tiene varios dominios SIP y desea reducir los requisitos de registro de DNS y de certificado de estas direcciones URL sencillas, use la opción 3 que se describe más adelante en este tema.

  • Para la dirección URL de acceso telefónico, necesita un registro A de DNS que se resuelva en la dirección URL en la dirección IP del director, si se ha implementado uno. En caso contrario, necesita resolverse en la dirección IP del equilibrador de carga de un grupo de servidores front-end. Si no ha implementado un grupo de servidores y usa una implementación de servidores Standard Edition, el registro A de DNS necesita resolverse en la dirección IP de un servidor Standard Edition de su organización.

  • La dirección URL sencilla de administrador es solo de uso interno. Necesita un registro A de DNS que se resuelva en la dirección URL en la dirección IP del director, si se ha implementado uno. En caso contrario, necesita resolverse en la dirección IP del equilibrador de carga de un grupo de servidores front-end. Si no ha implementado un grupo de servidores y usa una implementación de servidores Standard Edition, el registro A de DNS necesita resolverse en la dirección IP de un servidor Standard Edition de su organización.

Con la opción 2, todas las direcciones URL sencillas de reunión, de acceso telefónico y de administrador tienen una dirección URL base común, como lync.contoso.com. Por consiguiente, únicamente necesita un registro A de DNS para estas direcciones URL sencillas, que resuelve lync.contoso.com en la dirección IP de un grupo de servidores de director o un grupo de servidores front-end. Si no ha implementado un grupo de servidores y usa una implementación de servidores Standard Edition, el registro A de DNS necesita resolverse en la dirección IP de un servidor Standard Edition de su organización.

Tenga en cuenta que si dispone de más de un dominio SIP en la organización y usa esta opción, aún necesita crear direcciones URL sencillas de reunión para cada dominio SIP y necesita un registro A de DNS para cada dirección URL sencilla de reunión. En este ejemplo, aunque las tres direcciones URL sencillas se basan en lync.contoso.com, se configura una dirección URL sencilla de reunión adicional para fabrikam.com con una dirección URL base distinta. En este ejemplo, necesita crear registros A de DNS para https://lync.contoso.com y para https://lync.fabrikam.com. La opción 3 de dirección URL sencilla muestra otra forma de administrar registros A de DNS y de nomenclatura si tiene varios dominios SIP.

Opción 2 de dirección URL sencilla

Dirección URL sencilla

Ejemplo

Reunión

https://lync.contoso.com/Meet, https://lync.fabrikam.com/Meet, etc. (una por cada dominio SIP de la organización)

Acceso telefónico

https://lync.contoso.com/Dialin

Administrador

https://lync.contoso.com/Admin

La opción 3 resulta más útil si se tienen varios dominios SIP y desea reducir los requisitos de registro de DNS y de certificado de estas direcciones URL sencillas. En este ejemplo, solo se necesita un registro A de DNS, que resuelve lync.contoso.com en la dirección IP de un grupo de director o un grupo de servidores front-end.

Opción 3 de dirección URL sencilla

Dirección URL sencilla

Ejemplo

Reunión

https://lync.contoso.com/contosoSIPdomain/Meet

https://lync.contoso.com/fabrikamSIPdomain/Meet

Acceso telefónico

https://lync.contoso.com/contosoSIPdomain/Dialin

Administrador

https://lync.contoso.com/contosoSIPdomain/Admin

Si tiene varios sitios que contienen Grupos de servidores front-end y su proveedor de DNS admite GeoDNS, puede configurar sus registros de DNS para que las direcciones URL sencillas admitan la recuperación ante desastres, de modo tal que continúe la funcionalidad de las direcciones URL sencillas incluso si un Grupo de servidores front-end completo deja de funcionar. Esta característica de recuperación ante desastres admite las direcciones URL sencillas de acceso telefónico y de reunión.

Para configurar esto, cree dos direcciones de GeoDNS. Cada dirección tiene dos registros A de DNS o CNAME que se resuelven en dos grupos de servidores que funcionan juntos con fines de recuperación ante desastres. Una dirección de GeoDNS se utiliza para el acceso interno y se resuelve en el FQDN web interno o la dirección IP del equilibrador de carga para dos grupos de servidores. La otra dirección de GeoDNS se utiliza para el acceso externo y se resuelve en el FQDN web externo o la dirección IP del equilibrador de carga para dos grupos de servidores. Lo siguiente es un ejemplo de dirección URL sencilla de reunión, que utiliza los FQDN para los grupos de servidores.

Meet-int.geolb.contoso.com
     Pool1InternalWebFQDN.contoso.com
     Pool2InternalWebFQDN.contoso.com
Meet-ext.geolb.contoso.com
     Pool1ExternalWebFQDN.contoso.com
     Pool2ExternalWebFQDN.contoso.com

Luego, cree registros CNAME que se resuelven en la dirección URL sencilla de reunión (como meet.contoso.com) en las dos direcciones de GeoDNS.

noteNota:
Si su red utiliza vinculaciones (enrutamiento de todo el tráfico de direcciones URL sencillas a través del vínculo externo, incluido el tráfico que proviene desde su organización), puede sencillamente configurar la dirección de GeoDNS externa y resolver la dirección URL sencilla de reunión en solo esa dirección externa.

Al utilizar este método, puede configurar cada dirección de GeoDNS para que utilice un método round robin para distribuir solicitudes en los dos grupos de servidores, o bien para que se conecte principalmente a un grupo de servidores (como el grupo de servidores más cercano) y utilizar el otro grupo solo en caso de que no se pueda establecer la conexión.

Puede configurar las mismas opciones para la dirección URL sencilla de acceso telefónico. Para ello, cree registros adicionales como los del ejemplo anterior, y sustituya dialin por meet en los registros de DNS. Para la dirección URL sencilla de administrador, utilice una de las tres opciones que se mencionaron antes en esta sección.

Una vez que esta configuración esté definida, necesita utilizar una aplicación de supervisión para configurar la supervisión HTTP para que busque errores. Para el acceso externo, supervise para asegurarse de que sean correctas las solicitudes HTTPS GET lyncdiscover.<sipdomain> realizadas al FQDN web externo o a la dirección IP del equilibrador de carga para los dos grupos de servidores. Por ejemplo, las siguientes solicitudes no tienen que contener ningún encabezado ACCEPT y necesitan devolver 200 OK .

HTTPS GET Pool1ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root
HTTPS GET Pool2ExternalWebFQDN.contoso.com/autodiscover/autodiscoverservice.svc/root

Para el acceso interno, necesita supervisar el puerto 5061 en el FQDN web interno o la dirección IP del equilibrador de carga para los dos grupos de servidores. Si se detecta cualquier problema de conectividad, la dirección VIP de estos grupos de servidores necesita cerrar los puertos 80, 443 y 4443.

En esta sección se describen los registros del sistema de nombres de dominio (DNS) necesarios para el inicio de sesión automático de los clientes. Cuando se implementan servidores Standard Edition o grupos de servidores front-end, se pueden configurar los clientes para que usen la detección automática para iniciar sesión en el servidor Standard Edition o en el grupo de servidores front-end adecuado. No recomendamos solicitar a los clientes que se conecten manualmente a Skype Empresarial Server.

Para admitir el inicio de sesión automático de los clientes, necesita:

  • Designar un único servidor o grupo de servidores para distribuir y autenticar las solicitudes de inicio de sesión de los clientes. Puede ser uno de los servidores o grupos de servidores existentes en la organización que hospede usuarios, o bien, puede designar un servidor o grupo de servidores dedicado para este fin que no hospede usuarios. Para lograr una alta disponibilidad, recomendamos designar un grupo de servidores front-end para esta función.

  • Crear un registro SRV de DNS interno para admitir el inicio de sesión automático de los clientes para este servidor o grupo de servidores.

    noteNota:
    En los siguientes requisitos de registro, el dominio SIP hace referencia a la parte correspondiente al host de los URI de SIP asignados a los usuarios. Por ejemplo, si los URI de SIP tienen el formato *@contoso.com, contoso.com es el dominio SIP. El dominio SIP suele ser distinto del dominio de Active Directory interno. Una organización también puede admitir varios dominios SIP.

Para habilitar la configuración automática de los clientes, necesita crear un registro SRV de DNS interno que asigne uno de los registros siguientes al nombre de dominio completo (FQDN) del grupo de servidores front-end o del servidor Standard Edition que distribuya las solicitudes de inicio de sesión de los clientes de Skype Empresarial:

  • _sipinternaltls._tcp. <domain> : para conexiones TLS internas

Solo tiene que crear un único registro SRV por dominio para el servidor Standard Edition o el grupo de servidores front-end que distribuirá las solicitudes de inicio de sesión.

En la tabla siguiente se muestran algunos registros de ejemplo necesarios para la compañía ficticia Contoso, que admite los dominios SIP de contoso.com y retail.contoso.com.

Ejemplo de registros de DNS necesarios para el inicio de sesión automático de los clientes con varios dominios SIP

FQDN del grupo de servidores front-end utilizado para distribuir las solicitudes de inicio de sesión Dominio SIP Registro SRV de DNS

pool01.contoso.com

contoso.com

Registro SRV para el dominio _sipinternaltls._tcp.contoso.com por el puerto 5061 que se asigna a pool01.contoso.com

pool01.contoso.com

retail.contoso.com

Registro SRV para el dominio _sipinternaltls._tcp.retail.contoso.com por el puerto 5061 que se asigna a pool01.contoso.com

noteNota:
De forma predeterminada, las consultas de los registros de DNS observan estrictamente los resultados de los nombres de dominio entre el dominio del nombre de usuario y el registro SRV. Si prefiere que las consultas de DNS de los clientes usen los resultados de sufijos, puede configurar la directiva de grupo DisableStrictDNSNaming. Para más detalles, consulte Planeación de clientes y dispositivos en Lync Server 2013 en la documentación sobre planeación.

En este ejemplo se utilizan los mismos nombres de ejemplo de la tabla anterior. La organización Contoso admite los dominios SIP de contoso.com y retail.contoso.com, y todos sus usuarios tienen un URI de SIP con uno de los formatos siguientes:

  • <user> @retail.contoso.com

  • <user> @contoso.com

Al implementar la característica de movilidad de Skype Empresarial Server, puede usar las nuevas direcciones URL que están disponibles con el servicio de detección automática de Microsoft Skype Empresarial Server; o bien, puede usar las direcciones URL de servicios web existentes. Si usa las direcciones URL existentes, los usuarios necesitan introducir manualmente las direcciones URL en la configuración del dispositivo móvil. Normalmente, esta opción se usa para solucionar problemas. Cuando use las nuevas direcciones URL, los clientes móviles pueden detectar automáticamente los recursos de Skype Empresarial Server. Cuando admite la detección automática, necesita agregar los registros del sistema de nombres de dominio (DNS) nuevos. En esta sección se describen los registros de DNS necesarios para la detección automática.

Para admitir la detección automática, cree los siguientes registros de DNS para cada dominio SIP:

  • Un registro de DNS interno para admitir usuarios móviles que se conectan desde la red de su organización

  • Un registro de DNS externo, o público, para admitir usuarios móviles que se conectan desde Internet

La URL de detección automática interna no tiene que ser direccionable desde fuera de su red. La dirección URL de detección automática externa no tiene que ser direccionable desde dentro de su red. Pero, si no cumple este requisito para la dirección URL externa, la funcionalidad del cliente móvil no tendría que verse afectada.

Los registros de DNS pueden ser registros CNAME o registros A (host).

Registros de DNS internos

Cree uno de los siguientes registros de DNS internos:

 

Tipo de registro Nombre de host o definición SRV Se resuelve en

CNAME

lyncdiscoverinternal. <sipdomain>

Nombre de dominio completo (FQDN) de servicios web internos para el Grupo de directores, si dispone de uno, o para el Grupo de servidores front-end si no dispone de un Director

A (host)

lyncdiscoverinternal. <sipdomain>

Dirección IP de servicios web interna (dirección IP virtual [VIP], si usa un equilibrador de carga) del Grupo de directores, si dispone de uno, o del Grupo de servidores front-end, si no dispone de un Director

Registros de DNS externos

Cree uno de los siguientes registros de DNS externos:

 

Tipo de registro Nombre de host Se resuelve en

CNAME

lyncdiscover. <sipdomain>

FQDN de servicios web externo del Grupo de directores, si dispone de uno, o del Grupo de servidores front-end, si no dispone de un Director.

A (host)

lyncdiscover. <sipdomain>

Dirección IP externa o pública (dirección VIP si usa un equilibrador de carga) del proxy inverso

SRV

_sipfederationtls._tcp. <sipdomain>

Se resuelve en el registro de host (A o AAAA) para el Servidor perimetral de acceso

Para admitir Servicios de notificaciones de inserción y Servicios de notificaciones de inserción de Apple, cree un registro SRV para cada dominio SIP que tenga clientes de Microsoft Lync Mobile.

importantImportante:
Este requisito se aplica solo a clientes de Microsoft Lync Mobile en dispositivos móviles basados en Apple o en Microsoft. Los dispositivos Android y Nokia Symbian no usan notificaciones de inserción.
noteNota:
El tráfico de detección automática circula a través del proxy inverso. El registro SRV apunta a un registro que se resuelve a través del Servidor perimetral de acceso.

Skype Empresarial Server permite el equilibrio de carga de DNS, una solución de software que puede reducir considerablemente la sobrecarga de administración para el equilibrio de carga en la red. El equilibrio de carga de DNS equilibra el tráfico de red que solo pertenece a Skype Empresarial Server, como el tráfico SIP y el tráfico de medios.

Si implementa el equilibrio de carga de DNS, se reducirá considerablemente la sobrecarga de administración de la organización correspondiente a los equilibradores de carga de hardware. Además, se evitará la solución de problemas complejos asociados a errores de configuración de equilibradores de carga del tráfico SIP. También puede impedir que se establezcan conexiones de servidores para poder desconectar servidores. El equilibrio de carga de DNS también garantiza que los problemas relacionados con los equilibradores de carga de hardware no afecten a elementos de tráfico SIP, como el enrutamiento de llamadas básico.

Si se utiliza el equilibrio de carga de DNS también podrá adquirir equilibradores de carga de hardware a un precio más económico que si usa equilibradores de carga de hardware para todos los tipos de tráfico. Necesitará utilizar equilibradores de carga que hayan superado las pruebas de calificación de interoperabilidad con Skype Empresarial Server. Para obtener más información acerca de pruebas de interoperabilidad de equilibrador de carga, consulte "Lync Server 2010 carga equilibrador de Partners" en https://go.microsoft.com/fwlink/p/?linkId=202452. Allí, el contenido se aplica a Skype Empresarial Server.

El equilibrio de carga de DNS es compatible con grupos de servidores front-end, grupos de servidores perimetrales, grupos de servidores de director y grupos de servidores de mediación independientes.

Puede usar el equilibrio de carga de DNS para el tráfico SIP de los grupos de servidores front-end y los grupos de servidores de director. Con el equilibrio de carga de DNS implementado, seguirá necesitando usar también equilibradores de carga de hardware para esos grupos de servidores, pero solo para el tráfico HTTPS de cliente a servidor. El equilibrador de carga de hardware se usa para el tráfico HTTPS de los clientes en los puertos 443 y 80.

A pesar de que seguirá necesitando equilibradores de carga de hardware para esos grupos de servidores, su instalación y administración será fundamentalmente para el tráfico HTTPS, al que están habituados los administradores de equilibradores de carga de hardware.

El equilibrio de carga de DNS admite la conmutación automática por error solo en los servidores que ejecutan Skype Empresarial Server o Lync Server 2010 y para los clientes de Lync 2013 y Skype Empresarial. Las versiones anteriores de los clientes y Office Communications Server pueden seguir conectándose a grupos de servidores que ejecuten el equilibrio de carga de DNS pero, si no consiguen establecer una conexión con el primer servidor al que los remita el equilibrio de carga de DNS, no pueden efectuar la conmutación por error a otro servidor del grupo.

Por otra parte, si usa la mensajería unificada de Exchange, necesita utilizar como mínimo Exchange 2010 SP1 para obtener compatibilidad con el equilibrio de carga de DNS de Skype Empresarial Server. Si usa alguna versión anterior de Exchange, los usuarios no tendrán capacidades de conmutación por error para estos escenarios de la mensajería unificada de Exchange:

  • Reproducir el correo de voz de Enterprise en el teléfono

  • Transferir llamadas de un operador automático de la mensajería unificada de Exchange

Todos los demás escenarios de la mensajería unificada de Exchange funcionarán correctamente.

Para implementar el equilibrio de carga de DNS en grupos de servidores front-end y grupos de servidores de director, es necesario realizar un par de pasos adicionales con los registros de DNS y los FQDN.

  • Si un grupo de servidores usa equilibrio de carga de DNS, necesita tener dos FQDN: el FQDN normal del grupo que usa el equilibrio de carga de DNS (como, por ejemplo, pool01.contoso.com) y que se resuelve en las IP físicas de los servidores del grupo, y otro FQDN para los servicios web del grupo (como, por ejemplo, web01.contoso.com), que se resuelve como la dirección IP virtual del grupo.

    En el Generador de topologías, si desea implementar el equilibrio de carga de DNS en un grupo, para crear este FQDN adicional para los servicios web del grupo, necesita activar la casilla Reemplazar el FQDN del grupo de servicios web internos y escribir el FQDN en la página Especificar las direcciones URL de los servicios web de este grupo .

  • Para admitir el FQDN que usa el equilibrio de carga de DNS, necesita aprovisionar el DNS, de modo que resuelva el FQDN del grupo (como, por ejemplo, pool01.contoso.com) en las direcciones IP de todos los servidores del grupo (por ejemplo, 192.168.1.1, 192.168.1.2, etc.). Necesita incluir solo las direcciones IP de los servidores implementados actualmente.

    warningAdvertencia:
    Si tiene más de un Grupo de servidores front-end o Servidor front-end, el FQDN de los servicios web externos tiene que ser único. Por ejemplo, si define el FQDN de los servicios web externos de un Servidor front-end como pool01.contoso.com , no puede usar pool01.contoso.com para otro Grupo de servidores front-end o Servidor front-end. Si también está implementando Directores, el FQDN de los servicios web externos definidos para cualquier Director o Grupo de directores necesita ser diferente de cualquier otro Director o Grupo de directores, al igual que cualquier otro Grupo de servidores front-end o Servidor front-end. Si decide omitir los servicios web internos con un FQDN autodefinido, cada FQDN tiene que ser diferente de cualquier otro Grupo de servidores front-end, Director o Grupo de directores.

Puede implementar el equilibrio de carga de DNS en grupos de servidores perimetrales. Si lo hace, necesita tener en cuenta varias consideraciones.

El uso del equilibrio de carga de DNS en los servidores perimetrales provoca una pérdida en la capacidad de conmutación por error, en los siguientes escenarios:

  • Federación con organizaciones que ejecutan versiones de Skype Empresarial Server anteriores a Lync Server 2010.

  • Intercambio de mensajes instantáneos con usuarios de servicios de mensajería instantánea (MI) pública, como AOL y Yahoo!, además de servidores y proveedores basados en XMPP, como Google Talk, que actualmente es el único socio XMPP admitido.

Estos escenarios funcionarán siempre que se ejecuten correctamente todos los servidores perimetrales del grupo pero, si un servidor perimetral no está disponible, fallarán todas las solicitudes de estos escenarios que se envíen a él, en lugar de redirigirse a otro servidor perimetral.

Si usa la mensajería unificada de Exchange, necesita utilizar como mínimo Exchange 2013 para obtener compatibilidad con el equilibrio de carga de DNS de Skype Empresarial Server en los servidores perimetrales. Si usa alguna versión anterior de Exchange, los usuarios remotos no tendrán capacidades de conmutación por error para estos escenarios de mensajería unificada de Exchange:

  • Reproducir el correo de voz de Enterprise en el teléfono

  • Transferir llamadas de un operador automático de la mensajería unificada de Exchange

Todos los demás escenarios de la mensajería unificada de Exchange funcionarán correctamente.

La interfaz perimetral interna y la interfaz perimetral externa necesitan usar el mismo tipo de equilibrio de carga. No puede usar equilibrio de carga de DNS en una interfaz perimetral y equilibrio de carga de hardware en la otra interfaz perimetral.

Para implementar el equilibrio de carga de DNS en la interfaz externa del grupo de servidores perimetrales, necesita las siguientes entradas de DNS:

  • Para el servicio perimetral de acceso, necesita una entrada por cada servidor del grupo. Cada entrada necesita resolver el FQDN del servicio perimetral de acceso (por ejemplo, sip.contoso.com) en la dirección IP del servicio perimetral de acceso de uno de los servidores perimetrales del grupo.

  • Para el servicio perimetral de conferencia web, necesita una entrada por cada servidor del grupo. Cada entrada necesita resolver el FQDN del servicio perimetral de conferencia web (por ejemplo, webconf.contoso.com) en la dirección IP del servicio perimetral de conferencia web de uno de los servidores perimetrales del grupo.

  • Para el servicio perimetral de audio y vídeo, necesita una entrada por cada servidor del grupo. Cada entrada necesita resolver el FQDN del servicio perimetral de audio y vídeo (por ejemplo, av.contoso.com) en la dirección IP del servicio perimetral de audio y vídeo de uno de los servidores perimetrales del grupo.

Para implementar el equilibrio de carga de DNS en la interfaz interna del grupo de servidores perimetrales, necesita agregar un registro A de DNS que resuelva el FQDN interno del grupo de servidores perimetrales en la dirección IP de cada servidor del grupo.

Puede usar el equilibrio de carga de DNS en grupos de servidores de mediación independientes. Todo el tráfico de medios y SIP se equilibra con el equilibrio de carga de DNS.

Para implementar el equilibrio de carga de DNS en un grupo de servidores de mediación, necesita aprovisionar el DNS, de modo que resuelva el FQDN del grupo (por ejemplo, mediationpool1.contoso.com) en las direcciones IP de todos los servidores del grupo (por ejemplo, 192.168.1.1, 192.168.1.2, etc.).

Si utiliza el equilibrio de carga de DNS y necesita bloquear el tráfico a un equipo específico, no es suficiente con solo quitar las entradas de direcciones IP del grupo FQDN. También necesita quitar la entrada de DNS para el equipo.

Tenga en cuenta que para el tráfico de servidor a servidor, Skype Empresarial Server usa el equilibrio de carga preparado para la topología. Los servidores leen la topología publicada en el Almacén de administración central para obtener los FQDN de los servidores en la topología y distribuyen automáticamente el tráfico entre los servidores. Para bloquear un servidor para que no reciba tráfico de servidor a servidor, necesita quitar el servidor de la topología.

En esta sección se describen los registros del sistema de nombres de dominio (DNS) necesarios para la implementación de Servidores de chat persistente.

En la siguiente tabla se especifican los requisitos de DNS para la implementación de Servidor de chat persistente.

Requisitos de DNS para un servidor de chat persistente

Escenario de implementación Requisito de DNS

Un servidor de chat persistente

Un registro A interno que resuelve el nombre de dominio completo (FQDN) del servidor en su dirección IP.

Grupo de servidores de chat persistente

Un registro A interno que resuelve el nombre de dominio completo (FQDN) de los servidores en su dirección IP.

Ejemplo

PersistentChatServer01.contoso.com 10.10.10.1

PersistentChatServer02.contoso.com 10.10.10.2

Un registro A interno que resuelve el nombre de dominio completo (FQDN) de los servidores en su dirección IP.

Ejemplo

PersistentChatPool.contoso.com 10.10.10.1

PersistentChatPool.contoso.com 10.10.10.2

 
Mostrar: