We, here at The Virtualization Practice, are getting ready to have a cloud presence. Since we ‘eat our own dogfood’ with a 100% Virtual Environment, we are gearing up to move some of those workloads into a hybrid cloud. We already use some cloud resources, but now is the time to look at other workloads. Why we are moving to the cloud is three fold: how can we write about various aspects of being a tenant in the cloud, if we are not one; a recent power outage at the grid level; and a upcoming data center move. Two of these reasons are all about business continuity with the first being what we do. While we already have a cloud running within our own environment, it is time to branch out.Before last weeks OpenStack Conference, I would have said our choices were fairly slim and that we had to look for a VMware vCloud provider as we are 100% virtualized on VMware vSphere with Hyper-V, Xen, and KVM in our test lab. Now I am not so sure. It is possible to run OpenStack on top of vSphere and if such a cloud existed it would definitely be considered. However, we want a hybrid cloud and while the future is bright for cross-cloud interoperability, the fact is, the hypervisor in use still matters.
OpenStack clouds are built either upon KVM or Xen. This open source route will save on funds when creating a cloud, but does nothing to aid in the ability to move workloads into and out of the cloud when the enterprise is running anything besides KVM or Xen. OpenStack is actually in a very good position to provide a way around this, how you may ask?
OpenStack could implement the following set of additions and projects:
- Create a Replication Receiver project which would allow OpenStack infrastructures to replicate to and from other OpenStack implementations regardless of hypervisor. This replication receiver codebase would either do the virtual disk conversion during replication, or
- Glance should be updated to either convert virtual disks on the fly before they are launched, or
- Create a translating filesystem that does all the work for the hypervisor during boot.
While the virtual disk contents would not change, it is the container around those contents that would need to change as well as the meta-files that define the virtual machine. Unless of course VMware, Microsoft, and the Open Source communities can define a common file format that could be used. Ideally, this should be the approach and we are working towards that with OVF. Unfortunately, OVF is just a transfer format, not a run-time format. So we are left with translation requirements.
Why is this important?
Because the obvious way to migrate to a cloud is to setup replication to move all the data into a tenants cloud instance over time and to keep it in sync until the cut-over is ready. Use of replication as a migration tool would:
- ease migration to the cloud
- ease migration from the cloud
Why? For business continuity and data protection reasons. Once in the cloud, organizations may choose other options, but getting to the cloud when you have terabytes of data to copy is not instantaneous and will take time, time when the servers and workloads need to be running. So, for an enterprise, replication receiver clouds are a must. This would definitely have provided business continuity for our own recent disaster.
Once in the cloud, we may decide to stay there and fore-go our own datacenter as just a test lab, but getting there easily and running our workloads efficiently is crucial to the successful migration to a hybrid cloud. Is OpenStack a contender? I think so, but we will have to wait for the RFP to be finished and sent out. We will make our RFP public (by adding another tab at the top entitled Cloud RFP) as well as our results, designs, and architectures. We will start with our requirements and move from there.
How would you move to the cloud? And what clouds?
Share this Article:
Latest posts by Edward Haletky (see all)
- Anti-Ransomware: All About Architecture - May 22, 2017
- Educate, Upgrade, Patch, or Else.. - May 15, 2017
- Software-Defined Storage for Containers Ignores Storage - May 9, 2017