HPE EVA Storage

Testing HP EVA Dialhome

 
Kites BM
Regular Advisor

Testing HP EVA Dialhome


Assuming that any of the components failed on HP EVA,how to test the dial home for the same?

Please mention steps to trouble shoot the same.

thanks
9 REPLIES 9
Sivakumar MJ._1
Respected Contributor

Re: Testing HP EVA Dialhome

HP will have configured Remote Support Pack for your EVA.. Check it out..

If not ask HP to Configure it.

S. Boetticher
Regular Advisor

Re: Testing HP EVA Dialhome

after the RSP was installed and configured (by HP) correctly, there is a "test" functionality for verification of proper call home. also you could test for instance with pulling a (redundant) power cord.
Niels Vejrup Pedersen
Respected Contributor

Re: Testing HP EVA Dialhome

Hello,

There are different ways of checking that the Remote Support works.

1) run the command: wccproxy test
on the Command View machine

2) Check in System Event Analyzer that the event has been delivered

3) Change the alart level on a diskgroup to e.g. 5% instead of 90/95 and check System Event Analyzer again.

Regards
S. Boetticher
Regular Advisor

Re: Testing HP EVA Dialhome

I doubt that a disk group occupancy alert will ever be reported to HP (it was asked for Call Home, not simple email alerts)... ;-)

So I'd use a non-critical HW issue, like pulling a redundant power cable instead
Uwe Zessin
Honored Contributor

Re: Testing HP EVA Dialhome

Not to HP, but you will see it in HPSIM. Couple this with a "wccproxy/wsea test" and you have at least _some_ confidence that the end-to-end signaling works.

I do _NOT_ recommend removing redundancy on a production system.

It is too bad that after all these years (neither WEBES nor the EVA are _that_ new) you can still not trigger a 'simulated failure' from CV-EVA so that it automatically exercises the full path from the EVA to the service center. We don't need a telephone call - a simple close like on "wccproxy/wsea test" is sufficient.

I know that even some HP documents recommend to touch the system for testing, but let's face it:

- sometimes a service solution can only installed _after_ the EVA has gone into production, because some requirements were not met

- sometimes a service solution need to be upgraded or re-installed from scratch

It is not acceptable to remove redundancy from the production system just for test. I really don't want to explain to a customer that he had bad luck due to a

http://en.wikipedia.org/wiki/Synchronicity

- f.ex. I pulled a PS and the other power line went down. Yes, such things are rare, but they do happen.
.
Niels Vejrup Pedersen
Respected Contributor

Re: Testing HP EVA Dialhome

The idea about changing the alert level on a disk group will make sure the SEA gets the alert from command view. I know it won't be sent to HP.

But the wccproxy test command will check the full path to hp's backend.

As Uwe states it's not advisable to simulate real hardware faults - you know.. murphys law..

Regards
S. Boetticher
Regular Advisor

Re: Testing HP EVA Dialhome

ok guys, you won ;-)))


well, if it is a 4400 with certain XCS level and FATA drives, just wait a few days until a drive either goes single port on fibre or simply dies. That way you can verify the whole chain including response times until a replacement drive will appear on your site


;-)
Niels Vejrup Pedersen
Respected Contributor

Re: Testing HP EVA Dialhome

Hehe :-)

Yea, there are problems with the FATA's.

Many issues is solved by updating to latest drive firmware.

Regards
Uwe Zessin
Honored Contributor

Re: Testing HP EVA Dialhome

A bit off-topic, but there are also problems with the I/O modules, because some enclosures _love_ to bypass FC drives as well.
.