11-15-2016 11:38 AM
We are [mostly] an AIX shop with AIX 7.1 backup masters running NB 773. We use mostly Storagetek L700 silos (we have one IBM library).
Officially Veritas says:
NetBackup has been supporting non-IBM tape libraries (robotics) with an IBM AIX robotic control host using the "ovpass" driver for many years. Changes and new functionality in AIX 6.1 and 7.1 have resulted in some issues with ovpass and an inability to support new functionality such as dynamic tracking and controlling SAS robots. Therefore, beginning with NetBackup 7.5, Symantec is no longer supporting the ovpass driver. Existing customers may continue to use ovpass as they are today, but if issues are encountered Symantec will not be able to resolve them. Symantec recommends using another OS platform as the robotic control host.
Then what is an AIX-master shop to do? Does Veritas mean we can have another server (a media server) that is something other than AIX simply to do robot control? I am not sure I understand how that would work.
11-15-2016 11:57 AM
If all robots and drives are visible to all media servers, i.e. you have a complete site wide SSO config, then a Linux media server could be added to the environment (assuming that the total number of SSO paths does not go above 255)... then whilst this Linux media server would have storage units, you just don't send any backups via that media server, and just ensure that only that one server is the robot control host.
If you have an environment where each individual library is tied specifically to one media server... then... well... I can only empathise.
How is robot control achieved with your StorageTek libraries ? Via direct connect SAS, or via LUN 0 via SCSI over FC, or via IP over LAN/ethernet ?
If you are not using SAS libraries then, the wording of the text that you posted might be construed as implying that you might not have any problems.
11-15-2016 01:53 PM
The robot control (as I understand it) is thru SCSI over FC.
I have a pair of windows servers (one is the master and one is a medis server) that both see the same L700 library. I then see that at any given time one has a robotic path listed and one does not (probably which ever one came up first). I guess the one showing a robotic path is doing the robotic control?
Similarly for my situation - as you saying I could have the AIX master server see the L700 library and also have a Linux media server see the same L700 library - but the Linux media servers sole function would be to perform the robotic control? The Linux server would not perform any backups.
11-15-2016 02:56 PM - edited 11-15-2016 03:00 PM
SC: The robot control (as I understand it) is thru SCSI over FC.\
sdo: Sounds like should be ok, if the vendor (Veritas) expressed limitation is solely restricted to SAS connectivity. Maybe worth asking them what they really mean.
SD: I have a pair of windows servers (one is the master and one is a medis server) that both see the same L700 library.
sdo: ok
SC: I then see that at any given time one has a robotic path listed and one does not (probably which ever one came up first). I guess the one showing a robotic path is doing the robotic control?
sdo: Yes, sounds reasonable. Did you know that you can control which server always has robotic control?
SC: Similarly for my situation - as you saying I could have the AIX master server see the L700 library and also have a Linux media server see the same L700 library - but the Linux media servers sole function would be to perform the robotic control?
sdo: Sorry, I thought you said you had a Windows based master. Or do you have multiple masters with their own sets of libraries? But I think you would only need this for SAS connectivity libraries. I think the Veritas statement is too generic. I'd ask them for a clearer definition on whether ovpass will always be supported as long as SAS is not used perhaps?
SC: The Linux server would not perform any backups.
sdo: Actually the converse statement might be true. If a new or existing library was SAS conencted then only the directly connected Linux host could be used for write because SAS libraries are typically not shared.
.
I think what we're missing is what you've actually got. Any chance of a bit of a basic topology map?
e.g. a table by media server, we don't need to see real names, just some kind of name token that expresses the config (where the columns can repeat- but sort by media server):
Master Server Master OS Media Server Media OS Connectivity Library
masterA Windows masterA Windows FC library1
masterA Windows mediaA Windows FC library1
masterB AIX - - - -
masterB AIX mediaB AIX FC library2
.
Or maybe such a table is a moot point... if all of your connectivity is FC and you have no plans to introduce SAS connected libraries (which typically cannot be SSO anyway) - then maybe you have not too much to worry about - but you are right, definitely worth checking out in more detail with Veritas.
If you do plan to deploy new SAS connected tape libraries, then clearly you are not going to be able to connect them to AIX based hosts.
11-15-2016 03:13 PM
Can you post the link to the doc that carries the vendor text from your opening post? I want see what the published date was, i.e. when they let their customers know about this?
11-15-2016 03:14 PM
11-15-2016 03:18 PM
We have three independent master servers each connected to an L700. One is Windows; two are AIX.
I gave the Windows example because that is the only one in which I already have a master server plus a media sharing an L700.
I'd like to setup the same for our two AIX master servers if that will get us out of the 'ovpass not supported for AIX for non-IBM libraries' situation.
11-15-2016 10:36 PM
yes its still valid.... smc drivers are still valid. Do you see any challenges using it ? Would you like to post it here.
11-16-2016 12:14 AM
The note in HCL also says: "... Existing customers may continue to use ovpass as they are today ...."
The L700s are very old, so the assumption is that you have been using ovpass drivers for some time now?
Have you been experiencing issues related to ovpass?
If so, best to add a Windows media server for robot control.
Since you need to license an new media server, you may as well configure it with tape drives as to share the backup load.
11-16-2016 08:47 AM
Ovpass continues to work for us. But when we have to manually build the ovpass device (when, for example, we rebuild the AIX backup master on new hardware) it's a manual process that is technically not supported. Our support vendor has been very good about helping us the last two times we've needed to build the ovpass device but we also know its a 'best effort' basis since ovpass is not supported by Veritas anymore.
11-16-2016 08:53 AM
I like the idea of introducing a Windows media server to do the robot control since I have experience with that already. If we went with a Linux media server that would be new ground for us.
Is there any way for the Windows media server to be a VM? Right now all our master and media servers are physical machines since they have Fiber cards in them to talk to the tape silos thru the switch. I would think we need physical so we can have a fiber attachment to the silo?
11-16-2016 09:05 AM
We use the SMC drivers for our IBM library. Its the ovpass that we use to talk to the Storagetek that we are concerned about. It works fine but Veritas says its unsupported.
11-16-2016 10:12 AM
11-16-2016 10:47 AM
"Did you know that you can control which server always has robotic control?"
sdo - How do I do that?
11-16-2016 10:53 AM
OK - thanks for that info.
Procuring a Windows server beefy enough to actually perform backups to tape will be difficult. But if I can get two minimal windows servers built (for each AIX master) and insert a FC card in each one than they could do the robotics control?
11-16-2016 10:58 AM
11-16-2016 02:31 PM
Personally, if there is a possibility, I would let a Unix/ Linux server be the robot control host.
Why - because Linux/ UNix OS have a number of tools that can be used for troubleshooting, Windows has about 0. Given that the majority of robot/ drives are not NetBackup related, you can see why I make this point.
11-16-2016 04:23 PM
As thankfully usual... some sage advice from mph999.