Harley Davidson can Guarantee 50% Less Tires on the Road compared to Fords Traditional Cars and Trucks!
September 30th, 2008 by 
Steven J. Schwartz
Image via Wikipedia
In Recent News, and as an outstanding announcement for travelers everywhere, Harley Davison motorcycles (with some caveats) can Guarantee a 50% reduction of tires in use on the road compared to traditional cars and trucks made by the Ford Motor Company.
Using the following math:
50% less tires compared to a baseline of traditional cars and trucks. The baseline is determined from the amount of tires touching the ground on a car/truck and the amount of tires that a vehicle of transport requires. For example, suppose that you need a vehicle to get you from point A to point B. Here’s how we calculate the baseline:
- Default Harley Davidson Motorcycle has only 2 wheels/Tires, add on 100% overhead for 4 wheel ability, plus an additional spare tire.
- Total tires required to get from Point A to Point B – 2 tires on a traditional auto this number is 4 tires plus a smaller spare tire.
- 50% less tires means a traveler will only need to purchase 2 tires to get from Point A to Point B
In Similar News, NetApp releases “50% Virtualization Guarantee*”
50% less storage compared to a baseline of traditional storage. The baseline is determined from the amount of data to be stored and the amount of storage overhead that a system of similar protection and performance levels typically requires. For example, suppose that you need a system to accommodate 10TB of data. Here’s how we calculate the baseline:
• Add on 100% overhead for RAID 10 protection; 2.6% overhead for rightsizing and formatting; and two spare drives.
• Total raw capacity required for 10TB of data on a traditional storage system is roughly 21.75TB.
• 50% less storage means that the customer will need to purchase only 10.75TB of raw space with NetApp.
Obviously, there are other significant savings with NetApp, reduction in Hot Spares, Deduplication, etc. I just thought it was funny that the baseline for storage chosen wasn’t another RAID6 based configuration, but comparison to a RAID10 deployment.
Also, that URL isn’t a typo, guarantee was in fact spelt wrong.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
Posted in Deduplication, Enterprise, NOT SAN Related, SAN and NAS, virtualization | 
14 Comments »
September 30th, 2008 at 11:21 am
LOL!!!
My take on it is here ..
http://chucksblog.typepad.com/chucks_blog/2008/09/storage-shenani.html
September 30th, 2008 at 11:31 am
[...] Read more here: Harley Davidson can Guarantee 50% Less Tires on the Road compared … [...]
September 30th, 2008 at 1:42 pm
Definition from the Collins Online Dictionary seem to confirm spelling of guarantee
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)
October 1st, 2008 at 2:17 am
LOL,
Actually I kind of like the analogy, a motorcycle goes faster, handles better, has better fuel economy and is a lot more fun.
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
October 1st, 2008 at 10:05 am
Thank you John for the comment. I was just trying to get a good laugh out of it. It is very possible that with all of the caveats in the announcement that the savings should really be more then 50%, but only 50% is laughable, esp. since the largest % of that savings is just in RAID differences.
October 1st, 2008 at 2:23 pm
@John
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.
October 1st, 2008 at 9:16 pm
While 41% savings arent as emotionally compelling as 50%, its still pretty impressive.
October 1st, 2008 at 9:16 pm
Oops try again ..
@ 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.
October 3rd, 2008 at 10:43 am
[...] are calling it a marketing joke and others are saying the 50% utilization is just a matter of how you perform the measurements. I’ll keep my thoughts to myself, except to say I disagree with the requirement that the [...]
October 5th, 2008 at 9:37 pm
[...] The SAN Technologist (Independent blog, but employed by Dell/Equilogic): This post is pretty fair about the entire issue, but compares it to Harley Davidson stating that motorcycles reduce tire needs by 50%. “I just thought it was funny that the baseline for storage chosen wasn’t another RAID6 based configuration, but comparison to a RAID10 deployment.” [...]
October 9th, 2008 at 1:58 am
[...] In recent news, and in reaction to H-Ds claim 50% tire reduction announcement, SEARS® released claims that using it’s trash compactors will condense the amount of trash a [...]
October 12th, 2008 at 11:49 pm
Even if Netapp calculations are correct and the filer CPU’s can handle the load, what happens when you backup those VM’s? They “re-hydrate.” The real pain is still backing up data efficiently to disk for easier recoveries, etc. After just one month of full backups, you’re talking 4X production(VM’s) of B2D data. So, I theoretically save 50% on production disks. Big deal. I’ll use de-dupe for B2D first, thank you. Netapp’s “guarantee” doesn’t discuss the whole data protection picture. I’ll be happy to help my prospects understand that data protection goes beyond the production footprint of a volume.
December 18th, 2008 at 4:11 pm
Beside of dedupe another big story NetApp brings to the table is backup to disk. Gmoneymac is talking about the whole data protection picture. If one vendor has a whole picture in that area, then we talk about NetApp. Snapshots are integral part of every NetApp system. Products to move this snapshots to another system are available since years (e.g. Snapmirror or Snapvault). The movement happens block-level incremental forever – very few data (only changed blocks) to move and non-deduplicating
No VTL dedupe product can compete with that.
September 9th, 2009 at 10:40 am
[...] while ago I poked fun at the NetApp 50% Guarantee. The idea that most of the savings come from taking a RAID10 [...]