Posts by Nick Triantos4 posts • joined Saturday 4th October 2008 04:14 GMT
The title that NetApp dumps FilerView is not accurate and rather misleading. FilerView will not be going away in the foreeable future. It will still be there, fully supported for those who chose to use it. Eventually, it may get replaced but not until a suitable replacement is found.
This particular SPC1 test didn't affect just EMC. It also affected Dell which resells this particular Clariion array used for the benchmark. So EMC could have still challenged the result via its Dell relationship because Dell IS a member of the SPC. In fact, the timeframe was not 45 days as I had previously stated, but 60.
Furthermore, while the rules were written assuming that challenges would come from members, the SPC was aware of the unique nature of that particular event and would have permitted EMC to challenge even if they chose to maintain their non-member status. Like I said before, the SPC auditor notified EMC of the SPC's intention to allow them to respond. In fact the auditor has stated the following to an techtarget interview:
"Baker said EMC has not challenged yet. “Absolutely not–and they have been notified, because I spoke with them myself,” he said. He added, “as the auditor I feel the result produced by NetApp is representative.”
Of all the things listed, following best practices according to published TR, snapshots, dedup, Autosupport, TP and grouping VMs of same OS type to get good dedup ratios are things that netapp has been doing for years. They were not invented for the purposes of this Program.
Furthermore, since we're on the hook for this, i see no problem having our PS organization participate in the design and deployment process. Sounds like a no brainer to me. It should also be evident to those that understand dedup that certain types of *primary* data just don't dedup well at all (images, encrypted data etc) so you can't guarantee dedup of this types of data no matter what the dedup algorithm is.This is about deduping *primary* data not backups and archives only.
Rob,
NetApp's RAID-DP practices recommend 14+2 RAID Groups not 8+2. Furthermore, there's no such recommendation for 60% utilization. In fact, fo dedup we recommend 3-5% available space in the volume because we need the space to store the fingerprint file and some temp files we use for sorting the contents of the fingerprint file prior to doing the comparisson of the generated MD5 hashes which reside in the fingerprint (byte to byte comparisson occurs if 2 MD5 hashes match). Now, if we recommended 60% maximum volume utilization it would be pretty silly to recommend 3-5% available space in the volume, wouldn't it?
As far your 60% before degrading performance comment goes my comment would be that it is upon those who are making the claim to prove it. At least that's how the legal system works. I can easily claim that anyone who buys a system other than netapp will get sick and suffer from severe diarrhea. I can argue that until I'm blue but i can't prove it. Neither can you.
Just because NetApp's dedup is post processing that does not mean you have to have ALL the space up front. There are 2 ways to skin this cat. One way is shotguning it and move everything at one time. However, that's not how people deploy server virtualization. It's an evolution, not a revolution. So what you do is you allocate some space up front, you deploy, you dedup and then you use the freed up blocks to deploy more. If you follow a staged approach then you don't have to have the entire space up front.
Now the questions here are these:
What does everybody else guarantees on their dime?
What do customers who participate in the program have to lose when dedup is FREE and the provisions are in place to address those who may not benefit from it?
why don't you pay a visit to StorageMojo's Blog and take a look in the comment section the space savings output posted from a netapp customer aleady doing it. he not the only one.
http://storagemojo.com/2008/09/30/de-duplicating-primary-storage/#comments
Anonymous, you make it sound as RAID10 provides a triple disk protection? It doesn't. It does provide double protection failure, although selectively depending on which pair fails.
RAID4 = Tolerant of Up to 1 disk loss
RAID-DP = Tolerant of Up to 2 disk loss
SynMirror + RAID4 = Tolerant of Up to 3 disks (any 3)
SyncMirror + RAIDDP = Tolerant of Up to 5 (any 5)
Show me how a RAID configuration provides this level of protection and the associated cost. Btw...people deploy this stuff.
Of course we'd compare RAID-DP against RAID 1. RAID-DP is more resilient than RAID1 or RAID10. And from a performance standpoint we proved we can beat RAID10 using an industry accepted, industry written, cache hostile audited benchmark. Anyone who has had questions or qualms about it had 45 days to respond and didn't...In fact they still haven't responded.
