浅谈私有云架构设计

"All models are wrong, the practical question is how wrong do they have to be to not be useful."
George E.P. Box and Norman Draper (1987)

在开始讨论私有云的架构之前我们首先确定一件事情，即没有架构是完美的，它们多根据业务和应用进行针对性优化改进，甚至有时被完全推翻，才最终满足或超越需求。

 

私有云客户与公有云客户最大的一点不同是——私有云客户对本地的“云”实体拥有最大处置权限，可以很放心地把有可能涉及到公司或者单位隐私的东西放上去。并且私有云就服务器规模、SLA、防火墙、计费、安全性等级要求等方面而言，与公有云有着不同的侧重点，架构上自然也要区别对待。

基础架构

基础架构的设计是私有云架构的重点之一，其构建原则简言之即是——扩展性、稳定性、冗余性。

扩展性

扩展性包含两个方面：集群横向扩展以及与其它平台进行资源（存储、网络、虚拟机等）进行交互。

集群横向扩展主要包括计算节点、存储、网络资源的扩展以及扩展后的聚合。计算节点新加入集群后，其上的所有业务均能在新节点正常运行；同时，新节点的加入对用户来说是透明的，即用户不需要额外操作就可以正常使用。

平台在扩展时，不应止于基础资源的扩展，也应包含业务资源的扩展。比如，某企业内现有某国际大厂商的虚拟化产品，如果国内的虚拟化产品能够直接使用或平滑迁移原平台的虚拟机、虚拟硬盘甚至是虚拟网络的话，那么对企业来说这个过渡将会是很轻松的。

现在能够提供云平台API的厂商比较多，而能够作为标准的只有Amazon、OpenStack、VMWare等国际化平台。中国云计算协会目前尚未制定出一套靠谱的“标准”，作为国内云计算厂商我们现在遵循国际化的总是好的。

稳定性

基础架构的稳定性对于一个平台是至关重要的。存储、网络、计算节点自身的稳定性，以及它们之间通信的稳定性，都时时刻刻影响着用户体验。稳定性不单单是连续运行多久无故障，也包括系统监控、问题解决的能力。

冗余性

冗余性是稳定性和扩展性的补充。对于私有云项目而言，其成本往往仅能满足稳定性所需的资源要求，而在冗余性保障上有较少的支出。当成本不足以满足所有基础资源的冗余性的时候，就要根据具体环境做出取舍，尽量保持它们冗余能力的平衡，最大程度地减少潜在风险。

1、合理的存储配置
存储接入方式：

私有云中的存储配置按照接入平台的方式可分为本地存储和共享存储，而它们之间又可进行自由组合，除专用本地存储、共享存储外，也有比如NFS挂载作为计算节点的本地存储，或者计算节点上的空闲空间组合为分布式存储等解决方案。

图1中有本地硬盘、共享存储/FC/SCSI存储作为本地存储的两种用例，后者应用相对较少；图2中节点1直接使用外部存储作为共享存储，节点2和3提供本地硬盘作为Ceph/Glusterfs的存储后端，再使用Ceph/Glusterfs作为共享存储。

存储的接入方式对平台的都直接或间接的影响，并各有优缺点。
使用共享存储：

• 虚拟机可以进行在线迁移，合理利用服务器资源，增加业务连续性；

• 计算节点宕机不会造成虚拟机单点故障，提高稳定性；

• 可以更灵活地应用备份机制，并且扩容相对简单，提高可维护性；

• 可与其它业务或者平台共享存储，提高扩展性；

• 存储与计算节点逻辑、物理都分离时，架构清晰；

• 对网络连接路径较为依赖，计算节点增加时可能需要增加线路隔离流量；

• 可以利用网络缓存机制，减轻启动风暴影响，但对存储硬件有一定要求。

使用本地存储：

• 虚拟机存储更加独立，某个用户的资源过度使用不会对其它服务器上的虚拟机的造成读写性能影响，从而保证用户体验；

• 可以利用相对高效的本地缓存机制，减轻启动风暴的影响；

• 存储成本投入较小；

• 计算节点宕机时会造成其上所有机器不可访问，即单点故障损失较大，影响平台稳定性；

• 虚拟机在线迁移有难度，难以平衡集群负载。

存储后端:

