[pete_d_ats]

Hello,

We are using a Shark via SAN (fibre broacade switch) for all of our database disks (using VPATHs) and only 1 of the "paths" is being used. Unfortunetely, this was setup YEARS ago by an outside vendor which we no longer use. Another vendor we are starting to use wants use to run a manual "lscfg" to see if the other chanel will be picked up, and if not, to remove the fibre chanel devices and reconfigure. He "says" that all of the VPATH/HDISKs will "come back", but I can't take this chance since this is a production box and restoring/rebuilding 38 different database instances is not an option at this time.

Does anybody know if what he wants to do is feasable or not?

Not knowing alot about this particular issue, I don't know if the following is enough info or "too much" info:

Heres an example of a "datapath query device" for 1 of the "vpaths":

DEV#: 19 DEVICE NAME: vpath19 TYPE: 2105F20 POLICY: Optimized
SERIAL: 30617013
================================================== =========================
Path# Adapter/Hard Disk State Mode Select Errors
0 fscsi0/hdisk21 OPEN NORMAL 350714 0
1 fscsi0/hdisk41 OPEN NORMAL 350097 0
2 fscsi0/hdisk61 OPEN NORMAL 350470 0
3 fscsi0/hdisk81 OPEN NORMAL 350854 0

# datapath query adapter

Active Adapters :1

Adpt# Adapter Name State Mode Select Errors Paths Active
0 fscsi0 NORMAL ACTIVE 55730841 0 80 80

]# lscfg |grep fsc
* fscsi1 U0.1-P2-I1/Q1 FC SCSI I/O Controller Protocol Device
* fscsi0 U0.1-P2-I6/Q1 FC SCSI I/O Controller Protocol Device

[ross.mather]

In this setup he could legitimately rmdev the fcs1 and fscsi1 as they are not being used. however just deleting everything seems a bit heavy handed.

However looking at what you've posted the fcs1 is not connected to the storage, but 4 fibres in the Shark are connected to fibre card one.

Before you let the consultant delete stuff I'd first al all check your SAN configuration to ensure the fcs1 can indeed access the disks.

check the WWNs in the fcs against the SAn switch configs and against the ESS configs for the relevant LUNS.

[pete_d_ats]

Thx for the response Ross!

I don't wanna sound stupid, but I don't have any experiance with SAN configs. Is your comment "check your SAN configuration to ensure the fcs1 can indeed access the disks." on the AIX side? Same with the "check the WWNs in the fcs against the SAn switch configs and against the ESS configs for the relevant LUNS." comment.

If on the AIX side can you give me the commands? Can I provide any more details? We actually have 20 VPATH's that show during the "datapath query device" output. All outpu is the same with the exception of the dev#, vpath# and hdisk value.


If they would only send me to some classes so I can actually support what I have it would be nice.

Pete

[ross.mather]

This problem will - in all probablility - be the same for all vpaths, so investigating one should be enough.

For each fcs we need to do this:

lscfg -l fcs0 -vps | grep Network
Which will show you something like:
Network Address.............10000000BCA31432

This is the WWN of the fibre card - actually this fulfills the same function as a MAC Address for an Ethernet Card.

Check also:
lsattr -El fscsi0 | grep attach
Which (hopefully) will show:
attach switch How this adapter is CONNECTED False

This means that the Fibre card is correctly connected to the switch.

Picking the example above do:
lscfg -l hdisk21 -vps

The following fields are important
Machine Type and Model......2107900
Serial Number...............2135438000
Device Specific.(Z1)........0101

The LUN id is the last three digits of the Serial Number and the 4 digits of the Z1 field. You can use this info to verify via the GUI for the shark if the LUN is indeed allocated to the two relevant Fibre Cards. You can also check the configs in the switchs via the GUI to see that the two WWNS are allocated to the same zone as the Fibre Cards for the Shark - you may need to dig out the manuals to do those.

[pete_d_ats]

Thx again Ross,

Here's what I get:

[/]# lscfg -l fcs0 -vps | grep Network
Network Address.............10000000C93A19D1
[/]# lsattr -El fscsi0 | grep attach
attach switch How this adapter is CONNECTED False
[/]# lscfg -l hdisk21 -vps
hdisk21 U0.1-P2-I6/Q1-W5005076300C4800D-L5306000000000000
IBM FC 2105F20

Manufacturer................IBM
Machine Type and Model......2105F20
Serial Number...............30617013
EC Level.....................142
Device Specific.(Z0)........10
Device Specific.(Z1)........0000
Device Specific.(Z2)........0075
Device Specific.(Z3)........35600
Device Specific.(Z4)........05
Device Specific.(Z5)........00


PLATFORM SPECIFIC

Name: disk
Node: disk
Device Type: block
[/]#

Info for 2nd card:
[/]# lscfg -l fcs1 -vps | grep Network
Network Address.............10000000C93A344C
[/]# lsattr -El fscsi1 | grep attach
attach switch How this adapter is CONNECTED False

I'm assuming that from your previous comment that the above 2 checks show that both fibre cards are attached to the brocade switch correctly.

That would make the LUN ID 0130000 for the first fibre card. Shall I assume that the LUN ID would be the same for both paths since the LUN ID is the ID of the shark/VPATH locations??

I'll pass this on to the folks who have access to the GUI interface for the other validation.

We already know that the ip address of the path that is working is 10.105.1.210 whereas the ip address of the "missing" path is 10.105.1.211.

Thanks again for the assist.

Pete

[HessIBM]

Just out of curiosity, what is the output of the following command:

lsdev -Cc adapter | grep fcs1 ???

Does the adapter show as available or defined?

Something just strikes me as odd because the IBM SDD does not recognize the fact that you have a second fiber adapter in the system. Which could mean the fiber adapter is not available..

[pete_d_ats]

Here's the output:

[/]# lsdev -Cc adapter | grep fcs1
fcs1 Available 11-08 FC Adapter

So it sees the 2nd card and it shows as being available.

Pete

[pete_d_ats]

** RESOLVED **

After investigation by multiple parties, including suggestions by all of you, everything is now up and running.

The issue was on the SAN/Shark side. Apparently the other 3rd party vendor we had set this up eons ago never finished the job and configured the 2nd switch parameters into the shark. This was addressed and after I re-run "cfgmgr -l fcs1" there was 80 new hdisk's created. Running "addpaths" after this was done reconfigured the vpaths correctly so we are now running a true-multi-path environment.

Now I gotta get time to upgrade the ancient SDD sub-system...

Thanks for everybody's responses.

Pete