---> It won't take too many connections on the main pipe to take a
big chunk of it, and if you stream to tape you want the LTO drive
buffers to be well fed (a potential performance issue).

As Suad already pointed you have many drives not too much LAN
connectivity. In fact 1Gb Ether can be enough for 1-3 LTO drives (depends
on compression ratio achieved) or up to 4-5 without drive-compression. If
you compress at the TSM node be aware that each thread is run on separate
processor and uses separate session to the TSM server. The best
performance I've seen was 10-11 MB/s read from disk --> 3-4 MB/s
compressed transferred over LANto the server per thread/processor. This
was achieved on mighty M80 server with 750 MHz RS64-IV processors.

Bottom line: With node-compression you should always buffer to a diskpool
and migrate to LTO. Without node-compression and using LTO drive
compression you will suffer if more than 2 sessions write direct-to-tape.
Separate Gigabit segment might double this number but anyway you have to
consider throughput required for sessions backing up to the diskpool.

For such number of drives I would recommend to evaluate usage of
SAN-sharing of the library and Storage Agent on Oracle and/or Domino
servers.
I already reported to this list the success I had with Oracle & Storage
Agent - based on class bindings big files went LAN-free to SAN-attached
library while small files were bound (and directed) to the diskpool.

Zlatko Krastev
IT Consultant






Suad <s.musovich AT AUCKLAND.AC DOT NZ>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
20.11.2002 00:58
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: New TSM Server Question


There ain't no magic bullet for that question.

You have to factor in a bunch of things;
- The size of the backup windows for the Oracle/Domino server
- how much the Oracle/Domino/other server windows overlap.
- The amount of Oracle/Domino data you need to backup in the windows.
- amount of disk stgpool (can you backup the entire window)
- number of available tape drives (how many can you spare at any given
time)
- type of disk (can it handle a full write load from Gigabit Ethernet)
- if you are confident the Oracle/Domino servers can stream to the TSM
server at the speed of the tape drives (15MBytes/sec)

Judging from the number of tape drives it would make sense to keep
streaming the Oracle/Domino data directly to tape. This would avoid a
potential bottleneck writing to the disk pool (unless you have very fast
disk subsystem) and the 15MB/sec would allow most large database dumps
in a few hours.

I would look at keeping a separate Gigabit segment for the database
servers. It won't take too many connections on the main pipe to take a
big chunk of it, and if you stream to tape you want the LTO drive
buffers to be well fed (a potential performance issue).

Cheers, Suad
--

On Tue, 2002-11-19 at 21:45, HEMPSTEAD, Tim wrote:
> Hi,
>
> We are replacing our existing TSM server with a new one and I have a
> question about storage pool configuration.
>
> Currently our TSM server is running on the same RS6000 as our main
Oracle
> databases using a STK L700 tape silo connected directly to the RS6000.
The
> TSM server also backs up another RS6000 running Oracle and a couple more
> running Domino over a gigabit network.  The Oracle data and Domino
database
> data from these servers goes straight to tape whilst file-level data and
> Domino transaction log data go via a disk storage pool.
>
> We are now going to use a separate RS6000 server running TSM 5 with an
IBM
> 3584 silo with 8 LTO drives.  This will be connected to the other
servers
> via the gigabit lan.
>
> Would it be better to keep some of the data going straight to tape or
would
> I be better to use an intervening disk storage pool for all of the data
and
> then use multiple LTO drives to migrate to tape?
>
> Thanks
>
> Tim
>
> --
> Tim Hempstead, thempstead AT slb DOT com
> Unix Technical Specialist
> SchlumbergerSema
>
>
> _________________________________________________________
> This email is confidential and intended solely for the use of the
> individual to whom it is addressed. Any views or opinions presented are
> solely those of the author and do not necessarily represent those of
> SchlumbergerSema.
> If you are not the intended recipient, be advised that you have received
> this email in error and that any use, dissemination, forwarding,
printing,
> or copying of this email is strictly prohibited.
>
> If you have received this email in error please notify the
> SchlumbergerSema Helpdesk by telephone on +44 (0) 121 627 5600.
> _________________________________________________________