OpenStack在小米私有云平台的实践

小米 OpenStack 项目概况

小米目前内部建设的是高可用的私有云平台，为全公司提供统一的云服务平台。提供弹性的资源分配和部署方式，同时提高资源的分配和管理效率。减少服务资源的交付周期。为此小米定了四大目标：

• 稳定第一：支撑公司多条产品线业务，力求稳定
• 性能优化：尽快可能的降低虚拟机的资源消耗，保证虚拟机的性能
• 内网互通：虚拟机需要和公司其他主机互联互通。对其他主机透明
• 业务定制：OpenStack需要和公司其他系统互通（监控和主机信息）

小米基于这四点做了私有云平台，有着数千台VM的OpenStack集群，稳定服务公司线上线下业务一年多时间，数据说明如下：

• 可用度达到99.99%。运行16个月，2次故障，分别是GlusterFS和OpenvSwitch引发的问题：1.GlusterFS的bug有可能导致文件系统被置为Readonly，据说bug目前已经修复；2.在广播风暴的情况下，OpenvSwith由于起软件性能的问题，最有可能被打死，这个问题是所有的软网桥（包括VMware）都存在的问题；
• 目前使用率：平均40%（物理机利用率），1虚12；
• 覆盖度：小米所有产品线；
• 业务类型：开发，测试，线上（线下70%）。

现在整个平台上运行在四个机房，有2000+VM，4500+物理机内核（E5-2640）；机器的配置主要为：50T内存、1200T虚拟磁盘、480T块存储、120T对象存储。

上图是小米根据自己的情况定制的Dashboard的，分为动态信息和静态信息两个部分，静态信息显示的是资源的分配情况，动态信息显示的是目前资源的使用情况。

上图是OpenStack物理主机的使用情况，机器是负载明显看出是分层的，因为是一批一批上的机器，后面机器由于虚拟机的使用还没有分配满，所以CPU LOAD会低一些。

上图是虚拟机的负载情况，可以看出，有些虚拟机的负载程周期性变化，可能是跑的和流量相关的一些线上业务；而有些虚拟机的CPU却一直持续在500%左右，可能是虚拟机里面跑了高负载的离线计算业务。

小米 OpenStack 探索之路

机器选型

在进行机器选择时，可选的类型并不多，一般是在公司内部已有的套餐类型中选择，然后稍加定制，主要的要求实现服务器性能的均衡，而且性能比较好的主机类型。机器配置详细参数为：

计算节点:  DELL _R720

• CPU： E5-2640v2*2(32核)
•   MEM：16G*24
•   磁盘：2*600G SAS（Raid1) + 6*4T（Raid5） SATA
•   网卡:  1G * 2 + 10G*2 (Intel 82599EB 10-Gigabit SFI/SFP+ )

控制节点:  DELL_R620

• CPU： E5-2630v2*2 (24核)
• MEM：16G*4
• 磁盘：2*600G SAS（Raid1) + 2*240G SSD(Raid1)
• 网卡:  1G * 2 + 10G*2 (Intel 82599EB 10-Gigabit SFI/SFP+ )

其实Dell R720是Dell官方推荐的虚拟机云计算主机，作为OpenStack的计算节点还是比较合适的。

版本选择

操作系统

操作系统选择：Ubuntu vs CentOS。

OpenStack最早默认支持的操作系统版本是Ubuntu，后来才加入了Redhat系列操作系统的支持，但公司一般使用CentOS的系统，装机方便，系统稳定，为了稳定性和兼容性，我们也是采用CentOS做为OpenStack的操作系统。采用RDO的方式进行安装，但是在装的过程中也遇到一些问题。比如在三个月之前采用RDO部署了一套系统，在三个月以后我们再需RDO部署的时候，RDO源上的版本就更新了，有可能导致老版本和新版本不兼容，由于OpenStack版本之间的测试不是特别完备，尽管是大版本相同但是小版本有差异，都有可能导致不兼容，但也有解决的方法：把yum源down下来，即解决了版本问题，同时也能加快软件安装下载的速度。

采用RDO安装还有另外一个问题，就是在安装完成以后，不能手动更改系统配置的路径，如数据库路径或者镜像存储路径，如果一定要改，须连packstack中的Puppet配置路径一起改。否则在下次启动RDO安装时，他会再次将路径再改成默认配置，这个将导致不可预知的错误。如果此时已经跑了服务，那很有可能会影响的服务。

总的来说，RDO的优点是简单快速部署，支持多种网络结构，缺点也明显，添加计算节点是个坑，存在各种兼容性问题（packstack版本、qpid版本、libvirt版本），而解决的办法就是建立自己的源，手动添加计算节点。

