IBM云计算参考架构2.0介绍和体系架构概述 – 果果(苹果和因果)

IBM云计算参考架构2.0介绍和体系架构概述

Introduction and Architecture Overview

IBM Cloud Computing Reference Architecture 2.0

IBM云计算参考架构2.0介绍和体系架构概述

Authors:

Michael Behrendt

Bernard Glasner

Petra Kopp

Robert Dieckmann

Gerd Breiter

Stefan Pappe

Heather Kreger

Ali Arsanjani

文档历史

文档位置

This is a snapshot of an on-line document. Paper copies are valid only on the day they are printed. Refer to the author if you are in any doubt about the currency of this document.

修订历史

Date of this revision: 02-28-11

Date of next revision: to be defined

Revision Number	Revision Date	Summary of Changes	Changes marked
1.0	02-28-11	1.0 Submission to Open Group	N

目录

文档历史......................................................................................................................................... 2

文档位置......................................................................................................................................... 2

修订历史......................................................................................................................................... 2

1. 介绍....................................................................................................................................... 5

1.1. 描述...................................................................................................................................... 5

1.2. 目的...................................................................................................................................... 5

1.3. 怎样使用本作品?.................................................................................................................... 6

1.4. SOA 和云............................................................................................................................. 6

1.5. 使用基于CCRA和SOA RA..................................................................................................... 10

2. IBM 云计算参考架构(CCRA) 概述............................................................................... 13

2.1. 介绍.................................................................................................................................... 13

2.2. 角色.................................................................................................................................... 13

2.2.1.1. 云服务消费者......................................................................................................... 14

2.2.1.2. 云服务供应商......................................................................................................... 14

2.2.1.3. 云服务创建者......................................................................................................... 15

2.3. 架构元素............................................................................................................................. 16

2.3.1. 云服务消费者................................................................................................................ 16

2.3.1.1. 云服务集成工具...................................................................................................... 16

2.3.1.2. 消费者内部IT.......................................................................................................... 16

2.3.2. 云服务提供商................................................................................................................ 18

2.3.2.1. 云服务................................................................................................................... 18

2.3.2.1.1. 云服务模式............................................................................................................ 19

2.3.2.1.1.1. 基础设施即服务(IaaS).......................................................................................... 20

2.3.2.1.1.2. 平台即服务（PaaS）........................................................................................... 20

2.3.2.1.1.3. 软件即服务（SaaS）........................................................................................... 20

2.3.2.1.1.4. 业务流程即服务（BPaaS）.................................................................................. 21

2.3.2.1.2. 云服务创建&生态系统............................................................................................. 21

2.3.2.2. 基础设施................................................................................................................ 22

2.3.2.3. 公共云管理平台(CCMP)......................................................................................... 24

2.3.2.3.1. 商业支持服务（BBS）........................................................................................ 27

2.3.2.3.2. 业务操作支持服务（OSS）................................................................................. 29

2.3.2.4. 安全性、灵活性、性能和消费性............................................................................... 30

2.3.3. 云服务创建者................................................................................................................ 31

2.3.3.1. 服务开发工具......................................................................................................... 31

3. 云计算服务参考架构（CCRA）:架构原则和相关指导................................................ 33

3.1. CCRA特定架构原则.............................................................................................................. 33

3.1.1. 表示架构原则的起源...................................................................................................... 33

3.1.2. 原则1：云规模设计....................................................................................................... 34

3.1.3. 原则2：支持精简服务管理............................................................................................. 35

3.1.4. 原则3: 识别和利用共性................................................................................................. 37

3.1.5. 原则4: 在云服务的生命周期中，应该统一定义和管理...................................................... 38

4. 参考..................................................................................................................................... 40

1. 介绍

This document serves as the definition of the IBM Cloud Computing Reference Architecture (CCRA).

此篇文档是IBM云计算参照架构(CCRA)的定义说明。

A Reference Architecture (RA) provides a blueprint of a to-be-model with a well-defined scope, requirements it satisfies, and architectural decisions it realizes. By delivering best practices in a standardized, methodical way, an RA ensures consistency and quality across development and delivery projects.

一个参考模型(RA)主要用于提供一个这样的模型蓝图：具有良好的使用范文、使需求得到满足、架构目标能够得到实现。通过标准化、有条理的方式提供最佳实践做法，RA在跨越项目的开发和交付上提供了一致性和质量。

CCRA的目标任务被定义如下：

Definition of a single Cloud Computing Reference Architecture, enabling cloud-scale economics in delivering cloud services while optimizing resource and labor utilization and delivering a design blueprint for

一个简单的云计算参考架构定义为启用一个云规模经济，提供能优化资料和劳动力利用率，并且提供设计蓝图的云服务：

§ 向客户提供的云服务；

§ 私有、公共或混合模式的云项目；

§ 工作负载的优化系统；

§ 在基于同样的、公共的规模经济管理平台下，能够管理多路云服务（基础设施云（IaaS）/平台云（PaaS）/软件云（SaaS）/商业处理云（BPaaS））。

1.1. 描述

The CCRA is based on real-world input from many cloud implementations across IBM. The Architecture Overview Diagram (AOD) provides overview of the fundamental architectural building blocks making up the CCRA. It also defines architectural principles serving as a guideline for creating any cloud environment.

CCRA是基于现实世界、许多来自全国各地的IBM云实现结果的导入。该架构概述图（AOD）提供了构建CCRA的基础架构构件的一个概述。同时也定义了创建任何云环境的原则性的架构指导。

1.2. 目的

