私有云基础架构设计:存储、网络、计算、安全和应用的设计最佳实践及案例

前两天看到网络某位大牛的一篇文章分析超融合市场，其中提到“超融合是从很大意义上将计算、存储、网络、安全等企业级IT基础设施有机融合在了一起，但不只是硬件架构上的融合。到目前为止，能完全有机融合这四大元素的公司似乎还没有出现，更多的还是如何将计算、存储、网络还有虚拟资源互相融合。”

在开始讨论私有云的架构之前我们首先确定一件事情，即没有架构是完美的，总是根据实际业务慢慢优化最终满足或者超越最初需求。

私有云客户与公有云客户最大的不同是——客户对私有的“云”在管理层面上拥有较大的权限，他（她）可以很放心地把有涉及到公司或者单位隐私的东西放进“云”中，出现意外时自己可以要求管理员随时处理。并且私有云就服务器规模、SLA、防火墙、计费、安全性等级要求等方面而言，与公有云的侧重点不大相同，架构上自然也要区别对待。

本章会从基本原则、架构安全、“云”化架构三个方面叙述基础架构的设计实现，涉及到的技术细节笔者尽量在后面的基础知识章节部分加以叙述。

1、基本架构原则

基础设施架构的核心即是整合计算、存储与网络三种资源，而在配置这些时我们需要在扩展性、稳定性及冗余性达到一定要求。

• 稳定性

基础架构的稳定性对于一个平台是至关重要的。存储、网络、计算节点自身的稳定性，以及它们之间通信的稳定性，都时时刻刻影响着用户体验。

即使是稳定性非常好的系统，也应该在平时的运维，即监控以及出现故障时的跟踪、定位、解决上花一定功夫。现在国内很多云平台厂商都没有提供服务状态报告，比如可用性、地域延迟、资源统计等，相比国外的主流平台而言仍有很大差距。

• 扩展性

扩展性包含两个方面：横向扩展（scale out/in）和纵向扩展(scale up/down)。

集群横向扩展主要包括计算节点、存储、网络资源“节点级别”的扩展，比如新添加了服务器、交换机等整机设备。需要注意的是，节点加入集群后，其上的所有业务均能在新节点正常运行；同时，新节点的加入对普通用户来说是透明的，即用户不会感知到集群的横向扩展。

纵向扩展即是整机中加入例如新的CPU、内存、硬盘、网卡等组件以提高单机性能。

平台在进行横向扩展时，也可使用其他平台的资源。比如企业内现有国际品牌的虚拟化产品，如果国内厂商的虚拟化产品能够直接使用原平台的虚拟机、虚拟硬盘甚至是虚拟网络的话，那么对企业来说，这个过渡将会非常轻松。现在能够提供云平台API的厂商比较多，而能够作为参考标准的只有Amazon、OpenStack、VMWare等国际化平台。笔者成文时，中国信息技术标准化组织目前尚未制定出“及时”的标准，但已经成立了很多的工作组，比如服务器虚拟化、桌面虚拟化、云存储等，相信他们也很快推出统一标准。

• 冗余性

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

1.1 合理的存储配置

私有云中存储配置是整个架构的重点，它承担着整个平台的数据，所以这里一般需要进行重点配置。除了传统存储架构外，也有厂商Nutanix为首提出的超融合架构，即存储与网络一样也可以进行软件定义。目前对多数国内私有云厂商来说，超融合的一般实现即是在虚拟化平台中添加分布式存储的后端与前端管理，可对计算节点资源进行复用，从而降低项目整体成本。

不管何种形式，它们对平台的提供的功能都是相同的，接下来笔者针对私有云平台的存储基础架构予以介绍，相关的存储知识读者可以阅读本书的第7章。

• 接入方式

私有云中的存储配置按照接入平台的方式可分为本地存储和共享存储，而它们本身的组合方式又是自由的，除传统的本地存储和网络存储外，也有NFS存储可以挂载后作为计算节点的本地存储，或者计算节点上的空闲空间组合为分布式存储等方法。图2-1和图2-2分别是本地存储与共享存储的接入方式示例，本地存储即直接使用本地磁盘或者iSCSI、SAS等设备作为镜像存储，虚拟机实例与镜像在同一主机中，而共享存储下虚拟机实例可在任意主机中打开镜像并运行，从而使得虚拟机热迁移成为可能。

