High availability (HA) refers to the ability to maintain operational integrity when a server failure occurs. This can be achieved by installing two or more Oracle SOA Suite 12c nodes in a cluster to protect against failure. Server failures could be software induced, such as a JVM crashing due to it being out of memory, or due to hardware failure, such as a local disk going bad. Installing an Oracle SOA Suite 12c cluster requires additional setup and configuration that are different from that of a single-node installation.

In this chapter, we describe how to set up a two-node Oracle SOA Suite 12c cluster in an active-active mode, wherein if a server fails, the other will continue processing transactions, ensuring a relatively high degree of availability. This type of architecture provides a high degree of failover, wherein most asynchronous transactions are failed over on the active node in the cluster, with little loss of transactional data.

There are many ways in which you can set up a highly available SOA Infrastructure, such as vertical and/or horizontal scaling over physical machines, hardware partitioning using virtualization, and cloud computing. The Oracle Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 12c (12.1.3), informally referred to as the Enterprise Deployment Topology (EDG), provides a detailed example of how to install a highly available production-quality environment. This guide is comprehensive and complete, discussing all aspects of enterprise deployment. With 290 pages, the Oracle documentation is extremely detailed (and somewhat complicated) for the non-experienced administrator, requiring a deep understanding of Oracle WebLogic Server clustering and failover concepts.

This chapter describes many more scaled down and simplified instructions, and despite the limitations of our architecture (which will be described later), is completely acceptable for most mid-sized to large production environments. The intent of this chapter is to provide instructions that are easy to execute and entirely repeatable, while remaining light on concepts and explanation.

Architecture

There are many types of architectures that can be implemented in an enterprise deployment topology, and this chapter focuses on one of the simpler ones. With reduced complexity comes certain disadvantages.

Software versions

The resulting installation as documented in this chapter, is based on the following 64-bit software products:

• Supported Linux versions:
  • Oracle Linux 5 Update 6+
  • Oracle Linux 6 Update 1+
  • Red Hat Enterprise Linux 5 Update 6+
  • Red Hat Enterprise Linux 6 Update 1+
• Oracle JDK 7 (1.7.0_55-b13)
• Oracle Web Tier 12c (12.1.3)
• Oracle WebLogic Server 12c (12.1.3.0.0)
• Oracle SOA Suite 12c (12.1.3.0.0)

An architectural diagram

Figure 12.1 depicts the architecture of our two-node Oracle SOA Suite 12c cluster. It relies on two physical servers called SOAHOST1 and SOAHOST2 (also aliased as WEBHOST1 and WEBHOST2). A single domain, soa_domain, is created in this architecture. The managed servers are clustered as depicted in the following figure. Oracle HTTP Server, installed on each of the separate physical hosts, listens on port 7777 and routes console requests to the Admin Server, and transactional requests to the SOA and OSB managed servers. Each node of the cluster requires access to a shared filesystem and shared database.

Oracle Web Services Manager (WSM) is installed on a separate managed server and must be started up prior to bringing up SOA and OSB. ESS is also installed on its own independent managed servers.

Figure 12.1: Architecture of the two-node cluster

Multiple load-balanced URLs should be set up and defined on an external hardware load balancer, such as F5 BIG-IP. No secure communication, such as SSL, is defined in this architecture, as it assumes that the installation is exclusively used internally. This can be reconfigured later if needed. The EDG located at http://docs.oracle.com/cd/E12839_01/core.1111/e12036/toc.htm details this.

Architectural considerations

Certain design considerations are made in the architecture outlined in this chapter. Failover of certain components may not be possible, all for the purpose of considerably reducing the complexity. This architecture is not ideal if your environment cannot guarantee the recovery of a failed physical server, which is rarely the case nowadays.

Thus, the following are the considerations that deviate from the EDG with reference to our architecture:

• Oracle BAM is not installed, primarily for the purpose of avoiding the installation of a reporting tool on the same hardware as your transactional SOA infrastructure.
• No firewall restrictions are assumed. For more details on which ports must be open in your network, refer to the EDG.
• No floating IP address will be utilized; thus, the Admin Server is tied exclusively to SOAHOST1 for the sole purpose of reducing complexity in the network setup and failover. In the unlikely event that SOAHOST1 is down and irrecoverable, additional work that is not detailed in this chapter is needed to reconfigure SOAHOST2 in order to bring up the Admin Server.
• WSM is deployed on its own managed servers to improve performance and availability.
• No SSL is configured between the load balancer and Oracle HTTP Server (OHS), OHS and WebLogic Server, and WebLogic Server and Oracle Database.
• A shared filesystem is utilized for transaction logs, deployment descriptors (plan files), persistent stores, as well as software binaries that include the Oracle JRockit JDK, Oracle WebLogic Server, and Oracle SOA Suite.
• 64-bit installations are performed. Though 64-bit JVMs have a very slight performance disadvantage compared with 32-bit equivalents, memory space is hypothetically unlimited.
• Oracle Web Tier is utilized to allow the WebLogic Server cluster membership to be reconfigured. This is used to easily add and remove servers without changing the load balancing configuration.
• A total of five Node Managers will be running: one for the Admin Server, one for each of the managed server's domain directory, and one for each of the OHS instances.
• Unicast, versus multicast, is leveraged for communication between the members of the cluster, as it does not require cross-network configuration and reduces potential network errors that can occur from multicast address conflicts.
• WebTier and MidTier are installed on the same physical server.
• There is no utilization of virtual hosts and virtual IP addresses, and the WebLogic whole server migration is not set up. Thus, the automatic restart of a server instance on a separate physical machine is not available. Furthermore, messages in JMS destinations bound to the failed managed server are not picked up by any of the active servers of the cluster.
• Contrary to the instructions in the EDG, a dedicated, centralized LDAP-compliant authentication provider is not utilized.

Understanding the variables and terms

Certain terms and variables described in this chapter require familiarization prior to the installation. Refer to the following table for a set of explanations:

Term	Explanation
MidTier	A single domain is created to host the software installation, residing on the Oracle Home that is split between the local and shared storage. This installation of WebLogic Server, WSM, SOA Suite, OSB, and ESS is referred to as MidTier.
WebTier	The term WebTier and OHS are used interchangeably. This is a separate independent installation on the same physical box, but under a separate Oracle Home than the MidTier. Both MidTier and WebTier require different environment variables.
SOAHOST1	Considering this is a two-node cluster, any reference to SOAHOST1 should be executed on the first node of the cluster, and any reference to SOAHOST2 should be executed on the second node of the cluster.
WEBHOST1	Both WebTier and MidTier reside on the same physical server, so any references to WEBHOST1 and SOAHOST1 technically refer to the same physical server. However, during installation and configuration, there are some notable differences.
$ORACLE_HOME	Any variables that appear in this form should be typed as is.
[ORACLE_HOME]	If you encounter a variable name surrounded by square brackets, the actual value must be substituted. Note that the value of the variable may differ depending on whether you are executing a MidTier or WebTier instruction. Simply type either source envMidTier.sh or source envWebTier.sh followed by echo $ORACLE_HOME to retrieve the value of the variable.