Hyper-V and the Small Business: Sample Host Builds

I get quite a few requests to assist with sizing of hosts, and I turn all of them away. Some of it is that I can’t offer free consulting — it’s not fair to me and it’s not fair to the consultants that I would be so dramatically undercutting. The other part of it is that no one that has ever asked has given me nearly enough information to do a good job of it. While I do not intend to change my policy on not designing systems, I will share some theoretical builds based on hypothetical situations. You can measure your projections against them, adjusting for any differences, to see where you might be overspending or under-allocating.

General Guidelines

First things first. If you haven’t read my article with tips for host provisioning, start there, then come back. I won’t restate the contents of that post, but I will rely on its information.

Now, set your priorities. Most small businesses do not have sufficient funds to meet every desire. Therefore, you must decide what is most important. When it comes time, you’ll have a better idea of where to add or cut. Almost every small design will follow this priority order:

• Storage
• Memory
• CPU
• Network

Storage

All else being equal, I prefer having a larger number of small platters to having a few very large platters. The larger disks tend to be slower and present more risks. Adding spindles is the best way to improve storage performance. You might find yourself constrained by drive bay count, however. Your greatest challenge then, is to not buy more storage than you need. How much do you need? Well, how much are you using today? Do you know how quickly it grew to that point? If you do, just project from there out to the maximum amount of time that you expect to use the new host, and add in a bit for overflow. If you’re not certain, a good rule of thumb is that 100 GB today will need 130 GB in 5 years. Capacity is the most important thing to know when sizing storage.

Once you have an idea for capacity, the next thing you need to figure out is what sort of fault tolerance you’re going to provide. If you’re using very large platters (I usually draw the line at anything over 1 TB per disk drive), then RAID-10 is really your best bet. For smaller platters, or if you’re using solid-state disk, then it really comes down to how many spindles you have and if you want your money to go more for capacity or more for redundancy. With a very small number of disks (4), RAID-5 is usually the best balance. RAID-10 will give a small performance boost but not much protective benefit over RAID-5. RAID-10 actually has a worse redundancy profile than RAID-6 in a 4-disk array, although its performance will be noticeably better. If I were to build a 4-disk array of spinning disks but couldn’t satisfy the size requirements with disks whose size is suitable for RAID-5, then I would definitely add spindles.

From there, I would counsel you to read my article on the RAID types. The biggest thing is to just avoid the FUD. I know of more than a few people out there trying their best to terrorize everyone into using RAID-10 by waving a lot of scary-looking charts and quoting statistically-unsound junk science. RAID-10 is perfectly fine if you’re willing to sacrifice half of your capacity for somewhat better performance, but it is not the automatic best fit for every situation. If you want better performance, your first choice should be to add spindles or switch to solid-state disks, not wring your hands over the RAID level.

Also, don’t do this:

Bad Hyper-V Array Design

Splitting arrays to segregate I/O comes from early SQL Server design, where both arrays do different work constantly. If you build your arrays like that for Hyper-V, you’re going to have two disks that do nothing all of the time while the rest handle all of the work. It’s a waste of money and places an unnecessarily high burden on the virtual machine-bearing spindles. This is what you want to do:

Good Array Design for Hyper-V

With all the drives in a single array, the work is spread out more evenly and across a greater number of spindles. You get better performance and reduced odds of a disk failing.

This also helps with the question of, “How should I partition my drives for Hyper-V?” If they’re all internal, that’s completely up to you. This is what I like to do:

Hyper-V Multiple Partitions

This gives me good logical separation and safe places to use Storage Live Migration to fix things. The 100 GB for Hyper-V isn’t a hard number, but it’s worked very well for me.

Since you’re using internal storage, this is also a perfectly viable option:

Hyper-V Single Partition

I know that the very idea that anyone might do something like this ruffles a lot of people’s feathers, but there aren’t any quantifiable reasons for not doing so. Split partitions come from the days of split arrays, which as we said before, are a SQL thing. For bigger guys, they’re installing Hyper-V on internal storage but running virtual machines from the SAN, so they cannot physically do this. You’re building a Hyper-V host on all-local storage. Having one big partition doesn’t prevent upgradeability or portability or anything else. It’s just — unusual. If it works for you, that’s completely fine.

