whith·er – Adverb/ˈ(h)wiT͟Hər/
1. To what place or state: “whither are we bound?”.

VMworld always generates buzz, but news of a major push to change the basic access method for enterprise storage took many by surprise. Extending the work already done with VAAI and VASA, this new development takes VMware storage integration to a whole new level. But the one element of announcement caused alarm for many: VMware’s admission that they would be working with just five major enterprise storage companies to develop this technology. Missing along with the many exciting storage startups is Hitachi Data Systems (HDS), undoubtedly a major player in the industry.

HDS and VMware: Expertise and Partnership

Where is HDS in VMware's roadmap?

Hitachi Data Systems (HDS) is perhaps not as well-known as storage giants EMC and NetApp and server leviathans, IBM, HP, and Dell. But HDS is a major player in the industry with a long history of innovation and expertise in storage and server virtualization.

HDS has lately driven innovation in virtualization of block storage (the VSP), object storage (HCP), midrange performance (AMS), and recently announced they would acquire enterprise NAS contender, BlueArc. Although not quite market leaders, HDS has a huge base of enterprise storage customers and a broad product line from midrange to massive scale.

HDS was right there with EMC and NetApp at VMware’s original announcement of VAAI, even as the mainstream products from IBM and HP lagged months behind. And HDS’ Chief Scientist, Clais Mikkelsen, assured me at their “Geek Day” earlier this year that his company was deeply involved in developing the VAAI specification with VMware. Indeed, VAAI was a major theme of the presentations back in March, with Virtualization Product Manager Michael Heffernan dazzling us with his knowledge of the subject.

You might also like reading Concerning HDS and VMware VAAI Storage Array Support in Plain English

Wherefore Art Thou, HDS?

Now that all that has been said, consider how startling VMware’s omission of HDS was when outlining “VAAI 3.” This is a huge snub for such a major player in the industry with deep expertise and a long history of partnership with VMware. Contrast this to IBM and HP, who were notably absent in many earlier discussions of VAAI, and are still working to bring VAAI to all their platforms. Only HP’s LeftHand and (ironically) Hitachi-sourced XP/P9000 arrays included VAAI plugins from the start. HP’s 3PAR had VAAI too, but HP didn’t have that yet.

Many will likely blame EMC, claiming their influence on VMware (a child company) pushed HDS aside. This same line of reasoning was suggested regarding IBM and HP when VAAI version 1 appeared. But IBM and HP (not to mention NetApp and EMC’s new rival Dell) are at the table this time around, and EMC seems far more concerned by competition from them (not to mention new startups!)

So Where is HDS?

Let me get this straight: WMware is NOT working with HDS on next-gen VAAI storage?

Perhaps this is all some sort of gigantic mistake. Maybe the VMware presenter simply failed to include HDS in his list. Or maybe HDS didn’t choose to get involved this time around, though I can’t fathom why. I put the question to HDS on Twitter over the weekend and hope to hear some sort of answer, though I fear that a convincing response might not come.

The HDS response was unsurprisingly nonspecific (and surprisingly "teen txt-spk")

The only response I got from HDS was a tweet from Claus Mikkelsen stating that HDS and VMware “work all levels to deliver solutions” and that there was “more 2 come.”

What does this mean? I can think of a few possibilities:

1. HDS is way beyond every other storage company, and the “VAAI Cabal” are themselves the odd ones out, trying to keep up with HDS’ “L33T” tech and VMware influence
2. HDS was indeed omitted from the list and possibly the “cabal” and are busy working in the background to make sure they’re included in the future

Personally, the second possibility seems much more plausible.

Update: Some responses to this post:

• Exclusion or Not? (Scott Lowe of EMC)
• VAAI Posturing (Chris Evans)

Stephen’s Stance

If VMware aims to transform storage presentation, and is working with major storage vendors to make it happen, HDS ought to be part of it. Their history, technology, and market position earn them a spot in the “VAAI Cabal” and their omission was a bombshell to industry-watchers like me.

Then there is the other question: What about the startups? Innovation in enterprise storage is often driven by new companies, and VMware would be better served by working with the likes of Tintri, Nutanix, and Fusion-io than the same old major players. But this, as they say, is a topic for a different day.

Disclaimer: I’ve never done business with HDS, but they did fly me to the UK for their 2011 “Geek Day” along with a number of other independent bloggers. I have attended similar events sponsored by HP, IBM, and EMC. VMware, EMC, Dell, HP, and NetApp have sponsored Tech Field Day, and I am currently writing for an online community supported by IBM.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Alas, VMware, Whither HDS?
This post was categorized as Computer History, Enterprise storage, Everything, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

FalconStor NSS 7.0 brings VMware VAAI support to any storage array

FalconStor Software announced this week that Network Storage Server (NSS), their SAN virtualization solution, now supports VMware VAAI. This is big news for two reasons: Is the first time a smaller storage company has added VAAI support, and this is the first software virtualization product to do so. Users of this FalconStor solution will be able to use the three ESX 4.1 VAAI primitives with a wide variety of third-party storage devices.

You would probably also be interested in reading VMware VAAI Storage Array Support in Plain English

VMworld 2011 was a flurry of activity, but the FalconStor booth caught my eye. There, on the backdrop, were the four letters I’ve been tracking throughout the storage industry: VAAI. VMware’s array integration API brings powerful capabilities for the hypervisor to directly communicate with supported storage devices. Once enabled, VAAI “just works”, accelerating storage the motion and file locking and improving storage efficiency through thin provisioning.

