我们正在为我们的Web环境构build一个新的SQL 2012集群。 我们决定使用两个节点，并利用AlwaysOn高可用性可用性组。 Server01和Server02已经安装了SQL的独立实例，并且都已经join到Cluster01中。 可用性组已创build。 Server01和Server02是可用性组中的节点，并configuration为同步提交副本。
不过，我注意到有一天，Server01需要重新启动进行修补，导致整个群集。 在Server02上打开Windows故障转移群集pipe理MMC时，我发现群集已closures，并且需要在Server02上重新启动服务（不确定这是否与我们最终想实现的目的相关）。 我在Server02上打开SQL Management Studio，可用性组显示“正在parsing”状态（不表示Server02已成为主节点）。 如果我在SSMS中展开“数据库”部分，则会显示处于“恢复挂起”状态的数据库。 如果我尝试扩展其中一个数据库（不是系统数据库，即master，model等），我得到以下错误：
错误：
数据库SiteAdmin不可访问。 （ObjectExplorer）
当我展开SSMS中的可用性组，然后展开副本时，我只能看到列出的Server02。 在Server01恢复之后，我在服务器上本地打开Windows故障转移群集pipe理。 Server01显示它正试图连接到群集。 但是，Server02显示群集仍然closures。 尽pipe我仍然需要在两个节点上手动启动群集服务。 在我这样做后，可用性组回到联机，显示Server02仍然是次要节点。
看到这个之后，我检查了Cluster01的当前Quorum设置。 目前它被设置为节点多数，它指示我们有两个节点configuration，它不能承受甚至一个节点的丢失。 我相信，如果我们站在第三台服务器上，而另一个独立的SQL实例可以工作在多数节点上。 但是我们没有资源。 基于这些设置，我认为我们需要更改群集的仲裁设置，但不确定AlwaysOn是否支持使用磁盘或文件共享见证来实现自动故障转移。
你可以使用磁盘或文件共享，它会工作得很好。 第三台机器（甚至是虚拟机）也能正常工作。