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
Important
The internal Edge interface and external Edge interface must use the same type of load balancing. You cannot use DNS load balancing on one Edge interface and hardware load balancing on the other Edge interface.
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
| Topology | High availability | NAT/Public IP address type | Additional external DNS A record required for each Edge Server in the Edge pool | Edge Failover for Lync-to-Lync sessions* | Edge Failover for Lync-to-Lync EUM/PIC/OCS Federation sessions |
|---|---|---|---|---|---|
Single Edge |
No |
NAT optional / public or private IP addresses |
No |
No |
No |
Scaled Edge (DNS load balanced) |
Yes |
NAT optional / public or private IP addresses |
Yes |
Yes |
No (Yes for Exchange UM with Exchange Server 2010 with SP1 or later configured to use DNS Load Balancing) |
Scaled Edge (hardware load balanced) |
Yes |
NAT not used / public IP mandatory |
No (only one per VIP) |
Yes |
Yes |
* Failover for Exchange UM (remote user), public instant messaging (IM) connectivity, and federation with servers running Office Communications Server.
Note
The NAT/Public IP required and Additional external DNS A record required for each Edge Server in the Edge pool columns pertain only to the Edge external interfaces. Single Edge and Scaled Edge (DNS load balanced) topologies can use routable public IP addresses, or can use non-routable private IP address. If you decide to use non-routable private IP addresses, you must use it on all three external interfaces. Additionally, you must configure symmetric NAT for incoming and outgoing traffic. Scaled Edge (hardware load balanced) topology must use public IP addresses.
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)
| Number of Edge Servers per pool | Number of required IP addresses Lync Server 2010 (DNS load balanced) | Number of required IP addresses Lync Server 2010 (hardware load balanced) |
|---|---|---|
2 |
6 |
3 (1 per VIP) + 6 |
3 |
9 |
3 (1 per VIP) + 9 |
4 |
12 |
3 (1 per VIP) + 12 |
5 |
15 |
3 (1 per VIP) + 15 |
IP Address Requirements for Scaled Consolidated Edge (Single IP address for all roles)
| Number of Edge Servers per pool | Number of required IP addresses Lync Server 2010 (DNS load balanced) | Number of required IP addresses Lync Server 2010 (hardware load balanced) |
|---|---|---|
2 |
2 |
1 (1 per VIP) + 2 |
3 |
3 |
1 (1 per VIP) + 3 |
4 |
4 |
1 (1 per VIP) + 4 |
5 |
5 |
1 (1 per VIP) + 5 |
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.
Important
Using DNS load balancing is recommended if you are federating with companies using Lync Server 2010. Be aware that there are significant performance impacts if most of your federated partners are using Office Communications Server 2007 or Office Communications Server 2007 R2.