Microsoft Office Communications Server2007R2
Scale to a Load Balanced Edge Server Walkthrough
Published: July 2009
Updated: October 20098
Updated: April 2010
For the most up-to-date version of the Scale to a Load Balanced Edge Server Walkthrough documentation and the complete set of the Microsoft® Office Communications Server 2007 R2 online documentation, see the Office Communications Server TechNet Library at
Note: In order to find topics that are referenced by this document but not contained within it, search for the topic title in the TechNet library at
1
This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
Copyright © 2010 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Outlook, SQL Server, Visio, Visual C++, Windows, Windows Media, Windows PowerShell, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.
1
Contents
Scale to a Load Balanced Edge Server Walkthrough
Walkthrough: Plan for Scaling Edge Servers
Walkthrough: Supported Topologies for Load Balanced Edge Servers
Walkthrough: Enabling Load Balancer Routing (Two-Armed Only)
Walkthrough: Configuring New Edge Servers
Setup Reverse Proxy Servers
Setup Edge Servers
Walkthrough: Validating New Edge Servers
Walkthrough: Installing and Configuring Load Balancers for Edge Servers
Connect and Configure Reverse Proxy Load Balancer
Connect and Configure External Edge Load Balancer
Connect and Configure Internal Edge Load Balancer
Walkthrough: Validating Load Balancers for Edge Servers
Walkthrough: Decommissioning Non-Load Balanced Edge Servers
1
Scale to a Load Balanced Edge Server Walkthrough
Many enterprises begin their Office Communications Server deployment with a Edge environment that is not load balanced, consisting of a single consolidated Edge Server and a single reverse proxy. As the organization’s use of the product becomes increasingly mission critical, it is common to move this to a load balanced configuration to provide high availability and increased capacity. This section describes the procedure for migrating from a single reverse proxy and consolidated Edge Server to a load balanced reverse proxy array and consolidated Edge Server array.
In This Document
Walkthrough: Plan for Scaling Edge Servers
Walkthrough: Supported Topologies for Load Balanced Edge Servers
Walkthrough: Enabling Load Balancer Routing (Two-Armed Only)
Walkthrough: Configuring New Edge Servers
Walkthrough: Validating New Edge Servers
Walkthrough: Installing and Configuring Load Balancers for Edge Servers
Walkthrough: Validating Load Balancers for Edge Servers
Walkthrough: Decommissioning Non-Load Balanced Edge Servers
Walkthrough: Plan for Scaling Edge Servers
To switch from a consolidated Edge server and reverse proxy to load balanced arrays, you perform the following steps:
The first step is to bring up the new Edge and reverse proxy servers that you want to use in the new load balanced environment. Until you change Domain Name System (DNS) entries, all users continue to use the existing non-load balanced servers. This allows you to test the new servers individually by using a few host file changes, ensuring minimal downtime and service-level agreement (SLA) risk. Because Edge servers are assigned at a pool level you need a test pool availability to validate the new Edge environment. (This could be a Standard Edition server because you are only using it for testing purposes.)
After you have validated the individual Edge servers, the next step is to configure the load balancer VIPs in front of these new servers. Again, the corporate and public DNS records have not been touched, so end users are still using the existing Edge infrastructure. With some additional host file record changes, you can now test the load balanced environment and validate behavior associated with testing failover on each of the Edge servers.
After you have validated the load balancing behavior, you can cut over to this new environment by removing the host file entries and changing the correct DNS entries in your production environment. The benefit of this methodology is that you can fully validate the load balanced environment before it goes live and have the option of quickly reverting to the non-load balanced servers in case something goes awry after the cut over. When the new configuration is operating smoothly, you can decommission the non-load balanced servers. The rest of this section describes each phase of this process in detail.
One thing you need to consider is whether it is absolutely necessary to load balance the reverse proxy. This depends on the types of services being exposed by the reverse proxy. For instance, if the reverse proxy is only exposing the Office Communications Server web components, a temporary outage would impact the download of address book, DL expansion, and meeting content. Your end users may not notice a temporary outage of these services. However, if the reverse proxy is exposing Communicator Web Access and Exchange services, high availability is probably more critical. Evaluate your company’s needs and decide accordingly.
Walkthrough: Supported Topologies for Load Balanced Edge Servers
This topic defines two sample topologies to illustrate specific steps that are involved in moving to a load balanced edge configuration. The following diagrams illustrate these topologies: Figure 1 illustrates a one-armed topology, and Figure 2 illustrates a two-armed topology. These are the only two topologies that are supported in Office Communications Server 2007 R2. Note that the IP addresses of the corresponding servers in both diagrams are the same. The key difference is the networking topology and routing. In particular, notice the difference in subnets between the two diagrams.
Figure 1. One-armed edge topology
Figure 2. Two-armed edge topology
Your networking team may have an existing best practice for deploying load balanced services, which will probably have the biggest impact on which option you choose. If no precedent exists, following are factors to consider when you are deciding between a one-armed or two-armed topology:
One-armed topology. A one-armed topology is easier to deploy from a networking perspective because the load balancers can reside on the existing networks without requiring any additional changes in routing. However, not all traffic goes through the load balancer VIP, such as media between clients and the A/V Edge Server. If one function of the load balancer is to be a firewall for the Edge Servers, this topology will not be sufficient. One benefit of this topology is that testing the Edge Server functionality independent of the load balancer is easier because there is no dependency on the routing functionality of the load balancer.
Two-armed topology. In a two-armed topology, the Edge Server and reverse proxy server reside behind the load balancers on private networks. The intent is to abstract these servers away from the internal and external perimeter networks. This is possible with the reverse proxies, since only HTTP traffic is being handled. However, the Edge Servers cannot truly be hidden by the load balancer VIPs alone because clients on the Internet and corporate networks need to contact the A/V Edge Server directly to establish media. In addition, the Access Edge Server and A/V Edge Server need to be able to initiate connections out to the Internet for federation. This means that the load balancers that are servicing both the internal and external sides Edge Server interfaces must actually route packets in both directions. It also means that the internal private edge networks must use an IP address range that is routable from within the corporation and the external private edge network must use an IP address range that is publically routable from the Internet. This topology enables the load balancer to be a single point of entry for all packets to and from the Edge Servers, so you can perform firewall functionality in the two-armed topology. Remember that the networking load is considerably higher in the two-armed topology because all traffic destined for the Edge Servers goes through the load balancer.
Walkthrough: Enabling Load Balancer Routing (Two-Armed Only)
Important:
If you are using a one-armed topology, the load balancer does not need to be in place before installing and testing the Edge Servers. You can skip this step and proceed to Walkthrough: Configuring New Edge Servers.
If you are using a two-armed load balancer topology, you need to enable routing between the perimeter and edge networks. There are three distinct load balancer usages, but only two require routing. Depending on the type of load balancer, you may be able to use a single piece of hardware for all three usages. For details, check your model.
Edge External. Connect the load balancer to the perimeter external and edge external networks and configure the appropriate IP addresses. Then, enable routing between these two networks. Do not configure any VIPs at this stage.
Edge Internal. Connect the Load Balancer to the perimeter internal and edge internal networks and configure the appropriate IP addresses. Then enable routing between these two networks. (Do not configure any VIPs at this stage.)
After you have confirmed routing, you can move forward with installing and testing each Edge Server and reverse proxy server.
Walkthrough: Configuring New Edge Servers
Before you setup your Edge Servers, you need to obtain the correct certificates that you will use when configuring the Edge Servers. Following is a list of the certificates:
1.Access Edge External (Public Certificate). In our sample topology, the subject name and subject alternative name (SAN) would be set to sip.contoso.com, the fully qualified domain name (FQDN) of the Access Edge Server external interface.
2.Web Conf External (Public Certificate). In our sample topology, subject name would be set to webconf.contoso.com, the FQDN for the Web Conferencing Edge Server external interface.
3.Access Edge Internal (Corporate Certificate). In our sample topology, the subject name would be set to ocsedge.contoso.com, the FQDN of the Edge Server internal interface.
4.A/V Authentication Internal (Corporate Certificate). In our sample topology, the subject name would be set to ocsedge.contoso.com, the FQDN of the Edge Server internal interface.
5.Reverse Proxy External. In our sample topology, the subject name would be set to ocsweb.contoso.com, the FQDN of the reverse proxy listener that handles the Office Communications Server Web components.
These certificates come with an exportable private key, so keep them in a secure location. When importing into the relevant reverse proxy or Edge Servers, set the private key as non-exportable. This ensures that if one of your servers is compromised, an attacker will not be able to transfer the certificate to another computer.
Setup Reverse Proxy Servers
First, setup your two reverse proxy servers. Follow the setup instructions for your particular reverse proxy to set up the appropriate Web listeners. Then, assign the Web certificate(s) that you obtained previously. Be sure to import the root certificate of the corporate certification authority (CA), because the reverse proxy will establish Transport Layer Security (TLS) connections to servers within the corporation that have been issued by the corporate CA.
Setup Edge Servers
Next, set up your new Edge Servers that you want to use in the load balanced array. To do this, follow the Edge Server installation procedure. In our example, this involves the following:
1.Obtain a new physical server, and install the pre-requisite Windows Server operating system for Office Communications Server 2007 R2. Ensure that the server has two physical network interface cards (NICs).
2.Name the machine ocsedge01.
3.On the external NIC, assign it the following three IP addresses: 128.95.1.41, 128.95.1.51, and 128.95.1.61. Assign the proper subnet and default gateway according to the topology diagram.
4.On the internal NIC, assign the IP address: 172.24.1.41.
5.Import the root certificate of the corporate network along with the four Edge Server certificates that you obtained earlier.
6.Run the Office Communications Server 2007 R2 Enterprise Edge Server installation.
7.Install files for Office Communications Server 2007 R2.
8.Assign the appropriate certificates and associate the IP addresses to the corresponding services on the Edge Server.
9.Add your production pool and test pool FQDNs to the trusted server list.
10.Set a static IP route for all traffic destined for the corporate network 10.0.x.x/16 to route through the internal interface.
11.In a one-armed topology, set the default gateway to the external firewall IP address (that is, 128.95.0.1). In a two-armed topology, set the default gateway to the Load Balancer (that is, 128.95.1.1).
12.Set the next hop to be your test pool.
13.Start all services.
14.Repeat the previous steps on the second Edge Server ocsedge02, using the corresponding IP addresses for the second Edge Server.
Ensure that the following requirements are maintained:
The A/V Edge Server external IP addresses needs to be routable from the public Internet.
The A/V Edge Server internal IP address needs to be routable from the corporate network.
Walkthrough: Validating New Edge Servers
At this stage, you have configured two additional Edge Servers that are fully configured. Although no load balancer VIPs are in place, the Edge Servers are fully functional and able to handle Office Communications Server workloads. In this section, you validate basic functionality of your two new Edge Servers. By doing so, when you add the load balancer, you can focus your troubleshooting on the load balancer. This testing will not affect your production users.
If you are using a one-armed topology, the load balancer does not need to be in place to perform this testing. However, if you are using a two-armed load balancer topology, you need to enable routing between the perimeter networks and the private edge networks for this testing to succeed.
To perform this testing, first add a temporary hosts file entry on your Office Communications Server test pool, pointing the fully qualified domain name (FQDN) of the internal Office Communications Server Edge Server to the IP address of the particular Edge Server you test first. Then, configure the test pool with the corresponding FQDNs for your Edge Server. For example, in our sample topology:
1.On ocsstd.contoso.com, add a hosts file entry resolving ocsedge.contoso.com to 172.24.1.41.
2.On ocsstd.contoso.com, configure ocsedge.contoso.com as the Access Edge Server, webconf.contoso.com as the Web Conferencing Edge Server, and av.contoso.com as the A/V Edge Server.
3.In a command window, run ipconfig /flushdns to clear the Domain Name System (DNS) cache.
4.Restart all services on the Front End Server to ensure that they use the updated IP address.
Next, prepare three test workstations with the Office Communicator, Outlook, and Live Meeting clients, and perform the following:
1.Add hosts file entries on each client resolving sip.contoso.com to 128.95.1.41, webconf.contoso.com to 128.95.1.51, av.contoso.com to 128.95.1.61, and ocsedge.contoso.com to 172.24.1.41.
2.In a command window, run ipconfig /flushdns to clear the DNS cache.
3.In Office Communicator, configure connection settings to Manual, specifying ocsstd.contoso.com as the internal server name and sip.contoso.com as the external server name.
4.In the Live Meeting Client, configure the Office Communications Server to Manual, specifying ocsstd.contoso.com as the internal server name and sip.contoso.com as the external server name.
5.Using the test clients located on a combination of the Internet and the corporate networks, log on to Office Communicator by using some test accounts homed on the Standard Edition server and verify all peer-to-peer (P2P) and conference modalities work. This includes instant messaging (IM), voice, video, and desktop sharing.