3 Design Considerations

This chapter describes design considerations for an Oracle Fusion Middleware Disaster Recovery solution for an enterprise deployment.

It includes the following topics:

Section 3.1, "Network Considerations"
Section 3.2, "Storage Considerations"
Section 3.3, "Database Considerations"
Section 3.4, "Starting Points"
Section 3.5, "Topology Considerations"

Note:

You can automate disaster recover operations like switchover and failover, using Oracle Site Guard. For more information, see "Using Oracle Site Guard" in Oracle Enterprise Manager Life Cycle Management Guide.

This chapter describes detailed instructions for setting up an Oracle Fusion Middleware 11g Disaster Recovery production site and standby site for the Linux and UNIX operating systems. It primarily uses the Oracle SOA Suite enterprise deployment shown in Figure 3-1 in the examples of how to set up the Oracle Fusion Middleware 11g Disaster Recovery solution for an enterprise deployment. After you understand how to set up Disaster Recovery for the Oracle SOA Suite enterprise topology, you can use the information for other 11g enterprise deployments in this chapter to set up Disaster Recovery for those deployments as well.

Note:

This chapter describes an Oracle Fusion Middleware 11g Disaster Recovery symmetric topology that uses the Oracle SOA Suite enterprise deployment shown in Figure 3-1 at both the production site and the standby site. Figure 3-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.

Figure 1-1 shows a Disaster Recovery symmetric production site and standby site in a single figure.

Figure 3-1 Deployment Used at Production and Standby Sites for Oracle Fusion Middleware Disaster Recovery

Description of "Figure 3-1 Deployment Used at Production and Standby Sites for Oracle Fusion Middleware Disaster Recovery"

Figure 3-1 shows the mySOACompany with Oracle Access Manager enterprise deployment from the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite. See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for detailed information about installing and configuring this Oracle SOA Suite enterprise deployment.

The Oracle Fusion Middleware Disaster Recovery topology that you design must be symmetric for the following at the production site and the standby site.

Directory names and paths

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

Port numbers are used by listeners and for the routing of requests. Port numbers are stored in the configuration and must be the same at the production site hosts and their standby site peer hosts.

Section 3.4.1 describes how to check for port conflicts between production site and standby site hosts.
Security

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, then 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.
Software

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.

3.1 Network Considerations

This section describes the following network considerations:

Planning Host Names
Virtual IP and Virtual Host Name Considerations
Load Balancer Considerations
Virtual Server Considerations
Wide Area DNS Operations

3.1.1 Planning Host Names

In a Disaster Recovery topology, the production site host names must be resolvable to the IP addresses of the corresponding peer systems at the standby site. Therefore, it is important to plan the host names for the production site and standby site. After failover from a primary site to a standby site, the alias host name for the middle tier host on the standby site becomes active. You do not need to reconfigure the host name for the host on the standby site if you set up an alias for the standby site.

Creating aliases for physical host names is required only when using a single global DNS server to resolve host names.

This section describes how to plan physical host names and alias host names for the middle tier hosts that use the Oracle Fusion Middleware instances at the production site and standby site. It uses the Oracle SOA Suite enterprise deployment shown in Figure 3-1 for the host name examples. The host name examples in this section assume that a symmetric Disaster Recovery site is being set up, where the production site and standby site have the same number of hosts. Each host at the production site and standby site has a peer host at the other site. The peer hosts are configured the same, for example, using the same ports as their counterparts at the other site.

When configuring each component, use host-name-based configuration instead of IP-based configuration, unless the component requires you to use IP-based configuration. For example, if you are configuring the listen address of an Oracle Fusion Middleware component to a specific IP address (such as 172.16.10.255), then use the host name SOAHOST1.EXAMPLE.COM, which resolves to 172.16.10.2555.

The following subsections show how to set up host names at the Disaster Recovery production site and standby site for the following enterprise deployments:

Host Names for the Oracle SOA Suite Production Site and Standby Site Hosts
Host Names for the Oracle WebCenter Portal Production Site and Standby Site Hosts
Host Names for the Oracle Identity Management Production Site and Standby Site Hosts
Host Names for the Oracle Portal, Forms, Reports, and Discoverer Production Site and Standby Site Hosts
Host Names for the Oracle WebCenter Content Production Site and Standby Site Hosts
Host Names for the Oracle Business Intelligence Production Site and Standby Site Hosts

Note:

In the examples listed in this book, IP addresses for hosts at the initial production site have the format 172.16.x.x and IP addresses for hosts at the initial standby site have the format 172.16.x.x.

Host Names for the Oracle SOA Suite Production Site and Standby Site Hosts

Table 3-1 shows the IP addresses and physical host names that will be used for the Oracle SOA Suite Enterprise Deployment Guide (EDG) deployment production site hosts. Figure 3-1 shows the configuration for the Oracle SOA Suite EDG deployment at the production site.

Table 3-1 IP Addresses and Physical Host Names for SOA Suite Production Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`WEBHOST1`	None
`172.16.2.112`	`WEBHOST2`	None
`172.16.2.113`	`SOAHOST1`	None
`172.16.2.114`	`SOAHOST2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-2 shows the IP addresses, physical host names, and alias host names that will be used for the Oracle SOA Suite EDG deployment standby site hosts. Figure 3-2 shows the physical host names used for the Oracle SOA Suite EDG deployment at the standby site. The alias host names shown in Table 3-2 should be defined for the SOA Oracle Suite standby site hosts in Figure 3-2.

Note:

If you use separate DNS servers to resolve host names, then you can use the same physical host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-2. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-2 IP Addresses, Physical Host Names, and Alias Host Names for SOA Suite Standby Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYWEB1`	`WEBHOST1`
`172.26.2.112`	`STBYWEB2`	`WEBHOST2`
`172.26.2.113`	`STBYSOA1`	`SOAHOST1`
`172.26.2.114`	`STBYSOA2`	`SOAHOST2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Figure 3-2 Physical Host Names Used at Oracle SOA Suite Deployment Standby Site

Description of "Figure 3-2 Physical Host Names Used at Oracle SOA Suite Deployment Standby Site"

Host Names for the Oracle WebCenter Portal Production Site and Standby Site Hosts

Table 3-3 shows the IP addresses and physical host names that will be used for the Oracle WebCenter Portal EDG deployment production site hosts. Figure 4-4 shows the configuration for the Oracle WebCenter Portal EDG deployment at the production site.

Table 3-3 IP Addresses and Physical Host Names for Oracle WebCenter Portal Production Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`WEBHOST1`	None
`172.16.2.112`	`WEBHOST2`	None
`172.16.2.113`	`SOAHOST1`	None
`172.16.2.114`	`SOAHOST2`	None
`172.16.2.115`	`WCPHOST1`	None
`172.16.2.116`	`WCPHOST2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-4 shows the IP addresses, physical host names, and alias host names that will be used for the Oracle WebCenter Portal EDG deployment standby site hosts. Figure 4-4 shows the configuration for the Oracle WebCenter Portal EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same physical host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-4. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-4 IP Addresses, Physical Host Names, and Alias Host Names for Oracle WebCenter Portal Standby Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYWEB1`	`WEBHOST1`
`172.26.2.112`	`STBYWEB2`	`WEBHOST2`
`172.26.2.113`	`STBYSOA1`	`SOAHOST1`
`172.26.2.114`	`STBYSOA2`	`SOAHOST2`
`172.26.2.115`	`STBYWCP1`	`WCPHOST1`
`172.26.2.116`	`STBYWCP2`	`WCPHOST2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Host Names for the Oracle Identity Management Production Site and Standby Site Hosts

Table 3-5 shows the IP addresses and physical host names that will be used for the Oracle Identity Management EDG deployment production site hosts. Figure 4-6 shows the configuration for the Oracle Identity Management EDG deployment at the production site.

