前言

随着信息技术的飞速发展，云计算技术的应用也越来越广泛。云计算为企业带来了资源快速的交付能力、强大的敏捷性、灵活的横纵向扩展性以及高标准的部署规范性。这些优点在开发测试云计算的运用当中，表现地尤为突出。云计算平台不仅仅是一个统一资源管控平台，更重要的是一个IT服务平台，它将资源抽象化和服务化，极大简化了企业用户的管理和使用，而在云计算中最核心的就是云管平台，一个贴切企业实际需求的云管平台，能够强化企业IT资源的管理能力，提升企业IT资源利用率，满足企业对大规模计算能力的需求，从而进一步推动企业业务的发展。本文旨在探讨如何更好地设计金融行业开发测试云管平台，包括云管平台的需求、定位和设计方案。

开发测试云的需求

在金融行业中，对于开发测试云，通常有以下几点需求：

1.资源整合、大幅提高资源利用率

在开发测试环境，由于环境复杂性、成本、历史等原因，开发测试环境的资源孤岛现象十分常见，资源利用率低但却依旧无可用资源，为了摆脱该痛点，企业都已经开始利用虚拟化技术，进行资源整合和资源共享，摆脱开发测试资源孤岛格局。另外，资源回收也是企业一大痛点，传统环境资源回收过程艰难，不彻底，也没有资源生命周期的概念。这是开发测试云管平台需要考量的要点之一。

2.为敏捷开发提供快速部署的支撑

随着金融行业业务的互联网化，功能的快速开发、测试和上线变得越来越重要，而敏捷开发和测试对资源的需求是极快速的，这里的资源不仅仅包括计算、存储和网络，还包括各类基础软件资源、中间件资源和数据库资源等，所以需要利用云计算快速、自动化软硬件服务编排的功能，提高敏捷开发的能力，大幅缩短开发测试环境部署的时间。这是开发测试云管平台需要考量的要点之二。

3.资源部署策略多样性

云计算资源池可提供各类不同平台、不同性能、不同厂商的资源，为多样性的开发测试提供选择，所以资源的部署策略同样需要多样性，能够根据企业用户设定的不同策略，动态自动化的部署到不同的资源当中。同样，这些策略的设定也需简易和便捷，无需用户了解过多的底层实现。这是开发测试云管平台需要考量的要点之三。

4.资源调配灵活性

资源的调配不局限，需要具有灵活性和动态性，灵活性方面无论是计算资源、存储资源还是软件资源，无论是Scale Up还是Scale Out，甚至需要云管平台能够对接外部的公有云资源，动态调配私有云和公有云的资源，实现混合云的工作负载模式。动态性方面云管平台需要能够实时监控底层资源的使用情况，在触发动态调配阀值时，通知用户或者自动进行资源的在线迁移或者扩展。这是开发测试云管平台需要考量的要点之四。

5.保持开发测试与生产的统一规范

传统开发测试环境和生产环境部署不规范，不统一，造成了很多问题和痛苦，即使制定了相关规范性文档或者实施工艺，但由于人和流程等的因素，往往落地十分困难，形成一纸空文。而在云计算中，由于云管平台的存在，可以将标准的模版、软件和配置规范可以介质的形式存放于云仓库，生产和测试环境只需保持云仓库的同步即可，这样一来更易于保持生产与开发测试环境的统一和规范，二来由于这些规范随资源部署时自动化落地，规避了人为和流程的因素。这是开发测试云管平台需要考量的要点之五。

6.自动化运维、监控和流程的集成

相较于生产环境，开发测试环境的自动化运维和监控往往就不大重视，然而实际问题却是开发测试环境经常莫名奇妙出现各类问题，各个节点检查后才发现是非常简单的原因造成的，这时简单的监控也变得需要；另外由于开发测试环境节点数规模十分庞大，也不可能指定大量专门的运维团队去维护开发测试环境，所以开发测试环境的自动化运维也变得需要；最后如何实现开发、测试和生产运维流程一体化也是需要考量点之一，让整个IT流程在各个阶段都运转和串联起来。所以开发测试环境的云管平台需要合理的集成自动化运维、监控和流程平台。这是开发测试云管平台需要考量的要点之六。

云管平台的定位

说完了云管平台的需求，再来说说云管平台的定位。由于云计算的层次和概念比较多，各个行业的资源使用情况也不一样，加上各类云计算厂商的宣传和用词，很容易造成用户的概念混淆或者疑惑。我们先来看看目前常见的云计算体系层次架构：

1.商用X86云

