1 云平台内核：存储要理解什么
订单 API 收到购买请求后，通常要把订单写入数据库，再向用户返回结果。部署平台能启动进程，身份系统能限制访问，网络能把请求送达；存储负责让提交的数据在约定的故障范围内留下来。用户看到的是“订单已提交”，平台看到的却是一串跨越应用、操作系统、虚拟卷和物理设备的动作。理解云存储，就是把这些动作与承诺对应起来：数据写到了哪里，什么时候算完成，谁能读取，故障后怎样恢复。
本课聚焦支撑虚拟机和数据库的块存储。卷把可寻址的数据空间交给主机，主机再组织文件系统或数据库文件。对象存储通常通过对象接口读写，文件存储通常提供共享目录，它们在访问方式和管理边界上不同。订单附件可以放对象存储，数据库可以使用块卷，但不能仅凭“都是存储”就互换接口。具体数据库也可能采用本地盘或其他服务形态，选择需要结合其恢复能力。
从平台视角看，卷是逻辑资源，存储池是汇集容量和性能的管理单元，设备才提供底层介质。多个卷可以共享同一个池，因此某个卷变慢，原因可能在自己的限额，也可能在共同使用的设备、链路和后台任务。容量配额回答“最多允许占多少”，性能约束回答“可以消耗多少服务能力”；拥有 100 GiB 卷，并不自然获得固定的 IOPS 或带宽。
读写完成也有层次。程序把数据交给内存缓冲区，不能自动视为断电后仍可恢复；数据库提交、文件系统刷新和卷的持久化完成需要遵守各自约定。平台文档应明确完成语义、故障假设和责任边界。初学阶段先记住：请求返回成功的含义需要核实，副本数量本身不能解释全部数据保证，更不能替代数据库事务语义。
平台身份权限同样作用于数据。能创建虚拟机，不一定应该能挂载所有订单卷；能读取监控，不应因此获得快照导出权限。卷挂载、快照创建、备份读取和密钥使用应分别授权。监控则把这些资源连起来：当订单提交变慢时，需要知道它使用哪个卷、属于哪个池、所在故障范围以及当时发生了什么。后面的机制都围绕这条可追踪的路径展开。
2 池化、精简与快照
池化把多个设备的容量与服务能力集中管理，再向上分配卷。它减少逐台设备分配带来的碎片，也便于迁移数据和统一执行策略。不过，汇集资源同时建立了共享关系。某个租户做全盘扫描，可能消耗其他租户需要的吞吐；多个租户同时扩容，也可能让池内空闲空间迅速下降。平台必须管理资源总量和共同活动，不能只看每个卷单独是否合法。
精简分配允许先声明逻辑容量，等实际写入时再消耗物理空间。例如创建 10 个 100 GiB 卷，逻辑承诺合计 1000 GiB，当前实际数据可能只有 200 GiB。这能提高利用率，但不能据此认为其余承诺永远不会兑现。要区分已承诺逻辑容量、已分配物理空间和可用物理空间，并把副本、快照、元数据及预留空间纳入容量账本。不同实现的统计口径需要逐项确认。
精简卷删除文件后，池内空间未必立即减少。文件系统需要支持并发出空间释放提示，存储层需要识别这些提示，旧数据还可能被快照引用，回收任务也可能异步执行。因此，主机显示“空闲很多”和池显示“空间紧张”可以同时成立。排查时应沿层次确认空间是否已经释放，而不是反复删除文件后等待数字自动一致。空间水位告警也应看增长速度，给扩容和迁移留出时间。
快照记录某个时刻的卷状态。常见实现通过保留旧版本和维护映射避免立即完整复制所有数据，但具体机制并不完全相同。快照创建很快，不代表没有后续成本：持续覆盖数据可能增加保留空间，快照链和回收也会带来额外工作。估算快照空间时，变化量与保留时间通常比快照个数更有解释力。每天修改很少的卷，与持续覆盖大量数据的卷，保留成本会明显不同。
快照的一致性还要单独讨论。仅在存储层截取状态，往往只能得到类似突然掉电后的磁盘视图；数据库可能需要依靠日志恢复。若希望得到应用一致的恢复点，应按数据库支持的流程协调写入、日志和快照。涉及多个卷时，也要确认它们是否属于同一个一致性范围。不能把“每个卷都有快照”直接等同于“整套应用能在同一业务时刻恢复”。
把快照用于快速回退很方便，但恢复前应明确丢失范围。若回到 10:00 的状态，10:00 之后确认的订单可能需要从其他记录补齐。回退还可能影响仍在运行的应用连接与缓存。实际操作通常更适合先从快照创建隔离副本，确认数据和应用能启动，再决定切换方式。这样既能检验恢复点，也能避免在原卷上反复尝试而覆盖排查证据。
3 QoS、副本与重建
存储 QoS 是对服务能力的分配与约束。常见指标有每秒 I/O 操作数 IOPS、每秒传输的数据量和延迟。假设每个请求传输 4 KiB，1000 IOPS 对应约 3.9 MiB/s 的数据量；请求改为 1 MiB，同样的 IOPS 就会提出完全不同的带宽需求。因此，单写“支持 1000 IOPS”不够，还应说明请求尺寸、读写比例、并发、持续时间，以及是否允许短时突发。
上限、保障和权重表达不同意思。上限限制租户最多使用多少，保障表示在约定条件下可以获得多少，权重表示竞争时的相对分配关系。给所有卷设置上限，可以减少个别租户无限占用，却不能自动保证所有卷同时达标。保障总量需要与池能力和故障余量匹配；突发额度也要说明补充和耗尽规则，否则测试初期很快、运行稍久就变慢，会被误认为设备发生了随机故障。
副本把数据保存在多个位置，以应对约定的故障。例如采用 3 副本时，应说明这些副本是否跨设备、主机或更大的故障范围。多个副本若共用同一个供电或机柜，仍可能一起不可用。副本还会消耗空间和写入资源；逻辑数据量不能直接当作物理占用量。完成写入需要哪些副本确认、故障时能否继续写入，应以服务约定为准，本课不展开具体协议。
设备故障后，剩余副本可以提供恢复来源。平台将缺失的数据复制到健康位置，使冗余回到目标状态，这个过程称为重建。重建不是免费维护：它需要读取健康设备、经过链路并写入新位置，与订单请求竞争资源。平时足够用的池，可能在重建时出现排队。采购和准入只按健康稳态能力计算，就会把故障期间最需要的余量全部售出。
重建过快会挤压前端，过慢则延长冗余不足的时间。合理策略是同时约束前端服务目标与恢复期限，根据剩余冗余、当前负载和设备状态调整后台速率。所谓“保证前端”，必须说明在哪些故障条件下、什么负载范围内成立。无限期暂停重建虽然可能暂时改善延迟，却没有完成恢复；只追求最快重建，也可能让原本仍可服务的订单入口超时。
平台还应区别正常复制流量、重建流量、快照回收和用户批处理。它们可能经过相同资源，但调度优先级和业务紧迫性不同。建立独立观测与预算后，才有条件先限制可延后的任务。高级实现可能涉及更复杂的数据布局和调度，本课先掌握可迁移原则：识别共享资源，说明完成条件，为故障恢复保留空间与性能，并验证这些策略能共同工作。
4 动手：测量一次卷延迟分层
实验目标是判断等待主要出现在哪层，不是给某种介质排排名。使用可丢弃的测试环境与独立测试卷，准备足够空间，确认测试文件路径不属于业务目录。测试工具会产生真实负载，平台共享池也应允许这类测试。先固定卷等级、主机规格、连接方式、请求尺寸和读写比例，记录测试时段及有无快照、重建等后台任务，避免条件变化后仍把结果直接比较。
可以用 fio 在已挂载的测试卷上创建专用文件。下面是起点示例，路径必须换成实际测试挂载点；文件名不要指向原始设备或现有业务文件。这里测量随机读取，文件准备过程仍会写入并占用空间。直接 I/O 是否生效取决于操作系统与文件系统，遇到不支持时应先解释原因，不能静默改动参数后把结果当成同一组实验。
fio --name=read-latency --filename=/mnt/test-volume/c56-test.bin \
--size=2G --rw=randread --bs=4k --ioengine=libaio \
--direct=1 --iodepth=1 --numjobs=1 --time_based=1 \
--runtime=60 --ramp_time=10 --group_reporting先用 1 个并发请求建立基线，再只把队列深度改为 8，其他条件保持一致。队列深度表示允许同时在途的请求数，不代表设备数量。记录 IOPS、带宽和延迟分位数，同时观察主机 I/O、卷 QoS 与池内指标。fio 的提交延迟和完成延迟具有工具自身定义，使用时应核对输出说明；它们不能直接替代订单事务延迟，也不能单凭名称认定是哪段网络在等待。
假设教学记录中，队列深度从 1 增到 8 后，IOPS 从 800 增到 2400，p99 从 4 ms 增到 18 ms。这说明并发提高了完成速率，同时使部分请求等待更久；不能仅凭这组结果断言设备变慢。如果卷的 QoS 等待明显上升而池服务延迟稳定，应优先检查入口预算；如果多个卷的池服务延迟一起上升，则共享资源或后台活动更值得关注。这些数字只是演示如何推理。
延迟分层需要统一测量边界。应用提交延迟可能包含连接池、事务锁、日志写入和存储等待；主机 I/O 指标又可能包含自身队列。不同层的 p99 不能相减来得到“剩余部分的 p99”，因为它们未必对应同一批请求，分位数也不具备这种可加性。应对齐时间窗，结合单次追踪、队列变化和关联指标判断；没有关联证据时，把结论写成待验证假设。
最后在安全范围内重复基线，确认前后的负载条件接近。若测试遇到突发额度耗尽、缓存升温或后台任务启动，就分别记录，不要简单把所有样本平均。短时实验能暴露趋势，不能证明长期服务承诺。实验报告应留下参数、时间窗、环境、分位数和可能干扰因素，再说明下一步要验证哪个假设。测试结束后按实验约定清理专用文件，观察实际空间回收是否存在延迟。
5 密度与尾延迟取舍
密度可以理解为一个共享池承载多少活跃租户或工作负载。增加密度通常能提高资源利用率，因为租户不一定同时达到峰值。但订单高峰、定时任务、备份窗口和业务活动可能让原本独立的负载一起上升。把“平时平均负载低”当作“峰值不会重叠”，会低估共同排队的风险。平台需要观察高峰相关性，并按可接受的故障与突发条件决定准入。
尾延迟描述较慢请求的体验。p99 为 20 ms，表示在给定样本和统计方法下，约 99% 请求延迟不超过该值；它不代表每隔固定请求数就必然出现慢请求，也不说明最慢请求只有 20 ms。订单事务可能依次执行多次 I/O，只要某次关键写入等待很久，整个提交就被拖慢。平均延迟稳定时，p99 仍可能显著恶化，因此只看平均值容易漏掉用户超时。
服务能力接近饱和时，新的请求更容易等候已有工作完成。请求尺寸不一致、读写混合和偶发后台任务，又会让等待分布更加复杂。不能从某个利用率直接推出固定毫秒数，也不能认为所有设备都在相同水位出现拐点。实践中应测量本池在代表性负载下的延迟变化，把可接受区间和保护动作写成策略，再用生产观测逐步修正，而非照搬一条通用阈值。
交互把池能力简化成 100 个资源单位，用来观察预算关系。增加重建预算，前端余量会减少，但重建可以更快推进；降低重建预算，短期前端余量增加，冗余恢复时间却拉长。提高租户数或负载倍数，会增加前端需求。当需求达到可用预算，持续输入就会造成积压。交互没有输出真实 p99，因为实际延迟还取决于大量没有纳入模型的因素。
容量余量和性能余量也不能混用。池内剩余空间很多，设备仍可能因为大量小请求而繁忙；性能暂时空闲，也不代表精简分配可以继续无限承诺容量。平台至少应分别跟踪可用空间、增长速度、服务能力与故障恢复所需余量。为关键订单卷保留预算，可能减少可售资源，却使服务目标更可解释。成本讨论应比较这种保障的收益与占用，而不是把最高利用率视为唯一目标。
6 常见坑：快照当备份且未演练
快照解决快速获得恢复点的问题，备份还需要回答恢复点能否在目标故障后存活。若快照和源卷依赖同一存储池，池级故障可能同时影响它们；若删除权限共用同一身份，误操作或凭据失陷也可能同时删除源数据和快照。有些服务会将快照数据独立保存，因此应核实真实故障范围。关键不是名字，而是数据位置、依赖、权限、保留策略与可恢复性。
备份方案通常需要独立副本和明确的管理边界。是否跨区域、是否独立账号、谁能修改保留策略，应由需要防范的故障决定。仅仅把备份放进另一个目录，不能建立独立故障范围；反过来，也不必为所有测试数据使用最高等级的隔离。订单数据应根据业务价值与恢复要求分级，明确哪些误删、损坏和基础设施故障必须被覆盖，并给出可检查的证据。
恢复点目标 RPO 描述可接受的数据回退范围，恢复时间目标 RTO 描述恢复服务可接受的时间。每 1 小时创建快照，并不自动保证 RPO 为 1 小时：任务可能失败，快照可能不一致，最近可用恢复点也可能更旧。RTO 更不能只统计“创建新卷”的时间，还应包含发现问题、选择恢复点、准备环境、恢复数据库、校验数据、切换连接和确认业务正常。
演练应在隔离环境中完成，并阻止恢复出来的订单服务向真实客户重复发通知、扣款或发货。检查数据库能否启动只是起点，还要抽查订单、明细与支付关联，验证关键业务约束，并确认密钥、权限、配置和依赖服务是否齐全。加密备份若缺少可用密钥，同样无法恢复。演练要记录实际可用恢复点与耗时，不能只保留任务面板上的“成功”状态。
常见失误是备份持续运行，却从未验证恢复；另一个失误是只演练管理员手工修复的理想路径，值班人员无法照做。可执行的恢复手册应给出环境准备、恢复点选择、数据验证、切换条件和回退办法，并说明谁有权限执行。每次数据结构、身份策略或密钥配置发生重要变化，都应评估是否需要重演练。恢复能力是持续维护的流程，不是创建策略时获得的永久属性。
7 案例：重建风暴拖垮前端
某订单平台把在线数据库卷与夜间批处理卷放在同一池中。健康状态下，平均延迟较低，团队据此继续提高租户密度。夜间出现设备故障后，平台开始重建；恰好批处理正在扫描历史订单，在线接口也有持续流量。前端 p99 上升并触发超时，应用立即重试，随后积压进一步增长。设备故障是触发点，共享余量不足与重试放大让局部事件扩散到了服务入口。
值班人员先查看应用吞吐、并发和重试率，确认用户请求量没有相同比例增长。随后对齐时间窗，发现多个卷延迟一起变差，卷限额没有变化，池内设备忙碌与重建流量却明显升高。这条证据链支持“共享资源竞争”的假设。如果只看单个数据库的慢查询，可能误判为查询计划突然退化；如果只看容量尚有空闲，又可能错误排除存储。需要把延迟、负载与事件同时摆在一起。
处置首先限制可延后的批处理，并对应用重试设置退避、抖动和上限，减少额外请求。接着在确认剩余冗余与风险后，调整重建预算，观察前端延迟和预计完成时间。若池能力不足以同时满足目标，还要按预案降级非关键功能或减少准入。每次只改变可解释的参数并保留时间记录，避免多个动作同时执行后无法判断效果。具体限制由平台能力和业务优先级决定。
前端恢复正常不等于事件结束。重建仍在进行时，系统可能处于更脆弱的冗余状态。值班人员应持续跟踪缺失副本、失败重试、剩余工作量和容量水位，直到恢复完成，再逐步解除临时限制。若只把重建压到极低速后关闭告警，下一次故障可能造成更严重后果。恢复过程本身应有告警与升级条件，避免后台任务长期停滞而无人知晓。
复盘将“同池平均利用率不高”改成可以验收的条件：在线与批处理分配不同服务等级，池准入计入故障余量，重建拥有受控预算，应用重试有边界。团队还补做故障期间的混合负载测试，检查关键卷 p99 与冗余恢复时间能否同时达标。所谓重建风暴并非重建机制必然失控，而是多个后台任务、共享瓶颈与前端反馈相互叠加；修复需要覆盖这些联系。
8 把存储 QoS 写进平台方案
方案首先描述工作负载，而不是直接填写某个卷等级。订单数据库的请求尺寸、读写比例、并发、高峰持续时间和增长趋势，决定需要怎样的预算。还要说明业务关注的指标：订单提交延迟与存储 I/O 延迟属于不同边界，目标应分别记录并建立关联。初期数据不足时，可以先给出假设和压测方法，再在试运行后修正，避免用无法解释的精确数字制造确定感。
服务等级应把可用容量、持续 IOPS、带宽、突发规则和延迟条件放在一起。延迟目标要注明测量点、统计窗口、分位数、样本量要求及适用负载，说明故障期间的处理方式。上限不应被包装成保障，突发峰值也不应被写成长期能力。共享池承诺的保障总量必须有准入依据，并说明设备退出、重建启动或空间水位过高时如何保持或调整这些承诺。
观测设计要让业务、主机、卷与池之间可关联。保留卷标识、池标识、服务等级、主机和业务归属，记录变更与后台事件时间。告警可以组合容量增长、QoS 等待、p99、错误率和重建停滞，但应区分“达到约定限额”与“底层无法提供约定能力”。前者可能需要调整负载或等级，后者需要平台排障。清楚的分类能避免所有问题都通过临时扩容解决。
验收至少覆盖稳态、受控突发和故障恢复。稳态验证长期持续能力，突发验证额度与回落行为，故障测试验证前端服务与恢复预算是否冲突。测试应在隔离且获得授权的环境执行，故障注入范围由平台能力限定。验收材料保留负载条件、时间窗、结果和偏差，不只放一张平均吞吐截图。目标未达成时，应说明调整预算、降低密度或改变服务承诺的具体选择。
最后给出责任人和操作入口：谁审批扩容，谁能创建或删除快照，谁管理备份密钥，谁在重建超时后升级处理。容量预测、备份恢复与性能管理应共用资源清单，防止迁移卷后遗漏策略。方案的价值在于把“快、可靠、可恢复”拆成可执行约束，使开发、平台和值班团队对同一个承诺有相同理解。下一节会把这条请求路径延伸到网络。
9 从云平台内核：存储走向云平台内核：网络（C57）
远程存储请求需要经过主机、网络和存储服务。即使设备服务时间稳定，链路拥塞、丢包后的重传或连接异常也可能增加完成时间。反过来，存储重建和副本传输会占用网络资源，使其他业务受到影响。因此，看到卷变慢时要保留网络方向的假设，但不能仅凭“跨机器访问”就把所有等待归因于网络。仍应从测量边界与关联证据出发。
到 C57 时，可以带着本课的共享资源问题继续学习：流量如何隔离，带宽怎样分配，排队发生在哪里，故障时路径如何变化。存储 QoS 与网络 QoS 使用的指标和实现不同，却都需要说明保障、上限、竞争与观测边界。订单 API 的完整路径也会更清楚：身份决定谁能操作资源，网络连接服务，存储保留数据，监控帮助定位偏差。平台方案需要把这些原语组合起来。
现在应能用自己的话解释：为什么逻辑卷总容量可能大于物理池可用容量，为什么快照会随着覆盖写入继续占空间，为什么增加副本不等于已经拥有独立备份，以及为什么重建限速需要同时考虑前端延迟和恢复时间。若这些问题仍只能回答“取决于平台”，就继续补充取决于哪些条件、用什么指标确认。可迁移的知识来自明确条件，而不是记住某个产品页面上的数字。
放进方案里
为订单服务写存储方案时，先建立数据清单：数据库卷保存交易状态，附件使用对象接口，测试数据与生产数据分开管理。每项记录业务负责人、容量增长、访问身份、加密密钥归属和故障范围。订单数据库卷采用明确的服务等级，填写持续 IOPS、带宽、突发规则和适用请求模型；订单提交延迟与卷延迟分别设目标，所有目标注明测量窗口与负载条件。
容量账本同时展示逻辑承诺、实际物理占用、快照保留与恢复预留，按增长速度设置预警和扩容触发条件。池准入保留设备故障后的空间与性能余量，在线请求、批处理和重建分别设置预算。若共享池无法同时满足前端与恢复目标，应在方案中给出降低密度、调整等级或业务降级的选择，并指定执行责任人。
恢复部分填写 RPO、RTO、备份保存位置和权限边界，确认源卷损坏或误删时仍有可用恢复来源。快照用于快速恢复点，独立备份覆盖指定故障范围；数据库一致性按受支持流程保障。演练在隔离环境恢复数据，检查订单关联、密钥可用性和应用启动，并阻止通知、支付等外部副作用。记录实际恢复点、完整耗时及发现的问题。
上线验收提交稳态、突发和故障恢复的负载记录，关联应用、主机、卷、池与重建指标，确认关键分位延迟和冗余恢复时间都符合约定。运行手册明确限流、重试退避、后台任务降速和升级条件。每次迁移、扩容或权限调整后更新资源清单及恢复流程，使方案中的承诺始终对应可观察、可操作的实际资源。
10 小结：下一步云平台内核：网络（C57）
云存储把设备能力组织成可分配的服务。池化提高利用率，精简分配推迟实际占用，快照保留恢复点；QoS 管理竞争，副本与重建管理故障后的数据保护。每项机制都需要容量、性能、权限与恢复条件配合，才能转化为业务可以依赖的承诺。
自测时，尝试回答 3 个问题：卷 p99 上升时应先收集哪些分层证据？快照任务成功为什么仍不能证明订单能恢复？重建降速后还需要验收什么？下一课进入云平台内核：网络（C57），继续追踪请求经过共享路径时的隔离、排队和故障处理。