The Cloud Computing Reference Architecture is intended to be used as a blueprint / guide for architecting cloud implementations, driven by functional and non-functional requirements of the respective cloud implementation. Consequently, the CCRA should not be viewed as fine-granular deployment specification of just a single specific cloud implementation (and its management platform

云计算参考架构（CCRA）主要目的是用于蓝图/云实现项目的大纲指导、云实施项目中功能性或非功能性需求驱动的设计指南。因此CCRA不应被看作是一个特定云实施（包含管理平台）项目的细颗粒的部署规格说明。

本文档的编写目的如下：

1. 本文档定义了构成IBM云计算参考架构的基本的架构元素和关系；
2. 本文档定义了用于交付和管理云服务的基本架构原则的基础。

CCRA的主要受众：

· 实现展现CCMP能力的云服务开发团队；

· 实现CCMP交付和管理能力的开发团队；

· 为客户实现私有云的从业人员。

1.3. 怎样使用本作品?

The architecture overview is intended to provide a common, coherent architectural structure which should be used as a basis for any cloud computing project. This allows representing the architecture of any cloud project in a consistent fashion. Existing "legacy" products and technologies as well as new cloud technologies can be mapped on the AOD to show integration points amongst the new cloud technologies and integration points between the cloud technologies and already existing ones.

本架构概述主要提供一个可以在任何云计算项目中可以使用的、公共的、一致的基础架构，这使得任何云项目架构的表现都是一致的。这允许代表以一致的方式在任何云项目的体系结构。现有的"传统"（架构和技术实现）的产品和技术，以及新云技术，都可以映射到AOD之上显示为一个集成上；此集成点是新的云技术和包含云技术和现有技术的整合点的统一整合。

The architectural principles define the fundamental principles which need to be followed when realizing a cloud. These principles need to be followed on all implementation stages (architecture, design, and implementation) and have implications across all work products.

架构原则定义了在实现云时需要遵循的基本原则。这些原则需要在所有实施阶段被遵循（架构、设计和实施）和所有的工作产品中产生影响。

1.4. SOA 和云

为了理解IBM CCRA，就必须理解SOA和云之间的关系，不仅仅在架构层次，也包括在解决方案和服务层次理解两者的关系。

Service oriented architecture (SOA) is defined by The Open Group (http://www.opengroup.org/soa/soa/def.htm) to be "an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services."

Open Group这样定义了面向服务架构(SOA) (http://www.opengroup.org/soa/soa/def.htm) ："支持面向服务的体系结构风格，服务导向是一种想法的服务和基于服务的发展和服务的成果。"

According to NIST (http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc), "Cloud Computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models."

根据NIST （http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc），"云计算模型启用共享的可配置计算资源（例如，网络、服务器、存储、应用程序和服务），可以迅速调配和最少的管理工作或服务提供者的互动与发布无处不在、方便的点播网络访问权限。这云模型推动可用性而是组成的五个基本特征、三个服务模型和四种部署模型。

The Service models are Cloud Infrastructure as a Service, Cloud Platform as a Service, and Cloud Software as a Service. The service models, and the fact that cloud computing is discussed in terms of the creation, delivery and consumption of cloud services, means cloud computing supports service orientation. Enterprises expose infrastructure, platforms and software as services as part of SOA solutions today. Certainly Software as a Service is not new and has been a popular topic for years.

云基础架构作为一项服务、云平台作为一种服务和云软件作为一种服务的服务模式。服务模式，并指出，云计算讨论中创建、交付和消费的云计算服务，意味着云计算支持服务方向。企业公开基础设施、平台和软件服务作为SOA 解决方案的一部分作为今天。当然作为服务的软件并不是新和多年来一直受欢迎的主题。

The cloud Deployment models are Private, Community, Public, and Hybrid. These deployment models define the scope of the cloud architecture and solution, does the cloud solution exist strictly within the organization boundaries (private), across organization boundaries (public), or a combination (Hybrid). Certainly these scopes have been seen in SOA solutions before Cloud (while there was not a well known architectural model for them as there is in cloud computing), there are SOA solutions that exist strictly within an enterprise, or between businesses across enterprise boundaries (B2B). In fact one of the key values of SOA was to develop SOA solutions with services that are integrate between business partners, enabling outsourcing, simplifying integration and increasing agility, much like the Hybrid model. Cloud computing enables this paradigm by adding cloud-characteristics to the services being delivered & consumed.

云部署模型是私人、 社区、 公开和混合。这些部署模型定义云的体系结构和解决方案的范围、 云解决方案存在严格 （私人），组织边界，跨组织边界 （公共） 或组合 （混合） 内。当然在 SOA 解决方案之前云已见过这些作用域 （而不有众所周知的建筑模型，他们是在云计算），有存在严格的企业内部或跨企业 (B2B) 的企业之间的 SOA 解决方案。事实上，SOA 的键值之一是开发 SOA 解决方案的集成业务伙伴，从而实现外包、 简化集成和提高灵活性，很像的混合模型之间的服务。云计算通过此范例将云特性添加到服务正在传递科技消耗。

The essential characteristics for Cloud Computing are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured Service. These characteristics can be found in requirements and SOA solutions in various organizations today, although these characteristics are optional for SOA and mandatory for cloud.

云计算的基本特征是自助服务的需求、 广泛的网络访问、 资源池、 快速的弹性和衡量的服务。这些特性可以找到要求和 SOA 解决方案在各种组织今天，虽然这些特点是可选的 SOA 和强制性的云。

Usually, a single SOA solution does not have all of these are characteristics simultaneously, unless it is a very mature organization leveraging SOA. For these organizations, each of these solutions had to be built in its entirety for that organization. The SOA solution and management of it must be built from scratch, and is not generally shared amongst organizations. Reuse is generally within an organization or an industry, not between organizations and entire communities. Service delivery and consumption aspects are a small part of the requirements for the SOA solution.

通常情况下，一个单一的 SOA 解决方案不包含所有的这些特点是同时，除非它是一个非常成熟的组织，利用 SOA。这些组织中，这些解决方案的每个了该组织的全部建成。SOA 解决方案和它的管理必须从零开始，建造和一般不会组织之间共享。重用通常是在组织或工业，不是组织和整个社区之间。所需的 SOA 解决方案的一小部分的服务交付和消费等方面的问题。

What is new about cloud is that instead of supporting these requirements per solution, the industry is trying to \'standardize\' how these requirements are being met to enable cloud computing. Cloud architectures require a set of capabilities and ABBs to meet the NIST essential characteristics that are optional in SOA. In addition, these ABBs may be implemented in Cloud specific ways to handle scale, cost optimization and automation.

新云的是的而不是支持这些要求每个解决方案，业界正试图\'规范\' 这些要求都得到满足，使云计算。云体系结构需要一组功能和ABBs，以满足NIST 本质特征在SOA 都是可选的。此外，这些ABBs 可实现在云具体的方法来处理规模、成本优化和自动化。

This discussion shows that Cloud computing architectures are Service Oriented architectures and adhere to architectural style that supports service orientation. Cloud solutions are SOA solutions.

云计算体系结构是面向服务的体系结构，并坚持支持服务导向的建筑风格，显示了这一讨论。云的解决方案是 SOA 解决方案。

Open Group组织是这样定义了服务的：

" 一个服务：

• 是一个具有特定的结果输出的、可重复执行的商业获得的逻辑表示（例如：检查客户信用、提供气象数据、提供数据钻取报告）；
• 是独立的；
• 可能由其他服务组成
• 对于服务的消费者来说是一个\'黑盒子\'"

Cloud services, according to The Open Group definition, are SOA services. However, not all SOA services are Cloud service because they require automated deployment and management as well as offering support in order to support the Cloud characteristics.

根据Open Group组织的定义，云服务就是SOA服务。然而，不是所有的SOA服务都是云服务，因为云服务需要自动化的部署和管理，来为云特性提供支持。

On the architecture continuum (see TOGAF at http://www.opengroup.org/architecture/togaf9-doc/arch/chap39.html), Cloud architectures are more concrete than The Open Group\'s SOA reference architecture (http://www.opengroup.org/projects/soa-ref-arch/uploads/40/19713/soa-ra-public-050609.pdf), a domain architecture scoped to service delivery and management. Principles and architectural decisions have been premade already to enable the Cloud computing architecture to be self service, network accessible, and scalable. Architectural building blocks have already been identified for Cloud solution architects to use for operational and business support. In some cases, Cloud service providers may provide well defined, maybe even standardized, management and security support and services.

对体系结构连续 （见在 http://www.opengroup.org/architecture/togaf9-doc/arch/chap39.html 的 TOGAF），云体系结构是更具体的比公开组的 SOA 参考体系结构 （http://www.opengroup.org/projects/soa-ref-arch/uploads/40/19713/soa-ra-public-050609.pdf），应用范围限定为服务的提供和管理域体系结构。原则和建筑的决定有被预制已经使云计算体系结构要自助服务，网络可访问的和可扩展性。建筑构造块已查明的云解决方案架构师使用的运营和业务支持了。在某些情况下，云服务提供商可能会提供定义好、 甚至标准化、 管理和安全性的支持和服务。

For cloud, some service identification has been done (reusable, utility services, for example, to control VMs and deploy/undeploy applications or services) and implementations of services may be available from an existing services ecosystem. The existence of this services ecosystem and concrete architecture makes SOA via clouds simpler for service consumers to adopt because the designs and implementations have been provided.

云，有些服务标识已经(可重用、实用程序的服务，例如，控制虚拟机和部署取消部署应用程序或服务）和服务的实现可以从现有的服务生态系统。存在此服务的生态系统和混凝土建筑使SOA 云通过简单的采用，因为提供了设计和实施服务消费者。

The benefit of recognizing the heritage of Cloud from SOA is that the existing experience over the last 5 years and standards already available for SOA and SOA solutions can be applied to Cloud Computing and Cloud solutions.

好处是承认的遗产云从SOA 是现有的经验，在过去的5 年，已可用的标准为SOA 和SOA 解决方案可应用于云计算和云的解决方案。

SOA standards in The Open Group that can be applied to Cloud include:

可应用于云的公开组中的SOA 标准包括：

• The Open Service Integration Maturity Model - this model helps determine the level of service use in an organization, these levels apply to the use of cloud services. Cloud computing can be seen as the \'Virtualized" and "Dynamically reconfigurable" levels. 打开服务一体化的成熟度模型--此模型，可以帮助确定在组织中使用的服务的级别，这些级别适用于云服务的使用。云计算可以被视为虚拟化"和动态可的重构的水平。
• The SOA Ontology defines service and SOA concepts which can be used as a basis for describing cloud services, though extension Ontologies should be developed for cloud.. SOA 本体定义服务和SOA 概念可作为基础来描述云服务，虽然扩展本体应发展为云...
• The SOA Reference Architecture defines the functional and cross cutting concerns and ABBs for SOA, which also applies to Cloud. This standard has been used as a basis for the IBM CCRA. SOA 的参考体系结构定义的功能和交叉切割关切和SOA 的ABBs，这也适用于云。这一标准已被用作基础IBM 数据库。
• The SOA Governance Framework defines a governance reference model and method that applies to the development of cloud services and solution portfolio and lifecycle management. Best practices for governance of Cloud solutions will need to be developed in addition to this standard. SOA 治理框架定义了一种治理参考模型与方法适用于云服务和解决方案组合和生命周期管理的发展。治理的云解决方案的最佳实践需要除本标准制定中。
• Security for Cloud and SOA, a joint workgroup between SOA and Cloud Workgroups in The Open Group, defines security considerations and ABBs for both Cloud and SOA. 云和SOA，SOA 和的打开组中，云工作组之间的联合工作组的安全定义云，SOA 的安全注意事项和ABBs。
• SOCCI, another joint SOA and Cloud Workgroup in The Open Group defines the architecture for exposing infrastructure as a service for both SOA and Cloud solutions. SOCCI，另一种联合SOA 和云工作组在公开组定义作为SOA 和云的解决方案服务公开基础设施的体系结构。

Certainly functions that were optional for SOA solutions are now required for Cloud solutions, like virtualization, security across business boundaries, and service management automation. New functions and requirements are getting in focus with cloud driving experiences from the SOA world to the next level.

当然都是可有可无的SOA 解决方案的功能目前所需的云的解决方案，如虚拟化，跨业务边界和服务管理自动化的安全。新的功能和要求从SOA 世界驾驶经验，到下一个级别的云焦点越来越。

1.5. 使用基于CCRA和SOA RA

The SOA RA (http://www.opengroup.org/projects/soa-ref-arch/uploads/40/19713/soa-ra-public-050609.pdf),), as being standardized by The Open Group, applies to Cloud architectures and is the underlying architecture for the IBM CCRA.

公开组之外，通过规范的SOA RA （http://www.opengroup.org/projects/soa-ref-arch/uploads/40/19713/soa-ra-public-050609.pdf），），适用于云的体系结构和是IBM 数据库的基本体系结构。

The functional concerns: operational systems, service components, services, business processes and consumer interfaces; all exist in and are relevant to functional concerns for cloud architecture\'s

功能的关注： 运营系统、 服务组件、 服务、 业务流程和消费者的接口 ；所有存在的和相关的云的体系结构的功能注意事项

For the Cloud architecture, there has been special focus on the:

对于云体系结构中，有一些需要特别关注：

· Operational Layer: Infrastructure is part of the operational systems layer, but often highlighted in Cloud architectures because Cloud imposes new requirements on infrastructure to enable broad network access, resource pooling, rapid elasticity, virtualization and scalability. 业务层： 基础设施是业务系统层中的一部分，但云的体系结构中经常强调，因为云规定新基础设施，使广泛的网络访问、 资源池、 快速的弹性、 虚拟化和可扩展性。

· Service Layer: The common cloud service types, *aaS, are identified in the services layer. These cloud service types, like other services, use and sometimes expose assets in the Operational systems layer. For cloud services, which assets are exposed is often the focus of the service type, ie within operational systems, hardware infrastructure is exposed as IaaS, and middleware is exposed as PaaS, and business process as BPaaS. 服务层： 常见云服务类型，* 原子，标识服务层中。这些云服务的类型，如其他服务和使用有时公开资产运营系统图层中。云的服务，哪些资产受到往往是服务类型的重点、 ie 业务系统内，硬件基础设施作为云计算模式将，和中间件受到部分分配数量，以及作为 BPaaS 的业务流程。

· Business Process: Business processes participate in a Cloud solution much like they do in SOA solutions, they can be provided as a service (BPaaS) or be the consumer of services (whether they care cloud services or not). Additionally, business processes within a cloud provider organization need to be restructured and streamlined in novel ways to meet much faster time-to-deliver, time-to-change and cost objectives.. 业务流程： 业务流程参与云解决方案更像他们一样的 SOA 解决方案，它们可以作为一种服务 (BPaaS) 提供或将服务的使用者 （无论他们关心云服务）。此外，云提供商组织内部的业务流程需要重组和精简以新颖的方式，以满足多快交货时间，要更改的时间和成本的目标...

· Consumer Layer: The consumer layer is more strictly and carefully separated from the services and service provider to allow pooling and substitution of cloud services or providers. 消费层： 消费层更严格、 细致的分离的服务和服务提供商以允许池和替代云服务的提供商。

The cross cutting concerns in the SOA RA: integration, quality of service, information and governance: are important concerns for all cloud architectures and solutions, just like they are for SOA. The fact that they are cross cutting means that each of the functional layers may have interactions with capabilities in the cross cutting layers.

在 SOA RA 的交叉问题： 集成、 优质的服务、 信息和治理： 是重要的问题，所有的云体系结构和解决方案，就像它们是 SOA。他们是交叉切割的事实意味着每个功能的图层可能具有交互功能的交叉层中。

For the Cloud architecture, there has been special focus on the:

对于云体系结构中，有一直特别关注：

· Quality of Service (QOS) layer: The Quality of Service cross cutting concern has additional significant requirements for Cloud for management and security in order enable NISTs on-demand self-service and measured service requirements as well as IBM\'s requirements for resiliency, security, performance, automated management, operational, and business support. The management support can be represented as a Common Cloud Management Platform in the SOA RA QOS layer, which includes support for operational and business support services, aka OSS and BSS. This is critical for driving economies-of-scale by delivering many cloud services based on the same foundation. 优质的服务 (QOS) 层： 交叉切割关注服务质量有云的附加重要要求管理和安全，为了使 NISTs 点播的自助服务和测量的服务需求，以及 IBM 的可恢复性、 安全性、 性能的要求自动管理、 运营和业务支持。管理支持可以表示为一个共同的云管理平台，在 SOA RA QOS 层中，其中包括运营和业务支持服务，也称为开放源码软件和盲源分离的支持。这是带动经济的规模提供的相同的基础上的很多云服务的关键。

· Governance for cloud solutions will also have some unique patterns of requirements needed to support governance across organizational boundaries. 云解治理还将一些独特的模式的支持跨组织边界的治理所需的要求。

For the cloud ecosystem, they cloud service consumers, providers and creators are the common high level roles identified in the cloud architectures.

云的生态系统，为他们云服务消费者、 供应商和创作者是共同确定云的体系结构中的高级别角色。

It is important to look at Cloud in the context of SOA, and Cloud solutions in the context of the larger SOA solutions underpinning them. This diagram shows the QOS layer details that are essential to understand for Cloud, as well as the *aaS and Infrastructure layers

请务必在SOA，看看云和云加以巩固的较大的SOA 解决方案的上下文中的解决方案。此图显示所必需的云，理解QOS 层详细信息以及* 原子和基础结构层

The cross cutting concerns for integration and information are still important and must be considered in the development of any Cloud architecture and solution architecture. However, cloud does not introduce any new principles or concerns to these cross cutting layers.

集成和信息的交叉问题仍然是重要的和必须考虑任何云的体系结构和解决方案体系结构的发展。然而，云不引入任何新的原则或关注这些交叉切割图层。

To make it easier to focus on the Cloud concerns rather than the SOA concerns, we can lift the Cloud concerns into its own diagram, as we show in the remainder of this document.

为了便于云的关注，而不是SOA 关注的重点，我们可以提升云关切到其自己的图中，正如我们在本文的其余部分中显示。

The concepts and architectural elements not depicted in the CCRA are still implied and present via its SOA RA heritage.

概念和不在数据库中所描述的建筑元素是仍然隐含与目前通过其SOA RA 遗产。

The cross cutting concerns for integration and information are still important and must be considered in the development of any Cloud architecture and solution architecture. However, cloud does not introduce any new principles or concerns to these cross cutting layers.

集成和信息的交叉问题仍然是重要的和必须考虑任何云的体系结构和解决方案体系结构的发展。然而，云不引入任何新的原则或关注这些交叉切割图层。

To make it easier to focus on the Cloud concerns rather than the SOA concerns, we can lift the Cloud concerns into its own diagram, as we show in the remainder of this document.

为了便于云的关注，而不是SOA 关注的重点，我们可以提升云关切到其自己的图中，正如我们在本文的其余部分中显示。

2. IBM 云计算参考架构(CCRA) 概述

2.1. 介绍

The IBM Cloud Computing Reference Architecture (CCRA, see 图2) defines the fundamental architectural elements constituting a cloud computing environment. The CCRA is structured in a modular fashion in a sense that on its highest level of abstraction, the main roles and the corresponding architectural elements are defined allowing to drill down for each of these elements as needed. Later sections of this document will describe detailed versions of this IBM Cloud Computing Reference Architecture Overview diagram, which provide a more fine-grain view of the high-level architectural elements of the overall CCRA. As a result of specifying the CCRA, a base terminology is established, which should be used as a reference for any other cloud computing related effort.

IBM 云计算参考架构(CCRA, 参见图2) 定义了构成云计算环境的基本架构元素。CCRA在某种模块化意义上是最高层次的抽象，主要角色和相应的架构元素被定义允许向下钻取每个必须的元素。本文档后面的章节将详细介绍IBM 云计算参考架构概述关系图的详细版本，在关系图中详细的提供了CCRA中更细粒度的架构元素视图。CCRA的规格结果，将建立一套基本术语用于其他任何相关联的云计算工作。

The following sections will describe each architectural element of the CCRA depicted in 图3 in detail.

以下各节将对图3中出现的架构元素作详细的描述。

图1: IBM 云计算参考架构（CCRA）概念图

2.2. 角色

The IBM Cloud Computing Reference Architecture defines three main roles: Cloud Service Consumer, Cloud Service Provider and Cloud Service Creator. Each role can be fulfilled by a single person or can be fulfilled by a group of people or an organization. The roles defined here intend to capture the common set of roles typically encountered in any cloud computing environment. Therefore it is important to note that depending on a particular cloud computing scenario or specific cloud implementation, there may be project-specific sub-roles defined.

IBM云计算参考架构定义了三个主要角色：云服务消费者、云服务提供商和云服务创造者。每一个角色可以由单个人执行，也可以由一组人或一个组织团体去执行。这里定义的角色是在云计算环境中遇到的典型性的通用角色集合。但必须要注意到，在特定的云计算场景和云计算实现中，存在着项目特定的子角色定义。

2.2.1.1. 云服务消费者

A cloud service consumer is an organization, a human being or an IT system that consumes (i.e., requests, uses and manages, e.g. changes quotas for users, changes CPU capacity assigned to a VM, increases maximum number of seats for a web conferencing cloud service) service instances delivered by a particular cloud service. The service consumer may be billed for all (or a subset of) its interactions with cloud service and the provisioned service instance(s).

一个云服务消费者可以是一个组织、一个人或一个IT系统，他们消耗着特定的云服务实例（即请求、使用和管理，例如：更改用户的配额，改变分配给虚拟机的CPU使用量，为Web会议云服务增加最多席位数）。在所有（或部分）云服务和相关服务实例的使用时，服务消费者可能会被收取费用。

A service consumer can also be viewed as a kind of super-role representing the party consuming services. For example, in case a credit card company is using some cloud services, the company as a whole is a service consumer relative to the provider. Within the service consumer role more specific roles may exist, such as a technical role responsible for making service consumption work from a technical perspective; and there might be a business person on the consumer side who is responsible for the financial aspects. Of course, in more simplified public cloud scenarios all of these consumer-centric roles could be collapsed into a single person, but the roles still exist.

云服务消费者当然也能被视为一个超级角色，其提供了社交性的公共服务。例如：在一个案例中，一家信用卡公司正在使用默写云服务，相对于服务供应商，公司以一个整体性的消费者来获取服务。

The cloud service consumer browses the service offering catalog and triggers service instantiation and management from there. There may be cases where the interaction with the service delivery catalog is tightly embedded within the actual cloud service. In particular this is pretty common for SaaS and BPaaS cloud services where application-level virtualization is implemented, e.g. LotusLive.

云服务消费者浏览服务提供商提供的服务目录并触发和管理一个得到的服务实例。

2.2.1.2. 云服务供应商

The Cloud Service Provider has the responsibility of providing cloud services to Cloud Service Consumers. A cloud service provider is defined by the ownership of a common cloud management platform (CCMP). This ownership can either be realized by truly running a CCMP by himself or consuming one as a service.

云服务提供商有能力提供云服务给云服务消费者。云服务提供商被定义为具有公共云服务管理平台(CCMP)的所有权。这里的所有权指的是真实的有自己运行一个CCMP，或者以服务方式去消费其中的一个。

People acting in the role of a Cloud Service Provider and a Cloud Service Consumer at the same time would be a partner of another cloud service provider reselling cloud services or consuming cloud services and adding value add functionality on top, which would in turn be provided as a cloud service.

人们以云服务提供商和云服务消费者的作用，同时将另一个云计算服务提供商转销云服务的合作伙伴或消费的云计算服务和增值之上添加功能这反过来会作为云服务提供。

Although defined as a separate role, it would also be possible that a Cloud Service Provider has Cloud Service Creators in the same organization, i.e. it is not necessary that Cloud Service Provider and Cloud Service Creator are in separate organizations.

虽然定义为一个单独的角色，它也有可能云服务提供商在同一组织中有云服务的创建者，即是不必要的云服务提供商和云服务的创建者是在独立的组织。

2.2.1.3. 云服务创建者

The Cloud Service Creator is responsible for creating a cloud service, which can be run by a Cloud Service Provider and by that exposed to Cloud Service Consumers. Typically, Cloud Service Creators build their cloud services by leveraging functionality which is exposed by a Cloud Service Provider. Management functionality which is commonly needed by Cloud Service Creators is defined by the CCMP architecture. A Cloud Service Creator designs, implements and maintains runtime and management artifacts specific to a cloud service.

云服务创建者的目的是创建一个能够被云服务提供商运行并暴露给云服务消费者的云服务。通常情况下，云服务创建者利用云服务提供商暴露的服务功能来创建他们的云服务。由CCMP架构定义了云服务创建者需要的服务管理功能。云服务创建者设计、实现和维护运行时，并且管理运用于云服务的特定工件。

Just like the Cloud Service Consumer and the Cloud Service Provider, the Cloud Service Creator can be an organization or a human being. For example, an ISV company developing a cloud service is a Cloud Service Creator, whereas obviously there could be 100\'s of employees within that particular Cloud Service Creator incarnation, each of them taking on a specific business or technically focused sub-role.

就如同云服务提供商和云服务消费者一样，云服务创建者可以是一个组织或一个人。例如，一个开发云服务的独立软件开发商(ISV)是一个云服务创建者，显然其中的100个员工也可能是特定范围内的云服务创建者的化身，他们中的每一个都在特定业务或技术上聚焦于子角色任务。

It is also typical that that operations staff responsible for operating a cloud service is closely integrated with the development organization developing the service (this integration is commonly referred to as "DevOps"). This is an important aspect to achieve the delivery efficiency expected from cloud services as it allows a very short feedback loop to implement changes in the cloud service which benefit the operational efficiency of the cloud service.

这也是典型的操作人员负责操作云服务，紧密结合与发展组织发展（这种集成俗称为"DevOps"）的服务。这是一个重要的方面，以实现预期从云服务，因为它允许在受益云服务的运作效率的云服务中实施更改很短的反馈循环的递送效率。

2.3. 架构元素

2.3.1.云服务消费者

Diagram 2: IBM CCRA -云服务集成工具&消费者内部IT系统

2.3.1.1. 云服务集成工具

From the perspective of a Cloud Service Consumer, it is important to be able to integrate cloud services with their on-premise IT. The functionality of Cloud Service Integration Tools is specifically relevant in the context of hybrid clouds, where seamless integrated management, usage and interoperability of cloud services in integration with on-premise IT is critical.

从云服务消费者的角度看，重要的是与服务能够集成到的内部部署的IT系统中。云服务集成工具的功能是具体有关混合云的上下文中，在无缝集成的管理、使用情况和云服务的集成与互操作性上-前提是关键。

2.3.1.2. 消费者内部IT

Besides IT capabilities consumed as cloud services, consumers of such IT may continue to have in-house IT, which can be managed in a traditional non-cloud fashion. In case functionality of the existing in-house IT should be integrated with cloud services consumed from a cloud service provider, the aforementioned cloud service integration tools are required. Consumer in-house IT exists across all layers of the technology stack (infrastructure, middleware, applications, business processes, service management), therefore integration with cloud services can take place on each of these layers.

除了它功能消耗为云服务，这样它可能会继续有内部，可以管理的一种传统的非云方式的消费者。如果现有内部IT 功能应结合云消耗从云服务提供商的服务，需要上述云服务的集成工具。内部存在跨所有图层的技术堆栈（基础设施、中间件、应用程序、业务流程、服务管理），因此与云服务的集成的消费者可以在每一层上的地方。

2.3.2.云服务提供商

2.3.2.1. 云服务

图3: IBM CCRA -云服务明细

Cloud Services can represent any type of (IT) capability which is provided by the Cloud Service Provider to Cloud Service Consumers, implementing all cloud characteristics (self-service access, network-based access, served out of a resource pool, elastic, pay-per-use). There are four categories of Cloud Services: Infrastructure, Platform, Software or Business Process Services. In contrast to traditional (IT) services, cloud services have attributes associated with cloud computing, such as a pay-per-use model, self-service usage, flexible scaling & shared of underlying IT resources.

云计算服务可以表示任何类型的(IT) 是云服务提供商提供云服务的消费者，执行所有的云特性（自助服务的访问，基于网络的访问外, 送达资源池，弹性的情况下，每个使用付费）的能力。有四种类别的云计算服务：基础设施、平台、软件或业务流程服务。相对于传统的(IT) 服务，云服务有云计算，每个使用付费的模式，如自助服务的使用情况，灵活与关联的属性扩展科技的底层IT 资源的共享。

The management functions defined as part of the CCMP architecture are responsible for delivering instances of Cloud Services of any category to Cloud Service Consumers, the ongoing management of all Cloud service instances from a provider perspective and allowing Cloud Service Consumers to manage their Cloud Service instances in a self-service fashion.

负责为云服务的消费者，从供应商的角度看云服务的所有实例的日常管理提供云服务的任何类的实例，并允许云服务消费者来管理它们的云服务实例，以自助方式管理功能，定义为CCMP 体系结构的一部分。

For all cloud services there is software required implementing cloud service specifics: For IaaS, there are typically hypervisors installed on the managed hardware infrastructure, for PaaS there would a multi-tenancy enabled middleware platform, for SaaS a (multi-tenancy enabled) end-user application and for BPaaS there typically is a multi-tenancy enabled business process engine.

有实施云服务细节的软件所需的所有云服务：云计算模式为将，通常有PaaS 有托管的硬件基础设施，已安装的系统管理程序的SaaS （启用multi-tenancy) 将multi-tenancy 已启用的中间件平台，最终用户应用程序BPaaS 通常有一个multi-tenancy 的已启用的业务流程引擎。

Depending on the nature of the respective cloud service, there are cloud service specific management interfaces exposed, which are typically used by the management services as defined in the CCMP architecture.

取决于各自的云服务的性质，有云服务特定的管理接口公开，这通常由管理服务使用CCMP 体系结构中定义。

Each cloud service also typically exposes APIs towards the cloud service consumer for programmatic use.

每个云服务通常还公开朝云服务消费者的程序中使用的Api。

Cloud Services can be built on top of each other, e.g. a software service could consume a platform or infrastructure service as its basis, a platform service could consume an infrastructure service as its foundation. However, this is not required, i.e. a software service could also directly be built on top of bare metal infrastructure, clearly inheriting all constraints associated with such an infrastructure. In general, architectural principle #3 postulates to share as much as possible across cloud services with respect to management platform and underlying infrastructure. However, it does not require just one single, fully homogeneous infrastructure - of course, this would be the ideal goal, but given different infrastructure requirements this is not always possible. For example, if a particular cloud service has very specific infrastructure needs (with respect to reliability, latency, throughput, computational performance, hardware platform, etc.) it is clearly allowed to run this cloud service on a dedicated infrastructure (e.g. HPC cloud services would generally run on a purpose-built physical infrastructure for performance and efficiency reasons, they wouldn\'t run on virtualized compute cloud service).

云服务可以建立彼此的顶部，如软件服务可以使用平台或基础设施的服务，作为其基础，平台服务可以消耗作为其基础的基础设施服务。不过，这不是必需，即软件服务也直接可以建立裸金属基础设施的基础上，清楚地继承的所有约束关联等基础设施。一般情况下，建筑原则# 3 假设要尽可能多地共享管理平台和基础架构的云计算服务。不过，它不需要只是一个单一的、完全均匀的基础设施--当然，这将是理想的目标，但鉴于不同基础设施的要求并不总是可能。例如，如果特定云服务有非常具体的基础设施需求（对可靠性、滞后时间、吞吐量、计算性能、硬件平台等）它明确允许运行此云服务专用的基础设施（例如HPC 云服务通常会运行一个专门的物理基础架构，性能和效率的原因他们不会运行虚拟化的计算云服务）。

In the context of building cloud services on top of each other, it is important to distinguish the sharing of a common OSS/BSS (aka CCMP) structure across multiple cloud services and the usage of the actual cloud service capability by another one. An example for the first aspect would be LotusLive and Compute Cloud exploiting / getting managed by the same OSS/BSS construct. An example for the latter aspect would be LotusLive (SaaS) using the compute capacity of a compute cloud service (IaaS) vs. purchasing their own servers.

在建筑上彼此的顶部的云计算服务方面，是区分分享共同的OSS/BSS (aka CCMP) 结构的跨多个云服务和实际云服务能力的使用的另一个重要。第一性的例子就是LotusLive，并计算云开发/ 获得由相同OSS/BSS 构造。后者的方面的例子就是LotusLive (SaaS) 与购买他们自己的服务器使用的一种云计算服务(IaaS) 的计算能力。

In any case, each Cloud Service offered by a Cloud Service Provider is "known" to the BSS & OSS of the Common Cloud Management Platform (otherwise the cloud service wouldn\'t be visible via the service catalog and ready to be consumed). A cloud service provider offers cloud services as a result of very conscious business decisions, since taking a cloud service to market must be supported by a corresponding solid business model and investments for the development and operations (software & operations staff) of the cloud service.

在任何情况下，云服务提供商所提供的每个云服务"已知"星科技开源软件的常见的云管理平台（否则云服务不是通过服务目录可见并准备要消耗）。云服务提供商提供云服务的结果非常清楚的业务决策，因为云服务以市场必须由一个相应的固体的商业模式和投资开发和操作（软件科技操作人员）云服务的支持。

2.3.2.1.1. 云服务模式

There are four cloud service models within the context of the IBM Cloud Computing Reference Architecture - Infrastructure-, Platform, Software- and Business-Process-as-a-Service.

在IBM CCRA中设计了四种云服务模式：基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS）和业务过程即服务（BPaaS）。

IaaS, PaaS and SaaS are defined according to the "NIST Definition of Cloud Computing" [7]. There is an IBM-specific definition of BPaaS since that is not defined by the NIST.

"NIST 云计算定义"[7]中定义了IaaS、PaaS、SaaS，但NIST中未定义BPaaS，BPaaS是IBM中特殊定义的。

Since this is often a point of confusion it is important to note that across all cloud service models the definition is determined by the management scope covered by the provider.

因为这往往是一个混乱的点很重要，请注意跨所有云服务模型的定义由管理范围涵盖由提供程序。

For example, in IaaS "the consumer does not manage or control the underlying cloud infrastructure […]", in PaaS "the consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, or storage […]", etc.. So this essentially about the tasks the operations staff of the provider takes on, it is not about the virtualization technology being used. For example, it\'s possible to use hypervisor-level virtualization to realize PaaS, SaaS or BPaaS.

例如，在云计算模式将"消费者不管理或控制云的底层基础架构[…]"，在PaaS"消费者不管理或控制云的底层基础结构、网络、服务器、操作系统或存储[…]"等……这实质上是有关任务的提供程序的操作人员就有了，所以它不是有关正在使用的虚拟化技术。例如，它是可以使用虚拟化管理程序级别实现PaaS、软件即服务或BPaaS。

2.3.2.1.1.1. 基础设施即服务(IaaS)

"The capability provided to the consumer is to rent 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 select networking components (e.g., firewalls, load balancers)."[7]

"提供给消费者的能力就是租用处理、存储、网络和其他基本的计算资源，消费者在任何地点都能够部署和运行任意的软件，它可以包括操作系统和应用程序。消费者不用去管理或控制云底层的基础架构，但可以控制操作系统、存储、部署的应用程序，和有能力选择网络组件（例如，防火墙、负载平衡器）。"[7]

2.3.2.1.1.2. 平台即服务（PaaS）

"The capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created applications using programming languages and tools supported by the provider (e.g., java, python, .Net). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, or storage, but the consumer has control over the deployed applications and possibly application hosting environment configurations." [7]

"向消费者提供的能力就是将用户创建的云应用程序部署到云基础架构上，应用程序使用支持的编程语言和工具来创建（例如，java、python 、.Net）。消费者不用去管理或控制云的底层基础结构、网络、服务器、操作系统或存储，但消费者可以对已部署的应用程序和应用程序宿主环境配置进行控制。"[7]

2.3.2.1.1.3. 软件即服务（SaaS）

"The capability provided to the consumer is to use the provider\'s applications running on a cloud infrastructure and accessible from various client devices through a thin client interface such as a Web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings." [7]

向消费者提供的功能是使用该提供程序的应用程序通过一个瘦客户端界面如Web 浏览器（例如，基于web 的邮件）运行云基础架构，可从不同的客户端设备访问。消费者不会不管理或控制云的底层基础结构、网络、服务器、操作系统、存储或甚至单个应用程序的功能，用有限的特定于用户的应用程序配置设置的可能是个例外。

Software-as-a-Service is also referred to as Applications-as-a-Service since SaaS is essentially about providing applications as a service (vs. software in general). This also includes content services (e.g. video-on-demand) and higher value network services (e.g. VoIP) as typically encountered in communication service provider scenarios.

软件作为服务也称为应用程序作为服务因为SaaS 基本上是作为一种服务（而不是一般的软件）提供的应用程序。这也包括内容服务（如视频点播）和高价值网络服务(例如VoIP)，通常遇到的通信服务提供商方案。

2.3.2.1.1.4. 业务流程即服务（BPaaS）

"Business process services are any business process (horizontal or vertical) delivered through the Cloud service model (Multi-tenant, self-service provisioning, elastic scaling and usage metering or pricing) via the Internet with access via Web-centric interfaces and exploiting Web-oriented cloud architecture. The BPaaS provider is responsible for the related business function(s)." [Source: IBM MI and IPR definition bridge between Gartner and IDC, Aug 19, 2010]

"是业务流程服务任何业务流程（水平或垂直）通过因特网访问通过以Web 为中心的接口和开发面向Web 的云体系结构与通过云服务的模型（多租户、自助服务的资源调配、弹性缩放和使用计量或定价）。BPaaS 提供程序是负责相关的业务功能。[来源：IBM MI 和知识产权定义桥之间Gartner、IDC，2010 年8 月19 日]

Examples are processes for employee benefit management, business travel, procurement or also IT-centric processes such as software testing (where the entire testing process including testing staff is provided as an externally hosted cloud service).

例子是员工的过程中受益管理、商务旅行、采购或还以信息为中心的流程，如软件测试（包括测试员工的整个测试过程提供作为外部托管的云服务）。

2.3.2.1.2. 云服务创建&生态系统

It is very important to understand the relationship between a cloud service and the artifacts which can be developed based on and within the boundaries of an ecosystem-focused IaaS or PaaS cloud service. Bringing any cloud service to market requires corresponding pre-investment, along with respective metering & charging models in support of the corresponding business model. For example, Amazon EC2 is an eco-system focused IaaS cloud service. The eco-system artifacts in EC2 are VM images. EC2 allows uploading newly created VM images and charging for these VM images. However, each VM instance inherits almost all technical and business decisions already made by Amazon when they decided to take EC2 to market for a specific price-point: Each VM on EC2 is running based on the availability & performance SLAs as defined by EC2, the metrics which can be used to charge for VMs are the ones defined by EC2, the management actions (start, stop, reboot, etc.) consumers can perform on the image are the ones pre-defined by EC2, etc. The fact that Amazon nails down all these characteristics has a very good reason as each characteristic has implications on the costs for offering EC2 - therefore making the characteristics flexible to artifact developers is not possible as it would be very hard to make the corresponding costs flexible and by that very hard to predict.

它是非常重要的了解云服务和可供发展的工件之间的关系基于和注重生态系统的云计算模式将或PaaS 云服务的范围内。将任何云服务推向市场，需要相应的前期，随各自计量科技收费模式的相应的业务模型的支持。例如，亚马逊EC2 是生态系统集中云计算模式将云服务。生态系统项目中EC2 VM 映像。EC2 允许上传新创建的VM 映像和收费，这些VM 映像。但是，每个虚拟机实例继承几乎所有的技术和业务决定，当他们决定要EC2 市场的具体价位已经由亚马逊：EC2 上的每个虚拟机上正在运行基于可用性科技性能Sla 所界定EC2可以用来收费的虚拟机是由EC2 定义度量，操作（开始、停止、重新启动、等) 的消费者可以在图像执行的管理是EC2 等的预定义的。亚马逊钉下所有这些特性的事实有一个很好的理由，如每个特性的成本提供EC2 上有影响--因此使得特点灵活工件开发商是不可能将会是很难作出相应的费用灵活和，很难预测。

This illustrates that defining and delivering a cloud service requires nailing down all corresponding functional and non-functional requirements. The artifacts developed on top of an ecosystem-focused cloud service have then only very minimal room to change how these functional and non-functional requirements are addressed. Note that this is not to be viewed as something negative, but rather as something very positive from an eco-system perspective - it is a core value proposition of eco-system focused cloud services to provide pretty strict guidelines with respect to how they can be exploited as this is the main factor driving a reduction in cost of artifact development. The easier it is to develop artifacts for such a cloud service, the more likely the cloud service is successful.

这说明该定义，并提供云服务的要求，钉下所有相应的功能性和非功能性要求。注重生态系统的云服务的基础上制定的文物有然后只是很小的房间，更改这些功能性和非功能性的需求如何处理。请注意这并不是被看作是负面的但作为一些非常积极的生态系统视角--而是核心价值主张生态系统集中云服务的提供相当严格的准则，对如何他们可以利用，这是在项目开发成本推动减少的主要因素。它是发展工件的云服务，就越有可能云服务是成功就越容易。

As a summary, it is important to note that there is a difference between developing cloud services as a very conscious technical and business decision vs. developing artifacts on top of eco-system focused cloud services prescribing the boundaries for how these artifacts can run.

为摘要，请务必注意有非常清楚的技术和业务决策，与发展中国家工件订明如何运行这些构件可以为边界的生态系统集中云服务的基础上发展云服务的区别。

Note that sometimes the concept of a "Cloud Service" is also referred to as a "Cloud Service Product".

注意"云服务的概念，有时也被称为云服务产品。

2.3.2.2. 基础设施

图4: IBM CCRA - 基础设施明细

"Infrastructure" represents all infrastructure elements needed on the cloud service provider side, which are needed to provide cloud services. This includes facilities, server, storage, and network resources, how these resources are wired up, placed within a data center, etc. The infrastructure element is purely scoped to the hardware infrastructure, therefore it does not include software running on top of it such as hypervisors (hypervisors are generally specific to an IaaS offering and therefore belong to that particular cloud service). Consequently it also does not include any virtualization management software.

"基础结构表示基础设施所有的元素需要在云服务提供商方面，所需提供云服务。这包括设施、服务器、存储和网络资源，这些资源如何连结起来，放在数据中心等。基础架构元素纯粹限于硬件基础设施，因此它不包括如系统管理程序（系统管理程序通常是专门为云计算模式将发行和因此属于该特定云服务）上运行的软件。因此它也不包括任何虚拟化管理软件。

The decision whether the infrastructure is virtualized or not depends on the actual workload characteristics to be run on the respective infrastructures: For many workloads (e.g. compute & storage as-a-Service) it is very convenient to virtualize the underlying infrastructure, especially since virtualization enables some use cases which can basically not be realized with a physical infrastructure (e.g. all use cases related to image management or dynamic scaling of CPU capacity as needed). For other workloads (e.g. analytics/search) it is required to have maximum compute capacity and use 100\'s or 1000\'s of nodes to run a single specialized workload. In such cases a non-virtualized infrastructure is more appropriate. As mentioned in 2.3.2.1, this is not a violation of the architectural principles postulating as much as possible commonality across cloud services: While maximum commonality is a core architectural principle, it is allowed to have different infrastructure architectures per workload category. For example, a collaboration, web and infrastructure workload requires a different underlying infrastructure than an HPC or highly transactional workload. However, a requirement in any case is that all of these infrastructure components get managed from a single, central CCMP and CCMP has the ability to place instances of each cloud service on the corresponding infrastructure (or IaaS service instance, in case a SaaS instance is not directly running on an infrastructure but leverages a IaaS cloud service as an alternative sourcing model).

基础设施是否虚拟化或不取决于实际工作量特征，在各自的基础设施上运行的决定：对于很多的工作负载（如计算科技存储作为服务) 非常方便，虚拟化基础的基础设施，特别是因为虚拟化使一些，基本上可以与有形基础设施（例如，全部使用相关的情况下不会实现的使用案例图像管理或动态缩放的CPU 容量根据需要）。其他工作负荷（例如分析/搜索）它是需要有最高的计算能力和运行单个的专门工作负荷使用上百或上千个节点的甩在了身后。在这种情况下更适合非虚拟化基础设施。As mentioned in 2.3.2.1, 这不是违反了一样可能共同确立跨云服务的体系结构原则：时最大的共性是一项核心建筑原则，它允许有不同基础设施的体系结构，每个类别的工作量。例如，协作、网络和基础设施的工作量需要不同的底层基础架构，比高性能混凝土或高事务性工作负载。但是，要求在任何情况下是所有这些组件管理从单一、中央CCMP 和CCMP 的基础设施，每个云服务的实例放在相应的基础设施的能力（SaaS 实例不是直接在基础设施上运行，但利用云计算模式将云服务的情况下，云计算模式将服务实例，或替代采购模式）。

The less variance the infrastructure has, the more it caters to the standardization needs of a cloud environment. Minimal variance on the infrastructure side is critical for enabling the high degrees of automation and economies of scale which are base characteristics of any cloud environment. However, it has to be acknowledged that in many installed cloud computing environments (specifically private clouds) there are different workloads to be provided as a cloud service and each of these workloads might have special infrastructure needs and might need to support different SLAs. So although the ideal case is total homogeneity on the infrastructure side, it is important to note that there will cloud installations with a few variants in the infrastructure elements (e.g. different HW platforms).

少一方差基础结构的更是迎合云的环境的标准化需求。在基础设施方面的最小方差是自动化的实现高程度和规模经济的基本特征的任何云环境的关键。不过，它不得不承认许多安装云计算环境（特别是私人云) 有不同的工作负载，以作为云服务提供和每个这些工作负荷可能会有特别的基础设施需求，并且可能需要支持不同的Sla。那么理想情况是在基础设施方面的总均匀性，虽然很重要地注意到，有云的基础结构元素（例如不同硬件平台）中的几个变量具有安装。

The infrastructure is managed by the OSS as part of the CCMP, whereas the CCMP by itself is also running on the infrastructure.

基础设施被管理的开放源码软件CCMP，作为而CCMP 本身也正在运行的基础结构。

Note: The physical existence of a virtualized infrastructure on the cloud service provider side is not mandatory, since it is also possible for a cloud service provider to consume infrastructure as a service (and the required CCMP) from a different cloud service provider and put higher value cloud services on top. Clearly, the consuming service provider inherits all SLA constraints defined for the consumed cloud service. So depending on the capability to implement SLAs in software or by using other means, improving SLAs beyond what is provided by the underlying cloud service might be hard (admittedly, there are exceptions to this statement, specifically for cloud workloads which have QoS totally realized in software).

注：在云服务提供商端虚拟基础架构的物理存在不是强制性的因为它也是从不同的云服务提供商的服务（和所需的CCMP) 作为消费基础设施和更高价值的云服务放顶云服务提供商可能。很明显，消费的服务提供商将继承为消耗的云服务定义的所有SLA 约束。因此，取决于执行Sla 的软件，或通过使用其他手段的能力，提高超出所提供的基本的云服务的Sla 可能很难（不可否认，也有例外，这项声明，专为云的工作负载，这已完全实现软件中的QoS)。

2.3.2.3. 公共云管理平台(CCMP)

图5: IBM CCRA - CCMP Details

The Common Cloud Management Platform exposes a set of business and operational management focused services (BSS & OSS). These BSS & OSS functions must be exploited by Cloud Services to run within the context of the respective cloud service provider (and the corresponding CCMP installation). Besides OSS and BSS, the CCMP also includes User Interfaces serving the three main roles defined in the CCRA - a Service Consumer Portal to be used by Cloud Service Consumers for self-service delivery & management (the actual cloud service instances are used via a cloud service specific UI, a Service Provider Portal serving Cloud Service Provider internal users & administrators for daily operations and a Service Development Portal used by Cloud Service Creators. CCMP functionality is accessible via APIs exposed by the CCMP-internal components. Note that the architecture described in this work product is agnostic to the actual software products used to implement this architecture.

常见的云管理平台公开了一组的业务和业务管理的集中服务(BSS 科技OSS)。这些星科技开放源码软件的功能，必须利用云到各自的云服务提供商（和相应的CCMP 安装）的上下文中运行的服务。除了开放源码软件、星CCMP 还包括服务商业信贷资料库--用于云服务的消费者的自助服务传递科技管理服务消费门户中定义的三个主要角色的用户接口（实际云服务实例用于通过云服务特定的用户界面为云服务提供商的内部用户科技的日常操作和云服务的创建者所使用的服务发展门户管理员提供服务的服务提供商门户。CCMP 功能是通过由CCMP 内部组件公开的Api 访问。请注意该工作产品中描述的架构是不可知论者用来实现这种体系结构的实际软件产品。

As the name already implies, the CCMP is structured as a platform. Based on the platform nature, the CCMP exposes a set of services which can (and sometimes must) be used within the context of a specific cloud service. The management services exposed by the CCMP to cloud service creators are not to be confused with the cloud services developed by cloud service creators. Cloud Service Creators are strongly encouraged to use the management services provided by the CCMP in order to enable the economies-of-scale required for achieving the extremely high degrees of efficiency associated with any cloud computing environment.

正如名称已经暗示，CCMP 的结构作为一个平台。基于平台性质，CCMP 公开了一组服务，可以和有时必须使用特定的云服务的范围内。由CCMP 云服务创作者公开的管理服务都不能混淆与开发的云服务创作者的云计算服务。强烈建议使用CCMP 所提供的管理服务，以便使经济-的-规模所需的实现与任何云计算环境相关联的效率极高程度云服务的创建者。

As an example, it is required to apply a special audit for any software component having financial impact, which means the component doing billing for the consumption of a cloud service must be audited to be compliant. Since every cloud service requires integration with such financial systems, the effort, cost and complexity associated with such an auditing processes can be very cumbersome. By establishing a single deployment of a billing component - shared amongst multiple cloud services - the complex and time-consuming audit process has to be executed only once and can then be used for any number of cloud services vs. executing a separate audit each time a new cloud service is deployed in an environment without a CCMP. Clearly, this concept of sharing enables economies-of-scale and does not only apply for the billing service of BSS, but for any other management service being part of a CCMP deployment.

作为一个例子，它是须于金融的影响，这意味着做云服务的消费帐单的组件必须审核，符合任何软件组件的专项审计。由于每个云服务需要与这种金融系统的集成，可以很繁琐的努力、成本和复杂性与审计的进程关联。通过建立--多云服务之间共享--一个帐单组件部署一次复杂和耗时的审计过程都必须执行一次，然后可以用于任意数量的云计算服务与无CCMP 的环境中执行每次部署新的云服务的独立审计。显然，这一概念的共享使经济的规模和仅适用的BSS，付费服务，但CCMP 部署的一部分的任何其他管理服务。

The CCMP is defined as a general purpose cloud management platform to support the management of any category of cloud service across I/P/S/BPaaS.

CCMP 被定义为通用云的管理平台，以支持跨越我/P/S/BPaaS 的任何类别的云服务的管理。

The CCMP is split into two main elements - the Operational Support Services (OSS) and Business Support Services (BSS). Historically, the OSS and BSS acronyms have been used in the Telco industry in the context of providing Telco-centric services. Since cloud computing targets a similar scenario - providing services over a network - it feels appropriate to use the same conceptualizations as the Telco industry. However, the cloud services provided in the cloud computing context have a more IT centric nature (e.g. virtual machines, web conferences, etc.) than classical communication services (e.g. dial-tones on a mobile phone).

CCMP 分为两个主要元素--业务支持服务(OSS) 和业务支持服务(BSS)。从历史上看，开放源码软件和BSS 首字母缩写词用在电信行业提供电信为中心的服务的上下文中。自云计算的目标--在网络上提供服务--一个类似的情况它认为适当使用相同的概念，为电信行业。然而，云计算范围内提供的云计算服务有更多IT 中心性质（如虚拟机、web 会议等）比经典的通信服务（例如拨号-音的移动电话上）。

In the classical telco/communication service provider world OSS and BSS are treated as operational / business support system, which implies a kind of monolithic notion of the respective component. In contrast, OSS and BSS are more viewed as a set of operational / business support (self-contained) services in the cloud computing context, which expresses a higher degree of modularity of OSS and BSS. This architectural modularization also makes it possible for cloud service creators to flexibly choose implementations of the various architectural elements being part of CCMP

在古典电信/通信服务提供商世界开放源码软件和BSS 被视为业务/ 业务支持系统，这意味着一种整体概念的相应的组件。与此相反，开放源码软件和BSS 更视为一套业务/业务在云计算方面，它表达的较高程度的开放源码软件和盲源分离的模块化设计的支持（独立）的服务。此体系结构的模块化还可以灵活选择实现CCMP 的一部分的各种建筑元素的云服务创作者

The ideal case from a cost optimization and economies-of-scale perspective is to use as much as possible shared CCMP OSS/BSS functionality across multiple cloud services, but depending on the isolation or time-to-market requirements for certain cloud services this may not be possible. In general, OSS + BSS should be viewed as the (integrated) set of management platform functionality underpinning the operation of any cloud service (similar to middleware being the functional / runtime platform).

理想的情况，从成本优化和规模经济的角度是使用尽可能可能跨多个云服务，共享CCMP OSS/BSS 功能，但取决于隔离或市场的时间要求某些云服务这不可能。一般情况下，开放源码软件+ BSS 应视为支撑任何云服务的运作的管理平台功能（综合）集（类似于中间件的功能/ 运行平台）。

All CCMP functions can be used for the consistent management of cloud services virtualized on any level - be it hypervisor-level, Operating-system level, platform-level or application-level virtualization (see 图below).

CCMP 的所有功能，可以都用于云的一致的管理服务在任何级别--虚拟化将它管理程序级别、-操作系统级别、平台级或应用程序级别的虚拟化（请参阅下面的二房）。

图6: CCMP supports any level of virtualization

A portal is the interface to the external world, whether it is a client, provider or partner. In this RA, there are three different portals which can be decomposed with the same set of components. While we refer to three different portals from an architectural perspective, all three portals could be realized by a single implementation with different access rights and presenting different capabilities depending on who is logged in:

门户是该接口与外部的世界，无论它是客户、供应商或合作伙伴。在此角，有三个不同的门户网站，可以使用同一组组件的分解。虽然我们引用三个不同的门户从建筑的角度来看，所有的三家门户网站可以实现由单个实现具有不同的访问权限，并提出不同的功能取决于登录的用户：

1. Service Consumer Portal: This allows consumer, business managers and administrator to manage their cloud environment in a self-service fashion. 服务消费门户：这使消费者、业务经理和管理员来管理他们的云环境，以自助方式。
   
   The Service Consumer Portal exposes information & functionality for Service Catalog, Service Instance management, User/Entitlement management and Reporting. 服务消费门户网站公开信息科技功能服务目录、服务实例管理、用户/权利管理和报告。
   
   The service consumer portal does not expose cloud service-specific usage functionality - this is covered by cloud service specific UI implementations. For example, the UI for running a web conference via LotusLive, displaying all participants, showing the screen of other participants is not something that would be implemented in the context of the service consumer portal. 服务消费门户网站不公开云使用特定于服务的功能--这受云服务特定用户界面实现。例如，运行web 会议LotusLive，显示所有的参与者，显示在屏幕的其他参与者通过用户界面不是将服务消费门户的上下文中执行。
2. Service Provider Portal: This allows service providers to manage the infrastructure and use the management components included in CCMP. 服务提供商门户：这允许服务提供商管理基础架构，并使用包含在CCMP 的管理组件。
3. Service Development Portal: This supports cloud service creators in creating new cloud services. 发展门户服务：这支持云服务创作者在创建新的云计算服务。

Similar to OSS & BSS, the Service Consumer UI/Portal components are split into a platform- / cloud service independent part and cloud service-specific UI definitions, which can be plugged into that base framework.

开放源码软件科技BSS 类似，服务消费者UI/门户组件被拆分为平台-/ 云服务独立部分和云特定于服务的用户界面定义，可以插入到该基地的框架。

2.3.2.3.1. 商业支持服务（BBS）

图7: CCMP RA - BSS Details

Business Support Services represents the set of business-related services exposed by the CCMP, which are needed by Cloud Service Creators to implement a cloud service.

业务支持服务代表业务相关的服务由CCMP，公开实施云服务需要的云服务创作者的一组。

The motivations for using these commonly defined BSS functions are the same as the ones for reusing all other services defined in the context of CCMP:

使用这些通常定义的BSS 函数的动机是相同的重用CCMP 的上下文中定义的所有其他服务：

• Using standard component services will reduce the unique development required, reducing development and support costs both使用标准组件服务会减少独特的发展需要，降低了开发和支持成本两个
• Using standard components will result in a cloud service more likely to be compatible with other cloud services, providing the client with even more economies of scale and efficiencies使用标准组件将导致更可能是与其他云服务，提供更多经济规模和效率的客户端兼容的云服务
• Standard components and User Interfaces will reduce the complexity, simplify operations and make the cloud solutions easier to use (more consumable) 标准组件和用户界面将降低复杂性、简化操作，并使云解决方案更易于使用（更多耗材)

Like any other component of the CCMP, the BSS is generic across all cloud service types and can be configured to behave appropriately in the context of the managed cloud services. As an example, the billing service of the CCMP BSS must be usable to do billing for the consumption of virtual machines (IaaS), a multi-tenancy capable middleware platform and for collaboration services like LotusLive (SaaS). This drives the need for a proper platform-level definition of all BSS components and exploitation artifacts enabling cloud service creators to prime the behavior of each BSS component in a cloud service specific fashion.

像任何其他组件的CCMP，BSS 跨所有云服务类型是通用的并可以配置为在托管的云服务的上下文中使用合适的。作为一个例子，CCMP BSS 付费服务必须可用做multi-tenancy 能够中间件平台的虚拟机(IaaS)，消费和协作服务，如LotusLive (SaaS) 的帐单。此驱动器需要适当的平台级定义的所有的BSS 组件和开发项目启用云服务创作者以素云服务的具体方式每个BSS 组件的行为。

2.3.2.3.2. 业务操作支持服务（OSS）

图8: CCMP RA - OSS Details

Operational Support Services represents the set of operational management / technical-related services exposed by the CCMP, which are needed by Cloud Service Creators to implement a cloud service.

业务支持服务表示设置的操作管理/ 技术相关公开的CCMP，实施云服务需要的云服务创造者的服务。

Many management domains shown in the OSS can also be encountered in traditionally managed data centers (e.g. monitoring & event management, provisioning, incident & problem management, etc.) while other components are new and pretty specific to the degrees of automation and efficiency associated with clouds (e.g. service automation, image lifecycle management). Particularly for the \'traditional\' management domains it is important to note that conceptually they are the same in the cloud world and in the traditional world, whereas in a cloud world these domains are generally implemented in radically different ways taking advantage of the high degrees of homogeneity in a cloud. For example, a traditionally managed data center is implemented in a way that an incident gets raised if a physical server fails, a ticket gets opened, assigned to an admin (maybe 2 AM in the morning), after some time an escalation takes place if the admin hasn\'t resolved the ticket until then, etc. In contrast, there is also incident & problem mgmt for typical VMaaS cloud services, whereas here a broken physical machine is just left broken on the floor until some later point of time and the virtual machines which have been running on that physical machine are brought up on another one. Of course, this is only possible if the availability SLA associated with the VMaaS cloud service permits such approaches. Both scenarios described above address incident & problem management, but in radically different ways and for radically different labor costs and SLAs. A similar "cloudified" perspective exists also for most other OSS components.

开放源码软件所示的很多管理域也可以将遇到的传统托管的数据中心（例如监测科技事件管理、资源调配、事件科技问题的管理等），而其他组件是新的和非常具体的自动化和效率与云（例如服务自动化相关联的程度生命周期管理的图像）。特别是对\'传统\' 管理域很重要，请注意从概念上来说它们相同的云世界和在传统的世界中，而在云的世界中，这些域一般实施完全不同的方式，利用中云的同质化程度高。例如，将传统托管的数据中心实施获取引发事件的方式一张票一台物理服务器出现故障，如果获取开启时，分配给管理员（也许早上2 AM)，升级需要一段时间后放置如果管理员还没有解决的票才等等。与此相反，也是事件科技问题管理的典型VMaaS 云服务，而这破碎的物理机只是离开破碎直到一些稍后的时间点，已在该物理计算机上运行的虚拟机另一个成长在地板上。当然，这是唯一的可能，如果VMaaS 云服务许可证与这种方法相关联的SLA 的可用性。这两种情况，上述地址事件科技管理问题，但截然不同的方式和截然不同的劳动力成本和服务级别协议。类似"cloudified"的角度来看还存在其他大多数的开放源码软件组件。

The platform notion of CCMP obviously also applies to all components defined as part of the OSS: A proper platform-level definition of all OSS components and exploitation artifacts enabling cloud service creators is needed to prime the behavior of each BSS component in a cloud service specific fashion.

CCMP 平台概念显然也适用于所有的组件定义为开放源码软件的一部分：需要适当的平台级定义的所有开放源码软件组件和开发项目启用云服务创作者素云服务的具体方式每个BSS 组件的行为。

2.3.2.4. 安全性、灵活性、性能和消费性

图9: CCRA - Security, Resiliency, Performance & Consumability Details

Security, Resiliency, Performance & Consumability are cross-cutting aspects spanning the CCMP, the hardware infrastructure and Cloud Services. These non-functional aspects must be viewed from an end-to-end perspective including the structure of CCMP by itself, the way the hardware infrastructure is set up (e.g. in terms of isolation, network zoning setup, data center setup for disaster recovery, etc.) and how the cloud services are implemented.

安全、可恢复性，性能科技Consumability 是交叉跨越CCMP、硬件基础设施和云服务的方面。这些非功能性方面的问题，必须从本身，包括CCMP 结构的硬件基础设施设置的方式的端到端角度（如的隔离，网络分区设置，数据中心安装的灾难恢复等）和云计算服务如何实现的。

2.3.3.云服务创建者

2.3.3.1. 服务开发工具

图10: CCRA - 服务创建明细

Service Development Tools are used by the Cloud Service Creator to develop new cloud services. This includes both the development of runtime artifacts and management-related aspects (e.g. monitoring, metering, provisioning, etc.). "Runtime artifacts" refers to any capability needed for running what is delivered as-a-service by a cloud deployment. Examples are JEE enterprise applications, database schemas, analytics, golden master virtual machine images, etc.

云服务创建者使用服务开发工具来开发新的云服务，包括开发运行时工件和管理相关方向的（如监测、计量、配置等）。"运行库项目"是指任何所需的运行什么由云部署作为服务的能力。巨企业应用程序、数据库架构、分析、金主虚拟机图像、等的例子。

In the context of a particular infrastructure- or platform-as-a-service offering, there may also be tooling to develop artifacts which are specific to the particular cloud service. For example, in the context of a VM-as-a-service offering, it is possible to use image creation tools for developing images that can be deployed in the context of the VM-aaS cloud service. As another example, in the context of a platform-aaS cloud service there may be application development tooling to develop an application which can be deployed on the respective platform.

中的特定基础设施或平台-作为-服务提供方面，那里可能也模具开发特定于特定的云服务的构件。例如，在VM 作为服务提供方面，有可能使用图像创建工具开发可以部署在VM 原子云服务的上下文中的图像。作为另一个示例，在平台原子云内服务有可能会开发应用程序，可以在各自的平台上部署应用程序开发工具。

3. 云计算服务参考架构（CCRA）:架构原则和相关指导

The following top-level architectural principles guide the definition of any cloud implementation, with a focus on delivery & management of cloud services.

以下的顶级建筑原则指导定义的任何云实施中，重点是提供科技云服务的管理。

The architectural principles in this chapter are focused on the CCMP element of the overall architecture as this element is required consistently, independent of which cloud service is implemented, delivered & managed:

这一章中的建筑的原则是元素聚焦于CCMP 总体架构此元素是要求一致，独立的实施、交付科技管理的云服务：

1. Design for Cloud-scale Efficiencies: When realizing cloud characteristics such as elasticity, self-service access, and flexible sourcing, the cloud design is strictly oriented to high cloud scale efficiencies and short time-to-delivery/time-to-change. ("Efficiency Principle")

云升缩效率设计：实现云特征如弹性、自助服务的访问，以及灵活的采购，云设计时严格面向高云规模效率和短的时间为交付/时间而变。效率原则

2. Support Lean Service Management: The Common Cloud Management Platform fosters lean and lightweight service management policies, processes, and technologies. ("Lightweightness Principle")

支持精益服务管理：常见的云管理平台促进精益和轻量级的服务管理策略、过程和技术。Lightweightness 原则

3. Identify and Leverage Commonalities: All commonalities are identified and leveraged incloud service design. ("Economies-of-scale principle")

识别和利用共性：标识所有的共同点并将其利用云服务的设计中。规模经济的原则

4. Define and Manage generically along the Lifecycle of Cloud Services: Be generic across I/P/S/BPaaS & provide \'exploitation\' mechanism to support various cloud services using a shared, common management platform ("Genericity").

定义和管理云服务的生命周期：在我/P/S/BPaaS 是通用科技提供\'剥削\' 的机制，以支持各种云服务使用一个共享、共同管理平台（泛型）。

These principles can be summaries as ELEG (= Efficiency, Lightweightness, Economies-of-scale, Genericity).

这些原则可为ELEG （= 效率，Lightweightness，经济双的尺度，泛型）的摘要。

It is the objective of this chapter to refine these top-level principles into memorable and actionable guidelines for cloud architects and developers.

这是令人难忘的、可操作的指导方针调整这些顶级的原则，云建筑师和开发人员的这一章的目标。

3.1. CCRA特定架构原则

3.1.1.表示架构原则的起源

The notion of architectural principles is commonly used in the enterprise architecture community. The Open Group Architecture Framework (TOGAF), for instance, provides a definition [1]. There is defined: Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission. In their turn, principles may be just one element in a structured set of ideas that collectively define and guide the organization, from values through to actions and results.

架构原则的概念很大程度上常用在企业架构社区中。Open Group的架构框架(TOGAF)，例如提供了定义[1]。定义到：原则是一般规则和指导方针。那里定义：原则是一般规则和指导原则，目的是能够持久和很少的修改，告知并支持的方式组织着手履行它的使命。反过来，原则可能是一套结构的集体定义和指导本组织，通过行动和结果值的想法的其中一环。

Depending on the organization, principles can be defined and established on different levels. Architecture principles are a subset of IT principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of the enterprise architecture.

取决于组织中，可以定义和在不同层次上建立原则。建筑设计原则是体系结构工作有关系的IT 原则的子集。他们整个企业，反映一定程度的共识和体现的精神和思想的企业体系结构。

In contrast to an architectural decision, an architectural principle is an overarching guideline or paradigm driving architectural decisions on a more granular level (which reflects the enforcement of an architectural principle). Architecture standards as well are more granular than architecture principles and describe technical specifications.

建筑的决定，相对于建筑的原则是首要的指引或驾驶更精细的级别（它反映了建筑方针的执法) 体系结构决策的范式。建筑标准以及更细比建筑设计原则和描述的技术规范。

