Archive

Networking the cloud (Part 1 of 3)

Share this post:

This is the first in three posts looking at networking in the cloud. This post looks at some basic concepts. Read part 2 of this series.

Introduction

To understand how virtual machines are networked, let’s have a look at a notebook computer. On the side there is (probably) a socket into which you can plug a cable, the other end connecting out to the Internet. This is usually what is called an “Ethernet port.” Inside the notebook are some connectors from the computer’s mother board into the Ethernet port, where the processor at the heart of the machine can “talk” to the Ethernet port.

Now you may recall plugging in a new device into a notebook computer and seeing messages about “hardware drivers being installed.” A hardware driver is a special program that control things like these Ethernet ports. So the operating system running the computer will recognize that some data needs to be sent over the port and invokes a command to do this. This command is translated by the operating system to the specific command required by the Ethernet port.

As Ethernet ports come from different manufacturers, each type of port requires different specific commands to make all of this happen. This is where the hardware driver comes in: it can translate the generic command from the operating system into something specific for the installed hardware.

Virtual machines (VMs) calling out

In the virtual world, things get a bit tricky. After all, if a virtual machine is virtual then how can you plug a cable into it so it can communicate?

The answer is that you cannot. Remember that a virtual machine lives within the cloud, which in turn runs on a physical computer – a big server. Now that physical computer can be connected to a network. What the clever people in cloud laboratories did was to create virtual networking techniques and invented “virtual device drivers.” Yes, they created things like virtual Ethernet devices, which in reality are nothing more than programs within the hypervisor.

So if a VM wants to send some data to the Internet, it will have a virtual Ethernet device defined to it: a device which it automatically installed a driver for, just like in the real world. The fact that the device does not exist is irrelevant – the VM operating system is none the wiser.

As before on the physical world example, the operating system can work out which command to send to the virtual device to request some data to be sent, using the right driver. The hypervisor monitors this virtual device and cleverly translates that command to a “real world” command on a physical cable link. Thus your virtual machine can communicate with the physical world.

And incidentally, virtual devices are not restricted to networking: in order to see the output from a virtual machine, there will be a virtual display and keyboard too. Anything (pretty much) can be virtualized in this way, even disc storage.

Yes, but at which address?

Everyone understands that to access a webpage — say www.bbc.co.uk — you simply type “bbc.co.uk” into the top of a browser and the information appears. Actually, the Internet cannot understand this address as it works with numbers, not meaningful words. Behind the scenes is a special computer on the Internet called a “DNS Server” that translates your typed web address into an address the Internet can understand: something like “212.58.241.131.” This is called an “IP address” – in fact, you can type that into your browser and still access the BBC News. By the way, IP addresses are unique – hence why the world is running out of Internet addresses and why a new addressing scheme is being bought in, called “IPv6”.

So when you create a virtual machine (VM), it too must have an IP address. When the cloud Management Software creates the VM, the workflow has a pool of pre-defined IP address available to it which is accessed to ensure your new VM has a unique IP address. The network outside of the physical cloud infrastructure is set up to know that IP addresses in that range will be inside the cloud. The hypervisor knows which VM has which IP address and routes the message accordingly. Thus requests for data from outside of the cloud can find their way into the cloud – and out again.

Read part 2 of this series next.

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