企业官网建设流程全解析

简介：一份曙光ParaStor云存储系统的解决方案文档，面向存储架构师、IT运维及售前技术人员，用来说明海量非结构化数据场景下分布式文件系统的选型与架构要点。PDF共1个文件，约3.39MB，内容精炼，便于快速通读。内容以ParaStor为主线，展示了其Scale-out集群NAS形态、非对称式元数据与数据分离架构，以及索引控制器、数据控制器可扩展的硬件规格；同时对比了Lustre、Ceph、GlusterFS、EMC Isilon等常见分布式系统，梳理了对称/非对称、共享式/分布式等核心概念。文档还穿插了全球与中国存储市场趋势、IDC排名和ParaStor产品形态介绍，适合用产品学习、方案汇报或撰写技术对比材料。已有208人学习，对想快速建立存储知识框架的读者有一定参考价值。

1. 先说结论：ParaStor 不是一台大号 NAS，而是一套把元数据和数据分开跑的分布式文件系统

很多刚接触曙光 ParaStor 的人，第一反应是把它当成一台“大号 NAS”。我自己接过一个项目，客户用传统 NAS 扛大数据训练集的目录流，文件一多，ls 都卡，最后换了 ParaStor 才缓过来。差别不在硬件多贵，而在 ParaStor 是非对称式集群 NAS——元数据走独立的索引节点，数据走数据节点，两边各干各的。这份《曙光 ParaStor 云存储系统.pdf》我前后翻了三遍，把产品规格、架构对比和部署参数都过了一遍，写给正在调研分布式存储、或者想搞懂非对称架构好在哪的人看。这套系统 2015 年已经做到中国区 NAS 市场第一，累计销售容量 260+ PB，不是 PPT 里跑出来的数字。

2. 架构拆解：索引节点与数据节点分离，扩容边界在 128 还是 4096？

2.1 为什么是非对称式而不是全对称式

分布式文件系统里，争论最多的就是“对称性”。全对称式代表是 Ceph 和 EMC Isilon，集群里每个节点既能处理元数据也能处理数据，所有节点功能对等。这种设计在小规模下很舒服，几台节点就能撑起一个分布式存储池，单客户端性能也不差。但问题是同一个节点上，元数据进程和数据进程会互相抢 CPU、抢内存、抢磁盘 IO。尤其在做数据重构的时候，节点既要搬运数据块，又要同步元数据信息，两边都在吃资源，系统整体性能经常被拖到很难看。节点数量一上去，元数据同步的复杂度是指数级增长，这也是为什么全对称式系统在超大集群里容易出现性能拐点。

ParaStor 走的是非对称式路线。元数据服务单独放在索引节点上，数据节点只管文件内容读写，两边物理隔离、职责分离。好处是清晰的：元数据节点性能不会被数据重构拖垮，数据节点也不用分心处理目录树和文件属性，各自服务能力都能顶到很高。故障也是隔离的——某个数据节点挂了，不影响索引节点对外提供目录查询服务；反之亦然。缺点是哪怕你只需要 10TB 容量，也必须先配索引节点，小规模下显得有点贵。但部署规模一旦超过几十个节点，这套架构的优势就盖过成本劣势了。

2.2 三层架构：管理控制器、索引控制器、数据控制器各管什么

ParaStor 的逻辑架构分三层：应用协议层、数据处理层、硬件节点层。硬件节点层是三类角色——管理控制器、索引控制器、数据控制器。

• 管理控制器：负责集群配置、WebUI 管理、告警监控，相当于整个系统的控制面。生产环境我一般建议保持双活，避免管理面单点。
• 索引控制器：负责元数据服务，包括文件系统的目录树、文件属性、权限、配额。它支持 2 到 128 个节点横向扩展，对外体现为全局命名空间。
• 数据控制器：负责实际的文件数据存储和读写。支持 3 到 4096 个节点，数据盘按条带分布在多个数据节点上，单个客户端读写时也会从多个节点并行取数据。