Table 3-5 IP Addresses and Physical Host Names for Identity Management Production Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`WEBHOST1`	None
`172.16.2.112`	`WEBHOST2`	None
`172.16.2.118`	`IDMHOST1`	None
`172.16.2.119`	`IDMHOST2`	None
`172.16.2.122`	`OIDHOST1`	None
`172.16.2.123`	`OIDHOST2`	None
`172.16.2.124`	`OVDHOST1`	None
`172.16.2.125`	`OVDHOST2`	None
`172.16.2.126`	`OIFHOST1`	None
`172.16.2.127`	`OIFHOST2`	None
`172.16.2.128`	`OAMHOST1`	None
`172.16.2.129`	`OAMHOST2`	None
`172.16.2.130`	`OAAMHOST1`	None
`172.16.2.131`	`OAAMHOST2`	None
`172.16.2.132`	`OIMHOST1`	None
`172.16.2.133`	`OIMHOST2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-6 shows the IP addresses, physical host names, and alias host names that will be used for the Oracle Identity Management EDG deployment standby site hosts. Figure 4-6 shows the configuration for the Oracle Identity Management EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same physical host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-6. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-6 IP Addresses, Physical Host Names, and Alias Host Names for Identity Management Standby Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYWEB1`	`WEBHOST1`
`172.26.2.112`	`STBYWEB2`	`WEBHOST2`
`172.26.2.117`	`STBYADM`	`OAMADMINHOST`
`172.26.2.118`	`STBYIDM1`	`IDMHOST1`
`172.26.2.119`	`STBYIDM2`	`IDMHOST2`
`172.26.2.122`	`STBYOID1`	`OIDHOST1`
`172.26.2.123`	`STBYOID2`	`OIDHOST2`
`172.26.2.124`	`STBYOVD1`	`OVDHOST1`
`172.26.2.125`	`STBYOVD2`	`OVDHOST2`
`172.26.2.126`	`STBYOIF1`	`OIFHOST1`
`172.26.2.127`	`STBYOIF2`	`OIFHOST2`
`172.26.2.128`	`STBYOAM1`	`OAAMHOST1`
`172.26.2.129`	`STBYOAM2`	`OAAMHOST2`
`172.26.2.130`	`STBYOAAM1`	`OAAMHOST1`
`172.26.2.131`	`STBYOAAM2`	`OAAMHOST2`
`172.26.2.132`	`STBYOIM1`	`OIMHOST1`
`172.26.2.133`	`STBYOIM2`	`OIMHOST2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

The Administration Server, the Oracle Identity Manager Managed Servers, and the SOA Managed Servers require a floating IP address to be provisioned on each site (Table 3-7). Ensure that you provision the floating IP addresses with the same virtual host names on the production site and the standby site.

Table 3-7 Floating IP Addresses

Physical Host Name	Virtual Host Name	Floating IP
`AdminServer`	`ADMINVHN`	`172.16.2.134`
`OIMHOST1`	`OIMVHN1`	`172.16.2.135`
`OIMHOST2`	`OIMVHN2`	`172.16.2.136`
`SOAHOST1`	`SOAVHN1`	`172.16.2.137`
`SOAHOST2`	`SOAVHN2`	`172.16.2.138`

Note:

For more information, see the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

Host Names for the Oracle Portal, Forms, Reports, and Discoverer Production Site and Standby Site Hosts

Table 3-8 shows the IP addresses and physical host names that will be used for the Oracle Portal, Forms, Reports, and Discoverer enterprise deployment production site hosts. Figure 4-9 shows the configuration for the Oracle Portal enterprise deployment at the production site and Figure 4-10 shows the configuration for the Oracle Forms, Reports, and Discoverer enterprise deployment at the production site.

Table 3-8 IP Addresses and Physical Host Names for Oracle Portal, Forms, Reports, and Discoverer Production Site Hosts

IP Address	Physical Host Names^Foot 1	Alias Host Names
`172.16.2.111`	`WEBHOST1`	None
`172.16.2.112`	`WEBHOST2`	None
`172.16.2.126`	`APPHOST1`	None
`172.16.2.127`	`APPHOST2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-9 shows the IP addresses, physical host names, and alias host names that will be used for the Oracle Portal, Forms, Reports, and Discoverer enterprise deployment standby site hosts. Figure 4-9 shows the configuration for the Oracle Portal enterprise deployment at the production site and Figure 4-10 shows the configuration for the Oracle Forms, Reports, and Discoverer enterprise deployment at the production site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same physical host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-9. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-9 IP Addresses, Physical Host Names, and Alias Host Names for Oracle Portal, Forms, Reports, and Discoverer Standby Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYWEB1`	`WEBHOST1`
`172.26.2.112`	`STBYWEB2`	`WEBHOST1`
`172.26.2.126`	`STBYAPP1`	`APPHOST1`
`172.26.2.127`	`STBYAPP2`	`APPHOST2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

The alias host names in Table 3-2, Table 3-4, Table 3-6, and Table 3-8 are resolved locally at the standby site to the correct IP address. Section 3.1.1.1 describes two ways to configure host name resolution in an Oracle Fusion Middleware Disaster Recovery topology.

Host Names for the Oracle WebCenter Content Production Site and Standby Site Hosts

Table 3-10 shows the IP addresses and physical host names that will be used for the Oracle WebCenter Content EDG deployment production site hosts. Figure 4-11 shows the configuration for the Oracle WebCenter Content EDG deployment at the production site.

Table 3-10 IP Addresses and Physical Host Names for Oracle WebCenter Content Production Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`WEBHOST1`	None
`172.16.2.112`	`WEBHOST2`	None
`172.16.2.113`	`WCCHOST1`	None
`172.16.2.114`	`WCCHOST2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-11 shows the IP addresses, physical host names, and alias host names that will be used for the Oracle WebCenter Content EDG deployment standby site hosts. Figure 4-11 shows the configuration for the Oracle WebCenter Content EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same physical host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-11. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-11 IP Addresses, Physical Host Names, and Alias Host Names for Oracle WebCenter Content Standby Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYWEB1`	`WEBHOST1`
`172.26.2.112`	`STBYWEB2`	`WEBHOST2`
`172.26.2.113`	`STBYWCC1`	`WCCHOST1`
`172.26.2.114`	`STBYWCC2`	`WCCHOST2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Host Names for the Oracle Business Intelligence Production Site and Standby Site Hosts

Table 3-12 shows the IP addresses and physical host names that will be used for the Oracle Business Intelligence EDG deployment production site hosts. Figure 4-13 shows the configuration for the Oracle Business Intelligence EDG deployment at the production site.

Table 3-12 IP Addresses and Physical Host Names for Oracle Business Intelligence Production Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`WEBHOST1`	None
`172.16.2.112`	`WEBHOST2`	None
`172.16.2.113`	`BIHOST1`	None
`172.16.2.114`	`BIHOST2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-13 shows the IP addresses, physical host names, and alias host names that will be used for the Oracle Business Intelligence EDG deployment standby site hosts. Figure 4-13 shows the configuration for the Oracle Business Intelligence EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same physical host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-13. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-13 IP Addresses, Physical Host Names, and Alias Host Names for Oracle Business Intelligence Standby Site Hosts

IP Address	Physical Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYWEB1`	`WEBHOST1`
`172.26.2.112`	`STBYWEB2`	`WEBHOST2`
`172.26.2.113`	`STBYBI1`	`BIHOST1`
`172.26.2.114`	`STBYBI2`	`BIHOST2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

3.1.1.1 Host Name Resolution

Host name resolution is the process of resolving a host name to the proper IP address for communication. Host name resolution can be configured in one of the following ways:

Resolving host names locally

Local host name resolution uses the host name to IP address mapping that is specified by the /etc/hosts file on each host.

See Section 3.1.1.2 for more information about using the /etc/hosts file to implement local host name file resolution.
Resolving host names using DNS

A DNS server is a dedicated server or a service that provides DNS name resolution in an IP network.

See Section 3.1.1.3 and Section 3.1.1.4 for more information about two methods of implementing DNS server host name resolution.

You must determine the method of host name resolution that you will use for your Oracle Fusion Middleware 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 Fusion Middleware hosts and the shared storage system for each site must be able to communicate with each other.

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 3-1, make the files entry the first entry for the hosts parameter if you want to resolve host names locally on the host. When files is the first entry for the hosts parameter, entries in the host /etc/hosts file are used first to resolve host names.

Example 3-1 Specifying the Use of Local Host Name Resolution

hosts:   files   dns   nis

As shown in Example 3-2, make the dns entry the first entry for the hosts parameter if you want to resolve host names using DNS on the host. When dns is the first entry for the hosts parameter, DNS server entries are used first to resolve host names.

Example 3-2 Specifying the Use of DNS Host Name Resolution

hosts:   dns    files   nis

