我正在尝试为正在进行的项目设计一个基础设施。它将是一个文件共享/下载项目（如 rapidshare），我需要高存储容量和良好的可扩展性，并且我会在项目发展壮大后添加新的存储节点。
我为我的项目想出了 3 个解决方案，分别是使用 Luster、GlusterFS、HDFS 和 RDBD。
首先，我会有 2 台服务器，一台用于 glusterfs 客户端 + web 服务器 + db 服务器 + 流媒体服务器，另一台服务器是 gluster 存储节点。（一段时间后，我会添加更多节点服务器和客户端服务器（不知道要添加多少新客户端新服务器，稍后再看）
所以，我正在考虑使用 glusterfs。但我真的想知道我是否必须使用具有高存储容量的高性能服务器或具有高存储容量的普通/慢速服务器？或者 nas/das/san 解决方案更适合 glusterfs 存储节点？我可能会购买 nas 并在其上安装 glusterfs。我很乐意听取您对服务器属性（针对每个客户端和节点）的建议。我真的不知道我是否真的需要大量 RAM 和良好的 CPU 来用于节点。我确信我需要它用于客户端服务器。
文件也会被流式传输，因此自动文件复制非常重要，因此，我的系统应该像云一样工作，在需要时，根据高流量，存储节点应该复制最需要流式传输的文件，并帮助我摆脱可扩展性问题，我的访问者将能够流式传输/下载这些文件。
此外，我愿意听取您对任何好的解决方案的经验/想法。Luster、hdfs、rbdb 是其他选项，我很乐意在这里听听您的想法。我非常非常高兴听到任何人对我在这里使用的任何词语发表评论。
谢谢
编辑：
我知道 IOPS 是我在网络设计中每次计算都必须考虑的关键变量，这就是我说随机请求的原因。但不幸的是，我根本没有任何统计数据。这就是我在这里的原因 :)
我的项目是这样的，你输入一个下载网址到我的网站，我的网址下载，然后你从我自己的服务器开始下载，就像一个代理下载器一样。
所以我现在有一个 100mbit 连接的服务器和 2TB 硬盘。我正在考虑添加 nas 服务器。真的不知道我是否必须在 nas 中添加重复的存储节点。我可以连接 nas 设备的数量是否有限制？我的意思是我最多可以将 2 个 nas 服务器连接到我的主要服务器？
答案1
您的问题并不简单，而且没有足够的信息来给出好的答案。我可以给出一个答案（基于光纤通道 SAN 的集群文件系统）——但它可能会比它需要的更昂贵和更复杂。
所以我只想抛出一些评论/想法。这确实值得你考虑。也许在阅读完这些想法后，你将能够重新陈述你的应用的预期行为，然后我们也许可以给你一个更好的答案。
NAS 设备导出文件系统（例如 CIFS、NFS），因此您实际上并没有将它们连接到您的服务器 - 您的服务器从它们安装文件系统。这意味着对它们的读取和写入需要通过您的连接。因此，如果您的 NAS 和服务器之间有 100mbit 的网络连接，并且您的读取/写入以 1:1 的比例发生，那么您将获得的最佳读取速度是 50mbit，因为对于您读取的每个字节，您也会写入一个字节。如果您的客户端和下载流量在同一个网络上，那么您可以再次将其减半。显然，如果您想使用 NAS，那么您将需要在您的服务器中使用多个 NIC，并在您的架构中使用多个网络/VLAN。
假设您的应用中有 4 个可能的数据位置。
- A) 原始数据源，例如互联网。
- B) 您的服务器。
- C）NAS。
- D）客户端列表项
那么有 4 个可能的数据向量
- AB，即数据从A（网络）下载到B（您的服务器）。
- BC，即将数据从您的服务器写入 NAS。
- CB 从 NAS 读取数据到你的服务器
- BD 将数据从服务器写入客户端
根据您的应用程序的工作方式并忽略协议开销，您可能（最坏的情况）需要 4 个 100mbit 网络以每秒 100mbit 的速度向您的客户端传输。
因此，如果您使用 NAS，则需要考虑 NAS 的读取和写入带宽。如果您使用 FC SAN，则可以减少网络需求并获得其他优势。
例如，根据您最终使用的操作系统和文件系统，SAN 将允许您动态地扩展您的 LUN 并实时扩展您的文件系统以及与更多主机共享 LUN，这也可能作为实时操作。
您可以通过不使用光纤通道来降低 SAN 的成本，例如，您可以使用 iSCSI。在这种情况下，您将再次需要单独的网络来存储数据，并且需要专用 NIC，最好使用 tcp/iSCSI 卸载硬件。这将使您以较低的成本获得 SAN 的大部分优势。
我还没有真正使用过 iSCSI，除了最基本的单个 LUN 到单个主机，使用简单的 linux LVM 和 ext3，所以我不能 100% 确定它是否真的和 FC SAN 一样好，但我认为如果实施得当，它是可以的。
如果您要使用集群文件系统，SAN 阵列可能是更好的选择。问题是您真的需要集群文件系统吗？这取决于您的应用程序和架构的特性。
现在，如果您的应用程序可以保证在给定时间只有节点会写入给定文件，那么您可能可以使用 NAS。但是，如果您在一台主机上修改文件，而另一台主机正在读取该文件，则可能会遇到问题，因此您的应用程序需要检测并处理这种情况。如果您不想遇到这种情况，那么集群文件系统可能是更好的选择 - 它们旨在处理这种情况。
因此，下面列出的一些问题可能会对您的架构产生重大影响：
- 文件下载一次并发送到客户端后，是否需要再次重复使用 - 即是否可以从存储中重新读取并提供给另一个客户端？
- 文件发送给客户端之前是否需要完全写入存储？
- 文件是否可以存储在服务器的本地磁盘上，并从本地磁盘提供给客户端，然后在提供给客户端之后写入 NAS/SAN？
- 多个客户端是否可能同时使用同一个文件？例如，是否有可能 50 个客户端访问一个文件或 50 个客户端访问 50 个不同的文件。
- 如果有 50 个客户端分别请求同一个文件，那么该文件会被下载一次还是五十次？
- 如果 3 小时后另一个客户端出现并请求相同的文件，该文件会被再次下载还是来自磁盘？
- 磁盘是缓存还是慢速缓冲区？
- 在文件返回给客户端之前是否会对其进行任何其他处理，例如安全扫描、重写 URL 等？
鉴于我们掌握的信息有限，我认为最安全的架构是最昂贵、最复杂的架构，因为它可以处理大多数最坏情况的问题，并且具有很强的可扩展性。例如光纤通道 SAN 和集群文件系统。
无论您的存储是DAS、SAN还是NAS，在所有情况下，在其他条件相同的情况下，主轴数量越多越好。
答案2
我会选择基于 DAS 的架构。问题是文件系统在某种程度上是无关紧要的 - 问题是，给定一个特定的 IO 要求，您可以以最佳价格将多少 GB 投入到特定的基础设施成本（大小、功率）中。
- SuperMicro 有可容纳 48 个硬盘的特殊机箱。它们并不便宜，但基于 SAS。
- 您可能必须为这些配备一个合适的 SAS 控制器。
- 处理能力也可能是一个问题，内存也是如此。当你在一个盒子里有 40.000gb 时，缓存可能需要 8 GB 左右的 RAM 才能有效 ;)
因此，最后我会选择一款非常不错的双处理器 AMD 服务器，它采用特殊的外壳设置，可以在专门的笼子里处理大量的光盘。
话虽如此，只要您不需要大型数据库通常所需的超快速磁盘访问，Cluster 可能已经是最好的了。它应该能满足您的大部分要求。但是一旦您开始使用，保持每 GB 的价格较低可能是最重要的事情 - 而不会让您的管理开销过高。