做基础设施这行，绕不开的一个话题就是存储怎么选。我这些年经手过不少项目，从几十号人的小团队到上百台服务器的集群，几乎每次扩容或新建，都会有人把DAS、NAS、SAN 三种存储架构摆到桌面上讨论一遍。有意思的是，讨论常常跑偏：有人上来就比价格，有人死磕 IOPS 数字，还有人直接把“共享”等同于“高级”。结果方案落地半年，业务方抱怨慢，运维抱怨难管，采购抱怨钱花冤枉了。这篇东西不打算写成产品手册，而是想把这三种架构放回真实的业务场景里，讲清楚它们各自解决什么问题、在什么条件下会失效、落地时要盯住哪些参数和细节。不管你是刚接手存储规划的新人，还是被“到底该上哪种”折磨过的老运维，看完应该都能拿到一套能直接用的判断方法和操作清单。

1. 先把三种架构的底层逻辑掰开

1.1 块、文件、对象：数据到底以什么形态被访问

很多人一上来就记 DAS 是直连、NAS 是文件共享、SAN 是块级网络，背得滚瓜烂熟，但一到选型就懵。问题出在只记了“形态”，没搞懂“形态”背后对应的是数据访问方式。存储架构的差别，本质上是上层业务拿到的是“一块裸地”还是“一栋装修好的房子”。

块级访问，指的是服务器拿到的是一段连续的、带编号的逻辑地址空间，比如从 0 到 1TB，至于这段空间上放什么文件系统、怎么组织目录，存储设备一概不管。这就像开发商给你一块地，你爱盖什么盖什么，自由度最高，性能路径最短，但也意味着你得自己负责地基、水电、物业。DAS 和 SAN 给的都是这种“地”。

文件级访问，指的是服务器拿到的是一棵目录树，可以按路径打开、读写、加锁、改权限。存储设备负责把文件映射到底层块上，还要维护元数据。这就像拎包入住的公寓，省心，但户型、装修风格受限于物业，而且多个住户共用一套门禁和走廊，难免互相影响。NAS 走的就是这条路。

再往下还有对象级访问，用扁平的名字空间加元数据标签来管理数据，适合海量非结构化内容，典型场景是图片、备份归档、日志冷数据。对象存储不在这次三种架构的主线里，但它经常作为 NAS 的补充出现，后面讲组合场景时会带到。

把这三层想明白，后面很多“为什么”就顺了：为什么数据库跑在 NAS 上经常出问题？因为数据库要的是对块的精细控制和低延迟，而 NAS 在中间加了一层文件语义。为什么多台服务器同时读写同一份数据在 SAN 上很麻烦？因为块设备本身不知道“谁在写”，需要集群文件系统或卷管理器来仲裁。

注意：判断一个业务该用哪种架构，先别问“哪种好”，先问“这个业务打开数据的方式是 open 一个路径，还是直接读写一个设备节点”。这一句话能刷掉一半错误选项。

1.2 三种架构的协议栈与链路差异

链路差异直接决定了性能上限和故障域，这是选型时最容易被忽略的一层。DAS 的链路最短：硬盘通过 SATA、SAS 或 NVMe 直接挂在服务器的控制器上，中间没有网络设备。这条路径的延迟通常在百微秒级甚至更低，NVMe 盘能压到几十微秒。代价是数据被锁在这台机器里，别的服务器想访问，只能走网络绕一圈，或者干脆拷过去。

NAS 的链路是“服务器 → 以太网 → NAS 设备”。协议层面常见的是 NFS（类 Unix 环境）和 SMB（Windows 环境）。这条链路上，网络带宽是第一道闸门：千兆网理论 125MB/s，实际跑满大概 110MB/s 出头；万兆网理论 1.25GB/s，实际在 1.1GB/s 左右。如果业务是大量小文件读写，瓶颈往往不在带宽而在往返延迟和元数据操作次数上，这时候网卡再快也救不了。

