Siebel Deployment Planning Guide > Siebel Infrastructure Planning >

Defining High Availability Policies

This task is a step in Process of Infrastructure Planning.

This infrastructure planning task defines business policies regarding availability of servers.

Siebel Servers

For each business location, assess the impact of losing each server component. Consider the possibility of the component failing, rather than the hosting platform itself. Individual server components that are important to normal application function must be identified in your planning and review phases. Work closely with your implementation team to identify all of the components that could represent single points of failure.

After you complete this analysis, define high-availability policies for all of the applications and services. Decide how long your business can tolerate not having access to key applications. Also, decide how long your business can tolerate degraded performance.

For example, a company decides that Siebel Call Center must run 24 hours a day, seven days a week, and that the maximum acceptable downtime is 30 minutes. The company also decides that the maximum time it can accept degraded performance is one hour.

Finally, at each business location, list all of the server components to which each policy applies. This analysis forms the basis for implementing a high-availability strategy as part of hardware planning.

Database Platform and Data Integrity

The server platform that hosts the Siebel database is crucial to Siebel deployment operations. For this reason, it is important to define high-availability and data integrity policies specifically for the database server. The following policies are recommended:

• Cluster database servers to protect against platform hardware failures.
• Use redundant disk arrays (RAIDs) for disk storage. RAID 1+0 is recommended because it provides maximum performance, and there is no data loss if a disk fails. Do not implement RAID 0 arrays. RAID 0 offers good performance but does not protect data adequately in the event of a disk failure.
• Enable transaction logging.
• Observe the following best-practice guidelines for storing database files:
  • Store data and indexes on separate disk subsystems.
  • Store active log files and archived log files on separate disk subsystems.
  • Store the database and database control files on separate disk subsystems.
• To allow for good OLTP performance, set up four rollback segments (if you choose to use them) for each 20 to 40 users. For Initial extents or Next extents, set up rollback extents sized to 100 KB. If you use Siebel EIM, then also create several additional, large rollback segments to support Siebel EIM loads.

Siebel Gateway Name Server

The Siebel Gateway Name Server maintains the configuration information for all of the Siebel Servers in all of the Siebel Enterprise Servers it manages. Loss of the Siebel Gateway Name Server due to a disk failure could bring your Siebel Business Applications deployment to a halt while you restore the Siebel Gateway Name Server.

It is strongly recommended that you install a RAID or some other type of redundant disk configuration on your Siebel Gateway Name Server.

Mobile Users

A Siebel Server temporarily stores transaction files that move to and from Siebel Remote mobile users. The loss of these files results in the need to re-extract the database for all of the affected mobile users. (Siebel Remote supports synchronization of data between Siebel Mobile Web Clients and the Siebel database through a dial-up connection.)

It is strongly recommended that you install a RAID or some other type of redundant disk configuration on Siebel Servers that run Siebel Remote.