For simplicity and consistency, Oracle recommends that all the hosts within a site (production site or standby site) should use the same host name resolution method (resolving host names locally or resolving host names using separate DNS servers or a global DNS server).

The recommendations in the following sections are high-level recommendations that you can adapt to meet the host name resolution standards used by your enterprise.

3.1.1.2 Resolving Host Names Locally

Local host name resolution uses the host name to IP mapping defined in the /etc/hosts file of a host. When you use this method to resolve host names for your Disaster Recovery topology, the following guidelines apply:

Ensure that the hosts parameter in the /etc/nsswitch.conf file on all the production site and standby site hosts looks like this:
```
hosts:   files   dns   nis
```
The /etc/hosts file entries on the hosts of the production site should have their physical host names mapped to their IP addresses. For simplicity and ease of maintenance, Oracle recommends that you provide the same entries on all the hosts of the production site. Example 3-3 shows the /etc/hosts file for the production site of a SOA enterprise deployment topology.
Example 3-3 Making /etc/hosts File Entries for a Production Site Host
```
174.0.0.1      localhost.localdomain    localhost
172.16.2.111    WEBHOST1.EXAMPLE.COM    WEBHOST1
172.16.2.112    WEBHOST2.EXAMPLE.COM    WEBHOST2
172.16.2.113    SOAHOST1.EXAMPLE.COM    SOAHOST1
172.16.2.114    SOAHOST2.EXAMPLE.COM    SOAHOST2
```
The /etc/hosts file entries on the hosts of the standby site should have their physical host names mapped to their IP addresses along with the physical host names of their corresponding peer on the production site defined as the alias host names. For simplicity and ease of maintenance, Oracle recommends that you have the same entries on all the hosts of the standby site. Example 3-4 shows the /etc/hosts file for the standby site of a SOA enterprise deployment topology.
Example 3-4 Making /etc/hosts File Entries for a Standby Site Host
```
176.0.0.1      localhost.localdomain    localhost
172.26.2.111    STBYWEB1.EXAMPLE.COM    WEBHOST1
172.26.2.112    STBYWEB2.EXAMPLE.COM    WEBHOST2
172.26.2.113    STBYSOA1.EXAMPLE.COM    SOAHOST1
172.26.2.114    STBYSOA2.EXAMPLE.COM    SOAHOST2
```
After setting up host name resolution 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 in Example 3-3, a ping webhost1 command on the production site returns the correct IP address (172.1.2.111) and indicates that the host name is fully qualified.
Similarly, for a system configured with static IP addressing and the /etc/hosts file entries shown in Example 3-4, a ping webhost1 command on the standby site returns the correct IP address (172.2.2.111) and it shows that the name WEBHOST1 is associated with that IP address.

3.1.1.3 Resolving Host Names Using Separate DNS Servers

This manual uses the term "separate D NS servers" to refer to a Disaster Recovery topology where the production site and the standby site have their own DNS servers. When you use separate DNS servers to resolve host names for your Disaster Recovery topology, the following guidelines apply:

Ensure that the hosts parameter in the /etc/nsswitch.conf file on all the production site and standby site hosts looks like this:
```
hosts:   dns   files   nis
```
The DNS servers on the production site and standby site must not be aware of each other and must contain entries for host names used within their own site.
The DNS server entries on the production site should have the physical host names mapped to their IP addresses. Example 3-5 shows the DNS server entries for the production site of a SOA enterprise deployment topology.
Example 3-5 DNS Entries for a Production Site Host in a Separate DNS Servers Configuration
```
WEBHOST1.EXAMPLE.COM    IN    A    172.16.2.111
WEBHOST2.EXAMPLE.COM    IN    A    172.16.2.112
SOAHOST1.EXAMPLE.COM    IN    A    172.16.2.113
SOAHOST2.EXAMPLE.COM    IN    A    172.16.2.114
```
The DNS server entries on the standby site should have the physical host names of the production site mapped to their IP addresses. Example 3-6 shows the DNS server entries for the standby site of a SOA enterprise deployment topology.
Example 3-6 DNS Entries for a Standby Site Host in a Separate DNS Servers Configuration
```
WEBHOST1.EXAMPLE.COM    IN    A    172.26.2.111
WEBHOST2.EXAMPLE.COM    IN    A    172.26.2.112
SOAHOST1.EXAMPLE.COM    IN    A    172.26.2.113
SOAHOST2.EXAMPLE.COM    IN    A    172.26.2.114
```
Ensure that there are no entries in the /etc/hosts file for any host at the production site or standby site.
Test the host name resolution using the ping command. For a system configured with the production site DNS entries shown in Example 3-5, a ping webhost1 command on the production site returns the correct IP address (172.1.2.111) and indicates that the host name is fully qualified.
Similarly, for a system configured with the standby site DNS entries shown in Example 3-6, a ping webhost1 command on the standby site returns the correct IP address (172.2.2.111) and indicates that the host name is fully qualified.

3.1.1.4 Resolving Host Names Using a Global DNS Server

This manual uses the term "glob al DNS server" to refer to a Disaster Recovery topology where a single DNS server is used for both the production site and the standby site. When you use a global DNS server to resolve host names for your Disaster Recovery topology, the following guidelines apply:

When using a global DNS server, for the sake of simplicity, use a combination of local host name resolution and DNS host name resolution.
In this example, it is assumed that the production site uses DNS host name resolution and the standby site uses local host name resolution.

The global DNS server should have the entries for both the production and standby site hosts. Example 3-7 shows the entries for a SOA enterprise deployment topology.

Example 3-7 DNS Entries for Production Site and Standby Site Hosts When Using a Global DNS Server Configuration

WEBHOST1.EXAMPLE.COM    IN    A    172.16.2.111
WEBHOST2.EXAMPLE.COM    IN    A    172.16.2.112
SOAHOST1.EXAMPLE.COM    IN    A    172.16.2.113
SOAHOST2.EXAMPLE.COM    IN    A    172.16.2.114
STBYWEB1.EXAMPLE.COM    IN    A    172.26.2.111
STBYWEB2.EXAMPLE.COM    IN    A    172.26.2.112
STBYSOA1.EXAMPLE.COM    IN    A    172.26.2.113
STBYSOA2.EXAMPLE.COM    IN    A    172.26.2.114

Ensure that the hosts parameter in the /etc/nsswitch.conf file on all the production site hosts looks like this:
```
hosts:   dns   files   nis
```
Ensure that the hosts parameter in the /etc/nsswitch.conf file on all the standby site hosts looks like this:
```
hosts:   files   dns   nis
```
The /etc/hosts file entries on the hosts of the standby site should have their physical host names mapped to their IP addresses along with the physical host names of their corresponding peer on the production site defined as the alias host names. For simplicity and ease of maintenance, Oracle recommends that have the same entries on all the hosts of the standby site. Example 3-8 shows the /etc/hosts file for the production site of a SOA Enterprise Deployment topology:
Example 3-8 Standby Site /etc/hosts File Entries When Using a Global DNS Server Configuration
```
176.0.0.1      localhost.localdomain    localhost
172.26.2.111    STBYWEB1.EXAMPLE.COM    WE172BHOST1
172.26.2.112    STBYWEB2.EXAMPLE.COM    WEBHOST2
172.26.2.113    STBYSOA1.EXAMPLE.COM    SOAHOST1
172.26.2.114    STBYSOA2.EXAMPLE.COM    SOAHOST2
```
Test the host name resolution using the ping command. A ping webhost1 command on the production site returns the correct IP address (172.1.2.111) and indicates that the host name is fully qualified.
Similarly, a ping webhost1 command on the standby site returns the correct IP address (172.2.2.111) and indicates that the host name is fully qualified.

3.1.1.5 Testing the Host Name Resolution

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.

3.1.2 Virtual IP and Virtual Host Name Considerations

Virtual IP addresses and host names are required to enable the Oracle WebLogic Administration Server to continue servicing requests when the machine hosting the Oracle WebLogic Administration Server fails. Virtual IP addresses enable Managed Servers in your domain to participate in server migration. Virtual servers should be provisioned in the application tier so that they can be bound to a network interface on any host in the application tier.

In a Disaster Recovery topology, the production site virtual IP host names must be resolvable to the IP addresses of the corresponding peer systems at the standby site. Therefore, it is important to plan the host names for the production site and the standby site. After failover from a primary site to a standby site, the alias host name for the middle tier host on the standby site becomes active. You do not need to reconfigure a host name for the host on the standby site if you set up aliases for the standby site.

