Overview of Server Pooling for Instant Messaging

By creating a server pool, the number of users you can support in an Instant Messaging deployment is no longer constrained by the capacity of a single server system. Instead, you can use the resources of several systems to support the users in a single domain. In addition, server pools provide redundancy so that if one server in the pool fails, affected clients can reconnect and continue their sessions through another server in the pool with a minimum of inconvenience. Deploying more than one server in a server pool creates a multi-node deployment.

You create a server pool by configuring the Instant Messaging servers to communicate over the server-to-server port and get user data from the same LDAP directory. Once you have configured the servers, you need to configure the client resources to point to the load balancer, or load director, instead of a single node's host and port.

While it is possible to use a shared file system instead of an LDAP directory to store user properties, doing so negatively impacts performance and manageability. For this reason, only LDAP storage is supported for server pools.

In order to ensure that all servers within a server pool have consistent data, the following information is replicated among all servers in the pool:

• Routing information for end users

• Conference membership and configuration

• Multiparty conference messages

The following information is not replicated:

• One on one chat messages

• Presence subscriptions and notifications

In addition, if you are enforcing policy through access control files in your deployment, the content of the access control files must be the same among all servers in a server pool. See Managing Policies Using Access Control Files for more information.