CN112199178A - 一种基于轻量化容器的云服务动态调度方法及系统 - Google Patents
一种基于轻量化容器的云服务动态调度方法及系统 Download PDFInfo
- Publication number
- CN112199178A CN112199178A CN202011134587.7A CN202011134587A CN112199178A CN 112199178 A CN112199178 A CN 112199178A CN 202011134587 A CN202011134587 A CN 202011134587A CN 112199178 A CN112199178 A CN 112199178A
- Authority
- CN
- China
- Prior art keywords
- container
- node
- plan
- computing node
- state
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开一种基于轻量化容器的云服务动态调度方法及系统,方法包括:当各计算节点不为离线状态时,主节点根据用户发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案;与预案中的ip相同的计算节点利用自身的docker服务创建容器;当容器创建成功且启动成功时,则说明容器服务正常,此时用户访问服务正常容器内的服务;本发明利用docker创建容器,不需要进行硬件虚拟及运行完整操作系统等额外开销,因此提高了系统资源的利用率;另外基于docker服务创建容器,由于直接运行于宿主内核,无需启动完整的操作系统,因此会大大节约开发、测试部署的时间。
Description
技术领域
本发明涉及资源调度技术领域,特别是涉及一种基于轻量化容器的云服务动态调度方法及系统。
背景技术
Docker和虚拟化技术的兴起,解决了服务的一次创建和部署,可以在任意地方运行,具有更快速的启动时间和更高的资源利用效率,对于现有IT基础架构产生了重大影响,促进了Paas和DevOps等领域的发展。
目前,各种云平台的部署环境和服务所适配的环境主要针对x86平台,但是在JS领域,随着国产化融合需求的提出,对基于各种国产芯片、CPU和操作系统环境的统一融合的云服务的需求迫在眉睫,并且由于各种服务部署在完全不同的异构软、硬件环境上,对所部署多实例服务的故障恢复和异构计算节点的自动故障处理的要求很高,因此,亟需研究一种能够针对异构国产硬件环境的资源动态调度方法十分必要。
发明内容
基于此,本发明的目的是提供一种基于轻量化容器的云服务动态调度方法及系统,以提高资源的利用率。
为实现上述目的,本发明提供了一种基于轻量化容器的云服务动态调度方法,所述方法包括:
步骤S1:主节点根据各计算节点收集的状态信息判断各计算节点是否为离线状态;如果各计算节点为离线状态,则主节点不给离线状态的计算节点分配任务;如果各计算节点不为离线状态,则执行“步骤S2”;
步骤S2:主节点根据用户发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案;
步骤S3:各计算节点判断预案中的ip是否与自身的ip相同;如果相同,则执行“步骤S4”;如果不相同,则各计算节点无需操作;
步骤S4:计算节点利用自身的docker服务创建容器,并判断容器是否创建成功;如果容器创建失败,则执行“步骤S6”;如果容器创建成功,则执行步骤S5;
步骤S5:判断容器是否启动成功;如果容器启动成功,则说明容器服务正常;如果容器启动失败,则执行“步骤S7”;
步骤S6:计算节点记录创建失败次数,并判断创建失败次数是否大于或等于设定创建失败次数;如果创建失败次数大于或等于设定创建失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果创建失败次数小于设定创建失败次数,则返回“步骤S4”;
步骤S7:计算节点记录重启失败次数,并判断重启失败次数是否大于或等于设定重启失败次数;如果重启失败次数大于或等于设定重启失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果重启失败次数小于设定失败次数,则增加重启延时时间,并根据所述重启延时时间重新启动容器,并返回“步骤S5”;
步骤S8:主节点检测到预案为“重新部署”状态时,则返回“步骤S2”;
步骤S9:用户访问服务正常容器内的服务。
可选地,所述方法还包括:
当计算节点监测到上一次生成的预案被覆盖后,则计算节点删除根据上一次预案对应的容器。
可选地,所述主节点和所述计算节点分别部署在不同的机器上。
可选地,步骤S1具体包括:
步骤S11:各计算节点收集状态信息,并将状态信息定时上报给主节点;所述状态信息包括计算节点的CPU、内存和品牌;
步骤S12:主节点根据收集的各计算节点对应的状态信息进行更新内存;
步骤S13:主节点根据内存的状态信息对所有计算节点进行筛选,判断各计算节点是否大于设定时间没有更新状态信息;如果各计算节点大于设定时间没有更新状态信息,则将大于设定时间没有更新状态信息的各计算节点标记为离线状态,主节点在分配任务时,不给离线状态的计算节点分配任务;否则执行步骤S2。
可选地,步骤S2具体包括:
步骤S21:主节点接收到用户发出的任务部署请求时,按照任务需求对所有正常状态的计算节点进行筛选和计算,选取资源占用率最低的计算节点;所述任务需求包括所需CPU、内存、硬盘大小以及硬件架构;
步骤S22:主节点根据任务需求和筛选后的计算节点生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
可选地,所述方法还包括:
当主节点接收到计算节点上传异常状态时,主节点不给异常状态的计算节点分配任务,同时返回“步骤S2”。
本发明还提供一种基于轻量化容器的云服务动态调度系统,所述系统包括:
第一判断模块,用于主节点根据各计算节点收集的状态信息判断各计算节点是否为离线状态;如果各计算节点为离线状态,则主节点不给离线状态的计算节点分配任务;如果各计算节点不为离线状态,则执行“预案生成模块”;
预案生成模块,用于主节点根据用户发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案;
第二判断模块,用于各计算节点判断预案中的ip是否与自身的ip相同;如果相同,则执行“第三判断模块”;如果不相同,则各计算节点无需操作;
第三判断模块,用于计算节点利用自身的docker服务创建容器,并判断容器是否创建成功;如果容器创建失败,则执行“第五判断模块”;如果容器创建成功,则执行“第四判断模块”;
第四判断模块,用于判断容器是否启动成功;如果容器启动成功,则说明容器服务正常;如果容器启动失败,则执行“第六判断模块”;
第五判断模块,用于计算节点记录创建失败次数,并判断创建失败次数是否大于或等于设定创建失败次数;如果创建失败次数大于或等于设定创建失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果创建失败次数小于设定创建失败次数,则返回“第三判断模块”;
第六判断模块,用于计算节点记录重启失败次数,并判断重启失败次数是否大于或等于设定重启失败次数;如果重启失败次数大于或等于设定重启失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果重启失败次数小于设定失败次数,则增加重启延时时间,并根据所述重启延时时间重新启动容器,并返回“第四判断模块”;
返回模块,用于主节点检测到预案为“重新部署”状态时,则返回“预案生成模块”;
访问模块,用于用户访问服务正常容器内的服务。
可选地,所述系统还包括:
删除模块,用于当计算节点监测到上一次生成的预案被覆盖后,则计算节点删除根据上一次预案对应的容器。
可选地,所述第一判断模块,具体包括:
信息上报单元,用于各计算节点收集状态信息,并将状态信息定时上报给主节点;所述状态信息包括计算节点的CPU、内存和品牌;
内存更新单元,用于主节点根据收集的各计算节点对应的状态信息进行更新内存;
筛选单元,用于主节点根据内存的状态信息对所有计算节点进行筛选,判断各计算节点是否大于设定时间没有更新状态信息;如果各计算节点大于设定时间没有更新状态信息,则将大于设定时间没有更新状态信息的各计算节点标记为离线状态,主节点在分配任务时,不给离线状态的计算节点分配任务;否则执行“预案生成模块”。
可选地,所述预案生成模块,具体包括:
选取单元,用于主节点接收到用户发出的任务部署请求时,按照任务需求对所有正常状态的计算节点进行筛选和计算,选取资源占用率最低的计算节点;所述任务需求包括所需CPU、内存、硬盘大小以及硬件架构;
预案生成单元,用于主节点根据任务需求和筛选后的计算节点生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
根据本发明提供的具体实施例,本发明公开了以下技术效果:
本发明公开一种基于轻量化容器的云服务动态调度方法及系统,方法包括:当各计算节点不为离线状态时,主节点根据用户发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案;与预案中的ip相同的计算节点利用自身的docker服务创建容器;当容器创建成功且启动成功时,则说明容器服务正常,此时用户访问服务正常容器内的服务;本发明利用docker创建容器,不需要进行硬件虚拟及运行完整操作系统等额外开销,因此提高了系统资源的利用率;另外基于docker服务创建容器,由于直接运行于宿主内核,无需启动完整的操作系统,因此会大大节约开发、测试部署的时间。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本发明实施例集群逻辑时序图;
图2为本发明实施例任务分发时序图;
图3为本发明实施例容器异常迁移流程时序图;
图4为本发明实施例主机异常迁移时序图;
图5为本发明实施例基于轻量化容器的云服务动态调度系统结构图;
图6为本发明实施例某公司应用资源访问权限控制服务部署界面;
图7为本发明实施例某公司应用资源访问权限控制部署流程界面;
图8为本发明实施例某公司应用资源访问控制权限部署完成访问图;
图9为本发明实施例某公司应用机器故障前容器的部署情况图;
图10为本发明实施例某公司应用机器故障并迁移完成后容器的部署情况图;
图11为本发明实施例其他上云服务实例图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明的目的是提供一种基于轻量化容器的云服务动态调度方法及系统,以提高资源的利用率。
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。
如图1-4所示,系统集群分为主节点和计算节点,分别部署在不同的机器上,一个集群共用同一个etcd数据库,因此基于主节点和计算节点提供一种基于轻量化容器的云服务动态调度方法,所述方法包括:
步骤S1:主节点根据各计算节点收集的状态信息判断各计算节点是否为离线状态;如果各计算节点为离线状态,则主节点不给离线状态的计算节点分配任务;如果各计算节点不为离线状态,则执行“步骤S2”。
步骤S2:主节点根据用户user发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
步骤S3:各计算节点判断预案中的ip是否与自身的ip相同;如果相同,则执行“步骤S4”;如果不相同,则各计算节点无需操作。
步骤S4:计算节点利用自身的docker服务创建容器,并判断容器是否创建成功;如果容器创建失败,则执行“步骤S6”;如果容器创建成功,则执行步骤S5。
步骤S5:判断容器是否启动成功;如果容器启动成功,则说明容器服务正常;如果容器启动失败,则执行“步骤S7”。
步骤S6:计算节点记录创建失败次数,并判断创建失败次数是否大于或等于设定创建失败次数;如果创建失败次数大于或等于设定创建失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果创建失败次数小于设定创建失败次数,则返回“步骤S4”。
步骤S7:计算节点记录重启失败次数,并判断重启失败次数是否大于或等于设定重启失败次数;如果重启失败次数大于或等于设定重启失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果重启失败次数小于设定失败次数,则增加重启延时时间,并根据所述重启延时时间重新启动容器,并返回“步骤S5”。
步骤S8:主节点检测到预案为“重新部署”状态时,则返回“步骤S2”。
步骤S9:用户访问服务正常容器内的服务。
下面对各个步骤进行详细论述:
本发明所述方法还包括:
当计算节点监测到上一次生成的预案被覆盖后,则计算节点删除根据上一次预案对应的容器。
本发明步骤S1具体包括:
步骤S11:各计算节点收集状态信息,并将状态信息定时上报给主节点;所述状态信息包括计算节点的CPU、内存和品牌。
步骤S12:主节点根据收集的各计算节点对应的状态信息进行更新内存。
步骤S13:主节点根据内存的状态信息对所有计算节点进行筛选,判断各计算节点是否大于设定时间没有更新状态信息;如果各计算节点大于设定时间没有更新状态信息,则将大于设定时间没有更新状态信息的各计算节点标记为离线状态,主节点在分配任务时,不给离线状态的计算节点分配任务;否则执行步骤S2。
如图2所示,本发明步骤S2具体包括:
步骤S21:主节点接收到用户发出的任务部署请求时,按照任务需求对所有正常状态的计算节点进行筛选和计算,在最低限度是满足任务需求的基础上,选取资源占用率最低的计算节点;所述任务需求包括所需CPU、内存、硬盘大小以及硬件架构。
步骤S22:主节点根据任务需求和筛选后的计算节点生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
本发明所述方法还包括:
当主节点接收到计算节点上传异常状态时,主节点不给异常状态的计算节点分配任务,同时返回“步骤S2”。
具体的,如附图4所示,当计算节点状态异常时,主节点将会将计算节点上所有的任务状态改为“重新部署”,并将这些任务全部进入任务分发子线程,返回“步骤S2”重新生成部署预案。当以上新部署预案生成完成后,系统会删除原任务,计算节点监控到该子任务被删除的事件后,将删除部署在自身上的对应的容器。
本发明的目的是基于各种异构国产硬件环境,通过轻量化容器和云平台技术对异构资源的统一管理、统一调度,实现了软件服务的容器化部署。针对不同国产硬件环境可能出现的不同的异常情况,通过自研故障检测和恢复系统,对容器和集群出现的各种故障进行及时发现并自动化处理,最大限度的保障服务的稳定运行。
本发明将服务容器化与传统的虚拟化以及直接部署具有以下优势:
1、更高效的利用系统资源;由于容器不需要进行硬件虚拟及运行完整操作系统等额外开销,docker对系统资源的利用率更高。
2、更快速的启动时间,基于docker容器的应用,由于直接运行于宿主内核,无需启动完整的操作系统,因此会大大节约开发、测试部署的时间。
3、一致的运行环境,docker的镜像提供了除内核外的完整的运行时环境,确保了应用运行环境的一致性。
4、持续交付和部署,使用docker可以通过定制应用镜像来实现持续集成、交付和部署。
5、由于docker确保了执行环境的一致性,使得应用的迁移更加容易。
6、微服务架构实践,使用容器技术可以更充分的应用系统资源、快速启动的特性,可以实现近乎实时的面向海量用户负载进行精准的应用调度,因此迅速广泛的对应用进行微服务化改造。
7、容器技术安全;容器技术由内核的命名空间和控制组机制提供的容器内在安全;内核安全性的加强机制对容器安全性的影响,要包括保护宿主不受容器内部运行进程的入侵、防止容器之间互相破坏。
如图5所示,本发明还提供一种基于轻量化容器的云服务动态调度系统,所述系统包括:
第一判断模块1,用于主节点根据各计算节点收集的状态信息判断各计算节点是否为离线状态;如果各计算节点为离线状态,则主节点不给离线状态的计算节点分配任务;如果各计算节点不为离线状态,则执行“预案生成模块”。
预案生成模块2,用于主节点根据用户发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
第二判断模块3,用于各计算节点判断预案中的ip是否与自身的ip相同;如果相同,则执行“第三判断模块”;如果不相同,则各计算节点无需操作。
第三判断模块4,用于计算节点利用自身的docker服务创建容器,并判断容器是否创建成功;如果容器创建失败,则执行“第五判断模块”;如果容器创建成功,则执行“第四判断模块”。
第四判断模块5,用于判断容器是否启动成功;如果容器启动成功,则说明容器服务正常;如果容器启动失败,则执行“第六判断模块”。
第五判断模块6,用于计算节点记录创建失败次数,并判断创建失败次数是否大于或等于设定创建失败次数;如果创建失败次数大于或等于设定创建失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果创建失败次数小于设定创建失败次数,则返回“第三判断模块”。
第六判断模块7,用于计算节点记录重启失败次数,并判断重启失败次数是否大于或等于设定重启失败次数;如果重启失败次数大于或等于设定重启失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果重启失败次数小于设定失败次数,则增加重启延时时间,并根据所述重启延时时间重新启动容器,并返回“第四判断模块”。
返回模块8,用于主节点检测到预案为“重新部署”状态时,则返回“预案生成模块”。
访问模块9,用于用户访问服务正常容器内的服务。
作为一种实施方式,本发明所述系统还包括:
删除模块,用于当计算节点监测到上一次生成的预案被覆盖后,则计算节点删除根据上一次预案对应的容器。
作为一种实施方式,本发明所述第一判断模块1,具体包括:
信息上报单元,用于各计算节点收集状态信息,并将状态信息定时上报给主节点;所述状态信息包括计算节点的CPU、内存和品牌。
内存更新单元,用于主节点根据收集的各计算节点对应的状态信息进行更新内存。
筛选单元,用于主节点根据内存的状态信息对所有计算节点进行筛选,判断各计算节点是否大于设定时间没有更新状态信息;如果各计算节点大于设定时间没有更新状态信息,则将大于设定时间没有更新状态信息的各计算节点标记为离线状态,主节点在分配任务时,不给离线状态的计算节点分配任务;否则执行“预案生成模块”。
作为一种实施方式,本发明所述预案生成模块2,具体包括:
选取单元,用于主节点接收到用户发出的任务部署请求时,按照任务需求对所有正常状态的计算节点进行筛选和计算,选取资源占用率最低的计算节点;所述任务需求包括所需CPU、内存、硬盘大小以及硬件架构。
预案生成单元,用于主节点根据任务需求和筛选后的计算节点生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
以下以实际案例说明,当使用docker创建容器进行服务的一键式部署,所带来的部署效率的提升。
以某公司提供的应用资源访问权限控制服务的部署过程来说明。要在国产集群上部署这套服务,必须要部署应用服务器(如tomcat、金蝶等)、缓存和数据库服务,并且要部署集群或几个服务时,必须将整个部署流程重新走一遍,并且很难迁移和启动流程都比较复杂,具体不再赘述。
当使用容器化部署服务后,首先将该服务部署所需的镜像打包成基础镜像,再通过一次性的资源编排服务,可以对服务进行一次性部署,用户在部署时,如附图6,只需要自主选择要部署的机器类型、部署的容器实例数、服务运行的应用服务器、缓存和数据库类型,平台就可以对所有依赖进行打包,并一键化部署。整个部署流程如附图7,部署完成后,用户可以自由的启动、停止和删除服务。
仍然以上一部分的应用资源访问权限控制为例,当按照上一部分对服务进行部署完成后,点击服务链接,如附图8,发现服务可以进入服务首页并正常访问,此时进入后台,如附图9发现容器部署在192.168.11.15的飞腾服务器上,将192.168.11.15服务器关闭或断网,此时该服务立刻变为不可访问,约30秒后(可配置),系统发现该机器下线,立刻对该容器进行自动迁移处理,如附图10,服务容器被自动迁移到192.168.11.16机器上,当服务状态变为“服务正常”后,服务又恢复可正常访问状态。
本发明的云平台已经适配了基于多种国产机型(如飞腾、龙芯、申威、华芯等)、多种国产服务器(如金蝶、东方通等),如附图11,已经有多家国产软件厂商与云平台对接,均可实现服务的一键化部署和自动化故障恢复和迁移。
以上图6-图11中只是用于显示操作后的界面,里边的文字没有任何意义。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。
本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处。综上所述,本说明书内容不应理解为对本发明的限制。
Claims (10)
1.一种基于轻量化容器的云服务动态调度方法,其特征在于,所述方法包括:
步骤S1:主节点根据各计算节点收集的状态信息判断各计算节点是否为离线状态;如果各计算节点为离线状态,则主节点不给离线状态的计算节点分配任务;如果各计算节点不为离线状态,则执行“步骤S2”;
步骤S2:主节点根据用户发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案;
步骤S3:各计算节点判断预案中的ip是否与自身的ip相同;如果相同,则执行“步骤S4”;如果不相同,则各计算节点无需操作;
步骤S4:计算节点利用自身的docker服务创建容器,并判断容器是否创建成功;如果容器创建失败,则执行“步骤S6”;如果容器创建成功,则执行步骤S5;
步骤S5:判断容器是否启动成功;如果容器启动成功,则说明容器服务正常;如果容器启动失败,则执行“步骤S7”;
步骤S6:计算节点记录创建失败次数,并判断创建失败次数是否大于或等于设定创建失败次数;如果创建失败次数大于或等于设定创建失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果创建失败次数小于设定创建失败次数,则返回“步骤S4”;
步骤S7:计算节点记录重启失败次数,并判断重启失败次数是否大于或等于设定重启失败次数;如果重启失败次数大于或等于设定重启失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果重启失败次数小于设定失败次数,则增加重启延时时间,并根据所述重启延时时间重新启动容器,并返回“步骤S5”;
步骤S8:主节点检测到预案为“重新部署”状态时,则返回“步骤S2”;
步骤S9:用户访问服务正常容器内的服务。
2.根据权利要求1所述的基于轻量化容器的云服务动态调度方法,其特征在于,所述方法还包括:
当计算节点监测到上一次生成的预案被覆盖后,则计算节点删除根据上一次预案对应的容器。
3.根据权利要求1所述的基于轻量化容器的云服务动态调度方法,其特征在于,所述主节点和所述计算节点分别部署在不同的机器上。
4.根据权利要求1所述的基于轻量化容器的云服务动态调度方法,其特征在于,步骤S1具体包括:
步骤S11:各计算节点收集状态信息,并将状态信息定时上报给主节点;所述状态信息包括计算节点的CPU、内存和品牌;
步骤S12:主节点根据收集的各计算节点对应的状态信息进行更新内存;
步骤S13:主节点根据内存的状态信息对所有计算节点进行筛选,判断各计算节点是否大于设定时间没有更新状态信息;如果各计算节点大于设定时间没有更新状态信息,则将大于设定时间没有更新状态信息的各计算节点标记为离线状态,主节点在分配任务时,不给离线状态的计算节点分配任务;否则执行步骤S2。
5.根据权利要求1所述的基于轻量化容器的云服务动态调度方法,其特征在于,步骤S2具体包括:
步骤S21:主节点接收到用户发出的任务部署请求时,按照任务需求对所有正常状态的计算节点进行筛选和计算,选取资源占用率最低的计算节点;所述任务需求包括所需CPU、内存、硬盘大小以及硬件架构;
步骤S22:主节点根据任务需求和筛选后的计算节点生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
6.根据权利要求1所述的基于轻量化容器的云服务动态调度方法,其特征在于,所述方法还包括:
当主节点接收到计算节点上传异常状态时,主节点不给异常状态的计算节点分配任务,同时返回“步骤S2”。
7.一种基于轻量化容器的云服务动态调度系统,其特征在于,所述系统包括:
第一判断模块,用于主节点根据各计算节点收集的状态信息判断各计算节点是否为离线状态;如果各计算节点为离线状态,则主节点不给离线状态的计算节点分配任务;如果各计算节点不为离线状态,则执行“预案生成模块”;
预案生成模块,用于主节点根据用户发出的任务需求生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案;
第二判断模块,用于各计算节点判断预案中的ip是否与自身的ip相同;如果相同,则执行“第三判断模块”;如果不相同,则各计算节点无需操作;
第三判断模块,用于计算节点利用自身的docker服务创建容器,并判断容器是否创建成功;如果容器创建失败,则执行“第五判断模块”;如果容器创建成功,则执行“第四判断模块”;
第四判断模块,用于判断容器是否启动成功;如果容器启动成功,则说明容器服务正常;如果容器启动失败,则执行“第六判断模块”;
第五判断模块,用于计算节点记录创建失败次数,并判断创建失败次数是否大于或等于设定创建失败次数;如果创建失败次数大于或等于设定创建失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果创建失败次数小于设定创建失败次数,则返回“第三判断模块”;
第六判断模块,用于计算节点记录重启失败次数,并判断重启失败次数是否大于或等于设定重启失败次数;如果重启失败次数大于或等于设定重启失败次数,则计算节点将预案改成“重新部署”状态,并写入etcd数据库;如果重启失败次数小于设定失败次数,则增加重启延时时间,并根据所述重启延时时间重新启动容器,并返回“第四判断模块”;
返回模块,用于主节点检测到预案为“重新部署”状态时,则返回“预案生成模块”;
访问模块,用于用户访问服务正常容器内的服务。
8.根据权利要求7所述的基于轻量化容器的云服务动态调度系统,其特征在于,所述系统还包括:
删除模块,用于当计算节点监测到上一次生成的预案被覆盖后,则计算节点删除根据上一次预案对应的容器。
9.根据权利要求7所述的基于轻量化容器的云服务动态调度系统,其特征在于,所述第一判断模块,具体包括:
信息上报单元,用于各计算节点收集状态信息,并将状态信息定时上报给主节点;所述状态信息包括计算节点的CPU、内存和品牌;
内存更新单元,用于主节点根据收集的各计算节点对应的状态信息进行更新内存;
筛选单元,用于主节点根据内存的状态信息对所有计算节点进行筛选,判断各计算节点是否大于设定时间没有更新状态信息;如果各计算节点大于设定时间没有更新状态信息,则将大于设定时间没有更新状态信息的各计算节点标记为离线状态,主节点在分配任务时,不给离线状态的计算节点分配任务;否则执行“预案生成模块”。
10.根据权利要求7所述的基于轻量化容器的云服务动态调度系统,其特征在于,所述预案生成模块,具体包括:
选取单元,用于主节点接收到用户发出的任务部署请求时,按照任务需求对所有正常状态的计算节点进行筛选和计算,选取资源占用率最低的计算节点;所述任务需求包括所需CPU、内存、硬盘大小以及硬件架构;
预案生成单元,用于主节点根据任务需求和筛选后的计算节点生成预案,并将预案写入etcd数据库中,并覆盖上一次生成的预案。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011134587.7A CN112199178B (zh) | 2020-10-21 | 2020-10-21 | 一种基于轻量化容器的云服务动态调度方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011134587.7A CN112199178B (zh) | 2020-10-21 | 2020-10-21 | 一种基于轻量化容器的云服务动态调度方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112199178A true CN112199178A (zh) | 2021-01-08 |
CN112199178B CN112199178B (zh) | 2022-12-16 |
Family
ID=74010552
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011134587.7A Active CN112199178B (zh) | 2020-10-21 | 2020-10-21 | 一种基于轻量化容器的云服务动态调度方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112199178B (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112968897A (zh) * | 2021-02-25 | 2021-06-15 | 浙江清华长三角研究院 | 一种在去中心化系统中运行的容器计算方法 |
CN113641456A (zh) * | 2021-08-18 | 2021-11-12 | 中国联合网络通信集团有限公司 | 数据集群的部署方法、装置及系统 |
CN114003006A (zh) * | 2021-10-19 | 2022-02-01 | 宝鸡钛业股份有限公司 | 一种采用虚拟化智能算法解决进口控制系统限制权限国产化方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103825964A (zh) * | 2014-03-19 | 2014-05-28 | 北京邮电大学 | 一种基于云计算PaaS平台的SLS调度装置和方法 |
CN109885389A (zh) * | 2019-02-19 | 2019-06-14 | 山东浪潮云信息技术有限公司 | 一种基于容器的并行深度学习调度训练方法及系统 |
CN111212116A (zh) * | 2019-12-24 | 2020-05-29 | 湖南舜康信息技术有限公司 | 一种基于容器云的高性能计算集群创建方法和系统 |
-
2020
- 2020-10-21 CN CN202011134587.7A patent/CN112199178B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103825964A (zh) * | 2014-03-19 | 2014-05-28 | 北京邮电大学 | 一种基于云计算PaaS平台的SLS调度装置和方法 |
CN109885389A (zh) * | 2019-02-19 | 2019-06-14 | 山东浪潮云信息技术有限公司 | 一种基于容器的并行深度学习调度训练方法及系统 |
CN111212116A (zh) * | 2019-12-24 | 2020-05-29 | 湖南舜康信息技术有限公司 | 一种基于容器云的高性能计算集群创建方法和系统 |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112968897A (zh) * | 2021-02-25 | 2021-06-15 | 浙江清华长三角研究院 | 一种在去中心化系统中运行的容器计算方法 |
CN113641456A (zh) * | 2021-08-18 | 2021-11-12 | 中国联合网络通信集团有限公司 | 数据集群的部署方法、装置及系统 |
CN113641456B (zh) * | 2021-08-18 | 2023-06-13 | 中国联合网络通信集团有限公司 | 数据集群的部署方法、装置及系统 |
CN114003006A (zh) * | 2021-10-19 | 2022-02-01 | 宝鸡钛业股份有限公司 | 一种采用虚拟化智能算法解决进口控制系统限制权限国产化方法 |
Also Published As
Publication number | Publication date |
---|---|
CN112199178B (zh) | 2022-12-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11226847B2 (en) | Implementing an application manifest in a node-specific manner using an intent-based orchestrator | |
CN112199178B (zh) | 一种基于轻量化容器的云服务动态调度方法及系统 | |
CN111966305B (zh) | 持久卷分配方法、装置、计算机设备和存储介质 | |
US10795781B2 (en) | Recreating a computing environment using tags and snapshots | |
CN111290834B (zh) | 一种基于云管理平台实现业务高可用的方法、装置及设备 | |
CN110377395B (zh) | 一种Kubernetes集群中的Pod迁移方法 | |
US7992032B2 (en) | Cluster system and failover method for cluster system | |
US8230264B2 (en) | System evaluation apparatus | |
US8060792B2 (en) | Monitoring and automated recovery of data instances | |
CN109656742B (zh) | 一种节点异常处理方法、装置及存储介质 | |
CN103414712B (zh) | 一种分布式虚拟桌面管理系统和方法 | |
CN110895487B (zh) | 分布式任务调度系统 | |
CN110895484A (zh) | 任务调度方法及装置 | |
CN102833310B (zh) | 一种基于虚拟化技术的工作流引擎集群系统 | |
CN112667362B (zh) | Kubernetes上部署Kubernetes虚拟机集群的方法与系统 | |
CN110895488B (zh) | 任务调度方法及装置 | |
CN110895483A (zh) | 任务恢复方法及装置 | |
CN110895486B (zh) | 分布式任务调度系统 | |
CN107465709B (zh) | 分布式镜像构建任务方法及装置、系统 | |
CN111343219A (zh) | 计算服务云平台 | |
CN114679380A (zh) | 边缘集群的创建方法和相关装置 | |
CN111984274A (zh) | 一种一键自动化部署etcd集群的方法及装置 | |
CN113535532A (zh) | 故障注入系统、方法和装置 | |
CN110895485A (zh) | 任务调度系统 | |
US8595349B1 (en) | Method and apparatus for passive process monitoring |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |