为什么云计算不一定节省企业成本？

首先把之前关于云计算观点做了简单总结，将以IaaS为主，兼带PaaS和SaaS的部分内容与大家一同分享。

一、关于云

1 云产业分析

根据IDC的分析报告，美国和中国云计算产业发展差异巨大：美国以公有云为主，SaaS最大、IaaS最小；而中国截然相反，以私有云为主，IaaS占了大约50%的份额。

究其原因，跟中美两国云计算产业发展的阶段、成熟度有很大关系。

中国的公有云主要使用者是小微、创新企业等。我认为IaaS公有云已经或者将要巨头化，PaaS还有机会，SaaS会是云计算几大分类中的爆发点，但是要看准行业。

在诸多产业中，中国云计算私有云市场主要的客户来自：通讯、金融、政府。金融行业受安全、政策、法规的约束，几乎不会选择纯公有云，大型国有银行私有云的建设步骤也很谨慎、渐进式，会首先考虑迁移非核心应用；小金融相对对新技术比较开放，会实验一些开源的技术，如Openstack、ceph等。

政府由于“十二五”、“十三五”政策持续推动、对于政务云建设的现实需求、统一纳管基础设施资源、节省成本等考虑，对云计算的投入较大。

2 国内有私有云需求的四类企业

a、政策驱动
因为政策持续推动、创新补助、领导要求（政绩）等原因，需要上云的企事业单位、行政机关。

b、人云亦云
不解释：）

c、新技术跟进
看到新技术的发展、成熟，希望分一杯羹的，也包括IDC之类的转型企业。和上一类的区别一个是模糊的、被动的，一个是有自主想法、主动的。

d、为业务而云
因为业务发展规模（含弹性）、统一上收资源、成本等考虑云。主要也分两类大型互联网企业和传统大型企业。

前者因为业务发展需要考虑云计算，从成本、技术可控性考虑，会采用大量的开源技术，同时会对硬件、软件提出改造要求，大力发展分布式、集群技术以适应其性能、可靠性等需求。典型的代表是阿里等。

而传统大型企业走的是另一条路，相对稳健，会选用成熟可靠的商业化解决方案为主，如虚拟化选择VMWare。另一方面，这类企业相对比较谨慎，会以规划咨询、POC、招标、建设、交付、运维相对固定的模式去建设云。典型的代表是大型央企。

3 IaaS、PaaS、SaaS分析

我把顺序反过来，先说SaaS，再说PaaS，IaaS。SaaS主要会在三种情况下出现：

a、行业SaaS
有行业属性的SaaS，如教育、医疗、培训等。

b、工具化SaaS
比如workday类似的管理工具、office365类似的文档工具等。

c、大型企业（组织机构）内部SaaS
有些企业内部，各地/部门业务类型相对一致，使用SaaS软件统一上收权限，节省成本等。

如我之前所说，如果找准行业、方向，SaaS可能是创业的大风口。

PaaS的实现有两种：

a、基于商业化自动部署工具的
大型企业考虑人员技能、维护成本、可靠性等要求，较多选择类似方案。HP、IBM、BMC等都有类似的工具。自行实现的话，可以考虑流程引擎加上脚本执行器再加部署包。

b、基于开源框架和软件的轻量级PaaS
选择cloudfundry、openshift框架，加docker等技术，目前随着相关技术的成熟，越来越受到关注。上述的几个大外企实际上也有类似的实现。

IaaS的情况比较复杂，难度主要在理清几个头绪：

a、业务对于底层资源的要求、约束
联想的架构师团队已经做了一件事，就是梳理业界存在的十几种主要的企业业务架构（如电商、搜索等等），分析和总结它们对于资源的各方面要求，如计算能力、IO等等。

b、服务的设计、编排
需要从业务的承载要求、客户消费方式、业务系统架构、部署方式、虚拟化方式、集群、资源类型做统一的规划设计。根据对客户现有情况的分析，尤其是IT系统现状、痛点等，得出客户的期望，进而设计出客户需要的服务。

