VMware vRealize Tenant App Design

VMware vRealize Tenant App Design #

VMware supports thousands of partners to host and sell clouds built on VMware technology using vCenter and Cloud Director (VCD). While vCenter provides the core of virtualization, Cloud Director provides needed constructs for segmenting the virtual infrastructure appropriately and offering it as a service to tenants of these partners.

As can be imagined, there are several variants of infrastructure that can be sold by these partners such as “Pay as you go”, “Raw capacity” aka “Allocation based”, “Raw capacity with minimum guarantee” aka “Reservation based”, “Flex” i.e. “a combination of others”. Potentially combination of these could be offered to same tenants. It becomes challenging to track usage over a period and charge appropriately due to this complexity. In addition, tenants demand for a transparency in this billing, and it is imperative that service providers offer it.

vRealize Operations Tenant App (TA) sets out to solve these problems by metering the infrastructure. Further, it provides options to configure different models for pricing this metered infrastructure. Finally, it closes the loop by providing tenant specific views that help tenants validate their charges by looking at usage.

Architecture of TA is based on

  • Data collector that collects data from vCenter, VCD and NSX,
  • Pricing engine, that applies the charging policies defined by provider on the collected data

The collector and the pricing engine reside inside vRealize Operations Manager (vROps). TA appliance acts as a simple interface for creating pricing policies and storing generated “Bill”. TA appliance also provides a plugin to expose Tenant views inside VCD.

Because of these criterion, deployment of TA needs two Virtual Appliances namely the TA Virtual Appliance and the vROps Virtual Appliance. Partners who are already running vROps will be able to just connect Tenant App and begin, and those who do not can start with deploying the Chargeback Licensed edition of vROps.

Configuration of TA post deployment involves configuring vROps, Cloud Director, vCenter, and NSX. vROps connection is used for metering of collected data and bill generation. Cloud director connection is used for user management, providing Tenant view, and for collection of data from VCD using vROps VA. vCenter connection is used for collecting inventory changes and metering data about virtual machines using vROps. NSX connection is used for collecting usage information on network elements such as edges, load balancers, firewalls, etc. using vROps data collectors.

A functional flow of using TA involves

  • Defining pricing policies
  • Associating these pricing policies to Org- VDCs coming from VCD
  • Generating bills and reports (showback) using this combination
  • Exposing these bills and other usage data to Tenants
  • Providing an isolated view of the infrastructure and services for each tenant

Functional Flow Diagram

Graphical user interface, application Description automatically generated

Pricing policies have several variants such as their infrastructure scope of application (e.g.: Allocation pool, PAYG, Reservation pool), charge rates for different resources (e.g.: 2$/vCPU/Day, 1$/GB RAM configuration/Day) and conditions for applying the rates (E.g.: Only when powered on, slabbed rate or overage). Associating pricing policies to org VDCs sets up a combination that can be used henceforth for all metering and billing. Bills are created on-demand based on provider’s request and contain a detailed result of applying a pricing policy on and Org-VDC. Reports are customizable entities containing historical data about pricing and usage. They can be scheduled and exported to formats such as CSV and PDF. A plugin to VCD allows these bills and usage data to be exposed to tenants. In addition, Tenant App provides a set of dashboards that can be exposed to tenants.

Licensing #

Tenant App works in one of the two license modes.

  • Chargeback License: This license mode enables basic functionalities of Tenant App including metering for Cloud Director, vCenter and NSX based infrastructure. The license key is applied from vROps UI, post which the UI of vROps is turned off and can be used only as a headless data collection and pricing engine.
  • vROps entitled mode: If the partner is entitled to any variant of vROps already, he can continue to use the same vROps as a backend for Tenant App. In such cases, the partner gets additional flexibility of using vROps UI and perform customizations such as custom reports and dashboards based on his entitlement.

Deployment Architecture for vRealize Operations Tenant App for vCloud Director #

The following architecture provides an overview of integration of Tenant App with vCenter, vCloud Director, and NSX Management Packs.

Graphical user interface, application Description automatically generated

