@ open systems

I suppose NetApp could have chosen some other basis of comparison like 7+1 RAID-5 with a less emotionally compelling number that was still legally binding, but between the marketing guys and the legal types I think its a reasonable start.

So lets go with your assumptions, actually lets take the RAID efficiency issue out of the picture entirely and go with savings just from provisionable capacity.

To make my life easy, and because I dont like the idea of having less than two hot spares, I’ll start with an assumption of 6 shelves of 16 “300GB” drives.

96 drives in total
2 hot spares
10 7+1 RAID groups
2 6+1 RAID groups
=82 data disks
* “300GB”
= “24600GB”

Now I’ll convert this from base-10 to base-2 which is what applications like vmware sees. I did this using an internal calculator which I trust and which tells me that 23.9TB of base-10 = 21.7TB of base-2, so lets round up a little and say that 24600GB of drive manufacurers capacity equals 21.8 of what most people think of as a Terabyte, and that we can carve this into LUNs to be presented to Vmware.

Lets say that on average each virtual machine will be around 25GB,

Most customers I’ve seen run about 10VM’s per LUN. I’ve heard that EMC reccomend no more than 14, and HDS no more than 10, though this is anecdotal. Ten VMs per LUN was also the generally agreed number when I did my Vmware training.

So this means we need at least 250GB of space in each datastore, furthermore, lets assume that there will be some additional space left in the datastore to allow for vmware snapshot useage. Typically this figure is about 20% of the size of the space used in the datastore, (its an arbitraty number, but it matches what I’ve seen) so lets round this datastore size up to 300GB. The reason people do this is that if you run out of space in your datastore because the vmware snapshots fills up the remaining space, then every machine with a vmware snapshot in that datastore hangs and is unable to do I/O.

I know this is EXACTLY the same criticism made of NetApp, however there is one main difference, VMware does not currently have any policy driven method to manage this out of space condition whereas netapp does. Also while there is no requirement to use storage array based snapshots, Vmware snapshots are used for VCB, which has had a notorious reputation amongst two of my customers for failing half way through (tape .. arrggghh), and not cleaning up its Vmware snapshots.

So, now we have 72 datastores, each with 10 virtual machines for a total of 720 guest machines, its a big configuration, but using a smaller number of machines or datastores wont make any significant change the efficiency percentages.

Now I’ll make some more assumptions which match my experience, and which seem reasonable (actually their pretty conservative)

On average each of the virtual machines will have a nearly identical operating systems image of about 3GB
On average each of the virtual machines will have about 20% of the disk assigned to them as identical, free, unused blocks full of Nulls i.e. about 5GB

Here is where two saving NetApp features will help

1. Deduplication of identical blocks 3GB O/S plus 5GB “nulls” = 8GB per machine, this gives us an immediate saving of 5760GB
2. Thin provisioning of the VMFS datastores, this returns the 50GB of “reserve space” on 72 datastores for a further saving of 3600GB, though to be fair, we really should have some reserve shared between all the datastores, which for the sake of argument will be around 3x the allowance for any given datastore, lets say 144GB.

In addition and we’ll set up an alert from the array when we detect that this reserve space has exceeded 60% of its allocation to allow time for a sysadmin to take some form of action (e.g. clean up the rogue snapshots)

This means we’ve just saved 9TB of space, or 41% of the total capacity (this is withou

Just to summarise, using the assumptions above, to provision 720 guests OS with 25GB VMDK files on a traditional storage array without thin provisioning or deduplication you’d need 21.8 TB of provisionable storage. If you used these NetApp features, you’d only need 12.8TB of provisionable storage.

While 41% savings arent as emotionally compelling as 50%, its still pretty impressive.

While you can argue about the overheads involved in providing the provisionable storage, NetApp stacks up very well in this area too even when comparing 7+1 RAID groups vs 16+2 RAID-DP raid groups (the default).

On a final note, feel free to challenge my assumptions, I tried to make them reasonable, and apart from the 144GB figure (which made the 9TB saving a nice round figure, and its close enought to 150GB not to make a significant difference), none of them were “hand picked” to make the numbers turn out the way I wanted. IMHO, the average amount of unused space inside of a VM is a lot higher than 20% and there is a lot of other commonality in the rest of the data too.

Most customers I’ve dealt with get around 50% from deduplication in Vmware server environments, even before adding on the benefits of thin provisioning, and one large customer that does just thin provisioning without dedup has reported getting over 200% storage utilisation. Personally, I think NetApp has been very conservative with our space savings predicions. As always, your mileage may vary, but at least NetApp is prepared to insure you against that variation for qualified configurations. I wish my car company would do the same.

I like the idea, but I wish you guys hadn’t picked raid 10 as your baseline comparison. Best practices for ESX certainly allow for raid 10, but don’t specifically ask for it. Most everyone uses raid 5 with half or full enclosure raids. Commonly, using 16 drive shelves, there will be two raid 5 groups with one spare every 3 shelves.

Still, I’m a blogger and am hardly representative of your client base- hopefully this will work out for you.

Be that as it may, the reason why we used RAID-10 (or its HP equivalent) is that this is the RAID configuration we often see deployed for Vmware environments. I have seen RAID-5 set up for some VMware environments, but those all used a mix of 2+1 (!! yes I was surprised), 3+1 and 4+1 RAID groups.

The reason we didnt compare to another RAID-6 implementation is that we wanted to compare vs a RAID configuration with comparable performance and reliability characteristics.

We didnt compare vs RAID-6 simply because the performance characteristics of all other array based RAID-6 implementations just isnt suitable for the kind of random block I/O typically seen in Vmware environments.

For the same number of spindles, RAID-DP (which meets the SNIA definition of RAID-6), performs as well or better than RAID-10 for almost every workload. This is partly because of its inherent efficiency, and partly because of the way WAFL lays out its data. The net result is that for random block I/O, RAID-DP typically outperforms RAID-10, while maintaining exponentially higher reliability and useable capacity than either RAID-5 or RAID-10.

This raises the main area where your motorcycle analogy falls down, in that unlike motorcycles RAID-DP is much safer than the alternatives

guarantee
N

1 a formal assurance in writing that a product or service will meet certain standards or specifications

2 something that makes a specified condition or outcome certain ? there was no guarantee that there would not be another military coup

3 same as: guaranty
VB -teeing, -teed

1 to promise or make certain ? to guarantee absolute loyalty

2 (of a company) to provide a guarantee in writing for (a product or service)

3 to take responsibility for the debts or obligations of (another person)

My take on it is here ..

http://chucksblog.typepad.com/chucks_blog/2008/09/storage-shenani.html