专利名称：集群环境下的应用服务器的系统再生方法
技术领域：
本发明涉及一种应用服务器的再生方法，尤其涉及一种集群环境下的应用服务器的系统再生方法。
背景技术：
伴随着软件的运行，由于系统资源逐渐消耗或运行时错误逐渐积累所导致的系统性能持续下降乃至挂起或停机的现象。这就是所谓的“软件老化”。应用服务器也存在相同的问题。要保证服务器的高可用性和高可靠性，必须对服务器进行软件再生。“软件再生”是一种“前摄式”(proactive)的容错技术，它主要通过周期性地暂停软件的运行，清除持续运行系统的内部状态，重新启动并恢复到干净的初始或中间状态，从而达到预先防止将来可能发生的更严重的故障的目的。“软件再生”技术所涉及的主要问题是何时进行“再生”以及如何“再生”。由于“再生”本身也会导致系统的不可用，因此，过高频率的“软件再生”会增大系统停机的时间和损失，频率过低则不能保证起到应有的效用。“再生”的方法与“再生”的粒度有关，如基于组件的“再生”，基于检查点的“再生”等。
应用服务器(Application Server)中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，应用服务器中间件位于客户机服务器的操作系统之上，管理计算资源和网络通讯。它屏蔽了底层网络和操作系统的复杂性和异构性，提供客户标准的服务集，使得整个系统对于客户的访问是透明的。
与其他软件一样，应用服务器在运行一段时间后，可能由于系统资源逐渐消耗或运行时错误逐渐积累而性能下降，甚至使得应用服务器不可用，呈现老化状态。应用服务器的再生特征能很好地提高其性能和可用性。
在应用服务器运行期间，必须对服务器状态进行监控，获得展现服务器状态的各个指标，并通过数学模型分析判断这些指标所标识的服务器状态已经达到老化后，对服务器进行再生，从而提高服务器性能，提供可靠的服务。
再生策略一般可分为基于时间的策略以及基于时间和负载量的策略两种。基于时间的再生策略思想是按照实际服务器的运行时间，来确认系统老化程度。并假设系统从开始运行到系统崩溃的时间与服务器的能力和其它任何参数没有必然联系，而是通过收集历史数据，对历史数据进行建模分析得出老化时间，从而确认服务器的再生点。
基于时间和负载量的策略的基本思想是当系统定时再生被触发时，系统不再马上执行再生，而是首先检测集群系统的负载状态。由于重载状态时节点的再生会降低系统性能，故选择在系统轻载时再生。为了保证在再生该节点的过程中系统依然可用，首先将该节点中的负载量和相关服务迁移到其他节点，并将服务器内部状态备份到硬盘或者其他节点，同时回收导致服务器性能下降的资源，使得服务器回滚到启动状态或者某个可用状态。
常用的再生方法有基于模型的再生和基于测量的方法。基于模型的研究方法出现的较早，其思想是应用数学方法求解得出软件再生时间的最优值与各老化指标参量之间的一组函数关系，而各老化指标参量的具体值则可以通过对实际系统一段时间的试验或实际运行得到。目前，基于模型方法的重点在于利用随机Petri网等工具对软件系统的状态和转换进行刻画建模，结合随机过程等数学方法求解，最后得出在该模型下的最佳恢复时间的公式或关系。
基于测量的方法是在软件运行的实际过程中，监测反映系统运行状态的各项性能参数，再根据软件本身的一些参数，动态地进行软件老化的速度、时间、可能性及软件再生代价等的计算评估，做出是否以及何时采取软件再生措施的决策。
在中间件运行平台中通过支持集群来减轻负载是普遍所采用的方法。而集群环境本身的特点，即系统内多点之间会互动地起作用和产生状态的转换，决定了使用单一的方法可能无法很好地解决软件老化和再生的问题。使用基于模型的方法，对其容器集群系统的状态关系建立模型，研究系统运行状态的分布，从而进一步计算某些需要观测的关键点的时间和间隔，以达到从整个集群的角度研究出再生的最佳时间和频度的目的。利用基于模型的方法找到需要观测的关键点之后，再实时地用基于预测的方法判断软件老化的状态，决定是否需要采取相应的再生手段。这样以来，就能够从多方位多角度对一个集群系统进行软件再生。
应用服务器中间件容器环境的再生按照系统的运行状况划分为不同的粒度级别，提出在集群环境下的系统再生控制策略和再生控制模块的控制算法。将集群中的每个节点作为一个自治系统，同时遵循全局的再生策略，受到再生控制模块的调节。当某个节点处于轻度老化时，这个节点自身通过资源回收、服务重起来调节自身的老化程度。如果某个节点的老化积累已经不能由其自身来调节，再生控制模块首先对其负载和服务进行迁移，保持客户访问的可用性，然后重起这个老化节点，最后由再生控制模块来平衡整个系统的负载和请求状况。
目前软件再生的研究场景多集中于非集群环境，对于集群环境的再生问题研究极少。
发明内容
本发明的目的在于提出一种集群环境下的应用服务器的系统再生方法。此方法能够实现多个节点的JTone应用服务器集群在不停止服务的情况下，当某个节点被检测到老化时能动态地进行再生。
为达到上述目的，本发明采用的技术方案是首先通过老化建模检测当前服务器的节点是否老化，若当前服务器的节点已经老化则将此节点的当前操作设置为检查点，并通过状态复制操作确定当前正在处理的EJB请求的当前服务器节点的状态信息，将该节点的状态信息置为不可用，客户端得到通知该节点处于不可用状态，不再向该节点发送请求，此节点不再接收新的EJB请求，仅有状态会话bean和实体bean才有状态信息；通过EnterpriseContext保持此节点的状态信息并将节点的状态信息复制到另一个可用备份节点；状态复制过程如下首先状态复制器将此节点的状态信息传递给应用服务器底层的通讯框架，该通讯框架中的ReplicationManager模块同步各个节点的状态信息，当要进行再生的节点将状态信息传递到ReplicationManager模块时，ReplicationManager模块会将状态信息的改变同步到其余所有应用服务器节点，使各个节点的状态同步；此节点调用本地操作系统的Windows API——ExitWindowsEx(UINT uFlags，DWORDdwReserved)对该节点重启；应用服务器被配置成为Windows的一项服务，当计算机重新启动时，应用服务器随之启动，并作为系统的一个节点重新加入到集群中来，同时与其他节点同步，将当前备份节点的最新状态复制到本地节点；接受了复制状态信息节点的最新状态信息通过状态复制重新复制到发生再生的应用服务器节点，此应用服务器重新接受EJB请求。
本发明的再生通过主动停止程序运行，清理应用服务器的内部环境，使重启后的应用服务器进入一个正常的初始状态，从而避免因软件老化引起的突发性失效，有效的提高了应用服务器的可靠性和可用性。
附图是本发明的流程图。
具体实施例方式
下面结合附图对本发明作进一步详细说明。
参见附图，若当前服务器节点被检测到已经老化，则需要进行以下的再生步骤通过老化建模，得到当前服务器已处于老化状态，并将当前服务器老化信息传送给状态监测器；状态监测器接收到信息，得知本节点已老化，则向请求转发器和状态复制器发出再生通知，将当前操作设置为检查点，进行再生准备；请求转发器接受到请求后，向客户端显示该节点不可用，保存当前正在处理的请求，停止接受新请求；状态复制器则在当前请求执行完毕之后，将当前服务器状态复制下来，确定当前正在处理EJB请求的当前服务器节点的状态信息；仅有状态会话bean和实体bean才有状态信息，状态复制所需要的状态均由EnterpriseContext来保持，主要成员有idid的意义在不同种类EJB中各不相同。在有状态会话Bean中id是用来区分同一个EJB的不同客户端的，是一个只增的长整型值。因为有状态实体Bean接受多个客户端的调用，id则用于区分不同的客户端；instance是对当前EJB的Bean实现类实例的一个引用。对于有状态会话Bean来说，其对于客户端呈现出的“状态”就是Bean实现类所持有的成员域的值；locked表示本context是否正处于一次方法调用的过程中，是一个整型值。一般只在0和1之间变化，但在方法声明为可重入时也有可能出现1以上的值。容器类在进行钝化操作时要访问此成员域，若值不为0则钝化操作要推迟进行；状态复制下来之后，状态复制器将状态信息发送到状态同步器，状态同步器将该节点的状态信息同步到其它可用节点上；状态的复制是较为复杂的过程，其用到了底层的通讯框架，当前服务器要进行再生时，首先设置检查点以中断EJB请求的接受，然后当前处理的细粒度方法调用结束后(一个业务调用可能由很多组方法调用组成，当前正在执行的方法调用结束后，并不意味着应用服务器不再保存任何状态信息，而是当前处理结束后的状态，很有可能被用到下一次方法调用中去。这也是为什么要使用有状态会话Bean的原因所在，之所以使用有状态会话Bean，就是考虑到一次业务调用可能由多次的方法调用组成，使用有状态会话bean可以保持状态，从而避免了多次建立网络连接，减小网络消耗。正是由于状态信息的存在，才需要进行状态复制)，将当前服务器状态传递给底层的通讯框架，该通讯框架中存在一个名为ReplicationManager的一个模块，专门负责同步各个节点的状态信息。当要进行再生的节点将状态信息传递到复制管理器时，该模块会进行一次全局的状态同步，从而将状态信息的改变同步到其余所有应用服务器节点，这样就达到了各个节点的状态同步。
同理，在需要将另外应用服务器节点的最新状态信息重新复制到再生的服务器节点时，也要通过复制管理器的状态同步来实现状态的迁移；状态同步结束后，通知再生管理器进行再生；再生管理器调用相关接口对该节点进行再生。调用本地OS的API，重新启动计算机。调用本地操作系统的Windows API——ExitWindowsEx(UINTuFlags，DWORD dwReserved)对节点重启；再生后的节点需要与其它可用节点进行同步状态；系统重启成功时，应用服务器作为一项应用随之也自动重启。将应用服务器作为Windows的一项服务，当计算机重新启动时，应用服务器随之启动，并作为系统的一个节点重新加入到集群中来，同时与其他节点同步，将当前备份节点(已经是主节点)的最新状态复制到本地节点；将接受了复制状态的节点的最新状态信息通过状态复制重新复制到发生再生的应用服务器节点，请求转发器与状态监测器得到通知开始工作，重新接受EJB请求。
权利要求
1.集群环境下的应用服务器的系统再生方法，其特征在于1)首先通过老化建模检测当前服务器的节点是否老化，若当前服务器的节点已经老化则将此节点的当前操作设置为检查点，并通过状态复制操作确定当前正在处理的EJB请求的当前服务器节点的状态信息，将该节点的状态信息置为不可用，客户端得到通知该节点处于不可用状态，不再向该节点发送请求，此节点不再接收新的EJB请求，仅有状态会话bean和实体bean才有状态信息；2)通过EnterpriseContext保持此节点的状态信息并将节点的状态信息复制到另一个可用备份节点；状态复制过程如下首先状态复制器将此节点的状态信息传递给应用服务器底层的通讯框架，该通讯框架中的ReplicationManager模块同步各个节点的状态信息，当要进行再生的节点将状态信息传递到ReplicationManager模块时，ReplicationManager模块会将状态信息的改变同步到其余所有应用服务器节点，使各个节点的状态同步；3)此节点调用本地操作系统的Windows API——ExitWindowsEx(UINTuFlags，DWORD dwReserved)对该节点重启；4)应用服务器被配置成为Windows的一项服务，当计算机重新启动时，应用服务器随之启动，并作为系统的一个节点重新加入到集群中来，同时与其他节点同步，将当前备份节点的最新状态复制到本地节点；5)接受了复制状态信息节点的最新状态信息通过状态复制重新复制到发生再生的应用服务器节点，此应用服务器重新接受EJB请求。
全文摘要
集群环境下的应用服务器的系统再生方法，通过老化建模检测当前服务器的节点是否老化，若已老化将此节点的设置为检查点，并通过状态复制操作确定当前正在处理的EJB请求的当前服务器节点的状态信息，并将节点的状态信息复制到另一个服务器的可用备份节点；该服务器调用本地操作系统的Windows API——ExitWindowsEx对服务器的节点重启；重启后重新加入到集群中来，同时与其他节点同步，将当前备份节点的最新状态复制到本地节点；此应用服务器重新接受EJB请求。本发明的再生主动停止程序运行，清理应用服务器的内部环境，使重启后的应用服务器进入一个正常的初始状态，从而避免因软件老化引起的突发性失效，有效的提高了应用服务器的可靠性和可用性。
文档编号G06F11/36GK1766844SQ20051009606
公开日2006年5月3日 申请日期2005年9月26日 优先权日2005年9月26日
发明者齐勇, 郗旻, 张霞, 赵天海, 赵季中, 侯迪 申请人:西安交通大学