Skip Headers
Oracle® Application Server Installation Guide
10g Release 2 (10.1.2) for Microsoft Windows
B14094-03
  Go To Documentation Library
Home
Go To Table Of Contents
Contents
Go To Index
Index

Previous
Previous
Next
Next
 

13 Installing in High Availability Environments: OracleAS Disaster Recovery

This chapter describes how to install Oracle Application Server in OracleAS Disaster Recovery configurations. OracleAS Disaster Recovery is one of the high availability environments supported by Oracle Application Server.

Contents of this chapter:

13.1 OracleAS Disaster Recovery: Introduction

Use the OracleAS Disaster Recovery environment when you want to have two physically separate sites in your environment. One site is the production site, and the other site is the standby site. The production site is active, while the standby site is passive; the standby site becomes active when the production site goes down.

OracleAS 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:

In a symmetric topology, each node in the standby site corresponds to a node in the production site. This includes the nodes running both OracleAS Infrastructure and middle tiers. In an asymmetric topology, the number of instances required on the standby site are fewer than the number on the production site and the number of instances required on the standby site must be the minimum set of instances required to run your site in the event of a switchover or failover operation.

As a small variation to this environment, you can set up the OracleAS Infrastructure on the production site in an OracleAS Cold Failover Cluster environment. See Section 13.2.4, "If You Want to Use OracleAS Cold Failover Cluster on the Production Site" for details.

For these supported topologies, OracleAS Guard will be installed in every Oracle home on every system that is part of your production and standby topology configured for the OracleAS Disaster Recovery solution.

OracleAS Guard can be installed as a standalone install kit located on OracleAS Utility media #2. See Section 13.4, "Installing the OracleAS 10g (10.1.2.0.2) Standalone Install of OracleAS Guard into Oracle Homes" for more information about when this standalone kit should be installed.

Figure 13-1 shows an example symmetric OracleAS Disaster Recovery environment. Each site has two nodes running middle tiers and a node running OracleAS Infrastructure.

Data Synchronization

For OracleAS Disaster Recovery to work, data between the production and standby sites must be synchronized so that failover can happen very quickly. Configuration changes done at the production site must be synchronized with the standby site.

You need to synchronize two types of data. The synchronization method depends on the type of data:

See the Oracle Application Server High Availability Guide for details on how to use Oracle Data Guard and the backup and recovery scripts.

Figure 13-1 OracleAS Disaster Recovery Environment

Description of Figure 13-1  follows
Description of "Figure 13-1 OracleAS Disaster Recovery Environment"

13.2 Setting up the OracleAS Disaster Recovery Environment

Before you can install Oracle Application Server in an OracleAS Disaster Recovery environment, you have to perform these steps:

13.2.1 Ensure Nodes Are Identical at the Operating System Level

Ensure that the nodes are identical with respect to the following items:

  • The nodes are running the same version of the operating system.

  • The nodes have the same operating system patches and packages.

  • You can install Oracle Application Server in the same directory path on all nodes.

13.2.2 Set Up staticports.ini File

The same component must use the same port number on the production and standby sites. For example, if Oracle HTTP Server is using port 80 on the production site, it must also use port 80 on the standby site. To ensure this is the case, create a staticports.ini file for use during installation. This file enables you to specify port numbers for each component. See Section 4.4.4, "Using Custom Port Numbers (the "Static Ports" Feature)" for details.

13.2.3 Set Up Identical Hostnames on Both Production and Standby Sites

The names of the corresponding nodes on the production and standby sites must be identical, so that when you synchronize data between the sites, you do not have to edit the data to fix the hostnames.

For the Infrastructure Nodes

For the node running the infrastructure, set up a virtual name. To do this, specify an alias for the node in the C:\Windows\system32\drivers\etc\hosts file.

For example, on the infrastructure node on the production site, the following line in the hosts file sets the alias to asinfra:

138.1.2.111   prodinfra   asinfra

