VMware Virtual SAN Vsan 设计和优化指南

VirtuaN计6.和0 设计和优化指南 irtualSlASNA设优化指南

VMware Virtual SAN 设计和优化指南

Cormac Hogan

存储与可用性业务部门 VMw are 版本 年 4 月

目录

简介

5

5

Health Services

Virtual SAN Ready Node 6 VMware EVO:RAIL 6 Virtual SAN 设计概览 7

严格遵守“兼容性指南 (VCG)” 7 硬件、驱动程序和固件 7 使用受支持的 vSphere 软件版本 7 平衡配置 8

Virtual SAN 群集的生命周期 8

根据容量、维护和可用性要求优化调整 设计概览注意事项摘要 9

混合配置和全闪存配置的区别 10 全闪存配置注意事项 10 Virtual SAN 11

所需的 ESXi 主机最少数量 11 允许的 ESXi 主机最大数量 11 允许的虚拟机最大数量 11 受 vSphere HA 保护的虚拟机最大数量 12 磁盘、磁盘组和闪存设备最大数量 12 组件最大值 13 虚拟机存储策略最大值 13 VMDK 最大大小 14 设计注意事项摘要 14

网络设计注意事项 15

网络互连 - 1Gb/10Gb 15 全闪存带宽要求 15 使用 NIC 成组实现冗余 15 MTU 和巨型帧注意事项 16 多播注意事项 16 通过 Network I/O Control 实现网络 QoS 网络设计注意事项摘要 17 Virtual SAN 网络设计指南 17

存储设计注意事项 18

磁盘组 18

缓存优化调整概览 18 Virtual SAN 中的闪存设备 18 读取缓存的用途 19 写入缓存的用途 19

PCIe 闪存设备与固态驱动器 (SSD) 的比较闪存持久性注意事项 20

使用全闪存配置时的闪存容量优化调整 使用混合配置时的闪存缓存优化调整 实际示例 - 混合配置 22

使用全闪存配置时的闪存缓存优化调整 实际示例 - 全闪存配置 23 纵向扩展容量，确保充足的缓存 24 磁盘 24

9

1619212123

磁盘性能 - NL SAS、SAS 或 SATA 25

磁盘容量 - NL-SAS、SAS 或 SATA25 磁盘性能 - RPM 26

磁盘数量在混合配置中至关重要 26 使用不同的磁盘型号/类型提供容量 26 我需要多少容量 27 我应当预留多少空间裕量 28 格式化开销注意事项 28

快照缓存优化调整注意事项 29 选择存储 I/O 控制器 29 多个控制器和 SAS 扩展器 29 多控制器与单控制器比较 30 存储控制器队列深度 30 RAID-0 与直通比较 30 存储控制器缓存注意事项 31 高级控制器功能 31 磁盘组设计 31

将磁盘组用作存储故障域 31 多磁盘组和 3 节点群集 32

磁盘驱动器容量较小时的注意事项 32 VMDK 非常大时的注意事项 32 磁盘更换/升级所需容量设计 33 磁盘更换/升级人机工程学 33 设计时要避免耗尽容量 34 存储设计注意事项摘要 34 虚拟机存储策略设计注意事项 35 对象与组件 35 见证组件与副本 36 虚拟机快照注意事项 36 从 UI 查看对象布局 37 策略设计方案 38

每对象/条带宽度的磁盘条带数 38 条带宽度 - 优化调整注意事项 38 闪存读取缓存预留 38 闪存读取缓存预留 - 优化调整注意事项 39 闪存读取缓存预留配置示例 39 允许故障数 40

允许故障数优化调整注意事项 40 强制置备 40 对象空间预留 41

策略设计注意事项摘要 43 虚拟机命名空间和交换注意事项 43 虚拟机主页命名空间 43 虚拟机交换 44

为快照创建的增量磁盘 45 快照内存 45

动态更改虚拟机存储策略 45 使用无法实施的策略进行置备 46

使用默认策略进行置备 主机设计注意事项 47 CPU 注意事项 47

46

内存注意事项 47 主机存储要求 47 引导设备注意事项 纯计算主机注意事项 维护模式注意事项 刀片系统注意事项 外部存储机箱注意事项 处理器电源管理注意事项

48 48 49 49 50 50

群集设计注意事项

3 节点配置 51 vSphere HA 注意事项 故障域 52

51

51

确定工作负载是否适合 Virtual SAN

使用 vscsiStats 对 Virtual SAN 优化调整 55 使用 View Planner 对 Virtual SAN 优化调整 VMware Infrastructure Planner - VIP 58

设计与优化调整示例 59

容量优化调整示例 I 59

CPU 配置 60 内存配置 60 存储配置 61 组件数 62

容量优化调整示例 II 62

CPU 配置 内存配置 存储配置 - 方案 1 存储配置 - 方案 2 65 组件数 67 服务器选择 68

总结 69 更多信息

70

VMware 兼容性指南 70

vSphere 社区页面 70 重要博客 70 现有文档链接 70 VMware 支持 70 延伸阅读 70

55

58

简介

VMware® Virtual SAN™ 是一个软件定义的存储平台，它聚合了虚拟化管理程序， 并与 VMware vSphere® 全面集成。Virtual SAN 将 vSphere 群集中各主机的本地 连接磁盘聚合起来，创建了一个分布式共享存储解决方案。在创建和部署虚拟机的 过程中，Virtual SAN 可在 VMware vCenter™ 中快速置备存储。Virtual SAN 是第 一个专为 vSphere 环境设计的策略驱动型存储产品，可以简化存储置备和管理工 作。使用虚拟机级别存储策略时，Virtual SAN 会自动将要求与基础存储资源加以 动态匹配。通过 Virtual SAN，许多手动执行的存储任务可以实现自动化，从而提 供一种更高效、更经济的运维模式。

Virtual SAN 提供两种不同的配置方案：混合配置（利用基于闪存的设备和磁盘） 和全闪存配置。混合配置使用基于服务器的闪存设备提供缓存层，以获得最佳性能， 同时使用磁盘提供容量和持久数据存储。如此配置可以提供企业级性能和弹性存储 平台。全闪存配置使用闪存提供缓存层和容量层。

挑选主机型号、存储控制器以及闪存设备和磁盘时有众多方案可供选择。因此，为 Virtual SAN 设计挑选硬件组件时，严格遵守“VMware 兼容性指南 (VCG)”极其 重要。

本文旨在帮助管理员正确设计 Virtual SAN 群集并优化调整，解答有关主机数量、 闪存设备数量、磁盘数量的常见问题，并回答详细配置问题，帮助您成功部署 Virtual SAN。

Health Services

Virtual SAN 附带 Health Services 插件。此功能可以检查 Virtual SAN 方方面 面的运行状况，并洞察许多潜在问题的根源。部署 Virtual SAN 时，建议同时部署 Virtual SAN Health Services。检测到问题后，Health Services 会突出显示问题， 并引导管理员参照相应的 VMware 知识库文章解决问题。

请参考《Virtual SAN Health Services 指南》，了解关于如何获得 Health Services 组件、如何安装组件以及如何使用此功能验证 Virtual SAN 部署和解决常见 Virtual SAN 问题的更多信息。

Virtual SAN Ready Node

Virtual SAN 群集有两种构建方式：

• 使用认证组件自行构建 从 Virtual SAN Ready Node 列表中选择

Virtual SAN Ready Node 是经过验证的服务器配置，其中的硬件设备均针对 Virtual SAN 部署进行了测试和认证，属于服务器 OEM 和 VMware 共同推荐的产品。 Virtual SAN Ready Node 是理想的超融合构建块，适用于寻求自动化和需要自定义 硬件与软件配置的大型数据中心环境。

Virtual SAN Ready Node 文档会提供标准化配置示例，包括支持的虚拟机数量以 及预计可提供的 4K IOPS 数量。关于 Virtual SAN Ready Node 的更多详细信息， 请访问：

VMware EVO:RAIL

客户还可以选择 VMware EVO:RAIL™。EVO:RAIL 将 VMware 计算、网络和存储 资源合并成一个超融合基础架构设备，从而打造一个由我们的合作伙伴提供的简单、 易于部署的一体化解决方案。EVO:RAIL 软件可以完全加载到合作伙伴的硬件设备 中，并附带 VMware Virtual SAN。关于 EVO:RAIL 的更多详细信息，请访问：

Virtual SAN 设计概览

在介绍 Virtual SAN 设计和优化调整的具体细节之前，我们先概要说明一些注意 事项。

严格遵守“兼容性指南 (VCG)”

严格遵守适用于 Virtual SAN 的 vSphere 兼容性指南 (VCG) 非常重要。我们对大量 支持请求进行分析后发现，相关问题归根结底是因为没有遵守这些非常具体的建议 所导致的。此在线工具定期更新，确保客户始终可以从 VMware 获得最新指导。始 终要确认用于 Virtual SAN 部署的硬件组件是否受 VMware 支持。

硬件、驱动程序和固件

VCG 针对存储 I/O 控制器、固态驱动器 (SSD)、PCIe 闪存卡和磁盘驱动器的硬件 型号提供了非常具体的建议。它还说明了哪些驱动程序已使用 Virtual SAN 进行了 充分测试，而且在许多情况下，它会说明所需的最低固件级别。确保硬件组件拥有 这些固件级别，以及确保设计中的 ESXi 主机上安装的任何相关驱动程序拥有受支 持的最新驱动程序版本。

使用受支持的 vSphere 软件版本

尽管 VMware 支持使用 vSphere 和 vSphere 的各种版本（U2 和 U1）运 行 Virtual SAN，但我们始终建议运行最新版本的 vSphere 软件（无论在 ESXi 还 是在 vCenter Server 上都是如此）。尤其是，vSphere 包括许多针对 Virtual SAN 的改进功能。

VMware 不支持将 Virtual SAN 的 BETA 版升级到 GA 版。在这种情况下，需要全新 部署 Virtual SAN，即全新部署 vSphere 、 等。如果正在使用 Virtual SAN 的 Beta 版，而且现在希望使用该产品的 GA 版，请不要尝试从 升级到 或 。

VMware 会不断修复客户遇到的问题，因此，通过使用最新版本的软件，客户能够 避免遇到已经修复的问题。

平衡配置

作为一项最佳做法，VMware 建议在所有群集成员之间，部署具有类似或相同配置 （包括类似或相同的存储配置）的 ESXi 主机。这将确保在磁盘和主机群集之间平 衡虚拟机存储组件。在同一 vSphere 群集中，尽管不贡献存储的主机依然能够利

用 Virtual SAN 数据存储，但是，如果遇到问题，则可能需要开展额外的支持工作。 因此，VMware 建议采用平衡配置。

最佳做法：为 Virtual SAN 群集使用具有类似配置和大小的 ESXi 主机。

Virtual SAN 群集的生命周期

Virtual SAN 为客户提供的存储解决方案既可通过为 ESXi 主机添加全新或更大的磁 盘轻松实现纵向扩展，也可通过向群集添加全新主机轻松实现横向扩展。这使得客 户能够在一开始时使用非常小的环境，然后随着时间的推移，通过添加新主机和更 多磁盘，轻松实现扩展。

然而，无论是使用混合解决方案还是全闪存解决方案，扩展时都需要为工作负载提 供足够的缓存及容量，这一点十分重要。本指南会深入讨论这一注意事项。具体而 言，在设计时应当考虑选择拥有附加磁盘插槽，可提供附加容量，以及便于将附加 设备安装到这些插槽中的主机。

为 Virtual SAN 选择硬件时，始终要记住，无论是混合配置还是全闪存配置，添加 容量通常都比向缓存层添加更大的闪存设备容易得多。

添加额外容量可能会非常简单，也就是在维护现有容量的同时，插入新的磁盘驱动 器或闪存容量设备。然而，更新闪存缓存层时，除非添加全新的磁盘组，否则就需 要使用新闪存设备替代以前的闪存设备。这是因为每个磁盘组只有一个闪存设备。 如果在添加额外闪存的同时添加额外容量，那么纵向扩展 Virtual SAN 十分轻松。 如果不添加新容量，只添加额外闪存缓存，就会涉及到开展较为复杂的维护任务， 并可能需要从更新、更大的闪存缓存设备要加入的目标磁盘组撤出所有数据。如果 设计 Virtual SAN 时考虑未来缓存增长需求，换句话说，初始设计包含的闪存缓存 超过实际需求，则可以避免该问题。

最佳做法：设计时考虑未来增长需求

根据容量、维护和可用性要求优化调整

Virtual SAN 所需的最低配置为 3 个 ESXi 主机。然而，这个最小的环境面临着许 多重要。在 Virtual SAN 中，如果发生故障，系统会尝试在剩余群集上重新构 建故障设备或主机的任何虚拟机组件。在 3 节点群集中，如果一个节点发生故障， 则无处可以重新构建故障组件。将主机置于维护模式时也是如此。维护模式中有一 个选项可以从主机撤出所有数据。然而，这仅在群集中有 4 个或更多节点并且有充 足的备用容量时可行。

此外还要考虑容量层大小。因为部署在 Virtual SAN 上的虚拟机由策略驱动，而且 其中一个策略设置

(NumberOfFailuresToTolerate) 将创建虚拟机数据的镜像副本， 所以需要考虑允许一个或更多故障时需要多少容量。稍后将更加详细地讨论该设计 注意事项。

设计方案：4 节点或更多节点配置可以比 3 节点配置提供更多的可用性选项。 确保有充足的存储容量满足可用性要求，并允许在故障之后重新构建组件。

设计概览注意事项摘要

• 查阅“VMware 兼容性指南 (VCG)”，确保设计中使用的所有硬件都受支持 • 查阅 VCG，确保设计中使用的所有软件、驱动程序和固件版本都受支持 • 确保在执行新部署时使用最新级别的 vSphere 修补程序/更新，并考虑将现 有部署更新到最新修补程序版本，以解决已修复的已知问题 • 设计时考虑可用性要求。设计时考虑使用三个以上主机和额外容量，使群集 在发生故障时能够自动修复 • 设计时考虑增长要求。初始部署时，考虑让群集中的容量能够满足未来虚拟 机部署要求，且具有足够的闪存缓存支持未来容量增长要求

混合配置和全闪存配置的区别

在 Virtual SAN 中，VMware 引入了对全闪存 Virtual SAN 配置的支持。全闪存 版本与混合版本之间存在一些明显区别。本节将简单介绍这些区别。

与混合配置相比，使用全闪存 Virtual SAN 配置时，无论工作负载如何，它都可以 带来更好、高度可预测的统一性能。

混合群集和全闪存群集都建议将“10% 的已占用容量”用于缓存层；然而，缓存 在每个配置中的使用方式不同。

在混合群集中（容量层使用磁盘，缓存层使用闪存），缓存算法会尝试最大限度提 高读写性能。可用缓存中有 70% 分配用于存储频繁读取的磁盘块，从而最大限度

减少对速度缓慢的磁盘的访问。可用缓存中有 30% 分配用于执行写入操作。如果 可行，系统会合并多个写操作，并按顺序写入，从而再次最大限度提高磁盘性能。

全闪存群集有两种闪存：既快速又耐用的写入缓存和容量更大、更经济高效的容量 闪存。在此配置中，100% 的缓存都分配给写入操作，因为容量闪存提供的读取性 能绰绰有余。大量写入操作保存在缓存中，仅在需要时写入容量层，从而延长容量 闪存层的寿命。

最佳做法：确保有足够的闪存缓存满足设计要求。建议将 10% 的已占用容量分配 给缓存

全闪存配置注意事项

• • • • • •

全闪存仅在 Virtual SAN 中可用 它要求使用 10Gb 网络；不支持 1Gb NIC 全闪存节点的最大数量为 个 闪存设备同时用于缓存和容量

使用全闪存配置时，不会预留闪存读取缓存

需要标记闪存设备，使其能够用于容量 – 这将在《Virtual SAN 管理员指 南》中介绍 现在，持久性成为缓存层和容量层的重要考虑事项。

•

Virtual SAN

设计 Virtual SAN 群集时，必须考虑 Virtual SAN 。

所需的 ESXi 主机最少数量

