RBDB

我正在为我正在进行的项目devise一个基础设施。这将是一个文件共享/下载项目（像rapidshare），我需要高的存储容量和良好的可调性，我会增加新的存储节点后，我的项目成长。

我为我的项目使用了Lustre，GlusterFS，HDFS，RDBD三个解决scheme。

首先，我会有2台服务器，一台服务器是glusterfs客户端+ Web服务器+数据库服务器+stream媒体服务器，另一台服务器是gluster存储节点。（有时候，我会添加更多的节点服务器和客户端服务器（不知道要添加多less新的客户端新服务器，稍后会看到）

所以，我正在考虑与glusterfs合作。但我真的不知道，如果我不得不使用具有高存储容量的高性能服务器或具有高存储容量的avarage / slow服务器？或者nas / das / san解决scheme对于glusterfs存储节点更好？我可能会购买一个nas，并在其上安装glusterfs。我很乐意听取您对服务器属性的build议（针对每个客户端和节点）。我真的不知道我是否真的需要大量的内存和良好的节点。我相信我需要它的客户端服务器。

这些文件也将被stream式传输，所以自动文件复制是非常重要的，因此，我的系统应该像云一样工作，在需要时，根据高stream量，存储节点应该复制最需要的stream文件，并帮助我摆脱scable问题，我的访问者将能够stream/下载这些文件。

此外，我很乐意听取您有关任何良好解决scheme的经验/想法。 Lustre，hdfs，rbdb是其他的select，我会很高兴听到你的想法在这里。如果有人评论我在这里使用的任何词语，我会非常高兴听到任何人的评论。

谢谢

编辑：

我知道如果我的networkingdevise，IOPS是每个计算中必须考虑的关键variables，那就是为什么我说随机请求。但不幸的是，我没有任何统计数据。这就是为什么我在这里:)

我的项目是这样的，你input一个下载url到我的网站，我的url下载它，然后开始从我自己的服务器下载它，就像代理下载。

所以我现在有一个服务器100mbit连接和2TB硬盘。我想添加NAS服务器。真的不知道我是否必须在nas中添加重复的存储节点。有没有限制，我可以连接NAS设备？我的意思是我可以连接最多2台服务器到我的主服务器？

你的问题不是微不足道的，没有足够的信息给出一个好的答案。我可以给出一个答案（光纤通道SAN上的集群文件系统） – 但它可能会变得比所需要的更昂贵和复杂。

所以我只是抛出一些意见/想法。真的东西给你考虑。也许在阅读了这个大脑转储之后，你可以重申你的应用程序的预期行为，也许我们可以给你一个更好的答案。

NAS设备会导出文件系统（例如CIFS，NFS），因此您不能真正将它们连接到您的服务器上 – 您的服务器会从中安装文件系统。这意味着读取和写入他们需要检查你的连接。因此，如果NAS和服务器之间的networking连接速度为100mbit，并且读/写比率为1：1，那么最好的读取次数为50mbit，因为读取的每个字节都会写入一个字节。如果您的客户端和下载stream量在同一networking上，那么您可以将其减半。很显然，如果你想使用NAS，那么你将需要在你的服务器中使用多个NIC，在你的架构中使用multipelnetworking/ VLAN。

假设您的应用中有4个可能的数据位置。

A）信息数据源，例如互联网。
B）你的服务器。
C）NAS。
D）客户列表项目

然后有4个可能的数据向量

AB即从A（networking）到B（您的服务器）的数据下载。
BC即将数据从服务器写入NAS。
CB从NAS读取数据到您的服务器
BD将数据从服务器写入客户端

根据你的应用程序的工作方式和忽略协议开销，你可能（最坏的情况下）需要4个100mbit的networking，以每秒100mbit的速度向你的客户端传输。

因此，如果您使用NAS，则需要考虑NAS的读取和写入带宽。如果您使用FC SAN，则可以减lessnetworking需求，并获得其他通知。

例如，根据操作系统和最终使用的文件系统，SAN将允许您dynamic扩展您的LUN，并扩展您的文件，以及与更多主机共享LUN，这也可能是实时操作。

您可以通过不使用光纤通道来降低SAN成本，例如可以使用iSCSI。在这种情况下，您将再次需要单独的networking来处理您的数据，并且您需要专用NIC，理想情况下使用tcp / iSCSI卸载硬件。这将以更低的成本为您提供SAN的大部分优势。

我还没有真正将iSCSI exxcept用于最简单的单个LUN到单个主机，只有简单的linux LVM和ext3，所以我不能100％确定它是否真的和FC SAN一样好，但是我认为它可以是好的实现。

如果要使用群集文件系统，SANarrays可能是更好的select。问题是你真的需要一个集群文件系统吗？这将取决于你的应用程序的特点和你的架构。

现在，如果您的应用程序可以保证只有节点节点将在给定的时间写入给定的文件，那么您可能会去NAS。但是如果您在使用其他主机读取文件的同时修改文件，则可能会遇到问题，因此您的应用需要检测并处理该场景。如果这是一个你不想打扰的场景，那么一个集群文件系统可能是更好的select – 它们被devise为与这种场景一起工作。

因此，下面列出的一些问题可能会对您的架构产生重大影响：

文件是否需要在下载一次并重新发送到客户端之后再次使用 – 也就是说，是否可以从存储中重新读取文件并将其提供给另一个客户端？
在将文件发送到客户端之前是否需要将文件完全写入存储器？
文件可以存储在服务器上的本地磁盘上，并从本地磁盘传送到客户端，然后在传送到客户端后写入NAS / SAN？
多个客户可能一次使用同一个文件吗？例如50个客户端可能会访问一个文件，或50个客户端访问50个不同的文件。
如果50个客户端每个请求相同的文件，它会被下载一次或50次？
如果另外一个客户端3个小时后出现，请求相同的文件将文件再次下载或从磁盘来？
磁盘是caching还是caching？
在将文件返回给客户端之前是否会对文件执行任何其他处理，例如扫描的安全性，URL的重写等。

鉴于我们有限的信息，我会说最安全的架构是最昂贵和复杂的架构，因为这将处理大多数最坏的情况下的问题，并且是非常可扩展的。即光纤通道SAN和集群文件系统。

在所有情况下，无论您的存储，DAS，SAN，NAS，所有其他的东西是平等的更多的主轴更好。

我会去一个基于DAS的架构。问题在于文件系统无关紧要，问题在于，如果有特定的IO要求，可以将多lessGB的GB放入一定的基础架构成本（大小，功耗）中以获得最佳的价格。

SuperMicro有特殊情况，最多可容纳48个硬盘。他们不便宜，但基于SAS。
对于这些，你可能不得不使用合适的SAS控制器。
处理能力也可能是一个问题，内存也是如此。当你在一个盒子里有40,000GB的时候，那个caching可能需要8个左右的GB RAM才是有效的;）

所以，最后我会用一个相当不错的双处理器AMD服务器上的一个特殊的shell设置，可以在专门的笼子里处理很多光盘。

就是说，群集可能是一样的 – 只要你不需要超大型数据库的典型快速光盘访问。它应该做你所要求的大部分。但是，一旦你走了，保持每GB的价格可能是最重要的事情 – 而不是通过屋顶的pipe理开销。