There are many reasons organizations should be getting serious about modernizing their mainframes, including aging technical resources, getting rid of high MIPS costs, eliminating non-strategic platforms and gaining critical on-demand scalability, security and innovation. As one of the leading cloud providers, AWS, in conjunction with mLogica, offers a number of key advantages to private and public sector organizations looking to consolidate legacy workloads. These include access to AI, machine learning (ML), advanced analytic tooling and more.
However, the migration of mainframe environments, which typically host mission critical applications, is highly complex, requiring an in-depth assessment of the existing system followed by an end-to-end migration strategy with automation at its core. Why? Because automating the bulk of repetitive code conversion dramatically slashes timeframes and budgets—and virtually eliminates costly delays caused by human coding errors. A proven example is mLogica’ LIBER*M Mainframe Modernization Suite of automated software, which has been successfully employed globally to accelerate mainframe migrations to AWS cloud.
Migrating a mainframe environment to the AWS Cloud involves designing a target architecture that leverages AWS services to replicate or enhance the capabilities of your existing mainframe applications and processes. The specific architecture will depend on your organization's unique requirements, the nature of your applications and your modernization goals, both now and into the future.
There are a host of key technical decisions involved in replatforming a mainframe workload to AWS. To illustrate a best-practice strategy, this blog will detail a use case that comprises a typical set of mainframe system workloads, such as:
In this use case our objective is to serve the workloads from AWS in a single region using native AWS services wherever possible, including EC2 for compute and Aurora for the database. These workloads should be functionally equivalent and performance should be equivalent or better. The replatforming should have a minimal impact on end users; ideally, they would not need to be aware of a transition.
The replatformed system should also meet critical non-functional requirements, in particular:
Despite the general high reliability of AWS, it is crucial to plan for service interruptions isolated to a single availability zone. For this example, we will focus solely on high availability.
NOTE: In a future post, we will enhance this use case solution to address disaster recovery.
In designing a solution to replatform these mainframe workloads to AWS, we will address three areas:
For most workloads, mLogica’s automated LIBER*Z replatforming stack, a module of our LIBER*M Mainframe Modernization Suite, meets all requirements and offers excellent value.
LIBER*Z provides mainframe-equivalent transaction and batch frameworks and further integrates with an enterprise LDAP server like the AWS Active Directory service to provide federated security. With the support of other LIBER*M refactoring tools, LIBER*Z also has several other key features that distinguish it, including:
To inform the architecture, we determine the workload requirements for compute, memory, storage and database. For compute, a general rule is that for every 50 MIPS a workload consumes on an IBM z/OS mainframe, the replatformed workload will require 1 vCPU on AWS. This offers a starting point for narrowing the choice of an EC2 instance type.
However, since most storage on AWS is network-attached, including both EBS and EFS, the network interfaces on EC2 instances need to have adequate bandwidth to support the I/O load. For a discussion of the advantages of different storage services in a mainframe modernization context, see this related AWS blog, as well as AWS documentation that presents the IOPS potential of different instance types.
For memory, a good starting point is 4GiB of RAM per vCPU, the standard ratio in m-class instance type, to be adjusted based on testing with the actual workload. If testing shows the workloads only use 2 GiB per vCPU, AWS makes it easy to change instance types, which also optimizes cost.
Storage requirements depend on the system’s use of files on mainframe DASD for interfaces and intermediate processing. A comprehensive assessment of the existing system is required to make this calculation—in this use case, one that takes into account that VSAM in particular will move to relational tables. Also, in this use case we are assuming the workloads require a maximum of 100 GB of file storage.
Migrating to AWS offers multiple relational database alternatives. In business cases where there is a requirement to align with a commercial database, AWS provides options for both Oracle and MS SQL Server.
In the absence of such requirements, Amazon Aurora for PostgreSQL is a popular relational database choice. PostgreSQL offers solid power and performance, and the Aurora service handles the heavy lifting of database administration, patches, backups, replication and upgrades reliably and with less effort than other options.
Since AWS Aurora spans availability zones within a region, it’s also well suited to meet the high availability requirement of this use case. Aurora will allow the solution to have a primary instance in one availability zone and a read replica in another to ensure fulfillment of the high availability mandate. In the event of a failover, the read replica will be automatically promoted to the primary instance.
In terms of sizing, AWS Aurora Serverless expands and contracts processing and storage automatically based on demand within a defined range of Aurora capacity units (ACUs), with testing to indicate the appropriate production range. In this use case, as a starting point we will provision 1 TB of Aurora storage and a range of 4-32 ACUs of processing power.
Having established these building blocks, we can now lay out a hypothetical architecture and estimate the AWS costs. For this exercise, we will focus on the production environment only, however in most cases a system will also require at least two additional non-production instances for development and testing. The mLogica reference architecture for this approach relies on EC2 instances sized for the workload, an Aurora Serverless multi-availability zone cluster and EFS storage shared across availability zones.
For compute, the best starting point at the time of writing is a primary EC2 instance of type m7i.12xlarge in one availability zone (AZ) of the chosen AWS region, with an identical instance in a second AZ to meet the high availability requirement. This instance type provides 48 vCPUs, or roughly 1 vCPU per 50 MIPS (equivalent to one physical core per 100 MIPS) and 4 GiB RAM per vCPU, which is aligned with the LIBER*Z starting point benchmarks.
The mLogica migration team may recommend a change to the instance after testing with the actual workloads. Each instance is configured with minimal EBS storage for the Linux operating system, LIBER*Z and the deployed code.
To guarantee high availability, we will configure AWS CloudWatch to instantaneously detect any loss of availability of the primary instance. This would immediately initiate failover by promoting the Aurora replica in the failover availability zone to be the primary read/write database, redirecting traffic to the failover EC2 instance using AWS Route 53.
The architecture also includes a server for mLogica’s LIBER*IRIS Mainframe Data Modernization Suite, which will be used to migrate mainframe data to AWS Aurora and EFS. LIBER*IRIS generates extraction and transfer scripts on the mainframe to upload the data to EFS, as well as scripts on EC2 to load the data from EFS into Aurora.
A key feature of this approach is that the mLogica team will never require access to production data, as the scripts generated can be run by the customer. The LIBER*IRIS EC2 instance will be deprovisioned once the replatformed system is in production.
NOTE: In a future post, we will provide the details of this data migration process.
This reference approach to replatforming a mainframe workload to AWS provides a baseline that is easily augmented to meet any additional client requirements. In an upcoming blog we’ll examine how utilizing DevOps best practices accelerates mainframe modernization projects while mitigating risk.
Migrating mainframe infrastructure to the cloud requires expertise, top-flight automation software and proven methodologies. Engaging with mLogica’s AWS cloud migration and automation specialists can help ensure a seamless transition that quickly maximizes the benefits of migration for accelerated ROI.
Want to learn more? Contact us