Windows iSCSI Disk Drops After LUN Mapping 'Add-Reporting-Nodes'

[nzmarkc]

ONTAP version:  9.8P1

Windows version: 2012 (R2?)

Background:

• existing FAS8020 has had A220 added to the cluster
• planning vol moves from FAS8020 to A220
• majority of existing LUNs on FAS8020 had no reporting nodes

Action:

• on all LUNs:
  • ran a 'lun mapping add-reporting-nodes -path <lun path> -igroup <igroup> -vserver <vserver> -destination-aggregate <new node aggregate>
  • ran a 'lun mapping add-reporting-nodes -path <lun path> -igroup <igroup> -vserver <vserver>  -local-nodes true

Problem:

• Customer reported that their Windows 2012 server databases were going down
• Servers dropped the mapped iscsi disk
• BUT all target connections still showed as up in the iSCSI initiator properties

Questions:

1. Any ideas as to what might have happened?
2. Any pointers to documentation that might help with why it happened?

So far, all we can come up with is: "that's just windows" - but it's not something I can go back to the customer with!

Thank you all in advance.

[hmoubara]

Hello,

Not sure about the detail steps taken while performing the vol move and add-reporting node.  This article describes the procedure that should be followed to rescan and recover LUN paths in different Operating Systems (OS), while moving a LUN or a volume containing LUNs to another HA pair within the same cluster. Modify the Selective LUN Map (SLM) reporting-nodes list, before initiating the move (add-reporting-nodes) and after the move is completed (remove-reporting-nodes).

The procedure below ensures that active or optimized LUN paths are maintained in the host OS multipathing.

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/How_to_rescan_and_recover_LUN_paths_in_a_host_after_modifying_SLM_repo...

Hope this answer your questions.

Thanks 

[nzmarkc]

Hey @hmoubara - thank you for the feedback.

RE: "Not sure about the detail steps taken while performing the vol move and add-reporting node"

NO volume moves had been attempted. This was preparation for the moves.

None of the NetApp documentation (that we could find) says anything about the process of adding reporting nodes as being disruptive. And from what myself and my colleagues saw, the process of adding reporting nodes did not disrupt the initiator to target iscsi connections, but the disk mount in the Windows server was dropped. I notice that the title of the link you provided contains the term "recover LUN paths".  Could this be an indicator that the add-reporting-nodes process affects the LUN paths?

[hmoubara]

Hello,

Was there any errors seen on the host side or a rescan that was performed after modifying the Selective lun mapping (SLM)?

[paul_stejskal]

Also did you add the targets or confirm the targets IPs were added to the Windows server ok?

[nzmarkc]

Hello @paul_stejskal RE: "add the targets or confirm the targets IPs were added to the Windows server ok"

The targets and IPs (pathways) were all functional up to the 'add-reporting-nodes' and even still existed after the command was run on all the LUNs. It was just the disk mapping in the Windows servers that disappeared. BTW: the iscsi connections are all legacy and were not set up by us.

[paul_stejskal · Accepted solution]

It may be good to open a case to dig further.

[nzmarkc]

Hi again @hmoubara RE: "any errors seen on the host side or a rescan that was performed "

The customer did not report any errors other than the fact that the Windows mapped drive (which was via iscsi) disappeared. The disk reappeared after a rescan. And unfortunately we don't have access to the servers on the customer prem.