cloud standardization · nist is active in fostering cloud computing practices that support...

Cloud Standardization

Cloud Strategy Partners, LLC

Sponsored by: IEEE Educational Activities and IEEE Cloud Computing

Course Presenter’s Biography

IEEE eLearning Library Cloud Standardization Transcript pg. 2 / 21

This IEEE Cloud Computing tutorial has been developed by Cloud Strategy Partners, LLC. Cloud Strategy Partners, LLC is an expert consultancy firm that specializes in Technology and Strategy relating to Cloud Computing.

Course Summary


This tutorial will provide an overview of Cloud standardization activities and initiatives. It begins with a review of the work produced by the US Government Department of Commerce, National Institute of Standards and Technology (NIST), and Cloud Computing Project. Next we will look at a couple of “standards” that (a) aren’t really standards per-se and (b) apply more to architecture. We will look at two of them, one from the ITU-T, and one from the Open Datacenter Alliance. Finally, we will consider some proposed and actual standards for cloud components.

Transcript


Outline This Lesson will provide an overview of Cloud standardization activities and initiatives First, the work produced by the US Government Department of Commerce, National Institute of Standards and Technology (NIST), Cloud Computing Project, will be covered. Then we will look at a couple of “standards” that (a) aren’t really standards per-se and (b) they apply more to architecture. We will look at two of them, one from the ITU-T, and one from the Open Datacenter Alliance. Finally, we will consider some proposed and actual standards for cloud components.

Cloud Industry Standardization (1) – General and Architecture Here is the pointer to the NIST work. They have established a Wiki called “NIST – Collaboration on Cloud Computing Reference Architecture development” which is open to the public. While we won’t cover it in detail, the US Government is not the only Government concerned about Cloud Standards. In Japan the NICT (like the National Science Foundation in the US) funded a group called Global Inter-Cloud Technology Forum. They are producing Use Cases and Functional Requirements and the slide gives pointers to where you can find their work on the Web.

Cloud Industry Standardization (2) – Cloud Architecture Components There are many, many other groups who have launched Cloud Standardization “studies” or efforts in the past few years. Many of them did not proceed to completion, as the larger Standards Bodies finished their work. Four organizations who did continue working on the problem are: Storage Networking Industry Association (SNIA), with the SNIA Cloud Data Management Interface Distributed Management Task Force (DMTF), with the Open Virtualization Format Open Grid Forum (OGF), with the Open Cloud Computing Interface And the Advancing Open Standards for Information Society (OASIS), with the Topology and Orchestration Specification for Cloud Applications, and the Identity Management for Cloud We will review each of these in detail in the upcoming slides

Transcript


Other standardization activities on Cloud This slide references some other initiatives and pointers to initiatives should you be looking for even deeper or more specific work on Cloud Standards. Cloud Security Alliance ENISA Cloud Computing Risk Assessment (2010) Cloud Taxonomy and Cloud Standards Wiki.

NIST Documents on Cloud Computing (1) First, we review the NIST publications. This slide provides pointers to:

• A NIST definition of cloud computing • Cloud Computing Reference Architecture • Cloud Computing Synopsis and Recommendations • Cloud Computing Security Reference Architecture • Guide to Security for Full Virtualization Technologies.

NIST Documents on Cloud Computing (2) Continuing the review the NIST publications, this slide provides pointers to:

• US Government Cloud Computing Technology Roadmap Volume 1, High-Priority requirements to Further USG Agency Cloud Computing Adoption

• US Government Cloud Computing Technology Roadmap Volume II, Useful Information for Cloud Adopters

• US Government Cloud Computing Technology Roadmap Volume III, Technical Considerations for USG Cloud Computing Deployment Decisions

• NIST Cloud Computing Standards Roadmap This last document is very useful as it contains pointers to even more standardization efforts.

NIST Cloud Computing Definition: Components This slide is a visual representation of the NIST Cloud Computing Definition. We have grouped the NIST concepts into three areas-Deployment Models, Service Models, and Essential Characteristics. As you can see the key concepts in each area are:

• Cloud characteristics o On-demand self-service o Broad network access o Resource pooling o Rapid elasticity o Measured Service

Transcript


• Basic service models o Software as a Service (SaaS) o Platform as a Service (PaaS) o Infrastructure as a Service (IaaS)