c、服务与资源的关系
很多人搞不清楚什么是服务，什么是资源，甚至有个号称云架构师的人跟我说，他实现了对虚拟化的纳管、资源调度，就是完整的云。

资源（resource）：在系统中， 基础设施、network设备，VM、host、OS、CPU、Memory、存储、software等等都被视作可分配资源。

服务是云计算的核心特征，根据业务要求等可以编排服务，使之能让客户消费，通常会绑定价格、SLA等一些附带属性。

d、租户与组织的关系
要想清楚，根据客户现状，组织与租户怎么对应，是1对1，1对多，还是多对多。

e、资源调度的原则
要考虑资源调度策略、资源类型、性能要求，同时要考虑弹性的时候如何伸缩。经常会有只能scale out，不能scale in，或者频繁scale out、in的情况出现。那么在考虑弹性判断条件、算法的时候，要综合几种监控告警数据，如业务、资源。

二、IaaS方案

1 IaaS架构影响因素

很多因素都会影响企业IaaS架构的选择，主要有：企业IT发展规划、企业组织架构、企业管理制度、业务类型、应用层次、人员技能、技术成熟度、成本、周期、运维体制。。。

如果不考虑其中的某个因素，都有可能导致项目的失败。我曾经亲身经历过，因为管理和客户组织架构原因导致的云项目失败。

客户在实施云计算建设之前，业务部门是强势部门，IT部门是支撑部门，而在规划和建设中忽略了客户组织架构的影响因素。

IT部门变成了云平台的管理者，业务部门成为相对弱势的云服务消费者，导致客户内部组织架构重组、项目停滞。

2 私有云IaaS平台构成
广义的云平台，分成几大部分：门户（管理和自服务）、服务层、统一资源层（含适配器层）、基础设施（含虚拟化），紧密相关的有BSS、OSS子系统；外部可能交互的系统有ITSM、CMDB、外部监控系统、4A系统和通知系统等。我画了一个主要部件的草图，方便大家理解：

门户分为管理和自服务，分别给管理员和普通用户提供服务；用于展示基础设施、平台及软件服务，并控制用户接入方式，对用户的访问范围、界面的展示方式做设定等。以便于管理员和普通用户获取服务的信息，申请并使用各类服务。

服务层指服务构建与设计的逻辑组件，它负责定义服务的结构、流程等信息，组装原子服务，生成业务服务，发布到服务目录，监控服务运行状况等，形成完整的服务生命周期管理。业务用户可以通过服务管理层获取云计算服务；管理员可以通过服务管理层监控所有服务实例的整体状况；服务开发人员可以通过服务管理层定义和发布服务。服务管理层将以业务服务的形式对外发布所有的服务操作接口。

资源层指管理和调度软硬件资源的逻辑组件，它负责构建资源池，生成简单资源供应的技术服务（原子服务），定义资源运维的操作流程。为了组成资源池，一般将同质的设备集中安装，相互连接，并通过一定的管理软件来监管和配置。资源池由同质的一组资源组成，用户可以通过资源管理层软件从资源池中申请资源，指定该资源实例的配置，并管理其运行。

管理员可以监控每个资源池的资源使用率，健康状况和性能状况。资源管理层将以技术服务的形式对外发布所有的资源操作接口。这一层要屏蔽掉虚拟化等的差异，使得上层无法感知。

基础设施包括计算、存储、网络，其中计算含各种异构虚拟化。

BSS和OSS源自电信行业的B和O，BSS负责营销、结算等功能；OSS负责监控、安全等。不展开了。

3 虚拟化异构

能否支持X86虚拟化异构、异构的支持广度是衡量一个云资源管理平台（区别与云服务管理平台）的一个重要标准。目前主流的虚拟化软件有几种：
Vmware、Hyper-v、Xen、Kvm、在kvm和xen上演化的各种版本。

