customized billing policy

[zpeewee]

Hello,

I would like to know if it is possible to implement such billing policy for vcloud director

Each vDC is implemented with an allocation of 100 GHz and 300 GB memory with a garantee of 50 %.

I would like to charge the user for CPU and memory following this policy

- always charge for the garantee resource (50 Ghz and 150 GB) even if they are not used with a price w per Ghz per hour and a price x per vRam per hour

- charge what is above 50 GHz and 50 GB (charge bursting) with a price y per GHz per hour and a price z per vRam per hour

price for garantee resource and bursting resource are not the same

For example, if my customer use 45 GHz and 125 GB during one hour, he must pay w * 50 + x * 150

Second example, if my customer use 60 Ghz and 200 GB during one hour, he must pay w * 50 + x * 150 + y * (60 - 50) + z * (200 - 150)

Thanks for your help

[cgaussin]

Hi,

No idea ??

I really need some inspirations.

Thanks

[Stephen Parlier]

Aside from what you mentioned, how are your customers accessing the resources they are given? Is this a vCD implementation, do they go through the client to access their servers, etc..? This would actually aid in understanding the setup, and possibly lead to an answer to the questions you pose.

Thanks!

[mbrkic]

I have not tried this yet, but in Chargeback 2.0 this is what the "VMware Cloud Director Billing Policy - Overage Allocation Pool" is supposed to do. From what I understand, this will only make sense when applied to Allocation Pool based ovDCs and you will have to set the "VMware Cloud Director apply overage charge on Allocation Pool vDC" parameter to "true" either in the global config for the vCloud Collector or override it per hierarchy object. There is more info in the Chargeback User Guide as well as in the "Using VMware® vCenter™ Chargeback Manager™ with VMware vCloud® Director" white paper.

Let us know how this works for you.

[zpeewee]

@mbrkic

Your solution looks good.  I will try to implement it on our labo environnment

@bparlier

In attach of this post, you will find a graphical description of what we want to implement (show only the memory).

Customer is in allocation mode with a garantee of 50 % (for example)

The graph in black shows the memory usage evolution over a certain period in time.

Customer pay for red box (=garantee resource) even if the resources are not use.

Every resource that goes outside the garantee (in blue) are pay using a pay per use pattern with an higher price.

Hope this will clarify the situation.

Thanks for your help

[Stephen Parlier]

So based on what you have said and the graphics you sent, mbrkic has the best resolution I believe. Is 2.0 or 2.0.1 the version you are using? If so, you can use the billing policies he has described. You can find more information and tasks in the link below (which has other links to get you going in it as well).

http://www.vmware.com/support/vcbm/doc/vcbm_2_0_0_release_notes.html

[zpeewee]

Hi,

I have tested the solution on version 2.0.1 as proposed by mrikc but it does not come to the expected result.

When i configure the "VMware Cloud Director Billing Policy - Overage Allocation Pool" for an organization where no vm are running, i get a result of 0.

WHen i configure the "VMware Cloud Director Billing Policy - Allocation Pool" for an organization where no vm are running, i get a value different from 0.  At this stage the value use the garantee limit put on the allocation model which is the expected result (but it does not take into account the bursting).

When i read the script associated with the Overage allocation Pool billing policy, i can see that it calculates only the usage on CPU and on memory.  I do not see any elements that use the values defined in the overage parameter on the cost model.

May there is a bug on it.  I have raised the question towards vmware PSO.

[mbrkic]

Hi again,

I have spent some more quality time tweaking and dissecting the Chargeback models and reports and here are my observations and current understanding:

i) As far as I can tell, the overage flag's sole purpose is to tell Chargeback to set the allocation on the allocation based ovDCs to the reservation rather than limit of the corresponding resource pool (there are some issues with this process btw., but that can/should be a separate thread - I have an SR opened on this). If you look at the allocation setting on the entity in Chargeback you should see it corresponding to the reservation number if the flag is set to true.

ii) The way overage works in both vCloud and plain vSphere is that you set the 'base' rate that is applied to all units used below the allocation threshold, and another 'overage' rate for any units used above the allocation threshold. Note that this is the allocation in Chargeback and that for vCloud director ovDCs it is set by the vCloud collector automatically, and in vSphere based hierarchies it can be (and has to be) set manually on the entities (e.g., folders, clusters, resource pools, datacenters). If the amount used is below the allocation only the fraction that is used is billed and it is billed at the base rate. If the amount used is over the allocation then the units above the allocation are charged at the overage rate.

iii) Now we come to the fun part. The billing policy for the vCloud Allocation with Overage is set up to use "usage" which behaves as described above. When applied to an ovDC with allocation model it will NOT charge for the allocated amount regardless of usage (as promised and expected). It is using "usage" and behaves correspondingly. This is a bug (well, misconfiguration technically as it is not code but settings). The workaround is to create another billing policy that uses MAX(allocation, usage) for CPU and use this billing policy with a cost model that specifies overage rate for CPU. This will in-fact produce the expected results - when usage is under allocation it will charge the allocation at the base rate, and when usage is over allocation it will still charge allocation amount at the base rate and add on the amount used over that rate at the 'overage' rate.

