Compute Infrastructure as a Service: Recommendations from the Open Data Center Alliance SM and TM Forum A joint perspective on the requirements of

Transcription

1 Compute Infrastructure as a Service: Recommendations from the Open Data Center Alliance SM and TM Forum A joint perspective on the requirements of the enterprise consumer

2 Legal Notice This CIaaS: Recommendations from the ODCA SM and TM Forum is proprietary to both the Open Data Center Alliance, Inc. and the TeleManagement Forum (TM Forum). NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS AND NON-MEMBERS OF THE TM FORUM: Non-Open Data Center Alliance Participants and non-members of the TM Forum only have the right to review, and make reference or cite this document. Any such references or citations to this document must give joint credit to the Open Data Center Alliance, Inc. and the TM Forum and must acknowledge the Open Data Center Alliance, Inc. s and TM Forum s joint 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 ALLIANCE SM, ODCA SM, 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 Notice This material, including documents, code and models, has been through review cycles; however, due to the inherent complexity in the design and implementation of software and systems, no liability is accepted for any errors or omissions or for consequences of any use made of this material. Under no circumstances will the TM Forum be liable for direct or indirect damages or any costs or losses resulting from the use of this specification. The risk of designing and implementing products in accordance with this specification is borne solely by the user of this specification. This material bears the copyright of TM Forum and its use by members and non-members of TM Forum is governed by all of the terms and conditions of the Intellectual Property Rights Policy of the TM Forum ( and may involve a claim of patent rights by one or more TM Forum members or by non-members of TM Forum. Direct inquiries to the TM Forum office: 240 Headquarters Plaza East Tower 10th Floor Morristown, NJ USA Tel No Fax No TM Forum Web Page: 2

3 Compute Infrastructure as a Service: Recommendations from the Open Data Center Alliance SM and TM Forum A joint perspective on the requirements of the enterprise consumer Executive Summary This statement on requirements for Compute Infrastructure as a Service (CIaaS) merges recommendations from the TM Forum s Enterprise Cloud Leadership Council (ECLC) and the Open Data Center Alliance (ODCA). It identifies requirements for enterprise-grade CIaaS, and provides suggestions about how CIaaS services can be evaluated, acquired and disposed of in a way that reflects both TM Forum s Enterprise Cloud Leadership Council s and ODCA s visions of a robust and vibrant market by the end of The joint aim of the ECLC and ODCA is a common set of principles, as well as metrics and architectural frameworks for consistent capabilities, which includes service levels and service attributes across multiple providers, while still allowing individual providers to innovate and differentiate. Below is some of what you will find in the main ECLC and ODCA documents. The ODCA Master Usage Model: Compute Infrastructure as a Service (CIaaS) 1 describes the requirements for complete compute infrastructure as a service. This document addresses enterprise requirements, such as service attributes, usage scenarios, cloud lifecycle, services orchestration, technical architecture, security, operations, management and more. The ODCA Master Usage Model: Compute Infrastructure as a Service (CIaaS) 1 will enable subsequent requirements elaboration on higherlevel IaaS, PaaS, and SaaS solutions. The ODCA master usage model approach further develops discrete cloud topics that were addressed in focused usage models and brings these topics together in a more holistic manner. The TM Forum s Enterprise Cloud Leadership Council s Technical Report 2 excerpts of which are in this joint publication--describes the requirements for enterprise-grade external Compute IaaS from the perspective of the enterprise consumer, which has many similarities to ODCA s approach. It proposes common terminology to help reduce semantic arguments over meanings of words, and explores requirements in commercial, technical and operational categories. It includes background information about the cloud business case as well as sample use. The TM Forum s ECLC Technical Report 2 outlines the key requirements that differentiate an enterprise-grade Compute IaaS service from a general purpose Compute IaaS service. Its authors look forward to reviewing proposals by service providers who can address their solution carefully to these requirements, and then differentiate based on quality, performance, scale, service level, latency, security or cost over and above these requirements. The remainder of this joint document provides a preview and summary of the key themes in the TM Forum and ODCA reports. These source documents are: ODCA Master Usage Model: Compute Infrastructure as a Service (CIaaS) 1 TM Forum s TR174 Enterprise-Grade External Compute IaaS Requirements (Virtual Private Cloud) -often referred to as the Technical Report 2 3

4 TM Forum s TR174 Addendum A - Cloud Business Models 3 TM Forum s TR174 Addendum B Enterprise-Grade External Compute IaaS Requirements Spreadsheet (Virtual Private Cloud) 4 TM Forum s TR174 Addendum C Enterprise-Grade Virtual Private Cloud from a State-of-the-Art Reference Implementation 5 Enterprise CIaaS This section provides a preview of the key areas covered within the TM Forum and ODCA requirements for enterprise cloud services. Principles There are generic attributes that define enterprise-grade external Compute IaaS, which include external private cloud. Some features are common to a general-purpose external public cloud as well. These attributes include: Highly flexible service capability with the ability to scale up and down on demand. Pay-per-use (PPU) pricing, where the cost is simply the capacity times the duration of use. Virtualization (typically the only option), where the workload needs to conform to the attributes of the virtual container without dependency on the underlying hardware implementation or specific hardware drivers. Workloads are instantiated from images, rather than built each time from scratch via a scripted install of the OS, system management, security, databases, middleware and applications. An ability to store images for fast reload, or to clone multiple identical workloads and quickly apply unique personality (e.g. host name and IP address) A management interface allowing basic functions, such as create and destroy, scaling or elasticity, shut down and reboot, hibernate and resume, together with such service functions as billing inquiry and payment, SLA selection and reporting, monitoring, console access, and other administration actions. A baseline level of security management, including encryption and isolation from other consumer activities. A baseline level of network control, such as VLAN mapping, firewalls, overall service provider intrusion detection and prevention, and so on. Enterprise CIaaS--General Requirements Following are some of the high-level capabilities required for enterprise CIaaS. More details about these requirements can be found in the source ODCA and TM Forum documents. Operations and Management 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 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. 4. Alignment with Information Technology Infrastructure Library (ITIL) processes for change, incident, and configuration management. Network Management: The service provider must provide options for consumer network connectivity, such as internet VPN, and leased lines. Additionally, the service provider must articulate other network requirements, stipulations and constraints, such as NAT, IP address overlays, and latency controls. 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. 4

5 Security Management: The service provider must provide architectural, design, policy, and other artifacts that demonstrate the degree to which the cloud subscriber s service is segregated from other subscribers. This applies to single-tenant and multi-tenant cloud services. The cloud provider must formally and explicitly affirm that storage, network, and processing security meet the requirements of the cloud subscriber s contracted service level i.e., bronze, silver, gold, or platinum. Additionally, the cloud provider must support independent verification. 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. 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. 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: The service must provide volume flexibility, and allow the consumer to dial up or dial down the resources being consumed. The service must be capable of integrating with the consumer cloud management tools programmatically and through standard APIs. The service should allow the consumer to change workload policy rules and parameters on the fly within specific criteria. The service must provide a cloud service management portal. Compliance Management: The provider must agree and adhere to, and permit enforcement of governing frameworks and policies, internal and external audits, minimum standards and certifications, and consequence management. Lack of controls might subject providers to penalties. 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: 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: 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. The cloud provider must ensure that a third-party cloud subscriber cannot impact the primary or principal cloud subscriber, such as in noisy neighbor situations. Vulnerability Management: 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. 5

6 Monitoring Service: The cloud provider works closely with its ISPs and with regional and international security organizations in order to prevent internetdriven 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 gold and platinum services, DOS and DDOS attacks are contained by filtering the attacking servers as early as possible on the ISP s infrastructure. For service levels 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. 6 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. 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. 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, as well as to provide early warnings of issues that may be preventable. Incident Management: 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 interfaces must be established to manage incidents. 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. For major incidents, as agreed upon in a contract between the provider and the subscriber, the cloud provider must notify affected customers within 48 hours. Incident responses must be agreed upon between both parties in order to make them as effective as possible. Coordinated activities help prevent service degradation by avoiding conflicting actions. Change Management: Governance: 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. 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. For gold and platinum service levels, 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 tape locations. For gold and platinum levels, 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: Provider must have effective automated mechanisms to request, provision, manage, and meter usage of services wherever possible. 6

7 Basic Cloud Lifecycle There are essential lifecycle steps associated with compute infrastructure services. These are elaborated in greater detail in the ODCA Master Usage Model: Service Orchestration Discovery: The cloud subscriber obtains a list of available services from the CIaaS provider. This step may be facilitated by a cloud broker as an option. 2. Negotiation: The cloud subscriber and cloud provider negotiate contract and terms for CIaaS. Refer to the ODCA Master Usage Model: Commercial Framework.8 and ODCA Usage Model: Regulatory Framework 9 for in-depth coverage of relevant requirements and considerations. This step may be intermediated by a cloud broker as an option. 3. Provision: The cloud subscriber submits requirements to the cloud provider for the service that they need. The cloud service provider then fulfills the service request. 4. Instantiation: The step may or may not be required in a given situation. This entails the cloud subscriber taking any manual steps necessary to facilitate their use of the CIaaS service. 5. Use: The cloud subscriber s use of the service, until said service is modified or terminated. This includes management of the service, including start and stop, monitoring, reporting, and so on. 6. Modify: This is an optional step whereby the cloud subscriber reevaluates their requirements and can enter negotiations to alter the service. An example may be elastically bursting capacity beyond already agreed levels. 7. Terminate: Termination of service in accordance with the negotiated contract. Key Performance Indicators The key performance indicators (KPIs) for CIaaS correspond closely with the service attributes specified in the master usage model. They are defined in order to provide an effective way to measure the service. They are important when making services purchases, and for benchmarking those services. KPIs should focus on a small number of core and meaningful statistics that are cost-effective and useful. KPIs Associated with 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 by using the elements and desired service levels in the Service Attributes 10 and Commercial Considerations 11 sections of the ODCA Master Usage Model: Compute Infrastructure as a Service (CIaaS). 1 Major KPI themes include: Service usage and utilization Performance parameters Invocations of defined automated actions Capacity availability Supported service levels (bronze, silver, gold, platinum) Service continuity parameters (RTO, RPO, RCO) Data classification and retention metrics Security controls Defined reports and auditing metrics The master usage model expands on the KPIs, which includes suggested KPIs for internal subscriber and provider use. 7

8 Service Interfaces The CIaaS services interface provides a separation between the interface of a service and its underlying implementation. This ensures that cloud subscribers and their applications can interoperate across the widest possible set of cloud providers. To preserve the investment in development, application, and system logic are separated from the underlying infrastructure through the use of software interfaces. Each interface defines a contract between a service consumer and a service provider. These steps insulate the cloud subscriber from provider-specific protocols, server identities, utility libraries, etc. These help result in subscriber software that is easier to develop, longer lasting, and usable across a wider array of computing environments. CIaaS services interfaces must support the aims of interoperability, specifically: Portability of workloads across clouds and cloud providers. Interconnectability of different cloud infrastructures and services. Consistent management interfaces, both human and automated. Interoperability among disparate cloud providers. Generally, we default to open service interfaces in order to enable ease of adoption and portability of services. The importance of open interfaces cannot be overstated. As discussed by Buyya, et al, a standard interface for CIaaS will allow: 12 Consumers to interact with cloud computing infrastructure on an ad hoc basis. Integrators to offer advanced management services. Aggregators to offer a single common interface to multiple providers. Providers to offer a standard interface that is compatible with the available tools. Vendors of clouds to offer standard interfaces for dynamically scalable service s delivery in their products. Increasingly, cloud providers need to build their offerings on open and interoperable standards to be considered by enterprises. Where these standards don t exist or are found lacking, service and solution providers should collaborate on their development. Enabling Customers to Evaluate Cloud Benefits The main commercial challenges sit within the following themes that, when addressed as a whole, would enable the customer organization to understand whether the cloud service is a financially and operationally the right choice: The ease, and accuracy, with which the organization can develop a total cost of ownership view of the end-to-end service chain within which the external private cloud service sits ( financial normalization ). The clarity and cross service-provider commonality of pricing unit definitions. Minimum or clear commitment levels coupled with maximum flexibility. The inclusion of the customer protective contract terms that support the customer s regulatory environment. Assumption of service-provider liability for direct damages. Scope of service clarity and consumer approval rights for significant changes. Quality of service measures (or SLA) clarity and cross-service provider commonality of service level definitions. Audit rights, commensurate with the client industry, that are operable. Clarity around exit provisions. Commercially protective IP rights and protections. Business continuity and prioritization commitments. Commonality of language and contracting structures. 8

9 Industry Actions Required Select industry actions are listed below. For more information, refer to the ODCA Master Usage Model:Compute Infrastructure as a Service (CIaaS). 1 Solution and service providers need to ensure that their service and product offerings clearly delineate between core capabilities and differentiators. Providers should reference and map their offerings to this and other ODCA documents. Which capabilities are common with the industry at large, and which are unique differentiators for that provider should be clearly outlined as well. Standards development organizations (SDOs) need to develop and aggressively promote interfaces and processes that will enable seamless end-to-end CIaaS offerings that are vendor-agnostic. Service providers need to clearly communicate how their offerings map against the ODCA Conceptual Framework 13, and how the different architectural elements work together. Cloud consumers need to proactively prepare their organizations for the operating model changes and other potential disruptions that may arise from introducing CIaaS services from an outside provider. SDOs need to develop common, industry-standard semantics for cloud provisioning. Maturation of and standards for network virtualization. There needs to be a means for solution and service providers to enable metrics sharing across monitoring systems and tools in standardized and open ways whether through APIs, adapters, extensions, or the like. Service and solution providers should take into account real user monitoring insights to drive load test scripts, such that those scripts better reflect the combinations of transactions that occur based on real user usage. These complementary reports outline the key requirements that differentiate an enterprise-grade CIaaS from a general purpose CIaaS. The TM Forum and ODCA look forward to proposals by service providers who can target their solution carefully to these requirements, and then differentiate based on quality, performance, scale, service level, latency, security or cost over and above these requirements. 9

10 Endnotes 1. ODCA Master Usage Model: Compute Infrastructure as a Service (CIaaS) Compute_IaaS_MasterUM_v1.0_Nov2012.pdf 2. TM Forum s TR174 Enterprise-Grade External Compute IaaS Requirements (Virtual Private Cloud) org/docs/tmforum_tr174enterprisegrade_computeiaasrequirements.pdf 3. TM Forum s TR174 Addendum A-Cloud Business Models cloudbusinessmodels.pdf 4. TM Forum s TR174 Addendum B Enterprise-Grade External Compute IaaS Requirements Spreadsheet (Virtual Private Cloud) TM Forum s TR174 Addendum C Enterprise-Grade Virtual Private Cloud from a State-of-the-Art Reference Implementation opendatacenteralliance.org/docs/tmforum_tr174enterprisegrade_referenceimplementation.pdf 6. ODCA Usage Model: Provider Assurance 1.1_b.pdf 7. ODCA Master Usage Model: Service Orchestration v1.0_nov2012.pdf 8. ODCA Master Usage Model: Commercial Framework MasterUM_v1.0_Nov2012.pdf 9. ODCA Usage Model: Regulatory Framework docs?download=455:regulatory_framework 10. Service Attributes 7.0, page Commercial Considerations , page Cloud Computing: Principles and Paradigms; Buyya, Broberg, Goscinski; John Wiley & Sons; 2011; pg ODCA Conceptual Framework id=16&ie=utf-8&oe=utf-8&q=prettyphoto&iframe=true&width=60%25&height=90%25 10