Remove alternate links from Service Guard VGs for migration

[Christopher Hildrum_1]

All -
We plan on migrating data from our current Shark (F20) to a new Shark (800). We have a service guard environment (HP 11.00 - SG A.11.13) where each VG has a primary disk (one fibre channel) and the alternate disk is to the other fibre channel. I want to break the alternate link, connect that to the new Shark, mirror the data to the new shark, etc, and re-create the alternate after completed to the new Shark.
Questions are:
1) Can I remove the alternate link without causing a package fail?
2) Will this work becuase there will be different device files? I don't think SG cares about hardware level - just Logical level...
3) Am I crazy ?

Thanks in advance !
Chris

[John Poff · Accepted solution]

Hi Chris,

1. Yes, no problem. SG won't care as long as LVM is happy.

2. After you remove the PV links, you might want to do an 'rmsf -H ...' on the hardware path you are moving to the new array, and then do an ioscan and insf after you hook up so that you will get your new, correct device files.

3. Crazy? Only for buying another Shark! ;)

JP

[Sridhar Bhaskarla]

Hi Chris,

One thing you have to remember is that your ServiceGuard cluster lock disks will still be pointing to the old device files. So, you will need to re-apply the configuration.

However, you can do the migration while serviceguard is running by removing the links that are not specified as lock disks. Once the data migration is over, bring down the cluster, remove the other device files from the VG, extend the VG with the new alternate links, import them on the failover box, modify the cluster configuration file to modify the cluster lock device fiels, apply the configuration and bring up the cluster and package.

-Sri

[Michael Steele_2]

Important note to observe while performing this migration, you're removing all the links associated to one HBA.

The reason for this distinction is that all alternate disks may not be on the same controller / HBA / FC adapter so for you to just execute a vgreduce without specifying the lun will result in the last lun added to the vg being reduced out. So choose you're HBA and fail over if you need to:

pvchange -s n/y /dev/dsk/cXtYdZ

After you???ve attached the new disk array DON'T MIRROR if there???s a size difference, especially if the luns are bigger. Make new volume groups instead. Then create temporary mount points and copy over the data from original file systems to temporary file systems:

cp -p -r original temp

Now it???s just a matter of updating your /etc/fstab with the new vgs and re-directing the original mounts points, etc. In short, you???re using the file system structure to copy data over from old to new logical volumes and vgs.

The only time I'd mirror is if the lun sizes were identical.

Don't forget to pvcreate.

Regarding "...will the package failover...".

It???s a cluster coming down situation, not a package failover situation.

For example, the disk array drops. How could you fail over when all of the nodes are still up?

In your case nothing should happen since only a pvlink is being pulled so this is akin to a network failover instead of a package failover. Remember, its HW not SW.

Finally, if you are using the EMS Service Guard module then EMS will pick up the missing Pvlink and report it. This EMS module will also bring down the cluster if both pvlinks go away, or if the disk array goes away.
away.

[Christopher Caldwell]

We're doing something very similar right now.

1) shouldn't cause a package fail _unless_ there's a package dependency.

2) it will work

3) No. We're using MirrorDisk/UX migrating from an FC60 to an XP128 [everything in ServiceGuard]. It's working like a champ. The migration is easy.

[Christopher Hildrum_1]

All -

All answers are great ! You have helped me identify my concerns !

John- good reminder on rmsf
Sri - the lock disks are on primary HBA - but I will confim.

Michael - I have checked the paths and it was set up with one HBA then the second was added (from what I am told) - I have looked at all pri and alt links - I should be just fine. I am going to create same size, mirror, etc. This way I can copy on the fly.

Christopher - I will be doing the same as you - good to see someone else is currently doing this.

You may see a reply - thanks again to all!

[Christopher Hildrum_1]

Ok - Road block #1:

As always with new disk drives and size - my PE size is 4MB and total PE 1787 - ie 7.5 GB disk sizes.

I need to add 50GB LUNS - I know of no other way but to create new lvols, copy, etc.

Any tricks?

[John Poff]

Sorry. No tricks for increasing the PE size when adding much larger disks. Yes, you'll have to make a new VG with a larger PE for the new disks, make your LVs and mount them, and then just copy everything.

It was a cool idea, though!

JP

[Stephen Doud]

Sorry I didn't get to read this thread before now. This topic is addressed fairly well in this document located in the itrc:
UMCSGKBRC00008085
TITLE: Migrating "clustered" data from one disk array to another

-S.

[Michael Steele_2]

Sorry for the delay.

Regarding: "...I need to add 50GB LUNS - I know of no other way but to create new lvols, copy, etc..."


This is the procedure I described above copying data over into a temp. file system and updating /etc/fstab. Use cksum on the original and copy. Use fbackup for files over 2gb.

Regarding your 50gb luns.

-e MAX_PE (* default 1016 *)
-s PE_SIZE (* default 4mb *)
(* New PE_SIZE is power of 2. 4,8,16,32, etc. *)

Increase MAX_PE first but if you get "File too Large Error" on vgcreate failure then increase PE_SIZE.