Parent topic: Introduction to High Availability
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 |
|
WebLogic Server Domain |
|
Administration Server |
|
Managed Servers and Clusters |
|
Node Manager |
Note:
For more information, see Communications in a Cluster in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server
Typically, a load balancer front ends high availability deployments.
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.
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.
Detailed load balancer configuration steps depend on two elements.
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.
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 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 Configuring mod_wl_ohs.conf for more on the |
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 for more information. |
There are different types of failover and application behavior.
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.
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
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):
A user makes a request. A hardware load balancer routes it to Instance A of the application.
Instance A of the application becomes unavailable due to node failure, process failure, or network failure.
The hardware load balancer marks Instance A as unavailable.
The user makes another 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. 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.
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 information on Oracle RAC see:
Introduction and Roadmap in Oracle Fusion Middleware Administering Clusters for Oracle WebLogic Server
Overview of Oracle Clusterware in Oracle Clusterware Administration and Deployment Guide
Overview of Oracle RAC in Oracle Real Application Clusters Administration and Deployment Guide
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 |
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.
There are domain, file, and database-based profile types to consider as you configure a SIT.
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.2) 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. For more information see:
Introducing the Oracle HTTP Server Standard Installation Topologies in Oracle Fusion Middleware Installing and Configuring Oracle HTTP Server
Configuring the Oracle Fusion Middleware Infrastructure Domain in Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure.
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.
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 |
|
JMS and JTA |
|
Failover |
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.
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 doesn't support Automatic Service Migration, you can use whole service migration.
Note:
For more information, see Service Migration in Oracle Fusion Middleware Administering Clusters for Oracle for these topics:
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. |
|
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. |
|
6. Configure high availability for the Administration Server |
Configure high availability for the Administration Server |