网络

组件可选择有Neutron 和 Nova-network。

我们选择的是Neutron，也是跟着大趋势走。网络模型可选择FLAT、GRE和VLAN。我们选择了VLAN，因为公司现有网络模型也是采用VLAN模型，和OpenStack原生的网络模型相比，我们的主要改进点是停用了L3 Agent，无单独的网络节点，让虚拟机网络通过Trunk直接和物理路由器相连，因此虚拟机网络比较高效和稳定。与此同时，OpenStack工程师大部分是做开发和运维的，网络管理不是他们所擅长的，所以把网络节点去掉由交换机进行管理，全部交由网络工程师去做，他们更专业。同时，若采用一个物理的主机作为一个网络节点，无论是性能上还是可操作性上，都不如成熟的交换机。Neutron的稳定性确实不高，经常断掉，导致OpenVswtich无法配置网络策略。

块存储

块存储的组件选择有两个，一个是Ceph，另外一个是GlusterFS。我们对Ceph和GlusterFS做了测试，在四台机器上都部署了Ceph和GlusterFS，Ceph和GlusterFS在每台机器上各占一块磁盘，2副本策略，机器是单网卡，测试结果请看下图。

从上图IOSP测试对比中，可以看出在块比较小的时候，Ceph的IOPS性能非常高，在块大小为4KB的时候，甚至高出GlusterFS 40%左右，但是块大小大于1MB的时候，Ceph的性能就不如GlusterFS了，我们推动是Ceph和GlusterFS不同的副本同步策略造成的。GlusterFS采用Client直接写入的策略，即每次写入以后，节点之间不需要再同步；而Ceph采用的链式写入，即Client先写入到一个节点上，然后节点之间再同步，因此会消耗一定的带宽，当没有专门的同步网络的时候，同步所使用的网络带宽可能会影响到Ceph的写入性能。因此，写入方式的差异刚好能够解释GlusterFS在大块写入的时候会比Ceph性能好。

上图是对Ceph和GlusterFS进行4KB大小块的连续测试，我们会发现Ceph的整体性能会比GlusterFS高，但是他呈现出性能波动现象，而GlusterFS却一直比较稳定，这也从一个层面上说明了Ceph这种链式写入的机制对连续测试可能会产生波动性的结果。总的来说，两者各有千秋，存储没有完美的方案，Ceph逐渐成熟，在小块写入的时候Ceph性能比较好，但是大块写入却不如不如GlusterFS，同时Ceph的性能具有波动性。但是，GlusterFS在实际使用中可以导致虚拟机的文件系统被置为Readonly（据说此Bug已经被修复），需要慎重考虑和测试。不管是Ceph，还是GlusterFS作为虚拟机的共享存储，都能够提供毫秒级别的实时迁移，对虚拟机的负载均衡、主机维护非常有用；同时多副本的技术保证用户数据的安全性，将数据丢失的风险降低最低。

对象存储

所用组件是Swift，架构请参见上图，Swift可以说是OpenStack最古老最成熟的一个组件，良好的设计思想，完全对称的部署结构，无单点的系统架构。纵容有很多好处，但是在用Swift的时候，有一个惨痛的教训，Swift作为存储服务器没有丢失过数据，但是swift扛压能力非常小，曾使用Swift做为CDN的源服务器，流量稍一上来，Swift的服务器就被打死了，当时观测流量大约10Mb左右，观察Swfit资源消耗情况，在完全没有压力的情况下，Swift自动的组件性能消耗会占一个核。

私有云架构

上图所描述的是小米的OpenStack架构的使用，目前只有两种节点，一种是计算节点，另一种是控制节点，但没有网络节点，所以网络不会存在单点，任何一个计算节点宕机，只会影响其上面承载的虚拟机，不会影响其他节点，如果是一个可以预知的宕机，你甚至可以先将其上的虚拟机迁移到其他机器，这样就可以将对服务的影响降到最低。另外，控制节点是主备模式，并且采用冷备的方式，但是数据库保持实时同步。因为这种私有云的架构对控制节点的依赖非常小，控制节点宕机，在不重启计算节点的OpenVswitch-Aagent的情况下，几乎不会影响虚拟机的正常运行。在网络的架构上，我们有三种网络：虚拟机网络、存储网络和管理网络。虚拟机网络通过网桥，采用Trunk模式，直接连接到交换机，具有较好的性能和极高的稳定性。管理网络是OpenStack各个组件通信的网络，包括镜像分发，虚拟机迁移等都是走这个网络。存储网络是虚拟机访问共享存储Ceph的网络。

