Different minor numbers for the VG's in the Cluster.

[Bala C]

Hello,

I have Service guard setup of 3 node cluster Where I see that all the vg's minor number is different in each node.Looks like at the time of Service Guard setup, they haven't used the same minor number of the vg of node1 while creating the vg in the other node.

Is this a problem, Will it have a impact when the package fails over to the node2?

The SG documentation says the minor number of each Vg's should be common across the cluster nodes.

Kindly advise.

[Duncan Edmonstone · Accepted solution]

It's certainly "tidier" if they are all the same, but in most cases it doesn't really matter...

However if you are using the NFS toolkit and share NFS mount points out of your cluster, they _do_ need to be the same on all cluster nodes that can run the package with thye NFS share... this is because NFS uses the device major/minor numbers together with an inode to uniquely identify file handles for NFS clients - if they changed then after failover, a NFS client could think it has one file open, when in fact its another...

HTH

Duncan

[Bala C]

Thanks a lot, Duncan.

Anybody has a second thought?

[Stephen Doud]

Duncan is spot-on.
Page 212 in "Managing Serviceguard Eighteenth Edition, December 2009" states:

mknod /dev/vgdatabase/group c 64 0xhh0000
The major number is always 64, and the hexadecimal minor number has the form
0xhh0000
where hh must be unique to the volume group you are creating. Use a unique
minor number that is available across all the nodes for the mknod command above.
(This will avoid further reconfiguration later,when NFS-mounted logical volumes
are created in the volume group.)

As also Duncan stated, it eases administration if each server looks the same.
If NFS is not going to be used, then the admin decides whether it is worth it to match minor numbers across nodes.