此处的存储后端即平台存储资源的核心，组成部件不止于机械硬盘、SSD，也包括其通信链路、固件等。存储后端性能与其上的虚拟机紧密相关，如果选择不当会降低平台整体性能，从而影响用户体验。

在私有云项目的实施中，往往既有高速存储设备，又有相对低速的存储设备，我们要根据“业务”来规划存储使用，接下来我们做一次实验用数据简单说明如何选择存储。首先使用一块SSD代表成本较高的 高速存储 ，一块SATA 15K代表 相对低速存储 ，这里的“业务”是指启动以链接克隆方式创建的虚拟机直到其进入桌面。

注解：

kvm中的“完整克隆”、“链接克隆”
在虚拟化平台中，一般有两种新建实例的方式：克隆（完整克隆）与增量（链接克隆）。
克隆即完整克隆模板配置与硬盘，硬盘的创建方式一般为cp或者qemu-img convert。如此创建的实例，其硬盘与模板硬盘相对独立，在服务器存储上拥有各自的扇区位置，所以在读写操作时受机械盘磁头引起的小区域并发问题影响 较小，缺点是创建时需要消耗一定时间，不能满足秒级创建的需求。
增量即新建虚拟机只复制模板配置信息，但其硬盘文件通过qemu-img的backing file方法创建，基于backing file创建的硬盘不能是raw格式，命令如下：
qemu-img create -b hda.qcow2 -f qcow2 hda-new.qcow2
如此创建的硬盘对模板硬盘的依赖较大，非增量文件的读操作（比如启动系统）绝大部分在模板硬盘上进行，所以在传统机械盘上多个实例的并发启动风暴更容易在此种格式的硬盘上发生。

企业级 15K SATA 1T硬盘启动xp实验
所有实例、模板位于SATA 15K 1T硬盘上启动的结果如下：
启动20台XP的CPU及I/O用度，全部系统在第300秒左右进入桌面：

企业级 480G SSD启动xp实验
所有实例于Intel 480G SSD硬盘上启动的结果如下：
启动20台XP的CPU及I/O用度，全部系统在第35秒左右进入桌面：

高速设备比低速设备拥有更高的IOPS以及更高的读写速度，但由于两者成本相差很多，全部使用高速存储会增加很多项目成本。在实际实施中，高速和低速设备搭配使用，比如将高速设备用于存储模板和某些高IOPS虚拟机，低速设备用于存储普通虚拟机，这样从成本和用户体验综合考量，方可获得比较理想的配置。

2、稳定的网络基础

一个优秀的IT架构一定有一个优秀的网络基础架构。网络在私有云的影响有时比存储更加直接。比较多的私有云项目是在已有 IT架构的基础上进行延展，而不是厂商独立完成整个架构，所以清晰整个用户端网络拓扑就显得格外重要。在笔者接触的项目中，有比较多的问题是网络不稳定、拓扑接入不合理造成的。虽然我们在项目中极少拥有对用户网络改造的权力，但我们仍然要在全局拓扑视图下进行网络规划，并在关键结点与客户及时沟通，尽量减少网络问题造成的诸多 “麻烦事”。

对于构建一个稳定的网络基础来说，传统OSI七层模型很有参考价值，而侧重协议实现的TCP/IP的四层模型也很实用，在此我们使用它们的混合模型来分层讨论。

传统OSI在服务、接口、协议有所侧重，但是它由于历史原因以及实现等问题，现在仅仅被人奉为“经典”，具有的参考价值大于实用价值。而TCP/IP的实现由于其模型简单，很大程度上促进了互联网时代的来临，但是使用它来描述比如蓝牙网络，基本上是不可能的了。而混合五层模型即吸收了它们 的优点，又一定程度上回避了它们的缺点。

同存储资源一样，我们在构建私有云网络基础的时候也要关注其稳定、扩展、冗余的能力，同时注意成本。

物理层

在物理层，我们需要做出选择的方面有传输介质、无线传输方式。

在后端资源链路中，一般有计算节点、存储之间，计算节点、网络之间，存储、存储之间以及计算、网络、存储的内部通信链路。其数据量或高或低，对于私 有云而言可以采取后端全万兆的链路以减少后端对整个平台产生的短板效应。因为对于私有云而言批量启动是会经常出现的，所以至少计算节点与存储的链路一定要 有所保证，从而防止网络带宽成为存储能力的制约影响用户体验。

