OpenStack中国联盟公开课20160105参会笔记

首先是吐槽本次公开课的人真的是很多呀~~~。可见云计算是多么的火爆~。

以下是自己的笔记已经一点小小的想法。希望对大家能有抛砖引玉的作用~，共勉之~。

OpenStack中国联盟公开课20160105

OpenStack与Container的集成  IBM

1. Dock的集群的使用当前存在的主要问题：
   1. 网络问题：

对于跨主机的网络及部署现在还没有成熟的支持。对于container的网络支持可以了解一下 Kuryr Project 项目。

2. 安全问题：

由于Docker/Container是共享Kernel的，所以对于Container之间的隔离都是

3. 监控问题：

目前没有比较合适的监控可以对Container进行比较好的监控，大家都是用的比如zabbix等之前的监控设施。

4. 部署问题：

K8S、MESOS等都在完善中。支持起来的技术要求较高。

2. OpenStack中主要的有关Container的项目：
   1. Nova-docker驱动
   2. Magnum项目

这两个项目有一个比较详细的介绍文字可以参考：

【实战】使用OpenStack管理Docker容器  http://www.wtoutiao.com/p/h9dB6J.html

 

3. IBM的 Container支持：
   1. 支持多租户
   2. 每个用户可以有自己的 Image register
   3. 提供监控及log系统。

 

4. Docker与 LXC：

Docker在1.0前是用的LXC的技术，但是在1.0之后就开始开发自己的DockerEngine了。但是LXC与Docker都是使用的Linux kernel 的 Cgroup。Namspace等技术。

 

5. Kolla项目：

基于自动化部署工具： Ansible。将OpenStack部署在 Docker中，实现HA的一种思路。

简单介绍（来自网络）：

kolla项目是TripleO项目的一部分，聚焦于使用docker容器部署openstack服务。

项目于2014年9月开始，目前发布了两个release。参与贡献者有约14人。是openstack的孵化项目。

在裸金属上部署openstack不是killo项目当前的目标。因此一个用于部署kollacluseter的环境是必须的。

当前，使用heat模板在已经存在的openstackcloud上部署一个Kolla cluster。

源文档 <http://blog.csdn.net/halcyonbaby/article/details/44035653>

 

一点体会：

当前Docker运用到企业的集群中对于企业的技术储备要求比较高。但是在单机使用，提高自动化部署、发布等的应用还是比较广泛的。在IMB的Container支持中实现的多租户及监控、Log系统等也是对Docker应用于生产环境的要求。在OpenStack中可以借助于Keystone及Heart项目，在VM中启Docker可以比较方便的实现。其为每个租户提供自己单独的Image Register也是一个很好的PaaS功能，在企业云平台中亦可以借鉴。kolla项目是一种很好的思路，可以关注。

 

OpenStack之上构建 PaaS    HP

1. CloudFoundry是当前主流的PaaS平台，是Vmware开源给社区的项目。

要解决的问题：

1. 自动伸缩
2. 自动部署
3. 计费（需要自己实现）

2. Helion OpenStak介绍
3. Helion DevelopmentPlatform（PaaS）（基于CloudFoundry V2做的）

 

一点心得：

Hp是基于CloudFoundry实现自己的PaaS平台，如果我们要做PaaS的服务现在看，有三种方式： 1. 基于CloudFoundry去做，2.基于OpenStack的PaaS服务相关的项目来做。 3. 自己实现，以扩展项目的方式基于OpenStack做。

 

OpenStack Murano概念与实践  UMCloud（Ucloud、Mirantis）

   Murano项目类似于OpenStack的应用商店，可以实现一键部署等功能。以及应用的分发。

面向的人群有：

1. 使用者
2. 开发者
3. 管理员

 

应用场景：

   1.应用商店

2. 重复部署的QA、Test等环境。

 

基本概念：

 Environment

 Session

ObjectModel

Package

Environment-Template

 

