Thanks Daniel,
The host has 4 HBAs. Two attached to each of the two switches. One HBA is
zoned for tape traffic and the other for disk traffic. Only the db and log
are on the Shark F20. The disk stgpools are on attached SCSI disk drives.
The disks are 36G. There are 8 LSSes. Each LSS is striped across 8 drives
and sliced into 21G partitions. The db is on two of these 21G slices.
Tpae library is a 3494 with 6 3590E FC drives. All drives are connected
to the two switches, three each.
Come to think of it, the Shark only has 2 HBAs. I have to verify this, since
I am typing this from home. But it only has to read from the Shark and write
to tape through another port in the switch.
Eliza
> Hi
>
> The large disks you are talking about, are you meaning large as 36GB, 72GB
> an so on, or are you talking about LUN-sizes?
>
> In a shark, you can have very large LUN:s, but they will consist of a
> large number of smaller SSA-based hard drives. This means that you will
> not have a performance impact on the disks.
>
> Normally performance issues on TSM / SAN has to do with having disks and
> tapes on the same HBA. DB transactions is very randomly written, so if you
> for example are doing migration, TSM will write to both disks and tape(DB
> transactions to disk, migration from disk, migration to tape). This will
> have a huge impact, as the HBA is arbitrated(which means only one write
> can be done at a time). Also, doing backups and migration directly to
> tape, assumes the ablility to write continous, sequential data. If you
> have the DB on the same card, your clients, or the TSM server, won't be
> able to stream data to the tapes, leading to poor performance.
>
> Eliza, I'd suggest you use somekind of monitoring tool, like the Storwatch
> specialist, to see throughput from/to disks and tape. I'm sure that if you
> separate the disks from the tape, you will see a performance upgrade.
>
> How many HBA:s do you have in your Shark?
>
> Also, check to see that the logs, diskpook and database is not on the same
> volumes. This will also generate bad performance.
>
> The best practice is to have db & log on one HBA, diskpool on one HBA, and
> tape drives on one or more HBA:s(depending on amount of tapes drives).
> This is however recommended for large environments, with > 200 mid-size
> clients.
>
> Best Regards
>
> Daniel Sparrman
> -----------------------------------
> Daniel Sparrman
> Exist i Stockholm AB
> Propellervägen 6B
> 183 62 HÄGERNÄS
> Växel: 08 - 754 98 00
> Mobil: 070 - 399 27 51
>
>
>
>
> Remco Post <r.post AT SARA DOT NL>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 2002-09-02 10:48
> Please respond to "ADSM: Dist Stor Manager"
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
> cc:
> Subject: Re: backup performance with db and log on a SAN
>
>
> On zaterdag, augustus 31, 2002, at 05:18 , Eliza Lau wrote:
>
> > I recently moved the 36G TSM database and 10G log from attached SCSI
> > disk
> > drives to a SAN. Backing the db now takes twice as long as it used to
> > (from 40 minutes to 90 minutes). The old
> > attached disk drives are non-RAID and TSM mirrored. The SAN drives are
> > RAID-5 and TSM mirrored. I know I have to pay a penalty for writing to
> > RAID-5. But considering the massive cache of the SAN it should not be
> > too bad. In fact, performance of client backups hasn't suffered.
> >
> > However, the day after the move, I noticed that backup db ran for twice
> > as long. It just doesn't make sense it will take a 100% performance hit
> > from reading from RAID-5 disks. Our performance guys looked at the sar
> > data and didn't find any bottlenecks, no excessive iowait, paging, etc.
> > The solution is to move the db and log
> > back to where they were. But now management says: "We purchased this
> > very expensive 2T IBM SAN and you are saying that you can't use it."
> > Meanwhile, our Oracle people happily report that they are seeing
> > the performance of their applications enjoy a 10% increase.
> >
> > Has anyone put their db and log on a SAN and what is your experience?
>
> Yes we have. SAN is very bad for database performance. We used it as a
> temp storage space while we were reorganizing the ssa disks on our TSM
> server. The reason SAN attached storage gives poor performance is the
> size of the disks. You now have just a few large disks for your
> database, while in the past you probably had a few more smaller disks to
> hold the same amount of data. Disk seek times have not kept pace with
> disk size, so while the disks are a lot bigger, they take about the same
> amount of time to find a block of data. Since almost each database read
> access requires a seek, more spindles give more bandwith and this better
> performance. Even worse in raid5, since now all disks must have read the
> block of data before the raid5 controller can return anything.
>
> Raid5 will give you another performance hit, especially if you have a
> write-trough cache (or no cache at all) and not a write back cache.
>
> You probably want to look into the cache-hit ratio on the raid5
> controller, and see how you could improve that. Other than that, I still
> feel jbod is the way to go for databases. More spindles are more
> better... ;)
>
> > I have called it in to Tivoli support but has yet to get a callback.
> > Has anyone noticed that support is now very non-responsive?
> >
>
>
>
> > server; AIX 4.3.3, TSM 4.2.1.15
> >
> > Thanks,
> > Eliza Lau
> > Virginia Tech Computing Center
> > 1700 Pratt Drive
> > Blacksburg, VA 24060
> > lau AT vt DOT edu
> >
> ---
> Met vriendelijke groeten,
>
> Remco Post
>
> SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl
> High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
> PGP keys at http://home.sara.nl/~remco/keys.asc
>
> "I really didn't foresee the Internet. But then, neither did the computer
> industry. Not that that tells us very much of course - the computer
> industry
> didn't even foresee that the century was going to end." -- Douglas Adams
>
|
