An HLB is required for every Enterprise pool. The HLB is an important element of the redundancy story offered by Enterprise Edition. An Enterprise pool contains one or more front-end servers that perform the same function. Therefore, clients can connect to any of the available front-end servers. It is important that the client does not need to know which front-end server it should connect to. By using an HLB, clients connect to a single FQDN, and the HLB determines which front-end server should service the request based on availability and workload. After the HLB routes a client’s connection to a particular front-end server, the HLB must be capable of routing all traffic from that client to the same front-end server for the duration of the user’s session.

At the time of this writing, Microsoft has tested and supports Office Communications Server 2007 R2 with the following HLBs (see the section titled "Additional Resources" at the end of this chapter for the link):

Destination NAT (DNAT) and Source NAT (SNAT) are two methods of applying the network address translation in devices such as HLBs. The difference between the two, like the name implies, is what the translation rewrites. In DNAT, the destination address (or target) is rewritten to comply with the rules of the translator. SNAT rewrites the source address (or sender). Both rewrites occur at the IP layer, ensuring that the sender can respond to the correct address.

However, DNAT is much more difficult to set up and configure properly. DNAT has been supported in Office Communications Server in the past but is no longer supported in Office Communications Server 2007 R2 due to the overall complexity of implementing DNAT. If your load balancer is currently using DNAT, you must convert the ports that the Office Communications Server systems are using to SNAT.

You must configure a static IP address for the VIP address of the HLB. The HLB must be configured with the static IP address of each front-end server of the Enterprise pool to load balance. For more information about how to configure the specific HLB of your choice, see the Partner Documentation section at http://go.microsoft.com/fwlink/?LinkID=133669 and the upcoming section in this chapter, "Port and Protocol Configuration Considerations for Hardware Load Balancers."

Finally, you must publish the FQDN of the Enterprise pool in DNS. An A record must be defined for the pool FQDN, and the IP address to match to this FQDN should be the IP address of the HLB’s VIP.

This will result in a new Host (A) record being created in DNS for the FQDN of the VIP for the Enterprise pool.

Figure 4-23. Publishing an Enterprise pool in DNS

Verify that you configured the HLB with this IP address and make sure you can resolve the pool’s FQDN. You can easily do this by performing a ping command. To do this, open a command prompt window and type ping <pool fqdn>.

The pool’s FQDN is automatically defined once you specify the pool name. It is composed of the name specified in the Pool Name field and the domain’s name shown in the Domain field in the Create Enterprise Pool Wizard. This is shown in Figure 4-24.

Figure 4-24. Create Enterprise Pool Wizard

The pool name can be any value you select, as long as it does not conflict with the name of an existing pool. The pool name gets populated as the CN of the pool object and the value of the msRTCSIP-PoolDisplayName attribute.

The SQL Server instance is parsed, and the server name portion is stored in the msRTCSIPBackEndServer attribute. By default, if no instance name is supplied, the instances created are called RTC, RTCDYN, and RTCCONFIG. It is recommended not to specify any instance name when creating a new pool. The RTC database contains user and pool information synchronized from Active Directory. The RTCDYN database stores transient information, such as subscriptions, endpoints, and publications. The RTCCONFIG database contains pool-level configuration settings specific to the Enterprise pool.

Port and Protocol Configuration Considerations for Hardware Load Balancers

To properly configure your HLB for the Enterprise pool, it’s helpful to understand the network traffic into the servers of an Enterprise pool. This background information makes it easier to optimize your HLB for Office Communications Server, Enterprise pool.

Understanding the network flow of servers is important as you begin to configure your HLB and any internal firewall that protects the servers within the Enterprise pool. The HLB primarily serves to distribute client SIP requests across all of the front-end servers. The HLB also serves to source NAT the network connections from the IM, Telephony, Web, and A/V Conferencing Servers (referred to as MCUs) to the Focus and MCU Factory. The Conferencing Servers can connect to any Focus running on each of the front-end servers because the conference information used by the Focus resides on the back-end server. Therefore, any Focus element can service the Conferencing Server request. Consequently the Conferencing Server must connect to the front-end servers, where the Focus runs, through the HLB to take advantage of the load-balancing functionality. This design provides more scalability and reliability.

In the case of an Enterprise pool in consolidated configuration, as shown in Figure 4-25, the Conferencing Server components reside on the front-end servers, and the load-balanced network connections need to appear as if they are originating from a server on a different subnet. This requires that the HLB support SNAT. SNAT provides the ability to translate the source IP address of the originating server to one that is owned by the HLB that supports the server-to-server network connections between different Office Communications Server 2007 R2 components residing on the same physical servers. Figure 4-26 illustrates information needed to resolve these same requirements for an expanded configuration.

Figure 4-25. Network protocols and communication flows for an Enterprise pool in consolidated configuration

Figure 4-26. Network protocols and communication flows for an Enterprise pool in expanded configuration

Table 4-2 describes the ports and protocols that will need to be configured on the load balancers to allow for the traffic that will be sent to and from the servers and services that the load balancer is hosting. For example, a client’s computer that needs to connect to a pool server behind the load balancer will need to connect on port 5061/TCP. Table 4-2 indicates this configuration in the first entry.

Table 4-2. Configuration Settings for Hardware Load-Balancer Ports

PORT REQUIRED	SOURCE	DESTINATION	DESCRIPTION
TCP 5061	Client PC	VIP for pool	Client IM traffic encrypted via SIP/TLS
TCP 4441	Front-end server actual IP	VIP for pool	Conference MCUs to Focus and MCU Factory to track health and schedule meetings
TCP 443	Client PC	VIP for pool	Web Components Server traffic (HTTPS) to download content for meetings
TCP 8057	Client PC	Web Conferencing Server	Web Conferencing MCU traffic (SIP/TLS) for meetings
User Datagram Protocol (UDP) 135	Admin PC	Front-end server actual IP	Distributed Component Object Model (DCOM) traffic for Office Communications Server 2007 R2 Admin tool
UDP 49152 – 65535	Client PC	A/V Conferencing Server	A/V Conferencing Server traffic