Finally, don’t do this:

Bad SSD Design for Hyper-V

The above computer has its fastest, most reliable disks doing nothing and its slowest, most failure-prone disks bearing all the weight. There is no sense in this design whatsoever. If you can’t afford SSDs for your virtual machines, then don’t buy any at all. Put comparable spinning disks in those first two slots and make your array encompass them all as described above.

I will reiterate from my previous post that only hardware RAID controllers should be used, especially with internal storage.

Memory

There isn’t much to say about memory. If you know what you need, buy that, plus some for expansion, plus 2 GB for the management operating system. If you don’t know what you need, well, you’re probably going to buy too much.

CPU

Modern CPUs are difficult to overdrive, especially in the small business environment. If you’re looking forward to Windows Server 2016 licensing, buy a dual 8-core system to get the most bang for your licensing dollar. I did a little poking around as I was writing this post, and it does appear that everything above 8 cores per CPU gives diminishing returns. While it’s difficult to give great guidelines here, I would be surprised if any typical 5o-user business couldn’t cover all of its server needs using a single 6-core CPU.

Do not scale out to the second CPU unless you have good reason to believe that you’ll need it. Unlike a lot of other resources, CPUs are bought in pairs and quads to give more computing power to a single box, not for redundancy. In my entire career, I’ve seen exactly two CPUs fail (not counting dead-on-arrival and improper user installations). Out of those two, one was because the owner didn’t believe us when we told him that CPUs were hot and that he shouldn’t touch it. His disbelief was rewarded with burned-out CPU and a permanent reverse imprint of the Intel logo on his thumb. I’ll tell you like we told him: “No, that’s not covered under warranty.” Now that we use heatsinks on all CPUs, I don’t think that will be a problem again. So, with only one non-user error CPU failure across a 15-year career, I think it’s very safe to say that buying a second CPU just for redundancy is a waste of money.

When you have two or more CPUs in the same box, memory balancing becomes an issue. While I struggle to envision the small business whose performance needs would be negatively impacted by a poorly designed NUMA layout, I still encourage you to work with your hardware vendor to ensure an optimal configuration.

Network

Networking is probably the easiest thing to size. For a standalone host with all internal storage in a typical small business, two gigabit adapters is perfect. If you’re going to use iSCSI/SMB, four gigabit adapters is perfect. To justify anything more, you’re either not fitting the small business mold very well or you’re building a cluster. For a small business cluster, four gigabit adapters for non-iSCSI/SMB hosts and six gigabit adapters for hosts that will use iSCSI/SMB is a solid number. If anyone tries to sell you anything more or anything bigger, demand concrete supporting evidence.

Small Business Management Operating System Choice

Ordinarily, I push for everyone to install Hyper-V Server (that’s the free one) and manage it remotely. I would be inclined to counsel a lot of small businesses to consider installing the full GUI of Windows Server as the management operating system instead. This would be one of those cases where it’s necessary to understand the best practice and why it may not apply to you.

