OpenStack计费项目CloudKitty的强化及运用

本文转自Openstack中国社区Openstack计费项目CloudKitty的强化及运用

本文作者： “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层的计费需要如下几个步骤：

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的架构如下图所示：

主要包括四个部分：

• 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步：

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在图形界面这一块还比较欠缺，社区最近主要是想提升统计报表的功能。