Virtual SAN 群集中至少要有 3 个 ESXi 主机。 和 版本都是如此。尽管 Virtual SAN 完全支持 3 节点配置，但它们的行为方式不同于有着 4 节点或更多节 点的配置。具体而言，发生故障时，Virtual SAN 无法在群集中的其他主机上重新 构建组件来允许另一次故障。同样，在 3 节点配置下，Virtual SAN 不能在维护期 间从节点迁移所有数据。

设计方案：4 节点群集可以提供更高的灵活性。如果可行，请考虑至少使用 4 个节 点设计群集。

允许的 ESXi 主机最大数量

对于混合配置，在版本 中，支持每 Virtual SAN 群集最多使用 个 ESXi 主机。 对于 Virtual SAN ，支持每 Virtual SAN 群集最多使用 32 个 ESXi 主机。

要运行 个节点，必须设定某些高级设置。请参考 VMware 知识库文章 2110081。

允许的虚拟机最大数量

在版本 中，Virtual SAN 最多支持每 ESXi 主机使用 200 个虚拟机，每群集最 多使用 6,400 个虚拟机。在版本 中，每 ESXi 主机最多使用 100 个虚拟机，因此 在 32 主机 Virtual SAN 群集中，最多支持 3,200 个虚拟机。当然，可用计算资源也 会实际可部署的虚拟机数量。本指南稍后讲述设计和优化调整示例时，将详细 讨论此注意事项。

设计方案：如果设计目标是部署一定数量的虚拟机，请确保群集中有足够的 ESXi 主机支持设计。

受 vSphere HA 保护的虚拟机最大数量

在 vSphere 中，vSphere HA 在同一数据存储上最多可以保护 2,048 个虚拟机。 由于 Virtual SAN 只有一个数据存储，这意味着vSphere HA 最多可以为每个 Virtual SAN 群集保护 2,048 个虚拟机。因此，在启用 vSphere HA 的 Virtual SAN 群集中， 如果虚拟机超过 2,048 个，vSphere HA 将无法保护所有这些虚拟机。此在 vSphere 中已解除，vSphere HA 现在可以保护部署在群集上的所有虚拟机， 最多可达 6,400 个。

最佳做法：在 Virtual SAN 群集上启用 vSphere HA，以提供最高级别的可用性。

磁盘、磁盘组和闪存设备最大数量

磁盘组是通过将本地连接存储设备聚合起来创建的管理构造。在混合配置中，磁盘 组是单个基于闪存的设备与多个磁盘设备的组合，前者提供缓存和性能，后者提供 容量。在混合配置上创建磁盘组要求指派单个基于闪存的设备和一个或多个磁盘。

在全闪存配置中，磁盘组是具有两种用途的闪存设备的组合。首先，单个基于闪存 的设备用于提供缓存和性能，其次，多个额外闪存设备用于提供容量。这里需要执 行一个额外步骤，也就是将用于容量层的闪存设备特别标记为容量闪存设备。在全 闪存配置上创建磁盘组时，要求指派单个基于闪存的设备用于缓存（1 级设备）， 并指派一个或多个额外闪存设备用于容量层。

注意：Virtual SAN 不支持在同一群集中混合使用全闪存磁盘组和混合磁盘组。混 合使用不同类型磁盘组会导致性能不稳定。

加入 Virtual SAN 群集的 ESXi 主机上最多有 5 个磁盘组（闪存缓存设备 + 容量设 备）。闪存缓存设备可以是 PCIe 闪存设备或固态磁盘 (SSD)。容量设备可以是混 合配置中的磁盘或全闪存配置中的闪存设备。闪存缓存设备专门用于单个磁盘组： 不能与其他磁盘组共享，也不能共享用于其他用途。

在混合配置中，每磁盘组最多有 7 个磁盘用于容量层，每磁盘组最多有 1 个闪存设 备用于缓存层。

在全闪存配置中，每磁盘组最多有 7 个闪存设备用于闪存容量层，每磁盘组最多有 1 个闪存设备用于缓存层。

根据这些最大值进行推断可知，每 ESXi 主机总共有 35 个设备用于容量层，每主 机最多有 5 个设备（PCIe 或 SSD）用于缓存层。

组件最大值

部署在 Virtual SAN 上的虚拟机由一组对象组成。例如，VMDK 是对象，快照是对 象，虚拟机交换空间是对象，虚拟机主页命名空间（.vmx 文件、日志文件等内容 的存储位置）也是对象。每个对象都由一套组件构成，这些组件由虚拟机存储策略 中的功能决定。例如，如果使用允许一次故障的策略部署虚拟机，那么对象将由两 个副本组件构成。如果策略包含条带宽度，对象将在容量层中跨多个设备进行条带 化。每个条带都是对象的一个组件。稍后，本指南将更加详细地讨论对象和组件的 概念，但总而言之，在 Virtual SAN 中，每 ESXi 主机最多有 3,000 个组件，在 Virtual SAN （采用磁盘上格式 v2）中，上限为每主机 9,000 个组件。从 升 级到 时，磁盘上格式也需要从 v1 升级到 v2，以获得最多 9,000 个组件的支持。 《Virtual SAN 管理员指南》介绍了升级过程。

虚拟机存储策略最大值

每对象的最大条带宽度为 12。默认情况下，最小条带宽度为 1。然而，如果不在策 略中设置任何条带宽度要求，Virtual SAN 可以决定对象可能需要跨多个磁盘进行 条带化。虽然具体原因会因情况而异，但通常是因为管理员请求创建的 VMDK 太 大，不适合放在单一物理驱动器上。此外，还应当注意，Virtual SAN 上的最大组 件大小为 255GB。对于超过 255GB 的对象，Virtual SAN 会自动将它们拆分为多 个组件。因此，如果管理员部署 2TB VMDK，则可能会在同一 RAID-0 条带配置中 看到 8 个或更多组件构成 VMDK 对象。

设计方案：确保容量层中有充足的物理设备满足所需的条带宽度要求。 对象可以允许的最大故障数为 3。默认情况下，系统使用 NumberOfFailuresToTolerate 为 1 的设置部署虚拟机。此策略设置决定了部署在Virtual SAN 上的对象拷贝/副本数。

要允许“n”个故障，群集中需要有“2n + 1”个主机。如果设计方案包括故障域，那 么群集中需要有“2n + 1”个故障域，才能在 Virtual SAN 群集中允许“n”个故障。

设计方案：确保群集中有充足的主机（和故障域）满足所需的

NumberOfFailuresToTolerate 要求。

另一个策略设置是 FlashReadCacheReservation，但它仅适用于混合配置。全闪 存配置上没有读取缓存。FlashReadCacheReservation 的最大值为 100%，意味着 将根据虚拟机 VMDK 大小预留匹配的缓存。与 FlashReadCacheReservation 相关 的设计注意事项将在虚拟机存储策略设计部分详细讨论。

同时适用于混合配置和全闪存配置的 ObjectSpaceReservation 的最大值为 100%， 意味着虚拟机的 VMDK 将按“厚置备”方式部署。与 ObjectSpaceReservation 相 关的设计注意事项将在虚拟机存储策略设计部分详细讨论。

VMDK 最大大小

在 Virtual SAN 中，支持的最大 VMDK 大小为 62TB。在 Virtual SAN 中， 最大 VMDK 大小为 2TB。

正如在上一部分提到的，在 Virtual SAN 中，对象大小为 255GB 时即会进行条 带化。如果管理员部署的对象为 62 TB，将创建大约 500 个组件（假设默认策略为 NumberOfFailuresToTolerate = 1）。在 Virtual SAN 上创建非常大的 VMDK 时， 需要考虑组件最大数量。

设计注意事项摘要

• 考虑在 Virtual SAN 群集上启用 vSphere HA，以提供最高级别的可用性。 在版本 中，vSphere HA 最多可以保护 6,400 个虚拟机。 • 考虑允许故障时所需的主机（和故障域）数量。 • 考虑实施条带宽度时容量层中所需的设备数量。 • 部署非常大的虚拟机时，考虑组件数量。许多客户不太可能要求每主机部署多 个 62TB VMDK。实际上，在 Virtual SAN 中，应该不需要担心组件数量。 • 请记住，默认情况下，VMDK（甚至是 62TB VMDK）最初将采用精简置备， 因此，客户应当为未来容量增长做好准备。

网络设计注意事项

网络互连 – 1Gb/10Gb

VMware 支持将 1Gb 和 10Gb 网络接口卡 (NIC) 用于混合配置下的 Virtual SAN 网 络流量。如果使用 1Gb NIC，VMware 要求将此 NIC 专门用于 Virtual SAN 流量。 如果使用 10Gb NIC，此 NIC 可以与其他类型网络流量共享。

尽管 VMware 成功在 1Gb 链路上运行了较小的混合 Virtual SAN 部署，但最佳做 法是使用 10Gb 链路。10Gb 链路不需要专门用于 Virtual SAN 流量；它们可以与 其他类型网络流量共享，例如 vMotion。如果在多个类型流量之间共享 10Gb NIC， 则建议使用 Network I/O Control 阻止一种类型流量占用所有带宽。

对于全闪存配置，由于网络流量有可能增加，VMware 建议仅将 10Gb NIC 用于 Virtual SAN 网络流量。此 NIC 依然可以与其他类型流量共享。

需要考虑 ESXi 主机之间有多少复制和通信流量（这直接关系到群集中的虚拟机数 量），每虚拟机有多少副本，以及虚拟机中运行的应用程序的 I/O 强度如何。

全闪存带宽要求

Virtual SAN 全闪存配置仅支持 10Gb 网络互连。原因之一是，全闪存配置提供的 更高性能可能会在主机之间占用更多网络带宽，以获得更高的吞吐量。此外，即便 不是为了获得更高吞吐量，部署全闪存配置也可完美实现可预测的低延迟。

• 1Gb 网络连接不支持全闪存 Virtual SAN 配置。

•

在版本 和 中，1Gb 网络连接继续支持混合配置。

使用 NIC 成组实现冗余

将接口成组聚合在一起时，Virtual SAN 网络流量不能跨多个网络接口进行负载平 衡。虽然可能会实现部分负载平衡，但 NIC 成组更应该被看作是提供一种使 Virtual SAN 流量网络“高度可用”的方式。如果一个适配器发生故障，另一个适 配器将接管通信。

MTU 和巨型帧注意事项

Virtual SAN 支持巨型帧。

VMware 测试发现，使用巨型帧可以降低 CPU 利用率，增加吞吐量，然而，这两 项优势仅处于最低水平，因为 vShpere 已经使用 TCP 分段卸载 (TSO) 和大型接收 卸载 (LRO) 带来了类似的优势。

在网络基础架构中已启用巨型帧的数据中心里，建议将巨型帧用于 Virtual SAN 部 署。否则，不建议使用巨型帧，因为在整个网络基础架构中配置巨型帧的操作成本 远远超出了有限的 CPU 和性能优势。

设计注意事项：如果增益在很大程度上可以忽略不计时，请考虑在 Virtual SAN 环 境中引入巨型帧是否值得冒操作风险。

多播注意事项

多播是 Virtual SAN 的网络要求。多播可用于发现参与群集的 ESXi 主机以及跟踪 群集中的变化。请务必确保在参与 Virtual SAN 群集的所有节点之间允许多播流量。

多播性能也非常重要，因此，应当确保使用高质量的企业级交换机。如果将低端交 换机用于 Virtual SAN，应当明确测试交换机的多播性能，因为单播性能不能反映 多播性能。

通过 Network I/O Control 实现网络 QoS

服务质量 (QoS) 可以使用 Network I/O Control (NIOC) 实施。这将允许向 Virtual SAN 流量分配专用数量的网络带宽。使用共享机制时，通过使用 NIOC，可以确保 没有其他流量影响 Virtual SAN 网络，反之亦然。

然而，NIOC 要求使用 Distributed Switch (VDS)，而且此功能在标准交换机 (VSS) 上不可用。对于面向 Virtual SAN 的每个 vSphere 版本，VMware 都会在该版本中 提供 VDS。这意味着，无论部署哪个版本，都可以配置 NIOC。然而，Virtual SAN 同时支持 VDS 和 VSS。

网络设计注意事项摘要

• •

混合配置支持 1Gb 和 10Gb 网络 全闪存配置要求使用 10Gb 网络 • 为实现可用性/冗余，请考虑使用 NIC 成组 • 考虑引入巨型帧是否值得 • 必须配置多播并且确保在所有主机之间可以使用 考虑使用具备 NIOC 的 VDS，在 Virtual SAN 流量上提供 QoS

Virtual SAN 网络设计指南

《VMware Virtual SAN 网络设计指南》介绍了设计方案、最佳做法和配置详情， 包括：

• • • • • 结果

vSphere 成组注意事项 - IP 哈希算法和其他成组算法的比较 物理拓扑注意事项 – 叶脊（Spine/Leaf）拓扑与接入/汇聚/核心拓扑在 大型 Virtual SAN 群集中的影响 面向高可用性的 Virtual SAN 网络设计 - 实现高度可用的 Virtual SAN 网络 的设计注意事项 负载平衡注意事项 - 如何通过多个物理上行链路，为 Virtual SAN 流量和 其他类型流量获得聚合带宽 Virtual SAN 与其他类型流量 - 同时使用 Virtual SAN 和其他类型流量时， 使用 Network IO Control 的详细架构示例和测试

本指南的延伸阅读部分提供了该指南的链接，强烈建议打开链接阅读该指南。

存储设计注意事项

为 Virtual SAN 正确优化存储大小之前，需要先了解一些关键的 Virtual SAN 概念。 这对 Virtual SAN 的总体存储设计很有帮助。

磁盘组

磁盘组可看作是 Virtual SAN 上的存储容器；它们包含一个闪存缓存设备和最多七 个容量设备（磁盘或在全闪存配置中用作容量层的闪存设备）。简单地讲，磁盘组 会指派一个缓存设备，为既定容量设备提供缓存。这会在一定程度上决定性能，因 为缓存容量比基于磁盘组配置。

如果所需的缓存容量比非常高，可能要求每主机使用多个闪存设备。在这种情况下， 必须创建多个磁盘组来满足要求，因为每磁盘组受仅限一个闪存设备的配置。 不过，使用多个磁盘组和小型闪存设备有很多优势。它们通常可以提供更多的 IOPS，也可以减小故障域。

缓存容量比越高，可供虚拟机提升性能的缓存就越多。但是，这会带来附加成本。 设计方案：单个大磁盘组配置或多个小磁盘组配置。

缓存优化调整概览

客户应当根据虚拟机的活动工作集，确定 Virtual SAN 中的缓存大小要求。理想情 况下，缓存大小应当足以容纳工作负载中重复使用的块。我们将其称作活动工作集。 然而，获得工作负载的活动工作集并不容易，因为典型的工作负载会随时间而变， 这会导致工作集和关联的缓存要求也会发生变化。

作为一个指导原则，VMware 建议 Virtual SAN 配置中闪存缓存至少是已占用容量 的 10%。此建议适用于混合和全闪存 Virtual SAN 配置。

Virtual SAN 中的闪存设备

在 Virtual SAN 混合配置中，闪存设备有两个用途：读取缓存和写入缓冲区。 在全闪存配置中，一个指定的闪存设备用于缓存，其他闪存设备用于容量层。 两种配置都可以显著提高运行在 Virtual SAN 上的虚拟机的性能。

读取缓存的用途

读取缓存仅适用于混合配置，它用来保存最近读取的磁盘块集合。这可以在缓存命 中时降低 I/O 读取延迟，也就是说，磁盘块可以从缓存获取，而不是从磁盘获取。

对于既定的虚拟机数据块，Virtual SAN 始终从同一副本/镜像读取。然而，当有多 个副本（以允许故障）时，Virtual SAN 可以在副本拷贝之间平均分布数据块缓存。

如果从第一个副本读取的块不在缓存中，则引用目录服务，查找块是否在群集中另 一个镜像（在另一个主机上）的缓存中。如果在那里找到块，则从那里检索数据。 如果块不在另一个主机的缓存中，则表明读取缓存未命中。在这种情况下，系统直 接从磁盘检索数据。

写入缓存的用途

混合配置和全闪存配置上的写入缓存可用作非易失性写入缓冲区。这将大大提高混 合配置和全闪存配置的性能，还能延长全闪存配置中的闪存容量设备的寿命。

