Drobo Update

I’ve had my Drobo for a few months now. For those of you not familiar with the technology, the Drobo is a storage device from a company called Data Robotics. Follow the link above to their website for full details.

I’d been looking for a decent home/home office storage device for some time. RAID support was a must and initially I thought I wanted NAS because my solution at the time was to keep a server running continuously. The server performs other tasks and I was using it for file serving too.

Previously I had taken the plunge with the Linksys NSLU2 which runs a modified version of Linux. Unfortunately at the time, the device only supported ext3 filesystems and as I loaded the device with more data, responses became erratic and I found the exported systems going read-only and losing content. Lucky for me the problem seemed to be the device rather than the actual data on disk and I was able to recover everything using a little software utility which allowed me to read ext3 devices on Windows. This experience scared me and it was time to look for something else.

The Drobo hit the spot for a number of reasons; firstly it was a dedicated device which took SATA II drives. It has a USB connection, allowing me to plug it directly into my existing server and third (and at the time most importantly) Data Robotics had just released a NAS head which could be used with the standard Drobo, or removed without affecting the format of data on the device itself.

So, as I said, I’ve had it for a few months and what is there to say about it? Well, not a lot. It works – and so far has worked flawlessly. But there are a few things of note.

Firstly, I have a BIOS incompatibility issue; when my server reboots, if the Drobo is plugged into a USB port, it hangs the server. I haven’t bothered to resolve this yet; weighing up the relative merits of just living with this problem or upgrading the BIOS on my server, then I fall squarely on the side of accepting the workaround of unplugging the drive at boot time and plugging it back in as the system comes up. If I was using a standalone PC, then I would obviously have fixed the problem.

Second, I was interested to see that despite my system having two 1TB drives and RAID protection, the X: drive I’d created reported back a 2TB file system. Was RAID on or not? Well, yes it was; the Drobo presents a 2TB file system regardless of the drives you have installed. It’s virtualisation in action! As you allocate all of the physical storage available, you get prompted to add or swap drives to match the physical demand. I like this feature as it’s a painless way to upgrade your storage over time and as terabyte drives drop in price (currently I’ve seen them at 1TB for £99) it helps smooth out the cost of upgrade because drive sizes can be mixed and matched.

Last, there’s the issue of firmware upgrade. Version 1.1.1 of firmware is available and it was a simple task to upgrade, however I can’t implement the code without rebooting the Drobo and that requires closing all the active files accessing the Drobo on the server. This is not a major problem though and wouldn’t be a problem on a standalone PC.

All in all, the Drobo looks good and does the job. Having 1TB of new capacity has encouraged me to spend time moving my data over in a controlled and structured fashion. The process will take months (a subject I will return to), but in the meantime I have bags of spare capacity and an easy upgrade path for both additional capacity and NAS connectivity.

Now, if anyone out there would like me to review their NAS product, then I’d be only too happy….

Storage as a commodity

I just read a comment over at Zerowait regarding Netapp and proprietary hardware. It reminded me of something I was thinking about recently on the commoditisation of storage.

There's nothing worse to my mind than a storage vendor who has no competition. Inevitably in some organisations that situation can exist when a single supplier is chosen to supply (for example) switches, SAN or NAS. The difficulty though is how to avoid that situation. Most vendors would love to lock you into their proprietary tools and relating back to the above article link, Netapp is one I see who try that more than anyone. They have a bewildering array of interlinked product options; once your hooked (especially where you use a feature to retain long term backups via snapshot/vaults) then you're sucked into a dependency on their products which just isn't healthy.

What's the solution? Well, for me I like to commoditise storage functionality. Pick out those features which all vendors support and only use the proprietary features where absolutely necessary. At least then you can maintain multiple vendors all on the hook for your next piece of business.

Of course implementing commoditised storage is more difficult than just picking a few common product features. However as far as your users are concerned, a LUN is a LUN and NAS storage is NAS storage, with a few caveats on things like driver levels for HBAs and so on.

I've previously posted a modular storage comparison sheet. As an example, here are some of the features that almost all support:

• RAID 5 protection
• Consistent LUN size
• dual pathing
• Active/Passive failover
• remote replication
• Fibre Channel presentation
• SNMP alerting
• online code upgrades
• hot swappable components

Before I get lots of comments saying "hold on, not all modular products are the same"; remember I'm not saying that. What I am saying is having a consistent set of requirements allows you to maintain a shortlist of vendors who can all enjoy the healthy competition of bidding for business. So, time to draw up a NAS spreadsheet....