NAS、SAN和DAS有什么区别？服务器存储架构选择指南

给服务器加存储时，你会遇到三个缩写：DAS、NAS、SAN。它们都叫"存储"，但工作在不同的层级，解决完全不同的问题。选错了要么是花了冤枉钱，要么是性能达不到预期。

最容易混淆的是 NAS 和 SAN：两者都是"通过网络访问存储"，但 NAS 给你的是文件系统（你挂载的是一个目录），SAN 给你的是块设备（你拿到的是一块"硬盘"）。这个区别决定了它们的性能特征、共享能力和适用场景。这篇文章从协议层级讲清楚三者的本质差异，给出完整的对比表和选型建议，并顺带说明分布式存储与对象存储在现代架构里的定位。

一、三种架构的本质区别：看协议层级

理解这三种架构，最关键的是看"存储协议发生在哪一层"。

应用
  ↓
文件系统（ext4 / xfs / NTFS）     ← 这一层由谁负责，是关键分界线
  ↓
块设备层（/dev/sdb）
  ↓
物理介质（磁盘）

DAS：直连，文件系统在服务器本地

硬盘直接接在服务器上（服务器内置盘位，或者通过 SAS/SATA 线外接一台磁盘阵列）。服务器看到的是一块裸盘 /dev/sdb，自己在上面格式化、创建文件系统。

关键点：文件系统由这台服务器独占管理。 别的机器看不到这个文件系统，也就无法直接访问里面的文件。

NAS：网络附加存储，文件系统在存储设备端

存储设备（NAS 一体机，或者一台跑 NFS/Samba 的服务器）自己管理文件系统，通过网络把目录共享出来。客户端用 NFS 或 SMB 协议挂载这个目录，像本地目录一样读写。

关键点：文件系统由 NAS 设备独占管理，多个客户端同时挂载同一个目录。 客户端看到的是"文件"这个抽象，不是裸盘。

SAN：存储区域网络，文件系统仍在服务器本地

SAN 通过专用网络（FC 光纤通道，或者基于以太网的 iSCSI）把块设备送给服务器。服务器看到的是 /dev/sdb，然后自己在上面格式化。

关键点：文件系统还是由服务器自己管理，但底下的那块"盘"其实在远端的存储阵列上。 对操作系统来说，它和本地硬盘没有区别。

一句话区分

架构	你拿到的是什么	文件系统在哪	类比
DAS	一块盘	服务器本地	自己家的硬盘
NAS	一个目录	存储设备端	网盘、共享文件夹
SAN	一块盘（远端的）	服务器本地	把硬盘线延长了几百米

为什么这个区别很重要？ 因为文件系统是"独占"的。传统文件系统（ext4、xfs、NTFS）设计时假定只有一个操作系统能修改磁盘上的元数据。多个服务器同时挂载同一个块设备并各自格式化文件系统，会立刻导致元数据冲突和数据损坏。这就是 NAS 和 SAN 在共享能力上的根本差异：

• NAS 天然支持多机共享：因为文件系统在 NAS 设备上，所有客户端都通过协议向它请求，由它统一协调锁和元数据
• SAN 的多机共享需要额外机制：要么用集群文件系统（如 OCFS2、GFS2、VMware VMFS）来协调，要么干脆只让一台服务器用这块 LUN

二、DAS：直连存储

形态

• 服务器内置硬盘：最常见的形式，机器前面板插几块盘
• 外挂磁盘阵列：通过 SAS 线连接一台 JBOD（只是一堆盘，没有 RAID 逻辑）或带 RAID 控制器的阵列柜

优点

延迟最低。 数据不经过网络，直接走 SAS/SATA 总线。NVMe 直连的延迟可以低到几十微秒，这是任何网络存储都达不到的。

简单。 没有网络配置、没有存储网络、没有多路径，插上就能用。排障也简单——dmesg 和 smartctl 就能定位大部分问题。

成本最低。 不需要额外的存储设备、交换机、HBA 卡。

性能好且可预测。 没有网络拥塞、没有协议开销，性能等于硬盘本身。

缺点

无法共享。 一块盘只能给一台服务器用。多台服务器需要同一份数据时，只能靠应用层同步或者复制多份。

容量受限于单机。 一台服务器能插的盘数是有限的（通常 8 到 24 块），超过就要外挂阵列柜。