KeyPoint:

  VM的image中需要有 Murano-Agent，才能使用该项目提供的功能。

Murano Action自动扩展的功能。

 

一点想法：

从现场的讲解及Demo来看。配置起来非常的复杂。而且结合我们的平台实用性并不强。现在看还不算成熟。可以适当关注。

 

携程OpenStack打造私有云 携程

 

1. 主要应用场景是桌面云，用户3000+员工的呼叫中心来节省成本。IT人员通过OpenStack的Console相关API来远程协助解决故障。
2. 现有的Windows2000、VMware虚拟机、KVM虚拟机、裸机等都要纳入管理。
3. 实现VM 1小时SLA（service level agreement）。
4. 对于裸机的管理实现了如下功能：
   1. 自动发现
   2. 自动OS安装
   3. 软件自动配置
   4. 自动切换到生产网段（管理操作在部署网中，部署完成切换到生产网中，通过换VLAN来实现）

 

5. KVM虚拟机带来的挑战：
   1. Windows机器在KVM中的稳定性问题。
   2. 对于 Linux Kenel、OVS、driver等的掌控。

 

6. 实践：

软件的发布，主要是源码发布，对于配置文件纳入版本控制。正在尝试使用Docker

一点想法：

对于裸机的管理，我们的云平台管理系统也可以纳入考虑。对于他们已经感知到的KVM的一些挑战，对于我们的云平台同样存在，值得关注。

 

基于OpenStack的企业私有云实践  lenovo

 

1. 对于少于50个计算节点的OpenStack，建议有3个Controller节点做HA。 Controller节点数量建议： 3、5、7递增。另外对于存储使用的Ceph方案而言，日志盘建议使用SSD盘。 ceph与compute可以部署在一起（即同一主机上）。但是当大于50个节点就可能有性能问题。考虑 ceph与compute分开部署。
2. 多Region部署。对于OS规模较大的环境，可以考虑用多Region的方式部署。每个Region有少于50台的计算，这样可以保证 OS Controller、Compute VM、Ceph等的性能及稳定性。同时Neutron的L3的压力也会小。也会更稳定。

3. Ceph的监控、调优等工作必须做。比如使用的网络 10000M、单独的交换机等。

4. OpenStack对Vmware的Vm的管理是：OpenStack-->Vcenter-->VmwareVM.
5. VM的HA，也就是Compute Node的HA。主要的思路是通过监控去检测 Host的网络、系统、硬件等数据或Log当达到我们设定的阈值之后就调用OpenStack的API将该主机的VM迁出，如果已经宕机，考虑自己从新启动VM。
6. 运维开发实践：
   2. 上图主要是当前的趋势。其中zabbix监控建议使用agent的方式，libvirt的方式可能不准确。saltstack是小型一些的工具。而Murano、Cloudify等则是多云部署工具。

 

一点想法：

  1.其中对于 OpenStack规模的控制，对我们的平台建设有一定的参考价值。我们可以通过测试等方式鉴证该问题。但是应该引起我们的注意。2.对于存储及计算放在同一个主机上的问题。我们也应该在监控系统中进行必要的关注。对于提升及优化我们的云平台有一定的参考价值。自动化部署是我们比较欠缺的地方，我们可以给予一定的关注。

 

 

OpenStack大规模部署实践中国移动

创建一个VM有多少个数据库事务： 200个。

       构建的时候在每个API前都用Haproxy做了LB，但是却在有的情况下成为了性能瓶颈。当同事创建1000VM，每个VM的镜像为1G.那么：1000*1G=1TB流量。10Gb网卡满负荷需要1000s。改用LVS-DR为Glance做负载则能够解决该问题。同事Ceilometer也是用的LVS-DR做的负载均衡。

    数据库框架的性能瓶颈的解决：

