什么'；在Erlang集群的所有节点上运行gen_服务器的最佳方式是什么？

我在建一个房子。在集群上运行时，它应该在所有节点上运行一组数据收集功能，并在单个“记录器”节点上使用RRD记录数据

当前版本在主节点（

rolf\u node\u sup

）上运行一个监控器，该监控器尝试在群集中的每个节点上运行第二个监控器（

rolf\u service\u sup

）。然后，每个节点上的监控器应启动并监控一组进程，这些进程将消息发送回主节点上的gen_服务器（

rolf_recorder

）

这只在本地有效。没有在任何远程节点上启动任何监控器。我使用尝试从记录器节点加载节点上的监控器：

rpc:call(Node, supervisor, start_child, [{global, rolf_node_sup}, [Services]])

我发现有几个人认为监管者实际上只为本地流程设计。例如

要实现我的要求，让有监督的代码在集群中的所有节点上运行，OTP最有效的方法是什么

• 建议使用分布式应用程序作为分布式管理器树的替代方案。这些不适合我的用例。它们提供节点之间的故障切换，但保持代码在一组节点上运行
• 这个模块很有趣。但是，它提供在当前加载最少的节点上运行作业，而不是在所有节点上运行作业
• 或者，我可以在主机上创建一组受监督的“代理”进程（每个节点一个），这些进程使用

  proc\u lib:spawn\u link

  在每个节点上启动一个主管。如果某个节点出现问题，代理进程应该死亡，然后由它的主管重新启动，而主管又应该重新启动远程进程。这个模块在这里可能非常有用
• 或者我把事情复杂化了。直接监视节点是一个坏主意，相反，也许我应该设计应用程序，以一种更松散耦合的方式收集数据。通过在多个节点上运行应用程序来构建集群，让其中一个成为主节点，就这样吧

一些要求：

• 该体系结构应该能够处理加入和离开池的节点，而无需手动干预
• 为了简单起见，我想构建一个单一的主解决方案，至少最初是这样
• 在我的实现中，我更愿意使用现有的OTP工具而不是手工编写的代码

---

有趣的挑战，有多种解决方案。以下是我的建议，希望能让您更好地选择如何编写程序

据我所知，您希望有一个主节点来启动应用程序。这将在集群中的节点上启动Erlang VM。

pool

模块使用

slave

模块来执行此操作，这需要在两个方向上进行基于密钥的ssh通信。它还要求您有正确的dns工作

从机的一个缺点是，如果主机死亡，从机也会死亡。这是经过设计的，因为它可能完全适合原始用例，但是在您的情况下，它可能会很愚蠢（例如，您可能仍然希望收集数据，即使主服务器已关闭）

对于OTP应用程序，每个节点可以运行相同的应用程序。在代码中，您可以使用配置或发现来确定集群中的节点角色

我建议使用一些操作系统工具或daemontools或类似工具启动ErlangVM。每个VM都将启动同一个应用程序，其中一个作为主应用程序启动，其余作为从应用程序启动。这样做的缺点是很难在集群中出现的机器上“自动”运行软件，就像您可以使用
slave
一样，但是它也更加健壮

在每个应用程序中，您都可以根据节点的角色拥有合适的监控树。删除节点间的监视和繁殖使系统更加简单

我还建议将所有节点推送到主节点。这样，主节点实际上不需要关心从节点中发生了什么，它甚至可以忽略节点已关闭的事实。这还允许添加新节点，而无需对主节点进行任何更改。cookie可以用作身份验证。多个主控器或“记录器”也相对容易

然而，“从”节点需要注意主节点的升降，并采取适当的措施，比如存储监控数据，以便在主节点备份后发送。
我将研究riak_core。它提供了一层基础设施，用于在erlang和otp本身的原始功能之上管理分布式应用程序。在riak_core下，无需将任何节点指定为主节点。在otp意义上，没有节点是中心节点，任何节点都可以接管其他故障节点。这就是容错的本质。此外，riak_core为加入和离开集群的节点提供了优雅的处理，而无需求助于主/从策略

虽然这种“拓扑”分散很方便，但分布式应用程序通常需要逻辑上特殊的节点。因此，riak_核心节点可以公布它们正在提供特定的集群服务，例如，如您的用例所体现的结果收集器节点

另一个有趣的特性/架构结果是riak_core提供了一种机制，通过“八卦”协议维护集群成员可见的全局状态

基本上，riak_core包含一系列有用的代码，用于开发高性能、可靠和灵活的分布式系统。你的申请听起来很复杂，有一个稳固的基金会会比以后更快地分红。
otoh，现在几乎还没有文档(

这里有一个家伙谈到了他用riak_core编写的AOL内部应用程序：


以下是有关钢筋模板的注释：