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:

1. 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.
2. 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.

1. It eliminates the likelihood of hot spots.
2. 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.
3. 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.