图2-1 本地存储接入示例

图2-2共享存储接入示例

图2-1中有本地硬盘、共享存储/FC/SCSI存储作为本地存储的两种用例；图2-2中节点1直接使用外部存储作为共享存储，节点2和3提供本地硬盘作为Ceph/Glusterfs的存储后端，再使用Ceph/Glusterfs作为共享存储。存储的接入方式对平台性能、稳定性甚至使用体验上都有直接或间接的影响。

当使用共享存储时：

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

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

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

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

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

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

• 可以利用网络缓存机制，减轻启动风暴影响，但对共享存储设备有一定要求；

当使用本地存储时：

• 虚拟机更加独立，某个用户的过度使用不会造成其它虚拟机的读写性能影响，增强用户体验；

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

• 存储成本投入较小；

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

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

我们选择接入方式时需要综合考虑业务类型、成本、用户体验、风险控制等等各方面因素，尽量避免对整个平台的稳定性和性能造成负面影响。

• 存储后端

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

图2-3 存储节点物理示意图

多数项目方案中既有高速存储设备，又有相对低速的存储设备，我们要根据“业务”来规划存储使用。接下来我们做一次实验，用数据简单说明虚拟机硬盘格式与物理存储的相互影响，其中我们使用一块SSD代表性能较高的高速存储，一块SAS硬盘代表相对低速存储，这里的“业务”是启动链接克隆方式创建的虚拟机并进入桌面。

“完整克隆”与“链接克隆”

在KVM虚拟化平台中，有两种创建实例的常用方式：完整克隆与链接（增量）克隆，在以后章节中会有详细介绍。

完整克隆即完全复制模板配置信息与硬盘文件，硬盘的复制方式一般为cp或者qemu-img convert。如此创建的实例，其硬盘与模板硬盘相对独立，在服务器存储上拥有各自的扇区位置，所以在读写操作时受机械盘磁头引起的小区域并发问题影响 较小，缺点是创建时需要花费一定时间，不能满足秒级创建的需求。

链接克隆即新建虚拟机时只复制模板配置信息，硬盘文件则是以原硬盘为模板的增量硬盘。如此创建的硬盘对模板硬盘的依赖程度较高，对于硬盘内已有文件的读操作（比如启动系统时）绝大部分在模板硬盘上进行，所以在传统机械盘上多个实例的并发启动风暴更容易在此种格式的硬盘上发生。

本次实验环境中，笔者使用一台双路E5-2630v3、128G内存的服务器，两块企业级SSD（其中一块为服务器系统，另一块虚拟机存储）和一块企业级SAS硬盘（虚拟机存储），将1G内存、单核、全新安装的XP虚拟机作为模板。为了防止虚拟机进入系统后进行文件索引等占用空间的操作，模板虚拟机建立之前开机“静置”了一段时间直到其资源用度无明显变化。

• 企业级1T SAS硬盘虚拟机批量启动实验

此时新建的实例所和模板都位于SAS硬盘上。同时启动20台虚拟机后，全部虚拟机在第300秒左右进入桌面。启动20台虚拟机过程中的服务器CPU及I/O用度如图2-4所示。

图2-4 于SATA硬盘中启动20台虚拟机的CPU及I/O用度

• 企业级480G SSD虚拟机批量启动实验

此时新建的实例和模板都位于SSD上。同时启动20台虚拟机后，全部虚拟机在第35秒左右进入桌面。启动20台虚拟机过程中的服务器CPU及I/O用度如图2-5所示。

图2-5 于SSD中启动20台虚拟机的CPU及I/O用度

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

1.2 稳定的网络基础

一个优秀的IT架构一定有一个优秀的网络基础。网络在私有云尤其是桌面云中的影响有时比存储更加直接。在搭建私有云的过程中，更多的项目是在已有 IT架构的基础上进行延展，而不是厂商独立的架构，所以对整个用户端网络框架有个清晰认识就显得很重要。在我们接触的项目中，有比较多的问题是网络不稳定、框架不合理造成的。虽然我们在项目中极少拥有对用户网络改造的权力，但是也要在网络上下功夫认真规划，并在关键结点与客户及时沟通，尽量减少网络因素带来的诸多“麻烦事”。

