How to allocate, price and utilize Your OpenStack private cloud resources

OpenStack is often deployed to help improve efficiency for an organization, but without an adequate amount of attention, deployment can run inefficiently and lead to a significant decrease in ROI. In this post, we will cover best practices and lessons learned from monitoring allocation and utilization within OpenStack private cloud environments, and explain several techniques for properly allocating and pricing your resources.

Before deploying OpenStack, it’s important to be aware of your private cloud management capabilities and available resources so that you can allocate them properly. To do that, you must monitor your system with a specific set of tools that analyze usage and trends, enabling you to properly price your resources and appropriately plan capacity.

We’ll start by looking at allocation, then delve into pricing.

Avoiding imbalanced Virtual Machine (VM) allocation

The first place to start in properly utilizing your OpenStack system is to avoid unoptimized CPU  and memory allocation. To ensure efficient and organized allocation in any private cloud environment, you’ll need to define VM types, which are often referred to as ‘flavors’ or ‘families’. The hardware in the example below has a capacity of 16GB of RAM and 16 virtual CPUs (a ratio of 1:1), and the servers are partitioned according to two flavors:

  1. The first flavor is composed of small, medium, and large instances. The small instance has 1 virtual CPU and 1GB of memory; the medium instance has 2 virtual CPUs and 2GBs of memory; and the large instance has 4 virtual CPUs and 4GBs of memory.
  2. The second flavor is composed of a small instance with 1 virtual CPU and 2GBs of memory; the medium instance has 2 virtual CPUs and 4GBs of memory.

In the diagram below, you can clearly see that Flavor 1, configured with a 1:1 ratio of CPU to RAM, optimally allocates the available hardware. However, Flavor 2, with a 2:1 ratio of CPU to RAM, doesn’t demonstrate optimal allocation because all of the RAM is used up with plenty of CPU left over.

As a general rule of thumb to prevent imbalanced allocation, we recommend that both virtual and hardware layers have the same VM to RAM ratio.

Each flavor should maintain the ratio, while doubling the resources of the previous one.  For example, you might have flavors of:


By coordinating with the CPU/RAM ratio of your hardware, you can prevent underutilization of your hardware.

Now let’s look at what these resources are actually costing you.

Calculating the cost of the private cloud

Resource costs in an OpenStack environment take into account a combination of several factors, some of which involve passing expenses back to each business unit.

Resource unit costs

Cloud cost allocation is critical and challenging for financial and accounting enterprise teams, especially when calculating costs for each business unit or project in the cloud. It’s eminently valuable to associate proper resources to their respective costs within any given group or department. Server flavor pricing is not an easy task. First, it is important to calculate the overall cost of the hardware, server room, and manpower that it takes to manage a certain amount of CPU and RAM (e.g. TCO, or the Total Cost of Ownership). You can then divide the TCO by each resource unit, which reveals the specific internal cost of each resource. We’ll refer to this as the “unit list price”.

Private cloud chargeback costs

When it comes to the private cloud, enterprise IT needs to worry about more than just controlling provisioned capacity; there’s also the need to perform resource cost allocation and chargebacks for each business unit. Once you set a resource unit cost, the next step involves calculating the price of each flavor. This simple and straightforward calculation signifies the cost of a single unit that is then multiplied by the amount of units that the flavor holds.

The actual cost of chargebacks per flavor is driven by physical resource utilization. In order to calculate the unit cost per resource, you need to multiply the “actual usage” by the “unit list price”. For example, if hardware is underutilized, the IT department needs to perform a chargeback, compensating for the idle capacity. This means that the cost per resource will be higher than its “list price”. Conversely, if you overcommit CPU usage, the cost per resource is lower.

Eventually, the flavor cost comes out to:

Flavor cost (unit list price, number of units) = unit list price x number of
resources (per flavor) x (average) underutilization/(average) overcommit

* The average is based on monitoring metrics of hardware utilization during a specific period of time (monthly, quarterly).

Obviously, in order to set the chargeback, IT needs to continuously monitor the average utilization and usage and be able to dynamically set flavor costs.

Capacity planning

In private clouds such as OpenStack, jumps in cost tend to occur when more hardware is purchased, requiring new employees for operational support and maintenance, so it’s preferable to avoid that as much as possible in order to maximize ROI.  In the other hand, you need to make sure that you do have enough capacity, so private cloud capacity planning involves defining your utilization policy.

For example, if your policy is to make sure that you’re never less than 15% underutilized to allow for sudden spikes, you’ll need to take that into account when planning purchases. When you know your specific resource hardware utilization levels, your environment, or even the overall cloud, you can make better decisions regarding allocation, as well as purchasing additional hardware.

Continuous Monitoring and Optimization

Strategically allocating your hardware doesn’t guarantee that the hardware will be properly utilized. Contrary to static traditional data center environments, the OpenStack environment’s usage and utilization need to be closely monitored due to their flexible and dynamic nature. Additionally, monitoring utilization levels, including idle capacity trends within specific business units and across organizations, is crucial for hardware allocation, remodeling and resource or workload re-allocation. Maintaining transparency and proactive optimization will generate an efficient environment, avoid new redundant IT capacity purchasing, and maximize your OpenStack cloud ROI.

About Cloudyn

Cloudyn uses Ceilometer, a built-in OpenStack and open source metering module, to measure performance metrics for resources. Cloudyn’s enterprise customers enjoy cloud comparison, monitoring, and optimization tools. Cloudyn’s cost monitoring for OpenStack provides proper visibility and better predictability for cost, resource association, attachment to particular projects or applications, and even the ability to compare OpenStack to public cloud alternatives. Cloudyn offers these tools to help customers engage in balanced decision-making in the modern and heterogeneous enterprise IT environment.

Subscribe to Our Newsletter

Latest Tweets

Suggested Content

Mirantis Cloud Platform
Machine Learning in the Datacenter