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.
Only HLBs are supported for Office Communications Server 2007 R2. The Network Load Balancer component in Windows Server 2003 or Windows Server 2008 is not a supported option to meet this requirement.
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):
F5 Big-IP
Nortel Application Switch (NAS)
CAI Networks WebMux
Foundry Networks ServerIron
Cisco Application Control Engine (ACE)
Citrix Netscaler
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.
Select Start and select Administrative Tools.
Select DNS.
Right-click your domain’s node under Forward Lookup Zones.
Select New Host (A).
Enter the Enterprise pool’s FQDN in the Name field of the New Host dialog box, as shown in Figure 4-23.
This will result in a new Host (A) record being created in DNS for the FQDN of the VIP for the Enterprise pool.
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.
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.
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
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 |
18.191.237.176