给定以下参数，我如何估计磁盘子系统要求？
该环境是一个公共的网络服务器，用于向许多并发用户传送大文件。
- 文件集总大小（以 GB 为单位）
- 文件集总大小（文件数）
- 工作文件集大小（以 GB 为单位）
- 工作文件集大小（文件数）
- 平均文件大小
- 客户端平均下载速度
- 预期并发客户端
尽管这些都是大文件，但我想我应该估计纯随机 IO 和纯顺序 IO 之间的某个值。对于速度更快/更少的客户端，我猜它会趋向于顺序，而对于速度更慢/更多的客户端，它会趋向于随机。希望这有点正确？
所以我的想法是先计算“预期 IOPS”。这就是我所坚持的。我假设我应该能够使用以下参数来接近：工作集大小、平均客户端速度和预期并发客户端。
从那里，我可以查看磁盘和 RAID 控制器的 IOPS 等级，并粗略估计为许多用户提供文件集所需的磁盘子系统。
显然，它还有更多内容，例如预读和可用于缓存的 RAM 数量，以及文件系统块大小、RAID 条带宽度等，但我想如果我以 0 预读和 0 RAM 为基础，那应该能给我一个粗略的悲观估计。
请有该领域经验的人告诉我我是否走在正确的轨道上，和/或就如何计算这些值提供任何建议？
如果有讨论此问题的网站或可以购买的书籍，我非常愿意这样做，但我已经搜索了 2 天，但运气不佳。在存储方面我有点力不从心。
我也知道我必须进行基准测试才能得到正确的答案，但我希望首先尽可能多地进行估算。
感谢所有帮助，欢迎火焰！
答案1
您似乎忽略了预期的最大传输速率。此外，您还需要了解 IOPS 曲线的“噪声”程度。如果噪声很大，则可能会出现持续一段时间的显著高于平均 IOPS 的情况，您需要为此进行设计。根据经验，一些最大的突发 IOPS 发生在大型传输中，如果这些大型传输以某种方式使您的 I/O 子系统饱和，则传输期间的其他操作将受到影响。
峰值负载确实需要考虑，因为您希望在峰值负载发生时能够充分发挥作用。这可能意味着您的系统在很多时候都没有得到充分利用，但这是理所当然的。我们在预期的负载范围和可控的增长范围内创建了最低服务保证，这会导致一定程度的过度设计。
另一个方面是预期的读/写 I/O 百分比。您说的是 Web 服务器，所以我猜读比写要多，但您最好知道。如果百分比严重偏向读（例如，80% 的读），这将影响您为存储子系统选择的内容，因为您将能够负担得起昂贵的写操作以获得快速读操作（例如 RAID5 或 RAID6）。但不要太贵，因为您不想用大量的写操作来饱和某些东西，这会使整个系统陷入困境。
一旦你拿到了硬件，就测试故障模式。弄清楚当一个驱动器发生故障时，以及当一个驱动器重新插入时，情况会变得有多糟糕。如果你只有五个磁盘，这可能不是什么大问题，因为故障率应该足够低，坏盘应该很少发生。但是如果你有很多主轴（比如说……超过 10 个），你的故障率可能很高，以至于你必须在估算中考虑“故障”状态。几年前我们被这个问题搞得很惨，因为某个驱动器阵列在重建奇偶校验集时严重阻塞了写入（它禁用了写入缓存，太邪恶了），当有人在此期间试图将 CD 映像（625MB！）写入它时，这造成了严重破坏。
最后，在估算期间考虑备份期间的负载。如果您必须在备份忙于读取服务器上的所有内容时提供服务，这也会影响您获得的存储系统的强大程度。因此，请考虑实用程序 I/O 操作，而不仅仅是用户生成的操作。
这将为您提供更多可供使用的数据点！
**编辑：*峰值余量...这取决于负载。我有一个系统，白天平均速度在 3-5 MB/s 之间，峰值在 10-15MB/s 范围内，备份可以将其推至 20-25MB/s。因此，平均值约为 12MB/s，真正的峰值略高于这个数字的两倍。这个特定的系统在 RAID 重建期间不会受到太大影响，因此它不进入规划。此外，在备份期间，最终用户驱动的 I/O 很少，所以我不必担心争用，这意味着我可以在备份期间全力以赴，而不必担心接到电话。