这个三层设计直接决定了系统的两个关键属性：并行访问和线性扩展。所谓并行访问，是指一个文件的数据块被条带化打散到多个数据节点上，多客户端并发读取时每个客户端都能从多个节点同时拿数据，聚合带宽自然高；线性扩展是指加数据节点，聚合带宽和容量基本按比例上涨。

2.3 控制器规格与扩容边界

从产品规格来看，ParaStor 标准版的索引控制器支持 2~128 个，数据控制器支持 3~4096 个，数据控制器硬件规格有 2U24、4U24、4U36、5U86 四种盘位。注意一个细节：索引控制器的数字上限是 128，数据控制器的上限是 4096，这个差距本身就是非对称架构在横向扩展能力上的体现——元数据服务的扩展难度远高于数据存储，能做到 128 个索引节点已经是很高的水平。

扩容时常见做法是批量增加数据控制器，系统会自动做数据均衡，把已有数据逐步迁移到新节点。这个过程不需要业务停机，但会有后台数据迁移流量，所以实际运维时要控制扩容节奏，不要在业务高峰期大批量加节点。单系统最大可构建 EB 级存储空间，这个不是口号——原文提到 2010 年单一系统最大已经做到 16PB，2015 年累计交付容量 260+PB，说明大集群在真实生产环境里跑过。

2.4 数据冗余：多副本与纠删码怎么选

ParaStor 的索引控制器是双活架构，避免元数据单点；数据冗余支持多副本和纠删码两种方式，原文明确给了推荐组合：双副本（推荐）、2+2:1 纠删码。

双副本的优点是简单直接，每个文件写两份，任意一份丢失都能用另一份恢复，读性能也好，空间利用率 50%。缺点是存储效率低，1PB 有效数据实际占用 2PB 物理空间。纠删码的 2+2:1 模式空间利用率明显更高，适合海量数据以降低成本，但写入时需要计算校验块，重构时需要的 IO 更多，对节点的计算和网络都有额外压力。

我的选择依据是：关键业务目录、并发写要求高的数据用双副本；冷数据、归档数据、监控视频这类只写一次很少修改的数据用纠删码。另外原文提到两个容易被忽略的功能——磁盘分组和节点分区。磁盘分组是把一个节点的多块盘划分成不同冗余组，单盘故障只影响本组；节点分区是逻辑上把集群切成多个故障域，副本或校验块尽量分布在不同分区，避免一个机柜断电带走所有副本。

3. 部署落地：从节点选型到存储策略的关键参数

3.1 数据控制器选 2U24 还是 5U86

数据控制器的盘位型号直接决定了容量密度和运维方式。ParaStor 标准版给了四种规格：2U24、4U24、4U36、5U86。我按实际项目经验给你一个选型参考：

我的习惯是：在线业务为主的集群，首选 2U24，因为单机故障影响面小，性能和容量平衡；归档类业务用 5U86，机柜利用率最高。另外原文还提到 ParaStor 双节点系统和视频监控专用存储系统——双节点是 2U12 和 4U36 盘位，不支持节点扩容；监控专用是 4U24 和 4U36，单路服务器、32GB Cache、3.5 英寸 HDD、1GbE/10GbE 网络，定位非常明确：只服务视频监控码流。

3.2 存储策略配置：副本、纠删码与故障域

存储策略是在创建文件系统或存储池层面配置的，不是每个目录单独去改。常见做法是先把集群划分出多个存储池，不同池用不同冗余策略，再把业务目录挂载到对应池上。

配置要点：

