I have a lab environment where I have a Synology NAS that provides iSCSI targets which are used by Windows 2012 R2 VM's running on virtual box.
I want to setup a Windows Failover Cluster and in order to do so the VM's need to share a disk.
I added a new target with a new LUN. I added this via the iSCSI initiator on the VM, formatted the disk and then added in the Storage Disks for my cluster via the Failover Cluster Manager. I can bring the Role online and it correctly initiates the disk.
By default the Synology does not allow multiple connections to the same iSCSI target.
Not enabling multiple sessions results in only one node to connect thus bring the corresponding disk online. Performing a Failover didn't automatically bring the iSCSI connection up on the other node.
It seems I have the following options:
Enable *Allow multiple sessions from one or more iSCSI Initiators. This has the large warning:
To avaoid risk of significant data corruption, please make sure you are operating in a cluster aware filesystem.
Add an additional target to the LUN. Having two targets share the same LUN thus having a target per cluster node.
Both of these options result in that the iSCSI initiators on both nodes are able to connect to the iSCSI targets.
Questions:
- Which of these should I use?
- Both seem to work does it make a difference? I understand that a target has its own buffers.
- Is Windows Failover Clustering supporting this?
- Which of these can result in data loss?
- I also see that I can create a Shared cluster volume should that be used? Maybe I'm doing it completely wrong.
What I read and what I understand suggest to me that in either case you're likely to end up with corruption unless you're using a cluster-aware file system such as CSVFS. I'm not a Synology user, but I do work with iSCSI and Failover Clusters.
I would say that in your case, allowing multiple sessions will be the most appropriate option. Adding a new target might be helpful if you wanted to take advantage of MPIO, where you have two separate network segments for accessing the storage simultaneously, thus creating redundant paths.
It sounds like this would be a supported solution, and yes you should add the disk to cluster shared volumes, but you only do this once all nodes are able to 'see' the LUN.
After you've done this you can experiment by moving the CSV between nodes and seeing it stay online, and shutting down cluster nodes to watch it fail over.
One other thing... All nodes in the cluster need to be able to communicate with each other so that they can co-ordinate activities and keep an eye out for nodes going offline (heartbeat).