商用X86云主要是Vmware技术为主要代表，VCenter虚拟化管理平台相当于资源管理层，Vrealize Automation则为云管理平台层，不仅提供API功能的自服务和统一服务目录，也能支持不同供应商的多套私有云和公有云，还支持对容器的管理等。该云管平台的特色是和Vmware的底层技术紧密结合，通过抽象化底层实现技术，同时提供可视化服务和可拖放的设计画布，将预构建的组件组合为各种应用。

2.开源X86云

开源X86云主要以OpenStack为框架，利用OpenStack的各类组件对接不同的资源，各厂商在公版OpenStack的基础之上，开发各具特色的云管平台，包括统一资源层和服务抽象层，资源层的实现需要在公版OpenStack各组件上进行改良和优化，而服务抽象层的设计完全就是各组件的API的调用和抽象，将不同的IT服务、编排策略、动态优化策略等翻译成不同组件的API调用组合，另外还需和其他像自动化运维和监控等工具相结合，这就完全考验各厂商或者用户企业的开发实力和对云管平台的理解能力。

3.Power云

Power云很简单，以IBM的PowerVC为目前的最佳选择，PowerVC提供两种版本，一种是PowerVC Standard Edition，提供基本的虚拟化资源管理能力，另一种是Cloud PowerVC Manager，在Standard Edition之上还提供了自服务功能和简单流程审批功能，能够定义各类计算模板和存储模板，自动化按照模板进行计算资源和存储资源的编排。此外，还提供了DRO动态资源优化功能，能够实时监控资源的使用情况，按照设定，提示或者自动化在不同计算节点上均衡工作负载。最后，PowerVC和Power的特性紧密结合是最大特色，比如Remote Restart、LPM、EnterprisePool和PowerHA等等，利用该云管平台能够实现一整套完善的Power高可用体系架构。

4.Power和X86共存云

这是金融行业云计算体系最常见的架构体系，不像纯互联网企业那样，完全是X86，而由于金融行业的特殊性，以追求最大的稳定可靠性为第一目标，所以金融行业的企业目前Power计算资源是必不可少的，至少在今后很长一段时间Power和X86将共存，所以其云计算体系架构是需要考虑如何实现不同平台异构资源的共存，同时还要考虑纯物理计算资源的接管。相较于开源X86云，这类异构资源的统一管理，实现技术为Driver的集成，将PowerVC Adapter、Vcenter甚至Z/VM的Driver集成至云管平台的统一资源层，通过Driver的API间接管理和调度Power和Vmware X86的资源池；至于纯物理计算资源的接管，则是用到了OpenStack裸金属Ironic组件，它提供了一系列常用的Baremetal Server的Driver，并且提供了插件的机制让二次开发的厂商可以开发一些其他Baremetal Server的Driver嵌入其中。最后，对于公有云或者容器云，也是云管平台通过其提供的Restfull API进行对接。

综上四种架构，可以很清楚看到，云计算体系应该包含三层或者四层：资源池层，虚拟化管理平台层，云管平台资源层和云管平台服务层。资源池层，包括各类计算、存储和网络资源，这个资源可以是做了虚拟化技术的，也可以是没做虚拟化技术的物理机；虚拟化管理平台层对各类同构的底层虚拟化资源池统一管理；云管平台资源层实现对所有异构的资源的统一管理；云管平台服务层实现自服务界面，将服务的底层资源实现、部署策略和动态调配实现抽象化，集成各类运维、管理和流程的工具等。实际上，广义上来说，云管平台应该包含统一资源层和服务层，狭义的云管平台只是服务层，这两个层次可以在一套软件中实现，像轻量级IaaS Power云---Cloud PowerVC Manager、其他三方（如EasyStack、东软Saca、云宏和SAP等）云管平台，也可以多套软件实现，软件和软件间有API接口实现对接，像Cloud Manager+ICO的组合、StartCloud+SelectStack的组合、VCenter+Vrealize的组合或者异构软件的组合（如StartCloud+Vrealize/ICO/EasyStack）等等。这些商用云管平台的例子告诉我们，统一资源层和服务层是紧密不可分割的，所以我们在设计云管平台时的定位应该要在广义的角度去统一设计，而不仅仅是从服务层的角度。

云管平台的架构设计

有了前面开发测试云的需求和云管平台定位的简单介绍，现在正式进入开发测试云管平台的设计阶段，主要包括三个部分：统一资源层的设计、服务抽象层的设计和运维管理集成的设计。逻辑架构图如下：

1.统一资源层的设计

云管平台的统一资源层并非是资源的直接提供者，而是资源的管控者或者调度者，对上提供API，供服务抽象层调用，对下集成资源的Driver，承上启下，作为云计算技术的具体实现层，统一资源层的设计需要有“平台”、“分布式”和“动态”的设计理念。

一是资源层能够提供一个资源适配平台，能够适配各类计算资源（异构X86和Power虚拟化、物理机、公有云和容器云），各类网络资源（网络类型：local、Flat、VLAN、VXLAN、GRE；网络机制：LinuxBridge、Openvswitch；网络服务：Router、LoadBalance、Firewall、DHCP等），各类存储资源（LVM，NFS，Ceph，GlusterFS，以及EMC和IBM等商业存储系统），各类软件资源（中间件、工具、数据库和应用等）；

二是资源层的各组件能够按照一定细粒度分布到不同的控制节点中，这样可以提高性能和伸缩性，避免随着资源节点数的增加，造成的瓶颈；

三是资源层的编排是动态和自动化的，在资源层按照过滤规则、策略或者资源模板进行设定后，部署则按照该策略模型就行自动化的编排，并且可以和监控组件（如OpenStack的Ceilometer）相结合，实现动态的迁移、伸缩和扩展资源。整体资源层示意图如下：

“平台”理念：

（1）计算资源

OpenStack作为开放的Infrastracture as a Service云操作系统，支持业界各种优秀的技术，这些技术可能是开源免费的，也可能是商业收费的。 这种开放的架构使得OpenStack 保持技术上的先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in）。那OpenStack 的这种开放性体现在哪里呢？一个重要的方面就是采用基于Driver的平台框架。先来看Nova组件：

计算资源分两块，一块是虚拟化资源，一块是物理资源，虚拟化资源又分直接虚拟化资源和间接虚拟化资源，先说直接虚拟化资源，也就是云管平台资源层直接对接虚拟化资源，但是现在市面上有这么多Hypervisor，资源层的Nova又是如何与他们配合的呢？答案是通过Nova-API调用Nova-compute子组件，Nova-compute子组件为Driver 架构，nova-compute 为这些 Hypervisor 定义了统一的接口，Hypervisor只需要实现这些接口，就可以Driver 的形式即插即用到OpenStack Nova系统中。下面是Nova Driver的架构示意图，这时的Nova-compute存在于物理计算节点中：

再说间接虚拟化资源，云管平台资源层的Nova-compute集成了虚拟化管理平台的Driver，间接通过虚拟化管理平台管理和调度计算资源，如PowerVC、Vcenter和Z/VM就是这样纳入云管平台的。但是这种方式也有一个弊端，虽然通过Driver可以调用虚拟化管理平台的API获得资源信息和进行操作，但是由于不直接跟Hypervisor通信，一些底层的虚拟化操作是无法被云管接管的，特别是一些特性化的功能，另外API也无法提供所有的操作，依旧需要去虚拟化管理平台进行操作，此外，虚拟化管理平台本身也具备一些编排策略和动态优化规则，而云管平台资源层也设计了相应的策略和规则，间接的接管方式需要考虑这些功能是否可以通过API往统一资源层上集成，再往服务抽象层上集成。

最后是物理资源，Nova-API调用资源层的Nova-compute，Nova-compute再调用Ironic的API来实现对物理资源的管理和控制，可以理解为Nova-compute集成了Ironic的Driver，Ironic可以看成一个Hypervisor Driver来给Nova来用。再者Ironic中也集成了许多Baremetal Server的Driver，并提供了插件的机制让二次开发的厂商可以开发一些其他Baremetal Server的Driver嵌入其中。

（2）存储资源

OpenStack的存储组件为Cinder，存储节点支持多种Volume Provider，包括LVM, NFS, Ceph, GlusterFS，以及EMC, IBM等商业存储系统。Cinder-volume为这些Volume Provider定义了统一的 Driver 接口，Volume Provider只需要实现这些接口，就可以Driver的形式即插即用到OpenStack中。下面是Cinder Driver的架构示意图：

（3）网络资源

Neutron的核心组件包括Core Plugin和Service Plugin，Core Plugin负责管理和维护 Neutron的Network, Subnet和Port的状态信息，这些信息是全局的，只需要也只能由一个Core Plugin管理。只使用一个Core Plugin本身没有问题。但问题在于传统的Core Plugin 与Core Plugin Agent是一一对应的。也就是说，如果选择了Linux Bridge Plugin，那么 Linux Bridge Agent将是唯一选择，就必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机（即Network Provider）。同样的，如果选择Open Vswitch Plugin，所有节点上只能使用Open Vswitch，而不能使用其他的Network Provider。此外，所有传统的 Core Plugin都需要编写大量重复和类似的数据库访问的代码，大大增加了Plugin开发和维护的工作量。到了OpenStack Havana版本时，实现了一个新的Core Plugin，即ML2，ML2作为新一代的Core Plugin，提供了一个框架，允许在OpenStack网络中同时使用多种Layer 2网络技术，不同的计算节点可以使用不同的网络实现机制。如下图所示，采用ML2 Plugin 后，可以在不同节点上分别部署Linux Bridge Agent, Open Vswitch Agent, Hyper-v Agent 以及其他第三方Agent。 ML2不但支持异构部署方案，同时能够与现有的Agent无缝集成：以前用的Agent不需要变，只需要将Neutron server上的传统Core plugin替换为ML2。 有了ML2，要支持新的Network Provider就变得简单多了：无需从头开发Core Plugin，只需要开发相应的Mechanism Driver，大大减少了要编写和维护的代码。

（4）软件资源

软件也作为一种资源存在于云管的资源层，软件资源的实现有多种方式，一是最简单的镜像模板实现，通过制作安装了特定软件资源的虚拟机，再捕获为镜像模板，存在镜像仓库，部署时克隆一份；二是通过OpenStack HEAT组件实现，OpenStack Heat是一个基于模板来编排复合云应用的服务模板，它的使用简化了复杂基础设施，服务和应用的定义和部署。Heat模板支持丰富的资源类型，实现了对操作系统、应用、中间件、框架和工具等的自动化安装和配置，规范了软件资源的部署。OpenStack Heat提供四种软件资源编排方式：Heat对软件配置和部署的编排；Heat对负载均衡的编排；Heat对资源自动伸缩的编排；Heat和配置管理工具集成。云管平台在设计时，在服务抽象层存放编排的脚本，服务层在进行翻译时，会将编排的脚本加载至资源层的OpenStack Heat组件中，在其他组件完成硬件资源的部署后，OpenStack Heat运行编排脚本，实现软件资源的部署；三是通过容器编排实现，服务层将需求翻译成资源层的API，再通过云管平台的资源层API调度容器云的编排引擎（Docker Swarm、Kubernetes和Mesos），间接实现容器软件资源部署；四是通过OpenStack的特殊组件实现特殊软件服务，如OpenStack的Trove组件可以实现DBaaS，OpenStack的Sahara组件可以实现HadoopaaS等。

综上，在设计云管平台资源层时，要以“平台”的理念去长远规划，保证云管平台资源管理的统一性和可扩展性。

“分布式”理念：

OpenStack的开放性除了Driver框架下的平台特性，还在于分布式的特性。所有组件既可以采用all-in-one的方式存在一个控制节点中，各个组件也可以广泛分布于各个不同的控制节点中，只需保证节点间的通信即可；不仅如此，每种组件中的子组件也可存在多个，进行分布式部署，通过LoadBlance实现负载均衡；另外，对于all-in-one架构的控制节点，也可按照不同功能、分区甚至数据中心进行区分，组成多个全套的控制节点，这多个控制节点通过将Keystone认证信息和EndPoint链接注入至其中一个主控制节点当中，实现在该主控制节点统管所有资源，实际上部署却是分布式的，互不相干的。

（1）资源层控制节点的组件all-in-one

云管平台资源层设计为所有OpenStack组件都集中在一个控制节点中，适用于计算节点和存储节点较少的场景，并且并发部署和管理的资源个数不宜太多。另外，由于只有一个控制节点，该节点的高可用也需要考虑，尤其是控制节点中的数据库，用数据库复制技术也可，还可以用双机软件，搭建Linux操作系统的双机实现高可用，如Keepalive、TSA或者Pacemaker等。

（2）组件或者子组件分布于不同控制节点

云管平台资源层设计为所有不同的组件和子组件均衡分布于不同的控制节点当中，如下图所示为资源层架构样例，相同组件的控制节点通过应用负载节点实现负载均衡（如HAProxy），实现ACTIVE-ACTIVE；RabbitMQ的消息控制节点则可通过自身的集群实现ACTIVE-ACTIVE，所有组件均通过RabbitMQ实现异步通信，同时为保证负载均衡和自动切换，组件配置了RabbitMQ的集群节点列表。数据库节点间可通过高可用软件+数据库复制技术实现ACTIVE-STANDBY，所有数据库的访问请求均通过虚拟服务IP实现。

不仅如此，每个控制节点当中的子组件设计也可以按照“分布式”的理念进行设计，如下图所示，同样是多个相同的子组件通过HAProxy实现负载均衡，组件内部的不同子组件间也均通过RabbitMQ集群进行异步的通信。

整个架构有几下优点：

A.当计算资源不够了无法创建虚机时，可以增加计算节点或者存储节点（增加Nova-Compute、Neutron-Agent和Cinder-Provider）。

B.当客户的请求量太大调度不过来时，可以增加Scheduler或者直接增加控制节点。

