Applied approach for creating flavors

OpenStack team decided to bundle five default flavors into the system from the early versions of the OpenStack that is providing a list of general templates. Often in projects, Cloud engineers define their own sets of flavors as they find the default list very general and simple. The objective of this article is to analyze the “Flavors” and to form a new list of flavors to help OpenStack admin in order to build a suitable and more usable cloud infrastructure. The list will be compiled by following a methodology to compile and analyze a list of factors that are being used by OpenStack engineers and identify the factors they used to create their flavors. It is expected that the results shed lights and assist OpenStack cloud administrators to create and maintain their instances effectively.

Analyzing flavors in cloud providers

Cloud providers provide variety combination of the flavor to serve variety range of customer applications needs, which lead to cloud users can deploy VMs with flavors, which they are the excellent fit for their applications.

By analyzing our findings, we can conclude that proper management of the flavors includes the following best practices :

• Naming convention
• Flavor categories
• Flavor approach
• Larger ephemeral disk size approaches on flavor

Naming convention

As a general rule, it is recommended by experts to use a naming convention to define flavors. It’s not only a common practice for OpenStack. Other cloud platforms like AWS use a standardized naming convention. It is suggested to create a standard prefix for templates to help administrator to manage them. Such rules not only can be applied to VM templates but also flavors can get the benefit of it.  A proper naming convention for flavors can help administrator to know what can be derived from the flavors.

Naming of a flavor is defined as <category><generation>.<size>

The category reflects different application requirements in terms of performance (general purpose, CPU bound, memory bound, maybe more in the future). The generation is used to identify new iterations of the category. Like if we want to redefine “general purpose” for example in some way, we can increment the generation. Generation instances for users who have optimized their applications around instances.
Increase the number of generation lead to faster processors, larger host memory, faster network, and an additional instance size which delivers practically all of the compute and memory resources of the host hardware to our instances and we get a higher performing CPU with support.
The size defines the compute power (CPU and memory).

Flavor categories

Cloud providers need to consider different properties that a flavor influence it or crap it such as CPU model, CPU speed, memory speed, ephemeral storage size, ephemeral provisioned storage, etc. The main factors to define a flavor are CPU, hard disk and memory.  A proper combination of these factors is crucial because it will result in improving the performance of the application by utilizing a adequate mix of resources. Flavors are comprised of three main categories. They can be categorized based on the application usage, which these bounding categories include memory bound (MB), CPU bound (CB) and general purpose  (GP).

Memory Bound

The Memory bound means the application is bottlenecked by memory. Memory bound is a term used in the situations when the time to complete a given function is determined by the required amount of memory that can hold data. The only way to run more apps concurrently is growth the size of RAM.

CPU Bound

The CPU bound means the application is bottlenecked by an excessive amount of processing in the CPU that the limiting element in an algorithm is doing the computation. Additional CPU horsepower leads to increase the speed and run more complex calculations or operations.

General Purpose

The General purpose is something between CPU bound and Memory bound. It is for applications that do not fall into existing categories neither CPU bound categories nor memory bound categories.

The balanced mixture of the CPU and RAM or the efficient combination of CPU to RAM is more important factors, which cloud provider should consider it and expand it at least to the three main bounding categories.

After the analyzing and extracting the OpenStack categories below are the summary of OpenStack ratios:

The ratio of CPU to RAM for memory bound is 1:4

The ratio of CPU to RAM for CPU bound is 1:1

The ratio of CPU to RAM for general purpose is 1:2

We can expand this combination of CPU to RAM by bonding it with other categories such as small, medium, large and Xlarge. Such bounding will allow us to have the more flexible combination for more efficient resource planning and management for our instances.

Flavor Approach

If we consider the table of OpenStack flavor approach. We can realize that the sum of the RAM ratio for MB is 28, and the sum of the RAM ratio for CB is 7. The average of these ratios is 17.5. It is against the sum of the RAM ratio for GP, which it is 14. These ratios lead to having at least one physical server for each category.

In other words, if VM1 uses CB.small flavor with 1 vCPU and 1 GB virtual memory, and then VM2 uses  Mb.small flavor with 1 vCPU and 4 GB virtual memories. In total, we have 2 vCPUs and 5 GB virtual RAM. The ratio of 2:5 will be 1: 2.5, Which it is against of 1:2 at GP ratio.

For solving this problem, A new ratio is offered that uses the average of the ratios (MB, CB, GP), which it is GP ratio. The CPU to RAM ratio of MB is 1:3, the CPU to RAM ratio of CB is 1:1 and The CPU to RAM ratio of GP is 1:2.  All flavors can be deployed to the same physical server and we do not have to have at least three physical server for covering each ratio, which the average ratio leads to reduce the physical hardware to buy, as the mentioned advantage of this approach. In other words, cloud provider can share the physical hardware for all ratios at the same time. By considering our ratio, providers can allocate the remaining memory from CP VMs to the MB VMs as long as the average is GP(1:2).  

For example, if VM1 uses CB.small flavor with 1 vCPU and 1 GB virtual memory, and then VM2 uses Mb.small flavor with 1 vCPU and 3 GB virtual memories. In total, we have 2 vCPUs and 4 GB virtual RAM. The ratio of 2:4 will be 1: 2, which it follows GP ratio(1:2) nicely.

