★ FEATURED ARTICLE 简介华为HCNA-Storage培训教材V4.0以单个PDF文件交付压缩包约39.06MB面向准备华为存储认证、希望系统补齐数据中心存储基础的工程师与学员。教材从广义与狭义存储定义切入梳理存储系统由硬件架构、软件组件和解决方案构成的关系并重点比较直连存储、网络附加存储、存储区域网络三类架构的差异、典型协议与适用场景涵盖内部与外部直连存储、文件共享协议、光纤通道存储区域网络与IP存储区域网络等内容同时延伸至分布式存储和软件定义存储。读者可据此建立从存储设备、存储网络到数据管理功能的整体认知理解镜像、复制、备份等软件能力及总体拥有成本考量为后续存储选型、规划与运维排错打下基础。已有1241人学习内容体系化较强适合作为入门到进阶的参考资料。1. 三种架构的真相硬盘没变变的是“谁掌握地址翻译权”很多人默认 DAS、NAS、SAN 是三代产品新的淘汰旧的。把这三套东西拆到最底层看磁盘、闪存颗粒、控制器几乎没变变的只是服务器交出去的那一层地址DAS 交块号NAS 交文件名SAN 把块号延伸到了另一个专用网络上。这份存储培训教材 V4.0 开篇先区分“狭义存储”和“广义存储”看着像概念铺垫实际是在给后面所有架构划边界——狭义指软盘、光盘、磁带、硬盘这类具体设备广义指数据中心里的硬件系统、软件系统和存储网络的组合。搞不清这条边界后面 LUN、Zoning、挂载点这些词就会互相打架。下面把三种架构拆到地址翻译这一层来看。2. DAS 的物理边界内部总线为什么注定被外置存储取代2.1 块级服务的本质服务器拿到的是一串编号直连存储DAS为服务器提供的是块级服务注意不是文件系统级。服务器内核里看到的是一块裸设备比如/dev/sdb文件系统是服务器自己在这块裸设备上建的inode、目录项、日志、位图全在服务器这一侧。存储设备那一侧只认一个东西从某个逻辑块地址LBA开始的多少个定长块。这个分工决定了很多后面会反复出现的现象。设备不知道也不关心这些块属于哪个文件它无法判断写请求是否合理——一台服务器如果把文件系统写坏了它下发的垃圾块会被阵列原样落盘设备没有任何能力阻止。反过来DAS 的性能上限就是单台服务器 I/O 栈的上限阵列再快也要过服务器这一道。用一个最小模型把块级语义说明白class BlockTarget: 模拟一个只认 LBA 的块设备没有文件名没有目录只有编号 def __init__(self, name, capacity_blocks, block_size512): self.name name self.capacity capacity_blocks # 总块数决定 LBA 上界 self.block_size block_size # 块大小传统 512B现代盘常见 4KB self._store {} # 稀疏字典只有写过的块才占空间 def read(self, lba, count): # 服务器视角读到的是定长块没有任何文件语义 if lba 0 or lba count self.capacity: # 越界由设备侧直接拒绝因为设备根本不知道文件边界在哪 raise IOError(LBA out of range: %d%d % (lba, count)) return [self._store.get(lba i, b\x00 * self.block_size) for i in range(count)] def write(self, lba, payload): for i, blk in enumerate(payload): assert len(blk) self.block_size, 块长度必须对齐 self._store[lba i] blk disk BlockTarget(/dev/sdb, capacity_blocks1024 * 1024) disk.write(0, [bA * 512]) print(disk.read(0, 1)[0][:4]) # bAAAA这段代码里三个参数值得记住capacity_blocks决定 LBA 的上界block_size决定一次 I/O 的最小粒度_store的稀疏特性说明块设备天然支持“没写过的位置读出来是全零”——这也是精简置备能成立的前提之一。write里的对齐断言对应现实中“块设备只接受整块写入”任何非对齐的写都要由上层补齐。理解了这一层再看 NAS 就会明白它到底把什么东西挪走了。2.2 内部 DAS 的三个天花板内部 DAS 指的是存储设备通过服务器机箱内部的并行或串行总线连接最典型的就是机箱里的那几块硬盘、内置磁带机。它有三个硬约束而且这三个都不是厂商偷懒是物理规律。第一个是距离。早期并行总线窄带 SCSI 的 50 针排线、IDE 的 40/80 芯排线靠多条线同时传一个字的多个 bit线一长各 bit 到达时间就不一致这种偏斜会让接收端的时钟沿对不齐误码率陡增。所以机箱内排线的长度通常被压在几十厘米到一两米。后来的串行总线SAS、SATA改用 SerDes把并行字拆成高速串行比特流靠编码和时钟恢复来对抗偏斜这才把距离和速率同时拉起来——代价是每条链路变成点对点要靠 expander 才能扩出更多端口。第二个是设备数。并行 SCSI 一条总线最多 15 个设备窄带只有 7 个还要占掉一个 ID 给控制器设备一多总线仲裁和终端匹配就变得敏感。串行总线虽然靠 expander 可以扩到上百个盘位但机箱内的盘位、背板走线、供电和散热仍然是硬限制。第三个是维护性也是实际运维里最疼的一个。盘在机箱里换一块盘意味着停机、开盖、动风道风道一乱旁边那些盘的进风温度立刻上去。对 7×24 的业务来说这不叫麻烦叫可用性缺口。培训教材里那句“存储设备放在服务器机箱内部会占用大量空间对服务器其它部件的维护造成困难”说的是同一件事。2.3 外部 DAS把总线变成网络代价是什么外部 DAS 把存储设备搬出机箱服务器与外置盘阵、磁带库直接相连大多数情况走 FC 协议或者 SCSI 协议。它解决了两件事距离和数量。FC 在光纤上可以跑到几百米甚至更远外置盘阵可以挂几十上百块盘集中供电、集中散热、集中管理换盘不用停机开服务器盖子。但“直连”这两个字没有变。一条链路对应一台服务器或者一组 HA 服务器LUN 被这台服务器独占除非上集群文件系统否则别的服务器看不到这块容量。三台服务器要用同一批空间只能各划一块容量孤岛随之出现——A 服务器上剩 8TB 用不上B 服务器却要申请扩容采购单照批。这个矛盾正是 SAN 出现的直接动因也解释了为什么教材在讲完 DAS 之后马上切到 SAN中间没有别的过渡。维度内部 DAS外部 DAS连接方式机箱内并行/串行总线FC 或 SCSI 线缆直连距离约束几十厘米到一两米几十米到数百米取决于介质设备数量受盘位与总线 ID 限制受阵列规格限制可扩展管理方式随服务器分散集中到阵列管理面共享能力无无LUN 仍被单机独占这张表里最后一行是重点。外部 DAS 解决了物理层的问题没有解决共享的问题而共享恰恰是文件级和网络级存储要回答的问题。3. NAS 的重心转移文件系统为什么必须搬到存储设备那一侧3.1 一次 open 背后交换了什么网络附加存储NAS是连接到局域网、基于 IP 的文件共享设备。它和 DAS 最根本的差别不在接口在于文件系统跑在谁那边。DAS 的文件系统在服务器上NAS 的文件系统在存储设备上客户端通过网络协议请求“打开路径/project/a.dwg并从偏移 4096 开始读 64KB”请求用 NFS 或者 CIFS 封装跑在 TCP/IP 之上。请求粒度一变设备侧要维护的东西就完全不同了目录树、文件记录、权限UID/GID 或 ACL、文件锁、客户端缓存一致性。这几样加起来相当于一个小型操作系统所以 NAS 设备有自己的操作系统一点都不奇怪——它必须能独立回答“这个文件在哪、谁能读、现在有没有人锁着”。教材里说 NAS 设备“使用自己的操作系统和集成的硬件、软件组件”讲的就是这个必然结果。还有一个容易被忽略的差异块级请求基本是定长的4KB 或 8KB文件级请求里元数据操作readdir、stat、rename、lookup占比很高这些操作的数据量极小但对延迟极其敏感。所以 NAS 的性能调优思路和块存储完全不是一回事给 NAS 配大缓存、优化目录索引往往比堆带宽更有效。3.2 NFS 与 CIFS 的语义鸿沟NFS 的早期设计v2/v3追求无状态每个请求自带文件句柄服务器不保存“这个客户端打开了哪个文件”这类会话上下文。好处很实在服务器重启后客户端重发请求就行不需要重建会话坏处是文件锁必须单独用 NLM 协议解决缓存有效性要靠客户端自己按超时判断。CIFS/SMB 是另一条路有状态会话建立、认证、树连接、文件句柄都在服务端维护还带机会锁来减少网络往返。语义更完整贴近本地文件系统的行为代价是断线重连、会话迁移这些事复杂得多。所以教材里“UNIX 通常用 NFSWindows 用 CIFS”这句话背后是语义匹配而不是操作习惯。真正麻烦的是同一台 NAS 同时开两种协议、共享同一个目录UID/GID 和 SID 之间没有天然映射同一个文件在 NFS 客户端看来属于 1000:1000在 SMB 客户端看来属于某个账户两边的权限判断可能不一致。这是跨平台共享里最常见的翻车点上线前一定要把身份映射策略定死。# 服务端导出一个目录给指定网段 # rw/no_root_squash 决定写权限与 root 身份是否被压缩 # sync 保证落盘后再应答async 快但掉电可能丢最近写入 /export/share 10.0.0.0/24(rw,sync,no_subtree_check,root_squash) # 客户端一次挂载里藏着四个关键决策 mount -t nfs -o vers3,rw,hard,timeo600,retrans2,rsize1048576,wsize1048576 \ 10.0.0.10:/export/share /mnt/sharevers3决定了走无状态还是有状态语义hard表示服务端无响应时无限重试业务不会收到错误但可能卡死timeo600的单位是 0.1 秒也就是 60 秒超时rsize/wsize是单次读写的数据块大小设小了协议开销占比高设大了在小文件场景反而浪费。这几个参数怎么配取决于业务能容忍“数据不一致”还是能容忍“卡住”没有统一答案。3.3 专用化砍掉什么换来什么NAS 是单一用途设备这句话不是贬义。硬件上砍掉显卡、多余的 PCIe 槽、通用外设软件上砍掉通用发行版里那一堆用不上的服务把 CPU 时间和内存几乎全留给文件服务和网络栈。换来的是三样东西单设备能接入的客户机数量远高于通用服务器文件 I/O 路径更短没有本地磁盘调度和其他业务抢 CPU配额、快照、共享权限收敛到一个管理界面里。代价同样明确。文件级接口不满足所有场景数据库、虚拟机镜像、需要裸设备语义的应用仍然要块级。于是有了统一存储同一套硬件同时暴露块接口FC/iSCSI和文件接口NFS/CIFS教材里那句“兼容 SAN 和 NAS 两种方式满足业务弹性发展简化业务部署提升存储资源利用率”说的就是它。但统一存储不是免费午餐。同一套控制器要同时处理块和文件两类负载缓存要分区、前端端口要分配、故障域要提前规划。混跑时一个文件业务的元数据风暴把块业务的时延拉高是运维里非常常见的抱怨——不是设备不行是两类负载的资源竞争没在设计阶段算清楚。4. SAN 的分层设计SCSI 命令为什么要被“打包”进另一个网络4.1 三层映射从 SCSI 命令到 FC 帧存储区域网络SAN是服务器和存储资源之间专用的、高性能的网络体系为大量原始数据的传输做过专门优化。教材里有一句很关键的判断FC SAN 可以看成 SCSI 协议在长距离应用上的扩展。这句话把 SAN 的本质说透了——它不是新的存储语义是把原来只能在机箱里跑的 SCSI换了一套传输层送到几公里外。分层看就很清楚。最上面是 SCSI 层产生命令描述块CDB比如 READ(10) 就是一个 10 字节的数组中间是 FC 层把 CDB 塞进 FC 帧的数据区加上 24 字节帧头帧头里有源地址 S_ID、目的地址 D_ID、交换 ID 和序列 ID最下面是 FC-0光模块、光纤、编码。SCSI 是货物FC 是卡车货物本身没变。def read10(lba, blocks, flags0): 构造 SCSI READ(10) 的 CDB共 10 字节iSCSI 会把它原样放进 PDU 头 return bytes([ 0x28, # opcodeREAD(10) flags, # FUA / DPO / RDPROTECT 等标志位 (lba 24) 0xFF, # LBA 高字节大端序 (lba 16) 0xFF, (lba 8) 0xFF, lba 0xFF, 0x00, # group number老设备用通常填 0 (blocks 8) 0xFF, # 传输长度要读多少个逻辑块 blocks 0xFF, 0x00, # control 字节 ]) cdb read10(0x1A2B3C, 8) print(len(cdb), cdb.hex()) # 10 281a2b3c00000008000lba占 4 字节理论寻址空间是 2 的 32 次方个块按 512 字节算就是 2TB这也是为什么大容量场景要用 READ(16) 或者变长 CDB。blocks只占 2 字节单条命令最多 65535 个块超过就要拆成多条命令——这条限制直接影响了主机侧 I/O 调度器怎么切分大请求。flags里的 FUA 位表示“绕过阵列缓存直接落盘”做数据一致性校验时经常用到。FC 世界里还有一个概念绕不开WWN。它是 64 位地址pWWN 标识端口nWWN 标识节点相当于 FC 的 MAC 地址但硬编码在 HBA 或阵列端口上比 MAC 稳定得多。所有的 Zoning、LUN 映射最终都是围绕这串地址在做。4.2 Zoning 与 LUN Masking可见性的两道闸门Zoning 在交换机上做控制“哪些端口能互相看见”。硬 zoning 按端口划软 zoning 按 WWN 划生效之后不在同一个 zone 里的端口连登录都完不成。LUN Masking 在阵列上做控制“这台主机能访问哪些 LUN”阵列根据 HBA 的 pWWN 或 iSCSI 的 IQN 建立映射表主机登录后只能看到属于自己的那些 LUN。为什么两道闸门都得有只做 zoning主机仍然可能扫到并写入不属于自己的 LUN——操作系统扫描总线是很积极的行为扫到就敢往上建文件系统。只做 masking交换机侧的登录风暴、链路状态变化通知仍然会在不该互通的主机之间互相干扰一台配置错误的主机甚至能把整个 fabric 搞乱。两道闸门一个管“能不能通信”一个管“能看见什么”职责不重叠。有个细节特别容易踩LUN ID 是主机视角的编号不是设备的全局编号。同一个物理 LUN在 A 主机上可能是 LUN 3在 B 主机上可能是 LUN 7甚至是 LUN 0。这解释了为什么同一条链路在两台服务器上看到的/dev/sdX名字不同——sd 名字是主机内核按扫描顺序给的跨主机对账必须靠 LUN 序列号或者阵列侧的映射表拿 sd 名字对账早晚出事。4.3 iSCSI同一批命令换个信封IP SAN 是以 TCP/IP 为底层传输协议、用以太网作为承载介质构建的存储区域网络典型协议是 iSCSI它定义了 SCSI 指令集在 IP 网络中的封装方式。封装结构是48 字节的基本头BHS里面有一段 16 字节的 CDB 区、可选的附加头、头校验、数据段、数据校验。能跑在以太网上的原因不复杂SCSI 命令本身与传输介质无关它只要求可靠、有序、有时延上限的传输。TCP 提供可靠有序以太网提供带宽两者一拼就能承载。代价也很清楚软件协议栈吃 CPU可以用卸载卡缓解、以太网的拥塞和丢包会让时延抖动比 FC 大、VLAN/QoS/流控这些网络侧配置得和存储侧对齐否则出了问题两边互相甩锅。# 发起端先发现目标再登录注意 -p 指的是业务口不是管理口 iscsiadm -m discovery -t sendtargets -p 10.0.0.20:3260 iscsiadm -m node -T iqn.2024-01.example:array01 -p 10.0.0.20:3260 -l # 登录成功后内核才会生成块设备多路径必须能认出两条链路是同一个设备 multipath -ll-m discovery只负责列出目标上有哪些 target不做登录-m node -l才是真正建立会话会话建立后内核才会创建块设备。multipath -ll里如果同一个 WWID 下面挂了两个sd设备说明多路径识别正常如果出现两个独立条目先别往上建文件系统那是数据损坏的前奏。维度FC SANIP SANiSCSI承载介质光纤、FC 交换机以太网、普通交换机协议栈开销硬卡卸载主机 CPU 占用低软件栈为主可配卸载卡典型时延低且稳定受网络拥塞影响抖动更大运维技能栈存储与光纤网络存储与以太网适用场景高性能、低时延的核心库中低端业务、远程复制、成本敏感5. 避坑与排查链路上“ping 通但业务不通”的五个现场5.1 坑一能 ping 通存储却扫不到任何 LUN现象很典型主机能 ping 通阵列的管理地址但lsscsi或者fdisk -l里一块新盘都没有看起来像“网络没问题但存储不认我”。原因通常是平面搞混了。管理口是带外管理跑的是 Web 界面和告警LUN 映射走的是业务口FC 或者 iSCSI 的业务网。另外 iSCSI 场景下如果发起端没有登录 target网络再通也不会有块设备因为块设备是会话建立之后才被内核创建的。解决要按固定顺序走别跳步先确认业务口连通性iscsiadm -m discovery能不能列出 target再确认主机发起端的 IQN 或 HBA 的 pWWN 已经被加进阵列的主机组然后确认 LUN 已经映射到这个主机组最后在主机侧rescan-scsi-bus.sh触发扫描。四步任何一步没做前面的都白搭。5.2 坑二多路径的两条链路被识别成两块盘现象multipath -ll里出现两个独立设备/dev/sdb和/dev/sdc内容看起来一样更糟的情况是有人在这两块盘上各建了一个文件系统写进去的数据互相覆盖。原因有两个常见分支。iSCSI 场景下主机用两个不同的 IQN 登录了同一个 target或者两条路径的 target portal group 不一致内核就认为是两个不同设备。FC 场景下通常是 multipath 服务没装、没启动或者multipath.conf里的黑名单把设备过滤掉了。解决一台主机只用一个 IQN确认 target 侧把两个门户放在同一个 portal groupmultipath.conf里按阵列型号配好prio和path_grouping_policy支持 ALUA 的阵列用service-time或alua上线前一定用multipath -ll逐条确认所有路径归到同一个 WWID 下面。这个检查花三十秒能省掉后面几天的事故复盘。5.3 坑三NFS 挂载后客户端彻底卡死现象服务端网络抖动或者重启之后客户端ls卡住CtrlC 退不出来负载一路飙升重启都费劲。原因是hard挂载加上默认超时。hard的语义是“服务端不响应就一直重试”客户端进程会卡在不可中断状态只要服务端不回来它就一直等。解决要按业务性质分。能容忍读不一致的场景可以上soft配合timeo/retrans超时后返回错误不能容忍写丢失的场景保留hard但必须把timeo调大、把监控做在前面让告警先于人发现服务端异常。另一个思路是用自动挂载控制挂载的生命周期按需挂载、空闲卸载把故障影响面压到最小。5.4 坑四阵列扩容了主机侧容量没变现象阵列侧把 LUN 从 2TB 扩到 4TB主机侧df -h还是 2TB反复刷新也没用。原因是容量扩展是分层生效的缺一层就不动阵列 LUN 扩容 → 主机内核重新识别块设备大小要 rescan→ 分区表扩展growpart→ LVM 物理卷扩展pvresize→ 逻辑卷扩展lvextend→ 文件系统扩展xfs_growfs或resize2fs。任何一层漏掉df都不会变。解决就是按层往下查每层都有对应命令和日志。还要记住两个文件系统的差异XFS 只能扩不能缩ext4 可扩可缩但缩之前必须卸载。规划时如果预判未来会缩容文件系统选型就要提前定别等扩容扩完了才发现退不回去。5.5 坑五双控切换业务断了半分钟现象控制器主备切换预期几秒内恢复实际断了 20 到 40 秒上层应用已经报超时。原因是主机侧多路径没识别 ALUA 状态切换发生时仍然往失效路径发 I/O一直等到默认超时30 秒或 60 秒才切到可用路径。这中间的时间完全是被超时参数吃掉的不是阵列切换慢。解决开启 ALUA确认阵列上报的路径状态在multipath -ll里能正确显示为 active 或 ghostpath_checker设成tur或tut让探测更轻更快把fast_io_fail_tmo调到 5 到 10 秒让失败尽快上报给上层而不是干等。这些参数改完必须做一次真实的切换演练纸面推算不算数。6. 从入门级到中端再到分布式与软件定义TCO 这笔账怎么算把教材里几类产品放在一张表里对比取舍就清楚了定位核心能力关键指标口径典型场景入门级简单、经济、易用全冗余双控按需扩展几步完成配置7×24 在线同时支持 FC 与 iSCSI硬盘智能休眠降能耗约 40%16 档风扇调速企业数据中心入门平台、分支节点中端全协议覆盖FC/iSCSI/NFS/CIFS/FTP/FCoE/IB热点分层、缓存加速、精简置备、自愈合前后端带宽高出业界 50%随机 IOPS 基准高出 30%缓存与容量扩展倍数更高30 分钟/TB 重构通用业务平台、虚拟化与数据库混跑分布式标准 x86 服务器本地 HDD/SSD 组成大规模资源池数据分散到多节点横向扩展能力、副本或纠删码带来的可用性海量非结构化数据、对象与文件场景软件定义通用 x86 介质经分布式技术池化对外提供标准 SCSI/iSCSI 接口硬件解耦、按需弹性、与虚拟化平台集成非虚拟化上层应用与虚拟机的统一供给入门级那段里最容易被低估的是能耗手段硬盘按负载智能休眠、16 档风扇调速、按业务压力调 CPU 频率这几项叠起来能把电费和散热成本压下去一大截而 TCO 里电费占比往往比采购价更持久。中端那段里最容易被高估的是峰值性能数字前后端带宽和 IOPS 基准只说明上限真正决定体验的是热点分层准不准、精简置备的空间回收及不及时、重构时业务掉不掉速。我个人判断一台中端存储值不值不看它把多少高端功能下放而看它把哪些能力做成了默认开启、不需要在项目里额外规划。热点分层如果要在实施阶段人工设计迁移策略精简置备如果要靠脚本定期回收自愈合如果要在故障后才手动触发那这些功能的价值就打了一半折扣。分布式和软件定义也一样把一堆 x86 服务器堆成资源池只是第一步真正的成本在运维节点扩容时的数据重平衡、坏盘后的重构窗口、版本升级时的滚动策略这些才是三年后账单上的大头。那年做一次容量规划我按阵列标称容量算的比例忘了给快照和精简置备的元数据留余量上线三个月就触发了水位告警临时扩容的采购流程走了六周。从那以后我每次做容量方案都强制把“有效容量、快照预留、精简置备超配比、重构预留”四项分开列任何一项不写清楚就不签字。教材里的架构图能帮你理解机制但真正让你少踩坑的是这些把数字落到纸面上的习惯。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