This section describes how to plan virtual IP host names and alias host names for the middle tier hosts that use the Oracle Fusion Middleware instances at the production site and the standby site. This is required when you have a single corporate DNS.

It uses the Oracle SOA Suite enterprise deployment shown in Figure 3-1 for the host name examples. The host name examples in this section assume that a symmetric disaster recovery site is being set up, where the production site and standby site have the same number of hosts. Each host at the production site and the standby site has a peer host at the other site. The peer hosts are configured the same, for example, using the same ports as their counterparts at the other site.

The following subsections show how to set up virtual IP addresses and host names at the Disaster Recovery production site and standby site for the following enterprise deployments:

Virtual IP Addresses and Virtual Host Names for the Oracle SOA Suite Production Site and Standby Site Hosts
Virtual IP Addresses and Virtual Host Names for the Oracle WebCenter Portal Production Site and Standby Site Hosts
Virtual IP Addresses and Virtual Host Names for the Oracle Identity Management Production Site and Standby Site Hosts
Virtual IP Addresses and Virtual Host Names for the Oracle Portal, Forms, Reports, and Discoverer Production Site and Standby Site Hosts
Virtual IP Addresses and Virtual Host Names for the Oracle WebCenter Content Production Site and Standby Site Hosts
Virtual IP Addresses and Virtual Host Names for the Oracle Business Intelligence Production Site and Standby Site Hosts

Virtual IP Addresses and Virtual Host Names for the Oracle SOA Suite Production Site and Standby Site Hosts

Table 3-14 shows the virtual IP addresses and virtual host names that will be used for the Oracle SOA Suite EDG deployment production site hosts. Figure 3-1 shows the configuration for the Oracle SOA Suite EDG deployment at the production site.

Table 3-14 Virtual IP Addresses and Virtual Host Names for the SOA Suite Production Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.16.2.115`	`ADMINVHN`	None
`172.16.2.116`	`SOAVHN1`	None
`172.16.2.117`	`SOAVHN2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-15 shows the virtual IP addresses, virtual host names, and alias host names that will be used for the Oracle SOA Suite EDG deployment standby site hosts. Figure 3-2 shows the physical host names used for the Oracle SOA Suite EDG deployment at the standby site. The alias host names shown in Table 3-15 should be defined for the SOA Oracle Suite standby site hosts in Figure 3-2.

Note:

If you use separate DNS servers to resolve host names, then you can use the same virtual IP addresses and virtual host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-2. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-15 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for SOA Suite Standby Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.26.2.115`	`STBYADMINVHN`	`ADMINVHN`
`172.26.2.116`	`STBYSOAVHN1`	`SOAVHN1`
`172.26.2.117`	`STBYSOAVHN2`	`SOAVHN2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Virtual IP Addresses and Virtual Host Names for the Oracle WebCenter Portal Production Site and Standby Site Hosts

Table 3-16 shows the virtual IP addresses and virtual host names that will be used for the Oracle WebCenter Portal EDG deployment production site hosts. Figure 4-4 shows the configuration for the Oracle WebCenter Portal EDG deployment at the production site.

Table 3-16 Virtual IP Addresses and Virtual Host Names for Oracle WebCenter Portal Production Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`ADMINVHN`	None
`172.16.2.113`	`SOAVHN1`	None
`172.16.2.114`	`SOAVHN2`	None
`172.16.2.115`	`WCPVHN1`	None
`172.16.2.116`	`WCPVHN2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-17 shows the virtual IP addresses, virtual host names, and alias host names that will be used for the Oracle WebCenter Portal EDG deployment standby site hosts. Figure 4-4 shows the configuration for the Oracle WebCenter Portal EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same virtual IP addresses and virtual host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-4. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-17 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for WebCenter Portal Standby Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYADMINVHN`	`ADMINVHN`
`172.26.2.113`	`STBYSOAVHN1`	`SOAVHN1`
`172.26.2.114`	`STBYSOAVHN2`	`SOAVHN2`
`172.26.2.115`	`STBYWCPVHN1`	`WCVHN1`
`172.26.2.116`	`STBYWCPVHN2`	`WCVHN2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Virtual IP Addresses and Virtual Host Names for the Oracle Identity Management Production Site and Standby Site Hosts

Table 3-18 shows the virtual IP addresses and virtual host names that will be used for the Oracle Identity Management EDG deployment production site hosts. Figure 4-6 shows the configuration for the Oracle Identity Management EDG deployment at the production site.

Table 3-18 Virtual IP Addresses and Virtual Host Names for Identity Management Production Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`ADMINVHN`	None
`172.16.2.118`	`IDMHVHN1`	None
`172.16.2.119`	`IDMVHN2`	None
`172.16.2.122`	`OIDVHN1`	None
`172.16.2.123`	`OIDVHN2`	None
`172.16.2.124`	`OVDVHN1`	None
`172.16.2.125`	`OVDVHN2`	None
`172.16.2.126`	`OIFVHN1`	None
`172.16.2.127`	`OIFVHN2`	None
`172.16.2.128`	`OAMVHN1`	None
`172.16.2.129`	`OAMVHN2`	None
`172.16.2.130`	`OAAMVHN1`	None
`172.16.2.131`	`OAAMVHN2`	None
`172.16.2.132`	`OIMVHN1`	None
`172.16.2.133`	`OIMVHN2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-19 shows the virtual IP addresses, virtual host names, and alias host names that will be used for the Oracle Identity Management EDG deployment standby site hosts. Figure 4-6 shows the configuration for the Oracle Identity Management EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same physical host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-6. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-19 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for Identity Management Standby Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYADMINVHN`	ADMINVHN
`172.26.2.118`	`STBYIDMVHN1`	IDMVHN1
`172.26.2.119`	`STBYIDMVHN2`	IDMVHN2
`172.26.2.122`	`STBYOIDVHN1`	OIDVHN1
`172.26.2.123`	`STBYOIDVHN2`	OIDVHN2
`172.26.2.124`	`STBYOVDVHN1`	OVDVHN1
`172.26.2.125`	`STBYOVDVHN2`	OVDVHN2
`172.26.2.126`	`STBYOIFVHN1`	OIFVHN1
`172.26.2.127`	`STBYOIFVHN2`	OIFVHN2
`172.26.2.128`	`STBYOAMVHN1`	OAAMVHN1
`172.26.2.129`	`STBYOAMVHN2`	OAAMVHN2
`172.26.2.130`	`STBYOAAMVHN1`	OAAMVHN1
`172.26.2.131`	`STBYOAAMVHN2`	OAAMVHN2
`172.26.2.132`	`STBYOIMVHN1`	OIMVHN1
`172.26.2.133`	`STBYOIMVHN2`	OIMVHN2

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

The Administration Server, the Oracle Identity Manager Managed Servers, and the SOA Managed Servers require a floating IP addresses to be provisioned on each site (Table 3-7). Ensure that you provision the floating IP address with the same virtual host names on the production site and the standby site.

Table 3-20 Floating IP Addresses

Physical Host Name	Virtual Host Name	Floating IP
`AdminServer`	`ADMINVHN`	`172.16.2.134`
`OIMHOST1`	`OIMVHN1`	`172.16.2.135`
`OIMHOST2`	`OIMVHN2`	`172.16.2.136`
`SOAHOST1`	`SOAVHN1`	`172.16.2.137`
`SOAHOST2`	`SOAVHN2`	`172.16.2.138`

Note:

For more information, see the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management.

Virtual IP Addresses and Virtual Host Names for the Oracle Portal, Forms, Reports, and Discoverer Production Site and Standby Site Hosts

Table 3-21 shows the virtual IP addresses, virtual host names, and alias host names, that will be used for the Oracle Portal, Forms, Reports, and Discoverer enterprise deployment production site hosts. Figure 4-9 shows the configuration for the Oracle Portal enterprise deployment at the production site, and Figure 4-10 shows the configuration for the Oracle Forms, Reports, and Discoverer enterprise deployment at the production site.

Table 3-21 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for Oracle Portal, Forms, Reports, and Discoverer Production Site Hosts

Virtual IP Address	Virtual Host Names^Foot 1	Alias Host Names
`172.16.2.111`	`ADMINVHN`	None
`172.16.2.126`	`APPVHN1`	None
`172.16.2.127`	`APPVHN2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-22 shows the Virtual IP addresses, virtual host names, and alias host names that will be used for the Oracle Portal, Forms, Reports, and Discoverer enterprise deployment standby site hosts. Figure 4-9 shows the configuration for the Oracle Portal enterprise deployment at the production site and Figure 4-10 shows the configuration for the Oracle Forms, Reports, and Discoverer enterprise deployment at the production site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same virtual IP addresses and virtual host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-9. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-22 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for Oracle Portal, Forms, Reports, and Discoverer Standby Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYADMINVHN`	ADMINVHN
`172.26.2.126`	`STBYAPPVHN1`	APPVHN1
`172.26.2.127`	`STBYAPPVHN2`	APPVHN2

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Virtual IP Addresses and Virtual Host Names for the Oracle WebCenter Content Production Site and Standby Site Hosts

Table 3-23 shows the virtual IP addresses and virtual host names that will be used for the Oracle WebCenter Content EDG deployment production site hosts. Figure 4-11 shows the configuration for the Oracle WebCenter Content EDG deployment at the production site.

Table 3-23 Virtual IP Addresses and Virtual Host Names, and Alias Host Names for Oracle WebCenter Content Manager Production Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.16.2.111`	`ADMINVHN`	None
`172.16.2.112`	`WCCVHN1`	None
`172.16.2.114`	`WCCVHN2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-24 shows the virtual IP addresses, Virtual host names, and alias host names that will be used for the Oracle WebCenter Content EDG deployment standby site hosts. Figure 4-11 shows the configuration for the Oracle WebCenter Content EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same virtual IP addresses and virtual host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-11. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-24 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for Oracle WebCenter Content Standby Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.26.2.111`	`STBYADMINVHN`	`ADMINVHN`
`172.26.2.112`	`STBYWCCVHN1`	`WCCVHN1`
`172.26.2.113`	`STBYWCCVHN2`	`WCCVHN2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Virtual IP Addresses and Virtual Host Names for the Oracle Business Intelligence Production Site and Standby Site Hosts

Table 3-25 shows the virtual IP addresses and virtual host names that will be used for the Oracle Business Intelligence EDG deployment production site hosts. Figure 4-14 shows the configuration for the Oracle Business Intelligence EDG deployment at the production site.

Table 3-25 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for Oracle Business Intelligence Production Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.16.2.115`	`ADMINVHN`	None
`172.16.2.116`	`BIVHN1`	None
`172.16.2.117`	`BIVHN2`	None

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