C.通过消息组件RabbitMQ的异步通信实现调用，一是可以解耦各子组件和组件，他们不需要知道其他组件在哪里运行，只需要发送消息给消息组件就能完成调用。二是提高了性能，异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。三是提高伸缩性，子组件和组件可以根据需要进行扩展，启动更多的控制节点处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他组件，也就是说变化对别人是透明的。

所以，该资源层的架构非常适合大规模和超大规模的云计算。

（3）多个all-in-one的控制节点功能分区

云管平台资源层的单个控制节点五脏俱全，包含了所需的所有组件，但每个控制节点的用途不一样，比如每个网络安全分区一个控制节点或者Power平台一个或多个控制节点，Vmware X86一个或多个控制节点，然后开源X86一个或多个控制节点，然后再搭建一个主控制节点，通过继承其他控制节点的KeyStone和EndPoint实现资源的接管，在主控制节点的Dashboard上通过切换不同Region实现管理的切换。通常商用私有云管平台喜欢采用这种架构，因为商用产品的软件会做得比较全，按照它的设计理念，面面俱到。但是这样如果部署在一个控制节点上，在资源规模比较大的情况下，不可避免地会产生性能瓶颈，可靠性也存在考验。如果按照不同功能进行分区的方式，则能起到立竿见影的效果，同时也可以实现统一管理的效果。比如下面商用私有云的架构（IBM Cloud Manager+IBM Cloud Orchestrator），不同功能的ICM控制节点分别管理不同的资源池，最后在逻辑上从属于主ICM，主ICM设计为高可用集群架构，其中的部分组件则采用了ACTIVE-ACTIVE的方式，均衡负载请求，实际上这个集群架构则为第二种架构模型，相当于在这个架构模型之上，再来了一层控制节点，增加了一层深度。和第二种架构模型的区别是，第二种架构组件的子组件也可以采用分布式部署方式，而该架构只能是所有组件all-in-one。这种架构由于也是“分布式”，可适用的资源规模也可以非常大，但显然没有第二种架构灵活性高。

“动态”理念：

部署策略：顾名思议，在资源部署时能够按照不同的模板或者策略，自动地或者可选择地部署到不同的资源当中。先说部署模板，在OpenStack里面叫做Flavor，定义了VCPU，RAM，DISK，Metadata四类，Scheduler会按照flavor去选择合适的计算节点；在PowerVC里面叫做Templete，有Compute Templete和Storage Templete，按照Templete去计算节点中部署资源。再说策略，策略在OpenStack中叫做Filter，也就是过滤规则，在部署时，按照规则的设定过滤一遍，最终选择合适的目标计算节点进行部署。比如RetryFilter（刷掉之前已经调度过的节点）、ServerGroupAntiAffinityFilter（可以尽量将 Instance 分散部署到不同的节点上）、ComputeCapabilitiesFilter（根据计算节点的特性来筛选）、AvailabilityZoneFilter（为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中）等等，并且能够支持第三方Scheduler，按照Driver的框架，配置Scheduler_driver 即可。最后说下策略继承，云管平台的资源层由于是异构的资源层，包含了Power、商用X86、开源X86、容器、公有云，甚至Z/VM，采用的资源接管方式也不一样，有的是直接管理，有的是间接管理，直接管理可以采用云管资源层自身设定的部署策略，而间接管理由于资源池层也存在部署策略（如PowerVC、VC、公有云、容器云）则需要考虑能否将这些部署策略通过API集成过来，或者是不去集成这些策略，直接读取过来，亦或是不去管理这些策略。因为云管资源层的开发者或者厂商和间接管理的这些资源池层厂商不是同一家，相互间的配合和协同，或者一些API并不开放等，所以这一块，为了简便，直接采取不去管理这些策略，一来必要性也不是那么高，二来节约了成本。

动态优化规则：动态优化规则是通过一定的监控手段，采集资源使用情况，当触发优化规则时，通过事件通知用户，或者直接执行动作去在线迁移资源或者横纵向扩展资源。这里有两种方式来实现，一是通过Nova组件协同Ceilometer来实现。Ceilometer对底层资源使用实时采集和监控，当触发动态优化规则时，如计算节点CPU使用率、内存使用率、使用率连续3次超过所设定的阀值，则开始执行动作，按照虚拟机的权重，迁移该计算节点上的权重较低的部分虚拟机至资源池的其他计算节点当中。二是通过Heat组件协同Ceilometer来实现，同样Ceilometer对资源使用进行采集，当触发告警阈值时，通知Heat调度编排脚本，自动横向部署一个新的虚拟机供业务使用。Heat对资源的伸缩编排如下图所示：

