Capacity Planning for Red Hat Enterprise Linux OpenStack Platform
Sizing an instance
Determining the resource requirements of your VMs will go a long way to defining the underlying physical hardware requirements:
Instance Flavors
RHEL OpenStack Platform uses the concept of flavors to present users with hardware types for selection when creating a new VM. With flavors, the administrator creates configuration templates that pre-define a VM's hardware resources, including the number of vCPUs and the amount of RAM.
This approach can be considered similar to a service catalog, allowing users to select from pre-defined hardware types that align closest to their requirements.
Instance flavors also permit a measure of capacity forecasting, since common use cases are predictably sized, rather than ad-hoc.
Flavor vCPU allocation
Try to limit your flavors to one vCPU each, if possible. It's important to note that Type 1 hypervisors find it much easier to schedule CPU time to VMs configured with just one vCPU.
For example, a hypervisor scheduling CPU time to a VM configured with 4 x vCPUs will need to wait until four physical cores are available (even if the actual work requires only one vCPU).
vCPU to physical core ratio
The default allocation ratio in RHEL OpenStack Platform is 16 vCPUs per physical (or hyperthreaded) core. Usually memory becomes a performance bottleneck before CPU resources do, however the allocation ration can be lowered to 8 vCPUs per physical core, if necessary.
The following table is the maximum number of VMs that can be suitably run on a physical host (including 4GB reserved for the system):
| Total Amount of RAM | VMs | ~ Total of vCPU |
|---|---|---|
| 64GB | 14 | 56 |
| 96GB | 20 | 80 |
| 128GB | 29 | 116 |
As a result, planning an initial greenfields standup of 60 instances would require 3+1 Compute nodes.
Memory overhead
The KVM hypervisor incurs a small amount of VM memory overhead, including nonshareable memory. Shareable memory for qemu/KVM systems can be rounded to 200 MB for each hypervisor.
| vRAM | Physical memory usage (average) |
|---|---|
| 256 | 310 |
| 512 | 610 |
| 1024 | 1080 |
| 2048 | 2120 |
| 4096 | 4180 |
It is reasonable to estimate an overhead of 100mb per VM.
Storage backend
The Ceph cluster backend must be sized to service the expected number of concurrent VMs while maintaining decent latency. A reasonable service level would maintain 99% of I/O operation under 20ms for write operations, and 10ms for read.
You can isolate I/O spikes from affecting other VMs by configuring the maximum bandwidth per RBD, or setting a minimum guaranteed commitment.
Network planning
The amount of network connectivity to the hypervisors is also critically important. If your hypervisors only support a few VMs per node, and your applications do not require high speed networking, then using one or two 1Gb Ethernet links may be sufficient. However, if your applications require high speed networking and/or your hypervisors can support many VMs per node then one or two 10Gb Ethernet links are recommended.
The typical cloud deployment uses much more peertopeer communication than the traditional core network topology is designed for. As VMs are provisioned randomly throughout the cluster, they will still need to communicate with other VMs as if they are on the same network. This can cause slowdowns and packet loss on traditional core network topologies since they have highly oversubscribed links between the edges and the core of the network.
Performance baselines
Ensure that you retain a performance baseline of your systems, even when they are performing adequately with no slowdowns. Having this information on hand will be a useful reference when you encounter performance issues and require data for comparison purposes.
Oversubscription
Memory is considered the limiting factor for hypervisor deployment; the number of VMs you can run on a physical host is limited by the amount of memory the host can access. However, deploying a quadcore CPU with 256GB of RAM and over 200 1GB instances will result in poor performance, so a careful balancing act is required to determine the best mix of CPU cores and memory.
Capacity Planning methodologies
Short-term model (3 months)
To perform short-term capacity planning and forecasting, consider capturing a record of the following metrics:
- Total vCPU number
- Total vRAM allocation
- I/O mean latency
- Network traffic
- Compute load
- Storage allocation
The first three metrics are the most accessible for capacity planning. With these details, you can apply a standard second-order regression and receive a usable capacity estimate covering the next three months. As a result, additional hardware can be deployed to accommodate the anticipated usage.
Middle-term model (6 months)
The model requires iterations of review, and deviations between forecasting trends and actual usage must be estimated using standard statistical tools, or more pragmatic criterion like Nashsutcliffe. Trends may still be calculated using second-order regression.
Note: In deployments with a diverse mix of instance flavors, regarding the vCPU and vRAM metrics as a whole would assist with correlating vRAM and vCPU usage .
Long-term model (1 year)
Total resource usage may vary over one year, and deviations in long-term capacity can be expected. This results in second-order regression being an insufficient measure for capacity forecasting, especially in cases where usage is cyclical. In addition, a capacity planning model based on data spanning over a year must fit at least the first derivative. Frequency analysis may be required, depending on the usage pattern.
Resources
- Content from github.com is not included.Cloud Resource Calculator
This ODS document assists with calculating capacity requirements. Enter your hardware details into this spreadsheet for an estimation of the number of instances available to you, including their flavor variations.