• Deployment models o Private clouds o Public clouds o Hybrid clouds o Community clouds o Federated clouds, Interclouds

NIST Cloud Computing Reference Architecture (CCRA) 2.0 – Components, Capabilities, Actors This slide shows an illustration of the NIST Cloud Computing Reference Architecture (CCRA) 2.0. Standardization has been very important from the beginning of the Cloud Computing development. It is important for both Cloud Services Providers and for cloud services consumers to allow their interoperability with other services. In the Lecture Notes we refer to the related standards by NIST and also ITU-T work. NIST is active in fostering cloud computing practices that support interoperability, portability, and security requirements that are appropriate and achievable for important usage scenarios. Since the first publication of the currently commonly accepted NIST Cloud definition in 2008, NIST is leading internationally recognized activities on defining conceptual and standard base in Cloud Computing, which has been resulted in publishing the following documents that create a solid base for cloud services development and offering:

• NIST SP 800-145, A NIST definition of cloud computing – quoted above • NIST SP 500-292, Cloud Computing Reference Architecture, v1.0 DRAFT • NIST SP 800-146, Cloud Computing Synopsis and Recommendations • NIST SP500-291 NIST Cloud Computing Standards Roadmap

The slide presents a high level view of the NIST Cloud Computing Reference Architecture (CCRA), which identifies the major actors (Cloud Consumer, Cloud Service Provider, Cloud Auditor, Cloud Broker, and Cloud Carrier), their activities and functions in cloud computing. A cloud consumer may request cloud services from a cloud provider directly or via a cloud broker. A cloud auditor conducts independent audits and may contact the others to collect necessary information. The proposed architecture is suitable for many purposes.

Transcript


ITU-T Focus Group on Clouds The ITU Telecommunication Standardization Sector (ITU-T) is one of the three parts of the International Telecommunication Union (ITU); it coordinates standards for telecommunications. ITU-T Focus Group on Cloud Computing (FG Cloud) was established to study issues related to Cloud Computing. As can be seen from the slide, they tackled Seven Areas:

• Part 1: Introduction to the cloud ecosystem: definitions, taxonomies, use cases and high level requirements

• Part 2: Functional Requirements and Reference Architecture • Part 3: Requirements and framework architecture of Cloud Infrastructure • Part 4: Cloud Resource Management Gap Analysis • Part 5: Cloud security • Part 6: Overview of SDOs involved in Cloud Computing • Part 7: Benefits from telecommunication perspectives

Parts 2 and 3 are of main interest to us.

ITU-T FG TR Part 2: Functional Requirements and Reference Architecture ITU-T FG TR Part 2 Establishes a Functional requirements and reference architecture. It teaches a Layered Cloud computing architecture includes:

• User layer (including user functions, partner functions, administration functions)

• Access layer (including endpoint functions and inter-cloud functions). Network service providers role is to provide inter-cloud transport network

• Cloud services layer (including basic cloud services IaaS, PaaS, SaaS, NaaS, CaaS and also Orchestration service)

• Resources and network layer (including physical resources, pooling and orchestration, pooling and virtualization)

Cloud Standardization – ITU-T Tech Report ITU-T Tech Report Part 2set out Functional requirements and reference architecture in a Layered Cloud computing architecture. Four Layers were specified:

Transcript


• User layer Including user functions, partner functions, administration functions

• Access layer Including endpoint functions and inter-cloud functions, where the role of network service providers is defined as to provide inter-cloud transport network

• Cloud services layer Including basic cloud services IaaS, PaaS, SaaS and also Orchestration service

• Resources and network layer Including physical resources, pooling and orchestration, and virtualization

Ongoing Standardization: IETF Internet Draft Cloud Reference Framework The Internet Engineering Task Force (IETF), best known for their work in the Internet Protocols space, also proposed some architectural blueprints for Cloud. In the Cloud Reference Framework Internet Draft, a Multilayer Cloud Services Model, an Intercloud Architecture Framework, and some Use cases were set out

Multilayer Cloud Services Model (CSM) This slides illustrated the IETF Multilayer Cloud Services Model (CSM). The CSM layers are:

• (C6) User/Customer side Functions • (C5) Intercloud Access and Delivery Infrastructure • (C4) Cloud Services (Infrastructure, Platform, Applications) • (C3) Virtual Resources Composition and Orchestration • (C2) Virtualization Layer • (C1) Hardware platform and dedicated network infrastructure

