CN111400036A - 基于服务器集群的云应用管理系统、方法、装置及介质 - Google Patents

Abstract

本申请实施例公开了一种基于服务器集群的云应用管理系统、方法、装置及存储介质。本申请实施例提供的技术方案，通过在服务器上运行应用程序，构建应用管理器以管理对应的应用程序，对用户请求映射信号进行转发和处理，并通过各个应用管理器接收对应应用程序发送的心跳信息，基于心跳信息记录应用程序状态。此外，通过主应用管理器汇总自身及各个从应用管理器的应用程序状态和所归属的服务器业务情况，并实时根据心跳信息的应用程序异常情况或所归属服务器的业务负载告警情况进行应用程序热迁移。采用上述技术手段，可以实现应用程序的灵活管理，保障云应用管理系统的安全性，并借助应用程序热迁移使得各个服务器负载均衡，降低云应用管理成本。

Description

基于服务器集群的云应用管理系统、方法、装置及介质

技术领域

本申请实施例涉及云应用管理技术领域，尤其涉及基于服务器集群的云应用管理系统、方法、装置及介质。

背景技术

云应用是通过终端与云端互动的应用，其通过终端操作同步云端，而占用本地空间也通过云端备份保留终端数据。相较于运行在单一系统环境中的传统软件应用，云应用利用其跨平台特性可以帮助用户大大降低使用成本，并提高工作效率。

目前，比较常见的云应用技术为桌面云，桌面云是基于云平台的一种虚拟桌面应用。其通过在云平台上部署桌面云软件，终端用户可通过瘦客户端或者其他任何与网络相连的设备来访问跨平台应用程序及整个桌面。桌面云提供方将桌面计算机的计算和存储资源(包括CPU、硬盘、内存)集中部署在云计算数据中心机房，通过虚拟化技术将物理资源转化为虚拟资源。并根据用户的需求将虚拟资源集成为不同规格的虚拟机，向用户提供虚拟桌面服务。以此来优化互联网的资源利用及应用管理。

但是，现有的桌面云技术在部署过程中受系统框架限制导致应用程序管理缺乏灵活性，且无法较好的做到负载均衡管理。

发明内容

本申请实施例提供一种基于服务器集群的云应用管理系统、方法、装置及存储介质，能够实现应用程序的灵活管理，保障服务器负载均衡，并提高云应用的安全性。

在第一方面，本申请实施例提供了一种基于服务器集群的云应用管理系统，包括多个服务器，所述服务器用于运行应用程序，并构建应用管理器，所述应用管理器用于管理对应的应用程序，并对用户请求映射信号进行转发和处理；

各个所述应用管理器还实时接收对应应用程序发送的心跳信息，基于所述心跳信息记录应用程序状态；所述服务器包括主服务器和从服务器，所述主服务器构建的应用管理器为主应用管理器，所述从服务器构建的应用管理器为从应用管理器，所述主应用管理器用于汇总自身及各个所述从应用管理器对应的应用程序状态和所归属的服务器业务情况；

所述应用管理器还用于根据所述心跳信息的应用程序异常情况或所归属服务器的业务负载告警情况进行应用程序热迁移。

在第二方面，本申请实施例提供了一种基于服务器集群的云应用管理方法，应用于如本申请实施例第一方面所述的基于服务器集群的云应用管理系统，包括：

各个应用管理器接收对应应用程序发送的一级心跳包，所述一级心跳包包含io吞吐信息、网络流量信息、内存使用信息、用户使用情况和应用程序辨识信息的一种或多种；

各个应用管理器将接收到的所述一级心跳包中的信息写入自身的应用程序状态表，并实时根据新接收的所述一级心跳包更新所述应用程序状态表；

各个应用管理器根据所述应用程序状态表和所归属服务器的业务情况生成二级心跳包，将所述二级心跳包汇总至所述主应用管理器，由所述主应用管理器将所述二级心跳包中的信息写入自身的应用程序状态表。

进一步的，所述各个应用管理器根据所述应用程序状态表和所归属服务器的业务情况生成二级心跳包，还包括：

所述应用管理器提取对应的所述一级心跳包中包含的应用程序正常关闭信息，将所述应用程序正常关闭信息放入对应的二级心跳包中上传，并实时根据主应用管理器的回文从所述应用程序状态表中删除对应应用程序的信息。

进一步的，所述各个应用管理器接收对应应用程序发送的一级心跳包，还包括：

所述应用管理器根据所述一级心跳包确定相应的应用程序异常情况，并基于所述应用程序异常情况执行异常业务调控机制，所述异常业务调控机制根据对应应用程序的用户接入情况、对应应用程序是否瘫痪以及各个所述服务器的业务情况进行对应应用程序的热迁移。

进一步的，还包括：

各个所述应用管理器根据所归属服务器的业务负载告警设定进行对应应用程序的动态调度，通过对应应用程序的热迁移使各个所述服务器负载均衡。

进一步的，各个所述应用管理器根据所归属服务器的业务负载告警设定进行对应应用程序的动态调度，还包括：

所述应用管理器根据所归属服务器的低业务负载告警信息咨询其余服务器的应用管理器进行业务负载分摊或应用程序热迁移，并在应用程序热迁移后进行所归属服务器的关机操作。

进一步的，所述通过对应应用程序的热迁移使各个所述服务器负载均衡，还包括：

所述应用管理器根据所述应用程序状态表计算各个应用程序的迁移难度值和迁移收益值，基于所述迁移难度值和/或所述迁移收益值选取对应的应用程序进行热迁移。

进一步的，还包括：

主应用管理器实时接收用户请求映射信号并根据主服务器和从服务器的业务情况进行转发或处理。

在第三方面，本申请实施例提供了一种基于服务器集群的云应用管理装置，包括：

接收模块，用于通过各个应用管理器接收对应应用程序发送的一级心跳包，所述一级心跳包包含io吞吐信息、网络流量信息、内存使用信息、用户使用情况和应用程序辨识信息的一种或多种；

写入模块，用于通过各个应用管理器将接收到的所述一级心跳包中的信息写入自身的应用程序状态表，并实时根据新接收的所述一级心跳包更新所述应用程序状态表；

汇总模块，用于通过各个应用管理器根据所述应用程序状态表和所归属的服务器业务情况生成二级心跳包，将所述二级心跳包汇总至主应用管理器，由所述主应用管理器将所述二级心跳包中的信息写入自身的应用程序状态表。

在第四方面，本申请实施例提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如第二方面所述的基于服务器集群的云应用管理方法。

本申请实施例通过在服务器上运行应用程序，构建应用管理器以管理对应的应用程序，对用户请求映射信号进行转发和处理，并通过各个应用管理器接收对应应用程序发送的心跳信息，基于心跳信息记录应用程序状态。此外，通过主应用管理器汇总自身及各个从应用管理器的应用程序状态和所归属的服务器业务情况，并实时根据心跳信息的应用程序异常情况或所归属服务器的业务负载告警情况进行应用程序热迁移。采用上述技术手段，可以通过心跳信息实现对应用程序的灵活管理，并借助应用程序热迁移使得各个服务器负载均衡，降低云应用管理成本。

此外，通过实时接收应用程序的心跳信息，实现对各个云应用的全流量监控，进而减少信息泄露风险，保障云应用管理系统的安全性。

附图说明

图1是本申请实施例一提供的一种基于服务器集群的云应用管理系统的心跳信息传输示意图；

图2是本申请实施例一中的一种基于服务器集群的云应用管理方法的流程图；

图3是本申请实施例一中的用户请求映射信号转发示意图；

图4是本申请实施例一中的应用程序热迁移示意图；

图5是本申请实施例二提供的一种基于服务器集群的云应用管理装置的结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面结合附图对本申请具体实施例作进一步的详细描述。可以理解的是，此处所描述的具体实施例仅仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部内容。在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作(或步骤)描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

本申请提供的基于服务器集群的云应用管理系统和方法，旨在通过应用管理器实时接收应用程序信息，并通过应用程序热迁移以实现较好的云应用管理。使得应用管理根据灵活性和安全性，并进一步保障各个服务器负载均衡，降低云应用管理成本，保障系统性能。对于传统的桌面云而言，其应用程序的部署成本相对较高，因此在用户的容纳上具有一定局限性(一般为私有云)。而扩展至公有云部署，则会存在很多的安全问题。并且，目前的桌面云计算中负载均衡的最小管理单位为虚拟机，没有更细的划分，不利于负载均衡管理。此外，桌面云云应用在部署上受限于传统框架导致系统缺乏一定的灵活性，当云应用部署数量过大的时候，单个应用程序的运行情况不能直观的反映给管理员。基于此，提供本申请实施例的基于服务器集群的云应用管理系统和方法，已解决现有云应用管理受限，负载管理不均的技术问题。

实施例一：

本申请实施例一提供了一种基于服务器集群的云应用管理系统，包括多个服务器，所述服务器用于运行应用程序，并构建应用管理器，所述应用管理器用于管理对应的应用程序，并对用户请求映射信号进行转发和处理；各个所述应用管理器还实时接收对应应用程序发送的心跳信息，基于所述心跳信息记录应用程序状态；所述服务器包括主服务器和从服务器，所述主服务器构建的应用管理器为主应用管理器，所述从服务器构建的应用管理器为从应用管理器，所述主应用管理器用于汇总自身及各个所述从应用管理器对应的应用程序状态和所归属的服务器业务情况；所述应用管理器还用于根据所述心跳信息的应用程序异常情况或所归属服务器的业务负载告警情况进行应用程序热迁移。

本申请实施例通过将产品提供方提供的应用程序直接部署在服务器集群中的物理服务器上以供用户使用，而用户与应用程序的映射和管理则通过构建于服务器上应用管理器实现。每一个服务器上均运行了多个相同或者不同提供商提供的应用程序，并将这些应用程序单独映射给不同的设备使用。同时通过各个服务器上构建的应用管理器进行应用管理，心跳信息汇总，而各应用管理器之间的联系也可进行服务器的负载均衡管理。

具体的，本申请实施例通过在服务器上构建应用管理器，应用管理器的主要功能是实现对服务器上的应用程序管理和对用户请求映射信号的转发和管理。应用程序在运行过程中，会向应用管理器发送心跳信息(如应用程序所处状态、io流量和网络流量信息等)，基于心跳信息发送机制对发送和处理心跳信息。并且，为了方便汇总和管理各个应用程序的心跳信息，同时提供用户请求映射信号的处理效率。会选择一个服务器作为主服务器，在主服务器构建主应用管理器，在从服务器构建从应用管理器。主应用管理器根据接收到的用户请求映射信号会下发至主服务器上的应用程序进行处理或者转发至从应用管理器进行下发。而从应用管理器也会基于自身收集到的心跳信息汇总应用程序状态信息和所归属服务器业务情况至主应用管理器。

更具体的，本申请实施例使用心跳信息发送机制进行心跳信息发送。其中，由应用程序向应用管理器发送一级心跳包，定义该发送操作为“一型心跳”。由各个应用管理器向主应用管理器发送二级心跳包，定义该发送操作为“二型心跳”。参照图1，提供云应用管理系统的心跳信息传输示意图。通过“一型心跳”和“二型心跳”，最终实现对应用程序状态和服务器业务情况的灵活管理的实时监控。

进一步的，图2给出了本申请实施例一提供的一种基于服务器集群的云应用管理方法的流程图，本实施例中提供的基于服务器集群的云应用管理方法可以由上述基于服务器集群的云应用管理系统执行，该基于服务器集群的云应用管理系统可以通过软件和/或硬件的方式实现，该基于服务器集群的云应用管理系统可以是两个或多个物理实体构成。下述以该基于服务器集群的云应用管理系统为执行基于服务器集群的云应用管理方法的主体为例，进行描述。参照图2，该基于服务器集群的云应用管理方法具体包括：

S110、各个应用管理器接收对应应用程序发送的一级心跳包，所述一级心跳包包含io吞吐信息、网络流量信息、内存使用信息、用户使用情况和应用程序辨识信息的一种或多种；

S120、各个应用管理器将接收到的所述一级心跳包中的信息写入自身的应用程序状态表，并实时根据新接收的所述一级心跳包更新所述应用程序状态表；

S130、各个应用管理器根据所述应用程序状态表和所归属服务器的业务情况生成二级心跳包，将所述二级心跳包汇总至所述主应用管理器，由所述主应用管理器将所述二级心跳包中的信息写入自身的应用程序状态表。

其中，在“一型心跳”中，正常的心跳包中会包含io吞吐信息、网络流量信息、内存使用信息以及用户使用情况等一系列会影响到业务的信息。在应用程序完成启动后，会实时向其对应的应用管理器发送一级心跳包，第一次发送的一级心跳包还可以包含该应用程序的基本信息(应用程序类型等相关应用程序辨识信息)，以便于应用管理器辨识该应用程序。应用管理器会将接收到的一级心跳包中包含的信息写入到自身的应用程序状态表中，并且在收到新的一级心跳包后更新应用程序状态表。此外，当根据心跳信息发现有应用程序出现故障时，应用管理器则会根据应用程序状态表上的信息来为之后的异常业务调控或应用程序热迁移提供应用程序信息。在二型心跳中，各个应用管理器会定期向主应用管理器发送应用管理器所归属服务器的业务承载情况、业务情况以及应用管理器所属服务器的所有应用程序运行情况，将这些信息打包为二级心跳包，发送至主应用管理器。这些信息将会记录到主应用管理器的应用程序表和主应用管理器上独有的服务器状态表上。同样的，“二型心跳”在第一次发送的二级心跳包中也会包含应用程序的基本信息。

在一些实施例中，所述应用管理器还提取对应的所述一级心跳包中包含的应用程序正常关闭信息，将所述应用程序正常关闭信息放入对应的二级心跳包中上传，并实时根据主应用管理器的回文从所述应用程序状态表中删除对应应用程序的信息。可以理解的是，应用程序将要正常关闭的时候会将应用程序正常关闭信息打包放入一级心跳包。此时如若应用管理器收到了应用程序的心跳包中包含了应用程序正常关闭信息，则会在下一次向主应用管理器发送的二级心跳包中加上该应用程序正常关闭信息。并在收到主应用管理器的回文过后，从自身的应用程序状态表上删除该应用程序的信息。

