Go to primary content
Oracle® Hierarchical Storage Manager and StorageTek QFS Software Installation and Configuration Guide
Release 6.0
E78137-01
  Go To Documentation Library
Library
Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

8 Configuring SAM-Remote

The Oracle Hierarchical Storage Manager software's SAM-Remote feature lets Oracle HSM file-system hosts access tape media and drives that are hosted on a remote, Oracle HSM file-system host. The local host accesses tape resources as a SAM-Remote client of the remote host, which serves as a SAM-Remote server. The client's archiving policies typically maintain one or two copies in a local magnetic or solid state (SSD) disk archive and one or two copies on remote tapes provided by the server. The master configuration file on each host, /etc/opt/SUNWsamfs/mcf, defines the shared resources and the client/server relationships using special, SAM-Remote equipment types.

You can address a number of archiving and data-protection requirements SAM-Remote clients and servers:

This chapter outlines the process of configuring a SAM-Remote client/server network. It covers the following tasks:

Make Sure that All SAM-Remote Hosts Use the Same Software

SAM-Remote clients and servers must have the same revision of the Oracle HSM software installed. Check the revision levels using the procedure below:

  1. Log in to the SAM-Remote server host as root.

    In the example, the server host is server1:

    [server1]root@solaris:~# 
    
  2. Log in to the SAM-Remote client hosts as root.

    In the example, we open a terminal window and use ssh to log in to the host client1:

    [server1]root@solaris:~# ssh root@client1 
    Password: ...
    [client1]root@solaris:~# 
    
  3. Make sure that Oracle HSM package revision levels are identical on all SAM-Remote servers and clients. On each SAM-Remote host, use the command samcmd l to list configuration details. Compare the results.

    In the example, we compare the results on server1 to those on client1. Both use the same release of the Oracle HSM software:

    [server1]root@solaris:~# samcmd l
    Usage information samcmd     6.0  10:20:34 Feb 20 2015
    samcmd on server1
    ...
    [server1]root@solaris:~# 
    
    [client1]root@solaris:~# samcmd l
    Usage information samcmd     6.0  10:20:37 Feb 20 2015
    samcmd on client1
    ...
    [server1]root@solaris:~# 
    
  4. Using the procedures in Chapter 4, "Installing Oracle HSM and QFS Software", update host software as necessary until all SAM-Remote servers and clients are at the same revision levels.

  5. Next, Stop Oracle HSM Processes.

Stop Oracle HSM Processes

  1. Log in to the SAM-Remote server host as root.

    In the example, the server is named server1:

    [server1]root@solaris:~# 
    
  2. Obtain the equipment ordinal numbers of the configured devices. Use the command samcmd c.

    In the example, the devices are numbered 801, 802, 803, and 804:

    [server1]root@solaris:~# samcmd c
    Device configuration samcmd     6.0  10:20:34 Feb 20 2015
    samcmd on server1
    Device configuration:
    ty  eq  state   device_name                        fs   family_set
    rb  800 on      /dev/scsi/changer/c1t0d5           800  rb800
    tp  801 on      /dev/rmt/0cbn                      801  rb800
    tp  802 on      /dev/rmt/1cbn                      802  rb800
    tp  803 on      /dev/rmt/2cbn                      803  rb800
    tp  804 on      /dev/rmt/3cbn                      804  rb800
    
  3. Idle all archiving processes, if any. Use the command samcmd aridle.

    This command will allow current archiving and staging to complete, but will not start any new jobs:

    [samfs-mds]root@solaris:~# samcmd aridle
    [samfs-mds]root@solaris:~# 
    
  4. Idle all staging processes, if any. Use the command samcmd stidle.

    This command will allow current archiving and staging to complete, but will not start any new jobs:

    [samfs-mds]root@solaris:~# samcmd stidle
    [samfs-mds]root@solaris:~# 
    
  5. Wait for any active archiving jobs to complete. Check on the status of the archiving processes using the command samcmd a.

    When archiving processes are Waiting for :arrun, the archiving process is idle:

    [samfs-mds]root@solaris:~# samcmd a
    Archiver status samcmd     6.0 14:20:34 Feb 22 2015
    samcmd on samfs-mds
    sam-archiverd:  Waiting for :arrun
    sam-arfind: ...
    Waiting for :arrun
    
  6. Wait for any active staging jobs to complete. Check on the status of the staging processes using the command samcmd u.

    When staging processes are Waiting for :strun, the staging process is idle:

    [samfs-mds]root@solaris:~# samcmd u
    Staging queue samcmd      6.0 14:20:34 Feb 22 2015
    samcmd on solaris.demo.lan
    Staging queue by media type: all
    sam-stagerd:  Waiting for :strun
    root@solaris:~# 
    
  7. Idle all removable media drives before proceeding further. For each drive, use the command samcmd equipment-number idle, where equipment-number is the equipment ordinal number assigned to the drive in the /etc/opt/SUNWsamfs/mcf file.

    This command will allow current archiving and staging jobs to complete before turning drives off, but will not start any new work. In the example, we idle four drives, with ordinal numbers 801, 802, 803, and 804:

    [samfs-mds]root@solaris:~# samcmd 801 idle
    [samfs-mds]root@solaris:~# samcmd 802 idle
    [samfs-mds]root@solaris:~# samcmd 803 idle
    [samfs-mds]root@solaris:~# samcmd 804 idle
    [samfs-mds]root@solaris:~# 
    
  8. Wait for running jobs to complete.

    We can check on the status of the drives using the command samcmd r. When all drives are notrdy and empty, we are ready to proceed.

    [samfs-mds]root@solaris:~# samcmd r
    Removable media samcmd     6.0 14:20:34 Feb 22 2015
    samcmd on samqfs1host
    ty   eq   status      act  use  state  vsn
    li  801   ---------p    0   0%  notrdy
              empty
    li  802   ---------p    0   0%  notrdy
              empty
    li  803   ---------p    0   0%  notrdy
              empty
    li  804   ---------p    0   0%  notrdy
              empty
    [samfs-mds]root@solaris:~# 
    
  9. When the archiver and stager processes are idle and the tape drives are all notrdy, stop the library-control daemon. Use the command samd stop.

    [samfs-mds]root@solaris:~# samd stop
    [samfs-mds]root@solaris:~# 
    
  10. Next, Configure the SAM-Remote Server.

