GPFS storage 2026-6-15

GPFS IBM homepage⭐️ The purpose is to demonstrate that you can take over this business.熟悉 GPFSGPFS 给GPU 集群提供的就是一个共享目录 /indosat_gpfsGPFS 集群里一共 14 台机器nc1-01…nc1-14，每台机器 16 块 NVMe( 也就是 pdisk )。一共是224 块物理盘（pdisk）. 这224块盘组成一个 declustered array: DA1, 一个 recovery group 里面包含这个 DA1。每台机器两个 log group, 每个log group 包括三种 vdisk set，每种一个vdisk , 那么一共就是 1423=84 个 vdisk.3 个 vdisk set：vs_meta(3副本)、vs_data1(8+2p)、vs_data2(8+2p)vdisk：当创建一个 vdisk 的时候。DA1 中的224块 pdisk，GNR 通过 Declustered 算法在每块盘中分出一点空间(Chunk) 拼成一个 vdisk.3副本和 8+2p 就是在 vdisk 这个级别定义的。在GPFS 眼里，vdisk 就是带了RAID 保护的逻辑盘，也叫 NSD。每个LG 下面都有 3个vdisk.（vs_meta、vs_data1、vs_data2）RAID code 就是指 3 副本或者 纠删码 8+2p此 GPFS 是 ECE 架构的，也就是硬盘插在单机上，不是ESS 架构 – 几台server 共用一组硬盘的形式。多台机器通过高速网络互联，利用软件算法(副本/ 纠删码) 在整个集群间进行数据保护。场景：一台 GPU 机器存一个 100 MiB 的 checkpointcp model.pt /indosat_gpfs/ckpt/执行这个命令后发生的一切。将100MiB 的 checkpoint 切成假设 4MiB 的 block 25个，和一组元数据，包括这个文件的 inode、它在ckpt/目录里的目录项、以及指向 25 个 block 的指针表。元数据进 vs_meta 的 vdisk set 的某个vdisk, block 进 vs_data1 或者 vs_data225块 block 是并行分到每个 LG 管理的。比如 data block #1 被分到LG7也就是nc1-04这台 server 上. 同时 data block #2 可能被分到LG19（nc1-10管的），分到某台 server 不是将block 存在这台存储节点，而是由这台 server 负责写。nc1-04拿到这个 4 MiB block，在内存中做 8+2p 编码的到10个 strip：4 MiB block 切成 8 份数据 strip，每份 512 KiB 再算出 2 份校验 strip = 10 个 strip这10个 strip 被分散存到 224块 pdisk 里的 10块上。算法保证这10个 strip 不会有两个落在同一台server上。同样 3副本的metadata block 也会被分到3个不同的 pdisk上。一个 Recover Group (RG) 包含了这28个 LG。当一台节点宕机，RG 根据集群初始化（mmvdisk rg create）时候设置好的计算节点优先级让其他server 通过本地存放的 LG 日志的副本来 接管恢复这台宕机上的两个 LG。Failure Group (FG) 只有两个，但是 三副本。 3个副本中 A 分到一个故障域，B分到另一个，而C 随机即可。但是3个副本一定分散到3台不同的server上。场景：坏盘了会怎样每个 pdisk 上面都有预留备用空间。不是单独的一块预备盘。如果某块盘坏了，它的数据就会被很多盘一起写到别的盘的预留空间里。这就是重建块的原因ReconstructAggressiveness 0就是在这里起作用：它选择"重建慢一点，别抢正常业务的 I/O"。这套系统的价值取向是坏盘期间业务优先。++++++ 下面是之前的笔记。需要梳理的。上面是梳理好的。quorum 节点数为单数，是为了防止脑裂。14 台 server(nc1)中 7 台是 quorum 节点防脑裂、14 台都可做 manager 选举出 FS/Token Manager(mmlscluster)这套有 7个 quorum ，集群要正常，必须有 7个中最少 4个能正常通信、活着。这叫 “达到法定人数”。如果集群连接断开，分成了两个集群，两边都想当家，就会同时写。有了 quorum，哪一边 quorum (≥4 个)，哪一边说了算，另一边自动停止服务。过半数嘛，总有切开的一半过半数。quorum节点(7个) ──投票──► 选出 Cluster Manager(1个,集群总管) │ 指派 ▼ File System Manager(管indosat_gpfs) │ 协调 ▼ Token Manager等(管分布式锁)Cluster Manager 是被选出来的总管;manager 资格池提供"可以被派去当 FS Manager 的候选机器";FS Manager 管具体某个文件系统的日常运营。一个节点可以同时有多个身份(比如 node 1 既是 quorum 又是 manager)。一个节点可以同时有多个身份(比如 node 1 既是 quorum 又是 manager)。分区后 cluster manager 根本联系不上对面,也发不了号令。但 quorum 机制的精妙之处恰恰在于:它不需要联系对面,而是让每一半自己根据"我手里有几张 quorum 票"来独立判断自己该活还是该死。CCR(Clustered Configuration Repository,集群化配置存储库)，管集群配置的，分布式地存放在 quorum 上，也是多数派思想，使得配置永远一致可用。400+ GPU 节点作为 GPFS 的 client.GPFS 机器 两个 400 Gbps ROCE 口，合计 800Gbps ≈ 100 GB/s 单机网络带宽。14台合起来有上千 GB/s. 约1.4 TB/s 的网络能力“block 再细分为 subblock”, 小文件不必沾满 4 MiB, 最小能只占32 KiB。prevent waste space.第一层条带化(文件系统层,GPFS做): 一个文件 → 切成多个block → scatter打散到不同NSD(vdisk) 这是"跨vdisk的条带化",让一个文件的I/O摊到多个vdisk并行 第二层条带化(RAID层,GNR做): 一个block → 8+2p切成8数据strip+2校验strip → 打散到多块pdisk 这是"跨pdisk的条带化",让一个block的I/O摊到多块物理盘并行① 文件 → 按block大小(4MiB)切成多个block, 这些block被scatter打散分配到不同NSD(这一步就是"条带化"—— 不同block去不同NSD,实现并行)② subblock只在"这个文件不满一个整block"时才登场: 尾巴上不足4MiB的部分,按32KiB的subblock粒度分配,省空间 ③ 每个要落盘的block(或它的数据),交给GNR按8+2p 切成10个strip,铺到pdisk这里用的是 scatter 策略scatter(打散)和 cluster(聚集)的区别: scatter:把一个文件的各个 block 随机打散到文件系统的所有 NSD(disk)上。这里的"所有 disk"指的是 GPFS 文件系统里的那些 NSD(你这套就是84个 vdisk,具体是 data 那56个),不是 pdisk。好处是任何一个文件的 I/O 都自然摊到很多 NSD 并行, 负载均匀,无热点。适合大集群、多节点随机访问。 cluster:尽量把一个文件的相邻 block 放到物理上相邻或相近的 disk 位置。好处是单个文件顺序读时寻址更连续(对机械盘 HDD 友好,减少磁头移动)。适合节点少、单流顺序访问为主的场景。 小集群、少节点、单流大顺序读、用 HDD,可考虑 cluster。GPFS 在节点数超过一定阈值(默认大于某个值)时会自动倾向 scatter。你这套-n150预估150节点,远超阈值,所以选 scatter 是顺理成章的。-n 150 是创建文件系统时填的预估值,不是实际挂载数,也不是硬限制。它指的就是预计有多少节点会挂载这个文件系统(主要是那些 GPU/应用客户端 + 14 台 server)。GPFS 用这个估值在创建时预先规划一些内部数据结构的初始规模(锁表、缓冲结构等)。实际现在挂了 400+ 个节点,超过 150,GPFS 照常工作——150 不是上限,只是当初的优化基准。可能的情况是:创建时(2025-08-24)规划的是 150 节点规模,后来集群扩容,GPU 节点加到了 400+,但这个创建参数没改(改它要重建文件系统,代价大,不值得)。影响是:按 150 优化的内部结构面对 400+ 节点可能不是最优,但 GPFS 有自适应能力,实际跑起来差别通常可接受。如果性能有问题,运维可以用 mmchconfig 调相关参数缓解,而不必动这个 -n。pagepool 缓存，这里 GPFS every server 192GiB memory 做 cache, 用来 GNR 的 RAID 计算和大量数据缓冲GPU server 每台 8GiB，nc1就是前面讲的 node class(节点类),是那 14 台 GPFS server 的分组名字。mmlsconfig 里 [nc1] pagepool 192GiB 意思是"对 nc1 这组(14 台 server),pagepool 设成 192 GiB"。配置可以按节点类分别下发,server 一组参数、客户端另一组参数。[clientNodes] pagepool 8G 是给客户端节点(GPU server)设的 pagepool = 8 GiB。它就是前面讲的本地内存缓存,作用是:GPU 节点读过的数据块、待写的数据块缓存在这 8 GiB 里,下次访问同样数据直接从本地内存拿,不用再走网络找 server,降低延迟、减少网络流量。server 给 192 GiB 是因为它要扛 RAID 计算和海量数据中转;客户端 8 GiB 够缓存自己任务的热数据即可。mmlsconfig 里这类参数调的是"GPFS 用多少资源、多激进地预取和缓存",目标是让带宽更高、延迟更低.一句话:这些参数是把硬件能力(800Gbps 网、NVMe 盘、大内存)真正榨出来的软件旋钮。喂满 800Gbps 网络mmlsconfig 这些旋钮不需要经常调。绝大多数情况下,这些参数在系统部署时按 IBM ESS 的最佳实践配好(你这套就是 ESS 出厂 + 现场调优的结果),之后长期不动。能在GPU server 上的 GPFS 客户端 实时看自己的 GPFS 读写速度。跑了多少带宽和 IOPS, 判断瓶颈是在 I/O 嘛？有没有吃满网络。如果读命中 pagepool，就不算盘 I/Ommpmon 是 GPFS 客户端自带的性能监控工具,fs_io_s 报的就是本节点 GPFS 客户端层的累计 I/O 计数。没装 GPFS 客户端的机器(只通过 CES NFS 访问的)就用不了 mmpmon,得用 NFS 那边的监控手段。subblocks-per-full-block,即"一个完整 block 切成多少个 subblock",这套配置是 128。block(完整块) ÷ 128 = subblock(子块,最小分配单位) system池: 1 MiB ÷ 128 = 8 KiB subblock data池: 4 MiB ÷ 128 = 32 KiB subblock┌─ 文件系统层(面向空间分配) ────────────────────────┐ │ 完整block = 4 MiB │ │ ↑可向上:多个block组成大文件 │ │ ↓可向下:切成128个subblock(各32KiB) │ │ subblock