本文遵循「知识共享许可协议 CC-BY-NC-SA 4.0 International」，未经作者书面许可，不允许用于商业用途的转载、分发、和演绎。

在本部分，我们探讨当传统IT建设和云计算的浪潮相遇的时候，作为互联网企业究竟应该如何抉择，是顺势而为投入云计算的怀抱，还是坚持基础设施自建，精耕细作。其实这两者并不矛盾，在我们的实践过程中，一方面，在私有云建设方面持续投入，不断提高技术、人才储备，实现资源的最优利用以及自动化程度的持续提升；另一方面，从“轻资产”的思路出发，在公有云服务逐渐普及、单位成本持续下降的情况下，按照业务的特点类型，将适合的业务迁移至公有云，提升业务稳定性，减少成本支出。

在展开详细内容之前，我们先来一起看看传统的IT建设方式是什么样子的。我们用一个应用场景来说明：在企业内部，或多或少地需要一些基础设施资源，包括计算资源、存储资源和网络资源等。传统的做法是组建一个系统团队，经过服务器选型、服务器采购、数据中心选择、服务器上架、网络建设等一系列过程，才能完成资源的交付。整个过程比较长，而且需要较多的人力。对于一个初创公司或者中小型企业来说，基础设施资源建设是个必需但不太划算的投入，本来公司规模小、人不多，公司内部的人员应该更加专注于自己的业务，基础设施资源建设不应该耗费公司较多的人力和物力。

和传统IT建设方式不同，IaaS（Infrastructure as a Service）作为一种新型的基础设施资源的获取方式产生了，即把服务器的基础资源作为一种服务形式，通过互联网提供给大家租赁获取。假设企业打算架设自己的服务，原来需要买一堆服务器、网络带宽等，现在完全可以通过IaaS服务商租赁虚拟机，而且这些虚拟机所需要的存储资源和网络资源是可以随时按需调配的，这样可以节省大量的人力、物力。一般的IaaS厂商会比单个企业在服务器规模上更大，在资源管理方面也会更加专业，因此，无论是服务质量还是投入成本都比企业自建更加优化。

一般来说，IaaS服务可以分为公共的IaaS和私有的IaaS。公共的IaaS又称公有云，规模大，服务比较全面，通过租赁的方式提供给公众使用，像AWS、金山云、阿里云和腾讯云等都是比较著名的IaaS服务提供商。私有的IaaS又称私有云，在公司内部组建，把服务器资源做成服务，提供给公司内部各个部门使用，极大地提高了资源分配的灵活性，缩短了资源交付周期，相比公有云来说安全可控性更高。IaaS服务既能有效地提高资源利用率，又能减少服务提供成本。由于私有云在企业内部的建设更有价值一些，后面我们将重点讨论私有云的建设过程，以及在使用过程中遇到的问题和解决方法。

IaaS平台选择

前面介绍了什么是IaaS，这里我们讨论一下IaaS的形式之一——私有云的建设过程。最近几年，私有云建设受到了国内外很多公司的关注和参与，阿里、腾讯、百度等都纷纷建立起自己的私有云平台。建立的方式主要有两种：一种是以开源的虚拟机计算平台为基础，开发自己的云计算管理分配平台；另一种是完全采用开源云技术方案，如OpenStack等来设计自己的私有云平台。这两种方式各有优缺点，第一种方式采用自主开发，可控性好，对代码和功能能够完全掌控，问题追查也比较方便，但是开发周期长，搭建速度慢，很难在短时间内实现一套完整的私有云平台；第二种方式采用开源云技术方案，能在短时间内搭建起一套完整的私有云平台，但是需要完全熟悉和掌握你所使用的那套开源软件，有一定的学习成本，随着开源软件越来越复杂，对平台的掌控有时也会力不从心。具体采用哪种方式，主要看公司的规模和对私有云人力的投入。大公司由于人力充足，对私有云定制的需求较多，对平台的掌控性要求较高，所以完全可以自己开发。而小公司由于仅想使用私有云来方便自己的资源管理和分配，也不需要对私有云进行太多的定制，所以选择开源的私有云方案是一个很不错的选择。后续内容主要探讨开源私有云方案的选择和架设过程。

OpenStack

OpenStack是一个非常流行的开源云计算平台，以Apache许可证授权，提供计算资源、存储资源和网络资源的分配与管理，是AWS服务的一个开源解决方案。最早是由美国国家航空航天局和RackSpace联合发起的，目前由OpenStack基金会管理和维护，已经有AT&T、Dell、Intel、RedHat等200多个公司参与该项目。

OpenStack发展更新速度很快，从发起到现在，一直维持着半年一个版本的发布周期，在产品的规划周期里会定时举行峰会以确定开发需求和方向。操作系统对OpenStack的支持也非常紧密，目前Ubuntu和RedHat对OpenStack都有良好的支持。OpenStack是由Python编写的，不同的功能被划分成不同的模块，模块与模块之间采用松散耦合的方式，使用队列进行异步通信。OpenStack功能非常完整，社区非常活跃，支持参与的厂商较多，这些都是它的优点。但是缺点也是非常明显的，如学习成本较高和稳定性欠佳等。

