Around the Storage Block Blog : virtualization, EMC

EVA Simplicity Challenge

CalvinZ — Fri, 24 Apr 2009 22:05:00 GMT

Back in early March, I talked about our storage virtualization announcement and pointed you to a video we did on the EVA. Well, I think I finally figured out how to embedded video in the blog (at least from YouTube), so I wanted to mention it it again and embedded the video. But first, here's a bit about the video.

Last year when we announced the EVA4400, we were just wrapping up some work with the Edison Group where we measured the time it took to perform specific storage administrative tasks on an EVA, Clariion CX, and NetApp FAS array. As a follow-up to the EVA4400 announcement, we brought some IT administrators to HP and asked them to perform a number of tasks on an EVA and Clariion array. The video was pretty good and was well received. So as we were getting ready to announce the EVA6400 and EVA8400 this year, we wanted to do another video to show just how easy the EVA with it's unique virtualization is to manage compared to competitive traditional arrays.

My original idea was to use either high school or college students; we'd have two groups - one a few football players and the other students taking high-tech classes. I was very confident that if we asked the football players to configure the EVA's and the tech students to work on the competitve arrays, the EVA would win hands down. A few folks on my team thought this could be a bit offensive, suggesting you really don't have to be educated to be an IT administrator. I saw it very differently - if HP StorageWorks can make products that simplify the time it takes to administrate their storage, that's really what our customers need - make it simple! I think the idea we used works just as well - we had three teams of high school students who each were asked to perform the same tasks on an EVA, Clariion CX4, and NetApp FAS array. As you'll see in the video, it appears as though the NetApp results are close but this is a bit misleading as we had to tell the students to skip some tasks on the FAS because no one could figure out how to do them.

With that background, there's the video:

(Please visit the site to view this media)

Come on - is the EVA really that easy to manage?

CalvinZ — Fri, 13 Mar 2009 20:31:00 GMT

By Calvin Zito

As I mentioned in my post titled Storage virtualization and the new EVA, the StorageWorks EVA is proving itself to be far easier to manage than competitive traditional disk arrays. Let me give you some of the back story here.

Last year, we commissioned an analyst team (The Edison Group) to measure the steps, clicks, and time it took to perform the most common array administrative tasks on several midrange arrays. They wrote a paper about those findings called "TCO White Paper: EMC, NetApp, and HP Midrange Storage Arrays". To be blunt, the paper never really measured TCO and in the end I thought it was the wrong title but it was still a good thing to see the time savings that we get with the EVA versus other arrays.

As I discussed in my post titled "Must See TV: EVA, EMC, and NetApp Go Head to Head" we brought customers to Houston to run some testing for us. You can find the video in the Must See TV post but there was also a white paper titled "Competitive Testing of Common Administrative Tasks" that gave more details on what happened through that testing. Again, interesting but still didn't give me what I wanted to see - how much can a customer save.

Fast forward to pulling together our announcement for the new EVA6400 and EVA8400. The thought was to do a survey of storage administrators on how they spend their day - meaning how often do they perform these different administrative tasks on their storage arrays. It seemed to me that if we had that data, we could then get to a time or cost savings when managing an EVA. This approach hit paydirt! Because the Edison Group had done the original testing, we turned to them again to survey administrators and calculate the savings. The paper based on this research is called "Comparative Management Cost Survey" Let me briefing summarize the results:

The total workday savings of an organization using an EVA as compared to EMC is 36 percent. When compared to NetApp, the savings are 50 percent. Workday savings is a term Edison uses to describe the value of an employee's daily work averaged over a year.

So when you hear us say the EVA costs up to 50% less to manage than other competitive traditional disk arrays, you know now why we can confidently say that. If you aren't using EVA's today, can you really afford to spend 2X managing the other guys' arrays, especially in today's economy?

One last point - I'm sure the competition will try to come up with 30 different reasons why our conclusions are wrong. EMC already tried to debunk the original Edison report by having an EMC engineer perform the same tasks on a Clariion and time the results they got. Well, duh! If I have an EVA engineer do the same tasks that Edison did I'm sure they'd complete them faster too. I would love to put all of these products to a joint test - have the best and brighest engineers from each company perform these tasks on their own storage array and everyone posts the results to their website. Somehow I don't get the sense that this is a challenge that either EMC or NetApp will want to touch.

Have a great weekend!

Must see TV: EVA, EMC, and NetApp go head to head

CalvinZ — Fri, 13 Mar 2009 04:03:00 GMT

By Calvin Zito

Last year when we announced the EVA4400, we brought some customers and partners to Houston who were not familiar with the management of either the EVA or EMC Clariion CX array. We gave them a list of tasks to complete and then created a video of that. It was one of the most popular videos of the last year on hp.com. The test showed that for the tasks these customers were asked to accomplish, they clearly thought the EVA was far easier to manage.

