This chapter describes how to set up and configure OpenVault, as well how to perform some basic management tasks. The sections in this chapter are:
“OpenVault Configuration Files” describes configuration files.
“Administering OpenVault ”, describes how to administer OpenVault.
“Monitoring OpenVault”, describes how to monitor OpenVault.
OpenVault uses configuration files to initiate a communication session between device components on OpenVault clients and server. Configuration files are automatically created by the OpenVault ov_admin script, and contain information to bootstrap pieces of the system into full functionality. Once the various components have booted, the OpenVault server controls and manages clients and their components.
The following list defines terms used for OpenVault setup and administration:
OpenVault configuration files are described in detail in the following sections.
When first configuring OpenVault, login to the OpenVault server system as superuser and run ov_admin , with its menu-based interface that helps guide you. For more information about setup procedures, see Chapter 2, “Installing OpenVault”.
The OpenVault server configuration is stored in the /var/opt/openvault/server/config/config file.
OpenVault client software must run on all systems where OpenVault-managed drives and libraries are attached, in particular on systems not designated as the OpenVault server. These non-server systems are called OpenVault clients.
If you want to implement security, an authorization key must be created, as described in “Setting Up Security”. Client security keys are part of their library, drive, and application configuration files. They are not in a separate file by themselves.
Each drive needs its own drive control program (DCP) and configuration description, located in the /var/opt/openvault/client/dcp/*/*/config file. A drive-specific DCP should be installed using the standard OpenVault installation procedure.
For DCPs that are provided by SGI, DCP installation produces an interactive ov_admin script that requests the configuration information that is necessary to create the configuration file. For DCPs supplied by other venders, consult their documentation.
The ov_admin script asks similar questions as for configuration of the OpenVault server, but limited to information needed for drive and DCP configuration.
Each library needs its own library control program (LCP) and configuration description, located in the /var/opt/openvault/clients/lcp/*/*/config file. A library-specific LCP should be installed using the standard OpenVault installation procedure.
For LCPs that are supplied by SGI, LCP installation produces an interactive ov_admin script that requests the configuration information that is necessary to create the configuration file. For LCPs supplied by other venders, consult their documentation.
The ov_admin script asks similar questions as for configuration of the OpenVault server, but limited to information needed for library and LCP configuration.
The ov_admin script asks you questions for configuring and storing the hostname of the OpenVault server used for the TCP interface. If you want to implement security, the application's OpenVault password must also be given. For details, see “Setting Up Application Security”.
An ASCII authorization key file must be created on each AAPI/CAPI client and server system, and the client must be configured to use Open Vault with each key file. The authorization key file uses a shared secret--the client and server share a secret password. The server has one key file (/var/opt/openvault/server/config/core_keys ) containing the passwords of each of the clients it knows about (drives, libraries, and applications). The clients each have an authorization key file listing the servers it knows about.
Example 4-1 shows a key file that can be used on either a client or a server.
Example 4-1. Client and Server Key Authorization File
#Host Client Instance Language Key moon System OnlyInstance AAPI a4sum moon Robbie one ALI a2by4 moon Herbie alpha ADI gr8day earth networker * CAPI un2 |
The meanings for each column in the key authorization file are described in Table 4-1.
Table 4-1. Key Authorization File Description
Column Title | Description |
|---|---|
Host | IP hostname of the system that communicates with this system. If this is a CAPI client, give the OpenVault server hostname. If this is the OpenVault server, give the IP hostname of the client running the application. |
Client | Name of the application. |
Language | The language used for the connection, either AAPI, CAPI, ADI, or ALI. |
Key | A password used to secure the connection, or “none” for no security. |
On the server host, the shared secret key is stored in /var/opt/openvault/server/config/core_keys.
 | Note: Non-robotic libraries are not supported in the OpenVault releases 1.x. |
