Application Server

WebSphere Application Server (WAS) for z/OS is IBM's z/OS implementation of the J2EE server design. To build robust and efficient WAS environments on z/OS, you must determine the topologies that address your needs. Since WAS for z/OS is middleware, the topologies can become quite complex and require forethought. Considerations should be given to scalability, availability, and factors such as security, performance, and administration.

zSeries platform technologies have great impact on WAS for z/OS topology, scalability, and availability. Let's start with zSeries technologies.

Important zSeries Concepts To Understand
Today's zSeries Servers run in logical partition (LPAR) mode as shown in Figure 1. zSeries LPAR, delivered via the Processor Resource/System Manger (PR/SM), is a very mature server virtualization technology that improves server utilization and overall system availability. A physical zSeries box is split into multiple logical partitions. Each LPAR runs a distinct z/OS. The zSeries Intelligence Resource Director (IRD) can adjust logical resources across LPARs dynamically and automatically based on Workload Manager (WLM) and policy.

zSeries clustering technology, Parallel Sysplex, is based on a Non-Uniform Memory Access (NUMA) star clustering topology. The multi-system data-sharing technology enables up to 32 z/OS systems to be clustered with near-linear scalability.

The heart of the Parallel Sysplex is a special high-speed hardware construct, the zSeries Coupling Facility, which provides very fast communication among LPARs with latency of microsecond. It also maintains a global cache, global lock manager and shared communication area, all of which can be accessed and shared by z/OS subsystems.

Parallel Sysplex enables direct concurrent read/write access to shared data from all processing nodes in the configuration without sacrificing performance or data integrity. The CICSPlex, DB2 data-sharing group and WebSphere MQ queue-sharing group leverage Parallel Sysplex technology to achieve high scalability, continuous availability, failover, and load balance.

Dynamic Virtual IP Address (VIPA) and Sysplex Distributor are two basic z/OS TCP/IP technologies used by Parallel Sysplex for workload distribution and continuous availability.

Resource Recover Services (RRS) and Automatic Restart Management (ARM) are zSeries technologies for fast failover and recovery.

z/OS has a built in Unix System Service (USS) with an Hierarchy File System (HFS). All the WAS configuration files for z/OS are held in the HFS.

That's pretty much all you need to know about IBM's zSeries server. The rest of this article will discuss various WAS topologies for z/OS. Along with the topology discussion, the scalability and availability implication of a topology will be explored too.

WAS for z/OS Building Blocks
Starting with version 5, WAS for z/OS was equivalent to the WAS Network Deployment (ND) for distributed platforms. If a specific version isn't mentioned, the discussion here applies to version 5.x. Figure 2 shows a WAS ND cell on z/OS. It has similar building blocks:

• Server - the basic unit where applications execute.
• Nodes - the collection of servers on a given z/OS image.
• Node Agents - a special-purpose server that acts on behalf of the administrative application to make changes in the node.
• Deployment Manger - a special-purpose server that runs the administrative application
• Cell - a collection of nodes managed by the Deployment Manager. A cell is the management boundary of WAS for z/OS.

WAS for z/OS can be configured as a standalone server as well. A standalone server is a single-application server that's not part of a Deployment Manager's cell. As shown in Figure 3, it's also a node and a cell. We're going to call it a base cell.

WAS Topology in Single LPAR
Three basic topologies can be used to configure WAS for z/SO in a single LPAR:

• Multiple base cells each with its own node and application server
• A single base cell having a single node with multiple application servers
• A single deployment manager cell

As shown in Figure 4, multiple base cells are configured in the same LPAR. This topology provides several basic WAS for z/OS runtime environments. It can only scale up by adding servant regions. Each building block of a base cell, LPAR, and related subsystems such as CICS, DB2 and WebSphere MQ is a single point of failure (SPOF). Obviously these base cells can't be used as a production environment.

So what's this configuration good for? These base cells provide the most isolation between application servers. Each server has its own administration console. Resources for each node are separated. Large zSeries shops use this configuration as their development environment. Each development group can do whatever it wants in its own base cell.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...