Page tree

Unsupported content

 

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Skip to end of metadata
Go to start of metadata

To learn more about Chargeback specific to BMC Cloud Lifecycle Management, refer to the following sections:

How does Chargeback for BMC Cloud Lifecycle Management work

BMC Cloud Lifecycle Management stores information about Services that can be requested and provisioned in the Service Catalog. In order for a Service to be available for request, there needs to be a Service Offering (SO) for that Service, that specifies details about how the Service is presented to users for request and how it is priced. Setting a price in the Service Catalog implies that you select a specific Unit of Measure (UoM) corresponding to this price.

When a Service is requested, BMC Cloud Lifecycle Management creates a Contract Line associated with the proper Tenant that specifies the:

  • Service that has been requested
  • Price as per the Catalog at the time of the request
  • Time period for the request

BMC Cloud Lifecycle Management also provisions a Service Offering Instance (SOI), and the related Contract Line contains information about the SOI provisioned for this request.

How are BMC Cloud Lifecycle Management concepts mapped to Chargeback concepts

For each BMC Cloud Lifecycle Management Cloud Services Extractor ETL (connected to a BMC Cloud Lifecycle Management instance) a corresponding Cost Model Template is automatically created in BMC Capacity Optimization. A Cost Model Template contains the full list of cost objects - composite or basic - used by belonging Cost Models. In a Cost Model Template, users can manage the set of report templates automatically executed for all Cost Models and Aggregated reports for the whole integration.

It is important to note, that for each:

  • BMC Cloud Lifecycle Management Tenant, a specific Cost Model is automatically created and updated reflecting the Chargeback information extracted from the BMC Cloud Lifecycle Management instance.
  • BMC Cloud Lifecycle Management Service Offering (SO) a BMC Capacity Optimization Composite Cost Object is created; depending on the pricing model configured in BMC Cloud Lifecycle Management, one or more Basic Cost Objects are assigned to the Composite Cost Object.
  • Service Offering bought by the Tenant (SOI) a specific Allocation of a Composite Cost Object is created.
    • Allocation reflects the validity period of the SOI and contains identifiers and metadata useful for reporting purposes.

Note

Provisioning or decommissioning dates in the SOI are imported in the Allocation, and influence the final charge.

The BMC Cloud Lifecycle Management Services Extractor also populates a domain in the BMC Capacity Optimization workspace section with the list of allocated resources (typically Virtual Machines) provisioned by the SOI. This domain is linked to the allocation and contained entities together with their configuration, and utilization metrics are used for the Cost Model calculation.

Mappings created by the Cloud Services Extractor ETL

The following table shows mappings that are automatically created in BMC Capacity Optimization by the Cloud Services Extractor ETL. For more information, see Extracting cloud services data in BMC Capacity Optimization.

Mappings created by the Cloud Services Extractor ETL

BMC Cloud Lifecycle Management
concept or object

BMC Capacity Optimization
concept or object

Tenant

Cost Model

Service Offering (SO)

Composite Cost Object (CCO)

Service Offering Instance (SOI)

Allocation of a CCO

Contract line start and stop dates

Allocation fields

Compute Containers in an SOI

VMs in the domain in the workspace tree

Prices on SO, RO, or options

Cost rates in Cost Model

Price currency

Single currency at entire Cost Model (tenant level)

Any OOTB Allocation UoM

Corresponding BMC Capacity Optimization metric extracted by Cloud Services Extractor

Any OOTB Utilization UoM

Corresponding BMC Capacity Optimization metric by platform

Chargeback behavior when changes are made to the Service Offering Instance

After the SOI has been provisioned, users in Cloud Lifecycle Management may modify the SOI, either by changing the compute resources assigned (e.g., adding memory to a virtual machine) or by adding or removing compute containers (e.g., virtual machines). The following table shows how these changes affect the Chargeback calculations.

Change made in CLM

Example of change

Effect on Chargeback

More resources added to existing compute container; no prices changed.

More CPUs added to one VM in the SOI

If a CPU allocation price was in effect, then the additional CPUs will be charged starting from when the CLM Cloud Services Extractor discovers the new VM configuration.