SAN 的链路是“服务器 → HBA 卡 → 光纤交换机 → 存储阵列”，跑的是 FC 协议；也有用普通网卡加 iSCSI 走以太网的变体。FC 常见的速率是 8Gb、16Gb、32Gb，iSCSI 则依赖 10Gb、25Gb 以太网。SAN 的关键设计是多路径：一台服务器通过两张 HBA 卡、两条链路连到存储的两个控制器，任何一条链路或一个控制器故障，业务不中断。这个能力是 NAS 和 DAS 在单机层面很难对标的。

这张表只能当路标用，真到项目里，每一行的权重都不一样。比如一个视频剪辑团队，看的是顺序读写带宽，NAS 万兆就能满足；一个跑虚拟化的环境，看的是随机 IOPS 和链路冗余，SAN 更稳；一个单机跑分析的场景，本地 NVMe 阵列的性价比能把前两者按在地上摩擦。

1.3 选型时真正该问自己的三个问题

我在项目里总结出一个粗糙但好用的三问法，基本能在十分钟内把方向定下来。

第一问：这份数据需要被几台机器同时访问？一台，DAS 优先；多台但要共享同一份文件，NAS；多台但各自要独占一块空间，SAN。注意“同时”这两个字的含义差别很大：NAS 的多机共享是文件级并发，两个客户端改同一个文件会涉及锁和缓存一致性；SAN 的多机访问是各看各的 LUN，天然隔离，除非上集群文件系统。

第二问：业务的性能瓶颈是带宽还是 IOPS？大文件顺序读写，看带宽，万兆 NAS 通常够；数据库、虚拟化这类随机小 IO，看 IOPS 和延迟，本地盘或 SAN 更合适。这里有个估算方法：先算出业务峰值 IOPS，再乘一个 1.5 到 2 的安全系数。比如一个中等规模的虚拟化环境，200 台虚拟机，按每台常态 20 IOPS、峰值 60 IOPS 算，峰值合计 12000 IOPS，再留余量就是 18000 到 24000 IOPS。这个量级用全闪 SAN 很轻松，用机械盘的 NAS 就是自找麻烦。

第三问：故障容忍度有多高，预算卡在哪？DAS 的单机故障就是业务中断，除非做应用层复制；NAS 靠设备本身的冗余和双机方案；SAN 靠双控制器加多路径。预算方面，同样 50TB 可用容量，DAS 可能就是几块盘的价钱，NAS 要加设备和管理成本，SAN 还要算交换机、HBA 卡、授权，常常是前两者的数倍。

提示：三问法不是让你跳过详细评估，而是先把明显不合适的选项排除掉。我见过太多项目在细枝末节上纠结两周，最后发现业务根本就是单机场景，一台带 RAID 卡的服务器就能解决。

2. DAS：被低估的直连存储

2.1 DAS 的形态与适用边界

DAS 的全称是直接附加存储，说白了就是硬盘或盘柜直接连在服务器上。形态上分几种：服务器机箱内的本地盘位、通过 SAS 线缆外接的磁盘柜、以及近几年常见的 NVMe 直连背板。别看它“土”，在很多场景里它是最优解，而不是退而求其次。

适合 DAS 的场景有几个共同特征：数据归属单一主机、对延迟敏感、预算有限。比如单机数据库、日志采集节点、边缘计算小站、渲染农场的本地缓存盘、开发测试环境。这些业务要么不需要共享，要么共享的代价远大于收益。我见过一个日志分析场景，非要把采集节点的本地盘换成网络存储，结果网络抖动直接导致日志丢失，反而不如本地盘加应用层异步上传稳。

DAS 的性能优势来自路径短。数据从内存到磁盘，中间只经过控制器的缓存和总线，没有协议封装、没有网络往返、没有额外的元数据服务。一块企业级 NVMe 盘的随机读延迟能做到几十微秒，4K 随机读 IOPS 轻松上几十万，这个数字放在网络存储上要靠全闪阵列加高速链路才能接近，成本完全不是一个量级。

