OpenStack奥斯汀峰会的第4天,在奥斯汀直播前线的小伙伴们相当给力,为大家带来了超多的干货分享。

我们现在讨论OpenStack,不得不提Magnum。Mangum现在应该是OpenStack里边比较热门的和Docker集成的项目。今天关于Magnum开发设计讨论的Session很多。

EasyStack创始工程师王后明从现场带来了一手的消息分享,他表示:“本次关于Magnum的话题很密集,包括Magnum PTL Hongbin Lu、创始PTL Ardian Otto、Core Reviewer Ton Ngo等众多Magnum社区开发者共聚一堂,上下午一共进行了7个话题讨论,涉及到Magnum当前开发过程中的各类待深入讨论的功能点,包括大家关心的容器网络与Kuryr的集成、对Ironic裸机的支持、集群健康状态和资源使用率监控等。”同时,王后明也介绍了关于Magnum的热门讨论。

容器存储 — 探索容器数据卷的支持

首先,王后明谈道:数据在Docker容器中有两个位置可以存储:和容器同一生命周期的容器可读写层或持久化的挂载到容器的数据卷。Magnum当前已经支持用Cinder volume来存储容器镜像,该话题讨论了挂载Cinder volume到每个独立的容器作为数据卷的可能性。

值得大家关注的是OpenStack社区已发起一个新的孵化项目Fuxi,专注于使Docker容器可以使用Cinder Volume和Manila Share,这样Docker卷可以重用Cinder和Manila的高级特性和众多的存储厂商驱动。该项目已在2月26号被OpenStack接受。王后明提供了详细讨论内容的网址,大家可见:https://etherpad.OpenStack.org/p/newton-magnum-container-storage

容器网络 — 集成Kuryr网络驱动

接下来,王后明介绍道:Magnum当前使用Flannel来为不同主机上的容器提供网络连通。Flannel大部分使用场景是用于Overlay网络,有一定的性能问题。为了提升容器网络性能,Magnum需要一种非Overlay解决方案,让容器可以直接接入底层Neutron网络。Magnum和Kuryr社区协作讨论,分析各种方案的可行性。首先需要解决的问题是Keystone认证信息的存储和管理,因为非overlay方式,Nova虚拟机内部生产网络需要访问物理网络的OpenStack环境,需要相应认证和授权机制。

王后明同样提供了详细讨论内容的网址,大家可见:https://etherpad.OpenStack.org/p/newton-magnum-container-network

Ironic集成 — 支持Ironic virt-driver

在Ironic集成方面,王后明这样说:Magnum当前是把容器管理集群和容器运行与虚拟机之上,并不支持裸机部署。社区计划通过Nova的Ironic virt-driver来达到让容器集群和容器运行于Ironic提供的裸机服务器上。

接下来王后明提供了详细的讨论内容,大家可见:https://etherpad.OpenStack.org/p/newton-magnum-ironic-integration

Magnum生产部署面临的挑战 — 经验分享及如何克服:

王后明表示,该话题讨论了Magnum达到生产可用成熟度所需要增强和完善的各方面功能点,包括API版本化、异步消息、可扩展性、集群生命周期管理、更完善的文档等等。

详细讨论内容大家可见:https://etherpad.OpenStack.org/p/newton-magnum-adoption-challenges

兼容不同COEs的通用容器接口抽象

王后明随后介绍道:Magnum目前支持三种容器编排引擎,包括Kubernetes、Mesos和Docker Swarm,三者有各种独有的API接口和特性,并且运行于不同集群的容器负载相互间不可移植。Magnum创始PTL Ardian Otto强烈反对在Magnum中实现不同COEs的统一接口封装,他认为这种方式是OpenStack的大的策略错误,并建议Magnum采取数据库即服务项目Trove里的实现方法,直接把不同COE的原生API接口暴露给用户,这样有利于用户用COE原生的生态工具和库去进行集成。

详细讨论内容大家可见:https://etherpad.OpenStack.org/p/newton-magnum-unified-abstraction

另外,王后明还给出了更多讨论的内容,大家可参考:

https://etherpad.OpenStack.org/p/newton-magnum-heat-template-versioning

https://etherpad.OpenStack.org/p/newton-magnum-monitoring

关于OCI和CNCF这两个新的组织

EasyStack研发工程师杨宏扬在分享中表示:自从2014年初开源Docker流行起来之后,业界一直在谈论云的Workload的容器化。与此同时,OpenStack Containers Team成立并且发起了Magnum项目,Magnum项目旨在方便用户在OpenStack环境中部署Containers环境。

另外,随着在OpenStack环境中运行Containers的需求日益增多,打通Containers与OpenStack Neutron网络的项目Kuryr应运而生。去年12月,两个新的组织成立,主要致力于创造开放的,统一的标准,来规范Containers生态,一个是Open Container Initiative (OCI), 另一个是Cloud Native Computing Foundation (CNCF)。包括Docker, Google, Intel, IBM等在内都是他们的成员。希望不久的将来我们能够迎来一个更加统一开放的容器生态世界。

深入了解Astara项目

杨宏扬在Astara项目的分享中介绍道:Astara项目是最新的OpenStack Bit Tent项目之一,它是一个开源的网络编排工具。在这个Session,来自Akanda的CTO,Mark McClain给我们详细讲解了Astara的架构,以及Astara项目是如何利用OpenStack生态来形成了一个可扩展的解决方案。Astara利用虚拟机来替代neutron的L3服务,比如router, lbaas等,在Astara环境中,这些服务都以虚拟机的形式存在,可以动态创建删除或者动态扩展,L2对于Astara是透明的,Astara并不关心L2的实现,不管是OVS, 还是Linux Bridge都可以,可以说Astara是一个L3的NFV解决方案。截止到Mitaka,Astara已经实现了router, lbaas, vpnaas,实例池,并且可以集成你自己的网络功能(Network Function),Newton中,将主要实现以下的功能:

1. 通用的VNF驱动

2. Python Entrypoint Support

3. Load Balancing(根据不同的Workload来动态调整网络服务的实例)

4. SFC Integration

Nova:Scheduler性能分析

EasyStack研发工程师李章梅在“Nova:Scheduler性能分析”的分享中看到来自Intel的工程师YingXin Cheng给我们分享了Nova Scheduler性能分析。

通过对各种场景进行测试分析,其发现整个Nova的性能瓶颈在于Scheduler,根源在于每次创建云主机时,大量节点信息需要从数据库更新到内存。

那么如何来提高Scheduler的性能,为此他提出了3种可能的解决方案:

1.增加 Scheduler的数量

2.增加Worker的数量

3.直接对节点信息进行缓存。

经过验证,方案1可以带来一些性能提升,但并不是 Scheduler数量越多就性能越好;方案2对性能影响较小; 最终方案3可以带来明显的性能改善,从图中可以看出速度大概有9倍的提升。

134379854

Intel2

Cheng先生最终总结出了3点优化细节的设想:

1改进数据库,如利用内存数据库;

2优化数据库查询语句;

3放弃使用数据库,转而使用状态共享的Scheduler 。

其详尽的分析不仅给我们带来了优化Nova性能的实践经验,也更加深入的了解了Nova整个流程的处理过程,以及其中存在的瓶颈。即使最终优化方案我们不使用缓存,也打开了我们如何利用其它方式进行优化的思路。

如何让制作Trove的镜像变得更简单

EasyStack研发工程师陈超喆在分享中表示:在OpenStack的很多项目中,都需要特殊定制化的镜像来实现项目功能,在OpenStack上进行部署,或是用于部署Opensack。例如Kolla,或是Sahara,都有自己的Image-Build方案,而Trove始终没有一个完善的镜像制作、管理、发布的解决方案,官方提供的Trove镜像都是用于测试和开发的,这也一直困扰着Trove的很多用户和初学者的。今年三月份,Pete Mackinnon就提出过’Trove-Image-Builder’的计划,该计划刚提出就获得了很多的关注和支持,所以这次自由讨论中就这个问题做了单独的讨论。

陈超喆的图

​图:关于制作Trove的镜像讨论现场

据陈超喆介绍,会上讨论十分热烈,Humar提出的观点和需求很简单,就是想尽早的让用户能够有获取镜像的途径,会场也不时有人表示十分赞同。而对于最终是采用Repo镜像源,还是提供一套工具让用户自己制作,以及如何选择镜像的更新周期等等这些问题,大家都各抒己见。但是,大家是一致认同通过让用户简便快捷地获得不同OS版本的Trove镜像,能够推动Trove项目的广泛应用,吸引更多的人选择和使用Trove。

关于Murano,什么是新的?什么是旧的?为什么?

