Trilio's Approach
Last updated
Last updated
Trilio’s backup and recovery solution is an OpenStack native service similar to Nova, Cinder, Glance, etc. This software-only solution can be deployed using OpenStack distribution-specific DevOps scripts. For example, Trilio’s solution is native to the RHOSP platform and can be deployed and managed using Red Hat Director.
We extended Trilio’s architecture to support migration at scale. Since Trilio migrates the VM from VMware ESXi to the OpenStack compute node, the solution scales with your VMware/OpenStack without suffering from performance bottlenecks.
The process of migration usually involves moving virtual machines from a source platform to a target platform, however, the strategy to achieve this should be considered carefully.
If the migration process is initiated from the target platform, it is called inline migration. Trilio advocates inline migration as it helps map organizational structures such as data centers/clusters/folders in VMware to regions/domains/projects in OpenStack.
A project owner with sufficient privileges to their VMware resources can migrate the VMs to their project. If every project owner can migrate their resources from VMware, it provides better control to cloud architects to orchestrate the migration.
If the migration process is initiated from an outside source or target platform, it is called out-of-band migration. Out-of-band demands a centralized approach and places constraints on how cloud architects can design their OpenStack clouds.
A very intuitive tenant dashboard for the tenant to manage their migrations. If you want to migrate to KubeVirt, Red Hat’s MTV solution can be helpful.
The sub-commands for the migration feature are available as:
Migration APIs look and feel like OpenStack API. Each tenant can source their cloud rc and start using migration cli commands. CLI also helps users to extend their Ansible scripting for migration.
Trilio migration functionality supports three types of migrations
Dry-run lets users create the VMs on OpenStack with storage volumes, networking, and security groups attached. It does a migration of VM data from VMware to OpenStack by taking a snapshot of the VM without shutting it down and hence, does not guarantee the data/application consistency. Unlike Cold and Warm migration, there is no disruption to the VMware VMs during this migration. It is a handy feature for users to test VMs and their interconnectivity before completely migrating VMs.
Cold migration shuts down the VMware VMs and migrates the VMs to OpenStack. Depending on the size of the data to migrate, cold migration can take minutes to hours to complete, and during the entire duration, the applications are unavailable. Cold migration is more disruptive than warm migration.
Warm migration leverages VMware snapshot and the Change Block Tracking functionality to migrate VMs with less disruption. It first takes the VM snapshot and copies the full snapshot data to OpenStack. Depending on the size of the data, this upload operation may take a few minutes to a few hours. During this period the VM may have written a few more blocks of data, which then gets uploaded by taking a second snapshot of the VM. It then shutdowns the VM, takes another snapshot of the VM, copies the blocks that were changed since the last snapshot, and reboots OpenStack VMs. So warm migration incurs less disruption compared to cold migration.
Trilio's support for migrating VMware VMs to OpenStack is recognized as an industry-leading solution. Its scalability and ability to be deployed organization-wide scale make it a valuable choice for businesses. The self-paced approach provided by Trilio allows application owners to experiment with migration options and gain confidence before performing the final migration. In the context of businesses transitioning from vendor lock-in to open-source technologies, Trilio's migration feature can be a helpful tool in accelerating the transition process.