Configure the SAM-Remote Server

A SAM-Remote server is an Oracle HSM file-system host that makes its attached robotic tape libraries, and tape drives available to remote clients that are themselves Oracle HSM file-system hosts. The SAM-Remote server must mount at least one QFS file system to start Oracle HSM processes.

To configure a SAM-Remote server, carry out the following tasks:

Define the Remotely Shared Archiving Equipment in the SAM-Remote Server's mcf File

  1. Log in to the SAM-Remote server host as root.

    In the example, the server is named server1:

    [server1]root@solaris:~# 
    
  2. On the server, open the /etc/opt/SUNWsamfs/mcf file in a text editor, and scroll down to the archiving equipment definitions.

    In the example, we use the vi editor. The file defines one Oracle HSM archiving file system, fs600, and a tape library, rb800, that holds four drives. Note that the example includes clarifying headings that may not be present in actual files and abbreviates lengthy device paths:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    #=======================================================================
    # Oracle HSM archiving file system fs600
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    fs600                      600       ms        fs600   on
     /dev/dsk/c9t60...F4d0s7    610       md        fs600   on
     /dev/dsk/c9t60...81d0s7    611       md        fs600   on
    #=======================================================================
    # Local tape archive rb800 
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /dev/scsi/changer/c1t0d5   800       rb        rb800   on
     /dev/rmt/0cbn              801       tp        rb800   on
     /dev/rmt/1cbn              802       tp        rb800   on
     /dev/rmt/2cbn              803       tp        rb800   on
     /dev/rmt/3cbn              804       tp        rb800   on
    
  3. At the end of the archiving equipment definitions, start an entry for the server that will make tape resources available to clients. Enter the path to the SAM-Remote server configuration file, /etc/opt/SUNWsamfs/samremote, in the Equipment Identifier field, and assign an equipment ordinal number.

    In the example, we add some headings as comments and assign equipment ordinal number 500 to the server samremote:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #==========================================================================
    # Server samremote shares tape hardware and media with clients 
    # Equipment                   Equipment Equipment Family  Device Additional
    # Identifier                  Ordinal   Type      Set     State  Parameters
    #---------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/samremote  500       
    
  4. In the Equipment Type field of the new entry, enter ss, for SAM-Remote server equipment.

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #==========================================================================
    # Server samremote shares tape hardware and media with clients 
    # Equipment                   Equipment Equipment Family  Device Additional
    # Identifier                  Ordinal   Type      Set     State  Parameters
    #---------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/samremote  500       ss     
       
    
  5. Assign a Family Set name that is unique across all hosts and servers, and set the device on.

    In the example, we assign the family set name ss500 to the new equipment:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #==========================================================================
    # Server samremote shares tape hardware and media with clients 
    # Equipment                   Equipment Equipment Family  Device Additional
    # Identifier                  Ordinal   Type      Set     State  Parameters
    #---------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/samremote  500       ss        ss500   on
    
  6. If you plan to configure more than ten SAM-Remote clients, add an additional server-equipment (type ss) entry for each successive group of one to ten clients.

  7. Save the file, and close the editor.

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    /etc/opt/SUNWsamfs/samremote  500       ss        ss500   on
    :wq
    [server1]root@solaris:~# 
    
  8. Next, Create the samremote Server Configuration File.