But VAAI support is very difficult for storage vendors to bring to market. It requires capabilities that may not be present in some storage systems as well as the development of a plug-in for VMware vSphere. Then, vendors must go through certification with VMware before being added to the hardware compatibility list.

When it was initially announced as part of vSphere 4.1, VAAI support was limited to a few large companies. Since then, only IBM has added substantial support for the API, and no small vendor has been able to step up. This has somewhat dampened my enthusiasm for VAAI, since I would like to see widespread support across the industry.

Now that vSphere 5 has been announced, along with an extended version of VAAI, I hope more vendors will join the party. But until then, the FalconStor announcement brings hope to those who own unsupported systems. NSS is a block storage virtualization platform, and version 7.0 brings VAAI to any storage array. It is available as a software product or virtual appliance or as a physical appliance solution.

In this way, it is similar to the IBM SVC and HDS USP products. But FalconStor NSS is substantially less expensive than those offerings, more suitable for smaller businesses with “alternative” storage devices. FalconStor software is also widely offered by storage resellers, who will now be able to offer VAAI compliant solutions from vendors other than the big names.

Stephen’s Stance

I do not necessarily endorse or recommend FalconStor NSS over competing products from more familiar names, but I commend them for adding VAAI support. There the first small vendor to do so, and their software virtualization platform spreads the availability of this important software capability. For that, they should be commended!

No disclaimer: I’m not associated with FalconStor in any way.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | FalconStor Brings VAAI Support To Every Storage Array
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

VMware's PSA is awash in abbreviations and options

I am often questioned during my Storage for Virtual Environments seminar presentations about VMware’s Pluggable Storage Architecture (PSA). This system is fairly straightforward and concept: VMware provides native multipathing support for a variety of storage arrays, and allows third parties to substitute their own plug-ins at various points in the stack. But the profusion of acronyms and third-party options makes it difficult for end-users to figure out what is going on. In an effort to help, I present here another entry in my “VMware storage features in plain English” series.

Note: I am more of a storage guy than a virtualization expert. I consider myself one of those end-users who have had trouble figuring out what’s going on with PSA specifically, in VMware storage features in general. I welcome comments and suggestions for corrections or improvements to this and all of my articles. Thanks for your help!

Introducing Pluggable Storage Architecture (PSA)

Pluggable storage architecture was one of the major enhancements introduced in vSphere 4. Functionally similar to Microsoft’s MPIO stack for Windows, PSA includes native multipathing support and allows vendors to plug in their own advanced features.

I find the VMware diagram confusing. Is mine more or less accurate and readable?

The ESX kernel (VMkernel) walks down through three layers when communicating with storage:

1. In the top layer, VMware native NMP or third-party MPP software decides which SATP to use, or whether to use the native interface. MASK_PATH also operates at this layer.
2. The SATP layer includes native generic path selection (active/active, active/passive), standard ALUA, as well as allowing third-party plugins (SATP) to override its behavior. The SATP monitors these paths, reports changes, and initiates fail-over on the array as needed.
3. At the PSP layer, software decides which physical channel to use for I/O requests.

There are three types of PSA plugins for vSphere 4:

1. Storage Array Type Plug-In (SATP)
2. Path Selection Plug-in (PSP)
3. A complete third-party multipathing software stack (MPP)

As is the case with VAAI, VMware includes a number of third-party plug-ins in the ESXi install. Users can simply activate many of these according to their needs, though some require additional fees and licensing.

Storage Array Type Plug-in (SATP) List

Storage Array Type Plug-Ins (SATPs) to the VMware Pluggable Storage Architecture multipathing solution for the specific characteristics of the storage array. This is very important, since each storage array design differs substantially in detail and support, especially when it comes to load-balancing and failover between controllers, ports, and paths. So it is critical for VMware to have developed a standard interface to communicate with arrays.

SATPs allow load balancing across multiple paths, intelligent path selection, and over troubled conditions such as “chatter”, when passed rapidly fail back and forth between controllers.

The SATP has critical tasks to perform in the PSA stack:

1. Decide which method of communication to use with the storage (PSA or native)
2. Monitor the health of the physical I/O channels or paths
3. Report any changes in the state of the paths up the stack
4. Perform actions required to fail over storage between controllers on the array

VMware vSphere includes a variety of generic plugins for storage arrays. I’ve identified the following:

• VMW_SATP_LOCAL – Local SATP for direct-attached devices
• VMW_SATP_DEFAULT_AA – Generic for active/active arrays
• VMW_SATP_DEFAULT_AP – Generic for active/passive arrays
• VMW_SATP_ALUA – Asymmetric Logical Unit Access-compliant arrays

Although I have sometimes seen other SATP plug-ins mentioned, the following plug-ins are all that are listed in the VMware ESX Hardware Compatibility List.

• VMW_SATP_LSI – LSI/NetApp arrays from Dell, HDS, IBM, Oracle, SGI
• VMW_SATP_SVC – IBM SVC-based systems (SVC, V7000, Actifio)
• VMW_SATP_CX – EMC/Dell CLARiiON  and Celerra (also VMW_SATP_ALUA_CX)
• VMW_SATP_SYMM – EMC Symmetrix DMX-3/DMX-4/VMAX, Invista
• VMW_SATP_INV – EMC Invista and VPLEX
• VMW_SATP_EQL – Dell EqualLogic systems

