This is a multi-part message in MIME format.
------_=_NextPart_001_01C5EC55.294B9FB5
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
The only time I use storage unit groups is when I have drives from two
robot's connected on the same media server. Since a storage unit is tied
to a paticular robot, you have to make two storage units if you have
drives from two robots. In the policy, you can only select 1 storage
unit or group. By making a storage unit group with both storage units in
it, you are able to have failover to the other drives in another robot
if the first one goes down.
=20
Thanks,
=20
Kris
________________________________
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Dean
Sent: Friday, November 18, 2005 12:56 AM
To: dale AT daleking DOT org; veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Why use storage unit groups?
Dale,
Some comments below.
On 11/18/05, Dale King <dale AT daleking DOT org> wrote:
A collegue and I in different parts of our organisation were
discussing
the use of storage unit groups. My philosophy is that you
should have a=20
single storage unit per media server - robot pair set to use all
drives
for sanity, with max multiplexing set at the highest you would
want to go.
This is easy to manage and I think is the most efficient way to
use your=20
drives.
Yep, pretty simple and manageable. If that kind of setup meets your
needs, then go for it.=20
The other theory put forward is that you have multiple storage
unit groups
limiting each individual storage unit to one or two drives
depending on=20
policy requirements. My collegue says this has been used to
resolve
problems where multiple policies using different volume pools
want to run
to the same storage unit thereby causing some sort of exclusive
lock.=20
I have never seen this storage unit lock - perhaps back in the 3.4 days.
Lock-outs happen more at the drive level. I'm certain you can have 2
streams with different retentions writing to 2 drives in the same
storage unit.
The reasons for using groups that I know of are:
- you have multiple robots and prefer one over the other
but are=20
happy to use both
- you want to load balance the same robot across two or
more media
servers for a single policy
- you have drive contention and want to set some crazy
high=20
multiplexing value on your last few drives so that
drives don't
fail
I worked with a system where we had around 10 media servers sharing a
set of 5 tape drives. All 4 drives were shared to all 10 media servers.
We had 15 or more Storage Units defined, but all pointed to the same
library and the same 5 tape drives, with the same MPX settings.
In this case, the storage units were used to bind a backup policy to a
particular Media Server. Some of them were just SAN Media Servers, but
some where full Media Servers, so we needed to use the Storage Units to
ensure that the backups were written by the correct Media Server. Some
of the SAN Media Servers were also part of a cluster, so this added to
the complexity. We had to define more Storage Units which were tied to
the cluster packages (virtual hosts).
It doesn't sound like the above is relevant to your situation, but I'm
just trying to give a different example of using Storage Units.
As for Storage Unit Groups, I saw one need for it. We offloaded Oracle
archivelogs to tape using User Archives. During business hours, one of
these archives would run every 5 minutes or so. It was quite important
that the archives ran and completed in a reasonable timeframe, lest the
archivelog filesystem fills up and Oracle gets upset.
So, in this case, we had one preferred Storage Unit (Media Server) to do
the job. However, if each of the 4 drives was in use by one of the
*other* full Media Servers, we were happy to divert the archivelog
backup to another Media Server.
Storage Unit Groups might have been helpful here. Unfortunately I could
never get it to work the way I wanted and gave up. But that was back
when STorage Unit Groups were first introduced - it probably works a bit
better now. I can't recall the specific problems.
I've typed enough! Hope that helps.
Regards,
Dean
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
=09
iD8DBQFDfQGR/dB3EOgAfiQRAsdbAJ9mHrZWYzs2nuR5XK+TmL5sYe2FSgCfcNm1
4yNwjbhhcjXPLeWQWFSkJ6U=3D
=3DysUc
-----END PGP SIGNATURE-----
=09
=09
=09
------_=_NextPart_001_01C5EC55.294B9FB5
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246392815-18112005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>The only time I use storage unit groups is =
when I have=20
drives from two robot's connected on the same media server. Since a =
storage unit=20
is tied to a paticular robot, you have to make two storage units if you =
have=20
drives from two robots. In the policy, you can only select 1 storage =
unit or=20
group. By making a storage unit group with both storage units in it, you =
are=20
able to have failover to the other drives in another robot if the first =
one goes=20
down.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246392815-18112005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246392815-18112005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246392815-18112005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D246392815-18112005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Kris</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> =
veritas-bu-admin AT mailman.eng.auburn DOT edu=20
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] <B>On Behalf Of=20
</B>Dean<BR><B>Sent:</B> Friday, November 18, 2005 12:56 =
AM<BR><B>To:</B>=20
dale AT daleking DOT org; veritas-bu AT mailman.eng.auburn DOT
edu<BR><B>Subject:</B> =
Re:=20
[Veritas-bu] Why use storage unit groups?<BR></FONT><BR></DIV>
<DIV></DIV>Dale,<BR>Some comments below.<BR><BR>
<DIV><SPAN class=3Dgmail_quote>On 11/18/05, <B =
class=3Dgmail_sendername>Dale=20
King</B> <<A =
href=3D"mailto:dale AT daleking DOT org">dale AT daleking DOT org</A>>=20
wrote:</SPAN><BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">A=20
collegue and I in different parts of our organisation were =
discussing<BR>the=20
use of storage unit groups. My philosophy is that you =
should have a=20
<BR>single storage unit per media server - robot pair set to use all=20
drives<BR>for sanity, with max multiplexing set at the highest you =
would want=20
to go.<BR>This is easy to manage and I think is the most efficient way =
to use=20
your <BR>drives.</BLOCKQUOTE>
<DIV><BR>Yep, pretty simple and manageable. If that kind of setup meets =
your=20
needs, then go for it. <BR></DIV><BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">The=20
other theory put forward is that you have multiple storage unit=20
groups<BR>limiting each individual storage unit to one or two drives =
depending=20
on <BR>policy requirements. My collegue says this has been =
used to=20
resolve<BR>problems where multiple policies using different volume =
pools want=20
to run<BR>to the same storage unit thereby causing some sort of =
exclusive=20
lock. </BLOCKQUOTE>
<DIV><BR>I have never seen this storage unit lock - perhaps back in the =
3.4=20
days. Lock-outs happen more at the drive level. I'm certain you can have =
2=20
streams with different retentions writing to 2 drives in the same =
storage=20
unit.<BR></DIV><BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">The=20
reasons for using groups that I know of=20
are:<BR> - you have =
multiple=20
robots and prefer one over the other but are=20
<BR> happy =
to use=20
both<BR> - you want to =
load=20
balance the same robot across two or more=20
=
media<BR> serv=
ers=20
for a single =
policy<BR> - you=20
have drive contention and want to set some crazy high=20
=
<BR> multiplex=
ing=20
value on your last few drives so that drives=20
=
don't<BR> fail=
</BLOCKQUOTE>
<DIV><BR>I worked with a system where we had around 10 media servers =
sharing a=20
set of 5 tape drives. All 4 drives were shared to all 10 media servers. =
We had=20
15 or more Storage Units defined, but all pointed to the same library =
and the=20
same 5 tape drives, with the same MPX settings.<BR><BR>In this case, the =
storage=20
units were used to bind a backup policy to a particular Media Server. =
Some of=20
them were just SAN Media Servers, but some where full Media Servers, so =
we=20
needed to use the Storage Units to ensure that the backups were written =
by the=20
correct Media Server. Some of the SAN Media Servers were also part of a =
cluster,=20
so this added to the complexity. We had to define more Storage Units =
which were=20
tied to the cluster packages (virtual hosts).<BR><BR>It doesn't sound =
like the=20
above is relevant to your situation, but I'm just trying to give a =
different=20
example of using Storage Units.<BR><BR>As for Storage Unit Groups, =
I saw=20
one need for it. We offloaded Oracle archivelogs to tape using User =
Archives.=20
During business hours, one of these archives would run every 5 minutes =
or so. It=20
was quite important that the archives ran and completed in a reasonable=20
timeframe, lest the archivelog filesystem fills up and Oracle gets=20
upset.<BR></DIV><BR>So, in this case, we had one preferred Storage Unit =
(Media=20
Server) to do the job. However, if each of the 4 drives was in use by =
one of the=20
*other* full Media Servers, we were happy to divert the archivelog =
backup to=20
another Media Server.<BR><BR>Storage Unit Groups might have been helpful =
here.=20
Unfortunately I could never get it to work the way I wanted and gave up. =
But=20
that was back when STorage Unit Groups were first introduced - it =
probably works=20
a bit better now. I can't recall the specific problems.<BR><BR>I've =
typed=20
enough! Hope that helps.<BR>Regards,<BR>Dean<BR>
<BLOCKQUOTE class=3Dgmail_quote=20
style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">-----BEGIN=20
PGP SIGNATURE-----<BR>Version: GnuPG v1.4.1=20
=
(GNU/Linux)<BR><BR>iD8DBQFDfQGR/dB3EOgAfiQRAsdbAJ9mHrZWYzs2nuR5XK+TmL5sYe=
2FSgCfcNm1=20
<BR>4yNwjbhhcjXPLeWQWFSkJ6U=3D<BR>=3DysUc<BR>-----END PGP=20
SIGNATURE-----<BR><BR><BR></BLOCKQUOTE></DIV><BR></BODY></HTML>
------_=_NextPart_001_01C5EC55.294B9FB5--
|