OpenNebula

OpenNebula起源于2005年的一个研究性项目，2008年3月发布第一版，目前已经发展成一个流行的开源云软件，得到了广大用户的参与支持。OpenNebula的目标是将一群实体集群转换为弹性的虚拟基础设备，且可动态调适服务器工作负载的改变，OpenNebula作为在服务器设备和应用之间新的虚拟层，使得服务器的使用效率能够极大地优化。目前OpenNebula可支持Xen和KVM，更重要的是还支持EC2管理。OpenNebula可以构建私有云、公有云，同时还提供Deltacloud适配器与Amazon EC2相配合来管理混合云。OpenNebula由于起源比较早，同时由于项目更加偏向于学术研究，因此OpenNebula有很多创新功能，其中有很多已经应用到生产实践中了。鉴于其项目性质的特点，其稳定性方面稍差一些，企业和社区的支持力度也较小。

CloudStack

CloudStack始于Cloud.com，其目标是使服务供应商和企业创建运营能力类似于亚马逊公司的公有云、私有云。2010年，Cloud.com提供了基于GPLv3的社区版本，供用户免费下载，并随后发布了两个支持版本。思杰（Citrix）公司在2011年7月收购了Cloud.com。思杰公司是OpenStack社区早期成员之一，但在2012年决定离开OpenStack社区。据媒体报道，做出这一决定是因为思杰公司认为，最初由Cloud.com提供的代码相比OpenStack更稳定，可为用户提供更多的功能。

CloudStack是一个开源的具有高可用性及扩展性的云计算平台，支持管理大部分主流的Hypervisor，如KVM、VMware、Oracle VM、Xen等。同时CloudStack是一个开源云计算解决方案，可以加速高伸缩性的公共云和私有云（IaaS）的部署、管理、配置。使用CloudStack作为基础，数据中心运营商可以快速、轻松地提供云存储服务和弹性云计算服务。CloudStack采用Java编写，在设计思想上更加趋向于简单稳定。但在使用者和社区支持度上，都比OpenStack差了不少。

IaaS开源软件选择

上面介绍了三种IaaS平台，它们各有自己的优缺点，如图1所示是三者近年来的Google趋势图，其中蓝线表示OpenStack，红线表示CloudStack，黄线表示OpenNebula。从趋势上看，OpenNebula起源最早，但是关注度一直不高；CloudStack从2012年开始，已经超过了OpenNebula，位居第二；OpenStack从诞生之日开始，就非常火爆，目前稳居第一。

三种IaaS平台我们已经介绍完了，该是做决定的时候了。对于开源软件的选择，我们认为应该遵循以下几个原则。

• 功能完备性：所需功能必须完整，这是选择的前提。
• 系统稳定性：由于服务对系统的稳定性要求较高，任何不稳定的软件将会给后续维护带来非常大的困难。
• 使用广泛性：相信大家的眼光，和别人相同的选择至少不吃亏。
• 社区支持度：具备良好的社区支持度，即使出现问题，也很容易通过社区的力量解决。

图1 IaaS软件对比趋势图

从以上几点来看，OpenStack是这几个候选者中综合指标最好的一个，因此，采用OpenStack搭建IaaS平台是一个较好的选择。后续将以OpenStack为基础，详细介绍IaaS平台的搭建过程。

IaaS平台建设

前面我们已经介绍过选择使用OpenStack建设IaaS平台。在使用OpenStack建设IaaS平台时，首先需要明确我们的需求。我们为公司建设IaaS平台，主要是满足公司内部的服务器虚拟资源的使用，作为私有云平台。通过对公司的私有云平台的需求进行收集，总结起来包括如下几点。

• 提供弹性的、高效的计算资源池，缩短机器的交付周期。
• 提高稳定的、高可用性的服务，支持公司线上和线下业务。
• 在网络连接上与现有业务无缝衔接，在使用体验上与物理机无明显差异。
• 虚拟机生命周期有效管理，虚拟机资产有效管理。

以上这4点需求，是大多数企业建设云平台的首要需求。第一点需求是云平台自有的特点，无须特别关注；第二点是提供高可用性的服务，鉴于OpenStack目前的稳定性，提供一个企业级高可用性的服务还需要做很多事情；第三点主要体现在网络方面，要求私有云网络和现有的业务网络高效互通，此外，在性能方面不能和物理机有太大差异；第四点主要是和现有业务系统和管理系统的对接，这和每个企业的资产管理系统相关，这里不多叙述了。下面我们就针对以上需求，了解整个私有云环境的建设过程。

架构设计

