故障服务的挑战和最佳实践

Question

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

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

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

由于

约翰

Answer 1

这对我有用。

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

从服务的角度来看，您需要设计自己的服务，使其尽可能无状态。这是一种蹩脚的建议，但它实际上取决于您的服务在做什么。在设计中，假设在代码生命周期的某个时刻，它将在最糟糕的时间停止。 node2上的服务如何知道node1在哪里取消？这是你需要设计的难点。根据服务的作用，您可以将最后完成的任务保留在db表或共享数据文件中。您也可以从头开始并在采取行动之前仔细检查该任务是否已完成。

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

Answer 2

让两者一直运行可能是最简单的解决方案，但是你需要确保你永远不会超过50％的负载，否则当一个失败时，另一个将变得过载并且也可能失败。

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

Answer 3

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

Answer 4

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

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

1. 测试连接/服务电话
2. 如果测试失败，请发送提醒
3. 故障转移到下一个“已注册”服务端点

Answer 5

有两种基本方法。

1. 客户端知道不同的端点地址，并根据需要或其他服务或配置机制的指示进行切换。 （例如stocktrader demo application执行此操作。）

2. 客户端不知道，您使用标准网络负载平衡方法，该方法也可以提供故障转移。 F5是一款产品。还有很多其他的。它基本上就像服务的NAT一样，所有请求都通过你的NLB并且它们将它们发送到服务器，然后将响应转发回调用者。这些产品监控服务并仅使用那些服务。此外，您通常可以使用规则对其进行自定义，以使其根据服务器工作负载为服务器分配新请求。在某种程度上内置Windows server has this功能。

无论你采用哪种方式，如果你的服务电话是“无国籍的”，那就容易多了。