图2-6是以业务为核心的通用私有云架构，图2-7则是从计算节点出发网络视图，它们的共同点都是对网络进行了较为严格的区分，但划分标准不同，读者在很多云平台中都会看到类似架构。其中会涉及到虚拟化网络基础与软件定义网络（SDN）等知识点，具体内容读者可阅读本书的第6章。

图2-6 业务为核心的通用架构

图2-7 计算节点为中心的网络架构

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

图2-8 OSI模型与TCP/IP模型

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

图2-9 OSI与TCP/IP混合模型

同存储资源一样，我们在构建私有云网络基础的时候也要关注其稳定、扩展、冗余的能力，同时注意成本，以下笔者将从这5层分别进行介绍。

• 物理层

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

表2-1 网络线材分类

分类	光纤	万兆铜缆	千/百兆双绞线
最大带宽	100Mb-100Gb	10Gb	100Mb-1Gb
能量衰减	极低	低	中
最大长度	300m-40km	100m	100m
成本估算	中-高	中-高	低

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

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

• 数据链路层与网络层

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

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

图2-10 星型＋环形网络拓扑

其中有几点需要注意：

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

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

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

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

• Bonding（链路聚合）是比较常用的增加冗余和带宽的措施，但要注意交换机关于bonding负载均衡的策略，防止bonding无实际效果，比如IP、MAC、TCP Port的组合方式；

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

• 传输层与应用层

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

其中，从用户端到云平台需要保持良好通信的有http(s)、spice/vnc等，服务器之间则有ssh、sql、telnet、smtp、pop等之间影响业务等应用层协议。

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

在设计时我们需要注意以下几点：

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

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

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

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

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

1.3 可靠的计算资源

提供考量计算资源的标准，不止于物理服务器的性能、安全、稳定等因素，还有计算节点组成的集群所具有的能力，比如负载均衡、高可用等。接下来，笔者将根据硬件、软件配置并结合私有云的特性进行计算资源服务器的选择，以其达到最优的计算资源配置。

• 服务器硬件

图2-11 PC服务器一般架构

通常情况下，CPU、内存是决定服务器能够承担多少负载的决定性因素，而存储、NUMA和扩展属性保证着服务器运行的功能性和稳定性。

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

其中，sockets、cores、frequency分别代表服务器的物理CPU数量、单CPU线程数、最大主频，当超线程HT打开（为真）时获得20%的提升，否则不提升，cap代表服务器的能力。读者可以访问Intel ARK网站（或手机APP）查询具体的CPU参数。

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

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

内存技术也是影响虚拟机的重要因素，目前在KVM中可以使用内存气球、巨页、KSM等技术提高内存使用效率。虽然内存可以超分（overcommit），但我们仍然要保证物理内存不小于所有虚拟机分配内存，因为内存不足导致的问题一般比较严重，对于服务器来说甚然。另外，当内存充足时建议关闭swap分区，因为在数据拷贝期间发生交换将带来比较严重的性能损失。

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

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

• 操作系统

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

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

稳定性是考量系统的重要标准之一，影响它的因素或是系统本身，或是软件，或是硬件。一般私有云厂商在进行实施之前，如有可能会对服务器进行连续中低压测试，确保其稳定性后再进行软件的部署。而服务器硬件兼容性问题伴随着硬件厂商和操作系统厂商（尤其RedHat）的紧密合作，它的出现情况已经比较少了。但是一旦出现兼容性问题，一般都比较难以排查，往往需要硬件厂商提供协助。

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

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

操作系统的选择

目前主流云平台多基于CentOS/RHEL或者Ubuntu系统。其主要原因就是其生命周期与知识库——CentOS每个大版本是10年左右，Ubuntu/Debian为5年，SUSE为10+3年（期限虽长但对应云平台知识库较少）。当然，影响我们对服务器选择的因素中，软件也占据大部分，比如下图就是虚拟化相关软件的通用架构，其中哪部分使用或高或低配置的服务器甚至虚拟机作服务器还是要调研一番更为妥当。

• 软件服务

在分布式架构中，不同的软件服务一般部署在不同的服务器上，这样就会使单独的软件服务模块更具可维护性和部分性能上的优势。以IaaS为例，常用的软件服务模块如图2-12所示。

