Paul,

may I object on only one point - IBM ESS is designed to use RAID-5 in
ranks but its huge memory cache hides RAID-5 specifics and mitigates
nearly all drawbacks. So we should not compare ESS to simple RAID-5
implementations, this would be apples vs. oranges. ESS' big cache is
better than any disks, even JBOD or RAID-0.
And even ESS can have poor performance if improperly configured. For
example if we put many LUNs on same rank and later use those LUNs for
DBVols - expected parallelism will be bottlenecked deeply in ESS
internals. In such case Storwatch Expert can help a lot.

Zlatko Krastev
IT Consultant






"Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08.10.2002 03:06
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: TSM Database Disk Layout Recommendations


The reason why is because everyone is saying RAID-5 is bad versus a
particular implementation or whatever.  The Enterprise Storage Server
(SHARK) is RAID-5 SSA under the covers.  It flies because it has
controllers
on the front end that essentially eliminate the RAID-5 effect and can
actually blow away RAID-1 solutions under high sequential write
applications.  The HDS 9900 series is the same.

It is all a balance.  RAID-5 works great for some things, bad for others.
If your RAID-5 solution does any kind of parity calculation in the array
it
will perform well on sequential write.  Why? Because the generally change
from RAID-5 to RAID-3 which is the fastest on write.

Now, considering this.  What does high sequential write?

        Generally, Storage Pools and the LOG.

What does high sequential read?

        Storage Pools and the DB during backup.

So, to generally say RAID-5 is bad is totally incorrect.  It depends on
your
hardware.  The number of simultaneous write operations you can perform,
the
speed of your disk, etc.

In the case of TSM it even depends on how your environment is setup. Would
I use software RAID-5, heck no, the CPU overhead is astronomical and the
read back penalty on something like Windows is will just kill you because
it
is a dumb RAID-5 implementation.

I hope everyone will look at what they are saying and give specific
complete
configuration information in the future.

We use the ESS.  We do striping in the AIX file system, not RAID-5.
Protection is performed in the ESS.  We had some serious performance
problems in relation to other ESS applications because we did not
implement
our striping correctly and our AIX system needed some serious tuning.

If you are running default AIX vmtune parameters.  You are probably
experiencing bad performance, not because of the RAID-5 implementation,
but
because of the stress RAID-5 puts on the filesystem buffers in the
non-comp
space and causing astronomical paging on your system.  You change to raw
and
magically the problem goes away.  Why, becauase the file system usage
drops
dramatically and the paging stops.


By changing to the recommendations folks kindly suggested over the past
weeks.  My database backup time went from about 3 hours down to 1 hour for
an 85GB database.  My storage pools have dramatically improved as well and
I
have not corrected their striping yet.  How did I get the performance:

        maxperm set to 40
      minperm set to 10
        max page read ahead set to 256K
        bufferpool set to 256MB (memory on the machine is 2GB)
        sufficient free pages to support the max read ahead (there are
rules
about this number)

Our machine is a P660-6H1,
        (4) 450MZ processors,
        2GB memory,
        2 Fibre Channel cards for the disk, 4 for the tape (1 Gbit)
        640GB of ESS disk
        14 Magstar Drives in use so far, eventually 32.
        2 Gbit Ethernet Cards.

Yes, my environment may be unique, but at least I am telling you why what
I
have works well so that a generalization is not made that has no point of
reference.

Thanks Mark, you probably saved us about 55K to prevent us from buying a
much larger TSM server.  We will probably change to (6) 750mz processors
and
4GB of memory, add another Gbit card, and 2 more FC Cards to a new IO
frame
for the 6H1.  Your methodical approach was exactly what we needed to
understand the issues and what to do.  Our machine purrs like a kitten
now.



Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180