用于评估升级活动的方法和系统与流程

本申请要求在2016年5月19日提交的编号为62/338,587的美国临时申请的权益。

本公开的实施例涉及用于高可用系统的软件管理。

背景技术：

高可用性（ha）是对电信级服务（carriergradeservice）的重要要求。服务可用性论坛（saf）为ha使能中间件开发了一套标准服务。在这些服务之中，可用性管理框架（amf）负责管理应用/服务可用性，而软件管理框架（smf）负责对执行在这些应用上的改变的升级活动进行编排。

升级活动是将系统从其当前配置迁移到例如部署新版本的某一软件的目标配置的过程。在符合服务可用性论坛（saf）的环境中，smf通过遵循路线图：升级活动规范（其描述要进行的改变和它们的排序）来编排此迁移。升级活动规范描述初始化和回绕活动的动作以及构成活动的主体的升级过程。每个过程具有升级范围、升级方法和构成此过程的步骤的共同属性。基于升级范围、升级方法和当前系统配置的状态，在执行时间，smf将每个过程分解成多个升级步骤。每个步骤具有一系列的动作，其中一些动作是在服务被提供的同时在线被执行，而其它动作是通过在升级服务提供商的子集的同时使它们停止服务而被离线执行。后者可诱发一定的服务停运。

若干升级活动规范可能适用于使系统从源配置变成目标配置。这些升级活动规范共同具有它们必须要执行的改变的集，但它们在其它方面有所不同，诸如过程的数量、过程的排序或甚至每个过程的范围和升级方法的选择。因此，一些升级活动规范可诱发更多的停运或者可比其它升级活动规范采用更长的时间来执行。

技术实现要素：

在一个实施例中，提供有用于从将系统从当前配置升级到目标配置的升级活动规范的给定集选择一个或多个升级活动规范的方法。方法包括：（a）对于每个升级活动规范：识别在升级活动规范中为升级系统指定的软件和管理操作；以及对于按照操作执行时间选择和执行模式定义的一个或多个情形的集中的每个情形，根据软件和管理操作的对应安排，模拟系统的升级，从而获得对应的执行时间和对应的停运。方法进一步包括：（b）拒绝升级活动规范的子集，对于所述子集，对应的执行时间不满足执行时间阈值，或者对于所述子集，对应的停运不满足停运阈值。

在另一实施例中，提供有一种包括处理电路系统和存储器的网络节点。存储器包含由处理电路系统可执行的指令，用以从将系统从当前配置升级到目标配置的升级活动规范的给定集选择一个或多个升级活动规范。网络节点可操作以：（a）对于每个升级活动规范：识别在升级活动规范中为升级系统指定的软件和管理操作；以及对于按照操作执行时间选择和执行模式定义的一个或多个情形的集中的每个情形，根据软件和管理操作的对应安排，模拟系统的升级，从而获得对应的执行时间和对应的停运。网络节点进一步可操作以：（b）拒绝升级活动规范的子集，对于所述子集，对应的执行时间不满足执行时间阈值，或者对于所述子集，对应的停运不满足停运阈值。

在仍有的另一实施例中，提供有可操作以从将系统从当前配置升级到目标配置的升级活动规范的给定集选择一个或多个升级活动规范的网络节点。网络节点包括：识别模块，适于为每个升级活动规范识别在升级活动规范中为升级系统指定的软件和管理操作；模拟模块，适于为每个升级活动规范和为按照操作执行时间选择和执行模式定义的一个或多个情形的集中的每个情形，根据软件和管理操作的对应安排，模拟系统的升级，从而获得对应的执行时间和对应的停运；以及拒绝模块，适于拒绝升级活动规范的子集，对于该子集，对应的执行时间不满足执行时间阈值，或者对于该子集，对应的停运不满足停运阈值。

在另一个实施例中，提供有用于从将系统从当前配置升级到目标配置的升级活动规范的给定集选择一个或多个升级活动规范的方法。方法包括在云计算环境中发起服务器实例的例示，云计算环境提供处理电路系统和存储器以用于运行服务器实例。服务器实例可操作以：（a）对于每个升级活动规范：识别在升级活动规范中为升级系统指定的软件和管理操作；以及对于按照操作执行时间选择和执行模式定义的一个或多个情形的集中的每个情形，根据软件和管理操作的对应安排，模拟系统的升级，从而获得对应的执行时间和对应的停运。服务器实例进一步可操作以：（b）拒绝升级活动规范的子集，对于所述子集，对应的执行时间不满足执行时间阈值，或者对于所述子集，对应的停运不满足停运阈值。

在结合附图查看特定实施例的以下描述后，其它方面和特征将变得对本领域技术人员而言是显而易见的。

附图说明

现在将仅通过示例，参考附图来描述实施例。

图1图示了根据一个实施例的升级活动规范的模拟和评估框架。

