EfficientMetering
Efficient Metering in OpenStack Blueprint
Related resources
- http://wiki.openstack.org/utilizationdata
- Swift
- Retrieve Account Metadata http://docs.openstack.org/bexar/openstack-object-storage/developer/content/ch03s01.html#d5e388
- swift middlewares examples :
Uses cases
- need a tool to collect per customer usage
- need an API to query collected data from existing billing system
- data needed per customer, with an hour level granularity, includes:
- Compute - Nova:
- instances (type, availability zone) - hourly usage
- cpu - hourly usage
- ram - hourly usage
- nova volume block device (type, availability zone) - hourly usage
- reserved
- used
- network (data in/out, availability zone) - hourly bytes + total bytes
- differentiate between internal and external end-points
- External floating IP - hourly bytes + total bytes
- Compute - Nova:
- Storage - Swift
- total data stored
- data in/out - hourly bytes + total bytes
- differentiate between internal and external end-points
^l
Proposed design
Counters
The following is a first list of counters that needs to be collected in order to allow billing systems to perform their tasks. This list must be expandable over time and each administrator must have the possibility to enable or disable each counter based on his local needs.
Counter name | Component | Volume unit | Secondary | |
c1 | instance | nova compute | minute | type |
c2 | cpu | nova compute | minute | type |
c3 | ram | nova compute | Megabyte | |
c4 | disk | nova compute | Megabyte | |
v1 | bd_reserved | nova volume | Megabyte | |
v2 | bd_used | nova volume | Megabyte | |
n1 | net_in_int | nova network | Kbytes | |
n2 | net_in_ext | nova network | Kbytes | |
n3 | net_out_int | nova network | Kbytes | |
n4 | net_out_ext | nova network | Kbytes | |
n5 | net_float | nova network | count | |
o1 | obj_volume | swift | Megabytes | |
o2 | obj_in_int | swift | Kbytes | |
o3 | obj_in_ext | swift | Kbytes | |
o4 | obj_out_int | swift | Kbytes | |
o5 | obj_out_ext | swift | Kbytes |
Note for network counters (n1-n4): the distinction between internal and external traffic requires that internal networks be explicitly listed in the agent configuration.
Agents
- Agent on each nova compute node to accumulate and send counters for c1, c2, c3, n1, n2, n3, n4. The agent is likely to be pulling this information from libvirt.
- Agent on each nova volume node to accumulate and send counters for v1, v2
- Agent on each swift proxy to forward existing accounting data o1 and accumulate and send o2-o5
Note: nova network node need not accumulate and send counters for n5 because they can be pulled directly from the nova database ( see nova-manage floating list for instance )
Storage
- Data is stored on a per account basis in a db on a per availability zone basis
- Per account records hold
- account_id (same as keystone’s)
- account_state (enabled, credit disabled, admin disabled)
- Per event records hold
- account_id
- counter_type
- counter_volume
- counter_duration
- counter_datetime
- message_signature
- message_id
- db is not directly accessible by any other mean than API
- a process must collect messages from agent and store data
- a process may validate counters against nova event database
- a process may verify that messages were not lost
- a process may verify that accounts states are in sync with keystone
Messaging
- data is sent from agents to storage via a trusted messaging system (RabbitMQ?)
- message queue is separate from other queues
- messages in queue are signed and non repudiable (see link for explanation on this exotic word)
API
- Database can only be queried via a REST API
- Requests must be authenticated (separate from keystone, or only linked to accounting type account)
- API Server must be able to be redundant
- Requests allow to
- GET account_id list
- SET account_id state
- When this is called, the API server transfers the request to the keystone database to ensure account state is in sync
- GET list of counter_type
- GET list of events per account
- optional start and end for counter_datetime
- optional counter_type
- GET list of events per account
- GET sum of (counter_volume, counter_duration) for counter_type and account_id
- optional start and end for counter_datetime