乐视和小米基于openstack云计算方案.docx

乐视云计算基于OpenStack的IaaS实践日期：2015-09-22来源： KVM虚拟化实践 作者：字体：大中小本文作者岳龙广，现在就职于乐视云计算有限公司，负责IaaS部门的工作。从开始工作就混在开源世界里，在虚拟化方面做过CloudStack/Ovirt开发，现在是做以OpenStack为基础的乐视云平台。所以对虚拟化情有独钟，也对虚拟化/云计算的未来充满了信心。乐视网的所有服务是跑在乐视云上的，乐视云提供所有的底层支撑，包括IaaS/PaaS/Storage/CDN等等。为了带给用户更好的体验，乐视网的服务到哪，乐视云的底层服务就会跟到哪。其中虚拟化是必不可少的部分，它的快速提供、按需分配、资源隔离显得特别重要，但我们会遇到什么问题呢?今天的主要目的是分享我们在OpenStack项目中做的一部分工作，它们解决了内部的一些需求，也是实际经验，希望对大家有所启发。开始之前 首先感谢肖总、浩宇、victor等朋友给予的大力支持，感谢群友、技术爱好者的围观。很荣幸有这次机会来与大家做这个分享。提纲：1. IaaS Architecture2. OpenStack Deploy & QOS3. Multiple Regions4. LeTV LBaaS5. DEV乐视云计算IaaS的基本架构首先就是介绍一下乐视云计算基础架构，再介绍OpenStack 网络组件的部署，Multiple Regions是什么样子的，更方便于使用的LeTV LBaaS，最后是开发/上线流程。乐视云计算 IaaS 采用了 OpenStack 和 Ceph 的开源方案，为乐视提供了云主机、虚拟网络、云硬盘和 S3 对象存储。我们采用了 Ceph RBD 作为 统一存储，OpenStack使用的Cinder，后端接的是Ceph，Glance也是共享Ceph存储。我们同时还提供了 S3 对象存储，用作于 CND 源站，存储乐视网的视频以及客户需要分发的资源。S3 也是全国分布式部署，用户可以就近上传，再推送到北京。目前乐视云 OpenStack 规模已达 900 个物理节点，对象存储的数据达到数PB。Neutron Deployment & QOS我们 Havana 版本采用了 nova-network 的 FlatDHCP 类型。Icehouse 版本采用了 Neutron，再做足调研的前提下，我们对 Neutron 做了大量的减法，所用服务仅为 Neutron Server 和 OpenvSwitch Agent，控制节点部署 Neutron Server(with ML2 plugin)，计算节点部署 OpenvSwitch Agent。没有网络节点，因而没有用到DHCP Agent，L3 agent 和 Metadata Agent。 物理网络使用 VLAN 做隔离。由于 Region 数量较多，每个 region 有不同的物理网络(对应ml2_conf 中的 physical_network 字段)，可以缓解 VLAN 数量的限制。私有云环境通过 Config Drive 配置虚拟机网卡和 metadata，Public IP 地址直接配在虚拟机网卡上，走物理路由器。无论是 nova-network 还是 neutron，我们都采用了稳定可靠的网络，由于不存在网络节点的单点问题，因此集群在满足私有云的需求前提下，兼顾了可靠性、稳定性和可扩展性。优点：简单稳定，性能更好，这也是业务最需要的，线上业务稳定、可用性是最重要的。缺点：牺牲了灵活性，和物理网络的耦合度高为了防止某个虚拟机负载过高而影响其它虚拟机或者宿主机，我们做了了 CPU，Network 和 Disk IO 的 QoS，其中 Cpu 的 QoS 采用 cgroup 实现，虚拟机网卡的 QoS 通过 TC 实现。一开始我们采用了 cgroup 限制 Disk IO，由于 ceph 采用了 Non-host-block，故 cgroup 无法限制基于 ceph 的 Disk IO, 因此我们采用了 qemu io throttling。和 cgroup 相比，qemu io throttling 不仅仅能支持 non-host-block IO，同时限速的效果也更为出色，限速后，虚拟机的 IO 不会有太大抖动。此外，如果基于 cgroup 的 Disk IO 设置过小，会导致虚拟机删除失败。原因在于 qemu 提交的 Direct IO 必须完成后才能退出，使用过小的磁盘带宽导致此动作需很长时间才能完成，导致 qemu 进程不能及时响应 libvirt 发出的 SIGTERM 和 SIGKILL 信号。而如果使用 qemu io throttling，则 io 会现在 qemu block layer 中加入 queue，此时 qemu 可以响应 libvirt 发出的信号而退出 。使用 qemu io throttling 需要需注意的是，当 Xfs 扇区大小为4k时，qemu 以 cache=none 方式启动失败Multiple Regions由于乐视网业务的特殊性，为了让用户有更好的体验，服务会分散部署在全球。乐视网的视频服务需要 CDN 的支持，对于某些 CDN 节点，特别是国外，需要提供云主机等基础设施服务。我们在国内外部署了有 20 多个集群，每个集群规模大小不一，其中最大的有上百个物理节点，这种需求也是极罕见的。这些节点既有 Havana 版本，又有 Icehouse 版本。每个集群均维护独自的 Dashboard 和用户信息，这就造成了以下四个问题：1. 用户租户信息不统一，不同集群的用户信息不一致，对用户使用有很大的影响2. 访问不同的集群，用户需要登录不同的 IP3. 运维难度增加4. 维护 H 和 I 版本的 Keystone 和 Horizon随着集群数量的不断增加，上述问题将显得越发突出，于是我们采用了 Multi-Region 方案，把这些集群做了统一的管理。部署方面， Keystone 和 Horizon 全局唯一，其中 Keystone 部署在公网，从而能够被其它服务访问，Horizon 部署在内网，从而能够访问其它集群。这是大概的分布图:LeTV LBaaSLeTV LBaaS,在原生LBaaS基础上做了定制化，为了区分开来，就叫做LeTV LBaaS。乐视网的服务需要高可用、扩展性。Neutron LBaaS 看起来是个不错的选择，基本框架有了，但是还不能完全满足业务需要。要想满足业务需要，除了增强已有的接口，还有开发新的功能，比如HaProxy 冗余，本身服务健康检查，以及与LVS整合。这是实际业务架构，通过域名解析到LVS，LVS把流量负载到LB机器，在通过LB把流量负载到其他机器，实际提供服务的机器可以横行扩展，不管是虚拟机还是物理机，甚至是容器。Letv LBaaS 可以轻松满足业务需求，优势如下：1. 不同业务之间的LB，互不干扰。Haproxy跑在各自的namespace里面2. Haproxy HA 冗余功能，保证服务的高可用3. 方便动态增加机器4. 与LVS整合DevOps & Community开发上线流程，基本和社区一致，是方便、可靠的：Commit-Review-Auto Testing-Package-Testing-Production最后总结一点建议：方案的选取1. 合适的才是最好的2. 业务需求优先，稳定性优先组件的选取1. 尽量采用主流软件，遇到问题可以快速解决版本的选取1. 成熟度与时新并重虚拟化，虚拟计算，虚拟网络，虚拟存储，我们大多会第一个想到OpenStack，或者由OpenStack带来的这些功能。其实这些技术是可以独立的，可以完美用到其他方面。让所有的业务都跑在虚拟网络里，为他们提供虚拟资源，并且可以轻而易举的控制调整它们，方便管理整个数据中心，希望我们以后可以探讨更大的话题。Q&A1.为什么没有使用swift?答： switft 我不熟悉，但是ceph 数据分布，性能方面都很不错，crush算法是它的亮点。2.可否介绍下你们的网络架构 ，以及你们目前架构下对网络的要求答：总体的架构是标准的neutron架构，但是我们没有部署网络节点，直接使用物理路由器，这适合稳定性高的场景。3.监控咱们这边是怎么做的，是用社区原生的Celimeter还是自己的监控系统答：是的ceilometer，做过优化，以及换成influxdb，包括对floatingIP的流量监控。4.iaas层是否提供了nas接口，视频转码，合成等业务软件访问存储是通过S3 接口还是其他接口呢;答：没有NAS接口。视频提供了S3和HTTP接口。5.选Haproxy有什么优势吗?答：HaProxy 是专注于负载均衡的功能，提供的算法比较丰富，并发性也更好。6.你提到有的有集群上百个物理节点，部署这些物理节点时候，采用什么方法的?答：参照问题2。7.集群把公网线和心跳线用反了有什么后锅，我感觉谁当心跳谁当公网，没什么大不了，求解答：你说的心跳线是指什么? 公网是收费的，大家不希望浪费购买的带宽，所有不稳定的因素多。 内网做心跳更好，心跳实时性要求高。8.交换机上的VLAN全手动配置?交换机也手动配置与虚拟机TC相对应的QoS?答：是的，这个地方的QOS 主要是限速。9.高可用如何保证的答：DNS负载均衡 和 LVS 高可用，共同保证总的高可用。10.那db性能怎么解决?答：一般没问题，如果ceilometer 采样频繁，vm多的话，撑不住。我们现在是influxdb，已经对采样频率和采样的内容进行裁剪。11.对于些开发能力小的公司来说，使用上openstack不?openstack在虚拟机的基础上做了资源管理，目的是充分利用资源吧?cpu方面的分配很好理解，IO能调配不?有一些场景是，部分机器io很闲，部分IO很忙，可以调整利充分用上?乐视的定制版在这方面有改进呢?答：如果没有太多需求，可以用virt-manager,直接管理。 openstack 还是比较复杂的。但是虚拟化可以大量节省成本io就是限制读写磁盘的速率iops 或者带宽 ，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，需要互通吗?答：部署在几个region 是为了高可用性。 大家都会访问同一个数据库。18.请问平均一个节点多少虚机?答：为了保证业务，我们的配比 比较低。没有超过1：10. 主要看业务和重要程度。19.每次版本更新需要多长时间，什么范围内更新呢?答：我们现在是长期维护一个稳定版本。20.在问个成本问题，是用的整理柜服务器还是定制的服务器，一个机柜装几台?答：不好意思，这个问题，我回答不了你，抱歉。21.华为分布式存储要求各个机器硬盘配置一样，ceph有这个要求吗?答：没有强制要求，ceph 可以设置机器的权重。22.keystone，horizon全局唯一，是放在一个region里面还是怎么做冗余的?答：主要做好数据库冗余就好，前端部署LB，提供 高可用和并发。23.想问下硬件资源cpu,mem,storage的超配比，是怎么调配的答：这个要根据自己的策略来定，看你的flavor，超配等。24.请问是否有对云主机安装agent用做监控来收集信息答：一般不需要，这个地方只是为了取内存数据。25. ceph稳定性如何?性能和san或者nas做过对比测试吗?答：和本地做过对比， san 和nas 品种很多，看对IO的要求，业务要求，ceph性能和稳定性都不错。小米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测试时，差别非常明显，虚拟机仅相