ODCA Service Orch MasterUM v1.0 Nov2012

7/27/2019 ODCA Service Orch MasterUM v1.0 Nov2012

1/49

OPEN DATA CENTER ALLIANCESM

Master Usage Model:Service Orchestration REV 1.0


2/49

Copyright 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.2

Open Data Center Alliance: Service Orchestration Rev 1.0

Table of Contents

Legal Notice ............................................................................................................................................................................................... 4

Acknowledgments .............. .............. ............... .............. .............. .............. .............. ............... .............. .............. .............. .............. ............ 4

Terminology and Provenance ............. .............. .............. .............. .............. ............... .............. .............. .............. .............. .............. ............ 4

1.0 Executive Summary .............. .............. .............. .............. .............. .............. ............... .............. .............. .............. .............. .............. ..... 5

2.0 Purpose ............................................................................................................................................................................................... 6

3.0 Taxonomy ............. .............. ............... .............. .............. .............. .............. .............. ............... .............. .............. .............. .............. ..... 6

Table 3.1Terms and Denitions............... .............. ............... .............. .............. .............. .............. .............. ............... .............. .. 6

Figure 3.1Overview o the CIaaS Environment .......................................................................................................................... 7

4.0 Introduction ......................................................................................................................................................................................... 9

5.0 Reerence Framework .........................................................................................................................................................................10

Figure 5.1High-Level Grouping o Service Scenarios ................................................................................................................10

6.0 Usage Scenarios .................................................................................................................................................................................11

6.1 Usage Scenario 1Compose Service ..........................................................................................................................................11

6.2 Usage Scenario 2 Submit Provisioning Request ........................................................................................................................12

6.3 Usage Scenario 3 Reserve Resources or Service .....................................................................................................................12

6.4 Usage Scenario 4Deploy Service ..............................................................................................................................................13

6.5 Usage Scenario 5Track Status and Manage Deployment ...........................................................................................................13

6.6 Usage Scenario 6Reopen Expired Request ...............................................................................................................................14

6.7 Usage Scenario 7Start Dependencies .......................................................................................................................................15

6.8 Usage Scenario 8Stop Dependencies .......................................................................................................................................15

6.9 Usage Scenario 9Suspend Cloud Service .................................................................................................................................16

6.10 Usage Scenario 10Resume Cloud Service ...............................................................................................................................16

6.11 Usage Scenario 11Systems Monitoring, Alerting, and Data Collection ......................................................................................16

6.12 Usage Scenario 12Systems Administration and Remediation ...................................................................................................17

6.13 Usage Scenario 13Reporting ..................................................................................................................................................18

6.14 Usage Scenario 14Capacity Planning ......................................................................................................................................18

6.15 Usage Scenario 15Auditing .....................................................................................................................................................19

6.16 Usage Scenario 16Change a Deployed Service Instance ......................................................................................................... 20

6.17 Usage Scenario 17Auto Scale .............. .............. .............. .............. ............... .............. .............. .............. .............. .............. ... 20

6.18 Usage Scenario 18 Comply to Regulatory Requirements .............. .............. ............... .............. .............. .............. .............. ..... 21

6.19 Usage Scenario 19 Service and Data Termination and Deletion .............. .............. .............. .............. .............. .............. .......... 22


3/49

Copyright 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED. 3


7.0 Service Orchestration Overview ...........................................................................................................................................................24

Figure 7.1Generic Cloud Ecosystem Architecture .....................................................................................................................24

8.0 Service Catalog Overview ................................................................................................................................................................... 26

8.1 Background .............. .............. .............. .............. ............... .............. .............. .............. .............. .............. ............... .............. ....... 26

8.2 Description ................................................................................................................................................................................. 26

8.3 Service Catalog Liecycle ............................................................................................................................................................ 28

Figure 8.3.1Service Catalog Liecycle..................................................................................................................................... 28

8.4 Service Catalog Usage ................................................................................................................................................................ 28

8.5 Service Catalog XML Structure.................................................................................................................................................... 29

Example 1 ................................................................................................................................................................................. 30

Example 2 ................................................................................................................................................................................. 31

Example 3 ................................................................................................................................................................................. 319.0 Services Interace Overview ............................................................................................................................................................... 31

Table 9.1Requested Collections and Associated Usage Models ............................................................................................... 32

Table 9.2 Requested Resources and Associated Usage Scenarios ............................................................................................ 33

10.0 Key Perormance Indicators Overview ............................................................................................................................................... 35

Figure 10.1KPI Visualization ................................................................................................................................................... 35

Table 10.1Measures in KPI Calculation ............. .............. .............. .............. .............. ............... .............. .............. .............. ..... 37

11.0 Orchestration Liecycle Overview ............. .............. .............. .............. .............. ............... .............. .............. .............. .............. .......... 38

Figure 11.1Orchestration Liecycle Flowchart ............... .............. .............. .............. .............. .............. ............... .............. ....... 38Table 11.1High Level Process or a Service Requiring Orchestration ............ ............... .............. .............. .............. .............. ..... 39

Table 11.2Liecycle Events and Phases .............. .............. .............. ............... .............. .............. .............. .............. .............. ... 40

Figure 11.2Service Catalog Lie Cycle .....................................................................................................................................41

Table 11.3Dened Cloud Consumer Responsibilit ies .............. .............. .............. ............... .............. .............. .............. ............ 42

Table 11.4Activities Within the Phases o Orchestration .......................................................................................................... 43

12.0 Usage Requirements...... .............. .............. .............. .............. ............... .............. .............. .............. .............. ............... .............. ....... 45

Table 12.1Additional Requirements .............. .............. .............. ............... .............. .............. .............. .............. .............. .......... 45

13.0 RFP RequirementsService Providers ............................................................................................................................................... 4614.0 Summary o Industry Actions Required ..............................................................................................................................................47

15.0 Reerences ............. .............. .............. .............. .............. ............... .............. .............. .............. .............. .............. ............... .............. 48


4/49



Legal NoticeCopyright 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.

This Open Data Center AllianceSM Master Usage Model: Service Orchestration is proprietary to the Open Data Center Alliance, Inc.

NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Open Data Center Alliance Participants only havethe right to review, and make reerence or cite this document. Any such reerences or citations to this document must give the Open Data

Center Alliance, Inc. ull attribution and must acknowledge the Open Data Center Alliance, Inc.s copyright in this document. Such users are

not permitted to revise, alter, modiy, make any derivatives o, or otherwise amend this document in any way.

NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use o this document by Open Data Center Alliance

Participants is subject to the Open Data Center Alliances bylaws and its other policies and procedures.

OPEN DATA CENTER ALLIANCESM, ODCASM, and the OPEN DATA CENTER ALLIANCE logo are trade names, trademarks, service marks and

logotypes (collectively Marks) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly

prohibited.

This document and its contents are provided AS IS and are to be used subject to all o the limitation set orth herein.

Users o this document should not reerence any initial or recommended methodology, metric, requirements, or other criteria that may becontained in this document or in any other document distributed by the Alliance (Initial Models) in any way that implies the user and/or its

products or services are in compliance with, or have undergone any testing or cer tication to demonstrate compliance with, any o these

Initial Models.

Any proposals or recommendations contained in this document including, without limitation, the scope and content o any proposed

methodology, metric, requirements, or other criteria does not mean the Alliance will necessarily be required in the uture to develop any

certication or compliance or testing programs to veriy any uture implementation or compliance with such proposals or recommendations.

