DAS、NAS与SAN深度解析：架构差异、选型要点与部署调优

1. 从“存储盘插在哪里”聊起：DAS、NAS、SAN的本质区别

做了这么多年存储相关的项目，我发现自己每次被问得最多的一个问题，不是“哪种存储性能最强”，而是“我到底该买DAS、NAS还是SAN？”这背后其实隐藏着一个更本质的困惑：它们三个长得相似，都是把数据存起来，但价格差好几倍，网上资料又各说各话，越看越糊涂。

我习惯用一个最朴素的判断标准去拆解它们——看数据是怎么从服务器走到硬盘上的。这个走法决定了协议、性能、扩展方式和运维边界，也决定了预算去向。

1.1 DAS不是“过时方案”，而是离服务器最近的存储

直接存储（Direct-Attached Storage，DAS）这个概念，翻译得够直白了：存储设备直接挂在服务器上，中间不经过任何网络设备。常见的形态就是服务器机箱里插几块SATA/SAS盘，或者用SAS线缆外接一个磁盘扩展柜（JBOD/JBOD阵列）。从操作系统视角看，这些盘就是本地磁盘，你可以在里面建文件系统，做RAID，当作 /data 目录挂载。

很多新人听到“DAS”会觉得这是上个世纪的产物，但实际上，今天绝大多数业务服务器跑的还是DAS，只不过形态变成了内置NVMe SSD或者PCIe扩展卡上的U.2盘。DAS的核心优势是低延迟、高带宽、零网络开销，一台机器独占整个磁盘通道，做数据库或者高并发缓存的时候，DAS的本地NVMe盘性能仍然是最能打的。

DAS的短板也显而易见：容量扩展受限、数据无法多机共享。一块盘坏了，影响范围可能就是这台服务器上的业务。早期我见过不少小公司用DAS跑MySQL，业务量涨了几倍后，磁盘不够了，只能停机加盘、迁移数据，整个过程非常痛苦。

1.2 NAS：文件共享协议的产物

网络附加存储（Network-Attached Storage，NAS）改写了“存储”的定义——它不再是一堆裸设备，而是一台自带操作系统、文件系统和网络服务的专用存储服务器。对外提供的不是“磁盘块”，而是文件共享服务，比如通过NFS、SMB/CIFS协议，把一个目录共享给网内多台服务器或终端使用。用户访问的是“文件夹”，存储细节被完全封装在NAS设备内部。

我用一个生活化类比来理解NAS：DAS像是你桌上那台只有自己能用的打印机，NAS则像办公室公共区域的共享打印机，谁都能连，但打印规则和队列由它自己管理。

NAS的强项是共享与协作。多个应用服务器可以同时读写同一个目录，天然解决“数据孤岛”问题。我们日常用的网盘、企业文件服务器、影视后期共享存储，几乎都是NAS方案。它的部署门槛也比较低，中小团队买一台群晖或威联通，简单配置一下SMB共享，整个办公室就能用起来。

但这东西有个很容易被忽略的点：NAS是把“文件语义”通过网络传输给客户端，底层文件系统加网络协议栈的双重开销，决定了它不是数据库这类块级高并发应用的最优解。把Oracle或MySQL的数据目录放到普通NAS上，跑sysbench时会有很高的锁等待和协议转换延迟，这是方案设计时最常被吐槽的坑。

1.3 SAN：把硬盘柜搬到数据中心网络后面

存储区域网络（Storage Area Network，SAN）是三者中最“重”的一种形态。它的核心逻辑是：把存储设备和服务器拆开，中间用一套专门的高速网络连接起来。这套网络可以是以光纤通道（FC）为主的光网络，也可以是以太网上的iSCSI协议。服务器看到的是一个“虚拟硬盘”，它对这个硬盘发起的是底层的SCSI块读写命令，完全不知道这块盘背后是什么厂商的设备、什么型号的硬盘。

SAN和NAS的本质区别在于提供服务的方式不同：NAS给的是文件路径，SAN给的是裸设备块。SAN上跑数据库、虚拟化集群非常合适，因为Oracle RAC、VMware vSphere这类应用需要多台服务器共同访问同一块磁盘空间，并且要求像本机硬盘一样的块级语义和性能。SAN设备内部通常还做了比较完整的数据保护机制，比如快照、克隆、远程复制，这些都是DAS和普通NAS不具备的企业级功能。

我以一个简单的方式总结它们三个的区别：DAS = “本地独占的一块大硬盘”；NAS = “办公室共享的文件柜”；SAN = “通过专用网络远程插到服务器上的硬盘阵列”。

2. 项目选型时到底看什么：不只是容量和价格

理解了架构差异，接下来就是实际选型。很多人选存储方案时只会盯着一张容量报价单看，这是很危险的。存储选型的本质是在性能模型、故障域、扩展路径和运维能力之间做权衡，而不是单纯选一台最便宜的硬盘柜。

