Failover Clustering and Network Load Balancing Team Blog
In this blog, I am going to discuss the considerations for configuring a File Share Witness (FSW) for the Failover Cluster hosting your workloads, on a separate Scale-Out File Server cluster. You can find more information on Failover Clustering quorum here.
File Share Witness on a Scale-Out File Server
It is supported to use a file share as a witness that is hosted on a Scale-Out File Server cluster. It is recommended that the following guidelines be considered when configuring your File Share Witness on a Scale-Out File Server:
Configuring a File Share Witness on a Scale-Out File Server
In this section, I will explain how you can create a file share on a Scale-Out File Server that will act as a witness for the cluster hosting your workloads. Therefore, you have two clusters – a “storage” cluster hosting your file share witness and a “compute” cluster hosting your highly available workloads.
You can configure a File Share Witness on a Scale-Out File Server as follows:
1) Create the Scale-Out File Server as described in Section 2.1 of this article.
2) Create a File share on the Scale-Out File as described in Section 2.2 of this article.
a. Modify the properties of the share to make it a non-CA share. Right-click on the share, select Settings and uncheck the Enable continuous availability checkbox.
b. Ensure that you have Full Control to the newly created share.
3) Configure the File Share as a Witness on your cluster
a. Using the Failover Cluster Manager
i. Type cluadmin.msc on an elevated command prompt
ii. Launch the Quorum Wizard by Right-clicking on the Cluster Name, Selecting More Actions and then selecting Configure Quorum Settings
iii. Select Next and then choose the Select the quorum witness option and select Next.
iv. Choose the Configure a file share witness option and select Next.
v. Specify the path to the File Share on your Scale-Out File Server and select Next.
b. Using Windows PowerShell
i. Open a Windows PowerShell® console as an Administrator
ii. Type Set-ClusterQuorum –FileShareWitness <File Share Witness Path>
You should now see the File Share Witness configured for your Cluster.
When you navigate to your File Share Witness share you will see a folder created for your Cluster.
This folder will have permissions for the Cluster Name Object of your “Compute” Cluster so that the entries in the folder can be modified on Cluster membership changes.
You will also notice a file Witness.log which contains the membership information for the Cluster.
You have now successfully configured a File Share Witness on a Scale-Out File Server, for the cluster hosting your workloads.
Clustering and High Availability
Hi, this guide helped me a lot. However i am experiencing a problem with my fileshare witness. My cluster keeps reporting a warning 1562 and error 1069: "Cluster resource 'File Share Witness' of type 'File Share Witness' in clustered role 'Cluster Group' failed."
It happens every couple of hours, but it seems that the virtual machines running of other shares have no problems. So i am hoping its not a problems with the SOFS cluster.
Have you experienced this before? and is the non-CA option involved?
Same problem as Max's in my place. Any idea?
Hi Max and Mixer,
If the SOFS cluster is functional and only the FSW is hitting issues, then this is most likely due to inappropriately configured Permissions.
Which OS version was this configured on? How was the FSW configured (ex: FCM GUI or PowerShell)?
When using FCM GUI, the CNO is automatically given permissions on the share (assuming the logged in user has permissions on the share). However, this is not the case when configuring with PowerShell.
Try to give the CNO full permission on the Share & File System under the share. If configured with PowerShell attempt to reconfigure the FSW using FCM GUI.
I manually created the file share, gave domain admins full control (removed everyone from the file security). Created the File Share Witness and it failed.
The CNO had been assigned to the file permissions, but it had no rights. Gave the CNO object full control at the file level , re-ran the file share wizard and the witness was successfully created
We have 2 data centers . to setup the SOFS how storage needs to be clustered is it data center specific or non shared storage like always-on..
Hi Sri, The following technet article provides the information you are looking for: technet.microsoft.com/.../jj134181.aspx
Same issue as Max and MIXER. All nodes and CNO have full control over share and file system, so don't think it's a permissions configuration problem. Tried both FCM GUI and PowerShell.
All servers running 2012 R2 Datacenter with the December 2014 UR.
This is great and helped me out while I try and tune everything. I currently have it configured for Continuous Availability. I was going to configure another volume/share for this but I noticed I can just remove the "Continuous Availability" check mark (like 2a) which would save me time, but do you see it causing any issues with the currently configured cluster witnesses that are already configured on that CA share?
Hi John, This would not have an impact on the clusters currently using the share as a FSW.
We have a SOFS/Hyper-V cluster that's constantly flagging 1562 and 1062 on the Hyper-V side plus when we go to reboot one of the Hyper-V nodes we get a 1561 for the rebooted node "cluster service determined this node does not have the latest copy of cluster configuration data".
Permissions were verified and verified yet again for the FSW at all levels.
OS is 2012 R2 across both pairs of nodes.
Thanks Philip for reaching out. What you are observing is the “Partition In Time” scenario for quorum.
It seems that the timestamp updated in FSW is newer than the copy of the cluster database stored on the local node that you are starting.
Consider a scenario:
Node 1, Node 2 & FSW
a. Node 2 goes down (T1)
b. FSW & Node 1 stay up because they have quorum vote (T2 – timestamp updated with latest cluster membership)
a. FSW has T2 timestamp, Node 2 has T1 timestamp, Node 1 has T2 timestamp
c. Node 1 goes down (causing cluster to go down)
d. Admin tries to start Node 2 with FSW (assuming enough votes)
e. Node 2 recognizes that FSW has T2 which is later than T1 within its own copy of cluster database
f. Cluster service on Node 2 does not start because that would lead to the loss of any changes done on Node1 (when Node 2 was down)
Either try starting all the nodes in your Hyper-V cluster (there by including the node which has the latest copy of cluster database).
Or simply override quorum manually to recover from this situation by running:
On exactly one node:
Start-ClusterNode –Node <name> -ForceQuorum
On all the remaining nodes:
Start-ClusterNode –Node <name> -PreventQuorum