Live Optics | Optical Prime | VMware 来宾虚拟机性能

本文档中的概念不仅对正确的收集和容量调整很重要，对于理解成本的重要性也至关重要，因为它与公有云和私有云的比较有关。本文档的结尾处将更详细地讨论这些概念。

虚拟机管理程序性能

虚拟机管理程序性能是“实时”收集的，因此命名为 Live Optics。它会在从您开始收集的那一刻起到所选持续时间结束的期间捕获性能指标。

这意味着 Live Optics 会轮询 vCenter 并实时创建遥测文件。

虚拟机性能

来宾虚拟机性能数据是可选的，但默认情况下处于启用状态。

VMware 通过归档遥测文件提供对各个虚拟机数据的访问。

环境中的来宾虚拟机性能遥测文件是不一致的。VMware 管理员可以按指标配置归档，以将遥测数据保留几分钟、几小时或更长时间。因此，虽然 Live Optics 可以拉取这些数据，但数据可能因指标或环境而异。

在当前形式下，Optical Prime 会获取 IOPS、内存、CPU 等的归档指标，并创建数据点，如“峰值 IOPS”。这些计算的指标将发布到门户的 Excel 输出中的虚拟机详细信息。

虚拟机性能遥测检索确实会给收集带来更大的负担。根据环境的不同，每个虚拟机的检索可能耗时 1 秒到 5 秒。

这会在收集环境中产生很少的开销，但需要耗费时间，Optical Prime 必须确保在可执行文件的运行时间中补偿此时间。

我们可以进行一个简单的计算，假设每个虚拟机 5 秒的最坏情况，50,000 个虚拟机至少需要大约 3 天的等待期来检索所有这些数据。

因此，来宾虚拟机性能数据的收集绑定到 Optical Prime 例行的性能收集，并且收集器禁止为所有虚拟机遥测文件选择低于估计检索时间的记录持续时间。

在上述情况下，记录性能的最短收集持续时间至少为 3 天。

了解性能数据

当您希望了解环境的性能时，您应该使用虚拟机管理程序的性能数据。

根据所采用的方法，使用 Excel 工作表中的来宾虚拟机性能数据可能会导致严重高估性能需求。

为了理解这一点，我将深入探讨一下这一切是如何运作的。

Live Optics 最初的名称是“DPACK”，当它进入市场时，它解决了业内的一个根本性误解。

由于正确执行这些任务的复杂性，这一误解持续了多年。这是一个大数据问题，需要软件才能正确完成，而 Live Optics 已在业界将其商品化。

这种容易出错的方法在业内被称为“峰值相加”，并且有明确的证据表明这是一种具有误导性的项目规模调整方法。让我通过一个虚构的简化场景来进行解释。

示例 1：

服务器 A 的峰值 IOPS 为 500，服务器 B 的峰值 IOPS 为 500，符合逻辑的假设是您需要 1,000 IOPS 才能支持两台服务器。

此方法称为“峰值相加”。它是由于聚合一段“时间”内的“数据”的复杂性而得出的。

Windows 有 Perfmon 数据，Linux 有 IOSTAT，过去人们通过 ESXTOP 获取来自 VMware 环境的性能数据。

社区发现很难正确关联不同格式的文件，因此唯一的选择是猜测需求或将峰值相加。

示例 2：

现在，让我们重复这个练习，但提供更多数据点。服务器 A 的峰值出现在下午 3 点，服务器 B 的峰值出现在下午 4 点。

Live Optics 收集器会同时向其记录数据的所有端点启动数据收集。它还以专有格式执行此操作，以便所有数据点可以完美地对齐，以形成“聚合的”性能视图。

对于此基本示例，我们假设这是这些服务器在一天中产生的唯一活动。由于服务器 A 和服务器 B 的活动不会同时发生，我们可以清楚地看到，我们根本不需要 1,000 IOPS。我们只需要 500 IOPS。

这种方法称为“时间对齐聚合”，是 Live Optics 首创的方法，随后在业界实现了商品化。

示例 3：