在一个实施例中，当应用管理器向主应用管理器发送二级心跳包期间，应用管理器会进行响应计时，若超过设定时间没有收到主应用管理器的响应，则该应用管理器会咨询其他的应用管理器是否能正常与主应用管理器通信。当其他应用管理器收到此应用管理器发送的咨询信息时，则会将自己的通信情况和自己的负载情况反馈给此应用管理器。

进一步的，此应用管理器如果收到来自其他应用管理器上的回文中都显示“可以正常通信”。则该应用管理器会将自身所在的服务器上的应用程序状态表转发给其它应用管理器中负载相对为最小的应用管理器(通过其他应用管理器的反馈信息比对获知)，再由这一负载最小的应用管理器转发给主应用管理器。此时该应用管理器存在以下几种决策情况：

1、若在服务器集群中存在未启动的服务器，则对其上电并根据转发的应用程序表对其实施应用程序热迁移(由无法与主应用管理器通信的服务器迁移至刚上电的服务器)。

2、若其他服务器的负载不大，则由无法与主应用管理器通信的服务器迁移至负载较小的一个或者多个服务器中。

3、若整体服务器集群中的负载普遍较大，则不实施迁移，而由负载相对最小的应用管理器承担转发不能与主应用管理器通信的应用管理器的“二级心跳包”。

另一方面，若此应用管理器收到来自其他应用管理器上的回文中都显示“不可以正常通信”。则所有应用管理器判断主应用管理器故障或者主服务器故障，此时所有应用管理器会重新选择主服务器和主应用管理器。通常会选择业务负载最小的服务器作为主服务器，在该服务器上的应用管理器会成为主应用管理器并接受剩余所有的应用管理器的二级心跳包，并同时向管理员告警主服务器故障。此外，如若此应用管理器接受回文超时。则该应用管理器会继续维持业务(如果业务能够正常进行的话)，直到管理员发觉异常并进行维修。

在一些实施例中，所述应用管理器根据所述一级心跳包确定相应的应用程序异常情况，并基于所述应用程序异常情况执行异常业务调控机制，所述异常业务调控机制根据对应应用程序的用户接入情况、对应应用程序是否瘫痪以及各个所述服务器的业务情况进行对应应用程序的热迁移。

具体的，对应异常情况本申请实施例使用异常业务调控机制ABCM(AbnormalBusiness Control Mechanism)进行处理。在该机制下，当应用管理器检测到应用程序发送的心跳信息出现异常或者有出现异常的趋势(如接受应用程序的心跳信息时间紊乱，接受心跳信息时间超时或者心跳信息中包含的信息开始出现异常)。则通过异常业务调控机制进行异常处理。此时首先通过应用程序状态表上记录的应用程序信息来判断应用程序的用接入户情况，如果无用户接入，则直接关闭或者强制关闭该应用程序，然后在本地服务器上再创建一个相同的应用程序；如果有用户接入，则会查询本地服务器的应用管理器上的应用程序状态表是否存在相同类型并处于空闲状态的应用程序，如果存在则执行本地内存热迁移，并在迁移完成后转移用户映射请求信号。而如若应用程序此时已经瘫痪，则只转移用户请求映射信号至目标应用程序。而如果本地服务器不存在这样的应用程序，则应用管理器会咨询主应用管理器是否在其他服务器上存在相同类型且用户状态为：“无用户接入使用”的应用程序，若存在则将应用程序热迁移到目标服务器上，迁移完成后转移用户映射请求信号；而如若应用程序此时已经瘫痪或者处于异常无法进行应用程序热迁移，则只转移用户请求映射信号至目标应用程序。此时若其他服务器上也不存在符合的应用程序，则应用管理器会根据本地服务器业务情况来决策。在进行决策时，若本地业务承载负荷不大，则在本地服务器上执行本地应用程序热迁移并转移用户映射请求信号。若应用程序此时已经瘫痪或者处于异常无法进行应用程序热迁移，则在本地创建同类型的应用程序后只转移用户请求映射信号至目标应用程序。若本地业务承载负荷较大(已经或者即将达到告警设定值)，则再次查询主应用管理器的服务器状态表来寻找是否有业务承载较低的服务器。其中，若查询存在这样的服务器，在目标服务器上执行应用程序热迁移。若应用程序此时已经瘫痪，则创建目标应用程序后只转移用户请求映射信号。需要说明的是，当有应用程序出现故障，且在异常业务调控机制下应用管理器没有在本地服务器上找到适合的应用程序时，应用管理器会询问主应用管理器，由主应用管理器根据应用程序状态表上的信息来为异常业务调控提供应用程序信息。

