2011-02-05 110 views
1

我想开发一个应用程序,它连接到一些输入源并处理它读取的消息(原则上认为是BizTalk,但不是那么重)。为了提高性能和可靠性,我希望启用服务的水平扩展,显然通过使用共享存储(如DB)充当消息排队机制。用于主动/被动故障转移群集的.NET库

但是,访问诸如电子邮件或磁盘文件夹等资源的线程无法水平缩放。一次只能从该输入源读取一个实例。 (进一步的消息处理业务逻辑当然可以驻留在多个节点上)。

这是主动/被动群集的完美人选。一个节点被认为是“活动的”并且主动连接到“单实例”资源(例如电子邮件收件箱),而其他节点则是“被动”。如果“活动”节点死亡,则其他“被动”节点在它们之间选择新的“活动”节点。

现在的问题是:在那里有一个.NET库,它可以帮助实现通常的故障转移群集逻辑? (即实施必要的心跳发送/检测,以及“主动”节点选举过程)。因为我不想重新发明轮子。

我可以从已经完成的研究看:

  • 的BizTalk Server支持此功能本身,但我不使用BizTalk因为它太笨重和昂贵的(但我想效仿它的这个功能)
  • Windows Server支持故障转移群集(在某些高端版本,如Windows Server 2008 Enterprise或Datacenter中),但这又是一个昂贵的解决方案(因为每个节点都需要昂贵的许可证)
  • 有很多信息关于故障转移算法应该如何工作,但我看不到开源在任何地方实施...(只在商业产品溢价销售)

我知道它可能被认为是先进和理想的功能,因此为什么商业解决方案是昂贵的。这很好 - 如果没有开源实现或库,那么我将自行开发一个。我只是不想花费它已经存在的努力。

UPDATE 12/02/2011:找到SAForum(http://www.saforum.org/link/linkshow.asp?link_id=214720),这是一个发布开放式服务可用性概念规范的网站。还有OpenSAF(http://www.opensaf.org/Welcome-to-OpenSAF%E2%84%A2~151213~14944.htm)以及SAForum规范的开源C++实现。看起来很全面,但非常重。要花费我很多时间来阅读规范和文档。它不仅涵盖了故障转移,还提供了完全可扩展的分布式系统(通知,分布式事件,锁定,集群管理等)的规范......仍然没有任何.NET实现的迹象。

+0

在发生故障时您能容忍多少停机时间?一旦您摆脱真正的高可用性解决方案,许可成本就会急剧下降。自己开发它的开发工作也是如此。 – saille 2011-02-13 00:10:05

+0

假设即使是15到20分钟也是可以忍受的(因为这意味着工作排队)。我只想** **自动**故障切换,以便人类不必介入。你知道哪些图书馆/解决方案? – Lev 2011-02-14 23:08:14

回答

2

当然,开发这种先进的功能自己将比商业购买更昂贵。除非你的时间被捐赠给项目,并且你没有截止日期,否则我会排除你自己写这个。

要获得高可用性和水平缩放,您需要编写一个的代码。测试它在高可用性生产环境中的工作水平将需要相当大的努力。即使你这样做了,你会不会相信你自己的代码,而不是微软的代码,它已经在游戏中累积了运行时间,并且已经通过了所有软件都需要经过的多个版本才能变得成熟和稳定。

我知道你真的在问开放源代码库,但同样的观点适用 - 你会相信吗?它是否经过了充分测试?是否经过实地验证?

更新:好吧,这是几年前,我想我已经软化了我对使用开源这种关键任务基础设施的可行性的立场,尽管我仍然相信有商业支持是必不可少的,并且我仍然避免自己写。

作为高可用性,高扩展性的消息总线,我会在这里插入一个Rabbit MQ的插件,以便其他读者阅读。商业支持是可用的,其基于开放标准(AMQP)。客户端库可用于任何主要平台。

相关问题