David's Discussions

OK, dedupuplication technology is cool. It makes disk a viable target for longer term retention. Dedupe, however, is not the panacea of backup. I have been getting a lot of questions about deduplication from my customers and it's a fun topic to discuss. Being a professional pessimist, it's my job to play Debbie Downer at the dedupe party, though, and say "hey now, let’s not lose sight of the fundamentals, people."

1. Reporting – It’s almost not worth doing a backup if you can’t prove it happened, or more importantly, why it didn’t. I appreciate we are not all waiting for the SEC to kick in the doors and look for our latest backup reports to determine if you are going to jail or not. Some products such as CommVault’s Simpana have a very nice native reporting tool with an option to do some very cool statistical trending that makes decisions around necessary throughput and media not so dependent on the crystal ball. Even if you are not looking for a complete solution overhaul or have already taken the Data Domain jump or just plain happy with BackupExec, there are some tools that are remarkably functional at increasingly competitive prices such as EMC’s Data Protection Advisor that cover all the mainstream backup tools.

CommVault’s Data Growth Report from the SRM expanded reporting tools.

2. Integration with the platforms that drive your business – While all the big hitters are touting integration with the soon-to-be ousted VCB, some products have really stood out such as Symantec’s NetBackup, which allows a single backup to provide both machine and single file restore (video here). Also there are a number of VMware specific solutions that have introduced a flavor of dedupe into their technologies as well. Veeam is a standout here that is probably worth taking a look at, providing replication and backup with dedupe in a single, very cost attractive product. This product also lends well to where I see next generation data protection going. See my rant "Why Back Up Your Business Data?"

3. Speed – Depending on how you implement your backups, deduped or not, you may still be racing the sun to get your servers backed up before your users show up to change all the files again. Avamar is a clear dedupe stand out here since the method they utilize to perform the dedupe usually results in ridiculously shorter backups (see Justin’s blog "Data Domain vs. EMC Avamar: Which deduplication technology is better?"). However, being able to add media servers with a single management interface to increase the sheer brute force of your solution with or without deduplication will keep you with the old stand bys like Symantec’s NetBackup and CommVault’s Simpana.

Other criteria off the top of my head include:
1. Do you have application agents for MY applications?
2. Can you restart your backup / restore jobs from where they left off?
3. What is your bare metal solution?
4. Can you protect desktops with the same interface as the datacenter?
5. Do you have integrated archiving / compliance search?
6. How difficult is it to protect / recover the backup solution itself with history?
7. Can you multiplex / multi-stream backups for improved reporting?
8. Can I write to disk and tape at the same time?
9. How granular is your security construct?
10. Do you support my hardware with tools such as NDMP?
11. How well does your solution work with my firewall?
12. If I backup to disk, how do I cut tapes / restore from tapes?
13. Does your solution have CDP as well as regular backups?
14. Do I have to configure every server or does your solution leverage policies?
15. Does your solution manage encryption / encryption keys?
16. Does your solution push updates or do I manually update all the clients?
17. How functional is your GUI / Command Line interface what can / can’t I do from each?

This list could go on for another hundred points depending on the specific needs of your business, but I think we are now at the point when we have a deduplication conversation that extends back to what our dedupe vendor is bringing to the table beyond a compression ratio.

I love technology. There is nothing better than waking to the news of the next cool tool, gadget, or blinky thing. However, I have recently become a bit cynical of recent releases in the storage world. Many of these new “innovations” have been the product of the marketing teams more than the engineering teams at our storage manufacturers. Everyone out there is touting their storage “virtualization” and I have completely lost track of what that term actually means. So my apologies for the next few paragraphs which are a little more negative than usual.

Head trip: Middle managers for your storage TPS reports…

IBM, Hitachi and EMC have long had head appliances you can shove everything from ghetto RAID to ultra high end storage behind and present it all as a single storage pool from which to carve. In this case we are creating one big “virtual” array from lots of other smaller arrays. I suppose there was a time when the companies out there who needed Petabytes of storage may have wanted this to simplify their lives by having a single interface and had a few hundred thousand dollars burning a hole in their budget. I have never worked with that finance guy (rare as the Loch Ness Monster), but I would love to. These days even mid range arrays scale to just shy of a Petabyte and have a very healthy set of tools so it seems a shame to dumb them down to disk behind this “one ring to rule them all”.

Big Pool: Come on in, the storage is fine…

Here we are talking about putting all (or a big bunch) of your disks into one big RAID and slicing off storage as you need it. Wow, now that I just wrote that I have no idea what is new about this (sneaky marketers).  VMware is even doing this in software. I guess what has changed is the messaging from the storage vendors saying that all your storage is ideal for all of this. I get that more spindles thrown at an IO problem is great, but I don’t know if I want to comingle my critical Oracle data on the same spindles as my summer intern’s home drive who may very well upload his classic Ren and Stimpy collection to the public share during month end cube runs. Call me crazy. I guess if you have so many disks that this does not affect your performance why not, but again this is the classic mark of the wayward finance guy. Fencing off a little IO for my critical apps still seems like a good idea unless you have some Quality of Service tools in the array to prevent dropping business critical apps for business social tasks. These QoS tools are becoming more available all the time from the likes of EMC. Net of net, I would be wary of a salesperson or their engineer calling this strategy a technology. The worst part is that they are selling it as something to make the IT person’s life easier. I am a lazy as the next guy but I don’t know if I am going to risk my performance (and maybe my job) to save myself one more trip down a wizard to create a RAID before I carve my LUN.

Performance Pyramid: Step on up, for now…

Now we get into what I would really call a new technology. Here we get into moving away from your classic contiguous LUN idea and move to a LUN actually being an amalgamation of stripes of data from several different RAIDs and potentially from RAIDs of different performance bands. Pillar tried pulling this off in the array by moving data that needed more performance to the edge of the platters. This, in a lab, really would result in better performance. That said, the array still puts data on the inner radials so the actuator arm is still working very hard and wanders away from your performance sensitive data. It was a great concept but my experience what that this was a very “gen 1” way of going about it. Generation two has the LUN moving between multiple kinds of disks based on its temporal needs. If it does not need it to be fast, the LUN moves down to SATA, if the LUN needs heat, it moves up to 15K SAS/ Fibre Channel drives until it qualifies to move back down. Here the algorithm on what moves when is key. If the window of decision is too big, by the time the array decides the data needs more performance, the job may already be done requiring the performance. If the window is too small, minor blips from an application could result in hundreds of gigs of data flying around the array, wasting precious IOPS.  Here is where the policy engine will rule and I expect these engines to get very complex very quickly but the resulting savings from potentially overbuilding arrays for end of month style processes will be worth it.

Performance Soup: Pay no attention to the man behind the curtain…

So now that we have awesome engines making really good calls on when the data can move up and down based on educated empirical data lets reduce the LUN to smaller components and move the busy pieces all the way to flash so I don’t use any more of the prime real estate than necessary to get the job done. Most of the LUN may actually be on SATA, and still other pieces may sit on Fibre Channel or SAS. This is the end game until solid state drives are so cheap we all just buy as much as we need for capacity and walk away. This small segment migration is happening now. The array that will win the day will be the one with the smartest (not fastest) head since it will be up to the rule base to make the magic happen.

So the good news is that there are some really applicable technologies out there changing the face of storage as we know it. Just don’t let the marketing teams fool you into mistaking old school lazy for next gen cool.