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

Ops/Design Summit - 2014-11-06 Record

1. Neutron Kilo Lighting Talks

1. MPLS VPN

(1)Brocade提出的一个数据中心互联方案

(2)单个租户网络可以扩展到多区域的数据中心

(3)无缝迁移VM的负载

(4)提出一个MPLS VPN Service的API Ext和对应的Model:

Attachment Circuit:租户网络内部的一个逻辑接口

MPLS LSP Tunnels:在多个MPLS VPN服务间共享

Provider Edge Routers:边界三层设备,可选的

2. IPv6的支持

3. L2GW Support

(1)二层逻辑网关服务,实现在租户网络内部接入物理网络设备或物理服务器。

(2)基于Neutron Service Plugin,通过OVSDB配置外部SDN交换机或者Open vSwitch。

4. Service VM & L3 Router VM

(1)在Neutron中支持基于虚拟机的网络服务链功能

(2)已经有了一个L3 Router VM的参考实现

5. 100个物理节点的Neutron验证

(1)用Rally作为测试框架,配置测试用例

(2)使用Iperf测试网络性能

6. 还有一个课题是说明提交代码过程中的一些注意事项:

(1)改空格、改格式

(2)改不影响阅读的拼写错误

(3)说明模糊

(4)几个bug fix合在一个commit里

(5)没有launchpad bug ID

(6)等等

2. Log Rationalisation

1. 这个主题是讲OpenStack日志内容的设计

2. 时间戳:都是基于UTC

3. 时间格式:Year:Month:Day-Hour:Minute:Second (Padded 4:2:2-2:2:2)

4. 是否需要根据国际标准走,比如Syslog RFC 5424

5. 如何隔离字段?空格?Tab?

6. 日志内容应该包含:

- time
- repeat count
- message payload
- error id
- where is this coming from:操作对象的意思
- category:日志等级
- Add Hostname and Locator to the format
- What about cell/cluster/deployment zone ID?

7. Payload里需要添加Request-ID

8. 日志里面的错误,或者描述不清,可以提到launchpad,标记low-hanging-fruit。

3. Documentation

1. 需要升级指南

2. 架构指南,这份文档并没有实际的用途,很多地方说的很模糊,需要把一步步如何配置的详细记录,不能算是一个Cookbook或How-To,而是对于初学者的补充。

3. 运维指南,需要添加AD集成。

4. HA指南,需要添加测试流程和结果。

4. Telco Working Group

1. 建议把目前社区的NFV Subteam可以整合到一起工作。

2. 这个工作组的目标是:

(1)技术:提出扩展性和性能方面的要求并分析如何解决。

(2)生态:与解决方案供应商、设备商等建立合作关系,参与ETSI NFC和OPNFV组织。

(3)文档:编写参考架构、白皮书和用例。

(4)市场:沟通、内容编写、活动支持

3. 讨论工作组的名字、目标、生态系统的建设,吸引更多的专家,没有明确。

4. 如何与OpenStack的各个项目沟通合作。

5. 需求:高性能、高可靠性、高扩展性……

6. 需要有针对性的外部测试

7. 技术研讨范围:

(1)电信运营商的需求,不是企业的需求

(2)基于OpenStack部署电信应用时的各种NFV需求、性能、稳定性的问题。

用OpenStack来实现所需的分布式架构。

OPNFV和OpenStack的交接点在哪?OPNFV不会创建另外的分支,而是希望让自己成为OpenStack upstream的一部分。

OPNFV有代码库,Stackforge更多用来管理哪些与测试相关的内容,而不是实际的功能代码。

我们需要专注在核心的点上,因为人力资源有限。

(3)专注在电信运营商的用例上。

(4)除了性能外,应用编排也非常重要。

Orange、DT这些运营商都有这方面的强烈需求。

需要一些Nova、Neutron方面的BP来实现。

(5)让Telco的运维人员参与进这个组?让OpenStack开发人员进入Telco领域?

