存储空间和处理它所需的 CPU 数量之间是否存在关系？如果我每晚有 100GB 的数据通过一条粗管道从 50 个不同的站点远程传入，那么 18 小时内的总数据占用空间为 100GB，并且我希望有一个 20TB 的 NAS 或存储系统接收它，NAS 服务器是否需要有，例如，1 个 xeon 或它应该是具有多核的双 CPU 等
NAS 的目的是为现场数据提供冗余。假设没有带宽问题，我们将使用粗管道来移动数据，我担心的是同时传输来自 50 - 100 个不同站点的 2GB 数据的不同地理实例。我不想出现读/写问题或同步丢失/崩溃。
我需要一个方向来开始测试这个想法，所以我是否必须每晚将那么多数据移动到 NAS 服务器上。
如果问题太模糊，我可以进一步详细说明，谢谢。
答案1
处理存储所需的处理能力取决于许多因素。如今，存储处理是一个分布式过程。但处理的各个地方如下：
- 文件共享协议。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，它们通常会在达到极限之前扩展得相当远，但那时您的中央处理器加载并不重要。
- 网络堆栈。糟糕的 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 负载。
答案2
这种关系并不完全是空间：CPU 问题。根据您目标的解决方案，您可能需要 CPU 能力来实现重复数据删除、压缩、加密或哈希/校验和计算等功能。
除非您的系统设计得非常糟糕，否则简单的数据复制过程不会产生太多的 CPU 开销。您每 18 小时 100 GB 的需求平均为 1.58 MB/秒 - 如今，即使是上网本也能应付。
您还应该专注于所使用的 I/O 后端。虽然每秒写入 1.58 MB 听起来并不困难，但使用 50-100 个同时进行的进程将产生大量随机写入负载。硬盘不能很好地处理随机（写入）负载，因为这些负载将产生大量耗时的磁头寻道，因此您需要使用某种东西来缓冲随机性 - 例如 DRAM 或 SSD 写入缓存。