With 200M files and only 7TB you must have many small files. To guess
at how many objects will be in your DB you could use the file count from
an incremental backup. Just multiply by your retention and add the base
count.
For comparison purposes I have 149M objects in a 71% used 94GB DB. The
source data is about 40TB, of which TSM has 72TB stored. TSM backs up
about 1.2TB per night.
To keep LTO3's fed, be sure you have adequate system busses to handle
the simultaneous reads and writes from disk, tape, network, DB and Logs.
Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Dave Mussulman
Sent: Friday, May 19, 2006 3:13 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] multiple instance recommendations
Hello,
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. I'm just not sure how best to partition it in my
environment and use the resources available to me. (Or what resources
to ask for if the addition of X will make a much easier TSM
configuration.) For database and storage pools, I will have a multiple
TB SAN allocation I can divide between instances. I have one 60 slot HP
MSL6060 library (SCSI), with two LTO-3 SCSI drives. There is also an
external SCSI LTO-3 drive.
My understanding of a shared SCSI library indicates that the library is
SCSI-attached to a server, but drive allocation is done via SAN
connections or via SCSI drives that are directly attached to the
different instances. (Meaning the directly attached SCSI drives are not
sharable.) Is that true, at least as far as shared libraries go? The
data doesn't actually go through the library master to a directly
connected drive, does it?
If not, and I still wanted to use sharing, I could give each instance a
dedicated drive - but since two drives seems like the minimum for TSM
tape operations, I don't really think it's wise to split them.
(However, if the 'best' solution would be to add two more drives to max
out the library, I can look into doing that.)
If the drives need to be defined just on one server, it looks like
server-to-server device classes and virtual volumes are the only
solution. I don't really like the complexity of one instance storing
anothers' copy pools inside of an archive pool just to use tape, but it
looks like things are heading that way.
Other than the obvious hardware cost savings, I don't really see the
advantage of multiple instances on the same hardware. (I haven't
decided yet if we would use one beefy server or two medium servers.) If
you load up multiple instances on the same server, do you give them
different IP interfaces to make distinguishing between them in client
configs and administration tools easier? Tape access-wise, is there a
hardware advantage putting multiple instances on the same system?
Any recommendations on any of this? Your help is appreciated.
Dave
This e-mail (including any attachments) is confidential and may be legally
privileged. If you are not an intended recipient or an authorized
representative of an intended recipient, you are prohibited from using, copying
or distributing the information in this e-mail or its attachments. If you have
received this e-mail in error, please notify the sender immediately by return
e-mail and delete all copies of this message and any attachments.
Thank you.
|