在私有云建设过程中，OpenStack的架构设计是非常重要的一部分。由于OpenStack的组件相当多，搭建起来会有不同的架构。考虑到之前收集的需求，高可用性是比较重要的需求，因此需要设计成一个高可用性的架构。由OpenStack提供的私有云服务，主要分为计算、存储、网络、管理4种资源，对每一种资源我们都要评估其高可用性。

计算资源主要由KVM、Xen等虚拟机提供。虚拟机技术已经在业界使用了很多年，属于比较成熟的方案，稳定性也已经不是问题。

存储资源分为两种：本地磁盘和共享存储。本地磁盘的稳定性由硬件的稳定性保证，一般来说，本地磁盘如RAID等已经能够满足大部分应用的稳定性需求。若应用需要更高的稳定性，可以考虑使用共享存储。OpenStack的共享存储主要分为GlusterFS和Ceph两种，都能保证数据的高可用性。GlusterFS和Ceph我们都测试过，但是由于一些原因，最后投向了Ceph的怀抱。

网络资源是OpenStack私有云最重要的地方，决定了整个私有云的成败，必须选择一种高效稳定的模型。在OpenStack中提供了Flat/FlatDHCP、GRE、VLAN等几种网络模型。通过对比，VLAN模型是最适合企业级需求的，具体原因会在后面详述。

鉴于目前OpenStack的稳定性还不够高，我们无法保证在大规模应用中，不会因为OpenStack的问题导致整个云服务宕机。那么我们必须在架构设计上保证，OpenStack的任何服务挂掉都不会影响云服务的稳定性。综合以上考虑，我们的私有云架构如图2所示。

上面的架构是从公司的需求出发，结合公司业务定制而成的。

首先，OpenStack控制节点故障，不会影响虚拟机的正常使用。因为虚拟机只是通过OpenvSwitch上网，通过物理路由器直接路由出去，跟控制节点没有关系，只是无法对虚拟机进行管理操作。如若是短时间宕机，无须切换备机，等待主节点启动即可。倘若主控制节点长时间故障，也可以启用备控制节点。

图2 私有云架构图

其次，计算节点不存在单点，而且计算节点之间也不相互依赖，单个计算节点宕机只会影响本节点的虚拟机。虚拟机可以使用本地磁盘和共享云存储相结合的方式，本地磁盘可以提高虚拟机磁盘的性能，减少网络带宽的消耗，但是有一定的故障率（取决于系统硬件的故障率），适合做操作系统等非业务数据。倘若是业务数据，为了提高数据的可用率，也可以通过存储网络获取共享存储资源。使用共享存储的虚拟机，在宿主机宕机之时，也可以通过实时迁移或者重新挂载等方式，快速恢复虚拟机的使用。

最后，虚拟机上网通过OpenvSwitch直接和硬件交换机等相连，不需要通过L3 Agent等连接网络，规避了OpenStack L3 Agent不稳定问题，既可以无缝和现有业务访问衔接，也可以提高虚拟机网络的效率和稳定性，使虚拟机网络和其他物理机网络的稳定性在同一个级别上。

网络设计

基于OpenStack的私有云建设，最复杂的当属网络部分。在前面，我们提到了虚拟机网络中OpenvSwitch和交换机直连，下面重点分析一下为什么这样设计。在OpenStack中，支持Flat/FlatDHCP、GRE、VLAN等几种模型，我们先分析一下这必种网络模型。

（1）Flat/FlatDHCP

Flat和FlatDHCP基本没有太多差异，只是有无DHCP功能的区别，它们都属于一种扁平的网络模型，所有的虚拟机网络在一个大二层的环境当中，不利于租户网络之间的隔离；由于共享段广播的存在，不利于在大规模网络中使用。

（2）GRE

一种网络隧道的方式，通过OpenvSwitch GRE模块传输，在IP报文上添加GRE头，重新封装而成。不需要交换机特殊配置，就可以实现租户网络之间的隔离，但是GRE的性能不是太好。

（3）VLAN

通过OpenvSwitch在二层报文上打上相应的VLAN Tag，从而实现租户网络隔离，性能比较好。但由于VLAN ID最多4096个，所以网段只能限制在4096个，而且还需要交换机做相应配置。

Flat/FlatDHCP不能实现租户网络之间的隔离，同时由于二层中IP地址数量的限制，不太适用于中等规模以上的私有云建设。VLAN和GRE最大的区别在于性能差别，因此我们做了一个VLAN和GRE性能的对比测试，在不同宿主机上启动两个虚拟机，宿主机采用万兆网卡相连，CPU是Intel E5-2640，测试结果如表1所示。

表1 测试结果

从上面的测试结果可以看出，GRE的性能不太好，同时会消耗大量CPU，无法达到万兆网卡极限；而VLAN的性能比较好，可以轻松地达到网卡极限。在企业中，性能可能是需要极致追求的东西，因此VLAN对于多数企业的私有云来说都是一种优选模型。

