DAS、NAS、SAN存储架构选型指南：原理、场景与实操

做基础设施这行绕不开的一个话题就是存储怎么选。我这些年经手过不少项目从几十号人的小团队到上百台服务器的集群几乎每次扩容或新建都会有人把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 环境和 SMBWindows 环境。这条链路上网络带宽是第一道闸门千兆网理论 125MB/s实际跑满大概 110MB/s 出头万兆网理论 1.25GB/s实际在 1.1GB/s 左右。如果业务是大量小文件读写瓶颈往往不在带宽而在往返延迟和元数据操作次数上这时候网卡再快也救不了。SAN 的链路是“服务器 → HBA 卡 → 光纤交换机 → 存储阵列”跑的是 FC 协议也有用普通网卡加 iSCSI 走以太网的变体。FC 常见的速率是 8Gb、16Gb、32GbiSCSI 则依赖 10Gb、25Gb 以太网。SAN 的关键设计是多路径一台服务器通过两张 HBA 卡、两条链路连到存储的两个控制器任何一条链路或一个控制器故障业务不中断。这个能力是 NAS 和 DAS 在单机层面很难对标的。维度DASNASSAN访问粒度块文件块典型链路SAS/SATA/NVMe 直连以太网 NFS/SMBFC 或以太网 iSCSI延迟量级几十到几百微秒毫秒级受网络与元数据影响百微秒到毫秒级多机共享需额外软件层原生支持需集群文件系统扩展方式加盘、换大盘、加盘柜加节点、扩容量加控制器、加盘柜、扩 LUN典型成本最低中等最高这张表只能当路标用真到项目里每一行的权重都不一样。比如一个视频剪辑团队看的是顺序读写带宽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 su64k,sw6 /dev/sdb挂载参数上noatime能减少不必要的元数据写入nobarrier在老内核上曾有性能收益但现在一般不推荐因为会牺牲掉电安全性。对于纯读多写少的场景可以适当调大预读mount -o noatime,nodiratime /dev/sdb1 /data blockdev --setra 8192 /dev/sdb2.3 DAS 最容易踩的三个坑第一个坑是把 RAID 当备份。RAID 解决的是磁盘故障导致的可用性问题解决不了误删、勒索软件、控制器损坏、整机报废。我见过一个团队8 块盘做 RAID 5觉得万无一失结果运维误执行了删除命令文件系统层面的数据全没了RAID 一点忙都帮不上。RAID 之外必须有独立介质的备份这是底线。第二个坑是重建窗口被低估。大容量机械盘做 RAID 5一块 16TB 盘重建可能要十几个小时甚至更久这期间阵列处于降级状态性能下降再坏一块就全没了。所以盘数多、单盘容量大的阵列优先 RAID 6 或 RAID 10别为了多那一点可用容量赌运气。另外重建期间最好限制重建速率避免把业务 IO 饿死多数 RAID 控制器都有重建限速参数。第三个坑是盘位和控制器成为隐形天花板。选服务器时觉得 12 个盘位够用两年后数据涨上来加盘没位置换大盘又要全量迁移。我的经验是规划时按当前容量的两到三倍留盘位或者选择支持外接 SAS 盘柜的方案扩展时直接接线扩容比换整机省事得多。提示DAS 场景下盘的选择比很多人想的更重要。机械盘适合大容量顺序写SSD 适合随机 IONVMe 适合低延迟高并发。混插时注意控制器和背板的带宽分配别让几块高速盘被一条窄链路卡住。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决定单次读写的数据块大小万兆环境建议设到 1MBhard和soft决定服务端无响应时的行为hard会一直重试保证数据一致性但可能卡住进程soft会超时返回错误适合能容忍失败的场景intr允许中断挂起的操作交互式环境建议加上。生产环境里数据库、虚拟化这类不能容忍静默错误的场景用hard更稳妥。mount -t nfs -o rw,hard,rsize1048576,wsize1048576,vers4.1,noatime \ 192.168.10.20:/export/data /mnt/dataSMB 在 Linux 上挂载则要注意协议版本和缓存策略。vers3.0及以上支持多通道和更完善的锁机制cachestrict保证一致性但性能一般cacheloose适合只读共享。实际项目里如果客户端主要是 Windows直接用系统自带客户端最省心如果是 Linux 访问 SMB记得把uid、gid、file_mode、dir_mode设对否则挂上来全是 root 权限后续权限管理会乱套。mount -t cifs //192.168.10.21/share /mnt/share \ -o usernamesvc_storage,vers3.0,uid1000,gid1000,file_mode0664,dir_mode0775NAS 侧的调优核心是把元数据和数据分开看。如果业务以小文件为主优先考虑服务端是否支持元数据加速、是否有 SSD 缓存层、是否开启了目录索引优化。网络侧则要确认 MTU 一致万兆环境开启巨帧MTU 9000能减少协议开销但要求链路上所有设备都配成一样否则会出现能 ping 通但大包丢失的怪现象。3.3 NAS 的典型问题小文件、锁、权限映射小文件性能是 NAS 最常见的投诉来源。一个目录下几十万个文件ls都要转半天更别说遍历扫描。根因在于每次目录读取和文件属性查询都要走网络往返加元数据服务。缓解办法有几个按时间或哈希做目录分片避免单目录文件数过万业务侧合并小文件再写入比如打包成 tar 或列式存储格式服务端加 SSD 元数据缓存。这些手段能改善但改变不了“小文件不适合网络文件系统”的基本事实真有大规摸小文件场景本地盘加对象存储往往是更合理的选择。文件锁的问题更隐蔽。多个客户端同时写同一个文件时NFS 的锁机制在不同版本和不同实现之间行为差异不小轻则写入覆盖重则应用报错。我的建议是不要让多个客户端并发写同一个文件。真需要并发写要么在应用层做分片要么用支持分布式锁的存储方案。SMB 的锁相对完善但也要注意客户端缓存导致的可见性延迟一个客户端写完另一个客户端可能还在读旧缓存。权限映射则是运维天天见的坑。NFS 的 UID/GID 对不上表现为 Permission deniedSMB 的 ACL 配错表现为能进目录但打不开文件。排查时先确认客户端和服务端的用户映射关系再检查共享目录的导出配置最后看上层 ACL。对于跨平台共享统一用名字映射服务如 ID 映射比手工对齐数字 ID 靠谱得多。现象常见根因排查顺序挂载成功但读写报权限错误UID/GID 不匹配、导出配置限制核对客户端用户 ID、检查 exports 配置小文件操作极慢元数据往返次数多、单目录文件过多统计目录文件数、观察服务端元数据负载多客户端写入内容错乱缺乏有效文件锁、缓存不一致检查挂载参数、确认是否并发写同一文件大文件传输达不到带宽MTU 不一致、链路协商速率低检查巨帧配置、确认网卡与交换机速率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 常见问题速查表问题现象可能原因处理方向NAS 挂载后写入速度只有几十 MB/s链路协商到千兆、MTU 不一致检查网卡速率与交换机端口、统一巨帧配置SAN 主机识别到重复磁盘多路径未配置或配置错误检查 multipath 服务状态与 WWID 绑定两台主机写入同一 LUN 后文件系统损坏缺少集群文件系统仲裁改为单主机挂载或部署集群文件系统DAS 阵列重建期间业务卡顿重建占用大量 IO、未限速设置重建速率上限错峰执行NFS 客户端偶发卡死服务端无响应、hard 挂载持续重试检查服务端负载与网络评估是否改 soft备份任务跑不完小文件过多、元数据瓶颈改为打包备份或改用块级快照5.3 性能验证怎么测才算数选型阶段最忌讳只看厂商参数一定要自己做一轮贴近业务的测试。测试方法不需要多复杂但要注意几点。第一测业务真实的 IO 模型。数据库看 8K 随机读写虚拟化看 4K 到 16K 混合随机媒体看大块顺序。用错模型测出来的数字毫无意义。第二同时测延迟和 IOPS。IOPS 高但延迟抖动大的存储跑批处理可能没问题跑在线业务就会出事故。第三在接近满载的条件下测。空载跑出来的数字都好看把容量填到七成以上再测才能看出真实水平。具体工具上块设备用 fio 最灵活可以自定义块大小、队列深度、读写比例文件级可以用 dd 做粗略的顺序测试小文件场景则要写脚本模拟真实的创建和遍历。测试时记得在客户端和服务端同时观察资源占用确认瓶颈到底在磁盘、网络还是 CPU否则优化方向会跑偏。# 8K 随机读队列深度 32跑 60 秒 fio --namerandread --ioenginelibaio --direct1 --bs8k \ --iodepth32 --rwrandread --size4G --runtime60 --numjobs4 \ --filename/mnt/data/testfile --group_reporting最后分享一个我在实际项目里踩出来的经验存储方案确定之后一定要把容量水位、性能基线、故障切换这三件事做成日常监控项而不是等出问题再查。容量到七成就该规划扩容性能基线偏离两成就该排查原因故障切换每半年至少演练一次。这三件事做到位比选型时多纠结两周有价值得多。