RZ 3783 (# Z1010-001) 10/21/2010 Computer Science 6 pages Research Report Dependable Storage in the Intercloud C. Cachin, R. Haas, M. Vukolić IBM Research – Zurich 8803 Rüschlikon Switzerland LIMITED DISTRIBUTION NOTICE This report will be distributed outside of IBM up to one year after the IBM publication date. Some reports are available at http://domino.watson.ibm.com/library/Cyberdig.nsf/home. Research Almaden • Austin • Beijing • Delhi • Haifa • T.J. Watson • Tokyo • Zurich Dependable Storage in the Intercloud∗ Christian Cachin Robert Haas Marko Vukolic´ IBM Research - Zurich IBM Research - Zurich IBM Research - Zurich [email protected] [email protected] [email protected] Abstract like multi-tenancy entail vulnerabilities. More specifi- cally, often cited problems include data confidentiality The cloud computing paradigm with its elastic pay- and integrity, but also reliability and consistency of the as-you-go model, “infinite” scalability and “always-on” contracted service (we collectively refer to these four di- availability arguably changes the landscape of services mensions as CIRC). and systems. However, so far, cloud proliferation has not We believe that a promising solution for improved lived up to expectations in the enterprise segment. Often cloud security and dependability lies in the Intercloud1, cited issues include confidentiality and integrity, but also the cloud of clouds, and goes beyond adding perfection reliability and consistency. to single, isolated clouds. In this paper, we first argue In this paper, we argue for the Intercloud as the sec- for the Intercloud as the second layer in the dependable ond layer in the cloud computing stack, with the goal of cloud computing stack for the next-generation cloud. building more dependable cloud services and systems. In The upcoming Intercloud and today’s single-provider the Intercloud layer, we foresee client-centric distributed clouds are two separate layers in the cloud computing protocols to complement more provider-centric, large- stack of tomorrow (Fig. 1) that complement each other. scale ones in the (Intra)cloud layer. These client-centric The Intercloud offers promising solutions for enhanced protocols orchestrate multiple clouds to boost depend- dependability. Secondly, we present the design of a ser- ability by leveraging inherent cloud heterogeneity and vice in the Intercloud, which exploits the unique features failure independence. of this model: An Interclud storage (ICStore) service that We also discuss the design of Intercloud storage, is currently under development and addresses the CIRC which we currently are implementing, as a primer for dimensions through a layered architecture (Sec. 3). dependable services in the Intercloud. Intercloud Stor- age precisely addresses and improves the CIRC attributes (confidentiality, integrity, reliability and consistency) of 2 Dependable Cloud Computing Stack today’s cloud storage services. In this section, we first overview the single-domain cloud layer and its dependability limitations and then argue for 1 Introduction looking at Intercloud for solutions. Cloud computing promises to the client an elastic pay- 2.1 Single-Domain Cloud and Limitations as-you-go model, “infinite” scalability and “always-on” availability, which renders it appealing for data and com- This layer encompasses most of the cloud computing putation outsourcing, both for consumers that want to systems to date, and consists of distributed protocols de- share their pictures with friends and for enterprises that signed to run in a single administrative domain, typically want to reduce their IT budgets. under the control of one service provider (e.g., Amazon 2 3 4 However, there are obvious dependability and security AWS , Google Apps , Nirvanix ). Distributed protocols concerns associated with outsourcing data and computa- used in this context are intended for wide-area systems, tion to a potentially untrusted third-party (cloud). Even 1http://www.google.com/search?q=intercloud if the cloud provider is itself trusted by the client, issues 2http://aws.amazon.com/ 3http://www.google.com/a/ ∗IBM Research Report RZ 3783, May 28, 2010. 4http://www.nirvanix.com/ 1 ity issues, we propose to look at the Intercloud. Client Dependability Confidentiality Intercloud Integrity 2.2 Intercloud Layer Reliability Consistency We advocate to leverage a multitude of cloud providers Scalability for addressing dependability issues and limitations of Single-domain cloud High availability isolated single-domain clouds. These multiple cloud providers form the Intercloud, which we expect to be- Cloud computing layer Focal goals come an increasingly relevant layer in the cloud comput- ing model at large, which resides on top of the single- Figure 1: Dependable cloud computing stack. domain cloud layer. The Intercloud layer offers a unique environment for building dependable services. Consider, for example, with scalability to a very large number of clients and high fault-tolerance as one of the key aspects of dependabil- availability as their most important goals [18]. ity. A fundamental assumption, on which virtually all The dependability and security of a single-domain fault-tolerant dependable systems rely, is the failure in- cloud, especially its integrity, confidentiality, and isola- dependence assumption. This assumption comes in dif- tion for data and computations in a multi-tenant model, ferent flavors, ranging from classical threshold failure as- are receiving increased attention (e.g., [5, 16]). However, sumptions to non-threshold failure models (e.g., [12]). In devising a dependable service while relying on offerings the first case, failure independence is reflected through of a single cloud provider P has its inherent limitations, the assumption that only the number of faulty processes since all trust in the system reduces to trusting P . Con- counts, i.e., up to t but not t + 1 or more processes may sider for example, encryption as the classical way for fail; in the second case, failure independence is assumed achieving data confidentiality. Encryption creates keys across different fault-prone sets. However, the cover- to be managed: but if a client solely relies on offerings age of this assumption in practice is sometimes small. of provider P , it would have to store encryption keys This remains a weak point of many dependable systems, through a service offered by provider P as well, which and results in the assumption often being criticized. In immediately defeats the benefits of encryption. On the this aspect, the Intercloud is without precedent: it comes other hand, we consider storing the encryption keys lo- with diversity in geographical locations, power supplies, cally at fault-prone clients to be an unacceptable solu- internal cloud architectures, separate administrative do- tion, since losing a key implies losing the encrypted data. mains and different proprietary middleware and applica- Moreover, when data and computation are outsourced to tion implementations. Best of all, this diversity comes to an untrusted cloud, integrity of data and computation can the client essentially for free, because the maintenance be guaranteed only to a certain extent [7]. of such diversified (yet semantically similar) services is Other limitations in relying on a single cloud not the responsibility of a client, but is in the hands provider’s services are related to data reliability and of the separate cloud providers. Since cloud-provided consistency. While clouds are designed to be highly resources are a commodity, their cost is absorbed by available, outages may and do occur at any individual many clients for different tasks. In contrast, maintain- provider (see, e.g., [1] for details). In addition, the net- ing enough diversity for a single task “in-house,” which work to a cloud provider remains a single point of fail- could include (but is not limited to) hardware and operat- ure, especially in the case of cloud providers that do not ing systems diversity, n-version programming and soft- geographically diversify their services. Moreover, net- ware maintenance, and administration know-how, is pro- work connections are particularly vulnerable when the hibitively expensive. Furthermore, trusting the ensemble client resides outside North America and Western Eu- of diversified clouds by distributing trust across differ- rope, where high-bandwidth connections might not be ent cloud domains is an appealing alternative to trusting readily available. Finally, eventual consistency offered (possibly critical) data to a single cloud provider. by many cloud providers, which comes as a byproduct Clearly, the Intercloud layer does not replace the of high availability goals [18], might not be sufficient for single-cloud layer, but greatly expands its scope. We ex- some applications. Single-cloud solutions may give an pect that dependable protocols in the Intercloud will be incentive for a client to locally cache data, in order to client-centric first, where client-side proxies orchestrate avoid consistency problems. But this complicates con- multiple clouds. This will be followed by more sophis- current access to the service or may completely defeat ticated services involving communication among differ- the very purpose of outsourcing data to the cloud. ent cloud services (this is not easily possible today due To cope with these and other single-cloud dependabil- to lack of standardization). We envisage that protocols 2 in the Intercloud add considerable value over the single cloud,