Hi team!
Here's a case that An Alarm of No Redundant Link Exists After Storage Array Upgrade Because of Slow Device Deletion Following Windows iSCSI Link Interruption.
Symptoms
A Windows host is interconnected with the storage.
The host is connected through iSCSI links to the two controllers of an engine.
The storage is upgraded in the online mode, with the host running I/O services.
Storage controllers are upgraded one by one.
When all controllers are upgraded, an alarm is displayed indicating there is no redundant link.
Alarm Information
An alarm indicating there is no redundant link is displayed on the DeviceManager.
Possible Causes
The Windows iSCSI network has large-block I/Os or a large number of concurrent I/Os.
As a result, the device deletion and reporting periods are long when iSCSI links are interrupted and being recovered.
Identification Method
Procedure:
Step 1 Confirm that the upgrade is complete and the host is running correctly.
Step 2 In UltraPath key events, confirm whether links on a controller were deleted after the upgrade is complete,
as shown in the following figure:
Confirm whether iSCSI initiator link interruption is reported in Windows system events to check whether iSCSI links are interrupted. The following figure shows an example:
From the preceding procedure, the following can be confirmed:
Windows does not delete LUN devices on the relevant targets;
LUN devices on the relevant targets of controller l 1 start to be deleted after the storage upgrade,
causing the link between the multipathing software and controller 1 to be in a disconnected state.
Device deletion takes approximately 35 minutes.
Analysis:
After a link status change, Storport delivers the SCSCI command to all buses, targets, and LUNs supported by MSISCSI to confirm current devices.
MSISCSI has an upper limit for the number of I/O requests being processed.
If the current number of I/O requests exceeds the limit, some I/O requests wait in a queue.
As a result, the SCSI command is delayed, which in turn leads to device deletion delay.
This issue is caused by system design of Microsoft.
Microsoft gives an official explanation for this issue on https://support.microsoft.com/en-us/kb/3073577.
As a result, links are interrupted and recovered, causing long device deletion and reporting periods and a delay of 10 to 30 minutes.
In extreme cases, the system tries to delete a device when another controller restarts,
causing the host to have no available links, I/Os to fail to be delivered, and services to be interrupted.
When this issue occurs, there has been an I/O delay of one to two seconds, and host services are already running slowly.
This issue is caused by system design of Microsoft.
Windows does not ensure devices can be deleted or reported within specified time.
This issue is a third-party issue.
Troubleshooting Procedure
Step 1 Query the service running status.
It can be seen that the service is running slowly.
Step 2 Reduce the I/O pressure to enable the service to run smoothly.
Device deletion and creation are completed in short periods.
Check After Recovery
Observe for a certain period of time to ensure smooth service running.
If the alarm persists, contact Huawei engineers.
Application Scope
This issue has nothing to do with the storage array version.
It is related to the Windows operating system.