iv) The other thing to know is that overage is calculated on a per sample basis, but then averaged over the report period or existence time of the item considered. I am not sure what the exact time interval is, and if it is configurable or not through some setting on the server, but it seems to be basically the sampling period of the collector.

I can provide more details if people are interested.

Hope this helps.

Cheers,

Milos

[zpeewee]

Hi Milos,

Thanks for the clarification.

I still have a question on the modified script you propose as alternative.

If i use MAX(allocation, usage) and i define 2 price values on overage (one upto (X) and second one beyond(Y)), are you sure that if i go over the allocation guarantee level (allocation guarentee level = Z - measured level is W) ,the price will be   X * Z + Y * (W-Z) and not Y * W

How is the calculation script aware that he must use the overage value combined with the MAX parameter on the billing policy script ?

Thanks again for your time.

Regards

Christophe

[mbrkic]

Hi Christophe,

please remember that I am not a vmware employee, so everything l say here comes from 'reverse engineering' the logic from tests and reports. Having said that, I cannot answer your last question, I can only guess that the biling policy is only used to determine how the "used units" are calculated from the different metrics and that the cost model then determines the chargning of these units (i.e., overage). If this is the case, then it does not matter what you use to calculate the used units (as in the MAX function example).

The calculation that you show is correct from my tests. When you look at the pdf report for a case when there is overage you will see something like this:

Above 0.056 is the base rate and 0.067 is the overage rate. The Used Units is actually an average rate (per hour) so the cost calculation in the above example is:

TIME = (23:59 - 12:25) = 11.58 hrs

COST = $0.056 * 0.5 * 11.58 + 0.067 * 1.03 * 11.58 = $1.12

If you look at the detailed usage report you can see that the 1.03 is calculated as a sum of the usage above the allocation (0.5 above) over all the samples divided by the total time period (i.e., it is a weighted average of the overage usage over the time period indicated).

Cheers,

Milos

[Sathyamurthy Hassan]

Hi mbrkic, Christophe,

What you have described here is partially correct way of achieving the goal. However, in vCloud director hierarchies, this works only with CPU resource and not with Memory. Here is why. Below are a few terms before that.

Usage unit: the amount of usage that should be charged for. This could be actual usage, allocation, reservation etc.

Max expression in billing policy: Compare the resource attributes (usage, allocation, reservation etc) and consider the maximum of these, as usage units for charging

Overage : Compare 'rolled up' usage units (summed up usage units of descendants in hierarchy), with defined allocation at a level and charge based on slabs defined.

When you combine both max and overage, we determine usage units to be charged is by comparing 'rolled up' usage units and considering the max among them. For example, max(usage, allocation) would compare rolled up actual usage with rolled up allocation at a org-vdc level and consider the max for charging.

In case of CPU, there is no allocation defined at VM levels (Remember, there are allocations for vCPU count at VM level but not CPU). Therefore rolled up allocation of CPU at org-vdc level is nothing but defined allocation itself, which is set according to percentage guaranteed. This is compared with rolled up actual usage of CPU and if there are any spikes which exceed percentage guaranteed, rolled up actual usage will be considered for charging, and overage will be rightly applied. In case rolled up actual usage is lesser than rolled up allocation, rolled up allocation is considered as usage units for charging and charged.

However, in case of Memory, allocation is defined at VM levels too. Which means the rolled up allocation at org-vdc level is different than the defined memory allocation at that level unless there are no VMs underneath and rolled up value from them amounts to zero. Only in this case, defined allocation at org-vdc will be considered as rolled up allocation. During evaluation, as before, rolled up allocation is compared with rolled up usage and the max among them is considered for charging. Since actual rolled up allocation could be different depending on VMs underneath, it will not give you a effect of minimum charging. For example, on a org-VDC with 100GB memory and % guaranteed 50%, defined allocation at org-vdc level is 50GB. If it has 3 VMS with 2GB Memory each below it, the rolled up allocation is 6GB. Max(usage, allocation) will return 6GB in this case and will be used for charging.

I will anyway confim these results with actual testing and post the results by tomorrow, but if you get a chance in your own setup, please do try it.

The basic problem here is that charging for minimum is not an explicit feature in chargeback and the method you have mentioned helps in some cases. We already have noted this feature request and are considering it for future releases.

Thanks,

Datta

[mbrkic]

Hi Datta,

thanks for this update.

Are you sure that using max and overage together changes how allocation is treated? I just ran a quick test and I see the memory 'units used' determined by the allocation on the ovDC, not the sum of the memory allocations from VMs (which is smaller). This is consistent with how allocation is treated without the max and overage (i.e., consider parent setting, and only look at the children if parent is not set).

