Real Networking Comes to the Cloud
In past blogs, I’ve often referenced a common concern heard from our customers - how they can embrace the cloud but still use familiar networking controls and topologies. Sure it’s great if you can completely re-architect an application for cloud use, but in reality this isn't possible for many enterprise and federal customers' applications and workloads.
Nearly 6 months ago, we set about attacking this issue with our InstantOn 2.2 release code named "Kittyhawk". (As an aside, each of our cloud releases carries an internal code name to help us track. Our current release track is based on airline call signs – “Kittyhawk” being the UK Royal flight).
Kittyhawk’s design criteria was pretty straightforward. We wanted to be able to support:
- Complex network topologies (multiple private networks) - Give the customer the ability to build the kinds of solutions they are used to in private, virtualized environments but in a multi-tenant platform
- Support the connection of non-cloud resources directly to the cloud in a secure and scalable way - Particularly enabling customers to take advantage of directly connecting to the cloud from within data centers we are deployed in. (See our recent Equinix alliance press release.)
- Support the cloud bridging use-case where the customer can extend a corporate network in their own or third party data center to the cloud
- Allow the creation of private cloud solutions by carving up our multi-tenant cloud, by using our policy-based engine to allow customers to request dedicated resources while under the control of our orchestration interface.
- Finally - and probably one of the most interesting criteria (and challenge) - Rather than using high-end switching platforms to accomplish this, we elected to make the setup/teardown/reconfiguration process under the control of our orchestration engines and use commodity switching fabric.
So let’s talk a little about what we have accomplished.
The first thing we should discuss is private networking - the foundation for these capabilities. As a user logging into our cloud platform, you have the option to define a number of private networks, which is really simple to do. Just name the network and provide a description; there’s no need to worry about any additional details at this point.
This network then becomes an available resource inside your control panel.
These networks are turned into tagged vlans that are provisioned into our switching fabric. In fact, if you view one of these networks, you can see some of the underlying configuration. In this example, dmznet is showing vlan 3004.
It’s important to note that we just created a layer2 network that can be connected to virtual machines. This also allows the customers to use their IP addressing directly on the virtual machine vs. ours, or some form of NAT between us and the customer.
Once the network is defined, it's then just a matter of creating a virtual machine to use the network. In the Kittyhawk release, each virtual machine can have multiple virtual interfaces. And each virtual interface can be configured in 3 possible states:
- None = as you would expect no networking. We have found some customers who actually load a vm with data then take it off net to process, only using the console to access. So in effect, it becomes a capability with some novel use cases.
- Public = in this mode a public IP address is connected to the interface and is linked to our public switching fabric with a Carpathia provided public IP address.
- Private = in this mode you connect the virtual interface to the defined network above.
Now that each virtual machine has these options, you can start to model some more complex architectures and implement environments based on n-tier stacks with isolated networking. For example, maybe you have a web server that needs to be on a "dmz" network, or you want your database traffic to be isolated from your internet networks.
The actual implementation of this capability turned out to be pretty interesting. We used a commodity switching fabric inside our cloud, the intelligence on the provisioning lifecycle, and the connection between virtual machines (which by their nature, migrate around the cloud). The switch ports is all handled within our cloud platform. The other challenge is to make this all scale – a challenge we were able to solve.
Here is a simple vm that has been created with no public IP space, just a private network called "dmznet" and includes a customer-provided rfc1918 ip block.
This new capability offers all kinds of possibilities. Let's assume that you are in the same data center our cloud is deployed in (I'll refer to our Equinix alliance to highlight why this gets exciting!). You may currently have no business relationship with Carpathia, but perhaps you have a colo environment in Equinix that needs extra capacity. You can take advantage of another capability in the Kittyhawk release allowing you to take a data center cross-connect and terminate it directly into our cloud switching fabric (technically we have a pool of switches/ports you connect to so we can have a form of layer2 dmz). The private network you have created above can now be flattened out and sent over your cross connect as a layer2 connection. Or, we can emit the tagged vlans over the cross connect allowing you to interface into your own vlan structure. This provides a low latency connection using your own IP address space that you can then terminate into your existing environment through common security controls. Since this is over a data center cross-connect, you also do not pay for any additional bandwidth charges (in or out), just turn a vm on and consume.
This blog is already getting pretty long, so let me stop here for now. I'll run through other networking capabilities from the Kittyhawk release including our IP allocation tool and high-availability options for this kind of connectivity (also a non-trivial problem thanks to our good friend spanning tree). I'll also post some specific use-cases and customer examples of our private networking in action.
[ Authors ]
- Jon Greaves (44)
- Brian Winter (2)
- Carpathia Hosting (17)
- Paul Roberts (3)
- Teejay Riedl (5)
- Tim Burke (1)
- Rich Thompson (2)
[ Categories ]
[ Archives ]
Archives
- July 2012
- June 2012
- April 2012
- March 2012
- February 2012
- December 2011
- October 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- February 2010
- January 2010
- December 2009
- November 2009
- September 2009
- August 2009
- June 2009
- May 2009
- March 2009
- January 2009
- January 2008
Write a comment
Posts: 17
Reply #17 on : Fri November 30, 2012, 02:55:23
Posts: 17
Reply #16 on : Thu November 29, 2012, 23:16:44
Posts: 17
Reply #15 on : Wed November 28, 2012, 02:13:45
Posts: 17
Reply #14 on : Wed November 14, 2012, 23:58:06