显然，世界上没有哪种服务器只运行一会儿，然后在一天的剩余时间里处于休眠状态。让我们展开此图，看看它是如何大规模运作的。

“峰值相加”用红线/虚线表示。
“时间对齐聚合”用绿色/实线表示。

根据定义，服务器的 IOPS 性能是一个“每秒”指标：每秒的 I/O 量。IOPS 在一天之中是波动的，因为服务器会在“思考”和“执行”周期之间切换。

这意味着示例 2 的简化场景每天出现数千次，因此参与的服务器越多，两种方法之间的差异就越大。

换言之，参与的服务器越多，“峰值相加”方法就越不准确。

在下图中可以看到，如果将所有这些虚拟机的峰值活动相加，会导致接近 40% 的过度补偿，而实际需求仅为 605。

当所有服务器在任何给定时间都在运行时，它们从未超过 605 IOPS。  

示例 4：

由于我们可以假设任何场景来说明一个观点，因此让我们来看一个真实项目。

此项目包含 344 个正在运行的虚拟机。如果导出此项目的 Excel 输出，我将获得每个虚拟机的所有峰值 IOPS 指标。

Excel 对 IOPS 值进行 SUM() 运算，结果是 4,454 IOPS。

或者，我们可以使用时间对齐聚合方法，创建整个数据集的第 95 百分位，并计算所有虚拟机的混合性能。

得到的结果截然不同，计算结果仅为 1,219 IOPS，比峰值相加方法的值低 73%。 

结果

这对于确定项目规模至关重要，并且您应了解 IOPS、内存、CPU、吞吐量和网络流量也会产生相同的影响。

但是，这不会影响容量大小调整。容量不是在一段时间内衡量的指标，也不会波动到足以对项目需求产生任何实际影响。

如果要对任何共享资源环境（如超融合、VSAN，甚至共享外部存储阵列）进行合理的规模调整，这些都是必须考虑的基本数据。

可以看到，这大大降低了项目要求的入口点，但通过使用 Live Optics 门户中功能强大的软件来简化此任务，效果要好得多。

Live Optics 会为您计算所有这些值，并且由于这些值是从支持工作负载的硬件中提取出来的，因此您可以在“假设”场景下创建混合平台和作系统的有效模拟。

为什么有效

关于应该使用什么指标来调整规模，存在着很大的哲学争论。思想流派分为：来自虚拟机、来自虚拟机管理程序或来自存储阵列。

在此分析中，我们将对此进行分解。

对于后台，Live Optics 根据前端 IOPS 进行标准化。“前端”是指源自应用程序或操作系统的 IOPS。前端 IOPS 是平台和供应商中立的，而后端 IOPS 则特定于技术和供应商。

一个简单的示例：如果服务器具有 15 个前端写入 IOPS，并且数据写入 RAID 10 中，则每个前端 IO 有 2 个后端 IOPS，因此后端 IOPS 为 30。

每个硬件供应商和每个存储管理员都可以将这些前端 IOPS 定向到任意数量的技术，以提供某种程度的保护或速度。

对于可能在“后台”发生的其他活动（如复制或快照），也是如此。每个供应商都以或多或少的效率实现不同的技术，并且它们不需要进行比较，或者更常见的情况是，它们根本无法进行比较。

在更换技术或更换供应商时，这些特定于供应商或产品的实现无法与新技术的方法相比较，但有一点是一致的，那就是前端 IOPS（以及前端容量）。

因此，前端 IO 是应使用的性能标准。

定义了前端 IO 后，我们来看看这一切是如何运作的。

虚拟机层

如果您使用 Live Optics 记录每个虚拟机的性能，它将考虑其一段时间内的所有 IO 性能，并将它们汇总到最终的时间对齐性能统计中。

虽然这在技术上可行，但这意味着 Live Optics 收集器可能要以数千台虚拟机为目标。这不仅是一项枯燥的任务，而且 Live Optics 收集器和 Portal Viewer 也不是为这种量级而设计的，并最终会导致糟糕的体验。

通常仅在 VMware 环境中没有管理 ESXi 节点的 vCenter 时才采用此方法。这些例外情况几乎总是很小的，并且此方法可以成功实现。

