Monday, September 3, 2012

VMworld 2012: Cloud Bursting redefined

While the notion of Cloud Bursting is enticing we are still at the early stages of making this a seamless and autonomic process. Technologies such as VXLAN and VMGRE are an important piece in getting to this point but they do not completely solve the problem. VXLAN (Developed by CISCO) and VMGRE (Developed by Microsoft) allow you to overlay a Layer 2 (L2) network over a Layer 3 (L3) network to remove the need to update IPs and MACs to gain mobility. These technologies are being used to extend L2 networks to public cloud providers to simplify deployment.

As Cloud Bursting is a much overused term, in this post I define it as the ability to dynamically create additional VMs based on Key Performance Indicators (KPIs) that flow over into a public cloud with complete autonomy.
While we are not there yet, we have significantly moved the bar forward to something I refer to as dynamic stretched scaling.

VMware has suggested that scaling involves automatically adding additional VMs to vApps based on demand. VMware defines bursting as essentially doing the same thing only between a hybrid private and public cloud. This is now possible but as suggested it is closer to dynamic stretched scaling than true cloud bursting.

To break this down into a more tangible example lets look at the layers required to make this work. The current architecture of dynamic stretched scaling takes advantage of new features in the vCloud Connector product from VMware (for additional details please see my post on the Tech Preview on vCloud Connector). vCloud Connector allows you to keep a catalog in sync between your private and public cloud. In order to configure this you will need to have the same catalog available in both locations. The client connections will be LB using any technology that provides Global Load Balancing (GLB). VMware's goto partner for LB in generally is F5 which does offer GLB.

In the backend you must monitor your vApps KPIs to identify when additional load is required and alternatively when it is not required. Based on these KPIs you add or delete VMs equally on both sides of your cloud (public and private). You can automate this by tying in your monitoring to VMware Orchestrator.

Although this is substantial leap forward from where we were a very short time ago, there is still a great deal of complexity in the configuration. It also requires tying various vendor solutions together. Also while this works well for some architectures, it adds complexity to others. For example consider a traditional tiered architecture with a relational database, application and web tier. You may have to segregate the relational database between read/write masters and read only subscribers to adjust for latency while still ensuring reasonable performance.

Latency in this model may be relative as well. You will have to know when the performance latency in the private cloud environment is greater than the network latency introduced by using a public cloud provider and react accordingly.

Using dynamic scaling locally and in the public cloud requires you to know what things to monitor that indicate poor performance like the time it takes an end-user to load a page for example. In addition if you are a Cloud provider, performance typically is defined by an SLA. To match the service commitment it may require adding or throttling resources.

It is possible to put these models together now but it still requires an in-depth understanding of the components and how they interact with each other. This is why I refer to current capabilities as dynamic stretched scaling vs. true Cloud busting.

- Posted using BlogPress from my iPad

VMworld 2012: vCloud Connector Technology Preview

VMware has introduced three major enhancements to Cloud Connector which they are calling:

One Network

Cloud Connector has the ability to do a stretched network using an SSL VPN to connect from an on premise cloud to a public cloud. This allows you to move VMs between locations. Even though you are moving VMs between locations, the Layer 2 network configuration is maintained meaning that neither the IPs or MAC addresses need to change even if you are moving to different geographical regions. The initiation of the SSL VPN is facilitated through the vCloud Director API which all public cloud providers generally expose so it should be universally available. One network does require the underlying virtual infrastructure (vSphere, vCloud Director) to be running at version 5.1.

One Catalog

VMware has enhanced catalogs to allow a publisher subscriber model. For example you can publish a catalog from your private cloud and have your public cloud organizations subscribe. Any changes made to the published catalog are synced to maintain consistency across all copies (Note: at the time of release this is a full sync not a delta sync)

One Cloud

Significant changes have been made to the GUI. It is based on the vCloud Director 5.1 interface so has the same look and feel. Now the Connector Console has the ability to have direct console access to your VMs from within the interface. In addition the migration of workloads is wizard driven and has been reduced to a few clicks.

The migration of workloads still requires the VMs or vApps to be powered off but VMware has hot-migration on its roadmap targeted for the next major release. VMware sited a number of Universities and Sega Gaming systems who were using the One Catalog feature to share projects and gaming catalogs between different regions using public cloud providers.

- Posted using BlogPress from my iPad