No throughput/activity on StorageWorks FC switch

[EildonHA]

Hello,

We have 2 x HP Storage Works 4/8 Base SAN switches (FC – 4GB) and an HP MSA 2012 FC.

The MSA acts as our SAN for our VMware environment (3 x ESX servers). It has 2 controllers and 2 HBA’s per controller. Similarly our ESX Hosts have 2 HBAs each.

It’s a switch environment, so the MSA Host Ports are configured Point to Point (host port interconnect not enabled).

The switches are configured each in their own Fabric and they have a connection from each of the devices (MSA Controller A, Controller B, ESX 1, ESX 2 ESX 3 etc).

We recently started some logging on our ESX servers (using resxtop command) and some odd results were returned. On one HBA per ESX Host, no activity was returned at all in the logs. However, the other HBA on each Host, showed normal operation. I investigated further and found that the HBA’s showing no throughput, were all plugged into the same switch.

I accessed both switches via the CLI and the TX/RX frames on all the HBA’s on the switch in question are negligible. A few K at most. Again, the HBA’s on the other switch shows normal operation.

I am not an expert here and I didn’t set up the switches and fabrics myself but it doesn’t seem like a configuration error on that particular switch, as the configs seem to be all but the same.

Seems like an actual fault on the switch but if it is I cannot see  any errors in the Web Tools events or any red/amber LEDS anywhere on the switch.

Rebooting the switch made no difference. Both switches FW version is v6.2.0b.

Can anyone offer any helpful advice please??

Thanks,
Steve

P.S. This thread has been moved from General to Storage Area Networks (SAN) (Small and Medium Business). - Hp Forum Moderator

[Torsten. · Accepted solution]

It depends on your SAN and array configuration.

Each vdisk in a MSA in owned by a controller, if you have a single vdisk only, only 1 controller can work with it. Since the array is ALUA, each server will speak to this single controller only, the other is standby only.

How many vdisks do you have in your MSA?

[Johan Guldmyr]

Hello, 

You could also disable alua on the server-side, unsure how to do it with ESX but with Linux you'd set the multipath config to "multibus". That way the server would use both paths to both controllers of the array even though the vdisk is owned by one of the controllers. On a MSA (P)2000 G3 we tested this and saw slightly better performance with alua enabled.

Looks your setup has been set up properly if there's only one vdisk.

Fabric OS 6.2.2f is the latest FOS in the 6.2.x series, been quite a few releases since 6.2.0b

[EildonHA]

That sounds like the answer. My lack of knowldege rather than a fault.

We only have 1 vdisk. I did see on the MSA that the vdisk was 'owned' by Controller A and did actually wonder if this was the cause.

But because one of the HBA's from Controller A is plugged into the second switch (one with no activity)  and that HBA is showing no activity, that led me to believe it was the switch rather than because the vdisk being owned by the 1 controller and the other being a standby.

But will assume this is just behaviour it exhibits? Any idea why the second HBA on the active controller would show no activity??

Thanks for both responses,

Steve

[Torsten.]

As I wrote earlier, the array is ALUA.

The server "knows" the owner controller can work much faster, thats why the server is talking only to the owner controller.

Sending data to the standby controller will slow down the transfer (as Johan confirmed).

If you would have 2 vdisks, each owned by another controller, you could see both working.

[EildonHA]

Thanks for the response Torsten, it's much appreciated.

Not looking to send data to the standby controller. Just thought I should be seeing activity on both HBAs in Controller A  (active) rather than just one HBA. And obviously, in turn see no activity on both HBA's in Controller B (standby).

Steve

[Torsten.]

Well, if both HBAs have a way to controller A, the traffic should go through both HBAs.

Check if the volumes (LUNS) are presented to all the host ports of the MSA / all the HBAs of the server.

[Johan Guldmyr]

Perhaps you have fixed/preferred path configured on the ESX.

[EildonHA]

I’ll give you the history of this setup. The FC storage layer (switches/SAN) and the original 2 ESX servers were configured by someone else. I have since formatted and installed latest ESX on the 2 Hosts and added another ESX Host. I zoned and mapped the new ESX server on the switches/SAN same as the previous servers were configured.

Tortsen – Each ESX Host has both its HBAs mapped (RW permissions) to each of the LUNs, so there should be an open path. Have added a screendump of the mappings, if that may assist?

Johan – As I say, I installed and configured ESX on the servers and didn’t manually configure a fixed path.

I do appreciate the time taken to give this advice :)

Steve

[Torsten.]

Nothing attached.

However, run this on the MSA (telnet/ssh):

# show host-maps

you will see for each server HBA WWN a list of volumes/LUNS and mapped ports like this:

# show host-maps
Host View [ID (500143801123456) Name (server1_hba1) Profile (HP-UX) ] Mapping:
   Name        Serial Number                    LUN   Access       Ports        
   -----------------------------------------------------------------------------
   LUN1_01    00c012345678987654333301000000   0     read-write   A1,A2,B1,B2

...

Check if each LUN is mapped to all HBAs in question.