云社区分享Cloudkitty – OpenStack计费服务
Posted 云技术实践
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云社区分享Cloudkitty – OpenStack计费服务相关的知识，希望对你有一定的参考价值。
嘉宾介绍：张国庆，zhangguoqing，开源社区爱好者。
分享摘要：详细介绍OpenStack计费服务Cloudkitty项目及社区情况；带您快速理解Cloudkitty的计费实现机制；丰富的hashmap计费模型举例；秒级计费的实现细节；希望更多的开发者加入到Cloudkitty项目和社区。
Cloudkitty – OpenStack计费服务
不得不说的计量服务和Gnocchi简介
三张图和24行代码快速看懂Cloudkitty
Cloudkitty核心模块（Tenant_fetcher，Collector，Rating，Storage）的详细介绍
基于事件分析的秒级计费实现
社区与开发，以及推荐阅读
Cloudkitty – OpenStack计费服务.pdf
大家好！我们都知道云计算是一种按需付费的服务模式，在OpenStack 中完成计费服务的组件是Cloudkitty，很高兴能在今天晚上与大家交流探讨OpenStack计费服务--Cloudkitty，如有纰漏，欢迎雅正，先在这里谢谢各位了！
谈到计费就不得不先说说OpenStack的计量服务，虽然前期在计量服务上走了些“弯路”，但现在ceilometer、gnocchi、aodh、panko项目的稳步并进算是峰回路转。这其中Ceilometer负责采集计量数据并加工预处理；Gnocchi主要用来存储时序计量数据和提供资源索引；Panko主要提供事件存储服务；aodh主要提供预警和计量通知服务。Ceilometer一分为四，各司其职，因此计费服务的数据源就有了保障（说明：Cloudkitty并非仅能用于OpenStack计费，这取决于collector的具体实现）。
Gnocchi的一个核心功能是资源索引器，通过资源也可以快速知道此资源的基本信息和其所具有的metric(例如instance资源具有cpu_util, memory.usage等metric)。另一个功能是存储计量数据即所有metric的measures(<时间,值>)信息。而metric的measures信息在使用上面会涉及到大量的查询过滤和聚合操作，早期Ceilometer将measures数据存于SQL数据库中的一张表里，由此所带来的延迟在实际使用中是不能忍受的，但在Gnocchi中得到了解决，并且不会随着云环境中资源和时间的增加而产生新的性能瓶颈。
Gnocchi的数据归档策略解释了其中的原因：归档策略决定了points的数量，而每个point的存储空间为9字节，所以每个metric对应文件的存储空间是可预知的；Gnocchi在收到新的measures时，会动态根据预先定义的聚合方法进行聚合操作，并维护存储在文件中的points信息；在使用API获得某个metric的计量信息时，这些计量信息会直接从metric所对应的文件中读取得到points，故时间复杂度为O(1)不存在性能瓶颈。
由此可见，类似于Ceilometer计量数据存储的问题都可以采用gnocchi，那么计费服务产生的费用数据的存储也类似。
Cloudkitty Official包括cloudkitty, cloudkitty-dashboard, python-cloudkittyclient三个部分，Cloudkitty是核心功能组件，包含Tenant fetcher，Collector，Rating和Storage四大核心模块；cloudkitty-dashboard为管理员提供简洁的操作设定界面和为用户提供直观的视图界面；python-cloudkittyclient为管理员提供命令行交互接口。
当然，我们关注的核心是Cloudkitty，基本可以用上面的二十四行代码描述。整体上Cloudkitty计费引擎以定时（CONF.collect.period）task的形式执行计费任务；每一轮计费任务之初要知道需要为哪些租户进行计费get_tenants()，再依次对每个租户的每一项服务进行计费；首先会通过collector模块从计量数据源中获得计费数据data；其次将数据交给计费模型根据定价规则完成费用计算；最后使用storage模块将费用数据持久化存储保存。
下面将依次详细介绍Cloudkitty的四大核心模块。每个模块都使用了stevedore，即插件形式的多种实现，均具有良好的可配置性，拓展性和灵活性。
Tenant Fetcher模块是要告诉Cloudkitty此轮计费任务应该为谁计费。可以从cvs文件（FakeFetcher）和keystone（KeystoneFetcher）中知道需要对谁的资源/服务进行计费。其中广泛使用keystone，支持V2和V3版本。所以对于想要计费的租户需要执行命令’keystone user-role-add --user cloudkitty --role rating --tenant xxx’，将cloudkitty用户加入xxx租户并赋予rating角色。
Collector和Transformer模块是收集和格式化计费源数据。从collector的实现上来看，Cloudkitty不仅仅能为OpenStack计费，而且能为其它有计费需求的平台计费，仅需实现和配置相应的collector模块即可。常用的collector模块是CeilometerCollector和GnocchiCollector，分别使用Ceilometer和gnocchi的API获取计量数据，而在OpenStack环境中GnocchiCollector必将成为核心的收集器。
由Collector的retrieve方法获得计费所需要的计量数据形如item格式，再由Transformer将之格式化为data格式，最终交付给计费模块处理。
计费模型是实现计费的核心，一般能允许用户根据实际需求设定计费规则并且根据收集到资源数据进行准确的费用计算。Cloudkitty实现了多种计费模型noop，hashmap和pyscripts，允许同时启动多个计费模型，并根据设置的优先级完成执行费用计算。Cloudkitty中的pyscripts计费模型使用门槛较高，hashmap计费模型成为了使用价值最高，易用性最强的计费模型，接下来将详细讲解。
上面那张图展示了hashmap计费模型的例子，可以将其看作简单的树形结构。其模型的核心是它的几个概念：Group，Service，Field，Mapping和Threshold，上面PPT中给了详细的例子做参考。
费用总和可由上面的公式验证。
计费模型计算出来的费用数据将由storage模块持久化存储下来，所需记录的核心字段包括begin，end，unit，qty，res_type，desc和tenant_id等，包含了时间信息，资源相关信息，属主信息。每个租户的各项服务费用数据会先缓存下来，最后再将当前租户的当前周期内所产生的费用数据一次性提交到存储后端。
Cloudkitty当前实现的SQLAlchemyStorage和GnocchiHybridStorage实际上都是基于SQL方式存储费用数据。随着云环境中需要计费的项目增多和时间的推移，在使用方面必将会存在于Ceilometer存储measure数据类似的性能瓶颈问题，故使用原生GnocchiStorage来归档费用数据：。
Collector所能收集的数据决定了Cloudkitty所能计费的资源/服务，包括compute，image，volume，network.bw.in，network.bw.out和network.floating。再细分，则计费源主要有两类，一类是静态资源，比如虚拟机实例，镜像，云硬盘，浮动IP，需根据其生命周期按使用时间长短计费；另一类是动态资源，比如网络流量，则需要统计计量情况进行计算费用。这就意味着完善的计费数据源应该包括event和measurement两类，而目前Cloudkitty并不支持event分析，这也是Cloudkitty不能达到秒级计费精度的根本原因。
由于Blueprint（https://blueprints.launchpad.net/cloudkitty/+spec/rating-for-second-level）基于事件分析的秒级计费实现（https://review.openstack.org/#/c/382127/）还未合并到社区，在此做下详细介绍和举例说明。Event模块预计实现三种插件ceilometer（默认） ， noop（仅测试用）和 panko（等pankoclient完善后再具体实现）。
为了保证数据的一致性和不改变原有计费模型的代码，event模块在事件分析的过程中把从collector模块获得的数据进行分片，各个数据分片以时间为轴，保证了时间的连续性和事件的连贯性，过程中仅维护cur_period['begin']和cur_period['begin_event']字段即可。
new_item['vol']['qty']的值：create事件之前和delete事件之后均置为零，其余片段则按时间占比计算。rate = (generated - cur_period['begin']) / self._collect_period；new_item['vol']['qty'] = item['vol']['qty'] * rate。
如果data一旦被分片则slice_flag标识为真，最后需要做分片后处理，否则返回空[]。
以上是裁剪的代码！另外对item分片的过程中，对于instance和volume需要额外维护desc中的一些字段并配合准确计算qty和适配field，例如volume需要维护size字段，instance需要flavor，vcpus和memory字段等，这些字段的值可以从事件的traits中取得。
上面是一个关于云主机是否使用“基于事件分析的秒级计费”模块，对比计费的例子。instance生命周期内相关的事件有create，resize，resize.revert和delete，跨越了两个计费周期00:00:00至01:00:00和01:00:00至02:00:00，注意cloudkitty.period.cutting事件的位置。
上面两张图来自统计的关于Cloudkitty在N版本的社区贡献情况。可见并不乐观，因此希望借助本次分享能吸引更多的开发者focus到计费项目中。
这里给出了一些实用的blueprints和参与Cloudkitty社区的一些tips。
以上是推荐阅读《OpenStack计费项目Cloudkitty系列文章 一，二，三》和完成这次分享过程中所参考的资料。
最后再次感谢大家，如有纰漏还望雅正！有什么问题欢迎共同探讨！
希望更多的开发者加入到Cloudkitty项目和社区中。希望Cloudkitty能被广泛地落地使用起来，将使用的情况和碰到的问题反馈到社区才能快速地推进cloudkitty走向成熟。
最后再次感谢大家，如有纰漏还望雅正！有什么问题欢迎共同探讨QQ：474751729希望更多的开发者加入到Cloudkitty项目和社区中。希望Cloudkitty能被广泛地落地使用起来，将使用的情况和碰到的问题反馈到社区才能快速地推进cloudkitty走向成熟。
计费周期稳定性怎么样？如何保证准确？
计费周期可在配置文件中设置，默认是一个小时。只有一个周期内能完成所有资源的计费即可。
请问CloudKitty现在能否在生产环境上用，如果在生产环境上使用是否需要二次开发？
可以在生产环境中使用，我们明年将会有客户部署。至于二次开发就得看需求了，我想基本能满足需求，去了解各个租户的费用和资源使用情况，避免浪费资源。
秒级别的计费，有必要吗？
有必要，PPT上面有说明的。
如何保证计费模块cloudkitty数据的唯一性？
依赖于数据源的数据准确性；而计费模型完成计费的过程这是可靠和准确的；费用数据的持久化存储保护数据不丢失。
静态资源和动态资源是二种模式吗？
不是，是我对资源的一种分类，为了方便解释Cloudkitty需要结合event分析对有生命周期的资源进行计费的必要性。
这个cloudkitty，是Openstack官方的project吗？
是的，在bit tent下面。但不是很活跃，也希望借助这次分享吸引更多用户和开发者，把Cloudkitty做成熟。
Cloudkitty对虚拟机内部有监控吗？
Cloudkitty只是计费，没有对虚拟机内部监控。
ceilometer是CloudKitty的子项目吗？
不是。Ceilometer是做监控的，Cloudkitty是做计费的，是两个作用完成不同的项目。Cloudkitty会用到Ceilometer监控获得的数据作为计费的输入。故不存在是否是子项目的问题。
松耦合？ Ceilometer和Cloudkitty
这两个项目在Cloudkitty的collector模块上存在依赖而没有耦合的关系。collector是收集计费源数据的模块，也可以自己实现从cloudstack中获得计量数据，从vmware中获取计量数据。在OpenStack中则多从Ceilometer或者gnocchi中获取。
问个题外话题：据说N版本开始，可以实现“滚动式”升级，不知道Cloudkitty是否具备同样的特性？
我知道kolla中有个bp将Cloudkitty加进去，社区是在利用kolla实现“滚动式”升级。
“推荐活动”
运维世界大会（OpsWorld2016）
深圳站
老王专场+运维自动化专场门票限时只要10元！！！
QQ 1群：434720759（已满）
QQ 2群：131961942，加入密码大写KVM
1000人VMWare技术交流群：494084329，加入密码小写vm
2000人OpenStack开发纯技术群： 334605713 加入密码nova
Cloudstack纯技术交流群：515249455密码cs
2000人桌面云行业讨论： 484979056 加入密码大写VDI
2000人超融合行业讨论群：65779632 加入密码大写HC
2000人云技术招聘求职群: 279875515 加入密码hr
以上是关于云社区分享Cloudkitty – OpenStack计费服务的主要内容，如果未能解决你的问题，请参考以下文章
云原生社区第一次线下 meetup 上海站回顾及 PPT 分享