服务器与前端的链路数据根据私有云业务的而异，主要是控制台画面传输、交互（键鼠输入、外设重定向数据、语音等）、文件传输（云存储）等。一般到客户端汇聚层的链路使用千兆双绞线，到客户端使用千兆/百兆双绞线。

数据链路层与网络层

这两层中我们要关注的部分主要是不同层次的交换机/路由置配、IP、VLAN的划分，除非对于完全自主搭建网络的厂商，否则我们只要了解其基本拓扑和路由配置即可。

目前比较主流的网络规划为环网＋星型拓扑，并且按照核心层、汇聚层和接入层区分职责。

在平时的网络实施中我们需要注意以下几点：

• 组网的有多种，不同规模可以使用不同的混合拓扑；

• 在私有云的架构中，网络标签更偏向以功能逻辑而不是以地理位置区分。这点在开源云实现中体现的很明显，比如Mirantis OpenStack部署规划选项中以及oVirt的逻辑网络；

• 由于后端资源链路较多，一般情况下会使用VLAN（tagged/untagged）来进行隔离；

• 非核心资源尽量采用dns＋主机名的方式进行搭建，防止以后IP变化带来的维护困难；

• bonding是比较常用的增加冗余和带宽的措施，但要注意交换机关于bonding负载均衡的策略，比如IP、MAC、TCP Port等组合,防止bonding不适用于我们的场景；

• 交换机尽量采购同一品牌，以免增加运维人员负担。

传输层与应用层

我们需要保持网络稳定高效的主要目的之一就因为这两层，因为它们对用户接入、桌面协议、业务网络、资源网络、控制协议等有直接影响。

其中，从客户端到云平台需要保持良好通信的有Web、Spice/VNC、RDP等，服务器之间则有ssh、sql、telnet、smtp等直接影响业务等应用层协议。

而在传输层中，经常出现的问题有网络拥堵、过载、超时、延迟等问题。比如当一端等交换机或者设备达不到处理大量报文所需的计算能力、内存时，就会导 致丢包或者多次重发的现象；当有错误或者恶意报文进行广播时，所有机器都会返回错误信息而导致广播风暴；当有大量机器重启从DHCP服务器获取IP时，也 会对服务器造成很大负载；报文的超时时间对应用的影响也很大，过低会导致在网络繁忙时大量应用超时，过高会引起传输效率变低从而影响视频等实时应用卡顿。

以下是笔者设计主机网络时的一些经验可供参考：

• 终端/服务器的带宽要尽量保证不低于直接连接的网络带宽，否则当网络端（有意/无意/恶意）发送大量报文时，会造成主机网卡处理能力的大幅下降，影响主机的应用性能；

• 适量增加封包大小，减少数据发送次数，从而降低网卡负担；

• 适量调整报文超时时间，减少网络繁忙时产生拥堵；

• 在可以压缩协传输层议头甚至数据的条件下优先压缩协议头，从而减少报文传输次数降低流量；

总之，私有云网络设计与传统网络架构设计相比，需要考虑的变量更多。尤其近些年软件定义网络（SDN）的发展，以及OpenStack、VMWare中网络虚拟化的推进，导致私有云/公有云对厂商的综合素质要求更高了。

3、可靠的计算资源

提供考量计算资源的标准，不止于物理服务器的性能，还有集群能力比如负载均衡、高可用等重要因素。接下来，我们从硬件、软件结合私有云的特性进行计算资源服务器的选择。

硬件

一般CPU、内存是决定服务器能够承担多少负载的决定性因素，而硬盘、NUMA和扩展属性保证着服务器运行的稳定性和功能性。

多数厂商在部署私有云时，往往按照CPU逻辑核总数和虚拟机总核数按 1:X 来分配，当虚拟机有卡顿或者其它情况出现时，再调整比例。这一点在笔者看来是很不好的习惯，因为它忽略了太多事实，比如CPU最大主频、非NUMA核间数 据拷贝代价、虚拟机运行程序时的保证峰值负载等。

笔者在此使用一个经验公式来计算：

其中，sockets、cores、frequency分别代表服务器的物理CPU数量、单CPU线程数、最大主频，当超线程HT打开时获得20%的提升，否则不提升，cap代表服务器的能力。

注解：
http://www.dasher.com/will-hyper-threading-improve-processing-performance/ 
http://www.vmware.com/files/pdf/techpaper/VMware-PerfBest-Practices-vSphere6-0.pdf

