|
Redundancy
The architecture of the Weblicon PIM provides a high level of redundancy at all tiers eliminating single-point-of-failure and thus ensures a high availability in mission-critical implementations. All tiers of the architecture can gracefully handle failure of individual applications or server hardware without interruption of service.
HTTP Server Failure
If an HTTP server fails due to hardware or software failure, the hardware load-balancer will notice the failure when trying to dispatch incoming HTTP requests to the HTTP server. It will mark the server as unavailable and will redirect the request to other HTTP servers. Since all WebObjects HTTP adaptors running on different HTTP servers maintain a list of all application IDs and their related Host IP:Port addresses, any HTTP server available can handle requests for any application instance. Thus, users will not be affected by an HTTP server failure.
Application Instance Failure
If an application instance fails, the wotaskd agent will report the failure to the WebObjects HTTP adaptors, which will then route incoming requests to other application instances. Sessions handled by the failed application will be lost and users affected will have to re-login. However, users of other application instances running on the same server or on other servers are unaffected. If the application instance is re-launched, wotaskd will report the availability of the application instance and it will be included for future requests from the WebObjects HTTP adaptor.
Application Server Failure
If an application server fails due to a software or hardware failure, all application running on the server and the related user sessions are lost. When dispatching requests, the WebObjects HTTP adaptor will be unable to connect to application instances on the failed application server and will mark the application instances of this server as unavailable ignoring them for further requests.
Users of other application instances running on other application servers are unaffected by an application server failure. If the failed application server is restarted, the wotaskd agent will report availability of the application server to the WebObjects HTTP adaptors, which will then include the application instances running on this server for future requests.
When deployed on J2EE application servers, such as BEA WebLogic, redundancy in the application server tier is provided by the appropriate architecture of the application server.
Database Failure
Database failures can be transparently handled by leading database clustering architectures such as the Oracle 9i database system.
The Oracle Real Application Clusters (RAC) architecture provides near-continuous availability by hiding failures from application server clients. It maintains full database access and uninterrupted operation as long as there is at least one surviving database node.
If a node of the database cluster fails, all database resources are re-mastered onto the surviving nodes. Transparent Application Failover in the database transparently re-routs application clients to an available database node in the cluster when the connected node fails
In this way, the Oracle Real Application Clusters database with the Cache Fusion architecture is resilient to N-1 node failures in an N node cluster. Full data access is maintained as long as there is one surviving node in the cluster.
LDAP Failure
Leading LDAP directory servers, such as the iPlanet or Critical Path Directory Servers provide hot-failover mechanisms and Multiple-Master replication as well as Master-Slave replication to guarantee uninterrupted service in case of a hardware or software failure.
Multi-master replication allows a subtree of LDAP entries to be mastered by more than one Directory Server; that is, each master server can accept updates for entries within a replicated subtree. Each master replicates add, delete, modify, and rename operations to the other master and to multiple slave servers. The replication process used between one master and another is the same as that used between a master and a slave. If one master is unreachable for some period of time (due to hardware failure, software failure, or network failure), the other master continues to accept updates and can replicate the changes to the read-only replicas. A load balancing hardware, or a Directory Access Router can be placed in front of the master servers to facilitate smooth failover.
|
  |
|
|
