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

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、数千台虚拟机,服务公司几十个产品线的线上和线下业务。

Comments are closed.