Wanda has identified the critical choices; there is no single, right answer because the performance factors intersect at different points for nearly every situation -- if only because most sites are at different points along the evolutionary development of IT infrastructure, different sized disks for RAID, different RAID technologies (ESS vs. EMC vs. native/local drives, etc.), and different performance ranges for a given TSM server box.
And it does matter how you decide to carve up your disk pool resources. Just as different tape capacities & technology will influence your choices for how tape pools are configured, variety in the type and capacity AND number of channels accessing a set of disks will dictate the kind of performance you can achieve. So, if you think your TSM server system can handle 25 (50 in today's terms) sessions concurrently, then you measure the disk I/O performance choices against that level of concurrency. Most folks (these days) disregard the effect of distributing many logical (TSM) volumes over some number of physical volumes; increasing the number of logical volumes per physical gets that many concurrent writes queued to the device. The more of each, the more sessions can be sustained without waiting for "mount-point". I rather NOT use RAID-5 for TSM disk pool volumes... Why pay the penalty for calc & writing parity when you don't expect to read it more than once?!? This data is so transient (in general, it exists for less than 48 hours) it's not worth sacrificing ANY performance -- we really want to get the backups AND migration done as quickly as possible, right? These days, I recommend RAID-0, striping without parity, if any at all; on most moderate sized Unix machines, no striping at all, and as many smaller drives as can be handled -- these days that translates to 36 or 72 GB drives, fill the drive bays, get as much SCSI separation as possible... do the math on dividing each physical drive into some 7-10 logical drives. For RAID anything, Gianluca's 7 or 8 physical drives per RAID config is a good high-end count. Don France Technical Architect -- Tivoli Certified Consultant San Jose, Ca (408) 257-3037 mailto:[EMAIL PROTECTED] Professional Association of Contract Employees (P.A.C.E. -- www.pacepros.com) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Gerald Wichmann Sent: Tuesday, May 28, 2002 3:30 PM To: [EMAIL PROTECTED] Subject: Re: allocating disk volumes on RAID5 array That's more along the lines of what kind of info I'm digging for - but doesn't quite address how one goes about coming up with a number or size. There may not be a "right" or "single" answer however you must admit there is a generalized "right" answer. Consider for example that while RAID-5 arrays can vary in the # of disks assigned and size of them, there is a generalized rule of thumb as Cordiali pointed out. Too few or too many disks in your RAID-5 array and you can have performance implications. There's a sort of sweet spot for creating RAID-5 arrays and keeping that in mind there should also be a similar sweet spot in how many volumes one might want to assign. All in all though I still wonder if it really matters a whole lot.. Whether you have 1 write going on or 10, you're still striping across the array and I question whether you'd really see much difference one way or another. Might be an interesting thing to try various variants of.. Regards, Gerald Wichmann Senior Systems Development Engineer Zantaz, Inc. 925.598.3099 (w) -----Original Message----- From: Prather, Wanda [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 2:38 PM To: [EMAIL PROTECTED] Subject: Re: allocating disk volumes on RAID5 array Well yes, it does matter. Trouble is, there is no "right" answer. It's a performance thing. Assuming you have multiple clients backing up concurrently to your disk pool, TSM will start as many I/Os as there are clients sending data, up to the number of TSM "volumes" in your disk pool. If you have more "volumes", then you get more I/O's in flight concurrently. That's a good thing and will improve performance, until you get "too many" in flight, then the effect of yanking the heads around degrades performance. It's even harder to figure out what is optimal in a RAID situation, since you don't have a 1-to-1 correspondendence between your TSM "volumes" and physical disks. And most RAID setups have some cache that acts as a buffer, and that helps improve performance but further disassociates the number of concurrent writes from the number of physical disks. So think about it this way: How many concurrent WRITES do you want to occur in that RAID pool? Pick a number, and create that many TSM "volumes". -----Original Message----- From: Gerald Wichmann [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 5:01 PM To: [EMAIL PROTECTED] Subject: Re: allocating disk volumes on RAID5 array Yes I'm well aware of the different pro's and con's to using various levels of RAID vs non-RAID. In my application protection is paramount and mirroring is simply too wasteful to use. I've used RAID5 repeatedly in the past in regards to TSM and have always been very happy with the results. So the issue here isn't really what to use or not but rather whether there's any pro's or con's on the way you go about creating volumes on a RAID5 array. E.g. lots of smaller volumes or fewer large volumes? Having lots of RAID5 arrays as was also suggested isn't really practical because these days it's rare you don't have fairly large disks (18 or 36GB each) so in that example of 100GB you're really only talking 1 RAID5 array of 4-5 disks. Bottom line is I was just speculating out loud perhaps on whether there were any pro's or con's to how many volumes and what size one would make the volumes on a RAID5 array. Say you had a 100GB RAID5 array. Would you create 10 10GB volumes or 2 50GB volumes? Does it matter since it's all just going into a big array? Regards, Gerald Wichmann Senior Systems Development Engineer Zantaz, Inc. 925.598.3099 (w) -----Original Message----- From: Gianluca Perilli [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 28, 2002 1:35 PM To: [EMAIL PROTECTED] Subject: Re: allocating disk volumes on RAID5 array Hi Gerald, I think you have to consider that if you use RAID5 logical drives, you have to calculate and write a parity every time you write any data on the disk: so if you have a write intensive application, RAID5 is not so efficient as other RAID protections (1,10, etc); if you have instead read-intensive applications RAID 5 is a good choice because it gives you the possibility to use more physical drives concurrently. Furthermore RAID 5 is the most efficient protection regarding the optimal usage of the available phisical capacity, and it is more and more efficient as the number of physical drives in the array increase; but at the same time as the number of physical drives increase, the performance goes down (because you have to calculate the parity on a larger number of blocks): probably the best compromise is a number of 7/8 disk drives/array. I hope this helps. Cordiali saluti / Best regards Gianluca Perilli Gianluca Perilli Tivoli Customer Support Via Sciangai n0 53 - 00144 Roma (Italy) Tel. 06/5966 - 4581 Cell. 335/7840985 Gerald Wichmann <gwichman@ZANTAZ. To: [EMAIL PROTECTED] COM> cc: Sent by: "ADSM: Subject: allocating disk volumes on RAID5 array Dist Stor Manager" <[EMAIL PROTECTED] .EDU> 28-05-02 21.14 Please respond to "ADSM: Dist Stor Manager" Since a RAID-5 array shows up as one big filesystem, what's the best strategy for determining how many and of what size disk pool volumes to create for your primary disk storage pool? For the most part I don't think it really matters unlike allocating volumes on individual disks but perhaps I'm not considering something. Thanks..
