------=_Part_97_4506359.1132293384130
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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
> 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
> drives.
Yep, pretty simple and manageable. If that kind of setup meets your needs,
then go for it.
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
> 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.
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 stream=
s
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
> 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
> 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 o=
f
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 thes=
e
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 th=
e
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)
>
> iD8DBQFDfQGR/dB3EOgAfiQRAsdbAJ9mHrZWYzs2nuR5XK+TmL5sYe2FSgCfcNm1
> 4yNwjbhhcjXPLeWQWFSkJ6U=3D
> =3DysUc
> -----END PGP SIGNATURE-----
>
>
>
------=_Part_97_4506359.1132293384130
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Dale,<br>
Some comments below.<br><br><div><span class=3D"gmail_quote">On 11/18/05, <=
b class=3D"gmail_sendername">Dale King</b> <<a href=3D"mailto:dale@dalek=
ing.org">dale AT daleking DOT org</a>> wrote:</span><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">A collegue and I =
in different parts of our organisation were discussing<br>the use of storag=
e unit groups. My philosophy is that you should have a
<br>single storage unit per media server - robot pair set to use all drives=
<br>for sanity, with max multiplexing set at the highest you would want to =
go.<br>This is easy to manage and I think is the most efficient way to use =
your
<br>drives.</blockquote><div><br>
Yep, pretty simple and manageable. If that kind of setup meets your needs, =
then go for it. <br>
</div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid=
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The oth=
er theory put forward is that you have multiple storage unit groups<br>limi=
ting each individual storage unit to one or two drives depending on
<br>policy requirements. My collegue says this has been used to =
resolve<br>problems where multiple policies using different volume pools wa=
nt to run<br>to the same storage unit thereby causing some sort of exclusiv=
e lock.
</blockquote><div><br>
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.<br>
</div><br>
<blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The reasons for u=
sing groups that I know of are:<br> &nbs=
p; - you have multiple robots and prefer one over the other but are
<br> happy to us=
e both<br> - you want to loa=
d balance the same robot across two or more media<br> &nbs=
p; servers for a single policy<br> =
- you have drive contention and w=
ant to set some crazy high
<br> multiplexin=
g value on your last few drives so that drives don't<br> &=
nbsp; fail</blockquote><div><br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
</div><br>
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.<br>
<br>
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.<br>
<br>
I've typed enough! Hope that helps.<br>
Regards,<br>
Dean<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid r=
gb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-----BEGI=
N PGP SIGNATURE-----<br>Version: GnuPG v1.4.1 (GNU/Linux)<br><br>iD8DBQFDfQ=
GR/dB3EOgAfiQRAsdbAJ9mHrZWYzs2nuR5XK+TmL5sYe2FSgCfcNm1
<br>4yNwjbhhcjXPLeWQWFSkJ6U=3D<br>=3DysUc<br>-----END PGP SIGNATURE-----<br=
><br><br></blockquote></div><br>
------=_Part_97_4506359.1132293384130--
|
