Clustering Server Components

About Clusters

Establishing one or more SBM clusters provides several benefits to your SBM installation.

• Creating a cluster for SBM Application Engine provides failover in the event one of the servers in your installation fails or loses connection.
• Clustering SBM Orchestration Engine can provide greater scalability for the orchestrations that you create in SBM Composer.
• Using a cluster can improve the overall performance and load handling of SBM.

For example, you can use SBM Configurator to create an Application Repository cluster, where each Application Repository server is an individual node in the cluster that is connected to the same Application Repository database. Multiple users can access the Application Repository cluster, with each request routed to one given Application Repository instance using either a software or hardware load balancer.

Using Load Balancers

The load balancer has knowledge about the health of the configured servers in the cluster. If one of the servers goes down, the load balancer sends requests to the other servers in the cluster.

Load Balancer Requirements in a Tomcat Cluster

You can use either a software or hardware load balancer, though using a hardware load balancer is recommended due to better support, statistics, and overall performance. For uninterrupted service, the load balancer should be configured to ensure that sessions are "sticky" or persistent. This ensures that the same HTTP session is always delegated to the same machine, as state information resides on only one Application Repository server. The load balancer can then delegate different sessions to different servers so that multiple sessions can run on different servers.

For more details on configuring your load balancer with a Tomcat cluster, refer to solution S140260.

Load Balancer Requirements in a Application Engine Cluster

In an Application Engine cluster, the load balancer requires session persistence via the "Node Lock" option (also called "Server Affinity" and "Persistence" depending on the load balancer). This option ensures that once a user is directed to a server, they are continuously directed to that server unless there is a long period of inactivity or the server goes down. Data loss can occur if the Node Lock option is not used, in addition to an over consumption of licenses (1 per server that is connected to).

You also need to ensure that the load balancer is configured to properly identify the client. When SBM receives a network packet, it initially scans for X-FORWARDED-FOR: client1, proxy1, proxy2 in the header. If SBM cannot find this header, it uses the source IP address from the packet header instead. A packet that is sent from a load balancer or proxy will contain the load balancer or proxy server's address and not the client address; therefore, you must configure the load balancer header settings to include X-FORWARDED-FOR as SBM expects.

For more details on configuring your load balancer with an Application Engine cluster, refer to solution S138266.

Installation and Configuration Considerations

Review the following important considerations before you configure a cluster.

• You will run the SBM installer on each server that will join the cluster as a node. When the installer is finished, you will use the Component Servers tab on one of the servers to create the cluster and define the nodes.
• The method you use to configure the cluster depends on the following:
  • If you are using the Configuration Settings database (recommended), the entire configuration is saved in a single database and all servers should be in sync. This means after you have installed SBM on each server, you can configure the entire cluster from one server, and then click Update From Database on each server to have them join the cluster as a new node with all the settings that you defined.
  • If you are using configuration snapshots instead of the Configuration Settings database, enter all the configuration information in SBM Configurator on one server (pre-defining all node number and host name pairings at the same time), and then export the data into a snapshot configuration file using the System Settings tab. Once the snapshot is created, import it into SBM Configurator on each server that will become a node in the cluster. This ensures that each server is configured exactly the same.
• There are multiple clustering options available, depending on the number of components that you want to cluster and the number of clusters you want to create. For example:
  • You can create a single cluster for a single Tomcat component (for example, SBM Orchestration Engine).
  • You can create a single cluster for multiple Tomcat components (for example, SBM Orchestration Engine and SBM Mail Services together).
  • You can create multiple clusters each comprised of a single Tomcat component or multiple clusters each comprised of multiple Tomcat components. In either scenario, you must enable the same Tomcat components on each node in the cluster.
  • You can create a single cluster for SBM Application Engine or combine it with Tomcat components in a mixed cluster.
