OPEN DATA CENTER ALLIANCE SM Master Usage Model ......This “Open Data Center AllianceSM Master Usage Model: Compute Infrastructure as a Service” is proprietary to the Open Data

OPEN DATA CENTER ALLIANCESM Master Usage Model:Compute Infrastructure as a Service REV 1.0

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

Open Data Center Alliance: Compute Infrastructure as a Service Rev 1.0

Table of Contents

Legal Notice ............................................................................................................................................................................................... 6

Acknowledgments ...................................................................................................................................................................................... 6

Terminology and Provenance ...................................................................................................................................................................... 6

1.0 Executive Summary .............................................................................................................................................................................. 7

2.0 Purpose ............................................................................................................................................................................................... 7

3.0 Taxonomy ............................................................................................................................................................................................ 8

Table 3.1–Terms and Definitions................................................................................................................................................... 8

4.0 Defining CIaaS ..................................................................................................................................................................................... 9

Figure 4.0.1 ODCA Conceptual Framework ................................................................................................................................... 9

4.1 CIaaS Scope ................................................................................................................................................................................10

Figure 4.1.1 CIaaS in Context ......................................................................................................................................................10

4.2 CIaaS Workloads ..........................................................................................................................................................................11

4.3 Deployment Models .....................................................................................................................................................................11

Table 4.3.1 Cloud Models ............................................................................................................................................................11

4.4 CIaaS Service Attributes ..............................................................................................................................................................12

Table 4.4.1 Service Tier Attributes ...............................................................................................................................................12

4.5 General Capabilities .....................................................................................................................................................................13

4.6 CIaaS Key Performance Indicators ................................................................................................................................................15

5.0 Interoperability ....................................................................................................................................................................................17

6.0 Business Drivers and Usage Scenarios ................................................................................................................................................17

6.1 Business Usage Scenarios ............................................................................................................................................................17

Figure 6.1.1 Sample CIaaS Usage Scenarios ................................................................................................................................18

6.2 Development/Test ........................................................................................................................................................................19

Table 6.2.1 Requirements for Development and Test ....................................................................................................................19

6.3 Load Stress Test Environment ..................................................................................................................................................... 20

Table 6.3.1 Load Stress Test ...................................................................................................................................................... 20

6.4 Grid and High-Performance Computing ....................................................................................................................................... 21

Table 6.4.1 Requirements for Grid and High Performance Computing .......................................................................................... 21

6.5 Standalone Traditional Production Environment ........................................................................................................................... 22

Table 6.5.1 Standalone Cloud-Enabled Production ...................................................................................................................... 22

6.6 Enterprise Traditional Production Environment ............................................................................................................................. 23

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


Table 6.6.1 Enterprise Traditional Production .............................................................................................................................. 23

6.7 Enterprise Cloud-Aware Production Environment ..........................................................................................................................24

Table 6.7.1 Enterprise Cloud-Aware Production ............................................................................................................................24

6.8 Cloud Brokering and Federation ...................................................................................................................................................24

7.0 Service Attribute Details ..................................................................................................................................................................... 25

7.1 Functionality ................................................................................................................................................................................ 25

7.2 Availability .................................................................................................................................................................................. 25

7.2.1 Service Tier Summary: Availability ..................................................................................................................................... 25

7.3 Recoverability ............................................................................................................................................................................. 26

7.3.1 Service Tier Summary: Recoverability ................................................................................................................................ 26

7.4 Security ...................................................................................................................................................................................... 27

7.4.1 Service Tier Summary: Security ......................................................................................................................................... 28

7.5 Elasticity ..................................................................................................................................................................................... 29

7.5.1 Service Tier Summary: Elasticity ....................................................................................................................................... 30

7.6 Manageability Services ................................................................................................................................................................ 30

7.6.1 Service Tier Summary: Monitoring ..................................................................................................................................... 31

7.6.2 Service Tier Summary: Reported Sampling Interval ............................................................................................................ 31

7.6.3 Service Tier Summary: Number of Active Automated Tasks ................................................................................................ 32

7.6.4 Service Tier Summary: Reporting ...................................................................................................................................... 32

7.7 Performance ............................................................................................................................................................................... 33

7.7.1 Performance SLA ............................................................................................................................................................... 33

7.7.2 Performance Measuring ..................................................................................................................................................... 33

7.7.3 Performance Reporting ...................................................................................................................................................... 33

7.7.4 Performance Monitoring .................................................................................................................................................... 33

7.7.5 Performance Analysis ........................................................................................................................................................ 34

7.7.6 Performance Definition and Interface ................................................................................................................................. 34

8.0 Service Interface and Reference Model............................................................................................................................................... 34

8.1 ODCA Conceptual Architecture .................................................................................................................................................... 34

Figure 8.1.1 ODCA Conceptual Framework ................................................................................................................................. 34

8.2 Basic Cloud Lifecycle .................................................................................................................................................................. 35

8.3 Service Interface Requirements ................................................................................................................................................... 35

8.4 Specific Required Interfaces ........................................................................................................................................................ 37

Table 8.4.1 Specific Required Interfaces ..................................................................................................................................... 37



8.5 Services Orchestration ................................................................................................................................................................ 40

Figure 8.5.1 Interfaces ............................................................................................................................................................... 40

8.6 Usage Scenario Example: Burst Capacity at a Specified SLA .........................................................................................................41

9.0 Operations and Management .............................................................................................................................................................. 42

9.1 Overview ..................................................................................................................................................................................... 42

9.2 Motivations ................................................................................................................................................................................. 42

9.3 CIaaS Operations Usage Scenarios .............................................................................................................................................. 43

9.3.1 Usage Scenario 1–Access and Control Configuration ......................................................................................................... 43

9.3.2 Usage Scenario 2– Provisioning/Deprovisioning Capabilities .............................................................................................. 44

9.3.3 Usage Scenario 3– SLA or Service Fault Identification by Provider ..................................................................................... 45

9.3.4 Usage Scenario 4– SLA or Service Fault Identification by Subscriber ................................................................................. 45

9.3.5 Usage Scenario 5– Service Change or Outage Notification ................................................................................................ 46

9.3.6 Usage Scenario 6– Service Monitoring .............................................................................................................................. 46

9.3.7 Usage Scenario 7– Subscriber Billing and Usage ................................................................................................................47

9.4 Operations and Management Service Tiering ............................................................................................................................... 48

Table 9.4.1 Operations and Management Service Tiering ............................................................................................................ 48

10.0 Technical Architecture ...................................................................................................................................................................... 48

10.1 Assumptions and Context .......................................................................................................................................................... 48