图2图示了根据一个实施例的扩展元类的示例。

图3图示了根据一个实施例的另一扩展元类的示例。

图4图示了根据一个实施例，在模拟中牵涉到的对象和模型。

图5图示了根据一个实施例，用于评估升级活动规范的方法。

图6图示了根据另一实施例，用于评估升级活动规范的方法。

图7是图示了根据一个实施例，用于选择一个或多个升级活动规范的过程的图。

图8是图示了根据一个实施例，用于选择一个或多个升级活动规范的方法的流程图。

图9是根据一个实施例的网络节点的框图。

图10是根据一个实施例的另一网络节点的框图。

图11是根据一个实施例的云计算环境的架构概览。

具体实施方式

下面可对根据附图进行编号的具体要素进行参考。下面的讨论应在性质上被视为是示范性的，并且不应被视为受下面描述的实现细节限制，其如本领域技术人员将领会到的，能够通过将要素替换为等效功能要素而被修改。

本发明的实施例提供用于从升级活动规范的给定集选择一个或多个升级活动规范的方法和系统。为选择优于另一升级活动的一个升级活动，必须考虑在该升级活动的执行期间在系统中可发生的每个行为。这在一方面包括执行升级步骤、升级过程和升级活动的smf的行为；并且在另一方面包括相对于作为升级活动的目标并且其可用性由amf管理的配置对象表示的系统实体，amf的行为。因此，做出此决定不是直接的任务，并且随着系统变得更大和更复杂，它变得甚至更加困难。

本文中描述的实施例为升级活动规范的评估提供基于模拟的方案。该方案基于用来对升级活动规范及其执行环境进行建模的离散事件系统规范（devs）形式体系（formalism），以及用来执行模拟和评估的devs-suite模拟器。为从诱发的停运和执行时间两者的角度比较升级活动规范，最佳和最差情况的特定情形被作为用于每个升级活动规范的目标。在这两种情形中模拟升级活动规范能够向管理员提供会预期到什么的见识以及在维护窗口内升级活动规范的适用性。

最佳和最差情况情形被定义用于升级活动规范的完全和部分有序执行。基于这些定义，能够对于每个升级活动规范获得针对这些情形的服务停运和执行时间。执行时间和服务停运能够与目标维护窗口和合适的服务停运（如果有的话）进行比较。能够做出有关是否可修改升级活动以满足维护窗口和服务停运的要求的建议。

在描述用于选择一个或多个升级活动规范的方法和系统前，解释包括amf和smf的符合saf的环境中的相关概念是有用的。然而，应理解的是，下文描述的模拟和评估框架具有广义适用性，并且不被限于符合saf的环境。例如，模拟和评估框架可也适用于网络功能虚拟化（nfv）的领域。amf和smf的角色可由管理和编排功能的不同部分（例如，虚拟网络功能管理器、网络功能虚拟化编排器、虚拟基础设施管理）履行。

amf根据指定描述系统的实体及其关系的配置对象的配置，管理服务提供商资源。此配置的最小构件是组件，其表示诸如软件的执行的资源。每个组件能够提供称为组件服务实例（csi）的一个或多个基本服务。组件集形成服务单元（su）以提供服务实例（si），其是由此su的组件提供的csi的聚合。为确保服务可用性，将能够提供相同si的冗余su编组到服务群组（sg）中。为提供si表示的服务，在运行时，amf指派si到保护性sg的一些su。如果被指派的su不能提供服务，则amf指示相同sg的另一su来接管。sg通常被部署在构成集群的节点的子集上。关于组件、csi、si、su和sg的所有此信息作为配置被提供到amf。系统的动态运行时间状态通过属性集被捕捉。除其它之外，属性还捕捉组件生命周期的不同阶段（存在状态）、su提供服务的合适性（管理状态）、以及si供应级别（指派状态）。在配置中的每个实体的状态影响其父项的状态，且反之亦然。这些状态遵循在safamf规范中使用有限态机器（fsm）描述的状态模型。用于评估升级活动规范的相关状态是si指派状态，其能够是被完全指派、部分指派或未被指派。当表示的si处于未被指派的指派状态中时，服务被认为是被中断的。在本公开中，saf系统指其服务可用性由safamf规范的实现所管理的系统。