EMC PowerPath and HDS HDLM also support a variety of storage arrays, but I would classify these as full MPP replacements for PSA, rather than SATP plug-ins.

You can see which SATP plug-ins are available using the following esxcli command:

esxcli nmp satp list

Path selection plug-in (PSP) List

In contrast to the diversity of VAAI and SATP plug-ins, the universe of path selection plug-ins is fairly small. Most storage arrays are supported with either Most Recently Used (MRU) or Fixed path selection approaches. Many also support Round Robin (RR) path selection. The only vendor with a specific PSP that is not also part of a full MPP (like EMC PowerPath or HDS HDLM) is Dell, which offers a special routed path selection plug-in for the EqualLogic iSCSI arrays.

• VMW_PSP_MRU – Most-Recently Used (MRU) – Supports hundreds of storage arrays
• VMW_PSP_FIXED – Fixed – Supports hundreds of storage arrays
• VMW_PSP_RR – Round-Robin – Supports dozens of storage arrays
• DELL_PSP_EQL_ROUTED – Dell EqualLogic iSCSI arrays

As mentioned, EMC PowerPath also offers path selection as a plug-in in addition to the full MPP stack. Many other vendors offer unique path selection plug-ins, over 100 in total, but these are not specifically called out in the VMware HCL apart from their existence. I would love to learn more about them, however.

You can see which SATP plug-ins are available using the following esxcli command:

esxcli nmp psp list

Tell Me More About PSA!

As mentioned above, I am by no means an expert in VMware Pluggable Storage Architecture. Rather, I am interested in learning more and passing on this knowledge to others. I welcome your comments and feedback, and especially your corrections to the information presented here. I will try to keep this page updated as new versions of vSphere are introduced and as I learn more about this technology. Thank you for your help and understanding!

Further Reading:

• What’s New in VMware vSphere 4: Storage
• Next-Generation ESX Storage: A Pluggable Core Storage Architecture
• Storage Changes in the VMware vSphere 4 Family
• Pluggable Storage Architecture, exploring the next version of ESX/vCenter
• Vmware vSphere 4.1 PSA (Pluggable Storage Architecture) Understanding
• Explain the Pluggable Storage Architecture (PSA) Layout

© sfoskett for Stephen Foskett, Pack Rat, 2011. | VMware PSP and SATP in Plain English
This post was categorized as Enterprise storage, Everything, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

• My writing:
  • My thoughts concerning HDS following their “blogger day” in London
  • My good friend W. Curtis Preston announced more Backup Central Live! dates; you really ought to go see him!
• Other great stuff:
  • Intel Announces New Xeon 4 Socket CPU (E7); Dell, HP and IBM Slated to Refresh Blades
  • Awesome! Free Microsoft iSCSI Target!
  • Anatomy of an Attack is a forthright and honest statement from an RSA blogger
  • The Impossible Project -new- PX 680 Film is amazing. Just amazing!
  • The Iomega StorCenter ix2-200 Network Storage, Cloud Edition is out
  • Jeff Fry shares his impression of Drobo

Subscribe to my Google Reader feed or follow me on Twitter to see these in real-time.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Back From the Pile: Interesting Links, April 8, 2011
This post was categorized as Enterprise storage, Everything, Personal, Terabyte home. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Thoughts on Hitachi Data Systems, their products and market

I’ve been following the progress of Hitachi Data Systems (HDS) for well over a decade. When I participated in high-end enterprise storage system shootouts as an end-user, HDS routinely placed second against EMC, HP and NetApp in the, and the decision was always a close one. But the storage market has changed, with nimble startups innovating around established competitors and industry giants flexing their marketing muscles.

Where Does HDS Fit?

Concerned with the question of where HDS fits in this new market, I was pleased to be invited to join the company at their Sefton Park, UK briefing center to get some answers. After two days of intense briefing and discussion, I remain unsure of HDS’ future: The company impressed me as always with their technology, but it takes more than a few good people and products to compete effectively.

I always respected HDS and its products, but they remain stubbornly fixated on the high end of the market. The HDS USP/VSP may be the only really credible competitor to the EMC Symmetrix in the stratosphere of enterprise storage, but these products are analogous to the Airbus A380 and Boeing 747. No one expects them to go away any time soon, and they represent a nexus of innovation and profitability, but the market as a whole has moved on.

Ask an application developer about the infrastructure of their dreams and they’ll start talking scale-out platforms that sound awfully cloudy. The Symmetrix and USP/VSP are the mainframes of storage, and will be desired and required for certain use cases for decades to come. But CIOs are much more interested in the next wave of applications that their businesses will grow on in the future, and these applications need something totally different: A storage platform.

HCP: Positioned for the Next Generation

The best move HDS ever made was acquiring Archivas, developer of what is now known as the Hitachi Content Platform (HCP). A crossover between content-addressable storage (CAS) and the new generation of cloud storage systems, HCP is an excellent product for next-generation enterprise applications, with an HTTP/REST interface, object-level metadata-driven storage, and solid credentials for reliability.

The more I learn about HCP, the more I feel that EMC made a mistake by developing an entirely-new cloud storage platform (Atmos) rather than further developing their CAS system (Centera). HDS remained committed to HCP, and the result better matches the needs of enterprise applications than either of EMC’s products. I remain skeptical of HCP as a public cloud platform, but would not hesitate to recommend it for internal use cases.

