vMotion is a fantastic capability provided by VMware to VMware environments, but what if you’re not using VMware? Or what if you’re using VMware on-site, but would like to rehost the workload into a public cloud provider such as Amazon or Azure? It’s not yet possible – without third-party tools – to move a workload from the VMware host to AWS. In addition, what if you are using VMware on both sides, but the health of your systems are such that running vMotion is not possible?
DH2i felt this was the problem that needs solving – workload mobility and availability. DH2i first tackled this problem by providing high availability and disaster recoverability for SQL Server workloads on Windows. Its most recent announcement brings similar functionality to other operating environments, including Linux and Docker containers.
Fixing The Problem
The idea is simple. Install the DH2i application on any of the servers in the environment where you wish to be able to move workloads, and you can easily rehost the workload between any number of different bare metal machines or VMs. VMs could be any kind of VMs, including VMware, Hyper-V, and AWS – even a physical server somewhere. The product works at the instance level, and is completely agnostic to the underlying infrastructure.
For example, it can easily move a SQL Server workload from one Windows machine to another, or from one Linux machine to another whether that “machine” is a VM in VMware, an AWS VM, or a physical machine. The same is true of workloads running in Docker containers. These instance or container movements can be initiated manually or completely automated based on the health or performance of the workloads or servers in the environment.
Room For Development
DH2i’s software currently relies upon shared and/or replicated storage The product does not yet actually replicate the data between the servers they are protecting. Just like vMotion, DH2i counts on the customer replicating the data using storage-level or OS-level replication. Its job is to orchestrate all of the complicated processes that happen when one moves a workload from one server to another. DH2i even claims to be able to migrate workloads from one machine to another without changing the connection string to that workload. This requires, of course, addressing problems like managing IP addresses, registry components, and hostnames – all without clients noticing.
The main limitations in the DH2i product come from the limitations of the underlying infrastructure. For example, the product cannot move a SQL Server instance from Windows to Linux. The same is true of workloads in Docker containers. As long as you are moving a Docker container to a host with the same OS type—either Windows to Windows or Linux to Linux—everything should be fine. But since there are still differences between containers on Windows and Linux, it is not possible to migrate workloads between those two, either.
We’ve barely touched on the scenarios under which one would want to move a workload from one system to another—including various scenarios for automatic moves such as HA, disaster recovery, or changes in resource utilization. The people at DH2i are able to describe many such scenarios, many of which are not possible using tools such as VMware’s vMotion. Anything that makes it easier for customers to move workloads between heterogeneous environments is something that IT professionals should consider.