Reference Architecture
Topic Last Modified: 2012-10-15
Three reference architectures are provided to highlight the Microsoft Lync Server 2010 communications software topologies that have been tested and are therefore supported. There are two primary Edge topologies and one alternate:
Primary – Reference Architecture 1: Single consolidated Edge using network address translation (NAT)
For details, see Reference Architecture 1: Single Consolidated Edge.
Primary – Reference Architecture 2: Scaled consolidated Edge using NAT and Domain Name System (DNS) load balancing
For details, see Reference Architecture 2: Scaled Consolidated Edge (DNS Load Balanced).
Alternate – Reference Architecture 3: Scaled consolidated Edge using public IP and hardware load balancing
For details, see Reference Architecture 3: Scaled Consolidated Edge (Hardware Load Balanced).
The recommended approach for deploying Lync Server 2010, Edge Server is to use the Planning Tool to generate an input file for Topology Builder. The reference architectures in this section are not a replacement for that process, but instead are a set of drawings and tables designed to assist with it.
For best results, use the topology flowchart in Defining Your Requirements for External User Access to select a topology and then review the reference architecture section that corresponds to it. The assumptions in the following section apply to all three topologies, and you should review them first.
Assumptions
There are a number of network and environmental factors that can affect Edge Server performance. The reference architectures are designed using best practices to help prevent common configuration issues and are based on the assumptions defined in the following list. If you choose a different configuration (for example, a three-leg perimeter network), you may still be able to make it work, but it is not a configuration that has been tested or supported.
Dedicated perimeter network (also known as a DMZ, demilitarized zone, and screened subnet) with internal and external firewalls.
Lync Server 2010 supports virtualization of Edge servers but the reference architectures assume physical servers are used.
Two network interface cards (NICs) configured as follows:
Edge internal interface is on a different network than the Edge external interface.
The Edge external interface NIC has three IP addresses bound to it (that is, Access, Web Conferencing and A/V, with the Access IP address set to primary and the other two IP addresses set to secondary).
Only one default gateway is configured and it is assigned to the Access Edge external interface and pointed to the external firewall's IP address.
The NIC for the Edge external interface and the NIC for the Edge internal interface are on two separate networks that do not have routing configured between them.
Windows Server 2008 strong host model is used on all Edge Servers. For details, see "The Cable Guy: Strong and Weak Host Models" at https://go.microsoft.com/fwlink/p/?LinkId=178004
Director is not shown for simplicity but a Director would typically be deployed to reduce the risk of a denial-of-service (DoS) attack.
There is a route from the network containing the Edge internal interface to any networks that contain Lync 2010 clients or servers running Lync Server 2010.
Split-brain DNS (that is, the same domain hosted on internal and external DNS servers) is not used in the examples specifically to highlight the workarounds required for this configuration but typically it is deployed.
Edge servers are pointed to a DNS server in the perimeter because host files can be difficult to maintain.
All Edge external interfaces use either NAT, with destination IP addresses changed inbound and the source IP addresses changed outbound combined with DNS load balancing. Or, they use publicly routable IP addresses combined with hardware load balancing.
A hybrid configuration with Access Edge service and Web Conferencing Edge service behind NAT and the A/V Edge service configured with a publicly routable IP address, is not supported in Lync Server 2010.
Router and firewall functions are integrated into a single device and for reference, the Edge and reverse proxy server(s) in a perimeter network that is in between an external and internal integrated router/firewall.
Only a single reverse proxy server is shown but if there was a pool of reverse proxy servers deployed in the perimeter network, they would be load balanced using a hardware load balancer because DNS load balancing does not work with client to server web traffic.
After you have selected a topology and determined your certificate, port and DNS requirements, you can use one of the three reference architectures to see how a typical deployment will look. You should then be able to modify the existing tables with your production fully qualified domain names (FQDNs) and IP addresses and use them to assist with your production deployment.