本文作者: “Li Xiangjun”

 

在OpenStack开发社区向“Big Tent”模式全面转型之际,一个新的项目—CloudKitty进入了人们的视野。该项目基于OpenStack对外提供Rating-as-a-Service的服务,旨在解决IaaS层计费方面的需求。

 

Why we need it

云计算的一个最大特征就是“按需使用,按量付费”,那么基于OpenStack的云平台如何来实现计费方面的需求呢?很遗憾,社区在很长一段时间内都没有给出一个切实可行的解决方案(有这方面的尝试,像BP: https://wiki.openstack.org/wiki/Ceilometer/blueprints/Add_Billing_in_Ceilometer就是计划在Ceilometer框架内添加计费的功能,但最后都没有了下文),很多公司都是各自为OpenStack开发自己的计费服务作为其产品化的一部分。随着OpenStack的不断发展,社区在计费方面的诉求也越来越强烈。为了填补OpenStack计费方面的空白同时也为了避免重复造轮子,CloudKitty应运而生。

 

How it works

一般意义上来讲,要最终实现对IaaS层的计费需要如下几个步骤:

1

 

 

Step 1. Metering: 收集资源的使用数据,其数据信息包括:使用对象(what),使用者(who),使用时间(when),使用量(how much)

Step 2. Rating: 将资源使用数据按照商务规则转化为可计费项目并计算费用

Step 3. Billing: 结账开票,也就是根据指定的时间段计算用户总的资源使用费用(由于各个公司对于billing都有自己独特的需求,所以该步骤一般都是用户自己实现的)

在OpenStack所有组件中,Ceilometer负责收集虚拟资源的详细使用数据,充当Metering的角色。CloudKitty做的事情就是从Ceilometer端获取计量数据,然后根据事先定义好的计费规则对这些使用数据进行Rating,为最终的billing提供数据支撑。如上图所示,CloudKitty在整个计费流程中充当的是Rating的角色。

 

CloudKitty的架构如下图所示:

 

2

 

 

主要包括四个部分:

 

  • Data collection (collector)
  • Rating processing
  • Storage
  • Report writer

 

分别说明如下:

 

  •  Collector:负责收集虚拟资源的原始使用信息并转化为CloudKitty能够识别的数据格式。Collector采用插件式设计,可以根据不同的计量组件或不同的meter数据获取方式装载不同的collecotr(理论上甚至可以为CloudStack开发一个collecotr让CloudKitty可以在CloudStack上工作),至于在运行时装载哪个collector可以在配置文件中进行配置。目前社区已实现ceilometer的collector。
  •  Rating processing:计费引擎, CloudKitty的核心组件,对外提供设定价格的API接口,对内负责计算所有虚拟资源使用记录的费用。它从collector获取原始的使用记录,然后根据事先设定好的价格及计价策略对这些记录进行费用的计算。同样该模块采用插件式设计,具有良好的可扩展性。现在社区实现了一个名为hashmap的rating module。我们可以根据自身的需求开发我们自己的rating module。还可以在同一时刻加载多个rating module,并且设置执行的先后顺序。最后该模块处理好的计费信息会传递给Storage和Report writer。
  •  Storage:负责把rating processing处理好的计费信息持久化存储到后端数据库。由于在设计的时候引入了ORM框架sqlalchemy所以支持多种类型的数据库,例如mysql、postgresql、sqlserver。另外查询计费信息和创建报表的API也封装在这个模块中。
  •  Report writer:最终的计费信息在存储到后端数据库的同时,还可以用文件的形式存储到磁盘上,方便与第三方系统交换数据。目前支持输出json格式的文件。

分析了CloudKitty的应用架构后,那我们对CloudKitty的内部数据处理流程就很好理解了。如下图所示,从分析计量组件产生的数据,到最终根据计价策略完成对资源使用数据的计费, 总共需要4步:

3

主要包括四个部分:

  • Data collection (collector)
  • Rating processing
  • Storage
  • Report writer

分别说明如下:

  • Collector:负责收集虚拟资源的原始使用信息并转化为CloudKitty能够识别的数据格式。Collector采用插件式设计,可以根据不同的计量组件或不同的meter数据获取方式装载不同的collecotr(理论上甚至可以为CloudStack开发一个collecotr让CloudKitty可以在CloudStack上工作),至于在运行时装载哪个collector可以在配置文件中进行配置。目前社区已实现ceilometer的collector。
  • Rating processing:计费引擎, CloudKitty的核心组件,对外提供设定价格的API接口,对内负责计算所有虚拟资源使用记录的费用。它从collector获取原始的使用记录,然后根据事先设定好的价格及计价策略对这些记录进行费用的计算。同样该模块采用插件式设计,具有良好的可扩展性。现在社区实现了一个名为hashmap的rating module。我们可以根据自身的需求开发我们自己的rating module。还可以在同一时刻加载多个rating module,并且设置执行的先后顺序。最后该模块处理好的计费信息会传递给Storage和Report writer。
  • Storage:负责把rating processing处理好的计费信息持久化存储到后端数据库。由于在设计的时候引入了ORM框架sqlalchemy所以支持多种类型的数据库,例如mysql、postgresql、sqlserver。另外查询计费信息和创建报表的API也封装在这个模块中。
  • Report writer:最终的计费信息在存储到后端数据库的同时,还可以用文件的形式存储到磁盘上,方便与第三方系统交换数据。目前支持输出json格式的文件。

分析了CloudKitty的应用架构后,那我们对CloudKitty的内部数据处理流程就很好理解了。如下图所示,从分析计量组件产生的数据,到最终根据计价策略完成对资源使用数据的计费, 总共需要4步:

 

4

 

CloudKitty从Ceilomter获取资源的使用记录,根据admin用户预先设定的计费策略生成计费记录,然后end user就可以通过CLI或GUI查询到自己的计费信息。

 

Current status and Roadmap

相对于OpenStack的其它组件,CloudKitty算得上是一个比较年轻的项目了,去年8月才在社区注册。在今年6月份我们决定采用它做为公司内私有云的计费模块时它还是一个孵化项目,到今年十月底的时候就已经转变为OpenStack的正式项目了。之所以发展这么快我认为一个很大的原因就是上文提到的OpenStack计费方面的需求太强劲,社区太需要一个项目来填补metering和billing之间的空白了。CloudKitty加入Big Tent后,社区活跃度有了质的提升,根据社区统计数据,CloudKitty加入Big Tent两周后获得的contributions比加入前半年的总计还要多。CloudKitty近期(M cycle)主要的开发计划大致如下:

  • 添加Gnocchi支持

主要是性能/可伸缩性方面的考虑。当前的CloudKitty在架构上存在一个很大的性能方面的风险(其实问题根源在Ceilometer),由于CloudKitty需要调用Ceilometer的API获取虚拟资源的使用信息,但是大家都知道在数据规模比较大(数千台虚拟机)的情况下,Ceilometer在查询的时候会有很大的性能问题,这样就会导致CloudKitty的collector在收集数据的时候速度变慢,从而产生连锁反应使整个CloudKitty的处理速度慢下来。近期,Ceilometer社区为解决查询时的性能问题导入了一个名为Gnocchi的组件(Gnocchi是一个时间序列存储后端,它对存储和检索时间序列的数据有着天然的性能优势),专门向外提供Metric数据的查询服务。所以为了适配这个变化,CloudKitty正在开发一个工作在Gnocchi上的collector,希望利用Ceilometer的这个改进一劳永逸的解决获取计量数据时的性能瓶颈。

  •  增加名为pyscript的rating module

装载了这个rating module后,支持用户编写python代码来灵活定义自己的计费规则。以前要自定义计费策略你必须自己开发一个独立的rating module,在这个过程中你需要对CloudKitty的内部实现有一定程度的认识,但是有了pyscript计费模块后,你完全可以把CloudKitty当做一个黑盒,只要专注于用python来实现你自己的计费策略并上传到pyscript即可,这样就大大降低了CloudKitty的使用门槛。

  • 提升图形界面

CloudKitty在图形界面这一块还比较欠缺,社区最近主要是想提升统计报表的功能。

 

FNST’s Effort

FNST(南大富士通)是一家软件研发公司,2014年已经基于VMWare建设了开发测试用的私有云,从2015年年初开始将其转向基于OpenStack的开源方案。为了把握各个部门对资源的使用情况引入了计费功能,而计费模块采用的就是CloudKitty。为了满足实际需求,对CloudKitty进行了功能强化,主要包括:

  1. Event分析支持

原生的CloudKitty只对Ceilometer的sample进行分析,这样就导致:

√  虚拟资源的计费周期不能准确与其生存周期对应

√  虚拟资源的状态变化不能及时触发计费策略的变化

√  不支持VM开机状态和关机状态分别应用不同的计费策略

我们对Ceilometer collector做了相应增强,增加了对event进行分析的功能。下面是相同的使用场景在添加event分析支持前后生成的最终计费记录的对比,可以清楚的看出效果:

计费策略

flavor-A(2C4G)为5元每小时,flavor-B(4C8G)为10元每小时。计费周期为1小时1次。

场景

①在某日13时15分10秒用flavor-A创建了一台虚拟机à②13时45分13秒对其做了变更flavor的操作(变更为flavor-B)à③14时10分59秒关机à④14时35分20秒开机à⑤最后在14时49分13秒删除了该虚拟机

对应的,ceilometer端生成的event如下:

①compute.instance.create     ② compute.instance.resize

③compute.instance.power_off ④compute.instance.power_on

⑤compute.instance.delete

原生CloudKitty生成的计费记录:

Begin End Unit Unit Price
(per hour)
Rate
2015-11-28 13:00:00 2015-11-28 14:00:00 instance:flavor-B 10 10
2015-11-28 14:00:00 2015-11-28 15:00:00 instance:flavor-B 10 10

增加event分析支持后的CloudKitty生成的计费记录:

Begin End Unit Unit Price
(per hour)
Rate comment
2015-11-28 13:15:10 2015-11-28 13:45:13 instance:flavor-A 5 2.50 begin: instance.create
end: instance.resize
2015-11-28 13:45:13 2015-11-28 14:00:00 instance:flavor-B 10 2.46 begin: instance.resize
end: period_cutting_event
2015-11-28 14:00:00 2015-11-28 14:10:59 instance:flavor-B 10 1.83 begin: period_cutting_event
end: instance.power_off
2015-11-28 14:10:59 2015-11-28 14:35:20 instance:flavor-B 10 0 begin: instance.power_off
end: instance.power_on
2015-11-28 14:35:20 2015-11-28 14:49:13 instance:flavor-B 10 2.31 begin: instance.power_on
end: instance.delete

 

比较改造前后计费记录的变化可知,增加了event分析支持后:

√计费精度能精确到秒级

√使针对虚拟资源不同状态应用不同计费策略的处理方式成为可能

  1. 层级tenant支持

利用Kilo版本中新增加的层级tenant特性,在CloudKitty里实现按组织结构分层统计的功能,例如事业部(bd1)下面有4个开发部(dep1-4),在Keystone中的存储结构是4个开发部的parent id都指向这个事业部,在CloudKitty中获取事业部的费用统计情况的时候,效果如下所示:

6

  1. 专门的计价模块

为实现我们公司独有的计价需求,我们开发了独立的rating module。该module能够对虚拟资源定义多维度的计费策略,包括针对instance支持按flavor、开关机状态、运行时长三个维度来综合计算费用,而对于volume支持按size、volume type和运行时长三个维度来算费。

  1. 完全重构的GUI界面

为满足公司IT部门和财务部门的需求,我们完全重构了CloudKitty在Horizon中的显示页面,把展现内容按功能分布在定价、概览及详单三个页面中。

……

现在,经过我们改造增强后的CloudKitty已经投入运行(虚拟机规模两千台左右),同时我们还把这些增强内容对CloudKitty社区做了介绍并获得了非常正面的评价,社区的PTL邀请我们把诸如evnet分析支持,tenant层级支持合并到社区版本中来。不出意外的话,大家就可以在Mitaka版本发布的时候看到上面这些功能了。

 

Summary

由于CloudKitty诞生时间不长,项目的成熟度还不高,离生产环境上的部署和运用还存在一定的距离。但是相信在强劲的计费需求的驱动下,CloudKitty项目能够得到快速的发展。

 

  1. 一件代发ၝ高仿原单ၝ顶级A货 V:LoveMeJckBvlgariᕀCoachᕀPradaᕀDiorᕀIWCᕀCartierᕀchanelᕀ