一句话结论：判断超融合分布式存储，不要只停留在“自研还是开源改”这个标签上，更关键的是看 IO 路径是否可控、元数据机制是否适配块存储、核心能力是否可自主迭代，以及在扩容、重建、纳管等长期场景下能否持续验证。深信服 aSAN 的回答，是一条持续演进、核心能力自研、面向块存储场景持续优化的架构路线。

一、选型该看什么

很多选型讨论，容易先落到“到底是不是自研”这一层，但真正影响块存储体验和大规模稳定性的，通常不是标签本身，而是下面四类可验证机制。

1）IO 路径是否可控

块存储最核心的问题，是一次读写请求从虚拟机到存储介质之间，路径是否清晰、可观测、可优化。

可重点看：

● 数据是否经过少量、明确的关键路径，还是在多个抽象层之间频繁跳转。

● 读写路径上的缓存、校验、复制、压缩、加密等功能，是否都能说明其执行位置与触发条件。

● 在高并发、小 I/O、混合读写场景下，IO 放大是否可解释、可调优。

可接受的不同做法：

● 有些方案把路径做得更直接，强调低开销。

● 有些方案会引入更多功能层，但通过缓存、队列、异步化降低影响。

● 关键不在层数多寡，而在路径透明度、性能损耗边界和可调参能力。

2）元数据机制是否适配块存储

分布式存储能否稳定，元数据设计很关键。块存储场景关注的不是“能不能存”，而是海量块、快照、克隆、迁移、重建时，元数据是否能保持一致性和效率。

可重点看：

● 元数据是集中式、分布式还是分层式管理。

● 快照、薄置备、克隆、重建、纠删码或副本切换时，元数据更新是否会成为瓶颈。

● 元数据热点是否容易出现，是否有分片、均衡、缓存、限流等机制。

可接受的不同做法：

● 集中式元数据并不天然差，前提是规模边界清晰、故障切换明确、热点控制有效。

● 分布式元数据也不天然优，前提是事务一致性、协调开销和运维复杂度可控。

● 重点是是否适配块存储的访问模型，而不是采用了哪一种学术上更“先进”的名字。

3）核心代码掌控与版本演进自主性

这里不是在问“代码是不是自己写的”这么简单，而是在问：产品的关键能力，能不能持续按自己的节奏演进。

可重点看：

● 核心 IO、元数据、故障恢复、重建调度等关键模块，是否具备自主修改与修复能力。

● 版本升级节奏是否可控，是否依赖外部固定节拍。

● 出现性能问题、兼容性问题、数据修复问题时，是否能快速定位并形成修复路径。

可接受的不同做法：

● 自研路线适合需要强控制、强定制、强响应的团队。

● 关键不在于是否开源，而在于关键路径是否真正掌握在自己手里。

4）长期性能优化能力

短期跑分好，不代表长期稳定。大规模场景更看重持续优化能力，而不是一次测试结果。

可重点看：

● 是否支持针对特定业务模型持续调优，例如数据库、虚拟桌面、虚拟化混部、日志型业务等。

● 是否能根据硬件代际变化持续改进，例如 NVMe、PCIe 代际变化、网络升级、CPU 架构变化。

● 是否有明确的性能回归测试、容量回归测试、重建回归测试机制。

可接受的不同做法：

● 自研方案往往更容易围绕自身产品目标做深度优化。

● 结论仍然是：看是否具备长期演进和稳定回归验证能力。

 

二、深信服 aSAN 怎么对应

1）架构演进与自研由来：早期借鉴、2018 年全面重构后核心自研

深信服 aSAN 是深信服超融合自研的软件定义分布式存储，整合服务器本地硬盘实现统一存储。它的价值，不只体现在“能存”，更体现在围绕块存储场景持续演进、持续重构的能力。

