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" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 08.10.2002 03:06 Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] 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