Archive

Networking the cloud (Part 3 of 3)

Share this post:

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

Why we added new map tools to Netcool

I had the opportunity to visit a number of telecommunications clients using IBM Netcool over the last year. We frequently discussed the benefits of have a geographically mapped view of topology. Not just because it was nice “eye candy” in the Network Operations Center (NOC), but because it gives an important geographically-based view of network […]

Continue reading

How to streamline continuous delivery through better auditing

IT managers, does this sound familiar? Just when everything is running smoothly, you encounter the release management process in place for upgrading business applications in the production environment. You get an error notification in one of the workflows running the release management process. It can be especially frustrating when the error is coming from the […]

Continue reading

Want to see the latest from WebSphere Liberty? Join our webcast

We just released the latest release of WebSphere Liberty, 16.0.0.4. It includes many new enhancements to its security, database management and overall performance. Interested in what’s new? Join our webcast on January 11, 2017. Why? Read on. I used to take time to reflect on the year behind me as the calendar year closed out, […]

Continue reading