vmware
Cloud Wars Heat Up
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy John Considine
Last week I wrote about the Cloud.com acquisition and what it means for Citrix, Rackspace, OpenStack and the industry. Next, I’d like to dig into the VMware announcement about their cloud infrastructure suite. Citrix clearly wanted to announce their news just prior to VMware’s, and for a good reason – Citrix is hitting VMware in a weak spot of their cloud strategy. It’s pretty clear that VMware is not getting the vCloud adoption they were anticipating from service providers and even enterprises.
In Paul Maritz’s presentation, he mentioned that VMware “…has been working closely with service providers because you need the same stacks on both sides [the private cloud and public cloud] to be able to ‘slide’ applications to the cloud…and back again.” At CloudSwitch we are dedicated to the notion that you don’t have to have identical infrastructure stacks between the data center and the cloud. You have to expect that what a cloud provider chooses will not necessarily be the same as what the enterprise has chosen, or that they will work together in lock-step. VMware seems committed to the strategy that they will provide the complete solution on both sides of the cloud, and that all parties will work together to stay coordinated. This is very different from Citrix’s positioning around more open and heterogeneous solutions.
Citrix and VMware have been competing in the virtualization space for years with a battle of features (mostly Citrix catching up with VMware and trying to gain share in the enterprise virtualization market), but the scope of the competition has been growing thanks to cloud computing. Cloud computing expands the server virtualization fight from hypervisor features to integrated stacks for deploying/managing infrastructure. The hypervisors remain important, but the new frontier contains everything from core networking to storage management, to large scale deployments to self-service IT. In this new battle, Citrix has some real strength in networking (Netscaler, etc.) and application delivery, and with their Cloud.com acquisition, they are capturing some proven orchestration technologies.
VMware is investing huge resources to expand their cloud offerings (Maritz claims a million man hours). Their focus is on adding features to their hypervisor and layers to their stack (vSphere+vCenter SRM+vCenter Operations+vShield+vCloud Director). They have lots of expertise in this area and direct interaction with enterprise customers and requirements. On the service provider side, they are dependent on feedback from VMware-based partners to provide input and learn how to build and run large-scale infrastructure clouds. We’ll have to see how this approach plays out vs. Citrix’s CloudStack.
In the end, this competition is great for all of us as well as for CloudSwitch specifically. The competition in the cloud space will continue to drive innovation, new features, and simplification of deployment for this great new platform called cloud computing. CloudSwitch is all about choice and giving enterprises control and flexibility in their cloud architectures. As the world of cloud computing evolves, we love to see different options, technologies, and capabilities – because a world filled with different cloud choices needs a CloudSwitch to connect all of the pieces.
Buying the Cloud
By John Considine
Here we are on July 12, mid-summer when you think most people are wondering about going to the beach in 90 degree weather, and instead we have big cloud news. Early this morning we were greeted with the announcement that Citrix is buying Cloud.com for more than $200M. After the initial congratulations to Sheng and the team at Cloud.com, the twitter-sphere and blogosphere went wild with thoughts and deal analysis. At the same time, everyone was waiting to hear what VMware was going to say in their “Cloud Infrastructure Launch” webcast.
I’ll start with some thoughts on the Cloud.com acquisition. Rather than go into the rationale and size of the deal, I’d like to focus on what this acquisition means to Citrix, OpenStack, and Rackspace.
It’s clear that Citrix has been a major supporter of OpenStack and that support makes sense since it’s a great way to compete against VMware. OpenStack is shaping up to be the answer to the closed source solutions being developed by VMware for building both public and private clouds. It’s also clear that Citrix needed a boost to gain traction and credibility in the market for producing cloud infrastructure. They have a good hypervisor and are busy building out more features, tools, and performance – but cloud infrastructure is a lot more than hypervisor + new features.
Enter the Cloud.com guys. They know how to build clouds, and already have traction with service providers and enterprises alike. They have proved that they know how to make a cloud scale – and this is not as easy as it sounds. Keep in mind that building clouds is more complicated than standing up virtualized clusters and running standard tools; there are complex networking, storage, and workload placement problems, not to mention versioning, maintenance, and operations.
So this is clearly a good thing for Citrix, and on the face of it, a good thing for Cloud.com – but what about OpenStack? The bigger question here is: what does this really mean for the OpenStack community? Is this a case of Citrix providing the enterprise/supported version of OpenStack as RedHat does for Linux? Will we see a set of capabilities delivered by Citrix that are built on OpenStack, but that are exclusive to Citrix’s CloudStack? Will OpenStack be increasingly driven by Citrix’s needs and integration with Xen (versus other hypervisors)?
If Citrix remains committed to its stated direction of providing the software for clouds (rather than building a cloud themselves), they are in a great position to capitalize on OpenStack. Rackspace, on the other hand, has a more complicated opportunity with OpenStack. They created the idea and built the community, but they are limited by the fact that they are themselves a cloud provider, so it would be hard for them to sell and support OpenStack software to other cloud providers and vendors. That leaves the door open for someone else to step in and become the enterprise software vendor for OpenStack. Clearly Citrix has been targeting this, and the addition of Cloud.com adds the full software stack and knowhow for building and deploying a cloud.
And in other news...VMware announced its Cloud Infrastructure suite today. Given that the VMware announcement was previously scheduled, I can only conclude that Citrix picked today to overlap with their announcement. These two announcements occurring on this sleepy mid-July date point to high activity in the cloud space, and the coming wars around who is going to provide the cloud infrastructure for both service providers and the enterprise. This may become a battle of closed source solutions from VMware and open source solutions from Citrix (and OpenStack)… I’ll write more about the VMware announcement in my next blog, but the battle between Citrix and VMware is definitely heating up.
Cloud Tip: CloudSwitch Networking and ESX
By Damon Miller
As Director of Technical Field Operations for CloudSwitch, I have the pleasure of interacting with most of our customers on a regular basis. This is an integral part of my job since I’m ultimately responsible for making sure we provide a positive experience every time someone uses our product. The past month has provided a fantastic opportunity to do just this, as we opened our beta program to the public on March 1st. We’ve learned a tremendous amount from our customers so I thought I’d take a moment to share some of that information to help everyone interested in using CloudSwitch.
First, there are some basic things to remember before using CloudSwitch to move servers to the cloud:
- Applications need to be virtualized before they can be moved into the cloud, and you need a virtual environment in your datacenter for deploying the CloudSwitch Appliance.
- The virtual machines that you move to the cloud need to come from a supported version of VMware. Today, this list includes ESX 3.5 & 4.0, VirtualCenter 2.5, and vSphere 4.0. We can also access servers directly through a CIFS share.
- When running the CloudSwitch Appliance in an ESX environment, specific networking options are required for connectivity to servers running in the cloud.
The last item—ESX network configuration—has caused confusion for a few of our customers, so I thought I would also take some time to explain what specific settings we require and why they are needed. First, though, it makes sense to provide a very quick description of how the CloudSwitch solution works.
After deploying the CloudSwitch Appliance (CSA) into a VMware environment, users select internal VMs to be migrated to a target cloud. I’ll leave the full architectural overview for a later article, but suffice it to say that the selected VMs are then migrated securely into the cloud—encrypted in transit and at rest. Once the migration is completed, the CSA starts the selected servers within our Cloud Isolation Technology. This technology allows unmodified VMs to run in the cloud provider of your choice and provides secure, layer 2 connectivity to the datacenter. A layer-2 connection—or a network bridge—means that users don’t need to change any network configuration data such as IP addresses and netmasks, since this is transparent when connectivity is established at the data link layer.
After the migration, one of two things will happen: network connectivity will work exactly as it always has or the migrated VM will appear to be down (from a network perspective). As you might imagine, our goal is the former. However, in some cases VMware’s network configuration can interrupt the flow of CloudSwitch’s network traffic. Specifically, there are two Virtual Switch Policy settings which must be enabled in order for CloudSwitch to provide layer 2 connectivity. These are:
- Promiscuous Mode
- Forged Transmits
So, what do these settings actually mean?
Let’s start with Promiscuous Mode. The name Promiscuous Mode is actually a bit confusing, though if you’re familiar with the related network interface option this will kind of make sense. When Promiscuous Mode is enabled, ESX will send all traffic to nodes whose interfaces are placed into promiscuous mode. Ultimately, enabling Promiscuous Mode on a virtual switch makes that switch function kind of like a network hub. VMware has essentially provided a way to see all traffic on a given Virtual Switch or Port Group.
Ok, but why does CloudSwitch need this? The quick answer is because without this option enabled, the CSA won’t receive traffic intended for servers it has migrated into the cloud. If ESX’s virtual switch functioned just like a physical switch this would not be a problem. Physical switches build up a list of MAC addresses connected to them, effectively “learning” which network interfaces are where. Without this intelligence, a node would never be able to communicate across more than one switch. However, ESX assumes that the VMs attached to its virtual switches are always the final destination. In CloudSwitch’s case, this is not true: There are other servers “behind” the CSA—cloud-based servers launched by customers.
If enabling Promiscuous Mode was acceptable in all environments, we would be in great shape. However, some of our customers have told us that they don’t feel comfortable with this configuration for their virtual switches. We completely understand their position, because we don’t want that extra traffic either! We’re only interested in traffic for the servers we’ve migrated into the cloud. Thankfully there is a quick and simple solution. The CloudSwitch Appliance can be configured with its own Port Group and Promiscuous Mode can be enabled only for this port group. In this configuration, the CSA will never receive traffic from any other node on its switch since Promiscuous Mode applies only to itself.
There’s one more setting we need to discuss, and that’s Forged Transmits. With this option enabled, VMware allows virtual machines to generate traffic using a source address that is different from the network interface connected to the virtual switch. CloudSwitch isn’t actually “forging” anything; rather, we are delivering the traffic generated by a customer’s cloud-based virtual machines into the datacenter across the secure tunnel we establish using the CSA. All physical switches support this behavior by default because, again, without it no network consisting of more than one switch would function. To provide traffic from migrated virtual machines to customer datacenters, CloudSwitch needs the CSA’s virtual switch to function more like a physical switch and allow this traffic to flow correctly. Enabling ESX’s Forged Transmits option on the CSA’s virtual switch or port group makes this happen.
Both of these settings can be updated from the Virtual Infrastructure client. The process for enabling Promiscuous Mode and Forged Transmits is described in a knowledge base article available from VMware. Note that these settings can be applied either to an entire Virtual Switch or to a Port Group. Port Group settings override Virtual Switch settings so if you do change them on your Virtual Switch and you still don’t see the expected traffic, be sure to check the Port Group settings: They may be overriding your switch-level changes.
CloudSwitch’s goal is to provide a simple, secure way to use cloud-based resources without requiring any change to applications or operating systems. A few basic requirements such as a virtual environment are required to make this possible. Additionally, when deploying the CloudSwitch Appliance under VMware ESX, two specific network configuration options are required. Hopefully this article will help users understand what’s needed to get started, and thereby ensure a smooth, successful product experience.