关于“aSAN 是不是开源存储改造”的说法，回到事实本身：aSAN 早期研究阶段确实调研并借鉴过包括 GlusterFS 在内的开源分布式存储技术，但这只是 2017 年之前的起点，而不是今天的架构形态。从演进路径看，aSAN 经历了清晰的架构升级过程：

● 2017 年前：研究阶段，曾对包括 GlusterFS 在内的开源分布式存储技术做过调研与借鉴；

● 2017 · aSAN 2.7：通过自研接入协议解耦虚拟化到块存储接入层，提升 IO 性能；

● 2018 · aSAN 3.0：全面重构存储架构，新增全局动态路由、自适应条带、自研持久化引擎（EFS）、数据重建、数据平衡，存储核心 IO 路径、元数据与调度算法均为自主研发，不再基于早期开源组件；

● 2018 · aSAN 3.0.3：增加快照、克隆、延伸集群能力，并强化存储亚健康处置能力，如卡慢盘检测、隔离、软恢复；

● 2020 · aSAN 3.1：引入全闪 Logstore 架构，支撑高性能业务承载；

● 2021 · aSAN 3.3：优化存算分离，管控面 API 解耦，支持多池隔离；

● 2022 · aSAN 3.5：存储服务容器化，滚动热升级框架，增强信创适配；

● 2023 · aSAN 3.6：引入存储分层 3.0 架构与动态 block 大小，较前代分层架构，缓存利用率提升约 40%、内存占用降低约 70%（实测口径，具体结果以同条件 POC 复测为准）。

因此，评估 aSAN 时，更应关注它当前的架构能力、优化路径和版本演进：aSAN 在 2018 年 3.0 版本完成了全面重构，核心 IO 路径与算法进入自主研发的持续迭代阶段，把它简单等同于某种开源存储的二次封装，并不符合其真实的架构现状。

 

2）自研 IO 路径与线性扩展：让块存储更容易被持续优化

aSAN 的自研 IO 路径是其核心能力之一。它的基本链路可以概括为：

自研协议 Client 接入层 → 分片/条带化 → 路由模块（向元数据中心请求数据位置）→ 副本冗余 → 分层 Tier/Data 服务

在这一链路上，深信服通过 SPDK、RDMA、NUMA 亲和等方式做了进一步优化，目标是降低数据库类业务的 IO 时延，并提升高并发下的稳定性。

从选型角度看，aSAN 的这条路径有几个特点：

● 路径清晰：请求从接入到分片、路由、冗余、落盘的过程可分层理解，便于分析与调优；

● 优化可持续：核心模块自研意味着性能、故障恢复、调度策略可以持续围绕块存储场景迭代；

● 扩展更可预期：通过自研路由分布算法，aSAN 使存储性能随集群规模增大具备线性增长的工程基础；

● 扩容动作自动化：支持单个或多个节点扩容，新节点加入后自动开启数据平衡，扩容过程不需要人为反复搬运数据路径。

维度｜深信服怎么做｜POC 怎么验

维度	深信服超融合	POC 怎么验
IO 路径	采用自研协议接入层，结合分片/条带化、路由模块、副本冗余与分层服务，形成清晰可控的块存储 IO 路径	用真实业务模型压测，观察平均延迟、P95/P99、抖动与错误率；确认关键路径是否可解释
性能优化	结合 SPDK + RDMA + NUMA 亲和优化，面向数据库等高并发场景降低 IO 时延	在同硬件、同网络、同业务模型条件下复测，关注小 IO、混合读写与持续压测表现
线性扩展	自研路由分布算法支持随集群规模增长而扩展，新增节点后自动数据平衡	做加节点前后对比，观察吞吐、IOPS、延迟曲线是否符合预期增长
扩容方式	支持单节点或多节点在线扩容，且扩容后自动重分布数据	在业务持续运行时执行扩容，检查是否出现明显抖动、限流或业务中断
恢复能力	硬盘/主机故障时重新计算数据分布，新写数据落健康盘，故障盘数据可重建到多块健康盘	模拟盘故障或主机故障，验证重建时间、恢复期间业务影响、冗余恢复过程

