企业官网建设流程全解析

三种存储架构放在一起讨论，最容易跑偏的地方是把它们当成"快慢排序"来比。DAS、NAS、SAN 这三个词，真正划分的不是性能档次，而是文件系统到底跑在谁身上、数据以什么粒度被访问、共享的边界画在哪里。这三件事定下来，性能、成本、运维方式全都是推论。我在实际项目里见过太多团队，一开始就纠结"NAS 是不是比 SAN 慢"，纠结了半个月，最后发现真正的瓶颈是那台机器上跑着一个单线程的小文件读写任务，换成什么架构都一样卡。这篇内容适合正在做存储选型的人、被"块存储/文件存储"绕晕的运维和开发，也适合想把老架构重新盘一遍的负责人。下面我按"先把边界讲清楚、再逐个拆解、最后落到选型和排错"的顺序来写，能直接抄的部分我会给命令和参数。

1. 三种架构真正的分界线：文件系统落在谁手里

1.1 一句话判断法：谁在管文件系统

判断一套存储属于哪一类，不用看它长什么样、插什么线，只问一个问题：这块空间上的文件系统，是主机在管，还是存储设备在管？

主机管，就是块级访问。存储设备只是把一堆连续的扇区（块）交出去，主机拿到/dev/sdb这样一个裸设备，自己格式化成 ext4、XFS，自己维护目录树、inode、权限位。DAS 和 SAN 都归这一类，区别只在"块设备是怎么送到主机面前的"——DAS 是线直接插在机器上，SAN 是块设备穿过了一张专用网络。

存储设备管，就是文件级访问。设备自己有一整套文件系统，对外只暴露"目录"和"文件"，主机通过 NFS 或者 SMB 协议去读写。NAS 归这一类。

这个区别听起来像概念游戏，实际影响非常大。举个生活里的类比：DAS 和 SAN 像是给你一块空地，你自己设计、自己盖房、自己装修，怎么折腾都行，但邻居进不来；NAS 像是给你一套已经装修好的公寓，你只能往里搬家具，格局动不了，但一把钥匙可以给很多人。

1.2 三者的对位关系

把关键维度摊开对照，很多模糊的争论会瞬间清晰：

注意表里"多主机并发读写同一空间"这一行。这是三种架构在业务层面差异最直接的一行，比带宽数字重要得多。NAS 天生就是给多台机器共享同一份数据设计的；DAS 和 SAN 交给你的是一块裸地，两台主机同时挂载同一个块设备去写，结果就是文件系统元数据互相踩踏，轻则目录错乱，重则整块数据报废。想让它支持共享，得换集群文件系统，那又是另一套东西了。

1.3 "NAS 慢、SAN 快"是半截话

这句话在十年期 SSD 还没普及的年代有一定道理，现在直接拿来当选型依据基本会翻车。

NAS 走的是以太网和文件协议栈，确实比块级多了一层元数据处理和协议协商；但今天的万兆、25G 以太网，加上 NFSv4.2 的多连接和服务端并行处理，大文件顺序读的吞吐能轻松压满链路。反过来，一台配置糟糕的 SAN——单口 HBA、没开多路径、LUN 全部压在一个控制器上——实测跑不过一台调优过的 NAS 是常有的事。

真正该问的不是"哪个快"，而是"我这个业务访问的粒度是什么"。数据库跑的是 8KB、16KB 的随机小块；视频剪辑跑的是几十 GB 的大文件顺序读写；代码仓库跑的是成千上万个几 KB 的小文件加海量元数据操作。这三种负载在三套架构下的表现完全不是一回事。

2. DAS：延迟路径最短，代价是数据孤岛

2.1 直连架构到底省掉了什么

DAS 的数据路径极短：磁盘或 SSD 通过 SAS、SATA 或 PCIe 直接连到主机的控制器上，中间没有交换机、没有协议转换、没有网络栈。这条路径上省掉的每一层，都是一份延迟和一份故障点。

以一块企业级 NVMe SSD 直连为例，主机侧感知到的读延迟通常在一百微秒以内；同样的盘放进走网络的存储里，端到端延迟要加上协议封装、网络传输、目标端处理的开销，落到几百微秒是正常的。对于高频交易类的前置缓存、实时音视频处理、本地数据库的 WAL 日志盘，这个差距是实打实能感知到的。

我一般的判断标准是：如果这块数据天然只属于一台机器，而且这台机器对延迟敏感，DAS 就是最省事也最快的解法。单机数据库的数据盘、日志盘、分析节点的临时目录、GPU 训练节点的本地高速缓存盘、边缘采集设备的数据落地盘，都属于这个范畴。