但 DAS 的边界也很硬：数据绑在机器上。机器挂了，数据要靠换盘或重建才能拿到；机器满了，扩容只能加盘或换大盘，受限于机箱盘位和控制器端口数；多机协作时，共享只能靠应用层自己解决，比如定时同步、分布式文件系统、对象存储网关。这些方案不是不能用，但每一个都引入了额外的复杂度和故障点。

2.2 DAS 实操：RAID 级别选择与文件系统参数

DAS 落地最核心的一步是 RAID 规划，这一步做错，后面性能和安全都无从谈起。先看容量计算，这是最基础的账：

• RAID 0：可用容量 = 单盘容量 × 盘数，无冗余，一块盘坏全盘数据丢失，只适合临时缓存。
• RAID 1：可用容量 = 单盘容量，两块盘互为镜像，读写性能一般，适合系统盘或小容量高可靠场景。
• RAID 5：可用容量 = (盘数 - 1) × 单盘容量，允许坏一块盘，写性能受校验计算影响，重建时间长。
• RAID 6：可用容量 = (盘数 - 2) × 单盘容量，允许坏两块盘，适合大容量机械盘阵列。
• RAID 10：可用容量 = 盘数 / 2 × 单盘容量，先镜像再条带，写性能好、重建快，成本高。

举个实际例子：8 块 8TB 机械盘，做 RAID 5 可用 56TB，做 RAID 6 可用 48TB，做 RAID 10 可用 32TB。如果这组盘用来存备份归档，RAID 6 更稳，因为大容量盘重建动辄十几个小时，期间再坏一块的概率不能忽略；如果用来跑数据库，RAID 10 的随机写优势明显，多花的那点盘钱换来的是实打实的响应速度。

文件系统选择同样影响很大。Linux 环境下常见的 ext4、XFS，前者成熟稳定、适合中小容量，后者在大容量和高并发写入上表现更好，删除大文件也更利索。格式化时有个细节值得注意：mkfs.xfs默认会按底层设备优化条带参数，如果是硬件 RAID，最好显式指定-d su=和-d sw=，让文件系统的分配单元对齐 RAID 条带，避免读改写放大。不做对齐，顺序写性能掉个两三成很常见。

# 以 8 盘 RAID 6、条带 64K 为例做 XFS 对齐 mkfs.xfs -f -d su=64k,sw=6 /dev/sdb

挂载参数上，noatime能减少不必要的元数据写入，nobarrier在老内核上曾有性能收益但现在一般不推荐，因为会牺牲掉电安全性。对于纯读多写少的场景，可以适当调大预读：

mount -o noatime,nodiratime /dev/sdb1 /data blockdev --setra 8192 /dev/sdb

2.3 DAS 最容易踩的三个坑

第一个坑是把 RAID 当备份。RAID 解决的是磁盘故障导致的可用性问题，解决不了误删、勒索软件、控制器损坏、整机报废。我见过一个团队，8 块盘做 RAID 5，觉得万无一失，结果运维误执行了删除命令，文件系统层面的数据全没了，RAID 一点忙都帮不上。RAID 之外必须有独立介质的备份，这是底线。

第二个坑是重建窗口被低估。大容量机械盘做 RAID 5，一块 16TB 盘重建可能要十几个小时甚至更久，这期间阵列处于降级状态，性能下降，再坏一块就全没了。所以盘数多、单盘容量大的阵列，优先 RAID 6 或 RAID 10，别为了多那一点可用容量赌运气。另外重建期间最好限制重建速率，避免把业务 IO 饿死，多数 RAID 控制器都有重建限速参数。

第三个坑是盘位和控制器成为隐形天花板。选服务器时觉得 12 个盘位够用，两年后数据涨上来，加盘没位置，换大盘又要全量迁移。我的经验是，规划时按当前容量的两到三倍留盘位，或者选择支持外接 SAS 盘柜的方案，扩展时直接接线扩容，比换整机省事得多。

提示：DAS 场景下，盘的选择比很多人想的更重要。机械盘适合大容量顺序写，SSD 适合随机 IO，NVMe 适合低延迟高并发。混插时注意控制器和背板的带宽分配，别让几块高速盘被一条窄链路卡住。

