Solved: New Cluster Nodes Not Showing in NetApp DSM for MPIO - Page 2

TMADOCTHOMAS · ‎2016-10-10

I've just added two new nodes to our production cluster. I've added two new iSCSI LIFs on the nodes and added those LIFs to the port group. I've used SnapDrive to add connections to the two new iSCSI LIFs on the first of many Windows hosts. After doing this, I checked the Data OnTAP DSM for MPIO software to be sure it was showing 4 nodes per LUN. It is not. It is still just showing two paths. Any ideas as to what I am missing?

bobshouseofcards · ‎2016-10-10

Assuming you are running cDoT 8.3 or higher, you are likely encountering the new "Selective LUN Mapping" feature. This feature was added in cDoT 8.3 to address the multiplication of paths across large clusters that can impact server based total and per LUN path limits.

From the SAN Administration Guide...

Selective LUN Map

Selective LUN Map (SLM) reduces the number of paths from the host to the LUN. With SLM, when a new LUN map is created, the LUN is accessible only through paths on the node owning the LUN and its HA partner.

SLM enables management of a single igroup per host and also supports nondisruptive LUN move operations that do not require portset manipulation or LUN remapping.

Portsets can be used with SLM just as in previous versions of Data ONTAP to further restrict access of certain targets to certain initiators . When using SLM with portsets, LUNs will be accessible on the set of LIFs in the portset on the node that owns the LUN and on that node's HA partner.

Beginning with Data ONTAP 8.3 SLM is enabled by default on all new LUN maps. For LUNs created prior to Data ONTAP 8.3, you can manually apply SLM by using the lun mapping remove-reporting-nodes command to remove the LUN reporting nodes and restrict LUN access to the LUN owning node and its HA partner.

I ran into the same situation myself when adding nodes 5 and 6 to a cluster, moving some LUNs there, and then not seeing direct paths. Mine was FCP, but since this applies at the LUN mapping level it would be just as applicable to iSCSI as well.

The commands of interest to you are:

lun mapping show -field reporting-nodes -vserver <SVM> -path <lun-path>

lun mapping add-reporting-nodes ...

lun mapping remove-reporting-nodes ...

SLM provides for very specific path control and in conjunction with portsets can limit path proliferation especially as the number of potential ports increases and the number of allowed hosts in a SAN cluster increases with refreshed hardware and ONTAP 9.1.

Hope this helps.

Bob Greenwald

Senior Systems Engineer | cStor

NCIE SAN ONTAP, Data Protection

Kudos and accepted solutions are always accepted.

View solution in original post

TMADOCTHOMAS · ‎2016-10-12

Bob, thank you!

After this whole discussion, I still believe I'd like to play it safe and go ahead and add the reporting nodes for 3 and 4 before migrating the LUNs. To do that, i believe the following commands would work. Does this appear correct?

lun mapping add-reporting-nodes -vserver <vserver> -path <LUN_path> -igroup <Igroup_Name> -destination-aggregate <aggregate_on_node_3>

lun mapping add-reporting-nodes -vserver <vserver> -path <LUN_path> -igroup <Igroup_Name> -destination-aggregate <aggregate_on_node_4>

For the <LUN_path>, do you happen to know how the wildcard feature works. Specifically:

Can I do this: /vol/<servername>*

Instead of this: /vol/<servername>*/<servername>*.lun

bobshouseofcards · ‎2016-10-12

Those commands are the right form but you only run one of them per volume to be moved. So you would not run both commands for all aggregates. An aggregate exists within a node HA pair construct. It is owned by one node, but will failover to the other node. Hence, when you add the nodes associated with a destination aggregate, you are adding both nodes in the HA pair since either one could own the aggregate.

And the wildcarding works as you'd expect. * matches everything.

Bob Greenwald

Senior Systems Engineer | cStor

NCIE SAN ONTAP, Data Protection

TMADOCTHOMAS · ‎2016-10-17

Thanks Bob. So just to be sure I understand, are you saying I only need to add ONE destination aggregate from the HA pair, as seen below:

lun mapping add-reporting-nodes -vserver <vserver> -path <Server_Name>* -igroup <Igroup_Name> -destination-aggregate <aggregate_on_node_3_or_4>

.... or, should I add both aggregates on one command line as seen below:

lun mapping add-reporting-nodes -vserver <vserver> -path <Server_Name>* -igroup <Igroup_Name> -destination-aggregate <aggregate_on_node_3>,<aggregate_on_node_4>

bobshouseofcards · ‎2016-10-18

You need only add the one aggregate. The idea behind adding an aggregate is to add the aggregate where you are going to move the volume that contains the LUN.

ONTAP knows that both nodes in an HA pair could potentially own that aggregate (either through failover or through manual aggregate relocation) so both will be set as "reporting" nodes. Obviously only one will be an optimized path at any given time, but paths to both nodes become available.

You can see the results immediatly if you use the command lun mapping show -field reporting-nodes with SVM and LUN qualifiers before and after the "add".

Running a second "add" to target an aggregate on the HA pair is not needed but it also doesn't hurt anything. It's just redundant in that both nodes of the HA pair are already added by the first command.

Hope this helps.

Bob Greenwald

Senior Systems Engineer | cStor

NCIE SAN ONTAP, Data Protection

Kudos and accepted solutions are always appreciated.

TMADOCTHOMAS · ‎2016-10-18

That answers my questions, thank you again Bob. This has been a very helpful thread!

bobshouseofcards · ‎2016-10-12

Always forget about that on the remove (since I rarely do myself).

Thanks for the clarification!

Bob Greenwald

Senior Systems Engineer | cStor

NCIE SAN ONTAP, Data Protection

TMADOCTHOMAS · ‎2016-10-11

Bob,

Really appreciate your comments, they are helping a lot.

I had intended to leave all four paths available, just in case for some reason I needed to move a volume/LUN back to the original nodes. Would you recommend against that?

If I do remove the original reporting nodes, and follow the sequence "add new/remove local/move volume", won't that break the existing volumes/LUNs since they will not be on reporting nodes anymore? I may not be understanding the role of a "reporting node".

Here are my thoughts on the syntax I need. Does this look correct?

lun mapping add-reporting-nodes -vserver <vserver> -path <LUN_path> -igroup <Igroup_Name> -destination-aggregate <aggregate_on_node_3>

lun mapping add-reporting-nodes -vserver <vserver> -path <LUN_path> -igroup <Igroup_Name> -destination-aggregate <aggregate_on_node_4>

Lastly: for the <LUN_path>, can I enter a * wildcard character at the end of the volume name to make it cover any volume/LUN starting with that volume name? In other words:

Can I do this: /vol/<servername>*

Instead of this: /vol/<servername>*/<servername>*.lun

(or will either work)