Table of Contents
云调度概述
http://accelazh.github.io/cloud/A-Summary-of-Cloud-Scheduling
现实世界资源利用
为了提供一些背景知识，Quasar总结了许多有关数据中心资源利用率的真实世界统计信息（我复制了大部分内容）
- Twitter上的一个生产集群，具有数千台服务器，由Mesos管理超过一个月。
- 群集主要托管面向用户的服务。即使预留达到总容量的80％，总的CPU利用率始终低于20％。
- 即使查看单个服务器，它们的大多数在任何一周内都不会超过50％的利用率。典型的内存使用率较高（40-50％），但仍与保留的容量有所不同。
- 很少的工作负载会保留适当数量的资源；大多数工作负载（70％）高估了预留量达10倍，而许多工作负载（20％）低估了预留量达5倍。
- 使用更成熟的Borg系统管理的12,000台服务器的Google集群始终可以实现25-35％的CPU总利用率和40％的内存总利用率。相反，预留的资源分别超过了CPU和内存可用容量的75％和60％。
Twitter和Google处于使用范围的高端。对于无法与Google和Twitter分别与Borg和Mesos共同处理工作负载的云设施，利用率估计甚至更低。
- 各种分析估计整个行业的利用率在6％至12％之间。
- 最近的一项研究估计，Amazon EC2上的服务器利用率在3％到17％之间。
因此，总的来说，我可以假设现实世界的资源利用率低于20％。太低了
计划目标
如之前的“能源感知型云计算摘要”所述，调度的根本动机是节省能源成本（几乎占总支出的50％，其中包括购买新机器）。为了提高资源利用率（或能源效率），调度需要在更少的主机中整合应用程序。但这提出了有关性能和QoS（服务质量）/ SLA（服务水平协议）/ SLO（服务水平目标）的新问题。下面我总结了调度的目标
- 服务器整合。机器更少，应用密度更高，资源利用率更高，能源效率更高。最终降低成本。
- 提高资源利用率。更高的资源利用率可以提高电源效率，并减少空闲资源的浪费。
- 余额资源放置是同一枚硬币的另一面。对于存储，我们需要兼顾存储容量空间和访问热点空间。但是，对于第二点，基于一致性哈希的展示位置通常会忽略/不灵活。
- 确保应用程序的QoS / SLA / SLO。有相似的名字。为了一致性，我在下面将其称为SLA。
- 通过更好的放置来提高预定应用程序的性能
这些目标是相互关联的。同样，基本上，将更多的应用程序整合在一台主机中，提高资源利用率，这自然是针对应用程序SLA的。在调度领域这是一场持续的战斗。
尽管如此，调度程序可能还有其他目标，例如下面。所以要保持开放的心态
- 尾部潜伏期。通过巧妙地放置或复制分区任务，所有分区的最大延迟（尾部延迟）数量将受到限制。同样，正如所看到的，延迟可能是调度的目标。
计划的补充部分
我实际上将云调度理解为三个互补方面
- 常识调度。任务启动时，调度程序会找到最佳运行位置。
- 例如：Green Cloud，Paragon，Quasar。还有Openstack，Kubernetes，Mesos等等的调度程序。
- 持续优化。当任务已经运行时，我们可以优化其放置。最常见的技术是实时迁移。可以在另一台主机上移动/重新安排/重新启动任务。监视是必要的。
- 示例：Openstack Watcher，VMware DRS
- 资源容器（我叫这个名字）。它在本地一个主机级别上工作。它的需求是双重的，AFAIK远远超出了Docker
- 对于位于同一位置的关键应用程序和效果最好的（低优先级）应用程序，我们需要一种隔离其资源大小，隔离其资源带宽，隔离其资源干扰并最终隔离其性能的方法。
- 另一个方面是，由于工作负载是随时间变化的，因此资源容器需要动态响应以扩展/缩小其气泡。这样，尽力而为的应用程序就可以利用关键应用程序留下的所有空闲资源。
- 示例：Google Heracles
理想的情况是，它们可以一起作为完整的云调度解决方案。在现实世界中，通常缺少后两个。另外，为了提高资源利用率，例如也可以从人/用户开始。
- 资源定价和退款。它迫使用户考虑应该租多少钱。金钱激励提高了资源效率。请参阅Twitter的。
调度因素
我尝试总结调度应该考虑的所有因素。AFAIK，考虑了更多因素，调度效率更高。
首先，资源。它包括资源大小和资源带宽。后者更容易忽略。Google Heracles是一个很好的参考。容器名称空间的隔离仅仅是一个开始。CGroups没有提供完整的功能。
- CPU：Cpu内核，时间配额，权重
- 缓存：L1 / L2 / L3 /上级缓存（LLC）（Intel CAT），TLB
- DRAM：内存大小，内存带宽；还有NUMA和内存节点
- 永久内存：大小，带宽；如果添加到系统
- 磁盘IO：IOPS，每秒请求，磁盘带宽
- NVM：如果将NVM / NVMe / SSD磁盘视为更宝贵的资源，则可以使用它们
- 网络流量：每秒数据包，带宽
- PCI总线：PCI总线带宽是有限的资源
- 电源：电源病毒可能会降低CPU核心频率
- GPU：限制使用的大小（核心？内部存储器？），使用的带宽等
- 更多的硬件（虚拟）功能：例如压缩卡，Fathom GPU棒等
另一件容易忽略的事情是
-
随时间变化。实际的工作量实际上是随时间变化的，因此需要资源利用。通过恒定的模板/清单（例如，在Openstack，Kubernetes，Mesos中）指定应用程序需要多少总是会浪费一些内部剩余的资源。
- 无服务器，从本质上将应用程序划分为短期任务，可能会解决此问题。
总体而言，资源干扰是主要问题。如在Paragon中所使用的，Bubble-up提出了一种很好的方法来建模和测量资源干扰
-
为应用建模资源干扰
-
可以接受：每种资源的单一基准，请查看其压力将使应用程序脱离其SLA。它揭示了应用程序对每种资源干扰类型的不同敏感性。
-
原因：当应用程序在其SLA级别运行时，每种资源会产生多大的压力。它将充当其他位于同一位置的应用程序上的资源干预。
-
-
要确定资源的吸引力，请使用气泡
-
可以容忍：对于每种资源，请慢慢增加其基准压力，直到应用程序无法通过其SLA为止。记下这一点作为得分。
-
原因：让应用程序仅在其SLA点运行。记录下每种类型产生的资源压力。
-
Paragon＆Quasar揭示，应用程序首选项在很大程度上提高了调度效率，尤其是服务器配置（即（VM）硬件设置）。他们在上线之前就按阶段分析了已分阶段的任务，并使用协作过滤来填充缺失的列。
-
偏好资源干扰。不同的应用程序对资源类型的敏感性不同。
-
首选服务器配置。服务器配置可能会严重影响应用性能
-
它包括：CPU时钟频率，插槽，内核，L1 / L2 / L3高速缓存/ LLC，TLB，内存和服务器硬件的寿命等。
-
硬件支持也是一个考虑因素。GPU，大内存，SR-IOV，NVM或特殊的硬件辅助，加速卡等。
-
-
倾向于横向扩展和纵向扩展。应用程序性能可能对每个应用程序都有不同的敏感性。
下一个因素是应用程序依赖性。应用程序通常依赖于其他应用程序来工作。他们的互动频率和流量不对称。统一调度在这里不合适。应用程序之间变化的亲和力导致
-
通过应用之间的流量亲缘关系进行调度：频率，带宽。
-
应用托管。将高度有限的应用程序放在一台主机，一个机架中，在同一台交换机下或任何位置，以缩短其网络距离。
-
单元架构。我们没有将所有事物放入一个非常大的群集中，而是将它们划分为多个较小的单元。通常我们可以按用户对它们进行分区。从根本上讲，高度依赖的应用程序被划分到同一单元中，并在同一位置部署。
-
数据局部性。将应用程序（计算）靠近数据（待计算）。自Hadoop和MapReduce以来，该概念已普及。
另外，应考虑不同的工作负载/任务类型。这是尺寸。Google Omega和Borg显示了一些方面。
-
服务与批次。服务通常是面向用户的，对延迟至关重要的并且具有较高的优先级。批处理通常是Hadoop / Spark / etc，优先级低，并且按时更灵活。
-
短期任务和长期工作。通常，短期任务和长期工作会受到不同待遇。它们的数量泛滥可能是非常不同的。
-
洪水量。每秒执行多少任务，是重负载还是轻负载。这可能导致不同的策略。
社区的努力是巨大的，但是AFAIK仍然有很多缺失的部分。
排程方法
这是最灵活的部分。这取决于调度程序如何使用上述因素并决定其策略。我总结了一些我知道的
-
贪婪。筛选不合适的主机，找到最合适的主机，然后在其上安排应用。这是最常用的方法，通常足够有效。
-
约束方程。将调度问题视为求解约束方程。它可以用来表达复杂的业务规则。
-
使用预测。机器学习和智能分析高度参与。
-
使用的模型可以是简单的线性函数，统计模型（PDF）或其他机器学习算法（例如，Paragon中的协作过滤）。
-
预测的可能是工作负载模式（例如Netflix Scryer），应用程序首选项（例如Paragon和Quasar），展示位置分布，违反SLA的可能性……这是无限的。
-
策略的元数据。一种调度策略可能并不适合所有条件。调度程序可以配备许多策略，并决定何时切换到什么。
-
-
积极主动。决定是对变化做出反应还是对变化采取积极行动会导致采取不同的策略，通常是为了应对变化的工作量。Netflix Scryer就是一个例子。
-
优化问题。将资源的最佳分配视为优化问题，并使用适当的渐变色（例如Google Heracles）。
-
舞台分析。在线预定该应用之前，我们可以先在几台专用计算机上对其进行概要分析。了解更多关于它的偏好后，我们可以进行更好的调度。参见Paragon。
-
结合专用问题/用例。例如，移动众包。这可以得出不同的算法。
必须始终有新的，更好的方法和更好的方法。敬请关注。
调度架构
正在进行各种调度体系结构。这是很好的参考（及其中文翻译版本）。
-
整体调度程序。中心调度程序会做所有事情，或者共享同一数据库的无状态调度程序的副本。这是一种常见的方法，可以很好地应对工程师的复杂性。在Openstack中看到的大多数调度程序，Kubernetes都是这样。
-
两级调度程序。例子是Mesos。它将资源分配和任务放置分开。通常，中央调度程序会分发资源提议，并且每个应用程序都挂在其第二级调度程序上以进行任务放置。
-
优点：应用程序更容易在二级调度程序中挂接其专用逻辑。资源提供是一个新概念。
- 最重要的是，Mesos解决了静态分区问题：Hadoop，Spark，Storm等各自占用自己的资源池，它们每个都有自己的调度程序。但是，由于池分区是静态的，因此Hadoop无法借用Spark的空闲资源，反之亦然。通过Mesos，它们共享相同的资源池。Mesos充当数据中心级别的资源调度程序。
-
不好的一面：二级调度程序的意见不一。他们看不到全球地位，而只能看到提供给他们的东西。如果没有全局性的了解，就很容易做出次优的决策，尤其是对于共置任务。
- 有些作品试图解决Mesos的问题，例如Netflix Fenzo。
-
-
共享状态调度程序。示例是Google Omega。调度程序共享群集的状态。群集状态的副本由调度程序独立更新；它们可能会发生冲突，因此需要乐观地并发事务。单个调度程序可能正在处理过时的信息，并且在高竞争下可能会遇到性能下降的情况。
-
完全分布式的调度程序。调度程序是分布式的，它们之间没有协调。作业可以提交给任何调度程序，每个调度程序都可以将任务放置在群集中的任何位置。它仍然是学术性的。问题在于，以这种方式设计功能全面的综合调度程序太困难了。
-
混合调度程序。它试图结合单片计划程序和共享状态计划程序，以解决完全分布式计划程序的问题。例如，有两种调度路径：用于非常短的任务或低优先级批处理工作负载的分布式路径，以及用于其余任务的集中式路径。它仍然是学术性的。
IBM云调度概述
调度提供了在受测试应用程序上应用大型用户负载的方式。要应用该数量的负载，您需要良好的基础结构支持，包括有足够 RAM、处理器和不同操作系统的物理台式计算机。您需要实验室来托管这些计算机。需要大量的资金投入。 可通过在云位置上运行调度来减少投资。
IBM® Rational® Performance Tester 支持通过使用 SoftLayer 基础结构在公有云上或在 VMware 的私有云上运行调度。
关于促销码和预订标识
要运行云调度，需要促销码（试用）或预订标识。通过试用促销码，运行不会收取您任何费用。当您购买云负载生成服务时，运行云调度的成本基于此调度所运行的虚拟测试员小时数。因此，仅当运行云调度时才需要付费。
可从 http://www.ibm.com/marketplace/cloud/performance-testing/us/en-us 请求促销码。该页面还具有 IBM Cloud Marketplace 的链接，从其中可请求预订标识。当您获取到促销码或预订标识时，将其与 IBM 标识一起添加到窗口 > 首选项 > 测试 > 帐户 > 云负载生成服务。
试用促销码
试用促销码用于评估有限时间段内云中没有任何成本的负载生成能力。但也存在某些限制，例如可在调度中使用的虚拟用户数和代理程序数。促销码的到期日期从美国太平洋时区进行计算。试用促销码服从在产品安装时接受的试用许可证条款和条件。在 SoftLayer 公有云基础结构中运行调度所需的促销码与 VMware 私有云基础结构所需的促销码不同。
预订标识
需要预订标识来运行调度而对持续时间和代理程序数没有任何限制。http://www.ibm.com/software/products/en/rpts 页面上提供了 IBM Cloud Marketplace 的链接。使用该门户网站可查看更多信息并注册服务。在成功的注册后，会向您发送确认电子邮件。IBM 标识可与多个预订标识关联。类似地，在团队环境中，多个 IBM 标识可共享同一预订标识。与预订的购买关联的 IBM 标识可添加其他订户。
对于 V8.7.1，仅当在 SoftLayer 基础结构上运行调度时，预订标识才有效。如果使用 VMware 的私有云基础结构，请对运行使用促销码。
为 SoftLayer 创建位置模板
位置模板用于定义诸如以下的虚拟机属性：操作系统映像类型、数据中心位置以及要在云中托管的代理虚拟机的主机类型。创建位置模板后，在创建云调度时，请将这些位置模板与此调度相关联，并指定要用于运行此调度的代理虚拟机数。
开始之前
- 确保您具有 IBM 标识。
- 确保您具有促销码或预订标识。请参阅关于促销码和预订标识。
关于此任务
如果您必须通过位于不同地理位置的虚拟测试程序来运行云调度，例如达拉斯数据中心内的用户组以及巴黎数据中心内的另一个用户组，那么可创建多个位置模板并将其与一个云调度相关联。为代理虚拟机选择数据中心时，请谨记，数据中心与您应用程序的位置之间的距离以及到达数据中心所需的中继段数可造成响应时间差异。
主机类型的选择也可确定响应时间。在共享系统管理程序中，可与许多其他访客操作系统共享底层硬件，因此添加审计用户组以确保响应时间的准确性很重要。在专用系统管理程序中，硬件不与其他操作系统共享。裸机表示完全专用的一台硬件。主机类型的选择会影响在云中运行调度的成本。
过程
- 单击文件 > 新建 > 位置模板
- 指定位置模板的名称。 将创建模板。
- 要连接到云管理器，单击连接。
- 如果连接成功，请指定数据中心的位置、操作系统类型和代理程序虚拟机的主机类型。 如果连接失败，请联系产品支持人员。
- 保存位置模板。
下一步做什么
可创建云调度并将位置模板关联到调度。
为 VMware 创建位置模板
位置模板包含了要在云中托管的代理程序虚拟机的虚拟机属性，例如数据中心位置、资源池和数据存储。创建位置模板后，在创建云调度时，请将这些位置模板与此调度相关联，并指定要用于运行此调度的代理虚拟机数。
连接到 SoftLayer 的云管理器
要运行云调度，首先必须建立与云管理器的连接。通过连接到云管理器，可在云上指定工作台和代理机器的属性，例如数据中心的位置、操作系统的类型和主机管理器的类型。
通过代理连接到云管理器
要在云上运行调度，工作台必须连接到 Rational Performance Tester 云管理器。如果工作台安装在防火墙后面，请使用连接到工作台计算机后面且具有因特网访问权的代理计算机。
连接到 VMware 服务器
要启动云运行，必须首先建立与 vCenter 服务器的连接。在连接到服务器时，指定工作台模板的属性，例如数据中心、资源池和托管虚拟机的域。如果通过位置模板连接到 vCenter 服务器，那么还必须遵循本主题中的指示信息，通过“首选项”窗口建立连接。
创建云调度
如果您必须扩展性能测试的用户负载而无法对物理计算机投入资金，那么可创建在云上运行的调度。
运行云调度
IBM Rational Performance Tester 可用于在云中运行调度。 在云中运行调度的好处包括可访问云中的负载生成代理程序，可从具有位于全球的数据中心的不同地理位置访问受测试系统，以及仅在需要时购买负载生成服务。
审计度量准确性
在虚拟环境中，负载生成能力可能会由于吞吐量、CPU 利用率和度量准确性而显著降低。例如，在云环境中，响应时间度量可能会根据诸如数据中心位置、主机类型和代理虚拟机生命周期的因素而有所不同。因为并非所有因素均可由 IBM Rational Performance Tester 控制，所以每次都获取准确响应时间会很困难。但可在报告的度量与可信控制之间进行统计方面的对比。
扫一扫
1371
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
