5Server Clustering Planning
Server Clustering Planning
This chapter provides information about planning server clustering for your Siebel CRM deployment. It includes the following topics:
About Server Clustering
A server cluster is a group of two or more servers that are configured so that, if one server fails, another server can take over application processing. The servers in a cluster are called nodes. Typically, these servers store data on a common disk or disk array.
Clustering software monitors the active nodes in a server cluster. When a node fails, the clustering software manages the transition of the failed server’s workload to the secondary node.
When a clustered Siebel Server fails, all of the applications and services on the server stop. Application users must reconnect and log in to the server that takes over. For example, if the Siebel Server that failed was hosting Siebel Communications Server, then the communications toolbar is disabled, and users must reconnect and log in to the new server.
Cluster vendors can validate their third-party server cluster products to provide server clustering for deployments of Siebel CRM applications. For validation assistance, contact your Oracle sales representative for Oracle Advanced Customer Services to request assistance from Oracle’s Application Expert Services. For recommendations and help on the use of cluster products with Siebel CRM, customers are advised to contact the cluster vendor of their choice.
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. For more information, see Defining High Availability Policies.
This topic contains the following information:
Active-Passive Configuration
An active-passive server cluster contains a minimum of two servers. One server actively runs applications and services. The other is idle. If the active server fails, then its workload is switched to the idle server, which then takes over application processing.
Because the standby server is idle, active-passive server clusters require additional hardware without providing additional active capacity. The benefit of active-passive clusters is that, after a failover, the same level of hardware resources is available for each application, thereby eliminating any performance impact on users. This benefit is particularly important for performance-critical areas such as the database. The most common use of active-passive clusters is for database servers.
This topic is part of About Server Clustering.
Active-Active Configuration
An active-active server cluster contains a minimum of two servers. Both servers actively run applications and services. Each server might host different applications or might host instances of the same application. If one server fails, then its processing load is transferred to the other server.
Active-active configuration is the most common server clustering strategy for servers other than the database server.
This topic is part of About Server Clustering.
Potential Port Conflicts
Some Siebel Server components, such as Siebel Connection Broker (SCBroker), Siebel Gateway, and Siebel Remote Synchronization Manager, listen on a configurable static port. When these components run in an active-active cluster, you must plan your port usage so there is no port conflict after failover.
For example, an active-active server cluster contains two computers, each running a Siebel Server. If one computer fails, then the other computer hosts two Siebel Servers. Siebel Servers include a number of services, such as Siebel Connection Broker, that use a dedicated port. If this port number was the same on both computers, then a port conflict occurs after failover.
Capacity Planning
Active-active clusters use all of the server platforms continuously. Consequently, they take better advantage of computing resources than active-passive clusters. When doing capacity planning, make sure that clustered servers have sufficient capacity to handle a failover. Because failovers are usually infrequent and normally last only a short time, some performance degradation is often acceptable.
An active-active server cluster contains a minimum of two servers. Both servers actively run applications and services. Each server might host different applications or might host instances of the same application. If one server fails, then its processing load is transferred to the other server.
Active-active configuration is the most common server clustering strategy for servers other than the database server.
Where to Use Server Clustering
Siebel CRM supports server clustering for the following parts of a Siebel CRM deployment:
Siebel Gateway
Alternatively, you can configure clustering for Siebel Gateway using Siebel Management Console. For more information, see Defining High Availability Policies.
Siebel Servers
Individual server components can be clustered. Some Application Object Manager components do not support or require clustering.
Siebel File System
Siebel database
Subject to limitations of third-party RDBMS software.
Siebel Application Interface
In addition, server clustering is the preferred method for providing high availability for the following Siebel Server components:
Workflow Monitor Agent
Siebel Remote
The DockString parameter in the Siebel Mobile Web Client configuration file must reference the virtual server name for remote synchronization to work after failover.
Replication Agent
MQSeries Server Receiver
Server Clustering for Some Components Is Not Supported
Siebel CRM does not support server clustering for the following components:
LDAP directory server. The vendor might provide built-in replication.
Siebel Document Server (Microsoft server-side integration).
CTI hardware or switch.
Recommendations for Server Clustering
The following recommendations help promote failover protection for your Siebel CRM deployment. However, these practices are neither exhaustive nor all-inclusive.
If you have multiple Siebel Servers running that are not clustered, then load balance these servers.
Make clustering the Siebel database a high priority because it is a single point of failure. When clustering the Siebel database, have it already installed and running. Cluster the Siebel database server first.
Install and configure clustering software on each node to detect failure of that node and to recover and manage all of the servers as a single system.
Make sure all of the hardware used is certified for server clustering by the hardware vendor.
If you operate the Siebel Gateway and Siebel Servers as part of a cluster, then you must install and configure the Siebel Gateway and the Siebel Server individually as separate cluster services.
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. For more information, see Defining High Availability Policies.
On the copy that you made of the cluster deployment worksheet (which is located in an appendix of the Siebel Installation Guide for the operating system you are using), or your custom worksheet, fill out the section related to server clustering, and refer to it during installation.