This document does not grant any user o this document any rights to use any o the Alliances Marks.

All other service marks, trademarks and trade names reerenced herein are those o their respective owners.

Published November, 2012

AcknowledgementsODCA would like to acknowledge the substantial contributions o content and prior ar t rom Deutsche Bank, UBS, NAB, Deutsche Telekom,

Bank, Leumi, Atos CapGemini, BMW, and rom Wikipedia.

Terminology and ProvenanceSome o the content o this document has been sourced with permission rom work product outside the ODCA. Every eor t has been made to

reconcile terminology and nomenclature. Where this is a confict, however, ODCA terms take precedence.


5/49

OPEN DATA CENTER ALLIANCESM

Master USAGE MODEL:Service Orchestration REV 1.0


1.0 Executive SummaryAs service o erings rom cloud providers become more complex and open, it will become increasingly important to ensure that cloud

inrastructure requirements are aligned with cloud consumer demand and can scale as needed. This includes providing the underlying

physical resources, such as servers, networks, storage, and hosting inrastructure, and the cloud sotware that renders these resources. Inthis environment, service orchestration becomes essential to developing and providing Compute Inrastructure as a Service (CIaaS) that is

relevant to a variety o cloud consumers.

What is service orchestration? Briefy stated, its a paradigm that supports cloud providers in arranging, coordinating, and managing

computing resources as a system o components and automated workfows that can be delivered as cloud services to cloud consumers. The

scope o this involves three types o system componentsthe service layer, the resource abstraction and control layer, and the physical

resource layerwhich are the underlying oundations o the cloud providers oerings provided in a service catalog.

This document, ODCA Master Usage Model: Service Orchestrationprovides the usage model or service discovery and orchestration or

Compute IaaS. This includes all the components, repositories, data structures, conversation maps, and workfows that allow a cloud provider

to orchestrate services to meet objectives determined by the cloud subscriber and or the context o use. It denes automation required or

orchestration that includes programmatic interaces, interaction patterns, control interaces, and liecycle management.

This usage model includes 19 usage scenarios describing various stages o a cloud service engagement, including ordering, starting and

stopping, running, changing and ending or deleting cloud services. It also lays out the oundation or the next phase o usage development,

such as bursting between clouds and other areas o the cloud that include PaaS, SaaS, and so on.

Finally, the document makes recommendations or industry actions to urther develop capabilities that are oundational to building a

marketplace o services that allows a cloud consumer to source well-dened and standards-based services.

While services composed in such orchestrations can be sourced rom either public, private, community, or hybrid clouds, the ocus o

this usage model is the cloud subscriber sourcing services rom public cloud providers. The orchestration could be as simple as placing

constraints on the use o the service to more complex orchestrations that are a composition o more elemental services to derive an overall

higher level o service.

This document serves a variety o audiences. Solution providers and technology vendors will benet rom its content to better understand

customer needs, and to their tailor service and product oerings. Standards organizations will nd the inormation helpul in dening end-user relevant and open standards.


6/49



2.0 PurposeThis document ocuses on service discovery and orchestration or Compute IaaS. It denes automation required or orchestration that

includes programmatic interaces, interaction patterns, control interaces, and liecycle management.

The goals o this usage model are as ollows:

Deine the basic elements o service orchestration or Compute IaaS.

Apply the baseline work on the ODCA Usage Model: Service Catalog1 and ODCA Usage Model: Standard Units o Measure or

IaaS2

Identiy the ODCA Usage Model: Service Catalog1, API interace, key perormance indicators (KPIs), and process or Service

Orchestration.

Align with the ODCA Master Usage Models: Commercial Framework3and Compute IaaS (CIaaS)4to underpin cloud services

provisioning.

Deine a standard orchestration process or service integration which can be used as a reerence model or improving

interoperability between cloud providers and subscribers.

3.0 Taxonomy

Term Denition

Auto Scaling The ability to automatically provision a new service instance or remove an existing serviceinstance in a collection as dened by a set o one or more policies. It also includes the ability toalter a conguration to align more directly on usage requirements.

Bursting The ability or a cloud consumer to scale out its inrastructure rom one cloud provider intoanother, typically rom a private cloud provider to a public cloud provider.

Collection Describes a set o one or more service instances.

Migration The ability or cloud consumer to move a service instance rom one cloud provider to another.

Post Deployment Task Represents a task to be executed ater the deployment o service instance, typically in the orm oa script that the cloud consumer provides.

Reservation A conrmation rom the cloud provider that the specic set o resources specied in a servicerequest has been reserved or the cloud consumer.

Service Composition The action o dening the specication or a set o interrelated components that makes up aservice.

Service Instance An occurrence or instantiation o the service as lis ted in the catalog that is deployed into theenvironment or a cloud consumer.

Service Orchestration The ongoing ability to arrange, coordinate, and manage the automated deployment andconguration o one or more interrelated components required or service delivery at a point intime.

Service Request An order submitted by the cloud consumer that details the service and its composition that thecloud provider is expected to deliver.

Table 3.1Terms and Deinitions
http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=445:service-cataloghttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measurehttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measurehttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=445:service-cataloghttp://www.opendatacenteralliance.org/docs/ODCA_Commercial_Framework_MasterUM_v1.0_Nov2012.pdfhttp://www.opendatacenteralliance.org/docs/ODCA_Compute_IaaS_MasterUM_v1.0_Nov2012.pdfhttp://www.opendatacenteralliance.org/docs/ODCA_Compute_IaaS_MasterUM_v1.0_Nov2012.pdfhttp://www.opendatacenteralliance.org/docs/ODCA_Commercial_Framework_MasterUM_v1.0_Nov2012.pdfhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=445:service-cataloghttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measurehttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measurehttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=445:service-catalog


7/49

Copyright 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.

The ollowing diagram provides an overview o a CIaaS environment, and the variety o components and systems that are addressed by the

orchestration task. Note: Orchestration is indicated on the right side o the diagram.

Figure 3.1Overview o the CIaaS Environment

The top layer represents the service bundlinginto usable services or a consumer, rom the service provider, and accessible through a servicecatalog; or example, availability, administration, and data recovery (DR) as represented in the service catalog. Access to this catalog is based

on both Graphical User Interace(s) (GUIs), Command Line Interaces (CLIs) and Application Programmable Interace(s) (APIs).

The multiple layers, ront to back, represent the contributions and interactions and responsibilities rom vendors, service providers, and

service consumersall have some responsibility in the Orchestration process which must be triggered, and these have to be clearly mapped

and integrated within the Orchestration process. (For example: the hardware vendor must support the SLA-based Break Fix requirement, the

service provider must take care o the SLA monitoring, incidents and events, and the consumer must dene his data classication, availability

and perormance requirements, and SLA requirements).

The denitions or each block in Figure 3.1 are as ollows:

1. Solution Provider Plane

a. Monitoring: Monitoring o the constituent element o the overall cloud service or which the solution provider is contracted.

b. Resource Allocation: Allocation o contracted resources to overall ederation that comprises the cloud service, and can include

people, technology, and processes.

c. Remediation: Address and resolve incidents and problems.

d. Tuning & Optimization: Monitor perormance and resolve any bottlenecks or IO contention, and maximize capacity utilization/

eciency o provided resources.

BusinessProcesses

ActionableSe