上图是小米私有云的网络详细架构图，基于L3-Agent的稳定性和性能，我们停用了L3-Agent，虚拟机首先连接到br-int,，br-int连接到br-em3上，通过Trunk就可以达到外部网络，这样的架构解决了两个问题：第一，能够保证网络的性能和稳定性，第二，能实现和内网其他机器无缝互通，

性能测试

在使用虚拟机时候，很多人抱着一个怀疑的态度，他们会担心虚拟机的性能是否够用，我们对虚拟机的性能做了如下测试：

测试1：整体性能测试

UnixBench是一个测试系统整体系能的软件，测试中我们分别对比了AWS, MiStack,3U8j机器，从测试结构看，同样是虚拟机，MiStack的机器会比AWS相同的机型性能好很多，主要原因是AWS为了保障每个虚拟机的服务质量，对虚拟机的资源占用情况做了严格的限制，因此可比性并不大，但是MiStack和3U8相比，其实相比相差不大，3U8作为一种物理机器，在性能上只比MiStack主机好1/6左右，因此，我们可以说虚拟机的性能可以相当于相同配置的物理机行的80%以上。

测试二：磁盘性能测试

测试二是词用IOzone对虚拟机的磁盘性能进行了测试，对比的是MiStack和3U8机器，从图上可以看出，在读取方面，虚拟机相当于物理机的5/6左右，在写方面，虚拟机相当于物理机的9/10左右。

测试三：网络性能测试

网络测试分为了两组测试，一个测试是用HelloWorld做的，另一个是PhoInfo做的。采用PhoInfo测试时，虚拟机和物理机的差别并不大，但是在采用HelloWorld测试时，差别非常明显，虚拟机仅相当于物理机的1/4。我们对原因进行了分析，由于HelloWorld页面非常小，测试过程相当于产生了很多小数据包，而PhpInfo相对页面很大，从而产生的数据包也比较大。当在小包测试下，网络的瓶颈在PPS上，我们反复测试过，虚拟机软网桥的性能只能到达5wPPS左右，此时OpenVswitch已经到了极限，而普通的物理网卡确定达到200wPPS。在打包测试时，网络的瓶颈在网络带宽上，因此，虚拟机和物理机带宽相差不大，因此测试的结果也相差不大。

维护方案- 虚拟机迁移

为实现物理机故障维护和虚拟机的负载均衡，虚拟机通常需要迁移，主要分为两种维护方案：实时迁移和带磁盘的迁移。

维护方案-实时迁移

因为企业很难接受频繁的更换，如果一两个月换一次，那么一个月要维护一两次，若这时全部都通知用户把机器和业务停了，会很痛苦。虚拟机迁移可以很好地实现“无痛迁移”。虚拟机迁移方案中的实时迁移是用一个precopy算法去迭代拷贝，在每次拷贝的过程中用内部记录的方式记录内存“脏”页，当“脏”张页数据集小于一定程度时，比如4K的时候，停止虚拟机，把内容和寄存器迁移，由于需要停机拷贝的内容非常少，因此停机的时间非常短，不过实时迁移一般是相同体系的CPU才能相互迁移。上图是实时迁移，它的停机时间会很短。

维护方案-带磁盘迁移

带磁盘的迁移是将磁盘和内存一起拷贝到目前机器，由于磁盘数量很大，所以一般是先做快照，然后将形成的数据写到增量中去，然后我们开始拷贝快照，当所有的快照都已经拷贝完成以后，再开始拷贝增量文件，一般在拷贝的过程中，产生的增量文件是非常小的，因此停机时间还是可以接受的。但是OpenStack没有这么做，他只做了一个快照，那就是镜像文件，其他的数据都是增量，这样会导致OpenStack虚拟机的增量文件非常大，停机拷贝的时间非常长，如上图。

总的来说，实时迁移是采用precopy算法循环拷贝内存到目的机器，停机时间极短，但需要共享存储；而带磁盘迁移：将磁盘做快照后拷贝磁盘到目的机器，后面过程跟实时迁移一样，整个过程时间取决于磁盘大小，停机时间稍长。（责编/周建丁）

作者简介： 潘晓东， 毕业于华中科技大学集群与网格实验室，从2007年开始研究虚拟化云计算技术，曾对XEN的实时迁移算法进行改进和优化。先后在百度、小米等公司从事运维、开发工作，现为小米OpenStack项目负责人。在小米一直致力于高稳定的OpenStack私有云建设，目前小米集群分布在多个IDC、数千台虚拟机，服务公司几十个产品线的线上和线下业务。