物理服务器/虚拟机管理程序层

除非在虚拟机管理程序上运行虚拟机，否则它们没有有意义的活动。这意味着，如果您记录了托管所有虚拟机的虚拟机管理程序，这是所有虚拟机性能的“汇总”。从性能角度来看，您将获得与定位和记录每个虚拟机基本相同的结果，但您可以通过添加单个 vCenter 地址来获得该结果。

这种方法要容易得多，并且也更受欢迎。

提醒：建议不要同时以虚拟机和托管虚拟机的服务器为目标。由于虚拟机管理程序是所有虚拟机的汇总，因此直接以某个虚拟机为目标并将其包含在虚拟机管理程序项目中将使该虚拟机影响的性能和容量值翻倍。

由于虚拟机管理程序方法可以获得所有性能，但性能将显示在一个汇总的图表中，因此通过遥测文件检索收集的来宾虚拟机性能数据点对于确定工作集中性能最高的虚拟机非常有用。

在单独的活动和单独的项目中，可以直接使用 Live Optics 收集器将这些顶级虚拟机作为目标，以获得所选虚拟机及其可能正在运行的应用程序的深层扫描视图。

提醒：Live Optics 收集器了解 VSAN 配置中的虚拟机管理程序与传统外部存储支持方案中的虚拟机管理程序之间的差异。当遇到 VSAN 支持的情景时，收集器将动态切换 API，以仅关注前端容量和 IOPS。这会将实际工作负载与 VSAN 提供程序生成的开销隔离开来。

存储层

前两个层次现在已经很明显了，但最后一层引入了一种近乎宗教的争论。但是，它相对简单直接。与虚拟机与其虚拟机管理程序之间的关系一样，除非服务器启动任务，否则存储阵列也不会产生工作负载。

假设有五台服务器与存储阵列通信，它们通过最终与存储控制器通信的构造进行通信。

这创造了一种门控活动，就像高速公路上的汽车必须通过收费站一样。这 5 台服务器中的每一台都向存储阵列发送下行 IO 活动，我们会看到，由于控制器是聚合点，对存储前端 IOPS 产生了类似的影响。

这意味着 Live Optics 方法可以安全地模拟和预测存储阵列的前端 IOPS，而无需与存储阵列本身进行通信。

前端服务器 IOPS = 前端存储 IOPS

如果您想隔离 IO 和容量，然后重新计算项目，您可以使用 Live Optics 查看器选择加入或取消内部服务器驱动器。这可用于针对特定存储提供商并获取更精确的详细信息。 

迁移到 HCI 时调整项目规模

调整虚拟机迁移规模时，Live Optics 建议您从至少支持虚拟机 24 小时的虚拟机管理程序获取性能要求。

4 小时的性能是了解一段时间内性能的任何实际影响的最低要求。

24 小时会显示备份周期的影响，或者是否不存在备份周期。

迁移存储设备时调整项目规模

如果您的服务器保持不变，并且项目仅升级存储阵列，则也可以从主机获取性能，并且建议您也使用 24 小时性能窗口。

在这种场景中，您可能有物理 Windows、Linux、VMware 和其他操作系统。出于这个原因，Live Optics 支持在单个收集中的异构混合操作系统。

“对公有云的影响”对话

有一组令人信服的证据证明本文档中的概念是真实的，因为它们与针对共享资源运行的工作负载的净收益有关。

如果不是这样，CI、HCI、VSAN 甚至虚拟化存储阵列等技术就不会有效，而且根本不会存在。

因此，虽然我们必须适当地调整项目规模，但不建议单独考虑工作负载本身。

巧合的是，这确实有利于公有云考量。虚拟机的每个实例在公有云中根据其 CPU 使用量、内存使用量、容量和性能独立计费。

这样做的最终结果是，当将性能较低的虚拟机迁移到公有云时，迁移到高度虚拟化环境的成本效益可能会被抹去，因为本文档中介绍的净聚合收益将不尽如人意。

如有任何问题，请通过 liveoptics.support@dell.com 联系 Live Optics 支持。