locked
Why continue to choose disk witness when file share witness is better RRS feed

  • General discussion

  • Hi,

    I have made a lot of tests  last 3 weeks and my conclusion is : File share witness is the best option.

    And this is why :

    I have 2 nodes clusters running on physical blades in 2 different chassis.

    - Node 1 owns witness disk and one role (sql)

    - I remove network cable from chassis where node 1 is running.

    - Node 1 never release disk reservation on witness disk and cluster service is stopping on node 2.

    When i would like Node 2 become the only surviving node ....

    Same test but using file share witness.... 

    As node 1 is losing connectivity to file share witness, node 2 can take ownership and become the surviving node with my role running.

    I am surprised to not see others people with same conclusion. Am i wrong somewhere ?

    Thanks for sharing your thoughts 

    Wednesday, June 24, 2020 6:19 PM

All replies

  • Nobody with same conclusion or any comments ?

    Meaning that when you have network issue, you are not sure to have your resources online on right side ?

    Sunday, July 5, 2020 9:05 PM
  • For me is not possible  to add the file share witness , because i have only 2 node Hyperv cluter and have no other external servers in datacenter which i can use for file share witness, so i have to add shared witness disk

     


    My issue is when i try to  add Witness disk to the cluster to configure quorum with cluster Quorum wizard ,  disk it doesn't appears as storage volume.

    On windows disk manager is available 



    • Edited by myissar Friday, July 17, 2020 3:36 PM
    Friday, July 17, 2020 3:00 PM
  • Hey, 

    You can use StarWind VSAN free to create Witness disk for the cluster. The process is easy and works stable with fast failover, if needed. The following guide will help you configuring it: https://www.starwindsoftware.com/resource-library/starwind-virtual-san-for-hyper-v-2-node-hyperconverged-scenario-with-windows-server-2016/

    Cheers,

    Alex Bykvoskyi

    StarWind Software

    Blog:   Twitter:   LinkedIn:  

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Saturday, July 18, 2020 7:59 AM
  • Hi,

    there are two scenarios in Failover Clustering: Host failure and host isolation. WSFC historically was designed to recover from failure, and this it will do equally well both using a disk and a file share witness.

    Now isolation is a different beast entirely, and even more so in a two node cluster. As long as you have more than two nodes, a single host that becomes isolated knows that it is time to shut down. With two nodes, 'a single host' equals 'half of the hosts' or 'one datacentre' so it's hard for the host to decide whether it's on the surviving or on the dying side. By using FSW *over the heartbeat network* you make isolation of one host appear as the lost of that host to the other node.

    To summarize, it could be said that

    • the 'best option' is not to use two node clusters if it can be avoided,
    • but in a two node cluster, FSW allows for surviving severed networks, as long as it's accessed over the heartbeat network (or at least a network that is *physically* identical to heartbeat)
    • if the witness in a two-node cluster is accessed by other means than heartbeat network, the severed heartbeat will create a split-brain condition
    • for the 'host failure' scenario, both techniques are equally well suited.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Saturday, July 18, 2020 8:43 AM