3. NAS：文件共享的最低门槛

3.1 NAS 的工作机制：NFS 与 SMB 的差别

NAS 的本质是“一台专门提供文件服务的设备”，它自己管理文件系统和磁盘，对外通过标准协议暴露目录树。客户端看到的不是裸设备，而是挂载点或网络路径。这个抽象层带来了极大的便利，也带来了性能上的固有开销。

NFS 主要用在类 Unix 环境，协议本身比较轻，服务端无状态设计（NFSv3）让故障恢复相对简单，NFSv4 增加了状态管理和更强的安全机制。SMB 主要面向 Windows 生态，功能更丰富，支持文件锁、ACL、影子副本、多通道等特性。两者在权限模型上差别很大：NFS 传统上依赖 UID/GID 数字映射，客户端和服务端的用户 ID 必须对得上，否则就会出现“文件明明在，就是打不开”的经典问题；SMB 则更依赖用户名密码认证和 ACL。

性能上，NAS 的瓶颈通常出现在三个地方：网络带宽、元数据操作、以及服务端磁盘的随机 IO。大文件顺序读写基本能跑满网络带宽，比如万兆环境下 1GB/s 左右；但如果是几十万个几 KB 的小文件，性能会断崖式下跌，因为每个文件的创建、查找、属性读取都是一次或多次元数据操作，这些操作对延迟极其敏感。

3.2 NAS 实操：挂载参数、权限与性能调优

NFS 挂载参数里，有几个直接影响体验。rsize和wsize决定单次读写的数据块大小，万兆环境建议设到 1MB；hard和soft决定服务端无响应时的行为，hard会一直重试，保证数据一致性但可能卡住进程，soft会超时返回错误，适合能容忍失败的场景；intr允许中断挂起的操作，交互式环境建议加上。生产环境里数据库、虚拟化这类不能容忍静默错误的场景，用hard更稳妥。

mount -t nfs -o rw,hard,rsize=1048576,wsize=1048576,vers=4.1,noatime \ 192.168.10.20:/export/data /mnt/data

SMB 在 Linux 上挂载则要注意协议版本和缓存策略。vers=3.0及以上支持多通道和更完善的锁机制，cache=strict保证一致性但性能一般，cache=loose适合只读共享。实际项目里，如果客户端主要是 Windows，直接用系统自带客户端最省心；如果是 Linux 访问 SMB，记得把uid、gid、file_mode、dir_mode设对，否则挂上来全是 root 权限，后续权限管理会乱套。

mount -t cifs //192.168.10.21/share /mnt/share \ -o username=svc_storage,vers=3.0,uid=1000,gid=1000,file_mode=0664,dir_mode=0775

NAS 侧的调优，核心是把元数据和数据分开看。如果业务以小文件为主，优先考虑服务端是否支持元数据加速、是否有 SSD 缓存层、是否开启了目录索引优化。网络侧则要确认 MTU 一致，万兆环境开启巨帧（MTU 9000）能减少协议开销，但要求链路上所有设备都配成一样，否则会出现能 ping 通但大包丢失的怪现象。

3.3 NAS 的典型问题：小文件、锁、权限映射

小文件性能是 NAS 最常见的投诉来源。一个目录下几十万个文件，ls都要转半天，更别说遍历扫描。根因在于每次目录读取和文件属性查询都要走网络往返加元数据服务。缓解办法有几个：按时间或哈希做目录分片，避免单目录文件数过万；业务侧合并小文件再写入，比如打包成 tar 或列式存储格式；服务端加 SSD 元数据缓存。这些手段能改善，但改变不了“小文件不适合网络文件系统”的基本事实，真有大规摸小文件场景，本地盘加对象存储往往是更合理的选择。