On the standby site, the following line sets the node's alias to asinfra.

213.2.2.110   standbyinfra   asinfra

When you install OracleAS Infrastructure on the production and standby sites, you specify this alias (asinfra) in the Specify Virtual Hostname screen. The configuration data will then contain this alias for the infrastructure nodes.

For the Middle-Tier Nodes

For the nodes running the middle tiers, you cannot set up aliases like you did for the infrastructure nodes because the installer does not display the Specify Virtual Hostname screen for middle-tier installations. When installing middle tiers, the installer determines the hostname automatically by calling the gethostname() function. You want to be sure that for each middle-tier node on the production site, the corresponding node on the standby site returns the same hostname.

To do this, set up a local, or internal, hostname, which could be different from the public, or external, hostname. You can change the names of the nodes on the standby site to match the names of the corresponding nodes on the production site, or you can change the names of the nodes on both production and standby sites to be the same. This depends on other applications that you might be running on the nodes, and whether changing the node name will affect those applications.

  1. On the nodes whose local names you want to change, set the _CLUSTER_NETWORK_NAME_ environment variable to specify the new local fully qualified name (for example, asmid1.oracle.com).


    Note:

    You must set the _CLUSTER_NETWORK_NAME_ environment variable as a "user" environment variable, not as a "system" environment variable.

  2. Enable the other nodes in the OracleAS Disaster Recovery environment to be able to resolve the node using the new local hostname. You can do this in one of two ways:

    Method 1: Set up separate internal DNS servers for the production and standby sites. This configuration allows nodes on each site (production or standby) to resolve hostnames within the site. Above the internal DNS servers are the corporate, or external, DNS servers. The internal DNS servers forward non-authoritative requests to the external DNS servers. The external DNS servers do not know about the existence of the internal DNS servers. See Figure 13-2.

    Figure 13-2 Method 1: Using DNS Servers

    Description of Figure 13-2  follows
    Description of "Figure 13-2 Method 1: Using DNS Servers"

    Method 1 Details

    1. Make sure the external DNS names are defined in the external DNS zone. Example:

      prodmid1.us.oracle.com     IN  A  138.1.2.333
      prodmid2.us.oracle.com     IN  A  138.1.2.444
      prodinf.us.oracle.com      IN  A  138.1.2.111
      standbymid1.us.oracle.com  IN  A  213.2.2.330
      standbymid2.us.oracle.com  IN  A  213.2.2.331
      standbyinf.us.oracle.com   IN  A  213.2.2.110
      
      
    2. At the production site, create a new zone at the production site using a domain name different from your external domain name. To do this, populate the zone data files with entries for each node in the OracleAS Disaster Recovery environment.

      For the infrastructure node, use the virtual name or alias.

      For the middle-tier nodes, use the node name (the value in the _CLUSTER_NETWORK_NAME_ environment variable).

      The following example uses "asha" as the domain name for the new zone.

      asmid1.asha    IN  A  138.1.2.333
      asmid2.asha    IN  A  138.1.2.444
      asinfra.asha   IN  A  138.1.2.111
      
      

      Do the same for the standby site. Use the same domain name that you used for the production site.

      asmid1.asha    IN  A  213.2.2.330
      asmid1.asha    IN  A  213.2.2.331
      asinfra.asha   IN  A  213.2.2.110
      
      
    3. For each node on the production site, configure the DNS resolver to point to the internal DNS servers instead of the external DNS server.

      Table 13-1 Configure the DNS Resolver to Point to Internal DNS Servers

      Windows 2000 or Windows 2003
      1. Display the Local Area Connection Status dialog.

        In Windows 2000, select Start > Settings > Control Panel. Double-click Network and Dial-up Connections. Then double-click Local Area Connection.

        In Windows 2003, select Start > Control Panel > Network Connections > Local Area Connection.

      2. Click Properties to display the Local Area Connection Properties dialog.

      3. With the General tab selected, select Internet Protocol (TCP/IP) from the list box and click Properties. This displays the Internet Protocol (TCP/IP) Properties dialog.

      4. Replace the existing name server IP address with the IP address of the internal DNS server for the production site.

      5. Click Advanced. This displays the Advanced TCP/IP Settings dialog.

      6. Select the DNS tab, and update the DNS server addresses.


      Do the same for the nodes on the standby site, but use the IP address of the internal DNS server for the standby site.

    4. Create a separate entry for Oracle Data Guard in the internal DNS servers. This entry is used by Oracle Data Guard to ship redo data to the database on the standby site.

      In the next example, the "remote_infra" entry points to the infrastructure node on the standby site. This name is used by the TNS entries on both the production and standby sites so that if a switchover occurs, the entry does not have to be changed.

      Figure 13-3 Entry for Oracle Data Guard in the Internal DNS Servers

      Description of Figure 13-3  follows
      Description of "Figure 13-3 Entry for Oracle Data Guard in the Internal DNS Servers"

      On the production site, the DNS entries look like this:

      asmid1.asha        IN  A  138.1.2.333
      asmid2.asha        IN  A  138.1.2.444
      asinfra.asha       IN  A  138.1.2.111
      remote_infra.asha  IN  A  213.2.2.110
      
      

      On the standby site, the DNS entries look like this:

      asmid1.asha        IN  A  213.2.2.330
      asmid2.asha        IN  A  213.2.2.331
      asinfra.asha       IN  A  213.2.2.110
      remote_infra.asha  IN  A  138.1.2.111
      
      

    Method 2: Edit the C:\Windows\system32\drivers\etc\hosts file on each node on both sites. This method does not involve configuring DNS servers, but you have to maintain the hosts file on each node in the OracleAS Disaster Recovery environment. For example, if an IP address changes, you have to update the files on all the nodes, and restart the nodes.

    Method 2 Details

    1. On each node on the production site, include these lines in the C:\Windows\system32\drivers\etc\hosts file. The IP addresses resolve to nodes on the production site.


      Note:

      In the hosts file, be sure that the line that identifies the current node comes immediately after the localhost definition (the line with the 127.0.0.1 address).

      127.0.0.1    localhost
      138.1.2.333  asmid1.oracle.com   asmid1
      138.1.2.444  asmid2.oracle.com   asmid2
      138.1.2.111  asinfra.oracle.com  asinfra
      
      
    2. On each node on the standby site, include these lines in the hosts file. The IP addresses resolve to nodes on the standby site.


      Note:

      In the hosts file, be sure that the line that identifies the current node comes immediately after the localhost definition (the line with the 127.0.0.1 address).

      127.0.0.1    localhost
      213.2.2.330  asmid1.oracle.com   asmid1
      213.2.2.331  asmid2.oracle.com   asmid2
      213.2.2.110  asinfra.oracle.com  asinfra
      
      
    3. Set the order of hostname resolution so that the node resolves hostnames by reading the hosts file first. If the hosts file does not contain an entry for the desired hostname, then the node will resolve the hostname through DNS.

      You can do this by adding the entries to the hosts file, then running the "nbtstat -R" command to purge cached information and reload the name table. See your system administrator for details.