• 副本策略：生产环境我推荐至少双副本，副本数不要超过故障域数量。如果节点分区只分了两个，副本数设成 3 会导致有些副本写不进去，整个文件系统进入降级模式。
• 纠删码策略：以 2+2:1 为例，实际是每 2 个数据块配 2 个校验块外加 1 个局部校验，空间利用率约为 4/5。如果底层盘位是 4U36 这样的高密机型，机械盘单盘容量大，校验块占用的额外空间要提前算进容量规划。
• 磁盘分组：单节点内按 RAID 或磁盘组再把数据盘分几个冗余组，目的是缩小单盘故障的恢复范围。我之前遇到过整节点 36 块盘不做分组，坏一块盘触发全节点重构，恢复时间长得吓人。
• 节点分区：逻辑上划分故障域，把同一文件的不同副本或编码分片放到不同分区。配置节点分区时，分区数量要大于副本数，否则冗余策略降级。

3.3 对外接口：POSIX、NFS、CIFS、FTP、HTTP、HDFS 怎么配

ParaStor 的协议层支持 POSIX、NFS、CIFS、FTP、HTTP、HDFS 多种接口。同一套底层存储，不同客户端按不同协议接入。实际上每个协议需要在管理控制台上配置虚拟 IP 和授权规则，不是装完系统就自动全部开放。

配置时最容易被忽略的是网络规划。管理网、业务网、存储内部网严格分开，至少做到业务网和存储网隔离。存储内部节点间通信走专用网段，带宽建议不低于 10GbE，否则节点一多，内部同步流量会跟业务流量抢带宽。

3.4 高级功能：WORM、配额和自动精简配置

原文列了一批高级功能：分级存储、配额管理、目录分片、自动精简配置、远程同步、数据归档、WORM、QoS、自动功耗控制。这些功能不是每个项目都用得上，但有三个我会在交付时根据场景强制打开或关闭。

• WORM（Write Once Read Many）适合合规归档场景，比如金融票据影像。文件写入后只读不可修改，防篡改。但注意：一旦开启 WORM，文件删除和覆盖都会受限，测试阶段不要急着打开，否则后续做清理会很痛苦。
• 配额管理适合多租户共享集群的场景。我的建议是业务上线前就把配额设好，而不是等用户把空间跑满再收紧。上线后突然限制配额，业务方的投诉会堆成山。
• 自动精简配置（Thin Provisioning）适合虚拟化和云平台场景，业务方申请多少容量都先记账，实际占满多少才消耗物理空间。但物理存储水位一旦超过 80%，需要及时扩容，否则会出现“申请的容量没超、物理盘满”的尴尬。

4. 典型场景与选型：不是所有非结构化存储都该上 ParaStor

4.1 高性能计算与科研计算：聚合带宽比单流延迟更要紧

ParaStor 最初的立足点是高性能计算。原文提到的应用场景包括科研计算，这类负载的典型特征是大量计算节点同时读写同一个文件系统，每个节点各写各的结果文件，同时又频繁读取公共数据集。传统 NAS 在这类场景下容易遇到瓶颈：单控制器的网络带宽撑不住几百个计算节点的并发访问。ParaStor 的多数据节点条带化恰好匹配这种并发写模式，每个计算节点写入时都会把数据分散到多个数据控制器上，聚合带宽可以随着数据节点增加而线性扩展。

单流延迟方面，ParaStor 因为数据要经过网络和分布式协议处理，单客户端读写延迟会比本地盘或全闪 SAN 高，但它卖的是并发吞吐和扩展能力。如果你评估的场景是“几十个 GPU 节点同时读训练数据”，那看重的应该是聚合带宽能不能撑住，而不是单流延迟是不是多了几毫秒。

4.2 视频监控：专用机型是成本优先的解

视频监控有两个特点：写入数据流是顺序的，数据量大且增长快，但对随机读性能要求不高。2016 年 10 月，曙光针对这个细分市场专门推出了视频监控专用存储系统。

