OpenPaaS Le réseau social d'entreprise

Transcription

1 OpenPaaS Le réseau social d'entreprise Open-PaaS platform resources description model SP L2.2.1 Télécom SudParis 1 / 18

2 1Contexte Abstract Contributors Remainder...3 2Open Cloud Computing Interface...4 3Platform resources description model OCCI platform resources Database resource Container resource Router resource OCCI platform links DatabaseLink resource RouterLink resource ContainerLink resource OCCI platform mixins WSO2 ESB router mixin Other mixins Application resources description model OCCI application resources Environment resource Application resource Deployable resource OCCI application links EnvironmentLink resource References...17 Télécom SudParis 2 / 18

3 1 Contexte 1.1 Abstract This document provides information regarding our defined description model for Open-PaaS platform resources. 1.2 Contributors Name Organism Contact Sami Yangui Samir Tata Institut Mines-Telecom, Telecom SudParis Institut Mines-Telecom, Telecom SudParis 1.3 Remainder We classify the Open-PaaS platform resources into two categories: Application resources and Platform resources. These two resources are extended from the OCCI core model 1 By Application resources, we mean all programs and/or software to be deployed on the Open-PaaS platform while Platform resources represent the needed mechanisms and services to host and execute the application to deploy. The remainder of this document is as follows: We introduce the OCCI standard and its different extensions in Section 2. Then, we detail respectively the Platform and Application description models in Section 3 and Section Télécom SudParis 3 / 18

4 2 Open Cloud Computing Interface OCCI is a Protocol and an API for all kinds of Management tasks. To model Open-PaaS platform resources, we opted to extend the OCCI specifications mainly dedicated for infrastructure resources modeling and defining a REST API for handling these resources [R. Nyren, A. Edmonds, A. Papaspyrou, and T. Metsch. Open Cloud Computing Interface- Core. GFD-P- R (2013)]. These specifications are already implemented in many Cloud infrastructures managers and consist of 3 parts: OCCI core that defines a meta-model for Cloud resources [T. Metsch and A. Edmonds. Open Cloud Computing Interface- Infrastructure. GFD- P-R (2013)] OCCI infrastructure which is an instantiation of the OCCI core metamodel for infrastructure resources. OCCI infrastructure defines IaaS resources through three types (i.e. Network, Compute and Storage) and also classifies the relationship between resources in two types (StorageLink and NetworkInterface) [T. Metsch and A. Edmonds. Open C l oud C omputi ng Interface- H TT P Renderi ng. G FD-P-R (2013)] OCCI HTTP rendering specifications that contains multiple documents describing rendering of the OCCI Core Model [4]. In addition to these specifications, we propose in this document an OCCI platform specification which constitutes our proposed extension to model Open-PaaS platform resources. Télécom SudParis 4 / 18

5 1 Platform resources description model Figure 1: Overview of the defined OCCI platform types. Figure details the overview of the different OCCI platform types that we have defined and the connection of these types with the OCCI core entities. The platform resource types are derived from Resource entity at OCCI core level. The platform resource mixins are derived from Mixin entity at OCCI core level. The interfaces which link these resources between them are derived from the Link entity at OCCI core level. The main defined OCCI platform types are: Database which are data store resources for platform applications which process persistent Data. Database resources can be relational (e.g. MySQL, PostgreSQL, etc.) or non-relational database (e.g. MongoDB, CouchDB, etc.), Container which are engines to host and run applications (e.g. Apache Axis container, Bonita, IBM WebSphere, etc.), Router which are resources that provide protocols, message format transformations and routing (e.g. ESBPetals router, Apache Synapse, etc.). We also define relations between platform resources using different links provided for this purpose: ContainerLink to connect Container resources, RouterLink to connect Router resources, DatabaseLink to connect a Container resource to a Database resource. The Kind s defined for each one of the platform Resource or Link subtypes are described in Table 1. In addition to that, a set of platform mixin resources can be defined if needed through this extension to support specific Télécom SudParis 5 / 18

