Deployment Planning Guide > Siebel Infrastructure Planning >

Defining High-Availability Policies

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

This topic is a step in Process of Infrastructure Planning.

Siebel Servers

For each business location, assess the impact of losing each server component. Think about the component failing rather than the hosting platform. A common problem when Siebel Expert Services does implementation readiness reviews at customer sites is that failure of individual server components has not been adequately analyzed. The result is that server components important to normal application function are not recognized as single points of failure.

After you complete this analysis, define high-availability policies for all 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 will run 24 hours a day, seven days a week, and the maximum acceptable downtime is 30 minutes. The company also decides the maximum time it can accept degraded performance is one hour.

Finally, at each business location, list all 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 for each 20 to 40 users. The size of rollback extents should be 100K/100K. If you are using Siebel EIM, create several additional, large rollback segments to support EIM loads.

Siebel Gateway Name Server

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

It is strongly recommended that you install a RAID or some other type of redundant disk configuration on your 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 will result in the need to re-extract the database for all affected mobile users. (Siebel Remote supports synchronization of data between Siebel Mobile Web Clients and the Siebel Database Server 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.