smf已被引入以便在saf系统中管理软件。smf包括两个部分：（1）软件输送，其描述软件束（softwarebundle）如何被输送到saf系统。每个软件束伴有实体类型文件（etf），其充当描述该束输送的组件类型和其它实体类型以及它们能够提供的服务类型的清单。etf文件通常由软件供应商提供，并且包含有关给定类型的组件将如何被部署的数据。（2）软件部署，其描述升级活动将如何被指定以及它如何被执行以部署配置改变集。在saf系统中，这些改变由smf引擎基于升级活动规范文件的内容来执行。改变被分布在部分有序过程集上。每个过程部分指定一种升级方法（例如，滚动升级或单步升级）和升级范围（其由表示过程将作用于其上的系统中的实体的配置对象的集组成）。当smf引擎被给予此类文件时，它执行升级活动，和指定的升级过程（在指定的升级过程被应用到系统的当前状态时）。更具体地说，每个过程根据其升级方法和根据其范围到saf系统的配置的映射，被划分成升级步骤。与升级步骤、升级过程和升级活动关联的行为能够使用fsm来描述。这些升级步骤、升级过程和升级活动在smf信息模型中被表示为升级对象。为实现改变，smf引擎执行升级动作，诸如软件安装/移除、与amf的交互和配置修改。作为执行升级动作的一部分，smf可根据在考虑的升级步骤的升级范围，命令amf锁定和重新启动组件集、su集或甚至节点集。这些动作是由给定升级活动诱发的服务停运的主要原因。

本公开也涉及devs，其是在1976由bernardp.zeigler提出的形式体系。它通常用于离散事件系统建模和分析。devs模型能够是原子的，以捕捉组件的行为，或者被耦合以捕捉系统的结构和构成它的组件。devs中的系统能够通过输入和输出事件与其环境交互，导致从一种状态到另一状态的转变。在根据系统的定义，在某种状态中花费的时间已消逝时，devs模型可也生成输出或状态改变，而无与其环境的任何交互。已为devs建立几个模拟器，包括devsjava，其是由亚利桑那州立大学引领的项目，devs-suite项目的一部分。

图1图示了根据一个实施例的升级活动规范的模拟和评估框架。模拟采用以下输入：

（1）升级活动规范文件：它描述要执行的活动。活动的此描述一方面允许该模拟框架适当地分解过程，并且另一方面基于其指定的属性，为每个例示的升级对象运行适当的行为。

（2）系统配置：要升级的saf系统的当前系统配置提供正确地例示和模拟配置对象所要求的信息以及这些对象如何彼此相关。这些关系能够是如在amf规范中所定义的服务之间的依赖性或组件之间的生命周期依赖性。

（3）升级上下文：它包括描述针对配置中的组件类型的操作的持续时间的上限和下限的etf文件集。模拟也需要一些另外的信息，诸如组件类型的失败率及它们的生命周期操作、软件操作（安装/移除）的失败率及节点启动和关闭操作的持续时间。

根据上面所提及的使用模型变换的输入，为包含对升级活动运行时间环境的描述的耦合的devs模型创建java类。此java类被封装成jar（ucs.jar）并且被加载到模拟框架中。在一个实施例中，模拟环境至少由以下项构成：

修改的devs-suite：devs-suite模拟器的扩展版本。在下一子章节中描述对devs形式体系和suite模拟器的扩展。

java升级库：此库定义用于模拟配置和升级在活动执行中牵涉到的对象的devs原子模型的结构和行为。变换仅例示在库中定义的概念，并且将它们组合成devs耦合模型（ucs.java）。驱动模拟的实际行为在此库中定义的每个概念的级别被实现，并且它实现saf标准中所提供的描述。

高级分析包：定义了对于完全有序执行（即，顺序执行）和部分有序执行（即，并行执行）的最佳情况和最差情况情形。

通过使用该模拟，能够具有对活动的以下方面的见解：

（1）活动的执行时间及其每个过程，这能够通过填补一些缺失属性来帮助完成/修订升级活动规范，以及从其执行时间的角度来比较升级活动规范。

（2）在活动的执行期间的si指派状态，这能够帮助完成/修订升级过程的规范，并且也从它们诱发的服务停运的角度来比较升级活动规范。

（3）情形的概率，这能够用于获得最佳和最差情况情形的概率。

devs形式体系被扩展以用于评估升级活动。现有技术devs形式体系只能够建模编作式执行的合作（choreographicallyperformedcollaborations），意味着合作的逻辑被分布在合作实体之中。在本文中的实施例中，一些合作是被编排的，意味着存在对合作实体集之间的合作进行编排的中心实体。例如，在任何时间点的amf可具有不同服务以转换到带有用于下一事件的不同时间偏移的不同实体。为使这些事件的编排更容易，为表示amf的原子devs模型提供了状态独立的时间感知。更具体地说，devs时间功能通过一种不但状态具有寿命期限，而且事件也具有寿命期限的方式来被扩展。在此情况下，如果devs模型接收到进入事件，其当前状态的寿命期限已截止，或者如果其事件之一的寿命期限已截止，则devs模型是即将发生的（或者为转变准备就绪的）。在转变是由事件的寿命期限的截止所导致时，devs模型的唯一反应是将该事件输出到其目的地，并且返回等待下一转变触发。

