Udostępnij za pośrednictwem

  • Artykuł

Using a Load Balancer to Increase Capacity and Availability

Topic Last Modified: 2009-01-22

A single server running Communicator Web Access (2007 R2 release) can handle approximately 5,000 simultaneous connections. If you need to support more users than that, you will need more than one Communicator Web Access server. If you need more than one Communicator Web Access server, you will probably want to deploy a hardware load balancer to help ensure that the workload is equitably distributed between those servers.

Note

In addition to increasing the overall capacity of your Communicator Web Access infrastructure, by using an array of servers and a load balancer you can increase the reliability and availability of Communicator Web Access. Should a single server fail, the load balancer can automatically route incoming connection requests to the servers that are still functioning.

Communicator Web Access requires session affinity, a requirement that directly impacts load balancing. Session affinity simply means that a given Communicator Web Access session must take place on the same server. Communicator Web Access does not allow an instant messaging session to begin on one server and then somehow be transferred to another server. If a user is logged on to Server A at the beginning of his or her Communicator Web Access session, he or she will continue to use Server A for the duration of that session. If Server A should fail, the user will have his or her session terminated. (That user can then sign on again, and the load balancer will route them to a server that is still running.) However, users connected to Server B or Server C will not have their session disrupted in any way should Server A fail.

This explains why you must use hardware load balancing with Communicator Web Access. Software load balancing can also equally distribute connection requests among servers. However, if Server A fails, a software load balancer will redistribute all the client connections, including those clients on Server B and Server C. As a result, not only will users on Server A lose their connections, but many users on Server B and Server C will lose their connections as well.

Note

As noted, software load balancing is not supported on Communicator Web Access. In addition, Communicator Web Access does not support any type of load balancing scenario involving multi-homed network adapters or computers equipped with more than one network adapter and more than one default gateway.

Communicator Web Access supports most hardware load balancers, provided that the load balancer:

  • Allows you to set the TCP idle timeout to 1,800 seconds (30 minutes). The TCP idle timeout represents the amount of time the server will wait for information during a session. If you are using a reverse proxy server (such as Microsoft Internet Security and Acceleration Server) then the TCP idle timeout on that computer should also be set to 1,800 seconds.
  • Allows you to use a source network address translation (SNAT) pool if you need to handle more than 65,000 simultaneous connections. SNAT is designed to “hide” multiple servers behind a single IP address (that is, a number of servers can be accessed using just one IP address). With a SNAT pool, servers can be hidden behind multiple IP addresses.
  • Allows you to use cookie persistence when configuring session affinity. With cookie persistence, information about the actual Communicator Web Access server being used for a session is stored in an Internet cookie on the client computer. When configuring the load balancer’s session persistence profile it is recommended that you use “HTTP Cookie Insert.” With this configuration method, information about the server to which the client is connected is inserted in the header of the HTTP response from that server as a cookie.

Communicator Web Access also supports Secure Sockets Layer (SSL) acceleration on the load balancer. With SSL acceleration, the load balancer decrypts HTTPS transmissions before sending that unencrypted traffic to the Communicator Web Access server. Relieving the server of the need to perform SSL decryption can markedly improve that server’s performance.

Communicator Web Access should always have a dedicated load balancer. You should not share a load balancer between Office Communications Server and Communicator Web Access server.