图2-12 开源云平台虚拟化相关功能软件架构

其中，我们重点考虑的软件模块是模拟器部分（关于开源的x86模拟器QEMU读者可以参考第4章内容）。

首先，模拟器会对计算节点的CPU特征有一定要求。以虚拟机迁移为例，现在的虚拟化实现不能进行异构迁移，即虚拟机vCPU不能在迁移后改变其CPU特征，这就要求集群中的计算节点使用统一的CPU特征组启动模拟器，并且所有计算节点的的CPU至少属于同一架构。其次，模拟器会对计算节点的CPU性能有一定要求。私有云中常常会有重点业务虚拟机，它们对CPU性能、内存等计算资源有较高要求，此时我们就需要赋予较高资源优先级，保证它们在资源充裕且状态良好的计算节点上运行。然后，如果虚拟机需要使用常驻的外部设备，那么我们就需要进行设备透传或重定向。而现有的模拟器实现不能在设备已与虚拟机连接的情况下进行迁移，这就只能将此虚拟机在固定的计算节点上运行，从而要求此计算节点需要拥有数量合适的外部设备或接口。最后，某些模拟器的性能会受主板设置的影响，比如CPU电源管理，这就要求计算节点需要针对具体的模拟器类型作出相应设置，保证模拟器性能最优。

需要注意的是集群中的网络组件，以Neutron为例，其OVS节点在网络数据包较多的情况下，会对本地CPU造成不小的压力从而引起网络丢包、延迟现象，而针对这点常用的做法是使用单独的网络控制节点和SDN交换机以分离控制层与数据层，从而保障网络性能的稳定。

至于容器，它运行在Linux服务器中时一般不会对CPU有特殊要求，只要保证核数与主频合适即可。而集群组件，比如Nova、Glance、vdsm等，它们对计算资源要求也比较少。

2.、架构安全

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

图2-13 私有云环境用户接入简图

2.1 认证与授权

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

在传统认证授权系统中，普遍使用AD、LDAP等作为网络信息服务器（NIS），前者是类Kerberos的实现，后者可直接与Kerberos进行结合。私有云需要这种NIS访问方式，以便接入现有业务系统或者启用单点登录（Single Sign On）。Kerberos的认证流程如图2-14所示，其核心是ticket的获取与授权。

图2-14 Kerberos认证过程

可以看到用户与服务的认证授权过程很清晰，实现时注意需要用户/服务端/KDC（相当于AD域控）三者时钟同步。当用户进行登录以后，他使用任何应用都不再需要再次输入密码认证，应用程序通过用户第一次获取的key向服务请求对应的权限，并且所有权限都可以进行细分管理。

虽然Kerberos性能、安全性方面都很优秀，但与应用结合时仍需考虑它引入的运维复杂度问题，尤其是在扩展性方面。

2.2 服务安全

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

• 网络安全

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

• 加密传输

在私有云平台中，所有服务的TCP/IP连接都可以选择性地使用SSL/TSL进行加密。而在进行SSL/TSL加密传输时，有两点需要注意：确保至少有一个可信的根证书颁发机构颁发的根证书，对于小规模私有云来说，可以使用二级可信证书或者自建可信域；谨慎管理私钥及其备份，防止外泄。

• 防DDoS/CC/SQL注入

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

• 流量控制

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

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

• 存储介质加密

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

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

图2-15 用户数据加密主体

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

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

服务器设备

我们现在也有很多措施可以专门用来加强服务器本身的安全性，不妨尝试从以下两方面入手：

• 可信平台模块

可信平台模块（TPM，Trusted Platform Module）由计算机工业的可信计算组（TCG，Trusted Computing Group）制定，旨在提供计算机安全加密设备与技术，用来防止密码、敏感数据被窃取的标准设备。下图为某厂商的TPM模块，附加于专用的主板I/O接口。

图2-16 某厂家的TPM模块

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

• 平台认证

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

• 硬盘加密

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

• 密码保护

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

目前在私有云中，主流虚拟化平台都提供了对TPM的支持。QEMU中除了TPM透传外，也可以使用QEMU模拟出TPM设备进行加解密。

