對 40TB 伺服器配置進行完整性檢查
我有 40 年的計算經驗，但我從來沒有建構過像這樣的伺服器，所以這可能是一個 n00b 問題。
我有一個客戶端將提供超高畫質音樂文件供下載。在這種情況下，這意味著 FLAC 壓縮的 24/192Khz =~ 10GB/專輯。（不，我不想討論產品的可取性，只討論伺服器配置。）目錄將包含大約 3,000 張專輯，包括超高畫質和低解析度版本（我猜是為他們的 iPod 提供的），大約35-40TB 左右的原始數據。
由於這是一個非常專業的產品，市場規模相對較小（想想： $ 20,000+ on their audio systems), which means most of the time the server is going to be 100% idle (or close to it). I have what looks like a good colocation offer from ColocationAmerica with a 1Gbps connection and bandwidth at about $ 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那麼，我是否朝著正確的方向前進，或者這完全是解決問題的 n00b / 恐龍方式？
更新以澄清幾點：
- 我沒有使用 ZFS 的經驗，因為我擁有的最後一個 Sun 產品是在 80 年代後期。我會做一點 RTFMing 來看看感覺是否正確。
- 我真的不需要文件系統來做任何引人注目的事情，因為文件名將是簡單的 UUID，並且對象將在驅動器之間保持平衡（有點像大型記憶體系統）。所以我真的認為這些是 40 個獨立的文件系統，這使得 RAID 1 聽起來很正確（但我承認這裡的無知）。
- 因為我們目前的預期是我們不可能在任何時候下載超過幾十個文件，而且在大多數情況下只有一個人下載任何給定的文件，我不知道我們是否需要大量記憶體用於緩衝區。也許 8GB 有點輕，但我認為 128GB 除了消耗能量之外不會做任何事情。
- 這裡沒有提到 2 台獨立的機器：他們目前的網路商店，以及一個幾乎完全解耦的 Download Master，它處理所有身份驗證、新產品攝取管理、策略執行（畢竟，這是RIAA 的遊樂場）、臨時 URL 創建（可能如果流量超出我們的預期，則將下載移交給這些野獸中的多個）、使用跟踪和報告生成。這意味著這台機器幾乎可以用 Quaaludes 上的沙鼠來建造。
ZFS？好處在哪裡？
好的，我正在閱讀多個 ZFS 指南、常見問題解答等。請原諒我聽起來很愚蠢，但我真的想了解使用 ZFS 對我的 N RAID1 對的古老概念的好處。在這個最佳實踐頁面（從 2006 年開始）上，他們甚至建議不要做 48 個設備的 ZFS，而是 24 個 2-device-mirrors——聽起來有點像我所說的。其他頁面提到了為了傳遞 1（一個）ZFS 塊而必須訪問的設備數量。另外，請記住，在每個對象 10GB 和 80% 的磁碟使用率下，每個 4TB 驅動器總共儲存 320 個文件。對於任何給定的驅動器故障，我使用 N RAID 1 的重建時間是從一個設備到另一個設備的 4TB 寫入。ZFS 如何使這變得更好？
我承認自己是恐龍，但磁碟很便宜，RAID 1 我理解，我的文件管理需求微不足道，Linux 上的 ZFS（我的首選作業系統）還很年輕。也許我太保守了，但是當我在看一個生產系統時，我就是這樣滾動的。
我非常感謝你們所有人的評論讓我思考這個問題。我還沒有完全決定，我可能不得不回來問一些更多的 n00b 問題。
根據您的問題描述，您的問題與其說是伺服器，不如說是儲存。
您需要一個可靠、健壯的文件系統，例如ZFS，它旨在很好地處理大儲存容量，並具有內置管理功能，使系統的這一端更易於管理。
正如評論中提到的，我會使用 ZFS 作為儲存池（可能在 FreeBSD 上，因為我最熟悉那個作業系統，並且因為它在 ZFS 的可靠性能方面有著長期、可靠的記錄——我的第二選擇作業系統將是Illumos，再次因為經過良好測試的 ZFS 支持）。
就提供文件而言，我同意 - 您不需要太多硬體即可將數據推出網路埠。CPU/RAM 的主要驅動力將是文件系統 (ZFS) 的需求。
一般的經驗法則是 ZFS 需要 1GB 的 RAM，加上它管理的每 10TB 磁碟空間需要 1GB（因此對於 40TB，ZFS 需要 5GB 的 RAM）——儘管這種關係不是很線性（有很多ZFS 上的好書/教程/文件，可以幫助您對您的環境進行估計）。
請注意，添加像重複數據刪除這樣的 ZFS 功能將需要更多 RAM。
顯然，將 RAM 要求向上而不是向下取整，並且不要吝嗇：如果您的數學表明您需要 5GB 的 RAM，請不要使用 8GB 載入伺服器 - 提高到 16GB。
然後，您可以直接在儲存盒上執行您的伺服器（這意味著您將需要更多的 RAM 在該儲存盒上支持伺服器程序），或者您可以將儲存遠端安裝到“前端”伺服器以實際服務於客戶請求。
（前者最初更便宜，後者長期擴展更好。）
除了這個建議之外，我能給你的最佳建議已經很好地涵蓋在我們的容量規劃系列問題中——基本上是“負載測試、負載測試、負載測試”。