Tuesday, March 10, 2009

Virtual Networking in the Cloud

Originally clouds provided public addresses for all resources in the cloud, for IPv4, this obviously doesn't scale well.  The alternative is placing a few on public network and the majority on a private network with each public address costing additional money motivating users to use private addressing.  Some potential solutions involve setting up complex static links via L2TP or GRE.  The problem is that for each one of these connections, it requires an operating system specific configuration.  Many users are unfamiliar with these protocols and according to wikipedia they aren't necessarily that easy to configure in Windows prior to Vista.

Now you could argue that most users won't use Windows with the cloud and that'd be a fair argument, so perhaps they could just use Linux and have automatically configured L2TP/GRE paths.  That could potentially work, though for a shared address space that would require a single L2TP/GRE server that requires being on a public address.  All nodes would have to route through that point in the public network.  Two cases where this is a big issue are:  1) two machines on the same physical network would have to route through the L2TP/GRE server for their "virtual" addressing and 2) two remote machines not connected on the same physical network nor to the public address would have to route through the public machine to communicate with each other, creating a huge potential bottleneck.

The problem lies in the desire of vendor lockin via centralization.  If all cloud vendors were to use a unified interface, users could at least minimize their overhead in working with different cloud providers.  Though cloud vendors may be not so excited about having a unified layer 2 network with others and even if they did it would have to be a selective process so that not all cloud vendors may provide this service.

What P2P Overlays and Network Virtualization can do to improve the situation:

  • Migration between clouds and between a cloud and the users environment

  • Separation of network spaces between resources in a cloud

  • Private communication between multiple clouds and user resources

  • Supporting a single address space across multiple sites in a single cloud


Enough for now, I'll discuss the above in future posts.