Manage Learn to apply best practices and optimize your operations.

More science than art: Design a virtual server farm with math

There is no one-size-fits-all approach to designing a virtual server farm, but there are some simple formulas to help you build a scalable and reliable infrastructure.

Designing and installing a new virtual server farm requires detailed knowledge on the hardware and software components...

you need. Often times, this process can seem overwhelming and there are few documents that tell you what you need to create your next server farm or even how to virtualize your business or application. Part of the problem is that each environment and business is unique, and there is no single one-size-fits-all best practice approach. However, with some simple math and a bit of research, you can correctly size and design your next virtual farm.

Understand your applications

As you look to expand your virtual infrastructure, examine the types of applications in your environment. You don't have to evaluate each one, but get an overall measure of your environment by considering the types of applications you use and your ratio of production servers to test and development servers. For example, if you use financial or heavy transaction-based applications, you will find that your servers use more processing power. This is in contrast to the healthcare industry, where you will find more databases and memory-intensive applications. Different industries require a different mix of processor, memory, disk and network resources. Ensure you design your next virtual infrastructure to fit your specific needs and applications.

Quantity and density of hosts

Before you even get to decide the number of CPUs and amount of memory your infrastructure will need, make a few key decisions in advance. Now that you know your application makeup, you can figure out the quantity of hosts and density of the virtual machines -- with math. Host quantity should account for at least one host being offline for maintenance or failure. The n-1 formula means that, in a farm of 10 hosts, each can use up to 90% of its memory or CPU load, leaving the remaining 10% in reserve in the event one host fails. If we had a farm of five hosts, we would need to reserve 20% for the same failover capacity.

To get our initial quantity of hosts, we have to look at the density of VMs we want per host and what capacity they will have. The density of VMs per host is based on the ratio of production to test and development servers per host and how many production virtual servers you can afford to lose in the event of a host failure. While you don't have to mix production and test servers, there are many good reasons to take this approach, which you can read in my previous article on mixing test and production servers.

Production and test server ratios

While your ratio may vary, you still need to determine how many production servers you can afford to lose at once. While VMware's Distributed Resource Scheduler (DRS) rules, high availability and fault tolerance all help in the event of an issue, and you will still be faced with an outage that you need to resolve. Using an example of a 50-50 mix of production and test servers, a VM density of 20 VMs per host means that one host failure would lead to the crash of 10 production VMs. This scenario would be easier to recover from than one in which you lost a host running 25 production VMs. A key piece to keep in mind when making the decision about density is that you cannot guarantee which VMs will crash if you use DRS to help balance performance. Finding that balance will vary based on business needs and cost, because a lower density equals more hosts. In my experience, 30 VMs (15 production and 15 test VMs) has always seemed to be a sweet spot, so we'll use that example for the next step.

Designing a server farm is not an open-ended process, because the hardware we purchase today will not be available next year.

Now that we know our density (30 VMs per host), we can determine how many hosts we need. Designing a server farm is not an open-ended process, because the hardware we purchase today will not be available next year. Different generations of hardware can present compatibility issues as you try to mix them in the same virtual server farm. The ideal solution is to keep each farm based on the same hardware generation for stability and performance, but that also means each farm has a lifespan.

Setting a fixed quantity of VMs per farm helps prevent over commitment and VM sprawl while also giving you the ability to measure consumption so you can forecast your next purchase. So, if we want this farm to support 300 VMs, we would need 10 hosts (rounding up if required) to support this effort. Once we add in our n-1 calculation to ensure enough resources to survive a host failure, that brings us to a total of 11 hosts to support our new 300 VM infrastructure.

In the second part of this two-part tip, I'll explain how to determine the level of resources each host will require and help you choose the best hardware for your server farm.

Next Steps

Consider these server virtualization security concerns

Make room for storage in a virtual environment

This was last published in September 2014



Find more PRO+ content and other member only offers, here.

Essential Guide

How to design your server virtualization infrastructure

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What rules do you follow when designing your virtual server farm?
The first time we implemented a virtual server farm, we ended up having an outage less than 72 hours after setup. Part of the problem was underestimating the workload as our app went viral. This was made worse by one of the VMs that ran production servers crashing.
Nowadays, we determine the apps requirements (storage vs processing etc.), provide for outages by having a redundant host ready to go and mix test and production servers.