First off: before you start using new pieces of hardware plan thoroughly. Update all firmware/microcodes to the absolutely latest level, regardless of being needed or not. You never know when you get another downtime once the systems are productive. The following is just a rough sketch - read it, fill in the details, go over it again, test it with a play system, test it again, review again, .... only then file a change and do the real takeover. This may sound chicken, but it will make sure you are home early.

Changing your SAN hardware and your server hardware should be two different things. Let us first talk about moving the LPARs to new hardware:

LPAR moves

You cannot do it without any interruption, but you can minimise the impact pretty much - in fact you can get down to one HACMP takeover for the whole operation. This will be the only visible effect for your users.

HACMP communication is done via communication daemons called "RSCT". As long as these daemons are at the same version HACMP will work even if the underlying OS versions are different. Keep this in mind for the following procedure:

1) Split the cluster (shutdown the cluster software on the standby node) and update RSCT on both nodes. Because the cluster is down no communication takes place and the active node will not notice that the standby node is on a different level as long as you do not restart the cluster software.

2) Once both nodes are udated RSCT-wise restart and resync the cluster. This step is optional but i am of fthe paranoid sort, therefore i did it.

3) Move the passive node over to the new hardware after you have split the cluster again. If you do it via LPM or not doesn't matter, as the node is not participating in the cluster anyway. You also do the OS update/upgrade now, either on the new or the old hardware. (I suppose here that the boot disk for the LPAR is provided by the VIOS and both VIOS pairs in the new and the old ahrdware can serve it up to the LPAR.)

4) Restart the cluster, synchronize (this will work because the RSCT is on the same level even if the rest of the OS is not) and do a takeover. You will end up with an active node on the new hardware, already updated to the target OS level. Notice, that i also presuppose here the availability of th data disk(s) on both the new and the old hardware. Take your time with the zoning for this, it can be pretty tricky!)

5) shut down the now passive (=further active) node, do the OS update and the LPAR move, like you did before with the other LPAR.

6) Restart the cluster and synchronize. Your resource groups now run on the "wrong" node (the one being passive when you started) and if you want to move it back you will have to do another takeover - this will also be noticeable by the users, but it is optional. You are running completely on new hardware and new OS levels.


SAN takeover

The first I'd like to recommend is: take your time for the zoning and the layout of your new SAN. Create sound naming conventions, zoning conventions, conventions for everything you can think about. Review these, over and over again. You will get no second chance for doing it right the first time. Changing conventions once you have some 100 LUNs given out is nigh impossible. Take care for live partition mobility! What makes P7 systems so sexy is that LPARs are (can be) completely independent from hardware. If you do it right you can move your LPARs around from one managed system to the next withput the user even noticing. You can make one MS free, shut it down, update it, bring it back online and move the LPARs back. Still, the SAN and the zoning has to support that, so think twice and thrice about what you do and if it leaves you with all these freedoms.

Once you are done SAN takeover is quite easy:

1) create new LUNS and bring it to the LPAR.

2) if you have concurrent VGs (ECC) it is easy, but some older SANs do not allow for concurrent mirrors. (Our old EMC Clariion for instance.) Bring the PVs to the active node in this case.

3) Before the change: bring the new LUNs online, then do a "extendvg" and a "mirrorvg" to the new disk(s). You can do this during online time, it will not slow down the system all too much. For maximum performance switch off the immediate synchronisation (use "-s" with "mirrorvg") and do a "syncvg" afterwards in background wiht the "-P" parameter set, i.e.:

Code:

extendvg myVG newPV
mirrorvg -s myVG newPV
syncvg -P <somenumber> -v myVG &

Depending on the PP size i used numbers between 5 and 16, which worked well.

4) If you have to promote the VG to ECC you will need some downtime. After syncing, shut down the cluster on both nodes, do a learning import on the passive node, remove the old disk from the VG ("unmirrorvg myVG oldPV"), change to ECC and do a learning import on te active side.

5) Note that you probably have to build new disks for the disk heartbeat too. I suggest moving them into a VG after discovering and configuring the heartbeat network just to make them unavailable for erroneous use otherwise.

I hope this helps.

bakunin

//PS: been there already: Takeover-Howto

Another point: If you use PowerHA 7.1 you have to use this idiotic "system repository disk", which was about as necessary as catching a flu, serves absolutely no purpose but may make problems if you have the wrong SAN storage. Our EMC VMax, virtualized via EMC VPLexes, for instance, are not supported. We have to (if we ever have to go for 7.1, which we try to avoid - its a long time until September, y'know) serve the repo-disk via VIOS as iSCSI therefore.

bakunin