前言：

1. 来源：https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Ops
2. 不一定翻译准，因为是在summit上随手写的。
3. 重点关注Ops Summit，其内容与实际生产环境密切相关。

OpenStack Ops/Design Summit - 2014-11-04 Record

1. Top 10 Pain points from the user survey

1. Neutronclient没有文档

2. ML2没有文档

3. OpenStack HA还没做到zero-time恢复

4. L3 HA还有Bug

5. oslo.messaging和RabbitMQ还有Bug

6. 数据库重连问题

7. RabbitMQ异常恢复问题

8. 不是所有的OpenStack服务都支持HA，比如Heat就是单点

9. Ceilometer在生产环境下不可用：

（1）SQL作为Database，没法在生产环境下用

（2）MongoDB，也同样，这个问题是欧洲原子能机构在用Ceilometer时发现的，MongoDB有很严重的集群扩展性问题，目前的最佳实践就是用HBase，扩展性较好。

（3）Ceilometer API性能很差，我们使用elasticsearch来保存payload

10. 数据库读写分离问题

11. neutron.conf如果全部使用默认值，基本不可用

12. Keystone：

（1）与LDAP和Windows AD的整合，没有文档

（2）v3没有文档

13. Nova Cells需要提高优先级维护

14. Python库依赖更新太快

15. Neutron：

（1）默认配置不精确

（2）数据库升级脚本无法正常使用，Schema变化大

（3）Openvswitch-Agent重启会导致所有Flow重新配置，导致网络中断

（4）无法删除namespace（内核问题）

（5）某些组件无法支持HA，目前是lbaas-agent

（6）DVR还没能被理解

（7）DVR使南北向性能变差

（8）Neutron需要Cell

（9）Neutron需要AvailabilityZone

16. 文档：

（1）API文档无法反应最新的变化，导致不可用

（2）一些Nova Extensions没有文档

（3）新的项目文档找不到

（4）ML2 Plugins文档

（5）Keystone v3文档

17. 各个发行版的目录结构不一样

18． API Extensions太多，最好有一套完整的API说明

19. Horizon：

（1）无法提供所有功能

（2）UI Team不完整，经常变

（3）无法为VM指定IP地址

（4）Release Note内容不咋地

（5）不要在doc不完整的情况下给+2

（6）在Gerrit里，提供一个docimpact-created的标记

2. What is the best practice for managing ‘pets‘?

1. pets和cattle的比喻，有人接受不了

2. 如何运维长时间运行的单个VM？

（1）讨论帖：

http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposal/

http://lists.openstack.org/pipermail/openstack-dev/2014-October/048338.html

（2）自动撤离功能可以实现，但无法生产使用

原因：

nova中VM的状态还不完整，无法反应VM当前的真实处境；

nova没有稳定的检测节点状态的机制；

nova不支持fencing！

（3）现在很多生产环境下的实践都建议统一用Pacemaker来管理OpenStack服务，但好像没人用它来管理nova-compute？

（4）需要哪些环境参数来提供给HA软件？

（5）OpenStack到底支持HA到什么程度？

（6）外部的部署工具很有用，但是目前运维的人都希望OpenStack至少能提供一个基础工具来实现。

（7）在VM中，提供一些访问OpenStack服务的工具，比如将数据导入Swift或Cinder或Trove。

（8）Nova提供了watchdog的功能，可以用来支持VM HA。

https://wiki.openstack.org/LibvirtWatchdog

只支持Linux VM。

（9）如果有一些长时间运行的VM拥有比如PCI passthrough这样的状态，如何迁移？

或者运行的音频解码应用、加密服务等。

（10）目前迁移或撤离功能，无法指定hints。

（11）给用户的忠告：

当前的OpenStack完全不支持生产环境下的VM HA，需要直接告诉客户，VM的HA自己在应用层面去配置。

需要让User社区来帮忙编写最佳实践。

3. Distributed Virtual Router - finally neutron HA

1. 基于DVR的VM迁移问题

2. 需要HA测试

3. DVR会让FWaaS、LBaaS和VPNaaS失效

4. 我能使用类似nova network-create --multi-host=T这样的命令么？

5. SNAT的性能问题

6. Neutron支持AZ的问题