• Security: One common reason to use Hyper-V Server or Windows Server in Core mode is security. There are fewer components in use, which means fewer things for attackers to target. There’s also no Explorer, which is one of the favorite targets of attackers. However, these concerns are easy to blow out of proportion. In a major datacenter with thousands of servers, worrying about patching Explorer flaws on all of them can drive a security office insane. In a small office with one physical server and no security office, the concern is much less. Don’t browse the Internet from the server and most worries are instantly alleviated.
• Reboots: Supposedly, a system only running Hyper-V Server needs fewer reboots for patches than a full GUI because it needs fewer patches. Well, whether this patch cycle has eight patches that need a reboot or one patch that needs a reboot, it all winds up with the same outcome. Truthfully, I don’t even know how it pans out because all of my patch reboots are automated to occur when nobody is around to care and I almost never follow up. I’m going to make a guess that if I set any given small business’s Hyper-V host to patch as necessary at 4 AM every Wednesday and allow a reboot if one is required, I’m probably not going to need to run from anyone chasing me with a pitchfork. If you have a cluster, Cluster Aware Updating should be taking care of everything for you.
• Management: I often push for Hyper-V Server because I think that a Hyper-V host should be deployed and then never directly logged on to again. In organizations with multiple physical hosts, that’s a relatively simple reality to accomplish. In sites with one or two hosts, it’s less likely. If it would be a hardship to have a management system, don’t use one.
• Features: You aren’t supposed to run anything alongside Hyper-V unless it is for managing or protecting Hyper-V and/or the virtual machines. Anything else causes you to forfeit one of your Windows Server guest virtualization rights, places a drag on the guests, and is probably better suited to a guest anyway. However, you might want to use Storage Spaces in the management operating system. If that’s you, then Windows Server is the only way to go because none of the advanced storage capabilities are supported by Hyper-V Server. However, take these notes to heart before you do that:
  • Like Hyper-V, Storage Spaces works best when it is all by itself. I like Storage Spaces as a technology and I think Microsoft has done some fantastic work with storage in the last few years, but I still would be reluctant to combine these two roles in most cases. A hardware RAID controller will be more cost-efficient and supportable. If you choose to use Storage Spaces anyway, make sure to increase CPU, RAM, and, if possible, the count and speed of the disks that you use. For context, I am using a stand-alone Storage Spaces host in my lab and it routinely alerts me that it is using 3.75 GB out of the installed 4 GB, and almost all of it is for storage-related tasks.
  • If you only use Storage Spaces to hold virtual machine files (BIN, VSV, VHD/X, XML, and SLP) and anything that will be used on the local host, it does not cost you a guest virtualization privilege. If you create a share on it and host anything else at all, you lose a privilege.
  • The Hyper-V deduplication feature of Storage Spaces is only supported for VDI (virtual desktops). It does work for server loads (I have it in my lab), but you can find yourself in a position where no one can or will be able to help you in production. Also, the outcome for deduplication of server loads is not nearly as satisfying as it is for VDI. A supported method that does not forfeit a right is to build a file server virtual machine on dynamically expanding VHDX and use the normal deduplication technique within the virtual machine. That method’s space yield is commonly not very satisfying either, but there is no question around supportability.
• PowerShell: I’m never going to stop beating the drum for PowerShell adoption. DevOps and control by keyboard is the present and the future as much as it is the past. However, there’s not as much going on in a one or two host environment that creates a strong driver for intimate PowerShell knowledge. To be sure, if you’re vying for that sysadmin job at a larger company, you’re going to be deservedly knocked out of consideration very quickly if you’ve decided that you’re too good for PowerShell. But, if you’re a small business principal who is only wearing the IT hat because you can’t afford to pay someone else, acquiring a strong PowerShell skillset is probably too much. You’ll still need to have enough familiarity to not be afraid to use PowerShell solutions to fix your problems, but it’s OK to stay rooted in the GUI.

Sample Build #1

So, let’s move on to our samples.

Scenario

These are the parameters for this scenario:

• 20 user organization, single site
• Uses a cloud service for e-mail
• Has 1TB of file storage with typical growth
• 2 printers on-premises

Suggested Build

This one looks really easy, but I’m going to say this because I think it’s something never to be forgotten: I would spend some time setting up Performance Monitor and build from that. From what I’ve seen of organizations in this scenario, the server that I would build would look like this:

• Quad-core CPU
• 8-16 GB RAM
• 4x 600 GB SAS in RAID-5; prefer chassis with additional bays
• 2x gigabit; paired in a switch-independent, dynamic team. It would handle management operating system traffic and all virtual machine traffic.
• 1x Windows Server 2012 R2 Standard license
• Virtual machines
  • 1x domain controller
    • Generation 2
    • 2 vCPU
    • 60GB dynamically expanding C:
    • Dynamic RAM; 512MB startup, 512MB minimum, 3GB maximum
  • 1x file/print server
    • Generation 1 or 2 — Generation 1 still seems to be a bit more stable
    • 2 vCPU
    • 60GB dynamically expanding C:
    • 1.5TB dynamically expanding D:
    • Dynamic RAM; 512MB startup, 512MB minimum, 4GB maximum
• 2x 2TB external HDDs for daily backup rotation

Discussion

This build is difficult to undersize. Even though it will likely not need anything more than 8GB of memory, doubling it to 16GB will likely not be expensive and give the system room for growth. The main issue holding this system back is really the Windows Server licensing. Adding even one more virtual machine will require the purchase of another Windows Server license (of course, this is assuming that Windows Server is the operating system that would be used).

Anything larger than a quad-core CPU will be wasteful, and even a quad-core won’t be used to anything resembling its capacity.

Disk space is also well-sized against the need. At current growth rates, it will be unlikely for the system to need even as much as it has until the fifth year. By leaving open even one bay, the array can be expanded with another 600GB, which is quite a substantial increase when growing from 1.8TB.

The 2TB backup disks might be a bit small, but remember that most data is static in nature. Data churn is likely to be small. These disks should be sufficient for day one, but the organization should be prepared to acquire larger disks if necessary.

Sample Build #2

The above scenario is more likely to exist in a textbook than in the real world, although I’ve seen some that fit. The sample build is going to be more realistic and incorporate some of the harder realities faced by small businesses.

Scenario

These are the parameters for this scenario:

• 20 user organization, single site
• Uses a cloud service for e-mail
• Has 1 TB of file storage with typical growth
• Has a line-of-business application server whose developer publishes the following requirements:
  • 4 GB of RAM, fixed
  • 500 GB of HDD, fixed
  • 2 CPU reservation
• Multiple client-based (no server) applications
• 2 printers on-premises

This scenario takes the company from scenario #1 and adds in what most small businesses really have: an application system that is provided by a software house that caters to their industry along with a smattering of other applications. Ideally, that application would be placed on its own server. Realistically, that would mean another full Windows Server license, which might not be feasible.

Suggested Build

• Single hex-core CPU
• 16 GB RAM
• 6x 600 GB SAS in RAID-5; prefer chassis with additional bays
• 2x gigabit; paired in a switch-independent, dynamic team. It would handle management operating system traffic and all virtual machine traffic.
• 1x Windows Server 2012 R2 Standard license
• Virtual machines
  • 1x domain controller
    • Generation 2
    • 2 vCPU
    • 60GB dynamically expanding C:
    • Dynamic RAM; 512MB startup, 512MB minimum, 3GB maximum
  • 1x file/print/application server
    • Generation 1 or 2 — Generation 1 still seems to be a bit more stable — app vendor recommendations apply
    • 4 vCPU; 50% reserved
    • 60GB dynamically expanding C:
    • 1.5TB dynamically expanding D:
    • 500GB fixed E:
    • Fixed RAM: 8GB
• 2x 2TB or 3TB external HDDs for daily backup rotation

This build doesn’t change a great deal over the original. The virtual machine that was serving as only file and print has been augmented to host the application server. We’ve doubled its memory allotment to 8GB fixed, given it another drive that exactly matches the vendor’s specification, and established CPU reservations to ensure that the application vendor is satisfied.

As with the previous build, I believe that the CPU on this system will be largely wasted. However, the fiscal distance between a quad-core and a hex-core processor is usually minimal. Since your application vendor demands two of them, having another two at your disposal gives you a bit more flexibility to grow.

The bit about other applications is just to throw it off a bit. They don’t run from a server, so you’ll probably have a “Software” or an “Apps” share with their installers on the file server. Other than that, any provisioning that you do for them is at the desktop/laptop computer level.

Sample Build #3

Let’s move up a little bit to a somewhat larger company.

• 50 user organization, single working site with disaster recovery site
• Hosts Exchange on-premises
• Has 2 TB of file storage with typical growth
• Has a line-of-business application server whose developer publishes the following requirements:
  • 4 GB of RAM, fixed
  • 50 GB of HDD, fixed
  • 2 CPU reservation
  • SQL
• The line-of-business SQL server has these requirements:
  • 8 GB of RAM
  • 1TB of HDD
  • 4 CPU reservation