3.1.2.原则1：云规模设计

The first CCRA principle is the overarching policy governing the architecture, design, and implementation efforts:

第一条CCRA原则是：治理架构、设计和实现工作是首要政策。

Architectural Principle 1 ("Efficiency Principle"):

架构原则1（"效率原则"）

Whenrealizing cloud characteristics such as elasticity, self-service access, and flexible sourcing, the cloud design is strictly oriented to high cloud scale efficiencies and short time-to-delivery/time-to-change.

实现云特征如弹性、自助服务式访问，以及灵活的来源订购，云设计时严格的面向高云规模效率和短时间交付/短时间变动。

动机和优点

The objective of cloud computing in general and CCRA in particular is to enable changes in orders of magnitude with respect to operational efficiencies (compared to traditional IT environments); hence, any design activity must be directed with this top-level principle and policy in mind.

云计算一般和数据库的目标特别是启用对运营效率（相对于传统的IT 环境）；数量级的变化因此，任何设计活动必须向此顶级的原则与政策的考虑。

Operational and maintenance efforts and costs with today\'s IT landscape are too high. The complexity and interdependencies within the IT landscape is too high. IT operations are by far too much based on manual activities and procedures. The time needed to change an existing IT system or to provide a new IT system is longer than the business now can accept.

操作和维护的努力和当今IT 业前景与成本都太高。过高的复杂性和IT 环境中的相互依赖性。IT 运营用得太多了基于手动活动和程序。若要更改现有的IT 系统，或提供一种新的IT 系统的所需的时间是长于业务现在可以接受。