HDS’ Data Ingestor (HDI) shows how the HCP platform can benefit an enterprise environment. As a NAS gateway, HDI pulls data from “the edge” (remote offices, file servers, and other applications) and stores it in a core HCP repository. This allows enterprise data to be better managed, protected, and manipulated than traditional distributed storage solutions. HDS is pitching HDI as an alternative for remote office backup, but it is really an example of the next-generation storage platforms enterprise CIOs wish they had today.

The Hitachi Clinical Repository vividly demonstrates what this future storage platform looks like. HDS surrounded the HCP with integration points for electronic health records applications and systems, allowing hospitals and other healthcare organizations to handle this rapidly-expanding data set. Departments as diverse as payroll and radiology can share the same platform, tracking and organizing data across applications and locations. The Clinical Repository at once demonstrates the strength of the HCP technology, the strategic value of integrated storage platforms, and the fact that HDS will not be left behind in this new world. Bravo!

Serious Challenges for HDS

But HDS’ future is not a slam dunk. The company faces serious obstacles in all directions, and it is not clear that they are ready to overcome them.

Let’s start with baggage. HDS is the exact opposite of a startup. This is an industry stalwart with a history of technology stronger than its sales execution; a private organization that must open up and change course without sinking; a company at once supported by and saddled with its link to “the mothership”, Hitachi Limited; and a group of talented people whose pride does not always serve their objectives.

The recent sale of Hitachi Global Storage Technologies (HGST), a key hard disk drive manufacturer, to Western Digital set some tongues wagging that HDS would be next. But HDS is nothing like HGST: Hitachi is first and foremost a developer and manufacturer of technological products, from televisions to nuclear reactors, and HDS is an integrator and distributor of their storage products. Hitachi could, in theory, decide to exit the storage space, and this would be the end of HDS. But this is highly unlikely. Hitachi is in the IT space for the long haul, with a slate of products that also includes servers and networking gear, and HDS is key to internationalizing this business.

But Hitachi is also an anchor, restricting the flexibility and creativity of HDS, and the curious case of Hitachi’s blade servers is a case in point. As noted, Hitachi is a major server vendor in Japan, and the company has named HDS the international custodian of these products. But HDS lacks the resources to sell into the highly-competitive server market. HDS has little choice but to put on a brave face and try to use these blade servers for their content platform, NAS, and unified “datacenter block” offerings, but there is no way they would have sought this product if not for Hitachi’s influence.

More pressing, however, is the challenge HDS faces with their sales force. Time and again one hears tales of clueless HDS sales reps pushing the same old SAN products to the same old customers rather than talking about HCP and the value of a strategic storage platform. One fellow event attendee remarked that his rep hadn’t ever mentioned HCP and HDI, even though it would have been a perfect fit for his large multi-national corporation. The rep either didn’t know about it or didn’t want to bother rocking the boat, and both are equally damning for HDS’ future growth.

One also senses a certain frustrated pride from some HDS employees, and this can be off-putting. This event was populated by some of the best and brightest representatives the company has to offer, but some continually resorted to a pointless “been there, done that, invented it” grouchiness. To hear them tell it, Hitachi is the secret force behind just about every enterprise storage innovation of the past two decades and their failure to dominate the market is a cruel injustice. But this is patently false: HDS is an innovator to be sure, but they play in a competitive market of equals. They must take responsibility for their own failings and work harder for success rather than whining about pretenders and upstarts.

Stephen’s Stance

As the baseball season begins, I can’t help but compare HDS to a big-budget team like the Chicago Cubs: They have all the tools and talent they need to succeed, but only time will tell how competitive they can be.
HDS should be commended for acquiring and developing the HCP technology, as well as spotting and fostering great new faces like Michael Heffernan, David Merrill, and Dave Wilson. But HDS must execute.

My prescription is simple but difficult: Lose the hubris and really dive into the battle for hearts and minds. Engage thought leaders and customers alike and show them how you can solve business problems rather than blathering on about unrecognized technical superiority. Educate the sales force and better incentivize them to “go strategic” instead of falling back on “speeds-and-feeds” SAN sales, and cut off anyone who isn’t on board. Let Heff and Wilson run free, find more like them, and bring Merrill into every CIO-level meeting.

HDS has to step up and be the healthy competitor for NetApp and EMC that the enterprise storage industry so desperately needs.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Concerning HDS
This post was categorized as Computer History, Enterprise storage, Everything, Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

• A special video message for NerdBlurt and #HDSday folks …
• Evolving vs. Arriving
• Cisco’s CleanAir vs the Atheros vendors
• MetaGeek – Gestalt IT Wireless Tech Field Day
• Hands on with the Metageek Wi-Spy DBx

Subscribe to my Google Reader feed or follow me on Twitter to see these in real-time.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Back From the Pile: Interesting Links, March 25, 2011
This post was categorized as Everything. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Note: This information was based on the “VMware Storage/SAN Compatibility Guide” and is being regularly updated. Please add comments here and I will add products and change and update listings as soon as they appear in the guide!

Where, Why, and What is VAAI?

I’ve previously discussed the fact that VMware’s excellent ESX hardware compatibility list (HCL) is so comprehensive than obscures basic facts about supported products. This is especially true for VAAI, since compatibility is only noted as a footnote in individual storage array listings. It does not help matters that not all VAAI plugins support all three capabilities.

