云计算存储基础全解：从DAS/SAN/NAS到RAID与虚拟化-北京尧图网络

存储基础在云计算里的分量很多初学者是低估的。我当年备考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-1507.2K转的盘就更低了。它强的是顺序吞吐单盘顺序读写能跑到150-250MB/s但随机读写能力惨不忍睹。SATA和SAS是两种常见的企业级硬盘接口。SATA便宜、容量大适合做冷数据存储SAS通道数多、协议支持全双工、抗并发能力强适合对可靠性和IOPS要求更高的场景。很多服务器里的系统盘、数据库盘宁可多花点钱上SAS也不拿SATA去赌性能。2.2 NVMe固态盘带来的性能跃升固态盘SSD因为内部没有机械运动随机IO能力比HDD提升了整整一个数量级。普通的SATA SSD随机读的IOPS能做到2-5万而走PCIe通道的NVMe SSDIOPS轻松到十几万甚至更高延迟也从机械盘的十几毫秒降到了几十微秒级别。在云平台里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/写惩罚2600。如果是8块盘组RAID5同样是150单盘IOPS写场景下大约只有8150/4300。四舍五入打对折都不止。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倍那整个池子的峰值需求就是10001002200,000 IOPS。再看磁盘能力如果用NVMe SSD单盘厂商给的随机写IOPS是80,000考虑写惩罚和其他损耗实际单盘可能打5折就是40,000。那需要的盘数大约是200,000/40,0005盘。再加一点冗余比如10%-20%就得到最终盘数。容量侧的计算也常用。100台虚机每台系统盘100GB数据盘200GB快照每天一个保留5天再考虑30%损耗最终池子需求量和物理盘数量的关系就能算得很清楚。这个公式看起来简单但很多初学在做存储选型时根本不列算式直接拍脑袋差别就在这。5.3 云环境下的性能观测方法实际环境中Unity操作看似繁琐建议分三步走第一步看底层磁盘。登录存储阵列或分布式存储自己的管理界面先看单块盘的健康状态和使用率掉盘或者有坏道都会导致性能异常。第二步看存储池IOPS和延迟。如果池子整体延迟上来了那就是容量或并发的问题如果只是个别卷延迟高就要怀疑热点卷或者快照是否过于膨胀。第三步看虚拟机层面。虚机内的监控比如IO延迟往往比存储设备侧更能反映真实用户体感。毕竟存储设备显示无故障但虚机内已经卡得无法操作的情况也很常见不能只盯一端。提示新环境上线前一定要做基准性能测试得到一个刚上线时的正常值存档。将来遇到投诉变慢了时拿新数值和基线比判断到底慢了多少、哪个环节明显劣化排查效率会高很多。存储系统本来就是越用越慢的没有一个基线数字撑腰后面谁都说不清楚。6. 备份、快照与容灾数据生命周期里的存储知识最后谈数据保护。很多存储基础笔记把备份和容灾一笔带过但其实备份快照这块在云计算考试的占比不低而且做运维时最头疼的就是数据丢。6.1 快照和备份的区别不是一回事快照是某一个时间点的数据状态主要作用是快速还原。它依赖底层存储的COWCopy on Write写时复制或ROW重定向机制创建速度极快瞬间就能完成容量占用在创建时也很小只有后续发生数据变化时才会逐渐增长。备份是把数据完整复制到另一个位置与快照的本质差异在于它只跟时间点和一致性有关不做持续冗余所以通常备份完成后数据是独立的不依赖源存储。备份更强调的是可找回——能找回很久以前的数据、能找回不同时间点的数据。实战中正确姿势是两者结合快照用来应对误删、改错、病毒软删除这类短期故障备份用来满足审计要求、长期归档以及整个存储绑定故障的灾难恢复。6.2 副本、镜像、双活理解冗余的几个维度除了傻瓜式备份存储还经常提到各种同步方式副本存储系统内同一数据保存多份比如三副本模式写成功至少保证写2份以上坏了自动从其他副本修复镜像主要指两地或两个存储间的实时数据镜像常用于容灾同步复制源端写成功后立刻被复制到远端两端数据时刻一致但代价是延迟增加、依赖远端的稳定性异步复制源端写成功后在后台异步把数据复制到远端延迟影响小但容灾切换时可能丢失最后一小段时间的数据考试里考灾难恢复类型时经常让你区分RPO恢复点目标和RTO恢复时间目标。同步复制的RPO趋近于0异步复制通常会有几秒到几分钟的数据丢失而传统备份的RPO可能是上一晚备份的那个时间点。6.3 数据保护设计不该是事后补丁写这节前我在笔记本上列过一个表场景推荐方式原因误删数据库表快照定期备份快照秒回备份保底整机故障虚拟机克隆/镜像直接拉起备用虚机数据中心级故障异步复制到异地兼顾成本和RPO勒索恶意加密离线备份必须要有不在线、不可变的副本真正的数据保护设计应该在存储规划的前期就确定下来。你到底是一池一备份、两地三中心还是三副本加异地异步复制直接决定了硬件采购、网络规划、运维团队的工作模式。我见过太多项目上线后才发现没做异地容灾或者备份窗口覆盖不了所有的数据增长最后只能拆东墙补西墙绕了特别大的弯路。注意云平台里备份失败最常见的原因不是网络也不是存储故障而是备份窗口内虚机IO过多、快照合并不及时。所以给虚机打快照做备份时尽量挑选业务低峰并且提前评估快照保留时长。永远记住快照不是坏的是你没给足它消化的时间。结语存储学习这块最容易走弯路的地方就是背了一堆名词却不能串联。DAS、SAN、NAS告诉你存储怎么连接HDD、SSD、NVMe决定性能下限RAID解决单盘故障的可靠性存储池和精简配置解决容量的逻辑切分性能指标指导你做出合理规划最后快照和备份帮你守住数据底线。这些知识链环环相扣考试考它们其实就是在考你拿到一台物理服务器、一组业务需求能不能做出靠谱的存储方案。我自己的经验是学存储不要追求一次全搞懂。先把每种技术到底解决什么问题想明白再看它的实现机制和代价最后结合一个具体业务场景去套。哪怕只是在自己的测试环境里手动创建一个RAID组、划分一个LUN、给虚机打一个快照再恢复一次都比你对着教材念十遍要管用得多。后面复习云计算网络、计算虚拟化时你会发现存储不是个孤立的知识点它是整个资源池的底座。

云计算存储基础全解：从DAS/SAN/NAS到RAID与虚拟化

相关推荐

Samba服务零基础到实战：SMB协议、权限模型与客户端挂载全指南

MyBatis源码解析：日志模块中的适配器模式与代理模式实践

Blazor WebAssembly 与 gRPC-Web：从 proto 到浏览器的高性能通信实践

更多资讯

OpenClaw龙虾场主模式：用状态机与检查点把多Agent协作拉回正轨

ARM内核深度对比：Cortex-M与Cortex-A运行模式及寄存器组解析

Python桌面截图文字识别：自适应分辨率与OCR实战

C语言多线程+Pipe实现单机聊天系统

双节锂电池主动均衡设计：MP2642GR-Z与STM32G071RB协同方案

双节锂电池主动均衡设计：MP2642+PIC18LF4680硬件闭环方案

今日更新

NetSpot 实战：用信道分析与频宽优化解决 Wi-Fi 卡顿

C++ split() 字符串分割的五种实现与性能实测

R语言坐标轴范围设置：从xlim/ylim到coord_cartesian的完整指南

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？