• 地理位置标签

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

3、“云”化架构

由第一章私有云的定义我们可知，虚拟化只是“云”的实现手段之一，而面对真正的云我们仍需要很多工作。我们接下来讨论的内容就是如何将基础架构“云”化。

3.1 池化资源

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

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

图2-17 典型“云”服务模型

3.2 SLA管理

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

• 高可用

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

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

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

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

• 资源限制

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

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

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

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

读者可能会在很多地方读到关于将PaaS平台搭建在IaaS平台上的资料，但是我们需要了解这样做的原因主要是考虑到了资源的隔离控制，而不是资源用度方面，所以其高可用性较之以物理机直接接驳容器工具方式有一定劣势。

• 资源配置

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

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

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

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

图2-18 KSM原理

图2-19 内存气球技术

• 资源调度

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

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

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

图2-20 快速启动示意图

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

图2-21 最优启动示意图

启动排队

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

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

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

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

虚拟机亲和组

虚拟机亲和组即是按虚拟机应用或者关系将其分组，同一组的虚拟机尽量在同一台服务器中运行或者往同一台服务器迁移。应用 环境相似的虚拟机会有很多相同的内存页，那么将它们保持在同一台服务器上运行就会很大程度上地节约资源消耗。集群架构的业务虚拟机有时也需要在同一亲和组 中，比如负载均衡的Web服务器、分布式计算服务器等。

• 弹性伸缩

弹性伸缩是“云”化的重点之一，主要功能是在基础设施资源固定的情况下，平台可根据用户应用程序的需求对其在用资源进行自动扩充或回收，其实现包括Amazon简单/分步扩展策略、阿里云的弹性伸缩服务等，但这不代表它仅适用于公有云。一般来说，三大主要资源都可以进行弹性伸缩，但它们落实到具体对象上时则主要以虚拟机实例（或者vCPU）数量、容器实例数量、网络质量、存储读写质量等为单位（vCPU、内存热插拔方式的伸缩目前由于操作系统支持受限，所以应用极少），可应用的场景主要有Web服务、分布式计算、存储服务等依托LB（Load Balance，负载均衡）与HA的集群服务（关于LB/HA的技术选型可参考第10章相关内容）。

以应用较多的Web服务为例，它的典型实现示意图如图2-22所示。

图2-22 典型Web集群服务实现示意图

当Web服务网关收到请求以后，它会从LB集群中选择一个Web服务器响应服务，此Web服务器将与HA的数据库服务交互以后再返回信息给用户。如果用户请求过多，每个Web服务器的资源用度超过上限阈值一定时间时，平台就需要新建一台Web服务器并将其注册到LB集群中，如此以来新的请求便会被引导至新加入的Web服务器上，从而使得集群服务处理能力得以提高；反之，当多数服务器的资源用度低于下限阈值超过一定时间时，平台则会从LB集群中移除一台Web服务器以节省资源占用。

这个过程中的资源用度检测、阈值设定、Web服务器数量变化、LB服务器的注册与注销，即是由弹性伸缩服务所提供。

完善的弹性伸缩系统对于监测准确度、阈值选择与设定、阈强度（即高于或低于阈值的持续时间）、响应时间（即伸缩条件被触发后，Web服务器创建/移除、注册/注销过程消耗的总时间）、可伸缩集群类型（Web服务、数据库服务等）、防火墙（有效阻挡攻击流量）等方面都有一定要求。以阈值选择与设定为例，在实现是多以服务器即时并发量、资源消耗等综合考量，如果我们仅仅将指标设置为CPU用度，且阈值设置不合理的话，就可能发生如下现象：已知单位时间内用户请求数一定，那么当一个已经扩展的LB集群整体资源用度低于缩减阈值时，则其中一台Web服务器会被移除，用户请求被单台服务器全部接收导致其CPU利用率上升，如果此时扩展阈值过小系统则会再次向LB集群中添加一台服务器使得CPU利用率再次下降，最后重复前面的步骤导致震荡发生，如图2-23。

图2-23 典型Web集群服务实现示意图

如果读者对此部分设计有兴趣可适当阅读自动化相关书籍，比如《线性系统理论》、《现代控制系统》、《自动控制原理》等，虽然是面向电子电气专业人员，但对IT从业者也颇具参考价值。

