EMC

This coming Thursday, April 26, I’ll be participating in an EMC webinar titled “Best Practices: When and How to Use Stretched Clusters.” (I wanted to title it as “Current Recommended Practices,” but the marketing group shot me down.) The webinar starts at 8 AM PT/9 AM MT/11 AM ET.

This webinar will discuss whether stretched clusters or a solution like VMware Site Recovery Manager is a better fit for your needs, as well as provide some guidelines around the use of stretched clusters as of vSphere 5.0.

If you’re interested in registering for the webinar, visit the registration page and sign up. Thanks!

As you might have already seen (Chad broke the news here, Itzik has more details here), EMC has released version 5.1 of the Virtual Storage Integrator (VSI), the vCenter plugin available to customers at no additional charge. I won’t revisit all the new features; rather, I wanted to bring to your attention a late-discovered issue with the VSI 5.1 release. If this information hasn’t already made it into the Release Notes, it should be there soon (there’s also an EMC Primus case being created).

Here’s the lowdown: there’s an issue with VSI Storage Viewer 5.1 that prevents it from properly upgrading previous versions of VSI. After an upgrade to Storage Viewer 5.1, the user may encounter an error like “Unable to load DLL ‘SEWrapper.dll’: The specified module could not be found” (or similar).

The problem isn’t in SEWrapper.dll, which is working properly and is, in fact, installed on the system. The problem is in the Microsoft Visual C++ 2010 Redistributable Package (x86) isn’t installed, and that’s a pre-requisite for the SEWrapper.dll library.

There are two workarounds for this issue:

1. Remove VSI Storage Viewer 5.1 and re-install it from scratch. This will cause the Visual C++ redistributables to get installed correctly, fixing the problem. Note: If you have older VSI features installed—like Storage Pool Management 5.0 or Path Management 5.0—reinstall those after Storage Viewer 5.1 is installed.

2. Download and install the Microsoft Visual C++ 2010 Redistributable Package (x86) separately. You should be able to download that here.

This will be in the Release Notes very soon (if not already), but I wanted to highlight the problem—and the fixes—here just in case.

You might wonder what fate and free will have to do with virtualization and storage. The title of this post is a reference to the debate of Fate vs. Free Will, which in turn is a reference to Stephen Foskett’s recent post VMware as Oedipus: How Server Virtualization will Change Storage Forever. I won’t provide all the details here (go read the post), but the basic idea behind the post is that VMware’s drive to add storage features to the virtualization stack puts it on a collision course with EMC, a leading storage vendor. The twist here is the fact that EMC has a majority ownership in VMware, thereby earning EMC the term “parent company” and creating the Oedipal conflict to which Stephen alludes in his post.

First, let me sum up Stephen’s points:

1. VMware is causing users not to purchase storage arrays.
2. VMware integration is “leveling” the playing field.

Let’s take a look at each of these points.

A Decrease in Shared Storage?

Stephen makes this statement in his article (emphasis his):

VMware is rapidly innovating in this area. Integrating and developing snapshot, replication, thin provisioning, and other features in VMFS enables everyone to have advanced storage functionality, regardless of which storage device they use. In this way, VMware is already causing many users to forego an enterprise storage array purchase.

Perhaps it’s the specific term “enterprise storage array,” but I have a hard time believing that the adoption of VMware is causing users to forgo array purchases. Think about it: to even use many of the advanced features of vSphere like vSphere HA, vSphere DRS, or vSphere FT, shared storage is a prerequisite. Users literally cannot use these features without shared storage, and—today, at least—shared storage in almost all cases means an array.

If, however, the statement is intended to say that VMware users are buying less feature-rich arrays because of the features being added into vSphere—features like snapshots, replication, and thin provisioning—then I suppose I can see that. This is why array vendors are (or should be) driving innovation in other areas, such as dynamic auto-tiering, more robust snapshotting functionality, higher availability, and higher levels of performance.

Additionally, this is an opportunity for both virtualization experts and storage experts to help customers understand the differences between the features provided by the hypervisor and features provided at the storage layer. While these features share names, they can be very different! Here are a couple specific examples:

• VMware’s snapshots are fundamentally and dramatically different from the snapshot features offered by many storage vendors. Not only are they different in how they work, they are also different in their uses and usage patterns. Storage administrators use array-based snapshots for different purposes and in different ways than vSphere administrators use snapshots.
• vSphere’s replication functionality is a nice “check box” item, but lacks many of the features that array-based replication offers. For example, there’s no compression, no deduplication or WAN optimization, and no idea of consistency groups.

As you can see, while it’s true that VMware is offering features that are similar in name and purpose, these features often are not true competitors to the features that storage array vendors offer, EMC included. Looking ahead, I anticipate that will continue to be the case, and storage vendors will continue to have ample opportunities to offer functionality above and beyond what the hypervisor can or will offer.

Homogenization of Storage?

The second point of the article is the assertion that “ever tighter integration serves to anonymize and homogenize enterprise storage devices.” I don’t agree here, for a couple of reasons:

1. This statement assumes that all integration is the same, which is not the case. One vendor’s level and type of integration with VMware can be very different than another vendor’s level and type of integration. A vCenter plug-in is not the end of the story. What about integration with your replication solution? What about integration with your snapshot functionality? What about the quality of your VAAI implementation? One vendor’s implementation of VAAI might behave quite differently than another vendor’s implementation. What about your support of VMware’s multipathing APIs? I could go on and on, but you get the idea.
2. This statement excludes the value of innovation in other areas, implying that VMware integration is the sole factor that levels the playing field. As I’ve stated on many occasions, every storage solutions has its advantages and disadvantages. The way that EMC does things gives it an advantage over NetApp in some areas; at the same time, the way that NetApp does things gives it an advantage over EMC in other areas. If all arrays were the same and were measured only on their VMware integration, then I could see this statement. That’s not the case. And even if it were, then as I’ve just shown you, VMware integration can take many forms and many levels. Despite ever increasing levels of integration, vendors still have plenty of opportunities to differentiate themselves from other vendors through price, performance, data protection, scalability, reliability, and availability.

Conclusion

I don’t disagree that VMware will change the nature of enterprise storage; in fact, I would argue that it already has changed enterprise storage. But to say that VMware will completely anonymize and homogenize enterprise storage is, in my humble opinion, a bit of a reach. There are still plenty of areas in which storage vendors can innovate and differentiate, both in addition to as well as in spite of VMware’s own storage-related ambitions.

Disclaimer: It’s probably well-known anyway, but it’s important to state that I do work for a storage vendor (EMC), although—as my site-wide disclaimer indicates—content here is not sponsored by, reviewed by, or even approved by my employer.