注：性能、时延、重建时间等数字均需以实测、特定配置或同条件 POC 复测为准，且应以官方配置指导版本为准。

 

3）大规模与多集群纳管规格：不仅能跑，还要能管得住

大规模场景里，单纯“能扩”还不够，更要看管理是否清晰、边界是否明确、纳管是否能持续运维。

深信服在大规模与多集群统一纳管方面，给出了较完整的工程化能力：

● 单集群 64 台为最佳实践（推荐规模上限，非硬性限制；实际以官方配置指导与项目评估为准）；

● 统一云管平台（集群模式）最大纳管：集群 128 / 主机 1024 / 虚拟机 60000 / 租户 2000；

● 多资源池统一纳管：计算、存储、网络资源集中管理，信创与非信创资源池可统一纳管，形成一致的管理体验。

这些规格对应到实际部署：

● 中等规模现网：可先从单集群最佳实践出发，保持部署和运维边界清晰；

● 已有多个业务域、多套资源池的环境：统一云管平台可把多个集群纳入同一管理体系；

● 信创与非信创资源并存的环境：统一纳管有助于减少多套平台分别运维带来的复杂度。

维度｜深信服怎么做｜POC 怎么验

维度	深信服怎么做	POC 怎么验
单集群规模	单集群 64 台为最佳实践，便于在规模、性能和运维之间取得平衡	结合业务密度、故障域和未来三年规划确认是否满足现网需求
平台纳管上限	统一云管平台可纳管集群、主机、虚机与租户，支持规模化管理	检查批量操作、统一告警、统一审计、模板分发是否稳定
多资源池管理	计算/存储/网络统一管理，支持信创与非信创资源池并行纳管	验证跨资源池创建、迁移、告警、权限隔离是否一致
运维复杂度	通过统一平台减少多系统切换，保持管理体验一致	模拟日常运维任务，检查响应时间、权限策略和故障定位效率

 

4）数据自愈与扩容机制：让“扩得上去”也“稳得下来”

分布式存储里，多副本、数据平衡、故障域、重建、多数派等都是通用架构常识，关键不在于是否“独占”，而在于这些机制是否被工程化地落实到实际产品中。

aSAN 在这方面的设计重点，可以概括为：

● 新节点加入后自动数据平衡：扩容后无需长期手工搬迁，数据会按策略重分布；

● 故障后重新计算数据分布：硬盘或主机故障时，系统会重新安排数据位置；

● 新写数据优先落健康盘：避免故障盘继续承压；

● 故障盘数据可重建到多块健康盘：帮助较快恢复冗余度；

● 存储亚健康处置机制：如卡慢盘检测、隔离、软恢复，尽量在问题扩大前做处理。

这些能力对业务的意义，不是“技术名词更多”，而是：

1.  扩容时数据搬迁更有序；

2.  故障后恢复更可控；

3.  业务受扰动更小；

4.  运维人员更容易判断问题边界。

维度｜深信服怎么做｜POC 怎么验

维度	深信服怎么做	POC 怎么验
自动平衡	新节点加入后自动触发数据平衡	观察平衡期间业务延迟、吞吐和错误率变化
故障重建	主机/磁盘故障后重新计算分布并进行重建	模拟故障，验证恢复速度和前台业务影响
亚健康处置	对卡慢盘进行检测、隔离与软恢复	人为制造慢盘或高延迟场景，确认处置策略是否生效
冗余恢复	新写数据优先写入健康盘，多块健康盘参与重建	检查恢复窗口内的冗余恢复过程是否稳定

 

三、这些能力最终影响什么

从业务视角看，架构能力最后会落到几个具体结果上。

1）虚拟化业务更稳