模拟引擎也被扩展以用于评估升级活动。上面提及的对形式体系的扩展在devs-suite模拟器中被实现。一方面，已经提供的api被扩展以创建输出事件，其包括作为变元的事件寿命期限。考虑到向后兼容性约束，用于事件寿命期限的默认值被定义为零（即，事件在其创建后立即被发出）。另一方面，模拟机构（模拟器和协调器）被扩展以在下一迭代时间的计算中包括事件寿命期限。注意，devs在外部转变（由事件的接收触发的转变）与内部转变（由当前状态寿命期限的截止触发的转变）之间进行区分。本文中描述的实施例扩展外部转变概念，以便它也包括事件寿命期限的截止。

为执行准确的模拟，将对于模拟所需的属性（诸如失败率和执行时间）添加为升级上下文的一部分。图2图示了根据一个实施例，采用描述用于软件束的软件操作的失败模型以及所述软件操作的默认执行时间的属性来扩展的magicetfswbundle元类的示例。类似地，图3图示了根据一个实施例，对magicetfcomptype元类的扩展的示例以表述组件类型的失败模型及其生命周期操作。注意，模型中的时间属性是有界时间，意味着它们提供用于给定操作的执行的下限和上限。这些下限和上限可用于模拟最佳情况和最差情况执行情形。在一个实施例中，上限可用配置的超时值来替换。

参考回图1，模型变换从给定配置、升级上下文和升级活动规范文件生成devs耦合模型。此devs耦合模型由通过将在输入文件中提供的配置和升级对象映射到在java升级库中定义的devs原子模型而推断的devs原子模型组成。此映射基于在给定系统的升级活动的执行中牵涉到的不同对象之间的通信模式被建立，并且在图4中被概述，图4图示了根据一个实施例，在模拟中牵涉到的对象及其关联的devs模型。

升级活动对象例如需要与管理员及其过程通信，这解释与其devs模型关联的输入/输出（i/o）端口。类似地，升级过程与活动和关联步骤通信。升级步骤与过程和与amf交换事件，以对amf配置中的逻辑的实体执行动作。因此，存在对表示amf的原子devs模型的需要。它采用来自最终devs模型中的每个升级步骤和每个配置对象的输入事件和到最终devs模型中的每个升级步骤和每个配置对象的输出事件来被设计。表示amf的原子devs模型的主要责任是解释和分解通过升级步骤对配置对象执行的动作。具体地说，由升级步骤发出的管理操作被分解成关联的受时间约束的amf组件管理操作，并且对于其而言时间约束在系统配置中被给出。

在一个实施例中，变换可以epsilon生成语言（egl）被编写，该语言是用于模型到文本转换的模型变换语言。

升级活动的模拟能够提供对升级活动规范能够如何应用到给定配置的一定见解。然而，在涉及升级活动规范的比较时，模拟结果可仍保持是不确定的。实际上，失败和执行时间的分布可诱发相当大的随机性到模拟的行为中，并且使模拟结果变得随意，因而对于比较的目的是不可靠的。如果模拟情形被随机采用，则一个升级活动规范可比另一规范生成更佳结果，但不清楚这是否是因为设计中的差异还是因为随机情形只显露对于一个升级活动规范比对于另一升级活动规范更有优势的执行路径。本文中描述的系统和方法比较在类似的情形中在类似环境下的升级活动规范。考虑了两个具体情况：最佳情况和最差情况情形。

通过考虑与活动模拟和执行有关的三个方面，定义最佳情况和最差情况情形：

软件操作：软件操作的执行可成功或失败，并且不会始终耗费相同持续时间。前面描述的升级上下文通过将失败率和指定下限和上限的有界持续时间属性与每个软件操作关联来捕捉此事实。然而，升级活动规范可通过默认超时来约束这些操作，如果计时器截止，则默认超时在smf参与适当的升级修复机制时替换上限值。

amf配置对象行为：如前面所述，牵涉到配置对象的升级动作被分解成amf组件管理操作，其以不同方式应用到不同组件类别。由于每个可适用的管理操作可成功或失败，并且可采用不同量的时间，因此，升级上下文包括对于每个组件类型用于这些管理操作中的每个的失败率和有界时间属性。另外，给定的amf配置也通过超时来约束所有这些操作，意味着如果某个操作耗费比配置的超时更多的时间，则amf假定该操作已失败，并且参与恢复和修复动作，其映射到在组件级或在节点级的amf管理操作中。在失败的情况中，amf还可在报告失败前重新尝试一些操作达配置的次数。所有这些方面用于定义在给定组件上操作的最佳执行和最差执行。

升级修复机制：当升级动作在某个升级步骤内失败时，smf尝试撤消在该步骤内执行的动作直至失败的动作，并且如果此撤消成功，则smf重新尝试升级步骤。允许的重试的次数在升级活动规范中被指定。相应地，重试时间取决于失败发生所在的升级动作和允许的重试次数。如果重试次数达到，则smf将升级活动宣布为失败，并且通过回滚升级活动或者从系统备份来恢复系统的原始状态。

