In my previous blog we discussed the idea of controlling workload demand through Live Migration capability on OpenStack. Let’s extend this discussion by incorporating an additional lever that humans can use to control performance while increasing efficiency: Sizing workloads to OpenStack Flavors. Before workloads are provisioned into the environment, users will need to build nova flavors that define the custom specifications for those VMs. OpenStack offers flexibility in how to create, adjust, and remove these flavor specs as seen below
From here the user can define resource capacities such as VCPUs, GBs for Memory, Ephemeral Storage Disk Size, and ID/Name for the workload(s) that they are offering as part of their services. The first difficulty that organizations need to tackle is how to actually determine what size specs to create based on anticipated application load and differentiated service offerings. Here is the default OpenStack Flavor Specs:
In reality, the IaaS provider is going to customize these flavor specs per its service offerings and user demands. This process needs to be weighed against the differentiated services that the provider plans on delivering to the end user. Some services may be designed for long term workload demands and users that plan on use the workload over lengthy periods of time.
Others may be designed for short term needs such as Web Hosting, or Development cycles that will have heavy initial requirements but decreasing long term needs in the environment. Size it too small for initial deployment: and we run into performance issues…. size it too large and we run into overcommit issues and scheduling conflicts through Nova that prevents us from maximizing the # of VMs possible on existing capacity.
Plus, given the unpredictability of workload demand, organizations must now manage the range of small to large flavor specs in order to cover the gambit of possibilities between what are the expected loads vs what will actually be seen in real time across these services. This increases the chance of overprovisioning physical resources in the environment.
When it comes to a implementing any kind of self-service provisioning workflow, OpenStack administrators are inevitably going to be faced VMWare’s equivalent for “VM Sprawl” for request to fulfillment based on the flavor specs that they choose. Here are some of the considerations that might go into the cloud offering for the initial sizing of workloads:
- What is the adoption rate that I expect from my users?
- What types of workload demands to I anticipate from my service offerings and when do I anticipate heavy requests from each?
- How many virtual machines do I expect to run? In 12 months, in 24 months?
- What is the CPU Overcommitment that we can handle without seeing QoS constraints?
- How many tenants and transactions can I manage through my compute-controllers?
- How many physical machines do I need to initially support the # of instances/flavor specs?
- How many physical machines do I need to support my future workload?
- How do I plan on distributing my workload across segregation methods? Do I choose Cells, Regions, Availability Zones, or Host aggregates?
- Where will I observe the most workload demand based on my differentiated offerings? (Storage, Memory, or CPU?)
Once organizations choose a service catalog and make their way through these challenges, the demand for workloads in real time will begin to drive complexities around managing the in-flight environment. The underlying problem will be centered on the same question we explored in our last blog: How do we assure application performance while simultaneously increasing efficiency. This means finding a place where Flavor Spec sizes can be managed intelligently within the constraints of available capacity and be controlled in real time
Consider a case where a customer demands a virtual machine flavor for a “small” template. Once provisioned, user load increases and the virtual machines begin to demand more resources than available. As an OpenStack administrator, how do we know that this customer needs an increase in template size? And how do we know if there is enough capacity underneath to actually increase the flavor spec itself?
At the same time, would it be better to place the VM on a different compute-node prior to increasing its allocation? What happens to our capacity when one offering demands for resources/instances from our environment over another? – While increasing allocations to workloads that require them will be important for performance, it will be equally important to understand where there is waste in the environment to eliminate allocations that take up valuable capacity for future demands. As we discussed in our previous article, we also need to manage these decisions alongside of real time placement for performance.
When we think about the amount of tenants that will presumably being using the OpenStack environment, the idea of managing flavor sizing across every virtual machine simultaneously will becomes a management nightmare. The end result is the same as before: We are left in a position where administrators must manage the trade-offs associated with sizing flavors in the context of deployment, real time management, and future planning. Missing the mark could mean a significant risk to performance or a considerable overspend on physical infrastructure needed to support the IaaS provider’s changing service offerings