数据存储方案 | 第4期：超融合开始拆开了

存储专题 · 2026-10-25 · 九羲科技

超融合这词，过去十年讲的都是一件事：计算、存储、网络塞进一个盒子，一起买、一起扩、一起换。可 10 月 15 日 Nutanix 和 NetApp 扔出来的新方案，讲的是反话——换虚拟化平台，不必先把存储换了。

这是「数据存储方案」专栏的第 4 期。过去这几天看下来，方向收得很拢：拆开。超融合把计算和存储拆开，AI 工厂的存储把元数据和数据路径拆开，连向量库都在往"溶进已有存储"里拆。这一期，我们拆三件事。

· · ·

① 换虚拟化平台，先不用换存储了

背景先说一句。Broadcom 收购 VMware 之后，授权和价格的变动，让不少企业重新盘算虚拟化路线。过去的难处是：想换平台，往往意味着计算和存储要一起动——换一套的钱和风险，常常把换平台的念头本身压回去。

1. 新方案怎么搭

Nutanix 的新方案叫 Nutanix Cloud Infrastructure for External Storage：Nutanix Cloud Infrastructure（NCI）里的 AHV 虚拟化层，通过 NFS 去接 NetApp ONTAP 存储。企业现有的 NetApp AFF 全闪阵列和 FAS 阵列不用动，继续服役。两家 2026 年 4 月结成的战略联盟，这次落到了具体产品上；方案计划随下一个 NCI 版本在今年秋季推出¹。

分工也划得很干净：虚拟化团队继续用 Nutanix Prism 管虚拟机和应用，存储团队继续用 ONTAP 的工具和流程管存储。迁移用 Nutanix Move 做自动化，含网络映射和校验；两家还在推进对 NetApp Shift Toolkit 的支持，目标是虚拟磁盘零拷贝转换——数据本体不动，只换格式，这一步目前是"正在推进"，不是已交付¹。

图：数据中心机房（图片来源：Intelligent CIO，Adobe Stock 配图）

2. 拆开到底值多少钱

值钱的地方不在技术多新，在决策变小了。以前换平台是一次性豪赌：计算、存储、运维流程全押上。现在可以先只换虚拟化一层，存储等下一轮预算、下一批设备折旧到期再说。Nutanix 产品管理副总裁 Ketan Shah 的原话是："企业不应该在保住可信的数据基础设施和拿回虚拟化路线主导权之间二选一"¹。

反过来也要说清楚：拆开不是没有代价。NFS 这条线能不能扛住核心业务的延迟和吞吐，要看现有 AFF/FAS 的型号和负载，不能凭一句"支持"就下单。而且方案还没正式上市，秋季那个时间点，留给采购的验证窗口并不宽。拆开的好处是真实的，验证的活还得自己干。

② AI 工厂的存储，也把两条路拆开了

10 月 1 日，NetApp 在拉斯维加斯的 Insight 大会上发布了 Novus，一个面向 AI 工厂的存储架构。NetApp 首席执行官 George Kurian 在台上抛了个判断：制约企业 AI 的已经不是算力，是数据。他给的数字——93% 的企业称至少有一种数据挑战在拖住 AI 雄心，约 85% 的企业数据是非结构化的——都是 NetApp 口径，听方向，别当第三方实测²。

1. 架构怎么搭

Novus 的核心动作就一个：把元数据从数据路径里抽出来。Novus Data Director 元数据软件跑在 Supermicro 硬件上，ONTAP 数据服务跑在 AFF A90 系统上，对外是一个 NFS 名字空间。性能、容量、并发三件事，各自扩，不互相等²。

NetApp 宣称这套架构吞吐可扩展到 100TBps，并且说，存储喂不饱数据时，GPU 利用率能跌到 30% 以下。这两个数字都是厂商宣称：100TBps 是"可扩展到"的上限表述，不是某个客户实测的交付数字；30% 以下讲的是"喂不饱"情形下的下限，不是常态。NetApp 说 Novus 现在可订购，并留了一条通向软件定义部署的路²。

图：Novus 架构示意——元数据与数据路径分离（示意图按 Computer Weekly 报道绘制）

2. 和上一节放在一起看

有意思的对照：上一节是把计算和存储拆开，这一节是把元数据和数据拆开。拆的部位不一样，动机是同一个——原来绑在一起扩的东西，现在要各扩各的。AI 工厂里，元数据量（文件名字、位置、权限、版本）涨得比数据本身还快，绑在一起扩，迟早有一头先顶到天花板。拆开之后，元数据不够就加元数据节点，容量不够就加盘，两边的账分开算。

但也要留个问号：元数据和数据路径分开，中间那条协调链路本身就成了新的单点——延迟、一致性、故障切换，都得在真实负载下验。NetApp 这一仗打的是"AI 工厂"这个新词，买家要问的还是老问题：我的数据量、我的并发、我的预算，落到这个架构上，账怎么算。

③ 向量库正在溶进存储，不再单独立项

RAG 落地两年，存储层正在发生一个安静的变化：向量库不再理所当然地单独立项。10 月初，Turbopuffer 一篇"RIP，向量数据库"在 Hacker News 上冲到几百个赞，论点是结构性的，不是情绪化的——向量检索正在塌进通用存储：对象存储加索引、Postgres 扩展、无服务器查询层。单独为向量再养一套有状态系统，越来越难通过财务那一关³。

1. 新的 RAG 存储分层长什么样

一份 10 月的自托管选型指南把规模划成三档，挺适合照着对自己的量：一人一机、几万个片段，用 LanceDB、Chroma 或 Milvus Lite，HNSW 默认索引就够；小团队、几十万到几百万个片段，Qdrant、Milvus Standalone 或 Weaviate 单节点加一个持久卷，瓶颈在内存不在磁盘——100 万条 768 维 float32 向量，HNSW 索引要吃掉几十 GB 内存；到了几千万量级或有严格延迟 SLA，才上 Milvus 分布式或 Weaviate 上 Kubernetes⁴。

检索本身也在变：向量负责全局粗筛，元数据过滤（客户、年份、状态这类结构化条件）负责收口，长上下文负责局部精读。pgvector 这类"向量藏在已有数据库里"的路线，恰好同时吃到了结构化过滤和语义检索两头——这也是它在小团队里越来越常见的原因³⁴。

2. 什么情况下还是要单独立项

溶进去不等于消失。判断标准就一条：拿得出延迟和召回的实测数字吗？如果已有存储里的向量检索在你的数据量和并发下，延迟和召回都达标，就别再单独立项；如果达不到，专用向量库就是该花的钱。还有一个容易漏的点：向量本身也是资产——嵌入数据被抽走就是知识产权外泄，权限、审计、脱敏要跟原数据一个待遇，不能因为"只是个索引"就放松³。

· · ·