假设一个Windows 7桌面普通办公流畅的最小负载为2.0Ghz，使用双路Intel E5-2630 v3，则cap为61.44GHz，即我们这台服务器可以保障30台单核Windows 7桌面流畅运行。由于桌面应用程序往往可以利用多核特性，所以我们会考虑分配其双核甚至四核，同时其单核负载下降，亦可以看做2 * 1 Ghz，加之峰值负载下的机器并发量少，我们可以再适当增加虚拟机数量。在选配CPU时，我们要根据实际负载、桌面应用、成本等因素综合考量，尽量减少 CPU性能的瓶颈或者过剩。

NUMA技术和主板省电选项（C1E）同样也会影响服务器CPU性能。NUMA技术会大幅提高CPU间通信，换句话说，当有较多进程存在时，利用 NUMA可以减少进程在CPU之间切换的时间，一般建议打开。对于高I/O、低CPU利用率的应用，主板使用C1E或者更深度的电源管理选项（C1/C3 /C6）时会较大程度地影响其性能。目前在KVM中，缺少C1E动态开关的选项，所以建议在BIOS设置中关闭此项。

内存技术也是影响虚拟机的重要因素，目前在kvm中可以使用balloon、large page、KSM等技术提高内存使用效率。虽然内存可以超分（over_conmit），但我们仍然要保证物理内存大于所有虚拟机分配内存，因为内存不足 导致的问题一般比较严重，对于服务器来说甚然。另外，当内存充足时我们最好关闭swap分区，因为如果有进程被交换到它上时会比较重地影响性能。

计算节点的硬盘配置可分为系统盘和数据盘，系统盘即运行虚拟化节点所需操作系统的硬盘，数据盘即用于本地存储或者共享存储的硬盘。当采用共享存储时，可以省去服务器数据盘配置。

扩展插槽中可以添加RAID控制器、JBOD控制器、GPU卡、网卡等高速设备。而USB控制器则用于加密狗、U-Key透传等功能。这两项外设扩展在特定的服务器中可以进行额外扩展。

操作系统

计算资源的操作系统首先要做到效率高、稳定性好、兼容性好，其次是无状态、易维护等。

在效率上我们能进行很多比较系统的优化，比较通用的有进程调度、驱动程序优化、I/O优化等。通用的优化做好以后就可能需要对具体硬件进行针对性的驱动、调度优化。通用的优化是可移植的，而针对具体硬件的优化难以保证，所以我们在这两方面应有所取舍。

稳定性是考量系统的重要标准之一，影响它的因素或是系统本身，或是软件，或是硬件。一般私有云厂商在进行实施之前，如有可能会对服务器进行连续中低压测试，确保其稳定性后再进行软件的部署。

服务器硬件兼容性问题伴随着硬件厂商和操作系统厂商（尤其RedHat）的紧密合作，它的出现情况已经比较少了。但是一旦出现兼容性问题，一般都比较难以排查，往往需要硬件厂商提供协助。

所谓无状态操作系统时，即我们需要这个计算节点异常断电重启后无需人工干预继续提供服务。它提供了一种类似还原模式的操作系统，降低了系统损坏后难以修复的几率同时减少了运维负担。其实现方式比较多，包括DOM盘、PXE、SQUASHFS等。

至于易维护性的对象，主要针对服务器的状态监视、系统软件修复/升级。

注解：
操作系统的选择

目前笔者所用的云平台都是基于CentOS/RHEL系统。其主要原因就是社区的维护时间—CentOS每个大版本是10年左右，Ubuntu/Debian为5年，SUSE为10+3年（期限虽长但对应主流云平台知识库较少）。

当然，形象我们选择服务器的软件因素仍然有，比如下图中就是虚拟化软件的典型架构，其中哪部分使用或高或低配置的服务器甚至虚拟机作服务器我想还是要厂商自己调研一下更为妥当。

架构安全

当人们讨论安全时，首先想到的可能就是一个复杂的密码，还有不同网站使用不同的密码。作为被各种网站注册页面包围的现代人来说，这是一个好习惯。其 实，对一个面向终端用户的系统而言，密码只是它复杂又精密的安全机制体现之一。一个系统安全机制实现的复杂度直接关系到用户数据的安全保障程度，它始终以 用户数据为核心，以保障系统自身安全的条件下保障用户数据的安全性。