此外，本申请实施例在整个服务器集群中选取的主服务器MM(Master Machine)，通过在主服务器构建主应用管理器，参照图3，主应用管理器会实时接收用户终端设备发送的用户请求映射信号并根据主服务器和从服务器的业务情况进行转发或处理。其中，在主服务器的选择上一般会选择服务器集群中性能最高的服务器作为主服务器。主服务器在负载均衡管理上的资源告警设定值会小于其他的服务器(因为主服务器承受的业务最为繁重)。而若云应用的用户群体较大，则可以单独选择性能相对较低的服务器作为主服务器，这样选择出来的服务器上只会存在主应用管理器，并且该应用管理器不会在主服务器上创建应用程序，以此来减少业务负载的占用。

需要注意的是，本申请实施例对每台服务器都进行了业务负载告警设定WL(Warning level)。该业务负载告警默认开启，可以由管理员自由设置告警阈值。当服务器业务承载压力达到业务负载告警设定值的时候，会触发应用管理器调整功能，并向管理员告警。一般而言，服务器上可以设置告警设定值，高负载告警设定值，低负载告警设定值，三种触发阈值可以同时开启或者只开启其中的几种。

此外，本申请实施例的主应用管理器通过接收来自其他应用管理器的心跳信息(服务器业务承载状态和业务流量情况)，可由此实时监控各个服务器上的应用程序并为主应用管理器提供查询其他服务器上应用程序情况的功能。如图3所示，通常而言，服务器集群接收的用户请求会先全部交给主应用管理器来处理。此时的业务处理情况分为三种：1、若主服务器上有处于等待用户连接的应用程序则直接将应用程序给用户使用；2、若主服务器上没有处于等待用户连接状态的应用程序，主应用管理器会根据主服务器目前的情况(硬件负荷等相关会影响业务的条件)进行决策，若服务器在增加应用程序后不会或者轻微影响到业务性能，则直接在主服务器上创建相应的应用程序，然后将用户映射请求信号转移到应用程序；而若主服务器继续创建应用程序会影响业务，或主服务器已经达到负载上限，则主应用管理器会根据其自身的应用程序状态表来选择合适的应用程序。若没有合适的应用程序，则查询服务器状态表，根据服务器负载情况寻找合适的服务器并通知目标服务器上应用管理器创建目标应用程序。需要说明的是，若选择性能相对低的服务器作为主服务器，则主应用管理器只会将用户请求转发至其他应用管理器进行处理。

本申请实施例中运行在服务器上的应用程序为专用应用程序DA(DedicatedApplications)，该应用程序为产品提供商提供的应用程序，其可以让专用应用程序具有像虚拟机一样的热迁移功能同时也可以在同一台服务器上创建大量相同的应用程序。服务器集群会从共享存储设备里的“应用程序”分区中创建应用程序。需要说明的是，本申请实施例对主服务器和从服务器的选定不做固定限制，根据实际需要，可将服务器集群中的服务器在主服务器和从服务器之间进行转换。同理，主应用管理器和应用管理器的本质也是一样的，根据实际需要，主应用管理器和应用管理器也可相互转换。在共享存储设备中同时还有从应用管理器和主应用管理器的安装包，为主后服务器和从服务器、主应用管理器和从应用管理器之间的相互转换提供一定的及时性。当要进行应用程序热迁移时，服务器也会根据迁移信息从中选择相应的应用程序进行安装或者启动。这种应用程序会向所在的服务器的应用管理器发送心跳信息，在应用程序每一次发送心跳信息后，会进入“计时关闭”状态，在该状态下达到一定的时间后，应用程序会自动关闭。若应用管理器成功收到了则会向应用程序发送回文，每次应用程序收到回文后则重置“计时关闭”的时间。应用管理器则会根据心跳信息用来检查应用程序是否正常运行以及用户的使用情况。其中，用户状态分为用户未接入、用户接入以及用户接入，但暂时切出了应用程序。当应用程序处于“用户接入，但暂时切出了应用程序”时，在该状态下若用户没有再次切入该应用程序达到一定时间的时候，应用程序将会自动关闭。根据用户状态和应用程序状态，应用管理器会实时对应用程序做出对维持业务稳定有益的操作。

基于上述云应用管理系统设置，各个所述应用管理器会根据所归属服务器的业务负载告警设定进行对应应用程序的动态调度，通过对应应用程序的热迁移使各个所述服务器负载均衡。