如早先所提及的，smf规范留下了要对于smf引擎实现器（smfengineimplementer）做出的一些决定。这些决定中的一个是smf引擎是否能进行升级过程的并行执行。升级活动的升级过程只是部分有序的，并且相应地，实现可并行执行无序集，或者将它们串行化成完全有序执行。由于此能力取决于在给定saf系统中使用的给定smf引擎实现，因此，此方面被认为是用于升级活动规范的评估的上下文参数。不过，此方面影响最佳和最差情况情形的定义。

在完全有序执行中，smf引擎一次只执行一个升级步骤，而不考虑这些步骤到升级过程中的安排。每个升级步骤包含升级动作的序列，一些升级动作由smf本身执行，即，软件操作，而其它升级动作被向amf发出，并且因此根据可适用的amf配置对象行为被分解成amf管理操作的序列。因此，执行时间是在升级活动中进行的每个操作所需要的时间之和。从停运角度来说，每个升级动作可造成一定的停运，但完全有序执行意味着升级动作不能相互干扰和造成相比各个动作的更大的停运，因为每个动作被一次一个地启动和完成。

因此，用于完全有序执行的最佳情况情形被定义为：

时间方面：执行时间是用于在活动执行中发生的每个操作的最佳执行时间的累积和，其中操作的最佳执行时间意味着：操作在第一次尝试成功（无失败和无重试）；并且操作耗费需要的最小时间，其等于为升级上下文（即，适当的etf文件）中的操作而指定的下限值。

停运方面：由于在升级动作之间无干扰，因此，无需做进一步考虑。停运信息是在活动期间的任何时间达到未被指派的服务指派状态的si的集合及它们停留在此状态中的每si累积时间。例如，假设对于si1、si2和si3的停运分别是outage（si1）、outage（si2）和outage（si3），其中每个outage（sii）（i=1、2或3）是sii停留在未被指派的服务指派状态中的累积时间。对于这三个si的集合的停运可被表述为三个值的向量（outage（si1），outage（si2），outage（si3））。备选的是，对于这三个si的集合的停运时间可被表述为如下所述的加权和。

在一个实施例中，si根据其重要性在符合saf的系统中被评级。一般情况下，丢弃（即，不提供）更低评级si比更高评级si是更可接受的。因此，每个等级可与权重关联，使得更高评级si比更低评级si具有更大权重。此权重能够用于调整停运时间，即将si的停运时间乘以与其等级关联的权重。在三个si的上述示例中，在每个情形执行下的停运能够被计算为加权累积停运时间之和。例如，假设si1被指派到等级1（即，最重要），si2被指派到等级2，并且si3被指派到等级3（最不重要），并且到等级1、等级2和等级3的权重分别是w1=1.5，w2=1和w3=0.5。因此，用于三个si的集合的加权累积停运是wco=1.5xoutage（si1）+outage（si2）+0.5xoutage（si3）。

在最差情况情形中，操作可失败并且能够被重试。因此，最差情况情形将smf升级修复机制及amf恢复和修复动作考虑在内。这些被考虑，同时升级活动的执行仍是成功的。相应地，从升级修复机制，只考虑升级步骤重试选项。关于amf恢复和修复动作，它们映射到amf管理操作，并且能够在操作级被处理。因此，对于完全有序执行的最差情况情形被定义为：

时间方面：执行时间是在每个升级步骤的执行的最差但成功情况下的执行时间的累积和，这意味着升级步骤在允许的重试的最后尝试时成功，同时对升级动作的第一次尝试全部失败。每个失败的尝试触发amf恢复和修复动作，这也仅在其允许的重试的最后尝试时成功，即，第一次尝试失败，并且amf恢复和修复动作被应用，其产生另外的amf管理操作。对于由于此类最差情况执行但升级活动成功而发生的每个操作，最差执行时间被定义为：如果它是amf管理操作，则是amf配置中的可适用的超时，或者如果它是软件操作，则是在用于软件束的升级活动规范中指定的超时。

停运方面：针对最差情况情形的考虑与针对最佳情况情形的考虑相同。

部分有序执行指在其中升级过程的子集不是有序的执行。由于在它们之间没有由升级活动规范施加的同步，因此，smf引擎能够以包括并行的任何顺序执行这些子集。一些升级过程的并行执行缩短了升级活动需要的执行时间。然而，在升级过程之间同步的缺乏也意味着它们可相互干扰。这些升级过程可使相同sg的多个su停止服务，超出在停运方面在给定配置中所能够容忍的范畴。它取决于smf引擎实现，其是否能够避免此类干扰。