6 platform resource features (e.g authentication PaaS features, logging PaaS features, etc.). Table 1: The kind s defined for the platform subtypes of Resources and related Links. Term Scheme Title Related Kind Database <schema> /platform# Database Resource Container <schema> / platform # Container Resource <schema> /core#resource <schema> /core#resource Router <schema> / platform # Router Resource <schema> /core#resource DatabaseLink <schema> / platform # Database Link <schema> /core#link ContainerLink <schema> / platform # Container Link <schema> /core#link RouterLink <schema> / platform # Router Link <schema> /core#link 1.4 OCCI platform resources Each one of our defined platform resources (i.e. Database, Container and Router) is characterized by a set of attributes (including state attribute) and actions according to the OCCI standard. We believe that all platform resources, which can be provisioned by a PaaS provider, may be assigned to one of these three resources Database resource The Database resource type represents storage resources which can be provisioned by the platform for applications which process persistent Data (e.g. MySQL, Apache CouchDB, etc.). The Database type inherits the Resource base type defined in the OCCI core model. Table 2: Database type attributes Attribute Type Multipli- Mutabili- Description Télécom SudParis 6 / 18

7 city ty occi.database.name String 0..1 mutable Name of the occi.database.type Enum {relational, keyvalue, 0..1 mutable Scheme type of the document, graph} occi.database.architecture Enum {x86, x64} 0..1 mutable CPU architecture of the occi.database.version String 0..1 mutable Version Label of the occi.database.state Enum {Available, Unavailable} 1 Immuta ble Current state of the Table 2 details the attributes describing the Database type through its Kind (Database scheme), whereas Table 3 lists the actions applicable to this type by its Kind. Action Term refers to the term of the Action s category identifier. Table 3: Actions applicable to Database type s. Action Term Target state Attributes StartDB Available Database credentials StopDB Unavailable - RestartDB Available (via Stop and Start Database credentials chain) BackupDB None - The Database resource attributes and actions are exposed by all Database type s and are necessary to describe and handle the context of these s (i.e. provisioning of a new, updating an existing, etc.). In addition to that, the defined Database resource actions are used to manage these s (i.e. start an, backup an, etc.). Every defined action is identified by a Category using a /database/action# categorization scheme. The execution of an action causes the modification of the status value of an. For example, for an already created and unavailable Database, the execution of the StartDB action brings the state to available by updating the state attribute value Container resource The Container resource type represents service containers and engines provisioned by the platform to host and run applications (e.g. Apache Axis, Oracle GlassFish Server, etc.). We defined a set of attributes to describe a Container type through its Kind (Container scheme) and a set of Télécom SudParis 7 / 18

8 actions to manage the different Container s (see respectively Table 3 and Table 5). Table 4: Container type attributes Attribute Type Multiplicity Mutability Description occi.container.name String 0..1 Mutable Name of the occi.container.version String 0..1 Mutable Version of the occi.container.architecture Enum {x86, x64} 0..1 Mutable CPU architecture of the occi.container.state Enum {Available, Restarting, Unavailable} 1 Immutable Current state of the These attributes and actions are exposed by all Container type s. Particularly, the state attribute enumerates the different predefined states that a Container can have (i.e. available, unavailable). The state attribute value can be changed by the execution of one of the actions listed in Table 5. Table 5: Actions applicable to Container type s. Action Term Target state Attributes StartContainer Available - StopContainer Unavailable - RestartContainer Available - SuspendContainer Unavailable Router resource The Router resource type represents message format transformation and routing systems provided by the platform to route and deliver messages between Container resources. Router entities are useful when the deployed applications on platforms are multi-tenant and/or service-based and require several (may be heterogeneous) containers. For example, a BPEL process deployed on an Apache ODE container invoking an external Web service deployed on an Apache Axis container. We defined necessary attributes to describe the Router type through its Kind (Router scheme) and its properties (see Table 6). Table 6: Router type attributes. Attribute Type Multiplicity Mutability Description Télécom SudParis 8 / 18

9 occi.router.name String 0..1 Mutable Name of the occi.router.version String 0..1 Mutable Version of the occi.router.architect ure Enum {x86, x64} 0..1 Mutable CPU architecture of the occi.router.state Enum {Active, configu ring, Inactiv e} 1 Immutable Current state of the A Router has, at a given moment, a context based on its attributes values and one state (i.e. active or inactive). The execution of one of defined Router actions (see Table 7) induces the modification of the selected state. Every action in this table is identified by a Category using a /router/action# categorization scheme. Table 7: Actions applicable to Router type s. Action Term Target state Attributes EnableRouter Active - ConfigureRouter None - DisableRouter Inactive OCCI platform links To connect the different platform resources, we have modeled a set of platform link entities. These entities are extended from the OCCI core model Link base type DatabaseLink resource The DatabaseLink type represents a binding between a Container resource and a Database resource. This enables a Database to be attached to a Container (see Figure 2). Télécom SudParis 9 / 18

10 Figure 2: DatabaseLink type: A binding between Container resource and Database resource As examples of DatabaseLink, we can cite:.net/connector: which connects a.net container to a MySQL, Mongo+Hadoop Connector: which connects a Hadoop server to a MangoDB. A DatabaseLink can be set up between two or several Container and Database s through the Bind action (see Table 8). Table 8: Actions applicable to DatabaseLink s. Action Term Attributes Description Bind source, target bind a Container source to a target Database RouterLink resource The RouterLink allows connecting one or several Container resources through Router resource (see Figure 3). Télécom SudParis 10 / 18

11 Figure 3: ContainerLink type: A connector between Container and Router resources ContainerLink resource The ContainerLink allows connecting one or several Container resources between them (see Figure 4). Figure 4: RouterLink type: A connector between several Container resources 1.6 OCCI platform mixins The platform Mixin resources are defined to support specific features and operations offered by the Open-PaaS platform and cannot be described by the main platform resources introduced in Section 3.1. In this section, we present, as an example, a platform resource that can be modeled as a mixin i.e. WSO2 ESB router mixin WSO2 ESB router mixin WSO2 is an Open Source Enterprise Service Bus (ESB) which allows users to configure message routing, virtualization, intermediation, transformation, logging, task scheduling, load balancing, failover routing and event brokering Télécom SudParis 11 / 18