Create the samremote Server Configuration File

The SAM-Remote server configuration file defines the disk buffer characteristics and media to be used for each client. For each server that you need to configure, proceed as follows:

  1. Log in to the SAM-Remote server host as root.

    In the example, the server is named server1:

    [server1]root@solaris:~# 
    
  2. On the server, create an /etc/opt/SUNWsamfs/samremote file in a text editor.

    In the example, we create the file with the vi editor. We start by documenting the file with some descriptive comments, as indicated by the hash (#) signs:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/samremote
    # Server Configuration File:
    # Defines the disk buffer and media that is available to each client.
    
  3. Start the first client entry by starting a new line and entering the hostname, IP address, or fully qualified domain name of the client in the first column.

    The client identifier line must start with a non-space character. In the example, we identify the client using the hostname client1:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/samremote
    # Server Configuration File:
    # Defines the disk buffer and media that is available to each client.
    client1
    
  4. Start identifying the media that will be shared with the client. Start a new line of the form indent media, where indent is one or more spaces and media is a SAM-remote keyword:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/samremote
    # Server Configuration File:
    # Defines the disk buffer and media that is available to each client.
    client1
            media
    
  5. Identify each media type and source with a new line of the form indent equipment-number media-type VSNs, where:

    • indent is one or more spaces.

    • equipment-number is the equipment ordinal number that identifies the archival storage equipment in the mcf file.

    • media-type is the media identifier for the tape media used by this equipment (see Appendix A, "Glossary of Equipment Types" for a full list of Oracle HSM media types).

    • VSNs is a space-delimited list of one or more volume serial numbers, which are alphanumeric strings of up to 31 characters.

    In the example, we identify one source of shared media, a range of tape volumes (type tp) resident in a tape library with equipment ordinal number 800. The available volumes are specified by a regular expression enclosed in parentheses: the expression VOL0[0-1][0-9] limits client1 to volumes VOL000-VOL019:

    client1
           media
             800 tp (VOL0[0-1][0-9])
    

    Note that each line can specify only one type of media. So, if the library were to support more than one media type, you would specify each type in a new entry:

          media
             800 ti VOL500 VOL501
             800 li (VOL0[0-1][0-9])
    
  6. When you have finished identifying the media that will be shared with the client, close the list by entering the SAM-Remote keyword endmedia.

    In the example, client1 is now fully configured:

    client1
           media
             800 tp (VOL0[0-1][0-9])
           endmedia
    
  7. If you need to configure additional clients, do so now. Add a new client configuration record for each, up to a maximum of ten (10). Then save the file and close the editor.

    To prevent contention for volumes and possible data loss, make sure that clients do not share the same removable media volumes.

    In the example, we configure one additional client, client2. The second client has access to a range of tape volumes resident in the same tape library as client1, equipment ordinal number 800. But the regular expression in the configuration specifies a different set of volumes: VOL020-VOL039.

    # Server Configuration File:
    # Defines the disk buffer and media that is available to each client.
    client1
           media
             800 tp (VOL0[0-1][0-9])
           endmedia
    client2
           media
             800 tp (VOL02-3][0-9])
           endmedia
    :wq
    [server1]root@solaris:~# 
    
  8. Next, Configure the SAM-Remote Clients.

Configure the SAM-Remote Clients

For each SAM-Remote client, perform the following tasks:

