峰会的第三天，来自 RedHat 的工程师、Telemetry PTL Julien Danjou 分享了本次项目的最新动态，介绍了 Gnocchi 最新优化后的架构，积极解决 Telemtry 部署水平扩展和性能的限制，对比之前的Boston峰会演示 Telemetry 5000 VMs 的测试和P版本10000+VMS优化后的测试。同时给出了 P、O、N 版本对于 Ceilometer 和 Gnocchi 的调优方案。
澳大利亚悉尼当地时间 11 月 6 号上午 9 点，第 16 届 OpenStack 峰会在悉尼国际会议中心盛大开幕，来自全球 52 个国家 2300 余名与会者，将就以 OpenStack 为核心的开放基础架构相关技术和商业实践展开为期三天的讨论，本文为第三天的讨论内容之一。
1. Telemetry 大规模环境测试
Telemetry 在推出 Gnocchi 项目希望积极解决 Ceilometer Backend 大量数据存储和相应缓慢问题，然后随着 Gnocchi 项目落地生产， Telemetry 在实际开发仍让需要面对许多陷阱和瓶颈。
在测试中，JD（Julien Danjou），通过在相同环境对比 5000 VMs 与调优后于10000 VMs性能参数做了对比。
测试使用的网络拓扑图：
测试中，通过一次性创建多个虚拟机，等待相同的时间段在操作多次， 通过段时间内创建的 Gnoccho measures 和 Metric 观察计算/控制/存储节点的cpu/memory/disoIO 等参数。
控制节点CPU使用率测试结果来看，Gnocchi主要是计算型服务，目前在最新的Pike版本上从三控环境的测试结果来看CPU负载分配比较均匀，但是Gnocchi 本身高负载的问题依然是个比较大的问题。
在控制节点磁盘IO测试结果上，每次在一次创建多个虚机，控制节点diskIO 在某一时间点出现一个高IOPS 的冲击波，总而言之，Ceilometer-agent每次抽样轮Polling产生的大量抽样数据或者段时间内大量事件信息都会对控制点带来短时间的磁盘读写压力。
存储节点CephStorage 节点，在整个测试过程保持很高的IOPS，即使我们在Pike 将来aggregation storage剥离incoming measure driver，但是存储节点的写入性能的问题还是有待改善。
2. Gnocch 4.1 最新更新
（1） Gnocchi storage 的拆分。可以从Gnocchi storge拆分出Measure storage提供一种缓存机制，在计量数据（Metric data）在做真正聚合的时候，将这些数据缓存起来然后在做聚合运算，这样就剥离出Measure storage 和 Aggregate storage 这两个Backend。
（2） Gnocchi 内部的计算引擎（measures aggregation）已经完全从Pandas 迁移 Numpy，虽然Pandas 也是基于Numpy做的开发，gnocchi 更想引用Numpy那部分更纯粹的计算能力。
（3） 添加 Gnocchi /v1/aggregates 接口，支持跨 Metric 的 Measure 的数据聚合，功能更加完善。
3. Telemetry 各版本推荐调优方案
（1） 给出 O、P、N 各个版本在 Gnocchi 的调优方案：
（2） 给出 O、P、N 各个版本在 Ceilometer 的调优方案：
4. 未来工作
最后JD总结此次 10000 vm大规模测试，着重阐述目前的测试结果并不能代表Gnocchi 能够真正能够面对大规模的生产环境应用，同时 Gnocchi 仍然有许多可以提升的空间，比如降低 Gnocchi Storage 的 Workload，缩短 Gnocchi API 的耗时问题，完成对于 Swift 和 File 等 Backend driver 的性能测试等。
感谢 EasyStack 工程师 发自悉尼现场的报道
投稿邮箱：[email protected]