Networking the cloud (Part 2 of 3)

Share this post:

This is the second of three posts looking at networking in the cloud. Read Part 1 of this series.

This post looks at clustering and network management.

Clustering virtual machines (VMs)

Very often there is a requirement to set up a number of VMs that are linked in some way to provide some computing need – this is called “clustering”. For example, a technique very often used is to set up a server to handle input and output (a “web server”), another server to run a database (a “database server”) and another to handle some real processing (an “application server”). These servers may be separate but form one logical processing group, only really addressable using one IP address. Inside the cluster, they need to talk to each other and so these servers need to have separate (but private) IP addresses.

Now in a cloud some very clever things can be done and such a cluster can be built in one go, rather than having to build each virtual machine separately.

When a user accesses the portal in the Cloud Management System to build a cluster, a workflow is started that will instruct the hypervisor to build the VMs in turn. Each VM then gets the software it needs to do the job and the workflow can directly configure each of those servers within the cluster with its own IP address and those of the other VMs in their cluster. Hence they can be set up to “know” about each other and work as a team. And because the workflow has been tested by the Cloud Support Team, this will work every time (or should).

This highlights another benefit of the cloud: bringing repeatable and consistent quality to new server builds.

Virtual network management

The Internet has its fair share of bad people who are looking for computers that can be attacked and probed. Every VM in a cloud needs to consider what protection it needs and whether it needs a firewall – and of course the host computer certainly needs protection.

Now a server cluster in the physical world could have a “load balancer.” This is usually a physical device that processes incoming requests for action and “serves” them to servers in the cluster depending on which is lightly loaded. In the virtual world, you can have a virtual load balancer which does this job.

Thus in our example above, there may be two or more web servers in the cluster, waiting to process requests. The workflow that built the cluster can also build a virtual load balancer, thus making sure that the cluster is used efficiently. Should one of the servers fall over (or break down) then the load balancer can detect this and switch the traffic to the remaining web server to handle the load. All virtually, all within the cloud.

More 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, 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