2.1 先分清业务吃的是带宽还是IOPS

去看一个业务属于哪类负载，基本就能判断出该选哪种存储。我常用的分类方法是把负载粗分成三种：

• 顺序读写大文件：典型如视频编辑、备份、日志归档，这类业务吃的是吞吐带宽，数据块通常几MB到几百MB，对延迟相对宽容。NAS在这个场景很合适，尤其是能提供万兆以上网络接入的中高端NAS。
• 随机小IO高并发：典型如数据库数据文件、虚拟机磁盘，特点是IO块只有4KB到32KB，但并发量非常大，核心指标是IOPS和延迟。这类业务更适合SAN，或者高性能DAS直连形态。
• 混合读写共享型：典型如应用服务器集群、办公文档共享、测试环境，既要有一定并发能力又需要共享。用NAS做统一存储池，性价比和易用性最好。

一个中型企业常用组合我见过很多次：Web前端无状态服务器用本地DAS甚至云主机，数据库和虚拟化集群用中端FC SAN，文件共享和备份归档单独上一台中端NAS。当然成本敏感的环境也有用全闪SAN加NAS一体机硬扛的，但我们后面会讲到那样容易出问题。

2.2 三种存储的可靠性和故障域边界

选存储不只是选性能，最关键的是要知道“坏了一块盘影响谁”。DAS因为是本地直连，一个磁盘柜坏了，只会影响连在它上面的那台服务器，故障域最小，最可控；但反过来，它的数据保护完全依赖本地RAID，没有双活和跨设备容灾。NAS和SAN把数据集中在一台或多台设备上，故障域被放大了——但这恰恰是其优势被放大的地方，因为集中式设备可以做多控制器冗余、多副本、快照和同城容灾，一台节点故障可以由另一台接管。VMware场景里，SAN出问题会导致所有虚拟化宿主机上的虚拟机全部受影响，所以很多团队会接两套存储或者搞存储双活，花的钱也比单套贵很多。

做选型时，一定先问清楚“这个存储服务的业务重要性等级是多少”，再决定要不要上SAN双活或者NAS异步复制。最怕的情况是老板只想花买NAS的钱，却要求SAN级别的RPO/RTO，那是方案层面没法调和的矛盾。

2.3 一个完整的中型项目选型推演

前年我协助某制造企业做数据中心改造时，他们当时的存储环境就是“两个柜子打天下”：一台DAS跑ERP数据库，一台老旧NAS做全部文件共享。每个月15号月结，ERP响应时间会飙到好几秒，而且硬盘空间随时告警。我们最后给出的方案是这样的：

• 数据库和核心虚拟机：新购两台全闪FC SAN，做双活复制，RPO等于0，RTO控制在分钟级，满足ERP系统对数据库IOPS和可靠性的要求。
• 办公文档、共享目录、研发代码库：一台高性能分布式NAS，12盘位以上配万兆网口，NFS/SMB双协议共享给几十台终端和服务器。
• 备份介质：不再单独买备份服务器，直接在NAS上开一个备份目录，利用它的iSCSI Target功能，把备份存储也网络化，内部跑Veeam做无代理备份。
• 存量DAS改造：那台老DAS上的磁盘阵列太老旧，干脆退役，把需要保留的数据迁移到新NAS。

项目中前期我们对比过用中端企业级NAS替代SAN的方案，毕竟NAS价格低不少，而且支持iSCSI，乍看之下并不差。但评估数据库负载细节后发现，ERP里大量并发写操作需要稳定极低的单线程延迟，普通NAS的协议转换和缓存算法还是差点意思。所以这个项目最终的核心生产存储分别给了SAN和NAS不同的职责，各司其职。项目上线后，月结报表从原本的十分钟缩短到两分钟以内，存储占用的空间预警再也没有出现过。

3. 部署和调优中的关键细节：很多问题出在“协议栈”而不是设备本身

存储设备买到手、连接好网络，不代表性能就达到了标称值。实际上，我接手过大量“新存储性能不如预期”的工单，最后排查下来，十有八九问题不在硬盘和控制器上，而在协议栈配置和链路调优上。这些坑，买设备时销售不会主动提醒你，但部署时每一步都得较真。

3.1 iSCSI性能没跑起来，背锅的往往不是存储

iSCSI是SAN在以太网上的实现，也是小团队切入“共享块存储”最现实的路径。但iSCSI的性能完全取决于底层网络和客户端协议栈的配合。曾有客户反馈：存储设备是双千兆网口，iSCSI磁盘的带宽始终只有100MB/s出头，死活上不去。我们登设备看了半天，硬件都没问题，最后发现是服务器端只配了一个网卡IP，Windows自带的MPIO（多路径IO）没有启用，两个网口一个在跑数据、一个在空等只用作冗余。

