CN103327066B - 用于在集群内调度作业的方法和系统 - Google Patents

Abstract

本发明公开了下一代群集，一种计算机实现的系统和方法以用于在群集内提供作业的调度。该系统包括：包括多个应用服务器的群集；作业调度器，在所调度的时间接受要由群集执行的作业；作为单例服务在群集内提供的定时器主控，在群集内被使用以分配所调度作业到群集内的应用服务器，所调度作业被调度为在所调度的时间在所分配的应用服务器上开始；租约表，记录群集内的哪个应用服务器当前正维持群集的定时器主控的租约并且担当群集的定时器主控；数据库，永久性存储作业信息。应用服务器周期性地投票定时器主控用于要执行的作业。如果当前担当定时器主控的应用服务器发生故障，另一个应用服务器被选择为担当定时器主控。

Description

用于在集群内调度作业的方法和系统

本申请是申请号为200780017766.9、申请日为2007年1月4日、名称为“下一代群集”的发明专利申请的分案申请。

优先权要求

美国临时专利申请号60/747,364，标题为“Next Generation Clustering”，由Naresh Revanuru等人在2006年5月16日提交[代理人案号BEAS-01937US0]。

美国专利申请号11/425,784，标题为“Automatic Migratable Services”，由Aaron Fiske在2006年6月22日提交[代理人案号BEAS-02030US0]。

美国专利申请号11/548,239，标题为“Job Scheduler”，由Naresh Revanuru等人在2006年10月10日提交[代理人案号BEAS-02031US0]。

美国专利申请号11/550,551，标题为“Database-Less Leasing”，由NareshRevanuru等人在2006年10月18日提交[代理人案号BEAS-02029US0]。

背景技术

为了处理大量的交互，企业软件应用可使用应用服务器，例如像从San Jose，California的BEA Systems，Inc.可得到的WebLogic ServerTM这样的J2EE应用服务器。这些应用服务器可用在可相互交互的群集中。

应用服务器的某些服务，称为单例服务，应当仅运行在群集的一个应用服务器上。这些单例服务可包括JMS服务器、事务恢复服务或者应当仅以单个实例运行的任何其它软件。

附图说明

图1示出了基于数据库的租赁系统。

图2示出了本发明的一个实施例的无数据库的租赁系统。

图3A和3B示出了本发明的一个实施例的无数据库的租赁系统。

图4A到4C示出了本发明的一个实施例的自动可迁移服务系统。

图5A和5B示出了作业调度器系统。

实施方式

无数据库的租赁

图1示出了使用数据库102的租赁系统的示例。在该示例中，群集110的应用服务器104、106和108可依靠数据库来提供对租约表102的访问。在租约表102处的租约可用于指示什么应用服务器应当运行单例服务。这些租约可由运行该单例服务的应用服务器来更新。在崩溃的情况下，租约将不再被更新并且将变为无效。这可使得群集110的应用服务器之一可以接替曾在控制租赁系统的崩溃或隔离的应用服务器。

在某些情况下，期望避免对用于租赁的高可用性(HA)数据库的需要。本发明的实施例包括无数据库的租赁系统。

本发明的一个实施例是包括应用服务器204、206、208和210的群集202的计算机实现的方法。方法可包括确定群集领导者202，使用群集领导者212在应用服务器之一处建立租约表214，并且使用租约表214来维持用于单例服务218的至少一个租约216。

由于租约表存储在应用服务器处，故不需要数据库。在一个实施例中，在群集中的每个应用服务器处维持租约表的副本，使得在崩溃或隔离的情况下租约表的副本是可得到的。

租约表可用于允许单例服务的自动迁移。节点管理器可用于确定群集中应用服务器的状态。节点管理器可以是在应用服务器主机上运行的软件程序。节点管理器可用于开始和停止应用服务器的实例。

可选择群集中最早开始的应用服务器来成为群集领导者。在一个实施例中，通过一种竞争来选择群集领导者。群集中的每个服务器可周期性地尝试成为群集领导者。例如，群集中的每个服务器可每隔30秒尝试成为群集领导者一次。如果群集领导者已经存在，它们的尝试被拒绝。如果当前不存在群集领导者，则第一个尝试成为它的服务器成为群集领导者，从而阻止其它任何一个成为群集领导者。以该方式，可选择群集中最早开始的应用服务器来成为群集领导者。作为候选，系统可设计为使得可通过另一方法选择群集领导者。

群集领导者212可以维活(heart beat)群集的其它应用服务器。群集领导者212可在群集202的其它应用服务器中存储租约表的副本，以在一个或多个应用服务器崩溃或隔离的情况下操作。在一个实施例中，如果当前的群集服务器212未能维活其它应用服务器，则其它应用服务器可选择另一群集领导者。

本发明的一个实施例包括应用服务器204、206、208和210的群集202。基于首先启动的应用服务器选择群集领导者。群集领导者212用于在一个应用服务器204处建立租约表214。

本发明的一个实施例包括计算机实现的系统，其中在应用服务器的群集202的应用服务器204处维持租约表214。群集的其它应用服务器可使用租约表214来维持用于单例服务218的至少一个租约216。