Table 3-26 shows the virtual IP addresses, virtual host names, and alias host names that will be used for the Oracle Business Intelligence EDG deployment standby site hosts. Figure 4-11 shows the configuration for the Oracle Business Intelligence EDG deployment at the standby site.

Note:

If you use separate DNS servers to resolve host names, then you can use the same virtual IP addresses and virtual host names for the production site hosts and standby site hosts, and you do not need to define the alias host names on the standby site hosts that are recommended in Table 3-11. See Section 3.1.1.3 for more information about using separate DNS servers to resolve host names.

Table 3-26 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for Oracle Business Intelligence Standby Site Hosts

Virtual IP Address	Virtual Host Name^Foot 1	Alias Host Name
`172.26.2.115`	`STBYADMINVHN`	`ADMINVHN`
`172.26.2.116`	`STBYBIVHN1`	`BIVHN1`
`172.26.2.117`	`STBYBIVHN2`	`BIVHN2`

^Footnote 1See Section 3.1.1.3 and Section 3.1.1.4 for information about defining physical host names.

3.1.3 Load Bal ancer Considerations

Oracle Fusion Middleware components require a hardware load balancer when deployed in high availability topologies. Oracle recommends that the hardware load balancer have the following features:

Ability to load balance traffic to a pool of real servers through a virtual host name: Clients access services using the virtual host name (instead of using actual host names). The load balancer can then load balance requests to the servers in the pool.
Port translation configuration.
Monitoring of ports (HTTP and HTTPS).
Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer. The virtual server names and ports must meet the following requirements:
- The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle Internet Directory clusters, the load balancer must be configured with a virtual server and ports for LDAP and LDAPS traffic.
- The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the load balancer through the virtual server names.
Ability to detect node failures and immediately stop routing traffic to the failed node.
Resource monitoring, port monitoring, and process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and stop directing non-Oracle Net traffic to the failed node. If your load balancer can automatically detect failures, you should use this feature.
Fault-tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.
Other: It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client system.
Sticky routing capability: Ability to maintain sticky connections to components based on cookies or URLs.
SSL acceleration: This feature is recommended, but not required.
For the Identity Management configuration with Oracle Access Manager, configure the virtual servers in the load balancer for the directory tier with a high value for the connection timeout for TCP connections. This value should be more than the maximum expected time over which no traffic is expected between the Oracle Access Manager and the directory tier.
Ability to preserve the client IP addresses: The load balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the client IP address.

3.1.4 Virtual Server Considerations

The virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

Oracle recommends that you use two load balancers when dealing with external and internal traffic. In such a topology, one load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. Although this is supported, the deployment should consider the security implications of doing this and if appropriate, open up the relevant firewall ports to allow traffic across the various DMZs. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode.

Some of the virtual servers defined in the load balancer are used for inter-component communication. These virtual servers are used for internal traffic and are defined in the internal DNS of a company. Oracle highly recommends that you create aliases for these virtual servers when you use a single global DNS server to resolve host names.

Creating aliases is not required when using separate DNS servers to resolve host names.

The virtual servers required for the various Oracle Fusion Middleware products are described in Table 3-27 through Table 3-38.

Table 3-27 Virtual Se rvers for Oracle SOA Suite Production Site

Components	Access	Virtual Server Name	Alias Name
Oracle SOA	External	`soa.example.com`	None
Oracle SOA	Internal	`soainternal.example.com`	None
Administration Consoles	Internal	`admin.example.com`	None

Table 3-28 Virtual Se rvers for Oracle SOA Suite Standby Site

Components	Access	Virtual Server Name	Alias Virtual Server Name
Oracle SOA	External	`soa.example.com`	None
Oracle SOA	Internal	`stbysoainternal.example.com`	`soainternal.example.com`
Administration Consoles	Internal	`admin.example.com`	None

Table 3-29 Virtual Ser vers for Oracle WebCenter Portal Production Site

Components	Access	Virtual Server Name	Alias Name
Oracle WebCenter Portal	External	`wcp.example.com`	None
Oracle WebCenter Portal	Internal	`wcpinternal.example.com`	None
Oracle SOA Internal	Internal	`soainternal.example.com`^Foot 1	None
Administration Consoles	Internal	`admin.example.com`	None

^Footnote 1Required when extending with SOA domain.

Table 3-30 Virtual Se rvers for Oracle WebCenter Portal Suite Standby Site

Components	Access	Virtual Server Name	Alias Virtual Server Name
Oracle WebCenter Portal	External	`wcp.example.com`	None
Oracle WebCenter Portal	Internal	`stbywcpinternal.example.com`	`wcinternal.example.com`
Oracle SOA Internal	Internal	`soainternal.example.com`^Foot 1	`soainternal.example.com`
Administration Consoles	Internal	`admin.example.com`	None

^Footnote 1Required when extending with SOA domain.

Table 3-31 Virtual Ser vers for Oracle Identity Management Production Site

Components	Access	Virtual Server Name	Alias Name
Oracle Internet Directory	External	`oid.example.com`	None
Oracle Internet Directory	Internal	`oidinternal.example.com`	None
Oracle Virtual Directory	External	`ovd.example.com`	None
Oracle Virtual Directory	Internal	`ovdinternal.example.com`	None
Oracle Identity Federation	External	`oif.example.com`	None
Oracle Identity Federation	Internal	`oifinternal.example.com`	None
Oracle Identity Manager	External	`oim.example.com`	None
Oracle Identity Manager	Internal	`oiminternal.example.com`	None
Single Sign-On	External	`sso.example.com`	None
Single Sign-On	Internal	`ssointernal.example.com`	None
Administration Consoles	Internal	`admin.example.com`	None

Table 3-32 Virtual Ser vers for Oracle Identity Management Standby Site