向闪存写入时，Virtual SAN 可确保在群集中的其他地方写入数据副本。部署到 Virtual SAN 的所有虚拟机都有默认可用性策略设置，确保至少有一个附加虚拟机 数据副本可用。这包括确保将写入内容写入到群集的多个写入缓存中。

写入操作由客户机操作系统中运行的应用程序发起后，写入内容将复制到包含存储 对象的副本拷贝的主机上的写入缓存。

这意味着在发生主机故障时，我们还有缓存内数据副本，从而不会丢失数据；虚拟 机可以重复使用复制的缓存副本以及复制的容量数据。

PCIe 闪存设备与固态驱动器 (SSD) 的比较

决定选择 PCIe 闪存设备而放弃固态磁盘时，有许多注意事项。注意事项分为三类： 成本、性能和容量。

大部分固态磁盘使用 SATA 接口。即便在闪存速度越来越快的情况下，SSD 依然遵 循 SATA 的 6Gb/s 标准。相比之下，PCIe 或 Peripheral Component Interconnect Express 是一种用于主板扩展的物理互连。它可以为 PCIe 设备提供 16 个数据 传输通道，每个方向上的每通道速度约为 1Gb/s。这将为使用所有 16 个通道的 PCIe 设备提供大约 32Gb/s 的总带宽。

另一个有用的性能注意事项是，使用 PC Ie 缓存设备可以减少存储控制器上的负载。 人们发现，这通常会改善性能。这条反馈来自许多闪存供应商，他们使用 PCIe 闪 存设备在 Virtual SAN 上做过性能测试。

这种性能提升是有代价的。通常，PCIe 闪存设备的成本比固态磁盘更高。 写入持久性是另一个重要的注意事项；持久性越高，成本也越高。

最后是容量注意事项。尽管固态磁盘会继续变大，但查阅 VCG 了解受支持的 Virtual SAN 闪存设备可以发现，在该指南编写时，最大的 SSD 为 2,000 GB，而 最大的 PCIe 闪存设备为 4,800 GB。

优化调整大小时，确保有足够的 1 级闪存缓存与容量比（无论容量层是磁盘还是闪 存都是如此）。同样，成本也是一个重要的考虑因素。

设计注意事项：考虑工作负载是需要 PCIe 性能，还是 SSD 提供的性能已足够。 考虑设计应当采用一个大磁盘组和一个大闪存设备，还是多个磁盘组和多个小闪存 设备。后者可以减小故障域，同时也可以提高性能，但成本可能更高。

闪存持久性注意事项

随着全闪存配置在容量层中引入了闪存设备，现在重要的是针对容量闪存层和缓存 闪存层的持久性进行优化。在混合配置中，只有缓存闪存层需要考虑闪存持久性。 在 Virtual SAN 中，持久性等级已更新，使用在供应商的驱动器保修期内写入 的 TB 量 (TBW) 表示。此前，此规格为每日完整驱动器写入次数 (DWPD)。

通过引用 TBW 规格，VMware 允许供应商灵活使用完整 DWPD 规格较低但容量 更大的驱动器。

例如，从持久性角度来讲，规格为 10 次完整 DWPD 的 200GB 驱动器与规格为 5 次完整 DWPD 的 400GB 驱动器相当。如果 VMware 要求 Virtual SAN 闪存设备具 有 10 次 DWPD，则会将具有 5 次 DWPD 的 400GB 驱动器排除出 Virtual SAN 认 证范围。

例如，将规格更改为每日 2 TBW 后，200GB 驱动器和 400GB 驱驱动器都将符合 认证资格 - 每日 2 TBW 相当于 400GB 驱动器的 5 次 DWPD 以及 200GB 驱动器 的 10 次 DWPD。

对于运行高工作负载的 VSAN 全闪存配置，闪存缓存设备规格为每日 4 TBW。这相 当于 5 年内写入 7300 TB 数据。

当然，在容量层上使用的闪存设备的持久性也可以此为参考，但是，这些设备往往 不需要与用作缓存层的闪存设备具备相同级别的持久性。

使用全闪存配置时的闪存容量优化调整

混合配置中与容量层优化调整有关的所有注意事项也适用于全闪存 Virtual SAN 配 置。例如，我们需要考虑虚拟机数量、VMDK 大小、并发拍摄的快照数量，当然还 包括根据虚拟机存储策略中的 NumberOfFailuresToTolerate 要求创建的副本拷贝 数量。

采用全闪存配置时，读取请求不再由缓存层响应，而是由容量层响应。通过移除全 闪存配置中的读取缓存，缓存层上的 IOPS 数量大大减少，持久性显著增加。这意 味着，持久性和性能现在成为全闪存配置中容量层的注意事项。

然而，在全闪存配置中，使用高持久性闪存缓存设备也可以延长闪存容量层的寿命。 如果在虚拟机中运行的应用程序的工作集大多可以放入闪存写入缓存，闪存容量层 上的写入操作次数将减少。

注意：在 Virtual SAN 中，如果用于全闪存配置中缓存层的闪存设备小于 600GB，闪存设备将 100% 用于缓存。然而，如果闪存缓存设备大于 600GB， 设备中只有 600GB 用于缓存。此要求适用于每个磁盘组。

设计注意事项：对于全闪存配置，为缓存层选择设备时，请确保将闪存持久性纳入 考虑范畴。持久性数据包含在 VCG 中。

设计注意事项：调整全闪存配置中磁盘组大小时，考虑为每个磁盘组使用不大于 600GB 的闪存设备，以实现最佳优化。

使用混合配置时的闪存缓存优化调整

Virtual SAN 闪存容量优化调整的一般性建议是，闪存容量应为预计占用存储容量 的 10%，然后再考虑 NumberOfFailuresToTolerate。例如，用户计划置备 1,000 个虚拟机，每个虚拟机有 100GB 精简置备的逻辑地址空间。然而，他们预计一段 时间内，每虚拟机占用的存储容量平均为 20GB。

计量要求 预计虚拟机空间使用情况 预计虚拟机数 预计空间占用总量 目标闪存容量百分比 所需的总闪存容量

值 20GB 1,000 20GB x 1,000 = 20,000GB = 20TB 10% 20TB x .10 = 2TB 因此，复制前的预计占用存储总量为 1,000 x 20GB = 20TB。如果虚拟机的可用性 系数定义为支持 NumberOfFailuresToTolerate = 1 (FTT=1)，此配置会导致为每个 虚拟机创建两个副本，也就是说，占用容量略微超过 40TB，包括复制的数据。然 而，对于这种情况，闪存可优化调整为 10% x 20TB，即置备虚拟机所在群集中的 总闪存容量为 2TB。

目标闪存容量百分比的最佳值根据实际工作负载特征算出，例如磁盘上数据的工作 集大小。10% 是一般准则，用作进一步优化的初始基础。

VMware 建议缓存大小至少占虚拟机存储（即 VMDK）占用容量的 10%，因为对 于大多数虚拟化应用程序，任何时候都是读取或写入大约 10% 的数据。目标是尽 可能将数据（活动实时数据集）保存在缓存中，以实现最佳性能。

此外，还要考虑主机故障、闪存缓存设备故障或 Virtual SAN 群集中的主机处于维 护模式这些情况。如果希望 Virtual SAN 重新构建受故障或维护模式影响的虚拟机 组件，而且策略包含读取缓存预留设置，读取闪存缓存数量必须在故障之后可用于 重新配置虚拟机。

FlashReadCacheReservation 策略设置仅适用于混合群集。全闪存阵列没有读取 缓存。读取操作直接从闪存容量层读取数据，除非数据块已在写入缓存中。

此注意事项稍后将在本指南的“虚拟机存储策略”部分详细讨论。 实际示例 - 混合配置

客户计划在 4 节点 Virtual SAN 群集上部署 100 个虚拟机。假设每个 VMDK 为

100GB，但估计实际仅占用每个 VMDK 的 50%。 要求在这些虚拟机使用的策略中，将“NumberOfFailuresToTolerate”设为 1。

注意：尽管在策略中将“NumberOfFailuresToTolerate”设为 1 会使这些虚拟机占 用的磁盘空间量增加一倍，但它不会计入缓存大小。

因此，预计占用容量为 100 x 50GB = 5TB。

因此，缓存大小应当调整为 5TB 的 10%，即 500GB 闪存。对于 4 节点群集，这 意味着每个主机中的闪存设备大小至少为 125GB。

然而，如上文所述，应考虑在设计时使用更大的缓存配置，以便顺利应对未来的容 量增长要求。在本例中，如果 VMDK 最终占用 70% 而不是估计的 50% 空间，缓 存配置大小可能略小，性能可能受影响。

设计注意事项：设计时考虑未来增长需求。考虑购买足够大的闪存设备，允许容量 层随着时间的推移进行扩展。

使用全闪存配置时的闪存缓存优化调整

尽管全闪存 Virtual SAN 配置只为写入缓存使用闪存层，但相同的缓存优化调整设 计规则同样适用。同样，一般说来，VMware 建议缓存大小至少为虚拟机存储（即， VMDK）占用的 Virtual SAN 数据存储容量的 10%。然而，应考虑在设计时使用额 外的闪存缓存，以便顺利应对未来的容量增长要求。

实际示例 - 全闪存配置

我们还是使用前面的例子，即客户计划在 4 节点 Virtual SAN 群集上部署 100 个虚 拟机。同样，假设每个 VMDK 为 100GB，但企业估计实际仅占用每个 VMDK 的 75%。假设在这些虚拟机使用的策略中将“NumberOfFailuresToTolerate”要求设 为 2。

注意：尽管在策略中将“NumberOfFailuresToTolerate”设为 2 会使这些虚拟机占 用的容量空间增加两倍，但它不会计入缓存大小。

因此，预计占用容量为 100 x 75GB = 。

同样，缓存层优化调整为 的 10%，即至少需要 750GB 的闪存。对于 4 节 点群集来说，该群集可能需要每个主机中配置大小至少为 的闪存设备。

下表列出了持久性级别和写入 TB 量：

SSD 持久性级别 A B C D

SSD 层 全闪存 - 容量 混合- 缓存 全闪存- 缓存 （中等工作负 全闪存- 缓存 （高工作负载） 每日写入 TB 量 1 2 4 5 年写入 TB 量 365 1,825 3,650 7,300 如果供应商在其规格中使用每日完整驱动器写入次数 (DWPD)，通过执行这里显示 的转换，可以获得用写入 TB 量 (TBW) 表示的持久性。使用 Virtual SAN 时，从持 久性角度来讲，重要的是在驱动器保修期（在本例中为 5 年）内可以向 SSD 写入 多少数据。 • TBW（5 年）= 驱动器大小 x DWPD x 365 x 5。 如欲了解最新信息和准则，应当始终查阅“VMware 兼容性指南”。 最佳做法：查阅 VCG，确保闪存设备 (a) 受支持，以及 (b) 可以提供 Virtual SAN 设计要求的持久性特性。

纵向扩展容量，确保充足的缓存

Virtual SAN 引人注目的特征之一是纵向扩展和横向扩展能力。例如，对于处在自 动模式下的 Virtual SAN 群集设置，用户可以简单地向群集添加新磁盘驱动器（假 设有三个可用磁盘插槽），让 Virtual SAN 自动声明磁盘，并将其添加到磁盘组， 增加 Virtual SAN 数据存储的可用容量。

如果通过添加新磁盘组同时纵向扩展缓存和容量，则同样如此。管理员可以简单地 为缓存添加一个新的 1 级闪存设备，为容量层至少添加一个额外磁盘或闪存设备， 并构建新磁盘组。

然而，如果目的是纵向扩展 Virtual SAN 数据存储的容量（为每个服务器添加更多 容量），确保有充足的缓存非常重要。一个注意事项是，初始可配置较高的缓存容 量比，以允许容量层增长，尽管这会影响未来的闪存容量比。

通过引入新磁盘组，同时纵向扩展缓存和容量相对容易。此外，在混合配置中， 通过向磁盘组插入新磁盘来添加额外容量很容易（在全闪存配置中，则插入闪存设 备）。但是，添加额外缓存容量则困难得多。如果需要撤掉现有缓存设备并更换上 更新、更大的缓存设备，则更是如此。当然，此方法的成本也更高。相比在 Virtual SAN 投入生产之后尝试增加闪存资源，一开始就配置充裕的闪存资源则要容易得多。

设计方案：设计时使用额外的闪存缓存，可以更轻松地纵向扩展容量层。或者，通 过添加新磁盘组，同时纵向扩展缓存和容量，这比只更新现有磁盘组中的现有闪存 缓存设备更容易。

磁盘

磁盘在混合 Virtual SAN 配置中有两个作用。它们在混合配置中构成 Virtual SAN 数据存储的容量。

磁盘数量也是影响条带宽度的一个因素。在虚拟机存储策略中指定条带宽度时，构 成条带的组件将放置在单独的磁盘上。如果要求特定的条带宽度，群集中的主机上 必须有所需数量的磁盘可用，以满足此要求。如果虚拟机在策略中也规定了允许故 障要求，则要求单独的主机上含有附加磁盘，因为每个条带组件都需要复制。

Virtual SAN 设计和优化指南

在下面的截屏中，我们可以看到这样的配置。条带宽度要求为 2 (RAID 0)，允许故 障数为 1 (RAID 1)。请注意，所有组件都按照“HDD 磁盘 Uuid”列放置在唯一磁 盘上：

请注意，HDD 指的是容量设备。在混合配置中，这指的是磁盘。在全闪存配置中， 这指的是闪存设备。

磁盘性能 - NL SAS、SAS 或 SATA

在混合模式下配置 Virtual SAN 时，容量层由磁盘构成。设计时，Virtual SAN 设计 师可以选择许多方案，而且设计师需要考虑可靠性、性能、容量和价格。Virtual SAN 支持三种类型磁盘：

串行连接 SCSI (SAS) 近线串行连接 SCSI (NL-SAS) • 串行高级技术附件 (SATA)

NL-SAS 可被视为采用 SAS 接口的企业级 SATA 驱动器。使用 SAS 和 NL-SAS 可以获得最佳结果。SATA 磁盘应当只在以容量为中心且不优先考虑性能的环境里 使用。

磁盘容量 - NL-SAS、SAS 或 SATA

与 SAS 驱动器相比，SATA 驱动器可以为混合 Virtual SAN 配置提供更高的容量。 根据目前适用于 Virtual SAN 的 VCG，有 4TB SATA 驱动器可用。在该指南编写 时，SAS 驱动器的最大大小为 。当然，我们需要在容量层所需的磁盘数量与 容量层的性能之间做出取舍。如上文所述，尽管 SATA 可以提供更多的每驱动器容 量，但在注重性能的环境里，应当选择 SAS 磁盘而不是 SATA 磁盘。SATA 往往 成本较低，但无法提供 SAS 所具有的性能。SATA 驱动器通常以 7,200 RPM 或更 低的速度运行。

磁盘性能 - RPM

SAS 磁盘往往更加可靠，提供更高的性能，但成本更高。这些磁盘的速度往往高达 15K RPM（每分钟转数）。VCG 列出了受支持驱动器的 RPM（驱动器速度）。这 允许设计师在配置混合 Virtual SAN 时选择容量层所需的性能级别。尽管磁盘的驱动 程序/固件不需要检查，但必须检查磁盘为 SAS 还是 SATA，以确保它们受支持。 因为 SAS 驱动器的性能比 SATA 好得多，所以要想在混合配置中的磁盘层获得理 想性能，应当认真考虑更快的 SAS 驱动器。

缓存友好型工作负载不像缓存不友好型工作负载那样对磁盘性能十分敏感。然而， 由于应用程序性能状况可能会随着时间推移而改变，保守估计所需磁盘驱动器性能 通常是一个好做法，因为 10K RPM 驱动器是大多数工作负载组合的公认标准。

磁盘数量在混合配置中至关重要

尽管拥有充足数量的闪存缓存很重要，但拥有充足的磁盘心轴同样重要。在混合配 置中，所有虚拟机写入操作都保存到闪存，稍后，这些块会转储到旋转磁盘。拥有 多个磁盘心轴可以加快转储过程。

