Comparing RackWare RMM Against Virtual Machine Image Migration to OCI

Overview

At times, migrating to the cloud can feel like it's just too much of a hassle. With all of the moving parts that go into cloud migration and the valid concern of downtime, migration teams struggle with where to start and feeling overwhelmed. With the right cloud migration tools, there is absolutlely no reason to be worried or concerned. To help put your mind at ease, we've gathered a few things to consider when migrating to the cloud.

Points to Consider When Migrating VMs to Cloud

Migrating VMs to the cloud requires careful planning to avoid compatibility and cost issues. VM migrations are not a straightforward task in large enterprises with hundreds, or perhaps thousands, of applications and workloads, all of which may run differently in the cloud than they did on-premise.

Sizing VMs in Oracle Cloud

Oracle provides high power processing CPUs and designs the right sizing as per the available compute shapes and considering future growth. Also the cloud provides the flexibility to update the shapes on the fly

Application Migration Strategy

Apps should be organized into three broad categories:

• Easy to move
• Difficult to move
• Cannot be moved

1. Applications that are easy to move because they are relatively new, don’t have a lot of dependencies, have few or no licensing restrictions, and will adapt well to the scalability of the cloud.
2. Applications that are difficult to move because they aren’t tolerant to scaling, have more dependencies, or are subject to complex licensing restrictions.
3. Applications that cannot be moved due to compliance or licensing restrictions, or because they are older legacy applications that would require significant refactoring or a complete rewrite.

Migration Roadmap

1. Plan to migrate the applications sequentially and begin with a hybrid cloud model. It is easy to migrate the applications to cloud and retire the VMs on prem and switch to cloud VMs to host applications on the fly. Preparing a migration roadmap is very critical in the project so that the integrated systems are updated along with the migration.

Tools that Can Assist with the Process

1. Amazon Migration Services:
   a. Executes homogeneous and heterogeneous database migrations
   b. Performs continuous data replication for multiple use cases
   c. Can migrate data into and out of the cloud for development reasons
2. Azure Migration Services:
   a. Extensible and flexible to streamline your migration
   b. Integrate with tools for your workloads to help track and manage migrations
   c. Maintain compliance with your migrations
3. Carbonite Migrate:
   a. Migrate workflows between physical, virtual, or cloud-based environments
   b. Minimal downtime with almost immediate failover in case there’s an emergency
4. RackWare Management Model RMM:
   This offers a simple and cost effective solution for migration of workloads to the cloud. Key functionalities of RMM:
   a. Cloning of Production and Non Production Servers
   b. Incremental Synchronization
   c. Cloud to Cloud Migrations
   d. Physical to Cloud Migration
   e. Failover and Failback

Comparison Between the RackWare (RMM) and Virtual Machine Image (VMI)

Description of Comparison Points

Delta Sync

This means that the initial replication is non-disruptive to the origin system. The production server is still running uninterrupted while the replicated server is verified in the target environment. There is no technical reason to rush the verification as the RMM supports a highly efficient delta sync that can be done at any time. After the application verification the cutover window can be defined and only then should the applications be quiesced. So down time is at a minimum. And this process can be iterated if needed. Any number of delta syncs are easy to do. In contrast, the Image import requires lengthy downtime. The downtime starts as soon as the Imaging is started, and downtime continues through testing and cutover.

Question: Why is delta sync important during a migration? Why not just take the image and shut down the on-premise environment when it is moved to OCI?

Migration of projects are usually associated with application downtime, data loss, and diversion of internal resources from strategic initiatives. Many customers have in-flight projects during the migration process so it is not ideal to abruptly shut down these systems and migrate them to OCI. Delta Sync features of the RMM tool is highly recommended in such a scenario.The initial migration can happen when the on premise system is fully functional.Using the Delta Sync feature, only the changed parts of the files can be synced during the final migration phase. This drastically reduces the application downtime and makes the transition to cloud a smooth process.

Scale and Concurrency

The RMM can handle multiple replications, syncs, and cutovers all at the same time. It's common to want to replicate, test, and ultimately cutover servers together as an entire application. The RMM is designed to do this with the ability to define groups of servers and perform operations all at the same time or in a specific sequence. In contrast the Image import in OCI is largely single threaded with no support for waves, application affinities, or scheduling sequences. As an example, there can be many multiple servers that are part of the migration to cloud. These servers share similar network topology and can be grouped together as batches. A common migration template can be shared with this group. This helps to scale the task and have a common repository to monitor the progress of migration of the batch. For example, in the Peoplesoft ERP system, the web servers, application servers, process servers, and files servers can all be a part of a batch and can be migrated to the cloud simultaneously as a single batch.

Report Generation

Often migrations require reports for compliance or audit reasons. Image import has little or no report structure, and certainly nothing that would pass an audit or compliance test.

Overcoming VMDK Conversion Limitations

The RMM provisions a VM (or physical server) in the Target environment in the correct, most recent Machine Format for that Cloud or Target environment. Often the VMDK conversion process is limited even for simple servers. Certain limitations being -

• You must power off source virtual machines before you convert them.
• When you convert a virtual machine with snapshots, the snapshots are not transferred to the destination virtual machine.
• When you convert Linux virtual machine sources.

1. Only disk-based cloning is supported for Linux guest operating systems
2. Configuration or customization is not supported for Linux guest operating systems.

Migrating to the correct, most recent Machine Format ensures the VM runs at optimal performance in the most efficient manner with less layers of virtualization.

The RMM can also be configured to support converged DR and backup after the migration. in fact, it's far simpler after a migration as all the tooling is already in place.

Hostname and IP Addresses Migration Flexibility

By default the RMM retains the hostname as part of the replication and will automatically update the IP addresses as part of the replication. The RMM allows the modification of hostname as an option and IP addresses can be kept the same (as long as the subnet is supported by OCI for BYOIP.

Conclusion

In summary, the RMM is a highly automated product with options to handle the more difficult elements of a migration in a way that avoids human error and facilitates proper verification and cutover.

To learn more about about Disaster Recovery on Oracle Cloud click here or schedule a meeting with an Astute DR expert.