简介这份华为HCNA-Storage培训教材V4.0面向准备考取华为存储认证的工程师、数据中心运维人员及存储技术初学者系统讲解企业级存储的基础概念与主流架构。内容由存储技术概述切入区分狭义与广义存储定义梳理硬件架构、软件组件与存储解决方案三大部分并重点对比DAS含内部与外部两类、NAS、SAN三种架构的连接方式、协议差异与适用场景同时延伸至IP SAN、分布式存储、软件定义存储以及低端与中端存储产品的特性帮助读者建立选型与规划思路。压缩包内为1个PDF文档约39.06MB排版完整、图文配套适合作为通读教材或查阅手册。该资料已有1241人学习下载可用于认证备考、日常方案设计与技术扫盲为后续实验与实战打下概念基础。1. 从一块硬盘到一套存储系统为什么存储从来不是一个盒子刚翻开 HCNA-Storage 这类入门存储认证教材的人很容易把存储当成一个盒子买了、插上、划几个 LUN 就完事。教材开篇先把定义分成两半——狭义的存储指具体介质软盘、CD、DVD、硬盘、磁带广义的存储指数据中心里那套由存储硬件系统、软件系统、存储网络和解决方案叠起来的整体。这个分法不是咬文嚼字它决定了你后面读 DAS、NAS、SAN、分布式、软件定义存储时的站位你是在挑一台设备还是在设计一条数据从主机到介质的完整路径。HCIA 存储方向的题库里DAS/NAS/SAN 的区别几乎必考但考的是结论考不出动机。真正值得搞懂的是这些名词底下那层共用结构同一条 SCSI 指令可以被塞进并行总线、FC 帧、TCP 报文里传输介质换了三轮上层语义一个字没改。理解了这层一份两百页的培训教材在你眼里就不再是五六个并列的产品类别而是一套被反复复用的抽象在换外壳。2. 块与文件访问语义才是架构分叉的真正起点教材把 DAS 定义成为服务器提供块级的存储服务不是文件系统级把 NAS 定义成文件级的数据访问和共享。这两句话是全篇的分水岭。块和文件不是两种设备形态而是两种分工谁负责解释这些字节。把这一点想透后面所有架构差异都是它的推论。2.1 块级访问把一维地址空间原样交出去块设备对外只暴露一件事从 0 开始编号、长度为 N 个逻辑块的一维地址空间。主机发一条 READ(10)写明起始 LBA 和要读多少个块设备把对应字节搬回内存全程不问这块数据属于哪个文件、哪个目录、有没有人正在写它。文件系统、inode、目录树、权限位全部住在主机侧。这解释了 DAS 那句块级服务不是文件系统级的含义设备只当搬运工元数据的一致性由主机的文件系统保证。也解释了另一件常被忽略的事——为什么同一块裸盘能被格式化成 ext4 也能被格式化成 XFS甚至能被两个文件系统抢着挂载因为设备本身没有这块归谁的概念。def build_read10(lba: int, blocks: int) - bytes: # READ(10) 的 CDB 固定 10 字节多字节字段一律大端序 cdb bytearray(10) cdb[0] 0x28 # 操作码10 字节 CDB 版本的读命令 cdb[1] 0x00 # 控制位DPO/FUA 全关允许走设备缓存 cdb[2:6] lba.to_bytes(4, big) # 起始逻辑块地址4 字节上限 2^32 块 cdb[6] 0x00 # group number多数实现填 0保留位 cdb[7:9] blocks.to_bytes(2, big) # 传输长度单位是块不是字节 cdb[9] 0x00 # control 字节NACA 与链接位 return bytes(cdb)这段代码里有两个字段值得盯住。第一LBA 只有 4 字节512 字节块下寻址上限是 2TB超过就得换 READ(16) 把 LBA 扩到 8 字节。第二传输长度是 2 字节、单位是块一次最多 65535 块512 字节块下约 32MB所以再大的 I/O 到了设备侧也是被切成多条命令排队下发的。块级存储的性能特征、队列深度怎么算、为什么大块顺序写比随机写划算得多根子都在这 10 个字节里。2.2 文件级访问NAS 为什么必须自带一套操作系统NAS 做的事正好反过来把路径到数据的解析过程搬进设备内部。客户端发来的不是 LBA而是\\share\report.xlsx偏移 4096 到 8192 字节这一段。设备要自己解析路径、查目录项、校验权限、维护打开文件的句柄、处理并发写的锁和缓存一致性。这些活需要一个完整的文件系统实现、一个完整的协议栈也就需要一个自己的操作系统。教材里那句NAS 设备使用自己的操作系统和集成的硬件、软件组件读起来平淡实际是 NAS 和一台装了文件共享服务的通用服务器的本质差别。通用服务器的 CPU 要分给业务进程、要跑一堆无关服务文件 I/O 只是它众多任务里的一个NAS 把资源压在一件事上砍掉通用操作系统的调度噪声网络栈和文件系统走的是精简过的路径所以教材说它执行文件 I/O 比一般用途的服务器更好也所以它能接入更多客户机、反过来整合掉一堆分散的文件服务器。2.3 SCSI 指令集三条架构共用的一套语义这里有个反直觉的地方NAS 看起来和 SCSI 毫无关系可它内部管盘、做 RAID、访问后端磁盘用的还是 SCSI 指令集外部 DAS 在多数情况下经由 FC 或 SCSI 协议通信FC SAN 的典型协议组是 SCSI Fiber ChannelIP SAN 的典型协议是 iSCSI教材的原话是定义了 SCSI 指令集在 IP 网络中传输的封装方式。四条路一套语言。常见的实现思路是把这件事拆成三层最上面是命令集READ/WRITE/INQUIRY/REPORT LUNS 这些 CDB中间是架构模型把两端抽象成 initiator 和 target最下面是承载FCP、iSCSI、SAS、SRP 各自负责把 CDB 和数据装进自己的帧或 PDU。换传输层不换语义代价是每层都得自带可靠性机制——FC 用 buffer-to-buffer credit 做流控iSCSI 用 command sequence number 做窗口和乱序重组。理解了 initiator/target 这个抽象很多配置项就不用死记了target 侧的LUN 映射是把内部卷编号翻译成对外呈现的 LUN IDinitiator 侧的启动器名是给 target 认人用的身份标识多路径是同一个 target LUN 走了多条链路时在 initiator 侧做的聚合。这些概念在 FC 和 iSCSI 上完全同构换协议不用重新学一遍。3. DAS、NAS、SAN同一份 SCSI 语义的三条传输路径教材把三种架构并排讲很容易读成三个并列的产品类别。换个角度看它们回答的是同一个问题的三个版本主机和介质之间那段路用什么协议走、能走多远、能挂几个。3.1 内部 DAS 与外部 DAS距离和设备数这两个硬约束的来处内部 DAS 的存储设备挂在服务器机箱内部的并行或串行总线上教材点了三条限制物理总线有距离限制只能支持短距离高速传输能连接的设备数目有限设备放在机箱内占空间还影响其他部件的维护。这三条不是产品取舍是电气特性。并行总线靠多根线同时传一个字的多个 bit频率一高线间 skew 和串扰就把眼图糊掉所以并行 ATA 到了 133MB/s 就顶住了串行总线把时钟嵌进数据流速率能上去但背板走线和连接器密度仍然限制着机箱内能塞多少盘。设备数限制则来自总线仲裁和地址位宽一条总线能挂几个 target id 是定死的。外部 DAS 把这些约束松开了一半存储设备移到机箱外经由 FC 或 SCSI 协议直连。距离拉长了设备数上去了还能把存储集中到一处管理。但拓扑没变主机到设备仍是一条专线一台服务器占了第二台接不进来——除非中间加一台交换机做交换那一步跨出去就走到 SAN 的地界了。DAS 和 SAN 的分界不在协议在有没有一张可以共享的交换网络。3.2 NAS 的协议栈CIFS 和 NFS 各自管什么NAS 的定位教材写得很明确连接到一个局域网的基于 IP 的文件共享设备经由文件级的数据访问和共享提供存储资源。它跑在 IP 上用 TCP/IP 传输用 CIFS、NFS 提供远程文件服务。NFS 和 CIFS 的差别不只是 Windows 与 UNIX。NFSv3 是无状态设计每个请求自带完整凭证和文件句柄服务端不保存会话客户端崩溃重启后重发即可服务端不需要恢复什么。CIFS/SMB 从设计之初就是有状态的先协商版本再建会话再连树再打开文件拿句柄每一步都在服务端留下状态。有状态换来更强的语义——字节范围锁、机会锁、目录变更通知这些在无状态模型里做起来很别扭。代价也很直接状态越重断线重连和故障切换越麻烦延迟对语义的影响越大。这就是为什么 NAS 上跑数据库、跑虚拟机镜像盘总觉得别扭——锁、缓存一致性、元数据操作的开销都压在协议层而块设备把这些责任一股脑交给了主机的文件系统或数据库自己。教材说 NAS 适合文件共享和服务器整合适合什么其实不重要从协议语义就能推出它不适合什么。3.3 FC SAN 和 IP SANiSCSI 封装的到底是什么教材给 FC SAN 的定义是用在服务器和存储资源之间的、专用的、高性能的网络体系为了实现大量原始数据的传输而做了专门优化紧接着补了一句很精辟的话可以把 FC SAN 看成 SCSI 协议在长距离应用上的扩展典型协议组是 SCSI Fiber Channel。FC 适合这件事有两个原因教材也点了一方面能传大块数据另一方面能远距离传输。背后的机制是 FC 自己的帧结构和信用式流控——发送端要先拿到接收端给的 credit 才能发帧链路不会因为突发流量丢帧也就不需要 TCP 那套丢了再退避重传的拥塞控制。代价是 FC 是一张独立的网交换机、HBA、线缆、运维体系都是另一套所以它的市场集中在高端企业级性能、冗余度和数据可获得性要求都高的场景。IP SAN 走另一条路TCP/IP 做底层传输以太网做承载典型协议是 iSCSI。封装这件事要说准——iSCSI 把 CDB 放进 PDU 的头部段把数据放进数据段加上序号和摘要字段剩下的可靠有序传输交给 TCP。被封装的是命令与数据不被封装的是块语义本身主机侧看到的还是一块裸盘照样要自己格式化、自己做文件系统。# 1. 发现阶段只向门户询问你有哪些 target此时不建立会话 iscsiadm -m discovery -t sendtargets -p 10.0.0.10:3260 # 2. 登录阶段与指定 target 完成登录协商内核 SCSI 中间层随后枚举 LUN iscsiadm -m node -T iqn.2024-01.example:array0 -p 10.0.0.10:3260 --login # 3. 确认阶段打印会话详情核对 target 名与已挂接的 scsi disk iscsiadm -m session -P 3 | grep -E Target|Attached scsi disk这三条命令对应 iSCSI 的三个阶段参数含义也不难-m discovery切到发现模式-t sendtargets指定发现方式-p是门户地址-m node操作用节点记录--login才真正建立会话-P 3打印会话的详细信息。机制上说登录协商完成后内核的 SCSI 中间层会为目标上的每个 LUN 生成一个 sd 设备节点主机这才看见盘。如果第三条命令里只看到 Target 却没有 Attached scsi disk问题基本就落在 LUN 映射和启动器白名单上跟网络连通性无关——这是排查时最先要切开的两段。维度内部 DAS外部 DASNASFC SANIP SAN访问粒度块块文件块块承载协议并行/串行总线FC 或 SCSITCP/IP CIFS/NFSSCSI over FCSCSI over TCP典型距离机箱内数十米内直连局域网数据中心级局域网到园区共享能力独占独占多客户端共享多主机经交换网络共享多主机经以太网共享典型场景单机系统盘小规模外挂文件共享、服务器整合高要求企业级核心业务中低端块存储接入4. 存储软件栈镜像、重构、分层都发生在哪一层教材在讲低端和中端产品时把大量篇幅给了功能名字全冗余双控、RAID 2.0、SmartTier、SmartCache、SmartThin、自愈合。名字是产品层的话术机制是另一回事。这一章把它们拆回三个问题控制器在什么位置、对什么数据、做了什么动作。4.1 双控冗余冗余的到底是什么全冗余的双控系统架构这句话里被冗余的对象不是硬盘而是写请求的确认和控制路径。两个控制器各有 CPU、缓存、电源、到盘的通路正常时各管一部分 LUN故障时对端接管。关键在于写缓存怎么保证不丢。常见的实现思路是写请求先进入控制器 A 的缓存A 立刻把它镜像到 B 的缓存两边都落地之后才向主机回写完成。这样 A 掉电B 手里还有一份完整数据接管后可以继续刷盘反过来只写本地缓存就回确认掉电瞬间主机以为写成功、数据实际还在内存里这种丢数据往往事后完全查不出来属于典型的玄学事故。多控环境下还要处理路径归属。LUN 有归属控制器主机如果从非归属控制器的路径发请求请求要经由内部互联转发到归属端延迟会高出一截。于是有了 ALUA 这类非对称访问语义target 主动告诉 initiator 哪些路径是优化的、哪些是非优化的多路径软件据此设置优先级。切换演练之后性能腰斩多半就是这一步没配对。4.2 RAID 2.0把重建粒度从盘改成块传统 RAID 的重建痛点很直白一块盘坏了重建要读整个条带组的每一块盘把校验算出来写到热备盘上。盘越大、盘组越宽重建窗口越长窗口里所有盘都在满负荷读形成热点盘重建期间再坏一块整组数据就没了。这是扩容越快、风险越大这个悖论的来处。RAID 2.0 换了个思路先把每块物理盘切成固定大小的 chunk把来自不同盘的 chunk 组成 chunk group在 chunk group 上做 RAID 切出 extent再由 extent 组成 LUN。教材的说法是通过全虚拟化机制实现数据灵活调度30 分/TB 数据重构0 热点硬盘坏道自修复。# 极简化的 RAID 2.0 地址映射LUN LBA - (物理盘, 盘内偏移) CHUNK_SIZE 256 * 1024 # 每块盘切出的 chunk 大小单位字节 EXTENT_CHUNKS 4 # 一个 extent 由几个 chunk 组成决定条带宽度 def lba_to_disk(lun_lba: int, ckg: list[list[int]]) - tuple[int, int]: # 先定位 LUN 地址落在第几个 extent、extent 内偏移多少 extent_id, offset divmod(lun_lba, CHUNK_SIZE * EXTENT_CHUNKS) # 再在 extent 内定位第几个 chunk、chunk 内偏移多少 chunk_idx, in_chunk divmod(offset, CHUNK_SIZE) # ckg 是映射表[extent 编号][条带内位置] - 物理盘号 disk ckg[extent_id][chunk_idx] return disk, in_chunk映射表是这套机制的核心。LUN 的地址空间被切成 extent每个 extent 落在哪些盘的哪些 chunk 上由这张表决定逻辑地址和物理位置彻底解耦。直接后果有三个重建只处理有数据的 extent空 extent 完全不用管所以每 TB 的重构时间被压到分钟级重建的读压力被摊到整个 chunk group不再集中轰一个盘组扩容时新盘的 chunk 直接进池参与分配不必重算全量校验。坏道自修复是同一套机制的自然延伸某个 chunk 读到坏道控制器从同组其他 chunk 算出这块数据写到健康位置并更新映射表整个过程对上层 LUN 完全透明。传统 RAID 遇到坏道只能交给上层文件系统去报错差别就在这里。4.3 分层、缓存与精简热点统计和写时分配教材把中端存储的精细化能力归成几个名字SmartTier/SmartCache/SmartMotion 做热点统计与自动迁移SmartThin 做写时分配与空间回收。名字不同底下是同一类问题——数据的访问频次不均匀空间的占用也不均匀而固定分配把两者都当成了均匀。分层存储的前提是能统计。控制器按固定周期采样各 LUN 各段的 IO 次数和块大小算出热度超过阈值就把这一段迁到 SSD 层冷下来再迁回 HDD 层。最容易翻车的地方是迁移本身消耗的带宽迁移是后台任务和业务 IO 抢同一批盘所以真实实现都会给迁移限速并在业务高峰推迟迁移。教材说性能提升三倍是在稳态下测出来的迁移动作本身的开销不会写进这句话里。精简配置的前提是写时分配。创建 LUN 时只登记逻辑容量不落物理空间主机第一次写到某个块控制器才分配物理块并更新映射表。麻烦的地方在回收主机删掉文件文件系统知道这些块空了存储并不知道映射表里还老老实实挂着。要有 UNMAP/TRIM 这类语义把这些块我不要了传下去池子才可能真正瘦回来。注意精简池的容量告警和实际数据量是两回事。池子里除了有效数据还压着快照占用的空间、未回收的孤儿块、以及写时分配的元数据开销按逻辑容量估算使用率一定会算错。5. 避坑与排查从现象倒推是哪一层出的问题教材给的是正确状态下的模型真实环境里更多是不对劲。下面几条是存储交付和运维里出现频率最高的每条按现象、原因、解决三段写重点不在结论在怎么从现象定位到层。5.1 现象LUN 划好了、掩码也配了主机就是看不到盘现象主机侧fdisk -l看不到新盘iscsiadm -m session -P 3能列出 target 名但没有 attached scsi disk存储侧显示 LUN 在线且健康。原因这类问题九成出在认人环节。一是启动器名对不上主机换了 HBA 或重装系统后 IQN 变了存储侧白名单里还是旧的那个二是 LUN ID 冲突同一个 target 下两个 LUN 用了相同编号主机枚举时后一个被覆盖三是多路径软件还没重扫内核 SCSI 层没收到 rescan 通知。解决先在主机侧确认实际 IQN再去存储侧核对白名单别凭记忆然后在主机上触发 SCSI 总线重扫让内核重新走一遍 REPORT LUNS最后才怀疑映射。这里有一条血泪经验——排障顺序要从身份往下走先证身份对、再证枚举到、最后才查路径和性能反着查会把时间全花在网络上。5.2 现象NAS 共享目录 Windows 能读不能写UNIX 侧一切正常现象同一个共享目录UNIX 客户端用 NFS 挂载后读写正常Windows 客户端用 CIFS 挂载后能打开、能读新建文件和保存全部失败权限报错。原因两套权限模型在同一份目录上打架。NFS 侧认的是 UID/GIDCIFS 侧认的是 ACL中间要做身份映射映射表里没有对应用户时写操作被降级成匿名访问而目录权限只给了属主可写于是表现为能读不能写。有些实现里 root squash 也会参与进来让 root 写同样被拒。解决先把两侧的身份映射表对齐确认 Windows 账号被映射到正确的 UID再核对目录的属主和权限位注意 NFS 的 umask 和 CIFS 的继承 ACL 谁覆盖谁最后确认共享本身没有被设成只读。这类问题适合在交付前用两个客户端各写各读一遍别等业务上线才发现。5.3 现象双控切换演练之后业务性能掉了一半现象切换前业务平稳手动切换控制器再切回来之后告警清零、LUN 全部在线、链路状态正常但业务侧响应时间翻倍存储侧看 IOPS 掉了不少。原因LUN 的归属控制器在切换过程中漂走了回来时没有自动漂回主机侧的路径一直走非归属控制器的优化路径每次 IO 都要经内部互联转发。多路径软件如果没有正确识别 ALUA 的优先级也会一直挑非优先路径发请求。解决先看路径状态确认每条路径标的是优化还是非优化再核对 LUN 当前归属和主机实际使用路径是否一致最后调整多路径的优先级策略把优化路径设为优先。切换演练一定要带性能验证只验连通性等于没验。5.4 现象精简配置的池子没写多少数据就快满了现象池子标称 100TB业务实际写入不到 40TB使用率已经飘红扩容申请单都批下来了。原因精简池里占用空间的除了有效数据还有快照占用的写时复制块、删文件后没有回收的孤儿块、以及元数据开销。文件系统删数据只是改了自己的位图存储侧的映射表并不会自动释放UNMAP 没开或者间隔太长空间就一直挂着。解决先区分数据占用和快照占用把快照单独统计再确认文件系统侧的 UNMAP 是否开启、存储侧是否接收最后核对池子的超额订阅比有没有设得过高。精简配置不是免费的超额订阅比一旦超过可回收能力池子早晚会被看不见的占用填满。5.5 现象扩容之后的重构时间比估算的长很多现象加了一批盘做扩容按重构速率估算三小时能完成实际跑了十几个小时同期业务延迟明显抖动。原因重构是后台任务和业务 IO 抢同一批盘控制器通常会做限速把重构带宽压到某个比例以下避免影响业务限速加上业务高峰叠加实际速率远低于理论值。chunk 大小和 extent 分布也会影响碎片化的映射表让重构时的读放大更严重。解决先看重构速率曲线和业务 IO 曲线是否反向相关确认是限速在起作用再评估是否需要在业务低峰期手工提速长期看要调 chunk 大小和 extent 分布策略减少碎片。扩容计划里必须把重构窗口当成业务风险窗口来排而不是当成后台静默完成的事。6. 分布式与软件定义把存储池从机柜里搬出来之后的取舍教材对分布式存储的描述只有两句话却点到了要害将标准 x86 服务器的本地 HDD、SSD 组织成大规模存储资源池把数据分散存储到多个数据存储服务器上目前多借鉴分布式文件系统的思路先在众多服务器上搭一个分布式文件系统再在其上实现存储业务。软件定义存储则是把这套池子对非虚拟化环境和虚拟机统一暴露成标准的 SCSI 和 iSCSI 接口。6.1 接口不变控制面外移这里的设计取舍值得琢磨。分布式存储把数据面打散到几十上百台 x86 服务器上控制面元数据、映射、故障检测、重建调度单独抽出来集中判断、分散执行。它没有发明新接口对外仍然是 SCSI 和 iSCSI——主机侧不需要为新架构改任何一行代码这是标准接口省下的大量适配成本。代价同样明显。集中式阵列的控制器是专门为存储设计的缓存、队列、流控都在一块板子上延迟的确定性很好分布式存储每一次 IO 都要经过网络、要跨节点确认副本尾延迟的抖动天然更大。教材里中端存储强调前端带宽超出业界 50%SPC-1 性能超出业界 30%讲的是确定性分布式讲弹性扩展按需增长讲的是上限。这两件事很难同时拿满。6.2 中端存储的全协议覆盖说明了什么教材说中端产品FC/ISCSI/NFS/CIFS/FTP/FCoE/IB 全协议灵活覆盖并且兼容 VAAI/VASA/SRM/SMI-S 这类标准。这其实是厂商对上面那个取舍给出的中间答案不赌某一种架构会赢而是把所有协议栈都做进同一个控制器的软件里让用户按业务挑路径。代价是协议栈的复杂度和测试矩阵成倍膨胀——一套代码要同时伺候块和文件还要保证在每种协议下的性能都不塌这是工程上的硬活。我自己的习惯是看到这类全协议覆盖的产品不先看它支持多少种协议而先看它每种协议下的性能曲线是不是一个量级。支持列表是销售语言性能曲线才是工程语言。6.3 我的验证习惯从那以后我每次评估一套存储方案都强制走一遍同一个顺序先确定这份数据是块语义还是文件语义再确定访问它的主机有几种、会不会增长然后才去看具体产品支不支持。这个顺序反过来——先看产品功能列表再找场景——踩过的坑太多了最后总会买回一堆用不上的协议许可。希望帮到你。本文还有配套的精品资源点击获取