企业官网建设流程全解析

简介：曙光 ParaStor 云存储系统是一份面向存储架构师、IT运维与云计算从业者的解决方案文档，围绕大规模非结构化数据的分布式存储需求，系统梳理了ParaStor的市场地位、产品规格、技术特性与典型应用场景，也点明了其在中国区NAS市场的领先表现。PDF共1个文件，压缩包3.39MB，正文内容涵盖存储市场趋势、Scale-out NAS发展、分布式文件系统产品分类，以及ParaStor与Lustre、Ceph、GlusterFS、EMC Isilon、华为OceanStor 9000等产品的架构对比。其中重点剖析了分布式非对称架构的优势，即元数据节点与数据节点分离带来的故障隔离与横向扩展能力，并结合分布式 vs SAN共享式、全对称式 vs 非对称式两组维度，帮助读者理解不同存储架构的适用边界；同时介绍了EB级单一存储空间、双节点高可靠设计及视频监控专用存储形态。已有207人学习下载，适合正在做存储选型、方案设计或技术预研的读者，可作为了解国产集群NAS产品及其在科研计算、视频监控、云计算平台落地思路的入门参考。

1. 存储市场向Scale-Out转向，ParaStor云存储系统为什么值得拆解

看2014-2018年的存储市场预测数据，传统阵列从61亿美元掉到18亿，Scale-Out NAS从19亿涨到39亿，存储行业的主线已经很清楚了：过去“把单机框做大”的玩法，正在让位给“一堆服务器组成分布式文件系统”的玩法。曙光ParaStor是这条线上国内走得比较早的产品，2015年中国区NAS市场IDC排名第一，累计销售260+PB。它不是传统NAS或SAN，而是把索引控制器和数据控制器分开的分布式文件系统，支持POSIX、NFS、CIFS、FTP等协议，目标是把非结构化数据放进一个可扩展到EB级的命名空间里。HPC、视频监控、云平台这类场景的运维和存储选型人员，可以把它当成理解分布式NAS的一个坐标系。

2. 分布式文件系统分类与ParaStor非对称架构的核心设计

2.1 先分清文件系统、块存储、对象存储

分布式存储产品并不是同一个东西。分布式文件系统保留POSIX语义，支持目录树、文件锁、属性，能直接用mount挂到服务器上；分布式块存储一般以内核模块或QEMU驱动形态提供裸设备，典型代表是Ceph RBD和AWS EBS；对象存储通过REST接口提供上传下载，但很难支持文件的打开和原地修改。ParaStor属于分布式文件系统，它提供NFS、CIFS、POSIX接口，同时又带HTTP和HDFS入口，这说明它在设计上兼顾了传统POSIX业务和大数据访问路径。

2.2 主流分布式文件系统的分类矩阵

要理解ParaStor，需要先看两个维度：后端数据访问方式是分布式还是SAN共享式，协作管理角色是对称性还是非对称性。共享式表示集群节点通过SAN网络访问同一套后端存储，分布式表示每个节点只访问本地磁盘，跨节点取数要走网络；对称性指集群里每个节点同时承担元数据和数据服务，非对称性则把元数据节点和数据节点分开。

常见产品的架构归类如下。

ParaStor在表里的位置很明确：分布式加非对称。它与Lustre同属于非对称阵营，但Lustre依赖后端SAN，ParaStor走的是本地盘加以太网，因此容量扩展更自由，客户端也不用接入SAN交换机。

2.3 ParaStor非对称架构如何拆解元数据与数据路径

访问ParaStor一次典型的文件读请求，逻辑上是这样分流的：

def read_file(path, offset, length): # 第一步：先找索引控制器拿元数据 meta = index_controller.lookup(path) # 第二步：拿到block map后，直接找对应数据控制器 blocks = meta.block_map(offset, length) for controller_id, local_path in blocks: data = data_controller.read(controller_id, local_path) return data

