A naming system applied to a RESERVOIR cloud

A Naming System Applied to a RESERVOIR Cloud Antonio Celesti, Massimo Villari, Antonio Puliafito and Francesco Longo Dept. of Mathematics, Faculty of Engineering, University of Messina Contrada di Dio, S. Agata, 98166 Messina, Italy. e-mail: {acelesti, mvillari, apuliafito, flongo}@unime.it

Abstract—Cloud environments offer a variety of concrete and abstracted entities which need to be identified. An example of cloud environment is the European project RESERVOIR, which similarly to other platforms characterized by a high level of dynamism, needs to identify and resolve resources. RESERVOIR has to manage allocation, deallocation and migration of virtual machines from an execution context to another. Such tasks could trigger identity and name alterations; in addition, a virtual machine may hold one or more names, identifiers, and representations in various execution environments. Nowadays, the Internet is using the Domain Name System (DNS), that is not suitable to such emerging scenarios. This paper aims to explore several RESERVOIR use cases, demonstrating how a flexible cloud naming system allows organizations to simplify the management of their assets deployed into the cloud. Keywords-Cloud Computing; Cloud Name Space; Cloud Naming System; RESERVOIR; XRI; XRDS;

I. I NTRODUCTION In cloud computing environments, as well as in all systems characterized by a high level of dynamism, naming and resource location become critical issues. Currently the Internet uses the Domain Name System (DNS) for the resolution of prefixed domain names, that does not seem to be suitable to the new emerging cloud scenarios. In fact, the DNS presents several disadvantages: the traditional resource records are not able to describe complex structured entities and to efficiently remap entities that frequently change their status. For example, a virtual resource, could be allocated, deallocated or moved from a context to another, due to migration mechanisms. Since a migration may trigger an identity alteration, a cloud entity being part of a virtual cloud application could later become part of another cloud application, either in the same cloud or in another cloud if we consider federated environments. In cloud environments there are always more concrete and abstracted entities, which need to be identified both in human-readable and in machine-readable fashion. These entities might hold one or more identifiers also with different levels of abstraction. In such context, the management of cloud entity names and cloud name spaces may become very difficult. As described in [1], a cloud naming system should be characterized by: scalability, extensibility, services of description and discovery, name recycling, non-correlation, and name space integration mechanisms which avoid name conflicts.

This paper aims to apply the cloud naming concepts proposed in [1] to RESERVOIR [2], a real federated cloud architecture. More specifically, we introduce a methodology to design a cloud naming system able to meet as much as possible the requirements of several use cases described in the RESERVOIR architectural document. The main advantages of the proposed cloud naming system are: integration between different cloud name spaces, compatibility with other URI-based naming system and with the public DNS, support to the “mounting” of a cloud name space under other cloud name spaces. Subsequently, we will demonstrate how our solution can help the operation of more federated cloud infrastructures. The paper is organized as follows. Section II provides a brief description of the European 7FP project RESERVOIR. Several use cases are introduced and analyzed, highlighting the involved naming issues. Section III describes the state of the art of naming systems and the most widely adopted solutions of naming in distributed and ubiquitous computing environments. In section IV, we present an analysis the cloud name spaces, introducing the reference framework used to develop our own cloud naming system. In Section V, we show as a possible implementation of the cloud naming framework (based on eXtensible Resource Identifier (XRI) [3], eXtensible Resource Descriptor Sequence (XRDS) [4], and HTTP) can to meet the requirement of the RESERVOIR use cases. Conclusions and lights to the future are summarized in section VI. II. RESERVOIR - A N EXAMPLE OF CLOUD - FEDERATED VIRTUALIZATION INFRASTRUCTURE

In this Section, we describe the RESERVOIR architecture and the involved use cases on which, in Section V, we are going to apply our naming concepts. RESERVOIR introduces an abstraction layer that allows to develop a set of high level management components that are not tied to any specific environment. This abstraction involves a federation of heterogeneous physical infrastructures. In RESERVOIR, more sites can share physical infrastructure resources on which service applications can be executed. Each site is partitioned by a virtualization layer into virtual execution environments (VEEs). These environments are fully isolated runtime modules that abstract away the physical characteristics of the resource and enable sharing. The virtualized