同样，混合 Virtual SAN 配置预计实现 90% 的读取缓存命中率。这意味着 10% 的 读取操作将未命中读取缓存，此时这些块必须从容量层的旋转磁盘检索。同样， 拥有多个磁盘心轴可以加速这些读取操作。

设计方案：磁盘数在混合配置中至关重要，因此，请明智地选择磁盘数量。在混合 配置中，采用更多、更小的磁盘通常比采用更少、更大的磁盘提供更好的性能。

使用不同的磁盘型号/类型提供容量

VMware 不建议在同一主机中以及在不同主机之间使用不同类型磁盘。这是因为， 组件性能取决于组件部署到哪种类型的磁盘，而使用不同类型磁盘有可能造成性能 不可预测。VMware 强烈建议在群集中的所有主机上使用统一的磁盘型号。

设计方案：在群集中的所有节点之间选择标准磁盘型号/类型。不要混合使用不同 的驱动器型号/类型。

我需要多少容量

确定 Virtual SAN 设计所需的容量时，必须要考虑“NumberOfFailuresToTolerate” 策略设置，这十分重要。NumberOfFailuresToTolerate 和创建的副本数量直接相 关。例如，如果在虚拟机存储策略中将 NumberOfFailuresToTolerate 设为 1，则 会在另一个主机上的容量层创建另一个 VMDK 副本（两个数据拷贝）。如果 NumberOfFailuresToTolerate 设为 2，群集中会有两个 VMDK 副本拷贝（三个数 据拷贝）。

此时，容量需要根据故障要求加以确定。然而，我们可能需要安排充足的容量， 以便在发生故障时，Virtual SAN 能够在群集中的剩余容量上创建缺失/故障组件。 此外，对群集中的主机进行线下维护时，也可能需要虚拟机具备完整可用性。

另一个基本问题是，设计方案是否应当允许 Virtual SAN 在维护过程中将组件迁移 到群集中的其他地方并重新加以保护（或者在故障期间重新构建组件）。如果主机 处于维护模式，而且不重新构建存储对象，在此期间发生的设备故障可能会造成数 据丢失，这一点需要予以高度重视。

请注意，这仅在群集中的节点数量超过 3 个时可行。如果只是 3 节点群集，Virtual SAN 不能在发生故障时重新构建组件。然而，请注意，在此情况下，Virtual SAN 将处理故障，I/O 将继续，但是需要先解决故障，Virtual SAN 才能重新构建组件并 再次得到全面保护。

如果群集包含 3 个以上的节点，而且要求在发生故障时或在维护活动期间重新构建组 件，需要为此目的预留一定数量的额外磁盘空间。用户应考虑预留一台主机以提供充 足可用的存储，因为这是在发生一次故障时需要重新构建的最大数据量。如果设计需 要允许两次故障，则需要准备额外 2 个有着充足可用存储的节点。16、32 或 节点 配置同样如此。需要多少附加容量的决定因素取决于 NumberOfFailuresToTolerate 设置。

设计方案：设计 Virtual SAN 容量时，始终要将 NumberOfFailuresToTolerate 设 置纳入考虑范畴。

设计方案：如果要求在故障之后重新构建组件，则应当调整设计大小，确保有一台 主机具有充足容量，可以允许每次故障。为了在一次故障之后或维护期间重新构建 组件，需要一个完整主机的容量可用。为了在第二次故障之后重新构建组件，需要 两个完整主机的容量可用。

我应当预留多少空间裕量

如果可以，VMware 建议在 Virtual SAN 数据存储中留 30% 的可用容量。预留空间 裕量的原因是，当磁盘达到 80% 的完整阈值时，Virtual SAN 开始自动重新平衡， 以致于在群集上生成重新构建流量。如果可以，应当避免这种情况。理想情况下， 我们希望配置比 80% 的阈值少 10%。因此，建议预留 30% 的可用容量。

当然，如果需要，客户可以预留更小的可用容量。然而，请注意，达到 80% 的阈 值时，Virtual SAN 可能会利用循环回收保持群集平衡。

最佳做法/设计建议：设计容量时预留 30% 的空间裕量。

格式化开销注意事项

Virtual SAN 数据存储容量由群集中所有 ESXi 主机的设备容量层的聚合容量确定。 在混合配置中，磁盘组包含一个基于闪存的设备、一个或多个聚合在一起的磁盘， 但只有磁盘的可使用容量计入 Virtual SAN 数据存储的总容量。对于全闪存配置， 计算 Virtual SAN 数据存储容量时，仅包含标记为容量的闪存设备。

磁盘组中的所有磁盘都使用磁盘上文件系统进行格式化。如果磁盘上格式为版本 1， 格式化共占用每磁盘 750MB 到 1GB 的容量。在 Virtual SAN 中，管理员可以 使用 v1 (VMFS-L) 或 v2 (VirstoFS)。在版本 中，磁盘上格式 v1 的格式化开销 保持不变，但磁盘上格式 v2 的开销不同，通常是驱动器容量的 1%。设计 Virtual SAN 容量要求时需要考虑这一点。下表提供了所需开销的估算值。

Virtual SAN 版本

格式类型 VMFS-L VMFS-L VirstoFS 磁盘上版本 v1 v1 v2 开销 每磁盘 750MB 每磁盘 750MB 1% 的物理磁盘容量 Virtual SAN 版本 不支持 v2 磁盘上格式。v2 格式仅在 Virtual SAN 版本 上 受支持。v2 开销非常依赖用户数据在文件系统上的碎片化程度。在实践中，我们 发现，元数据开销通常少于 1% 的物理磁盘容量。

设计方案：计算容量时包含格式化开销。

设计注意事项：除了 NumberOfFailuresToTolerate 和格式化开销以外，还需要考 虑其他注意事项。这就包括是否计划虚拟机快照。我们将在阐述一些设计示例时介 绍这些内容。一般来说，VMware 建议在群集容量中预留大约 30% 的可用空间。

快照缓存优化调整注意事项

在 Virtual SAN 版本 中，管理员如果希望使用虚拟机快照，则需要像在 VMFS 或 NFS 数据存储上使用虚拟机快照一样，考虑所有同样的。根据 VMware 知 识库文章 1025279，VMware 建议单个快照的时间不要超过 24-72 小时，而且，尽 管快照链支持 32 个快照，但 VMware 建议仅在快照链中使用 2-3 个快照。 在 Virtual SAN 和磁盘上格式 v2 中，快照机制已得到大大加强，使得虚拟机快 照的表现远超以往。Virtual SAN 完全支持每个磁盘上格式 VMDK 使用 32 个快 照。v2 上的新快照机制使用新的“vsanSparse”格式。然而，尽管这些新快照的 表现胜于以往版本，但依然需要考虑一些设计和优化调整问题。 为 VSAN 混合配置确定缓存大小时，设计必须考虑大量使用快照这一潜在使用 情形。创建多个活动快照会很快耗尽缓存资源，甚至有可能影响性能。将缓存优化 为 10% 的占用容量这一标准准则可能需要调整至 15% 或以上，尤其是在需要大量 使用快照的情形下。

对于 Virtual SAN 全闪存配置，虚拟机快照对缓存的使用并不是问题。

如果在 Virtual SAN 从版本 升级到 时，磁盘上格式未升级到 v2，而是保持 在 v1，则请使用旧的（重做日志）快照格式，并继续遵守 VMware 知识库文章 1025279 中的注意事项。

设计注意事项：如果在混合设计中大量使用虚拟机快照，请考虑将缓存容量比从 10% 增加到 15%。

选择存储 I/O 控制器

设计存储方案时，最重要的一点就是要确保选择“VMware 兼容性指南 (VCG)”中 列出的组件。请查阅 VCG，确保 VMware 支持您选择的存储 I/O 控制器以及固态 磁盘或 PCIe 闪存设备。这里列出了一些存储硬件的设计注意事项。

多个控制器和 SAS 扩展器

Virtual SAN 支持每个 ESXi 主机使用多个控制器。每个主机的最大磁盘数为 35 （每磁盘组 7 个磁盘，每主机 5 个磁盘组）。有些控制器支持 16 个端口，因此一 个控制器最多可以管理 16 个磁盘。使用最大磁盘数时，在一个主机中使用两个此 类控制器即可以近似满足要求。然而，有些控制器仅支持 8 个端口，因此，要管理 最大磁盘数，总共需要 4 或 5 个控制器。

有时，可以考虑使用 SAS 扩展器，增加可使用单个存储 I/O 控制器配置的存储设 备的数量。VMware 没有对 VSAN 与 SAS 扩展器配合使用的情形进行全面测试， 因此并不鼓励使用此方案。除了潜在的兼容性问题，使用 SAS 扩展器还可能会影 响性能并增加对故障磁盘组的影响。

多控制器与单控制器比较

使用多控制器和单控制器配置 ESXi 主机的区别在于，前者有可能允许实现更高的 性能，以及将控制器故障隔离到更小范围的磁盘组。

使用单控制器时，主机中的所有设备都在同一控制器控制之下，即使主机上部署了 多个磁盘组也是如此。因此，控制器故障会影响主机上的所有存储。

如果有多个控制器，则可以把部分设备放在一个控制器后面，把其他设备放在另 一个控制器后面。此配置不仅能在单个控制器发生故障时减小故障域，也可以提 高性能。

设计方案：在每个主机上使用多个存储 I/O 控制器可以减小故障域，同时也能提高 性能。

存储控制器队列深度

VCG 针对存储 I/O 控制器列出了两个重要项目，对此必须予以注意。第一个是 “功能”，第二个是队列深度。

队列深度十分重要，因为队列深度很小的控制器已被观察到存在问题。具体而言， 当 Virtual SAN 由于故障或进入维护模式而需要重新构建组件时，队列深度小（不 足 256）的控制器会影响虚拟机 I/O 性能。

设计方案：尽可能选择队列深度大的存储 I/O 控制器。尽管最小值为 256，但建议 在可行的情况下，选择队列深度更大的控制器。

RAID-0 与直通比较

第二个重要项是“功能”列，其中列出了 Virtual SAN 支持以何种方式将物理磁盘 呈现给 Virtual SAN。这其中有些条目涉及 RAID 0 和直通。直通意味着，此控制器 支持把磁盘直接呈现给 ESXi 主机。RAID 0 指的是，每个磁盘都必须配置为 RAID 0 卷，才能让 ESXi 主机看到它们。关于 RAID 0，这里有一些额外的事项需要注意。 例如，管理员可能不得不采取额外的手动步骤来更换故障驱动器。这些步骤包括重 新构建新 RAID 0 卷，而不能简单地将替换用的空磁盘插入主机后让 Virtual SAN 声明它。

设计方案：从操作角度来讲，提供 RAID-0 模式的存储 I/O 控制器的安装和替换通 常比直通驱动器更耗时。

存储控制器缓存注意事项

VMware 建议，如果可以，请在控制器上禁用缓存。Virtual SAN 已在存储层上缓 存数据，因此无需在控制器层上再次执行此操作。如果由于存储控制器而无法 禁用缓存，建议将缓存设为 100% 读取。

高级控制器功能

有些控制器供应商提供第三方加速功能。例如，HP 有一项叫作 Smart Path 的功能， LSI 有一项叫作 Fast Path 的功能。VMware 建议，在 Virtual SAN 环境中使用控 制器时，请禁用所有高级功能。

设计方案：选择存储 I/O 控制器时，请确认它是否位于 VCG 中，并确保禁用了缓 存和所有第三方加速功能。如果控制器同时支持 RAID 0 和直通，请考虑使用直通， 因为这种模式下更易于执行磁盘更换等维护任务。

磁盘组设计

虽然 Virtual SAN 只要求群集中的每个主机至少有一个磁盘组提供存储容量，但也 可以考虑在每个主机上使用多个磁盘组。

将磁盘组用作存储故障域 在 Virtual SAN 中，磁盘组可被视为存储故障域。如果与磁盘组关联的闪存缓存设 备或存储 I/O 控制器发生故障，将影响同一磁盘组中贡献容量的所有设备，乃至使 用该存储的所有虚拟机组件。驻留在该磁盘组中的所有组件将在群集中的其他位置 重新构建。这里假设有足够的资源可用。

组件位于其他主机或其他磁盘组或附加到不同存储 I/O 控制器的其他虚拟机不会受 到影响。

因此，如果使用包含大闪存设备和大容量的大型磁盘组，则可能意味着发生故障时， 需要重新构建相当多的数据。这种重新构建流量会影响虚拟机流量的性能。重新构 建组件的时间也是一个问题，因为拥有正在重新构建的组件的虚拟机有可能在此期 间再次遭遇故障。

使用多个较小的磁盘组时，可以提高性能，并能在存储 I/O 控制器或闪存设备发生故 障时减小故障域。这里同样需要做出权衡，即此设计方案要求使用多个闪存设备和/ 或存储 I/O 控制器，这将占用额外的磁盘插槽，产生额外费用，因此需要深思熟虑。

通常，实施多个磁盘组的成本并不高。如果比较 2 个 200GB 固态设备与 1 个 400GB 固态设备的成本，价格往往不相上下。此外，还值得考虑的是，同一主机 上两个磁盘组中的两个缓存设备可以比一个磁盘组中的一个缓存设备提供明显更高 的 IOPS。

设计方案：多个磁盘组通常意味着更高的性能和更小的故障域，但有时会带来一定 成本，并且会占用额外的磁盘插槽。

多磁盘组和 3 节点群集

多磁盘组设计相比单磁盘组设计的另一个优势与 3 节点群集有关。如果 3 节点群集 中每个主机只有一个磁盘组，当其中一个闪存缓存设备发生故障时，将无处重新构 建磁盘组中的组件。

然而，如果每个主机有多个磁盘组，而且在某个闪存缓存设备发生故障时其他磁盘 组中有充足的容量，Virtual SAN 将能够在剩余磁盘组中重新构建受影响的组件。 这是在计划部署 3 节点 Virtual SAN 群集时另一个需要注意的事项。

磁盘驱动器容量较小时的注意事项

使用小容量设备时，如果部署具有较大 VMDK 的虚拟机，VMDK 对象可能会被拆 分到多个磁盘上的多个组件，以容纳较大的 VMDK。为 VMDK 对象使用 RAID-0 配置时便会出现这种情况。然而，当 Virtual SAN 按这种方式拆分对象时，多个组 件可能驻留在同一物理磁盘上，而在策略中指定 NumberOfDiskStripesPerObject 时，这种配置是不允许的。

这不一定是问题，并且 Virtual SAN 能够很好地处理这种情况。但是，在策略中未 指定条带宽度请求时，它会造成对象为何被条带化这一问题。

VMDK 非常大时的注意事项

Virtual SAN 现在支持 62TB 的虚拟机磁盘大小。然而，应当考虑应用程序是否 真的需要这么大的 VMDK。如上文所述，Virtual SAN 上的最大组件大小为 255GB。 创建很大的 VMDK 时，对象将拆分（条带化）为多个 255GB 组件。这会导致组件 数消耗得非常快，尤其是在考虑 NumberOfFailuresToTolerate 时。 NumberOfFailuresToTolerate = 1 时，单个 62TB VMDK 在群集中大约需要 500 个组件（尽管许多组件可以驻留在相同的物理设备上）。

另一个注意事项是，尽管 Virtual SAN 在群集上的聚合空间也许能够容纳这么大 的 VMDK 对象，但具体还得取决于此空间在哪里以及能否满足虚拟机存储策略中 的要求。

例如，在拥有 200TB 可用空间的 3 节点群集中，您可能坚信，这么大的空间应该 可以容纳 NumberOfFailuresToTolerate=1 (2 x 62TB = 124TB) 的 62TB VMDK。 然而，如果主机 1 有 100TB 可用空间，主机 2 有 50TB 可用空间，且主机 3 有 50TB 可用空间，那么此 Virtual SAN 无法满足这种要求。

磁盘更换/升级所需容量设计

当闪存设备或磁盘发生故障时，Virtual SAN 将立即在群集中的其他磁盘上重新构 建这些故障磁盘的组件，目标是尽可能保持群集平衡。发生磁盘故障或闪存容量设 备故障时，组件可以在同一磁盘组中的容量设备上或在其他磁盘组上重建。

