Is service guard aware of alternate path to CL Disk

[Jonathan Walker]

I am currently making a change to the SAN infrastructure which will cause my EMC disks to change their CTD values. I have already migrated 1 path in the SAN and updated the cluster config file with the new CTD values of the CL Disk (this obliviously required the cluster to be down. But now I want to do the second path.

This is easy to fix in LVM because I vgreduce all devices that are seen down one path. I modify the SAN and then ioscan / insf -e, I then pull out the disks associated with each volume group and vgextend them back in to the VG.

This is all ok for LVM, but does service guard know about the old ctd values for the cluster lock disk. This was the error I got when I did the first migration and attempted cmcheckconf / cmapplyconf....

Oct 16 12:11:38 spfs809a vmunix: 0/10/0/0: Unable to access previously accessed device at nport ID 0xa0700.

Where was service guard getting this info ?

Thanks

Jonathan

[G. Vrijhoeven]

Hi Jonathan,

the cluster ascii file:

FIRST_CLUSTER_LOCK_PV /dev/dsk/c?t?d?

I think your instance numbers are changed.

Gideon

[melvyn burnard]

When you configure the cluster, in the ascii file you specify the physical device file, which points to the device, as the CLUSTER LOCK DEVICE. This is the ONLY path SG will try to use to talk to the disc, it has no idea of Alternate Paths.
if you change the path to a device, then you will have to halt the cluster, change your config file, and reapply the binary, remembering to have the cluster lock vg activated at the time of applying the binary.

[Jonathan Walker]

Sorry, I don't think the last few paragraphs are clear. I have updated cluster configs with the new path for the cluster lock disk. But a new CTD will be created for the alternate path to that disk. I was concerned that service guard was accessing the device when I was doing a cmcheckconf.

Oct 16 12:11:38 spfs809a vmunix: 0/10/0/0: Unable to access previously accessed device at nport ID 0xa0700.

Jonathan

[Geoff Wild]

No, MC/SG is not aware of alternate path(s) to cluster lock. You will have to regen your cmclconfig file with:
cmquerycl -v -C /etc/cmcluster/yourascii.file -n node1 -n node2

That will tell you what it wants for a cluster lock.

You will have to halt the cluster to apply it.

Rgds...Geoff

[Pramod_4]

Do the following to resolve your issue:

Generate the ascii cluster config file from the the cluster config binary file:
# cmgetconf > /etc/cmcluster/new.cluster.ascii

Edit new.cluster.ascii file and modify the entry for each node in your cluster.
"FIRST_CLUSTER_LOCK_PV /dev/dsk/c?t?d?"

Put the new CTD's for the EMC device.

Do a "cmcheckconf -C /etc/cmcluster/new.cluster.ascii" to very the syntax and integrity.

No no error reported, generate a new cluster config binary:
# cmapplyconf -C /etc/cmcluster/new.cluster.ascii

Regards,
Pramod

[Steven E. Protter]

After you are done, schedule a test that makes sure this configuration works. It will involve downing one of the servers in the cluster and then testing application availability.

SEP