Dissecting the Cloud – Part 2

This post further delves in a little more deeply into the cloud. In the last post Dissecting the Cloud –Part1, I described the analogy of a person partitioning a large house by creating self-contained units through the use of a hypervisor which abstracts the underlying hardware( CPU, storage and NICs) into virtual CPUs, virtual NICs and virtual disks.

Hence there are has several instances on the cloud each with its own CPU, NIC and storage. In fact several tenants can reside on the same cloud with their own individual CPU, NIC and storage. This is known as multi-tenancy.

However multi-tenancy creates a unique set of associated issues similar to that of a multi-tenanted house. For e.g. how does one isolate one tenant from another? How does one charge each tenant? Are the tenants secured from the prying eyes of their neighbors? How can the owner ensure that one  particular tenant does not consume an inordinate amount of water or electricity at the expense of other tenants?

These are typical problems in a multi-tenanted cloud. A common and a high profile issue in the cloud is that of the ‘noisy neighbor’. In this situation one of the instances of the cloud hogs the network bandwidth or the storage tier, resulting in a severe bandwidth crunch or storage access problems for other instances. Here is an interesting article on the noisy neighbor issue “The Problem with noisy neighbors in the cloud”.

It appears that IBM has patented a solution for the bandwidth crunch caused by noisy neighbors: IBM patents ‘noisy neighbor’ problem with SDN.

In order to ensure that multi-tenancy can be realized in the cloud it is essential to isolate the virtual CPUs, network and storage in the cloud

Network isolation: Network isolation is achieved through the use of VPNs (virtual private network), VLANs (Virtual LANS) and subnetting.

A VPN creates a secure tunnel between a user and the cloud instance while accessing the instance from the internet. The data in motion is encrypted using IPSec.  Also vNICs belonging to a client are logically grouped together in a VLAN. Groups of vNICs can be sub-netted together to allow broadcast between then.  VLANs can effectively isolate traffic between itself and other VLANs. A very good write-up of VLANs and sub-netting can be seen at “What is the difference between subnetting and VLAN”.

Storage isolation: Storage in cloud can be made of block storage, SAN or NAS storage. Storage isolation is typically achieved through the hypervisor and zoning. Zoning is the partitioning of a Fibre Channel fabric into smaller subsets to restrict interference, add security, and to simplify management.  While a SAN makes available several devices and/or ports to a single device, each system connected to the SAN should only be allowed access to a controlled subset of these devices/ports.

CPU isolation: The hypervisor does create individual instances all fairly isolated from one another. However this is the area that is receiving more attention than storage or networking isolation because of security concerns and is prone to attack. In fact I was greatly surprised to hear that there is a technique called ‘side channel’ attack by which an intruder by just observing the time that is taken for computations and the temperatures generated can reverse engineer the actual instructions. This is really a scary thought!

This is how multi-tenancy is achieved in clouds. I hope to revisit this topic again in the future.