本发明涉及计算机应用技术领域，具体涉及一种针对典型容器的Docker动态调度算法。
背景技术：
容器技术作为虚拟机的一种轻量级替代方案，在保证容器之间资源隔离的同时，其处理能力、内存和网络吞吐率都接近物理机原始性能。作为容器的应用引擎，Docker能够高效部署、执行和管理容器。然而现有的Docker资源管理机制较为简单，为用户提供了默认资源配置和通过参数手动配置容器实例资源这两种方式。但是并没有区分应用容器实例类型，对于每种容器实例的资源分配比较平均。当物理机上同时运行实时型应用容器和批处理型应用容器时，很难根据实时型应用容器的服务强度变化来快速动态调整容器实例的资源配置，因此无法保证实时型应用容器的服务性能。
目前Docker现有的资源管理策略，不会根据当前物理机上整体资源使用情况进行资源限制检查，不限制容器实例增加。当同时运行偏重资源类型相同或相似的多个应用容器时，容器使用资源类型比较单一，容易造成其他系统资源的利用率低；同时由于资源竞争导致无法满足应用容器的资源需求，从而造成容器运行性能比较差。另外，运行的容器实例使用的总内存资源达到系统内存限制时，可能会导致由于当前内存不足，系统杀掉正常运行的容器。
容器实例在创建时和运行中，Docker为用户提供了对CPU份额和磁盘I/O权重的设置方式，但是用户在使用过程中，若不清楚测试应用的资源使用特征，便很难确定偏重资源类型及相应参数值的大小。
因此多个容器实例运行时，需要针对应用容器运行状态以及系统资源使用状态，来实时动态调整容器的资源配置。确保每个应用容器的运行性能满足SLA协议要求，同时在有限的资源情况下，最大化系统整体资源利用率。
技术实现要素：
本发明的目的在于提供一种针对典型容器的Docker动态调度算法，其在能保证应用容器的运行性能的同时，提高系统资源利用率。
为实现上述目的，本发明的技术方案是：
一种针对典型容器的Docker动态调度算法，包括如下步骤：
S1：典型应用容器的场景包括CPU密集型/批处理型、内存密集型/批处理型、I/O密集型/批处理型和CPU密集型/实时型，其分别选取对应的应用容器，分析各应用容器在Docker环境下单独运行和多个并发运行时的资源使用及性能情况；
S2：调度算法包括容器静态调度算法和基于运行时监控的容器动态调度算法；根据用户使用需求，分情况采用容器静态调度方式和容器动态调度方式；运行多个同种应用容器时，采用容器静态调度方式，根据应用容器特点和SLA协议要求，最大化节点上运行的容器实例数量；异构并发应用容器时，采用容器动态调度方式，优先保证实时型应用容器服务，其次保证批处理型应用容器的运行性能，并根据节点运行现状，推荐最优实例类型，从而在减少与现有运行时应用容器的资源竞争的同时，最大化系统资源利用率。
优选地，步骤S1中，具体包括如下子步骤：
S1.1：典型应用容器的场景CPU密集型/批处理型、内存密集型/批处理型、I/O密集型/批处理型和CPU密集型/实时型分别选取对应的应用容器为：Memcached、Parsec、Speccpu2006和Filebench；
S1.2：对于每种应用容器，在应用容器环境下进行单个运行，获得在无竞争情况下每个单个应用容器的运行特征；
S1.3：对于每种应用容器，多个同时在容器环境下运行，获得其同时运行时的资源使用限制及应用容器的性能表现。
优选地，步骤S2具体包括如下子步骤：
S2.1：根据用户需求来增加应用容器，根据是否仅运行同一种应用容器，来选择使用容器静态调度方式还是容器动态调度方式，当仅运行同种应用容器时，进入步骤S2.2；若否，进入步骤S2.3；
S2.2：采用容器静态调度方式；
S2.3：采用容器动态调度方式；
S2.4：将用户请求处理结果反馈给用户；
优选地，步骤S2.2具体包括如下子步骤：
S2.2.1：当用户提交请求需要运行的应用名称及数量时，首先从数据表中读取指定应用的实例个数限制值，当请求运行的容器实例数量小于或等于该值时，则可以完成容器实例增加。否则，不允许增加请求的容器实例数；
S2.2.2：反馈处理结果。
优选地，步骤S2.3具体包括如下子步骤：
S2.3.1：首先根据指定应用，查询应用容器运行特征表，得到该应用容器的限制运行实例数，判断当前节点上运行的该应用容器实例数是否已经达到限制，若是，则无法完成新增容器操作；若否，则进入步骤S2.3.2；
S2.3.2：查询该应用容器的类型、最小CPU需求和最大内存需求；先判断当前物理机上可用内存资源是否能够满足新增应用容器的最大内存需求；若不能满足，则无法完成新增应用容器操作，选择其他资源充足的物理机来完成新增操作；若可以满足，则进入步骤S2.3.3；
S2.3.3：判断当前可用CPU资源是否能够满足新增应用容器的最小CPU需求；若不能满足，则无法完成新增应用容器操作，选择其他资源充足的物理机来完成新增操作；若可以满足，则进入步骤S2.3.4；
S2.3.4：用户在创建容器实例时，若采用默认设置方式设置优先级，则进入步骤S2.3.5；若采用手动指定值方式设置优先级，则进入步骤S2.3.6；
S2.3.5：批处理型应用容器的优先级设置为1，而实时型应用容器的优先级设置为2，完成新增应用容器操作；
S2.3.6：手动设置优先级时，用户通过系统提供接口，查看到当前节点上所有应用容器实例的优先级设置情况，然后在新增容器时为实例指定优先级；另外，用户在容器实例运行过程中，根据需求来更改指定容器的优先级；优先级设置值越大，则优先级越高，容器实例可使用的偏重资源数越多；在手动设置优先级方式下，依然优先满足实时型应用的资源需求，将实时型应用容器的优先级设置为指定值的两倍，完成新增容器操作；
S2.3.7：每3秒获取一次所有运行中的批处理型应用容器的CPU利用率，并查询其在无竞争状态下运行时的平均CPU利用率，对比两个值，如果其差值超过100%，则认为可能出现了资源竞争情况，接下来每秒监测一次实时CPU利用率值，总共监测3次，如果每次差值都超过100%，则确定处于资源竞争状态；
S2.3.8：当运行实时型应用容器后，以10秒作为一个时间阶段获取实时型应用容器的平均响应时间，设置调控梯度为6毫秒，8.5毫秒，9.5毫秒，13毫秒四级；处于6毫秒和8.5毫秒调控梯度时，CPU份额的调控粒度为512，处于9.5毫秒调控梯度时，CPU份额的调控粒度为1024，处于13毫秒调控梯度时，CPU份额的首次调控粒度为2048，第二次为1024，当处于6毫秒梯度时减少CPU份额，其他梯度时都增大CPU份额；每次调整CPU份额，都即时更新容器实例状态表中指定容器的CPU份额值；
S2.3.9：当用户提交推荐应用容器请求时，根据当前节点资源使用情况，推荐可运行的应用容器，减少与现有运行时容器的资源竞争的同时，充分利用空闲资源，提高整体资源利用率；针对CPU资源，通过此时系统是否处于资源竞争状态来判断资源使用状态，当系统处于资源竞争状态时，认为CPU资源已经处于竞争状态；内存资源和I/O资源都认为是空闲资源；查询应用容器运行特征表，找到偏重使用空闲资源，且竞争资源需求小的应用，并经过增加容器实例算法判断可以增加后，向用户推荐运行该应用容器。
本发明的工作原理为：
本发明提供的这种针对典型应用的动态调度算法，简化优先级设计，针对应用容器运行状态以及系统资源使用状态，来实时动态调整容器的资源配置。确保每个应用容器的运行性能满足SLA协议要求，同时在有限的资源情况下，最大化系统整体资源利用率。
在运行多个同种应用容器时，采用静态调度算法；在多个异种应用容器并发时，采用动态调度算法。当同时运行实时型和批处理型应用容器时，根据实时型应用容器的服务强度变化，来及时调整资源配置，在优先保证实时型应用的服务性能满足SLA协议要求的同时，保障批处理型应用容器性能。此外，动态调度算法还可以根据节点资源使用现状，推荐可增加的应用容器，从而减少与现有运行时容器资源竞争，使节点的资源利用率最大化。
本发明的有益效果为：动态调度算法在不影响应用容器运行性能的同时，可起到提高系统资源利用率的作用。
附图说明
图1是本发明针对典型应用的Docker动态调度算法的整体流程图；
图2是本发明增加应用容器的流程图；
图3是本发明资源竞争调度的流程图；
图4是本发明服务强度调度的流程图。
具体实施方式
下面结合附图1-4和实施例，对本发明的具体实施方式作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。
本发明具体实施的技术方案是：
为便于理解，将在本发明中涉及的术语解释说明如下：
容器：是为应用程序提供的一个资源隔离的运行环境，并且可以将运行应用程序的完整组件打包成镜像，便于重复使用。
Docker：是一个部署、执行和管理容器的工具，使用官方的Docker hub所提供的标准镜像可以快速构建容器，实现秒级启动，同时在版本保存上也更加轻便和低成本。
Memcached：是一个开源的针对分布式内存对象的高性能缓存系统，旨在通过减轻数据库负载压力，来加速动态web应用程序。
Speccpu2006：是SPEC的标准化测试集，用于系统处理器，内存子系统和编译器测试。
Filebench：是一款自动化测试应用，通过快速模拟真实环境中应用服务器的负载，来对文件系统的性能进行测试。
Parsec：是一个由多线程应用程序组成的测试程序集。
本发明提供了一种针对典型容器的Docker动态调度算法，主要利用运行时监控的方式，根据系统资源使用状态及应用容器运行状态来进行实时调度，其具体流程如图1所示，包括如下步骤：
一种针对典型容器的Docker动态调度算法，包括如下步骤：
S1：典型应用容器的场景包括CPU密集型/批处理型、内存密集型/批处理型、I/O密集型/批处理型和CPU密集型/实时型，其分别选取对应的应用容器，分析各应用容器在Docker环境下单独运行和多个并发运行时的资源使用及性能情况；
S2：调度算法包括容器静态调度算法和基于运行时监控的容器动态调度算法；根据用户使用需求，分情况采用容器静态调度方式和容器动态调度方式；运行多个同种应用容器时，采用容器静态调度方式，根据应用容器特点和SLA协议要求，最大化节点上运行的容器实例数量；异构并发应用容器时，采用容器动态调度方式，优先保证实时型应用容器服务，其次保证批处理型应用容器的运行性能，并根据节点运行现状，推荐最优实例类型，从而在减少与现有运行时应用容器的资源竞争的同时，最大化系统资源利用率。
优选地，步骤S1中，具体包括如下子步骤：
S1.1：典型应用容器的场景CPU密集型/批处理型、内存密集型/批处理型、I/O密集型/批处理型和CPU密集型/实时型分别选取对应的应用容器为：Memcached、Parsec、Speccpu2006和Filebench；
S1.2：对于每种应用容器，在应用容器环境下进行单个运行，获得在无竞争情况下每个单个应用容器的运行特征；
S1.3：对于每种应用容器，多个同时在容器环境下运行，获得其同时运行时的资源使用限制及应用容器的性能表现。
步骤S2具体包括如下子步骤：
S2.1：根据用户需求来增加应用容器，根据是否仅运行同一种应用容器，来选择使用容器静态调度方式还是容器动态调度方式，当仅运行同种应用容器时，进入步骤S2.2；若否，进入步骤S2.3；
S2.2：采用容器静态调度方式；
S2.3：采用容器动态调度方式；
S2.4：将用户请求处理结果反馈给用户；
步骤S2.2具体包括如下子步骤：
S2.2.1：当用户提交请求需要运行的应用名称及数量时，首先从数据表中读取指定应用的实例个数限制值，当请求运行的容器实例数量小于或等于该值时，则可以完成容器实例增加。否则，不允许增加请求的容器实例数；
S2.2.2：反馈处理结果。
步骤S2.3具体包括如下子步骤：
S2.3.1：首先根据指定应用，查询应用容器运行特征表，得到该应用容器的限制运行实例数，判断当前节点上运行的该应用容器实例数是否已经达到限制，若是，则无法完成新增容器操作；若否，则进入步骤S2.3.2；
S2.3.2：查询该应用容器的类型、最小CPU需求和最大内存需求；先判断当前物理机上可用内存资源是否能够满足新增应用容器的最大内存需求；若不能满足，则无法完成新增应用容器操作，选择其他资源充足的物理机来完成新增操作；若可以满足，则进入步骤S2.3.3；
S2.3.3：判断当前可用CPU资源是否能够满足新增应用容器的最小CPU需求；若不能满足，则无法完成新增应用容器操作，选择其他资源充足的物理机来完成新增操作；若可以满足，则进入步骤S2.3.4；
S2.3.4：用户在创建容器实例时，若采用默认设置方式设置优先级，则进入步骤S2.3.5；若采用手动指定值方式设置优先级，则进入步骤S2.3.6；
S2.3.5：批处理型应用容器的优先级设置为1，而实时型应用容器的优先级设置为2，完成新增应用容器操作；
S2.3.6：手动设置优先级时，用户通过系统提供接口，查看到当前节点上所有应用容器实例的优先级设置情况，然后在新增容器时为实例指定优先级；另外，用户在容器实例运行过程中，根据需求来更改指定容器的优先级；优先级设置值越大，则优先级越高，容器实例可使用的偏重资源数越多；在手动设置优先级方式下，依然优先满足实时型应用的资源需求，将实时型应用容器的优先级设置为指定值的两倍，完成新增容器操作；
S2.3.7：每3秒获取一次所有运行中的批处理型应用容器的CPU利用率，并查询其在无竞争状态下运行时的平均CPU利用率，对比两个值，如果其差值超过100%，则认为可能出现了资源竞争情况，接下来每秒监测一次实时CPU利用率值，总共监测3次，如果每次差值都超过100%，则确定处于资源竞争状态；
S2.3.8：当运行实时型应用容器后，以10秒作为一个时间阶段获取实时型应用容器的平均响应时间，设置调控梯度为6毫秒，8.5毫秒，9.5毫秒，13毫秒四级；处于6毫秒和8.5毫秒调控梯度时，CPU份额的调控粒度为512，处于9.5毫秒调控梯度时，CPU份额的调控粒度为1024，处于13毫秒调控梯度时，CPU份额的首次调控粒度为2048，第二次为1024，当处于6毫秒梯度时减少CPU份额，其他梯度时都增大CPU份额；每次调整CPU份额，都即时更新容器实例状态表中指定容器的CPU份额值；
S2.3.9：当用户提交推荐应用容器请求时，根据当前节点资源使用情况，推荐可运行的应用容器，减少与现有运行时容器的资源竞争的同时，充分利用空闲资源，提高整体资源利用率；针对CPU资源，通过此时系统是否处于资源竞争状态来判断资源使用状态，当系统处于资源竞争状态时，认为CPU资源已经处于竞争状态；内存资源和I/O资源都认为是空闲资源；查询应用容器运行特征表，找到偏重使用空闲资源，且竞争资源需求小的应用，并经过增加容器实例算法判断可以增加后，向用户推荐运行该应用容器。
以下结合具体实施例阐述本发明提供的针对典型应用的Docker动态调度算法；实例中采用的是动态调度方式；其中，系统内存大小为16GB，CPU为8核16线程。
如图2所示，是实施例中采用动态调度方式下增加应用容器算法的示例图；其中，用户需要新增的应用容器为一个Memcached容器，采用默认优先级方式；
本实施例提供的动态调度方式下的增加应用容器算法，具体如下：
（1）实施例中，用户需要增加的应用容器为Memcached容器，依次判断系统剩余资源是否满足需要增加的应用容器需求；
（2）首先从数据表中读取指定应用的实例个数限制值，例如此时Memcached容器的限制数为4，而当前系统上正在运行的Memcached容器数小于4，则可以进行下一步增加检查；
（3）查询该应用容器的类型、最小CPU需求、和最大内存需求。判断当前物理机上可用内存资源是否能够满足新增应用容器的最大内存需求；例如此时Memcached容器的类型为实时型应用容器，最小CPU需求为400%，最大内存需求为2GB，而此时系统的可用CPU资源为1600%，可用内存资源为16GB，因此系统可用资源能够满足容器需求，则可以进行优先级设置；设置优先级，例如此时用户请求中采用默认优先级设置方式，而Memcached容器为实时型应用容器，则设置优先级为2；
上述步骤（1）（2）（3）对应图2中所指示的流程；
（4）重复步骤（1）～（3），直到处理完成用户全部的增加容器请求，依次完成增加Memcached容器、和两个Parsec容器；
（5）获取一次中所有运行的批处理型应用容器的CPU利用率，并查询其在无竞争状态下运行时的平均CPU利用率，对比两个值，如果其差值超过100%，则认为可能出现了资源竞争情况，进入步骤（6），否则每隔3秒执行一次步骤（5）；
（6）每秒监测一次实时CPU利用率值，总共监测3次，如果每次差值都超过100%，则确定处于资源竞争状态，否则，重新执行步骤（5）；
上述步骤（5）（6）对应图3中所指示的流程；
（7）当运行实时型应用容器后，一次获取10秒的实时型应用容器平均响应时间；
（8）平均响应时间小于6毫秒的次数大于3时，将容器的CPU份额减少512，当大于5时，将容器的CPU份额再减少512；平均响应时间大于8.5毫秒且小于9.5毫秒的次数大于3时，将容器的CPU份额增加512，当大于5时，将容器的CPU份额再增加512；平均响应时间大于9.5毫秒且小于13毫秒的次数大于3时，将容器的CPU份额增加1024，当大于5时，将容器的CPU份额再增加1024；平均响应时间大于13毫秒的次数大于3时，将容器的CPU份额增加2048，当大于5时，将容器的CPU份额再增加1024；
（9）每次调整CPU份额，都即时更新容器实例状态表中，重新进入步骤（8）；
上述步骤（7）～（9）对应图4中所指示的流程；
实施例中，采用动态调度算法，相比于一般的Docker资源管理策略，可以针对应用容器运行状态以及系统资源使用状态，来实时动态调整容器的资源配置。确保每个应用容器的运行性能满足SLA协议要求，同时在有限的资源情况下，最大化系统整体资源利用率。当同时运行实时型和批处理型应用容器时，根据实时型应用容器的服务强度变化，来及时调整资源配置，在优先保证实时型应用的服务性能满足SLA协议要求的同时，保障批处理型应用容器性能。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。