文件锁的问题更隐蔽。多个客户端同时写同一个文件时，NFS 的锁机制在不同版本和不同实现之间行为差异不小，轻则写入覆盖，重则应用报错。我的建议是：不要让多个客户端并发写同一个文件。真需要并发写，要么在应用层做分片，要么用支持分布式锁的存储方案。SMB 的锁相对完善，但也要注意客户端缓存导致的可见性延迟，一个客户端写完，另一个客户端可能还在读旧缓存。

权限映射则是运维天天见的坑。NFS 的 UID/GID 对不上，表现为 Permission denied；SMB 的 ACL 配错，表现为能进目录但打不开文件。排查时先确认客户端和服务端的用户映射关系，再检查共享目录的导出配置，最后看上层 ACL。对于跨平台共享，统一用名字映射服务（如 ID 映射）比手工对齐数字 ID 靠谱得多。

4. SAN：块级共享的重型装备

4.1 SAN 的组成与链路

SAN 是把块设备通过专用网络暴露给多台服务器，让每台服务器像使用本地盘一样使用远端的 LUN。它的组成包括服务器侧的 HBA 卡、连接设备（光纤交换机或以太网交换机）、存储阵列的控制器和盘柜。FC 方案用光纤交换机和 FC 协议，iSCSI 方案用普通以太网卡和 TCP/IP 承载 SCSI 命令，前者延迟更低、隔离性更好，后者成本低、复用现有网络。

SAN 真正的价值不在“块级”本身，而在集中管理加高可用。几十台服务器不用各自买盘，容量池化后按需划分 LUN；双控制器加双链路，任何单点故障都有冗余路径；快照、克隆、远程复制这些高级功能在阵列层面统一提供，比在每台服务器上装软件实现要省心得多。这也是为什么虚拟化平台、核心数据库这类场景长期偏爱 SAN。

但 SAN 的复杂度是三者里最高的。LUN 怎么划、多路径怎么配、集群文件系统选哪个、交换机怎么划 zone，每一步都有讲究。配错一个环节，轻则性能减半，重则两台服务器同时写同一个 LUN 导致文件系统损坏。我见过最典型的事故，就是两台服务器都挂载了同一个 LUN 并各自格式化成 ext4，结果互相覆盖元数据，数据全废。

4.2 SAN 实操：LUN 规划、多路径与集群文件系统

LUN 规划的第一原则是一个 LUN 只给一台服务器用，除非上层有集群文件系统或卷管理器做仲裁。LUN 大小不要一次划太大，按业务增长分批扩展，因为多数文件系统支持在线扩容但不支持在线缩容。划 LUN 时还要注意对齐，让 LUN 的起始偏移和 RAID 条带对齐，避免跨条带读写放大。

多路径配置是 SAN 必做项。Linux 下常用的是 device-mapper-multipath，核心配置在/etc/multipath.conf。基本思路是让系统识别到同一个 LUN 的多条路径，然后按策略聚合。常用策略round-robin做负载均衡，failover做主备。配置完用multipath -ll确认每条路径状态都是 active。

# 最简配置示例：按 WWID 识别，轮询策略 defaults { user_friendly_names yes path_grouping_policy multibus path_selector "round-robin 0" failback immediate }

如果多台服务器确实需要共享同一个块设备，就必须上集群文件系统，比如 GFS2、OCFS2，或者用卷管理器加集群锁。这类方案会在挂载时做集群仲裁，防止并发写入冲突。代价是配置复杂、性能有一定损耗，所以除非业务确实需要（比如共享数据库文件、集群应用的数据目录），否则优先考虑“一个 LUN 一台机”的简单模型。

iSCSI 场景还要注意网络配置。建议单独划一个存储网段，开启巨帧，关闭不必要的服务和防火墙规则。 Initiator 侧配置 CHAP 认证，Target 侧做好访问控制列表，避免任意主机都能连上来。多路径在 iSCSI 下同样适用，通过两个网卡、两个网段连到阵列的两个控制器，效果和 FC 双链路类似。

4.3 SAN 的坑与成本账

SAN 最容易被低估的是总拥有成本。除了阵列本身，还要算光纤交换机、HBA 卡、光模块、线缆、管理软件授权、以及运维人力。一个小规模 SAN 落地，硬件成本常常是同容量 NAS 的两到三倍。如果业务量不大，这个投入很难回本。