InterCloud Architecture Framework (ICAF) Researchers at the University of Amsterdam in Europe focused on the cloud to cloud, or “Intercloud” architecture, and developed an InterCloud Architecture Framework (ICAF). The main elements, defined in more detail in the slide, are

• An InterCloud Control and Management Plane (ICCMP) • An InterCloud Federation Framework (ICFF) • An InterCloud Operations Framework (ICOF) • An Intercloud Security Framework (ICSF)

Transcript


General use case for infrastructure provisioning: Workflow => Logical (Cloud) Infrastructure Let us examine a use case, where I have a large application which can be mapped out in functionality by its Master Workflow. This is illustrated in the Slide on the top. I have several cloud service providers, as illustrated by the four entities on the bottom of the slide. Actually, a participant in this can be non-cloud, as long as it participates in the same federation protocols, as indicated by the terms “Resource Service Provider”. Through Federation, a “logical Intercloud” is formed, and the 4 different datacenters let’s say, appear to part of one virtual cloud. This is indicated as the “cloud in the middle”. To further complicate our example, the problem is being looked after by two universities and so the User Groups A and B represent traditional diagrams of a control function.

General use case for infrastructure provisioning: Logical Infrastructure => Network Infrastructure (2) The application is mapped to run on the virtual VM’s which are mapped to the actual underlying services. The two campuses in this example can monitor and manage the Workflow across VMs across the federated cloud. Here, the orchestration occurs over the public internet. Either way the composite application is choreographed and the elements of application code are set to run on the public cloud. These sets of slides meant to illustrate scenarios where our definition of “an application” is not constrained to one cloud or to our native service provider either. Intercloud allows for a composite application to be deployed as it makes sense, putting some components with one Cloud Service Provider and some with another.

Intercloud Applications Integration: ICCM, ICFF, ICOMF Operational and business issues are typically addressed by Operations services and a framework. This slide illustrates the interplay between ICCM, ICFF, ICOMF and the Business Processes Management and Services Operation Support

• SLA Management • Business roles and Actors • Business level Service Registry and Broker • Mobility

Transcript


IEEE P2302 WG Cloud Interoperability Federation (1) At a plumbing level, roughly equivalent to ICCMP in the previous examples, progress has been made as to the actual implementation directions. This work has moved to a Standards Working Group within the IEEE called IEEE P2302 Draft Standard for Intercloud Interoperability and Federation (SIIF) is modeled after the public Internet infrastructure. Intercloud Roots: containing services such as Naming Authority, Trust Authority, Messaging, Semantic Directory Services, and other “root” capabilities. The Intercloud root is not a single entity –it’s a globally replicating and hierarchical system. Several Intercloud Exchanges: analogous to Internet Exchanges and Peering Points – called Brokers in the NIST Reference Architecture where clouds can interoperate. Several Intercloud Gateways: analogous to the Internet Router which connects an Intranet to the Internet.

IEEE P2302 Cloud Interoperability Federation (2) The Intercloud Gateways would provide mechanism for supporting the entire profile of Intercloud protocols and standards utilizing a common transport. From Intercloud topology perspectives, Intercloud Roots will provide PKI CA root like functionality. According to the current PKI based trust model, once the CA authorizes the certificate for an entity, the entity is either trusted or non-trusted. However, in the cloud computing environment, especially in the Intercloud environment, this model needs to be extended to have “Trust Zone” to go along with the existing PKI based trust model. Intercloud exchanges will be responsible for the “Trust Zone” based trust model layered on top of the PKI certificate based trust model. The Intercloud Root and Intercloud Exchanges would facilitate and mediate the initial Intercloud negotiating process among Clouds. Once the initial negotiating process is completed, each of these Cloud instance would collaborate directly with each other via a protocol and transport appropriate for the interoperability action at hand; for example, a reliable protocol might be needed for transaction integrity, or a high speed streaming protocol might be needed optimized for data movement over a particular link.

Intercloud Root, Exchange, Catalog Various providers will emerge in the enablement of the Intercloud. One can first envision a community governed set of Intercloud Root providers who will act as brokers and host the Cloud Computing Resource Catalogs for the Intercloud computing resources.

Transcript