2.服务抽象层的设计

云管平台的服务抽象层建立在资源层之上，也就是前面所说的狭义云管平台，官方的定义基本都是这种：Gartner 对 CMP 的定义---CMP (Cloud management platforms，云管理平台)是一种管理公有云、私有云和混合云环境的整合性产品，其最小的功能范围应该包括自服务界面(self-service interfaces)、创建系统镜像(provision system images)、监控和账单(metering and billing)，以及基于策略的一定程度的负载优化(workload optimization)等。高级的功能还包括整合外部已有的企业管理系统，包括服务目录(service catalogs)、存储和网络资源配置，更高级的资源管理和监控，比如客户机性能和可用性监控等。具体见下图：

狭义云管平台本身来说，并不具备能够独立完成这些能力，而是基于对底层资源层API和企业IT管理平台API的抽象整合去实现这些能力，技术实现真正是在资源层完成的，下面这张图则是OpenStack官方核心组件的整体架构图，做了些许微调。

图中明确地指出了管理OpenStack的三种方法：Command-line interfaces（命令行界面）、GUI Tools（类似于Horizon的Dashboard图形界面工具)、Cloud Management Tools（Rightscale, Enstratius,etc)。显然，在大规模的云计算运维中，使用Command-line interfaces（命令行界面）去执行运维活动是不切实际的。使用OpenStack Horizon的Dashboard图形界面工具，其有限的功能对大规模的云计算环境而言同样是不完备的。OpenStack的Horizon并不是完整意义上的CMP，作为OpenStack的Dashboard项目，当前的Horizon只有很少的一部分CMP功能。Horizon调用OpenStack的各个API接口去操作云平台资源中的各类资源，提供了管理和操作OpenStack的用户界面，实现了 CMP 所要求的一部分功能，但是，它还缺少很多核心功能，尽管基于OpenStack发展而成的CMP可能是未来的技术趋势。而OpenStack被专用性强的Cloud Management Tools（CMP）所纳管，这是被OpenStack官方所认可的管理OpenStack的标准方法之一。另外对于一些资源层的API（如容器云、公有云），也可直接集成到CMP中，而不仅仅限于放在OpenStack资源层中，其区别是有些商用CMP产品已经实现了这些集成，不必要再对OpenStack资源层再定制这些API集成，增加开发量。如果资源层和服务层（狭义CMP）都是走的研发路线，可以考虑将资源和服务彻底分开管理。

所以我们总结一下，目前有三种方式来实现服务抽象层：

（1）使用OpenStack自带的Horizon

前面也讲了，这种方式面向的是基础资源的管理，缺少很多CMP需要的核心功能，如服务目录和编排，多云管理方面也不支持公有云和容器云，计量计费及成本优化等等，面向用户的美观感、页面布局和体验感差，不友好。

（2）定制或者重新开发 OpenStack Horizon

许多商用软件厂商重新定制了Horizon，定制分为两种，一种是基于Horizon社区提供的 Horizon定制方法所做的非常简单的定制，比如更换Logo，简单改变布局、更换界面颜色等，很显然这种定制所带来的差异化非常有限；另一种是深度定制甚至重新编写，这能带来足够的差异化，再者也能将一些核心功能补齐，比如通过集成公有云API，实现公有云和私有云管理平台的整合，还能够整合用户的其他管理系统等。

（3）运用专业的CMP（商用或者研发）

专业的CMP考虑的面比较广，往往以应用和用户为中心，支持各种高级功能，但目前的一个事实是：CMP市场的碎片化程度极高，各产商占有的市场份额都非常低，大部分在10%以下。这个市场呈现出显著的战国时代的特征，这预示着未来几年在CMP市场的白热化的市场竞争。对于我们企业用户来说，选择与自身企业需求和规划相匹配的专业CMP才是最佳选择。下面举四个专业商用CMP的例子：

RightScale RightCloud：

RightCloud能管理公有云和私有云，以及虚拟服务器和裸金属服务器，提供的功能包括自服务、云管理和云分析等。功能全面、丰富，支持几乎所有的主流公有云、私有云、虚拟服务器和裸金属服务器等。界面风格现代，用户体验非常好。

（1）系统架构

（2）功能特色

云管理: 异构环境统一管理、自动化部署与运维；统一监控与集成、持续集成与交互。

▪ 自服务---通过从一个门户网站对多个云进行基于模板的配置，加快开发速度。

▪ 云监控---支持多云环境统一监控视图，查看，自动化和管理任何云和服务器上的云资源。

▪ 主机模板---支持多种主机模板配置，在多云环境下创建云资源，主机模板提供一种新的配置方式。