在此不把容器作为虚拟化来考虑。

主要的实现思路是在资源层做统一纳管，用一套接口整合，也即适配器模式，每种使用一个适配器。在实际开发中，一般接口做二次抽象。

目前最常见的异构是VMWare和KVM（通过openstack纳管），目前有几种途径：

a、自行定制实现，调用vcenter或vsphere的接口
推荐使用这种方式。各企业商业发行版如，mirantis、hp hellion os商业版、racespace等，基本上不尽成熟，或者高级功能有缺陷。

b、VIO（VMWare Intergrated Openstack）
很多人和我推荐VIO，我个人不认同，理由有几点：
1）遗产系统接管。如果对于已有的VMWare虚拟化，VIO无法接管性能。

2）VIO部署在虚拟机上，作为vcenter插件，性能无法保障。

3）VIO本质上还是Openstack的一个实现，没有高级功能。

4）如果需要SDN，要集成NSX，成本等各方面都需要考虑。

4 小机与X86异构

除了X86虚拟化异构，还要考虑小机（主要是IBM power）、物理机、虚拟机的供应，这时也要考虑小机的纳管需求。采用的方式也是在资源层统一纳管，但接口会有独特性，一般用流程引擎调HMC解决。

5 Openstack及其应用场景

Openstack现在持续火热，各大厂商都在积极参与，本人也参加过openstack峰会。结合工作中的实际，Openstack长期来讲是个好东西，适合一定场景的应用范围，目前也应用的越来越广泛，但并不普适。可以应用在：

开发测试环境、非关键业务、科研实验环境

Openstack需要解决的问题有：

稳定性、可升级、高级功能，如HA等、遗产接管

此外，我认为Openstack存在贪多求快的问题，面铺的广，不够扎实，主要使用的还是那几个核心模块。

6 SDN不是企业级私有云基本需求

我曾经设计了一个集成SDN和NFV（部分功能，如SLB、VFW等）对的拓扑设计器，但在具体的企业级客户中，并没有太多客户迫切需要SDN。都会提到、以后扩展到SDN的实现，而不是眼前，从长期趋势来看，前景广阔，市场无限。

SDN主要应用在几个场景：

公有云，租户定义私有网络
私有云，需要频繁变更网络拓扑的环境，如开发测试、科研等
电信、IDC等

7 云管平台部署架构

云管平台的部署和普通的SaaS网站没有什么不同，都是SLB加HA，后端应用集群、数据库集群，一般没有很大的压力。
三、云不一定节省成本
我知道我这个观点可能很多同行要扔搬砖，可是作为一个驾狗狮，虽千万人吾往矣。。。

规划、设计和建设周期长。云平台要承载所有准备上云的业务系统，考虑因素较多，如前述。

前期采购成本高。前期资源池建设采购的设备数量较多，占用大量的机房、电源等资源，投资和运维成本均较高，一定时间内会闲置。前期规划能力不足，也会造成资源浪费。

对企业的组织管理制度可能会有调整。单体人员技能会有较高要求，造成行政和人员成本升高。

管理维护成本高、维护力量无法分层。维护人员要分成不同的团队，分别管理云平台和业务，必须熟悉平台所涉及的所有的软硬件资源，维护效率不高。

人云亦云，并不少见。尤其是资源池较小的情况下，纯属浪费。

四、IaaS私有云平台构成

如上所说，我们已经分析了企业级IaaS平台架构设计中要考虑的一系列因素，其中提及了对于遗产系统的纳管——这也是私有云区别于公有云的主要特点之一。

在当前需要建设IaaS私有云平台的企业中，往往要考虑多种遗产系统、异构虚拟化资源的统一纳管。

以下简要介绍：

这里讲的是广义的云平台，我一般认为分成几大部分：门户、服务层、统一资源层、基础设施，紧密相关的外部系统有BSS、OSS子系统；外部可能交互的外部系统有ITSM、CMDB、外部监控系统、4A系统和通知系统等。逻辑架构图如下所示：