Verifying that the Nodes Resolve the Hostnames Correctly

After making the changes and restarting the nodes, check that the nodes resolve the hostnames properly by running the following commands:

  • On the middle-tier nodes on both sites, run the hostname command. This should return the internal hostname. For example, the command should return "asmid1" if you run it on prodmid1 and standbymid1.

    C:\> hostname
    asmid1
    
    
  • On each node, ping the other nodes in the environment using the internal hostname as well as the external hostname. The command should be successful. For example, from the first midtier node, prodmid1, run the following commands:

    C:> ping prodinfra        ping the production infrastructure node
    Pinging prodinfra [138.1.2.111] with 32 bytes of data:
    Reply from 138.1.2.111: bytes=32 time<1ms TTL=128
    
    C:> ping asinfra          ping the production infrastructure node
    Pinging prodinfra [138.1.2.111] with 32 bytes of data:
    Reply from 138.1.2.111: bytes=32 time<1ms TTL=128
    
    C:> ping asmid2           ping the second production midtier node
    Pinging asmid2 [138.1.2.444] with 32 bytes of data:
    Reply from 138.1.2.444: bytes=32 time<1ms TTL=128
    
    C:> ping prodmid2         ping the second production midtier node
    Pinging asmid2 [138.1.2.444] with 32 bytes of data:
    Reply from 138.1.2.444: bytes=32 time<1ms TTL=128
    
    C:> ping standbymid1       ping the first standby midtier node
    Pinging asmid2 [213.2.2.330] with 32 bytes of data:
    Reply from 213.2.2.330: bytes=32 time<1ms TTL=128
    
    