7. 默认的网关IP地址是什么？回答：每个Subnet的第一个IP地址

8. Backporting频率太低

9. DVR最大的规模能达到多少？

10. 能否在社区建立一个运维实验室，做一个真实的集群开放到互联网，让大家学习和调试。

4. How do we fix logging?

OpenStack的日志没做好，只有打开Debug，才能看到想要的。但是如果Debug关闭，会仍然写入很多无用的数据。这样数据很难被调试所用。

1. HAProxy的日志，我需要它记录心跳，但它却记录请求，请求其实对运维没有多少作用，运维关心的是心跳正常。

2. 不同项目有不同的日志标准，汗。比如，Debug等级的日志不建议生产环境下开放，是因为它会记录用户的身份和认证信息，这个是安全漏洞，没有必要写入Debug日志。

3. Duncan和一些人非常烦恼，OpenStack会记录“我有一个HTTP请求啦”以及“我收到一个RPC消息啦”这类的日志。（太多，而且过滤麻烦，连实际的内容都没有？怎么调试？）

4. python-glanceclient的日志基本没用。

5. 我比较想要dynamic logging这个功能能够实现，类似下面的代码：

https://review.openstack.org/#/c/86357/

虽然没实现好，但是很有用。

6. 最好直接打印Traceback，而不要擅自格式化，很难看。

7. 最好所有的服务能使用Apache Log格式；最好能通过日志就能发现问题，为调试和修复Bug做指导，而不是一定要重现；经常会有修改了日志导致测试不过（因为很多测试需要判断正确的日志格式和内容是否写入）；一个例子是：为什么nova-scheduler不能输出正确的日志来告诉，为什么调度会失败（当前nova-scheduler输出的日志大多无用）。后面有人插话说，nova-scheduler的Bug，因为日志的等级搞错了，正在review。

8. Nova Bug，ssh的日志内，无论IP是多少，一律写成了localhost。

9. 日志可读性太差，只有开发者看得懂。

10. 开发相关：如果捕获了一个异常，但还想抛出另一个异常，那么需要重新抛出之前的那个异常。

11. oslo.messaging为日志标准化做了贡献。

12. python-neutronclient输出日志太多。

13. 一些日志仅仅说明了已经做了哪些事，但是没有说明应该要做哪些事。

14. dynamic logging的讨论，忽略。

15. 希望未来能做的事情：

（1）oslo.log能做好

（2）Reviewer要去咨询终端用户，如何来提供好读的日志。

（3）日志中能提供一些指导性的意见，比如哪些参数没有调好才导致了这个问题的发生。

16. 日志你会如何用？

（1）保存一段时间后删除

（2）错误分析用，通过logrotate处理

17. 跨项目的请求聚合：这个问题一共讨论了3年，但还是没人去做。oslo准备利用request-id来实现，有些bp的讨论了。

18. dynamic logging：

（1）能够支持运行时直接调整日志等级，便于在线调试

19. 建议将Debug日志输出到特定的地方做rotate，这样帮助很大。

回答：这个功能可以通过配置实现，logging配置是Python本身就有的功能。

5. Architecture Show and Tell

Godaddy的故事：

1. 不用cinder和swift，计划用cells

2. 数据中心网络架构是：Spine&Leaf

3. 不用floating IPs

4. 使用Neutron

5. 过去在Open vSwitch上出过事

6. 东西向流量需要关注

7. 用了2个镜像

8. 对每个内部团队，提供定制的镜像

9. 本地磁盘

10. 当前正在做Ceph和Swift的部署

SWITCH的故事

1. 瑞士的学术研究网络项目，社区云

2. SaaS平台，使用ownCloud来做网盘

3. 使用Ceph

4. 使用Foreman来部署服务器和Puppet

5. 使用Ubuntu Linux

6. 不用Swift

7. 建议使用MTU=1600，确实可以工作

8. 在H版本的升级，基本就是毁灭

9. 使用主机聚合来管理VM

麻省理工学院CSAIL实验室的故事

1. MTU=9120

2. 从E版本开始测试OpenStack

3. 使用Ubuntu 12.04

4. Keystone、Glance、Nova、Ceph，实时迁移

