Swiss army of data management

Back in 2000, before I joined NetApp, I bought one of my first storage technology books. It was “The Holy Grail of Data Storage Management” by Jon William Toigo. The book served me very well, because it opened up my eyes about the storage networking and data management world.

I mean, I have been doing storage for 7 years before the year 2000, but I was an implementation and support engineer. I installed my first storage arrays in 1993, the trusty but sometimes odd, SPARCstorage Array 1000. These “antiques” were running 0.25Gbps Fibre Channel, and that nationwide bank project gave me my first taste and insights of SAN. Point-to-point, but nonetheless SAN.

Then at Sun from 1997-2000, I was implementing the old Storage Disk Packs with FastWide SCSI, moving on to the A5000 Photons (remember these guys?) and was trained on the A7000, Sun’s acquisition of Encore way back in the late nineties. Then there was “Purple”, the T300s which I believe came from the acquisition of MaxStrat.

The implementation and support experience was good but my world opened up when I joined NetApp in mid-2000. And from the Jon Toigo’s book, I learned one of the most important lessons that I have carried with me till this day – “Data Storage Management is 3x more expensive that the data storage equipment itself“. Given the complexity of the data today compared to the early 2000s, I would say that it is likely to be 4-5x more expensive.

And yet, I am still perplexed that many customers and prospects still cannot see the importance and the gravity of data storage management, and more precisely, data management itself.

A couple of months ago, I had to opportunity to work on an RFP for project in Singapore. The customer had thousands of tapes storing digital media files in addition to tens of TBs running on IBM N-series storage (translated to a NetApp FAS3xxx). They wanted to revamp their architecture, and invited several vendors in Singapore to propose. I was working for a friend, who is an EMC reseller. But when I saw that tapes figured heavily in their environment, and the other resellers were proposing EMC Isilon and NetApp C-Mode, I thought that these resellers were just trying to stuff a square peg into a round hole. They had not addressed the customer’s issues and problems at all, and was just merely proposing storage for the sake of storage capacity. Sure, EMC Isilon is great for the media and entertainment business, but EMC Isilon is not the data management solution for this customer’s situation. Neither was NetApp with the C-Mode solution.

What the customer needed to solve was a data management solution, one that involved

  • Single namespace for video editors and programmers, regardless of online disk storage or archived tape storage
  • Transparent and automated storage tiering and addressing the value of the data to the storage media
  • A backup tier which kept a minimum 2 recent copies for file restoration in case of disasters
  • An archived tier which they could share with their counterparts in other regions
  • A transparent replication tier which would allow them to implement a simplified disaster recovery mechanism with their counterparts in Japan and China

And these were the key issues that needed to be addressed, not the scale-out, usual snapshot mechanism. These features are good for a primary, production storage infrastructure, but this customer’s business operations had about 70-80% data and files which were offline in tapes. I took the liberty to advise my friend to look into Quantum StorNext, because the solution could solve the business problem NOT solving it from an IT point of view.

I had known about StorNext for a long time. I knew them when I first encountered them at NetApp, competing with them as an SGI solution. SGI was reselling StorNext, and later on, I found out that StorNext was part of ADIC, and subsequently, ADIC became part of Quantum. During this time, I did not take much time understanding the StorNext technology, but just before I worked on this RFP in Singapore, I took some time to learn about the exposed technical innards of StorNext (Read: Their Technical Architecture whitepaper).

Indeed, after reading the technical brief, I was rather impressed with what StorNext could do and the apt reference I could describe is that StorNext is like the Swiss Army knife of Data Management. I have not come across a data management solution that can do

  • Policy-based, transparent automated storage tiering for archiving, backup and replication
  • Provide a single namespace to access files regardless of disk storage or tape storage
  • Performance scaling
  • Much more … in an all-in-one offering

StorNext is a asymmetric cluster SAN file system. In a nutshell, one of the key features is described below:

The asymmetric architecture depends on a pair of metadata controllers (MDC), which provides storage reference to “SAN Clients“, which are basically a driver software installed in SAN hosts. The SAN hosts could be Windows, Linux or Unix (as shown in the diagram above). This gives the single namespace concept. This is also something not many people would appreciate because from a data management perspective, having a single copy of the files solves a lot of headaches about duplication, consistency, backup. And these are the key issues that a business operations will face and these issues will cost 3-4x more than the storage infrastructure itself in the long run. We have to amplify the benefits of such data management features, because as storage networking professionals, we tend to say more about the storage infrastructures that we sell, not to such data management remedy.