具体的，在应用管理器有可以开启和关闭应用程序热迁移AHM(APP HotMigration)的功能，所有应用程序的动态调度(负载均衡)均由应用管理器控制，动态调度规则可以人为修改。参照图4，当服务器已经达到设置的业务负载告警设定值时，应用管理器会向主应用管理器咨询服务器状态表，若咨询存在业务承载压力不大的服务器，则主应用管理器会通知最适合迁移的服务器上的应用管理器准备执行迁移。此时在源服务器(原应用程序运行处)上的应用管理器选举出最优迁移应用程序后，即可准备进行应用程序热迁移。在收到接收迁移通知后，目标迁移服务器(应用程序迁移目标处)上的应用管理器会咨询主应用管理器来获取准备被迁移的应用程序的相关迁移信息。目标服务器根据源服务器上的将被迁移的应用程序的详细信息来创建应用程序。创建完成后源服务器会开始将应用程序的全部内存镜像拷贝到目标服务器，在这一轮复制完成后，会检查经过这次复制后内存发生了多少变化。在下一轮复制中会将发生变化的内存页重新复制到目标服务器中覆盖掉先前的内存页。当复制所耗费的时间发生变化量达到一定标准后，会将剩余的内存变化和应用程序的工作状态复制到目标服务器上。在此过程中用户与源服务器上的应用程序的读写操作依然可以正常进行。当复制内存操作完成后，暂停源服务器上被迁移的应用程序，将存储从源应用程序上解锁，并锁定在目标服务器已创建的应用程序上，启动目标应用程序，并与存储资源和网络资源相连接。此时源服务器的应用管理器会将用户的请求信号转移到目标服务器上的应用管理器，再由应用管理器下发用户请求信号给刚才创建的应用程序。在这个过程中会暂停用户的连接，但是这个时间控制会在用户察觉异常的时间范围内，以避免影响用户体验。

此外，在一个实施例中，所述应用管理器根据所归属服务器的低业务负载告警信息咨询其余服务器的应用管理器进行业务负载分摊或应用程序热迁移，并在应用程序热迁移后进行所归属服务器的关机操作。应用管理器还具有对服务器下电的功能，在该功能中，如果服务器集群中某一服务器的业务负载过低(触发了低业务负载告警设定值)，则应用管理器会咨询其他服务器上的应用管理器是否需要分摊业务负载，若其他应用管理器都回应不需要，则应用管理器会对其服务器上的应用程序全部进行迁移，迁移完成后进行服务器关机操作，以此来避免服务器空置节约能耗。

在一个实施例中，所述应用管理器根据所述应用程序状态表计算各个应用程序的迁移难度值和迁移收益值，基于所述迁移难度值和/或所述迁移收益值选取对应的应用程序进行热迁移。

具体的，在应用程序热迁移中应用管理器会使用应用程序迁移选优功能AMOF(Application Migration Optimization Function)来选取目前时刻所要迁移的应用程序。该最优应用程序的选取是通过应用管理器检索自身的应用程序状态表上所有应用程序的信息来进行的。应用管理器会根据应用程序状态表上的信息来计算迁移难度值和迁移收益值，迁移难度值表现为迁移该应用程序所消耗的时间会不会高于用户察觉时间。当应用管理器计算得到的预计迁移时间小于用户察觉时间，则迁移难度值为用户察觉时间减去预计迁移时间的毫秒数，该值是负的。当应用管理器计算得到的预计迁移时间大于用户察觉时间，则迁移难度值为预计迁移时间的毫秒数减去用户察觉时间，该值是正的。之所以用以上方式计算是为了能让数据能直观明确的显示给管理员。然后应用管理器会从中选取迁移难度值最低的应用程序。迁移收益值表现为迁移该应用程序后会为本地服务器释放多少的内存资源，GPU资源和网络流量，每种资源会计算一个收益值，收益值为：(各资源迁移后释放的资源数量/各资源的告警设定值所对应的资源数量)×100％。若服务器是网络流量告警则将网络流量设置为首要考虑要素，首要考虑对比的是不同应用程序的网络流量收益值。若网络流量收益值相同。则比较另外两项的收益值，若三项收益值完全相同。则选择迁移用户状态为“使用中，但是目前切出”的应用程序。如果两个应用程序的用户状态相同，则考虑用户接入时间的长短来选择应用程序。若服务器有多个资源即将告警或者已经告警，例如服务器是网络流量告警，内存即将达到告警设定值但还未达到，此时首要计算网络流量与内存大小的总体收益值，总体收益值的计算是将网络流量正常计算的收益值+内存大小的收益值×(目前总内存占用量/资源的告警水位所对应的资源数量)，然后比较总体收益值，选取应用程序。若服务器此时已经高负荷运转，则优先考虑迁移收益值所选取的应用程序，来减少服务器的负载业务。若服务器只是刚刚告警，则优先考虑迁移难度值所选取的应用程序来保证用户体验。此外，还可以通过浏览该服务器上所有应用程序的迁移收益值和迁移难度值表手动选择或者设置相对适用于该服务器的选择策略，选择策略有激进，正常，保守三种设置通过比较各应用程序的客制值来实现该功能，客制值的计算为：迁移难度值×管理员设置的策略方案+迁移收益值×管理员设置的策略方案，其中，激进策略>正常策略>保守策略。

