Symptoms

Note: This feature is set to be enabled by default. This alert is supported from XIOS 6.1 and later.Alert if lack of redundancy is detected for an Initiator. Symptom CodeAlert NameDescription 2400203 initiator_redundancy_state_non_redundant Initiator has non-redundant path connectivity (Connected to a single Storage Controller). The alert is raised for each initiator with this condition. As of version XIOS 6.1.0, it is possible to monitor path redundancy. When monitoring is enabled and a lack of redundancy is identified, an alert is issued.To disable path redundancy monitoring for an Initiator, run the "modify-Initiator" XMCLI command with the "path-redundancy-monitor-mode" set as disable, shown below: modify-initiator path-redundancy-monitor-mode="disable" initiator-id=<initiator_id> After the path redundancy monitor is disabled, the "show-initiators" and "show-initiator" XMCLI commands output indicate that its status is changed to disabled and the redundancy mode can be monitored using the "Path-Redundancy-State" parameter. Example: XMCLI> show-initiator initiator-id=1 show-initiator initiator-id=1 Initiator-Name: lgdrm1959-fc1 Index: 1 Cluster-Name: xbrickdrm978-979 Index: 1 Port-Type: fc Port-Address: 10:xx:xx:xx:xx:xx:xx:xx IG-Name: lgdrm1959 Index: 1 Path-Redundancy-Monitor-Mode: Disabled Path-Redundancy: Non-Redundant Non-Redundant Volumes:

Cause

The path monitor function is based on individual initiator WWPNs. It does not consider redundancy on host-level based on all initiators for a specific host. It provides an indication of lack of redundancy per initiator and not per host. That is, it may occur that at the level of the host that there is no lack of redundancy and we provide a false indication. Path Redundancy is being monitored based on Initiator-Target-LUN (ITL) at the SCSI layer. Throughput for every volume is monitored every 5 minutes. If any volume DOES NOT receive any traffic (I/O from an application or heartbeat from a Multipath driver) across at least two paths within 300 seconds, the cluster marks the initiator as non-redundant. ITL path redundancy for an initiator to a specific volume exists if the initiator has at least two healthy paths to two target ports on two storage controllers. PowerPath does not send out keep-alive (KA) or path test request to every ITL across a single Initiator-Target (IT) pairing. The KA or path test request is run at an IT basis. When there is low application SCSI I/O and multipath software runs a KA on such IT basis, XIOS code raises such false alerts even though there is no real SCSI path issue. Windows native Multipath driver does not send KA on the paths. This paired with low application SCSI I/O can raise such false alerts even though there is no real SCSI path issue. Initiators with multiple volumes can encounter time periods where one LUN may see little or no I/O. This triggers path redundancy monitoring to mark the initiator as being non-redundant despite other ITL paths being active redundant for the same initiator.

Resolution

In order to determine how to best address the alert, it is necessary for the customer to confirm if the non-redundant path is consistent with the network design. Proper zoning (FC) and subnetting (iSCSI) result in a configuration where each initiator is zoned to at least two different targets on two different storage controllers on the same brick. Path redundancy is necessary to avoid situations of Data Unavailability as a result of problems in multipathing. When one of the paths is down (for example, during NDU or FRU procedures), all traffic is channeled through the second path on the peer controller. In case the backup channel is down, there is no connection to the X-Brick and Data Unavailability occurs.However, there are some configurations where the storage recognizing only a single path is the preferred network configuration. For example, VPLEX may have a single backend initiator to a single XtremIO FC target. Scenario 1 - Redundant MultiPathing is Expected: Check if multiple paths were configured for the cluster. The following XMCLI command can be used to view the initiators and which XtremIO target ports each host HBA is connected to. show-intiators-connectivity target-details Verify that the network between the cluster and the host ports do not have any issues. Scenario 2 - Redundant MultiPathing is not Wanted:Use the following XMCLI command to disable the "Path-Redundancy-Monitor-Mode" modify-initiator IMPORTANT: It is highly recommended to disable path redundancy monitoring for any VPLEX initiators, as they show as non-redundant even when set to VPLEX best practice configuration. Scenario 3 - Intermittent low or no I/O on LUNs for Initiators leading to alert raising and removing. Review of the mechanism is under way to identify ways to improve the monitoring.You may opt to disable path monitoring for initiators as wanted per Scenario 2 if there is an expectation that the low I/O profile of mapped LUNs leads to alert raising and removing repeatedly.It is recommended to modify the alert definition to disable the send-to-call-home option to avoid service request for High Incoming Box due to alerts raising and removing for large number of initiators. Annotated in the Notes section

Support Cases