我最近设置的文件共享存储配置出现了一些问题。我们最近将视频流服务转移到了 NAS(1x24TB)。我们设置了 9 个前端服务器,它们将使用 NFS 与 NAS 通信,但遇到了问题。由于对文件的请求太多,而只有“1 个物理”驱动器,NAS 服务器无法跟上所有请求,导致我们出现 IO 问题。
无论如何,我们决定要更改为不同的配置,因为 NAS 设置对我们来说效果不佳。我猜它不适合数百个随机文件下载。
正在寻找替代解决方案。我们考虑过设置两个 4 服务器集群并在每个集群上使用 gluster,但我认为这不是最佳解决方案。我们还考虑过在 8 服务器集群上设置 mogilefs,但是我们需要使用 nginx 来提供文件服务器,而这无法通过 mogilefs 实现。
有人能推荐一些可以提供冗余和可扩展性的更大规模文件共享服务吗?我不是专家,这是我第一次尝试配置这么大的东西。
答案1
另一个值得考虑的配置是让 9 个 nginx 服务器使用 proxy_cache 设置在提供文件时保留文件的副本,这样对同一文件的第二次请求将从服务器的本地磁盘提供。您可以将此缓存设置为有限的大小,并在有限的时间内存储文件。这将减少 NFS 服务器上的负载,并且不需要您将数据复制到每个节点。
一旦文件到本地,您还可以使用操作系统的 sendfile 功能,该功能允许内核接管将数据发送到套接字,而不是让 nginx 执行此操作,这大大提高了性能,但不建议通过 NFS 进行。
答案2
答案3
您的问题的标题与您所要求的内容关系不大。
使用共享文件系统,您将遇到可扩展性问题 - 您可以通过使用 SAN(即使只是 10Gb iSCSI)来推迟此问题出现的时间点,但对于您的应用程序,其中写入操作很少并且(大概)更新只需要接近实时而不是原子,我建议使用分布式对等或复制文件系统。
据我所知,有选择有限用于 ptp 文件系统的现成解决方案 - 但在您的应用程序中实现这一点并不困难。
复制文件系统是一项更为成熟的技术 - AFS 如今已成为 Linux 的标准。
答案4
告诉我你是否能得到你的网格文件系统MongoDB 处于“磁盘已满”或“资源不足”状态。