Instant Cutover for High-Availability Legacy Workload Migration Using AWS Outposts, CloudEndure, and Stromasys

By Luis Ramos, EMEA Field Engineer – Stromasys
By Didier Durand, Sr. Mainframe Architect – AWS
By Kevin Yung, Sr. Modernization Architect – AWS
By Rohit Darji, Sr. Modernization Consultant – AWS

Stromasys

Numerous legacy workloads, still hosted on premises, are mission-critical and hardly interruptible. Their migration to Amazon Web Services (AWS) must happen quasi-transparently for their users.

This post details how the combination of AWS Outposts and CloudEndure can be used to solve for this issue.

We demonstrate this by migrating a Solaris machine making use of the Charon SSP emulator by Stromasys, running on standard Amazon Elastic Compute Cloud (Amazon EC2) instances, and using CloudEndure. The approach provides a riskless and fluid migration to AWS of sensitive applications with cutover reduced to seconds.

Stromasys is an AWS Partner that helps address customers’ data center modernization needs by allowing the movement of legacy system applications and data to x86 infrastructure without changing any legacy code or data.

Stromasys Charon software emulates legacy SPARC, DEC, and PA-RISC systems, thus freeing critical legacy applications that had been tied to such platforms to run on modern cloud infrastructure.

Business Need

In the financial services industry (among others), many key workloads still run on legacy servers like Solaris. Enlyft reports than 6,000+ organizations use Solaris. Similarly, 15,000+ organizations still run applications on HP-UX. Many of those organizations currently target migration to the cloud.

AWS Partners like Stromasys provide hardware emulators for legacy servers, running as standard Linux applications to allow the efficient rehosting of Solaris applications to AWS.

Through a classic lift-and-shift, the operating system, its utilities, application programs, and customer data are moved as-is to an Amazon EC2 instance. The Solaris application can be restarted in its original legacy form and executed by Charon without any recompilation or code/data changes.

Stromasys offers its Charon product directly on AWS Marketplace to help organizations execute lift-and-shift for legacy VAX, Alpha, PA-RISC, and SunSPARC systems.

Figure 1 – Virtualization of legacy hardware with Charon.

The move to AWS usually requires the transfer of dumped disks of the original legacy machine to the AWS data center. For low-criticality workloads, the dump, transfer, and restore is achieved via AWS Snowball.

Snowball provides a secure, cost-efficient, and large-scale data transfer between the customer’s on-premises environment and AWS. However, the physical transport of the Snowball device incurs significant delays (hours to days) before the restoration is complete and the application can be restarted on the cloud EC2 instance.

This long service interruption is not acceptable in some stringent operational contexts.

CloudEndure Migration combined with AWS Outposts provides the right solution to deliver a de-risked, seamless, and transparent migration to the AWS Cloud.

High-Level Migration Concepts and Process

The essence of the solution is to leverage the replication of the Amazon EC2 Linux filesystem by CloudEndure Migration, which provides an indirect and transparent way to clone (with high fidelity) the legacy storage accessed and managed by Charon.

This replication is transparent to the hardware emulator and its rehosted operating system, application workload, and data.

Figure 2 – Gradual cloud migration of Solaris workloads with Charon.

The first step of the process is to install a transient AWS Outpost machine for on-premises staging. Charon and CloudEndure Migration will be installed on the Outpost machine, and the origin machine restored to it.

As the origin machine and the Outpost are located on the same LAN segment, the restore and restart on Outpost happens quickly. When prepared with an initial restore and done at the proper moment of low-activity using differential copy mechanisms, the switch from on-premises legacy to on-premises EC2 on AWS Outposts can be very rapid.

The switch from one to the other can even be made imperceptible via host-based Solaris replication mechanisms, which are beyond the scope of this post. The legacy machine can be decommissioned when the Solaris application has been successfully restarted on Charon and secured via EC2 instance snapshots.

As a second step, CloudEndure Migration is activated on the Outpost-hosted EC2 instance. It works at the disk level—each time a disk block is modified, the CloudEndure Migration agent will capture it and transfer the disk block over the network to the target EC2 instance where an exact clone disk will be reconstructed.

When the initial replication happens for gigabytes of data corresponding to dumped disks, the network traffic is heavy. The duration of this initial cloning can be reduced by the use of AWS Direct Connect, which allows private connections up to 100 Gbps between customers’ on-premises environments and the AWS Cloud.

When the initial replication is complete, the network traffic reduces and is limited to the data effectively changed by the application. The CloudEndure Migration agent replicates the modified data blocks in real-time over the network to the target EC2 instance.

Through this process, a clone of the on-premises machine is kept up to date on AWS. A proper transition can be managed using the Amazon Route 53 DNS service to switch from the source machine to cloud transparently.

From this point, CloudEndure Disaster Recovery can be leveraged to clone the migrated machine in real time to another AWS region so it can restart in minutes in case of failure in the primary region.

Before the cutover, some snapshots of the EC2 machine can be taken and restored on validated EC2 instances to allow thorough testing and ensure a seamless cutover.

After the cutover has been executed, the on-premises Outpost can be decommissioned. For each source server that has to be migrated, CloudEndure Migration can be used for a free period of 2,160 hours, which represent 90 days when used continuously.

