| Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard 10g Release 2 (10.1.2.3) Part Number E11078-02 |
|
|
View PDF |
| Oracle® Application Server Disaster Recovery Guide Using OracleAS Guard 10g Release 2 (10.1.2.3) Part Number E11078-02 |
|
|
View PDF |
Disaster recovery refers to how a system recovers from catastrophic site failures caused by natural or unnatural disasters. Examples of catastrophic failures include earthquakes, tornadoes, floods, or fire. Additionally, disaster recovery can also refer to how a system is managed for planned outages. For most disaster recovery situations, the solution involves replicating an entire site, not just pieces of hardware or subcomponents. This also applies to the Oracle Application Server Disaster Recovery (OracleAS Disaster Recovery) solution.
The Oracle Application Server Disaster Recovery Guide Using OracleAS Guard is intended for administrators, developers, and others whose role is to deploy and manage Oracle Application Server in Disaster Recovery environments using the Oracle Application Server Guard (OracleAS Guard) utility.
The information in this manual replaces the Disaster Recovery chapters and appendixes in the 10.1.x releases of the Oracle Application Server High Availability Guide, which included information about the OracleAS Guard utility. This manual assumes that you have read and are familiar with the High Availability information in the Oracle Application Server High Availability Guide.
Note:
This manual describes how to use OracleAS Guard for disaster protection of your Oracle Application Server deployment. If you are already using OracleAS Guard for disaster protection of your present Oracle Application Server deployment, then the information in this manual can help you manage it.However, if you are planning a new Oracle Application Server deployment that needs disaster protection, Oracle recommends that you use disk replication to provide disaster protection for the Oracle Application Server deployment. For more information on how to provide disaster protection for Oracle Application Server deployments using disk replication, refer to the Oracle Application Server Disaster Recovery Guide for Oracle Application Server release 10.1.3.3.0.
This chapter describes the OracleAS Disaster Recovery solution, how to configure and set up its environment, and how to manage the solution for high availability. The discussion involves both OracleAS middle tiers and OracleAS Infrastructure tiers in two sites: production and standby. The standby site is configured either identically and symmetrically (same number of instances) or asymmetrically to the production site (fewer instances or OracleAS Disaster Recovery capability for only the Infrastructure services is supported). Under normal operation, the production site actively services requests. The standby site is maintained to mirror or closely mirror the applications and content hosted by the production site.
The term topology refers to all Oracle Application Server instances that share the same Oracle Internet Directory for an OracleAS Disaster Recovery production site. The discover topology command queries Oracle Internet Directory to determine the list of instances and then generates a topology.xml file that describes the production site topology. The discover topology within farm command is used in cases where Oracle Internet Directory is not available (for example, in Oracle Application Server 10.1.3 environments); in this case, Oracle Application Server Guard uses OPMN to discover the topology within the farm.
The OracleAS Disaster Recovery aspects of these sites are managed using Oracle Application Server Guard, which contains a command-line utility (asgctl) that encapsulates administrative tasks (see Chapter 5, "Oracle Application Server Guard asgctl Command-line Reference" for reference information about these administrative commands). The OracleAS Disaster Recovery solution leverages the following services among other system services that are available across the entire site. Behind the scenes Oracle Application Server Guard automates the use of OracleAS Recovery Manager (for managing configuration files in the file system) and Oracle Data Guard (for managing the OracleAS Infrastructure database) in a distributed fashion across the topology. Table 1-1 provides a summary of the OracleAS Disaster Recovery strategy and how this Oracle software is used behind the scenes:
Table 1-1 Overview of OracleAS Disaster Recovery Strategy
You can use the add instance command to manually add any database instances besides the OracleAS Infrastructure database to the topology as part of the disaster recovery solution.
Note:
You must configure Oracle Data Guard for every database in your OracleAS Disaster Recovery topology. See Section 1.1.1.1, "Configuring Oracle Data Guard for Databases in an OracleAS Disaster Recovery Topology" for more information about configuring Oracle Data Guard for the databases in your OracleAS Disaster Recovery topology.In addition to the recovery strategies, this chapter discusses configuration and installation of both sites. For these tasks, two different ways of naming the middle-tier nodes are covered as well as two ways of resolving hostnames intra-site and inter-site.
With OracleAS Disaster Recovery, planned outages of the production site can be performed without interruption of service by switching over to the standby site using the Oracle Application Server Guard switchover operation. Unplanned outages are managed by failing over to the standby site using the Oracle Application Server Guard failover operation. Procedures for switchover and failover are covered in Section 2.9, "Runtime Operations -- Oracle Application Server Guard Switchover and Failover Operations".
This chapter is organized into the following sections:
Section 1.1, "Oracle Application Server 10g Disaster Recovery Solution"
Section 1.2, "Preparing the OracleAS Disaster Recovery Environment"
Section 1.4, "Overview of Installing Oracle Application Server"
See Also:
Oracle Application Server Installation Guide for instructions about how to install the OracleAS Disaster Recovery solution.The Oracle Application Server Disaster Recovery solution consists of two configured sites - one primary (production/active) and one secondary (standby). Both sites may or may not have the following: same number of middle tiers and the same number of OracleAS Infrastructure nodes, and the same number of components installed. In other words, the installations on both sites, middle tier and OracleAS Infrastructure could be identical (symmetrical topology) or not identical (asymmetrical topology). Both sites are usually dispersed geographically, and if so, they are connected through a wide area network.
Some important points to emphasize for the Oracle Application Server Disaster Recovery solution are the following:
The number of instances required on the standby site to run your site can be identical to (symmetric) or fewer (asymmetric) than the production site.
The set of instances needed must be created on the standby site for Disaster Recovery set up. You can create the instances at the standby site by installing them using Oracle Universal Installer or by cloning them from the production site using the asgctl clone instance command or the asgctl clone topology command. See Section 2.7.1, "Cloning Single or Multiple Production Instances to a Standby System" for more information on cloning.
The standby site needs the minimum set of instances required to run your site.
This section describes the overall layout of the solution, the major components involved, and the configuration of these components. It has the following sections:
To ensure that your implementation of the OracleAS Disaster Recovery solution performs as designed, the following requirements must be adhered to:
On each host in the standby site, make sure the following is identical to its equivalent peer in the production site:
For the middle-tier hosts, physical hostnames.
Note:
If you already have installed systems, you must only modify the physical names for the middle-tier systems at the standby site to match the physical and network hostname of the peer systems at the production site. Then create a virtual hostname for the physical hostname of the OracleAS Infrastructure at the standby site to match the virtual hostname of the OracleAS Infrastructure at the production site. See Section 1.2.1, "Planning and Assigning Hostnames" for information about physical hostnames, network hostnames, and virtual hostnames. See the Glossary for a definition of physical hostname, network hostname, and virtual hostname.Port number usage. Make sure that no port number conflicts exist for production site and standby site peer hosts.
Hardware platform
Operating system release and patch levels
All installations conform to the requirements listed in the Oracle Application Server Installation Guide to install Oracle Application Server.
The following details must be the same between a host in the production site and a peer in the standby site:
User name and password of the user who installed Oracle Application Server must be the same between a host in the production site and its peer in the standby site.
Numerical user ID of the user who installed Oracle Application Server on that particular node
Group name of the user who installed Oracle Application Server on that particular node
Numerical group ID of the group for the user who installed Oracle Application Server on that particular node
Environment profile
Shell (command-line environment)
Directory structure, Oracle home names, and path of the Oracle home directory for each OracleAS installation on a node. Do not use symbolic links anywhere in the path.
Oracle Application Server installation types (Any instance installed on the standby system must be identical to that installed on the production system):
The SID names must be the same for Oracle database peers at a Disaster Recovery primary site and standby site(s).
Entries in TNSNAMES.ORA files for databases at a production site or standby site should include the domain name.
Any database in an Oracle Application Server Disaster Recovery topology must be configured by Oracle Data Guard, so that Oracle Data Guard will ship archive logs from the primary database at the production site to the standby database at the standby site.
Note:
Before you attempt to configure Oracle Data Guard for a database, use the asgctl
dump topology command to ensure that the database is included in the Disaster Recovery topology at the primary site. If the database is not included in the Disaster Recovery topology at the primary site, use the asgctl add instance command first to add the database to the topology. Then use Table 1-2 to choose an appropriate method of configuring Oracle Data Guard for the primary database at the primary site and the standby database at the standby site.Table 1-2 assumes that you have created the primary database at the primary site, and the database is included in the Disaster Recovery topology for the primary site.
Table 1-2 shows the supported methods of configuring Oracle Data Guard for different types of databases that can be included in your Disaster Recovery topology.
Table 1-2 Configuring Data Guard for Databases in an OracleAS Disaster Recovery Topology
| Database Type at Primary Site | Method(s) of Configuring Oracle Data Guard for the Database |
|---|---|
|
A database with the Metadata Repository schemas that is created during an Application Server Infrastructure installation in the Application Server homeFoot 1 |
You can use either of these methods:
For more information about configuring Oracle Data Guard using these commands, refer to the reference information for the clone instance, clone topology, and instantiate topology commands. |
|
A single instance or RAC database installed outside an Application Server home that does not use the Oracle Managed Files (OMF) or Automatic Storage Management (ASM) database storage options |
Use the For more information about configuring Oracle Data Guard using the After using the |
|
A single instance or RAC database installed outside an Application Server home that uses either the Oracle Managed Files (OMF) or Automatic Storage Management (ASM) database storage option |
Create the standby database and configure Oracle Data Guard for the production and standby databases by following the instructions in the "Creating a Standby Database that Uses OMF or ASM" section of Oracle Data Guard Concepts and Administration in the Oracle Database documentation set. Then, perform a |
Footnote 1 The only type of database that Disaster Recovery supports in an Oracle Application Server home is a database that includes that Metadata Repository schemas and which was created during an Application Server Infrastructure installation in the Application Server home.
When you use the asgctl clone instance, clone topology, instantiate topology, or create standby database command to configure Oracle Data Guard for primary and standby databases in your Disaster Recovery topology, the following Oracle Data Guard configuration is set up by Oracle Application Server Guard:
The primary database is set up with the maximum availability data protection mode.
The standby database is set up with the LGRW SYNC and AFFIRM archive attributes for the LOG_ARCHIVE_DEST_n parameter.
In some cases, for example, if you are using BPEL Process Manager, you may want to change the default Oracle Data Guard configuration set up by Oracle Application Server Guard. For more information, see Section A.1.1, "Changing the Default Oracle Data Guard Configuration Set Up by Oracle Application Server Guard."
Oracle Application Server Guard (ASG) supports Oracle Application Server release 10g (10.1.2.0.0, 10.1.2.0.2, 10.1.2.1, 10.1.2.2, 10.1.2.3, 10.1.3.0.0, 10.1.3.1.0, 10.1.3.2.0, and 10.1.3.3.0). By default, when you install an Oracle Application Server instance using any Oracle Application Server installation type that also installs a JDK or JRE environment, a particular release of ASG is installed into the Oracle home when the instance is installed.
You must also install ASG on standalone hosts on which external resources (such as an Oracle database) are located that you want to include in your OracleAS Disaster Recovery topology.
Multiple releases of ASG are available. It is possible (recommended) in some cases to upgrade the ASG release that was installed in an Oracle Application Server instance home when you installed that instance. To upgrade the ASG release in an Oracle Application Server instance home, download the ASG standalone kit for the recommended ASG release from the Oracle Technology Network (OTN), and then use that ASG standalone kit to install the recommended ASG release into the home.
You can access the Oracle Technology Network at:
http://www.oracle.com/technology/index.html
Use the ASG standalone kit to install ASG on standalone hosts that you want to include in your OracleAS Disaster Recovery topology. The ASG standalone kit must be installed in its own home on any host that has a database Oracle home that you want to include in your Disaster Recovery topology (except on a host that has a database with the Metadata Repository schemas that is created during an Application Server Infrastructure installation in the Application Server home). After you install the ASG standalone kit on a database host, use the asgctl add instance command to add the database instance to your Disaster Recovery topology.
You must install the ASG kit on all systems with Oracle homes or Oracle Application Server instances that you want to include in your Disaster Recovery topology. See the OracleAS Disaster Recovery installation information in Oracle Application Server Installation Guide for more information.
Use Table 1-3 and Table 1-4 to determine whether a particular ASG release is compatible when installed into an Application Server instance home for a particular Oracle Application Server release. The left column of the table shows the different ASG releases for which an ASG standalone installation kit is available. The remaining columns show different Oracle Application Server releases for which an Oracle Application Server instance can be created.
This list describes the meaning of the entries in Table 1-3 and Table 1-4:
N: This ASG release is not compatible with an instance from this Oracle Application Server release.
X: This ASG release cannot be installed into the Oracle home for an instance from this Oracle Application Server release.
Y-NR: This ASG release is compatible with an instance from this Oracle Application Server release, but Oracle recommends that you do not install this ASG release into the instance's Oracle home because another ASG release is recommended.
Y: This ASG release is compatible with an instance from this Oracle Application Server release. Oracle recommends you install this ASG release into the instance's Oracle home.
Table 1-3 shows the compatible ASG releases for Oracle Application Server instances from Oracle Application Server 10.1.2.0.2 through 10.1.3.3.
Table 1-3 Compatible ASG Releases for OracleAS Instances from Releases 10.1.2.0.2 Through 10.1.3.3
| ASG Release | 10.1.2.0.2 OracleAS Instance | 10.1.2.1 OracleAS Instance | 10.1.2.2 OracleAS Instance | 10.1.2.3 OracleAS Instance | 10.1.3.0 OracleAS Instance | 10.1.3.1 OracleAS Instance | 10.1.3.2 OracleAS Instance | 10.1.3.3 OracleAS Instance |
|---|---|---|---|---|---|---|---|---|
|
10.1.2.0.2 |
Y-NR |
X |
X |
Y |
N |
N |
N |
N |
|
10.1.2.2 |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
|
10.1.2.2.1 (ASG-only release)Foot 1 |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
|
10.1.2.3 |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
|
10.1.3.0 |
N |
N |
N |
N |
Y-NR |
X |
N |
X |
|
10.1.3.1 |
N |
N |
N |
N |
Y-NR |
Y-NR |
Y-NR |
X |
|
10.1.3.3 |
N |
N |
N |
N |
Y |
Y |
Y |
Y |
Footnote 1 This is the ASG release that was provided (installed by default) with the OracleAS 10.1.4.2 release. It is compatible with the OracleAS 10.1.2.x releases. There is no OracleAS 10.1.2.2.1 release.
For example, if you have an Oracle Application Server 10.1.3.1 instance and you want to know which ASG release to install in the Oracle home for the instance, you can use Table 1-3 to determine the following:
No ASG 10.1.2.x release is compatible with an Oracle Application Server 10.1.3.1 instance.
The ASG 10.1.3.0 release cannot be installed into the Oracle home for an Oracle Application Server 10.1.3.1 instance.
The ASG 10.1.3.1 release is compatible with an Oracle Application Server 10.1.3.1 instance, but Oracle recommends that you do not install the ASG 10.1.3.1 release into the Oracle home for an Oracle Application Server 10.1.3.1 instance.
The ASG 10.1.3.3 release is compatible with an Oracle Application Server 10.1.3.1 instance and Oracle recommends that you install the ASG 10.1.3.3 release into the Oracle home for an Oracle Application Server 10.1.3.1 instance.
Table 1-4 shows the compatible ASG releases for Oracle Application Server instances from Oracle Application Server 10.1.4.0 through 10.1.4.2.
Table 1-4 Compatible ASG Releases for OracleAS Instances from Releases 10.1.4.0 Through 10.1.4.2
| ASG Release | 10.1.4.0 OracleAS InstanceFoot 1 | 10.1.4.1 OracleAS InstanceFoot 2 | 10.1.4.2 OracleAS InstanceFoot 3 |
|---|---|---|---|
|
10.1.2.0.2 |
Y-NR |
Y-NR |
X |
|
10.1.2.2 |
Y-NR |
Y-NR |
Y-NR |
|
10.1.2.2.1 (ASG-only release)Foot 4 |
Y |
Y |
Y |
|
10.1.2.3 |
Y-NR |
Y-NR |
Y-NR |
|
10.1.3.0 |
N |
N |
N |
|
10.1.3.1 |
N |
N |
N |
|
10.1.3.3 |
N |
N |
N |
Footnote 1 ASG 10.1.2.0.2 is installed by default.
Footnote 2 ASG 10.1.2.0.2 is installed by default.
Footnote 3 ASG 10.1.2.2.1 is installed by default.
Footnote 4 This is the ASG release that was provided (installed by default) with the OracleAS 10.1.4.2 release. It is compatible with the OracleAS 10.1.2.x releases. There is no OracleAS 10.1.2.2.1 release.
In addition to making sure that each of the ASG releases installed in the Oracle Application Server instance homes in your topology are compatible with those Oracle Application Server releases, you must make sure that all the ASG releases in the topology are compatible with each other.
Use Table 1-5 to determine whether two ASG releases are compatible in an OracleAS Disaster Recovery topology. Find the first ASG release in the left column of the table and then find the second ASG release in one of the other columns of the table.
This list describes the meaning of the entries in Table 1-5:
Y-NR: The first ASG release is compatible with the second ASG release, but Oracle recommends that you do not use this ASG release combination in your topology.
Y: The first ASG release is compatible with the second ASG release. Oracle recommends that you use this ASG release combination in your topology.
Table 1-5 shows which ASG releases are compatible with other ASG releases.
Table 1-5 Compatible ASG Releases in a Topology
| ASG Release | 10.1.2.0.2 | 10.1.2.2 | 10.1.2.2.1 | 10.1.2.3 | 10.1.3.0 | 10.1.3.1 | 10.1.3.3 |
|---|---|---|---|---|---|---|---|
|
10.1.2.0.2 |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
|
10.1.2.2 |
Y-NR |
Y |
Y |
Y-NR |
Y-NR |
Y-NR |
Y |
|
10.1.2.2.1 |
Y-NR |
Y |
Y |
Y |
Y-NR |
Y-NR |
Y |
|
10.1.2.3 |
Y-NR |
Y-NR |
Y |
Y |
Y-NR |
Y-NR |
Y |
|
10.1.3.0 |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
|
10.1.3.1 |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
Y-NR |
|
10.1.3.3 |
Y-NR |
Y |
Y |
Y |
Y-NR |
Y-NR |
Y |
You must also make sure that each Oracle Application Server home on a standby site peer host is upgraded to the same ASG release as the equivalent Application Server home at the production site host.
OracleAS Disaster Recovery supports a number of basic topologies for the configuration of the Infrastructure and middle tier on production and standby sites. OracleAS Disaster Recovery supports these basic topologies:
For information on using RAC databases in your Disaster Recovery topology, refer to the following sections:
For OracleAS Disaster Recovery Release 10.1.2.0.1, only the OracleAS Disaster Recovery symmetrical topology environment was supported. This OracleAS Disaster Recovery environment has two major requirements:
The deployment must use a single default Infrastructure install that contains a collocated OracleAS Metadata Repository and Oracle Identity Management.
The standby site has to be a strict mirror of the production site with the same number of instances (symmetrical topology).
Figure 1-1 depicts an example OracleAS Disaster Recovery solution having a symmetrical topology with a Cold Failover Cluster on the primary site. This is considered a symmetrical topology because from an Oracle Application Server perspective both sites contain two Oracle Application Server middle tiers and one Infrastructure.
Figure 1-1 Example Oracle Application Server Site-to-Site Disaster Recovery Solution (Load Balancer Appliance is Optional If Only One Middle-Tier Node is Present)
The procedures and steps for configuring and operating the OracleAS Disaster Recovery solution support 1 to n number of middle-tier hosts in the production site. The same number of middle-tier installations must exist in the standby site. The middle tiers must mirror each other in the production and standby sites.
For the OracleAS Infrastructure, a uniform number of hosts is not required (names or instances must be equal) between the production and standby sites. For example, the OracleAS Cold Failover Cluster (Infrastructure) solution can be deployed in the production site, and a single node installation of the OracleAS Infrastructure can be deployed in the standby site as shown in Figure 1-1. This way, the production site's OracleAS Infrastructure has protection from host failure using an OracleAS Cold Failover Cluster. This solution provides hardware redundancy by utilizing a virtual hostname. Refer to Section 6.2.2, "Active-Passive High Availability Topologies" on page 6-5 of the Oracle Application Server High Availability Guide in the OracleAS Release 10.1.2.0.2 documentation set for more information on OracleAS Cold Failover Clusters.
The OracleAS Disaster Recovery solution is an extension to various single-site Oracle Application Server architectures. Examples of such single-site architectures include the combination of OracleAS Cold Failover Cluster (Infrastructure) and active-active Oracle Application Server middle-tier architecture. For the latest information on what single-site architectures are supported, check the Oracle Technology Network (OTN) Web site for the latest certification matrix.
http://www.oracle.com/technology/products/ias/hi_av/index.html
The following are important characteristics of the symmetric OracleAS Disaster Recovery solution:
Middle-tier hosts are identical between the production and standby sites. In other words, each middle-tier host in the production site has an identical host in the standby site. More than one middle-tier host is recommended because this enables each set of middle-tier installations on each site to be redundant. Because they are on multiple systems, problems and outages within a site of middle-tier installations are transparent to clients.
The OracleAS Disaster Recovery solution is restricted to identical site configuration to ensure that processes and procedures are kept the same between sites, making operational tasks easier to maintain and execute. Identical site configuration also allows for a higher success rate for manually maintaining the synchronization of Oracle Application Server component configuration files between sites.
When the production site becomes unavailable due to a disaster, the standby site can become operational within a reasonable time. Client requests are always routed to the site that is operating in the production role. After a failover or switchover operation occurs due to an outage, client requests are routed to another site that assumes the production role. For a symmetric topology, the quality of service offered by the new production site should be the same as that offered by the original production site before the outage.
From the standpoint of a single site, the sites are set up in active-passive configuration. An active-passive setup has one site used for production and one standby site that is initially passive (on standby). The standby site is made active only after a failover or switchover operation is performed. Since the sites are symmetrical, after failover or switchover, the original standby site can be kept active as the new production site. After repairing or upgrading the original production site, it can be made into the new standby site as long as the OracleAS Disaster Recovery site requirements are maintained. Either site should offer the same level of service to clients as the other. Note that in an active-passive setup, the standby site can be comprised of different Oracle homes that can be active on the same hosts as long as the Oracle homes being used in the Disaster Recovery environment are passive (inactive).
For a database recovery (DBR) site as explained shortly (an Oracle Application Server 10g release (10.1.3) site is most likely not involved, whereas an Oracle Application Server 10g release (10.1.2.0.2) site is involved), the site playing the standby role contains a physical standby of the Oracle Application Server Infrastructure coordinated by Oracle Data Guard. Oracle Application Server Guard automates the configuration and use of Oracle Data Guard together with procedures for backing up and restoring OracleAS Infrastructure configuration files and provides configuration synchronization between the production and standby sites. Switchover and failover operations allow the roles to be traded between the OracleAS Infrastructures in the two sites. Refer to Section 2.7, "Oracle Application Server Guard Operations -- Standby Site Cloning of One or More Production Instances to a Standby System", Section 2.8, "Oracle Application Server Guard Operations -- Standby Instantiation and Standby Synchronization", Section 2.9, "Runtime Operations -- Oracle Application Server Guard Switchover and Failover Operations", and Section 2.11, "Using Oracle Application Server Guard Command-Line Utility (asgctl)" for information about using the asgctl command-line interface to perform Oracle Application Server Guard administrative tasks of cloning, instantiation, synchronization, switchover, and failover in the OracleAS Disaster Recovery solution.
Beginning with OracleAS Disaster Recovery Release 10.1.2.0.2, support for asymmetric topologies includes support for the following simple asymmetric standby topologies:
A standby site having reduced resources (fewer middle tiers); this means support for all production services except the scaling and high availability characteristics. This approach guarantees all services are maintained, but not scaled (see Figure 1-2 for an example of this OracleAS Disaster Recovery solution).
Figure 1-2 Simple Asymmetric Standby with Reduced Resources
Figure 1-2 shows a production site of four middle tier instances and one Infrastructure (collocated Oracle Identity Management and OracleAS Metadata Repository). In this example, the services and applications deployed to middle tier 1 are scaled to include middle tier 2. In addition, the services and applications deployed to middle tier 3 are scaled to include middle tier 4. To satisfy the requirements for reduced resources for disaster recovery, the scaling is not necessary at the standby site. Therefore, the services deployed at production middle tiers 1 and 2 are satisfied by a disaster recovery peer middle tier 1 at the standby site, which will be synchronized with the production middle tier 1. Likewise, the services deployed at production middle tiers 3 and 4 are satisfied by a disaster recovery peer middle tier 3 at the standby site, which will be synchronized with the production middle tier 3.
A standby site that maintains OracleAS Disaster Recovery support for the Infrastructure services only, while the middle-tier instances are supported only through production site management. This approach guarantees that only the Infrastructure services are maintained (see Figure 1-3 for an example of this OracleAS Disaster Recovery solution).
Figure 1-3 Simple Asymmetric Standby with Guaranteed Infrastructure
Figure 1-3 shows a production site consisting of four middle tier instances, with two middle tier instances (1 and 2) collocated with the production Infrastructure services and two middle tier instances (3 and 4) remotely located at the standby site. In this configuration, since the middle tier instances 3 and 4 on the standby site are configured in an active/active model and are actively serving requests, they are technically members of the production topology. Only the Infrastructure services on the standby site provide passive Disaster Recovery capability.
The initial deployment of instances 3 and 4 is handled through routine production site creation. Under normal conditions, application requests are serviced by middle tier instances 1 through 4, and instances 3 and 4 have to tolerate the latency, firewall and network issues associated with this topology. After a failover, only instances 3 and 4 are available and must be able to tolerate the latency, firewall, and network issues. After a switchover, the services and applications deployed to middle tier instances 1 and 2 must be able to tolerate the latency, firewall, and network issues associated with this topology. For the Disaster Recovery instantiate and sync operations, only the Infrastructure services must be maintained using policy files.
Upon failover, instances 1 and 2 and the production Infrastructure are not available. Connection information for instances 3 and 4 would have to be updated so that requests previously routed to the production Infrastructure would be routed to the standby Infrastructure. You would use a failover policy file that ignores instances 1 and 2 to fail over the Infrastructure and start the middle tier services for instances 3 and 4 (the assumption is that instances 3 and 4 would be available at the standby site).
With this configuration, when you perform an instantiate or sync operation, use a sync policy file or instantiate policy file that ignores instances 1 through 4, since the only passive Disaster Recovery instance is the Infrastructure.
With this type of asymmetric topology, the standby site has a reduced number of Oracle homes that guarantee a certain minimum level of service capability at a reduced performance level.
This topology (Figure 1-4), consists of an OracleAS Infrastructure with two OracleAS Metadata Repositories and multiple middle tiers. One OracleAS Metadata Repository is used by Oracle Identity Management components, such as Oracle Internet Directory and OracleAS Single Sign-On. All middle tiers use this OracleAS Metadata Repository for Oracle Identity Management services, as well as any additional middle tiers that might be added to this topology as it expands. The other OracleAS Metadata Repository is used for product metadata by the OracleAS Portal and OracleAS Wireless middle tier components. With two metadata repositories, this deployment can best be described as two DCM production farms.
An OracleAS Disaster Recovery standby configuration could be set up as either a symmetrical topology as described in Section 1.1.3.1, "Symmetrical Topologies - Strict Mirror of the Production Site with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure," thereby requiring two DCM standby farms be configured or as a simple asymmetric topology as described in Section 1.1.3.2, "Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure," with service guaranteed requiring minimally that a single DCM standby farm be configured.
Figure 1-4 Collocated Oracle Identity Management and OracleAS Metadata Repository with a Separate OracleAS Metadata Repository
The topologies in Section 1.1.3.1, "Symmetrical Topologies - Strict Mirror of the Production Site with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure," Section 1.1.3.2, "Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure," and Section 1.1.3.3, "Separate OracleAS Metadata Repository for OracleAS Portal with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure (the Departmental Topology)" describe a deployment for a default database repository collocated for both the Oracle Identity Management and OracleAS Metadata Repository Infrastructure, while Section 1.1.3.3, "Separate OracleAS Metadata Repository for OracleAS Portal with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure (the Departmental Topology)" also describes a topology with a separate OracleAS Metadata Repository.
In a topology with distributed application OracleAS Metadata Repositories and non collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure, the Oracle Identity Management Infrastructure and one OracleAS Metadata Repository Infrastructure are installed on separate hosts, and other OracleAS Metadata Repositories are installed to reside with respective applications on different hosts. Thus, one OracleAS Metadata Repository can be the result of a deployment using a single default Infrastructure install, while one or more OracleAS Metadata Repositories can be the result of an Oracle Application Server user using a tool, such as the OracleAS Metadata Repository Creation Assistant, to install one or more application OracleAS Metadata Repositories on one or more systems with the application data, for management or policy reasons, or both.
Figure 1-5 shows an example OracleAS Disaster Recovery solution having non collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure and distributed OracleAS Metadata Repositories.
Figure 1-5 Non-Collocated Oracle Identity Management (IM) and OracleAS Metadata Repository (MR) Infrastructure Topology with Distributed OracleAS Metadata Repositories
Figure 1-6 shows an example OracleAS Disaster Recovery solution having a configuration supporting high availability of J2EE servers in an Oracle Application Server 10.1.3 topology consisting of four nodes, known as a cluster (also called an OPMN instance). The install type of Web Server (Oracle HTTP Server or OHS) and Process Management (OPMN) is installed on nodes 1 and 2 and the install type of J2EE Server (OC4J) and Process Management (OPMN) is installed on nodes 3 and 4. There is no Identity Management.
Figure 1-6 Redundant Multiple Oracle Application Server 10.1.3 Homes J2EE Topology
Beginning with Oracle Application Server 10.1.3, a new dynamic node discovery mechanism is operational within Oracle Notification Server (ONS), a component of OPMN. Dynamic node discovery enables the cluster to manage itself. When a new ONS node is added to the cluster, each existing ONS node announces its presence with a multicast message and each existing node then adds the new node and its connection information to its map of the current cluster, while at the same time the new ONS node adds all the existing nodes to its map. This fulfills one of the requirements for OracleAS Disaster Recovery that the Oracle Application Server cluster be currently configured. In this case, the OPMN configuration file, opmn.xml, is updated whenever a new Oracle Application Server server node is added to or removed from the cluster. This clustering configuration applies to all instances of OracleAS Server components, including OHS and OC4J, installed on the node.
By default, Oracle Application Server Guard is installed in each Oracle home on each node in the Oracle Application Server cluster. When an Oracle Application Server Guard client connects to an Oracle Application Server Guard server, and the Disaster Recovery Administrator performs a discover topology within farm command, Oracle Application Server Guard utilizes OPMN to discover all the instances on nodes within the cluster, creates the Disaster Recovery topology.xml file on the Oracle Application Server Guard server, and then propagates this file to all systems across the Disaster Recovery production topology. Any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology.
Thereafter, the Disaster Recovery Administrator can use the discover topology within farm command following the addition or removal of one or more nodes to the Oracle Application Server cluster knowing that the ONS dynamic node discovery mechanism will automatically manage the cluster configuration information and keep it current. See Oracle Containers for J2EE Configuration and Administration Guide for more information about the ONS dynamic discovery mechanism. You can also manage instances in the local topology file using the add instance and remove instance commands, and if specified propagate this updated local topology file to all instances in the Disaster Recovery production environment. Any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby environment. See Section 2.5, "Discovering Oracle Application Server 10.1.3 Instances in Redundant Multiple Oracle Application Server 10.1.3 Homes J2EE Topology" for a use case example. Thus, the key point is that you must perform a discover topology within farm command if any nodes have been added to the cluster and if any instances have been added to these nodes that are part of your Disaster Recovery environment.
Figure 1-7 shows an example OracleAS Disaster Recovery solution supporting a mixed version topology, where Oracle Application Server 10.1.3 instances are integrated into an existing Oracle Internet Directory (OID) based topology (OracleAS Cluster (IM) 10.1.4.2). In this case, multiple Oracle Application Server 10g (10.1.3) installations of the Integrated Web server, J2EE Server, and OPMN installation option in a single Oracle home on individual systems create the redundant single Oracle Application Server 10.1.3 Oracle home J2EE topology.
Figure 1-7 Redundant Single Oracle Homes J2EE Topology Plus OracleAS Cluster (IM) 10.1.4.2 (OracleAS Mixed Version Topology)
By default, Oracle Application Server Guard is installed in each Oracle home. When an Oracle Application Server Guard client connects to an Oracle Application Server Guard server in the IM 10.1.4.2 OracleAS topology, and performs a discover topology command, Oracle Application Server Guard utilizes OID and automatically recognizes all Oracle Application Server 10.1.4.2 instances within the existing OID based topology. The discover topology operation creates the Disaster Recovery topology file and propagates it to all instances across the production topology. Any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology.
A Disaster Recovery Administrator can use the asgctl add instance or remove instance command to add or remove from the local topology file single Oracle Application Server 10.1.3 J2EE instances to or from an existing OID based 10.1.4.2 production topology. With either operation, the local topology file is updated and if specified, the local updated topology file is propagated to all instances across the production topology. Any Oracle Application Server Guard operation that affects the standby site, such as verify, instantiate, sync, and switchover will automatically propagate the production topology file across the standby topology. The resulting topology is then described as a redundant single Oracle Application Server 10.1.3 Oracle home J2EE topology integrated with an existing OID based topology (OracleAS Cluster (IM) 10.1.4.2). See Section 2.6, "Adding or Removing Oracle Application Server 10.1.3 Instances to Redundant Single Oracle Application Server 10.1.3 Home J2EE Topology Integrated with an Existing Oracle Identity Management 10.1.4.2 Topology" for a use case example. See Section 5.2, "Information Specific to a Small Set of Oracle Application Server Guard Commands" for more information about topology files.
Prior to the installation of OracleAS software for the OracleAS Disaster Recovery solution, a number of system level configurations are required or optional as specified. The tasks that accomplish these configurations are:
This section covers the steps needed to perform these tasks for the symmetrical topology. These same steps are also applicable to topologies for non collocated Oracle Identity Management and OracleAS Metadata Repository with or without distributed OracleAS Metadata Repositories.
Before performing the steps to set up the physical and network hostnames, plan the physical and network hostnames you want to use with respect to the entire OracleAS Disaster Recovery solution. The overall approach to planning and assigning hostnames must meet the following goals:
OracleAS components in the middle tier and OracleAS Infrastructure must use the same physical hostnames in their configuration settings regardless of whether the components are in the production or standby site. In addition, you must also create a virtual hostname for the physical hostname of the OracleAS Infrastructure.
For example, if the physical hostname asmid1 is used for a middle-tier host in the production site, the same physical hostname, asmid1, should be used for the peer middle-tier host in the standby site. Likewise, if the virtual hostname infra is used for the OracleAS Infrastructure host on the production site, then the same virtual hostname infra should be used for the OracleAS Infrastructure host on the standby site.
No changes to hostnames (physical, network, or virtual) are required when the standby site takes over the production role. However, a DNS switchover must be performed to redirect client requests transparently to the new site that has assumed the production site. See Section 1.5, "Wide Area DNS Operations" for more information about performing a DNS switchover.
Figure 1-8 illustrates the process of planning and assigning hostnames.
Figure 1-8 Name Assignment Example in the Production and Standby Sites
In Figure 1-8, two middle-tier nodes exist in the production site. The OracleAS Infrastructure can be a single node or an OracleAS Cold Failover Cluster solution (represented by a single virtual hostname and a virtual IP, as for a single node OracleAS Infrastructure). The common names in the two sites are the physical hostnames of the middle-tier nodes and the virtual hostname of the OracleAS Infrastructure. Table 1-6 shows the physical, network, and virtual hostnames in the example:
Table 1-6 Physical, Network, and Virtual Hostnames in Figure 1-8
| Physical Hostnames | Virtual Hostname | Network HostnamesFoot 1 |
|---|---|---|
asmid1 |
- |
prodmid1, standbymid1 |
asmid2 |
- |
prodmid2, standbymid2 |
- Foot 2 |
infra |
prodinfra, standbyinfra |
Footnote 1 The network hostname is the hostname defined in domain name system (DNS). A network hostname is the name by which a host is known to the network.
Footnote 2 In this example, the physical hostname for the OracleAS Infrastructure host is the network hostname.
The following sections and the Glossary explain that physical, network, and virtual hostnames have different purposes in the OracleAS Disaster Recovery solution. These hostnames are also set up differently. See the following sections for more information on physical, network, and virtual hostnames:
When you are installing an Oracle Application Server middle-tier instance (non-Infrastructure instance) on a host, there are different ways of specifying a physical hostname for that host, depending on the release of Oracle Application Server that you are installing. The Oracle Universal Installer will use the hostname string that is discovered during the installation in the OracleAS Disaster Recovery configuration.
The subsections in this section describe the different ways of specifying a physical hostname for a host prior to installing an Oracle Application Server middle-tier instance for a particular Oracle Application Server release on the host.
Oracle recommends that you use the same physical hostname for a production site middle-tier host and its peer middle-tier host at the standby site. However, if the middle-tier hosts at the production site already have installed software, changing the physical hostnames of those hosts may break the software. To avoid breaking already installed software, you can optionally continue to use the network hostnames for the production site middle-tier hosts and not define physical hostnames for them. In this case, though, you must change the physical hostnames for the standby site middle-tier hosts to match the network hostnames for their production site peer hosts.
The installation procedures for Oracle Application Server middle-tier instances (non-Infrastructure instances) for releases 10.1.2.0.2 and 10.1.2.1 do not allow you to specify a physical hostname as part of the installation. Therefore, you must follow the steps below to specify a physical hostname for middle-tier hosts prior to these installations:
Follow these steps to change the physical hostname of a Solaris host:
On a Solaris middle-tier host, check the setting for the existing hostname as follows:
prompt> hostname
Use a text editor, such as vi, to edit the name in /etc/nodename to your planned physical hostname.
For each middle-tier host, restart it for the change to take effect.
Repeat Step 1 to verify the correct physical hostname has been set. For example:
prompt> hostname asmid1
Repeat the previous steps to create a new physical hostname for each Solaris middle-tier host at the production and standby sites.
Follow these steps to change the physical hostname of a Linux host:
On a Linux middle-tier host, check the setting for the existing hostname by issuing the hostname command as follows:
prompt> hostname
Use the hostname command and specify the new physical hostname you want to create for the host (you must be root to issue the hostname command). The following example shows how to create a physical hostname of asmid1 for the host:
prompt> hostname asmid1
Repeat Step 1 to verify the correct hostname has been set:
prompt> hostname asmid1
Add the new physical hostname as an entry in the /etc/hosts file for the host. An /etc/hosts file is used for local hostnaming file resolution. The supported methods for configuring OracleAS Disaster Recovery hostname resolution are described in Section 1.2.2, "Configuring Hostname Resolution." In this example, adding the following /etc/hosts file entry for the host with an IP address of 123.1.2.333 creates a physical hostname of asmid1 for that host:
123.1.2.333 asmid1.oracle.com asmid1
Repeat the previous steps to create a new physical hostname for each Linux middle-tier host at the production and standby sites.
Note:
For other UNIX variants, consult your system administrator for equivalent commands.Follow these steps to change the physical hostname of a Windows host:
Note:
The user interface elements in your version of Windows may vary from those described in the following steps.In the Start menu, select Control Panel.
Double-click the System icon.
Select the Advanced tab.
Select Environment Variables.
Under the User variables for the installer account, select New to create a new variable.
Enter the name of the variable as "_CLUSTER_NETWORK_NAME_".
For the value of this variable, enter the planned physical hostname, for example, admid1.
Add the new physical hostname as an entry in the C:\WINDOWS\system32\drivers\etc\hosts file for the host. For example, adding the following entry in the \etc\hosts file for the host with an IP address of 123.1.2.333 creates a physical hostname of asmid1 for that host:
123.1.2.333 asmid1.oracle.com asmid1
Repeat the previous steps to create a new physical hostname for each Windows middle-tier host at the production and standby sites.
To create a new physical hostname for a host prior to installing Oracle Application Server middle-tier instances (non-Infrastructure instances) for releases 10.1.2.2 and 10.1.2.3 on the host, you can specify the physical hostname as an entry in the /etc/hosts file for the host on which you are installing the middle-tier instance. For example, the following entry in the /etc/hosts file for the host with an IP address of 123.1.2.333 creates a physical hostname of asmid1 for that host:
123.1.2.333 asmid1.oracle.com asmid1
If you do not create a new physical hostname by specifying it as an entry in the /etc/hosts file for the host, then the Oracle Universal Installer will use the name returned by the hostname command on the host as the physical hostname for the host.
Use one of these options to create a new physical hostname for a host prior to installing Oracle Application Server middle-tier instances (non-Infrastructure instances) for releases 10.1.3.0 through 10.1.3.3 on the host:
On UNIX platforms, you can set the VIRTUAL_HOST_NAME environment variable prior to the installation to create a new physical hostname for the middle-tier system on which you are installing Oracle Application Server (even though you use the VIRTUAL_HOST_NAME environment variable, this variable creates a physical hostname on a middle-tier host). For example, to specify a physical hostname of asmid1 or a middle-tier host Linux host, log into the host and issue the following command prior to installing Oracle Application Server:
setenv VIRTUAL_HOST_NAME asmid1
You can create a new physical hostname for the host prior to the installation by specifying it as an entry in the /etc/hosts file for the host on which you are installing the middle-tier instance. For example, adding the following entry in the /etc/hosts file for the host with an IP address of 123.1.2.333 creates a physical hostname of asmid1 for that host:
123.1.2.333 asmid1.oracle.com asmid1
If you do not create a new physical hostname by using either the VIRTUAL_HOST_NAME variable or by specifying the new physical hostname as an entry in the /etc/hosts file for the middle-tier host, then the Oracle Universal Installer will use the name returned by the hostname command on the host as the physical hostname for the host.
The network hostnames used in the OracleAS Disaster Recovery solution are defined in domain name system (DNS). These hostnames are visible in the network that the solution uses and are resolved through DNS to the appropriate hosts by the assigned IP address in the DNS system. You must add these network hostnames and their corresponding IP addresses to the DNS system.
Using the example in Figure 1-8, the following additions should be made to the DNS system serving the entire network that encompasses the production and standby sites:
prodmid1.oracle.com IN A 123.1.2.333 prodmid2.oracle.com IN A 123.1.2.334 prodinfra.oracle.com IN A 123.1.2.111 standbymid1.oracle.com IN A 213.2.2.443 standbymid2.oracle.com IN A 213.2.2.444 standbyinfra.oracle.com IN A 213.2.2.210
As defined in this section and the Glossary, virtual hostname applies to the OracleAS Infrastructure only. It is specified during installation of the OracleAS Infrastructure. When you run the OracleAS Infrastructure installation type, a screen called Specify Virtual Hostname appears to provide a text box to enter the virtual hostname of the OracleAS Infrastructure that is being installed. Refer to the Oracle Application Server Installation Guide for more details.
For the example in Figure 1-8, when you install the production site's OracleAS Infrastructure, enter its virtual hostname, infra, on the Specify Virtual Hostname screen. Enter the same virtual hostname when you install the standby site's OracleAS Infrastructure.
Note:
If the OracleAS Infrastructure is installed in an OracleAS Cold Failover Cluster solution, the virtual hostname is the name that is associated with the virtual IP of the OracleAS Cold Failover Cluster.For high availability deployment with multiple Oracle Application Server instances using a load balancer on the production site, but no load balancer on the standby site, the virtual hostname is the DNS based virtual hostname for the load balancer, for example lbr01.us.oracle.com. For more information, see the white paper on using load balancers and OracleAS High Availability on the Oracle Technology Network (OTN).
When setting up a Disaster Recovery solution in environments involving both Oracle RAC databases and non-RAC databases, it is recommended to define a virtual hostname that can be used as an alias at both the production site and standby site. The alias must be defined in the /etc/hosts file on Windows and UNIX platforms on each node running a database instance.
In a Disaster Recovery environment, the site that actively accepts connections is the production site. At the completion of a successful failover or switchover operation, the standby site becomes the new production site.
This section includes an example of defining an alias for database hosts stajo01 and stajo02. Table 1-7 shows the database hostnames and the connect strings for the databases before the alias is defined:
Table 1-7 Database Hostnames and Connect Strings
| Site | Database Hostname | Database Connect String |
|---|---|---|
|
Primary |
stajo01.us.oracle.com |
stajo01.us.oracle.com:1521:orcl |
|
Standby |
stajo02.us.oracle.com |
stajo02.us.oracle.com:1521:orcl |
In this example, all database connect strings on the production site take the form "stajo01.us.oracle.com:1521:orcl." After a failover or switchover operation, this connect string must be changed to "stajo02.us.oracle.com:1521:orcl." However, by creating an alias of "proddb1" for the database hostname as shown in Table 1-8, you can avoid manually changing the connect strings, which enables seamless failovers and switchovers:
Table 1-8 Specifying an Alias for a Database Host
| Site | Database Hostname | Alias | Database Connect String |
|---|---|---|---|
|
Production |
stajo01.us.oracle.com |
proddb1.us.oracle.com |
proddb1.us.oracle.com:1521:orcl |
|
Standby |
stajo02.us.oracle.com |
proddb1.us.oracle.com |
proddb1.us.oracle.com:1521:orcl |
In this example, the production site database hostname and the standby site database hostname are aliased to "proddb1.us.oracle.com" and the connect strings on the production site and the standby site can take the form "proddb1.us.oracle.com:1521:orcl". On failover and switchover operations, the connect string does not need to change, thus enabling a seamless failover and switchover.
The format for specifying virtual hostnames as aliases in /etc/hosts file entries is:
<IP> <ALIAS WITH DOMAIN> <ALIAS> <HOSTNAME WITH DOMAIN> <HOSTNAME>
In this example, you create an alias with the virtual hostname of proddb1 for host stajo01 at the production site and for host stajo02 at the standby site. The hosts file entry should specify the fully qualified virtual hostname with the <ALIAS WITH DOMAIN> parameter, the short virtual hostname with the <ALIAS> parameter, the fully qualified physical hostname with the <HOSTNAME WITH DOMAIN> parameter, and the short physical hostname with the <HOSTNAME> parameter.
So, in the /etc/hosts files at the production site, make sure the entry for host stajo01 looks like this:
152.68.196.213 proddb1.us.oracle.com proddb1 stajo01.us.oracle.com stajo01
And, in the /etc/hosts files at the standby site, make sure the entry for host stajo02 looks like this:
140.87.25.40 proddb1.us.oracle.com proddb1 stajo02.us.oracle.com stajo02
In the OracleAS Disaster Recovery solution, you must configure hostname resolution in one of two ways to resolve the hostnames you planned and assigned in Section 1.2.1, "Planning and Assigning Hostnames." The two methods of configuring hostname resolution are:
In UNIX, the order of the method of hostname resolution is specified using the "hosts" parameter in the file /etc/nsswitch.conf. The following is an example of the hosts entry:
hosts: files dns nis
In the previous statement, local hostname file resolution is preferred over DNS and NIS (Network Information Service) resolutions. When a hostname is required to be resolved to an IP address, the /etc/hosts file (UNIX) or C:\WINDOWS\system32\drivers\etc\hosts file is consulted first. In this example, if a hostname cannot be resolved using local hostnaming resolution, then DNS is used. (NIS resolution is not used for the OracleAS Disaster Recovery solution.) Refer to your UNIX system documentation to find out more about name resolution using the file /etc/nsswitch.conf.
After you choose and configure either local hostname file resolution or DNS resolution for Disaster Recovery on UNIX, make sure that the resolution method you configured is the first entry for the hosts parameter in the /etc/nsswitch.conf file on each host in your Disaster Recovery production site and standby site. For example, if you chose local hostname file resolution, the hosts parameter must look like this in the /etc/nsswitch.conf file on each host:
hosts: files dns nis
If you chose DNS resolution, the hosts parameter must look like this in the /etc/nsswitch.conf file on each host:
hosts: dns files nis
In Windows, the method of ordering hostname resolution varies depending on the Windows version. Refer to the documentation for your version of Windows for the appropriate steps.
This method of hostname resolution relies on a local hostnaming file to contain the requisite hostname-to-IP address mappings. In UNIX, this file is /etc/hosts. In Windows, this file is C:\WINDOWS\system32\drivers\etc\hosts.
To use the local hostnaming file to resolve hostnames for the OracleAS Disaster Recovery solution in UNIX for each middle tier and OracleAS Infrastructure host in both the production and standby sites, perform the following steps on each host at the production and standby sites:
Use a text editor, such as vi, to edit the /etc/nsswitch.conf file. With the "hosts:" parameter, specify "files" as the first choice for hostname resolution.
Edit the /etc/hosts file to include the following:
The physical hostnames and the correct IP addresses for all middle-tier nodes in the current site. The first entry must be the hostname and IP address of the current node.
Note:
When making entries in the hosts file, make sure the intended hostname is positioned in the second column of the hosts file; otherwise, an asgctlverify topology with <host> operation will fail indicating that the production topology is not symmetrical with the standby topology. See Section A.1.7, "Failure of Farm Verification Operation with Standby Farm" for more information about troubleshooting and resolving this type of problem.For example, if you are editing the /etc/hosts file of a middle-tier node in the production site, enter all the middle-tier physical hostnames and their IP addresses in the production site beginning the list with the current host. (You should also include fully qualified hostnames in addition to the abbreviated hostnames. See Table 1-9.)
The virtual hostname of the OracleAS Infrastructure in the current site.
For example, if you are editing the /etc/hosts of a middle-tier node in the standby site, enter the virtual hostname, fully qualified and abbreviated, and the IP address of the OracleAS Infrastructure host in the standby site.
Restart each host after editing the files mentioned in the previous steps.
From each host, use the ping command for each physical hostname that is valid in its particular site to ensure that the IP addresses have been assigned correctly.
For the example in Figure 1-8, on the asmid1 host, use the following commands in succession:
ping asmid1
The returned IP address should be 123.1.2.333.
ping asmid2
The returned IP address should be 123.1.2.334.
ping infra
The returned IP address should be 123.1.2.111.
Note:
Some UNIX variants, such as Solaris, require the-s option to return an IP address.Using the example in Figure 1-8, Table 1-9 shows that the /etc/hosts file entries on each production node contains the required entries for each UNIX host. The entries in the Windows C:\WINDOWS\system32\drivers\etc\hosts file should be similar.
Table 1-9 Network and Virtual Hostname Entries in Each /etc/hosts File of Example in Figure 1-8
| Host | Entries in /etc/hosts |
|---|---|
|
|
123.1.2.333 asmid1.oracle.com asmid1 123.1.2.334 asmid2.oracle.com asmid2 123.1.2.111 infra.oracle.com infra 213.2.2.210 remoteinfra.oracle.com remoteinfra |
|
|
123.1.2.334 asmid2.oracle.com asmid2 123.1.2.333 asmid1.oracle.com asmid1 123.1.2.111 infra.oracle.com infra 213.2.2.210 remoteinfra.oracle.com remoteinfra |
|
|
123.1.2.111 infra.oracle.com infra 123.1.2.333 asmid1.oracle.com asmid1 123.1.2.334 asmid2.oracle.com asmid2 213.2.2.210 remoteinfra.oracle.com remoteinfra |
|
|
213.2.2.443 asmid1.oracle.com asmid1 213.2.2.444 asmid2.oracle.com asmid2 213.2.2.210 infra.oracle.com infra 123.1.2.111 remoteinfra.oracle.com remoteinfra |
|
|
213.2.2.444 asmid2.oracle.com asmid2 213.2.2.443 asmid1.oracle.com asmid1 213.2.2.210 infra.oracle.com infra 123.1.2.111 remoteinfra.oracle.com remoteinfra |
|
|
213.2.2.210 infra.oracle.com infra 213.2.2.443 asmid1.oracle.com asmid1 213.2.2.444 asmid2.oracle.com asmid2 123.1.2.111 remoteinfra.oracle.com remoteinfra |
To set up the OracleAS Disaster Recovery solution to use DNS hostname resolution, you must set up site-specific DNS servers in the production and standby sites in addition to the overall corporate DNS servers (usually more than one DNS server exists in a corporate network for redundancy). Figure 1-9 provides an overview of this setup.
See Also:
Chapter 6, "Setting Up a DNS Server" for instructions on how to set up a DNS server in a UNIX environment.Figure 1-9 DNS Resolution Topology Overview
For the topology in Figure 1-9 to work, the following requirements and assumptions must be made:
The DNS servers for the production and standby sites must not be aware of each other. They make non authoritative lookup requests to the overall corporate DNS servers if they fail to resolve any hostnames within their specific sites.
The production site and standby site DNS servers must contain entries for middle-tier physical hostnames and OracleAS Infrastructure virtual hostnames. Each DNS server contains entries of only the hostnames within its own site. The sites have a common domain name that is different from that of the overall corporate domain name.
The overall corporate DNS servers contain network hostname entries for the middle-tier hosts and OracleAS Infrastructure hosts of both production and standby sites.
In UNIX, the /etc/hosts file in each host does not contain entries for the physical, network, or virtual hostnames of any host in either the production or standby site. In Windows, this applies to the file C:\WINDOWS\system32\drivers\etc\hosts.
To set up the OracleAS Disaster Recovery solution for DNS resolution, follow these steps:
Configure each of the overall corporate DNS servers with the network hostnames of all the hosts in the production and standby sites. Using the example presented in Figure 1-8, the following entries are made:
prodmid1.oracle.com IN A 123.1.2.333 prodmid2.oracle.com IN A 123.1.2.334 prodinfra.oracle.com IN A 123.1.2.111 standbymid1.oracle.com IN A 213.2.2.443 standbymid2.oracle.com IN A 213.2.2.444 standbyinfra.oracle.com IN A 213.2.2.210
For each site, production and standby, create a unique DNS zone by configuring a DNS server as follows:
Select a unique domain name to use for the two sites that is different from the corporate domain name. As an example, use the name "oracleas" for the domain name for the two sites in Figure 1-8. The high level corporate domain name is oracle.com.
Configure the DNS server in each site to point to the overall corporate DNS servers for unresolved requests.
Populate the DNS servers in each site with the physical hostnames of each middle-tier host and the virtual hostname of each OracleAS Infrastructure host. Include the domain name selected in the previous step.
For the example in Figure 1-8, the entries are as follows:
For the DNS server on the production site:
asmid1.oracleas IN A 123.1.2.333 asmid2.oracleas IN A 123.1.2.334 infra.oracleas IN A 123.1.2.111
For the DNS server on the standby site:
asmid1.oracleas IN A 213.2.2.443 asmid2.oracleas IN A 213.2.2.444 infra.oracleas IN A 213.2.2.210
Note:
If you are using a load balancer, you must alias the IP addresses inside the host file with DNS based virtual hostnames. This is essential for Oracle Application Server Guard on the local host to perform a local write of the topology file from a discover topology within farm command and to correctly perform an add instance command and update the topology file.If you are using the OracleAS Cold Failover Cluster solution for the OracleAS Infrastructure in either site, enter the cluster's virtual hostname and virtual IP address. For example, in the previous step, infra is the virtual hostname and 123.1.2.111 is the virtual IP of the cluster in the production site. For more information on the OracleAS Cold Failover Cluster solution, see Section 6.2.2, "Active-Passive High Availability Topologies" on page 6-5 of the Oracle Application Server High Availability Guide in the Oracle Application Server Release 10.1.2.0.2 documentation set.
Because Oracle Application Server Guard automates the use of Oracle Data Guard technology, which is used to synchronize the production and standby OracleAS Infrastructure databases, the production OracleAS Infrastructure must be able to reference the standby OracleAS Infrastructure and conversely.
For this to work, the IP address of the standby OracleAS Infrastructure host must be entered in the production site's DNS server with a hostname that is unique to the production site. Similarly, the IP address of the production OracleAS Infrastructure host must be entered in the standby site's DNS server with the same hostname. These DNS entries are required because Oracle Data Guard uses TNS Names to direct requests to the production and standby OracleAS Infrastructures. Hence, the appropriate entries must also be made to the tnsnames.ora file. Additionally, Oracle Application Server Guard asgctl command-line commands must reference the network hostnames.
Using the example in Figure 1-8 and assuming that the selected name for the remote OracleAS Infrastructure is "remoteinfra," the entries for the DNS server in the production site are:
asmid1.oracleas IN A 123.1.2.333 asmid2.oracleas IN A 123.1.2.334 infra.oracleas IN A 123.1.2.111 remoteinfra.oracleas IN A 213.2.2.210
And, in the standby site, the DNS server entries should be as follows:
asmid1.oracleas IN A 213.2.2.443 asmid2.oracleas IN A 213.2.2.444 infra.oracleas IN A 213.2.2.210 remoteinfra.oracleas IN A 123.1.2.111
Section 1.1.3.2, "Asymmetrical Topologies - Simple Asymmetric Standby Topology with Collocated Oracle Identity Management and OracleAS Metadata Repository Infrastructure" describes some of the asymmetrical topologies supported by OracleAS Disaster Recovery.
This section describes the system level configuration you should perform prior to installing the OracleAS software for an asymmetrical OracleAS Disaster Recovery solution where the standby site has fewer hosts than the production site. Much of the information in Section 1.3, "Preparing the OracleAS Disaster Recovery Environment for an Asymmetrical Standby Site," which is written for symmetrical topologies, is also true for asymmetrical topologies. Therefore, this section describes only the differences you need to be aware of when setting up an asymmetrical standby site topology.
Figure 1-10 shows the asymmetrical topology being described in this section and illustrates the name assignments for the production site and standby site:
Figure 1-10 Name Assignment Example for an Asymmetrical Standby Site Topology
In Figure 1-10, two middle-tier nodes and an OracleAS Infrastructure exist at the production site. OracleAS Portal & Wireless is installed in an Oracle home on Node 1 and OracleAS J2EE & Web Cache is installed in an Oracle home on Node 2. The OracleAS Infrastructure can be a single node or an OracleAS Cold Failover Cluster solution (represented by a single virtual hostname and a virtual IP, as for a single node OracleAS Infrastructure). At the standby site, only one middle-tier node (with collocated Application Server instances) and an OracleAS Infrastructure node exists. OracleAS Portal & Wireless is installed in an Oracle home on Node 1 and OracleAS J2EE & Web Cache is installed in another Oracle home on Node 1. The OracleAS Infrastructure is a single node at the standby site.
Table 1-10 shows the physical, network and virtual hostnames to use for the asymmetrical standby site shown in Figure 1-10:
Table 1-10 Physical, Network, and Virtual Hostnames in Figure 1-10
| Physical Hostnames | Virtual Hostname | Network Hostnames |
|---|---|---|
|
asmid1 |
- |
prodmid1, standbymid1 |
|
asmid2 |
- |
prodmid2 |
|
- Foot 1 |
infra |
prodinfra, standbyinfra |
Footnote 1 In this example, the physical hostname is the network hostname.
See the following sections for general information on setting up hostnames and configuring hostname resolution:
Section 1.2.1.1, "Physical Hostnames" describes setting up physical hostnames.
Section 1.2.1.2, "Network Hostnames" describes setting up network hostnames.
Section 1.2.1.3, "Virtual Hostname" describes setting up virtual hostnames.
Section 1.2.1.4, "Virtual Hostname Aliases" describes setting up virtual hostname aliases for Oracle database hosts.
Section 1.2.2, "Configuring Hostname Resolution" describes how to use local hostnaming file resolution (/etc/hosts files) or DNS resolution for hostname resolution.
Before you perform any installations, follow these steps to prepare for setting up the OracleAS Disaster Recovery asymmetrical standby site topology in Figure 1-10:
Note:
When you do perform the installations required to set up the OracleAS Disaster Recovery topology in Figure 1-10, you must use only Oracle Universal Installer to install all the Oracle software on the hosts at the production site and standby site. Do not use the asgctlclone instance or clone topology commands when setting up this asymmetrical standby site topology. The asgctl clone instance and clone topology commands are not supported for this asymmetrical standby site topology.
None of the required installations are done as part of the steps below. See Section 1.4, "Overview of Installing Oracle Application Server" for a description of the order in which the required installations for the asymmetrical topology should be performed.
Requirements for the OracleAS Infrastructure host at the production site:
Make sure the network hostname prodinfra is set up for the host prior to installing the OracleAS Infrastructure on the host. You do this by confirming that the corporate DNS server includes the entries shown in Figure 1-11 and Section 1.3.1.2, "Using DNS Resolution for the Asymmetrical Topology."
When you install the OracleAS Infrastructure on the host later, create the virtual hostname infra for the host by following the instructions in Section 1.2.1.3, "Virtual Hostname."
Requirements for the OracleAS Infrastructure host at the standby site:
Make sure the network hostname standbyinfra is set up for the host prior to installing the OracleAS Infrastructure on the host. You do this by confirming that the corporate DNS server includes the entries shown in Figure 1-11 and Section 1.3.1.2, "Using DNS Resolution for the Asymmetrical Topology."
When you install the OracleAS Infrastructure on the host later, create the virtual hostname infra for the host by following the instructions in Section 1.2.1.3, "Virtual Hostname."
When you install the OracleAS Infrastructure on the host later, install it into an Oracle home directory with the same path as the Oracle home directory that the OracleAS Infrastructure was installed into on the Infrastructure host at the production site. Use the portlist.ini file from the OracleAS Infrastructure installation at the production site as input to the OracleAS Infrastructure installation at the standby site.
Requirements for Node 1 at the production site:
Make sure the network hostname prodmid1 is set up for the host prior to installing OracleAS Portal & Wireless on the host. You do this by confirming that the corporate DNS server includes the entries shown in Figure 1-11 and Section 1.3.1.2, "Using DNS Resolution for the Asymmetrical Topology."
When you install OracleAS Portal & Wireless on the host later, make sure that the physical hostname asmid1 is set up for the host by following the instructions in Section 1.2.1.1, "Physical Hostnames."
Requirements for Node 2 at the production site:
Make sure the network hostname prodmid2 is set up for the host prior to installing OracleAS Portal & Wireless on the host. You do this by confirming that the corporate DNS server includes the entries shown in Figure 1-11 and Section 1.3.1.2, "Using DNS Resolution for the Asymmetrical Topology."
When you install OracleAS J2EE & Web Cache on the host later, make sure that the physical hostname asmid2 is set up for the host by following the instructions in Section 1.2.1.1, "Physical Hostnames."
Make sure that you do not install the OracleAS J2EE & Web Cache instance on Node 2 at the production site into an Oracle home directory with the same path as the Oracle home directory you installed the OracleAS Portal & Wireless instance into on Node 1 at the production site. For example, do not install the OracleAS Portal & Wireless instance into the /app/instance1 Oracle home directory path on Node 1 at the production site and then install the OracleAS J2EE & Web Cache instance into the /app/instance1 Oracle home directory path on Node 2 at the production site. The relative paths to the Oracle homes for these instances must be different to enable a successful failover or switchover from the production site to the standby site. The reason for this is because it is not supported for both the OracleAS Portal & Wireless instance and the OracleAS J2EE & Web Cache instance to be installed in a single Oracle home directory (the /app/instance1 directory, for example) on Node 1 at the standby site.
Plan the ports for the entire topology so that the port each OracleAS instance at the standby site listens on is the same port as its peer instance listens on at the production site peer host.
Requirements for Node 1 at the standby site:
Make sure the network hostname standbymid1 is set up for the host prior to installing either the OracleAS Portal & Wireless instance or the OracleAS J2EE & Web Cache instance on the host. You do this by confirming that the corporate DNS server includes the entries shown in Figure 1-11 and Section 1.3.1.2, "Using DNS Resolution for the Asymmetrical Topology."
When you install the OracleAS Portal & Wireless instance on the host later, make sure that the physical hostname asmid1 is set up for the host by following the instructions in Section 1.2.1.1, "Physical Hostnames." Make sure that the OracleAS Portal & Wireless instance is installed into the same Oracle home directory as the peer instance was installed into on Node 1 at the production site. Use the portlist.ini file from the OracleAS Portal & Wireless installation at Node 1 at the production site as input to the OracleAS Portal & Wireless installation at Node 1 at the standby site.
When you install the OracleAS J2EE & Web Cache instance on the host later, make sure that the physical hostname asmid2 is set up for the host by following the instructions in Section 1.2.1.1, "Physical Hostnames." Make sure that the OracleAS J2EE & Web Cache instance is installed into the same Oracle home directory as the peer instance was installed into on production site Node 2. Use the portlist.ini file from the OracleAS J2EE & Web Cache installation at Node 2 at the production site as input to the OracleAS J2EE & Web Cache installation at Node 1 at the standby site.
General standby site requirements:
If you are using local hostnaming file resolution, confirm that both asmid1 and asmid2 are in the /etc/hosts files for the standby site hosts and that the entries show the 213.2.2.443 IP address.
If you are using DNS hostname resolution, confirm that the entries shown in Figure 1-11 and Section 1.3.1.2, "Using DNS Resolution for the Asymmetrical Topology" have been made.
After performing the preparatory steps in this section, you are ready to begin the installations required for the asymmetrical topology in Figure 1-10. Perform the required installations for the topology in the order described in Section 1.4, "Overview of Installing Oracle Application Server."
After completing the installations required for the topology, use the asgctl discover topology command and the asgctl instantiate topology command to perform the remaining setup for the site.
General information on configuring hostname resolution is provided in Section 1.2.2, "Configuring Hostname Resolution." This section describes how to configure hostname resolution for the OracleAS Disaster Recovery asymmetrical standby site topology shown in Figure 1-10.
Section 1.3.1.1, "Using Local Hostnaming File Resolution for the Asymmetrical Topology" describes how to configure hostname resolution for this asymmetrical standby site topology using local hostnaming file resolution.
Section 1.3.1.2, "Using DNS Resolution for the Asymmetrical Topology" describes how to configure hostname resolution for this asymmetrical standby site topology using DNS resolution.
This method of hostname resolution relies on a local hostnaming file to contain the requisite hostname-to-IP address mappings. In UNIX, this file is /etc/hosts. In Windows, this file is C:\WINDOWS\system32\drivers\etc\hosts.
To use the local hostnaming file to resolve hostnames for the OracleAS Disaster Recovery solution in UNIX for each middle tier and OracleAS Infrastructure host in both the production and standby sites, perform the following steps:
Use a text editor, such as vi, to edit the /etc/nsswitch.conf file. With the "hosts:" parameter, specify "files" as the first choice for hostname resolution.
Edit the /etc/hosts file to include the following:
The physical hostnames and the correct IP addresses for all middle-tier nodes in the current site. The first entry must be the hostname and IP address of the current node.
Note:
When making entries in the hosts file, make sure the intended hostname is positioned in the second column of the hosts file; otherwise, an asgctlverify topology with <host> operation will fail indicating that the production topology is not symmetrical with the standby topology. See Section A.1.7, "Failure of Farm Verification Operation with Standby Farm" for more information about troubleshooting and resolving this type of problem.For example, if you are editing the /etc/hosts file of a middle-tier node in the production site, enter all the middle-tier physical hostnames and their IP addresses in the production site beginning the list with the current host. (You should also include fully qualified hostnames in addition to the abbreviated hostnames. See Table 1-11.)
The virtual hostname of the OracleAS Infrastructure in the current site.
For example, if you are editing the /etc/hosts of a middle-tier node in the standby site, enter the virtual hostname, fully qualified and abbreviated, and the IP address of the OracleAS Infrastructure host in the standby site.
Restart each host after editing the files mentioned in the previous steps.
From each host, use the ping command for each physical hostname that is valid in its particular site to ensure that the IP addresses have been assigned correctly.
For the example in Figure 1-10, on the asmid1 host at the production site, use the following commands in succession:
ping asmid1
The returned IP address should be 123.1.2.333.
ping asmid2
The returned IP address should be 123.1.2.334.
ping infra
The returned IP address should be 123.1.2.111.
Note:
Some UNIX variants, such as Solaris, require the-s option to return an IP address.Using the example in Figure 1-10, Table 1-11 shows that the /etc/hosts file entries on each production node contains the required entries for each UNIX host. The entries in the Windows C:\WINDOWS\system32\drivers\etc\hosts file should be similar.
Table 1-11 Network and Virtual Hostname Entries in /etc/hosts File of Example in Figure 1-10
| Host | Entries in /etc/hosts |
|---|---|
|
asmid1 in production site |
123.1.2.333 asmid1.oracle.com asmid1 123.1.2.334 asmid2.oracle.com asmid2 123.1.2.111 infra.oracle.com infra 213.2.2.210 remoteinfra.oracle.com remoteinfra |
|
asmid2 in production site |
123.1.2.334 asmid2.oracle.com asmid2 123.1.2.333 asmid1.oracle.com asmid1 123.1.2.111 infra.oracle.com infra 213.2.2.210 remoteinfra.oracle.com remoteinfra |
|
infra in production site |
123.1.2.111 infra.oracle.com infra 123.1.2.333 asmid1.oracle.com asmid1 123.1.2.334 asmid2.oracle.com asmid2 213.2.2.210 remoteinfra.oracle.com remoteinfra |
|
asmid1 in standby site |
213.2.2.443 asmid1.oracle.com asmid1 213.2.2.443 asmid2.oracle.com asmid2 213.2.2.210 infra.oracle.com infra 123.1.2.111 remoteinfra.oracle.com remoteinfra |
|
infra in standby site |
213.2.2.210 infra.oracle.com infra 213.2.2.443 asmid1.oracle.com asmid1 213.2.2.443 asmid2.oracle.com asmid2 123.1.2.111 remoteinfra.oracle.com remoteinfra |
To set up the OracleAS Disaster Recovery solution to use DNS hostname resolution, you must set up site-specific DNS servers in the production and standby sites in addition to the overall corporate DNS servers (usually more than one DNS server exists in a corporate network for redundancy). Figure 1-11 provides an overview of this setup.
See Also:
Chapter 6, "Setting Up a DNS Server" for instructions on how to set up a DNS server in a UNIX environment.Figure 1-11 DNS Resolution for Asymmetrical Topology
For the topology in Figure 1-11 to work, the following requirements and assumptions must be made:
The DNS servers for the production and standby sites must not be aware of each other. They make non authoritative lookup requests to the overall corporate DNS servers if they fail to resolve any hostnames within their specific sites.
The production site and standby site DNS servers must contain entries for middle-tier physical hostnames and OracleAS Infrastructure virtual hostnames. Each DNS server contains entries of only the hostnames within its own site. The sites have a common domain name that is different from that of the overall corporate domain name.
The overall corporate DNS servers contain network hostname entries for the middle-tier hosts and OracleAS Infrastructure hosts of both production and standby sites.
In UNIX, the /etc/hosts file in each host does not contain entries for the physical, network, or virtual hostnames of any host in either the production or standby site. In Windows, this applies to the file C:\WINDOWS\system32\drivers\etc\hosts.
To set up the OracleAS Disaster Recovery solution for DNS resolution, follow these steps:
Configure each of the overall corporate DNS servers with the network hostnames of all the hosts in the production and standby sites. Using the example presented in Figure 1-10, the following entries are made:
prodmid1.oracle.com IN A 123.1.2.333 prodmid2.oracle.com IN A 123.1.2.334 prodinfra.oracle.com IN A 123.1.2.111 standbymid1.oracle.com IN A 213.2.2.443 standbyinfra.oracle.com IN A 213.2.2.210
For each site, production and standby, create a unique DNS zone by configuring a DNS server as follows:
Select a unique domain name to use for the two sites that is different from the corporate domain name. As an example, use the name "oracleas" for the domain name for the two sites in Figure 1-10. The high level corporate domain name is oracle.com.
Configure the DNS server in each site to point to the overall corporate DNS servers for unresolved requests.
Populate the DNS servers in each site with the physical hostnames of each middle-tier host and the virtual hostname of each OracleAS Infrastructure host. Include the domain name selected in the previous step.
For the example in Figure 1-10, the entries are as follows:
For the DNS server on the production site:
asmid1.oracleas IN A 123.1.2.333 asmid2.oracleas IN A 123.1.2.334 infra.oracleas IN A 123.1.2.111
For the DNS server on the standby site:
asmid1.oracleas IN A 213.2.2.443 asmid2.oracleas IN A 213.2.2.443 infra.oracleas IN A 213.2.2.210
Note:
If you are using a load balancer, you must alias the IP addresses inside the host file with DNS based virtual hostnames. This is essential for Oracle Application Server Guard on the local host to perform a local write of the topology file from a discover topology within farm command and to correctly perform an add instance command and update the topology file.If you are using the OracleAS Cold Failover Cluster solution for the OracleAS Infrastructure in either site, enter the cluster's virtual hostname and virtual IP address. For example, in the previous step, infra is the virtual hostname and 123.1.2.111 is the virtual IP of the cluster in the production site. For more information on the OracleAS Cold Failover Cluster solution, see Section 6.2.2, "Active-Passive High Availability Topologies" on page 6-5 of the Oracle Application Server High Availability Guide in the Oracle Application Server Release 10.1.2.0.2 documentation set.
Also, for this asymmetrical topology, follow the instructions in Section 1.2.2.2.1, "Additional DNS Server Entries for Oracle Data Guard."
This section provides an overview of the steps for installing the OracleAS Disaster Recovery solution. These steps are applicable to the topologies described in Section 1.1.3, "Supported Topologies". After following the instructions in Section 1.2, "Preparing the OracleAS Disaster Recovery Environment" to set up the environment for the solution, read this section for an overview of the installation process. Then, follow the detailed instructions in the Oracle Application Server Installation Guide to install the solution.
Note:
To assign identical ports for use by symmetrical hosts in the production and standby sites, you can use static port definitions. These definitions are defined in a file, (for example, namedstaticports.ini). Then, specify the staticports.ini file in the Specify Ports Configuration Options screen in the installer. (Detailed information on the static ports file is found in the Oracle Application Server Installation Guide.)The following steps represent the overall sequence for installing the OracleAS Disaster Recovery solution:
Install OracleAS Infrastructure in the production site (see Oracle Application Server Installation Guide).
Install OracleAS Infrastructure in the standby site (see Oracle Application Server Installation Guide).
Start the OracleAS Infrastructure in each site before installing the middle tiers for that site.
Install the middle tiers in the production site (see Oracle Application Server Installation Guide).
Install the middle tiers in the standby site (see Oracle Application Server Installation Guide).
The following points are important when you perform the installation:
Ensure that the same ports are used by equivalent peer hosts in both sites. For example, the asmid1 host in the standby site must use the same ports as the asmid1 host in the production site. Use a static ports definition file. (see the previous note in this section and the following point).
Specify the full path to the staticports.ini file in the installer's Specify Ports Configuration Options screen.
During the Infrastructure installation, ensure that you select the High Availability and Replication option in the installer's Select Configuration Options screen.
Specify the virtual address assigned to the OracleAS Infrastructure in the Specify Virtual Hostname screen during OracleAS Infrastructure installation.
Install for the middle-tier hosts, any of the available middle-tier installation types. (Ensure that the OracleAS Infrastructure services have been started for a site before installing any middle tiers in that site.)
Specify the OracleAS Infrastructure's virtual hostname as the OracleAS Infrastructure database during each middle-tier installation.
Start the OracleAS services on the hosts in each site starting with the OracleAS Infrastructure.
To direct client requests to the entry point of a production site, use DNS resolution. When a site switchover or failover is performed, client requests must be redirected transparently to the new site that is playing the production role. To accomplish this redirection, the wide area DNS that resolves requests to the production site has to be switched over to the standby site. The DNS switchover can be accomplished by either using a wide area load balancer or manually changing DNS names.
Note:
A hardware load balancer is assumed to be front-ending each site. Check for supported load balancers at:The following subsections describe the DNS switchover operation.
When a wide area load balancer (global traffic manager) is deployed in front of the production and standby sites, it provides fault detection services and performance-based routing redirection for the two sites. Additionally, the load balancer can provide authoritative DNS name server equivalent capabilities.
During normal operations, the wide area load balancer can be configured with the production site's load balancer name-to-IP mapping. When a DNS switchover is required, this mapping in the wide area load balancer is changed to map to the standby site's load balancer IP. This allows requests to be directed to the standby site, which now has the production role.
This method of DNS switchover works for both site switchover and failover. One advantage of using a wide area load balancer is that the time for a new name-to-IP mapping to take effect can be almost immediate. The downside is that an additional investment must be made for the wide area load balancer.
This method of DNS switchover involves the manual change of the name-to-IP mapping that is originally mapped to the IP address of the production site's load balancer. The mapping is changed to map to the IP address of the standby site's load balancer. Follow these instructions to perform the switchover:
Make a note the current time-to-live (TTL) value of the production site's load balancer mapping. This mapping is in the DNS cache and it will remain there until the TTL expires. As an example, let's assume that the TTL is 3600 seconds.
Modify the TTL value to a short interval (for example, 60 seconds).
Wait one interval of the original TTL. This is the original TTL of 3600 seconds from Step 1.
Ensure that the standby site is switched over to receive requests.
Modify the DNS mapping to resolve to the standby site's load balancer giving it the appropriate TTL value for normal operation (for example, 3600 seconds).
This method of DNS switchover works for planned site switchover operations only. The TTL value set in Step 2 should be a reasonable time period where client requests cannot be fulfilled. The modification of the TTL is effectively modifying the caching semantics of the address resolution from a long period of time to a short period. Due to the shortened caching period, an increase in DNS requests can be observed.
If you are using a Server Load Balancer to direct HTTP requests to multiple Oracle HTTP Server instances, Web access to some applications (such as the Application Server Control console and Oracle Web Services Manager) may be redirected to the physical HTTP Server hosts.
To ensure that redirected requests are always sent to the load balancer, configure an Oracle HTTP Server virtual host for the load balancer.
For example, if Oracle HTTP Server is listening on port 7777 and a load balancer called bigip.acme.com is listening on port 80, then consider the following entry in the httpd.conf file:
NameVirtualHost *:7777 <VirtualHost *:7777> ServerName bigip.us.oracle.com Port 80 ServerAdmin youyour.address RewriteEngine On RewriteOptions inherit </VirtualHost>