12 [WSO2 admin guide.]. WSO2 ESB design is particular and strongly extensible to allow integrating new modules if needed from a remote P2 repository (e.g. installing the Carbon UI Feature) [WSO2 admin guide.]. To support these specific features, a WSO2 ESB router mixin was defined. Specific action (see Table 9) characterizes this mixin. Table 9: Actions applicable to WSO2 ESB router mixin type. Action Term Target state Attributes InstallModule Available module properties (name, version, provider, etc.) Other mixins Platform providers proposes technical functionalities and features (e.g. authentication, logging, metering, messaging, etc.) and even paid applications and services in marketplaces (e.g. Heroku add-ons [Heroku platform Add-ons. Cloud Foundry marketplace [Cloud Foundry services marketplace.]). These functionalities and services are also considered as platform resources. They are supported by our extension and can be modeled as mixins. Télécom SudParis 12 / 18

13 1 Application resources description model Application resource types extends OCCI core entities. Both applications resources and the links between them are respectively derived from Resource and Link entities located at the OCCI core level (see Figure 5). Figure 5: Overview of the defined OCCI application types. The defined OCCI application types are: Environment which represents a set of settings needed to host and run an Application (e.g. runtime, framework, message queue, etc.), Application which is the software that can be deployed on top of a PaaS (e.g. WAR file, Ruby program, etc.), Deployable which represents the Application deployables (e.g. sources archives, etc.), EnvironmentLink which connects an Application to an Environment. Table 10 describes the Kind s defined for each one of the application Resource or Link sub-types. Table 10: The kind s defined for the application subtypes of Resources and related Links. Term Scheme Title Related Kind Environment <schema> /application# Environment Resource <schema> /core#resource Application <schema> /application# Application Resource <schema> /core#resource Télécom SudParis 13 / 18

14 Deployable <schema> /application# Deployable Resource <schema> /core#resource Environment- Link <schema> /application# Environment Link <schema> /core#link 1.7 OCCI application resources According to Resource entity at OCCI core level, application resources (i.e. Environment, Application and Deployable) are described and managed through attributes (including a state attribute) and actions Environment resource The Environment resource represents a set of configurations and settings of the platform resources. The Environment resource is needed to host and run applications on the Open-PaaS platform i.e. the needed runtime (java 7, java 6, ruby, etc.), the needed frameworks/containers (spring, tomcat, ruby, etc.) and eventually the needed provider services (monitoring, messaging, etc.). Table 11: Environment type attributes. Description Attribute Type Multiplicity Mutability occi.environment.- name occi.environment.- description occi.environment.- memory occi.environment.variables occi.environment.- containerslist occi.environment.databaseslist occi.environment.- routerslist occi.environment.databaseslink String 0..1 Mutable Name of the String 0..1 Mutable Float, 109 (GiB) Set of (var, value) Mutable Mutable Set of URIs 0..1 Mutable Set of URIs 0..1 Mutable Set of URIs 0..1 Mutable Set of URIs 0..1 Mutable Human readable description of the. RAM allocated to the. Environment variables associated to the. Set of URIs of Container s associated to the. Set of URIs of Database s associated to the. Set of URIs of Router s associated to the. Set of URIs of DatabaseLink s associated to the. Télécom SudParis 14 / 18

15 occi.environment.state Enum {available, unavailable} 1 Immutable Current state of the Table 11 describes the OCCI attributes defined for an Environment resource through its Kind resource. We defined also an action (see Table 12) applicable to an Environment type. This action is exposed by all Environment type s. Table 12: Actions applicable to Environment type s. Action Term Target state Attributes Update None New context Application resource The Application type represents any computer software or program that can be deployed on top of a PaaS into a hosting Environment. This Environment is set up thanks to the instantiation and the configuration of necessary platform resources. To deploy an Application, the end-user specifies a set of properties (e.g. application name, application description, etc.). Moreover, if the target PaaS provider supports the management of multiple s (e.g. Cloud Foundry), the user can specify the desired number of active s to ensure application scalability and availability (see Table 13). Table 13: Application type attributes. Description occi.application.name String 0..1 Mutable Name of the Human readable occi.application.descri String 0..1 Mutable description of the ption. ineteger 1..N occi.application.url URL 0..1 Attribute Type Multiplicity Mutability occi.application.s occi.application.deployables Mutable Mutable Set of URIs 0..1 Mutable Number of the copies. Public URL associated to the. Set of URIs of Deployable s associated to the. occi.application.state Enum {started, stopped} 1 Immutable Current state of the Télécom SudParis 15 / 18

16 Once deployed, the Application can be invoked and executed through its URL provided by the target PaaS. The load balancing between the different s is managed by the PaaS solution. To manage the different Application s, we defined a set of actions (see Table 14). Table 14: Actions applicable to Application type s. Action Term Target state Attributes Update None New context. Start Started - Stop Stopped - Restart Started Deployable resource The Deployable type represents the application deployables to be provided on application sources upload process. By deployable, we mean all necessary artifacts (e.g. ZIP file, EAR file, etc.), configuration files (e.g. Chef script, etc.) and/or deployment descriptor (XML file) needed to carry out the application deployment (see Table 15). Table 15: Deployable type attributes. Attribute Type Multiplicity Mutability Description occi.deployable.nam e occi. deployable.descriptio n occi. deployable.- content_type occi. deployable.location String 0..1 Mutable Name of the String 0..1 Mutable Enum {artifact, war, ear} 0..1 URL 0..1 Mutable Mutable Human readable description of the. Number of the copies. Location of the artifact associated to the (file path or a logical name). occi.application.state Enum {available, unavailable} 1 Immutable Current state of the The end-user can upgrade Deployable s to apply new source updates for example through the update action (see Table 16). Télécom SudParis 16 / 18

17 Table 16: Actions applicable to Deployable type s. Action Term Target state Attributes Update None New deployables. 1.8 OCCI application links Application links entities are extended from the OCCI core model Link base type in order to connect the different application resources EnvironmentLink resource According to our description model, to deploy an Application on an Environment, one must instantiate an EnvironmentLink between these two resources (see Figure 6). Figure 6: EnvironmentLink type: A connector between Application resource and Environment resource. Télécom SudParis 17 / 18

18 1 References 1. R. Nyren, A. Edmonds, A. Papaspyrou, and T. Metsch. Open Cloud Comp u t i n g I n t e r f a c e - C o r e. G F D - P - R (2013) 3. T. Metsch and A. Edmonds. Open Cloud Computing Interface- HTTP Rendering. GFD-P-R (2013) 4. WSO2 admin guide WSO2 admin guide Heroku platform Add-ons Cloud Foundry services marketplace. 2. T. Metsch and A. Edmonds. Open Cloud Computing Interface- Infrastructure. GFD-P-R (2013) 79a590a67930/marketplace Télécom SudParis 18 / 18