Non-robotic libraries are controlled and manipulated by a human operator rather than by a robotics interface. Organization of your cartridges is key to keeping your library accessible and usable. OpenVault can help by tracking the location of cartridges within a library. Assigning cartridges to a bay can further pinpoint cartridge location.
A bay is a storage location within the library. In the case of robotic libraries, bays can be a range of slots, a removable tray, or a storage silo. In the case of non-robotic libraries, a bay could be a bookshelf, a file drawer, or a storage closet. In these examples, a bookcase, file cabinet, or hallway is the library, partitioned into bays as you prefer.
Planning is important in determining how many bays and how many libraries are necessary for your storage needs. Be sure to plan adequate space to allow your library to grow and allow for further separation, based on detail (you may start with a “project,” but then add more bays for phase 1, phase 2, and so forth).
Another major difference with a manual library is the need for communications with the operator. OpenVault needs to send messages to the operator, via a terminal, to prompt for action, such as loading a cartridge or removing a cartridge. Be sure to put the terminal that the operator uses in a convenient location so that timely communication is possible.
| Note: Offsite libraries are not supported in the OpenVault releases 1.x. |
An offsite library is a special type of manual library, differing in that an offsite library has no drive. Storage bins (which can be referred to as bays) contain the cartridges. OpenVault tracks the location of offsite storage cartridges. If a cartridge is needed from an offsite storage area, it must manually be located and moved into another library (see “Moving Cartridges within Libraries” in Chapter 5). The chosen library must contain a drive that is compatible with the cartridge type.
Once OpenVault has been set up, as described in “OpenVault Configuration Files”, you can start to configure it to meet your storage management needs. This section describes some basic configuration tasks, such as:
“Setting Logging Levels”setting logging levels.
“Registering Applications”, registering applications.
“Unregistering Applications”, unregistering applications.
“Setting Up Application Security”, setting up application security.
“Enabling Application Access to a Drive”, enabling application access to a drive.
“Managing Cartridge Groups”, managing cartridge groups.
“Introducing Cartridges”, introducing cartridges.
setenv OVSERVER hostname
If you want to use a different server, use the -S command-line option to specify another server (-S newOVserver). This overrides the OVSERVER environment variable.
You can configure the degree of system status reporting and message logging that you want to have. By default, system message logging sends all error messages to the file /var/opt/openvault/server/logs/OVLOG. yyyymmdd. Example 4-2 shows how to set the “information” log level.
Example 4-2. information Log Level
To set logging level to the information level:
ov_msg -s -t core -m information |
See the ov_msg(1M) man page for details and “Accessing OpenVault Messages” in Appendix A, for message log information.
Internally OpenVault keeps time in UCT (universal coordinated time, also called GMT) and writes UCT timestamps into the message log file. The administrative commands translate UCT into the client's local time zone when displaying time values.
Applications are client programs that can read data from or write data to (or both) removable media after OpenVault has found and mounted the desired media element. Reads and writes are performed using POSIX standard I/O facilities.
Applications can be added to (registered with) the OpenVault system at any time without the need to take OpenVault offline or perform a software upgrade. Registering an application introduces it to the OpenVault system so resources can be allocated for its use.
An authorization key, or password, can be added when registering an application to ensure secure transactions; see “Setting Up Application Security”. Unless an application is registered, it cannot connect to the OpenVault server. To register an application, use the Manage Applications option from the ov_admin OpenVault Configuration Menu.
Unregistering an application from the OpenVault system means the application can no longer connect to OpenVault. To unregister an application, use the Manage Applications option from the ov_admin OpenVault Configuration Menu.
Application security setup is similar to client security setup. Setting up an application with an authorization key ensures that, without the security key, no other application can connect to OpenVault masquerading as the originally authorized application.
As shown in the first and last lines of Example 4-1, the application name is used as a Client for the OpenVault server, which is named as the Host. The first line is an example that secures the OpenVault administrative tools and the last line is an example that secures the IRIX Networker application. The middle two lines appear only in the server keyfile and describe options for a library named moon and a drive named “moon”.
The key that is assigned in the key authorization file, also known as the password, must already exist in the configuration file for the application. See “Applications Configuration”, for details on setting up his file.
A drive is in exactly one drive group. Each application can be given access to one or more drive groups (all drives in a group). The ov_admin command can be used to enable a drive for a specific application, allowing the application to run on the drive. The Manage Drive Groups option of the ov_admin command allows the user to create a drive group, reassign a drive to another group, grant an application access to a drive group, and perform other related functions.
When using ov_admin to grant an application access to a drive group, one of the parameters you are asked to enter is the priority for the application's use of the drive group. OpenVault can be configured so an application will prefer to use drives in certain drive groups over drives in other groups. A priority is given to the application's use of each drive group and those priorities are used to sort the available drives into preference order. A higher priority number means that the application will prefer that drive group, while a lower number means that the application will prefer not to use that drive group.
Cartridge groups allow sets of cartridges to be allocated for specific applications or purposes. You may want to do this, for example, based on the capacity of the cartridge or its content (for example, the existing data on the cartridge is related to other cartridges in the group). Creating cartridge groups helps you organize your media and fulfills the demands of the application for available storage.
Figure 4-1 shows an environment with several cartridge groups.
Cartridges move in and out of groups (shown by the arrows) based upon demands made by the application or by their place in the media life cycle (see “Preventative Maintenance” in Chapter 7). The cartridge groups in the figure are Void, Unallocated, and Degauss.
| Void | A set of cartridges whose labels are not in the OpenVault library. This is a holding place until you move the cartridge to another group, such as Scratch, or find out why the catalog entry for the cartridge is missing. |
| Unallocated | A set of unallocated cartridges that are available for allocation by any application. These cartridges have been introduced into the OpenVault system and are ready to be allocated to some application. |
| Degauss | A set of cartridges that are ready to be demagnetized or destroyed. Cartridges are demagnetized to ensure all data is destroyed. Some of these cartridges may need to be terminated if they are approaching the end of their media life span. |
| Full | IRIX NetWorker manages this set of cartridges. When a volume fills up, NetWorker marks it as full and holds it for a specified retention period. |
| Recyclable | IRIX NetWorker manages this set of cartridges, too. When the retention period expires and its cycle ends, a volume is marked for recycling. |
Before setting up a cartridge group, plan where the group will reside and which drives or applications need to access it. Does the cartridge group require high throughput or high availability? Consider the network environment and any limitations it may impose when deciding where to locate the group. Consider the drives that will be servicing the group. What advantages or limitations do they impose? Also consider the growth potential for your storage requirements and choose a library that is adequate for its needs both now and for its projected future.
To create a cartridge group, follow the steps in Procedure 4-1.
Procedure 4-1. Creating a Cartridge Group
Be sure you have registered the application that will manage this group. See “Registering Applications”, for details.
Determine whether to assign drives to the application. If you decide to do so, see “Enabling Application Access to a Drive”, for details.
Create the cartridge group. The Manage Cartridge Groups menu item of the ov_admin command is the preferred way to create a cartridge group. The Manage Cartridge Groups menu option can also be used to grant an application access to the cartridge group.
Introduce cartridges into the cartridge group. Continue with the next section, “Introducing Cartridges”, for details.
If necessary, move cartridges between groups or within the library. The following sections describes situtions when you may need to move cartridges:
If a cartridge is no longer needed by an application, see “Removing Cartridges from Libraries” in Chapter 5.
If a cartridge can be moved back into the Unallocated group, see “Recycling Cartridges” in Chapter 5.
If a cartridge should go to the Degauss group for erasure, see “Destroying Cartridges” in Chapter 5.
If a cartridge needs to be moved within its own group, see “Moving Cartridges within Libraries” in Chapter 5.
Cartridges must be introduced into the OpenVault system before they can be used by an application. When a cartridge is introduced, an entry in the OpenVault catalog is created for the cartridge and the cartridge is assigned a cartridge ID. The entry, or cartridge ID, tracks information such as the PCL or bar code, application ID (if it's associated with an application), number of reads and writes, form factor, capacity, and so forth.
Client applications may choose their own names for cartridges. Because OpenVault client applications operate in separate name spaces, different applications may use the same name for different cartridges. Moreover, cartridges used by one application are not visible to or accessible from another application, unless the system administrator permits specific cartridges to be moved from one application to another.
Cartridges can be introduced in two ways, as shown in Figure 4-1:
Cartridges without data (including data that can be overwritten)
Cartridges containing data that is needed by an application (partition needed)
To introduce a cartridge without data, follow the steps in Procedure 4-2:
Procedure 4-2. Introducing a Cartridge without Data
To facilitate the cartridge identification, create its PCL by attaching a bar code or a label to the outside of the cartridge. The PCL is tracked in the catalog entry for this cartridge and is used as the default identification for the cartridge in most commands.
Signal the library to open its inject port so you can insert the cartridge. You must specify the library name (-l libraryName).
ov_inject -l libraryName
Create a new (ov_cart -n -T) cartridge entry in the OpenVault catalog so the cartridge can be recognized and accessed. The -B label gives the PCL affixed to the cartridge. Also, assign the cartridge to a cartridge group (-g cartridgeGroup ) so it can be used by an application needing a new cartridge:
ov_cart -n -B label -g cartridgeGroup -T cartridgeType
OpenVault checks its catalog to ensure the PCL is unique (new) and rejects the entry if that PCL already exists. Then ov_cart automatically creates sides on the cartridge, depending on the cartridgeType argument. The group name, form factor, media type, PCL and other identifying information are recorded in the OpenVault catalog for this cartridge.
Note: This command (ov_cart -n -T) is a good way to enter each new cartridge into the OpenVault system. Bulk insertion of cartridges into OpenVault may also be done using the ov_import command. Create a partition on side 1 of the cartridge.
ov_part -n -C cartridgeID -p partitionName -s SideA
To introduce a cartridge that already contains data, follow the steps in Procedure 4-3:
Procedure 4-3. Introducing a Cartridge with Data
Follow Procedure 4-2, for introducing cartridges without data, including step 5.
Create volumes for this cartridge. A volume allows the cartridge to be segmented so separate areas of the media can be used by an application:
ov_vol -n -v volumeName -a applicationName -C cartridgeID -p "PART 1" -s SideA
Use this command for each volume you are creating. OpenVault checks that the applicationName and volumeName combination is unique. Standard attributes are assigned to the volume and given default values if the values are not specified.
Note: This ov_import command optionally allows you to automatically create volume records for cartridges with data, in addition to creating the cartridge, side, and partition information for OpenVault.
You have now successfully introduced a cartridge and associated it with an application. Repeat this procedure for each new cartridge you are adding to the OpenVault system. You can now perform operations on the cartridge, as described in Chapter 5, “Operating OpenVault”.
Monitoring OpenVault helps you spot potential problems so that you can take appropriate action, and allows you to track the OpenVault system usage. If reconfiguration is necessary, it can be done before it becomes critical.
Probably most helpful in daily operations, monitoring can help you track the data you have on your media and where the media is located. The following subsections describe these monitoring tasks:
“Checking Server Status and Configuration”, describes checking server status.
“Checking Media Inventory”, describes checking media inventory.
“Listing Cartridge Information”, describes how to list cartridge information.
OpenVault can be monitored on several levels and to varying degrees of detail. From the general to the specific, some of the areas that can be monitored are:
OpenVault server status, including whether the server is up or down and by listing system error messages
Library status, including names, types, whether the library is up or down, and slotmaps (showing occupancy and reservations)
Drive status, including names, types, whether the drive is up or down, and cartridge occupancy
Libraries and drives without active LCPs and DCPs
Cartridge group status, including names of groups, number and names of cartridges in them
Names of registered applications
Cartridge status, including listing of all known cartridges, cartridge locations, and cartridge characteristics
Volume status, including cartridge ID and PCL, and the owning application
System messages, including by library, drive, and type (warning, error, operator)
Check the OpenVault man pages for a complete description of available commands and options (see Appendix B, “OpenVault Man Pages”, for a complete listing of man pages).
Using the ov_stat command to check the status of the OpenVault server allows you to view your system from a top-level viewpoint. Some things to check for are:
Check that the default server is up:
ov_stat
Check that a specific server is up:
ov_stat -S serverName
Show the task queue for the default server:
ov_stat -q
Display status of all items for the server, LCPs, DCPs, and applications:
ov_stat -a
Show configuration (-c) and drive ( -d) mode information for a drive:
ov_stat -D driveName -d -c Drive Mode Slot Type Cart Type Bit Format Capacity ... ...
Show library (-l), configuration ( -c), and slot map (-s) information for a library:
ov_stat -L libName -l -c -s Library Name Broken Disabled State LCP SoftState LCP HardState lib1 false false ready inactive ready ...
Note: A drive or library cannot spontaneously become Disabled. The system administrator disables a drive or library; it does not happen automatically.
If a library or drive fails an internal hardware diagnostic, its LCP or DCP can report the device as Broken. No currently shipping LCP or DCP does this, however.
The Access heading indicates whether the library believes it can mount and unmount cartridges in a particular drive. It is possible for a drive to be in perfect running order, but nonetheless unreachable by the library.
OpenVault tracks up to 8 status items for drives and libraries, as shown in Table 4-2.
Table 4-2. ov_stat Headings Explained
| Software | Hardware |
|---|---|---|
LCP | State of the LCP: “ready”, “not ready”, “disconnected”, “inactive”, or ”active”. | Always set to “ready”. |
DCP | State of the DCP: “ready”, “not ready”, “disconnected”, “inactive”, or ”active”. | DCP's view of the drive: “loaded”, “unloading”, “unloaded”, or “loading”. |
library | Always set to “ready”. | Always set to “ready”. |
drive | Whether the drive being used by an application: “inuse” or “ready”. | Drive state: “loaded”, “unloaded”, “loading”, or “unloading”. |
The meaning of tokens shown in ov_stat output is as shown in Table 4-3:
Table 4-3. ov_stat Tokens Explained
Token | Meaning of Token |
|---|---|
ready | Can accept commands, or is working properly, or is unallocated. |
not ready | Temporarily unable to accept commands (the door might be open). |
disconnected | The LCP or DCP is communicating with the MLM, but not with the hardware. |
inactive | The LCP or DCP is not communicating with the MLM. |
inuse | A drive has been allocated for use by an application. |
unloaded | There is no cartridge in the drive. |
loading | A cartridge is being loaded into the drive. |
loaded | A cartridge is loaded in the drive. |
unloading | A cartridge is being unloaded from the drive. |
active | The LCP or DCP is becoming ready, but is not yet able to take commands. |
Knowing your media inventory is essential for a well-organized site. OpenVault helps track the contents of libraries and cartridge groups so you know the whereabouts of your cartridges, including those that are currently loaded into drives.
The following ov_lscarts commands can be used to check the media inventory:
Show location information for all cartridges, such as the library location, slot assignment, presence in slot, or if loaded in a drive, the name of that drive:
ov_lscarts -w '.*'
Show cartridges assigned to the IRIX Networker application, in long format:
ov_lscarts -A networker -l '.*'
Other information that is important to a smooth-running site is information regarding cartridge contents and usage, such as the number of reads, writes, mounts, and so forth.
The following ov_lscarts commands can be used to check information about cartridges:
Show a summary of all cartridge information on the default server:
ov_lscarts '.*'
Show the application and cartridge group associated with each cartridge:
ov_lscarts -g -a '.*'
If your site performs system-wide backups, then the OpenVault database files will be included in these backups. If the OpenVault server is running at the time of the backup, the catalog files may not get backed up properly. These files can change in the middle of a backup session, especially if your backup scheme employs OpenVault.
To ensure backup of the OpenVault catalog files, follow the steps in Procedure 4-4:
Procedure 4-4. Backing Up OpenVault
Shut down OpenVault.
Copy the /var/opt/openvault/server/dbase directory to another location, using care to preserve the hard links in that directory. One way to do this is as follows:
# cd /var/opt/openvault/server # tar cvf - dbase | (cd savelocationpath ; tar xvf -)
savelocationpath is the name of the directory where the copies will be saved.
Restart OpenVault.
Perform the normal backup procedure, making sure to back up the copy you made of the /var/opt/openvault/server/dbase directory.
Of course, any single-user mode level-0 dumps, which you should be doing, will also backup the OpenVault catalog files.
To recover the catalog files, just restore them from tape to the temporary location, then copy them back into /var/opt/openvault/server/dbase , making sure that you preserve the hard links.