Define the Remote Archiving Equipment in the SAM-Remote Client's MCF File

  1. Log in to the SAM-Remote client host as root.

    In the example, the SAM-Remote client is named client1:

    [client1]root@solaris:~# 
    
  2. On the client, open the /etc/opt/SUNWsamfs/mcf file in a text editor, and scroll down to the archiving equipment definitions.

    In the example, we use the vi editor. The file defines one Oracle HSM archiving file system, fs100. Local copies are stored in disk-archive DISKVOL1, a local ZFS file system. Note that the example includes clarifying headings that may not be present in actual files and abbreviates lengthy device paths.

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    # Client's /etc/opt/SUNWsamfs/mcf file
    #=======================================================================
    # Oracle HSM archiving file system "fs100"
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    fs100                      100       ms        fs100   on
     /dev/dsk/c10t60...7Bd0s7   110       md        fs100   on
     /dev/dsk/c10t60...48d0s7   111       md        fs100   on
    #=======================================================================
    # Disk archive "/diskvols/DISKVOL1" stores local archive copies
    
  3. At the end of the archiving equipment definitions, start an entry for the equipment that the server will make available to the client. In the Equipment Identifier field, enter the path to the SAM-Remote server configuration file, and assign an equipment ordinal number.

    In the example, we name the client configuration /etc/opt/SUNWsamfs/sc400 and assign the client the equipment ordinal number 400. We also add some headings as comments:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    # Disk archive "/diskvols/DISKVOL1" stores local archive copies
    #
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/sc400   400     
      
    
  4. In the Equipment Type field of the new entry, enter sc, for SAM-Remote client equipment.

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/ss500   400       sc
    
  5. Assign a Family Set name that is unique across all hosts and servers, and set the device on.

    In the example, we assign the family set name ss500 to the new equipment.

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/ss500   400       sc        ss500   on     
    
  6. For each tape drive that the SAM-Remote server makes available, add a SAM-Remote pseudodevice to the SAM-Remote client sc equipment. In the Equipment Identifier field, add an entry of the form /dev/samrd/rddevice-number, where device-number is an integer.

    In the example, we start entries for two pseudodevices, /dev/samrd/rd 0 and /dev/samrd/rd 1:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/sc400   400       sc        sc400   on     
     /dev/samrd/rd0
     /dev/samrd/rd1
    
  7. In the Equipment Ordinal field for each pseudodevice, enter a number in the range that you assigned to the sc equipment.

    In the example, we assign equipment ordinal 410 to /dev/samrd/rd0 and equipment ordinal 420 to /dev/samrd/rd1:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/ss500   400       sc        ss500   on     
     /dev/samrd/rd0             410
     /dev/samrd/rd1             420
    
  8. In the Equipment Type field for each SAM-Remote pseudodevice, enter rd, the equipment type for SAM-Remote pseudodevices.

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/ss500   400       sc        ss500   on     
     /dev/samrd/rd0             410       rd
     /dev/samrd/rd1             420       rd
    
  9. In the Family Set field for each pseudodevice, enter the family set name for the sc equipment.

    In the example, we use the family set name ss500:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/ss500   400       sc        ss500   on     
     /dev/samrd/rd0             410       rd        ss500
     /dev/samrd/rd1             420       rd        ss500
    
  10. In the Device State field for each pseudodevice, enter on. Then save the file and close the editor.

    In the example, we assign equipment ordinal 410 to /dev/samrd/rd 0 and equipment ordinal 420 to /dev/samrd/rd 1:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/mcf
    ...
    #=======================================================================
    # Client "sc400" accesses tape resources on server "samremote" (ss500)
    # Equipment                Equipment Equipment Family  Device Additional
    # Identifier               Ordinal   Type      Set     State  Parameters
    #------------------------  --------- --------- ------  ------ ----------
    /etc/opt/SUNWsamfs/ss500   400       sc        ss500   on
     /dev/samrd/rd0             410       rd        ss500   on
     /dev/samrd/rd1             420       rd        ss500   on
    :wq
    [client1]root@solaris:~# 
    
  11. Next, Create the SAM-Remote Client Configuration File.

Create the SAM-Remote Client Configuration File

