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.
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.