CN115686830A - 边缘计算资源弹性调度方法及系统 - Google Patents
边缘计算资源弹性调度方法及系统 Download PDFInfo
- Publication number
- CN115686830A CN115686830A CN202211240008.6A CN202211240008A CN115686830A CN 115686830 A CN115686830 A CN 115686830A CN 202211240008 A CN202211240008 A CN 202211240008A CN 115686830 A CN115686830 A CN 115686830A
- Authority
- CN
- China
- Prior art keywords
- container
- resource
- resources
- module
- application
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Computer And Data Communications (AREA)
Abstract
本发明提供了一种边缘计算资源弹性调度方法及系统，包括：步骤S1：评估当前终端设备，将数据发送到边缘服务器集群上；步骤S2：边缘服务器集接收到数据后，创建基于容器的应用，同时监控应用指标，对应用指标数据进行分析预测，做出弹性决策；步骤S3：弹性决策模块感知到工作负载的变化，要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；步骤S4：边缘计算服务器集群计算完成，将结果返回给终端设备，当接收到终端设备发送的任务量减少后，减少当前该应用的数量。本发明可以加强边缘计算节点之间的协作；相邻的边缘计算服务器之间可以协作进行缓存和计算。
Description
技术领域
本发明涉及边缘计算技术领域，具体地，涉及一种边缘计算资源弹性调度方法及系统。
背景技术
随着边缘智能设备性能的不断提高、以及处在网络边缘的基础网络设备广泛部署，基于“靠近感知数据源处理数据”的理念，学术界和产业界提出了新型的边缘计算范型。边缘计算实现了物联网技术前所未有的连接性、集中化和智能化，全方位使能和赋能智能资产、智能网络、智能系统和智能服务，是实现分布式自治、工业控制自动化的重要支撑。
边缘计算作为一种融合分布式边缘环境中计算、存储、通信资源的开放性平台，实现对云计算中心和核心网络的纵向扩容，对当今的计算模式带来深刻的变革，具体体现为计算节点从同构趋于异构、资源模式从隔离趋于融合、以及任务调度从孤立趋于协同。通过协作机制，不仅可以有效提高计算、存储和网络资源的利用效率，还可以极大地改善网络的服务质量和用户的体验。边缘计算主要采用分布式的方式部署，而且每个边缘计算节点具有一定的计算、存储能力，为连接到该节点的终端提供相应服务。当某节点数据和计算量突然增大时，会出现节点超载等问题，或者流量、计算分布不均，某一节点有较大处理压力而相邻节点大量计算存储资源闲置的问题。这种情况下，单独增加某一节点的计算存储能力或临时配置新增服务器并不能完全解决问题，而对单一节点进行负载均衡的方案虽然可以保证单一节点不会超载，但是会对网络的性能产生影响，尤其在时延和计算性能方面。
因此，面向协作机制的边缘计算资源管理是一个重要的研究方向。资源管理技术是边缘计算中的关键技术之一，主要解决边缘计算系统中计算、存储和网络资源的管理和优化问题。传统的云计算系统在资源管理与优化方面已经有了大量的研究工作。然而，随着边缘终端设备规模的持续增长、边缘网络拓扑的动态化加剧、以及应用的智能化与多样化特征，如何在高度动态的拓扑和资源状态下实现边缘资源的协同优化配置和弹性管理仍然面临许多难点亟须攻克。
基于虚拟化技术的边缘计算平台的关键特性之一是弹性，即能够根据工作负载需求的变化动态调整已分配资源的能力。基于虚拟化技术，硬件集群资源进行了抽象化，工作环境的复杂性得以隐藏，这使得在同一台服务器上运行多个操作系统或者多个应用程序成为可能。弹性允许系统动态添加和删除资源以适应工作负载变化，是基于虚拟化技术的计算平台的动态属性，这里的资源可以是CPU、内存等服务器硬件资源，也可以是虚拟机、容器的个数。当前弹性解决方案在不同的策略、方法和技术上构建了不同的机制，根据配置、范围、目的、策略可以进行不同的分类。
资源弹性伸缩技术实现的第一种方案是基于阈值的静态伸缩，弹性云计算大多仅仅使用基于阈值的规则提供reactive的自动伸缩。这种方法是预先设定一个阈值，当系统状态到达这个阈值时，就会触发自动伸缩的功能。这种方法比较简单，但对于客户来说很有吸引力。它的缺点是：一是为应用设定一个阈值需要对应用负载的趋势有一个很深的认识；二是在面对突发的负载时，这种方法的时效性比较低，反应比较慢。基于阈值的规则一般会设定最少两个规则，一个用来扩容，一个用来缩容。第二种方案是基于控制理论的弹性伸缩，控制变量u(例如虚拟机或容器的数量)是目标系统的输入，受控变量y(如CPU负载)是目标系统的输出。控制器通过调整控制变量u来保持受控变量y接近期望的值或者预先设定的值。为了实现这个目的，就要构建输入与输出之间的模型，它决定了输入如何影响输出的值。
在云计算集中式服务架构中，研究者针对多个云中心的协作调度和资源调度的负载均衡问题展开了比较多的研究，基于对计算任务特征刻画和网络性能感知，实现资源的高效协同分配。由于边缘环境中的计算、存储、通信资源具有高度的动态性和异构性，并且大量的计算任务针对瓶颈资源存在竞争关系，有研究者分别从边缘设备移动性、多样性网络接入、多任务资源竞争的角度研究边缘环境中的资源优化分配和计算任务调度机制。有研究者将由存在依赖关系的任务构成的应用(将任务视作定点，依赖关系视作有向边，从而构成有向无环图)在边缘集群上进行调度，主要解决不违背应用处理时限要求下的最小化能量开销的优化问题，并提出了一个基于任务复制的启发式算法来获得一个有效的决策。启发式算法首先为应用的每个任务分配了一个任务处理时限，然后基于这个任务处理时限对每个任务的调度进行优化。
边缘计算面向的是局部网络，相对云计算而言，用户量和业务量通常不会很大，因此，为了避免资源的闲置和浪费，部署在边缘节点的计算、存储和网络资源相对有限。然而，由于网络的随机性和突发性的用户数量和业务量突然爆发性增大时，边缘计算中有限的计算、存储和网络资源可能无法满足用户和业务需求，从而造成时延增大、网络服务不稳定，用户体验质量差等问题。而且随着边缘终端设备规模的持续增长以及应用的智能化与多样化特征，如何在高度动态的资源状态下实现边缘资源的协同优化配置和服务的可靠性保证仍然面临许多难点亟须攻克。
专利文献CN109788046B(申请号：CN201811637049.2)公开了一种基于改进蜂群算法的多策略边缘计算资源调度方法，主要体现在：第一，改进蜂群算法充分发挥边缘计算平台弹性扩展的优势；第二，采用两级更新的优选调度方式，先通过各候选边缘节点服务器的自扩展与替换，实现候选边缘节点服务器的一级更新；再通过系统随机扩展方式，实现候选边缘节点服务器的二级更新，及时填补候选边缘节点服务器集合中的空缺；第三，改进蜂群算法思想的引入。但该发明不可以使相邻的边缘计算服务器之间协作进行缓存和计算。
发明内容
针对现有技术中的缺陷，本发明的目的是提供一种边缘计算资源弹性调度方法及系统。
根据本发明提供的一种边缘计算资源弹性调度方法，包括：
步骤S1：评估当前终端设备，将数据发送到边缘服务器集群上；
步骤S2：边缘服务器集群接收到数据后，创建基于容器的应用，同时监控应用指标，对应用指标数据进行分析预测，做出弹性决策；
步骤S3：边缘服务器集群的弹性决策模块感知到工作负载的变化，要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
步骤S4：边缘计算服务器集群计算完成，将结果返回给终端设备，当接收到终端设备发送的任务量减少后，减少当前该应用的数量。
优选地，在所述步骤S1中：
当终端设备上有新的应用执行任务时，终端设备上的任务决策模块评估当前终端设备的电量、计算能力，做出在本地进行计算还是发送到边缘计算服务器集群上计算的决定；如果需要发送到边缘服务器集群，通过网络传输模块将数据发送到边缘服务器集群。
优选地，在所述步骤S2中：
边缘服务器集接收到终端设备发送过来的数据后，开始创建基于容器的应用，同时监控应用的关键指标，弹性决策模块获取应用的指标数据进行分析预测，做出弹性决策；
采用自回归综合移动平均模型和BP神经网络进行资源需求预测，计算预期的弹性资源或容器数量，资源需求预测分析具体流程如下：
步骤S2.1：通过监测软件获取相应的监测指标数据，包含应用响应时间，形成时间序列；
步骤S2.2：统计终端设备发送过来的任务请求量，使用ARIMA对请求量趋势进行预测，换算成资源请求量以及资源使用优先级；
步骤S2.3：以监测的实时指标数据、期望的资源请求量、期望的应用响应时间为输入，以需要运行的或容器数量为输出，构建BP神经网络预测模型；
步骤S2.4：根据BP神经网络的预测结果，获得需要伸缩的或容器数量。
优选地，获得需要伸缩的容器数量后，对边缘服务器集群中的资源进行动态伸缩管理；
计算资源动态伸缩的实现过程：
步骤A1：根据BP神经网络的预测结果，获得需要伸缩的容器数量；
步骤A2：判断需要伸缩的容器数量，若数量大于0，则表示资源需要扩展，转步骤A3；若数量小于0，则表示资源需要收缩，转步骤A8；若数量等于0，则表示资源无需伸缩，结束本次资源动态伸缩调整；
步骤A3：通过资源监控获取可用的资源，形成可用资源队列；可用资源队列有两个：高优先级队列和低优先级队列，存储了处于关机状态的容器的服务器节点并且此节点的可用资源能够满足一个容器重新运行所必须的资源条件，则此节点中可用资源属于响应优先级高的可用资源，形成高优先级可用资源队列；其他的可用服务器节点资源形成低优先级可用资源队列；
步骤A4：针对需要新增加运行的容器进行资源配给，根据应用运行优先级在可用资源队列中寻找满足条件的边缘服务器节点，对于需要优先运行的应用首先在高优先级队列中查找匹配可用资源的服务器节点，其次再查找低优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；对于不需要优先运行的应用首先在低优先级队列中查找匹配可用资源的服务器节点，其次再查找高优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；
步骤A5：资源匹配成功后，如果匹配到处于关机状态的容器资源，则重启容器，否则创建容器并部署运行它；
步骤A6：对新增加运行的容器进行资源监控，抽取相应的监控指标数据；
步骤A7：需要伸缩的容器数量减1，返回步骤A2；
步骤A8：获取全部处于运行状态的容器，选定待缩减的容器进行锁定，不再执行新的任务请求；
步骤A9：判断选定的容器是否满足关机条件，如果本容器的任务还没有执行完，则等待预设时间后再判断是否满足关机条件，直到满足预设条件为止；
步骤A10：对满足关机条件的容器，判断容器中运行的应用优先级，如果应用优先级高并且当前可用资源中没有处于关机状态的容器，则执行关机操作，否则执行销毁容器的操作；
步骤A11：资源回收，需要伸缩的容器数量加1，返回步骤A2。
优选地，在所述步骤S3中：
如果终端设备发送的任务量增高幅度大于预设值，弹性决策模块感知到工作负载的变化后，就会要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
在所述步骤S4中：
边缘计算服务器集群计算完成之后，通过网络传输模块将结果返回给终端设备，当接收到终端设备发送的任务量减少后，弹性模块减少当前该应用的数量。
根据本发明提供的一种边缘计算资源弹性调度系统，包括：
模块M1：评估当前终端设备，将数据发送到边缘服务器集群上；
模块M2：边缘服务器集群接收到数据后，创建基于容器的应用，同时监控应用指标，对应用指标数据进行分析预测，做出弹性决策；
模块M3：边缘服务器集群的弹性决策模块感知到工作负载的变化，要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
模块M4：边缘计算服务器集群计算完成，将结果返回给终端设备，当接收到终端设备发送的任务量减少后，减少当前该应用的数量。
优选地，在所述模块M1中：
当终端设备上有新的应用执行任务时，终端设备上的任务决策模块评估当前终端设备的电量、计算能力，做出在本地进行计算还是发送到边缘计算服务器集群上计算的决定；如果需要发送到边缘服务器集群，通过网络传输模块将数据发送到边缘服务器集群。
优选地，在所述模块M2中：
边缘服务器集接收到终端设备发送过来的数据后，开始创建基于容器的应用，同时监控应用的关键指标，弹性决策模块获取应用的指标数据进行分析预测，做出弹性决策；
采用自回归综合移动平均模型和BP神经网络进行资源需求预测，计算预期的弹性资源或容器数量，资源需求预测分析具体流程如下：
模块M2.1：通过监测软件获取相应的监测指标数据，包含应用响应时间，形成时间序列；
模块M2.2：统计终端设备发送过来的任务请求量，使用ARIMA对请求量趋势进行预测，换算成资源请求量以及资源使用优先级；
模块M2.3：以监测的实时指标数据、期望的资源请求量、期望的应用响应时间为输入，以需要运行的或容器数量为输出，构建BP神经网络预测模型；
模块M2.4：根据BP神经网络的预测结果，获得需要伸缩的或容器数量。
优选地，获得需要伸缩的容器数量后，对边缘服务器集群中的资源进行动态伸缩管理；
计算资源动态伸缩的实现过程：
模块B1：根据BP神经网络的预测结果，获得需要伸缩的容器数量；
模块B2：判断需要伸缩的容器数量，若数量大于0，则表示资源需要扩展，转模块B3；若数量小于0，则表示资源需要收缩，转模块B8；若数量等于0，则表示资源无需伸缩，结束本次资源动态伸缩调整；
模块B3：通过资源监控获取可用的资源，形成可用资源队列；可用资源队列有两个：高优先级队列和低优先级队列，存储了处于关机状态的容器的服务器节点并且此节点的可用资源能够满足一个容器重新运行所必须的资源条件，则此节点中可用资源属于响应优先级高的可用资源，形成高优先级可用资源队列；其他的可用服务器节点资源形成低优先级可用资源队列；
模块B4：针对需要新增加运行的容器进行资源配给，根据应用运行优先级在可用资源队列中寻找满足条件的边缘服务器节点，对于需要优先运行的应用首先在高优先级队列中查找匹配可用资源的服务器节点，其次再查找低优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；对于不需要优先运行的应用首先在低优先级队列中查找匹配可用资源的服务器节点，其次再查找高优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；
模块B5：资源匹配成功后，如果匹配到处于关机状态的容器资源，则重启容器，否则创建容器并部署运行它；
模块B6：对新增加运行的容器进行资源监控，抽取相应的监控指标数据；
模块B7：需要伸缩的容器数量减1，返回模块B2；
模块B8：获取全部处于运行状态的容器，选定待缩减的容器进行锁定，不再执行新的任务请求；
模块B9：判断选定的容器是否满足关机条件，如果本容器的任务还没有执行完，则等待预设时间后再判断是否满足关机条件，直到满足预设条件为止；
模块B10：对满足关机条件的容器，判断容器中运行的应用优先级，如果应用优先级高并且当前可用资源中没有处于关机状态的容器，则执行关机操作，否则执行销毁容器的操作；
模块B11：资源回收，需要伸缩的容器数量加1，返回模块B2。
优选地，在所述模块M3中：
如果终端设备发送的任务量增高幅度大于预设值，弹性决策模块感知到工作负载的变化后，就会要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
在所述模块M4中：
边缘计算服务器集群计算完成之后，通过网络传输模块将结果返回给终端设备，当接收到终端设备发送的任务量减少后，弹性模块减少当前该应用的数量。
与现有技术相比，本发明具有如下的有益效果：
1、本发明基于边缘计算分布式的部署方式，可以加强边缘计算节点之间的协作；相邻的边缘计算服务器之间可以协作进行缓存和计算，当本地边缘计算服务器没有相应缓存内容或计算资源紧张时，可以调用其他空闲边缘计算服务器的资源；
2、在边缘计算分布式的部署环境下，本发明能够针对能耗、计算、通信资源瓶颈，同时考虑任务精确度和完成时间需求，实现边缘计算资源在边缘节点上的弹性伸缩、协同调度。
附图说明
通过阅读参照以下附图对非限制性实施例所作的详细描述，本发明的其它特征、目的和优点将会变得更明显：
图1为边缘计算资源弹性调度整体架构；
图2为资源需求预测分析；
图3为资源动态伸缩实现过程。
具体实施方式
下面结合具体实施例对本发明进行详细说明。以下实施例将有助于本领域的技术人员进一步理解本发明，但不以任何形式限制本发明。应当指出的是，对本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变化和改进。这些都属于本发明的保护范围。
实施例1：
本发明主要面向云边端复杂多变的环境，充分考虑边缘节点性能受限和突然失效所导致的服务响应时间滞后问题，基于边缘资源状态感知，提出一种边缘计算资源的弹性保证机理，依据在资源受限条件下的按需分配模型，提高资源利用效率，保证服务的可靠性并提升服务质量。
根据本发明提供的一种边缘计算资源弹性调度方法，如图1-图3所示，包括：
步骤S1：评估当前终端设备，将数据发送到边缘服务器集群上；
优选地，在所述步骤S1中：
当终端设备上有新的应用执行任务时，终端设备上的任务决策模块评估当前终端设备的电量、计算能力，做出在本地进行计算还是发送到边缘计算服务器集群上计算的决定；如果需要发送到边缘服务器集群，通过网络传输模块将数据发送到边缘服务器集群。
步骤S2：边缘服务器集群接收到数据后，创建基于容器的应用，同时监控应用指标，对应用指标数据进行分析预测，做出弹性决策；
优选地，在所述步骤S2中：
边缘服务器集接收到终端设备发送过来的数据后，开始创建基于容器的应用，同时监控应用的关键指标，弹性决策模块获取应用的指标数据进行分析预测，做出弹性决策；
采用自回归综合移动平均模型和BP神经网络进行资源需求预测，计算预期的弹性资源或容器数量，资源需求预测分析具体流程如下：
步骤S2.1：通过监测软件获取相应的监测指标数据，包含应用响应时间，形成时间序列；
步骤S2.2：统计终端设备发送过来的任务请求量，使用ARIMA对请求量趋势进行预测，换算成资源请求量以及资源使用优先级；
步骤S2.3：以监测的实时指标数据、期望的资源请求量、期望的应用响应时间为输入，以需要运行的或容器数量为输出，构建BP神经网络预测模型；
步骤S2.4：根据BP神经网络的预测结果，获得需要伸缩的或容器数量。
优选地，获得需要伸缩的容器数量后，对边缘服务器集群中的资源进行动态伸缩管理；
计算资源动态伸缩的实现过程：
步骤A1：根据BP神经网络的预测结果，获得需要伸缩的容器数量；
步骤A2：判断需要伸缩的容器数量，若数量大于0，则表示资源需要扩展，转步骤A3；若数量小于0，则表示资源需要收缩，转步骤A8；若数量等于0，则表示资源无需伸缩，结束本次资源动态伸缩调整；
步骤A3：通过资源监控获取可用的资源，形成可用资源队列；可用资源队列有两个：高优先级队列和低优先级队列，存储了处于关机状态的容器的服务器节点并且此节点的可用资源能够满足一个容器重新运行所必须的资源条件，则此节点中可用资源属于响应优先级高的可用资源，形成高优先级可用资源队列；其他的可用服务器节点资源形成低优先级可用资源队列；
步骤A4：针对需要新增加运行的容器进行资源配给，根据应用运行优先级在可用资源队列中寻找满足条件的边缘服务器节点，对于需要优先运行的应用首先在高优先级队列中查找匹配可用资源的服务器节点，其次再查找低优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；对于不需要优先运行的应用首先在低优先级队列中查找匹配可用资源的服务器节点，其次再查找高优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；
步骤A5：资源匹配成功后，如果匹配到处于关机状态的容器资源，则重启容器，否则创建容器并部署运行它；
步骤A6：对新增加运行的容器进行资源监控，抽取相应的监控指标数据；
步骤A7：需要伸缩的容器数量减1，返回步骤A2；
步骤A8：获取全部处于运行状态的容器，选定待缩减的容器进行锁定，不再执行新的任务请求；
步骤A9：判断选定的容器是否满足关机条件，如果本容器的任务还没有执行完，则等待预设时间后再判断是否满足关机条件，直到满足预设条件为止；
步骤A10：对满足关机条件的容器，判断容器中运行的应用优先级，如果应用优先级高并且当前可用资源中没有处于关机状态的容器，则执行关机操作，否则执行销毁容器的操作；
步骤A11：资源回收，需要伸缩的容器数量加1，返回步骤A2。
步骤S3：边缘服务器集群的弹性决策模块感知到工作负载的变化，要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
优选地，在所述步骤S3中：
如果终端设备发送的任务量增高幅度大于预设值，弹性决策模块感知到工作负载的变化后，就会要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
步骤S4：边缘计算服务器集群计算完成，将结果返回给终端设备，当接收到终端设备发送的任务量减少后，减少当前该应用的数量。
在所述步骤S4中：
边缘计算服务器集群计算完成之后，通过网络传输模块将结果返回给终端设备，当接收到终端设备发送的任务量减少后，弹性模块减少当前该应用的数量。
根据本发明提供的一种边缘计算资源弹性调度系统，包括：
模块M1：评估当前终端设备，将数据发送到边缘服务器集群上；
优选地，在所述模块M1中：
当终端设备上有新的应用执行任务时，终端设备上的任务决策模块评估当前终端设备的电量、计算能力，做出在本地进行计算还是发送到边缘计算服务器集群上计算的决定；如果需要发送到边缘服务器集群，通过网络传输模块将数据发送到边缘服务器集群。
模块M2：边缘服务器集群接收到数据后，创建基于容器的应用，同时监控应用指标，对应用指标数据进行分析预测，做出弹性决策；
优选地，在所述模块M2中：
边缘服务器集接收到终端设备发送过来的数据后，开始创建基于容器的应用，同时监控应用的关键指标，弹性决策模块获取应用的指标数据进行分析预测，做出弹性决策；
采用自回归综合移动平均模型和BP神经网络进行资源需求预测，计算预期的弹性资源或容器数量，资源需求预测分析具体流程如下：
模块M2.1：通过监测软件获取相应的监测指标数据，包含应用响应时间，形成时间序列；
模块M2.2：统计终端设备发送过来的任务请求量，使用ARIMA对请求量趋势进行预测，换算成资源请求量以及资源使用优先级；
模块M2.3：以监测的实时指标数据、期望的资源请求量、期望的应用响应时间为输入，以需要运行的或容器数量为输出，构建BP神经网络预测模型；
模块M2.4：根据BP神经网络的预测结果，获得需要伸缩的或容器数量。
优选地，获得需要伸缩的容器数量后，对边缘服务器集群中的资源进行动态伸缩管理；
计算资源动态伸缩的实现过程：
模块B1：根据BP神经网络的预测结果，获得需要伸缩的容器数量；
模块B2：判断需要伸缩的容器数量，若数量大于0，则表示资源需要扩展，转模块B3；若数量小于0，则表示资源需要收缩，转模块B8；若数量等于0，则表示资源无需伸缩，结束本次资源动态伸缩调整；
模块B3：通过资源监控获取可用的资源，形成可用资源队列；可用资源队列有两个：高优先级队列和低优先级队列，存储了处于关机状态的容器的服务器节点并且此节点的可用资源能够满足一个容器重新运行所必须的资源条件，则此节点中可用资源属于响应优先级高的可用资源，形成高优先级可用资源队列；其他的可用服务器节点资源形成低优先级可用资源队列；
模块B4：针对需要新增加运行的容器进行资源配给，根据应用运行优先级在可用资源队列中寻找满足条件的边缘服务器节点，对于需要优先运行的应用首先在高优先级队列中查找匹配可用资源的服务器节点，其次再查找低优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；对于不需要优先运行的应用首先在低优先级队列中查找匹配可用资源的服务器节点，其次再查找高优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；
模块B5：资源匹配成功后，如果匹配到处于关机状态的容器资源，则重启容器，否则创建容器并部署运行它；
模块B6：对新增加运行的容器进行资源监控，抽取相应的监控指标数据；
模块B7：需要伸缩的容器数量减1，返回模块B2；
模块B8：获取全部处于运行状态的容器，选定待缩减的容器进行锁定，不再执行新的任务请求；
模块B9：判断选定的容器是否满足关机条件，如果本容器的任务还没有执行完，则等待预设时间后再判断是否满足关机条件，直到满足预设条件为止；
模块B10：对满足关机条件的容器，判断容器中运行的应用优先级，如果应用优先级高并且当前可用资源中没有处于关机状态的容器，则执行关机操作，否则执行销毁容器的操作；
模块B11：资源回收，需要伸缩的容器数量加1，返回模块B2。
模块M3：边缘服务器集群的弹性决策模块感知到工作负载的变化，要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
优选地，在所述模块M3中：
如果终端设备发送的任务量增高幅度大于预设值，弹性决策模块感知到工作负载的变化后，就会要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
模块M4：边缘计算服务器集群计算完成，将结果返回给终端设备，当接收到终端设备发送的任务量减少后，减少当前该应用的数量。
在所述模块M4中：
边缘计算服务器集群计算完成之后，通过网络传输模块将结果返回给终端设备，当接收到终端设备发送的任务量减少后，弹性模块减少当前该应用的数量。
实施例2：
实施例2为实施例1的优选例，以更为具体地对本发明进行说明。
一般的边缘计算框架包括由终端设备、边缘服务器节点和边缘工作节点三部分组成，如图1所示。边缘服务器节点主要包括镜像管理、资源监控、弹性决策和容器调度等功能；工作节点完成应用镜像管理、资源监控管理等功能，将应用的指标数据反馈到服务器节点。之后，边缘服务器节点根据工作节点上的应用指标信息，可以做出弹性决策。终端设备上一般有各式各样的终端应用、任务决策和本地执行等功能模块。
边缘计算资源弹性伸缩的整个过程如下：
(1)当终端设备上有新的应用执行任务时，终端设备上的任务决策模块会评估当前终端设备的电量、计算能力，做出在本地进行计算还是发送到边缘计算服务器集群上计算的决定。如果需要发送到边缘服务器集群，就会通过网络传输模块将数据发送到边缘服务器集群上。
(2)边缘服务器集接收到终端设备发送过来的数据后，就会开始创建基于容器的应用，同时监控应用的关键指标。弹性决策模块会获取应用的指标数据进行分析预测，做出弹性决策。
(3)如果终端设备发送的任务量大幅度增高，弹性决策模块感知到工作负载的变化后，就会要求创建新的应用。创建的新容器会根据设定的容器调度方式，决定容器是否需要调度其他可用节点上运行。例如，图像识别应用是需要带有GPU的边缘服务器集群节点处理的，因此需要将应用调度到该节点上运行。
(4)边缘计算服务器集群计算完成之后，就会通过网络传输模块将结果返回给终端设备。当接收到终端设备发送的任务量减少后，弹性模块会减少当前该应用的数量，空出边缘计算服务器集群的资源以供其他应用使用。
对于不同应用的指标可以有不同的弹性伸缩策略，但在边缘服务器集群上实现边缘计算资源弹性伸缩一般分为四个步骤：资源监控、预测分析、弹性伸缩和容器调度。
(1)资源监控：拉取应用的自定义指标进行存储。自定义的指标一般主要包括应用的请求量、CPU利用率、内存利用率、Pods的数量、响应时间等信息。
(2)预测分析：从资源监控模块获取应用的自定义指标数据进行分析，包括预测未来工作负载，计算预期的弹性资源或容器数量等功能。
(3)弹性伸缩：边缘服务器集群控制器根据预测分析的结果，实现资源弹性伸缩决策，增加资源或减少资源。
(4)容器调度：根据调度策略指定容器最终调度的物理节点位置。
边缘服务器集接收到终端设备发送过来的任务需求后会进行资源需求预测分析，本发明采用自回归综合移动平均模型(ARIMA)和BP神经网络进行资源需求预测，计算预期的弹性资源或容器数量。资源需求预测分析具体流程如下图2所示。
(1)通过监测软件获取相应的监测指标数据，包含应用响应时间，形成时间序列。
(2)统计终端设备发送过来的任务请求量，使用ARIMA对请求量趋势进行预测，换算成资源请求量以及资源使用优先级。
(3)以监测的实时指标数据、期望的资源请求量、期望的应用响应时间为输入，以需要运行的Pods数量(或容器数量)为输出，构建BP神经网络预测模型。
(4)根据BP神经网络的预测结果，获得需要伸缩的Pods数量(或容器数量)。
获得需要伸缩的Pods数量(或容器数量)后，就可以对边缘服务器集群中的资源进行动态伸缩管理。计算资源动态伸缩需要考虑如下问题：
(1)弹性伸缩策略。系统级性能参数的弹性伸缩，包括cpu使用率、内存使用率、虚拟内存页面交换率等；业务级别的性能参数的弹性伸缩，包括tcp连接数、http连接数、数据库连接数等。除了支持系统性能参数、业务性能参数弹性伸缩外，还支持监测应用是否健康来进行弹性伸缩。例如通过http/https心跳消息进行检测，发送约定次数的http/https消息均无响应时，则认为是业务系统节点已经宕机，需要进行相应处理。首先重启容器，若重启容器后，该业务系统节点还是宕机，则弹性生成一个业务节点，同时添加至虚拟负载均衡集群中，以接收新的业务服务请求。
(2)延时关机。弹性收缩容器时，为减少对已经建立会话的业务影响，需要支持延时关机。边缘服务器集群控制器收到减少集群成员时，不是马上将该成员移出集群，而是继续处理已经存在的会话，但是此时不再处理新的会话，等待一段时间后，再执行移出集群，执行关机或销毁容器。
(3)动态伸缩模式。计算资源的动态伸缩模式可主要分为资源节约优先模式和伸缩时间优先模式两种：资源节约优先模式和伸缩时间优先模式。a)资源节约优先模式。计算资源扩展时，通过容器镜像创建新容器并加入资源池。由于需要重新创建容器并安装部署和传送相关的数据，时间上不占优势。计算资源收缩时，不提供服务的容器都进行销毁，回收全部资源，资源可以得到最大程度的利用。b)伸缩时间优先模式。该方式总是保存弹性伸缩组(集群)最大容量的容器数量，即使该容器没有提供服务，此时只是将该容器关闭。容器关闭时，存储空间小能进行回收(CPU、内存可以回收重新利用)。由于容器未激活时仅只处于关闭状态，在需要新增活动容器进计算资源池中时，只需要重新启动即可，所以该方式在伸缩时间效率上具有较大的优势。
基于以上考虑，计算资源动态伸缩的实现过程如图3所示。(1)根据BP神经网络的预测结果，获得需要伸缩的Pods数量(或容器数量)。
(2)判断需要伸缩的Pods数量(或容器数量)，若数量大于0，则表示资源需要扩展，转步骤(3)；若数量小于0，则表示资源需要收缩，转步骤(8)；若数量等于0，则表示资源无需伸缩，结束本次资源动态伸缩调整。
(3)通过资源监控获取可用的资源，形成可用资源队列。可用资源队列有两个：高优先级队列和低优先级队列。存储了处于关机状态的Pod(或容器)的服务器节点并且此节点的可用资源能够满足一个Pod(或容器)重新运行所必须的资源条件，则此节点中可用资源属于响应优先级高的可用资源，形成高优先级可用资源队列。其他的可用服务器节点资源形成低优先级可用资源队列。
(4)针对需要新增加运行的Pod或容器进行资源配给，根据应用运行优先级在可用资源队列中寻找满足条件的边缘服务器节点。对于需要优先运行的应用(或优先响应运行)首先在高优先级队列中查找匹配可用资源的服务器节点，其次再查找低优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；对于不需要优先运行的应用首先在低优先级队列中查找匹配可用资源的服务器节点，其次再查找高优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作。
(5)资源匹配成功后，如果匹配到处于关机状态的Pod或容器资源，则重启Pod或容器，否则创建Pod或容器并部署运行它。
(6)对新增加运行的Pod或容器进行资源监控，抽取相应的监控指标数据。
(7)需要伸缩的Pods数量(或容器数量)减1，返回步骤(2)。
(8)获取全部处于运行状态的Pod(或容器)，选定待缩减的Pod(或容器)进行锁定，不再执行新的任务请求。
(9)判断选定的Pod(或容器)是否满足关机条件，如果本Pod(或容器)的任务还没有执行完，则等待一段时间后再判断是否满足关机条件，直到满足条件为止。
(10)对满足关机条件的Pod(或容器)，判断Pod(或容器)中运行的应用优先级，如果应用优先级高并且当前可用资源中没有处于关机状态的Pod(或容器)，则执行关机操作，否则执行删除Pod或销毁容器的操作。
(11)资源回收，需要伸缩的Pods数量(或容器数量)加1，返回步骤(2)。
实施例3：
实施例3为实施例1的优选例，以更为具体地对本发明进行说明。
本发明的实现实例如下。
通过K3S+Prometheus+Docker容器构建边缘计算分布式集群环境。用Docker实现轻量级容器系统，运行相关的业务应用，由K3S的资源对象实现Docker容器的编排，通过Prometheus监控方案监控边缘计算集群节点和应用状态。弹性伸缩模块的设计基于K3S的Pod水平自动伸缩机制。
(1)针对应用的需求，将应用的关键指标映射为不同类型的度量指标。编写完成的应用代码通过Dockerfile制作成应用镜像。当该应用运行时，应用的度量指标会暴露给监控模块，这样监控模块就可以采集到应用的自定义指标。
(2)运行Prometheus收集相关的监控指标，包括自定义的指标，例如应用的请求量、CPU利用率、内存利用率、Pods的数量、响应时间等信息，形成时间序列。
(3)统计终端设备发送过来的任务请求量，使用ARIMA算法对请求量趋势进行预测，换算成资源请求量以及资源使用优先级。
(4)构建BP神经网络预测模型，根据BP神经网络的预测结果，获得需要伸缩的Pods数量。
(5)通过K3S中默认的HPA控制器，结合本发明提出的计算资源动态伸缩过程实现应用Pod数量的水平弹性伸缩。
本领域技术人员知道，除了以纯计算机可读程序代码方式实现本发明提供的系统、装置及其各个模块以外，完全可以通过将方法步骤进行逻辑编程来使得本发明提供的系统、装置及其各个模块以逻辑门、开关、专用集成电路、可编程逻辑控制器以及嵌入式微控制器等的形式来实现相同程序。所以，本发明提供的系统、装置及其各个模块可以被认为是一种硬件部件，而对其内包括的用于实现各种程序的模块也可以视为硬件部件内的结构；也可以将用于实现各种功能的模块视为既可以是实现方法的软件程序又可以是硬件部件内的结构。
以上对本发明的具体实施例进行了描述。需要理解的是，本发明并不局限于上述特定实施方式，本领域技术人员可以在权利要求的范围内做出各种变化或修改，这并不影响本发明的实质内容。在不冲突的情况下，本申请的实施例和实施例中的特征可以任意相互组合。
Claims (10)
1.一种边缘计算资源弹性调度方法，其特征在于，包括：
步骤S1：评估当前终端设备，将数据发送到边缘服务器集群上；
步骤S2：边缘服务器集群接收到数据后，创建基于容器的应用，同时监控应用指标，对应用指标数据进行分析预测，做出弹性决策；
步骤S3：边缘服务器集群的弹性决策模块感知到工作负载的变化，要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
步骤S4：边缘计算服务器集群计算完成，将结果返回给终端设备，当接收到终端设备发送的任务量减少后，减少当前该应用的数量。
2.根据权利要求1所述的边缘计算资源弹性调度方法，其特征在于，在所述步骤S1中：
当终端设备上有新的应用执行任务时，终端设备上的任务决策模块评估当前终端设备的电量、计算能力，做出在本地进行计算还是发送到边缘计算服务器集群上计算的决定；如果需要发送到边缘服务器集群，通过网络传输模块将数据发送到边缘服务器集群。
3.根据权利要求1所述的边缘计算资源弹性调度方法，其特征在于，在所述步骤S2中：
边缘服务器集接收到终端设备发送过来的数据后，开始创建基于容器的应用，同时监控应用的关键指标，弹性决策模块获取应用的指标数据进行分析预测，做出弹性决策；
采用自回归综合移动平均模型和BP神经网络进行资源需求预测，计算预期的弹性资源或容器数量，资源需求预测分析具体流程如下：
步骤S2.1：通过监测软件获取相应的监测指标数据，包含应用响应时间，形成时间序列；
步骤S2.2：统计终端设备发送过来的任务请求量，使用ARIMA对请求量趋势进行预测，换算成资源请求量以及资源使用优先级；
步骤S2.3：以监测的实时指标数据、期望的资源请求量、期望的应用响应时间为输入，以需要运行的或容器数量为输出，构建BP神经网络预测模型；
步骤S2.4：根据BP神经网络的预测结果，获得需要伸缩的或容器数量。
4.根据权利要求3所述的边缘计算资源弹性调度方法，其特征在于：
获得需要伸缩的容器数量后，对边缘服务器集群中的资源进行动态伸缩管理；
计算资源动态伸缩的实现过程：
步骤A1：根据BP神经网络的预测结果，获得需要伸缩的容器数量；
步骤A2：判断需要伸缩的容器数量，若数量大于0，则表示资源需要扩展，转步骤A3；若数量小于0，则表示资源需要收缩，转步骤A8；若数量等于0，则表示资源无需伸缩，结束本次资源动态伸缩调整；
步骤A3：通过资源监控获取可用的资源，形成可用资源队列；可用资源队列有两个：高优先级队列和低优先级队列，存储了处于关机状态的容器的服务器节点并且此节点的可用资源能够满足一个容器重新运行所必须的资源条件，则此节点中可用资源属于响应优先级高的可用资源，形成高优先级可用资源队列；其他的可用服务器节点资源形成低优先级可用资源队列；
步骤A4：针对需要新增加运行的容器进行资源配给，根据应用运行优先级在可用资源队列中寻找满足条件的边缘服务器节点，对于需要优先运行的应用首先在高优先级队列中查找匹配可用资源的服务器节点，其次再查找低优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；对于不需要优先运行的应用首先在低优先级队列中查找匹配可用资源的服务器节点，其次再查找高优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；
步骤A5：资源匹配成功后，如果匹配到处于关机状态的容器资源，则重启容器，否则创建容器并部署运行它；
步骤A6：对新增加运行的容器进行资源监控，抽取相应的监控指标数据；
步骤A7：需要伸缩的容器数量减1，返回步骤A2；
步骤A8：获取全部处于运行状态的容器，选定待缩减的容器进行锁定，不再执行新的任务请求；
步骤A9：判断选定的容器是否满足关机条件，如果本容器的任务还没有执行完，则等待预设时间后再判断是否满足关机条件，直到满足预设条件为止；
步骤A10：对满足关机条件的容器，判断容器中运行的应用优先级，如果应用优先级高并且当前可用资源中没有处于关机状态的容器，则执行关机操作，否则执行销毁容器的操作；
步骤A11：资源回收，需要伸缩的容器数量加1，返回步骤A2。
5.根据权利要求1所述的边缘计算资源弹性调度方法，其特征在于：
在所述步骤S3中：
如果终端设备发送的任务量增高幅度大于预设值，弹性决策模块感知到工作负载的变化后，就会要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
在所述步骤S4中：
边缘计算服务器集群计算完成之后，通过网络传输模块将结果返回给终端设备，当接收到终端设备发送的任务量减少后，弹性模块减少当前该应用的数量。
6.一种边缘计算资源弹性调度系统，其特征在于，包括：
模块M1：评估当前终端设备，将数据发送到边缘服务器集群上；
模块M2：边缘服务器集群接收到数据后，创建基于容器的应用，同时监控应用指标，对应用指标数据进行分析预测，做出弹性决策；
模块M3：边缘服务器集群的弹性决策模块感知到工作负载的变化，要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
模块M4：边缘计算服务器集群计算完成，将结果返回给终端设备，当接收到终端设备发送的任务量减少后，减少当前该应用的数量。
7.根据权利要求6所述的边缘计算资源弹性调度系统，其特征在于，在所述模块M1中：
当终端设备上有新的应用执行任务时，终端设备上的任务决策模块评估当前终端设备的电量、计算能力，做出在本地进行计算还是发送到边缘计算服务器集群上计算的决定；如果需要发送到边缘服务器集群，通过网络传输模块将数据发送到边缘服务器集群。
8.根据权利要求6所述的边缘计算资源弹性调度系统，其特征在于，在所述模块M2中：
边缘服务器集接收到终端设备发送过来的数据后，开始创建基于容器的应用，同时监控应用的关键指标，弹性决策模块获取应用的指标数据进行分析预测，做出弹性决策；
采用自回归综合移动平均模型和BP神经网络进行资源需求预测，计算预期的弹性资源或容器数量，资源需求预测分析具体流程如下：
模块M2.1：通过监测软件获取相应的监测指标数据，包含应用响应时间，形成时间序列；
模块M2.2：统计终端设备发送过来的任务请求量，使用ARIMA对请求量趋势进行预测，换算成资源请求量以及资源使用优先级；
模块M2.3：以监测的实时指标数据、期望的资源请求量、期望的应用响应时间为输入，以需要运行的或容器数量为输出，构建BP神经网络预测模型；
模块M2.4：根据BP神经网络的预测结果，获得需要伸缩的或容器数量。
9.根据权利要求8所述的边缘计算资源弹性调度系统，其特征在于：
获得需要伸缩的容器数量后，对边缘服务器集群中的资源进行动态伸缩管理；
计算资源动态伸缩的实现过程：
模块B1：根据BP神经网络的预测结果，获得需要伸缩的容器数量；
模块B2：判断需要伸缩的容器数量，若数量大于0，则表示资源需要扩展，转模块B3；若数量小于0，则表示资源需要收缩，转模块B8；若数量等于0，则表示资源无需伸缩，结束本次资源动态伸缩调整；
模块B3：通过资源监控获取可用的资源，形成可用资源队列；可用资源队列有两个：高优先级队列和低优先级队列，存储了处于关机状态的容器的服务器节点并且此节点的可用资源能够满足一个容器重新运行所必须的资源条件，则此节点中可用资源属于响应优先级高的可用资源，形成高优先级可用资源队列；其他的可用服务器节点资源形成低优先级可用资源队列；
模块B4：针对需要新增加运行的容器进行资源配给，根据应用运行优先级在可用资源队列中寻找满足条件的边缘服务器节点，对于需要优先运行的应用首先在高优先级队列中查找匹配可用资源的服务器节点，其次再查找低优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；对于不需要优先运行的应用首先在低优先级队列中查找匹配可用资源的服务器节点，其次再查找高优先级队列中可用资源的服务器节点，如果都没有找到匹配的可用资源的服务器节点，则提示无可用的匹配资源，结束本次资源伸缩操作；
模块B5：资源匹配成功后，如果匹配到处于关机状态的容器资源，则重启容器，否则创建容器并部署运行它；
模块B6：对新增加运行的容器进行资源监控，抽取相应的监控指标数据；
模块B7：需要伸缩的容器数量减1，返回模块B2；
模块B8：获取全部处于运行状态的容器，选定待缩减的容器进行锁定，不再执行新的任务请求；
模块B9：判断选定的容器是否满足关机条件，如果本容器的任务还没有执行完，则等待预设时间后再判断是否满足关机条件，直到满足预设条件为止；
模块B10：对满足关机条件的容器，判断容器中运行的应用优先级，如果应用优先级高并且当前可用资源中没有处于关机状态的容器，则执行关机操作，否则执行销毁容器的操作；
模块B11：资源回收，需要伸缩的容器数量加1，返回模块B2。
10.根据权利要求6所述的边缘计算资源弹性调度系统，其特征在于：
在所述模块M3中：
如果终端设备发送的任务量增高幅度大于预设值，弹性决策模块感知到工作负载的变化后，就会要求创建新的应用，创建的新容器根据预设的容器调度方式，决定容器是否需要调度其他可用节点上运行；
在所述模块M4中：
边缘计算服务器集群计算完成之后，通过网络传输模块将结果返回给终端设备，当接收到终端设备发送的任务量减少后，弹性模块减少当前该应用的数量。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211240008.6A CN115686830A (zh) | 2022-10-11 | 2022-10-11 | 边缘计算资源弹性调度方法及系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211240008.6A CN115686830A (zh) | 2022-10-11 | 2022-10-11 | 边缘计算资源弹性调度方法及系统 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115686830A true CN115686830A (zh) | 2023-02-03 |
Family
ID=85064431
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211240008.6A Pending CN115686830A (zh) | 2022-10-11 | 2022-10-11 | 边缘计算资源弹性调度方法及系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115686830A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117539439A (zh) * | 2024-01-09 | 2024-02-09 | 北京腾达泰源科技有限公司 | 轻量实时应用开发方法、装置、设备及存储介质 |
-
2022
- 2022-10-11 CN CN202211240008.6A patent/CN115686830A/zh active Pending
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN117539439A (zh) * | 2024-01-09 | 2024-02-09 | 北京腾达泰源科技有限公司 | 轻量实时应用开发方法、装置、设备及存储介质 |
| CN117539439B (zh) * | 2024-01-09 | 2024-04-09 | 北京腾达泰源科技有限公司 | 轻量实时应用开发方法、装置、设备及存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Han et al. | Tailored learning-based scheduling for kubernetes-oriented edge-cloud system | |
| Askarizade Haghighi et al. | An energy-efficient dynamic resource management approach based on clustering and meta-heuristic algorithms in cloud computing IaaS platforms: Energy efficient dynamic cloud resource management | |
| CN104317658B (zh) | 一种基于MapReduce的负载自适应任务调度方法 | |
| CN109324875B (zh) | 一种基于强化学习的数据中心服务器功耗管理与优化方法 | |
| CN104657221A (zh) | 一种云计算中基于任务分类的多队列错峰调度模型及方法 | |
| Liu et al. | A survey on virtual machine scheduling in cloud computing | |
| Arkian et al. | Model-based stream processing auto-scaling in geo-distributed environments | |
| Zhu et al. | A self-adapting task scheduling algorithm for container cloud using learning automata | |
| Liu et al. | An adaptive online scheme for scheduling and resource enforcement in storm | |
| Rolik et al. | Dynamie management of data center resources using reinforcement learning | |
| CN112214301A (zh) | 面向智慧城市基于用户偏好的动态计算迁移方法及装置 | |
| CN115686830A (zh) | 边缘计算资源弹性调度方法及系统 | |
| He et al. | Energy-efficient framework for virtual machine consolidation in cloud data centers | |
| AlOrbani et al. | Load balancing and resource allocation in smart cities using reinforcement learning | |
| Masoumzadeh et al. | A cooperative multi agent learning approach to manage physical host nodes for dynamic consolidation of virtual machines | |
| Zikos et al. | The impact of service demand variability on resource allocation strategies in a grid system | |
| CN114637586A (zh) | 一种数据驱动的在线预测和实现k8s资源超售的方法 | |
| CN113014649B (zh) | 一种基于深度学习的云物联负载均衡方法、装置及设备 | |
| US20240004707A1 (en) | Methods and systems for energy-efficient scheduling of periodic tasks on a group of processing devices | |
| Singh et al. | Load balancing algorithms with the application of machine learning: a review | |
| Meddeber et al. | Tasks assignment for Grid computing | |
| Salimian et al. | Energy-efficient placement of virtual machines in cloud data centres based on fuzzy decision making | |
| CN115562812A (zh) | 面向机器学习训练的分布式虚拟机调度方法、装置和系统 | |
| Surya et al. | Novel Approaches for Resource Management Across Edge Servers | |
| Kortas et al. | Performance impact of the MVMM algorithm for virtual machine migration in data centres |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |