分享

云来了，安全盒子怎么办

by 何恐，一个安全人

前提和假设：

本文主要讨论“当下的”私有云安全，公有云不在此文范围内

1、云带来的安全挑战

近两年，云计算发展迅猛，新建的IDC如政务云，行业云，绝大部分都是云机房。云计算是大势所趋已经毫无疑问，已开始遍地开花。

关于云环境下如何做网络安全防护，常听见一种观点：云是颠覆性的，传统硬件安全设备完全不适用云环境。

那么，云来了，安全盒子到底该怎么办？

从本质上来说，对于网络安全设备，云带来的最直接挑战有两个：

1、 主机虚拟化

2、 网络虚拟化

云主机虚拟化带来的挑战

传统机房里面，每个租户的服务器是看得见摸得着的。在云环境下，租户的服务器变为了一个个运行在硬件服务器上的虚拟机，一个租户的虚拟机，可以位于不同的硬件服务器上，这是形态的变化，会引起租户的边界，从传统物理边界，变为动态、虚拟的逻辑的边界。

另外，因为一些历史原因会出现软硬件资源混合的情况。某些服务器不方便虚拟化，如历史遗留的数据库服务器，就需要和虚拟资源一起组成租户的计算资产。

最后，不同虚拟化厂家，如vmware，citrix，Hawei，H3C，各家的hipervisor系统不兼容，也会给安全厂商带来适配的工作量。安全厂家如果要以虚拟的形态运行在虚拟环境里面，需要适配不同平台的虚拟机格式。

因此，传统安全硬件要继续发挥作用，首先就要能够识别和保护虚拟的资产域，并且以动态的方式，切入到虚拟计算环境里面去。

另外，现在的运营商也不喜欢硬件盒子了。毕竟专用的盒子，利用率低，又互不兼容，运营商希望用通用的X86服务器来运行虚拟的安全设备，类似NFV，来提升经济性，可扩展性，以及适应业务快速可变的要求。

网络虚拟化带来的挑战

如果按照vmware 1999年发布VMware WorkStation算起, OS虚拟化的发展时间已经不短了。但是，仅仅是服务器形态的虚拟化，还不足以支持云的发展。在云环境下，要满足云的虚拟性、动态性，还需要将网络也虚拟化。

第一个问题是传统vlan的4K问题。传统vlan因为tag字段位数限制，只能支持最多4k个vlan。但是在云环境下，租户的数量非常多，4K上限是不能满足租户数量的要求的。基于这个目的，扩展vlan tag字段位数，重新对ip报文做wrap，以便于支持更多的租户容量，采用类似vxlan这种方式来划分网络是主流方式。对传统安全盒子来说，首要问题就是能识别vxlan报文。另外vxlan带来的不仅仅是报文tag改变这一点点内容，vxlan带来的相关的网络控制方式改变，调度，如服务链、SDN等等，也都是安全盒子需要去适应的。

另外，云环境下业务动态变化非常频繁，靠传统硬件去动态开通或者销毁一个业务，显然是不行的。之前大家只知道需要把服务器虚拟化，后来随着云虚拟机数量规模的扩大，大家逐渐意识到光服务器虚拟化还不够，需要把网络部分也虚拟化，软件化，并自动化。举个例子：某租户需要开通一个业务需要一台路由器，过一段时间又不需要了，硬件路由器可以满足这样的频繁变化吗？硬件盒子，必须要也可以动态灵活的部署进去才行啊。

再加上云环境为了满足虚机动态迁移，需要在一个大二层，传统二层设备没办法支持这么巨大的mac表项，这一块也需要新的二层技术，如vxlan的支持。传统网络显然不行的。

还有，租户都有自己的vpc，IP地址范围很可能是重叠的。传统硬件设备大部分是不支持这个的，大部分不具备硬件设备虚拟为多个硬件设备的功能的。租户是逻辑的、虚拟的，是接在“逻辑交换机”上的。逻辑交换机本身就不位于任何一个固定位置，是通过计算机节点overlay的方式，分布式部署的。因此，对多租户的安全检测能力，是传统安全盒子不具备的，这显然无法适应云安全的要求。

最后，SDN控制网络，控制和转发平面分离，也使得云环境的网络和传统网络大大不一样。传统盒子如何接入如何适配新的网络架构，这个也是需要有一个重大改变的。之前安全盒子通过策略路由、桥接、分光镜像等方式接入网络做安全检测的方式，在SDN网络架构下已经不能适用了。传统安全盒子，需要按照新型网络的控制方式，来接入业务流量。否则，就完全不能发挥作用。

总结

上述挑战，传统安全盒子通过交换机、路由器、分光器等物理方式接入租户网络的方式，在云环境下就失效了。要继续发挥作用，传统硬件必须要解决在云环境下的接入问题，要做到看得见、认得出、防的住，才行。

除了接入问题，安全盒子还需要适应云的弹性。硬件固定性能的盒子不容易弹性扩展，在云里面，安全也要像计算资源一样，可以动态的、弹性的扩展。

总的来说，云是利用资源的新的方式，安全本质并没有发生变化。但是，安全发挥作用的方式，需要根据云的变化而调整，才能继续有效。

2、 什么是东西向流量

凡提到云防护，必然会听见“东西向防护”这个词。那么，什么是东西向流量？

下面这幅图，是传统IDC的流量走向：

可以看到，大部分业务流量，都是从外到内为主，安全防护设备，也集中在由外到内的防护路径上，我们称之为“南北向”防护。

IDC云化以后，服务器的规模，包括虚拟机的数量，都扩大了很多。横向的虚机密度大大增加，也因此衍生出租户和各种复杂的网络虚拟设备，如下图：

传统IDC的安全问题，主要集中在①这个位置。云化以后，流量问题复杂化了，衍生出②、③、④、⑤这几个新的情况，防护也因此而有所不同。

在云网络内部，租户之间是隔离的，互相访问要通过vpn或者隧道访问。租户内部可以划分不同的子网，子网之间，子网内部虚拟机之间，虚拟到外部，外部到虚拟机，都会产生访问流量，安全问题也由此而生。

重要的是，这些流量往往产生在云内部，甚至不出服务器（如同一服务器内部虚机之间的流量）。因此这些流量，对传统硬件盒子不可见，从而也无法防护。这些流量，会成为一个真空地带，一旦发生安全问题，如虚机中木马或者病毒，将会迅速在云内部蔓延，并难以进行防护控制。这种情况是非常可怕的。根据《云等保增补方案》同等防护的原则，云内部流量也需要进行同等安全强度的防护，防护缺失是无法接受的。

综上，南北向流量，主要是指外部公网进出云计算内部的流量。东西向流量，主要是指租户内部虚拟机的访问所产生的流量。注意，东西向流量在这里是泛指租户相关的流量，并不仅仅是从外到内的流量。如果外部流量访问虚拟机，需要按照不同租户的策略来防护，此刻也称之为“东西向”。

南北向防护，传统方案都可以继续有效。而东西向防护，是云化后的机房新增加的需求。本文后面的讨论，主要集中在东西向防护方案。

3、 现有东西向防护方案

凡是解决方案，出发点都是根据安全厂商自身情况优先考虑。同样的，对客户而言，“反厂商绑架”也是自然的诉求。

虚拟OS厂商的方案

虚拟OS厂商，指的是虚拟系统厂家。这类厂家因为掌握了虚拟操作系统，所以自然考虑从虚拟系统本身入手来构建安全方案。通用的示意图如下：

虚拟操作系统厂家，通过在虚拟系统网卡之上增加驱动过滤层，将虚拟机的流量截获，将流量导向系统内置安全模块，或第三方的安全虚拟机，进行安全防护。

从上图可以看出，对内部流量的防护，利用了计算节点本身的计算能力进行，流量在出计算节点之前，就得到了有效的防护。

这种方式有他的优缺点。优点是，在靠近虚拟机的位置进行防护，能够在最短路径上防护，同时流量不出计算节点，不会对云内部骨干网络，造成额外的流量负担。另外随着虚拟OS的部署，安全能力随之部署，在部署上也会比较便利。

缺点也很明显，首先是第三方安全厂商必须获取虚拟OS的防护API授权，才能引入自己的安全虚机，如vmware的nsx认证。对于虚拟OS厂商来说，自然不愿意第三方碰自己的蛋糕。比如vmware的NSX模块，终端用户须付费购买，第三方安全厂商须通过商业认证。只有同时满足这两个条件，用户才可以用到想要的安全厂商的安全能力。

另外一个缺点是安全模块和安全虚机运行在计算节点，会占用计算资源。对于计算资源紧缺型的用户，或许无法接受。同时安全能力和计算能力混合在一起，出现问题的时候，排查责任也会有较高的复杂度，互相依赖交叉的情况，会对虚拟OS厂商和安全厂商造成同时困扰。

最后一个缺点，是安全虚机厂商多样性也会有问题。不同厂家的安全虚机，要同时出现在同一个计算节点上，技术上会有很大的问题。从客户长远利益考虑，客户需要一个比较好的，兼容各个安全厂商的安全架构，或者说良好的生态圈。

网络厂商的方案

这类厂商，以传统网络数通厂家为主。云化，不仅仅需要服务器虚拟化，也需要网络的虚拟化。流量可以在计算节点的驱动层捕获，也可以在网络层面捕获。我们知道，业务流量在哪里，安全问题就在哪里。因此对于网络安全盒子来说，在网络层面接入才是正道。

如上图所示，SDN网络，控制面和转发面分离，通过控制器来集中控制所有流量的转发。在SDN网络内部，可规划安全区。在安全区域，安全虚拟机或安全设备，可注册为服务节点。在SDN协议字段里，通常有服务字段。通过设置服务字段的值，即可控制任意的流通过指定的服务节点。

那么，安全盒子的部署，在这种情况下，也简单了。只要把安全盒子或者安全虚机，部署在服务区域，并注册为标准服务节点，即可利用SDN的服务编排能力，“指挥”任意流量，经过相应的安全节点，从而完成安全防护。

同时，SDN也有强大的网络控制力，可以实现流量镜像到服务节点，以及把服务节点的虚拟机工作口，绑定到用户VPC从而完成扫描类任务。

因为流量调度，通过网络进行了横向迁移，此刻可能大家会担心对网络带宽占用问题。为因对此问题，SDN网络内部增加了横向交换机的密度，所谓spine-leaf架构，通过增加横向带宽，来满足流量横向迁移的能力。

这种方式的优点很明显：通过设置服务节点，将流量通过网络调度的方式，进行服务编排，可以很方便的接入第三方厂商的传统盒子以及安全虚机。同时，因为通过网络控制器来进行流量牵引，可以自然兼容大部分hipervisor OS厂家——因为引流和虚拟OS没有关系。

缺点主要是增加了横向流量，会增加一部分网络建设的开销。另外在网络时延方面，不如内置在计算节点的方式。最后，采用这种方式，网络设备必须是支持服务编排的SDN网络，这对于采用传统网络方式的客户，增加了改造费用。

传统终端安全厂商的方案

传统终端安全厂商，优势在于有安全终端，劣势在于没有网络产品，也没有虚拟操作系统产品。那么，自然会从自身优势出发，在虚拟机操作系统内想办法来构建安全能力，如下图：

即：通过在虚拟机操作系统内，安装安全代理（通过虚拟机模板部署），以及在HiperVisor OS内安装安全模块，或称之为“无代理”方式，通过在HiperVisor系统底层以及虚拟机操作系统驱动层，捕获数据流以及文件内容，来实现安全防护。一般可实现杀毒、文件监控、网络防护等功能。

这种方式的优点在于，通过在虚拟机操作系统部署安全代理，避免了必须依赖虚拟OS以及SDN网络，而直接实现了流量捕获以及防护。另外，也可以充分利用计算节点的计算能力，无需额外增加安全硬件资源的投入，也不会引起流量的横向调度。

缺点主要有三个：一个是在客户虚拟机上安装代理，会有信任问题。如果客户数据比较敏感，可能不愿意安装第三方的程序在自己的虚拟机内；另外，如果要按照不同租户不同策略来进行防护，还是需要一个集中的管理中心和虚拟系统用户数据库进行对接，以便于识别租户以及下发相应的策略。第三个缺点是防护能力的多样化会有问题，即：很难在这样高度集成的架构内，开放的引入各家厂商的安全能力。

网络安全厂商的方案

网络安全厂家，既没有SDN产品，也没有虚拟OS产品。在这种情况下，往往会选择一个中立的态度来构建云内的安全解决方案。

网络安全厂商，优势在于安全产品线很全，可以很快的将安全盒子，虚拟化为各种安全虚机，并池化。如下图：

通过在标准x86服务器上，安装各类虚拟机，并形成安全池集群；然后，根据租户的需求，构建虚拟的安全能力，如虚拟WAF，虚拟IPS，以对应虚拟资源的概念。这样做可以将以前安全盒子专属硬件才能提供的能力，灵活的虚拟化到通用硬件，客无须再采购专用硬件，可就地利用虚拟服务器来作为安全池的部署环境，甚至利用现有的虚拟资源池来部署安全虚机。

那么剩下的，就是通过各种方式，将流量往安全池牵引，以实现安全防护。具体的引流方式，需要结合用户网络环境来实现。比如通过SDN API引流，通过传统路由器进行策略路由方式引流，通过虚拟/传统交换机镜像口引流，以及在计算节点内安装引流代理，通过代理方式引流。如下图：

上图的微代理，可以看作一个特殊的虚拟交换机。如果VM2需要被防护，那么只需要拆除VM2和原有虚拟交换机的连接，并将VM2的虚拟网卡，连接到微代理，微代理用TRUNK的方式再连接到虚拟交换机上，这样便不会破坏原有VM2的VLAN拓扑。然后，所有VM2的流量就会经过微代理，即使是同一个计算节点内虚机之间的互访流量，也会被微代理截获。截获后的流量，通过隧道送往安全池过安全策略，然后发回原有微代理进行正常转发。

这种方式的好处在于，通过池化安全能力，可以构建弹性、多样化且开放的安全池，方案本身符合云的特性。同时利用各种引流手段，能够灵活的实现安全防护。

缺点在于，引流方式会带来额外的带宽占用和延时。同时，需要对接不同的客户网络方案，对接成本较大。

总结：

综上，可看出目前云环境下，缺乏统一的网络安全设备部署环境，目前局势还有点混乱。从另一个侧面，也看出虚拟化发展过程中，基础设施对于安全方面考虑的缺失。

4、 关于变化和发展

安全能力池化

传统的安全能力，都是通过固定的硬件盒子的形式提供的。在云时代，这种情况将发生变化。固化的安全能力，不能匹配云防护的要求。安全能力池化，首先是将传统的安全能力（引擎）虚拟化，其次是可弹性伸缩的安全池，最后能适应云环境的部署方式。云环境都是有租户的，那么云平台除了提供基础安全能力以外，也需要提供不同租户需求的不同安全能力套餐，并做到可运营。这样做的原因，本质是为了匹配云的特点：弹性，敏捷，虚拟化，可运营。

未来，传统硬件盒子的份额，可预见会持续下降，虚拟化安全产品的份额则会持续提高，此消彼长。传统盒子为了适应虚拟化，数通部分的模块会退化，引擎部分会持续强化。

在安全池基础上，需要有一个运营平台，对安全池进行统一管理，对安全业务进行灵活的开通、计费，并按照租户查看报表，以及云内部整体态势等功能。传统盒子的安全视角，是基于设备的。云安全池的视角，是基于运营平台的，安全盒子（虚机），只是平台下的一个基础模块。

最后，安全池是软件不是硬件，安全池泛指所有安全能力的集合，包含以安全硬件、安全虚机等组成的混合能力的“池”。

内嵌模式和外置模式互为补充

内嵌模式，指的是安全池内置在计算节点内，充分利用计算节点的计算能力进行安全防御的模式，简单可认为如下图所示：

外置模式，正好相反，安全能力放在单独的通用服务器内，如下图所示：

关于这两种方案的优劣势，争论很多。总的来说，内置式的最大优点，是充分利用计算节点进行就近防御。外置式最大优点，是有单独的安全能力空间，不占用计算资源。

不论安全厂商如何声称哪种方案好，从技术角度看，这两种方式实际上是互补的。外置安全池，更适合通过网络调度能力比较强的场合，以及以网络流量防护为主的场合；但是对于网络调度能力弱，需要结合local防护的场合，就适合内置方式。比如HWAF，本地杀毒，就近阻断，以及想在宿主机OS上搞点事情的场合。

外置和内置模式，都有对方干不了的事儿。从技术角度看，互补能够形成最完整的解决方案，缺一不可。无论目前坚持哪一派的厂商，最终都会走到这条路上来。从看见的客户实际需求，以及大厂的收购路线，都能印证这个趋势。

平台为王

传统盒子都是以卖盒子为主要销售模式。云机房，不但需要虚拟化的安全盒子（池），还需要处理和虚拟系统的对接以获取租户信息、vxlan信息，SDN引流对接；另外从运营模式看，云平台除了提供基础防护，更重要的是提供满足租户多样化需求的可运营的平台，并满足增值收入。

传统机房只需要安全盒子接入，最多加个网管软件，即可完成销售。对云安全来说，这是不够的，需要提供平台能力，通过将虚拟化能力引入平台，并将平台和云平台的对接，从而提供云防护能力。

云安全平台的模式和盒子不一样，平台模式是平台先行，盒子和虚机随后逐步建设。从这个角度看，得平台者得天下。平台模式示意图简单如下所示：

分享

分享

包云岗：中科院计算所副研究员，主要从事高效数据中心(ResourceDfficient Datacenter)体系结构与系统性能评测分析方面的工作。个人主页: http://asg.ict.ac.cn/baoyg/ ，新浪微博: @包云岗。

大概在2012年夏天，那时我还在普林斯顿大学，思考过如何从计算机底层的体系结构入手支持资源管理，消除计算机硬件层次上的“无管理的共享”。当时普林斯顿计算机系有好几位教授正在开展软件定义网络SDN方面的研究，也邀请很多大牛来做报告，比如SDN主要发起人之一、UC Berkeley的Scott Shenker教授等。平时和朋友也经常会聊起一些SDN的技术问题。网络早就面临着多业务共享与服务质量的问题，因此QoS技术（如区分服务）也相对比较成熟。而SDN则可以通过标识网络包、增加控制平面、增加可编程机制使网络管理变得更灵活方便。

当时就有一个想法——“其实计算机内部也是一个小型网络，那是不是可以将SDN技术借用到计算机内部呢？”于是写了一个5页的备忘录，题目叫《Software Defined Architecture：The Case for Hardware-EnabledVirtualization》，就搁起来了。2012年10月份回到计算所后组建了一个小团队。所里很开放，让我自己选择研究方向和内容，于是我把在普林斯顿的想法拾了起来。但那只是一个很粗略的想法，我们经过大半年的调研与摸索，不断调整目标与技术路线，在2013年中有了比较清晰的思路。我们将这个思路凝练为一种新的计算机体系结构，叫“资源按需管理可编程体系结构PARD（Programmable Architecture for Resourcing on-Demand）”。

仍然用城市交通作为例子，PARD体系结构的核心设计理念其实很直观且易于理解：（1）将车辆根据不同的用途进行涂装并安装鸣笛，救护车是白色加红十字涂装，消防车涂装等（对计算机内部流动的数据包贴上标签）；（2）在一些关键路口设置红绿灯，在加油站、维修站等服务点设置管理装置（在计算机内部关键位置增加控制平面）；（3）制定交通规则，红绿灯对救护车、消防车等关键车辆可以随时放行，而其他车辆则需要等待绿灯放行，而那些服务点也是优先服务那些关键车辆（根据不同标签来区分处理数据包）；（4）交通规则可由管理部门根据需要进行调整，比如道路上新出现一批武警巡逻车，就为它们设立一些管理规则（管理员可以调整处理规则）。

事实上，我们日常的交通管理正是采用了这些理念。只要执行严格到位，这样的交通管理系统能在保障救护车等关键车辆顺利通行的前提下提高道路利用率。而PARD体系结构也正是希望通过相同的设计理念实现计算机内部高效灵活的资源共享与性能隔离，从而在多种应用混合的数据中心环境下，能在保障关键应用的服务质量前提下提高资源利用率。

假设PARD技术被验证是可行的（也很可能是不可行的，因为还有太多不确定的未知因素，所以还需要更深入的研究），那么将会有很多新的应用场景。比如对于云计算，可以做到做到更有效的分级服务管理，类似于航空公司的VIP服务，有的愿意多交钱，享受更稳定的服务质量，甚至是一下特殊服务，比如硬件提供的加密或压缩服务。

目前PARD第一阶段软件模拟器验证已经初步完成，还在进行第二阶段FPGA原型系统验证，有了进一步进展后希望能跟大家汇报交流。

最后，简单聊几句另一个Matrix，即《黑客帝国》。我想《黑客帝国》设想了一种场景从技术框架上是可行的，今天的云计算模式其实正是朝着这个方向发展。数据中心就像是“母体”。在《黑客帝国》中，所有人都会接入到母体中，在虚拟世界中工作生活。而如今，我们也是通过各种移动设备接入到数据中心，越来越多的时间是在数据中心上度过的。就如我们刚过去的一个多小时，就是在腾讯的数据中心上度过的。等到哪一天，我们的脑机接口有突破，人们不再需要手机这种“原始”的设备，而是可以直接通过大脑来接入数据中心，那么《黑客帝国》中的场景可能真的会成为现实。谢谢大家！

分享

分享

http://www.valleytalk.org/wp-content/uploads/2014/06/浅谈IaaS.pdf

图画得不咋地，不喜欢的可以直接看下面纯文本。
写不动了，自娱之作，版权license遵循WTFPL，具体可查看《从半空看虚拟化》一文：）

1 前言
云计算进入红红火火的落地部署阶段，IaaS、PaaS和SaaS（为省点儿事，后文同时提这三个aaS时均以XaaS替代）也成为大家挂在口头上的热词儿。厂商、运营商和用户，谁也不甘落后。“我能承建IaaS”，“我能提供PaaS服务”，“我需要SaaS部署”。。。在站队之余，跨界也成了硬道理，厂商想要XaaS产品全销售，运营商想要XaaS服务全提供，用户想要XaaS业务全部署。纷纷攘攘，这场云计算大乱斗不知何时方休。
100个人心中有100朵云，借此文章分享一下作者对云的认识，望有参考。
本文重点放在IaaS建设相关内容上。能力有限，对PaaS和SaaS不做深入分析。
2 XaaS关系
2.1 云的由来
想了解什么是云，什么是XaaS，先要知道他们是怎么来的。印象中，7-8年之前的“云”可没有现在这么火，那时热炒的还是DataCenter。
云概念出现之前的IT结构可简化如图1所示，其中网络和存储可以理解为计算的外延，毕竟没有服务器，啥IT建设都是扯淡。

图1. 传统IT系统结构
应用软件又可以细化为多层结构，以一直流行的BS结构为例，可以简化为WEB（前端）-APP（中间件）-DB（数据库）三个大的层面。当然前端可以做缓存和分布式，中间件又可以分层，数据库也有分布式数据库或者数据库前端等等更细的层面，技术扩展开无穷无尽，这里做结构分析先以这三层举例就够了。

图2. 传统IT系统结构-应用分层
权且先将图2作为传统IT的业务系统结构图，图中各个元素由上到下是逐层调用，逐层访问的，可以将下层元素视作为上层元素的可用资源，跨层则不可见也不需要关心。
那什么是云呢？个人理解云就是将图2中各个元素层次之间插入一个接口平台进行下层资源的统一调用，实现规模弹性扩展。对于上层元素，下层元素的具体实体与操作细节都被中间的云层屏蔽掉了，只需根据需求调用接口实现功能即可，不需了解下层元素的内部实现，就像站在云上一样。以前是跨层不可见，现在是上下层也见不着了，因为中间被插入了一个云层。云技术的关键是无限扩展和统一调用，简而言之就是要大而简。
举两个例子：
1、当图2中计算资源云化后，对于操作系统而言，所有的配置调度都是通过云层管理台接口完成，只需知道是安装在X个某性能的CPU，Y大小内存，Z大小的硬盘等等环境的服务器上，至于这个环境是虚拟机还是物理机，是IBM还是DELl品牌服务器，挂的是什么型号的存储磁盘，用的VLAN还是VXLAN网络等等，统统不清楚也不需关心。只要有个平台能提供这些硬件的或虚拟的资源接口即可。
2、当图2中DB层面云化后，中间件也只能通过云数据库的管理平台去使用数据库资源。对其而言这时只需有个支持XX连接数，YY处理能力的数据库表或实例，提供对应API接口能够调用即可，同样不需要关心下面跑的是MYSQL还是SQLServer，更不用管跑在什么样的底层操作系统和计算资源之上了。
计算机技术的发展历史就是一部中间层不断扩大的过程，最早期的计算机是应用程序直接去调用硬件资源，后面慢慢才有了图2中操作系统和数据库、中间件等平台软件的内容，现在继续向里面填充各个云层也是很正常的发展思路。这种多层次调用模型的好处是，对用户而言，简化了资源配置过程；对管理员而言，统一的云管理平台操作更加方便。坏处则是调度层面变多，运行效率变低，故障风险加大，出了问题很难快速定位。有得必有失，想坐享便捷就要有承担风险的思想准备。
再多说一句，在资源层之间添加中间调度层的思路其实古已有之，一直伴随着人类的发展。我们想走得更远更舒服，于是在脚和地面之间有了鞋，有了车。我们想吃得更好更便捷，于是在手和食物之间有了筷子勺，有了刀叉。我们想见得更广更清晰，于是在眼和景物之间有了眼镜，有了摄像器材。人类的进化史就是身体与物质资源层之间工具层的进化史。对于计算机技术的进步来说，云层化同样是必然的发展方向，应用程序到硬件实体之间的层次会持续不断的扩充。
2.2 XaaS技术构成
如图2中几乎每一个元素层面为了达到大而简的效果，都发展出了各自的云化技术，这些云化技术既可以结合使用，也可以独立使用。举例一些代表性技术如图3所示。

