Windows 2012 R2群集 – networking适配器失败

最简单的方法是使用PowerShell脚本，在发生networking故障时将angular色迁移到健康节点。

通常情况下，如果networking适配器失败，则将事件login到Windows Server系统日志中。 只需创build一个Windows任务，它将运行PowerShell脚本并将其绑定到该特定事件。 您可以从脚本中重新检查界面状态，并决定是否移动angular色。

已经给出的答案确实是“手动”移动群集中的组的方法。

但是要回答这个问题：

networking故障时是否可以实现故障切换？

是的，这是可能的，但让我解释故障转移群集的一个方面。

故障转移群集有许多“故障检测方法”，其中之一是由群集的RHS.exe（资源主机子系统）执行的所谓的IsAlive / LooksAlive方法实现的。

基本上（除非默认值已被更改），RHS每5秒钟对每个资源调用一次“LooksAlive”。 这是一个“小”testing，以确定资源“看起来还活着”。

如果这个“LooksAlive”testing失败：它将对资源执行“IsAlive”testing。 这将是一个更“彻底”的testing，最终确定资源是否运作。

RHS也每30秒运行一次“IsAlive”，而不pipe“LooksAlive”是成功还是失败。

如果“IsAlive”失败，那么[cluster]会将“事件1069”发送到系统事件日志，指示资源已经失败。

发生故障后故障转移群集将决定如何处理失败的资源。 它将基于以下几个因素：

• 什么是资源的重新启动阈值：它可能会也可能不会尝试重新启动资源，看看它是否联机（没有故障转移）
• 如果它已经用尽重启阈值：它将确定资源故障是否应该影响“组”（默认情况下）
• 如果阈值确实用尽，并且资源影响组，则[集群]将做出故障切换决定（如果可用，组移动到另一个节点）

我会把它留在那里，还有很多其他的function领域我们应该讨论，以便充分理解集群的决定

因此，为了“testing”一个“自动故障转移”，我们需要了解这个“IsAlive / LooksAlive”testing实际上在做什么。

我们需要确保集群应用程序组中至less有一个“IP地址”资源，以确保集群正在检查这个资源，以捕获networking故障。

如果您正在运行“通用服务”，那么您的组应如下所示：

Application-Group - Generic Service |- Physical disk (only if your app needs it) |- Network Name |- IP address 

“拾取”networking故障的“IsAlive / LooksAlive”，在“IP地址”中，定义在这里可以看到 – >这篇文章是针对Windows 2003编写的，但其内容大体上还是真实的，甚至还引用了微软故障转移集群小组成员撰写的关于故障转移群集的优秀文章 。

由此，我们知道“IsAlive”在“IP地址”资源方面与“LooksAlive”相同。 它基本上检查IP地址是否绑定到操作系统的TCP / IP堆栈中相应的NIC。 （你可以看到你是否运行ipconfig ）

为了testing这样的故障转移，你有两个select：

• 在故障转移群集pipe理器中，右键单击您的应用程序组中的IP地址资源，然后select“模拟失败”。 您可能必须这样做两次，因为集群将在做出故障切换决策之前尝试重新启动资源（如上所述）。
• （就像你所做的那样）在OS中禁用NIC。 只要确定它实际上是在禁用之前实际绑定了IP地址（包含您的通用服务的实际组的“IP地址资源”）的NIC。 您可以通过在命令行上运行ipconfig来检查。 （群集将尝试重新启动，但重新启动将失败，因为NIC被禁用）
• 拉出物理网卡的线缆。 只要确定它实际上是在拉电缆之前实际绑定了IP地址（包含您的通用服务的实际组的“IP地址资源”）的NIC。 您可以通过在命令行上运行ipconfig来检查。 （群集将尝试重新启动，但重新启动将失败，因为NIC电缆被拉出）

如果拥有合适的应用程序组，并且具有适当的依赖关系，则可以使用IP地址来成功testing故障转移。

我希望这可以解释你的情况。