One of the things you have to do when building out your VMware cluster is size the amount of memory (RAM) you need. From what I have seen most people assume that by adding up the total amount of RAM they have on their physical servers they will get the total amount of memory that is required for their cluster; those people are wrong.
What they have forgotten about is the overhead that VMware has on their requirement. Not only does the hypervisor require memory to run, but also for each virtual machine you have powered on memory is required for management overhead.
If you already have an ESX host up and running you can check the amount of overhead different virtual machines require by creating a new virtual machine and assigning it the specs that are in question. Then on the Summary tab look for “Memory Overhead”. In this example a virtual machine with 1 vCPU and 4GB of RAM would consume 183.05MB of RAM for overhead purposes. If I increase the number of vCPU’s to 2, then it jumps to 245.61MB. The same is true with RAM, if I put the vCPU back to 1 and move RAM to 8GB instead of 4GB the overhead goes back up to 247.39MB.
As you can see you are talking between 200-250MB per virtual machine of RAM overhead, if your cluster has 20-30 virtual machines with various sizes you could be talking as much as 7.5GB of RAM!
Another thing to take into consideration is the virtual machines that you will add in order to run vSphere. Right now vCenter Server runs on a 64bit virtual machine, and its stated that the minimum RAM is 4GB. However if your vCenter server is doing other things, such as running a local version of SQL Express, VUM, vCenter Converter, or other tasks; you could easily need 8GB of RAM just for vCenter.
RAM is almost always the limiting factor in a VMware cluster design. Mostly because it is a static assignment once the virtual machine boots up… its not like CPU power where a VM will use it for a second then let it go… once you assign RAM to a virtual machine it keeps it (except when ballooning). The other thing that hurts RAM usage on virtualization projects is scope creep.
Because you have the ability to spin up a virtual machine so quickly and easily it seems logical to start separating server functions out into their own isolated environments. The problem is that when we start to run more copies of Windows, we require more RAM. So you really have to be smart and think ahead when calculating the amount of memory you’re going to get.
If you want to be on the safe side, your best bet would be calculate the amount of memory you have in your physical machines. Then that number and triple or even quadruple it! For example if your current physical server infrastructure has 50 servers, each has 4GB of RAM and will require 1vCPU’s. We already know that we can fit this workload on 3 physical servers ( this was determined by using our pretend Capacity Planner results). So we will need 200GB of RAM to equal what we have in the physical boxes now. Next we need to calculate overhead for those VM’s…it comes to about 9.2GB. Then we add in the memory we need to run vCenter in a virtual machine (8GB plus 342MB), and also figure 1GB for ESX or ESXi per server.
So total for RAM we are thinking about 218GB to run everything… so now we can divide by 3 (because we have 3 servers), this comes out to about 73GB per physical machine. However if we lose a box we have to compensate for that so add in another 73Gb of RAM spread across 3 hosts (so about 14GB per physical).
So we started out saying that we needed 218GB of RAM to match our physical servers… best case after recalculating that number knowing what the overhead is we are now at 292GB…so figure 100GB of RAM per server.
Bottom line… the fastest swapping rate is the one that isn’t needed… So always buy more then enough RAM… you will use it sooner or later.
Incoming search terms:
- vmware memory
- vmware memory overhead
- memory overhead vsphere 5
- vmware memory calculator
- vmware sizing
- vmware host sizing calculator
- how to size vmware server
- vmware ram
- vmware sizing tool
- vmware memory sizing