▪ 云治理---支持多租户控制，基于自动化策略，对云环境下的多租户进行治理和权限控制，消除障碍，而不会牺牲控制。

云分析：管理和优化多云环境成本；协同采取行动，减少支出。

▪ 分析报告---在统一仪表板中查看来自公有云和私有云的使用情况及成本数据；将成本分摊给对应部门；通过云帐户、团队或应用程序维度来分析成本使用趋势。

▪ 协同优化---获得降低成本的自动化建议；向right cloud的用户提供储蓄建议；通过仪表盘展现成本降低的趋势。

▪ 自动化的动作---为改善未来的建议提供反馈；一键终止或删除未使用或空闲的资源；优化使用AWS保留实例和Google承诺的折扣。

▪ 预算和预测---预测未来或现有云应用的未来成本；制定预算并提醒用户或管理者超支；评估不同的云，实例类型和购买选项。

云比较：免费的工具，可让用户轻松比较领先的公有云提供商所提供的功能。

（3）功能列表：

Red Hat CloudForms:

CloudForms是红帽公司开发的CMP,功能包括审批流程、合规、自服务、记账和配额管理。能管理多种IT和云环境功能全面、丰富，能管理多云，支持OpenStack, VMware, KVM, Microsoft和Amazon等云环境。界面的用户体验不错，但是其风格还是传统IT管理软件的风格，Redhat 基于CloudForms提供了Open Hybrid Cloud解决方案，该云管理平台同时管理RHEV与OpenStack。

（1）系统架构

（2）功能列表

浪潮数据中心管理平台InCloud Manager:

云管理平台InCloud Manager是云数据中心管理平台，面向私有云和混合云市场，提供开放、安全的企业级云数据中心运维管理能力。InCloud Manager借由自服务的管理Portal，提供跨基础架构一致性的功能和体验，帮助企业加速云的应用，实现业务的动态变更，资源的智能管理和服务的自动化交付。

（1）系统架构:

（2）功能特色：

完善的生态，异构资源的统一管理：

▪ 支持主流厂商x86服务器、K1、IBM小型机、SmartRack的管理；

▪ 支持对Inspur InCloud Sphere、VMware vSphere、Citrix XenServer、IBM PowerVM等多种异构虚拟化软件统一管理:

▪ 支持对容器环境的接管，可以和容器调度系统Kubernetes进行对接混合云提供更多业务灵活性：

▪ 充分利用私有云和公有云的优势；

▪ 客户根据业务需要，灵活云间切换；

▪ 混合云备份容灾，保障数据和业务；

▪ 打通公有云，开启混合云应用的新模式。

完善的服务目录：

▪ 丰富的服务目录实现一体化资源交付；

▪ 服务内容涵盖云主机、云物理机、云桌面、云盘、云网络、云存储、云监控；

▪ 统一的管理平台，满足新建云和增量云的需求。

跨地域多数据中心管理:

▪ 分散的异地数据中心协同管理，高效运管；

▪ 跨数据中心的应用和数据保护支撑，保护业务和数据；

▪ 单一数据中心可管理5000+服务器，2000+虚拟机，10000+用户，1000+组织。

智能的自动化运维：

▪ 分布式远程执行系统，可以执行任意命令和预定义的模块命令；

▪ 基于网络加载，自动化安装，支持多节点并发和一键式智能安装控制；

▪ 数据库、Web应用、中间件等服务的快速交付；

▪ 业务上线时间由原来的几周、几天，缩短为几分钟。

高效的业务支撑：

▪ 业务感知，资源池弹性应对业务负载；

▪ 支持软件负载均衡和硬件负载均衡；

▪ 根据自身业务情况，灵活添加及修改审批节点；

▪ 实现订单历史全程可追溯，各审批环节实时提醒。

精细的监控管理：

▪ 服务器、存储、网络、操作系统、中间件、数据库、业务应用七大监控类别；

▪ 20000+监控项，提供对数据中心全面的监控；

▪ 巡检计划、巡检策略和巡检报告实现巡检任务策略化；

▪ 3D机房建模实现物理机房可视化监控；

▪ 全生命周期资产管理。

安全可靠云平台：

▪ 符合4A的安全运维规范，提供完备的安全体系；

▪ 通过*部计算机信息系统安全产品质量监督检验中心检测；

▪ 通过中国信息安全测评中心分级评估EAL3+级安全评测和专家验收；

▪ 集成第三方安全模块，支持底层无代理防护，实现操作系统到应用层面的多层防御；

▪ 全自主研发，构建Web安全、虚拟化安全、数据安全、访问控制、安全审计、多租户资源安全隔离，可提供端到端的安全管理方案。

