Udostępnij za pośrednictwem

Edge Server disaster recovery in Lync Server 2013

  • Artykuł

 

Topic Last Modified: 2014-03-12

As with other server roles, the best way for you to provide high availability for your Edge Servers is to deploy multiple Edge servers in pools in each site. If one Edge Server goes down, the other servers in the pool will continue to provide Edge services.

To enable disaster recovery procedures, you must have separate Edge Server pools deployed at separate sites. You do not need to explicitly pair Edge pools together as you do with Front End pools, but having multiple Edge pools still provides the availability to carry on if one entire Edge pool goes down. The following sections provide details on disaster recovery for the various functions of Edge Servers.

Remote Access

If you have multiple sites, each with a pool of Edge servers, and one entire Edge pool fails, the remote access services will continue to function without needing administrator action. When creating Edge pools in different sites, you cannot use the same FQDN. Each Edge pool must have unique FQDNs (internal and external). The Edge pools do not use reverse proxy publishing rules to talk to the Front End servers. Automatic failover occurs when the client re-queries the remote access DNS service records, and remote users are routed to the Edge servers in another site. The client attempts each external Edge FQDN according to the priority of the DNS SRV records.

Note

For failover to work smoothly, ensure that the firewall allows the Front End servers from every pool to communicate with all Edge servers.

Federation

For federation relationships with other organizations running Lync Server, inbound federation requests will continue to work as long as you have solutions like Geo-DNS GTM. It’s important to understand that federation failover does not provide failover with priority in SRV records. A solution provided earlier can help you provide disaster recovery capabilities for inbound federation.

Outbound federation is always set up through one published Edge pool or Edge Server in the organization. If this Edge pool has gone down, you must use Topology Builder to change the outbound federation route to use an Edge pool which is still running. For details, see Failing over the Edge pool used for Lync Server federation in Lync Server 2013

XMPP Federation

For XMPP federation, both outbound and inbound traffic will fail if the Edge pool which is designated as the XMPP federation gateway goes down. To make XMPP federation work again, you must change XMPP federation to use a different Edge pool. For details, see Failing over the Edge pool used for XMPP federation in Lync Server 2013.

Edge Pool Fails But Front End Pool Is Still Running

If an Edge pool fails at a site, but the Front End pool at that site is still running, you will need to change the Front End pool to use a different Edge pool at a different site while that first Edge pool is down. For more information, see Changing the Edge pool associated with a Front End pool in Lync Server 2013.