Netware SAN Failover issue

[SirCam]

Hi,

We run a Netware 6.5 Cluster on a Blade Centre, connected to an IBM T600 Turbo SAN. The blades have two HBA Fibre Channel cards which connect to two internal switches. These switches then connect to two IBM 32-port switches (fabric A and B) (switches are not connected to each other) which then connect to Controllers A and B respectively. It's not a meshed fabric, i.e. controler A connects to switch A which connects to the Blade Centre switch A, and same for B fabric. We run RDAC on the blades.

Issue: I cannot see the failover paths from the servers. When I run "List failover devices" i get no result. I've looked at "

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10070244.htm"

which has some ideas, but it's like the failover paths do not exist.

When I failover a LUN from one controller to another, it fails back straightaway. If I set the preferred path to the other contoller, it will still run from the orginal controller, even though the other one is it's preferred owner.

Does anyo one know of any issues running this sort of set up? Do I need to mesh the SAN FC, i.e. connect the SAN switches together, have a FC path from controller A to switch A AND B, and vice versa for Controller B?

Do I need to configure RDAC somehow, or does it do it's own config?
In config.txt I see under Qlogic 1, a path to the LUN, but not under Qlogic 2.
Thanks.

 

[SirCam]

I think this is due to Host Type on the SAN being set to Netware-IBMSAN not Netware-Failover. Anyone see any issues if I change this? I am using the native Netware failover driver.

 

[ITsmyfault]

sounds like a zoning problem. Can each HBA "see" each controller, eg:
if you zone single initiator you should have:

zone 1
hba-1 on serverA
controller A on fastT
controller B on fastT

zone 2
hba-2 on server A
controller A on FastT
controller B on FastT

This will control what the server can "see". If you have no zoning then forget this..

If you no zoning set up and the switches are completely seperate, then you need to add an ISL link (aka E port some folks call it) to mesh the switches.

 

[SirCam]

Yes we do use zoning. We have 2 HBA's per server, and two switches connecting to two controllers in one SAN.

Zone 1
HBA1 on serverA
Controller A on FastT

Zone2
HBA2 on serverA
Controller B on FastT

I have read somewhere to keep these fabrics separate. Is this correct? What would happen if we added to each zone the other controller? If a LUN fails over to the other controller (say from A to B), isn't it up to the server failover software to move the path to go through HAB2 to get to Controller B?

 

[ITsmyfault]

I have always been told to keep the tape and data fabrics seperate, but it is possible to link the 2 data fabrics you have via an ISL or "e" port. This is like chaining ethernet switches essentially, but again you should zone. This is how you can mesh your fabrics.

Not sure how rdac figures in.. I thought it only ran on Windows? FWIW we just run the Netware MPIO driver.

Are you loading the LSIMPE driver in your startup.ncf?
Are you using storage partitioning on the FastT?

The only really wierd issue (we've had a couple times) is sometimes the MPIO software and the FastT get into a "loop" of sorts and the luns fail back and forth constantly. The only way we've been able to stop it is to power everything down and bring it all back up 1 thing at a time. Then we're golden.

 

[dan]

We have an IBM4800 SAN. To get the redundant link in Netware 6.5 we had to add /ALLPATHS to the end of each of the fiber channel adaptor drivers in startup.ncf.
Then:
restart server
SCAN ALL LUNS
NSSMU (list the devices and scan) You should see both devices each listing the same lun.
Dan

 

[SirCam]

We changed the host type to netware failover and we could then see the multipathing. Unfortunately, the SAN isn't cabled properly to manage a cluster so we had repeated failovers on resources on controllers so we had to do a rollback.
We are about to introduce SVCs into the environment and recable, and is now working fine in test, so not long til it's put into production.

Thanks for your posts.