


STORAGE_NODE(5)                                   STORAGE_NODE(5)


NNAAMMEE
       storage node - description of the storage node feature

SSYYNNOOPPSSIISS
       The  _s_t_o_r_a_g_e  _n_o_d_e feature provides central server control
       of distributed devices for saving  and  recovering  client
       data.

DDEESSCCRRIIPPTTIIOONN
       A  _s_t_o_r_a_g_e  _n_o_d_e  is  a  host  that  has directly attached
       devices that  are  used  and  controlled  by  a  NetWorker
       server.    These  devices are called _r_e_m_o_t_e _d_e_v_i_c_e_s_, since
       they are remote from the server.   Clients  may  save  and
       recover to these _r_e_m_o_t_e _d_e_v_i_c_e_s by altering their "storage
       nodes" attribute (see nnssrr__cclliieenntt((55))))..  A _s_t_o_r_a_g_e _n_o_d_e  may
       also  be  a  client of the server, and may save to its own
       devices.

       The main advantages provided by this feature  are  central
       control  of  remote devices, reduction of network traffic,
       use of faster local saves and recovers on a storage  node,
       and  support  of  heterogeneous  server  and  storage node
       architectures.

       There are several attributes which affect  this  function.
       Within the NSR resource (see nnssrr__sseerrvviiccee((55)))) there are the
       "nsrmmd polling interval", "nsrmmd restart  interval"  and
       "nsrmmd  control  timeout"  attributes.   These attributes
       control how often the remote media daemons (see nnssrrmmmmdd((88))))
       are  polled,  how  long  between restart attempts, and how
       long to wait for  remote  requests  to  complete,  respec-
       tively.

       Within  the  "NSR device" resource (see nnssrr__ddeevviiccee((55)))) the
       resource's name  will  accept  the  "rd=hostname:dev_path"
       format  when  defining a _r_e_m_o_t_e _d_e_v_i_c_e_.  The "hostname" is
       the hostname of the storage node  and  "dev_path"  is  the
       device  path  of  the device attached to that host.  There
       are also hidden attributes called "save mount timeout" and
       "save  lockout,"  which allow a pending save mount request
       to timeout, and a storage node to be locked out for upcom-
       ing save requests.

       Within  the  "NSR  client"  resource  (see nnssrr__cclliieenntt((55)))),,
       there are the "storage nodes" and  "clone  storage  nodes"
       attributes.  The former is used by the server in selecting
       a storage node when the client is saving data.  The latter
       is  used during cloning, to direct cloned data from a vol-
       ume on the storage node  (the  node  represented  by  this
       client resource).

IINNSSTTAALLLL AANNDD CCOONNFFIIGGUURREE
       In  order to install a storage node, choose the client and
       storage node packages, where given the choice.  For  those



UNRELEASED                March 08, 2000                        1





