我正在testing我们testing系统的韧性。 我们在故障转移群集中安排了2 x DB（Server 2008 R2上的SQL 2008 R2，运行在ESXi VM中）。
closuresActive SQL Server服务没有太多的工作 – 服务没有重新启动，也没有发生故障切换; 我站在这是devise – 系统假定pipe理员有充分的理由closures服务，所以会静静地坐着。
但是，我们可以通过多种方式来模拟失败 – 我发现最简单的就是在任务pipe理器中杀死SQL服务。 我们的集群设置为在6小时内允许一次故障，所以在第一次故障之后，它会尝试重新启动服务 – 成功。 再次终止服务（6小时内），集群pipe理器将决定将数据库交给被动服务器。 到现在为止还挺好…
如果将终止第二台服务器上的服务，它将重新启动。 但是当我们再次终止服务时，它不会故障回复到第一台服务器。
我假设这也是devise; 这是有道理的，因为为什么还没有恢复到只有几分钟前本身还不够稳定的服务器呢？ 这听起来合乎逻辑，但这是真的吗？ 如果是，服从相同的超时时间（即6小时），是否可以重置？
基本上，在我告诉同事故障转移function正在运行之前，我只想确认/澄清我的理解和假设。
其他一些你可以testing的东西：
尝试closures盒子（甚至closures电源，以获得更好的模拟）。 还要拔掉网线并禁用服务器之间的连接。
（虽然承认，它通常是似乎导致故障转移的软件）
设置重启策略：
打开群集pipe理员。
在控制台树中，单击资源文件夹。
在详细信息窗格中，单击所需的资源。
在文件菜单上，单击属性。
在高级选项卡上，进行所需的更改。
似乎您想要查看以下设置：资源的超时，故障转移阈值和故障转移期限。 超时控制群集服务等待资源closures的时间。 故障转移阈值和时间段控制群集服务在特定时间段内尝试故障转移资源的次数。