13.2.4 If You Want to Use OracleAS Cold Failover Cluster on the Production Site

On the production site of a OracleAS Disaster Recovery system, you can set up the OracleAS Infrastructure to run in a OracleAS Cold Failover Cluster configuration. In this case, you have two nodes in a hardware cluster, and you install the OracleAS Infrastructure on a shared disk. See Chapter 11, "Installing in High Availability Environments: OracleAS Cold Failover Cluster" for details.

Figure 13-4 Infrastructure in an OracleAS Cold Failover Cluster Configuration

Description of Figure 13-4  follows
Description of "Figure 13-4 Infrastructure in an OracleAS Cold Failover Cluster Configuration"

To set up OracleAS Cold Failover Cluster in this environment, use the virtual IP address (instead of the physical IP address) for asinfra.asha on the production site. The following example assumes 138.1.2.120 is the virtual IP address.

asmid1.asha          IN  A  138.1.2.333
asmid2.asha          IN  A  138.1.2.444
asinfra.asha         IN  A  138.1.2.120         this is a virtual IP address
remote_infra.asha    IN  A  213.2.2.110

On the standby site, you still use the physical IP address for asinfra.asha, but the remote_infra.asha uses the virtual IP address.

asmid1.asha          IN  A  213.2.2.330
asmid2.asha          IN  A  213.2.2.331
asinfra.asha         IN  A  213.2.2.110         physical IP address
remote_infra.asha    IN  A  138.1.2.120         virtual IP address

Need to Create the Password File in Oracle Fail Safe

When you are setting up OracleAS Cold Failover Cluster in an OracleAS Disaster Recovery environment, you need to create the password file when you are adding the OracleAS Metadata Repository to the Oracle Fail Safe group.

In Section 11.12.2, "Make OracleAS Metadata Repository Highly Available", in step c, select Yes, create the password file.

In User Name, enter SYS.

In Password and Confirm Password, enter and confirm the password that you want to set for the SYS user.

13.3 Installing Oracle Application Server in an OracleAS Disaster Recovery Environment

Install Oracle Application Server as follows:


Note:

For all of the installations, be sure to use staticports.ini to specify port numbers for the components. See Section 13.2.2, "Set Up staticports.ini File".

  1. Install OracleAS Infrastructure on the production site.

  2. Install OracleAS Infrastructure on the standby site.

  3. Start the OracleAS Infrastructure in each site before installing the middle tiers for that site.

  4. Install middle tiers on the production site.

  5. Install middle tiers on the standby site.

13.3.1 Installing the OracleAS Infrastructure

You must install the Oracle Identity Management and the OracleAS Metadata Repository components of OracleAS Infrastructure on the same node. You cannot distribute the components over multiple nodes.

