| Sun StorageTek SAM Archive Configuration and Administration Guide |    
|
| Sun StorageTek SAM Archive Configuration and Administration Guide |
|
| C H A P T E R 8 |
|
Advanced Topics |
This chapter discusses advanced topics that are beyond the scope of basic system administration and usage.
This chapter contains the following sections.
High availability Sun StorageTek SAM (HA-SAM) is an interface between a SAM-QFS file system and Sun Cluster software running on Solaris
for SPARC® and x64 hardware (Solaris 9 and 10 are supported on SPARC, and only Solaris 10 is supported on x64). The HA-SAM Sun Cluster agent periodically monitors the health of Sun StorageTek SAM operations on the primary node. In the event of an unrecoverable problem it switches the Sun StorageTek SAM archiving and staging operations to a healthy node. Both voluntary and involuntary failover are supported on active-passive configurations. Only two-node active-passive configurations are supported.
For tape archiving and staging to continue after failover, tape drives must be visible to all nodes in a cluster on which HA-SAM is running, but they should not be configured as Sun StorageTek SAM shared drives. HA-SAM also supports disk archiving with disk archives visible to all nodes in a cluster.
HA-SAM depends on the Sun StorageTek QFS Sun Cluster agent and assumes that the Sun StorageTek QFS file systems are mounted and managed by the Sun StorageTek QFS agent. HA-SAM requires that the Sun StorageTek SAM catalog and stager directories be linked from the standard location to a directory in a HAStoragePlus file system. HA-SAM should be a resource in a resource group that contains Sun StorageTek QFS and catalog resources.
In order to configure the HA-SAM Sun Cluster agent, the Sun StorageTek QFS Sun Cluster agent must already be configured. These instructions assume that you have Sun StorageTek QFS configured in a Sun Cluster environment using a shared Sun StorageTek QFS file system as described in the Sun StorageTek QFS Installation and Upgrade Guide and the Sun StorageTek QFS File System Configuration and Administration Guide.
|
Note - HA-SAM is available only with Sun StorageTek SAM and Sun StorageTek QFS software versions 4U6 and later. |
The following are requirements and restrictions that you should be aware of before configuring this feature.
Before configuring HA-SAM, you must configure the following extension properties using the Sun Cluster scrgadm command:
|
Note - See the Sun Cluster administration guide for more details on using the scrgadm command. |
Use the following command to verify that SUNWhasam Resource Type Registration (RTR) file is linked correctly:
# ls -l /usr/cluster/lib/rgm/rtreg/SUNW.hasam lrwxrwxrwx 1 root other 32 Feb 26 10:59 /usr/cluster/lib/rgm/rtreg/SUNW.hasam -> /opt/SUNWsamfs/sc/etc/SUNW.hasam |
In order to configure for high availability, the SAM-QFS catalog and stager queues must be in an HAStoragePlus file system. During the software installation process symbolic links should have been created from /var/opt/SUNWsamfs to the shared HAStoragePlus file system. This must be confirmed before continuing with the configuration process.
Verify that the /var/opt/SUNWsamfs/catalog and /var/opt/SUNWsamfs/stager contain a symbolic link to the HAStoragePlus mount point.
a. View the catalog and stager files.
b. Verify that the output shows symbolic links similar to the following example.
lrwxrwxrwx 1 root other 19 Sep 30 11:05 /var/opt/SUNWsamfs/catalog -> /sam_shared/catalog lrwxrwxrwx 1 root other 18 Sep 30 11:05 /var/opt/SUNWsamfs/stager -> /sam_shared/stager |
If the symbolic links exist, proceed to To Configure Sun StorageTek SAM in a Sun Cluster Environment. If the links do not exist, proceed to Step c.
c. Copy any existing Sun StorageTek SAM catalog information to a temporary location.
d. Delete the existing catalog and stager files from their current location.
e. Create the /var/opt/SUNWsamfs/catalog and /var/opt/SUNWsamfs/stager symbolic links to the HAStoragePlus mount point.
The following example is for an HAStoragePlus file system mounted at /sam_shared.
# ln -s /sam_shared/catalog /var/opt/SUNWsamfs/catalog # ln -s /sam_shared/stager /var/opt/SUNWsamfs/stager |
f. Copy the catalog information saved in Step c to the new shared catalog.
|
|
In this example procedure, two file systems are configured: qfs1 and qfs2.
1. Create an HA-SAM resource group.
2. Create and configure the SUNW.qfs resource.
3. Create and configure a Sun StorageTek SAM shared resource.
# scrgadm -a -j sam-hastp -g SAM-HA -t SUNW.HAStoragePlus \ -x FilesystemMountPoints=/sam_shared -x AffinityOn=TRUE |
4. Create the HA-SAM resource type.
5. Create and configure the SUNW.hasam resource.
# scrgadm -a -g SAM-HA -t SUNW.hasam -j sam-ha \ -x QFSName=qfs1,qfs2 -x CatalogFileSystem=/sam_shared |
6. Create dependencies between resources within the resource group.
# scrgadm -c -j qfs-res -y Resource_dependencies=sam-hastp # scrgadm -c -j sam-ha -y Resource_dependencies=qfs-res |
7. Use the scswitch(1M) -Z -g command to bring the resource group online.
|
Note - The Sun StorageTek QFS file systems must be mounted before bringing the resource group online. |
8. Ensure that the resource group is functional on all configured nodes.
The samd command has an option that is specifically for use with HA-SAM. The samd hastop command stops the archiver and stager daemons before stopping sam-amld and its children.
The samd hastop command must not be used by an administrator in either a stand-alone or shared Sun StorageTek SAM environment. In addition, the normal samd stop command must not be used on nodes under HA-SAM control.
If you are using Sun StorageTek libraries in an HA-SAM environment, the STK daemons need to be notified to use a forced dismount instead of a normal dismount in the case of an involuntary failover. To accomplish this, the /var/run/hasam_running file is created on the active Sun Cluster node when the HA-SAM resource is brought online. This is a zero-byte file with root permissions. If this file is detected on a node, sam-stkd and sam-stk_helper use force_media to dismount the tape on the drive. This allows the successful initialization of the library and the drives after an involuntary failover. The hasam_running file is deleted when SAM resource is brought offline on a node.
In order to ensure the correct failover behavior for Sun StorageTek libraries, make sure the /var/run/hasam_running is not deleted if found on a Sun Cluster node that has an HA-SAM resource online.
The device-logging facility provides device-specific error information that you can use to analyze certain types of device problems. It can help to determine a failing sequence of events for an automated library, tape drive, or optical drive. The device-logging facility does not collect soft media errors (such as recoverable read errors).
Device-logging messages are written to individual log files. There is a log file for each automated library, for each tape and optical drive device, and one for the historian. The log files are located in /var/opt/SUNWsamfs/devlog. The name of each log file corresponds to the name of the equipment ordinal.
For example, assume that you have a Sun StorageTek SAM file system and a single Hewlett Packard optical library with two optical drives.
CODE EXAMPLE 8-1 shows the mcf file.
/dev/samst/c1t5u0 40 hp hp40 - etc/opt/SUNWsamfs/hp40_cat /dev/samst/c1t4u0 41 mo hp40 - /dev/samst/c1t6u0 42 mo hp40 - |
CODE EXAMPLE 8-2 shows the /var/opt/SUNWsamfs/devlog file.
The device log can easily generate many log messages, especially when all logging options for all devices are turned on and there is a great deal of device activity. Initially, the device log settings are set to the following default values:
If you suspect there is a problem with one of the devices configured within a Sun StorageTek SAM environment, it is appropriate to enable additional logging events for that device. Also, it is appropriate to enable device logging if you are advised to do so by your service provider. In these situations, set the event to detail. In extreme cases, you might be advised by your service provider to set the event to all for a device. This adds additional log information. However, in general, it is probably not useful or practical to run the system with excessive logging.
The device log information is collected automatically when the samexplorer(1M) command is issued. This allows the file system service to review any possible device error information as part of problem analysis activity.
You can enable the device log in one of two ways, as described in the following subsections:
For eq, specify the equipment ordinal of the device for which you want to log messages.
For event, specify one or more of the events listed in the samset(1M) man page. If you specify more than one event, separate them with space characters.
2. Use vi(1) or another editor to open file /etc/opt/SUNWsamfs/defaults.conf.
3. Add the devlog directive in the defaults.conf file.
For eq, specify the equipment ordinal of the device for which you want to log messages.
For event, specify one or more of the events listed in the samset(1M) man page. If you specify more than one event, separate them with space characters.
When a Sun StorageTek SAM file system starts up, it automatically sets the event type for each available device to default. You can also use the samset(1M) command to determine the present settings for each device log.
4. Save and close the defaults.conf file.
5. Use the samd(1M) config command to propagate the defaults.conf file changes.
You can use the request(1) command to manually create, write, and read files that do not use the disk cache for buffering the data. Files created in this manner are called removable media files.
|
Note - The request(1) command bypasses the typical functions of the archiver. |
Removable media files look like typical Sun StorageTek SAM files in that they have permissions, a user name, a group name, and size characteristics. However, their data does not reside in the disk cache. Thus, you can create removable media files that are larger than the disk cache and write them to removable media cartridges.
The system creates an inode entry in the .inodes file for the file that you specify on the request(1) command. The Sun StorageTek SAM file systems read that information from the inode entry. Multiple removable media files can reside on the same volume.
If a removable media file spans multiple volumes, it is called a volume overflow file. The volume overflow feature enables a single large file to span multiple volumes on multiple cartridges. The volume overflow feature is useful if you have very large files that exceed the capacity of their chosen media.
You must read and write removable media files sequentially. The Sun StorageTek SAM file system automatically mounts the requested volume if the volume resides in an automated library defined in the mcf file.
The presence of a removable media file on a volume prevents that volume from being recycled. The recycler expects that only archived files reside on the particular volume that is assigned for archiving. In addition, removable media files are never archived. Removable media files are not supported over NFS.
|
1. Use the tplabel(1M) or odlabel(1M) command to label a tape or magneto-optical cartridge, respectively.
For information on these commands, see their respective man pages.
2. Use the request(1) command.
At a minimum, use the following options:
The following command creates a removable media file:
The following command creates a volume overflow file on three volumes:
For detailed examples of how to create removable media files, see the request(1) man page.
The Sun StorageTek SAM environment supports segmented files. Segmenting files improves tape storage retrieval speed, access, and manageability for very large files. A segmented file can be larger than the physical disk cache. It is possible for only part of a segmented file to reside on the disk cache at any one time.
The segment(1) command enables you to specify the segment size. You cannot set a segment size that is smaller than the current file size.
Segmented files support tape striping. After a file is segmented, it can be striped simultaneously over multiple tape devices, which significantly reduces the time needed to store the file segments. Data access is accelerated by allowing users to retrieve only the desired file segments rather than the entire file.
Segmentation can enhance archiving efficiency because only changed portions of a file are rearchived. Segments of a file can be archived in parallel, and segmented files can be staged in parallel. This increases performance during archiving and retrieving.
Segmentation can be enabled on a file, directory, or entire file system. Segmented files support all other Sun StorageTek SAM capabilities.
|
Note - The mmap function cannot take place on a segmented file. Because of this, a segmented file cannot be an executable binary. |
The following sections describe how segmented files differ from nonsegmented files. For more information about segmented files, see the segment(1) or the sam_segment(3) man pages.
For a segmented file, the archivable unit is the segment itself, not the file. All archiving properties and priorities apply to the individual segments, and not to the file.
You can stripe a segment by specifying both the -drives and -drivemin parameters for the archive set in the archiver.cmd file. For example, assume that there is a 100-megabyte segmented file in the file system and that its segment size is 10 megabytes. If the archiver.cmd file defines an archive set with a -drives 2 directive, this file is archived to two drives in parallel. Segments 1, 3, 5, 7, and 9 are archived using the first drive, and segments 2, 4, 6, 8, and 10 are archived using the second drive.
Only segments that have been modified are archived. Up to four archive copies can be made for each segment. Sun StorageTek SAM also supports volume overflow for segments.
|
Note - The index of a segmented file contains no user data. It is considered metadata and is assigned to the file system archive set. |
For information about recovering a segmented file in the event of a disaster, see the Sun StorageTek Storage Archive Manager Troubleshooting Guide.
The system error facility (SEF) reporting system captures log sense data from tape devices in an automated library, writes it to a log file, and translates it into human-readable form. It consists of the following:
The log sense pages differ from vendor to vendor. For the meanings of the parameter codes, control bits, and parameter values, see the vendor documentation for each specific device.
SEF is not supported for stand-alone tape drives. SEF reporting is most useful for older SCSI-2 devices that do not support the tapealert(1M) functionality. For more information, see the tapealert(1M) man page.
|
2. Use the mkdir(1) command to create the SEF directory.
3. Use the touch(1) command to create the log file.
You can enable SEF reporting any time after installation by creating the sefdata log file. Initially, the SEF log file must be empty.
The following command shows the SEF log file being created in the default location.
4. Use the samd(1M) stop and samd(1M) start to initialize SEF reporting.
SEF data is appended to the log file as it is generated.
|
Note - SEF reporting is enabled as long as the sefdata log file exists. To disable SEF reporting, you must rename or remove this file. |
You can configure SEF reporting to log and read log sense data from an alternate location. For more information about reading log sense data from an alternate location, see the sefreport(1M) man page.
|
Before you use the sefreport(1M) command, ensure that /opt/SUNWsamfs/sbin is in your command path. The SEF report output consists of header lines and log sense data.
Use the sefreport(1M) command to generate SEF output.
The following are the most commonly used options with the sefreport(1M) command:
The -v option generates information in verbose mode. It appends information regarding the equipment ordinal, page code, and VSN to each line of a record. This makes it possible to select only those lines that pertain to a specific device or a specific volume.
The -t option generates log sense output with text descriptions. For each line of log sense data output, the report includes an additional string containing the equipment ordinal, page code, VSN, and parameter code description.
Do not specify the -t and -v options on the same command line. They are mutually exclusive.
For example, the following SEF command reads the SEF log file from the default location, writes the device number and path name for each device, and generates output:
CODE EXAMPLE 8-3 shows the content of sef.output file.
For more information about the SEF log file, including its content and format, see the sefdata(4) man page. For more information about optional SEF report formats, see the sefreport(1M) man page.
You manage the SEF log file just as you manage any other Sun StorageTek SAM log file. You can run a cron(1) job periodically to save the current log file to another location, to delete old SEF files, to create new (empty) SEF files, or to perform other file management tasks.
You can also use the log_rotate.sh(1M) utility to rotate this log file.
For more information about tools for managing the SEF log file, see the cron(1) or log_rotate.sh(1M) man pages.
In addition to using the SEF log file, you can use the Solaris sysevent feature to obtain tape drive SCSI log sense error counter pages 2 and 3 for media analysis. By default, the SEF sysevent feature is enabled and set to poll once before unload. The SEF sysevent behavior is controlled by defaults.conf and samset.
In the defaults.conf file, the sef parameter can be used to enable SEF sysevent feature by equipment ordinal, or to specify the log sense polling frequency. For more information, see the defaults.conf(4) manu page.
1. Create the /var/tmp/xx file similar to the following:
#!/bin/ksh
echo "$@" >> /var/tmp/xx.dat
exit 0
2. Make the /var/tmp/xx file executable:
3. Add the SEF sysevent handler to the syseventd file by typing the following:
# syseventadm add -vSUNW -pSUNWsamfs -cDevice -sSEF /var/tmp/xx \"\$VENDOR\" \"\$PRODUCT\" \"\$USN\" \"\$REV\" \$TOD \$EQ_ORD \"\$NAME\" \$INQ_TYPE \"\$MEDIA_TYPE\" \"\$VSN\" \$LABEL_TIME \$LP2_PC0 \$LP2_PC1 \$LP2_PC2 \$LP2_PC3 \$LP2_PC4 \$LP2_PC5 \$LP2_PC6 \$LP3_PC0 \$LP3_PC1 \$LP3_PC2 \$LP3_PC3 \$LP3_PC4 \$LP3_PC5 \$LP3_PC6 \$WHERE \$sequence
This command creates the /etc/sysevent/config/SUNW,SUNWsamfs,Device,sysevent.conf file containing the SEF sysevent handler /var/tmp/xx and loads the event handler into the syseventd daemon.
4. To load the SEF sysevent handler, use the command pkill -HUP syseventd to activate the /var/tmp/xx SEF sysevent handler.
For more information about SEF sysevent usage, see the sefsysevent(4) man page.
| Sun StorageTek SAM Archive Configuration and Administration Guide | 819-7931-10 |
|
Copyright © 2007, Sun Microsystems, Inc. All Rights Reserved.
To Verify the SUNWhasam Resource Type Registration File