图3A示出了群集领导者为群集的其它应用服务器提供数据。图3B示出了在成为当前群集领导者的应用服务器崩溃的情况下另一群集领导者被选择。本发明的一个实施例示出了在网络隔离使得第一应用服务器不可用的情况下另一群集领导者被选择。

自动可迁移服务

本发明的一个实施例是计算机实现的系统，其包括群集404中运行单例服务406的第一应用服务器402。第一应用服务器102在租约表410处维持用于单例服务406的租约408，迁移主控412检查租约表410并且如果第一应用服务器402未能维持租约408则将单例服务406重新分配给群集404的第二应用服务器414。租约表410可在数据库中维持，

或者通过使用如上所述的无数据库的租赁来维持。

由于第一应用服务器402的崩溃，第一应用服务器可未能更新租约，如图4B中所示，或者因为第一应用服务器402从租约表隔离，第一应用服务器402可未能更新租约，如图4C中所示。第一应用服务器402可维活租约408以维持对单例服务406的控制。单例服务可以是JMS服务器、定时器主控或者应当以单个实例运行的任何其它软件。

在得到单例服务之前，第二应用服务器414可运行预定的启动脚本。在放弃单例服务之后，第一应用服务器402可运行预定的停用脚本。迁移主控412可选择下一个应用服务器来运行单例服务，例如通过选择下一应用服务器。

在一个实施例中，如果单例服务是Java消息传送系统(JMS)服务则可存在专门的规则。如果单例服务是JMS服务，在任何迁移之前迁移管理器可尝试第一应用服务器上的重新启动。

一个实施例是计算机实现的方法或计算机可读介质，该介质包含代码以进行更新租约表410处用于单例服务的租约408的步骤。在第一应用服务器402处，用迁移主控412检查租约表410。另外，如果第一应用服务器不维持租约408，将单例服务406重新分配给第二应用服务器。

作业调度器

本发明的一个实施例是在群集506的应用服务器504处的定时器主控502。定时器主控502将所调度的作业分配给群集的其它应用服务器508、510和512。应用服务器504维持来自租约表516的用于定时器主控的租赁514。定时器主控502在数据库中存储所调度作业的作业信息520。在应用服务器504崩溃的情况下，可向群集506的另一应用服务器510分配可使用作业信息来分配所调度作业的定时器主控502。

所调度作业可包括报告，例如数据库报告。这种报告可需要大量的数据库访问并且因而占用大量的系统资源。所调度作业可因而调度为在非高峰时间运行以便不降低其它应用的性能。租约表可在数据库中，或者可使用无数据库的租赁系统作为候选。定时器主控502可以是单例服务。定时器主控502可由迁移主控分配给应用服务器510。其它应用服务器可从定 时器主控502请求作业。

本发明的一个实施例是计算机实现的系统，其包括在群集的应用服务器504处的定时器主控502。定时器主控502可将所调度作业分配到群集506的其它应用服务器508、510和512。在应用服务器504崩溃的情况下，可向群集506的另一应用服务器510分配可分配所调度作业的定时器主控。

本发明的一个实施例是群集506的应用服务器504，其将所调度作业分配给群集504的其它应用服务器。在应用服务器504崩溃的情况下，向另一应用服务器510分配定时器主控502。其后，使用在另一应用服务器510处的定时器主控502来分配所调度作业。

具体实施方式

下面描述一个示例实施例的细节。这些细节给出了如何实现所要求的本发明的一个示例并且不意味着限制本发明的范围或者缩小所要求项中任何一个的范围。

像自动服务器和服务迁移、群集范围单例和锁管理器这样的先进的群集特征可使用租赁和租约管理。租赁可保证群集中仅一个成员在可展期的某时间段内得到租约的所有权。知道它具有租约的排它所有权，租约所有者然后能够执行某些特权操作，像迁移失败的服务器。本说明书描述了如何可实现租赁和群集主控型功能，而无需依赖于像高可用性数据库这样的外部仲裁者。

可由子系统使用租约管理器来获得租约，登记在租约可用时得到租约的兴趣，找出租赁的当前所有者等。用于自动服务器迁移的一类租赁基础需要高可用性(HA)数据库的存在。换言之，租约表总是寄宿于数据库中并且数据库对于群集应当是高度可用的，以查询和更新租约。

租约表可寄宿在群集中的服务器之一中并且不在数据库中。这意味着群集成员可选举将容宿租约表并且成为群集领导者的服务器。该被选举的群集领导者可以负责分发租约，更新租约表以及原子地将更新复制到群集。复制对于故障用途是重要的。如果群集领导者变为不可用并且不向群 组发送心跳来声称它的存在，则成员可开始另一轮的投票来选举新的群集主控。新选举的主控可获得租约表的所有权。除了获得所有权和容宿租约表之外，群集主控还可执行故障群集节点的自动服务器迁移。

在一个实施例中，基于合意(consensus)的租赁可满足以下的要求：

1.在任何给定的时间点处将至多有一个群集主控。这意味着将从不会有一个以上的群集主控，但是可能在短暂的时期内群集没有群集主控。