L3（Neutron L3 Agent）也是需要考虑的部分，到目前为止，OpenStack还没有提供高可靠性的L3解决方案。虽然可以使用多网络节点的部署模式，但是它仅是一个负载均衡方案，并非一个高可用性方案，直到最近的Juno版本提供了基于Keepalived的HA解决方案，但也并非完美的解决方案。我们从以下三点来说明L3目前存在的问题。

第一，从我们的运营经验来看，OpenStack的L3 Agent本身稳定性不够，流量稍大就有可能达到L3的性能瓶颈，甚至有可能服务失效。

第二，多网络节点能解决负载均衡问题，但无法解决L3稳定性问题和节点失效问题。

第三，Juno版基于Keepalived的方案，依赖于VIP和VRRP协议，从理论上是可行的，但是从我们的经验来看，在现实的网络环境中，VRRP也不是完全可信的，经常出现主备来回切换的问题。由于以上问题无法解决，因此我们采用去L3的结构，如图3所示是最终的网络方案图。

图3 私有云网络结构图

在网络结构图中，与原生OpenStack的最大不同就是停用了L3 Agent，由物理交换设备或者路由器承担L3的功能，在稳定性和性能上较OpenStack软件的L3 Agent都有很大提升，同时也不需要关注单点问题。如图3所示，控制节点提供Neutron-Server、DHCP等功能，通过eth0管理计算节点OVS-Agent，控制OVS-Agent的VLAN ID的映射规则生成。虚拟机连接br-int，在br-int上已经做了VLAN ID映射规则，VLAN ID转换完成以后，出br-eth2，通过eth2的Trunk模式连接物理交换设备，和其他网络相连。不需要浮动IP，就可以实现和其他网络的互通。

存储选型

存储选型是OpenStack私有云建设中比较重要的一部分，好的存储选型能够极大地提高系统的稳定性和数据的可用性。一般来说，可以分为本地存储和网络存储两种方式。

本地存储就是用本地磁盘作为虚拟机的存储磁盘，操作简单，无须任何配置，是OpenStack的默认存储方式。在性能方面，由于直接读取磁盘，没有经过网络等设备中转，因此性能较好，比较适合作为系统盘使用。但是，由于本地存储的数据可靠性依赖于本地硬件，所以可靠性并不高，因此需要用户自己做一些冗余性备份。

网络存储是采用一些分布式文件系统作为存储，通过网络的访问方式，提供给OpenStack私有云使用。分布式存储一般是采用多副本的冗余技术，当一个副本丢失的时候，系统会自动检查到，同时将副本复制到其他机器上，以保证副本的数量不小于设置的副本数量。因此，在数据可用性方面，分布式存储要远远好于本地存储。在网络条件较好和存储集群规模较大的情况下，分布式存储一般能够提供较高的存储性能。

但是，分布式存储由于冗余较大，建设成本也会较高。在一些典型的云计算环境中，一般将本地存储作为系统盘来提高本地磁盘的利用率，减少网络带宽的使用，而数据盘则采用分布式存储来提供数据的高可用性。比如AWS就是这样做的，当系统宕机以后，数据盘就可以轻松地挂载在其他机器上，几乎不影响数据的使用。

1．块存储

在OpenStack支持的存储中，比较常用的是Ceph和GlusterFS。GlusterFS是一个开源项目，后来被RedHat收购，但是仍然提供免费版本，是一个PB级别的分布式文件系统。GlusterFS的主要特点如下。

（1）高可用性

GlusterFS可以对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。

（2）无元数据

GlusterFS采用弹性Hash算法来进行数据的分布和查找，摒弃了传统的元数据节点结构，数据采用镜像复制结构，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。

（3）访问方式

Gluster存储服务支持NFS、CIFS、HTTP、FTP以及Gluster原生协议，完全与POSIX标准兼容。现有的应用程序不需要做任何修改或使用专用API，就可以对Gluster中的数据进行访问，非常方便。

在GlusterFS中，分为分布卷（Distributed Volume）、复制卷（Replicated Volume）、分片卷（Striped Volume）三种卷类型。分布卷通常用于扩展存储能力，不支持数据的冗余，除非底层的Brick使用RAID等外部的冗余措施。复制卷为GlusterFS提供高可用性，卷创建时可以指定副本的数量，当某个卷发生故障时能够自动同步和修复。分片卷将单个文件分成小块（块大小支持配置默认为128KB），然后将小块存储在不同的Brick上，以提升文件的访问性能。

在分布式存储中，Ceph是一支后起之秀，是其创始人Sage Weil在加州大学攻读博士期间的研究课题。随着云计算兴起以后，OpenStack社区把Ceph作为其最核心的开源存储方案之一，推动了Ceph的快速发展。Ceph之所以成为OpenStack的官方存储组件，这和其优秀的特性和良好的性能是分不开的。总地来说，Ceph是为优秀的性能、可靠性和可扩展性而设计的，是一个统一的、分布式存储系统。在Ceph中，包括OSD、MON、MDS三个组件，OSD负责数据的存储和管理，MON负责数据的一致性维护，MDS负责CephFS元数据的管理。其主要特性如下。