无法做存储层面的在线迁移。 想把一块盘从这台机器挪到那台机器，基本要停机。

没有存储层的高级功能。 快照、克隆、精简配置这些通常由存储阵列提供的能力，DAS 上要么没有，要么靠软件层实现（LVM 快照、文件系统快照）。

典型用途

• 单台服务器的本地盘（系统盘 + 数据盘）
• 单机数据库（MySQL、PostgreSQL）——这是 DAS 最经典的应用，因为数据库自己管理数据文件和缓存，不需要共享，且对延迟极度敏感
• 开发测试环境

实操：识别本地盘

lsblk                      # 看块设备与挂载点
lsscsi                     # 看 SCSI/SAS 设备
sudo smartctl -a /dev/sdb  # 看硬盘健康
cat /sys/block/sdb/queue/rotational    # 1=机械盘, 0=SSD

三、NAS：网络附加存储

协议

NFS：Unix/Linux 世界的标准，客户端用 mount -t nfs 挂载。NFS v3 简单但无状态（锁管理靠辅助协议），NFS v4 有状态、支持更好的锁和 ACL。

SMB/CIFS：Windows 世界的标准，也常被称为 Samba（Linux 上实现 SMB 的服务就叫 Samba）。Windows 客户端可以直接映射网络驱动器。

还有用于特定场景的：AFP（macOS，已逐渐淘汰）、以及各大云厂商提供的 NFS 兼容接口（比如云上的 NAS 文件存储服务）。

优点

共享最方便。 多台服务器挂载同一个目录，看到的是同一份数据。这是 Web 集群共享静态资源（图片、附件、用户上传文件）最简单直接的方案。

配置简单。 服务端配一个 exports，客户端一条 mount 命令，不需要 HBA 卡、不需要专用网络。用普通以太网就行。

支持文件级操作。 可以直接 ls、cp、看文件属性，运维直观。备份时可以直接拷贝文件。

成本低。 一台装了几块盘的服务器跑 NFS 就是最简朴的 NAS；商用 NAS 一体机的价格也远低于 SAN 存储。

缺点

协议开销较大，延迟高于 DAS/SAN。 每一次文件操作都要走网络往返：路径解析、权限检查、元数据查询都会产生多次 RPC。小文件随机读写的性能尤其差。

单点问题。 传统 NAS 是一个设备（或一对主备），它挂了所有挂载它的客户端都受影响。虽然有高可用方案，但成本和复杂度都上去了。

扩展上限有限。 单个 NAS 命名空间的性能有上限（由其控制器 CPU、内存、网络带宽决定），不像分布式存储那样能线性扩展。

文件锁与一致性问题。 NFS 的锁语义在不同版本下表现不同，多机同时写同一个文件需要应用层自己保证（通常的做法是避免同时写同一文件）。

网络依赖。 网络抖动、丢包会直接影响文件访问；NFS 服务不可用时，客户端上的挂载点会卡住（进程进入不可中断的 D 状态），这个现象很常见也很烦人。

实操：NFS 挂载

服务端（以 Linux 为例）：

# RHEL/CentOS/Rocky
sudo dnf install -y nfs-utils
sudo systemctl enable --now nfs-server

# Debian/Ubuntu
sudo apt-get install -y nfs-kernel-server
sudo systemctl enable --now nfs-server

配置共享（/etc/exports）：

/data/share  10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash)

sudo exportfs -rav
sudo exportfs -v          # 查看已导出的目录

no_root_squash 允许客户端的 root 保持 root 权限，方便但有安全风险。生产环境建议用默认的 root_squash，并通过 uid/gid 映射管理权限。

客户端挂载：

# RHEL/CentOS/Rocky
sudo dnf install -y nfs-utils
# Debian/Ubuntu
sudo apt-get install -y nfs-common

sudo mkdir -p /mnt/nas
sudo mount -t nfs -o vers=4,noatime,nodiratime 10.0.0.100:/data/share /mnt/nas

写入 /etc/fstab 实现开机挂载：

10.0.0.100:/data/share  /mnt/nas  nfs  defaults,noatime,hard,timeo=600,retrans=2,_netdev  0  0

_netdev 参数很重要：它告诉系统这个挂载依赖网络，要等网络就绪后再挂载，否则开机时可能因为网络未就绪而挂载失败，甚至导致系统启动卡住。