结果和影响

To really implement a cloud following this principle with that high level of efficiency and flexibility, a very high degree of standardization (i.e. minimal variety in the data center with respect to numbers of server, storage, network technologies, operating systems & versions, middleware products, applications, etc.) is required to enable high degrees of automation. The higher the degree of standardization / minimization of variety is, the better automation can be realized (assuming a well-integrated and interoperable set of management components). Obviously, in a highly homogeneous public cloud data center this can be achieved in a better way compared to private cloud enterprise data centers running a variety of workloads each of them having different requirements, so there is typically a trade-off between degree of standardi­zation and level of efficiency.

要切实执行这一原则，高效率和灵活性的程度非常高的标准化（即最小品种在数据中心的服务器、存储、网络技术、操作系统科技版本号码云、应用程序、中间件产品等等。)是的就需要启用高程度的自动化。标准化程度越高/ 最小化的品种是，可实现更好的自动化（假设一套完全集成和可互操作的管理组件）。很明显，在高度同质化的公共云才能更好地相比，他们每个人都运行多种工作负载的私人云企业数据中心的数据中心有不同的要求，所以通常是standardi 研究的程度以及效率之间的权衡。

All IT services have to be defined with the highest degree of standardization and documented in a com­pre­hen­sive IT service catalogue.