As we were preparing to announce the EVA6400 and EVA8400, we wanted to create an interesting video that would again make the point of how easy the EVA is to manage compared to competitive disk arrays. So the idea that we came up with was to have some high school students who are taking technical classes at their local high school (e.i. technology saavy) but not SAN or disk array experts put the EVA and competitive arrays to the test. The result is the HP StorageWorks EVA Simplicity Challenge. I don't want to spoil the fun for you but I'll make one comment about the results - the only reason the NetApp FAS system was even close was because no one could figure out how to do a snapshot on the NetApp system. So while the results look close, I personally thought we should have elimimated them from the results all together but we decided to keep their results in the video and note that doing the snapshots was beyond the scope of the test (in other words, was way too hard to figure out).

By the way, I wonder if my EMC blogger buddies have noticed that the EVA now has SSD drives - about a year a sooner than they predicted because to paraphrase their point of view, HP is a server company and can't innovate in storage. Of course, EMC doesn't have a virtualized storage array so what else can they say!

Storage Capacity Efficiency - Not Quite So Final

Anonymous — Wed, 03 Sep 2008 20:57:00 GMT

By Craig Simpson

EMC's Chuck Hollis recently posted quite a blog stream on storage capacity efficiency. His latest post concluded "it's time to step back a bit from the fray." It is quite a fray. But, my step back to look at the big picture uncovered some different thoughts from Chuck's. He started this with a case where a chosen interpretation of best practices could make CX look better than EVA. Of course, if one levels the playing field by letting EMC configure the CX (like Chuck did) and HP configure the EVA they both come out around 70% efficiency. I appreciate that EMC recognized some of our points. Here’s the rest.

However, since turnabout is fair play, I wondered if I could cook up a case to make EVA look lots better than CX. Sure enough. Put both a performance intensive workload (3000 IOPS, 1TB) and a non-performance intensive workload (300 IOPS, 1TB) on the array. The performance intensive workload uses RAID1 while the other uses RAID 5. Seems a reasonable mix of uses for an array. The EVA uses 30 disks compared to CX’s 41 making it 37% more efficient because CX can’t have RAID 1 and RAID 5 in the same RAID set. Now EMC could open the arguments about how their workload is better or I’m misusing their array or …

But the point is that anybody can find a way to make their array look good. EMC, why did you use RAID5 for “Exchange” when you recommend RAID 1? Digging into the numbers shows it was important to making your array look good. If you really want to show a meaningful comparison let’s agree on a third party to define and do the comparison. Let’s make it a challenge. Loser pays and we both put it on our websites. I know we can get plenty of volunteers to run it. But if you don’t, then this was just a colorful marketing show proving anybody can make their array look good.

EVA Disk Groups: The Fewer the Better

Anonymous — Wed, 03 Sep 2008 20:12:00 GMT

