故障转移服务的挑战和最佳实践答案

【问题标题】：Challenges and Best Practices for Failing Over Services故障转移服务的挑战和最佳实践
【发布时间】：2009-11-20 08:46:41
【问题描述】：

是否有人知道运行 Windows 服务（在我的例子中是在 .NET 中开发的）的任何已建立的最佳实践，以便它们能够（自动）正确地故障转移到另一台服务器，以实现高可用性？

我可以看到完成此操作的主要方式是在需要时启动辅助服务器（在这种情况下需要有东西监控另一台服务器），或者让两个服务一起运行（在这种情况下它们需要同步他们的工作，所以他们不会尝试做同样的事情）。

这类问题有模式或模型吗？我知道确切的情况会产生很大的不同，但这似乎是一个相当普遍的问题。

谢谢

约翰

【问题讨论】：

感谢您的回答。抱歉，我应该指出我所指的服务更多的是后台处理服务——它不处理传入的网络连接。我感谢所有的建议！

标签： design-patterns windows-services high-availability

【解决方案1】：

这对我有用。

从基础架构的角度来看，您需要拥有 2 个集群的 Windows 服务器。（2个标准的Windows Server盒子就可以了，可以安装和配置集群部分，大多数系统管理员应该知道如何做到这一点。）接下来，在集群的两个节点上安装您的服务并将它们都关闭并设置为手动启动。接下来，为您的服务添加一个群集资源到 Windows 群集管理器，该资源将管理在任何活动节点上打开和关闭您的服务。让 Windows 集群管理您的服务何时运行以及在哪个节点上运行。这是集群服务的简单部分。

从服务的角度来看，您需要将服务设计为尽可能无状态。这是一种蹩脚的建议，但这实际上取决于您的服务在做什么。在设计中，只需假设在代码生命周期的某个时刻，它会在最糟糕的时间停止。节点 2 上的服务如何知道从节点 1 停止的地方提取？这是您需要设计的难点。根据您的服务正在做什么，您可以将最后完成的任务留在数据库表或共享数据文件中。您也可以让它从头开始，并在执行之前仔细检查该任务是否已完成。

同样，这实际上取决于服务需要完成什么。希望这会有所帮助。

【讨论】：

是的故障转移集群是正确的方法。您可以编写脚本以在部署期间配置集群组、资源和依赖项。这需要 Windows 服务器企业版，但不是标准版。
我对集群的想法很薄弱，所以你能解释一下“接下来，为你的服务添加一个集群资源到 Windows 集群管理器，它将管理在任何节点上打开和关闭你的服务活跃”。它是指一个单独的控制应用程序吗？如果是这样，它将安装在集群内的哪个位置？

【解决方案2】：

让两者一直运行可能是最简单的解决方案，但您需要确保负载永远不会超过 50%，否则当其中一个出现故障时，另一个会过载，甚至可能也会出现故障。

要进行同步，请使用事务数据库。尝试编写自己的同步通常会导致错误。

【讨论】：

【解决方案3】：

如果您可以同时使用这两种服务 - 那就更好了。您需要确保它们是无状态的或知道如何处理状态问题，并且数据库将在它们之间同步。在没有单点故障的情况下 - 您将问题推送到数据库，在那里您可以拥有一个 2 节点活动的活动集群，并让数据库制造商处理同步问题。

【讨论】：

【解决方案4】：

我相信处理故障转移的最佳方法是尽可能在网络级别。面向负载平衡或主要/故障转移环境的虚拟 IP 是避免为故障转移场景编写代码的好方法。

如果您必须在代码中处理故障转移：

测试连接/服务调用
如果测试失败，发送警报
故障转移到下一个“注册”服务端点

【讨论】：

网络与 Windows 服务有什么关系。可以有一个后台服务运行并完成它的工作，而不必有任何客户端连接到它。操作系统进行故障转移集群的正确方法。

【解决方案5】：

有两种基本方法。

客户端知道不同的端点地址，并根据需要或根据其他服务或配置机制的指示进行切换。（例如stocktrader demo application 就是这样做的。）
客户端不知道，您使用标准网络负载平衡方法也可以提供故障转移。 F5 是一种产品。还有很多其他的。它基本上就像服务的 NAT，所有请求都通过您的 NLB，并将它们发送到服务器，并将响应转发回调用者。这些产品监控服务并且只使用那些启动的服务。此外，您通常可以使用规则对其进行自定义，使其根据服务器工作负载将新请求分配给服务器。 Windows server has this 一定程度上内置了功能。

无论您采用哪种方式，如果您的服务调用是“无状态的”，就会容易得多。

【讨论】：