我已经有了40年的计算能力，但是我从来没有像现在这样build立一个服务器，所以这可能是一个问题。
我有一个客户端，将提供超高清音乐文件下载。 在这种情况下，这意味着FLAC压缩24 / 192Khz =〜10GB /专辑。 （不，我不想讨论产品的可取性，只是服务器configuration。）目录大约有3000个专辑，包括超高清和低清版本（对于他们的iPod，我想），给出原始数据35-40TB左右。
由于这是一个非常专业化的产品，因此市场规模相对较小（想想：在audio系统上花费2万美元以上的人），这意味着大多数情况下服务器将100％空闲（或接近它）。 ColocationAmerica提供的1Gbps连接和带宽约为20美元/ TB，这是一个很好的托pipe服务，所以现在我只需要构build一个盒子来交付货物。
数据访问用例是一次写入/多次读取的，所以我正考虑使用软件RAID 1来配对驱动器。 这可以让我（我认为 ）重新configuration备用驱动器的故障的dynamic，从而能够开始重build第二个驱动器之前，一些系统pipe理员注意到系统上的红灯（他们可以自由换出）。 如果不需要的话，我可以让大部分硬盘进入hibernate/hibernate状态，这对于大多数硬盘来说是大部分时间。
我并不需要太多的计算能力 – 这个东西只是把肥pipe放在pipe道上 – 所以CPU /主板可以是非常适中的，只要它能支持这个数量的驱动器。
我目前正在考虑以下configuration：
Chasis: Supermicro CSE-847E26-RJBOD1 Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?) MB: SUPERMICRO MBD-X10SAE-O w/ 8GB CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server 那么，我是朝着正确的方向走，还是这是一个完全解决问题的方法？
更新以澄清几点：
ZFS？ 效益在哪里？
好吧，我正在通过多个ZFS指南，常见问题解答等方式来抨击我。请原谅我听起来很愚蠢，但我真的很想了解使用ZFS而不是N RAID1对的先前概念。 在这个最佳实践的页面（从2006年开始），他们甚至build议不要使用48个ZFS设备，而是使用24个2个设备的镜像 – 这听起来就像我正在谈论的那样。 其他页面提到为了交付1个（一个）ZFS块而必须访问的设备数量。 另外，请记住，每个对象10GB，磁盘利用率为80％， 每个4TB驱动器总共存储320个文件。 对于任何给定的驱动器故障，我使用N个RAID 1重build时间是从一个设备到另一个设备的4TB写入。 ZFS如何使这个更好？
我会承认是恐龙，但是磁盘价格便宜，RAID 1我知道，我的文件pipe理需求是微不足道的，Linux上的ZFS（我的首选操作系统）还是很年轻的。 也许我太保守了，但是当我看着一个生产系统的时候，我就是这样滚动的。
我感谢你们所有的意见，这让我想到了这一点。 我还没有完全决定，我可能不得不回来问一些更多的问题。
根据您的问题描述，您的问题不是存储的服务器。
您需要像ZFS这样的可靠，强大的文件系统来处理大型存储容量，并且具有内置的pipe理function，以使系统的端点更容易pipe理。
正如在评论中提到的那样，我将使用ZFS作为存储池（可能在FreeBSD上，因为我对这个操作系统非常熟悉，而且它在ZFS方面有很长的，可靠的性能logging – 我的第二select操作系统将是Illumos ，再次因为经过良好testing的ZFS支持）。
至于提供的文件，我同意 – 你不需要太多的硬件，只是推出的数据networking端口。 CPU / RAM的主要驱动程序将成为文件系统（ZFS）的需求。
一般的经验法则是ZFS需要1GB内存，加上每pipe理10TB磁盘空间需要1GB（因此对于40TB，ZFS需要5GB内存） – 这种关系不是非常线性的（有很多关于ZFS的好书/教程/文档，可以帮助您对您的环境进行估算）。
请注意，添加重复数据删除等ZFS铃声和哨声将需要更多的RAM。
很明显，内存要求不是宕机，不要吝啬：如果你的math说，你需要5GB的内存不要加载8GB的服务器 – 升级到16GB。
然后，您可以直接在存储盒上运行服务器（这意味着您需要更多的RAM来支持服务器进程），或者您可以将存储远程安装到“前端”服务器实际上服务客户的要求
（前者最初便宜，后者长期更好。）
除了这个build议，我可以给你的最好的build议已经在我们的容量规划系列的问题中得到了很好的覆盖 – 基本上就是“负载testing， 负载testing ， 负载testing ”。
我使用ZFS作为多TB服务器，并且一直坚如磐石。 我使用OpenIndiana开始，现在已经转移到FreeNAS，因为它做我需要做的。
我推荐使用带有SAS扩展器的LSI HBA卡（9211-8i是一个很好的基卡）（SuperMicro案例可以使用基于LSI芯片组的集成SAS扩展器）。 FreeNAS和FreeBSD支持LSI固件。 检查适当的版本（V16在FreeBSD V9.x上是好的）。
考虑到一次写入你的系统的许多性质，我会使用ZFS Z2拓扑（避免RAID-5和Z1驱动器的大小）。 考虑到您使用的是4TB磁盘，如果池已满，大型单个vDevarrays的重build（重新启动）时间将会很长。 为了避免冗长的重build时间，请将vDevs分成6组或10组来创build池（FreeNAS文档中的build议）。 由三个6驱动器vDevs（假定4TB驱动器）组成的池将具有〜48TB的可用容量，并提供良好的容错级别（请记住，由于RAID不会替代备份，所以仍然需要备份）。
为了加快常用文件的速度，你可以在L2ARC上安装一些固态硬盘（可能不是你的应用程序所需要的，但是对于120GB固态硬盘来说它们相当便宜）。
如上所述，使用大量的RAM。 考虑到系统中的其他硬件，64GB并不是太昂贵。 不幸的是，更小的XEON不能使用超过32GB。 你可以试试，但根据ZFS文献（我使用XEON你提到的32GB内存和24TB容量的Z2arrays，它工作正常），更多的RAM会更好。
ZFS的另一个优点是您可以设置定期快照。 这样，您可以轻松恢复以前的版本，快照非常节省空间。 此外，您可以将任何快照复制到另一个数据集（本地或远程），这可以通过SSH安全来完成。
我非常喜欢ZFS系统的可靠性。 我也喜欢它是硬件独立的事实！ 任何可以看到驱动器的系统都可以导入池。 没有固件依赖等，可能发生在硬件突袭（不是一个更好的卡问题，但他们比HBA卡更昂贵，需要驱动程序等 – 在过去一点点）。
鉴于这个post比较老，你可能有一个解决scheme。 如果是这样，请告诉我们你build立了什么？
干杯，