前言：
- 来源：https://wiki.openstack.org/wiki/Summit/Kilo/Etherpads#Ops
- 不一定翻译准。由于是在summit上随手写的。
- 重点关注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来部署server和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台物理server。通过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项目能够做到在物理server上部署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
本文转自mfrbuaa博客园博客，原文链接：http://www.cnblogs.com/mfrbuaa/p/5274812.html，如需转载请自行联系原作者
