Operating the Cloud from Inside Out
چکیده
Virtual machine images and instances (VMs) in cloud computing centres are typically designed as isolation containers for applications, databases and networking functions. In order to build complex distributed applications, multiple virtual machines must be connected, orchestrated and combined with platform and infrastructure services from the hosting environment. There are several reasons why sometimes it is beneficial to introduce a new layer, Cloud-in-a-VM, which acts as a portable management interface to a cluster of VMs. We reason about the benefits and present our Cloud-in-a-VM implementation called Nested Cloud which allows consumers to become light-weight cloud operators on demand and reap multiple advantages, including fully utilised resource allocations. The practical usefulness and the performance of the intermediate cloud stack VM are evaluated in a marketplace scenario. I. LIMITATIONS OF PUBLIC CLOUDS Cloud computing is, for a reason, also called utility computing: all infrastructure, software and data should be available on demand, at the right scale, and for a price which precisely corresponds to the usage pattern [1]. In practice, public cloud providers only offer utility computing at a first approximation. The on-demand or ad-hoc acquisition is limited by manual sign-up processes which involve credit cards and personal data; the vertical scalability is coarse-grained and the horizontal scalability subject to customised applications; and the billing is performed in needlessly large time slots [2]. Furthermore, the management APIs and graphical user interfaces cannot fulfil all potential requirements on a scale between full automation and high user-friendliness. The intertwined nature of cloud services and corresponding management services contributes heavily to this issue. For multiple reasons, to be detailed later, it would be desirable to introduce an intermediate layer under the control of the user. As opposed to existing cross-cloud management tools and portals [3], it would operate directly within the user’s allocation. We envision a Cloud-in-a-VM scenario which, when deployed in a compute cloud, enables the infrastructure service consumer to become a light-weight provider and overcome the mentioned operational limitations through proper provisioning and management tools. The VM which contains the intermediate cloud and which operates subordinate application VMs would be externally indistinguishable from traditional application VMs. One evident practical requirement for the envisioned Cloudin-a-VM approach is the pass-through and thus the availability of hardware virtualisation features on the VM level. The virtualisation extensions of current 64-bit processors (Intel VTx/VMX, AMD-V/SVM, ARM AVE) have led to sophisticated nested virtualisation support in several hypervisors (KVM 1.0+ on Linux 3.2+, VMware vSphere 5.0+ with VHV switch, Xen 4.2+ experimentally). This means that a hypervisor on the lowest level (L0) can operate a VM (L1) with a hypervisor which can operate an internal VM (L2) [2]. Users of cloud computing stacks (Xen Cloud Platform, OpenStack and others) benefit from the pass-through. The nesting is often limited to specific combinations (e.g. KVM-on-KVM and KVM-onXen), but constantly expanding, and somewhat limited in terms of L2 performance, but constantly improving [4]. Other hypervisors (Microsoft Hyper-V, Oracle VirtualBox) don’t support nesting, and hence cloud stacks and infrastructure services on top of them (Microsoft Azure) do neither. Even when nestingcapable hypervisors are employed by a cloud provider, nesting may be switched off (e.g. Amazon EC2 on Xen) for technical or business reasons. Our Cloud-in-a-VM approach assumes that nesting is available in the hypervisor which runs the VM instances in a public cloud. In other words, once the passthrough limitation is overcome, all other mentioned limitations can be overcome as well. II. BENEFITS OF CLOUD-IN-A-VM The recent terms Meta Cloud, Nested Cloud, Cloud of Clouds and Intercloud all describe sharpening trends towards higher operational control across cloud providers’ technical and business boundaries [5], [6]. In particular, nested clouds are known to offer benefits over a flat VM-to-provider deployment model [7]. These benefits encompass a higher degree of utilisation, more convenient deployment of a large number of already interconnected VMs, economic gains through repurposing otherwise idle and already paid-for resources, and unified interaction with consistent provider-independent user interfaces. • Higher degree of utilisation. Often, VM allocations in the public cloud are subject to coarse-grained scaling and duration. With a Cloud-in-a-VM, these limits can not be overcome, but the allocation can be more efficiently utilised by re-purposing the unused slices. • Economic gains. In combination with the higher degree of utilisation, re-selling otherwise unused slices grants an income which in some cases may even cumulatively offset the initial purchasing cost. For instance, a large VM instance can be reserved early on for a good price and later in parts be re-sold as subordinate spot instances. • More convenient deployment. When large numbers of VMs need to be deployed from existing instances, it becomes easier to just migrate (virtualise) their host machines instead of migrating each VM on its own. • Consistent user interfaces. Instead of having to learn and use a different user interface for each cloud provider, a distributed Cloud-in-a-VM offers a unified management interface with at least a common subset of operational controls such as restart, rescale and snapshot creation. Nested clouds are typically designed using nested virtualisation to avail oneself of hardware acceleration. This concept is outlined in Fig. 1 using the following example: Two physical hosts which run two and three VMs, respectively, are subject to being virtualised. Instead of allocating five new VMs and their dependencies, the virtualisation is performed at the host level, thus moving the operating system and hypervisor to an application level on the target host which already runs a hypervisor. However, so far, nested clouds have only been superficially analysed, primarily on the underlying virtualisation level [2], [8]. No implementation of a usable nested cloud is known to the authors, and no insight-delivering measurement results are available. Therefore, it is our aim to introduce Nested Cloud as a prototypical representative of a nested Cloud-in-a-VM and evaluate it in the context of a market-driven cloud resource service economy.