Changing tape library control host

[CadenL]

Hi all

I have a previous post (see link) that gives an account of what I'm looking to do  - which incidently has one more question about the bpmedia command if any fancy's trying to answer that for me 

https://vox.veritas.com/t5/NetBackup/Moving-a-tape-library-to-a-different-media-server-in-the-same/t...

But in summary I'm replacing an old 5230 appliance media server with a new 5340 appliance media server (the master server is a windows 8.1.2 vm). The backup policies have already been reconfigured to the MSDP on the 5340 but there is still an FC attached tape library on the 5230 where these backups duplicate to. I want to move the tape library now so that it is owned by the 5340. Eventually I will decommission the older 5230.

I wanted to see if there was an easier, non disruptive way to achieve this by using the SSO option - would the following work:

• Make sure the SSO license is installed on the master server
• Zone the FC tape library so it is visible to the 5340 as well as the 5230 appliance
• Scan the 5340 appliance to discover the tape robot and tape drives
• Run the device configuration wizard on the master server
• Ensure it identifies the robot and tape drives on the 5230 and 5340 as shared drives
• Complete the device configuration wizard and restart LTID on both appliances
• Run a library inventory to ensure all the installed media is up to date
• Edit the tape robot properties to make the 5340 the robot control host
• Create a new storage unit for this tape library
• Edit all backup policies and SLPs to use this storage unit
• At a future date run the nbdecommission procedure on the 5230 to remove all references and allow the 5230 to be switched off

My main questions are

• Is the above a feasible solution with minimal disruption?
• Do I have the correct order of activities?
• Are there steps here that I don’t need to do\should do differently or have left out?

Many thanks

[sdo · Accepted solution]

The order of steps looks ok.

You might want to enable unrestricted media sharing:

https://www.veritas.com/content/support/en_US/doc/18716246-126559472-0/v15887824-126559472

.

And the fly in the ointement... is... that... some say that the RedHat Linux OS inside an Appliance needs an actual physical reboot after zoning / re-zoning LUNs from FC SAN disk arrays for use as VMFS datastores... and so... personally myself I cannot be sure that you will not also require a reboot after zoning new FC SAN WWPN and presenting new SCSI LUNs as tape drives.  The word was that this isn't so much a NetBackup problem per se, because all NetBackup is interested in is SCSI devices, and so the impression is that it is a RedHat thing, in so far as RedHat perhaps isn't quite so plug-and-play when it comes to re-working its own internal OS driver stack view of the world from FC up through SCSI up to /dev/blah.

[Marianne]

@CadenL 

I stopped reponding because I am confused about what has been done already and what still needs to be done. 

In your other post, you said that backups have already been redirected to the new media server. 

So, this means that zoning was already done, right? 

[CadenL]

Hi Marianne

Sorry for the confusing and thanks for sticking with this.

The zoning hasn't been done yet, what I meant by the backups being redirected to the new media server is in relation to the MSDP stage only. The SLP is to first backup to MSDP and then duplicate to tape. The SLPs have been amended so the client backups now go to the MSDP on the new media server before being duplicated to tape - however, as the tape is still only visible and controlled by the old media server and so when the duplicate jobs run they go over the network to the old media server before going to tape.

I'm looking to get the tape library visible and controlled by the new media server to keep this from going over the network and eventually plan to decommission the old media server.

Initially I thought I would need to remove the library from the old server and add it to the new server, however, if I have the SSO licence I may be able to do this quicker and with less distruption.

many thanks again

[sdo]

IMO, I think you should expect to have to reboot, and so (IMO) you should plan to have to do that.  By all means try to avoid it, but I can't help but think that the plug-and-play-ness of RedHat isn't quite as responsive / cohesive as we would necessarily like or expect from that OS.

Look at this way, if RedHat thelselves deem it worthy to publish an article such as this:

https://access.redhat.com/solutions/3941

...then (IMO) that has to imply something, there must be a reason why they publish this for their customers.

Now then, layer on top of that (side-by-side) the Appliance CLIsh and also the NetBackup application itself... and you can kind of begin to see why sometimes there's no avoiding an OS reboot.

I guess the final question is... do you really want to get down and dirty with RedHat Fibre Channel drivers and resetting / re-scanning the FC HBAs (ask yourself: can you single them out, disk versus tape, can you be sure that you reset the correct tape only HBA) and SCSI mapping and not involve the CLIsh ?

I'm sure that NetBackup won't mind, as the CLIsh and NetBackup are not tightly coupled.  But the appliance CLIsh and RedHat... hmmm... I suspect that deep early elements of the CLIsh boot-up prepares the CLIsh for its view of the OS world (until next reboot), and if you go changing that view manually using advanced OS techniques that the CLIsh does not itself offer you, then well, you would be circumventing the CLIsh.

IMO, reboot the appliance at some point after zoning. Look at this way, after zoning new WWPNs and new LUNs then you would reboot for Solaris, you would reboot for Windows, you would reboot for AIX, and you would reboot for RedHat - and the appliance is, after all, built on RedHat.

[CadenL]

Thanks both

That all seemed to work fine - in the end I didn't reboot and it all seems ok, but we've a maintenance weekend over Christmas so these appliances will get a reboot at that time anyway.

many thanks

[sdo]

Well done, and thanks for the feedback and for confirming that a reboot wasn't necessary when zoning new WWPN(s) and presenting new robot and tape drive LUNs to a 5340 Appliance.