Data Freighting across the Clouds (Part 1)

11. Nov, 2009 0 Comments

Compatibility, Portability, Interoperability

Imagine you’re a dock worker at the Port of Seattle in the 1950s having to handle hundreds of bushels of beans, halibut filets, and pallets of paint cans, all individually, and load them onto ships. It was costly and time-consuming labor.

Malcolm McLean of North Carolina is known as the innovator behind shipping containers. McLean’s work streamlined and standardized all aspects of global transportation—shipping, receiving, loading, unloading. Instead of dock workers handling (or stevedoring) cumbersome bulk freight, crane operators load containers onto containerships. An entire ecosystem for reliable, cost-competitive, and predictable delivery of goods was created, using established systems (trains, trucks, and ships).

In cloud computing, no such standard or ecosystem yet exists. An external cloud provider may have a very different application hosting infrastructure than your local IT organization. Thus, relocating applications and associated data sets from your local facility to a cloud provider (or vice versa) may be costly, or not worth the effort.

Um, so I need to rewrite my app to deploy in your data center?

One aspect of this problem is platform-related. If your app is written in one language for one platform, chances are it won’t easily “just run” on another. Most applications have been carefully designed for local operating systems (variations of SMP), file systems, databases, and custom configurations.

Virtual machines—and a standard virtual machine format—can provide a standard virtual container for storing and freighting bulk data sets from one location to another, at the virtualization level. Once a P2V (physical to virtual) migration has been performed, an application and associated data is now virtualized and relatively portable, at least within an operating environment such as VMware vCloud.

Unfortunately, a virtual machine from one vendor won’t easily run on the hypervisor of another. Unless I migrate each virtual machine, I need both sites to be running software from the same vendor. Another issue is remapping virtual storage underneath the hypervisor: while the file format can be migrated, the storage settings and configuration may not easily be transferred. A VM or set of VMs include numerous files and metadata about the VM.

On the positive, virtualization vendors such as Citrix, Microsoft, and VMware are working out common virtual machine file formats through the DMTF’s Virtualization Management (VMAN) Initiative, based on Open Virtualization Format (OVF) and other technologies.

Citrix has a cool cross-hypervisor migration tool and import/export utility. According to Simon Crosby, CTO of Citrix, Kensho will support all major virtual disk file formats, including VMware, Microsoft Hyper-v (supported in XenServer), and the Amazon Machine Image (AMI) format used in Amazon’s Elastic Compute Cloud (EC2). Of course, this requires using the tool and deploying XenServer.

Great, but if I create a virtual machine locally, I should be able to upload that virtual machine and run it remotely in an external cloud. Conversely, if I create and run a virtual machine externally, I should be able to download it—and run it locally.

Prediction: virtualization file and metadata formats will standardize such that I can run instances across heterogeneous hypervisors, as customized by various cloud providers.

Our next blog will deal more specifically with the longhaul transport issues related to cloud computing, virtualization, and importing/exporting bulk data sets.

- Jason Goodman, LW2 Solutions

http://community.citrix.com/display/ocb/2008/08/08/Kensho+-+Portability,+Ubiquity…+Now+with+Extra+Freedom!