故小里1. 三种存储架构的核心认知
1.1 为什么存储选型总是绕不开这三兄弟
做IT基础设施这一行，存储永远是绕不开的话题。不管你是在给一台服务器装系统，还是在给一个机柜规划共享存储，最终都会碰到三个概念：直接存储、网络附加存储、存储区域网络。这三个缩写对应的实际方案，决定了你的数据放在哪里、怎么被访问、性能能跑到多少，以及最关键的——坏了一块盘之后你的业务还能不能继续跑。
先给还不熟悉的朋友快速建立概念。所谓直接存储，就是硬盘直接插在服务器本地，操作系统直接接管这些盘，中间没有任何网络设备插手，最典型的例子就是服务器机箱里的SATA盘或NVMe盘。网络附加存储则是把存储做成一个独立的文件服务器，通过NFS或SMB这类文件协议对外提供访问，客户端看到的是一个共享文件夹，而不是一块裸盘。存储区域网络走的是另一条路线，它通过网络（光纤通道或者以太网）把存储设备上的块设备映射给服务器，服务器看到的是几块“远程硬盘”，可以在这上面装文件系统、跑数据库，感知上跟本地盘基本一致。
这三者的差别，本质上可以归结为一句话：存储资源以什么粒度、通过什么通道、以什么协议对外提供服务。理解这句话，后面的所有选型判断都会变得非常清晰。
1.2 直接存储：看似老土却从未退场
很多人觉得DAS是老古董，实际上到今天它依然是大规模基础设施里占比最高的存储形态。原因很简单：没有网络协议栈的开销，没有额外的交换机故障点，也没有权限体系的干扰，延迟最低、性能最稳定、部署最省事。
我见过不少团队在追求“一切皆分布式”的潮流下，把所有数据都搞到集中式存储上，结果性能瓶颈反而出现在网络链路上。反观那些对性能极其敏感的组件，比如数据库的redo日志、虚拟化宿主机上的本地缓存盘、大数据节点的临时目录，绝大多数时候用的还是DAS。关键在于，DAS不背锅，它把存储性能的上限完全交给硬件本身，硬盘多快性能就是多快，坏了一个盘也不会影响其他服务器的存储，故障域天然隔离。
当然，DAS的短板同样明显：存储容量和计算资源绑死在同一个机箱里，扩容要么关停机箱加盘，要么买新服务器然后把数据迁过去；空闲的磁盘空间没法共享给别的机器用；做高可用方案时，需要额外借助分布式存储软件或者操作系统的复制机制，才能让另一台机器接管这块盘上的数据。简单说，DAS适合对性能敏感、数据归属清晰、不需要横向共享的场景。
1.3 网络附加存储：文件共享的最佳帮手
网络附加存储在我心中的定位是“存储界的共享文件夹服务”。它把文件系统做成了一个独立的服务终端，所有客户端通过标准文件协议访问统一的目录树。最常用的协议是NFS（Linux/Unix阵营）和SMB（Windows阵营），国内企业环境里两者混用的场景非常多。
NAS的优势在于管理简单、开箱即用。新建一个共享目录、设置好权限、告诉用户路径，整个交付就完成了。用户不需要关心底层是RAID几、容量还剩多少，也不需要理解什么是LUN、什么是映射关系。对非技术部门的需求来说，NAS几乎是唯一合理的选择。
但它也有自己的天花板。文件协议本身有额外的元数据操作开销，权限校验、目录遍历、文件锁定都会消耗性能；同时每个客户端连接都会占用NAS节点自身的CPU和内存资源，连接数一多，性能下降非常明显；再加上网络往返延迟，NAS很难在随机小IO和超高并发场景下与DAS或SAN抗衡。典型的使用场景集中在文档共享、日志归档、备份中转、静态资源存储，这些业务对延迟不那么敏感，但对容量弹性和协作便利度要求很高。
1.4 存储区域网络：块级存储的共享化方案
SAN解决了NAS和DAS各自的核心痛点：既要像NAS一样把存储资源集中起来统一管理，又要像DAS一样给服务器提供裸块设备。它通过网络把磁盘阵列上的块设备映射给多台服务器，每台服务器可以在自己的LUN上随意格式化、建文件系统、跑数据库，互不干扰。
SAN的发展史上有两条技术脉络。一条是传统的光纤通道SAN，使用专用的FC交换机，走SCSI协议封装，性能和稳定性是企业级标杆，但硬件成本居高不下；另一条是基于以太网的iSCSI SAN，通过普通万兆网卡走TCP/IP传输SCSI命令，成本亲民很多，被中小型环境广泛接受。近些年还有一种趋势是NVMe over Fabrics，把原本为本地PCIe设计的NVMe协议扩展到网络传输，延迟可以压到非常低的水平，这是后话。
SAN最吸引人的地方在于它为虚拟化平台提供了标准的共享存储底座。VMware vSphere的VMFS、KVM的共享文件系统、Windows故障转移集群的集群磁盘，底层依赖的几乎都是SAN。没有共享存储，虚拟机热迁移就是空谈，集群高可用也是纸上谈兵。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 协议与传输的底层逻辑
2.1 块、文件、对象：三种数据访问粒度
要理解三种存储架构的差异，必须先从数据访问粒度说起。这个粒度决定了存储系统能够提供什么样的接口，以及上层应用要如何消费存储资源。
块级别的访问是最底层的抽象。块设备上没有文件、目录、权限这些概念，只有一段连续的线性空间，按固定大小的块进行读写。数据库系统最懂块，因为它自己管理数据文件内部的页（page）结构，不希望在文件系统层再套一层缓存和锁机制；虚拟化平台也偏好块，因为虚拟机镜像本质上就是个文件，但如果把它换成块设备，就可以绕开文件系统的限制，获得更稳定的IO路径。
文件级别的访问在块的基础上增加了一层文件系统抽象。客户端看到的是目录树、文件名、文件大小、修改时间这些语义化信息，所有数据组织、空间分配、并发访问控制都由文件系统负责。NAS在这里的定位就是帮客户端把文件系统管理好，客户端不需要关心数据块落在哪块盘上、RAID怎么布局。
对象级别的访问（S3、Swift这类）是另一个维度，通过HTTP接口对不可变对象进行读写，最擅长处理海量非结构化数据。很多团队做存储选型时经常混淆对象存储和NAS，实际上两者面对的场景差异很大，但本文先不展开，聚焦在块和文件两条主线上。
2.2 协议演进：从SCSI到NVMe over Fabrics
DAS时代，操作系统通过驱动直接跟硬盘控制器通信，标准接口就是SCSI层。无论是SATA盘的AHCI协议还是NVMe协议，最终在操作系统内部都呈现出SCSI块设备模型（Linux下的/dev/sd*就是典型表现）。这个模型非常稳定，以至于当人们想把存储从机箱内搬到网络上时，最自然的思路就是让网络传输SCSI命令。
SAN最早期的实现方式就是把这个想法变成现实：FC协议在物理层用光纤取代SCSI线缆，在逻辑层仍然传输SCSI命令字。服务器上的FC HBA卡向FC交换机发送SCSI指令，存储阵列上的目标端口接收并执行。后来iSCSI把同样的思路搬到普通以太网上，只不过将SCSI命令封装进TCP报文，虽然增加了协议开销，但大大降低了接入成本。
NVMe over Fabrics的出现则改变了底层命令集。NVMe协议相比SCSI大幅简化了命令队列机制，支持多队列、每个队列深度高达64K，而且将数据交互映射为共享内存式访问，延迟远低于SCSI。当NVMe通过RDMA或者光纤通道传输时，远程访问的延迟可以逼近本地NVMe盘的水平。这也是为什么新一代全闪存储都在向NVMe over Fabrics演进，它同时解决了性能和远程访问两个问题。
2.3 网络传输开销对存储性能的实际影响
聊到协议，就避不开网络传输开销这个话题，这里要诚实地算一笔账。
一个标准的IO请求，从应用发出到数据落盘，要经过的内容包括：应用的文件系统调用、页缓存或直接IO、SCSI命令构造、传输层封装、网络链路传输、存储控制器接收、缓存或盘片写入、响应返回。每增加一个封装层，都会增加CPU占用和延迟。FC SAN的设计目标就是把这些开销压到最低，它去掉了TCP/IP层，减少了协议栈处理时间。iSCSI虽然方便，但TCP/IP协议栈的CPU消耗在万兆网络下非常可观，所以标准做法是启用TCP卸载引擎或者使用支持iSCSI HBA的网卡。
延迟数字上，本地NVMe盘在4K随机读下延迟约在100微秒以内，FC SAN全闪阵列大概能做到200到400微秒，iSCSI全闪阵列则普遍在500微秒以上，基于普通机械盘阵列的延迟更是到毫秒级别。如果你的核心业务是每秒几万次随机读写的高并发事务，这些微秒级的差距会在业务上放大成明显的时间差异。
2.4 单点故障与链路冗余：存储高可用的第一道防线
不管是NAS还是SAN，只要是网络化存储，就必须正视网络链路和设备本身的单点故障问题。这里分享一个踩过的坑：曾经有一个客户，早期部署iSCSI SAN时只在服务器上配了一块万兆网卡，结果某次存储端升级固件触发链路闪断，所有数据库会话瞬间全部中断，业务侧直接报警。排查下来发现存储端和网络端都做了冗余，唯独服务器端的单一网卡成了明显的短板。
正确的做法是，无论是NAS还是SAN，服务器侧至少配备两块网卡做绑定或MPIO多路径。FC SAN场景下必须配置两张HBA卡和两条光纤路径，操作系统启用多路径软件把多条路径合并成一块设备；iSCSI场景下至少用两张物理网卡配合交换机堆叠或MC-LAG，配合会话级多连接。高可用不是某一个环节的高可用，而是端到端的冗余设计，任何一个单点都可能成为整个链条断掉的节点。
3. 典型应用场景与选型考量
3.1 虚拟化平台的存储选型思路
虚拟化平台是存储架构中最复杂的场景，因为它同时需要块级性能和共享访问能力。一台虚拟机的磁盘在宿主机上可能是一个镜像文件，但这个镜像文件必须能被多台宿主机同时访问，才能实现热迁移，否则虚拟机就钉死在某台物理机上了。
当集群规模较小（比如3到5台宿主机）时，一个非常务实的选择是使用基于分布式存储的软件方案，比如Proxmox VE自带的Ceph或者VMware的vSAN，底层使用的都是服务器本地盘，通过万兆网络组成共享存储池。这种方式的好处是无需额外采购专用存储设备，横向扩展简单，性能随节点数线性增长。缺点则是对网络要求高、运维复杂度明显重一些。
当集群规模较大或者对数据可靠性有硬性要求时，集中式SAN依然是最稳妥的选择。全闪阵列配合FC网络能提供极低的延迟和极高的稳定性，虽然单TB成本高于分布式方案，但它解决的是可靠性和可维护性的问题，很多企业愿意为这份确定性买单。
3.2 数据库与容器场景对三种架构的真实需求
数据库绝对是存储选型的硬指标测试器。以MySQL的InnoDB为例，它对随机IO的延迟极其敏感，4K页的读取速度直接决定查询响应时间。把数据库腾到NAS上并不是不行，但很快会发现，文件锁机制、网络延迟、并发连接数都成了瓶颈。我实测过同样的TPC-C负载，跑在本地NVMe上的事务延迟比跑在万兆NAS上低了近十倍，这种差距在业务高峰期会被进一步放大。传统的集中式数据库，老老实实用DAS或者SAN就对了。
容器化场景则有点不一样。Kubernetes的持久化存储需求非常多元，有状态的中间件需要块存储，共享配置和日志则需要文件存储。当前主流的做法是通过CSI接口同时接入块和文件两类存储：块存储给数据库Pod使用，文件存储给日志收集、共享配置使用。如果你在搭建Kubernetes生产集群，比较好的实践是底层使用分布式存储统一提供块和文件能力，而不是把两类存储割裂成两套独立设备。
3.3 备份、归档与大数据：容量优先的场景怎么选
备份系统和归档系统是文件共享需求最集中的场景，NAS在这里的优势非常明显。备份软件通过NFS或SMB把数据写到共享目录，天然支持跨平台备份、多客户端并发写入、文件级去重和定期清理。相比SAN的块设备，NAS的文件管理能力让备份数据的生命周期管理变得直观很多。
大数据平台（Hadoop、ClickHouse这类）的存储模式比较特殊。计算节点本地盘是首选，因为数据本地性（data locality）能减少网络传输、提升扫描性能。搭建大数据集群时，我会明确把DAS作为主要存储形态，每个节点配足本地盘，用HDFS复制机制解决单盘故障问题。只有在需要将海量冷数据集中归档时，才会把低频表或历史分区迁移到NAS或对象存储上。
3.4 一个公式讲清楚IOPS与带宽的评估方法
做存储选型时，最常被问到的问题是“我需要多大的存储性能”。这里分享一个常用的估算方法。
第一步是明确业务峰值时段的IO模式。顺序读写的业务主要看带宽，随机读写的业务主要看IOPS和延迟。第二步是统计单台服务器在峰值时段产生的存储请求数，乘上服务器总数得到总IOPS需求；再统计平均IO大小，乘上IOPS就能得到带宽需求。第三步是加上冗余余量，一般建议按峰值需求的1.5到2倍进行评估。
举例来说，一个小型虚拟化集群有10台宿主机、每台宿主机在业务高峰期大约产生3000 IOPS（混合读写），总需求就是30000 IOPS。如果平均IO大小为8KB，带宽需求就是30000乘以8KB约等于240MB/s，但实际考虑到突发和放大效应，建议按400到500MB/s规划网络带宽。换到存储侧，一台中端全闪阵列提供5万到10万IOPS没有问题，而一台机械盘阵列能够提供3000到5000 IOPS就不错了，所以是选择全闪阵列还是混合阵列，这个数字就足够做决策依据了。
4. 常见问题与运维避坑经验
4.1 NAS环境最常见的性能陷阱
NAS部署中，我观察到的第一个高频问题来自网络配置。不少人以为NAS接在千兆交换机上，客户端就能跑到千兆的极限速率，实际上文件协议的开销会吞掉大量带宽。NFS和SMB在拷贝大数据时，千兆网络实测吞吐一般只有110MB/s左右，而单块机械盘在纯顺序读时已经能跑到150MB/s以上，外网拷贝反而成为瓶颈。强烈建议NAS后端至少使用双万兆上联，客户端使用万兆网卡，源端和目标端的网卡、交换机、线缆都要逐一确认不是瓶颈。
第二个常见问题出在SMB协议版本上。老版本SMB1已经被视为高危协议，安全性不足且传输效率低，Windows客户端在访问NAS时如果因为兼容性设置意外启用了SMB1，会导致大量TCP连接占用、延迟明显偏高。建议在NAS管理界面强制要求SMB2.1以上版本，并在Windows侧禁用SMB1组件。
第三个问题经常被忽略：NAS文件系统层的空间规划。NAS目录使用率一旦超过90%，文件系统碎片率会急剧上升，创建和删除文件都会明显变慢。如果NAS支持配额和预留空间功能，建议给每个共享目录设置独立配额，并预留至少10%的剩余空间给文件系统元数据和碎片整理使用。
4.2 SAN环境最容易被忽视的三个细节
SAN看起来比NAS简单，但实际运维中反而更容易出问题，因为它涉及主机层、网络层、存储层三个层面的调优。第一个细节是队列深度。现代SSD盘和阵列控制器都支持很深的任务队列，但服务器操作系统和存储驱动默认的队列深度往往偏低，导致设备无法充分发挥并发能力。Linux环境下可以使用lsblk -t、blockdev --getiomm等命令检查队列设置，必要时通过udev规则调整设备调度参数。
第二个细节是超时参数的设置。FC链路虽然稳定，但也存在网络抖动的情况，操作系统默认的SCSI命令超时时间通常设置在30到60秒，如果链路出现短暂中断而设备驱动没有及时重连，上层应用就会因为IO长时间无响应而过期。建议将存储控制器的链路故障切换参数和操作系统超时参数联动调整，确保路径切换时间远小于应用超时时间。
第三个细节和扇区大小有关。许多企业级阵列默认使用4K扇区，而旧版操作系统或数据库工具可能默认使用512字节逻辑块，两者不匹配会造成严重的写放大。搭建数据库环境时，务必先确认存储阵列导出的LUN的逻辑扇区大小，再决定文件系统格式化参数和数据库数据块大小，避免出现这种低级的性能损失。
4.3 混合部署时的路由与安全边界
很多中大型环境里，DAS、NAS、SAN是共存的，我见过最典型的混乱场景是：NAS管理口、iSCSI存储网络、业务内网混在同一台交换机上，导致存储流量与业务流量相互干扰，严重时甚至出现广播风暴拖垮整个存储链路。这里必须强调存储网络隔离的重要性。
对于SAN，存储流量应该走独立的VLAN并建议使用独立交换机，至少也要通过物理上的端口隔离来避免与广播域内的其他流量混跑。对于NAS虽然通常复用业务网络，但建议为存储协议预留独立VLAN并且开启Jumbo Frame，9000字节的巨型帧能明显降低CPU处理开销。安全边界也不能放松，存储网络的管理端口只允许跳板机访问，阵列管理员的账号必须启用双因子认证，否则一旦老管理口暴露在业务内网里，风险是防不胜防的。
4.4 故障恢复演练：比冗余更重要的是可预测
冗余设计只是第一步，真正决定存储系统可用性的，是故障发生后的恢复时间。一个只做了冗余但没有演练过的存储环境，跟没有冗余几乎没有本质区别，因为你不知道故障发生时切换能不能成功，也不清楚恢复需要多长时间。
我个人的习惯是每半年做一次完整的故障切换演练。在业务低峰期，手动断开一台存储控制器的电源，观察多路径软件是否能在预期时间内完成路径切换；拔掉一块NAS节点上的硬盘，测试热备盘自动重建的完整过程；模拟核心交换机的一侧堆叠故障，验证服务器端网卡绑定的切换行为。每次演练生成一份报告，记录切换耗时、告警信息、日志输出，并找出比上次演练改进的点。这种费时间、不产生直接收益的工作，往往是被重视不足但能救命的关键环节。
根据我的个人经验，存储架构没有绝对的最好方案，只有是否匹配业务需求、团队运维能力和预算约束的判断。不要因为听到某个新技术名词就盲目跟风，也不要因为某个方案旧就轻易放弃，踏踏实实从业务本身的IO特征、数据量、可用性要求出发，把这篇文章里讲到的三个层级理解透，做出来的选型至少是不会出大错的。