Networking the cloud (Part 3 of 3)

This is the last of three posts looking at networking in the cloud. This post looks at protecting networks in the cloud from each other. Read part 1 and part 2 of this series.

Chinese walls

There are some vendors who sell cloud services – collectively they are known as Cloud Service Providers. These services provide the opportunity for “Joe Public” to log onto the cloud vendor’s web site and “buy” a virtual machine (VM). So in one of these clouds there will be several organizations as customers, each with data that needs to be kept separate and confidential.

Similarly, an organization may design a cluster of VMs to work together but that the servers in the cluster must always have the same IP address. If only one cluster is built in the cloud, there is no problem. Build it more than once and things start to fail as more than one VM will have the same IP address. And remember that every IP address needs to be unique.

One way to get around this would be to build the VMs on separate physical networks. But if you start to require VMs to be built in this way, then there will be an awful lot of cabling to be done, more cabling then can be plugged into the physical cloud host. Additionally, you do not want a workflow to be stopped; that takes away the cost advantage of automation.

To get around this, the operatives in Cloud Laboratories came up with the idea of Virtual Networks (or VLANs). The cloud host has a special hardware device called a “switch” attached, which places a VLAN identifier alongside the IP address into every data message within the cloud,. The virtual network adapters in the VMs are designed to only process data messages with a specified VLAN ID. Remember these are virtual hardware devices which can be controlled by the VM operating system – but they cannot be reprogrammed to listen out for a different VLAN ID by an application.

In reality, everything is still on the same physical network but it has been logically subdivided into a number of virtual networks, each separate from each other. Thus a “Chinese wall” effect is created that keeps network traffic separate within the cloud; and VMs can thus have the same IP addresses, albeit on separate VLANs.

Using these techniques, VMs in Cluster A cannot “see” VMs in Cluster B unless they know the public IP Address of the VM cluster: in other words VM cluster A has to go out of the cloud to the public internet and back into the cloud to access it.

Read part 1 and part 2 of this series.

Share this post:

Share on LinkedIn

Add Comment
No Comments

Leave a Reply

Your email address will not be published.Required fields are marked *

More Archive Stories

A guide to Federated Identity, Icehouse and beyond

When I was told to kick off a new developer-focused series of entries for Thoughts on Cloud, I was stunned. First, by the honor that it would be, and then by the realization that I would have to actually write something down. I’m not a writer, not a blogger, the whole thing suddenly seemed kind […]

What is social business in the cloud?

The one thing that all organizations have in common is that they must all identify new ways to grow revenue and expand their businesses to stay competitive. Increasingly, organizations are using cloud computing and social business to help them embrace new market opportunities and speed time to market.

What’s the deal with BYOD and security?

What are some of the considerations for organizations adopting BYOD?