这套系统用的是单路服务器，主频和性能比标准版数据控制器低，4U24、4U36 盘位，32GB Cache，3.5 英寸 HDD，提供 1GbE 和 10GbE 网络接口。定位非常直白：仅作为存储资源池，存储节点上不跑视频业务软件，成本比标准版明显低。如果你正在为平安城市、园区监控这类项目做选型，预算紧张且业务就是纯粹的码流写入，这个机型价值很高；但千万注意它只适合顺序码流，不适合跑数据库这类随机 IO 业务。

4.3 双节点系统：中小容量场景的专用选择

ParaStor 双节点系统是另一条产品线：双节点对称存储架构，2U12 或 4U36 盘位，不支持扩容。官方推荐用于容量小、大文件存储场景，典型市场是金融票据和医疗 PACS。

双节点系统的定位和我前面讲的标准版完全不同。标准版是 Scale-Out 架构，靠加节点扩展；双节点是固定两个节点，内嵌 ParaStor 组件，提供 POSIX、NFS、CIFS、FTP 和 RESTful 接口，支持双副本（推荐）和 2+2:1 纠删码。选择这个机型前必须确认业务符合两个前提：一是容量预期不会增长到单节点上限之外；二是业务以 1MB 以上大文件为主。原文明确提醒：小文件存储、有扩容要求不建议用双节点。

4.4 选型对比：标准版、双节点、监控专用怎么选

5. 避坑手册：部署 ParaStor 后五个常见问题与排查思路

5.1 小文件一多，目录遍历和创建操作就卡成幻灯片

现象：业务端大量创建、删除小文件（几百 KB 甚至几十 KB），客户端执行 ls 大目录要几十秒，文件写入速率上不去，但磁盘利用率并不高。

原因：小文件的元数据开销远大于数据本身。每次创建文件都要往索引节点写一条目录项，海量小文件会把索引节点的元数据压力直接打满。数据节点闲着，索引节点累死。

解决：优先从应用层解决——把零碎小文件合并成大文件（打包或按业务维度聚合）再入库；其次利用 ParaStor 的目录分片能力，把一个大目录按规则拆成多个分区，分散单目录的元数据压力；最后才是加索引节点，扩大元数据服务能力。

5.2 纠删码配置下坏了一块盘，重构期业务带宽被拖垮

现象：某块数据盘故障，触发纠删码数据重构，重构期间业务读写明显变慢，严重时业务 IO 延迟翻了数倍。

原因：纠删码重构不是简单拷贝副本，而是需要读取参与编码的所有数据块和校验块，再重新计算并写入新数据块。这个过程的 IO 量和计算量比副本重构大得多，如果重构任务和业务高峰期重叠，很容易占满节点带宽。

解决：尽量把维护窗口放在业务低谷，手动触发重构或调整重构并发参数，避免系统自动检测到故障后立刻全速重构；重构期间临时降低客户端并发写入量，必要的时候暂停非核心业务。经历过一次就会发现，配置纠删码时提前评估重构带宽比选策略本身更重要。

5.3 扩容后发现新节点容量空闲，老节点却快被写满

现象：新加的数据节点长时间处于低水位，新增业务数据仍然写到旧节点上，集群容量分布明显不均。

原因：ParaStor 的数据自动均衡是按水位和策略触发的，不是立即生效。均衡迁移需要时间，如果触发条件设置得保守，新节点可能很久都等不到数据迁过来。

解决：扩容后主动检查均衡任务状态，确认自动均衡开关已经打开；批量扩容而不是零星加节点，一批至少加 3~4 个节点，数据分布会更均匀；扩容期间不要立刻跑大压力业务，等均衡任务完成再上量。

5.4 拿视频监控专用机型去跑数据库或虚拟化，随机 IO 延迟直接崩

现象：在视频监控专用存储节点上建了数据库实例，或者跑虚拟机磁盘镜像，结果随机读写延迟高到业务无法接受，性能远差于同等配置的标准版节点。

原因：监控专用机型的定位是顺序码流写入，用了单路低主频 CPU 和面向读写的 Cache 策略，硬件和软件都是按视频监控场景优化的，并不适合随机 IO 密集的小块写入。

