Windows服务 - 高可用性方案和设计方法

时间:2010-04-07 12:14:57

标签: windows-services high-availability design-decisions failovercluster

假设我有一个在Windows服务器机器上运行的独立Windows服务。如何确保它具有高可用性?

1)。你可以提出的所有设计水平指南是什么?

2)。如何使其高度可用,如主要/次要,例如,市场上现有的集群解决方案

3)。如何在任何故障转移情况下处理横切关注

如果您能想到其他任何其他请在此处添加..

注意: 问题只与Windows和Windows服务有关,请尝试遵守此规则:)

3 个答案:

答案 0 :(得分:5)

要使服务至少保持运行,您可以安排Windows Service Manager在服务崩溃时自动重新启动服务(请参阅服务属性上的“恢复”选项卡。)此处提供了更多详细信息,包括用于设置这些服务的批处理脚本属性 - Restart a windows service if it crashes

高可用性不仅仅是从外部保持服务 - 服务本身需要以高可用性为基础构建(即使用良好的编程实践,适当的数据结构,配对资源获取和发布),以及经过整体压力测试,以确保它能够保持在预期负载下。

对于幂等命令,可以通过重新调用命令一定次数来实现容忍间歇性故障(例如锁定的资源)。这允许服务屏蔽客户端以防止故障(直到某一点。)客户端也应编码以预测故障。客户端可以通过多种方式处理服务故障 - 记录,提示用户,重试X次,记录致命错误和退出都是可能的处理程序 - 哪一个适合您,取决于您的要求。如果服务具有“会话状态”,当服务失败时(即重新启动进程),客户端应该知道并处理这种情况,因为它通常意味着当前的会话状态已经丢失。

单台机器容易受到硬件故障的影响,因此如果您打算使用单台机器,请确保它具有冗余组件。 HDD特别容易出现故障,因此至少具有镜像驱动器或RAID阵列。 PSU是下一个弱点,因此冗余PSU也是值得的,就像UPS一样。

对于群集,Windows支持服务群集,并使用网络名称而不是单个计算机名称来管理服务。这允许您的客户端连接到运行该服务的任何计算机,而不是硬编码的名称。但除非您采取其他措施,否则这是资源故障转移 - 将请求从一个服务实例引导到另一个实例。 Converstaion状态通常会丢失。如果您的服务正在写入数据库,那么也应该对其进行集群以确保可靠性,并确保整个集群(而不仅仅是本地节点)可以进行更改。

这真的只是冰山一角,但我希望它能为你提供进一步研究的想法。

Microsoft Clustering Service (MSCS)

答案 1 :(得分:0)

如果你打破了你想要解决的问题,我想你自己可能会想出几个答案。正如贾斯汀在评论中提到的,没有一个答案。这完全取决于您的服务以及客户如何使用它。您也没有指定有关客户端 - 服务器交互性的任何详细信息。 HTTP? TCP? UDP?其他

以下是一些可以帮助您入门的事情。

1)如果服务或服务器出现故障,您会怎么做?

  • 如何在不同的服务器上运行多个服务实例?

2)好的,但现在客户如何了解多种服务?

  • 您可以将列表硬编码到每个客户端(不推荐)
  • 您可以使用DNS循环法在所有这些请求中退回请求。
  • 您可以使用负载平衡设备。
  • 您可以拥有一个了解所有其他服务的单独服务,并可以将客户端引导至可用服务。

3)那么如果一项服务出现故障怎么办?

  • 客户端应用程序是否知道如果他们连接的服务出现故障该怎么办?如果没有,那么他们需要更新以处理这种情况。

这应该让您开始了解如何开始使用高可用性的基本概念。如果您提供有关架构的具体详细信息,则可能会得到更好的响应。

答案 2 :(得分:0)

如果服务没有公开客户端连接的任何接口,您可以:

  • 广播或公开“我还活着”的消息或发信号通知数据库/注册表/ tcp /无论你还活着

  • 有第二个服务(监视器)检查这些“我还活着”的信号并尝试重新启动该服务以防万一

但是如果你有一个客户端通过namedpipes / tcp / etc连接到这个服务,客户端必须检查服务器在数据库中运行的机器的地址,或者像智能交换机那样更好地重定向流量