5. 临时存储、Glance都在Ceph上

6. 300TB，6 OSD节点

7. Jumbo Frame能提升性能

8. 迁移临时存储到Ceph，参考：

https://blueprints.launchpad.net/nova/+spec/use-libvirt-storage-pools

欧洲原子能机构的故事：

1. 上博客：http://openstack-in-production.blogspot.fr/

2. 他们从2011年C版本开始测试OpenStack。

3. 他们第一次完成G到H的平滑升级：

经验之谈：http://openstack-in-production.blogspot.fr/2014/02/our-cloud-in-havana.html

4. 升级到了I版本，blog会发布。

5. 正在测试：hypervisor的升级

6. 升级工具欠缺

7. Redhat系的OS，如何从6升级到7？

8. nova-network如何升级到neutron？能忍受30秒-5分钟的断网，也能忍受一个一个用户迁移。

9. client包升级？

10. 升级的时候，第一个目标是Ceilometer，因为它的代码更新最快，直接用trunk就好了。

11. Backport肯定是需要的，但目标是能够紧跟release的周期。

12. 让puppet来做升级，写模板。

13. Qemu如何从1.x升级到2.x？

14. 使用社区的puppet模组，还是自己开发？

15. 如何处理Client曝出的deprecation？

16. 重制RPM并往里增加patch？还是安装标准RPM，然后再脚本升级代码？

17. Tempest用了么？

18. 如果组件跑在HA状态下，对升级是否产生新的挑战？

19. 用了6个小时时间升级了3000+的VM环境，需要停止API服务，这样才能保证DB的一致性。

20. 1个OpenStack集群做到了3200台物理服务器，通过nova-cells实现。

eBay的故事：

1. 花了2个月的时间来研究如何从E升级到F。

2. 在几个小时内，为千台VM做了保护措施（应该指备份）

3. 2013年11月止，有多个独立的云平台。

（1）F版本跑nova-network，G版本跑quantum

（2）有些用RHEL，有些用Ubuntu

（3）网络架构不同

（4）Puppet模组不同

（5）所有都不同！

4. 新的架构：

（1）每次全新的部署作为一个AZ

（2）使用catalogue

（3）H版本合适

（4）一整套完整的拓扑

（5）一步步完成升级

5. 如何升级？

（1）状态维护问题？

（2）每个独立的云平台所运行的服务也都不同

（3）6-8小时完成F升级到H，还花了多个星期的时间来测试

（4）周六早上8点开始升级

（5）关闭控制面的服务

（6）部署新版本的控制面

（7）导出数据库

（8）升级数据库，并检查错误

（9）增加一些空的计算节点，测试是否错误

（10）升级其它的计算节点

6. 如何从nova-network迁移到neutron

（1）一定会断网

7. G版本到H版本的升级：

（1）步骤和之前一样

8. RabbitMQ没问题

9. ElasticSearch会错误，因为日志格式改了

10. 配置文件更新，比如nova-compute，需要每个检查

11. 数据库升级

12. 丢掉了千台VM

13. 多个cells

6. What do we want from containers/docker?

1. Container是一等公民

2. 目前有三个方向上都在做着：

（1）Nova有多个驱动支持：libvirt-LXC（不合适生产环境部署），nova-docker（位于stackforge上）。

（2）一个项目叫Magnum，提供Container as a Service API。

（3）nova-compute-flex，已经可以跑LXC container了，它支持社区标准的LXC接口，默认跑的是unprivileged containers。

3. 值得注意的是，nova-docker driver不支持在同一台计算节点上同时部署VM和docker container，这个需要修改大量代码。

4. Magnum项目并不会绑定在docker上，希望支持其它的container技术。

5. Magnum agent最好能支持多个发行版，比如Trove agent目前貌似只支持Ubuntu上跑。

6. 支持多租户

7. 支持迁移

8. 是否会让Heat来通过Magnum部署docker应用？

回答：这个在ansible的session上有提，我也希望我的devstack能被docker所替换，但是cinder无法工作在container环境，因为Kernel不支持在namespace里跑iscsi，这个是netlink模块导致的错误。

9. 需要考虑container级别的亲和力调度问题，也许和Gantt项目有关。

