内容


云计量和计费

云计算资源的计费计量

Comments

综合考虑 IT 资源和费用,可以确定每个部门或每个人的盈利能力和费用分配。如果组织在使用资源之前或之后都不能确定 IT 资源的费用,而且也不知道哪个部门、哪个人使用了资源,但是为了能使服务仍然可用并得到维护而持续付费,这并不是正确的做法。例如,如果从网络上获得一项新服务,以及一个通用数据库,那么无法确定谁会为数据库或服务器空间以及长期容量规划而付费(这些总的来说是一种失败,可这种失败可能对组织的客户带来影响)。

云计算本身不能帮助组织来确定由谁为资源付费,但它提供了一个基础架构设计的平台,可以建立一个计量和计费的扣款模型。本文描述了一些计量和收费功能,可用于已经实现的云计算模式和正在开发中的模式。

云计算计费影响

每个可用的云模型都有自己关于如何确定资源分配的规则,而且这些规则在支付能力和费用模式上与传统的 IT 业务模型不同。每一项服务成本降低,IT 资源分配得到改善,这使得普通 IT 部门的资本支出 变成了服务和用户的运营支出。例如,每个请求的消息队列 GETPUT 操作数会构成每个客户的成本结构,进而累计为每个事务的总成本,最终形成每个用户每月的成本(和手机账单一样)。

在您的代码中考虑云的成本分配

如果计量是基于事务,并且利用云计算成本分配模型,那么要确定将成本特定的设计模式包含在您的应用程序代码中。如果在应用程序架构中没有设计关于每次使用应用程序资源的费用的模式,那么它就无法为您的组织提供任何合适的架构来采用下一代云计算计量和计费功能。例如,开发下一代、基于服务的平台并利用云计算可提供一种经济实用的新方法进行计算,但该平台可能在提供可根据需要进行伸缩的创新性解决方案方面有所缺失。

设置一个事务目标,追踪提交的每一个 HTTP 或 SOAP 请求及基于云的应用程序的相关成本。由于资源(服务器硬件、数据库请求、消息队列或监视服务)根据实际使用收费,您必须在每一步和资源调用中包含事务用户 ID。例如,如果调用外部服务获取数据库的数据,相关的 HTTP 请求就应该包含事务 ID 和用户 ID 以在以后关联这些度量。当然,这些应用程序中还应该有额外的线程来获取事务关联数据以免核心事务性能和响应时间受到影响。

图 1 显示了一个汉堡包制造者事务的示例,它包含了不同的 SOA 服务并使用了事务 ID。所有节点上都部署了代理以获取每个事务的事务数据。这里,t1234 是识别事务的事务 ID;每个服务绑定对应事务 ID 的 CPU 运行时间,用于以后计费和计量。

图 1. 使用 SOA 服务和事务 ID 的事务示例
使用 SOA 服务和事务 ID 的事务示例
使用 SOA 服务和事务 ID 的事务示例

操作

云计算计量和计费的操作在一些基础架构(即公共基础架构)中已经提供,但在一些构建在企业应用程序服务器基础架构的私有云中仍然需要。主要的差异是安全需求,因为大多数应用程序特定的计费和计量与私有或公共云计算是类似的。因此,还需要一些额外的运营基础架构项目用于计量和收费,例如获取使用数据的消息服务。所以必须要考虑到,需要部署额外的基础架构项目来管理云计算计量和收费资源的使用和成本。

已建立的服务模式

有些服务模式设计之初就比传统的程序更加创新。尽管如此,对于云计算基础架构的计量和计费,它们非常完善而很有用。重要的是要注意实现了哪种模式,例如,服务器以每小时 US$0.10 计费,而非以大量的前端采购成本计费。

基础架构即服务(Infrastructure as a Service)以及计费和计量服务

配置服务器和基础架构的高昂成本曾一度限制了开发软件即服务(SaaS) 应用的能力。例如,需要花费几周甚至几个月的时间来规划、预定、装运和安装数据中心的新服务器硬件。现在,新的计费和计量方式让硬件和操作系统(基础架构即服务 IaaS)的采购只需要几分钟就可完成(参见 图 2)。

图 2. IaaS 平台的每月帐户活动
图片显示 IaaS 平台的每月帐户活动
图片显示 IaaS 平台的每月帐户活动

IaaS 的基本概念包括:

  • 服务器每小时按需服务的模式
  • 保留服务器以备更好地规划
  • 根据应用程序性能增加或减少计算资源单元
  • 根据使用的实例数进行基于存储卷的计量
  • 预付与预留的基础架构资源
  • 集群服务器资源

