Page 1 of 1
Using Starwind iSCSI for a Windows Failover Cluster
Posted: Mon Feb 25, 2013 10:03 pm
by teleute
I've installed the free version of Starwind iSCSI SAN to test and see if it would be usable for our purposes and therefore whether we should purchase it. We're trying to set up a Windows Failover Cluster for our HPC Head nodes, so we need two shared locations - one for the witness, and one for the HPC data (which is stored in a SQL db). I asked on the MS forums how to do this if one doesn't have a SAN, and it was suggested that I could use Starwind to emulate a high-availability SAN on the direct attached storage of the two servers in question. (
http://social.technet.microsoft.com/For ... 4e68099b95)
So I'm working on this, and having some issues. I've installed iSCSI SAN, and added a High Availability image. Since we don't have any virtual disks, I selected the "Create HA device from the device" option, even though it says it's experimental - if that's experimental, how is this normally done if the server is bare metal, not virtual?
I tried the experimental option, but it's not working. I can create an iSCSI initiator to the disk from both servers, and it shows up on both. However, if I reboot either server, when they come back up the iSCSI initiators just hang at "Reconnecting".
If anyone has any ideas as to how I can proceed, I would very much appreciate it; been banging my head against this for a few days now. Thank you!
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Mon Feb 25, 2013 11:00 pm
by teleute
Also, I'm a bit confused - if I set up the HA image, it's (kind of) mirrored between the two devices, correct? So when I set up my iSCSI connectors, do I point them at the primary target, or the secondary, or set up MPIO and point to both?
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Tue Feb 26, 2013 9:19 am
by sjender
I have exact the same question.
I'm also looking forward to an answer in this thread.
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Tue Feb 26, 2013 5:13 pm
by Anatoly (staff)
Hell gentlemen,
By saying "this feature is experimental" we are assuming that this feature is under beta-testing, and we strongly do not recommend to put it in production environment, otherwise you can get some errors and face malfunctions which are expectable for beta products.
I`d recommend you to go and create HA basing on the virtual disks. Here are some docs that you guys might find helpful for you:
http://www.starwindsoftware.com/configu ... erver-2012
http://www.starwindsoftware.com/configu ... or-smb-nas
http://www.starwindsoftware.com/sw-prov ... le-servers
http://www.starwindsoftware.com/install ... er-2008-r2
http://www.starwindsoftware.com/starwin ... ng-started
Please let me know if you guys have any additional questions.
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Tue Feb 26, 2013 9:24 pm
by teleute
I'm sorry, but I'm having a hard time figuring out what info on those docs is applicable in our case. The majority of them seem to reference Hyper-V, which we're not using. I'll keep going through them, but so far I haven't seen our situation in these guides. Thank you.
ETA: Ah - my apologies. I just discovered that you can create a virtual disk directly in Windows now, even without Hyper-V (I work a lot more in Linux on the server side...). I'll try that and post back with results.
Further ETA: So, I tried creating virtual disks in Windows, and then selecting "Create HA device from the virtual disk". This did not work, as it seems to be looking for .img files, not .vhd. I then tried the only remaining option, to create the device from virtual disk, and create new. This so far appears to work, and to be what I should have chosen from the start (I chose the bottom selection initially thinking it would work like this one; I just misread the descriptions, I guess). So that's part I think is good - we'll see once I actually get the iSCSI part set up whether it's behaving as intended. Thanks!
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Wed Feb 27, 2013 12:53 am
by teleute
Okay - in the first document, under "Connecting Targets", it says:
"Click Discover Portal. Enter an IP address of each StarWind Server in the appropriate field of the Discover Target Portal dialog. Click OK."
But while that says "an IP", there are 4 addresses there. From previous diagrams, this looks to be two from each server. Also, those are the two that are selected as heartbeat only. Does this matter?
We've only got 2 network connections on each server, one on our enterprise network and one on a private. I've assigned one each to heartbeat and to heartbeat+sync. When I get to the above step, should I just be putting in the heartbeat only IP for each, or the sync+heartbeat IP, or both? If I put in all 4, I still don't get the option to select a different path in Step 8 of that same section - only one shows, no matter what.
I hope this makes sense - I'm just finding this section somewhat unclear. Thank you!
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Mon Mar 04, 2013 10:12 am
by Anatoly (staff)
The are a lot of things to comment here. Lets go through it all one-by-one:
as it seems to be looking for .img files, not .vhd
Exactly. Our HA virtual disks are using the .img format. In future release our users will be able to create the HA basing on other virtual disk files propitiatory for StarWind, but I highly doubt that we will use .vhd files, which is propitiatory for MS Windows.
Okay - in the first document, under "Connecting Targets", it says:
"Click Discover Portal. Enter an IP address of each StarWind Server in the appropriate field of the Discover Target Portal dialog. Click OK."
But while that says "an IP", there are 4 addresses there. From previous diagrams, this looks to be two from each server.
To be honest I do not see any problem here - you have two SAN nodes that are running in HA mode, and you need to connect to both of them using minimum 1 path to each to configure everything properly.
Also, those are the two that are selected as heartbeat only. Does this matter?
Yes and no. HeartBeat is the simple ping signal, which is designed and developed for health monitoring status, so yes, it is important to have HB on as much data links as possible. But since HB is really low resource consuming process (its using ~200MB per month) it will not affect anything's performance.
We've only got 2 network connections on each server, one on our enterprise network and one on a private. I've assigned one each to heartbeat and to heartbeat+sync. When I get to the above step, should I just be putting in the heartbeat only IP for each, or the sync+heartbeat IP, or both? If I put in all 4, I still don't get the option to select a different path in Step 8 of that same section - only one shows, no matter what.
Well, first of all you couldn't configure each NIC to run SyncChannel and HB both (Wizard wouldn't simply allow you to do that missconfiguration), so I~d like to ask you to clarify how exactly have you configured everything. Please note that your SyncChannel should be isolated from anything else - SyncChannel NICs should run only synchronization processes. HeartBeat should be configured as I have mentioned above.
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Mon Mar 04, 2013 4:56 pm
by teleute
Sorry - I wasn't clear. The initial disk setup is fine - each machine has one NIC for heartbeat and one for heartbeat+data. When I'm talking about these configuration steps, I'm specifically referring to the iSCSI initiator setup as in the first document you linked to.
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Wed Mar 06, 2013 10:33 am
by Anatoly (staff)
Could you please clarify your question?
Thank you
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Wed Mar 06, 2013 4:44 pm
by teleute
I'm having a difficult time phrasing this differently, but I'll try. In the first document, you linked to (
http://www.starwindsoftware.com/configu ... erver-2012) under "Connecting Targets" (this is for the iSCSI Initiator) it says:
"Click Discover Portal. Enter an IP address of each StarWind Server in the appropriate field of the Discover Target Portal dialog. Click OK."
But while that says "an IP", there are 4 addresses there - 172.16.1.58, 172.16.1.59, 172.16.2.58, and 172.16.2.59. From previous diagrams, this looks to be two from each server. In those previous diagrams, each server has 4 IPs - two for heartbeat only, and two for heartbeat+sync. These 4 listed for the iSCSI connector seem to be the heartbeat only ones from each server.
However, we only have two on each server - one for heartbeat, and one for heartbeat+sync. I can put the heartbeat only IPs for each in the iSCSI Discover Target Portal box, and that's fine. However, when I get to step 8, "Select the same target and again click Connect. Perform the actions described in the items 6-7 of this section; this time specify another IP address as a target portal IP" there is no other IP address in the drop down. If, back in the earlier steps I put both the private and the enterprise IPs for each server (giving me 4, like in your example), there's still no second address here in the drop down on step 8. However, there's no indication that this step is optional, so it worries me that I'm seeing something different than what's indicated. Is this okay - can I move on with just the one? Or will it cause a problem? Shouldn't it be able to connect over both NICs?
I hope this is clearer. Thank you.
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Wed Mar 06, 2013 9:09 pm
by Joseph (staff)
Good Day,
Hopefully, I can shed some light here. Let's start by going over the StarWind Traffic Channels:
StarWind Management Console - This NIC does not have to be dedicated, and it can be shared with your LAN MGMT NICs
iSCSI Traffic - These should be segregated from you LAN either by dedicated switches or subnets, these NICs can be shared with your heartbeat
Heartbeat - The heartbeat can either be placed on the LAN MGMT NICs or the iSCSI NICs, they do not have to be dedicated
Sync - The sync channel NICs should be compeltely dedicated and on their own subnet, and should be directly connected server to server
The guides are only providing examples, so please don't get hung up on the amount of NICs that are listed in the Discovery Interface Tab. If you only have 1 iSCSI NIC per server, you will put the IP Address of each of the SANs iSCSI NICs in the Client's iSCSI Initiator Discovery Tab. When you refresh the targets you should see the target on each SAN Node; let's call them TestTarget and TestTargetSecondNode. When you connect, you can go into the advanced tab, and select the initiator IP and Target IP. Ideally, you would want dedicated NICs to each SAN on the client side as well, so the connections to each target (primary and secondary) should have unique Initiator IPs and Target IP's. In your case, you don't have to "Select the same target and again click Connect" because you don't have more than 1 NIC per SAN. You simply connect to the Primary, and then you connect to the Secondary. I hope this answers your questions.
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Thu Mar 07, 2013 5:04 pm
by teleute
In your case, you don't have to "Select the same target and again click Connect" because you don't have more than 1 NIC per SAN.
Ah - okay. I was confused partially because of the diagram, and partially because of the fact that I do have two NICs (but only one of them would be considered an iSCSI NIC, from your description. Thanks for that, by the way; it does help clear things up). One of my test servers just had a hardware failure, so we're moving ahead and ordering the production servers earlier than we meant to.

So I should have more interfaces to work with there. However, this definitely sheds some light. Thanks!
(Might want to say something about that "connect again" step being optional in that guide, though...might help. Thanks again!)
Re: Using Starwind iSCSI for a Windows Failover Cluster
Posted: Wed Mar 13, 2013 3:18 pm
by Max (staff)
Hi Teleute,
Sounds as a good idea, I'll ask our tech writers to include this in the upcoming documentation.