构建 24 块磁盘池 SSD 热设置缓存的推荐方法：RAID、LVM JBOD 等？

Question

我试图找出将 24x 本地连接的 SSD 配置为具有低价值数据的大型逻辑卷的最低麻烦方法。我将它们用作主状态（大约 PB 级）驻留在 S3 中的数据的热设置缓存，因此与丢失的数据相比，我更关心性能、维护的复杂性和停机时间。没有任何东西会在热数据集中停留超过几天，无论如何都可以轻松地从 S3 重新创建。

• 中大型实例：32x vCPU、120GB RAM、Skylake
• 24 个本地连接的 SSD @ 每个 375GB = 总共 9TB
• 托管在 Google Cloud (GCP) 上
• Debian 10（巴斯特）
• 读取访问比写入重约 4 倍
• 大量并发用户（人和机器）具有相当随机的访问模式，并且非常渴望 I/O。
• 90% 的文件大于 10MB

我认为 RAID 5 是不可能的，我不可能等待手动重建。我倾向于使用 RAID 0、RAID 10 或......也许这实际上是一个根本没有 RAID 的简单 LVM 池的情况？在这种情况下，走相对简单的路线，我真的会失去任何东西吗？

我的理想解决方案是将每个/子目录（每个子目录都有一个自包含的数据集）完全包含在单个磁盘上（我可以在每个驱动器上安装 10 个子目录）。如果驱动器出现故障，我会暂时中断该驱动器上的子目录/数据集，但很容易推断“这些数据集正在重新下载但不可用”。然后我只是在新驱动器上从 S3 重建丢失的数据集。我怀疑 LVM jbods（不确定这个词的确切含义？）可能最接近复制这种行为。

Answer 1

您似乎与您的需求相矛盾 - “我理想的解决方案将让每个子目录（每个子目录有一个自包含数据集）/完全包含在单个磁盘上”告诉您您不需要 RAID、LVM 或任何抽象技术- *当然，解决这个问题的方法是简单地单独安装每个磁盘。这里的缺点是您可能会浪费磁盘空间，并且如果数据集增长，您将需要花费更多时间来处理它。（我希望您知道 Unix 可以在文件系统树的任意位置安装驱动器，因此只要稍微考虑一下，就应该很容易使驱动器作为逻辑树结构可见）

你说的是JBOD还是RAID0。如果您决定采用组合磁盘解决方案，RAID0 在大多数情况下将为您提供更好的读取性能，因为数据很容易在磁盘上分解。RAID10 将为您购买您声称不需要的冗余。JBOD 仅在您拥有不同大小的磁盘时才对您有用，并且您最好使用 LVM，因为它可以以相同的方式运行，但可以让您灵活地移动数据。

我可以看到 LVM 对单个磁盘有帮助的边缘情况，但一般来说，任何情况都可能会增加更多的复杂性，然后它在这里提供有用的灵活性 - 特别是要记住关于数据集绑定到磁盘的最初声明。

您可能需要花一些精力寻找最合适的文件系统和调整参数。