华尔思论坛

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 344|回复: 2

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

[复制链接]

4

主题

6

帖子

25

积分

新手上路

Rank: 1

积分
25
发表于 2016-7-20 20:01:55 | 显示全部楼层 |阅读模式
本帖最后由 华尔思研究 于 2016-7-20 20:07 编辑

小米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对象存储。
        

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

4

主题

6

帖子

25

积分

新手上路

Rank: 1

积分
25
 楼主| 发表于 2016-7-20 20:08:32 | 显示全部楼层
上图是小米根据自己的情况定制的Dashboard的,分为动态信息和静态信息两个部分,静态信息显示的是资源的分配情况,动态信息显示的是目前资源的使用情况。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

4

主题

6

帖子

25

积分

新手上路

Rank: 1

积分
25
 楼主| 发表于 2016-7-20 20:09:19 | 显示全部楼层
本帖最后由 华尔思研究 于 2016-7-20 20:14 编辑

上图是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算法循环拷贝内存到目的机器,停机时间极短,但需要共享存储;而带磁盘迁移:将磁盘做快照后拷贝磁盘到目的机器,后面过程跟实时迁移一样,整个过程时间取决于磁盘大小,停机时间稍长。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|小黑屋|华尔思论坛 ( 京ICP备07006477号

GMT+8, 2019-3-22 23:17 , Processed in 0.119685 second(s), 26 queries .

Powered by Discuz! X3.1

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表