| Oracle® Application Server Disaster Recovery Guide 10g Release 3 (10.1.3.3.0) Part Number E12297-02 |
|
|
View PDF |
| Oracle® Application Server Disaster Recovery Guide 10g Release 3 (10.1.3.3.0) Part Number E12297-02 |
|
|
View PDF |
This chapter describes how to implement Oracle Application Server Disaster Recovery solution for an enterprise deployment.
It contains the following topics:
Figure 2-1 shows the mySOACompany with Oracle Single Sign-On deployment from the Oracle Application Server Enterprise Deployment Guide. The Oracle Application Server Enterprise Deployment Guide describes how to install the Oracle Application Server instances on the five Oracle Application Server host clusters (OIDHOST1 and OIDHOST2, WEBHOST1 and WEBHOST2, APPHOST1 and APPHOST2, WEBHOST3 and WEBHOST4, and IDMHOST1 and IDMHOST2) and how to perform the necessary configuration for the deployment.
This manual describes how to set up this deployment at an Oracle Application Server Disaster Recovery production site and standby site for the Linux and UNIX operating systems.
Note:
This manual describes an Oracle Application Server Disaster Recovery symmetric topology that uses the deployment shown in Figure 2-1 at both the production site and the standby site. Figure 2-1 shows the deployment for only one site; the high level of detail shown for this deployment precludes showing the deployment for both sites in a single figure.This manual refers to the deployment in Figure 2-1 as the EDG deployment. However, unlike the Oracle Application Server Enterprise Deployment Guide, this manual directs you to install the Oracle Application Server instances that will be used by the Oracle Application Server host clusters into Oracle home directories in volumes on shared storage at the production site. Shared storage will also be set up for the standby site. Then, Oracle Application Server data on the production site storage will be replicated asynchronously to the standby site storage as part of the Oracle Application Server Disaster Recovery solution.
Figure 2-1 Deployment Used at Production and Standby Sites for Oracle Application Server Disaster Recovery Symmetric Topology
The EDG deployment is described in detail in the Oracle Application Server Enterprise Deployment Guide.
This manual describes how to set up and deploy an Oracle Application Server Disaster Recovery topology on Linux and UNIX systems. The Oracle Application Server Disaster Recovery symmetric topology described in this manual uses the EDG deployment at both the production site and standby site.
The Oracle Application Server Disaster Recovery topology that you design must be symmetric for the following at the production site and standby site.
The same Application Server host name must be used for each production site host and its standby site peer host. The Application Server host name for a host is either specified when Oracle Application Server is installed or derived from the host at installation time. A host's Application Server host name is stored in the Oracle Application Server Disaster Recovery configuration.
It is recommended that a host have a different Application Server host name and network host name. See Section 1.1.2, "Terminology" for the definitions of Application Server host name and network host name.
In some cases, a host will use the same host name as its Application Server host name and network host name. This situation is described in Section 2.1.2, "Designing with an Existing Production Site."
Every file that exists at a production site host must exist in the same directory and path at the standby site peer host.
Thus, Oracle home names and directory paths must be the same at the production site and standby site.
Port numbers are used by listeners and for the routing of requests. Port numbers are stored in the configuration and have to be the same at the production site hosts and their standby site peer hosts.
Section 2.1.2, "Designing with an Existing Production Site" describes how to check for port conflicts between production site and standby site hosts.
The same user accounts must exist at both the production site and standby site. Also, the file system, SSL, and Single Sign-On must be configured identically at the production site and standby site. For example, if the production site uses SSL, the standby site must also use SSL that is configured in exactly the same way as the production site.
Load balancers and virtual server names
A front-end load balancer should be set up with virtual server names for the production site, and an identical front-end load balancer should be set up with the same virtual server names for the standby site.
The same versions of software must be used on the production site and standby site. Also, the operating system patch level must be the same at both sites, and patches to Oracle or third party software must be made to both the production site and standby site.
The following design topics are included in this section:
Planning Host Names for the Production Site and Standby Site
Making /etc/hosts File Entries for Local Host Name File Resolution
Before setting up the standby site, the administrator must evaluate the starting point of the project. The starting point for designing a symmetrical Oracle Application Server Disaster Recovery topology is usually one of the following:
The production site is already created and the standby site is being planned and created.
Section 2.1.2, "Designing with an Existing Production Site" describes how to design the Oracle Application Server Disaster Recovery standby site when you have an existing production site.
There is no existing production site or standby site. Both need to be designed and created.
Section 2.1.3, "Designing a New Production Site and Standby Site" describes how to design the Oracle Application Server Disaster Recovery production site when you do not have an existing production site or standby site.
Some hosts or components may exist at a current production site, but new hosts or components need to be added at that site or at a standby site to set up a functioning Oracle Application Server Disaster Recovery topology.
Use the pertinent information in this chapter to design and implement an Oracle Application Server Disaster Recovery topology.
When the administrator's starting point is an existing production site, the configuration data for the production site already exists. For example, for any Oracle software already installed, the Oracle home names and the paths to the Oracle home directories exist on the file system. Also, the host names, ports, and user accounts are already defined. When a production site exists, the administrator can choose to either re-create the production site from scratch (as described in Section 2.1.3, "Designing a New Production Site and Standby Site") or to create a symmetric standby site for the existing production site, as described in this section.
The following sections describe how to meet the requirements for symmetric ports, Application Server host names, storage configuration, and Oracle Central Inventories for the production site and standby site when the production site already exists.
When Oracle Application Server components have already been installed at an existing production site, a production site host will most likely have the same host name as its Application Server host name and its network host name. For example, if the network host name for an existing production site host is PROD001, then the Application Server host name for the host will most likely also be PROD001, because the Oracle Application Server installation will use the network name of the host as its Application Server host name.
The recommended Oracle Application Server Disaster Recovery configuration is for each production site host and each standby site host to have an Application Server host name that is different than its network host name (host name planning is described in detail in Section 2.1.4, "Planning Host Names for the Production Site and Standby Site"). However, this recommendation is difficult to implement with an existing production site where some or all of hosts were previously set up to use the same host name as the Application Server host name and network host name for the host. If you attempt to change the existing Application Server host name for a host, it can break applications that have been installed at the site and cause other issues that can be difficult to diagnose and fix. Therefore, if the same host name is being used for both the Application Server host name and network host name for a production site host, you should not change the existing Application Server host name.
When the production site already exists and the production site hosts have the same host name as both the Application Server host name and network host name, the standby site hosts must be given the same Application Server host names as their peer hosts on the production site. An example of using the Application Server host name for a production site host as the Application Server host name for the peer host at the standby site is shown in Table 2-1. Specifically, production site host PROD001 has an Application Server host name of PROD001, so its peer host STBYWEB1 on the standby site must also use PROD001 as its Application Server host name. Similarly, production site host PROD002 has an Application Server host name of PROD002, so its peer host STBYWEB2 on the standby site must also use PROD002 as its Application Server host name PROD002.
Table 2-1 Using Production Site Application Server Host Names as the Application Server Host Names for Standby Site Hosts
| IP AddressFoot 1 | Site | Application Server Host Name | Network Host NameFoot 2 |
|---|---|---|---|
|
123.1.2.113 |
Production |
PROD001Foot 3 |
PROD001 |
|
123.1.2.114 |
Production |
PROD002Foot 4 |
PROD002 |
|
123.2.2.113 |
Standby |
PROD001 |
STBYWEB1 |
|
123.2.2.114 |
Standby |
PROD002 |
STBYWEB2 |
Footnote 1 In this book's examples, IP addresses for hosts at the initial production site have the format 123.1.x.x and IP addresses for hosts at the initial standby site have the format 123.2.x.x.
Footnote 2 See Section 2.1.7, "Resolving Host Names Using DNS Host Name Resolution" for information on defining network host names.
Footnote 3 This Application Server host name is added for illustration purposes; technically, the absence of a resolution mechanism from the Application Server host name to the network host name is a valid configuration for these hosts. (technically, an Application Server host name does not need to be assigned to a production site host, in which case the network host name is used as the Application Server host name.
Footnote 4 This Application Server host name is added for illustration purposes; technically, the absence of a resolution mechanism from the Application Server host name to the network host name is a valid configuration for these hosts. (technically, an Application Server host name does not need to be assigned to a production site host, in which case the network host name is used as the Application Server host name.
If your Oracle Application Server Disaster Recovery solution includes a pre-existing production site, then after a failover operation or switchover, the original standby site assumes the production role. In this situation, the Application Server host names for the new production site (original standby site) are the same as the Application Server and network host names of the original production site. This can cause administrative confusion, because the Application Server host names that appear in the display and in logs at the new production site are the same as the host names used at the original production site.
Standby site hosts must use the same port numbers as their peer hosts at the production site. To prevent port conflicts between production site and standby site peer hosts, it is recommended that the administrator get a list of the port numbers for each production site host and confirm that the same ports are used for the same components at the standby site peer host.
Begin by getting a copy of portlist.ini file for each of the existing Oracle homes used at the production site. The contents of this file contains the port numbers that were assigned during the installation process.
Then, at the standby site peer host, you can use the netstat utility to ensure that the ports in use at the standby site are the same as those in use the production site (note that the netstat utility will only show ports in use by running software; it does not show ports used by transient run-time components if those components are not active).
For instance, the first part of Example 2-1 shows some of the ports in the portlist.ini file for an Oracle Application Server installation at a production site host. Note that port 7777 was assigned to Oracle HTTP Server at the production site host.
In the second part of Example 2-1, after the standby site is created, the netstat utility is used on the standby site peer host to check whether port 7777 is assigned to Oracle HTTP Server on the standby site peer host.
Example 2-1 Checking Ports Usage for an Existing Host
[Ports] Oracle HTTP Server port = 7777 Oracle HTTP Server Listen port = 7777 Oracle HTTP Server SSL port = 4443 Oracle HTTP Server Listen (SSL) port = 4443 Oracle HTTP Server Diagnostic port = 7200 . . . prompt> netstat -an | grep 7777
Port usage for each standby site host must be identical to the port usage for the production site peer host.
The Oracle Application Server Disaster Recovery solution relies on shared storage to implement disk replication for disaster protection of the Oracle Application Server middle tier configuration. When a production site has already been created, it is likely that the Oracle home directories for the Oracle Application Server instances that comprise the site are not located on the shared storage. If this is the case, then these homes have to be migrated completely to the shared storage to implement the Oracle Application Server Disaster Recovery solution.
Information about setting up the shared storage for the Oracle Application Server Disaster Recovery solution is provided in Section 2.2.2, "Creating Volumes, Mount Points, and Symbolic Links."
The Oracle Central Inventory stores information about all Oracle software products installed in all the Oracle homes on a host (provided the product was installed using Oracle Universal Installer). Some Oracle components, including the Oracle Opatch utility, must have a complete inventory of the software components installed on the host.
The location of the Oracle Central Inventory for a host is recorded in the inventory pointer file, oraInst.loc.
By default, Oracle Universal Installer places and looks for the oraInst.loc file in the /etc directory for installations on Linux platforms and in the /var/opt/oracle directory for installations on Solaris platforms. You can use the runInstaller script with the -invPtrLoc option to specify another inventory pointer file.
There are two requirements regarding the location of the Oracle Central Inventory within the Oracle Application Server Disaster Recovery environment:
The location must be defined and accessible.
The location must be on shared storage that is synchronized along with the software installed on the host.
If you move the Oracle home for an Oracle Application Server instance from a production site host's local storage to the shared storage set up for the site, then you must reassociate that Oracle home with the Oracle Central Inventory on the site's shared storage. To reassociate the Oracle home with the Oracle Central Inventory, use the runInstaller script (located under the $ORACLE_HOME/oui/bin directory) with the -attachHome option, as shown in Example 2-2:
Example 2-2 Attaching an Oracle Home to the Oracle Central Inventory
./runInstaller -attachHome ORACLE_HOME="/u01/app/oracle/oid_oh" ORACLE_HOME_NAME="OIDHome"
See Oracle Universal Installer and OPatch User's Guide for more information about Oracle Universal Installer, OPatch, and the Oracle Central Inventory.
This section presents the logic to implementing a new production site for an Oracle Application Server Disaster Recovery topology. It describes the planning and setup of the production site by pre-planning host names, configuring the hosts to resolve the Application Server host names and network host names, and ensuring that disk replication is set up to copy the configuration based on these names to the standby site. When you design the production site, you should also plan the standby site, which must be symmetric with the production site.
When you are designing a new production site (not using a pre-existing production site), you will use Oracle Universal Installer to install software on the production site, and parameters such as Application Server host names and software paths must be carefully designed to ensure that they are the same for both sites.
The flexibility you have when you create a new Oracle Application Server Disaster Recovery production site and standby site includes:
You can design your Oracle Application Server Disaster Recovery solution so that each host at the production site and at the standby site has a different Application Server host name and network host name.
When you design and create your production site from scratch, you can choose the Oracle home name and Oracle home directory for each Application Server installation, following the instructions recommendations in this chapter. You can also choose the location of the Oracle Central Inventory for each host, and the location of the static HTML pages directories for hosts.
Designing and creating your site from scratch is easier than trying to modify an existing site to meet the design requirements described in this chapter.
You can assign ports for the Application Server installations for the production site hosts that will not conflict with the ports that will be used at the standby site hosts.
This is easier than having to check for and resolve port conflicts between an existing production site and standby site.
This section describes how to plan Application Server host names and network host names for the middle tier hosts that use the Oracle Application Server instances at the production site and standby site.
Table 2-2 shows the IP addresses, Application Server host names, and network host names that will be used for the EDG deployment production site hosts that use the Oracle Application Server instances in the production site. Figure 2-1 shows the configuration for the EDG deployment at the production site.
Table 2-2 IP Addresses, Application Server Host Names, and Network Host Names for Production Site Hosts and Shared Storage
| IP Address | Application Server Host Name | Network Host NameFoot 1 |
|---|---|---|
|
123.1.2.111 |
OIDHOST1 |
PRODOID1 |
|
123.1.2.112 |
OIDHOST2 |
PRODOID1 |
|
123.1.2.113 |
WEBHOST1 |
PRODWEB1 |
|
123.1.2.114 |
WEBHOST2 |
PRODWEB2 |
|
123.1.2.115 |
APPHOST1 |
PRODAPP1 |
|
123.1.2.116 |
APPHOST2 |
PRODAPP2 |
|
123.1.2.117 |
WEBHOST3 |
PRODWEB3 |
|
123.1.2.118 |
WEBHOST4 |
PRODWEB4 |
|
123.1.2.119 |
IDMHOST1 |
PRODIDM1 |
|
123.1.2.120 |
IDMHOST2 |
PRODIDM2 |
|
123.1.2.121 |
N/A |
PRODSTOR |
Footnote 1 See Section 2.1.7, "Resolving Host Names Using DNS Host Name Resolution" for information on defining network host names.
Table 2-3 shows the IP addresses, Application Server host names, and network host names that will be used for the EDG deployment standby site hosts that use the Oracle Application Server instances in the standby site.
Table 2-3 IP Addresses, Application Server Host Names, and Network Host Names for Standby Site Hosts and Shared Storage
| IP Address | Application Server Host Name | Network Host NameFoot 1 |
|---|---|---|
|
123.2.2.111 |
OIDHOST1 |
STBYOID1 |
|
123.2.2.112 |
OIDHOST2 |
STBYOID2 |
|
123.2.2.113 |
WEBHOST1 |
STBYWEB1 |
|
123.2.2.114 |
WEBHOST2 |
STBYWEB2 |
|
123.2.2.115 |
APPHOST1 |
STBYAPP1 |
|
123.2.2.116 |
APPHOST2 |
STBYAPP2 |
|
123.2.2.117 |
WEBHOST3 |
STBYWEB3 |
|
123.2.2.118 |
WEBHOST4 |
STBYWEB4 |
|
123.2.2.119 |
IDMHOST1 |
STBYIDM1 |
|
123.2.2.120 |
IDMHOST2 |
STBYIDM2 |
|
123.2.2.121 |
N/A |
STBYSTOR |
Footnote 1 See Section 2.1.7, "Resolving Host Names Using DNS Host Name Resolution" for information on defining network host names.
The Application Server host names are resolved locally at the production site or standby site to the correct IP address. In an Oracle Application Server Disaster Recovery topology, there are two ways to configure host name resolution for the Application Server host names planned for the production site and standby site in Table 2-2 and Table 2-3. The two ways to configure Application Server host name resolution are described in Section 2.1.5, "Host Name Resolution."
Host name resolution is the process of resolving a host name to the proper IP address for communication. Oracle Application Server Disaster Recovery supports two methods of configuring host name resolution.
The two ways to configure the Application Server host name resolution are:
Local host name resolution uses the Application Server host name to IP address mapping that is specified by the /etc/hosts file on each host.
See Section 2.1.6, "Making /etc/hosts File Entries for Local Host Name File Resolution" for more information about using the /etc/hosts file to implement local host name file resolution.
DNS server resolution is a method of centralizing the Application Server host names to IP addresses in a database and configuring each host to use a DNS server to resolve host names.
See Section 2.1.7, "Resolving Host Names Using DNS Host Name Resolution" for more information about implementing DNS server host name resolution.
You must determine the method of host name resolution you will use for your Oracle Application Disaster Recovery topology when you are planning the deployment of the topology. Most site administrators use a combination of these resolution methods in a precedence order to manage host names.
The Oracle Application Server hosts and the shared storage system for each site must be able to communicate with each other.
The Application Server host names are not actually assigned to the production site hosts (included in the Oracle Application Server configuration for the host) until the Oracle Application Server middle tier components are installed at the production site host.
Host Name Resolution Precedence
To determine the host name resolution method used by a particular host, search for the value of the hosts parameter in the /etc/nsswitch.conf file on the host.
As shown in Example 2-3, if local host name file resolution is used for the host, the files entry will be the first entry for the hosts parameter. When files is the first entry for the hosts parameter, entries in the host's /etc/hosts file will be used first to resolve host names:
As shown in Example 2-4, if DNS server host name resolution is used for the host, the dns entry will be the first entry for the hosts parameter. When dns is the first entry for the hosts parameter, DNS server entries will be used first to resolve host names:
All the hosts in an Oracle Application Server Disaster Recovery production site and standby site must have the same values for the hosts parameter in the host's /etc/nsswitch.conf file. Also, the nis entry must be the last entry for the host's parameter for all production site and standby site hosts. Oracle Application Server Disaster Recovery does not support nis host name resolution.
If you decide to use local host name file resolution to resolve Application Server host names, then the /etc/hosts file for each host at the production site should include entries for the Application Server host names of other hosts at the production site. Make sure that the first entry in the /etc/hosts file for each production site host is the entry for the Application Server host name for that host.
Example 2-5 shows the entries in the /etc/hosts file for OIDHOST1 at the standby site. Each entry provides the IP address of a production site host and specifies the Application Server host name that will be used at the production site for that host:
Example 2-5 Making /etc/hosts File Entries for a Production Site Host
127.0.0.1 localhost.localdomain localhost 123.1.2.111 OIDHOST1.ORACLE.COM OIDHOST1 123.1.2.112 OIDHOST2.ORACLE.COM OIDHOST2 123.1.2.113 WEBHOST1.ORACLE.COM WEBHOST1 123.1.2.114 WEBHOST2.ORACLE.COM WEBHOST2 123.1.2.115 APPHOST1.ORACLE.COM APPHOST1 123.1.2.116 APPHOST2.ORACLE.COM APPHOST2 123.1.2.117 WEBHOST3.ORACLE.COM WEBHOST3 123.1.2.118 WEBHOST4.ORACLE.COM WEBHOST4 123.1.2.119 IDMHOST1.ORACLE.COM IDMHOST1 123.1.2.120 IDMHOST2.ORACLE.COM IDMHOST2
Technically, each host in a site only needs entries for the other hosts it directly communicates with at the site. However, for consistency and ease of maintenance, it is recommended that the /etc/hosts file for each host at a site include entries for all the other hosts at the site.
You can copy the /etc/hosts file for one host to each the other hosts at the site. Then, for each host, edit the /etc/hosts file so that the entry for that host is the second entry (just after the 127.0.0.1 entry) in the file.
Similarly, if you use local host name file resolution to resolve Application Server host names, then the entries for each host at the standby site should include entries for the Application Server host names of other hosts at the standby site. Make sure that the second entry in the /etc/hosts file for each standby site host is the entry for the Application Server host name of that host.
Example 2-6 shows the entries in the /etc/hosts file for OIDHOST1 at the standby site. Each entry provides the IP address of a standby site host and specifies the Application Server host name that will be used at the standby site for that host:
Example 2-6 Making /etc/hosts File Entries for a Standby Site Host
127.0.0.1 localhost.localdomain localhost 123.2.2.111 OIDHOST1.ORACLE.COM OIDHOST1 123.2.2.112 OIDHOST2.ORACLE.COM OIDHOST2 123.2.2.113 WEBHOST1.ORACLE.COM WEBHOST1 123.2.2.114 WEBHOST2.ORACLE.COM WEBHOST2 123.2.2.115 APPHOST1.ORACLE.COM APPHOST1 123.2.2.116 APPHOST2.ORACLE.COM APPHOST2 123.2.2.117 WEBHOST3.ORACLE.COM WEBHOST3 123.2.2.118 WEBHOST4.ORACLE.COM WEBHOST4 123.2.2.119 IDMHOST1.ORACLE.COM IDMHOST1 123.2.2.120 IDMHOST2.ORACLE.COM IDMHOST2
In this example, the entries in the /etc/hosts file for OIDHOST1 at the standby site are very similar to the entries in the /etc/hosts file for OIDHOST1 at the production site. The difference is that all the IP addresses for the production site hosts begin with 123.1.n.n and all the IP addresses for the standby site hosts begin with 123.2.n.n.
The /etc/hosts files for the other hosts at the standby site would include these same entries, but the second entry (just after the 127.0.0.1 entry) in each /etc/hosts file at the standby site would be the entry for the Application Server host name for that standby site host.
When you are using local host name file resolution for Application Server host name resolution, the network host names for the production site shown in Table 2-2 and the network host names for the standby site shown in Table 2-3 are not defined in the /etc/hosts file. Instead, the network host names for the production and standby site hosts must be defined in the corporate Domain Name System (DNS) that includes the production and standby site.
When you are using local host name file resolution, make sure that files is specified as the first method of host name resolution for the hosts parameter in the /etc/nsswitch.conf file for each middle tier host, as shown in Example 2-3.
See Section 2.1.7, "Resolving Host Names Using DNS Host Name Resolution" for information about defining network host names.
Basic Rules for /etc/hosts File Entries
Follow these basic rules for creating host name entries in /etc/hosts files:
Each host name entry must include an IP address for a host, the fully qualified name (host name and domain) of the host, and the short name of the host.
Add the entry that specifies the Application Server host name for the local host immediately after the 127.0.0.1 localhost.localdomain entry. During installations, the Oracle Universal Installer looks for the Application Server host name in the entry after the 127.0.0.1 localhost.localdomain entry.
If you want to create multiple Application Server host names for a given IP address, enter the primary Application Server host name that you want returned for that address before the additional entries for that IP address.
If you would like to include multiple Application Server host names in a single entry, add them at the end of the entry.
Example 2-7 shows /etc/hosts file entries that could be made for production site host WEBHOST1. These entries demonstrate the basic rules described earlier:
Example 2-7 Making Valid /etc/hosts File Entries
127.0.0.1 localhost.localdomain localhost 123.1.2.113 WEBHOST1.ORACLE.COM WEBHOST1 MYHOST 123.1.2.114 WEBHOST2.ORACLE.COM WEBHOST2 123.1.2.114 WEBHOSTPEER.ORACLE.COM WEBHOSTPEER
The rules that are demonstrated in Example 2-7 are:
Rule 1 is followed for all the entries in WEBHOST1's /etc/hosts file.
Rule 2 is followed by the second entry. This is the /etc/hosts file for WEBHOST1 and the entry for WEBHOST1 is just after the 127.0.0.1 localhost.localdomain entry.
Rule 3 is illustrated by the third and fourth entries. The third entry (for WEBHOST2) appears before the fourth entry (for WEBHOSTPEER.ORACLE.COM) because WEBHOST2.ORACLE.COM is the primary Application Server host name for IP address 123.1.2.114. Although WEBHOSTPEER will be recognized as an Application Server host name for 123.1.2.114, the first host name returned for IP address 123.1.2.114 on most operating systems will be WEBHOST2.ORACLE.COM.
Rule 4 is illustrated by the second entry for WEBHOST1. In this entry, MYHOST has been specified at the end of the entry, so that MYHOST can be used as an additional Application Server host name in addition to the primary Application Server host name, WEBHOST1.US.ORACLE.COM.
After you set up host name resolution for your production site and standby site hosts using /etc/host file entries, use the ping command to test host name resolution. For a system configured with static IP addressing and the /etc/hosts file entries shown for WEBHOST1 in Example 2-7, a ping webhost1 command would return the correct IP address (123.1.2.113) and also indicate that the host name is fully qualified. Similarly, a ping webhostpeer command will return the correct IP address (123.1.2.114) and it will also show that the name WEBHOST2 is also associated with that IP address.
The corporate DNS server includes entries that map host names to IP addresses. The corporate DNS server entries map network host names to the IP addresses of the hosts that those network host names are assigned to. The corporate DNS must include an entry for each production site host and standby site host, which will maps the network host name for the host to the IP address of the host. These network host names are visible in the network that includes the Oracle Application Server Disaster Recovery production site and standby site.
Regardless of whether you are using local host name file resolution (/etc/hosts file entries) or you are using DNS host name resolution exclusively (no /etc/hosts file entries) for your Oracle Application Server Disaster Recovery topology, you must make sure that the corporate DNS includes an entry for each production site host and standby site host that maps the network host name for the host to the IP address of the host.
When you are using DNS host name resolution exclusively for all host name resolution (in other words, if you are not using /etc/hosts files for local host name resolution), then in addition to making network host names entries for the production site hosts and the standby site hosts in the corporate DNS, you must also have a DNS server for the production site and a DNS server for the standby site. You will make Application Server host name entries for the production site hosts in the production site DNS and make Application Server host name entries for the standby site hosts in the standby site DNS. Logically, the entries in the production site DNS and standby site DNS serve the same purpose as the /etc/hosts file entries when local host name file resolution is used; the difference is that all the Application Server host names for a site are consolidated into one location (one DNS server).
Note:
For the DNS configuration described in this section to work properly, these requirements must be met:The production site DNS server and standby site DNS server must not be aware of each other. They should make non-authoritative lookup requests to the corporate DNS servers only if they fail to resolve a host name within their specific site.
The production site DNS server and standby site DNS server must contain entries for only Application Server host names used within their own site.
The overall corporate DNS servers contain network host names and any other aliases or virtual names that needed for the site currently serving in the production role.
If you are using DNS host name resolution exclusively (not using /etc/hosts file entries to implement local host name file resolution), then there should be no entries in the /etc/hosts file for any host at the production site or standby site to any other host in either site.
Section 2.1.7.1, "Making Host Name Entries in the Corporate DNS" describes how to make network host name entries for the production site hosts and standby site hosts in the corporate DNS server.Section 2.1.7.3, "Making Host Name Entries in the Standby Site DNS" describes how to make host name entries for the standby site.
Section 2.1.7.2, "Making Host Name Entries in the Production Site DNS" describes how to make Application Server host name entries for production site hosts in the production site DNS.
Section 2.1.7.3, "Making Host Name Entries in the Standby Site DNS" describes how to make Application Server host name entries for standby site hosts in the standby site DNS.
You must make sure that the corporate DNS includes an entry for each production site host and standby site host that maps the network host name for the host to the IP address of the host. Example 2-8 shows the entries to make in the corporate DNS server for the Oracle Application Server Disaster Recovery topology that uses the EDG deployment in Figure 2-1 for the production site and standby site:
Example 2-8 Network Host Name Entries for Production Site Hosts and Standby Site Hosts in the Corporate DNS
PRODOID1.ORACLE.COM IN A 123.1.2.111 PRODOID2.ORACLE.COM IN A 123.1.2.112 PRODWEB1.ORACLE.COM IN A 123.1.2.113 PRODWEB2.ORACLE.COM IN A 123.1.2.114 PRODAPP1.ORACLE.COM IN A 123.1.2.115 PRODAPP2.ORACLE.COM IN A 123.1.2.116 PRODWEB3.ORACLE.COM IN A 123.1.2.117 PRODWEB4.ORACLE.COM IN A 123.1.2.118 PRODIDM1.ORACLE.COM IN A 123.1.2.119 PRODIDM2.ORACLE.COM IN A 123.1.2.120 STBYOID1.ORACLE.COM IN A 123.2.2.111 STBYOID2.ORACLE.COM IN A 123.2.2.112 STBYWEB1.ORACLE.COM IN A 123.2.2.113 STBYWEB2.ORACLE.COM IN A 123.2.2.114 STBYAPP1.ORACLE.COM IN A 123.2.2.115 STBYAPP2.ORACLE.COM IN A 123.2.2.116 STBYWEB3.ORACLE.COM IN A 123.2.2.117 STBYWEB4.ORACLE.COM IN A 123.2.2.118 STBYIDM1.ORACLE.COM IN A 123.2.2.119 STBYIDM2.ORACLE.COM IN A 123.2.2.120
If your Oracle Application Server Disaster Recovery topology uses only DNS resolution for Application Server host names and network host names, configure the production site DNS server to use the corporate DNS server as the forwarding server for unresolved requests.
Make entries for the production site Application Server host names in the production site DNS to configure host name resolution for these host names. Example 2-9 shows the Application Server host name entries to make in the production site DNS server:
Example 2-9 Application Server Host Name Entries for Production Site Hosts in the Production Site DNS
OIDHOST1.ORACLE.COM IN A 123.1.2.111 OIDHOST2.ORACLE.COM IN A 123.1.2.112 WEBHOST1.ORACLE.COM IN A 123.1.2.113 WEBHOST2.ORACLE.COM IN A 123.1.2.114 APPHOST1.ORACLE.COM IN A 123.1.2.115 APPHOST2.ORACLE.COM IN A 123.1.2.116 WEBHOST3.ORACLE.COM IN A 123.1.2.117 WEBHOST4.ORACLE.COM IN A 123.1.2.118 IDMHOST1.ORACLE.COM IN A 123.1.2.119 IDMHOST2.ORACLE.COM IN A 123.1.2.120
If your Oracle Application Server Disaster Recovery topology uses only DNS resolution for Application Server host names and network host names, configure the standby site DNS server to use the corporate DNS server as the forwarding server for unresolved requests.
Make entries for the standby site Application Server host names in the standby site DNS to configure host name resolution for these host names. Example 2-10 shows the Application Server host name entries to make in the standby site DNS server:
Example 2-10 Application Server Host Name Entries for Standby Site Hosts in the Standby Site DNS
OIDHOST1.ORACLE.COM IN A 123.2.2.111 OIDHOST2.ORACLE.COM IN A 123.2.2.112 WEBHOST1.ORACLE.COM IN A 123.2.2.113 WEBHOST2.ORACLE.COM IN A 123.2.2.114 APPHOST1.ORACLE.COM IN A 123.2.2.115 APPHOST2.ORACLE.COM IN A 123.2.2.116 WEBHOST3.ORACLE.COM IN A 123.2.2.117 WEBHOST4.ORACLE.COM IN A 123.2.2.118 IDMHOST1.ORACLE.COM IN A 123.2.2.119 IDMHOST2.ORACLE.COM IN A 123.2.2.120
Follow these steps to prepare for setting up the Oracle Application Server Disaster Recovery topology:
On the production site, install the Oracle databases that will be used in the Oracle Application Server Disaster Recovery topology that you are setting up. Then create standby databases on the standby site and configure Oracle Data Guard for the production and standby databases. For more information, see Section 2.2.1, "Database Considerations."
The Oracle home directories for each of the Application Server instances used at the production site (the Application Server instances shown in Figure 2-1) must be on volumes in the shared storage for the production site. The Oracle homes for these Application Server instances cannot be in local storage for the middle tier hosts that use the instances. Therefore, begin preparing the environment by planning where (on which volumes in the production site shared storage) you will create the Oracle home directories for the production site Application Server instances. See Section 2.2.2, "Creating Volumes, Mount Points, and Symbolic Links" for more information about planning and creating volumes for the Oracle Application Server instances in the production site shared storage.
Then plan the mount points and symbolic links to create to the Oracle home directories that will be used for the Oracle Application Server instances on the production site shared storage. No Oracle software is installed in local storage for the middle tier hosts that use these instances at either the production site or standby site. For more on planning and creating mount points and symbolic links for the Oracle Application Server homes on the shared storage, see Section 2.2.2, "Creating Volumes, Mount Points, and Symbolic Links."
Validate the environment by connecting to each host at the production site and using the ping command to ensure that the host can locate the other hosts at the production site. Then connect to each host at the standby site and use the ping command to ensure that the host can locate the other hosts at the standby site. See Section 2.2.3, "Testing the Host Name Resolution" for more information.
The rest of this section describes how to perform these steps for the Oracle Application Server Disaster Recovery topology for the deployment shown in Figure 2-1.
This section describes how to set up the Oracle databases that will be used in the Oracle Application Server Disaster Recovery topology that you are setting up. These are the tasks to perform for databases:
Install the Oracle databases that will be used in the Oracle Application Server Disaster Recovery topology that you are setting up.
For more information about this step, refer to Section A.1, "Installing the Oracle Databases in the Production Site."
Create a standby database for each database included in your Oracle Application Server Disaster Recovery production site.
For more information about this step, refer to Section A.2, "Creating Standby Databases at the Standby Site."
Set up the Oracle Data Guard configuration for databases at the production site and standby site in your Oracle Application Server Disaster Recovery topology.
For more information about this step, refer to Section A.3, "Setting Up the Oracle Data Guard Configuration."
Set up TNSNAMES.ORA entries to enable the production site databases and standby site databases to reference each other.
For more information about this step, refer to Section A.3, "Setting Up the Oracle Data Guard Configuration."
For Oracle Application Server components that store middle tier configuration data in Oracle database repositories, use Oracle Data Guard to manually force a database synchronization whenever a middle tier synchronization is performed.
For more information about this step, refer to Section A.5, "Manually Forcing Database Synchronization with Oracle Data Guard."
Optionally, set up database host name aliases for the databases at your production site and standby site. The alias must be defined in DNS or in the /etc/hosts file on each node running a database instance.
For more information about this step, refer to Section A.6, "Setting Up Database Host Name Aliases."
This section includes the following topics:
Creating Volumes for the Application Server Host Clusters
This section describes how to create a volume on the shared storage for each of the Application Server host clusters in the EDG deployment in Figure 2-1.
Creating Mount Points, Symbolic Links, and Oracle Home Directories
This section describes how to create Oracle home directories for the Application Server instances for a host cluster on the cluster's volume, and how to create mount points and symbolic links on the hosts to the Oracle home directories.
Creating Mount Points, Symbolic Links, and Oracle Central Inventory Directories
This section describes how to create Oracle Central Inventory directories for the Application Server instances for a host cluster on the cluster's volume, and how to create mount points and symbolic links on the hosts to the Oracle Central Inventory directories.
Creating Mount Points, Symbolic Links, and Static HTML Pages Directories
This section describes how to create static HTML pages directories for Oracle HTTP Server instances for a host cluster on the cluster's volume, and how to create mount points and symbolic links on the hosts to the static HTML pages directories.
There are five Oracle Application Server host clusters in the EDG deployment shown in Figure 2-1. The Oracle Application Server instances for each of these host clusters must be installed on the volume created for that host cluster. The reason for using a separate volume for each host cluster is to ensure data consistency for the cluster across the production site shared storage and standby site shared storage.
Note:
This section describes how to create volumes, mount points, and symbolic links for the EDG deployment production site shown in Figure 2-1. These are preliminary steps that you perform before installing the production site Oracle Application Server instances.Do not install any production site Oracle Application Server instances until you are directed to do so later in this manual.
Table 2-4 shows the volume that will be created for each host cluster. In Table 2-4, the host clusters are shown in the order in which the Oracle Application Server instances for the host cluster are installed and configured in the Oracle Application Server Enterprise Deployment Guide.
Table 2-4 Volumes To Be Created for Each Oracle Application Server Host Cluster in the EDG Deployment
| Host Cluster | Volume for Host ClusterFoot 1 |
|---|---|
|
OIDHOST1 and OIDHOST2 |
/vol/voloid |
|
WEBHOST1 and WEBHOST2 |
/vol/volweb1 |
|
APPHOST1 and APPHOST2 |
/vol/volapp |
|
WEBHOST3 and WEBHOST4 |
/vol/volweb2 |
|
IDMHOST1 and IDMHOST2 |
/vol/volidm |
Footnote 1 These examples use /vol in the volume name. Refer to vendor-specific storage documentation for approved naming of volumes.
Create a volume on the shared storage for each of the Application Server host clusters. The examples later in this section assume that the volumes for the host clusters in Table 2-4 have been created.
Note:
Some shared storage (for example, NAS, NFS, or SAN storage) may not provide the reliable file locking that Oracle HTTP Server requires. When a 10.1.2.x or 10.1.3.x Oracle HTTP Server instance is installed on shared storage that does not provide reliable file locking, the Oracle HTTP Server instance may experience performance problems.In this situation, perform the steps in Section G.1.3, "Changing the LockFile Directive for 10.1.2.x and 10.1.3.x Oracle HTTP Server Instances" and Section G.1.4, "Use the DEFAULT_DMS_DIR Environment Variable for Oracle HTTP Server 10.1.3.x Instances" to resolve the Oracle HTTP Server performance issues.
In this section, mount points and symbolic links are set up on the Oracle Application Server host clusters to the Oracle home directories on the storage volume where the Application Server instances will be installed. These mount points and symbolic links are set up so that the same directory structure can be used on each Oracle Application Server host in the cluster. Using the mount points and symbolic links on the host simplifies the installation, management and maintenance of the Oracle Application Server instances for the hosts in the clusters.
Table 2-5 shows each Oracle Application Server host in the EDG deployment in Figure 2-1 and the type of Oracle Application Server instance or instances that need to be installed for each host. For each Oracle Application Server instance, the table shows the mount point directory to create on the host to the Oracle home directory on the storage volume, the symbolic link to create on the host to the Oracle home directory on the volume, and the actual Oracle home directory to create on the volume for the instance. The reason for creating the symbolic links on each host is to ensure that the same Oracle home directory path is used for the instances in each host cluster.
Table 2-5 Mount Points, Links, and Oracle Homes for OracleAS Instances
| Host | Application Server Instance Type | Host Mount Point Directory to Oracle Home Directory on Volume | Link on Host to Oracle Home Directory on Volume | Oracle Home Directory on Volume |
|---|---|---|---|---|
|
OIDHOST1 |
Oracle Internet Directory |
/u02/voloidmount/oid1_oh |
/u01/app/oracle/oid_oh |
/vol/voloid/oid1_oh |
|
OIDHOST2 |
Oracle Internet Directory |
/u02/voloidmount/oid2_oh |
/u01/app/oracle/oid_oh |
/vol/voloid/oid2_oh |
|
WEBHOST1 |
Oracle HTTP Server |
/u02/volweb1mount/web1_oh |
/u01/app/oracle/web_oh |
/vol/volweb1/web1_oh |
|
WEBHOST2 |
Oracle HTTP Server |
/u02/volweb1mount/web2_oh |
/u01/app/oracle/web_oh |
/vol/volweb1/web2_oh |
|
APPHOST1 |
First OC4J Instance |
/u02/volappmount/app1_oh1 |
/u01/app/oracle/app_oh |
/vol/volapp/app1_oh1 |
|
APPHOST1 |
Second OC4J Instance |
/u02/volappmount/app1_oh2 |
/u01/app/oracle/app_oh2 |
/vol/volapp/app1_oh2 |
|
APPHOST2 |
First OC4J Instance |
/u02/volappmount/app2_oh1 |
/u01/app/oracle/app_oh |
/vol/volapp/app2_oh1 |
|
APPHOST2 |
Second OC4J Instance |
/u02/volappmount/app2_oh2 |
/u01/app/oracle/app_oh2 |
/vol/volapp/app2_oh2 |
|
WEBHOST3 |
Oracle HTTP Server |
/u02/volweb2mount/web3_oh |
/u01/app/oracle/web_oh |
/vol/volweb2/web3_oh |
|
WEBHOST4 |
Oracle HTTP Server |
/u02/volweb2mount/web4_oh |
/u01/app/oracle/web_oh |
/vol/volweb2/web4_oh |
|
IDMHOST1 |
Oracle Identity Management |
/u02/volidmmount/idm1_oh |
/u01/app/oracle/idm_oh |
/vol/volidm/idm1_oh |
|
IDMHOST2 |
Oracle Identity Management |
/u02/volidmmount/idm2_oh |
/u01/app/oracle/idm_oh |
/vol/volidm/idm2_oh |
Example 2-11 uses hosts OIDHOST1 and OIDHOST2 to show the basic steps for creating the Oracle home directories for a host cluster's Application Server instances on its storage volume, and for setting up mount points and symbolic links on the host cluster to the Oracle home directories on the volume.
Figure 2-2 shows the storage after the Oracle home directories for the Oracle Application Server instances for OIDHOST1 and OIDHOST2 have been created on the /vol/voloid volume , and the mount points and symbolic links to the Oracle home directories have been set up on the hosts, as described in the following steps.
Figure 2-2 Links on OIDHOST1 and OIDHOST2 to Oracle Home Directories for Application Server Instances on Storage
Example 2-11 Setting Up Mount Points and Symbolic Links to Oracle Home Directories
Log in as root on OIDHOST1 and create the following directories:
prompt> mkdir /u01/app/oracle prompt> mkdir /u02/voloidmount
On OIDHOST1, mount the /u02/voloidmount directory to the /vol/voloid volume on the storage, and set up the mount point permissions and ownership as necessary. Refer to vendor-specific information for the shared storage to perform this step.
While logged in as root on OIDHOST1, mount the storage volume:
prompt> mount /u02/voloidmount
On OIDHOST1, create the Oracle home directory for the Oracle Application Server instance in the storage:
prompt> cd /u02/voloidmount prompt> mkdir oid1_oh
On OIDHOST1, create a symbolic link named oid_oh in the /u01/app/oracle directory to the /u02/voloidmount/oid1_oh directory on the storage:
prompt> cd /u01/app/oracle prompt> ln -s /u02/voloidmount/oid1_oh oid_oh
On OIDHOST1, the following command changes the working directory to the /vol/voloid/oid1_oh directory on the storage.
prompt> cd /u01/app/oracle/oid1_oh
You do not install the Oracle Application Server instance for OIDHOST1 now. The Application Server installations are performed later. For more information about installing Oracle Application Server instances on the storage volumes, see Section 2.3, "Installing the Oracle Application Server Instances for the Production Site."
Log in as root on OIDHOST2 and create the following directories:
prompt> mkdir /u01/app/oracle prompt> mkdir /u02/voloidmount
On OIDHOST2, mount the /u02/voloidmount directory to the /vol/voloid volume on the storage, and set up the mount point permissions and ownership as necessary. Refer to vendor-specific information for the shared storage to perform this step.
While logged in as root on OIDHOST2, mount the storage volume:
prompt> mount /u02/voloidmount
On OIDHOST2, create the Oracle home directory for the Oracle Application Server instance in the storage:
prompt> cd /u02/voloidmount prompt> mkdir oid2_oh
On OIDHOST2, create a symbolic link named oid_oh in the /u01/app/oracle directory to the /u02/voloidmount/oid2_oh directory on the storage:
prompt> cd /u01/app/oracle prompt> ln -s /u02/voloidmount/oid2_oh oid_oh
On OIDHOST2, the following command changes the working directory to the /vol/voloid/oid2_oh directory on the storage.
prompt> cd /u01/app/oracle/oid_oh
You do not install the Oracle Application Server instance for OIDHOST2 now. The Application Server installations are performed later. For more information about installing Oracle Application Server instances on the storage volumes, see Section 2.3, "Installing the Oracle Application Server Instances for the Production Site."
Use similar steps for the other host clusters in Table 2-4 to create the storage volumes and Oracle home directories on the host cluster's volume, and then to create the mount points and symbolic links on the hosts to the Oracle Application Server homes on the volume. Use the information in Table 2-5 to perform this step.
Figure 2-3 shows the shared storage after the Oracle home directories for the Oracle Application Server instances for WEBHOST1 and WEBHOST2 have been created on the /vol/volweb1 volume, and the mount points and symbolic links to the Oracle home directories have been set up on the hosts.
Figure 2-3 Links on WEBHOST1 and WEBHOST2 to Oracle Home Directories for Application Server Instances on Storage
Figure 2-4 shows the shared storage after the Oracle homes for the Oracle Application Server instances for APPHOST1 and APPHOST2 have been created on the /vol/volapp volume, and the mount points and symbolic links to the Oracle home directories have been set up on the hosts.
Figure 2-4 Links on APPHOST1 and APPHOST2 to Oracle Home Directories for Application Server Instances on Storage
Figure 2-5 shows the shared storage after the Oracle home directories for the Oracle Application Server instances for WEBHOST3 and WEBHOST4 have been created on the /vol/volweb2 volume, and the mount points and symbolic links to the Oracle home directories have been set up on the hosts.
Figure 2-5 Links on WEBHOST3 and WEBHOST4 to Oracle Home Directories for Application Server Instances on Storage
Figure 2-6 shows the shared storage after the Oracle home directories for the Oracle Application Server instances for IDMHOST1 and IDMHOST2 have been created on the /vol/volidm volume, and the mount points and symbolic links to the Oracle home directories have been set up on the hosts.
Figure 2-6 Links on IDMHOST1 and IDMHOST2 to Oracle Home Directories for Application Server Instances on Storage
This section describes how to create a directory on the volume for a host cluster to store the Oracle Central Inventory for each host in the cluster, and how to set up a mount point directory and symbolic link on the host to the Oracle Central Inventory directory on the volume.
If the Oracle Central Inventory for a host cluster is on the cluster's volume on the shared storage, the Oracle Central Inventory will be updated when patches or patch sets are applied to an Application Server instance for the host cluster. Then, when the host cluster volume is replicated from the production site shared storage to the standby site shared storage, the updated Oracle Central Inventory will be replicated to the standby site shared storage. Therefore, you only need to apply patches and patch sets at the production site; any updates to the Oracle Central Inventory at the production site will be replicated to the corresponding host cluster volume at the standby site.
Table 2-6 shows where to create directories to store the Oracle Central Inventory for each host on the host's volume in the shared storage. It also shows the mount points and symbolic links to set up on the host to access the Oracle Central Inventory directory on the volume.
Table 2-6 Mount Points and Symbolic Links to Oracle Central Inventory Directories on Volumes
| Host | Host Mount Point Directory to Oracle Central Inventory Directory on Volume | Link on Host to Oracle Central Inventory Directory on Volume | Oracle Central Inventory Directory on Volume |
|---|---|---|---|
|
OIDHOST1 |
/u02/voloidmount/oid_orainv |
/u01/app/oracle/oid_orainv |
/vol/voloid/oid_orainv |
|
OIDHOST2 |
/u02/voloidmount/oid_orainv |
/u01/app/oracle/oid_orainv |
/vol/voloid/oid_orainv |
|
WEBHOST1 |
/u02/volweb1mount/web_orainv |
/u01/app/oracle/web_orainv |
/vol/volweb1/web_orainv |
|
WEBHOST2 |
/u02/volweb1mount/web_orainv |
/u01/app/oracle/web_orainv |
/vol/volweb1/web_orainv |
|
APPHOST1 |
/u02/volappmount/app_orainv |
/u01/app/oracle/app_orainv |
/vol/volapp/app_orainv |
|
APPHOST2 |
/u02/volappmount/app_orainv |
/u01/app/oracle/app_orainv |
/vol/volapp/app_orainv |
|
WEBHOST3 |
/u02/volweb2mount/web_orainv |
/u01/app/oracle/web_orainv |
/vol/volweb2/web_orainv |
|
WEBHOST4 |
/u02/volweb2mount/web_orainv |
/u01/app/oracle/web_orainv |
/vol/volweb2/web_orainv |
|
IDMHOST1 |
/u02/volidmmount/idm_orainv |
/u01/app/oracle/idm_orainv |
/vol/volidm/idm_orainv |
|
IDMHOST2 |
/u02/volidmmount/idm_orainv |
/u01/app/oracle/idm_orainv |
/vol/volidm/idm_orainv |
Example 2-12 shows the steps for creating the Oracle Central Inventory directory on the host cluster volume for hosts OIDHOST1 and OIDHOST2. The example assumes that the /u02/voloidmount and /u01/app/oracle directories were already created on the hosts (see Example 2-11).
Example 2-12 Setting Up Mount Points and Symbolic Links to Oracle Inventory Directories
On OIDHOST1, log in as root and create the directory for the Oracle Central Inventory in the storage:
prompt> cd /u02/voloidmount prompt> mkdir oid_orainv
On OIDHOST1, create a symbolic link named oid_orainv in the /u01/app/oracle directory to the /u02/voloidmount/oid_orainv Oracle Central Inventory directory on the storage:
prompt> cd /u01/app/oracle prompt> ln -s /u02/voloidmount/oid_orainv oid_orainv
On OIDHOST1, the following command changes the working directory to the /vol/voloid/oid_orainv directory where the host's Oracle Central Inventory will be located on the storage:
prompt> cd /u01/app/oracle/oid_orainv
On OIDHOST2, log in as root and create the directory for the Oracle Central Inventory in the storage:
prompt> cd /u02/voloidmount prompt> mkdir oid_orainv
On OIDHOST2, create a symbolic link named oid_orainv in the /u01/app/oracle directory to the /u02/voloidmount/oid_orainv Oracle Central Inventory directory on the storage:
prompt> cd /u01/app/oracle prompt> ln -s /u02/voloidmount/oid_orainv oid_orainv
On OIDHOST2, the following command changes the working directory to the /vol/voloid/oid_orainv directory where the host's Oracle Central Inventory will be located on the storage:
prompt> cd /u01/app/oracle/oid_orainv
Use similar steps for the other host clusters in Table 2-4 to create the Oracle Central Inventory directories on the host cluster's volume, and then to create the mount points and symbolic links on the hosts to the Oracle Central Inventory on the volume. Use the information in Table 2-6 to perform this step.
As described in Section 1.2.3.2, "Disaster Recovery Recommendations for Oracle HTTP Server," the static HTML pages for Oracle HTTP Server are deployed by administrators and are typically maintained outside Oracle home directories. In an Oracle Application Server Disaster Recovery topology, you must store these static HTML pages in a directory on the shared storage, and set up mount points and symbolic on the hosts that access the static HTML directories in the shared storage.
If the static HTML pages for a production site host cluster are on the cluster's volume on the shared storage, any changes to those pages will be replicated from the production site shared storage to the corresponding host cluster volume at the standby site.
Table 2-7 shows where to create directories to store the static HTML pages for the production site hosts that use Oracle HTTP Server on the host's volume in the shared storage. It also shows the mount points and symbolic links to set up on the hosts to access the static HTML pages directory on the volume.
Table 2-7 Mount Points and Symbolic Links to Static HTML Directories on Volumes
| Host | Host Mount Point Directory to Static HTML Directory on Volume | Link on Host to Static HTML Directory on Volume | Static HTML Directory on Volume |
|---|---|---|---|
|
WEBHOST1 |
/u02/volweb1mount/web1_sthtml |
/u01/app/oracle/web_sthtml |
/vol/volweb1/web1_sthtml |
|
WEBHOST2 |
/u02/volweb1mount/web2_sthtml |
/u01/app/oracle/web_sthtml |
/vol/volweb1/web2_sthtml |
|
WEBHOST3 |
/u02/volweb2mount/web3_sthtml |
/u01/app/oracle/web_sthtml |
/vol/volweb2/web3_sthtml |
|
WEBHOST4 |
/u02/volweb2mount/web4_sthtml |
/u01/app/oracle/web_sthtml |
/vol/volweb2/web4_sthtml |
Example 2-13 shows the steps for creating the static HTML pages directory on the host cluster volume for hosts WEBHOST1 and WEBHOST2. The example assumes that the /u02/volweb1mount and /u01/app/oracle directories were already created on the hosts.
Example 2-13 Setting Up Mount Points and Symbolic Links to Static HTML Pages Directories
On WEBHOST1, log in as root and create the directory for the static HTML pages in the storage:
prompt> cd /u02/volweb1mount prompt> mkdir web1_sthtml
On WEBHOST1, create a symbolic link named web_sthtml in the /u01/app/oracle directory to the /u02/volweb1mount/web1_sthtml static HTML pages directory on the storage:
prompt> cd /u01/app/oracle prompt> ln -s /u02/volweb1mount/web1_sthtml web_sthtml
On WEBHOST1, the following command changes the working directory to the /vol/volweb1/web1_sthtml directory where the host's static HTML pages will be located on the storage:
prompt> cd /u01/app/oracle/web_sthtml
On WEBHOST2, log in as root and create the directory for the static HTML pages in the storage:
prompt> cd /u02/volweb1mount prompt> mkdir web2_sthtml
On WEBHOST2, create a symbolic link named oid_sthtml in the /u01/app/oracle directory to the /u02/volweb1mount/web2_sthtml static HTML pages directory on the storage:
prompt> cd /u01/app/oracle prompt> ln -s /u02/volweb1mount/web2_sthtml web_sthtml
On WEBHOST2, the following command changes the working directory to the /vol/volweb1/web2_sthtml directory where the host's static HTML pages will be located on the storage:
prompt> cd /u01/app/oracle/web_sthtml
Use similar steps for the other host clusters in Table 2-4 that require static HTML pages directories (in the EDG deployment, this would be the WEBHOST3 and WEBHOST4 host cluster). After you create the static HTML pages directories on the host cluster's volume, create the mount points and symbolic links on the hosts to the static HTML pages directories on the volume. Use the information in Table 2-7 to perform this step.
Validate that you have assigned host names properly by connecting to each host at the production site and using the ping command to ensure that the host can locate the other hosts at the production site.
Then, connect to each host at the standby site and use the ping command to ensure that the host can locate the other hosts at the standby site.
After you have performed all the steps in Section 2.2.2 through Section 2.2.3, you can begin to install the Oracle Application Server instances into the Oracle home directories on the production site shared storage.
The topics in this section are:
During the planning of your Oracle Application Server Disaster Recovery topology, you planned the Application Server host names to use for your production site and standby site hosts. The Application Server host name for a host is included in the Oracle Application Server Disaster Recovery topology when you install an Oracle Application Server instance for the host. The Application Server host name for a host is assigned as follows during installation:
You can choose the Application Server host name to use for a host by specifying it as the second entry (after the 127.0.0.1 localhost.domain entry) in the /etc/hosts file for the host for which you are installing the instance. For example, specifying the following entry as the second entry in the /etc/hosts file for a host with an IP address of 123.1.2.111 will result in an Application Server host name of OIDHOST1 being used for that host:
123.1.2.111 OIDHOST1.ORACLE.COM OIDHOST1
Before installing an Oracle Application Server instance for release 10.1.3 for a host, you can use the VIRTUAL_HOST_NAME environment variable to specify the Application Server host name you want to use for the host (even though the name of this variable is VIRTUAL_HOST_NAME, it does set the Application Server host name for the host). For example, if you set the following environment variable before installing an Oracle Application Server 10.1.3 instance for a host, an Application Server host name of OIDHOST2 will be assigned to the host:
setenv VIRTUAL_HOST_NAME OIDHOST2
Setting the VIRTUAL_HOST_NAME variable before a 10.1.3 installation causes the Application Server host name specified with the variable to take precedence over the second entry in the /etc/hosts file.
If the second entry in the /etc/hosts file is not the IP address of the host for which the installation is being performed and the VIRTUAL_HOST_NAME environment variable is not specified (for 10.1.3 installations only), then the Application Server host name that will be used for the host is the name returned when the hostname command is issued on the host.
During the installation of the Oracle Application Server instance for the host, the installation procedure will prompt you for the Oracle home directory into which to install the instance. To install the software properly, specify the symbolic link that you created for the Oracle home. in Table 2-5 in Section 2.2.2, "Creating Volumes, Mount Points, and Symbolic Links."
For example, when you are installing the Oracle Application Server instance for OIDHOST1 and the installation prompts you for the Oracle home directory into which to install the instance, you would specify the /u01/app/oracle/oid_oh directory. This is a symbolic link to the /vol/voloid/oid1_oh directory on the storage, so the Oracle Internet Directory instance will be installed into the /vol/voloid/oid1_oh directory on the storage. See Table 2-5 for the names of the symbolic links set up for the Oracle home directories needed for the EDG deployment in Figure 2-1.
Similarly, when you are installing the Oracle Application Server instance for OIDHOST2 and the installation prompts you for the Oracle home directory into which to install the instance, you would specify the /u01/app/oracle/oid_oh directory. This is a symbolic link to the vol/voloid/oid2_oh directory on the storage, so the Oracle Internet Directory instance will be installed into the /vol/voloid/oid2_oh directory on the storage. Again, see Table 2-5 for the names of the symbolic links set up for the Oracle home directories needed for the EDG deployment in Figure 2-1.
Follow these steps to finish setting up disk replication for the Oracle Application Server Disaster Recovery topology:
On the standby site, make sure the same Application Server host names are used for middle tier hosts as were used for the middle tier hosts at the production site.
On the shared storage at the standby site, create the same volumes as were created on the shared storage at the production site.
On the standby site, create the same mount points and symbolic links that you created at the production site.
Note:
It is not necessary to install the same Oracle Application Server instances at the standby site as were installed at the production site. When the production site storage is replicated to the standby site storage, the Oracle software installed on the production site volumes will be replicated at the standby site volumes.Perform any other necessary configuration required by the shared storage vendor to enable disk replication between the production site shared storage and the standby site shared storage.
Create the baseline snapshot copy of the production site shared storage that sets up the replication between the production site and standby site shared storage. Create the initial baseline copy and subsequent snapshot copies using asynchronous replication mode. After the baseline snapshot copy is performed, validate that all the directories inside the standby site volumes have the same contents as the directories inside the production site volumes.
Set up the frequency of subsequent copies of the production site shared storage, which will be replicated at the standby site. When asynchronous replication mode is used, then at the requested frequency the changed data blocks at the production site shared storage (based on comparison to the previous snapshot copy) become the new snapshot copy, and the snapshot copy is transferred to the standby site shared storage.
Make sure that disaster protection for any database that is included in the Oracle Application Server Disaster Recovery production site is provided by Oracle Data Guard, as described earlier in Section 2.2.1, "Database Considerations." Do not use disk replication technology to provide disaster protection for Oracle databases.
The standby site shared storage receives snapshots transferred on a periodic basis from the production site shared storage. After the snapshots are applied, the standby site shared storage will include all the data up to and including the data contained in the last snapshot transferred from the production site before the failover or switchover.
You should manually force a synchronization operation whenever a change is made to the middle tier at the production site (for example, when a new application is deployed at the production site). Follow the vendor-specific instructions for forcing a synchronization using disk replication technology.
The synchronization of the databases in the OracleAS Disaster Recovery topology is managed by Oracle Data Guard.
When the production site becomes unavailable unexpectedly, you must perform a failover operation so that the standby site takes over the production role.
Follow these steps to perform a failover operation (these steps assume that the host names and mount points have been configured properly) :
Shut down any processes still running on the production site (if applicable).
Stop the replication between the production site shared storage and the standby site shared storage.
Use Oracle Data Guard to fail over the databases.
Your production site hosts may include Oracle Application Server instances from different Oracle Application Server releases, such as release 10.1.2.x and 10.1.3.x. For any OC4J instances from Oracle Application Server 10.1.3.x releases, download and run the script provided with OracleMetaLink patch 6785728 in the Oracle home directories for the 10.1.3.x OC4J instances to remove persistent OC4J lock files. The URL for OracleMetaLink is:
Note:
Run the script in the Oracle homes for 10.1.3.x OC4J instances only.On the standby site hosts, manually start up the processes for the Application Server instances.
Ensure that all user requests are routed to the standby site (using a global DNS push or by updating the global load balancer).
Use a browser client to perform post-failover testing to confirm that requests are being resolved and redirected to the new failed over site.
After these steps have been performed, the former standby site has become the currrent production site. At this point, the issues that caused the original production site to become unavailable can be examined. Then work can begin on resolving those issues so that the original production site can be used again at some point in the future as either the production site or standby site, if desired.
To use the original production site as the current standby site, you need to reestablish the replication between the two sites, but configure the replication so that the snapshot copies go in the opposite direction (from the current production site to the current standby site). Refer to the documentation for your shared storage system to learn how to configure the replication so that snapshot copies are transferred in the opposite direction.
To use the original production site as the new production site, you should perform the switchover steps in Section 2.7, "Switchover Steps."
When you plan to take down the production site (for example, to perform maintenance) and make the current standby site the new production site, you must perform a switchover operation so that the standby site takes over the production role.
Follow these steps to perform a switchover operation:
Shut down any processes still running on the production site.
Stop the replication between the production site shared storage and the standby site shared storage.
Use Oracle Data Guard to switch over the databases.
Your production site hosts may include Oracle Application Server instances from different Oracle Application Server releases, such as release 10.1.2.x and 10.1.3.x. For any OC4J instances from Oracle Application Server 10.1.3.x releases, download and run the script provided with OracleMetaLink patch 6785728 in the Oracle home directories for the 10.1.3.x OC4J instances to remove persistent OC4J lock files. The URL for OracleMetaLink is:
Note:
Run the script in the Oracle homes for 10.1.3.x OC4J instances only.On the standby site hosts, manually start up the processes for the Application Server instances.
Ensure that all user requests are routed to the standby site (using a global DNS push or by updating the global load balancer).
Use a browser client to perform post-switchover testing to confirm that requests are being resolved and redirected to the new switched over site.
After these steps have been performed, the former standby site has become the currrent production site. At this point, you can perform maintenance at the original production site. After performing the planned tasks on the original production site, you can use it again at some point in the future as either the production site or standby site.
To use the original production site as the current standby site, you need to reestablish the replication between the two sites, but configure the replication so that the snapshot copies go in the opposite direction (from the current production site to the current standby site). Refer to the documentation for your shared storage to learn how to configure the replication so that snapshot copies are transferred in the opposite direction.
To use the original production site as the new production site, perform the switchover steps described in this section again.
This manual describes how to set up Disaster Recovery for an Oracle Application Server production site and standby site. In a normal Oracle Application Server Disaster Recovery configuration, the following are true:
Disk replication is used to copy Oracle Application Server middle tier file systems and data from the production site shared storage to the standby site shared storage. During normal operation, the production site is active and the standby site is passive. When the production site is active, the standby site is passive and the standby site shared storage is in read-only mode; the only write operations made to the standby site shared storage are the disk replication operations from the production site shared storage to the standby site shared storage.
Oracle Data Guard is used to copy database data for the production site Oracle databases to the standby databases at standby site. By default, the production site databases are active and the standby databases at the standby site are passive. The standby databases at the standby site are in managed recovery mode while the standby site is in the standby role (is passive). When the production site is active, the only write operations made to the standby databases are the database synchronization operations performed by Oracle Data Guard.
When the production site becomes unavailable, the standby site is enabled to take over the production role. If the current production site becomes unavailable unexpectedly, then a failover operation (described in Section 2.6, "Failover Steps") is performed to enable the standby site to assume the production role. Or, if the current production site is taken down intentionally (for example, for planned maintenance), then a switchover operation (described in Section 2.7, "Switchover Steps") is performed to enable the standby site to assume the production role.
The usual method of testing a standby site is to shut down the current production site and perform a switchover operation to enable the standby site to assume the production role. However, some enterprises may want to perform periodic testing of their Disaster Recovery standby site without shutting down the current production site and performing a switchover operation.
An alternate method of testing the standby site without shutting down the current production site is to create a clone of the read-only standby site shared storage and then use the cloned standby site shared storage in testing. To use this alternate testing method, perform these steps:
Use the cloning technology provided by the shared storage vendor to create a clone of the standby site's read-only volumes on the shared storage at the standby site. Make sure that the cloned standby site volumes are writable. If you want to test the standby site just once, then this can be a one-time clone operation, but if you want to test the standby site regularly, you can set up periodic cloning of the standby site read-only volumes to the standby site's cloned read/write volumes.
Perform a backup of the standby site databases, then modify the Oracle Data Guard replication between the production site and standby site databases.
For 10.1 databases, break the replication by following the instructions in the 10.1 Oracle Data Guard documentation.
For 10.2 and later databases, follow these steps to establish a snapshot standby database:
If you do not have a Flash Recovery Area, set one up.
Cancel Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE CANCEL;
Create a guaranteed restore point:
SQL> CREATE RESTORE POINT standbytest
GUARANTEE FLASHBACK DATABASE;
Archive the current logs at the primary (production) site:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Defer the standby site destination that you will activate:
SQL> ALTER SYSTEM SET
LOG_ARCHIVE_DEST_STATE_2=DEFER;
Activate the target standby database:
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
Mount the database with the Force option if the database was opened read-only:
SQL> STARTUP MOUNT FORCE;
Lower the protection mode and open the database:
SQL> ALTER DATABASE SET STANDBY DATABASE TO
MAXIMIZE PERFORMANCE;
SQL> ALTER DATABASE OPEN;
For 11g databases, use the procedure to establish a snapshot standby database in the "Managing a Snapshot Standby Database" section in the 11g Oracle Data Guard Concepts and Administration.
Use Oracle Data Guard database recovery procedures to bring the standby databases online.
On the standby site computers, modify the mount commands to point to the volumes on the standby site's cloned read/write shared storage by following these steps:
Unmount the read-only shared storage volumes.
Mount the cloned read/write volumes at the same mount point.
Before doing the standby site testing, modify the hostname resolution method for the computers that will be used to perform the testing to ensure that the host names point to the standby site computers and not the production site computers. For example, on a Linux computer, change the /etc/hosts file to point to the virtual IP of the load balancer for the standby site.
Perform the standby site testing.
After you complete the standby site testing, follow these steps to begin using the original production site as the production site again:
Modify the mount commands on the standby site computers to point to the volumes on the standby site's read-only shared storage: In other words, reset the mount commands back to what they were before the testing was performed.
Unmount the cloned read/write shared storage volume.
Mount the read-only shared storage volumes.
At this point, the mount commands are reset to what they were before the standby site testing was performed.
Configure Oracle Data Guard to perform replication between the production site databases and standby databases at the standby site. Performing this configuration puts the standby database into managed recovery mode again:
For 10.1 databases, reinstantiate the databases by following the instructions in the 10.1 Oracle Data Guard documentation.
For 10.2 and later databases, follow these steps:
Revert the activated database back to a physical standby database:
SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO POINT standbytest; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> STARTUP MOUNT FORCE;
Restart managed recovery:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY
DATABASE USING CURRENT LOGFILE DISCONNECT;
Reenable the standby destination and switch logs:
SQL> ALTER SYSTEM SET
LOG ARCHIVE DEST STATE 2=ENABLE;
For 11g databases, set up the replication again by following the steps in the "Managing a Snapshot Standby Database" section in the 11g Oracle Data Guard Concepts and Administration.
Before using the original production site again, modify the hostname resolution method for the computers that will be used to access the production site to ensure that the host names point to the production site computers and not the standby site computers. For example, on a Linux computer, change the /etc/hosts file to point to the virtual IP of the load balancer for the production site.
|
 Copyright © 2008, Oracle. All rights reserved. Legal Notices |
|