Virtualizing onto mainframes: How to make it fit

The flexibility, efficiency, and reduced cost of ownership virtualization provides makes it extremely compelling to large and small organizations alike, says CiRBA's Andrew Hillier.
Written by Andrew Hillier, CiRBA, Contributor on
Commentary--The flexibility, efficiency, and reduced cost of ownership virtualization provides makes it extremely compelling to large and small organizations alike. Increasingly IT organizations are contemplating virtualization across all platforms.

As this trend makes its way deeper and deeper into the data center, organizations are starting to leverage the fact that virtualization also lifts many of the constraints that govern which platform an application needs to run on. Different types of applications possess different workload “personalities” and these heavily influence how well an application will perform on a given virtualization model.

Some workloads possess certain characteristics that make them ideal for consolidation on to mainframes. In this article I’ll discuss these characteristics as well as the overall process for analyzing existing IT environments to determine the optimal approach to consolidate workloads onto the mainframe platform.

Analyzing workloads onto mainframes
Partitioning, hypervisors, containers, and other approaches can all be used to allow workloads to co-reside on a common platform. Given the relative strengths and weaknesses among platform classes, a considerable amount of diligence is required when consolidating workloads between them. This involves understanding which applications will run on the mainframe, which applications will experience the most benefit by moving, and what they will look like after the transition. In practice, it’s even more important to understand the subtlety of such a transformation, particularly when the overall goals are to optimize the benefit while at the same time to minimize the risk.

By modeling transformations in terms of the constraints that govern them, it’s possible to chart a course that reaches the end goal while not going off side in the process. These constraints can be classified into three categories:

1. Technical Constraints--what can go together
2. Business and Process Constraints--what should go together
3. Workload Analysis--what fits together

Technical constraint analysis
Technical constraint analysis generally deals with compatibilities and affinities between hardware and software components. What can run on what, what talks to what, etc. For mainframes, this step is concerned with what applications will work on the mainframe, which will accrue the most benefit by moving, and how they should be organized to optimally leverage these benefits.

• Hardware and software compatibility
In addition to understanding what applications talk to one another and which have an affinity or aversion to one another, it’s also important to understand how the applications and their usage drive middleware to behave. Likewise, any cross-platform transition must take into account whether the source systems employ any specialty hardware such as token rings, faxes, and USB devices that may be difficult to move with them. If any of these things influence how the application is configured in the mainframe environment, it should be ruled out as a consolidation candidate.

• Network connectivity and latency
Any shifts in the topological location of an application may introduce changes in communication latency that can impact application performance. If the changes introduce latency in the wrong places, such as between application servers and databases, performance will suffer. This is why targeting applications whose databases are already on the mainframe is a good initial strategy.

• Application connectivity
Rather than just looking for applications that already talk to the mainframe, organizations should look for applications that talk to each other. By consolidating onto the same system, they can realize tremendous benefits by promoting “crosstalk” that doesn’t ever hit the network. A note of caution though: this strategy can sometimes bypass important network security controls, so collapsing application tiers and communication paths should be approached carefully.

Business and process constraint analysis
These constraints help organizations determine what can and cannot be done from a non-technical perspective due to regulatory requirements, internal politics, or other real-world considerations.

• Process-oriented constraints
The proper functioning of production IT environments often relies on tight process controls. Change freezes, maintenance windows and other controls must be respected, and any transformation of IT environments must take into account the rules that have been put in place.

This is good news for mainframe consolidation, as the mainframe platform had traditionally been subject to a level of process rigor that is only now making its way the data center.

• Security and regulatory compliance
To protect intellectual property and other sensitive information, many environments segregate data types and apply security and access control policies accordingly. Businesses should avoid virtualization scenarios that may cause any security vulnerabilities. Even if the security model of the mainframe supports policies that mirror the distributed environment, it may be more practical to try simpler approaches that don’t cross security zones and introduce potential regulatory or security challenges.

• General business constraints
Organizations are often resistant to sharing infrastructure between departments, partly due to the lack of chargeback models that enable cross-department hosting. Another issue that may impact virtualization is operational environments. Combining production and non-production environments on a shared infrastructure may not be desirable. Placing the unpredictable patterns of development and testing on the same system as critical production workloads requires a great deal if finesse, particularly with respect to workload management.

Workload analysis
One of the most challenging aspects of analyzing mainframe virtualization is the proper normalization of system utilization patterns. Because of the diverse workload personalities present in the data center, and the varying characteristics of the platforms themselves, getting the right answer is no easy feat. CPU utilization must be properly normalized and must take into account I/O rates, memory utilization, and context switching to ensure accurate results.

To compound this problem, many published benchmarks tend to steer clear of the high bandwidth, high synchronization segment of the workload population, necessitating the creation of specialized benchmarks that accurately capture the relative merits of the different platform classes. To put this in a different way, using standard integer benchmarks to normalize workloads between midrange and mainframe platforms simply will not give the right answer.

This problem is not unique to the mainframe – many virtualization technologies are plagued by the fact that proper benchmarks are either non-existent or only just emerging. In any case, what is required is a flexible benchmarking approach that allows different workloads to be normalized independently based on their specific personalities and the relative performance of the target platforms with respect to that personality.

• CPU normalization and benchmarking
Although the theory behind what makes a workload run well on a mainframe can be daunting, the practical approach to getting the answer is a little more straightforward. By employing multiple benchmarks that represent the relative performance of source and target systems for a given workload personality, it is possible to construct a single analysis that optimizes utilization across multiple source/target combinations in a single step. Each source workload is then able to be normalized independently based on its distinct personality, and the target endpoints (mainframe partitions) filled to capacity based on a reasonably accurate projected utilization. Although the advantages of this approach are numerous, the challenge becomes the determination of exactly what the personality is for each source workload. Fortunately there are some key indicators that can be used to separate out the different types of activity.

• I/O analysis Although one of the strengths of the mainframe platform is its I/O performance, it is still important to analyze the I/O characteristics of the source workloads. In any consolidation scenario it is desirable to combine workloads that dovetail in a way that promotes a balanced use of resources. Because of this, I/O constraints should be analyzed in parallel with CPU and other metrics in order to give a balanced result that makes optimal use of the target resources.

• Memory Analysis
Memory is often a deciding factor when determining how many applications can be virtualized onto a single system. Yet this can be tricky to analyze, as the truly memory requirements of an application are not always made evident by the physical memory in use on the system. Using the measured memory utilization to determine what can fit on a target will provide a safe answer but might require the use of more memory than is actually required.

Ultimately, all of these constraints must be analyzed together to determine the optimal paths to virtualization. When considering this array of constraints against a series of source and target servers, the analysis becomes a three-dimensional optimization problem.

Consolidating application workloads onto the mainframe platform is a great strategy to consider in many IT environments. By properly assessing the suitability of applications to consolidate, the results they will give, and the overall TCO of the solution, it is possible to uncover significant opportunities to simplify IT infrastructure, improve reliability, increase resilience, decrease power consumption and ultimately drive down the costs associated with servicing these workloads.

Andrew Hillier is co-founder and CTO of CiRBA. You can reach him through www.cirba.com.

Editorial standards