EMC, in a recent blog on array capacity efficiency, admittedly included some inaccuracies about the EVA. They've said they'll rerun their EVA tests and expect more favorable results. Good enough on that point. But they continue to think that EVA users wanting to run multiple applications are encouraged to use multiple disk groups. We've said it before and we'll say it again. NO! EVA users are encouraged to configure as few disk groups as possible. EMC makes claims about HP's product related to performance and availability isolation. EVA customers know that this isn't a concern (and we'll review that in just a minute). And with all due respect, we think we are the experts at configuring and developing best practices for the EVA. We'd politely suggest that EMC should stick to doing the same for their products.

Before we dive into EMC's claims about the EVA, a couple of points to note:

An EVA properly configured to service a set of high demand applications with a few appropriately sized disk groups doesn't experience the issues that Chuck mentions. The EVA also provides a much more cost-effective solution than traditional arrays that use "LUN" groups. This greater cost effectiveness results from reduced management and performance tuning overhead combined with excellent capacity efficiency; the EVA does not suffer from a traditional array's built-in inefficiency coming from the effort required to get several small "LUN" groups and spindle counts to match both capacity and performance requirements. In fact, such a manual process applied to traditional LUN groups typically trades off capacity efficiency for performance or vice versa.

EVA solves this dilemma by spreading all of the data across all the disks in a disk group and allowing the mixture of VRAID types on the same spindles. This simplifies the problem of simultaneously meeting performance and capacity requirements across the same set of spindles while providing greater capacity savings than mentioned in the EMC blog.

Now for the details. EMC talks about the concept of "performance isolation", e.g. minimizing contention between demanding applications. In a traditional array, this concept creates the problem that each small LUN group has to satisfy the maximum performance requirements of the application, even if that maximum performance is sustained only a fraction of the time. This, when combined with the limited set of disk sizes available, often results in over-provisioning of capacity, leading to wasted/stranded capacity.

Another issue that can result from using several LUN groups on a traditional array is that it increases the likelihood of hotspots. By using a few large disk groups enabled by EVA virtualization, occurrences of hotspots become virtually unknown.

EMC admits that EVA's approach of creating fewer disk groups offers greater performance. But that the array needs enough spindles. HP provides sizing tools that help our customers and partners KNOW that they have enough spindles to satisfy their requirements. And the EVA architecture allows for the simple insertion of more disks to increase the size of the disk group if (or when) requirements change over time.

Chuck goes on in his blog to tell EVA users that "if you plan to load up your EVA with several performance-intensive applications, and you don't want them stepping on each other, there's a case that can be made (unofficially confirmed) that you'll want more than the 1 or 2 disk groups that HP is offering up." Again, we believe that HP is in a better position to make best practice recommendation to our users. And our message is consistent with the other responses Chuck's heard from the HP community. Generally a large disk group will service all of the applications more effectively when considering the combined goals of performance and capacity efficiency. This results from the ability of a large disk group with more spindles to be able to adapt to the variable demand of all the applications while simultaneously being able to provide better system throughput and response times.

One more inaccuracy. Chuck claims that if a disk fails in an EVA (configured with a single disk group) that every application can have a problem and need to be recovered. This is true of any array. The CX and other traditional arrays have the same problem if they are unable to recover a failed disk. This was one of the reasons for the introduction of RAID technology in the first place and why the EVA is designed to ensure that it will recover the failed disk as long as the data is not stored in RAID 0. (Note: the exception for RAID 0 applies to ANY array.)

Finally, Chuck specifically asks "What are the recommended number of disk groups for an EVA with 120 usable disks where the customer has 6 or 7 demanding applications, and desires a significant degree of performance isolation and availability isolation?" Thanks for asking! Our answer is simple. A single large disk group would be best. If the separation of logs is a requirement, a user could create a large disk group for applications and a small disk group for logs.

Now let's summarize. EVA virtualization and its ability to use a few large disk groups solve several problems created by traditional arrays using several small LUN groups.

It eliminates the likelihood of hot spots.

It significantly improves capacity efficiency by eliminating the primary cause of capacity inefficiency in traditional arrays, which is using several small LUN groups. It does this by solving the problem of providing enough spindles for performance, while at the same time eliminating the stranding of storage in LUN groups sized for performance efficiency and not capacity efficiency.

EVA provides a simpler/cost effective performance tuning/management model that ends up being substantially more capacity efficient, while providing better throughput and response times for multiple high demand applications. The EVA does this by providing an architecture the meets these demands via larger/fewer disk groups as opposed to traditional arrays that chop up their resources and capabilities due to the need to carve an array up into several small LUN groups.

The result is efficient use of capacity and array performance that is substantially easier to manage than a traditional array.

Storage Just got SASsy! VMware set free of the SAN.

jasontreu — Tue, 22 Jul 2008 02:24:00 GMT

By Lee Johns, director of marketing, StorageWorks Entry Storage and Storage Blades, HP

Serial Attached SCSI (SAS). Does not sound very exciting really does it? Many of you will know SAS as a class of disk drives found in servers and arrays but how many have ever though of using SAS as an interconnect for storage instead of Fibre Channel or iSCSI? Probably not many and with good reason. SAS is a point to point protocal that can not compete today with the sophistication of network storage toploogies like Fibre Channel and iSCSI for Enterprise Arrays.

But what if you just want to deliver a simple solution for shared boot, or a VMware infrastructure that enables Vmotion without a SAN, or you have an application that performs best with a direct attached storage architecture but you want better storage utilization. Now the cost and complexity of a SAN seems somewhat redundant. Why is there no way to provide the performance you need with the consolidation and utilization of a SAN without the overhead of an expensive fibre channel network infrastructure or leaving things as they are with existing direct attached storage (DAS)?

There is an answer. It is using SAS as a shared storage interconnect and with it you can build much simpler shared storage environments that can be managed by a server administrator. This saves you time, money and enables you to build the best architecture for any application. It is not a replacement for the traditional SAN but it is an enhancement to DAS that places the data and control where it should be and does not force fit a SAN as the answer to all storage problems.

Shared SAS solutions are available today and I encourage you to think where they could help you improve your Direct Attached Storage architectures and augment the SAN. SAS began as an internal server interconnect so maybe it is no surprise that dedicated storage vendors like EMC and NetApp are ignoring SAS as an interconnect. They feel it is threatening to them and that is exactly why you should be taking a serious look!