这段伪代码说明了一个关键点：客户端只需要在元数据查询阶段接触索引控制器，后续数据读取直接与数据控制器通信。数据流不经过索引节点，因此大带宽读写不会打满元数据节点CPU。同时，索引控制器和数据控制器故障相互隔离，单个数据控制器宕机不会让目录服务不可用，这是非对称架构相对对称架构最明显的好处。

对称式系统如Isilon、OceanStor 9000，所有节点功能对等，小规模时成本更低，但如果某个节点同时跑元数据服务和数据服务，在高负载或数据重构时，节点内进程容易互相抢占CPU和内存。非对称架构在同等规模下需要额外配置索引节点，小集群成本不占优，不过到了数百节点规模，元数据与数据分离带来的稳定性收益会明显放大。

2.4 与SAN共享式架构的取舍

SAN共享式系统也有自己的优势：客户端直接访问后端块设备，IO路径短，时延低，单客户端性能高。问题在于，所有客户端都必须处在SAN环境中，而且容量受SAN扩展能力限制，这在FC-SAN场景下尤其明显。ParaStor选择本地盘加网络交换，每个数据控制器只访问本机磁盘，新增节点就是新增存储带宽，因此更适合需要高聚合吞吐和EB级容量的场景。

代价是IO路径变长，单流延迟高于SAN共享式。ParaStor的定位也决定了它不会去抢低延迟OLTP市场，它更擅长的是科研计算、视频监控这种顺序读写多、并发带宽大的工作负载。

3. 节点规划与协议挂载：ParaStor云存储系统接入实操

3.1 三种硬件形态怎么选

ParaStor的产品形态比一般分布式文件系统更细，至少分三套。

双节点系统是一个独立分支，它内嵌ParaStor软件，提供POSIX、NFS、CIFS、FTP和RESTful接口，冗余策略以双副本为主。它的局限性很明确：不能扩容，硬件规格固定，更适合容量需求较小、以大文件为主的场景。如果业务有在线扩容要求，或者存在大量小文件，这套方案就不是好选择，我一般会直接劝退。

视频监控专用存储是另一种裁剪形态，使用单路服务器，配置32GB Cache和千兆或万兆网卡，整体成本压得很低。它的定位是单纯存储资源池，上面不跑视频业务软件，适合监控点位多、写入压力大但读取频率低的场景。

3.2 最小集群规划与网络划分

一个可用于生产的最小通用ParaStor集群，我一般建议这样规划：

管理网和业务网要分开。管理网只跑WebUI和监控告警，业务网负责客户端与存储节点之间的数据流量。索引控制器双活需要独立心跳链路，避免脑裂后同时提供元数据服务。数据控制器不需要额外SAN网络，因为每台节点只访问本地磁盘，节点间数据迁移走业务网络。

3.3 在线扩容与数据均衡

通用ParaStor支持在线扩容，索引控制器可以扩展到128个，数据控制器可以扩展到4096个。扩容时把新节点加入存储池，系统会自动迁移一部分已有数据到新节点，整个过程不需要业务停机。数据均衡本质上是后台迁移任务，对业务网和磁盘IO都有影响。

我踩过的一个坑是：为了快速扩容，一次加入十几个数据控制器，结果重建数据分布时网络队列被打满，正常业务读写延迟升高。现在我的做法是每次先挂1到2个节点，观察网络流量和磁盘繁忙度，稳定后再继续加。

3.4 客户端接入：NFS与CIFS挂载参数

ParaStor对外提供POSIX、NFS、CIFS、FTP、HTTP、HDFS等协议。Linux客户端最常见的是NFS挂载：

mkdir -p /mnt/parastor mount -t nfs -o vers=4.0,rw,hard,bg,timeo=600,retrans=2,noatime \ 192.168.10.11:/para_share /mnt/parastor