4、OpenStack基础架构设计示例

基础架构模型是需要根据业务模型设计的，接下来笔者以OpenStack基础架构为例，首先介绍适用性较广的通用型设计，然后以其为基础拓展至计算或存储密集型的设计。

另外，在部署工具的选择上，笔者推荐初学者使用Mirantis Fuel或RedHat RDO部署OpenStack，它们都使用了自动化部署工具——Puppet，前者相对后者拥有友好的Web界面，所以用户相对较多，在国内也有分支合资公司。

• 通用型设计

通用型设计即是指用户需求不太明显的情况，我们提供给用户适用性较广的架构以满足其潜在需求。比如用户在内网运行Web服务器但不知何时会面向公网，或者用户是为了某个项目进行实验等等。这种设计所需要的OpenStack组件中，我们对用户的潜在需求进行分析，然后选择安装尽可能多的组件。

• 存储考虑

提供的存储服务主要包括块存储与对象存储两部分。

块存储服务是整个架构的基础，一般会直接部署Cinder管理块存储服务，其后端有很多商业存储可供选择，同时OpenStack也提供了针对商业存储的插件。如果没有单独的存储设备则考虑在各个服务器上部署多副本的CephFS集群，但服务器上除系统盘外也要有额外的硬盘组RAID 5或6。如果用户希望虚拟桌面的操作更流畅，或者他们需要频繁地创建、删除虚拟机，可考虑划分单独的SSD存储池用于虚拟机镜像存储（Nova、Glance）。如果服务器仅仅用作提供存储服务，从笔者经验来说采用高主频、少核的CPU时性价比较高。

而使用对象存储的目的有两个，一是存储部分虚拟机模板镜像，二是让用户将其作为网盘使用。存储模板镜像时，对象存储架构比较简单，Swift控制节点也可放入主控制器中；当作网盘使用时，那么Swift网关服务器就相当于一个Web服务器，且用户会话时间较长，此时如果并发有一定数量但未具备相当规模时，一般只需加强网关服务器硬件与优化系统配置即可，如果要针对较大规模并发，则需要更改其架构，比如添加单独的负载均衡设备或者组成高可用集群。

• 网络考虑

在设计基础网络时，一般会针对不同的网络功能区域进行单独设计。

OpenStack目前提供nova-network与neutron两种网络后端，但前者在最近的版本中已被标记为“deprecated（抛弃）”，所以笔者推荐使用neutron以提高系统向后兼容性与扩展性。

通用型设计中，网络一般划分为公共网络、用户网络、管理网络、存储网络等。公共网络即是用于对外服务的网络，这些服务主要用于用户访问（Web、REST API、Spice），连接到这些网络的节点只有Controller、Swift网关、桌面协议代理网关等，同时LB集群节点也会使用此网络。用户网络即是用户的虚拟机或容器实例使用的内部网络，其IP地址位于“虚拟网段”中，或者是与物理交换机相连的“物理网段”中，一些在公共网络中的服务也可在此网络中以提高内部实例访问服务的速度。管理网络即是管理硬件资源时使用的网络，管理员使用工具添加新节点时会赋予其管理网络所在网段的IP。存储网络即是存储节点所使用的网络，它对网络硬件的要求较高，包括带宽、延迟、冗余性等方面。

• 计算考虑

通常，计算节点所组成的集群按照其逻辑功能或位置划分为多个计算池，且每个池中的资源总量都由管理员定义，比如常驻桌面池、浮动桌面池、研发服务器池、办公服务器池等。考虑到虚拟机实例的可迁移性，同一池中的服务器CPU配置（主频适中、多核）都是相同的，同时服务器都与需接入对应功能区域的网络。

虚拟化的基本特性之一是资源超分，即分配给虚拟机的资源可以超过所在计算节点实际资源，CPU资源、内存资源在OpenStack中的比例默认为16:1、1.5:1。这些比例并不一定适用于实际环境，比如当CPU超分过多时，会导致部分虚拟机因QEMU进程上下文切换成本过高而变得卡顿，当内存超分过多时，如果虚拟机实例实际占用的内存超过hypervisor的物理内存，则有可能发生交换（swap out）动作同样导致部分虚拟机性能下降。