所有IT 服务必须定义具有最高程度的标准化，并记录在com 预母鸡综合服务目录。

For each cloud service every service request has to be described and implemented to be run on an automated basis.

A cloud management platform has to be designed and implemented that is able to manage the status of every operational task and all (typical known) operational deviations (aka incidents).

每个云服务每一个服务请求，以描述和实施自动化的基础上运行。云管理平台已设计和实施，能够管理的每个操作的任务和所有（典型已知）业务偏差（也称为事件）的状态。

范例

Infrastructure costs can be significantly reduced if their utilization is increased. That is quite easy to be done by leveraging the degree of standardization of the infrastructure components as well as the whole IT services. The IT services are run on a standardized and shared IT environment that keeps IT costs low.

如果他们利用增加，可以大大减少基础架构成本。这是标准化的很容易通过利用基础结构组件，以及整个IT 服务的程度。IT 服务标准化和共享的IT 环境，让它成本低上运行。

Deliveries as well as change tasks for example today are too often based on manual work and coordination. In a cloud environment most of these typical tasks can be automated; manual work is only necessary in case of exceptional situations. Keeping manual effort and therefore labor costs low is achieved by a high level of automation.

交货，以及更改任务，例如今天太通常基于手动工作和协调。在云环境中可以自动的大多数这些典型的任务；只有在特殊情况下的情况下有必要手动工作。保持手动操作，因此劳动力成本低，被通过自动化程度高。

