Networker

Re: [Networker] Utilization of Tapes

2004-07-26 07:23:02
Subject: Re: [Networker] Utilization of Tapes
From: Davina Treiber <Treiber AT HOTPOP DOT COM>
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Date: Mon, 26 Jul 2004 12:21:38 +0100
Eichelberger, Jon wrote:

From my observations this is being caused by the fact that I have too much 
hardware (not really).
What I mean is that I have a networker server with 4 dedicated tape drives and 
6 storage
nodes, 2 or which have 6 tape drives each and 4 or which have 5 tape drives 
each.  Just
to distribute the load of the backups, client A has storage node 1 as the first 
node in its
list, client B has storage node 2 as the first node in its list, and this goes 
round and round for
300 clients.  So when client A needs to do a backup, it loads a tape from pool 
XXX and does
the backup on storage node 1.  Since this tape is still mounted (but idle) when 
client B needs to do a
backup to pool XXX, a different tape is labeled and mounted on storage node 2 
since client B has
storage node 2 at the top of its list of storage nodes.

So are these storage nodes all controlling drives in the same library?
If so you could try reducing the idle device timeout to 2 or 3 minutes.

My ideas are:
1. Find some way to eject a tape as soon as it is done being used so, for 
example,
storage node 2 will mount the tape that client A (storage node 1) already wrote 
on.
I have found no way yet to know from a programmable/command line level to sense 
that a tape
drive is in the "writing, done" state.

You can do this by using nsradmin to query the "message" attribute of
the NSR device resources.

but I ruled that out because Networker 6.1.3 on Solaris 8 (that's what I use) 
seems to really
fixate on the fist storage node on the list.  I don't know what 7.x does - 
probably nothing
different.  It would be nice if the sessions per drive were really obeyed and 
Networker would just
roll down to the next storage node without waiting for a timeout.  I'd also end 
up working a few
tape drives to death while others sat idle.

The storage node doesn't work this way. In general it won't use the
second node in the list unless the first node is unavailable, or
unavailable for the specified pool.

--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=