For each SAM-Remote client, proceed as follows:

  1. Log in to the SAM-Remote client host as root.

    In the example, the SAM-Remote client is named client1:

    [client1]root@solaris:~# 
    
  2. On the client, create an /etc/opt/SUNWsamfs/family-set-name file in a text editor, where family-set-name is the family set name for the remote equipment as used in the mcf file.

    In the example, we create the file with the vi editor and name it for the family set ss500. We also document the file with some descriptive comments preceded by hash (#) signs:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/sc400
    # Client's SAM-Remote client configuration file: /opt/SUNWsamfs/sc400
    # This file identifies the host of the SAM-Remote server.
    
  3. Add a single entry for the server by starting a new line and entering the hostname, IP address, or fully qualified domain name of the server in the first column. Then save the file and close the editor.

    The line must start with a non-space character. In the example, we identify the server using the hostname server1:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/samremote
    # Client's SAM-Remote server configuration file: /opt/SUNWsamfs/sc400
    # This file identifies the host of the SAM-Remote server.
    server1
    :wq
    [client1]root@solaris:~# 
    
  4. Next, Configure the archiver.cmd file on the SAM-Remote Client.

Configure the archiver.cmd file on the SAM-Remote Client

  1. Log in to the SAM-Remote client host as root.

    In the example, the SAM-Remote client is named client1:

    [client1]root@solaris:~# 
    
  2. Open the /etc/opt/SUNWsamfs/archiver.cmd file in a text editor, and scroll down to the copy parameter directives, which start at the keyword params and end at the keyword endparams.

    In the example, we open the file in the vi editor:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/archiver.cmd
    ...
    #-----------------------------------------------------------------------
    # Copy Parameter Directives
    params
    allsets -sort path -offline_copy direct
    allfiles.1 -startage 10m -startsize 500M -drives 10
    allfiles.2 -startage 24h -startsize 20G -drives 2 -reserve set
    endparams
    
  3. Check the copy parameters for all archive sets that will be archived on remote media. If any of them includes -tapenonstop and/or -offline_copy direct directives, remove these directives now.

    In the example, the all parameter specifies the -offline_copy direct directive for all copies. So we override this directive by specifying -offline_copy none for the copy that we intend to send to remote media, allfiles.3:

    #-----------------------------------------------------------------------
    # Copy Parameter Directives
    # Copy Parameter Directives
    params
    allsets -sort path -offline_copy direct
    allfiles.1 -startage 10m -startsize 500M -drives 10
    allfiles.2 -startage 24h -startsize 20G -drives 2 -reserve set offline_copy none
    endparams
    
  4. Scroll down to the VSN directives, which start at the SAM-Remote keyword vsns and end at the keyword endvsns.

    In the example, we use the vi editor. The only copy that currently has media assigned, allfiles.1, will be made using the local disk archive volume, qfs200:

    ...
    endparams
    #-----------------------------------------------------------------------
    # VSN Directives
    vsns
    allfiles.1 dk qfs200
    endvsns
    
  5. Assign archive copies to the remote media, as specified for this client in the server's /etc/opt/SUNWsamfs/samremote file. Then save the file and close the editor.

    In the example, we are configuring client1. Copy allfiles.2 will be made using a remote tape volume in the range VOL000-VOL019, as specified in the samremote server configuration file:

    ...
    endparams
    #-----------------------------------------------------------------------
    # VSN Directives
    vsns
    allfiles.1 dk qfs200
    allfiles.2 tp VOL0[0-1][0-9]
    endvsns
    :wq
    [client1]root@solaris:~# 
    
  6. Next, Validate the Archiving Configuration on the SAM-Remote Server.

Validate the Archiving Configuration on the SAM-Remote Server

  1. Log in to the SAM-Remote server host as root.

    In the example, the SAM-Remote server is named server1:

    [server1]root@solaris:~# 
    
  2. Start the Oracle HSM processes on the server. Use the command samd start:

    [server1]root@solaris:~# samd start
    
  3. On the server host, check the status of the shared-device server. Use the command samcmd s.

    In the example, the SAM-Remote server equipment (type ss) with equipment ordinal number 500 is on and operating normally:

    [server1]root@solaris:~# samcmd s
    Device status samcmd     6.0  11:20:34 Feb 20 2015
    samcmd on server1
    ty    eq  state   device_name                      fs     status
    rb    800 on      /dev/scsi/changer/c1t0d5         800    m--------r
    tp    801 on      /dev/rmt/0cbn                    800    ---------p
      empty
    tp    802 on      /dev/rmt/1cbn                    800    ---------p
      empty
    tp    803 on      /dev/rmt/2cbn                    800    ---------p
      empty
    tp    804 on      /dev/rmt/3cbn                    800    ---------p
      empty
    ss    500 on      /etc/opt/SUNWsamfs/samremote     ss500  -------o-r
    [server1]root@solaris:~# 
    
  4. If the shared-device server is not on, make sure that it is correctly defined in the server host's /etc/opt/SUNWsamfs/mcf file. Make sure that the /etc/opt/SUNWsamfs/samremote file is correct and in the correct location.

    See the procedures "Define the Remotely Shared Archiving Equipment in the SAM-Remote Server's mcf File" and "Create the samremote Server Configuration File".

  5. On the server, check the connection status of the SAM-Remote clients. Use the command samcmd R.

    In the example, both client1 and client2 are in state 0005 and are thus connected (state 0004 indicates no connection):

    [server1]root@solaris:~# samcmd R
    Remote server eq: 500 addr: 00003858 samcmd 6.0  11:20:44 Feb 20 2015
    samcmd on server1
    message:
    Client IPv4: client1 192.10.10.3 port - 5000
     client index - 0 port - 31842 flags - 0005 connected
    Client IPv4: client2 10.1.229.97 port - 5000
     client index - 1 port - 32848 flags - 0005 connected
    [server1]root@solaris:~# 
    
  6. If a shared-device client is not connected (state 0004), check network connectivity. Make sure that server and client(s) can resolve each other's hostnames and addresses. Make sure that server and client(s) can reach each other.

    In the example, we use ssh with the getent and ping commands to check connectivity from each host to each of the other hosts in the SAM-Remote configuration:

    [server1]root@solaris:~# getent hosts client1
    192.10.10.3      client1
    [server1]root@solaris:~# getent hosts 192.10.10.3
    192.10.10.3      client1
    [server1]root@solaris:~# ping 192.10.10.3
    192.10.10.31 is alive
    [server1]root@solaris:~# getent hosts client2
    10.1.229.97 client2
    [server1]root@solaris:~# getent hosts 10.1.229.97
    10.1.229.97 client2
    [server1]root@solaris:~# ping 10.1.229.97
    192.10.10.31 is alive
    [server1]root@solaris:~# ssh root@client1
    Password: ...
    [client1]root@solaris:~# getent hosts server1
    192.10.201.12    server1
    ...
    [client1]root@solaris:~# exit
    [server1]root@solaris:~# ssh root@client2
    Password: ...
    [client2]root@solaris:~# getent hosts server1
    192.10.201.12    server1
    ...
    [client2]root@solaris:~# exit
    [server1]root@solaris:~# 
    
  7. If a shared-device client is not connected (state 0004), make sure that it is correctly defined in the client host's /etc/opt/SUNWsamfs/mcf file. Make sure that the server host is correctly identified in the /etc/opt/SUNWsamfs/family-set-name file and that the file is in the correct location on the client host. Then make sure that the client hosts are correctly identified in the /etc/opt/SUNWsamfs/samremote file on the server host.

    See the procedures "Define the Remote Archiving Equipment in the SAM-Remote Client's MCF File" and "Create the SAM-Remote Client Configuration File".

  8. On the client, make sure that the server host is correctly identified in the /etc/opt/SUNWsamfs/family-set-name file and that the file is in the correct location on the client host.

    See the procedure"Create the SAM-Remote Client Configuration File".

  9. If a shared-device client is not connected (state 0004) and the client-side configuration files are not the problem, check the server. Make sure that the client hosts are correctly identified in the /etc/opt/SUNWsamfs/samremote file.

    See the procedure "Create the samremote Server Configuration File".

  10. On the server, make sure that each client can access the catalog for the shared tape library and view the available volumes. Use the command samcmd v equipment-number, where equipment-number is the equipment ordinal that the client's mcf file assigns to the SAM-Remote client equipment.

    In the example, we check client1, so 400 is the equipment number for the SAM-Remote client equipment, /etc/opt/SUNWsamfs/sc400. The output correctly lists the volumes that client1 can access, VOL000 to VOL019:

    [server1]root@solaris:~# samcmd v 400 
    Robot catalog samcmd     6.0  12:20:40 Feb 20 2015
    samcmd on server1
    Robot VSN catalog by slot       : eq 400
    slot     access time  count use flags         ty vsn
       3     none         0     0%  -il-o-b-----  li VOL000 
       7     none         0     0%  -il-o-b-----  li VOL001
    ...
      24     none         0     0%  -il-o-b-----  li VOL019 
    [server1]root@solaris:~# 
    
  11. If a shared-equipment client cannot see the correct volumes, check the host files. On the server host, make sure that the assigned volumes are correctly identified in the /etc/opt/SUNWsamfs/samremote file. On the client host, make sure that the /etc/opt/SUNWsamfs/family-set-name file correctly identifies the server host.

    See the procedures "Create the samremote Server Configuration File" and "Create the SAM-Remote Client Configuration File".

  12. Next, Validate the Archiving Configuration on Each SAM-Remote Client.

Validate the Archiving Configuration on Each SAM-Remote Client

For each SAM-Remote client, proceed as follows:

  1. Log in to the SAM-Remote client host as root.

    In the example, the SAM-Remote client is named client1:

    [client1]root@solaris:~# 
    
  2. Start the Oracle HSM processes on the client host. Use the command samd start:

    [client1]root@solaris:~# samd start
    [client1]root@solaris:~# 
    
  3. On the client host, check the status of the shared-device client. Use the command samcmd s.

    In the example, the SAM-Remote client equipment (type sc) with equipment ordinal number 400 is on and operating normally:

    [client1]root@solaris:~# samcmd s
    Device status samcmd     6.0  12:20:49 Feb 20 2015
    samcmd on client1
    ty    eq  state   device_name                      fs     status
    sc    400 on      /etc/opt/SUNWsamfs/sc400         sc400  -------o-r
    
  4. If the shared-device client is not on, make sure that the sc device is correctly defined. On the client host, check the /etc/opt/SUNWsamfs/mcf file, and make sure that the /etc/opt/SUNWsamfs/family-set-name file is correct and in the correct location.

    See the procedures "Define the Remote Archiving Equipment in the SAM-Remote Client's MCF File" and "Create the SAM-Remote Client Configuration File".

  5. On the client host, confirm that the /etc/opt/SUNWsamfs/archiver.cmd file specifies the correct volume serial numbers for the remote media. List the file using the command archiver -A.

    In the example, we are configuring client1. Copy allfiles.2 will be made using one of the remote tape volumes in the range VOL000-VOL019, as specified in the samremote server configuration file:

    [client1]root@solaris:~# archiver -A
    Reading '/etc/opt/SUNWsamfs/archiver.cmd'.
    1: # archiver.cmd
    2: #-----------------------------------------------------------------------
    3: # Global Directives
    4: archivemeta = off
    5: examine = noscan
    ...
    30: #-----------------------------------------------------------------------
    31: # VSN Directives
    32: vsns
    33: allfiles.1 dk qfs200
    34: allfiles.2 tp VOL0[0-1][0-9]
    36: endvsns
    [client1]root@solaris:~# 
    
  6. If you note any discrepancies in the archiver.cmd file, correct them before continuing.

  7. If you intend to configure recycling, see Configuring Recycling for SAM-Remote.

Configuring Recycling for SAM-Remote

When SAM-Remote is configured, you must insure that recycling on one host cannot destroy valid data on another. Any recycling directives that you configure on a SAM-Remote server must recycle only the media that the server uses for its own archive sets. The server must not try to recycle media volumes that it has made available to SAM-Remote clients. Similarly, any recycling directives that you configure on a SAM-Remote client must recycle only the media that holds archived client data, either locally or in the designated volumes made available by the server.

You should thoroughly understand the recycling process before trying to use the recycler in a SAM-Remote environment. So read "Recycling" and the sam-recycler, archiver.cmd, recycler.cmd, and recycler.sh man pages.

Then, when you are familiar with how recycling works, carry out the tasks below:

Configure Recycling on the SAM-Remote Server

If you need to configure recycling for file systems that the SAM-Remote server hosts, proceed as follows:

  1. Log in to the SAM-Remote server as root.

    In the example, the SAM-Remote server is named server1:

    [server1]root@solaris:~# 
    
  2. Open the /etc/opt/SUNWsamfs/archiver.cmd file in a text editor. Scroll down to the params section.

    In the example, we open the file in the vi editor:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/archiver.cmd
    ...
    #-----------------------------------------------------------------------
    # Copy Parameter Directives
    params
    allsets -sort path -offline_copy direct
    allfiles.1 -startage 10m -startsize 500M -drives 10
    allfiles.2 -startage 24h -startsize 20G -drives 2 -reserve set
    endparams
    
  3. Enter your recycler directives by archive set, in the form archive-set directive-list, where archive-set is one of the archive sets and directive-list is a space-delimited list of directive name/value pairs (for a full list of recycling directives, see the archiver.cmd man page).

    When using SAM-Remote, you must configure recycling by archive sets, in the params section of the archiver.cmd file. You cannot specify recycling by library.

    In the example, we add recycling directives for archive sets allfiles.1 and allfiles.2. The -recycle_mingain 90 directive does not recycle a volume unless at least 90 percent of the volume's capacity can be recovered. The -recycle_hwm 60 directive starts recycling when 60 percent of the removable media capacity has been used. The -recycle_vsncount 1 schedules no more than one removable media volume for recycling at a time:

    #---------------------------------------------------------------------
    #  Copy Parameters Directives
    params
    allsetsallfiles. -sort path -offline_copy direct
    allfiles.1 -startage 10m -startsize 500M -drives 10
    allfiles.1 -recycle_mingain 90
    allfiles.2 -startage 24h -startsize 20G -drives 2 -reserve set offline_copy none
    allfiles.2 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    endparams
    

    Note that the recycling directives defined on the SAM-Remote server apply only to archival volumes that the server uses for its own archive sets. The server's recycling directives do not apply to volumes that are accessible from the clients.

    In the example, the server's recycling directives for copy allfiles.2 apply to the tape volumes listed for the server's use in the VSN Directives section, VOL100-VOL199. The server's recycling directives do not apply to volumes VOL000-VOL019, which are reserved for client1, or to volumes VOL020-VOL039, which are reserved for client2:

    ...
    endparams
    #-----------------------------------------------------------------------
    # VSN Directives
    vsns
    allfiles.1 dk DISKVOL1
    allfiles.2 tp VOL1[0-9][0-9]
    endvsns
    
  4. Save the archiver.cmd file, and close the editor.

    ...
    endvsns
    :wq
    [server1]root@solaris:~# 
    
  5. On the server, create the recycler.cmd file in a text editor. Specify a path and file name for the recycler log.

    In the example, we use the vi editor. We specify the default location for the log file:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/recycler.cmd
    logfile = /var/adm/recycler.log
    
  6. In the recycler.cmd file on the server, add a directive of the form no-recyle media-type volumes, where media-type is one of the media types specified in Appendix A, "Glossary of Equipment Types" and where volumes is a space-delimited list or regular expression that specifies a volume serial number for every archival storage volume that you have assigned to SAM-Remote clients. Save the file and close the editor.

    The no-recyle directive provides additional protection for storage resources that are dedicated to client use. It explicitly orders the host recycling processes to skip the specified volumes.

    In the example, we add a no-recyle directive for media type tp (tape) volumes in the ranges VOL000-VOL019 and VOL020-VOL039:

    [server1]root@solaris:~# vi /etc/opt/SUNWsamfs/recycler.cmd
    logfile = /var/opt/SUNWsamfs/recycler/recycler.log
    no_recycle tp VOL0[0-1][0-9] VOL0[2-3][0-9] 
    :wq
    [server1]root@solaris:~# 
    
  7. Now, Configure Recycling on the SAM-Remote Client.

Configure Recycling on the SAM-Remote Client

For each client, proceed as follows:

  1. Log in to the SAM-Remote client as root.

    In the example, the SAM-Remote client is named client1:

    [client1]root@solaris:~# 
    
  2. On the client, open the /etc/opt/SUNWsamfs/archiver.cmd file in a text editor, and scroll down to the copy params section.

    In the example, we open the file in the vi editor.

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/archiver.cmd
    ...
    #-----------------------------------------------------------------------
    # Copy Parameters Directives
    params
    allsets -sort path -offline_copy stageahead
    allfiles.1 -startage 6h  -startsize 6G  -startcount 500000
    allfiles.2 -startage 24h -startsize 20G -startcount 500000 -archmax 24G
    endparams
    #-----------------------------------------------------------------------
    # VSN Directives
    vsns
    allfiles.1 dk qfs200
    allfiles.2 tp VOL0[0-1][0-9]
    endvsns
    
  3. In the params section of the archiver.cmd file, enter your recycler directives by archive set, in the form archive-set directive-list, where archive-set is one of the archive sets and directive-list is a space-delimited list of directive name/value pairs (for a list of recycling directives, see the archiver.cmd man page). Then save the file and close the editor.

    When using SAM-Remote, you must configure recycling by archive sets, in the params section of the archiver.cmd file. You cannot specify recycling by library.

    In the example, we add recycling directives for archive sets allfiles.1 and allfiles.2. The -recycle_mingain 90 directive does not recycle volumes unless at least 90 percent of the volume's capacity can be recovered. The -recycle_hwm 60 directive starts recycling when 60 percent of the removable media capacity has been used. The -recycle_vsncount 1 directive schedules no more than one removable media volume for recycling at a time.

    #-----------------------------------------------------------------------
    # Copy Parameters Directives
    params
    allsets -sort path -offline_copy stageahead
    allfiles.1 -startage 6h  -startsize 6G  -startcount 500000
    allfiles.1 -recycle_mingain 90
    allfiles.2 -startage 24h -startsize 20G -startcount 500000 -archmax 24G
    allsets.2 -recycle_hwm 60 -recycle_mingain 90 -recycle_vsncount 1
    endparams
    

    Note that the recycling directives defined on the client apply only to media that the client uses for its own archive sets. In the example, the client's recycling directives for copy allfiles.2 apply to server-provided remote tape volumes in the range VOL000-VOL019. They do not apply to volumes in the range VOL020-VOL039, which are reserved for client2, or to volumes in the range VOL100-VOL119, which are reserved for the server:

    ...
    endparams
    #-----------------------------------------------------------------------
    # VSN Directives
    vsns
    allfiles.1 dk qfs200
    allfiles.2 tp VOL0[0-1][0-9]
    endvsns
    :wq
    [client1]root@solaris:~# 
    
  4. Save the archiver.cmd file, and close the editor.

    ...
    endvsns
    :wq
    [client]root@solaris:~# 
    
  5. On the client, create the recycler.cmd file in a text editor. Specify a path and file name for the recycler log. Then save the file and close the editor.

    We have configured the server and clients so that the client does not have access any of the archival media used by the server or by client2. So we do not need to add no-recyle directives.

    In the example, we use the vi editor. We specify the default location for the log file:

    [client1]root@solaris:~# vi /etc/opt/SUNWsamfs/recycler.cmd
    logfile = /var/adm/recycler.log
    :wq
    [client1]root@solaris:~# 
    
  6. Repeat this procedure until all SAM-Remote clients have been configured.

  7. Enter the command sam-recycler -dvxn, where the parameters have the following effects:

    • -d displays volume-selection messages that indicate why each volume was or was not selected for recycling.

    • -v lists the files that are resident on each volume that is marked for recycling and will need to be moved.

    • -x returns an error and stops if it lists any archive copies that are older than the time when the volume was labeled and are thus irrecoverable.

    • -n prevents actual recycling. The recycling process behaves as if all archive set definitions in the archiver.cmd file included the -recycle_ignore, so you can test the recycling configuration non-destructively.

  8. Once all SAM-Remote clients and servers have been configured, if you plan to use the sideband database feature, go to "Configuring the Reporting Database".

  9. Otherwise, go to "Configuring Notifications and Logging".