2.2 被忽略的成本优势

除了快，DAS 还有一个常被低估的优点：它就是便宜，而且便宜得很干脆。

一台机器加几块盘，加一张 RAID 卡或者 HBA，完事。没有独立的存储阵列要买，没有交换机要买，没有多路径软件要配，没有专门的存储管理员要养。对于规模不大、业务边界清晰的场景，这个成本差距是数量级的。

还有一种情况值得单独提：临时性、短周期的项目。用 DAS 意味着项目结束机器一撤，数据跟着走，不用考虑存储侧的资源回收和权限清理。我在几个短周期的数据处理任务里都优先选本地盘，就是因为省掉了"项目下线后存储上还挂着一堆没人认领的 LUN"这种后遗症。

2.3 DAS 的三个硬伤，以及它们什么时候会咬人

第一个硬伤是孤岛。数据绑在这台机器的物理盘上，别的机器想用，只能通过网络复制或者导出，一来一回延迟和带宽都不划算。机器一坏，数据能不能拿出来取决于 RAID 级别和备件速度。

第二个硬伤是扩容刚性。盘位、控制器端口、机箱空间都是物理上限。有些场景能通过 SAS 扩展柜往下挂，但级联层数、单控制器带盘数量都有天花板。更麻烦的是扩容往往要停机或者重建 RAID，重建期间性能和可靠性都会下降。

第三个硬伤是共享冲突。这一点必须重点强调，因为它造成的损失往往是不可逆的。同一个块设备被两台主机同时以读写方式挂载，两边的文件系统各自维护自己的缓存和元数据，谁也不知道对方在改什么，几分钟内就能把目录结构写成一团乱麻。修起来通常只能靠备份恢复。

如果确实需要多机共享本地盘，唯一的正道是用集群文件系统，或者在业务层做分片，让不同机器负责不同区段。硬挂普通文件系统这条路不要走。

2.4 一个容易忽略的细节：RAID 卡缓存策略

直连场景里，RAID 卡的写缓存策略对性能影响极大，而且经常被默认配置坑到。带电池或超级电容保护的卡，写策略设成 Write Back 能显著提升随机写性能；没有掉电保护的话设成 Write Back 就是在赌运气，一次意外断电可能让整个阵列的元数据不一致。

我的做法是：先确认卡上有没有可靠的掉电保护单元，有就开 Write Back，没有就老老实实 Write Through，宁可慢一点。这条经验说出来很简单，但我在不止一个环境里见过为了跑分好看把缓存策略改了、后来出了事查了半天的案例。

3. NAS：把文件系统外包出去，换来了共享和简单

3.1 共享能力是它存在的核心理由

NAS 最大的价值不是速度，是多台机器看到的是同一份数据、同一套权限、同一个目录树。

这个特性在很多业务里是不可替代的。设计团队几十号人共享素材库、研发团队共享构建产物、办公环境共享文档、监控系统把录像往一个中心目录里写——这些场景如果换成块存储，要么每台机器分一块自己的空间然后靠脚本同步，要么上集群文件系统增加复杂度，都远不如直接用 NAS 干净。

从运维角度看，NAS 的日常操作也更友好：加盘、建目录、配配额、调权限，都在存储管理界面里完成，不需要碰主机侧的分区表和文件系统。备份也简单，直接对目录做快照或者同步就行。

3.2 NFS 和 SMB 不是随便挑一个

NAS 上最常见的两种协议是 NFS 和 SMB，选错了后面全是麻烦。

实际踩过最多的坑是 NFS 的 UID 映射。服务端导出的目录，客户端用某个 UID 去访问，如果两边的用户 ID 对不上，就会出现"文件明明存在但读不了"或者"写进去的文件属主是个陌生数字"。稳妥的做法是在关键环境里统一用集中式用户目录，或者在导出时明确指定匿名映射策略，别指望默认行为能对。

SMB 那边最常见的坑是大小写。Windows 侧习惯不区分大小写，Linux 挂载时如果没开对应选项，会出现同一目录下Report.txt和report.txt被当成两个文件，构建脚本直接找不到文件。

3.3 三个性能天花板，以及绕过它们的办法

第一层是元数据开销。小文件密集的负载——比如代码仓库、依赖包缓存、邮件存档——瓶颈几乎从来不是带宽，而是每秒能处理多少次元数据操作。一次stat、一次目录遍历，在 NAS 上都要走一轮协议往返。这类负载上，NAS 的表现和你想象的带宽数字关系不大。