图3. 云化IT系统技术结构
XaaS层次划分上，底层的计算、网络和存储属于IaaS无疑，前端WEB属于SaaS，中间件属于PaaS。这些都是公认无疑的，但操作系统和数据库两个层面的划分就是仁者见仁的事情了，更准确的说法是屁股决定脑袋，处于下层的设备商或IaaS服务提供商，肯定希望把这两个层次拉低到IaaS来，但精于软件的中间件厂商或PaaS运营商则希望拉升到PaaS上来。作为用户其实大可不必纠结这两者到底是哪个aaS，只要能用即可。
PaaS和SaaS之间同样存在很多灰度，千变万化的软件结构远比底层复杂，不熟不谈。
再强调一点，XaaS之间不存在必然关系，我们可以在IaaS层面上跑传统的业务结构，也可以将SaaS或PaaS运行在传统物理服务器和FC存储上，谁离开谁都能活。当然一些追求高大上的用户希望XaaS全建设，所有业务应用都要运行在SaaS模式下，SaaS要通过PaaS提供架构服务，PaaS需要IaaS做资源支撑。说句掏心窝子的话，这就是作啊。
2.3 系统设计原则
给新系统设计提几个建议供参考：
1、大道至简
系统越复杂，建设周期越长，关键节点越多，故障概率越高，问题越难解决。
2、自顶向下
先考虑面向最终用户的应用，再逐层提需求向下设计。如果先把下面敲定了，建到上面和业务系统对接时发现驴唇不对马嘴，就只能自吞苦果了。
3、长远架构
架构设计一定要估算到未来10年的业务需求变化，不求精细，也必须有所打算，否则跑了两年架构满足不了需要，那就得整个系统推倒重来。虽然早晚会重构，但能多挺一年就省一年的钱。
4、短期产品
目前整个业界都不流行长生命周期产品，归根结底是最底层芯片技术和最上层业务量发展速度决定的，芯片两三年换一代，数据量一年要翻好几倍，3-5年升级换代一批产品是很正常的事情。如果真遇到10年8年不用换情况，并不一定说明用的产品多NB，十有八九是业务量一直上不去，凑合过日子而已。
5、跟而不追
新技术新概念层出不穷，既不能落伍，又不能冒进，跟而不追是一个尺度的把握。当新技术冒头后，学习了解和实验分析都是要做的，但系统设计时的选用务必谨慎，如果不能摸透宁可不用。
6、稳固多变
系统架构要稳固，不能经常受新概念的冲击而贸然变化。好像人的骨架，成型后轻易不变，动则影响巨大。部件细节要多变，发现满足不了业务需要或可靠性不够就立即更新。好像人的肌肉，发现赘肉后要抓紧锻炼，否则久了会拖累全身。
总体来说，一个健康持续发展的系统，其生命周期应该是：首先根据用户的业务需要自顶向下，逐层设计，设计架构要尽量简单明了，可扩展性强，充分考虑到中长期的业务发展规模及承载能力，并采用前期实验分析过的较成熟技术搭建。系统架构设计完成后，选择已有一定部署规模的稳定产品实施运维。在系统使用过程中，根据运行表现和业务发展情况对局部产品技术分阶段更新替换。当整体系统架构性能发挥到瓶颈，已经制约了业务能力发展的时候，进行重构，建设新一代系统，并逐步将原有业务迁移到新的系统中，实现稳定平滑过渡。
由产品更新到系统重构是一个量变到质变的过程，所有变化的根因都应该是业务量不断发展扩充的需求。不要盲目的被新产品技术理念所诱惑，适合的才是最好的，“新”同时还意味着 “风险”、“不稳定”等含义。
3 IaaS结构设计
IaaS关注的是基础架构的云化，和以往的Datacenter建设理念最为接近，IaaS架构设计也和数据中心架构相似。
为了文章整体表述的完整性，下文如网络和计算虚拟化部分都涵盖了以前写过一些其他文章的内容，但只做简单介绍，更具体的请参考《云计算数据中心网络技术》与《从半空看虚拟化》。
3.1 IaaS整体系统结构
从架构上来看，IaaS可分为7个部分组成。
 计算资源
 存储资源
 网络资源
 安全防护
 应用优化
 管理平台
 交付平台

图4. IaaS整体系统架构
如图4所示，计算资源与存储资源提供了云计算中最为基础的计算与存储系统，安全防护与应用优化提供了安全优化的附加增值服务，管理平台和交付平台为外部的管理员与用户提供了云计算资源管理使用的入口，网络资源通过连接整合将上述6个部分紧密结合在一起，使所有资源能够作为一个真正的整体对外提供IaaS服务。
3.2 计算系统设计
云的基础是虚拟化技术，IaaS的本质是一虚多，将几百上千台物理服务器虚拟化为成千上万台虚拟服务器供用户使用。所有虚拟机的配置只能是物理服务器的子集，意味着不可能通过IaaS平台申请到一台几百个vcpu的虚拟机，那是超算干的事情。
同时能够对物理服务器和虚拟服务器进行配置部署的统一平台技术目前还相对不够成熟，为了能够集成大量的计算资源在一起，统一对外提供计算服务，通用做法是全部部署上虚拟化系统来整合成云。这就意味着在云中，即使用户需要一个4*8cpu计算能力的服务节点，也不能直接提供一台4*8cpu的物理服务器，只能通过在此物理服务器上唯一运行的4*8vcpu虚拟机形式提供。因此在IaaS内，服务器虚拟化软件平台是最为核心的组成内容。
虚拟化软件平台通常分为业务平台和管理平台两个部分，业务平台部署在大量的物理服务器计算资源上，实现计算资源一虚多的业务需求；而虚拟化管理平台则通常会部署在IaaS管理平台组件内部，对业务平台所在的服务器计算资源进行统一调度部署。
服务器虚拟化业务平台主要提供分区、隔离、封装和迁移4个关键特性。
 分区：在单一物理服务器上同时运行多个虚拟机。
 隔离：在同一服务器上的虚拟机之间相互隔离。
 封装：整个虚拟机都保存在文件或块存储中，而且可以通过移动和复制这些文件与块存储的方式来移动和复制该虚拟机。
 迁移：运行中的虚拟机可实现动态迁移到不同物理机的虚拟平台上。
目前IaaS数据中心的虚拟化业务平台有ESXi、Hyper-V、XEN和KVM四大主流软件产品。其中ESX/ESXi和Hyper-V分别是VMware和Microsoft的私有技术平台。而XEN和KVM则是两款主流开源虚拟化平台，有诸多厂商（如Citrix、Redhat、Amazon等）的虚拟化平台产品都是基于这两款开源平台修改实现的。从基本功能支持到性能和可靠性等多个方面比较，上述四款平台的差别不大。相对来说，ESXi和Hyper-v属于商用产品，实用性更佳，但由于源代码的封闭，二次开发空间不大。而XEN和KVM属于开源平台项目，多需要经过二次开发才能满足实际业务使用，在IaaS的私有云和公有云数据中心建设部署时被选用的也相对更多。其中XEN是2002年发布的早期虚拟化平台，KVM是2007年发布的新一代虚拟化平台， XEN在已有数据中心项目应用较多， KVM则由于其结构精简，且与Linux内核结合的更加紧密，在近些年新建的IaaS数据中心中更受欢迎，有后来居上的趋势。

图5. KVM虚拟化平台结构
以KVM为例简单分析虚拟化平台的结构与运行机制。如图5所示，最底层为物理服务器的硬件平台Platform，其上运行的是虚拟化业务处理平台Hypervisor层，最上面是运行的虚拟服务器Guest OS，Guest OS会安装主流的Windows Server或Linux等操作系统，所有的数据中心业务应用Apps都是运行在虚拟服务器的操作系统中。当业务应用下发某个CPU计算、数据读写或网络收发报文等任务时，KVM平台会首先将Guest OS发出的请求通过kvm-QEMU进行指令转换，然后再发给Hypervisor层上的硬件驱动程序Driver，最后由驱动通知硬件平台执行完成任务。当不同的Guest OS同时下发任务指令时，由Hypervisor进行任务排序调度，整合处理。
3.3 存储系统设计
在IaaS内部，除了使用虚拟化平台对物理服务器计算资源进行整合以外，还需要对存储资源进行集中处理，以达到数据级别的资源整合。存储系统实现上有很多技术分类，根据服务规模要求，在IaaS内主要使用IP SAN或FC SAN作为共享存储系统提供数据存储服务。IP SAN通常针对数据规模较小，IOPS（每秒I/O吞吐）要求较低的场景使用，建设成本低。FC SAN则针对大数据规模或高IOPS要求的场景使用（如数据库等），系统搭建消耗较高。近些年随着FCoE技术的发展，这种兼具了IP网络带宽优势与FC存储高IOPS特点的融合型存储系统开始受到关注，但由于厂商产品还不够成熟，大规模部署实现还需要一定的时间。
存储系统整合后，可以通过专业的软件平台为服务器集群提供共享数据存储服务。共享存储平台产品分为两大类，其中绝大部分是由存储设备厂商根据自身产品特性设计提供，主要在自己的产品上使用，如EMC、IBM、NetApp和Hitachi等。另外一部分是由专业的软件厂商设计，通过增加一层数据管理平台架构，可以在绝大部分存储产品上使用，如Symantec的VERITAS等。具体选择取决于决策者更加看重数据中心存储管理的运维简化还是兼容异构。
值得一提的是，在近几年，随着服务器计算能力和网络传输带宽的极大提升，整个业务系统的性能瓶颈开始向存储设备上转移，如上介绍的传统集中式存储受到带宽和I/O吞吐等硬件条件限制，发展速度已现颓势。新兴的分布式存储技术正在逐步走进大众的视野，该技术将原有单一磁盘阵列中的存储资源分散到大量低成本的服务器磁盘中，通过软件算法进行数据并行读写调度，并提供基于块的元数据冗余。分布式存储代表技术有开源的Ceph等。
另外还有分布式文件系统如Google的GFS和Hadoop的HDFS等也可以有效的对分散存储资源进行调度。二者的区别是，分布式存储主要提供块资源（Target-Lun）给用户，可以作为虚拟磁盘使用；而分布式文件系统则多了一层数据逻辑，能够直接提供完整的文件系统供读写使用，更适用于配合分布式计算技术实现文件级操作。分布式文件系统技术出现较早，目前已经拥有不少大型互联网企业应用，而单纯的分布式存储出现较晚，且因为无法直接和分布式计算应用对接，导致实际使用较少。分布式存储技术在IaaS系统中与计算虚拟化技术有部分配合，可以为虚拟服务器提供虚拟磁盘的服务。但相对于传统集中式存储技术，分布式存储单纯作为数据存储资源提供服务的技术成熟度较低，还需要时间成长。
3.4 网络系统设计
如果将IaaS比作为人体，计算资源就好像心脏，网络系统则是遍布全身的血管。再强健有力的心脏，如果没有繁茂通畅的血管，也无法将能量发挥出来，整个人也谈不上健康精神了。在IaaS数据中心内，网络系统将其他组件联通在一起，使所有系统密切结合为一个整体。
如图6所示，在数据中心内部，根据位置和连接资源的不同，网络系统通常可以分为五个部分。
 接入网络：服务器到接入设备之间；
 后端网络：服务器到存储设备之间；
 前端网络：接入设备到核心设备之间；
 互连网络：数据中心之间互连部分；
 边缘网络：数据中心与外部网络互连部分。

图6. IaaS数据中心网络系统结构
3.4.1 接入网络
接入网络主要用于连接物理服务器与接入层设备，在IaaS中，由于大量虚拟化技术的应用，对接入网络的挑战从传统的物理服务器间流量传输变化为如何更好的承载虚拟机之间的流量。从技术思路上来说，目前主要有两个发展方向，一是由虚拟化软件厂商主导的将流量处理工作都交由物理服务器的虚拟交换机vSwitch完成，同一物理服务器内部虚拟机交互流量由vSwitch本地转发，不同物理服务器的虚拟机通信时，通过在vSwitch之间建立隧道技术完成，无需关心中间物理网络的连接方式，此类方案代表技术如VXLAN、NVGRE和NVP等；另一个方向由网络厂商主导的将网络流量处理仍然交给网络设备完成，服务器内部不对虚拟机的流量进行细分控制，由接入层网络设备在连接服务器的物理接口下建立对应虚拟机的虚拟接口，从而达到精细化流量控制的目的，代表技术如IEEE的802.1BR和802.1Qbg。
进行接入网络系统架构设计时，对技术的选择主要依据服务器资源与网络资源投入情况。vSwitch处理方式明显会加剧服务器的计算资源消耗，如果所有服务器的性能都足够强大，且虚拟化之后都会预留较多计算资源供vSwitch做任务处理，则可以选择使用vSwitch处理流量的方案。如果希望将更多的计算资源用于虚拟化后的业务处理，则可以考虑将虚拟机流量放到接入设备上处理的方案，即仍由网络设备处理网络的任务。
3.4.2 后端网络
后端网络主要用于连接服务器资源与存储资源，可选方式以FC/IP/FCoE几种为主，设计原则依据存储资源的类型选择。
值得一提的是FCoE网络由于可以与接入网络融合，从整体结构上可以简化网络设计与降低投资，同时能够兼容FC存储资源，所以在最近几年的发展中逐渐走俏。但由于在整体存储技术发展方面，传统集中存储遭受到分布式存储得一定冲击，所以FCoE的前途还不是很明朗。
分布式存储的各个存储节点间存在大量频繁的full mesh数据交互，对网络带宽要求较高，一般需要以万兆IP以太网进行组网。且由于节点众多，故障点增多，导致稳定性与可靠性较差，需要配合前端的分布式计算业务系统提供强有力的冗余保护。另外如果还是采用传统的计算业务模式，通过IP挂接分布式存储的Target，一是Target IP所在设备可能会出现网络传输瓶颈点，二是当分布式存储自身节点故障导致存储资源短时间不可用会使前端计算业务受到影响。
3.4.3 前端网络
根据数据中心的计算资源规模大小，前端网络可以选择采用二层或三层架构设计。如预设条件接入层设备采用1:40的服务器接入比例，所有服务器都使用双上行到两台接入层设备实现冗余，几种常见接入层到核心层网络结构对应规模如下：
 使用传统二层MSTP设计，网络节点规模在50以下，服务器资源需要小于1000台(50*40/2)。
 使用三层OSPF设计，网络节点规模可以支持200左右，服务器资源达到4000台。
 使用大二层如TRILL设计，网络节点规模理论上可以达到500以上，对应服务器资源规模能够支持到10000台。