hard vs soft：hard 模式下服务端不可用时客户端会一直重试（进程卡住），soft 模式会在超时后返回错误。数据库类应用要用 hard（避免拿到错误结果），但要知道它会让进程卡住；对可用性要求高的场景要配合监控和快速切主。

风险提示：在 NFS 挂载点上跑数据库是常见误区。 NFS 的锁语义、缓存一致性和延迟特征与本地文件系统差异很大，MySQL 这类数据库跑在 NFS 上会出现性能问题和难以排查的一致性故障。数据库的 data 目录必须使用本地盘或 SAN 块设备，不要用 NFS。

查看挂载与排障：

df -hT | grep nfs
mount | grep nfs
showmount -e 10.0.0.100        # 看服务端导出了哪些目录
nfsstat -c                     # 客户端统计
rpcinfo -p 10.0.0.100          # 检查 RPC 服务是否可用

典型用途

• Web 集群共享静态资源（用户上传的图片、附件、视频）
• 部门文件共享、办公网盘
• 容器集群的共享存储（Kubernetes 的 PV 用 NFS 是很常见的方案）
• 备份落地目录（多台机器把备份写到同一个 NAS）
• 影视/设计行业的素材共享（这类行业对共享和大文件顺序读写需求强）

四、SAN：存储区域网络

两种主要形态

FC SAN（光纤通道）：用专用的光纤通道网络（8/16/32 Gbps），需要 FC HBA 卡、光纤交换机、光纤线缆。性能最好、延迟最低、也最贵。

IP SAN（iSCSI）：把 SCSI 命令封装在 TCP/IP 上跑，用普通以太网（建议万兆以上）。成本低得多，性能略逊于 FC，但对大多数场景够用。

还有 FCoE（FC over Ethernet）等过渡技术，实际部署不常见。

核心概念

• LUN（Logical Unit Number）：存储阵列划分出来的一块逻辑盘，映射给服务器后表现为 /dev/sdX
• Target / Initiator：存储端叫 Target，服务器端叫 Initiator
• ** zoning / LUN masking**：控制哪些服务器能看到哪些 LUN，是 SAN 的安全边界
• 多路径（Multipath）：服务器通过多条物理路径连到同一个 LUN，既提高带宽又提供冗余

优点

块级访问，性能接近本地盘。 没有文件系统的协议开销，服务器直接读写块。配合 FC 网络，延迟可以做到接近本地 DAS 的水平。

容量与性能可独立扩展。 存储阵列可以加盘、加控制器，服务器侧几乎无感。

企业级功能丰富。 存储阵列提供快照、克隆、远程复制（同步/异步）、精简配置、自动分层、QoS 等能力。基于阵列的快照是数据库备份的重要手段（几秒钟生成一个一致性快照，然后挂载到别的主机做备份，对生产库几乎无影响）。

高可用性设计完善。 双控制器、双交换机、多路径，全链路冗余。

支持集群。 配合集群文件系统（VMFS、OCFS2、GFS2），多台服务器可以同时访问同一个 LUN——这是 VMware 虚拟化集群和 Oracle RAC 这类场景的基础。

缺点

成本高。 FC SAN 需要 HBA 卡、光纤交换机、光纤线、存储阵列本身，总体投入往往比同等容量的 NAS 高数倍。运维也需要专门技能。

复杂度高。 zoning、LUN masking、多路径配置、固件版本兼容性，每一环都有出错的可能。一个配置错误可能导致某台服务器看到不该看到的 LUN，进而破坏数据。

共享需要集群文件系统。 前面说过，普通文件系统不能多机同时挂载同一个 LUN。如果误操作让两台服务器都以 ext4 挂载了同一个 LUN，数据损坏几乎是必然的。

网络是新的故障域。 光纤交换机故障、链路问题会导致存储不可达，排障比本地盘复杂。

实操：iSCSI 配置（Linux initiator）

# RHEL/CentOS/Rocky
sudo dnf install -y iscsi-initiator-utils
# Debian/Ubuntu
sudo apt-get install -y open-iscsi

发现与登录：

sudo iscsiadm -m discovery -t sendtargets -p 10.0.0.200
sudo iscsiadm -m node -T iqn.2026-01.com.example:storage.lun1 -p 10.0.0.200 --login
sudo iscsiadm -m session -P 1        # 查看会话

登录后会出现新的块设备：

lsblk
lsscsi

配置开机自动登录：

