《乐视和小米基于openstack云计算方案》由会员分享，可在线阅读，更多相关《乐视和小米基于openstack云计算方案（21页珍藏版）》请在金锄头文库上搜索。
1、乐视云计算基于乐视云计算基于 OpenStack 的的 IaaS 实践实践日期：2015-09-22来源： KVM 虚拟化实践 作者：字体：大 中 小本文作者岳龙广，现在就职于乐视云计算有限公司，负责 IaaS 部门的工作。从开始工作就混在开源世界里，在虚拟化方面做过 CloudStack/Ovirt 开发，现在是做 以 OpenStack 为基础的乐视云平台。所以对虚拟化情有独钟，也对虚拟化/云计算的未来 充满了信心。乐视网的所有服务是跑在乐视云上的，乐视云提供所有的底层支撑，包括 IaaS/PaaS/ Storage/CDN 等等。为了带给用户更好的体验，乐视网的服务到哪，乐视云的底层服务
2、就 会跟到哪。其中虚拟化是必不可少的部分，它的快速提供、按需分配、资源隔离显得特别重要， 但我们会遇到什么问题呢?今天的主要目的是分享我们在 OpenStack 项目中做的一部分工作，它们解决了内部的 一些需求，也是实际经验，希望对大家有所启发。开始之前 首先感谢肖总、浩宇、victor 等朋友给予的大力支持，感谢群友、技术爱好 者的围观。很荣幸有这次机会来与大家做这个分享。提纲：1. IaaS Architecture2. OpenStack Deploy 答：没有 NAS 接口。视频提供了 S3 和 HTTP 接口。5.选 Haproxy 有什么优势吗?答：HaProxy 是专注于负载均衡
3、的功能，提供的算法比较丰富，并发性也更好。6.你提到有的有集群上百个物理节点，部署这些物理节点时候，采用什么方法的?答：参照问题 2。7.集群把公网线和心跳线用反了有什么后锅，我感觉谁当心跳谁当公网，没什么大不 了，求解答：你说的心跳线是指什么? 公网是收费的，大家不希望浪费购买的带宽，所有不稳 定的因素多。 内网做心跳更好，心跳实时性要求高。8.交换机上的 VLAN 全手动配置?交换机也手动配置与虚拟机 TC 相对应的 QoS?答：是的，这个地方的 QOS 主要是限速。9.高可用如何保证的答：DNS 负载均衡 和 LVS 高可用，共同保证总的高可用。10.那 db 性能怎么解决?答：一般没问
4、题，如果 ceilometer 采样频繁，vm 多的话，撑不住。我们现在是 influx db，已经对采样频率和采样的内容进行裁剪。11.对于些开发能力小的公司来说，使用上 openstack 不?openstack 在虚拟机的基础上 做了资源管理，目的是充分利用资源吧?cpu 方面的分配很好理解，IO 能调配不?有一些场 景是，部分机器 io 很闲，部分 IO 很忙，可以调整利充分用上?乐视的定制版在这方面有改 进呢?答：如果没有太多需求，可以用 virt-manager,直接管理。 openstack 还是比较复杂 的。但是虚拟化可以大量节省成本 io 就是限制读写磁盘的速率 iops 或
5、者带宽 ，qemu 自 身可以限制。12.公网络这块，这接把 pub ip 配置到容器，那平台的防火墙策略在哪一层做限制?答：外层防火墙，一般是 3，4 层. 是否控制 7 层，我不能确定。13.二次开发主要是改了哪些地方答：社区有我们提交的代码。14.底层操作系统是啥?rehl6,7? or ubuntu?答：centos6.5。15.上线往各个节点推送文件，是用什么推的呢答：是 puppet。16.LVS 是什么?会有单点问题吗?答：LVS 是 linux virtual server, 没有单点故障，参见问题 9。17.会有一个业务几个 region 都有 vm，需要互通吗?答：部署在几
6、个 region 是为了高可用性。 大家都会访问同一个数据库。18.请问平均一个节点多少虚机?答：为了保证业务，我们的配比 比较低。没有超过 1：10. 主要看业务和重要程度。19.每次版本更新需要多长时间，什么范围内更新呢?答：我们现在是长期维护一个稳定版本。20.在问个成本问题，是用的整理柜服务器还是定制的服务器，一个机柜装几台?答：不好意思，这个问题，我回答不了你，抱歉。21.华为分布式存储要求各个机器硬盘配置一样，ceph 有这个要求吗?答：没有强制要求，ceph 可以设置机器的权重。22.keystone，horizon 全局唯一，是放在一个 region 里面还是怎么做冗余的?答：
7、主要做好数据库冗余就好，前端部署 LB，提供 高可用和并发。23.想问下硬件资源 cpu,mem,storage 的超配比，是怎么调配的答：这个要根据自己的策略来定，看你的 flavor，超配等。24.请问是否有对云主机安装 agent 用做监控来收集信息答：一般不需要，这个地方只是为了取内存数据。25. ceph 稳定性如何?性能和 san 或者 nas 做过对比测试吗?答：和本地做过对比， san 和 nas 品种很多，看对 IO 的要求，业务要求，ceph 性 能和稳定性都不错。小米小米 OpenStack 项目概况项目概况小米目前内部建设的是高可用的私有云平台，为全公司提供统一的云服务
8、平台。提供弹性的资源分配和部署方式，同时提高资源的分配和管理效率。减少服务资源的交付周期。为此小米定了四大目标：稳定第一：支撑公司多条产品线业务，力求稳定性能优化：尽快可能的降低虚拟机的资源消耗，保证虚拟机的性能内网互通：虚拟机需要和公司其他主机互联互通。对其他主机透明业务定制：OpenStack 需要和公司其他系统互通（监控和主机信息）小米基于这四点做了私有云平台，有着数千台 VM 的 OpenStack 集群，稳定服务公司线上线下业务一年多时间，数据说明如下：可用度达到 99.99%。运行 16 个月，2 次故障，分别是 GlusterFS 和 OpenvSwitch 引发的问题：1.Gl
9、usterFS 的 bug 有可能导致文件系统被置为 Readonly，据说 bug 目前已经修复；2.在广播风暴的情况下，OpenvSwith 由于起软件性能的问题，最有可能被打死，这个问题是所有的软网桥（包括 VMware）都存在的问题；目前使用率：平均 40%（物理机利用率），1 虚 12；覆盖度：小米所有产品线；业务类型：开发，测试，线上（线下 70%）。现在整个平台上运行在四个机房，有 2000+VM，4500+物理机内核（E5-2640）；机器的配置主要为：50T 内存、1200T 虚拟磁盘、480T 块存储、120T 对象存储。上图是小米根据自己的情况定制的 Dashboard
10、的，分为动态信息和静态信息两个部分，静态信息显示的是资源的分配情况，动态信息显示的是目前资源的使用情况。上图是 OpenStack 物理主机的使用情况，机器是负载明显看出是分层的，因为是一批一批上的机器，后面机器由于虚拟机的使用还没有分配满，所以 CPU LOAD 会低一些。上图是虚拟机的负载情况，可以看出，有些虚拟机的负载程周期性变化，可能是跑的和流量相关的一些线上业务；而有些虚拟机的 CPU 却一直持续在 500%左右，可能是虚拟机里面跑了高负载的离线计算业务。小米小米 OpenStack 探索之路探索之路机器选型机器选型在进行机器选择时，可选的类型并不多，一般是在公司内部已有的套餐类型中
11、选择，然后稍加定制，主要的要求实现服务器性能的均衡，而且性能比较好的主机类型。机器配置详细参数为：计算节点: DELL _R720CPU： 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_R620CPU： E5-2630v2*2 (24 核)MEM：16G*4磁盘：2*600G SAS（Raid1) + 2*240G SSD(Raid1)网卡: 1G * 2 + 10G*2
12、(Intel 82599EB 10-Gigabit SFI/SFP+ )其实 Dell R720 是 Dell 官方推荐的虚拟机云计算主机，作为 OpenStack 的计算节点还是比较合适的。版本选择版本选择操作系统操作系统操作系统选择：Ubuntu vs CentOS。OpenStack 最早默认支持的操作系统版本是 Ubuntu，后来才加入了 Redhat 系列操作系统的支持，但公司一般使用 CentOS 的系统，装机方便，系统稳定，为了稳定性和兼容性，我们也是采用 CentOS 做为 OpenStack 的操作系统。采用 RDO 的方式进行安装，但是在装的过程中也遇到一些问题。比如在三个
13、月之前采用 RDO 部署了一套系统，在三个月以后我们再需 RDO 部署的时候，RDO 源上的版本就更新了，有可能导致老版本和新版本不兼容，由于 OpenStack 版本之间的测试不是特别完备，尽管是大版本相同但是小版本有差异，都有可能导致不兼容，但也有解决的方法：把 yum 源 down 下来，即解决了版本问题，同时也能加快软件安装下载的速度。采用 RDO 安装还有另外一个问题，就是在安装完成以后，不能手动更改系统配置的路径，如数据库路径或者镜像存储路径，如果一定要改，须连 packstack 中的 Puppet 配置路径一起改。否则在下次启动 RDO 安装时，他会再次将路径再改成默认配置，这
14、个将导致不可预知的错误。如果此时已经跑了服务，那很有可能会影响的服务。总的来说，RDO 的优点是简单快速部署，支持多种网络结构，缺点也明显，添加计算节点是个坑，存在各种兼容性问题（packstack 版本、qpid 版本、libvirt 版本），而解决的办法就是建立自己的源，手动添加计算节点。网络网络组件可选择有 Neutron 和 Nova-network。我们选择的是 Neutron，也是跟着大趋势走。网络模型可选择 FLAT、GRE 和 VLAN。我们选择了 VLAN，因为公司现有网络模型也是采用 VLAN 模型，和 OpenStack 原生的网络模型相比，我们的主要改进点是停用了 L3
15、 Agent，无单独的网络节点，让虚拟机网络通过Trunk 直接和物理路由器相连，因此虚拟机网络比较高效和稳定。与此同时，OpenStack工程师大部分是做开发和运维的，网络管理不是他们所擅长的，所以把网络节点去掉由交换机进行管理，全部交由网络工程师去做，他们更专业。同时，若采用一个物理的主机作为一个网络节点，无论是性能上还是可操作性上，都不如成熟的交换机。Neutron 的稳定性确实不高，经常断掉，导致 OpenVswtich 无法配置网络策略。块存储块存储块存储的组件选择有两个，一个是 Ceph，另外一个是 GlusterFS。我们对 Ceph 和GlusterFS 做了测试，在四台机器上
16、都部署了 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 的整体性能
