Archive

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:

Add Comment
No Comments

Leave a Reply

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

More Archive Stories

Open, hybrid cloud is about to rain down. Are you ready?

We’re nearing a critical inflection point. The convergence of technologies like cloud, analytics, mobile, and social business is a phenomena that will literally transform industries. Customers and vendors that fail to leverage this unique opportunity to drive business model innovation will be left behind. Most of the clients I talk to get it. However, they’re […]

Continue reading

Can Internet of Things help create a smarter government?

Mac Devine shares his impressions from the Intel Developer Forum as they relate to government, internet of things and cloud computing.

Continue reading

Migrating from one application or management stack to another

According to Gartner, one role of an IT department is to be a cloud services broker (CSB) for sourcing external services. However, I personally believe that a full-fledged CSB also requires dynamicity in decision making, experience managing IT for others, technology to aggregate IT capabilities from the market and various other considerations that go beyond […]

Continue reading