2.就在群集启动之后当没有群集主控时将有短暂的时期。时期可能是分钟的阶数。

3.在当前群集主控死去时，新群集主控的选举所可以花费的时间等于以下各项的和：

1.心跳超时(下一投票时间)。这是在其间群集成员没有接收到来自群集主控的任何心跳的时间段。默认该时段为30秒。

2.算法为达到合意而花费的时间。

4.用户可标记其中可产生群集主控的群集子集。由于冗余网络连接的存在等，该子集更好地适于参与合意。但是这意味着，如果合意列表中的所有成员死去，那么群集将没有群集主控。强烈建议合意列表属于分离的机器。

可充当群集主控并且参与合意算法的群集成员可用config.xml中的专用ConsensusProcessIdentifier来标记。该标识符可以是唯一的整数值。这可以是关于ServerMBean的属性。客户应当恰能够标记可充当群集主控的服务器并且产品应当能够自动生成标识符。可存在关于ClusterMBean的另一属性，其指定合意参与者的总数目。在一个实施例中，该属性称为ConsensusParticipants。它可以是群集中具有CunsensusProcessIdentifier的服务器的总计。

达成谁将是群集领导者的协议可以是耗费时间的过程。一旦选举了群集领导者，可由群集领导者直接仲裁对于租约的请求，而不必经过一轮合意。群集领导者将更新租约表并且将更新复制到合意列表中的所有其它成员。这可以不同于数据库租赁。在数据库租赁中，包括用于群集领导者的租约的所有租约可在数据库中同等维持。以合意租赁的基础，群集领导者 租约可用于快速地准予其它租约。

选择默认的租赁基础是可能的。合意租赁基础可以是默认的设置。消费者可用数据库租赁基础来覆盖默认，如果他们想要这样。诸如ClusterMBean.setMigrationBasis()之类的值可控制默认。

控制台可允许客户选择哪些群集节点可充当群集主控并且自动生成合意过程标识符。它还可基于在群集中选择的服务器的数目来设置值ClusterMBean.setConsensusParticipants()。

合意租赁基础，像所有其它的LeasingBasis接口的实现一样，可对子系统和外部用户隐藏。子系统可通过实现weblogic.cluster.singleton.SingletonService接口并且然后向SingletonService管理器登记来请求单例服务。锁管理器也可以实现于租赁之上。

当可迁移服务由于任何原因(服务代码中的程序缺陷、服务器崩溃、网络隔离)而变为不可用时，它可在其当前位置被停用并且在新服务器上启用。如果在新服务器上启用时存在故障，它可在该服务器上停用并且再次迁移。默认地，我们可尝试在群集中的每个候选服务器上开始直到它已经开始或者在每一个上失败为止。如果它在每一个候选服务器上失败，它可记录错误并且让它停用。

服务的活性可由租赁的维持来证实。其上存活有服务的服务器可以负责经由心跳机制保持租约存活。服务器崩溃可自然地导致租赁超时。在一个实施例中，每个可迁移目标仅存在一个租约。该目标上的所有服务可共享该租约。在一个实施例中，可认为目标上的所有服务有些相互依赖。(或者至少，用户应当容忍目标上一个失败的服务造成整个目标迁移)。在一个实施例中，管理服务器不需要对于自动迁移是活动的。

迁移主控(MM)可跟踪应当保持存活的所有服务。信息可从配置得到。这是有用的，因为如果服务是未租出的，那么它将不在存在于要监视的表中。跨越群集中的所有服务，配置可以是相同的。

服务器可以处于管理器服务独立(MSI)模式并且仍然参与自动迁移。唯一的限制是不可开始新服务。在一个实施例中，如果它们部署到单个服务器，没有管理服务器分发配置改变，服务将不会被自动迁移。当管 理服务器开始并且同步每个人的配置时，可为任何新添加的服务启用迁移(并且即使管理服务器随后关机，迁移可持续)。

如果租约丢失(例如，网络发布可造成租约丢失)，服务器可停用其服务。MM可在另外某处开始服务。如果网络连接在停用之后但是在MM注意租约超时之前恢复，这可导致冗余的停用调用，但是停用是等幂的。

如果服务是不健康的然而尚未断开的，它将向可迁移目标传达并且告诉它放弃租赁。MM将注意租赁消失/超时，并且将迁移它。

以下方法可添加到MigratableTarget：

/**

*当Migratable类检测到故障并且需要停止和在不同服务器上开始时被它们调用。应当仅用于可迁移对象的不可恢复故障。如果shutdownServer为true(如对于JTA它将是这样)，那么服务器将关机并且服务因此而停用。*/public void failedService(StringserviceName，Boolean shutdownServer)

围栏的处理可以不同于JTA的情况。如果停用花费很长时间，则无法保证在下一服务器尝试启用服务之前停用它。在该情况下，如果优雅的关机花费的时间比租约时段更长，服务器可立即并且突然地退出。它的服务可由为可迁移服务新选择的家来接管和恢复。