This extended free use gives customers enough time to safely execute the migration to AWS. After this period, further use gets charged $0.042 per server (as of prices at day of publication).

This multi-step and gradual migration process allows for a safe trip to the cloud for legacy and critical workloads. This solution also works for partitioned machines hosting isolated Solaris Zones. The following section details technical insights and lessons learned in such use cases.

CloudEndure Migration Setup and Test

Step 1: Create Migration Project in CloudEndure Migration

To start a migration, the customer needs to create a migration project in the CloudEndure Migration console. In the project, specify the source and target to be AWS regions.

As shown in the screenshot below, our test environment is configured to use CloudEndure Migration to migrate servers within the same region us-west-2.

Figure 3 – CloudEndure project setup and info.

When creating a CloudEndure Migration project, customers need to prepare an AWS Identity and Access Management (IAM) user credential using the recommended IAM permissions. The example of the policy can be downloaded via the documentation.

Step 2: Configure CEM Replication Settings

Once the migration project is configured, customers need to set up the replication settings in the CloudEndure Migration console.

In our test environment, we’ve chosen the source and target as the same region, which simulates migration from an Outpost (as a region’s extended zone) to the same region’s AWS Availability Zone (AZ).

Figure 4 – CloudEndure replication settings.

In the next settings, we selected a replication subnet that’s in a normal AZ. This means the replication server will be deployed in AWS regions to replicate migrating EC2 instances from simulated Outposts.

Step 3: Install CloudEndure Migration Agent on Source Instances

To install the CloudEndure Migration agent on the Stromasys Charon SSP EC2 host, an out-of-the-box Linux command from the console is used.

In the CloudEndure Migration project, select the Other Settings tab, and select the How to add machines link. It provides instructions how to install the agent to a Linux machine.

Figure 5 – CloudEndure agent installation command line.

Step 4: Test Cutover to AWS Region.

When the CloudEndure Migration agent is stalled correctly, the console will display the source machines connected and that the replication is in progress.

Figure 6 – CloudEndure replication logs.

When CloudEndure Migration has completed the initial replication of the source machine, it enters into continuous data replication. In our example, the following image shows that two SPARC Servers on Charon SSP emulators are in this mode.

Figure 7 – CloudEndure replication status.

Once the server is in the continuous data replication state, we are ready to test the migration. We configured the blueprint of the target instance, and in the configuration we selected a different subnet of the virtual private cloud (VPC) from the source instance’s subnet to simulate a migration from AWS Outputs to an Availability Zone.

Assuming a server migration can use a new IP address, in the blueprint we choose to create new private IPs for the target instance. In a real migration scenario, customers will use a runbook and scripts to manage IP changes and DNS updates in the integration points.

In the test environment, the emulated SUN SPARC servers are using multiple Network Interface Cards (NICs). CloudEndure Migration automatically created the same number of NICs in the target server as on the source server. It’s a best practice to configure compliance tags for the target instances in the blueprint so you and the administrators can identify the migrated target instances from the AWS console easily.

When the blueprint is ready, you can launch the target instance in TEST mode. CloudEndure Migration will catch up on any data block changes from the source server and take a snapshot of the replicated Amazon Elastic Block Store (Amazon EBS) volume. It then creates a target server as configured in the blueprint.

Step 5: NICs Mapping Changes in Charon SSP Emulator

During the migration, new NICs are created in the target server. The NICs configuration in the Charon SSP emulator needs to be updated in order to map the new Interface and MAC address to the SUN SPARC guests.

In the Charon SSP manager, we selected the Ethernet setting and configured the interface to use the newly-created interface and associated MAC address.

Figure 8 – Stromasys Charon-SSP manager settings.

The process of substituting network interfaces and MAC associations is also applicable to the SUN SPARC servers that host Solaris Zones. In this case, customers will need to update the zone configuration to use the newly-created NIC.

The process to update Charon SSP manager settings can be done automatically by using Charon SSP configuration files and running post migration scripts to substitute values in the config file. In the case of migrating SUN SPARC servers with Solaris Zones, you can use Linux tools like Expect to script the Solaris Zone config changes.

While we explained the NICs mapping update above, you also need to consider that, during a launch of a test server, it will consume one license from the Stromasys license server. Because of this, during the migration, it’s recommended to contact Stromasys and prepare additional licenses in the license pool for migration.

On the other hand, when migration is completed, the number of Stromasys licenses can be reduced to the same number it was running in AWS Outposts.

Summary

This post has presented why and how some mission-critical legacy workloads can be transparently migrated to AWS with service interruption time close to zero when cutover moment is adequately selected.

The proposed process combines various technologies to value-added outcomes. The migration will in most cases generate savings when compared to the initial on-premises installation. More importantly, it will mitigate the risks created by ancient hardware, no longer supported by suppliers in some cases.

Finally, as first step as a transformation journey, this initial rehosting on the cloud usually increase the efficiency and speed of further gradual modernization.

.

.

Stromasys – AWS Partner Spotlight

Stromasys is an AWS Partner that helps address customers’ data center modernization needs by allowing the movement of legacy system applications and data to x86 infrastructure without changing any legacy code or data.

Contact Stromasys | Partner Overview | AWS Marketplace

*Already worked with Stromasys? Rate the Partner

*To review an AWS Partner, you must be a customer that has worked with them directly on a project.