发生闪存缓存设备故障时，由于这会影响整个磁盘组，Virtual SAN 需要使用群集 中的附加容量来重新构建该磁盘组的所有组件。如果同一主机上有其他磁盘组，它 可能尝试使用这些磁盘组，但也会使用群集中其他主机上的磁盘组。同样，这么做 的目的是保持群集平衡。如果一个磁盘组发生故障，并且虚拟机占用了大量的磁盘 空间，则需要找到大量备用容量来重新构建组件，以便满足虚拟机存储策略中指定 的要求。

因为最常见的故障是主机故障，所以应当从容量角度调整主机大小。

设计方案：VMware 建议保留大约 30% 的可用容量，以避免产生不必要的重新构 建/重新平衡活动。为了在发生故障时重新构建组件，设计方案还应当至少包含一 个具有充足容量的主机。如果设计方案需要在多次故障之后重新构建组件，则需要 额外包含具有充足容量的主机。

磁盘更换/升级人机工程学

设备维护人机工程学是一个很重要的注意事项。一个注意事项是主机上的故障组件 是否容易替换。关于主机有一个简单的问题：磁盘托架是位于服务器正面，还是需 要操作员将机箱滑出机架才能检修。如果 PCIe 设备需要替换，也需考虑类似的注 意事项。

另一个注意事项与是否支持热插拔/主机交换有关。如果驱动器发生故障，Virtual SAN 可以为管理员提供点亮驱动器 LED 指示灯的功能，以方便找出故障驱动

器。将驱动器放入服务器/机架后，可以通过 UI（在版本 中包含磁盘撤出选项）

将驱动器从磁盘组移除，然后将驱动器弹出，用新驱动器替换。某些控制器，尤其 是在采用 RAID 0 模式而非直通模式时，要求在弹出原始驱动器和插入新驱动器时， 通过额外步骤发现驱动器。此操作需要尽可能无缝执行，因此，很重要的一点就是 要考虑为 Virtual SAN 设计选择的控制器能否支持即插即用操作。

设计时要避免耗尽容量

VMware 建议统一配置 Virtual SAN 群集中的主机。这样可以让组件和对象平均分 配到群集中的所有磁盘上。

然而，群集有时也可能会变得不平衡，例如，在维护模式下需要完整撤出主机，或 者部署了过多虚拟机导致 Virtual SAN 数据存储过载。

如果容量层中的任何物理设备达到了全阈值的 80%，Virtual SAN 将自动实例化重 新平衡过程，以便在群集中移动组件，确保所有磁盘组保持在 80% 阈值以下。此 过程可能要密集开展 I/O 操作，并可能会在运行重新平衡期间影响虚拟机 I/O。

最佳做法：请尝试在群集中至少保留 30% 的可用容量，以便在发生故障或需要开 展维护任务时，为组件修复提供空间。此最佳做法也可以避免产生不必要的重新平 衡活动。

存储设计注意事项摘要

• 考虑是全闪存解决方案更适合 Virtual SAN 设计，还是混合解决方案更适合。 尽管全闪存解决方案可能更昂贵，但可以提供更高的性能和低延迟 • 确保在设计中使用的闪存设备的持久性符合要求 • 请记住使用 10% 的闪存容量比，此要求同时适用于混合配置和全闪存配置 花些时间确定容量层在一段时间后会变得多大，并使用提供的公式推算闪存 缓存大小 • 考虑是 PCI-E 闪存设备还是 SSD 最适合设计方案 • 确定闪存缓存的持久性要求以及全闪存解决方案设计的闪存容量要求 • 确定适合混合解决方案设计的最佳磁盘 • 确定容量层大小时，记得将文件系统开销包含在内 • 如果可以，考虑在每个主机上使用多个存储 I/O 控制器，以便提高性能， 实现冗余。 • 考虑直通相对于 RAID-0 的优势，确保控制器支持所需模式 • 禁用控制器上的缓存，或者如果不可行，将缓存设为 100% 读取 • 禁用存储 I/O 控制器的高级功能 • 设计磁盘组时，不仅将磁盘组视作故障域，还将其视作提高性能的方式 • 考虑使用较小物理驱动器时受到的 • 考虑在 Virtual SAN 上部署很大的虚拟机磁盘时受到的 • 设计一个具有充足容量的额外主机，以便在磁盘故障时方便开展修复操作， 从而可以在提供完整虚拟机可用性的同时，容许群集中再次发生故障 • 考虑有助于轻松替换故障组件的设计 • 一般来说，目标是保留大约 30% 的可用容量

Virtual SAN 设计和优化指南

虚拟机存储策略设计注意事项 了解 Virtual SAN 中的虚拟机存储策略机制非常重要。虚拟机存储策略从可用性、 优化调整和性能角度，定义虚拟机中运行的应用程序的要求。

对象与组件

部署在 Virtual SAN 数据存储上的虚拟机由一组对象构成。它们分别是虚拟机主页 命名空间、VMDK、虚拟机交换（虚拟机开启时）以及使用快照时的增量 VMDK 和虚拟机内存快照（作为快照的一部分捕获时）：

每个对象都由一套组件构成，这些组件由虚拟机存储策略中的功能决定。例如，如 果在虚拟机存储策略中设置了 NumberOfFailuresToTolerate=1，VMDK 对象将被 镜像/复制，且每个副本至少由一个组件构成。如果在虚拟机存储策略中将 NumberOfDiskStripesPerObject 设置为大于 1，对象将跨多个磁盘进行条带化，且 每个条带都被称为对象的组件。

对于在 Virtual SAN 中创建的每个组件，元数据会占用额外的 2MB 磁盘空间。 在 Virtual SAN 中，如果在已升级到 v2 磁盘上格式的容量层上构建组件，则会 占用额外的 4MB 磁盘空间。

了解虚拟机、对象和组件之间的关系有助于了解各种 Virtual SAN 故障情形。

设计注意事项：实际上，在 Virtual SAN 上创建组件产生的元数据开销微不足道， 不需要计入总容量。

见证组件与副本

在 Virtual SAN 版本 中，只要对象配置为至少允许一次故障，见证组件便是每 个存储对象不可或缺的。它们是不包含数据，只包含元数据的组件。它们的用途是 在作出可用性决定时作为“仲裁者”，以满足允许故障数策略设置的要求。它们用 于确定群集中是否存在组件仲裁。见证组件在 Virtual SAN 数据存储上占用大约 2MB 的元数据空间。

在 Virtual SAN 中，仲裁计算方式已经改变。规则不再是“50% 以上的组件”。 相反，在 中，每个组件都有许多投票（可以是 1 票或更多票）。现在，仲裁根 据“需要 50% 以上的投票”这一规则计算。这就存在一种可能，也就是即便不使 用见证组件，组件分布方式依然能让 Virtual SAN 保证容许故障数。然而，在 中，许多对象依然有见证组件。

副本构成虚拟机存储对象。为虚拟机指定可用性功能 (NumberOfFailuresToTolerate) 时，系统会对副本进行实例化。可用性功能指定创建多少副本。它可以让虚拟机在 群集中发生主机、网络或磁盘故障时，继续使用一整套数据运行。

注意：在 Virtual SAN 中，要想让对象可以访问，它的 50% 以上的组件必须 可以访问。在 Virtual SAN 中，要想让对象可以访问，它的 50% 以上的投票 必须可以访问。

设计注意事项：实际上，在 Virtual SAN 上创建见证组件产生的开销微不足道，不 需要计入总容量。

虚拟机快照注意事项

Virtual SAN 具有全新快照格式。然而，这要求磁盘上格式为 v2。如果升级后 磁盘上格式依然为 v1，旧快照机制（基于重做日志格式）会继续用于虚拟机快照。

快照处理方式发生的另一个重大变化与为正在运行的虚拟机拍摄快照时的虚拟机内 存有关。在 Virtual SAN 中，拍摄快照时，虚拟机内存会另存为虚拟机主页命 名空间中的文件。在 Virtual SAN 中，虚拟机内存现在会实例化为它在 Virtual SAN 数据存储上的对象。

Virtual SAN 设计和优化指南

设计注意事项：如果需要使用虚拟机快照并在快照中捕获虚拟机内存，则确定

Virtual SAN 数据存储大小时，需要考虑虚拟机内存快照大小。

从 UI 查看对象布局

vSphere Web Client 提供了一种查看 Virtual SAN 上的对象布局的方式。在下图中， 使用策略设置 NumberOfFailuresToTolerate = 1 和 NumberOfDiskStripesPerObject

= 2 部署虚拟机时，会显示虚拟机主页命名空间对象和 VMDK 对象。第一个快照来 自虚拟机主页命名空间。它未实施条带宽度设置，但实施了允许故障数策略设置。 图中列出了一个 RAID 1，其中包含两个组件（副本），还列出了一个用于仲裁的见 证组件。见证组件和其他组件必须位于不同的主机上。

下一个截屏来自 VMDK – 硬盘 1。它实施了条带宽度 (RAID 0) 和允许故障数 (RAID 1) 要求。总共有 5 个组件组成此对象，其中两个组件被条带化，然后镜像 到另一个双向条带。最后，此对象还包括用于仲裁决定的见证组件。

注意：物理磁盘放置视图的位置在版本 和 之间有所不同。在 中，它位 于“管理”选项卡下。在 中，它位于“监控”选项卡下。

策略设计方案

管理员必须了解这些存储功能如何影响 Virtual SAN 中的存储容量占用。Virtual SAN 中有 5 个虚拟机存储策略要求。

每对象/条带宽度的磁盘条带数

NumberOfDiskStripesPerObject 通常称为条带宽度，它是定义每个存储对象副本 分布到的容量设备最小数量的设置。实际上，Virtual SAN 可以创建多于策略中指 定数量的条带。

如果某些虚拟机是 I/O 密集型的，而其他虚拟机不是，条带化有助于提高性能。通 过条带化，虚拟机数据可以分布到更多驱动器上，它们全都有利于提高虚拟机的总 体存储性能。在混合配置下，条带化会跨磁盘进行。在全闪存配置下，条带化会跨 构成容量层的闪存设备进行。

然而，如果 (a) 应用程序不是特别密集地执行 I/O 操作，或者 (b) 虚拟机的数据分 布到忙于为其他 I/O 密集型虚拟机服务的设备，条带化可能不会提高性能。

然而，在大多数情况下，VMware 建议将条带化保留为默认值 1，除非发现了可通 过条带化缓解的性能问题。条带宽度默认值为 1，最大值为 12。

条带宽度 - 优化调整注意事项

谈到条带宽度，有两个主要的优化调整注意事项。第一个注意事项是，各个主机和 群集上是否有充足的物理设备来容纳请求的条带宽度，尤其是当还要满足 NumberOfFailuresToTolerate 值的要求的情况下。

第二个注意事项是，为条带宽度选择的值是否要求使用大量的组件并占用主机组件 数。在任何 Virtual SAN 设计中都应考虑这两个注意事项，尽管考虑到 中的最 大组件数已增加并且采用磁盘上格式 v2，这实际上不再是主要问题。稍后，我们会 看到一些实际示例，它们将说明在设计 Virtual SAN 群集时如何考虑这些因素。

闪存读取缓存预留

我们在前面提到了确定闪存缓存大小时应遵循的 10% 规则。这些闪存缓存在混合 配置中用作读取缓存和写入缓冲区，在全闪存配置中仅用作写入缓冲区，并会在所 有虚拟机之间均匀分布。然而，通过使用虚拟机存储策略设置 FlashReadCacheReservation，可以将部分读取缓存专门用于一个或多个虚拟机。

注意：此策略设置仅适用于混合配置。由于缓存机制的变更且全闪存配置中没有读 取缓存，它不支持或不适用于全闪存配置。

对于混合配置，此设置定义应当为存储对象预留多少读取闪存容量。它被指定为虚 拟机磁盘对象逻辑大小的百分比。它只应用于专门解决已发现的读取性能问题。其 他虚拟机对象不使用此预留的闪存缓存容量。

未预留的闪存在所有对象之间平等共享，为此，VMware 建议不要更改闪存预留， 除非发现了具体的性能问题。默认值为 0%，意味着对象没有预留读取缓存，而是 与其他虚拟机共享读取缓存。最大值为 100%，意味着预留的读取缓存数量与存储 对象 (VMDK) 大小相等。

闪存读取缓存预留 - 优化调整注意事项 在虚拟机存储策略中设置读取缓存预留要求时必须十分谨慎。在用户看来很小的

FlashReadCacheReservation 值很容易就会耗尽所有 SSD 资源，尤其是采用精简 置备时（请注意，在虚拟机存储策略术语中，精简置备指的是对象空间预留）。

闪存读取缓存预留配置示例

在此混合 Virtual SAN 示例中，客户针对所有虚拟机磁盘，将虚拟机存储策略 FlashReadCacheReservation 设为 5%。请记住，在混合配置中，70% 的闪存留 给读取缓存。

通过精简置备，客户可以过量置备，拥有超过实际空间的逻辑地址空间。在本例中， 客户精简置备了两倍于物理空间的逻辑空间 (200%)。

如果计算管理员请求的 FlashReadCacheReservation 并将其与主机上的可用总闪 存读取缓存进行比较，可以发现：

o 虚拟机占用的总磁盘空间：X

可用总闪存读取缓存：（X 的 10% 的 70%）= X 的 7% o

请求的闪存读取缓存预留：（X 的 200% 的 5%）= X 的 10% o

=> X 的 10% 大于 X 的 7%

因此，如果使用精简置备过量占用存储空间，必须十分谨慎，确保不会给缓存预留 设置造成负面影响。如果缓存预留耗尽所有读取缓存，它会给性能造成负面影响。

设计注意事项：谨慎使用 FlashReadCacheReservation。错误配置或错误计算会 很容易向一些虚拟机过度分配读取缓存，而让其他虚拟机得不到足够的读取缓存。

允许故障数

NumberOfFailuresToTolerate 策略设置是一个可应用到所有虚拟机或各个 VMDK 的可用性功能。为 Virtual SAN 计划和调整存储容量大小时，此策略发挥着重要作 用。根据虚拟机的可用性要求，在虚拟机存储策略中定义的设置会导致占用四倍的 虚拟机容量。

允许“n”次故障时，系统会创建“n+1”个对象副本，并且需要“2n+1”个主机 贡献存储。NumberOfFailuresToTolerate 的默认值为 1。这意味着，如果部署虚拟 机时不选择策略，依然有一个虚拟机数据的副本拷贝。NumberOfFailuresToTolerate 的最大值为 3。

注意：仅在 VMDK 小于 16TB 时适用。如果 VMDK 大于 16TB， NumberOfFailuresToTolerate 的最大值为 1。

Virtual SAN 引入了故障域概念。它可以通过将数据的副本拷贝放在不同位置， 使 Virtual SAN 不仅允许主机故障，还允许环境故障，例如机架、交换机和电源故 障。使用故障域时，为允许“n”次故障，需要创建“n+1”个对象副本，并且需要 “2n+1”个故障域。每个故障域必须至少包含一个贡献存储的主机。稍后将更加详 细地讨论故障域。

允许故障数优化调整注意事项

例如，如果 NumberOfFailuresToTolerate 设为 1，则在群集上为虚拟机或各个 VMDK 创建两个副本镜像拷贝。如果设为 2，则创建三个镜像拷贝；如果设为 3， 则创建四个拷贝。

强制置备

强制置备策略允许 Virtual SAN 在虚拟机初始部署期间违反 NumberOfFailuresToTolerate (FTT)、NumberOfDiskStripesPerObject (SW) 和 FlashReadCacheReservation (FRCR) 策略设置。

Virtual SAN 将尝试找到符合所有要求的位置。如果找不到，它将尝试找一个更加简单 的位置，即将要求降低到 FTT=0、SW=1、FRCR=0。这意味着Virtual SAN 将尝试创 建仅具有一个镜像的对象。不过，对象依然遵守所有 ObjectSpaceReservation (OSR) 策略设置。

Virtual SAN 在为对象查找位置时，不会仅仅降低无法满足的要求。例如，如果对象 要求 FTT=2，但该要求得不到满足，那么 Virtual SAN 不会尝试 FTT=1，而是直接 尝试 FTT=0。

同样，如果要求是 FTT=1、SW=10，但 Virtual SAN 没有足够的容量设备容纳

