Double-Take is an excellent stack of migration, replication, and availability software owned by Vision Solutions. The product comes in many different flavors depending on your use case, such as Double-Take Move for one-time migrations using source-based licensing keys and Double-Take Availability to set up more permanent replication between servers to protect an application. I’ve personally used Double-Take Availability to migrate several hundred physical machines out of a co-location and into a private data center when I worked in the customer side with great success. It enabled me to quickly get virtual servers off the prohibitively high cost of monthly maintenance and then address platform migrations at a later date.

Oh, and a Physical-to-Virtual (P2V) migration of a GreatPlains (Great Pains) box on Windows Server 2000 that was permanently stuck in the “soon to be decommissioned but it never quite happens” status. 🙂

A few weeks back, Vision Solutions announced their next iteration with the release of Cloud Migration Center. This is a SaaS based front-end that abstracts away all of the Double-Take back-end infrastructure while also providing a slew of cloud source and target destinations for migrations, disaster recovery, and application protection. For those new to Double-Take, you typically install a Double-Take Console somewhere within an environment to add source and target servers, control replication, and monitor failover. With CMC, that’s no longer necessary – you use the web interface to perform all these tasks and gain visibility into the health, status, and controls of the product.

There are a few restrictions that are coupled with the release:

Source environments are limited to VMware vSphere and Amazon AWS.
Target environments are limited to Microsoft Azure.
Windows virtual machines only.

The benefit, however, is that the product is operational today and should include a greater choice in source and target environments in the future. I’m a fan of releasing a small number of working features to start, and then adding more features within quick iterations, rather than trying to build every bell and whistle into the initial release.

Contents

Configuring Cloud Migration Center

I asked the team for a handful of licenses so I could tinker around with the Cloud Migration Center interface. And, since I have environments in most of the major clouds, it seemed like a good idea to connect them into the CMC dashboard and see how they appeared.

I’ve added four environments to my CMC portal below: a source environment for both VMware vSphere and Amazon AWS, and two target environments within Microsoft Azure. This will allow me to perform migrations on my Windows VMs that live in either vSphere or AWS and move them over to Azure.

You can pass credentials to CMC to discover VMs in the source environment(s) or even set up a proxy server inside of a private vSphere deployment to circumvent NATs and reveal private IPs. Notice that my vSphere-WahlNetwork environment is using a proxy called JUMP1. This is nothing more fancy than the result of me logging onto my jump server, which is a small Windows VM I connect to via WinRM and RDP to get into the lab, and installing the proxy software. I then connected it to CMC as shown below:

Once a discovery has completed, a list of supported servers will appear in the Servers list of the dashboard. Servers that are missing the latest Windows Updates will flag a yellow bang, while other servers will simply show that they are ready to migrate. Note that my template is offline and thus has no details to share with CMC.

Preparing the Azure Network

If you’re like most folks, you’ve configured private IP addresses for your environment and are using NAT or a DMZ to access those services. If so, you’ll need to prepare your Azure subscription with a virtual network. Specifically, a site-to-site VPN is recommended, as it gives a clear way of defining a private address range that corresponds to the source server’s subnet range. In my case, I ran through the creation of a new site-to-site VPN between my Meraki MX60w and Azure.

While I don’t want to spend that much time on the Azure network portion, I would suggest reading these two documents if you’ve not worked with an Azure virtual network previously:

Once the virtual network gateway is online and connected to your VPN endpoint, the virtual network dashboard will change to green and data in / out values will be non-zero values.

From a network perspective, I’m using a split tunnel from my on-premises 172.16.0.0/12 private network to an Azure 10.0.0.0/8 private network. While using the entirety of the class-A private IP range is severely overkill, I didn’t so much mind because this was just a test. You’ll likely want to use a much smaller range.

The last thing I’ll share is the Meraki site-to-site VPN configuration.

Enable split tunnel mode to avoid sending all traffic across the VPN tunnel (which would be bad).
Toggle the “use VPN” to yes for any subnets that are hosting source VMs to be migrated via CMC.
Enter a name, the Azure virtual network gateway’s public IP address, the Azure private IP subnet range, and preshared secret key value.

The VPN link should come up in less than a minute.

Double-Take Move Migrations

Getting workloads into Azure is pretty simple and follows the logical workflow that anyone who’s used Double-Take Move will be familiar with. However, there are fewer steps because the target environment is a public cloud with a specific configuration. While I’m not going to walk step-by-step through all of the options, I will state that the options are fairly simple and live within a five step migration workflow:

Select the name and target environment for the server migration, including a few cut-over options.
Select the source servers. After this step, CMC validates that the Azure virtual network is available for the selected source servers. Otherwise, you’ll see a “no suitable locations found in target environment” error.
Choose a target VM tier and size based on public cloud sizing models, such as A1 or D4, along with a name for the service.
Pick a target virtual network, storage account, and temporary credentials.
Review a migration summary.

For my test, I chose a VM named CA1 and kicked off a migration into Azure. There’s a snazzy little mouseover available that shows every single step that the CMC engine will walk through in order to get the VM stood up in the Azure cloud. These all went off without a hitch.

Reviewing Azure’s virtual network dashboard shows data being received over the VPN as the Double-Take software synchronizes state between the two servers. Additionally, the new target VM is visible using an Azure private IP address (10.0.0.12)

Monitoring the Azure Target VM

What I thought was really interesting about this migration was how automated the steps were. For example, Cloud Migration Center even sets up the endpoints for the virtual machine. Below you can see that the target VM, CA1, has ports configured for three Double-Take entities.

I also enjoyed watching the VM swim along in the cloud, eating up replication bits from my home lab. 🙂

Thoughts

I’m pretty jazzed up about how slick the Double-Take Cloud Migration Center looks and handles. The interface is simple to learn and contains a wealth of migration details. Most all of the process has been completely automated away, making anyone pretty awesome at performing Double-Take migrations with little or no experience, thus lowering the bar for entry. And the entire process uses the same Double-Take Move licenses that you and I can use for on-premises migrations, so there’s no funky SKU to locate.

It would be nice if the CMC interface would be more specific about the “no suitable locations found in target environment” error when I neglected to configure a site-to-site VPN to Azure that included the lab subnet, although to their benefit this is called out as a requirement in the documentation. And I’m looking forward to being able to migrate to target clouds that aren’t specifically Azure, although that was a good cloud to pick based on the warp-speed momentum by which Microsoft has shown to be operating.

All in all, kudos to the Double-Take team!