3.1.3.原则2：支持精简服务管理

Cloud computing will only be able to deliver on its promises if a paradigm shift for data center and service management design takes place, including a redesign of management processes and related tools. This principle is an implication of principle 1:

云计算将只能够履行其承诺，如果数据中心和服务管理设计的范式转换发生，包括重新设计的管理流程和相关的工具。这一原则是1 原则的含义：

Architectural Principle 2 ("Lightweightness Principle"):

架构原则2（"轻量级原则"）

The Common Cloud Management Platform fosters lean and lightweight service management policies, processes, and technologies.

CCMP鼓励精益和轻量的服务管理策略、过程和技术

动机和优点

Today\'s service management processes are by far too much based on manual and individual work and far away of being lean and automated.

今天的服务管理流程是大多数是依赖于人工和个人性的工作，而远离了精益化和自动化处理。

Current service management technologies are not integrated and comprehensive enough to address all global service management functions.

当前服务管理技术不是整合的和全面的，以至于无法解决所有全球的服务管理功能。

结果和影响

All (automated) service management functions need to communicate and deal with status information.

所有（自动化的）的服务管理功能需要传递和处理状态信息。

An overall status and steering function is necessary.

整体状态和指导功能是必要的。

At least a monitoring function on status information is necessary.

至少对状态信息的监测功能是必要的。

