DMP With CLARiiON:-
CLARiiON arrays are active-passive devices that allow only one path at a time to be used for I/O. The path that is used for I/O is called the active or primary path. An alternate path (or secondary path) is configured for use in the event that the primary path fails. If the primary path to the array is lost, DMP automatically routes I/O over the secondary path or other available primary paths.
For active/passive disk arrays, VxVM uses the available primary path as long as it is accessible. DMP shifts I/O to the secondary path only when the primary path fails. This is called "failover" or "standby" mode of operation for I/O. To avoid the continuous transfer of ownership of LUNs from one controller to another, which results in a severe slowdown of I/O, do not access any LUN on other than the primary path (which could be any of four available paths on a FC4700 and CX-Series arrays).
Note: DMP does not perform load balancing across paths for active-passive disk arrays.
DMP failover functionality is supported and should attempt to limit any scripts or processes from using the passive paths to the CLARiiON array. This will prevent DMP from causing unwanted LUN trespasses.
To view potential trespasses, look at the ktrace (kt_std) information from SPcollect, messages similar the following can be seen happening with regularity.
09:07:31.995 412 820f6440 LUSM Enter LU 34 state=LU_SHUTDOWN_TRESPASS
09:07:35.970 203 820f6440 LUSM Enter LU 79 state=LU_SHUTDOWN_TRESPASS
09:07:40.028 297 820f6440 LUSM Enter LU 13 state=LU_SHUTDOWN_TRESPASS
09:07:42.840 7 820f6440 LUSM Enter LU 57 state=LU_SHUTDOWN_TRESPASS
The "Enter LU ##" is the decimal array LUN number one would see in the Navisphere Manager browser. When the messages occur, there will be no 606 trespass messages in the SP event logs. This is an indication that thetrespasses are the 'masked out' DMP trespass messages. Executing I/Os to the /dev/dsk device entry will cause this to happen.
Using the SPcollect SP_navi_getall.txt file, check the storagegroup listing to find out which hosts these LUNs belong to. Then obtain an EMCGrab/EMCReport from the affected hosts and you will need to look for a host-based process that could potentially be sending I/O down the 'passive' path. Those I/Os can be caused by performance scripts, format or devfsadm commands being run or even host monitoring software that polls all device paths.
One workaround is to install and configure EMC PowerPath. PowerPath disables the auto trespass mode and is designed to handle I/O requests properly so that the passive path is not used unless required. This will require changing the host registration parameter "failover mode" to a '1'. This failover mode is termed an "explicit mode" and it will resolve the type of trespass issues noted above.
Setting Failover Values for Initiators Connected to a Specific Storage System:
Navisphere Manager lets you edit or add storage system failover values for any or all of the HBA initiators that are connected to a storage system and displayed in the Connectivity Status dialog box for that storage system.
1. In the Enterprise Storage dialog box, navigate to the icon for the storage system whose failover properties you want to add or edit.
2. Right-click the storage system icon, and click Connectivity Status.
3. In the Connectivity Status dialog box, click Group Edit to open the Group Edit Initiators dialog box.
4. Select the initiators whose New Initiator Information values you want to add or change, and then add or edit the values in Initiator Type, ArrayCommPath and Failover Mode.
5. Click OK to save the settings and close the dialog box.
Navisphere updates the initiator records for the selected initiators, and registers any unregistered initiators.
Background Verify and Trespassing
Background Verify must be run by the SP that currently owns the LUN. Trespassing is a means of transferring current ownership of a LUN from one SP to the other. Therefore, aborting a Background Verify is part of the trespass operation – it is a necessary step.
Not sure how old your post is, but DMP 5.0 most definitely supports various load balancing policies for CLARiiON (minqueue, round-robin, etc.).
However, on Solaris, we have an issue where format, devfsadm, etc. commands that cause the passive paths to be probed generate Solaris "device offline" messages. With large systems, this can be hundreds of messages every time a scan is done. Sun, Veritas, EMC have provided no mechanism to disable this, except for disabling DMP load balancing (use single active policy). Do you know much about this issue?
Ian: See VxVM 5.1.
VERITAS Native Multipathing feature performs the 'intercept driver' behaviour like Powerpath on AP/F storage (Not just Clariion).
Those device offline messages are a thing of the past.