- 作者简介:胡晓亮,目前就职于IBM Platform Computing 系统科技部云计算部门,担任云计算开发部工程师。自2013年8月开始参与OpenStack相关的开发工作,涉及Nova、Cinder、Heat、等项目。
OpenStack简介:OpenStack是旨在为公有及私有云的建设与管理提供软件的一个开源项目,采用Apache授权协议,它的核心任务是简化云系统的部署过程,并且赋予其良好的可扩展性和可管理性。它已经在当前的基础设施即服务(IaaS)资源管理领域占据领导地位,成为公有云、私有云及混合云管理的“云操作系统”事实上的标准,在政府、电信、金融、制造、能源、零售、医疗、交通等行业成为企业创新的利器。OpenStack基于开放的架构,支持多种主流的虚拟化技术,许多重量级的科技公司如RedHat,AT&T,IBM,HP,SUSE,Intel,AMD,Cisco,Microsoft,Citrix,Dell等参与贡献设计和实现,更加推动了OpenStack的高速成长, 打破了Amazon等少数公司在市场上垄断的局面,解决了云服务被单一厂商绑定的问题并降低了云平台部署成本。
OpenStack的虚拟机调度策略主要是由FilterScheduler和ChanceScheduler实现的,其中FilterScheduler作为默认的调度引擎实现了基于主机过滤(filtering)和权值计算(weighing)的调度算法,而ChanceScheduler则是基于随机算法来选择可用主机的简单调度引擎。如图1是FilterScheduler的虚拟机调度过程,它支持多种built-in的filter和weigher来满足一些常见的业务场景。在设计上,OpenStack基于filter和weigher支持第三方扩展,因此用户可以通过自定义filter和weigher,或者使用json资源选择表达式来影响虚拟机的调度策略从而满足不同的业务需求。
Built-in的filter(部分):
Built-in的weigher(部分):
在一个复杂的云系统中,对云计算资源的监控和优化对于保证云系统的健康运行,提高IT管理的效率有重要的作用。最新版本的OpenStack也没有提供类似的功能,这可能是由于云系统的监控的对象和优化目标对于不同的用户有不同的要求,难于形成统一实现和架构,但是OpenStack已经意识到这部分的重要性并且启动了2个项目来弥补这个短板,当前它们都处于孵化阶段:
由于OpenStack开源的特性,直接投入商业使用可能面临后期升级,维护,定制化需求无法推进的问题,因此一些有技术实力的公司都基于OpenStack开发了自己商业化的版本,这些商业化版本的OpenStack都包含了一些独有的特性并和社区开源的OpenStack形成了差异化, 比如完善了OpenStack虚拟机的调度和编排功能,加强了云系统的运行时监控和优化,弥补了云系统自动化灾难恢复的空缺,简化了云系统的安装和部署,引入了基于资源使用时长的帐务费用系统等等。PRS(Platform Resource Scheduler)是IBM Platform Computing公司的基于OpenStack的商业化资源调度,编排和优化的引擎,它基于对云计算资源的抽象和预先定义的调度和优化策略,为虚拟机的放置动态地分配和平衡计算容量,并且不间断地监控主机的健康状况,提高了主机的利用率并保持用户业务的持续性和稳定性,降低IT管理成本。PRS采用可插拔式的无侵入设计,100%兼容OpenStack API, 并且对外提供标准的接口,方便用户进行二次开发,以满足不同用户的业务需求。本文将会从虚拟机初始调度策略,实时监控和优化策略,用户自定义OpenStack Filter,虚拟机调度失败的Trouble Shooting Report和基于拓扑结构调度等方面概括介绍PRS的主要功能和使用场景,之后将有一系列文章对每个主题展开深入介绍。
虚拟机的初始放置策略指的是用户根据虚拟机对资源的要求决定虚拟机究竟应该创建在哪种类型的主机上,这种资源要求就是一些约束条件或者策略。例如,用户的虚拟机需要选择CPU或者内存大小满足一定要求的主机去放置,虚拟机是需要放置在北京的数据中心还是西安的数据中心,几个虚拟机是放在相同的主机上还是放置在不同的主机上等等。原生OpenStack调度框架在灵活的支持第三方的filter和weigher的同时也丧失了对调度策略的统一配置和管理,当前PRS支持如图2的初始放置策略,并且可以在运行时动态的修改放置策略。
随着OpenStack云系统的持续运行,云系统中的计算资源由于虚拟机的放置会产生碎片或分配不均,虚拟机的运行效率由于主机load过载而降低,主机的down机会造成用户应用程序无法使用等一系列问题。 用户可以通过人工干预的方式来排除这些问题. 例如用户可以将load比较高的主机上的虚拟机migrate到其他主机上来降低该主机的load,通过rebuild虚拟机从down掉的主机上到其它可用主机上解决用户应用程序高可用性的问题,但这需要消耗大量的IT维护成本,并且引入更多的人为的风险。PRS针对这些问题提供了如图3的两种类型的运行时策略来持续的监控和优化云系统。
OpenStack对虚拟机的调度是基于对主机的过滤和权值计算,PRS也实现了相同的功能,并且为提供了更加优雅的接口方便用户定义出复杂的filter链,并且配合使用虚拟机初始调度策略从而动态的将用户自定义的虚拟机放置策略插入到虚拟机的调度过程中去满足业务的需求:
当虚拟机创建失败处于Error的时候,云系统应该提供足够的能力方便管理员trouble shooting,从而尽快排除错误并保证云系统正常运行。造成虚拟机部署失败的原因主要有2种:第一种是调度失败,没有足够的计算资源或者合适的主机满足虚拟机虚拟机的请求。 第二种是调度成功,但是在计算节点上部署虚拟机的时候失败,原因是多种多样的,比如Libvirt错误,image类型错误, 创建虚拟机网络失败等。当前的OpenStack虚拟机的Trouble Shooting机制不能够清晰反映问题的原因,需要管理员大量的分析工作,这无疑增加了排除问题的难度和时间:
OpenStack Heat是虚拟机组的编排组件,它本身没有调度模块,它基于Nova的FilterScheduler作为调度的引擎对一组或多组虚拟机进行主机级别的扁平化调度和编排,但这种调度模型每次只能处理一个虚拟机请求,当部署多个虚拟机的时候,它不能根据资源请求进行统一的调度和回溯,将会造成调度结果不准确。 PRS不但支持主机级别的扁平化调度,还支持对一组同构虚拟机内部或者一组虚拟机和另一组虚拟机在一个树形拓扑结构上(Region,Zone,Rack,Host)上进行整体调度。基于拓扑结构的多个虚拟整体调度可以得到一些显而易见的好处,比如在部署的时候为了拓扑结构上层级之间或虚拟机之间获得更好的通信性能可以选择Affinity的策略,为了获得拓扑结构上层级之间或虚拟机之间的高可用性,可以选择Anti-Affinity策略。PRS通过和Heat的深度集成实现了基于拓扑结构的整体调度。新的Heat资源类型IBM::Policy::Group用来描述这种一组或多组虚拟机在一个树形的拓扑结构上的部署需求。
案例1:如图6,用户定义了2个auto scaling group tier1和tier2, 每个tier都需要2个虚拟机,其中tier1需要虚拟机在rack节点上Anti-Affinity,tier2需要虚拟机在rack节点上Affinity,并且tier1和tier2上的虚拟机之间需要满足Affinity. 这个场景类似于在生产环境上部署2组web application, 要求运行database的虚拟机(tier1)和运行web的虚拟机(tier2)在相同的主机上(方便web服务器和database服务器通信),并且2个运行database的虚拟机(tier1)和2运行web的虚拟机(tier2)不能同时运行在一台主机上(rack级别上Anti-Affinity,担心单rack单点故障造成所有的database服务器或者web服务器都不可用)。图的左边是一个部署的结果,红色的虚拟机的是web服务器tier1,黄色的虚拟机是database服务器(tier2), 这样host1上的database服务器直接为host1上的web服务器提供服务, host6上的database服务器直接为host6上的web服务器提供,并且rack1或者rack3的单点故障,不会造成用户web服务的中断。
案例2:如图7,用户定义了1个auto scaling group tier1, 这个tier1需要4个虚拟机,要求当zone发生单点故障的时候,用户的4个虚拟机的损失率不能大于50%。这个场景类似于在生产环境上部署一个Nginx 服务器集群,当发生故障时,总有一半的Nginx服务器能够正常工作。图的左边是一个部署的结果,当zon1或者zone2中人任何一个发生故障,用户的应用程序最多损失2个Nginx服务器,满足用户的业务要求,这样用户在部署的时候就通过整体优化的虚拟机放置策略实现应用程序的高可用性而不必等节点失败的时候通过PRS HA策略的监控策略亡羊补牢。
- OpenStack Days China将于7月14-15日在北京国家会议中心隆重举行,包括Alan Clark等基金会董事都会亲临现场,目前票价优惠,欲报从速。