Conference stkhlm::magtape

    Thanks for the answers.  I'm checking this with Bill Coots, but I'm
    planning to have the MUSL code installed now, though I won't be using
    two-unit support until at least the summer.
    
    I read the instrutions on how to set up MUSL.  But what are the
    differences and advantages of Multi-Unit Single LUN (MUSL) over
    Multi-Unit Multiple LUN?  Is MUML the kind of multi-unit support
    available in the near past?
    
    Thanks!
    tl

	The advantage of MUSL is that it works and complies to the
	SCSI-2 specification for medium changers, so that software
	can support it.  MUML presented each robot as a separate
	logical unit of the same target.  The individual element
	spaces were distinct and had to be separately controlled.
	By itself this was little different than have N towers
	not bolted together.  The problem was the pass-through
	addressing wasn't SCSI compliant.  To move a tape from one
	side of the PTM to the other you had to use port addresses
	that weren't contiguous, and thus something that no reasonable
	SCSI-2 software implementation would expect.

	Software using the serial interface wasn't constrained by
	this, but that wasn't a very popular interface.  I think
	DECls used it.

	The advantage of MUSL is that the robot handles making 
	all the element space appear as one large robot.

    An excellent summary, and exactly what I needed.  Thanks for taking the
    time to write it!
    
    tl

	For UNIX and NT the choice of one mutli-tower or several
	single towers depends on your needs.  

	The multi-tower configuration has the primary
	advantage that any tape can go to any drive.  With only
	three drive in each TL820/822 tower this can be significant.

	Single towers allow simultanious operation.  NetWorker locks
	the complete unit while loading tapes, not just until the
	tape is moved, but until it can verify that it's the right
	tape by reading the first data record.  So if you have a 
	lot of tape changes then single towers may be faster.

	One general disadvantage to a MUSL configuration vs. single
	towers in the current firmware, is that if one tower can fail
	a Test Unit Ready command, the whole configuration fails the
	command.  This reduces the MTBF of the configuration.  Or
	at least this is how we were told it would work.  I haven't
	done anything to verify it.

	For the VMS products, HSM is probably better served with
	multiple independent towers.  I'm not sure about SLS and
	ABS.

    Hi
    
    I'm planning a couple of things, that I'd like to sanity check here.
    
    Near-term, I plan to add a second TL8nn to our NetWorker environment. 
    I'm planning to bolt the two TL8nn units together.  Here are the goods
    (+) and bads (-) I perceive:
    	+ any tape can go to any drive;
    	+ one virtual tape library, rather than two smaller ones;
    	- if one TL8nn fails, both fails [I may need more details on this]
    	others?
    If I don't bolt the boxes together, is that a MUML configuration?  Or
    can MUML support bolted boxes as well?
    
    Longer-term, I'm planning to have 4 TL893 boxes connected to a two-node
    TruCluster running Digital UNIX V4.0c (which, I believe, introduces
    sharing of tape devices) and NetWorker Vn.n (where 'n.n' introduces
    support for this configuration).  I'm very concerned about a problem on
    one box hanging all boxes.  Part of the work for this configuration
    will be to back up SAP R/3 archived redo logs.  I can't afford downtime
    for all boxes at the same time.
    
    Thanks in advances for your thoughts.
    tl

	MUML is the multi-tower configuration when the libraries
	are bolted together, but each robot controller (MUC) shows
	up a different logical unit of the same target ID.  It had
	the severe disadvantage of requiring moves between towers
	to do Element -> PTM -> other PTM -> Element.  This was
	further complicated by the fact that the PTM addresses
	don't follow the SCSI spec.

	If you have separate disconnected towers, you have separate
	disconnected towers.  One slight advantage is that if you have
	lots of robot operations going on, you can one such operation
	going on at the same time for each robot.  In a MUSL configuration
	the requests are serialized even if they could be done in
	parallel.

	If you take care to make sure that tapes a distributed properly
	between the units, several single units will be better.

	If the tapes all end up bunched up you could watch one unit
	stay busy while the others just wait.  This isn't a problem
	the the multi-tower mode.  

	If you do use single towers then you will need an IOD for each.

	Considering how much time you spend managing your backups, the
	cost in convenience of the multi-tower would not be worth
	the decrease in robustness.  This would be different for a user
	that just plugs it in and leaves it alone.

    Hi
    
    Thanks for the replies.  I've also learned, from the NETWORKER notes
    file, that NetWorker supports both MUSL and MUML, but (according to
    Kevin Farlee [note 179.6]):
    
    "If you run the MUML firmware, NetWorker will see it as multiple
    independant jukeboxes, incapable of interchanging tapes."
    
    So, even if the boxes are bolted together in a MUML configuration,
    NetWorker won't be able to move tapes between the boxes.
    
    So I'm pondering which is more valuable to me:  one virtual jukebox,
    where all media are accessible by all tape drives, or several
    jukeboxes, each with a fairly dedicated and segmented pool of tapes,
    but without a single point of failure (if one ATL fails, the others
    keep on going).
    
    tl