门户分为管理和自服务，分别给管理员和普通用户提供服务。用于展示基础设施、平台及软件服务，并控制用户接入方式，对用户的访问范围、界面的展示方式做设定等。以便于管理员和普通用户获取服务的信息，申请并使用各类服务。

服务层指服务构建与设计的逻辑组件。它负责定义服务的结构、流程等信息，组装原子服务，生成业务服务，发布到服务目录，监控服务运行状况等，形成完整的服务生命周期管理。

资源层指管理和调度软硬件资源的逻辑组件。它负责构建资源池，生成简单资源供应的技术服务（原子服务），定义资源运维的操作流程。所有异构主要在这一层解决。

基础设施，包括计算、存储、网络，其中计算含各种异构虚拟化。

BSS和OSS源自电信行业的B和O，BSS负责营销、结算等功能；OSS负责监控、安全等。

接下来讲正题，怎么在上述云平台架构中实现异构资源纳管：

五、异构资源纳管与调控

1 小型机与X86物理机异构

根据市场分析报告，目前小型机市场约占整个中国服务器市场的9.1%。2009年以前X86服务器稳定性较差，2012年开始随着X86架构的突破和技术成熟，稳定性已经超过Oracle小型机，逐步接近IBM小型机SLA，而成本仅为小型机的30%左右。

但在另一方面，存量小型机会在企业系统一段时间内存在，IaaS私有云平台在考虑遗产接管时，需要考虑小型机和X86的异构管理。以下以Power小机的管理为例，试述异构管理的架构设计思路，其它品牌，如HP、Oracle小机也可以采用类似的策略。

对于小机的虚拟化使用相对较少，主要是直接在小机上部署操作系统、中间件、数据库及其它软件，用以承载业务。本小节中，X86只考虑物理机部署，因此部署的软件要求和小机类似，虚拟化软件以后再具体探讨。

以物理机部署为例，有两种典型的方式，我戏称为土豪架构和平民架构，实际上分别代表了商业级自动化部署软件集成架构和开源软件集成架构，本质是类似的。

商业级自动化部署软件集成构架

此类方案以相关商业级产品为代表的软件集成方案，相当于对小型机做有代理的远程自动部署。如惠普的流程调度软件HP OO（Operations Orchestration），可以调用另一款软件HP SA（Server Automation）去做操作系统的远程部署。

支持的范围包括AIX、HP Unix，各Linux发行版、windows等。其它各大公司的集成方案也可以实现类似的效果。集成架构图如下：

方案的核心是服务器自动控制和部署组件，该组件包含文件服务器、Agent和应用服务器三个模块，介质库存放软件安装介质、操作系统安装介质、安装脚本等；Agent安装在操作系统中，执行应用服务器推送的各种指令并返回结果；应用服务器接收交付层传递的指令并执行相应的自动化任务。

此类架构的特定是集成为主、方案相对简单、成熟；缺点是成本较高、范围受相应软件限制。

开源构架

实际上实现架构和上一种方式大同小异，通过集成开源规则引擎（如Drools等）加相应的控制脚本（基于PXE/IPMI、HMC等不同方式）实现。

在设计上做两层抽象，第一层是资源类型，第二层是对资源类型的操作、接口。

以管理物理机为例，第一层定义的类型是Host，需要设计的接口含getHost，listHost，operateHost，monitorHost等等；

第二层定义Host的Operation、Info、Monitor等，需要设计的接口有getHostInfo,asyncHostInfo，getHostAlarmList等等。针对不同的设备，通过不同的适配器实现相应的接口，如X86适配器通过PXE/IPMI部署X86物理机、通过VCenter API管理VM的部署、电源操作等。如下图类似的接口定义：

这种方案需要考虑的主要因素是接口的参数在哪一层级、多大程度上统一。

优点是灵活度高、不受限制，缺点是需要自己定义实现、有一定的技术门槛。