The starting point as well as finishing the service delivery should be related to self-service functions

服务交付的启动点及其结束，应当与自助服务功能进行关联。

The operational teams need other skills than today esp. a higher skill level on cloud service delivery.

业务团队需要比今天更多的技能，尤其是在云服务业务的交付上需要更高的技能。

Existing implementations of IT Service Design (as of ITIL v3) might have to be re-designed to deliver IT services conform to the CCMP.

现有IT服务（作为ITIL v3标准）的设计实现可能要被重新设计发行为符合CCMP标准的IT服务。

New technical service management components (i.e. beyond traditional enterprise data center management) are required in CCMP implementations, e.g., service automation management or image lifecycle management. Not all Commercially-Of-The-Shelf (COTS) products e.g. might be able to support CCMP as defined in the CCRA without customization or extensions. In those cases it is critically important to understand how the existing management tools have to be used in novel/different ways to achieve cloud-scale efficiencies. Technical variability should be limited so that management can be streamlined and automated as much as possible. The degree of achievable efficiency also depends on interoperability & integration amongst the set of management tools being used.

在CCMP的实现中需要新技术的服务管理组件（即超越传统企业数据中心管理），例如，服务自动化管理或图像生命周期管理。不是所有的商用现成品或技术（Commercially-Of-The-Shelf，COTS）可能能够支持CCMP，在CCRA中定义且无需定制和扩展。在这种情况下，了解现有的管理工具必须使用novel/different方式来如何实现云规模效率是极其重要的。技术变化应该有限制，以便在管理上尽可能的简化和自动化尽。效率的实现程度还取决于被使用的管理工具之间的互操作性与整合。

范例

One frequently cited example is the incident, problem, and change management approach taken by several public cloud implementations.

一个经常引用示例是事件、问题和采取的几个公共云实现的变化管理办法。

Let us take as an example that a cloud service consumer reports that a virtual machine has gone down and that the root cause of the problem is a hardware failure. In the traditional IT Infrastructure Library (ITIL) approach to change management, the help desk would alert a technician who would repair the faulty hardware as soon as possible. This guarantees a high quality of service (here: time-to-repair), but is rather costly. In a cloud scenario, the broken hardware/hypervisor would just be disabled and when users start up their virtual machine again (because it failed due to the broken hardware/hypervisor) they are brought up on one of the remaining healthy hypervisors. All faulty hardware is replaced or repaired on a regular base (e.g., monthly) vs. repairing it immediately whenever it fails. Due to the higher amount of automation, less admin staff is required to provide the service. This is an example for dramatically increasing the efficiency in operating the data center, which should serve as an inspiration for novel ways of dealing with old problems, leveraging new technology approaches and building on high degrees of standardization and automation.

让我们来为例，云服务消费者报告下降了虚拟机和问题的根本原因是硬件故障。在传统的IT 基础架构库(ITIL) 方法更改管理，帮助台会提醒技术人员会尽快修复硬件故障。这可以保证高质量的服务（在这里：维修时间)，但比较昂贵的费用。云的情况下，在损坏的硬件/管理程序将只被禁用并当用户启动的虚拟机再次（因为它由于损坏的硬件/管理程序失败）他们都长大剩余的健康管理程序之一。所有硬件故障是更换或定期的基础上修复（例如，每月）与失败时，立即修复它。由于更多的自动化，更少的管理人员被需要提供服务。这是一个例子，极大地提高了操作的数据中心，应作为灵感的老问题的处理、利用新的技术途径和建立标准化和自动化程度高的新型方法的效率。

Note that this example shouldn\'t be viewed as the \'authoritative\' way of dealing with hardware failures in all cloud implementations: Of course, depending on the SLAs of the actual workload running on the cloud and the underlying hardware it might well be that a different approach for dealing with such problems is more appropriate.

请注意，此示例不应该被看作是\'权威\' 云的所有实现硬件故障的处理方式：当然，取决于云和底层的硬件上运行它的实际工作量的Sla 很可能不同的方法来处理这类问题是更合适。

Fundamental restructuring and streamlining of IT management processes is required to maximize the elimination of manual data center management tasks. Depending on the degree of optimization, this might also require deviating from well-established standards for traditional data center management (e.g. ITIL).

