Re: EVA8100 diskgroup occupancy alarm best practice (2068 Views)
Reply
Advisor
krs2prs
Posts: 32
Registered: ‎06-20-2007
Message 1 of 18 (2,068 Views)
Accepted Solution

EVA8100 diskgroup occupancy alarm best practice

Hi,
I just like to know if the 85% best practice for the occupance alarm level is still valid for the new EVA4400, EVA8100, EVA8400? I believe this recommendation was mentioned when we only have EVA3000s and 5000s.
thanks and regards
krs2prs
Honored Contributor
Uwe Zessin
Posts: 10,320
Registered: ‎02-16-2004
Message 2 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

I have never heard about a "85%" best practice. It really depends on the environment. If your setup excludes BC and CA and you make use of the so-called 'protection level' to reserve disk space to recover redundancy from a disk drive failure you can go down to 5GB free space in a disk group.

And the 'occupancy alarm' is just that - a message if the value has been passed. The array continues to work fine.
.
Valued Contributor
Wickedsunny
Posts: 133
Registered: ‎05-03-2009
Message 3 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Occupancy alarm level is a percentage of the total disk group capacity in blocks. When the number of blocks in the disk group that contain user data reaches this level, an event code is generated. The alarm level is specified by the user.

Regardless of the EVA product which you are using, its always recommended to keep the Occupancy alarm on. The percentage can be decided by you.

Ideally 85% to 90% is what HP recommends.

Regards,
Sunny

P:S - Rate Solutions with points. It keeps us going..
Honored Contributor
Uwe Zessin
Posts: 10,320
Registered: ‎02-16-2004
Message 4 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Can you quote an official document?

The latest edition (March 2009) of 4AA2-0914ENW,
HP StorageWorks 4400/6400/8400 Enterprise Virtual Array configuration
Best practices white paper

Says
""* Most misunderstood best practice: 5 GB of free space is sufficient for array optimization in all configurations, or 90 percent/95 percent LUN allocation is a good rule of thumb for free space.

These rules are over simplifications and are correct for only some configurations. Five GB is sufficient only if no snapshots or DR groups exist and some availability tradeoffs are accepted (proactive disk management events). Ninety percent is frequently more than is really required for optimum operation, thus unnecessarily increasing the cost of storage. Be sure to read and follow the free space management best practices.""

The 'free space management' section talks about a mysterious PDM (Proactive disk management) which is an user initiated or automatic - ungrouping of a disk drive from a group.

So in addition to the so-called 'protection level' the user is supposed to keep free the capacity of two more disk drives from the group to be able to do a PDM.

Well, since 2002 I don't recall I have ever seen an EVA do an automatic PDM and have heard about only 1 or 2 cases where a disk drive has been manually ungrouped due to repeated errors reported.
.
Valued Contributor
Wickedsunny
Posts: 133
Registered: ‎05-03-2009
Message 5 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

90% is the default value which is set, once we first go to configure this. I have an extract from the Student guide which says:-

Occupancy alarm level This value is the percentage of total disk capacity used. When the amount of data in the disk group reaches this level, an event code is generated on the SMA or management server. For example, if the capacity of a disk group is 5GB, and the occupancy alarm level is 80%, the event code is generated when the amount of data in the disk group reaches 4GB.
The default value is 90%.

As Uwe said this entirely depends upon the kind of storage configured.

Regards,
Sunny

Advisor
krs2prs
Posts: 32
Registered: ‎06-20-2007
Message 6 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Hi Guys,
Thanks for the replies. I ran across a EVA perforamnce analysis template document before that actually give 85% as one of the checkpoints. I just don;t remeber were that doc is. But I do remember that the template was for eva5000. SO I'm not too sure if that still exists.
thanks,
krs2prs
Honored Contributor
Uwe Zessin
Posts: 10,320
Registered: ‎02-16-2004
Message 7 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

I remember when the EVA was all new the max. occupancy suggestion was rather conservative. The 'at minimum 5GB free in some situations'-rule is only a few years old.

In the early days the EVA sizing was kind of 'black art'. Does anybody remember the formulas with used 'Vfactorx' and secretly assumed a 95% rule? You were supposed to enter the disk dive size in 'Hardware Gigabytes), but a '72GB' disk drive is a little bit larger - I just checked an old, old report and that model had 73.4 HWGB.

Well, it looks like it still is a black art. Some weeks ago I met somebody from another partner who told me they sometimes have to deliver some disks 'for free' after the initial installation, because it turns out his maths does not work.
.
Valued Contributor
McCready
Posts: 91
Registered: ‎02-09-2007
Message 8 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

I think what you are really asking is how much space to leave free on an EVA; personally, I think the alarm should never be a suprise and we should always know how much is left before we think about allocating more.

As to that free space, I would generally lean towards a lower overall percentage free when I have a larger number of drives in a disk group, as that gives the EVA more leeway to do things like split an RSS group, etc. Just from a gut feeling, I would range between 90% in a 56 disk group to 95 percent in a 168 member group.