IBM SelectStack云管平台：

SelectStack(PMC v2.0)是IBM新一代的易于部署实施的，集成硬件、管理软件与实施服务为一体的，简单快速的实现动态资源部署的云管理平台。

（1）系统架构

（2）功能特色

快速可靠地实现集成化私有云管理平台

▪ 提供全生命周期的部署服务，快速提供“即申即用”的云计算环境，并且在集成化平台中同时支持多种虚拟化技术。

▪ 提供了虚拟机、中间件、客户应用以及复杂拓扑结构的一键式自动化部署。

▪ 提供高度客户化的服务目录，客户还可以自主扩展该服务目录。

▪ 提供高性能、可伸缩、可靠、可容错的涵盖物理机和虚拟机的资源实时监控、历史数据汇总、业务数据分析、计量统计、重要信息通知、故障告警以及事件管理。

▪ 还可以通过内置的流程引擎实现灵活的多级审批，支持企业灵活地将虚拟资源的管理同自己企业的组织结构，审批流程相结合，搭建更适用于自身的私有云管理平台。

▪ 提供的多租户管理，*部门及子部门配额管理等高级功能可以更好的配合用户的实际业务需求，实现IT运维管理与业务实施的完美配合。

丰富的功能支持企业数据中心云计算

▪ 标准的云计算管理功能：集群和主机管理、服务目录管理、资源池管理、自动化部署 以及资源调整和回收、中间件部署、用户管理和通知等。

▪ 灵活的架构:可以直接管理不同虚拟化平台，支持x86、System Z和Power系列服务器，可以部署Windows、 Linux、AIX等操作系统，方便定制开发新功能。也可以通过OpenStack管理虚拟化平台，方便利用开源社区提供的功能。

▪ 提供区域管理功能，能够同时管理位于多个区域、数据中心的不同虚拟化环境。利用部门来指定配额，资源池和服务目录，方便管理员细粒度掌控云环境中的各种资源。

▪ 拓扑结构管理：用户可以通过向导方便创建出部署环境对应的拓扑结构图（服务器硬件资源、操作系统、中间件、中间件关联关系等），SelectStack ( PMC v2.0 )会自动生成对应的多台服务器，并进行后台安装和部署。

▪ 丰富的监控和告警信息：提供物理机和虚拟机的实时监控、历史数据汇总、业务数据分析、计量统计、重要信息通知和故障告警。方便扩展和定制。

▪ 集成流程引擎，可以创建灵活的审批流程，方便扩展和集成第三方系统。具备在资源管理的全生命周期集成定制化业务逻辑的能力。

▪ 灵活可定制的资源调度策略。提供随机分配、平均分配、按资源指定属性分配等资源调度策略，并可按客户要求定制资源分配策略。

▪ PaaS级别服务：应用容器引擎Docker的引入使得SelectStack( PMC v2.0 )超越了单一IaaS 服务提供商的局限，从PaaS级别极大的满足了企业客户使用大规模分布式系统水平扩展功能的需求，降低了云计算技术在企业IT转型过程中的复杂度。

3.运维管理集成的设计

运维管理主要包括云管平台自身的运维管理和对接企业现有的IT运维管理系统（监控、CMDB、流程平台、自动化运维等），这里可能会出现一个设计误区，认为云管平台要做成本身就是一整套企业运维管理系统，不可否认，云管平台通过研发是具备一部分这样的能力的，从前面的专业商用CMP介绍中也可以看到这些能力的影子，但用户如果要这样做，可能存在以下问题，一是将云管平台定位过高了，项目目标过于高远，成本高，难度大，难以实现；二是上面的每一个IT运维管理系统都是一个完整的有机个体，覆盖范围大，功能强大，简单地认为云管平台可以取代这些运维管理平台是不现实的，就拿监控体系来说，有基础监控，软件监控，事件平台，容量监控，大数据应用日志监控，应用性能监控，网络监控，监控报表等等，而云管平台只是简单的资源监控和资源事件告警等；三是选择面缩小，倘若全靠云管平台来做，只能和云管平台厂商+自己研发的方式去做，这样容易造成厂商锁定，云管平台厂商也不具备这样完整的能力。

综上，目前而言，对运维管理集成的设计，如果是金融行业生产环境，建议分步骤，分阶段建设不同的运维管理系统，并预留接口，最终将需要的部分功能集成或者通过EndPoint链接到云管平台即可，目前专业商用CMP基本也都支持这些集成或者定制；如果是金融行业开发测试环境，由于其所需的运维管理功能不多，专业商用CMP的功能基本满足其所需，可以直接使用。这里以生产环境功能集成为例，简单画了示意图，抛砖引玉：