与计算节点紧密相关的控制节点硬件配置一般不需要很高，可参考存储网关节点配置。

• 架构示例

如图2-23是以提供Web服务虚拟机为主和对象存储为辅服务的OpenStack架构。

存储服务由单独的存储服务器集群提供，包括用于计算节点的块存储服务Cinder以及用于云存储的对象存储服务Swift。

网络部分的划分笔者并没有在图中标注，但整体可进行如下划分：外部业务网络包括防火墙、控制器、Swift网关、负载均衡网关（虚拟机），服务器网络包括控制器、Nova计算集群，存储网络包括CephFS存储集群、Nova计算集群、Swift存储网关，虚拟机网络则专门用于虚拟机。

计算服务池分为研发和业务，前者用于研发人员开发、测试、代码/项目管理等，后者则用于运行已经上线的Web服务。由虚拟机组成的Web服务集群接收来自负载均衡设备分发的请求，再选择Web服务器予以响应。图中的负载均衡网关是在虚拟机内以软件形式提供的，它和Web服务器集群的架构与传统架构相同，因为管理员对后者更为熟悉。而高可用的控制器则保证了所有OpenStack组件控制组件的稳定性。由于用户需求中对象存储仅仅作为可选存在，所以此设计并没有添加单独的Swift存储网关负载均衡措施。

图2-23 提供Web服务虚拟机、对象存储服务为主的OpenStack架构示例

• 计算密集型设计

如果用户的应用是在高性能计算（HPC）、网格计算（GRID）、图文索引等非常依赖CPU性能的环境中时，我们可以对通用型稍作修改以完成应用计算密集型设计，而这其中又可以分别选择Nova或者Magnum提供虚拟机实例或容器实例，以隔离计算资源分别进行计算作业，从而构建出多租户环境的PaaS平台。

计算密集型的设计中，我们会尽量缩短I/O路径以减少数据搬迁带来的时间成本，且由于虚拟机实例或容器实例很少有高可用需求，所以采用本地存储将直接用于存放Nova虚拟机实例镜像与应用程序需要的文件系统，比如HDFS。此时，网络划分相对来说简单一些，但是计算节点则需要拥有独立的数据盘，采用OpenStack 基础设施的Hadoop集群架构如图2-24所示，其中控制节点可选装OpenStack大数据项目Sahara。

这种架构虽然牺牲了虚拟机的迁移特性，但同时正因为这点我们便可以在Nova节点添加物理显卡并透传至虚拟机中，从而提高特定行业领域的分布式计算性能。

图2-24 以OpenStack虚拟机作为基础设施的Hadoop集群

由于虚拟化的性能较之物理机有轻微损失，所以有人考虑使用性能几乎等同于物理机的容器运行分布式计算应用。笔者成文时原生Kubernetes、Docker Swarm、Mesos/Marathon组建的Docker集群并没有多租户功能，而出现稍晚的OpenStack容器服务Magnum则可将Swarm与Kubernetes作为容器集群后端，可同时利用Nova或者Heat提供容器模板，加之其原生的多租户支持而越来越受人关注。其架构可参考图2-25，其中使用Kubernetes作为容器集群服务，两个计算池分别用Nova和Heat提供的容器实例以适应不同的应用场景，其网络同样由Kubernetes提供，存储部分可参考上图。

图2-25 OpenStack Magnum参考架构

• 存储密集型设计

存储密集型的设计一般可将其理解为用于提供对外存储服务的基础架构，相当于一个独立的存储设备，其中的Nova上的虚拟机仅用作高可用存储管理服务与负载均衡的Swift存储网关，如图2-26所示。

图2-26 存储密集型OpenStack架构

这个架构主要参考了一些存储厂商的软件设计，所有对外暴露的存储服务都由管理入口进行控制，包括RBD、共享文件系统、对象存储以及基于它们二次构建的NFS、iSCSI、CIFS等。其中计算节点性能较弱，仅运行一些功能单一的虚拟机，厂商的实现中甚至将包括控制器、管理入口在内的服务直接部署至存储节点。

5、总结

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

案例探讨：

融合计算、存储、网络和安全于一身的公司还未出现？看EMC技术大牛如何回应 https://www.sohu.com/a/192561815_262201