Components	Access	Virtual Server Name	Alias Name
Oracle Internet Directory	External	`oid.example.com`	None
Oracle Internet Directory	Internal	`stbyoidinternal.example.com`	`oidinternal.example.com`
Oracle Virtual Directory	External	`ovd.example.com`	None
Oracle Virtual Directory	Internal	`stbyovdinternal.example.com`	`ovdinternal.example.com`
Oracle Identity Federation	External	`oif.example.com`	None
Oracle Identity Federation	Internal	`stbyoifinternal.example.com`	`oifinternal.example.com`
Oracle Identity Manager	External	`oim.example.com`	None
Oracle Identity Manager	Internal	`stbyoiminternal.example.com`	`oiminternal.example.com`
Single Sign-On	External	`sso.example.com`	None
Single Sign-On	Internal	`stbyssointernal.example.com`	`ssointernal.example.com`
Administration Consoles	Internal	`admin.example.com`	None

Table 3-33 Virtual Ser vers for Oracle Portal, Forms, Reports, and Discoverer Production Site

Components	Access	Virtual Server Name	Alias Name
Oracle Portal	External	`portal.example.com`	None
Oracle Portal	Internal	`portalinternal.example.com`	None
Oracle Forms and Oracle Reports	External	`forms.example.com`	None
Oracle Forms and Oracle Reports	Internal	`formsinternal.example.com`	None
Discoverer	External	`disco.example.com`	None
Discoverer	Internal	`discointernal.example.com`	None
Administration Consoles	Internal	a`dmin.example.com`	None

Table 3-34 Virtual Se rvers for Oracle Portal, Reports, Forms, and Discoverer Standby Site

Components	Access	Virtual Server Name	Alias Virtual Server Name
Oracle Portal	External	`portal.example.com`	None
Oracle Portal	Internal	`stbyportalinternal.example.com`	`portalinternal.example.com`
Oracle Forms and Oracle Reports	External	`forms.example.com`	None
Oracle Forms and Oracle Reports	Internal	`stbyformsinternal.example.com`	`formsinternal.example.com`
Discoverer	External	`disco.example.com`	None
Discoverer	Internal	`stbydiscointernal.example.com`	`discointernal.example.com`
Administration Consoles	Internal	`admin.example.com`	None

Table 3-35 Virtual Ser vers for Oracle WebCenter Content Production Site

Components	Access	Virtual Server Name	Alias Name
Oracle WebCenter Content	External	`wcc.example.com`	None
Oracle WebCenter Content	Internal	`wccinternal.example.com`	None
Oracle SOA Internal	Internal	`soainternal.example.com`^Foot 1	None
Administration Consoles	Internal	`admin.example.com`	None

^Footnote 1Required when extending with SOA domain.

Table 3-36 Virtual Se rvers for Oracle WebCenter Content Standby Site

Components	Access	Virtual Server Name	Alias Virtual Server Name
Oracle Enterprise Content Management	External	`ecm.example.com`	None
Oracle Enterprise Content Management	Internal	`stbyecminternal.example.com`	`ecminternal.example.com`
Oracle SOA Internal	Internal	`stbysoainternal.example.com`^Foot 1	`soainternal.example.com`
Administration Consoles	Internal	`admin.example.com`	None

^Footnote 1Required when extending with Oracle SOA domain.

Table 3-37 Virtual Ser vers for Oracle Business Intelligence Production Site

Components	Access	Virtual Server Name	Alias Name
Oracle Business Intelligence	External	`bi.example.com`	None
Oracle Business Intelligence	Internal	`biinternal.example.com`	None
Oracle Access Manager Internal	Internal	`oaminternal.example.com`^Foot 1	None
Administration Consoles	Internal	`admin.example.com`	None

^Footnote 1Required when extending with Oracle Access Manager domain.

Table 3-38 Virtual Se rvers for Oracle Business Intelligence Standby Site

Components	Access	Virtual Server Name	Alias Virtual Server Name
Oracle Business Intelligence	External	`bi.example.com`	None
Oracle Business Intelligence	Internal	`stbybiinternal.example.com`	`biinternal.example.com`
Oracle Access Manager Internal	Internal	`stbyoaminternal.example.com`^Foot 1	`oaminternal.example.com`
Administration Consoles	Internal	`admin.example.com`	None

^Footnote 1Required when extending with Oracle Access Manager domain.

3.1.5 Wide Area DNS Operations

When a site switchover or failover is performed, client requests must be redirected transparently to the new site that is playing the production role. To direct client requests to the entry point of a production site, use DNS resolution. To accomplish this redirection, the wide area DNS that resolves requests to the production site has to be switched over to the standby site. The DNS switchover can be accomplished by either using a global load balancer or manually changing DNS names.

Note:

A hardware load balancer is assumed to serve as a front end for each site. Check for supported load balancers at:

http://support.oracle.com

The following topics are described in this section:

Using a Global Load Balancer
Manually Changing DNS Names

3.1.5.1 Using a Global Load Balancer

When a global load balancer is deployed in front of the production and standby sites, it provides fault detection services and performance-based routing redirection for the two sites. Additionally, the load balancer can provide authoritative DNS name server equivalent capabilities.

During normal operations, the global load balancer can be configured with the production site's load balancer name-to-IP mapping. When a DNS switchover is required, this mapping in the global load balancer is changed to map to the standby site's load balancer IP. This allows requests to be directed to the standby site, which now has the production role.

This method of DNS switchover works for both site switchover and failover. One advantage of using a global load balancer is that the time for a new name-to-IP mapping to take effect can be almost immediate. The downside is that an additional investment must be made for the global load balancer.

3.1.5.2 Manually Changing DNS Names

This method of DNS switchover involves the manual change of the name-to-IP mapping that is originally mapped to the IP address of the production site's load balancer. The mapping is changed to map to the IP address of the standby site's load balancer. Follow these instructions to perform the switchover:

Note the current Time to Live (TTL) value of the production site's load balancer mapping. This mapping is in the DNS cache, and it will remain there until the TTL expires. As an example, assume that the TTL is 3600 seconds.
Modify the TTL value to a short interval (for example, 60 seconds).
Wait one interval of the original TTL. This is the original TTL of 3600 seconds from Step 1.
Ensure that the standby site is switched over to receive requests.
Modify the DNS mapping to resolve to the standby site's load balancer, giving it the appropriate TTL value for normal operation (for example, 3600 seconds).

This method of DNS switchover works for switchover or failover operations. The TTL value set in Step 2 should be a reasonable time period where client requests cannot be fulfilled. The modification of the TTL is effectively modifying the caching semantics of the address resolution from a long period of time to a short period. Due to the shortened caching period, an increase in DNS requests can be observed.

3.2 Storage Considerations

This section provides recommendations for designing storage for the Disaster Recovery solution for your enterprise deployment.

3.2.1 Oracle Fus ion Middleware Artifacts

The Oracle Fusion Middleware components in a given environment are usually interdependent on each other, so it is important to have the components in the topology be in sync. This is an important consideration for designing volumes and consistency groups. Some of the artifacts are static whereas others are dynamic.

Sta tic Artifacts

Static artifacts are files and directories that do not change frequently. These include:

MW_HOME: The Oracle Middleware home usually consists of an Oracle home and an Oracle WebLogic Server home.
Oracle Inventory: This includes oraInst.loc and oratab files, which are located in the /etc directory.
BEA home list: On UNIX, this is located at user_home/bea/beahomelist.

Dyna mic or Runtime Artifacts

Dynamic or runtime artifacts are files that change frequently. Runtime artifacts include:

Domain home: Domain directories of the Administration Server and the Managed Servers
Oracle instances: Oracle Instance home directories
Application artifacts, such as .ear or .war files
Database artifacts, such as the MDS repository
Database metadata repositories used by Oracle Fusion Middleware
Persistent stores, such as JMS providers and transaction logs

3.2.2 Ora cle Home and Oracle Inventory

Oracle Fusion Middleware allows creating multiple Managed Servers from one single binary installation. This allows the installation of binary files in a single location on a shared storage and the reuse of this installation by the servers in different nodes. However, for maximum availability, Oracle recommends using redundant binary installations.

When an Oracle home or a WebLogic home is shared by multiple servers in different nodes, Oracle recommends that you keep the Oracle Inventory and Middleware home list in those nodes updated for consistency in the installations and application of patches.

