存储基础在云计算里的分量，很多初学者是低估的。我当年备考HCIA云计算的时候，一开始把精力全放在虚拟化、网络、容器这些看起来"更高级"的内容上，结果一到存储相关的题目就卡壳。后来把存储基础这块彻底捋清楚之后，才发现整个云计算的知识体系都顺了不少。这篇笔记就是我当时学习的思路整理，把存储架构、硬盘接口、RAID级别、存储虚拟化、性能规划和数据保护这几个点串起来讲，适合正在备考HCIA云计算、或者刚入行做云平台运维的同学参考。里面的内容不光是应付考试，很多在真实项目里选型和排障时也用得上。
1. 存储架构：DAS、SAN、NAS的边界与云计算中的落位
存储这块最容易让人犯迷糊的，就是一上来就背一堆英文缩写，却不知道这些架构到底解决什么问题。考试和面试都喜欢问"DAS、SAN、NAS区别"，但死记硬背区别没意义，你得理解它们出现的逻辑顺序。
1.1 三种架构的本质差异
DAS（直连存储）是最原始也最朴素的形态——硬盘通过接口直接挂在服务器上，比如笔记本里的那块硬盘就是典型的DAS。DAS没有网络的概念，存储只有本地能访问，扩展就加盘，容量就到头了。
SAN（存储区域网络）解决的是"共享"和"扩展"的问题。它把存储设备从服务器里抽出来，通过专用网络（常见的是光纤通道FC，也有IP SAN走iSCSI协议）连接。服务器看到SAN里的存储，依然是以块设备的形式出现，就像本地硬盘一样，甚至能直接在上面装操作系统。SAN有个特点：基于块级协议，操作系统可以把它格式化成自己想要的任何文件系统。
NAS（网络附加存储）则是共享文件的神器。它本身就是一个"小电脑"，自带文件系统，通过网络对外提供文件访问服务（NFS、CIFS/SMB这些协议）。客户端访问NAS时，看到的是一个共享目录，不需要自己格式化，也不用关心底层的块设备长什么样。
这里需要记住一个关键区分：SAN给你的是"一块硬盘"，NAS给你的是"一个文件夹"。SAN关注的是块，NAS关注的是文件。
1.2 云计算场景里怎么选
在云平台（尤其是私有云）里，这三种架构经常同时存在。虚拟机磁盘一般跑在SAN或者分布式块存储上，因为虚机需要块级的读写性能，而且块存储比较通用，虚拟化层可以在上面建立自己的文件系统。而NAS更适合挂载共享目录，比如多个虚拟机要共同访问一份配置文件、做文件共享、存静态资源，选NAS比选SAN省事得多。
DAS在云计算里虽然看起来最"不高级"，但很多超融合方案、分布式存储节点的数据盘，物理上其实就是DAS——每台服务器把自己本地的SATA/SAS/NVMe盘贡献出来，再利用软件层做成一个统一的分布式存储池。这套思路把DAS的廉价和本机高性能发挥出来了，同时通过网络复制弥补单机可靠性不足的问题。
提示：理解三种架构时，别只看传输协议，核心是看"存储怎么暴露给上层"。SAN暴露块设备，NAS暴露文件共享，DAS则什么都不暴露，只有本机可见。考试里所有和"块""文件"相关的题目，都是围绕这个核心在绕。
2. 硬盘、接口与协议：性能数字背后的物理基础
架构决定了存储怎么连，但最终的性能下限由硬盘本身决定。这块内容在HCIA云计算里出现的频率不算特别高，但它是理解IOPS、吞吐量、延迟这些存储核心指标的基石，不补上后面很多内容都似懂非懂。
2.1 机械盘、SATA与SAS的取舍
机械硬盘（HDD）转一圈才能读一次数据，所以它的IOPS基本和转速挂钩。15K转的盘，IOPS大概在150-200左右；10K转的盘，IOPS大概在100-150；7.2K转的盘就更低了。它强的是顺序吞吐，单盘顺序读写能跑到150-250MB/s，但随机读写能力惨不忍睹。
SATA和SAS是两种常见的企业级硬盘接口。SATA便宜、容量大，适合做冷数据存储；SAS通道数多、协议支持全双工、抗并发能力强，适合对可靠性和IOPS要求更高的场景。很多服务器里的系统盘、数据库盘，宁可多花点钱上SAS，也不拿SATA去赌性能。
2.2 NVMe固态盘带来的性能跃升
固态盘（SSD）因为内部没有机械运动，随机IO能力比HDD提升了整整一个数量级。普通的SATA SSD，随机读的IOPS能做到2-5万；而走PCIe通道的NVMe SSD，IOPS轻松到十几万甚至更高，延迟也从机械盘的十几毫秒降到了几十微秒级别。
在云平台里，NVMe盘通常被用作高性能计算节点、数据库实例的本地盘，或者作为分布式存储的缓存层。很多存储一体机的"热数据层"，实际就是用NVMe加速盘来承载高并发读写的。
2.3 企业盘与消费盘的本质差别
这个点考试不爱考，但做项目时特别容易踩坑。消费级硬盘的定位是"家用零散负载"，可靠性设计上没有那么严格；而企业级硬盘支持7x24小时持续运行，固件里带更多的掉电保护、错误校验、磨损均衡策略。
更关键的是，消费盘在企业环境频繁掉盘后，你根本没法判断它是偶发故障还是批量隐患。云平台里一旦出现磁盘离线，所有关联的数据副本都要重新校验，非常消耗整体资源。
提示：判断一个存储系统的性能上限，第一眼就看它用的什么盘。全是机械盘，再怎么优化也到了了高端数据库的随机IO要求；一旦换上了NVMe，瓶颈往往就转移到网络和CPU那边了。
3. RAID级别选型：从计算写惩罚到真实场景的取舍
RAID（冗余磁盘阵列）是存储这块必考、也必用的知识点。理解RAID不能停留在"RAID1是镜像，RAID5是校验"这个层面，你得会算它的开销，会结合应用场景做取舍，否则在实际项目里很容易选错。
3.1 写惩罚：为什么RAID级别直接影响性能
写惩罚是计算存储性能时躲不开的概念。它的含义是：应用每次写入一个数据块，存储系统为了维持冗余，需要在底层做额外多次物理写入。不同的RAID级别写惩罚不同，直接决定了一个RAID组对上层IOPS的实际承载能力。
常见写惩罚系数：
- RAID0：写惩罚为1，没有冗余，写性能最好
- RAID1/RAID10：写惩罚为2，一份数据写两次
- RAID5：写惩罚为4，每次写数据要读旧数据、读校验、写新数据、写校验
- RAID6：写惩罚为6，比RAID5还要多一次校验操作
这个系数的意义在于算"RAID组实际IOPS"时要用到。比如一个RAID10组里有8块15K机械盘，单盘IOPS按150算，不考虑其他损耗时，组理论IOPS大约为8盘150/写惩罚2=600。如果是8块盘组RAID5，同样是150单盘IOPS，写场景下大约只有8150/4=300。四舍五入，打对折都不止。
3.2 RAID5、RAID6、RAID10的适用边界
RAID5利用空间好，读性能也不错，对写入不密集、但需要冗余的普通业务很合适。但它有个短板，单盘故障后进入降级重建状态，重建时间较长，且重建期间如果第二块盘再出问题，整个组数据就全没了。
RAID6在这点上安全得多，能容忍两块盘同时故障，代价是写性能和可用容量都会明显下降，适合大容量近线存储、备份数据池这类对安全要求高、但对写入性能没那么敏感的业务。
RAID10则是性能和安全性平衡比较好的方案，写惩罚低、重建相对快（只需重建镜像盘），所以数据库、高并发业务、虚机系统盘这类对延迟和IOPS都要求高的场景，优先考虑RAID10。缺点就是可用容量只有总容量的一半，成本高。
3.3 一个被忽视的小技巧：把镜像和应用放在不同存储组
RAID级别选完之后，还有一个常见坑：很多团队把全部虚机磁盘一股脑塞进同一个RAID5存储池，然后到IO出问题时才怪存储不行。实际上，存储规划应该是"分类存放"，系统盘和数据库数据盘分开，冷数据用RAID6的大容量组，热数据用RAID10的高性能组。
这么做不光是性能隔离，还是故障域隔离。存储组的故障和热点是会被其他业务感知到的，把关键业务摊在独立的存储结构上，相当于是数据层面的"物理隔离"。
注意：RAID2、RAID3、RAID4这些老级别在HCIA云计算大纲里基本不需要深究，重点掌握RAID0、RAID1、RAID5、RAID6、RAID10就足够了。但RAID5和RAID6的写惩罚计算要会，这是笔试里常考的数值类题目。
4. 虚拟化存储：从物理磁盘到存储资源池
前面讲的都是物理层面的存储基础，而云计算存储最大的不同在于，它把物理存储抽象成了逻辑资源，让你没办法直接看到盘，只能看到存储设备提供的"容量"。这一层抽象，就是存储虚拟化，也是HCIA云计算里核心中的核心。
4.1 存储池、存储卷、存储控制器的关系
先理清三个词：
- 存储池：一堆物理磁盘（或者RAID组）通过软件层聚合出来的容量池，可以切成很多份给上层用
- 存储卷：从存储池里划分出来的一段逻辑空间，对上层来说，它就是一个可格式化的"盘"
- 存储控制器：存储设备的大脑，负责处理IO请求、缓存、快照、复制等高级功能
在华为云的体系里，FusionStorage这种分布式块存储就属于"软件把服务器本地盘聚合成分散存储池"的代表性方案。而在传统存储阵列里，存储池通常由若干RAID组组成，再在上面划LUN（逻辑单元号）给主机用。
考试里常见的问法是"存储池和LUN是什么关系"，你只要记住"存储池是源，LUN是从池子里划分出来的"就够了，但实际规划时还要考虑池子的大小、剩余容量、条带化粒度这些细节。
4.2 精简配置与厚配置：一个容易出错的容量概念
这是云计算存储虚拟化里非常有区分度的考点。
厚配置（Thick Provisioning）的意思是创建卷的时候，就按设定的大小从存储池里一次性划出全部空间。这样性能稳定、空间有保证，但缺点是浪费——明明虚机只用了20GB，却占用了100GB的存储池容量。
精简配置（Thin Provisioning）刚好相反，创建卷时逻辑上显示100GB，但实际上只按照实际写入量来占用存储池空间。它的好处是容量利用率高，适合大量低写入虚机的场景；坏处是如果所有人都在过度分配，存储池容量可能悄悄被写满，最终导致某些卷无法写入，出现IO阻塞。
注意：做云计算存储规划时，精简配置率不要拍脑袋定。合理做法是根据业务实际增长速度和平均用量来估算，并且要配套容量告警机制，在存储池使用率达到比如70%、80%、90%的时候分级预警，不然出了问题就是整个集群级别的故障。
4.3 虚拟磁盘在虚拟化层怎么落地
虚机的系统盘、数据盘，在物理存储上通常不是一个完整的LUN，而是一个存放在存储设备上的虚拟磁盘文件。这个文件会被格式化出虚机自己的文件系统，虚机内看到的就是一块标准硬盘。
这种设计带来两个好处：一是整个虚机磁盘可以作为一个普通文件来管理，备份、迁移、克隆都非常方便；二是可以通过给这个虚拟磁盘打快照，做一致性备份。
考试里经常出现"裸设备映射""虚拟磁盘文件"这些概念，理解关键点就够了：虚拟磁盘文件适合管理、复制、迁移，但多了一层文件系统封装，性能上会有轻微损耗；裸设备映射把LUN直接交给虚机，绕过了文件系统封装，适合对性能有极致要求的场景，但灵活性和可管理性会差一些。
5. 性能观测与容量规划：用基准数字做存储设计
懂了一些存储术语之后，还得知道怎么把概念落到实际。做云计算架构设计时，用户总问"我这套环境要多大存储、什么性能"，如果你只能给经验值，那很容易被挑战。这块内容就是把物理知识和规划方法串起来。
5.1 IOPS、吞吐量、延迟：三个指标先别混
存储性能最常用的三个指标：
- IOPS：每秒读写的IO次数，关注的是随机吞吐能力
- 吞吐量：单位时间内能传输的数据量，比如MB/s，关注的是顺序读写能力
- 延迟：一次IO从发起到返回的时间，关注的是快不快
实际业务里，数据库类应用主要看IOPS和延迟，视频渲染、大数据这类顺序读写多的应用主要看吞吐量。有的存储系统标称"IOPS百万"，但如果业务全是顺序大块读，那IOPS高并不能直接体现优势，重点要看MB/s。
5.2 一个简单但很有效的规划估算
假设一个业务池里有100台虚机，每台平均需要1000 IOPS，峰值是平均的2倍，那整个池子的峰值需求就是10001002=200,000 IOPS。再看磁盘能力，如果用NVMe SSD，单盘厂商给的随机写IOPS是80,000，考虑写惩罚和其他损耗，实际单盘可能打5折就是40,000。那需要的盘数大约是200,000/40,000=5盘。再加一点冗余，比如10%-20%，就得到最终盘数。
容量侧的计算也常用。100台虚机，每台系统盘100GB，数据盘200GB，快照每天一个保留5天，再考虑30%损耗，最终池子需求量和物理盘数量的关系就能算得很清楚。这个公式看起来简单，但很多初学在做存储选型时根本不列算式直接拍脑袋，差别就在这。
5.3 云环境下的性能观测方法
实际环境中，Unity操作看似繁琐，建议分三步走：
第一步，看底层磁盘。登录存储阵列或分布式存储自己的管理界面，先看单块盘的健康状态和使用率，掉盘或者有坏道都会导致性能异常。
第二步，看存储池IOPS和延迟。如果池子整体延迟上来了，那就是容量或并发的问题；如果只是个别卷延迟高，就要怀疑热点卷或者快照是否过于膨胀。
第三步，看虚拟机层面。虚机内的监控（比如IO延迟）往往比存储设备侧更能反映真实用户体感。毕竟存储设备显示"无故障"，但虚机内已经卡得无法操作的情况也很常见，不能只盯一端。
提示：新环境上线前，一定要做基准性能测试，得到一个"刚上线时的正常值"存档。将来遇到投诉"变慢了"时，拿新数值和基线比，判断到底慢了多少、哪个环节明显劣化，排查效率会高很多。存储系统本来就是越用越慢的，没有一个基线数字撑腰，后面谁都说不清楚。
6. 备份、快照与容灾：数据生命周期里的存储知识
最后谈数据保护。很多存储基础笔记把备份和容灾一笔带过，但其实备份快照这块在云计算考试的占比不低，而且做运维时最头疼的就是数据丢。
6.1 快照和备份的区别：不是一回事
快照是"某一个时间点的数据状态"，主要作用是快速还原。它依赖底层存储的COW（Copy on Write，写时复制）或ROW重定向机制，创建速度极快，瞬间就能完成，容量占用在创建时也很小，只有后续发生数据变化时才会逐渐增长。
备份是"把数据完整复制到另一个位置"，与快照的本质差异在于它只跟时间点和一致性有关，不做持续冗余，所以通常备份完成后数据是独立的，不依赖源存储。备份更强调的是"可找回"——能找回很久以前的数据、能找回不同时间点的数据。
实战中正确姿势是两者结合：快照用来应对误删、改错、病毒软删除这类短期故障；备份用来满足审计要求、长期归档，以及整个存储绑定故障的灾难恢复。
6.2 副本、镜像、双活：理解冗余的几个维度
除了傻瓜式备份，存储还经常提到各种同步方式：
- 副本：存储系统内同一数据保存多份，比如三副本模式，写成功至少保证写2份以上，坏了自动从其他副本修复
- 镜像：主要指两地或两个存储间的实时数据镜像，常用于容灾
- 同步复制：源端写成功后立刻被复制到远端，两端数据时刻一致，但代价是延迟增加、依赖远端的稳定性
- 异步复制：源端写成功后在后台异步把数据复制到远端，延迟影响小，但容灾切换时可能丢失最后一小段时间的数据
考试里考灾难恢复类型时，经常让你区分RPO（恢复点目标）和RTO（恢复时间目标）。同步复制的RPO趋近于0，异步复制通常会有几秒到几分钟的数据丢失，而传统备份的RPO可能是上一晚备份的那个时间点。
6.3 数据保护设计不该是事后补丁
写这节前我在笔记本上列过一个表：
| 场景 | 推荐方式 | 原因 |
|---|---|---|
| 误删数据库表 | 快照+定期备份 | 快照秒回，备份保底 |
| 整机故障 | 虚拟机克隆/镜像 | 直接拉起备用虚机 |
| 数据中心级故障 | 异步复制到异地 | 兼顾成本和RPO |
| 勒索恶意加密 | 离线备份 | 必须要有不在线、不可变的副本 |
真正的数据保护设计，应该在存储规划的前期就确定下来。你到底是"一池一备份"、"两地三中心"，还是"三副本加异地异步复制"，直接决定了硬件采购、网络规划、运维团队的工作模式。我见过太多项目上线后才发现没做异地容灾，或者备份窗口覆盖不了所有的数据增长，最后只能拆东墙补西墙，绕了特别大的弯路。
注意：云平台里备份失败最常见的原因，不是网络也不是存储故障，而是"备份窗口内虚机IO过多、快照合并不及时"。所以给虚机打快照做备份时，尽量挑选业务低峰，并且提前评估快照保留时长。永远记住，快照不是坏的，是你没给足它"消化"的时间。
结语
存储学习这块，最容易走弯路的地方就是背了一堆名词却不能串联。DAS、SAN、NAS告诉你存储怎么连接；HDD、SSD、NVMe决定性能下限；RAID解决单盘故障的可靠性；存储池和精简配置解决容量的逻辑切分；性能指标指导你做出合理规划；最后快照和备份帮你守住数据底线。这些知识链环环相扣，考试考它们，其实就是在考你"拿到一台物理服务器、一组业务需求，能不能做出靠谱的存储方案"。
我自己的经验是，学存储不要追求一次全搞懂。先把每种技术到底解决什么问题想明白，再看它的实现机制和代价，最后结合一个具体业务场景去套。哪怕只是在自己的测试环境里手动创建一个RAID组、划分一个LUN、给虚机打一个快照再恢复一次，都比你对着教材念十遍要管用得多。后面复习云计算网络、计算虚拟化时，你会发现存储不是个孤立的知识点，它是整个资源池的底座。
