2 High Availability Concepts

This section describes high availability concepts and includes the following topics:

2.1 Oracle Fusion Middleware Concepts

For information on Oracle Fusion Middleware concepts, see the following topics in Oracle Fusion Middleware Understanding Oracle Fusion Middleware Concepts.

Table 2-1 Oracle Fusion Middleware Concepts

For information on... See this topic...

Oracle Home, Oracle Common, WebLogic Server Domain

"What are the Key Oracle Fusion Middleware Directories?"

WebLogic Server Domain

"What is an Oracle WebLogic Server Domain?"

Administration Server

"What is the Administration Server?"

Managed Servers and Managed Server Clusters

"Understanding Managed Servers and Managed Server Clusters"

Node Manager

"What is Node Manager?"

See Also:

"Communications in a Cluster" in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server

2.2 Server Load Balancing in a High Availability Environment

This section includes the following topics:

2.2.1 About Load Balancing

Load balancing is the even distribution of jobs and associated communications across computing and networking resources in your environment.

Typically, a load balancer front ends high availability deployments. You use Oracle HTTP Server or Oracle Traffic Director to configure load balancing between different components or applications. See Section 2.2.4, "Server Load Balancing with Oracle HTTP Server or Oracle Traffic Director."

You can also combine of a load balancer and Oracle HTTP Server (as Figure 1-1 shows) to provide maximum availability.

2.2.2 Third-Party Load Balancer Requirements

You can use third-party load balancers in your Oracle Fusion Middleware high availability deployments. Oracle recommends load balancers that support 'sticky' session routing. Sticky session routing is the ability, for the entire session, to route traffic to the same server that processes the first request.

Your external load balancer must 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 actual host names. The load balancer can then load balance requests to servers in the pool. Typically, the load balancer can balance across Oracle HTTP Server instances and then the Oracle HTTP Servers can balance across application servers.

  • Port translation configuration.

  • Monitoring of ports (HTTP and HTTPS).

  • Ability to configure virtual server names and ports on the load balancer.

  • 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 clusters, you must configure the load balancer with a virtual server and ports for HTTP and HTTPS traffic.

  • Virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through virtual server names.

  • Resource monitoring/port monitoring/process failure detection: the load balancer must be able to detect service and node failures and to stop directing non-Oracle Net traffic to a failed node. If your external load balancer can automatically detect failures, Oracle recommends that you use it.

  • Fault tolerant mode: Oracle recommends that you configure the load balancer to be in fault-tolerant mode.

  • Virtual server returning to calling client: Oracle highly recommends that you configure the load balancer virtual server to return immediately to the calling client when back-end services that it forwards traffic to are unavailable. This is preferred over a client disconnecting on its own after a timeout based on TCP/IP settings on a client machine.

  • SSL acceleration. Oracle recommends this feature but does not require it.

  • Client IP Address (Preserving): the load balancer must be able to insert a request's original client IP address in an X-Forwarded-For HTTP header to preserve it.

2.2.3 Configuring Third-Party Load Balancers

Detailed load balancer configuration steps depend on:

  • The environment you are using the load balancer in.

  • The type of load balancer you are using.

For these reasons, Oracle recommends that you follow your load balancer's documentation. For high-level load balancer configuration steps, see the enterprise deployment guide for the component you are working with.

2.2.4 Server Load Balancing with Oracle HTTP Server or Oracle Traffic Director

This section describes Oracle load balancing products.

Table 2-2 Server Load Balancing Products

Product Description

Oracle HTTP Server (OHS)

Web server with a built-in WebLogic Server Proxy Plug-In module to act as HTTP front-end for one or more WebLogic servers. Receives incoming requests from clients and load balances each request to one or more WebLogic Servers. The OHS mod_wl_ohs module routes requests to one or more WebLogic servers. Has the same load balancing functionality as mod_weblogic (Oracle WebLogic Server Plug-in for Apache HTTP Server). See "Configuring the mod_wl_ohs Plug-In for Oracle HTTP Server" in Oracle Fusion Middleware Using Web Server 1.1 Plug-Ins with Oracle WebLogic Server for more information. See Section, "Configuring mod_wl_ohs.conf" for more on the mod_wl_ohs module.

Oracle Traffic Director

Highly available Application Delivery Controller with WebLogic inter-operability enhancements. Efficiently throttles requests to one or more clusters. A fast, reliable, and scalable layer-7 software load balancer. Reliable entry point for all HTTP, HTTPS and TCP traffic. Distributes client requests based on specified load-balancing method, routes requests based on specified rules, caches frequently accessed data, prioritizes traffic, and controls service quality. See Oracle Traffic Director Administrator's Guide for more information.