10.2 Components.............................................................................................................................................................................. 48

Figure 10.2.1 CIaaS Architecture Components ............................................................................................................................ 49

10.3 Compute Layer .......................................................................................................................................................................... 49

10.3.1 Service Tier Summary: Compute Instance Attributes ........................................................................................................ 50

10.4 Storage Layer ........................................................................................................................................................................... 50

10.4.1 Block Storage Requirements ............................................................................................................................................ 50

10.4.1.1 Service Tier Summary: Block Storage Attributes .................................................................................................... 50

10.4.2 Object Storage Requirements ...........................................................................................................................................51

10.4.3 Storage Fabric .................................................................................................................................................................51

10.4.3.1 Service Tier Summary: Storage Fabric Attributes ................................................................................................... 52

10.5 Network Fabrics ........................................................................................................................................................................ 52

10.5.1 Service Tier Summary: Network Fabric Attributes ............................................................................................................ 53

10.6 Management ............................................................................................................................................................................. 53

10.6.1 Service Tier Summary: Management ............................................................................................................................... 54

11.0 Security Considerations .................................................................................................................................................................... 54



11.1 Security Requirements ............................................................................................................................................................... 54

11.2 Implementation Guidelines ......................................................................................................................................................... 56

11.2.1 Assumptions ................................................................................................................................................................... 56

11.2.2 General Guidelines .......................................................................................................................................................... 56

11.2.3 Service Tier Specific Guidelines: ...................................................................................................................................... 57

11.3 Security Service Catalog............................................................................................................................................................ 57

11.4 Malware Protection ................................................................................................................................................................... 57

11.5 Admission Control ..................................................................................................................................................................... 58

11.6 Security Audit and Governance .................................................................................................................................................. 59

11.6.1 Security Governance Usage Scenario ............................................................................................................................... 59

12.0 Commercial Considerations .............................................................................................................................................................. 60

13.0 Regulatory Considerations ................................................................................................................................................................ 60

14.0 RFP Requirements ............................................................................................................................................................................ 60

15.0 Next Steps and Summary of Industry Actions Required ..................................................................................................................... 60

15.1 Industry Actions Required .......................................................................................................................................................... 63

15.2 Future CIAAS Requirements Development ................................................................................................................................. 63

16.0 References ....................................................................................................................................................................................... 64

ODCA Usage Models ......................................................................................................................................................................... 64

Other Sources ................................................................................................................................................................................... 65

Endnotes .......................................................................................................................................................................................... 66



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

This “Open Data Center AllianceSM Master Usage Model: Compute Infrastructure as a Service” 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 have the right to review, and make reference or cite this document. Any such references or citations to this document must give the Open Data Center Alliance, Inc. full attribution and must acknowledge the Open Data Center Alliance, Inc.’s copyright in this document. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way.

NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Open Data Center Alliance Participants is subject to the Open Data Center Alliance’s 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 of the limitation set forth herein.

Users of this document should not reference any initial or recommended methodology, metric, requirements, or other criteria that may be contained 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 certification to demonstrate compliance with, any of these Initial Models.

Any proposals or recommendations contained in this document including, without limitation, the scope and content of any proposed methodology, metric, requirements, or other criteria does not mean the Alliance will necessarily be required in the future to develop any certification or compliance or testing programs to verify any future implementation or compliance with such proposals or recommendations.

This document does not grant any user of this document any rights to use any of the Alliance’s Marks.

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

Published November, 2012

AcknowledgementsODCA would like to acknowledge the substantial contributions of content and prior art from the Enterprise Cloud Leadership Council of the TM Forum, CloudScaling and Atos.

Terminology and ProvenanceSome of the content of this document has been sourced with permission from work product outside the ODCA. Every effort has been made to reconcile terminology and nomenclature. Where this is a conflict, however, ODCA terms take precedence.

OPEN DATA CENTER ALLIANCESM Master USAGE MODEL:Compute Infrastructure as a Service REV 1.0


1.0 Executive SummaryGiven the broad range of cloud consumers and their compute infrastructure requirements, there is a wide spectrum of capabilities that service providers could offer to meet compute service needs, and ultimately to deliver excellent, cost-effective end user application usage experiences.

Clearly it is not possible for service providers to meet all possible permutations of demand and capabilities, particularly for edge cases where lack of scale or volume limit service providers’ ability to achieve economies of scale.

In order to meet the compute 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.

By 2014, the Open Data Center Alliance (ODCA) and its members would like to see a robust marketplace, with full coverage for all of the usage scenarios contemplated herein. Furthermore, most providers should offer service for at least half of the usage scenarios. This 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.

To date, the efforts of the ODCA have focused on the top concerns of service consumers and providers. The resulting original usage models focused on specific topics, such as measurement and identity management, among others. The purpose of this newest round of usage models is to continue to develop these specific focus topics and to provide a platform on which to bring the topics together in a more holistic manner. The master usage models will reference and support the previously published usage models.

This document serves a variety of audiences. Business decision makers looking for specific solutions and enterprise IT groups involved in planning, operations, and procurement will find this document useful. Solution providers and technology vendors will benefit from its content to better understand customer needs and tailor service and product offerings. Standards organizations will find the information helpful in defining end-user relevant and open standards.

2.0 PurposeThis document and its referenced supporting usage models describe the requirements for complete compute infrastructure as a service. There are aspects of this usage model where requirements are more stringent than found in popular public clouds today. It is important to understand that this document specifies enterprise requirements, sufficient to displace incumbent enterprise data centers. This common framework is required so that CIaaS services can be evaluated, acquired and disposed of by enterprises in a way that reflects the ODCA member firms’ vision of a robust and vibrant market by the end of 2014.

The IaaS area is quite broad and can be segmented into three different “as a service” offerings: compute, storage and network, each offered in a variety of usage models. While storage and network services areas are essential to the overall cloud services model, the foundation of cloud computing is fundamentally based on “compute as a service” capabilities. Thus, this document addresses the compute portion of IaaS in greater depth than storage and network areas. ODCA will address these other areas of IaaS in future work.



3.0 Taxonomy

Actor/Term Definition

Cloud-Aware Application Cloud-aware applications have been designed and built with the sole intent of running in a cloud environment.

Cloud Broker A cloud broker is an entity that manages the use, performance, and delivery of cloud services and negotiates relationships between cloud providers and cloud subscribers. In general, a cloud broker can provide services in three categories: Service Intermediation, Service Aggregation, and Service Arbitrage.1

Cloud Federation A concept of service aggregation characterized by interoperability features, addressing the economic problems of vendor lock-in and provider integration.2

