Fabric Interconnect Failure Detection Delay

[andyblada1]

Hello Team,

I have one interesting query related to FI failure detection delay.

Lets say one of my FI got failed ? Detection time and tries? Is the failure detected with zero delay or only after a delay of x seconds ?

If there is a delay of x seconds, let say that x=10s to simplify the reasoning,

what happen a) if a writing on a VMDK  is initiated and not finished before the failure

b) if a writing on a VMDK is initiated after the failure and before its detection

I went through few discussions and weblinks, however didn't get concrete details.

Cheers

Andy! 

[Kirk J]

Your OS NMP should take care of detecting path down issues regardless of type of connectivity (i.e. iscsi, FC, NFS).

The same would hold true if the same path was impacted upstream above the FIs.

If you are referring to fabric failover for the vnics, then you can definitely loose some packets between the detected fail, and when that same vnic is brought up on the other FI.

You are generally better off with dual vnics (one side a, one side b) and making sure the your NMP is configured correctly to see the multiple storage paths to the same LUN/storage, and let the OS take care of 'failing' the detected path.

Kirk...

[andyblada1]

Thank You Krik for your reply!

I know the fail-over mechanism and vNic part is clear to me.

My question was specific to vHBAs, If FI- A went down then how much time it will take to detect error and switch the FC traffic FI-B.

And during that failure , what happen a) if a writing on a VMDK is initiated and not finished before the failure b) if a writing on a VMDK is initiated after the failure and before its detection

Cheers!

Andy 

[Kirk J]

I think you are confusing VNIC fabric failover capabilities, with core FC functionality that doesn't 'failover' or apply to vHBAs.

By design, for FC/FCOE fabrics, you want to have separate A vs B side connectivity, and wouldn't want your vHBA that is zoned for A side automagically switching over to B side.  That is why you want to have multiple active paths on A and B side.

That would allow for load balancing and quick path failover as directed by the OS NMP for storage.

Your NMP should mark your 'A' side related paths down to LUN X, and continue reading writing to it via alternate paths (i.e. B side paths).  If you have a specific path disruption, you will have specific FC exchanges that will get aborted for in-transit exchanges that don't get acknowledged or have timed out.

Kirk...