My previous posts were all based on CPU, as that is the one that I think you would want to charge overage on. Memory is different. For memory, usage is not really a great measure, since it seems to map to 'consumed' metric in vCenter and that does not follow the VMs memory usage from the guest perspective. Let me explain what I mean. Memory is only released from the VM if there is contention for memory at the host level. This means that once the physical memory is allocated to the VM it will stay allocated to the VM even if the guest OS is not actively using it (hence the difference between consumed and active in vSphere). This leads to an unrealistic definition of memory usage, in my opinion. In order to charge for memory usage there has to be a mechanism for the VMs to release memory voluntarily, otherwise the usage metric is measuring the peak of memory use as long as there is no contention for memory. This is made even less realistic by the fact that some OSes seem to 'touch' a lot of the memory on startup, leading to usage (i.e., consumed) being effectively equivalent to size.

Cheers,

Milos

[zpeewee]

Hi,

Thanks all for your information.

I have tested the model using memory with overage.

I come to a really strange behavior.

1.  When i start measuring on an empty org, i get the value of the garanteed limit (ex : 3 GB are garanteed - 1 € per hour per GB -> 3 € to pay per hour)

2. When i start a virtual machine with 4 GB of ram, i get the value of the memory above the limit (4 GB is used - 100 € per hour per GB for the used / 1 € per hour per GB for the garantee -> 103 € to pay per hour (3 first GB cost 1 € each - the 4th one GB cost 100 €))

3.  The strange now -> when i stop the virtual machine (meaning that the memory is not allocated anymore to the virtual machine), i still get the value as the machine stay running (103 € per hour instead of 3 €)

4. When i upgrade the memory of the machine to 5 GB, the report price per hour becomes 203 € (seems logic).

5. When i stop the vm again, i stay at 203 €

I have wait enough time to be sure that the samplings occur correctly.

I know it would be possible to play with the power ON/OFF machine parameter in the script of the billing policy but the behavior does not follow my understanding of the logic.

Following your experience with the product, is it a side effect of the tuned allocated overage cost model or a new issue ?

Thanks

Christophe

[Sathyamurthy Hassan]

Hi Christope,

My explaination matches your test results.

Milos, are you sure you tested Memory with max(usage, allocation) billing policy? and I agree with you on the Memory charging, that usage is not a great measure.

Christophe, explaination of why results of 1 and 2 are that way are in my previous response. In short, when we use overage+max billing policy we always consider rolled up values from children for computation. Rolled up value by definition is the summed up usage units of children. However, if summed up value is zero, then defined value at the aprent level (which in this case is the guaranteed allocation set at org-vdc level) becomes the rolled up value. I understand this is a little twisted and hence is difficult to use it for cases like minimum charge. Hence we plan to implement minimum charging as a first class feature.

with respect to 3,4, and 5, If a VM is just powered off, then the 'allocation' on the VMs remain as they are, but there will be no 'usage'. If you want to charge only when the VM is powered on, then as you have rightly pointed out, you will have to use the power on/off option of billing policy.

Thanks,

Datta

[mbrkic]

Hi,

Here are the results of my test.

Set-up

=====

Billing Policy:

cpu = max(usage,allocation);
memory = max(allocation,usage);

Cost model has overage charge for memory (note that the costs are artificial to easily see the behavior):

Base rate - $18/hour

Overage rate - $100/hour

Procedure

========

Run usage and cost reports on a folder in vCenter Hierarchy, so that allocation can be adjusted manually.

Change the allocation from 0 to 150 to 200 GB and run the usage and cost reports for the above billing policy.

Results

======

Below are the usage samples for memory for a time that the memory was around 150 (some samples less, some more).

Note that the first one shows the actual usage, since the allocation is set to 0. Second one, with allocation set to 150, shows some samples at 150 and others at the usage value. The last one with 200 shows all the samples at 200 (since actual usage was always < 200).

Allocation not set:

Allocation set to 150 GB:

Allocation set to 200 GB:

Finally, here is the cost report segment for memory for the 150 case, when there is overage:

This clearly shows the 150 base (allocated) and then overage for additional usage.

All this indicates that the behaviour is as expected - usage is rolled up, but allocation is considered at the top (parent) level, and max compares these two and picks the higher for each sample.

Maybe you can illustrate the behaviour that you are seeing, so we can compare?

Note that unlike CPU there are no detailed per vApp and VM summaries in the report for memory, only the total for the whole folder.

Cheers,

Milos

[Sathyamurthy Hassan]

Hi Milos,

The scenario you have described below is just the right one. However, in case of vCloud hierarchies, all VMs are also set with allocation which is equal to configured size of them. So in your setup, under the folder you are testing, set the Memory allocation on all VMs to their configured size. What will happen in this case is: Since there is rolled up allocation available from VMs, the defined allocation at folder level will not be used, and you may see the behavior I described.

Thanks,

Datta

[mbrkic]

Hi Datta,

I repeated the tests like you suggested. One forlder with one VM in it. Allocation set for memory at folder and VM level. I changed them to be different sizes (i.e., folder > VM, folder < VM) and the behaviour was consistent with the CPU behaviour - the folder allocation was used to compare to the usage roll-up. I must be missing something? I also tried to do max{allocation, size} and while the VM was off the allocation was used and when I turned the VM on it changed to size (which was bigger). Overage was applied to units above allocation, at the folder level.

Cheers,

Milos