上述计算都是理想情况下的结果，实际部署时考虑到带宽和管理等其他因素，对应支持的服务器资源规模还要更少一些。
此外，时下热炒的SDN（软件定义网络）技术如OpenFlow等，原理上将控制层面与转发层面分离，网络节点只处理转发任务，所有的路径计算与管理都由独立的控制器设备完成。此类技术理论上都是支持无限大的网络与计算资源规模，实际部署时只受限于控制器软件所在的硬件（如服务器）处理能力。但由于SDN技术相对不够成熟，真正的达到大规模实践还需要一定时间。
因为SDN属于纯软件实现，因此也可以在接入网络中，部署到虚拟交换机上，实现虚拟网络与物理网络的统一转发管理。SDN还可以与VXLAN/NVP等技术配合，由VXLAN/NVP负责用户流量的分组隔离，SDN负责转发控制，类似于传统网络中VLAN和MAC/IP地址转发技术的关系。
3.4.4 互连网络
受场地供电等限制以及不同地理位置用户就近接入的需求，在扩大到云计算规模时，IaaS中多地部署数据中心站点已经是很常见的建设方式，尤其像一些超大型全球企业，其私有云数据中心势必需要多点开花，以支撑其遍布世界各地的分支使用。
互连网络需要根据站点的地理距离以及通信需求选择合适的网络技术进行搭建。现有技术主要是以搭建隧道为主，如二层隧道VPLS/OTV/EVI，三层隧道MPLS/GRE等。这些技术都是来自网络厂商，通过数据中心互连边缘的网络设备实现。但在计算资源虚拟化的发展下，软件厂商更加倾向于引导使用前面提到的vSwitch之间建立的隧道如VXLAN/NVP等，好处是对中间网络没有特殊需求，只要能够保证服务器的vSwitch间IP层能够实现通信即可，无论是数据中心内部的前端网络还是站点之间的互连网络，只需提供最基本的IP通信，对网络的依赖性降到最低。此类方案是将隧道的建立维护工作都放到了服务器内部，虽然降低了网络资源的需求与投资，但增加了对计算资源软硬件的需求及相应投资成本。
3.4.5 边缘网络
边缘网络用于云计算用户的接入使用，根据用户的不同，接入方式有所区别。在私有云中，由于其用户群主要为企业内部雇员，因此接入方式以专线为主，相对来说此部分技术较为简单，只需要规划好接入办公地点与数据中心之间的路由即可。但随着目前移动办公的需求，互联网也成为私有云必不可少的接入方式。考虑到企业私有云的安全性，因此必须使用一些隧道技术对通过互联网接入的企业用户进行识别与保护。如中小型办公分支通常使用GRE/IPSEC结合的手段接入到私有云中，而单独的移动用户更多的使用SSL VPN方式接入。IaaS还需要为业务提供统一的Portal访问门户以集中进行交付使用，具体见下文将要介绍的使用交付系统。公有云的用户类型与私有云正好相反，大量的集中与互联网接入，少部分大型用户会采用专线接入的方式，在具体技术上与私有云相同。
3.5 安全防护系统设计
由于云用户的接入广泛性，安全在云计算环境中显得更加重要。IaaS系统设计时，可以分四个方面来考虑安全防护系统设计（如图7所示）。

图7. IaaS安全防护系统
3.5.1 接入防护
由于IaaS需要为终端用户提供业务服务，首先需要对接入用户进行安全防护。这里可以分为两个方面来进行接入安全防护。
一是接入身份安全，通过SSL VPN/IPSEC VPN/Portal等手段对用户身份进行辨识确认，并分配访问权限。
二是接入设备安全，通过客户端代理程序等手段对用户使用的接入设备进行安全判断，以防止存在木马病毒或不合规软件操作等问题。随着终端技术的发展，接入终端已经不再局限于传统的个人电脑，智能Pad和Phone等都成为用户常用工具，因此BYOD（Bring your own device）等技术解决方案也应运而生。
从技术角度分析，接入安全技术又可以分为预装方式与随装方式两种，预装方式指在接入终端上提前安装专门的客户端软件，集接入身份认证与程序安全检查功能于一身，在用户需要连接私有云时运行，属于传统的CS（Client-Server）结构。
随装方式通常是BS（Browser-Server）结构，一般通过浏览器实现WEB登录进行身份认证，当认证通过后会自动或手动下载一段代理程序到终端上，对运行环境进行安全检查，符合规则才允许接入。当用户访问业务应用时，代理程序会一直在后台运行，监控环境与用户行为，直到用户退出访问，自动终止运行或卸载。
接入安全技术自身的安全性也在被人们日益关注，如大量云服务采用SSL VPN技术进行接入，如“心脏滴血”等漏洞就对云服务产生了巨大威胁。
3.5.2 网络防护
网络防护指IaaS数据中心内部网络中提供的流量安全防护手段，技术上通常是通过读取流量报文中的特定字段，去匹配预设内容，进而执行通过、删除、重定向或统计等动作，针对OSI模型L2-L7可以提供不同层次的检测防护。由于数据报文L2-L4的封装报文头内容较为规范，且种类较少，因此交换机和路由器等网络设备可以使用ASIC芯片对相应报文字段进行截取、解析与判断处理，即常用的ACL过滤功能。由于L4以上各层封装内容多种多样，很难将大量的判断工作由简单的ASIC完成，因此需要专门的防火墙等安全设备使用CPU进行解析处理。而病毒漏洞等特征代码往往隐藏在报文的应用层负载中，所以相应的工作也需要更专业的如IPS和流量清洗等安全设备，使用高性能处理器手段来识别处理。对网络防护安全系统进行设计时，往往考虑的是需要提供何种级别的业务安全防护，以及对处理性能的要求。
在网络防护层面，除了上述对业务流量数据报文的安全防护外，还需要考虑对网络通信协议层面的防护设计，如MAC防攻击、ARP防攻击、IP防攻击与RIP/OSPF等路由协议的认证机制。这些功能通常由网络设备如路由器和交换机等自身具备并部署。
3.5.3 虚拟化防护
在IaaS中，虚拟化系统是计算资源必不可少的部分，因此也需要考虑在虚拟化方面进行安全防护。虚拟化防护从保护对象上可以分为两类：
 虚拟机间访问防护
 虚拟化系统自身防护
虚拟机间访问防护从技术思路上也可以属于网络防护，主要是以在vSwitch上部署ACL等安全策略和建立虚拟防火墙vFW如VMware的vShield为主，和前面提到的在物理网络设备与防火墙/IPS上是实现的功能大致相仿，都是对访问虚拟机的流量进行过滤处理。二者的区别是，网络防护主要针对外部访问虚拟机业务的流量进行处理，既常说的数据中心南北向流量。而虚拟机间访问防护关注的是同一物理服务器内部，虚拟机之间的互访流量，既常说的数据中心服务器内部东西向流量。对于跨物理服务器的虚拟机互访东西向流量，二者都可以处理。如果采用网络防护，则需要将防护控制点尽量降低，采用例如在接入层交换机上部署大量ACL或旁挂FW/IPS设备的方式，会导致部署点增多，设备采购量巨大。如果采用虚拟机间访问防护的方式，则需要在vSwitch或vFW等软件处理点上增加大量如ACL等控制规则，对性能要求较高，增大了软硬件的处理压力。由于虚拟机间访问防护需要额外占用较多的物理服务器自身计算资源，因此只有在服务器硬件性能充足的情况下建议部署。
配合IEEE 802.1Qbg和802.1BR等标准协议，还可以将虚拟机之间的流量都牵引到物理接入交换机上，此种方式可以部分减轻vFW占用服务器性能的问题，但缺点是会导致物理服务器内部交互流量两次通过物理网卡与物理接入交换机之间的链路，部署时需要保证拥有足够的网络带宽余量。
另外在虚拟化防护中还需要注意对虚拟化系统自身的安全防护。虚拟化系统需要构筑在一套底层操作系统之上，还必须要提供一些外部开放接口如SSH，http/https等供虚拟化管理平台进行访问控制，因此也需要对底层操作系统及开放接口进行一些必要的安全防护。此部分安全防护可以采用网络防护的手段对访问虚拟化系统的流量进行保护，同时结合应用防护在底层操作系统上安装防火墙或杀毒等软件，来进行全方位的系统级别防御保护。
3.5.4 应用防护
应用防护主要基于虚拟机操作系统层面，通过软件防火墙如360、瑞星金山等产品或技术基于应用自身进行安全防护。在IaaS中，根据提供服务的不同，此方面安全防护设计也不一样，如果IaaS只提供虚拟机环境，用户自行安装维护操作系统，则此方面的安全防护功能，服务提供商就不需要考虑了。但如果提供的操作系统级别服务，则必须要同步提供操作系统的补丁升级，漏洞防护和安全杀毒等对应服务。如果提供的是数据库服务，那么数据库程序的升级防护，包括数据安全防窃取等也是必须同步交付的了。总之一句话，只要是给用户的产品服务目录上有的内容，相关安全保证就必须同步设计提供，做戏要做全套。
3.6 应用优化系统设计
IaaS内部，为了提供更好的业务应用系统访问能力，往往需要应用优化系统，典型的应用优化系统有应用负载均衡、链路负载均衡、全局负载均衡和应用加速等。这些系统可以是各自独立的物理设备，也能够以软件授权的形式部署在同一套物理设备上。下面就几个常用的应用优化系统进行举例介绍。
3.6.1 应用负载均衡系统
应用负载均衡系统提供对服务器业务访问的负载均衡能力，原理上通常使用网络地址转换NAT技术，将多个实际的业务系统IP地址转换为一个虚拟业务IP地址对外部提供业务访问。应用负载均衡系统包含两个重要算法，一是对业务系统内部的不同实体进行保活探测算法，此算法可结合业务应用，从IP/TCP层次进行探测，高级些的算法还可以探测如http get/post等动作，根据探测反馈结果来选择出可用的业务实体。二是将不同用户访问分发到不同业务实体的分配算法，用户访问到达时，负载均衡系统会自动依据预设的分配算法（如轮转、随机和最小连接等），将这些访问请求尽量均衡的分发到同一系统的不同可用业务实体中，避免其中某几个实体运行负载过高，影响访问效果。
应用负载均衡系统配合计算资源虚拟化管理平台，还可以实现弹性计算智能扩展。即配置虚拟化管理平台与负载均衡系统实现联动，当管理平台检测到当前虚拟服务器访问量较大，CPU、内存或连接数等关键指标运行超过预设阀值，则会自动创建新的虚拟服务器，并通过DHCP或静态IP配置下发等技术使用不同的业务访问地址。当新的虚拟服务器启动运行后，管理平台会通知负载均衡系统，将其自动加入到现有的实际业务系统集群中，新的访问请求可以被分配到新建的虚拟服务器上，从而降低原有实际业务系统的压力。当访问量降低，业务服务器的关键运行指标低于预设阀值时，管理平台可以通知应用负载均衡系统不要再分配访问请求给一些低负载虚拟服务器，并当现有连接处理完成后关闭或删除这部分低负载的虚拟服务器，以达到节省能耗的效果。
应用负载均衡系统多会部署在靠近服务器的网络位置，以降低网络中的流量负载。
3.6.2 链路负载均衡系统
链路负载均衡系统往往部署在IaaS数据中心存在多个互联网入口的场景中。当用户请求从不同的入口进入数据中心内部返回数据时，为了能够减少数据报文在互联网中传输的距离，使用户侧的业务响应延迟更低，我们会希望数据都是从哪个接口进入，就还从哪个接口发出。
技术原理上，链路负载均衡系统会记录不同入口收到报文的特征表项（如源目的IP和源目的端口号等）和入口下一跳设备的MAC地址，创建相应连接信息表项，当收到返回数据报文时，直接查找此表，根据特征表项对应的MAC地址进行二层报文封装，并通过对应接口发送，不会再去查找路由表做IP转发。因此链路负载均衡系统多会部署在数据中心出口位置，连接不同的互联网入口。
3.6.3 全局负载均衡系统
当IaaS包含多个数据中心站点时，为了提供冗余与高可靠，会需要多个站点均同步部署相同的业务应用。我们为了降低业务响应延迟，让用户能够获得更好的业务访问体验，往往会希望其能够访问就近的或负载最小的数据中心站点。此时就需要通过全局负载均衡系统，对用户访问进行统一调度，为其定位最适合的响应站点。
目前主流的业务访问模式都是使用域名的方式，通过DNS技术来解析名称所对应的IP地址，因此全局负载均衡系统的技术原理都是通过为不同用户解析不同的数据中心站点的业务IP地址来达到负载均衡效果。既在全局负载均衡系统上同一域名都会对应多个数据中心站点的IP地址，当DNS请求到达后，全局负载均衡系统会对各个数据中心站点的业务IP进行探测，根据存活情况以及响应时间等探测结果，结合预设的一些分配规则（如最小响应时间或最小连接数等），为用户反馈合适的IP地址。全局负载均衡技术的核心就是业务IP的保活探测算法与DNS请求回应的分配算法，和应用负载均衡系统很相似。
全局负载均衡系统可以选择部署在某个数据中心内部接近出口的位置，或者为了解决容灾的需要，部署在数据中心站点以外的单独位置。
3.6.4 应用加速系统
当前主流的BS结构业务系统中，都采用HTTP方式进行连接处理，用户进行业务访问时，与业务服务器间会存在大量TCP连接关系，我们可以将这些连接通过中间设备代理方式进行TCP连接的合并，减少服务器上的连接维护数量，从而提升业务系统的处理能力。这种技术通常被称为TCP卸载，对应的还有SSL卸载技术，专门处理HTTPS连接的代理优化。
当传输内容存在大量文本或图片等数据时，可以使用专用的设备或软件对内容进行标准化压缩，当数据传到用户侧终端时再解压，这样可以降低中间网络的负荷，提高传输速度与减小延迟。
还有Cache缓存系统通常部署在数据中心出口附近，可以对用户经常访问的一些静态服务内容进行本地缓存，这样后续用户访问相同内容时本地直接代答反馈，不需要再把请求转到数据中心内部，可以降低后端网络流量压力和服务器的业务处理压力，同时减少了流量路径延迟，达到优化用户体验的效果。
应用加速系统主要针对应用进行业务优化，种类繁多，可根据业务特点进行系统设计，灵活部署，前面介绍的几种都是较为通用的技术，更多的内容本文不作细致分析。
3.7 管理系统设计
在传统数据中心中，统一管理大多指的是将计算、存储和网络等资源管理平台，集中放置到管理区域统一进行业务处理，但实质上，各个管理平台仍然是各自为政的。当管理员完成一个业务部署时，需要面对多套平台系统进行任务下发，往往需要很高的业务技术广度能力要求，多方配合才能完成。
在IaaS内，真正的统一管理是指可以由一位管理员通过一套管理平台系统，方便的完成整个业务系统的部署。技术原理上，需要计算、存储和网络等资源均提供基于标准的API开放接口，管理平台可以通过这些标准接口下发配置，对资源实现创建、修改和删除等基本的处理动作。从架构设计上，统一管理平台可以直接和设备资源进行交互，也可以通过对应的管理平台去管理不同的资源（如图8所示）。

