Transforming WebSphere to Open Liberty on OpenShift: An Operations point of view — Part 2: A simplified overview of WAS ND
This article is written by Karri Carlson-Neumann and Eric Herness.
This is part 2. You can also jump to part 1, or get wild and jump to part 3.
Introduction
This series is devoted to introducing traditional WebSphere Application Server Network Deployment (WAS ND) architects and runtime operations teams a first look at Open Liberty on OpenShift Container Platform (OCP).
In this installment of our series, we will focus on WAS ND, and setting the groundwork including the terminology and points of focus from which we will later expand. This will help clarify the relevant basics of where we are starting (WAS ND) and the important facts about for this audience about where we are going (Open Liberty on OCP).
Please note that all storytelling has been greatly simplified. The immediate goal of this section is to set the footings for some bridges between some of the major concepts.
This document will not dive into the fine details, because that can go on forever. It is hoped that once enough of the higher-level translations are established, you will be empowered to make some conclusions about the relationships of the finer details. You are encouraged to dig into deeper details in the appropriate product documentation, such as:
- WAS ND Knowledge Center (https://www.ibm.com/docs/en/was-nd/)
- Open Liberty documentation (https://openliberty.io )
- Kubernetes documentation (https://kubernetes.io/docs/home/)
- OCP documentation (https://docs.openshift.com)
Simplified overview of WAS ND — Infrastructure View
A minor note: Here we are specifically referencing WAS ND. However, most WAS ND details apply to a number of WebSphere stack products that are based on WAS ND, such as Business Process Manager (more recently known as Business Automation Workflow).The WAS ND product could be installed on to a number of host systems, of various Operating Systems, including bare-metal and Virtual Machines (VMs). For simplicity, this article will generically refer to the hosts as VMs.
A WebSphere cell is the administrative domain of the WebSphere Application Server environment. A WebSphere ND cell consists of a Deployment Manager (Dmgr) and a number of WebSphere nodes. The Deployment Manager is the central location for administration. The WebSphere administrative console runs on the Dmgr, and the WebSphere CLI communicates with the Dmgr process. Administrators have likely crafted their own playbooks full of JACL and Jython scripts for customized creation and configuration of runtime artifacts. When an administrator makes configuration changes, these changes are pushed to each of the Node Agents.
Each WebSphere node has a node agent. The node agent ensures that administrative commands from the dmgr are carried out on its node. Each WebSphere node may have one or more server JVMs.
Another minor note: in common language, the term “node” is often overloaded. In this document, “node” does not mean Virtual Machine (VM). However, it is true that 1 VM typically hosts 1 WebSphere node or the Deployment Manager, so this 1:1 mapping generally makes the squished terminology forgivable. The common exception to “separate VMs for all” is when the first VM hosts both the Deployment Manager and the first WebSphere node.
A WebSphere cluster is a collection of server JVMs which are managed as a single unit. Every member of the same cluster is hosting the same applications. The use of clusters encourages scalability, availability, and avoids a single point of failure for the deployed applications.
A webserver, such as IBM HTTP Server (IHS), routes the incoming HTTP traffic across the cluster members.
The figure below illustrates a cell that has 1 cluster. The cluster has 3 total cluster members, where 1 cluster member is on each WebSphere node.
Although the diagram above shows 1 cluster member on each WebSphere node, WebSphere does not require each cluster to have a member on every node. A cluster is also not required to have only 1 member per node.
An additional dimension to consider is the total number of WebSphere cells, and how many clusters and cluster members there are cumulatively.
Jumping ahead, one thing you are looking for here is a count of the cluster member JVMs. Soon, this document will add in the consideration of workload. In that context, that means how many applications are running in each JVM, and how much efficiency or density are you achieving overall. 
One detail not shown in the illustrations above is the concept of WebSphere “profiles”. Profiles tend to be quiet details that don’t shine as brightly in overall runtime topology pictures. Profiles provide a level of abstraction between the product installation versus instance information. As WebSphere administrators, you know that a “profile” is essentially an “instance”, and that “profile creation” is part of standing up a new cell or adding more nodes to a cell. The location of the profile information on each host’s file system contains instance-specific details, such as the logs for the JVMs on that node (unless you have specified for logs to be elsewhere) and the persisted configuration definitions for servers and resources on that node (ie, the “server.xml” files and the “resources.xml” files).
Part of the reason for calling out profiles is to keep in mind that it is possible to have a single installation of WebSphere on a VM while also having created many profiles that use that single installation. We won’t dive into that scenario and its many implications here.
Depending on whatever your requirements were at the time your WAS ND environments were created, there were (and are) many reasons for different WAS ND cluster topologies.
Some common variations include:
There are many different mixtures of leveraging cells, VMs and clusters, each with their own pros and cons. Some of the variations have attempted to reduce licensing costs, but usually at the expense of complexity and maintainability. Remember a few more abstract things as you begin to look at the existing WebSphere installations:
- Cells generally are updated to a new version of WebSphere all at once.
- VMs all need maintaining and generally some level of licensing.
- Some of these architectures were built in the days of 32-bit JVMs, as opposed to the mature 64-bit JVMs we enjoy today.
One of the concepts that the variations in cluster topologies backs into is scaling. Without going into an entire dissertation of the topic, the basic ideas of scaling in WAS ND boils down to the fact that a workload is deployed to a cluster, and you can put more horsepower to a workload in a few ways:
Historically in WAS ND, these are not automatic or dynamic activities. Performing any of the above actions, even if scripted, likely required a change ticket and some planning before the WAS admins could do anything.
A small detail that will become pertinent later is to restate that each particular workload (application) is deployed to a particular cluster. That cluster “exists” only where the cluster members (server JVMs) exist. Please forgive the statement of the obvious, but this means that the workload does NOT just run anywhere in the cell, on any available node, wherever capacity may be. This point will later be compared against pod placement in OCP and the general approach Kubernetes uses to schedule work. The last touchstone we’ll mention here is that security has always been a priority in WAS ND, but it will become a more detailed, granular, and unavoidable priority in OCP. In WAS ND, a lot of security configuration, such as user registry, was done at the cell level.
Simplified overview of WAS ND — Applications View
Now let’s focus on the applications that run in the WAS ND environment.
The application code that is deployed is packaged in EAR and WAR files. This is essentially a zip file with a lot of metadata, compiled code, and some exposed bindings so that when the EAR or WAR is deployed, the admin can tell that application how to look up and find the specific runtime resources it needs from the available scopes of JNDI namespace.
Head’s up: the “namespace” concept is different and more developed in OCP, and we’ll get to that when we talk about OCP. In WAS ND, namespace is more commonly thought about in terms of “scope”, as in the cell, cluster, node, or server scope at which a particular resource can be shared.A single business app may utilize several EAR and WAR files. Each cluster may be the deployment target for one or more applications.
There are many reasons for choosing to deploy applications to shared or separate clusters, including the three mentioned in the table below:
When considering the eventual decommissioning of each cell, all of the remaining applications in each cluster will need to have been first redeployed to new OCP targets. Specifically, this means that the host VMs cannot be reclaimed until all of the applications from a cell are gone.
Applications generally need other things to function properly. Some need to be able to communicate with databases. Some need to be able to communicate with JMS providers, such as MQ. The WAS admins create runtime resources, such as datasources to point to databases, or Queue Connection Factories to point to MQ. As mentioned earlier, when you deploy the applications, one of the steps of app deploy is to tell the application how to look up the specific datasource or QCF that it needs (aka, the JNDI name of the resource).
This means that the application developers don’t know any environment-specific details about the configuration of the resource that the application needs. They basically just expose a way to ask for the resource later, while sticking to the standard APIs as they write the application code.
A side note: the act of the WAS ND application developer exposing a way to ask for a resource later, but then forgetting to actually tell the runtime admin any details about the resource (or its QoS requirements) is a terrible, and terribly common, practice. This is an area in which the runtime admin will appreciate the improved practices ushered in via pipelines and practices in OCP.The exact same EAR file could be deployed to many different environments, and the WAS admins would just have to ensure that the runtime resources (datasource, QCF, etc) were created and available in the target environments. Keeping track of the resources defined in the WAS ND environments is not trivial, and requires skill and coordination at a number of levels:
- coordination with the app developers to ensure what resources are needed by which apps
- ensure that the resources exist so that the app deployments can succeed
- develop the skills necessary to create these resources and understand the many parameters of each
- ongoing tuning of resources
- understanding if the resources have any involvement when troubleshooting problems
- cleaning up (deleting) the resources when no longer required (ie, the app has been removed)
Earlier in this post, it was mentioned that each “profile” writes some information to a file system, and that some of that information is configuration details. In a WAS ND environment, there is a large “configuration tree” of resource definition files. The Deployment Manager is the administrative center of the cell, and therefore the Deployment Manager’s copy of the config tree has all files. Each node profile’s copy of the config tree contains only the files that are pertinent to that node. When you have opened a support ticket to IBM to work on a WAS ND problem, some of the must gather information most likely included configuration data copied from the Deployment Manager’s copy of the config tree.
The information in the configuration definitions is scoped. There is a resources.xml file at each scope (cell, node, cluster, server). Resources defined in the cell’s resources.xml file can be found by anything in the cell. Resources defined in a particular server’s resources.xml file can only be found by that server.
Another type of file is a server.xml file, which describes a JVM. Each cluster member’s JVM contains many details that eventually require tuning as per the workload running on them. Most commonly, this is the Java heap setting, but in traditional WAS ND this also includes things like various thread pools and timeout settings. The server.xml file exists only at the server scope.
Peeking ahead: The server.xml file continues to be important to Open Liberty images. In addition to performing the traditional server definition that you're familiar with from WAS ND, Open Liberty's server.xml has evolved to additionally include definitions that we associate with other WAS ND files, such as resources.xml, security.xml, and binding XMLs.This was an extremely simplified overview of WAS ND. A number of breadcrumbs have been sprinkled throughout in order to help relate to details in the upcoming OCP overview.
One takeaway from the WAS ND overview is that this is older technology. Most of it is automatable and scalable, but maybe not quite in the way that you’d hope, especially from today’s perspective. It definitely requires quite a bit of time, dedication, and WebSphere-specific skill.
Summary of WAS ND
The overview in the preceding pages was not brief. Some of the main points are arranged in the tables below.
Coming up next…
In Part 3 of this series, we will overview basic terminology and concepts in OCP. This overview will roughly parallel the touch points from this WAS ND overview, so that you can start to see some relationships.