2.3 Application Failover

This section describes different types of failover and behavior. Topics include the following:

2.3.1 About Failover, Application Failover, and State

Failover is relocating an overloaded or failed resource such as a server, disk drive, or network to its backup location.

Application failover is when an application component doing a certain job becomes unavailable and a copy of the failed component finishes the job.

State is information about what has been done on a job. WebLogic Server maintains state information using session replication and replica-aware stubs. If a component unexpectedly stops doing its job, replication techniques enable a copy of the component to pick up where the failed component stopped and finish the job.

2.3.2 Session Failover Requirements


Oracle applications meet these session failover requirements unless a specific exception is made for an application.

For seamless failover, an application must meet the following conditions:

  • The application is in a cluster and at least one member of the application cluster is available to serve the request.

  • For stateful applications, state replication is configured correctly.

  • If you use Oracle HTTP Server, the server is configured with the WebLogic Cluster directive to balance among all available application instances.

  • If you are using a hardware load balancer, the load balancer is:

    • Routing traffic to all available instances

    • Configured correctly with a health monitor to mark unavailable instances

    • Configured to support persistence of session state

2.3.3 Application Failover Expected Behavior

If you configure the environment correctly, users don't notice when an application instance in a cluster becomes unavailable. The application failover sequence of events is, for example:

  1. A user makes a request and a hardware load balancer routes it to Instance A of the application.

  2. Instance A of the application becomes unavailable due to node failure, process failure, or network failure.

  3. The hardware load balancer marks Instance A as unavailable.

  4. The user makes a subsequent request. The request is routed to Instance B.

  5. Instance B is configured as a replication partner of Instance A and has the user's session state.

  6. The application resumes using the session state on Instance B and the user continues working without interruption.

See Also:

See Domain Template Reference for domain and extension templates that support high availability.

See Failover and Replication in a Cluster in Administering Clusters for Oracle WebLogic Server for more on failover and replication at the application level.

2.4 Real Application Clusters

Oracle Real Application Clusters (RAC) enable you to cluster an Oracle database. A cluster comprises multiple interconnected computers or servers that appear as if they are one server to end users and applications. Oracle RAC uses Oracle Clusterware for the infrastructure to bind multiple servers so they operate as one system. Along with a collection of hardware (cluster), Oracle RAC unites the processing power of each component to become a single, robust computing environment. Oracle RAC provides a highly scalable and highly available database for Oracle Fusion Middleware.

Every Oracle RAC instance in a cluster has equal access and authority. Node and instance failure may affect performance but do not result in downtime because the database service is available or can be made available on surviving server instances.

See Also:

For more information on Oracle RAC see:

2.5 Coherence Clusters and High Availability

If you follow Oracle Fusion Middleware Installing and Configuring Oracle WebLogic Server and Coherence or a product installation guide, the standard installation topology includes a standard Coherence cluster that is a starting point for additional configuration.

A Coherence cluster is a collection of Java Virtual Machine (JVM) processes running Coherence. In 12c, these processes are called WebLogic Managed Coherence Servers. JVMs that join a cluster are cluster members or cluster nodes. Cluster members can be:

  • Dedicated storage members

  • Client members that have storage disabled

  • Proxy members that allow non-cluster members to access Coherence caches

Cluster members communicate using Tangosol Cluster Management Protocol (TCMP). Cluster members use TCMP for both multicast communication (broadcast) and unicast communication (point-to-point communication).

Coherence characteristics include the following:

  • Each domain typically contains one Coherence Cluster.

  • Each managed Coherence server in a domain is associated with a Coherence cluster, defined through a Coherence Cluster System Resource.

  • Each application has its Coherence configuration in a Grid Archive (GAR) file, which deploys with the application and to all dedicated storage nodes.

All applications that use Coherence use the cluster associated with the managed Coherence server and deploy their GAR files co-located with their applications. The following table lists sources of information about Coherence.

Table 2-3 Coherence and Coherence Clusters

For information on... See this topic...

Coherence concepts and features

"Introduction to Coherence" in Oracle Fusion Middleware Developing Applications with Oracle Coherence

Creating Coherence clusters

"Setting Up a WebLogic Server Domain Topology for Coherence" in Coherence Administrator's Guide

Configuring a Coherence Cluster

"Configuring and Managing Coherence Clusters" in Administering Clusters for Oracle WebLogic Server

2.6 Disaster Recovery

For maximum availability, you may need to deploy services at different geographical locations to protect against entire site failures due to unforeseen disasters and natural calamities. Oracle Fusion Middleware products support the configuration of a geographically separate standby site to act as a backup. Applications and services can fail over to this backup in the event of natural or unplanned outages at a production site.

