NSR_STORAGE_NODE(5)

NAME
nsr_storage_node - description of the storage node feature

SYNOPSIS
The storage node feature provides central server control of distributed devices for saving and recovering client data.

DESCRIPTION
A storage node is a host that has directly attached devices that are used and controlled by a NetWorker server. These devices are called remote devices, because they are remote from the server. Clients may save and recover to these remote devices by altering their "storage nodes" attribute (see nsr_client(5)). A storage node 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 nsr_service(5)) there are the "nsrmmd polling interval", "nsrmmd restart interval" and "nsrmmd control timeout" attributes. These attributes control how often the remote media daemons (see nsrmmd(8)) are polled, how long between restart attempts, and how long to wait for remote requests to complete.

Within the "NSR device" resource (see nsr_device(5)) the resource's name will accept the "rd=hostname:dev_path" format when defining a remote device. 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 upcoming save requests.

Within the "NSR client" resource (see nsr_client(5)), there are "storage nodes" and "clone storage nodes" attributes. The "storage nodes" attribute is used by the server in selecting a storage node when the client is saving data. The "clone storage nodes" attribute is used during cloning, to direct cloned data from a volume on the storage node (the node represented by this client resource).

The "NSR jukebox" resource (see nsr_jukebox(5)), contains the "read hostname" attribute. When all of a jukebox's devices are not attached to the same host, this attribute specifies the hostname that is used in selecting a storage node for recover and read-side clone requests. For recover requests, if the required volume is not mounted, and the client's "storage nodes" attribute does not match one of the owning hosts in the jukebox, then this attribute is used. For clone requests, if the required volume is not mounted, then this attribute is used.

INSTALL AND CONFIGURE
In order to install a storage node, choose the client and storage node packages, where given the choice. For those 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 nsrexecd(8) 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 jukebox (on a storage node), run jbconfig(8) from the node, after adding root@storage_node to the server's administrator list, (where root is the user running jbconfig(8) and storage_node is the hostname of the storage node). This administrator list entry may be removed after jbconfig(8) completes.

In addition to jbconfig(8), when running scanner(8) on a storage node, root@storage_node must be on the adminstrator list.

When a device is defined (or enabled) on a storage node, the server will attempt to start a media daemon (see nsrmmd(8)) 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 jukebox will need its own jukebox enabler. for local jukeboxes.

OPERATION
A storage node is assignable for work when it is considered functional by the server - nsrexecd(8) running, device enabled, nsrmmd(8) running, and the node is 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. These save sets can later be cloned to a storage node, as can any save set.

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 later defined on that host, then the client's hostname must be added manually to the client's "storage nodes" attribute. This attribute is an ordered list of hostnames; add the client's own name as the first entry.

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 manually setting this field to any device on that node (using the "rd=" syntax). For jukeboxes which do not have all of their devices attached to the same host, see the previous description of the "read hostname" attribute.

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

CLONING FUNCTION
A single clone request may be divided into multiple sub-requests, one for each different source machine (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 nsr_client(5)) 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 is read. If this attribute has no value, the "clone storage nodes" attribute of the server's client resource is consulted. If this attribute has no value, the "storage nodes" attribute of the server's client resource is used.

LIMITATIONS
A server cannot be a storage node of another server.

SEE ALSO
jbconfig(8), mmlocate(8), nsr_client(5), nsr_device(5), nsr_jukebox(5), nsr_service(5), nsrclone(8), nsrexecd(8), nsrjb(8), nsrmmd(8), nsrmon(8), scanner(8).