sudo iscsiadm -m node -T  -p 10.0.0.200 --op update -n node.startup -v automatic
sudo systemctl enable iscsid

多路径配置：

# RHEL/CentOS/Rocky
sudo dnf install -y device-mapper-multipath
sudo mpathconf --enable --with_multipathd y
sudo systemctl enable --now multipathd
sudo multipath -ll

风险提示：iSCSI LUN 登录后表现为一块新盘，mkfs 之前务必反复确认盘符正确——格式化错盘会直接毁掉数据。建议用 multipath -ll 和 lsblk 交叉确认，并用 /dev/mapper/ 下的稳定名称或 UUID 而不是 /dev/sdX（sdX 的编号在重启后可能变化）。

典型用途

• 虚拟化集群（VMware、OpenStack）：虚拟机镜像放在共享 LUN 上，才能做虚拟机在线迁移（vMotion）和高可用
• 数据库集群（Oracle RAC）：多节点共享同一份数据
• 关键业务数据库：利用存储阵列的快照做备份
• 需要大容量且要在线扩展的核心业务

五、完整对比

维度	DAS	NAS	SAN
访问方式	直连总线（SAS/SATA/NVMe）	网络文件协议（NFS/SMB）	网络块协议（FC/iSCSI）
呈现给服务器	块设备 /dev/sdX	目录（已格式化的文件系统）	块设备 /dev/sdX
文件系统位置	服务器本地	存储设备端	服务器本地
协议层级	无网络协议	文件级	块级
延迟量级	最低（几十微秒）	较高（毫秒级）	低（亚毫秒到毫秒，FC 更低）
多机共享	不支持	天然支持	需要集群文件系统
扩展性	受单机盘位限制	中等（受控制器限制）	高（阵列可在线扩容）
典型带宽	由总线决定（SAS 12/24G、NVMe 更高）	千兆到万兆以太网	8/16/32G FC，或 10/25G 以太网
成本	最低	中	最高
运维复杂度	低	中	高
高级功能	少（靠软件层）	中（快照、配额、ACL）	丰富（快照、克隆、远程复制、QoS）
典型产品形态	服务器内置盘、外挂 JBOD	NAS 一体机、NFS 服务器	企业级存储阵列
典型场景	单机数据库、本地存储	文件共享、Web 静态资源	虚拟化、数据库集群

六、分布式存储与对象存储

现代架构里还有两类存储，它们不是 DAS/NAS/SAN 的直接替代品，而是解决不同规模下的问题。

分布式存储

Ceph、GlusterFS、MinIO（分布式模式）、以及各大云厂商的分布式块存储，本质是把很多台普通服务器的本地盘（DAS）通过网络聚合起来，用软件层实现副本或纠删码，对外提供块、文件、或对象接口。

它的核心特点是：用"多副本 + 软件定义"替代"专用硬件的高可靠"。 三副本意味着任意一台服务器宕机数据都不丢，且能自动恢复。扩展性可以做到近线性——加机器就加容量和性能。

代价是： 延迟高于本地盘（要跨网络多次往返）、运维复杂度高（Ceph 的调优是个专门的技能）、以及需要至少三台（通常更多）服务器才能组建。

什么时候用它：服务器数量多（十台以上）、数据量达到几十 TB 以上、需要弹性扩展、且能接受比本地盘高一些的延迟。云厂商的云盘底层基本都是这类架构。

什么时候不用它：只有两三台服务器、数据量几个 TB——这时候分布式存储的成本（至少三节点）和复杂度远超收益，不如直接用本地盘加 RAID。

对象存储

S3、OSS、COS 这类服务提供的是"对象"接口：通过 HTTP API 存取，扁平的 bucket + key 结构，没有目录树，不支持随机改写（只能整体替换）。

特点：

• 容量几乎无限、按需付费，单 GB 成本通常是最低的
• ** durability 极高**（多副本或纠删码 + 跨可用区）
• 延迟高（HTTP 请求，几十毫秒级）、不适合做数据库的底层存储
• 支持生命周期管理（自动转冷存储、自动过期删除）
• 适合存放：图片视频等静态资源、备份归档、日志文件、大数据分析的数据湖

对象存储最常见的用法：数据库备份的最终归档地、网站的静态资源（配合 CDN）、日志的长期留存。用 S3FS 之类的方式把对象存储挂载成文件系统是可行的，但性能和一致性都不理想，不要在上面跑数据库。

