| Issue 2, 2013 | Download pdf |
Most would agree that high availability, ensuring a single point of failure does not cause disruption to critical applications, is an important aspect of any IT architecture. High availability can also increase capacity by adding process instances for servicing client workload. Discover how EntireX and TCP/IP work in tandem to support high availability on IBM® Parallel Sysplex®. This information is intended to assist application integration professionals seeking to improve their customers’ application infrastructure availability, minimize downtime and potentially increase system capacity.
EntireX High Availability
The fundamental design principles behind EntireX High Availability (HA) include promoting redundant and loosely coupled services without adding proprietary architecture or requiring a shared store between EntireX Brokers. The intent is to use common z/OS features available through existing Parallel Sysplex license entities such as Sysplex Distributor and Workload Manager (WLM). The simplest form of this proposed design is depicted in Figure 1 using two EntireX Brokers, each with redundant RPC (Remote Procedure Call) Servers servicing customer applications.
FIGURE 1. EntireX Broker and RPC Server redundancy improves mainframe application availability.
In the case of EntireX HA, each instance is equal and independent of one another, yet share common client RPC workload through a virtual IP address (clustering layer). In the event of a failure, client application requests will flow to an available EntireX Broker in the cluster.
Network-based high availability solutions provide health monitoring and fault recovery at both the TCP/IP and EntireX Broker stub levels to increase the availability of applications without proprietary software, and in addition to fail-over, allow resources to be load-balanced. A good way to think of it is that if an EntireX Broker goes away (like a power cord was pulled), client requests are instantaneously routed to an available EntireX Broker in the cluster. High availability solutions can reroute messages in milliseconds and achieve excellent levels of uptime for planned and unplanned outages.
Examples of network-based high availability solutions include Sysplex Distributor (System z®), Windows Server’s Network Load Balancing (NLB) and F5® BigIP®.
Virtual IP Address Evolution
Virtual IP Addresses (VIPAs) are IP addresses without any particular network interface. In other words, to an external router or other TCP/IP stack (e.g., client), a VIPA appears as a normal address that is reachable via the hosting stack. The hosting stack contains additional information to route to another address or physical link hosted by the stack.
The benefit of using a VIPA as an application address on a z/OS TCP/IP stack containing multiple physical links is that a failure of any one link will not disrupt connectivity to the application. Plus, because the virtual device exists only in software, it is always active and never experiences a physical failure.
Dynamic VIPA (DVIPA) is the capability to provide cross-stack VIPA and requires Sysplex Cross-system Coupling Facility (XCF) communications. Essentially, the System z platform allows multiple z/OS images to run in a single processor complex via Logical Partitioning (LPAR). Although each LPAR manages its own TCP/IP stack(s), high-speed connectivity functions like Open Systems Adapter (OSA) and HiperSockets™ may be shared between TCP/IPs in different LPARS. The main function of the DVIPA however, is to provision the single-node appearance of a redundant IP platform to the network using the Sysplex clustering technology.
Distributed DVIPA (also known as Sysplex Distributor) builds on DVIPA to provide additional customer network configuration flexibility. In addition to fail-over features, Sysplex Distributor provides more real-time consultation with the Workload Manager for determining cluster node capabilities as well as consulting the Policy Agent to allow the actual EntireX Broker selection to be influenced by policies governed by the business’ service level agreements.
How Client RPC Connections Work with DVIPA
A particular z/OS TCP/IP is configured as a routing stack with a DVIPA, with one or more other stacks configured as backup routing stacks for that DVIPA. An additional configuration statement (VIPADISTRIBUTE) on the primary stack designates the identifying EntireX Broker port number(s) and which TCP/IPs (target stacks) in the Parallel Sysplex will be hosting EntireX Broker listeners. This configuration information is distributed automatically to all of the target stacks via XCF messaging; therefore, only the routing stack needs the additional VIPADISTRIBUTE statement. The target stacks each activate the same VIPA address, but do not advertise it to the routing networks. When a RPC client connection binds to the designated EntireX Broker port on a target stack, the target stack notifies the routing stack via XCF messaging that the EntireX Broker is available for work.
When the routing stack receives a client connection request for a DVIPA EntireX Broker, the routing stack first determines which target stacks have active EntireX Brokers listening on the same port. The routing stack then consults the Workload Manager on relative capacities, and adjusts those capacity values with information from the Service Policy Agent (if applicable) before selecting the target stack. The RPC client connection request is then routed via the appropriate dynamic XCF IP link to the target stack and the proper EntireX Broker. For efficiency, the routing stack caches active RPC client connections so that future client IP traffic for a connection is routed to the same target stack and EntireX Broker. The target stack notifies the routing stack when the RPC connection ends, to allow the routing table entry to be deleted.
If the routing stack should suffer an outage, the VIPA takeover mechanism will automatically move the DVIPA to a backup routing stack. The remaining target stacks notify the backup routing stack of active connections so that clients connected to those target stacks will not see an outage at all (other than possible TCP retransmissions during the takeover process). When the primary routing stack is restored, non-disruptive VIPA movement is used to restore the routing function and the backup stack no longer needs to serve as the routing stack. Again this occurs with no visible disruption to the RPC clients.
Configuring Redundant RPC Servers
Like EntireX Brokers, RPC Servers need to be configured for high availability using a redundant approach. But unlike EntireX Brokers that are configured for dynamic client workload, RPC Servers must have statically controlled connections so that they can be properly managed and monitored through upstream EntireX Brokers.
FIGURE 2: DVIPA Configured EntireX Example
As shown in figure 2, it is important to segment TCP/IP-based RPC Server connections on static EntireX Broker addresses (1) rather than using DVIPA addresses (2) in order to control these backend connections. Typically, you will want to configure at least two RPC Server instances for every service (CLASS/SERVER/SERVICE) definition to achieve redundancy.
HiperSockets, if available, is a high-performance feature of z/OS that allows on board TCP/IP applications to use shared-memory techniques under the covers. z/OS RPC Server TCP/IP connections with z/OS EntireX Brokers can take full advantage of this feature.
In Summary
EntireX is Software AG's premier solution for directly connecting processes and applications running on a mainframe with distributed delivery systems and services. One of the most admired features of mainframe computing is its ability to consistently maintain the highest level of service availability. By leveraging the accessibility features of EntireX with the mainframe's availability characteristics, you can minimize downtime and increase system capacity.
Find more information about EntireX HA and new product documentation for EntireX at: http://documentation.softwareag.com/webmethods/entirex.htm
An example DVIPA EntireX Broker configuration with detail listings can be found on the Tech Community