Backup
關於 TeraByte 大小與基本數據儲存的 cpu 功率的 nas 問題
儲存空間和處理它所需的 cpu 數量之間是否存在關係？如果我每晚有 100GB 的數據通過胖管道從 50 個不同的站點遠端進入，因此 18 小時內的總數據佔用量為 100GB，並且我希望有一個 20TB 的 NAS 或儲存系統來接收它，NAS 伺服器是否需要，例如，1 xeon 或者它應該是具有多核等的雙 cpu
NAS 的目的是為現場數據提供冗餘。假設沒有頻寬問題，我們將使用胖管道來移動數據，我擔心的是同時管道來自 50 - 100 個獨立站點的 2GB 數據的獨立地理實例。我不想有讀/寫問題或同步失去/崩潰。
我需要一個方向來開始測試這個想法，所以如果我必須每晚將這麼多數據移動到 NAS 伺服器上。
如果這個問題太模糊，我可以詳細說明一下，謝謝。
處理儲存所需的處理能力取決於許多因素。如今，儲存處理是一個分佈式過程。但是遇到處理的各個地方：
- 文件共享協議。SMB、AFP、NFS 和 iSCSI 對載入都有自己的影響。程式碼質量也有重大影響；使用 netatalk 包支持 AFP，Mac 可以比基於 Linux 的 NAS 更遠地擴展 AFP。3.0 Samba 的行為比 3.6 Samba 差。
- 核心 I/O 常式。一些核心比其他核心更有效地處理 I/O。2.6.4 時代的 Linux 核心的性能不如 2.6.28 或 2.6.36。
- 軟體與硬體 RAID。如果使用軟體奇偶校驗 RAID（R5 或 R6），參與 I/O 操作的 CPU 可能會變得很重要。但是，如果您要進行條帶化（RAID1 或 RAID10，或強烈不推薦的 RAID0），它幾乎不會抽搐。如果您使用的是硬體 RAID，它們通常會在達到限制之前擴展得相當遠，但此時您的CPU負載並不重要。
- 網路堆棧。糟糕的 NIC 驅動程序可能會導致 CPU 峰值。很難預測。
以上所有提供了應用於傳入儲存請求的處理倍數。執行 6.2 MB/s 的純寫入 I/O 會產生一定量的負載，但係統所經歷的負載範圍可以從可忽略不計到崩潰，這取決於上述所有因素如何擺脫。
例如，實際伺服器硬體上的 Windows Server 2008R2 和硬體 RAID 控制器上的幾個磁碟可以整夜以 6.2 MB/s 的速度執行，並且幾乎不費吹灰之力（裸露壞驅動程序），即使在相對較舊的 64 位 Pentium 上也是如此4 個 CPU。基於 Core2 處理器的 FreeNAS 在 AFP 上執行相同的寫入速率可能無法跟上。
這是一個很長的說法，儲存的 TB 是 CPU 負載的一個非常差的預測指標。