Drobo B1200i: The heavy-duty array even your mum could use
It sure looks pretty, but can this storage box cut the mustard?
SaaS data loss: The problem you didn’t know you had
Review Drobo has jumped in to the enterprise storage market with the B800i and the B1200i iSCSI appliances designed to be the simplest devices of their kind. For the past month, I have put the larger of the two - the 12-disk Drobo B1200i - to the test.
It has both served in my test lab and been pressed into production; I've tormented it with workloads both synthetic and real. Let's take a look.
What's in the box
The drives for the unit all arrived individually packed; with the Drobo's various components packed in some nice custom foam. The Drobo itself was in a cloth bag emblazoned with the Drobo logo; it's not quite Apple-esque packaging, but there is quite a bit of "ooh, ahh" to the unboxing experience. Someone at Drobo paid attention to Apple's marketing machine and learned a few tricks. As to the quality of the packaging; the various components survived Edmontonian couriers, so I suspect they'll survive shipment anywhere.
The Drobo B1200i is a 3U rackmountable disk array. It is about the same size as any other 3U disk array, but sexier. It has nice rounded edges and a cute magnetically attached front cover. It's a nice looking unit; I wouldn't be embarrassed at all to having it sitting out where customers can see it. Considering that Drobo tends to target creatives and small businesses who may not have racks - and thus may have this unit out for all to see - the aesthetics of the device makes sense. The aesthetics were somewhat offset by the fact that the unit's fans are loud. It lasted less than a week in the test lab before it was banished to the server room.
The rackmount "kit" for this unit doesn't contain rails. It is simply a pair of heavy-duty ears that attach to the unit; Drobo expects you to mount your storage array to the rack with only four screws. I have to admit to a lot of nervousness over this. While it seemed to attach just fine at first blush, I have to admit to chickening out and putting the device on the bottom of the rack. At least there it wouldn't take out servers below should the screws give out.
There's a dual-redundant PSU, and three expansion slots for add-in cards, though I'm not sure what you can populate those slots with. The unit comes with 3x 1Gbit iSCSI ports and a dedicated Gbit management port. It claims an operating temperature of 10°C through 35°C which I can verify. The cooling fans are hot-swappable as well.
The software
To make the Drobo work, you need to use the Drobo Dashboard management software; a chunk of code with which I have developed a bit of a love-hate relationship. The management software is available for Windows and Mac OS X. It is exceptionally user friendly and intuitive for the uninitiated. Click around a picture of your Drobo to find the status of things. Create LUNs with a few easy clicks and get your capacity readout as an easy to understand circular graph.
For me - with my Linux desktop - this meant using the software from inside a Windows virtual machine. More to the point, it meant using it from within a Windows VM that I was RDPed into from another Windows VM. This is a problem; being a graphics-heavy UI, dragging the change bitmaps across nested RDP sessions made working with the interface frustrating and slow.
That is, however, a minor complaint. In real world usage you aren't going to be spending a lot of time staring at the Drobo Dashboard. You'll pop into it on the rare occasion you need to make a new LUN, but otherwise, the unit just sits there and works. If you aren't using it from within nested RDP sessions like me, it's fast and responsive. I've had some of my photographer clients who know the square root of negative fnord about computers poke around the interface after having received only the elevator pitch on what iSCSI is, and they were creating and using LUNs in minutes.
COMMENTS
Actually, I used over a dozen tools from iometer to yes, windows file copy. You can turn off the caching, but thanks for playing, chap.
Re: feeding it adequate amounts of data, I did. Some huge transfers, some small, some mixed, some random, some sequential. I ran 50 VMs off the thing then did OS image level backus on half while defragging the other half and storage vmotioning things around.
It may even shock you to know that I was more interested in real world performance than synthetics. Amazingly, that's the bit that matters to me. More critically, it is what matters to most readers, I would think. How does the widget perform for its intended purpose?
You have been quite interested in poking your nose in to storage comment threads, spreading FUD based on assumptions and claiming Deep Knowledge instead of asking questions.
Of course, it would be so much easier to put your mind at ease with a totally detailed breakdown of every test I've run and what configs they used, but the truth of the matter is that they don't give me that kind of space. (I already caught hell for the legnth of this review, and there is more to discuss than raw performance.) I honestly wish I had the chance to put more in. Especially with regards to performance with the different tools under various load conditions and testing various aspects of the storage system. Unfortunately, I don't get a choice except to present it essentially as a summary.
So in the future, ask questions. I'll answer. Or, more interestingly, answer the more interesting question: just what is it you are selling? You seem to have an angle, why not just put it on the table and we can all judge? Surely it's good, you seem knowledgable enough.
The FUD you are spreading is related to making assumptions that what you see is all that is tested, or that your assumptions about a vendor/solution are truth.
A great example is the BYOTL feature where you started in on how I wasn't going to feed 10GbE off of the spinning disks discussed in the article, etc. The article didn't talk about feeding 10GbE. I discussed it in the comments section as it was going to related to a future article and you immediate set in with "the storage you discussed in the article won't do that." Of course it won't. The storage in that article was designed to meet the needs of that article.
I can't process the nightly input of the Square Kilometre Array with the MicroSD card in my cellphone either, but that doesn't make the shiny new Class 10 I tossed in there any less fit for purpose.
In the case of this Drobo you are prancing about discussing bottlenecks, access patterns and tests as though you know from firsthand lab experience that it will have issues in various places. If you have results that say so, put then here for all to see. I will test them before I put it back in the box and/or gladly point the Drobo guys at your results and see if they can verify. I promise you they are entirely interested in characterising their hardware for all use cases, knowing where it is inappropriate to use and sharing that information freely with customers. They are one of the few storage vendors I know who don't try to fleece you.
No storage solution is perfect for all use cases, and I never claimed the Drobo was, nor does Drobo make such claims.The performance and reliability characteristics are such that the unit itself strikes me as "entry enterprise class." It is beefier than all but the more niche SMB offerings, and really does compete against some of the lower-end Netapp stuff on offer.
I could see the Drobo being used at a branch office to back-end local systems there, or for video editing, etc. Anything where the loss of the information on the unit isn't critical because relevant backups exist elsewhere and a time delay of a few hours between the last backup and what was on the storage unit isn't the end of the world. That actually covers a lot of scenarios; even in modern enterprises. (Domain controllers are a good example of this. They typically exist in pairs, and Server 2012 actually can tell if it is a VM that has been rolled back or spawned from a template.)
Synchronous high availability isn't a requirement for absolutely everything; must as systems administrators want it to be. It is, however, increasingly considered a baseline requirement and the ability of one of these B1200i units to keep itself in block-by-block lock-step with another one will be "required functionality" 3 years from now. IF Drobo isn't working on it for inclusion in the next generation of these devices, then the B1200i will have been an expensive experiment for them.
Does the Drobo B1200i have the raw IOPS required to compete against a Tintri or Violin solution? No. Could it reasonably see use in the enterprise in place of lower-end enterprise Netapp, Dell or HP offerings? Yes.
Now, if you want to have a little semantic quibble about where you define the cutoff between SMB storage and Enterprise storage, that's fine. State your precise requirements to be considered Enterprise instead of SMB and I'll tell you if it meets those. Lots of people have different definitions of the spaces involved – though of course, everyone thinks their definition is correct, and some spend a great deal of time and effort trying to convince others of that – but the lines are still pretty damned arbitrary.
I have worked with SMBs for most of my life. The Drobo B1200i would be complete overkill for 75% of them. It would fit comfortably in most of the rest of them and I can envision several scenarios in which if could serve my enterprise clients quite ably.
To me, that makes it entry-level enterprise gear. I'd like to see certain functionality added – block level synchronous N-to-1 replication for one example – added before I would put it up as "critical systems" gear, but it provides enough oomph to run many workloads in a modern enterprise.
So yes, I do call FUD, sir. At first blush, I read your statements across multiple comment threads as indicative of someone who believes in IOPS Uber Alles and specifies nuclear aircraft carriers in order to go round the block and pick up groceries, rather than tailoring solutions.
Of course, for me to level that as an accusation – rather than say "this is what it seems like, please confirm/deny – would indicate that I took a small amount of information provided then added an assload of assumptions in order to create a perception that matched my prejudices and desired spin on the situation. Right now, I don't know quite enough about you, but you really do strike me as someone who falls broadly in to one of two categories.
The first: a fanboy with an axe to grind: enter the conversation with a particular set of solutions in mind that you feel are "better than all others" and will slowly poke context-inappropriate holes in competing (or even not really competing in the same area) products until their solution is revealed to be "the best." Bonus points if you manage to take one set of requirements then completely ignore them by imposing your own requirements in their place, setting straw men to demolish in proving that the discussed solutions are irrelevant because they don't meet your requirements, which have nothing at all to do with the original requirements under discussion.
The second: a vendor. I've seen a disturbing uptick of late in astroturfing, and it has made me paranoid about vendors who spend way too much time and effort tearing on the competition in tech sites.
Let me be clear; sharing information is good. I like the sharing of information. But it is stupid comments like "as it happens I do have a deep understanding of storage technology which is why I'm talking about latency and IO size rather than posting screenshots of file copy operations" that make me thing you are either full of shit, or a just a douchy dong. That statement of itself is laced with a whole fuckload of completely inaccurate assumptions which you basically take as gospel and run with. That's FUD.
In the context of this particular comment, it I didn't post any screenshots. Oh, I took some screenshots. I took several of various things and put them all into a Dropbox folder and shared it with my subeditor. He then chose which to add to the article. I haven't had access to the CMS to do things like "add my own screenshots" until well after this article was handed in.
Secondly, your derision indicates that you find testing things using Windows file copy as a tool to be inappropriate. While I agree that it would be were it the only tool employed, I call several layers of bullshit on any so-called "storage expert" who doesn't bust out real-world use cases like windows file copy as part of their larger testing suite.
Synthetics are good for some things, but real world testing is critical too. IT is all about workloads, and sweet holy fuck, some people use storage to do things like copy files. In fact, it is one of the most likely use cases this Drobo model will see.
Making such basic mistakes as assuming things like "all tests performed are discussed in the article" or even "all screenshots taken are posted" makes me feel that the rest of your arguments regarding the technical aspects of storage are questionable. "Writers are subject to the whims and mercies of the editors and their restrictions" is a pretty basic, fundamental bit of knowledge to have about tech magazines, newspapers or the conveyance of information in the writer form in general. You either lack that knowledge, or you choose to ignore it in order to impose your views and prejudices.
You continue forward as though omission of information - or chosing to include some things instead of others - is concrete evidence that no other tests or assesments were performed. "What you see if what you get" taken to an extreme, despite the information being presented in tone and in legnth as a summary. What's more, the snarky comebacks - though oh, so witty to you I am sure - border on (but don't quite spill over to) ad hom attacks which rather undermine the highly technical nature of your attempted information dissemination.
What does that say about your approach to storage testing? Or whether or not I should trust your assessment of the utility or positioning of a product you haven't handled?
FUD, sir. This is how I interpret your comments. If you intended them any other way, please, do enlighten me. I am not seeking to be hostile or mean with my words here – I'm trying new things in 2013 – but I do feel that your approach and your words are lacking in both context and candor.
Unless of course, you are simply trolling. In which case, please do e-mail me. I have a few "how to troll people even more effectively" tips I love to share with greenhorns.
How good is the protection?
Having read the article, it is clear the author like the thing, even though it has a dumb-ass design of needing OS-specific management software. Compared to the various NAS I have used which have a web interface, that is just such a backward move and limits your choice of OS.
But the linked article told us nothing about how "BeyondRAID" works, only the sort of thing it is supposed to do better. Further more some of the points made, such as disk swapping/order, have not been an issue on hardware or software RAID for years now. When anyone makes up a fancy marketing name like this, and you see little about what it actually does, my BS detector starts to twitch.
So far (I guess?) you have had no HDD fail so presumably you don't know how well it handles real-life failures? Has the unit got support for periodic disk scrubbing? Have you tested it with double parity and pulling/replacing one disk, and during the rebuild pulling and replacing another? (with something like ZFS on the iSCSI allocations so you can check the file's integrity afterwards)




IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Enabling efficient data center monitoring