OpenStack奥斯汀峰会的第三天,容器类的技术Session依然是备受追捧的热门,OpenStack中国社区前线报道团依然给大家带来了一手的技术分享,来看看都有哪些内容和评论吧。

容器改变了应用的组织方式,由传统的一体化架构转变为大量无状态、松耦合应用组成的微服务架构。虽然组织方式发生了变化,但应用数据的持久化存储任然不可避免。EasyStack创始工程师王后明发现,在本届奥斯汀峰会上,针对如何持久化容器数据、如何利用OpenStack已有的丰富的存储设备管理能力为容器提供持久存储、持久化容器数据的几个原则等问题,有多位工程师就这些话题进行了阐述。

运用Cinder实现容器的持久存储

来自EMC的工程师Drew Smith介绍了专为Docker容器提供持久化容器解决方案的开源REX-Ray项目。REX-Ray有几大重要的任务,包括为容器提供存储管理组件、能支持丰富的存储设备、集成并紧跟Docker的开发周期。目前REX-Ray已支持众多存储后端平台,包括:Virtual Box、AWS EBS、GCE Persistent Volume、OpenStack Cinder以及EMC VMAX、ScaleIO等EMC存储设备。

此外,Drew还现场演示了REX-Ray使用Cinder为Docker提供持久存储的场景,可以看到是十分简单易用的。由于能支持主流公有云AWS和GCE的块存储,同时又支持OpenStack块存储,这给予了REX-Ray强大的存储设备管理能力,加上开源开放和接口的简洁,使其成为容器持久化存储的主流解决方案之一。

(容器数据)持久?还是不持久?这真是个问题

持久化存储有多种方案,包括本地存储、商业存储、分布式存储、对象存储等。来自Rackspace的工程师Kenneth Hui借用了莎翁名句,进行了《To Persist, or not Persist (Container Data), that is the Question》主题分享。

在使用容器进行应用微服务化,在考虑持久化存储的过程中应该避免的思路,包括:不要把容器当做轻量级虚拟机,应该把容器当做奶牛而不是宠物;不要把存储挂载到所有容器上,这样丧失了容器间松耦合原则、减少了易用性;不要使用传统商业存储,因为这样会影响整个系统的可扩展性,并带来了单点故障。

同时,Kenneth给出了几个建议:使用松耦合存储后端,包括使用对象存储保存文件、使用数据库即服务保持数据;仅仅在必要时才使用持久化存储,保持容器无状态;使用分布式存储。

最后,来自SolidFire工程师、前Cinder PTL John Griffith现场演示了Docker如何对接SolidFire存储来持久化数据。

Magnum项目Design话题讨论

作为Magnum的贡献者,王后明也参加了该项目的Design 讨论,让我们来一睹Magnum的最新研发方向吧。

1、Bay Driver开发

Magnum目前支持3种容器编排集群(COEs),包括Google Kubernetes、Apache Mesos和Docker Swarm,但用户可能对各个集群的默认配置并不满意,或者用户有其它的容器编排工具。为此,Magum社区引入了Bay Driver的概念,以支持三种默认COE之外的其它驱动和需要定制化的驱动。

2、长期运行集群的生命周期管理

针对长期运行的容器集群,Magnum需要提供机制,支持集群组件升级、自动容错及恢复等生命周期管理。目前Magnum对这部分支持不够,将可参照Rackspace Carina的机制,逐渐丰富Magnum的集群周期管理能力。

3、Magnum可扩展性、异步方法实现

Magnum需要支持成百上千个集群创建以及成千上万个容器的创建,这要求Magnum本身有强大的可扩展性和处理能力,Magnum目前正在通过运行多个子进程、采用异步消息机制等措施,逐步增强Magnum可扩展性以支持大规模容器部署。

发现问题,解决问题,Horizon会更优化

EasyStack资深工程师王博在Horizon的分享中提到,越来越多的项目加入社区的“Big Tent”,Horizon不应该维护所有项目Dashboard的代码,所以提供Plugin的机制,各个Project根据Plugin的框架维护各自的Dashboard并作为一个独立的项目,例如Magnum。使用时通过修改Horizon配置文件,加载Plugin,集成的Horizon的统一页面中。Horizon Team希望听到使用者,二次开发者以及Plugin开发者的声音,以解决Plugin开发中的问题及Horizon整体的用户体验。会议开放讨论Horizon在哪些方面做的好,哪些方面做的不好,目的是为了解决问题,所以大家更多的是讨论Horizon体验不好的点。

同时,王博认为,这个会议可以从不同角度(使用者,二次开发者)发现Horizon的问题,使得Horizon作为一个开源软件可以不断优化,为使用者提供更大的帮助。分享会上讨论最多的是:Launch Instance页面操作复杂;很难定制化。王博认为操作复杂是因为Nova Create Instance的参数较多,也是这个原因导致页面交互很多代码复杂。好在程序员可以重构这部分代码,降低耦合度,使其更容易被定制化。

Romana项目的一些理念

Romana是全新的专为原生云应用设计的软件定义网络解决方案。Romana允许OpenStack、Docker和Kubernetes构建多租户云计算网络,即便目前没有被封装或虚拟网络的覆盖。

911439922

Romana项目概述

EasyStack工程师汤晨在Romana计划分享中提到,目前,IP地址的分配和管理机制有许多不足,例如,租户越多,Segment就越多,找到IP地址对应的租户信息效率低下;手动配置CIDR非常麻烦,容易出错等等。Pani Networks的工程师们提出了更加聪明的IPAM方案,将IP地址以Bit为单位分段,每一段代表一定的意义,例如32位的IPv4地址,1~8位代表Network,9~16位代表Host,17~20位代表Tenant,21~24位代表Segment,25~32位代表Endpoint。这样在处理数据包的时候,通过这些信息与IP地址的映射关系,避免了繁重的数据库操作,提升了性能。这个思想由Romana项目实现,提供Pluggable IPAM机制,使IP地址的管理更加灵活和高效。

2084213518

另外,汤晨认为Pani Networks的思想是很新颖的,但是Romana项目到底有多大功效,还有待实际环境的验证,尤其是在性能和稳定性方面。

Ceilometer、Nova 和 Neutron 的结合为你打造健康的云坏境

EasyStack研发工程师陈超喆在分享中提到,Juniper网络工程师介绍如何通过收集Network Health KPI,API上报给Ceilometer,并将节点网络状况加入Nova Scheduler的Filter和Weight,来提高云环境网络监控能力和可控性。

webwxgetmsgimg

webwxgetmsgimg (2)

OpenStack OSLO Design讨论

来自EasyStack创始工程师、OpenStack OSLO Core reviewer郭长波的分享——OSLO 几个Session 主要讨论了OSLO.CONFIG。

可修改配置项的支持:希望通过系统信号触发重新加载配置文件目前第一个使用用例为运行时更改Log级别;OSLO.Policy支持Yaml格式:Yaml格式较Json格式有明显的优点,所以将来OSLO.Policy会默认使用Yaml,这需要一个过程,先把使用Json标记为Warning,最终移除掉,并讨论了可插拔的Policy规则实现,通过外在的服务查询权限,可实现动态修改权限的功能。

其中上报Ceilometer用的是Sample-Create的API,其实可以通过添加一个Ceilometer的Plugin来做相同的工作。

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


直播二维码更新

初稿