一些Telco的需求,未必能进入各个项目的计划中。

(6)吸引Telco的人进入项目讨论,如果某些功能确实非常重要的话。

(7)让更多的参与者进入这个工作组。

8. 需求研讨:

(1)不管NFV还是non-NFV,我们能否准确获得Telco的需求?

(2)有个关于应用编排的讨论,与NFV无关。

(3)与OPNFV如何交互?

9. 总结:

创建这个组,让更多的运维人员进入讨论。

10. 应用编排相关:

(1)让提出的BP落地。

(2)将ETSI的NFV需求转化为OpenStack的技术实现,需要有Telco的人员来将这些电信需求翻译成OpenStack社区的需求。

11. 合作对象:

(1)ETSI NFV

(2)OPNFV

(3)ETSI MEC

(4)Open Compute Group

12. 如何协作?

(1)IRC:1400 UTC Wednesday或1600 UTC Thursday

(2)Mailing List:ops或dev

(3)在Wiki上创建新的Member Page

(4)工作内容:

定义用例;OPNFV参考架构;当今存在的最佳实践,将NFV用例运行到云基础架构上;

下一步,定义工作组章程和目标;Telco运维人员提供用例,最好是Public,不要NDA的;安排工作组会议;对此感兴趣的组织提供用例(有时间表);推荐一些开发人员进入这个组,可以做一些PoC。

5. Monitoring

1. 运维脚本Repo:

https://github.com/osops/
https://github.com/osops/tools-monitoring

2. Rally,这个工具现在已经够用了。

https://wiki.openstack.org/wiki/Rally
https://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/

3. HP Public Cloud的经验:

(1)使用Icinga:进程状态监控。

(2)拥有一个小团队负责建设功能测试库,负责端到端的功能测试。Tempest不合适用来做生产环境的测试,无法分布式到数千个节点,处理错误也不行。还没正式发布,希望能够开源。

(3)功能实现上还存在一些难点,特别是测试产生的负载影响环境什么的。

4. 性能监控 vs 可用性监控 vs 测试

5. API层面的入侵检测以及DDOS防护?没答案。

6. 需要一个在所有组件内部都统一的事件ID。

7. 可用性监控工具:

(1)https://github.com/osops/tools-monitoring

(2)Nagios/Icinga/Shinken + Thruk + MK Livestatus

(3)Nagios for OpenStack:

nagios-plugins-openstack:http://packages.ubuntu.com/search?keywords=nagios-plugins-openstack

nagios/icinga scripts:https://github.com/cirrax/openstack-nagios-plugins

(4)Centreon

(5)Xymon

(6)Zabbix

(7)Zenoss

(8)Monit

(9)Sensu:

https://github.com/sensu/sensu-community-plugins/tree/master/plugins/openstack

(10)Consul(Gossip + Health Checks)

(11)StackTach:https://github.com/rackerlabs/stacktach

(12)Monasca:https://wiki.openstack.org/wiki/Monasca

(13)https://github.com/stackforge/monitoring-for-openstack

(14)Rally

8. 性能监控工具:

(1)pnp4nagios

(2)ganglia and slow

(3)cacti

(4)Munin

(5)netcool

(6)DataDogHQ(pay-per-host)

(7)CopperEgg(pay-per-host)

(8)Observium

(9)Etsy skyline and oculus

(10)Collectd

(11)statd

(12)Backends:OpenTSDB,Graphite,InfluxDB,Rally,Diamond

9. 测试工具:

(1)Rally,Benchmark-aaS:

有时候需要关注它创建的测试对象没清理干净。

(2)Tempest

不会在测试完毕后清理测试对象。

10. 日志如何处理?

(1)保存是重要的。

(2)需要保存很长时间,甚至一直。

11. 如何获得监控需要的数据?

(1)SNMP

(2)NRPE

(3)Connsul agent

(4)Ansible / SSH

12. 如何发送告警?

(1)Email to SMS

(2)SMS