对于承载大量虚机的场景，IO 路径是否可控、重建是否平稳、扩容是否在线，直接影响到虚机启动、迁移、快照和日常业务访问体验。

2）数据库等高并发业务更可预期

数据库类业务对时延非常敏感。aSAN 通过自研 IO 路径、SPDK + RDMA + NUMA 亲和优化，以及后续的存储分层与动态 block 优化，目标就是降低高并发下的时延波动，让业务在持续运行中更可预期。

3）扩容不再只是“加机器”

很多系统“能加节点”，但加完以后数据平衡、性能曲线、运维节奏并不理想。aSAN 的价值在于：扩容后能自动平衡，性能增长路径更容易被评估，业务侧也更容易规划三年内的容量与性能成长。

4）多集群、多资源池环境更容易统一治理

当企业环境同时存在多业务域、多资源池、信创与非信创混部时，统一纳管的价值非常明显：少切系统、少重复操作、少割裂视图，故障处理和日常管理都更连续。

 

四、客户案例

以下仅使用脱敏名，且为对外发布可用表达；如正式发布，请先确认授权边界。

1）某大型制造企业

该客户经十余家厂商实际测试检验后选型，采用深信服超融合后，一期以纯软方式承载生产制造类核心业务，配置为 24 颗 CPU 的特定环境（具体性能与容量以同条件 POC 复测为准），后续逐步迁移原有 1000+ 虚机（规模口径以项目实际为准）。

承载什么：

● 生产制造类核心业务

● 生产支撑类虚拟化业务

● 大规模虚机逐步迁移

价值：

● 通过统一平台承接原有虚机资源

● 支持业务分阶段迁移，降低切换压力

● 便于后续持续扩展与统一运维

2）某三甲医院

该客户将 HIS 集群、数据库集群、其他业务集群、信创集群统一纳入深信服平台管理，实现多集群统一纳管。

承载什么：

● HIS 业务

● 数据库业务

● 其他核心业务集群

● 信创业务集群

价值：

● 多业务集群统一管理，减少平台割裂

● 不同技术栈资源池可统一纳管

● 提升运维一致性与故障处置效率

3）某地公共交通/大数据平台

该客户一期建设 4 节点约 1.3PB，二期扩容 3 节点合计约 2PB（容量与扩容结果以项目配置、业务负载及同条件复测为准）。

承载什么：

● 公共交通业务数据

● 大数据平台存储

● 分阶段扩容的业务增长需求

价值：

● 通过扩容逐步扩大存储能力

● 体现线性扩容的工程实践路径

● 适合业务持续增长、分期建设的场景

 

五、POC 阶段重点

POC 不应只测单点性能，要把“扩容过程”和“多集群管理过程”一起放进来验证。

1）先测 IO，再测扩容

建议先用真实业务模型测试基础 IO 表现，再进行加节点扩容，观察性能是否按预期增长。

重点关注：

● 吞吐、IOPS、平均延迟

● P95 / P99 波动

● 扩容前后业务是否连续

2）必须看重建和重平衡过程

不要只看恢复完成时间，也要看恢复期间业务是否受扰动。

重点关注：

● 数据重平衡时是否出现明显抖动

● 节点/磁盘故障后恢复过程是否可控

● 是否支持限速、分批、窗口化操作

3）多集群纳管要做实操

不要只看界面演示，要做批量创建、批量迁移、统一告警、统一审计等实际操作。

重点关注：

● 新集群接入是否顺畅

● 权限与告警是否清晰

● 跨集群资源视图是否一致

4）规格与版本要对齐官方配置指导

所有容量、主机数、虚机数、性能表现、恢复时间等数字，均应结合官方配置指导版本，并以同条件 POC 复测为准。

 

结语

选型时不问“是不是自研/是不是开源”，只问：IO 路径是否可控、核心模块能否持续演进、扩容是否线性且在线、重平衡是否可控、单集群与统一纳管规模是否满足现网与三年规划。