Cloud Provider An organization providing cloud services and charging cloud subscribers. A cloud provider provides services over the Internet. A cloud subscriber could be its own cloud provider, such as for private clouds.

Cloud Standards Body An entity responsible for setting and maintaining the cloud orchestration standards contemplated in this usage model.

Cloud Subscriber A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud provider.

Maintenance Window A period of time designated in advance by the cloud provider, during which preventative maintenance is performed, that could otherwise cause disruption of service.3

Recovery Consistency Objective (RCO)

RCO defines a measurement for the consistency of distributed business data after a disaster or other business continuity event.6

Recovery Point Objective (RPO) The maximum tolerable period in which data might be lost from an IT service due to a major incident.4

Recovery Time Objective (RTO) The duration of time and a service level within which a business process must be restored after a disruption in order to avoid unacceptable consequences.5

Traditional Application A program or system that has not been specifically designed (or remediated) to transparently leverage the unique capabilities of cloud computing.

Workload A machine image or virtual machine instance, together with the needed information about the technical layout (e.g., number of cores, RAM), network configuration and the data store directly associated with the VM. The VM is the abstraction of all the workload’s constituent elements.

Table 3.1–Terms and Definitions

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

4.0 Defining CIaaSIn order to work to a common framework, we use the NIST definition for Infrastructure as a Service:

“Infrastructure as a Service (IaaS). The capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).” 7

We specifically position the work in this master usage model as a general-purpose cloud compute container, including the necessary supporting network and storage capabilities to make it useful. However, the emphasis of this usage model is on compute capabilities. As illustrated in the conceptual framework below, this foundation will allow us to consider separately higher-level IaaS, PaaS, and SaaS solutions higher up the stack. Also, while storage and network requirements are addressed in this document, distinct usage model requirements for storage as a service and network as a service will be addressed in the future.

Figure 4.0.1 - ODCA Conceptual Framework v1.0

Capacity &Performance

SW DeliveryOS and Apps

Configuration

Event

Security

Consume / Subscribe

Provide

Facility

Cloud Aware Apps

Web Database

PaaS

SaaS

Web & Data Service Interoperability

IaaS

Traditional & Cloud Aware Apps

Compute Storage Network

Power, Cooling, Physical Space

Actionable Service Catalog (UI and API)

Business Processes

Dynamic M

anagement & Orchestration

of End-to-End Services

End User

ApplicationDevelopment

IT Ops

The ODCA Conceptual Framework illustrated above shows that CIaaS services may be used for both “traditional” and “cloud-aware” applications. Indeed, this document includes sample usage scenarios for both types of applications. It is worth, however, first defining what we mean by cloud-aware and traditional applications.

•Cloud-Aware: Cloud-aware applications have been designed and built with the sole intent of running in a cloud environment. They are both free of the dependencies and assumptions which 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 are generally agreed to include the following8,9:

º 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 others, as the needs of the business or market change, with minimal impact to the business.

9



º Extensible: Applications are incrementally deployed and tested. That is, there is the 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

• Traditional: 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.

4.1 CIaaS ScopeCIaaS requires the following elements:

•Compute instance (may or may not be virtual, although virtual machines (VMs) are typical)

•CPU and memory resources

•Network components

•Storage

These will be deployed in different configurations to meet a range of service capabilities and attributes. We do not seek to define technical implementation in this usage model. Instead, we seek to define the capabilities required in common terms and measures.

Orch

estra

tion

Container

Server

Storage

Network

Orch

estra

tion

Container

Server

Storage

Network

Cloud Subscriber

Cloud Broker

Cloud Provider 2Cloud Provider 1 Cloud Provider 3

Orch

estra

tion

Container

Server

Storage

Network

Figure 4.1.1 - CIaaS in Context

10



4.2 CIaaS Workloads10

Generically, a workload is an encapsulation of the following:

•Application processes

•Data

•Configuration information

•State

This also includes metadata that describes the relationships among those elements. For Infrastructure as a Service (IaaS) services, the workload encapsulation is usually the virtual machine.

Best practices11 dictate that service descriptions and levels should be consistent in order to ensure transparency and to fairly compare/contrast cloud providers against each other. Additionally, billing models, etc. should be comparable across environments. These are key practical realizations of cloud interoperability. See also the ODCA Master Usage Model:Commercial Framework 12, and ODCA Usage Model:Regulatory Framework 13 for more on this broad topic.

4.3 Deployment ModelsUnless specified otherwise, the requirements described in this document are assumed to apply to all potential cloud deployment and procurement models:

11


Table 4.3.1 Cloud Models

Model Definition

Private Cloud The cloud infrastructure is operated solely for an organization (cloud subscriber). It may be managed by that organization itself (an Enterprise Internal Private Cloud) or a third party and may exist on premise (Managed Internal Private Cloud) or off premise (Managed External Private Cloud). (based on NIST definition11)

Community Cloud The cloud infrastructure is shared by several organizations and supports a specific community or industry vertical that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It may be managed by the organizations or a third party and may exist on premise or off premise. Members may have similar or correlated utilization profiles. (based on NIST definition)

Sector Cloud Demand may be highly correlated among the members of a community cloud, undermining its economics. Thus, a Sector Cloud is a multi-industry community cloud where peaks and troughs in demand may be smoothed out, allowing for greater optimization opportunities.14

Public Cloud The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services. (based on NIST definition)

Hybrid Cloud The cloud infrastructure is a composition of two or more clouds that remain unique entities but are bound together by technology that enables data and application portability (e.g., cloud bursting for load-balancing between clouds). (based on NIST definition)

Cloud Marketplace Professional exchanges of cloud services by members (cloud providers and cloud subscribers) who agree on common rules, along with being certified and audited by third-party cloud auditors to ensure consistency and quality.

http://www.opendatacenteralliance.org/docs/ODCA_Commercial_Framework_MasterUM_v1.0_Nov2012.pdfhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=455:regulatory_frameworkhttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=455:regulatory_framework



4.4 CIaaS Service AttributesA compute IaaS offering will be defined using the service assurance attributes below, most of them as per the ODCA Usage Model: Standard Units of Measure for IaaS.15 We additionally include two further terms, functionality and interoperability.

•Availability: The degree of uptime for the solution, such as taking into account contention probabilities.

•Performance: The extent to which the solution is assured to deliver a level of output.

•Recoverability: The solution’s recovery point and recovery time objectives.

•Security: The extent of the solution’s protection (e.g., encryption, tripwires, virtual local area network or VLAN, port filters, etc.).

•Manageability: The degree of automation and control available for managing the solution.

