CN101038564A - 应用服务器分级再生方法 - Google Patents

Abstract

应用服务器分级再生方法，通过老化建模检测当前服务器的老化状态，根据不同老化状态进行组件级再生：确定老化组件，保存该组件状态信息，关闭相应服务然后重起此服务；重起后读取保存的状态信息恢复组件状态，使组件重新提供服务；JVM级再生：保存当前服务器的状态信息，关闭服务器并进行重起；操作系统级再生：保存服务器状态，重起操作系统，服务器随操作系统自动重起，读取保存的状态信息，服务器重新接受请求。每进行完一级再生，就再次进行老化检测，若服务器已恢复到正常，再生结束；若服务器仍处于老化状态，则进行下一级别的再生，直到服务器恢复正常。本发明通过再生操作分级，避免了局部老化就进行全局再生的可能，减少了应用服务器停机时间，降低再生代价。

Description

应用服务器分级再生方法

技术领域

本发明涉及一种应用服务器的再生方法，尤其涉及一种应用服务器的分级再生方法。

背景技术

伴随着软件的运行，由于系统资源逐渐消耗或运行时错误逐渐积累所导致的系统性能持续下降乃至挂起或停机的现象。这就是所谓的“软件老化”。应用服务器也存在相同的问题。要保证服务器的高可用性和高可靠性，必须对服务器进行软件再生。“软件再生”是一种“前摄式”(proactive)的容错技术，它主要通过周期性地暂停软件的运行，清除持续运行系统的内部状态，重新启动并恢复到干净的初始或中间状态，从而达到预先防止将来可能发生的更严重的故障的目的。“软件再生”技术所涉及的主要问题是何时进行“再生”以及如何“再生”。由于“再生”本身也会导致系统的不可用，因此，过高频率的“软件再生”会增大系统停机的时间和损失，频率过低则不能保证起到应有的效用。“再生”的方法与“再生”的粒度有关，如基于组件的“再生”，基于检查点的“再生”等。

应用服务器(Application Server)中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，应用服务器中间件位于客户机服务器的操作系统之上，管理计算资源和网络通讯。它屏蔽了底层网络和操作系统的复杂性和异构性，提供客户标准的服务集，使得整个系统对于客户的访问是透明的。

与其他软件一样，应用服务器在运行一段时间后，可能由于系统资源逐渐消耗或运行时错误逐渐积累而性能下降，甚至使得应用服务器不可用，呈现老化状态。应用服务器的再生特征能很好地提高其性能和可用性。

在应用服务器运行期间，必须对服务器状态进行监控，获得展现服务器状态的各个指标，并通过数学模型分析判断这些指标所标识的服务器状态已经达到老化后，对服务器进行再生，从而提高服务器性能，提供可靠的服务。

再生策略一般可分为基于时间的策略以及基于时间和负载量的策略两种。基于时间的再生策略思想是：按照实际服务器的运行时间，来确认系统老化程度。并假设系统从开始运行到系统崩溃的时间与服务器的能力和其它任何参数没有必然联系，而是通过收集历史数据，对历史数据进行建模分析得出老化时间，从而确认服务器的再生点。

基于时间和负载量的策略的基本思想是：当系统定时再生被触发时，系统不再马上执行再生，而是首先检测集群系统的负载状态。由于重载状态时节点的再生会降低系统性能，故选择在系统轻载时再生。为了保证在再生该节点的过程中系统依然可用，首先将该节点中的负载量和相关服务迁移到其他节点，并将服务器内部状态备份到硬盘或者其他节点，同时回收导致服务器性能下降的资源，使得服务器回滚到启动状态或者某个可用状态。

常用的再生方法有基于模型的再生和基于测量的方法。基于模型的研究方法出现的较早，其思想是应用数学方法求解得出软件再生时间的最优值与各老化指标参量之间的一组函数关系，而各老化指标参量的具体值则可以通过对实际系统一段时间的试验或实际运行得到。目前，基于模型方法的重点在于利用随机Petri网等工具对软件系统的状态和转换进行刻画建模，结合随机过程等数学方法求解，最后得出在该模型下的最佳恢复时间的公式或关系。

