| Oracle® Application Server High Availability Guide 10g (10.1.4.0.1) Part Number B28186-01 |
|
|
View PDF |
| Oracle® Application Server High Availability Guide 10g (10.1.4.0.1) Part Number B28186-01 |
|
|
View PDF |
Oracle Application Server local high availability topologies include several active-active and active-passive topologies. Within each type of topology, multiple solutions exist that differ in ease of installation, cost, scalability, and security.
This chapter contains the following sections:
You can group Oracle Application Server high availability topologies into two categories: active-active and active-passive: Table 2-1 summarizes the topology types.
Table 2-1 High Availability Topology Types
| Topology | Description |
|---|---|
|
In active-active topologies, you run multiple active Oracle Application Server instances 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 for Oracle Application Server are also called OracleAS Clusters topologies. Specifically, active-active topologies for Oracle Identity Management are also called "OracleAS Cluster (Identity Management)" topologies. Active-active topologies are: |
|
|
In active-passive topologies, you have two nodes in a hardware cluster, 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 in Oracle Application Server are also called OracleAS Cold Failover Cluster topologies. Active-passive topologies are: |
Although all topologies provide high availability, active-active solutions generally offer higher scalability and faster failover. On the downside, they tend to be more expensive.
For all topologies, you can install and run the Oracle Application Server components together (that is, from the same Oracle home), or you can install and run them in a distributed manner (that is, on separate nodes and separate Oracle homes).
Table 2-2 compares how components are distributed in the Oracle Application Server topologies. Later chapters in this guide provide details.
Table 2-2 Distribution of Components in High Availability Topologies
| Topology | OracleAS Metadata Repository |
Oracle Identity Management |
|---|---|---|
|
OracleAS Cluster (Identity Management) Topology |
Installed in an existing database. |
Installed in an active-active configuration. |
|
DistributedOracleAS Cluster (Identity Management) Topology |
Installed in an existing database. |
Oracle Internet Directory and Oracle Directory Integration Platform: installed in an active-active configuration. OracleAS Single Sign-On and Oracle Delegated Administration Services: installed in an active-active configuration. |
|
OracleAS Cold Failover Cluster (Infrastructure) Topology |
Installer installs the Oracle Identity Management components and a new database for the OracleAS Metadata Repository in an active-passive configuration. In the installer, you select the "Identity Management and OracleAS Metadata Repository" installation type. |
Oracle Identity Management components are installed together with the OracleAS Metadata Repository in the same Oracle home in an active-passive configuration. |
|
Distributed OracleAS Cold Failover Cluster (Infrastructure) Topology |
Installer installs the Oracle Identity Management components and a new database for the OracleAS Metadata Repository in an active-passive configuration. In the installer, you select the "Identity Management and OracleAS Metadata Repository" installation type. |
Oracle Internet Directory and Oracle Directory Integration Platform: installed together with OracleAS Metadata Repository in active-passive configuration. OracleAS Single Sign-On and Oracle Delegated Administration Services: installed separately from the other components in an active-active or active-passive configuration. |
|
OracleAS Cold Failover Cluster (Identity Management) Topology |
Installed in an existing database. |
Installed in an active-passive configuration. |
|
DistributedOracleAS Cold Failover Cluster (Identity Management) Topology |
Installed in an existing database. |
Oracle Internet Directory and Oracle Directory Integration Platform: installed in an active-passive configuration. OracleAS Single Sign-On and Oracle Delegated Administration Services: installed in an active-active or active-passive configuration. The active-active configuration is the more common configuration in this topology. |
Oracle Application Server provides an active-active model for its components in OracleAS Clusters topologies. In an OracleAS Clusters, two or more Oracle Application Server instances are configured to serve the same application workload. These instances typically run on different nodes. These nodes do not need to be in a hardware cluster.
You need an external load balancer in front of the nodes. Clients direct requests to these nodes through the load balancer, which then sends the requests to one of the nodes for processing. The load balancer uses its own algorithm to decide which node to send a request to.
You configure the load balancer with a virtual server name and port. When clients need to access an Oracle Identity Management component running on the nodes, they use this virtual server name and port.
In general, the term OracleAS Clusters describes clustering at the Oracle Application Server instance level. However, if it is necessary to call out the specific type of instances being clustered, this document uses the term "OracleAS Clusters (type)" to characterize the cluster solution. For example:
two or more Oracle Identity Management instances are known as OracleAS Cluster (Identity Management)
two or more J2EE instances are known as OracleAS Clusters (J2EE)
Common properties of an OracleAS Clusters topology include:
Identical instance configuration
The instances are meant to serve the same workload or application. Their identical configuration guarantees that they deliver identical responses to the same request. Note that some configuration properties are allowed to be instance-specific, such as local host name information.
Managed as a virtual single instance
Changes in configuration made to one instance usually need to be propagated to the other instances in an active-active topology.
Independent operation
The loss of one Oracle Application Server instance in an active-active topology should not affect the ability of the other instances to continue to serve requests.
Advantages of an OracleAS Clusters topology include:
Increased availability
An active-active topology has built-in redundancy (multiple Oracle Application Server instances run the same components). Loss of one instance can be tolerated because other instances can continue to serve the same requests.
Increased scalability and performance
Multiple identically-configured instances provide the capability to have a distributed workload shared among different machines and processes. New instances can also be added as the demand of the application grows.
In 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 RepCA to install the directory store and OracleAS Metadata Repository into an existing database that is already configured for high availability, such as:
Oracle Application Server provides an active-passive model for its components using OracleAS Cold Failover Clusters. In an OracleAS Cold Failover Cluster topology, two Oracle Application Server instances are configured to serve the same application workload but only one instance is active at any particular time. These instances run on two different nodes in a hardware cluster. These two nodes also have access to a shared storage, on which you install the Oracle home for the Oracle Application Server instance.
One of the nodes in the hardware cluster is the active node. It mounts the shared storage and runs the Oracle Application Server instance. The other node is the passive, or standby, node. It runs only when the active node fails. During the failover event, the passive node mounts the shared storage and runs the Oracle Application Server instance.
You also need a virtual hostname and virtual IP address to associate with the nodes in the hardware cluster. Clients use this virtual hostname to access the Oracle Application Server components. During normal operation, the virtual hostname and IP address are associated with the active node. During failover, you make the switch: the virtual hostname and IP address are now associated with the passive node.
In general, the term OracleAS Cold Failover Cluster describes clustering at the Oracle Application Server instance level. However, if it is necessary to call out the specific type of instances being clustered, this document will use OracleAS Cold Failover Cluster (type) to characterize the cluster solution. For example
OracleAS Cold Failover Cluster (Identity Management)
OracleAS Cold Failover Cluster (Middle-Tier)
Common properties of an OracleAS Cold Failover Cluster topology include:
The Oracle home for the Oracle Application Server instance is typically installed on storage that is shared by the nodes in the OracleAS Cold Failover Cluster topology. The passive Oracle Application Server instance has access to the same Oracle binaries, configuration files, and data as the active instance.
Virtual hostname
During OracleAS Infrastructure installation, you can specify a virtual hostname. This OracleAS Infrastructure virtual hostname can be managed by a hardware cluster or a load balancer and is used by middle-tier and OracleAS Infrastructure components to access the OracleAS Infrastructure.
The virtual hostname is associated with a virtual IP. This is the name that gives the Oracle Application Server middle tiers a single system view of the OracleAS Infrastructure with the help of a hardware cluster or load balancer. This name-IP entry must be added to the DNS that the site uses, so that the middle-tier nodes can associate with the OracleAS Infrastructure without having to add this entry into their local /etc/hosts (or equivalent) file. For example, if the two physical hostnames of the hardware cluster are node1.mycompany.com and node2.mycompany.com, the single view of this cluster can be provided by the name selfservice.mycompany.com. In the DNS, selfservice maps to the virtual IP address of the OracleAS Infrastructure, which either floats between node1 and node2 via a hardware cluster or maps to node1 and node2 by a load balancer, all without the middle tier knowing which physical node is active and actually servicing a particular request.
Failover procedure
OracleAS Cold Failover Cluster topologies also include a set of scripts and procedures to detect failure of the active instance and to fail over to the passive instance while minimizing downtime.
Advantages of an OracleAS Cold Failover Cluster topology include:
Increased availability
If the active instance fails for any reason or must be taken offline, the passive instance is prepared to take over at any time.
Reduced operating costs
In OracleAS Cold Failover Cluster topologies, only one set of Oracle Application Server processes is up and serving requests. Management of the active instance is generally easier than managing an array of active instances.
Application independence
Some applications may not be suited to run in an OracleAS Clusters, or active-active, topology. This may include applications that rely heavily on application state or on information stored locally. An active-passive topology has only one instance serving requests at any particular time.
In OracleAS Cold Failover Cluster topologies, you have the following high availability options for the OracleAS Metadata Repository.
For the OracleAS Cold Failover Cluster (Infrastructure) and distributed OracleAS Cold Failover Cluster (Infrastructure) topologies, the OracleAS Metadata Repository is installed in a new 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:
In high availability topologies, you can install and run the Oracle Identity Management components from the same Oracle home or you can distribute them to run them on different nodes.
For the collocated topologies, which are:
OracleAS Cluster (Identity Management)
OracleAS Cold Failover Cluster (Infrastructure)
OracleAS Cold Failover Cluster (Identity Management)
you run the Oracle Identity Management components from the same Oracle home.
Reasons for choosing a collocated topology over a distributed topology include lower cost (you need fewer machines) and ease of management. However, if you need to run some components on nodes that are more secure (located behind additional firewalls), then you need to distribute the Oracle Identity Management components.
For the distributed topologies:
Distributed OracleAS Cluster (Identity Management)
Distributed OracleAS Cold Failover Cluster (Infrastructure)
Distributed OracleAS Cold Failover Cluster (Identity Management)
you install and run the Oracle Identity Management components on separate nodes. A common distribution model is:
Oracle Internet Directory and Oracle Directory Integration Platform on one set of nodes
OracleAS Single Sign-On and Oracle Delegated Administration Services on a different set of nodes
The components are separated in this manner because OracleAS Single Sign-On and Oracle Delegated Administration Services are typically the first components to be accessed by clients and other components. You can run these components on nodes in the DMZ.
For the Oracle Internet Directory and your databases (including the OracleAS Metadata Repository), these components are repositories of data that you want to secure. You should run these components on more secure nodes located behind an additional firewall.
Reasons for distributing the Oracle Identity Management components include:
Security: You might want to run some components, typically the Oracle Internet Directory and database, on nodes that are located behind additional firewalls.
Performance: You may get better performance by running the components on multiple nodes.
Choice of high availability topology: You can configure different high availability models for each tier. For example, in the DistributedOracleAS Cold Failover Cluster (Identity Management) Topology, you run OracleAS Single Sign-On and Oracle Delegated Administration Services in an active-active configuration, but run Oracle Internet Directory in an active-passive configuration.
Performance isolation: You can scale each set of components independently of each other. For example, if the bottleneck is in OracleAS Single Sign-On, you can just increase the number of nodes that are running OracleAS Single Sign-On without changing the number of nodes that are running Oracle Internet Directory.
There is no single best high availability solution for all systems in the world, but there may be a best solution for your system. Perhaps the most important decision in designing a highly available system is choosing the most appropriate high availability architecture or type of redundancy based on service-level requirements needed by a business or application. Understanding the availability requirements of the business is critical since cost is also associated with the different levels of high availability.
Oracle Application Server offers many high availability solutions to meet different service-level requirements. The most comprehensive solution may not necessarily be the best for your business. To choose the correct high availability topology, ensure you understand your business's service-level requirements first.
Here are some questions to determine your high availability needs:
Local high availability: does your production system need to be available 24 hours per day, 7 days per week, and 365 days per year?
Scalability: is the scalability of multiple active Oracle Application Server instances required?
Site-to-site disaster recovery: is this required?
Based on the answers to these questions, you need to make your selection in two dimensions:
Instance redundancy: base, active-active, or active-passive.
Site-to-site disaster recovery-enabled architecture: yes or no.
Table 2-3 shows the topology choices based on business requirements.
Table 2-3 Service-Level Requirements and Topology Choices
| Business Requirements | Topology Choices | |||
|---|---|---|---|---|
| Local High Availability | Scalability | Disaster Recovery | Instance Redundancy | Disaster Recovery |
|
N |
N |
N |
Base |
N |
|
Y |
N |
N |
Active-passive |
N |
|
N |
Y |
N |
Active-active |
N |
|
N |
N |
Y |
Base |
Y |
|
Y |
Y |
N |
Active-active |
N |
|
Y |
N |
Y |
Active-passive |
Y |
|
N |
Y |
Y |
Active-active (middle tier) Base (Infrastructure)Foot 1 |
Y |
|
Y |
Y |
Y |
Active-active (middle tier) Active-passive and active-active (Infrastructure)Footref 1 |
Y |
Footnote 1 OracleAS Disaster Recovery supports the base, active-passive, and active-active OracleAS Infrastructure architectures. For additional scalability in a base, active-passive, or active-active architecture, extra computing power can be added to the infrastructure hardware (for example, high capacity CPUs, more memory).
Although you can choose different high availability topologies for your Oracle Application Server middle tier and OracleAS Infrastructure, their local high availability and disaster recovery requirements should be identical. Scalability requirements should be evaluated separately for Oracle Application Server middle tier and OracleAS Infrastructure. Typically the OracleAS Infrastructure does not need to be as scalable as the middle tier because it handles fewer identity management requests.
Because of the differences in scalability requirements, deployment choices for the middle tier and the OracleAS Infrastructure may differ in architecture. For example, if your deployment requires local high availability, site-to-site disaster recovery, scalable middle tier but basic OracleAS Infrastructure scalability, you can choose an active-active middle tier, an active-passive OracleAS Infrastructure, and deploy a standby disaster recovery site that mirrors all middle tier and OracleAS Infrastructure configuration in the production site.