•Client SLA priority: The service contention design for handling peak demand.

• Functionality: The essential services provided by the cloud provider to the cloud subscriber.

• Interoperability: The degree to which a cloud subscriber can do all of the following16,17:

º Migrate workloads from one cloud to another (including across cloud providers).

º Link disparate clouds.

º Compare cloud providers based on cost and capabilities.

º Utilize consistent management interfaces.

The service attributes can be described in terms of multiple service tiers. Specifically, each of these attributes can be defined at the bronze, silver, gold and platinum service levels, described in the table below. The intent of this master usage model is that service tiers can be mixed and matched across the different service attributes, but not within them. That is, it is possible to have a cloud service with bronze availability but gold performance. However, all of the elements that comprise a given attribute’s service tier must be met. For example, all of the sub-requirements for gold performance must be met for it to be deemed gold-level service tier for performance (see section 7.0 Service Tier Details).

Service Tier Positioning Description

Bronze Basic Representing the lower-end corporate requirement, possibly equating to a reasonably high level for a small to medium business customer

Silver Enterprise Equivalent Representing higher quality than bronze, and a trade-off with higher costs, within the SLA range

Gold Critical market or business sector equivalent

Representing a preference for a further higher quality of service within the SLA range.

Platinum Military or safety-critical equivalent

Representing the maximum contemplated corporate requirement, stretching towards the lower end of military or safety-critical needs

Table 4.4.1 Service Tier Attributes

It is assumed that lower service tiers correspond with lower cloud provider pricing.

The service levels are specifically defined using qualitative and quantitative measures aligned with the ODCA Usage Model: Standard Units of Measure for IaaS.15 Note: service levels for “Interoperability” are defined in the ODCA Usage Model: Guide to Interoperability Across Clouds,17 and CIaaS “functionality” is defined here for the first time.

Given the broad range of CIaaS requirements and capabilities, a good way to understand specific service attributes for CIaaS is to use examples. These are introduced in a subsequent section.

http://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=458:standard_units_of_measurehttp://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measurehttp://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0_BD.pdf



4.5 General CapabilitiesCIaaS must include the following general management and operational capabilities as also highlighted by the TM Forum’s Enterprise Cloud Leadership Council.18 ODCA has extended these requirements to enhance security and fit within the enterprise.

IT Operations Management:

Note: Item 4 below is an ODCA requirement, beyond those of the TM Forum.

1. The service must support a wide range of x86-based operating systems, including Windows (server and desktop OS), Solaris x64 and Linux (leading distributions) in 32-bit and 64-bit versions.

2. The service must support network isolation controls for inbound and outbound traffic.

3. The service must support the deployment of Web, Application, Database and Infrastructure Service components, such as LDAP components.

4. Alignment with Information Technology Infrastructure Library (ITIL) processes for change, incident and configuration management

Network Management:

1. The service provider must provide options for consumer network connectivity, such as internet VPN, and leased lines. In addition, the service provider must articulate any other network requirements, stipulations and constraints, such as NAT, IP address overlays, and latency controls.

2. The service must include instrumentation to provide the consumer with a view of bandwidth, performance, and latency. These should be available via the service interfaces (including the service portal user interface and the API).

Security Management:

Note: Items 3 through 5 below are ODCA requirements, beyond those of the TM Forum.

1. The service provider must provide architectural, design, policy and other artifacts that demonstrate the degree to which the cloud subscriber’s service is being segregated from other subscribers. This applies to single-tenant and multi-tenant cloud services.

2. The cloud provider must formally and explicitly affirm that the storage, network, and processing security meet the requirements of the cloud subscriber’s contracted tier (bronze, silver, gold, or platinum). Additionally, the cloud provider must support independent verification.

3. The subscriber must adhere to the security policies and procedures implemented by the provider in order to comply with the actual assurance level of the cloud.

4. In a managed cloud environment, certain software used by the subscriber within the cloud should integrate with the monitoring tools provided in the cloud that ensure the cloud’s integrity. This includes such software for intrusion detection and prevention, thresholds on access logs, and so on.

5. Application monitoring is under control of the subscriber and can run locally in the cloud as well as be connected to the subscriber’s monitoring infrastructure. Application level security monitoring is the subscriber’s responsibility (Note: in higher-value service types an application firewall might be part of the provider’s offering).

Workload Management:


1. The service must provide volume flexibility, and allow the consumer to dial up or down the resources being consumed.

2. The service must be capable of integrating with the consumer cloud management tools programmatically and through standard APIs.

3. The service should allow the consumer to change workload policy rules and parameters at will within specific criteria.

4. The service must provide a cloud service management portal.

http://www.opendatacenteralliance.org/docs/tmforum_tr174enterprisegrade_computeiaasrequirements.pdfhttp://www.opendatacenteralliance.org/docs/tmforum_tr174enterprisegrade_computeiaasrequirements.pdf



Compliance Management:

1. The provider must agree and adhere to, and permit enforcement of governing frameworks and policies, internal and external audits, minimum standards/certifications and consequence management. Lack of controls may subject providers to penalties.

2. There may be technical and procedural requirements based on the cloud subscriber’s industry or country in which they operate or have customers. This may also include requirements such as data that must stay within the country of origin, or regular, prescriptive disaster recovery testing. The cloud subscriber may be required to provide evidence of compliance, and thus may need the provider’s assistance to produce that.

Problem Management:

1. Each party must have established an effective root cause analysis of incidents related to contracted or consumed services to prevent recurrence of negative service impacts.

Service Continuity Management:


1. Each party must have effective processes to ensure that IT services can recover and continue even after a serious incident occurs. This will also include the business continuity of material suppliers.

2. The cloud provider must ensure that a third party cloud subscriber cannot impact the cloud subscriber, such as in “noisy neighbor” situations.

Vulnerability Management:


1. The cloud provider must establish a regular practice of identifying, classifying, remediating, and mitigating vulnerabilities, including patch management. Furthermore, the provider must notify the cloud subscriber of any actions or incidents, known or suspected, that may risk the cloud subscriber’s assets or data via the provider’s service.

2. The cloud provider works closely with its ISPs and with regional and international security organizations in order to prevent Internet driven attacks against its clients or its infrastructure. The provider has a risk response team and a security operations team that is trained to respond quickly to attacks, and to preserve their clients from being impacted. Furthermore, for the gold and platinum services, DOS and DDOS attacks are contained by filtering the attacking servers as early as possible on the ISP’s infrastructure.

3. For service tiers silver, gold and platinum, the subscriber has a vulnerability management system in place and applies security patches in a timely manner, as defined in the ODCA Usage Model: Provider Assurance.19

