Minor number uniqueness

[UniRock]

Hi Again..

We are going to create a new cluster, so have some questions in mind.

Why is it critical that the shared volume groups have identical minor numbers on all nodes in the cluster?

What might go wrong in case the minor number is different for a VG in different nodes?

Regards

[R.O. · Accepted solution]

Hi,

From SG manual:

1. First, set up the group directory for vgdatabase:
# mkdir /dev/vgdatabase
2. Next, create a control file named group in the directory
/dev/vgdatabase, as follows:
# 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 below. (This will avoid further reconfiguration later, when NFS-mounted logical volumes are created in the VG.)

Look for the manuals at "docs.hp.com", then "High Availability" and search for the manuals of your SG version.

Regards,

[Prasanth V Aravind]

>Why is it critical that the shared volume groups have identical minor numbers on all nodes in the cluster?


Its a best practice we follow to keep the minor number as same on all servers. it will make easy to trak if we keep identical minor number on all nodes.


Though, i strongly "feel" that service gaurd will work even you have different minur number on different node.

Like ... datavg-1 have minor number 0X030000 in server1 & 0X040000 in server2 .. it will work...


Correct me, if i am wrong.


Rgds
Prasanth

[Rita C Workman]

Think about it...you are designing a failover environment. Some failover designs can be quite extensive, with many nodes in a cluster and multiple failovers.
If you had multiple node failures, where might those packages, which node might be left running those packages.

The point is to guarantee that each number is unique or owned by ONE volume group, so on failover you don't have a conflict.

You could re-use a minor number on a VG on a different server - BUT...I'd make sure that vg will NEVER be inside my clustered environment.

The following is from an HP MC/SG document...
LVM Planning
You can create storage groups using the HP-UX Logical Volume Manager
(LVM), or using VERITAS VxVM and CVM software, which are
described in the next section.
When designing your disk layout using LVM, you should consider the
following:
â ¢ The root disk should belong to its own volume group.
â ¢ The volume groups that contain high availability applications,
services, or data must be on a bus or busses available to the primary
node and all adoptive nodes.
â ¢ High availability applications, services, and data should be placed in
a separate volume groups from non-high availability applications,
services, and data.
â ¢ You must group high availability applications, services, and data,
whose control needs to be transferred together, onto a single volume
group or a series of volume groups.
â ¢ You must not group two different high availability applications,
services, or data, whose control needs to be transferred
independently, onto the same volume group.

Kindest regards,
Rita

[Stephen Doud]

Page 212 of the Managing Serviceguard manual at http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02056213/c02056213.pdf
states:

"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.)"

[UniRock]

Thanks all for your answers and tips.