SSO and FC I/O Blade configuration question

[tommcf64]

Hi,

We are running NetBackup 7.6.0.4 with a Quantum I500 utilizing SSO, and I have a question about the Host Mapping of the medium changer.  According to the Quantum manual:

There is also an internal (i.e., not attached to a port) controller device

presented at LUN 0 by default. The controller device facilitates

initialization and device discovery. In some instances it may be useful to

map the controller device to a different LUN if an application typically

expects to see a media changer device (partition) or tape drive at LUN 0.

Does NetBackup expect the media change to be mapped to LUN 0?  Currently we have the medium changer mapped to LUN 1 and it seems to be causing issues with the drives on the blade were this mapping is set.  Below is a screenshot of the mapping:

Description	Type	Serial Number	Vendor	Product	Lun
Control LUN	Processor	AMP021897-0073	QUANTUM	FC IOB	0
Drive[-1,1](library_a)	Sequential Access	F09D76B090	IBM	ULTRIUM-TD4	2
Drive[-1,2](library_a)	Sequential Access	F09D76B094	IBM	ULTRIUM-TD4	3
Drive[-1,3](library_a)	Sequential Access	F09D76B098	IBM	ULTRIUM-TD4	4
Drive[-1,4](library_a)	Sequential Access	F09D76B09C	IBM	ULTRIUM-TD4	5
library_a	Medium Changer	ADICA0C0148217_LLA	ADIC	Scalar i500	1

Thank you in advance,

Tom

[sdo]

1) Is this whole SSO environment a new build of a new NetBackup domain, which has not yet been productionised?

2) If so, why not test by de-mapping the 'Control LUN / Processor', and mapping the robot as LUN 0, and then mapping the drives in ascending LUN order to match the phyiscal drive number locations within the enclosure?

3) Can I ask if you have a specific reason why you have the 'Control LUN / Processor' mapped as a LUN at all?  Can't you simply give it a LUN ID of 250, and NOT present this LUN ID of 250 to any servers?

[tommcf64]

Hi,

  Thank you for your reponse.  This is a production enviroment.  I am going to try mapping the media changer to LUN 0 but we have a small maintaience window and I was trying to see if anyone had a similar library.  As for question three.  The Storage team zoned the hba card on the master server to the active FC I/O card on the blade, and in the host mapping the Control Lun, the media chnager and the 4 drives are available to be configured. If I do not select the medium changer the Windows O/S does not see the robot.  We are seeing several errors in the event viewer related to this issue.  Some I have listed bellow:

TLD(0) key = 0x2, asc = 0x4, ascq = 0x1, LOGICAL UNIT IS IN PROCESS OF BECOMING READY

TLD(0) going to DOWN state, status: Unable to sense robotic device

TLD(0) Mode_sense error

TLD(0) going to DOWN state, status: Timeout waiting for robotic command

TLD(0) [5348] timed out after waiting 855 seconds for ready, drive 6

Despite these errors the tape library does not go down, only certain drive paths go down.

Thank you,

Tom

[Marianne]

TLD(0) key = 0x2, asc = 0x4, ascq = 0x1, LOGICAL UNIT IS IN PROCESS OF BECOMING READY

Hopefully you are stopping NBU services while making changes at SAN and/or OS-level?

The above message is normally seen when robot is busy coming up after power reset or when robot door has been opened and closed. 

The rest of the errors are pointing to comms issues between robot and tape drives and between tape drives and OS.

[tommcf64]

Hi Marianne,

  Thank you for responding.  I am stopping NetBackup before making the changes. We appear to have an issue on the blade which the library is zoned to.  I was trying to find out if NetBackup expects the medium changer to be mapped to LUN 0 on the FC/IO blade?  Currently we have the Control lun mapped to LUN0.

Thank you,

Tom

[sdo · Accepted solution]

Re medium change on LUN 0 - does the tape library vendor not have a set of best practices or recommendations for NetBackup?

I bet they do.  You just have to try to get hold of a person who has that info.

.

Personally, I've always put the medium changer on LUN 0 - I can't say I have a specific reason for that, it's just what I and others have always done.

Why not try switching LUN 0 and LUN 1 around.  The documentation you posted seems to suggest that the vendor has fairly often seen the need to switch them around.

[tommcf64]

The documentation is vague and implies it is application  specific.  I am going to try changing it to LUN 0 next week.

Thanks Tom

[mph999 · Accepted solution]

I don't think NBU will care, generally, as long as the OS can see the device is all that matters.  Maybe there could be a case where odd things happen regarding this, but in 8 years, I've never seen it 

In fact, on some IBM  libraries, the changer is accessed via a tape drive path, but one lun extra,  so the drive is lun 0, and the robot lun 1, works perfectly, so no, NBU doesn't expect the changer on lun 0