computational resources, alongside with the virtualization layer and all the management enablement components, are referred to as the VEE Host. A service application is a set of software components which work to achieve a common goal. Each component of such service application is executed in a dedicated VEE. These VEEs are placed on the same or different VEE Hosts within the site, or even on different sites. We underline, that neither the Service Provider (SP) nor the final user are aware of the real mapping between service application and hardware resources. Our proposal makes real this assumption, guarantying an high level of cloud interoperability and enabling a transparent interaction among the involved entities. A. Description of the RESERVOIR Use Cases In the architectural RESERVOIR designing phase, several use cases of real applications have been identified and investigated. Such use cases represent the source of user’s requirements that cloud environments should satisfy. Originally these application were thought for traditional distributed systems, but the virtualization technology has permitted the execution of them into the cloud. 1) The Telco Application Use Case: The Telco application use case focuses on building a complete computing environment in which a Telco operator, such as Telef´onica, could host massive access Web Services, such as one linked to a worldwide event, like the Olympics, or a service like Youtube. This use case will develop a “Platform as a Service” (PaaS) business model where the Telco operator could host owned or third party services over a Cloud Computing infrastructure, integrating them using the Web 2.0 EzWeb integration platform. Third party service could be created with platform services (billing, messaging, video streaming, VoIP, etc.). To deploy such a system in a Cloud infrastructure it is necessary to guarantee intercommunication among all the components of the platform (PaaS). This determines a transparent intercommunication among the inter-domain federated networks. All Web Services have also to be identified when are spreading among many sites. Finally the monitoring, billing and accounting policies need a common framework in which to interact and also exchange data. Thus, network management, name service consistency and data intercommunication framework represent a big challenge in this cloud context. 2) The Utility Computing Application Use Case: It is based on the Sun Grid Engine (SGE or GE), an application able to provide Grid functionalities confined into virtual environments.The SGE provides workload management and dynamic provisioning of application workloads. The SGE accepts jobs from the outside world, queues and schedules them according to policies. A Sun Grid Engine cluster consists of the following core components: hosts, daemons and queues. Hosts present four types of configuration: Master

Host, Execution Host, Administration Host and Submit Host. Three daemons characterize the Sun infrastructure: Master Daemon, Scheduler Daemon, and Execution Daemon. A queue is a container for a class of jobs that are allowed to run on one or more hosts concurrently. A queue determines certain job attributes, for example, whether the job can be migrated. To deploy such a system in a Cloud infrastructure it is necessary to guarantee intercommunication among all the Virtual Machine hosting the GRID environment. The main constrain in such a context is that the virtual resources management has to be totally transparent respect to the overall native functionalities of the SGE. 3) The eBusiness Application Use Case: It is based on a commercial application, the SAP software customers management. The use case described below illustrates the case of providing a pre-existing application (that was not necessarily designed for the cloud) on the cloud. A SAP system is a three-tiers system consisting of a presentation layer, application layer and a database layer. The main components are: • The Dialogue Instance (DI) hosts the work processes that execute the “Advanced Business Application Programming” (ABAP) programs as a response to user requests. The number of DIs can be configured for scalability. • There is only a single Central Instance (CI) per SAP system. The CI communicates with the DIs and performs central services such as locking, messaging, registration of DIs, and session initiation and load balancing among DIs. • A single Database Management System (DBMS) serves the SAP system. The DBMS accesses its storage either as a Network-Attached Storage (NAS) or by a Storage Area Network (SAN). From a scalability and robustness point of view, one can add and remove DIs while the system is running, as well as adapt the number of work processes of a specific DI or CI. The components can be arranged in a variety of configurations, from a minimal configuration where all components run on a single machine, to larger ones where there are several DIs, each running on a separate machine, and a separate machine with the CI and the DBMS. The deployment of such a system in a Cloud infrastructure has to guarantee intercommunication among all the physical hosts and hypervisors where the VMs of DIs, CIs and DBMS are confined, even in partner clouds. B. Considerations on the RESERVOIR Use Cases Basically the use cases reported above present several common features and requirements. To simplify the dissertation, we performed a sub selection of the overall customer requirements derived by such use cases. In an early classification, we identified three big management containers in which to confine the main requirements obtained, that are:

