Difference between revisions of "Ceilometer/blueprints/PaaSEventUsageCollection"

Revision as of 17:53, 7 October 2013

Introduction

Ceilometer must be able to efficiently extract and process usage information from services in order to properly generate bills. In order to be able to efficiently process usage data, ceilometer requires services to implement a consistent interface. This document describes the metering requirements, use cases and provides a architecture for collection of usage information from Platform as a Service (PaaS) offerings.

Example Use Cases

Database as a Service Database as a Service (DBaaS), i.e. Trove, has an architecture where a service controller manages special Nova compute instances on behalf of the customer. From their perspective they are running instances of a database, not compute instances. Metering and billing will be based on hours that the database has been running, not necessarily how long the hosting instance has been run. This requires a unique set of metering records to be generated and stored to enable usage tracking and billing of the individual database instances. Ceilometer must be able to pull application specific records from the DBaaS service controller or an appropriate intermediary. DNS as a Service DNS as a service runs on a similar service controller architecture to DBaaS. In this case, the meters that need to be measured are the existence of a DNS zone and the number of DNS queries that have been served. Once again these are application level meters that do not correlate directly to the host instances that are running. Queries could be served by a variety of hosts and a DNS zone's existence does not depend on a specific compute instance. Application level metrics must be tracked by the DNS service and reported out so that these systems can be tracked. Ceilometer must be able to pull application specific records from the DNSaaS service controller or an appropriate intermediary. Load Balancing as a Service A load balancer is a logical system that consists of some number of compute instances that host the load balancing software. Meters that must be measured would be things like the existence of a load balancer instance and the amount of data that is being transferred through the system. Once again, this does not directly correlate to the underlying infrastructure but must be reported at the application level. Ceilometer must be able to pull application specific records from the LBSaaS service controller or an appropriate intermediary. Integration Model

Service Ownership

PasS Services are hosted within instances of Nova virtual machines. Variations in the hosting and ownership model have a large effect on the billing model. There are two potential models for ownership: 1. PaaS Service owns the VM instance: in this model VM instances are not visible to the end customer. The owner of the VM is the ?the PaaS service. Usage records generated by Nova refer to the PaaS service controller's ?projectId. 2. End User owns the VM instances: VM instances are visible and can be controlled by the end user. Nova usage records refer to the actual end user ?projectId. Requires some mechanism to differentiate PaaS Nova instances from base Nova instances.

Billing Model

There are several potential billing models for a PaaS service:

1. Base Nova + Premium: in this model a user is charged for the same metrics as the base Nova instances, but with a premium charge. The billing process must be able to identify the PaaS type for each Nova instance. There are two potential ways this identification can be done

• Embedded Usage Record Key: each usage record contains a field that identifies the instance as a specific type. The windows Nova instances are an example of this. The Nova events include a license key that uniquely identifies operating system type. Metering aggregation looks for this key and processes records appropriately. The main disadvantages of this method are that the license key must be inserted by Nova and that it will be difficult to support complicated product bundles.
• PaaS Service provides a list of active instances for their service via a out-of-band method. This could be delivered through a message queue or made available via a dedicated API that the PaaS service controller would need to implement.

2. Application Specific Metrics: in this model a user is not charged for the compute instance resource directly, but for some set of PaaS service/application specific metrics. The PaaS service will generate the usage records and make them available to the metering system. Lower level Nova usage records will be either ignored or attributed to the PaaS service.

Application Specific Integration Architecture

The following architecture supports the collection of PaaS application specific metrics. Note that this architecture relates to a separate blue print that covers the event format itself (PaaS Event Format). The architecture consists of the following components:

• PaaS Service (controller and instances): The PaaS service and instances run inside one or more Nova virtual machines. The PaaS service controller is responsible for instrumenting the system so that the PaaS application specific usage records are generated and delivered to a message queue.
• Message Queue: The message queue infrastructure provides the primary integration point between the PaaS services and ceilometer. Each PaaS service will have a dedicated queue for delivery of events/usage records. The Message Queue infrastructure itself could be deployed in a number of ways: shared as part of the underlying infrastructure, shared in-cloud service, owned by the PaaS service itself. Ceilometer will need a flexible configuration mechanism to map each PaaS metric type to be collected to some endpoint and queue.
• Ceilometer PaaS Event Listener: Provides the ceilometer component that collects PaaS events/usage records from the message queue, translates into ceilometer internal events and then puts them on the ceilometer message bus.

The following diagram shows the high level integration architecture: