|
Oracle® Application Server 10g High Availability Guide
10g (10.1.2) Part No. B14003-01 |
|
 Previous |
 Next |
|
Oracle® Application Server 10g High Availability Guide
10g (10.1.2) Part No. B14003-01 |
|
|
Previous |
Next |
This chapter focuses on the high availability aspects of the Oracle Application Server Infrastructure. It discusses the features and architectural solutions for high availability of the OracleAS Infrastructure and is divided into the following sections:
Section 5.1, "Oracle Application Server Infrastructure Overview"
Section 5.2, "Oracle Application Server Infrastructure Components"
Section 5.3, "High Availability Configurations for Infrastructure"
Section 5.4, "OracleAS Infrastructure Backup and Recovery Considerations"
Oracle Application Server provides a completely integrated infrastructure and framework for development and deployment of enterprise applications. An Oracle Application Server Infrastructure installation type provides centralized product metadata, security and management services, and configuration information and data repositories for the Oracle Application Server middle-tier. By integrating the Infrastructure services required by the middle tier, time and effort required to develop enterprise applications are reduced. In turn, the total cost of developing and deploying these applications is reduced, and the deployed applications are more reliable.
The OracleAS Infrastructure consists of several components that contribute to its role and function. These components work with each other to provide the Infrastructure's product metadata, security, and management services. This section describes these components, which are:
Section 5.2.1, "Oracle Application Server Metadata Repository"
Section 5.2.4, "Oracle Application Server Containers for J2EE (OC4J)"
Section 5.2.5, "Oracle Enterprise Manager 10g Application Server Control Console"
The Oracle Application Server Metadata Repository (OracleAS Metadata Repository) stores component-specific information that is accessed by the Oracle Application Server middle-tier or Infrastructure components as part of their application deployment. The end user or the client application does not access this data directly. It stores three main types of metadata corresponding to the three main Infrastructure services described in Section 5.1, "Oracle Application Server Infrastructure Overview". These types of metadata are:
Table 5–1 shows the Oracle Application Server components that store and use these types of metadata during application deployment.
Table 5-1 Metadata and Infrastructure Components
Oracle Application Server metadata and customer or application data can co-exist in the same database as the Oracle Application Server Metadata Repository; the difference is in which applications that are allowed to access them. Customer applications will not be able to access product or management metadata.
OracleAS Metadata Repository is needed for all application deployments except for those using the J2EE and Web Cache installation type. Oracle Application Server provides two middle-tier installation options:
J2EE and Web Cache: Installs Oracle HTTP Server, Oracle Application Server Containers for J2EE (OC4J), Oracle Application Server Web Cache (OracleAS Web Cache), Web Services, ADF Business Components, and Application Server Control Console.
Portal and Wireless: Installs all components of J2EE and OracleAS Web Cache, plus UDDI, Oracle Application Server Portal (OracleAS Portal), Oracle Ultra Search, and Oracle Application Server Wireless (OracleAS Wireless).
The Distributed Configuration Management (DCM) component enables middle-tier management, and stores its metadata in the OracleAS Metadata Repository for the Portal and Wireless installation. For the J2EE and Web Cache installation type, by default, DCM uses a file-based repository. If you choose to associate the J2EE and Web Cache installation type with an OracleAS Infrastructure, the file-based repository is moved into the OracleAS Metadata Repository.
The Oracle Identity Management framework in the Infrastructure includes the following components:
Section 5.2.2.4, "Oracle Directory Integration and Provisioning"
Section 5.2.2.5, "Oracle Application Server Certificate Authority"
Oracle Internet Directory is Oracle's implementation of a directory service using the Lightweight Directory Access Protocol (LDAP) version 3. It provides a centralized repository for creating and managing users for the rest of the Oracle Application Server components such as OC4J, Oracle Application Server Portal, or Oracle Application Server Wireless. Central management of user authorization and authentication enables users to be defined centrally in Oracle Internet Directory and shared across all Oracle Application Server components.
Oracle Internet Directory is provided with a Java-based management tool (Oracle Directory Manager), a Web-based administration tool (Oracle Delegated Administration Services) for trusted proxy-based administration, and several command-line tools. Oracle Delegated Administration Services provide a means of provisioning end users in the Oracle Application Server environment by delegated administrators who are not the Oracle Internet Directory administrator. It also allows end users to modify their own attributes.
Oracle Internet Directory also enables Oracle Application Server components to synchronize data about users and group events, so that those components can update any user information stored in their local application instances.
OracleAS Single Sign-On is a multi-part environment which is made up of both middle-tier and database functions allowing for a single user authentication across partner applications. An application can become a partner application that uses single sign-on either by using the SSOSDK or via the Apache mod_osso module. This module allows Apache (and subsequently URLS) to be made partner applications.
OracleAS Single Sign-On is fully integrated with Oracle Internet Directory, which stores user information. It supports LDAP-based user and password management through Oracle Internet Directory.
OracleAS Single Sign-On supports Public Key Infrastructure (PKI) client authentication, which enables PKI authentication to a wide range of Web applications. Additionally, it supports the use of X.509 digital client certificates and Kerberos Security Tickets for user authentication.
By means of an API, OracleAS Single Sign-On can integrate with third-party authentication mechanisms such as Netegrity Site Minder.
|
See Also: Oracle Application Server Single Sign-On Administrator's Guide. (This guide also includes Identity Management replication instructions.) |
Oracle Delegated Administration Services provide trusted proxy-based administration of directory information by users and application administrators. They employ a delegated administration model and application that enables the administrator of the Oracle Identity Management system to selectively delegate access rights to an administrator of an individual application, or directly to a user. Certain aspects of application administration can be delegated to users, which reduces the deployment cost of the applications.
With delegated administration, the management of the data inside the identity management system can be distributed to many different administrators depending upon their security requirements. This combination of centralized repository and delegated privileges results in secure and scalable administration in the identity management infrastructure.
Identity management privileges are created and granted to the bootstrap user who can further delegate these authorizations through the Oracle Delegated Administration Services self-service console. Some of these privileges include:
Common identity management operational privileges, such as user creation, user profile modification, and group creation
Privileges to install new Oracle applications using the identity management infrastructure
Privileges to administer Oracle Delegated Administration Services
Oracle Directory Integration and Provisioning consists of a set of services and interfaces built into Oracle Internet Directory that facilitate the development of synchronization and provisioning solutions between Oracle Internet Directory and other repositories, such as third-party directories (for example, SunONE Directory and Microsoft Active Directory Services), application user repositories (as might be stored in a flat file, for example), or database tables containing HR information.
Oracle Directory Integration and Provisioning includes a documented API and incorporates available industry standards where they exist, making it possible for Oracle Corporation, customers, and third parties to develop and deploy customized synchronization and provisioning solutions. It also facilitates interoperability between Oracle Internet Directory and third-party meta directory and provisioning solutions.
Oracle Directory Integration and Provisioning enables you to:
Synchronize data between Oracle Identity Management and other connected directories.
Send notifications to target applications to reflect changes to a user's status or information.
Develop and deploy your own connectivity agents.
Using Oracle Directory Integration and Provisioning, Oracle Identity Management leverages current investment in planning and deployment of a third-party enterprise directory. This provides the means to map and inherit major considerations such as directory naming, directory tree structure, schema extensions, access control, and security policies. Established procedures in an existing framework for user enrollment, identity, and account provisioning can be seamlessly incorporated into the corresponding operations of Oracle Identity Management.
Oracle Application Server Certificate Authority (OCA) issues, revokes, renews, and publishes X.509 v3 certificates to support PKI-based strong authentication methods. Usually, OCA is deployed on standalone mode.
|
Note: OCA cannot be installed as part of an Oracle Application Server Cluster (Identity Management). It has to be installed separately. |
The Infrastructure installation type installs Oracle HTTP Server for the Infrastructure. This is used to service requests from other distributed components of the Infrastructure and middle-tier instances. In the Infrastructure, Oracle HTTP Server services requests for OracleAS Single Sign-On and Oracle Delegated Administration Services. The latter is implemented as a servlet in an OC4J process in the Infrastructure.
In the Infrastructure, OC4J is installed in the Infrastructure to run Oracle Delegated Administration Services and OracleAS Single Sign-On. The former runs as a servlet in OC4J.
Oracle Delegated Administration Services provide a self-service console (for end users and application administrators) that can be customized to support third-party applications. In addition, it provides a number of services for building customized administration interfaces that manipulate Oracle Internet Directory data. Oracle Delegated Administration Services are a component of Oracle Identity Management.
|
See Also: Oracle Internet Directory Administrator's Guide for more information about Oracle Delegated Administration Services. |
Oracle Enterprise Manager 10g Application Server Control Console (Application Server Control Console) provides a Web-based interface for managing Oracle Application Server components and applications. Using the Oracle Application Server Console, you can do the following:
monitor Oracle Application Server components, Oracle Application Server middle-tier and Infrastructure instances, OracleAS Clusters, and deployed J2EE applications and their components
configure Oracle Application Server components, instances, OracleAS Clusters, and deployed applications
operate Oracle Application Server components, instances, OracleAS Clusters, and deployed applications
manage security for Oracle Application Server components and deployed applications
For more information on Oracle Enterprise Manager and its two frameworks, see Oracle Enterprise Manager Concepts.
|
See Also: Oracle Application Server Administrator's Guide - provides descriptions on Application Server Control Console and instructions on how to use it. |
As described earlier the OracleAS Infrastructure provides the following services
product metadata
security service
management service
From an availability standpoint, these services are provided by the following components, which must all be available to guarantee availability of the Infrastructure:
For the 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. Any high availability solution must be able to detect and recover from any type of software failures of any of the processes associated with the Infrastructure components. It must also be able to detect and recover from any type of hardware failures on the hosts that are running the Infrastructure.
In Oracle Application Server, all of the Infrastructure processes, except the database, its listener, and Application Server Control Console, are started, managed, and restarted by the Oracle Process Management and Notification (OPMN) framework. This means any failure of an OPMN-managed process is handled internally by OPMN. OPMN is automatically installed and configured at installation time. However, any database process failure or database listener failure is not handled by OPMN. Also, failure of any OPMN processes leaves the Infrastructure in a non-resilient mode if the failure is not detected and appropriate recovery steps are not taken. Refer to Section 2.2.1, "Process Death Detection and Automatic Restart" for further discussion on process management and monitoring.
This release of Oracle Application Server provides intra-site high availability solutions for the OracleAS Infrastructure, which can be generally categorized into the following:
Table 5-2 summarizes each of the above. In general, there are three solutions. One is active-active, the other two are active-passive. For each of these solutions, you can choose to have co-located Oracle Identity Management components or the OracleAS Single Sign-On and Oracle Delegated Administration Services components can be distributed out into 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, the OracleAS Metadata Repository can be installed in its own or existing cold failover database or an existing Real Application Clusters database.
Table 5-2 Summary of intra-site high availability solutions
The above high availability solutions provide protection from local hardware and software failures that cannot be detected and recovered by OPMN. Examples of such failures are a system panic or node crash. These solutions, however, cannot protect the Infrastructure from site failures or media failures, which result in damage to or loss of data.
Oracle Application Server provides a site-level active-passive disaster recovery solution to protect against disasters and site failures. This solution is described in Chapter 7, "Oracle Application Server Disaster Recovery".
A site failure or disaster will most likely affect all the systems including middle tiers, OracleAS Infrastructure, and backend databases. Hence, the disaster recovery solution also provides mechanisms to protect all components in the middle tier and OracleAS Infrastructure including any databases used by these components.
In short, the intra-site high availability solutions provide resilience for only the Infrastructure from local hardware and software failures. The middle tier can continue to function with a resilient Infrastructure. The Oracle Application Server Disaster Recovery solution, on the other hand, deals with a complete site failure, which requires failing over not only the Infrastructure but also the middle tier. The intra-site high availability solutions for the Infrastructure are discussed in the following sections.
In the case of media failures, the Oracle Application Server Backup and Recovery Tool provides a way for Oracle Application Server metadata, in both the OracleAS Metadata Repository database and file system, to be backed up for recovery if a storage media fails or if the metadata is somehow corrupted. For more details about this tool see Oracle Application Server Administrator's Guide.
The active-active solutions specifically provide active-active high availability for the Oracle Identity Management components. They are also known as Oracle Application Server Cluster (Identity Management) solutions.
Two OracleAS Cluster (Identity Management) solutions exist: non distributed and distributed Oracle Identity Management components. For both, the Oracle Identity Management components need not be installed on machines that are part of a hardware cluster.
Table 5-3 OracleAS Cluster (Identity Management) solutions (active-active)
| Solution | Description |
|---|---|
| OracleAS Cluster (Identity Management) | In the non distributed solution, all the Oracle Identity Management components are installed on each of two or more nodes. These nodes are deployed behind a load balancer, which directs requests to them. If a node fails, the load balancer directs requests to the remaining node(s). |
| Distributed OracleAS Cluster (Identity Management) | In the distributed solution, OracleAS Single Sign-On and Oracle Delegated Administration Services components are deployed on separate machines from Oracle Internet Directory and Oracle Directory Integration and Provisioning. These machines are fronted by a load balancer, which gives them active-active availability. Separating out OracleAS Single Sign-On and Oracle Delegated Administration Services components enable the other Oracle Identity Management components to be secured behind a firewall. |
Oracle Application Server Metadata Repository High Availability Options
For both of the above solutions, 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 Oracle Application Server 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:
Active-active solutions are presented in the following sections:
In this configuration, Oracle Identity Management components (Oracle Internet Directory, OracleAS Single Sign-On, Oracle Delegated Administration Services, and Oracle Directory Integration and Provisioning) are deployed together in two or more nodes. Each node runs all of the Oracle Identity Management components mentioned above. Traffic to these nodes is load balanced by a redundant load balancer. Figure 5-1 shows the layout of this configuration.
|
Note: Oracle Application Server Certificate Authority cannot be installed as part of an Oracle Application Server Cluster (Identity Management). It has to be installed separately. |
Figure 5-1 OracleAS Cluster (Identity Management) configuration
The nodes hosting the Oracle Identity Management components should be functionally equivalent. These nodes provide active-active availability for Oracle Identity Management services. OracleAS Single Sign-On and Oracle Delegated Administration Services are deployed in a single OC4J_SECURITY instance in each Oracle home. An Oracle Internet Directory process also runs in each node.
The load balancer can be configured with three virtual server names: one for single sign-on, one for Oracle Internet Directory, and one for the middle tier (as shown in Figure 5-1 ). The single sign-on virtual server name is used by requests from clients to access OracleAS Single Sign-On. The Oracle Internet Directory virtual server name is used by LDAP and JNDI requests from the middle tier and OracleAS Single Sign-On to access Oracle Internet Directory. And, clients use the middle-tier virtual server name to access the middle tier.
OracleAS Single Sign-On/Oracle Delegated Administration Services and Oracle Internet Directory access the database instances through Oracle Net load balancing. Note that OracleAS Single Sign-On establishes connection pools to access the database. A connection in the pool can be to any of the database instances in the Real Application Clusters cluster.
OPMN on each node provides process management, monitoring, and notification services for the OC4J_SECURITY instances and Oracle HTTP Server processes. When a process for one of these instances fails, OPMN detects the failure and attempts to restart it. If the restart is unsuccessful, the load balancer detects the failure (usually through a non response timeout) and directs requests to another active OC4J_SECURITY instance in another node of the Oracle Application Server Identity Management Cluster.
oidmon monitors the Oracle Internet Directory processes oidldapd, oidrepld and odisrv while OPMN monitors oidmon. If oidldapd, oidrepld, or odisrv fails, oidmon will attempt to restart it locally. Similarly, if oidmon fails, OPMN will try to restart it locally. Only one odisrv process and one oidrepld process can be active at any time in an OracleAS Cluster (Identity Management) while multiple oidldapd processes can run in the same cluster. Refer to Oracle Internet Directory Administrator's Guide for more details.
In the event an Oracle Identity Management node fails, the load balancer detects the failure and redirects requests to a remaining active node. Because each node provides identical services as the others, all requests will be fulfilled by the remaining nodes. For more information on Oracle Internet Directory in OracleAS Cluster (Identity Management) and how directory replication can provide high availability, see the OracleAS Cluster (Identity Management) chapter in the Oracle Internet Directory Administrator's Guide.
For the database tier, node failures are managed by Oracle Net and Real Application Clusters if the OracleAS Metadata Repository is installed in an existing Real Application Clusters database. Oracle Net redirects requests to remaining active database instances if any of the other database instances fail. If the OracleAS Metadata Repository is installed in a cold failover cluster database, node failure is performed by switching the virtual hostname and IP to the standby node and starting the relevant processes on that node. Section 6.2, "Managing Oracle Application Server Cold Failover Cluster (Infrastructure)" provides instructions on how to accomplish these tasks.
This configuration is a variation of that described in Section 5.3.1.1. Instead of co-locating all Oracle Identity Management components on each of the OracleAS Cluster (Identity Management) nodes, the OracleAS Single Sign-On and Oracle Delegated Administration Services components are distributed out to another set of OracleAS Cluster (Identity Management) nodes. Hence, this configuration, as shown in Figure 5-2, has three tiers: database (OracleAS Metadata Repository) tier, Oracle Internet Directory tier, and OracleAS Single Sign-On/Oracle Delegated Administration Services tier.
Figure 5-2 Distributed OracleAS Cluster (Identity Management) Configuration
The OracleAS Single Sign-On/Oracle Delegated Administration Services tier is fronted by a redundant load balancer that distributes requests to the nodes in this tier. The Oracle Application Server middle-tier and clients access OracleAS Single Sign-On and Oracle Delegated Administration Services using the virtual server name of this load balancer. (Note that the middle tier could also be installed in the same nodes as the OracleAS Single Sign-On and Oracle Delegated Administration Services nodes.)
The advantage of this configuration is that the nodes hosting the OracleAS Single Sign-On and Oracle Delegated Administration Services components can be deployed in the DMZ. That allows the Oracle Internet Directory to be deployed inside an intranet, protected by the firewalls (as depicted in Figure 5-2).
|
Note: Oracle Application Server Certificate Authority cannot be installed as part of an Distributed OracleAS Cluster (Identity Management). It has to be installed separately. |
The Oracle Application Server active-passive solutions use a cold failover cluster configuration on a hardware cluster. These solutions are explained in Table 5-4. The variations in the solutions are based on the way OracleAS Infrastructure components are set up and distributed.
Table 5-4 Overview of OracleAS Cold Failover Cluster solutions
| Solution | Description |
|---|---|
| OracleAS Cold Failover Cluster (Infrastructure)
|
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 components are installed together into the same Oracle home, which resides in the shared storage. A new database is installed at the same time for the OracleAS Metadata Repository.
Hence, OracleAS Metadata Repository and Oracle Identity Management are active together on one node and both are passive on the other node. This solution is the easiest to install and configure out-of-box. Details can be found in Section 5.3.2.1. |
| Distributed OracleAS Cold Failover Cluster (Infrastructure) | In this configuration, the OracleAS Single Sign-On and Oracle Delegated Administration Services components are installed in separate machines from the Oracle Internet Directory and Oracle Directory Integration and Provisioning components.
OracleAS Single Sign-On and Oracle Delegated Administration Services are installed in two or more machines that are load balanced by a load balancer router. OracleAS Single Sign-On and Oracle Delegated Administration Services are active-active. However, Oracle Internet Directory and Oracle Directory Integration and Provisioning are installed in an OracleAS Cold Failover Cluster with the OracleAS Metadata Repository. A new database is installed for the OracleAS Metadata Repository. The OracleAS Cold Failover Cluster enables active-passive availability. Note that for this configuration, OracleAS Single Sign-On/Oracle Delegated Administration Services are active-active, and Oracle Internet Directory and OracleAS Metadata Repository are active-passive. Details can be found in Section 5.3.2.2. |
| OracleAS Cold Failover Cluster (Identity Management)
|
This configuration requires the installation of Oracle Identity Management components in a hardware cluster. The OracleAS Metadata Repository is installed separately and can be installed in an existing database using OracleAS Metadata Repository Creation Assistant. Hence, 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.
Details can be found in Section 5.3.2.3. |
| Distributed OracleAS Cold Failover Cluster (Identity Management)
|
This configuration differs from the overall OracleAS Cold Failover Cluster (Identity Management) (Section 5.3.2.3) solution in that the OracleAS Single Sign-On and Oracle Delegated Administration Services components are installed in separate machines from the Oracle Internet Directory and Oracle Directory Integration and Provisioning components.
OracleAS Single Sign-On and Oracle Delegated Administration Services are deployed on separate machines from other Oracle Identity Management components. They can be installed on the OracleAS middle-tier machines and can have active-active availability as they are fronted by a load balancer. Separating out OracleAS Single Sign-On and Oracle Delegated Administration Services components enable the other Oracle Identity Management components to be secured behind a firewall. The other Oracle Identity Management components, Oracle Internet Directory and Oracle Directory Integration and Provisioning are installed on a two node active-passive cold failover hardware cluster. 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. This configuration is very similar to that in Section 5.3.2.2, "Distributed OracleAS Cold Failover Cluster (Infrastructure)". 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 for this configuration, OracleAS Single Sign-On/Oracle Delegated Administration Services are active-active, and Oracle Internet Directory server is active-passive. OracleAS Metadata Repository availability is dependent on the high availability configuration used by the database. Details of this solution can be found in Section 5.3.2.4. |
Oracle Application Server Metadata Repository High Availability Options
For the solutions in this section, various high availability options are available for the OracleAS Metadata Repository.
For the OracleAS Cold Failover Cluster (Infrastructure) solution and its distributed variant, a new database is installed for the OracleAS Metadata Repository. Hence, the OracleAS Metadata Repository is in a cold failover cluster database.
For the OracleAS Cold Failover Cluster (Identity Management) and its distributed variant, the OracleAS Metadata Repository is installed in an existing database. This database can be in one of the following:
This section is divided into the following:
Section 5.3.2.1, "OracleAS Cold Failover Cluster (Infrastructure)"
Section 5.3.2.2, "Distributed OracleAS Cold Failover Cluster (Infrastructure)"
Section 5.3.2.3, "OracleAS Cold Failover Cluster (Identity Management)"
Section 5.3.2.4, "Distributed OracleAS Cold Failover Cluster (Identity Management)"
Figure 5-3 shows the architecture of an OracleAS Cold Failover Cluster high availability solution with co-located Oracle Identity Management and OracleAS Metadata Repository. Co-location implies that Oracle Identity Management and OracleAS Metadata Repository are installed in the same Oracle home.
The architecture consists of a two-node cluster, which are attached to shared storage. The shared storage contains the single Oracle home shared by both nodes. Only one node, the active node, is mounted to the shared storage at any time.
Figure 5-3 Normal operation of OracleAS Cold Failover Cluster (Infrastructure)
Installation of the co-located OracleAS Cold Failover Cluster solution involves running the installer on a single node. A single ORACLE_HOME is then installed on the shared storage for both nodes. Only one node is active at any time and this active node mounts the shared storage and provides access to the ORACLE_HOME.
During the installation process, when asked to select the Infrastructure installation type, select "Identity Management and OracleAS Metadata Repository". The installer installs both OracleAS Metadata Repository and Oracle Identity Management components (Oracle Internet Directory server, Oracle Directory Integration and Provisioning, OracleAS Single Sign-On, and Oracle Delegated Administration Services) into an ORACLE_HOME in the shared storage. At the same time, a new database is installed for the OracleAS Metadata Repository.
Also during installation, a high availability addressing screen appears where you can specify the virtual hostname for the hardware cluster. This name is associated with the virtual IP of the hardware cluster and is used to access the active node of the OracleAS Cold Failover Cluster.
|
See Also: Oracle Application Server Installation Guide |
For illustration purposes as shown in Figure 5-3, assume a virtual/logical IP address of 144.25.245.1 is active on physical Node 1. Hence, Node 1 is the primary or active node. The virtual hostname, cfcinfra.mydomain.com, is mapped to this virtual IP address, and the middle tier associates the Infrastructure with cfcinfra.mydomain.com.
In normal operating mode, the hardware cluster's software enables the virtual IP 144.25.245.1 on physical Node 1 and starts all Infrastructure processes (database, database listener, Oracle Enterprise Manager 10g process, and OPMN) on that node. OPMN then starts, monitors, and restarts, if necessary, any of the following failed Infrastructure processes: Oracle Internet Directory, OC4J instances, and Oracle HTTP Server.
If the primary node fails, the virtual IP address 144.25.245.1 is manually enabled on the secondary node (Figure 5-4). All the Infrastructure processes are then started on the secondary node. The middle-tier processes accessing the Infrastructure will see a temporary loss of service as the virtual IP and the shared storage are moved over and the database, database listener, and all other Infrastructure processes are started. Once the processes are up, middle-tier processes that were retrying during this time are reconnected. New connections are not aware that a failover has occurred.
If you plan to use the Automatic Storage Management (ASM) feature of Oracle Database 10g for the OracleAS Metadata Repository, the CSS daemon must be configured on the standby node. The CSS daemon synchronizes ASM instances with the database instances that use the ASM instances for database file storage. Specific instructions are provided in the chapter on installing OracleAS Cold Failover Cluster in the Oracle Application Server Installation Guide.
Figure 5-4 OracleAS Cold Failover Cluster (Infrastructure) after primary node failover
While the hardware cluster framework can start, monitor, detect, restart, or failover Infrastructure processes, these actions are not automatic and involve some scripting or simple programming. Some of these details are discussed in Chapter 6.
For information on setting up and operating the OracleAS Cold Failover Cluster solution for the Infrastructure, see Oracle Application Server Installation Guide. This guide covers pre-installation, installation, and post-installation tasks, if any.
The co-located OracleAS Cold Failover Cluster high availability configuration provides the following capabilities:
The OracleAS Cold Failover Cluster solution consists of a two-node cluster accessing a shared disk (see Figure 5-5) that contains the Infrastructure's data files. At any point in time, only one node is active. During normal operation, the second node is on standby. OracleAS middle-tier components access the cluster through a virtual hostname that is mapped to a virtual IP in the subnet. In the example in Figure 5-5, the virtual hostname cfcinfra.mydomain.com and virtual IP 144.25.245.1 are used. When a failover occurs from node 1 to node 2, these virtual hostname and IP are moved to the standby node, which now becomes the active node. The failure of the active node is transparent to the OracleAS middle-tier components.
|
Note: Only static IP addresses can be used in the OracleAS Cold Failover Cluster (Infrastructure) solution for Windows. |
Figure 5-5 OracleAS Cold Failover Cluster (Infrastructure) for Windows
The concepts explained in Section 5.3.2.1, "OracleAS Cold Failover Cluster (Infrastructure)" are also applicable to the solution discussed here, which uses Microsoft Cluster Server software for managing high availability for the hardware cluster. Additionally, Oracle Fail Safe is used in conjunction with Microsoft Cluster Server to configure the following components:
OracleAS Infrastructure database
Oracle Process Manager and Notification Server service
Application Server Control Console
Central to the Windows OracleAS Cold Failover Cluster solution is the concept of resource groups. A group is a collection of resources defined through Oracle Fail Safe. During failover from the active node to the standby node, the group, and hence, the resources in it, failover as a unit. During installation and configuration of the OracleAS Cold Failover Cluster, a single group is defined for the solution. This group consists of the following:
Infrastructure database
OPMN
Application Server Control Console
The integration of Oracle Fail Safe and Microsoft Cluster Server provide an easy to manage environment and automatic failover functionality in the OracleAS Cold Failover Cluster solution. The Infrastructure database, its TNS listener, and OPMN are installed as Windows services and are monitored by Oracle Fail Safe and Microsoft Cluster Server. Upon failure of any of these Windows services, Microsoft Cluster Server will try to restart the service three times (default setting) before failing the group to the standby. Additionally, OPMN monitors, starts, and restarts the Oracle Internet Directory, OC4J, and Oracle HTTP Server processes.
|
See Also: Oracle Application Server Installation Guide for details on the installation process and requirements for installation. |
This is a solution where the middle tier, in a cold failover configuration, is co-located on the same nodes as the OracleAS Cold Failover Cluster (Infrastructure). The middle tier is in an OracleAS Cold Failover Cluster (Middle-Tier). The OracleAS Cold Failover Cluster (Infrastructure) and OracleAS Cold Failover Cluster (Middle-Tier) have separate virtual hostnames mapping to separate virtual IPs. This allows the Infrastructure to failover independently from the middle tier and vice versa.
In Figure 5-6, the Infrastructure is active on Node 1 while the middle tier is active on Node 2. If Node 2 fails, the middle tier can failover to Node 1. If Node 1 fails, the Infrastructure can failover to Node 2. By having the Infrastructure active on one node and the middle tier active on the other node during normal operation, resources are efficiently utilized as both nodes are performing work and no node is idle. This configuration also provides high performance isolation since the middle tier and the OracleAS Infrastructure services run in separate environments. See Oracle Application Server Installation Guide for instructions on installing such a configuration.
Figure 5-6 OracleAS Cold Failover Cluster (Middle-Tier) on the same nodes as OracleAS Cold Failover Cluster (Infrastructure)
In the previous sections describing OracleAS Cold Failover Cluster (Infrastructure), Oracle Identity Management components are deployed together in an OracleAS Cold Failover Cluster with OracleAS Metadata Repository.
To provide more robust security, the OracleAS Single Sign-On and Oracle Delegated Administration Services components of Oracle Identity Management can be deployed separately from the Oracle Internet Directory and Oracle Directory Integration and Provisioning components (in a DMZ, for example). In such a set up, OracleAS Single Sign-On and Oracle Delegated Administration Services components are installed in two nodes in an active-active configuration. They are installed on their own nodes or are co-located with other Oracle Application Server middle-tier components. These nodes are front-ended by a hardware load balancer to enable load balancing and failover between the two nodes. Clients connect to OracleAS Single Sign-On and Oracle Delegated Administration Services using a virtual server name configured in the load balancer (sso.mydomain.com in Figure 5-7).
Figure 5-7 provides a diagrammatic example of this configuration.
Figure 5-7 Distributed OracleAS Cold Failover Cluster (Infrastructure) deployment
In the example presented in Figure 5-7, the OracleAS Single Sign-On and Oracle Delegated Administration Services components are deployed between two firewalls. The figure shows the OracleAS middle-tier installed on the same nodes as OracleAS Single Sign-On and Oracle Delegated Administration Services.
Clients from outside the first firewall can access single sign-on and self-service directory administration services; the second firewall prevents clients from accessing the identity and metadata repositories directly.
The above configuration also allows straightforward active-active installation and deployment of OracleAS Single Sign-On and Oracle Delegated Administration Services. Failover and load balancing for these components are performed by a redundant load balancer. If there is no firewall separating the middle tier and OracleAS Single Sign-On and Oracle Delegated Administration Services components, the same load balancer can be configured to load balance the middle tier also.
Other Oracle Identity Management components, the Oracle Internet Directory and Oracle Directory Integration and Provisioning, are deployed in the same OracleAS Cold Failover Cluster as the OracleAS Metadata Repository. Failover from the active node to the passive node occurs at the node level. Hence, Oracle Internet Directory, Oracle Directory Integration and Provisioning, and OracleAS Metadata Repository fail over together.
During runtime, the following applies:
Only one node of the hardware cluster is active. The virtual hostname (oidmr.mydomain.com) is occupied by the active node. The shared disk is mounted only on the active node.
Oracle Internet Directory accesses its repository through the active database instance.
OracleAS Single Sign-On accesses its schema in the database using connection pools over JDBC (and hence, Oracle Net). These connection pools are established to the active node in the OracleAS Cold Failover Cluster.
OracleAS Single Sign-On and Oracle Delegated Administration Services use the OracleAS Cold Failover Cluster (Infrastructure)'s virtual hostname (oidmr.mydomain.com in the above example) to access the Oracle Internet Directory process in the active node.
OracleAS Single Sign-On and Oracle Delegated Administration Services applications are deployed in the single OC4J_SECURITY instance on their respective nodes.
OPMN performs process management tasks in the OracleAS Single Sign-On and Oracle Delegated Administration Services nodes.
|
See Also: Oracle Application Server Installation Guide. for installation details of this configuration |
For this configuration, Oracle Identity Management is installed in a OracleAS Cold Failover Cluster. Two installations are performed on the same hardware cluster, one for Oracle Identity Management and one for OracleAS Metadata Repository. This allows Oracle Identity Management components to be installed in a cold failover configuration and the OracleAS Metadata Repository in an existing database. This database can be a Real Application Clusters database that is already installed in the hardware cluster(shown in Figure 5-8). Alternatively, the database can be in a cold failover cluster configuration. The cold failover configuration provides the database with active-passive availability while the Real Application Clusters database has active-active availability. The installation of OracleAS Metadata Repository is performed using OracleAS Metadata Repository Creation Assistant.
Each installation has its unique Oracle home that is a different path from the other. Figure 5-8 shows two shared disks with an Oracle home in each. Both Oracle homes may also be installed in one shared disk as long as their paths are unique.
Figure 5-8 OracleAS Cold Failover Cluster (Identity Management) (with OracleAS Metadata Repository installed in a cold failover database shown)
A virtual IP address is used to represent the active node for Oracle Identity Management components. A virtual hostname is mapped to this address. This virtual hostname is used by the middle tier and clients to access the Oracle Identity Management components.
Middle-tier components and applications access Oracle Identity Management services by making LDAP requests to Oracle Internet Directory, HTTP/HTTPS requests to OracleAS Single Sign-On or Oracle Delegated Administration Services. Clients can perform single sign-on by making direct HTTP/HTTPS requests to OracleAS Single Sign-On server via the single sign-on URL. OracleAS Single Sign-On establishes connection pools to access the OracleAS Metadata Repository database. A connection in the pool uses Oracle Net to communicate with the active database instance(s). Oracle Net is also used by middle-tier components and Oracle Internet Directory servers to connect to the database.
Both Oracle Identity Management and OracleAS Metadata Repository are active in Node 1. In Node 2, all components are passive, on standby, unless the database that contains the OracleAS Metadata Repository is a Real Application Clusters database. In this case, the database instance is active on Node 2.
This configuration is similar to that described in Section 5.3.2.3, "OracleAS Cold Failover Cluster (Identity Management)" except for the deployment of OracleAS Single Sign-On and Oracle Delegated Administration Services components in their own nodes. Requests to these nodes are load balanced by a load balancer router, thus, enabling OracleAS Single Sign-On and Oracle Delegated Administration Services to have active-active availability.
Oracle Internet Directory is installed on its own two-node OracleAS Cold Failover Cluster with shared storage. In this configuration, Oracle Internet Directory has active-passive availability.
For the OracleAS Metadata Repository, it can be installed, using OracleAS Metadata Repository Creation Assistant, in an existing Real Application Clusters database for active-active availability. Otherwise, it can be installed in a cold failover cluster database for active-passive availability. If a cold failover database is used, the OracleAS Metadata Repository has its own virtual hostname and virtual IP that is different from those of Oracle Internet Directory.
Figure 5-9 shows the distributed OracleAS Cold Failover Cluster (Identity Management) configuration with the OracleAS Metadata Repository in a cold failover cluster database.
Figure 5-9 Distributed OracleAS Cold Failover Cluster (Identity Management) with OracleAS Metadata Repository in an existing cold failover cluster database
This section contains considerations for backup and recovery for the Infrastructure. It has the following sections:
|
Note: Complete procedures for backup and recovery of the OracleAS Infrastructure are documented in the Oracle Application Server Administrator's Guide. |
When performing backup and recovery operations for a OracleAS Cold Failover Cluster, take note of the following:
backup considerations for OracleAS Cold Failover Cluster:
Oracle recommends that you locate archive logs for the OracleAS Metadata Repository on the shared disk. This ensures that when failing 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. Hence, 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 equivalents), each Oracle Identity Management installation needs to be backed up and restored individually. The backup performed on each Oracle Identity Management installation can be restored only on the respective instance in case of any failure.
If the DCM repository is located in the Infrastructure database, the OracleAS Backup and Recovery Tool requires at least one Oracle Internet Directory process to be up 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 bring up the Oracle Internet Directory process on that node. Subsequently, you canthen perform the restore operation on other Oracle Identity Management nodes.
If you lose an Oracle Identity Management node completely and need to restore it to a new node, please refer to 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, execute thedcmctl whichfarm command and check for the "Repository Type: Database" or "Repository Type: Database (host)" line in the output.
|
