Recuperación ante desastres del servidor perimetral en Lync Server 2013
Última modificación del tema: 2014-03-12
Al igual que con otros roles de servidor, la mejor manera de proporcionar alta disponibilidad para los servidores perimetrales es implementar varios servidores perimetrales en grupos de cada sitio. Si un servidor perimetral se apaga, los demás servidores del grupo seguirán proporcionando servicios perimetrales.
Para habilitar los procedimientos de recuperación ante desastres, debe tener grupos de servidores perimetrales independientes implementados en sitios independientes. No es necesario emparejar explícitamente los grupos de servidores perimetrales, al igual que con los grupos de servidores front-end, pero tener varios grupos de servidores perimetrales sigue proporcionando la disponibilidad para continuar si se baja un grupo completo de servidores perimetrales. Las siguientes secciones proporcionan detalles sobre la recuperación ante desastres para las distintas funciones de los servidores perimetrales.
Acceso remoto
Si tienes varios sitios, cada uno con un grupo de servidores perimetrales y se produce un error en un grupo completo de servidores perimetrales, los servicios de acceso remoto seguirán funcionando sin necesidad de acción de administrador. Al crear grupos de Servidores perimetrales en diferentes sitios, no puede usar el mismo FQDN. Cada grupo de servidores perimetrales debe tener FQDN únicos (internos y externos). Los grupos de servidores perimetrales no usan reglas de publicación de proxy inverso para hablar con los servidores front-end. La conmutación por error automática se produce cuando el cliente vuelve a consultar los registros de servicio DNS de acceso remoto y los usuarios remotos se redirigen a los servidores perimetrales de otro sitio. El cliente intentará cada FQDN de borde externo según la prioridad de los registros SRV de DNS.
Nota
Para que la conmutación por error funcione sin problemas, asegúrese de que el firewall permite que los servidores front-end de cada grupo se comuniquen con todos los servidores perimetrales.
Federación
Para las relaciones de federación con otras organizaciones que ejecutan Lync Server, las solicitudes de federación de entrada seguirán funcionando siempre y cuando tenga soluciones como Geo-DNS GTM. Es importante comprender que la conmutación por error de federación no proporciona la conmutación por error con prioridad en los registros SRV. Una solución proporcionada anteriormente puede ayudarle a proporcionar capacidades de recuperación ante desastres para la federación entrante.
La federación saliente siempre se configura a través de un grupo perimetral o servidor perimetral publicado en la organización. Si este grupo de servidores perimetrales ha desaparecido, debe usar el Generador de topología para cambiar la ruta de federación saliente para usar un grupo de servidores perimetrales que todavía se esté ejecutando. Para obtener más información, vea Errores sobre el grupo perimetral usado para la federación de Lync Server en Lync Server 2013.
Federación XMPP
Para la federación XMPP, se producirá un error en el tráfico entrante y de salida si el grupo de servidores perimetrales que se designa como puerta de enlace de federación XMPP baja. Para que la federación XMPP vuelva a funcionar, debe cambiar la federación XMPP para usar otro grupo de servidores perimetrales. Para obtener más información, consulte Errores sobre el grupo perimetral usado para la federación XMPP en Lync Server 2013.
Se produce un error en el grupo de servidores perimetrales, pero el grupo de servidores front-end sigue ejecutándose
Si se produce un error en un grupo de servidores perimetrales en un sitio, pero el grupo de servidores front-end de ese sitio sigue ejecutándose, deberá cambiar el grupo de servidores front-end para usar otro grupo de servidores perimetrales en un sitio diferente mientras ese primer grupo de servidores perimetrales esté sin conexión. Para obtener más información, vea Cambiar el grupo perimetral asociado a un grupo de servidores front-end en Lync Server 2013.