乐视云计算基于OpenStack的IaaS实践

本文作者岳龙广，现在就职于乐视云计算有限公司，负责IaaS部门的工作。

　　从开始工作就混在开源世界里，在虚拟化方面做过CloudStack/Ovirt开发，现在是做以OpenStack为基础的乐视云平台。所以对虚拟化情有独钟，也对虚拟化/云计算的未来充满了信心。

　　乐视网的所有服务是跑在乐视云上的，乐视云提供所有的底层支撑，包括IaaS/PaaS/Storage/CDN等等。为了带给用户更好的体验，乐视网的服务到哪，乐视云的底层服务就会跟到哪。

　　其中虚拟化是必不可少的部分，它的快速提供、按需分配、资源隔离显得特别重要，但我们会遇到什么问题呢?

　　今天的主要目的是分享我们在OpenStack项目中做的一部分工作，它们解决了内部的一些需求，也是实际经验，希望对大家有所启发。

　　开始之前 首先感谢肖总、浩宇、victor等朋友给予的大力支持，感谢群友、技术爱好者的围观。

　　很荣幸有这次机会来与大家做这个分享。

　　提纲：

　　1. IaaS Architecture

　　2. OpenStack Deploy & QOS

　　3. Multiple Regions

　　4. LeTV LBaaS

　　5. 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. 访问不同的集群，用户需要登录不同的 IP

　　3. 运维难度增加

　　4. 维护 H 和 I 版本的 Keystone 和 Horizon

　　随着集群数量的不断增加，上述问题将显得越发突出，于是我们采用了 Multi-Region 方案，把这些集群做了统一的管理。

　　部署方面， Keystone 和 Horizon 全局唯一，其中 Keystone 部署在公网，从而能够被其它服务访问，Horizon 部署在内网，从而能够访问其它集群。这是大概的分布图:

　　

 

　　LeTV LBaaS

　　LeTV 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&A

　　1.为什么没有使用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性能和稳定性都不错。