OpenStack 更新

问题导读
1、你如何看待OpenStack的软件和硬件发展？
2、 OpenStack有哪两大用得炉火纯青的技术基石？
3、openstack有哪些性能挑战？








趁着OpenStack Paris Summit余热未过，在此梳理一下会场上的OpenStack Vendor和一些 Startup的状态， 探讨一下它们的市场措施，技术进展， 以及分享一下关于OpenStack的问题思考，供各位OpenStacker参考，谢谢！


Quanta 和 NEC 主打服务器

服务器、存储和网络设备提供商Quanta  这次主要推其基于 OCP 标准的 Rackgo X机柜解决方案，采用模块化单元设计，目前支持四种服务器类型，分别是：两种 Microserver，一种 JBOD 和 QuantoMesh的交换机。

硬件厂商NEC 这次主要推出 Micro Modular Server ，很吸人眼光，2U 机器带 46 个节点，节点可以是使用 Atom C2750/C2730 和 4个 DIMM 插槽一个 SSD 插槽的服务器节点，这样每节点可以支持 32GB内存。也可以是一个2.5寸的SATA 盘，这样可以有23个服务器节点和23个 SATA 硬盘节点：这对于高密度内存服务还是很具有吸引力的。

希捷推IP硬盘

希捷这次着重推 IP 硬盘，目前与 SuperMicro 合作的 Kinetic 存储服务器可以容纳 48TB，使用了12个4TB 7200rpm的希捷盘，每个 IP 硬盘带一个千兆网口，通过 DHCP 来获得 IP，并利用 Kinetic API 进行访问。目前与Swift 已经整合成功，但是本人并没有在用户群中得到相应的反馈。这次 Kinetic API 其实在 Ceph 中已经得到整合，使用KeyValueStore 可以直接访问 Kinetic，但是因为 KeyValueStore 要求支持范围查询使得 Kinetic backend 的实现效果不是很好，所以目前并没有被 Ceph 社区宣传。

Redhat 和 华为: 开源栈与商业栈

Redhat 作为 Linux 和 OpenStack 社区的领军，思路是基于 OpenStack 整个软件栈进行整合和深度定制：推出OpenStack 发行版的同时，在 KVM, libvirt, VM guest OS, redhat storage server甚至内核等等都具有领先的技术和整合能力。与之相反的是华为推出 FusionSphere OpenStack 整合了原来FusionCompute，FusionStorage 和 FusionNetwork 等组件，用原有的私有技术做了一层 OpenStack API 封装，这也是一个不错的另一面 OpenStack 平台。

其他厂商观察：角色变化不大

Oracle 这次也包装了一下 Solaris 11 作为OpenStack 运行环境，同时 Oracle ZFS 作为其存储环境并强调对于 Oracle 数据库的支持。

BIOS IT 是一家 SDS  (Software Defined Storage)厂商，整合了 SuperMicro 的机器，Mellanox 的网口和交换机。

还有诸如 StorPool，CloudFounders 和 Scalacity 等等具有自己私有软件定义存储的小公司，今年已经更少了。

从整体来看，今年整个 OpenStack Summit 参展厂商相较以前在类型和角色上变化不大，仍然有众多 Startup 参与OpenStack 各个部分的插件、组件强化和整合服务。

Ceph成为存储主角

但是变化最明显的是软件存储上，这次 Summit 几乎所有硬件厂商都选择 Ceph作为其主要 Use case，大多数 OpenStack 发行版、云解决方案、软硬一体机等等都选择了 Ceph作为存储后端，这在前几届是没有出现过的。

OpenStack Next Challenge：Ceilometer， Marconi的性能挑战

在今年 OpenStack Paris Summit 的技术交流和讨论会上，能够看到针对第一批 Core 项目如 Nova，Cinder，Glance 和 Swift的讨论已经不多了，这实际上也印证了这些项目的成熟性。众多孵化项目受到了极大关注，以消息队列(Marconi)为例，OpenStack开发者更希望从不成熟和面临巨大变化的项目中得到机会，但是也以 Marconi 为例，OpenStack 在 PAAS上的服务也引起了一些质疑。

众所周知，OpenStack 现有 Core 服务都以管理/控制角色为主，其核心作用组件是后端的如 KVM，Ceph等等，真正参与具体逻辑的目前 Core 项目里只有 Ceilometer，当然其性能也受到广泛抨击。Marconi 这种 PAAS服务相对于 IAAS 服务最明显的就是 API 的使用频率大大提高，其带来的就是性能问题，OpenStack社区目前对于性能并没有一个很好生态环境。

另外，IAAS、PAAS、SAAS这三个的接口多样性是倒三角的，IAAS的软件稳定性、生命周期和一致性要比 PAAS 高得多。而 PAAS 作为更高层接近应用端的技术，其变革和演变频率高得多，能否做到 API统一和稳定是一个问号。



我们环顾整个 OpenStack 已有项目，首先以 Nova、Cinder 和 Glance 为首的成熟项目都是以管理为主，Backend执行实际业务逻辑的方式，Neutron 虽然有实际执行逻辑的部分，但是本质上还是 Management。

第一个独立完成大部分逻辑的应该是Ceilometer，它应该是 OpenStack 第一个严格意义上的 Functional项目，主要承担监控和报警作用。但是实际上对于大规模 OpenStack 集群，Ceilometer的查询效率和收集能力仍然有欠缺，主要体现在 API 的设计和整个查询路劲的实现，API独立于后端存储实现使得基本所有的后端都不能优雅高效的完成存储逻辑，而查询的低效更是成为问题。就目前来说，Ceilometer在使用案例上普遍仍然是 OpenStack 运营方的工具而不是平台用户的 PAAS服务，因此被大家所诟病的效率问题仅仅停留在其存储性能上。

而 Marconi 作为首批直接为 OpenStack 用户提供的 PAAS服务在这次 Summit 上广受关注，目前 Marconi 已经 release 了 API 1.0v，2.0 版本已经在设计草稿中，它采用Store-and-forward 模型而不是 Cut-through 来提供必要的消息持久性，目前第一个成熟的存储后端是MongoDB，而 Redis 作为第二个后端目前因为性能原因更加受关注，基于 AMQP 协议的后端也在计划之中。那么 Marconi的挑战是什么? 仍然是性能。

Marconi 继承了 OpenStack的两大用得炉火纯青的技术基石”Python”和”HTTP”，两者提供了优雅和便利也带来了低效的问题，HTTP协议的复杂性众所周知，无论是客户端还是服务器端对于协议的解析都是消息队列服务的重要延迟来源之一，而 Python更是准实时服务的“噩梦”。作为用户端 PAAS 服务，如果不解决性能问题无疑会让更多人对 Marconi 的实际生产环境能力产生质疑。这次Summit 上，作者从听和交流中大致归纳为以下三点:

1，Marconi Enhance: 在协议上采用 Websocket 提高服务能力，优化 Python 栈实现，后端采用更高效的 Redis ；

2，Management Marconi： 转型成为消息服务管理项目，对接成熟的消息队列服务如 RabbitMQ、ZeroMQ 和其他商用方案；

3， Marconi API Core: Marconi 专注于提供 OpenStack 生态圈的消息队列服务 API，采用与 Swfit类似的方式，Marconi 期望其他消息队列厂商来支持 Marconi API，同时自己作为一个原型系统实现呈现。

这三点其实并不矛盾，但是作为一个 OpenStack 项目，它需要在核心开发者端有一些一致的认识，这样不同厂商才会准确把握其趋势从而进行靠拢。

从Marconi 抽象出 OpenStack三种项目形态

管理类项目: Nova, Cinder, Glance 和 Neutron；

直接作用类项目: Ceilometer, Marconi；

API Core: Swift.

这种方式不太准确和严谨，但权当一种看待 OpenStack 项目的定位方式。因为这个分类可以看到 IAAS

服务由于其稳健的后端软件生命周期和基础性，OpenStack 可以很好的完成管理的实现:少则 3 年，多则 10 年的 IAAS层软件的变革周期足以使得 OpenStack 服务可以很好地应对变化。

OpenStack PAAS :Perfer API to Management

OpenStack PAAS 层服务首先相较于IAAS，其种类就大大丰富，而目前已有的开源实现更是多样化，光 DB 服务就可以报出一个列来。不同的用户对于 DB服务有不同的诉求，由于其紧耦合于用户软件实现，平台服务端势必需要有对应的服务来提供，因此 PAAS 服务如果在 OpenStack端以管理定位去做的话会产生 NN 的矩阵实现。

Marconi 作为消息队列服务实际上逻辑应该相对清晰和简单，因此采用自己重新定义 API的方式，与已有的 AMQP 或者其他商用消息队列服务协议并列，这种方式抛弃实现来说，一方面它使得 OpenStack可以提供自己的服务掌控性，社区能大大提高深度和广度(开发者最爱)，另一方面也给用户使用和普及带来一定难度，一种新的第三方协议对于软件开发者是一个简单的抉择。

当然，从另一个角度来说，OpenStack PAAS 服务如果决心提供 API 或者不做管理定位的话，它的主要工作量可以从兼容各类消息队列服务转移到自己协议实现上，有可能将 PAAS服务复杂性变成 N1 矩阵，但是在面对实际的大规模调用的服务承载能力需要跳出目前 OpenStack 已有框架去实现，Marconi作为“先锋”势必要走出一条高性能 OpenStack 服务框架，与目前的管理框架有着完全迥异的实现。

因此，对于 PAAS 服务来说，管理 API 还是业务 API 并不是一个像 IAAS 层一样清晰，OpenStack社区、厂商、用户和开发者乃至生态系统都会受到项目方向的影响。这对于 OpenStack 迈向 PAAS服务是一个艰难的挑战和抉择，如果对应到 AWS 如此众多的 PAAS 服务，OpenStack 如果要赶上 PAAS服务的步伐和实现生命周期，可能更多的还是取决于服务本身和开源实现和新的实现。

OpenStack 如能较好的平衡目前已有开源实现和自己实现，并且能够像IAAS 端管理框架一样铺平高性能框架(无论是修改目前的协议基石 HTTP 还是语言 Python),PAAS 服务层 OpenStack才可能也才能再现 IAAS 的地位。