Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

3305

October 14th, 2010 14:00

Clariion CX4 Trespass Question

Hello-

Hoping someone can assist with a situation we have, or at least help me understand why it is occuring.  We are in the middle of migrating a variety of windows, esx, aix, linux systems from an IBM SAN to a Clariion CX4-240, flare 29 sp3.  Because of this temporary situation we have the CX4 spa1 and spb0 going into the two switches that are currently connecting our systems to the shark and CX4 spa0 and spb1 going into two new mds 9134 switches.  With this setup our hosts are able to see data on th shark, via the old switches and can see the luns on the clariion through the new switches.  We are in the middle of migrating the data from the shark to the clariion.  Each time we finish with a system we pull its fiber cables from the old switch and cable it directly into the new switch.

The problem with this is we are using unlicensed powerpath on the windows hosts so we are only leveraging one hba.  When the project is done and all four sp connections are in the switch this won't be an issue if we have a trespass because the hba will have a connection from the switch into spa and spb.  But, right now if a trespass occurs the LUN is dropping, since basic pp will not trespass at the hba level and the switch only has a path to either spa or spb, but not both.  To deal with this short term issue we are being very carefull to not trespass any LUNs.  Now the issue.....

At randoms times we will get calls from our database team stating a drive has dropped and when we look at the window system we can see a trespass was initiated by the client, but since it can't get to the other sp, the trespass fails and the drive drops until we manually trespass it over.  This happened again today when we added an ISL connection into the MDS switch to add one of the blade systems we need to migrate into the fabric.  We made sure the domain ID's were higher on the switch we added so it wouldn't cause switch conflicts.  It also happened a few weeks ago when we added a few hosts into the Navisphere manager.  All we did was register the hosts and add them to some storage groups and once again some LUNs dropped.

Native MPIO on the linux systems seems to be dealing with this issue okay and LUNs seem to be trespassing fine, just 2003 windows boxes right now.

Does anyone know why these types of activities, adding an isl connection to a switch and adding hosts to the clariion, would cause this issue?

ps.  I would add the licensed version of powerpath if my customers would pay for it....I guess once all sp paths are set at the switch level I will be okay, but it is frustrating and emc can't really explain it, or I at least don't get what they are saying.

thank you

111 Posts

October 14th, 2010 16:00

One option is to manually move all the LUNs default owership to the SP that you have access to. Once the migration is complete and you have access to both SPs you can go back and change the default ownership.

Another option to try would be to use ALUA.

You can configure the failover properties to utilize ALUA (Asymmetric Logical Unit Access) which will redirect the I/O through the peer SP to the SP owning the LUN. It is not recommended to run this way for a prolonged period of time since this lengthens the host's response time and may cause performance problems, but slow is better that no access.  ALUA is supported with PowerPath, MPIO and PV Links.

For more information on ALUA see:

ALUA explanation

White Paper: EMC CLARiiON Asymmetric Active_Active Feature A Detailed Review

Failover mode setting 4 is for ALUA.

windows failover.jpg

11. For PowerPath for Solaris, Linux and Windows, failovermode settings are as follows:

• FLARE 24 or earlier: failovermode MUST be set to 1

• FLARE 26 or later:

- PowerPath 5.0 or earlier: failovermode MUST be set to 1

- PowerPath 5.1 or later: failovermode may be set to 4 for ALUA behavior, or

- PowerPath 5.1 or later: failovermode may be set to 1 for active/passive behavior

18. For using DMP within VERITAS Storage Foundation for Windows, set failovermode as follows:

• VERITAS VxVM 5.0 and earlier, failovermode MUST be set to 1

• VERITAS VxVM 5.1 and above: failovermode settings are as follows: – FLARE 24 or earlier: failovermode MUST be set to 1

– FLARE 26 or later:

  • Failovermode is recommended to be set to 4 for ALUA behavior, or
  • Failovermode may be set to 1 for active/passive behavior

     


 






All host settings are available in the EMC Knowledgebase article: emc99467

2 Intern

 • 

20.4K Posts

October 14th, 2010 14:00

every time you add new switch to the fabric, the fabric reforms ..sort of rediscovers itself so maybe that could be one of the instances where the host freaks out and loses the path.  Not sure how far you are in the migration process but was there any consideration of connecting mds 9134 (interop mode) and the other switch together. That would allow you to use both HBAs and avoid this issue.

22 Posts

October 14th, 2010 15:00

Thank you for the response.  We definitely wanted to interconnect the old and new switches, but when we tried the firmware was so old on the original switches we were going to have to upgrade it first.  Unfortunately,  and predictably, the flashing of the firmware would have been a disruptive process and was therefore shot down by management, since they won't allow planned downtime.

2 Intern

 • 

20.4K Posts

October 14th, 2010 21:00

is this host based migration ?

No Events found!

Top