传入文件的循环

Question

一堆具有唯一文件名的新文件定期在一台服务器上“出现” ¹。（就像每天数百 GB 的新数据一样，解决方案应该可扩展到 TB。每个文件都有几兆字节大，最多几十兆字节。）

有几台机器可以处理这些文件。（十个，解决方案应该可以扩展到数百个。）应该可以轻松添加和删​​除新机器。

有备份文件存储服务器，必须在其上复制每个传入文件以进行存档存储。数据不能丢失，所有传入的文件必须最终交付到备份存储服务器上。

每个传入的文件都被传送到单个机器进行处理，并且应该复制到备份存储服务器。

接收服务器在发送文件后不需要存储文件。

请建议一个强大的解决方案，以上述方式分发文件。解决方案不得基于 Java。Unix 方式的解决方案是可取的。

服务器基于 Ubuntu，位于同一个数据中心。所有其他事情都可以根据解决方案要求进行调整。

---

¹请注意，我有意省略了有关文件传输到文件系统的方式的信息。原因是第三方现在通过几种不同的传统方式发送文件（奇怪的是，通过 scp 和 ØMQ）。在文件系统级别削减跨集群接口似乎更容易，但如果一个或另一个解决方案实际上需要一些特定的传输 - 传统传输可以升级到那个。

Answer 1

这是您正在寻找的一种解决方案。这个系统的制作不涉及 Java，只是现成的开源位。此处介绍的模型可以与我用作示例的技术之外的其他技术一起使用。

1. 文件通过 HTTP POST 发送到特定的循环 DNS 地址。
2. 系统 POST 文件然后通过另一对负载平衡器将作业放入 AMQP 系统（此处为 Rabbit MQ）中，以启动处理工作流。
3. 接收 HTTP POST 的负载均衡器每个都位于一组 OpenStack Swift 对象存储服务器之前。
   • 每个负载平衡器背后都有两个或多个 OpenStack Swift 对象存储服务器。
   • 如果目标是 HA 本身，则可以是“循环不是 HA”。天啊。
   • 为了获得额外的持久性，RRDNS 中的 IP 可以是单独的热备份 LB 集群。
4. 实际获取 POST 的对象存储服务器将文件传送到基于 Gluster 的文件系统。
   • Gluster 系统应该是分布式（又名分片）和复制的。这允许它扩展到愚蠢的密度。
5. AMQP 系统将第一个作业（进行备份）分派到可用的处理节点。
6. 处理节点将文件从主存储复制到备份存储，并根据需要报告成功/失败。
   • 故障模式处理在此未作图解。本质上，继续尝试直到它起作用。如果它永远不起作用，请运行异常过程。
7. 备份完成后，AMQP 会将处理作业分派到可用的处理节点。
8. 处理节点要么将文件拉到其本地文件系统，要么直接从 Gluster 处理它。
9. 处理节点将处理产品存放到任何地方，并向 AMQP 报告成功。

如果有足够的服务器，此设置应该能够以极高的速度摄取文件。如果您足够大，获得 10GbE 聚合摄取速度应该是可行的。当然，快速处理如此多的数据将需要您的处理机器类中的更多服务器。这个设置应该扩展到一千个节点，甚至可能更多（尽管多远取决于你用所有这些做什么）。

深层次的工程挑战将隐藏在 AMQP 流程中的工作流管理流程中。这就是所有软件，并且可能是根据您的系统需求定制的。但它应该有很好的数据！

Answer 2

鉴于您已经澄清文件将通过 scp 到达，我认为前端服务器根本没有任何存在的理由，因为传输机制是可以在第 3 层重定向的。

我将一个 LVS 控制器（对）放在前面，后面有一个处理服务器池和一个循环重定向策略。这使得在池中添加和删除服务器变得非常容易，它提高了可靠性，因为没有前端服务器会崩溃，这意味着我们不必解决有关从中获取文件的拉/推问题前端到处理服务器，因为没有前端。

每个池服务器在接收文件时应该做两件事 - 首先，将其复制到存档存储，然后处理该文件并继续发送。