• Multiple client-based (no server) applications
• 5 printers on-premises

Even though the bullet points don’t look substantially different, we’ve made some major changes. Let’s begin by breaking down the roles we need to plan for:

• Active Directory (including DNS & DHCP)
• Exchange
• SQL
• Application
• File/print

We’ve come up with an odd number of roles again (5 printers is not nearly enough to separate them from the file role). Since Windows Server license coverage for virtual guests comes in pairs, we need to decide whether to bump up to three licenses and have an unused set or try to keep it at two. An additional $800USD for a third Windows Server license probably would not be a major barrier for most 50-user organizations, but let’s assume the worst and try to architect for only two licenses.

Suggested Build

• Single 8-core or dual hex-core CPU
• 48 GB RAM
• 6x 2TB SATA in RAID-10
• 2x gigabit; paired in a switch-independent, dynamic team. It would handle management operating system traffic and all virtual machine traffic.
• 2x Windows Server 2012 R2 Standard license
• Virtual machines
  • 1x domain controller
    • Generation 2
    • 2 vCPU
    • 60GB dynamically expanding C:
    • Dynamic RAM; 512MB startup, 512MB minimum, 3GB maximum
  • 1x file/print/application server
    • Generation 1 or 2 — Generation 1 still seems to be a bit more stable — app vendor recommendations apply
    • 4 vCPU; 50% reserved
    • 6 GB fixed RAM
    • 60GB dynamically expanding C:
    • 3TB dynamically expanding D:
    • 50GB fixed E:
    • Fixed RAM: 6GB
  • 1x SQL Server
    • Generation 1
    • 4 vCPU; 100% reserved
    • 8 GB fixed RAM
    • 60GB dynamically expanding C:
    • 500 GB fixed D: (data)
    • 500 GB fixed E: (logs)
  • 1x Exchange Server
    • Generation 1
    • 4 vCPU
    • 12 GB fixed RAM
    • 60GB dynamically expanding C:
    • 400GB fixed D:
• 4x 2TB external HDDs for daily backup rotation, two per day

One thing that you need to be aware of is that a lot of people will insist that this disk configuration is insufficient for either SQL or Exchange separately, much less together. That thinking is over a decade out-of-date. Exchange Server has been using progressively less IOPS for years, to the point that Microsoft now certifies it to run on so-called “near-line” SATA. Exchange now uses lots of RAM instead of lots of disk, and the 12 GB in this design will keep it happy while also meeting Microsoft’s requirements. Your only concern here is having sufficient space. At 400GB in the initial build, that’s close to 8 GB per mailbox, which is far more generous than I tend to be (anything after 2 and I start reminding users that Outlook is neither a customer-relations database nor a file server).

As for SQL, there is no magical number of IOPS to satisfy it. It all comes down to how it will be used. No one can determine this in the abstract. In my experience, most databases backing a vendor application for 50 users will not be a very heavy load.

My concern with this build is storage utilization. In order to maintain expansion capabilities, I have switched from fast SAS to somewhat slower SATA, albeit in the faster RAID-10 configuration. Had we continued with the 600GB SAS drives, we would have needed to use 8 bays, which is the most commonly available maximum. While it is possible to acquire hosts with more than 8 drive bays, it’s not the most practical approach for a single-host site. Even with an 8-bay system, the host would have started life by bumping up against the maximum capacity. One thing that I would try to do is investigate the possibility of reducing disk needs. 2 TB is a lot of file storage for only 50 users. If they’re engineers storing CAD drawings, it’s plausible. If they’re insurance agents, someone needs to transfer their MP3 collection to their own device.

You can’t always give much pushback on things like that. If they’re accustomed to having lots of space, taking it away will be difficult.

One other option would be to use the filled 8-bay SAS system. I would plan for such a system to expand out within its lifetime. You would start with that host, but set the expectation of an additional host at some point in the future. When its day comes, use Shared Nothing Live Migration to move roles to it. A secondary host would also open the door to a secondary domain controller.

Another option would be to transition the organization to hosted Exchange. The space reduction would allow you to back down the storage requirement significantly.