Install and configure your local and multihost disks for Solstice DiskSuite or Solaris Volume Manager software by using the procedures in this chapter, along with the planning information in Planning Volume Management. See your Solstice DiskSuite or Solaris Volume Manager documentation for additional details.
DiskSuite Tool (Solstice DiskSuite metatool) and the Enhanced Storage module of Solaris Management Console (Solaris Volume Manager) are not compatible with Sun Cluster software. Use the command-line interface or Sun Cluster utilities to configure Solstice DiskSuite or Solaris Volume Manager software.
The following sections are in this chapter:
This section provides information and procedures to install and configure Solstice DiskSuite or Solaris Volume Manager software. You can skip certain procedures under the following conditions:
If you used SunPlex Installer to install Solstice DiskSuite software (Solaris 8), the procedures How to Install Solstice DiskSuite Software through How to Create State Database Replicas are already completed. Go to Mirroring the Root Disk or Creating Disk Sets in a Cluster to continue to configure Solstice DiskSuite software.
If you installed Solaris 9 or Solaris 10 software, Solaris Volume Manager is already installed. You can start configuration at How to Set the Number of Metadevice or Volume Names and Disk Sets.
The following table lists the tasks that you perform to install and configure Solstice DiskSuite or Solaris Volume Manager software for Sun Cluster configurations.
Table 3–1 Task Map: Installing and Configuring Solstice DiskSuite or Solaris Volume Manager Software
Task |
Instructions |
---|---|
1. Plan the layout of your Solstice DiskSuite or Solaris Volume Manager configuration. | |
2. (Solaris 8 only) Install Solstice DiskSuite software. | |
3. (Solaris 8 and Solaris 9 only) Calculate the number of metadevice names and disk sets needed for your configuration, and modify the /kernel/drv/md.conf file. |
How to Set the Number of Metadevice or Volume Names and Disk Sets |
4. Create state database replicas on the local disks. | |
5. (Optional) Mirror file systems on the root disk. |
Do not perform this procedure under the following circumstances:
You installed Solaris 9 software. Solaris Volume Manager software is automatically installed with Solaris 9 software. Instead, go to How to Set the Number of Metadevice or Volume Names and Disk Sets.
You installed Solaris 10 software. Instead, go to How to Create State Database Replicas.
You used SunPlex Installer to install Solstice DiskSuite software. Instead, do one of the following:
If you plan to create additional disk sets, go to How to Set the Number of Metadevice or Volume Names and Disk Sets.
If you do not plan to create additional disk sets, go to Mirroring the Root Disk.
Perform this task on each node in the cluster.
Perform the following tasks:
Make mappings of your storage drives.
Complete the following configuration planning worksheets. See Planning Volume Management for planning guidelines.
Become superuser on the cluster node.
If you install from the CD-ROM, insert the Solaris 8 Software 2 of 2 CD-ROM in the CD-ROM drive on the node.
This step assumes that the Volume Management daemon vold(1M) is running and configured to manage CD-ROM devices.
Install the Solstice DiskSuite software packages.
Install the packages in the order that is shown in the following example.
# cd /cdrom/sol_8_sparc_2/Solaris_8/EA/products/DiskSuite_4.2.1/sparc/Packages # pkgadd -d . SUNWmdr SUNWmdu [SUNWmdx] optional-pkgs |
The SUNWmdr and SUNWmdu packages are required for all Solstice DiskSuite installations.
The SUNWmdx package is also required for the 64-bit Solstice DiskSuite installation.
See your Solstice DiskSuite installation documentation for information about optional software packages.
If you have Solstice DiskSuite software patches to install, do not reboot after you install the Solstice DiskSuite software.
If you installed from a CD-ROM, eject the CD-ROM.
Install any Solstice DiskSuite patches.
See Patches and Required Firmware Levels in Sun Cluster 3.1 8/05 Release Notes for Solaris OS for the location of patches and installation instructions.
Repeat Step 1 through Step 5 on each of the other nodes of the cluster.
From one node of the cluster, manually populate the global-device namespace for Solstice DiskSuite.
# scgdevs |
If you used SunPlex Installer to install Solstice DiskSuite software, go to Mirroring the Root Disk.
If the cluster runs on the Solaris 10 OS, go to How to Create State Database Replicas.
Otherwise, go to How to Set the Number of Metadevice or Volume Names and Disk Sets.
The scgdevs command might return a message similar to the message Could not open /dev/rdsk/c0t6d0s2 to verify device id, Device busy. If the listed device is a CD-ROM device, you can safely ignore the message.
Do not perform this procedure. in the following circumstances:
The cluster runs on the Solaris 10 OS. Instead, go to How to Create State Database Replicas.
With the Solaris 10 release, Solaris Volume Manager has been enhanced to configure volumes dynamically. You no longer need to edit the nmd and the md_nsets parameters in the /kernel/drv/md.conf file. New volumes are dynamically created, as needed.
You used SunPlex Installer to install Solstice DiskSuite software. Instead, go to Mirroring the Root Disk.
This procedure describes how to determine the number of Solstice DiskSuite metadevice or Solaris Volume Manager volume names and disk sets that are needed for your configuration. This procedure also describes how to modify the /kernel/drv/md.conf file to specify these numbers.
The default number of metadevice or volume names per disk set is 128, but many configurations need more than the default. Increase this number before you implement a configuration, to save administration time later.
At the same time, keep the value of the nmdfield and the md_nsets field as low as possible. Memory structures exist for all possible devices as determined by nmdand md_nsets, even if you have not created those devices. For optimal performance, keep the value of nmd and md_nsets only slightly higher than the number of metadevices or volumes you plan to use.
Have available the completed Disk Device Group Configurations Worksheet.
Calculate the total number of disk sets that you expect to need in the cluster, then add one more disk set for private disk management.
The cluster can have a maximum of 32 disk sets, 31 disk sets for general use plus one disk set for private disk management. The default number of disk sets is 4. You supply this value for the md_nsets field in Step 3.
Calculate the largest metadevice or volume name that you expect to need for any disk set in the cluster.
Each disk set can have a maximum of 8192 metadevice or volume names. You supply this value for the nmd field in Step 3.
Determine the quantity of metadevice or volume names that you expect to need for each disk set.
If you use local metadevices or volumes, ensure that each local metadevice or volume name on which a global-devices file system, /global/.devices/node@ nodeid, is mounted is unique throughout the cluster and does not use the same name as any device-ID name in the cluster.
Choose a range of numbers to use exclusively for device-ID names and a range for each node to use exclusively for its local metadevice or volume names. For example, device-ID names might use the range from d1 to d100. Local metadevices or volumes on node 1 might use names in the range from d100 to d199. And local metadevices or volumes on node 2 might use d200 to d299.
Calculate the highest of the metadevice or volume names that you expect to use in any disk set.
The quantity of metadevice or volume names to set is based on the metadevice or volume name value rather than on the actual quantity . For example, if your metadevice or volume names range from d950 to d1000, Solstice DiskSuite or Solaris Volume Manager software requires that you set the value at 1000 names, not 50.
On each node, become superuser and edit the /kernel/drv/md.conf file.
All cluster nodes (or cluster pairs in the cluster-pair topology) must have identical /kernel/drv/md.conf files, regardless of the number of disk sets served by each node. Failure to follow this guideline can result in serious Solstice DiskSuite or Solaris Volume Manager errors and possible loss of data.
On each node, perform a reconfiguration reboot.
# touch /reconfigure # shutdown -g0 -y -i6 |
Changes to the /kernel/drv/md.conf file become operative after you perform a reconfiguration reboot.
Create local state database replicas. Go to How to Create State Database Replicas.
If you used SunPlex Installer to install Solstice DiskSuite software, do not perform this procedure. Instead, go to Mirroring the Root Disk.
Perform this procedure on each node in the cluster.
Become superuser on the cluster node.
Create state database replicas on one or more local devices for each cluster node.
Use the physical name (cNtXdY sZ), not the device-ID name (dN), to specify the slices to use.
# metadb -af slice-1 slice-2 slice-3 |
To provide protection of state data, which is necessary to run Solstice DiskSuite or Solaris Volume Manager software, create at least three replicas for each node. Also, you can place replicas on more than one device to provide protection if one of the devices fails.
See the metadb(1M) man page and your Solstice DiskSuite or Solaris Volume Manager documentation for details.
Verify the replicas.
# metadb |
The metadb command displays the list of replicas.
The following example shows three Solstice DiskSuite state database replicas. Each replica is created on a different device. For Solaris Volume Manager, the replica size would be larger.
# metadb -af c0t0d0s7 c0t1d0s7 c1t0d0s7 # metadb flags first blk block count a u 16 1034 /dev/dsk/c0t0d0s7 a u 16 1034 /dev/dsk/c0t1d0s7 a u 16 1034 /dev/dsk/c1t0d0s7 |
To mirror file systems on the root disk, go to Mirroring the Root Disk.
Otherwise, go to Creating Disk Sets in a Cluster to create Solstice DiskSuite or Solaris Volume Manager disk sets.
Mirroring the root disk prevents the cluster node itself from shutting down because of a system disk failure. Four types of file systems can reside on the root disk. Each file-system type is mirrored by using a different method.
Use the following procedures to mirror each type of file system.
For local disk mirroring, do not use /dev/global as the path when you specify the disk name. If you specify this path for anything other than cluster file systems, the system cannot boot.
Use this procedure to mirror the root (/) file system.
Become superuser on the node.
Place the root slice in a single-slice (one-way) concatenation.
Specify the physical disk name of the root-disk slice (cNtXdY sZ).
# metainit -f submirror1 1 1 root-disk-slice |
Create a second concatenation.
# metainit submirror2 1 1 submirror-disk-slice |
Create a one-way mirror with one submirror.
# metainit mirror -m submirror1 |
If the device is a local device to be used to mount a global-devices file system, /global/.devices/node@nodeid, the metadevice or volume name for the mirror must be unique throughout the cluster.
Run the metaroot(1M) command.
This command edits the /etc/vfstab and /etc/system files so the system can be booted with the root (/) file system on a metadevice or volume.
# metaroot mirror |
Run the lockfs(1M) command.
This command flushes all transactions out of the log and writes the transactions to the master file system on all mounted UFS file systems.
# lockfs -fa |
Move any resource groups or device groups from the node.
# scswitch -S -h from-node |
Moves all resource groups and device groups
Specifies the name of the node from which to move resource or device groups
Reboot the node.
This command remounts the newly mirrored root (/) file system.
# shutdown -g0 -y -i6 |
Use the metattach(1M) command to attach the second submirror to the mirror.
# metattach mirror submirror2 |
If the disk that is used to mirror the root disk is physically connected to more than one node (multihosted), enable the localonly property.
Perform the following steps to enable the localonly property of the raw-disk device group for the disk that is used to mirror the root disk. You must enable the localonly property to prevent unintentional fencing of a node from its boot device if the boot device is connected to multiple nodes.
If necessary, use the scdidadm(1M) -L command to display the full device-ID path name of the raw-disk device group.
In the following example, the raw-disk device-group name dsk/d2 is part of the third column of output, which is the full device-ID path name.
# scdidadm -L … 1 phys-schost-3:/dev/rdsk/c1t1d0 /dev/did/rdsk/d2 |
View the node list of the raw-disk device group.
Output looks similar to the following:
# scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … |
If the node list contains more than one node name, remove all nodes from the node list except the node whose root disk you mirrored.
Only the node whose root disk you mirrored should remain in the node list for the raw-disk device group.
# scconf -r -D name=dsk/dN,nodelist=node |
Specifies the cluster-unique name of the raw-disk device group
Specifies the name of the node or nodes to remove from the node list
Use the scconf(1M) command to enable the localonly property.
When the localonly property is enabled, the raw-disk device group is used exclusively by the node in its node list. This usage prevents unintentional fencing of the node from its boot device if the boot device is connected to multiple nodes.
# scconf -c -D name=rawdisk-groupname,localonly=true |
Specifies the name of the raw-disk device group
For more information about the localonly property, see the scconf_dg_rawdisk(1M) man page.
Record the alternate boot path for possible future use.
If the primary boot device fails, you can then boot from this alternate boot device. See Chapter 7, Troubleshooting the System, in Solstice DiskSuite 4.2.1 User’s Guide, Special Considerations for Mirroring root (/) in Solaris Volume Manager Administration Guide, or Creating a RAID-1 Volume in Solaris Volume Manager Administration Guide for more information about alternate boot devices.
# ls -l /dev/rdsk/root-disk-slice |
Repeat Step 1 through Step 11 on each remaining node of the cluster.
Ensure that each metadevice or volume name for a mirror on which a global-devices file system, /global/.devices/node@nodeid, is to be mounted is unique throughout the cluster.
The following example shows the creation of mirror d0 on the node phys-schost-1, which consists of submirror d10 on partition c0t0d0s0 and submirror d20 on partition c2t2d0s0. Device c2t2d0 is a multihost disk, so the localonly property is enabled.
(Create the mirror) # metainit -f d10 1 1 c0t0d0s0 d11: Concat/Stripe is setup # metainit d20 1 1 c2t2d0s0 d12: Concat/Stripe is setup # metainit d0 -m d10 d10: Mirror is setup # metaroot d0 # lockfs -fa (Move resource groups and device groups from phys-schost-1) # scswitch -S -h phys-schost-1 (Reboot the node) # shutdown -g0 -y -i6 (Attach the second submirror) # metattach d0 d20 d0: Submirror d20 is attached (Display the device-group node list) # scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … (Remove phys-schost-3 from the node list) # scconf -r -D name=dsk/d2,nodelist=phys-schost-3 (Enable the localonly property) # scconf -c -D name=dsk/d2,localonly=true (Record the alternate boot path) # ls -l /dev/rdsk/c2t2d0s0 lrwxrwxrwx 1 root root 57 Apr 25 20:11 /dev/rdsk/c2t2d0s0 –> ../../devices/node@1/pci@1f,0/pci@1/scsi@3,1/disk@2,0:a,raw |
To mirror the global namespace, /global/.devices/node@nodeid, go to How to Mirror the Global Namespace.
To mirror file systems than cannot be unmounted, go to How to Mirror File Systems Other Than Root (/) That Cannot Be Unmounted.
To mirror user-defined file systems, go to How to Mirror File Systems That Can Be Unmounted.
Otherwise, go to Creating Disk Sets in a Cluster to create a disk set.
Some of the steps in this mirroring procedure might cause an error message similar to metainit: dg-schost-1: d1s0: not a metadevice. Such an error message is harmless and can be ignored.
Use this procedure to mirror the global namespace, /global/.devices/node@nodeid/.
Become superuser on a node of the cluster.
Place the global namespace slice in a single-slice (one-way) concatenation.
Use the physical disk name of the disk slice (cNtXdY sZ).
# metainit -f submirror1 1 1 diskslice |
Create a second concatenation.
# metainit submirror2 1 1 submirror-diskslice |
Create a one-way mirror with one submirror.
# metainit mirror -m submirror1 |
The metadevice or volume name for a mirror on which a global-devices file system, /global/.devices/node@nodeid, is to be mounted must be unique throughout the cluster.
Attach the second submirror to the mirror.
This attachment starts a synchronization of the submirrors.
# metattach mirror submirror2 |
Edit the /etc/vfstab file entry for the /global/.devices/node@nodeid file system.
Replace the names in the device to mount and device to fsck columns with the mirror name.
# vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/mirror /dev/md/rdsk/mirror /global/.devices/node@nodeid ufs 2 no global |
Repeat Step 1 through Step 6 on each remaining node of the cluster.
Wait for the synchronization of the mirrors, started in Step 5, to be completed.
Use the metastat(1M) command to view mirror status and to verify that mirror synchronization is complete.
# metastat mirror |
If the disk that is used to mirror the global namespace is physically connected to more than one node (multihosted), enable the localonly property.
Perform the following steps to enable the localonly property of the raw-disk device group for the disk that is used to mirror the global namespace. You must enable the localonly property to prevent unintentional fencing of a node from its boot device if the boot device is connected to multiple nodes.
If necessary, use the scdidadm(1M) command to display the full device-ID path name of the raw-disk device group.
In the following example, the raw-disk device-group name dsk/d2 is part of the third column of output, which is the full device-ID path name.
# scdidadm -L … 1 phys-schost-3:/dev/rdsk/c1t1d0 /dev/did/rdsk/d2 |
View the node list of the raw-disk device group.
Output looks similar to the following.
# scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … |
If the node list contains more than one node name, remove all nodes from the node list except the node whose disk is mirrored.
Only the node whose disk is mirrored should remain in the node list for the raw-disk device group.
# scconf -r -D name=dsk/dN,nodelist=node |
Specifies the cluster-unique name of the raw-disk device group
Specifies the name of the node or nodes to remove from the node list
Enable the localonly property.
When the localonly property is enabled, the raw-disk device group is used exclusively by the node in its node list. This usage prevents unintentional fencing of the node from its boot device if the boot device is connected to multiple nodes.
# scconf -c -D name=rawdisk-groupname,localonly=true |
Specifies the name of the raw-disk device group
For more information about the localonly property, see the scconf_dg_rawdisk(1M) man page.
The following example shows creation of mirror d101, which consists of submirror d111 on partition c0t0d0s3 and submirror d121 on partition c2t2d0s3. The /etc/vfstab file entry for /global/.devices/node@1 is updated to use the mirror name d101. Device c2t2d0 is a multihost disk, so the localonly property is enabled.
(Create the mirror) # metainit -f d111 1 1 c0t0d0s3 d111: Concat/Stripe is setup # metainit d121 1 1 c2t2d0s3 d121: Concat/Stripe is setup # metainit d101 -m d111 d101: Mirror is setup # metattach d101 d121 d101: Submirror d121 is attached (Edit the /etc/vfstab file) # vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/d101 /dev/md/rdsk/d101 /global/.devices/node@1 ufs 2 no global (View the sync status) # metastat d101 d101: Mirror Submirror 0: d111 State: Okay Submirror 1: d121 State: Resyncing Resync in progress: 15 % done … (Identify the device-ID name of the mirrored disk's raw-disk device group) # scdidadm -L … 1 phys-schost-3:/dev/rdsk/c2t2d0 /dev/did/rdsk/d2 (Display the device-group node list) # scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … (Remove phys-schost-3 from the node list) # scconf -r -D name=dsk/d2,nodelist=phys-schost-3 (Enable the localonly property) # scconf -c -D name=dsk/d2,localonly=true |
To mirror file systems other than root (/) that cannot be unmounted, go to How to Mirror File Systems Other Than Root (/) That Cannot Be Unmounted.
To mirror user-defined file systems, go to How to Mirror File Systems That Can Be Unmounted
Otherwise, go to Creating Disk Sets in a Cluster to create a disk set.
Some of the steps in this mirroring procedure might cause an error message similar to metainit: dg-schost-1: d1s0: not a metadevice. Such an error message is harmless and can be ignored.
Use this procedure to mirror file systems other than root (/) that cannot be unmounted during normal system usage, such as /usr, /opt, or swap.
Become superuser on a node of the cluster.
Place the slice on which an unmountable file system resides in a single-slice (one-way) concatenation.
Specify the physical disk name of the disk slice (cNtX dYsZ).
# metainit -f submirror1 1 1 diskslice |
Create a second concatenation.
# metainit submirror2 1 1 submirror-diskslice |
Create a one-way mirror with one submirror.
# metainit mirror -m submirror1 |
The metadevice or volume name for this mirror does not need to be unique throughout the cluster.
Repeat Step 1 through Step 4 for each remaining unmountable file system that you want to mirror.
On each node, edit the /etc/vfstab file entry for each unmountable file system you mirrored.
Replace the names in the device to mount and device to fsck columns with the mirror name.
# vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/mirror /dev/md/rdsk/mirror /filesystem ufs 2 no global |
Move any resource groups or device groups from the node.
# scswitch -S -h from-node |
Moves all resource groups and device groups
Specifies the name of the node from which to move resource or device groups
Reboot the node.
# shutdown -g0 -y -i6 |
Attach the second submirror to each mirror.
This attachment starts a synchronization of the submirrors.
# metattach mirror submirror2 |
Wait for the synchronization of the mirrors, started in Step 9, to complete.
Use the metastat(1M) command to view mirror status and to verify that mirror synchronization is complete.
# metastat mirror |
If the disk that is used to mirror the unmountable file system is physically connected to more than one node (is multihosted), enable the localonly property.
Perform the following steps to enable the localonly property of the raw-disk device group for the disk that is used to mirror the unmountable file system. You must enable the localonly property to prevent unintentional fencing of a node from its boot device if the boot device is connected to multiple nodes.
If necessary, use the scdidadm -L command to display the full device-ID path name of the raw-disk device group.
In the following example, the raw-disk device-group name dsk/d2 is part of the third column of output, which is the full device-ID path name.
# scdidadm -L … 1 phys-schost-3:/dev/rdsk/c1t1d0 /dev/did/rdsk/d2 |
View the node list of the raw-disk device group.
Output looks similar to the following.
# scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … |
If the node list contains more than one node name, remove all nodes from the node list except the node whose root disk is mirrored.
Only the node whose root disk is mirrored should remain in the node list for the raw-disk device group.
# scconf -r -D name=dsk/dN,nodelist=node |
Specifies the cluster-unique name of the raw-disk device group
Specifies the name of the node or nodes to remove from the node list
Enable the localonly property.
When the localonly property is enabled, the raw-disk device group is used exclusively by the node in its node list. This usage prevents unintentional fencing of the node from its boot device if the boot device is connected to multiple nodes.
# scconf -c -D name=rawdisk-groupname,localonly=true |
Specifies the name of the raw-disk device group
For more information about the localonly property, see the scconf_dg_rawdisk(1M) man page.
The following example shows the creation of mirror d1 on the node phys-schost-1 to mirror /usr, which resides on c0t0d0s1. Mirror d1 consists of submirror d11 on partition c0t0d0s1 and submirror d21 on partition c2t2d0s1. The /etc/vfstab file entry for /usr is updated to use the mirror name d1. Device c2t2d0 is a multihost disk, so the localonly property is enabled.
(Create the mirror) # metainit -f d11 1 1 c0t0d0s1 d11: Concat/Stripe is setup # metainit d21 1 1 c2t2d0s1 d21: Concat/Stripe is setup # metainit d1 -m d11 d1: Mirror is setup (Edit the /etc/vfstab file) # vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/d1 /dev/md/rdsk/d1 /usr ufs 2 no global (Move resource groups and device groups from phys-schost-1) # scswitch -S -h phys-schost-1 (Reboot the node) # shutdown -g0 -y -i6 (Attach the second submirror) # metattach d1 d21 d1: Submirror d21 is attached (View the sync status) # metastat d1 d1: Mirror Submirror 0: d11 State: Okay Submirror 1: d21 State: Resyncing Resync in progress: 15 % done … (Identify the device-ID name of the mirrored disk's raw-disk device group) # scdidadm -L … 1 phys-schost-3:/dev/rdsk/c2t2d0 /dev/did/rdsk/d2 (Display the device-group node list) # scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … (Remove phys-schost-3 from the node list) # scconf -r -D name=dsk/d2,nodelist=phys-schost-3 (Enable the localonly property) # scconf -c -D name=dsk/d2,localonly=true |
To mirror user-defined file systems, go to How to Mirror File Systems That Can Be Unmounted.
Otherwise, go to Creating Disk Sets in a Cluster to create a disk set.
Some of the steps in this mirroring procedure might cause an error message similar to metainit: dg-schost-1: d1s0: not a metadevice. Such an error message is harmless and can be ignored.
Use this procedure to mirror user-defined file systems that can be unmounted. In this procedure, the nodes do not need to be rebooted.
Become superuser on a node of the cluster.
Unmount the file system to mirror.
Ensure that no processes are running on the file system.
# umount /mount-point |
See the umount(1M) man page and Chapter 19, Mounting and Unmounting File Systems (Tasks), in System Administration Guide: Devices and File Systems for more information.
Place in a single-slice (one-way) concatenation the slice that contains a user-defined file system that can be unmounted.
Specify the physical disk name of the disk slice (cNtX dYsZ).
# metainit -f submirror1 1 1 diskslice |
Create a second concatenation.
# metainit submirror2 1 1 submirror-diskslice |
Create a one-way mirror with one submirror.
# metainit mirror -m submirror1 |
The metadevice or volume name for this mirror does not need to be unique throughout the cluster.
Repeat Step 1 through Step 5 for each mountable file system to be mirrored.
On each node, edit the /etc/vfstab file entry for each file system you mirrored.
Replace the names in the device to mount and device to fsck columns with the mirror name.
# vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/mirror /dev/md/rdsk/mirror /filesystem ufs 2 no global |
Attach the second submirror to the mirror.
This attachment starts a synchronization of the submirrors.
# metattach mirror submirror2 |
Wait for the synchronization of the mirrors, started in Step 8, to be completed.
Use the metastat(1M) command to view mirror status.
# metastat mirror |
If the disk that is used to mirror the user-defined file system is physically connected to more than one node (multihosted), enable the localonly property.
Perform the following steps to enable the localonly property of the raw-disk device group for the disk that is used to mirror the user-defined file system. You must enable the localonly property to prevent unintentional fencing of a node from its boot device if the boot device is connected to multiple nodes.
If necessary, use the scdidadm -L command to display the full device-ID path name of the raw-disk device group.
In the following example, the raw-disk device-group name dsk/d4 is part of the third column of output, which is the full device-ID path name.
# scdidadm -L … 1 phys-schost-3:/dev/rdsk/c1t1d0 /dev/did/rdsk/d2 |
View the node list of the raw-disk device group.
Output looks similar to the following.
# scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … |
If the node list contains more than one node name, remove all nodes from the node list except the node whose root disk you mirrored.
Only the node whose root disk you mirrored should remain in the node list for the raw-disk device group.
# scconf -r -D name=dsk/dN,nodelist=node |
Specifies the cluster-unique name of the raw-disk device group
Specifies the name of the node or nodes to remove from the node list
Enable the localonly property.
When the localonly property is enabled, the raw-disk device group is used exclusively by the node in its node list. This usage prevents unintentional fencing of the node from its boot device if the boot device is connected to multiple nodes.
# scconf -c -D name=rawdisk-groupname,localonly=true |
Specifies the name of the raw-disk device group
For more information about the localonly property, see the scconf_dg_rawdisk(1M) man page.
Mount the mirrored file system.
# mount /mount-point |
See the mount(1M) man page and Chapter 19, Mounting and Unmounting File Systems (Tasks), in System Administration Guide: Devices and File Systems for more information.
The following example shows creation of mirror d4 to mirror /export, which resides on c0t0d0s4. Mirror d4 consists of submirror d14 on partition c0t0d0s4 and submirror d24 on partition c2t2d0s4. The /etc/vfstab file entry for /export is updated to use the mirror name d4. Device c2t2d0 is a multihost disk, so the localonly property is enabled.
(Unmount the file system) # umount /export (Create the mirror) # metainit -f d14 1 1 c0t0d0s4 d14: Concat/Stripe is setup # metainit d24 1 1 c2t2d0s4 d24: Concat/Stripe is setup # metainit d4 -m d14 d4: Mirror is setup (Edit the /etc/vfstab file) # vi /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # # /dev/md/dsk/d4 /dev/md/rdsk/d4 /export ufs 2 no global (Attach the second submirror) # metattach d4 d24 d4: Submirror d24 is attached (View the sync status) # metastat d4 d4: Mirror Submirror 0: d14 State: Okay Submirror 1: d24 State: Resyncing Resync in progress: 15 % done … (Identify the device-ID name of the mirrored disk's raw-disk device group) # scdidadm -L … 1 phys-schost-3:/dev/rdsk/c2t2d0 /dev/did/rdsk/d2 (Display the device-group node list) # scconf -pvv | grep dsk/d2 Device group name: dsk/d2 … (dsk/d2) Device group node list: phys-schost-1, phys-schost-3 … (Remove phys-schost-3 from the node list) # scconf -r -D name=dsk/d2,nodelist=phys-schost-3 (Enable the localonly property) # scconf -c -D name=dsk/d2,localonly=true (Mount the file system) # mount /export |
If you need to create disk sets, go to one of the following:
To create a Solaris Volume Manager for Sun Cluster disk set for use by Oracle Real Application Clusters, go to Creating a Multi-Owner Disk Set in Solaris Volume Manager for Sun Cluster for the Oracle Real Application Clusters Database in Sun Cluster Data Service for Oracle Real Application Clusters Guide for Solaris OS.
To create a disk set for any other application, go to Creating Disk Sets in a Cluster.
If you used SunPlex Installer to install Solstice DiskSuite, one to three disk sets might already exist. See Using SunPlex Installer to Configure Sun Cluster Software for information about the metasets that were created by SunPlex Installer.
If you have sufficient disk sets for your needs, go to one of the following:
If your cluster contains disk sets that are configured with exactly two disk enclosures and two nodes, you must add dual-string mediators. Go to Configuring Dual-String Mediators.
If your cluster configuration does not require dual-string mediators, go to How to Create Cluster File Systems.
Some of the steps in this mirroring procedure might cause an error message that is similar to metainit: dg-schost-1: d1s0: not a metadevice. Such an error message is harmless and can be ignored.
This section describes how to create disk sets for a cluster configuration. You might not need to create disk sets under the following circumstances:
If you used SunPlex Installer to install Solstice DiskSuite, one to three disk sets might already exist. See Using SunPlex Installer to Configure Sun Cluster Software for information about the metasets that were created by SunPlex Installer.
To create a Solaris Volume Manager for Sun Cluster disk set for use by Oracle Real Application Clusters, do not use these procedures. Instead, perform the procedures in Creating a Multi-Owner Disk Set in Solaris Volume Manager for Sun Cluster for the Oracle Real Application Clusters Database in Sun Cluster Data Service for Oracle Real Application Clusters Guide for Solaris OS.
The following table lists the tasks that you perform to create disk sets.
Table 3–2 Task Map: Installing and Configuring Solstice DiskSuite or Solaris Volume Manager Software
Task |
Instructions |
---|---|
1. Create disk sets by using the metaset command. | |
2. Add drives to the disk sets. | |
3. (Optional) Repartition drives in a disk set to allocate space to slices 1 through 6. | |
4. List DID pseudo-driver mappings and define metadevices or volumes in the /etc/lvm/md.tab files. | |
5. Initialize the md.tab files. |
Perform this procedure to create disk sets.
(Solaris 8 or Solaris 9) Determine whether, after you create the new disk sets, the cluster will have more than three disk sets.
If the cluster will have no more than three disk sets, skip to Step 9.
If the cluster will have four or more disk sets, proceed to Step 2 to prepare the cluster. You must perform this task whether you are installing disk sets for the first time or whether you are adding more disk sets to a fully configured cluster.
If the cluster runs on the Solaris 10 OS, Solaris Volume Manager automatically makes the necessary configuration changes. Skip to Step 9.
On any node of the cluster, check the value of the md_nsets variable in the /kernel/drv/md.conf file.
If the total number of disk sets in the cluster will be greater than the existing value of md_nsets minus one, increase the value of md_nsets to the desired value.
The maximum permissible number of disk sets is one less than the configured value of md_nsets. The maximum possible value of md_nsets is 32, therefore the maximum permissible number of disk sets that you can create is 31.
Ensure that the /kernel/drv/md.conf file is identical on each node of the cluster.
Failure to follow this guideline can result in serious Solstice DiskSuite or Solaris Volume Manager errors and possible loss of data.
If you made changes to the md.conf file on any node, perform the following steps to make those changes active.
On each node in the cluster, run the devfsadm(1M) command.
You can run this command on all nodes in the cluster at the same time.
From one node of the cluster, run the scgdevs(1M) command to update the global-devices namespace.
On each node, verify that the scgdevs command has completed processing before you attempt to create any disk sets.
The scgdevs command calls itself remotely on all nodes, even when the command is run from just one node. To determine whether the scgdevs command has completed processing, run the following command on each node of the cluster.
% ps -ef | grep scgdevs |
Ensure that the disk set that you intend to create meets one of the following requirements.
If the disk set is configured with exactly two disk strings, the disk set must connect to exactly two nodes and use exactly two mediator hosts. These mediator hosts must be the same two hosts used for the disk set. See Configuring Dual-String Mediators for details on how to configure dual-string mediators.
If the disk set is configured with more than two disk strings, ensure that for any two disk strings S1 and S2, the sum of the number of drives on those strings exceeds the number of drives on the third string S3. Stated as a formula, the requirement is that count(S1) + count(S2) > count(S3).
Ensure that the local state database replicas exist.
For instructions, see How to Create State Database Replicas.
Become superuser on the cluster node that will master the disk set.
Create the disk set.
The following command creates the disk set and registers the disk set as a Sun Cluster disk device group.
# metaset -s setname -a -h node1 node2 |
Specifies the disk set name
Adds (creates) the disk set
Specifies the name of the primary node to master the disk set
Specifies the name of the secondary node to master the disk set
When you run the metaset command to configure a Solstice DiskSuite or Solaris Volume Manager device group on a cluster, the command designates one secondary node by default. You can change the desired number of secondary nodes in the device group by using the scsetup(1M) utility after the device group is created. Refer to Administering Disk Device Groups in Sun Cluster System Administration Guide for Solaris OS for more information about how to change the numsecondaries property.
Verify the status of the new disk set.
# metaset -s setname |
The following command creates two disk sets, dg-schost-1 and dg-schost-2, with the nodes phys-schost-1 and phys-schost-2 specified as the potential primaries.
# metaset -s dg-schost-1 -a -h phys-schost-1 phys-schost-2 # metaset -s dg-schost-2 -a -h phys-schost-1 phys-schost-2 |
Add drives to the disk set. Go to Adding Drives to a Disk Set.
When you add a drive to a disk set, the volume management software repartitions the drive as follows so that the state database for the disk set can be placed on the drive.
A small portion of each drive is reserved in slice 7 for use by Solstice DiskSuite or Solaris Volume Manager software. The remainder of the space on each drive is placed into slice 0.
Drives are repartitioned when they are added to the disk set only if slice 7 is not configured correctly.
Any existing data on the drives is lost by the repartitioning.
If slice 7 starts at cylinder 0, and the drive partition is large enough to contain a state database replica, the drive is not repartitioned.
Ensure that the disk set has been created. For instructions, see How to Create a Disk Set.
Become superuser on the node.
List the DID mappings.
# scdidadm -L |
Choose drives that are shared by the cluster nodes that will master or potentially master the disk set.
Use the full device-ID path names when you add drives to a disk set.
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). A shared drive has more than one entry for the same DID instance number.
In the following example, the entries for DID instance number 2 indicate a drive that is shared by phys-schost-1 and phys-schost-2, and the full device-ID path name is /dev/did/rdsk/d2.
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 … |
Become owner of the disk set.
# metaset -s setname -t |
Specifies the disk set name
Takes ownership of the disk set
Add the drives to the disk set.
Use the full device-ID path name.
# metaset -s setname -a drivename |
Adds the drive to the disk set
Full device-ID path name of the shared drive
Do not use the lower-level device name (cNtXdY) when you add a drive to a disk set. Because the lower-level device name is a local name and not unique throughout the cluster, using this name might prevent the metaset from being able to switch over.
Verify the status of the disk set and drives.
# metaset -s setname |
The metaset command adds the drives /dev/did/rdsk/d1 and /dev/did/rdsk/d2 to the disk set dg-schost-1.
# metaset -s dg-schost-1 -a /dev/did/rdsk/d1 /dev/did/rdsk/d2 |
To repartition drives for use in metadevices or volumes, go to How to Repartition Drives in a Disk Set.
Otherwise, go to How to Create an md.tab File to define metadevices or volumes by using an md.tab file.
The metaset(1M) command repartitions drives in a disk set so that a small portion of each drive is reserved in slice 7 for use by Solstice DiskSuite or Solaris Volume Manager software. The remainder of the space on each drive is placed into slice 0. To make more effective use of the drive, use this procedure to modify the disk layout. If you allocate space to slices 1 through 6, you can use these slices when you set up Solstice DiskSuite metadevices or Solaris Volume Manager volumes.
Become superuser on the cluster node.
Use the format command to change the disk partitioning for each drive in the disk set.
When you repartition a drive, you must meet the following conditions to prevent the metaset(1M) command from repartitioning the drive.
Create slice 7 starting at cylinder 0, large enough to hold a state database replica. See your Solstice DiskSuite or Solaris Volume Manager administration guide to determine the size of a state database replica for your version of the volume-manager software.
Set the Flag field in slice 7 to wu (read-write, unmountable). Do not set it to read-only.
Do not allow slice 7 to overlap any other slice on the drive.
See the format(1M) man page for details.
Define metadevices or volumes by using an md.tab file. Go to 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 disk sets that you created.
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 disk sets. For example, if the device-ID name /dev/did/dsk/d3 is used in a disk set, 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#.
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 (cN tXdY).
# 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.
If you have existing data on the 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.
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.
See your Solstice DiskSuite or Solaris Volume Manager documentation and the md.tab(4) man page for details about how to create an md.tab file.
The following sample md.tab file defines the disk set 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 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 sample md.tab file is constructed as follows.
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 |
Activate the metadevices or volumes that are defined in the md.tab files. Go to How to Activate Metadevices or Volumes.
Perform this procedure to activate Solstice DiskSuite metadevices or Solaris Volume Manager volumes that are defined in md.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 disk set on the node where the command will be executed.
Take ownership of the disk set.
# scswitch -z setname -h node |
Specifies the disk set name
Specifies the node that takes ownership
Activate the disk set's metadevices or volumes, which are defined in the md.tab file.
# metainit -s setname -a |
Specifies the disk set name
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 manually.
# metattach mirror submirror2 |
Repeat Step 3 through Step 6 for each disk set in the cluster.
If necessary, run the metainit(1M) command from another node that has connectivity to the drives. This step is required for cluster-pair topologies, where the 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.
In the following example, all metadevices that are defined in the md.tab file for disk set 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 |
If your cluster contains disk sets that are configured with exactly two disk enclosures and two nodes, add dual-string mediators. Go to Configuring Dual-String Mediators.
Otherwise, go to How to Create Cluster File Systems to create a cluster file system.
This section provides information and procedures to configure dual-string mediator hosts. Dual-string mediators are required for all Solstice DiskSuite or Solaris Volume Manager disk sets that are configured with exactly two disk strings and two cluster nodes. 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.
A dual-string mediator, or mediator host, is a cluster node that stores mediator data. Mediator data provides information about the location of other mediators and contains a commit count that is identical to the commit count that is 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.
A disk string consists of a disk enclosure, its physical drives, cables from the enclosure to the node(s), and the interface adapter cards.
The following table lists the tasks that you perform to configure dual-string mediator hosts.
Table 3–3 Task Map: Installing and Configuring Solstice DiskSuite or Solaris Volume Manager Software
Task |
Instructions |
---|---|
1. Configure dual-string mediator hosts. | |
2. Check the status of mediator data. | |
3. If necessary, fix bad mediator data. |
The following rules apply to dual-string configurations that use mediators.
Disk sets must be configured with exactly two mediator hosts. Those two mediator hosts must be the same two cluster nodes that are used for the disk set.
A disk set cannot have more than two mediator hosts.
Mediators cannot be configured for disk sets 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 disk sets 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.
Perform this procedure if your configuration requires dual-string mediators.
Become superuser on the node that currently masters the disk set to which you intend to add mediator hosts.
Add each node with connectivity to the disk set as a mediator host for that disk set.
# metaset -s setname -a -m mediator-host-list |
Specifies the disk set name
Adds to the disk set
Specifies the name of the node to add as a mediator host for the disk set
See the mediator(7D) man page for details about mediator-specific options to the metaset command.
The following example adds the nodes phys-schost-1 and phys-schost-2 as mediator hosts for the disk set dg-schost-1. Both commands are run from the node phys-schost-1.
# metaset -s dg-schost-1 -a -m phys-schost-1 # metaset -s dg-schost-1 -a -m phys-schost-2 |
Check the status of mediator data. Go to How to Check the Status of Mediator Data.
Ensure that you have added mediator hosts as described in How to Add Mediator Hosts.
Display the status of the mediator data.
# medstat -s setname |
Specifies the disk set name
See the medstat(1M) man page for more information.
If Bad is the value in the Status field of the medstat output, repair the affected mediator host.
Go to How to Fix Bad Mediator Data.
Go to How to Create Cluster File Systems to create a cluster file system.
Perform this procedure to repair bad mediator data.
Identify all mediator hosts with bad mediator data as described in the procedure How to Check the Status of Mediator Data.
Become superuser on the node that owns the affected disk set.
Remove all mediator hosts with bad mediator data from all affected disk sets.
# metaset -s setname -d -m mediator-host-list |
Specifies the disk set name
Deletes from the disk set
Specifies the name of the node to remove as a mediator host for the disk set
Restore each mediator host that you removed in Step 3.
# metaset -s setname -a -m mediator-host-list |
Adds to the disk set
Specifies the name of the node to add as a mediator host for the disk set
See the mediator(7D) man page for details about mediator-specific options to the metaset command.
Create cluster file systems. Go to How to Create Cluster File Systems.