参数含义：vers=4.0避免NFSv3在锁语义上的额外复杂度；hard表示网络恢复后客户端自动重试，不返回IO错误；bg让挂载在失败时转入后台重试，避免开机流程卡死在挂载点；timeo=600和retrans=2控制超时与重传策略；noatime减少元数据写操作。高会话并发场景，还可以看内核版本是否支持nconnect=4，给单挂载点建立多条TCP连接。

Windows或Linux下走CIFS时，挂载参数略有不同：

mount -t cifs //192.168.10.11/para_share /mnt/parastor \ -o username=stor_user,vers=3.0,rsize=1048576,wsize=1048576,actimeo=600

vers=3.0是为了兼容现代SMB3协议；rsize和wsize都设成1MiB，避免小IO缓冲导致吞吐上不去；actimeo=600把客户端属性缓存时间调长一点，减少stat和open阶段的往返次数。

4. 用fio和mdtest验证ParaStor性能，并规避数据重构风险

4.1 用fio验证聚合带宽

拿到一套ParaStor环境，第一步先验证它能给到多少聚合带宽。我常用的fio命令如下：

fio --name=seq-read --rw=read --bs=1M --size=32G \ --iodepth=32 --numjobs=16 --direct=1 \ --directory=/mnt/parastor --group_reporting

这个测试把16个进程同时往挂载点做1MiB顺序读，每个进程生成32GB文件，总计512GB流量。--direct=1绕过客户端page cache，保证压的是存储后端而不是缓存。如果带宽随numjobs增加接近线性增长，说明数据控制器扩展能力有效；如果再加进程带宽不再增长，优先检查客户端网卡是否打满、交换机链路是否做了端口限速，然后再看索引控制器CPU。

4.2 小文件性能与目录分片

大带宽不是分布式文件系统的唯一指标，小文件场景才是最容易暴露元数据短板的地方。用mdtest做元数据压力测试：

mdtest -d /mnt/parastor/mdtest -n 100000 -t -f -C

-d指定测试目录，-n 100000表示每个线程创建十万个条目，-t让每个线程使用独立子目录，-f构造文件树，-C在创建完成后保留文件。观察每秒创建文件数和删除文件数，如果百万级文件创建只有几十个OPS，问题通常出在索引控制器CPU、元数据缓存命中率和网络小包丢包。

输入里提到的“目录分片”是ParaStor优化单目录元数据热点的手段。文件数量大的时候，把一个大目录拆散到多个索引节点或后端分片上，可以避免所有客户端都去抢同一份目录条目。新项目上线前，我会先确定单目录文件数预期，超过百万级别就直接开启目录分片。

4.3 索引控制器双活的切换验证

ParaStor的索引控制器是高可靠双活架构，但双活不是配置完就一劳永逸。业务低峰期做一次切换验证，用管理端或直接断开主索引控制器心跳，观察VIP是否漂移到备用节点。

ping -c 4 192.168.10.11 showmount -e 192.168.10.11

如果使用NFS，客户端挂载参数里没有bg或hard，切换期间IO可能直接报错。hard模式会让客户端持续重试，恢复后自动继续，业务侧看到的只是一次卡顿。切换时间超过分钟级时，先查客户端timeo设置，600的超时会让等待被拉长，在双活切换场景下把timeo降到200到300更为合理。

4.4 数据重构和纠删码的运维影响

数据重构是分布式存储最常见的性能杀手。一个数据控制器宕机，系统要把它的数据补回去，副本模式下只是重新复制，纠删码模式下还要做校验块计算，CPU消耗更大。ParaStor支持磁盘分组和节点分区，目的就是限制故障域，避免一个节点上多块盘同时损坏导致数据不可用。

我一般会在管理界面上把重构带宽限制在一个可控范围，比如业务低峰期放开，白天限制在总带宽的20%以内。纠删码适合大文件和冷数据，副本适合小文件和延迟敏感业务。以下是冗余策略的选择经验。

5. 数据保护与策略配置：副本、纠删码、WORM和配额

5.1 冗余策略的落地方式

在ParaStor上配置冗余，通常不是在客户端做的，而是在存储池创建时选定数据保护策略。双副本是推荐默认项，因为实现简单，重构压力小，性能损失低。三副本用于关键数据，但容量成本很高。纠删码节省空间，但重建数据要消耗更多CPU和网络带宽，且参数的N和M直接决定冗余能力。

创建存储池时如果拿不准，就按数据冷热来分：热数据放副本池，冷数据放纠删码池。不要图省事把全部数据放在一套策略下，否则容量和性能至少牺牲一头。

5.2 WORM合规验证

WORM这个特性在金融票据和医疗影像场景非常关键，它保证文件被写入后在保留期内不能被修改或删除。验证方式不复杂：

mkdir -p /mnt/worm mount -t nfs 192.168.10.11:/para_worm /mnt/worm touch /mnt/worm/test.txt rm /mnt/worm/test.txt ls /mnt/worm/

在WORM目录里执行rm应该返回Operation not permitted，文件仍保留在目录里。如果发现touch或chmod还能改变已有文件权限，说明保留策略没有真正作用到该目录，需要检查目录是否被正确标记为合规保留。

5.3 配额、目录分片和自动精简配置

配额管理要同时看两个维度：容量配额和文件数配额。很多业务只关注容量，结果单个目录产生几千万个小文件，把索引控制器内存打爆。ParaStor的目录配额配合自动精简配置，可以实现“先超额分配，再按实际使用增长”，这适合云平台给多个项目组划分存储空间。

自动精简配置的坑在于，超卖比例太高会让底层存储写满后出现无空间可用的状态。管理上需要配置告警阈值，比如达到85%就告警，90%就停止写入，避免业务侧只能读不能写。

5.4 分级存储、归档和远程同步之间的关系

分级存储解决的是成本问题，把不热的数据迁移到低速介质；数据归档是把数据按策略移动到指定位置长期保存；远程同步解决的是容灾，把数据复制到另一套ParaStor或对象存储。

常见误区是把归档和备份混为一谈。归档是数据迁移，迁移完成后原数据可能被回收，只有一份数据；备份是保留多个时间点副本。ParaStor如果配置了数据归档，必须确认归档目标是否有独立副本，否则源数据损坏时，归档数据也无法恢复。远程同步任务要放在业务低峰期，且同步策略要设置带宽限制，不然会抢业务流量。

6. 场景选型与元数据节点规划：从HPC到视频监控的取舍

6.1 不同场景对应的ParaStor形态

视频监控专用存储不适合跑通用业务，它硬件上做了成本裁剪，计算能力有限，只适合顺序写为主的流媒体场景。双节点系统不要用在有小文件压力或未来数据量会快速增长的场景。

6.2 元数据节点数量的估算

索引控制器规模取决于文件数量，而不是存储容量。经验做法是每个文件在索引控制器内存中大约占用2KB元数据，双节点是起步配置。

def estimate_index_node_count(file_count): mem_needed_bytes = file_count * 2048 if file_count < 50_000_000: return 2 return max(2, mem_needed_bytes // (128 * 1024**3) + 1)

这个函数只是粗略估算，实际还要看目录深度、客户端并发数和是否开启目录分片。文件数过亿时，我建议索引节点从4到8个起步，内存直接给到192GB以上，同时把目录分片打开，这是我在多个项目中验证过性价比最高的一步。

6.3 上线前最后要做的验证

新项目评估ParaStor，先跑一轮目录扫描和小文件创建回归，确认元数据路径没有明显短板。

grep parastor /proc/mounts find /mnt/parastor -type f | wc -l

/proc/mounts能看到挂载选项是否生效，数量统计能判断目录分片是否真的把文件分散到多个索引分片上。如果扫描后索引控制器CPU打满，再调整分片数量或增加索引节点，优先于盲目增加数据控制器。

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