1. 课程导入与协同设计全景

在企业数据中心里，vSphere 与存储从来不是两个可以各自独立优化的世界。虚拟机的一次写操作，往往要穿过 ESXi 的存储栈、HBA 或网卡、SAN 或 NAS 网络、存储控制器的缓存与后端磁盘，最终才落到介质上。任何一段出现瓶颈或故障，业务感受到的都是"虚拟机变慢"或"业务中断"。本课程要解决的，正是如何把这两侧当作一个整体来设计。

什么是 vSphere 企业存储与虚拟化协同设计

协同设计（Co-design）指的是：在规划 vSphere 集群与后端企业存储时，不把两者当作"先买存储、再配虚拟化"的先后关系，而是围绕同一组业务目标，同时确定虚拟化侧的参数（集群规模、HA/DRS 策略、数据存储布局、多路径策略、队列深度）与存储侧的参数（RAID 级别、分层策略、缓存配置、LUN/卷的容量与 IOPS 上限、快照与复制策略），使两侧在性能、容量、可用性和成本四个维度上互相匹配、彼此留有余量。

一个典型的反例是：存储侧按 7.2K NL-SAS 大容量池设计，虚拟化侧却把几十台高事务数据库虚拟机放在同一个数据存储上，且未做 SIOC 限制。结果是随机 IOPS 被后端机械盘拖垮，而容量却大量闲置。协同设计要避免的正是这种"单侧最优、整体最差"。

四个核心矛盾

协同设计的本质是在四组相互拉扯的目标之间找平衡点：

• 性能：IOPS、吞吐、时延三者不可同时无限提升。随机小块看 IOPS 与时延，顺序大块看吞吐。虚拟化侧的队列深度、多路径策略与存储侧的缓存命中率、后端盘类型共同决定实际表现。
• 容量：精简置备、快照、克隆会带来容量放大；存储侧的精简池超配又可能在某次批量克隆后瞬间耗尽。容量必须按"有效可用容量"而非"标称容量"规划。
• 可用性：vSphere HA 依赖共享存储的可达性，存储双活、多路径、快照与复制策略决定了 RPO/RTO。可用性每提升一档，成本往往非线性上升。
• 成本：每 IOPS 成本与每 GB 成本方向相反。全闪存解决性能但推高每 GB 成本，大容量机械盘压低每 GB 成本却牺牲时延。分层与策略化放置是调和手段。

这四者构成一个"不可能三角加一"的约束：任何设计决策都会同时影响四项，必须显式说明取舍，而不是默认某一项优先。

整体设计框架

本课程采用"自下而上分层、自上而下约束"的框架。自下而上指从物理介质、存储控制器、网络/交换、ESXi 存储栈到虚拟机磁盘逐层理解；自上而下指从业务 SLA 反推每一层需要满足的指标。两者在"数据存储"这一层交汇，因此数据存储是协同设计的关键锚点。

图中左侧的绿色箭头表示"自下而上理解"：只有先弄清 NVMe、SAS、NL-SAS 在随机与顺序负载下的真实差异，才能判断某类业务能否放在某个存储池上。右侧橙色箭头表示"自上而下约束"：业务 SLA 先决定时延与 RPO 上限，再逐层推导出存储侧需要多少缓存、虚拟化侧需要怎样的多路径与队列配置。两条路径在"数据存储"处交汇，因此后续每一章都会回到这个锚点。

学习路径与关键判断

课程按"认知—选型—配置—验证—优化"推进，但并非线性流程，而是围绕数据存储反复迭代。前期先建立存储介质、协议、RAID 与缓存的基础认知；中期进入 vSphere 存储栈、多路径、数据存储设计与 SPBM 策略；后期聚焦性能排障、容量治理、可用性设计与成本优化。

在进入具体章节前，建议先完成一次现状盘点，作为后续设计的输入。下面是一份可直接填写的协同设计输入清单示例（数值为示例假设，非实测）：

有了这张表，就能初步判断：核心数据库必须落在全闪存池并配置固定多路径与较高队列深度；虚拟桌面适合全闪存或混合分层并启用 SIOC 限制；文件共享可放在大容量 NL-SAS 池；测试环境可用精简置备加低优先级策略。这正是协同设计"先约束、后选型"的体现。

本课程要建立的判断力

学完本课程，你应当能够在拿到一个业务需求时，快速回答三个问题：这个负载应该放在哪一类存储池上？虚拟化侧需要哪些配套参数？如果性能不达标，应该先查虚拟化侧还是存储侧？这三个问题贯穿全部章节，也是协同设计能力的直接体现。

接下来，课程将从存储介质与协议的基础认知开始，逐步搭建起完整的协同设计知识体系。