Like my previous posts regarding FCoE CNA’s, SATA and PATA chipsets, and home/lab network cards, I’ll attempt to boil down the VMware ESX HCL into plain English. This data will also be part of my Storage for Virtual Servers seminar presentation, the first of which will be given on March 10 in Philadelphia.

I’m not going to spend too much time on “what is VAAI” in this post. Instead, I suggest you read the following blog posts and VMware’s excellent guide, “What’s New in VMware vSphereTM 4.1 — Storage“?

• What is VAAI, and how does it add spice to my life as a VMware admin?
• vStorage APIs for Array Integration aka VAAI
• If You Ever Needed Convincing About VAAI…
• VMware VAAI pros and cons and the hidden fourth primitive

The Three VAAI Primitives

You ought to read the updated Complete List of VMware VAAI Primitives since it’s much more thorough and informative!

In ESX 4.1, that vStorage API for Array Integration includes three basic capabilities or primitives:

1. Blocks zeroing is a communication method for thin provisioning capable storage arrays, allowing them to quickly zero out storage capacity for later reclamation.
2. Full copy commands the storage array to make a mirror or snapshot of data without any I/O on the server hardware.
3. Hardware assisted locking enables more granular control of shared storage resources in ESX clusters

In order to support VAAI, a storage array requires two things:

1. Hardware capable of supporting one or more of the three primitives listed above
2. A software plug in for ESX enabling communication and integration

VAAI Plug In Support

Creating a VAAI plug in is not a trivial task, and not all storage arrays are yet supported. I have heard grumbling from storage vendors that EMC (the storage vendor that owns VMware) has been given early access to VAAI information, allowing them to support this feature set before their competitors. However, this has not stopped a diverse set of other unrelated storage vendors from quickly producing and releasing effective and complete VAAI plugins.

As of this writing, there are 11 array-specific plugins and one general-purpose plug in available for ESX 4.1. EMC, NetApp, 3PAR (HP), HDS, FalconStor, Fujitsu, IBM, Dell (EqualLogic), and HP (LeftHand, P9000, P2000) have produced VAAI plugins supporting all three primitives. Additionally, a cloud in supporting the T10 blocks zeroing methods is available, enabling other arrays to support this one primitive. Note that the T10 primitive should support nearly any capable array, but not all have been tested and qualified for use with it.

VAAI Support Matrix

Note that similar OEM versions (for example, Fujitsu’s FibreCAT CLARiiONs, and the Gateway/Lenovo/Acer AMS line) are also supported the same as the manufacturer’s offerings. I’ve simplified and eliminated similar models (the Dell EqualLogic PS6000E, PS6000S, PS6000X, PS6000XV, and PS6000XVS are all listed simply as PS6000).

Updates:

• IBM recently added full VAAI for the XIV, SVC, and similar Storwize V7000. I’m sure they’re also working on complete VAAI plugins for the big DS8000 systems!
• EMC certified the new VNX line for VAAI (FC only for now) and the V-Max just gained iSCSI VAAI support.
• FalconStor added VAAI for NSS, enabling any storage array to be used.
• HP created VAAI plugins for the P9500 and MSA P2000 lines as well.

Stephen’s Stance

VAAI is an exciting new capability for VMware ESX, and demonstrates the enterprise readiness of vSphere 4.1. Although not all storage arrays are yet supported, the diverse assortment listed above should cover the majority of enterprise storage environments. I fully expect that the obvious holes will be filled in soon, and I look forward to updating this list when I hear news of those product releases. I also look forward to learning of additional capabilities added as VAAI primitives in the future!

The Exhaustive List

I am attempting to keep this list up to date. My authoritative source of information is the VMware Storage Compatibility Guide. This is the only source of information I will use, since only official and supported implementations belong in production. But I welcome pointers, suggestions, and referrals for updates!

This list is complete as of February 21, 2011

Full VAAI (All 3 primitives)

• Dell
  • EqualLogic
    • iSCSI (vmw_vaaip_eql)
      • Dell EqualLogic PS4000E (Dell EqualLogic PS4000X; Dell EqualLogic PS4000XV)
      • Dell EqualLogic PS5000E (Dell EqualLogic PS5000X; Dell EqualLogic PS5000XV)
      • Dell EqualLogic PS5500E
      • Dell EqualLogic PS6000E (Dell EqualLogic PS6000S; Dell EqualLogic PS6000V; Dell EqualLogic PS6000XV; Dell EqualLogic PS6000XVS)
      • Dell EqualLogic PS6010E (Dell EqualLogic PS6010S; Dell EqualLogic PS6010X; Dell EqualLogic PS6010XV; Dell EqualLogic PS6010XVS)
      • Dell EqualLogic PS6500E (Dell EqualLogic PS6500X)
      • Dell EqualLogic PS6510E (Dell EqualLogic PS6510X)
      • EqualLogic PS100E
      • EqualLogic PS200E
      • EqualLogic PS300E
      • EqualLogic PS3600X
      • EqualLogic PS3700X
      • EqualLogic PS3800XV
        • EqualLogic PS3900XV
      • EqualLogic PS400E
      • EqualLogic PS50E
      • EqualLogic PS70E
