OASIS TOSCA. Introduction and Overview

Transcription

1 OASIS TOSA Introduction and Overview Frank Leymann, IBM & U of Stuttgart (Leymann@iaas.uni-stuttgart.de Thomas Spatzier, IBM (thomas.spatzier@de.ibm.com)

2 Agenda TOSA Overview and Examples TOSA oncepts Explained TOSA advanced Features 2

3 Motivation for TOSA Even simple cloud services sometimes have complex software and hardware infrastructures backing them. So how do we ensure portability? Deploy to my private cloud Deploy to any other cloud 3

4 Properties Properties What is TOSA? Topology and Orchestration Specification for loud Applications A language for defining Service Templates including a Topology Template describing the structure of a service elationship Template Service Template Topology Template type for Node Types apabilities equirements Interfaces Scripts Installables Definition of building blocks for services along with the implementation artifacts for manageability operations type for Images and the definition of deployment artifacts for components Node Template including the definition of plans for orchestrating the application Plans elationship Types Interfaces Definition of possible links between components Packaging format (SA) for packaging models and all related artifacts. loud Service Achive (SA) 4

5 Scenario 1: Portability of loud Applications loud Provider A loud Provider B Deploy & Manage Deploy & Manage 5

6 Scenario 2: Market-Place of loud Applications 3. Browse and Select 5. Use Service atalogue 4. Provision 2. Publish Service Template 1. reate 6

7 TOSA T Members 3M ActiveState Axway A Technologies enturylink isco itrix loudsoft EM Fujitsu Google HP IBM Huawei Jericho Systems NetApp Nokia Siemens Pricewaterhouse Primeton ed Hat SAP Software AG VE Vnomic WSO2 Zenoss 7

8 1 st Interop Example: SugarM SugarMApp SugarMDB depends on [WebApplication] connects to [MySQLDatabase] PHPModule [ApacheModule] hosted on hosted on installed on Apache MySQL [ApacheWebServer] [MySQL] hosted on hosted on LinuxOS4Web LinuxOS4DB [OperatingSystem] [OperatingSystem] hosted on hosted on Server4WebTier Server4DBTier [Server] [Server] 8

9 Templates Types Language TOSA v1.0 spec Using TOSA to model Applications Node Type elationship Type Implementation Artifact Deployment Artifact MySQL Database MySQLDBontainer eq. MySQL LinuxOS eq. start.sh start.sh configure.sh PMs: mysql mysql-server MySQLDBonnection Properties: ontext root: /mycrm SugarMApp [WebApplication] SugarMDB [MySQLDatabase] Properties: DB Name: mysqldb Properties: HTTP Port: 8080 Apache [ApacheWebServer] MySQL [MySQL] Properties: Admin User: myadmin Primary focus for users Orchestrator Deployed Instances 9

10 ole of elationships in Model Processing NodeType Application is of type elationshiptype DBonnection is of type is of type NodeType Database Lifecycle operations (create, configure, start, ) are used by an orchestrator to create and manage components NodeTemplate MyApp NodeTemplate MyDB onnector concept elationship Types declare what endpoints they can connect, and which processing logic they inject to establish a link at runtime Base elationship Types HostedOn, DependsOn and onnectsto define the base semantics for processing topology models Use defined lifecycle operations to deploy and manage each component Use base relationship types to derive processing order Process a host before a hosted component (HostedOn) Process a provider before a client (DependsOn, onnectsto) If a component is related to another component, see if relationship injects additional processing logic (e.g. pre-configure endpoint) a pretty mechanical process 10

11 How is a Topology processed? Use base relationship types to derive component processing order First process a host, then process hosted component First process a component that another component depends on, then process the dependent component First process a component that another component connects to, then process the connecting component For each component Deploy its Deployment Artifacts Invoke lifecycle operations in right sequence (create, configure, start ); their can be no-ops If a relationship contributes logic, inject it into component operation invocations Web 4 Web 5 Web 3 Web 2 Web 1 relationship injects logic DB 4 DB 3 DB 2 DB 1 Web 1 create VM DB 1 create VM Web 2 Web 3 perform base OS config install and configure httpd run in parallel DB 2 DB 3 perform base OS config install and configure MySQL Web 4 install and configure php runtime DB 4 create and configure SugarM database Web 5 install and configure SugarM app, configure database endpoint properties wait for step DB 4 to complete 11

12 Two Flavors of Processing Declarative What? Example: I want this, realize it! untime interprets topology and does deployment Imperative How? Example: First do this, than that. Management plan explicitly describes each step Plans

13 Declarative vs. Imperative Evaluation Imperative Style Declarative Style Logic completely implemented by loud Template Hybrid Approach Logic completely implemented by ontainer Deployment Flow Flexibility & ustomizability (Full Orchestration) Ease of Modeling Low Entry Barrier (Deployment & Decommissioning)

14 How Do Plans Do Orchestration? reate luster Task of a plan refers to interface of a topology node refers to WAS Topology node specifies all interfaces offered to manage it Interface is bound to a concrete implementation bound to Implementation is copied from SA, or Implementation already available at providers side, or A standardized loud Interface (Iaas, PaaS, SaaS) is used, or... 14

15 ompute Storage ompute Storage ompute Storage equirements & apabilities Some Application Database provider = MySQL version >= 5.5 Database Database Provider arch = x86_64 cpus = 2 mem >= 4GB OS = Linux Some Application size >= 10GB Database provider = MySQL version >= 5.5 equirements can be fulfilled explicitly by other components in the model arch = x86_64 cpus = 2 mem >= 4GB OS = Linux equirements can be fulfilled size by >= the 10GB runtime equirements/apabilities are base for substitutability Some omponent Provider A O Provider B O Provider 15

16 Model omposition Service Template 1 Node Template Service Template 2 Node Template boundary definitions Subsystems can be abstracted in some models. Other models can define details of subsystems. separation of concern, re-use 16

17 Usage Scenarios for Model omposition & Substitution Varying deployment options Layering of models WebApp ustom workload App DB Application Layer WebTier Multiple options of middleware deployments Tomcat MySQL Platform Layer Web Server VM Load Balancer VM Web Server VM 1..* Multiple options of infrastructure configurations VM Network VM Storage Infrastructure Layer Single node web tier Scalable web tier 17

18 Learn more about TOSA TOSA Specification, Version 1.0 ommittee Specification 02, 9 May 2013, TOSA Primer, Version 1.0 ommittee Note Draft (ND) 01, Public eview Draft 01, 31 January 2013, TOSA Implementer's ecommendations for Interoperable TOSA Implementations, Version 1.0 Interoperability Subcommittee, Working Draft 01, ev. 02, 14 January 2013, TOSA Interoperability Subcommittee, SugarM Scenario Sample SA Preliminary Draft SA for Interop. Testing against TOSA v1.0 Specification, 18

19 Thank you for your attention! 19