Since it wasn't specified, I assumed all 10 media servers were dedicated media
servers backing up clients over the network.
When you're talking about a large server that has another purpose, but is also
a media server to back itself up, currently there is one of two choices. As
you mentioned, you want to ensure that the media server backs itself up...
otherwise what's the point of it being a media server.
A class and/or schedule can only be configured one of two ways. You can
select "any available" or you can specify a stu. Unfortunately, if you
specify you can only specify one. Hopefully in the future we'll be able to
specify more than one and allow it to choose any available from that set of
selected stus, but we can't do that now.
stu configured as "on-demand" is easy. It does just as it says. The stu
doesn't get used unless it's specifically called by the class and/or schedule.
If you want the media server to back itself up and you don't want anyone else
to use this as a media server configure it this way.
If you use "any available" for the class and the schedule doesn't override it,
it does just that. It will use any available stu; however, you can add the
following to the bp.conf
MUST_USE_LOCAL_DRIVE
With this set you can have a class that is "any available" and put multiple
clients in it. If the client is not a media server it will go to any
available stu following the same old rules... and if there are no tapes
mounted that it can use (proper retention, mpx not reached, etc.) it will use
the first stu with drives available in alphabetical order... you can not
change this. If the client is also a media server this option will force it
to use itself, which is what we want. I believe this was new with 3.4. The
only problem is that other clients can also use this stu now. If you want it
to only back itself up and no one else, you have to do the "on-demand" way.
The second way also does not work well for a cluster where the media server
and the stu are configured with the physical node name, but the client being
backed up is an alias on the cluster. The only way I have found to force the
backup of the alias to a specific media server (which the alias also resides
on) is to use the "on-demand" method and to know what node will own that
alias. The only other way I have seen this done with MSCS clustering is a
"failover media server". I don't know if VERITAS has this with VCS or not.
It's only problem is that it only supports one "failover media server" in the
cluster so it can't be used in an active/active cluster configuration.
- Scott
"Trotman,
Kevin" To: "'scott.kendall AT abbott DOT
com'" <scott.kendall AT abbott DOT com>, "Lundy,
<Kevin_Trotman Mark" <mlundy02 AT sprintspectrum DOT
com>
@AFCC.com> cc: "'Veritas Support List
Server'"
<veritas-bu AT mailman.eng.auburn DOT
edu>
09/27/2001 Subject: RE: [Veritas-bu] How
many Storage Units do you have defined?
04:07 PM
Don't overlook that you want to make SURE that in a SAN environment, the stu
that is picked for a SAN client is the one that has that client listed as a
media server. Define one stu for each robot for that particular client at
most, with an appropriate number of drives, but don't allow it to just make
an alphabetical choice when picking the stu used. If it does not
consistently pick itself to backup through, then you will have to force it
to use its own stu by selecting it instead of "any available."
Remember, a stu is basically for load balancing purposes in a SAN
environment, so you can make these choices yourself. To load balance a group
of clients, you can move them from one robot to the other by changing the
robot number. You can choose how many tape drives each should use, moving a
higher number of drives to a specific client's stu. To do this correctly,
however, each client needs to have its own stu that lists a number of drives
that it should use a specific robot that it should use. And allowing the
software to override your careful planning is a BAD idea! Use the "any
available" option with extreme care and watch which media servers the
clients use carefully!
-----Original Message-----
What I would do is create 1 stu with 4 drives for each media server for each
32 drive robot. Then a 2 drive stu for each media server for each 16 drive
robot. Name the stus so they are picked out of the list alphabetically in a
manner that spreads the load nicely across the media servers and robots.
That
would give you a total of 40 stus.
|
