Recent Posts
Hubs, Spokes and WANs
Digg
Reddit
Delicious
StumbleUpon
Facebook
Twitter
LinkedIn
BuzzBy Ellen Rubin
Recently, we’ve had a number of discussions with enterprises about how they’d like to use the cloud. The basic use case is around capacity on-demand (not surprisingly), but the specifics have raised some interesting issues. The companies have distributed branch offices that need the capacity for a range of applications, including dev/test environments as well as back-office and web apps. Today, these distributed groups are relying on corporate IT to meet their scaling and infrastructure needs, and they are frequently bottlenecked. This is both in terms of overall challenges in getting new capacity approved in a timely way, but also from a network bandwidth perspective. At a panel this week at Interop, Riverbed noted that 2/3 of their enterprise customers have a hub and spoke model that requires the “spokes” to backhaul to the “hub” for connectivity to the internet, and thus to cloud computing services. Only the remaining 1/3 have direct connections. At the same panel, Blue Coat agreed with the stats but commented that the branch sites are trending towards a direct-connect model as new sites are added.
All this is interesting to us at CloudSwitch since we have been hearing more and more frequently from enterprises that want more “edge” computing, and to empower the branch offices to add capacity on-demand in a controlled but self-service way. This creates a set of new requirements around cloud computing, in terms of both networking and security. In the hub and spoke model, corporate IT maintains control over all access to the cloud, which has benefits on the security and permissions side, but creates potential bottlenecks – both in terms of the need for self-service management tools to increase agility, as well as in bandwidth constraints where the backhaul traffic starts to strain the corporate networks. Backhauling also creates strain on the branch offices since it often adds significant latency to their internet connections.
Most of the vendors at the Interop panel (including Akamai, Riverbed, Ipanema and Blue Coat) claimed to be developing or are already offering WAN optimization products – increasingly in the form of virtual appliances and/or software versions – to help alleviate these bottlenecks. These will surely help, but will become even more important as the branch offices start to have more direct connectivity to the cloud. WAN optimization offerings at the “edge” will be increasingly needed, and cloud service providers are focused on building out these capabilities at their end of the network. Security in a more distributed model will also require some new thinking, since users in the branches will want to maximize flexibility and agility, while corporate IT will still need a way to limit potential threats and exposure created by opening these direct connections.
Underlying all these discussions is the fundamental issue of the laws of physics. As enterprises start to embrace the cloud model, they’ve realized that the major choke-point will be their network bandwidth. Innovation around addressing these issues, especially in the virtualized world of the cloud, will definitely be required. At CloudSwitch, we’re staying closely involved in discussions around customer requirements and vendor offerings to increase performance for workloads moving to the cloud.
Cloud Expo 2010: Virtualization Steals the Spotlight
By Ellen Rubin
At first glance, cloud computing can appear to be “virtualization taken to its logical conclusion.” After all, if the main benefit of virtualization is to consolidate data center resources and increase the speed of provisioning, then cloud is the ultimate pay-off: don’t own the resources at all and cut provisioning down to a few minutes with instant self-service gratification.
But upon further thought, and as was highly visible at the Cloud Computing Expo this week in NYC, cloud seems to be giving virtualization a return to the spotlight. A recent Gartner study noted that cloud computing is the number 2 priority for CIOs – trumped only by…virtualization. And most of the sessions at the Cloud Expo made some mention of the benefits of extending virtualization footprints within the data center and starting to turn these into internal clouds, or at least “cloud-like” environments.
So is virtualization what’s old but new again? Remember that most enterprises have adopted virtualization in some way, but are only about 20% virtualized so far. So there’s plenty of room left to penetrate, and there’s still lots of opportunity for optimization and better management. Virtualization has primarily been used for consolidation, not for optimizing workload management and self-service. And many companies have large investments in existing hardware and virtualization licenses that they’d like to use more efficiently. In many ways, cloud computing has emerged on the scene as a disruptive force while virtualization is still an evolution in progress.
As at other recent shows, the common wisdom at the Cloud Expo was that “hybrid” environments are key to the emerging IT infrastructure. Some resources will stay behind the firewall and others can be moved to outside cloud environments. Some applications may need to be split between the data center and external clouds, especially where the database needs to stay inside. In this hybrid world, some enterprises will want to focus on growing the internal virtualization footprint and starting to build capabilities for provisioning, charge-back, orchestration, role-based access, etc. This may require significant investment in additional hardware and software. It will also require enterprise IT to develop a new perspective on managing their virt investments, learning from the cloud providers about best practices and from companies like CloudSwitch about how to combine external cloud services with their own environments securely and transparently.
It’s also true that many of the major technology vendors (as well as some IT departments) have a bias towards focusing the cloud revolution on known and existing technologies. It’s still somewhat scary to think about moving things outside the data center and cloud technologies are in relatively early stages. And external cloud services (in particular public clouds) are pushing the envelope in terms of customer expectations and placing new, challenging demands on virtualization.
But virtualization will have to step up to these demands now that the cloud revolution has raised the bar. Many of the emerging capabilities will need to be at the management plane: a broad range of self-service functions, for sure, but also the ability to route workloads to the appropriate environments based on business and technical requirements, and to federate across multiple and diverse environments both on-prem and externally. So maybe cloud computing turns out to be not only the logical extension of virtualization, but the catalyst that helps virtualization move to the next level.
Legacy Apps Make the Case for the Cloud
By John Considine
We often talk about CloudSwitch moving legacy applications to the cloud in a simple and secure way; this raises the question of what exactly we mean by “legacy.” To be more specific, we mean a broad range of apps—including third-party, custom and customized off-the-shelf applications—basically any application that has been developed in your current environment without specific design for a cloud.
It turns out that these existing applications are very important in cloud computing. When we started building CloudSwitch, we were focused on the hybrid cloud computing model; that is, some components must stay in the data center and other applications and functions can move to the cloud. However, it became apparent that “stretching” applications between the data center and cloud only works for certain types of deployments due to the added latency between the data center and the cloud. For this reason, we recommend moving as much of a multi-tier application to the cloud as you can. This allows the application to continue to run with low latencies between the different components. Sounds obvious, but this is where a whole new set of problems arise, and it’s what causes people to start talking about the challenges of moving legacy applications to the cloud.
In order to operate a multi-tier application in the cloud, you need to be able to control the application(s), infrastructure, and operating system, including things like a database tier, middleware, and custom applications. This also means that you have to “cloudify” each of these components. Suddenly you are looking at a lot of work, and potentially facing failure because some of those tiers can’t be modified to run in the cloud.
We saw a great example of this when Microsoft’s Azure service first launched. The initial release of Azure allowed application developers to build .NET applications and run them seamlessly on their local machines or in the Azure cloud. However, people trying to use this cloud usually had other applications/databases/etc. that were part of their solution, and there was no way to run these in Azure. This meant that there were a lot of things that could not be moved to Azure since “stretching” the application caused unacceptable latency and there was no way to connect the Azure deployment to the data center-side applications. Microsoft has since expanded the capabilities of Azure, but there are still many types of applications and services that cannot run in their environment.
Given all the challenges, why is it worth bothering to move legacy applications to the cloud? For most enterprises (as opposed to new ventures and SMBs), legacy apps by definition occupy the majority of the existing IT footprint, far more than newer applications, let alone those designed specifically to run in a cloud. In many of the companies we’ve worked with, legacy apps are well over 75% of the data center footprint, and they’re constantly expanding and creating needs for more capacity. Legacy apps tie up internal processing and storage resources, sometimes continually, sometimes in a “spiky” way to meet occasional massive needs. Their demand for computing power is usually growing (or skyrocketing), and contending with other applications. The enterprise then has to make tough choices about whether to buy more equipment or put up with degraded performance.
By providing access to virtually unlimited resources on demand, the cloud can bring a new level of elasticity and efficiency to a company’s IT environment. Legacy apps are often the best candidates for moving to the cloud, especially in cases where they’re infrequently used, or only need to scale for new releases or for seasonal/marketing-driven events. One of the best use cases for the cloud so far is the ability to offload this type of resource-consuming set of apps to a lower-cost cloud infrastructure, freeing IT to focus limited internal resources where they’re needed most.
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.