If a CPU utilization price was in effect, then the additional CPU utilization will be charged starting from when the vCenter Extractor Service discovers the new CPU utilization.

New compute container added; no prices changed.

One more VM was added to the SOI

 

If any allocation price was in effect, then the additional allocated resources will be charged starting from when the original SOI contract line was created.

If any utilization price was in effect, then the additional utilization will be charged starting from when the infrastructure connector (e.g., vCenter Extractor Service) discovers the new resource utilization.

New compute container added; new instance price assigned

One more VM was added to the SOI, and a per-instance price was set

The new instance price will be charged in addition to any existing instance price, starting from when the VM was added (because a new add-on contract line was started).

New compute container added; new allocation or utilization price assignedOne more VM was added to the SOI, and an allocation or utilization price was setThe new allocation or utilization prices will be ignored, and an error message will be written to the logs as in the section below, "Limitations on supported prices for Option Choices". Chargeback will continue to use the same prices as before the change. Chargeback will increase, applying any prices already in effect.

Workflow of Chargeback for BMC Cloud Lifecycle Management

This section illustrates a series of steps representing a typical workflow of Chargeback for BMC Cloud Lifecycle Management.

  1. The BMC Cloud Lifecycle Management Cloud Services ETL:
    1. Executes daily, and updates 'Cloud Services' information.
      (Tenant > Service > Service Instance (SOI) > Servers)
    2. Calls the Chargeback API, and automatically configures Chargeback Models.
  2. The Chargeback Store Task runs daily and calculates Chargeback results (based on Models).
    These results:
    • Can be browsed through the Chargeback - Admin view in BMC Capacity Optimization.
    • Are stored in the BMC Capacity Optimization repository and saved as Time Series in the Data Warehouse by the Chargeback Store Task.

      Note

      By default, Chargeback Models for BMC Cloud Lifecycle Management are marked as Golden. For all golden models, the Chargeback Store Task collects data of costs as a Time Series in the Data Warehouse (this is a requirement for OOTB Single Instance Reports).

  3. If any Chargeback Reports are scheduled, a Report Executor task exports the results.

The following figure illustrates the workflow with the help of a graphic.

Chargeback for BMC Cloud Lifecycle Management - Workflow

Unit of Measurement (UoM) of BMC Cloud Lifecycle Management cost rates

Prices defined in the BMC Cloud Lifecycle Management SO Catalog are copied into the provisioned SOI, the ETL extracts these prices and generates cost rates in the BMC Capacity Optimization Cost Model of the Tenant. Cost rates are strictly linked to the SOI and the specific Unit of Measurement (UoM). The Currency is imported only for labeling purposes and has a scope for the entire Tenant Cost Model.

As no currency conversion is supported, all SOs bought by a Tenant must be defined with the same currency. If different Tenants buy SOs with coherent currencies, their model results and especially the total charge will be computed correctly. Aggregated reports, summarizing different cost models can report a wrong summarized cost in case of multiple currencies.

BMC Capacity Optimization has a predefined mapping for OOTB BMC Cloud Lifecycle Management UoMs that defines how BMC Capacity Optimization accounts allocations and utilization costs, and which BMC Capacity Optimization metrics are used to compute the consumption of Basic Cost Objects. Consumption combined with the cost rate generates the final cost as it is described in BMC Cloud Lifecycle Management.

There are three kinds of BMC Cloud Lifecycle Management UoMs that are mapped to BMC Capacity Optimization Chargeback cost rates. Refer to the following table for a brief description.

BMC Cloud Lifecycle Management UoMs mapped to BMC Capacity Optimization Chargeback cost rates

Type of
BMC Cloud Lifecycle Management UoM

Description

Example

Flat-rate
allocation

This is the “Instance” UoM in BMC Cloud Lifecycle Management. It means that a single per-unit-time cost is to be charged for the entire Service Offering Instance.

These UoMs are based on BMC Capacity Optimization metrics whose values are extracted from BMC Cloud Lifecycle Management using the BMC Cloud Lifecycle Management services extractor. (BMC - Cloud Lifecycle Management 3.0 - Cloud Services Extractor).

