我从事计算机工作已有 40 年，但从未构建过像这样的服务器，所以这可能是一个新手问题。
我有一个客户，他要提供超高清音乐文件供下载。在这种情况下，这意味着 FLAC 压缩的 24/192Khz =~ 10GB/张专辑。（不，我不想讨论产品的可取性，只想讨论服务器配置。）目录将包含约 3,000 张专辑，包括超高清和低清晰度版本（我猜是用于他们的 iPod），提供约 35-40TB 左右的原始数据。
由于这是一款非常专业的产品，因此市场规模相对较小（想想那些在音频系统上花费 20,000 美元以上的人们），这意味着大多数时候服务器将处于 100% 闲置状态（或接近闲置状态）。我从 ColocationAmerica 获得了一个看起来不错的托管服务，提供 1Gbps 连接和带宽，价格约为 20 美元/TB，所以现在我只需要建立一个盒子来交付货物。
数据访问用例是一次写入/多次读取，因此我考虑只对驱动器对使用软件 RAID 1。这将允许我（我思考) 来动态重新配置备用驱动器以替换故障驱动器，从而能够在系统管理员注意到系统上的红灯之前开始重建第二个驱动器（它们会自由交换）。如果我能让大多数驱动器在不需要时进入睡眠/降速状态，那就太好了，大多数驱动器大多数时候都是这样。
我不需要太多的计算能力 - 这个东西只是将大物体推入管道 - 因此只要它可以支持这个数量的驱动器，CPU/主板就可以非常适中。
我目前正在考虑以下配置：
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，因为我拥有的上一款 Sun 产品是上世纪 80 年代末的产品。我会进行一些 RTFMing 来查看是否感觉合适。
- 我实际上并不需要文件系统做任何特别的事情，因为文件名将是简单的 UUID，并且对象将在驱动器之间保持平衡（有点像大型缓存系统）。所以我真的把它们看作 40 个独立的文件系统，这使得 RAID 1 听起来很正确（但我承认我无知）。
- 由于我们目前的预期是，我们不太可能一次下载超过几十个文件，而且在大多数情况下，只有一个人下载任何给定的文件，所以我不知道我们是否需要大量的内存来缓冲。也许 8GB 有点轻，但我认为 128GB 除了消耗能源之外不会做任何其他事情。
- 这里没有提到 2 台独立的机器：他们当前的网络商店，以及一个几乎完全解耦的下载主机，它处理所有的身份验证、新产品导入管理、策略执行（毕竟，这是RIAA 的游乐场）、临时 URL 创建（如果流量超出我们的预期，可能会将下载交给多个这样的野兽）、使用情况跟踪和报告生成。这意味着这几乎可以使用服用 Quaaludes 的沙鼠来建造机器。
ZFS？好处在哪里？
好吧，我正在努力阅读多个 ZFS 指南、常见问题解答等。请原谅我听起来很蠢，但我真的想理解好处使用 ZFS 而不是我的过时的 N RAID1 对概念。在此最佳实践页面（自 2006 年起），他们甚至建议不是执行 48 个设备的 ZFS，但有 24 个 2 设备镜像——听起来有点像我所说的那样。其他页面提到了必须访问的设备数量，才能提供 1（一个）ZFS 块。另外，请记住，每个对象 10GB，磁盘利用率为 80%，我总共存储了 320 个文件每 4TB 硬盘对于任何给定的驱动器故障，我使用 N RAID 1 的重建时间是从一个设备到另一个设备的 4TB 写入。ZFS 如何改善这一点？
我承认自己是老古董，但磁盘很便宜，RAID 1 我理解，我的文件管理需求微不足道，Linux（我首选的操作系统）上的 ZFS 还很年轻。也许我太保守了，但当我考虑生产系统时，这就是我的做法。
非常感谢大家的评论，让我思考这个问题。我还没有完全决定，可能还要回来问一些新手问题。
答案1
根据你的问题描述，你的问题不在于服务器，而在于存储。
你想要一个可靠、强大的文件系统，比如虚拟文件系统它旨在很好地处理大存储容量，并具有内置的管理功能，使系统端更易于管理。
正如评论中提到的，我会选择 ZFS 作为存储池（可能是在 FreeBSD 上，因为我最熟悉该操作系统，并且因为它在 ZFS 方面有着长期、可靠的性能记录 - 我的第二选择操作系统是伊鲁莫斯，同样归功于经过充分测试的 ZFS 支持）。
至于提供文件，我同意 - 您不需要太多硬件，只需将数据从网络端口推出即可。CPU/RAM 的主要驱动因素将是文件系统 (ZFS) 的需求。
一般经验法则是 ZFS 需要 1GB RAM，加上它管理的每 10TB 磁盘空间需要 1GB（因此对于 40TB，您需要 5GB RAM 用于 ZFS）-- 但关系并不完全是线性的（有很多关于 ZFS 的好书/教程/文档可以帮助您为您的环境做出估计）。
请注意，添加重复数据删除等 ZFS 附加功能将需要更多 RAM。
显然，应该将 RAM 需求四舍五入为高而不是低，并且不要吝啬：如果您的计算表明您需要 5GB 的 RAM，那么不要在服务器上加载 8GB——请增加到 16GB。
然后，您可以直接在存储盒上运行服务器（这意味着您将需要在该盒上安装更多 RAM 来支持服务器进程），也可以将存储远程安装到“前端”服务器以实际满足客户端请求。
（前者最初更便宜，而后者从长远来看更具可扩展性。）
除了这个建议之外，我能给你的最佳建议已经在我们的容量规划系列问题-- 基本上是“负载测试，负载测试，负载测试“。
答案2
我将 ZFS 用于多 TB 服务器，它非常稳定。我最初使用 OpenIndiana，现在已转向 FreeNAS，因为它可以满足我的需要。
我建议使用带有 SAS 扩展器的 LSI HBA 卡（9211-8i 是一款不错的基础卡）（可以订购带有基于 LSI 芯片组的集成 SAS 扩展器的 SuperMicro 机箱）。FreeNAS 和 FreeBSD 支持 LSI 固件。检查适当的版本（V16 适用于 FreeBSD V9.x）。
考虑到您系统的一次写入多次读取特性，我将使用 ZFS Z2 拓扑（避免使用这种大小的驱动器的 RAID-5 和 Z1）。假设您使用的是 4TB 磁盘，如果池已满，则大型单个 vDev 阵列的重建（重新镀银）时间会很长。为避免较长的重建时间，请将 vDev 安排为 6 或 10 个组来创建池（FreeNAS 文档中的建议）。由三个 6 驱动器 vDev（假设为 4TB 驱动器）组成的池将具有约 48TB 的可用容量，并提供良好的容错能力（请记住，您仍然需要备份内容，因为 RAID 不会取代备份 :)）。
为了加快常用文件访问的速度，您可以投入几个用于 L2ARC 的 SSD（您的应用程序可能不需要，但对于 120GB SSD 来说它们非常便宜）。
如上所述，使用大量 RAM。考虑到系统中的其他硬件，64GB 并不算太贵。不幸的是，较小的 XEON 不能使用超过 32GB 的内存。您可以尝试一下，但根据 ZFS 文献，更多的 RAM 会更好（我使用您提到的 XEON，它有 32GB 内存和 24TB 容量的 Z2 阵列，它运行良好）。
ZFS 的另一个优点是您可以设置定期快照。这样，您可以轻松恢复以前的版本，并且快照非常节省空间。此外，您可以将任何快照复制到另一个数据集（本地或远程），并且可以通过 SSH 进行安全操作。
我真的很喜欢 ZFS 系统的可靠性。我还喜欢它独立于硬件的事实！！任何能够看到驱动器的系统都可以导入池。没有固件依赖性等，硬件 raid 可能会出现这种情况（更好的卡不是问题，但它们比 HBA 卡更贵，需要驱动程序等 - 过去曾受到过这种影响）。
鉴于这篇文章比较老，您可能有一个解决方案。如果是这样，介意告诉我们您构建了什么吗？
干杯，