You can receive data from vCenter, vCloud Director, and NSX Management Packs.

  • vRealize Operations Manager collects resources from vCenter, vCloud Director, and NSX Management Packs using their respective Management Pack plugins and displays it in the vRealize Operations Manager Database.
  • vRealize Operations Tenant App for vCloud Director interacts with vRealize Operations Manager using the Suite APIs (internal/external) to collect resources and pricing information.
  • A service provider performs configuration actions using the standalone Tenant App UI.
  • The tenant can either use vRealize Operations Manager Tenant App Plugin UI or the standalone Tenant App UI.
  • All requests from Tenant App for vRealize OperationsvCloud Director are sent through Nginx Forward Proxy and the configuration is as displayed in the Deployment Architecture workflow diagram.

As can be seen in the diagram, combination of Tenant App appliance and vROps appliance together help service providers meter their infrastructure. vROps acts as the data collection engine talking to endpoints such as vCenter and Cloud Director using its management packs. Installation and configuration of these management packs are covered in Administration Guide of Tenant App. Tenant App adds a pricing layer on top of these collected metrics by allowing configuration of the pricing engine. The pricing engine itself runs inside the vROps appliance and outputs the pricing metrics back into vROps. So in essence for a provider, Tenant App VA acts as the configuration interface for pricing policies, whereas vROps acts as the single source of metrics for all collected and processed information. Full list of collected and processed metrics can be found in the addendum at the end of this white paper.

Tenant App VA also acts as the User interface that can be configured and plugged into Cloud Director to be accessed by Tenant Administrators. It provides summary information of usage and metered charges to Tenants of a provider.

Virtual Machines are priced depending on how long they live in the environment. Tenant App and vROps can track VMs to a minimum granularity of 5 minutes and charge them i.e. even if the VM is alive only for 5 minutes, pricing engine will be able to associate a charge with this VM and roll it up.

Architecture and Port Requirements #

The following architecture provides the port requirement for the integration of vRealize Operations Tenant App for vCloud Director.

Integration of vRealize Operations Tenant App for vCloud Director as a plug-in #

Graphical user interface, application Description automatically generated

The following architecture provides the port requirement of the vRealize Operations Tenant App for vCloud Director as a stand-alone app.

Integration of vRealize Operations Tenant App for vCloud Director as a stand-alone App #

Graphical user interface, application Description automatically generated

Deployment Model #

If the deployment is in a vCloud Director based cloud deployment, follow the design for vRealize Operations Tenant App for vCloud Director as a plug-in.

Design Decisions #

Deploy a vRealize Operations Tenant App appliance at each physical site where there’s a vCloud Director deployment that will use the plug-in. IE - if you have two physical sites; one in New York and one in Los Angeles, deploy a Tenat App appliance at each site that will connect to the local vCloud Director.

A public DNS name and IP will need to be allocated for each site that will resolve to the local Tenant App appliance, such as vta01.ny.cloud.mycompany.com. You can DNAT the public IP to the private IP assigned to the Tenant App appliance.

Pricing Policies #

This section provides details on various elements of pricing policy and how each of the components work in different scenarios, computation algorithm is described in detail.

Base Settings #

Policy Name #

Service provider admin will provide a relevant name to policy; one policy can be eventually assigned to multiple organization VDC. Each Organization in Cloud Director corresponds to one tenant, so pricing policy provides flexibility at much granular level (Org-VDC) so that differential charging can be done for different tenants (organizations) as well as multiple Org-VDCs within same tenant (organization).

Pricing Policy Type #

This corresponds to types of allocation models (Allocation pool, Reservation pool and Pay-as-you-go) in VCD. This field is just used as an identifier only, so that when you create a policy you can assign a label to it so as to later associate it with appropriate organization VDC of same allocation model selected.

The choice here decides how you charge for CPU and memory. For details, refer to Table 1.1

Currency #

This is the currency in which pricing is setup and bills are generated, this currency is same as set in vROps. In vROps navigate to Administration > Management > Global Settings > Currency to set this value. Please note that this can be set only once per installation and cannot be modified once set.

Policy Description #

Any additional details to be mentioned about pricing policy.

CPU Rate #

Charge CPU based on #

This is applicable when admin selects policy type as PAYG, where pricing happens at virtual machine level, and admin can choose to charge CPU based on either gHZ or based on vCPU count.

Charge Period #

A specific price can be applied with different periodicity such as Hourly, Daily and Monthly. The base rate and fixed cost mentioned will get applied based on this frequency.

Charge Based on #

For each allocation model in VCD admin can define specific rules based on which chargeback can happen, it can be based on resource allocation, usage or reservation (guaranteed resource) or max of two entities (usage vs allocation, usage vs reservation). The details of which value will be considered in computation based on this set rule is described in the below table.

