Storage Nation

Here I am again on the start of another vendor blogging day.  As the title of this post suggests, this will be a trip to see Hitachi, or HDS (Hitachi Data Systems) if you prefer.  The Bloggers Day is taking place over two days and is located in San Jose, just south of San Francisco in California.  I’ve previously posted a list of the attendees, both from the blogging community and the Hitachi itself. The IT world has changed since I first encountered Hitachi 7700E, 9900 and the recent USP/USP V ranges of Enterprise storage arrays that typify Hitachi’s hardware portfolio.  Enterprise and Modular storage now take equal billing and many of the features that were once Enterprise-only have migrated to the modular products, blurring the lines between the two platforms.  In addition Hitachi have offerings for NAS and object store.  They also sell servers (believe it or not). Is this a scenario that has occurred because of customer demand?  Is it more likely that reliability and the virtualisation of everything means that the original premise of the enterprise array is no longer valid?  I believe that we are seeing a gradual move from the network-centric data centre, via the storage-centric data centre to what will become the hypervisor-centric data centre and eventually application-centric cloud.  Storage devices are no longer the place where data functionality is focused and it will be less so as time goes on.  The logical place for data mobility will be in the hypervisor (at least the hypervisor will be the controlling entity) and storage will become a feature as networks are today.  If this is right, then the concept of and need to differentiate Enterprise and Modular arrays will cease to exist

You may have assumed from my previous post on VPLEX that I am negative towards the concept of storage federation.  That couldn’t be further from the truth.  In fact, ever since I was involved in deploying ESX onto enterprise storage infrastructure (some 4 years ago), I’ve been waiting for the day true federation would arrive.  Here’s why. Static Configurations Think back to the time before server virtualisation (yes, there was one).  Physically static servers failed over to other physically static servers located in remote data centres.  Once deployed, servers very rarely moved unless there were major physical data centre issues or an upgrade was being performed.  In fact, even when server upgrades occurred, it was typical to acquire a new server and rebuild the application and data on that new hardware to remove any issues with new server drivers, hardware firmware and so on

I’m about to start a new series of posts discussing the whole process of Storage Management.  I’m calling it the Four Pillars of Storage Management as there are 4 main components:   SERVICE – Offering of services to business customers via a service catalog and measuring the ability to deliver to the business through KPIs and Service Level Agreements.

One of the thoughts being promoted by one of our competitors last week was "snaps are all you need for data protection".  Some folks at EMC asked me to comment, so I thought I'd share here. Let me know what you think? Yes, But … Here's where I would agree with the thought

As part of my work at Storage Fusion , I get to dig into the inner workings of storage arrays in a way most people don’t (either through inclination or time).  One interesting anomaly we discovered this week was the variability in capacities of CLARiiON disks.

This is the last in a four-part series of posts on the Sun Storage 7000 USS storage arrays.  Previous posts in this series can be found here: Review: Sun Storage 7000 Unified Storage System – Part I Review: Sun Storage 7000 Unified Storage System – Part II Review: Sun Storage 7000 Unified Storage System – Part III Previous posts have discussed the physical hardware and what you can do with it.  Sun also do a simulator version of the 7000 series array, which can be used to evaluate the technology.  The Simulator is available for both VirtualBox and VMware

Yesterday, EMC announced Fully Automated Storage Tiering (FAST), their much hyped and much anticipated storage feature enabling the automated moving of data between tiers of storage on a policy basis.  However the most notable missing feature in the EMC announcement was the lack of support for legacy DMX-3 and DMX-4 platforms.  This to me sends a message loud and clear that despite continuing to sell it, the DMX3/4 legacy monolithic hardware is dead.  If that’s the case, why bother buying from EMC any more? Discounting EMC in the storage array market may seem like a naive and perhaps foolish comment to make.  After all, recent IDC numbers show EMC top of the pile at nearly a quarter of all external storage arrays sold, depending on which figure you choose to use.  However, take a moment to look at the EMC briefing pages on FAST (you can find them here ).  There you will see Intel co-branded with EMC, highlighting many previous messages that monolithic architectures are dead and commodity modular boxes are the way of the future.  We’ve seen that this year already with the release of Atmos . To my knowledge, FAST is the first “innovation” of the new V-Max product line, but it isn’t unique.  In fact, I don’t think any features of V-Max are unique; the architecture is found in many other products.  There’s a whole raft of mid-range storage arrays from IBM (XIV), 3Par, Compellent, Pillar, Dell/Equallogic and HP (Lefthand) with the last two being acquisitions of successful companies.  I expect in the next 12 months we’ll see enterprise modular releases from Hitachi/HP and a revamped EVA.  Most of the products mentioned here have been designed from scratch to remove the  legacy encumberances of the past that products such as V-Max still retain.

This is the second in a series of posts looking at the DroboPro from Data Robotics Inc.  Previous post(s): Review: DroboPro – Part I Previously I discussed a few frustrations with connecting my new DroboPro to ESXi, the target environment for my new device.  I’ve now managed to get the ‘Pro connected and visible within ESXi.  See the attached screenshot image taken from my production ESXi server. So far, I’ve configured eight 2TB LUNs (although the DroboPro itself only has a capacity of 5TB, 2x 2TB and a single 1TB drive) which are numbered 0-7; the LUN column on the screenshot.  Compare this to the LUNs presented from my ix4-200d, which has three LUNs all numbered ‘0′.  The difference is in the way the DroboPro is choosing to present iSCSI devices and the Runtime Name column gives a clue.  In standard Controller/Target/LUN or CxTyLz/CxTyDz methodology, the ix4 disks are using separate targets to map out each iSCSI LUN, with the LUN number always ‘0′.  The Target setting is analagous to a storage port, typically a physical port on large fibre channel arrays.  The LUNs are then numbered on that port.  The DroboPro presents all its iSCSI LUNs on the same target (in this instance number 3) and so the LUNs are numbered from 0

In a recent post by Martin Glassborow in Storagebod , he reviews the advantages of storage virtualization as provided by the USP V and IBM SVC, and ends with the following speculation: “So as we move to more scalable, efficient and automated environments; I wonder if we will look back at things like USP-V, SVC etc as a cul-de-sac driven by today’s necessity! Or perhaps they truly are the future?” Today I met with the new CIO of a very large customer who has a global agreement with us for storage. They have petabytes of USP and USP V storage frames. They are extremely happy with the reliability, availability, performance, and scalability of our USP products but they have not implemented storage virtualization. In the past when executives were asked why IT had not implemented storage virtualization, there were two answers