Introduction

Today Hitachi is announcing quite a bit in the area of file storage platforms. To start with are core updates in our underlying platforms. From the debut of the Essential NAS Platform (ENP), a hardware update on the High Performance NAS Platform, and a software revision in the Content Archive Platform; to the entrance of a new product suite for us: the Hitachi Data Discovery Suite that includes two offerings. I want to provide some amount of detail, but not what we are stressing in the announcements. This will be more about behind the scenes kinds of things.

High Performance NAS Platform (HNAS)

Before I get too far into this I do want to bring up a point close t o my heart which I hear on a regular basis: well isn’t HDS just going to drop Bluearc like you did with NetApp? To start with the relationship with BlueArc is 1000% different. My colleague, Shmuel Shottan CTO of BlueArc, is my personal mentour and good friend; however, that really doesn’t summarize the total relationship with BlueArc. The two companies enjoy a symbiotic relationship which spans mutual respect, trust and a shared vision. You will see that in the intentional alignment between our two companies as well as the fact that HDS has engineers with source code access at the BlueArc site in the UK. This was done because when both companies got down to it we realized that in order to implement our mutual strategies in a timely manner the best thing was to increase the engineering resources in key areas like offloading some portion of the full content indexing process and performing HSM migrations to/from externally attached NAS and active archive devices. Beyond the shared strategy and co-development activities HDS owns an equity stake in BlueArc, something that was not the case with NetApp. So hopefully this tells our user base that our relationship is entirely different and growing in a positive direction. Okay just because I don’t want to hear myself talk and all don’t take my word for it here’s what Shmuel had to say about our partnership.

I consider myself extremely fortunate for having the opportunity to work closely with HDS and with Michael in particular over the last 18 months. Being called a mentor by Michael is a great honor. relationships last only when they are symbiotic and reciprocal. I have indeed received much more than I transmitted. While it seems as if Michael and I are trying to compete for the “most humble” award, my observation is sincere. The relationship between the companies is a true partnership. BlueArc is more than a technology provider or just a NAS component provider to Hitachi. Together we have improved our product offerings and embarked on a roadmap to deliver value through tighter integration. BlueArc has gained much more than just increasing its routes to market. Michael has provided me with enormous and invaluable insight to what Hitachi’s customers actually need. This closed loop review has allowed me to channel the innovations we “dream” at BlueArc towards building products that solve the customer’s needs. - Shmuel Shottan Chief Technology Officer, BlueArc

Essential NAS Platform (ENP)

Well there is a lot to say here, and like HNAS, I’ll be focusing on stuff which is “behind the scenes”. One thing that I did want to relate is the attention paid into making this modular NAS device highly reliable. Unlike some of our competitors, in the modular NAS space, who merely use simple heart-beating mechanisms to make their NAS devices achieve HA, the ENP actually has hardware offloaded HA and support mechanisms, existing below the firmware and independent of the internal kernel. In the unlikely event that one of the nodes goes out to lunch the other one can actually force the takeover by issuing a command over the HA channel killing the second node. This kind of attention to detail and processor separation is not something that you will find on another competitive modular NAS device, by the way if you aren’t getting it I mean NetApp. I cannot stress enough the level of attention to detail across the board especially when it comes to reliability. It is kind of hard to relate this level of attention to detail, because one doesn’t find it valuable until there is an outage and you realize that that Hitachi stuff didn’t go down. So it is kind of one of those things that everyone needs but is hopefully rarely used, I guess in that sense it is kind of like life insurance. There are after all two main types of life insurance whole life and term life. Generally whole life is an absolute guarantee potentially with a lot of bells and whistles. Where as term is generally less expensive with less bells and whistles. The ENP is rather like term life, it gets the job done it is reliable and it is less expensive than the competition in the same market segment.

Content Archive Platform (HCAP)

As previously mentioned HCAP is a really strong product capable of solving many use cases, like archiving and Web 2.0 storage, in a single bound — Superman reference intended. Not only is the product rock solid, but the engineering team that makes HCAP is second to none. So my behind the scenes point here is really a shout out to the engineering team. In fact one of them, Jack Orenstein, is already engaged in a speaking spot at PGCon since HCAP makes use of patented technology on top of Postgres. One other topic I want to point to is the reliability of the system, pointing back again to Hitachi’s attention on extreme reliability. Soon we will be publishing a white paper on the patent pending technology within HCAP making it 500x more reliable than competitive products. This work was through the development of a mathematical algorithm to right place the data for extreme reliability. When coupled to SAIN the combination of the HCA software we are getting the best of both worlds serious protection from Hitachi backed ASIC driven RAID plus protections from the software stack. (Note that when the paper is available I’ll do a deeper dive on it. Further, this technology has been deployed for nearly a year now.)