（1）高可用性

Ceph采用多副本技术进行数据的冗余，从而防止了一份数据丢失导致整个数据失效的问题，没有任何单点。Ceph MON组件实时监控和管理着数据的冗余和一致性，以及所有故障的检测和自动恢复。恢复不需要人工介入，在恢复期间，可以保持正常的数据访问。

（2）分布式元数据

在Ceph中，元数据存储是可选的，只有当使用CephFS时，才会引入元数据节点。Ceph的数据访问采用CRUSH算法，这和GlusterFS类似，数据的访问通过算法就可以定位地址，真正做到无单点和性能瓶颈。而CephFS中的元数据，采用分布式存储，数据定位也是采用CRUSH算法。

（3）多访问方式

Ceph提供了块设备存储（Ceph RBD）、文件系统存储（CephFS）和对象存储三种方式，为用户提供更多的访问方式。块设备存储允许用户像使用物理裸磁盘一样使用Ceph块设备，可提供良好的性能和不错的特性，比如设备快照等。CephFS提供了一种方便的挂载方式，用户采用Ceph客户端就可以很轻松地将其挂载，访问较方便，但是会引入Ceph元数据节点。Ceph对象存储和Swift一样，提供了海量对象存储空间，同时拥有较好的性能。

在设计理念和产品特性上，Ceph和GlusterFS具有很大的相似性。但是作为OpenStack的存储组件，我们到底该如何选择？其实作为云存储组件，GlusterFS和Ceph都有很多公司在使用。我们主要考虑使用Ceph，原因如下。

• OpenStack社区主推Ceph，作为社区的主推组件，从未来的趋势来看，会更加有前途和生命力。
• Ceph提供多种存储形式，尤其是对象存储，是GlusterFS不支持的，而对象存储是云计算的一个核心组件。
• Ceph在OpenStack使用中更加稳定（我们的观点），在作为虚拟机的磁盘使用过程中，Ceph几乎没有出现过问题，而GlusterFS偶尔会出现网络超时引起文件系统置为只读的情况。

2．对象存储

在OpenStack中，Swift是对象存储的核心组件，Swift是一个高可用的、完全对称的、无单点的、无限扩展的对象存储软件。最初是由RackSpace公司开发的高可用性分布式对象存储服务，2010年加入OpenStack开源社区作为其最初的核心子项目之一。Swift包括以下核心服务。

（1）Proxy Server

负责处理每个客户端的请求，将其均匀分散地分发到后端Storage Server上。Proxy提供了RESTful API，并且符合标准的HTTP协议规范，这使得开发者可以快捷地构建定制的Client与Swift交互。

（2）Storage Server

提供磁盘设备上的存储服务。在Swift中有三类存储服务器：Account、Container和Object。其中Container服务器负责处理Object的列表，Container服务器并不知道对象存放位置，只知道指定Container里存的是哪些Object。这些Object信息以SQlite数据库文件的形式存储。Container服务器也做一些跟踪统计，例如Object的总数、Container的使用情况。

（3）Consistency Server

查找并解决由数据损坏和硬件故障引起的错误。它们会在后台持续地扫描磁盘来检测对象、Container和账号的完整性，如果发现数据损坏，就会以副本拷贝的方式来修复数据。

从Swift的服务特点可以看出，Swift是一个分布式的、无单点的、能够自动容错的存储系统。因此，Swift的特点可以总结如下。

（1）高可用性

Swift由多副本技术进行冗余，能够进行自动故障恢复和容错，提供了极高的可用性。强一致性的容错方式和完全对称的结构，使得任何一个节点故障都不会影响整个系统的可用性。

（2）可扩展性

Swift的容量通过增加机器可线性提升。同时因为Swift是完全对称的结构，扩容只需简单地新增机器，系统就会自动完成数据迁移等工作，使各存储节点重新达到平衡状态，完全不需要人工干预。

（3）无单点故障

Swift的元数据存储是完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。在整个Swift集群中，也没有一个角色是单点的，良好的结构和设计保证了无单点故障存在。

典型的Swift架构如图4所示，每个节点采用完全相同的软件结构，以及完全对称的结构，机器的管理和维护非常方便，同时也不存在任何单点。

图4 Swift架构图

尽管Swift是OpenStack最稳定的组件之一，也是OpenStack社区推荐的对象存储组件，但我们在Swift使用过程中也遇到了一些问题。在使用过程中，作为存储Swift没有丢失过任何数据，作为OpenStack的Glance后端也完全能够胜任，但是如果作为其他目的使用，比如图片存储等服务，只要流量稍微一上来，Swift就必然遇到性能瓶颈，反应速度变慢，最后导致服务完全中断。因此，Swift对象存储不建议使用在流量较大的业务上。