上述，通过在服务器上运行应用程序，构建应用管理器以管理对应的应用程序，对用户请求映射信号进行转发和处理，并通过各个应用管理器接收对应应用程序发送的心跳信息，基于心跳信息记录应用程序状态。此外，通过主应用管理器汇总自身及各个从应用管理器的应用程序状态和所归属的服务器业务情况，并实时根据心跳信息的应用程序异常情况或所归属服务器的业务负载告警情况进行应用程序热迁移。采用上述技术手段，可以通过心跳信息实现对应用程序的灵活管理，并借助应用程序热迁移使得各个服务器负载均衡，降低云应用管理成本。此外，通过实时接收应用程序的心跳信息，实现对各个云应用的全流量监控，进而减少信息泄露风险，保障云应用管理系统的安全性。

实施例二：

在上述实施例的基础上，图5为本申请实施例二提供的一种基于服务器集群的云应用管理装置的结构示意图。参考图5，本实施例提供的基于服务器集群的云应用管理装置具体包括：接收模块21、写入模块22和汇总模块23。

其中，接收模块21用于通过各个应用管理器接收对应应用程序发送的一级心跳包，所述一级心跳包包含io吞吐信息、网络流量信息、内存使用信息、用户使用情况和应用程序辨识信息的一种或多种；

写入模块22用于通过各个应用管理器将接收到的所述一级心跳包中的信息写入自身的应用程序状态表，并实时根据新接收的所述一级心跳包更新所述应用程序状态表；

汇总模块23用于通过各个应用管理器根据所述应用程序状态表和所归属的服务器业务情况生成二级心跳包，将所述二级心跳包汇总至主应用管理器，由所述主应用管理器将所述二级心跳包中的信息写入自身的应用程序状态表。

上述，通过在服务器上运行应用程序，构建应用管理器以管理对应的应用程序，对用户请求映射信号进行转发和处理，并通过各个应用管理器接收对应应用程序发送的心跳信息，基于心跳信息记录应用程序状态。此外，通过主应用管理器汇总自身及各个从应用管理器的应用程序状态和所归属的服务器业务情况，并实时根据心跳信息的应用程序异常情况或所归属服务器的业务负载告警情况进行应用程序热迁移。采用上述技术手段，可以通过心跳信息实现对应用程序的灵活管理，并借助应用程序热迁移使得各个服务器负载均衡，降低云应用管理成本。此外，通过实时接收应用程序的心跳信息，实现对各个云应用的全流量监控，进而减少信息泄露风险，保障云应用管理系统的安全性。本申请实施例三提供的基于服务器集群的云应用管理装置可以用于执行上述实施例一提供的基于服务器集群的云应用管理方法，具备相应的功能和有益效果。

实施例三：

本申请实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行一种基于服务器集群的云应用管理方法，该基于服务器集群的云应用管理方法包括：各个应用管理器接收对应应用程序发送的一级心跳包，所述一级心跳包包含io吞吐信息、网络流量信息、内存使用信息、用户使用情况和应用程序辨识信息的一种或多种；各个应用管理器将接收到的所述一级心跳包中的信息写入自身的应用程序状态表，并实时根据新接收的所述一级心跳包更新所述应用程序状态表；各个应用管理器根据所述应用程序状态表和所归属服务器的业务情况生成二级心跳包，将所述二级心跳包汇总至所述主应用管理器，由所述主应用管理器将所述二级心跳包中的信息写入自身的应用程序状态表。

