“云不一定节省成本”——云产业发展观察与企业级iaas建设实践

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

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

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

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

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

a、政策驱动

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

b、人云亦云

不解释：）

c、新技术跟进

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

d、为业务而云

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

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

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

我把顺序反过来，先说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. 企业IT发展规划

2. 企业组织架构

3. 企业管理制度

4. 业务类型

5. 应用层次

6. 人员技能

7. 技术成熟度

8. 成本

9. 周期

10. 运维体制

11. 。。。

如果不考虑其中的某个因素，都有可能导致项目的失败。我曾经亲身经历过，因为管理和客户组织架构原因导致的云项目失败。客户在实施云计算建设之前，业务部门是强势部门，IT部门是支撑部门，而在规划和建设中忽略了客户组织架构的影响因素。IT部门变成了云平台的管理者，业务部门成为相对弱势的云服务消费者，导致客户内部组织架构重组、项目停滞。

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

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

    

    

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

      

    

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

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

      

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

     

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

能否支持X86虚拟化异构、异构的支持广度是衡量一个云资源管理平台（区别与云服务管理平台）的一个重要标准。目前主流的虚拟化软件有几种：

1. Vmware

2. Hyper-v

3. Xen

4. Kvm

5. 在kvm和xen上演化的各种版本

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

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

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

1. 自行定制实现，调用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，成本等各方面都需要考虑。

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