Table 1.1

Pricing Policy, Type / Allocation Model Charge Based Power State CPU Memory
Allocation Pool Charged on Org-VDC Org-VDC
Allocation Not Applicable / No Impact CPU Allocation (GHz) Memory Allocation (GB)
Reservation Not Applicable / No Impact CPU Resoures Guaranteed (GHz) Memory Resources Guranteed (GB)
Usage Not Applicable / No Impact CPU Allocation Used (GHz) Memory Allocation Used (GB)
Max (Allocation, Usage) Not Applicable / No Impact Usage can go beyond what is allocated, so take whichever is higher Usage can go beyond what is allocated, so take whichever is higher
Max (Reservation, Usage) Not Applicable / No Impact Usage can go beyond what is guaranteed, so take whichever is higher Usage can go beyond what is guaranteed, so take whichever is higher
Reservation Pool Charged on Org-VDC Org-VDC
Allocation Not Applicable / No Impact Same as allocation, as 100% is guranteed Same as allocation, as 100% is guranteed
Usage Not Applicable / No Impact CPU Reservation Used (GHz) Memory Reservation Used (GB)
Max (Allocation, Usage) Not Applicable / No Impact Usage can go beyond what is allocated, so take whichever is higher Usage can go beyond what is allocated, so take whichever is higher
Max (Reservation, Usage) Not Applicable / No Impact Usage can go beyond what is guaranteed, so take whichever is higher Usage can go beyond what is guaranteed, so take whichever is higher
Pay As You Go Charged on VM VM
Allocation Not Applicable / No Impact Amount of configured CPU GHz at the VM level Amount of configured Membory GB at the VM level
Usage Not Applicable / No Impact CPU demand at the VM level Memory demand at the VM level

Default Base Rate #

Specific the rate or price at which you would like to charge the resource under consideration, this value will be multiplied accordingly with resource metered value to arrive at final charge to tenant in the bill generated.

Chage Based on Power State #

This rule is applicable for PAYG type of polices, where charging is done at virtual machine level and chargeback can be done based on three available options: Always, Only when powered-on, Powered-on at least once.

  • Always: do not consider VM uptime, charge irrespective of that
  • Only when powered-on: Charge will be prorated based on uptime
    • Example: if daily charge is 10$ per gHZ for CPU and specific VM was only 20 min a day, then charge will be prorated based on the fraction (20/1440), where 1440 is total minutes in day.
  • Power-on at Least Once: In this case full charge is applied even if VM is switched on at least once for minimum duration of minute.

Charge Overage #

This rule is applicable only to allocation pool model, where guaranteed resources are some % of total available resources. In this case till guaranteed %, normal base rate will be applied. If usage goes beyond guaranteed %, the rate mentioned in overage will be applied (for the delta usage which is higher than guaranteed).

  • Example: in allocation pool model for specific Org-VDC if allocated CPU is 10 gHZ and guaranteed is 50%, which is 5 gHZ, the normal base rate is 3$ per gHZ and overage base rate is 4$, then if usage is found to be 6.5 gHZ, then for 1.5 gHZ the overage rate of 4$ is applicable and below which normal base rate of 3$ will be applicable.

CPU Base Rate Slab #

The service provider may want to charge differently based on the volume of resources consumed.

  • Example: If usage is under 2 vCPUs, then default Base Rate $4 per vCPU will be applied for whole usage. If usage is greater than 2 vCPU, then Base Rate $6 per vCPU will be applied for whole usage.

Fixed Cost #

This price is applied to resource under consideration irrespective of resource metering. The difference between base rate and fixed cost is that base rate gets multiplied with resource metered quantity, if there is no resource consumption/allocation base rate will not be applied whereas fixed cost gets applied irrespective of metered resource. Fixed cost follows the charge period.

  • Example: charge period = If the per vCPU rate is $2 and a fixed cost of $10 is specified for a VM that has 4 vCPUs, charges will be computed as 4vCPUs*$2 + $10 = $18

Memory Rate #

Please refer to the “CPU rate” section, as all the fields and rules are similar in nature except that resource under consideration will be memory metered in MBs.

Price Based on Sizing Policy #

There may be Service Providers that do not want to charge per vCPU or per GB RAM, instead they want standard pricing templates for charging their customers (similar to the concept in AWS where they have Small, Medium, Large, T2 Small, R2 Large etc.)