七、选型建议

按场景直接给结论

场景	推荐	理由
单机数据库（MySQL/PG）	DAS（本地 NVMe SSD，做 RAID 10）	延迟最低，数据库自己管理缓存，不需要共享
多台 Web 服务器共享图片附件	NAS（NFS） 或对象存储	天然支持多机共享，配置简单
网站静态资源（图片/视频/下载）	对象存储 + CDN	成本最低、容量无限、自带 CDN 加速
虚拟化集群（VMware）	SAN（FC 或 iSCSI）	需要共享 LUN 才能做在线迁移与高可用
Oracle RAC 等多节点数据库集群	SAN（FC）	必须共享块设备
关键业务数据库 + 需要快照备份	SAN 或本地盘 + LVM/文件系统快照	阵列快照对生产影响极小
数据库备份归档	对象存储（或 NAS 做中转）	成本低、容量大、可跨地域
容器集群的共享卷	NAS（NFS） 或分布式存储	K8s 的 PV 支持多种后端，NFS 最简单
大数据/日志/数据湖	分布式存储或对象存储	容量与吞吐优先，延迟不敏感
服务器数量多、数据量大	分布式存储（Ceph 等）	弹性扩展、多副本自愈

决策的几个判断点

第一问：需要多台服务器同时访问同一份数据吗？

• 不需要 → DAS（最简单、最快、最便宜）
• 需要，而且是文件级共享 → NAS
• 需要，而且要块级共享（集群文件系统/数据库集群）→ SAN

第二问：对延迟有多敏感？

• 数据库主库、高频交易类 → 本地 NVMe（DAS），不要网络存储
• 一般业务 → SAN 可接受
• 文件存取、备份、静态资源 → NAS 或对象存储都行

第三问：数据量多大、要怎么扩展？

• 几 TB 以内 → 本地盘或单台 NAS
• 几十 TB 且要平滑扩展 → 分布式存储
• 海量且访问频率低 → 对象存储

第四问：预算和运维能力如何？

• 没有专职存储运维 → DAS 或托管服务（云盘、云 NAS、对象存储），别自建 Ceph
• 有专职团队且规模足够 → 分布式存储能显著降低成本

一个典型的中小企业组合

Web/应用服务器：本地 SSD（DAS）跑系统和代码
数据库服务器：本地 NVMe SSD 做 RAID 10（DAS）
用户上传文件：一台 NAS 或直接用对象存储
备份：先落地到 NAS，再同步一份到对象存储（异地）

这套组合成本可控、运维简单，覆盖了绝大多数中小规模业务的需求。不要为了"架构先进"上用不上的东西。

云环境下的对应关系

传统概念	云上的对应
DAS	云盘（本地 SSD 盘 / 云硬盘）
NAS	文件存储服务（NFS 接口）
SAN	云硬盘 + 多挂载（部分厂商支持共享块存储）
分布式存储	云盘的底层实现（用户不可见）
对象存储	对象存储服务（OSS/COS/S3）

云环境下一般不需要自己搭 NAS/SAN，直接用云厂商提供的对应服务即可，省掉硬件运维。但要注意：云盘的性能受规格限制（IOPS 和吞吐有配额），选型时要看清楚规格说明。

常见问题

数据库能不能跑在 NAS 上？

不能（或者说强烈不建议）。 数据库的 data 目录需要本地块设备的语义：直接 IO、文件锁、fsync 行为、以及低延迟。NFS 在这些方面的行为与本地文件系统差异很大，会导致性能极差、以及难以排查的一致性故障。数据库用本地盘（DAS）或 SAN 的块设备。

SAN 一定比 NAS 快吗？

通常块级访问（SAN）的延迟和吞吐优于文件级（NAS），但这不是绝对的。高端 NAS 配万兆网络和 SSD 缓存，性能可能超过低端 SAN 配机械盘。更准确的说法是：SAN 的延迟下限更低、更适合随机小 IO；NAS 在顺序大文件读写上也能做得很好。

两台服务器能同时用一块 SAN LUN 吗？

可以，但必须配集群文件系统（VMware VMFS、OCFS2、GFS2 等）。如果两台服务器都用 ext4/xfs 挂载同一个 LUN，会立刻造成元数据冲突和数据损坏——因为它们都认为自己独占这块盘。普通场景下，一块 LUN 只给一台服务器用，这是最安全的做法。