• EMC
  • FC (vmw_vaaip_cx)
    • EMC CLARiiON CX4-120 (EMC CLARiiON CX4-120 C8/C8X; Dell/EMC CLARiiON CX4-120; Fujitsu FibreCAT CX4-120)
    • EMC CLARiiON CX4-240 C8/C8X
    • EMC CLARiiON CX4-480 (EMC CLARiiON CX4-480 C8/C8X; Dell/EMC CLARiiON CX4-480)
    • EMC CLARiiON CX4-960 (EMC CLARiiON CX4-960 C8/C8X; Dell/EMC CLARiiON CX4-960)
    • EMC Celerra NS-120
    • EMC Celerra NS-480
    • EMC Celerra NS-960
    • EMC VNX5100
    • EMC VNX5300
    • EMC VNX5500
    • EMC VNX5700
    • EMC VNX7500
  • FC/iSCSI/FCoE (VMW_VAAI_SYMM)
    • EMC Symmetrix VMAX
  • iSCSI (vmw_vaaip_cx)
    • EMC Celerra CNS
    • EMC Celerra NS-120
    • EMC Celerra NS-480
    • EMC Celerra NS-960
    • EMC CLARiiON CX4-120 C8
    • EMC CLARiiON CX4-240 C8
    • EMC CLARiiON CX4-480 (EMC CLARiiON CX4-480 C8)
    • EMC CLARiiON CX4-960 (EMC CLARiiON CX4-960 C8)
• FalconStor
• FC (unknown)
• CDP Gateway
• CDP SA
• CDP VS
• CDPx Gateway
• IPStor Enterprise
• NSS Gateway
• NSS SA
• NSS VS
• Fujitsu
  • FC (fjt_vaaip_module)
    • Fujitsu Eternus DX410
    • Fujitsu Eternus DX440
    • Fujitsu Eternus DX8100
    • Fujitsu Eternus DX8400
    • Fujitsu Eternus DX8700
  • iSCSI (fjt_vaaip_module)
    • Fujitsu Eternus DX410
    • Fujitsu Eternus DX440
    • Fujitsu Eternus DX8100
    • Fujitsu Eternus DX8400
    • Fujitsu Eternus DX8700
• Hitachi
  • FC (vmw_vaaip_hds)
    • Hitachi AMS 2100 (Acer AMS2100; Gateway AMS2100; HDS AMS 2100; Lenovo-HDS AMS2100)
    • Hitachi AMS 2300 (Acer AMS2300; Gateway AMS2300; HDS AMS 2300; Lenovo-HDS AMS2300)
    • Hitachi AMS 2500 (HDS AMS 2500)
    • Acer AS2040; Gateway GS2040
    • Hitachi AMS 2010
    • Hitachi BR1600/BR1600E/BR1600S
    • Hitachi Virtual Storage Platform (Hitachi VP9500; HP StorageWorks P9500)
    • Nihon-Unisys Sanarena 1910
    • Nihon-Unisys Sanarena 1930
    • Nihon-Unisys Sanarena 1970
    • Nihon-Unisys Sanarena 1990
  • iSCSI (vmw_vaaip_hds)
    • Hitachi AMS 2010
    • Hitachi AMS 2100 (HDS AMS 2100; Lenovo-HDS AMS2100)
    • Hitachi AMS 2300 (HDS AMS 2300; Lenovo-HDS AMS2300)
    • Hitachi AMS 2500 (HDS AMS 2500)
    • Hitachi BR1600E
    • Nihon-Unisys Sanarena 1930
    • Nihon-Unisys Sanarena 1970
    • Nihon-Unisys Sanarena 1990
    • Hitachi Virtual Storage Platform
• HP
  • 3PAR
    • FC (3PAR_vaaip_InServ)
      • InServ E200
      • InServ F-Class
      • InServ S400
      • InServ S800
      • T-Class
    • iSCSI (3PAR_vaaip_InServ)
      • InServ E200
      • InServ F-Class
      • InServ S400
      • InServ S800
      • T-Class
  • P9500
  • FC (hp-vaaip-p9000)
  • HP P9500
  • P2000
  • FC/iSCSI (hp-vaaip-p2000)
  • HP MSA P2000
  • LeftHand
    • iSCSI (vmw_vaaip_lhn)
      • HP LeftHand P4500
      • HP LeftHand P4000 VSA
      • HP LeftHand P4000sb
      • HP LeftHand P4300 (HP LeftHand P4300 G2)
      • HP LeftHand P4500 (HP LeftHand P4500 G2)
      • HP LeftHand P4800
      • HP ProLiant DL380
      • Dell 2950
      • IBM x3650
      • LeftHand NSM 160
      • LeftHand NSM 185
      • LeftHand NSM 2060 (LeftHand NSM 2060 G2)
      • LeftHand NSM 2120 (LeftHand NSM 2120 G2)
      • LeftHand NSM 260
      • LeftHand NSM 320
      • LeftHand NSM 326
      • LeftHand NSM 3650
      • LeftHand NSM 380
      • LeftHand NSM 4150
      • LeftHand VSA
• IBM
  • FC/iSCSI (IBM_VAAIP_MODULE)
    • IBM XIV
    • IBM SVC
    • IBM V7000
    • Fujitsu VS850
    • Actifio