基于测量的方法是在软件运行的实际过程中，监测反映系统运行状态的各项性能参数，再根据软件本身的一些参数，动态地进行软件老化的速度、时间、可能性及软件再生代价等的计算评估，做出是否以及何时采取软件再生措施的决策。

由于应用服务器本身非常复杂，所以可能存在不同程度的老化，又因为内部拥有多个组件，每个组件都有出现老化的可能。所以简单的采用重起操作系统的方法并不能很好的解决这种老化程度的多样性和位置的不确定性。使用基于模型的方法，对应用服务器内部各个组件的状态关系进行建模，研究服务器的运行状态分布，从而计算出标志服务器或者单个组件老化的关键点。以此为基础，实时地用基于预测的方法判断软件老化的状态，决定是否需要采取相应的再生手段。这样就能解决服务器不同程度的老化问题。

应用服务器再生可以根据老化的程度分为不同粒度。将应用服务中每个组件都作为一个模块单独处理，同时也考虑服务器整体再生策略。当某个组件老化时，对这个组件进行资源回收、服务重起来解决老化，如果服务器整体老化，就保存整个服务器状态，对其进行重起。对于组件老化还需要考虑关联老化的情况，即一个组件的老化(或再生重起)可能引起其他组件同时出现老化或不可用，故再对老化组件进行重起的同时需要对相关组件也进行重起。

目前对于应用服务器的再生，大多不考虑老化的程度和具体位置，直接采取全局的重起，对于软件内部组件的重起考虑很少。

发明内容

本发明的目的在于克服上述再生方法较为单一的缺点，提供了一种能够实现在服务器仍然提供服务的情况下，完成再生，从而减少因再生引起的停机时间的应用服务器的分级再生方法。

为达到上述目的，本发明采用的技术方案是：1)首先通过老化模型检测应用服务器的老化状态，如果老化则判断是整体老化还是局部老化，若是整体老化直接转向步骤5)；若是局部老化则确定是哪些组件老化；

2)通过老化关联对照表查看已老化的组件是否会产生关联老化，如果不会则通过状态保存器保存目前老化服务的状态信息，并关闭此服务，然后重起；如果此服务存在关联的老化服务，则通过状态保存器将所有关联的服务状态都保存下来，关闭这些服务，并重起；

3)恢复上一步重起的服务状态，读取保存在状态保存器中的信息，重新响应用户请求；

4)此时，再次检测服务器是否老化，如果服务器正常，说明重起这些服务使服务器恢复到正常状态，再生成功，本次再生结束，否则继续下一步；

5)进行JVM级的再生，首先保存服务器和当前正在响应请求的状态，调用操作系统API，关闭服务器所运行的JVM，然后重起服务器并恢复状态；

6)服务器重起后再次对服务器进行老化检测，如果服务器正常则再生结束，否则进行下面的操作系统级再生；

7)调用操作系统API重起计算机，系统重启成功时，应用服务器作为一项应用随之也自动重启。

本发明通过将再生操作分级，避免了由于局部老化就进行全局再生的可能，从而减少了应用服务器的停机时间，降低再生代价。

附图说明

图1是本发明的流程图。

具体实施方式

下面结合附图对本发明作进一步详细说明。

参见图1，若当前服务器节点被检测到已经老化，则需要进行以下的再生步骤：

首先通过老化建模1，得到当前服务器已处于老化状态，并将当前服务器老化信息2传送给状态监测器，其中包括需要进行再生的组件列表。

状态监测器接收到信息，得知服务器已老化，则向请求转发器和状态保存器发出再生通知2，进行再生准备。

由于此时大多数服务器组件不需要再生，故服务器仍可以接受并处理客户请求。但状态监测器需通知请求转发器，把即将进行再生的组件置为不可用，如果用户请求不需要这些组件提供服务，则可正常响应；如果用户请求需要使用这些组件，则将请求保存在请求队列中，等组件再生完成后再恢复响应，这样就可以将服务器失效对用户屏蔽。