对策是把元数据操作尽量合并：打包传输而不是逐文件复制、用rsync带批量选项、构建时用本地缓存目录再统一同步。有些场景可以通过在客户端做本地缓存层来缓解。

第二层是单流带宽。单个 TCP 连接、单个 NFS 挂载点，往往吃不掉整条链路的带宽。因为协议栈处理、窗口大小、单队列深度都会成为限制。

对策是开多通道。NFS 在 Linux 客户端上可以用nconnect参数开多个连接：

mount -t nfs4 -o vers=4.2,rsize=1048576,wsize=1048576,nconnect=8,hard,timeo=600,retrans=2 192.0.2.10:/export/data /mnt/data

这里几个参数值得说清楚：rsize/wsize设到 1MB 是常见起点，太小会让往返次数暴增；nconnect=8让客户端对同一服务端建立 8 条连接并行传输，单流吃不满带宽时提升明显；hard表示服务端无响应时持续重试而不是直接报错返回，对数据一致性更安全，代价是服务端真挂了客户端会卡住。这几个值不是越大越好，nconnect开太多会加重服务端连接管理负担，一般 4 到 8 是甜点区。

第三层是小文件随机读写。这个最难受，因为它同时撞上元数据和 I/O 两个瓶颈。缓解手段主要靠存储侧的缓存分层——把热点数据放在 SSD 层，冷数据沉到机械盘。但这是存储侧的能力，客户端能做的有限。

3.4 一个容易被忽视的调优项：MTU

万兆环境里，把 MTU 从 1500 调到 9000（巨型帧）能明显降低大包传输的协议开销，提升吞吐、降低 CPU 占用。但这件事必须端到端全链路一致：主机网卡、交换机端口、存储侧接口，任何一跳没配，就会出现大包被丢弃、小包正常、表现为"能 ping 通但传大文件卡死"的诡异现象。

我一般的处理顺序是：先在隔离环境里把链路两端和中间交换机都改好，用ping -M do -s 8972验证不分片能通，再上生产。直接在生产环境改 MTU 然后指望它自愈，风险太高。

4. SAN：卖的不是速度，是块设备的远程化和可控性

4.1 SAN 解决的到底是什么问题

很多人对 SAN 的第一印象是"贵、快、企业级"。它真正提供的核心能力其实是三件事：

块设备的远程化。主机看到的还是/dev/sdX，但这块设备物理上在几十米外的机柜里，中间隔着一张专用网络。这意味着计算和存储可以独立扩展——算力不够加服务器，容量不够扩存储，互不影响。

多路径和冗余。一台主机通过两张 HBA、两条链路连到存储的两个控制器，任何一条链路或一个控制器故障，业务无感知。这个能力在块级网络上是标配，在直连架构上做不到。

在线扩容和迁移。存储侧扩一个 LUN，主机侧在线扩文件系统；换阵列的时候通过底层复制把数据迁过去，主机侧几乎不用停机。

这三件事加起来，才是 SAN 在核心业务系统里长期不可替代的原因。速度只是附带结果。

4.2 FC 和 iSCSI 的取舍

我的实际经验是：核心交易类、对延迟抖动极敏感的业务，FC 仍然更稳，因为它跑在独立网络上，不会因为办公网某台机器突然跑个备份把链路打满而受影响。而绝大多数虚拟化集群、内部业务系统，iSCSI 跑在独立的万兆或 25G 网络上，性能完全够用，成本低一大截，运维也更容易找到人。

关键点在"独立网络"这四个字。iSCSI 和业务流量混跑在同一个网段上，是很多性能问题的根源。最低要求是物理网口分开或者用独立的 VLAN，存储流量单独规划。

iSCSI 的基本接入流程不复杂：

# 发现目标 iscsiadm -m discovery -t sendtargets -p 192.0.2.20:3260 # 登录 iscsiadm -m node -T iqn.2024-01.example:storage.target01 -p 192.0.2.20:3260 --login # 确认会话 iscsiadm -m session -P 3 | head -40

登录之后会多出一个/dev/sdX，接下来就是常规的分区、格式化、挂载。这里有个必须做的动作：在/etc/iscsi/iscsid.conf里把node.startup设成automatic，否则重启后会话不会自动恢复，依赖这块盘的服务直接起不来。

4.3 多路径和 LUN 映射：出事最多的地方

SAN 环境里最常见的两类故障，一类是多路径没配好，一类是 LUN 映射配错。

