- Decide which of the nodes you trust as having the latest version - although in terms of clean shutdown it should be either
- Manually mark that node as synchronised
- Manually start re-sync to the other node
Cheers, Rob.
Moderators: anton (staff), art (staff), Max (staff), Anatoly (staff)
I`m not sure that I understood your question correctly, so correct me if I`m answering something wrong, but the StarWind will automatically detect what node has most recent data and will initiate the synchronization in proper direction automatically.I'm also a little concerned where disk IO goes when you power-up back up after a clean shutdown. The iSCSI connection is to both nodes but the nodes are not connected. What is the algorithm in this case? In the case of a power outage with clean shutdown, when power is restored and the SAN is restarted, disk IO will start. Where does it go?
Well, we`ve got nothing from you in our mailboxes yet. Let me know if you sent anything.it's taking a lot time to sync. I'm tempted to raise a support call on this specific case.
It happens in one of two cases:Power restored but assume something has gone wrong with SAN90 - it hasn't powered up for some reason. SAN91 has come back online as well as TEST90. However, iSCSI is stuck in reconnecting (see attached screenshot).
Next time don`t forget to check the FAQ: http://www.starwindsoftware.com/starwind-faq#q_11I've just found "Mark as synchronised" which I assume is the option to be chosen in the disaster scenario? It says it'll start processing client requests immediately - sounds like that's what I want it to do. The iSCSI initiator on TEST90 is still saying "Reconnecting" - will leave it a little longer to see if it manages to reconnect automatically.
Well wow:)Just impatience The iSCSI targets are now reconnecting to the one node that's up. So the steps that we'd have to document currently even after clean shutdown are:
Decide which of the nodes you trust as having the latest version - although in terms of clean shutdown it should be either
Manually mark that node as synchronised
Manually start re-sync to the other node
The reason for not starting re-sync first as in the lab it currently seems to not do a fast resync and therefore the resync could take some time. Marking one node as synchronised first means at least you can get everything else back up online which resync is carried out.
Have you checked the disk errors?Hmm, not good - the LSFS storage is stuck in a continual synchronisation loop. I checked a while back and it was at over 50%. Just checked now and it's back to 9%. The non-LSFS storage has synchronised fine. Will leave it overnight.
I'm just doing that - my lab PC is currently on the bench with all it's guts hanging out I'm doing some low-level bench marks plus wiping the disks using Active KillDisk:Have you checked the disk errors?
I dealt with this issue by placing an additional UPS inline for our primary node, it will be the last node to go down and is programmed to shutdown cleanly, where as node #2 will go down hard straight away.epalombizio wrote:It would really be good if there was an option to determine the last HA member to write to disk and auto sync based on that member being the primary.
While I haven't installed v8 yet, I've been bitten by this issue multiple times in v6. If we have a power outage and both HA members shutdown cleanly, there is no reason that I know of why it couldn't be setup to auto sync. I was hoping this would have been fixed in v8.
Why count? StarWind service will not be stopped until the data will be flushed.Count to 10 to allow everything to flush to disk
May I doublecheck why do we want it? I mean, what`s the reason and purpose?A wish here - ability to put StarWind into maintenance mode - a special state where a clean shutdown can be carried out safe in the knowledge that it will only wake up cleanly when one takes it out of maintenance mode. XenServer has this feature and it's a nice addition.
The trick here is the primary node is don`t know what happened when it was down - maybe you brought second node, and made it primary, for example. Thats why the sync is not automated here.Another snippet here. In the attached screenshot, I've just shutdown the second node and it's disconnected from the console as expected. However, note that it says that the primary node is synchronised. So how come when I shut this server down and restart it, it changes to Unsynchronised? Nothing has changed (well aside from a reboot) so the node should still be synchronised should it not? This may be the reason that auto-synchronisation isn't working.
Because of the confusion of node synchronisation after clean power down. Just an idea so that one can control the function manually. If auto-synchronisation worked better then it might not be needed.May I doublecheck why do we want it? I mean, what`s the reason and purpose?