VMWare ESXi suite has evolved from the previous years and it is now possible to run more than the 20 VM’s that once was almost a limitation that messed up IT infrastructure design. The reason it messed up the design was that customers were forced to create smaller datastores or waste space (whichever was more preferable) when it came to allocating VM’s per datastore. A lot of customers were really stuck with smaller size VM’s (more than 20 of them) that would make up close to 1Tb but would not allow customers to use 2Tb size because the remaining space would essentially be wasted.
With the latest release of ESXi 5.1 VMWare has worked on it and improved the number of VM’s you can have per datastore without running into I/O contention. But for many of the customers who now are looking beyond just a pure VM per datastore calculation it is always a catch-22 situation as to what should be the ideal size of their datastore.
In personal experience, I have found that customers are best suited to create a 2Tb VMFS datastore and then load balance their VM’s across them. The only problem that arises is that if you are using only 50% of that space what should you do with the rest. I propose that customers use the extra space to create cloned copies or setup temporary VM’s on the free space so that it does not go wasted. This avoids creation of a dedicated datastore that is used for testing purposes. While the optics of mixing production, test, or staging workloads on the same datastore is not preferable many SMB’s might actually not be affected by it. The reason is that a large number of SMB’s usually operate about 50-100 VM’s in their environment. That means three to five datastores can handle their entire workload.
A customer has three datastores with 2Tb space each and runs 75 VM’s. Out of the 75 VM’s about 50 are production and the remaining 25 VM’s are test/dev. Of the 50 production VM’s about 25 are highly critical and the rest are low utilization servers. The size of each server is approximately 50-80Gb in size – with an average of 80Gb the total size will be approx 6000 Gb.
Something that would be relevant for this environment would be is 10 highly critical VM’s with 10 low performance prod servers can be setup on one datastore. This would allow the creation of 2 datastores that are just production related and handle 40 servers. Create two more datastores then and add all remaining production servers in there and add some test/dev servers on which you are never going to perform stress testing. The ideal application type is web servers or file servers. Finally create the datastore to hold all of your remaining test/dev servers. As you see with 4 datastores you accommodated 75 servers with some growth. The layout would look like –
Datastore 1 – 2Tb size – 20 VM’s (Critical Prod + Regular Prod VM’s) – Used space is 1.6Tb
Datastore 2 – 2Tb size – 20 VM’s (Critical Prod + Regular Prod VM’s) – Used space is 1.6Tb
Datastore 3 – 2Tb size – 15 VM’s (Critical Prod + Regular Prod + Some test/dev VM’s) – Used space is 1.2Tb (keep clones etc in this datastore)
Datastore 4 – 2Tb size – 20 VM’s (Remaining Test/Dev VM’s) – Used space is 1.6Tb. Use this for stress testing.
We used 8 Tb of storage capacity to accommodate for 75 VM’s which otherwise would have been split up into several chunk of smaller datastores. When you have new project testing requirements shuffle some of the VM’s into the free space to avoid impacts due to stress testing in the test/dev datastore.
The above is just an indication of the type of datastore split that can be attempted. With the ESXi 5.1 release onwards you can pack more VM’s into a datastore as long the VM’s are not too demanding in terms of I/O and the metrics would be known to you.
If you do not know the I/O metrics let the workload run for a while in the test/dev environment and then review the reads and writes for each day. Also review the total IO/sec traffic throughput for each day.
This post is more relevant for virtualization administrators that may not be very experienced and would want an understanding of how datastore allocation should be performed.