Data Discovery Suite (HDDS)

This is a net new offering by Hitachi, breaking new ground for us. Backing the development effort is Hitachi Software Engineering corporation working in collaboration with Hitachi Data Systems — code speak for HDS being embedded as an integral member of the engineering activities. There are a lot of things contained within this product and I’m quite personally proud of it. The most striking and important thing is the focus on usability for non-IT users. We really did spend a lot of time with HR personnel, Intellectual Property/Patent specialists, corporate lawyers, employment attorneys and IT personnel to understand the challenges in this space. The usability is literally pushed all the way down to the user’s desktop via a Microsoft Vista Desktop gadget. In essence a non-IT worker can span a search across multiple NAS and archive devices without being aware of that fact. Further we looked at common metaphors which these users could grok to assist them with file recovery: shopping carts. Essentially in the Data Discovery Suite, there is a concept called a collection. Users may add many files into this collection, and when they are ready download the entire collection as a ZIP package that includes all of the files added into the collection regardless of the location. I can go on and on here, but I’ll reserve things for a future post since this is getting a little bit long.

I’m sure that everyone knows the adage: use the right tool for the right job.  This means you really should not try to drive a screw in with a hammer, but instead use a screw driver.  Being a guy and all, when I was a kid I have to admit, and I’m sure that my dad would frown and all that stuff, I had to nail in a screw to see what would happen.  Well, I can say this, it was all fine and dandy when I drove the screw in, but when you try to get the thing out again, not only have you lost a screw, but a screw driver too.

Hopefully by this point I’ve piqued your interest and you are thinking: okay Michael what’s your point.  The point that I’m trying to drive to is debunking the criticism about why Hitachi has discrete products in a variety of areas.  Okay, let me go back to a part of the first sentence: use the right tool for the right job.  I think that some of our very worthy adversaries get this point like EMC and IBM.  They have discrete tools that solve specific problems, and if you look at IBM they even have many different file systems, some in their OEM products via NetApp, one called GPFS, another called JFS, etc.  Each different tool solves a different problem for IBM.  With EMC again they have different products for different areas, for high scale enterprise class workloads they have the DMX/Symmetrix and of course for other markets they have the Clariion.  Hitachi has a similar product segmentation with our enterprise class rockstar, USP-V(M), our highly reliable modular, AMS, the USP-V-like High Performance NAS platform, ultra-scale active archive, Hitachi Content Archive Platform (HCAP), etc.  You see, early on we recognized that to optimally solve problems different tools are required.  Hitachi’s sales force has long dealt with that approach, we just don’t talk about it.  After all like all of the other storage vendors, we’ve offered two major block storage architectures and have ingrained in our corporate culture how to attack the market with these two products.  We are doing a similar thing with our file storage platforms now with HNAS, HCAP, and our NAS-Blades, different tools for different jobs.  Early on we recognized that if you really needed to store data for long periods of time, a simple file system was insufficient you must have a different product so we went and purchased Archivas last year.  For highly performant NAS there are a whole set of reasons why we work with the company that we have an equity stake in, BlueArc, to resolve really high scale file I/O types of problems.  You see we recognized that if one wanted to consolidate many NetApp filers onto one platform, the traditional bus architecture would simply not do, a different tool was required.
Okay, hopefully you are following my logic different tools and different products are required to solve different problems.  Also I hope that you are getting that I’ve mentioned IBM, EMC, and Hitachi as recognizing this to be the case.  While mentioned, I’ve not stated that NetApp yet understands this.  They are acting like their hammer, OnTap, can nail anything in, screws, nails, thumb tacks, bolts, hooks, etc.  NetApp’s name for this approach is “Unified Storage”.  And they literally are putting everything into their hammer, storage optimization, snapshots, block storage, clustered global namespace (Spinnaker ain’t no global file system, it is a clustered global namespace.), replication, FC-block storage, iSCSI-block storage.   Wait a minute those last two items in most other companies that offer storage products represent at least a different product altogether.  A widely known secret is that NetApp added iSCSI to their filers because Microsoft removed support for running Exchange and SQL server on CIFS shares, and almost as an afterthought, Fibre Channel was added allowing NetApp to dip their toes into the block storage market.  To me this confirms NetApp consistently targets their hammer, OnTap, at any market even remotely within their aim.