• NetApp
  • FC (VMW_VAAIP_NETAPP)
    • NetApp N3000 Series
    • NetApp N5000 Series
    • NetApp N6000 Series
    • NetApp N7000 Series
    • NetApp FAS2000 Series
    • NetApp FAS3000 Series
    • NetApp FAS3100 Series
    • NetApp FAS3200 Series
    • NetApp FAS6000 Series
    • NetApp FAS6200 Series
  • FCoE (VMW_VAAIP_NETAPP)
    • NetApp FAS3000 Series
    • NetApp FAS3100 Series
    • NetApp FAS3200 Series
    • NetApp FAS6000 Series
    • NetApp FAS6200 Series
  • iSCSI (VMW_VAAIP_NETAPP)
    • NetApp N3000 Series
    • NetApp N5000 Series
    • NetApp N6000 Series
    • NetApp N7000 Series
    • NetApp FAS2000 Series (Fujitsu Eternus NR1000F Series Model F2040)
    • NetApp FAS3000 Series
    • NetApp FAS3100 Series (Fujitsu Eternus NR1000F Series Model F3160)
    • NetApp FAS3200 Series
    • NetApp FAS6000 Series
    • NetApp FAS6200 Series

T10 Block Zero Only

• Bull
  • FC (vmw_vaaip_t10)
    • Bull Optima2000
  • iSCSI (vmw_vaaip_t10)
    • Bull Optima2000c
    • Bull Optima2000i
• NEC
  • FC (vmw_vaaip_t10)
    • NEC iStorage D3-30
    • NEC iStorage D4-30
  • iSCSI (vmw_vaaip_t10)
    • NEC iStorage D3-30/D3-30i
    • NEC iStorage D4-30/D4-30i
• Fujitsu
  • iSCSI (vmw_vaaip_t10)
    • Fujitsu Eternus VS850
• IBM
  • iSCSI (vmw_vaaip_t10)
    • IBM Storwize V7000
    • IBM SVC

© sfoskett for Stephen Foskett, Pack Rat, 2011. | VMware VAAI Storage Array Support in Plain English
This post was categorized as Enterprise storage, Everything, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Although I consider it the main stumbling block for thin provisioning, communication (or lack thereof) is being addressed with metadata monitoring, WRITE_SAME, the Veritas Thin API, and other ideas. But communication isn’t the only issue.

Let’s talk about page sizes. You’ll often see vendors tossing this “softball” objection at their competitors, claiming that their (smaller) page size makes for more-effective thin provisioning. And that’s true, to a some extent, but perhaps not the end of the story.

Look at the top block in this stack. The light background box is the page, and the colored boxes represent data. If your storage is written in “pages” of this size, you can’t thin it.

What if we used a smaller page? What if my page is a quarter of that size, as in the second row? I still can’t thin it out, because my data is spread all over the place.

Remember worrying about fragmentation back in the days of DOS and Windows and FAT filesystems? It’s kind of like this.

Because we’re using zero page reclaim, the whole page has to be zero to be reclaimed. If your data is all over the place, if there’s even one bit that’s not zero on a page, we’re not going to reclaim that whole page.

Now let’s return to our illustration. If we use a little bit smaller page, as in the bottom two rows, we can reclaim some space. If we use a really tiny page, we can reclaim half the space even.

We’re still not reclaiming all the space, though. At the beginning of this series, I showed the “simplified perfect-world” thin provisioning illustration. In that picture, the half-empty barrel was perfectly reclaimed thanks to this technology. We will never get there unless we are using really minuscule pages. But we can get somewhat close. Maybe we can thin out three-quarters of the empty space.

But some vendors use really big pages. Some folks made fun of Hitachi for using 42 megabyte pages, since, if there’s one bit in 42 megabytes of potential ones or zeros, the Hitachi will not thin that. It also won’t migrate it for automated storage tiering. But others use even-bigger pages; up to a gigabyte in size. And 42 MB isn’t that bad in practice.

I know of a company that’s doing four-kilobyte pages. And EMC actually allocates one-gigabyte slices of storage for writing on the CLARiiON, even though their thin size is 8 KB. So is the CLARiiON page size 8 KB or 1 GB? It’s very confusing to me (and probably the customer too)…

The trouble with 4 K or 8 K pages is it makes an awful lot of pages to keep track of. Consider the analogy of hard disk drive sector sizes. An ATA disk could only get to 2.1 terabytes until recently, because they still used 512-byte sectors. And 512 bytes times the biggest 32-bit number is 2048 GB. So 512 bytes makes for greater efficiency in theory, but hurts scalability in practice. So, the disk drive industry is moving to 4 K sectors.

It’s exactly the same thing as with thin provisioning. So, you’ve got to keep track of all these gazillions and gazillions of pages. So, from a vendor perspective, you can save a lot of horsepower and make it a lot easier to implement if you have bigger pages. It also means you’re not moving stuff around as much when using these big pages for automated tiering.

I’m not going to throw rocks at HDS or anyone else over page sizes. I actually don’t think 42 MB is that bad, because the biggest problem with underutilization is not inside a file system. In my experience, the big problem is storage that’s not used at all.

When I used to do storage assessments, it was very common to find LUNs that were allocated ant not used at all; not even touched. Your page size doesn’t matter if a LUN is not even touched: It’s going to be thinned out no matter what. So, regardless of the page size, thin provisioning will probably save more space outside a filesystem than within one, especially if your systems administrators are doing a reasonably good job of storage management. And even if they’re not doing a good job, there’s probably 42 megs of zeros that can be thinned out anyway.

So, I’m not as worried about the size of the pages. Granularity is an architectural decision, and larger pages are not the end of the world. Ask your vendor if they support thin provisioning and what the granularity or page size is, and think about how that’s going to affect you. At the end of the day, it’s probably going to yield about the same result no matter what the page size is.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Granularity of Thin Provisioning Approaches
This post was categorized as Computer History, Enterprise storage, Everything, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