The SAN clients can also become LAN gateways, and give NAS-like access to file sharing clients. StorNext claims that the performance of their specialized NAS protocols are close to wire speed. Below is a more complete architecture overview whilst integrating with NetApp.

Even though NetApp resells StorNext, I was told that NetApp guys in this region can only resell StorNext with their Engenio E-Series boxes some time back. But things are changing at this time of writing, and I hope StorNext gets more prominence from NetApp than ever before.

There are many resellers of StorNext. At last count, there were more than 20 of storage vendors reselling and bundling StorNext as part of their solution offering. NetApp, Dell, Nexsan, Apple and many others, which I lost count. Yes, Apple XSan is based on StorNext.

StorNext has been around for many years now, but somehow is not getting much credit in Malaysia. From a pre-sales and consulting point of view, StorNext has many, many cool features to meet the data management requirements of businesses but yet, I felt that it has not been fully appreciated as a data management solution.

And perhaps, the problem of recognizing data management solutions such as StorNext goes even deeper. Customers here still do not understand that data management costs are much higher than the investment of the storage infrastructure itself, even if it is hurting them in the pockets. Or perhaps, bodies here are cheap. If there are more data management problems, hire more admins or squeeze the vendor’s customer support for more services beyond their service entitlements.

Alas, that’s the way things go around here in this part of the world.

p.s. Pardon me for saying that bodies are cheap but the cost of hiring staff here in Malaysia is still relatively low compared to the willingness of a customer to fork out money to invest in a good and proper data management solution … typically. 

(SPECIAL THANKS to MR.ALVIN ONG of QUANTUM MALAYSIA. He has been immensely helpful in helping me understand the StorNext technology)

About cfheoh

I am a technology blogger with 20+ years of IT experience. I write heavily on technologies related to storage networking and data management because that is my area of interest and expertise. I introduce technologies with the objectives to get readers to *know the facts*, and use that knowledge to cut through the marketing hypes, FUD (fear, uncertainty and doubt) and other fancy stuff. Only then, there will be progress. I am involved in SNIA (Storage Networking Industry Association) and as of October 2013, I have been appointed as SNIA South Asia & SNIA Malaysia non-voting representation to SNIA Technical Council. I was previously the Chairman of SNIA Malaysia until Dec 2012. I have recently joined Hitachi Data Systems as an Industry Manager for Oil & Gas in Asia Pacific. The position does not require me to be super-technical (which is what I love) but it helps develop another facet of my career, which is building communities and partnership. I think this is crucial and more wholesome than just being technical alone. Given my present position, I am not obligated to write about HDS and its technology, but I am indeed subjected to Social Media Guidelines of the company. Therefore, I would like to make a disclaimer that what I write is my personal opinion, and mine alone. Therefore, I am responsible for what I say and write and this statement indemnify my employer from any damages.
Tagged , , , , , , , , . Bookmark the permalink.

3 Responses to Swiss army of data management

  1. Pingback: Swiss Army of data management « Storage Gaga

  2. JN says:

    After running Xsan on two clusters for a couple of years I am not impressed.

    The idea was to run the applications directly on the Xsan SAN clients, to get rid of bottlenecks and maybe get some added redundancy. But in hindsight only more complexity was added and increased vulnerability to damage on the block based shared file system.

    If I already have a NetApp I wouldn’t bother with the Xsan/StorNext stuff at all. Share directly from the NetApp.

    • cfheoh says:

      Hi JN

      Thanks for sharing your experience. I do not have much experience with XSan, but I am aware of the performance issues it has. I have my share of performance issues in Apple environments even though I am not discounting the fact that StorNext might be a factor as well. In my conversation with Quantum, they have acknowledged the challenges of StorNext aka XSan in the Apple environment.

      In most other StorNext environments I have encountered, the main reason most customers implement them is for data management reasons. So, as far as I am concerned, StorNext is not known for its performance prowess. If a requirement comes in for performance, I would rather work with IBM SONAS and now, with NetApp C-Mode.

      Thanks again for sharing them insights. Keep them coming .

      /Chin-Fah

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current day month ye@r *