For more on disaster recovery, see Oracle Fusion Middleware Disaster Recovery Guide.

2.7 Install Time Configuration (Profiles)

This section includes the following topics:

2.7.1 Domain (Topology) Profiles

Use the Configuration Wizard or WebLogic Scripting Tool (offline) to set up domains. See Oracle Fusion Middleware Creating WebLogic Domains Using the Configuration Wizard to create, update, and configure domains.

All 12c ( installation guides have steps to set up a single machine, multi-server domain, which is the standard installation topology. Section 1.6, "Understanding the Oracle Fusion Middleware Standard HA Topology" describes this topology in detail. For more information see:

2.7.2 Component/Service Database and File Persistence Profiles

Persistence profiles are a collection of settings that Oracle recommends for a specific persistence environment. There are two primary persistence profiles: database and file based. The following table shows persistence types for both profiles.

Table 2-4 Persistence Types for Database and File Persistence Profiles

Component/Service Database Persistence Profile File Persistence Profile


WLS JMS in Database Store

WebLogic Server JMS in File Store


JTA in Database Store

JTA in File Store


Database Store

Database Store


Database Store

Database Store

Service Table

Database Store

Database Store


Whole Server Migration

Whole Server Migration

Although you can "mix & match" a component or service with the persistence profile, the persistence type groups work together optimally. Oracle recommends that you use all options consistently within their respective profile.


An MDS data source has a WebLogic Server file persistence store allocated along with the data source. Because you use the file persistence store only in development mode, you can ignore it for high availability purposes. You don't need to recover the file persistence store in the event of failure.

See Also:

See "Interoperability with Supported Databases" in the Interoperability and Compatibility Guide for database version requirements for selected products and features.

2.7.3 Post-Configuration Defaults

When you complete a standard installation, a domain is set up with a file-based persistence profile. To configure database-based persistence for JMS/JTA resources, see Chapter 7, "JMS and JTA High Availability." To set up whole server migration, see Chapter 3, "Whole Server Migration."


Some products may have specific requirements for shared file stores; Oracle recommends that you refer to your product's requirements for details.

The following table describes additional sources of information.

Table 2-5 Domain Configuration Topics

For additional information on... See this topic...

Shared file systems to use with the file persistence profile

Chapter 4, "Using Shared Storage"


Section 7.2, "About Migratable Targets for JMS and JTA Services"


Section 2.3, "Application Failover"

2.8 Application and Service Failover

Migration in WebLogic Server is the process of moving a clustered WebLogic Server instance or a component running on a clustered instance elsewhere if failure occurs. Whole server migration occurs when the server instance migrates to a different physical system upon failure. Service-level migration is when services move to a different server instance within the cluster.

This section describes server and service failover for JMS and JTA.

2.8.1 About Automatic Service Migration (JMS/JTA)

Service-level migration in WebLogic Server is the process of moving pinned services from one server instance to a different available server instance in the cluster.

You can configure JMS and JTA services for high availability by using migratable targets. A migratable target is a special target that can migrate from one server in a cluster to another. A migratable target provides a way to group migratable services that should move together. High availability is achieved by migrating a migratable target from one clustered server to another when a problem occurs on the original server. When the migratable target migrates, all services that the target hosts migrate.

If a product does not support Automatic Service Migration, you can use whole service migration.

See Also:

For more information, see "Service Migration" in Oracle Fusion Middleware Administering Clusters for Oracle for the following topics:

2.9 Roadmap for Setting Up a High Availability Topology

The following table describes high level steps required to set up an example middleware topology with high availability.

Table 2-6 Roadmap for Setting Up a High Availability Topology

Task Description Documentation

1. Install Real Application Clusters

Install Real Application Clusters

Oracle Real Application Clusters Administration and Deployment Guide

2. Install and configure middleware components

Install and configure the application by following instructions in an application installation guide.

Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure or the installation guide for your product

3. Install and configure Oracle HTTP Server

Install and configure Oracle HTTP Server in the same domain

Installing and Configuring Oracle HTTP Server

4. Configure a load balancer

Configure a third- party load balancer that meets specific requirements, or Oracle HTTP Server/Oracle Traffic Director.

Section 2.2, "Server Load Balancing in a High Availability Environment."

5. Scale out the topology (machine scale out)Oracle Fusion MiddlewareOracle Fusion Middleware

Steps for scaling out a topology (machine scale-out) for all products that are part of a Fusion Middleware WebLogic Server domain.

Chapter 6, "Scaling Out a Topology (Machine Scale Out)"

6. Configure high availability for the Administration Server

Configure high availability for the Administration Server

Chapter 8, "Administration Server High Availability"