图8. 管理平台架构
架构一的好处是任务处理效率高，工作一次下发完成。但需要业内所有的设备厂商在其所有型号的设备上均支持统一的标准API，整合推进难度高，进展缓慢，短时期内还无法达到。如IaaS开源管理平台OpenStack的终极目标就是如架构一可以去直接管理所有的计算、网络和存储资源节点，当然完全实现就是路漫漫其修远兮了。
架构二是目前使用最多的方案，各个设备厂商都可以通过自己的软件管理平台上统一管理到自身设备资源，同时在自身管理平台上开发基于RESTful/SOAP等标准的平台接口，提供给上层的统一管理平台使用，虽然中间存在二次调度，系统较为复杂，但就目前业内发展情况而言，是最合适的设计架构，而且也已经有一些相关标准和产品完成设计投入使用。
从产品能力实现分析，管理平台技术最关键的就是接口、编排和界面。
IaaS所有的功能实际都是由资源节点自身实现的，管理平台只是通过接口去调用下发，因此接口的数量多少和粒度粗细决定了管理平台对资源管理功能的管控实现程度。接口是所有管理平台产品技术实现的根本所在。
然而资源节点的功能永远是有限的，哪怕有几百上千个功能规格，如果管理平台只能一比一的实现也没有什么竞争力，对这些功能的深度业务编排能力才真正体现了管理平台的价值。假如一个资源节点的功能规格是1、2、3三个，那么管理平台理论上的功能规格就可能达到1、2、3、12、13、23、11、22、33、123十个。多出来的那些就看产品设计者想象力的丰富程度了。实际上在底层技术趋同的今天，这部分也是各个厂商产品差异化竞争的关键所在，我们经常看到的大部分所谓特色解决方案，实际上就是这些通过多个基本功能编排出来的“组合拳”。这一部分真正体现的是厂商的用户业务理解，而不是基础技术能力。
最后一个关键点是界面，管理平台作为IaaS管理员与资源设备打交道的渠道，命令行肯定是不行的，图形界面是必须的。
 友好的人机交互。完备的输入反馈与帮助提示可以提升用户粘性；
 便捷的配置下发。同样的功能点击一下完成和点击五六下完成给人的感觉肯定天差地别；
 优美的界面设计。至于风格应该是高大上还是炫酷奇，谁也说不好，萝卜白菜各有所爱的事。如果实在没有很强的美感设计能力，跟着Windows或苹果风格走是不错的选择。
IaaS统一管理平台的代表产品如OpenStack和CloudStack等都已经拥有一些成功部署的案例，在业内有拥有不少拥趸，后续发展情况还要看用户厂商运营商之间的多方博弈。用户希望平台尽量省事，运营商希望管理运维简单可控，但厂商多是不愿意把自己产品最赚钱的管理软件部分直接砍掉的，如图8中架构2的妥协才是王道。
3.8 交付系统设计
交付平台是IaaS有别于传统数据中心的专有系统组件，也有称之为云服务平台。IaaS定义提供给用户完整的虚拟服务器资源（可能含操作系统及数据库）进行使用。用户需要能够对资源配给进行申请，当获得虚拟资源后，在虚拟机上能够自行安装业务系统，并对其执行启动暂停关闭等常规服务器处理动作。因此必须有一个交付平台为用户提供上述业务接口，并通过管理平台，将这些用户行为转换成对应的指令下发给资源设备执行。
如果只是管理员通过管理平台对各项资源进行配置管理与业务处理，那么仍然属于传统数据中心的架构范畴，并没有形成云的概念。只有通过使用交付系统，将数据中心整个资源服务进行整合，以逻辑资源形式提供给终端用户使用，才能称之为云。用户只关心自己使用的逻辑的计算、存储与网络资源，能够看到的只是一朵资源云，不会看到也不需看到数据中心内部的实际物理资源是如何在进行任务调度处理。
在进行使用交付系统设计时，通常包括提供给用户的认证授权、资源申请、资源使用和日志统计等功能模块。
 认证授权模块可以结合安全防护功能，使用Portal对用户身份进行确认，通过代理程序或客户端安装软件方式检查用户终端环境，结合LDAP等工具为用户提供权限设定。
 资源申请模块需要根据权限设定，提供给用户可以使用的后台资源统计信息，如CPU、内存、存储和网络等。然后用户可以根据自身业务特点，定制申请使用的虚拟服务器资源。资源申请模块再将此请求发送给管理平台，管理员审批通过后，由管理平台连接各个资源设备的管理平台下发命令，创建相应虚拟服务器等资源。
 资源使用模块为用户管理已经创建的资源提供入口，并提供一些基本和高级的使用操作，如对虚拟机的开关机、ISO挂载和远程登录等功能。用户执行动作时，资源使用模块会根据内容将部分指令通过API接口转给管理平台去执行，也可以提供一些资源重定向的服务将部分指令直接下发到创建好的虚拟服务器上。
 操作记录和性能监控等日志统计类功能也需要在使用交付系统设计时进行考虑，具体设计可以根据对业务管控的要求调整。
3.9 小结
IaaS的7个系统组件中，计算、存储和网络资源是必要的组成部分，提供最基础的设备资源使用与基础功能实现，与传统数据中心系统比较，主要针对各个资源虚拟化技术做出了部分专门设计；安全防护与应用优化根据业务系统的需求规划，可以较为灵活的进行设计部署，从而实现不同级别的安全与优化能力；管理平台和交付平台则是针对IaaS进行的专业设计，有别于传统的数据中心设备级别的管理监控功能，与云计算IaaS服务层面紧密结合，达到业务应用级别的深度管控与访问交付。
4 IaaS高可靠设计与能力度量
4.1 IaaS高可靠设计
高可靠性（高可用性）是所有应用系统必不可少的一个关键指标，在实际业务系统运行过程中，各种物理的和人为的故障是无法避免的，如何通过技术手段将此类故障造成的影响降到最低，就是高可靠要实现的目标。
在IaaS云计算设计中，同样需要高可靠相关技术来为整个业务系统的正常运行保驾护航。对用户而言，只需关注整个系统提供服务的高可靠性，不需要关心具体的使用技术。高可靠性的度量计算方法博大精深，简单些可以采用多个9的标准来进行度量，根据运营商承诺的一年内宕机（业务中断）时间所得。如某IaaS承诺一年内宕机时间在5小时以内，则高可靠性为1-5/365/24=99.9%，既3个9服务级别。
不同的高可靠技术用于应对不同的故障情况。常见的故障按系统组件可大体划分为网络故障，如网线断开，网卡损坏造成的通信异常；服务器故障，如断电或CPU/内存及其他物理配件故障；存储故障，存储网络断开或存储设备硬件故障等；虚拟化系统故障，如操作系统宕机或底层进程挂死等；软件故障，如安全与应用优化软件及管理交付平台的软件程序故障等。为了应对上述故障处理，确保业务系统的尽快恢复，涌现出了很多的高可靠技术。如网络方面的链路聚合，存储方面的Raid，计算物理资源方面的corosync/pacemaker，计算虚拟资源方面的VMware FT等等。
首先介绍下高可靠技术的通用技术特征，然后再介绍些具体的高可靠技术。
4.1.1 高可靠技术特征
高可靠技术特征可概括为四部分内容：备份Backup，同步Synchronous，监控Monitor，切换Switching。
备份：
首先要为需进行保障的业务实体（软件、系统、虚拟机、物理机甚至是集群）进行备份，可以采用指定或选举等方式，准备出一个（1:1）或多个（1:N）可用的对应备用实体。此备用实体可以处于运行状态直接提供业务访问能力（通常称为双活Active-Active或Load Balance，也可处于热备或冷备状态，等待主用实体故障后再进入运行状态提供业务访问（Active-Standby）。上述三种方式按投入和可靠性依序为由高到低，可依据不同的业务需要与资源投入情况进行选择。另外也可以采用多个业务实体共用一个备份实体的N:1备份方式，此方式比较前面提到的1:1和1:N备份方式明显更加节省成本，但缺点是可靠性同样随之降低，当多个主用业务实体故障时，备份实体没有足够资源支撑接管行为，势必造成业务的失效。这里还有个容易产生的理解误区，有时人们会认为Active-Active运行方式比较Active-Standby具有更高的资源利用率，实则不然。我们假设业务实体资源量为100，采用1:1备份，备用实体资源量也为100，则资源总量为200，但可供实际使用的资源总量不能超过100，否则将无法达到备份的效果，故障后也就不能满足业务切换需求，此场景下A-A和A-S两种方式区别只是小于100的实际使用资源是分布在两个实体上还是只在一个实体上，实际所消耗的资源总量是一样的。A-A模式的好处主要是可以让备用实体日常也运行起来，能够避免A-S模式，当主用实体故障时，备用实体可能因日常检测不足，自身存在问题，出现无法接管业务的情况。
同步：
当系统中的主用实体和备用实体都已经准备好，就要开始进行状态同步，同步的方案设计主要考虑内容和频度两个方面。内容可以分为固态内容如硬件环境配置，系统环境配置，软件运行环境配置等，和动态内容如内存运行状态，动态表项等。频度则最低的，如多用于冷备的只在初次安装完成后进行的基本环境同步，到中间状态多用于热备的定期（每年、每月、每天、每小时、每分钟）数据同步，甚至最高级别多用于Active-Active的实时业务数据更新同步。不同的同步方式对环境建设有不同的需求，会造成不等的资源消耗，实际部署时仍然是根据高可靠性要求和资源投入情况来进行选择。
监控：
主备系统部署好之后，就可以业务运行阶段，此时需要对主用业务系统的运行情况进行监控，当主用系统故障时，可以立即进入切换行为，减少业务宕机时间。监控是高可靠系统设计中必不可少的部分，在系统中通常需要部署一个监控者的角色，当主用与备用系统较少时，可以使备用系统成为监控者，当然也可以使用专门的第三方实体作为系统监控角色。监控者会定期向主用系统发送探测信号，进行业务监控，当故障导致信号响应出现问题后，监控者会对备用系统发送信号，令其将业务系统置于可用状态，进行故障切换。监控技术主要涉及频率、信号和故障确认三方面的设计。频率就是探测信号的发送间隔，通常根据高可靠要求按照秒、分钟、小时甚至更长的单位设定。信号则可根据业务系统特点，针对主机、操作系统或应用程序进行不同级别的探测。例如一套WEB网站系统，探测信号可以是HTTP访问请求、TCP连接请求、PING请求等。故障确认是对探测出现异常响应时，判断是否为故障的一整套规则设计。如可以设计1个或多个探测信号响应异常就视为故障出现，或者当出现1个或多个探测信号响应异常时，变更频率与内容发送其他探测信号等。
切换：
当监控者确认故障发生后，就要对备用系统发信号令其业务系统可用，完成切换动作后，将通过备用系统提供业务访问能力。切换动作主要涉及启动信号的设计，根据前面备份的不同方式，启动信号可以是基于主机的，基于操作系统的，基于业务系统的，或者基于网络路径的。另外业务切换完成后，还需要设计当原有主用系统恢复时，业务系统是否要切换回原主用系统上，通常的做法是不做二次切换，原有主用系统降为备用系统，等待现在运行的系统发生故障后再切换回去，当然也可根据业务需要立即切换回原有主用系统。切换动作除了自动切换方式外，依据业务系统需要有时还会设计为手动切换，如一些金融政府能源等合规要求较高的行业系统，备用系统的切换往往需要进行审批等流程处理，通过后才可以进行。
高可靠技术的最基本度量标准就是故障业务恢复时间，此时间通常为监控部分中故障发生到监控者确认故障的时间和切换后业务系统启动时间总和。举个例子，监控者每10s发送一个探测信号，当连续3个响应信号异常后确认故障，备份系统采用操作系统热备份方式，业务系统进程启动需要30s。则当主用系统故障发生后，需经过至少2*10+30=50s，最多3*10+30=60s可以恢复业务。
4.1.2 高可靠技术介绍
因为从最终用户角度首先看到的是业务应用层面，所以下面按照前面图2中的IT系统结构，对IaaS云计算可靠性设计也依据自顶向下的顺序分为八个部分。
 WEB
 APP
 DB
 OS
 Virtualization
 Server
 Network
 Storage