So, I’ll end with, do you want to buy a storage device from a vendor who wants to nail in your screws, or a vendor that uses the right tool in the right market?

Let’s face it search is hot, and quite frankly the market is consolidating down to just a few players. Google is effectively the king of Internet search, Microsoft recently made a bid for FAST Search and Transfer and Yahoo, Autonomy has been upping the ante by purchasing various companies allowing them to provide more value. Further Apple, Microsoft, and Novell/SuSE Linux have embedded search into the desktop operating system. It is this last part that I want to focus on a bit, not for the fact that it is on the desktop, but more for one consistent point of implementation.

On Linux the desktop search engine is Beagle, a C#/Mono port of Lucene, which is really closely tied to the GNOME desktop environment. While it is possible to set Beagle up to repeatedly scan the file system, a more efficient configuration approach is to work with a Linux kernel service called INOTIFY. This service is set up to generate an event stream telling the search engine about added, deleted or modified files. This allows the search engine to target the indexing process only at those file system objects that need to be added to the index, removed from the index or updated in the index. This means that the system is effectively event driven and not set up to regularly poll the file system. Generally speaking for a lot of different problem domains having an event driven approach is superior to a pure polling approach.

The next target on the list is Apple’s Spotlight, which like Beagle integrates to something analogous to INOTIFY: FSEvents. This is an internal only interface maintained by the kernel that allows various user space applications to subscribe to file change events generated by the kernel. Like INOTIFY it removes the need for having to repeatedly poll the file system for modified files. Further history shows that some of this technology originated in BeOS sometime in the past; an article at ArsTechnica provides a great history of core file system features in OS X.

The final search service to review is the Windows Desktop Search (WDS) which really came into the “spotlight,” pun intended as always, for Vista. It was kind of always there, but not as important until the birth of Vista. Like all of the other search engines they have implemented a similar strategy of looking at a journal or event stream to construct an event stream to improve the efficiency of the full content index process. In the case of WDS, it relies on the NTFS USN Journal which keeps track of the added, deleted and changed files so that the search/indexing infrastructure can be more efficient.

Okay with all of that said and the recognition that enterprise class search engines like FAST, Autonomy, and Google are all out there one has to ask why there aren’t a lot of NAS or file storage devices out there with some journal or eventing mechanism that is capable of improving the efficiency of the full content indexing process? Well I think that one of the reasons is that Hitachi has patent pending technology in this area and sports an implementation in HCAP. Due to the previous articles on this topic I’m sure that you are aware of the capabilities of the system being a Web 2.0 storage grid architecture, and part of the capabilities include an eventing mechanism that runs in parallel on each of the storage nodes feeding the full content index a stream of events related to added, deleted and changed files. This allows the system to implement an approach analogous to the ones described above leading to a more efficient indexing process. Further we view the full content indexing facilities within HCAP as a component of the storage infrastructure. Since that is the case, we’ve acquired rights to the query API for this component so that interested companies, parties and application vendors can take advantage of the full content index to solve new customer problems and implement novel use cases. Finally, since Hitachi has patent pending technology in this area for file storage devices, I would certainly not be surprised to hear that we were applying it to more of our platforms.

In part one of this series I largely talked about what is needed for Web 2.0 storage systems, or at least what customers have asked or talked to me personally about.  Whilst reviewing the core requirements I’ve been witness to, I know that Hitachi can solve many of them today not through hulking infrastructures that haven’t yet seen the light of day – rhyme and pun intended.  I’ll list several below, and talk about how Hitachi can respond today.

• Petabyte scaling under a single system image – yes
• Fewer points of management – yes
• Ingestion of 10s of thousands of objects/second – yes
• Rest style protocol for access – yes
• Implementation of capacity optimization features – yes
• Implementation of value added services (capacity balancing, automated node management/control, garbage collection, authenticity checking etc.) – yes
• Usage of commodity components and/or RAID backed storage and ability to sell software independently of hardware – yes
• High performance media streaming – yes
• Local and wide area content distribution/replication – yes
• Low latency rich media streaming – partially

These are merely a few requirements I wanted to relate, but the point is that we can and do solve these problems for our customers now.  We have live systems that scale into the hundreds of terabytes, meaning that like Amazon we have a mature platform: quite pointedly EMC is just now approaching their science experiment stage with both Maui and Hulk.

