IBM does not support same disk and tape across the same HBA on Windows. Basically, for optimal performance the disk and tape need different values for a couple of items and they are not testing both disk and tape on the same HBA.
Here is the reality. I have been running disk and tape on the same adapters on AIX and Solaris very successfully. I have McData Switches with ES-1000s. The issue is are you using arbitrated hubs or real switches. LIPs can cause all types of problems. In a Brocade switch or McData switch environment with ES-1000s it is not a problem. However, there is a case where performance will lag. FC has a receive and transmit link. Remember disk reads and type writes on a backup. So, if you are trying to run heavy production processing read/write disk at the same time with heavy tape backups, it is just like any other interface, it does not perform very well. But, if you are reading from disk and writing to tape with large blocks, it flys. It performs poorly when the block sizes are small and there is a lot of chat going on about IO completes or IO starts. Sorry, I cannot identify the cause of the performance issue here if it is single HBA related. I believe you would be better if you had 2 HBAs and ran load balancing software to the disk if it is available. However, I think the issue is more fundamental, disk pool migrations in the middle of doing backups, not recommended. Under that scenario you are doing a lot of IO against your TSM Database and storage pools. Have you tuned your database specifications for buffers, etc. I believe your problem is the database activity on the mirrored drives that conflicts with the backup processes and migration processes. These migrations are probably lots of little files causing lots of writes and reads to the database to update the information. Look to see if the database drives are taking a pounding during this process. -----Original Message----- From: Allen Barth [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 4:59 PM To: [EMAIL PROTECTED] Subject: Re: Bad performance with FC attached disk and tape Joshua, I've heard this before, but I couldn't find anyone at IBM to confirm it. SO......... I've been running tape and dasd thru the same FC adapter for about a year now. Traffic goes from rs6k to an IBM2109 (brocade) switch and then splits from there. I suspect the switch is handling the arbirated loop (3590) and point to point (ess aka shark) communication conversions. Gotchas? Al Barth Zurich Scudder Investments "Joshua S. Bassi" To: [EMAIL PROTECTED] <[EMAIL PROTECTED] cc: OM> Subject: Re: Bad performance with FC attached disk and tape Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] IST.EDU> 02/21/02 12:56 PM Please respond to "ADSM: Dist Stor Manager" Not only is sending disk and tape data across the same FC card a bad idea, I believe IBM doesn't even support that configuration. -- Joshua S. Bassi Sr. Solutions Architect @ rs-unix.com IBM Certified - AIX/HACMP, SAN, Shark Tivoli Certified Consultant- ADSM/TSM Cell (415) 215-0326 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of Wu, Jie Sent: Thursday, February 21, 2002 8:31 AM To: [EMAIL PROTECTED] Subject: Re: Bad performance with FC attached disk and tape >From the info you provided, your primary stgpool, the diskpool on Compaq disk cabinet, and the migrationpool defined on the 3584-L32 are sharing the same FC card. If thishis is the case, it is a bad design. You may use two FC card on the P610. One for the Compaq FC disk cabinet and the other for the 3584-L32. I believe this way you will get better performance. Jie -----Original Message----- From: Daniel Sparrman [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 1:22 AM To: [EMAIL PROTECTED] Subject: Bad performance with FC attached disk and tape Hi We have a system configured as follows: One P-Series 610 with dual 450 PowerPC processors 1GB RAM 2 18.2GB Ultra3 15K drives which are mirrored and contains AIX system and Tivoli logs 2GB Ultra3 15K drives which are mirrored and contains Tivoli database (30GB large) One IBM FibreChannel card One locally attached IBM Magstar 3575-L32 with 3 3570C drives. The system is attached to a SAN and has a dispool of totally 150GB on a Compaq FC disk cabinett. The system also is attached to a IBM 3584-L32 which as 2 SCSI drives connected through a IBM SAN Data Router (2108-R03) and one fibre attached LTO drive which is connected through a SAN switch(Compaq). The system uses 3 100Mbs Ethernet adapters, one which really are a Gigabit Ethernet card but is running at 100Mbs speed. When backup occurs, we have a good performance; normally about 15.000-16.000KB/s in Network speed, and about 6000-7000KB/s in Aggregate Transfer Rate. However, when the diskpool gets full in the middle of the night, and the TSM server starts migrating data to the drives in the 3584-L32, performance drops. We only get about 500KB/s-600KB/s throughput in the fibre attached drive. The AIX server however, has a good throughput through the FC adapter, and the Compaq disk cabinett has a throughput of about 10-14MB/s to the AIX server. If we do a storagepool backup from the 3575-L32 to the 3584-L32, the speed is good. If we do reclamation, or database backup, the speed of the FC drive is also good. Can this has something to do with the FC adapter? Should this configuration require 2 FC adapters? The first thing that hits me is that the FC adapter can't handle the throughput, doing both backup from clients to SAN attached disk, and doing migration from SAN attached disk to SAN attached drives. If we do a migration in the morning, when no backups are running, we get a speed of around 27MB/s on the fibre attached drive with compression. So, the FC drive has good performance, when no backups are running. Can somebody tell me whats wrong? Best Regards Daniel Sparrman ----------------------------------- Daniel Sparrman Exist i Stockholm AB Bergk�llav�gen 31D 192 79 SOLLENTUNA V�xel: 08 - 754 98 00 Mobil: 070 - 399 27 51 ******************* PLEASE NOTE ******************* This message, along with any attachments, may be confidential or legally privileged. It is intended only for the named person(s), who is/are the only authorized recipients. If this message has reached you in error, destroy it without review and notify the sender immediately. Thank you. **********************************************************