Sizing policies are predefined templates that are present in Cloud Director wherein you create a combo of vCPU and memory sizes and enter a rate against it.

In this, the price is based on VM Size instead of per CPU or Memory GB Charge individually.

Storage Rate #

Charge Storaged Based on #

Admin has two options here, Storage policies and Default rate.. When ‘storage polices’ option is selected, admin can do a ‘differential’ pricing based on storage tiers as set in VCD, for specific Org-VDC. When ‘Default rate’ is selected, for all the datastore same base rate mentioned will be applicable irrespective of storage tiers (Default Rate is a legacy option and will be deprecated soon).

  • Example: if the storage policies created in Cloud Director are Gold, Silver and Bronze tiers, a differential price of 4$, 3$ and 2$ per GB per month can be applied based on storage tiers.

Storage charges are not only applicable at the Org-VDC and VM level. But, they are also applicable for independent disks, media files, vApp templates.

Charge Based on: VMs can be charged based on configured storage by selecting ‘Limit’ as an option or based on the actual storage consumed by them based on ‘Usage’ as the option in pricing policy.

Storage Base Rate Slab #

The service provider may want to charge differently based on the storage consumed by the VM. So, in Storage also, we can charge based on the slab of consumption. Many Service providers provide a discounted rate if the consumption by VMs is higher.

  • Example: If you want to charge a VM consuming 100GB of storage at a lower rate ($1 per month) compared to a VM consuming 50GB of storage that is charged at $1.5 per GB per month. In such a case, base rates will be configured as “greater than or equal to:50GB”, “base rate:1”, “default base rate:1.5”. In such a case, a VM having 150GB of storage will be charged $150 a month and a VM having 30GB of storage will be charged $45 a month.

Graphical user interface, application Description automatically generated

Price Settings #

There are two types of Storage Pricing Policy Settings

  1. Aggregate storage charges from Storage profiles for PAYG Org-VDCs - this is the default mode for Storage Policy settings, and it includes overhead storage such as swap disks and log disks.
  2. Aggregate storage charges from VMs, media, vApp templates and independent disks for PAYG Org-VDCs – When the provider doesn’t want to charge the overheads to the users.

Please refer to the “CPU rate” section for other configuration parameters and rules, as all the fields and rules are similar in nature except that resource under consideration will be storage metered in GBs.

Network Rate #

Tenant app charges network only at edge gateway level and not at the individual VM level.

Tenant App can charge for Edge gateways that are backed either by NSXV or NSXT. The same pricing rate card fields are used for charging either of these networks. The details of which metrics will be used in each case are given in the metrics table towards the end of this document.

External Network Transmit #

Tenant app captures the egress data from edge gateway which in turn is associated with specific Org-VDC. Admin can apply a specific base rate ‘per mb’ of data transfer. The data is measured per edge gateway. All the traffic going through the network is charged here regardless of whether it’s going through the internet or not.

External Network Receive #

Tenant app captures the ingress data from edge gateway which in turn is associated with specific Org-VDC. Admin can apply a specific base rate ‘per mb’ of data transfer. The data is measured per edge gateway. All the traffic going through the network is charged here regardless of whether it’s going through the internet or not.

Network Transmit Rate (Bandwidth) #

There are 3 ways of charging bandwidth here.

  1. Conservative – In this this case the Service Providers charge for the average bandwidth consumed by the customer. This is more in favour of the customer and less in that of the Service Provider.
  2. Aggressive – Here, the Service Provider charges the whole usage at the peak bandwidth usage. This is more in favour of the Service Provider and less in that of the Customer
    • Example: The consumption rate is $10 per GBPS. If the average bandwidth usage is 5GBPS. But, the peak bandwidth used is 8GBPS. In this case, the tenant be charged $80 and not $50.
  3. Moderate – In this case, the Service Provider would charge at the 95th Percentile value of the bandwidth.
    • Example: The user has had 100 usage samples of Bandwidths 1 to 100 GBPS each respectively. In this case, the peak bandwidth is 100 GBPS and average bandwidth is 50 GBPS. But, in a moderate pricing mechanism, the charge would be calculated on the basis of 95th percentile i.e. with respect to 95 GBPS.

Network Receive Rate (Bandwidth) #

There are 3 ways of charging bandwidth here.

  1. Conservative – In this this case the Service Providers charge for the average bandwidth consumed by the customer. This is more in favour of the customer and less in that of the Service Provider.
    • Example: You have a 10 GBPS line and the rate is $10 per GBPS. But your average bandwidth usage is 5GBPS. Here you’ll be charged $50.
  2. Aggressive – Here, the Service Provider charges the whole usage at the peak bandwidth usage. This is more in favour of the Service Provider and less in that of the Customer.
    • Example: The consumption rate is $10 per GBPS. If the average bandwidth usage is 5GBPS. But, the peak bandwidth used is 8GBPS. In this case, the tenant be charged $80 and not $50.
  3. Moderate – In this case, the Service Provider would charge at the 95th Percentile value of the bandwidth.
    • Example: The user has had 100 usage samples of bandwidths 1 to 100 GBPS each respectively. In this case, the peak bandwidth is 100 GBPS and average bandwidth is 50 GBPS. But, in a moderate pricing mechanism, the charge would be calculated on the basis of 95th percentile i.e. with respect to 95 GBPS.

Advanced Network Rate #

Edge Services #

Apart from the basic data transfer, there are additional value added services offered in Cloud Director in combination with NSX.

All the network services associated with specific edge such as HA, DHCP, IPV6, IP Sec, Load Balancer, NAT, SSL VPN, L2 VPN, Firewall, Static Routing, BGP Routing, OSPF Routing are considered for charging based on these services are ‘Enabled’ or not. If services are enabled for specific day and base rate is applied for that service, then that particular service gets charged for that specific day. If the service is disabled on any day then base rate will not get applied.

IP Count #

These are the unique IP counts available on the external network of the Org-VDC. Pricing can be performed based on the count of these IPs.

Edge Gateway Sizes #

Tenant app understands the size of the edge gateway (Compact, Large, Extra Large and Quad Large) and differential price can be assigned based on the edge size.

NSXT Services #

Tenant app now allows you to price for NSXT services like Firewall Charges (per firewall rule count), L2VPN charges (per L2VPN count), Load Balancer Charges (per load balancer count).

Guest OS Rate #

Guest OS for a specific VM can be charged to apply based on licensing costs. The Guest OS name should be mentioned as displayed in the VCD for specific VM.

In future, Guest OS name will be a dropdown in tenant app policy creation for the admin to select from the available list.

Cloud Director Availability #

Cloud Director availability services can be priced on the basis of replication objects that are created in a Cloud Director availability solution.

Replication objects occupy certain amount of storage and have special qualities dependent on SLA profile that they belong to.

  • Example: If the storage policies created in Cloud Director are Gold, Silver and Bronze tiers, a differential price of 4$, 3$ and 2$ per GB per month can be applied based on storage tiers. These prices for the replication objects will be the same depending on the storage profile the belong to.

Replication objects are also charged on the basis of the SLA profiles that they belong to. SLA profile defines attributes of these replication objects such as how frequently is the backup taking place, how many back-ups are preserved etc. Based on these SLA profiles, you can add additional costs on top of it.

  • Example: If it is a ‘High frequency’ SLA profile, then you may want to charge an additional $100 per month for the given replication object.

There is ‘Storage Usage Charge’ section to set additional pricing for storage used by Cloud Director Availability replications in Cloud Director. Please note that the storage usage defined here will be added additionally to the Storage Policy Base Rate.

These replication objects will now be visible in the bill with their corresponding charges.

vCenter Tag Rate #

If a VM is tagged with specific key (tag category) and value (tag value) in vCenter then this key-value can be specified to charge a VM or bunch of VMs differentially. Any VM having the specific tag will get this charge applied based on charge period.

vCenter tag based charges that are added can be individually saved or obtained based on a setting ‘meteringTagDetailedMetricsEnabled’. When this setting is enabled, you can see each of the charges added here in this vCenter tag based section as an individual metric in vROps and hence in Tenant app as well.

How to Use the Confige File #

In EACH NODE within the vROps cluster should be performed the following steps:

  1. Connect the vROps node via SSH.
  2. Open and add/edit appropriate configuration in “$ALIVE_BASE/user/conf/analytics/advanced.properties” file.
  3. Restart the analytics service via “service vmware-vcops restart analytics” command.

Below shows a flag to enable/disable the publishing of particular flag specific prices as metrics on VMs.