要让iSCSI跑出理想性能，有几个关键实践值得照着做：

• 网络隔离：iSCSI流量很容易和业务流量抢带宽，所以一定单独划分VLAN或使用独立物理网络（IP-SAN专用交换机）。网上很多“iSCSI速度波动”案例，都是因为和数据备份流量挤在一起。
• 启用MPIO或网卡绑定：多块网卡时，正确配置MPIO，让IO能真正分散到多个路径上；不能简单做链路聚合（LACP），因为iSCSI是按TCP连接做哈希，可能全部哈希到同一条物理链路上。
• 开启巨型帧（Jumbo Frame）：MTU从1500调到9000，能减少同一数据量的包数量，降低CPU和交换机转发开销，大块顺序读写提升很显著。调巨型帧时记住要“端到端”——服务器网卡、交换机相应端口、存储控制器网口三层都得统一，否则会直接不通或者引发严重丢包。

同样的道理，在FC SAN环境中，Zoning和LUN Masking的配置也是故障多发地。有一回我们在给一台新服务器划盘，存储上能看到主机wwn，但操作系统始终无法识别磁盘，排查一圈后发现是FC交换机上的Zone没有把新服务器端口加进去。这不是设备问题，纯粹是配置遗漏。

3.2 NAS性能“慢”的真实原因：协议开销、缓存策略和网络瓶颈

NAS给人的第一印象往往是“用起来方便，但性能好像不够猛”，这也是很多技术人不愿意在数据库场景碰NAS的原因。但坦率说，现在中高端全闪NAS配合万兆网络，在小文件共享和虚拟化备份这些场景已经足够快了。很多人感觉NAS慢，其实是几个环节没做对。

• 网络协商速率问题：客户端有没有走万兆口？交换机端口是否被限速？我在用户现场见过一台NAS两个万兆网口，交换机却只有千兆模块，所有客户端都从千兆端口接入，瓶颈早就被钉死在网线上。要先跑通iperf，确认主机到NAS的真实TCP吞吐，再谈文件读写性能。
• 协议版本和参数：NFSv4相比NFSv3有更好的锁管理，但很多Linux默认挂载时没有开启类似 noatime、hard、nfsvers=4 等参数；SMB场景则要检查是否开启了SMB多通道（Multichannel），多网口NAS在多客户端接入时的负载均衡正依赖这个功能。
• 小文件场景：NAS文件系统在创建海量小文件时，目录项元数据处理最容易成为瓶颈。有些低端NAS因为CPU弱、内存小，几百万个小文件就会让系统变慢。购买前最好用小文件混合IO做一轮压测，比如用fio跑4K随机读50%写50%，观察实时时延是否持续攀升。

数据库跑在NAS上不是完全不行，但在设计上一定要用“高端存储+优化协议”的思路来做，而不是用小型NAS硬扛。

3.3 RAID级别、热备盘和文件系统选择：最容易忽略的底层细节

无论DAS、NAS还是SAN，底层都是磁盘阵列，所以RAID级别选择直接影响可靠性和性能体验。我基于多年实践总结出一个比较稳妥的分级原则：

很多人在做RAID 5大容量阵列时，以为只是少了点可用空间，却没意识到重构期间一旦有另外一块盘掉线，整个业务就全挂了。选型时先算一算重建时间：以10TB盘为例，RAID 5单盘重建速度通常在100-200MB/s，这意味着即使只坏一块盘，整个10TB阵列也要连续高强度跑十几个小时以上。这期间一旦再故障，数据基本没法救。

文件系统同样值得留意。NAS常用Btrfs/ZFS（提供校验和和快照），SAN上如果给虚拟机用，通常会让虚拟机自己格式化为ext4/XFS；如果直接把裸盘给Oracle用ASM，文件系统这层就省了，但管理逻辑要求更高。

4. 边界正在模糊：分布式存储、超融合与NVMe-oF给传统架构带来的冲击

标题虽然是“DAS、NAS和SAN总结”，但在当下的存储市场上，单纯把三者切成三个孤立品类已经不太够了。近几年我会明显感到一个新趋势：传统硬件定义的DAS/NAS/SAN边界，正在被分布式软件和新型协议重新打散。如果理解不了这一层，很多方案看不懂，也选不对。

4.1 为什么今天很难再画出干净的“三选一”界限

还记得2020年前后公司有几个项目，为了既节省成本又要“SAN级别的性能”，采用了基于标准x86服务器加Ceph搭建的分布式块存储集群。从接口上看它对外提供iSCSI和RBD块设备，业务端可以像使用SAN一样使用它；但从数据分布机制上看，它又借鉴了大数据领域常见的多副本和纠删码，每台服务器本地盘空间组成逻辑存储池。你说它是SAN吗？它没有专用光纤网络和专用存储控制器；你说它是DAS吗？它又能通过网络被多台物理机共享。