状态保存器则在当前请求执行完毕之后，将需要进行再生的组件信息保存下来即保存所需再生组件状态3，状态保存下来之后，状态保存器将已经保存状态的组件列表发给组件再生器，进行组件再生4。由于这些组件都被配置成服务器的服务，只需关闭这些服务并重起即启动组件再生5。

服务重启之后，通知组件再生完毕6并恢复保存的组件状态信息中的数据即恢复再生组件状态7，向老化建模通知组件再生完成，此时再通过老化建模检测服务器是否老化，若服务器恢复正常，则说明再生成功，状态检测器向请求接受器发出通知，将已再生的组件改为可用状态；若服务器仍然老化9，说明组件再生不能解决此次老化问题，则进行高一等级的再生(JVM级再生)。

状态监测器向请求接收器和状态保存器发出JVM级再生通知10，进行再生准备。

请求接收器收到JVM级再生通知，将服务器置为不可用状态，保存当前正在进行的请求，停止接受新的请求11。

状态保存器则在当前请求执行完毕之后，保存服务器运行状态12。这里不但有的组件需要保存状态，还有业务EJB也需要保存状态。仅有状态绘画bean和实体bean有状态信息。这里需要利用到java的对象持久化技术。实体bean只需调用其ejbStore()方法，将内存中的值保存到数据库中，使其保持最新数据。

状态保存完毕之后，通知JVM再生器进行JVM级再生，JVM再生器启动JVM级再生14。JVM级再生是JVM再生器调用服务器的shutdown服务(在shutdown服务老化不能正常使用时，调用操作系统API完成)，关闭服务器。接着启动服务器，并通知状态保存器JVM级再生完毕，状态保存器恢复保存的状态信息即恢复服务器状态16并向老化建模通知JVM级再生完成，此时再通过老化建模检测服务器是否老化17，若服务器恢复正常，则说明再生成功，通知请求接收器重新开始接受用户请求，状态监测器也恢复对服务器状态的检测；若服务器仍处于老化状态18，说明JVM级再生不能解决此次老化问题，则进行高一等级的再生(操作系统级级再生)。

由于服务器在JVM级再生后并未处理新的请求，所以服务器状态没有发生改变，不需要进行状态保存。状态监测器向操作系统级再生器发出操作系统级再生通知19，操作系统再生器启动操作系统级再生20即操作系统再生器调用本地OS的API，重新启动计算机。调用本地操作系统的Windows API--ExitWindowsEx(UINT uFlags，DWORD dwReserved)对节点重启；系统重启成功时，应用服务器作为操作系统一项服务也自动重启。此时再进行状态恢复即通知状态保存器恢复服务器状态22(同JVM级再生后的状态恢复)。

应用服务器恢复状态，状态保存器分别通知请求接受器重新接受请求、通知状态监测器继续监测服务器状态，请求接收器与状态监测器得到通知开始工作，重新接受EJB请求。

Claims (1)

1.应用服务器的分级再生方法，其特征在于：

1)首先通过老化模型检测应用服务器的老化状态，如果老化则判断是整体老化还是局部老化，若是整体老化直接转向步骤5)；若是局部老化则确定是哪些组件老化；

2)通过老化关联对照表查看已老化的组件是否会产生关联老化，如果不会则通过状态保存器保存目前老化服务的状态信息，并关闭此服务，然后重起；如果此服务存在关联的老化服务，则通过状态保存器将所有关联的服务状态都保存下来，关闭这些服务，并重起；

3)恢复上一步重起的服务状态，读取保存在状态保存器中的信息，重新响应用户请求；

4)此时，再次检测服务器是否老化，如果服务器正常，说明重起这些服务使服务器恢复到正常状态，再生成功，本次再生结束，否则继续下一步；

5)进行JVM级的再生，首先保存服务器和当前正在响应请求的状态，调用操作系统API，关闭服务器所运行的JVM，然后重起服务器并恢复状态；

6)服务器重起后再次对服务器进行老化检测，如果服务器正常则再生结束，否则进行下面的操作系统级再生；

7)调用操作系统API重起计算机，系统重启成功时，应用服务器作为一项应用随之也自动重启。

Images