rviceCatalog(UIandAPI

FacilityPower, Cooling, Physical Space

Cloud Aware Apps

Web Data Message

PaaS

SaaS

Web & Data Service Interoperability

IaaS

Traditional & Cloud Aware Apps

C ompu te St ora ge N etwork

Services

Remediation

Application

Operations

ServiceManagement

Integration

Service

Desk

Orchestrationof End-to-End

Services

Capacity &Performance

SW Delivery

OS and Apps

Configuration

Event

Security

ApplicationDevelopment

EndUser

Services

Monitoring

ResourceAllocation

Remediation

Tuning &Optimization

Solution Provider

Service Subscriber

Service Provider

7



8/49


2. Service Receiver Plane

a. End User: Overall end consumer o the service, unding the use o the cloud services.

b. AppDev: Internal corporate application development team, developing and operating business applications on the cloud

inrastructure, also providing data classication, business processes, and business rules and regulatory requirements.

c. Business Processes: Provision o the overall business processes into which the cloud based applications integrate as part o

an overall system, in order to convert dened inputs to dened outputs.

3. Service Provider Plane

a. Remediation: Address and resolve incidents and problems.

b. Application Operations: Monitor, run and perorm scheduled and dened tasks relating the smooth running and operations o

an application, on the cloud inrastructure.

c. Service Management: Monitor and ensure the achievement o dened SLAs and KPIs or the cloud service, including all cloud

elements, nancial, technical and legal dimensions.

d. Integration: Connect cloud based applications and processes to any other required/dened systems according to business

processes, rules, and interace denitions, in such a way as to enable the dened inputs and outputs o the business system,

based on the cloud inrastructure, to interact, internally, and with any external systems to the cloud.

e. Service Desk: Monitor events and queues or cloud based services, and respond and alert support resources in the event o an

incident or problem, as well as acting as an interace or cloud consumers to log calls, and nd status updates. May use web,

telephone and other interaces.

. Capacity & Service: Monitor and report overall service capacity consumption, available resources, trends, and create relevant

reports to enable consumer, operational and service delivery teams to operate and optimize the cloud inrastructure to

maximum eciency and perormance.

g. SW Delivery (OS & Apps): Dene cloud service elements and deliver the sotware components according to dened catalog

denitions, installed on the cloud inrastructure. Special ocus is on enabling the applications to be cloud aware so that

they can operate on vir tualized inrastructure. Additional packaging and bundling o sotware elements will constitute PaaSand SaaS oerings, depending on the level o unctionality, and the elements combined into useul pre-determined groups as

systems, with dened processes and unctions.

h. Conguration: Dene scripts and pre-determined implementation ormats, in addition to the binaries that the sotware

elements are undamentally composed o, and extends to the integration o so tware elements into PaaS and SaaS bundles

potentially.

i. Event: Any data generated as a result o a cloud element operation. Produces data which contributes towards reporting,

identication o incidents and problems, as well as nancial and compliance reporting

j. Security: Provides rules and guidelines or compliant delivery o services, and ensuring the security o the cloud service

according to dened requirements and catalog entries.

k. SaaS: The capability provided to the consumer is to use the providers applications running on a cloud inrastructure andaccessible rom various client devices through a thin client interace such as a Web browser (e.g., web-based email). The

consumer does not manage or control the underlying cloud inrastructure, network, servers, operating systems, storage, or

even individual application capabilities, with the possible exception o limited user-specic application conguration settings.5

l. PaaS: The capability provided to the consumer is to deploy onto the cloud inrastructure consumer-created applications using

programming languages and tools supported by the provider (e.g., java, python, .Net). The consumer does not manage or

control the underlying cloud inrastructure, network, servers, operating systems, or storage, but the consumer has control ove

the deployed applications and possibly application hosting environment congurations.5

8



9/49


m. IaaS: The capability provided to the consumer is to rent processing, storage, networks, and other undamental computing

resources where the consumer is able to deploy and run arbitrary sotware, which can include operating systems and

applications. The consumer does not manage or control the underlying cloud inrastructure but has control over operating

systems, storage, deployed applications, and possibly select networking components (e.g., rewalls, load balancers).5

n. Facility: The building acility where the cloud system is located; location is typically identiable by means o the networktermination on the compute inrastructure rom which the cloud services are provided.

For urther details about the elements o the diagram, reer to the ODCA Master Usage Model: Compute Inrastructure as a Service (CIaaS)4

4.0 IntroductionService discovery and orchestration is a paradigm that supports cloud providers in arranging, coordinating, and managing computing

resources as a system o components and automated workfows that can be delivered as cloud services to cloud consumers.

At the most basic level a service orchestrator can be a human, but or the purpose o this document, an orchestrator is an automation

service that provides orchestration across various technical and business workfow domains. Because the cloud is all about scale, automated

workfows are essential to the delivery o cloud services, which includes ullment assurance and billing in addition to other domains.

The main dierence between workfow automation and service orchestration is that automated workfows represent the entities andexecution relationship; automation is the non-human service that drives the workfow. These workfows are oten processed and completed

as processes with a single domain.

On the other hand, service orchestration includes a workfow, but implies directed action towards larger goals and objectives. In a nutshell, it

is dierent rom a typical workfow automation process because it ties together a variety o dierent or disparate automated processes and

IT resources that use workfows through a portal rom which those workfows can be managed.6

Service orchestration or any type o cloud service involves specic considerations. Functional, non-unctional, and constraint descriptions

must be clearly dened. Introspection o a service may be useul in determining these details. A well-dened service catalog where these

services can be looked up to determine which services are needed or required unctionality as well as the interaces that support them is a

must-have.

Discovery is a process o assessing the capabilities o the services and contracts as well as the commercial parameters that allow ecient

transactions that are highly secure with great elasticity. In the uture, with established marketplaces or services, i t will be possible to have

pre-qualied service providers and services and discovery time should be reduced.

Service reservation or a declaration o intent and when orders will be lled, such as when the service and resources are lled is important or

ullment o a service.

Identication o the methods or service orchestration o enhanced services, customization, or mashups is an important part o orchestration.

This also includes requirements related to business processes, outsourced segments o the business process to external cloud services, and

orchestration or managing contracted services. Dening the order o services may be necessary to identiy other dependencies, such as

liecycle management, interoperability o environments, bootstrapping, and so on.

Security considerations are a necessary requirement to delivering a robust cloud service. For example, authentication, authorization, audit

and accounting (AAAA) are essential to service orchestration as consumers evaluate such topics as ederated identity.

Service Level Agreements (SLAs) are also essential to the ullment o cloud services. This might take place either in-band, out-o-band, or in

advance o a specic engagement.

Using existing work rom the ODCA workgroups, this paper ocuses on how service components are combined based on the CIaaS

ramework. It also takes the viewpoint o the service consumer initially, and will later be updated to include the viewpoints o the service

providers and vendors.

9

http://www.opendatacenteralliance.org/docs/ODCA_Compute_IaaS_MasterUM_v1.0_Nov2012.pdfhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=678:HW_ODCA_%20IdM_PrivAccess_Rev1.0_finalhttp://www.opendatacenteralliance.org/docs/ODCA_Compute_IaaS_MasterUM_v1.0_Nov2012.pdf


10/49


Figure 5.1High-Level Grouping o Service Scenarios

This usage model contains 19 service orchestration usage scenarios between a cloud subscriber and a public cloud provider or CIaaS.

This usage model lays the oundation or the next phase o usage development and other areas o the cloud. It identies what needs to be

congured or the CIaaS cloud service, what must appear in the service catalog, as well as how the client orders it, orders changes, orders

decommissioning, and how it is proved that they are receiving the service.

5.0 Reference FrameworkThe ollowing ramework diagram illustrates ve high level groupings o usage scenarios based on the orchestration tasks that cloud

subscribers execute, which also map closely to the industry concepts o Install, Move, Add, Change, and Delete.

Cloud Service Life Cycle

Orchestration Usage Scenarios

Run CloudServices

14. Capacity Planning

11. System Monitoring &Data Collection

13. Reporting

15. Auditing

End / Delete Cloud

Services

18. Comply RegulatoryRequirements

19. Service and DataTermination & Deletion

16. Changes to DeployedService Instance

17. Auto Scaling

Change CloudServices

7. Start Dependencies

8. Stop Dependencies

Start / Stop CloudServices

Order CloudServices

4. Deploy Service

1. Compose Service

2. Submit ProvisioningRequest

3. Reserve Resourcesfor Service

10. Resume

9. Suspend

5. Track Status andManage Deployment

6. Reopen ExpiredRequest

12. System Administration& Remediation

More detail about each usage scenario is provided in the sections that ollow.

10



11/49


6.0 Usage Scenarios

6.1 Usage Scenario 1Compose Service

Actors: Cloud subscriber, cloud provider

Goal: Composition service order with advanced structures and dependencies, and the ability to manage deployment across multiple cloudproviders.

Assumption 1: An order or a complex service composition can target deployment to more than one service provider.

Assumption 2: Cloud subscriber should expect data validation, resource reservation, release or deployment, and progress tracking should

unctional similarly as dened above.

Success Scenario 1: Ability or cloud subscriber to compose a simple or more complex service request and structure. An order that requests

only a single service type (i.e., a VM instance) is the simplest orm. The complex composition proposed here is to allow cloud subscriber

to nest service requests in a single order. An example is a request that is composed o multiple VM instances with post deployment tasks

dened so that successul ullment o the order will result in an application that is ready to run. There are more advanced customizations

that must be considered such as but not limited to priority/dependency on the order o deployment. Service orchestration is visibility more

relevant here and must be able to reliably determine when an instance is successully deployed so that the orchestrator can move orwardwith the next deployments in the priority/dependency list.

Steps:

1. Cloud subscriber creates a new composition o a service: For each service instance that the cloud subscriber wants to embed into

this new request, cloud subscriber repeats the ollowing:

Select the cloud provider.

Deine the service identiier.

Deine the identity o the service process (technical user identity).

Deine the cloud subscribers operation support.

Select predeined user group/role that will have rights to manage the instance o this service based on ODCA Usage Model:Identity Management Interoperability Guide7

Select the ODCA Usage Model: Security Monitoring8 requirements.

Select the security requirements based on the bronze, silver, gold and platinum tiers deined in the ODCA Usage Model: Provider

Assurance. 9

Determine the service instance identiier (instances identiier) (i.e. network address o the server).

Dene the services runtime attributes such as memory, vCPU, storage, network, location.

Choose the desired commercial and nancial terms, SLA, qualities o service and availability or delivery o service.

Select the required post-deployment tasks and automation scripts.

2. Cloud subscriber identies dependencies in deployment (such as when instance #2 cannot start until instance #1 is successullycompleted).

3. Cloud subscriber selects notication methods, such as email or text.

Failure Condition 1: Data is incomplete.

Failure Handling 1: The subscriber is notied and prompted to correct the composition.

Failure Condition 2: Cyclic dependencies are identied and erred.

Failure Handling 2: The subscriber is notied and prompted to correct the composition.

11

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_finalhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_finalhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_finalhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_finalhttp://www.opendatacenteralliance.org/docs/ODCA_SecurityMonitoring_Rev1.1_Final.pdfhttp://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdfhttp://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdfhttp://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdfhttp://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdfhttp://www.opendatacenteralliance.org/docs/ODCA_SecurityMonitoring_Rev1.1_Final.pdfhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_finalhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=676:HODCA_%20IdM_%20InteropGuide_Rev1%200_final


12/49


6.2 Usage Scenario 2 Submit Provisioning Request


Goal: Validate, reserve resources (trigger Usage Scenario 3) and submit service request.

Assumption 1: Usage Scenario 1Compose Service has been completed.

Assumption 2: A new order process has been star ted but not yet released or deployment.

I data is complete and resources reserved, the cloud subscriber can release the order.

I resource reservation has expired, the cloud subscriber can submit request again.

I data is complete but one or more resources are not available, the cloud subscriber can make adjustments or cloud subscriber can request

cloud provider to reserve the resources or the order when they become available.

I data is not complete, the order is saved as incomplete, and cloud subscriber can continue at a later date and time.

At any given time, the cloud subscriber can delete the order and any resources reserved will be released back into the resource pool.

Success Scenario 1: Cloud subscriber submits the request to provision service. On submission, cloud provider checks or resource

availability and reserve resources. Cloud subscriber reviews the nal order prior to release or automatic deployment.

Steps:

1. Cloud subscriber selects the composed service created in the Usage Scenario 1, and submits to the cloud provider.

2. On request submission to the cloud provider:

Cyclic dependency is identiied. I a cyclic dependency is identiied by the cloud provider, the dependency is highlighted, and

prompts the cloud subscriber to review.

Each cloud provider checks i all the requested resources in the order are available and meet the speciications.

I data is incomplete, the missing data is highlighted, and prompts the cloud subscriber to review.

I the order can be met, the cloud provider reserves the resources or the cloud subscriber (trigger the Usage Scenario 3

Reserve Resources or Service). Reservation has an expiration date.

I the order cannot be met, the cloud provider will provide an estimated date in the uture when the cloud subscriber can expect

resources to become available.

3. Cloud subscriber reviews the order nally prior to release or automatic deployment.

Failure Condition 1: Data is incomplete

Failure Handling 1: The subscriber is notied and prompted to complete the request.

Failure Condition 2: Cloud provider does not have capacity to reserve resources or the cloud subscriber.

Failure Handling 2: The subscriber is notied and has the option o cancelling the order or waiting until resources are available.

6.3 Usage Scenario 3 Reserve Resources for ServiceActors: Cloud subscriber, cloud provider

Goal: Reserve resources or service request.

Assumption 1: Usage scenario 2Submit Provisioning Request has started.

Assumption 2: No pre-existing orders with any resources that has the same identier in the namespace. Any organization level resources,

such as user groups, networks, and rewalls, are predened and selectable.

12



13/49


Success Scenario 1: Cloud provider checks or resource availability and reserve resources.

Steps:

1. Cloud provider reserves the resources or the cloud subscriber. Reservation has an expiration date.


Failure Handling 1: The subscriber is notied and can resubmit the order at a later time. Ideally the provider noties the subscriber when

capacity is available.

6.4 Usage Scenario 4Deploy Service


Goal: Deploy service request

Assumption 1: Cloud provider conrmed resource availability and resource reservation has not expired.

Assumption 2: The service order has been released or automatic deployment. The cloud subscriber cannot make any more changes to the

service order. The cloud subscriber has an option to cancel the deployment.

Success Scenario 1: Cloud subscriber releases the service request or automatic deployment.

Steps:

1. Cloud subscriber selects rom a list o open service requests.

2. Cloud subscriber releases the service request or automatic deployment.

Failure Condition 1: Resource reservation has expired.

Failure Handling 1: The subscriber is notied and has to reopen the service request or start a new one.

Failure Condition 2: Cloud subscriber cancels the order and any resources reserved will be released back into the resource pool.

Failure Handling 2: Any resources reserved will be released back into the resource pool.

Failure Condition 3: Cloud subscriber cancels the deployment only. The service request is still open and resources are still reserved.

Failure Handling 3: The service request is still open and resources are still reserved.

6.5 Usage Scenario 5Track Status and Manage Deployment


Goal: Track progress o a service request and manage state. The cloud subscriber wants to manage a service request currently being

deployed.

Assumption 1: The cloud subscriber already submitted the service request or automatic deployment and current in progress.

Assumption 2: Deployment status is transparent to the cloud subscriber.

Success Scenario 1: Ater a service request has been released or deployment, cloud subscriber can track progress o the deployment andability to manage state.

Steps:

1. Cloud subscriber selects the service request.

2. Cloud provider returns summary about the request. Summary should include but not limited to the ollowing list o inormation:

Request ID

13



14/49


Name o request

Type o service and cloud provider

List o resources speciied in the request

Cloud provider returns deployment status. Status report should include but not limited to the ollowing list o inormation.

Percentage to completion

Estimated time o delivery

Status o di erent resources in the request

Error messages i any

Activity log

3. Depending on the current state o deployment, the cloud subscriber may choose one o the ollowing actions:

Cancel the deployment, rollback any changes, and put resources back into pool.

Pause the deployment at the next check point.

Resume deployment that was paused.

Fix error and retry/resume deployment rom last checkpoint.

Failure Condition 1: Provisioning request is not progressing and there is no error message.

Failure Handling 1: Subscriber has a sel-service means to check progress and escalate within the providers support organization.

Failure Condition 2: Deployment erred and aborted by the cloud provider.

Failure Handling 2: Subscriber is notied and can either resubmit or cancel the request.

6.6 Usage Scenario 6Reopen Expired Request


Goal: Reuse an expired service request without having to start rom scratch.

Assumption 1: The cloud subscriber previously submitted a service request but resource reservation has already expired.

Assumption 2: A new order process has been star ted but not yet released or deployment:

I data is complete and resources reserved, the cloud subscriber can release the order.

I resource reservation has expired, the cloud subscriber can submit request again.

I data is complete but one or more resources are not available, the cloud subscriber can make adjustments or cloud subscriber

can request cloud provider to reserve the resources or the order when they become available.

I data is not complete, the order is saved as incomplete, and cloud subscriber can continue at a later date and time.

At any given time, the cloud subscriber can delete the order and any resources reserved will be released back into the resource

pool.

Success Scenario 1: Cloud subscriber submits the request or service awhile back. Resources reserved by the cloud provider already

expired. Cloud subscriber can edit the request and resubmit.

Steps:

1. Cloud subscriber selects rom a list o expired service requests.

2. Cloud subscriber updates the service request. For instance: service type, reerence number, resources, dependencies,

customizations, and so on.

14



15/49


3. On submit, completeness o data is veried by the cloud provider.

4. I data is incomplete, the cloud provider highlights the missing data, and prompts the cloud subscriber to review.

5. On successul submission, the cloud provider checks i the requested resources in the order can be met.

6. I the order can be met, the cloud provider reserves the resources or the cloud subscriber (trigger the Usage Scenario 3ReserveResources or Service). Reservation has an expiration date.

7. I the order cannot be met, the cloud provider will provide an estimated date in the uture when the cloud subscriber can expect

resources to become available.

8. Cloud subscriber reviews the order one last time prior to release or automatic deployment.

Failure Condition 1: Data is incomplete.

Failure Handling 1: The subscriber is notied and prompted to complete the request.


Failure Handling 2: The subscriber is notied and can resubmit the order at a later time. Ideally the provider noties the subscriber when

capacity is available.

6.7 Usage Scenario 7 Start Dependencies


Goal: Ater successul reservation and initialization, cloud service is started.

Assumption 1: Cloud service provider conrmed resource availability.

Assumption 2: Star ting date and time do not exceed reservation period or that specic request or all resources.

Assumption 3: Cloud provider has all necessary and relevant data or the specic request.

Success Scenario 1: Cloud service is provided and started at the right point in time at the correct quality level according to the cloud

subscribers request.

Steps:

1. Start o cloud service (ensure right starting order o dependent resources i applicable).

2. Execution o cloud subscriber dened test-scenario or successul service execution; measurement o its runtime i applicable

(optional).

3. Return instance ID, star ting times, status and runtime to cloud subscriber.

4. Generate unique billing record.

Failure Condition 1: Cloud service not star ted or execution o test scenario unsuccessul.

Failure Handling 1: Escalation through cloud providers support path.

6.8 Usage Scenario 8 Stop Dependencies


Goal: Cloud service is stopped, reserved resources disengaged.

Assumption 1: Cloud service is running.

Assumption 2: Requestor is entitled to stop the service.

15



16/49


Success Scenario 1: Cloud service is stopped, resources are reed up. ID and conguration data is kept or billing and uture usage.

Steps:

1. Cloud service is stopped. Correct order o stopping dependencies is ensured.

2. Resources used by cloud service are reed up and made available to resource pool again.

3. ID, conguration and billing record are kept or uture re-initialization (see start).

Failure Condition 1: Cloud service is not stopped, not stopped at the designated time, or stopped.

Failure Handling 1: Tier 2 support o cloud provider.

6.9 Usage Scenario 9 Suspend CLOUD SERVICE


Goal: Cloud service is suspended

Assumption 1: Cloud service is running at cloud provider.

Assumption 2: It is ensured that requestor is entitled to suspend the service.

Success Scenario 1: Cloud service with all associated resources is resumed.

Steps:

1. Cloud service is suspended, check-pointing data is written, i applicable.

2. Resources stay reserved or the suspended service.

3. Billing record or unique ID is updated.

Failure Condition 1: Cloud service is not suspended.


6.10 Usage Scenario 10 Resume Cloud Service


Goal: Cloud service is resumed, resources available again.

Assumption 1: Cloud service is suspended.

Assumption 2: It is ensured that requestor is entitled to resume the service.

Success Scenario 1: Cloud service with all associated resources is resumed. I applicable, the service resumes in the last saved checkpoint

status.

Steps:

1. Cloud service is resumed. Right order o resuming resources is ensured.Failure Condition 1: Cloud service is not resumed, not resumed at the designated time, or just partially resumed.


6.11 Usage Scenario 11Systems Monitoring, Alerting, and Data Collection


Goal: Timely notication o urgent and important activity within the IaaS including health, perormance and billing.

16



17/49


Assumption 1: CIaaS has a set o KPIs which are congured based on published SLA and contract agreement between the subscriber and

provider.

Assumption 2: Dened monitoring points or data collection accommodate both KPI requirements and compliancy.

Assumption 3: Monitoring is based on pro-active, real-time architecture or all relevant KPI elements, according to a process which is

compliant with applicable country and corporate governance.

Assumption 4: A database has been created to store trend data, including on-going maintenance.

Success Scenario 1: Cloud subscriber receives an alert message when an established threshold is triggered.

Steps:

1. Thresholds and associated messaging are congured.

2. The system detects that an established threshold is reached in the running system, such as health, perormance or billing

conditions.

3. The trigger action is automatically executed to send an alert message in the proper ormat (email, SMS and message queue).

4. Identied data or trend analysis is posted to a database.

5. Data is retained or a sucient period to enable analysis and compliancy.

Failure Condition 1: Trigger condition is realized but alert is not generated.

Failure Handling 1: Error in alerting is logged and escalated. Cloud provider delivers a manual alert.

Failure Condition 2: Correct data is not retained in a database to enable sucient trend analysis.

Failure Handling 2: Update monitors to collect the correct data and to retain it in a suitable location.

Failure Condition 3: An agreed threshold was not established/captured by the cloud provider system.

Failure Handling 3: Technical business remediation, according to the agreement.

6.12 Usage Scenario 12Systems Administration and RemediationActors: Cloud subscriber, cloud provider

Goal: Take a prescribed action in response to an alert to correct a specic deect or deciency detected within CIaaS.

Assumption 1: The IaaS solution provides a mechanism to execute a remediation routine or script.

Assumption 2: Events are dened or all CIaaS service elements, with associated mapping to remediation routines or scripts. Step-out and

escalation conditions exist and are automated.

Success Scenario 1: Successul remediation executed.

Steps:

1. All events and remediation routines are dened.

2. A dened event is detected in the running system.

3. Each action associated with the event is executed.

Failure Condition 1: Failure to t rigger remediation routine or script.

Failure Handling 1: Identiy the trigger and correct remediation routine or script, and add them to the automation mechanism.

Failure Condition 2: Remediation routine or script ails

Failure Handling 2: Update the routine or script i applicable, or correct the pre-conditions expected or required by the routine or script.

17



18/49


6.13 Usage Scenario 13Reporting


Goal: Produce reports according to the dened KPIs and publish them to the authorized parties to enable proactive management and

planning.

Assumption 1: Dened reports orm a part o the service and align to the dened KPIs or the service.

Assumption 2: Ad-hoc reports can be generated as required.

Assumption 3: The monitoring system collects and retains sucient data relating to the KPIs to enable reporting, in both real time, and

historical dimensions.

Assumption 4: All reports are authenticated and tamper resistant, such as integrity checks and time stamps.

Success Scenario 1: All dened reports are rendered accurately and represent the real system.

Steps:

1. Reports are dened to show evidence that the expected service is indeed being delivered according to Key Perormance Indicators.

These include availability, perormance, capacity, service level achievement, compliance, commercial, security and other reportswhich may be deemed necessary rom time to time.

2. Data is mined automatically to create reports according to dened timing.

3. Reports are published automatical ly according to dened timeline.

Failure Condition 1: Reports are not dened.

Failure Handling 1: Identiy the relevant reports that must be produced, and the KPI related data to support them, and produce the report.

Failure Condition 2: Reports are inaccurate.

Failure Handling 2: Identiy i the incorrect data is being used, or i inadequate data is collected, and correct the gap.

Failure Condition 3: Report data is not retained.

Failure Handling 3: Identiy data and report retention requirements. Correct or uture report generation.

Failure Condition 4: Reports are inadequate to determine key service actors.

Failure Handling 4: Identiy the correct source data needed to represent the service actor, collect it, and update the report.

Failure Condition 5: Compliance requirements are not met.

Failure Handling 5: Review the process required to collect the data and produce the report, and identiy what gaps exist to achieve

compliance, and correct the process.

6.14 Usage Scenario 14Capacity Planning


Goal: Produce adequate data automatically or all parties to be able to predict service dimensions, capital expenditure, operational costs and

potential problems and incidents and plan capacity.

Assumption 1: Correct data to support capacity planning is collected and retained or an adequate period.

Success Scenario 1: Capacity planning process mines the correct data and automatically provides timely planning inputs which enable

sustainable services, and thereby avoids incident and problem occurrence.

18



19/49


Steps:

1. All capacity reporting dimensions are dened.

2. Supporting data collection is scheduled or automated.

3. Capacity data is analyzed automatically rom the available source.

4. Forecasts o events and changes are automatically produced.

5. The inormation is sent to the cloud subscriber or approval, i required by the contract .

Failure Condition 1: Service quality is impacted.

Failure Handling 1: Identiy the relevant data to analyze and develop a trend line with thresholds to orecast decision or change points.

Failure Condition 2: Unplanned costs arise.

Failure Handling 2: Identiy the relevant data to analyze and develop a trend line with thresholds to orecast decision / change points.

6.15 Usage Scenario 15Auditing

Actors: Cloud subscriber, cloud provider, third-party auditor

Goal: Produce evidence that the service is produced according to both country-compliant and corporate-compliant processes as well as

within legal boundaries.

Assumption 1: All needed data is identied, collected and retained according to processes compliant with country and corporate

requirements.

Assumption 2: An auditor is used who correctly interprets both corporate and country requirements.

Assumption 3: Some auditing is automated, and some audits are manual and ad-hoc and that data exists to support both.

Assumption 4: All reports are authenticated and tamper resistant, such as integrity checks and time stamps

Success Scenario 1: All services are proved to be rendered according to expectations, (dened by agreed upon KPIs), and in a manner that

meets the compliancy requirements o both the corporation and the country.

Steps:

1. Review i the necessary data is available to support the reporting on the agreed upon or identied KPIs.

2. Review i the method used to collect the data meets compliancy requirements.

3. Review i the method used to convert the data into reports meets compliancy requirements.

4. Schedule the audit activit ies and reports which can be automated.

5. Execute the dened auditing activit ies per the schedule and in response to ad-hoc requests.

Failure Condition 1: Required data to support KPI reporting is not available.

Failure Handling 1: Identiy the needed data, its source, and any other actors, such as retention requirements, and update the monitoringsystem to collect it.

Failure Condition 2: Unacceptable methods are used to collect the data.

Failure Handling 2: Identiy the correct method to be used or collecting the relevant data, and correct the method or process.

Failure Condition 3: Unacceptable methods are used to convert the data into reports.

Failure Handling 3: Identiy the correct method or interpreting the data into compliant reports, and then correct the process.

19



20/49


6.16 Usage Scenario 16 Change a Deployed Service Instance


Goal: Process o changes, change approvals, provision and track the entire cloud service lie cycle.

Assumption 1: All scalability and change options are based on items dened in the service catalog. No changes deviate rom options denedin the catalog.

Assumption 2: Inrastructure has ault toleranceload balancers cluster and auto ailover o compute.

Assumption 3: A set o rules exist dening what scalability options exist, which can be accommodated or both changes and scaling

workloads.

Success Scenario 1: Enhances the cloud consumer experience by:

Gives cloud consumers a unied experience and dramatically simplies requests or cloud resources.

Removes demand bottlenecks while enorcing approval policies through service automation.

Controls access to resources while providing the fexibility to choose and easily modiy services.

Steps:

1. Ensure IT organization clearly understands new governance structure and they consistently ollow new processes without creating

any shadow practices.

2. Check service catalog.

3. Check service rules.

4. Dene i standard change or non-standard change.

5. Execute change.

6. Update conguration records.

7. Execute the dened auditing activit ies per the schedule and in response to ad-hoc requests.Failure Condition 1: Change ailure.

Failure Handling 1: Run back-out script.

Failure Condition 2: Capacity constraintno landing zone or change.

Failure Handling 2: Delay change, notiy consumer o constraint, and nd an alternative resource.

6.17 Usage Scenario 17 Auto Scale


Goal: Automatically scale the number o compute resources or a subscriber based on current demand. Manage processing o cloud scale

requests and provision and track the entire cloud service lie cycle; deliver automated ullment or various business requirements and use

cases.

Assumption 1: The cloud provider has implemented a scalable architecture capable o automatically growing and shrinking based on

demand, regardless o how ast or how slow the demand changes over time.

Assumption 2: The cloud provider publishes a clear set o business rules or auto scaling with parameters that are set by the subscriber. This

includes maximum and minimum resource sizing and events that trigger growth and shrinkage.

Success Scenario 1: The workload scales out or back based on current environmental conditions.

20



21/49


Steps:

1. Front-end Site Trac: Scale based on the number o incoming requests, such as web pages, objects, and data transer.

2. The cloud consumer completes the necessary steps to request specic service and request a conrmation or the service provision

or expansion.

3. The cloud provider veries possible constraints o provision request, such as terms o service and contract, SLAs, etc.

4. Back-end Batch Processing (Scale Horizontally): Load-based scalingScale based on the number o jobs in the queue; Time-based

scalingScale based on how long jobs have been in the queue

5. The cloud provider updates the contract or a specic service, and provisions service-specic cloud inrastructure within the terms

o service requirements.

6. The cloud provider returns a conrmation message indicating the successul provision o the service.

7. The cloud provider returns evidence that the data has been deleted in accordance to the terms o service denitions.

Failure Condition 1: Scale-out request cannot be completed by the cloud subscriber.

Failure Handling 1: Consumer notied o ailed request and alternatives are suggested.

Failure Condition 2: Scale-back request cannot be completed by the cloud subscriber.

Failure Handling 2: Consumer notied o ailed request and alternatives are suggested.

6.18 Usage Scenario 18 Comply to Regulatory Requirements

Actors: Cloud subscriber, cloud provider, subscriber regulator, provider regulator

Goal: The regulatory requirements or the cloud subscriber and the cloud provider must be matched and refected in the SLA between the

cloud subscriber and the cloud provider. Contradictory requirements must be claried, and an agreement must be made that is acceptable to

the regulators.

Assumption 1: The regulatory requirements that impact the service are documented and refected in the SLA or the service. These are

corporate requirements as well as jurisdictional requirements. All regulatory requirements to be applied are identied and are part o thecontract between provider and subscriber. Methods or complying with these requirements have been identied and agreed upon between

provider and subscriber. Metrics to provide evidence have been agreed upon by the regulators.

Assumption 2: Both cloud subscriber as well as cloud provider are willing to comply with all regulatory requirements, irrelevant whether

they come rom the subscriber regulator or the provider regulator. I the regulators requirements o both cloud provider and cloud subscriber

do not dictate in which premises the data must be retained (either the providers or the subscribers) or a dened time, such as seven to 10

years or the nancial industry, it is up to both to agree on this as part o their contract.

Success Scenario 1: Termination o the service is compliant with regulatory requirements. All components o the service are shut down. All

data in les or databases is rozen. All regulatory reports are generated to provide evidence o the compliant termination o the service and

required data storage or deletion.

Steps:1. The service is terminated, and the termination does not leave any open transact ion or unresolved operation.

2. Open les or databases o the service are closed or shut down. The audit trails and log les are closed.

3. The audit trail is written to its long-term storage location (or archive); the service logs are written to their near or mid-term storage

location, such as a monitoring system, disk, or archive, according to the SLA or the service.

4. The operational data10 o the service is transerred to the place dened in the SLA, such as downloaded to the cloud subscriber or in

some way archived, or retention (see Assumption 2).

21



22/49


5. For assurance levels silver, gold, and platinum, all les and databases o the operational storage, such as disks and SSDs, are

deleted securely, that is not recoverable11. Additionally, or assurance levels gold and platinum, the le systems allocated to the

service are reormatted, including overwriting all physical disk blocks.

6. For assurance levels gold and platinum, the memory o all machines (physical and virtual) and in the various network components,

such as routers, switches, and rewalls, is securely deleted. The technical deletion process must be dened as being technicallyeasible and approved.

7. All archives on disks or tapes o the service are deleted securely so that they are not recoverable12 or destroyed.

8. The provider hands over a report evidencing all cleanup actions that were executed. The report content is dened and is part o the

contract between subscriber and provider. The report will take the assurance levels into account.

Failure Condition 1: Some transactions cannot be closed; some operations cannot be resolved when the service is shutting down graceully.

Failure Handling 1: The service is orced to shut down, unresolved operations or open transactions are logged, and provided to the

subscriber.

Failure Condition 2: The subscribers database or some les are corrupted ater the services shutdown.

Failure Handling 2: Application log and database t ransaction log are provided to the subscriber with the database les. Application log andcorrupted les are provided to the subscriber as well.

Failure Condition 3: The transer o the operational data to the subscriber ailed.

Failure Handling 3: The transer is repeated, possibly over a di erent channel.

Failure Condition 4: The provider cannot provide an evidence report that ts the contract between subscriber and provider.

Failure Handling 4: Provider has to redo some clean-up actions and reproduce an evidence report. For assurance levels gold and platinum,

the provider has to allow an external auditor to veriy the completion o the clean-up process.

6.19 Usage Scenario 19 Service and Data Termination and Deletion

Actors: Cloud subscriber, cloud provider, subscriber regulator, provider regulator

Goal: Complete the use o a service, terminate it, write out the relevant data according to requirements, scrub the inrastructure, and return

the resources to available pools.

Assumption 1: A termination ramework and process has been agreed upon within the contract or services or service elements, and a

ormal request or a service termination exists based on this.

Assumption 2: Data classication exists, with dened processes and rules.

Success Scenario 1: The service is ended as expected, data is handled as expected, and the resources are returned to the available pools

or re-use.

Steps:

1. The service is terminated and the termination does not leave any open transaction or unresolved operation.

2. Open les or databases o the service are closed or shutdown. The audit trails and log les are closed.

3. The audit trail is written to its long-term storage place, such as an archive; the service logs are written to their near or mid-term

storage location, such as a monitoring system, disk, or archive, according to SLA or the service.

4. The operational data10 o the service is transerred to the place dened in the SLA and downloaded to the cloud subscriber, or

archived) or retention. See Assumption 2.

22



23/49


5. For assurance levels silver, gold, and platinum, all les and databases rom the operational storage unit are deleted securely, and

are not recoverable.6Additionally, or assurance levels gold and plat inum, the le systems allocated to the service are reormatted,

including overwriting all physical disk blocks.

6. For assurance levels gold and platinum, the memory o all machines (physical and virtual ) and in the various network components,

such as routers, switches, and rewalls, is securely deleted as well. The technical deletion process must be dened as beingtechnically easible and approved.

7. All archives on disks or tapes o the service are deleted securely, and are not recoverable or destroyed.12

8. The provider hands over a report evidencing all cleanup actions that were executed. The reports content is dened and is part o the

contract between subscriber and provider. The report will take the assurance levels into account.

9. The resources are returned to the available pools or re-allocation within the cloud.

Failure Condition 1: Some transactions cannot be closed, or some operation cannot be resolved when the service is shutting down

graceully.

Failure Handling 1: The service is orced to shut down, unresolved operations or open transactions are logged, and provided to the

subscriber.

Failure Condition 2: The subscribers database or some les are corrupted ater the services shutdown.

Failure Handling 2: Application log and database transaction log are provided to the subscriber with the database les. Application log and

corrupted les are provided to the subscriber as well.

Failure Condition 3: The transer o the operational data to the subscriber ailed.

Failure Handling 3: The transer is repeated, possibly over a dierent channel.

Failure Condition 4: The provider cannot provide an evidence report that ts the contract between subscriber and provider.

Failure Handling 4: Provider has to redo some clean-up actions and reproduce an evidence report. For assurance levels Gold and Platinum,

the provider has to allow an external auditor to veriy the completion o the clean-up process.

23



24/49


Figure 7.1Generic Cloud Ecosystem Architecture

Front-end

Cloud Suppliers,and Providers

Front-end

Advice, Guidance

Implementation, Transition

Service Delivery

Monitoring

Service LevelRecording

Payments

Delivery, Operations

Metering

Management,Security

Image Library

Provisioning

Configuration

Catalog

Termination

Support

Billing

Master Services Agreement

Services

Offered

Available

Prices

Request

Done

Lodge

Invoke

Federation

Use

Events,

Incidents

Statistics

Avail able

Services

Capacities,

Prices

Deposit,

Invoke

Request

Create,

Admin

Usage

Events

Reporting

FAQs,

PD, RCA

Invoices

Payments

Finished

Cloud

Consumers

Cloud Broker

Visibi lity

CapacityPlanning

Allocation

ISO

Federation

Portal,API,Orchestration&Workflow

Functions

Front-end

7.0 Service Orchestration OverviewService orchestration ocuses on the triggering o a number o workfows through dierent layers o the cloud ecosystem as described earlier

in Section 4.0. It is thereore helpul to conceptualize the minimum standard o technology and the systems related to critical touch points or

orchestration and the subsequent workfow activity within a cloud ecosystem.

Cloud services are based on a number o enabling technologies that allow service to be delivered according to the characteristics dened

or the cloud as dened by NIST. Focus in this master usage model (MUM) is on the interactions to the cloud subscriber. But it must also

be noted that there are similar interactions with the service provider as well as with other solution providers within the overall service as

recognized in the services interaces section o this document. Reer to the ollowing illustration that depicts a high-level, generic cloud

ecosystem architecture that illustrates some o the touch points or orchestration while considering both hard and sot interaces.

A provision exists or an organization, or organizations to take on a number o roles as middlemen, usually described as brokerage,

integration, aggregation or orchestration. Large parts o these unctions might be automated.

The interactions to and rom cloud consumers and to and rom cloud providers are similar, with central unctionality sometimes acting

primarily as a switching center. They may be invoked through a portal, but are able to be used in a more sophisticated manner when

invoked by APIs. One issue that arises in such a multi-party arrangement is how visible, in terms o levels, prices, and volumes, the dierent

suppliers services will be between each other and to non-customers.

24



25/49


The components within the interactions are as ollows:

Master Services Agreement: As dened by the ODCA Usage Model: Regulatory Framework13, a work group within the commercial

ramework provides a contractual ramework in which services can be commissioned according to pre-agreed upon terms and conditions.

Services Catalog: As deined by the ODCA Usage Model: Service Catalog1, a work group provides a standard ramework or

the description o cloud services, especially IaaS, such that they can be described and discovered in a standard way and then

compared between suppliers.

Coniguration: Complements the services catalog by providing an indication o the available capacities and prices o the

suppliers environment at any one time. This can be used to support the implementation o conditional pricing, volume

discounting, or spot market, a market where services are traded or immediately.

Provisioning: Determines the best it or any particular request and assigns it to the relevant suppliers. This can be established

by pre-defined criteria as described in TREC rom the EC-sponsored OPTIMIS 14 project.

Image Library: Used to hold and allocate re-conigured machine images or deployment across any supplier. Images can be

deposited by cloud consumers or providers, and may or may not be made available to others.

Identity Management: Deployed on a ederated basis, using standard protocols, such as SAML, such that cloud consumer

organizations maintain their own directory o their users, and cloud providers can establish trust relationships to permit accessto their environments. These unctions can include both users who are entitled to commission and conigure systems as well as

the end-users themselves. It includes aspects such as authorization levels to order urther acilities.

Delivery and Operations: Takes place with the cloud provider who delivers services to the relevant cloud consumers.

Metering: Takes place during delivery, such that the cloud provider tracks the allocation or actual usage, depending on the

nature o the service contract or the relevant resources. This makes data available to the cloud consumer or real-time tracking,

and uses it or subsequent billing.

Monitoring: Allows or normal or exceptional events, utilisation levels, or component ailures in such a way that cloud

consumers can be alerted to potential ailures o their services, and that they or some agent can potentially take remedial

actions on their behal.

Service Level Recording: Takes place when tracking the actual services delivered against service levels, such as availability,that have been agreed upon or possible remediation and reporting to the cloud consumer. This may include utilization and

perormance levels that trigger the deployment or release o urther resources.

Support: An optional acility. This can be passive, such as the provision o requently-asked questions; or it can be more

active, whereby some agent can detect anomalies or errors in the running environment, ix the relevant ailing component, or

recommend a course o action to the cloud consumer.

Billing: Takes place on a periodic basis (typically monthly), involving the cloud consumer being notiied o their charges,

prompted by the contract terms, levels o actual usage, and service levels delivered..

Payments: Take place rom the cloud consumers directly to the cloud providers or through the broker organization.

Termination: Takes place when the cloud consumer has inished with part or all o the services.

In addition, some other possible services are shown that surround various operational services:

Advice and Guidance: Helping a potential cloud consumer determine what systems are most suitable or cloud, how they

should be conigured, and on which platorms they can be deployed.

Implementation and Transition: Actually converting applications or cloud platorms, identiying and transerring the necessary

data, setting up the environment, etc.; these are all things which the cloud consumer would otherwise have to do or themselves.

Successul CIaaS service orchestration requires a number o elements, including a service catalog, a services interace, and key perormance

indicators (KPIs). The ollowing sections cover each o these elements in turn. The service catalog section includes background inormation

and denitions as well as a detailed liecycle process or users. Inormation about a service catalogs structure also is included.

25

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=455:regulatory_frameworkhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=445:service-cataloghttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=445:service-cataloghttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=455:regulatory_framework


26/49


8.0 Service Catalog OverviewThis overview o the services catalog includes background inormation and denitions as well as a detailed liecycle process or users.

Additionally, this section includes details about the service guides XML structure and examples o how it can be used to provide relevant

inormation or implementing cloud services, such as provisioning VMs, cloud requests as well as cloud bursting capabilities.

8.1 Background

Service catalogs are designed to help organizations in their assessments and selections o cloud services. A detailed and up-to-date service

catalog is an essential component o any providers oerings. It is the mechanism by which a consumer can determine the capabilities and

characteristics o one or more services in an industry accepted standard and consistent manner.

Moreover, a standard approach to content and classication within a typical service catalog will allow consumers to be able to compare

services between providers. This will help drive competitiveness in the marketplace, allow meaningul service benchmarking and enable

consumers to be able to cross-check service details, costs and service levels on a like-or-like basis. Ultimately, in a market where services

become more and more intangible as products, a service catalog will enable the consumer to give the products more context and ensure they

do not eel as i they are missing out on elements o a service which may be more obvious in a traditional outsourced IT agreement.

The concept and design or the service catalog should be applicable to all layers o cloud services, rom Inrastructure as a Service (IaaS)

to Platorm as a Service (PaaS) and Sotware as a Service (SaaS), and to other kinds o services such as a Virtual Private Data Center

as a Service (VPDCaaS). The desire is that there should be a core set o parameters that are applicable to all o erings, plus specic

characteristics, or each o the individual services. Again, consistency across providers will allow comparisons to be made between

Documents

ODCA Service Orch MasterUM v1.0 Nov2012