Requisitos del equilibrio de carga para Skype Empresarial
Resumen: Revise las consideraciones de equilibrio de carga antes de implementar Skype Empresarial Server.
El equilibrio de carga distribuye el tráfico entre los servidores de un grupo. Si tiene grupos de servidores front-end, grupos de servidores de mediación o grupos de servidores perimetrales, deberá implementar el equilibrio de carga para estos grupos.
Skype Empresarial Server admite dos tipos de soluciones de equilibrio de carga para el tráfico de cliente a servidor: equilibrio de carga del sistema de nombres de dominio (DNS) y equilibrio de carga de hardware (a menudo abreviado como HLB). El equilibrio de carga DNS ofrece varias ventajas, entre las que se incluyen una administración más sencilla, una solución de problemas más eficiente y la capacidad de aislar gran parte del tráfico Skype Empresarial Server de cualquier posible problema del equilibrador de carga de hardware.
Decida por sí mismo qué solución de equilibrio de carga es adecuada para cada grupo de la implementación, pero tenga en cuenta las siguientes restricciones:
La interfaz perimetral interna y la interfaz perimetral externa necesitan usar el mismo tipo de equilibrio de carga. No puede usar el equilibrio de carga de DNS en una interfaz y el equilibrio de carga de hardware en la otra.
Algunos tipos de tráfico requieren un equilibrador de carga de hardware. Por ejemplo, el tráfico HTTP requiere un equilibrador de carga de hardware en lugar del equilibrio de carga de DNS. El equilibrio de carga de DNS no funciona con tráfico web del cliente al servidor.
Si decide usar el equilibrio de carga de DNS para un grupo, pero aún tiene que implementar equilibradores de carga de hardware para el tráfico, como el tráfico HTTP, la administración de los equilibradores de carga de hardware será mucho más sencilla. Por ejemplo, configurar el equilibrador de carga de hardware será más sencillo, pues solamente administrará el tráfico HTTPS y HTTP, mientras que el equilibrio de carga de DNS administrará todos los demás protocolos. Para más detalles, consulte DNS Load Balancing.
Para el tráfico de servidor a servidor, Skype Empresarial Server usa equilibrio de carga con conocimiento de 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 distribuir automáticamente el tráfico entre los servidores. Los administradores no necesitan configurar ni administrar este tipo de equilibrio de carga.
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 FQDN del grupo de servidores. También es preciso quitar la entrada de DNS para el equipo.
Requisitos del equilibrador de carga de hardware
La topología perimetral consolidada a escala Skype Empresarial Server está optimizada para el equilibrio de carga DNS para las nuevas implementaciones federadas principalmente con otras organizaciones que usan Skype Empresarial Server o Lync Server. Si se requiere alta disponibilidad para cualquiera de los siguientes escenarios, debe usarse un equilibrador de carga de hardware en grupos de servidores perimetrales para lo siguiente:
Federación con organizaciones que usan Office Communications Server 2007 R2 u Office Communications Server 2007
Mensajería unificada de Exchange para usuarios remotos que usan la mensajería unificada de Exchange anterior a Exchange 2010 con SP1
Conectividad con usuarios de mensajería instantánea (MI) pública
Importante
No se admite el uso del equilibrio de carga de DNS en una interfaz y del equilibrio de carga de hardware en otra. Necesita utilizar el equilibrio de carga de hardware o de DNS en ambas interfaces.
Nota
Si usa un equilibrador de carga de hardware, el equilibrador de carga que se haya implementado para las conexiones con la red interna necesitará configurarse para que solo equilibre la carga del tráfico de los servidores que ejecuten el servicio perimetral de acceso y el servicio perimetral A/V. No puede equilibrar la carga del tráfico al servicio perimetral de conferencia web interno o al servicio proxy XMPP interno.
Nota
El NAT de retorno de servidor directo (DSR) no es compatible con Skype Empresarial Server.
Para determinar si el equilibrador de carga de hardware admite las características necesarias que requiere Skype Empresarial Server, consulte Infraestructura para Skype Empresarial.
Requisitos de equilibrador de carga de hardware para servidores perimetrales que ejecutan el servicio perimetral A/V
Estos son los requisitos del equilibrador de carga de hardware para los servidores perimetrales que ejecutan el servicio perimetral A/V:
Deshabilitar el algoritmo de Nagle de TCP para los puertos 443 internos y externos. El algoritmo de Nagle es el proceso de combinación de varios paquetes pequeños en un único paquete más grande para obtener una transmisión más eficiente.
Desactive el tcp nagling para el intervalo de puertos externos 50 000 - 59 999.
No utilizar NAT en el firewall interno o externo.
La interfaz interna del perímetro debe estar en una red distinta de la interfaz externa del servidor perimetral y el enrutamiento entre ellos debe estar deshabilitado.
La interfaz externa del servidor perimetral que ejecuta el servicio perimetral de A/V debe usar direcciones IP enrutables públicamente y ninguna nat o traducción de puertos en ninguna de las direcciones IP externas perimetrales.
El equilibrador de carga no necesita cambiar la dirección de origen del cliente.
Otros requisitos de Load Balancer de hardware
Los requisitos de afinidad basados en cookies se reducen considerablemente en Skype Empresarial Server para los servicios web. Si va a implementar Skype Empresarial Server y no conservará ningún servidor front-end de Lync Server 2010 ni grupos de servidores front-end, no necesita persistencia basada en cookies. Sin embargo, si conservará temporal o permanentemente los servidores front-end de Lync Server 2010 o los grupos de servidores front-end, seguirá usando la persistencia basada en cookies a medida que se implementa y configura para Lync Server 2010.
Nota
La utilización de la afinidad basada en cookies pese a que su implementación no la necesite no tiene repercusiones.
Para las implementaciones que no utilizarán la afinidad basada en cookies:
- En la regla de publicación del proxy inverso para el puerto 4443, establezca Reenviar encabezado de host en True. Esto garantizará que se reenviará la dirección URL original.
Para las implementaciones que utilizarán la afinidad basada en cookies:
En la regla de publicación del proxy inverso para el puerto 4443, establezca Reenviar encabezado de host en True. Esto garantizará que se reenviará la dirección URL original.
La cookie del equilibrador de carga de hardware NO NECESITA estar marcada como httpOnly
La cookie del equilibrador de carga de hardware NO NECESITA tener tiempo de expiración
La cookie del equilibrador de carga de hardware NECESITA tener el nombre MS-WSMAN (este es el valor esperado por los servicios web y no puede modificarse)
La cookie del equilibrador de carga de hardware NECESITA estar establecida en cada respuesta HTTP para la que la solicitud HTTP entrante no tenía una cookie, independientemente de si una respuesta HTTP anterior en la misma conexión TCP ya había obtenido una cookie. Si el equilibrador de carga optimiza la inserción de cookies para que solo ocurra una vez por conexión TCP, la optimización NO NECESITA usarse.
Nota
Las configuraciones típicas del equilibrador de carga de hardware usan afinidad de dirección de origen y 20 minutos. Duración de la sesión TCP, que es válida para los clientes de Lync Server y Lync 2013 porque el estado de la sesión se mantiene mediante el uso del cliente y/o la interacción de la aplicación.
Si se implementan dispositivos móviles, es preciso que el equilibrador de carga de hardware pueda equilibrar la carga de una solicitud individual dentro de una sesión TCP (de hecho, necesita poder equilibrar la carga de una solicitud individual basada en la dirección IP de destino).
Precaución
Si va a implementar dispositivos móviles, el equilibrador de carga de hardware debe poder equilibrar la carga individualmente cada solicitud dentro de una conexión TCP. Las últimas aplicaciones móviles que utilizan Apple iOS requieren la versión 1.2 de la seguridad de la capa de transporte (TLS).
Precaución
Para obtener más información sobre los equilibradores de carga de hardware de terceros, consulte Infraestructura para Skype Empresarial.
A continuación, se muestran los requisitos del equilibrador de carga de hardware para los servicios web del grupo de servidores front-end y de directores:
Para VIP de los servicios web internos, configure la persistencia Source_addr (puerto interno 80, 443) en el equilibrador de carga de hardware. Por Skype Empresarial Server, la persistencia de Source_addr significa que siempre se envían varias conexiones procedentes de una única dirección IP a un servidor para mantener el estado de la sesión.
Use un tiempo de espera de inactividad de TCP de 1800 segundos.
En el firewall entre el proxy inverso y el equilibrador de carga de hardware del grupo de próximo salto, cree una regla para permitir https: tráfico en el puerto 4443, desde el proxy inverso al equilibrador de carga de hardware. El equilibrador de carga de hardware necesita configurarse para que escuche los puertos 80, 443 y 4443.
Resumen de los requisitos de afinidad del equilibrador de carga de hardware
| Ubicación de cliente/usuario | Requisitos de afinidad del FQDN de servicios web externos | Requisitos de afinidad del FQDN de servicios web internos |
|---|---|---|
| Lync Web App (usuarios internos y externos) Dispositivo móvil (usuarios internos y externos) |
Sin afinidad |
Afinidad de direcciones de origen |
| Lync Web App (solo usuarios externos) Dispositivo móvil (usuarios internos y externos) |
Sin afinidad |
Afinidad de direcciones de origen |
| Lync Web App (solo usuarios internos) Dispositivo móvil (no implementado) |
Sin afinidad |
Afinidad de direcciones de origen |
Supervisión de puertos para los equilibradores de carga de hardware
Es necesario definir la supervisión de puertos en los equilibradores de carga de hardware para determinar cuándo determinados servicios dejan de estar disponibles por errores de comunicaciones o de hardware. Por ejemplo, si el servicio servidor front-end (RTCSRV) se detiene porque se produce un error en el servidor front-end o el grupo de servidores front-end, la supervisión de HLB también debe dejar de recibir tráfico en los servicios web. La supervisión de puertos en ECH tiene que implementarse para supervisar lo siguiente:
Grupo de usuarios del servidor front-end - Interfaz interna de HLB
| Puerto/IP virtual | Puerto de nodo | Monitor/máquina de nodo | Perfil de persistencia | Notas |
|---|---|---|---|---|
| <int_mco_443_vs web de la piscina> 443 |
443 |
Front-end 5061 |
Origen |
HTTPS |
| <int_mco_80_vs web de la piscina> 80 |
80 |
Front-end 5061 |
Origen |
HTTP |
Grupo de usuarios del servidor front-end - Interfaz externa HLB
| Puerto/IP virtual | Puerto de nodo | Monitor/máquina de nodo | Perfil de persistencia | Notas |
|---|---|---|---|---|
| <web_mco_443_vs de la piscina> 443 |
4443 |
Front-end 5061 |
Ninguno |
HTTPS |
| <web_mco_80_vs de la piscina> 80 |
8080 |
Front-end 5061 |
Ninguno |
HTTP |
Equilibrio de carga de DNS
Skype Empresarial Server habilita el equilibrio de carga 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 DNS equilibra el tráfico de red que es exclusivo de Skype Empresarial Server, como el tráfico SIP y el tráfico multimedia.
Si implementa el equilibrio de carga DNS, se minimizará la sobrecarga de administración de su organización para 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.
El siguiente diagrama muestra un ejemplo que incluye equilibrio de carga DNS interno y externo:
Diagrama de red perimetral con direcciones IPv4 públicas
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. Debe usar equilibradores de carga que hayan pasado pruebas de cualificación de interoperabilidad con Skype Empresarial Server. Para obtener más información sobre las pruebas de interoperabilidad del equilibrador de carga, consulte Lync Server 2010 Load Balancer Partners. El contenido allí 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.
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 de un grupo mediante la conexión a una de las direcciones IP devueltas de la consulta de registro A y AAAA (si se usa la dirección IPv6) del grupo de servidores nombre de dominio completo (FQDN).
Por ejemplo, si hay tres servidores front-end en un grupo denominado pool01.contoso.com, pasará lo siguiente:
Clientes que ejecutan Skype Empresarial DNS de consulta para pool01.contoso.com. La consulta devuelve tres direcciones IP y las almacena en caché de la siguiente manera (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 prueba todas las entradas almacenadas en caché sin una conexión correcta, se notifica al usuario 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 (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 del grupo de tareas de ingeniería de Internet "RR de DNS para especificar la ubicación de los servicios (DNS SRV)" RFC 2782, DNS SRV RR especifica que, si hay varios registros SRV de DNS definidos, primero se usa la prioridad y, a continuación, el 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 DEBEN usar Peso 0 cuando no haya ninguna selección de servidor que realizar. 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.
Equilibrio de carga de DNS en grupos de servidores front-end y grupos de servidores de director
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.
Equilibrio de carga de DNS y compatibilidad con clientes y servidores más antiguos
El equilibrio de carga DNS solo admite la conmutación por error automática para 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 clientes y Office Communications Server aún pueden conectarse a grupos que ejecutan equilibrio de carga DNS, pero si no pueden realizar una conexión al primer servidor al que se refiere el equilibrio de carga DNS, no pueden conmutar por error a otro servidor del grupo.
Además, si usa mensajería unificada de Exchange, debe usar un mínimo de Exchange 2010 SP1 para obtener soporte técnico para Skype Empresarial Server equilibrio de carga DNS. 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.
Implementar el equilibrio de carga de DNS en grupos de servidores front-end y grupos de servidores de director
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.
Un grupo que usa el equilibrio de carga DNS debe tener dos FQDN: el FQDN de grupo normal que usa el equilibrio de carga de DNS (por ejemplo, pool01.contoso.com) y resuelve los IP físicos de los servidores del grupo, y otro FQDN para los servicios web del grupo (como web01.contoso.com), que se resuelve en la dirección IP virtual del grupo.
En el Generador de topologías, si desea implementar el equilibrio de carga DNS para un grupo, para crear este FQDN adicional para los servicios web del grupo debe activar la casilla Invalidar FQDN del grupo de servicios web internos y escribir el FQDN, en la página Especificar las direcciones URL de los servicios web para 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.
Precaución
Si tiene más de un grupo de servidores front-end o front-end, el FQDN de los servicios web externos debe 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 servidores front-end. Si también va a implementar directores, el FQDN de servicios web externos definido para cualquier director o grupo de directores debe ser exclusivo de cualquier otro director o grupo de directores, así como de cualquier grupo de servidores front-end o front-end. Si decide reemplazar los servicios web internos con un FQDN autodefinado, cada FQDN debe ser único de cualquier otro grupo de servidores front-end, director o grupo de directores.
Equilibrio de carga de DNS en grupos de servidores perimetrales
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 publicadas antes de Lync Server 2010.
El intercambio de mensajes instantáneos con los usuarios de servicios de mensajería instantánea pública (MI) AOL y Yahoo!, además de los proveedores y servidores basados en XMPP, como Google Talk, es actualmente el único socio de XMPP compatible.
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 mensajería unificada de Exchange, debe usar un mínimo de Exchange 2013 para obtener soporte técnico para Skype Empresarial Server equilibrio de carga DNS en Edge. 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.
Implementar el equilibrio de carga de DNS en grupos de servidores perimetrales
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 debe resolver el FQDN del servicio perimetral de audio y vídeo (por ejemplo, av.contoso.com) en la dirección IP del servicio perimetral A/V en 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.
Usar el equilibrio de carga de DNS en grupos de servidores de mediación
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.).
Bloquear tráfico a un servidor con equilibrio de carga de DNS
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 es preciso 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 consciente de 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 distribuir 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.