不同层面的高可靠技术既可以单独使用，也可以配合使用。原则上采用的技术所在层次越高，对业务应用的保障程度越高，故障恢复时间越短。每个层面的技术可以处理自身层面及其下层的资源故障，并为其上层的资源提供高可靠性保障。
WEB/APP/DB高可靠技术
其实这三个部分的高可靠技术内容是最多的，但由于作者不是很熟悉，所以合并在一起简单做下介绍。软件层面的高可靠技术更适合配合Load Blance负载均衡技术实现Active-Active级别的高可靠效果，当然传统的Active-Standby方式也有软件会设计使用，但此类软件性能一定会受限制，都很难应对线性增长的用户量需求的。
多说两句分布式的事情，目前能实现A-A级别的应用软件大多属于分布式计算范畴，可以由多个资源节点提供并行服务。注意，这里的关键是并行，有些软件只是将自身不同组件模块放到不同节点上提供服务，确实也可以达到总体上的效率优化提升，但实际上系统整体性能仍然会受限于单一模块所在资源节点能力，更远谈不上线性增长了。因此个人认为此类软件应该被命名为“分开式”而不是“分布式”。
可以使应用软件达到A-A级别高可靠效果的分布式技术如Hadoop，Hbase和Zookeeper等，非常多，不多说了。
再谈个基本概念的问题，什么样的业务应用需要在IaaS上运行？IaaS的根本是计算虚拟化技术，这个虚拟化目前来看就是一虚多，从技术产生到发展，要解决的都是物理计算资源剩余问题，达到的目的也是提高资源使用效率。那么很简单了，IaaS上面运行的都应该是轻载业务，通过将多个轻载业务以虚拟化方式部署到同一物理服务器上，可以达到省资源省开销的目的。如果是需要部署10台1核计算能力虚拟机才能完成的任务，为啥不能找个10核的物理服务器直接搞定就完了。虚拟化层面势必会消耗物理服务器的计算资源，这是显而易见无可避免的。对于那种部署在虚拟机上，还要配合负载均衡来玩的业务应用，只可能是软件程序无法将物理服务器的多核资源充分调用起来，水平还有待提高。这样的程序给他分再多的核，也还是只能把有限的几个核跑死，对多分配的计算资源根本无法利用起来。
如上所述，IaaS中的业务应用根本没有必要上LoadBalance技术达到A-A效果，运行一些A-S级别的轻载业务就OK了。目前业内提供IaaS中的负载均衡服务，更多的是厂商和运营商出于市场因素考虑，为了多卖些产品服务引导的。作为用户有较为富裕的资源投入，还不如对自身业务系统设计进行优化提升来的划算。高性能严要求的业务还是运行在传统的物理服务器上，等着真正的基于底层计算资源层面的多虚一技术出来后再说吧。
OS高可靠技术
虚拟机操作系统级别的高可靠技术主要就两大类（因为X86服务器操作系统主要也就两种），Linux集群技术和Windows集群技术。这里的集群Cluster可以认为是提供A-A或A-S高可靠性能力的一组服务器。
Linux集群技术以LVS（Linux Virtual Server）为代表，与Heartbeat、Keepalived等监控技术配合，可以实现操作系统级别的负载均衡，达到Active-Active级别的高可靠效果。当然Linux也有能够实现A-S级别的高可靠技术，如Redhat的群集管理器技术等。
Windows集群技术主要指Windows Server提供的集群技术，从2003、2008到最新的2012，都能够做集群提供高可靠性，技术上逐渐进步，配置上也越加简便。
OS高可靠技术在IaaS中部署的位置较为尴尬，处于不上不下的地位，实际采用的情况较少。
Virtualization高可靠技术
虚拟化是IaaS的重头戏，因此虚拟化层面的高可靠技术也是IaaS能够提供的主力特性。通常采用虚拟化集群技术对物理计算资源节点进行运行状态监控，当某个物理计算资源节点发生故障后，可以将其上运行的虚拟计算资源都转移到其他物理计算资源节点上，以提供可靠性保障。上述过程涉及到两个层面内容，一是节点间的运行监控，二是监控到事件发生后的资源调配，如Corosync/Heartbeat+Pacemaker就是这二者的典型技术组合。由Corosync或Heartbeat做运行监控，Pacemaker做资源管理，可以较好的实现虚拟化层面的高可靠能力。
但虚拟化层面的高可靠技术服务对象为虚拟机实例整体，能做到的也只是基于虚拟机整个进程的故障恢复，内存，作为虚拟机操作系统而言，肯定需要经历重新启动的过程，导致整个业务层面的故障恢复时间实际上为虚拟化层故障恢复时间+虚拟机操作系统启动恢复时间+虚拟机业务服务启动恢复时间，往往会达到分钟级别甚至小时级别。此时可以应用如VMware的FT技术，在前面高可靠集群基础上通过对主备虚拟机资源的内存运行状态进行实时同步，达到秒级甚至毫秒级的故障恢复能力。当然有得必有失，FT技术需要至少同时在两个物理计算节点上运行两套完全相同的虚拟资源，占用了2倍的计算资源，而且由于内存要实时同步，对网络资源要求较高，也会造成很多使用上的限制，仅适合一些要求较高的业务应用使用，广泛部署会对虚拟化集群资源造成很大压力。
对于虚拟化集群部署最大的技术难题就是规模，由于对集群中的资源节点必须进行监控，因此当集群节点数量增加时，监控的连接数也会成倍增加。当前监控技术实现有两种主要思路，一是增加专用于监控的节点，集群资源节点只做查询响应。这样做虽然集群资源节点数量不再受到限制，但会导致监控节点成为整个结构中的性能瓶颈和单点故障点，还需要再专门为监控节点进行高可靠性设计。另一种思路是资源节点之间通过组播的方式实现Fullmesh结构监控，虽然不需要引入其他设计，但问题是组播方案限制了集群资源节点IP必须在同一子网下，导致组网设计受限，而且当节点数量增多后单节点处理连接压力倍增，组播风暴的风险激增，往往规模也无法做到很大，能有百十台就不错了。
Server高可靠技术
前面的软件高可靠技术部分，已经可以完成对服务器层面故障的业务恢复，硬件服务器的高可靠技术都和自身硬件系统设计相关，如双电源冗余，cache电容保护，本地多磁盘Raid等等。
Network高可靠技术
网络高可靠技术的根本思路就是多路径冗余，根据网络节点设备的处理角色不同，可以分为服务器网络高可靠技术，网络设备高可靠技术和存储网络高可靠技术。
服务器操作系统提供了多种多网卡路径冗余技术，Windows和Linux具体技术各不相同，但总体思路是一致的，都是通过主备，收发方向负载均衡和与对端接入交换机协商（如LACP）等方式来控制流量如何通过多条路径进行转发，从细节HASH算法和故障切换逻辑上有所区别。
网络设备自身专攻流量转发，因此也存在丰富的基于网络的高可靠性技术。如链路层的链路聚合技术和RPR环网技术等，路由层OSPF/BGP等路由协议技术，主机层面的vPC/IRF等多虚一技术，网络操作系统层面的ISSU/NFS等高可靠技术。有机会单独成文介绍，这里不多讲了。
存储网络如果是iSCSI和FCoE等技术，可以使用前面的基于IP/Ethernet的网络高可靠技术，另外FC SAN存储结构也有FC多路径设计，可以实现多FC链路的网络冗余高可靠。
Storage高可靠技术
在IaaS中存储设备自身需要提供三个方面的高可靠能力，一是针对前端的虚拟或物理服务器提供存储资源的高可靠性，二是存储设备自身硬件高可靠性，三是对存储数据的高可靠性保障。
存储设备对服务资源的高可靠性保障，主要通过如存储多路径技术和多控制器技术等，通过主备路径或主备控制器来提供服务器访问能力的冗余。
对于存储设备自身而言，双电源，磁盘阵列Raid，Cache缓存等技术方案和硬件服务器很类似，但高可靠性级别会提升更多。
对存储数据来说，可以通过多个存储阵列集群、网络Raid以及同异步远端备份等技术手段实现数据级别的容灾保护，进一步提升IaaS整体的服务高可靠性保障。
4.2 IaaS能力度量
当IaaS建设完成交付使用后，如何对其提供的服务能力进行度量就是大家所关心的内容了。度量的内容主要分为功能、性能与可靠性三个部分。
4.2.1 功能度量
功能度量相对简单，就是厂商IaaS平台产品能够提供的功能规格，运营商测试只要对照使用说明将交付平台和管理平台界面上所有能输入和能点击的功能都运行一遍就成了。由于不同产品平台的界面肯定是不一样的，因此也没有通用性的测试工具可以使用，只能手动的去逐个测试。用户测试就更简单了，只需对交付平台上运营商提供的产品服务目录功能逐一遍历一遍即可。在整个IaaS平台能力度量中，功能度量是最为基础的部分。
4.2.2 性能度量
性能度量是根据测试角色不同，关注点也有所区别。用户关注的是能够申请到的资源使用性能，如单个或几个虚拟机和数据库实例等，运营商关注的则是整个运营平台能够提供的最大性能规格，例如能支持多少个虚拟机同时运行，能支持多大容量的数据库实例等等。厂商则是关注单产品能达到的最大能力。举例来说某厂商虚拟化平台能够支持1000个虚拟机运行，他就关注这个性能规格能够满足即可；而运营商如希望能对外提供10000个虚拟机的服务，则需要弄10套平台，测试整体方案架构能否支撑这么大的运行规格；对于用户来说，他只要关心自己申请的单个虚拟机计算、网络和存储能力能否达到预期的性能即可。
因此IaaS性能度量可以细化为虚拟资源性能测评（主要还是虚拟机性能。数据库性能测试方法也较为标准化，但由于其归属不清这里不多讲）和云平台规格测评两个主要组成部分。其中虚拟资源性能测评方法及测试工具和我们日常对服务器主机进行性能测评时一致。测试内容主要分为下面四大方面：
CPU计算能力，通常采用一些标准化的任务如压缩、气象和编译等计算模型，查看任务完成所需要的运行时间，一般单位为秒s，结果越小越好。根据不同的测试用操作系统，对应的测试工具很多，如linux系统上收费的SPEC cpu2006和免费的phoronix-test-suites，windows系统上的PassMark PorformanceTest等。也有部分测试工具为了更好的进行比较会将测试结果自行算个分数出来，这个分数在不同的测试工具间就没有比较意义了。
内存处理能力，对指定大小数据块的内存读写速度进行比较，结果单位为秒s或毫秒ms，越小越好。常见的测试工具如phoronix-test-suites和PassMark PorformanceTest等。
IO吞吐能力，衡量虚拟磁盘的读写能力，测试通常采用固定大小数据块对磁盘持续一定时间的读写操作，查看平均处理速率。结果单位分为MBytes/s和IOPS两种，分别是每秒数据读写速率和每秒IO操作完成次数。不同的上层业务应用关注的衡量结果不同，如大文件应用关注MB/s，数据库关注IOPS。测试时标准数据块大小一般从4K-1M翻倍增长，通常采用小数据块（如4K）测试系统IOPS能力，使用大数据块（如1M）测试系统MB/s处理，当然也可以根据业务系统模型选取其他更贴近的值进行测试。测试模型往往覆盖顺序和随机读写共四类场景，通常顺序好于随机，读好于写。这里要注意的一个细节是如果系统开启了缓存功能（软件或硬件），缓存的读写比例设置会对测试结果产生一定影响。常见的IO测试工具有fio、iometer、phoronix-test-suites和PassMark PorformanceTest等。
网络带宽能力，衡量虚拟网络转发能力，通常采用CS结构的双虚拟机节点进行流量收发双向通信来测试虚拟带宽。测试结果以Mbits/s（Gbits/s）为单位。测试工具有iperf、netperf、phoronix-test-suites和PassMark PorformanceTest等。
除了上述的通用型测试方法外，也有通过模拟一组真实应用业务服务访问的方式来进行综合性评价的测试工具，如SPEC virt2010/2013就是通过模拟mail、db、web等一组6个服务应用来测试虚拟化资源性能综合表现。但由于业务层面的测试实际上与用户真实应用强相关，同样的Tomcat服务器配置不同，结果肯定也没有太大参考意义。因此在SPEC上跑出来高分不见得就能真的代表用户的最终业务跑起来能有多流畅，只是个参考而已。由于IT应用技术的模型是底小顶大的锥形，越往应用层走技术花样越多（想想有多少种web服务器技术，有多少种数据库应用），因此可以说测试方法越偏底层测试出来的结果参考意义越大，越往上就越小了。
云平台规格测评是运营商最关注的度量结果，能够体现整体平台支撑的最大能力，并根据此能力提供对外服务。规格测评可以包含但不限于以下内容：
平台最大物理服务器节点数量规格
平台最大虚拟服务器节点数量规格
平台最大虚拟磁盘存储总量规格
平台最大租户并发数量支持规格
……
由于云平台规格测评往往需要测试出最大结果，而实际测试环境很难都做到一比一的模拟，因此可以采用推演或模拟等方法来进行测试。推演就是通过测试几个较低的规律条件下系统表现，来推测出最大承载的能力。例如测试最大物理服务器节点数量规格时，可以测试4、8、16台物理服务器节点下，平台系统各主要指标消耗情况，进而叠加计算出接近临界值的可容纳数量。模拟则是通过开发软件工具模拟大量节点注册交互情况，查看系统能够承受的临界值。例如通过Load Runner等模拟器模拟大量租户对平台资源的申请使用，测试最大租户并发数量规格。但这些方法都有各自的局限性，如推演法只是理论结果，实际在资源使用消耗逼近临界值之前就有可能出现一些问题，导致规格的降低；而模拟器功能单一，不能模拟所有的实际注册交互过程，和真实业务使用情况差别较大。
总的来说，虚拟机性能测试有章有法可循，结果比较靠谱。但云平台受测试手段限制，大多时候规格数据都是猜出来的，越高实际上越不靠谱，只有通过真正的项目实践过的数据才是有意义的。比如有个平台说能支持10万个虚拟机，明显就是演绎出来的数；如果说能支持1024个虚拟机，倒是真有可能是实际一比一测试过的。
4.2.3 可靠性度量
IaaS平台的可靠性度量包含两个方面，一是前面提到的高可靠度量，二是系统稳定性度量。这二者都是运营商所关注的重点，对用户来说，实际上各种可靠性设计和技术应用已经被逻辑化为N个9的指标了，运营商业务中断时间在范围内就OK，范围外就赔钱，服务合同里面都应该写明了，没有什么好争议和测试的。对运营商而言，将多个厂商的杂七杂八软硬件设备堆在一起，在各个层面都要考虑到可靠性设计，再将各种技术风险预估出能达到的几个9指标提供服务给用户，这可是个高技术含量的活儿。当然不排除那种明明3个9的水平，硬充5个9的，这种事情需要风险和收益全方位考虑，如果签合同的水平高些，赔的钱远低于拿下合同的收益，那么指标就编吧，反正几个9都能找到理论支撑的。国内做数据统计向来有先出结果，再编算法往上靠的传统。并不是牢骚，现实如此，很多时候技术只是一方面，做项目要考虑的方方面面实在太多。
回到正题，运营商对IaaS平台进行高可靠性度量时，需要关注多个资源层面的实现，如计算、存储和网络，软件和硬件，系统和协议等。度量的方法很简单，就是故障模拟，看业务恢复的时间和影响范围。测试结果单位可能是毫秒ms、秒s、分钟m甚至小时h。小到一根网线一个进程，大到一个机房一座大楼（可以叫灾备了），不同级别的故障恢复技术对整体方案规划和投资影响差别很大，总得来说，一分钱一分货，投入越多高可靠性越高。
这里将高可靠性定义为可靠性的一个子集，仅代表作者的理解，可能和其他地方的定义说法不一样，大家阅读时请关注其具体意义。名字只是个代号，没有必要太较真，理解其代表的含义更重要。现在的技术概念满天飞，各人的理解又都不相同，混淆不清是常事，抓住核心才是能力。
稳定性度量是可靠性度量的另一个主要方面，关注的是系统部件长时间稳定运行的能力。测试手段无非是大压力负载下的长时间运行，观测系统各项指标有无明显的异常变化。但实际上稳定性测试也属于推论测试，简单的说就是根据一些测试环境下观察的结果去推断更复杂环境下更长时间的运行情况。但推断毕竟是推断，运行两周不出问题不代表运行两个月一定不出问题，模拟的100%压力下不出问题不代表实际环境80%就一定不出问题。测试度量只是用于风险评估的辅助依据之一，只要是系统运行势必有故障风险，任何测试活动都只能有限的降低风险，而不能杜绝风险，千万不要将结果OK的测试报告当作系统能够长期稳定运行的保证书来看。
目前常规的测试周期根据项目需要可分为1天、1周或1月等多种试运行时间，业务系统可使用半负载50%、高负载80%或满负载100%来加压。但之前说过，满规格的模拟手段限制是极大的，因此这里的模拟压力也与真实环境业务压力会有较大差别。虚拟资源方面计算、存储和网络压力模拟工具还比较成熟，但针对整个云平台的压力模拟难度就很大了，原因参考前面的云平台规格测评部分。常见的计算资源压力工具如linux系统的stress和windows系统的PassMark BurnInTest等，网络压力可以采用专业测试仪器或者iperf等软件打流，存储压力可以通过大量数据导入的方式模拟。
5 总结
随着云计算产业的发展，数据中心也已经不再是硬件设备的简单堆积。应用软件的进步和业务规模的提升，都对数据中心系统设计提出了更高的要求。云已经是大势所趋，对于中小企业来说，公有云IaaS已经完全可以满足其IT业务基础架构需要，而对于大中型企业来说私有云或混合云IaaS更加适合，毕竟有很多业务还是不适合都跑到公网上的。总之，云化已经成为数据中心发展的必然阶段，而IaaS系统设计也一定是从传统数据中心继承得来，而不是凭空想象的，大部分传统数据中心设计理念也可以直接继承，没有必要完全推到重来。
了解了云IaaS与数据中心的联系，再来重温一下IaaS与传统数据中心的差异。前面提到过IaaS最大的改进就在于管理系统与交付系统，自动化的管理编排和用户服务是云化的特色，而整个系统的自动化程度则体现了数据中心云化的成熟度。云计算是软件的天下，整个产业利润增长点也将集中在软件产品上，卖盒子的势必都想去改卖光盘，相信最近3-5年势必迎来整个IT行业的大洗牌。摩托罗拉卖给了google，诺基亚大楼也已换上了Microsoft标志，昨日霸主今日黄花，大浪淘沙，唯有技术的车轮是在始终不移的向前滚动。
很久无法沉下心来做技术研究，东西写出来也七零八落的，诸君随便看看即可。
谨以此文献给正在云计算产业大潮中翻腾搏击的IT战友们。

