I've mentioned in the forum my experiment to implement direct-to-tape
backups. I've succeeded in the reconfiguration of my TSM system and
thought I'd share with the forum what I did.
TSM 4.1.5.0 on AIX 4.3.3 PL 8; 7025 F50; 2 x 332 MHz CPUs; 1024 MB RAM;
100 Mbs network
Approx 135 clients: mostly Windows, some AIX/Irix, 3 TDP/Domino
4 TB data on online tape; 11 TB data total on tape
We have four primary data paths through our system:
1) large client backups - terminate on 3583-L72 (LTO) w/ 4 drives,
collocated
2) small client backups - terminate on 3575-L18 (3570XL) w/ 4 drives,
non-coll.
3) temporary-retention archives - terminate on 3575-L12 (3570XL) w/ 4
drives, non-coll.
4) permanent-retention archives - terminate on HP 4/40 (DLT) w/ 4 drives,
non-coll.
Also, data from paths 1 and 2 get sent to our copypool, which is also
located on the HP 4/40.
For over five years, since ADSM 2, we have force-migrated disk pools to
zero utilization, and performed all restores (2-5 per week) from tape.
Both of those techniques are contrary to TSM best practices, but have not
caused any operational problems in the entire period.
We shrank the upstream disk pools of paths 2 and 3 to 1 GB each,
implemented as 20 volumes of 50 MB each. These are the
"almost-direct-to-tape" paths. The disk volumes serve as mount point
multipliers, and the migration thresholds are set to zero. Migration to
tape occurs as soon as a client commits its data.
We eliminated the upstream disk pool of path 1 and send that data
direct-to-tape. There are only 13 clients that send data to the LTO during
the night. Four drives provided plenty enough mount points, and a single
drive can take the full throughput of the NIC.
Only path 4 retains a large (28 GB as 28 x 1000 MB) disk pool upstream.
This disk pool is used to funnel data to one tape at a time. That is to
avoid sending a lot of expensive DLTs to the vault that are 5-10% filled.
We had several reasons for cofiguring our TSM system that way:
1. The network is the pinch point. Each library, despite being connected
to just one SCSI adapter, can accept 16 MB/s, while the network tops out at
about 11 MB/s. Note that for incoming backup data, network overhead is
only 5%, so 95% of what passes through the NIC ends up on tape.
2. Once we had four drives in each library, we no longer had drive
contention because of insufficent mount points. We added drives to the two
3575s; the DLT and LTO were bought with four drives.
3. Our TSM server is five years old and every I/O slot is filled. To
double-connect the libraries, I need a new server with more slots. A quote
for a new RS/6000 with lots of RAM, enough slots, and enough SSA disk space
to implement TSM best practice was over $150,000! When SCSI disks were
substituted, the price dropped to $90,000, still a lot of money to our
little company. Reducing the required disk space shaves thousands of
dollars from the server price, and makes it an easier sell to management.
I've watched the operation of the system in this configuration for hours
and have seen no problems other than the one caused by the node MaxNumMP
parameter, and that has been fixed.
Tab Trepagnier
TSM Administrator
Laitram Corporation
|
