Choosing a Topology

Topic Last Modified: 2012-08-22

When you choose a topology, you can use one the following supported topology options:

• Single consolidated Edge using private IP addresses for each Edge interface and a network address translation (NAT) public IP address

• Single consolidated Edge using public IP addresses for each Edge interface

• Scaled consolidated Edge using NAT, private IP addresses on Edge interfaces and using Domain Name System (DNS) load balancing

• Scaled consolidated Edge using public IP addresses on Edge interfaces using Domain Name System (DNS) load balancing

• Scaled consolidated Edge using public IP addresses and hardware load balancing

The following table summarizes the functionality available with the three supported Lync Server 2010 topologies. The column headings indicate the functionality available for a given Edge configuration option. Using the Scaled Edge (DNS load balanced) option as an example, you can see that it supports high availability, can use non-routable private IP addresses (with NAT) or routable public IP addresses assigned to the Edge external interfaces, reduces cost because a hardware load balancer is not required.

Edge failover scenarios supported with DNS Load Balancing are Lync-to-Lync point-to-point sessions, Lync conferencing sessions, and Lync-to-PSTN sessions. Edge failover scenarios that do not benefit from DNS Load Balancing are failover for Exchange Unified Messaging (UM) prior to Exchange Server 2010 with SP1 configured to use DNS Load Balancing, public instant messaging (IM) connectivity, and federation with servers running Office Communications Server.

Summary of Edge Server Topology Options

* Failover for Exchange UM (remote user), public instant messaging (IM) connectivity, and federation with servers running Office Communications Server.

Unlike Microsoft Office Communications Server 2007 R2, Lync Server 2010 supports placing Access, Web Conferencing, and A/V Edge external interfaces behind a router or firewall that performs network address translation (NAT) for both single and scaled consolidated Edge Server topologies.

Using NAT for all Edge external interfaces requires the use of DNS load balancing. When compared to using hardware load balancers, using Domain Name System (DNS) load balancing allows you to reduce the number of public IP address per Edge Server in an Edge pool as described in the following list:

• Lync Server 2010 Scaled Consolidated Edge (DNS load balanced) Requires three public IP addresses for each Edge Server in an Edge pool.

• Lync Server 2010 Scaled Consolidated Edge (hardware load balanced) Requires three public IP address for load balancer virtual IP addresses (one time requirement that does not increment as more Edge Servers are added to the pool) plus three public IP addresses per Edge Server in a pool.

IP Address Requirements for Scaled Consolidated Edge (IP Address per role)

IP Address Requirements for Scaled Consolidated Edge (Single IP address for all roles)

The primary decision points for topology selection are high availability and load balancing. The requirement for high availability can influence the load balancing decision.

• High availability   If you need high availability, deploy at least two Edge Servers in a pool. A single Edge pool will support up to ten Edge Servers. If more capacity is required, you can deploy multiple Edge pools. As a general rule, 10% of a given user base will need external access.

• Hardware load balancing   Hardware load balancing is supported for load balancing Lync Server 2010 Edge Servers when using publicly routable IP addresses for the Edge external interfaces. For example, you would use this approach in situations where failover is required for any of the following applications:

  • Public IM connectivity

  • External access to Exchange 2007 Unified Messaging (UM) or Exchange 2010 UM

  • Federation with companies running Microsoft Office Communications Server 2007 or Microsoft Office Communications Server 2007 R2

  These three applications will continue to operate, but they are not DNS load balancing aware and will only connect to the first Edge Server in the pool. If that server is unavailable, the connection will fail. For example, if multiple Edge Servers are deployed in a pool to handle the federated traffic load, only one access proxy actually receives traffic while the others are idle.