The installation steps are similar to that for OracleAS Cold Failover Cluster. See Section 11.3, "Installing an OracleAS Cold Failover Cluster (Infrastructure) Configuration" for the screen sequence. Note the following points:

  • Select Configuration Options screen: be sure you select High Availability and Replication. See Table 11-4, step 2.

  • In the Specify Virtual Hostname screen, enter the fully qualified local hostname as the virtual address (for example, asinfra.oracle.com). See Table 11-4, step 6.

13.3.2 Installing Middle Tiers

You can install any type of middle tier that you like:

For installing J2EE and Web Cache, see Section 7.9, "Installing J2EE and Web Cache in a Database-Based Farm Repository and with Oracle Identity Management Access".

For installing Portal and Wireless or Business Intelligence and Forms, see Section 7.13, "Installing Portal and Wireless or Business Intelligence and Forms".

Note the following points:

  • When the installer prompts you to register with Oracle Internet Directory, and asks you for the Oracle Internet Directory hostname, enter the alias of the node running OracleAS Infrastructure (for example, asinfra.oracle.com).

13.4 Installing the OracleAS 10g (10.1.2.0.2) Standalone Install of OracleAS Guard into Oracle Homes

OracleAS 10g (10.1.2.0.2) standalone install of OracleAS Guard is located on Utilities Disk 2. This standalone install of OracleAS Guard can be installed in the following environments:

If this is an upgrade installation of OracleAS Guard, make a copy of your dsa.conf configuration file to save your current settings for your OracleAS Guard environment. After running the OracleAS 10g (10.1.2.0.2) standalone install kit of OracleAS Guard, you can restore your saved dsa.conf configuration file with your settings to continue using the same settings for the upgraded OracleAS Guard environment.

To run the OracleAS 10g (10.1.2.0.2) standalone install kit of OracleAS Guard, run the kit in the following directory path:

On Windows systems:

\Disk2\asg\install\setup.exe

Choose the type of install that you want. Choose Typical for most installations. Choose Custom or Reinstall for upgrading from an older release of OracleAS Guard to the current release.

Enter the ias_admin account password to continue the installation.

13.5 Patching OracleAS Guard Release 10.1.2.0.0 with Release 10.1.2.0.2

If you already have an OracleAS Disaster Recovery environment set up using OracleAS Guard Release 10.1.2.0.0, you can patch OracleAS Guard in your environment to take advantage of new features and support for the topologies described in Section 13.1, "OracleAS Disaster Recovery: Introduction". To patch your OracleAS Disaster Recovery environment, follow these basic steps:

  1. Stop the OracleAS Guard server in all OracleAS 10.1.2.0.0 Oracle homes on both production and standby sites using the following opmnctl command:

    On Windows systems:

    <ORACLE_HOME>\opmn\bin\opmnctl stopall
    
    
  2. Install the OracleAS 10g (10.1.2.0.2) standalone install of OracleAS Guard into each Oracle home on the production and standby sites.

    If multiple Oracle homes exist on the same system, ensure that different ports are configured for each of the OracleAS Guard servers in this configuration file.

    Because this is an upgrade installation of OracleAS Guard, make a copy of your dsa.conf configuration file to save your current settings for your OracleAS Guard environment. After running the OracleAS 10g (10.1.2.0.2) standalone install kit of OracleAS Guard, you can restore your saved dsa.conf configuration file with your settings to continue using the same settings for the upgraded OracleAS Guard environment.

    On Windows systems:

    <ORACLE_HOME>\dsa\dsa.conf
    
    
  3. Start the OracleAS Guard server in all OracleAS 10.1.2.0.0 Oracle homes on both production and standby sites using the following opmnctl command:

    On Windows systems:

    <ORACLE_HOME>\opmn\bin\opmnctl startall
    <ORACLE_HOME>\opmn\bin\opmnctl startproc ias-component=DSA
    
    

13.6 What to Read Next

For information on how to manage your OracleAS Disaster Recovery environment, such as setting up Oracle Data Guard and configuring the OracleAS Metadata Repository database, see the Oracle Application Server High Availability Guide.