在 vSphere 8.0 的版本里,vSAN 的部署流程相比 6.x/7.x 时代有明显的变化,尤其是新的快速配置向导、集群类型选择、以及被称为 ESA 的高级存储架构,很多人照着老教程去做会卡在集群页面上找不到入口。这篇文章梳理一下我最近在 vSphere 8.0 环境里从零部署 vSAN 8 集群的完整过程,包括硬件资源规划、网络要求、vCenter 配置、集群启用、磁盘组和存储策略的下发,以及健康检查中常见报错的处理思路,希望能给你一份可以直接落地参考的实验手册。无论你是想搭一套用于学习 vSAN 的实验环境,还是准备在生产里用软件定义存储替换传统 SAN,部署思路基本都是相通的,但细节上我会单独把实验场景的坑标出来。
1. 动手之前想清楚:vSAN部署的架构思路与版本取舍
1.1 vSAN 的存储逻辑其实不难懂
很多人第一次接触 vSAN,容易被分布式存储、对象存储、存储策略这些词吓到。我的理解方式很简单:vSAN 就是把每台 ESXi 主机本地插着的 SSD 和 HDD 聚合成一个分布式共享存储池,再通过 vSphere 统一的存储接口提供给集群里的虚拟机使用。虚拟机跑在主机 A 上,数据可能同时存了一份在主机 B 和主机 C 的本地磁盘里,任何一台主机宕机了,另一台主机上还有副本,虚拟机可以自动在其它主机重新启动。
这种设计带来的最大变化是存储不再依赖机架顶部的 SAN 交换机和后端磁盘阵列,而是跟着 ESXi 主机走。你加一台新主机进去,往里面插几块盘,vSAN 集群容量就自动扩容。所谓的“对象”和“组件”则是 vSAN 内部的逻辑单位:虚拟机的 VMDK 会被拆分成多个对象,每个对象根据存储策略生成一个或多个组件,分布在不同主机上。这些机制你不用理解到很深也能完成部署,但如果你能在配置之前知道“数据为什么放在那里”,后面排查故障时会从容很多。
1.2 vSAN 8 两种架构怎么选
vSphere 8.0 里最让老用户不习惯的是,创建 vSAN 集群时会遇到“vSAN OSA”和“vSAN ESA”两种架构。
OSA(Original Storage Architecture)是传统结构,延续了 7.x 里“磁盘组 + 缓存盘 + 容量盘”的概念。你仍然需要在每台主机上规划一块 SSD 作为缓存盘,若干 HDD 或 SSD 作为容量盘,然后创建磁盘组。这种架构兼容性好,既支持全闪配置,也支持混合配置,对硬件要求相对宽松。
ESA(Express Storage Architecture)是 vSAN 8 主推的新一代架构。它不再使用磁盘组,以全 NVMe 闪存为核心,整个主机上的 NVMe 设备统一贡献给存储池,由 vSAN 自动管理。ESA 的数据路径效率高、可预测性好,但官方对硬件的要求也更高:它要求全闪,要求所有参与主机的存储设备都为 NVMe,而且至少需要一个支持特定功能集的 NVMe 设备。对绝大多数普通实验环境来说,你搞不到几块企业级 NVMe 盘来跑嵌套实验,所以老老实实用 OSA 做标准集群是更现实的路径。
我建议你在学习阶段先完整跑一遍 OSA,理解磁盘组、缓存盘、容量盘的作用,之后再考虑搭建 ESA 环境来感受新架构。遇到生产上讨论“转 ESA”的情况,那是另一个要单独写一篇文章的迁移话题,前提条件非常多。
1.3 实验和生产环境资源规划清单
以下是部署 vSAN 前必须确认的资源项,无论实验还是生产都通用,只是数量级不同:
- 主机节点:实验环境建议至少 3 台 ESXi 主机。3 台是为了支持默认存储策略 FTT=1,即允许 1 台主机或磁盘故障而不中断业务。如果你的实验资源紧张,只有两台物理机,vSAN 也支持 2 节点直连模式,但需要额外部署一台见证主机(witness),配置复杂度高不少,不推荐初学阶段碰。生产集群建议从 3 台起步,如果要跑 RAID 5/6 纠删码策略,则需要至少 4 台/6 台。
- 存储:每台主机至少需要 1 块缓存盘和 1 块容量盘。缓存盘必须是 SSD 或 NVMe,容量盘在混合架构里可以使用机械盘,全闪架构中则是 SSD。缓存盘上不保存真正的数据,它只承担读缓存和写入缓冲,所以容量不需要太大,但是寿命和随机性能要好。
- 内存与 CPU:ESXi 8.0 官方要求 CPU 必须支持 AVX2 指令集,这一点很重要,很多旧服务器直接因此装不上 ESXi 8。实验环境里,每台虚拟机建议给 8GB 以上内存,实际跑 vSAN 加 vCenter 时,如果每台 ESXi 只有 8GB,创建虚拟机、跑存储策略校验可能会感觉明显卡顿。有条件的话,三台节点各给 12-16GB 最稳。生产环境请直接查 VMware 兼容性指南(HCL),不要凭感觉买盘。
- 网络:vSAN 流量带宽直接影响存储性能。生产环境至少 10GbE 起步,实验环境用 1GbE 也能跑通流程,只是性能一般。需要单独规划一个网段给 vSAN 使用。
我把实验环境中常见的资源参考值整理成表,方便你对照:
| 资源项 | 实验环境建议 | 说明 |
|---|---|---|
| ESXi 8.0 主机数量 | 3 台 | 支持 FTT=1 的最小主机数 |
| 每台主机 CPU | 4 vCPU 以上 | 宿主机必须支持 AVX2 |
| 每台主机内存 | 12 GB 起 | 至少保证虚拟机正常创建与迁移 |
| 每台主机存储 | 1 块虚拟 SSD(缓存)+ 1 块虚拟盘(容量) | 模拟 OSA 磁盘组结构 |
| vCenter | 1 台 | 部署于集群外的单独虚拟机或物理机 |
| vSAN 专网 | 独立网段,如 192.168.20.0/24 | 与管理网络分开 |
如果你用 VMware Workstation 做嵌套实验,整个环境的“主机数量”其实就是你电脑里同时运行了几台虚拟机,CPU 必须是支持虚拟化嵌套的型号,并且 Workstation 里要开启“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 环境准备:这部分不做完,后面全是泪
2.1 基础环境搭建顺序
vSAN 的部署顺序不能乱。我见过不少人先把 ESXi 装好,然后在单机 ESXi 里打开 vSAN 服务,折腾半天发现根本没有配置入口,原因是 vSAN 是基于集群的功能,必须由 vCenter Server 统一管理后才能启用。
正确顺序是:
- 准备至少 3 台安装了 ESXi 8.0 的主机。如果是嵌套实验,这 3 台 ESXi 都作为 VMware Workstation 里的虚拟机运行,并且需要在每台虚拟机的 CPU 设置里勾选“虚拟化 Intel VT-x/EPT”或“AMD-V/RVI”。ESXi 8 对虚拟化支持的检测比旧版严格,这一步没开的话,宿主机无论如何都启动不了。
- 部署一台 vCenter Server Appliance 8.0,通常可以放在第一台 ESXi 上。
- 通过 vCenter Web Client 完成数据中心与集群创建,然后把 3 台 ESXi 主机逐台添加到集群。
关于 vCenter 的部署方式多说一句:vCenter 8.0 安装时要求输入一个 FQDN,而不是直接用 IP 地址。这在后续添加主机时非常容易引发问题。如果实验环境没有 DNS 服务器,你有两个选择,一是给每台 ESXi 的 /etc/hosts 文件加上 vCenter 的映射记录,二是在 vCenter 部署时把所有 ESXi 都用 IP 加入。最稳妥的方式还是手动把主机名映射写进去,否则主机向 vCenter 回连时解析不到 FQDN,主机状态会一直显示“无法访问”。
2.2 vSAN 网络要求,别踩了单播的大坑
vSAN 对网络的要求第一条是:必须要有专用 VMkernel 网络接口,并且该接口上要启用 vSAN 流量服务。很多初学者在集群配置向导里选了 vSAN 网络后一直报“未找到 vSAN VMkernel 接口”,就是因为没有预先创建这个接口。
在 vSphere Client 中,选中每台主机,进入“网络- VMkernel 适配器”,点击“添加 VMkernel 网络适配器”。在协议处选择“VMkernel”,然后在服务列表里勾选 vSAN。请注意:vSphere 8 默认使用单播通信,vSAN 集群里每台主机都需要能通过该 VMkernel 接口和其他主机互通。所谓单播,就是每台主机直接向集群中的所有其它主机发送数据,不再像老版本那样依赖组播。这意味着你的网络拓扑里不需要专门开启组播协议,但所有 vSAN 节点之间的三层路由必须打通。
网络规划上,我的习惯是给 vSAN 单独划分一个 VLAN 和独立网段,不要把 vSAN 的 VMkernel IP 和管理 IP 混在同一网段。实际使用中混在一起也能工作,只是当发生网络抖动时,你很难区分是管理平面问题还是存储平面问题。vSAN 集群的每个节点 IP 最好静态配置,不要用 DHCP 去碰运气。
如果你是多网卡主机,建议至少规划两个物理网口给 vSAN VMkernel 使用,再结合分布式交换机或标准交换机做负载均衡。生产环境通常用两张 10GbE 网卡分别跑 vSAN,或者用两个 25GbE 做冗余。实验环境没有那个条件,就把 vSAN VMkernel 单独挂在一个虚拟交换机上就可以。
2.3 vSAN 磁盘准备与嵌套环境特别注意事项
在把主机加入带 vSAN 功能的集群之前,强烈建议先完成磁盘的清理和确认。物理机上如果这些硬盘以前安装过 ESXi 系统,它们上面会残留 VMFS 分区,不清理的话,vSAN 创建磁盘组时不会认领。
vSphere Client 中处理方式很简单:
- 在主机“存储-存储设备”里选中目标磁盘。
- 右键点击“清除分区”。
- 确认磁盘状态变为“未知”或“未使用”。
嵌套实验里最常踩的坑是:大家给嵌套 ESXi 虚拟机加的“数据盘”在 Workstation 中需要选择“独立-持久”,且“惯用”模式不要选“非持久”。另一个坑是磁盘类型默认可能就是 SATA,你要么就全给 SAS/SCSI 类型的虚拟盘,要么在后端模拟时留意 SATA SSD 的兼容问题。实际部署里我倾向于给每台嵌套主机加两块同样的虚拟磁盘,一块小一点比如 50GB 作为缓存盘,另一块大一点比如 500GB 作为容量盘,并全部“标记为固态磁盘”。
为什么必须标记为固态磁盘?因为嵌套实验中的虚拟盘底层可能是机械盘,ESXi 无法自动把它识别成 SSD。而 vSAN 对缓存盘要求“必须为 SSD”,不标记的话缓存盘无法被创建到磁盘组里。通过下面命令可以查看磁盘是否被识别成 SSD:
bash复制esxcli storage core device list
输出中每块磁盘会有一个 Is SSD 字段,如果显示 false,手动标记成 SSD:
bash复制esxcli storage nmp satp rule add --satp=VMW_SATP_LOCAL --device=<磁盘设备ID> --option=enable_ssd
执行后重新扫描存储适配器,然后再次确认 Is SSD 已经变为 true。这里要注意,嵌套环境里如果你只有一块盘插上去了,上面又装了 ESXi,剩下的空间不足以另做数据盘,最好给虚拟机再加盘之前先关一次机,否则 Workstation 新增的磁盘在系统内可能无法识别。
3. vSAN 集群配置全过程:从磁盘认领到策略下发
3.1 集群创建与主机纳管
登录 vCenter Web Client 后,在工作负载界面创建数据中心,然后在数据中心里创建集群。集群创建向导里会有“vSAN”复选框,你可以在这里勾选,也可以先不勾,等主机全部加入后再单独开启。第一次做实验的话,我建议先不勾选,主机加进来正常无报错之后,再单独走到集群的 vSAN 配置页去启用,这样整个问题排查路径更清晰。
添加主机时,输入 ESXi 的 root 密码或者域账户。vSphere Client 会自动检测主机版本与 vCenter 是否一致,版本不一致往往会提示“不受支持”。有三台主机都加入同一个集群后,先别急着启用 vSAN,花两分钟做三件事:
- 检查每台主机的时间是否同步。vSAN 的健康检查对时间偏差很敏感,偏差过大会直接报时钟偏差错误。
- 确认每台主机都已经配置完 vSAN VMkernel 网络适配器,也就是前面提到的 VMkernel 接口上勾选了 vSAN 服务。
- 在主机“存储”页面里,确认本地磁盘没有 VMFS 残留分区。
如果主机过多,还可以使用 vSphere 的“主机配置文件”功能把网络配置批量下发,不过实验环境只有三台,手动配置比学主机配置文件更省事。
3.2 启动 vSAN 快速配置向导
进入集群详情页后,点击“配置”选项卡,左侧菜单里找到“vSAN”,然后选择“服务”下的“快速配置”。点击“开始”,vSphere 8 的 vSAN 快速配置向导会带着你走完整个配置。这个流程在 7.x 上是“配置 vSAN”按钮,很多人从旧版本升级上来后找不到入口,其实就是因为 vCenter 8 将 vSAN 配置收敛到了“快速配置”里。
快速配置向导第一步是选择集群类型。这个选项至关重要:默认可能会推荐 vSAN ESA,如果你的主机磁盘不是全闪 NVMe,选了 ESA,向导会在后面提醒你至少需要一台 NVMe 设备并提供设备列表,实验环境通常根本无法通过。所以除非你真的有一整套全 NVMe 设备,否则老老实实选择“标准集群”或“vSAN OSA”,两者在 OSA 结构下基本等同。
接着是磁盘认领界面。你可以选择“自动认领所有可用磁盘”或“手动配置”。我强烈建议实验环境手动配置,原因很简单:自动认领有可能把 ESXi 系统盘外的所有磁盘都收进 vSAN,如果某台主机的系统盘没有被单独识别,你可能会把自己的启动盘也填进存储池。在这个界面里,向导会显示每台主机上发现的、可用于 vSAN 的磁盘列表。
在快速配置中,关于网络的部分向导还会要求选择 vSAN 流量使用的网络。如果你已经提前建好 VMkernel 接口,这里会直接列出可用的 vSAN VMkernel 适配器。确认无误后继续,向导会自动在集群上启用 vSAN 文件服务和 vSAN iSCSI 服务,这两个服务不是必须的,可以不勾选,以免引入额外复杂度。
等待向导完成后,集群的“vSAN | 磁盘管理”页面中应该能看到每台主机的磁盘均被标记为“已声明”,同时每台主机可能已经自动创建了一个磁盘组。
3.3 磁盘组设置与容量管理
为什么在 OSA 架构里还要看磁盘组?因为磁盘组是 OSA 的基本管理单元,缓存盘和容量盘必须绑定成一个组,组内缓存盘与容量盘是 1:N 关系。官方推荐一个磁盘组里最多放置 7 块容量盘,如果容量盘更多,再建新的磁盘组并配置额外的缓存盘。
如果你在“磁盘管理”里看不到任何磁盘组,可以手动创建:
- 选中目标主机,进入“磁盘管理”页面。
- 点击“创建磁盘组”。
- 选中一块已经标记为 SSD 的设备作为缓存盘。
- 在容量盘里勾选该主机上其余要加入的磁盘。
- 确认后提交。
每台主机上的磁盘组数量并不要求一致。比如主机 A 上你插了 2 块 SSD 和 10 块 HDD,可以拆成两个磁盘组,每个组 1 块缓存 + 5 块容量;主机 B 只有 1 块 SSD + 5 块 HDD,那它就只有一个磁盘组。在配置策略时,vSAN 会把集群中所有主机的容量视为同一个存储池,虚拟机的组件会根据策略调度到不同主机的磁盘上。
实验中最容易出问题的地方是:嵌套环境下你先在新加的虚拟盘上创建了 VMFS,再打开 vSAN,磁盘盘符一直显示为“不兼容”或“已禁用”。原因就是 VMFS 分区残留。这时候要到主机存储设备里对磁盘执行“清除分区”,把磁盘恢复成未格式化状态,再返回磁盘管理就能正常声明了。
3.4 存储策略:决定数据的冗余形式与效率
vSAN 启用后并不会自动给虚拟机提供存储,真正发挥作用的是“虚拟机存储策略”。vSphere 会默认创建一条 “vSAN 默认存储策略”,所有新建在 vSAN 数据存储上的虚拟机会自动应用这个策略,除非你手动选择其它策略。
默认策略是“允许的故障数 FTT=1,镜像模式 RAID-1”,意思是每个虚拟磁盘对象会在集群内保存 2 份副本,最多允许 1 份副本所在的主机或磁盘发生故障,数据仍然可访问。这种设计对应的最小主机数就是 3 台,因为两份副本加一份故障余量至少需要 3 个不同位置。
如果把默认策略理解为“每份数据都复制两份”,那 FTT=2 就是复制三份,需要至少 5 台主机。对存储容量敏感的环境,可以考虑把镜像模式改成纠删码 ERASURE CODING。比如 FTT=1 时使用 RAID-5,相当于每 4 份数据块加 1 份校验块,空间效率远高于 1:1 镜像,但要求至少有 4 台主机。两个方案的取舍非常清晰:
| 策略参数 | 镜像 RAID-1 | RAID-5 纠删码 |
|---|---|---|
| 允许故障数 | 1 | 1 |
| 最小主机数 | 3 | 4 |
| 可用容量 | 约 50% | 约 75% |
| CPU 开销 | 低 | 中 |
| 适用场景 | 默认、高安全 | 对容量效率更敏感 |
当你配置好策略后,去“存储”页签能看到 vSAN 数据存储,其总容量为你所有主机的容量盘之和,可用容量则取决于策略。比如你总共 3 台主机每台 500GB 容量盘,集群总额 1.5TB,但在 FTT=1 镜像策略下,虚拟机能用的空间大约只有 750GB。很多人部署完 vSAN 后惊呼容量怎么少了一半,其实就是这个原理不算错。在“存储策略”中调整新策略后,可以右键已有虚拟机-“虚拟机策略”-“编辑”,使用新策略重新应用并触发对象重新配置,不过这个操作可能引起数据迁移和重新同步,生产环境要在维护窗口里做。
验证环节也简单:直接在 vSAN 数据存储上创建一台虚拟机,正常装系统、跑应用,然后强制关闭或断开其中一台 ESXi 主机的网络,观察虚拟机的磁盘 IO 是否仍然正常。vSAN 会在剩余主机上重新实现冗余,等故障主机恢复后,vSAN 对象会自动重新同步。掌握这个验证路径,比看一百次文档都有用。
4. 实际部署中的高频问题与排查实录
4.1 vSAN 无法启动,最常见的原因是什么
我总结了这几类出现频率最高的“启动失败”场景:
第一类是许可证权限不足。vSAN 需要 vSphere Enterprise Plus 级别的许可配合独立的 vSAN 许可证。如果你用的是 Standard 版本许可,或者 vSAN 许可证没有正确附加到集群,集群“vSAN 服务”就无法开启。新装环境一般默认有 60 天评估许可,可以覆盖 vSAN,但如果你的 vCenter 或 ESXi 上手动输入过低版本许可证,就要小心了。可以在“许可证”页面查看 vSAN 许可当前是否已分配。
第二类是找不到适合的磁盘。这通常在嵌套实验里最常见,原因是所有磁盘都被 ESXi 用了 VMFS,或者磁盘没有标记为 SSD。处理方式前面已经提过:清理分区,并确认缓存盘 Is SSD 为 true。
第三类是 vSAN VMkernel 接口缺失。进入“集群-监控-vSAN-健康”,你可能会看到“vSAN 网络”检测失败,对应主机的 vSAN VMkernel 未启用流量服务。回到主机网络 VMkernel 适配器编辑里重新勾选 vSAN,并互 ping 所有节点地址确认联通。
还有一类比较隐蔽的是不同 ESXi 主机之间防火墙规则不一致。有些实验环境出于安全考虑改了主机的防火墙配置,阻止了 vSAN 使用的端口。如果你对 ESXi 防火墙做过手工调整,检查一下名为 vsan 相关的防火墙规则是否处于启用状态。通常不做修改默认是允许的。
4.2 健康检查的几个核心指标怎么看
vSAN 健康检查是排错最直接的入口。位置在集群的“监控-vSAN-健康”下。可以看到大量检查项,不用全看,重点关注前几个:
- “标识”:显示集群内主机和网络信息,检查是否有成员失联。
- “硬件兼容性”:生产环境如果磁盘和控制器不在 HCL 列表上,会在这里报错,实验环境可以忽略。
- “排除故障前检查”或者“数据”检查:会检查磁盘组状态、组件数量是否正常。
- “vSAN 对象”:显示是否有降级对象、不可访问对象。正常状态应该是绿色,出现黄或红就说明冗余受到破坏。
健康检查中的“性能服务”如果没开启,也会有一条提示。性能服务本身不是必须,但建议打开,因为它能展示 IOPS、延迟、吞吐量,排查性能问题特别有用。开启方式是在集群“vSAN-性能”中点击“启用”。开启后需要等几分钟才能看到数据曲线。
另一个很有用的指标是“容量使用情况”。vSAN 会在容量使用率超过 80% 时发出告警,超过 90% 时可能禁止写入。在实验里经常有人把 RAID-1 的容量误解为能够实际写入的容量,结果虚拟机创建到一半就报“存储空间不足”。如果遇到这种问题,先检查“vSAN-容量”里的“可用空间”和“主机上的副本数”。
4.3 维护操作务必记住一个习惯:先进入维护模式
vSAN 集群的磁盘操作和普通虚拟机维护完全不同。你如果直接在 vSphere Client 里把某台 ESXi 主机关闭电源,vSAN 会开始重新同步数据,把该主机上承载的组件副本重建到其它主机上,这对存储网络和磁盘都会造成压力,严重时可能拖垮整个集群。规范做法是让主机进入维护模式,vCenter 会主动将该主机的虚拟机移到其它节点,并且触发 vSAN 的数据撤离。
在主机上右键-“进入维护模式”,会弹出两个关键选项:
- 确保数据可访问:vSAN 会将当前主机的对象组件重建或复制到其它主机。这是最常用的选项。
- 关闭电源后仍然保留数据:一般在只短时间维护时用,但风险是维护期间如果其它主机再出故障,集群可能没有足够冗余。
进入维护方式后,可以看到 vSAN 在后台做迁移和重新同步。等到所有对象状态正常后,再关闭主机或断开网络。我在实际操作中吃过一次亏,为了重启一台内存热插拔后的服务器,没等 vSAN 重新同步完成就直接 shutdown,结果集群状态一度显示“部分对象不可访问”。虽然最后靠 vSAN 的自愈机制恢复了,但整个过程很惊险。
4.4 排错速查表
我把一段时期内高频出现的问题整理成了速查表,遇到问题时直接对照:
| 症状 | 常见原因 | 处理思路 |
|---|---|---|
| vSAN 服务无法开启 | 许可证版本不足或 vSAN 磁盘不可用 | 添加 Enterprise Plus 与 vSAN 许可,检查磁盘分区是否清除且 SSD 标记正确 |
| vSAN 数据存储未出现在下拉列表 | 集群中没有任何主机有可用容量设备 | 到磁盘管理里确认磁盘已被声明并创建磁盘组 |
| 某主机显示“无法访问 vSAN 网络” | 未配置 vSAN VMkernel 或网络隔离 | 检查 VMkernel 适配器服务是否勾选 vSAN,并测试节点间连通性 |
| 虚拟机创建到一半报空间不足 | 策略为 FTT=1 镜像,有效容量只有一半 | 查看 vSAN 容量页签,可调整存储策略或清理临时虚拟机 |
| 主机维护后数据同步很久 | 集群数据量大且网络带宽低 | 可在 vSAN 高级设置中调整重同步限制,必要时扩容网络带宽 |
| 健康检查报时钟偏差 | 主机 NTP 未配置或未同步 | 给 ESXi 与 vCenter 配置同一 NTP 服务器源 |
5. 一点补充心得
从最初在 Workstation 里嵌套三台 ESXi 虚拟机开始摸 vSAN,到现在能够在物理机上独立完成集群部署,我最大的感受是:vSAN 的学习曲线主要卡在概念上,不在操作上。只要你理解磁盘组、缓存盘、容量盘、存储策略这几个核心概念,操作流程其实一个下午就能走完。
但概念之外,环境的严谨性更加重要。实验环境虽然随意,但它确实是训练“故障意识”的好地方。比如你有没有在部署前检查所有主机的 BIOS 电源策略一致?有没有确认磁盘的缓存模式是直通而非 RAID 卡虚拟出来的?这些在生产环境是绝对要预先确认的事情,在实验里也可以提前养成习惯。
我推荐的后续路径是:基础 vSAN 跑通后,试着破坏性验证一下,把其中一台主机的磁盘直接拔掉,或者强制下电,然后观察 vSAN 如何重新保护。再进一步,可以实践存储策略的修改,尤其是把镜像改成纠删码,体验不同冗余策略在容量和性能上的差异。最后再去碰 vSAN 的延伸功能,比如 vSAN 文件服务、vSAN iSCSI 目标、延伸集群和故障域设计,一步一步来,会发现软件定义存储的思路确实重塑了整个基础设施的操作逻辑。
