小米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-2640v22(32核)
MEM：16G24
磁盘：2600G SAS（Raid1) + 64T（Raid5） SATA
网卡: 1G 2 + 10G2 (Intel 82599EB 10-Gigabit SFI/SFP+ )
掌握节点: DELL_R620
CPU： E5-2630v22 (24核)
MEM：16G4
磁盘：2600G SAS（Raid1) + 2240G SSD(Raid1)
网卡: 1G 2 + 10G2 (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就可以达到外部网络，这样的架构办理了两个问题：第一，能够担保网络的性能和稳定性，第二，能实现和内网其他机器无缝互通，
性能测试
在利用虚拟机时候，很多人抱着一个疑惑的态度，他们会担心虚拟机的性能是否够用，我们对虚拟机的性能做了如下测试：
测试一：整体性能测试
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算法循环拷贝内存到目的机器，停机韶光极短，但须要共享存储；而带磁盘迁移：将磁盘做快照后拷贝磁盘到目的机器，后面过程跟实时迁移一样，全体过程韶光取决于磁盘大小，停机韶光稍长。
【预报】首届中国人工智能大会（CCAI 2015）将于7月26-27日在北京友情宾馆召开。机器学习与模式识别、大数据的机遇与寻衅、人工智能与认知科学、智能机器人四个主题专家云集。人工智能产品库将同步上线，预约咨询：QQ：1192936057。欢迎关注。