解决：把数据库和虚拟化业务迁回标准版数据控制器或双节点系统；监控专用集群只承载视频码流。机型定位在选型阶段就要定清楚，指望同一套硬件既便宜又能跑所有负载，最后两边都做不好。

5.5 节点数比副本数还少的时候，文件系统写入失败

现象：集群只有两个节点，却把副本数改成 3，结果业务写入提示“无足够空间”或“副本不可用”，容量明明显示还有富余。

原因：副本策略要求每个副本落在不同故障域（节点分区）里。故障域数量小于副本数时，系统无法放置所有副本，出于数据安全考虑会拒绝写入。

解决：副本数必须不大于节点分区数量。小规模集群老老实实用双副本，或者明确分区后再配置副本策略。配置完成后可以用df和系统“文件系统信息”界面检查实际可用容量，确认副本数生效。

6. 交付前验证：一套能说服甲方的性能测试流程

6.1 聚合带宽：fio 的跑法要避开缓存陷阱

验证聚合带宽时，我习惯用 fio 顺序写和顺序读分别测。关键点是 direct=1 绕过操作系统页面缓存，文件大小要大于内存容量，否则测出来的是缓存性能而不是存储性能。

# 顺写测聚合带宽，单客户端 fio -name=write_test -filename=/mnt/parastor/fiotest.dat \ -iodepth=16 -numjobs=8 -size=64G -direct=1 \ -rw=write -bs=1M -group_reporting -time_based -runtime=300 # 顺读测聚合带宽，单客户端 fio -name=read_test -filename=/mnt/parastor/fiotest.dat \ -iodepth=16 -numjobs=8 -size=64G -direct=1 \ -rw=read -bs=1M -group_reporting -time_based -runtime=300

bs=1M模拟大文件顺序流，numjobs=8让单个客户端开 8 个并发进程去压带宽，iodepth=16控制每个进程的队列深度。跑完后看 aggregate 行的带宽值，这就是单客户端的聚合能力。要验证集群级带宽，多开几台客户端同时跑同一组参数，汇总各客户端结果。

6.2 元数据性能：mdtest 别只测创建

小文件性能用 mdtest（Intel 开源的那版）测。注意别只跑“创建”测试，得把目录创建、文件创建、stat、删除都跑一遍，否则结果虚高得没法看。

# mdtest 测试小文件元数据性能，覆盖 create/stat/delete mdtest -d /mnt/parastor/mdtest_bench -n 50000 -i 3 \ -C -T -r -v > /tmp/mdtest_result.txt

-n 50000表示每个测试目录创建 5 万个文件，-i 3跑 3 轮取稳定值，-C测创建，-T测 stat，-r测删除。重点看每秒钟的文件操作数（ops/s）。如果创建、stat、删除三项都跑完，这个数据才能真正反映小文件场景的上限。顺序跑完这三项再对比原始文档里宣传的元数据性能数据，通常会有差距，不奇怪，端到端验证本来就是看真实环境能力。

6.3 扩容验证：加节点前后对比聚合带宽

交付阶段加节点扩容验证比单点性能测试更有说服力。我的血泪经验是：扩容验证必须看两个指标，一是聚合带宽是否随节点增加而接近线性提升，二是扩容期间业务是否有明显中断。

实际操作时，先记录扩容前的双客户端聚合带宽，再执行节点添加并等数据均衡结束，然后重新跑同样参数的 fio 和 mdtest，对比前后结果。如果带宽有提升但明显低于节点比例，优先怀疑网络瓶颈——节点多了，跨节点数据协调流量增加，存储内部网的带宽可能不够。这种情况我一般先升级存储网到 25GbE，再重新评测。从那以后，我每次验证分布式存储交付，都会强制走一遍“基线测试→扩容→复测”的流程，数据和结论才敢写进验收报告。希望帮到你。

本文还有配套的精品资源，点击获取