SERVER 2014 FCI群集需要太长时间才能进行故障转移

Question

我支持多实例，两个节点故障转移集群(活动-活动)。这两个实例都在WindowsServer2008R2上运行SQL 2014。每个节点都有3/4 TB的内存和32个核心(64与HT)。SQL为每个实例配置了最大内存350 is。每个实例有60到100个数据库，每个实例有3-5 TB的数据文件。

我想解决的故障转移时间有一些问题。该问题的中心似乎是在故障转移之前关闭SQL实例。当执行手动故障转移时，我们执行以下操作以加快速度。

1. 在故障转移之前检查所有数据库，以便在故障转移开始之前获得尽可能多的写入磁盘的脏页。在添加此步骤之前，故障发生的时间要长得多
2. 手动故障转移启动，SQL进入SA模式仅1-2分钟，然后SQL实例停止。
3. 在发生故障转移并在另一个节点上出现资源之前，再需要1-2分钟才能将内存释放回操作系统。

如果SQL实例在内存中只有有限的数据，则故障转移发生得更快。

我们查看了I/O和CPU度量，没有发现任何重大问题。

我正在寻找资源和想法，以帮助减少这一故障转移发生所需的时间。谢谢，-Luke。

Answer 1

当我们迁移到具有3TB内存的更大硬件时，我们在这里面临的问题变得更大了，故障时间超过10分钟。

我们用两种方法解决了这个问题.

1)间接检查点，这有助于SQL Server更快地关闭。

2)为SQL引擎帐户启用内存中的锁定页。这使得SQL能够更好地处理内存分配，同时可以释放内存并更快地占用内存。

失败时间从每次10+分钟增加到大约30秒。

Answer 2

该问题的中心似乎是在故障转移之前关闭SQL实例。

你是对的，因为这正是正在发生的事情。在一个节点上很好地关闭它，移动资源，并在另一个节点上启动它。这个问题实际上与集群无关，而是与加快SQL Server的干净关机有关。

当执行手动故障转移时，我们执行以下操作以加快速度。

当Server彻底关闭时，它会刷新所有缓冲区，并要求内部系统自行关闭。

那么，你如何使这个更快？首先，这是真正的情况，只有当你干净地关闭-这很可能不会发生在一个真正的失败。其次，不要让Server关闭--我将研究使用可用性组和测试手动故障转移时间来比较和对比这些差异。

此外，无论您使用什么，间接检查站都比传统更加有效。

Answer 3

检查数据库的VLF计数也有帮助。我也面临同样的问题，原因是VLF计数高，>15K。在减少vlf计数之后，它运行得非常快。