STORAGE_NODE(5)                                   STORAGE_NODE(5)


       platforms  that  do  not  have  a choice, the storage node
       binaries are included in the client package.  In addition,
       install  any  appropriate  device driver packages.  If not
       running in evaluation mode, a storage node enabler must be
       configured on the server for each node.

       As  with  a  client, ensure that the nnssrreexxeeccdd((88)) daemon is
       started on the storage node.  To  define  a  device  on  a
       storage  node, from the controlling server define a device
       with the above mentioned "rd=" syntax.  For a remote juke-
       box  (on  a storage node), run jb_config(8) from the node,
       after adding root@storage_node to the server's administra-
       tor  list,  (where  root is the user running jb_config and
       storage_node is the hostname of the storage  node).   This
       administrator list entry may be removed after jb_config(8)
       completes.  Note that on a Windows NT  storage  node,  use
       jbconfig rather than jb_config(8).

       In  addition to jb_config(8), when running scanner(8) on a
       storage node, root@storage_node must be on the  adminstra-
       tor list.

       When  a  device is defined (or enabled) on a storage node,
       the server will attempt to start a media daemon (see  nnssrr--
       mmmmdd((88))))  on  the  node.   In  order for the server to know
       whether the node is alive, it polls the node every "nsrmmd
       polling  interval"  minutes.   When  the  server detects a
       problem with the node's daemon  or  the  node  itself,  it
       attempts  to  restart  the  daemon  every  "nsrmmd restart
       interval" minutes, until either the daemon is restarted or
       the  device  is  disabled (by setting "enabled" to "no" in
       the device's "enabled" attribute).

       In addition to needing a storage  node  enabler  for  each
       storage  node, each remote jukebox will need its own juke-
       box enabler, as is needed for local jukeboxes.

OOPPEERRAATTIIOONN
       A storage node is assignable for work when it  is  consid-
       ered  functional  by  the server (nsrexecd running, device
       enabled, nsrmmd running, and responding  to  the  server's
       polls).   When a client save starts, the client's "storage
       nodes" attribute is used to select a storage  node.   This
       attribute  is  a list of storage node hostnames, which are
       considered in order, for assignment to the request.

       The exception to this node assignment approach is when the
       server's  index  or  bootstrap is being saved - these save
       sets are always directed to the  server's  local  devices,
       regardless  of  the  server's  "storage  nodes" attribute.
       Hence, the server will  always  need  a  local  device  to
       backup such data, at a minimum.  Note that these save sets
       can later be cloned to a storage node,  as  can  any  save
       set.



UNRELEASED                March 08, 2000                        2





STORAGE_NODE(5)                                   STORAGE_NODE(5)


       If  a  storage node is created first (by defining a device
       on the host), and a client resource for that host is  then
       added,  that  hostname  is  added  to  its "storage nodes"
       attribute.  This addition means the client will back up to
       its  own  devices.   However, if a client resource already
       exists, and a device is defined on  that  host,  then  one
       must   manually   update   the  client's  "storage  nodes"
       attribute, with the hostname for that machine.  Since this
       attribute  is  an  ordered  list of hostnames, add its own
       name as the first entry.

       Note that the volume's location field is used to determine
       the  host  location  of  an  unmounted volume.  The server
       looks for a device or jukebox name in this field, as would
       be added when a volume resides in a jukebox.  Volumes in a
       jukebox are considered to be located on the host to  which
       the  jukebox is connected.  The location field can be used
       to bind a stand-alone volume to a particular node by manu-
       ally  setting this field to any device on that node (using
       the "rd=" syntax).

       There are several commands that interact directly  with  a
       device,  and so must run on a storage node.  These include
       jb_config(8), nsrjb(8)  and  scanner(8),  in  addition  to
       those  in  the device driver package.  When invoking these
       commands directly, do so on the storage node  rather  than
       on the server, and use the server option ("-s server_host-
       name", where server_hostname is the  controlling  server's
       hostname).

CCLLOONNIINNGG FFUUNNCCTTIIOONN
       A  single  clone request may be divided into multiple sub-
       requests, one for each different source  machine  (i.  e.,
       the host from which save sets will be read).  For example,
       suppose a clone request must read data  from  volumeA  and
       volumeB,  which  are  located  on  storage  nodes A and B,
       respectively.  Such a request would be  divided  into  two
       sub-requests,  one to read volumeA from storage node A and
       another to read volumeB from storage node B.

       Before the "clone storage nodes" attribute was  introduced
       (see  nnssrr__cclliieenntt((55))))  the  target  location  for  a  clone
       request (the storage node to which cloned data is written)
       was  determined  by  the  "storage nodes" attribute of the
       server's client resource.  In  servers  where  the  "clone
       storage  nodes"  attribute  is defined, the target node is
       determined  by  examining  the   "clone   storage   nodes"
       attribute of the client resource of the storage node, from
       which the clone volume will be read.   If  this  attribute
       has  no  value, the "clone storage nodes" attribute of the
       server's client resource is consulted.  Finally,  if  this
       attribute  has  no value, the "storage nodes" attribute of
       the server's client resource is used.




UNRELEASED                March 08, 2000                        3





STORAGE_NODE(5)                                   STORAGE_NODE(5)


LLIIMMIITTAATTIIOONNSS
       Some limitations of this feature are that a server  cannot
       be  a  storage  node of another server, and a storage node
       can only be controlled by one server.

SSEEEE AALLSSOO
       jjbb__ccoonnffiigg(8), mmmmllooccaattee(8),  nnssrr__cclliieenntt(5),  nnssrr__ddeevviiccee(5),
       nnssrr__jjuukkeebbooxx(5),  nnssrr__sseerrvviiccee(5), nnssrrcclloonnee(8), nnssrreexxeeccdd(8),
       nnssrrjjbb(8), nnssrrmmmmdd(8), nnssrrmmoonn(8), ssccaannnneerr(8).
















































UNRELEASED                March 08, 2000                        4