这些元素大多是按照每月计费,每台服务器在几分钟之内就按初始配置释放并返回。整个月累积的收费包含运行整整 30 天和只运行了一分钟的服务器实例。每个计算过程都按一小时收费,而不管它运行了一分钟还是一小时。

而使用预留实例的高级计费和规划能降低每月和每小时的成本,从而能够使计算资源模型具有已知使用模式,并且能够根据需要建立底线。在提前预留服务器的模式中,必须有一个初始投入以保护某些区域的特定服务器,从而最小化虚拟机 (VM) 每小时的使用量。某些情况下,初始的投入会让每小时的费用降低 50% 以上。

大多数情况下,非高峰时间降低实例数,高峰时间增加实例数能帮助改善可用性和响应时间。通常,如果将应用程序适当调整,那么当云计算基础架构中添加服务器后,每秒处理的事务率应该会直线上升。惟一会出问题的是第三方的资源与基础架构没有按指数率进行调整,例如,数据库、认证服务以及其他可伸缩的基础架构访问的服务。

在某些已启动的服务器上,由于运行着大量虚拟服务器,会出现一些折扣,例如,当您保留 100 个 VM 时。这些折扣会帮助云计算供应商规划容量需求,从而将按需实例的成本和风险降到最低。同样,预付实例能帮助云计算供应商估算容量,并最大地降低耗尽资源或过多占用未使用实例的风险。如果在某段时间内资源未使用,折扣和使用都会过期。例如,可以将预付实例用于基线计算资源(面向外部的企业内部网的 Web 服务器)。

在大型部署中,启动和停止实例和按照集群利用率进行计费与 IaaS 管理都合在一起。单个服务器的管理和资源利用会随着企业应用程序的增加而增加,按照集群收费(可能包括自定义资源,如路由器和其他设备和服务)可帮助降低管理成本。

平台即服务(Platform as a Service)以及计费和计量服务

由于平台在总量和实例层使用度量方面不同,平台即服务(PaaS) 收费和计量是根据实际使用确定的。实际使用收费让 PaaS 供应商能根据使用监视的粒度在同组硬件上的多租户中运行程序代码。例如,每个事务或每个应用程序的网络带宽、CPU 利用率和磁盘利用率可确定 PaaS 的成本。

PaaS 计量和计费的主要概念包括:

  • 传入和传出的网络带宽
  • 每小时的 CPU 使用时间
  • 存储数据
  • 高可用性
  • 每月服务收费

网络传入传出的流量带宽决定了每个用户的使用量并为计费和计量建立了度量。带宽度量很有帮助,因为 Web 应用程序根据内容会进行扩展。例如,对于很多返回简单 WSDL 和 RESTful 负载的 Web 服务,与包含大量图片、视频和音频媒体的事务相比,行数很少。

基于每小时、每分钟或每秒钟 CPU 时间进行的事务和 HTTP 请求计量是最准确的计费和计量模式,因为可以计算总成本中每个事务的成本。由于无法精确计量每个事务用户在每个请求中使用了多少 CPU 资源,所以很难在用户层上分配资源。因此,一个简单而有效的计费和计量方法是确定用户使用的存储数据量。这么做可以帮助对服务进行容量规划、计费和计量,例如存储即服务,大量数据存储在基础架构中的服务器上。在这种情况下,使用基于千兆字节的收费模式来确定每个月服务的成本是多少。

在所有的企业应用程序中,服务的质量(大多数情况下)是实施计划投入和价格的双倍(有时会超过双倍),因为会复制基础架构并包含额外的基础架构项目来支持高可用性。高可用性计费和计量能在需求可预测的情况下根据实际需要提升服务的质量。

在计费和计量方面存在实例层功能局限的高级平台,会选择提供通用计费模式,这种模式在运行应用程序代码时会产生固定费用。这样的平台通常包含对不长期运行的安全代码、耗费 CPU 的事务,以及其他内置的安全措施的需求来遏制基础架构的利用率。例如,有一个平台,其中应用程序代码部署为文件,而底层运行时间具有平台即服务供应商提供的增强的安全措施和可伸缩性。

SaaS 以及计费和计量服务

对 SaaS 应用程序计费和计量的传统观念是每月固定费用;有些情况下,根据数据量或 “座位数”,对计费和定价进行了优化。用户的数量取决于组织允许访问 SaaS 应用程序的用户数,这会增加每月费用的价格;有些情况下,如果达到一定量的存储卷数,会有折扣。例如,将销售软件作为服务,对于使用该应用程序的公司来说,每个销售代理处每月花费 US$50。

