我们有一台中央存储服务器 (PowerEdge R720)，为 HPC 集群提供共享文件，它连接了两个硬件 RAID 控制器 (PERC H810，每个控制器驱动 2 个装有 7200rpm 4TB 磁盘的 MD1200 机箱)。与典型的 HPC 工作负载一样，访问模式预计是高度并行的顺序读取/写入。我认为将文件条带化到两个阵列可以提供更好的总吞吐量，但在硬件 RAID 之上使用软件 RAID 0 的想法对我来说听起来很疯狂。
我想到了两个选择：
- NFS 在 XFS 上 在软件 RAID 0 上 在硬件 RAID 6 上
- 每个硬件 RAID 6 上的光泽
XFS 的优点：项目配额。
XFS 缺点：XFS 上的 NFS 表现出非常糟糕的元数据性能（当吞吐量很大时会降级到几乎无法使用，我调整错了吗？）。
lustre 的优点：元数据性能显著改善。
lustre 的缺点（？）：我们没有专用的元数据设备，必须对阵列进行分区。这听起来不是一个值得推荐的做法。
我们考虑了元数据性能，因为虽然顺序读写是主要工作负载，但我们有一些程序正在处理大约 40k 个 1GB 的文件。以交互方式管理这些文件确实需要可接受的元数据性能。
最后一个问题是，硬件和软件上应使用多大的条带大小？
答案1
我们确定了以下设置：
- 每个 MD1200 盘柜中均有硬件 RAID-6
- 四个硬件阵列上有两个 LVM LV，每个 LV 将两个卡上的两个阵列组合在一起，不进行条带化
- 两个 LV 上的 XFS，条带化选项与裸硬件阵列相同
- 两块砖上的光泽体积，没有条纹
我们调查了用户的所有应用程序，发现它们都对许多文件进行操作。因此，许多客户端访问单个大文件的情况并不适合，而 gluster 级别的条带化是必需的；相反，只需将文件随机分布到砖块上就能提供足够的总吞吐量。
虽然此设置的元数据性能比 Lustre 差（大约差一半），但在吞吐量较大时，性能不会下降。结果还是可以接受的。
Gluster 可对目录进行配额配置，而且设置起来比 lustre 容易得多，因此所需的管理工作量也比 lustre 少得多。在我的（粗略）测试中，此设置的连续吞吐量与 lustre 相当，因此我们决定牺牲元数据性能的这一部分，以简化管理。