相应地，对于部分有序执行，最佳情况情形被定义为诱发最小停运的部分有序升级过程的升级步骤的安排。随后，针对此情况计算最佳执行时间。在最佳情况情形的执行时间的计算中，以与用于完全有序执行相同的方式定义每个操作的最佳执行时间。升级活动的总执行时间被计算为无序升级过程的每个子集的最大升级过程执行时间的累积和，即假设这些过程被同时执行。对于模拟，升级步骤的安排由图1中的高级分析包以尽可能避免干扰的方式强制进行。

部分有序执行的最差情况情形考虑在无序过程的干扰最大时，即在它们诱发服务的最大停运时无序过程（即，其被同时执行）的升级步骤的安排（同样地，由高级分析包强制进行）。这与针对完全有序执行的最差情况情形的相同时间考虑相组合：即，操作在它们的最后尝试时成功，它们占用与它们的配置的超时一样多的时间并且失败的尝试触发可适用的恢复和修复动作。同样地，对于针对最差情况的总执行时间，对于并行执行的升级过程的每个子集，耗费最大最差执行时间。

给定能够使系统从其当前配置转到相同目标配置的升级活动规范的集合，上面提及的模拟框架用于通过考虑某一目标可接受停运和维护窗口，来评估上述升级活动规范以决定哪些是更适用或更不适用的。

上面讨论的情形的适用性取决于在其当前配置在评估中被考虑的系统中部署的smf引擎的能力。所有smf引擎能在顺序执行模式中执行完全有序升级活动规范，但一些smf引擎可不能进行升级活动规范的部分有序过程的并行执行模式。

从满足可接受的停运和维护窗口的目标是否能够被实现的角度来评估升级活动。

图5图示了根据一个实施例，用于评估升级活动规范的方法500。

在步骤510，针对适用于目标系统的smf引擎的执行模式，来对所有升级活动规范进行评估，并且对最佳和最差情况情形二者进行针对其执行时间和诱发的停运的评估。

在步骤520，如果smf引擎的执行模式是顺序式，则诱发对于最佳或最差情况情形的不可接受停运的所有升级活动规范能够被安全地消除，因为不存在它们能够满足停运约束的保证。

在步骤530，在并行执行模式的情况下，对违反停运约束的升级活动规范进一步进行针对顺序执行的评估，因为它一般诱发更少的停运。在步骤540，消除仍产生对于最佳或最差情况的不可接受停运的那些升级活动规范。此集的剩余升级活动规范被标记用于潜在串行化。

在步骤550，相对于维护窗口，评估所有剩余升级活动规范的执行时间。升级活动要在可用维护窗口的一半内完成，以便如果在活动执行期间任何事情意外出错，允许系统从容回滚到其原始配置。相应地，产生大于目标维护窗口的一半的执行时间的所有升级活动被拒绝。如果来自备份的系统的部分或完全复原是可接受的恢复，则此准则可被放宽，并且因此能够用于缩短回滚时间。

在步骤560，在步骤550的操作后留下的升级活动规范是可接受的，虽然一些带有对于串行化的需要。能够从它们所诱发的停运和执行时间的角度来对它们进行比较和进一步分析，以挑选最适合用于给定系统和约束的那一个。一个人可以选择耗费最少时间的活动以便更好地利用其维护窗口，而另一个人可以选择耗费更长时间的活动，因为例如它指定更多升级步骤重试并且因此更可靠。选择也能够基于与最佳情况和最差情况情形关联的概率，并且具有用于最佳情况情形的更高概率的活动可被选择。用于服务停运的执行时间的权衡且反之亦然也可是在选择中的因素。可根据被中断的服务的重要性、与中断关联的惩罚，以及还有升级的紧迫性来考虑权衡。因此，这些考虑取决于要升级的系统及其服务。

出于若干原因，升级活动规范的评估是有用的。除了不同升级活动规范的比较外，评估也有助于满足可用性要求。

基于随机模拟的评估由于模拟的行为的随机性而缺乏准确性和系统性方案。因此，存在对于一些打破僵局的情形的需要。最佳情况情形是有效的选择。它对于消除升级活动规范是有用的，易于模拟并且比其它情形耗费更少时间，但在相当多的情况中仍是不确定的。最差情况分析的使用是更有效的，并且给予对在执行时间和服务停运级别二者的活动的适用性的有用见解，以及进一步优化升级活动规范的任何机会。