4. For service tiers gold and platinum, the subscriber performs analysis of its access and application logs and communicates identified patterns to the provider, in order to improve the accuracy of the provider’s filters.

Monitoring Service:

Note: Item 2 is an ODCA requirement, beyond those of the TM Forum.

1. The cloud provider must monitor the environment, including event, capacity, security and utilization, to ensure SLAs are met. The provider’s monitoring data must be provided over standardized APIs.

2. If application layer monitoring and analytics point to the infrastructure, then the infrastructure metrics should be easily accessible and available for root cause analysis, troubleshooting, and to provide early warnings of issues that may be preventable.

Incident Management:


1. Each party must inform the other of incidents that may affect the other. Pre-defined agreements must be established on prioritization of an incident and level of effort required by the cloud provider during an incident. Automated and standardized

http://www.opendatacenteralliance.org/docs/Security_Provider_Assurance_Rev%201.1_b.pdf



interfaces are to be established to manage incidents.

2. Note that incidents to be communicated also include those where the cloud subscriber must inform the cloud provider of incidents that may affect other third-party subscribers.

3. For major incidents, as agreed in a contract between the provider and the subscriber, the cloud provider must notify the affected customers within 48 hours.

4. Incident responses must be agreed between both parties in order to make them as effective as possible. Coordinated activities help prevent service degradation by avoiding conflicting actions.

Change Management:

1. Each party will notify the other when a change in configuration or other operational aspect may affect the service capabilities of the other party. Proactive management is required to ensure a stable environment.

Governance:

Note: Items 2 and 3 below are ODCA requirements, beyond those of the TM Forum.

1. The provider must adhere to and permit enforcement of governing frameworks and policies, internal and external audits, minimum standards and certifications, and security controls. Penalties and termination of contracts may be established where requirements are not met.

2. For gold and platinum service tiers, the contract between the subscriber and the provider will typically stipulate geographic or jurisdictional limitations where the subscriber’s data can be stored and processed, including secondary site and backup tapes location.

3. For gold and platinum tiers, the provider must notify the subscriber of the parent company or legal jurisdiction if they have a US parent company governed by the US PATRIOT Act.

Provisioning of Services:

1. Provider must have effective automated mechanisms to request, provision, manage, and meter usage of services wherever possible.

4.6 CIaaS Key Performance IndicatorsA key performance indicator (KPI) is an IT term of art for a type of performance measurement. A very common way of choosing KPIs is to apply a management framework (for example, the balanced scorecard), and consolidate a number of SLA perspectives and metrics into a smaller set of overall indicators. Some KPI types include:20

•Quantitative indicators; potentially anything numeric and relevant to business objectives and service contract.

• Practical indicators that interface or align with enterprise processes.

•Directional indicators specifying whether a service or an organization is improving or not.

•Actionable indicators are those which are sufficiently in an organization’s control in order to affect change.

• Financial indicators that could include spend, savings, service credits for SLA failure, etc.

Key performance indicators, in practical terms and for strategic development, are objectives to be targeted that will add the most value to the business.

KPI Principles:

•KPIs should define specific and unambiguous measure titles or labels.

• The parameters of the KPI help constitute the SLA.

•KPIs have a high and low water mark, against which SLAs are set.



•KPIs can have multiple dimensions, some of which are shared, such as:

º Cloud subscriber view to gauge quality of service.

º Cloud provider view to manage overall services.

º Shared view on some items.

The key performance indicators for CIaaS correspond closely with the service attributes. They are defined in order to provide an effective way to measure the service. They are also important to cloud subscribers when making services purchases, and to cloud providers when benchmarking their services. KPIs should focus on a small number of core and meaningful statistics that are cost-effective and useful.

KPIs associated with the Service Attributes

These are the KPIs that will be used on a day-to-day basis by the cloud subscriber to ensure that the service is being delivered to requirements, and to track deviations from the norm. These can be easily described using the elements and desired service tiers in the “Service Attributes” and “Commercial Considerations” sections of this document. However, the major KPI themes include:21

• Provisioned and contracted capacity

•Capacity usage and utilization

• Performance parameters

• Invocations of defined automated actions

•Service availability

•Supported service tiers (bronze, silver, gold and platinum)

•Service Continuity parameters (RTO, RPO, RCO)

•Data classification and retention metrics

•Security controls

•Defined reports and auditing metrics

Example

KPI: Service is available as expected

May Include:• System Uptime• Network Uptime• Storage Uptime• Incident Response Time

Low Water Mark: Minimum acceptable level

High Water Mark: Target achievement

Actual AchievementAggregated SLA Committed

Suggested Additional Business Value KPIs for Cloud Subscribers

Cloud subscribers should consider developing internal KPIs which can be used to gauge the value derived by their business from adoption of CIaaS. These are optional, but may include:22

•Metrics measuring performance of the service against the strategic business and IT plans.

•Metrics on risks and compliance against regulatory, security, and corporate governance requirements for the service.

•Metrics measuring financial contributions of the service to the business.



5.0 InteroperabilityInteroperability is concerned with portability of workloads, interconnectivity of clouds, and the ability to integrate systems. Interoperability is important to cloud subscribers because it helps avoid provider lock-in while ensuring flexibility for the subscriber. It allows compute service decisions to be less tightly coupled with business priorities. Interoperability is also important to cloud providers because it can help prevent disqualification by potential customers fearing lock-in.

As discussed in the ODCA Usage Model: Guide to Interoperability Across Clouds17, there are two key aspects of interoperability: portability of workloads and interconnectability of systems. Each of these aspects comes with its own set of unique requirements.

•Portability is required to be triggered as needed, as an event, including maintaining access to data and control over the workload, and allowing dynamic configuration and reconfiguration.

• Interconnectability addresses the need for applications and services to establish and preserve, on an ongoing basis, complex connections that occur between different systems. Consistent manageability across the connected clouds is implicitly included.

6.0 Business Drivers and usage scenariosThe purpose of this master usage model is not to define in detail what the service providers deliver in terms of precise technical architecture. Some consumers want providers to provide “enterprise” grade infrastructure, meaning compute infrastructure that can replace internal enterprise-provided and managed infrastructure, and can be used interchangeably. However, the real benefits and economies from the cloud model stem from approaches where applications are designed and built from the ground up to take advantage of the commodity common services available from multiple providers. There are two approaches to consider: should the cloud adapt to legacy enterprise requirements, as in the case of traditional applications, or should the enterprise adapt to the cloud, such as with cloud-aware applications?

