Billing Calculation
Below you will find the description of the billing logic and how the billing is calculated for the following bucket resources:
- Free limits
- Free and free per month limit types
- Calculation for the missing period
- IP addresses
- CPU units
- Instance packages
- DRaaS
If you remove from the bucket a resource that has a virtual server(s) running on it, the pricing for that resource will be removed for such VSs. This behavior refers to user VS limits, template stores, edge groups, recipe groups, backup server zones, and guaranteed minIOPS.
Free Limits
To calculate the free limits, the system first adds up all resources as if there were no free limits configured and then, at the end of the hour, subtracts the cost of free resources from the total amount of used resources.
For example, a user's bucket has the free limit for acceleration set to '2' (VS/hr) and the price for acceleration set to '5 VSs'. If this user creates four VSs with acceleration enabled, at first, the system will calculate the price of all the servers excluding the free limit: 4*5=20. At the end of the billing period (hour), the system will subtract the price of the free resources, in this case, 2*5=10, from the total amount for the used resource: 20-10=10.
Free and Free per Month Resource Limit Types
It is possible to choose hourly or monthly free limits when adding a data store or network zone resources to the OnApp bucket.
When setting the 'free' resource type, the limit for resources is set per hour, and the statistics are gathered hourly and then is compared to the free resource limit. Then, the resource limits which exceed the free amount allowed are billed.
When setting the ''free per month' resource type, the limit for resources is set per month, and the statistics are gathered hourly and then are compared to the free resource limit set per month. When the free limit set per month is exceeded, the exceeding amount is billed based on the overusage price per resource per hour.
For example, a user adds a data store zone with 'free per month' limits to the bucket and sets free data read limit per month to 50 GB:
- During the first hour, 50 GB are used (all the free limit).
- During the second hour, 2 GB are used. As there’s no free limit left, the user is charged for 2 GB per hour.
- During the third hour, 5 GB are used. Since there’s no free limit left, the user is charged for 5 GB per hour (previous 2 GB over limit are not taken into account, since they are already billed).
If a user adds a data store zone with 'free' limits to the billing plan and sets free data read limit per hour to 50 GB:
- During the first hour, 5 GB are used. As the free limit is 50GB the user is not charged (all the free limit).
- During the second hour, 52 GB are used. The user is charged for 2 GB over free limit per hour.
- During the third hour, 55 GB are used. The user is charged for 5 GB per hour overusage (the previous 2 GB over the limit are not taken into account since they are already billed).
Calculation for Missing Period
Under certain circumstances, statistics might be missing for a period of time. This might happen due to daemon issues, cron jobs failures, or some other unexpected errors with the statistics collection mechanism. In such cases, the instant (raw) statistics is aggregated for the whole missing period, and the calculated amount is added into the hourly statistics for the first hour when the services are up again. This behavior is relevant only to the resources which are calculated dynamically on the hourly basis, in particular:
Data store zones | Data read |
| Data written | |
| Input requests | |
| Output requests | |
Network zones | Data received |
| Data sent |
The following scheme demonstrates this behavior for Data Received for network zones as an example:
The last value for data received (Hour1) reported as hourly statistics for the network zone in question was 10GB. Then the OnApp daemon stopped working, and no hourly statistics were generated for Hour2, Hour3, Hour4, and Hour5. On Hour6 the problem was fixed, and daemon was up again. The hourly statistics for Hour6 will aggregate all the statistics for the whole missing period into that hour. Most probably you will get a huge value for the Hour6 as it will be the summary for the whole period when no stats have been reported. Pay attention that the Outstanding amount and Total amount for users will be calculated as per one hour: the whole aggregated statistics will be regarded as statistics per one hour, and compared to the free limits and charged for overusage.
As a workaround, to fix the overcharging for the aggregated stats, you can use the payments functionality. Add the appropriate value as a payment for a user, and it will be subtracted from the Total amount.
Each virtual server has two IP types: regular and outside. Public IP addresses are used for servers’ Internet access. Private IP addresses are used for private networks.
IP addresses
When calculating IP address billing for a particular resource, each virtual server’s IP address is compared to the free IP limit in a linear queue (starting with the first added IP address). Regular IPs are calculated first.
Example
Free IP address limit is 3.
VS 1
The first virtual server has two regular and two outside IP addresses, but the second regular IP address is the same as the second outside IP address, so the number of unique IPs assigned to this virtual server is 3.
VS2
The second virtual server has two regular and two outside IP addresses.
According to the billing algorithm, the first regular IP address checks if there are some IPs added before it and then gets compared to the free IP address limit. 1 < 3, so it is not charged (2 IPs of free limit left).
Then, the second IP address is compared to the remaining free IP address number. 1 < 2, so the second IP also is not charged (1 IP of free limit left).
After that, the outside IPs are calculated:
The first outside IP address checks if there are some outside IPs added before it and then gets compared to the free IP address limit.
1 ≥1, so this IP address is not charged (0 IP of free limit left).
Then, the second outside IP is compared to the remaining free IP address number. There are no free IPs left, but since the second regular IP address equals the second outside IP address, the second IP also is not billed.
Consequently, all IP addresses of the second virtual server are billed, as the free IP address limit is already used up.
One IP address can be added as a regular and an outside IP at the same time. In this case, it will be only charged as a regular one. That is why outside IPs are calculated second.
Port Speed
Port speed is calculated by subtracting the free port speed value from the free port speed limit and summing up the remainders. If the port speed is less than the free port speed limit, it is not billed.
If the NIC port speed is set as Unlimited in the bucket, it means that the maximum port speed value is the value specified in the Control Panel Admin > Settings > Configuration > Max network interface port speed field.
(NIC 1 port speed - free port speed value) + (NIC 2 port speed - free port speed value)..etc
Example
In this example, the free port speed limit is 20 MB/second.
VS 1
The first virtual server has two NICs.
NIC 1 = 10 MB/second
NIC 2 = 25 MB/second
VS 2
Second virtual server has two NICs.
NIC 3 = 10 MB/second
NIC 4 = 30 MB/second
Then, (10 - 20) + (25 - 20) + (10 - 20) + (30 - 20) = 15 MB will be charged.
Since the first and the third NICs are less than the free amount, they are not charged.
Guaranteed minIOPS
Guaranteed minIOPS is calculated by subtracting the free IOPS value from each disk’s IOPS and summing up the remainders. If the disk’s IOPS is less than the free IOPS value, it is not billed.
(Disk 1 IOPS - free IOPS value) + (Disk 2 IOPS - free IOPS value)...etc
Example
In this example, free IOPS = 45
Disk 1 has 50 IOPS
Disk 2 has 45 IOPS
Disk 2 has 60 IOPS
Disk 4 has 20 IOPS
Then: (50-45) + (45-45) + (60-45) + (20-45) = 20 IOPS which is billed.
Since the second and the fourth disks’ IOPS values are less than the free amount, these disks are not billed.
Disk size
When calculating disk size billing for a particular resource, each virtual server’s disk size is compared to the free disk size limit in a linear queue (starting with the first added disk), then each next disk is compared to the free disk size limit remainders.
Example
Free disk size is 50 GB.
We have two virtual servers assigned to the same data store.
VS 1
The first virtual server has two disks.
Disk 1 = 15 GB
Disk 2 = 20 GB
VS 2
The second virtual server has two disks.
Disk 1 = 20 GB
Disk 2 = 15 GB
According to the billing algorithm, the first disk checks if there are disks added before it and then gets compared to the free disk size limit:
15< 50, so it is not charged (35 GB of free disk size limit left).
Then, the second disk is compared to the remaining free disk size limit:
20 < 35 (15 GB of free disk size limit left).
So, the second disk is also not charged.
After that, the second virtual server’s disks are processed. The third disk is compared to the remaining free disk size limit:
20 >15 (20 - 15 = 5, so 5 GB of the disk’s size will be charged).
Finally, the fourth disk is charged for the whole disk size, as the free disk size limit is already reached.
CPU
CPU, CPU shares, and memory limits are set for the compute zone.
When calculating CPU billing for a particular resource, the sum of all virtual server’s CPU over the free limit is billed.
(VS1 CPUs) + (V2 CPUs) + (VS# CPUs) - free CPU limit
Example
Free CPU limit is 3.
If we have two virtual servers:
VS 1
The first VS has 2 CPUs
VS 2
The second VS has 3 CPUs
The number of CPUs charged: (2+3) - 3 = 2
CPU Shares
To calculate the CPU shares price for the virtual server, multiply the number of server’s cores by the CPU priority percentage given.
Then, each virtual server’s CPU priority value is compared to the free CPU shares limit in a linear queue (starting with the first added virtual server), then each next virtual server is compared to the free CPU shares limit remainders.
In this example, free CPU shares limit is 140.
VS 1
The first virtual server has 2 CPUs and 50% CPU priority (100% in total).
VS 2
The second virtual server has 3 CPUs and 40% CPU priority (120% in total).
According to the billing algorithm, the first virtual server checks if there are servers added before it and then gets compared to the free CPU shares limit:
100 < 140, so it is not charged (40 of free CPU shares limit left).
Then, the second virtual server is compared to the remaining CPU shares limit:
120 > 40 (120 – 40 = 80), so 80 percent of this server’s CPU shares will be charged.
CPU Priority
The amount of CPU resource a VS is given is the CPU priority (you can think of this as its "share percentage") multiplied by the number of cores allocated to that VS. This is a minimum number – clients can burst over it by manually adding up to 100% multiplied by the number of cores. You may do it by modifying the CPU priority value at the Adjust Resource Allocation page (Cloud > Virtual Servers > label of the necessary VS > Actions > Options > Edit Virtual Server). For example, on a compute resource with 3GHz CPU cores:
- 100% x 1 core = 3GHz (burstable to 3GHz)
- 10% x 2 cores = 600MHZ (burstable to 6GHz)
- 5 % x 4 cores = 600MHz (burstable to 12GHz)
In other words, you can either create one VS with 100% CPU priority on that HV or 5 VSs with 20% CPU priority (or any other combinations with a total of 100%).
By default, OnApp allows overselling of cloud resources. For example, OnApp will allow users to create 5 VSs with 100% CPU priority/1 CPU core on a compute resource with a 4-core CPU. In this example, OnApp would reduce the guaranteed CPU for each VS.
If you build a VS on a KVM compute resource, the CPU priority settings will be disabled and the CPU priority value will be 100 by default.
Depending on the settings of your cloud (CPU Guarantee), OnApp may allow overselling of cloud resources. For example, OnApp will allow you to create 5 virtual servers with 100% CPU priority/1 CPU core on a compute resource with a 4-core CPU. In this example, OnApp would reduce the guaranteed CPU for each virtual server.
If resource overselling is disabled for your cloud, OnApp will not create virtual servers requiring more CPU resource than it is available on the hypervisor.
You can set the CPU priority to virtual server depending on the virtualization type of the compute resource the server is located on:
- on KVM compute resource under CentOS 6, you can set the 1-100 CPU priority value.
- on KVM hypervisors under CentOS 5, the CPU priority is 100 by default.
CPU Units
The CPU unit is an abstract figure that replaces CPU priority. It is an arbitrary relative value that the host can enter to mark the capacity of the compute resources in a zone. It is the host's responsibility to enter the values per compute resources correctly and logically. You can set the amount of units per compute zone and per each particular compute resource in a zone. If you set the CPU Units per compute zone, then each compute resource in this zone will be assigned the number of units set. To set different capacity to a particular compute resource, specify the CPU units amount to a required compute resource not a zone. To bill for CPU Units, enable CPU units for a bucket and set the price per unit.
Each compute resource core within a zone is given a 1000 CPU Units default value when CPU units are enabled per zone (this is made in the bucket). The Host can then change that number for each compute resource to any other number between 1-100,000 to fit its capacity. The faster the compute resource, the higher the value should be set.
CPU Units show the speed of the CPU - this can be done in any way that the host wants to as it’s just a number that is relative to another number. OnApp will simply process the numbers. For example, if one compute resource is two times more powerful than another, then the CPU units could be 1000 and 500.
To evaluate compute resource’s physical performance, you can take the following values:
- CPU Mhz
- Passmark Score (http://www.cpubenchmark.net/)
- BogoMips (http://en.wikipedia.org/wiki/BogoMips)
When creating a VS, you will specify the desired amount of CPU Units that this VS will take out of total CPU Units set for compute resource.
Example: If you have a compute zone (Compute resourceZ) with 5 compute resources attached to it, and you set 1000 CPU Units to Compute resourceZ zone, then each of five compute resources in this zone will have 1000 CPU Units. In case you would like to increase the capacity of specific Compute resource1 compute resource to 2000 in this Compute resourceZ zone, set the CPU Units option of this Compute resource1 to 2000. For example, giving Compute resource 1 a score of 1000 and Compute resource 2 the score of 500 is the same as giving Compute resource 1 a score of 2 and Compute resource 2 a score of 1. However, the first case gives you more flexibility in spreading the resources between VSs.
When setting CPU units, the main thing is that the correlation between the CPU Units for each compute resource should correspond to the correlation of their actual performance. Example of setting CPU units based on CPU speed:
Compute Resource | Compute Resource CPU Mhz | Compute Resource Units |
A | 4000 | 1000 |
B | 2000 | 500 |
C | 1000 | 250 |
D | 500 | 125 |
Limitations
- CPU Units are available for KVM compute resources only.
- Do not apply CPU Units for KVM compute resources running on VMware, baremetal servers, and load balancers.
- So far only billing calculation can be performed based on CPU units. At this time we do not guarantee the same performance for VSs when migrating to another compute resource with different capacity.
Instance Packages
To set up billing for the instance packages, at first configure the number of available resources in the package at the Admin > Instance Packages > Create Instance Package menu.
Second, add the instance package(s) to the bucket. There you set the price that will be charged per VS powered on/off for each appropriate instance package.
There are also a number of VS resources that are not set up during instance package creation but are configured automatically:
- CPU Priority - CPU priority is automatically set to 100
- Swap disk size - swap disk size can have the size of 1/2/3 GB. Its size is calculated by multiplying the RAM by two.
- IP address - the first available IP address is selected. One IP address is assigned to the VS created using an instance package for free.
- Port speed - depends on the bucket limit. If the port speed Max limit in the bucket is set to unlimited, the port speed in the instance package will also be set to unlimited. If the port speed Max limit in the bucket is set to a certain value, the port speed in the instance package will be set to that same value.
When you build a VS using an instance package, certain bucket limits will not apply to that VS:
- Data read/written and input/output requests are not billed for disks of the VS built using an instance package. The VSs disk size will be defined by the disk size indicated in the selected instance package.
- The Limits & Prices for Network Zones will only apply to the VSs that overuse the bandwidth limit set in the selected instance package. A free IP address is assigned to the VS. The VSs port speed, data sent and data received are not billed until the VS overuses the instance package's bandwidth limit. After that, the data the VS sends and receives will be billed according to the Price over free units cost.
For more information, refer to the Billing for Instance Packages section.
DRaaS
In a bucket, DRaaS resources are a part of User VS limits. You can set the following additional fees for a VS with DRaaS enabled:
- for disk size per GB per hour
- for RAM per GB per hour
- for CPU core per core per hour
- for CPU per percent per hour or CPU per unit per hour
- for node per unit per hour
These prices are additional to regular prices per indicated resources.
Regular price for disk size, set in your bucket, is 10$ per GB per hour. Additionally, you set price for disk size for a VS using DRaaS, as 5$ per GB per hour. So the total price for the VS disk size will be 15$ per GB per hour when DRaaS enabled.
In the case of billing per node, it is calculated how many nodes each VS with DRaaS enabled has. The number of nodes corresponds to the highest resource requirement, e.g. a VS with 1 Core, 1GB RAM, and 20GB Storage is equivalent to two nodes and is charged accordingly.