Clustered deployments

In an enterprise deployment, use clustering for scalability, failover, and load balancing. Clustering is the use of multiple IBM® Sametime® servers of the same type. Each cluster of servers can be managed by the IBM Sametime System Console.

Every clustered deployment starts with an LDAP directory, DB2®, and the Sametime System Console. Most servers must be installed using the Sametime System Console. While some components such as the Sametime Gateway Server are not installed through the Sametime System Console, all are registered with Sametime System Console and administered through the Sametime System Console. The only exceptions are Sametime Bandwidth Manager and the TURN Server. Use a guided activity on the Sametime System Console to create a deployment plan for server installations.

Clusters are groups of servers that are managed together and participate in workload management. When one node or application server fails, the load is picked up by other servers in the cluster. A node is usually a physical computer system with a distinct host IP address that is running one or more application servers. High availability means that a system can continue to process work at one location after routine failures. High availability planning assumes a single failure, with a goal of brief disruptions for only some users during unplanned outages. Clusters can be grouped under the configuration of a cell, which logically associates many servers and clusters with different configurations and applications.

A clustered production deployment consists of multiple servers of the same type, so you can have a cluster of Sametime Proxy Servers, a cluster of Meeting Servers, and so on. You can create a horizontal cluster or vertical cluster. A horizontal cluster contains multiple physical computers, each with one type of Sametime server. In a vertical cluster, you install multiple Sametime servers of the same type on one computer as long as the computer's hardware, RAM, and processing speed can keep up.

Servers that are a part of a cluster are called cluster members. All clustered servers in WebSphere Application Server must use the same cell profile. When installing the first server of a cluster, select the Primary Node profile. Subsequent cluster members are installed using the Secondary Node option. You can have only one Sametime Proxy Server cluster, one Sametime Meeting Server cluster, one Sametime Proxy/Registrar cluster , and so on in a cell.

Network considerations

Keeping servers on the same network is a good rule to follow to keep response times between the web client and the servers similar, and also to support Live Name integration. If there is no Live Name integration, the requirements are less rigid. It's also a good rule to have all host names similar for session scoping and SSO (LTPA) integration. Finally, being in the same local network helps to prevent delays in communication across components. For high availability deployments involving the Sametime Media Manager, IBM Load Balancer, and WebSphere Application Server Proxy server, all these components must be in the same subnet within the local network. Installing and clustering Sametime components across a WAN, especially in Disaster Recovery scenarios where you might have multiple data centers, and mirroring or clustering across the data centers, is not recommended.

While planning your deployment, use the Installation worksheets to record your own DNS-registered host names, database names, IP addresses, ports to open, and credentials.

Sametime servers and clustering

• Community Server

  Unlike other Sametime products, the Community Server is not hosted on WebSphere Application Server. Instead, you install the Community Server on IBM Domino and use the Domino replication feature to create a cluster. You can significantly increase capacity and performance on a Community Server by adding a stand-alone Community Mux in front of the Community Server. You can also add rotating DNS or a load balancer.

• Meeting Server

  The Meeting Server runs on WebSphere Application Server and uses the Sametime System Console as a cluster's deployment manager. You administer the servers through the Sametime System Console. If you cluster Meeting Servers, a WebSphere Application Server HTTP proxy server is required for determining the node on which the meeting is taking place. Only the Base Meeting Server can be clustered using WebSphere Network Deployment; however, the Recording Capturer and Recoding Renderer servers can be configured provide high availability through the use of a load balancer to distribute client connections among the servers.

• Advanced Server

  The Sametime Advanced Server runs on WebSphere Application Server and can be clustered using WebSphere Network Deployment; by default the Sametime System Console functions as the cluster's deployment manager.

• Sametime Proxy Server

  The Sametime Proxy Server runs on WebSphere Application Server and can be clustered using WebSphere Network Deployment; by default the Sametime System Console functions as the cluster's deployment manager.

• Sametime Media Manager
  The Media Manager by itself cannot be clustered. But some of its components can be clustered:

  • You can cluster the Conference Manager, which handles data, and the SIP Proxy/Registrar, which handles user connections. You must use a WebSphere SIP Proxy server in front of the cluster if you cluster Media Manager components.
  • You cannot cluster the Video Manager and Video MCU components of the Media Manager using WebSphere Network Deployment, but you can configure those servers to provide high availability by deploying a load balancer to distribute connections among multiple nodes.
• Sametime Bandwidth Manager

  The Bandwidth Manager is hosted on WebSphere Application Server, but installs and clusters differently from other WebSphere-based Sametime servers because it is not installed or administered through the Sametime System Console. A Sametime Bandwidth Manager cluster always requires a dedicated deployment manager.

• Sametime TURN Server

  The TURN Server is not hosted on WebSphere Application Server. You can configure it to provide high availability by deploying a load balancer to distribute connections among multiple nodes.

• Sametime Gateway

  The Gateway server is hosted on WebSphere Application Server, but installs and clusters differently from other WebSphere-based Sametime servers. A Sametime Gateway cluster always requires a dedicated deployment manager, and additionally uses a dedicated WebSphere SIP proxy server.

• Sametime System Console

  The Sametime System Console cannot be clustered.

• WebSphere Proxy Server

  A WebSphere proxy server can be configured as an HTTP proxy server, a SIP proxy server, or both. These proxy servers cannot be clustered but can be configured to provide high availability by deploying a load balancer in front of multiple nodes.

Clustering decisions for WebSphere Network Deployment

Installing each server in the same cell is recommended. When installing a server, choose the Primary Node option when you want to put servers in the same cell and allow for clustering. A primary node can be federated into an existing Deployment Manager in the Sametime System Console

• Where will you install the deployment manager?
  The type of server you are clustering determines the role of the deployment manager.

  • Sametime Community Server

    Use IBM Domino replication to create the Sametime Community Server cluster. Each of the Sametime Community Servers in the cluster is registered with the Sametime System Console when you use a deployment plan to install the servers. You then register the Community Server cluster itself with the Sametime System Console.

  • Sametime Proxy Server, Media Manager, Meeting Server, and Advanced Server

    Each deployment manager (including the Sametime System Console when it is used as a deployment manager) supports one cluster of each Sametime server product (for example, a Meeting Server cluster). To create additional clusters for a particular Sametime server product, install the first server using Cell as the configuration type, which designates it as the deployment manager and the primary node for the cluster.

  • Sametime Bandwidth Manager

    If you are clustering Bandwidth Manager servers, you must install a dedicated deployment manager for the cluster, and then manage the nodes using the deployment manager's WebSphere Integrated Solutions Console.

  • Sametime TURN Server

    A TURN Server cluster does not use a Deployment Manager.

  • Sametime Gateway Server

    If you are clustering Sametime Gateway Servers, you must install a dedicated deployment manager for the cluster, and then manage the nodes using the deployment manager's WebSphere Integrated Solutions Console.

• Which kind of cluster are you creating: vertical or horizontal?
  The Sametime Proxy Server, Media Manager, Meeting Server, and Sametime Advanced Server support two types of clusters, called vertical clusters and horizontal clusters.

  • A vertical cluster contains multiple instances of one type of Sametime server hosted on the same physical computer (or node). A vertical cluster distributes the load as appropriate across servers. Computer maintenance in a vertical cluster is easier and more convenient because everything is on one computer.
  • A horizontal cluster contains multiple physical computers (or nodes), each with one type of Sametime server. A horizontal cluster distributes the load across servers on multiple computers as needed. The advantage of a horizontal cluster is that users can still use the Sametime application even if one computer in the cluster fails. A horizontal cluster includes a deployment manager, a primary node, and at least one secondary node. The primary node and each secondary node has only one Application Server configured to run on it as part of the cluster.
  • Clustering requires a deployment manager.
  • The clustering guided activity in the Sametime System Console can use any deployment manager that is visible to the Sametime System Console that has been installed for its own product. For example, a Sametime Meetings Server can only use a deployment manager that has been installed for the Sametime Meetings Server.
  The following graphic shows a vertical cluster of three nodes on one computer: Meeting Server primary node and two Meeting Server secondary nodes. The graphic also shows a horizontal cluster made of up of two computers, a Meeting Server primary node on one computer and a Meeting Server secondary node on the second computer.
  
  
• How will you cluster Media Manager components?

  Clustering the Sametime Media Manager works differently from clustering other Sametime products. When you install the media manager, you have the option of installing its three components on separate computers, but you can only cluster two of them:

  1. SIP Proxy/Registrar: You can deploy either a vertical or a horizontal cluster for this component. You must configure this cluster before you configure a cluster of Conference Managers.
  2. Conference Manager: You can deploy either a vertical or a horizontal cluster for this component.
• Will you need a dedicated load balancer?

  When you create a cluster, you may need to deploy a dedicated WebSphere proxy server or a load balancer in front of the cluster to direct traffic for load balancing and failover purposes. If this is necessary for a particular Sametime product, the clustering instructions for that product explain what is needed and how to install it.