第二个坑是过度设计。有些项目一上来就配全闪阵列加双活，结果业务峰值 IOPS 连阵列能力的十分之一都用不到。合理的做法是先做性能基线测试，按实测数据加余量选型，而不是按厂商宣传的峰值参数买单。

第三个坑是扩容和迁移。SAN 的扩容往往涉及控制器升级、微码更新、LUN 重新分布，操作窗口和风险都比 NAS 高。做规划时要把三到五年的容量增长算进去，LUN 命名和映射关系做好文档，否则几年后接手的人根本看不懂哪块空间给了谁。

注意：SAN 环境里任何涉及 LUN 映射变更的操作，都要先确认目标主机上没有挂载该 LUN，或者在业务停机窗口内进行。热操作配错映射，导致生产机看到不该看到的盘，是很常见的事故来源。

5. 组合场景与问题排查实录

5.1 四类典型业务的架构组合

真实项目里，三种架构很少单独出现，更多是组合使用。下面这几类组合我在不同项目里反复见过，效果比较稳。

第一类，虚拟化平台。计算节点用本地 SSD 做系统盘和缓存，虚拟机镜像和核心数据放在 SAN 上，通过多路径保证链路冗余；备份和归档走 NAS，利用其大容量和文件级共享。这样既保证了核心业务的 IO 和可用性，又把冷数据的成本压了下来。

第二类，数据分析与日志平台。采集节点用 DAS 本地盘做缓冲，避免网络抖动影响写入；汇总层用 NAS 做共享目录，方便多个分析任务读取同一份数据；最终结果和冷数据转存到对象存储。这个组合的关键是让每一层只做自己擅长的事，不要让 NAS 承担高频随机写。

第三类，媒体制作。素材库放 NAS，万兆网络保证多台工作站同时在线剪辑；渲染节点的临时缓存用本地 NVMe，减少网络往返；成片归档用大容量 DAS 或归档存储。这里 NAS 的带宽和并发能力是核心指标，选型时要重点看顺序读写和并发连接数。

第四类，边缘小站。单机或少量服务器，DAS 本地盘解决全部存储需求，定期把关键数据同步回中心。边缘场景网络条件不稳定，依赖网络存储反而增加故障面，本地盘加异步复制是更务实的选择。

5.2 常见问题速查表

5.3 性能验证：怎么测才算数

选型阶段最忌讳只看厂商参数，一定要自己做一轮贴近业务的测试。测试方法不需要多复杂，但要注意几点。

第一，测业务真实的 IO 模型。数据库看 8K 随机读写，虚拟化看 4K 到 16K 混合随机，媒体看大块顺序。用错模型测出来的数字毫无意义。第二，同时测延迟和 IOPS。IOPS 高但延迟抖动大的存储，跑批处理可能没问题，跑在线业务就会出事故。第三，在接近满载的条件下测。空载跑出来的数字都好看，把容量填到七成以上再测，才能看出真实水平。

具体工具上，块设备用 fio 最灵活，可以自定义块大小、队列深度、读写比例；文件级可以用 dd 做粗略的顺序测试，小文件场景则要写脚本模拟真实的创建和遍历。测试时记得在客户端和服务端同时观察资源占用，确认瓶颈到底在磁盘、网络还是 CPU，否则优化方向会跑偏。

# 8K 随机读，队列深度 32，跑 60 秒 fio --name=randread --ioengine=libaio --direct=1 --bs=8k \ --iodepth=32 --rw=randread --size=4G --runtime=60 --numjobs=4 \ --filename=/mnt/data/testfile --group_reporting

最后分享一个我在实际项目里踩出来的经验：存储方案确定之后，一定要把容量水位、性能基线、故障切换这三件事做成日常监控项，而不是等出问题再查。容量到七成就该规划扩容，性能基线偏离两成就该排查原因，故障切换每半年至少演练一次。这三件事做到位，比选型时多纠结两周有价值得多。