One dollar per day.

Tiered flat-rate
allocation

This kind of UoM, for example, CPU Count, is a per-unit-time cost based on some allocated resource.

These UoMs are based on BMC Capacity Optimization metrics whose values are extracted from BMC Cloud Lifecycle Management using the BMC Cloud Lifecycle Management Services extractor. (BMC - Cloud Lifecycle Management 3.0 - Cloud Services Extractor).

One dollar per CPU per day.

Measured resource
utilization

This kind of UoM is a per-unit-time cost, based on actual resource usage during that time.

These UoMs are based on BMC Capacity Optimization metrics whose values are extracted from the underlying infrastructure resources (for example, VMware vCenter). This extraction is done by the appropriate extractor depending on the data source.

One cent per CPU GHz used per hour.

For more information on mappings, see UoM mapping in BMC Cloud Lifecycle Management.

Note

The Network GB Upload/Download UOMs refer to the amount of data, in GBs, that is received and sent in the network. The price period defined in BMC Cloud Lifecycle Management for those UoMs is irrelevant because in effect, the price defines cost per 1 GB sent/received.

Limitation of supported prices for Option Choice and Post Deploy Action

In Chargeback specific to BMC Cloud Lifecycle Management, the Customer Price(s) supported for Option Choice and Post Deploy Actions are only per instance.

The reason for this limitation is explained with the help of the following example.

Example

  • An SOI has an Initial Storage Allocation of 30GB.
  • You add an Additional Storage Allocation – An Additional 5GB Virtual Disk exercised as an Option Choice.
    With this addition, you now have a total allocation of: 30GB + 5GB = 35GB.

The metric used for Chargeback is unable to distinguish between the Initial Storage Allocation and the Additional Storage Allocation of the exercised Option Choice.

Therefore, if you set a Customer Price of 1.00 USD per Allocated Storage as an Option Choice, the final cost will be 35.00 USD, and not 5.00 USD.

Note

This cost is charged only when the option is bought, because the Customer Price is actually set as an Option Choice.

You can approach this limitation in the following ways:

  • Use a per instance Customer Price in the Option Choice.
    For example: 5.00 USD / per instance / per month.

    In this scenario, the tenant will pay an additional 5.00 USD per month only when he has bought the Option Choice.
  • Set an Allocated Storage Customer Price in the Service Offering.
    For example: 1.00 USD / Allocated Storage GB / per month.

    In this scenario, the tenant will pay 30.00 USD for initial storage, and an additional 5.00 USD when he has bought the Option Choice.

Note

When a Cloud Administrator configures a Customer Price in BMC Cloud Lifecycle Management for a Post Deploy Action or for an Option Choice which is not per instance, the BMC Cloud Lifecycle Management integration for Chargeback generates WARNING messages.

In BMC Cloud Lifecycle Management, there is currently no restriction on the types of Customer Price that a Cloud Administrator can configure for an Option Choice or for a Post Deploy Action, and this can cause a bad configuration. When the ETL discovers this situation, it logs a WARNINGmessage.

 Click here to see a sample WARNING message:

BCO_CHRS_WARN303: Some prices not supported were found.
Only per instance prices are allowed for the option choice.
Selected option choice line : 2012-08-20 03:49:05 - ?
(REGAA5V0ACW92AMJBPWKA1W4KW64AR)
Option -> Add Disk - Additional Virtual System Disk
(B86F46FB-0BB4-EB96-9632-40145A894D09)
Option choice -> 5GB 
Following prices are not supported and they will be skipped:
- Allocated GB / Month - na 
(REGAA5V0ACW92AMJBPWKA1V2AA64A9) -> 1.0USD MEMCNT per MNTH
Only these prices will be imported:
- Add Disk - 5GB VMDK (UNKNOW) -> 0.0USD INST per 1TIME
- One Time Setup Fee - na 
(REGAA5V0ACW92AMJBPWKA1VE0I64A7) -> 5.0USD INST per 1TIME

Customization of UoM mapping