通过前面的介绍我们知道，Ceph和GlusterFS大体的思想是差不多的，都是没有元数据节点的分布式存储，采用算法进行数据寻址，都是非常优秀的分布式文件系统。我们在使用GlusterFS作为虚拟机镜像时，经常会出现文件系统被写保护情况，非常影响虚拟机的使用。后续来我们换成了Ceph，在使用过程中，并没有出现明显的问题，因此推荐使用Ceph作为块存储。同时，Ceph的社区非常活跃，更新速度也非常快，相信在不久的将来，Ceph一定会变得更加稳定和成熟。另外，在对象存储方面，虽然OpenStack官方主推Swift，但是从笔者的惨痛经验来看，Swift的性能问题已经非常影响使用，因此Ceph的对象存储也是一种不错的选择。

服务器选型

私有云的架构和网络模型已经确定了，接下来我们将对硬件配置进行描述。控制节点需要运行MySQL服务和RabbitMQ服务，在稳定性上要求较高。同时，Glance服务也是运行在控制节点上的，由于Glance需要存储大量的镜像文件，因此也需要较大的存储空间。总地来说，控制节点需要稳定的大存储服务器。计算节点兼计算和本地存储两部分功能，计算性能和存储性能要求服务器性能比较均衡，网络节点由硬件路由设备担任，不需要网络节点。存储节点只需能够多挂载硬盘，使用普通存储性服务器即可。下面给出我们使用的硬件配置，如表2所示，供大家参考。

表2 硬件配置

安装部署

由于OpenStack的组件较多，安装部署一直是OpenStack一个被诟病的问题。限于篇幅的原因，这里我们不再探讨每个组件该如何安装，只是简单地说明各种安装方式需要注意的问题。我们尝试过的安装方式有三种：Fuel安装、RDO安装和手动安装。以下是这三种安装方式的特点。

（1）Fuel安装

OpenStack的一键部署工具，由Mirantis公司提供，提供硬件自动发现机制。通过简单的Web界面操作，就可以将OpenStack连同操作系统一起部署完成。这是最简单的一种部署方式。

（2）RDO安装

RDO安装是使用PackStack安装部署工具，将OpenStack的RPM包安装部署并且完成配置的一种部署方式。整个过程只需配置一个PackStack的配置文件，部署较为方便。

（3）手动部署

使用Yum源，按照OpenStack官方部署文档，一步一步安装配置，安装比较麻烦，但是能够增进对OpenStack各组件的了解。

Fuel安装无疑是最简单的部署方式，作为初学者使用一个快速搭建的工具是一个不错的选择。但是Fuel作为一个整体会连操作系统一起安装，企业一般会有自己的长期使用的操作系统版本，同时会在此版本下做大量适合自己业务的定制和优化，因此，Fuel一般不适合已经成熟的企业用来部署私有云，而且若对OpenStack做了定制化修改，采用Fuel也不是一个太好的选择。

RDO部署相对Fuel来说复杂度略高，需要指定PackStack的配置文件，后续的过程也是自动化安装。有几个问题也是要注意的：第一，由于网络的问题，PackStack在安装的过程中有可能失败，需要反复重试。第二，部署完成以后，尽量不要手动修改集群配置，因为增加节点时，PackStack会再次检查配置，将修改的配置覆盖，可能造成不可预知的错误。第三，由于依赖Yum源，若集群扩容机器，前后时间相隔太长，Yum源上软件包可能已经更新，可能造成前后安装的小版本不一致，这可能导致软件版本不兼容问题。

手动安装是最复杂的一种方式，但也是最可控的一种方式。对操作系统和软件的依赖最小，只要在一个系统上正确完成一次安装，其他节点就可以大批量部署，效率极高。由于依赖Yum源，因此和RDO安装有相同的问题。为了解决Yum源更新问题，我们可以在第一次部署完成以后，就将Yum源同步到自己的机器上并且做成自己的Yum源，以后安装使用自己的源即可，速度快而且不易出错。因此，手动安装OpenStack是我们比较推荐的一种方式。

性能优化

虚拟化技术已经是一项非常成熟的技术，但是在使用虚拟机时，很多人还是持半信半疑的态度，质疑虚拟机的性能问题。当然，使用虚拟机，服务器的性能会有所降低，到底会降低多少，我们用测试数据说话。在测试之前，我们需要对虚拟机——KVM主机进行一系列调优，以便虚拟机的性能达到较好的发挥。

1．CPU调优

CPU绑定是提升虚拟机性能比较常用的方法，通过绑定VCPU，能够减少CPU Cache的失效，从而提高虚拟机的性能。但是目前OpenStack虚拟机VCPU绑定不能自动化，必须手动使用virsh对虚拟机CPU绑定。另外，为宿主机预留CPU资源，是一个非常不错的选择。预留一定数量的CPU资源，也能提高整体的计算性能，通过配置nova.conf的参数就可以做到，如下所示：