多路径的配置逻辑是：主机上跑一个多路径服务，把通往同一块 LUN 的多条链路识别成同一个设备，对外只暴露一个/dev/mapper/xxx，同时在多条链路上做负载均衡和故障切换。配好之后用multipath -ll能看到类似这样的输出：

multipath -ll # mpatha (3600a0980...) dm-3 STORAGE,VRAID # size=500G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw # |-+- policy='service-time 0' prio=50 status=active # | `- 2:0:0:0 sdb 8:16 active ready running # `-+- policy='service-time 0' prio=10 status=enabled # `- 3:0:0:0 sdc 8:32 active ready running

看到两条路径一主一备、状态都是 ready，才算配好了。如果只看到一条，或者两块盘各自独立出现，那说明多路径没生效——这时候如果主机直接对其中一块做格式化，切换路径之后数据就对不上了，属于典型的高危配置。

另一个高危点是LUN 映射。存储侧把一个 LUN 分配给某台主机的 WWN 或 IQN，如果分配错了主机，或者把一个已经格式化过的 LUN 分给了新主机，新主机上电一看是块"空白盘"，一格式化，原来那台机器的数据就没了。防御手段是在存储侧建立严格的命名和分配记录，主机侧接入前先确认设备序列号或者 LUN 标识是否匹配。

在 Linux 上可以用lsblk -o NAME,SIZE,SERIAL,WWN或者读/sys/block/sdX/device/wwid来确认设备身份。接入一块来源不明的块设备，先查身份，再动分区表。

4.4 成本结构决定了它不是默认选项

SAN 的成本不只在硬件。HBA 卡、专用交换机、光模块、线缆，这些是显性的；隐性成本在于人——懂 FC 交换配置、懂多路径调优、懂存储阵列管理的工程师，不是随便拉个人就能上手。

所以我的观点一直是：SAN 不该是默认选项，而应该是被业务需求逼出来的选项。只有当"必须多机共享块设备""必须做到链路级冗余""必须在不中断业务的前提下扩容和迁移"这几条里有一条硬性成立时，上 SAN 才划算。否则用 DAS 加 NAS 的组合，成本可能只有三分之一，效果差不多。

5. 选型不该是三选一，而是三者的配比

5.1 用三个坐标轴定位业务

我给业务做存储定位时，习惯问三个问题：

第一个问题：这份数据天然属于一台机器，还是多台机器都要看到？只属于一台，DAS 或 SAN 的块设备；多台都要看，NAS 或者集群文件系统。

第二个问题：访问粒度是块还是文件？数据库、虚拟机的磁盘镜像，是块级访问，必须块存储；文档、素材、代码、日志归档，是文件级访问，NAS 更顺手。

第三个问题：对延迟抖动的容忍度有多高？容忍度极低的核心业务，给独立网络和专用资源；容忍度一般的业务，共享资源完全够。

三轴一交叉，答案基本就出来了，剩下的只是预算权衡。

5.2 场景对照表

5.3 真实环境里的混合形态

实际生产环境很少是纯一种架构。比较典型的一套是：核心数据库跑在 SAN 提供的块设备上，保证多机能共享和链路冗余；虚拟机集群用 iSCSI 挂载集群文件系统；文件共享、素材库、归档走 NAS；每台计算节点再配一块本地 NVMe 做缓存或者临时目录。

这种做法看着复杂，但每一层都有明确的分工：热的、小的、延迟敏感的放本地；核心的、需要共享的放 SAN；大的、共享的、访问模式偏顺序的放 NAS。数据按温度分层，成本按层控制。

要注意的是分层策略一旦定下来，数据流转规则必须写清楚。我见过数据在两个层里各存一份、谁也不敢删、最后容量翻倍的情况。冷热分层的迁移策略、保留周期、谁负责清理，这些管理规则比技术选型更容易出问题。

5.4 超融合和分布式存储把边界搅浑了

这几年超融合和分布式存储流行起来，很多团队会问：既然一套分布式系统就能同时提供块、文件、对象接口，那还分什么 DAS、NAS、SAN？

这里要说清楚：分布式存储是把这三种访问方式在软件层重新实现了一遍，底层仍然是服务器本地盘（也就是 DAS），通过网络聚合后对外提供块和文件接口。所以它并没有让三种架构的分类失效，而是把它们打包成了一个产品。

