About Siebel Gateway Clustering

Siebel CRM supports an optional native clustering feature for Siebel Gateway to provide high availability benefits to Siebel CRM customers. This feature works at the software level and is the preferred and recommended approach for clustering the Siebel Gateway. This topic is part of Configuring the Siebel Gateway Cluster.

The clustering feature supports both the Siebel Gateway service (application container) and the Siebel Gateway registry (Apache ZooKeeper). You might choose to use Siebel Gateway clustering only for your production environment, for example. Further, you can use clustering for only the Siebel Gateway service, or only the Siebel Gateway registry. It is recommended to configure clustering for both the Gateway service and the Gateway registry. Clustering for the Siebel Gateway registry uses functionality native to Apache ZooKeeper, which is described in documentation for this third-party product.

For this feature, Siebel Management Console supports a new profile type, the Siebel Gateway cluster profile, and a new step to deploy the cluster profile.

Overview of Configuring Siebel Gateway Clustering

To use Siebel Gateway clustering, you perform the following tasks:

Install at least three instances of Siebel Gateway for Siebel CRM on different nodes. You can collocate a Siebel Gateway with a Siebel Server, for example, as noted in Installing Siebel CRM using the User Interface.
In a migration installation case, you perform a migration installation for the existing installed Siebel Gateway. Then you perform new installations for all other Siebel Gateway nodes that you require.
(New deployment only) Configure and deploy the primary Siebel Gateway node in Siebel Management Console, as described in Configuring the Siebel Gateway and Security.
The first Siebel Gateway installed and configured is the primary node, unless you later changed the primary node to a different instance. This task does not apply in a migration installation case, because the existing Siebel Gateway is migrated and serves as the primary Siebel Gateway.
Start the Siebel Management Console.
Configure a Siebel Gateway cluster profile in Siebel Management Console, as described in Creating a Siebel Gateway Cluster.
In the cluster profile, you specify values for Registry Client Port, Registry Follower Port, and Registry Leader Port. For Registry Client Port, you specify the same Siebel Gateway registry port number that you specified when you configured the primary Siebel Gateway, as described in Configuring the Siebel Gateway and Security. The Registry Follower Port and Registry Leader Port are used for internal communication between Siebel Gateway nodes.
(Required as precaution) Back up the Siebel Gateway registry, as described in Siebel System Administration Guide.
Deploy the Siebel Gateway cluster profile, specifying all participating nodes, as described in Deploying the Siebel Gateway Cluster.

Siebel Gateway Clustering Requirements and Operations

The specific requirements for Siebel Gateway clustering differ for the Siebel Gateway service and the Siebel Gateway registry. Optionally, you can deploy the Siebel Gateway service cluster and registry cluster on different nodes.

Siebel Gateway service clustering requires a minimum of two nodes. You can include all the same nodes that you include for the registry cluster, or include only a subset of these nodes.
Siebel Gateway registry clustering requires a minimum of three nodes and an odd number of nodes: three, five, and so on.

Note: At any time after the primary Siebel Gateway has been configured in Siebel Management Console and the participating nodes have been installed, you can configure and deploy the Siebel Gateway cluster or change an existing cluster, such as to add or remove nodes or change the primary service node and primary registry node. In general, it is recommended to deploy the Siebel Gateway cluster before you configure the Siebel Enterprise, Siebel Server, and so on. If you deploy the Siebel Gateway cluster after you configure the rest of the Siebel environment, then afterward you must restart the application containers for all of the other services.

After cluster deployment, all applicable nodes function as part of the cluster, for the Siebel Gateway service and the Siebel Gateway registry, as applicable. The Siebel Deployment screen in Siebel Management Console shows all of the components of the Siebel Gateway cluster, within the overall deployment hierarchy. The item Gateway Cluster has child items Gateway Service Cluster and Gateway Registry Cluster, each of which has child items representing the participating nodes. Deployment status is shown for each cluster node. The primary node is highlighted, for your reference. If deployment does not succeed for the minimum number of nodes required for each cluster, then cluster deployment fails and the system uses the primary Siebel Gateway.

Siebel Application Interface and Siebel Server function as clients for the Siebel Gateway service. When a Siebel Gateway service cluster is deployed, then Siebel Application Interface or Siebel Server can communicate with any of the nodes in the Siebel Gateway service cluster, and route requests to each available node, in a round-robin manner.

