分享

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战友们。

分享