自建 Ceph 划算吗？

大多数中小企业不划算。Ceph 的生产部署至少需要 3 个节点（推荐 5 个以上）、万兆网络、专用 SSD 做 journal/db，还要有懂它的人调优和排障。如果你的规模不到几十 TB、没有专职存储运维，直接用云盘或商业 NAS 更省心。 云厂商的云盘底层就是这类技术，你享受了它的好处而不用自己维护。

对象存储能当网盘用吗？

可以，但要理解它的语义：它不是文件系统，没有真正的目录（只是 key 的前缀模拟），不支持文件的部分修改，重命名和移动大文件实际上是一次拷贝。适合存"一次写入、多次读取、很少修改"的数据（图片、视频、备份包、日志）。需要频繁修改的文档共享还是用 NAS 或专业的文档协作系统。

为什么数据库服务器还要用本地盘而不是共享存储？

因为数据库（MySQL/PostgreSQL 这类）的架构假定自己是数据唯一的管理者：它自己做缓存（buffer pool）、自己的锁、自己的事务日志。共享存储带来的好处（多机访问）对单机数据库没用，反而引入了额外的延迟和故障点。只有当数据库本身是多节点集群架构（如 Oracle RAC）时，共享存储才是必需的。

存储网络要单独隔离吗？

要。无论是 NFS 还是 iSCSI，存储流量都应该走独立的网络（独立的网卡、独立的交换机/VLAN）。原因：存储流量对延迟和丢包敏感，与业务流量混跑会互相影响；而且存储网络上跑的是未加密的数据（NFS 默认不加密），隔离也是安全需要。iSCSI 尤其建议独立网络甚至独立交换机。

怎么判断当前磁盘是本地盘还是网络存储？

lsblk -d -o NAME,SIZE,ROTA,MODEL
lsscsi                      # 看设备类型，iSCSI 会显示 IET/VENDOR 为存储厂商
cat /sys/block/sdb/queue/rotational

更可靠的方式是看内核日志和 /sys 下的设备路径：

dmesg | grep -i -E 'scsi|iscsi|nvme'
ls -l /sys/block/sdb          # 看它挂在哪条总线下

如果是云主机，云盘通常显示为 vda/vdb（virtio 虚拟设备）。

总结

• 看协议层级就能分清三者：DAS 是直连裸盘（文件系统在本地）；NAS 给你一个已格式化的目录，文件系统在存储设备端，所以天然支持多机共享；SAN 给你一块远端裸盘，文件系统仍在服务器本地，多机共享必须配集群文件系统。
• DAS 赢在延迟和简单：单机数据库就该用本地 NVMe SSD 做 RAID 10，延迟几十微秒，数据库自己管理缓存和锁，共享对它没意义。不要为了"看起来专业"给单机数据库配 SAN。
• NAS 赢在共享便利：NFS/SMB 让多台 Web 服务器挂载同一份静态资源，配置只需一条 mount。挂载时记得加 _netdev（等网络就绪）和 hard 模式（数据库类应用避免拿错误结果）。但绝不要把数据库的 data 目录放在 NFS 上。
• SAN 赢在企业级能力和块级共享：虚拟化集群的在线迁移、Oracle RAC 的多节点共享、基于阵列快照的秒级备份，这些是 SAN 的专属价值。代价是成本高、复杂度高（zoning、多路径、固件兼容），且普通文件系统多机挂载同一 LUN 会直接毁数据。
• 现代架构还有两个选项：分布式存储（Ceph 等）用多副本替代专用硬件，适合十台以上服务器、几十 TB 以上的规模，但运维门槛高，小团队不要自建；对象存储成本最低、容量无限，适合静态资源、备份归档和日志，但延迟高、不能做数据库底层存储。
• 选型按四问走：要不要多机共享 → 对延迟多敏感 → 数据量多大怎么扩展 → 预算和运维能力如何。中小企业的经典组合是"应用用本地 SSD、数据库用本地 NVMe RAID 10、共享文件用 NAS 或对象存储、备份先落 NAS 再同步到对象存储"。
• 存储网络要独立：NFS 和 iSCSI 流量应与业务网分离（独立网卡/VLAN），既是性能隔离也是安全需要。云环境下直接用托管服务（云盘、文件存储、对象存储），不必自建 NAS/SAN，但要注意云盘的 IOPS 与吞吐配额。