The answer is both. Large enterprises have correspondingly large application portfolios, many of which have been designed and implemented within traditional distributed computing environments. These enterprises have neither the desire nor economic justification to refactor their entire application estate to optimally leverage the cloud delivery model. Over time, it can be expected that enterprises will adapt to the cloud delivery model. However, this will be an extended journey. There is an opportunity for service providers to deliver a wide range of service levels and capabilities - ranging from high grade “enterprise class” compute infrastructure through to fully commoditized capacity.

Ensuring service providers deliver environments, services, and associated tools that enable enterprises to operate effectively and efficiently across these hybrid environments will be key as cloud computing penetration increases, while enterprise also continues to make the most of investments they already have in place.

6.1 Business USAGE ScenariosIn this section, we propose some example business usage scenarios for deployment to Compute IaaS. For each one, we characterize the general service attributes of the usage scenarios. These general attributes are elaborated into detailed elements elsewhere in this document. See the “Technical Architecture” and “Service Tiers” sections for more detail.

The usage scenarios contemplated herein are not intended to be comprehensive. They are, rather, intended to be representative of the kinds of business problems for which CIaaS services are suitable. There are innumerable other potential combinations of requirements. The CIaaS framework put forth by this master usage model should allow the reader to describe other usage scenarios in a similar manner.

Suggested Additional Relationship KPIs for Cloud Providers

Below are some suggested KPIs cloud providers should track to ensure customer satisfaction and to benchmark services against their peers.22 If possible, cloud providers should maintain an open and ongoing dialogue with their enterprise cloud subscribers regarding the above “business value” KPIs as well. These are optional, but may include:

•Metrics monitoring the key IT processes supporting the service.

•Metrics measuring customer satisfaction.

http://www.opendatacenteralliance.org/docs/ODCA_Interop_Across_Clouds_Guide_Rev1.0_BD.pdf



Figure 6.1.1 - Sample CIaaS Usage Scenarios

CIaaS Usage

Scenarios

Production Non-Production

Strategic Dev Ad HocDev / Test QABase Variable

Standalone Enterprise EnterpriseGrid

Traditional Cloud-Aware

Dev / Test LoadTesting

Traditional Cloud-Aware

Hybrid cloud environments will also be around for a while. There is a requirement for IT operations professionals to be able to manage, measure and report on systems running behind the firewall in a manner consistent and compatible with those in the cloud, traditional or cloud-aware. Industry can and should provide this ability for cloud subscribers operating in hybrid environments.

Note that the usage scenarios below do not differentiate between internal or employee-facing scenarios vs. external or client/public-facing. However, it is reasonable to assume that where multiple attributes service tiers are indicated, public and client-facing requirements will often exceed those of internal and employee-facing scenarios. Business criticality is also indicated for each example.

Most of the usage scenarios below cite and expand on scenarios previously documented by the TM Forum’s Enterprise Cloud Leadership Council (ECLC).

For the production usage scenarios below, Client SLA priority was derived using the following scenario assumptions:

• For high priority events and requests, as agreed between cloud subscriber and cloud provider

• Time to respond: bronze, 4 hours; silver, 1 hour; gold, 10 minutes; platinum, immediate/instant.

Below is a simple diagram illustrating the hierarchy of usage scenarios described in this usage model. Traditional and cloud-aware applications are described elsewhere.


6.2 Development/TestThis is a subclass of non-production CIaaS use. For this example, we are assuming traditional, or non-cloud-aware, workloads. The ECLC description follows:

This is one of the most accessible and obvious usage scenarios for CIaaS, as development and test environments are typically temporary and disposable. By adopting CIaaS for development and test, environments are more easily segregated –or logically isolated –from production, helping to eliminate interdependencies and negative consequences from inadvertent interaction with production systems.These environments may also be provisioned and deployed much more rapidly than would be feasible with physical systems, allowing for improvements in business agility and time to market.

Requirements for development and test on the cloud can be further subdivided into three sub-cases: Strategic Development, Ad Hoc Development and Test, and Quality Assurance.

•Strategic Development: Major, long-term software development efforts core to the cloud subscriber’s business.

•Ad Hoc Development and Test: Informal, short term or experimental software development that is not core to the cloud subscriber’s business.

•Quality Assurance: Formal testing of software by cloud subscriber as part of quality assurance, systems integration or other similar formal testing of software that is core to the cloud subscriber’s business. This will necessitate greater resilience and performance consistency from the cloud service.

Table 6.2.1 – Requirements for Development and Test

19


Requirement(O-Optional, M-Mandatory)

Strategic Development Ad Hoc Dev / Test Quality Assurance

Business Criticality Low or Medium Low Low or Medium

Service Attribute Tier Tier Tier

Availability Bronze or Silver Bronze Bronze or Silver

Performance Bronze Bronze Bronze or Silver

Recoverability Bronze or Silver Bronze Bronze or Silver

Security Silver or Gold Silver Silver or Gold

Elasticity Bronze Bronze Bronze

Manageability Silver Bronze or Silver Silver

Client SLA priority Bronze Bronze Bronze

Interoperability Silver Bronze Silver


6.3 Load Stress Test EnvironmentThis is also a subclass of non-production CIaaS use. For this example, we are assuming traditional, or non-cloud-aware, workloads. From the ECLC description of the usage scenario with the same name:

“This usage scenario is emerging as a key enabler for online businesses and other businesses that require massive scaling. As an extension of development and test, load testing is a specialized domain that can be used to detect algorithmic weaknesses that only surface at scale. While an application may run as expected as a singleton or as part of a small cluster, doubling or exponentially increasing the number of processing nodes may yield unexpected results. CIaaS allows a developer to simulate this scaling using a shared internal or external resource, eliminating the capital outlay that would be required to provision capacity for hypothetical load levels. Additionally, client-server systems may benefit from the cloud by leveraging CIaaS capacity to simulate large numbers of clients to drive load against servers.”

Additionally, there are now means for test scripts to reflect real user patterns of transactions that occur concurrently and stress the underlying IaaS services in differing ways. Load stress tests should incorporate real user usage patterns from real user monitoring systems to implement these tests.

Table 6.3.1 – Load Stress Test

20



Load Stress Test

Business Criticality Low

Service Attribute Tier

Availability Bronze

Performance Gold (fidelity with the target production environment is a key consideration)

Recoverability Bronze

Security Bronze or Silver

Elasticity Silver or Gold

Manageability Silver

Client SLA priority Bronze

Interoperability Bronze



6.4 Grid and High-Performance ComputingGrid and high-performance computing (HPC) applications may be either traditional or cloud-aware. Due to their inherent parallel distributed compute pattern, grid applications are often natural good fits for cloud architectures. For this example, we are assuming the grid application is cloud-aware. However, a traditional, non-cloud-aware grid system should not have substantively different requirements.

