An Architecture for Community Clouds Using
Concepts of the Intercloud
Mark Gall, Angelika Schneider and Niels Fallenbeck Fraunhofer AISEC
Garching, Germany
e-mail:{gall, schneider, fallenbeck}@aisec.fraunhofer.de
Abstract—When cooperating enterprises want to build a com-munity cloud and don’t want to burden only a single partner with the provisioning of the cloud infrastructure, they need an architecture that combines the cloud resources from different sites to form a single community cloud. While the idea is similar to grid computing the control over how the resources are used does not stay with the site, but is transferred to the user. Assuming that the IT infrastructures of the enterprises at least partly evolve towards a private cloud, the challenges we face become similar to those posed by the Intercloud. The architecture we present in this paper shows how clouds from different administrative domains can be linked together in a secure way. We also present a policy mechanism that allows users to control how their applications are distributed among the distributed architecture. This way it is possible to scale out parts of a distributed application, while other sensitive parts remain in the local cloud.
Keywords-cloud; intercloud; community cloud; policy manage-ment;
I. INTRODUCTION
Cloud computing was introduced with the promise of vir-tually unlimited resources available on-demand for anybody who is willing to pay for it on a pay-per-use basis. This promise can only hold true if several conditions are met, e.g. that the cloud provider can offer enough resources and that the customers’ virtual machines share the underlying physical resources. Small cloud providers, be it commercial resource providers or a company’s in-house IT department, are usually unable to fulfill these requirements.
Recently, the possible ways of cooperation between clouds – often dubbed Intercloud– have become more popular both in industry and academia. Bernstein et al. [1], [2] use the term Intercloud to describe a high level architecture in which all clouds are interconnected analogous to the way networks are interconnected through the internet. Buyya et al. [3] use the term with the notion of market-oriented cloud computing. Their understanding of the term includes a brokering system for the exchange of services. Though Celesti et al. do not use the term continuously in their work on cross-cloud federation, they use it while presenting their “InterCloud Identity Manage-ment Infrastructure” [4]. For them, the term denotes a cloud federation scenario in which clouds cooperate with each other in order to enlarge their computing and storage capabilities.
In this paper, the term Intercloud will be used similar to the latter, but we will focus on small communities of trusted
Infrastructure-as-a-Service (IaaS) clouds, i.e. small numbers of clouds sharing similar security standards. To emphasize the difference between a global Intercloud and our architecture for small communities of trusted clouds, we will use the term
Community Intercloud. Though the idea of a global Intercloud
which would make the collaboration between every cloud possible is intriguing, we believe that cooperation on the level of smaller communities of clouds is a more pressing matter at the moment. Many problems that the Intercloud poses do not depend on the number of clouds cooperating, but emerge already when two heterogeneous clouds from different administrative domains are linked together.
An example for the need of cooperation on the level of smaller communities is given through the research project ASMONIA [5], in the course of which our Community Intercloud approach was developed. It focuses primarily on the development of new security and collaboration concepts in the backend of mobile provider networks. In ASMONIA cloud computing is used to deal with overload and outage situations. Utilization of public cloud resources as offered by Amazon1 or Google2 is not possible in this situation due to privacy regulations and the lack of trust. The expected number of participating clouds in the ASMONIA scenario is relatively small, does not change very often and includes contractual relationships. Thus our Community Intercloud approach can rely on some semi-automated mechanisms concerning the joining and leaving of participating clouds. Throughout this paper, we will use the termparticipating cloud whenever we refer to a single cloud that participates in the Community Intercloud.
For smaller communities of enterprises that have similar security standards and shared concerns, the usage of a global Intercloud might be possible, especially if the individual enterprises were already connected to the Intercloud. While this is not the case, we believe that a solution on a smaller scale such as the usage of a community cloud [6] is a more likely scenario. The reasons for employing a community cloud depend on the shared concerns of the community and can range from basic sharing of resources to more elaborate forms of collaboration between the enterprises. The typical usage scenario of our Community Intercloud Architecture involves
1http://aws.amazon.com/ec2/
2http://cloud.google.com/products/compute-engine.html
cooperating enterprises that combine (parts of) their clouds for horizontal federation [7].
The deployment of such a community cloud poses a chal-lenge. Though the NIST definition also includes the case of one single organization operating the community cloud, other works on community cloud computing [8] assume a distributed architecture. Our Community Intercloud Architecture also follows a distributed approach and uses concepts from the Intercloud to create a community cloud distributed among the participating enterprises without the need of relying on third parties, e.g. an identity provider.
While on an abstract level a community cloud represents a homogenous environment for a user, from the security perspective this is not the case, when it is composed of clouds belonging to different administrative domains. Our Community Intercloud Architecture addresses this issue by including a mechanism that allows us to control the dispersion of cloud applications among the participating clouds. Thus enabling us to configure where sensitive parts of an application are executed, while other parts scale out to other clouds.
The remainder of this paper is organized as follows: Chap-ter II gives an overview of the proposed Community InChap-tercloud Architecture, before chapter III provides a detailed view of our approach including components to address challenges of net-work connectivity and policy management in an Community Intercloud environment. Existing approaches in this area are presented in chapter IV. Chapter V summarizes the described approach and gives a brief outlook of potential research work.
II. COMMUNITYINTERCLOUDARCHITECTURE
This section gives an overview of our Community Intercloud Architecture. We describe the design goals we followed when we designed the architecture and explain its most important components.
A. Design Goals
One of the most important design goals that has driven the design of our Community Intercloud Architecture is robust-ness. Conceptually the Community Intercloud is a large dis-tributed system, thus we have to deal with the usual problems of such systems, e.g. that parts of the system might become temporarily unavailable. As a consequence we designed our architecture in a way that even if parts of the system are unavailable the remaining parts of the system will be able to work properly.
The participating clouds are interconnected as equal peers; no inherent hierarchy between the clouds and no central components provided by a third party are defined using our Community Intercloud approach. This lack of a fixed hierarchy is done intentionally in order to avoid single points of failures and achieve high robustness. We also believe that such an approach, which is basically a concept borrowed from peer-to-peer networks, is very versatile and fits our envisioned scenario.
While our Community Intercloud Architecture interconnects separate clouds from different administrative domains, at the
same time it preserves the autonomy of each cloud. Our architecture is intended for the use in a business environment with enterprises sharing their own cloud infrastructures with each other, so the preservation of their autonomy is an im-portant factor. It is imim-portant to note that our architecture does not force each cloud to act as a resource provider. Participating clouds can also be configured in a way so that they only consume resources. Another consequence of the business environment is the goal to avoid modifications of the existing cloud infrastructures, especially the cloud service APIs since they will already be in use by enterprise cloud applications.
Our architecture does not interfere with the already de-ployed enterprise applications in the participating clouds; they remain fully functional. On the other hand, if the applications are tightly coupled with the cloud service APIs of their local participating cloud, they can only benefit from our Community Intercloud approach after this tight coupling is removed. As our Community Intercloud Architecture enables horizontal federation, applications deployed in the Community Intercloud could at the same time use resources from different clouds. This leads directly to another design goal, which is
independency from the cloud provider for the applications
deployed in the Community Intercloud.
In order to achieve that goal, a certain degree of in-teroperability between the clouds needs to be established. Keahey et al. [9] identified as primary challenges for the achievement of interoperability “virtual image compatibility”, “contextualization compatibility” and “API-level compliance”. All those challenges need to be addressed in order to support a broader range of scenarios. We limit our concern to API-level compliance, since this suffices for our scenario. We can depend on image conversion tools for virtual image compatibility and can avoid automatic contextualization.
B. Architecture Overview
While we interconnect IaaS clouds and allow access to the Community Intercloud in the fashion of a traditional cloud, i.e. using a cloud service API, we basically compose a bigger cloud – the Community Intercloud – in a grid-like way. The Community Intercloud is composed using a middleware deployed inside the individual clouds that creates an overlay network on a peer-to-peer network basis and acts as a gateway for the traffic between the clouds, similar to the tunneling approach used for Sky Computing [9].
Fig. 1 shows a schematic overview of our Community Intercloud Architecture. Two clouds are depicted including the IaaS-level cloud services and their API. Cloud applications are deployed in both clouds, depicted as virtual machines (VMs). The Community Intercloud Middleware is also deployed in VMs and these VMs are securely connected over VPN (virtual private network) with each other, forming an overlay network. The middleware acts as a gateway for the cloud applications. The most important components in Fig. 1 are:
1) Community Intercloud API: The Community Intercloud
Community Intercloud Overlay Network
Cloud Service API Compute Services Networking Services Storage Services Shared Cloud Services
VM Cloud Application OS C Clouuud A liatiooon VM Cloud Application OS Appppliccca C Clouud Apppplicaatiooon OSSS VM Cloud Application OS VM Community Intercloud API Community Intercloud Middleware
Cloud Service API Compute Services Networking Services Storage Services Shared Cloud Services
VM Cloud Application OS C Clouud A liatioon VM Cloud Application OS Appppliccca C Clouud Apppppliccaatioon OSSS VM Cloud Application OS VM Community Intercloud API Community Intercloud Middleware
Fig. 1. Community Intercloud Architecture Overview
a uniform interface to the cloud services provided by the participating clouds; instead of sending requests directly to the cloud service API, the cloud applications use the Community Intercloud API as depicted in Fig. 1. The received requests are passed to the Community Intercloud Middleware that decides to which participating cloud, i.e. cloud service API, the request gets delegated. The concept of such an abstraction API has been proved by several abstraction APIs which came to life
over the last years, e.g. OCCI3. We will not present a new
Community Intercloud API in this paper but rather rely on the existence of such an abstraction API.
2) Community Intercloud Middleware: The Community
In-tercloud Middleware has several functions, some of which we will discuss in more detail in the next section. As mentioned earlier, the Community Intercloud Middleware is deployed in VMs and is responsible to create a secure overlay network for the communication between the participating clouds. It also needs to register the cloud services that are available in each participating cloud and takes care of the policy management that handles the access to the cloud service APIs. Fig. 1 also shows the connection between two instances of the Community Intercloud Middleware and indicates that they schedule the requests between them. The scheduling decides to which cloud the requests are delegated to, judging from the incoming requests received from the Community Intercloud API.
III. COMMUNITYINTERCLOUDMIDDLEWARE
This section describes some aspects of the Community Intercloud Middleware in more detail. The middleware is deployed as an ordinary cloud application in each participating cloud. Fig. 1 shows it as a single VM, which is a simplification ignoring load balancers and horizontal scaling mechanisms which can be put in place. It is important to note that the Community Intercloud Middleware will need to be able to scale, because it has to act as a network gateway for the cloud applications in some cases, e.g. when the cloud application is designed as a distributed application with parts running in different clouds.
3http://occi-wg.org/
When the middleware receives a request from the Commu-nity Intercloud API, the request is of a uniform format that all instances of the middleware deployed in the interconnected clouds can process. The scheduling decision made by the middleware is controlled using policies, which allows for a flexible system that can easily adapt to the changes in the composition of the Community Intercloud, i.e. the joining or leaving of clouds. It also allows the integration of access control into the scheduling decision. We will discuss the integration of the policy management into the Community Intercloud Architecture and more details on its use in a separate section.
For being able to make a scheduling decision the middle-ware needs information about the cloud services provided by each participating cloud. It also needs to be able to relate the requirements concerning a service from the incoming requests to this information. The range of values of a requirement and its representation in an incoming request are defined by the Community Intercloud API, which enforces a uniform representation and defines the valid values. The occurring degree of variance of the information about the cloud services depends on the diversity of the services. A solution tackling the problem in its full complexity will need to use a complex ontology and catalog system similar to the one Bernstein et
al. outlined [2], which is based on RDF/OWL4. Our solution
can avoid the use of a complex ontology by restricting the problem to include only a specified set of services. With our focus on small communities this is a feasible solution. A. Community Intercloud Overlay Network
The Community Intercloud Overlay Network is an unstruc-tured peer-to-peer network created by the VMs running the Community Intercloud Middleware, which acts as peers. The middleware plays a role similar to a Virtual Router (VR) proposed in the ViNe architecture [10], though the network connections between the middleware instances are secured using VPN.
It is worth noting that the Community Intercloud Overlay Network is not designed for high scalability, handling thou-sands of peers. Moreover, all peers are known and trusted and the overlay network does not allow ad-hoc connections of new unknown peers. This is because our Community Intercloud ap-proach focuses on smaller communities of enterprises working together. Thus the expected number of peers is relatively low and the frequency with which new peers join and old peers leave the community is also low.
Joining the community requires a signed contract between all participants so that only authorized peers are able to connect to the Community Intercloud. The public keys for authentication are exchanged when a new participating cloud joins the community forming the Community Intercloud. The public keys are used to authenticate the participating clouds, as well as to establish the VPN connection between the participating clouds.
A
KB, KCB
KA,KC,C
KA, KBD
KB KD KB Authentication (steps 1-4) send list of credentials (step 5) send credentials of D (step 6) send credentials of D (step 6)Fig. 2. New participating cloud D joins the community
It is important to distinguish between the usual joining or leaving of the network that occurs in a peer-to-peer network and the joining or leaving of the community. In our case joining or leaving the network means that the VPN connection broke down due to an error and will be reestablished when the peers have recovered from the error. Joining the community means that a new participating cloud needs to negotiate the contract, i.e. the enterprise owning the cloud, and exchange the public keys for the authentication as described later. Thereafter the VPN tunnel remains open as long as the participating cloud belongs to the community. Leaving the community means that the participating cloud leaving is excluded from the Community Intercloud and will not be able to connect to it anymore using its public key.
The participating clouds authenticate themselves with each other using the public key they exchanged when they joined the community. We decided to use a decentralized authen-tication mechanism, because it fits well with our distributed architecture. It also helps to achieve our robustness design goal by avoiding the use of a single point of failure. As our focus lies on small communities of clouds, complex authentication mechanisms relying on identity providers or third parties are not necessary, and would introduce a single point of failure.
1) Participating cloud joins the community: As mentioned
earlier, the frequency with which new participating clouds join or leave the community is expected to be low. Thus we are able to choose a semi-automated mechanism to handle this event. Fig. 2 gives a schematic overview of the authentication mechanism when a new participating cloud joins, while its individual steps are shown in form of a protocol in table I.
Before a new participating cloud can join the community, we expect that the enterprise owning the cloud signs a contract with the other community members. As this step is more on a process management level we did not include this step in our mechanism. After the contract has been signed, our mechanism can start. The new participating cloud D creates an asymmetric key pair (step 1a) and exchanges its public key and IP address (step 1b) with another participating cloud (B in Fig. 2). It is up to them which channel they use for the exchange – e.g. an USB token or e-mail – but they have to ensure the channel
TABLE I
PARTICIPATING CLOUD JOINS THE COMMUNITY
1a D generate public key pairKpubD ,KprivD
1b B,D exchange public keysKpubB ,KpubD and the corresponding IPs
2a D generaten
2b D → B sendn
2c B → D sendenc(KpubD , sig(KprivB , n))
2d D dec(KprivD , enc(KpubD , sig(KprivB , n)))
2e D ver(KBpub, sig(KprivB , n))=? n
3a B generaten
3a B → D sendn
3b D → B sendenc(KpubB , sig(KprivD , n))
3c B dec(KprivB , enc(KpubB , sig(KprivD , n)))
3d B ver(KDpub, sig(KprivD , n))=? n
4 B,D establish VPN connection
5 B → D send list of public keys and IPs of all other participants
6 B → A, C send public keyKprivD and IP of new participant D
integrity.
The remaining steps of the protocol can be completely auto-mated. B and D authenticate each other with their respective public keys (steps 2 and 3). After successful authentication they establish a secure VPN connection (step 4) and B sends D the public keys and ips of all other participating clouds (step 5) and B also sends the public key and IP of D to all other participating clouds (step 6). After that all participating clouds have the public key of the new authenticated participating cloud and vice versa. From now on all participating clouds can establish VPN connections with the new participating cloud.
Steps 2-6 of our mechanism are used to propagate the public key of the new participating cloud to all other participating clouds and vice versa. This is done to simplify the key exchange, as only two parties need to exchange the keys manually. But it is also possible that all the participating clouds exchange the public keys manually as in step 1b.
2) Participating cloud leaves the community: The
mech-anism that takes care of a participating cloud leaving the community is also semi-automated. When a participating cloud leaves the community, this includes again a step on the process management level – the termination of the signed agreement. Thereafter one of the remaining participating clouds needs to trigger the process for deleting the VPN credentials of the leaving cloud.
The first step, which is simply the trigger to start the process, needs to be done manually. Of course it might be possible to use a cron job as a trigger at a specific date and time, but then somebody needs to create the cron job. After the trigger starts the process, the remaining steps of the process are fully automated. First of all, the public key of the leaving cloud is marked invalid locally. Subsequently the information needs to be propagated to all other participating clouds by sending messages to them with the instruction to invalidate the public key of the leaving participant. Each cloud has the public key of all other participating clouds, hence every cloud is able to
Cloud Provider A
Customer B
VM VM
VM
Community Intercloud Resources for Provider B
VM VM VM Customer A VM VM VM VM VM Cloud Provider B Community Intercloud Management VM Community Intercloud API Community Intercloud Middleware Customer D VM VM VM Customer C VM VM VM
Community Intercloud Resources for Provider A VM VM Community Intercloud Management VM Community Intercloud API Community Intercloud Middleware Community Intercloud Overlay Network VM VM VM
Fig. 3. Community Intercloud Overlay Network Topology
send the message to invalidate public keys to all other clouds. It is possible that a cloud is not reachable when this process is executed and thus does not receive the message. The cloud propagating the information must ensure that the message will be resent until all participating clouds have received it.
This mechanism could be used by a participating cloud to launch an internal attack against another participating cloud. But as we assure that the messages sent are irrefutable, we assume that no participant will carry out such an attack. Being irrefutable the messages can be easily traced back to the attacker by the other participating clouds, who will be sanctioned, e.g. by excluding the attacker from the community. Fig. 3 illustrates how the network topology looks like when two clouds are joined together with the Community Intercloud Middleware. In our example each cloud contains four different subnets used to separate the VMs of the different customers and the management of the Community Intercloud Middleware: two subnets are used by customers of the cloud provider, one subnet is used for the management of the Com-munity Intercloud Middleware (labeled ComCom-munity Intercloud Management) and one subnet is used for providing resources for the other cloud (labeled Community Intercloud Resources). The network topology inside a cloud can vary, as it depends on the deployment the cloud provider uses. The situation in Fig. 3 depicts one of the more complicated network configurations
possible in OpenStack5, an open source cloud software.
Similar to the VRs from ViNe [10], our middleware can act as a gateway tunneling the network traffic for the VMs of a cloud provider that take part in the Community Intercloud. The VMs are grouped into different virtual networks managed by the middleware. This virtual network structure is necessary to achieve the isolation of customer VMs in the Community Intercloud Resources subnet, similar to the isolation in a usual cloud deployment. Fig. 3 depicts the different virtual networks using different shades of grey. While all VMs in the Community Intercloud Resources subnet are by default routed through the middleware and divided into the virtual networks, the VMs from the customer subnet are not (white VMs in
5http://www.openstack.org/
Fig. 3), but can be configured to (grey VMs).
The subnets hosting customer VMs in a cloud deployment usually use private IP addresses; in our case this also includes the subnets hosting the Community Intercloud Resources. This represents a limitation, as it is possible that two clouds use the same IP addresses, resulting in a collision of IP spaces. B. Policy Management
Policies play an important role in our Community Intercloud architecture, because it joins together individual cloud infras-tructures possibly located in different administrative domains. To protect its respective administrative domain from unautho-rized access, each cloud needs to define access policies for the other clouds. It is equally important for a cloud to define policies that restrict the access to other domains, e.g. for the purpose of data leakage prevention. For the further discussion
we will use the terms originating cloud for the cloud that
originally received a request from a cloud application and
fulfilling cloudfor the cloud that fulfills the request, whenever
we need to differentiate between them.
The use of policies also allows the creation of a more flexible system that can be adapted to the needs of the users and the changing conditions of the environment, i.e. clouds joining and leaving the community. In our Community Intercloud Architecture policies are used to:
1) Define the amount of shared resources: In the proposed
Community Intercloud Architecture participating clouds are interconnected as peers. In the most basic scenario, which does not require the use of policies, each cloud offers all of its available resources to the other clouds. That means that each cloud can act as a consumer of resources of another cloud, as well as a provider of resources for another cloud. More complex scenarios can be addressed with policies, e.g. when a cloud needs to hold a certain amount of resources available for an important local application, or if it wants to restrict the usage of resources for one specific cloud. The amount of shared resources can easily be changed by adapting the policies, allowing the dynamic regulation of the amount of shared resources.
2) Define the conditions for cloud bursts: From the per-spective of each individual participating cloud, our Community Intercloud architecture can be used to realize a hybrid cloud deployment model [6] that enables cloud bursting [11]. The usual cloud bursting scenario involves a private cloud running out of resources that requests additional resources from a public cloud, thus “bursting” into the public cloud.
By allowing the users to add their own policies we are able to influence the scheduling decision of the Community Inter-cloud Middleware in a very flexible way. The scenario we have in mind is that of a cloud application, developed in a modular fashion just like GrepTheWeb [12]. Some components of such an application might require access to sensitive data and process it, resulting in the component being considered sensitive as well. A user might want to run those components in specific trusted clouds, fearing that the providers of other clouds might copy the virtual machine images while they are processing the data. At the same time, other components that are not considered sensitive could be scaled out to whatever cloud having enough resources.
3) Define fine-grained access control for Community
Inter-cloud services: While a basic access control mechanism can
be utilized to grant the interconnected clouds access to each other and the services they provide, our Community Intercloud architecture allows a more fine-grained access control for the cloud services. With the help of policies it is possible to provide different kinds of services with the same cloud service to different administrative domains. For example one cloud provider could make certain kinds of virtual machines only available for users from his own administrative domain.
Our solution for the integration of a XACML-based policy management [13] focuses on the access control of the cloud service APIs, i.e. the objects of our policies are the services provided by the APIs. This allows us to achieve the aforemen-tioned goals. But this also presents a limitation. The access to already created VMs does usually not involve requests to a cloud service API, so our policy management is unable to deal with them. On the other hand, our approach works fine in conjunction with cloud storage services because access to those services usually includes requests to the cloud service API. But in that case the access control only happens on the application level and not on user level.
Fig. 4 shows how the policy management is integrated in the Community Intercloud Architecture. Instead of directly calling the cloud API of the respective cloud it is deployed in, a cloud application uses the Community Intercloud API. The requests sent to the Community Intercloud API are passed to the Community Intercloud Middleware that decides to which cloud the requests will be forwarded. The integration of a policy management based on XACML is possible by intercepting the requests after the Community Intercloud API receives them but before the decision is made to which cloud API they will be delegated.
Fig. 4 shows the flow of events that occurs, e.g. when a controller component of a distributed cloud application requests a new worker component. After the request is received
Community Intercloud Overlay Network
Community Intercloud Middleware VM Cloud Application OS Cloud API PEP PDP Cloud API Community Intercloud API
Community Intercloud Middleware
PEP PDP
Community Intercloud API
1 2 3 4b 4a 5b 6b 7b 8b
Fig. 4. Policy Management in the Community Intercloud
by the Community Intercloud API, the API passes it to the Policy Enforcement Point (PEP) inside the Community Intercloud Middleware (step 1), which consults the Policy Decision Point (PDP) for a decision (step 2). This step is simplified compared to the XACML 3.0 specification, which uses a context handler as an intermediary between PEP and PDP. After a decision has been reached (step 3), the PEP passes the request to the Community Intercloud Middleware including instructions how to forward the request. This only happens if the request complies with the policies known to the PDP, otherwise the request is rejected and the application gets an negative response.
At this point, i.e. when the request was judged valid by the PDP, two cases need to be differentiated:
a) The PEP tells the Community Intercloud Middleware to delegate the request to the originating cloud. The middleware can then delegate the request to the cloud API of the originating cloud and the request gets processed (step 4a).
b) The request needs to be transferred to another cloud, the fulfilling cloud. The Community Intercloud Middle-ware of the originating cloud sends the request to the middleware of the fulfilling cloud (step 4b). The request enters a different administrative domain at this point. So a check for the compliance to the policies of the fulfilling domain needs to be executed including the same steps as mentioned above until the request reaches the cloud API of the target cloud and can be processed there (steps 5b-8b).
Our policy management works under the assumption that the fulfilling cloud either fulfills a received request or rejects it. The fulfilling cloud is not allowed to further pass the request to another cloud, which can potentially violate the policies of the originating cloud. From the point of view of the originating cloud the policies define which one of the other interconnected clouds is allowed to fulfill the request. From the point of view of the fulfilling cloud the policies define which services are accessible for other interconnected clouds.
IV. RELATEDWORK
Similar to us, Marinos et al. [8] proposed an architecture for Community Cloud Computing. Their architecture involves all virtual machines that are part of their Community Cloud to form a peer-to-peer network, while our architecture uses one virtual machine running the middleware per cloud to form the network and tunnel the network traffic between them. This means that the middleware acts on behalf of the cloud it resides in, so that the clouds interact with each other.
In this way our Community Intercloud Architecture is related to the work on the Intercloud topic. Bernstein et al. introduce a high level architecture of the Intercloud in which all clouds are interconnected, point out several problems that the Intercloud poses and discuss technologies that might be used to solve these problems [1]. Their work focuses on a federation of massive scale addressing topics such as Identity Federation Model [14] and an Intercloud Directory Exchange Protocol [2]. Their approach depends on an organization that governs the Intercloud infrastructure, similar to ICANN governing the top level domains, which is something we are able to avoid.
The high-level Intercloud architecture presented by Buyya et al. [3] focuses on so-called market-oriented cloud computing, which includes the existence of cloud brokers and a “Cloud Exchange”. The “Cloud Exchange” allows the trading of cloud services on competitive economic models, e.g. auctions. For the federation of the clouds the middleware Aneka [15] is used. It differs from our approach in the way that the Aneka container needs to reside in each host of the participating cloud, whereas our solution works through a gateway that creates the access to participating clouds and their hosts.
Celesti et. al. [4], [7], [16] present a federation model allowing a cloud to establish an interoperable heterogenous cloud environment for on-demand resource provisioning. In this context, they introduce their authentication phase for a dis-tributed scenario with hundreds of clouds which could support different authentication mechanisms. However, their approach requires the usage of an external Identity Provider/Service Provider. Our Community Intercloud approach avoids the dependency on third party Identity Providers by employing a simple yet robust authentication mechanism.
Maximilien et al. [17] point out the need for a cloud-agnostic middleware and show a high-level architecture of their middleware. It includes an abstraction API and focuses on the deployment of VMs. But they focus on employing their middleware on a single cloud and do not present a concept for connecting two or more clouds.
Linking high performance computing resources from dif-ferent research institutions together has been one of the the main motivations in Grid computing, a term coined by Ian Foster and Carl Kesselman [18], [19]. The Grid bases on a middleware which provides identity management functionality as well as data management functions. The necessity of using and managing VMs in a distributed Grid environment has been identified early by research groups around the world
[20]–[24]. Though our middleware has similar functions to a grid middleware, i.e. it links together cloud computing infrastructures instead of grid computing infrastructures, the control of the scheduling decisions of our middleware can be influenced by user controlled policies. This is in contrast with the general assumption in grid computing that the control over how resources are used stays with the site [9].
Nimbus (formerly known as Virtual Workspaces) [9], [25], [26] is able to use cloud resources when local resources become insufficient for the actual workload. Since Nimbus has its origins in Grid computing, it can deal with local cluster resource managers (CRMs) such as the Oracle (formerly: Sun) Grid Engine [27] which manages the execution of compu-tational tasks on a Grid site. Originally, Nimbus has been built focused on the compute job-centric approach of Grid computing, but recent versions of the Nimbus Infrastructure can provide resources without relying on CRMs. Although Nimbus can use VMs hosted in the cloud to provide additional resources, it has not been designed with focus of linking different existing independent clouds together which are not under central control.
Keahey et al. [9] propose the idea of Sky computing which aims at linking different Grid or cloud sites together. They point out several requirements for an Intercloud middleware including the necessity to provide the users with virtual network space which is used to connect the users’ virtual machines hosted on the different participating clouds. They focus on the deployment of distributed applications, but do not present a mechanism to influence the scaling mechanism with user controlled policies.
ViNe [10], [28] has been designed to provide a virtual network overlay regardless of the particular machines within the virtual network having public IP addresses or not. This approach tackles many of the requirements of Intercloud net-work connections but does not provide an encrypted netnet-work link between the host within the different participating clouds. Takeda et. al. [29] propose a decentralized mutual authenti-cation mechanism for peer-to-peer networks where millions of nodes communicate with each other. Their approach does not involve a trusted third party, but uses a distributed management of public keys by employing Web of Trust (PGP) and dis-tributed hash tables. They also describe a node authentication method, using neither Web of Trust nor any third party, that depends only on public keys and signatures. We employ an authentication mechanism similar to that, because this is the simplest and least expensive way and fits our scenario well.
V. CONCLUSION ANDFUTUREWORK
In this paper we have proposed an architecture for a Community Intercloud that links together clouds from different administrative domains. Central point of our architecture is the Community Intercloud Middleware, which overcomes many of the problems that arise in such a heterogeneous environment without relying on third parties or central components. Even if parts of the Community Intercloud fail, the other parts remain fully functional. The policy management integrated in our
architecture allows us to define a fine-grained access control on the cloud services and can be used to control the scaling process of applications. This way it is possible to scale out parts of a distributed application, while other sensitive parts remain in the local cloud.
We will work on the development of a prototype for the proposed Community Intercloud Architecture and test it for both our envisioned scenarios. For the current version of our prototype we assume that the participating clouds do not use the same private IP addresses. We will evaluate how we can address this issue in a next step of our prototype, e.g. by using NAT. Also we plan to expand the policy management to involve multiple PDPs in the decision making process to avoid the overhead of checking the requests twice, for example by using metapolicies [30], making it possible to intercept requests only once.
ACKNOWLEDGMENT
Parts of this work were supported by the German Federal Ministry of Education and Research (BMBF) under grant 01BY1011 within the project ASMONIA.
REFERENCES
[1] D. Bernstein, E. Ludvigson, K. Sankar, S. Diamond, and M. Morrow, “Blueprint for the Intercloud - Protocols and Formats for Cloud Comput-ing Interoperability,”2009 Fourth International Conference on Internet and Web Applications and Services, vol. on, pp. 328–336, 2009. [2] D. Bernstein and D. Vij, “Intercloud Directory and Exchange Protocol
Detail Using XMPP and RDF,” pp. 431–438, 2010.
[3] R. Buyya, R. Ranjan, and R. N. Calheiros, “InterCloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services,”Algorithms and Architectures for Parallel Processing, vol. 6081, no. PART 1, p. 20, 2010.
[4] A. Celesti, F. Tusa, M. Villari, and A. Puliafito, “Security and cloud computing: Intercloud identity management infrastructure,” inEnabling Technologies: Infrastructures for Collaborative Enterprises (WETICE), 2010 19th IEEE International Workshop on. IEEE, 2010, pp. 263–265. [5] J. Lueken, M. Gall, B. Jaeger, R. Koch, M. Luft, and A. Schneider, “D3.2: Architecture Concept for the Use of Cloud Systems,” 2012. [Online]. Available: http://www.asmonia.de/index.php?page=20 [6] P. Mell and T. Grance, “The NIST Definition of Cloud Computing
(Draft),” Nist Special Publication, vol. 145, no. 6, p. 7, 2011. [Online]. Available: http://csrc.nist.gov/publications/nistpubs/800-145/ SP800-145.pdf
[7] A. Celesti, F. Tusa, M. Villari, and A. Puliafito, “How to enhance cloud architectures to enable cross-federation,” inCloud Computing (CLOUD), 2010 IEEE 3rd International Conference on. IEEE, 2010, pp. 337–345. [8] A. Marinos and G. Briscoe, “Community cloud computing,” Cloud
Computing, pp. 472–484, 2009.
[9] K. Keahey, M. Tsugawa, A. Matsunaga, and J. Fortes, “Sky computing,”
Internet Computing, IEEE, vol. 13, no. 5, pp. 43–51, 2009.
[10] M. Tsugawa and J. A. B. Fortes, “A Virtual Network (ViNe) Architecture for Grid Computing,” inParallel and Distributed Processing Symposium, 2006. IPDPS 2006. 20th International. IEEE, 2006, pp. 10–pp. [11] T. Guo, U. Sharma, T. Wood, S. Sahu, and P. Shenoy, “Seagull:
Intelligent Cloud Bursting for Enterprise Applications,” inProceedings of the Usenix Annual Technical Conference (short paper), Jun. 2012. [12] “Building GrepTheWeb in the Cloud, Part 1: Cloud Architectures,” 2008.
[Online]. Available: http://aws.amazon.com/articles/1632? encoding= UTF8&jiveRedirect=1
[13] “OASIS eXtensible Access Control Markup Language (XACML),” 2012. [Online]. Available: https://www.oasis-open.org/committees/tc home.php?wg abbrev=xacml
[14] D. Bernstein and D. Vij, “Intercloud Security Considerations,” 2010 IEEE Second International Conference on Cloud Computing Technology and Science, pp. 537–544, 2010.
[15] C. Vecchiola, X. Chu, and R. Buyya, “Aneka: A Software Platform for .NET-based Cloud Computing,”The Computing Research Repository CoRR, vol. abs/0907.4, p. 30, 2009. [Online]. Available: http://arxiv.org/abs/0907.4622
[16] A. Celesti, F. Tusa, M. Villari, and A. Puliafito, “Three-phase cross-cloud federation model: The cloud sso authentication,” inAdvances in Future Internet (AFIN), 2010 Second International Conference on. IEEE, 2010, pp. 94–101.
[17] E. Maximilien, A. Ranabahu, R. Engehausen, and L. Anderson, “Toward cloud-agnostic middlewares,” inProceeding of the 24th ACM SIGPLAN conference companion on Object oriented programming systems lan-guages and applications. ACM, 2009, pp. 619–626.
[18] I. Foster and C. Kesselman, “Globus: A Metacomputing Infrastructure Toolkit,”International Journal of High Performance Computing Appli-cations, vol. 11, no. 2, pp. 115–128, 1997.
[19] I. Foster, “Globus Toolkit Version 4: Software for Service-Oriented Systems,”FIP International Conference on Network and Parallel Com-puting, vol. 4, no. 21, pp. 513–520, 2006.
[20] I. Krsul, A. Ganguly, J. Zhang, J. A. B. Fortes, and R. J. Figueiredo, “VMPlants: Providing and Managing Virtual Machine Execution En-vironments for Grid Computing,”SC ’04: Proceedings of the 2004 ACM/IEEE conference on Supercomputing, 2004.
[21] K. Keahey, I. Foster, T. Freeman, X. Zhang, and D. Galron, “Virtual Workspaces in the Grid,”Lecture Notes in Computer Science, pp. 22– 34, 2005.
[22] P. Ruth, X. Jiang, D. Xu, and S. Goasguen, “Virtual Distributed Environments in a Shared Infrastructure,”Computer, vol. 38, no. 5, pp. 63–69, 2005.
[23] H. Nakada, T. Yokoi, T. Ebara, Y. Tanimura, H. Ogawa, and S. Sekiguchi, “The Design and Implementation of a Virtual Cluster Man-agement System,”Proceedings of 1st IEEE/IFIP International Workshop on End-to-end Virtualization and Grid Management, pp. 61–71, 2007. [24] M. Smith, M. Schmidt, N. Fallenbeck, T. D¨ornemann, C. Schridde, and
B. Freisleben, “Secure on-demand grid computing,”Journal of Future Generation Computer Systems, Elsevier, vol. 25, no. 3, pp. 315–325, 2009.
[25] T. Freeman and K. Keahey, “Flying Low: Simple Leases with Workspace Pilot,”Proceedings of the 14th international Euro-Par Conference on Parallel Processing (Euro-Par ’08), pp. 499–509, Feb. 2008. [26] P. Marshall, K. Keahey, and T. Freeman, “Elastic Site: Using Clouds
to Elastically Extend Site Resources,” Proceedings of the 2010 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Com-puting (CCGRID ’10), pp. 43–52, 2010.
[27] W. Gentzsch, “Sun Grid Engine: Towards Creating a Compute Power Grid,”Proceedings of the First IEEE/ACM International Symposium on Cluster Computing and the Grid, pp. 35–36, 2001.
[28] M. Tsugawa and J. A. B. Fortes, “Characterizing User-Level Network Virtualization: Performance, Overheads and Limits,”Proceedings of the Fourth IEEE Conference on eScience, pp. 206–213, 2008.
[29] A. Takeda, K. Hashimoto, G. Kitagata, S. Zabir, T. Kinoshita, and N. Shiratori, “A new authentication method with distributed hash table for p2p network,” in Advanced Information Networking and Applications-Workshops, 2008. AINAW 2008. 22nd International Con-ference on. IEEE, 2008, pp. 483–488.
[30] J. Sch¨utte, H. S. Fhom, and M. Gall, “Security Policies in Dynamic Ser-vice Compositions,” inProceedings of the 7th International Conference on Security and Cryptography, 2012, pp. 233–238.