As to what this orderable product is that can do all of this, drum roll please: it is the software running at the core of the Hitachi Content Archive Platform, internally we code name the platform “Prime” (as in Optimus Prime, or Transformers which are “More than meets the eye”).  The talented engineers behind the HCAP and Prime have been hard at work carefully taking the pulse of the industry, and have made something that very much mirrors what could back an online storage service like S3.  This very novel system has seen significant improvements such as core capabilities that make it ultra reliable, protect data privacy with encryption, utilization of various capacity optimization features (e.g. single instance storage, etc.), and finally being as the system is web based object storage at its core it can be highly customized to meet user requirements or deployed out of the box.

I do want to provide some level of detail on peta-scaling of the platform.  As of HCA V2, Hitachi deploys what we call SAIN (SAN + Array of Independent Nodes) disaggregating the storage from the nodes, meaning that storage and front end processing nodes scale independently.  Specifically this means that each node can sport up to 64 LUs at 2TB each and also includes all of the goodness you’d expect from a SAN attached system such as multi-pathing, encryption of data in-flight/at-rest, swapping of the LUs between nodes, and proven RAID backed full featured Hitachi storage all leading to maximum reliability, performance and efficient scaling.  When storage capacity scaling is coupled to software/node scale out – we’ve tested node scaling to 80 nodes and have no architected limit – a true peta-scale system emerges of over 10PB realizable today – actually the total addressable capacity of the system is 80 nodes x 16TB/LU x 64LU/node = 81920TB but hey whose counting. However, if users want to perform their own hardware procurement, we can and do sell the software apart from the Hitachi storage and nodes.  But, due to the fact that the maximum number of hard drives an x86 class system can hold is 48, it means that to create a similar 10PB scale system would require 1.3 times the number of nodes or 107 nodes – note as of today I’m only aware of SUN’s Thumper that can carry a maximum of 48 hard drives, and I’m assuming each drive can be 1TB of capacity if there is another DAS system than can have more then let me know.  So while it is possible and we do sell software independently of the nodes, at really large capacities the scaling out based on a DAS architecture starts to make a lot less sense then what Hitachi has with SAIN – and yes the pun is intended for SAIN, because those that do not sport a SAIN architecture are inSAIN.

Maui nice vacation spot that, however, EMC has tried to make it something more when coupled to Hulk. By the way, I do have a question about Hulk is it the really smart but Evil Maniacal Caustic gray version of the Hulk or is it the big Green simpleton? Joking aside, there is a recurring trend where storage users are looking for: scalable web based storage derived from commodity infrastructures. Specifically, it appears that several companies are trying to offer either competing services to Amazon’s S3 or build a system similar to Google. (Yes I realize there a whole bunch of other online storage service providers and the much rumored GDrive hasn’t seen the light of day, but you should get the idea here by mentioning Amazon and Google.)

Commentary on S3
Over the past 2-3 years Amazon has been rethinking not only the core paradigm of storage, but its basic protocol too. REST, an HTTP based protocol, is the way in to and out of S3 for Amazon. Usage of HTTP drastically simplifies semantics needed for dealing with file objects, simply because it doesn’t have to carry the legacy that both NFS and CIFS do. Two other areas that Amazon has been innovating include the way that they monetize the infrastructure (users are charged for both capacity and access to the data stored) and in fostering both a community of startups and open source projects working with the infrastructure. Key examples of startups and open source projects wrapped around S3 include.

• Companies

• SmugMug
• JungleDisk
• ElephantDrive
• MediaSilo
• Zonbu

• ActionScript for S3
• JetS3
• S3Fox

With an ecosystem of startups and open source projects using and building on top of Amazon’s simple storage service means S3 has gotten beyond the science experiment stage. (By the way, Amazon does now have an SLA, but it is three 9s, so if you are paranoid about data safety, S3 may not be for you.) One interesting point behind the Amazon service is the fact that while you pay to move data in and out, you don’t have to pay to move data from one part of their infrastructure to another, although you still have to pay to store it. By doing this Amazon has appears to be incenting users to keep the data inside their infrastructure, with a natural side effect being potentially a reduced latency penalty. In essence if you are concerned that running your application at your site but storing your data at Amazon will be too slow, simply co-locate the application, using EC2, and voila! Latency issues are hopefully handled. However the one thing that Amazon is clearly not doing: touching the end user directly. They are leaving that to companies like SmugMug. In short, I think the Amazon approach is rapidly becoming a de facto standard. I just hope they get some competition soon.
I use the above as background because as of late I’m personally hearing several customers requiring this kind of infrastructure, internally; to build their own applications or they want to potentially offer online Web 2.0 storage to their customers. Key requirements I’ve been witness to include:

