最近，来自VMware CTO办公室的一篇博客文章讨论了"DRS成对平衡"，据称这是vSphere 6.5及更高版本中DRS的改进版本该博客宣称，"随着集群规模越来越大，云服务器促销，这一新功能是必不可少的。"结果发现，旧的dr使用的一些统计指标在较大的集群中变成了"统计异常值"，根据VMware的说法，"由于大量主机的利用率低得多，它们只是作为噪音消失了"，因此"下降到"以下触发负载平衡所需的阈值。"换言之，旧的DRS无法扩展。输入新的DRS:DRS成对平衡。"通过添加成对平衡的功能，以及"简单地"比较报告的最高利用率和最低利用率，这些异常值"维护了VMware"可能已经成为过去。今天的数据中心，无论是在prem上还是在公共云上，都是异常复杂的环境。他们一点都不简单。一个中等规模的房地产（5000vm，无论如何都不算大）需要进行数万亿次的权衡。下面是一个示例，展示了标准虚拟数据中心中的一些折衷：任何一个解决方案，如果不连续地同时考虑上述所有的折衷，就永远无法解决当今的应用。当你考虑所有需要考虑的权衡时，如上面所示，"简单地‘比较报告的最高利用率和最低的CPU和内存利用率’的想法几乎是荒谬的。在上面所示的中等规模环境中，大数据的内容，这种权衡的规模并没有什么"简单"的，更不用说在超大规模环境下。更令人惊讶的是，这句话的条件性质——"可能是"。您可能认为创建hypervisor的人可能能够提供一个比这更确定的解决方案。虽然这可能会让一些人感到惊讶，但我们一点也不惊讶。事实上，如果这个"DRS成对平衡"功能真的解决了这个问题，那就令人惊讶了。正如你所见，在当今的超规模虚拟化世界中，问题不能用阈值来解决。当今超尺度世界的问题在于，它是一个多变量问题，必须同时考虑所有变量。退一步说，解决办法到底是什么？我们如何确保在整个系统中，所有的应用程序都能在需要时持续不断地获得执行所需的资源？嗯，与此观点不同，这种观点寻求在不断增长的集群中平衡主机，我们的客户真正关心的是更简单的：他们希望——实际上，他们需要——他们的应用程序能够运行。确保应用程序的性能应该是目标，因为这是唯一重要的事情——毕竟，除了提供客户愿意支付的服务之外，公司不会因为任何其他原因购买昂贵的服务器硬件和虚拟化软件（或云实例）。如果服务不起作用，世界人工智能，那么顾客就得不到任何价值，而且很快就会停止支付。让我们考虑一下这个思考实验：如果vCPU阈值为90%，您应该再添加多少个vCPU？你检查过主机以确保有足够的CPU可用吗？如果你给那个虚拟机更多的vCPU，会不会导致CPU就绪队列，影响主机上的其他虚拟机？如果资源不可用，您要移动哪些虚拟机？这会对您要将它们移动到的目标主机产生什么影响？现在只考虑一个变量，CPU——应用程序需要执行的其他资源，比如内存、存储或网络资源呢？简单的基于阈值的度量失败了，因为它们与确保应用程序性能所需的所有资源隔离地查看一个或两个变量。门槛本身呢？他们不过是猜测而已。为什么选90%？为什么不是95%？或者80%。然而，简单的基于主机的阈值只是我们超大规模虚拟化世界中的第一个失败点。从这个角度来看，一个更根本的失败是因为在这里，重点是集群中的主机，但是如上所述，没有客户为了平衡主机而在主机上花钱。他们把辛苦挣来的公司资本花在客户关心的东西上：在需要时执行的应用程序。通过关注硬件并试图从这个角度来解决问题，这种方法没有考虑到应用程序本身。有空吗？如果可用，它是否响应？如果是响应性的，响应时间是否与客户期望一致？这些问题都不是通过简单地关注基于主机的阈值来回答的。但在这种以主机为中心、基于阈值的方法中，可能还有一个更重要、更根本的失败点：它之所以失败，是因为它首先假设了失败。基于阈值的方法的问题是，通过等待某个任意阈值被突破，它假设失败是给定的。它假定我们必须等到出了问题才可以采取措施。VMware也许可以原谅这一点—毕竟，农业物联网，这种失败的假设是有史以来开发的所有监视工具的基础。从本质上讲，网络、硬件、应用程序性能——无论是哪种类型的监控——都是为了尽快发现异常情况而设计的，这样人们就可以得到警报，并着手进行故障排除和根本原因分析。这就是监控的问题：异常通常是短暂的、暂时的事件，在人类找出根本原因并加以补救之前，这些事件来来往往。然而，这种情况的一个方面并不是暂时的，而是对试图使用您的服务的客户的影响：他们的体验充其量是次优的，而且他们对这种体验的记忆可能会在事件减轻后很长时间内挥之不去。这就是为什么我们在十年前创造了涡轮力学。我们了解到，为了确保应用程序的性能，您必须将重点放在应用程序上，不仅要考虑应用程序的需求，还要考虑IT堆栈（"供应链"）的多个层次上的所有必要资源，以使应用程序符合客户的期望。为了做到这一点，Turbonomic将任何环境整体表示为一个由消费者和资源提供者共同工作以满足应用需求的供应链。本质上，Turboenomic的模型在Turboenomic管理的每一个环境中都创建了"完美市场"——在市场理论意义上，买方和卖方都是理性的参与者，买方和卖方之间的信息在任何时候都是对称的（双方都能看到所有资源的价格，并且具有完全的透明度——确切的价格，同时查看）。更好的是，这种模式非常适合创新——SDN、容器、公共云、云原生技术等创新在我们的模型中都很受欢迎，因为它们的存在增加了市场流动性。与金融市场一样，市场越大、越复杂——市场中的参与者越多——流动性就越大，这使得均衡更加稳定，从而形成一个更有效、更有效的市场。然而，更为根本的是，当我们创建了涡轮经济系统时，我们就下了赌注，把传统的监测方法完全颠覆了。传统的监测一直集中在快速发现故障的移动目标上，以便能够召集人类来解决故障，而我们选择关注另一个移动目标：健康。而不是让应用程序出现问题，失去性能，甚至可能完全失败，我们选择了一种在应用程序需求和基础设施供应之间寻求难以捉摸的平衡的方法—应用程序资源管理或"ARM"—这种平衡将保持应用程序的健康和性能，以便客户可以在您设计精美的服务中享受到他们选择的时间。寻求这种"期望的状态"来确保应用程序的性能，这是一种效率更高的方法，而不是让事情中断，然后试图找出如何修复它们。它也更方便客户，因为我们一开始就不会让他们面对失败。然而，在任何规模上做到这一点的唯一方法是授权系统自己发现这种平衡点，这样它就可以自我管理了。通过向"买方"（如应用程序、虚拟机、实例、容器、服务等实体）提供预算，以寻求交付其设计交付的任何服务所需的资源，并授权"卖方"根据利用率实时定价其可用资源（如CPU、内存、存储、网络等资源），TurboEnomics支持管理良好、运行良好的操作：当对特定应用程序的需求增加时，应用程序与其他购买者共享的资源的价格也随之上涨，在本例中，迫使工作负载发生变化。即使在今天的小数据中心规模下，人类也无法考虑所有必要的折衷，以确保及时交付性能。任何一个解决方案，只要考虑到一些"简单"的指标，并以失败为先决条件…好吧，那个解决方案根本不是解决方案。因此，大数据产品，要小心任何听起来像技术的方法，只要"简单地"比较报告的最高利用率和最低利用率，"可能会更好"。考虑到这种方法没有考虑到的所有问题，"DRS"可能实际上并不具有可伸缩性。