SW=10，那么它将退回到 FTT=0、SW=1，即便策略 FTT=1、SW=1 也许能成功。

此外还有另一个注意事项。如果管理员没有充分了解强制置备的行为，强制置备会 造成容量问题。如果强制置备了若干虚拟机，但由于缺乏资源，目前只有一个对象 副本拷贝实现了实例化，那么随着添加新主机或新磁盘，使得这些资源变得可用之 后，Virtual SAN 将立即代表虚拟机占用它们。

使用此选项强制置备虚拟机的管理员需要注意，一旦附加资源在群集中变得可用， Virtual SAN 可能会立即占用这些资源，以尝试满足虚拟机的策略设置。

注意：另一个特别注意事项与在完整数据迁移模式下进入维护模式以及通过版本 中引入的数据迁移删除磁盘/磁盘组有关。如果强制置备导致对象目前不符合要 求（因为初始放置或策略重新配置无法满足策略要求），此类对象的“完整数据撤 出”实际上会产生类似于“确保可访问性”的行为，即，数据撤出将使得对象降低 可用性，面临更高的风险。这是使用强制置备时需要考虑的重要注意事项，且仅适 用于不符合要求的对象。

最佳做法：添加新资源之前，核实任何虚拟机是否因缺乏资源而不符合要求。这将 解释为什么新资源会立即被 Virtual SAN 占用。此外，执行完整数据迁移之前，核 实是否有由于强制置备而不符合要求的虚拟机。

对象空间预留

管理员应当始终了解 Virtual SAN 上的存储过度使用情况，就像需要监控传统 SAN 或 NAS 阵列上的过度使用情况一样。

默认情况下，部署在 Virtual SAN 上的虚拟机存储对象采用精简置备。 ObjectSpaceReservation (OSR) 功能指定置备虚拟机时应当预留（厚置备）的存储 对象逻辑大小的百分比。存储对象的剩余部分将保持精简置备。默认值为 0%，意 味着对象采用精简置备。最大值为 100%，意味着对象空间全部预留，可被视为完 全采用厚置备。由于默认值为 0%，部署在 Virtual SAN 上的所有虚拟机都置备为精 简磁盘，除非在策略中明确指定 ObjectSpaceReservation 要求。如果指定 ObjectSpaceReservation，则预留与该策略关联的一部分存储对象。

Virtual SAN 上没有快速置零的厚置备格式。使用时，OSR 与延迟置零厚置备格式 类似。

Virtual SAN 设计和优化指南

许多保障措施可防止过度使用容量。例如，如果群集中所需数量的主机上没有足够 的存储容量来满足副本或条带宽度策略设置，将显示以下警告信息。

“监控”>“Virtual SAN”>“物理磁盘”视图将显示群集中的已使用容量。该 截屏来自 配置。 上的视图与此类似。

设计注意事项：尽管计算 Virtual SAN 数据存储容量时要考虑副本创建情况，但在 Virtual SAN 上置备虚拟机时，精简置备过度使用应计入优化调整计算中。

策略设计注意事项摘要

•

应考虑所有策略设置，也就是考虑此类策略所产生的组件数量。

• StripeWidth 也许能（也可能不能）改善混合配置的性能；它对全闪存配置 的影响很小。 FlashReadCacheReservation 应当谨慎使用，而且仅在已确定具体性能问 题时使用。

NumberOfFailuresToTolerate 需要考虑随着该策略设置的增加，有多少附加 容量将被占用。 配置 NumberOfFailuresToTolerate 时，需要考虑贡献存储的主机的数量， 而如果使用故障域，还要考虑包含贡献存储的主机的故障域的数量。 • ForceProvisioning 将允许部署不符合要求的虚拟机，但是在附加资源/容量 变得可用时，这些虚拟机将占用它们，变得符合要求。

• •

采用强制置备的虚拟机会影响维护模式执行完整数据迁移的方式，即使用 “确保可访问性”而非“完整数据迁移”。 所有使用策略部署在 Virtual SAN 上的虚拟机将采用精简置备。这可能使得 管理员需要监控过度使用情况。

虚拟机命名空间和交换注意事项

虚拟机在 Virtual SAN 上部署为对象。部署虚拟机时，Virtual SAN 会创建虚拟机命 名空间（虚拟机主页）对象。打开虚拟机电源时，虚拟机交换对象也会实例化，同 时虚拟机电源保持打开。虚拟机主页命名空间和虚拟机交换都不从虚拟机存储策略 继承所有设置。它们都有对 Virtual SAN 群集优化调整意义重大的特殊策略设置。

虚拟机主页命名空间

Virtual SAN 上的虚拟机主页命名空间是 256GB 精简置备对象。每个虚拟机都有自 己的虚拟机主页命名空间。如果将某些策略设置分配给虚拟机主页命名空间，例如 ObjectSpaceReservation 和 FlashReadCacheReservation，可能会不必要地浪费 许多存储容量和闪存资源。虚拟机主页命名空间不会从这些设置中受益。为此，虚 拟机主页命名空间会覆盖用户提供的虚拟机存储策略的某些功能。

每对象磁盘条带数：1 闪存读取缓存预留：0% 允许故障数：（继承自策略） 强制置备：（继承自策略） 对象空间预留：0%（精简）

Virtual SAN 设计和优化指南

虚拟机主页命名空间具有以下特性。

RAID 1 是可用性功能。虚拟机主页对象有一个镜像副本，它由两个副本组件构成， 表示虚拟机采用

NumberOfFailuresToTolerate = 1 部署。虚拟机主页会继承此策略 设置。组件分别位于不同主机上。发生（例如）网络分区后，在 Virtual SAN 群集 中作出可用性决定时，见证组件用作“仲裁者”。见证组件与副本驻留在完全不同 的主机上。这就是为何 Virtual SAN 至少需要三个带有本地存储的主机的原因。

虚拟机主页命名空间会继承策略设置 NumberOfFailuresToTolerate。这意味着， 如果创建包含

NumberOfFailuresToTolerate = 2 策略设置的策略，虚拟机主页命名 空间对象将使用此策略设置。它将忽略大部分其他策略设置，并用其默认值覆盖这 些设置。

虚拟机交换

虚拟机交换对象也有自己的默认策略，也就是允许一次故障。它具有默认条带宽度 值，采用精简置备，并且没有读取缓存预留。

然而，交换不驻留在虚拟机主页命名空间里；它是一个的对象，因此，不会像 虚拟机主页命名空间受 255GB 精简对象那样受到。

虚拟机交换对象不会继承虚拟机存储策略中的任何设置。它始终使用以下设置：

• • • • •

每对象磁盘条带数：1（即，无条带化） 闪存读取缓存预留：0% 允许故障数：1 强制置备：启用

对象空间预留：100%（厚置备）

请注意，查看虚拟机存储策略时，虚拟机交换对象在 UI 中不可见。用户需要使用

Ruby vSphere Console (RVC) 命令显示此对象的策略和容量信息。 为快照创建的增量磁盘 增量磁盘是在拍摄 VMDK 对象快照时创建的，它与基础磁盘 VMDK 继承相同的策 略设置。

请注意，查看虚拟机存储策略时，增量磁盘在 UI 中也不可见。然而，VMDK 基础 磁盘可见，因此用户可以根据基础 VMDK 磁盘策略推断快照增量磁盘的策略设置。 这也是正确设计和优化 Virtual SAN 部署时需要考虑的重要注意事项。

快照内存 在 Virtual SAN 中，包含内存快照的虚拟机快照会在虚拟机主页命名空间中存 储内存映像。由于虚拟机主页命名空间大小受限 (255GB)，它意味着同时捕获内存 的虚拟机快照只能在内存小得足以保存在虚拟机主页命名空间时拍摄。

在 中，内存快照在 Virtual SAN 数据存储上实例化为的对象，不再受大小 。然而，如果计划拍摄包含内存的快照，这是一个重要的优化调整注意事项。

稍后，我们将详细了解一些容量优化调整示例，并充分考虑此处讨论的注意事项。

动态更改虚拟机存储策略 对于 Virtual SAN 管理员来说，了解 Virtual SAN 如何动态更改虚拟机存储策略非 常重要，尤其是在确定大小时。管理员需要明白，动态更改策略可能会导致 Virtual SAN 数据存储上占用的空间量临时增加。

当管理员更改虚拟机存储策略，然后将策略更改应用到虚拟机进行更改时，Virtual SAN 将尝试为采用新配置的副本寻找新位置。如果 Virtual SAN 找不到新位置，重 新配置将失败。在某些情况下，当前配置的现有部分可以重复使用，配置只需更新 或扩展。例如，如果对象目前使用 NumberOfFailuresToTolerate=1，而用户要求 使用

NumberOfFailuresToTolerate =2，那么如果有附加主机可用，Virtual SAN 只 需添加另一个镜像（和见证）。

在其他情况下，例如将 StripeWidth 从 1 更改为 2，Virtual SAN 不能重复使用现有 副本，并在不影响现有对象的情况下，创建全新副本。这意味着，应用此策略更改 将增加虚拟机占用的空间量，尽管是临时的，而且占用的空间量由在策略中指定的 要求决定。完成重新配置后，Virtual SAN 随后将丢弃旧副本。

使用无法实施的策略进行置备

另一个关于虚拟机存储策略要求的注意事项是，即使 Virtual SAN 中看似有足够的 空间，但虚拟机也不会使用某些策略设置进行置备。

尽管明显需要一定数量的心轴来满足条带宽度要求，而且所需的心轴数量会在 NumberOfFailuresToTolerate 要求添加到策略时增加，但 Virtual SAN 也不会整合 现有配置，以容纳新部署的虚拟机。

例如，Virtual SAN 不会在主机或磁盘组中移动组件以允许置备新副本，即使这可 能会释放足够的空间，允许置备新虚拟机。因此，即使群集中有足够的总可用空间， 但大部分可用空间可能在一个节点上，其余节点上没有足够的空间来满足 NumberOfFailuresToTolerate 复制副本。

采用统一存储和闪存配置的平衡群集可以明显缓解此问题。

使用默认策略进行置备

在 Virtual SAN 中，应当始终使用虚拟机存储策略。不选择策略将无法精简置 备虚拟机磁盘。相反，它将使用默认策略，实施虚拟机置备向导的默认 VMDK 置 备格式，即 Lazy-Zero-Thick（延迟置零厚置备）。Virtual SAN 的默认虚拟机 存储策略可避免此情形。

最佳做法：在 Virtual SAN 中，总是使用策略部署虚拟机。如果可以，请不要 使用默认策略。

主机设计注意事项 下面列出了为恰当设计 Virtual SAN 群集，需要在配置设计中考虑的问题和注意事项。

CPU 注意事项 - 所需的每主机插槽数 - 所需的每插槽内核数 - 所需的虚拟机数以及所需的虚拟机 CPU (vCPU) 数 - 所需的 vCPU 与内核比 为 Virtual SAN 提供 10% 的 CPU 开销 内存注意事项 - 所需的虚拟机内存 - 为获得完整的 Virtual SAN 功能，每 ESXi 主机至少需要 32GB（5 个磁盘组， 每磁盘组 7 个磁盘）

主机存储要求

- - - - -

虚拟机数量、关联的 VMDK、每个虚拟机的大小以及需要为虚拟机存储提供 多少容量。 每个虚拟机占用的内存，因为开启虚拟机时，会在 Virtual SAN 数据存储上创 建交换对象 每虚拟机的快照数以及维持时间 每个快照的预计空间占用量 主机中存储设备的物理空间

所需的 NumberOfFailuresToTolerate 设置，因为这会直接影响虚拟机磁盘所 需的空间量

引导设备注意事项

- Virtual SAN 支持为 ESXi 引导设备使用 USB 和 SD 设备，但不支持 SATADOM - Virtual SAN 引入了 SATADOM 作为受支持的 ESXi 引导设备 - 当这些设备用于引导设备时，日志和跟踪驻留在 RAM 磁盘上，而且在重新 引导期间不会保存下来 o 当这些设备用作引导设备时，考虑将日志和跟踪重定向到持久存储

VMware 不建议在 VSAN 存储上存储日志和跟踪。如果 Virtual SAN 出现影响 VSAN 数据存储访问的问题，这些日志可能无o

法检索。这 将妨碍故障排除工作。 o VMware 知识库文章 1033696 详细介绍了如何将暂存空间重定向到 持久数据存储。 o 要将 Virtual SAN 跟踪重定向到持久数据存储，可以使用 esxcli vsan trace set 命令。请参考 vSphere 命令行文档，了解更多信息。

纯计算主机注意事项

下面的示例将提供一些背景信息，介绍 VMware 为何建议在群集中使用统一配置的 主机，而不使用纯计算节点。

假设有一个六节点群集，群集中每个 ESXi 主机运行 100 个虚拟机，每个虚拟机总 共占用 2,000 个组件。在 Virtual SAN 中，主机可以产生的组件为 3,000

个。如果群集中的所有主机都均等地占用组件，为了让上例中的 100 个虚拟机运行，

所有主机总共占用大约 2,000 个组件。这不会造成任何问题。

现在，假设在同一六节点 Virtual SAN 群集中，仅三个主机拥有贡献 Virtual SAN 数据存储的磁盘，其他三个为纯计算主机。假设 Virtual SAN 实现了完美平衡，每 个贡献存储的主机现在需要产生 4,000 个组件，才能让此类配置运行。这在 Virtual SAN 中无法实现，因此，向不是所有主机都贡献存储的 Virtual SAN 群集部署 虚拟机时，请务必谨慎。

尽管在 Virtual SAN 中，每主机的组件数已增加到 9,000 个， 但使用纯计算主机会导致配置不平衡，以及无法置备 Virtual SAN 支持的最大数量 的虚拟机。

最佳做法：为 Virtual SAN 部署使用统一配置的主机。尽管纯计算主机可以存在于 Virtual SAN 环境中，并占用来自群集中其他主机的存储，但 VMware 不建议采用 不平衡的群集配置。

维护模式注意事项

在 Virtual SAN 群集上执行修复操作时，需要不时将 ESXi 主机切换到维护模式。 维护模式可以为管理员提供各种各样的选项，其中一个是完整数据迁移。采用此方 法时，需要考虑以下几点：

考虑群集中需要多少主机才能满足 NumberOfFailuresToTolerate 策略要求 2. 考虑在一个主机进入维护模式时，其余主机上剩下的容量设备数量能否处理条 带宽度策略要求 3. 考虑其余主机上是否有足够的容量，用于处理必须从已切换到维护模式的主机 迁移的数据量 4. 考虑其余主机上是否有足够的闪存缓存容量，用于处理混合配置中的任何闪存 读取缓存预留

如果进入维护模式后，没有足够的资源执行完整数据迁移，通常会显示以下消息 “Failed to enter maintenance mode in the current Virtual SAN data migration

mode due to insufficient nodes or disks in the operation in another mode or after adding more resources to the cluster.”（由于群集中的节点或磁盘 不足，在当前的 Virtual SAN 数据迁移模式下，没有进入维护模式。在另一个模式 下或者向群集添加更多资源后，重新尝试操作。）

刀片系统注意事项

尽管 Virtual SAN 能够完美运行并且完全支持刀片系统，但刀片配置存在一个固有 的问题，因为它们无法从本地存储容量角度进行扩展，原因很简单，即主机中没有 足够的磁盘插槽。然而，通过在 Virtual SAN 中引入对外部存储机箱的支持， 现在刀片系统能够扩展本地存储容量，而且成为了非常有趣的 Virtual SAN 部署解 决方案。

外部存储机箱注意事项

VMware 在 Virtual SAN 中支持有限的外部存储机箱配置。这会令那些希望使 用刀片系统，但受限于主机上的可用磁盘插槽数量的客户感兴趣。顺便说一下，受 磁盘插槽数的机架安装主机也是如此。

同样，如果计划将外部存储机箱与 Virtual SAN 配合使用，请确保按照 VCG 的要 求使用相应版本的设备。

处理器电源管理注意事项

尽管处理器电源管理设置与 Virtual SAN 没有具体的关系，但它会影响总体性能。 启用处理器电源管理功能时，某些对处理速度延迟非常敏感的应用程序的性能可能 会低于预期。最佳做法是选择“平衡”模式，避免极端的省电模式。详细信息请参 阅 VMware 知识库文章 1018206。

