Thanks again, Steve, Tom, David and all for your responses on this subject!
Steve Harris wrote: > Well said Tom, > > Also add into the mix your san environment. eg host is on one switch but > disk and multiple tape drives are connected into a second san switch, but > there is only one inter switch link. > > We do make things complex, don't we? > > Regards > > Steve. > > >>> [EMAIL PROTECTED] 10/12/2004 6:18:01 >>> > The short answer is that you can't get there from anywhere. The slightly > longer answer is that this becomes an exercise in moving the bottlenecks > and choke points around. > > The IBM documentation on the 6228 fiber card (200 Mbyte or 2 Gbit) in > the Subsystem Device Driver manual indicates that one card can saturate > a PCI bus - so make sure that each 6228 card is on it's own dedicated > bus. This is implied in other placement guides, but the SDD manual is > explicit. > > Now -- in my case I have LTO-2 drives (30 MB per second transfer rate, > "higher if the data is compressable"). I'm getting 5.2 to 1 compression > on Oracle backups. Um . . . 156 MB/Second anyone? One drive per fiber > per bus - 10 drives - 10 PCI buses; three buses per I/O drawer in the > Pseries (prior to the 550 and above). > > Starting to look a bit pricey. Now, add in gigabit ethernet interfaces > to feed the drives (at no more than two to the bus). But the Gig > ethernet will limit my maximum throughput to 100 MB/second by definition > -- so I can now do two drives per fiber . . . And if I'm not running 10 > Ethernet interfaces (bottleneck!) I can hang more tape drives per fiber > . . . > > To add to the fun, again on IBM Pseries (AIX or Linux, your choice) the > RIO cable that interfaces between the CPU drawer and the I/O Drawer(s) > is rated at 1 GigaByte per second. Supposedly, the 2 GB/sec RIO > interface will be coming out next year. > > So -- it's a bit of a crap shoot. Until the hardware supports direct I/O > from card to card without CPU/system memory involvement (S/390 channel > program, anyone?) you won't come close to theoretical (marketing) > numbers. > > Put the number of drives that seems 'reasonable' or 'works' on one fiber > -- I've got five per fiber at the host right now - host PCI bus > limitation - and will be dropping to three per fiber next year with the > hardware swaps I've got coming. No more than one fiber adapter per PCI > bus, or two per PCI-X bus; preferably with no other adapters on the bus. > And check for bottlenecks. Mine is currently the network overhead on my > primary Oracle DB server -- I can max out all 4 cpus during the 2.5 hour > backup. I'm looking at better network design and SAN backup for next > year. > > If you're still awake -- I hope this helped put things into perspective. > > Tom Kauffman > NIBCO, Inc > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Timothy Hughes > Sent: Thursday, December 09, 2004 10:21 AM > To: [EMAIL PROTECTED] > Subject: TSM best Practices for tape drives using FC > > I read in a the Tivoli guide (A brief Introduction to IBM Tivoli Storage > Manager Architecture) > under Tape Drives (best practices) > > Where it say's Carefully consider card and bus throughput when attaching > tape > drives to systems most protocal/tape combinations can accommodate 2-3 > tape, > drives per card? We would like to use more than say 10 12 or more > but not to cause issues. > > We are Using 3590-H1A's (soon to upgraded to 3592's) which > would could change the amout of tape drives we use. > > We are using FC connections (the HBA's that are attached to the tape > drives are 1GB but are piped in at 2GB. > > 3590's Assumed speed 39 (GB/HR) > 3592's Assumed speed 112 (GB/HR) > > Thanks for any replies! > > All thoughts are welcome! > > *********************************************************************************** > This email, including any attachments sent with it, is confidential and for > the sole use of the intended recipient(s). This confidentiality is not > waived or lost, if you receive it and you are not the intended recipient(s), > or if it is transmitted/received in error. > > Any unauthorised use, alteration, disclosure, distribution or review of this > email is prohibited. It may be subject to a statutory duty of > confidentiality if it relates to health service matters. > > If you are not the intended recipient(s), or if you have received this email > in error, you are asked to immediately notify the sender by telephone or by > return email. You should also delete this email and destroy any hard copies > produced. > ***********************************************************************************
