9 Scaling Instant Messaging Server By Using Server Pooling

This chapter describes how to scale an Oracle Communications Instant Messaging Server deployment by using server pooling. It assumes that you have already installed Instant Messaging Server on the hosts in your server pool.

Overview of Server Pooling for Instant Messaging Server

Server pooling enables you to support millions of users within a single domain. By using a server pool, you can share a domain across several servers in a server pool. In addition, you can use a load balancer to help manage server utilization in the pool.

By creating a server pool, the number of users you can support in an Instant Messaging Server 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.

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
Multi-party conference messages

The following information is not replicated:

One-on-one chat messages
Presence subscriptions and notifications

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 Instant Messaging Server Security Guide 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 do 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

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 9-1 lists the configuration properties 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 properties, see "Configuration Properties".

Table 9-1 Example Configuration Information for Two Instant Messaging Servers in a Server Pool

Property	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	None
iim_server.domainname	siroe.com	siroe.com	Peer servers within a server pool share the same default domain.

Note:

When open federation is enabled, do not use the host name as the server ID. For example, the property iim_server.serverid should not be set to host name.

You define coserver properties by running the imconfutil add-coserver command. The add-coserver property enables you to set the server ID, the password used to authenticate for this coserver, the coserver host name, the domain server used by the coserver, and whether SSL is required.

After setting the coserver property, you can retrieve it by using the imconfutil get-coserver-prop command. If you need to modify an existing coserver property, use the imconfutil set-coserver-prop command. To remove a coserver, use the imconfutil delete-coserver command. If you need to verify the password of a coserver, use the imconfutil verify-coserver-pass command. To see a listing of all configured coservers, use the imconfutil list-coservers command.

For more information on coserver configuration, see "To Set Up Communication Between Two Instant Messaging Servers in a Server Pool".

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

The following example shows how to set up coservers im1.example.com and im2.example.com.

Perform the following commands on host1 (im1.example.com).

Set the iim_server.serverid and iim_server.password configuration properties.

imconfutil set-prop -c /opt/sun/comms/im/config/iim.conf.xml iim_server.serverid=peer1.im1.example.com iim_server.password=peer1

Add the coserver (im2.example.com).

imconfutil add-coserver -c /opt/sun/comms/im/config/iim.conf.xml id=coserver1 serverid=peer2.im2.example.com password=peer2 host=im2.example.com domain=example.com

Perform the following commands on host2 (im2.example.com).

Set the iim_server.serverid and iim_server.password configuration properties.

imconfutil set-prop -c /opt/sun/comms/im/config/iim.conf.xml iim_server.serverid=peer2.im2.example.com iim_server.password=peer2

Add the coserver (im1.example.com).

imconfutil add-coserver -c /opt/sun/comms/im/config/iim.conf.xml id=coserver1 serverid=peer1.im1.examnple.com password=peer1 host=im1.example.com domain=example.com

Restart Instant Messaging Server on both hosts.
```
imadmin refresh server
```

Adding a New Node to an Existing Instant Messaging Server 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 property 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 Server 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.

Use the imconfutil command to modify the value of the iim_server.dialback.key configuration property.

For example:
```
imconfutil -c /opt/sun/comms/im/config/iim.conf.xml iim_server.dialback.key=mymultinodedialbackkey
```
Refresh the configuration on both servers.
```
imadmin refresh server
```

Using Shoal for Server Pool Messaging

Instant Messaging Server uses Shoal, a Java technology-based scalable and dynamic clustering framework to connect multiple servers within a server pool. For more information on Shoal, see the Project Shoal website at:

https://shoal.java.net

Setting Shoal Properties

To enable Shoal, use the imconfutil command to set the following configuration properties:

iim_server.serverid=servername (Make sure that this value is unique for each server)
iim_server.password=password (Make sure that this password is same across all servers)

For example:

imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop iim_server.serverid=server1 iim_server.password=password

Using Shoal for Automatic Discovery of Peer Servers in a Pool

Instant Messaging Server enables you to use the Shoal clustering framework to automatically discover and add peer servers in a server pool. The following steps describe how to configure Shoal for the servers in a pool that belong to the same IP subnet. To configure Shoal for servers in a pool that are part of different subnets, see "Using Shoal Across Subnets".

To enable auto-discovery of peer servers:

Configure a server pool containing a number of Instant Messaging servers to use the LDAP propstore property.
Use the imconfutil command to set the following configuration property to start auto-discovery.

For example:
```
imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop iim_server.peer.autodiscover=true
```
Set the configuration properties as explained in "Setting Shoal Properties".

Setting the properties enables you to start and stop the servers as required. If you are connected to one server, you can see the presence of the server and chat with users on any other server.

Using Shoal for Conferences Across Server Pools

Instant Messaging Server enables the use of Shoal group messaging to broadcast conference messages across the server pool. Shoal framework can be used to send conference messages across the server pool even if you have not used Shoal for auto-discovery or across subnets. When you enable use of Shoal across server pools, all conference presence broadcasts including join and leave notifications, messages, and chat status notifications will be sent using the Shoal group messaging feature.

To enable Shoal for conferences:

Set the properties as explained in "Setting Shoal Properties".
Use the imconfutil command to set the following configuration property. For example:
```
imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop iim_server.peer.conferences.usep2p=true
```
This property is used to enable or disable the use of Shoal for conference messaging. If you set the property to false or not set at all, the legacy server-to-server connection is used.

You can enable Shoal anytime during and after configuration. If you enable this feature after configuration, restart all the servers.

Note:

When using Shoal for peer discovery and conferences, ensure that:

The iim_server.password property is the same on all hosts.
Relay is enabled for communication to work when hosts are on different subnets.

Using Shoal Across Subnets

The Shoal configuration of a server pool in a subnet cannot discover new peers that are present in different IP subnets. Shoal uses relay nodes to propagate peer information across subnets. You need to configure Instant Messaging Server to start a separate process that performs the Shoal relay functionality, by providing connection details of the relays present in different subnets.

To enable Shoal across different subnets, you must start the relay server. To start the relay server, you need at least one relay server per subnet. You can configure any number of relay servers.

To start the relay server, use the imconfutil command to set the relay.imadmin.enable and relay.listen_address (optional) configuration properties. For example:

imconfutil -c /opt/sun/comms/im/config/iim.conf.xml set-prop relay.imadmin.enable=true relay.listen_address=192.0.2.0

The list of relay servers is specified by using the relay.uri_list parameter:

relay.uri_list = list of relays

You specify each relay by using a URI of the form tcp://host:port. For example:

relay.uri_list = tcp://relay2.example.com:5600, tcp://relay3.example.com:5600

You can start or stop the relay process independently of the Instant Messaging server. Stopping or restarting the relay process does not affect the servers that are already in the pool.