The default mapping between BMC Capacity Optimization objects and BMC Cloud Lifecycle Management units of measures comes OOTB with BMC Capacity Optimization. If needed, it is possible to redefine those rules in order to support a new custom UoM.

The BMC Cloud Lifecycle Management Cloud Services Extractor uses a .XML configuration file that describes how the BMC Cloud Lifecycle Management unit of measures must be mapped into chargeback costs. It defines the type of UoM, and the BMC Capacity Optimization metric that is associated with different technologies.

Each BMC Cloud Lifecycle Management UoM is described by the uom tag that contains all the information needed by BMC Capacity Optimization to create the related chargeback elements.

Structure of a XML configuration file used by the BMC Cloud Lifecycle Management Cloud Services Extractor

This section discusses the following:

Structure and composition of a XML configuration file

This section illustrates the elements used in the example XML configuration file that is used by the BMC Cloud Lifecycle Management Cloud Services Extractor.

The following tables per section describe each element the XML configuration file consists of, according to the relevant tags in the XML structure.

uom tag

UoM name

Internal name of the BMC Cloud Lifecycle Management unit of measure.

skip

True if the UoM should not be imported for the chargeback purpose

utilizationCost

Element used to describe utilization cost.

instanceCost

Element used to describe instance cost.

instanceCost tag

instanceCost

Element used to describe instance cost.

consumptionUnit

Label used for the consumption unit.

costUnit

Label used for the cost unit.

fixedPricePeriod

Override the price period specified in BMC Cloud Lifecycle Management.
Allowed values are: 1TIME HOUR, DAY, WEEK, MONTH, QUARTER, YEAR

utilizationCost tag

typenm
(Required)

Semicolon separated values of the type of resource to be extracted.
Allowed values are:

  • gm:wvn (Virtual Node - VMware)
  • gm:xen (Virtual Machine - Xen)
  • gm:kvm (Virtual Machine - KVM)
  • gen (Physical server)

metricName
(Required)

BMC Capacity Optimization metric name.

scaleFactor
(Default: 1)

A consumption scale factor. This value is multiplied by daily consumption

subresource
(Default: GLOBAL)

BMC Capacity Optimization subresource name.

interpolation
(Default: false)

If true, a last value algorithm is used in order to fill data gaps

fixedPricePeriod

Override the price period specified in BMC Cloud Lifecycle Management. Allowed values are: 1TIME HOUR, DAY, WEEK, MONTH, QUARTER, YEAR

*Tip*

You can override the configuration file of the Cloud Services Extractor by uploading your own custom XML file in the primary scheduler host, and manually add the chargeback.client.file.path property to the run configuration of the extractor, along with the path of the configuration file. The following graphic illustrates the property.

Note

The custom configuration file must contain all definitions of the UoM available in BMC Cloud Lifecycle Management. The easiest way to customize the UoM mapping is to make a copy of the OOTB configuration file, and then modify it as needed.

An example illustrating a section of a XML configuration file

The following code snippet is an example illustrating a section of a .XML configuration file.

<!-- Instance -->
<uom name="INST">
	<instanceCost>
		<consumptionUnit>Inst Hour</consumptionUnit>
		<costUnit>Inst</costUnit>
	</instanceCost>
</uom>

<!-- Allocated Storage GB -->
<uom name="GB">
	<utilizationCost typenm="gm:vmw;gm:kvm;gm:xen;gen">
		<metricName>REQUESTED_DISK_SIZE</metricName>
		<interpolation>true</interpolation>
		<consumptionUnit>GB Hour</consumptionUnit>
		<costUnit>GB</costUnit>
		<scaleFactor>2^(-30)</scaleFactor>
	</utilizationCost>
</uom>

Sample copy of the OOTB XML configuration file

To download a sample copy of the OOTB XML configuration file for the BMC Cloud Lifecycle Management Cloud Services Extractor, click here.

Chargeback API calls applicable to Chargeback for BMC Cloud Lifecycle Management

Among all API calls documented for Chargeback in BMC Capacity Optimization, the only two kinds applicable to Chargeback for BMC Cloud Lifecycle Management are:

The other API calls are applicable only if you are building custom Chargeback models.

Related topics