(3)Email

(4)Jabber / XMPP

(5)IRC

(6)NOC Console

(7)事件、工单管理系统(ServiceNow,RequestTracker)

13. 日常检查任务是否会影响性能?

(1)肯定会,但需要测试,最好影响力在5%以下。

(2)每隔5分钟,检查一个节点;每隔1分钟检查,如果一些检查很关键。

14. 有人用Host Aggregates?如何监控?

貌似在场没人用。

15. 在一些旧的系统,我们需要知道大量的认证信息来开始维护集群。

(1)Puppet、Chef可以管理认证信息。

(2)如何自动发现需要被监控的实例?

回答:我们使用nova instances metadata来定义监控需求。

(3)如何对集群分类,用来自动进行服务检查。

16. 如果有天OpenStack所有的服务都能汇报OK,会如何?

(1)很好,可以用来进行上层的健康检查。

(2)会很复杂,特别对于大型系统来说。

(3)必须是端到端的检查。

(4)可以重用HAProxy?

(5)在日志中可以被容易地过滤,比如设置成DEBUG。

(6)需要一个类似于ping的功能来检查API和其它服务的状态。

17. 有人需要statsd?

(1)只有Swift使用了。但是有人说,这个工具很差,会影响原本生产环境的正常运转。另一个人说,用了很长时间没出事,对每个服务都需要监控。

18. 监控分类建议:

(1)传统的服务监控

(2)租户功能的监控

(3)云监控服务

19. 最佳实践:

(1)用户操作需要监控。

(2)扩展性?

(3)需要清理数据库。

(4)功能测试

(5)监控进程,运行一些OpenStack CLI命令来检查。

(6)比如:check_keystone_token.sh,github

(7)监听所有的notifications

(8)自动测试安全组是否配置正确:通过bash一个个执行iptables测试。

20. Ceilometer需要扩展来监控物理服务器。

6. Large Deployments Group

0. 在场的50人都是来吐槽的,还偶尔看到了几个香港认识的家伙。

1. Docker Stack,RAX的私有云用了LXC容器来部署OpenStack,看上去还不错。

2. Nova Cell v2的BP是焦点,话说v1做的太烂。

3. 需要能支持大规模的测试,因为很多时候需要在大规模的时候才能触发Bugs。

4. 部署文档和架构文档需要增加与大规模应用相关的章节。

5. 如何参与社区?

(1)标记Bug。

(2)参与Bug修复,多留言。

(3)将重要的Spec贴到ops邮件列表里。

(4)在Superuser上多讲案例。

6. 吐槽大会开始。

(1)数据库问题:nova instance table。

(2)数据库升级。

(3)没有LTS。

(4)计算节点管理不完整:

主要是状态管理和维护(libvirt和nova-compute不一致);没有API可以重置VM的状态。

(5)Cells:Neutron不认识;调度器不认识;Cell RPC返回的值不一致。

(6)部署验证:如何验证?是否可以用Rally?

(7)网络问题:

8k以上的VM会占满交换机TCAM,如果没有SDN方案介入,大规模跑L2 Fabric不可行。或者干脆换成L3 Fabric架构。

网络分区问题:nova的分区没法识别,包括Cell,AZ等。

Nova-network到Neutron的迁移还是问题。

MPLS?

给特定的数据流打标签(Flavor,Tenant等)

(8)调度器存在Race condition。

(9)Ceilometer问题,包括MongoDB无法扩展,需要用HBase。

(10)日志:Request ID不一致;日志全部打开才有意义。

(11)Nova-conductor优化。还不清楚具体的细节,但是nova-conductor确实存在扩展性问题。

(12)性能测试,用Rally。

(13)Cinder-volume问题,并发删除Ceph上的卷会导致cinder-volume进程卡死并占满CPU。

(14)所有OpenStack API进程均存在的问题:大量并发导致操作失败,原因是Python GIL和C库。

你可能感兴趣的:(云计算,OpenStack)