没有中央控制点的冗余？

Question

如果可以向多个客户端提供服务,如果提供此服务的服务器发生故障,另一个服务器就会占用它 - 没有某种集中的"控制",它会检测主服务器是否已关闭并将客户端重定向到新服务器？

是否可以不使用集中式接口/网关？

换句话说,它有点像问你可以设计一个节点平衡器而没有集中控制来指导客户端吗？

Answer 1

好吧,你没有提供有关你所询问的"服务"的更多信息,所以我将以通用的方式回答.

对于我的答案的第一部分,我假设您正在谈论涉及IP地址的"集中式接口/网关".为此,引用了来自wiki的CARP(通用地址冗余协议):

公共地址冗余协议或CARP是允许同一本地网络上的多个主机共享一组IP地址的协议.其主要目的是提供故障转移冗余,尤其是在与防火墙和路由器一起使用时.在某些配置中,CARP还可以提供负载平衡功能.它是思科HSRP的免费,非专利保护替代品.CARP主要在BSD操作系统中实现.

引用netbsd的" CARP简介 ":

CARP的工作原理是允许同一网段上的一组主机共享IP地址.该组主机称为"冗余组".为冗余组分配一个在组成员之间共享的IP地址.在组内,一个主机被指定为"主",其余主机被指定为"备份".主主机是当前"拥有"共享IP的主机; 它响应任何针对它的流量或ARP请求.每个主机一次可以属于多个冗余组.

这可能会解决您在网络级别的问题,让奴隶按顺序接管IP地址,而不会出现单点故障.

现在,对于答案的第二部分(应用程序级别),使用分布式erlang,您可以拥有几个节点(一个集群),它将为您提供容错和冗余(因此您不会在这里使用ip地址,但是"分布式erlang" " - 一组erlang节点 - 而不是.

启动分布式应用程序时会有很多节点,应用程序资源文件将包含可以运行应用程序的节点列表(已排序).

分布式erlang将控制哪些节点是"主节点",并且会在不同节点中自动启动和停止应用程序,因为它们会上下移动.

从http://www.erlang.org/doc/design_principles/distributed_applications.html引用(尽可能少):

在具有多个Erlang节点的分布式系统中,可能需要以分布式方式控制应用程序.如果正在运行某个应用程序的节点发生故障,则应在另一个节点上重新启动应用程序.

应用程序将在分布式配置参数指定的第一个节点上启动,该参数已启动并正在运行.该应用程序照常启动.

为了使应用程序控制的分发正常工作,分布式应用程序可以运行的节点必须相互联系并协商启动应用程序的位置.

启动时,节点将等待sync_nodes_mandatory和sync_nodes_optional指定的所有节点出现.当所有节点都出现时,或者当所有必需节点都出现并且sync_nodes_timeout指定的时间已经过去时,将启动所有应用程序.如果并非所有必需节点都已启动,则节点将终止.

如果正在运行应用程序的节点发生故障,则应用程序将在分布式配置参数指定的第一个节点上重新启动(在指定的超时之后),该参数已启动并正在运行.这称为故障转移

distributed = [{Application,[Timeout,] NodeDesc}]

如果根据分布式启动了具有比分布式应用程序当前正在运行的节点更高优先级的节点,则应用程序将在新节点处重新启动并在旧节点处停止.这被称为收购.

好的,这是一般概述,因为它可能是一个很长的话题:)

有关具体细节,强烈建议阅读" 分布式OTP应用程序"一章,了解learnyousomeerlang(当然还有以前的链接:http: //www.erlang.org/doc/design_principles/distributed_applications.html)

此外,您的"服务"可能依赖于其他外部系统(如数据库),因此您也应该考虑容错和冗余.整个架构需要容错,并以"服务"的方式分发,以此方式工作.

希望能帮助到你!

Answer 2

这个答案概述了网络应用程序的高可用性,而不是Erlang特有的.我不太了解OTP框架中的可用内容,因为我是该语言的新手.

这里有一些不同的问题:

1. 必须将客户端连接移动到备份计算机
2. 会话可能包含状态数据
3. 如何检测崩溃

问题1 - 移动客户端连接
这可以通过许多不同的方式和网络体系结构的不同层来解决.最简单的方法是将其编码到客户端,这样当连接丢失时,它会重新连接到另一台机器.

如果您需要网络透明性,您可以使用某种技术在不同计算机之间同步TCP状态,然后将所有流量重新路由到新计算机,这可能对客户端完全不可见.这比第一个建议要困难得多.

我相信这两者之间有很多事情要做.

问题2 - 状态数据
您显然需要将会话状态从崩溃的计算机转移到备份计算机.这很难以可靠的方式进行,并且您可能会丢失最后几个事务,因为崩溃的计算机可能无法在崩溃之前发送最后一个状态.您可以使用同步调用以这种方式是真的肯定没有失去状态:

1. 交易/消息从客户端进入主机.
2. 主机更新某些状态.
3. 新状态被发送到备份机器.
4. 备用机器确认新状态的到来.
5. 主机确认客户成功.

在某些情况下,这可能是昂贵的(或者至少不够响应),因为您甚至在向客户端确认任何内容之前依赖备份计算机及其连接,包括延迟.为了使其性能更好,您可以让客户端在连接时检查备份机器收到的事务,然后重新发送丢失的事务,使客户端负责排队工作.

问题3 - 检测崩溃
这是一个有趣的问题,因为崩溃并不总是很明确.什么事真的崩溃了？考虑一个关闭客户端和服务器之间连接的网络程序,但它们仍然处于启动状态并连接到网络.或者更糟糕的是,如果服务器没有注意到,客户端会与服务器断开连接.以下是一些需要考虑的问题:

• 客户端应该连接到备份机吗？
• 如果主服务器更新某些状态并将其发送到备份计算机,而备份与真实客户端连接,那么会有数据竞争吗？
• 主机和备份机可以同时启动,还是需要关闭其中一台机器并移动所有会话？
• 你在这个问题上需要某种权威,一些协议决定哪一个是主人,哪一个是奴隶？谁是那个权威？你如何分散它？
• 如果您的节点失去了它们之间的连接但两个都继续按预期工作(称为网络分区)怎么办？