支持多租户应用服务器环境中的补丁修补的系统和方法与流程

本专利文献的公开的一部分包含受版权保护的材料。版权所有者不反对任何人对专利文献或者专利公开进行传真复制，如其在专利和商标局专利文件或记录中那样，但是在除此之外的任何情况下保留所有版权权利。优先权要求和相关申请的交叉引用本申请要求于2014年9月24日提交的、标题为“SYSTEMANDMETHODFORMULTITENANT-AWAREPATCHINGINAMULTITENANTAPPLICATIONSERVERENVIRONMENT”的、申请号为62/054,903的美国临时申请的优先权权益；并且与于2015年1月21日提交的、标题为“SYSTEMANDMETHODFORSUPPORTINGMULTI-TENANCYINANAPPLICATIONSERVER,CLOUD,OROTHERENVIRONMENT”申请号为14/601,883的美国专利申请有关；上面申请中的每一个通过引用结合至此。
技术领域：
本发明的实施例一般地涉及应用服务器和云平台环境，并且具体而言涉及用于支持在多租户(multitenant)应用服务器环境中补丁修补(patching)的系统和方法。
背景技术：
：在应用服务器和其他企业计算环境中，管理员的常见任务是需要对支持多个域的一系列应用服务器安装进行补丁修补。补丁可以包括具体问题的一次性修复(one-offfix)，或者周期性的版本更新。不管为什么需要安装补丁，管理员通常必须在域的每个节点上执行复杂的一系列步骤以便铺开(rollout)补丁同时最小化应用停机时间，这包括：确保在每个主机上补丁修补环境都是最新的；关闭在主机上运行的那些服务器；以及然后进行补丁修补并且重启应用服务器实例以及验证补丁正确地工作。因为补丁修补是复杂的过程，并且即使对于单个应用服务器实例都可能消耗许多分钟，当补丁应用于域中的所有节点时，这可能变成数个小时，所以该过程对于冒着系统停机时间可能性风险的用户可能造成焦虑。技术实现要素：根据实施例，这里描述的是用于支持在多租户应用服务器环境中补丁修补的系统和方法。系统可以将一个或多个分区与租户相关联以由该租户使用，其中分区是域的运行时和监管性细分(subdivision)或切片(slice)。补丁修补过程可以利用由应用服务器集群环境提供的高可用性特征，以便在受控的滚动重启中应用补丁，这维持域的无中断操作或者零停机时间操作的能力。该过程可以用来将复杂的或者长期运行的任务自动化，包括保存应用服务器、应用或者其他软件组件的未经补丁修补版本或者先前版本以用于可能的回退(rollback)，或者在不可复原的错误的情况下提供自动恢复(reversion)。附图说明图1例示根据实施例的在应用服务器、云或者其他环境中支持多租赁(multi-tenancy)的系统。图2进一步例示根据实施例的在应用服务器、云或者其他环境中支持多租赁的系统。图3进一步例示根据实施例的在应用服务器、云或者其他环境中支持多租赁的系统。图4例示根据实施例的与示例性多租户环境一起使用的域配置。图5进一步例示根据实施例的示例性多租户环境。图6例示根据实施例的对于补丁修补的支持。图7进一步例示根据实施例的用于补丁修补的系统，包括对于会话处置的支持。图8进一步例示根据实施例的用于补丁修补的系统，包括对于会话兼容性检测的支持。图9进一步例示根据实施例的用于补丁修补的系统。图10进一步例示根据实施例的用于补丁修补的系统。图11进一步例示根据实施例的用于补丁修补的系统。图12进一步例示根据实施例的用于补丁修补的系统。图13例示根据实施例的补丁修补事件图。图14例示根据实施例的另一个补丁修补事件图。图15例示根据实施例的另一个补丁修补事件图。图16例示根据实施例的用于补丁修补的方法的流程图。具体实施方式根据实施例，这里描述的是用于支持在多租户应用服务器环境中补丁修补的系统和方法。系统可以将一个或多个分区与租户相关联以由该租户使用，其中分区是域的运行时和监管性细分或切片。补丁修补过程可以利用由应用服务器集群环境提供的高可用性特征，以在受控的滚动重启中应用补丁，这维持域的无中断或者零停机时间操作的能力。该过程可以被用来将复杂的或者长期运行的任务自动化，包括保存应用服务器、应用或者其他软件组件的未经补丁修补版本或者先前版本以用于可能的回退，或者在不可复原的错误的情况下提供自动恢复。应用服务器(例如，多租户，MT)环境图1例示根据实施例的用于在应用服务器、云或者其他环境中支持多租赁的系统。如图1中所例示的，根据实施例，使得能够进行软件应用的部署及执行的应用服务器(例如，多租户，MT)环境100或者其他计算环境可以被配置为包括域102配置并且根据域102配置进行操作，域102配置在运行时使用以定义应用服务器域。根据实施例，应用服务器可以包括被定义以用于在运行时使用的一个或多个分区104。每个分区可以与全局唯一分区标识符(ID)以及分区配置相关联，并且可以进一步包括一个或多个资源组124(连同对资源组模板的引用126)和/或分区特定(partition-specific)的应用或资源128。域级别的资源组、应用和/或资源140也可以在域级别定义，可选地具有对资源组模板的引用。每个资源组模板160可以定义一个或多个应用A162、B164、资源A166、B168和/或其他可部署的应用或资源170，并且可以由资源组引用。例如，如图1中所例示的，分区104中的资源组124可以引用190资源组模板160。一般而言，系统管理员可以定义分区、域级别的资源组和资源组模板以及安全性领域；而分区管理员可以例如通过创建分区级别的资源组、将应用部署到分区或者引用分区的具体领域来定义他们自己分区的方面。图2进一步例示根据实施例的在应用服务器、云或者其他环境中支持多租赁的系统。如图2中所例示的，根据实施例，分区202可以包括例如资源组205、虚拟目标(例如，虚拟主机)信息207以及可插拔数据库(PDB)信息208，资源组205包括对资源组模板210的引用206。资源组模板(例如，210)可以定义例如多个应用A211和B212，以及诸如Java消息服务器(JMS)服务器213、存储和转发(SAF)代理215、邮件会话组件216或者Java数据库连接(JDBC)资源217之类的资源。图2中例示的资源组模板作为示例而提供；根据其他实施例，可以提供不同类型的资源组模板和元素。根据实施例，当分区(例如，202)内的资源组引用220特定的资源组模板(例如，210)时，与特定的分区相关联的信息可以与所引用的资源组模板组合使用，以指示分区特定的信息230(例如分区特定的PDB信息)。然后分区特定的信息可以由应用服务器使用以配置资源(例如PDB资源)以用于由该分区使用。例如，与分区202相关联的分区特定的PDB信息可以由应用服务器使用，以配置232具有适当的PDB238的容器数据库(CDB)236以用于由该分区使用。类似地，根据实施例，与特定的分区相关联的虚拟目标信息可以用来定义239分区特定的虚拟目标240(例如，baylandurgentcare.com)以用于由该分区使用，然后该虚拟目标240可以经由统一资源定位符(URL)(例如，http://baylandurgentcare.com)变得可访问。图3进一步例示根据实施例的在应用服务器、云或者其他环境中支持多租赁的系统。根据实施例，使用诸如config.xml配置文件之类的系统配置来定义分区，该系统配置包括用于与该分区相关联的资源组和/或其他分区属性的配置元素。可以使用属性名称/值对按照分区指定值。根据实施例，可以在受管理的服务器/集群242或者可以提供对CDB243的访问并且可以经由web层244访问的类似环境内执行多个分区。这允许例如域或者分区与(CDB的)PDB中的一个或多个相关联。根据实施例，多个分区中的每个分区(在此示例中为分区A250和分区B260)可以被配置为包括与该分区相关联的多个资源。例如，分区A可以被配置为包括资源组251，资源组251包含应用A1252、应用A2254以及JMSA256，连同与PDBA259相关联的数据源A257，其中该分区可经由虚拟目标A258访问。类似地，分区B260可以被配置为包括资源组261，资源组261包含应用B1262、应用B2264以及JMSB266，连同与PDBB269相关联的数据源B267，其中该分区可经由虚拟目标B268访问。虽然上面示例中的几个例示了CDB和PDB的使用，但是根据其他实施例，也可以支持其他类型的多租户数据库或者非多租户数据库，其中可以例如通过模式的使用或者不同数据库的使用，对于每个分区提供特定的配置。资源根据实施例，资源是系统资源、应用或者可以部署到环境的域的其他资源或对象。例如，根据实施例，资源可以是应用、JMS、JDBC、JavaMail、WLDF、数据源或者可以部署到服务器、集群或者其他应用服务器目标的其他系统资源或者其他类型的对象。分区根据实施例，分区是域的运行时和监管性细分或切片，分区可以与分区标识符(ID)和配置相关联，并且可以包含应用和/或通过资源组和资源组模板的使用来引用域范围(domain-wide)的资源。一般而言，分区可以包含它自己的应用，经由资源组模板引用域范围的应用，并且具有它自己的配置。可分区的实体可以包括资源(例如JMS、JDBC、JavaMail、WLDF资源)以及其他组件(诸如JNDI命名空间、网络流量、工作管理器以及安全性策略和领域)。在多租户环境的上下文中，系统可以被配置为提供对与租户相关联的分区的监管性和运行时方面的租户访问。根据实施例，分区内的每个资源组可以可选地引用资源组模板。分区可以具有多个资源组，并且它们中每一个可以引用资源组模板。每个分区可以定义在分区的资源组所引用的资源组模板中没有指定的配置数据的属性。这使得分区能够充当在资源组模板中定义的可部署资源到与该分区一起使用的具体值的绑定。在一些情况下，分区可以覆盖由资源组模板指定的配置信息。根据实施例，如例如由config.xml配置文件定义的分区配置可以包括多个配置元素，例如：“partition(分区)”，其包含定义分区的特性和子元素；“resource-group(资源组)”，其包含部署到分区的应用和资源；“resource-group-template(资源组模板)”，其包含由该模板定义的应用和资源；“jdbc-system-resource-override(JDBC系统资源覆盖)”，其包含数据库特定的服务名称、用户名和密码；以及“partition-properties(分区属性)”，其包含可以用于资源组模板中的宏替换(macroreplacement)的属性键值。当启动时，系统可以使用由配置文件提供的信息，从资源组模板为每个资源生成分区特定的配置元素。资源组根据实施例，资源组是可部署资源的已命名的、完全合格的集合(collection)，资源组可以在域或者分区级别定义，并且可以引用资源组模板。资源组中的资源被认为是完全合格的，因为管理员已经提供了启动这些资源或者连接到这些资源所需要的所有信息(例如连接到数据源的证书，或者应用的目标信息)。系统管理员可以在域级别或者在分区级别声明资源组。在域级别，资源组提供对于相关资源进行分组的方便途径。系统可以像管理未分组资源一样管理在域级别资源组中声明的资源，使得资源可以在系统启动期间启动以及在系统关闭期间停止。管理员也可以单独地停止、启动或者移除分组中的资源，并且可以通过对分组进行操作而隐式地作用在分组中的所有资源上。例如，停止资源组停止分组中尚未停止的所有资源；启动资源组启动分组中尚未启动的任何资源；以及移除资源组移除包含在分组中的所有资源。在分区级别，受任何安全限制，系统或者分区管理员可以在分区中配置零个或者更多资源组。例如，在SaaS用例中，各种分区级别的资源组可以引用域级别的资源组模板；而在PaaS用例中，可以创建分区级别的资源组，这些分区级别的资源组不引用资源组模板，而是相反地代表将变得仅在该分区内可用的应用以及它们的相关资源。根据实施例，资源分组可以用来将应用以及它们使用的资源分组在一起作为域内的不同监管性单元。例如，在下面描述的医疗记录(MedRec)应用中，资源分组定义MedRec应用及其资源。多个分区可以运行相同的MedRec资源组，每个分区使用分区特定的配置信息，使得作为每个MedRec实例的一部分的应用被置为对于每个分区而言是特定的。资源组模板根据实施例，资源组模板是可以从资源组引用的、在域级别定义的可部署资源的集合，并且激活资源组模板的资源所需要的信息中的一些可以不被存储作为模板自身的一部分，使得它支持分区级别配置的规范。域可以包含任何数量的资源组模板，其中每个资源组模板可以包含例如一个或多个相关Java应用以及这些应用所依赖的资源。关于这种资源的信息当中的一些可以跨所有分区是相同的，而其他信息可以根据分区变化。不是所有配置都需要在域级别指定——代替地，可以通过宏或者属性名称/值对的使用在资源组模板中指定分区级别的配置。根据实施例，特定资源组模板可以由一个或多个资源组引用。一般而言，在任何给定分区内，资源组模板一次可以由一个资源组引用，亦即，不由同一分区内的多个资源组同时引用；然而，它可以同时由不同分区中的另一个资源组引用。包含资源组的对象(例如，域或者分区)可以使用属性名称/值分配来设置资源组模板中任何令牌(token)的值。当系统使用引用资源组激活资源组模板时，它可以用在资源组的包含对象中设置的值替换这些令牌。在一些情况下，系统也可以使用静态配置的资源组模板和分区来生成用于每个分区/模板组合的运行时配置。例如，在SaaS用例中，系统可以多次激活相同的应用和资源，包括为将使用它们的每个分区激活一次。当管理员定义资源组模板时，他们可以使用令牌来代表将在别处供应的信息。例如，在连接到CRM相关的数据资源中使用的用户名可以在资源组模板中指示为\${CRMDataUsername}。租户根据实施例，在诸如多租户(MT)应用服务器环境之类的多租户环境中，租户是可以由一个或多个分区和/或一个或多个感知租户的应用代表或者以其他方式与其相关联的实体。例如，租户可以代表不同的用户组织，诸如不同的外部公司，或者特定企业内的不同部门(例如，HR(人力资源)和财务部)，其中每个租户可以与不同的分区相关联。租户全局唯一身份(租户ID)是特定用户在特定时刻与特定租户的关联。系统可以例如通过参考用户身份储存库来从用户身份推导出特定用户属于哪个租户。用户身份使得系统能够实施用户被授权执行的那些动作，包括但不局限于用户可以属于哪个租户。根据实施例，系统使得能够将不同租户的监管和运行时彼此隔离。例如，租户可以配置他们的应用的一些行为，以及配置它们能访问的资源。系统可以确保特定的租户不可以监管属于另一个租户的工件(artifact)；并且可以在运行时确保代表特定租户工作的应用仅引用与该租户相关联的资源，而不引用与其他租户相关联的资源。根据实施例，不感知租户(tenant-unaware)的应用是不包含显式地涉及租户的逻辑的应用，使得不管什么用户提交了应用所响应的请求，该应用使用的任何资源都可以是可访问的。相比之下，感知租户(tenant-aware)的应用包括显式地涉及租户的逻辑。例如，基于用户的身份，应用可以推导出用户所属的租户并且使用该信息访问租户特定的资源。根据实施例，系统使得用户能够部署被显式地编写为感知租户的应用，使得应用开发者可以获得当前租户的租户ID。感知租户的应用然后可以使用租户ID来处置正在使用该应用的单个实例的多个租户。例如，支持单个医生的办公室或者医院的MedRec应用可以暴露于两个不同的分区或者租户(例如BaylandUrgentCare(湾区急救)租户和ValleyHealth(溪谷健康)租户)，这些不同的分区或租户中的每一个能够在不改变底层的应用代码的情况下访问单独的租户特定的资源，诸如单独的PDB。示例性域配置和多租户环境根据实施例，应用可以部署到在域级别上的资源组模板，或者部署到范围到分区或者范围到域的资源组。可以使用每个应用或者每个分区指定的部署计划覆盖应用配置。部署计划也可以被指定作为资源组的一部分。图4例示根据实施例的与示例性多租户环境一起使用的域配置。根据实施例，当系统启动分区时，它根据所提供的配置创建虚拟目标(例如，虚拟主机)以及到各自数据库实例的连接池，包括每个分区一个。典型地，每个资源组模板可以包括一个或多个相关应用以及这些应用所依赖的资源。每个分区可以通过提供资源组模板中的可部署资源到与该分区相关联的具体值的绑定，来提供在它所引用的资源组模板中没有指定的配置数据；在一些情况下，包括覆盖由资源组模板指定的某个配置信息。这使得系统能够使用每个分区已经定义的属性值，对于每个分区不同地激活由资源组模板代表的应用。在一些情况下，分区可以包含没有引用资源组模板、或者直接定义它们自己的分区范围的可部署资源的资源组。在分区内定义的应用和数据源通常仅对该分区可用。可以部署资源使得可以使用partition:<partitionName>/<resourceJNDIname>或者domain:<resourceJNDIname>来从跨分区访问它们。例如，MedRec应用可以包括多个Java应用、数据源、JMS服务器和邮件会话。为了针对多个租户运行MedRec应用，系统管理员可以定义单个MedRec资源组模板286，在模板中声明那些可部署资源。与域级别的可部署资源相比，在资源组模板中声明的可部署资源可能没有在模板中充分配置或者不可以原样激活，这是因为它们缺少一些配置信息。例如，MedRec资源组模板可以声明由应用使用的数据源，但是它可能没有指定用于连接到该数据库的URL。与不同租户相关联的分区(例如，分区BUC-A290(湾区急救，BUC)和分区VH-A292(溪谷健康，VH))可以通过各自包括引用296、297MedRec资源组模板的MecRec资源组293、294，来引用一个或多个资源组模板。然后该引用可以用来创建302、306用于每个租户的虚拟目标/虚拟主机，包括与BUC-A分区相关联的虚拟主机baylandurgentcare.com304，以用于由湾区急救租户使用；以及与VH-A分区相关联的虚拟主机valleyhealth.com308，以用于由溪谷健康租户使用。图5进一步例示根据实施例的示例性多租户环境。如图5中所例示的，并且继续来自上面的示例(其中两个分区引用MedRec资源组模板)，根据实施例，伺服小程式(servlet)引擎310可以用来支持多个租户环境，在该示例中为湾区急救医师租户环境320以及溪谷健康医师租户环境330。根据实施例，每个分区321、331可以定义在其上接受针对该租户环境的传入流量的不同虚拟目标，以及用于连接到分区以及连接到它的资源324、334的不同URL322、332，在该示例中分别包括湾区急救数据库或者溪谷健康数据库。数据库实例可以使用兼容模式，因为相同的应用代码将针对两个数据库而执行。当系统启动分区时，它可以创建虚拟目标以及到各自数据库实例的连接池。感知多租户的补丁修补根据实施例，这里描述的是用于支持在多租户应用服务器环境中补丁修补的系统和方法。系统可以将一个或多个分区与租户相关联，以用于由该租户使用，其中分区是域的运行时和监管性细分或切片。补丁修补过程可以利用由应用服务器集群环境提供的高可用性特征，以在受控的滚动重启中应用补丁，这维持域的无中断或者零停机时间操作的能力。该过程可以用来将复杂的或者长期运行的任务自动化，包括保存应用服务器、应用或者其他软件组件的未经补丁修补或者先前版本以用于可能的回退，或者在不可复原的错误的情况下提供自动恢复。根据各种实施例，在这里提供的补丁修补过程的描述使用下面的概念当中的一些或者全部：PSU：补丁集更新(patchsetupdate)。ZDT：零停机时间(zerodowntime)。工作流：由编排框架(orchestrationframework)或者补丁编排器(patchorchestrator)执行的任务序列。补丁修补原语(primitive)：代表补丁修补铺开的可重用部分的逻辑操作。不在位(out-of-place)的补丁修补：正在非生产(non-production)服务器上运行的例如OracleHome的补丁修补，然后在将它推出到生产服务器之前以带外(outofband)补丁修补和测试的方式测试并且验证补丁，该带外补丁修补和测试的方式需要较少的生产服务器停机时间并且如果需要的话提供更容易地回退原始版本的能力。图6例示根据实施例的对于补丁修补的支持。如图6中所例示的，根据实施例，系统可以包括负责监管受管理的服务器或者集群的监管服务器(监管服务器)400，受管理的服务器或者集群在该示例中包括受管理的服务器的第一故障转移(failover)分组404(这里指示为MS1、MS2和MS3)，以及受管理的服务器的第二故障转移分组(这里指示为MS4、MS5和MS6)。监管服务器可以由客户端经由RESTAPI410或者另一种类型的接口访问。根据实施例，系统还包括补丁编排框架或者补丁编排器420，补丁编排框架或者补丁编排器420操作以使用如下面进一步描述的多个补丁修补原语铺开和/或应用不同版本的软件组件或者补丁，这是作为补丁修补工作流的一部分。一般而言，补丁编排器被设计为以稳健方式操作，并且被设计为包括对于诸如任务重试以及回退语义之类的功能性的支持。根据实施例，补丁编排过程利用由应用服务器提供的各种特征以提供高级功能性，这些高级功能性诸如：处置可能不向后兼容的应用会话的能力；感知会话(session-aware)的优雅关闭(gracefulshutdown)，其在关闭受管理的服务器之前等待该服务器中的现有会话结束；重复会话的懒惰解除序列化(lazyde-serialization)，其在补丁修补窗口期间关掉重复会话的自动解除序列化；懒惰解除序列化的动态打开/关掉，以避免集群重启；以及基于分组信息的故障转移，这些特征或者功能性当中的每一个都在下面进一步描述。根据实施例，由补丁编排器支持的补丁修补原语的示例可以包括：静默服务器(QuiesceServer)422，其与流量引导器或者其他类型的负载均衡器430(例如Oracle流量引导器(OTD))通信，以使到指定服务器的流量静默；更新宿主(UpdateHome)424，其改变宿主目录或者其他存储装置的(例如，OracleHome)符号链接(symlink)以指向新目标；就绪检查应用(ReadyCheckApps)426，其与就绪应用(readyapp)或者类似的框架通信，并且只有当所有已注册应用都处于就绪状态时才完成；以及激活服务器(ActivateServer)428，其与例如OTD通信以继续(resume)发送流量到指定服务器。根据实施例，补丁编排器连同它的原语和工作流一起可以与补丁数据库440组合使用，以支持不同版本的软件组件或者补丁，包括例如针对一个或多个受管理的服务器451，将一组宿主目录或者其他存储装置450从经初始补丁修补的或者未经补丁修补的版本452进行补丁修补或者更新至经后续补丁修补的版本454所需要的信息。例如，如图6中所例示的，集群可以包括如上所述的受管理的服务器的两个故障转移分组，其中第一故障转移分组以及它的受管理的服务器的选集(MS1、MS2和MS3)使用经补丁修补的版本的宿主目录，而第二故障转移分组以及其他受管理的服务器(MS4、MS5和MS6)使用初始版本的或者未经补丁修补的版本的宿主目录。来自流量引导器或者负载均衡器的请求可以故障转移到故障转移分组内的任何服务器。如下面进一步描述的，根据实施例，懒惰会话解除序列化功能性可以用来优雅地处置可能跨两个故障转移分组及其中的受管理的服务器的任何会话的故障转移。图7进一步例示根据实施例的用于补丁修补的系统，包括对于会话处置的支持。在典型的应用服务器的环境中，服务器实例的关闭和后续的重启可能花费一些时间，也许甚至几分钟。为了解决这一点，根据实施例，系统包括可以在关闭时执行的更智慧的会话复制过程，包括确定活跃会话是否在系统内其他任何地方提供，并且如果活跃会话未在系统内其他任何地方提供，则使得会话在关闭预期的服务器之前可用。如图7中所例示的，根据实施例，流量引导器支持诸如负载均衡452、503报头检测454、动态发现456以及健康检查458之类的功能性；而应用服务器集群环境460支持诸如动态懒惰会话解除序列化462、会话取回464以及孤立(orphaned)会话清理468之类的功能性；web容器470支持诸如会话兼容性检测472之类的功能性；以及服务器生命周期组件480支持诸如关闭时的会话复制482以及等待所有会话484之类的功能性。根据实施例，在下面更详细地描述上面组件当中的每一个，包括它们的解决各种情况的使用，这些情况诸如：在补丁修补之前和之后补丁修补支持的动态打开和关掉；会话取回；孤立会话清理以避免多个备份；不兼容会话的处置，包括一个服务器可以如何发送503消息到流量引导器以指导它尝试不同的服务器；以及多个版本的应用服务器、应用或者其他组件的处置。例如，根据实施例，通过创建新分区并且在新分区处设置不同版本的应用服务器、应用或者其他组件，系统允许不同版本的应用服务器、应用或者其他组件部署到不同的分区。流量引导器可以被配置为控制与新版本的应用服务器、应用或者其他组件相比较多少流量和/或哪种类型的流量应当被引导至旧版本的应用服务器、应用或者其他组件。不像应用的生产重新部署(productionredeloyment)(其中只可以部署两个版本的应用，并且其中一个版本的应用需要标记为退休)，根据实施例，系统允许多于两个版本的应用同时部署和活跃，并且唯一的要求是它们被部署到不同的分区。根据实施例，系统也支持多个租户共享底层逻辑的能力，该底层逻辑在集群级别处维持特定补丁级别，但是例如如果确定一些分区在该特定的时间不能支持特定的补丁级别，则必要时将这些分区移动到各个集群。类似地，根据实施例，系统支持为了测试目的在一个节点处使用例如OracleHome的补丁级别版本，并且然后一旦测试已经完成，必要时将该版本的OracleHome铺开到其他节点的能力。图8进一步例示根据实施例的用于补丁修补的系统，包括对于会话兼容性检测的支持。如图8中所例示的，根据实施例和其中所例示的示例，集群500可以包括在多个分组中提供的多个受管理的服务器(这里指示为MS1-MS5)，其中该多个分组包括经补丁修补的服务器502、不可用的服务器504以及未经补丁修补的服务器506的分组。根据实施例，当受管理的服务器变得不可用时(这里指示为MS3被删除)，那么流量引导器(例如，OTD)可以接收到指示MS3关闭的错误消息511。流量引导器可以尝试512联系另一个受管理的服务器MS2，其在检测解除序列化错误时将使得web容器返回具有例如故障转移分组(FailoverGroup)报头信息的503消息。基于503报头信息，流量引导器可以重试513它的请求，这次指向受管理的服务器MS4。MS4处的应用服务器然后可以从MS2取回适当的会话信息514，并且最终对请求做出响应515。根据实施例，如下面进一步描述的，该过程可以利用对懒惰会话解除序列化518功能性的使用。图9进一步例示根据实施例用于补丁修补的系统。如图9中所例示的，根据实施例，系统允许域内的集群使用不同的宿主目录(例如，不同的OracleHome)并且因此使用不同的应用服务器(例如，WLS)版本或者补丁版本进行操作。因为任何受管理的服务器支持来自相同域的其他集群，用于集群的受管理的服务器可以驻留在相同或者不同的主机上。具体地，如图9中所例示的，系统可以包括多个集群，这些集群包括C1530、C2532以及C3534，每个集群操作一个或多个分区550、552、554，这里指示为分区A562、分区B564、分区C566和分区N568。根据实施例，补丁数据库540可以包括用于多个版本的应用服务器、应用或者其他组件的版本或者补丁信息，这些版本或者补丁信息在这里指示为版本A542、版本B补丁集1(PS1)544以及版本B补丁集2(PS2)546。根据实施例，不同的分区可以在不同的时间迁移和/或进行补丁修补，使得例如分区A可以从具有第一版本A的特定应用服务器(例如，WLS)的集群C1迁移到具有不同版本BPS1的应用服务器的集群C2。类似地，分区C可以从具有版本A的应用服务器的集群C1迁移到具有另一个不同版本BPS2的应用服务器的集群C3。根据实施例，该补丁修补过程的一些优点包括使得离散的分区能够迁移到较新(例如，经补丁修补的)版本的应用服务器、应用或者其他组件(例如，较新版本的WLS)而不影响共享相同资源的其他分区。补丁修补过程也允许对例如初始版本的WLS应用服务器相对经补丁修补的版本的WLS的A/B测试(A/Btesting)，或者使用特定版本的WLS对不同版本的应用的测试。根据实施例，在一段时间内，分区可以被认为在两个集群(例如，源和目标集群)中同时“活着”，这允许任何现有会话完成或者超时。一旦分区迁移完成，分区然后就将变得仅在目标集群中可用，目标集群包括任何较新(例如，经补丁修补的)版本的应用服务器、应用或者其他组件。图10进一步例示根据实施例的用于补丁修补的系统。如图10中所例示的，根据实施例，为了对应用服务器、应用或者其他组件在其上运行的一个或多个计算机节点或者服务器进行补丁修补，首先优雅地关闭这些节点上的服务器。在580处，在将要进行补丁修补的节点或者服务器处调用准备切换(例如，prepareSwitchOracleHome)原语，这引导用于该节点或者服务器的节点管理器设置将要执行它的宿主目录(例如，OracleHome)的切换的脚本。该步骤用来向节点管理器提供它执行操作所需要的参数。在582处，执行对重启节点管理器(例如，RestartNodeManager)原语的调用，这使得该节点处的节点管理器将控制转移给脚本(例如，switchOracleHome脚本)，该脚本继而将当前宿主目录(例如，OracleHome)移动583到指定的目录路径，将经补丁修补的应用服务器、应用或者其他组件映像(image)提取到原始位置中，并且然后再次启动节点管理器。在584处，执行断言切换(例如，AssertSwitchOracleHome)原语，该原语将确认宿主(例如，OracleHome)目录的切换585已经成功完成。在588处，为每个节点或者服务器调用启动服务器(例如，StartServers)原语，并且直到就绪应用检查(例如，ReadyAppCheck)成功返回(如果它已配置)启动服务器原语才完成。这将确保在工作流将关闭任何更多节点或者服务器之前，该节点处的所有经补丁修补的应用服务器、应用或者其他组件可以服务请求，并且这支持有限的停机时间或者无(亦即，零)停机时间。图11-图12进一步例示根据实施例的用于补丁修补的系统。如图11-图12中所例示的，根据示例性实施例，系统可以在跨三个物理机器或者节点(这里指示为计算机节点1-3)运行的集群604中包括多个受管理的服务器，并且监管服务器独自运行在它自己的机器(这里指示为监管节点600)上。集群中的在相同机器上的每对受管理的服务器共享相同的本地域目录以及相同的本地宿主(例如，OracleHome)目录。每个机器包括它自己的节点管理器。根据实施例，最初，监管服务器和受管理的服务器使用原始宿主目录602、606、607、608。补丁修补过程可以通过将经补丁修补的版本拷贝到每个受管理的服务器，并且然后执行到监管服务器的铺开(无服务中断)610而继续前进。根据实施例，受管理的服务器跨足够多的机器而充分分布以能够提供正在被补丁修补的应用服务器、应用或者其他组件的故障转移，即使是当一些受管理的服务器暂时关闭时。然后对受管理的服务器进行补丁修补，并且然后执行指向经补丁修补的共享存储的滚动重启616、617、618。该过程导致没有因状态复制而引起的会话丢失，并且导致有限的停机时间或者无(亦即，零)停机时间。示例性实施例根据示例性实施例，不在位的补丁修补利用构建到集群中的现有高可用性特征，以在受控的滚动重启中应用补丁，这维持域的无中断操作的能力。该过程被设计为通过将复杂的并且长期运行的任务自动化、保存未经补丁修补(或者先前)的版本用于回退、并且在不可复原的错误的情况下提供自动恢复来减少暴露。在高层级上，该过程将要：克隆正由域中的服务器使用的一个或多个OracleHome目录；将零停机时间兼容的补丁应用到复制目录；并且启动将处置铺开的编排任务。根据实施例，铺开任务将对于每个服务器依次协调下面操作：优雅地关闭在节点上的共享共同域(目录)的服务器；重启与该服务器相关联的节点管理器；将当前OracleHome目录移动到备份位置并且在当前OracleHome目录的位置部署指定的OracleHome目录；以及启动服务器，并且如果已配置ReadyAppsCheck则等待ReadyAppsCheck。在一些情况下，基于服务器的配置，可能期望一次关闭多于一个服务器。在任何一次关闭的服务器的数量应当保持尽可能地少，以使得铺开的影响最小化。集群中将总是存在正常运行(up)并且响应请求的至少一个服务器。在不可复原的错误的情况下，铺开任务将自动地恢复它已经做出的任何改变，使得服务器将返回到它们的原始状态(先前版本)。这将确保域在错误被诊断并且被解决时是完全可用的。通过保存原始OracleHome目录使得回退变得可能，并且回退是补丁应用于复制目录而不是原始目录的原因的一部分。如果在回退过程期间遭遇阻止回退完成的另一个错误，那么将提出错误并且该过程将停止以允许调查。一旦该错误被清除，就可以继续恢复过程。初始安装和配置根据实施例，为了便于不在位的补丁修补，对于跨服务器的应用服务器(例如，WLS)的安装，存在必须满足的若干要求。在域中存在引用OracleHome的位置的许多地方。这包括启动脚本中的变量、属性文件以及xml配置文件。找到并且更新所有的这些位置以指向新版本的OracleHome通常是不现实的。因此，根据实施例，铺开通过移动现有OracleHome(到用户指定的备份位置)并且在现有OracleHome的位置扩展期望的OracleHome而起作用。为了确保这个程序不会影响仍然在运行的受管理的服务器，OracleHome目录必须由机器上的所有受影响的受管理的服务器使用，并且不会由其他机器上的受管理的服务器使用。OracleHome也必须位于节点管理器进程可写的位置。为了确保这些条件，OracleHome目录可以安装在受影响的受管理的服务器本地的硬盘驱动器上。升级服务器同时维持正常运行时间(uptime)的关键在于利用通过集群配置的高可用性。在集群内最小数量的服务器必须保持一直都是工作的。因为集群内的在相同机器上的服务器将需要一起重启(如果它们共享共同的域目录)，所以需要集群内的服务器托管在至少两个不同的物理机器上，但是推荐每个集群最少三个机器。这将允许一些服务器保持正常运行并且提供服务，同时其他服务器作为滚动重启的一部分而关闭。当确定在不同机器上可用于处置请求的服务器的数量时，重要的是排除正在运行但是处于监管(admin)或者备用(standby)模式的受管理的服务器，这是因为这些服务器将不对请求做出响应。如果监管服务器和受管理的服务器需要同时更新，那么铺开过程可能非常复杂。如果监管服务器和受管理的服务器被配置在相同的机器上运行并且共享相同的域目录，就将是这种情况。监管服务器将需要与受管理的服务器同时关闭，因为它将根据共享的OracleHome目录运行。如果受管理的服务器的安装宿主被隔离以允许以每个受管理的服务器为基础铺开补丁，那么这个限制将不适用。因此，支持简化这个问题的两种不同配置：1.第一种配置是让监管服务器运行在没有任何受管理的服务器运行在其上的机器上。这允许监管服务器独自在一个步骤中更新，并且一旦该更新完成，下一个步骤将是更新该域中的在不同机器上的受管理的服务器。2.第二种配置是允许监管服务器运行在与受管理的服务器相同的机器上，但是使得监管服务器从监管服务器自己单独的域目录中运行。这将也允许监管服务器单独地更新，并且受管理的服务器可以在它们自己的步骤中更新。除了提供将更新域中所有服务器的机制之外，这个特征还提供更新域内的各个集群的能力。当用户尝试使用集群铺开模式时，如果在单个节点上存在服务不同集群的多个受管理的服务器，那么这些受管理的服务器必须根据它们正在服务的集群具有单独的域目录。它们的域目录也必须指向单独的OracleHome目录，并且它们也必须由节点管理器的单独实例管理。这是必需的，使得可以关闭节点上针对一个集群的所有受管理的服务器并且更新它们的OracleHome目录而不影响服务其他集群(并且仍然在运行)的受管理的服务器的OracleHome目录。在不同的时间在域内对不同分区进行补丁修补不像这样被显式地支持，但是有可能通过管理分区并且使用集群级别补丁修补来实现。取决于分区在环境中是如何被使用的，可能期望升级一个分区而不升级另一个。这样的示例可能是以下环境：其中每个分区正由不同的租户使用，并且一个租户需要升级但是另一个租户没有可用的维护窗口。在这种情景中，分区迁移特征可以用来分离这些分区。可以将需要升级的分区迁移到不同的集群(现有的集群或者新创建的集群)，并且可以在新集群上执行集群级别铺开。实现这一点的最简单的途径是如果新集群托管在与原始集群不同的物理机器上，这将确保域目录、OracleHome和节点管理器不重叠。如果没有其他物理资源可用，那么只要新集群让它自己的域目录复本指向它自己的OracleHome目录复本，并且让它自己的节点管理器实例运行在每个受影响的机器上，就仍然可以支持这个程序。根据实施例，节点管理器负责将当前OracleHome移动至指定的备份目录，并且在当前OracleHome的位置上提取或者拷贝新OracleHome。节点管理器也必须重启以便从新目录中运行。为了协调这一点，每个节点必须具有它自己的节点管理器。例如，在上面描述的图10-图12中，系统在跨三个物理机器运行的集群中包括多个受管理的服务器，并且监管服务器单独运行在它自己的机器上。集群中的在相同机器上的每对受管理的服务器共享相同的本地域目录和相同的本地OracleHome目录；并且每个机器具有它自己的节点管理器在运行。克隆以及对克隆映像进行补丁修补根据实施例，为了克隆现有映像并且对克隆映像进行补丁修补，系统可以依赖于现有的工具，例如使用用于克隆现有OracleHome的FMW移动脚本。一旦克隆OracleHome存在，用户然后就可以使用现有的OPatch工具对该映像进行补丁修补。使用FMW移动脚本克隆OracleHome的描述如下：1.使用copyBinary.sh执行WLS安装的归档(archive)。2.对新目录使用pasteBinary.sh以执行WLS安装的克隆(更新中央库存文件)。一旦已经创建克隆，该使用可以运行Oracle通用安装程序并且保证克隆已经向中央库存注册。自动化的铺开如上所述，根据实施例，在很大程度上通过利用服务器集群的高可用性特征，以零停机时间铺开更新变得可能。使用服务器集群，受管理的服务器当中的一个或多个可以下线而不使应用遭受停机时间。事实上，使用优雅的服务器关闭，在大多数情况下防止甚至单个会话丢失是有可能的。关闭服务器、更新它们并且使得它们返回到服务中的协调可以通过创建称作补丁修补原语的自定义命令(customcommand)并且使用编排框架执行它们来处置。命令分析域的拓扑并且确定依次安全地更新所有服务器和节点管理器的最佳途径；同时编排框架提供过程的监控和错误处置。根据实施例，为了使得该机制恰当地工作，正在升级的集群内的受管理的服务器必须遍布两个或多个物理机器。这是因为，集群内的由相同机器托管的所有服务器将共享共同的域目录并且因此必须一起关闭。为了避免停机时间，集群中的服务器中的一些必须运行在与其他服务器不同的机器上。这样，总是存在一些服务器可用于服务请求。由该技术引入的另一个约束是以下要求：应用于克隆OracleHome的补丁必须使得服务器处于它们仍然与未经补丁修补的服务器兼容的状态。更具体地，在补丁铺开期间服务器故障的情况下，用户的会话必须有可能在经补丁修补的服务器和未经补丁修补的服务器之间无缝地迁移。根据实施例，存在可以以这种方式铺开的若干操作。这些包括铺开经补丁修补的OracleHome、跨服务器更新JAVA_HOME的位置、使用已更新的版本替换应用以及这些操作在单个铺开中的任意组合。也提供跨所有服务器执行滚动重启的能力。示例性补丁修补API根据实施例，下面描述的是可以用来铺开升级或者补丁的示例性补丁修补API。根据其他实施例，可以支持不同和/或附加的补丁修补API。rolloutUpdate(铺开更新)命令根据实施例，rolloutUpdate命令提供更新服务器上的OracleHome、JavaHome和应用的能力。它也允许这些改变的任意组合，这取决于指定可选参数当中的哪些。为了更新OracleHome，用户必须指定rolloutOracleHome(铺开OracleHome)、backupOracleHome(备份OracleHome)和isRollback(是否回退)参数。为了更新JavaHome，用户必须指定javaHome参数。为了更新应用，用户必须指定applicationProperties(应用属性)参数。isDryRun(是否为演习)和autoRevertOnFailure(故障时自动恢复)选项对于所有情况有效，isSessionCompatible(会话是否兼容)选项将仅在应用和/或OracleHome正被修改的情况下考虑。对于在单个铺开期间可以执行哪些更新不存在限制。如果用户没有指定OracleHome参数、JavaHome参数或者ApplicationProperties参数，那么将执行滚动重启。语法rolloutUpdate(target，[rolloutOracleHome，backupOracleHome，isRollback]，[javaHome]，[applicationProperties]，[options])示例铺开新的经补丁修补的OracleHome：回退到原始的OracleHome：仅铺开新版本的Java：>progress＝rolloutUpdate(DomainA，javaHome＝/pathto/jdk1.8.0_55)仅铺开已升级的应用：铺开新的经补丁修补的OracleHome以及新版本的Java：铺开新的经补丁修补的OracleHome、新版本的Java以及已升级的应用：rolloutOracleHome命令根据实施例，rolloutOracleHome命令提供更新OracleHome的能力。rolloutOracleHome任务负责弄清楚哪些服务器需要被更新，以什么次序更新，并且负责创建将安全地更新它们的工作流。这包括服务器的优雅关闭、替换OracleHome目录、重启节点管理器以及再次启动服务器。铺开任务将返回WorkflowProgressMBean(工作流进展MBean)，其中该WorkflowProgressMBean可以被轮询以获取状态。语法rolloutOracleHome(target,rolloutOracleHome,backupOracleHome,isRollback,[options])示例铺开经补丁修补的OracleHome：rolloutJavaHome命令根据实施例，rolloutJavaHome命令提供更新由受影响的服务器使用的JavaHome的能力。rolloutJavaHome任务负责弄清楚哪些服务器需要被更新，以什么次序更新，并且负责创建将安全地更新它们的工作流。这包括服务器的优雅关闭、更新它们使用的JavaHome的位置、重启节点管理器以及再次启动服务器。这个任务将返回WorkflowProgressMBean，其中该WorkflowProgressMBean可以被轮询以获取状态。语法rolloutJavaHome(target,javaHome,[options])示例更新域中所有服务器上的JavaHome以使用最新安装的版本的java。>progress＝rllloutJavaHome(DomainA，/pathto/jdk1.8._55)rolloutApplications命令根据实施例，rolloutApplications命令提供更新在服务器上部署的应用的能力。rolloutApplications任务负责弄清楚哪些服务器需要被更新，以什么次序更新，并且负责创建将安全地更新它们的工作流。这包括服务器的优雅关闭、更新应用、重启节点管理器以及再次启动服务器。这个任务将返回WorkflowProgressMBean，其中该WorkflowProgressMBean可以被轮询以获取状态。语法rolloutApplications(target,applicationProperties,[options])示例铺开已升级的应用>progress＝rolloutApplications(DomainA，/pathto/applicationProperties)rollingRestart(滚动重启)命令根据实施例，rollingRestart命令提供顺序地重启服务器的能力。rollingRestart任务负责弄清楚哪些服务器需要重启并且负责创建将安全地重启它们的工作流。这包括服务器的优雅关闭以及再次启动它们。这个任务将返回WorkflowProgressMBean，其中该WorkflowProgressMBean可以被轮询以获取状态。语法rollingRestart(target，[options])示例执行域中所有服务器的滚动重启>progress＝rollingRestart(DomainA)更新JavaHome根据实施例，零停机时间补丁修补特征提供更新用于指定目标中的服务器的JAVA_HOME设置的机制。存在两种发起该过程的途径，一种是使用独立式命令rolloutJavaHome，并且另一种是通过将可选的javaHome参数指定到rolloutUpdate命令。当使用后者时，有可能在同一铺开中更新OracleHome和/或应用。不管是否还升级OracleHome或升级应用，设置JAVA_HOME的功能性都是相同的。根据实施例，上面针对更新OracleHome而描述的拓扑前提条件也应用于更新JavaHome。另外，为了能够提供该功能性，需要JAVA_HOME被设置而指向的Java版本已经安装在本地可访问的某个地方，并且需要到JAVA_HOME的路径对于所有受影响的服务器是相同的。在关闭服务器之前安装Java意味着Java的每个版本(当前版本以及新版本)必须具有到它们的单独的唯一路径。根据实施例，为了铺开对JavaHome的改变，机器上的共享相同OracleHome的所有服务器(连同在该机器上运行的节点管理器一起)必须一起关闭。当它们关闭时，本机脚本将使用特殊形式的pasteBinary来更新OracleHome目录中的所有脚本以使用新的JAVA_HOME位置。Java更新脚本然后将把域目录中必要的启动脚本修改为也使用JAVA_HOME的新路径。然后，将再次启动该机器上的节点管理器和服务器。OracleHome下包含对JAVA_HOME的引用的所有脚本将指向指定的JAVA_HOME。在当前域目录下包含对JAVA_HOME的引用的所有脚本将指向指定的JAVA_HOME。对已经成功执行的对JavaHome的改变进行回退的最容易的途径仅仅是使用旧的位置作为新的路径执行新的updateJavaHome命令。然而，在一些实例中，系统也支持对还改变了JavaHome的OracleHome改变进行回退。将OracleHome脚本返回到它们的原始状态作为将OracleHome目录还原到先前状态的固有部分而发生。对域脚本进行回退可能不那么直接，因为用户在发出回退命令时可能没有指定原始的(期望的)JavaHome位置。为了解决这个问题，可以改写updateOracleHome命令，使得当OracleHome目录移动到备份位置时，它还包括称作“domainBackup(域备份)”的附加目录，该目录将在更新时保存当前版本的相关域脚本的复本。这样，如果未来用户从我们已备份的OracleHome位置执行回退命令，那么这些域文件可以被拷贝回到合适的地方。更新应用如上所述，根据实施例，零停机时间补丁修补特征也提供用于更新部署到应用服务器的应用的机制。用于这一点的一种机制是将它们包括在OracleHome目录中并且从那里无存放(no-stage)部署它们。对以这种方式部署的应用进行更新发生在铺开新版本的OracleHome(包括有已更新的应用)时。除了具有包括在正被铺开的新OracleHome中的最新版本之外，以这种方式部署的应用不需要任何附加的信息或者步骤。用于对在OracleHome目录之外的应用进行更新的过程对于存放(staged)应用和非存放(no-staged)应用是不同的，但是在两种情况下都涉及定位当前应用目录，将该目录移动到备份位置以及将包含新版本应用的应用目录移动到原始的位置中，从而本质上使用新的应用代码替换旧的应用代码。此操作在原始目录正被访问时不能执行，所以在此程序期间受影响的服务器必须关闭。然而，因为节点管理器独立于应用代码，所以当节点管理器仍然在运行时此过程可以执行(不像更新OracleHome或者JavaHome)。与铺开新OracleHome类似，存在一些需要的准备。例如，包含新应用代码的目录必须在开始铺开之前分布到所有受影响的节点，并且它必须对于每个节点都在相同的路径中。图13-图15例示根据实施例的补丁修补事件图。因为存放(staged)应用、无存放(no-stage)应用和外部存放(external-stage)应用被不同地部署的事实，它们需要不同的处理以便被恰当地更新。在所有模式中，新应用源必须作为目录提供在监管服务器上。对以无存放和外部存放模式部署的应用，新应用源也必须提前以与它在监管服务器上相同的路径分布到每个节点。存放模式如图13中所例示的，图13例示根据存放模式的实施例的监管节点620和监管服务器622与包括节点管理器624和两个受管理的服务器(这里指示为MS1和MS2)的节点1之间的交互，运行存放模式的应用的服务器直接从监管服务器获得它们的源。为了更新应用，必须首先在监管服务器上更新源，并且然后当服务器处于监管模式时，将针对每一个应用单独地调用具体目标重新部署，以便更新应用的源并且触发它恰当地拾取(pickup)改变。为了一致性，该操作将共同集群中共同机器上的服务器分组在一起。无存放模式如图14中所示，图14类似地例示根据无存放模式的实施例的监管节点630和监管服务器632与包括节点管理器634以及两个受管理的服务器的节点1之间的交互，当启动服务器时，无存放应用从服务器的机器上的目录中加载。为了更新这里的应用代码，该机器上指向相同应用目录的所有服务器必须同时关闭。然后可以将该目录的内容移到旁边并且用较新版本的应用替换。因为更新是通过替换目录来执行的，所以系统可能不支持针对无存放应用使用共享的存储目录，因为这对于仍然从该目录中运行应用的其他服务器将引发问题。然后将以监管模式启动受影响的服务器，并且将对于每一个应用单独地发出具体目标重新部署命令使得它拾取改变。外部存放模式如图15中所示，图15类似地例示根据外部存放模式的实施例的监管节点640和监管服务器642与包括节点管理器644和两个受管理的服务器的节点1之间的交互，外部存放应用与无存放应用相类似，因为它们的应用源需要由工作流更新。然而，主要的差别在于外部存放应用源目录位于服务器的存放目录(stagingdirectory)中，并且因此每个服务器具有它自己的将要更新的目录复本。工作流将一起关闭共同机器上的服务器(像其他存放模式一样)，并且然后在以管理模式启动每个受影响的服务器并且使用具体目标重新部署来触发该服务器拾取改变之前，更新每个受影响服务器的存放目录。为了使上面的过程起作用，应用代码的替换必须仅在服务器关闭时对服务器执行。如此，共享相同应用目录的任何服务器必须同时关闭。这阻止服务器为应用目录使用共同的共享存储位置。每个机器必须具有应用目录的本地复本以及新应用目录的本地复本。到新的应用目录、当前应用目录以及备份位置的路径必须对于所有受影响的服务器是相同的。此外，应用不可以驻留在OracleHome目录中。因为随着铺开继续前进，对应用的改变将以交错方式跨服务器铺开，并且当服务器仍然服务请求时，在铺开开始之前创建的会话可能不与较新版本的应用兼容。这将某种复杂性引入如何在铺开期间处置会话以及如何关闭服务器，这种复杂性可以通过在支持更新应用的命令中使用isSessionCompatible标记来解决。如果旧版本的应用与新版本的应用之间的会话是兼容的，那么某些保护措施(safeguard)将不是必要的，并且铺开将更高效地完成。根据实施例，通常需要来自用户的三条信息：应用名称(用来在配置(config)中查找更多信息)；新的/经补丁修补的应用代码的位置(必须是本地目录)；以及当前应用目录将要备份到的位置(也必须是本地目录)。当前应用源位置和存放模式可以由工作流基于每个服务器及其应用的配置来计算得出。在命令行上指定甚至这样精简的信息集合都可能是笨拙(unwieldy)的。为了解决这一点，根据实施例，信息可以由用户在发出命令之前放置到文本文件中，其中该文本文件位于当命令执行时命令可以读取它的位置。用于各命令的命令行变元仅仅是到该文件的路径。根据各种实施例，可以使用各种格式从而定义文件，主要的考虑是文件需要是人类友好的，这是因为人将生成它。例如，JSON是人类可读、容易组织的适当平衡，允许用户对于每个应用的属性使用相同的名称，并且具有众所周知且容易解析的附加益处。滚动重启根据实施例，零停机时间补丁修补特征提供一次一个重启一组服务器的机制。因为不存在在服务器或者OracleHome或者域目录上正在进行的配置改变，所以即使在同一机器上存在从共同的OracleHome目录运行的多个服务器，服务器也将一次一个地关闭。也是因为这个原因，如果工作流中存在故障，那么工作流将不会恢复，因为不存在要还原到先前受影响的服务器的原始状态。监控进展根据实施例，WLST铺开命令返回WorkflowProgressMBean，其中该WorkflowProgressMBean可以被查询以监控铺开任务的进展。铺开实现根据实施例，这个特征引入若干高级别操作或者补丁修补原语以便完成铺开任务。这些操作将实现来自编排框架的接口，使得它们可以在工作流中被管理。补丁修补原语可以由更高级别的补丁修补原语调用。例如，PatchNode(补丁修补节点)原语可以调用像ShutdownServer(关闭服务器)以及PrepareSwitchOracleHome(准备切换OracleHome)、RestartNodeManager(重启节点管理器)、AssertSwitchOracleHome(断言切换OracleHome)和StartServer(启动服务器)这样的其他原语。根据实施例，铺开WLST调用将使用PatchingFacadeMBean(补丁修补表观MBean)来创建工作流并且将它传递到工作流生命周期管理器(例如，WorkflowLifecycleManager)用于执行。工作流将结合原语，例如：RolloutDirectory(铺开目录)；CheckPrerequisites(检查前提条件)，其确定必须一起升级的服务器分组(相同集群，相同机器)；以及，对于每个服务器分组：对于每个服务器的ShutdownServer(优雅地)，对于节点进行一次的PrepareSwitchOracleHome，对于节点进行一次的RestartNodeManager，对于节点进行一次的AssertSwitchOracleHome以及对于每个服务器的StartServer。根据实施例，PatchServer(补丁修补服务器)原语可用于一次对单个服务器进行补丁修补。然而，因为铺开OracleHome将影响节点上共享目录的所有服务器，所以需要包括每个受影响的节点上的所有服务器。这一点被提供来由其他组件使用或者从部分铺开复原。它将对受影响的单个服务器调用下面的原语：对每个服务器调用ShutdownServer(优雅地)，对节点调用PrepareSwitchOracleHome一次，对节点调用RestartNodeManager一次，调用AssertSwitchOracleHome一次以及对每个服务器调用StartServer。根据实施例，OracleHome目录由新映像替换的途径包括：1.优雅地关闭服务器；2.调用prepareSwitchOracleHome原语。该原语让用于该节点的节点管理器设置将执行OracleHome目录的切换的脚本。这个步骤就是节点管理器是如何获得它执行操作所需要的所有参数的；3.下一个步骤是调用RestartNodeManager原语。这将使得节点管理器将控制转移给switchOracleHome脚本。那个脚本将当前OracleHome移动到指定的目录路径、将新映像提取到原始位置中以及然后再次启动节点管理器；4.将要执行的下一个原语是AssertSwitchOracleHome原语。此原语将确认OracleHome目录的切换成功完成；以及5.调用的最后一个原语是StartServers。这对于每个服务器而调用，并且它直到ReadyAppCheck成功地返回(如果ReadyAppCheck被配置的话)才完成。这将确保在工作流将关闭任何更多服务器之前，所有应用可以服务请求。错误和故障处置将编排框架用来协调滚动重启以更新OracleHome目录的一个优点在于该过程可能涉及许多步骤并且可能花费若干小时。手动执行所需的步骤将是乏味并且耗时的并且因此容易出现错误和低效。将过程自动化减少引入人为错误的机会，这使得更高效地使用执行该过程所需的时间，它提供若干故障处理选项，并且在最坏的情况下，它可以将它所有的改变自动地恢复回到它们的原始状态。根据实施例，当执行由多个命令(或者其他原语)构成的原语时，存在可以处置故障的几种途径。根据用来构造原语的设置，可以忽略或者重试关于单独的命令的故障。具有逻辑恢复操作(像在将文件移动到新位置之后将它移动回到它的原始位置)的每个原语也可以使用CommandRevertInterface(命令恢复接口)定义恢复行为。当遭遇到不可复原的错误(阻止铺开操作的成功完成并且在重试之后也不成功的错误)时，已完成的步骤将以完成它们的相反次序恢复。如果在该恢复阶段期间遭遇到附加的故障，那么恢复过程将停止，并且问题将需要由操作员手动地解决。根据实施例，用户也可以指定在故障的情况下工作流不应当自动地恢复，这向用户提供纠正阻止工作流继续前进的问题的机会。如果用户能够完成这个，那么用户可以对已停止的工作流调用执行方法并且它将从它最后一个成功完成的命令开始向前移动。如果用户不能清除引起工作流故障的错误，那么用户可以对已停止的工作流调用恢复以使得工作流恢复，工作流恢复从它的最后一个成功完成的命令开始。也可以通过对工作流调用取消，或者通过在恢复期间遭遇到不可复原的错误而停止工作流。回退在一些情景中，可能是如下情况：经补丁修补版本的OracleHome成功地铺开到域中的所有服务器，但是在使用经补丁修补的版本运行之后，发现关于补丁自身的问题。在这种情况下，可能期望回退更新并且将所有服务器移动回到先前的版本。根据实施例，该操作可以通过重新运行铺开过程但是使用较早的版本作为目标版本来实现。为了确保监管服务器总是在最高补丁级别处，这应当通过首先将先前补丁铺开到集群，并且然后单独地铺开到监管服务器来完成。关于对版本进行回退存在一些潜在的问题；例如，可能丢失用于在较新版本中引入的特征的配置信息，并且撤销模式改变可能丢失业务数据。补丁修补表观根据实施例，系统可以提供补丁修补表观(作为POJO)以及PatchingFacadeMBean。MBean版本充当到非MBean版本的直通(pass-through)，但是将作为MBean而不是pojo返回进展对象。表观中的方法封装编排框架的知识，包括注意调用PatchingWorkflowBuilder(补丁修补工作流构建器)中的适当的方法来创建WorkflowBuilder(工作流构建器)以传递到WorkflowLifecycleManager(工作流生命周期管理器)中。可以为每个暴露的补丁修补原语提供方法，以使得其他组件能够直接调用它们(连同将创建WorkflowBuilders的高级调用一起)以组合原语当中的若干原语。方法也可以被提供以允许查询活跃的和已完成工作流的列表，并且根据工作流的名称查找工作流的进展。工作流在它启动时由调用者分配名称，该名称必须是唯一的，因为它可以被用来识别工作流以查询工作流的进展。补丁修补原语根据实施例，补丁修补原语是优雅地执行由不在位的补丁修补方案所需要的滚动重启所需要的操作。下面是每个原语的列表以及它执行什么的解释、它支持哪些容错机制和它需要的特性。支持重试–如果原语具有若行为首次失败则应当再次尝试的行为，那么这为真。这可以用于依赖另一个对象的可能正在转变的状态(比如即将正常运行的服务)的原语，或者用于处置像不可靠的连接这样的间歇性故障。支持恢复–如果原语具有逻辑‘撤销(undo)’操作，其中撤销操作可以在正在恢复它所属的工作流的情况下执行，则这为真。如果原语为恢复情况定义任何特殊的行为，那么将在这里描述它。自定义继续–工作流可以在它由于监管服务器重启而暂停之后继续。存在允许原语有机会覆盖标准继续功能性(从而也许重新检查一些前提条件以确保它们仍然保持为真)的接口。如果原语为继续情况定义任何特殊的行为，那么将在这里描述它。忽略故障–对于作为工作流的一部分而执行但是如果原语没有成功地完成不应当引起工作流恢复的原语，这将为真。这可以由尝试对于工作流的成功非至关重要的操作的原语使用。根据实施例，每个原语也检查称作isDryRun的字段。如果isDryRun字段被设置为真，那么原语将日志记录(log)它本将执行的工作而不实际地执行它。原语也可以执行一些一致性检查，但是一些一致性检查在该模式中可能不适用。例如，StartServer原语不可以期望StopServer原语实际地关闭服务器，所以它将不执行确保服务器关闭的检查。根据实施例，为了协助管理员诊断可能出现的任何错误，并且回顾针对哪些节点和服务器运行了哪些原语，需要每个原语输出至少一个日志消息到服务器日志，其中该至少一个日志消息指示最高级别工作流的工作流id、正在执行的原语的类型以及受影响的目标，连同任何其他相关信息。示例性补丁修补原语根据实施例，下面描述的是可以用来铺开升级或者补丁的示例性补丁修补原语。根据其他实施例，可以支持不同的和/或附加的补丁修补原语。ShutdownServer(关闭服务器)根据实施例，该原语优雅地关闭指定的受管理的服务器。这通常是长期运行的过程，其中受管理的服务器从“RUNNING(运行)”状态转变为“SHUTDOWN(关闭)”状态，同时允许进行中的工作被优雅地处置。该原语基本上依赖于WLS中的优雅关闭特征。在实际地关闭服务器之前，原语将获得服务器的当前状态(它是RUNNING(运行)、SHUTDOWN(关闭)、ADMIN(监管)还是STANDBY(备用))并且更新称作lastServerState(最后服务器状态)的共享状态特性。这将由StartServer(启动服务器)原语使用，以确定究竟是否应当启动服务器。如果当执行ShutdownServer原语时停止服务器，那么StartServer原语将不会启动它。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持支持重试支持重试支持恢复支持恢复。恢复操作将调取StartServer原语/命令。自定义继续没有自定义行为忽略故障否UpdateOracleHomeDirectory(更新OracleHome目录)根据实施例，该原语执行将OracleHome目录更新为新目录的内容的工作。首先应当关闭从当前OracleHome位置运行的任何过程。一旦新目录到位，节点管理器就将控制转交给将从新目录重启它的外部脚本。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持支持重试重试是可能的，仅仅再次调用脚本支持恢复恢复将OracleHome改变回为原始的自定义继续没有自定义行为忽略故障否PrepareSwitchOracleHome(准备切换OracleHome)根据实施例，该原语向节点管理器给出它为了设置脚本所需要的参数，其中该脚本将用来替换OracleHome目录并且重启节点管理器。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持AssertSwitchOracleHome(断言切换OracleHome)根据实施例，该原语在节点管理器重启之后使用以确认OracleHome被成功更新。如果更新成功则它返回真，否则它将失败。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持StartServer(启动服务器)根据实施例，该原语启动受管理的服务器(使用新路径位置)。如这里文档记录的，服务器可以被配置为以STANDBY(备用)、ADMIN(监管)或者RUNNING(运行)模式启动。该信息保留在配置中并且在下次服务器启动(重启)时使用。当服务器通过该原语启动时，它将自动地转变到它被配置为将要启动的无论哪种模式。默认的服务器启动状态是RUNNING(运行)。根据实施例，该原语也将检查lastServerState共享特性的值，以查看当调用ShutdownServer原语时服务器是否已经处于SHUTDOWN(关闭)状态。如果是，那么StartServer原语将不会启动服务器，因为我们想要保持原始状态。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持RestartNodeManager(重启节点管理器)根据实施例，该原语将重启节点管理器。基于Java的节点管理器进程将以由startNodeManager脚本辨识的具体返回代码退出。当看到该返回代码时，startNodeManager脚本将开始updateOracleHome脚本。updateOracleHome脚本驻留在域目录中，并且负责将当前OracleHome目录移动到指定的备份位置，以及负责将新OracleHome目录移动到位(如果新目录是归档而不是目录，则使用pasteBinary)。然后它将从新OracleHome目录启动节点管理器。如果updateOracleHome脚本在提取归档或者将新目录移动到位时遭遇到错误，那么它将原始的目录移动回位并且启动节点管理器。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持ExecScript(执行脚本)根据实施例，该原语从指定机器上的domain/bin/patching目录运行自定义脚本。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持UpdateNodeDirectory(更新节点目录)根据实施例，该原语调用为单独节点更新OracleHome目录所必需的所有原语。它将调用ShutdownServer、UpdateOracleHomeDirectory、PrepareSwitchOracleHome、AssertSwitchOracleHome、RestartNodeManager、StartServer。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持RolloutDirectory(铺开目录)根据实施例，这是用于跨域或集群铺开OracleHome更新的主要的最高级别的原语。它协调所有其他原语来确保铺开成功。它将考虑铺开模式以确定将更新哪些服务器，并且确保服务器和节点管理器以正确的顺序更新。它将调用checkPrerequisites(检查前提条件)作为第一步骤，以尝试快速地找到可能阻止它成功的任何配置问题。然后它将以正确的次序对每个节点调用UpdateNode(更新节点)。参数原语的参数根据名称传递，任何共享状态对象也是如此。这里是根据名称的参数和共享状态对象的表格。容错支持符号链接在典型的系统中，在域中可能存在引用OracleHome位置的任何地方。这包括启动脚本、属性文件和xml配置文件中的变量。根据实施例，在到OracleHome目录的路径中使用符号链接允许系统通过仅仅改变符号链接来更新OracleHome的位置。这样，当路径改变时，系统不需要跟踪和更新引用该路径的每个文件。在每个节点上，包含OracleHome的共享存储在潜在地暴露安装在共享存储设备上共同目录中的多个应用服务器(例如WLS)版本的级别挂载(mount)。这样，新OracleHome目录可以被创建和补丁修补并且将变得可用，而不必改变任何节点上的挂载点。创建符号链接以通过挂载目录指向具体版本的应用服务器。共享存储上的宿主根据实施例，为了最小化作为运行铺开编排任务的前导必须克隆和补丁修补的目录的数量，推荐将OracleHome放置于可由将要进行补丁修补的所有服务器访问的共享存储设备上。这样，可以执行单个复制并且对其进行补丁修补，并且所有服务器可以挂载相同的存储点。推荐所提供的存储配置有一些冗余，使得对于所有服务器而言它不会变成单点故障。还需要所有服务器使用相同的路径挂载共享存储映像，使得用于每个服务器的符号链接可以以相同的途径更新。集群中的在分离的机器上的服务器如上所述，根据实施例，升级服务器同时维持正常工作时间的要素是利用通过集群配置的高可用性。根据实施例，在集群内最小数量的服务器必须保持一直都是工作的。因为集群内的在相同机器上的服务器将需要一起重启(如果它们共享共同域目录和符号链接)，所以集群内的服务器应当托管在至少两个不同的物理机器上，但是推荐每个集群最少三个机器。这将允许一些服务器保持正常工作并且提供服务，而其他服务器作为滚动重启的部分而关闭。当确定在不同机器上可用于处置请求的服务器的数量时，重要的是排除正在运行但是处于监管模式或者备用模式的受管理的服务器，因为这些服务器将不对请求做出响应。监管服务器分离如果监管服务器和受管理的服务器需要同时更新，那么铺开过程可能非常复杂。例如，如果监管服务器和受管理的服务器被配置在相同的机器上运行并且共享相同的域目录，就将是这种情况。监管服务器将需要与受管理的服务器同时关闭，因为它将从共享的符号链接运行。通过隔离受管理的服务器的安装宿主以允许以每个受管理的服务器为基础铺开补丁，可以解决这个限制。根据实施例，支持简化这个问题的两种不同配置：第一种配置是让监管服务器运行在没有任何受管理的服务器运行在其上的机器上。这允许监管服务器独自在一个步骤中更新，并且一旦该更新完成，下一个步骤将是更新在该域中的在不同机器上的受管理的服务器。第二种配置是允许监管服务器运行在与受管理的服务器相同的机器上，但是使得监管服务器从监管服务器自己单独的域目录中运行。这也将允许监管服务器单独地更新，并且受管理的服务器可以在它们自己的步骤中更新。集群级别补丁修补根据实施例，除了提供将更新域中所有服务器的机制之外，系统可以提供更新域内各个集群的能力。当用户正在尝试使用集群铺开模式时，如果在单个节点上存在服务不同集群的多个受管理的服务器，那么根据它们所服务的集群，受管理的服务器必须具有单独的域目录。这是必需的，使得可以关闭节点上针对集群的所有受管理的服务器并且更新它们的符号链接而不影响服务其他集群(并且仍然在运行)的受管理的服务器的符号链接。铺开模式根据实施例，铺开包括优雅地关闭服务器、改变它的OracleHome符号链接并且再次启动它。这可以应用于整个域、域内的单个集群或者各个服务器。对于这些模式的任何模式，如果在单个机器上存在正在被更新的共享共同OracleHome的多个服务器，那么它们将一起关闭和更新。此外，当更新服务器的OracleHome时，将重启它所关联的节点管理器以拾取改变。可能存在这不是严格必要的情况，但是一致地执行它简化过程并且仅导致短暂的节点管理器不响应的时间窗口。根据实施例，域模式铺开将更新域中的监管服务器和所有受管理的服务器，连同所有它们所关联的节点管理器。监管服务器总是运行在它的任何受管理的服务器当中的最高补丁级别是重要的。为了确保在域模式铺开期间满足这个要求，监管服务器将总是在受管理的服务器之前更新。根据实施例，集群模式铺开将不更新监管服务器，它将更新集群中的所有受管理的服务器以及它们所关联的节点管理器。根据实施例，服务器模式铺开将影响在目标参数中指定的服务器。它也将更新与这些服务器相关联的节点管理器。铺开WLST命令根据实施例，铺开任务负责弄清楚哪些服务器需要被更新，以什么次序更新，并且负责创建将安全地更新它们的工作流。这包括使得节点静默、优雅地关闭服务器、更新OracleHome链接、重启节点管理器、启动服务器以及优雅地激活节点。铺开任务取它将向工作流生命周期管理器(例如，WorkflowLifecycleManager，LCM)注册的名称，使得结果MBean可以在随后的时间处或者由另一个WLST连接访问。铺开任务将返回WorkflowProgressMBean，该WorkflowProgressMBean可以被轮询以获取状态。下面提供一些示例：执行跨域的铺开：>progress＝rollout(′DomainlRollout′，/opt/OracleHome，/mnt/wls1214.01)执行跨集群的铺开：执行到两个具体服务器的铺开：执行跨域的演习(dryrun)或者铺开而不配置OTD：根据实施例，WLST铺开命令返回WorkflowProgressMBean，其中该WorkflowProgressMBean可以被查询以监控铺开任务的进展。该信息可用于需要重新连接的WLST会话，并且在工作流已经完成之后仍然保持可用。节点管理器根据实施例，自动补丁铺开方案需要更新远程机器上的环境的机制。根据实施例，编排框架可以从监管服务器执行并且委派每个机器上的节点管理器执行诸如更新OracleHome以及重启进程这样的任务以摄取(uptake)新的二进制内容(binaries)。根据实施例，节点管理器将用作在远程机器上执行自定义补丁修补脚本以改变到OracleHome的符号链接的机制。可以每个域每个机器地执行脚本一次。节点管理器支持内部使用的API以允许在自动化的服务迁移期间的基础脚本执行，这可以被用来支持上面描述的补丁修补特征。根据实施例，符号链接将在节点管理器运行时被切换，然而，startNodeManager脚本将被设置为从实际目录运行而不总是使用符号链接。符号链接将仅用于重启节点管理器以使得它将能够摄取经补丁修补的二进制内容。或者在域中或者在OracleHome外部的节点管理器宿主中的父启动脚本将使用符号链接位置执行基本startNodeManager脚本。基本脚本以设置为真实目录的WL_HOME安装并且使用该值生成所有环境值。结果是当域从符号链接位置运行时，节点管理器将仅仅从真实目录运行并且因此在符号链接被切换时不会受影响。根据实施例，从节点管理器运行的系统组件将具有确保它们的进程可以支持补丁修补的选项。首先，如果它们利用节点管理器环境来启动它们的进程，那么它们将与符号链接改变隔绝并且将与节点管理器版本一致。这意味着它们将能够在符号链接被改变时保持它们的组件运行，并且仅在节点管理器重启之后重启以便取得新OracleHome位置。其次，如果它们希望更直接地利用符号链接，那么它们将需要通过像WLS使用的那样的某个启动脚本从域本身获得那个值，或者从节点管理器环境获得作为已定义值(诸如LINK_MW_HOME)的那个值，并且将需要确保它们的进程在符号链接改变之前适当地关闭。再另一个选项是允许它们供应它们自己的路径信息并且直接管理它。例如，OHS安装在JAVA_OPTIONS环境标记中将“ohs.home”传递到节点管理器。这个值通过提供控制什么时候改变路径以及什么时候重启进程的它自己的补丁修补原语，而可以作为在补丁修补期间受管理的符号链接。根据实施例，作为自动铺开补丁修补的一部分，通过将例如“RESTART(重启)”命令发出到节点管理器，可以重启节点管理器使得它从新的(经补丁修补的)WebLogic服务器映像运行。节点管理器也能够以其他途径启动，诸如指定不同选项的用户提供的脚本。一种方式是依赖于基本startNodeManager脚本来捕获内部退出代码并且然后执行在符号链接位置找到的startNodeManager脚本。例如，传入的RESTART(重启)命令将使用代码88退出JVM。脚本将看到88并且将尝试使用新脚本启动另一个实例以便拾取对脚本自身的任何改变。这不会拾取对域级别脚本或者其他包装器脚本的任何改变，仅仅拾取对WL_HOME/server/bin下的基本startNodeManager脚本的改变。这通过执行由父脚本使用的SCRIPTPATH(脚本路径)来实现，该SCRIPTPATH在此特定拓扑中将是符号链接。根据实施例，在自动补丁铺开方案中，铺开命令将关闭所有受管理的服务器，经由节点管理器执行自定义补丁修补脚本，启动所有受管理的服务器，并且重启节点管理器。节点管理器自身通过经由System.getenv()API和/或使用ProcessBuilder.environment()API获取系统属性并且当创建新进程时将这些值连同配置值一起提供给新进程来传递它自己的环境。根据实施例，当域具有它自己的到OracleHome目录的唯一符号链接时，它可以被掉换(swap)同时节点管理器维持它对OracleHome目录的原始视图。在这种拓扑中，节点管理器将传递CLASSPATH(类路径)以及将向受管理的服务器给出指向来自不正确版本的二进制内容的指针的其他值。这可以通过仅传递不是特定于WebLogic服务器和OracleHome的环境值来解决。根据实施例，在每个域的节点管理器和每个机器的节点管理器这二者中，期望NodeManagerHome(节点管理器宿主)目录位于OracleHome目录外部。默认地，每个域的节点管理器的NodeManagerHome目录是域目录下的子目录。节点管理器重启根据实施例，系统可以提供重启基于Java的节点管理器进程的自动化的能力。基于Java的节点管理器根据实施例，基于Java的节点管理器将接受从NMClient发出的新命令“RESTART(重启)”。当NMServer接收到重启命令时，它将以具体的退出代码88退出。也应当采取任何优雅的关闭动作，但是由节点管理器启动的受管理的进程应当保持运行。提出NMClientAPI：/***将RESTART(重启)命令发出到NMServer*@paramtimeoutMillis在抛出IO异常之前等待节点管理器进程重启并且可达*的时间量。值为0将返回而不阻塞。值必须为正。*/publicvoidrestart(longtimeoutMillis)throwsIOException；startNodeManager脚本根据实施例，当Java节点管理器不再运行时，所供应的startNodeManager脚本将检查具体的代码88。当88作为返回代码时，那么脚本将发动(launch)在符号链接位置处找到的新startNodeManager脚本。包括二进制内容和脚本的所有新的补丁文件将被放置于单独的位置中，并且将通过使用符号链接而可用。这意味着应当没有文件曾被覆写(overwritten)。像下面的示例一样对重启场景编写脚本，其中$WL_HOME指向符号链接位置：根据实施例，启动节点管理器进程的许多不同方法可以利用包含在WL_HOME/server/bin目录中的基本startNodeManager脚本。自定义包装器以及domain/bin中的域级别脚本应当委派该脚本，并且作为结果使用相同的逻辑以发动，并且WLSTstartNodeManager命令也可以使用这些脚本。图16例示根据实施例的用于补丁修补的方法的流程图。如图16中所例示的，在步骤660处，在一个或多个计算机处提供应用服务器环境，包括用于执行软件应用的域，域支持一个或多个分区，其中每个分区提供域的监管性和运行时细分，并且其中分区可以可选地包括一个或多个资源组，资源组具有可部署应用或者资源的聚集和/或引用资源组模板。在步骤662处，通过优雅地关闭这些节点上的服务器，具有应用服务器、应用或者其他组件运行在其上的一个或多个计算机节点或者服务器准备好进行补丁修补。在664处，在将要进行补丁修补的节点或者服务器处调用准备切换，该准备切换指导用于该节点或者服务器的节点管理器设置将执行它的宿主目录切换的脚本，并且向节点管理器提供它执行操作所需要的参数。在步骤668处，执行调用以重启节点管理器，这使得节点管理器将控制转移给如下脚本，该脚本将当前宿主目录(例如，OracleHome)移动到指定的目录路径，将经补丁修补的应用服务器、应用或者其他组件映像提取到原始位置，并且然后再次启动节点管理器。在步骤672处，执行断言切换，这将确认宿主(例如，OracleHome)目录的切换已经成功完成。在步骤674处，对于每个节点或者服务器调用启动服务器，以确保在工作流将再关闭更多节点或者服务器之前所有经补丁修补的应用服务器、应用或者其他组件可以服务请求，这支持有限的停机时间或者没有(亦即，零)停机时间。零停机时间补丁修补期间的会话复制根据实施例，在零停机时间补丁修补期间，防范会话丢失以便确保“零停机时间”是重要的。这意味着要负责滚动补丁修补过程期间的会话复制和故障转移，以及关注由于应用补丁修补而引起的会话兼容性。在典型的应用服务器(例如，WLS)环境中，系统通常尝试确保会话将在集群中某个地方可用，只要集群的仅单个成员在用户请求之间的时间期间关闭。如果主服务器崩溃(crash)并且然后辅助服务器崩溃，那么会话将丢失。因为来自主服务器的所有会话都复制到单个辅助服务器，所以会话复制分布在整个集群不是均匀的。然而，请求故障转移是均匀地分布的。这意味着当一组请求故障转移到另一个服务器时，均匀的部分将着陆到辅助服务器以及跨集群的每一个剩余服务器上。每个服务器然后将负责已经接收到的那一部分的请求。不具有会话复本的服务器将不得不取回会话并且然后将使用它们自己的辅助选择算法来决定在哪里保持备份复本。旧的、或者孤立的复本留在原地直到它超时。最终的结果是请求的均匀分布将确保即使复制算法不是均匀分布的，存储器中的会话也多少是均匀地分布的。异步复制具有不同的窗口，其中请求已经完成但是会话改变还没有被复制。该时间窗口也意味着无论何时请求由于服务器崩溃而故障转移或者从前端不正确地被路由，都可能存在被服务的陈旧(stale)的会话。根据实施例，用于针对特定会话id的找到会话对象的算法是：1.检查用于会话ROID的本地映射并且在找到时使用它。2.检查客户端cookie(网络跟踪器)中的JVMID以尝试从主服务器或者辅助服务器获取会话。3.当会话可用时，从该服务器获取会话，变成主会话并且复制到我们优选的辅助服务器。4.来自原始的主/辅助服务器的会话将变得孤立并且将仅在失效或者超时时清理。5.如果会话从上面不可用，那么返回新的会话。这意味着虽然cookie可以指向有效的主服务器或者辅助服务器，但是存在使用会话的本地复本的可能性。这将在出现故障转移并且不是辅助服务器的服务器服务请求时发生。原始的辅助服务器具有陈旧的复本并且如果对该服务器出现另一个故障转移，那么陈旧的复本将在任何其他复本之前被找到并使用。用于每个服务器的辅助选择将尝试自动地或者基于优选候选服务器、远程候选服务器以及本地候选服务器的配置值而选择辅助服务器。在没有额外的配置的情况下，自动选择将基于当前服务器在完整服务器列表中的索引与远程服务器列表的大小的取模运算来选择来自另一个机器的服务器。当每个机器包含单个服务器并且每个机器以与服务器类似的次序组织时，这导致每个服务器复制到列表中的下一个，服务器1到服务器2，服务器2到服务器3，服务器3到服务器4并以此类推，直到列表中的最后一个服务器复制到服务器1。当前端服务器由于关闭而不能够维持与主服务器的联系(affinity)时，它将以均匀分布在剩余的集群服务器中随机地重定向请求。在零停机时间补丁修补期间，有可能铺开包含上层应用的经补丁修补的OracleHome，或者甚至独立于OracleHome补丁铺开具体的应用补丁。当这些应用包含改变时，系统必须防范会话不兼容的可能性。会话不兼容的常见场景随着应用框架的使用而出现。使用新版本的这种框架来更新应用将导致缺少对于包含在类路径中的类的控制。一个经补丁修补版本的应用会话可能在会话中包含类“patched.Foo”，然而先前版本的应用会话可能包含类“unpatched.Bar”。当请求触发复制会话的尝试时，序列化将在经补丁修补或者未经补丁修补的服务器上出现，同时解除序列化的尝试可以在相反状态的服务器上出现。在缺少类路径中的适当的类的情况下，接收会话的服务器将不能完成解除序列化过程。这将导致会话没有被复制并且在日志文件中打印警告消息。由于会话仅存在于单个服务器上，它将处于由于服务器关闭或者服务器崩溃而丢失的风险中。当对应用进行补丁修补时，复制会话的能力是重要的，但是同样重要的是确保会话在某个服务器上成功地解除序列化以便服务请求的能力。在服务器已经关闭之后，前端将以均匀的分布将请求随机地故障转移给集群中的剩余成员当中的一个。一旦服务器接收到请求，它将尝试从保持该会话的复本的服务器抓取会话。当经补丁修补或者未经补丁修补的服务器尝试加载起源于相反状态的服务器的会话时，不兼容的会话将导致解除序列化错误并且用户将丢失它们的会话信息。这种场景将经常发生在服务器关闭并且然后带有补丁重启同时集群的其他成员处置随机的故障转移请求的补丁铺开过程期间。对于任何故障转移请求都可能是这样的情况，因为集群成员是从前端服务器随机选择的。此外，缓慢客户端或者懒惰客户端可以在服务器已经补丁修补之后将请求发送回到相同的服务器。这将具有如下效果：经补丁修补的服务器尝试加载存储在某个其他服务器上的“未经补丁修补的会话”。零停机时间补丁修补以滚动的方式更新每个节点，其中在继续下一个节点之前，服务器1关闭、进行补丁修补并且然后重启。当过程进行到将要补丁修补的最后一个服务器时，存在起源于未经补丁修补的服务器的、可能仅在最后一个服务器上兼容的一组会话。如果最后一个服务器在这些会话完成(超时或者失效)之前关闭，那么这些会话可能不会加载在任何服务器上并且将丢失。然而，如果会话是兼容的，那么它们可以安全地关闭而不等待。随着零停机时间补丁修补滚动通过集群，正在进行补丁修补的服务器将关闭，从而将它的主会话置于危险中。这是因为，当服务器1关闭时，它的会话的主复本不再可用。如果服务器2正在托管辅助会话，那么它们在服务器2上升高为主状态，但是直到另一个请求到来以更新会话时，会话才复制到集群中的任何其他服务器。在重启服务器1之后不久，作为补丁修补铺开中的下一个操作，可以关闭服务器2。在服务器2关闭之前没有发送另一个请求的任何客户端将丢失它的会话信息。根据实施例，为了处置会话不兼容并且对现有复制服务影响最小，补丁修补框架将连接到每个服务器并且临时启用对会话懒惰地进行解除序列化、集群范围的会话查询的现有选项，连同在关闭时复制会话以及在取回它们之后清理孤立辅助会话的新选项。这些选项将组合以确保会话可以跨集群适当地存储，并且最小化补丁修补期间的会话丢失。为了充分满足避免会话丢失的目标，系统必须确保能够加载会话的服务器服务请求。根据实施例，这将再次以对现有会话处置的最小干扰来完成。服务器将乐观地尝试加载会话并且当它不能做到这一点时，它将使用503响应代码将应当能够处置该请求的服务器的适当列表传达至OTD。根据实施例，当关闭将要进行补丁修补的服务器时，会话复制选项将允许服务器自动地复制确保它们在辅助服务器上全部可用所必要的任何会话。当补丁修补框架即将关闭集群中的最后一个服务器时，它将在关闭该服务器时默认发出信号waitForAllSessions(等待所有会话)。这将发出信号web容器以告知在服务器可以完成关闭之前所有会话都必须被处置。用户可以可选地提供输入以发出信号告知：所有应用补丁具有兼容的会话类并且因此对于集群中的最后一个服务器不需要等待。懒惰会话解除序列化是在诸如Exalogic平台之类的一些系统上启用的基于性能的特征。ReplicatedSessionData(复制的会话数据)对象查询ClusterMBean(集群MBean)以检查在决定是否对会话特性进行解除序列化之前是否启用了LazySessionDeserialization。当启用了LazySessionDeserialization时，会话特性将有效地存储为字节阵列。该字节阵列将随后在特性被检索时自动地解除序列化。根据实施例，为了只在必要时利用加载会话的这个能力，功能性可以变得动态。补丁修补框架将具有在补丁修补过程期间启用/禁用懒惰会话解除序列化的责任。因为这也是配置值，所以框架将只有在还没有启用ClusterMBean配置的情况下才尝试改变设置。否则，每个受管理的服务器上的ClusterService(集群服务)将用来接收运行时值，这些运行时值在被启用时将优先于配置值。这意味着ClusterService可以在即使LazyDeserializtion(懒惰解除序列化)关掉时打开LazyDeserializtion。但是当用户已经将LazyDeserializtion配置为打开时，ClusterService不能禁用它。因为这将是运行时值，所以补丁修补框架将不得不做出对ClusterService的多个调用。第一个通知将在集群中的任何服务器被补丁修补之前出现。它将使用RemoteClusterServicesOperations(远程集群服务操作)接口连接到集群中的每个服务器，以便在ClusterService上设置LazySessionDeserialization(懒惰会话解除序列化)。第二个通知将在服务器已经进行补丁修补并且重启之后发生。在重启之后，服务器将再次使用配置值，所以有必要重新建立运行时设置以启用LazySessionDeserialization。当补丁修补过程完成时，补丁修补框架将在必要时禁用懒惰会话解除序列化选项。根据实施例，补丁修补框架将以一对服务器列表的格式警告集群的每个成员关于服务器的当前状态。服务器名称的一个列表将被认为是一个分组，并且服务器名称的另一个列表将被认为是另一个分组。将再次存在通知是必要的两个不同的点。第一个通知将在关闭服务器并且应用补丁之后出现。在重启该服务器之前，将在新近经补丁修补的服务器加入经补丁修补列表情况下的新分组通知给集群。这将确保当重启经补丁修补的服务器时运行的服务器不具有陈旧的信息。第二个通知将在已经启动服务器之后立即出现，同时框架等待所有应用变得就绪。目标是确保服务器尽可能快地被通知，以确保它可以正确地处置涉及会话不兼容的任何请求。最后，在补丁修补过程完成之后，值将被重置为空(null)并且最后通知到集群。这将恢复补丁修补之前的状态，所以集群将不再假设补丁修补正在进行中从而行为可以再次返回到默认。根据实施例，web容器将乐观地尝试检索已复制的会话。如果存在出现的解除序列化错误，那么web容器将检查当前服务器分组。当前服务器分组的值将指示补丁修补当前是否正在进行中。web容器将检查分组的内容以识别当前服务器在哪个分组中。基于当前服务器不兼容并且因此其他分组必须兼容的逻辑，不包含当前服务器名称的分组将被认为是兼容分组。这应当同时服务前向兼容性问题和反向兼容性问题。一旦web容器已经识别在其中会话最有可能兼容的服务器的分组，它将返回503响应代码连同“X-WebLogic-Cluster-FailoverGroup-List”报头，该报头具有该分组中的服务器的列表。根据实施例，OTD将接收503连同包含服务器分组的报头，并且将从该列表中随机地选择服务器以重定向请求。OTD将必定处置耗尽池(drainpool)中的服务器，因为这是WLS不具有的信息。服务器指定的列表将包含集群中的在运行时生成的当前成员。这应当与加入集群的WebLogic服务器的动态发现相类似地由前端处理。列表将本质是动态的并且可以在运行时期间改变，然而，列表将包括在补丁修补过程启动时所有已知的集群成员。根据实施例，补丁修补框架将有责任在补丁修补期间使得能够实现会话的恰当处置。关闭期间会话的这种复制将取决于启用集群范围的会话查询以及孤立辅助会话清理这二者。框架将只有在ClusterMBean配置没有启用任一设置的情况下才尝试改变该设置。框架将在补丁修补之前连接到每个服务器并且将启用每个标记。然后，随着每个服务器重启，标记将不得不再次设置。最后，在补丁修补过程完成之后，设置将在必要时恢复。根据实施例，已经为WLS-MT集群实现的会话取回(sessionfetching)被用来自动地将会话复制到辅助服务器而不更新客户端cookie，使得故障转移请求将着陆在集群的任何成员上并且我们将需要某种机制来找到会话。当请求着陆在服务器上时的行为将是：检查用于会话ROID的本地映射并且当找到时使用它。2检查客户端cookie中的JVMID以尝试从主服务器或者辅助服务器获取会话。3当会话可用时，从该服务器获取会话，变成主会话并且复制到我们优选的辅助服务器。4将引入新机制来处理原始的主/辅助服务器上的孤立会话。5如果会话从上面不可用，那么：如果SessionFetching没有启用则返回新的会话。如果SessionFetching被启用，那么将广播查询发送到集群。第一个响应将被用来识别我们可以获得获取会话的服务器。我们变成主会话并且复制到我们优选的辅助服务器。ii.将引入新机制来处理原始的主/辅助服务器上的孤立会话。根据实施例，在服务器关闭期间，就在通知其他集群成员该关闭之前，ReplicationService将确保会话的每个主复本被复制到辅助服务器。这将确保在服务器的关闭操作期间没有会话丢失。这将仅影响自从原始的主服务器已经重启之后没有做出请求的客户端(意味着它们没有使用新的辅助服务器重新建立新的主服务器)。最后，当这种客户端返回时，会话将在集群中某个服务器上可用。根据实施例，孤立会话不是会话取回或者关闭时的会话复制独有的。然而，因为接连重启每个服务器的集群的迭代，这个问题变得更加可能。为了处理服务来自从孤立辅助会话的陈旧会话数据的可能性，将存在在取回之后清理孤立辅助复本的机制。当在补丁修补期间启用该功能性时，ReplicationService(复制服务)将触发后台进程，该后台进程将在取回该会话之后处置孤立会话的清理。后台进程将知道会话版本编号、时间戳信息、在哪里找到了会话、会话可能已经与其相关联的任何其他服务器以及新的辅助服务器。这将允许我们基于版本和时间戳信息清理所有陈旧复本，而不移除会话的当前复本。根据实施例，当优雅地关闭服务器时，用户可以指定ignoreSessions＝false(忽略会话＝假)来使得web容器等待没有被复制的会话的完成。但是web容器不会等待已复制的会话，因为在集群中某个地方存在会话复制品(replica)。但是对于ZDT补丁修补，如果会话不兼容并且服务器是集群中最后一个未补丁修补的服务器，那么服务器将是唯一具有兼容会话的服务器，并且它必须等待所有会话完成。为此目的引入用于优雅关闭的“waitForAllSessions”标记。当对集群中最后一个服务器调用关闭时，补丁修补框架将默认地指定“waitForAllSessions”布尔值。这将发出信号到web容器以等待所有会话在完成关闭序列之前失效。所有不具有相关联的会话的请求将由503响应拒绝，如果OTD得到503响应，OTD将尝试集群中的其他服务器来服务这些请求。具有现有会话的所有请求将被恰当地服务。web容器必须处置这些会话当中的每一个直到完成，因为它们在任何经补丁修补的服务器上可能不兼容。当开始补丁修补操作时用户可以可选地指定SessionCompatibility＝true(会话兼容＝真)以便发出信号告知waitForAllSessions可以是假。waitForAllSessions选项可以类似于现有ignoreSessions参数被添加到ServerLifeCycleRuntimeMBean(服务器生命周期运行时MBean)。根据各种实施例，可以支持附加参数，例如指示在开始关闭下一个用于进行补丁修补的受管理的服务器之前等待多久的超时(delayBetweenNodes(节点间延迟))；该超时可以用于确保在尝试关闭服务器之前辅助会话被复制。快速入门示例根据实施例，零停机时间补丁修补可以通过将改变一次铺开到一个节点，并且允许流量引导器(例如，OTD)将传入的流量重定向到剩余的节点直到改变完成来实现。用于例如OracleHome的补丁修补的典型序列操作包括：1.管理员检验补丁；2.创建OracleHome和代表性域的复本；3.补丁应用于测试/检验环境；4.执行测试以确保同意补丁用于生产；5.使用脚本复制经检验的OracleHome，并且所生成的归档被认为是将跨生产环境而铺开的经补丁修补的“黄金主档”；6.由管理员将所生成的OracleHome归档分布到跨生产环境的每个物理机器；以及7.管理员执行铺开操作。JavaHome的安装/更新以及应用源的分布可以类似地由管理员决定用于这些铺开操作。根据实施例，目标环境必须包括三个或者更多的物理机器或者节点；包括将运行监管服务器的一个节点。根据实施例，附加的要求包括受管理的服务器必须在集群中以支持零停机时间；每个节点必须具有它自己的节点管理器在运行，包括运行监管服务器的节点；OracleHome目录必须本地地安装在每个节点上，优选地在每个节点上相同位置(例如，/scratch/aime1/OracleHomes/wls1221)；以及域目录必须在OracleHome目录外部。管理员可以通过利用移动脚本创建OracleHome的归档jar并且将归档jar复制到每个远程节点，来避免不得不在每个节点上复制安装和域。根据实施例，域必须引用至少两个受管理的服务器以及至少三个节点管理器。可以使用压缩/解压缩实用程序对于多个节点而复制域，包括做出域的复本，并且将该二进制内容分布到两个远程节点，并且然后在每个远程节点上执行解压缩。为了使得JavaHome铺开成功，新的JavaHome必须安装在每个受影响的机器上，并且在每个机器上必须被放置于相同路径。这必须在当前节点管理器和受管理的服务器运行时完成，使得安装必须不改变现有的JavaHome路径。为了协助这一点，JavaHome指定为绝对路径，而不是作为包含符号链接的路径。一旦开始铺开操作，对于OracleHome的任何改变一次将应用一个节点。如下面进一步描述的，管理员可以使用OPatch工具以应用期望的补丁。一些客户可能具有已到位的可以帮助文件分布的工具，像Puppet或者Chef。与OPatch集成根据实施例，系统可以与诸如OpatchAuto之类的产品集成，以跨一系列例如Oracle产品为零停机时间补丁修补提供面向客户的前端。集成这些特征在单个接口下提供更完整的解决方案。根据实施例，OPatchAuto提供允许用户创建例如WLS组件的经补丁修补版本的工具，以使得它们对将要更新的节点可访问，以及调取并且监控补丁修补铺开。补丁修补基础设施管理服务器的可用性以及运行时状态、更新WLS组件和应用源、并且解决任何多租用问题同时确保活跃的会话被保存。在一些情景中，客户可能想要将铺开与经补丁修补的归档的创建分离，以便在非生产环境下执行验证测试，或者他们可能想要组合这些部分的单个动作。根据实施例，OPatchAuto提供作为分开或者组合的步骤的创建经补丁修补的WLS归档、使得归档对所有节点可用、以及发起铺开的能力。用户可以使用OPatchAuto创建将分布到每个节点的经补丁修补的二进制内容、在每个节点上存放经补丁修补的二进制内容、以及执行经补丁修补的二进制内容的运行时激活而没有服务停机时间(让WLS负责运行时管理和铺开)。根据实施例，OpatchAuto充当在WLS环境中驱动零停机时间补丁修补的入口点，包括提供审查补丁元数据使得补丁修补计划可以决定对于该拓扑ZDT补丁修补是否被支持的能力，以及提供创建用于测试的离线的经补丁修补的环境的工作流能力。这将包括直接从生产环境或者被认为等同于生产环境拷贝现有OracleHome的能力。附加地，OPatchAuto将提供将经成功补丁修补并且经测试的OracleHome归档分布到拓扑中的各种节点的工作流能力。这将让环境准备好用于可以使用OPatchAuto在任何时间处发起的铺开。OPatchAuto也可以用来发起并且监控补丁修补铺开。补丁修补基础设施负责确定服务器将被更新的次序；监控补丁修补铺开的步骤并且确定什么时候继续前进以及如果必要的话什么时候恢复；确保保存会话；管理服务器生命周期并且换入经补丁修补的OracleHome比特(bit)；提供它的标准进展对象以由OPatchAuto查询以用于状态更新；以及增强进展对象以提供关于将要对哪些服务器进行补丁修补以及已经补丁修补哪些服务器的信息。该信息也将在铺开开始执行之前经由进展对象变得可用。示例：在MW_HOME外部创建应用服务器(例如，WLS)域。创建OPatchAuto钱包(wallet)经由SSH/JMX连接到主机：将补丁应用于监管服务器并且基于不在位的经补丁修补的OracleHome创建归档：验证之后，将经补丁修补的归档存放到将要更新的所有节点：发起并且监控到整个域或者特定集群的铺开：继续或者回退失败的铺开：本发明可以使用一个或多个常规通用或者专用数字计算机、计算设备、机器或者微处理器(包括根据本公开的教导而编程的一个或多个处理器、存储器和/或计算机可读存储介质)来方便地实现。如将对软件
技术领域：
中的那些技术人员清楚的，适当的软件编码能够容易地由熟练的程序员基于本公开的教导而准备。在一些实施例中，本发明包括作为非临时性存储介质或者(一个或多个)计算机可读介质的计算机程序产品，这些介质具有存储在其上/其中的指令，这些指令可以用来对计算机进行编程以执行本发明的任何过程。存储介质能够包括但不限于任何类型的盘(包括软盘、光盘、DVD、CD-ROM、微型硬盘以及磁光盘)、ROM、RAM、EPROM、EEPROM、DRAM、VRAM、闪存存储器设备、磁卡或者光学卡、纳米系统(包括分子存储器IC)，或者适合于存储指令和/或数据的任何类型的介质或者设备。已经为了例示和描述的目的而提供了本发明的前述描述。它不打算是穷举的或者将本发明限制为所公开的精确形式。许多修改和变化对于本领域中熟练的实际工作者将是清楚的。选择并且描述实施例以便最好地解释本发明的原理以及它的实际应用，由此使得本领域的其他技术人员能够理解关于各种实施例以及具有适合于所思考的特定使用的各种修改的本发明。本发明的范围旨在由下面的权利要求书及其等同物定义。当前第1页1 2 3