10. 两个场景：docker in docker和docker in VM

（1）Nova创建docker，然后用magnum在docker中创建docker应用

（2）Nova创建VM，然后用magnum在VM中创建docker应用

（3）通过nova-docker项目可以做到在物理服务器上部署docker，但如果我创建了一个nova实例，不管是VM还是docker，然后我在其中用magnum部署docker，他们需要新的IP地址，如何处理？

11. 是否需要新的镜像管理机制来管理docker镜像，或者扩展下glance？

（1）glance已经支持处理通用的镜像。

（2）是否可以利用docker-registry？

12. Docker网络管理需要考虑

13. 为什么magnum需要agent？Heat就能做。

14. magnum最好优先支持LXC，而不是docker，因为docker是一家公司控制的技术，而LXC才是社区真正在做的事情。

7. Ops High Availability - How do you do it?

1. nova-consoleauth只能跑一个？

（1）没这回事，通过和memcached结合，可以跑多个

（2）目前nova有一个bp正在完整地支持consoleauth跑多个，还没实现

2. AA或AP

（1）数据库，如果要用多主Galera集群，还存在SELECT FOR UPDATE的问题，没法做。

（2）RabbitMQ可以实现多主集群

（3）AMQP：如何在AMQP节点间实现复制exchange？

回答：本来就支持集群模式

3. Keystone

（1）在多区域环境下，使用分布式的认证数据库，每个Region有单独的Token数据库，Heat会出现问题，如果你没实现在多个Keystone服务间复制Token的话。

（2）以上问题可以通过PKI和memcached的部署来解决。

4. RabbitMQ

在HA部署下，RabbitMQ不会重连，这个是已知的Bug。但是这个问题，可以通过部署HAProxy来实现，解决了RabbitMQ没有心跳和重连的问题。

5. MySQL

（1）Galera集群

需要修改innodb_lock_time，保证集群间网络的时延极低，然后把这个参数调节成1秒或2秒。

6. 在线迁移

（1）Ceph、NFS、XenServer、libvirt block-migration都有人用过。

（2）libvirt block-migration有问题：迁移时间和磁盘利用率有紧密的联系，如果非常高的迁移频率，会导致迁移永远不会结束。

7. LBaaS HA如何实现，Neutron没有做？

（1）自己使用keepalived

8. Pacemaker + HAProxy和Keepalived，用的人都很多

9. HA很有用，但是在服务升级的情况下，或者集群中多个不同版本的实例的跑，这样就需要自己去处理了。

8. Ops Storage Summit

1. 排名：

（1）Ceph

（2）Swift

（3）Cinder: LVM

（4）Gluster

（5）临时+本地

（6）Solidfire

（7）Ceph OSD，并且把日志放置在FC SAN上。

2. 最大规模

（1）Ceph集群从1PB升级到5PB

（2）Swift把1+PB的数据分布到不同的地点

3. 硬件

（1）超微 72 Driver Chasis with 6TB hard drivers

（2）EMC VNX 5300

（3）超微 4U 36 drivers

（4）超微 3U 18 drivers

（5）中兴 KS3200 2U 12 drivers

4. 监控和统计

（1）Nagios

（2）Shinken（Nagios的修改版本）

（3）Graphite

（4）check_mk + icinga

（5）Ganglia

（6）Calamari

（7）Zabbix

（8）Splunk for gluster

5. 复制比例

（1）2x

（2）3x

6. 多区域复制

（1）恢复距离：10km

7. 在线迁移经验分享：

（1）H版本，vFAT磁盘格式

（2）KVM虚拟机

（3）--block-migrate，config drive配置成vfat，boot from volume可以在线迁移成功。

（4）迁移失败比例很高，和后端存储无关，Nova实现的Bug。

（5）需要至少10Gbps网络

（6）需要研究下libvirt的支持，比如migrate-setmaxdowntime

（7）状态重置，也有10-20%的错误率

（8）目的Target有问题

（9）Ubuntu Trusty的Qemu

（10）没有升级Qemu

（11）Qemu版本会影响在线迁移，不能从1.0迁移到2.0的环境

（12）需要支持rolling upgrades

OpenStack Summit Paris 会议纪要 - 11-04-2014