•

•

•

Intra/Inter-cloud Virtual resources management for: Virtual Machine Identification, Resources availability, partner cloud discovery, Migration of VMs Monitoring and auditing, Accounting and billing. Network management: public networks for service exposition, cross-sites configuration for fault tolerance, load balancing, and scalability policies, private networks for back-end operations, hybrid networks, public cloud resources linked to legacy resources. Automatic service management: Rapid and Automatic Provisioning of Applications, Elastic Arrays of VMs, Scalability based on elasticity rules, Automating Complex Operations, Operational Flexibility, Automatic Adaptive Resource Allocation.

For elasticity we mean the possibility to increase/decrease the amount of total resources through the cloud federation mechanism. III. BACKGROUND OF D ISTRIBUTED NAMING S YSTEMS Cloud computing is generally considered as one of the more challenging research field in the IT world. It mixes aspects of Utility computing, Grid computing, Internet Computing, Autonomic computing and Green computing [5]. In such a perspective, resource location and identification are critical issues. In literature there are not many works on naming systems in cloud computing, as DNS is still erroneously considered as the “panacea for all ills”. DNS presents some problems: it is host centric, unsuitable for complex data and services location, and it is not suited to heterogeneous environments. An alternative to DNS is presented in [6]. The authors propose a Uniform Resource Name System (URNS), a decentralized solution providing a dynamic and fast resource location system for the resolution of miscellaneous services. The work lacks of an exhaustive resource description mechanism. With regard to naming system in ubiquitous computing, in [7] the authors propose a naming system framework for smart space environments. The framework aims to integrate P2P independent cloud naming systems with the DNS, but appears unfitted to be exported in other environments. In addition it aims to localize and identify an entity that moves from a smart space to another using as description mechanism the little exhaustive DNS resource records. A hybrid naming system that combines DNS and Distributed Hash Table (DHT) is presented in [8]. The authors adopt a set of gateways executing a dynamic DNS name delegation between DNS resolver and DHT node. With regard advanced resource description technologies, OASIS is developing the eXtensible Resource Identifier (XRI) [3], a URI-compatible protocol that provides a uniform syntax for abstract and structured entities. OASIS is also defining a simple generic resource descriptor format (XRDS) [4], that aims to become the standard in the near future. We believe that these protocols

offer excellent potentialities to solve many cloud naming and resource location problems. IV. C LOUDS AND NAMING I SSUES In this Section, we provide a generic analysis of the cloud name space, and we present our Cloud Naming System Framework able to address any cloud use cases. A. The Cloud Name Space Analysis In a high-dynamic federated cloud environment, the design of a cloud naming system could be very hard. First of all, it is not clear which the involved entities and the virtual contexts are. Moreover, in federated environments, a cloud naming system should be able to manage frequent name alteration and name space integration. The following analysis aims to clarify such concerns. Regardless the internal cloud structure, we think a cloud has many logical representations in various abstraction levels. In addition, there are many abstracted, structured entities. These entities are characterized by a high-level of dynamism: allocations, changes and deallocations could occur frequently. Moreover, these entities may have one or more logical representations in one or more contexts. But which are the entities involved in cloud computing? In order to describe such entities, we introduce the generalized concept of Cloud Named Entities Class (CNEC), indicating a set of Cloud Named Entities (CNEs). A CNE is a generic entity indicated by a name or an identifier which may refer both to real/abstracted and simple/structured entities. As depicted in Figure 1, examples of CNE may be a cloud federation, a cloud itself, a subcloud, a cloud application, a site, a host running a hypervisor, virtual machines (VMs), or cloud users including organizations, enterprises, data centers, technicians, and generic human end-users.

Figure 1.

A generic CNE in several cloud contexts (CCNTXs).

In our abstraction, we assume that a CNE is associated to one or more identifiers. Since a CNE is subject to frequent changes holding different representations in various Cloud Contexts (CCNTXs), the user-centric identity model [9] seems to be the most convenient approach. We define a

