Bookshelf Home | Contents | Index | PDF |
Siebel Deployment Planning Guide > High Availability Deployment Planning > How Service Failures Affect the Siebel Deployment > Components Involved in Service FailuresThis topic is part of How Service Failures Affect the Siebel Deployment. This topic identifies major architectural components in a Siebel deployment that may be affected when a service failure occurs. Siebel Web ClientsClient hardware failure and browser failures are the most common causes of Siebel Web Client failure. Operating system failures can also cause this, but are rare. When the Siebel Web Client fails, user sessions are lost even though the sessions may continue running on the Siebel Server for a time. The user session is lost because when the Web Client fails, the Siebel session cookie usually is also lost. Without the cookie, the user cannot be routed back to the existing user session on the Siebel Server. Therefore, the user will usually need to log in again and start a new user session. Web ServersWeb servers may fail because of hardware or software issues. Typically, when the Web server fails, Web Clients cannot access Siebel applications, since requests must go through the Web server first. Existing connections from the Web server to Siebel Servers are also lost. If Web servers are set up for high availability, for example if there are multiple, load-balanced Web servers, then subsequent requests can be routed to another working Web server. Usually when this occurs, the function of affected Web Client user sessions is not noticeably affected. Third-Party HTTP Load Balancer for Siebel ServersThird-party HTTP load balancers handle communication between Web servers and Siebel Servers. Causes of failure differ significantly between hardware-based and software-based solutions. When the load balancer fails, Web Clients and Web servers going through the load balancer cannot communicate with Siebel Servers. Network connections in most cases would also be severed, and user sessions are lost. If there are multiple, clustered load balancers, then the backup load balancer can take over. Some load balancers can failover TCP sessions to a backup load balancer. See the vendor's load balancer documentation for details. When the backup load balancer takes over, user sessions continue without interruption. However, user sessions are lost if any of the following occurs:
Siebel ServersSiebel Servers may fail because of hardware or software issues. If the hardware platform fails, or the Siebel Server software fails, then all Siebel Server components are lost. In other cases, individual Siebel Server components may fail. In turn, component failure can cause related user sessions or user requests to fail. The major groups of Siebel Server components are as follows:
Siebel DatabaseAccess to the Siebel Database can fail due to any of several factors:
The impact on the Siebel deployment will be either temporary or long term. For example, a temporary networking interruption, or a quick database server reboot, would result in a temporary disruption in service. A long-term interruption may occur when there is database corruption or a major server malfunction. In general, user sessions are lost when there is a Siebel Database service interruption. Users must log in to the system again. Application Object Manager sessions will continue to try to connect to the database and once the database is running (assuming the connection retry count has not been exceeded), the connection will succeed. Users should not notice that there was an outage, unless they were currently working at the time of the database failure. In this case, users get database error messages. If the interruption is temporary, interactive server components and most of the batch-mode server components try to reconnect with the Siebel Database. If the interruption is long-term, the Siebel deployment must be shut down and restarted once the database service is restored. NOTE: It is strongly recommended not to collocate a Siebel Server or other component with the Siebel Database. Such a deployment may affect performance of either component, and may in some cases lead to Siebel Server failure or extend interruptions of availability. For example, where a Siebel Server and the Siebel Database are collocated, if the server machine is rebooted, the database instance may not be up by the time this Siebel Server is up, so a connection could not be made. Siebel Server failure could result. However, if the Siebel Server and the database are on separate servers, as recommended, the database would be unaffected by rebooting the server machine where Siebel Server is installed, and would be available as soon as the Siebel Server was ready to connect. |
Siebel Deployment Planning Guide | Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices. | |