Similarly, the Siebel Gateway service that receives a request functions as a client for the Siebel Gateway registry. When a Siebel Gateway registry cluster is deployed, then the Siebel Gateway service can communicate with any of the nodes in the Siebel Gateway registry cluster, and routes each request to an available node, in a manner determined by ZooKeeper.

If an individual node goes down within the Siebel Gateway cluster, then the Siebel Application Interface or Siebel Server client connection switches to another available node, within the tolerance allowed by the cluster. After any Siebel Gateway cluster node goes down, when it is restarted, the node will again participate in the cluster.

For a Siebel Gateway service cluster, all but one node can go down, and the Siebel Gateway service will still function.
However, for the Siebel Gateway registry cluster, among those nodes configured as part of the cluster, a simple majority of running instances is required in order for the registry cluster to function: for example, two out of three nodes, or three out of five nodes.

If the Zookeeper Siebel Gateway cluster deployment fails (for example, if two out of three Siebel Gateway registry cluster nodes go down), then the system reverts to the non-clustered architecture: Siebel Application Interface and Siebel Server connect to the primary Siebel Gateway node, assuming it is running. (In this case, you can change the primary service node or primary registry node to a node that is functional if the system is no running.)

The Siebel Gateway cluster uses an active-active model, in which actions can originate in any available node. For the Siebel Gateway registry cluster, updates are replicated to the other nodes, thus keeping all of the cluster nodes synchronized. The active-active model enables the cluster nodes to participate in load balancing of Siebel Gateway activities.

If multiple network interface controllers are used in your deployment environment, then advanced DNS and IP networking concepts must be applied in your cluster configuration. To avoid DNS routing conflicts that could occur, you might need to specify IP addresses rather than host names.

To configure the gateway cluster with multiple networks

Follow the instructions described in Configuring the Siebel Gateway Cluster.

Note: This configuration only applies to Siebel 21.4 and above. It is mentioned on Bookshelf to take a backup copy of the Siebel Gateway registry before starting the Gateway Cluster configuration. A successful Gateway Cluster deployment depends on all used TCP ports be open bi-directionally on the firewall.

After deploying the Gateway cluster successfully on the Siebel Management Console (SMC), edit the registry.cfg located under ses/gtwysrvr/registry/conf directory to extend the leader or follower port definition by adding a second NIC. The following example shows how a non-modified registry.cfg looks like:


#Fri Nov 19 20:54:07 UTC 2021
autopurge.purgeInterval=1
initLimit=10
syncLimit=5
autopurge.snapRetainCount=10
maxClientCnxns=10000
clientPort=2330
tickTime=2000
multiAddress.reachabilityCheckEnabled=false
dataDir=/refresh/siebel/ses/gtwysrvr/registry/conf
admin.enableServer=false
server.1=cgw1.domain-A:2328:2329
server.2=cgw2.domain-A:2328:2329
server.3=cgw3.domain-A:2328:2329

The following example shows how the modified registry.cfg would look like:

#Fri Nov 19 20:54:07 UTC 2021
autopurge.purgeInterval=1
initLimit=10
syncLimit=5
autopurge.snapRetainCount=10
maxClientCnxns=10000
clientPort=2330
tickTime=2000
multiAddress.reachabilityCheckEnabled=false
dataDir=/refresh/siebel/ses/gtwysrvr/registry/conf
admin.enableServer=false
server.1=cgw1.domain-A:2328:2329|cgw1.domain-B:2328:2329
server.2=cgw2.domain-A:2328:2329|cgw2.domain-B:2328:2329
server.3=cgw3.domain-A:2328:2329|cgw3.domain-B:2328:2329

_JAVA_OPTIONS environment variable is required to enable the Zookeeper feature. On Unix or Linux operating systems, append the following export command to the siebenv.sh shell script located under the gtwysrvr directory.

export _JAVA_OPTIONS="-Dzookeeper.multiAddress.enabled=true"

On the Windows operating system, define the environment variable as a system environment variable.
Implement the above changes manually on all Gateway Cluster nodes.
Restart the Gateway Registry service on all nodes for the changes to take place.

Note:

A proper Gateway Cluster setup depends on the leader and follower TCP ports to be open bi-directionally in the firewall rules.

Related Books

Siebel Deployment Planning Guide

Siebel System Administration Guide

Overview of Configuring Siebel Gateway Clustering

Siebel Gateway Clustering Requirements and Operations

Related Topics

Related Books