Chapter 6 Scaling an Instant Messaging Deployment Using Server Pooling

Server pooling allows you to support millions of users within a single domain. Using a server pool, you can share a domain across several servers in a server pool. In addition, you can use a load balancer such as the redirect server to help manage server utilization in the pool. This chapter provides information on server pooling in the following sections:

For information on the load balancing and the redirect server, see Chapter 7, Optimizing an Instant Messaging Server Pool Using the Redirect Server. The procedures in this chapter assume you have already installed Instant Messaging on the hosts in your server pool. In addition, you need to install the Access Manager SDK on each node in the server pool, and configure the SDK to communicate with a single remote Access Manager server.

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.

Caution –

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.

Availability in an Instant Messaging Server Pool

If a node in a server pool goes down, all currently connected clients are disconnected and the sessions and resources become unavailable. If you set up your deployment with load balancers, users can immediately reconnect and be directed by a load balancer to another node in the pool. When they do so, they will not need to recreate conferences or news channels as this information is shared between servers in the pool. In addition, one-to-one chat sessions can be continued after the user is directed to another node in the pool.

Configuring Server-to-Server Communication Between Instant Messaging Servers in a Server Pool

This section describes how to enable communication between two Instant Messaging servers, or peers, in a server pool. You must configure all servers in the pool with information about all other servers in the pool.

Table 6–1 lists the parameters in iim.conf and their values used to set up communication for two example Instant Messaging servers in a server pool; iimA.siroe.com and iimB.siroe.com.

For more information on the configuration parameters, see Appendix A, Instant Messaging Configuration Parameters in iim.conf.

Table 6–1 Example Configuration Information for Two Instant Messaging Servers in a Server Pool


Parameter in `iim.conf`	Value for Server A	Value for Server B	Notes
`iim_server.serverid`	`iimA.siroe.com`	`iimB.siroe.com`	In a server pool, this ID is used to support the dialback mechanism and is not used for authentication. This value should be unique within the server pool.
`iim_server.password`	`secretforiimA`	`secret4iimB`
`iim_server.coservers`	`coserver1`	`coserver1`	Each Instant Messaging server is identified by its symbolic name. The symbolic name of the server is added in the `iim_server.coservers` parameter in `iim.conf`. This parameter may contain multiple, comma-separated values.
`iim_server.domainname`	`siroe.com`	`siroe.com`	Peer servers within a server pool share the same default domain.
`iim_server.coserver1.host`	`iimB.siroe.com:5269`	`iimA.siroe.com:5269`	The hostname and port number of the peer server in the server pool.
`iim_server.coserver1.serverid`	`iimB.siroe.com`	`iimA.siroe.com`	The server ID (`iim_server.serverid`) of the peer server in the server pool.
`iim_server.coserver1.password`	`secret4iimB`	`secretforiimA`	The password (`iim_server.password`) of the peer server in the server pool.
`iim_server.coserver1.domain`	`siroe.com`	`siroe.com`	Peer servers within a server pool share the same default domain.

To Set Up Communication Between Two Instant Messaging Servers in a Server Pool

Gather the information listed in Table 6–1.

Change to im-cfg-base on the server iimA.siroe.com.

See Instant Messaging Server Directory Structure for instructions on locating im-cfg-base.

Open iim.conf.

See Appendix A, Instant Messaging Configuration Parameters in iim.conf for instructions on locating and modifying iim.conf.

Note –
The iim.conf file should be owned by the Instant Messaging server account you created during installation. If the iim.conf file cannot be read by the Instant Messaging server account, the server and multiplexor will be unable to read the configuration. Additionally, you might lose the ability to edit iim.conf.

Modify the parameter values to match your deployment.

Table 8–1 lists the parameters you need to modify. If the parameters do not exist in iim.conf, add them. The following example shows the section of iim.conf on iimA.siroe.com corresponding to the server-to-server communications that you need to modify:

iim_server.serverid=iimA.siroe.com
iim_server.password=secretforiimA
iim_server.domainname=siroe.com
iim_server.coservers=coserver1
iim_server.coserver1.host=iimB.siroe.com:5269
iim_server.coserver1.serverid=iimB.siroe.com
iim_server.coserver1.password=secret4iimB
iim_server.coserver1.domain=siroe.com

Follow steps 2 through 4 for the iim.conf file on server iimB.siroe.com.

The following example shows the section of iim.conf on iimB.siroe.com corresponding to the server-to-server communications that you need to modify:

iim_server.serverid=iimB.siroe.com
iim_server.password=secret4iimB
iim_server.domainname=siroe.com
iim_server.coservers=coserver1
iim_server.coserver1.host=iimA.siroe.com:5269
iim_server.coserver1.serverid=iimA.siroe.com
iim_server.coserver1.password=secretforiimA
iim_server.coserver1.domain=siroe.com

Save the changes and close iim.conf.

Refresh the configuration on both servers.
imadmin refresh server

Adding a New Node to an Existing Instant Messaging Deployment

If you need to add an additional node to an existing server pool, you need to configure the new server for server-to-server communication and then add configuration information about the new server to all existing servers in the pool. In addition, you need to add configuration information about all the servers in the pool to the new node. See To Set Up Communication Between Two Instant Messaging Servers in a Server Pool for instructions.

Securing a Multi-node Deployment

When a node connects to a remote server, the node provides a dialback key. The remote server then connects back to the node in order to verify the dialback key. In a multi-node deployment, the remote server may connect back to a different node in the pool from the node that originally sent the dialback key. The node the remote server connects to must provide the same dialback key that the original connecting node supplied. The iim_server.dialback key configuration parameter defines which dialback key a node should use. The value for the dialback key is randomly generated unless you explicitly specify one. See To Manually Define the Dialback Key for an Instant Messaging Server in a Server Pool for instructions.

The From attribute is used by a remote server to connect back to an initiating server. Typically, a server's domain name is used as the value for the From attribute in server-to-server communication under Jabber. However, all servers in a server pool share the same domain name. Therefore, the domain name cannot be used as a key to locate a single server in a pool. Instead, Instant Messaging uses a server or peer identifier (serverid) instead of the domain name as the value for the From attribute.

To Manually Define the Dialback Key for an Instant Messaging Server in a Server Pool

The value for the dialback key is randomly generated unless you explicitly specify one.

Open iim.conf.

See iim.conf File Syntax for instructions on locating and modifying iim.conf.

Modify the value of the iim_server.dialback.key parameter.

For example:
iim_server.dialback.key=mymultinodedialbackkey

Save the changes and close iim.conf.

Refresh the configuration on both servers.
imadmin refresh server