Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

The answer really depends on your performance goals.

If a VM coming up required 100 IOs to complete all of its boot time operations, and you had 10 VMs coming up at the same time, then to have everything complete in 1 second you might want 100 * 10 = 1000 IOPs capable in your storage backend. So what IOPs capability is required is dependent on too many subjective factors for anyone to give you a better answer than "it depends", as any answer provided to you is bound to be wrong to some degree.

If you're looking for a generic answer nevertheless, a good rule of thumb may be to model general VM IO requirements similarly to the performance one can expect from a physical machine. Most desktop machines have ~100 IOPs capability with spinning disks and ~10k IOPs capability with SSD. If you're shooting to give your users a spinning disk kind of experience then take 100 * (# of VMs).

To size this down to a "just right" number though, you would have to understand on average how many VMs are actually accessing their disks at the same time, and you could take some reasonable ratio based on concurrent usage rates. To do this you would need a lot of monitoring and historical tracking of said monitoring data.

All of this will also depend highly on how many cinder nodes you have, and the level of distribution between these. You might assume that everything would be evenly distributed, but as VMs come and go, suspend, etc, you're going to have some amount of imbalance. This is especially true if you have different sized volumes as you'll inevitably end up with fragmentation, such that the number of volumes you have on a given node will be different across all of the nodes.

All of this only scratches the surface and doesn't really give you anything that you can expect to be reliable over time.

As infrastructure is rarely ever static, the best thing is to ensure you have sufficient monitoring to understand trends, and have routine maintenance windows to allow adjustment of the backend based on trends and capacity/subscriber projections.

Also keep in mind that cinder is not a single node solution, nor a "big iron" solution that's hard to scale out. Cinder is best used in a scale out manner, the idea being you add more nodes as your needs increase, and the rest of the infrastructure doesn't have to know the difference.