认证与授权

认证（authentication）与授权（authorization）历来是安全系统重点关注的部分，即使在现实生活中也是这样。认证过程发生在进入系统时，授权是对系统进行操作的过程中。

让我们用一个面向过程的方式来叙述一个场景：外网用户A君出差在外接到上司电话，要求他配合在公司内的人员检查今年的Q1账目，于是他连到咖啡馆提 供的免费Wi-Fi，打开公司网页输入他的企业帐户信息，然后打开公司提供的私有云平台，登陆进桌面，从云存储上拉取了最新的表格开始校验，完成后他发送 给同事检查，然后他去趟厕所，回来一起确定无误后配合同事提交至ERP并再次检查发送邮件通知相关人员。这一切都结束时，已经不知不觉过去一个下午了，他 关闭虚拟桌面中的程序退出登陆关闭连接，合上电脑离开咖啡馆。

假如你是黑客，不利用社交工程而使用传统技术的话，如何获取他提交到公司的ERP信息呢？

首先，你在咖啡馆中创建了一个开放的Wi-Fi，截取了所用连接到Wi-Fi的终端用户数据流，你从中找到了他的XX牌电脑的MAC地址从而完整地 提取出了他的数据流。你提前伪造了他公司的外网证书，又劫持了局域网DNS，所以他在其电脑上的所有操作对你来说都是明文。然后你从数据流中看到了他的公 司帐户信息，接下来你看到了似曾相识的协议头，但是尝试了你所知的各种协议，都未曾成功。你接下来试图用他的帐户信息登陆，发现只有个需要指纹认证才能登 陆进的虚拟机。机敏的你或许趁他上厕所的时间从咖啡杯上提取了指纹，然后成功登陆进虚拟桌面但是发现你没有权限执行任何操作，包括安装软件、访问外网。最 后过了不久你便被踢出桌面，并且发现截取到的密码也被更改了。

OK，以上虽然是笔者杜撰的场景，黑客手段也比较简单，但是希望读者认识到认证与授权在整个流程中发挥的作用。

在传统认证中，普遍使用AD、LDAP等作为网络信息服务器（NIS），其中都有类Kerberos实现。对于私有云来说，都需要这种NIS访问方 式，以便接入系统并启用SSO特性（Single Sign On）。本文不讨论Kerberos的技术实现，只简单介绍其原理方便理解整个架构。

可以看到用户与服务的认证授权过程很清晰，实现时注意需要用户/服务端/KDC三者时钟同步。当用户进行登录以后，他使用任何应用都不再需要再次输 入密码认证，应用程序通过用户第一次获取的key向服务请求对应的权限，并且所有权限都可以进行细分管理。SSO在私有云中乃至整个IT架构中都起着很重 要的作用。

服务安全性

对于用户来说，将数据保存在一个放心的环境里能减少他们很大程度上的担心。对于管理员来说，假如被入侵，那么损失/泄漏的不止是用户数据了，更会丧失用户对整个平台的信任。接下来我们从三个方面来增加我们服务器安全性。

网络

网络安全是我们第一个要考虑的事情。从功能上我们将网络划分为用户接入端网络、传输网络、后端网络。我们很难保证用户接入端网络的安全性，所以普遍做法是在传输网络与后端网络上实施安全防护措施，包括加密传输、防DDoS/CC攻击防火墙、流量限制等。私有云中，不仅要对外网流量进行防护，更要对内网流量进行监控和防护，我们要采取一定措施进行区分。

加密传输
在比较流行的私有云平台中，所有服务的TCP/IP传输都可以选择性地使用SSL/TSL进行加密传输。而在进行SSL/TSL加密传输时，有两点需要注意：

• 确保至少有一个可信的根证书颁发机构颁发的根证书，对于小规模私有云来说，可以使用二级可信证书或者自建可信域；

• 谨慎管理私钥及其备份，防止外泄。

防DDoS/CC攻击

整个平台给用户提供的接入方式很可能是一个Web界面，或者REST API的接口，那么就会与传统Web服务器一样面临着被攻击的威胁。和传统服务一样，我们可以使用专门的硬件/软件防火墙以及负载均衡来处理对访问入口的 大量并发请求。技术架构可以参考相关书籍，在此不以赘述。

流量控制