迁移主控在注意到期满租约时，可开始迁移。它可设置注释已为特定服务开始迁移的标志。这可防止在之前迁移的中间重新注意期满租赁并且再次迁移。(同样的机制用在服务器迁移中。)

服务(如果它仍是可用的)的当前位置可停用它本身。然后新位置可调用目标上的启用。这可以是与原始可迁移服务中相同的代码路径。然而，可引入另外的步骤。

当目标正被启用时，它的第一动作可以是要求租赁。这可使迁移主控停止经常地检查它的活性。它还可提供关于操作的原子锁；当该目标持有租赁时，没有另外的一个可以是启用的。

接下来，服务可检查是否为其指定了指名的节点主控(MM)预迁移脚本。然后，它可检查当前机器上节点管理器的存在。如果节点管理器不在那，但是存在指定的脚本，它可停止迁移。如果节点管理器在那，它可 检查看节点管理器是否已执行了指定的预迁移脚本。如果节点管理器尚未运行脚本，它可告诉节点管理器运行预迁移脚本。额外标志可传递到该脚本，以允许在我们正迁移JTA、JMS或完全不同的某些东西时脚本做某些不同的事情。例如，可提供占位符脚本，但是不需要完成特定的tlog迁移。

在一个实施例中，在节点管理器肯定地响应它已运行了预迁移脚本之前，启用将不会继续下去。我们可进行重复的尝试来运行预迁移脚本。如果由于某些原因未成功，迁移将停止，并且我们将让迁移主控将我们迁移到新服务器。

在此时，我们依次调用可迁移服务的activate()方法。如果它们都运行没有异常，迁移现在完成。

如果在启用期间存在错误，我们可停止并且进入停用模式。

停用本质上是启用的反面。首先，停用服务器可以指定顺序调用所有服务上的停用。将记录异常，但是不采取动作。

一旦所有的服务已被调用了停用，我们将执行另一节点主控检查。服务将检查是否为其指定了指名的节点主控后迁移脚本。然后，它可检查当前机器上节点管主控的存在。如果节点管理器在那，检查看节点管理器是否已执行了指定的后迁移脚本。如果节点管理器尚未运行脚本，告诉节点管理器运行后迁移脚本。额外标记可传递到该脚本，以允许在我们正迁移JTA、JMS或完全不同的某些东西时脚本做某些不同的事情。例如在一个实施例中，我们可提供占位符脚本，但是无法完成特定的tlog迁移。

如果后迁移脚本失败，将运行杀死脚本，如果可得到的话。如果杀死脚本失败，启用可照常继续。在最坏的情况下，当已解决问题时，我们可在各处停用并且让管理器重启用它。最后，当脚本部分是完整的时，服务将放弃租赁。脚本将在手工迁移期间被运行，如果指定的话。

在一个实施例中，没有自动恢复机制。默认地，服务可永远活在它的新位置。管理员可在任何时间以与他们之前所做的同样方式来手工将目标迁移到新(或者，在自动恢复的情况下为旧)服务器。

如果服务迁移到每个服务器并且从未成功启用，它可被停用。关于MigratableTargetMBean的可选设置可控制根据完整群集循环数目要进行多少次尝试。注意，现有可迁移目标限制仍然可应用：如果指定候选服务器，将仅尝试候选服务器列表中的服务器。

AdditionalMigrationAttempts可默认为零。它可控制我们将尝试跨越群集(或者候选服务器列表，如果指定的话)中的每个服务器迁移服务的次数。例如，如果群集有3个成员，并且AdditionalMigrationAttempts设置为2，我们可尝试在群集中的每个服务器上开始它，然后暂停，再尝试，暂停，并且尝试最后一次。在该示例中，这意味着每个服务器可有3次机会来成功地启用服务。

在迁移尝试之间的暂停可由诸如MillisToSleepBetweenAttenpts之类的值来控制。在一个实施例中，这仅控制当服务未能在任何服务器上启用所以我们返回最初并且再次尝试时发生的暂停。当进行正常迁移时，不需要存在延迟。

以下方法可添加到MigratableTargetMBean：

/*

*可迁移服务可未能在每个可能配置的服务器上启用。该属性控制在服务已在每个服务器上失败至少一次之后，还应当尝试多少次。注意，这里指定的每次尝试表示在所有经配置服务器之间的迁移的另一完全流程。所以对于3服务器的群集并且值为2的情况，将尝试总共4次另外的迁移。(原始服务器从不是有效的目的地)*/

get/setAdditionalMigrationAttempts()

/**

*控制在getAdditionalMigrationAttempts()中描述的迁移尝试之间应当有多长的暂停。注意，该延迟仅在服务在每个服务器上都未能启用时发生。它不会造成其他迁移尝试之间的任何类型的延迟。*/

get/setMillisToSleepBetweenAttenpts()