图6图示了根据另一实施例，用于评估升级活动规范的方法600。方法600通过步骤610开始，在该步骤，系统在用于第i个升级活动规范（s[i]）的最佳情况情形下执行模拟，其中索引i被初始化为一。模拟生成包括停运（outb[i]）和执行时间（tb[i]）的模拟结果。如前面所描述的，停运可被表述为n个元素的向量，其中向量的每个元素（outb[i][j]）是用于si[j]的每si累积停运时间，并且n是在系统配置中si的数量。备选的是，停运可被表述为wco。在步骤615，比较停运和停运阈值。在一个实施例中，停运阈值是可接受的停运（accout），如果outb[i]被表述为向量，则accout可以是n个值的向量。accout中n个值的每个（即，accout[j]）是每si的可接受停运。在此情况下，比较outb[i]的每个值和在accout向量中的对应值。为了outb[i]是可接受的，outb[i]的每个值不能大于对应accout值，即outb[i][j]≤accout[j]，其中j=1…n。备选的是，如果outb[i]是wco，则accout可以是单个值，并且在此情况下，在outb[i]与accout之间的比较是在两个值之间的比较。

如果停运outb[i]不大于accout，则方法600继续到步骤620，在该步骤系统在用于s[i]的最差情况情形下执行另一模拟，并且生成包括停运（outw[i]）和执行时间（tw[i]）的另一模拟结果。如果在步骤625，停运outw[i]不大于accout，则方法600继续到步骤635，在该步骤，比较tw[i]和时间阈值。在一个实施例中，时间阈值是维护窗口的一半（maintwin/2）。如果tw[i]小于maintwin/2，则在步骤636，s[i]被标记为被接受；否则，在步骤637，s[i]被标记为被拒绝。随后，方法600带有递增的i（例如，i=i+1）返回到步骤610，直至所有升级活动规范已被评估为止。

如果在步骤615或步骤625，outb[i]或outw[i]大于停运阈值accout，则方法600继续到步骤645以确定系统的执行模式是否是并行式。如果执行模式不是并行式，则在步骤646，s[i]被标记为被拒绝。如果执行模式是并行式，则在步骤650，系统将执行模式设置为顺序式，并且在步骤660在最差情况情形下执行模拟。模拟生成包括停运（outw[i]）和顺序执行时间（tseqw[i]）的模拟结果。在步骤665，比较此停运outw[i]和accout。如果outw[i]不大于accout，并且在步骤675，在步骤620生成的执行时间tw[i]小于maintwin/2，则在步骤676，s[i]被标记为通过串行化“能够被优化”。如果在步骤665，outw[i]大于accout，或者在步骤675，tw[i]不小于maintwin/2，则在步骤646，s[i]被标记为被拒绝。随后，方法600带有递增的i返回到步骤610，直至所有升级活动规范已被评估为止。

图7是图示了根据一个实施例的过程700的图。在一个实施例中，过程700可作为流程图而作为在图8中示出的方法800被执行，以用于从将系统从当前配置升级到目标配置的升级活动规范的给定集选择一个或多个升级活动规范。图7中带有尖角的每个框表示执行操作的模块，并且带有圆角的每个框表示来自模块的输入或输出。

参照图7和图8，识别模块710接收输入，该输入包括升级活动规范的给定集{ucsi}702，i=1、…、n。对于每个升级活动规范（ucsi），执行步骤810和步骤820。在步骤810，识别模块710识别在升级活动规范中为升级系统指定的软件和管理操作715。在步骤820，对于按照操作执行时间选择704和执行模式706定义的一个或多个情形的集（{sj}701，j=1、…，mi）中的每个情形，模拟模块720根据软件和管理操作715的对应安排，模拟系统的升级。在一个实施例中，选择用于操作的执行时间可包括选择以下的一项或多项：用于执行操作的下限时间值或超时值、操作成功所在的重试尝试（例如，第一尝试、最后可允许尝试等）及诸如此类。模拟生成用于升级活动规范ucsi和在{sj}，j=1、…、mi中每个情形sj的对应的执行时间和对应的停运725。在一个实施例中，模拟模块720模拟的情形的数量（mi）可对于不同升级活动规范是不同的。在步骤830，拒绝模块730拒绝升级活动规范735的子集，对于该子集，对应的执行时间不满足执行时间阈值707，或者对于该子集，对应的停运不满足停运阈值708。升级活动规范735的被拒绝子集是过程700的输出。

在一个实施例中，在不同情形下的执行时间和停运可受到操作执行时间属性、失败率、在失败的情况下是否重试及为在系统的升级中牵涉到的软件操作和组件执行多少次重试的不同组合的影响。在一个实施例中，情形的集701包括最佳情况情形，其中根据给定升级活动规范执行的每个操作在第一次尝试成功，并且在等于为操作指定的下限时间值的时间期内执行。在顺序执行模式中在最佳情况情形下的给定升级活动规范在情形的集之中具有最小停运。在并行执行模式中在最佳情况情形下的给定升级活动规范在情形的集之中具有最小执行时间。

在一个实施例中，情形的集701包括最差情况情形，其中根据给定升级活动规范执行的每个操作失败，直至可允许重试的最后尝试为止，并且在等于为操作指定的超时值的时间期内执行。在顺序执行模式中在最差情况情形下的给定升级活动规范在情形的集之中具有最差执行时间。在并行执行模式中在最差情况情形下的给定升级活动规范在情形的集之中具有最大停运。

