2 Design Considerations
Learn about the design considerations to keep in mind when you adapt an Oracle Fusion Middleware Disaster Recovery solution for your enterprise deployment.
This chapter provides instructions about how to set up an Oracle Fusion Middleware Disaster Recovery production and standby sites for the Linux and UNIX operating systems. The procedures use the Oracle SOA Suite enterprise deployment (see Figure 2-1) in the examples to illustrate how to set up the Oracle Fusion Middleware Disaster Recovery solution for that enterprise deployment. After you understand how to set up Disaster Recovery for the Oracle SOA Suite enterprise topology, use that information to set up a Disaster Recovery for your other enterprise deployments as well.
Note:
-
You can automate disaster recovery operations such as switchover and failover, by using Oracle Site Guard. For information about the product, see Introduction to Oracle Site Guard.
-
For information about installing and configuring Oracle SOA Suite components in an enterprise deployment, see Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite.
-
See Oracle Fusion Middleware Release Notes for Oracle Fusion Middleware Infrastructure for updates about errors.
Figure 2-1 shows the Oracle Fusion Middleware Disaster Recovery topology that uses the Oracle SOA Suite enterprise deployment at both the production site and the standby site. It 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.
While Figure 1-1 shows Oracle Fusion Middleware Disaster Recovery production and standby sites.
Figure 2-1 Deployment Used at Production and Standby Sites for Oracle Fusion Middleware Disaster Recovery
Figure 2-1 shows a diagram of the Oracle SOA, Business Process Management (BPM), and the Oracle Service Bus enterprise deployment topology. See the Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite for detailed information about installing and configuring an 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 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.
-
Security
The same user accounts must exist at both the production site and standby site. Also, you must configure the file system, SSL, and single sign-on 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.
This chapter includes the following topics:
- Network Considerations
When you plan your Disaster Recovery solution, consider host names, load balance, and external clients. - Storage Considerations
When you design storage for your Disaster Recovery solution, consider Fusion Middleware artifacts, and storage replication. - Database Considerations
When you plan your Disaster Recovery solution, consider synchronizing the databases in your system with Oracle Data Guard. - Starting Points
When you plan your Disaster Recovery solution, you can start with an existing site or creating a new site. - Topology Considerations
When you plan for your Disaster Recovery solution, consider designing a symmetric or an asymmetric topology.
Network Considerations
When you plan your Disaster Recovery solution, consider host names, load balance, and external clients.
This section includes the following topics:
- Planning Host Names
In a Disaster Recovery topology, the host name addresses used by the FMW components must be resolvable to the IP addresses of the appropriate system in each site. In production site, these addresses must be resolved to the IPs of the production hosts, and in standby site, these addresses must be resolved to the IPs of the standby site hosts. - Virtual IP Considerations
Starting with Oracle SOA Suite 12c, the SOA Suite products support Automatic Service Migration. As a result, it is no longer necessary to reserve Virtual IPs for each of the Managed Servers in the domain. Instead, a Virtual IP is required for the Administration Server only. - Load Balancer Considerations
In a Disaster recovery topology, both production and DR system must have a hardware load balancer, with equivalent configuration. Each load balancer will balance the traffic between the servers of its local site. - Virtual Server Considerations
You must configure the Virtual servers and the associated ports on the load balancer for different types of network traffic and monitoring. - External Clients Considerations
Systems directly accessing the servers in the topology need to be aware of the listen address that is used by the different Oracle WebLogic Server instances. - Wide Area DNS Operations
When a site switchover or failover is carried out, client requests must be redirected transparently to the new site that is playing the production role.
Parent topic: Design Considerations
Planning Host Names
In a Disaster Recovery topology, the host name addresses used by the FMW components must be resolvable to the IP addresses of the appropriate system in each site. In production site, these addresses must be resolved to the IPs of the production hosts, and in standby site, these addresses must be resolved to the IPs of the standby site hosts.
Oracle recommends creating aliases for physical host names to isolate the real physical host names (which are different in each site) from the host names used by the FMW components (which are the same regardless the 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. If you set up an alias for the standby site, you do not need to reconfigure the host name for the host on the standby site.
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 2-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 you configure each component, use host-name-based configuration instead
of IP-based configuration. For example, if you configure the listen address of an Oracle
Fusion Middleware component to a specific IP address (such as
172.11.2.113), then use the host name
SOAHOST1.EXAMPLE.COM, which resolves to
172.11.2.113.
The following section shows how to set up host names at the Disaster Recovery production and standby sites:
Note:
In the examples listed, IP addresses for hosts at the initial production
site have the format 172.11.x.x and IP addresses for
hosts at the initial standby site have the format
172.22.x.x.
- Host Names for the Oracle SOA Suite Production and Standby Site Hosts
Learn about the Oracle SOA Suite production and standby sites.
Parent topic: Network Considerations
Host Names for the Oracle SOA Suite Production and Standby Site Hosts
Learn about the Oracle SOA Suite production and standby sites.
Table 2-1 lists the IP addresses, physical host names, and aliases that are used for the Oracle SOA Suite Enterprise Deployment Guide (EDG) deployment production site hosts. Figure 2-1 shows the configuration for the Oracle SOA Suite EDG deployment at the production site.
Table 2-1 IP Addresses and Physical Host Names for SOA Suite Production Site Hosts
| IP Address | Physical Host Name | Host Name Alias |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table 2-2 lists the IP addresses, physical host names, and aliases that are used for the Oracle SOA Suite Enterprise Deployment Guide (EDG) deployment standby site hosts.
Table 2-2 IP Addresses and Physical Host Names for SOA Suite Standby Site Hosts
| IP Address | Physical Host Name | Host Name Alias |
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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. For more information about using separate DNS servers to resolve host names, see Resolving Host Names Using Separate DNS Servers.
However, it is recommended to use different hostnames and same aliases to isolate the real physical host names (which are different in each site) from the host names used by the FMW components (which are the same regardless the site).
Figure 2-2 shows the physical host names that are used for the Oracle SOA Suite EDG deployment at the standby site.
Figure 2-2 Physical Host Names Used at Oracle SOA Suite Deployment Standby Site
Starting Fusion Middleware version 12c, Automatic Service Migration is used in EDG environments as a better failover alternative to Server Migration. Contrary to Server Migration, Service Migration does not require that the managed servers use virtual IPs. Hence, only the Administration Server requires a floating IP address to be provisioned on each site. See,Table 2-3.
Ensure that you provision the floating IP addresses with the same virtual host names on the production site and the standby site.
Table 2-3 Floating IP Addresses
| Virtual IP | Virtual Name | Host Name Alias |
|---|---|---|
|
|
|
|
|
|
|
|
The following topics describe the host name resolution and testing:
- Host Name Resolution
Host name resolution means mapping a host name to the proper IP address for communication. - Resolving Host Names Locally
Local host name resolution uses the host name to IP mapping that is defined in the/etc/hostsfile of a host. - Resolving Host Names Using Separate DNS Servers
Use separate DNS servers to resolve host names for your Disaster Recovery topology. - Resolving Host Names Using a Global DNS Server
Use a global DNS server to resolve host names for your Disaster Recovery topology. - Testing the Host Name Resolution
Validate the host name assignment by connecting to each host at the production site and by using thepingcommand to ensure that the host can locate the other hosts at the production site.
Parent topic: Planning Host Names
Host Name Resolution
Host name resolution means mapping 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/hostsfile on each host.For more information about using the
/etc/hostsfile to implement local host name file resolution, see Resolving Host Names Locally . -
Resolving host names using DNS
A DNS server is a dedicated server or a service that provides DNS name resolution in an IP network.
For more information about two methods of implementing DNS server host name resolution, see Resolving Host Names Using Separate DNS Servers and Resolving Host Names Using a Global DNS Server .
You must determine the method of host name resolution that you will use for your Oracle Fusion Middleware Disaster Recovery topology when you plan 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.
If you want to resolve host names locally on the host, make the files entry the first entry for the hosts parameter, as shown in Example 2-1. When files is the first entry for the hosts parameter, entries in the host /etc/hosts file are used first to resolve host names.
If you want to resolve host names by using DNS on the host, make the dns entry the first entry for the hosts parameter, as shown in Example 2-2. When dns is the first entry for the hosts parameter, DNS server entries are used first to resolve host names.
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.
Example 2-1 Specifying the Use of Local Host Name Resolution
hosts: files dns nis
Example 2-2 Specifying the Use of DNS Host Name Resolution
hosts: dns files nis
Resolving Host Names Locally
Local host name resolution uses the host name to IP mapping that is defined in the /etc/hosts file of a host.
When you resolve host names for your Disaster Recovery topology in this way, consider the following procedure:
Example 2-3 Making /etc/hosts File Entries for a Production Site Host
127.0.0.1 localhost.localdomain localhost 172.11.2.134 prsoa-vip.example.com prsoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.11.2.111 prweb1.example.com prweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.11.2.112 prweb2.example.com prweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.11.2.113 prsoa1.example.com prsoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.11.2.114 prsoa2.example.com prsoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
Example 2-4 Making /etc/hosts File Entries for a Standby Site Host
127.0.0.1 localhost.localdomain localhost 172.22.2.134 stbysoa-vip.example.com stbysoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.22.2.111 stbyweb1.example.com stbyweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.22.2.112 stbyweb2.example.com stbyweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.22.2.113 stbysoa1.example.com stbysoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.22.2.114 stbysoa2.example.com stbysoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
Note:
The subnets in the production site and standby site are different.Resolving Host Names Using Separate DNS Servers
Use separate DNS servers to resolve host names for your Disaster Recovery topology.
The term separate DNS servers refers to a Disaster Recovery topology, where the production site and the standby site have separate and distinct DNS servers. When you use separate DNS servers to resolve host names for your Disaster Recovery topology, consider the following procedure:
Example 2-5 DNS Entries for a Production Site Host in a Separate DNS Servers Configuration
PRSOA-VIP.EXAMPLE.COM IN A 172.11.2.134 PRWEB1.EXAMPLE.COM IN A 172.11.2.111 PRWEB2.EXAMPLE.COM IN A 172.11.2.112 PRSOA1.EXAMPLE.COM IN A 172.11.2.113 PRSOA2.EXAMPLE.COM IN A 172.11.2.114 ADMINVHN.EXAMPLE.COM IN A 172.11.2.134 WEBHOST1.EXAMPLE.COM IN A 172.11.2.111 WEBHOST2.EXAMPLE.COM IN A 172.11.2.112 SOAHOST1.EXAMPLE.COM IN A 172.11.2.113 SOAHOST2.EXAMPLE.COM IN A 172.11.2.114
Example 2-6 DNS Entries for a Standby Site Host in a Separate DNS Servers Configuration
STBYSOA-VIP.EXAMPLE.COM IN A 172.22.2.134 STBYWEB1.EXAMPLE.COM IN A 172.22.2.111 STBYWEB2.EXAMPLE.COM IN A 172.22.2.112 STBYSOA1.EXAMPLE.COM IN A 172.22.2.113 STBYSOA2.EXAMPLE.COM IN A 172.22.2.114 ADMINVHN.EXAMPLE.COM IN A 172.22.2.134 WEBHOST1.EXAMPLE.COM IN A 172.22.2.111 WEBHOST2.EXAMPLE.COM IN A 172.22.2.112 SOAHOST1.EXAMPLE.COM IN A 172.22.2.113 SOAHOST2.EXAMPLE.COM IN A 172.22.2.114
Note:
If you use separate DNS servers to resolve host names, then you can use the same host names for the production site hosts and standby site hosts, and you do not need to define the alias host names.Resolving Host Names Using a Global DNS Server
Use a global DNS server to resolve host names for your Disaster Recovery topology.
The term global DNS server refers 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, consider the following procedure:
Example 2-7 DNS Entries for Production Site and Standby Site Hosts when using a Global DNS Server Configuration, when the Production Site is the primary
PRSOA-VIP.EXAMPLE.COM IN A 172.11.2.134 PRWEB1.EXAMPLE.COM IN A 172.11.2.111 PRWEB2.EXAMPLE.COM IN A 172.11.2.112 PRSOA1.EXAMPLE.COM IN A 172.11.2.113 PRSOA2.EXAMPLE.COM IN A 172.11.2.114 STBYSOA-VIP.EXAMPLE.COM IN A 172.22.2.134 STBYWEB1.EXAMPLE.COM IN A 172.22.2.111 STBYWEB2.EXAMPLE.COM IN A 172.22.2.112 STBYSOA1.EXAMPLE.COM IN A 172.22.2.113 STBYSOA2.EXAMPLE.COM IN A 172.22.2.114 ADMINVHN.EXAMPLE.COM IN A 172.11.2.134 WEBHOST1.EXAMPLE.COM IN A 172.11.2.111 WEBHOST2.EXAMPLE.COM IN A 172.11.2.112 SOAHOST1.EXAMPLE.COM IN A 172.11.2.113 SOAHOST2.EXAMPLE.COM IN A 172.11.2.114
Example 2-8 DNS Entries for Production Site and Standby Site Hosts when using a Global DNS Server Configuration, after a switchover to Standby Site
PRSOA-VIP.EXAMPLE.COM IN A 172.11.2.134 PRWEB1.EXAMPLE.COM IN A 172.11.2.111 PRWEB2.EXAMPLE.COM IN A 172.11.2.112 PRSOA1.EXAMPLE.COM IN A 172.11.2.113 PRSOA2.EXAMPLE.COM IN A 172.11.2.114 STBYSOA-VIP.EXAMPLE.COM IN A 172.22.2.134 STBYWEB1.EXAMPLE.COM IN A 172.22.2.111 STBYWEB2.EXAMPLE.COM IN A 172.22.2.112 STBYSOA1.EXAMPLE.COM IN A 172.22.2.113 STBYSOA2.EXAMPLE.COM IN A 172.22.2.114 ADMINVHN.EXAMPLE.COM IN A 172.22.2.134 WEBHOST1.EXAMPLE.COM IN A 172.22.2.111 WEBHOST2.EXAMPLE.COM IN A 172.22.2.112 SOAHOST1.EXAMPLE.COM IN A 172.22.2.113 SOAHOST2.EXAMPLE.COM IN A 172.22.2.114
Example 2-9 Production Site /etc/hosts File Entries when using a Global DNS Server Configuration
127.0.0.1 localhost.localdomain localhost 172.11.2.134 prsoa-vip.example.com prsoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.11.2.111 prweb1.example.com prweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.11.2.112 prweb2.example.com prweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.11.2.113 prsoa1.example.com prsoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.11.2.114 prsoa2.example.com prsoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
Example 2-10 Standby Site /etc/hosts File Entries when using a Global DNS Server Configuration
127.0.0.1 localhost.localdomain localhost 172.22.2.134 stbysoa-vip.example.com stbysoa-vip ADMINVHN.EXAMPLE.COM ADMINVHN 172.22.2.111 stbyweb1.example.com stbyweb1 WEBHOST1.EXAMPLE.COM WEBHOST1 172.22.2.112 stbyweb2.example.com stbyweb2 WEBHOST2.EXAMPLE.COM WEBHOST2 172.22.2.113 stbysoa1.example.com stbysoa1 SOAHOST1.EXAMPLE.COM SOAHOST1 172.22.2.114 stbysoa2.example.com stbysoa2 SOAHOST2.EXAMPLE.COM SOAHOST2
Testing the Host Name Resolution
Validate the host name assignment by connecting to each host at the production site and by using the ping command to ensure that the host can locate the other hosts at the production site.
In addition, 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.
Virtual IP Considerations
Starting with Oracle SOA Suite 12c, the SOA Suite products support Automatic Service Migration. As a result, it is no longer necessary to reserve Virtual IPs for each of the Managed Servers in the domain. Instead, a Virtual IP is required for the Administration Server only.
In a Disaster Recovery topology, as explained in the previous section, the production site virtual IP host names aliases 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 2-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, by using the same ports as their counterparts at the other site.
Table 2-4 shows the virtual IP addresses and virtual host names that are used for the Oracle SOA Suite EDG deployment production site hosts. Figure 2-1 shows the configuration for the Oracle SOA Suite EDG deployment at the production site.
Table 2-4 Virtual IP Addresses and Virtual Host Names for the SOA Suite Production Site Hosts
| Virtual IP Address | Virtual Host Name | Alias Host Name |
|---|---|---|
|
|
|
|
Table 2-5 shows the virtual IP addresses, virtual host names, and alias host names that are used for the Oracle SOA Suite EDG deployment standby site hosts. Figure 2-2 shows the physical host names that are used for the Oracle SOA Suite EDG deployment at the standby site. The alias host names shown in Table 2-5 should be defined for the SOA Oracle Suite standby site hosts, as shown in Figure 2-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.
For more information about using separate DNS servers to resolve host names, see Resolving Host Names Using Separate DNS Servers .
Table 2-5 Virtual IP Addresses, Virtual Host Names, and Alias Host Names for SOA Suite Standby Site Hosts
| Virtual IP Address | Virtual Host Name | Host Name Alias |
|---|---|---|
|
|
|
|
Parent topic: Network Considerations
Load Balancer Considerations
In a Disaster recovery topology, both production and DR system must have a hardware load balancer, with equivalent configuration. Each load balancer will balance the traffic between the servers of its local site.
Both primary and DR load balancer must support the wanted features of the external load balancer. For more information, see Hardware Load Balancer Requirements in Enterprise Deployment Guide for Oracle SOA Suite guide.
The virtual front-end name used by the production and DR load balancer must be the same. That virtual front-end name must be resolved in DNS with the IP of the load balancer of the site that has primary role in each moment.
Parent topic: Network Considerations
Virtual Server Considerations
You must configure the Virtual servers and the associated ports on the load balancer for different types of network traffic and monitoring.
Configure them 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 you deal 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. When you use a single global DNS server to resolve host names, Oracle highly recommends you to create aliases for these virtual servers. Creating aliases is not required when you use separate DNS servers to resolve host names.
The virtual servers required for the various Oracle Fusion Middleware products are described in Table 2-6 and Table 2-7.
Table 2-6 Virtual Servers for Oracle SOA Suite Production Site
| Components | Access | Virtual Server Name | Alias Name |
|---|---|---|---|
|
Oracle SOA |
External |
|
None |
|
Oracle SOA |
Internal |
|
None |
|
Administration Consoles |
Internal |
|
None |
Table 2-7 Virtual Servers for Oracle SOA Suite Standby Site
| Components | Access | Virtual Server Name | Alias Virtual Server Name |
|---|---|---|---|
|
Oracle SOA |
External |
|
None |
|
Oracle SOA |
Internal |
|
|
|
Administration Consoles |
Internal |
|
None |
Parent topic: Network Considerations
External Clients Considerations
Systems directly accessing the servers in the topology need to be aware of the listen address that is used by the different Oracle WebLogic Server instances.
An appropriate host name resolution needs to be provided to the clients so that the
host name alias used by the servers as listen address is correctly resolved. This is
also applicable to the Oracle JDeveloper deployments. The client hosting Oracle
Jdeveloper needs to map the SOAHOSTx and ADMINVHN
aliases to correct the IP addresses for deployments to succeed.
Parent topic: Network Considerations
Wide Area DNS Operations
When a site switchover or failover is carried out, 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:
This section includes the following topics:
- Using a Global Load Balancer
A global load balancer deployed in front of the production and standby sites provides fault detection services and performance-based routing redirection for the two sites. - Manually Changing DNS Names
The DNS switch-over involves to manually change the name-to-IP mapping of the production site's load balancer.
Parent topic: Network Considerations
Using a Global Load Balancer
A global load balancer deployed in front of the production and standby sites provides fault detection services and performance-based routing redirection for the two sites.
In addition, the load balancer can provide authoritative DNS name server equivalent capabilities.
During normal operations, you can configure the global load balancer 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.
Parent topic: Wide Area DNS Operations
Manually Changing DNS Names
The DNS switch-over involves to manually change the name-to-IP mapping 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 remains 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 the standby site's load balancer. It gives 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 effectively modifies 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.
networkaddress.cache.ttl to a low value:
-
You can do it globally, for all the applications that are running on the JVM, by modifying the property in
JAVA_HOME/jre/lib/security/java.security file: networkaddress.cache.ttl=60 -
You can define it for a specific application only, by setting that property in the application's initialization code:
java.security.Security.setProperty("networkaddress.cache.ttl" , "60")
Parent topic: Wide Area DNS Operations
Storage Considerations
When you design storage for your Disaster Recovery solution, consider Fusion Middleware artifacts, and storage replication.
This section includes the following topics:
- Oracle Fusion Middleware Artifacts
Oracle Fusion Middleware components in a given environment are usually interdependent on one another, so it is important that the components in the topology be synchronized. - Oracle Home and Oracle Inventory
Oracle Fusion Middleware allows you to create multiple Oracle WebLogic Server Managed Servers from one single binary file installation. - Setting Up Storage
Learn about the guidelines to create volumes on a shared storage.
Parent topic: Design Considerations
Oracle Fusion Middleware Artifacts
Oracle Fusion Middleware components in a given environment are usually interdependent on one another, so it is important that the components in the topology be synchronized.
This synchronization is important when you design volumes and consistency groups. Some artifacts are static whereas others are dynamic.
Static Artifacts
Static artifacts are files and directories that do not change frequently. These include:
-
home: The Oracle home usually consists of an Oracle home and an Oracle WebLogic Server home.
-
Oracle Inventory: This includes
oraInst.locandoratabfiles, which are located in the/etcdirectory.
Dynamic 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
.earor.warfiles. -
Database artifacts, such as the MDS repository and the JDBC persistent stores.
-
Deployment plans: Used for updating technology adapters, such as file and JMS adapters. They need to be saved in a location that is accessible to all nodes in the cluster that the artifacts are being deployed to.
Parent topic: Storage Considerations
Oracle Home and Oracle Inventory
Oracle Fusion Middleware allows you to create multiple Oracle WebLogic Server Managed Servers from one single binary file installation.
You can install binary files in a single location on a shared storage and reuse this installation by servers in different nodes. Note that, for maximum availability, Oracle recommends that you use 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 Oracle home list in those nodes that are 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 the ORACLE_HOME/oui/bin/attachHome.sh file.
Parent topic: Storage Considerations
Setting Up Storage
Learn about the guidelines to create volumes on a 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 complete the following:
-
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.
-
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 complete the following:
-
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.
-
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.
Parent topic: Storage Considerations
Database Considerations
When you plan your Disaster Recovery solution, consider synchronizing the databases in your system with Oracle Data Guard.
This section provides the recommendations and considerations to set up Oracle databases that are used in an Oracle Fusion Middleware Disaster Recovery topology.
-
Oracle recommends that you create 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 if the precise Oracle Fusion Middleware component supports it.
Note:
You can use Oracle GoldenGate in an active-passive configuration only.
-
The Oracle Data Guard configuration that is 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 you set up the Oracle Data Guard configuration.
-
Ensure that your network is configured for low latency with sufficient bandwidth, because synchronous redo transmission can affect the response time and throughput.
-
Oracle Data Guard provides three protection modes: Maximum Availability, Maximum Performance (default), and Maximum Protection. Oracle recommends to use the protection mode that better meets your availability, performance, and data protection requirements. For more information, see Oracle Data Guard Protection Modes.
-
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.orafile on the production site and the standby site must have entries for databases on both the production and standby sites. -
Oracle recommends to use ASM as the volume manager for Oracle database files. ASM is Oracle's recommended storage management solution that provides an alternative to conventional volume managers, file systems, and raw device, and supports single-instance Oracle Database and Oracle Real Application Clusters (Oracle RAC) configurations.
For additional information about RAC and ASM, see Oracle Automatic Storage Management Administrator's Guide and Real Application Clusters Installation Guide for Linux and UNIX.
-
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,home,ORACLE_INSTANCE,DOMAIN_HOMEin the middle tier must be identical. -
The values for
DB_NAME,INSTANCE_NAME,Listen Port, andORACLE_SIDin the database tier must be identical. -
To avoid manipulation of the WLS data sources, the
SERVICE_NAMEspecified in the Application Data Source must be identical. However, each database can have additional services defined.
-
The following section explains database points:
- Setting Up DataSources in the Middle Tier
In a Disaster Recovery topology, the following approaches can be used in the database connection string of the WebLogic datasources:
Parent topic: Design Considerations
Setting Up DataSources in the Middle Tier
In a Disaster Recovery topology, the following approaches can be used in the database connection string of the WebLogic datasources:
-
Use a dataguard ready (also known as "dual") jdbc string. In this case, the db connect string includes both primary's and standby's database connect addresses, but only the database that has the primary role provides the service.
Note:
Provided the service name is active when the role is primary.Example:
jdbc:oracle:thin:@ (DESCRIPTION= (CONNECT_TIMEOUT=15) (RETRY_COUNT=5) (RETRY_DELAY=5) (ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))) (ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)) )Advantages:
-
Since the same connect string is used in the primary and standby datasources, you need not perform modifications in the standby configuration after copying the WebLogic domain configuration from primary.
Disadvantages:
-
Delays in secondary: The first address provided in the dual string is always tried first. When secondary system becomes primary, jdbc will first try to connect to the address that is listed in the first position. Depending how the connection is rejected (either immediately because the remote scan is not resolved, or with a delay because the remote scan name is resolved but connections are rejected by a firewall, for example), there can be delays in db connection establishment in secondary.
-
Risk of cross connections: By default, the connections will go to the database with primary because the service will be active there. But if the standby is opened in snapshot mode and service is also active there, there would be a risk of getting connections from midtier in primary role to standby snapshot database.
This connect string is useful in the stretched cluster models. For example, as described in SOA in Best Practices for Oracle Fusion Middleware SOA 12c Multi Data Center Active-Active Deployment, where it is expected that the same SOA nodes can connect to the primary or to the secondary database, but it is not the best approach for an active-passive DR model where the cross-connection to the remote database are not expected nor recommended.
-
-
Another approach is to use a non-dual jdbc string, different in each site, pointing to the local database only. This approach is used for example in the SOAMP DR whitepaper.
Example:
Connect string in datasources in primary site:
jdbc:oracle:thin:@ (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=prmy-service)) )Connect string in datasources in secondary site:
jdbc:oracle:thin:@ (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=stby-service)) )Note:
Oracle recommends to enter the string in a single line (single line not used in these examples just for readability purpose).Advantages:
-
Given that each site points to the local database only, there is no risk of cross-connections from the mid-tier to the remote database.
Disadvantages:
-
The db connection string used in the datasources is different in each site, so a replacement is required everytime that the WebLogic domain configuration is copied from primary to standby.
-
-
Another approach, which is the recommended in this guide, is to use a TNS alias in the datasources, as explained in Using a TNS Alias instead of a DB Connect String of the WebLogic documentation. The TNS alias is the same name in primary and secondary, hence the datasources has the same db connect string. The TNS alias is resolved with a tnsnames.ora file that is stored separately from the WebLogic domain configuration, and not replicated between sites, so you can have a different tnsnames.ora content in each site. Each site will resolve the TNS alias with the appropriate connect string in each site, pointing to the local database only.
Example:
Connect string in datasources in primary site:
jdbc:oracle:thin:@soaedgwhere,
tnsnames.orafile in primary contains:SOAEDG = (DESCRIPTION= (ADDRESS_LIST= (LOAD_BALANCE=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)) )Connect string in datasources in secondary site:jdbc:oracle:thin:@soaedgwhere,
tnsnames.orafile in secondary contains:SOAEDG = (DESCRIPTION= (ADDRESS_LIST= (LOAD_BALANCE=ON) (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521))) (CONNECT_DATA=(SERVICE_NAME=soaedg.example.com)) )Advantages:
-
Since the same db connect string is used in the WebLogic domain config, no need to alter the WebLogic configuration after replicating the config from primary to standby.
-
As each site points to the local database only, there is no risk of cross-connections from the mid-tier to the remote database.
Disadvantages:
-
There are no disadvantages of using this method. It only requires a one-time setup step in order to configure the
tnsnames.orain each site and make the WebLogic to use it.
Note:
Using TNS alias in GridLink datasources is supported starting Oracle Fusion Middleware version 12.2.1.3 -
The TNS alias approach is used in this guide, because it provides the same advantages than the others, without any relevant disadvantage. For detailed information to configure the data sources, see Configuring Data Sources for Oracle Fusion Middleware Active-Passive Deployment.
Parent topic: Database Considerations
Starting Points
When you plan your Disaster Recovery solution, you can start with an existing site or creating a new site.
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.
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.
Starting with a New Site 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.
This section includes the following topics:
- Starting with an Existing Site
When you start with an existing production site, the configuration data and the Oracle binary files for the production site are already on the file system. In addition, the host names, ports, and user accounts are already defined. - Starting with a New Site
When you start with a new production site for an Oracle Fusion Middleware Disaster Recovery topology, consider host names and ensure that storage replication is set up to copy the configuration (based on these names) to the standby site.
Parent topic: Design Considerations
Starting with an Existing Site
When you start with an existing production site, the configuration data and the Oracle binary files for the production site are already on the file system. In addition, the host names, ports, and user accounts are already defined.
When you start with an existing production site, first migrate the production site to shared storage (if not already in a shared storage), and then create a symmetric standby as described in Design Considerations for a Symmetric Topology
To migrate a production site, see the following sections:
- Migrating an Existing Production Site to Shared Storage
- Preserving the Production Hosts Hostnames as Listener Address
Parent topic: Starting Points
Migrating an Existing Production Site to Shared Storage
When you use storage replication for Oracle Fusion Middleware Disaster Recovery, the Oracle Home and middle tier configuration have to reside on the shared storage. If the production site was initially created without Disaster Recovery, the directories for the Oracle Fusion Middleware instances that comprise the site might be located on the local storage. In this scenario, the 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:
-
Perform offline backup of the folder that is going to be moved to the shared storage. If the backup is performed using OS commands, it must be done as the root user and the permissions must be preserved.
See Types of Backups and Recommended Backup Strategy in Oracle Fusion Middleware Administering Oracle Fusion Middleware
-
Although you move the content to NFS, the path will be preserved. So the current folder that is going to be moved to an NFS (for example,
/u01/oracle/products) will become a mount point. In preparation for this, move or rename the current folder to another path so the mount point is empty. -
Ensure that the mount point where the shared storage will be mounted exists, is empty, and has the correct ownership.
-
Mount the shared storage in the appropriate mount point. The directory structure on the shared storage must be set up as described in Designing Directory Structure and Volumes. The directory structure on the shared storage must be set up as described in .
-
Once the shared storage is mounted, copy the content from the backup (or from the renamed folder) to the folder, that is now in shared storage.
Example: Moving a products folder, that is in /u01/oracle/products, from
local disk to an NFS folder.
-
To backup the content the content in the local folder, a copy is performed by user root, preserving the mode:
[root@soahost1]# cp -a /u01/oracle/products /backups/products_backup -
The current folder is moved, because the folder that will become the mount point should be empty:
[root@soahost1]# mv /u01/oracle/products /u01/oracle/products_local -
After renaming, it is checked that the mount folder point exists (created if not), verified that it is empty, and that it has the correct ownership. The mount point is
/u01/oracle/productsin this example:[root@soahost1]# mkdir -p /u01/oracle/products [root@soahost1]# ls /u01/oracle/products [root@soahost1]# chown oracle:oinstall /u01/oracle/products -
The NFS volume is mounted in the mount point.
[root@soahost1]# mount -t nfs nasfiler:VOL1/oracle/products/ /u01/oracle/products/ -
To make this persistent, the mount is added to the mount to the
/etc/fstabas described in Mounting the Required Shared File Systems on Each Host. -
Then, the content from the backup is copied to the mount:
[root@soahost1]# cp -a /backups/products_backup /u01/oracle/products
Parent topic: Starting with an Existing Site
Preserving the Production Hosts Hostnames as Listener Address
When a primary site is created without Disaster Protection in mind, it is possible that the FMW components are not using host name aliases as listener addresses and instead use the real physical host names of the nodes where they reside. If this is the case, you have two options:
-
Modify the WebLogic domain configuration in the existing site in order to use host aliases as listener addresses for the servers, as explained in the Planning Host Names. This change has additional implications as all client points accessing the servers need to be made aware of the new hostname.
-
Or, if modifying the production configuration is not feasible, preserve the configuration as it is in and continue using the physical host names as listener addresses for the FMW components and adjust secondary to use also these hostnames. This is the recommended approach. In this case, the primary physical host names must be added as aliases to the
/etc/hostsof the standby site hosts.Example:
/etc/hostsentries in production site hosts that do not use aliases for the components127.0.0.1 localhost.localdomain localhost 172.11.2.134 prsoa-vip.example.com prsoa-vip 172.11.2.111 prweb1.example.com prweb1 172.11.2.112 prweb2.example.com prweb2 172.11.2.113 prsoa1.example.com prsoa1 172.11.2.114 prsoa2.example.com prsoa2/etc/hostsentries in standby site hosts127.0.0.1 localhost.localdomain localhost 172.22.2.134 stbysoa-vip.example.com stbysoa-vip prsoa-vip.example.com prsoa-vip 172.22.2.111 stbyweb1.example.com stbyweb1 prweb1.example.com prweb1 172.22.2.112 stbyweb2.example.com stbyweb2 prweb2.example.com prweb2 172.22.2.113 stbysoa1.example.com stbysoa1 prsoa1.example.com prsoa1 172.22.2.114 stbysoa2.example.com stbysoa2 prsoa2.example.com prsoa2
Parent topic: Starting with an Existing Site
Starting with a New Site
When you start with a new production site for an Oracle Fusion Middleware Disaster Recovery topology, consider host names and ensure that storage replication is set up to copy the configuration (based on these names) to the standby site.
When you design a new production site, plan also the standby site, and use Oracle Universal Installer to install software on the production site. Parameters such as alias host names and software paths must be carefully designed to ensure that they are the same on both sites.
When you create a new Oracle Fusion Middleware Disaster Recovery production and standby sites, consider the following choices:
-
Design your Oracle Fusion Middleware Disaster Recovery solution so that each host at the production site and the standby site has the desired alias host name and physical host name. For more information about host name planning, see Planning Host Names.
-
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.
-
Assign ports for the Oracle Fusion Middleware installations for the production site hosts. You can also use the same ports for the standby site hosts. The same ports must be used for both sites.
This setup is easier than checking for and resolving port conflicts between an existing production and standby sites.
Parent topic: Starting Points
Topology Considerations
When you plan for your Disaster Recovery solution, consider designing a symmetric or an asymmetric topology.
This section includes the following topics:
- Design Considerations for a Symmetric Topology
A symmetric topology is an Oracle Fusion Middleware Disaster Recovery configuration that is identical across tiers on the production and standby sites. - Design Considerations for an Asymmetric Topology
An asymmetric topology is an Oracle Fusion Middleware Disaster Recovery configuration that differs across some tiers on the production and standby sites.
Parent topic: Design Considerations
Design Considerations for a Symmetric Topology
A symmetric topology is an Oracle Fusion Middleware Disaster Recovery configuration that is identical across tiers on the production and standby sites.
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.
Parent topic: Topology Considerations
Design Considerations for an Asymmetric Topology
An asymmetric topology is an Oracle Fusion Middleware Disaster Recovery configuration that differs across some tiers on the production and standby sites.
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).
For example, consider an asymmetric topology where the standby site uses fewer Oracle Fusion Middleware instances (for example, the production site could include four Oracle Fusion Middleware instances while the standby site includes just two Oracle Fusion Middleware instances).
Another asymmetric topology includes 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.
Note:
Oracle recommends configuring symmetrical topology and capacity at both production and standby sites. Having different number of nodes or capacity can cause inconsistencies at the functional and performance levels. For example, if production has three nodes, and standby has two nodes, the soa-infra application may not start in standby if there is an unknown node (the additional production node does not have any equivalent node in standby site).
As a summary, having asymmetric topology is risky and generically not recommended, only applicable to special cases at customer's own risk and knowledge.Parent topic: Topology Considerations