这种软件定义存储（SDS）正在成为中大规模系统的主流选择。它让存储的“性能”和“容量”可以被横向扩展，不用像传统SAN那样在控制器层面做“Scale-Up”就撞到性能上限。同时超融合基础架构把计算和存储装进了同一个节点，虚拟机的数据落在本地硬盘上，但通过分布式副本机制，数据可以从一台物理机漂移到另一台物理机。从应用视角看，它具备了SAN的共享特性和集中管理能力，底层却复用类似DAS的本地盘。

4.2 新协议和全闪介质正在改写“性能瓶颈”

过去判断SAN和NAS的一个重要依据是带宽：FC SAN 通常给企业提供8G/16G甚至32G接入，而NAS走以太网，一般到万兆就已经要烧高香了。但随着25G/100G以太网普及，以及NVMe协议走向前端，这种性能差距正在拉平。

现在很多全闪阵列同时支持FC-NVMe和NVMe over TCP，也就是说，可以用标准以太网加TCP协议获得接近本地NVMe盘的极低延迟iSCSI体验。NAS设备也开始内置NVMe缓存层和NVMe over Fabrics目标端，小文件随机读性能一改往日弱势。这带来的直接影响是：

• 原来看重FC SAN的数据库系统，现在可以考虑“NVMe/TCP + 分布式块存储”的方案，省掉光纤交换机和HBA卡的成本，性能损失控制在很小范围内。
• 原本用DAS直连NVMe的方案虽然延迟最低，但牺牲了集中管理和动态漂移能力，传统环境单机可用性低，所以超融合场景更容易大放异彩。
• NAS逐步从“文件共享设备”演变为“企业统一存储统一入口”，同一台设备可以既支持NFS/SMB，又支持iSCSI/S3对象存储协议。选型越来越不看你选了哪个品类，而是看设备在某个性能维度上能不能满足你的SLA。

4.3 在这种趋势下，三类存储该如何重新归位

我接触过的很多客户，在做新规划时已经不再问“该买DAS还是SAN”，而是问得更实际：“预算多少？需要几个9的可用性？跑什么负载？会不会频繁扩容？”这时我会引导他们用业务视角重新归位：

• 单机、延迟极敏感、数据量不共享：比如本机数据库、高性能计算卡，直接NVMe SSD做本地DAS，别画蛇添足接存储网络。
• 多机共享文件、协作办公、中小规模虚拟化备份：选NAS（传统文件型NAS或分布式NAS）。
• 数据库集群、虚拟化大规模生产存储、需要双活和容灾：优先传统FC SAN或高性能分布式块存储。

这三种需求并非永远互斥。很多企业的现网里，既跑着十几台NVMe直连的GPU服务器，也有一个双控SAN阵列给虚拟化和ERP供数，旁边还放了两台盘阵NAS做文件共享和备份归档。它们各管一段，谁也替代不了谁。而云原生环境下，对象存储正在承担越来越多传统NAS的海量归档职责，这也是存储选型需要继续关注的变量。

5. 我的几个实操判断和倾向

这几年做存储项目的总体感受是：不要过度迷信任何单一架构，也不要被厂商宣传带节奏。DAS、NAS、SAN之间的差异，与其说是技术代际关系，不如说是“距离、共享程度、性能模型和管理复杂度”之间的折中。

我遇到最多的问题之一，是用户想“一步到位”，直接上一套最贵的设备覆盖所有场景。存储预算有限时，我反而建议把应用仔细分层，让每一层用相对简单可靠的方案解决，不要试图用一台SAN通吃虚拟化、文件共享和备份。因为SAN是很好的块存储，但文件共享不是它的强项，它要性能和可靠性，但在共享文件协议和便捷管理上不如NAS来得灵活，而且SAN的运维门槛意味着至少要有一个人懂Zoning、多路径和快照复制。

反过来，如果团队技术实力一般，又非要自己攒一套开源存储集群来追求“低成本企业级”，我通常会提醒一句：开源SDS的初始采购成本确实低，但你要把人力消耗、调优周期和故障处理都算进去。曾有用户为省SAN采购费，自己搭了套Ceph做生产存储，结果节点带宽不均衡、网络抖动影响了整个虚拟化集群，线上服务在性能评估阶段就出了问题，最后又花更高的成本请人改造。分布式存储门槛远高于“装个系统、加个盘”这种普通阵列。不是精英团队就不要硬撑软件定义存储，而应该用商业阵列或超融合一体机，把不可控因素交给厂商兜底。

存储这行没有银弹，我对架构的判断始终是：DAS解决“快”的问题，NAS解决“分享”的问题，SAN解决“共享块级高质量存储”的问题，三者各有自己的地理边界。理解每一层的协议模型、性能和故障域，选型不会走偏，排障也才能做到有的放矢。