This chapter describes high availability concepts and includes the following topics:
Section 2.1, "Server Load Balancing in a High Availability Environment"
Section 2.8, "Roadmap for Setting Up a High Availability Topology"
For information on Oracle Fusion Middleware concepts, see the following topics in the guide 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 |
|
|
WebLogic Server Domain |
|
|
Administration Server |
|
|
Managed Servers and Managed Server Clusters |
|
|
Node Manager |
See Also:
"Communications in a Cluster" in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server
Load balancing is the even distribution of jobs and associated communications across the computing and networking resources in your environment.
Typically, Oracle Fusion Middleware high availability deployments are front ended by a load balancer that you configure to distribute incoming requests using various algorithms. You can configure load balancing between different components or applications.
You can also configure load balancing between different components or applications by using Oracle HTTP Server or, on Exalogic only, Oracle Traffic Director. See Section 2.1.3, "Server Load Balancing with Oracle HTTP Server or Oracle Traffic Director" for more information.
This section includes the following topics:
You can use third-party load balancers in your Oracle Fusion Middleware high availability deployments. 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 using actual host names. The load balancer can then load balance requests to the servers in the pool.
Note:
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).
Virtual servers and port configuration: ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:
The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle WebLogic Clusters, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.
The 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 the virtual server names.
Ability to detect node failures and immediately stop routing traffic to the failed node.
Resource monitoring / port monitoring / process failure detection: the load balancer must be able to detect service and node failures through notification or some other means and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to 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 the back-end services that it forwards traffic to are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.
SSL acceleration. Oracle recommends this feature but does not require it.
Ability to Preserve the Client IP Addresses: the load balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.
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 the documentation for your own load balancer. For high-level load balancer configuration steps, see the enterprise deployment guide for the component you are working with.
This section describes Oracle products you can use to provide load balancing.
Server Load Balancing with Oracle HTTP Server
Oracle HTTP Server is a web server with built-in WebLogic Server Proxy Plug-In module to act as HTTP front-end for one or more WebLogic servers. This built-in receives the incoming request from the client and load balances the request to one or more WebLogic Servers.
Oracle HTTP Server includes the mod_wl_ohs module, which routes requests to Oracle WebLogic Server. The mod_wl_ohs module provides the same load balancing functionality as mod_weblogic, the 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 7.8.1.4, "Configuring mod_wl_ohs.conf" for more information on the mod_wl_ohs module.
Server Load Balancing with Oracle Traffic Director
Oracle Traffic Director is a highly available Application Delivery Controller with WebLogic inter-operability enhancements to allow incoming requests to be efficiently throttled to one or more WebLogic server clusters. Oracle Traffic Director is a fast, reliable, and scalable layer-7 software load balancer. You can set up Oracle Traffic Director to serve as the reliable entry point for all HTTP, HTTPS and TCP traffic to application servers and web servers in the back end. Oracle Traffic Director distributes the requests that it receives from clients to servers in the back end based on the specified load-balancing method, routes the requests based on specified rules, caches frequently accessed data, prioritizes traffic, and controls the quality of service.You can use Oracle Traffic Director with Exalogic only.
Failover is relocating an overloaded or failed resource such as a server, disk drive, or network to its redundant or backup component.
Application failover is when an application component doing a particular job becomes unavailable for any reason and a copy of the failed component finishes the job.
Information about what has been done on a job is called state. WebLogic Server maintains state information using techniques called session replication and replica-aware stubs. When 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.
Note:
Oracle applications meet these session failover requirements unless a specific exception is made for an application.
For seamless application 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 are using Oracle HTTP Server, the server is configured with the WebLogicCluster 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
Expected Behavior for Application Failover
If you configure the environment correctly, application users do not notice when an application instance in a cluster becomes unavailable. The sequence of events in an application failover is, for example, as follows:
A user makes a request and a hardware load balancer routes it to Instance A of the application.
Instance A of the application becomes unavailable because of node failure, process failure, or network failure.
The hardware load balancer marks Instance A as unavailable.
The user makes a subsequent request. The request is routed to Instance B.
Instance B is configured as a replication partner of Instance A and has the user's session state.
The application resumes using the session state on Instance B and the user continues working without interruption.
See Also:
See the Domain Template Reference for information on domain and extension templates that support high availability.
See Failover and Replication in a Cluster in the guide Administering Clusters for Oracle WebLogic Server for information on failover and replication at the application level.
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 a single 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 simultaneously provides a highly scalable and highly available database for Oracle Fusion Middleware.
Every Oracle RAC instance in the cluster has equal access and authority. Node and instance failure may affect performance but does 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:
Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server
Oracle Real Application Clusters Administration and Deployment Guide
If you follow Oracle Fusion Middleware Installing and Configuring Oracle WebLogic Server and Coherence or a product installation guide, such as Oracle Fusion Middleware Installing and Configuring Oracle Fusion Middleware for Oracle Application Development Framework, the standard installation topology includes a standard Coherence cluster that serves as 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 referred to as WebLogic Managed Coherence Servers. JVMs that join a cluster are called 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 includes its Coherence configuration in a Grid Archive (GAR) file. The GAR file is deployed with the application and to all dedicated storage nodes.
All Fusion Middleware 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-2 provides additional sources of information about Coherence.
Table 2-2 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 |
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 detailed information about disaster recovery for Oracle Fusion Middleware components, refer to Oracle Fusion Middleware Disaster Recovery Guide.
This section includes the following topics:
You use the Configuration Wizard or WebLogic Scripting Tool (offline) to set up domains. See the guide Oracle Fusion Middleware Creating WebLogic Domains Using the Configuration Wizard for procedures to create, update, and configure domains.
All 12c (12.1.2) installation guides provide instructions for setting up a single machine, multi-server domain using the expanded profile. See one of the following guides for more information:
Oracle Fusion Middleware Installing and Configuring Oracle HTTP Server
Oracle WebLogic Server Installing and Configuring Fusion Middleware for Oracle ADF Applications
Persistence profiles are a collection of settings intended to meet a specific persistence environment. There are two persistence profiles for Expanded profiles: database and file based.
Table 2-3 shows persistence types for database and file persistence profiles.
Table 2-3 Persistence Types for Database and File Persistence Profiles
| Component/Service | Database Persistence Profile | File Persistence Profile |
|---|---|---|
|
JMS |
AQ 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 |
Automatic Service Migration |
Whole Server Migration |
Although you can "mix & match" a component or service with the persistence profile, the persistence type groups in Table 2-3 work together optimally. Oracle recommends that you use all options consistently within their respective profile.
See Also:
See "Interoperability with Supported Databases" in the Interoperability and Compatibility Guide for database version requirements for selected products and features.
For the expanded domain configuration, the database persistence mode is configured by default. For compact domain configuration, file persistence is the default.
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-4 describes additional sources of information. To configure file persistence after an expanded domain configuration, such as moving from database persistence to file persistence, see Chapter 5, "JMS and JTA High Availability".
Table 2-4 Domain Configuration Topics
| For additional information on... | See this topic... |
|---|---|
|
Shared file systems for use with the file persistence profile |
|
|
JMS and JTA |
Section 5.2, "Configuring JMS and JTA Services for High Availability" |
|
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. With service-level migration, the services move to a different server instance within the cluster.
This section describes server and service failover for JMS and JTA.
Topics in this section include:
A WebLogic Server cluster provides high availability and failover by duplicating an object or service on redundant servers in the cluster. However, some services, such as JMS servers and the JTA transaction recovery service, are designed with the assumption that there is only one active instance of the service running in a cluster at any given time. These types of services are referred to as pinned services because they remain active on only one server instance at a time.
In a WebLogic Server cluster, most services deploy homogeneously on all server instances in the cluster, enabling transparent failover from one server to another. However, pinned services such as JMS and the JTA transaction recovery system are targeted at individual server instances within a cluster. For these services, WebLogic Server supports failure recovery with migration instead of failover.
WebLogic Server provides a feature for making JMS and the JTA transaction system highly available: migratable servers. Migratable servers provide for both automatic and manual migration at the server-level, rather than the service level.
When a migratable server becomes unavailable for any reason, for example, if it hangs, loses network connectivity, or its host system fails—migration is automatic. Upon failure, a migratable server automatically restarts on the same system if possible. If the migratable server cannot restart on the system it failed on, it migrates to another system. In addition, an administrator can manually initiate migration of a server instance.
See Also:
See Whole Server Migration in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server for more information on preparing for automatic whole server migration, configuring automatic whole server migration, and server migration processes and communications.
See Section 5, "JMS and JTA High Availability" for more details on JMS and JTA services.
Service-level migration in WebLogic Server is the process of moving pinned services from one server instance to a different available server instance within 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. As such, 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 is migrated, all services hosted by that target are migrated.
See Also:
For more information, see "Service Migration" in the guide Oracle Fusion Middleware Administering Clusters for Oracle, which includes the following topics:
"Understanding the Service Migration Framework"
"Roadmap for Configuring Automatic Migration of JMS-related Services"
"Roadmap for Configuring Automatic Migration of the JTA Transaction Recovery Service"
This section provides high level steps for configuring an example middleware topology with high availability, such as the topology that Section 1.5, "Understanding the Oracle Fusion Middleware Standard HA Topology" describes.
Table 2-5 describes the steps required to set up a high availability topology.
Table 2-5 Roadmap for Setting Up a High Availability Topology
| Task | Description | Documentation |
|---|---|---|
|
1. Install Real Application Clusters |
Install Real Application Clusters |
See Oracle Real Application Clusters Administration and Deployment Guide |
|
2. Install middleware components |
Install the application by following instructions in an application installation guide. |
See Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure or the installation guide for your product |
|
3. Install Oracle HTTP Server |
Install Oracle HTTP Server in the same domain |
|
|
4. Configure a load balancer |
Configure a third- party load balancer that meets specific requirements, or Oracle HTTP Server/Oracle Traffic Director. |
See Section 2.1, "Server Load Balancing in a High Availability Environment." |
|
5. Scale out the topology (machine scale out) |
Steps for scaling out a topology (machine scale-out) for all Fusion Middleware products that are a part of a Fusion Middleware WebLogic Server domain. |