If WRITE_SAME can be a semaphore for thin un-provisioning, what about TRIM? It sounds like a perfect fit, and has wider implementation to boot! Let’s take a deeper look.

First, I’d like to remind the reader that I’m not some specialist storage engineer. I am regular guy who wanted to know about this TRIM thing. I welcome corrections and feedback on this piece!

We should note that TRIM was invented for SSDs, not thin provisioning. TRIM lets an operating system tell a storage device that certain blocks of data are no longer used. Although this sounds like a thin provisioning tool, it’s not. TRIM was never intended to be used this way.

Even though Microsoft supports TRIM in the file system, and even though, hopefully, Apple will introduce TRIM support in OS X Lion, this doesn’t do what we need it to do for thin provisioning. In fact, TRIM is not anything for enterprise storage folks to be getting all that excited about.

One reason for is is that TRIM is an ATA command, and most enterprise systems are not connected to their storage using any kind of ATA-based protocol. Maybe there are SATA disks somewhere down the line, but, whether they use iSCSI, FC, SAS, or FCoE, the servers speak SCSI.

Even though there are SCSI analogs of of TRIM, these commands were really not designed for thin provisioning. They are designed for SSDs, which have a big performance problem: An SSD can delete data and write data just fine, but in order to update data, they actually have to read, delete, and write a big page of data. What happen is that, as an SSD gets full, it starts slowing down. And that’s a problem because people buy SSDs for speed. So TRIM is a way to tell the SSD, “Sometime in the future, you can go ahead and delete this if you feel like it,” and the SSD will take care of that later.

There’s great OS support for this, but unfortunately, this is not something that enterprise storage vendors are looking at. The only vendor (that I know of) that’s working on this, NetApp, did propose to T10 a mechanism to do thin provisioning based on TRIM. I don’t think it got anywhere. They say that it did, but I just don’t see it. HDS and EMC, seem to like UNMAP and SCSI, which are peripherally related, but I don’t know much about what they’re doing either. Perhaps they’ll let me know in comments on this post.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Is TRIM Useful For Thin Provisioning?
This post was categorized as Apple, Enterprise storage, Everything, Terabyte home, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Get used to it: Commodity hardware like this Super Micro SBB server will dominate enterprise storage

The history of technology moves in fits and starts, but one trend trumps all else: An inevitable shift from fine-tuned specialized gear to general-purpose commodity building blocks. We see it in both hardware and software, and at all levels of the industry, from chips and wafers to operating systems and networking devices. Take a step back and you’ll certainly agree: Commodity hardware always wins (eventually).

Doing the Impossible

Building something new often requires amazing feats of engineering. Steve Wozniak’s hardware wizardry with the original Apple computer is now legend, but similar tales are found everywhere.

It’s frightfully difficult to do the impossible without at least some wizardry. Most new technologies are therefore built on specialized hardware and hand-tuned software. Engineers at the forefront of technology must eke out every ounce of performance from trailing technologies.

This is why we see so many special-purpose processors in high-performance devices, and why companies employing custom ASICs often enjoy a performance advantage. In enterprise storage, we look to companies like HDS and BlueArc who packed their arrays with special-purpose hardware, pointing the way to the future. We also see impressive developments from Fusion IO and SandForce in the SSD space, leading to the next generation of storage.

Can You Keep Ahead Of Intel?

Just about every technology sector progresses from the impossible to the commonplace, and these changes are often very quick. High-performance storage systems were once exotic multi-million dollar devices but millions of IOPS are now available for under $100k from dozens of vendors.

This progression typically includes a move from special-purpose to commodity underpinnings. Exotic real-time operating systems have been pushed aside in favor of Linux, BSD, and even Windows, while ASICs and FPGAs give way to Intel’s CPU juggernaut. Even Apple computers are today almost entirely commodity PCs.

I love how Denton Gentry phrases this in his Monday blog entry about Intel and Achronix:

“Once you commit to a specialized hardware design, the clock starts ticking. There will come a day when a software implementation could meet the requirements, and at that point the FPGA becomes an expensive liability in the BOM cost. You have to make enough profit from the hardware offload product to pay for its own design, plus a redesign in software, or the whole exercise turns out to be a waste of money.”

In other words, specialized software on proprietary hardware will eventually be overtaken by general-purpose software on commodity hardware. The decision must include not just what one can do today but what that baggage will mean in the future. Designing a system around proprietary components might look good now, but the next-generation product will be put at risk by this decision.

Stephen’s Stance

My opinion is right there in the title of this piece: Commodity hardware always wins. No matter how great your ASIC is, industry-standard CPUs will out-perform it sooner or later. No matter how much effort you put into tuning your software, Linux-based systems will eventually do just as well.

The rise of commodity hardware is everywhere: EMC, HDS, IBM, Oracle, and HP have all embraced Intel CPUs and their hardware is looking more and more like Intel’s reference designs, too. Startups are increasingly relying on software rather than hardware for their differentiation, and we’re seeing Supermicro servers shipped with just about everyone’s name on them. The Storage Bridge Bay specification is looking better all the time, too. Commodity hardware is winning in storage, just like it always does.

For more on this topic, see these related posts by others:

• The World Has Changed – Is Hardware Getting Softer?
• Commodity hardware always loses
• Storage is software
• Better storage through hardware

© sfoskett for Stephen Foskett, Pack Rat, 2010. | Commodity Hardware Always Wins
This post was categorized as Computer History, Enterprise storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.