Load Balancers for Office Communications Server 2007 R2
Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 will reach end of support on January 9, 2018. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
A hardware load balancer is required in an Enterprise pool with more than one Enterprise Edition server. A load balancer is not required for a Standard Edition server or a single Enterprise Edition Front End Server. A load balancer is required, for arrays of Office Communications Server 2007 R2 Edge Servers. The load balancer performs the critical role of delivering scalability and high availability across multiple servers connected to a centralized database on the Office Communications Server 2007 R2, Back-End Database.
Prerequisites for a Load Balancer Connecting to a Pool
Before configuring a load balancer to connect to the Office Communications Server 2007 R2 Enterprise pool, you must configure the following:
A static IP address for servers within your pool.
For each server within the pool, a certificate issued for server authentication by a certification authority in the pools local domain.
A virtual IP (VIP) address and a DNS record for the load balancer.
Test users created and SIP-enabled in the pool.
Install root certificate from the certification authority (CA) in the domain (or trusted CA) on client computers.
Log on to all servers in the pool using TLS to ensure certificates are working.
Load Balancer Requirements
A load balancer for the Office Communications Server 2007 R2 Enterprise pool must meet the following requirements:
Must expose a VIP Address through ARP (Address Resolution Protocol).
The VIP must have a single DNS entry, called Pool FQDN.
The VIP must be a static IP address.
Must allow multiple ports to be opened on the same VIP. Specifically, it must expose the ports described in the following table.
Ports Required Port Use
SIP communication over TCP.
SIP communication over TLS.
To move users from a pool and other remote DCOM-based operations.
HTTPS traffic to the pool URLs.
Communication between the focus (Office Communications Server 2007 R2 component that manages conference state) and the conferencing servers.
SIP listening requests for Application Sharing.
SIP listening requests for Response Group Service.
SIP listening requests for Conferencing Attendant.
SIP listening requests for Conferencing Announcement Server.
SIP listening requests for Outside Voice Control.
TLS (remoting over MTLS) listening for inter-server communications for Response Group Service.
The load balancer must provide TCP-level affinity. This means that the load balancer must ensure that TCP connections can be established with one Office Communications Server 2007 R2 in the pool and all traffic on that connection destined for that same Office Communications Server 2007 R2.
The load balancer must provide a configurable TCP idle-timeout interval with a maximum value greater than or equal to the minimum of the REGISTER refresh or SIP Keep-Alive interval of 30 minutes.
The load balancer should support a rich set of metrics (round robin, least connections, weighted, and so forth). A weighted least connections-based load balancing mechanism is recommended for the load balancer. This means that the load balancer will rank all Office Communications Servers 2007 R2 based on the weight assigned to them and the number of outstanding connections. This rank will then be used to pick the Office Communications Server 2007 R2 to be used for the next connection request.
The load balancer must be able to detect Office Communications Server 2007 R2 availability by establishing TCP connections to either port 5060 (SIP over TCP), 5061 (SIP over TLS), and 444 (conferencing over HTTPS), depending on which is active (often called a heartbeat or monitor). The polling interval must be a configurable value with a minimum value of at least five seconds. The load balancer must not select an Office Communications Server 2007 R2 that shuts down until a successful TCP connection (heartbeat) can be established again.
Network adapters must have exactly one static IP address. This IP address will be used for the incoming load-balanced traffic.
The computer must have a registered FQDN. The IP address registered for this FQDN must be publicly accessible from within the enterprise.
The load balancer must allow for adding and removing servers to the pool without shutting down.
The load balancer must be NAT (network address translation) capable.
When you configure the load balancer, you need to request the relevant network and DNS administrator for a VIP (virtual IP) address for the load balancer, as well as a static IP address for every server that you plan to deploy in the Enterprise pool.
Supported Load Balancer Configurations
Most load balancers can be configured to support Network Address Translation (NAT) using one of the following modes:
Full-NAT mode (also known as proxy, secure NAT, source NAT, or SNAT mode). In full-NAT mode, both the source and IP destinations are changed as packets pass through the load balancer.
Half-NAT mode (also known as transparency, destination NAT or DNAT mode). In half-NAT mode, the destination IP address is changed as packets pass through the load balancer, but the source IP address remains intact.
Load balancing using Direct Server Return configuration is not supported.
The following table describes the supported configurations for full-NAT and half-NAT modes.
|Load-Balanced Pools||Supported NAT Modes||Notes|
Enterprise pools and Communicator Web Access
Half-NAT is not supported for load balancing of internal pools because inter-server communications within an internal pool fail when servers in the pool try to connect to their own VIP
The VIP for the external interface of Edge Servers should be set to half-NAT or full-NAT only for traffic to the edge (for each VIP that is used for Edge Servers and HTTP). Also, NAT is not supported for the IP address of the external interface of the A/V Edge Server of an Edge Server, so the IP address of the external interface of the A/V Edge service on each Edge Server must be publicly routable (no NAT).
For details about load balancing pools, see Enterprise Edition in the Planning documentation. For details about load balancing Edge Servers, see External User Access Components in the Planning documentation. For details about load balancing Communicator Web Access, see Communicator Web Access Support in the Planning documentation. For details about Directors, see Director Component in the Supported Topologies and Infrastructure Requirements documentation. For details about load balancing support in Office Communications Server 2007 R2, see Environmental Requirements in the Supported Topologies and Infrastructure Requirements documentation.