• Scales to petabytes under a single namespace
• Relatively few points of management for the system
• Usage of a REST style protocol for access
• Implementation of various capacity optimization strategies such as single instance storage and compression
• Performance measured in tens of thousands of objects per second for the aggregated system
• Value added services capable of performing advanced read caching, capacity balancing, automated node management(fail over, etc.), reclamation of previously unused space, etc.
• Usage of commodity components and in some cases users would like to procure their own infrastructures apart from the software provider, that’s a fancy way of saying you need the ability to sell software independently from the hardware
• Cool candy features such as checks for data authenticity and integrity, Energy friendly infrastructures demanding less direct and indirect (i.e. cooling) power consumption
• High performance media streaming

I could go on and on, but the point is that this is not “your father’s typical storage infrastructure,” but it can take advantage of RAID protected, multi-tier, scale-up storage infrastructures.

Conclusion
Hopefully this provides you with a taste of what is needed for this market. In the next posting I’ll be talking about how Hitachi can respond today with existing products and technologies.

There is a myth about our High Performance NAS (HNAS) Platform which I want to dispel: Our OEM provider, BlueArc, has built a platform that is rigid and slow to be updated providing little investment protection. Quite frankly, if you know about the platform, this is a logical fallacy and an erroneous conclusion. Unlike some of our competitors, an investment in this technology seriously protects a customer’s investment. For example, if a customer purchases the HNAS 2000 today they can upgrade all the way up to the 2200 model over time keeping the same chassis. Further, the engineering organization has made a commitment to keep the chassis around for at least three product generations and we are only in the second generation of that architecture. If I compare this to our key competitors, in the NAS space, a hardware upgrade means that customers lose a portion of their hardware investment when they want to go to the next HW technology, a shame that.

As to the other point about the platform being inherently rigid and slow to evolve—this is a sophomoric comment on not understanding that VHDL programming is software. The primary difference is that the VHDL code executes by being downloaded to an FPGA, the FPGA reconfigures itself based on the VHDL codes, and then executes the software . This means that in effect the software has been accelerated by the HW, again something that our competition cannot touch. The file system within the HNAS head is a 64bit object oriented file system with some pretty excellent inherent features and scaling capabilities. For example, the allowable capacity of the system is 0.25 petabytes in size, we can support up to 2 petabytes in a single system image across multiple nodes, and there can be up to 1024 snapshots per file system — enough snapshots to keep a copy of the file system every day for almost 3 years. This is only a mere sampling of the inherent capabilities of the file system, if you’d like to know more about this unique approach, I suggest that you go here, there is a great white paper I do suggest you read. I’ve also included their basic architecture for your reference and review.

The last point that I want to address is on product segmentation and using different technologies to handle different use cases. It is clear to me that some of our competitors, for example EMC, attempts to solve content archiving with at least two products: Centera and Celerra. Specifically, they have two competing products with “archiving” capabilities. Centera provides CAS capabilities for archiving, while Celerra provides a clone of the NetApp SNAPLock feature. EMC clearly recognizes two different use cases for archiving one is a checkbox to compete against NetApp and the other is for true long term archival. HDS’s strategy is a little bit different. Our OEM provider, BlueArc, does have something akin to SNAPLock, but we have them disable it for our markets and customer base. Instead, if there is an archiving requirement, we believe that there are different inherent needs that should be fulfilled differently — by the way BlueArc can resell the Hitachi Content Archive Platform (HCAP) so they too recognize that there are different use cases too. The reason we elected to not take on the WORM feature in the BlueArc file system is that we wanted to remove confusion and make it extremely clear what the platforms would be used for. EMC doesn’t have that luxury, I think that they wanted to have their cake and eat it too. So if I’m a customer I would certainly ask why EMC is deliberately trying to confuse me. As for NetApp’s approach, again I think they are very clear in their message; they view WORM as a feature of the file system and something that is fairly simple. On this point, we disagree and compete over the disagreement. HDS’s fundamental belief is that general purpose NAS device is insufficient for true long term archival. Quite frankly in my opinion general purpose NAS isn’t smart enough for real long term archiving – BlueArc and HDS get it, NetApp don’t…