When it comes to consolidating servers, one thing becomes clear when considering how to allocate a consolidation server's resources: What you think you need might not be what you actually need. In every case, you'll be best served by learning about what each server's real needs and behaviors are, then modeling your consolidation server along those guidelines.
We've already covered the topic of
Network bandwidth Planning for the network bandwidth used by consolidated systems is a little like planning for CPU utilization, and can be approached in much the same way. Not every server is going to have its network bandwidth saturated 100% of the time, so it's a good idea to derive some live usage statistics for the servers in question and see how they add up. Servers that saturate their network connections fairly aggressively ought to be given a dedicated physical network card; less heavily-trafficked servers can share a card and will probably never come close to using its available bandwidth.
Here's where things are a bit more carved in stone. In a server (and in computers in general), unused memory is wasted memory. To that end, when you're consolidating multiple servers into a single server, the host should have at least as much memory as the guests did when combined. This in itself is a strong argument for consolidating to a 64-bit host with 64-bit OS support (for the sake of being able to use more than 4 GB of memory), although that's probably a given for any newly provisioned system.
Start by devoting at least 512MB of memory to the host itself, and figure in the same amount of physical memory used by each guest system. For instance, four 256 MB guests would mean you'd need at least 1.5GB of RAM to run everything comfortably. Also be mindful of any per-virtual-machine limits on memory, although if you're migrating older machines into your consolidation setup you probably won't encounter this issue.
Disk space is another resource where you probably can't cheat—you'll need at least as much disk space on the host as you did in each guest. The good news is that disk space is cheap, and if you're consolidating systems that were created back when disk space wasn't as cheap as it is now, you'll have a lot less trouble meeting or exceeding the original stats.
Another important corollary to this is how to handle separate OS and data disks on a virtualized guest. If you have a candidate guest machine which has an OS drive and a data drive (or even just has OS and data on separate partitions on the same drive), virtualize the OS drive but move the data drive directly to another physical disk whenever possible. This way you won't incur the additional overhead of virtualizing something that really doesn't need to be virtualized in the first place.
Whatever you do, don't try to save disk space by moving the OS partitions for several different machines onto the same physical disk. This not only slows things down but will negate another of the benefits of having things spread out across multiple physical drives: loss reduction. If that one shared drive goes out on you, you'll have five machines out of commission, not just one.
About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter, which is devoted to hints, tips, tricks, news and goodies for Windows NT, Windows 2000 and Windows XP users and administrators. He has more than 10 years of Windows experience under his belt, and contributes regularly to SearchWinComputing.com and SearchSQLServer.com.
More on Server consolidation
- Tip: Server consolidation: Calculating CPU utilization
- Topics: Server consolidation
- RSS: Sign up for our RSS feed to receive expert advice every day.
This was first published in February 2007