|
Oracle® Application Server High Availability Guide
10g Release 2 (10.1.2) B14003-03 |
|
 Previous |
 Next |
|
Oracle® Application Server High Availability Guide
10g Release 2 (10.1.2) B14003-03 |
|
|
Previous |
Next |
The OracleAS Infrastructure portion of Oracle Application Server consists of two parts: OracleAS Metadata Repository and Oracle Identity Management. Together, they provide centralized metadata, management, and security services for Oracle Application Server components.
To create a highly available OracleAS Infrastructure, you need to make both parts (Oracle Identity Management and OracleAS Metadata Repository) highly available. Each part can have its own high availability plan. For example, you can run Oracle Identity Management components in an active-active configuration against an OracleAS Metadata Repository database that is already configured for high availability (for example, a Real Application Clusters database). Chapter 9, "OracleAS Infrastructure: High Availability Topologies" describes high availability topologies for OracleAS Infrastructure.
This chapter describes high availability for the OracleAS Infrastructure from a high level. Subsequent chapters provide the details.
Contents of this chapter:
Section 6.1, "High Availability for OracleAS Infrastructure Services"
Section 6.3, "Backup and Recovery for OracleAS Infrastructure"
OracleAS Infrastructure provides the following services:
product metadata
security service
management service
These services execute on top of the following core components, which must all be available to guarantee high availability of the OracleAS Infrastructure:
These core components are used by Oracle Identity Management and Oracle Management applications. The following table lists the Oracle Identity Management applications, and how they use the core components.
Table 6-1 Oracle Identity Management Applications
| Oracle Identity Management Application | Description |
|---|---|
|
Oracle Internet Directory uses the OracleAS Metadata Repository as its data store. Oracle Internet Directory includes a monitoring process ( For Oracle Internet Directory to be highly available, the OracleAS Metadata Repository has to be highly available as well. |
|
|
Oracle Delegated Administration Services and OracleAS Single Sign-On are OC4J applications. They run on an OC4J instance called "OC4J_SECURITY". For Oracle Delegated Administration Services and OracleAS Single Sign-On to be highly available, the OC4J_SECURITY instance needs to be highly available. |
|
|
Oracle Directory Integration and Provisioning consists of a set of services and interfaces built into Oracle Internet Directory. For Oracle Directory Integration and Provisioning to be highly available, Oracle Internet Directory needs to be highly available. |
For management, Oracle Application Server provides Distributed Configuration Management (DCM). DCM also uses the OracleAS Metadata Repository.
For OracleAS Infrastructure to provide all essential services, all of the above components must be available. On UNIX platforms, this means that the processes associated with these components must be up and active. On Windows, some of these processes run as services.
OracleAS Infrastructure processes, except for the database, its listener, and Application Server Control Console, are started, managed, and restarted by Oracle Process Manager and Notification Server (OPMN). This means any failure of an OPMN-managed process is handled by OPMN. OPMN is automatically installed and configured during installation.
However, OPMN does not handle database process or database listener failures. Also, failure of any OPMN processes leaves OracleAS Infrastructure in a non-resilient mode if the failure is not detected and appropriate recovery steps are not taken. Section 2.2.1, "Process Death Detection and Automatic Restart" describes process management and monitoring.
To provide protection from local hardware and software failures (such as a system panic or node crash) that cannot be recovered by OPMN, you need to install and run OracleAS Infrastructure in a highly available topology.
Any high availability topology must be able to detect and recover from any type of software failures of any of the OracleAS Infrastructure components. It must also be able to detect and recover from any type of hardware failures on the hosts that are running the OracleAS Infrastructure. See Section 6.2, "Intra-Site High Availability Topologies".
These topologies, however, cannot protect the OracleAS Infrastructure from site failures, media failures, or regional disasters, which result in damage to or loss of data. For protection against these types of failures, Oracle Application Server provides OracleAS Disaster Recovery, which is a site-level active-passive disaster recovery topology. See Part IV, "Disaster Recovery" for details.
For media failures or if the metadata became corrupted, you can use the OracleAS Backup and Recovery Tool to back up and recover Oracle Application Server metadata, including data in the OracleAS Metadata Repository database and files in the file system. See Section 6.3, "Backup and Recovery for OracleAS Infrastructure".
Intra-site high availability topologies for OracleAS Infrastructure can be categorized into these groups:
Table 6-2 summarizes these topology types:
Table 6-2 Summary of Intra-Site High Availability Topologies
| Topology | Description |
|---|---|
|
In active-active topologies, you run multiple active instances of the OracleAS Infrastructure services on multiple nodes; all of the instances are servicing requests concurrently. If an instance or a node fails, the remaining active instances take over the workload of the failed instance. Active-active topologies use an external load balancer to distribute requests to the active instances. Active-active topologies are: |
|
|
In active-passive topologies, you have two nodes, but only one of the nodes is active at any time. If the active node or instance fails, the passive node becomes active and takes over the entire workload of the failed instance. The active and passive nodes share a storage device, on which you install Oracle Application Server. The nodes also use a virtual hostname, through which you access the active node. If the active node fails, the virtual hostname points to the other node, which becomes the active node. Active-passive topologies are: |
For each topology, you can choose to have collocated Oracle Identity Management components, or you can distribute the OracleAS Single Sign-On and Oracle Delegated Administration Services components onto their own nodes separate from Oracle Internet Directory node.
For the OracleAS Cluster (Identity Management) and OracleAS Cold Failover Cluster (Identity Management), which are focused on Oracle Identity Management, you install the OracleAS Metadata Repository on its own or in an existing cold failover cluster database or an existing Real Application Clusters database.
In active-active topologies, all the nodes running Oracle Application Server instances are active and share the same workload. Active-active topologies for Oracle Identity Management are also known as OracleAS Cluster (Identity Management) topologies.
OracleAS Cluster (Identity Management) topologies come in two variations: non-distributed and distributed. For both, the Oracle Identity Management components need not be installed on machines that are part of a hardware cluster. Table 6-3 describes the non-distributed and distributed OracleAS Cluster (Identity Management) topologies:
Table 6-3 OracleAS Cluster (Identity Management) Topologies (Active-Active)
| Topology | Description |
|---|---|
|
In the non-distributed topology, all the Oracle Identity Management components are installed on each of two or more hosts. These hosts are deployed behind an external load balancer, which directs requests to them. If a host fails, the load balancer directs requests to the remaining host(s). |
|
|
In the distributed topology, OracleAS Single Sign-On and Oracle Delegated Administration Services components are deployed on separate hosts from Oracle Internet Directory and Oracle Directory Integration and Provisioning. These hosts are fronted by a load balancer, which gives them active-active availability. Separating out OracleAS Single Sign-On and Oracle Delegated Administration Services components enables you to secure the other Oracle Identity Management components behind a firewall. |
High Availability Options for the OracleAS Metadata Repository in OracleAS Cluster (Identity Management) Topologies
For both OracleAS Cluster (Identity Management) topologies, the Oracle Identity Management components on all nodes are connected to the same directory store database. High availability for this database, which is also used by the OracleAS Metadata Repository, is achieved by using OracleAS Metadata Repository Creation Assistant to install the directory store and metadata repository into an existing database. This database is already installed in one of the following high availability configurations:
For details on active-active topologies, see:
Active-passive topologies use a cold failover cluster configuration on a hardware cluster. These topologies are described in Table 6-4. The variations in the topologies are based on the way OracleAS Infrastructure components are set up and distributed.
Table 6-4 OracleAS Cold Failover Cluster Topologies (Active-Passive)
| Topology | Description |
|---|---|
|
This a two-node, active-passive configuration on a hardware cluster. The two nodes are connected to shared storage. OracleAS Metadata Repository and Oracle Identity Management are installed together in the same Oracle home on the shared storage. A new database is installed for the OracleAS Metadata Repository. OracleAS Metadata Repository and Oracle Identity Management are active on one node and passive on the other node. This topology is the easiest to install and configure out-of-box. |
|
|
Distributed OracleAS Cold Failover Cluster (Infrastructure)Topology |
OracleAS Single Sign-On and Oracle Delegated Administration Services are installed on separate machines from Oracle Internet Directory and Oracle Directory Integration and Provisioning. OracleAS Single Sign-On and Oracle Delegated Administration Services are installed on two or more hosts that are load balanced by an external load balancer. OracleAS Single Sign-On and Oracle Delegated Administration Services are active-active. However, OracleAS Metadata Repository, Oracle Internet Directory and Oracle Directory Integration and Provisioning are installed in an OracleAS Cold Failover Cluster. A new database is installed for the OracleAS Metadata Repository. These components run in active-passive mode. |
|
OracleAS Cold Failover Cluster (Identity Management) Topology |
Oracle Identity Management components are installed in a hardware cluster, in active-passive mode. OracleAS Metadata Repository is installed separately. You can install it in an existing high availability database using OracleAS Metadata Repository Creation Assistant. Oracle Identity Management has a different Oracle home from OracleAS Metadata Repository. Failover of Oracle Identity Management can be performed independently of OracleAS Metadata Repository and vice versa. |
|
DistributedOracleAS Cold Failover Cluster (Identity Management) Topology |
OracleAS Metadata Repository is installed in an existing database using OracleAS Metadata Repository Creation Assistant. This database can use a cold failover cluster, Real Application Clusters, or other database-certified configurations to provide high availability. OracleAS Single Sign-On and Oracle Delegated Administration Services are deployed on separate hosts from other Oracle Identity Management components. They can be installed on the OracleAS middle-tier hosts and can have active-active availability as they are fronted by a load balancer. Oracle Internet Directory and Oracle Directory Integration and Provisioning are installed on a two node active-passive cold failover hardware cluster. This configuration differs from the OracleAS Cold Failover Cluster (Identity Management) Topology in that OracleAS Single Sign-On and Oracle Delegated Administration Services are installed on separate hosts from Oracle Internet Directory and Oracle Directory Integration and Provisioning. This separation enables you to run Oracle Internet Directory and Oracle Directory Integration and Provisioning behind a firewall. This topology is similar to the Distributed OracleAS Cold Failover Cluster (Infrastructure)Topology. The difference is that, in the hardware cluster where Oracle Internet Directory and OracleAS Metadata Repository are installed, each has a separate Oracle home from the other. Note that OracleAS Single Sign-On and Oracle Delegated Administration Services are active-active, and Oracle Internet Directory is active-passive. OracleAS Metadata Repository availability is dependent on the high availability configuration used by the database. |
High Availability Options for the OracleAS Metadata Repository in OracleAS Cold Failover Cluster Topologies
For the OracleAS Cold Failover Cluster topologies, you have the following high availability options for the OracleAS Metadata Repository.
For OracleAS Cold Failover Cluster (Infrastructure) and distributed OracleAS Cold Failover Cluster (Infrastructure), a new database is installed for the OracleAS Metadata Repository. The OracleAS Metadata Repository is in a cold failover cluster database.
For the OracleAS Cold Failover Cluster (Identity Management) and distributed OracleAS Cold Failover Cluster (Identity Management), you install the OracleAS Metadata Repository in an existing high availability database such as:
This section contains considerations for backup and recovery for OracleAS Infrastructure. It has the following sections:
See the Oracle Application Server Administrator's Guide for complete procedures for backup and recovery of the OracleAS Infrastructure.
When performing backup and recovery operations for OracleAS Cold Failover Cluster (Infrastructure), note the following points:
backup considerations for OracleAS Cold Failover Cluster
You should locate archive logs for the OracleAS Metadata Repository on the shared disk. This ensures that when you fail over from one cluster node to another in the case of media recovery, the archive logs are also failed over and available.
You can generate archive logs to a local file system. However, make this destination accessible to both nodes so that no matter which node is active, the database instance will always output archive logs to the same location. Otherwise, the backup operation will not be able to see all archive log files.
Proper capacity planning is required in order to ensure adequate space is available to store the desired number of archive logs.
Recovery considerations for OracleAS Cold Failover Cluster
There are no special considerations for recovering OracleAS Cold Failover Cluster. As mentioned in the backup considerations above, if archive logs are stored on a local file system, in the case of media recovery, all archive logs must be made available to the application server instance performing the recovery. Recovery can be performed on either node of the cluster.
Before taking a cold backup or restoring the metadata repository database, the OracleAS Backup and Recovery Tool shuts down the database first. In the Windows OracleAS Cold Failover Cluster environment, the Oracle Fail Safe Manager performs database polling and restarts the database if it is down. This means that every time before you perform "backup_cold" or "restore_repos" with the OracleAS Backup and Recovery Tool on the primary (active) node, you must disable database polling in the Oracle Fail Safe Manager and re-enable it after the backup/restore operation.
In an OracleAS Cluster (Identity Management) or OracleAS Cold Failover Cluster (Identity Management) environment (or their distributed variants), you back up and restore each Oracle Identity Management installation individually. The backup performed on each Oracle Identity Management installation can be restored only on the respective instance in case of failure.
If the DCM repository is in the OracleAS Metadata Repository database, the OracleAS Backup and Recovery Tool requires at least one Oracle Internet Directory process to be running during backup and restore operations. So, in case of a failure on all the Oracle Identity Management nodes, you need to first perform the restore operation on one of the Oracle Identity Management nodes and start up the Oracle Internet Directory process on that node. Then you can restore the other Oracle Identity Management nodes.
If you lose an Oracle Identity Management node completely and need to restore it to a new node, see the "Restoring an Identity Management Instance to a New Host" procedure in the Oracle Application Server Administrator's Guide.
|
Note: To determine if the DCM repository is in a database, run the "dcmctl whichfarm" command and look for the "Repository Type: Database" or "Repository Type: Database (host)" line in the output.
|