JMS应当能够重新启动它本身，而不必经受实际的迁移(对于正在讨论的问题，为了性能目的，进行完全的迁移将是浪费时间。为了它们的目的，将方法添加到迁移管理器，该方法将请求对指定服务的服务重新启动，或者在相同服务器上的停用和重新启用；没有资源被释放或获得。请求‘软迁移’。指定的可迁移服务将停用并且然后在相同的服务器上重新启用。节点管理器脚本将不被调用。依赖该可迁移的服务也将重新启动restartMigratable(Migratable m)。在满足某阈值之后，在一个服务器上的重复、快速的重新启动尝试将解释为错误，并且目标将迁移。因为这是仅设计用于内部使用的方法，不需要提供阈值的外部配置。ServerMBean上的隐藏get/set方法可控制可进行多少次尝试并且时段是多长。(例如，它可设置为在12小时时段内允许最多3次重新启动。)get/setAllowedRestartedAttempts()控制在getIntervalForRestartAttemptThrottling()中指定的间隔内服务可以重新启动多少次。getIntervalForRestartAttemptThrottling()控制将多长的间隔用于节流重新启动尝试。参见getAllowedRestartAttempts()，get/setIntervalForRestartAttemptThrottling()。

迁移主控可以是类似于群集主控的服务。它可以是轻量单例的，无状态的，并且以与群集主控相同的方式通过租赁竞争来维持。每个服务器可登记对获得迁移主控租约的永久兴趣。无论服务器当前持有什么，它可执行迁移任务的开始和停止。如果当前迁移主控崩溃或者关机，将由租赁基础设施选择等待服务器之一来接管租约，从而成为新的迁移主控。迁移主控不必与群集主控并列排置。

迁移主控可以是迁移信息的储存库。它可保持它已完成的所有迁移的 记录(目标名、源服务器、目的服务器、时间戳)。如果管理服务器可用，它可向管理服务器报告迁移以供控制台/JMX/WLST显示。

当迁移发生时，可添加非调试级记录以向用户提供信息。可记录服务器上目标的启用和停用。当前迁移主控可记录迁移的细节：源、目的、目标名、时间。它还可记录每次迁移是通过还是失败。可将失败的迁移记录为警告，而非错误。如果服务不能在任何服务器上成功地开始，我们将记录错误。

可存在新接口，SingletonService。MigratableTarget可修改为扩展SingletonService。MigratableTarget可以存活在MigratableTarget上的某些当前服务所需的预/后启用脚本的方式来提供另外的功能。注意，某些服务可实现的Migratable接口不是SingletonService。Migratable仅意味着类可针对MigratableTarget。实际上由代码操作的是MigratableTarget本身。目标可视情况开始/停止Migratable类，如它们总是这样。

SingletonService接口可由寻找轻量群集范围单例的客户或内部用户来实现。它没有与MigratableTarget(其将支持脚本、候选机器等)一样多的特征，但是更易于配置和创建。

SingletonService可通过对本身调用停用来请求立即迁移。MM将注意消失的租约并且将把服务迁移到新位置。

Interface SingletonService

/*

*这在服务器开始时并且在迁移的启用阶段期间被调用。它应当获得任何系统资源并且启动SingletonService要开始服务请求所需的任何服务。

*/

public void activate()

/*

*这在服务器关机时并且在迁移的停用阶段期间被调用。它应当释放在启用时获得的任何资源，并且停止应当仅可以从群集中一个提供者得到的任何服务。

*/

public void deactivate()

MigratableTargetMBean可具有额外、可选的属性。PreScript、PostScript和AutoMigratable。

以下方法可添加到MigratableTargetMBean

/**

*设置自动可迁移值。如果可迁移目标是自动可迁移的，则它将在其当前存活于的服务器关机或故障时被自动迁移。

*/

Get/setAutoMigratable()

/**

*设置在可迁移目标实际被启用之前运行的脚本。在启用目标前，如果存在指定的脚本和可用的节点管理器，我们将运行脚本。在没有可用的节点管理器的情况下设置脚本将导致在迁移时的错误。如果脚本失败或者不能找到，迁移将不会在当前服务器上继续进行，并且将在下一适合服务器上被尝试。(候选服务器列表中的下一服务器，如果没有候选者列表则为群集中的下一服务器。)

*/

get/setPreScriptFileName()

/**

*设置在完全停用可迁移目标之后运行的脚本。在停用目标之后，如果存在指定的脚本和可用的节点管理器，我们将运行脚本。在没有可用的节点管理器的情况下设置脚本将导致在迁移时的错误。如果脚本失败或者不能找到，迁移将仍继续进行。

*/

get/setPostScriptFileName()

/**

*设置在可迁移目标的后脚本失败的情况下运行的脚本。没有可用的节点管理器的情况下设置脚本将导致在迁移时的错误。如果脚本失败或者不能找到，迁移仍将继续进行。

*/

Get/setKillScriptFileName()

控制台可迁移目标页可需要额外的复选框来允许使得能够进行自动迁移。不需要预脚本和后脚本，但是如果它们存在将会被执行。用于可迁移目标的控制台编辑页可具有可设置的这些选项。

在存在依赖的情况下，针对一个可迁移目标的多个可迁移服务可指定它们启用的顺序。自动可迁移的目标不需要相关于彼此来排序。服务顺序将仍然有关于目标是否是自动可迁移的。

排序不需要暴露给消费者。可迁移目标基础设施通常仅是内部的。

可允许可迁移服务指定在它们的MBean中的部署顺序。行为在部署顺序上建模。可存在接受整数的称为‘Order’的值。(包括负值。)当请求目标启用它的组件服务时，它可以从最小Order到最大Order的顺序来这么做。如果没有指定Order，可指定默认值。为了一致性，这可以是部署顺序使用的同样的默认：100。如果两个服务具有相同的Order数，不保证它们的启用顺序相关于彼此。

当请求目标停用它的组件服务时，它可以从最大Order到最小Order的顺序来这么做。注意，如果两个服务具有相同的Order数，不保证它们的停用顺序是它们启用顺序的相反。

Order可以是动态值。Order的当前值总是使用过的。这意味着，如果 Order在启用和停用之间改变，序列可能不是彼此的精确相反。

失败启用的情况可遵循与正常启用和停用相同的规则。成功启用的服务的停用可以相反的顺序发生，除非Order号是一样的。在该情况下，停用顺序可以不是启用顺序的相反。

Weblogic.cluster.migration.Migratable接口可具有以下添加的方法：

/**

*返回用于该特定可迁移对象的顺序值。这控制该对象相关于部署在可迁移目标上的其它可迁移对象将以哪个顺序来启用和停用。

*/

public int getOrder()

可用另外的setOrder方法来扩充实现和MBeans，以允许该值的用户配置。然而，这不是必需的。它取决于每个单个实现者来判定他们是否想要顺序可配置。

默认的顺序变量可在基础接口：DEFAULT_ORDER中提供。默认地，所有当前的实现类将从getOrder()调用将其返回。这可保证当前的行为将不会改变，直到人们进行了特定的努力来改变它们的排序为止。

作业调度器可使得定时器知道群集并且提供了在群集中任何地方执行它们的能力。定时器不再依靠创建它们的服务器。

本说明书的目的是：

1.使得定时器知道群集。定时器应当能够在群集中任何地方执行并且按需要故障转移(failover)。

2.提供在应用服务器群集内的执行的守护程序作业类型。用户应当能够指定像“重复地在群集中的某些地方执行该作业。如果在群集中存在至少一个运行的成员，作业应当运行。”一样的事情。对实际创建定时器的服务器没有依赖。定时器执行是跨越群集平衡的负载并且能够在故障的情况下故障转移到另一运行成员。

存在基于它们的生命周期不同的两类定时器。

本地定时器

本地定时器可在服务器JAVA虚拟机(JVM)内调度并且在相同的 JVM内永远存活。只要JVM存活，定时器运行，并且当JVM退出时定时器死去。应用需要在随后的服务器启动时重新调度定时器。

群集范围的定时器

群集范围的定时器可知道形成相同群集的部分的其它服务器JVM并且能够负载平衡和故障转移。定时器生命周期不绑定到创建它的服务器而是绑定到群集的生命周期。只要至少一个群集成员存活，定时器能够执行。这种定时器能够幸免于完整的群集重新启动。群集范围的定时器由作业调度器创建和处理。

每种类型具有它自己的优点和缺点。本地定时器可以毫秒的阶数处理微粒度的周期。作业调度器不能用如定时器需要被持续的精度来处理微粒度的周期。群集范围的定时器以几秒或更大的阶数用粗粒度的间隔工作得很好。作业调度器可用于调度作业，像每天或者在每周结束时运行报告。即使创建它的服务器不再可用也运行作业是重要的。其它群集成员可确保作业继续执行。

作业调度器可满足以下要求：

1.使用客户配置的数据库来持续定时器并且使得它们对于整个群集可用。作业调度器是依赖于数据库的并且不能没有它而工作。支持Oracle、DB2、Informix、MySQL、Sybase、MSSQL。

2.在一个实施例中，作业调度器将仅在群集中工作。

3.所提交的作业可在群集中任何地方运行。作业的两个连续执行可在相同服务器上或不同服务器上运行。仅一个服务器可在任何给定的时间点执行作业。

4.作业调度器依赖于租赁。需要租赁支持来选举定时器主控。每个服务器在执行作业之前也可使用租赁来要求对作业的所有权。

5.作业调度器可使用与服务器迁移和单例服务相同的租赁基础。

6.作业调度器可使用良好定义的名称绑定到每个服务器的全局JNDI树内。JNDI名可以是“weblogic.JobScheduler”。用户可将所查找的对象转型为commonj.timers.TimerManager并且使用它的方法来创建作业。

7.作业调度器仅接受可串行化的作业。非可串行化的作业可使用IllegalArgumentException来拒绝。

8.ClusterMBean可暴露称为DataSourceForJobScheduler的属性，该属性将用于访问数据库。在一个实施例中，作业调度器功能仅在配置数据源的情况下可得到。

9.在一个实施例中，作业调度器将仅支持以固定延迟调度的功能。两个连续的作业执行由‘间隔’时期分离。

10.在一个实施例中，仅支持作业的循环负载平衡。每个群集成员将周期性地投票定时器主控(其仅仅是另一群集成员)用于要执行的就绪作业。定时器主控将向每个成员给出总的就绪作业的片段用于执行。

作业调度器可需要数据库用于持续定时器。服务器迁移功能支持的所有数据库也可由作业调度器支持。作业调度器可使用ClusterMBean.getDataSourceForJobScheduler()访问数据库。用户可创建称为“weblogic_timers”的表，其具有以下字段：

名称	类型
		——————	——————
		TIMER_ID	NUMBER
TIMER_INFO	VARchar2(100)
		TIMER_MANAGER_NAME	VARchar2(100)
CLUSTER_NAME	VARchar2(100)
		DOMAIN_NAME	VARchar2(100)
TIMER_LISTENER	BLOB
		NEXT_EXECUTION_TIME	NUMBER
INTERVAL	NUMBER

在一个实施例中，作业调度器仅在群集中工作。所有群集节点可参与执行作业而没有区别。在一个实施例中，仅在将DataSourceForJobScheduler ClusterMBean属性设置为config.xml中的有效数据源时，将开启作业调度器。这里是示例：

可使用JNDI名“weblogic.JobScheduler”来查找作业调度器并且将其转型为Commonj.timers.TimerManager。这里是示例：

jobScheduler.schedule(timerListener，0，30*1000)；//每隔30秒执行该作业

作业调度器可在执行之前使用租赁功能来要求单个定时器的所有权，并且选择定时器主控。定时器主控可完全在一个群集成员上运行并且负责将定时器分配到单个服务器。租赁基础可依赖于ClusterMBean.getLeasingBasising()属性。如果LeasingBasis设置到数据库，那么与数据库租赁相关联的配置可就像在服务器迁移中一样来设置。如果LeasingBasis设置为“合意”，那么对于租赁不需要数据库支持。

控制台可提供选项来设置ClusterMBean.setDataSourceForJobScheduler()。数据源可从在关机期间的服务器迁移或者会话连续性继承。如果客户配置用于一个的数据源，他们应当也能够对于作业调度器功能重用它。

可使用根据本公开教导编程的常规通用的专用数字计算机或微处理器来实现一个实施例，如对于计算机领域技术人员将是明显的。基于本公开的教导可容易地由熟练的编程者准备适当的软件编码，如对于软件领域技术人员将是明显的。本发明还可通过准备集成电路或者通过互连常规组件电路的适当网络来实现，如对于本领域技术人员将很容易明显的。

一个实施例包括作为存储介质(媒体)的计算机程序产品，所述存储介质在其上/其中存储了可用于编程计算机以执行这里给出的任何特征的指令。存储介质可包括但不限于任何类型的磁盘，包括软盘、光盘、DVD、CD-ROM、微驱动器、和磁光盘、ROM、RAM、EPROM、EEPROM、DRAM、媒体的闪存或者适于存储在任何一种计算机可读介质(媒体)上存储的指令和/或数据的设备，本发明可包括用于控制通用/专用计算机的硬件或微处理器，并且用于使得计算机或微处理器能够与人类用户或者利用本发明结果的其它机构交互的软件。该软件可包括但不限于设备驱动、操作系统、执行环境/容器、和用户应用。

本发明的实施例可包括提供用于实现本发明过程的代码。该提供可包 括以任何方式将代码提供给用户。例如，提供可包括向用户发送包含代码的数字信号；向用户提供物理媒体上的代码；或者使得代码可得到的任何其它方法。

本发明的实施例可包括用于发送代码的计算机实现的方法，该代码可在计算机上执行以执行本发明实施例的任何一种过程。发送可包括通过网络的任何部分，例如因特网的；通过线缆、空气或空间的；或者通过任何其它类型的传输来传送。发送可包括发起代码传输；或者使得代码从另一区域或者国家传递进入任何区域或者国家。例如，发送包括使得作为之前寻址的结果将代码通过网络的部分传送并且将包括代码的数据发送到用户。到用户的传输可包括由任何区域或国家中的用户接收任何传输，不管传输从什么位置发送。

本发明的实施例可包括包含可在计算机上执行以执行本发明实施例的任何一种过程的代码的信号。信号可通过网络，例如因特网；通过线缆、空气或空间；或者通过任何其它类型的传输来发送。不需要全部信号同时在运输中。信号可随着它的传送周期而及时扩展。信号不被认作为当前运输中的快照。

已为说明和描述的目的提供了本发明的优选实施例的前述描述。它不旨在是穷尽的或者将本发明限于公开的精确形式。对于有关领域中的普通技术人员来说，许多修改和变化将是明显的。例如，所公开的本发明实施例中执行的步骤可以交替顺序来执行，可省略某些步骤，并且可添加另外的步骤。选择和描述实施例以便最好地说明本发明的原理及其实际应用，由此使得本领域其它技术人员能够理解用于各种实施例并且具有各种修改的本发明，所述修改适于特定使用的预期。旨在本发明的范围由权利要求及其等同物来定义。

Claims (21)

1.一种计算机实现的系统，用于在群集内提供作业的调度，其特征在于，所述计算机实现的系统包括：

群集，其包括多个应用服务器；

作业调度器，其接受要由所述群集在所调度的时间执行的作业；

作为单例服务在所述群集内提供的定时器主控，其中所述定时器主控在所述群集内被使用以分配所调度作业到所述群集内的应用服务器，并且其中所述所调度作业被调度为在所述所调度的时间在所分配的应用服务器上开始；

租约表，其记录群集内的哪个应用服务器当前正维持所述群集的定时器主控的租约并且担当所述群集的定时器主控；

数据库，用于永久性存储作业信息以使得所述作业信息能够被群集内的所有应用服务器共享；

其中，所述应用服务器周期性地轮询定时器主控要执行的作业，并且其中响应于被轮询，定时器主控分配所调度作业的一部分给轮询的应用服务器以由该轮询的应用服务器执行；以及

其中，如果当前担当定时器主控的应用服务器发生故障，被当前定时器主控确定为不能更新其租约，则群集内的另一个应用服务器被选择为担当定时器主控，并且其使用在数据库中存储的作业信息来继续在群集内分配所调度作业。

2.如权利要求1所述的计算机实现的系统，其中所调度作业包括报告。

3.如权利要求2所述的计算机实现的系统，其中所述报告是数据库报告。

4.如权利要求1所述的计算机实现的系统，其中所述租约表在所述数据库中。

5.如权利要求1所述的计算机实现的系统，其中所述定时器主控由迁移主控分配给所述另一个应用服务器。

6.如权利要求1所述的计算机实现的系统，其中其它应用服务器从定时器主控请求作业。

7.如权利要求1所述的计算机实现的系统，其中所述作业被调度为在非高峰时间运行。

8.一种用于在群集内调度作业的方法，其特征在于，所述方法包括：

提供包括多个应用服务器的群集；

提供作业调度器，其接受要由所述群集在所调度的时间执行的作业；

提供作为单例服务在所述群集内提供的定时器主控，其中所述定时器主控在所述群集内被使用以分配所调度作业到所述群集内的应用服务器，并且其中所述所调度作业被调度为在所述所调度的时间在所分配的应用服务器上开始；

维持租约表，其记录群集内的哪个应用服务器当前正维持所述群集的定时器主控的租约并且担当所述群集的定时器主控；

提供数据库，用于永久性存储作业信息以使得所述作业信息能够被群集内的所有应用服务器共享；

其中，所述应用服务器周期性地轮询定时器主控要执行的作业，并且其中响应于被轮询，定时器主控分配所调度作业的一部分给轮询的应用服务器以由该轮询的应用服务器执行；以及

其中，如果当前担当定时器主控的应用服务器发生故障，被当前定时器主控确定为不能更新其租约，则群集内的另一个应用服务器被选择为担当定时器主控，并且其使用在数据库中存储的作业信息来继续在群集内分配所调度作业。

9.如权利要求8所述的方法，其中所调度作业包括报告。

10.如权利要求9所述的方法，其中所述报告是数据库报告。

11.如权利要求8所述的方法，其中所述租约表在所述数据库中。

12.如权利要求8所述的方法，其中所述定时器主控由迁移主控分配给所述另一个应用服务器。

13.如权利要求8所述的方法，其中其它应用服务器从定时器主控请求作业。

14.如权利要求8所述的方法，其中所述作业被调度为在非高峰时间运行。

15.一种用于在集群内调度作业的系统，其特征在于，所述系统包括：

用于提供包括多个应用服务器的群集的装置；

用于提供作业调度器的装置，所述作业调度器接受要由所述群集在所调度的时间执行的作业；

用于提供作为单例服务在所述群集内提供的定时器主控的装置，其中所述定时器主控在所述群集内被使用以分配所调度作业到所述群集内的应用服务器，并且其中所述所调度作业被调度为在所述所调度的时间在所分配的应用服务器上开始；

用于维持租约表的装置，所述租约表记录群集内的哪个应用服务器当前正维持所述群集的定时器主控的租约并且担当所述群集的定时器主控；

用于提供数据库的装置，所述数据库用于永久性存储作业信息以使得所述作业信息能够被群集内的所有应用服务器共享；

其中，所述应用服务器周期性地轮询定时器主控要执行的作业，并且其中响应于被轮询，定时器主控分配所调度作业的一部分给轮询的应用服务器以由该轮询的应用服务器执行；以及

其中，如果当前担当定时器主控的应用服务器发生故障，被当前定时器主控确定为不能更新其租约，则群集内的另一个应用服务器被选择为担当定时器主控，并且其使用在数据库中存储的作业信息来继续在群集内分配所调度作业。

16.如权利要求15所述的系统，其中所调度作业包括报告。

17.如权利要求16所述的系统，其中所述报告是数据库报告。

18.如权利要求15所述的系统，其中所述租约表在所述数据库中。

19.如权利要求15所述的系统，其中所述定时器主控由迁移主控分配给所述另一个应用服务器。

20.如权利要求15所述的系统，其中其它应用服务器从定时器主控请求作业。

21.如权利要求15所述的系统，其中所述作业被调度为在非高峰时间运行。