Bob,
Thank you for the suggestions.. I was able to get the SSO (Shared Storage
Option) option working within the SAN environment. In fact, I think I
originally had it working and didn't realize it because of the way the new
gui represents some of the information. I think the most confusing part was
the combination of media servers, device hosts, volume database, etc.
In the new java gui I would see Media server1, but media server2 would not
show up. I would have to click on the append media server to see
information about the second media server. Then depending on how the
vm.conf was configured would determine what information was seen for device
hosts. In the end I realized that On media server1 I would see device hosts
with server1 and server2 under them. Then they both had information about
the robot and multihosted drives. But media server2 when added to the gui
would show a red dot next to the robot under device hosts. I originally
thought that this meant that media server2 was not configured correctly.
What it really means is that the volume database was centralized on the
master server, and in addition my robotic control was set up on master
server1. The multihost SSO (shared storage option)was shown correctly at
the device hosts level when looking at the properties of the drives within
the library.
I configured the two storage units, and if I remember correctly, one storage
unit was configured as the multi-hosted drive that resided on server1 and
the other was configured as the multi-hosted drive that resided on server2.
The class was configured such that it specified the particular class. We
performed backups and verified that backups from server2 used server2 as the
media manager and likewise for server1. We also needed a way to verify that
the backups were going over the SAN and not the network. We used the SAN
admin tool to verify the number of frames received and transmitted before a
backup. We then performed backups from both media servers and verified that
we saw SAN traffic and that it was only increasing significantly over the
connection to the the library and the media server.
The volume database on the second media server actually had to be 8 bytes.
There is a small amount of information stored there. But it helped to know
that I shouldn't see 604+ bytes there.
Dan Sixbury
-----Original Message-----
From: Bob Bakh [mailto:bbakh AT veritas DOT com]
Sent: Thursday, March 01, 2001 9:21 PM
To: Harold Skelly Jr.; ricky.l.keahey AT intel DOT com
Cc: dsixbury AT saint-lukes DOT org; veritas-bu AT mailman.eng.auburn DOT edu
Subject: RE: [Veritas-bu] 81 errors
The best thing to do is do all the configurations from the master.
Delete anything you have on any of your other Media Servers and check under
/usr/openv/volmgr/database and see if the VolDB size is greater than 0, if
it is then shut down the daemons on that server and delete it. Also delete
what you have configured on that server.
If it's an NT replace Daemon with Service and /usr/openv with c:\program
files\veritas
Now go to the master and from there in it's media manager GUI create the
robot and the multi hosted drives. This way the logical name will be the
same on all servers and the volume database host will be the master or what
ever system you set up as the robotic control host.
I can't stress enough how important it is to do it this way. No matter how
adept you are at NetBackup, you are prone to screwing this up in a SAN
environment and running the GUI on the master keeps you safer. This is one
of the few things that the GUI does much better than the command line
interface.
Bob
-----Original Message-----
From: Harold Skelly Jr. [mailto:hskelly AT colltech DOT com]
Sent: Thursday, March 01, 2001 5:27 PM
To: ricky.l.keahey AT intel DOT com
Cc: hskelly AT colltech DOT com; dsixbury AT saint-lukes DOT org;
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] 81 errors
Oooops, I expressed that incorrectly. The drive(s) should be uniquely
named.
If a drive is visible to more that one host, it should be visible as the
same
name on each host. It comes from the 2nd page of the change attributes of
a multihosted drive using the java GUI.
Hal
"Keahey, Ricky L asserts: "
=]
=] Just curious. This is the first time that I have heard about naming the
=] drives different on each server. What is the purpose of this? Does it
=] cause problems if the drives are named the same on each server? The
wizard
=] I have found is very helpful if you only have one media server in your
=] environment, but if you have more than one host controller it can really
=] mess things up. I myself also use the tpconfig in a script to configure
the
=] drives.
=]
=] Rick
=]
=] -----Original Message-----
=] From: Harold Skelly Jr. [mailto:hskelly AT colltech DOT com]
=] Sent: Thursday, March 01, 2001 4:43 PM
=] To: dsixbury AT saint-lukes DOT org
=] Cc: veritas-bu AT mailman.eng.auburn DOT edu
=] Subject: Re: [Veritas-bu] 81 errors
=]
=]
=] Dan, do you actually see the shared drive on media server, server2? I
found
=] the
=] wizards to be non-helpful in setting up SSO. I used the tpconfig
interface
=] with
=] much better effect.
=]
=] Hal
=]
=] ps. don't forget to name the drives uniquely on each server even though
=] shared.
=] H.
=]
=] "Sixbury, Dan asserts: "
=] =]
=] =]
=] =] I am backing up via 2 media servers across a SAN to shared tape drive
in
=] a
=] =] library. Master/Media server1 is able to back up without problems to
the
=] =] library.
=] =]
=] =] When I try to backup files from/through media server, server2 I get 81
=] =] errors. 81 says that the Media Manager volume daemon is not active,
yet
=] I
=] =] can tell that the vmd is in fact running. If I play around with
vm.conf
=] I
=] =] will sometimes get a status 96 error?
=] =]
=] =] Thanks,
=] =] Dan
=] =] _______________________________________________
=] =] Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
=] =] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
=] =]
=]
=]
=] --
=] ==============================================================
=] \ \ |
=] \ \ \ | Hal Skelly, consultant
=] \ \ * * | Solaris, Backup, Storage Management
=] \ \ * |
=] \\ * COLLECTIVE | BEST WAY: hskelly AT colltech DOT com
=] \* | (619) 218-2291 (cell)
=] * | http://www.colltech.com
=] | Pager: 1-800-946-4646, pin 1468718
=] ==============================================================
=] _______________________________________________
=] Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
=] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
=]
=]
--
==============================================================
\ \ |
\ \ \ | Hal Skelly, consultant
\ \ * * | Solaris, Backup, Storage Management
\ \ * |
\\ * COLLECTIVE | BEST WAY: hskelly AT colltech DOT com
\* | (619) 218-2291 (cell)
* | http://www.colltech.com
| Pager: 1-800-946-4646, pin 1468718
==============================================================
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
