简介本资源是VMware官方发布的vSAN 8.0 U1深度技术白皮书PDF面向虚拟化架构师、存储工程师及vSphere高级运维人员系统解析vSAN超融合存储的部署逻辑、架构原理与高可用实践。内容覆盖vSAN 8核心能力——包括ESAExpress Storage Architecture新架构、分布式RAID设计、对象存储模型VMDK/见证/副本/性能统计DB、多站点容灾拉伸集群/ROBO/容错域、网络I/O控制与RDMA支持以及vSphere HA与VMCP协同机制等关键主题。资源为单个23.69MB PDF文件结构清晰含5大章节从基础概念与兼容性要求到安装配置实操、底层架构剖析、存储策略管理再到iSCSI/File Service等扩展服务具备完整技术闭环与工程落地参考价值。目前已有153人学习下载适合需深入理解vSAN底层机制、规划生产环境或备考VCP-DCV认证的技术人员系统研读。1. vSAN 8 不是“装完就能用”的存储插件它是一套需要提前规划、精细校准的分布式存储操作系统你刚在 vCenter 里点开「集群 → 配置 → vSAN」看到那个醒目的「启用 vSAN」按钮手已经悬在鼠标上——等等。vSAN 8 不是 VMware Workstation 里勾个 box 就能跑 Ubuntu 的玩具它是把物理服务器的本地磁盘SSDHDD 或全闪拧成一股绳对外提供企业级存储服务的黑匣子。它解决的不是「怎么装虚拟机」而是「当三台主机里有一台宕机数据库 VM 还能不能毫秒级续写日志」「当某块 NVMe 盘突然掉线重建流量会不会把万兆链路打满」「为什么启用了 FTT1 却报错说「可用容量不足」」这些血泪问题。适合谁不是刚配好 ESXi 就想试 vSAN 的新手而是已经管着 5 台以上 ESXi 主机、正被传统 SAN 成本压得喘不过气、且愿意花 3 天画拓扑图和容量表的运维工程师或架构师。这份《VMware-vSAN-8.pdf》不是安装说明书它是 vSAN 8 的「设计宪章」从硬件兼容性矩阵HCL的硬约束、到故障域与见证节点的部署逻辑、再到对象策略Storage Policy如何真正落地为磁盘 IO 路径——它不教你怎么点按钮它告诉你点之前每个按钮背后藏着多少个必须回答清楚的「为什么」。2. vSAN 8 架构选型为什么必须放弃「三节点起步」的幻觉而转向「最小可行集群」的硬核算vSAN 的最小节点数从来不是技术限制而是数据可靠性与运维弹性的数学边界。vSAN 8 官方文档写「支持 3 节点集群」但真实生产中我见过太多团队踩坑三节点集群一旦触发磁盘重建剩余两节点的 CPU 和网络带宽瞬间飙到 95%VM 卡顿、vCenter 响应延迟、甚至触发 HA 误判。这不是玄学是 vSAN 对象副本Object在重建时的并行度与资源争抢模型决定的。vSAN 8 引入了「双主机容错2-Node Cluster」模式但它强制依赖外部见证节点Witness Host且该见证节点不能运行任何 VM——这意味着你实际要部署 3 台物理机2 计算 1 见证成本并未降低反而增加了单点故障面。所以真正的「最小可行集群」是4 节点它允许你配置 FTT1容忍 1 节点故障的同时将重建负载分散到 3 台存活节点IO 峰值可控更重要的是它让你能启用「故障域Fault Domain」——比如把 2 台放机柜 A、2 台放机柜 B避免单机柜断电导致整个集群不可用。这比死磕「3 节点省钱」要实在得多。2.1 硬件兼容性不是「能亮灯就行」HCL 列表里的「Supported」和「Certified」有本质区别VMware 官方 HCLHardware Compatibility List网站上同一款 Dell R750 服务器可能同时出现在两个条目下一个是「vSAN ReadyNode」认证型号另一个是「ESXi Only」支持型号。前者意味着该型号已通过 VMware 全栈测试包括驱动、固件、RAID 模式、NVMe 驱动栈、甚至 BIOS 设置项后者仅表示「ESXi 能装上去vSAN 不保证」。我曾遇到一个案例某客户采购了 HCL 标注为「Supported」的 Supermicro 服务器但其 RAID 卡固件版本未更新到 vSAN 8 要求的最低版本v7.0.1.0导致 vSAN 启用后无法识别缓存盘Cache Tier所有磁盘被当作容量盘Capacity Tier使用性能暴跌 60%。关键动作不是查型号而是查固件驱动组合。vSAN 8 要求RAID/HBA 卡必须工作在JBOD 模式非 RAID 0/1/10否则 vSAN 无法直通管理物理盘NVMe 驱动必须为nvme内核模块而非nvmefc或nvme-rdma且固件需支持NVMe Namespace ManagementBIOS 中必须关闭Secure BootvSAN 8.0U1 之前版本或设置为UEFI Mode with Secure Boot DisabledU1 及之后。提示不要依赖服务器厂商预装的 ESXi ISO。务必从 VMware 官网下载vSAN-specific ISO如VMware-VIMSetup-all-8.0.0-21215222.iso它内置了经 vSAN 测试验证的驱动集比通用 ESXi ISO 更可靠。2.2 存储策略Storage Policy不是「选个模板就完事」它直接翻译成磁盘 IO 路径与重建行为vSAN 的 Storage Policy 是唯一控制数据存放方式的入口但它不是 UI 上几个下拉框那么简单。Policy 中的Number of failures to tolerate (FTT)参数表面看是容错能力实则决定了对象副本数Replica Count和见证组件Witness Component的生成逻辑FTT副本数Replica见证组件数最小节点数典型适用场景0101仅测试开发环境临时 VM121见证32-Node或 4标准生产数据库、核心应用2306关键业务双活容灾但更关键的是Object Space Reservation对象空间预留参数。设为 100%意味着 vSAN 在创建 VM 时就为其分配全部磁盘空间厚置备避免后续扩容时因碎片化导致无法满足策略设为 0%则是精简置备但一旦磁盘使用率超过 80%vSAN 会拒绝新建 VM 并触发告警——这不是容量告警而是「策略无法满足」告警因为精简置备下vSAN 需要预留空间用于重建。血泪经验生产环境一律设为 100%宁可多买 10% 容量也不赌碎片整理算法。2.3 网络设计不是「万兆够用」vSAN 流量必须独占物理网卡且禁用 LACPvSAN 流量vSAN Traffic和 vMotion 流量vMotion Traffic必须分离这是硬性要求。很多团队图省事把两者绑在同一个 vSwitch 下用 VLAN 隔离——这会导致 vSAN 流量在拥塞时被 vMotion 抢占引发心跳超时、集群分裂Split-Brain。正确做法是为每台 ESXi 主机配备至少 2 块独立万兆网卡一块专供 vSAN一块专供 vMotionvSAN 网卡必须绑定到vSphere Distributed SwitchvDS且启用Network I/O Control (NIOC)为 vSAN 流量设置Share值为High默认 50建议调至 100绝对禁用 LACP802.3ad。vSAN 使用自己的多路径算法基于 IP Hash 端口 IDLACP 会干扰其路径选择导致部分流量走不通。官方明确要求使用Route based on originating virtual port ID或Route based on physical NIC load。# 在 ESXi Shell 中检查 vSAN 流量是否走对网卡替换 vmk2 为你的 vSAN vmkernel 接口名 esxcli network ip interface ipv4 get -i vmk2 # 输出应显示Enabled: true, IPv4 Enabled: true, IPv4 Address: 192.168.100.10/24 # 然后确认该接口绑定的物理网卡 esxcli network ip interface list -i vmk2 | grep Portset # 应返回类似Portset: vds-vsan-pg说明已绑定到 vDS这段命令验证的是「配置存在」但真正要确认流量路径必须用tcpdump抓包# 在 vmk2 接口抓 vSAN 心跳包端口 22333 tcpdump-uw -i vmk2 port 22333 -c 10 # 正常输出应包含多个源 IP其他节点 vmk2 地址和目标 IP本机 vmk2 地址 # 若只看到本机发包无回包说明网络连通性或防火墙有问题3. vSAN 8 启用流程从「集群配置」到「首个 VM 落地」的七步闭环操作启用 vSAN 不是点击「启用」按钮就结束而是从底层硬件校验到上层策略验证的完整闭环。以下步骤缺一不可且顺序不可颠倒。我一般会把每一步的结果截图存档作为后续审计依据。3.1 第一步校验所有主机的 vSAN 硬件状态vsanHealth在 vCenter Web Client 中进入「主机和集群」→ 选择集群 → 「监控」→ 「vSAN」→ 「健康状况」。这里不是看绿色对勾而是点开每个节点的「详细信息」Physical Disk State所有磁盘状态必须为Online且Usage显示为Cache或Capacity不能出现UnknownNetwork Health所有节点间vSAN Network状态为OK延迟 5ms跨机柜可放宽至 10msCluster HealthvSAN Cluster状态为Online且Number of Objects为0表示尚未启用。注意如果某节点显示Not Eligible常见原因是该节点未配置 vSAN vmkernel 接口或该接口未启用vSAN Traffic服务。右键节点 →「编辑设置」→「网络适配器」→ 找到对应 vmk 接口 →「启用 vSAN 服务」。3.2 第二步创建 vSAN 数据存储Datastore这是最易被跳过的一步但却是策略生效的前提。在集群「配置」→「vSAN」→「快速入门」中点击「启用 vSAN」后系统会引导你创建 Datastore。关键参数Name建议命名为vsanDatastore-Prod避免用vsanDatastore这类泛称Default Storage Policy必须选择一个已存在的策略如FTT1不能留空Enable Deduplication and Compression生产环境强烈建议开启。vSAN 8 的去重压缩是 inline写入时即处理CPU 开销 5%但容量节省可达 30–50%。注意开启后无法关闭且会影响快照大小计算。# 启用去重压缩后验证是否生效需在 ESXi Shell 中执行 esxcli vsan storage list # 输出中应包含Deduplication: enabled, Compression: enabled # 若为 disabled说明创建 Datastore 时未勾选需删除重建3.3 第三步验证 vSAN 对象状态vsanObjectDatastore 创建完成后vSAN 会自动生成若干系统对象如vsanHealth、vsanStats。我们需确认这些对象已按策略分布# 在任意一台 ESXi 主机上执行替换 cluster_uuid 为你的集群 UUID esxcli vsan debug object list -c cluster_uuid # 正常输出应包含至少 3 行每行含 # Object UUID, State: active, Components: 2 (for FTT1), Hosts: [host1, host2, host3] # 若 Components 数量少于策略要求如 FTT1 但 Components1说明策略未生效或磁盘不足3.4 第四步部署首个测试 VM 并绑定策略创建一个最小 VM1vCPU/1GB RAM/8GB 磁盘关键在磁盘配置在「自定义虚拟机」向导中选择「vSAN Datastore」点击「硬盘」→「编辑」→「存储策略」→ 选择你创建的FTT1策略不要勾选「Thin Provision」选择「Thick Provision Lazy Zeroed」完成部署后在 vCenter 中右键 VM →「编辑设置」→「选项」→「vSAN」→「对象策略」确认策略已绑定。3.5 第五步强制触发一次对象同步vsanResync新 VM 部署后vSAN 会异步同步副本。为验证同步是否成功手动触发# 获取 VM 的 World ID在 vCenter 中右键 VM →「摘要」→「配置」→「World ID」 # 假设 World ID 为 123456 esxcli vsan debug object resync -w 123456 # 等待 30 秒再执行 esxcli vsan debug object list -w 123456 # 输出中 Components 状态应为 active且 Resyncing 字段为 false3.6 第六步模拟节点故障并验证自动恢复这是检验 vSAN 是否真正可用的终极测试。切勿在生产环境操作在测试集群中选择一台非主控节点避免影响 vCenterSSH 登录该主机执行esxcli system shutdown poweroff --reason vSAN test等待 2 分钟观察 vCenter 中该节点状态变为Disconnected进入「监控」→「vSAN」→「故障域」确认集群状态仍为Online查看该测试 VM 的「摘要」→「vSAN」确认其Object Health为Healthy且Components数量未减少。3.7 第七步导出 vSAN 健康报告vsanHealthReport最后一步不是收工而是建立基线。在 vCenter 中「监控」→「vSAN」→「健康状况」→「生成报告」选择「完整报告」格式选PDF报告包含硬件兼容性摘要、网络延迟矩阵、磁盘使用热力图、对象分布统计、最近 7 天告警日志。这份 PDF 就是你未来半年的运维基准线。下次扩容或升级前必须重新生成并对比差异。4. vSAN 8 常见问题排查五个高频翻车现场与根因定位法vSAN 的报错信息往往藏在层层嵌套的 UI 菜单深处或以晦涩的 CLI 错误码呈现。以下是我在客户现场亲手解决的五个典型问题每一条都附带现象、根因、定位命令和修复动作拒绝模糊描述。4.1 现象启用 vSAN 时提示「Host located in vSAN cluster but vSAN service is not enabled」现象集群已添加主机但在「配置」→「vSAN」页面该主机状态显示为灰色提示「主机位于 vSAN 集群中但尚未启用 vSAN 服务」。原因该主机的 vSAN vmkernel 接口vmk未启用vSAN Traffic服务或该接口未绑定到正确的 vDS 端口组。定位# 登录该主机 ESXi Shell esxcli vsan network list # 若输出为空说明未配置 vSAN 网络 # 若输出显示 vmk2 但 State 为 inactive说明服务未启用 esxcli network ip interface list | grep vmk2 # 查看 vmk2 是否启用 vSAN 服务 esxcli network ip interface tag list -i vmk2 | grep vsan # 若无输出说明未启用解决在 vCenter 中右键该主机 →「编辑设置」→「网络适配器」→ 找到 vmk2 →「启用 vSAN 服务」确认 vmk2 绑定的端口组属于 vDS且该端口组未启用 LACP。4.2 现象vSAN Datastore 创建失败报错「Insufficient free space to satisfy policy」现象明明集群总容量 10TB却提示「无法满足策略要求」即使创建最小 VM8GB也失败。原因vSAN 要求每个对象Object至少占用200MB的元数据空间Metadata Overhead且 FTT1 策略下需 2 份副本 1 份见证组件实际占用空间 VM 磁盘大小 × 2 200MB × 3。若磁盘碎片化严重vSAN 无法找到连续 200MB 空间。定位# 查看磁盘碎片率需先启用 vSAN Performance Service esxcli vsan storage list | grep Fragmentation # 若 Fragmentation 30%说明碎片严重 # 查看各磁盘的可用空间单位 MB esxcli vsan storage list | grep Free解决执行esxcli vsan storage reclaim强制回收已删除对象的碎片空间若无效重启 vSAN 服务esxcli vsan cluster leave esxcli vsan cluster join需先备份配置。4.3 现象vSAN 网络延迟高 10msvCenter 报「vSAN Network Health: Warning」现象vSAN 健康检查显示网络延迟超标但 ping 测试ICMP延迟正常 1ms。原因vSAN 使用 TCP 端口 22333 进行心跳和数据同步而 ICMP 包不经过 vSAN 网络栈。问题通常出在物理交换机未启用Jumbo FramesMTU9000导致 TCP 分片交换机 ACL 或 QoS 策略阻断了端口 22333ESXi 主机防火墙未放行该端口。定位# 在主机 A 上抓取 vSAN 端口包 tcpdump-uw -i vmk2 port 22333 -c 5 # 在主机 B 上执行相同命令对比是否双向都有包 # 若主机 A 有发包无回包检查主机 B 防火墙 esxcli network firewall ruleset list | grep vsan # 确认 vsan 规则状态为 enabled解决在物理交换机上全局启用 Jumbo FramesMTU9000在 ESXi 主机上执行esxcli network firewall ruleset set -r vsan -e true检查交换机 ACL 是否放行 TCP 22333。4.4 现象启用去重压缩后VM 克隆失败报错「Cannot create clone: Not enough space」现象开启 Dedup/Compression 后克隆一个 100GB 的 VM 失败提示空间不足但 Datastore 显示剩余 500GB。原因vSAN 的去重压缩是 inline 处理但克隆操作会绕过去重引擎直接复制原始数据块。因此克隆所需空间 源 VM 实际占用的未压缩空间可能远大于 Datastore 显示的「已用空间」。定位# 查看 VM 实际占用的未压缩空间需在 vCenter PowerCLI 中执行 Get-VM TestVM | Get-HardDisk | Select-Object Filename, CapacityGB, {NUsedSpaceGB;E{$_.ExtensionData.CapacityInKB/1MB}} # 若 UsedSpaceGB 远大于 Datastore 显示的已用空间说明去重率高解决克隆前先对源 VM 执行Storage vMotion到同一 Datastore触发去重压缩或改用「链接克隆Linked Clone」它共享父盘数据块不消耗额外空间。4.5 现象vSAN 集群状态为「Degraded」但所有主机和磁盘均显示「Online」现象集群健康状态为黄色「Degraded」点击详情发现「vSAN Cluster: Degraded」但所有节点、磁盘、网络均无告警。原因vSAN 的「Degraded」状态通常由见证组件Witness Component不可达引起。在 2-Node 集群中见证节点宕机或网络中断会导致集群降级在标准集群中若某对象的见证组件所在磁盘故障也会触发此状态。定位# 列出所有对象及其见证组件位置 esxcli vsan debug object list | grep -A 5 Witness # 找到状态异常的对象记录其 UUID esxcli vsan debug object list -u object_uuid # 查看 Witness Component 的 Host 和 Disk ID解决若是 2-Node 集群立即检查见证节点状态及网络连通性若是标准集群定位到故障磁盘执行esxcli vsan storage remove -d disk_id移除该磁盘vSAN 会自动重建见证组件。5. vSAN 8 进阶技巧用 vsanObserver 实时诊断 IO 瓶颈把「慢」定位到具体磁盘与策略vSAN 的性能问题最难缠的地方在于它把 IO 请求打散到多台主机、多个磁盘、多个副本你看到的「VM 卡顿」可能是某台主机的某块缓存盘写满、也可能是见证节点网络抖动、还可能是策略配置导致读请求被路由到远端副本。靠猜不行得用vsanObserver——这是 VMware 官方提供的实时 IO 路径追踪工具它不依赖 vCenter直接在 ESXi 主机上运行把抽象的「vSAN 性能」还原成具体的「哪个磁盘在拖后腿」。5.1 启动 vsanObserver 并连接到目标集群vsanObserver是一个 Java Web 应用需从 VMware 官网单独下载vsanobserver-8.0.0-xxxxxx.jar上传到任意一台 Linux 工作站非 ESXi 主机。启动命令java -jar vsanobserver-8.0.0-21215222.jar \ --vc-ip 192.168.1.10 \ --vc-user administratorvsphere.local \ --vc-password YourStrongPassword \ --cluster-name vsan-prod-cluster \ --port 8080注意--vc-ip必须是 vCenter 的管理 IP不是 ESXi 主机 IP--port是 vsanObserver 的 Web 界面端口浏览器访问http://localhost:8080即可。5.2 读懂 vsanObserver 的三大核心视图vsanObserver 页面分为三个标签页每个都解决一类问题标签页解决什么问题关键指标解读I/O Latency定位 IO 延迟源头Read Latency (ms)和Write Latency (ms)柱状图横轴是主机名纵轴是延迟值。若某主机柱子明显高于其他说明该主机磁盘或网络有问题点击柱子可下钻到该主机的Per-Disk Latency找出具体哪块盘延迟高。I/O Throughput判断带宽瓶颈Read Throughput (MB/s)和Write Throughput (MB/s)曲线。若Write Throughput长期接近网卡上限如万兆卡理论 1250MB/s实际 1100MB/s 即预警说明网络是瓶颈若某主机Read Throughput为 0但其他主机很高说明该主机缓存盘失效读请求全走远端副本。Object Distribution验证策略是否真落地Objects per Host饼图显示每个主机承载的对象数。理想状态是均匀分布误差 10%。若某主机占比 40%说明该主机磁盘容量大但 IO 能力弱vSAN 为保容量均衡牺牲了性能此时需调整该主机的Disk Claim Policy在 vCenter 中右键主机 →「配置」→「vSAN」→「磁盘管理」→「高级选项」→VSAN.ClaimPolicy设为capacity而非performance。5.3 用「Trace」功能捕获单次 IO 的完整路径这是 vsanObserver 最硬核的功能。当你发现某个 VM 持续慢可以对其发起一次fio压测同时在 vsanObserver 中开启 Trace在 VM 内执行fio --namerandwrite --ioenginelibaio --rwrandwrite --bs4k --numjobs4 --size1G --runtime60 --time_based --group_reporting在 vsanObserver 的「Trace」标签页点击「Start Trace」选择该 VM 的 Guest OS 名称Trace 结束后生成.trace文件用 vsanObserver 自带的Trace Analyzer打开分析结果会显示该次写请求的路径是VM → HostA Cache Tier → HostB Capacity Tier → HostC Witness耗时 12.3ms其中HostB Capacity Tier贡献了 8.7ms —— 这就精准定位到是 HostB 的某块 HDD 盘老化需更换。5.4 建立自动化健康巡检每天凌晨导出 vsanObserver 报告vsanObserver 支持命令行导出报告可集成进 cron# 创建脚本 /root/vsan-health-check.sh #!/bin/bash DATE$(date %Y%m%d) java -jar /opt/vsanobserver.jar \ --vc-ip 192.168.1.10 \ --vc-user administratorvsphere.local \ --vc-password YourPassword \ --cluster-name vsan-prod-cluster \ --export-report /var/log/vsan-report-$DATE.pdf \ --report-type health # 添加定时任务 echo 0 2 * * * /root/vsan-health-check.sh /etc/crontab这样每天凌晨 2 点一份包含昨日 IO 延迟峰值、磁盘健康度、对象分布偏差的 PDF 就会生成。我习惯把它邮件发送给运维组并设置阈值告警若I/O Latency峰值 50ms 持续 5 分钟自动触发 PagerDuty 告警。从那以后我每次上线新集群都强制走一遍 vsanObserver 的 I/O Latency 和 Object Distribution 两个视图哪怕只是看一眼数字是否在基线范围内。它不保证不出问题但能让我在用户投诉前 3 小时就知道哪块磁盘在呻吟。希望帮到你。本文还有配套的精品资源点击获取