In order for the Intercloud capable Cloud instances to federate or otherwise interoperate resources, a Cloud Computing Resources Catalog system is necessary infrastructure. This catalog is the holistic and abstracted view of the computing resources across disparate cloud environments. Individual clouds will, in turn, will utilize this catalog in order to identify matching cloud resources by applying certain Preferences and Constraints to the resources in the computing resources catalog. The technologies to use for this are based on the Semantic Web which provides for a way to add “meaning and relatedness” to objects on the Web. To accomplish this, one defines a system for normalizing meaning across terminology, or Properties. This normalization is called Ontology. Cloud Computing resources can be described, cataloged, and mediated using Semantic Web Ontologies, implemented using RDF techniques. Intercloud Exchanges, in turn, will leverage the globally dispersed resources catalog information hosted by federated Intercloud Roots in order to match cloud resources by applying certain Preferences and Constraints to the resources.

Open Data Center Alliance (ODCA): CIaaS Conceptual Framework The ODCA Master Usage Model: Compute Infrastructure as a Service (CIaaS) is intended to help facilitate the potential for this by establishing a requirements framework for open, interoperable compute infrastructure services. Infrastructure requirements for the broad range of service consumers, a common framework is required around which infrastructure as a service can be defined, provisioned, monitored and managed. A common set of principles, metrics and architectural frameworks can be defined, resulting in consistent capabilities, service levels and service attributes across multiple providers, while still allowing the individual providers to innovate and differentiate. CIaaS requires the following elements as detailed in the slide: Compute instance (may or may not be virtual, although virtual machines (VMs) are typical) CPU and memory resources Network components Storage These elements will be deployed in different configurations to meet a range of service capabilities and attributes. They do not seek to define technical implementation in this usage model. Instead, they seek to define the capabilities required in common terms and measures.

Cloud Aware Data Center (Services) Design Cloud-aware applications have been designed and built with the sole intent of running in a cloud environment. They are both

Transcript


free of the dependencies and assumptions that burden traditional or legacy applications, while simultaneously able to fully exploit the inherent advantages of cloud. Other terms have been used for these as well, including cloud-native, cloud-architected, born-cloud, or cloud-enabled. However, the attributes used to describe such architectures generally include the following:

• Composable. Applications are distributed and dynamically wired. • Elastic. The ability to scale up but also to scale down based on the load. • Evolvable. This is related to portability and suggests the ability to replace

existing underlying technology or vendor decisions with other decisions, as the needs of the business or market change, with minimal impact to the business.

• Extensible. Applications are incrementally deployed and tested; that is, there is an ability to easily grow the application over time.

• Granular. Metering and billing. • Multi-tenant. Multiple cloud subscribers may be using the same underlying

resources and infrastructure from the cloud provider, with reliability, security, and consistent performance.

• Portable. Applications can run almost anywhere, any cloud provider and from any device.

• Self-service. Simply put, a program or system that has not been specifically designed (or remediated) to transparently leverage the unique capabilities of cloud computing. Rather, such applications may be migrated to run in a cloud context, but the value realization from such instances will be limited.

Cloud Infrastructure Component Standards Next we will look at some Cloud Infrastructure Component Standards While these have limited commercial uptake, there are good communities developing and maintaining these standards primarily around the academic and ex-Grid community. The standards we will consider are

• OVF (Open Virtualization Format) by DMTF • CDMI (Cloud Data Management Interface) by SNIA • OCCI (Open Cloud Computing Interface) by OGF • OASIS TOSCA (Topology and Orchestration Specification for Cloud

Applications)

Transcript


Cloud Infrastructure Layers and Interfaces These standards fit into different layers of the cloud “stack”. This illustration shows that the “User API Layer” of Cloud infrastructure and services interfaces are where OCCI and TOSCA fit in, and that the “lower level Internal Interfaces” of Cloud resources interfaces and formats are where a different part of OCCI, and also CDMI and OVF fit in.

OVF (Open Virtualisation Format) by DMTF Open Virtualization Format (OVF) is an open standard for packaging and distributing virtual appliances or more generally software to be run in virtual machines. The standard describes an "open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines". The OVF standard is not tied to any particular hypervisor or processor architecture. The unit of packaging and distribution is a so-called OVF Package which may contain one or more virtual systems each of which can be deployed to a virtual machine.

