-- linux爱好者，业余时间热衷于分析linux内核源码 -- 目前主要研究云计算和虚拟化相关的技术，主要包括libvirt/qemu，openstack，opennebula架构和源码分析。 -- 第五届云计算大会演讲嘉宾 微博：@marshal-liu
分类： 云计算
2016-02-10 13:40:59
演讲1：大规模openstack环境中的性能数据分析 - 单region 1000个物理节点公有云环境
performance analysis in large-scale deployment - a single thousand-nodes cluster.
投票链接：
关于大规模openstack环境部署的性能瓶颈问题，众说纷纭，莫衷一是，比如：
（1）道听途说1：nova scheduler默认单进程，所以绝对是个性能瓶颈，顶多能抗住几百物理节点规模下，几百并发的请求，这里的”几百“又有众多版本，有人说300，有人说500，有人说绝对不会超过1000.
（2）道听途所2：大规模环境下，最大的性能瓶颈在消息队列和数据库，尤其ceilometer对消息队列和数据库造成的压力。
（3）道听途说3：听说某公司部署了1000规模的环境，在1024并发压力测试下，完全没有问题。
于是对各种道听途说的只言片语，很多人给出了不同的优化方法，但是从未有真实的测试环境和详细的测试数据，让openstackers能够通过测试数据来窥探大规模openstack环境下，真正的性能瓶颈所在，并根据测试场景和测试数据给出可参考的大规模环境下openstack的部署架构。
本演讲通过中国移动在公有云单region 1000个节点规模（30个控制节点，650个计算节点，250个存储结点）的部署架构和测试数据来论证大规模环境openstack真正的性能瓶颈所在，详细的优化方法和验证后的大规模环境参考部署架构。
演讲2：深入分析“有状态”应用向dcos平台迁移实践
dvie into the migration of stateful application to dcos platform - the practice in china mobile
投票链接：
伴随着docker等容器技术的流行，数据中心操作系统（dcos）必将在2016年蔚然成风，引领传统应用向容器化、微服务化的架构迁移。传统云平台的两大难题：基于iaas的混合云和应用粒度的弹性伸缩，得益于dcos架构的优势有望得到根本解决。
本演讲基于移动大云的dcos的架构，详细分析了“有状态”的应用容器化、微服务化以及向dcos平台迁移过程中碰到的问题，并针对一些比较普遍的问题给出了详细的解决方法，完整的展示了移动大云dcos平台的软件栈组成，企业级应用对dcos平台的要求以及dcos平台的参考架构。
there are always rumors around nova scheduler. like "scheduler can handle at most 1k nodes without problems" or "i don't believe scheduler can handle so much requests using only one tiny process". some would prefer to launch couples of scheduler instances to multiply the schedule throughput, but still others might worry about race conditions and decision conflicts that could outweigh the benefits. cloud users are interested in the deployment strategies to maximize the schedule performance, and developers are curious about the mystery of race condition and its performance impact. guesses and speculations are everywhere without evidences. so let's do some experiments and let data do the talk!
what is the problem or use case you’re addressing in this session?
when deploy openstack, it is very hard to predict how good a single nova scheduler instance can handle the coming requests. and when the single scheduler is saturated with requests, there is also no evidences that running multiple schedulers can mitigate the situation.
most developers are still not sure whether scheduler has been implemented to reach the performance design goal(i.e. 1k nodes but without specifying the overhead of requests).
this session is trying to answer the above questions by analyzing nova scheduler under various scenarios.