图9是图示了根据一实施例的网络节点900的框图。在一个实施例中，网络节点900可以是在运营商网络中或者在数据中心中的服务器。网络节点900包括电路系统，其包括处理电路系统902、存储器或指令存储库904及接口电路系统906。接口电路系统906能够包括至少一个输入端口和至少一个输出端口。存储器904包含由处理电路系统902可执行的指令，由此网络节点900可操作以执行如本文中描述的各种实施例，分别包括图5、6和8的方法500、600和800。

图10是包括多个模块的示例网络节点1000的框图。在一个实施例中，网络节点1000可以是在运营商网络中或者在数据中心中的服务器。也参照图7，网络节点1000包括识别模块710，其适于或操作以为每个升级活动规范识别在升级活动规范中为升级系统指定的软件和管理操作。网络节点1000也包括模拟模块720，其适于或操作以为每个升级活动规范和为按照操作执行时间选择和执行模式定义的一个或多个情形的集中的每个情形，来根据软件和管理操作的对应安排，模拟系统的升级，从而获得对应的执行时间和对应的停运。网络节点1000也包括拒绝模块730，其适于或操作以拒绝升级活动规范的子集，对于该子集，对应的执行时间不满足执行时间阈值，或者对于该子集，对应的停运不满足停运阈值。网络节点1000能够配置成执行如本文中已被描述的各种实施例。

图11是包括云计算实体的分层结构的云计算环境1100的架构概览。云计算环境1100能够包括在通过网络1135连接的不同地理站点的多个不同数据中心（dc）1130。每个数据中心1130站点包括多个机架1120，每个机架1120包括多个服务器1110。要理解的是，在备选实施例中，云计算环境可包括任何数量的数据中心、机架和服务器。服务器110集可被选择以托管资源1140。在一个实施例中，服务器1110提供用于托管实体及它们的被托管实体的执行环境，其中托管实体可以是服务提供商，并且被托管实体可以是由服务提供商提供的服务。除其它之外，托管实体的示例包括虚拟机（其可托管容器）和容器（其可托管包含的组件）。容器是能够在其自己内包含其它组件的软件组件。多个容器能够共享相同操作系统（os）实例，并且每个容器提供用于其包含的组件的隔离的执行环境。与虚拟机（vm）相反，容器及它们的包含的组件共享相同主机os实例，并且因此形成更少的开销。

根据一个实施例，在图11的虚线圆1115内示出了服务器1110及其资源1140的进一步细节。云计算环境1100包括通用网络装置（例如，服务器1110），其包括如下硬件，所述硬件包含一个或多个处理器1160(其能够是商用现货（cots）处理器、专用的专用集成电路（asic）或包括数字或模拟硬件组件或专用处理器的任何其它类型处理电路)的集、和网络接口控制器1170（nic）(也被称为网络接口卡)、及在其中存储有由处理器1160可执行的软件和/或指令的非暂态机器可读存储介质1190。

在操作期间，处理器1160执行软件以例示管理程序1150和由管理程序1150运行的一个或多个vm1141、1142。管理程序1150和vm1141、1142是虚拟资源，其在此实施例中可运行节点实例。在一个实施例中，节点实例可在管理程序1150上运行的vm1141、1142中的一个或多个上被实现，以执行如本文中已描述的各种实施例。在一个实施例中，节点实例可被例示为执行如本文中描述的各种实施例的网络节点。

在一实施例中，节点实例例示能够由用户1300或者由机器以不同方式发起。例如，用户1300能够例如通过点击按钮，通过用户接口输入命令以发起节点实例的例示。用户1300能够备选地在命令行上或者在另一类似的接口上键入命令。用户1300能够以其它方式通过用户接口或者通过到网络或云管理员的电子邮件、消息传递或电话来提供指令，以发起节点实例的例示。

实施例可被表示为在机器可读介质（诸如非暂态机器可读存储介质1190，也指在其中体现有计算机可读程序代码的计算机可读介质、处理器可读介质或计算机可使用介质）中存储的软件产品。非暂态机器可读介质1190可以是任何适合的有形介质，包括磁性、光学或电存储介质，其包括软盘、紧致盘只读存储器（cd-rom）、诸如硬盘或固态驱动器的数字多功能盘只读存储器（dvd-rom）存储器装置（易失性或非易失性）或类似存储机构。机器可读介质可包含各种指令集、代码序列、配置信息或其它数据，它们在被执行时，促使处理器执行根据一实施例的方法中的步骤。本领域技术人员将领会，用来实现描述的实施例所必需的其它指令和操作也可被存储在机器可读介质上。从机器可读介质运行的软件可与电路系统进行接口以执行描述的任务。