标签：des style blog http io color ar os 使用
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）等等
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。
1. 需要升级指南
2. 架构指南，这份文档并没有实际的用途，很多地方说的很模糊，需要把一步步如何配置的详细记录，不能算是一个Cookbook或How-To，而是对于初学者的补充。
3. 运维指南，需要添加AD集成。
4. HA指南，需要添加测试流程和结果。
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。
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需要扩展来监控物理服务器。
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 Summit Paris 会议纪要 - 11-06-2014
标签：des style blog http io color ar os 使用
原文地址：http://blog.csdn.net/cloudtech/article/details/41089253