1. SSD
2. 主、备
3. 多集群（nova用nova的数据库、neutron用neutron的数据库）。

   消息队列：

     1 RabbitMq在无Ceilomelter项目的情况下，并发1000VM的时候也会成为性能瓶颈。

     2. Ceilomelter用自己的消息队列集群服务。

 

  配置项的准确及调整：

        1.    Keystone的token用uuid还是 PKIZ

        2.   Python wsgi server or apache

        3.    worker数量为多少，默认的是cpu个数，中移动修改为4倍cpu数目。

         4.   RPC timeout设置成多久合适 默认是60s ，中移动增大了

         5. RPC的线程池设置为多少合适

         6.数据库连接池

         7.数据库最大用户连接数

         8.等待块设备的超时时间为多长，中移动增大了。

         9. token的超时时间多长。

         10.选择Metadata-server 还是 config-drive， metadata-server支持热迁移。但是在大并发的时候可能获取不到，比如流表下发失败导致vm创建失败。另外 config-drive有个分支已经支持 vm的热迁移了。可以去调查一下。

 

 监控Ceilomelter

监控项比较多，且频繁的请求token。对于keystone及MQ都会造成很大的压力。所以可以使用UDP而不用MQ，另外由于平凡的存取数据，其使用的数据库MangoDB，很快就会有很大的数据量。导致一些效率及性能问题。需要注意。

 

一点想法：

   我们的云平台由于规模及用户的原因。我们的并发数不会太大，所以我们的环境暂时应该不会有现在的问题。但是对于不同的项目用不同的数据库、负载均衡等想法，我们可以有所借鉴。对于MQ的压力及稳定性\HA等问题，我们应给与必要的关注。如果我们要上Ceilomelter，则他们的经验对于我们有参考价值。

 

OpenStack生产实践   easyStack

1. 操作系统： cent OS 6.5
2. 当计算与存储放在同一个节点上到时候可能有问题。如当VM数量增多的时候，其cpu、memroy的使用会对存储性能造成很大的影响。导致一些存储请求失败、延迟很大等情况。解决的思路可以是：1.内存不超售，预留memory给操作系统及存储Agent、用cgroup绑定VM的CPU、使用软件手段将集中在CPU0上的中断打散等。
3. Neutron的DVR在生产中可能有问题。所以推荐使用VLAN
4. ceph有瓶颈问题。当一个pool中的机器达到一定数量，再增加host无法提升性能。可以考虑多pool的部署形式。
5. zabbix和ceilomelter都集成到了zabbix的展示中。集中做了展示工作。

 

一点想法：

  他们遇到的问题及解决思路对于我们当前的环境有一定的参考价值。因为我们也上了ceph，可能会遇到以问题。我们的Neutron用的DVR，应该在正式上生产之前，对网络的稳定性做必要的更多的测试工作。

 

 

乐视OpenStack部署实践与运维支撑乐视

openstack版本 i版，存储用 ceph。主要采用i版本，然后将需要的新功能merge进i中用于生产。

 

1. API前加Haproxy做负载均衡
2. MQ及database做集群部署。
3. ceilomelter有自己的MQ server。同时也发现了mangoDB的一些问题。
4. 用多Region的方式部署。在登录之后选择，实现跨地域部署。用的同一个keystone服务来做唯一认证。
5. WSDL服务用的服务是http
6. 配置管理工具：从puppet迁移到了saltstack上，因为运维团队觉得简单。

7. 服务监控： zabbix，图形展示用的grafana-zabbix插件
8. 日志管理用的开源方案

经验：

 关掉 ksm，用大页内存， ksm对cpu性能影响较大。

 使用SRIOV来解决性能问题。

 做QoS，限速，主要在硬盘及网络上做。

Top List 也就是监控要做。

一点想法：

   对于管理工具saltstack，我们可以考虑使用。另外 WSDL服务用http可以考虑。日志管理我们可能也需要在我们的平台中去做。现在开源的有比较成熟的方案，包括收集、存储、检索、展示等。QoS我们也纳入到考虑中。

请保留原文链接，thanks

URL：http://blog.csdn.net/zzh_gaoxingjiuhao/article/details/50570980