私有云的流量限制条件比公有云宽松许多，但是仍要给予高度重视，否则同样会带来体验乃至安全性上的严重后果。平台入口以外的流量我们可以通过外部防 火墙进行处理，虚拟机内部的流量往往通过虚拟化平台的流量控制功能进行限制，有些时候也会引入内部防火墙。平台也要对架构中的异常流量有所感知，以通知相 关人员进行维护或者防护。

网络安全方面有很多成熟的方案或者产品，我们应根据它们的效能、管理复杂度、平台兼容性等进行综合选择，尽量减少引入私有云时带来的复杂度和成本。

存储介质

在此以常见的智能手机为例，用户保存在手机里的数据包括联系人、音视频、照片等，给手机屏幕解锁后，用户可以访问它们。当手机损坏并丢失后，某些心 怀不轨的人可能会dump出手机的flash内容，然后进行解读。为预防这种比较极端情况发生，现在的智能手机操作系统中都会有“加密存储”这个选项，当 用户选择进行加密存储后，对存储介质的非法直接访问也将变得异常困难。

上述的场景应用到私有云时，用户的数据即是虚拟机硬盘以及存储于“网盘”上的内容。

服务器操作系统中存储有虚拟硬盘，在这一层进行加密就意味着即使这台服务器硬盘被取出，也很难读取其中数据；KVM下的虚拟硬盘本身在创建时也支持 AES加密选项，但由于其稳定性欠佳已经被社区渐渐抛弃，截止成文时没有任何改进的措施出现；至于虚拟机OS内，它可以加密虚拟硬盘、数据、目录等等，但 是需要用户自己进行选择加密的内容。

数据加密解密的同时一定会带来性能上的些许影响，全部使用服务器OS加密硬盘一定不会适用于所有场景，同样强制用户虚拟机OS加密也不会太妥。当面向安全等级特别高的场景时，使用服务器加密一定是有益的，一般场景下我们提供虚拟机OS加密的建议即可。

服务器
我们现在也有很多措施可以专门用来加强服务器本身的安全性。以笔者经验来看，主要使用的有如下两方面技术：
可信平台模块：

可信平台模块（TPM，Trusted Platform Module）由计算机工业的可信计算组（TCG，Trusted Computing Group）制定，旨在提供计算机安全加密设备与技术，用来防止密码、敏感数据被窃取。

它是一个硬件模块，本身提供了各种加解密算法的快速计算，同时可以进行远程认证、数据加密/解密认证，主要应用场景如下：

• 平台认证：它可以从硬件设备、设备固件、BIOS到操作系统、软件都进行哈希校验，保证系统中没有未经许可的硬件或软件接入。比如接入一个未曾记录过的USB键盘时，它就会记录并按照预配置操作进行处理。

• 硬盘加密：服务器操作系统可以在其内部使用TPM协助进行硬盘加密，一般需要特定软件实现，比如dm-crypt、BitLocker等。

• 密码保护：用户的密码、密钥、数据、操作系统等都可以使用它来进行保护。传统软件实现的认证机制往往不能经受字典攻击，而TPM内置了防字典攻击机制，使得所有绕过软件限制的大量尝试登录操作被TPM终结。

目前在私有云中，主流的虚拟化都提供了对TPM的支持。KVM下除了TPM透传外，也可以使用模拟TPM设备进行加解密。
地理位置标签

使用地理位置标签（Geo-Tag）可以帮助管理人员了解服务器的具体位置，以方便管理维护。它可以配合RFID设备进行短距离细分标识，并且在统一管理平台的帮助下，实现所有设备状态、位置的实时监控。当然它也可以配合TPM组建基于地理位置的可信资源池。

"云"化架构

虚拟化只是“云”的实现工具。我们接下来讨论的内容就是如何将其“云”化。
池化资源

池化资源是向“云”迈进的重要一步，这一点我们可以通过社区动态以及商业云产品中窥探到。在前面的基础架构中，我们围绕着计算、存储、网络三个基本元素组建系统，而接下来就需要使用云平台将它们进行“池化”操作，从而提供更具有弹性、更加高效和稳定的的服务。

以服务器为基本载体的三种资源通过各种方式进行组合，提供IaaS、PaaS、DaaS、SaaS等模式的服务。这些服务模式展现给最终用户的有诸 如虚拟机、云存储、负载均衡、内容加速、App框架等具体产品。将资源进行池化的好处即是一方面用户不必知道所接受服务的具体来源，同时能够得到稳定、快 速的服务响应，另一方面服务提供商对资源也能进行合理的管理、分配和维护。

