By Warren Smith, HP StorageWorks

In an all too familiar world, we are compelled to report that the information in Chuck's blog on capacity efficiency is a distortion as far as the EVA is concerned. Read Chuck's blog post 

That this is a distortion, we are certain and details are provided below for the readers to evaluate for themselves.  But we wonder if Chuck and his team of EMC testing engineers, in a rush to post this, have not allowed their own ambition to deliberately ignore HP EVA technical guidance, or inadvertently done so.  In either case, you will find details below why we think that Chuck should have used the long weekend to re-consider the facts, before dashing off this blog.

Real story about EVA Usable Capacity

The best place to start a response to Chuck Hollis is to say that the EVA configuration cited in EMC's "fair comparison" test is a radical departure from published EVA best practices that can be found by clicking here.

Major points from these EVA best practices that undermine EMC's "fair comparison" test are:

CONCISE SUMMARY:  If EMC had followed HP's best practices for EVA, they would have configured this as a 2 disk group, rather than deciding to use 7 disk groups for this example.   The 2 disk groups would have consisted of 1 large disk group for Exchange data and 1 small disk group for logs.   Using 146GB drives example, then we would actually set aside the equivalent of 2 146GB drives for the single level of redundancy.  This is regardless of VRAID1 or VRAID5.  If EMC had followed this one single adherence to the EVA best practices, the resulting capacity rate shoots up dramatically to 74.73% capacity efficient with vRAID 5. 

For those with a taste for the details, the following bullets parse out how EMC got it wrong with the EVA Capacity Efficiency description and calculations.  But we add here that EMC and Chuck himself formerly whined about how NetApp had evaluated one their systems prejudicially by picking a configuration that would deliberately weaken the EMC system performance in the comparison.  We think that Chuck should practice what he preaches, because that is exactly what EMC has done in this comparison with the EVA, ie. ignored the EVA best practices guidance and implemented a worst case configuration.  Or maybe this was just an oversight by Chuck.

Disk Groups.  There is an assumption in Chuck's analysis that since Microsoft Exchange recommends separating Data and Logs into different EVA disk groups that every application's data must be separated.  We believe that is what led him to using the 7 disk groups with EVA choice, and he simply added up the number of data volumes needed for the "application example" he chose and said 1 per disk group.  The reality is that the separation is not for performance reasons but for some perceived data protection issues.  Microsoft Exchange relies on the Log files to protect and recover the Data files so they do not feel comfortable placing them in the same disk group lest they both be affected by some disk issues / failure / recovery.  However, if two Microsoft Exchange Servers have their data stored on the same EVA, it is perfectly acceptable for one EVA Disk Group to contain the Data from Exchange Server 1 *and* the Logs from Exchange Server 2.  Another EVA Disk Group would then contain the Logs from Exchange Server 1 *and* the Data from Exchange Server 2.  From the point of view of each Exchange Server, their separation has been accomplished.  From the EVA's point of view, the number of Disk groups has been kept to a minimum, achieving the performance recommendations.

• Hot spares. Chuck's description of the Distributed Sparing method used by EVA is not quite correct. The EVA spares virtual volume, as opposed to dedicated spare physical drives, across disk groups to deliver greater, rather than less capacity utilization, as suggested. The added advantages of EVA Distributed Sparing include the ability to incorporate added spindles (for the virtual distributed spare volume) in all disk group transactions to raise performance, while simultaneously providing virtual capacity for sparing use in the event of disk failure. This method also provides for room to rebuild in the event of failures that is faster than the comparative physical hot spare approach. And finally, the choice to use hot spinning spare drives, raises the prospect (admittedly small but still existing) of failure of the hot spares themselves. HP has asked the question: If the spare drive mechanics must be hot and available, why not have that contribute to the disk group performance? This is what EVA's Distributed Sparing method provides.

Also, "Virtual Spares" and "Proactive Disk Management" are two separate things so Chuck has also double counted the spares for the EVA example.  Since the "Protection Level" can be for 1 or 2 failures, the number of spares can either be 2 or 4 spindles per disk group.  Most of the EVA examples we show use Protection Level 1 (2 disks per group).

• Snapshots. Chuck is wrong in his statement that "HP EVA's ‘Virtually Capacity Free' snapshots, require close to the same amount of capacity as a CX4 would." The EVA uses two techniques for local replication, Cloning, snapclones, and mirrorclones - for complete point in time copies and Snapshots for efficient point in time copies. EVA also supports two types of snapshots and this may be the source of confusion. The first type, I fully reserved, i.e. reserves enough space for a fully diverged snapshot. The other type, more appropriate for this scenario, is space efficient, which only allocates space as required and keeps track of unchanged data via pointers. This type of snapshot has the potential to be virtually capacity free and can also be mounted and written to. The possible efficiency of this second snapshot method is a function of the planning effort by the user. If the user does no planning, and has no idea of the rate of change of his data, then the SnapClone, or fully reserved snapshots are the best and least efficient choice. But if the user has an intelligent or practiced sense of the rate of change for his data, then he can use the Space Efficient Snapshot, with a user selected allowance for Snapshot capacity growth. In the case of Exchange data, a typical rate of change that might be seen is on the order of 20-25% in the first 24 hours and nearly zero after that. And so the EVA's Space Efficient Snapshot method conserves capacity for original data use better than the CX4.
• Overhead. Chuck mis-states the overhead capacity that is required for meta-data. Such EVA meta-data consists of less than ½ of 1% of the total capacity. Thus, for 120 data disks, the overhead would be on the order of one disk, not five.

Occupancy Alarms.    Chuck has taken an EVA positive here and cast it as a negative.  We are happy to correct any misunderstanding on EVA's ability to allow for dynamic volume expansion.  Chuck states that "EVA best practice recommends a further 10% of each disk group be given to the EVA operating system, known as ‘Occupancy Alarm'".  Well, that does not remove that 10% from the available usable capacity.  Again, user planning and confidence in their planning comes into play here, as it did with Distributed Sparing.  If a user creates and mounts a LUN of a specific capacity on the EVA and has confidence that this capacity is adequate. In this case, there will be no Occupancy alarm, no extra Occupancy reserve, and no unusable capacity.  If however, the user wants the added assurance that should his LUN capacity require space beyond the original LUN capacity, he can elect to allow the LUN to dynamically grow within user selected limits. 

The reserve for such LUN expansion is active and usable space and in no way reduces the usable capacity of the EVA LUN.    The purpose of the "Occupancy Alarm' is not to withhold capacity, but to tell the user that a capacity threshold has been passed so they can proactively increase the capacity of a disk group by simply adding a disk(s) and letting the EVA transparently and non-disruptively incorporate the new disk(s) and capacity into the disk group.  There is no capacity use, reservation, or other impact to capacity efficiency related to "Occupancy Alarm," but simply a straight forward use model to allow a user to proactively and non disruptively adjust the capacity of a disk group.

We actually want to thank Chuck for stimulating this examination of EVA Capacity Efficiency, despite the errors in his initial reporting.  For the inquiring minds reading this, there is a also HP StorageWorks Usable Capacity Calculator tool that HP has developed that can be accessed through any direct, Partner or VAR authorized to sell the EVA.

Until Chuck holds another of these great public discussions, thanks for reading and HP looks forward to addressing such storage questions, as always, in a factual and objective manner.