vcpu_pin_set = 4-$

为宿主机预留了4个核，保证了宿主机对虚拟机的正常调度。另外，通过配置NUMA属性，能够显著提升虚拟机性能，因为绑定在同一个CPU上的两个超线程核心性能低于不同CPU上的两个超线程核心，不过这个特性只有J版本才支持。

2．内存调优

宿主机上的多个虚拟机会存在大量相似的内存页，如果将这些相似的内存页进行合并，就能节省大量的内存，KVM中的KSM就是这种技术，开启后会节省虚拟机的内存使用，但是同时会带来一定的CPU消耗。考虑到宿主机一般内存比较宽裕，而CPU增加成本较高，建议关闭内存合并，如下所示：

echo 0 > /sys/kernel/mm/ksm/pages_shared
echo 0 > /sys/kernel/mm/ksm/pages_sharing

另外，采用Huge Page开启也能提升一定的性能，不过目前Nova不支持，只能通过修改源码，需要在Libvirt生成的配置中加入以下内容：

<memoryBacking>
 <hugepages/>
</memoryBacking>

3．IO优化

在磁盘方面，通过改变磁盘的调度策略提高磁盘的效率，主要是将磁盘的调度方式改为Deadline，如下所示：

echo dealine > /sys/block/<dev>/queue/scheduler

另外，使用SR_IOV网卡虚拟化技术可以显著提高网卡性能，不过配置起来有点复杂，感兴趣的读者可以按照https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking自行配置。

性能测试

基本优化工作已经完成，下面对虚拟机性能做一个对比测试，测试对比机型配置如表3所示。

表3 测试对比机型配置

为了避免虚拟机之间的竞争，影响测试结果，在物理主机上只运行了一个虚拟机。若有多个虚拟机，虚拟机性能必然下降，此测试的主要目的是测试出KVM Hypervisor带来的性能损耗，因此单个虚拟机就可以说明问题。首先，通过UnixBench测试系统的整体性能，如图5所示。

图5 UnixBench性能测试结果

从测试结果可以看出，虚拟机大约相当于物理机5/6的性能。而且从参数上看，物理机的CPU主频更高。因此，KVM虚拟机能够达到物理机接近90%的性能。

接下来，我们使用iozone对磁盘的性能进行测试，如图6所示。

图6 磁盘性能测试结果

从磁盘的性能测试结果来看，Reader和Re-reader的性能下降较多，下降20%左右；而Write和Re-Write性能下降较小，下降10%左右。

最后，我们对虚拟机的网络性能进行测试，分别采用小包和大包进行测试，如图7所示。

对于小包的测试，我们采用一个字节的文件，通过Web服务下载，最后吞吐量8Kbps左右，大约是物理主机的1/4，主要是受限于虚拟机网卡的PPS。对于大包的测试，使用一个320KB的文件，通过Web服务进行下载，虚拟机和物理机基本差不多，都能将网卡跑到800bps以上。

图7 网络性能测试结果

总地来说，虚拟机的性能和物理机已经非常接近，CPU的性能达到物理机的90%，磁盘性能达到物理机的80%以上，网络性能在小包处理上较差。但是在现实应用中，存储小包的场景较少，虚拟机已经足够应付一些常规业务场景。若一定要追求较好的网络性能，则可以使用网卡虚拟机技术（SR-IOV），相信能够带来非常显著的提升。

IaaS平台运营心得

版本升级

版本升级是开源软件都会遇到的一个问题，OpenStack也同样遇到此问题。由于OpenStack组件很多，各组件之间相互关联，不同版本之间的组件可能存在兼容性问题，不同版本的数据表也存在差异性，因此，OpenStack的版本升级成本较高，需要慎重。OpenStack版本升级一般有以下两种原因。

• Bug修复。对于此问题，首先应考虑能否直接采取Bug修复补丁，这种方法成本较小，最后才考虑版本升级。
• 添加新功能。此种需求，首先应考虑新功能是否必需，有没有其他的代替方法，最后再考虑升级。

建议的升级方法如下：

在新服务器上搭建新版本控制节点，然后将线上控制节点数据库导入到新控制节点上，检查数据库兼容问题，两个控制节点数据库配置密码最好保持一致，使用OpenStack-status查看各组件状态，如果状态正常，说明控件节点升级完成。计算节点升级可能会升级Libvirt，有可能会导致虚拟机重启，因此应先升级一台做测试。为了安全起见，必须先通知虚拟机使用者，告知服务维护期间可能发生重启。准备工作都做好了以后，升级安装Nova和Neturon等，将控制节点指向新控制节点，其他节点都按照此操作，OpenStack的升级完成。

宿主机维护

虚拟机都运行在宿主机上，OpenStack的宿主机维护也是必须面临的一个问题。宿主机的维护一般分为可预知的维护和不可预知的故障。

可预知的维护比较好处理，一般采用虚拟机迁移方式，OpenStack支持实时迁移和带磁盘迁移。如果使用了Ceph等共享存储的话，实时迁移是非常不错的选择，实时迁移的时间与内存大小及内存修改速度有关。一般说来，虚拟机实时迁移宕机时间会在1秒以下。OpenStack带磁盘迁移需要的时间会比较长，而且需要停机。由于虚拟机的磁盘一般较大，要想将宿主机上的虚拟机全部迁出，在短时间之内是无法做到的，因此可以挑选一些重要性较高的虚拟机做带磁盘迁移。

对于不可预知的故障，宿主机已经停机，处理就比较麻烦，如果虚拟机使用的是共享存储，只需要修改Nova数据库中宿主机字段，然后硬重启虚拟机，虚拟机就可以恢复。如果使用的是本地磁盘，虚拟机就无法很快启动了，必须等宿主机故障恢复以后，虚拟机才能启动。如果是磁盘问题，虚拟机磁盘可能就无法找回了。因此，虚拟机最好要做备份。虚拟机备份也是一个比较棘手的问题，可以从两个方面进行处理，一是由于虚拟机磁盘大，备份成本较高，不停机备份磁盘可能出现数据不一致性问题，直接备份虚拟机磁盘的操作成本也较高，这种方法适合一些重要而且能够短时间停机的虚拟机使用；二是采用应用服务冗余机制，在业务层面保证有多个虚拟机提供同一服务。

RabbitMQ使用和监控

在OpenStack中，大量使用消息队列作为各组件交互的媒介，因此，消息组件的稳定性至关重要。在运营过程中，我们经常发现Nova或者Neutron连接RabbitMQ假死，导致虚拟机无法分配，或者虚拟机无法上网等情况。官方推荐使用RabbitMQ作为消息组件，尽量对RabbitMQ做高可用性配置，但是即使做了高可用性配置以后，还是会出现RabbitMQ连接超时的问题，因此需要对RabbitMQ进行监控。可以用Nagios或者Collectd等监控工具，监测到队列大于某个长度就可以告警，如果能写程序模拟队列的生成消费行为则更可靠。另外，可以对Nova-Compute和Neutron-OpenvSwitch-Agent的日志进行监控，一旦出现连接超时而且没有恢复就可以断定组件已经假死，需要重启才能恢复。为了减少消息队列的压力，尽量不要使用Ceilometer组件，若Ceilometer是必需组件，Ceilometer尽量使用单独的RabbitMQ队列，以减少对核心队列的压力。

虚拟机网络故障

在OpenStack中，经常会遇到虚拟机无法联网的情况，定位网络故障也是OpenStack运维必选课，主要追查流程如下。

（1）在虚拟机控制台中使用ifconfig检查IP配置，然后ping网关。
如若不通，执行步骤2。

(1)

（2）通过Dashboard检查Security Group，查看出口和入口的ICMP协议是否开启，若在开启情况下网络仍然不通，执行步骤3。

（3）在虚拟机宿主机上查看OpenFlow流。

(3)

若看到VlanID的转换规则，则说明VLAN转换没有问题；否则，需要重启Neutron-Server和RabbitMQ，再次查看VlanID转换规则是否已经生成。若还不通，执行步骤4。

（4）在出网的网卡（如em3）上抓包。

(4)

查看是否有包出去，如果看到包，则说明OpenStack配置没有问题，需要检查交换机是否配置Trunk模式。

总结

在本章中，我们介绍了IaaS建设的意义，探讨了两种搭建私有IaaS平台的方式：自己开发和采用开源方案。考虑到建设成本，对比了不同的开源IaaS建设方案后，我们选择基于OpenStack来搭建IaaS平台。在架构设计中，重点讨论了网络架构设计，因为网络架构设计是OpenStack搭建过程中最复杂的部分，也是决定成败的关键。鉴于对稳定性和性能方面的考虑，采用虚拟机通过Trunk直联交换机的方式，停用了Neutron-L3-Agent的功能，由物理设备直接担任路由转发的功能；在存储方面，通过经验选择了Ceph，因为它使用起来更加稳定，并且在不断的完善过程中。对象存储Swift的稳定性没有问题，但是性能问题非常明显，期待Swift的改进。在安装部署上，推荐使用手动安装方式，这是一种最可控的安装方式，但是需要对OpenStack的安装方法深入了解，增加了学习成本，同时建议将Yum源同步到本地，防止OpenStack源升级后产生不可预知的错误。接着，我们对虚拟机的性能进行了测试，以便消除大家对虚拟机性能的担忧。最后，介绍了一些OpenStack运营心得，比如版本升级、宿主机维护等常见问题，供大家参考。

本文遵循「知识共享许可协议 CC-BY-NC-SA 4.0 International」，未经作者书面许可，不允许用于商业用途的转载、分发、和演绎。