All FWIW,
In the beginning I ran just fine with 3590's and ESS on the same FC cards.
I had 3 3590's on each of 2 FC adapters, and the adapters also shared
work to the ESS via vpath. As the workload increased, the only problem I
saw was occasionally tapes wouldn't get unmounted despite being reported
as such, and then TSM would think the drive was free, try to use it, and
find it unavailable. Then the ANR8447 messages would begin like crazy. I
just reconfigured things last w/e to separate the disk and tape to
different FC adapters, and I haven't seen the condition since. OK, it's
a bit too early to be positive. This TSM environment/machine is 90+%
busy for hours on end. I had not changed any FC settings.
IBM H80 -- IBM 2109 FC switch ----- ESS/3590 drives
TSM 4.1.4
AIX 4.3.3.10
FC adapter microcode current
Atape 8.1.2.0
3590 microcode F26
Gianluca Mariani1 <gianluca_mariani AT IT.IBM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/19/03 04:51 AM
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: Mixing disk and tape on same FC aqdapter
This is our latest official statement concerning the FC HBA sharing
issue.to my knowledge, it hasn't been "updated" yet.
"...Using a single Fibre Channel host bus adapter (HBA) on a host server
for concurrent tape and disk operations is generally not recommended. In
high performance, high stress situations with dissimilar I/O devices,
stability problems can arise. IBM is focused on assuring configuration
interoperability. In so doing, IBM tests single HBA configurations to
determine interoperability. Certain customer environments using AIX with
the IBM FC Switch (2109) connecting both ESS (2105) and Magstar 3590 Tape
have demonstrated acceptable interoperability. For customers that are
considering sharing a single HBA with concurrent disk and tape operations,
it is strongly recommended that the sales team conduct a Pre-Sales
Solutions Assurance Review with members of the Techline or ATS team to
review the issues and concerns. IBM and IBM's partners will continue
evaluating other configurations and make specific statements regarding
interoperability as available."
what your local IBM support meant, probably, is that you risk a hang or
data corruption, not that it certainly won't work.but customers should
always be made aware of potential risks.
Cordiali saluti
Gianluca Mariani
Tivoli TSM Global Response Team, Roma
Via Sciangai 53, Roma
phones : +39(0)659664598
+393351270554 (mobile)
gianluca_mariani AT it.ibm DOT com
----------------------------------------------------------------------------------------------------
The Hitch Hiker's Guide to the Galaxy says of the Sirius Cybernetics
Corporation product that "it is very easy to be blinded to the essential
uselessness of them by the sense of achievement you get from getting them
to work at all. In other words ? and this is the rock solid principle on
which the whole of the Corporation's Galaxy-wide success is founded
-their fundamental design flaws are completely hidden by their
superficial design flaws"...
Neilson Lui
<nclui AT BPI DOT COM.
PH> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<ADSM-L AT VM DOT MARI
bcc
ST.EDU>
Subject
Re: Mixing disk and tape on same FC
19/05/2003 aqdapter
02:45
Please respond
to "ADSM: Dist
Stor Manager"
Have also got the impression from our local IBM support that the server
would hang if we mixed shark and tape access on the same FC card. But due
to lack of FC cards, some of our servers are running on mixed shark and
tape access and all of them are working fine. I agree with Steve that this
issue is a folklore or somesorts.
Steve Harris
<[email protected] To:
ADSM-L AT VM.MARIST DOT EDU
LD.GOV.AU> cc:
Sent by: "ADSM: Dist Subject: Re: Mixing
disk and tape on same FC aqdapter
Stor Manager"
<ADSM-L AT VM.MARIST DOT EDU>
05/19/2003 07:42 AM
Please respond to
"ADSM: Dist Stor
Manager"
Bill,
I ran for over a year on an SP node (F50 equivalent) single adapter to a
shark and 3590 drives without problem.
I've now moved to a P690 Lpar and because I have two sans, both connected
to the same ESS and the same tape and only two adapters I'm still mixing
traffic and it seems to work ok.
One issue is that there is folklore around that the max_xfer_size of the
FC
adapter should be set to 0x1000000 instead of the default 0x100000 for
tape usage. However, the only written confirmation that I could find for
this was in a Red Book where tape drives were connected via a San Data
Gateway. Whether this is useful or relevant in a pure SAN environment is
unclear.
I'd be glad if anyone could contribute a definitive opinion on this.
Steve Harris
AIX and TSM Admin
Quuensland Health, Brisbane Australia
>>> bill.boyer AT VERIZON DOT NET 19/05/2003 6:44:21 >>>
Is it still the rule-of-thumb to NOT combine disk access and tape access
across the same FC adapter? I have a client that doesn't want to purchase
a
separate adapter for the SAN tape backups to keep it off the adapter(s)
for
the FasT700 disk data.
I have a couple year old white-paper from IBM saying that data corruption
may occur if you mix the two, but has that changed with the advances in
Fibre?
Bill Boyer
"Some days you are the bug, some days you are the windshield." - ??
**********************************************************************
This e-mail, 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 e-mail 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
e-mail in error, you are asked to immediately notify the sender by
telephone or by return e-mail. You should also delete this e-mail
message and destroy any hard copies produced.
**********************************************************************
|
