曙光ParaStor并行文件系统部署与性能调优实战指南

简介《曙光ParaStor云存储系统》是一份PDF格式的解决方案型文档面向存储工程师、架构师和IT决策者聚焦大规模非结构化数据的分布式存储需求系统介绍产品定位与选型要点。资源为单个PDF文件压缩包约3.39MB轻量便于随时查阅。文档从存储市场趋势切入指出Scale-out NAS快速增长、传统阵列萎缩并梳理了ParaStor在2015年中国区NAS市场排名第一、累计销售容量超过260PB等关键数据同时细述其索引控制器与数据控制器分离的非对称式架构支持2~128个索引控制器、3~4096个数据控制器以及多副本、纠删码等冗余方式。文中还将ParaStor与Lustre、Ceph、GlusterFS、EMC Isilon、华为OceanStor 9000等主流系统横向对比分析分布式、SAN共享式、对称/非对称架构的各自适用场景帮助读者理解不同存储方案的技术边界。已有207人学习浏览适合作为存储选型、架构设计及了解国产分布式系统的入门资料。1. 曙光ParaStor云存储系统先想清楚它解决的是什么问题很多团队第一次接触中科曙光的ParaStor是抱着“给文件服务器扩容”的想法来的买一批服务器装上存储软件挂成一个大目录给计算节点用。这个理解不能说错但远远不够。ParaStor不是 SAN 的替代品也不是 NAS 的简单堆叠而是一套分布式并行文件系统核心目标是让几百上千个客户端同时读写同一份数据时聚合带宽和元数据性能还能撑得住。它解决的是传统 NAS 在计算集群场景里“单点扛不住、扩容要停业务、小文件卡成 PPT”的问题。这套系统最常见的落地场景是超算中心、AI 训练集群、气象海洋和生命科学这类数据密集型业务。它的主战场是大规模并行读写不是企业网盘。适合你的是如果你的业务里有几百 GB 的大文件要持续高带宽读写或者有几十亿个小文件要频繁打开和关闭这篇笔记能帮你把这个系统从选型到部署再到调优完整走一遍。它解决的不只是“文件放哪里”的问题而是“怎么放才能让计算效率不拖后腿”。2. 曙光ParaStor架构与部署形态并行文件系统不是“多台机器拼盘”2.1 控制节点、IO节点与元数据节点数据面与控制面分离ParaStor的架构里有三类核心角色搞混了后面很难排错。控制节点负责集群管理和状态监控相当于整个存储系统的“大脑”IO节点真正存数据数据块分散在这些节点上元数据节点维护目录树和文件属性所有文件的“户口”都归它管。数据面和控制面分离是它与传统 NAS 的根本区别传统 NAS 一台设备既是目录服务又是数据存储瓶颈集中在一个点上ParaStor 里元数据操作和数据读写走的是不同路径。这带来的直接好处是当你跑一个 MPI 程序一百个进程同时去写同一个大文件的不同区域时每个进程的写请求会被均衡分配到多个 IO 节点上每个节点的盘都在干活而不是其中一两块盘疯狂排队。这也是“聚合带宽”的由来。客户端进程越多、节点越多队列深度越深总的吞吐越接近所有节点和磁盘带宽的上限。还有一个常被忽略的设计ParaStor 内部采用副本或者纠删码的策略来保护数据。副本策略在性能和可用性上均衡适合多数通用场景纠删码更节省空间适合冷数据或者对容量利用率要求高的场景。你在初始化存储池的时候就要决定策略后续要调整只能迁移数据这个选择很关键后面避坑章节会单独说。2.2 两种部署形态全闪集群与混闪集群怎么选从硬件介质上看ParaStor 常见两种形态。全闪集群节点全部使用 SSD/NVMe适合需要高 IOPS 和高元数据性能的场景典型是 AI 训练和基因组分析混闪集群用机械盘做大容量数据盘配少量 SSD 做缓存或者元数据盘适合温冷数据为主、带宽要求大于延迟要求的场景。那么预算有限、想先跑通验证方案怎么办可以在测试环境用几台 x86 服务器装上 ParaStor 软件版数据盘用普通 SATA SSD 加机械盘组合。但这里要提醒测试环境下单块 NVMe 的突发性能往往很漂亮多客户端持续写入时性能会断崖下跌追根溯源大概率是网络或集群的节点数太少。所以测 ParaStor 时至少准备 3 个 IO 节点起步否则测出来的不是系统真实水平。2.3 硬件与网络规划一张表看清基础配置ParaStor 对硬件的具体需求在你拿到的实施文档里会有详细说明这里给你一个在实际部署中反复验证过的参照系角色最低配置建议说明控制节点2 路 CPU / 64GB 内存 / 双万兆网卡一般部署两个做 HA实际使用中压力不大元数据节点2 路 CPU / 128GB 内存 / NVMe 系统盘小文件性能取决于它的并发能力IO 节点2 路 CPU / 128GB 内存 / 多块数据盘数据盘数量直接影响节点带宽上限数据网络InfiniBand 或 25GbE/100GbE并行文件系统的性能上限由网络决定网络是整条链路里最容易被低估的一环。很多项目预算花在磁盘上最后发现瓶颈在网络侧客户端和存储节点之间用的是千兆交换机那不管后端多少块盘聚合总吞吐卡死在网关上。如果你的业务目标是跑模型训练、有持续的大文件读写网络这块不要压预算。2.4 曙光BMC/RAID配置装机前的硬件准备在装 ParaStor 软件之前每台服务器都要先完成底层的 RAID 和 BMC 设置。常见的做法是通过服务器管理口进入 RAID 配置界面把系统盘做成 RAID1数据盘根据存储池的设计决定是否做直通或者 RAID0。注意ParaStor 的 IO 节点上数据盘一般建议做直通或者 RAID0而不是 RAID5——文件系统层面已经有副本/纠删码保护底层再做 RAID5 既浪费性能又增加故障恢复的复杂度。控制节点的系统盘则必须做 RAID1防止单盘故障导致管理面挂掉。装机阶段常犯的错误是节点名称混乱或者 IP 规划冲突。建议在规划表里把每台机器的管理 IP、存储 IP、BMC IP 分开列清楚并保持和实际物理位置一致。别小看这一步后面找故障机、换故障盘、做固件升级时IP/机位对应关系乱套会浪费大把时间。如果你拿到的服务器配置了硬盘背板扩展多确认一下 SAS 线缆是否插紧、盘位号是否和系统识别一致比开机后踩坑更省事。3. 用ParaStor建一个最小可用的并行存储集群部署命令与参数3.1 安装前检查与环境清理现在进入可复现的部署环节。以下步骤以 Linux 系统为基础ParaStor 软件版安装完成后的初始化操作为例。先把所有节点的时间同步好这是分布式系统绕不开的第一步。时间不同步会导致元数据时间戳错乱后续排查起来非常痛苦。# 配置 NTP 时间同步第一行为控制节点其余为存储/计算节点 yum install -y ntpdate ntpdate 控制节点IP # 检查主机名解析IP 和主机名必须能互相解析 cat /etc/hosts # 192.168.1.10 parastor-mg1 # 192.168.1.11 parastor-io1为什么要先确认主机名解析ParaStor 集群注册节点时按主机名识别。如果 hostname 和 IP 对不上注册的节点信息混乱后面的图形界面里看到的节点状态会一路飘红。先确保每个节点的 /etc/hosts 内容一致再开始集群初始化。3.2 初始化GUI和创建集群登录 ParaStor Manager 管理界面之前先确认管理服务已启动。ParaStor 的初始化一般是命令行引导某些版本也支持 web 方式。最常见的是先执行初始化命令再通过浏览器访问 IP:# 进入管理软件安装目录执行环境初始化脚本 ./init_parastor.sh --node-type mg --node-id 1 # mg 表示控制节点node-id 是节点编号必须全局唯一 ./init_parastor.sh --node-type io --node-id 2 # io 表示 IO 节点每个节点的编号不能重复这个脚本干的最核心的事情是生成节点标识、配置内部通信、注册到集群。参数--node-type决定角色--node-id必须按你规划表里的编号填入后面换机器重新注册时如果沿用旧 ID可能和新节点日志里的旧记录混淆。如果初始化时提示失败看/var/log/parastor/下的日志多数是 IP 不通或者端口被占用。3.3 创建存储池和目录或卷导出集群节点注册进去后下一步是创建存储池定义数据放哪些节点上、用什么保护策略。用命令行或者图形界面都能做命令行操作对自动化和批量部署更友好:# 创建存储池选择 IO 节点并指定数据盘 parastor pool create --name data_pool \ --node-parastor-io1,parastor-io2,parastor-io3 \ --disk /dev/sdb,/dev/sdc \ --policy replica --replica-count 2 # policy 指定副本策略replica-count 2 表示存两副本 # 创建目录并导出给客户端挂载 parastor dir create /data/export parastor export create --path /data/export --pool data_pool--disk参数必须写每个 IO 节点上真正用于数据存储的盘符每个 IO 节点上都要有同样路径的裸盘。--policy replica的副本数选 2 还是 3取决于你的数据重要程度。副本数越高可用性越强但容量利用率越低如果副本数是 2单块盘故障后系统依然可用但建议尽快更换故障盘。3.4 Linux客户端挂载与POSIX权限落地服务器端导出完成后客户端安装 parastor client 包并挂载:# 客户端安装 client 包后加载内核模块 modprobe parastor # 挂载集群中的数据目录到本地路径 mount -t parastor -o rw,hard,intr,noatime \ 192.168.1.10:/data/export /mnt/parastor # hard 表示网络故障时客户端持续重试而不是报错 # intr 允许中断被阻塞的 IO 请求这里需要谨慎评估 # noatime 关闭访问时间更新减少元数据压力参数hard在 IO 持续重试时不会返回错误给应用层这在高可用场景是对的但如果某个存储节点彻底挂了且没有备用节点挂载点上的进程会卡住出现 D 状态进程难以清理。intr参数不是所有版本都支持配置前看内核模块是否接受该挂载选项。生产环境里我一般只加rw,hard,noatime,lazytimeintr不启用。挂载完成后POSIX 权限就可以正常使用了。chmod、setfacl、软链接、随机读写这些操作都和本地文件系统体验基本一致。这也意味着你在客户端上跑测试程序不需要修改 IO 代码直接把文件路径换成挂载目录即可。4. 曙光ParaStor的四个必调性能参数从带宽型到小文件型4.1 客户端挂载参数rsize/wsize与并发深度同一个 ParaStor 存储池在不同客户端挂载参数下测得的结果可能相差一倍以上。默认的传输块大小是针对兼容性设计的不是为性能设计的。跑大规模数据迁移或者高带宽读写时需要重新调整挂载参数:mount -t parastor -o rsize1048576,wsize1048576,max_read16777216,max_write16777216 \ 192.168.1.10:/data/export /mnt/parastor # rsize/wsize 设定单次读写请求的最大字节数 # max_read/max_write 设定单次 IO 的最大数据量单位字节rsize/wsize 设得越大大文件读写的效率越高因为网络往返次数减少了。但这不是无脑调大如果应用是大量小包随机读写1MB 的读写块反而不合适应该保持默认值 64KB 或者 128KB。测试方法很简单用 fio 分别测 64KB、512KB、1MB 三种块大小下的顺序读写带宽和 4KB 随机读 IOPS找出你业务 IO 模式下的最佳值。4.2 网络栈与HCA/网卡参数IB链路缓存与丢包ParaStor 部署在高性能计算环境时通常走 InfiniBand 网络。IB 链路默认的 MTU 是 2048 或者 4096如果因为交换机配置不一致掉到 1500大包传输会被拆包性能断崖下跌。检查当前 IB 链路状态和 MTU:# 查看 IB 链路状态确认 Physical State 为 LinkUp ibstat # 查看网络接口 MTU,确认是 2048 或 4096 而不是 1500 ip link show ib0 # 修改 MTU ip link set ib0 mtu 4096检查链路状态后还要关注丢包率。ibstat输出里有Rcv Errors和Xmt Discards只要这两个数值持续增长说明链路或者缓冲区有问题。常见解决方案是增大 HCA 的接收队列深度并调整内核网络参数:# 增大 TCP 缓冲区范围让大流量传输不因窗口过小而限速 sysctl -w net.core.rmem_max67108864 sysctl -w net.core.wmem_max67108864 sysctl -w net.ipv4.tcp_rmem4096 87380 33554432 sysctl -w net.ipv4.tcp_wmem4096 65536 33554432把参数写进/etc/sysctl.conf才能重启生效。不少团队部署时只调了块大小网络参数保持默认从 IO 节点到客户端之间的链路在深度队列下出现明显丢包表现为传输速率先冲到接近上限、然后突然掉到接近零周而复始。看带宽曲线基本就能判断出来。4.3 元数据与inode参数小文件场景的目录分片小文件场景的真正瓶颈往往不是数据盘而是元数据节点。几十万个两 KB 的小文件分布在几十个目录里每次打开关闭都要访问元数据节点压力全集中在那边。ParaStor 提供了目录分片的功能把一个逻辑目录的元数据分散到多个元数据节点上:# 设置目录分片数为 8将元数据操作分布到更多节点 parastor dir setattr /data/export --shard-count 8 # 分片数建议为 2 的幂最大不超过元数据节点总数 # 针对大量小文件的目录预分配 inode 空间 parastor dir setattr /data/export -max-inode 10000000 # 预估文件总数并预分配避免运行中因 inode 不足扩容分片数不是越大越好分片会把目录项分散到多个目录分片里若分片太碎单次ls操作反而要合并多个结果延迟变高。更关键的是在创建目录时就规划好业务跑起来后再改分片数元数据要重新分布期间文件访问可能短暂卡顿或者报错。4.4 MPI-IO/多进程场景的数据对齐与条带宽度对于 HPC 应用ParaStor 对大文件的条带化策略直接影响多进程并发写入是否产生严重的锁竞争。文件默认条带宽度如果和 MPI 进程的请求模式不匹配各个进程会反复抢同一批数据块。这时要看业务侧怎么配合:# 查看当前文件的条带信息确认条带宽度 parastor file getstripe /data/export/huge_file.bin # 新文件创建时指定条带宽度为 4条带大小为 1MB parastor file setstripe --stripe-count 4 --stripe-size 1m \ /data/export/input_dir/stripe-count的意义是把一个文件切分到几个 IO 节点上值设为实际应用并发写这个文件的进程数的一半到四分之一比较常见。stripe-size是每个条带块的大小一般设置和业务的单次写请求大小一致避免一个写请求拆成多次网络传输。注意这个配置只对新建文件生效已有文件要改必须重新拷贝这也是为什么大目录创建前就要把这个参数定好。5. 曙光ParaStor部署与使用的避坑指南四个常见问题与排查思路分布式存储的底层机制非常复杂部署和使用过程中遇到的大部分问题都有迹可循可能新手会以为是玄学实际上是参数配置、环境规划和底层机制的综合结果。下面这四条是我见过和踩过最多的坑按具体现象、原因和解决思路写清楚。5.1 节点掉盘后存储池状态正常但性能骤降现象某个 IO 节点上一块数据盘离线日志里没有报严重错误存储池显示正常但整体写入性能掉了一半以上。跑业务时客户端一侧的写延迟明显升高。原因数据盘掉线后系统进入降级写模式。写请求要同时写两个副本其中一个副本所在盘已经不在了那写入操作只能在内存里暂时标记、等待副本重建。而重建过程本身就是高消耗的后台任务它会持续占用磁盘和 CPU。表面上看存储池没有报错实际所有 IO 都在为数据重建让路。解决第一时间定位掉线盘确认是物理故障还是链路松动。物理故障直接换盘让系统快速切回正常副本状态。换盘时注意核对新盘容量必须不小于原盘。链路松动就重新插拔并检查背板和线缆。重点是判断掉线原因后马上处理拖得越久重建期间的风险窗口越大。5.2 客户端挂载后ls卡顿数据传输时断时续现象客户端挂载成功跑大文件拷贝时速度每秒能冲到几百 MB但跑到一半突然掉到几十 KB过一会儿再恢复。输入ls命令要卡好几秒才返回结果。原因这是标准的网络丢包和元数据拥塞混合症状。先看网络是否丢包再看客户端和元数据节点之间是否有防火墙或者安全策略在拦截部分 ICMP 或者大包。另一个常见原因是挂载参数里的intr或者hard选项配合不当网络瞬断时客户端内核模块反复重发请求卡住整个进程。解决先在客户端 ping 存储节点看延迟是否稳定再用ibstat或者ethtool -S查丢包计数。确认网络正常后检查挂载参数去掉intr。如果ls仍然卡顿用strace -c ls /mnt/parastor/看卡在哪个系统调用上判断是网络还是元数据节点响应慢。5.3 小文件目录统计耗时极长IOPS上不去现象业务侧要生成和读取几十万个几百 KB 的小文件客户端上并发 16 个进程处理测出来的 IOPS 只有预期值的五分之一。文件内容不大磁盘远没有写满。原因小文件操作的瓶颈在元数据节点和客户端内核模块之间的往返开销。每个文件打开、关闭、更新属性都要和元数据节点交互而客户端默认的元数据缓存相对有限频繁缓存失效导致每个系统调用都走到网络那边。另外文件分布在多个 IO 节点上时请求很快分散到不同节点上来回跳转。解决目录分片加上预分配 inode 都不能省这几个动作需要在业务落地前做完。同时检查客户端侧是否启用了元数据缓存并把目录分片数调整到和元数据节点数匹配不能毫无根据地把分片开到 16 或者 64。几个操作参数说起来都不复杂但要在单目录百万文件的压力测试下反复验证。5.4 格式化或换盘操作后的重启失效现象某次服务器重启后系统识别不到原来的存储池提示部分 IO 节点离线。RAID 卡和背板都没有报错更换故障盘之后重启系统发现存储池找不回来。原因大部分情况是数据盘的盘符发生变化。Linux 在重启或者新盘接入后/dev/sdb可能变成/dev/sdc系统按盘符找设备但对不上就认为节点离线。另有一类原因是底层做了 RAID 或者磁盘直通配置重启后 RAID 卡配置丢失导致盘阵没有被正确识别。解决部署时不要用裸盘符改用磁盘的 UUID 或者 WWN 来标识同时检查 RAID 卡是否有电池或者电容保护防止重启后配置丢失。操作顺序上也要养成习惯任何涉及格式化或换盘的变更先把存储池的状态和配置文档备份好再操作。这个习惯能给你一颗后悔药真出问题时不至于从零开始重新配置整个集群。6. 用fio和ior给你的ParaStor做一次体检验证方法与应用落地部署完成后的验证阶段很多人只是随便跑一下dd看速度但这样测出来的结果基本只有参考价值无法对系统的能力上限形成准确判断。用 fio 测单客户端随机读写和 IOPS用 ior 测多客户端聚合带宽更可靠。这是两个开源工具在 HPC 领域用得最多。先测单客户端的基准吞吐排除并发干扰确认挂载参数是否合理:# 顺序写测试块大小 1MB,队列深度 16 fio --namewrite-test --directory/mnt/parastor \ --rwwrite --bs1m --size10G --iodepth16 \ --numjobs1 --group_reporting # 4K 随机读测试观察 IOPS 和延迟 fio --namerandread-test --directory/mnt/parastor \ --rwrandread --bs4k --size2G --iodepth32 \ --numjobs4 --group_reporting跑完后看两个关键指标顺序写带宽是否接近预期值以及高队列深度下的平均延迟是否稳定。单客户端测完再用 ior 模拟 MPI 多进程并发:# 用 16 个进程同时写一个共享文件每个进程写 1GB ior -a POSIX -i 1 -t 1m -b 1g -s 1 -F \ -o /mnt/parastor/test_file -g -v # -t 传输大小, -b 块大小, -F 表示每个进程写独立文件如果 ior 聚合带宽远低于单客户端带宽乘以节点数量优先怀疑网络瓶颈和条带配置。把输出里的延迟分布对照一下就能定位问题在水线上游还是下游。注意测试文件一定要删掉或者覆盖到专门的测试目录避免把存储空间撑满。ParaStor 这套系统从选型到上线我最大的感受是它不是一个开箱即用的玩具也不是一个完全黑匣子的商业设备你对 Linux 存储协议栈和网络的理解都会体现在最终性能表现上。先把架构吃透再动手部署出问题时一步步从日志和数据中定位原因而不是盲目重启或重刷系统。这套做事方式比任何具体参数都管用希望帮到你。本文还有配套的精品资源点击获取