To update the inventory files in a node and attach an installation in a shared storage to it, use ORACLE_HOME/oui/bin/attachHome.sh.

To update the Middleware home list to add or remove a WebLogic home, edit the user_home/bea/beahomelist file. This is required for any nodes installed in addition to the ones shown in this topology.

3.2.3 Storage Replication

This section provides guidelines on creating volumes on the shared storage. Depending on the capabilities of the storage replication technology available with your preferred storage device you may need to create mount points, directories, and symbolic links on each of the nodes within a tier.

If your storage device's storage replication technology guarantees consistent replication across multiple volumes, then

Create one volume per server running on that tier. For example, on the application tier, you can create one volume for the WebLogic Administration Server and another volume for the Managed Servers.
Create one consistency group for each tier with the volumes for that tier as its members.
Note that if a volume is mounted by two systems simultaneously, a clustered file system may be required for this, depending on the storage subsystem. However, there is no known case of a single file or directory tree being concurrently accessed by Oracle processes on different systems. NFS is a clustered file system, so no additional clustered file system software is required if you are using NFS-attached storage.

If your storage device's storage replication technology does not guarantee consistent replication across multiple volumes, then

Create a volume for each tier. For example, you can create one volume for the application tier, one for the web tier, and so on.
Create a separate directory for each node in that tier. For example, you can create a directory for SOAHOST1 under the application tier volume, create a directory for WEBHOST1 under the web tier volume, and so on.
Create a mount point directory on each node to the directory on the volume.
Create a symbolic link to the mount point directory. This enables the same directory structure to be used across the nodes in a tier.
Note that if a volume is mounted by two systems simultaneously, a clustered file system may be required for this, depending on the storage subsystem. However, there is no known case of a single file or directory tree being concurrently accessed by Oracle processes on different systems. NFS is a clustered file system, so no additional clustered file system software is required if you are using NFS-attached storage.

Note:

Before you set up the shared storage for your Disaster Recovery sites, read the high availability chapter in the Oracle Fusion Middleware Release Notes to learn of any known shared storage-based deployment issues in high availability environments.

The release notes for Oracle Fusion Middleware can be found at this URL:

http://www.oracle.com/technology/documentation/middleware.html

3.2.4 File-Based Persistent Store

The WebLogic Server application servers are usually clustered for high availability. For the local site high availability of the Oracle SOA Suite topology, a file-based persistent store is used for the Java Message Service (JMS) and transaction logs (TLogs). This file-based persistent store must reside on shared storage that is accessible by all members of the cluster.

A SAN storage system should use either a host-based clustered or shared file system technology such as the Oracle Clustered File System (OCFS2). OCFS2 is a symmetric shared disk cluster file system that allows each node to read and write both metadata and data directly to the SAN.

Additional clustered file systems are not required when using NAS storage systems.

3.3 Database Considerations

This section provides the recommendations and considerations for setting up Oracle databases that will be used in the Oracle Fusion Middleware Disaster Recovery topology.

Oracle recommends creating Oracle Real Application Cluster (Oracle RAC) databases on both the production site and standby site as required by your topology.
Oracle Data Guard is the recommended disaster protection technology for the databases running the metadata repositories. You can also use Oracle Active Data Guard or Oracle GoldenGate.

Note:

You can only use Oracle GoldenGate in an active-passive configuration.

For more information, refer to the following:
- Oracle Active Data Guard at:
```
http://www.oracle.com/in/products/database/options/active-data-guard/index.html
```
- Oracle GoldenGate at:
```
http://www.oracle.com/technetwork/middleware/goldengate/overview/index.html
```
The Oracle Data Guard configuration used should be decided based on the data loss requirements of the database as well as the network considerations such as the available bandwidth and latency when compared to the redo generation. Ensure that this is determined correctly before setting up the Oracle Data Guard configuration.

See Oracle Data Guard Concepts and Administration and related Oracle Maximum Availability Architecture collateral at the following URL for more information:
```
http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm
```
Ensure that your network is configured for low latency with sufficient bandwidth, because synchronous redo transmission can affect the response time and throughput.
The LOG_ARCHIVE_DEST_n parameter on standby site databases should have the SYNC or ASYNC attributes. ASYNC is the default attribute if no attributes are specified.
The standby site database should be in Managed Recovery mode. This ensures that the standby site databases are in a constant state of media recovery. Managed Recovery mode is enabled for shorter failover times.
The tnsnames.ora file on the production site and the standby site must have entries for databases on both the production and standby sites.
Oracle strongly recommends that you force Oracle Data Guard to perform manual database synchronization whenever middle tier synchronization is performed. This is especially important for components that store configuration data in the metadata repositories.
Oracle strongly recommends that you set up aliases for the database host names on both the production and standby sites. This enables seamless switchovers, switchbacks, and failovers.
When one of the databases at either site is an Oracle RAC database, it is required that the single instance database at the peer site must have the same value for instance_name.
Note:
- The values for ORACLE_HOME, MW_HOME, ORACLE_INSTANCE, DOMAIN_HOME in the middle tier must be identical.
- The values for DB_NAME, INSTANCE_NAME, Listen Port, and ORACLE_SID in the database tier must be identical.
- To avoid manipulation of the WLS data sources, the SERVICE_NAME specified in the Application Data Source must be identical. However, each database can have additional services defined.

3.3.1 Maki ng TNSNAMES.ORA Entries for Databases

Because Oracle Data Guard is used to synchronize production and standby databases, the production database and standby database must be able to reference each other.

Oracle Data Guard uses tnsnames.ora file entries to direct requests to the production and standby databases, so entries for production and standby databases must be made to the tnsnames.ora file. See Oracle Data Guard Concepts and Administration in the Oracle Database documentation set for more information about using tnsnames.ora files with Oracle Data Guard.

3.3.2 Man ually Forcing Database Synchronization with Oracle Data Guard

For Oracle Fusion Middleware 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. Use the SQL alter system archive log all statement to switch the logs, which forces the synchronization of the production site and standby site databases.

Example 3-9 shows the SQL statement to use to force the synchronization of a production site database and standby site database.

Example 3-9 Manually Forcing an Oracle Data Guard Database Synchronization

ALTER SYSTEM ARCHIVE LOG ALL;

3.3.3 Set ting Up Database Host Name Aliases

Optionally, you can 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.

In a Disaster Recovery environment, the site that actively accepts connections is the production site. At the completion of a successful failover or switchover operation, the standby site becomes the new production site.

This section includes an example of defining an alias for database hosts named custdbhost1 and stbycustdbhost1. Table 3-39 shows the database host names and the connect strings for the databases before the alias is defined.

Table 3-39 Database Host Names and Connect Strings

Site	Database Host Name	Database Connect String
Production	`custdbhost1.example.com`	`custdbhost1.example.com:1521:orcl`
Standby	`stbycustdbhost1.example.com`	`stbycustdbhost1.example.com:1521:orcl`

In this example, all database connect strings on the production site take the form custdbhost1.example.com:1521:orcl. After a failover or switchover operation, this connect string must be changed to stbycustdbhost1.example.com:1521:orcl. However, by creating an alias of proddb1 for the database host name as shown in Table 3-40, you can avoid manually changing the connect strings, which enables seamless failovers and switchovers.

Table 3-40 Specifying an Alias for a Database Host

Site	Database Host Name	Alias	Database Connect String
Production	`custdbhost1.example.com`	`proddb1.example.com`	`proddb1.example.com:1521:orcl`
Standby	`stbycustdbhost1.example.com`	`proddb1.example.com`	`proddb1.example.com:1521:orcl`

In this example, the production site database host name and the standby site database host name are aliased to proddb1.example.com and the connect strings on the production site and the standby site can take the form proddb1.example.com:1521:orcl. On failover and switchover operations, the connect string does not need to change, thus enabling a seamless failover and switchover.

The format for specifying aliases in /etc/hosts file entries is:

IP    ALIAS_WITH_DOMAIN ALIAS    HOST_NAME_WITH_DOMAIN HOST_NAME

In this example, you create a database host name alias of proddb1 for host custdbhost1 at the production site and for host stbycustdbhost1 at the standby site. The hosts file entry should specify the fully qualified database host name alias with the ALIAS_WITH_DOMAIN parameter, the short database host name alias with the ALIAS parameter, the fully qualified host name with the HOST_NAME_WITH_DOMAIN parameter, and the short host name with the HOST_NAME parameter.