CCNTX as an environment where a CNE is represented by one or more identifiers. A CCNTX can be a cloud federation, a cloud itself, a sub-cloud, a cloud application or whatever abstracted environment. In this work, we assume a CNE is represented by one or more service end-points (SEPs), which are objects returning metadata associated to a CNE in a given CCNTX. The generic CNE depicted in Figure 1 is associated with six identities within four CCNTXs. The target CNE holds identity 1, 2 inside CCNTX A, identity 3 inside CCNTX B, identity 4 inside CCNTX C, and identity 5, 6 inside CCNTX D. We define a Cloud Naming System (NS) a system that maps one or more identifiers to a CNE. A cloud NS consists of a set of CNEs, an independent cloud name space, and a mapping between them. A cloud name space is a definition of cloud domain names. Instead, a name or identifier is a label used to identify a CNE. A client resolver who needs to identify a CNE in a given CCNTX performs a resolution task. Resolution is the function of referencing an identifier to a set of metadata describing the CNE in a given CCNTX. B. The Cloud Naming System Framework The cloud name space management raises new challenges concerning: compatibility, scalability, extensibility, CNE description, name recycling, non-correlation, and name space integration. Our solution to the problem is a Cloud naming framework placed inside the highest level of a generic threelayers cloud architecture (from the bottom: Virtual Machine Manager, Virtual Infrastructure Manager and Cloud Manager) [10] compliant to the major existing cloud platforms. Since the Cloud Manager layer is responsible for highlevel tasks, we think the framework can provide naming support to monitoring, QoS, security, identity management, federation, and billing. For example, for monitoring purposes the name of a CNE may be resolved with the corresponding performance metadata. Instead, for security purposes, a CNE name could be resolved by means of an identity provider (IdP) asserting its credentials in a given CCNTX. Figure 2 depicts the cloud naming framework in detail.

Figure 2.

Cloud Naming Framework in a generic cloud architecture.

The CNE Descriptor is the component describing a generic CNE. It can be a document containing a set of metadata associated to the target CNE, and a set of pointers to one or more SEPs representing the CNE in various CCNTXs. The Cloud Naming System represents the generic naming system used inside a cloud. The Cloud Name Space Mounter, is the component responsible of mounting a CNE name inside the cloud naming system. The Cloud Naming System Manager is the main component of the framework. It coordinates the whole cloud naming, managing the Cloud Naming System, the mounting of CNE names by means of the Cloud Mounter, the integration with other federated cloud name spaces, and the integration with the public naming system. It plays an important role in cloud name space integration by means of cross-reference and cross-resolver mechanisms. Let us consider two different clouds with different name spaces which establish a federation. With cross-reference mechanisms the two clouds could mount their name spaces under a common root forming a new CNE with a federated name space. Instead, cross-reference mechanisms permit the Cloud Name Space Manager to perform CNE name mounting inside the same name space or from a cloud name space to another. The Cloud Federation Cross-Resolver is the component which defines a cloud federation name space root under which the name spaces of the complying clouds will be linked. Besides defining the name space root, it is also responsible for avoiding name conflicts. In a federated cloud scenario several Cloud Federation Cross-Resolvers may exist, one for each cloud federation. In some cases there may be the need to mount the whole cloud name spaces or part of them in a public name space domain. In such perspective the framework must guarantee interoperability with any public naming system. For such purpose, a Public Naming System Mounter has been designed to act as a gateway between cloud name spaces and the public name space (the DNS). In a distributed scenario many Public Naming System Mounters may be active for each geographical area. V. T HE C LOUD NAMING F RAMEWORK APPLIED TO THE RESERVOIR U SE C ASES In this Section, we demonstrate how it is possible to address both the naming and resource location of the RESERVOIR use cases, using a combination of the XRI and the XRDS technologies, as one of the possible implementation of the Cloud Naming Framework. In fact, the framework acts as an extensible and scalable mapping tool able to logically arrange any cloud scenario. In our opinion, XRI is a protocol offering excellent potentialities to solve many cloud naming issues in cloud environment. Currently XRI does not have many applications, but it is used as part of OpenID [11] a protocol providing Single Sign On (SSO) authentication services. In the following, we demonstrate how XRI is able to solve many naming issues in cloud environments. The

