This chapter describes high availability concepts and includes the following topics:
Section 2.1, "Server Load Balancing in a High Availability Environment"
Section 2.7, "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.
You can also use a combination of a load balancer and the Oracle HTTP Server (as Figure 1-1 shows) to provide maximum availability.
This section includes the following topics:
You can use third-party load balancers in your Oracle Fusion Middleware high availability deployments.
Note:
Oracle recommends a third-party load balancer that supports '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 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 9.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 location.
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 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
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.3.0.0) installation guides provide instructions for setting up a single machine, multi-server domain, referred to as the standard installation topology, which Section 1.5, "Understanding the Oracle Fusion Middleware Standard HA Topology" describes. See one of the following guides for more information:
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-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 |
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 |
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.
Note:
An MDS data source has a WebLogic Server file persistence store allocated along with the data source. Because the file persistence store is used only in development mode, you can ignore it for high availability purposes. There is no 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.
Following a standard installation, the domain is set up with a file-based persistence profile. To configure database-based persistence for JMS/JTA resources, see Chapter 6, "JMS and JTA High Availability." To set up whole server migration, see Chapter 3, "Whole Server Migration."
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.
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 6.2, "Configuring JMS and JTA Services for High Availability" |
|
Failover |
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 and configure middleware components |
Install and configure 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 and configure Oracle HTTP Server |
Install and configure 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. |
|
|
6. Configure high availability for the Administration Server |
Configure high availability for the Administration Server |