它带来的实际变化是运维形态：不再需要独立的存储阵列和专用网络，扩容靠加节点，管理界面统一。代价是网络成为关键路径，节点间的东西向流量很大，网络规划不好性能会很难看；另外小规模部署时，副本和纠删码带来的容量开销可能比预期高。

选它之前，我会先算两笔账：一是节点数量和容量规划，少于某个规模时分布式反而更贵；二是网络带宽够不够支撑重建流量，节点故障后的数据重建会吃掉大量带宽，规划时要把这部分留出来。

6. 动手验证：几条能直接复现的判据

6.1 先用 fio 分清是设备慢还是链路慢

性能问题最忌讳拍脑袋。同一个业务跑得慢，可能是盘不行，也可能是链路不行，也可能是协议栈配置不对。用 fio 分层测一下，能快速定位。

# 大块顺序读，看吞吐能否吃满链路 fio --name=seqread --filename=/dev/sdb --direct=1 --rw=read \ --bs=1M --numjobs=1 --iodepth=32 --runtime=60 --time_based --group_reporting # 小块随机读，看 IOPS 和延迟 fio --name=randread --filename=/dev/sdb --direct=1 --rw=randread \ --bs=4k --numjobs=8 --iodepth=32 --runtime=60 --time_based --group_reporting

判读逻辑很直接：顺序读跑不满链路带宽，说明瓶颈在链路或者协议配置；随机读的 IOPS 和延迟远低于设备标称值，说明瓶颈在存储侧或者队列深度不够。两者都正常但业务还是慢，那大概率是上层应用或者文件系统的问题。

强调一句：--filename直接指向裸设备会破坏上面的数据，只能在测试盘或者已经确认可清空的设备上跑。生产环境请用--filename=/mnt/testdir/fiotest指定一个文件来测。

6.2 NAS 挂载卡顿的排查链路

NAS 上最典型的故障是"目录突然打不开，ls和df都卡住"。这时候不要急着重启，按链路往下查：

# 第一步：确认 NFS 服务端可达 ping -c 3 192.0.2.10 # 第二步：确认 NFS 端口通 ss -tnp | grep 2049 # 第三步：看客户端统计，是否有大量重传或超时 nfsstat -c # 第四步：看已挂载的服务端状态 cat /proc/fs/nfsfs/servers

nfsstat -c里如果retrans和timeout持续增长，基本可以断定是网络质量或者服务端负载问题。如果网络没问题，去看存储侧的连接数、会话数和 CPU 负载，很多时候是服务端被大量小文件请求打满了。

我遇到过最隐蔽的一次是链路上有个设备在做流量整形，导致大包被周期性丢弃，表现是"白天正常，晚上备份时段必卡"，查了三天才发现是中间设备的问题。这类问题用mtr或者连续 ping 带大小包对比，能比较快看出来。

6.3 iSCSI 和 SAN 链路的健康检查

SAN 环境我一般固定做三项检查：

# 会话状态 iscsiadm -m session -P 3 | grep -E "State|Internal iscsid Session State" # 多路径状态，重点看每条路径的 status multipath -ll # 块设备队列和错误计数 cat /sys/block/sdb/stat dmesg | tail -50 | grep -i -E "scsi|iscsi|error"

多路径输出里如果出现failed或者faulty状态，说明某条链路已经断了，虽然业务可能还在跑（靠另一条路径），但冗余已经没了，必须当天处理。dmesg里出现大量 SCSI 重试或者超时，说明链路质量有问题或者存储侧响应不过来。

6.4 几条踩过坑之后总结的判据

第一，新设备接入前先确认身份。不管是 LUN 还是共享目录，先用序列号、WWN、导出列表确认它是不是你要的那一个，别凭设备名猜。

第二，共享空间和块设备绝对不要混着用。同一块裸设备两台机器同时挂载普通文件系统，这个坑踩一次可能就是一整天的数据恢复。

第三，性能问题先分层测，再改配置。直接改 MTU、改缓存策略、改队列深度，改完不知道有没有效果，出了问题也不知道是哪一步引入的。

第四，容量规划要算上快照和重建开销。存储侧的快照不是免费的，分布式存储的副本和重建流量也要占资源。规划时留出三成余量，比事后扩容从容得多。

最后分享一个我自己一直在用的习惯：给每套存储环境写一页纸的"身份卡"，记录它的访问方式、挂载点、协议版本、关键参数、负责的人、上次变更时间。真出故障的时候，这一页纸能省掉大量翻配置的时间，也能避免"这块盘到底是谁的"这种低级混乱。存储这行当，架构选对了只是开始，把细节管住才是长期稳定的关键。