Of course, as was said, you need to have more space free when you do
- CA replication, for your logs (they are in RAID 1)
- snapshots or snapclones for backups or other purposes
- if you think you'll be removing disks from a group for whatever reason, like upgrading to higher capacity drives
- other work where you tend to keep copies of Vdisks around for a while, or if you want to handle emergency requests for space
check out evamgt.wetpaint.com and evamgt google group
Regular Advisor
S. Boetticher
Posts: 85
Registered: ‎11-23-2008
Message 9 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

@Uwe: about manual PDM ungrouping:

well, we had that several times on our EVAs, where we got "predictive failure warnings" (like S.M.A.R.T. on standard HDDs) and HP wanted us to proactively ungroup the disk as to not risk a failure (which would require VRaid-Rebuild and risk data loss if another HDD in that RSS set would die)...

OK, a many of that ungroupings were related to the EVA4400 1TB FATA issues with XCS09000xxx, however we even had such things on EVA4000...
Honored Contributor
Víctor Cespón
Posts: 2,397
Registered: ‎11-09-2007
Message 10 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

1 TB FATA drives (NB1000D4450) desesperately need firmware HP06, which should be out today AFAIK.
Honored Contributor
Uwe Zessin
Posts: 10,320
Registered: ‎02-16-2004
Message 11 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Now I understand why I try to avoid those FATAl disk drives in projects ;-)
.
Regular Advisor
S. Boetticher
Posts: 85
Registered: ‎11-23-2008
Message 12 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

yes, they are really different from the FCs (I have one EVA with both types, so I can measure the performance differences), however buying 96 1TB FATA vs. 96 450GB 15K FC is a big price difference, and you get double the storage. So for a VTL project with HW-compression before the data hits the spindles they are o.k. :-)
Honored Contributor
Mark...
Posts: 612
Registered: ‎02-26-2007
Message 13 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Hi,
Ref earlier post which is not quite correct (maybe a typo?) anyway:

"Occupancy alarm level is a percentage of the total disk group capacity in blocks. When the number of blocks in the disk group that contain user data reaches this level, an event code is generated. The alarm level is specified by the user."

The Occupancy alarm IS NOT "user data". This is the amount of space in a disk group that has been assigned for use - Vdisks, snapshots, snapclones, protected space etc.

Mark...
if you have nothing useful to say, say nothing...
Advisor
krs2prs
Posts: 32
Registered: ‎06-20-2007
Message 14 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Hi Guys,
Thanks for all you replies.
regards,
krs
Honored Contributor
Víctor Cespón
Posts: 2,397
Registered: ‎11-09-2007
Message 15 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

NEW Disk drive firmware bundle:

ftp://ftp.hp.com/pub/softlib/software10/COL17475/co-71198-1/HDDBundled_Image_2009_05_12.zip


The following 7.2K RPM HP06 enhancements are included in this release:

Fixed an issue with exchange timeouts in low temperature environments by decreasing the RAW (Read After Write) temperature threshold.

Fixed an issue where command timeouts would occur due to an overlapped command in the queue.

Fixed an issue where the drive would hang due to near-sequential writes interacting with RAW.

Fixed an issue of a drive hang caused during a read command after several queue-full responses during deep queue read testing.

Fixed an issue where the drive would Assert during sequential reads when the sequential read command was terminated by a check condition.

Fixed an issue in which the drive would erroneously SMART trip for ESI errors.

The following 15K RPM HP06 enhancements are included in this release:

Fixed an issue where command timeouts would occur due to an overlapped command in the queue.

Fixed an issue where the drive would hang due to near-sequential writes interacting with RAW.

Fixed an issue of a drive hang caused during a read command after several queue-full responses during deep queue read testing.

Fixed an issue in which the drive would erroneously SMART trip for ESI errors.

Fixed an issue where the drive would Assert during sequential reads when the sequential read command was terminated by a check condition.

Regular Advisor
S. Boetticher
Posts: 85
Registered: ‎11-23-2008
Message 16 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Thank you vcspon!

I'll have HP onsite tomorrow for update (they want to do it due to the escalation process).

Unfortunately a new XCS0950xxxx is not to be released soon (they won't risk a third recalled XCS in a row), so I have to live with the now recalled XCS09501100 for some weeks. At least all my problems are gone :-)
Honored Contributor
Zinky
Posts: 663
Registered: ‎11-26-2003
Message 17 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

Is the new XCS out for the EVA*400's?
Hakuna Matata

Favourite Toy:
AMD Athlon II X6 1090T 6-core, 16GB RAM, 12TB ZFS RAIDZ-2 Storage. Linux Centos 5.6 running KVM Hypervisor. Virtual Machines: Ubuntu, Mint, Solaris 10, Windows 7 Professional, Windows XP Pro, Windows Server 2008R2, DOS 6.22, OpenFiler
Regular Advisor
S. Boetticher
Posts: 85
Registered: ‎11-23-2008
Message 18 of 18 (2,068 Views)

Re: EVA8100 diskgroup occupancy alarm best practice

well, I got 09501400 under special conditions and know, that they even have a newer one...

but nothing official released yet, should arrive end of August/Start of september...
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.