Open Virtualization Format (OVF) Here is some detail about OVF. OVF package consists of an OVF descriptor and a set of additional content, typically virtual disks. The OVF descriptor is an XML document that describes meta-data about the software installed on the virtual disks. The specification allows any virtual disk format to be used, as long as the disk format specification is public and without restrictions. The virtual disk format will commonly be some simple basic disk block format agnostic to the guest OS installed.

Virtual Appliance Lifecycle and OVF place OVF applies to a specific part of the lifecycle of a Virtual Appliance. As can be seen from the illustration, it is aimed at the Packaging and Deployment phases.

OVF Package Structure OVF has a structured package format. The OVF package shall consist of the following files:

• one OVF descriptor with extension .ovf • zero or one OVF manifest with extension .mf • zero or one OVF certificate with extension .cert • zero or more disk image files • zero or more additional resource files, such as ISO images

Transcript


An OVF package may be stored as a single file with extension .OVA using the TAR format ordering restriction applies. An example is illustrated in the slide.

OVF Descriptor Example - Structure This slide shows the detailed structure of an OVF Descriptor.

OVF Environment Document OVF in itself is not enough to solve the whole deployment problem. An OVF Environment Document defines how the guest software and the deployment platform interact The Environment document is an extensible XML document that is provided to the guest software about the environment in which it is being executed The Transport types are specified in the OVF descriptor.

OVF Environment Document example This slide shows an example of an OVF Environment Document.

Cloud Data Management Interface by SNIA Next we will consider CDMI (Cloud Data Management Interface) by SNIA

Cloud Data Management Interface (CDMI) The Cloud Data Management Interface defines the functional interface that applications will use to create, retrieve, update and delete data elements from the Cloud. As part of this interface the client will be able to discover the capabilities of the cloud storage offering and use this interface to manage containers and the data that is placed in them. In addition, metadata can be set on containers and their contained data elements through this interface. This interface is also used by administrative and management applications to manage containers, accounts, security access and monitoring/billing information, even for storage that is accessible by other protocols. The capabilities of the underlying storage and data services are exposed so that clients can understand the offering.

CDMI Architecture Model This model shows multiple types of cloud data storage interfaces that are able to support both legacy and new applications. All of the interfaces allow storage to be provided on demand, drawn from a pool of resources. The storage capacity is drawn from a pool of storage capacity provided by storage services.

Transcript


The data services are applied to individual data elements, as determined by the data system metadata. Metadata specifies the data requirements on the basis of individual data elements or on groups of data elements (containers).

CDMI Object Model For data storage operations, the client of the interface only needs to know about container objects and data objects. All data path implementations are required to support at least one level of containers. Using the CDMI object model, the client may send a PUT via CDMI to the new container URI and create a new container with the specified name. Container metadata are optional and are expressed as a series of name-value pairs. After a container is created, a client may send a PUT to create a data object within the newly created container. A subsequent GET will fetch the data object, including the value field. Queue objects are also defined and have special properties for in-order, first in, first-out creation and fetching of queue values.

CDMI Protocol (HTTP REST based) The CDMI Protocol is HTTP REST based. It supports the following content-type operations:

• discovering the capabilities of a cloud storage provider • creating a new container • creating a new data object • listing the contents of a container • reading the contents of a data object • reading only the value of a data object • deleting a data object

CDMI Example: Read Content of Data Object This listing illustrates examples CDMI protocol Request and Response messages. The Request message requests data object in a form of MyDataObject.txt file. The Response message returns the content of the file “Hello CDMI World!”, data object identification information and a set of metadata, including the content size cdmi_size which in our example 17 bytes. All individual objects are identified by ObjectID.

OGF Open Cloud Computing Interface (OCCI) The Open Cloud Computing Interface (OCCI) is a set of specifications delivered through the Open Grid Forum (OGF).

Transcript


The aim of the Open Cloud Computing Interface is the development of an open specification and API for cloud offerings. The focus was on Infrastructure-as-a-Service (IaaS) based offerings but the interface can be extended to support Platform and Software as a Service offerings as well.

OCCI place in Cloud Provider model Because OCCI provides a Consumer to Cloud API, and in practice for Compute and Storage, it is easily adapted to a variety of cloud platforms. The OpenStack project has a community supported OCCI. The distributions of OpenNebula and CloudStack include an OCCI implementation. Service consumers can be both end-users and other system instances. OCCI is suitable for both cases. The key feature is that OCCI can be used as a management API for all kinds of resources while at the same time maintaining a high level of interoperability.

