Page 2 of 3   « previous page   next page »

Looking at Figure 5, a base cell having a single node with multiple application servers is configured in a single LPAR. It's a valid configuration. Compared to multiple base cell configurations, this configuration uses fewer resources. However, this topology isn't recommended. Since this configuration doesn't have a deployment manager; the administrative application runs in the first server created. It has only limited control over the other servers. Plus, key WAS functions such as clustering and some JNDI lookups aren't possible. The scalability and availability of this topology are the same as the base cell's.

An ND cell configuration in a single LPAR is shown in Figure 6. This is the most optimal topology for a single LPAR environment.

The Deployment Manager is the central point of administrative control. The Node Agent is responsible for administration at the node level. All application servers and applications are under the control of the administrative application running in the Deployment Manager.

Since everything is configured in a single LPAR, scale-up is the only way to scale in this environment. Overall availability depends on the availability of the LPAR, related subsystems such as CICS, DB2 and WebSphere MQ, and the application servers in the cell. A vertical cluster can be created to remove single points of failure of the application servers in the cluster.

If planned and configured properly, this environment can be expanded to cross multiple LPARs leveraging Parallel Sysplex's near-linear scalability and high availability. Since the topology can produce a complete ND cell with non-production scalability and availability, it's normally used as a QA/Testing environment.

Generally speaking zSeries LPARs and subsystems are fairly stable. So some companies run production applications in a single LPAR ND cell for cost reasons if they can stand the system scalability and maintenance downtime.

It may not be a good idea to share a single LAPR ND cell among multiple development groups as a development environment. A ND cell is the least isolated from the development groups because the administrative application can control all the servers and applications in the cell. Worse, only one user can deploy applications and make server configuration changes at any given time. Otherwise, the configuration files could crash.

It's not a good idea to create two or more nodes in the same cell on a single LPAR. It doesn't provide any greater degree of application isolation than that afforded by separate application servers. It doesn't provide any greater degree of administration isolation afforded by one node. It doesn't allow applying maintenance node by node. And it results two node agents getting created; a node agent consumes significant memory.

All possible WAS configurations in a single LPAR use zWLM for workload management, and RRS and ARM for fast recovery from subsystem failure (in the single LPAR). If you'd like to leverage the zSeries's near-linear scalability and continuous availability, Parallel Sysplex must be brought into the picture.

WAS Topology in a Sysplex Environment
A WAS for z/OS ND cell can be configured across LPARs in a (Parallel) Sysplex. Figure 7 shows the topology. Like the ND cell in a single LPAR, the Deployment Manager and Node Agent work together providing a central point of managing and controlling all the application servers and applications. In Figure 7, DB2 and WebSphere MQ subsystems co-locate with application servers in the same LPAR. This is not the only choice. But in general it boosts performance. I'll cover this in subsequent articles.

Horizontal clusters can be created across LPARs for scale-out, failover, workload balance, and continuous availability (especially when the LPARs are on different physical boxes).

Sysplex distributor with dynamic VIPA works with zWLM to determine how to direct inbound requests. The most suitable server (workload and resource wise) is chosen to process the work request.

If one of the servers isn't available, the requests will be routed to other servers in the same cluster. The work can be absorbed because in a truly heterogeneous application environment the zWLM and IRD can distinguish and dynamically adjust resource deployment to meet the goals of critical work.

To scale out and remove SPOF, applications have to be able to access the same database and/or message queues from the different LPARs. The CICSPlex, DB2 data-sharing group and WebSphere MQ queue-sharing group need to be created. Parallel Sysplex technology makes sure the data sharing doesn't sacrifice performance and data integrity.

Data sharing in the Parallel Sysplex also provides a significant availability benefit, protecting against the loss of data and availability in light of planned and unplanned outages by enabling workloads to be shifted among the LPARs as needed to maintain the business goal.

This configuration allows rolling-out of WAS maintenances and applications if the install HFS and configuration HFS are planned and implemented correctly. This way, WAS and application maintenances and upgrades downtime can be avoided. Should you need more information, please refer to the resources.

Since this configuration leverages all the Parallel Sysplex features, it's recommended as the WAS for a z/OS production environment. If possible, the production ND cell should be configured across three LPARs. If one of the LPARs is taken down for maintenance, the other two are still be available without compromising any QoS.

Obviously the system is more complicated and consumes more resources. It may be too expensive for some companies.

Page 2 of 3   « previous page   next page »