基本结构调整和优化it 管理流程需要最大限度地消除手动数据中心管理任务。取决于优化的程度，这可能还需要偏离既定标准，传统的数据中心管理(例如ITIL）。

This principle is not about gradual improvements of data center management processes as it is driven by many data center optimization initiatives. The reason for this is that with such an approach of gradual improvement it would only be possible to achieve gradual improvements of 10-15%, which does not fit to the order-of-magnitude improvements as they are targeted from the perspective of cloud-like data center management. Along these lines, this principle is also not about the 1:1 automation of existing data center management processes, as this would mostly mean transforming existing heavyweight processes into automated heavyweight processes, whereas actually a fundamental shift in data center management processes is required. Such a paradigm shift can be achieved by using most of existing service management tools (enriched by a few, new & distinguishing tools), but they must be used in very different ways.

这一原则不是逐步改善的数据中心管理流程，它由许多数据中心优化措施。原因是，这样的做法，逐步改进，才可能实现的10-15%，并不适合的数量级改善他们的目标是从类似云计算数据中心管理的角度来看，逐步改善。这些方针，这一原则也不是有关的现有数据1：自动化中心管理流程，这通常意味着改造现有重量级加工成自动化的重量级的过程，而实际上根本的转变，在数据中心管理过程是需要。通过使用大多数的现有服务的管理工具（按几下，丰富的新科技识别工具），要做到了根本性的转变，但他们必须使用非常不同的方法。

The main levers for massively driving down operational costs are elimination of tasks which are not needed any more due to limited scope of managed (e.g. in compute cloud only managing up to and including the hypervisor) and optimization (e.g. not immediate repair of a failed physical machine enabled by automated restart of crashed VMs or nodes or automating the service activation process, which is typically very time- and cost-intensive in traditional outsourcing environments). The basic thought is the more tasks get eliminated, and the more homogenous a data center is, the easier it becomes to highly automate any type of manual management task and drive down mgmt costs & delivery/change times significantly as a result of that.

为大幅降低运营成本的主要杠杆是消除的任务，而无需再因有限范围的（如在计算云只达管理，包括管理程序）管理和优化（如不立即修复失败的物理计算机启用了自动重启崩溃的虚拟机或节点或自动化服务激活过程，即通常非常时间和成本密集型传统外包环境中）。基本思路是被消灭，更多的任务，以及数据中心是越均匀，便高度自动化的任何类型的手动管理任务并降低了管理成本科技提供/更改时间大大的结果，就越容易。

Note that even for scenarios where management scope is not reduced (i.e. mgmt is still done up to the application layer), it is possible to eliminate management tasks by leveraging the sourcing options offered via cloud computing.

注管理范围不减少了的情况下，甚至(即管理仍是应用程序层高达)，它是可以通过利用所采购的选项，通过提供消除管理任务云计算。

For example, a cloud service provider offering SaaS can eliminate his management tasks for the underlying hardware infrastructure or for maintaining the required management software by retrieving the compute resources or the management functionality as-a-Service. Consequently the corresponding labor costs get eliminated on the SaaS-provider side while he has to pay the compute or mgmt-aaS provider for the respective service. However, since the underlying service provider is able to specialize in providing a very specific service and can distribute costs for providing that across multiple tenants (àeconomies of scale), the overall costs for the SaaS-provider might well come down. Of course, this also works within a cloud service provider environment where a higher-level service can build on a lower-level service, management being highly optimized for each of them.

例如，提供SaaS 云服务提供商可以消除他的管理任务的底层硬件基础架构或通过检索计算资源或管理功能作为服务维护所需的管理软件。因此相应的劳动成本被消灭SaaS 供应商方面，虽然他不得不支付各自服务费用的计算或管理原子的提供程序。但是，因为基础服务提供程序能够专注于提供非常特定的服务，并可以分发费用提供的跨多个住户(的规模经济，SaaS 提供商的整体成本可能也下来。当然，这也更高级别的服务能够在较低级别的服务，为他们每个人都被高度优化的管理的云服务提供商环境中工作。

3.1.4.原则3: 识别和利用共性

The third principle reminds us that the first \'C\' in CCMP does not stand for \'Cloud\', but for \'Common\':

第三项原则提醒我们第一次在CCMP 中的\'C\' 不\'云\'，而是\'常用\'：

Architectural Principle 3 in Common Cloud Management Platform ("Economies-of-scale Principle"):

建筑原则3 中常见的云管理平台规模经济的原则：

All commonality are identified and leveraged in cloud service design.

确定所有的公共性并将其利用云服务的设计中。

动机和优点

Although various and a lot of business as well as technical functions occur in the IT landscape, too many parts are implemented and operated on an individual, separated way. So redundancies that drive complications (as well as complexity) are daily business in the IT. Even some activities to identify commonalities are not established and use within the whole IT organization.

虽然IT 环境中出现的各种和大量的业务，以及技术的功能，太多的部件实施，对个人、分隔的方式运作。所以传动并发症（以及复杂性）的裁员是在日常业务。甚至一些活动，以找出共性没有设立办事处，并使用内整个组织。

Hence, the motivation for this principle is to reuse management/CCMP components and enable economies of scale (with respect to initial standup & operational costs and reduced time-to-market) by sharing a single/common management platform to deliver and manage many cloud services. An exploitation mechanism is required so that various cloud service types - across I/P/S/BPaaS (see also principle 4, section 3.1.5) - can share the same common management platform while having cloud service specific management requirements and scope.

因此，这一原则的动机是规模的重用管理/CCMP 组件并启用（对初始的待机科技运营成本和缩短的面市时间）经济的共享提供及管理多云服务单/常用管理平台。剥削制度是必需的以便各云服务类型--在我/P/S/BPaaS (see also principle 4, section 3.1.5) --可以共享相同的通用管理平台，而云服务具体管理要求和范围。

结果和影响

A more generic design requires more analysis, design, and development effort; it runs the risk of over-engineering (if the expected future requirements and usage scenarios never materialize) and compromising usability (if the responsibility to con图the feature for a specific usage scenario is shifted to the service consumer or the system administrator and the configuration procedure is time consuming and/or difficult to follow). This can be counter productive, particularly in the light of the overarching CCRA principle 1, design for cloud-scale efficiencies.

一种更通用的设计需要更多的分析、设计和开发工作；它运行over-engineering （如果预期未来的需求和使用情况永远不会实现）和损害可用性（如果con图功能的具体使用情况的责任转向服务消费者或系统管理员和配置过程是耗费时间和/或难以理解）的风险。此计数器可云规模效率生产，尤其是在首要的根据信贷原则1、设计。

Another consequence is, that a uniform management API becomes enabled for interactions with different service types and instances.

另一个后果是，具有不同的服务类型和实例的交互变为启用了API 的统一管理。

范例

Metering, monitoring, service automation, management User Interface (UI) components are examples of components with reuse potential - just like any other component which is defined as part of CCMP (if a component cannot be split into a platform aspect and an exploitation aspect, it probably doesn\'t make sense to make it part of CCMP, but treat it as something cloud service specific).

计量、监测、服务自动化、管理用户界面(UI) 组件是潜在的--就像任何其他组件的定义是CCMP 的部分(如果组件不能拆分为一个平台方面和开发方面的重用的组件的示例它可能没有任何意义，使这一部分的CCMP，但把它一样东西云服务具体）。

A counter example is the connection broker in the Desktop Cloud offering: Desktop connections do not exist in any other cloud offering type, so there is not much commonality potential in the design of this particular connection broker (as this component will hardly be reused for other cloud services). Therefore the connection broker would be handled as a management component residing outside the Common Cloud Management Platform, but within the specific context of a Desktop Cloud Service.

计数器示例是在桌面云提供连接经纪：桌面连接不存在于任何其他提供类型，不多通用性潜力很在设计中该特定连接代理（如几乎将其他云服务的重复使用此组件）的云。因此，连接代理会被当作管理组件，居住外常见的云管理平台中，但在桌面云服务的特定的上下文内。

3.1.5.原则4: 在云服务的生命周期中，应该统一定义和管理

A top-level architectural principle for the CCRA requires us to build on the notion of a service lifecycle as a central thought. :

CCRA的顶级架构原则就是需要我们在构造时必须建立"服务生命周期"为中心思想的概念。

Architectural Principle 4 ("Genericity Principle"):

架构原则4（"泛型原则"）：

Cloud services are managed generically along their lifecycle, across I/P/S/BPaaS.

云服务在其生命周期中，应统一管理（贯穿I/P/S/BPaaS）。

动机和优点

IT services today are usually not designed generic but specific. This is a large hurdle for reusing any service element in another IT service.

IT 服务今天通常不是设计的通用但特定。这是重用中另一项IT 服务的任何服务元素一大障碍。

A CCMP as defined in this RA is supposed to scale and to host multiple types of cloud services (across I/P/S/BPaaS), so it is essential to introduce a model which allows cloud service developers to specify how the CCMP functionality gets used in the context of their specific cloud service and how - based on that definition or template - instances of that cloud service get delivered to cloud service consumers (in line with the class/instance thinking from OO). This has been taken into account in the CCMP RA design. The remaining todo for the cloud management platform architect is to design how the CCMP management functionality gets exploited in the context of the respective cloud service. This is achieved by creating a set of service type-specific artifacts as required by the respective management platform components (e.g. cloud service-specific scripts, monitoring agents, etc.).

CCMP 所界定的这个RA 应该是基于该定义的扩展，（在我/P/S/BPaaS），主机的云服务的多个类型，因此必须引入一种模式，允许云服务开发人员指定的CCMP 功能获取其特定的云服务的上下文中的使用方式，以及如何--或模板--云服务的实例获取传递给云（按照从面向对象的类实例/思考) 服务消费者。这已在CCMP RA 设计中考虑。其余的todo 云管理平台建筑师是设计如何CCMP 管理功能获取利用各自的云服务的上下文中。这被通过创建一组各自的管理层所要求的服务类型特定工件平台组件（如云特定于服务的脚本，监控代理等。）。

It is important to be specific about the semantics of the term \'service\' when using it in the cloud context as just talking about the term \'service\' is too imprecise. In the context of the CCRA, the notion of a service and of a service instance exists, whereas a service is responsible for creating service instances and represents their runtime context. Services instances service as defined in the CCMP RA are typically not "classical" Web services; neither one of these concepts corresponds to an ITIL service either. In the context of the CCRA, service instances represent tangible units which are referred to in noun form (they are the units of delivery and management). Such cloud service instances represent something that is provided "as-a-service" (going across all aaS categories), such as an infrastructure element like a virtual machine, a middleware platform or an end user application. All these entity-like service instances have a lifetime that begins with deploying and delivering them; it ends with deprovisioning them. As a rule of thumb, everything that may appear in the XaaS stack can be a service instance.

它是重要的具体有关「服务」一词的语义时使用它，只在谈论「服务」一词云上下文中是不太精确。在数据库内，概念的服务和服务实例的存在，而服务是负责创建服务实例，并表示其运行时上下文。服务实例所界定的CCMP RA 通常不是"经典"的Web 服务；没有这些概念之一或者对应到ITIL 服务。在数据库的情况下，服务实例表示有形的单位，称为名词形式（它们的提供和管理单位）。这种云服务的情况下代表提供"作为服务"（穿过所有原子类别），如像一台虚拟机、中间件平台或最终用户应用程序基础架构元素的东西。所有这些实体类服务实例已部署和提供他们；开头的生存期它是以撤消他们结束的。作为一个经验法则，在XaaS 堆栈中可能出现的一切可以是一个服务实例。

Consequences and Implications

The cloud service creator needs to have a thorough understanding of the functionality provided by the CCMP and how this functionality can be leveraged within the context of the respective cloud service.

云服务的创建者要有充分的了解，由CCMP 和如何可以利用此功能，各自云服务的范围内提供的功能。

All IT services have to be clearly described due to their lifecycle. For every IT service a set of artifacts has to be created in a consistent fashion, according to the guideline defined in the CCRA "cloud service creation" work product.

所有IT 服务都要清楚地说明由于其生命周期。对于每一组工件的IT 服务，必须创建一致的方式，根据要在数据库中定义的准则"云创建服务"工作产品。

Examples

One example is capturing the specifics of providing and managing storage-as-a-service. As part of creating a storage cloud service all artifacts required for delivering & managing a new storage service instance are created. That means, in the context of a storage-aaS cloud service the cloud service consumer gets a file system or a storage volume to put data on.

一个例子捕获提供和管理存储作为服务的细节。作为创建存储云服务的一部分创建所需的提供科技管理新的存储服务实例的所有项目。手段，在存储原子云内服务云服务消费者获取文件系统或放入数据存储卷。

4. 参考

[1] The Open Group, The Open Group Architecture Framework (TOGAF), Definition of the term "Architectural Principle", http://www.opengroup.org/architecture/togaf8-doc/arch/chap29.html

[2] Barroso A., Hölzle U., The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines

[3] Amazon, AWS and EC2 resources

[4] Google App Engine articles

[5] Meyer, B., Object-Oriented Software Construction, 2nd edition. Prentice Hall, 2000.

[6] IBM GTW world-wide CoP lecture series (contact: Teisha Harry)

[7] National Institute of Standards and Technologies; Draft NIST Working Definition of Cloud Computing, May 14, 2009