cancel
Showing results for 
Search instead for 
Did you mean: 

SAP Migration, HPUX ServiceGuard to VCS

All,

We are preparing for a migration from a two node ServiceGuard on HPUX 11.23 to a two node VCS configuration. Does anyone have any experience with this type of migration? We have been planning and testing but are interested in experiences from the trenches, gotchas, look outs, make sure you xxxxx type of help. Anecdotes if you will.

 

The current config is active-passive with manual failover as needed under MC ServiceGuard. The data volumes are under LVM and the data will be migrated to VxFS on the new servers. One complication is that we have only one new machine. The exisiting primary node will become the failover node once we get the new server up and running. Storage is EMC Clariion 700.

hpux active node, lvm, MCService Guard, lets call it "alpha"

hpux passive node, lvm, MCService Guard, lets call it "beta"

 

will become

 

new hpux node, vxfs, VCS and lets call this new machine delta

alpha (current primary) will become the failover node and will have lvm and service guard torn down and VxFS and VCS installed and then joined to delta.

 

We wont tear down "beta" till delta is up and tested.

 

Any thoughts from the group, recommendations, anecdotes, concerns about our approach ?

 

1 Reply

I have gone through a similar

I have gone through a similar process in moving from SLVM with Oracle RAC using Serviceguard to CVM using VCS.  There are several things to watch out for and consider:

1) The only way to get rid of Serviceguard is to reinstall the OS.  I see in your plan that you will be migrating to a new system.  I would also make sure to reinstall the old system before bringing it into the cluster.

2) You can validate that the vxvmconvert process will get through the analysis phase without unmounting the file systems or stopping any applications.  If there is a configuration that it has problems with, it is better to know about it before going into a downtime situation.

3) Converting using VxVM 3.5 or 4.1 will allow for parallel conversions, which will speed up the time to convert.

4) Make sure that you have a full VxVM license on the box to convert.  If there are multiple paths to the devices, then during conversion the utility checks all paths.  If a full (at least temp) license is not on the box you may get errors, which are just due to the lack of a full license.

5) Mirrored LVM logical volumes can be tricky for the conversion process.  vxvmconvert has no problem converting a mirrored LV.  The tricky part is if you want to roll back.  During the conversion of a mirrored LV, the utility assumes that the mirrors are in sync, so no additional time is spent for conversion.  If you need to roll back, then all bets are off and the sync process is started.  This may impact a downtime window, so be prepared.  On previous projects, I have suggested that the mirrors be split before conversion as a safeguard to anything going wrong.  After you are in a good state, then you can re-attach the mirrors in VxVM and let them sync while the box is up and working.  I recommend that you have a process in place which is tested to be able to split the mirrors and reattach on the LVM side in case a backout is needed.

6) In your above info, I am assuming when you said vxfs you mean VxVM.

 

Hopefully this is what you were looking for.