OCCI URI/URL structure This slide illustrates the OCCI URI/URL structure. The OCCI HTTP Rendering uses many of the features the HTTP and underlying protocols offer and builds upon the Resource Oriented Architecture (ROA). ROA's use Representation State Transfer (REST) to cater for client and service interactions.

OCCI Core Model: UML class diagram This slide provides detail using a UML Class Diagram for the OCCI Core Model. The OCCI Core Model defines a representation of instance types which can be manipulated through an OCCI rendering implementation. It is an abstraction of real-world resources, including the means to identify, classify, associate and extend those resources. The heart of the OCCI Core Model is the Resource type. Any resource exposed through OCCI is a Resource or a sub-type thereof. A resource can be e.g. a virtual machine, a job in a job submission system, a user, etc. A fundamental feature of the OCCI Core Model is that it can be extended in such a way that any extension will be discoverable and visible to an OCCI client at run-time. An OCCI client can connect to an OCCI implementation using an extended OCCI Core Model, without knowing anything in advance, and still be able to discover and understand, at run-time, the various Resource and Link sub-types supported by that implementation.

Transcript


OCCI Infrastructure type An OCCI implementation can model and implement an Infrastructure as a Service API offering by utilising the OCCI Core Model. This API allows for the creation and management of typical resources associated with an IaaS service, for example, creating a Compute instance and Storage instance and then linking them with StorageLink. The main infrastructure types defined within OCCI Infrastructure are

• Compute Information processing resources. • Network Interconnection resource and represents a L2 networking resource.

This is complimented by the IPNetwork Mixin. • Storage Information recording resources. • Supporting these Resource types are the following Link sub-types: • NetworkInterface connects a Compute instance to a Network instance. This

complimented by an IPNetworkInterface Mixin. • StorageLink connects a Compute instance to a Storage instance.

Compute Attributes The Compute type represents a generic information processing resource, e.g. a virtual machine. Compute inherits the Resource base type defined in OCCI Core Model. Compute is assigned the Kind instance defined by the URL in the slide. A Compute instance MUST use and expose this Kind. Attributes defined for the Compute type are CPU Architecture of the instance Number of CPU cores assigned to the instance Fully Qualified DNS hostname for the instance CPU Clock frequency (speed) in gigahertz Maximum RAM in gigabytes allocated to the instance Current state of the instance.

Network Attributes The Network type represents a L2 networking entity (e.g. a virtual switch). It can be extended using the mixin mechanism (or sub-typed) to support L3/L4 capabilities such as TCP/IP etc. For the purposes of this specification we define an OCCI mixin so that IP networking can be supported where required. Network inherits the Resource base type defined in OCCI Core Model.

Storage Attributes The Storage type represents resources that record information to a data storage device. Storage inherits the Resource base type defined in the OCCI Core Model. The Storage type is assigned the Kind instance as defined in the URL in the slide.

Transcript


OCCI can be used in conjunction with the SNIA cloud storage standard, Cloud Data Management Interface (CDMI) to provide enhanced management of the cloud computing storage and data. For storage managed through CDMI, see the section in the OCCI Documents on StorageLink

Network Interface – Linking to Network In order to support L3/L4 capabilities (e.g. IP, TCP etc.) with the NetworkInterface type, an OCCI Mixin instance needs to be defined. The slide shows a UML object diagram depicts how NetworkInterface would be associated with an IPNetworkInterface Mixin when both are instantiated.

StorageLink Attributes – Linking to storage The StorageLink type represents a link from a Resource to a target Storage instance. This enables a Storage instance be attached to a Compute instance, with all the prerequisite low-level operations handled by the OCCI implementation. Storage inherits the Link base type defined in the OCCI Core Model

Example 1: Creating a Compute resource instance Here is an example of how one goes about creating a compute resource instance, using OCCI

Example 2 - Retrieving a Compute resource instance Here is an example of how one goes about Retrieving a Compute resource instance using OCCI

Example 3: Example category query Here is an example of how one goes about discovering the available categories using OCCI

OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TOSCA is intended to be the first standard to describe IT services that go beyond infrastructure as a service, i.e., describing service templates across *aaS layers and connecting them to the resource abstraction layer. Service templates can describe the topology of complex services and applications.

Transcript


They can also specify the administration of such services and applications, e.g., deploy, patch, and scale out. Service templates enable this describing the management procedures that create or modify services are said to be using orchestration processes. The combination of topology and orchestration in a Service Template describes what is needed to be preserved across deployments in different environments to enable interoperable deployment of cloud services and their management throughout the complete lifecycle (e.g. scaling, patching, monitoring, etc.) when the applications are ported over alternative cloud environments.

Service Template: Structural Elements The TOSCA specification defines ametamodel for defining IT services. This metamodel defines both the structure of a service as well as how to manage it. A Topology Template (also referred to as the topology model of a service) defines the structure of a service. Plans define the process models that are used to create and terminate a service as well as to manage a service during its whole lifetime. The major elements defining a service are depicted in the diagram in the slide.

Topology Template and Node Template Topology Template consists of a set of Node Templates and Relationship Templates that together define the topology model of a service as a (not necessarily connected) directed graph. A node in this graph is represented by a Node Template. A Node Template specifies the occurrence of a Node Type as a component of a service. A Node Type defines the properties of such a component (via Node Type Properties) and the operations (via Interfaces) available to manipulate the component. Node Types are defined separately for reuse purposes and a Node Template references a Node Type and adds usage constraints, such as how many times the component can occur. For example, consider a service that consists of an application server, a process engine, and a process model. A Topology Template defining that service would include one Node Template of Node Type “application server”, another Node Template of Node Type “process engine”, and a third Node Template of Node Type “process model”. The application server Node Type defines properties like the IP address of an instance of this type, an operation for installing the application server with the corresponding IP address, and an operation for shutting down an instance of this application server. A constraint in the Node Template can specify a range of IP addresses available when making a concrete application server available.

Transcript


Plans Plans defined in a Service Template describe the management aspects of service instances, especially their creation and termination. These plans are defined as process models, i.e. a workflow of one or more steps. Instead of providing another language for defining process models, the specification relies on existing languages like BPMN or BPEL.

TOSCA: Simple Service Template The diagram in the slide depicts a sample Definitions file named Payroll.tosca containing a Service Template of an application. The application is a payroll application written in Java that must be deployed on a proper application server. The Service Template of the application defines the Node Template Payroll Application, the Node Template Application Server, as well as the Relationship Template deployed on. The Payroll Application is associated with an EAR file (named Payroll.ear) which is provided as corresponding Deployment Artifact of the Payroll Application Node Template. An Amazon Machine Image (AMI) is the Deployment Artifact of the Application Server Node Template; this Deployment Artifact is a reference to the image in the Amazon EC2 environment. The Implementation Artifacts of some operations of the Node Templates are provided too; for example, the start operation of the Payroll Application is implemented by a Java API supported by the payrolladm.jar file, the installApp operation of the Application Server is realized by the Python script wsadmin.py, while the runInstances operation is a REST API available at Amazon for running instances of an AMI.

Example: PayrollTypes.tosca document Here is a TOSCA example: the PayrollTypes.tosca document. The Payroll Application Node Template specifies the deployment artifact PayrollEAR. It is a reference to the CSAR containing the Payroll.tosca file, which is indicated by the .../CSARref type of the DeploymentArtifact element. The type specific content is a path expression in the directory structure of the CSAR: it points to the Payroll.ear file in the EARs directory of the CSAR. The Application Server Node Template has a DeploymentArtifact called ApplicationServerImage that is a reference to an AMI (Amazon Machine Image), indicated by an .../AMIref type.

Transcript


TOSCA Metafile and CSAR File Structure The corresponding CSAR has the structure illustrated in the slide. The TOSCA.meta file is contained in the TOSCA-Metadata directory. The Payroll.tosca file itself is contained in the Service-Template directory. Also, the PayrollTypes.tosca file is in this directory. The TOSCA.meta file is also shown.

Wrap up and Take away Cloud Computing technology is well supported by standards on architecture part and on the major cloud infrastructure components Standardisation is a major factor of cloud services and data interoperability This also motivates development of the Intercloud architectures and models Knowing both cloud standardization bodies and cloud related standards is the necessary knowledge for effective design and use of cloud services