我目前有一个系统设置，客户端通过 FTP 将文件发送给我，这会触发 inotify（通过 Linux 内核通知）来触发解析以对这些文件采取行动。我遇到的问题是解析器当前正在达到一个 EC2 实例上的 I/O 容量，我想添加其他节点来分担文件负载。不幸的是，客户端只能通过 FTP 上传。这让我想知道如何让另一个不共享文件所在的 EBS 卷的实例处理该文件。
目前是否有一个 AWS 解决方案可以让我使用 FTP 的客户端不受影响（除了 IP 更改，这没问题）并允许我让多个 EC2 实例访问文件系统？
答案1
当然...
您可以对任意类型的多个卷进行附加和条带化，以提高 Amazon EC2 应用程序可用的 I/O 性能。
这是我曾经使用过的东西，EBS 卷的 RAID-10，但是...但是我想你已经想到了那个。
我考虑建议使用类似以下方法扩展你的 FTP 服务器HAProxy和/或redir与 Ubuntu 捆绑的实用程序（可以重写 FTP 数据包以修复该协议中固有的一些荒谬之处）但 FTP 尴尬的多连接性质可能使这成为一个复杂的命题，而且它可能不是您真正想要的。
那么，s3fs 怎么样？
在我提出这个建议之前，我在谷歌上搜索了一下，找到了类似的东西这个帖子，这表明它可能不起作用，但后来我意识到，在这种情况下，OP似乎对S3和文件系统的实际工作方式缺乏了解，并期望inotify能够意识到事情已经通过外部原因在S3中远程发生变化（没有遍历本地文件系统），这当然是没有意义的。
但我编写了一些代码来测试它，s3fs 确实似乎可以与 inotify 正确交互。您可以从 FTP 服务器安装存储桶而不是 EBS 卷，这样当您的客户端通过 FTP 上传文件时，它们会直接放入存储桶中 - 并且 inotify 会像传统文件系统一样捕获该事件，此时您可以使用 SQS 或任何其他机制来提醒工作机器有作业要完成。然后，它们可以独立获取和处理文件，I/O 仅受每台机器和 S3 基础设施之间的可用带宽限制。
s3fs 在许多情况下完全不适合，例如，服务器一遍又一遍地提供相同的静态内容 —— s3fs 不是一个好的解决方案，因为可能会出现大量冗余请求和/或需要 s3fs 在本地缓存内容（它可以，但没有意义 —— 如果你需要这样，那么你只需将文件存储在本地），并且在尝试提供响应式网站时按需单独获取它们所涉及的延迟可能会有问题……但是当每个文件都不是经过一次又一次的访问，我得到了积极的结果。
我最近为一个客户做了一个小项目，他们想将可公开下载的资产存储在 S3 中，但他们可能也遇到了和你类似的限制——他们真的希望能够使用 FTP 上传文件。将 proftpd 与通过 s3fs 安装到 EC2 实例的存储桶相结合，为他们提供了一个简单的 S3“网关”，并且与现有系统兼容...所以我知道它确实有效，而且我刚刚用 inotify 测试了相同的设置，我可以告诉你，这两者似乎具有预期的交互。
像这样在 EC2 内部使用 S3，存储价格基本上相当于 EBS，如果存储桶与您的端点位于同一区域，您无需支付带宽费用——您只需为每个请求PUT（每百万请求 5 美元）和GET（每百万请求 4 美元）付费（我对定价表的解释；我在 S3 中存储了数百万个对象，从未遇到过账单意外，但不要相信我的话）。文件和请求之间的对应关系可能不是精确的 1：1，因为 s3fs 必须做一些后台工作来将文件模式和所有权存储在 S3 中作为其伪文件系统模拟的一部分，并且必须迭代对象以生成目录列表，因此对请求的依赖程度可能不同……但这似乎是一个可行的解决方案。
只要您正确理解 S3 和传统文件系统之间的阻抗不匹配，我就会明白为什么它不能按照您的需要无限地扩展您。
当然，我最喜欢 s3fs 的一点是它永远不会用完空间。:)
Filesystem Size Used Avail Use% Mounted on
s3fs 256T 0 256T 0% /var/xxxxxxxxxxx
答案2
如果您的客户端能够通过 DNS 而不是 IP 访问您的 ftp，那么最简单的解决方案可能是将 ELB 放在几个 ftp 实例前面，以便您可以水平扩展。
然后，如果您需要在处理完成后将所有通过 ftp 传输的文件集中在一个地方，则可以使用 S3 或任意数量的解决方案将处理后的文件持久地存储在一个位置。
答案3
当 inotify 发现有新文件正在通过 ftp 传输到你的头节点时，你不能有一个脚本来将这些文件 scp 到另一个节点吗？