SLA管理

SLA（Service Level Agreement）即服务级别协议，它通过对资源的限制、置配、调度而保证服务的高可用。

高可用

高可用可以按照作用对象分为服务器、虚拟机以及虚拟机内应用程序。

在服务器层面，我们通过评分、隔离、电源管理等机制保证虚拟机运行在一个稳定的环境中。评分即通过监视服务器的资源当前及历史状态，对其进行综合评 价，分数越高具有运行虚拟机的权利。隔离操作一般发生在服务器与集群管理节点失去联系时，为保证服务质量而将其从服务集群中隔离不再运行虚拟机，一般配合 电源管理进行操作。

虚拟机层面的高可用往往需要对其添加模拟看门狗。看门狗是一种辅助芯片，在嵌入式系统中常用来监控CPU状态，当CPU停止工作后看门狗就不会再收到CPU发来的心跳信号而将CPU强制重启。对于PC而言，看门狗将系统重启的条件多是蓝屏、死机等。

对于虚拟机内的应用程序的高可用，可以通过外部监控（比如端口状态监测）和内部监控（比如虚拟机代理程序）完成。这方面的监控产品比较多，主流的有 Nagios/Icinga和Zabbix等，它们都需要在虚拟机内按照代理程序，当某一应用被监测到停止响应时，就可以使用管理员提前设置的策略尝试重 启此应用。

资源限制

资源限制即是对允许用户使用的最大资源进行限制，包括虚拟机数目、CPU、内存、磁盘、网络。这里的限制按照对象可以划分为两个方面，一是用户允许使用的总资源配额，二是虚拟机在运行时所允许的资源最大利用率.

比如在一个用户可以自己创建虚拟机的环境中，管理员往往难以控制其创建删除行为，如果能对用户创建的所有虚拟机数目、vCPU数目、内存大小、磁盘 大小、网络带宽进行配额限制的话，那就既能满足用户的自主性又可适当减少管理员负担了。这种限制有些类似操作系统中的配额限制，它主要体现在对“量”的限 制上.

但是对"量"的限制还不能满足私有云的需求，那么就要从“质”上进行限制了。如果用户拥有足够的服务资源配额，那么当他的虚拟机长期满负荷运行时（比如网络发包、磁盘高IOPS直写、CPU利用率高居不下等），就会对与其处在同一台服务器上的虚拟机造成比较严重的影响。为了其他用户的体验考虑，我 们引入了利用率的限制，包括CPU利用率（CPU数目与其利用率乘积）、磁盘利用率（读写IOPS、MBPS）、网络利用率（百分比）等.

当用户的资源将要超过配额或者较长时间内高利用率使用时，平台同样需要对其发出警告，防止其系统发生崩溃、恶意入侵等意外情况。

资源配置

资源置配往往是一个动态的过程，它通过一系列策略对虚拟机的CPU、内存使用进行控制，以期最有效地利用服务器资源。

当一个多核虚拟机运行时，它会有多个LWP（轻量级进程，可理解为线程）协同父进程运行。比如一个双路32核的服务器上运行一个单路32核的虚拟 机，往往就会有多于33个LWP在运行（数据与qemu-kvm版本有关，可用ps -eLf查看）。而这些LWP在未指定的情况下往往会在核之间漂移，然后由于进程同步和上下文切换对虚拟机性能造成比较大的损失，当使用率提高时也会对其 他进程产生比较严重的影响。为了解决这一类性能损失，我们引入p-vCPU绑定与NUMA机制，即是将vCPU置配到固定的pCPU上，同时也会利用 NUMA的CPU间共享内存通道增加多路多核虚拟机的效率。

另外我们还可对每个虚拟机vCPU进行优先级安排，较高优先级的vCPU拥有更多的CPU时间。这一特性由于其收益较小，在私有云中适合于极端优化场景。

对于内存的置配，我们同样可以利用KSM（Kernel SamePage Merging）配合内存气球技术提高内存使用效率并达到内存“超分”（over committing）的效果。从KSM可以看出其字面意思，即合并虚拟机所占用虚拟机的相同内存页以节约服务器内存占用。内存气球即假设虚拟机的实际占 用内存为气球体积，服务器总内存为装有许多气球的盒子，占用内存即为盒子中的空闲体积。当气球变小时，盒子空闲体积变大，就有更多的空间可以供给其他气球 及服务器使用，反之亦然。