Item Value
Confige Name meteringTagDetailMetricsEnabled
Default Value false
Possible Values true/false
Example meteringTagDetailedMetricsEnabled=true

These can be used when you want to apply additional charge for the applications running on the VM.

  • Example: You want to charge additional $10 if there is an SQL server installed (across all VMs). In this case you can set a tag like “SQL Server = True” for these VMs in vCenter. Then, in Tenant App’s Pricing Policy, add a tag “SQL Server” with the value “True” and a rate of “$10” per month. This would apply an additional charge of $10 per month for all the VMs with the tag “SQL Server = True”.

vCenter Tag Alternative Pricing Policy #

Within vCenter Tag rate, there is an ability to configure ‘Alternate Pricing Policy’, that allows the user to configure an additional charge for each vCPU that may have value added services enabled.

  • Example: For all VMs that have SQL server, you want to charge a different rate per vCPU per month. Say, a VM is charged at $1 per vcpu per month and you want to charge the SQL enabled VMs at $2 per vcpu per month. Here, you can create an alternate pricing policy like ‘SQL Server pricing policy’ that charges $2 per vCPU and $2 per GB RAM. In Tenant App Pricing Policy, you can apply a condition that if ‘SQL Server’ tag = ‘True’ then the Alternate pricing policy should be ‘SQL server pricing policy’

VCD Metadata Rate #

Very similar to VM Tags (as defined in the vCenter), admin can make use of VCD specific tags which are known as VCD Metadata. Objects with which specific metadata is associated will get the charge based on pricing attached to it in VCD metadata rate section of pricing policy.

These can be used when you want to apply additional charge for the applications running on the VM.

Metadata based charges that are added can be individually saved or obtained based on a setting ‘meteringTagDetailedMetricsEnabled’. When this setting is enabled, you can see each of the charges added here in this metadata based section as an individual metric in vROps and hence in Tenant app as well. “ref to section above”.

  • Example: You want to charge additional $10 if there is an SQL server installed (across all VMs). In this case you can use a VCD metadata like “SQL Server = True” for these VMs in VCD. Then, in Tenant App pricing policy, add the metadata tag “SQL Server” with the value “True” and a rate of “$10” per month. This would apply an additional charge of $10 per month for all the VMs with the tag “SQL Server = True”.

VCD Alternative Pricing Policy #

Within VCD Metadata, there is an ability to configure ‘Alternate Pricing Policy’, that allows the user to configure an additional charge for each vCPU that may have value added services enabled.

  • Example: For all VMs that have SQL server, you want to charge a different rate per vCPU per month. Say, a VM is charged at $1 per vcpu per month and you want to charge the SQL enabled VMs at $2 per vcpu per month. Here, you can create an alternate pricing policy like ‘SQL Server pricing policy’ that charges $2 per vCPU and $2 per GB RAM. In Tenant App Pricing Policy, you can apply a condition that if ‘SQL Server’ tag = ‘True’ then the Alternate pricing policy should be ‘SQL server pricing policy’.

Note: This mechanism can effectively be used when charging for FLEX Org-VDCs

One Time Fixed Cost #

One time fixed cost is a charge levied by the Service Providers for the events (service or resource provisioning) that happen at a point in time (not regularly or periodically).

  • Example: The charge of a new VM creation can be added as a ‘one time fixed cost’. Or, the Service Provider may address a support ticket that can be charged additionally, every time there’s a ticket that is addressed. This can also be configured with tags i.e. whenever you address a service request, you can add the tag (or VCD metadata)‘SR addressed’, the value ‘true’ on the VM. In Tenant App, if you have configured the Pricing Policy to add a ‘one time fixed cost’ when ‘SR Addressed’ = ‘True’ and one time fixed cost = ‘$50’, then the VM will get an additional ‘one time fixed cost’ of ‘$50’ in the bill. This one time fixed cost will be added every time the VM gets a tag ‘SR Addressed’ = ‘True’.

Note: In the above example, if the Service Provider intends to add ‘SR Addressed’ = ‘True’ cost every time an SR is addressed, then the recommended way is to set the tag ‘SR addressed =True’, leave it for a period of time (e.g. 2 hours) and then remove the tag.

Rate Factors #

Rate factors are used to either bump up or discount the prices either against individual resources consumed by the Virtual Machines, or whole charges against the Virtual Machine.