• You will typically create a cluster that contains either a set of Tomcat nodes or a set of SBM Application Engine nodes. If you have nodes with both SBM Application Engine and Tomcat components in one cluster (mixed), you must ensure that the load balancer is configured properly to redirect requests to the correct IIS or Tomcat ports in the cluster (unless you decide to have IIS proxy all server requests, in which case only the IIS ports are used).
• Ensure that you have dedicated servers that meet the minimum hardware requirements as specified in the "Hardware Requirements" section of the SBM Installation and Configuration Guide.
• Consult with your network administrator, and ensure that UDP multi-casting is available between all nodes in the cluster. In other words, ensure that all nodes in the cluster exist in a common subnet that supports UDP multi-casting.
• You must ensure UDP broadcasting is available between all of the nodes in your Tomcat cluster, otherwise deployed changes will not be synchronized on each node in the cluster until Tomcat is restarted.

  The EHCache is responsible for synchronizing the nodes in the cluster and uses UDP broadcasting to accomplish this. The multi-cast group address that is used is a logical IP address that does not represent a real server. Instead, it represents the group of nodes and identifies which nodes should receive broadcast messages. It must be identical on each node in the cluster and unique within the network in which UDP broadcasting is allowed. The logical IP address and ports that are specified must be unique in the event that you configure multiple Tomcat clusters.

  For example, depending on your network hardware and configuration, UDP broadcast messages can still be received by servers with different logical IP addresses if they share common port values. This can create a situation in which a process app deployment is not processed on the correct nodes in one of the clusters. Therefore, either ensure that your network supports multiple logical IP addresses for UDP broadcasting or ensure that a specific set of unique port values are assigned to each cluster.

• For correct results, you must ensure that the clocks on all the servers are synchronized within one second.

Creating a Cluster

To create one or more clusters, perform the following steps on each server that will join the cluster as a node :

1. On the Component Servers tab, drag and drop one or more SBM components that you intend to cluster to an empty space in the design area. This creates a temporary server definition that represents the entire cluster.
2. Click the new server definition that you just created in the design area.
3. In the General sub-tab, select Join cluster as a node. Enter the following details:

   Field Name	Description
   Cluster name	Enter a unique name for the cluster that distinguishes it from other clusters you might create in your development and staging environments. Note: If you configure each server manually (instead of updating from the database or importing a snapshot file), you must enter the same Cluster name on each server that you add to the cluster. This means that each server in the cluster will have the same value in the Cluster name field.
   Use HTTP on port	Select this check box to configure all SBM URLs to use HTTP. Important: If you select this option, all SBM components on this server are only accessible using HTTP. Select only the HTTP check box to force all traffic to use HTTP.
   Use HTTPS on port	Select this check box to configure all SBM URLs to use HTTPS. Important: If you select this option, all SBM components on this server are only accessible using HTTPS. Select only the HTTPS check box to force all traffic to use HTTPS.

4. On the Load Balancer tab, enter the following information:
   • Internal load balancer

     Used by nodes that are inside the firewall.

     Field Name	Description
     Protocol	Select HTTP or HTTPS, depending on which protocol your load balancer is configured to use.
     Host	Enter the host name for the internal load balancer.
     Port	Enter the port number that is used to access the nodes through the load balancer.

   • External load balancer

     Used for connections from outside the firewall.

     Field Name	Description
     Protocol	Select HTTP or HTTPS, depending on which protocol your load balancer is configured to use.
     Host	Enter the server host name that all incoming requests should use.
     Port	Enter the port number that is used to access the nodes through the load balancer.

   Important: After you enter load balancer details for a Tomcat cluster, you must log in to SBM Application Repository, edit the host environment, and update the target server endpoints with the load balancer host and port information that you entered in SBM Configurator. When you are finished, redeploy your process apps to this environment.
5. On the Nodes tab, enter the following information:

   Field Name	Description
   Node 1 Host	Enter the host name of the first node that you add to the cluster. Click Add Node to define additional nodes or Remove Node to delete this node from the cluster.
   Node 2 Host	Enter the host name of the second node that you add to the cluster. Click Add Node to define additional nodes or Remove Node to delete this node from the cluster.

   After you have added at least one other node, continue to add nodes for each server that will join the cluster as a new node. You must replicate the same node number and host name pairing on each server in the cluster. For example, if you create the following node number and host name pairing on Server A:

   Node	Host Name
   Node 1 host:	Server A
   Node 2 host:	Server B
   Node 3 host:	Server C

   You must enter the same pairing on the Nodes tab on Server B and Server C:

   Node	Host Name
   Node 1 host:	Server A
   Node 2 host:	Server B
   Node 3 host:	Server C

   If you remove a node, the following node becomes the node number that you just removed. For example, if you remove node 2 (Server B), then Server C becomes node 2. This means you must update each server again with the correct node number and host name pairing.

6. On the EhCache tab, review the UDP broadcast settings to ensure each cluster that you configure has a unique subnet address and that there are no port conflicts on the server. You must ensure each cluster is assigned a unique address to avoid problems with identifying clusters if they are in the same subnet.
7. To finish, verify the information on each server that will become a node in the cluster—the same configuration information and the same node number and host pairings should appear for each node that exists in the cluster.

Related Topics

Component Servers