ZStack Cloud 4.8.0>实践教程>私有云>云主机调度策略使用教程>概述

概述

云主机调度策略（VM Scheduling Policy）：为云主机分配物理机的资源编排策略，可用于保障业务的高性能和高可用。

功能原理

支持将云主机加入一个云主机调度组，通过为该云主机调度组绑定调度策略实现云主机调度。

若绑定互斥云主机或聚集云主机策略，无需指定物理机调度组，云主机按照策略及其执行机制分配物理机。
若绑定云主机亲和物理机或云主机互斥物理机调度策略，需指定对应的物理机调度组，云主机按照策略及其执行机制分配物理机。

下文通过四个场景说明四类调度策略的工作原理：

场景1：假定区域内有三台物理机Host1、Host2、和Host3。云主机调度组A已绑定互斥云主机调度策略，且云主机VM1和VM2已加入该调度组，并分别运行在物理机Host1和Host2上。此时将云主机VM3加入该调度组，不同执行机制下云主机VM3行为如下：

强制机制下，云主机VM3遵循与组内其他云主机强制互斥原则：
- 若物理机Host3资源充足，可正常在Host3上启动并运行。
- 若物理机Host3资源不足，无法在Host3上启动。
优先机制下，云主机VM3遵循与组内其他云主机尽量互斥原则，优先在Host3上启动：
- 若物理机Host3资源充足，可正常在Host3上启动并运行。
- 若物理机Host3资源不足，VM3可尝试在其他资源充足的物理机上启动。在该场景下，VM3在Host2上启动并运行。

如图 1所示：

场景2：假定区域内有两台物理机Host1和Host2。云主机调度组A已绑定聚集云主机调度策略，且云主机VM1和VM2已加入该调度组，并运行在物理机Host1上。此时将云主机VM3加入该调度组，不同执行机制下云主机VM3行为如下：

强制机制下，云主机VM3遵循与组内其他云主机强制聚集原则：
- 若物理机Host1资源充足，可正常在Host1上启动并运行。
- 若物理机Host1资源不足，无法在Host1上启动。
优先机制下，云主机VM3遵循与组内其他云主机尽量聚集原则，优先在Host1上启动：
- 若物理机Host1资源充足，可正常在Host1上启动并运行。
- 若物理机Host1资源不足，VM3可尝试在其他资源充足的物理机上启动。在该场景下，VM3在Host2上启动并运行。

如图 2所示：

场景3：假定区域内有三台物理机Host1、Host2、和Host3。云主机调度组A已绑定云主机互斥物理机调度策略，且云主机VM1和VM2已加入该调度组，并运行在物理机Host1上。物理机调度组A也已绑定云主机互斥物理机调度策略，且物理机Host2和Host3上已加入该调度组，分别运行两台云主机。此时将云主机VM3加入云主机调度组A，不同执行机制下云主机VM3行为如下：

强制机制下，云主机VM3遵循与物理机调度组A内的物理机强制互斥原则：
- 若物理机Host1资源充足，可正常在Host1上启动并运行。
- 若物理机Host1资源不足，无法在Host1上启动。
优先机制下，云主机VM3遵循与物理机调度组A内的物理机尽量互斥原则，优先在Host1上启动：
- 若物理机Host1资源充足，可正常在Host1上启动并运行。
- 若物理机Host1资源不足，VM3可尝试在其他资源充足的物理机上启动。在该场景下，VM3在Host2上启动并运行。

如图 3所示：

场景4：假定区域内有三台物理机Host1、Host2、和Host3。云主机调度组A已绑定云主机亲和物理机调度策略，且云主机VM1~VM5已加入该调度组，并分别运行在物理机Host2和Host3上。物理机调度组A也已绑定云主机亲和物理机调度策略，且物理机Host2和Host3上已加入该调度组。此时将云主机VM6加入云主机调度组A，不同执行机制下云主机VM6行为如下：

强制机制下，云主机VM3遵循与物理机调度组A内的物理机强制聚集原则：
- 若物理机Host2或Host3资源充足，可正常在Host2或Host3上启动并运行。
- 若物理机Host2和Host3资源不足，无法在Host2或Host3上启动。
优先机制下，云主机VM3遵循与物理机调度组A内的物理机尽量聚集原则，优先在Host2或Host3上启动：
- 若物理机Host2或Host3资源充足，可正常在Host2或Host3上启动并运行。
- 若物理机Host2和Host3资源不足，VM6可尝试在其他资源充足的物理机上启动。在该场景下，VM3在Host1上启动并运行。

如图 4所示：

功能优势

云主机调度策略具备以下优势：

全面&灵活：
- 提供4类调度策略*2种执行机制，定义云主机与云主机之间、云主机与物理机之间互斥/亲和关系。各类调度策略可灵活组合，满足所有主流业务场景需求。
- 支持通过云主机调度组实现多个云主机批量绑定/解绑一个或多个调度策略，简单高效。
- 直观展示云主机调度状态，并提供快捷解冲突操作，方便用户实时掌握业务调度动态，并及时进行调整。
强大&可靠：
- 相同/不同业务之间支持互斥/亲和，实现业务隔离/高效互通，保障业务高性能和高可靠性。
- 可通过物理机调度组灵活配置云主机业务故障域，支持单个物理机部署、单个集群内批量物理机部署、以及跨集群物理机部署，避免单点故障，保障业务稳定性，并提高物理资源利用率。

应用场景

以下介绍互斥云主机（强制/优先）和云主机亲和物理机（强制/优先）策略的应用场景。

互斥云主机（强制）策略应用场景举例：
承载主备数据库的两台云主机要求部署在不同的物理机上，保障业务高可用。
- 例如：用户部署两台业务云主机分别承载主备MySQL数据库，要求两台云主机必须部署在不同物理机上，以降低业务宕机的风险。由于部署自动化，用户事先并不能预知哪些物理机上有资源，采用互斥云主机（强制）策略，可选出两个不同的物理机分别运行这两台云主机，保障业务高可用。
互斥云主机（优先）策略应用场景举例：
希望Hadoop不同角色的节点尽量分散部署在不同的物理机上，提高系统整体性能。
- 例如：用户部署Hadoop系统，对于namenode、datanode、jobtracker、tasktracker等不同角色，事先并不能预知总共有多少个节点，但显然部署到不同物理机上效率更高。采用互斥云主机（优先）策略，可使Hadoop集群尽量分散部署在不同物理机上，分散IO压力提高系统整体性能。
云主机亲和物理机（强制）策略应用场景举例：
要求业务云主机部署在特定CPU主频的物理机上，保障业务稳定性。
- 例如：用户部署了四台云主机运行重要业务，要求所在物理机具有很高的CPU主频。由于能满足该CPU主频要求的物理机较少，云主机必须运行在这几台物理机上。此时可采用云主机亲和物理机（强制）策略，使云主机强制运行在目标物理机上，保障业务稳定性。
云主机亲和物理机（优先）策略应用场景举例：
希望运行不同的业务云主机尽量部署在同一机柜中的物理机上，保障业务高效互通。
- 例如：四台云主机运行不同业务，业务间需要频繁通信，要求物理机尽可能在同一机柜中，以缩短通信延迟。此时可采用云主机亲和物理机（优先）策略，使云主机尽量运行在目标物理机上，保障业务高效互通。