For VCD Metadata, you can change the price per vCPU, Memory, Storage Policy, Data In, Data Out, Bandwidth In, Bandwidth Out

For vCenter tag, you can change the price per vCPU, Memory, Storage Policy

  • Example 1: Discount overall charge on VM by 50% (Rate Factor 0.5) for all VMs tagged with Promo=True. So, if the cost of VM as per the base rate is $100 then after applying the Rate Factor for promotional VMs (or Promo = True), it’ll be $50'

Graphical user interface, application Description automatically generated

  • Example 2: Increase Storage rate by 100% (Rate Factor 2) for all VMs backed up by Avamar with tag ‘Avamar_Backed_Up = True’. In this case, the storage cost of VM as per the base rate is $100, then after applying the mentioned tag, it’ll become $200.

Graphical user interface, application Description automatically generated

Tanzue Kubernetes Clusters #

‘Tanzu Kubernetes Clusters’ section of the Pricing Policy helps you charge for Tanzu Kubernetes clusters and objects below an Org VDC based on certain attributes of Kubernetes like CPU, Storage, Memory and fixed cost per cluster.

  • Example: You could apply a fixed charge of $100 per cluster per month with additional CPU charge of $0.1 per CPU ghz based on usage or allocation, similarly $0.05 per Memory GB based on usage or allocation and $0.05 per GB storage. You can also define a base rate slab to charge differently after different degree of usage.

CSE Kubernetes Clusters #

‘CSE Kubernetes Clusters’ section of the Pricing Policy helps you charge for CSE Kubernetes clusters and objects below an Org VDC based on certain attributes of Kubernetes like CPU, Storage, Memory and fixed cost per cluster.

  • Example: You could apply a fixed charge of $100 per cluster per month with additional CPU charge of $0.1 per CPU ghz based on usage or allocation, similarly $0.05 per Memory GB based on usage or allocation and $0.05 per GB storage. You can also define a base rate slab to charge differently after different degree of usage.

Additional Fixed Cost #

This section is used to add any other costs that are to be applied at Org-VDC level. This can be used for charges such as overall tax, overall discounts etc. These can be applied to selective Org-VDCs based on Org-VDC metadata.

Graphical user interface, application Description automatically generated

  1. In the above screenshot, any Org-VDC with the above Pricing Policy enabled will be charged with $50 as an additional fixed cost per month
  2. Additionally, if the Org-VDC is tagged with the metadata ‘Snapshots Enabled = True’ will be charged $10 per day
  3. Also, if the Org-VDC has the ‘Installation Charge = True’ tag enabled, then an additional charge of $100 will be applied as a one-time fixed cost.

Reports and Bills #

Once these rates are set using the billing policy, they can be applied to organization VDCs in two different ways.

  1. You can assign a pricing policy to an organization VDC once, and vROps starts automatically calculating price metrics for the given Org-VDC and its resources using the assigned pricing policy. Subsequently, either customized reports can be created in vROps containing usage and price metrics, or prebuilt reports can be accessed from Tenant App. The advantage of setting up reports is that they can be scheduled and exported to formats such as PDF and CSV. You can also generate reports for the tenants to view directly at their end and send an email notification when reports become available.
  2. You can generate an On-Demand Bill by selecting an organization VDC and a pricing policy. This calculates the prices of Org-VDC and associated resources as per the values of the Pricing Policy at that point in time and presents a Bill inside Tenant App. This bill can be also shared with tenants.
  3. You can schedule bill generation, by selecting an Organization-VDC, a pricing policy and enable Schedule Bill setting. Then define the Recurrence (Monthly or Weekly), and detailed days of the billing period.

Note: This bill is typically used by the Service Providers via an API to read the details and feed to their own billing systems

Alerts #

You can enable and select the type of alerts to be shared with the customer to view at their end. An email notification is also triggered to the tenants on the alerts enabled for them.

Differences Between Tenant App and Chargeback Manager / Usage Meter #

vRealize Operations Tenant App today does not present rollups of usage in units of MB.hours, but in terms of $ cost. This can be worked around by setting a cost of $1/MB.hr. vRealize Operations has all the individual data points, which can be accessed through the Tenant App APIs. A detailed description of the metrics used for the bill creation and API usage examples can be found in the Appendix.

However, the collection interval, collection methods and rollup methods of vRealize Operations differs from Chargeback Manager / Usage Meter.