From the ECLC description for Grid computing applications:

“While Grid computing predates cloud computing, the cloud can be used to optimize Grid-based usage models. Whereas a classic compute Grid was traditionally housed in a static farm of physical compute servers, CIaaS offers dynamic capacity management, allowing the logical Grid to expand and contract based on the business demand and marginal benefit or cost to enabling additional parallel processing nodes.”

Requirements for grid and high performance computing in the cloud can be further subdivided into two sub-cases: base grid capacity and variable grid.

Table 6.4.1 – Requirements for Grid and High Performance Computing


Base Grid Capacity Variable Grid Capacity

Business Criticality High Medium or High

Service Attribute Tier Tier

Availability Gold or Platinum Bronze

Performance* Bronze to Gold Bronze to Gold

Recoverability Bronze Bronze

Security Gold or Platinum Gold or Platinum

Elasticity Bronze Gold or Platinum

Manageability Silver Silver

Client SLA priority Gold or Platinum Bronze

Interoperability Silver or Gold Silver or Gold

Additional assumptions:

In both usage scenario subtypes above, we explicitly assume that the operating model has the cloud subscriber doing their own management and support from the operating system up.

Both usage scenario subtypes assume production enterprise workloads.

*Note that performance may go as low as bronze for low-cost economy grids, depending upon cloud subscriber requirements and price sensitivity.



6.5 Standalone Traditional Production EnvironmentThis may be thought of as monolithic deployment. It is a subtype of traditional or legacy workloads, migrated over to the cloud. For example, a team or departmental production application that is important, but not critical, to day-to-day business operations. The ECLC description for standalone production is appropriate:

“Applications with minimal external dependencies can run more or less isolated from the corporate environment. While a bridge solution may be required to integrate with identity or other directory services, or to connect into other business workflows, these applications may function equally well in any location. These types of applications may be well-suited for deployment in a CIaaS environment, allowing them to benefit from migration or extension to other geographies in support of cost or productivity (follow-the-moon/follow-the-sun).”

This is a specific type of production requirement. However, as with other enterprise-production scenarios, the service in this case is deemed mission critical. Loss of the compute service will have material negative impacts on the cloud subscriber, such as significant loss of revenue or reputational damage.

Standalone production environments are intended to cover group and departmental applications that are considered production for the purposes of support and recovery, but have a limited impact to the business. Examples of these are internal file servers, web servers, and collaboration sites. Loss of these services is considered an inconvenience rather than a disruption to business operations, and manual workarounds, while feasible, might be undesirable.

Table 6.5.1 – Standalone Cloud-Enabled Production


Standalone Cloud-Enabled Production

Business Criticality Low - Medium


Availability Silver or higher

Performance Silver or higher

Recoverability Silver or higher

Security Silver or higher

Elasticity Bronze

Manageability Silver

Client SLA priority Silver



6.6 Enterprise Traditional Production Environment This is usually legacy distributed compute systems which have been migrated to the cloud, but not been fully remediated to be cloud-aware. This is a subclass of production use.

Enterprise applications differ from standalone production applications in their scope and importance to an organization. These are mission critical applications that affect the reputation and revenue stream of an organization. Loss of the enterprise production environment would result in significant loss of revenue and/or damage to the reputation of the subscriber. Examples of this are high volume transaction systems (ERP), customer facing web sites, partner integration sites and financial data processing systems where manual processing options are not feasible due to the volume or nature of the transactions.

These applications have external dependencies and integration requirements. Bridging solutions may be required to integrate with identity or other directory services, or to connect into other business workflows. They may not be able to fully exploit cloud elasticity. Compared to “standalone” applications, these are larger and more complex and may not be well-suited for migration from one geographic location to another due to the size or volume of data required.

Table 6.6.1 – Enterprise Traditional Production


Enterprise Traditional Production

Business Criticality Medium – High


Availability Gold or Platinum

Performance Gold or Platinum

Recoverability Gold or Platinum

Security Gold or Platinum

Elasticity Bronze or Silver

Manageability Gold

Client SLA priority Gold or Platinum

Interoperability Silver or Gold



6.7 Enterprise Cloud-Aware Production Environment This may be thought of as compute systems that, although not fully PaaS-based, have been architected for the cloud from the outset. Such systems may include newer web-style applications, exploit higher automation, and can query the infrastructure server about available capacity, services, and so on. This is a subclass of production use.

Infrastructure-aware applications are newer applications built to tolerate failure of underlying infrastructure components. These applications make use of services provided by the infrastructure providers to recover from component outages or scale as needed to support application workload demands. As with the traditional distributed computing variant, loss of the production application would result in significant loss of revenue and/or reputational damage to the subscriber. The difference is that the application is architecture to run on infrastructure with a lower level of service, reliability and availability. These applications may also be distributed across the resources of multiple providers.

These applications have internal/external dependencies and integration requirements.

Table 6.7.1 – Enterprise Cloud-Aware Production


Enterprise Cloud-Aware Production

Business Criticality Medium or High


Availability Silver or higher

Performance Bronze or higher

Recoverability Gold or Platinum

Security Gold or Platinum

Elasticity Gold or Platinum

Manageability Gold or Platinum

Client SLA priority Gold or Platinum

Interoperability Gold or Platinum

6.8 Cloud Brokering and FederationCloud brokering and cloud federation services are an important part of the cloud ecosystem, and will be addressed in a future update to the ODCA Master Usage Model: Compute Infrastructure as a Service (CIaaS).

http://www.opendatacenteralliance.org/docs/ODCA_Compute_IaaS_MasterUM_v1.0_Nov2012.pdf



7.2.1 Service Tier Summary: AvailabilityElements Bronze Silver Gold Platinum

Overall availability 99% 99.9% 99.9% 99.99%

Maintenance windows Fixed Fixed Flexible Flexible

Permissible unplanned outage frequency* 2 1 0 0

Per-incident RTO** 60 min 30 min 0 min 0 min

Target cumulative unplanned outage duration 120 min 30 min 0 min 0 min

Permissible unplanned internet connectivity disruptions* 3 2 0 or 1 0

Penalty for SLA breach None Yes Yes Yes

* Number of outages within a specified time window aligned with billing periods. Any penalty credits will be applied to the corresponding billing cycle. The intent here is to address transient or intermittent behavior where disruptions or outages are very brief but may materially impact workload performance and/or service quality.

** Total time duration per outage incident

