1. High Availability Guide
  2. Introduction to High Availability
  3. High Availability Concepts

2 High Availability Concepts

High availability involves elements such as load balancing, failover, Real Application Clusters, and profiles (settings).

Parent topic: Introduction to High Availability

Oracle Fusion Middleware Concepts

Get familiar with important concepts before scaling out.

Table 2-1 describes relevant 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 Clusters

Understanding Managed Servers and Managed Server Clusters

Node Manager

What Is Node Manager?

Note:

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

Parent topic: High Availability Concepts

Server Load Balancing in a High Availability Environment

Typically, a load balancer front ends high availability deployments.

Parent topic: High Availability Concepts

About Load Balancing

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

You use Oracle HTTP Server or Oracle Traffic Director to configure load balancing between different components or applications. See 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.

Parent topic: Server Load Balancing in a High Availability Environment

Third-Party Load Balancer Requirements

You can use third-party load balancers in your high availability deployments, as long as they have certain features.

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.

External load balancer must have these 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 doesn't 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.

Parent topic: Server Load Balancing in a High Availability Environment

Configuring Third-Party Load Balancers

The detailed load balancer configuration steps depend on two elements that are explained in this topic.

  • 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.

Parent topic: Server Load Balancing in a High Availability Environment

Server Load Balancing with Oracle HTTP Server or Oracle Traffic Director

Oracle has two options for server load balancing products: Oracle HTTP Server and Oracle Traffic Directory.

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 WebLogic servers. Receives incoming requests from clients and load balances each request to WebLogic servers. The OHS mod_wl_ohs module routes requests to 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.

See Configuring mod_wl_ohs.conf for more on the mod_wl_ohs module.

Oracle Traffic Director

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 Features of Oracle Traffic Director.

Parent topic: Server Load Balancing in a High Availability Environment

Application Failover

There are different types of failover and application behavior.

Parent topic: High Availability Concepts

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.

Parent topic: Application Failover

Session Failover Requirements

For seamless failover, an application must meet certain conditions.

Note:

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

An application must meet these conditions to failover seamlessly:

  • The application is in a cluster and at least one member of the 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

Parent topic: Application Failover

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. 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 another 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. The user continues working without interruption.

Note:

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.

Parent topic: Application Failover

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 that 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 don't result in downtime because the database service is available or can be made available on surviving server instances.

Note:

For more on Oracle RAC see:

Parent topic: High Availability Concepts

Coherence Clusters and High Availability

Every standard installation topology (SIT) includes a standard Coherence cluster. This cluster 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. Table 2-3 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

Parent topic: High Availability Concepts

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 Introduction to Oracle Fusion Middleware Disaster Recovery.

Parent topic: High Availability Concepts

Install Time Configuration (Profiles)

There are domain, file, and database-based profile types to consider as you configure a SIT.

  • Domain (Topology) Profiles
    Use the Configuration Wizard or WebLogic Scripting Tool (offline) to set up domains.
  • Persistence Profile Types
    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.
  • Post-Configuration Defaults
    When you complete a standard installation, a domain is set up with a file-based persistence profile.

Parent topic: High Availability Concepts

Domain (Topology) Profiles

Use the Configuration Wizard or WebLogic Scripting Tool (offline) to set up domains.

See Creating a WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard to create, update, and configure domains.

12c (12.2.1.3.0) installation guides have steps to set up a single machine, multi-server domain, which is the standard installation topology. About the Oracle Fusion Middleware Standard HA Topology describes this topology in detail. See:

Parent topic: Install Time Configuration (Profiles)

Persistence Profile Types

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.

Table 2-4 shows persistence types for both profiles.

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.

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

Component/Service Database Persistence Profile File Persistence Profile

JMS

WLS JMS in Database Store

WebLogic Server JMS in File Store

JTA

JTA in Database Store

JTA in File Store

OPSS

Database Store

Database Store

MDS

Database Store

Database Store

Service Table

Database Store

Database Store

Failover

Whole Server Migration

Whole Server Migration

Note:

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.

Note:

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

Parent topic: Install Time Configuration (Profiles)

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 JMS and JTA High Availability. To set up whole server migration, see Whole Server Migration.

Table 2-5 describes additional sources of information.

Note:

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

Table 2-5 Domain Configuration Topics

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

Shared file systems to use with a file persistence profile

Using Shared Storage

JMS and JTA

About Migratable Targets for JMS and JTA Services

Failover

Application Failover

Parent topic: Install Time Configuration (Profiles)

Application and Service Failover for JMS and JTA

Migration in WebLogic Server is the process of moving 1) a clustered WebLogic Server instance or 2) a component running on a clustered instance elsewhere if failure occurs.

Whole server migration occurs when a 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.

See these topics for server and service failover for JMS and JTA.

Parent topic: High Availability Concepts

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.

From release 12c (12.2.1.3.0), you can use the High Availability Options screen in the Configuration Wizard to automate the service-level migration configuration for the Fusion Middleware components. This screen appears for the first time when you create a cluster that uses Automatic Service Migration, persistent stores, or both, and all subsequent clusters that are added to the domain by using the Configuration Wizard, automatically apply the selected HA options.

If a product doesn't support Automatic Service Migration, you can use whole service migration.

Note:

See Service Migration in Oracle Fusion Middleware Administering Clusters for Oracle for these topics:

Parent topic: Application and Service Failover for JMS and JTA

Roadmap for Setting Up a High Availability Topology

Oracle recommends completing install and configuration steps in a certain order to set up an example high availability topology.

Table 2-6 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

Install Oracle Database 12c Software with Oracle RAC in 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.

Roadmap for Installing and Configuring the Standard Installation Topology in 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

Roadmap for Installing and Configuring Oracle HTTP Server in a WebLogic Server Domain in 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.

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.

Scaling Out a Topology (Machine Scale Out)

6. Configure high availability for the Administration Server

Configure high availability for the Administration Server

Administration Server High Availability

Parent topic: High Availability Concepts