我的三节点 SQL Server 2008 R2 物理服务器集群需要关闭，连同其存储一起移动到新位置，并在新位置重新启动一次。我的愿望是拥有一个干净、可控的关闭/启动序列，并且如果可能的话，在此过程中所有 SQL Server 实例都保留在其原始节点上。因此，如果SQLInstA打开NodeA、SQLInstB打开NodeB且NodeC为空，则在服务器关闭期间没有故障转移，我将在启动时单独启动服务。
我已经阅读了有关将 SQL Server 设置为离线、暂停节点、停止群集服务、将启动类型设置为手动的各种建议。
我首先想到的是设置SQLInstA和SQLInstB服务脱机故障转移群集管理器。离线不会触发故障转移，因此它们会保持原状。但是，无论我将它们设置为只有一个首选所有者，重新启动都会导致故障转移。即使我没有“禁用自动启动”，服务也不会重新启动，因此即使两个实例都在同一个节点上结束，服务也会在启动时关闭，这并不可怕。之后只需手动故障转移工作。
我可以停止集群服务，但这也会触发故障转移。在这种情况下停止集群服务重要吗？
关于如何实现这一点的任何想法？
许多数据库在没有见证人的情况下以高安全模式镜像。我试图了解在主服务器保持正常运行且所有其他镜像数据库处于正常同步状态时数据库（或多个数据库）遇到假故障的情况下可能会发生什么。
假故障 DB 的镜像状态是否会变为 DISCONNECTED，但是，因为服务器没有发生故障，主数据库上的 DB 仍然能够接受连接并执行事务，尽管它会在不受保护的情况下运行？或者，主数据库上的数据库是否会断开连接且不可用？而且，这将是什么恢复？它最有可能是一个简单的 ALTER DATABASE SET PARTNER RESUME 吗？
以前，我们将这些 DB 置于具有见证（自动故障转移）的高安全模式下，并将超时时间增加到 20 秒以消除假故障，这在一年半的时间里运行良好。但是，本周，由于未知原因，我们进行了一次数据库故障转移。我已将超时时间增加到 30 秒，但我们也在考虑删除见证，因为无论如何在故障转移的情况下应用程序都需要手动干预，因此我们也可以手动进行数据库故障转移。我可以处理计划好的故障转移，但我对我描述的情况不太满意。