golden grotto
Hello all,
Creating LUNs for a dedicated host is not an issue, this, via CLI or System Manager.
But shared LUNs across a 2 nodes MS failover cluster might be a different story...
Usually, our 6.0 SnapCenter server is doing the job, unfortunately it is out of order (once again...), therefore I would like to know what is the recommended way to create shared LUNs ?
Could it be done both via CLI and System Manager ?
Thank you in advance.
Regards.
brazen ice
The only thing that you have to do is map the LUN to an igroup with two (or more) hosts in it. The LUN itself is not in any way special. You can do the mapping through CLI or system manager
if you already have a (shared) iGroup on your SVM from another LUN, it's even easier, just create a new LUn and map it to that iGroup and you're done
golden grotto
OK thanks for your quick response, I will give it a try !
covert urchin
yep, igrp = multi-host
It's actually how we provision all of our LUNs for our SQL clusters
buoyant leaf
Cheat!
Make individual igroups for each host.
Then make a group igroup for the cluster
igroup create -vserver xxx -igroup host1…
igroup create -vserver xxx -igroup sql -child host1,host2 …
This technique allows for creating individual igroup for each host for possible single-host attach but also creates a grouped igroup for a cluster.
To add more to the group you just add more children
covert urchin
aye, that's exactly how we do it.
Don't know why you wouldn't
golden grotto
This means that in our case SnapCenter is almost useless ... The only benefit from this software is to avoid typing the long command lines with multiple parameters to create LUNs !
golden grotto
Hello,
I fully agree with the procedure described by you all, it makes sense.
However, I have encountered an issue, it seems that those shared disks were unusable in Windows Failover Cluster Manager (SQL cluster).
I did checked that shared disks appeared in Windows Disk Management on both cluster nodes, that was the case, and I made sure that in WFC those disks were seen if I right-clicked on " Storage ---> Disks ---> Add disk ", once again it was OK.
I do not know yet what was exactly the issue, I will try to reproduce it tomorrow with our SQL admin.
In the meantime, we installed SnapCenter 6.0.1 agents on both SQL cluster nodes where I provisioned shared LUNs via CLI, then a discovery of the resources of this cluster showed that those disks are dedicated, not shared :
On others SQL clusters, where shared LUNs have been provisioned via SnapCenter, disks appear as shared:
So, I guess there is a (slight) difference between provisioning shared LUNs/disks via CLI and SnapCenter... Or am I missing something ?
Any idea ?
Thanks.
covert urchin
on each of the windows systems do you have the netapp host utilities installed, multipath enabled and configured to the netapps, and the iscsi configs set properly?
If each server sees the disk, only one of them can 'own' it, and that's managed by the failover cluster tools.
vague seal
Back in the EMC days, we used to enable scsci3_persist_reserve on windows cluster luns . Not sure that is still a thing.
Edit : I couldn’t find a correct option to set the scsi3 persistent reserve option on netapp Luns. However there is an option in the advanced mode to show and clear persistent reservation. “lun persistent-reservation”. So chances are, the option may be enabled by default and it’s up to the initiator to use it or not. This bit is used to lock down a lun to the node.
golden grotto
on each of the windows systems do you have the netapp host utilities installed, ...
Hello @covert urchin ,
Host Utilities is not installed on any of our Windows servers in our environment and we do not encounter any issue usually.
However, I guess it is a best practice to install it, am I right ?
I downloaded latest release, 7.2.
---> Based on NetApp documentation, it looks like Host utilities is adapted to FC infrastructure, what is the point to use it in iSCSI environment ?
Multipath is enabled and configured through MPIO.
iSCSI configuration is OK, LUNs/disks are discovered via Disk Management.
Hello @vague seal ,
Command line " lun persistent-reservation show -vserver xxxxxxxxxxx -path /vol/yyyyyyyyyyyy/zzzzzz " for the LUNs that are not seen as shared by SnapCenter returns the following output:
And for a LUN seen as shared, the output is the following:
How can I interpret and understand the meaning of those outputs ?
Why in one case there is only 2 entries and 6 in the other case ?
covert urchin
The host utilities are not just for FC, there are several settings for iSCSI that are set when you install. It sets things like timeout, retry, etc.
vague seal
Hello <@1150874556131704882> ,
Command line " lun persistent-reservation show -...
Hi, sorry for my late response. In both the cases only one host seems to have write access, so that is the expected and correct response Now , why 6 entries in the second screen shot - chances are the - in the first case it is mapped to 2 initiators versus 2nd case it is mapped to 6 initiators Would you also share the out put of lun show -m for both the cases
buoyant leaf
It’s likely not configured correctly. In the ms iscsi tool:
go to the discovery tab. Cycle through each iteration of initiator and target.
Select ms iscsi. Select local ip dedicated for iscsi. Select one NetApp target on same network. Repeat for each combination. Reboot the host to reset the connections.
After it reboots, log into the Netapp:
set diag
iscsi initiator show -fields tpgroup,tpgroup-tag, initiator -sort-by vserver, initiator, tpgroup,tpgroup-tag
You can use the tpgroup tag to exactly identify each and every connection.
Go to the targets tab. Click on the name and hit properties. You should see all the sessions connected, each with a tpgroup tag. Look at each one. Verify the lif/ip it is attached to. You only need one connection per lif. Remove unneeded sessions.
Verify the discovery.
Verify favorites. Remove unneeded entries.
Reboot. Verify you only have the needed connections
Failover the application and repeat on the other host
If needed, remove everything in favorites. Remove everything under discovery. Remove all but one session under the name/properties/sessions. reboot. After reboot you should have one session. Use directions above
covert urchin
yep.. troubleshooting iscsi is time consuming, but having multiple targets on one system and not others is 99% config issue on that system
buoyant leaf
I just did this with a customer to clean up the connections. They originally used the primary interface (iscsi traffic on same vlan as everything else). Updated vm with two vlans. Took a few reboots to successfully clean all connections so that only the ones needed/wanted survived.
golden grotto
Hello,
This difference (6 entries vs 2) is encountered with all shared LUNs for the 2 SQL clusters I compared.
The " lun show -m -vserver xxxxxxxxxxxxxxx -path /vol/yyyyyyyyyyyy/zzzzzz " does not provide much more information:
I have checked the iSCSI initiator configuration and did not noticed anything wrong, all needed sessions are connected to a unique LIF, it looks good.
Would NetApp Host Utilities helps in that case ?
I have installed that tool on a VM that has iSCSI LUNs (MPIO used), it seems that no GUI is available for this tool, is that normal ?
I only noticed the registry values set by the software as described in NetApp documentation.
buoyant leaf
The tools will not necessarily help fix this. There is a setup/configuration issue that you are very likely missing on the windows side.
I provided some details to walk through.
There are many ways to configure but only a few of them are correct. If you are seeing too many paths then you likely have extra entries in discovery or favorites (on the windows side).
The best thing to do is to start over. Remove all discovered items. Remove all but one session. Remove all favorites. Then reconnect each session properly.