M2: Malleable Metal as a Service

Abstract

Existing bare-metal cloud services that provide users with physical nodes have a number of serious disadvantage over their virtual alternatives, including slow provisioning times, difficulty for users to release nodes and then reuse them to handle changes in demand, and poor tolerance to failures. We introduce M2, a bare-metal cloud service that uses network-mounted boot drives to overcome these disadvantages. We describe the architecture and implementation of M2 and compare its agility, scalability and performance to existing systems. We show that M2 can reduce provisioning time by over 50% while offering richer functionality, and comparable run time performance with respect to tools that provision images into local disks. M2 is open source and available at https://github.com/CCI-MOC/ims. 1 Previous provisioning systems exploited remote storage in special purpose environments, like HPC clusters, where all nodes boot the same kernel.2 As the focus of this work is to improve the provisioning time M2 only network-mounts boot drives that hosts the OS and applications. Data drives are still hosted on the local disks.

A Secure Cloud with Minimal Provider Trust

“…Images are exposed to the nodes via an iSCSI (TGT [19]) service managed by M2 and stored in a Ceph [50] distributed file system. As published previously, M2 is between 3-4 times faster than traditional provisioning systems that install an image into a server's local disk [36].…”

“…Degradation in the unattested experiments is due to a large number of concurrent block requests to the small scale Ceph deployment (with only 27 disks). Experiments [36] with a larger scale Ceph deployment demonstrated better M2 scalability. Performance of a fully attested boot degrades by only 13% as we move to 16 servers.…”

“…The fundamental operations HIL provides are (i) allocation of physical nodes, (ii) allocation of networks, and (iii) connecting these nodes and networks. A tenant can invoke HIL to allocate nodes to an enclave, create a management network between the nodes, and then connect this network to any provisioning tool (e.g., [9,14,17,36]). She can then create additional networks for isolated communication between nodes and/or attach those nodes to public networks made available by the provider.…”

“…Malleable Metal as a Service: The Malleable Metal-as-a-Service (M2) [36] is our implementation of the Bolted provisioning service. The fundamental operations M2 provides are: (i) create (disk) image, (ii) clone and snapshot an image, (iii) delete an image, and (iv) boot a node from an image.…”

Supporting Security Sensitive Tenants in a Bare-Metal Cloud

“…A prototype implementation of the Bolted architecture where all its components are made available by us opensource, including the isolation service (Hardware Isolation Layer [5,36]), a deterministic Linux-based minimal firmware (LinuxBoot [6,39], a disk-less bare-metal provisioning service (Bare Metal Imaging [7,57]), a remote attestation service (Keylime [9,73]), and scripts that interact with the various services to elastically create secure private enclaves. As we will discuss later, only the microservice providing isolation (i.e., Hardware Isolation Layer ) is in the TCB and we show that this can, in fact, be quite small; just over 3K LOC in our implementation.…”