Recently I was working on a clients file server cluster and while doing some troubleshooting with Microsoft Support one of 
the clustered disks wouldn’t respond correctly. Now this file server cluster is setup in Azure so it is using SIOS Data Keeper to replicate the data between the nodes of the cluster.
The state that the cluster was in looked something like this.
In this configuration the cluster has two nodes FILESERVER01a and FILESERVER01b. The cluster is named FILESERVER01 and the name that users access files through is FILESERVER01V01. The top three drives were working exactly as expected, but the last one wasn’t working at all. Nothing could talk to it, nothing could manage it.
Thanks to Dave Bermingham (Clustering MVP, SIOS Employee and all around good guy) we found a forum thread that talked about this same problem and that the root cause was that the pool was registered as a cluster object within Failover Cluster manager.
Once I went into the failover cluster admin and remove the failed object for that pool I could attach the virtual disk again. Then I just needed to configure the disks to automatically attach on reboot. That’s easy enough to fix with a little PowerShell.
get-virtualdisk {DiskName} | set-VirtualDisk -IsManualAttach $False
Then into computer management to bring the disk online (or reboot, but this is easier). Then resetup the SIOS software to replicate and away the data went.
Thankfully it’s fixed, and I can get back to the problem at hand of figuring out the EFS problem on the cluster.
Denny
The post Fixing a storage pool that doesn’t have an read-write server appeared first on SQL Server with Mr. Denny.