分享

分享

Network World — There’s no scientific formula behind this list: It’s just a bunch of new-ish, mainly enterprise-focused computing and networking companies that have launched, received fresh funding of late or otherwise popped onto my radar screen.

I’ll give you a brief description of the companies, then links to their respective websites or to stories about them so that you can explore further. Don’t read anything into the order in which these companies are presented either: It’s basically the order in which I came across them or their latest news. (IDG News Service and Network World staff reporting is included in this article.)

*Tactus: Appearing and disappearing tactile buttons for your otherwise flatscreen tablet or smartphone. Tactus, which got $6 million in Series A funding in December of 2011, announced a mysterious Series B round in January 2014: Weirdly, no financial details disclosed. One founder led JDSU’s Optical Communications Division, and the other led development efforts for microfluidic-based programmable transdermal drug delivery systems and advanced optical sensors at Los Gatos Research.

*Confide: Quickly became known as Snapchat for professionals not that Facebook has offered $3 billion for it — because like the popular photo-sharing app Confide is designed for highly secure messaging. A Confide messages, on sensitive topics like job inquiries or work conspiracies, disappear upon being read.

*ClearSky Data: This Boston-based startup is enjoying calling itself a stealthy venture on its Twitter account. The Boston Globe has reported that ClearSky’s founders previously helped get tech startups CloudSwitch and EqualLogic off the ground. Highland Capital, which along with General Catalyst invested a combined $12 million in ClearSky, describes the newcomer as “working on solving an enterprise infrastructure problem for medium and large enterprises.”

*Aorato: This Israeli company, which has received $10 million in funding from Accel Partners and others, calls its offering a firewall designed to protect Microsoft Active Directory shops. A pair of brothers are among the company’s founders.

*Nextbit: Rock Star alert! Oh, technical rock stars, from Google, Amazon, Dropbox and Apple, according to the company’s skimpy website. The San Francisco company is focused on mobile something or other possibly some sort of mobile OS reinvention — and has received $18 million in funding from Accel and Google.

*Confer: This Waltham, Mass., startup with perhaps the most boring name on this list hopes to make a name for itself nonetheless with software and services aimed at sniffing out malware and attackers targeting enterprise servers, laptops and mobile devices through its application behavior-analysis approach and its cloud-managed threat-intelligence platform.

*Bluebox: The latest in a long line of “Blue” IT companies (Blue Coat, BlueCat, Blue Jeans, Blue Prism, etc.), this startup has received more than $27 million in venture funding to back its mobile security technology. Its “data-wrapping” technology for Apple iOS and Android is designed to give IT control over enterprise apps but leave personal apps…personal.

*Viddme: No sign-up video posting and sharing app, which works on mobile devices and the desktop. Simpler than YouTube. Development team is out of Los Angeles.

*MemSQL: This Big Data startup formed by a couple of ex-Facebook engineers raised $45 million through January. This database company’s technology is designed to run on commodity hardware but handle high-volume apps.

阅读全文»

分享

分享

2014年再不加入OpenStack你就真OUT了！（下）

上篇：《一场没有硝烟的战争》文中讲到如今各家厂商已是纷争四起，主要是希望换个角度思考一下当前的OpenStack生态环境，文章发布之后未曾料到会得到这么多的关注，特别要感谢一下白小勇等几位好朋友的建议与反馈，谁让大家现在都如此的看好 OpenStack这块香饽饽了呢 :-)

下篇：《开放式创新》一文中将为大家整理一下OpenStack这三年来孕育的创新力量，以及它目前所面临的机遇与挑战。

开放式创新

“开放式创新”这个词最早应该是加州大学伯克利分校的Henry Chesbrough教授的《开放式创新：新的科技创造盈利方向》一书中所提到的，由于开源企业和周围环境之间的界限变得模糊，创新可以在公司以内和公司以外进行。OpenStack通过开放的社区直接把用户引入到这个创新的过程中来，这种以用户为中心的社会化研发方式越来越有优势（如果想了解以用户为中心的民主化的创新如何发挥作用不妨参考一下上篇提到的《民主化创新》一书）。
2013年12月18日，AWS正式宣布进入中国，无疑给云里雾里许久了的中国市场带来许多期望，大家都知道AWS真正的的影响力在于它已经成为美国互联网的创新之源，相比而言OpenStack又带来什么了呢？

首先正如OpenStack名字中所表达的，开放（Open）是这个项目核心的价值。这个成立之初仅有两个基础模块的OpenStack，如今已发展成为拥有9个核心子项目（Havana）一系列孵化项目的庞大开源组织。并且作为开源领域的后起之秀，它博采众长吸收了众多开源组织的优点，比如延用了 Ubuntu社区的发布模式，每六个月发布一个版本（与Ubuntu版本同步发行），借鉴了Apahce基金会和Linux基金会的运作模式，打造一个更加开放的OpenStack生态系统——OpenStack基金会，同时还为开发者提供更成熟和专业的社区管理工具，通过持续集成和基础设施项目为OpenStack开发进度和开发质量提供保障。也吸引到了众多开源领域的专家加入：如Nova项目里的Russell Bryant （Asterisk专家）、Oslo项目里的Mark McLoughlin （KVM、 GNOME、Linux kernel、Java专家）、TripleO & CI system 项目里的Monty Taylor （MySQL专家）等，还有厂商们的大力追捧：Top 3的服务器厂商（HP、DELL、IBM）、Top 3的Liunx发行版厂商（RedHat、Canonical、SUSE）、Top3的交换机厂商（Cisco、Juniper、Alcatel-Lucent）、Top3的存储厂商 （EMC、IBM、NetApp）等等，今年Orcale也刚刚加入这场变革。

社区的蓬勃发展，厂商的不断加入，成熟的社会化研发模式，精英团队的领导（但需不需要有一个灵魂人物也是大家争论的焦点之一），灵活的架构设计都使得OpenStack成为了最有活力的全球开源项目，这种开放也极大的激发了相关技术的创新。所以如果关注OpenStack只是看到大量优秀的代码和框架，不参与到这场令人兴奋的变革中去那你就损失大了，因循守旧就坐等淘汰吧！

OpenStack用户在哪里？

上篇也提到了中国用户对于OpenStack具有较高的认同度，并且已经纷纷开始尝试与实践。这些成功部署了OpenStack平台的企业大致可以分为两类：一类企业属于内部有较强的技术实力，对开源软件有着强烈的好感，他们下 载源码之后几乎可以通过DIY来解决自己问题的（不过这可不是下载几部电影那么简单，你真的要这样做吗？想好怎么升级了吗？谁来为你提供技术服务？）；另一类企业则选择了开源服务供应商，不管是OpenStack发行版还是各种OpenStack解决方案（请结合上篇的各个山头对号入座）。下面我就结合我个人所了解的情况来介绍一下国内OpenStack的用户发展情况，当然肯定会有遗漏或还未公布出来的信息，欢迎大家补充。

DIY用户

记得2011年初，我开始参与在国内推广和普及OpenStack时，国内也才刚刚开始了解OpenStack，很多企业都还在观望，包括之前我就职的一家国字头的Linux发行版厂商。既然项目不是咱们伟大的民族发起的，那咱就虚心学习呗~ 所以当时我们联合英特尔、广州电信研究院等几家单位，在上海市科委的支持下，邀请来了该项目的发起者RackSpace和Nebula（前NASA CTO创建的公司），以及Intel和Dell的海外研发团队来国内布道，共同组织了首届OpenStack上海峰会（后来由于和基金会的 OpenStack峰会在名称上容易混淆而改成用户组大会），国内也只有电信广研院和上海交大几个为数不多的机构和部门开始研究OpenStack。电信广研院后来做了一套开放云体系与OpenStack开放测试平台（OSTP：OpenStack Test Platform），上海交大的团队则对内提供了一套OpenStack运营平台，他们对于SDN网络虚拟化这块也有丰富的经验，另外还基于 OpenStack平台做过Syslog 分析方面的工作（大家有兴趣可以上网搜索一下金教授他们的发表的论文)。
可以看出国内已经有人开始在POC或测试环境中部署OpenStack，但生产环境当时还没有看到。这对于推广OpenStack是个非常大的挑战，所以我当时就四处打探国内到底有谁在实际使用OpenStack，也就是在这个时候我认识了新浪SAE团队的负责人丛磊童鞋，在他的引荐和帮助下找到原SAE团队技术经理程辉，并邀请他们到社区分享经验与心得。虽然当时新浪的规模并不大，但他们确实已经在生产环境中用到了OpenStack中的Nova和 Swift两个项目，并用Swift替换了原有的SAE存储，另外就是内部尝试做了计费Dough和监控Kanyun两个开源项目。
接下来国内OpenStack用户群体逐渐发展了起来，先是瞬联软件、趣游、网易等分别开始尝试基于OpenStack开发部署自己的云平台，之后爱奇艺、 用友、京东、百度、360、美团等纷纷选用OpenStack。例如京东基于openstack的数据库服务NEPO ，该部门对数据库服务有迫切的需求，希望减化相关流程，缩短服务时间，将重复性的工作自动化，也就是所谓的自助式平台化管理与资源封装，而 OpenStack又是一个松耦合的模块化系统平台可以灵活设计。去年基金会组织的OpenStack 3周年社区活动上我还有幸邀请到了来自百度和携程的嘉宾来做分享，当时国内也只有宋伟他们团队在部署了上千台物理服务器的OpenStack上做过测试，而携程则是典型的从VMWare往OpenStack迁移的用户代表（不知会不会因此被VMWare公关，哈哈）。对于大多数“领先用户”来说，他们内部有大量现成的服务器，已经开始尝试上虚拟化，因此无需购买新硬件，并且可以暂不考虑高可用，只为控制节点做备份，简化了应用场景。而数据又不想放在公有云里，因此希望能够为自己内部提供IT基础设施，优化业务流程，或者作为开发测试环境加速产品开发速度，当然最后期望能够提供类似公有云的服务。
但总的来说初期大多数用户都将OpenStack作为私有云服务，并且有发展成为OpenStack云服务提供商的趋势。当然也有部分玩家希望先基于OpenStack做公有云，认为如果OpenStack公有云平台能支撑住成千上万的虚拟机，做私有云就不是太大的问题。私有云中大部分也并没有采用直接替换现有系统的方式，例如携程（花旗银行之前的报告也曾提到过提供OpenStack发行版的价值要低于交钥匙的方案，还预测得私有云用户者得天下）。

付费用户

2013 年开始我和我的团队开始为部分国内企业客户服务，所以接触到一些付费或有意向用户。 如IDC客户，因为随着微软Azure与AWS的进入，外资领先的云服务商可能对国内IDC企业造成毁灭的打击，IDC正在转型的关键节点，迫使他们必须从卖资源转型到卖服务。而目前国内公有云现状是：没有成本优势 ，规模无法实现盈利，不计成本很难持久，几乎没有提供相关的API，不能给用户提供按需付费的交付方式。所以说AWS模式很难在国内复制，特别是AWS采用的DevOps模式，要知道有600多人在AWS产品线，并且他们无需客服人员，用户自助、互助服务，国内没有客服你都不敢想象会是什么样子。