存储介质——任何的各种类型的存储器设备或存储设备。术语“存储介质”旨在包括：安装介质，例如CD-ROM、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如DRAM、DDR RAM、SRAM、EDO RAM，兰巴斯(Rambus)RAM等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等。存储介质可以还包括其它类型的存储器或其组合。另外，存储介质可以位于程序在其中被执行的第一计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到第一计算机系统。第二计算机系统可以提供程序指令给第一计算机用于执行。术语“存储介质”可以包括驻留在不同位置中(例如在通过网络连接的不同计算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。

当然，本申请实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上所述的基于服务器集群的云应用管理方法，还可以执行本申请任意实施例所提供的基于服务器集群的云应用管理方法中的相关操作。

上述实施例中提供的基于服务器集群的云应用管理装置、存储介质可执行本申请任意实施例所提供的基于服务器集群的云应用管理方法，未在上述实施例中详尽描述的技术细节，可参见本申请任意实施例所提供的基于服务器集群的云应用管理方法。

上述仅为本申请的较佳实施例及所运用的技术原理。本申请不限于这里所述的特定实施例，对本领域技术人员来说能够进行的各种明显变化、重新调整及替代均不会脱离本申请的保护范围。因此，虽然通过以上实施例对本申请进行了较为详细的说明，但是本申请不仅仅限于以上实施例，在不脱离本申请构思的情况下，还可以包括更多其他等效实施例，而本申请的范围由权利要求的范围决定。

Claims (10)

1.基于服务器集群的云应用管理系统，其特征在于，包括多个服务器，所述服务器用于运行应用程序，并构建应用管理器，所述应用管理器用于管理对应的应用程序，并对用户请求映射信号进行转发和处理；

各个所述应用管理器还实时接收对应应用程序发送的心跳信息，基于所述心跳信息记录应用程序状态；所述服务器包括主服务器和从服务器，所述主服务器构建的应用管理器为主应用管理器，所述从服务器构建的应用管理器为从应用管理器，所述主应用管理器用于汇总自身及各个所述从应用管理器对应的应用程序状态和所归属的服务器业务情况；

所述应用管理器还用于根据所述心跳信息的应用程序异常情况或所归属服务器的业务负载告警情况进行应用程序热迁移。

2.一种基于服务器集群的云应用管理方法，应用于如权利要求1所述的基于服务器集群的云应用管理系统，其特征在于，包括：

各个应用管理器接收对应应用程序发送的一级心跳包，所述一级心跳包包含io吞吐信息、网络流量信息、内存使用信息、用户使用情况和应用程序辨识信息的一种或多种；

各个应用管理器将接收到的所述一级心跳包中的信息写入自身的应用程序状态表，并实时根据新接收的所述一级心跳包更新所述应用程序状态表；

各个应用管理器根据所述应用程序状态表和所归属服务器的业务情况生成二级心跳包，将所述二级心跳包汇总至所述主应用管理器，由所述主应用管理器将所述二级心跳包中的信息写入自身的应用程序状态表。

3.根据权利要求2所述的基于服务器集群的云应用管理方法，其特征在于，所述各个应用管理器根据所述应用程序状态表和所归属服务器的业务情况生成二级心跳包，还包括：

所述应用管理器提取对应的所述一级心跳包中包含的应用程序正常关闭信息，将所述应用程序正常关闭信息放入对应的二级心跳包中上传，并实时根据主应用管理器的回文从所述应用程序状态表中删除对应应用程序的信息。

4.根据权利要求2所述的基于服务器集群的云应用管理方法，其特征在于，所述各个应用管理器接收对应应用程序发送的一级心跳包，还包括：

所述应用管理器根据所述一级心跳包确定相应的应用程序异常情况，并基于所述应用程序异常情况执行异常业务调控机制，所述异常业务调控机制根据对应应用程序的用户接入情况、对应应用程序是否瘫痪以及各个所述服务器的业务情况进行对应应用程序的热迁移。

5.根据权利要求2所述的基于服务器集群的云应用管理方法，其特征在于，还包括：

各个所述应用管理器根据所归属服务器的业务负载告警设定进行对应应用程序的动态调度，通过对应应用程序的热迁移使各个所述服务器负载均衡。

6.根据权利要求5所述的基于服务器集群的云应用管理方法，其特征在于，各个所述应用管理器根据所归属服务器的业务负载告警设定进行对应应用程序的动态调度，还包括：

所述应用管理器根据所归属服务器的低业务负载告警信息咨询其余服务器的应用管理器进行业务负载分摊或应用程序热迁移，并在应用程序热迁移后进行所归属服务器的关机操作。

7.根据权利要求5所述的基于服务器集群的云应用管理方法，其特征在于，所述通过对应应用程序的热迁移使各个所述服务器负载均衡，还包括：

所述应用管理器根据所述应用程序状态表计算各个应用程序的迁移难度值和迁移收益值，基于所述迁移难度值和/或所述迁移收益值选取对应的应用程序进行热迁移。

8.根据权利要求2所述的基于服务器集群的云应用管理方法，其特征在于，还包括：

主应用管理器实时接收用户请求映射信号并根据主服务器和从服务器的业务情况进行转发或处理。

9.一种基于服务器集群的云应用管理装置，其特征在于，包括：

接收模块，用于通过各个应用管理器接收对应应用程序发送的一级心跳包，所述一级心跳包包含io吞吐信息、网络流量信息、内存使用信息、用户使用情况和应用程序辨识信息的一种或多种；

写入模块，用于通过各个应用管理器将接收到的所述一级心跳包中的信息写入自身的应用程序状态表，并实时根据新接收的所述一级心跳包更新所述应用程序状态表；

汇总模块，用于通过各个应用管理器根据所述应用程序状态表和所归属的服务器业务情况生成二级心跳包，将所述二级心跳包汇总至主应用管理器，由所述主应用管理器将所述二级心跳包中的信息写入自身的应用程序状态表。

10.一种包含计算机可执行指令的存储介质，其特征在于，所述计算机可执行指令在由计算机处理器执行时用于执行如权利要求2-8任一所述的基于服务器集群的云应用管理方法。

Images