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:
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:
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.