7.0 Service Attribute DetailsEach of the service attributes introduced above is explained in further detail below. Each attribute is subdivided into one or more elements. Together the values for the elements determine that attribute’s service tier. All of the elements that comprise a given attribute’s service tier must be met. For example, all of the sub-requirements for gold performance must be met for it to be deemed gold-level service tier for performance. The following assumptions apply for each service attribute section below:

Standardization: Services from cloud provider are standardized and consistent.

Documentation is available.

7.1 functionalityThe infrastructure must support basic functional cloud services, as defined by NIST. The provider should support at least version n-1 of the latest version of current and future cloud service standards where specified herein or delivered in response to ODCA requirements by SDOs.

7.2 AVAILABILITYIn the ODCA Usage Model: Standard Units of Measure for IaaS,15 ODCA has defined availability as the degree of uptime for the solution, such as taking into account contention probabilities.This should be construed as the overall service as a whole. There are certain general aspects that availability of CIaaS must address. The scope of CIaaS availability includes:

•Overall availability number -- for example, the number of nines.

•Connection from the POPs (point of presences) or internet connection points of the provider.

•How maintenance windows are defined-- for example, fixed--chosen by cloud provider, or flexibly--chosen by cloud subscriber.

• The possibility to define “critical time windows” would be available in the flexible versions.

•Note that contractually agreed planned maintenance windows do not count against availability targets.

• Target outage duration vs. number of outages-- Some workloads can better deal with short outages, even if there are many of them. Others need to have as few as possible, allowing longer downtime for each of them.

• Existence of contractually-specified penalties imposed for breach of SLA, as in the table below.

http://www.opendatacenteralliance.org/document-sections/category/71-docs?download=458:standard_units_of_measure



7.3 RecoverabilityODCA has defined recoverability as the solution’s recovery point and recovery time objectives.15 This should be construed for the recovery of the overall service as a whole. There are certain general aspects that recoverability of CIaaS must address. The scope of CIaaS recoverability includes:

•Backup and restore with or without incremental revisions

•Mean time to recovery

•Number or frequency of recovery points

7.3.1 Service Tier Summary: Recoverability

Elements(O-Optional, M-Mandatory)

Bronze Silver Gold Platinum

Data Backup No backup One copy Two copies Three copies

Geographic dispersion of data backups

None One site Two sites Three sites, and off-site

RTO for data restoration N/A Within 12 hours of service restoration

Within nine hours of service restoration

Within six hours of service restoration

Data Replication None None Snapshot, at least four times daily

Synchronous and Async to remote sites

Backup frequency N/A Weekly full Daily incremental, weekly full

Daily full

RTO for compute instance restoration

Subscriber responsibility

60 minutes 15 minutes 10 minutes

RCO for distributed data None 80% 90% 100%



7.4 SecurityODCA has defined security as the extent of the cloud solution’s or cloud provider’s protection. Below are the detailed security elements that must be addressed:

•Antivirus and malware protection (with definition updates within 24 hours)

• Vulnerability management process exists and is fully tested to ensure no impact to target hosts

•Network and firewall isolation of cloud subscriber systems

• Physical access control into cloud data center

•Secure protocols used for remote administration (for example, SSL,SSH, and RDP)

•All default passwords and guest access removed

•Use of non-disclosure agreements (NDAs) for cloud provider staff

•Use of Information Technology Infrastructure Library (ITIL) processes for change, incident and configuration management

• Identity management for subscriber assets

•Data retention and deletion managed

•Security incident and event monitoring

•Network intrusion prevention

• Event logging for all administration-level events (requires controlled access to logs)

• Four-eye principle for key administrator changes

•Cloud provider has an implemented and tested technical continuity plan

• Fully documented and controlled network

•Option to perform penetration testing on hosted systems

• Physical segmentation of hardware (server, storage, network, etc.) to ensure isolation from all other systems

• Encrypted communication between cloud provider and cloud subscriber for management

•Multi-factor authentication

•Ability for cloud subscriber to define geographic limits for hosting

•Storage encryption at logical unit number (LUN) level

•No administrative access for cloud provider staff

•Strong encryption for all data in-flight and at rest



7.4.1 Service Tier Summary - Security

Elements (O-Optional, M-Mandatory) Bronze Silver Gold Platinum

Antivirus and malware protection, with definition updates within 24 hours M M M M

Vulnerability management process exists and is fully tested to ensure no impact to target hosts

M M M M

Network and firewall isolation of cloud subscriber systems M M M M

Physical access control into cloud data center M M M M

Secure protocols used for remote administration (for example, SSL,SSH, and RDP) M M M M

All default passwords and guest access removed M M M M

Use of non-disclosure agreements (NDAs) for cloud provider staff M M M M

Use of Information Technology Infrastructure Library (ITIL) processes for change, incident and configuration management

M M M M

Identity management for subscriber assets (Refer to ODCA Usage Model: Identity Management Interoperability Guide)

M M M M

Data retention and deletion managed M M M M

Security incident and event monitoring M M M M

Network intrusion prevention O M M M

Event logging for all administration-level events (requires controlled access to logs) O M M M

Four-eye principle for key administrator changes O M M M

Cloud provider has an implemented and tested technical continuity plan O M M M

Fully documented and controlled network O M M M

Option to perform penetration testing on hosted systems O O M M

Physical segmentation of hardware (server, storage, network, etc.) to ensure isolation from all other systems

O O M M

Encrypted communication between cloud provider and cloud subscriber for management O O M M

Multi-factor authentication for the cloud to provider’s administrative access M M M M

Offer the capability for multi-factor authentication for the cloud to subscriber’s administrative access

O O M M

Ability for cloud subscriber to define geographic limits for hosting O O M M

Storage encryption at logical unit number (LUN) level O O M M

No administrative access for cloud to provider’s staff O O O M

Strong encryption for all data in-flight and at rest O O O M

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_final



7.5 ElasticityODCA defines elasticity as the configurability and expandability of the solution (consistent with NIST taxonomy7,23). Centrally, it is the ability to scale up and scale down capacity based on subscriber workload. There are certain general aspects that elasticity of CIaaS must address.

The scope of CIaaS elasticity includes:

•Ability to scale both up and down

• The definition of one or more policies that control how the cloud subscriber’s application should be scaled

•Responsiveness, such as speed of dynamic scaling

•Configuration of clones

•Configuration of environment such as network and security elements

• Execution of additional tasks on trigger

•

OPEN DATA CENTER ALLIANCE SM Master Usage Model ......This “Open Data Center AllianceSM Master Usage Model: Compute Infrastructure as a Service” is proprietary to the Open Data

Documents