资源调度

资源调度的过程按照虚拟机的生命周期可以划分为两部分，一是用户请求服务后服务资源后池中分配合适的资源提供服务，我们称之为启动策略；二是当提供的服务达到调度阈值后，为了服务的质量保证而进行的自动调度或者手工调度，我们称之为运行时策略。资源调度是考虑一个云平台质量的重要指标。为了实现私有云的资源调度策略，我们需要的操作通常有对虚拟机的迁移、开关机、挂起，以及对服务器的开关机、隔离，再结合定时、分级、排序、统计、反馈机制，套用到不同的场景中去。接下来我们从启动策略、运行时策略开始，讨论它们可能用到的机制和具体操作。

启动策略的实现或简单或复杂，目前在私有云中常用的有两种：

     快速启动：平台首先对服务器按照其所剩资源进行排序，比如第一个列表为所有服务器剩余内存从高到低的排序，第二个列表为所有服务器CPU剩余未分 配核数从高到低的排序。当虚拟机请求资源准备启动时，它从第一个列表中发现服务器甲、乙、丙满足其CPU核数要求，从第二个列表中发现服务器甲、丁满足其 内存要求，那么虚拟机就会在服务器甲上启动。类似这种快速启动策略实现起来比较容易，效果也能满足大多数场景。

     最优启动：同样地，平台也会对服务器进行排序，但是这次排序除了考虑剩余资源，也会考虑已用资源。当虚拟机请求资源准备启动时，平台根据剩余资源 选择一组可用的服务器，然后再计算出这个虚拟机在这些服务器上运行的话单个服务器的资源百分比是否超过预设阈值，然后它会选择一个资源百分比变化最小的服 务器上启动虚拟机。最优启动在实现时，往往会结合运行时策略进行调度，尽量减少虚拟机或者服务器的后期运行时调度。

注解

启动排队

在启动策略中为减少“启动风暴”的发生，我们往往会引入排队机制。每台服务器会根据其当时负载状况选择一定时间窗口内可 以允许多少台虚拟机启动，待这些虚拟机启动完成对磁盘和CPU的负载降低后后，再启动下一批虚拟机。在一个监控机制较完善的平台下，排队机制中的变量（队 列长度、窗口时间等）可以根据服务器状态进行动态调整。

运行时策略可以从很多角度进行设计，比如服务器利用率、电源能耗、用户负载等，常用的有如下两种：

      平均分布：平均分布即要求所有服务器上的负载（虚拟机数目、资源用度）尽量相同，对于负载过高的服务器就会迁移其上的某些虚拟机至其他负载较低的服务器。这样做的目的是降低局部负载，保持虚拟机所处环境的平等。

       低能耗：这种策略有两种实现，第一种要求所有虚拟机运行所占用的服务器数目尽可能少。它先将虚拟机从多台服务器上集中迁移到某些台服务器，然后再 将其他服务器关机以达到省电的目的。第二种则不要求服务器关机，但是会让闲置的虚拟机释放CPU、内存资源，它通过定期检测桌面连接或应用连接，挂起较长 时间无连接的虚拟机。在私有云桌面环境中，第二种实现应用比较广泛。

注解

虚拟机亲和组

虚拟机亲和组即是按虚拟机应用将其分组，同一组的虚拟机尽量在同一台服务器中运行或者往同一台服务器迁移。应用环境相似的虚拟机会有很多相同的内存页，那么将它们保持在同一台服务器上运行就会很大程度上地节约资源消耗。

总结

私有云的架构与传统IT架构一样，都是根据需求一步一步扩展。为了保证物理上难以的虚拟机维护的虚拟机稳定运行，我们要求资源的基础架构具有稳定 性、冗余性和扩展性。当资源延伸到虚拟机中使用以后，整个架构才开始变的即灵活又不易控制。此时需要我们采取安全防护措施，以让它在一个可控的环境中发 展。当它发展到一定成都后，我们赋予其“云”的属性，比如资源池化、SLA管理等。至此，我们的架构才开始走向正轨，经历更多意外、想到更多实用的点子， 然后变得更加成熟！