群集设计注意事项

此部分将讨论群集特定设计注意事项。

3 节点配置

尽管 Virtual SAN 完全支持 3 节点配置，但这些配置的表现不同于 4 节点或更多节 点的配置。具体而言，发生故障时，群集中的其他主机上没有资源可用来重新构建 组件，因此不能允许另一次故障。同样，在 3 节点配置中，无法在维护期间从节点 迁移所有数据。 在 3 节点配置中，有 2 个数据副本和 1 个见证组件，它们必须分别驻留在不同的 主机上。3 节点配置只能允许 1 次故障。这意味着，如果节点发生故障，Virtual SAN 无法重新构建组件，也不能置备新虚拟机来允许故障。发生故障后，它不能 重新保护虚拟机对象，直到故障组件恢复为止。请注意，在 3 节点群集中，维护模 式不能从需要维护的服务器执行完整数据迁移。 设计方案：考虑在 Virtual SAN 群集中包含 4 个或更多节点，以实现最大可用性

vSphere HA 注意事项

Virtual SAN 与 vSphere HA 结合使用时可为虚拟机工作负载提供高可用性解决方 案。如果发生故障的主机不运行任何虚拟机计算，则不会影响虚拟机工作负载。如 果发生故障的主机运行虚拟机计算，vSphere HA 将在群集中的其余主机上重新启 动这些虚拟机。

针对存在网络分区的情况，vSphere HA 已得到扩展，可以理解 Virtual SAN 对象。 这意味着，如果虚拟机之前在一个因网络分区而无法访问虚拟机组件的分区上运行， vSphere HA 会在一个依然能够访问虚拟机组件仲裁的分区上重新启动虚拟机。

Virtual SAN 与 vSphere HA 进行互操作需要满足许多要求。

vSphere HA 必须使用 Virtual SAN 网络进行通信 2. vSphere HA 不使用 Virtual SAN 数据存储作为“数据存储信号检测”位置 在群集上配置 Virtual SAN 之前，需要禁用 vSphere HA；vSphere HA 只能 在配置 Virtual SAN 之后启用。

Virtual SAN 的一个主要优化调整注意事项是与 vSphere HA 的互操作性。vSphere HA 的现有用户知道，NumberOfFailuresToTolerate 设置将在群集中的所有主机上 预留一定数量的 CPU 和内存资源，以便在发生主机故障时，群集中的其余主机上 有充足的可用资源供虚拟机重新启动。

管理员应当注意，Virtual SAN 不与 vSphere HA 进行互操作，以确保群集中其余 主机上有充足的可用磁盘空间。但是，主机发生故障一段时间后（默认 65 分钟）， Virtual SAN 将尝试使用群集中剩余主机和存储设备上的所有剩余空间，使虚拟机 符合要求。这可能需要创建附加副本和条带。对于采用 vSphere HA 的 Virtual SAN 设计，必须提前做好周密的规划，因为 Virtual SAN 群集中若发生多次故障， 可能会由于资源过度使用而填满 Virtual SAN 上的所有可用空间。

最佳做法：在 Virtual SAN 上启用 HA，以实现最高级别的可用性。然而，任何设 计都需要包含附加容量，用于重新构建组件。

故障域

使用故障域的理念是，我们希望能够允许几组主机（机箱或机架）发生故障，而不 需要使用附加数据副本。这种实施允许 Virtual SAN 在其他域（例如，不同的计算 机架）中保存虚拟机数据的副本拷贝。

在 Virtual SAN 中，部署 NumberOfFailuresToTolerate = 1 的虚拟机时，需要 2n + 1 个主机（其中 n = NumberOfFailuresToTolerate）。这意味着，要允许 1 次 故障，需要 3 个 ESXi 主机。要允许 2 次故障，则需要 5 个主机，而如果虚拟机允

许 3 次（最大值）故障，则需要 7 个主机。

NumberOfFailuresToTolerate 所需的主机数量 1 3 2 5 3 7

Virtual SAN 设计和优化指南

在下面的示例中，Virtual SAN 群集中有 8 个主机，分布在 4 个机架之间。假设每 个机架中有 2 个 ESXi 主机。部署允许 1 次故障的虚拟机时，可以在同一机架中的 不同主机上部署两个副本。

未启用故障域时，Virtual SAN 上的情况也是如此。然而，如果启用故障域，则 允许将主机聚合在一起，形成故障域。这意味着不在同一故障域内放置两个虚拟机 数据拷贝/副本。要计算允许故障所需的故障域的数量，请使用之前使用的等式； 在带有故障域的群集上部署 NumberOfFailuresToTolerate = 1 的虚拟机，需要 2n + 1 个故障域（包含 1 或更多贡献存储的主机）。

NumberOfFailuresToTolerate 所需故障域的数量 1 3 2 5 3 7

我们还是考虑上面的示例，但现在配置了 4 个故障域。

•

• • • 故障域 1 包含主机 1 和 2（机架 1） 故障域 2 包含主机 3 和 4（机架 2） 故障域 3 包含主机 5 和 6（机架 3） 故障域 4 包含主机 7 和 8（机架 4）

Virtual SAN 设计和优化指南

部署允许 1 次故障的虚拟机时，副本放置在不同的故障域中，以致于不会在同一机

架中部署两个副本。见证组件也部署在它自己的故障域中，表示至少需要 3 个故障 域来支持

NumberOfFailuresToTolerate = 1。NumberOfFailuresToTolerate 过去 适用于“磁盘、NIC、主机”，但在此情形下，它现在也适用于故障域（机架、电 源、架顶式网络交换机）。在此情形下，NumberOfFailuresToTolerate = 1 现在可 以允许一次主机故障或一次机架故障。

故障域的重要注意事项之一是使用统一配置的主机，因为域不平衡可能意味着， Virtual SAN 在一个容量较小的域中占用大部分空间，而在一个容量较大的域中闲 置空间。

我们之前讨论过需要针对 1 次主机故障进行规划，即需要使用具有额外空间的主机 来重新构建故障或缺失组件。发生故障域故障时，需要使用 1 个具有额外空间的额 外故障域来重新构建缺失组件。这也适用于计算主机。在这种情形下，需要使用 1 个 具有额外 CPU/内存的故障域，因为故障域故障需要避免资源匮乏。

设计方案：设计很大的 Virtual SAN 群集时，考虑利用故障域来避免影响属于单个 虚拟机的所有副本的单机架故障。此外，发生故障时，还要考虑重新构建组件所需 的附加资源和容量要求。

确定工作负载是否适合 Virtual SAN

一般情况下，大多数工作负载都适合在大小适当的 Virtual SAN 配置上使用，但也 有极少数例外。

对于混合配置，应当考虑应用程序如何与缓存交互。许多应用程序在大多数情况下 都是缓存友好型的，因此，使用 Virtual SAN 将体验到出色的性能。

但不是所有应用程序始终都是缓存友好型的。例如，完整数据库扫描、大型数据库 负载、大型内容存储库、备份和还原以及类似的工作负载配置文件。

在混合配置中，这些工作负载的性能在很大程度上取决于缓存背后的磁盘子系统： 有多少磁盘可用，它们有多快，以及它们在支持多少其他应用程序工作负载。

相比之下，全闪存配置始终都可提供低延迟、可预测的高性能，而不受工作负载 配置文件的影响。在这些配置中，缓存用于延长用作容量的闪存的寿命，同时增 强性能。

Virtual SAN Ready Node 文档会提供标准化配置示例，包括支持的虚拟机数量以 及预计可提供的 4K IOPS 数量。

对于那些希望了解更进一步信息的客户，VMware 可以提供若干工具，帮助确定 Virtual SAN 是否能够满足性能要求。

使用 vscsiStats 对 Virtual SAN 优化调整

对于细粒度虚拟机工作负载的详细信息，VMware 提供一款名为 vscsiStats 的工具， 用于确定虚拟机磁盘 I/O 工作负载特性。只需在 ESXi 命令行键入 vscsiStats 即可 开始。此命令会显示帮助/使用信息。首先可以使用 -s（启动）、-x（停止）和 -l （列出虚拟机及其磁盘）这些有用选项。我们首先显示虚拟机和 VMDK。

~ # vscsiStats -l

Virtual Machine worldGroupID:76634, Virtual Machine Display Name: win- 1, Virtual Machine Config File:/vmfs/volumes/vsan:5295b3cf23da4f38 - 33b970fc769c2c69/14a8cc51-f8f5-59fc-3584-1cc1de253de4/, { Virtual SCSI Disk handleID:8192 (scsi0:0) }

Virtual Machine worldGroupID:81265, Virtual Machine Display Name: win- 2, Virtual Machine Config File:/vmfs/volumes/vsan:5295b3cf23da4f38 - 33b970fc769c2c69/5fadcc51-e023-18a6-b53d-1cc1de2522/, { Virtual SCSI Disk handleID:8193 (scsi0:0) }

Virtual SAN 设计和优化指南

在本例中，有两个虚拟机在 ESXi 主机上运行，每个虚拟机有一个 VMDK。这里所 需的信息是 worldGroupID 与 Virtual SCSI Disk handleID。这是启动数据收集所必 需的。

下一个命令会启动数据收集。

~ # vscsiStats -s -w 76634 -i 8192

vscsiStats:Starting Vscsi stats collection for worldGroup 76634, handleID 8192 (scsi0:0) Success.

收集统计信息后，现在可以确定要显示的直方图类型。直方图类型可为以下一种： “all、ioLength、seekDistance、outstandingIOs、latency、interarrival”。

第一个直方图基于“ioLength”。命令如下所示（-c 表示输出用逗号隔开）：

~ # vscsiStats -p ioLength -c -w 76634 -i 8192

此命令将为虚拟机发起的命令、读取操作和写入操作显示一个用逗号隔开的 I/O 长 度列表。此输出可以轻松导入电子表格，用于创建图形。

这种特别输出在针对空闲 Windows 虚拟机运行 vscsiStats 后捕获。在观察期间， 可以观察到有许多写入操作发生，大部分为 4KB 写入操作。

下一个直方图显示同一虚拟机和磁盘上的 I/O 延迟。

~ # vscsiStats -p latency -c -w 76634 -i 8192

Virtual SAN 设计和优化指南

同样，此信息可以导入电子表格，而且可以显示此虚拟机磁盘的延迟值图表。此外， 大部分延迟值在 5000 微秒（或 5 毫秒）左右。

完成时，请记得使用 -x 停止收集统计信息。

~ # vscsiStats -x -w 76634 -i 8192

vscsiStats:Stopping all Vscsi stats collection for worldGroup 76634, handleID 8192 (scsi0:0) Success. ~ #

使用 View Planner 对 Virtual SAN 优化调整

如果 VMware View™ 是正在 Virtual SAN 上部署的应用程序，那么 VMware 提供 的 View Planner 工具可以帮助完成规划、设计和优化调整等工作。成功部署 VMware View 取决于能否透彻了解桌面用户活动对系统、网络和存储的影响。为 了更加精确地配置部署和优化调整，跨各种计算任务模拟典型的用户工作负载至关 重要。使用 VMware View Planner，您可以系统地模拟工作负载，优化调整和配置 参数，以便呈现工作负载的影响，从而更加成功地开展部署。VMware View Planner 可以提高顾问工作效率，加快 View 相关客户项目的服务交付。

View Planner 通过运行 Windows 桌面环境中经常使用的应用程序，模拟各种用户 类型（任务、知识和高级用户）的应用程序工作负载。在工作负载执行期间，系统 会随机调用应用程序，执行常见桌面用户操作，包括打开、保存、关闭、最小化和 最大化窗口；查看 HTML 页面、插入文本、插入词语和数字、演示幻灯片、观看 视频、收发电子邮件以及压缩文件。View Planner 使用专有的水印技术在用户客户 端/远程计算机上量化用户体验，并测量应用程序延迟。

View Planner Quality of Service (QoS) 方法将用户操作分为两个主组。

组 A CPU 密集型交互/快速运行操作，例如浏览 PDF 文件、修改 Word 文档等。 组 B 组 C IO 密集型长时间运行的缓慢操作，例如打开大文档、保存 PowerPoint 文件等。 后台工作负载。它不是直接方法的一部分，但作为后台负载发挥着重要 作用。

VMware Infrastructure Planner - VIP

VMware Infrastructure Planner 在虚拟环境里收集数据，显示特定资源摘要，并可 在部署 vCloud Suite 和其他软件定义数据中心 (SDDC) 产品时保存这些摘要。

这些报告按易于理解的类别分类，例如计算、存储和网络连接，并且由更加详细的 报告提供支持。VMware Infrastructure Planner 还会概要估算部署 vCloud Suite 带 来的经济效益。

设计与优化调整示例

这些示例说明前面讨论的设计和优化调整原则。

容量优化调整示例 I

在下面的示例中，客户希望在混合 Virtual SAN 群集中部署 100 个虚拟机。每个虚 拟机需要 2 个 vCPU、8GB 内存和一个 100GB VMDK。此部署位于混合配置中， 运行 Virtual SAN 和磁盘上格式 v2。 此客户希望实现 5:1 的 vCPU 与内核整合率。 估计客户机操作系统和应用程序将占用 50% 的存储。然而，相关要求是具有足够 的存储，允许虚拟机最终占用 100% 的存储。

唯一的虚拟机存储策略设置是将 NumberOfFailuresToTolerate 设为 1。所有其他 策略设置均保留默认值。主机将从 SD 卡引导。

请注意，我们未纳入组件元数据或见证占用的容量。这两项均可忽略不计。 考虑到上述注意事项，有效配置的计算方式如下所示： • 主机要求：Virtual SAN 至少需要 3 个主机 • CPU 总体要求：200 个 vCPU • vCPU 与内核比率：5:1 • 总体 CPU 内核要求：需要 200 / 5 = 40 个内核 • 每插槽多少个内核12 • 总体内存要求：

= 100 x 8GB o

= 800GB o

• 总体存储要求（无 FTT）：* o = 100 x 100GB o = 10TB • 总体存储要求（有 FTT）：* o = 10TB *2 o = 20TB • 总体存储要求（有 FTT）+ 虚拟机交换（有 FTT）：* o = (10TB + 800GB) *2 o = *2 o =

由于 VSAN 数据存储上的所有虚拟机均采用精简置备，估计存储占用应考虑精简 置备因素，然后才能计算闪存要求：

• o o o • • • o • • •

用于缓存计算的估计存储占用（无 FTT）： （未考虑 FTT 之前的总存储的 50%） = 10TB 的 50% = 5TB

所需缓存（估计存储占用的 10%）：500GB

估计快照存储占用：0（目的是让此示例不要那么复杂） 总体存储要求（虚拟机 + 快照）：

所需的空间裕量：30% 总体存储要求 + 空间裕量： o = + o = 估计磁盘上格式开销 (1%)：280GB**

* 这里不考虑精简置备/虚拟机存储占用。

** 磁盘上格式开销计算基于容量层的总体存储要求，因此，可能与基于最终容量层 大小的计算略有不同。

CPU 配置

在本例中，客户总共需要 40 个内核。如果我们取 10% 的 Virtual SAN 开销，这会 让内核总数增加到 44 个。客户采购了包含每插槽 12 个内核的服务器，双插槽系 统可提供 24 个内核。这样，3 节点群集有 72 个内核。

这远远超出了 3 个服务器须具有 44 个内核的要求。此外，如果一个主机发生故障， 此配置还可以满足我们的虚拟机要求，而且所有虚拟机需要在剩余的两个主机上运 行，同时不给它们的 CPU 性能造成任何影响。

内存配置

三个服务器中的每一个都需要包含至少 300GB 的内存，以满足运行要求。同样， 如果一个主机发生故障，我们希望可以在剩余的两个主机上运行所有 100 个虚拟机， 因此，我们应该考虑每服务器使用 500GB 内存。

从内存角度来讲，这也可以为 ESXi 和 Virtual SAN 提供 10% 的开销。Virtual SAN 设计师需要确保服务器有足够的 DIMM 插槽来满足内存要求。

存储配置

对于此配置，总共需要 3 个主机上具有 的磁盘和 500GB 的闪存。为留出 30% 的空间裕量，群集的实际容量必须为 。

除此之外，还要包括 v2 Virtual SAN 数据存储的格式化开销。这大约为 1%，相当 于 280GB。现在，所需的容量为 。

由于我们已经考虑了“允许故障数”，每个主机都需要配置为包含大约 的磁 盘和大约 200GB 的闪存。我们提倡遵守 Virtual SAN 最佳做法，即使用统一配置 的主机。

下一个注意事项是预留一些空间，用来在发生故障时重新构建虚拟机对象和组件。 由于群集中只有 3 个主机，没有足够的主机用来重新构建组件。对于大型配置来说， 必然要考虑此注意事项，因为重新构建组件会创建附加副本，而且同样能让群集允 许主机故障。但是，在其中 1 个节点已发生故障的 3 节点群集中，我们无法允许另 一次故障。如果我们希望满足这一要求，则需要向群集添加一个具备匹配容量的附 加主机。

这时，在如何配置主机方面还有一些回旋余地；设计方案包括是否需要一个或更多 磁盘组；每磁盘组有多少磁盘；等等。此外，还应考虑使用 SAS、SATA 还是 NL- SAS 磁盘，选择 PCIe 闪存设备还是固态驱动器。如上文所述，选择 SAS 和 SATA 时需要在性能与价格之间做出权衡。选择 PCIe 闪存设备与 SSD 时也是如此。

针对此类要求，下面给出了一个建议配置： • 需要 磁盘 => 每主机 11 个 900GB SAS 10K RPM • 需要 200GB 闪存 => 每主机 2 个 100GB SAS SSD

我们为什么选择 2 个 100GB 闪存设备，而不选择 1 个 200GB 闪存设备呢原因 是我们在每个磁盘组中最多只能有 7 个容量设备。在此配置中，我们的容量设备已 超过 7 个，因此我们需要 2 个磁盘组。每个磁盘组必须包含一个闪存设备，因此我 们选择两个较小的设备。

由于主机从 SD 卡引导，我们不需要为 ESXi 引导映像提供附加磁盘。采用这种 配置时，每主机一个磁盘组就已足够。

组件数

接下来，请在 Virtual SAN 中，检查此配置的组件计数是否超出了每主机最多 3,000 个组件的，或者在 Virtual SAN （磁盘上格式 v2）中，检查是否超出 了每主机最多 9,000 个组件的。此 3 节点 Virtual SAN 群集支持运行 100 个虚 拟机，每个虚拟机包含一个 VMDK。此部署中没有快照要求。

这意味着每个虚拟机都有以下对象：

• 1 x 虚拟机主页命名空间

1 x VMDK

• 1 x 虚拟机交换 • 0 x 增量快照

这表示每个虚拟机有 3 个对象。考虑到我们正在使用包含允许主机故障数 = 1 (FTT) 的虚拟机存储策略设置，我们现在需要计算每对象需要多少个组件。应当注意的是， 只有虚拟机主页命名空间和 VMDK 会继承 FTT 设置；虚拟机交换对象会忽略此设 置，但依然使用 FTT=1。因此，当我们在每个虚拟机上查看每对象组件数时，我们 会获得下列信息：

• 2 x 虚拟机主页命名空间 + 1 个见证 • 2 x VMDK + 1 个见证 • 2 x 虚拟机交换 + 1 个见证 • 0 x 增量快照

现在，每个虚拟机共有 9 个组件。如果我们计划部署 100 个虚拟机，那么我们最 多有 900 个组件。这远低于每主机 3,000 个组件（Virtual SAN ）和每主机 9,000 个组件（Virtual SAN ）的。

容量优化调整示例 II

现在，我们来看看更大、更复杂的配置。在下面的示例中，客户希望在混合 Virtual SAN 群集中部署 400 个虚拟机。每个虚拟机都要求 1 个 vCPU、12GB 内存和 2 个磁盘、1 个 100GB VMDK 引导磁盘和 1 个 200GB VMDK 数据磁盘。此部署位 于混合配置中，运行 Virtual SAN 和磁盘上格式 v2。 在此情况下，客户希望实现 4:1 的 vCPU 与内核整合比率。 估计客户机操作系统和应用程序将占用 75% 的存储。虚拟机存储策略设置

HostFailuresToTolerate (FTT) 设为 1，而 StripeWidth 设为 2。所有其他策略设置

均保留默认值。ESXi 主机将从磁盘引导。

请注意，我们未纳入组件元数据或见证占用的容量。这两项均可忽略不计。 考虑到上述注意事项，有效配置的计算方式如下所示： • 主机要求：Virtual SAN 至少需要 3 个主机，也可能需要更多 • CPU 总体要求：400 个 vCPU • vCPU 与内核比率：4:1 • 总体 CPU 内核要求：需要 400 / 4 = 100 个内核 • 每插槽多少个内核12 • 总体内存要求：400 x 12GB = • 总体存储要求（无 FTT）：*

(400 x 100GB) + (400 x 200GB) o

40TB + 80TB o

= 120TB o

• 总体存储要求（有 FTT）：* o = 120TB x 2 o = 240TB • 总体存储要求（有 FTT）+ 虚拟机交换（有 FTT）：* o = (120TB + *2 o = 240TB + o = • 用于缓存优化调整的估计存储占用（无 FTT）： o （存储总量的 75%） o = 120TB 的 75% o = 90TB • 所需缓存（估计存储占用的 10%）：9TB • 估计快照存储占用：每虚拟机 2 个快照 o 估计两个快照映像绝不超过基础 VMDK 的 5% o 存储要求（有 FTT）= 240TB o 不要求拍摄快照时捕获虚拟机内存 o 估计快照要求（有 FTT）= 5% = 12TB • 总体存储要求（虚拟机 + 快照）： o = + 12TB o = • 所需的空间裕量：30% • 总体存储要求 + 空间裕量： o = + o = 340TB • 估计磁盘上格式开销 (1%)： **

* 这里不考虑精简置备/虚拟机存储占用。

** 磁盘上格式开销计算基于容量层的总体存储大小，因此，可能与基于最终容量层 大小的计算略有不同。

CPU 配置

在本例中，客户总共需要 100 个内核。如果我们取 10% 的 Virtual SAN 开销，这 会让内核总数增加到 110 个。客户采购了包含每插槽 12 个内核的服务器，双插槽 系统可提供 24 个内核。这样，5 节点群集有 120 个内核。这超过了我们要求 的 110 个内核。然而，此配置并不能满足我们的虚拟机要求，因为只要有一个主机 发生故障，所有虚拟机就只能在剩余的四个主机上运行，很难不给它们的 CPU 性 能造成影响。因此，客户可能判定 6 节点群集更适合此配置。但是，这在很大程度 上取决于此节点数量能否满足设计中的大存储容量要求。

内存配置

六个服务器中的每一个都需要包含至少 800GB 的内存，以满足 虚拟机内存 运行要求。同样，如果一个主机发生故障，我们可能希望在剩余的 5 个主机上运行 所有 400 个虚拟机，因此，我们应该考虑每服务器使用 1TB 内存。从内存角度来 讲，这也可以为 ESXi 和 Virtual SAN 提供 10% 的开销。设计师将需要确保服务器 有足够的 DIMM 插槽来满足此内存要求。

存储配置 - 方案 1

本例中需要使用大量磁盘。为留出 30% 的空间裕量，群集的实际容量必须为 。对于 6 节点群集，要求 6 个主机上共有 的容量。这包括满足 允许故障数、快照和磁盘上格式开销要求所需的容量。此外，还需要 6 个主机上共 有 9TB 的闪存。由于我们已经考虑了“允许故障数”，每个主机都需要配置为包 含大约 60TB 的磁盘和大约 的闪存。 并且，我们需要做出设计选择 - 使用 SAS、SATA 还是 NL-SAS 磁盘。然而，如 果对磁盘层的性能有要求，SATA 可能不是合适之选。另一个设计方案是应当选择 的大小。最后，需要选择能够容纳满足容量要求所需的磁盘数的服务器。

对于闪存设备，需要做出类似的选择，即选择 PCIe 设备还是固态设备。同样，如 果已选择使用 SSD 的方案，则必须确定每主机所需的 SSD 数量。此外，还需根据 做出的选择，计算出容纳 SSD 和磁盘所需的磁盘插槽的适当数量。

如果需要多个磁盘组，设计将需要确保每磁盘组的磁盘数量不会超出，或者每 主机的磁盘组数量不会超出。请参考本文前面有关的小节，了解最大数量 实际值。

针对此类要求，下面给出了一个建议配置： • 整个群集需要 磁盘，这意味着每主机大约需要 60TB 磁盘（群集 中有 6 个主机） o 一种方案是考虑每主机使用 15 个 4TB SATA 7,200 RPM（尽 管容量略低，但它应该能满足我们的需求）。这可能是最经济 的方案，但性能可能无法接受 o 使用 15 个磁盘时可能需要购买附加控制器或 SAS 扩展器。多个 控制器将提供卓越性能，但成本较高 o 另一个设计注意事项是使用外部存储机箱容纳如此多的磁盘。 版本 中引入了对外部存储机箱的支持 o 由于每磁盘组只有 7 个磁盘，所以至少需要 3 个磁盘组 • 每群集需要 9TB 缓存，意味着每主机需要 缓存

需要 3 个闪存设备，上述每磁盘组 1 个 o

每主机使用 3 个 500GB SSD 意味着每主机现在需要 16 个磁盘插槽 o

为了应对未来增长，请考虑使用更大的闪存设备 o

• ESXi 主机从磁盘引导

现在每主机需要 17 个磁盘插槽 o

在本例中，客户现在需要为这个很大的配置购买包含 17 个磁盘插槽的服务器。然 而，这个设计是可以使用 6 节点群集实现的。不过，如果客户现在要求在发生故障 时重新构建组件，则需要另外向配置中添加一个完全插满磁盘的服务器。这会使所 需的主机数量增加到 7 个。

存储配置 - 方案 2

在方案 1 中，此 Virtual SAN 设计的容量要求可以通过每主机使用 15 个 4TB SATA 7,200 RPM 来满足。然而，这些驱动器可能无法实现最终解决方案所需的性能。

同样，还要针对磁盘类型做出选择。如上所述，Virtual SAN 支持的磁盘类型包括 SAS、SATA 或 NL-SAS。

考虑到需要性能更高的容量层，下面针对此类要求推荐一种配置： • 群集中总共需要 的磁盘 o 一种方案是考虑使用 SAS 10K RPM。它们可以为设计提供 可以接受的性能水平 o 这意味着整个群集总共需要 286 个 SAS 10K RPM 驱动器。

现在，这是最为重要的设计注意事项。我们需要考虑满足此存储要 求需要多少个主机 o 每磁盘组最多 7 个磁盘，每主机最多 5 个磁盘组，也就是每主机 可提供 35 x 存储。这相当于每主机 42TB o 满足此要求至少需要 9 个主机。当然，现在需要重新考虑和重新计 算 CPU 和内存要求。这意味着群集设计也可使用功能不太强大的 主机 o 这么多磁盘可能要求购买附加控制器或 SAS 扩展器。多个控制器 将提供卓越性能，但成本较高 o 另一种设计方案是使用外部存储机箱来容纳如此多的磁盘。版本 中引入了对外部存储机箱的支持 • 每群集需要 9TB 缓存 o 考虑到群集中现在有 9 个主机，群集中分布的每主机将有 1TB 闪存 o 由于每主机中有 5 个磁盘组，将 200GB 闪存设备（总共 5 个）用 于每个磁盘组可以轻松满足要求 o 为了应对未来增长，我们可以考虑使用更大的闪存设备，如下所示 o 由于每主机使用 5 个 200GB SSD，现在每主机总共需要 40 个磁 盘插槽 • ESXi 主机从磁盘引导 o 现在需要每主机 41 个磁盘插槽

现在，此设计需要将包含 41 个磁盘插槽的服务器用于这个相当大的配置。为满足 这种设计要求，此设计现在要考虑选择附加控制器、SAS 扩展器或外部存储机箱。 在 中，引入了对外部存储机箱的支持。替代方案是购买更多的服务器，将存储 分布到这些服务器上。然而，这可能要求重新设计方案。

同样，如果客户现在要求在发生故障时重新构建组件，则需要另外向配置中添加一 个完全插满磁盘的服务器。这会使所需的主机数量增加到 10 个。

组件数

最后，请在 Virtual SAN 中，检查此配置的组件计数是否超出了每主机最多 3,000 个组件的，或者在 Virtual SAN 中，检查是否超出了每主机最多 9,000 个组件的。 此 Virtual SAN 群集要求运行 400 个虚拟机，每个虚拟机包含一个 VMDK。在此部 署中，还要求每虚拟机有 2 个快照。

这意味着每个虚拟机都有以下对象：

• 1 x 虚拟机主页命名空间

2 x VMDK

• 1 x 虚拟机交换 • 2 x 增量快照

这表示每个虚拟机有 6 个对象。考虑到我们正在使用包含允许主机故障数 = 1 (FTT) 和条带宽度 = 2 的虚拟机存储策略设置，我们现在需要计算每对象有多少个组件。

应当注意的是，只有虚拟机主页命名空间、VMDK 和增量快照会继承 FTT 设置； 虚拟机交换对象忽略此设置。只有 VMDK 和增量快照会继承虚拟机存储策略

接下来，检查每对象的组件数：

• 每虚拟机主页命名空间 2 个组件（仅 FTT）+ 1 个见证 = 3 • 每 VMDK 4 个组件（FTT 和条带宽度）+ 3 个见证

o 每 VMDK 7 个组件 x 2 = 14

• 每虚拟机交换 2 个组件 + 1 个见证 = 3 • 每增量快照 4 个组件（FTT 和条带宽度）+ 3 个见证

o 每增量快照 7 个组件 x 2 = 14

据此推断，每个虚拟机共有 3 + 14 + 3 + 14 = 34 个组件。如果将这应用于 400 个 虚拟机，则共有 13,600 个组件。

以方案 1 这一最小的配置为例，将这些组件分布到 Virtual SAN 群集中的 7 个主机 上，则通过计算可知，每主机有 1,943 个组件。这远低于每主机 3,000 个组件（在 中）和每主机 9,000 个组件（在 中）的。

接下来，检查群集在发生主机故障时，是否依然能够处理相同数量的组件。将 12,800 个组件分布到 6 个主机上，意味着每主机共有 2,267 个组件，因此，我们 可以发现，此设计能够允许主机故障，并能在群集中剩余的 6 个主机上重新构建缺 失的组件。

包含 9 个或 10 个主机的方案 2 就更不用说了，它能够更好地处理这么多的组件。 服务器选择 对于方案 (1)，客户选择的服务器是 HP DL380p，为此需要核实它是否确实能配置 最多 25 个磁盘插槽。如果不可以，客户可能必须考虑购买更多服务器来满足存储

要求，而且必须重新计算。此外，此主机也能满足每插槽 12 内核的要求，并且有 24 个 DIMM 插槽来满足内存要求。

对于方案 (2)，如果找不到可支持 41 个插槽的主机（这是有可能的），客户可能需 要考虑使用外部存储机箱。替代方案是考虑购买更多服务器来满足存储要求，但此 时也必须重新计算。如果客户已选择服务器，例如 HP DL380p，需要使用此处讨 论的公式开始新一轮的计算。

总结

尽管大多数 Virtual SAN 设计和优化调整实践都很简单，但一开始就认真规划， 可以避免后续出现问题。

根据截至目前为止我们积累的经验，最常见的设计问题有：

- -

不使用 VCG 中列出的组件、驱动程序和固件，导致不可预测的行为。 闪存设备和 IO 控制器特别敏感。 没有针对容量增长情况确定适当的缓存大小（例如，精简卷逐渐变大）， 导致性能随着时间的推移而下降。 将 1Gb 网络用于性能密集型环境，因此，不出所料，性能很糟糕。 不了解 3 节点模式与维护模式和故障后保护有关的。

使用很大、很慢的磁盘提供容量，而一旦应用程序对缓存不友好，则会导 致性能下降。 没有准备充足的额外容量支持各项操作，例如进入维护模式、更改策略定 义等等。

-

-

- -