main benefit of using XRI is the support to the hierarchical mounting (and unmounting) of single names or entire name spaces under other names, by means of cross-reference mechanisms. The cross-reference is a property, not available in the DNS, to allow an entire path name to be mounted in another path name. For simplicity, in the following use cases we do not consider neither the mounting of the cloud name space on the public DNS nor the integration between different cloud name spaces, but we specifically focus on the management of a single RESERVOIR name space. A. The Telco Application Use-case In this use case, the Telco Operator, using a PaaS, acts as broker: it uses its own infrastructure or the physical resources rent from external infrastructure providers in order to offer deployment services to its clients (service providers), where they may deploy their services. The service provider will pay the deployment services according to the resource usage, business rules, and SLA contracts. The proposed naming solution allows a hierarchical organization of the involved CNEs, which are the Telco Operator itself, the infrastructures where the service are deployed and the services themselves. As depicted in Figure 3, each XRI name of an infrastructure or aservice has been associated to a XRDS document, which contains the links to several SEPs resolving the CNE in a given CCNTX. For example, the

acts as IDP providing authentication metadata, when Service 2 needs to be identified by an external third party. SEP4 and SEP5 provide respectively information on the service and the relative performance, instead SEP6 resolve the service providing metadata related to resource consumption and billing. B. The Utility Computing Use-case In this use case, a SGE application is deployed into the RESERVOIR infrastructure in order to provide workload management and dynamic provisioning of resources. As depicted in Figure 4, the proposed naming solution allows a hierarchical organization of the involved CNEs, which may be hosts and clusters. Hosts are virtual machine hosted into the RESERVOIR virtualization infrastructure, whereas clusters are groups of virtual machines connected to a virtual network managed by RESERVOIR. The SGE

Figure 4.

Figure 3.

Telco Operator use case.

name xri://@Telco*Infr 1, referred to an infrastructure, is associated to several SEPs, which resolve the name in various CCNTXs. SEP1 provides general info (i.e. whether the infrastructure is physical and owned by the Telco Operator or it is virtual and rent from RESERVOIR), SEP2 provides metadata referred to the performance, SEP3 acts as IDP, asserting the authenticity of the infrastructure, when it needs to access to external assets of third parties. Example of IDP technologies are OpenId [11], SAML [12], and Shibboleth [13]. Instead, the name XRI://@Telco*Infr 1*Service 2 identifies a service deployed in the XRI://@Telco*Infr 1 infrastructure. It may be resolved by means of SEP3, SEP4, SEP5, and SEP6. SEP3, as well as for xri://@Telco*Infr 1,

Utility Computing use case.

application must be able to identify the virtual machines of a given cluster. For example, the XRI://@Grid*Cluster2*VM2 identifies the virtual machine *VM2, belonging to the cluster named *Cluster2 and managed by the SGE application named XRI://@Grid. It may be resolved by means of SEP3, SEP4, and SEP5. SEP4 resolves the name XRI://@Grid*Cluster2*VM2 describing if the virtual machine runs a Master Host, an Execution Host, an Administration Hosts, or a Submit Host. In addition SEP3 provides information regarding the daemons installed and their status. SEP4 resolves virtual machine name providing metadata referred to its performances, whereas SEP3 acts as Identity Provider (IDP), asserting the authenticity of the virtual machine. In this case, the IDP prevents the access of false SGE Host to the SGE application. C. The eBusiness Use-case This use case is a little more complicated than the previous ones. It consists in the deployment of a SAP system into the RESERVOIR virtualization infrastructure. As depicted in Figure 5, the proposed naming solution allows a hierarchical organization of the involved CNEs,

which may be a physical host, a virtual machine, or a ABAP program. The SAP system must be able to logically map and

reference naming framework to address scenarios where it is needed an integration between independent cloud name spaces. ACKNOWLEDGEMENTS The research leading to the results presented in this paper has received funding from the European Union’s seventh framework programme (FP7 2007-2013) Project RESERVOIR under grant agreeement number 215605. R EFERENCES [1] A. Celesti, M. Villari, and A. Puliafito, “Design of a cloud naming framework,” in ACM International Conference on Computing Frontiers, pp. 105–106, May 2010.