还有一些金融客户，他们面临大数据的机遇与挑战，正在努力寻找突破。相对来说，互联网企业投入其实并不大，几个人的团队就已经足够为云平台提供运维支撑，出了问题也是可以自己抗的。金融客户重点在于关注自身的业务，而底层的基础设施服务希望能够通过第三方服务提供商来提供保障，进而可以加快项目实施进度。政府和教育行业也同样， 他们面临定制化开发风险，面对升级维护等问题时也倾向于选择第三方服务提供商来实施自己的云平台项目。
而安全可靠成了企业级用户在迁移到云平台时首先关注的问题，另外如何基于开源的 OpenStack 技术对企业应用进行优化，并为 OpenStack 核心组件设计高可靠和高可用方案，甚至要要为多租户提供分布式虚拟化防火墙，基于 SDN 技术为上层应用提供按需的网络资源及服务，完善监控和管理周期，实现全面自动化等。如何提高消息队列服务的高可靠性，避免因为发送消息到写入消息之间的延迟导致的信息丢失，如何实现 mysql 的高可用集群等都是企业客户比较关心的问题。我们在为客户实施时通过支持OpenStack的防火墙为租户网络隔离提供支持，通过 OpenFlow 交换机与协议对网络进行编程控制，打破了现有网络对业务封闭的问题，利用网络流量的可视化及灵活的编排，将流量导入特定的业务服务器、防火墙或者IDS/IPS 设备，确保应用程序以及流量的正确流向及安全可靠。

我们正在改变世界

在这过去的一年中，国内 VC们也很忙，苦苦支撑的国内云计算相关企业纷纷拿到融资。启明创投对七牛的投资，红杉资本对够快的投资， DCM和贝塔斯曼对UCloud的投资，涌金对华云的投资，光速安振对QingCloud的投资，以及一批项目的天使融资，让我们感受到了云计算市场的活跃。

国内几家专注OpenStack的初创企业也纷纷传来喜讯，先是年初UnitedStack获得红杉资本、ChinaRock、IDG的天使投资，年中中路股份投资了道里团队，11月份易云捷讯获得用友幸福投资和信中利集团的联合投资，年底的时候海运捷迅也斩获了A轮战略投资，还有最近一家新成立的 easystack也刚刚拿到了蓝驰的投资，还有stackinsider（云动科技的一个项目）等初创企业纷纷开始为国内客户提供OpenStack相关产品及服务。

IDG Connect发布的2013年度 OpenStack云发展路径的调研报告结果更是显示，绝大多数接受调研的企业IT决策者表示，OpenStack已纳入其企业云计算基础设施的未来计划当中。调查结果提到，随着企业用户可以越来越重视去解决这些问题，企业用户正在或有计划的向OpenStack私有云迁移。有60%的受访者表示，他们正处在配置OpenStack的初期阶段，有的尚未完成，或者还在实施过程当中。有84%的受访者表示OpenStack的是他们未来云计划的一部分。

说到这里忍不住想提一下TryStack.cn，早期为了推广OpenStack，解决大部分用户没有安装部署环境，另外各种组件及插件也不知该如何选择，还有版本升级更新维护等问题，所以在英特尔、山石、盛科等相关企业的支持下，提供了一个OpenStack测试体验环境，并公开了它的参考架构，从F版开始每个版本都及时更新，如今已经部署到最新的Havana版本，并在去年香港峰会上发布了面向企业的Trusted Enterprise Cloud 参考架构。

OpenStack生态系统将会重新洗牌

开放并不等于免费，所以如果把自由（free)当作免费 (free)那就图样图森破了。正如Mirantis有篇博客里写到的那样“Some companies will get acquired, while some others will get acqui-hired.”，OpenStack确实给一些初创公司带来了很高的知名度以及投资机会，但基础软件开发周期长，投入大、见效慢，技术创新转化成产品需要更多时间，而现在还搞不清楚用户在哪里的初创公司已经逐渐失去往日的光辉。

开放最大的价值在于创新，并且是超越了公司界限的创新。 开放协作才会有利和促进产业繁荣发展，这也是我发起TryStack社区联盟的主要用意。虽然越来越多的朋友开始拥抱OpenStack，并开始把 OpenStack作为创业途径或新的发展方向，但教育客户和培养市场的工作任重而道远。希望国内的OpenStack生态圈也能更加开放，充满活力，才能吸引更多人才加入到这个大家庭中来，一己之力毕竟是有限的，吸引更多人参与类似的事情当中才是有意义的，也希望看到越来越多的在OpenStack线体验或测试平台上线（或许大家可以反馈给我来做个统计？）。

去年我在给北航云计算硕士班的学生们讲OpenStack这门课时，曾说过好好花半年时间学习一下年薪30W不是没有可能（也不是说一定能拿到 :-)），今年看来门槛仍在不断提高，有朋友曾回复我说没有看懂上篇里的人才之争一部分的内容，其实我想告诉他的是创业团队和巨头们之间的人才之争已经愈演愈烈，丰厚的薪水还是美好的未来，你想好了吗？

分享

分享

［原文可参阅： http://duyujie.org/post/72355803255/2014-openstack-out］

2013年底最后一周突然收到两封邀请函，一封是来自微软，邀请我参加2014年1月微软开放技术有限公司中国运营启动仪式，这是微软新成立的一家专注于开源技术的全资子公司；还有一封是来自华为，邀请我前去为其某产品线做一个关于社区与运营的报告（上一次去华为还是2013年6月份，在他们加入OpenStack基金会之前，受邀前去深圳总部为云计算产品线做的关于OpenStack社区的报告），看到国内外的企业都越来越关注和重视开源社区，真是2014年的头等喜事。欣喜之余我整理了一下几年来对OpenStack社区的所见所感，希望对于想要了解OpenStack的朋友能够有所帮助，关于社区运营的的话题稍后我会另外再写一篇。纯属个人观点，仅供参考，拿砖头的、丢臭鸡蛋的看准了再扔:-)。

一场没有硝烟的战争

去年11月份，在香港举行的OpenStack峰会是OpenStack基金会首次在美国本土之外举行的大型社区活动。在这次峰会上，作为众多开源云架构中最受宠的OpenStack享受到的不仅仅是来自全球企业和开发者的高度热捧，主办方也是想尽一起办法彰显中国元素。

图1 -OpenStack香港峰会

无论是现场观众得知目前全球范围内拥有最多的OpenStack开发人员的城市是北京时的惊呼，还是在峰会期间，特意邀请来爱奇艺、奇虎360、携程等来自中国OpenStack用户所做的经验分享，无不显示出OpenStack基金会对中国市场的重视。

而每一场开源运动中，技术人才的争夺都是白热化的。OpenStack在开源云平台的人才大战中取得了不可思议的成绩，从2010年到香港峰会结束，三年的时间里，OpenStack社区已经遍及全球132个国家，13504人参与，其中个人开发者人数达到了近6000人，而支持厂商/组织共有298家，按级别来分共有8个白金会员、19个黄金会员、54个赞助公司、217个支持机构(截止至2013年12月31日)，这样的规模对于一个开源组织来说，可谓声势浩大。

图2-开源云计算社区对比参与度对比[1]

但看似一团和气的大家庭其实私下也是暗潮涌动，感受最为深刻的就是香港峰会展区里到处摆放着的RedHat Partner的牌子，可以说大家为了抢占至高点，用尽了各种手段招数。

图3 -香港峰会展厅

如果配上旁白的话大致如下：

• Redhat：我们拥有OpenStack社区主流影响力，我们会像征服Linux一样征服OpenStack世界。
• Canonical：我们是OpenStack部署第一的操作系统厂商，与OpenStack发布周期同步。
• RackSpace：我们创造了OpenStack神话。
• Mirantis：我们服务的OpenStack客户最多。
• CloudScaling：我们为OpenStack客户提供更多选择（AWS）。
• IBM/HP：我们是IBM/HP，我们为OpenStack做了不少贡献（不过我也知道你提供OpenStack是为了卖更多的XXX，Unix时代你不就是这么干的吗）。
• 现在连Orcale也想挤进来，可惜暂时还没想好他们的潜台词，如果您有更好的想法欢迎反馈给我:-)。

这不禁让我想起前段时间网上吐槽一则“雾霾对武器影响多大：侦察看不清导弹打不准”新闻时的一个段子：

美：我们有B52轰炸机。中：我们有雾霾；美：我们有精密雷达。中：我们有雾霾；美：我们有精确制导炸弹。中：我们有雾霾；美：我们能把你们的城市从地图上抹去。中：你们不能，我们能。美：你们有什么武器做到？中：我们有雾霾。

再看看这帮军阀们手中的武器都有哪些：

RedHat 作为老牌Linux厂商，手握Libvirt（别告诉我你不知道这个项目意味着什么）、KVM还有Gluster，最近CloudForm也是耍的有模有样，更别说OpenShift，oVirt等宝贝了。Libvirt和KVM反正是绕不过去了，所以Canonical很早就和 Inktank抱在一起，当然是试图希望通过Ubuntu和Ceph的整合来对抗RehHat的Glusterfs。而SUSE仍是紧抱微软的大腿（其中缘由请自行谷歌），不知是不是希望通过Hyper-V绕开RedHat 的KVM。其实RedHat 也没闲着，PLUMgrid的加入让人不禁猜想是否想对VMWare NSX + vCenter构成威胁？

武器在手免不了占山为王，所以除了各自产品的较量，更重要的还有山头之争，目前都有哪些山头呢？

第一个山头自然是对上游的影响力

图4-OpenStack基金会

在OpenStack社区里真正有影响力的当然是技术委员会的PTL和Core开发者，主要由他们决定OpenStack的开发方向，不过来自企业的代码贡献量也能说明不少问题：

图5 -企业贡献排名

从最新统计中可以看出Rackspace已从D版和E版的第一名贡献者已经下滑到H版的第三名，并且还有下滑的趋势；Mirantis从上一版的16位飞速上升到第五；HP和IBM最近几个版本倒是一直都在前五；RedHat从F版开始就一直领跑（Canonical的老大不知咋想的？），RedHat早已牢牢地控制住了Linux主要市场，如今看来他们对OpenStack也是势在必得，想想Cloudera和Hortonworks怎么争夺Hadoop的（这两兄弟也不知有没有分出高下？）。

进化论告诉我们物竞天择，竞争的结果就是用户直接受益。目前看到无论是你想要的度量和计费(Ceilometer)，或者是配置管理和编排服务（Heat）、甚至是部署服务(TripleO/Tuskar)和PaaS(Solum)服务在OpenStack中都有了各自的模块，所有你想要的一切，社区都会逐步的整合进来，所以不要再试图维护自己的专有分支或模块了，拥抱社区并参与贡献上游吧~

第二个山头应该算是服务提供商了

由于这块目前入门门槛比较低，但早期市场主要在这里，更接近早期的“领先用户”，并且提供服务的公司可以在这些客户的付费中成长，对于处于市场培养阶段的的OpenStack厂商来说自然也是必争之地。

实践证明参与产品开发与改良的用户很多，创新用户的研究表明，这些用户具有“领先用户”的特征，也就是说他们在一个重要的市场趋势中领先于用户总体的主流，而且他们为了自己所遇到的需求期望从一个解决方案中获取相对较高的收益。由于领先用户在重要的市场趋势中处于市场的前端，所以我们可以相信，许多他们自己开发使用的新产品也会吸引其他用户，即他们可以为愿意将创新产品商业化的制造商提供产品基础。

                                                                         ——节选自《民主化创新》

图6 -商业模式和生态系统

这个山头占据了几乎主要的OpenStack市场份额，引得大多数OpenStack厂商都杀向了这个山头。在这个山头上在新秩序还没建立起来之前，大家都被Linux世界的大佬们划分成鲜明的两大阵营：RedHat和Ubuntu。

第三个山头就是各自的相关产品

前面提到RedHat和Ubuntu作为上个时代的开源领袖，目前都开始角逐OpenStack时代的最强者。而Mirantis绝对是匹黑马，过去的一年当中连续推出了 Fuel for OpenStack deployment、Murano for Windows and Linux、  Savanna for Hadoop，Rally for testing and benchmarking等开源项目，还放出了Stackalytics统计社区的代码贡献量，硬件在线评估系统，几乎把能赚钱的工具都统统开放了出来，如今更是把它们整合成了Mirantis OpenStack 4.0，绝对值得期待！另外OpenStack的发起者RackSpace虽然放权给基金会，但并不意味着放弃整个市场，12年下半年就曾推出其私有云产品Alamo现在已经更新到最新的Havana版本的了。当时思科紧随其后也曾推出过一个OpenStack发行版本，不过随后就没什么音信了，倒是其公开的文档吸引了不少用户的关注[2]。

而CloudScaling 似乎和AWS走的很近(参见[3]： 一封致OpenStack社区的公开信)，并且由于瞻博和希捷参加了Cloudscaling 2013年B轮1000万美元的融资，所以他们的OCS似乎也很值得尝试。另外Piston 和国内程辉团队的UOS比较像，可最近声音都不多，不知出了什么状况？（Piston 2013年也拿到了B轮，目前融资总额1250万美金）。

另外两匹黑马Metacloud和Morphlabs，一个是做Managed service，另一个做OpenStack Applicance，倒也是风声水起，其中Metacloud在2013年6月刚获得1000万美元的A轮融资,投资者包括canaan Ventures、Storm Ventures和Jerry Yang(former Yahoo co-founder)的AME Cloud Ventures。MorphLabs 2013年D轮之后总共融了2250万美金，我在去年的CloudConnect China大会上曾邀请他们来上海分别做过交流。

最后还有培训这块山头

别小看了培训这不起眼的生意，大家都是醉翁之意不在酒，主要都是看重生态系统的建设。RedHat的Linux培训体系就是一个很好的证明，Cloudera的Hadoop培训也类似。他们一方面通过继续贡献社区提升对上游的影响力，加快代码修复速度，另一方面通过培训体系打造自己的生态系统。除了上述提到的几家厂商之外，还有swiftstack专门提供针对存储模块Swift的培训。目前国内唯一能看到的应该就是TryStack联盟成员Mirantis授权的培训课程（详细内容参见[4]）。

[1]CY13-Q4 Community Analysis — OpenStack vs OpenNebula vs Eucalyptus vs CloudStack

[2]思科wiki

[3]一封致OpenStack社区的公开信

[4]OpenStack培训

分享