EVA Shutdown w/Quorum disk

[Jack Trachtman]

I have a two node cluster connected to a SAN containing two EVA5000s. I am planning to shut down each EVA in turn to upgrade the firmware. Since one of the EVAs has the Quorum disk on it, what steps do I need to take (on the hosts and possibly the EVA) so this disk will be automatically reused as the QD when I restart the EVA? Thanks.

[Jan van den Ende]

Jack,


so this disk will be automatically reused as the QD when I restart the EVA?


Regrettably, I know of no way to do that.

Are you sure you do not have some kind of redundant config?
That would make make things easy.

I not, you can take the EVA with the QD offline, and upgrade it.
Now, you dismount your QD.
Remember, you are now vulnarable to cluster hang upon 1 node failure!

Now, upgrade the second EVA. Re-mount the QD and you are back in business.

EVE-1 and EVA-2 can of course be swapped.



btw,

how about all other disks served by each of your EVA's?

hth

Proost.

Have one on me.

jpe

[Jack Trachtman]

Jan,

"Are you sure you do not have some kind of redundant config? That would make make things easy."


I'm confused by your question. We have a cluster (redundancy) with dual paths to 2 EVAS and using HBVS - except for the Quorum disk which can't be shadowed.

Please explain the "That would make make things easy." comment. Thanks

[Volker Halle · Accepted solution]

Jack,

you just want to upgrade the firmware on the EVA, right ? You don't want to re-create empty disks, do you ? Are you talking about a dual-redundant EVA or 2 single EVAs ?

In case of a single EVA with the QD:

If you shutdown the EVA, to which the quorum disk is connected, the system will loose access to the quorum disk. If the votes are set up correctly and your 2 nodes are available, you'll get a cluster state transition, the quorum disk votes get removed and everything continues (assuming: EXPECTED_VOTES=3, 2 nodes with VOTES=1 each and QDSKVOTES=1).

The disks connected to that EVA will go into mount-verification. Depending on how long it takes to get the EVA back up, you'll have to take care of not exceeding MVTIMEOUT and SHADOW_MBR_TMO (these are dynamic parameters, so you can bump them up - BEFORE shutting down the EVA).

Once you reboot that EVA, mount-verification will succeed and the disks will become available again, including the QDSKVOTES.

In case of a dual-redundant EVA, I see no problem at all. The disks just fail over to the other EVA.

Volker.

[Jan van den Ende]

Jack,


Please explain the "That would make make things easy." comment.


Volker already explained that better than I could have done it!

Proost.

Have one on me.

jpe

[Uwe Zessin]

Volker, what do you mean by 'dual-redundant EVA'? Each EVA has two controllers whose firmware need to update at the same time.

If you are talking about CA-EVA data replication (Jack wrote they are using HBVS, not CA), I am afraid there is no 'automatic failover' to the other box - it's not that easy anyway...

[Volker Halle]

Uwe,

I've only seen an EVA once or twice ;-)

So you're saying an EVA is always a dual-redundant controller to be managed as one entity. I might have been thinking of it more like of a dual-redudant HSG80.

OK, so my 'single EVA' comments apply.

Volker.

[Uwe Zessin]

All EVAs I have seen had two controllers. I have even seen an engineering sample a few weeks before the EVA was announced ;-)

To the outside, an EVA looks similar to the HSG80 in 'multibus-failover mode' - the old 'dual redundancy setting' with port-WWN failover has never existed on the EVA.

[Jack Trachtman]

We do have two, separate, EVAs but as I mentioned the Quorum disk cannot be HBVSed across them per HP so shutting down the EVA with the QD will pull it ou from under the cluster.

Let me add: in a typical EVA firmware upgrade, the 2 controllers do a rolling boot and both typically restart quickly enough that VMS will simply go through a quick Mount Verify (though the Paths may also change).

The situation with the 3.025 FW upgrade I'm planning for is that it includes a disk FW upgrade. And, from what I've been told, depending on how many disks need their FW upgraded, the down time could be in the 30 minute time frame. This is the situation that is driving my question about what will VMS do when the QD "reappears" after an extended disappearance..

Again, thanks for all the input so far.

[Volker Halle]

Jack,

the default value of MVTIMEOUT is 3600 secs. You could even temporarily set it higher, if you expect you need more time. The disk will go into mount-verification and QDSKVOTES will be 'lost', but that's no problem, if your 2 nodes remain up and running. As you know from our previous discussion, you could also dismount the quorum disk before the EVA FW upgrade and remount is afterwards.

Consider to DISMOUNT your HBVS members connected to the EVA being updated with DISMOUNT/POLICY=MINI_COPY, this would allow them to be re-mounted with a fast mini-copy operation.

Volker.

[Jack Trachtman]

Volker's last response is what I'll try:

- dismount the QD on both nodes
- DISMOUNT/POLICY=MINI on all disk using EVA to be shutdown
- upgrade the EVA
- remount above disks, with the expectation that the nodes will recognize the QD and do the right thing

Thanks