Figure 5.

eBusiness use case.

manage both its components (DI, CI, and DBMS) and the ABAP programs that it instantiates on-demand. Therefore, it has to identify which virtual machines host the various components, and which DI executes the ABAP programs. For example, the xri://@SAP*PH2*VM3 identifies the virtual machine *VM3 placed in a physical host *PH2, and managed by the SAP system named xri://@SAP. It may be resolved by means of SEP7, SEP8, and SEP9. SEP7 resolves the name xri://@SAP*PH2*VM3 describing the configuration of the virtual machine (CI/DBMS, DI/CI-DBMS, or DI). SEP8 resolves virtual machine name providing metadata referred to its performances. SEP9 acts as Identity Provider (IDP), asserting the authenticity of the virtual machine. In this case, the IDP prevents the access of false SAP components to the SAP system. Instead, the xri://@SAP*ABAP 1 name identify a ABAP program, which may be resolved with monitoring, performance, and authentication metadata by means of the SEP10, SEP11, and SEP12. Since a single ABAP program may be executed by one or more virtual machines acting as DIs, it is needed to identify each single ABAP instance. In Figure 5, using the XRI cross-reference mechanisms, the xri://@SAP*ABAP 1/*(xri://@SAP*PH2*VM3) name identifies the aforementioned virtual machine *(xri://@SAP*PH2*VM3) acting as DI, hosting an instance of the *ABAP 1 program in the xri://@SAP system. VI. C ONCLUSIONS AND F UTURE W ORKS In this paper we tackled the naming and resource location problems in cloud computing, more specifically focusing on some RESERVOIR use cases. A reference Cloud Naming Framework has been defined and some examples of cloud naming scenarios have been presented considering XRI and XRDS technologies. More specifically, three RESERVOIR use cases have been treated providing resource identification and resolution examples. In future works we will use the

[2] J. Caceres, R. Montero, B. Rochwerger, “RESERVOIR: An Architecture for Services, The first issue of the RESERVOIR Architecture document”,http://www.reservoirfp7.eu/twiki/pub/Reservoir/Year1 Deliverables/080531ReservoirArchitectureSpec-1.0.PDF, June 2008. [3] Extensible Resource Identifier (XRI) Syntax V2.0, OASIS, http://www.oasis-open.org. [4] Extensible Resource Identifier (XRI) Resolution V2.0, OASIS, http:/docs.oasis-open.org/xri/2.0/specs/xri-resolutionV2.0.html. [5] I. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud computing and grid computing 360-degree compared,” in Grid Computing Environments Workshop, 2008. GCE ’08, pp. 1–10, 2008. [6] D. Yang, Y. Qin, H. Zhang, H. Zhou, and B. Wang, “Urns: A new name service for uniform network resource location,” in Wireless, Mobile and Multimedia Networks, 2006 IET International Conference, pp. 1–4, 2006. [7] Y. Doi, S. Wakayama, M. Ishiyama, S. Ozaki, T. Ishihara, and Y. Uo, “Ecosystem of naming systems: discussions on a framework to induce smart space naming systems development,” in ARES, p. 7, April 2006. [8] Y. Doi, “Dns meets dht: treating massive id resolution using dns over dht,” in Applications and the Internet International Symposium, pp. 9–15, January 2005. [9] G.-J. Ahn, M. Ko, and M. Shehab, “Privacy-enhanced usercentric identity management,” in IEEE International Conference on Communications, ICC ’09, pp. 14–18, June 2009. [10] B. Sotomayor, R. Montero, I. Llorente, and I. Foster, “Virtual infrastructure management in private and hybrid clouds,” Internet Computing, IEEE, vol. 13, pp. 14–22, September 2009. [11] D. Reed, L. Chasen, and W. Tan, “Openid identity discovery with xri and xrds,” in Proceedings of the 7th symposium on Identity and trust on the Internet, pp. 19–25, 2008. [12] SAML V2.0 Technical Overview, OASIS, http://www.oasisopen.org. [13] The Shibboleth system standards, http://www.openqrm.com.