EasyStack研发工程师刘楠科参加的讨论话题是Murano:本场讨论的主题是: What’s new, What’s old, What’s up。刘楠科介绍道:PTL首先对Murano 项目在最新版本Mitaka的新特性进行了简单介绍,比如对Multi-Region的支持,在核心库中加入Cinder Volume Classes ,MuranoPL(Murano项目语言) 测试框架的构建,对New Plugin的支持,如Magnum Plugin等等(刘楠科提供了讨论详情,大家可见http://docs.OpenStack.org/releasenotes/murano/mitaka.html#new-features),PTL肯定了这一阶段的项目的进展成果,并接着提出了下一阶段的目标,主要从三个方面去着手进行:

1. 简化项目的安装配置

2. 优化ui/dashboard,目标开发出更易于操作和自动化程度更高的前端界面

3. 对multi-region和multi-cloud的继续开发和支持

同时根据优先级对Newton版本进行分类,重点放在对界面操作的优化,和项目功能(可供VM安装的App的数量和质量)的扩展上。我认为Murano的发展终极目标意在提供稳定,高性能,可扩展的第三方App或者Service,可以让应用的开发者和云管理员们来发布各种为云准备好的App和Service,然后通过”一键”部署到环境。这对于OpenStack的发展是十分必要的。

通过Heat使用LBaaS V2服务

EasyStack资深工程师王博在分享中介绍道:OpenStack提供的集群功能特性(LBaaS, Auto-Scaling,HA)一直是大家关注的热点,Heat作为应用编排工具,通过模版将所需组件提供的服务绑定到虚机资源上,可以有效解决上述集群问题。

Session主要介绍如下内容:

LBaaS V1版本API在Liberty版本被Deprecated,V2版从Liberty开始有Horizon Pulgin,LBaaS V2支持多种Driver,默认是Octavia,Octavia作为一个独立项目,功能更加完善:L7层的LB,共享Pool,集成Barbican。

Heat从Mitaka版本开始支持创建V2版LBaaS的资源:

王博

如图所示,LB服务包含多个资源,Heat可以解析资源间的依赖关系,以保证整个LB所需资源并行快速创建,如果出错所有Resource执行回滚。

使用DevStack部署Enable LBaaS V2的环境,需要配置ENABLE_SERVICES+=Q-Lbaasv2; 如果需要Horizon Plugin需要配置Enable_Plugin。

OSLO.Messaging Driver 的更新

EasyStack创始工程师、OpenStack Oslo Core Reviewer郭长波在分享中介绍道:OSLO.Messaging Driver 更新:OSLO.Messaging 为每个项目组件间提供通信,稳定、高效至关重要,这次Worksession上介绍了每种Driver更新 ,在Newton版本里将为AMQP1.0 Driver 实现 Dispatch Router 实现根据消息地址路由功能 为跨网络部署Broker提供可能 。在Mitaka版本里实现了Pika 跟Kafka Driver 虽然这些Driver并没有达到生产级,但会逐渐完善为用户提供多种可能. 会上讨论了接下来要做的工作。

改善OSLO在各个项目的应用:有些项目仍然在用OSLO-Incubator里面的代码拷贝,在Newton版本会逐步去除掉使用已经Release的新库. 除了代码功能实现,也要重视文档和使用规范,通过提供更多的Example Code,发表介绍性的博客使其他项目开发人员 更好的理解和使用OSLO库,并讨论出具体任务

郭长波1

郭长波2

OSC未来的工作和发展方向

EasyStack工程师、OpenStack Client 项目 Core Reviewer汤晨在今天的OSC Work Session中表示:我们商量了OSC接下来的主要工作和发展方向。在Network方面,Neutron Client团队已经表明,开始将Neutron Client向OSC迁移,新的功能不再由Neutron Client实现,而是直接在OSC中实现,并且通过OpenStack sdk调用Rest API。网络的核心功能直接在OSC中实现,Lbaas,Fwaas等扩展功能以Plugin的形式实现。其他模块,今后也将迁移至OpenStack SDK,但这需要很长的时间。

PTL Dean还介绍了Neutron Library和OpenStack sdk的区别。他指出,Neutron Library面向服务器而开发,是供服务器端的程序调用的。而OpenStack SDK为Client端程序开发,在编写客户端程序或者基于OpenStack的应用程序时,应首先考虑使用SDK。

在OpenStack奥斯汀峰会期间,OpenStack中国社区将联合业内各界人士,为不能亲临现场的朋友传播峰会现场精彩内容,敬请期待。另:如果您有更为丰富的现场内容想要分享,欢迎您联系OpenStack中国社区的小伙伴,微信号:neocity,让我们一起见证中国OpenStack迈向更广阔的领域和更长远的发展。

OpenStack奥斯汀峰会直播群二维码

 初稿