In our series on Cloud Computing, we have looked at the history of the cloud, examined some of the technical breakthroughs that allowed the cloud to evolve, explored the design of the data centres that the cloud lives in, and looked at how the scale of modern data centres changes the mindset of operators. In this final piece, we will explore how cloud services are sold, how virtual server mobility is key to running cloud services and look at some of the issues round virtual storage.
Let’s start by looking in more detail at what happens inside a multi-tenant cloud data centre. For simplicity’s sake, we will focus on the classic virtual server model – most of the myriad other services that are available nowadays build on or extend this model. A typical cloud provider offers virtual servers based on the amount of virtual resources they can access. So you might have a small virtual server with a single virtual core, 512MB virtual memory and 5GB of storage. Or at the other end of the spectrum you might get 8 virtual cores with 32GB RAM and 100GB of storage.
But what do these numbers refer to and what will you receive in practice? To answer that we need to look at the concept of over-subscription. Many of you will be familiar with this from your broadband line. Essentially over-subscription means that a shared resource is sold many times over with the assumption being that at any given moment only a fraction of the users will be active (in networking the fancy term for this is statistical multiplexing).
In a cloud context, over-subscription ratios vary from no oversubscription to cheap operators that might sell their resources 20x over. In the latter case, that would mean that a 16 core server with 256GB of RAM could theoretically host 300+ small virtual servers. Many of you might assume that most operators would choose high over-subscription ratios. Indeed you may be asking the question why would you ever choose to run with no oversubscription? The answer to that lies in one of the other cool features that is offered by most hypervisors, namely migration.
Virtual Server Migration
One of the cleverest tricks provided by most hypervisors is Virtual Server Migration. This refers to the ability to move (or migrate) a virtual server from one hypervisor to another. That might be in the same rack, in a different rack in the same pod, in a different pod or even in a different data centre altogether! In some cases, migration can be done “hot” with the workload still running. Thus, one of the additional benefits of virtual servers is improved reliability. Rather than a hardware failure causing a service to fail, the workload can simply be migrated to another hypervisor.
Cloud operators use this ability to migrate workloads in order to try and maximise their revenue by allowing some servers to be turned off. Amazon also offers spot-pricing for any spare capacity that comes up, and users are able to specify that they effectively want to scavenge and spare resources rather than pay for a set level of service.
While it is relatively trivial to move a virtual server from one hypervisor to another, it’s harder to ensure that it still has access to the same data. Within a data centre, there are usually three types of storage resources. The first is in-memory storage, which is used for extremely fast access of things like key-value databases. However, as memory is one of the most constrained resources in a data centre, most cloud operators don’t offer this sort of service (or charge a lot for it). The next type of storage is local-accessed storage. This means storage resources that are either in the same physical server or very close. This means that the data can be accessed quickly. However, if the virtual server is migrated to another rack, then the storage also has to be migrated, which can take a long time. The third type of storage is called a Storage Area Network, or SAN. These are specialised devices that provide vast amounts of fast storage to all servers via the internal network. The clear benefit of this final approach is that the storage is always accessible wherever you are in the network. Of course, nothing is ever quite as clearcut as the above implies. Over time, myriad hybrid approaches have been developed that use local disks within the servers but replicate the data in multiple locations to improve both reliability and migration.