If we consider the table of the proposed approach, we can realize that the sum of the RAM ratio for MB is 21, and the sum of the RAM ratio for CB is 7. The average of these ratios is 14. It follows the ratio of GP, which the sum of the RAM ratio for GP is 14.

Extracting ratios below are the summary of the new efficient ratios after researching and analyzing categories:

The ratio of CPU to RAM for memory bound is 1:3
The ratio of CPU to RAM for CPU bound is 1:1
The ratio of CPU to RAM for general purpose is 1:2

If we consider that cloud users have more tendencies to create the mixture of large size and small size of the flavor. Under which condition this mixture works more efficient. For example, cloud users deploy CB only as “large” size and MB only as “small” size. So in the example above, the ratio of MB.small and CB.large is 5:7 =(4+1):(4+3), so if all N machines have similar usage patterns, we will still have N*13 MB of memory left and N*5 CPU left over on the physical host. Cloud users will consume approximately as many CB resources as they will consume MB resources. On average, the sum of CB and MB resources will follow the 1:2 ratio of the GP type.

1:2=5:7+x

x=5:13

(5+5):(7+13)=10:20

1:2 = 1:2

Therefore, we can assume that the average VM will be the ratio 1:2 and we can size our physical server accordingly. We can find more details accordingly as a following:

Please consider that a combination of the same size follows the GP ratio as well. For example, if users deploy CB only as “large” size and MB only as “Large” size as well. The ratio of cb1.large is 4:4 and the ratio of mb1.large are 4:12. Which the sum of CPU to RAM will be 8:16. It follows 1:2 ratio. (1:2=1:2)

Larger ephemeral disk size approaches on flavor

Cloud provider can create a new larger size for every combination of the category and generation by considering two following approach:

Approach 1:

Cloud providers create a new larger size for every combination of the category and generation. The new size will increment with CPU and memory according to our defined per-category ratios and the apply the growth factor. The new size will provide 40GB of ephemeral disk space. 

Option 1 is a valid argument to assume that bigger VMs in terms of CPU and memory will also need more disk space. Either the application itself or the data it works with will be larger. The advantage of this approach minimizes the number of flavors. The fewer flavors the more convenient for the user since he has to choose from a much smaller list. We can quickly provide even bigger ephemeral disks by adding only three additional flavors. Our option one might not be valid. Maybe there will be much smaller VMs needing 40GB of disk space, which we can consider as a disadvantage.

Approach 2:

Cloud providers introduce a new generation to the list of existing categories and starting with “generation 2” we have more disk space reserved for VMs. The new generation will provide 40GB ephemeral disk space while CPU and RAM will remain unchanged compared to generation 1.

Option 2 is a valid argument to assume that there is not any relation between computing power and disk space. An application is able to not only to use more disk space but also to use the right computing power. Whit the more variations available to choose from, the option which was not provided in the approach 1.

This approach can provide a more variety of flavors with the different category and size. There is the big variety of combination which, the user can choose, what the application needs and the user can have more possibility to choose from which can be a better fit with their application on VMs to satisfy greater storage needs. The second generation of flavor can provide the big variety of combination of the category and size which, The user can create more numbers of VMs with the bigger size of disk space for using different applications. Although it is giving the user more flexibility to choose from, it increases the number of flavors which might be considered confusing for the user since he has to select from a much bigger list.  

Option 2
Cat	Gen	Size		CPU	RAM	HDD
gp	1	small		1	2	20
gp	1	medium		2	4	20
gp	1	large		4	8	20
cb	1	small		1	1	20 Get the newsletter Get the most important tech news in your inbox each week. E-Mail(Required) Name First Last Datenschutz(Required) Ich bin mit der Speicherung und der Nutzung meiner Daten durch diese Website einverstanden. - Datenschutzrichtlinie * Email This field is for validation purposes and should be left unchanged. Relevant posts Create Network Policies to support your Kubernetes with Aqua 1. Introducing Aqua Before we start, we should explain what Aqua is in the first place.  Aqua is a cloud-native... Eduard Schwarzkopf 19. January 2023 How to create a local IoT broker with greengrass and connect it to the aws cloud Introduction Greengrass is a software developed by Amazon Web Services (AWS) for the deployment of local compute, messaging, and data... Eduard Schwarzkopf 22. September 2023 Create Network Policies to support your Kubernetes with Aqua 1. Introducing Aqua Before we start, we should explain what Aqua is in the first place.  Aqua is a cloud-native... Stelijan Markovic 19. January 2023 vSphere with Tanzu AKO integration for Ingress For vSphere with Tanzu deployments it is necessary to fulfill some networking requirements and at least have NSX Advanced Load... Steven Schramm 20. October 2022 Secure User Authentication with Next.js, NextAuth.js, and AWS Cognito Introduction For one of our projects, we have decided to use Next.js 13. As a backend developer, you can imagine... Eduard Schwarzkopf 7. March 2023 Inject secrets with Vault-agent-injector Securing sensitive information, like passwords, access tokens, and private keys, is really important in the modern software development lifecycle. If... Dominik Engelhardt 21. May 2024