SaaS 计量和计费的主要概念包括:

  • 每月订阅费用
  • 每个用户每月费用

每月订阅费用是固定的,一般以一年作为最短协议期。这样按月计费的模式将高昂的初期软件资本投资改变成按月运营费用。这样的模式对中小型组织特别有吸引力,可以帮助他们快速启动开展业务所需的软件。可伸缩性(或随增长而付费模式)对于那些初始投入很小、员工不多、随着需求变化的公司来说很有帮助。有些情况下,这些组织在访问相同数据时可以缩小规模。

日趋重要的服务模式

还有一些辅助服务模式正在开发过程中,其中许多已将计费和计量模式标准化,现在已受到企业各层的认可。由于 SaaS 的认可度越来越高,那么很有可能这些新兴的服务模式的应用也会越来越广。例如,数据即服务 (DaaS) 和监视即服务(MaaS) 正被 SaaS 供应商采用,并得到了云计算和专注于 SaaS IT 的公司的支持。

DaaS 以及计费和计量服务

传统的企业数据库基础架构和软件基础架构的区别是内置的可伸缩性和按实际使用量付费。DaaS 基础架构采用了以下概念:

  • 数据库服务器实例
  • 可伸缩的云计算数据库服务

目前大公司基础架构中存在的数据库实例已经开始使用基础架构即服务平台,并使用已有的许可协议。这样的基础工作可以帮助在 DaaS 模型中实现许可协议。例如,有许可的用户可以运行云计算基础架构中每个内核中相同的数据库实例。

可以使用基于云计算可伸缩性来创建数据库,并按实际使用量计费,通常是根据服务器上执行的请求数。此模型可以帮助确定软件和数据库基础架构的实际使用量。有时候,由于一个请求会比通常情况使用更多的 CPU 时间,DaaS 供应商会将 CPU 运行时间包含到数据库使用量计费中。例如,一项长期运行的保险事务可能包括使用数百毫秒响应时间,以及插入的成千上万行数,而财务支付事务在这方面的使用会较少,端到端响应时间只在 200 毫秒范围内。

MaaS 以及收费和计量服务

向现有的监视基础架构添加 MaaS 需要考虑基础架构的可用性需求。MaaS 基础架构采用了以下概念:

  • 外部服务监视
  • 监视基础架构的实例
  • CPU 运行时间

将外部服务应用于监视已经出现一段时间了,它提供了一种功能,可以从软件开发人员的数据中心通过检验或综合事务来检查 IT 资源。此服务一般是根据实际使用量、监视程序执行事务的间隔和收集数据的周期而按月计费。例如,如果在公司网站监视事务,会将每个 HTTP 添加到监视基础架构的提供者中,并按照 200 个 URL 的完整包进行计费。该解决方案不需要组织安排行政人员来管理监视基础架构,并且它是按照月份计费的。

供应商和软件开发合作伙伴还可以提供更复杂的基础架构来监视完整架构作为软件服务,它可以由客户进行维护,并且可按需进行计费和计量。这需要在软件和操作系统级别进行监视管理,一般还包含硬件和基础架构。对于计费,用户既可以按月支付费用,也可以再利用现有的企业许可证。

基于 CPU 运行时间的 MaaS 可确定每个请求的实际使用量,然后再在每个月底会合并使用量。如果没确定实际使用量,就难以为小型和大型客户提供可伸缩解决方案,因为使用量会各有差异。例如,在事件管理中,会处理每个事务请求的过滤器,其度量表是 CPU 运行时间的所有复合事务服务的总和。

结束语

SaaS 的计量和计费功能提供了满足业务目标的模式,满足了对大型组织业务单元的详细记录的需求,并降低了初创公司和小型企业的初始投资。SaaS 将大量的初始投资和软件采购转变成对实际使用量的满足,并让新的项目能在之前未作预算的情况下利用企业级软件。另外,对于事务负载的大量存储卷的可伸缩性不仅仅可用于企业。

同样,从资本支出到运营支出的转变可以实现更精确的计费和计量模式,这些模式可满足基于部门使用量记录的需求。例如,销售部门现在可以根据实际使用量添加新用户,而不会增加复杂性和采购新硬件、软件和管理资源的成本。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=767714
ArticleTitle=云计量和计费
publish-date=10242011