So, in the /etc/hosts files at the production site, ensure that the entry for host custdbhost1 looks like this:

152.68.196.213 proddb1.example.com proddb1 custdbhost1.example.com custdbhost1

And, in the /etc/hosts files at the standby site, ensure that the entry for host stbycustdbhost1 looks like this:

140.87.25.40   proddb1.example.com proddb1 stbycustdbhost1.example.com stbycustdbhost1

3.4 Starting Points

Before setting up the standby site, the administrator must evaluate the starting point of the project. The starting point for designing an Oracle Fusion Middleware 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 3.4.1, "Starting with an Existing Site" describes how to design the Oracle Fusion Middleware 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 3.4.2, "Starting with New Sites" describes how to design a new Oracle Fusion Middleware Disaster Recovery production site and standby 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 must be added at that site or at a standby site to set up a functioning Oracle Fusion Middleware Disaster Recovery topology.

Use the pertinent information in this chapter to design and implement an Oracle Fusion Middleware Disaster Recovery topology.

3.4.1 Starting with an Existing Site

When the administrator's starting point is an existing production site, the configuration data and the Oracle binary files for the production site already 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:

Design a symmetric standby site. See Section 3.5.1, "Design Considerations for a Symmetric Topology."
Design an asymmetric standby site. See Section 3.5.2, "Design Considerations for an Asymmetric Topology."
Migrate the production site to shared storage, if it is not already on shared storage, and then create either a symmetric standby site or an asymmetric standby site. See Section 3.4.1.1, "Migrating an Existing Production Site to Shared Storage."

3.4.1.1 Migrating an Existing Production Site to Shared Storage

The Oracle Fusion Middleware Disaster Recovery solution relies on shared storage to implement storage replication for disaster protection of the Oracle Fusion Middleware middle tier configuration. When a production site has already been created, it is likely that the Oracle home directories for the Oracle Fusion Middleware instances that comprise the site are not located on the shared storage. If this is the case, then these homes must be migrated completely to the shared storage to implement the Oracle Fusion Middleware Disaster Recovery solution.

Follow these guidelines for migrating the production site from the local disk to shared storage:

All backups performed must be offline backups. For more information, see "Types of Backups" and "Recommended Backup Strategy" in Oracle Fusion Middleware Administrator's Guide.
The backups must be performed as the root user and the permissions must be preserved. See the "Overview of the Backup Strategies" section in Oracle Fusion Middleware Administrator's Guide.
Because this is a one-time operation, so you should recover the entire domain.
The directory structure on the shared storage must be set up as described in Section 4.1.1
For Oracle SOA Suite, see "Backup and Recovery Recommendations for Oracle SOA Suite" in Oracle Fusion Middleware Administrator's Guide.
For Oracle WebCenter Portal, see "Backup and Recovery Recommendations for Oracle WebCenter Portal" in Oracle Fusion Middleware Administrator's Guide.
For Oracle Identity Management, see "Backup and Recovery Recommendations for Oracle Identity Management" in Oracle Fusion Middleware Administrator's Guide.
For Oracle WebLogic Server, see "Backup and Recovery Recommendations for Oracle JRF Installations" in Oracle Fusion Middleware Administrator's Guide.
For the Web Tier, see "Backup and Recovery Recommendations for Web Tier Installations" in Oracle Fusion Middleware Administrator's Guide.
For Oracle WebCenter Content, see "Backup and Recovery Recommendations for Oracle WebCenter Content" in Oracle Fusion Middleware Administrator's Guide.
For the Oracle Business Intelligence, see "Backup and Recovery Recommendations for Oracle Business Intelligence Installations" in Oracle Fusion Middleware Administrator's Guide.
For Oracle Portal, Oracle Forms, Oracle Reports, and Discoverer backup and recovery recommendations, see "Backup and Recovery Recommendations for Oracle Portal, Oracle Forms Services, and Oracle Reports Installations" in Oracle Fusion Middleware Administrator's Guide.

3.4.2 Starting with New Sites

This section presents the logic to implementing a new production site for an Oracle Fusion Middleware Disaster Recovery topology. It describes the planning and setup of the production site by preplanning host names, configuring the hosts to resolve the alias host names and physical host names, and ensuring that storage 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 can be a symmetric standby site or an asymmetric standby site.

When you are designing a new production site (not using a preexisting production site), you will use Oracle Universal Installer to install software on the production site, and parameters such as alias host names and software paths must be carefully designed to ensure that they are the same for both sites.

When you create a new Oracle Fusion Middleware Disaster Recovery production site and standby site, you can have the following flexibilities:

You can design your Oracle Fusion Middleware Disaster Recovery solution so that each host at the production site and at the standby site has the desired alias host name and physical host name. Host name planning was discussed in Section 3.1.1
When you design and create your own production site, you can choose the Oracle home name and Oracle home directory for each Fusion Middleware installation.

Designing and creating your own site is easier than modifying an existing site to meet the design requirements described in this chapter.
You can assign ports for the Oracle Fusion Middleware 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 checking for and resolving port conflicts between an existing production site and standby site.

3.5 Topology Considerations

This section describes design considerations for:

A symmetric topology
An asymmetric topology

3.5.1 Design Cons iderations for a Symmetric Topology

A symmetric topology is an Oracle Fusion Middleware Disaster Recovery configuration that is completely identical across tiers on the production site and standby site. In a symmetric topology, the production site and standby site have the identical number of hosts, load balancers, instances, and applications. The same ports are used for both sites. The systems are configured identically and the applications access the same data. This manual describes how to set up a symmetric Oracle Fusion Middleware Disaster Recovery topology for an enterprise configuration.

3.5.2 Design Con siderations for an Asymmetric Topology

An asymmetric topology is an Oracle Fusion Middleware Disaster Recovery configuration that is different across tiers on the production site and standby site. In an asymmetric topology, the standby site can use less hardware (for example, the production site could include four hosts with four Oracle Fusion Middleware instances while the standby site includes two hosts with four Oracle Fusion Middleware instances. Or, in a different asymmetric topology, the standby site can use fewer Oracle Fusion Middleware instances (for example, the production site could include four Oracle Fusion Middleware instances while the standby site includes two Oracle Fusion Middleware instances). Another asymmetric topology might include a different configuration for a database (for example, using an Oracle Real Application Clusters (Oracle RAC) database at the production site and a single instance database at the standby site).

3 Design Considerations

3.1 Network Considerations

3.1.1 Planning Host Names

3.1.1.1 Host Name Resolution

3.1.1.2 Resolving Host Names Locally

3.1.1.3 Resolving Host Names Using Separate DNS Servers

3.1.1.4 Resolving Host Names Using a Global DNS Server

3.1.1.5 Testing the Host Name Resolution

3.1.2 Virtual IP and Virtual Host Name Considerations

3.1.3 Load Balancer Considerations

3.1.4 Virtual Server Considerations

3.1.5 Wide Area DNS Operations

3.1.5.1 Using a Global Load Balancer

3.1.5.2 Manually Changing DNS Names

3.2 Storage Considerations

3.2.1 Oracle Fusion Middleware Artifacts

3.2.2 Oracle Home and Oracle Inventory

3.2.3 Storage Replication

3.2.4 File-Based Persistent Store

3.3 Database Considerations

3.3.1 Making TNSNAMES.ORA Entries for Databases

3.3.2 Manually Forcing Database Synchronization with Oracle Data Guard

3.3.3 Setting Up Database Host Name Aliases

3.4 Starting Points

3.4.1 Starting with an Existing Site

3.4.1.1 Migrating an Existing Production Site to Shared Storage

3.4.2 Starting with New Sites

3.5 Topology Considerations

3.5.1 Design Considerations for a Symmetric Topology

3.5.2 Design Considerations for an Asymmetric Topology

3.1.3 Load Bal ancer Considerations

3.2.1 Oracle Fus ion Middleware Artifacts

3.2.2 Ora cle Home and Oracle Inventory

3.3.1 Maki ng TNSNAMES.ORA Entries for Databases

3.3.2 Man ually Forcing Database Synchronization with Oracle Data Guard

3.3.3 Set ting Up Database Host Name Aliases

3.5.1 Design Cons iderations for a Symmetric Topology

3.5.2 Design Con siderations for an Asymmetric Topology