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.

Add Comment
No Comments

Leave a Reply

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

More Archive Stories

IBM SmartCloud Enterprise unleashed III – The security issue

This blog post will go into detail on how security is arranged within and around IBM SmartCloud Enterprise.

Redrawing the cloud atlas: How Africa is adopting cloud computing

South Africa is often cited as the breakout case, but cloud adoption is permeating through the continent.

Build a hybrid cloud using brokerage solutions

Note: Over the next two weeks, we’ll be posting one blog per day from our top 10 “greatest hits” from Thoughts on Cloud since we launched in September. This post was originally published on Nov. 9.