How to Create an md.tab File
Create an /etc/lvm/md.tab file on each node in the cluster. Use the md.tab file to define Solstice DiskSuite metadevices or Solaris Volume Manager volumes for the disksets that you created.
Note - If you are using local metadevices or volumes, ensure that local metadevices or volumes names are distinct from the device-ID names used to form disksets. For example, if the device-ID name /dev/did/dsk/d3 is used in a diskset, do not use the name /dev/md/dsk/d3 for a local metadevice or volume. This requirement does not apply to shared metadevices or volumes, which use the naming convention /dev/md/setname/{r}dsk/d#.
Tip - To avoid possible confusion between local metadevices or volumes in a cluster environment, use a naming scheme that makes each local metadevice or volume name unique throughout the cluster. For example, for node 1 choose names from d100-d199. And for node 2 use d200-d299.
Become superuser on the cluster node.
List the DID mappings for reference when you create your md.tab file.
Use the full device-ID path names in the md.tab file in place of the lower-level device names (cNtXdY).
# scdidadm -L
In the following example, the first column of output is the DID instance number, the second column is the full physical path name, and the third column is the full device-ID path name (pseudo path).
1 phys-schost-1:/dev/rdsk/c0t0d0 /dev/did/rdsk/d1 2 phys-schost-1:/dev/rdsk/c1t1d0 /dev/did/rdsk/d2 2 phys-schost-2:/dev/rdsk/c1t1d0 /dev/did/rdsk/d2 3 phys-schost-1:/dev/rdsk/c1t2d0 /dev/did/rdsk/d3 3 phys-schost-2:/dev/rdsk/c1t2d0 /dev/did/rdsk/d3 ...
Create an /etc/lvm/md.tab file and edit it by hand with your preferred text editor.
See your Solstice DiskSuite/Solaris Volume Manager documentation and the md.tab(4) man page for details on how to create an md.tab file.
Note - If you have existing data on the disk drives that will be used for the submirrors, you must back up the data before metadevice or volume setup. Then restore the data onto the mirror.
Activate the metadevices or volumes that are defined in the md.tab files.
Example--Sample md.tab File
The following sample md.tab file defines the diskset that is named dg-schost-1. The ordering of lines in the md.tab file is not important.
dg-schost-1/d0 -m dg-schost-1/d10 dg-schost-1/d20
dg-schost-1/d10 1 1 /dev/did/rdsk/d1s0
dg-schost-1/d20 1 1 /dev/did/rdsk/d2s0 |
The sample md.tab file is constructed as follows.
Note - The following example uses Solstice DiskSuite terminology. For Solaris Volume Manager, a trans metadevice is instead called a transactional volume and a metadevice is instead called a volume. Otherwise, the following process is valid for both volume managers.
The first line defines the device d0 as a mirror of metadevices d10 and d20. The -m signifies that this device is a mirror device.
dg-schost-1/d0 -m dg-schost-1/d0 dg-schost-1/d20
The second line defines metadevice d10, the first submirror of d0, as a one-way stripe.
dg-schost-1/d10 1 1 /dev/did/rdsk/d1s0
The third line defines metadevice d20, the second submirror of d0, as a one-way stripe.
dg-schost-1/d20 1 1 /dev/did/rdsk/d2s0
How to Activate Metadevices or Volumes
Perform this procedure to activate Solstice DiskSuite metadevices or Solaris Volume Manager volumes that are defined inmd.tab files.
Become superuser on the cluster node.
Ensure that md.tab files are located in the /etc/lvm directory.
Ensure that you have ownership of the diskset on the node where the command will be executed.
Take ownership of the diskset.
# metaset -s setname -t
-s setname Specifies the diskset name
-t Takes ownership of the diskset
Activate the diskset's metadevices or volumes, which are defined in the md.tab file.
# metainit -s setname -a
-a Activates all metadevices in the md.tab file
For each master and log device, attach the second submirror (submirror2).
When the metadevices or volumes in the md.tab file are activated, only the first submirror (submirror1) of the master and log devices is attached, so submirror2 must be attached by hand.
# metattach mirror submirror2
Repeat Step 3 through Step 6 for each diskset in the cluster.
If necessary, run the metainit(1M) command from another node that has connectivity to the disk drives. This step is required for cluster-pair topologies, where the disk drives are not accessible by all nodes.
Check the status of the metadevices or volumes.
# metastat -s setname
See the metastat(1M) man page for more information.
Does your cluster contain disksets that are configured with exactly two disk enclosures and two nodes?
If yes, those disksets require mediators. Go to Configuring Mediators to add mediator hosts.
If no, go to How to Add Cluster File Systems to create a cluster file system.
Example--Activating Metadevices or Volumes in the md.tab File
In the following example, all metadevices that are defined in the md.tab file for diskset dg-schost-1 are activated. Then the second submirrors of master device dg-schost-1/d1 and log device dg-schost-1/d4 are activated.
# metainit -s dg-schost-1 -a # metattach dg-schost-1/d1 dg-schost-1/d3 # metattach dg-schost-1/d4 dg-schost-1/d6 |
Configuring Mediators
A mediator, or mediator host, is a cluster node that stores mediator data. Mediator data provides information on the location of other mediators and contains a commit count that is identical to the commit count stored in the database replicas. This commit count is used to confirm that the mediator data is in sync with the data in the database replicas.
Mediators are required for all Solstice DiskSuite/Solaris Volume Manager disksets that are configured with exactly two disk strings and two cluster nodes. A disk string consists of a disk enclosure, its physical disk drives, cables from the enclosure to the node(s), and the interface adapter cards. The use of mediators enables the Sun Cluster software to ensure that the most current data is presented in the instance of a single-string failure in a dual-string configuration. The following rules apply to dual-string configurations that use mediators.
Disksets must be configured with exactly two mediator hosts. Those two mediator hosts must be the same two cluster nodes that are used for the diskset.
A diskset cannot have more than two mediator hosts.
Mediators cannot be configured for disksets that do not meet the two-string and two-host criteria.
These rules do not require that the entire cluster must have exactly two nodes. Rather, only those disksets that have two disk strings must be connected to exactly two nodes. An N+1 cluster and many other topologies are permitted under these rules.
This section contains the following procedures: