企业的数据中心正在同时面对两类任务：一类是让数据库、虚拟化、研发设计、医疗影像等生产业务持续稳定运行，另一类是把已有数据用于模型训练、智能分析和知识检索。前者看重访问时延、业务连续性和可管理性，后者需要海量数据供给、跨系统复用及持续扩展。当不同项目分别采购存储、复制数据和维护权限时，新增应用的成本不仅来自设备，也来自反复找数、搬数和重新建设。

深信服aStor统一存储解决方案以软件定义的分布式架构提供块、文件、对象和向量四类数据服务，面向中高端存储需求、中大型客户集群与大型数据中心，把生产承载、全域数据治理和长期扩展放入同一技术体系。企业可以按实际业务选择全闪或混闪、共享或独立部署，先解决当前任务，再把后续业务接入已有建设，让传统生产与AI创新共同受益。

这套方案的价值可以沿三条主线理解：以相应的数据服务承接不同应用，以统一视图和数据流动复用分散数据，以性能和容量的持续扩展支撑业务增长。统一建设由此既能覆盖一套生产系统，也能逐步形成跨部门、跨项目的数据底座。

图1 aStor统一存储的三个统一

从业务流程出发，确定统一建设的范围

规划存储时，先看数据怎样进入业务、被谁使用以及需要保存多久。例如，数据库通过块卷完成事务读写，研发人员通过共享目录修改设计文件，采集平台通过对象接口保存图像，训练任务再批量读取经过清洗和标注的数据。进入知识检索阶段后，应用还要将原文与向量关联，并在查询时找到对应内容。每个环节都需要合适的访问接口和资源配置。

 

在此基础上，把业务按性能敏感度、访问时间和恢复目标分组。在线数据库需要稳定响应，批量训练需要持续供数，历史影像和成果资料更关注长期可用与单位容量成本。aStor可按业务组合配置全闪性能资源和混闪容量资源；对故障域、权限或性能隔离要求较高的业务，采用独立资源或集群，并以统一技术体系和数据治理能力协同。

统一建设还意味着统一规划责任与流程。业务部门明确数据使用和保留要求，平台团队负责访问、容量和运行状态，应用团队确定写入发布、数据校验和恢复顺序。这样，新项目接入时可以复用已有标准，减少从接口、权限到保护策略都重新设计的工作。

一套分层架构，承接块、文件、对象和向量服务

统一承载各类业务： aStor在访问层承接iSCSI、NVMe-oF、NFS、SMB、S3及S3 Vector兼容API等接口，服务层分别处理卷、目录、对象桶和向量的数据模型，索引与缓存层处理元数据及热点访问，持久化层负责数据布局与冗余保护。应用保留熟悉的访问方式，平台则统一组织资源、监控和扩展，使新旧业务能够沿同一架构演进。

数据库和虚拟化通过块卷获得所需的存储空间，文件业务通过目录共享开展协作，对象应用通过桶和对象组织数据，向量应用通过相应接口写入与检索向量。四类服务各有职责，建设时根据实际应用启用和配置；例如企业知识库可以使用向量与对象能力，生产数据库仍继续采用适配的块访问方式。

图2 aStor数据服务与硬件架构

深信服aStor统一存储采用全栈自研路线，并非基于Ceph改造。自研PhxDFS文件系统、PhxKV元数据引擎和PhxTier存储引擎，为文件组织、索引访问、缓存与数据布局提供协同基础。全闪形态使用闪存介质支撑低时延和高带宽，混闪形态通过SSD缓存与HDD容量层衔接性能和容量需求。企业可以按当前负载配置资源，并延续同一软件体系建设后续业务。

文件与对象互通进一步缩短数据交付链路。将文件系统空间与S3共享桶关联，完成身份映射和权限配置后，采集、清洗或标注程序可通过文件接口写入，数据提交完成后，对象应用直接读取同一份底层数据；反向流程也可由对象写入、文件应用读取。通过确定各阶段的写入口和发布顺序，业务可以减少跨系统复制、额外容量占用及副本版本核对。

向量服务把向量、关联元数据和原文放在同一存储体系内管理，为知识检索提供过滤、近邻搜索和原文关联能力。应用侧负责文本处理、Embedding生成、重排及模型推理，存储侧负责向量持久化、索引和查询。各环节分工明确后，企业可以在原有数据基础上构建知识应用，并使知识更新与数据治理形成衔接。

统一承载之后，怎样实现高性能文件与高性能对象

高性能建设需要对应实际数据路径：应用发起请求，访问入口接收请求，元数据服务定位数据，数据节点经网络把内容交给计算任务。小文件业务往往需要先完成大量目录查找和属性访问，大文件任务则更依赖持续吞吐。aStor分别优化这些环节，使统一架构中的文件和对象服务能够面向各自负载发挥性能。

对于EDA设计、测绘切片、科研样本等海量小文件，aStor文件服务通过多活元数据服务、目录分片和PhxKV元数据引擎分散目录操作压力，并利用小文件聚合改善后端处理效率。多个客户端同时扫描、创建或读取项目文件时，请求可由相应服务资源协同处理，减少任务启动前等待目录遍历和数据定位的时间。

对于遥感影像、仿真结果、训练样本等持续读取任务，可以依据客户端与网络条件选择pNFS、NFS+或NFS over RDMA。pNFS使客户端按布局访问数据节点，NFS+通过多连接分担入口压力，RDMA路径减少传输过程中的网络栈和CPU开销。方案将客户端、交换网络与存储服务一起规划，使后端介质的带宽能够沿完整路径服务应用。

对象服务则同时面向数据定位、请求处理和内容传输。目录桶适合按项目、日期或数据集组织并反复访问对象的业务；对象引擎通过索引、缓存、小对象聚合与大对象流水处理，分别优化小对象请求和持续数据传输。训练平台既能使用对象方式管理大规模数据，也能围绕热点数据集配置相应的性能资源。

在高性能对象供数中，S3 over RDMA用于优化存储与主机之间的传输路径，cuObject配合GDS可减少数据进入GPU显存前的主机内存中转。实施时按所选路径完成客户端库、网卡、驱动、服务端版本及应用调用适配，并以实际训练读取和Checkpoint写入验证收益，从而把存储带宽转化为应用可用的供数能力。

块业务的性能保障同样纳入统一方案。多路径接入提高访问路径的可用性，针对业务配置卷资源和存储卷QoS，并结合前后台任务控制，减少批处理、数据均衡等任务对关键业务的竞争。对严格隔离的数据库，可采用独立资源或集群；对适合共享的业务，则通过合理配比提高资源利用率。统一管理与按需隔离结合，让各类应用按各自的性能目标运行。

验收时，应采用客户真实的任务组合：数据库并发事务、文件目录操作、大文件读取、对象上传下载以及后台保护任务共同运行。记录应用时延、任务完成时间、吞吐与错误重试，再调整资源和访问路径。这样的验证能够明确现有配置的承载范围，为后续扩展提供依据，也能避免只根据单项峰值指标配置全部业务。

统一治理全域数据，让已有资料更快进入新业务

统一治理全域数据： 企业已有数据通常分散在不同NAS、对象存储和云端空间。aStor通过受支持接口采集元数据，建立跨存储的统一视图，将名称、路径、时间、标签及来源等信息纳入检索。业务可以先找到数据，再按任务安排访问和加载，减少为识别数据而提前搬迁全部内容的工作。

统一视图解决“数据在哪里”，数据流动解决“任务怎样用到数据”。例如，某个研究项目只需要最近一周、指定设备产生的样本，可以先筛选目标数据，再按需加载或预热到性能层，供训练或分析任务使用。热数据由高性能资源服务，低频内容继续保留在适用容量层，数据使用与硬件投入因此更贴近真实需求。

图3 aStor全域数据治理

权限在这条链路中持续生效。统一检索、实际读取和跨系统流动分别核验访问身份、源端授权及目标权限，把元数据可见范围与内容可访问范围对应起来。项目成员通过受控入口使用所需数据，管理员可以保留来源和流动记录，使跨部门共享具备清晰的责任和审计依据。

面向普通对象桶与目录桶的数据分支管理，可固定一次训练或知识更新的输入状态。团队可以围绕数据版本开展处理、比较和回溯，使模型结果能够关联到所使用的数据集。对于持续采集的场景，生产写入继续推进，训练任务使用经过确认的版本；新数据完成清洗与核验后再进入下一轮任务，减少输入变化造成的重复排查。

知识应用则把数据发现、内容处理、向量生成与检索串起来：找到获准使用的文档，加载所需内容，由应用生成向量并写入向量桶，检索时按元数据过滤定位结果，再关联原文。应用负责更新与删除的任务编排，aStor提供相应存储和检索能力，使企业从分散文档走向可持续更新的知识服务。

面向EB级数据增长，协调性能、容量与可靠性

统一储存任意规模数据： aStor支持PB级数据承载，并具备面向EB级容量增长的扩展能力。企业可以从当前业务所需资源起步，随数据量和并发增加逐步扩展节点、介质及相应服务资源，无需在首期建满远期容量。全闪用于活跃分析与关键访问，混闪承接大规模数据及长期保存，再通过数据流动连接不同资源层次。

容量和性能可以围绕各自需求规划。新增磁盘解决空间增长，服务算力、元数据资源、访问入口和网络则共同支撑并发及吞吐增长。对于大型集群，需要同时观察空间水位、目录热点、网络利用率和任务队列，选择相应扩展方式。方案从“还能放多少数据”进一步落实到“增长后的数据是否仍能高效使用”。

扩展过程中，aStor利用数据放置和后台均衡组织新增资源，通过前后台服务质量控制协调生产访问与数据迁移。实施方案将资源接入、业务验证和均衡进度分别纳入检查，并为重建、快照及容量增长预留空间。这样的规划有助于维持长期运行的可管理性，避免把设备满配或空间用尽之后的调整留给业务高峰。

稳定可靠要落实到故障处理与恢复过程。aStor按部署形态配置副本或纠删码、故障域隔离及接管机制，结合持久化写入、端到端校验、亚健康盘隔离和并行重建，降低介质、节点及链路异常对生产的影响。冗余策略与机柜、网络、供电等实际故障范围匹配，才能使数据保护覆盖项目真正面对的风险。

面对误删除、错误写入或勒索风险，可按服务能力组合快照、回收站、不可变保护、WORM、访问控制和审计。重要业务再配置独立备份及适用的异地复制：本地保护帮助快速回到历史状态，独立副本保留恢复路径，异地方案服务站点故障后的业务接管。保护配置、保留周期与恢复流程一起设计，使数据安全与日常使用相互配合。

恢复演练从数据完整性一直延伸到业务可用性。数据库需要核验日志与事务恢复，文件应用要核对目录、权限和客户端访问，对象应用需要检查端点、访问密钥和桶策略。通过记录恢复步骤、责任人及实际耗时，企业可以把存储层的保护能力落实为可执行的业务连续性方案。

把统一方案落到AI、医疗、科研和企业生产场景

自动驾驶的重点是采集、标注、训练和回灌之间的数据循环。车辆或采集系统生成的视频和传感器数据持续进入平台，标注工具与训练框架使用不同接口，历史样本还要反复参与新模型训练。aStor通过文件与对象服务、适配的数据互通及冷热资源协同，减少阶段之间的数据搬运，为持续增长的数据集提供统一承载。

具身智能同时涉及图像、视频、传感器记录和机器人运行日志，需要将采集后的多模态数据交给训练任务。AI制药涉及分子数据、实验结果与计算分析，量化研究则涉及历史行情、特征数据、回测和模型训练。这些业务可以围绕活跃工作集配置高性能访问，围绕历史数据配置长期保存，并通过版本、权限和数据流动组织不同任务的使用范围。

面向运营商或企业大型智算中心，方案设计关注多租户、多任务并发供数，以及数据集加载、训练读取和Checkpoint写入的资源安排。aStor可围绕文件或对象访问路径配置入口、服务算力、元数据与容量资源，结合高速网络、热点预热和后台流量控制构建共享数据底座。强隔离业务按项目要求独立部署，再通过受控数据共享连接相关任务。

医疗场景既包含PACS影像，也包含病案、报告、HIS相关业务和医学科研。影像持续增长需要容量扩展，临床调阅需要稳定访问，基因测序又涉及计算集群共享大文件和过程数据。统一方案按应用选用服务与保护策略，结合全闪和混闪资源承接活跃访问及长期保存，使临床与科研能够分别获得合适的数据支持。

科研和EDA对数据访问的要求具有明显阶段性。任务启动可能集中扫描大量目录，仿真和分析阶段产生随机访问及临时文件，结果输出又形成持续写入。aStor将元数据并行处理、小文件优化和大文件传输能力用于这些路径，并通过项目权限、快照和分层保护代码、实验数据与成果，使团队协作、任务执行和成果留存能够沿同一平台衔接。

测绘、政府及公共服务机构需要长期积累图像、成果、文档和视频，并按网络及权限边界提供服务；企业还要承载生产系统、研发共享、办公数据与质量追溯。aStor可按业务选择相应数据服务，并在受支持的平台上规划信创部署，使生产访问、容量增长和自主可控建设共同推进。不同业务的安全域和访问权限在统一规划中保持清晰。

从实际项目看统一建设如何落地

太原重工：多类业务获得对应的存储服务

太原重工股份有限公司采用深信服aStor统一存储承载多类业务，合计规模为1.5PB，块服务承载仿真虚拟机及RAC共享盘，文件服务承载备份，对象服务支撑网盘数据。这一实践体现了统一建设的服务分工：同一产品体系根据应用需要提供对应接口，使生产计算、数据保护和内容共享能够纳入整体规划。

对于同样存在多类业务的企业，可以据此先梳理应用清单，再明确各项业务使用的服务、性能资源与保护方式。生产卷和备份用途分别配置访问与恢复策略，网盘应用按用户和内容管理要求接入对象服务，后续业务增长时再围绕实际瓶颈扩展，形成持续可用的建设路径。

西安市勘察测绘院：信创数据底座支撑实景三维

西安市勘察测绘院承担实景三维西安等基础测绘任务，业务覆盖遥感影像、测绘成果、三维建模、CAD制图和GIS切片。内网需要承载数据生产及原始、成果数据归档，互联网侧则主要提供脱敏数据应用服务。海量小文件并发、成果持续增长与信创适配共同构成存储建设要求。

项目采用深信服aStor统一存储，部署11台信创节点、合计约1PB容量，配合海光服务器及云安全方案构建数据底座。文件服务支撑生产与成果访问，容量横向扩展适应后续数据积累，统一运维配合整体云平台管理。该项目把高性能访问、国产平台适配、可靠性及持续扩展放在同一建设过程中，为测绘生产与公共服务提供基础支撑。

天瞳威视：全闪与混闪协同承接自动驾驶数据

天瞳威视的自动驾驶研发需要让标注与训练持续使用采集数据，同时保存不断增长的历史样本。项目采用深信服aStor统一存储，部署3台全闪与6台混闪设备，累计提供2PB存储空间，通过NFS和CIFS服务训练及标注。全闪承担活跃任务访问，混闪承接较大规模的数据保存，使不同阶段能够在统一体系中获得匹配资源。

这一建设方式把数据准备和计算使用连接起来：标注、训练及历史样本复用围绕共同的数据资源开展，减少跨业务拷贝，并为数据量增长预留扩展路径。对同类自动驾驶项目，可沿采集、加工、训练和留存的阶段划分工作集，再确定性能层规模及流动策略，使投入与研发任务的实际访问需求相匹配。

节卡机器人：衔接具身智能采集与训练

原有流程中，采集数据经S3进入对象存储后，还需通过NAS网关复制到GPU服务器本地盘，再由该服务器向其他训练节点提供NFS共享。数据量和训练并发增加时，中间复制与单点共享会增加供数压力。aStor将采集和训练接到同一存储底座，使数据提交后能够沿适配的文件访问路径直接用于训练。

节卡机器人股份有限公司需要保存协作机器人产生的图像、视频、传感器数据和日志，并交给AI训练使用。项目采用深信服aStor统一存储，以S3进行数据采集，通过NFS over RDMA承接训练访问，将F6000T全闪性能资源与已有混闪对象存储协同，服务采集、数据准备和训练的连续流程。

在该方案中，历史和新增数据可以按任务需要进入性能层，训练侧获得相应的高性能文件访问，已有容量资源继续发挥保存价值。文件、对象及数据流动能力围绕真实业务阶段配合，让机器人数据从采集进入训练的路径更连贯，也为后续数据积累和模型迭代提供扩展基础。

魔视智能：多期扩展支撑海量训练数据准备

魔视智能科技（上海）股份有限公司的自动驾驶研发持续产生路采图片和视频，训练前需要完成解压与数据准备。项目采用aStor混闪架构，在8个月内完成首期部署及两次扩容，总授权容量达到3.8PB。在容量利用率约90%的项目运行状态下，完成海量数据迁入并保持业务平稳运行，体现了持续增长环境下的生产承载。

在该项目同一业务压缩文件的处理过程中，解压耗时由90分钟缩短至7分钟，改善了训练开始前的数据准备效率。该结果对应具体解压任务；结合多期扩展实践，可以看到大规模承载既体现在容量增长，也体现在数据能够更快进入后续计算流程。

跨行业客户实践，覆盖生产、研发与AI应用

深信服存储产品已在不同规模、不同负载的业务中落地。下表按客户实际承载方向列举实践，既展示AI创新，也覆盖医疗、科研、EDA、测绘、企业制造和公共服务。各项目使用的服务及配置依据自身需求选择，具体规模与效果以对应项目为准。

 

从客户实践看，统一存储既能承接PB级生产项目，也能服务海量文件、研发并行访问及多模态训练数据。按业务选择服务、围绕访问路径优化性能，再用保护与扩展机制支撑长期运行，是这些建设经验中可复用的方法。

根据IDC《中国软件定义存储（SDS）及超融合存储（HCI）系统市场季度跟踪报告，2026Q2》，深信服进入中国文件存储市场前三。市场采用与跨行业落地共同体现其在企业级存储中的应用基础；深信服aStor以自研架构、多类数据服务和持续的数据治理能力，推动统一存储在国内生产与AI场景中的实践。

分阶段实施，让当前建设持续服务后续增长

第一阶段是业务与数据盘点。明确应用接口、活跃工作集、数据增量、保留周期、权限边界和恢复目标，并识别已有设备可以继续承担的角色。对要求信创适配的项目，把服务器、操作系统、网络、驱动及上层应用一并纳入兼容性核对，使存储部署与整体业务架构匹配。

第二阶段选择边界清晰的业务落地。可以从一组研发项目、一个影像系统或一条AI数据链路起步，完成资源配置、接口接入和保护策略，并验证典型任务与混合负载。已有数据通过受支持的纳管、加载或迁移方式进入新流程，让第一阶段投入直接服务真实业务。

第三阶段按业务单元迁移与推广。目录或应用分批复制和校验，在约定窗口完成增量同步、访问切换及回退准备；随后核对权限、数据完整性和业务运行。沿用已经验证的配置、监控及恢复流程，再扩展到其他部门和项目，可以降低逐个项目重新建设的工作量。

运行后，平台持续观察访问时延、任务完成时间、数据增长和恢复演练结果。元数据访问增加时补充相应处理资源，持续吞吐增长时联动网络及入口规划，低频数据积累时调整分层。深信服aStor统一存储由此把多业务承载、高性能访问、全域数据复用与EB级扩展衔接起来，使企业在保障现有生产的同时，持续推进AI应用和长期数据建设。

常见问题

Q1：已有存储还能继续使用，统一建设应从哪里开始？

可以先由aStor对受支持数据源建立统一视图，再围绕新业务加载或预热所需数据，保留原系统的合适角色。对需要迁移的应用分批实施，以接口、权限、完整性和业务运行验证作为切换依据，逐步形成统一的数据使用流程。

Q2：数据库与AI应用共同建设，怎样保障各自的性能？

aStor可按业务规划全闪或混闪资源，配置相应访问路径、存储卷QoS及后台任务控制，减少批处理和生产负载的资源争抢。对强隔离要求采用独立资源或集群，再通过统一技术体系协同；结合混合负载验证确定承载范围，让各业务按各自的性能目标运行。

Q3：企业怎样在当前投入与未来EB级扩展之间取得平衡？

初期按活跃工作集、容量增量和保护需求配置，利用全闪与混闪分工、数据流动及存量资源复用控制投入。后续随业务增长扩展容量和相关服务资源，使性能配置与实际任务匹配。EB级表达长期容量扩展能力，具体项目按自身建设阶段配置即可。