On Fri, May 19, 2006 at 10:05:38PM -0400, Allen S. Rout wrote:
> > I have questions about server sizing and scaling. I'm planning to
> > transition from Networker to TSM a client pool of around 300 clients,
> > with the last full backup being about 7TB and almost 200M files. The
> > TSM server platform will be RHEL Linux.
>
> > I realize putting all of that into one TSM database is going to make it
> > large and unwieldy.
>
> You may be underestimating TSM; the size there is well in bounds for
> one server. The file count is a little high, but I'm not convinced
> it's excessive. The biggest server in my cluster has 70M files, in a
> 70% full DB of 67GB assigned capacity. So if that means 67GB ~= 100M
> files, you might be talking 130-150GB of database. I wouldn't do that
> on my SSA, but there's lots of folks in that size range on decent
> recent disk.
I don't have a lot of a priori knowledge of TSM, so any sizing
recommendations I've seen have come from the Performance Guides,
interviews with a few admins, and general consensus from web searches
I've done. I agree that if the general concern is getting database
operations done in a managable timeframe, as long as I can architect the
db disk well enough, it should size-scale-up fairly well. Thoughts on
that?
> Do you feel your file size profile is anomolous? My 70M file DB is
> ~23TB; that ratio is an order of magnitude off mine, and my big server
> is a pretty pedestrian mix of file and mail servers.
My numbers come from the Networker reports on the last full. Our
domain is largely desktop systems with everything being backed up.
Those large numbers of small files puts our average system at 722k files
and 29GB of storage (averaging 39k a file?) I'm trying to float towards
just protecting user data (and not backing up C:\Windows 250 times,
especially on systems where we would never do a baremetal restore.) A
compromise against management that doesn't want to risk data loss by
people putting things in inappropriate (and not backed up) places would
be to use different MCs to provide almost no versioning outside of
defined user data spaces -- but that doesn't get around my high file
count problem.
> I have heard of some dual-attach SCSI setups, but never actually seen
> one in the wild. If I were going to point at one upgrade to improve
> your life and future upgrade path, getting onto a shareable tape tech
> would be it. I have drunk the FC kool-ade. It's tasty, have some. :)
I don't disagree. Maybe I'll start looking at storage routers to share
my SCSI drives over FC.
> > Tape access-wise, is there a hardware advantage putting multiple
> > instances on the same system?
>
> Yes, it solves your drive sharing problem. All the TSM instances
> would be looking at /dev/rmtXX. Your LM instance can do traffic
> direction to figure out who's got the drive, and they are all using
> the same bus, same attach.
Ah, that helps. I guess I could design one beefy system as a sole-TSM
instance, and if things get too bogged down, split it into two (or
three) TSM instances on that same hardware and not have to worry (as
much) about device sharing because it's all local. If it got to the
point where I'd want to split that to different hardware, I'd look at
moving the drives to FC and sharing them that way. That makes sense to
me.
> I like the 'beefy box' solution for all purposes except test instance.
> Make sure it's got plenty of memory. 6G? 8?
Can you clarify the memory needs? I was thinking 2G of RAM per
instance; would I need more?
Dave
|
