IT Is Power. Try Living Without A Single Breadboard For A Day.

Don MacVittie

Subscribe to Don MacVittie: eMailAlertsEmail Alerts
Get Don MacVittie: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Virtualization Magazine, F5 Networks

Blog Feed Post

Building the Hydra - Array Virtualization Is Not File Virtualization

There is more to life than is visible to your array

Hydra

So I’m jealous that Lori works D&D references into her posts regularly and I never have… Until today! For those who aren’t gamers or literary buffs, a Hydra is a big serpent or lizard with a variable number of heads  (normally five to nine in both literature and gaming). They’re very powerful and very dangerous, and running into one unprepared is likely to get you p0wned. The worst part about them is that mythologically speaking, if you cut one of the heads off, two grow in its place. Ugly stuff if you’re determined to defeat it.

That’s the way I see array-based file virtualization and other tack-on functionality. Vendors who are implementing it (many of whom are F5 partners), try to tell you that they’re unifying everything and the world is a wonderful place with greener grass and more smiling children due to their efforts. And they’re right…If you’re a homogenous shop with nothing but their storage gear. Then their multi-headed hydra looks pretty appealing. Everyone else feels like it only does a part of the job and is wary of getting too close.

For the rest of us there are products like ARX to take care of that nasty truth that no organization is an all-one-vendor shop, particularly not in the NAS space, where higher end gear can cost hundreds of thousands while entry level is a commodity server with a thousand bucks worth of disk slapped into it. In fact, I have never seen an IT department that was all one vendor for NAS, and that’s the problem with single-vendor messaging. Sure they can give you a handle on their stuff, help you virtualize it, give you a unified directory structure, automate tiering, but what about that line where their box ends and the rest of the organization begins? That’s the demarcation line where you have to find other products to do the job.

Picture from Pantheon.org


A TALE OF WEAL, OR WOE?

This has always been true in storage. Unlike the rest of IT infrastructure, the storage industry, the big iron vendors, have never felt compelled to see to the best interests of the customer where interoperability is concerned. While “vendor lock-in” was not invented in storage, it is certainly heard a lot more in reference to storage than most other spaces, and that’s too bad. Well, I’d say it was too bad, but truth be told that has left room for third party vendors to grow and thrive between the arrays. Acopia was one of those companies, and we snatched them up a few years ago to make the core of our Data Solutions Group. There are plenty of other third parties able to answer your needs both in virtualization and in the array of other problems (pun intended) that are not readily resolved with single-vendor solutions.

I’m really very happy to see storage vendors starting to provide unified interfaces to SAN/NAS/iSCSI SAN devices, I admit a bit of disappointment that “made by us” is nearly universally tacked onto the end. Maybe that’s for the best though, how much functionality do you want to stuff into your arrays? This debate has raged in the past and will in the future in storage – how much software should an array run or NAS head, or whatever your vendor calls their storage device run? Vendors (possibly correctly) point out that if they include the software, customers use it – even if it’s for-pay – and thus they’re offering a needed service. I contend that software on an array vendor’s hardware box is less likely (in the storage space) to support their competitor’s hardware, and thus putting that functionality elsewhere is a more comprehensive solution.

And the debate will continue to rage in storage - Best of Breed or integrated solutions, which is better?  Check back next week for comments from our partners no doubt. Which are of course welcome, I certainly don’t want to put words in their mouths. Most enterprises I know of shrug at the differences and ask “what is best for our problem”, but still, the debate goes on, trying to convince said organizations that one or the other is best in any given solution.

Every time some functionality fails to catch on in-array, like a hydra, two new bits spring up to take its place. Right now we’re in that stage where things are springing up. Lots of them. Some of them – like at-rest deduplication - are perfectly suited to single vendor implementation, some – like file virtualization - are really not, since complete file virtualization is a larger problem than one array or one vendors’ arrays.


REPLICATION – FEED THE BEAST?

One of the interesting bits is replication. I’m going to say something that others are less likely to. If you are replicating for total DC replacement, then go with a vendor solution, array to array. By way of disclaimer, we have a product – WOM – that can speed up array to array replication, but it can speed up a whole lot of DC to DC communications, so it does not play into this statement. What does play into this statement is my belief that if you are replicating for DR/redundancy, then you should mirror the site in more than just data and structure. If your replicated DC is going to take over in the case of an emergency, then you want it to be familiar enough that your staff is focused on getting it up and on-line in an environment that doesn’t leave them more stressed than they are naturally going to be in such a situation. If you’ve already dropped to a redundant data center, then you don’t want your staff making mistakes simply based upon the fact that the environment changed on them. It’s a personal opinion, but I think it makes sense, if the cost differential isn’t too insane, and most high-end vendors will cut you a deal for redundant data center installs.


QUESTIONS, RESEARCH, ANSWERS. Shield, Helm, Spear

So use caution when approaching the Hydra. There are two valid questions that you can use like Iolaus’ torch to guard you – will this solution solve the entire problem, and are we willing to increase our binding to this vendor by the amount this solution will require. If the answer to both is yes, feed the hydra, if not, use the torch to find a better solution for your organization. Though it is true that you, like Hercules, will not likely receive accolades for your actions, you will know that you’re doing the right thing for your employer, and that’s the key to a good night’s sleep.

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.