CN112753017A - 云升级的管理的自动化 - Google Patents

云升级的管理的自动化 Download PDF

Info

Publication number
CN112753017A
CN112753017A CN201980065043.9A CN201980065043A CN112753017A CN 112753017 A CN112753017 A CN 112753017A CN 201980065043 A CN201980065043 A CN 201980065043A CN 112753017 A CN112753017 A CN 112753017A
Authority
CN
China
Prior art keywords
upgrade
resources
resource
dependencies
iteration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201980065043.9A
Other languages
English (en)
Inventor
M·纳比
M·陶乐
F·肯德克
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of CN112753017A publication Critical patent/CN112753017A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Stored Programmes (AREA)

Abstract

基础设施即服务（IaaS）系统中的资源是在迭代过程中升级的。响应于指示对系统的当前配置的所请求改变的升级请求，创建当前配置和所请求改变的一个或多个图表示。图表示包括控制图，该控制图具有表示资源组的顶点和表示资源组之间的依赖关系的边。基于依赖关系和包括系统的可用性和弹性的服务级协定（SLA）要求，将一批资源组标识为在当前迭代中升级。使用选择的升级方法对所标识批执行升级操作，该升级方法处置系统配置的转变期间的潜在不兼容性。响应于失败的升级操作的反馈，更新图表示以包括任何新请求的改变和恢复操作。迭代过程继续进行以升级剩余的一个或多个资源组。

Description

云升级的管理的自动化
相关申请的交叉引用
本申请要求2018年8月6日提交的序号为62/714917的美国临时申请的权益。
技术领域
本发明的实施例涉及云环境中资源升级的管理。
背景技术
在基础设施即服务（IaaS）云服务模型中，有三种类型的资源：物理资源、虚拟化设施（也称为虚拟化资源）和虚拟资源（也称为虚拟化资源）。物理资源是在其上运行该层其余部分的基础设施的硬件。虚拟资源是通过使用虚拟化设施在物理资源顶上构建的作为服务提供的资源。
在它们的生命周期期间，这些资源被多次升级。在这些升级期间，由IaaS层交付的服务可能受影响。一些系统具有对服务中断的有限容忍度。这些系统或它们的子系统中的一些具有高可用性（HA）要求，例如，它们的服务应该可用于99.999%的时间；换句话说，不应经历每年多于五分钟和26秒的停机时间，包括由于升级引起的停机时间。的确，云提供商通过服务级协定（SLA）向租户承诺，该SLA指示承诺条款，例如甚至在升级期间的可用性级。
在IaaS升级期间，对于维持可用性有几个挑战。在IaaS层以及其他层中，资源可能取决于其他资源。打破升级期间资源之间的任何依赖关系（dependency）都可能导致升级期间的服务中断。此外，在升级过程中，当前配置或目标配置中不存在的不兼容性可能在转变期间出现，并打破依赖关系。此外，对资源执行的升级动作可能失败，并且这种失败可能危及系统配置的一致性。
云系统的动态性对升级引入了附加的挑战。云系统通过根据工作负载变化自动供应和取消供应资源来适应工作负载改变。这种机制被称为自动缩放或弹性。这种动态性给升级期间维持SLA带来了挑战。事实上，自动缩放特征可能以不同的方式干扰升级过程。当资源由于升级而停止服务（taken out of service）时，在升级期间系统的服务容量降低。同时，系统可能需要响应于工作负载增加而向外缩放。此外，当向内缩放释放新升级的资源（例如，VM）时，或者当向外缩放使用旧的（即，尚未升级的）版本的资源时，自动缩放可能撤销或阻碍升级过程。因此，对于许多常规系统，在升级期间禁用自动缩放特征。
对于在集群系统升级期间维持高可用性提出有不同的升级方法（例如，滚动升级、拆分模式和延迟切换）。然而，这些方法中没有一个解决云环境升级的所有挑战。例如，Windows® Azure Storage使用滚动升级将系统分区为子系统，并一次升级它们一个。然而，在冗余资源的不同版本之间的不兼容性的情况下，滚动升级方法可能引入混合版本不一致。其他解决方案提出了并行全域方法来解决不兼容性问题（即，混合版本不一致）。在这种情况下，利用新配置创建了全新的系统，而旧系统继续服务。然而，应用这种并行全域方法可能非常昂贵，因为全新的IaaS云系统是用新版本资源创建的。
由于云部署的大小和出于支持零接触操作的目的，存在对自动化IaaS系统的整个升级过程的需要。这种自动化可以包括选择适当的升级方法和恰当地编排升级过程，以避免或至少限制升级期间的服务中断。
发明内容
在一个实施例中，提供了一种用于在迭代过程中升级提供IaaS的系统中的资源的方法。该方法包括：接收升级请求，该升级请求指示对系统的当前配置的所请求改变；以及响应于升级请求，创建当前配置和所请求改变的一个或多个图表示。一个或多个图表示包括控制图，该控制图具有各自表示一个或多个资源的资源组的顶点和表示资源组之间的依赖关系的边。该方法进一步包括：基于依赖关系和包括系统的可用性和弹性的SLA要求，从资源组中标识要在当前迭代中升级的一批一个或多个资源组；以及使用选择的一种或多种升级方法对所标识批执行升级操作，所述升级方法处置系统的当前配置和升级的配置之间的转变期间的潜在不兼容性。所述方法进一步包括：响应于失败的升级操作的反馈，更新所述一个或多个图表示以包括任何新请求的改变和恢复操作，标识要在下一迭代中升级的下一批一个或多个资源组，以及升级剩余的一个或多个资源组。
在另一个实施例中，提供了一种包括处理电路和存储器的网络节点。存储器存储由处理电路可执行的指令。网络节点可操作以执行用于在迭代过程中升级提供IaaS的系统中的资源的上述方法。
在结合附图审查对特定实施例的以下描述时，对于本领域技术人员而言其他方面和特征将变得显而易见。
附图说明
现在将参考附图仅通过示例来描述实施例。
图1图示了根据一个实施例的用于IaaS云系统升级的升级管理框架。
图2示出了根据一个实施例的IaaS系统的说明性示例。
图3示出了根据一个实施例的在接收到升级请求之后反映图2的说明性示例的系统的示例资源图。
图4图示了根据一个实施例的升级方法的迭代过程的总体视图。
图5是图示根据一个实施例的图4的迭代过程的主要步骤的流程图。
图6A、6B、6C和6D图示了对具有拆分模式的升级单元的资源分区的示例。
图7A、7B、7C和7D图示了对具有修改拆分模式的升级单元的资源分区的示例。
图8示出了根据一个实施例的针对图2的说明性示例的与图3的资源图对应的控制图。
图9A、9B、9C和9D图示了根据一个实施例的图5的迭代过程的细节。
图10是图示根据一个实施例的用于在迭代过程中升级提供IaaS的系统中的资源的方法的流程图。
图11是图示根据一个实施例的用于选择升级方法以处置迭代升级过程期间的IaaS资源的潜在不兼容性的方法的流程图。
图12是根据一个实施例的网络节点的框图。
图13是根据一个实施例的云计算环境的架构概述。
具体实施方式
在以下描述中，阐述了许多特定细节。然而，要理解，没有这些特定细节也可以实践本发明的实施例。在其他实例中，众所周知的电路、结构和技术尚未详细示出，以免使对本描述的理解模糊不清。然而，本领域技术人员将领会，本发明可以在没有这种具体细节的情况下实践。本领域技术人员利用所包含的描述将能够在没有过度实验的情况下实现适当的功能性。
提供了一种方法，用于根据由管理员指定的升级请求，并且在可用性和弹性的SLA约束下，自动化IaaS云系统的升级。所公开的方法适用于升级所有种类的IaaS资源（例如，计算资源、网络资源和存储资源）。还提供了一种用于执行所公开的方法的系统。
所公开的方法在迭代过程中确定和调度适合于升级请求的升级方法和动作。为了防止由于现有依赖关系引起的服务中断，在运行时，该方法根据系统的配置来标识能被升级而不违反依赖关系兼容性要求的资源。沿着依赖关系的潜在不兼容性使用来自云供应商的信息确定，并根据依赖关系的类型使用适当的升级方法处置。此外，通过标识升级过程需要附加资源的子系统，最小化附加资源量。这种方法通过根据IaaS云系统相对于SLA的状态来调节升级速度，来避免升级和自动缩放过程之间的干扰。因而，当且仅当资源能停止服务并升级而不危及IaaS服务的可用性时，升级才开始/重新开始。为了维持系统配置的一致性，在升级期间失败的情况下，必要的重试和撤销操作被标识并自动发出，如适用于失败的升级动作。这种方法还能够处置新升级请求，甚至在正在进行的升级期间，这使得它适合于连续交付。
本发明的实施例基于资源之间的依赖关系和那些依赖关系的兼容性信息，自动化IaaS资源的升级的管理。相应地对资源进行分组，并为它们选择适当的升级方法。所公开的方法考虑了可用性和弹性约束，即，确保VM根据它们的反关联性分组受影响，并允许在有关SLA要求的范围内甚至在正在进行升级期间的向外缩放操作。这些特征之所以成为可能，是因为升级是在迭代中执行的。在每次迭代中，对系统的改变（例如，缩放）、先前迭代中的失败和新升级请求都被考虑进去。从而，该过程适应系统的状态，并且可以根据用于升级的资源的可用性停止和重新启动。所公开的方法也适合于连续操作和部署。所公开的方法适用于具有类似依赖关系的系统，即，它能被应用于云架构的其他层。
在描述所公开方法的进一步细节之前，解释贯穿本公开使用的一些术语是有帮助的。基础设施组件是由供应商作为产品的一部分交付的一段软件、固件或硬件。产品本身可以是单个组件（例如，ESXi管理程序）或由不同组件组成的复合产品（例如，具有不同组件的Ceph存储）。当产品被完全安装在IaaS系统中时，这种安装变成了资源（例如，ESXi管理程序、Ceph存储），并且可能由多个组件的安装组成。从而，多个IaaS资源能被映射到同一基础设施组件（例如，安装在不同主机上的ESXi管理程序），并且多个基础设施组件能被映射到单个IaaS资源（例如，其中组件在不同主机上运行的Ceph存储）。每个基础设施组件都附带文件、基础设施组件描述，其除了别的之外还描述了组件的服务能力、配置约束、硬件管理能力、交付软件/固件捆绑与它们的安装/升级/移除脚本/命令、它们的安装/移除所需的估计时间以及硬件/软件依赖关系。
接下来，解释术语“动作”、“操作”和“单元”。要在IaaS云系统中部署改变，可能需要执行一个或多个升级动作。升级动作被定义为能由配置管理工具（例如，Ansible）在资源上执行的原子动作（例如，在主机上安装ESXi的命令），或者由管理员在资源上执行的原子动作（例如，移除主机）。升级动作与一个或多个撤销动作关联。撤销动作复原升级动作对资源的影响。术语升级操作被用于表示升级动作的有序列表。术语撤销操作被用于表示撤销动作的有序列表；而重试操作被定义为升级操作的重试。恢复操作被定义为撤销和/或重试操作。
升级单元被定义为不得不使用适当的升级方法来升级的一组资源，例如，用于处置升级期间（即从源配置转变到目标配置期间）可能出现的不兼容性。升级单元的资源是基于沿着资源的依赖关系的可能的不兼容性来选择的。升级单元中的资源的升级操作是基于关联的升级方法排序的，这阻止了升级期间不兼容版本之间的通信。撤销单元由不得不全都一起应用升级操作的一组资源组成。否则，撤销操作被触发。这种分组的目的是要保存系统配置相对于IaaS云系统的改变的一致性。
系统管理员通过指定升级请求来发起升级，升级请求是改变集的集合，即，一组改变集。集合中的每个改变集都指定IaaS资源上的一组紧密耦合的改变，它们要么成功，要么一起失败，以维持系统配置的一致性。在每个改变集内，每个改变都指示一些资源的基础设施组件的添加、移除或升级、一些资源本身、或者两个资源或它们的集之间的依赖关系。注意，升级请求中的改变集彼此独立，并且改变集的失败不影响系统相对于其他改变集的一致性。
系统管理员可能不知道所有的依赖关系，并且因此，可能不指定改变集中所有必要的改变，即，改变集可能不完整。为了满足供应商在基础设施组件描述中指示的硬件和/或软件依赖关系，由系统管理员发起的升级请求可能需要补充改变。为了解决这个问题，相对于由（一个或多个）供应商提供的（一个或多个）基础设施组件描述来检查每个改变集的完整性，以导出任何缺失的改变。然后，这些缺失的改变作为补充改变添加到同一改变集。对于每个改变，不得不从基础设施组件描述中导出必要的升级动作。该描述包含用于安装和移除软件组件的脚本，而对于硬件组件，该脚本被用于其管理。
管理员还能在升级请求中指定关于重试和撤销操作的附加参数。为了确保升级过程完成，即限制其时间，针对每个改变集，可以指定最大重试阈值和最大完成期。为了确保系统对于（改变集中的）每个改变的一致性，可以指定撤销阈值参数和撤销版本。这四个参数的使用将在本公开中在后面详细描述。
升级请求模型可以用于跟踪升级请求。该模型包括跟踪将改变应用于系统（包括失败处置）的过程所必要的所有信息。改变集和每个集内的改变的执行状态指示它们是新的、调度的、完成的还是失败的。每当发出新的升级请求时，其改变集（包括它们相应的补充改变）被添加到升级请求模型。对于每个改变集中的每个改变，反映了目标资源、它们的源、目标和撤销版本，并维持了执行状态。从当前配置中标识目标资源以及它们的源版本。
所公开的方法解决了在IaaS云升级期间维持可用性的以下挑战：（1）应用（SaaS）层对IaaS层的依赖关系，（2）资源依赖关系，（3）升级过程期间沿着依赖关系的潜在不兼容性，（4）升级失败，（5）云环境的动态性，以及（6）将附加资源量保持在最小。
首先，描述了应用层对IaaS层的依赖关系的挑战。升级IaaS云系统能影响其它云层——诸如应用层——对IaaS层的依靠。从而，处置层之间现有的依赖关系使得能够防止升级期间的服务中断。IaaS层的可用性管理责任不同于应用层的可用性管理责任。IaaS不负责提供可用性解决方案来保护在VM中部署的应用的可用性。在VM中部署的应用的可用性可以通过可用性管理解决方案（诸如可用性管理框架）来维持。为了处置在IaaS层上运行的应用层的依赖关系，假定将应用级冗余的要求作为VM放置约束（即，作为反关联性组）朝向IaaS云表达。为了遵守这些要求，在升级、VM迁移或VM整合期间，同一组的VM将被放置在不同的物理主机上，并且一次将影响至多指定数量（通常一个）的反关联性组的VM。
本文描述了资源依赖关系的挑战。为了处置资源依赖关系，标识不同种类的IaaS资源以及它们之间的依赖关系。IaaS资源依赖关系落入两个主要类别，赞助和对称依赖关系，具有不同的子类别。在升级期间，为了避免任何资源依赖关系违反，升级不得不以特定顺序执行，这基于依赖关系的性质。而且，为了保持可用性，资源不能全都同时被升级。作为一种解决方案，迭代升级过程可以用于在每次迭代开始时选择能被升级的资源，而不违反该迭代中的任何依赖关系。在继续升级之前，在每个后续迭代开始时重新评估这种情况。对于这种选择，首先不得不同时升级的资源被分组在一起，并且然后能在当前迭代中升级的资源组使用一组规则（称为消除规则）来标识。这导致被称为初始批的初始选择，其中资源组是基于它们的依赖关系选择的。存在将进一步缩窄这个初始选择的其他标准。
本文描述了在升级期间沿着资源依赖关系的潜在不兼容性的挑战。即使源配置和目标配置它们本身没有不兼容性，但是在从一个配置到另一个配置的转变期间，不兼容性可能发生，因为需要维持服务的可用性。也就是说，在升级的时间内，沿着资源中的一些资源的一些依赖关系，可能发生版本不匹配。为了避免这种不兼容性，这些资源必须使用适当的升级方法按一定的顺序升级。所公开的方法自动标识在升级期间沿着它们的依赖关系可能具有不兼容性的资源，并将它们分组到升级单元中。每个升级单元使用适当的升级方法将必须被升级的资源分组在一起，这通过防止不兼容版本的资源之间的任何通信来避免不兼容性。从而，在升级单元内，根据关联的升级方法对资源的升级进行排序，并且用于批选择的消除规则确保根据关联的升级方法选择相同升级单元的资源。例如，拆分模式可以用于避免沿着某些依赖关系的不兼容性。在该方法中，升级单元的资源被分成两个分区，该两个分区以一次一个分区来升级。消除规则确保一次只选择一个分区，并且分区的去激活和激活顺序是这样的，它通过在任何给定时间只有一个版本活动直到两个分区都被升级，来避免任何不兼容性。
由于排序约束，资源上所需的升级动作可能需要在不同的迭代中应用。执行级（execution-level）被定义为在单次迭代中对资源要执行的升级动作的有序列表。此外，要执行动作（actions-to-execute）被定义为要通过不同迭代在资源上执行的执行级的有序列表。从而，执行级除了别的之外还对资源上的升级动作进行排序，以处置不兼容性。资源上的每个执行级都与升级单元关联。在每次迭代中，基于升级单元，取决于关联的升级方法所需的顺序，消除规则可以或可以不从初始批中移除资源。每当资源保留在迭代的最后批中（即，该迭代中要升级的资源批），其第一执行级的升级动作都将在该迭代中执行。在成功执行第一执行级的所有升级动作之后，执行级（与所有其升级动作）从资源的要执行动作的执行级列表中移除。因此，每当为最后批再次选择资源时，下一个执行级变成在后续迭代中要执行的第一个。
例如，升级单元还用于处置由新升级请求引入的潜在不兼容性。即使新的升级请求将与先前的升级请求相同的资源作为目标，但新的升级请求可能引入新的不兼容性。为了防止这种不兼容性发生，创建了不同于现有升级单元的新升级单元。与新升级请求关联的升级动作只能在完成正在进行的升级请求的升级动作之后在资源上执行。为了实现这一点，与新升级单元关联的升级动作被分组到新的执行级。
本文描述了处置升级失败的挑战。在升级失败的情况下，执行恢复操作，以将系统带到一致的配置。由于改变集中的改变是相关的，因此有两个主要标准来保证一致的配置：首先，在资源上部署改变集的所有升级动作要么需要成功应用，要么根本不应该应用它们中的任何一个。第二，改变集中的所有改变都必须在不违反它们的撤销阈值的情况下成功；否则，它们必须全部撤销。
根据第一标准，假如改变集的升级动作在资源上失败，则需要复原该集的已经执行的升级动作的影响。这被称为资源级撤销，其在应用改变集的升级动作之前将资源带到该版本。如果这是成功的并且资源上允许的重试操作（即，最大重试阈值）尚未达到，则可以进行另一尝试以重新执行该集的升级动作。否则，如果复原升级动作成功（即，达到先前的稳定配置），但不允许重试操作，则资源将与系统隔离。被隔离但未失败的资源被称为仅隔离的资源（isolated-only resource）。然而，如果复原升级动作失败，则资源需要被隔离并被标记为失败。如果应用了改变的资源集中仅隔离和失败的资源的数量违反了撤销阈值，则改变集的所有改变都将在所有适用的资源上撤销，以保存系统一致性。这个撤销操作被称为系统级撤销，因为它是在系统级执行的，并且考虑整个改变集。撤销单元（undo unit）被定义为在其上必须一起应用撤销恢复操作的一组资源。因此，撤销单元被指配给每个改变集及其目标资源，以维持适用于那些需要全部部署或撤销的资源的改变的关系。撤销操作可能如以下讨论地被触发：如果违反了集的撤销阈值；如果该集的所有升级动作都不能在指示的最大完成期内完成；或者如果管理员明确地针对尚未完成的改变集发出撤销操作。一旦改变完成，它便不能撤销，而是能请求新的改变。当撤销系统级中关于改变集的改变时，所有目标资源将被带到该改变的撤销版本。注意，由管理员指定的该撤销版本指示改变集的撤销操作所期望的版本，并且在应用改变集的升级动作之前，它可能不同于资源的原始版本。仅隔离的资源可能或者可能不处于撤销版本。这是因为在应用了改变的时刻，具有成功资源级撤销操作的仅隔离的资源被带到该版本（不是撤销版本）。如果仅隔离的资源处于撤销版本，则它们从隔离中释放。否则，进行尝试以将它们带到撤销版本。如果这不成功，则它们被标记为失败的资源。
注意，可能有几个改变集影响单个资源。每个资源可以与几个撤销单元关联。在所公开的方法中，当执行撤销操作时（例如，由于升级失败），撤销操作被局部化到由始发改变集所针对的资源（即，与该改变集关联的撤销单元中的那些），而不是撤销在系统中进行的所有改变。撤销操作本身被表示为有关资源上的改变集，并且从而，它能在其他改变集被应用于系统其他部分时被执行。撤销操作的撤销动作被组织到资源的第一执行级，使得它们将首先被执行。
本文描述了云环境的动态性的挑战。为了处置自动缩放和升级过程之间的干扰，调节了升级过程的速度。为了遵守SLA承诺（缩放和可用性），在每次迭代中，系统的当前配置都被考虑进去，并且只有一定数量的资源能停止服务以便升级。基于当前配置，在每次迭代中，确定容纳当前服务工作负载、任何潜在的向外缩放请求以及从针对该迭代持续时间计算的潜在失败中恢复所需的资源数量。这些在没有潜在违反可用性的情况下不能被升级。因此，从相对于它们的依赖关系选择的初始批资源中，这些资源被消除，并且只有剩余的子集能被升级。这个剩余的子集被称为最后批。当且仅当至少一个资源能被停止时（即，最后批不是空的）并升级，而不由于潜在的资源失败或有效的缩放请求而违反可用性和弹性约束，升级过程才开始/重新开始。否则，升级过程被暂停，直到有足够的资源被释放，例如通过向内缩放的过程。
本文描述了最小化所需附加资源量的挑战。由于升级从系统中取出资源，所以向系统临时提供附加资源对于在升级方面的进行可能变得必要。该量可能取决于升级方法、应用升级的资源数量以及应用它的时刻系统中的备用容量。可能有必要添加资源，以使得能够使用某些技术来维持服务连续性和服务可用性，尤其是在存在不兼容性的情况下。一些现有的升级解决方案使用并行全域方法来避免不兼容性。就资源而言，在系统级应用并行全域方法是昂贵的。想法是要只使用最少的必要附加资源来保持尽可能低的升级成本。所公开的方法标识需要附加资源的子系统，并且仅使用必要的最小量。
为了维持支持VM操作（例如，存储、控制器）的基础设施服务的连续性，当它们的资源需要被升级时，并且当新版本和旧版本不兼容时，本文提出了部分并行全域（PPU）方法。该方法将并行全域方法局部地应用于子系统（例如，存储或控制器子系统），而不是创建完整的IaaS系统作为并行全域。
用PPU方法，所公开的方法用它们的新版本创建支持基础设施资源的VM的新配置，同时（并行）保持这种基础设施资源和它们的配置的旧版本，直到新版本能接管对所有VM的支持。为了实现转移，提供IaaS的VM服务的物理主机（即，计算主机）也被分成两个分区。旧分区托管与支持基础设施资源的旧版本VM兼容的VM，并且它最初托管所有VM。最初为空的新分区托管与支持基础设施资源的新版本VM兼容的VM。支持基础设施资源的新版本VM一准备就绪，VM就潜在地在多次迭代中从旧分区迁移到新分区，如适用于它们的SLA。一旦所有VM都已经从旧分区迁移到新分区，便能安全地移除用旧版本支持基础设施资源的VM的配置。
从而，为了保证VM支持服务的连续性，在升级期间以及一直到VM迁移完成为止，必须同时满足支持基础设施资源的VM的配置的两个版本的要求。如果使用现有资源不能满足这些要求，则可能需要附加资源。所公开的方法通过在升级期间尽可能多地尝试使用可用资源并且仅在它们必要时请求附加资源来将所需附加资源的数量保持在最小。
图1图示了根据一个实施例的用于IaaS云系统升级的升级管理框架100。除了别的之外，框架100将可用性和弹性的SLA约束考虑进去。框架100包括两个主要组件，协调升级过程的升级协调器110，以及执行在系统中部署所请求升级所必需的升级动作的升级引擎120。
升级协调器110跟踪升级请求，并以迭代的方式决定关于升级过程。对于每次迭代，它都生成一个或多个运行时升级调度，其中的每个都是升级动作和在其上需要应用它们的资源集的集合。生成运行时升级调度以克服本公开中先前描述的挑战。升级协调器110使用以下作为输入：系统的当前配置130、（一个或多个）升级请求140中指示的改变集、供应商提供的基础设施组件描述150以及现有租户的SLA 160，作为输入来生成调度。
为了生成每次迭代的升级调度，升级协调器110考虑依赖关系、潜在的不兼容性、和可用性和弹性的SLA约束，以及处置先前迭代的失败所必需的动作。资源级失败在给定迭代内处置，而系统级失败在后续迭代中处置。
为了跟踪升级请求140，升级协调器110创建升级请求模型。该模型包括改变集，改变集包括每个升级请求的补充改变和它们的执行状态。基于基础设施组件描述150，升级协调器110推断满足所有依赖关系所需的任何补充改变，并且它标识部署不同改变集所需的所有升级动作，并生成（一个或多个）运行时升级调度。
升级引擎120，能够在IaaS资源上运行升级动作的引擎，执行从升级协调器110接收到的运行时升级调度中指定的升级动作。注意，在硬件资源的情况下，升级引擎120可以请求对诸如替换一件硬件的动作的管理协助。然而，升级引擎120能将资源带到所需的状态，并发信号通知何时协助是必要的以及在哪件硬件上。
在升级调度执行之后，升级引擎120向升级协调器110提供反馈，指示包括任何失败的升级动作的结果。基于该反馈，升级协调器110可以创建新的运行时升级调度，以处置在资源级的失败升级动作，即，将它们带入到稳定配置。一旦针对迭代处置了所有失败，升级协调器110便创建升级迭代报告，作为（一个或多个）运行时升级调度生成的下一次迭代的附加（用于第一迭代的那些）输入。升级迭代报告指示该迭代的失败和/或仅隔离的资源以及失败的撤销单元。基于这些，在（一个或多个）后续迭代中，升级协调器能发出如在系统级适当的重试或撤销操作，考虑所有有关的依赖关系，包括由升级请求中所请求改变的分组定义的那些依赖关系。
这种迭代方法也支持连续交付。也就是说，在正在进行的升级期间，可以在任何时间请求新的升级请求。升级协调器110考虑这些新的升级请求，将它们添加到升级请求模型，根据需要推断补充改变，并提取对应于改变的升级动作。新请求将在如适用的后续迭代中应用于该系统。该过程继续，直到所有未解决的升级请求都已经被处置。
以下描述提供了IaaS云系统的预备和定义。IaaS数据中心被定义为：提供计算服务的一组物理主机（Mcompute）、提供虚拟存储的一组物理主机（Mstorage）、专用于网络服务的一组物理主机（Mnetwork）和专用于控制器服务的另一组物理主机（Mcontroller）以及用于联网（例如，交换机、路由器）和用于存储（物理存储）的一组其他物理资源。注意，Mcompute和MStorage可能相交。由于失败和/或云弹性，这些组中的任一组的大小都可能在升级期间并随着时间改变。假定Mcompute中的所有物理主机都具有K个VM的容量。
租户数量也可能随着时间而变化，包括在升级期间。由于所公开的方法以迭代方式应用这些改变，因此在迭代i由IaaS云服务的租户的数量由Ni表示。每一个租户都有若干VM，其可能在minn和maxn之间变化。它们分别表示IaaS提供商同意在相应的SLA中提供的第n个租户的VM的最小数量和最大数量。每个租户的SLA还指定了缩放调整sn值和冷却持续时间cn，它们表示IaaS提供商要满足的一个缩放操作中VM方面调整的最大大小，以及两个后续缩放操作之间的最小时间量。这些参数定义了SLA弹性约束。
在一个实施例中，部署在VM中的应用的可用性由可用性管理解决方案管理。应用级冗余的要求作为VM放置约束（即作为反关联性组）朝向IaaS云表达，这些约束在升级期间被遵守。这不仅意味着同一组的VM应该被放置在不同的物理主机上，而且意味着一次能影响至多一组中指定数量（通常一个）的VM。租户的VM可能形成几个反关联性放置组。
表I列出了本公开其余部分中使用的所有参数的定义。
表II.在所公开方法中使用的参数
符号 描述 符号 描述
<i>K，K'</i> VM方面的主机容量（管理程序升级之前和之后） <i>M</i><sub><i>network</i></sub> 专用于联网服务的一组主机
<i>N</i><sub><i>i</i></sub> 迭代i中的租户数量 <i>M</i><sub><i>controller</i></sub> 专用于控制器服务的一组主机
min<sub>n</sub> 租户n的最小VM数量 <i>M</i><sub><i>computeForOldVM</i></sub> 能够托管旧版本VM的一组计算主机
<i>max</i><sub><i>n</i></sub> 租户n的最大VM数量 <i>M</i><sub><i>computeForNewVM</i></sub> 能够托管新版本VM的一组计算主机
<i>c</i><sub><i>n</i></sub> 租户n的冷却时间 <i>M</i><sub><i>usedCompute</i></sub> 一组在使用的计算主机
s<sub>n</sub> 按照租户n的每冷却时间的VM进行缩放调整 <i>M</i><sub><i>usedComputeForOldVM</i></sub> 具有旧版本的VM的一组在使用的计算主机
<i>S</i><sub><i>i</i></sub> 迭代i期间可能发生的每个租户的最大缩放调整请求 <i>M</i><sub><i>usedComputeForNewVM</i></sub> 具有新版本VM的一组在使用的计算主机
<i>T</i><sub><i>i</i></sub> 迭代i的那批的升级时间 <i>ScalingResv</i><sub><i>forOldVM</i></sub> 为旧版本VM的缩放预留的计算主机数量
<i>F</i> 迭代期间要容忍的计算主机失败数量 <i>ScalingResv</i><sub><i>forNewVM</i></sub> 为新版本VM的缩放预留的计算主机数量
<i>A</i><sub><i>i</i></sub> 在迭代i中，可能在与旧VM版本兼容的主机上向外缩放的租户数量 <i>FailoverResev</i><sub><i>forOldVM</i></sub> 为旧版本VM失败转移预留的计算主机数量
Z<sub>i</sub> 迭代i中可以停止服务的最大计算主机数量
Figure DEST_PATH_IMAGE001
 为新版本VM失败转移预留的计算主机数量
V<sub>i</sub> 迭代i中要升级的VM总数 <i>MinHostReqConf</i><sub><i>oldStorage</i></sub> 虚拟存储的旧配置所需的最小存储主机数量
<i>W</i><sub><i>ij</i></sub> VM方面的批大小，其中在主迭代i和子迭代j中，每个VM属于不同的反关联性组 <i>MinHostReqConf</i><sub><i>newStorage</i></sub> 虚拟存储的新配置所需的最小存储主机数量
<i>M</i><sub><i>Storage</i></sub> 有资格参与虚拟存储创建的一组主机（存储主机） <i>MinHostReqCap</i><sub><i>oldStorage</i></sub> 旧版本VM数据所需的最小存储主机数量
<i>M</i><sub><i>compute</i></sub> 有资格提供计算服务的一组主机（计算主机） <i>MinHostReqCap</i><sub><i>newStorage</i></sub> 新版本VM数据所需的最小存储主机数量
图2示出了具有15个主机的IaaS系统200的说明性示例。这些主机中有9个参与创建VMware虚拟存储区域网络（VSAN）–支持系统中VM操作的存储基础设施（|MStorage| = 9），而主机中的10个提供计算服务（|Mcompute|=10）。从而，主机6至主机9属于这两集。在本示例中，假定Mcompute中的每个主机都有容量服务于两个VM（K = 2）。除了这些资源，还有专用网络资源：交换机和路由器，在附图的底部示出。该示例假定四个租户，每个租户都有他们的缩放策略。注意，对于本示例，控制器主机未在图2中示出。
考虑图2的说明性示例，管理员可以发出具有两个改变的升级请求：（1）将虚拟共享存储从VSAN升级到Ceph；以及（2）将联网基础设施从IPv4升级到IPv6。虚拟共享存储和联网基础设施的这些改变彼此独立，因此管理员将它们分为两个改变集。对于每个集，从基础设施供应商提供的基础设施组件描述中自动推断出补充改变。例如，第二改变暗示所有路由器、交换机和主机升级到IPv6。这些被添加为在升级请求中给出的第二改变集的补充改变。
为了收集在IaaS系统中对于升级资源和执行撤销操作可能必需的所有信息，定义了资源升级目录。该目录包括由不同供应商针对IaaS系统中已经部署的所有组件和要添加到系统中的产品（又称为资源）提供的所有基础设施组件描述。因而，每当管理员指定将新产品称为改变的目标版本的新升级请求时，需要将该产品及其附带的基础设施组件描述添加到升级资源目录。
在说明性示例中，资源升级目录包括用于VSAN和Ceph两者的基础设施组件描述。使用这些基础设施组件描述，能导出用于将虚拟共享存储从VSAN升级到Ceph的脚本。这同样也适用于将其从Ceph降级到VSAN，如果撤销变得必要的话。
为了协调升级过程并创建用于每次迭代的（一个或多个）运行时升级调度，升级协调器需要知道系统的配置以及正在进行的升级的状态。为了这个目的，定义了资源图（RG）。它维持关于IaaS资源以及它们的依赖关系的升级过程的状态。
RG是有向图（R，D），其中R是顶点集，并且D是边集。顶点表示系统中的资源（现有的或要添加的）。顶点（资源）由以下属性表征：
●Resource/id：它是资源的id。对于要添加到系统的资源，当资源被添加到RG时，生成id。
●Resource-kind：它是基础设施资源模型中的资源的种类（例如，计算主机、交换机、路由器等）。
●Modification-type：它指示资源是要通过所请求改变来升级、添加或移除，还是它保持不变。它可以具有“升级”、“添加”、“移除”或“无改变”的值。随着升级进行，此参数的值被更新，以反映要应用于资源的剩余改变中的第一个。
●Activation-status：它指示资源的激活状态，其可以是活动的（即，服务中）或去激活的（即，停止服务）。
●Undo-unit-ids：它指示资源属于的那组撤销单元。由于可能有几个改变集影响同一资源，因此每个资源可能与几个撤销单元关联。
●Actions-to-execute：它是执行级的有序列表，其中每个执行级都是要在资源上执行的升级动作的有序列表。从而，为升级动作定义了两级排序，在执行级内和在执行级之间。
●Number-of-failed-upgrade-attempts：它是每个撤销单元对于资源的失败升级尝试的计数器。
●Related-resource：指示RG中新资源和当前资源之间的关系，其中新资源正在替换旧资源。注意，此参数仅用于控制PPU的过程，其中支持基础设施资源的VM的这两种配置在其升级的时间内被保持，以维持其服务的连续性。旧资源的相关资源将是新资源，并且反之亦然。
●Is-isolated：指示资源是否被隔离。
●Is-failed：指示资源是否失败。
D是边集，每个边表示当前或未来配置中资源之间的依赖关系。边可以是不同类型的，以捕获针对IaaS系统定义的不同类型的依赖关系：容器/包含的依赖关系、迁移依赖关系、合成依赖关系、聚合依赖关系、通信依赖关系、存储依赖关系、控制器依赖关系、VM支持基础设施依赖关系以及资源之间的对等依赖关系。
边dij表示资源Ri对资源Rj的依赖关系，即，它从相关资源定向到赞助商资源。对称依赖关系（对等）由两个资源之间的一对边（即，dij和dji）来表示。每个边有两个参数：
●Presence：它指示当前配置、未来配置或两者中是否存在依赖关系。它用于恰当地处置系统中现有和未来依赖关系的要求。它可以保存“未来”、“当前”或“当前/未来”的值。
●IncompatibilityFactor：它指示沿着依赖关系的不兼容性，这需要在升级期间解决。注意，不兼容性只能沿着具有“当前/未来”的存在值的依赖关系而发生。它用于标识升级单元。它能保存值“真”或“假”。
图3示出了根据一个实施例的在接收到升级请求之后反映图2的说明性示例的系统的示例RG 300。例如，在RG 300中，R1到R15的顶点表示在由顶点R16到R30表示的host1到host15上运行的管理程序。此托管关系（即容器/包含的依赖关系）由顶点（例如R1和R16）之间的边表示。为了可阅读性，在此图中仅表示了系统配置的一部分和所请求升级的修改类型。
供应商交付的产品（例如，Ceph）可以被映射到一个或多个IaaS资源。此示例旨在将现有VSAN虚拟共享存储（由R46表示）升级到Ceph（由R45表示），这两者都是由它们的供应商交付和描述的复合产品。在当前配置中，存储主机R16至R24被聚合到R46的虚拟共享存储中，而在未来配置中，R16至R20将被聚合到R45中。R46用作支持对计算主机R21至R30的存储的VM，并且需要由R45替换。用于当前配置的资源被映射到VSAN产品及其基础设施组件，而用于未来配置的资源被映射到Ceph产品及其组件。
由于虚拟共享存储是支持VM操作的基础设施资源，并且因为由于不兼容性而导致VSAN无法被就地升级到Ceph，因此PPU方法被用于升级。每当资源由于不兼容性而不能就地升级时，两个顶点被用于表示该资源，一个用于具有移除的修改类型的旧配置（例如，R46），并且一个用于具有添加的修改类型的新配置（例如，R45）。为了在IaaS系统中部署Ceph产品，基于所请求改变、RG和Ceph组件描述中指示的要求来标识IaaS资源的映射。新Ceph产品的不同组件将被映射到存储主机（由R16至R20表示）、计算主机（由R21至R30表示）和新的共享存储（由R45表示）。在成功映射后，一致性所需的任何附加改变都将被导出并添加到改变集。否则，不能应用改变集并将其标记为失败。
如先前在本公开中所提到的，升级单元标识一组资源，这组资源必须使用适当的升级方法来升级，以处置当前和未来配置之间的转变期间的潜在不兼容性。每个升级单元可能包括具有不同依赖关系的几个资源。根据可能出现不兼容性问题的现有依赖关系的类型，选择特定升级方法来防止不兼容版本的资源之间的通信。为此目的，升级方法模板定义如下。
当升级单元中的资源沿着对等依赖关系和/或沿着赞助依赖关系（除了通信依赖关系）具有可能的不兼容性时，使用拆分模式来避免沿着某些依赖关系的不兼容性。在这两种情况下，以下两个条件必须是有效的：1）在整个升级单元中不存在沿着通信依赖关系的不兼容性，以及2）在整个升级单元中不存在多于两个组成资源参与聚合依赖关系。否则，取决于情况而不得不使用其他升级方法。
在拆分模式下，升级单元的资源被分成两个分区，该两个分区一次升级一个分区。分区的去激活和激活的顺序是被编排的，以通过在任何给定时间只有分区中的一个分区活动来避免不兼容性，直到两个分区都被升级。
所公开的方法通过保持升级单元的至少一半资源在服务来最小化升级单元中的资源升级的影响。为了说明这一点，对于每个分区，在考虑另一分区停止服务时，以下规则必须有效：1）分区中的在服务资源数量必须是整个升级单元的在服务资源总数的一半的下限/上限（floor/ceiling），以及2）每个对等资源（直接或间接）当中至少一个资源在该分区中保持在服务。注意，由于聚合资源（即，组成）被认为是对等资源，因此每个分区中只能有一个聚合资源。
结合图6A-6D，提供了具有拆分模式的升级单元的资源分区的示例。在图6A中，升级单元包括四个对等资源（R1、R2、R3和R4），沿着对等依赖关系具有可能的不兼容性。根据前述用于拆分模式的分区规则，每个分区将包括四个资源当中的至少两个。对于此升级单元的一个可能分区是要在分区1中具有R1和R2，并且在分区2中具有R3和R4。
在图6B中，升级单元包括两个对等资源（R7和R8），与六个赞助相关资源（R1、R2、R3、R4、R5和R6），沿着所有依赖关系具有可能的不兼容性。注意，赞助依赖关系是除了通信依赖关系之外的任何子类别的赞助依赖关系。在这个示例中，每个分区必须包括R7和R8的对等资源之一，以及相关资源数量的一半的下限/上限（即，三个相关资源）。由于相关资源之间没有对等依赖关系，因此不同的相关资源组合可以在每个分区中，只要它包括相关资源的数量的一半的下限/上限。
在图6C中，升级单元包括与示例b类似的资源，不同之处在于赞助相关资源中的一些之间具有对等依赖关系。要避免对等资源在同一分区中。因此，示例b的分区对于这个示例不是有效的。可能的分区之一将是把R7、R1、R3和R5分组到分区1，并且将R8、R2、R4和R6分组到分区2。升级单元可以包括两级赞助依赖关系（除了通信依赖关系之外的任何类型）与沿着它们的可能的不兼容性，如图6D中所示。为了保持升级单元的资源的至少一半在服务，并维持由对等资源提供的服务的可用性，每个分区将包括独立的赞助商资源（R13和R14）中的一个以及它们的直接和间接相关资源（R1到R12）的一半，同时考虑资源之间对等依赖关系的约束。
拆分模式的步骤如下：1）使第一分区停止服务（即，去激活）并升级它。2）使第二分区停止服务（即，去激活第二分区）并使第一分区恢复服务（即，激活第一分区）。然后，升级第二分区，并使其恢复服务。
当升级单元中存在具有沿着通信依赖关系的可能的不兼容性的资源、并且在整个升级单元中不存在多于两个组成资源参与聚合依赖关系时，使用修改拆分模式。
修改拆分模式方法利用资源分区以及它们的激活/去激活中的一些修改来实现拆分模式升级。
如前所述，拆分模式能用于处置沿着大多数赞助依赖关系（除了通信依赖关系）的可能不兼容性。当沿着通信依赖关系存在不兼容性时，拆分模式的应用成问题。在拆分模式的分区中，通信相关资源以及其他资源将在两个分区之间被划分，以保持升级单元的资源的至少一半在服务。当应用拆分模式的第二步骤时，当旧版本的（一个或多个）通信相关资源必须与第二分区的剩余旧版本（一个或多个）通信赞助商同时升级时，出现问题。（一个或多个）旧版本通信相关资源将不从新版本的（一个或多个）赞助商（由于不兼容性）也不从具有旧版本的（一个或多个）剩余赞助商（由于它们存在于同一分区中，该分区被去激活）可达。实际上，这是由通信依赖关系和赞助依赖关系的其他子类别的差异引起的；通信依赖关系实现了资源之间的物理或虚拟链路，并且相关资源可能失去与网络的连接性而没有赞助商资源。为了解决该问题，同时解决沿着这种类型依赖关系的可能的不兼容性，第二分区（在拆分模式的步骤2中被升级）被拆分成两个或更多个分区，这取决于该分区中的通信依赖关系（具有沿着其的可能的不兼容性）的现有级。当沿着通信依赖关系存在可能的不兼容性时，通信相关和赞助商资源必须位于单独的分区中。类似于拆分模式，每一组对等资源中的至少一个资源必须位于单独的分区中。注意，第一分区将与拆分模式下的第一分区相同。不需要拆分第一分区，因为第一分区的通信相关资源在第一分区的升级期间从驻留在另一（仍然活动的）分区中的旧版本的任何通信赞助商可达。
图7A-7D图示了具有修改拆分模式的升级单元的资源分区的示例。在示例升级单元中，假定沿着通信依赖关系存在不兼容性，并且在每个升级单元中不存在多于两个组成资源；从而，将使用修改拆分模式。
在图7A中，升级单元包括两个对等资源（R7和R8），与六个通信相关资源（R1、R2、R3、R4、R5和R6），沿着所有依赖关系具有可能的不兼容性。由于升级单元包括一级通信依赖关系，因此资源将被分成三个分区。可能的分区之一是要将R7、R1、R2和R3分组到分区1中，将R4、R5和R6分组到分区2中，并让R8在分区3中。注意，在分区1中，通信相关资源（R1、R2和R3）能在与它们的通信赞助商之一（R7）相同的分区中分组和升级，因为它们能在升级时通过它们的其他通信赞助商（R8）到达。
图7B中的示例类似于图7A中的示例，不同之处在于通信相关资源中的一些之间具有对等依赖关系。要避免对等资源在同一分区中。从而，示例图7A的分区对于该示例不是有效的。可能的分区之一是要将R7、R1、R3和R5分组到分区1中，将R2、R4和R6分组到分区2中，并让R8在分区3中。
在图7C中，升级单元包括两级的通信依赖关系与沿着它们的可能的不兼容性。从而，资源将被分成四个分区，除了分区1之外，在单独的分区中具有通信相关和赞助商资源。注意，对等资源的分区约束需要被考虑进去。可能的分区之一将如下：分区1包括独立赞助商资源（R13）之一和它们的直接和间接相关资源（R9、R11、R1、R3、R5和R7）的一半，分区2包括剩余的间接通信相关资源（R2、R4、R6和R8），分区3包括剩余的直接通信相关资源，它们也是分区2的赞助商（R10和R12），以及分区4包括分区3的剩余直接通信赞助商（R14）。
在图7D的示例中，升级单元包括几级的赞助依赖关系。与示例c相反，升级单元中只有一级的通信依赖关系，而另一级是除通信之外的赞助依赖关系的任何子类别。从而，资源将被分成三个分区。可能的分区之一是要将R13、R9、R11、R1、R3、R5和R7分组到分区1中，将R2、R4、R6、R10和R12分组到分区2中，并且让R14在分区3中。注意，R2、R4、R6和R8可以在与R10和R12相同的分区中，因为这两组资源之间没有通信依赖关系。然而，R10和R12必须在与R14分开的分区中，因为除了分区1之外，通信相关资源不能在与它们的通信赞助商相同的分区中。
分区根据它们的编号升级；第一分区（即，分区1）将首先升级，并且然后旧版本的具有间接通信相关资源的分区（即，分区2）接下来将被升级。升级过程将通过升级包括前一分区的通信赞助商的分区来继续，直到到达包括独立通信赞助商资源的最后分区。
除了在修改拆分模式中的不同资源分区之外，在每个分区升级期间处置不兼容性的先决动作不同于拆分模式。可以基于系统中远程链路管理的可用性（即启用/禁用链路）以两种不同的方式应用修改拆分模式。
首先，描述了没有远程链路管理的修改拆分模式。当通信链路上的远程管理不可用时，不兼容版本的资源被去激活或激活，使得它防止不兼容性。在升级每个分区后，只要存在旧版本的任何活动资源，分区的资源将保持去激活，即，直到开始升级最后分区（其包括旧版本的剩余通信赞助商资源）。最后分区一停止服务，所有先前升级的分区都将恢复服务。从而，升级单元在应用修改拆分模式而没有远程链路管理时将具有完全中断。从而，为了维持可用性，必须使用附加资源来补偿这种升级的影响。
其次，描述了具有远程链路管理的修改拆分模式。当通信链路上的远程管理可用时，不兼容版本的资源之间的每个通信链路在分区升级期间被去激活或激活，以防止可能的不兼容性。在升级分区之前，系统禁用当前分区中正在升级的资源与它们在其他分区中的通信相关资源之间的通信链路。在升级分区之后并且在使其恢复服务之前，系统禁用该分区的升级资源（即新版本）与它们在其他分区中的通信赞助商资源（即旧版本）之间的通信链路。随后，在启用升级资源之前，启用升级资源朝向其他升级分区的通信链路。
当沿着对等或赞助依赖关系存在不兼容性时，使用具有多个组成资源的修改拆分模式；然而，由于升级单元中存在多于两个组成资源参与聚合依赖关系，因此不能使用拆分模式或修改拆分模式。由于存在一次不多于一个组成资源停止服务的限制，所以在同一分区中能留下不多于一个组成资源，因此无法应用相同的分区。在具有多个组成资源的修改拆分模式中，除了组成资源之外，类似于修改拆分模式将资源分组到分区中。每个组成资源将在单独的分区中。
分区的升级顺序类似于修改拆分模式，但是具有组成资源的分区一次升级一个。取决于远程链路管理的可用性，可以通过启用/禁用资源本身或它们之间的通信链路来避免不兼容性。
在滚动升级中，系统被分区成子系统，一次升级其中的一个，而其他提供服务。当没有不兼容性时，可以使用滚动升级方法。由于资源基于沿着它们的依赖关系的不兼容性被分组到升级单元中，因此没有沿着它们依赖关系的不兼容性的资源将在单独的升级单元中。
换句话说，这种升级单元包括要使用滚动升级方法升级的单个资源。注意，在给定的迭代中，取决于系统的当前状态、CG中的分组以及对于可用性和弹性的SLA约束，可以同时选择利用滚动升级方法的多个升级单元来升级。例如，如果容器和包含的资源被合并到CG的单个顶点，并且CG的这个顶点被选择用于滚动升级，则同时选择包含合并到该顶点的资源的所有升级单元。
所有上述处置可能不兼容性的升级方法，除了具有远程链路管理的修改拆分模式，通过在升级后保持每个分区的资源去激活来防止不兼容性。这导致对于升级单元的服务降级或服务中断。拆分模式将升级单元的服务容量减少到其一半，而没有链路管理的修改拆分模式（包括具有多个组成资源的修改拆分模式）导致升级单元在升级的持续时间内中断。一方面，作为支持处置不兼容性的升级方法的先决条件，需要附加的资源。另一方面，必须最小化所需的附加资源量，以降低升级成本。假定系统中有一些附加资源专门被用于处置不兼容性。
此类附加资源的最小数量可基于系统的现有升级单元并考虑可适用升级方法的服务降级量（就计算主机而言）来确定。要确定此最小数量，标识就计算主机而言具有最大服务降级的升级单元。计算主机的这个量被用作专用于处置系统中贯穿所有升级的不兼容性所需的最小附加资源。从而，由于可用的额外资源的限制，升级单元中的一些的升级可能被延迟。
以下是对提出的IaaS升级方法的详细描述。为了维持可用性，IaaS云系统必须使用迭代过程来升级。图4图示了根据一个实施例的升级方法的迭代过程的总体视图。在每次迭代中，将当前配置（配置i）升级为升级的配置（配置i+1），将升级请求、基础设施组件描述和SLA当作输入。先前的迭代报告（如果有的话）也被考虑进去。升级过程处置潜在的失败和缩放请求。如果存在任何剩余的改变要被处置，则迭代过程继续。
图5是图示根据一个实施例的迭代过程500的每次迭代中的主要步骤的流程图。四个主要步骤包括：步骤1创建/更新资源图（RG）；步骤2为升级对IaaS资源进行分组；步骤3为升级选择一批IaaS资源，以及步骤4选择一批VM来迁移。
在每次迭代中，步骤1通过创建或更新RG来收集和组织升级IaaS资源所必需的信息。该图在初始迭代中创建，并且然后在每个后续迭代中更新。这个步骤在初始和后续迭代中的输入虽然类似，但不相同。在初始迭代中，根据系统的当前配置、请求的改变集以及供应商提供的基础设施组件描述来创建RG。在后续迭代中，作为附加输入，使用升级请求模型，反映新的和正在进行的升级请求以及具有先前迭代的结果的升级迭代报告。除了别的之外，升级迭代报告还指示先前迭代的任何失败的升级动作连同失败的和仅隔离的资源，基于此可以根据需要发起撤销/重试操作。
如前所述，系统的配置也可能在独立于升级过程的两次后续迭代之间改变，例如，由于实时迁移、失败和向内/向外缩放。从而，在每次迭代中，RG被更新以反映系统的当前配置。RG更新还考虑了任何新的升级请求，针对其标识了补充改变和适当的升级方法。
在步骤2，基于资源的依赖关系和所选的升级方法，从RG中标识需要同时升级的资源。这些资源的顶点被合并，并且由此，RG被粗化为升级控制图（CG），其中每个顶点表示资源组，该资源组将需要同时升级的一个或多个资源进行分组。CG的顶点维持了从中形成它的RG的顶点的所有信息。例如，对于资源组，要执行动作属性是通过按执行级合并形成组的资源的要执行动作属性而形成的。在后续的步骤中，可以在当前迭代中升级的资源是根据CG的资源组以及它们的依赖关系来选择的。
从而，在步骤3，首先选择能被升级而不违反任何它们依赖关系兼容性要求的IaaS资源组，以形成初始批。然而，由于SLA约束，可能只有初始批的子集能在该迭代中升级，从而得到最后批。因而，生成运行时升级调度，由最后批的升级动作组成。该升级调度被发送到升级引擎来执行，其报告回结果。在升级动作失败的情况下，可以立即生成新调度，以试图使用在当前迭代中已经执行的升级动作的撤销动作将受影响的资源带回到稳定的配置。注意，只有同一撤销单元的升级动作才是有关的。如果已经执行了多于一个撤销单元的动作，则可能没有必要撤销其他撤销单元的动作。例如，如果uu1和uu2是两个不同的撤销单元，并且升级动作a1（uu1）、a2（uu1）、a3（uu2）、a4（uu2）在资源上成功执行，并且a5（uu2）失败，那么仅撤销a3和a4是足够的，因为它们与同一撤销单元uu2关联。升级动作a1和a2能保持适用。然而，这可以通过策略来确定执行级的这种部分撤销是否可接受。
在步骤4，考虑由基础设施托管的VM。每当在升级期间已经对计算主机进行了分区（如果适当的话）时，在此步骤中选择一批VM来迁移并且可能升级。由于升级VM支持基础设施资源和管理程序两者都影响托管VM的计算主机，因此在它们被升级时，IaaS计算主机被分区为旧分区和新分区。如果这些升级不需要VM升级，则在步骤4，将选择的一批VM从旧分区迁移到新分区。如果由于版本之间的不兼容性，VM升级也是必要的，那么VM也在该过程中升级。该批VM的选择考虑了前一步骤3的结果，即，（一个或多个）那些升级调度的执行的结果。为了遵守应用级冗余，所公开的方法一次可能只影响每反关联性组的有限数量的VM（一个或如对于SLA适当的）。这意味着选择的一批VM可能需要在子迭代中升级/迁移。从而，升级协调器为每个子迭代生成升级调度。如步骤3中，升级协调器将每个调度发送给升级引擎来执行，并基于接收收到的反馈生成下一调度。如果升级动作失败，则新的升级调度还包括针对失败动作而反转已完成升级动作的影响的动作。该过程继续直到选择的批中的所有VM都已经被处置。如果计算主机没有被分区，则全部跳过步骤4。
返回参考图1的升级协调器110和升级引擎120，在每次迭代中，升级协调器110生成几个升级调度。在执行每个调度之后，升级引擎120将结果报告回升级协调器110。在资源级，任何失败都由升级协调器110通过生成新的调度以将资源带到稳定配置或隔离它来立即处置。一旦资源级动作对于给定迭代不适当或必要，升级协调器110便更新升级请求模型、RG和CG，并生成升级迭代报告以反映该迭代内所有调度的执行结果。然后，升级协调器110如适当地继续进行到下一迭代。
当升级请求模型中指示的所有升级请求都已被处置并且尚未接收到新的升级请求时，升级过程终止。这意味着接收到的所有升级请求的所有改变集都已被成功应用或撤销，除非它们的目标资源失败。
图5中的四个步骤中的每一个都在下面进一步阐述。
步骤1：创建/更新资源图。在该步骤中用于创建/更新RG的任务在图9A和图9B的流程图910和920中从任务1至12指示。
如前所述，从管理员接收到的升级请求被处理并聚合到升级请求模型中，该升级请求模型被用作创建和更新RG的输入。
为了创建RG，从系统的当前配置中提取所有现有资源（即，顶点）和依赖关系（即，边）。它们的参数从系统配置（例如，资源id）和升级请求模型（例如，修改类型）导出。要添加的资源从升级请求模型中的改变集确定。对于它们而言，参数和依赖关系是从升级请求模型中和从供应商提供的基础设施组件描述中导出的。
例如，每当VM支持基础设施资源无法就地升级且使用PPU时，在RG中创建两个顶点来表示VM支持基础设施的旧配置和新配置。它们的修改类型分别被设置成移除和添加。从而，作为升级的结果，（一个或多个）VM支持基础设施资源的旧配置将被新配置替换。
为了满足供应商指示的要求，每个改变集都针对完整性来验证，并且任何缺失的改变都被添加到升级请求模型。这些也反映在RG中。在此过程中，每个改变集被指配给唯一撤销单元。
每个资源的要执行动作属性是使用升级资源目录中保持的基础设施组件描述来确定的。如果由于排序约束，所需的升级动作无法在单次迭代中应用于资源，则升级动作将被拆分为不同的执行级，以实施该排序。
为了避免不兼容版本的资源之间在它们升级期间通信，具有不兼容性的相关资源的升级需要使用适当处置这些不兼容性的升级方法来执行。为此，所公开的方法首先标识RG中的这种资源，并且然后将它们分组到与适当升级方法关联的升级单元中。使用的两种基本升级方法是：拆分模式和滚动升级。拆分模式通常在不兼容性和另外滚动升级的情况下被使用。如前所述，拆分模式升级方法具有不同的变体。此外，PPU方法可以被认为是其变体之一。取决于情况，也可以使用其他升级方法，但是在本公开中没有解决。
为了在后续迭代中更新RG，对于系统中发生的任何改变，首先在RG中反映系统的当前配置。刚刚完成的迭代的升级迭代报告有助于标识所需的任何重试和系统级撤销操作。如果失败的升级尝试数量少于相关撤销单元的重试阈值，则在具有升级尝试失败的资源上发起重试操作。根据需要调整要执行动作属性。否则，隔离资源。每当用于撤销单元的仅隔离和失败资源的数量达到撤销阈值时，必须撤销已经应用到撤销单元资源的所有改变。此外，对于在指示为最大完成时间的时间限制内无法完成其升级的任何撤销单元，发起撤销操作。这是从具有对应改变集的升级请求的时间戳的时间中测量的。时间戳可以反映接收到升级请求的时间或者应用与升级请求关联的第一动作时的时间。这些撤销单元和关联的改变集也被标记为失败。
为了应用撤销操作，在失败的撤销单元中所有受影响的资源（不包括失败的资源）的要执行动作属性被调整，使得它们将被带到针对资源指示的撤销版本。这些撤销动作被组织到资源的第一执行级，使得它们将首先被执行。由于这些资源在它们的要执行动作属性中可能有与在资源上请求的其他改变集关联的升级动作，其尚未完成并且由于撤销而变得在调整的情况下不适当或不完整，因此它们也需要被调整。为此，相对于潜在的新的源和目标版本来重新评估资源的其他执行级的升级动作，以及基于目录中的组件描述来更新升级动作。在撤销版本的仅隔离的资源从隔离中释放，否则它们变成失败的资源。例如，如果资源的要执行动作具有在执行级1用撤销版本2将资源从版本1改变为版本3的升级动作（例如，动作1），则另一升级动作（例如，动作2）在执行级2添加，这假定资源至少在版本2，并且第三升级动作（例如，动作3）在执行级3，这假定资源在版本3，那么当动作1失败时，动作2和动作3被修订。由于动作1的撤销版本是版本2，因此只要资源在它被应用之前升级到版本2，动作2就保持有效。也就是说，除了添加失败的动作1的撤销动作（这应该将资源带回到版本1）之外，还添加了附加动作以将资源的版本改变为版本2。这些动作是在执行级1添加的，使得它们在动作2被执行之前完成。关于在执行级3的动作3，由于资源将仅在版本2，仅与预期的版本3相反，因此该动作3需要从该资源的要执行动作中移除，并且还需要在相关的撤销单元中修订所有相关的改变。备选地，如果有可能，则可以将动作添加到执行级2，以将资源升级到版本3，使得它在动作3被执行之前完成。注意，其他调整也是可能的，并且可能取决于给定的情况而被需要。
如前所述，在步骤1，新的升级请求被添加到升级请求模型，并且然后也添加到RG。新的升级请求可能以作为未决改变请求的部分的资源为目标。这种新的升级请求也可能导致新的不兼容性。为了标识这些，使用了类似于RG的图：新请求图（NRG）。它仅从新的升级请求创建，而不考虑任何正在进行的升级。从组件描述中，用于新改变集的升级动作被提取并根据需要组织到执行级中。接下来，所公开的方法标识任何新引入的不兼容性，并创建与NRG中的适当升级方法关联的对应新升级单元。该NRG被用于更新RG如下：关于已经在RG中的资源的要执行动作属性，所公开的方法为NRG中的每个执行级创建并附加新的执行级。新添加的执行级与在NRG中标识的升级单元关联。一旦RG从它更新，NRG便被丢弃。
步骤2：对IaaS资源进行分组以便升级。资源之间的一些依赖关系兼容性要求需要它们在单次迭代中同时升级。如前所述，为了便于协调这些资源的升级，RG被粗化为CG，如图9B的流程图920中的任务13中所指示的。在CG中，每个顶点表示资源组，即，要同时升级的RG的单独资源或一组资源。在此，提供了关于用于创建或更新CG的操作的更多细节：
第一种类型的操作是基于依赖关系的边收缩。在升级容器期间，其包含的（一个或多个）资源除了它们自身升级期间的中断之外还经历中断。同样，在组成资源升级期间，它们的复合资源经历中断。为了减少中断时间，具有容器/包含的资源和具有合成依赖关系的资源将在单次迭代中同时升级。从而，表示RG中这种依赖关系的边被收缩，以将表示这些资源的顶点合并到CG的单个顶点中。CG中的顶点，表示RG的资源组，将具有与RG的合并顶点的资源相同的对其他资源的依赖关系，除了容器/包含的和合成依赖关系之外。图8示出了用于说明性示例的对应于图3的RG 300的CG 800。这种类型的边收缩被应用于表示资源R1、R16、R47、R48、R49和R50的RG 300的顶点，以将它们粗化为CG 800的顶点GR1。注意，在图8中，没有显示CG的升级相关参数。
第二种类型的操作是基于升级方法的顶点收缩。一些升级方法通过在单次迭代中同时升级资源来避免不兼容性。所公开的方法基于第一执行级在它们的要执行动作属性中的关联升级方法来针对此类资源执行顶点收缩。在顶点收缩的情况下，CG的结果顶点将具有该组的资源在RG中具有的所有依赖关系的并集。例如，表示要使用拆分模式升级方法来升级的升级单元的资源的顶点将根据用于拆分模式的升级单元的子分区而收缩。这允许恰当协调资源的升级，而不引入不兼容性。
在后续的迭代中，CG也被更新，以维持与步骤1中更新的RG的一致性。
步骤3：选择一批IaaS资源来升级。在这个步骤中，在当前迭代中要升级的那批IaaS资源被选择，考虑了现有依赖关系和SLA约束两者，并被应用在IaaS资源上。在图9C的流程图930中，从任务14到21指示了用于选择那批IaaS资源的任务。由于VM表示IaaS云系统提供的服务，因此在步骤4中通过考虑不同的标准来单独处置它们。
首先，如果适用的话，尽可能多地将VM整合到计算主机上，以释放一些主机。特别地，如果VM支持基础设施资源需要以不兼容的方式升级，则所公开的方法试图从多组MStorage和MCompute之间公用的物理主机中撤出VM，以尽可能多地适应PPU方法。注意，在VM整合期间，所公开的方法通过一次从每个反关联性组仅迁移允许数量（例如一个）的VM来遵守从反关联性分组推断出的可用性约束。整合之后，RG和CG必须相应地更新。
为了使用CG处置升级期间的依赖关系，所公开的方法标识能在当前迭代中升级而不违反任何它们的依赖关系的资源组（Gbatch）。为了以系统的方式这么做，第一Gbatch被初始化为具有剩余改变的CG顶点（即，“升级”、“添加”、“移除”的修改类型）和具有去激活状态的CG顶点（即，需要被激活）的并集。
接下来，所公开的方法从Gbatch中消除顶点，其由于一些依赖关系而不能在当前迭代中升级。为了这么做，定义了一组规则，称为消除规则。消除规则基于资源的修改类型、与资源的要执行动作属性中的第一执行级的升级单元关联的升级方法、资源的依赖关系的特性（即，不兼容性因素和存在）、资源的激活状态以及作为相关升级的先决条件的所需附加资源的可用性，来标识Gbatch中的不合适的候选。
这些消除规则保证：资源之间赞助依赖关系的兼容性要求的实施、对等资源提供的服务的可用性、PPU方法的资源要求的满足、根据SLA的VM服务的可用性、依赖关系兼容性要求的满足（即，在从系统中移除资源之前，以及在向系统添加资源之前）。
本文描述了消除规则之一。当VM支持基础设施资源无法在不影响其服务的情况下就地升级时，消除规则保证满足用于升级VM支持基础设施资源的PPU方法的资源要求。如前所述，并行维持VM支持基础设施资源的旧配置和新配置两者可能需要附加资源。如果这些无法使用可用资源提供，则要求管理员提供附加资源。直到这些资源要求不满足为止，从Gbatch中消除具有与VM支持基础设施资源的升级有关的改变的所有资源（由关联的升级单元指示）。
在该示例中，PPU方法用于将VM支持虚拟共享存储从VSAN升级到Ceph，因为新版本和旧版本的虚拟共享存储不兼容。为了在升级期间保持VM支持服务的连续性（例如，VM实时迁移和失败转移），虚拟共享存储的旧配置（即，VSAN）必须保持可操作，直到新配置（即Ceph）准备好使用。此外，托管VM的计算主机需要被分区为与旧版本的虚拟共享存储兼容的那些计算主机（旧分区）和与新版本的共享存储兼容的那些计算主机（新分区）。为了完成这个升级，数据转换也是必要的，并且它是在VM从旧分区迁移到新分区时执行的。一旦已经迁移了所有VM以及完成相关数据迁移，便能安全地移除虚拟共享存储的旧配置。
为了保证共享存储的升级期间VM服务的连续性，对于旧虚拟共享存储和新虚拟共享存储两者，相对于它们的配置和存储的数据，需要满足最低资源要求。出于这个原因，需要足够的物理存储主机来保持存储的旧配置活跃，同时调出新的配置。以下表达式评估当前系统是否具有足够的存储主机。
Figure 491238DEST_PATH_IMAGE002
针对使用的符号请参考表I。
| Mstorage-MusedCompute |表示在使用中没有作为计算主机的存储主机的数量。该数量应等于或大于在升级期间支持旧存储配置和新存储配置两者所需的最小主机数量。如果满足（1），则具有与虚拟存储升级关联的撤销单元相关的升级动作的资源保留在Gbatch中。否则，应用消除规则将把这些资源作为不合适的候选从Gbatch中移除。由于在每次后续迭代中都执行相同的检查，因此每当附加数量的存储主机变得可用于满足此要求时，这些资源将作为合适的候选保留在Gbatch中。注意，随着升级进行，可用资源的数量可能由于计算主机上的失败或缩放操作而改变，而且如果提供了附加的主机也是如此。从而，在任何迭代中，当（1）不满足时，该消除规则将从Gbatch中移除与此升级相关的资源（即，它们的升级将被暂停），直到所需的资源变得再次可用。
在应用所有消除规则之后，在Gbatch中保留的顶点表示在此迭代中潜在地能被升级的资源组（又称为初始批）。然而，这种选择尚未考虑到IaaS云的动态性；即，如果在当前迭代中升级了所有这些资源组，则SLA违反可能仍然发生。也就是说，考虑到迭代期间潜在的失败转移和向外缩放请求，只有一定数量的计算主机可以停止服务。从而，具有这些考虑，从初始批中选择最后批资源组。
每次迭代中的潜在向外缩放请求是基于升级候选批所需的时间来估计的，在候选批中并行升级资源。在每次迭代中，可以升级不同的资源，因此在每次迭代中，所公开的方法考虑Gbatch中的资源，并采取最大的它们所需的时间来升级（Ti）。使用这个，根据（2）计算迭代i中Gbatch升级期间每租户（Si）的最大缩放调整请求。
Figure 346061DEST_PATH_IMAGE003
其中sn是第n个租户的每冷却期cn的缩放调整。由于租户可能具有不同的缩放调整和冷却时间值，因此所公开的方法将它们中最大的缩放调整当作Si，并且由此它处置最坏情况场景。该计算仅对单次迭代有效，并且它对于每次迭代重新计算，因为在每次迭代中，不同的资源可能保留在Gbatch中，并且租户也可能被添加和/或移除。
每次迭代中可以停止服务的计算主机的最大数量（Zi）使用（3）计算。
Figure 125799DEST_PATH_IMAGE004
Figure 521008DEST_PATH_IMAGE005
是不在使用并且有资格为具有旧版本VM的租户提供计算服务（即，与旧管理程序或VM支持基础设施资源的旧配置兼容）的计算主机数量。FailoverResevforOldVM是为旧版本VM的失败转移预留的计算主机数量。当在属于MComputeForOldVM的主机上存在旧版本的VM时（即，MusedComputeForOldVM不为零），此数量等于在迭代（F）期间要容忍的主机失败数量；否则F将为零。F可以基于主机的失败率和概率函数来计算。F估计在周期Ti内所需的失败转移预留。ScalingResvforOldVM是用于利用旧版本的VM缩放租户预留的计算主机数量，并且它使用（4）计算。
Figure 335380DEST_PATH_IMAGE006
Ai指示仅具有旧版本的VM并且尚未达到它们的maxn（VM的最大数量）的租户数量，因此可以在与旧版本VM兼容的主机上向外缩放。
每当MusedComputeForOldVM旧版本使用中的计算主机集为空，在迭代中可以停止服务的计算主机的最大数量变得等于属于McomputeForOldVM的主机集。
注意，如果不存在与VM支持基础设施资源或管理程序的升级相关的不兼容性，则IaaS云系统的计算主机不被分区为旧分区和新分区。在这种情况下，上面的计算适用于所有计算主机（与托管旧VM的那些相反）和所有VM，因为不需要考虑VM和计算主机的兼容性。
因而，从初始批Gbatch中选择最后批资源组，使得受影响的计算主机总数不多于Zi。可以从最后批Gbatch中选择总的受影响资源小于或等于Zi的Gbatch的任何子集。升级协调器选择这样的最后批，并生成对应的升级调度。此升级调度包括Gbatch中每个资源组的要执行动作属性的第一执行级的升级动作。所生成的调度被发送到升级引擎来执行。在执行后，升级引擎将结果发送回升级协调器。
注意，应用升级方法中的一些可能需要先决条件和总结动作。如果最后批中的资源属于具有这种关联升级方法的升级单元，则升级协调器在升级调度中包括该资源的升级动作之前的先决动作以及它们之后的总结动作。例如，作为用于在升级单元中升级某些物理主机的先决动作，升级协调器可能需要在它们的升级动作之前在升级调度中包括以从那些物理主机中撤出VM。作为总结动作，它可能需要在升级调度中包括将VM带回升级的物理主机的动作。
如果最后批中资源的升级动作成功执行，则第一执行级从其要执行动作属性中移除。根据要执行动作属性的新的第一执行级的升级动作来调整资源的修改类型。
对于具有失败的升级动作的资源，失败尝试的计数器递增，但要执行动作属性保持不变。如前所述，为了将资源带回到稳定配置，在失败的尝试内从已完成升级动作的撤销动作中创建新的升级调度，以反转它们的影响。该升级调度被立即给到升级引擎来执行。如果此操作也失败，则资源被隔离并被标记为失败。
最后，根据该步骤的结果更新升级请求模型、RG和CG。
步骤4：选择一批VM来迁移。只有当计算主机由于VM支持基础设施和/或托管VM的管理程序的升级而被分成两个不兼容的分区并且因此VM需要在它们之间迁移（并潜在地升级）时，这个步骤才是必要的。例如，当使用PPU方法来处置VM支持基础设施资源的不兼容性时。
在旧版本的VM能被升级并迁移到与新VM版本兼容的主机之前，必须完成VM支持基础设施资源的新配置。如果新配置没有准备就绪，则在重新评估它时，VM迁移/升级被延迟到后续迭代。在由于管理程序升级导致不兼容性的情况下，可以在至少一个管理程序成功升级后开始此步骤。在图9D的流程图940中，从任务22到28指示了用于选择一批VM来迁移/升级的任务。
使用等式（5）计算在当前迭代i中可以被迁移并且如果必要的话被升级的VM的数量（Vi）。
Figure 95526DEST_PATH_IMAGE007
McomputeForNewVM是有资格为具有新版本VM的租户提供计算服务的主机集，MusedComputeForNewVM是有资格为具有新版本VM的租户提供计算服务的在使用的主机集，FailoverResevforNewVM是为升级的（新）VM的任何失败转移预留的主机数量。FailoverResevforNewVM类似于对具有旧版本VM的租户的失败转移预留（即，如步骤3中所提到的F）而计算，但在用于升级Vi数量的VM所需的时间段内。ScalingResvforNewVM是为对于具有升级的（新）VM的租户的缩放预留的主机数量，并且K'是升级后VM方面的新主机容量。这里，对于具有尚未达到它们的maxn（它们的VM的最大数量）的新版本VM的租户，ScalingResvforNewVM类似于（4）而计算。它们可能仅在与新版本VM兼容的主机上向外缩放。注意，每租户的新缩放调整类似于（2）而计算，同时考虑迁移所需的时间并且如果必要的话潜在地通过多个子迭代来升级Vi数量的VM，如下所述。
考虑到应用级冗余，通常每反关联性组一次只能迁移（和升级）一个VM。因此，升级Vi个VM可以在几个子迭代中执行。从而，迁移（和升级）Vi数量的VM所需的时间取决于子迭代的数量和单个VM所需的时间。在每个子迭代j中，从具有旧版本VM的每个反关联性组中选择一个VM。一批子迭代j将是Wij。可以通过不同标准选择反关联性组以及它们的VM来升级。在升级协调器选择VM来迁移/升级后，每子迭代创建调度，并将其提供给升级引擎来执行。在执行每个子迭代之后，升级引擎将结果返回给升级协调器。成功迁移/升级的VM的要执行动作属性通过移除第一执行级来更新。对于具有失败尝试的VM，失败尝试计数器递增，并且生成新的调度以将它们带回到稳定配置。如果对于VM，此操作也失败，则它被隔离并标记为失败。该过程重复，直到所有Vi个VM都已被处置。
每当在步骤3中最后批资源（Gbatch）和在步骤4中该批VM（Vi）两者对于迭代都是空的时，升级过程停止，直到有足够的资源可用于继续（例如，通过向内缩放来释放）。
已经描述了一种新颖方法和系统，用于在诸如可用性和弹性之类的SLA约束下升级IaaS云系统。所公开的方法以集成的方式解决了由依赖关系和沿着依赖关系的可能的不兼容性、由升级失败、由IaaS云系统的动态性以及由所使用的额外资源量所造成的挑战。
在所公开的方法中，升级由升级请求发起，该升级请求由例如系统管理员所请求的指示IaaS云系统中的期望改变的改变集组成。除了初始改变集之外，所公开的方法允许在升级过程的每次迭代的新升级请求。升级每个IaaS资源所需的升级动作、对于每个资源子集适当的升级方法以及每次迭代中要升级的那批资源由该方法自动确定，并以迭代方式应用。由于在每次迭代中，要升级的那批资源是根据系统的当前状态相对于依赖关系和SLA约束来选择的，所以自动缩放和升级过程之间的干扰被减轻。此外，由于升级过程是基于系统的当前状态来调节的，因此云提供商可以根据系统的状态来逐步执行升级，并且它们不需要指定用于执行升级的维持窗口。在所公开的方法中，在升级失败的情况下，还根据由管理员指示的失败和撤销/重试阈值自动发出局部化重试和撤销操作。此特征具有撤销失败的改变集的能力，同时升级继续进行其他改变集。
图10是图示用于在迭代过程中升级提供IaaS的系统中的资源的方法1000的流程图。当网络节点接收到指示对系统的当前配置的所请求改变的升级请求时，方法1000开始于步骤1010。响应于升级请求，网络节点在步骤1020创建当前配置和所请求改变的一个或多个图表示。一个或多个图表示包括控制图，该控制图具有各自表示一个或多个资源的资源组的顶点和表示资源组之间依赖关系的边。网络节点在步骤1030基于依赖关系和包括系统的可用性和弹性的SLA要求，从资源组中标识要在当前迭代中升级的一批一个或多个资源组。网络节点在步骤1040使用选择的一种或多种升级方法对所标识批执行升级操作，所述升级方法处置系统的当前配置和升级的配置之间的转变期间的潜在不兼容性。网络节点在步骤1050响应于失败的升级操作的反馈，迭代地更新一个或多个图表示以包括任何新请求的改变和恢复操作，标识要在下一迭代中升级的下一批一个或多个资源组，以及升级剩余的一个或多个资源组。
在一个实施例中，一个或多个图表示包括资源图，该资源图是资源、资源之间的依赖关系和所请求改变的表示。控制图通过基于依赖关系和要执行的升级方法收缩资源图来形成。
在一个实施例中，所述升级请求包括可彼此独立应用的改变集的集合，并且每个改变集包含相关改变。根据基础设施组件依赖关系的描述，相对于硬件或软件依赖关系而为缺失的改变检查每个改变集。如果改变集不满足基础设施组件依赖关系，则向改变集添加补充改变。
在一个实施例中，VM支持子系统包括以下中的一个或多个：管理程序、存储和控制器。在当VM支持子系统中的资源从旧版本升级到新版本时的迭代过程的迭代中，将若干VM从计算主机的旧分区迁移到与旧分区不兼容的新分区。迭代中要迁移的VM数量基于有资格托管VM的新版本的计算主机的数量和为所述迭代期间所述VM的新版本的缩放和失败转移而预留的计算主机的数量。在一个实施例中，根据对VM的反关联性分组要求，在迭代的多个子迭代中迁移VM。在一个实施例中，创建VM支持子系统的新配置，其中新配置由计算主机的新分区托管的新版本的资源组成。在计算主机的旧分区中并行维持旧版本的资源的当前配置，直到与所述新版本兼容的所有VM都从所述旧分区迁移到所述新分区。
在一个实施例中，在所述升级操作期间，网络节点仅当系统中的现有资源不满足所述SLA要求时，才向所述系统添加附加资源。
在迭代过程的每次迭代中，网络节点基于系统中的依赖关系、系统的当前状态以及升级操作的排序，从与剩余改变关联的资源中消除不合格资源，以获得初始批资源。然后，从初始批中选择最后批资源。初始批中的剩余资源在迭代期间不升级，以由此处置迭代期间的潜在的向外缩放请求和潜在的失败。
所公开的方法适用于包括计算资源、存储资源和网络资源的组合的资源。
在一个实施例中，响应于失败的升级操作的反馈而执行的恢复操作包括重试操作和撤销操作中的一个或多个。在一个实施例中，网络节点可以将给定改变集应用在对应于该给定改变集的目标资源的撤销单元上。如果所述给定改变集中的改变不能成功地应用于撤销单元中的目标资源，则网络节点复原给定改变集的已执行改变对撤销单元的影响。
在一个实施例中，每个改变集被提供有一组重试参数，所述重试参数被用于确定来自所述改变集的改变是否能被成功地应用于资源。所述一组重试参数包括以下中的一个或多个：最大重试阈值，其指定用于将来自改变集的改变应用于资源的重试尝试的最大数量；以及最大完成期，其指定分配来完成改变集中所有改变的最大时间。此外，每个改变集被提供有一组撤销参数，所述一组撤销参数包括以下中的一个或多个：撤销版本，其指定当复原所述改变集对资源的影响时所述资源的版本；以及撤销阈值，其指示在将所述改变集中的改变应用于所述撤销单元之后所述撤销单元中操作资源的所需数量。当在当前迭代中给定改变集中的改变不能成功地应用于所述撤销单元中的所述目标资源时，网络节点可以在下一迭代中自动地将所述给定改变集重新应用在所述撤销单元上。
图11是图示根据一个实施例的用于选择升级方法以处置迭代升级过程期间的资源的潜在不兼容性的方法1100的流程图。迭代升级过程将IaaS提供系统从当前配置升级到升级的配置。方法1100开始于步骤1110，当网络节点将具有潜在不兼容性的资源指配给相同升级单元，并将可兼容资源指配给不同升级单元；至少部分基于所述升级单元中的资源之间的依赖关系的类型，选择每个升级单元的升级方法；以及在所述迭代升级过程的每次迭代中升级一个或多个升级单元，其中每个升级单元在单次迭代中升级。
在一个实施例中，选择每个升级单元的升级方法基于若干因素，所述若干因素包括以下中的一个或多个：所述资源之间是否存在不兼容性，潜在不兼容性是否在具有对等依赖关系、赞助依赖关系或通信依赖关系的资源之间，所述通信依赖关系是否具有远程链路管理，以及是否有多于两个的组成资源参与到所述升级单元中的聚合依赖关系。
升级方法是以下中之一：拆分模式方法、不具有远程链路管理的第一修改拆分模式方法、具有远程链路管理的第二修改拆分模式方法、具有多个组成资源的第三修改拆分模式、部分并行全域方法和滚动升级方法。
在一个实施例中，拆分模式方法将升级单元的资源分成两个分区，所述两个分区包括第一分区和在所述第一分区之后升级的第二分区，并且所述两个分区中只有一个是活动的，直到所述两个分区两者都被升级，所述第一修改拆分模式方法和所述第二修改拆分模式方法进一步将所述第二分区分成两个或更多分区，以在单独的分区中保持通信相关和赞助商资源，所述第一修改拆分模式方法控制去激活和激活不兼容版本的资源的顺序，所述第二修改拆分模式方法控制去激活和激活不兼容版本的资源之间的通信链路的顺序，所述第三修改拆分模式方法将每个组成资源放置在单独的分区中，以及所述滚动升级方法一次升级一个或多个升级单元，而其他升级单元提供所述系统的服务，所述升级单元中的每个包含单个资源。在上述升级方法选择中，指配给升级单元的资源排除系统中的VM。
图12是图示根据一个实施例的网络节点1200的框图。在一个实施例中，网络节点1200可以是运营商网络或数据中心中的服务器。网络节点1200包括电路，该电路进一步包括处理电路1202、存储器1204或指令储存库和接口电路1206。接口电路1206能包括至少一个输入端口和至少一个输出端口。存储器1204包含由处理电路1202可执行的指令，由此网络节点1200可操作以执行本文描述的各种实施例。
图13是包括云计算实体层级的云计算环境1300的架构概述。云计算环境1300可以包括通过网络1335连接的在不同地理站点的若干不同的数据中心（DC）1330。每个数据中心1330站点包括若干机架1320，每个机架1320包括若干服务器1310。要理解，在备选实施例中，云计算环境可以包括任何数量的数据中心、机架和服务器。可以选择一组服务器1310来托管资源1340。在一个实施例中，服务器1310为托管实体以及它们托管的实体提供执行环境，其中托管实体可以是服务提供商，并且托管的实体可以是服务提供商提供的服务。除了别的之外，托管实体的示例还包括虚拟机（其可以托管容器）和容器（其可以托管包含的组件）。容器是软件组件，该软件组件在它本身内能包含其他组件。多个容器能共享同一操作系统（OS）实例，并且每个容器为其包含的组件提供隔离的执行环境。与VM相反，容器以及它们包含的组件共享同一主机OS实例，并且因此产生更少开销。服务器1310、VM和VM内的容器中的每个可以被配置成执行如本文中已经描述的各种实施例。
根据一个实施例，服务器1310及其资源1340的进一步细节在图13的虚线圆圈1315内示出。云计算环境1300包括通用网络装置（例如，服务器1310），该通用网络装置包括包含一组一个或多个处理器1360的硬件，该处理器1360可以是商业现货（COTS）处理器、专用的专用集成电路（ASIC）或任何其他类型的处理电路（包括数字或模拟硬件组件或专用处理器）、以及（一个或多个）网络接口控制器1370（NIC）（也称为网络接口卡），以及其中存储有由（一个或多个）处理器1360可执行的软件和/或指令的非暂时性机器可读存储介质1390。
在操作期间，（一个或多个）处理器1360执行该软件以实例化管理程序1350和由管理程序1350运行的一个或多个VM 1341、1342。管理程序1350和VM 1341、1342是虚拟资源，其可以在该实施例中运行节点实例。在一个实施例中，节点实例可以在VM 1341、1342中的一个或多个上实现，所述VM在管理程序1350上运行以执行如本文中已经描述的各种实施例。在一个实施例中，节点实例可以被实例化为执行如本文中所描述的各种实施例的网络节点。
实施例可以被表示为存储在机器可读介质（诸如非暂时性机器可读存储介质1390，也称为计算机可读介质、处理器可读介质或具有在其中体现的计算机可读程序代码的计算机可用介质）中的软件产品。非暂时性机器可读介质1390可以是任何合适的有形介质，包括磁、光或电存储介质，包括磁盘、致密盘只读存储器（CD-ROM）、数字通用盘只读存储器（DVD-ROM）存储器装置（易失性或非易失性），诸如硬盘驱动器或固态驱动器、或类似的存储机构。机器可读介质可以包含指令、代码序列、配置信息或其他数据的各种集，其在被执行时使处理器执行根据实施例的方法中的步骤。本领域技术人员将领会，实现所描述实施例所必要的其他指令和操作也可以存储在机器可读介质上。从机器可读介质运行的软件可以与电路通过接口连接以执行所描述的任务。
上面描述的实施例仅旨在是示例。本领域技术人员可以对特定实施例实现变更、修改和变化。

Claims (40)

1.一种用于在迭代过程中升级提供基础设施即服务（IaaS）的系统中的资源的方法，包括：
接收升级请求，所述升级请求指示对所述系统的当前配置的所请求改变；
响应于所述升级请求，创建所述当前配置和所请求改变的一个或多个图表示，所述一个或多个图表示包括控制图，所述控制图具有各自表示一个或多个资源的资源组的顶点和表示所述资源组之间的依赖关系的边；
基于所述依赖关系和包括所述系统的可用性和弹性的服务级协定（SLA）要求，从所述资源组中标识要在当前迭代中升级的一批一个或多个资源组；
使用选择的一种或多种升级方法对所标识批执行升级操作，所述升级方法处置所述系统的所述当前配置和升级的配置之间的转变期间的潜在不兼容性；以及
响应于失败的升级操作的反馈，迭代地更新所述一个或多个图表示以包括任何新请求的改变和恢复操作，标识要在下一迭代中升级的下一批一个或多个资源组，以及升级剩余的一个或多个资源组。
2.如权利要求1所述的方法，其中，创建所述一个或多个图表示进一步包括：
响应于所述升级请求，创建资源图作为所述资源、所述资源之间的依赖关系和所请求改变的表示；以及
通过基于所述依赖关系和要执行的升级方法收缩所述资源图来形成所述控制图。
3.如权利要求1所述的方法，其中，所述升级请求包括可彼此独立应用的改变集的集合，并且每个改变集包含相关改变，所述方法包括：
根据基础设施组件依赖关系的描述，相对于硬件或软件依赖关系而为缺失的改变检查每个改变集；以及
如果所述改变集不满足基础设施组件依赖关系，则向所述改变集添加补充改变。
4.如权利要求1所述的方法，进一步包括：
在当VM支持子系统中的资源从旧版本升级到新版本时的所述迭代过程的迭代中，将若干VM从计算主机的旧分区迁移到与所述旧分区不兼容的新分区，其中所述VM支持子系统包括以下中的一个或多个：管理程序、存储和控制器。
5.如权利要求4所述的方法，进一步包括：
基于有资格托管所述VM的新版本的计算主机的数量和为所述迭代期间所述VM的新版本的缩放和失败转移而预留的计算主机的数量，计算所述迭代中要迁移的VM的数量。
6.如权利要求4所述的方法，进一步包括：
根据对所述VM的反关联性分组要求，在所述迭代的多个子迭代中迁移所述VM。
7.如权利要求4所述的方法，进一步包括：
创建由所述计算主机的所述新分区托管的所述新版本的资源组成的所述VM支持子系统的新配置；以及
在所述计算主机的所述旧分区中并行维持所述旧版本的资源的所述当前配置，直到与所述新版本兼容的所有VM都从所述旧分区迁移到所述新分区。
8.如权利要求1所述的方法，进一步包括：
在所述升级操作期间，仅当所述系统中的现有资源不满足所述SLA要求时，才向所述系统添加附加资源。
9.如权利要求1所述的方法，其中，在所述迭代过程的每次迭代中，标识所述一批一个或多个资源组进一步包括：
基于所述系统中的依赖关系、所述系统的当前状态以及所述升级操作的排序，从与剩余改变关联的资源中消除不合格资源，以获得初始批资源；以及
从所述初始批中选择最后批资源作为所标识批，其中所述初始批中的剩余资源在所述迭代期间不升级，以由此处置所述迭代期间的潜在的向外缩放请求和潜在的失败。
10.如权利要求1所述的方法，其中，所述资源包括计算资源、存储资源和网络资源的组合。
11.如权利要求1所述的方法，其中，所述恢复操作包括以下中的一个或多个：重试操作和撤销操作。
12.如权利要求1所述的方法，其中，所述升级请求包括可彼此独立应用的改变集的集合，并且每个改变集包含相关改变，所述方法包括：
将给定改变集应用在对应于所述给定改变集的目标资源的撤销单元上；以及
如果所述给定改变集中的改变不能成功地应用于所述撤销单元中的目标资源，则复原所述给定改变集的已执行改变对所述撤销单元的影响。
13.如权利要求12所述的方法，其中，每个改变集被提供有一组重试参数，所述重试参数被用于确定来自所述改变集的改变是否能被成功地应用于资源，所述一组重试参数包括以下中的一个或多个：
最大重试阈值，其指定用于将来自所述改变集的改变应用于所述资源的重试尝试的最大数量；以及
最大完成期，其指定分配来完成所述改变集中所有改变的最大时间。
14.如权利要求12所述的方法，其中，每个改变集被提供有一组撤销参数，所述一组撤销参数包括以下中的一个或多个：
撤销版本，其指定当复原所述改变集对资源的影响时所述资源的版本；以及
撤销阈值，其指示在将所述改变集中的改变应用于所述撤销单元之后所述撤销单元中操作资源的所需数量。
15.如权利要求12所述的方法，进一步包括：
当在所述当前迭代中所述给定改变集中的改变不能成功地应用于所述撤销单元中的所述目标资源时，在下一迭代中自动地将所述给定改变集重新应用在所述撤销单元上。
16.一种用于选择升级方法以处置从提供基础设施即服务（IaaS）的系统的当前配置到升级的配置的迭代升级过程期间的资源的潜在不兼容性的方法，包括：
将具有所述潜在不兼容性的资源指配给相同升级单元，并将可兼容资源指配给不同升级单元；
至少部分基于所述升级单元中的资源之间的依赖关系的类型，选择每个升级单元的升级方法；以及
在所述迭代升级过程的每次迭代中升级一个或多个升级单元，其中每个升级单元在单次迭代中升级。
17.如权利要求16所述的方法，其中，选择每个升级单元的所述升级方法基于若干因素，所述若干因素包括以下中的一个或多个：
所述资源之间是否存在不兼容性，所述潜在不兼容性是否在具有对等依赖关系、赞助依赖关系或通信依赖关系的资源之间，所述通信依赖关系是否具有远程链路管理，以及是否有多于两个的组成资源参与到所述升级单元中的聚合依赖关系。
18.如权利要求16所述的方法，其中，所述升级方法是以下中之一：
拆分模式方法、不具有远程链路管理的第一修改拆分模式方法、具有远程链路管理的第二修改拆分模式方法、具有多个组成资源的第三修改拆分模式、部分并行全域方法和滚动升级方法。
19.如权利要求18所述的方法，其中：
所述拆分模式方法将升级单元的资源分成两个分区，所述两个分区包括第一分区和在所述第一分区之后升级的第二分区，并且所述两个分区中只有一个是活动的，直到所述两个分区两者都被升级，
所述第一修改拆分模式方法和所述第二修改拆分模式方法进一步将所述第二分区分成两个或更多分区，以在单独的分区中保持通信相关和赞助商资源，
所述第一修改拆分模式方法控制去激活和激活不兼容版本的资源的顺序，
所述第二修改拆分模式方法控制去激活和激活不兼容版本的资源之间的通信链路的顺序，
所述第三修改拆分模式方法将每个组成资源放置在单独的分区中，以及
所述滚动升级方法一次升级一个或多个升级单元，而其他升级单元提供所述系统的服务，所述升级单元中的每个包含单个资源。
20.如权利要求16所述的方法，其中，指配给升级单元的所述资源排除所述系统中的虚拟机（VM）。
21.一种网络节点，包括：
处理电路；以及
存储指令的存储器，所述指令由所述处理电路可执行以在迭代过程中升级提供基础设施即服务（IaaS）的系统中的资源，所述网络节点可操作以：
接收升级请求，所述升级请求指示对所述系统的当前配置的所请求改变；
响应于所述升级请求，创建所述当前配置和所请求改变的一个或多个图表示，所述一个或多个图表示包括控制图，所述控制图具有各自表示一个或多个资源的资源组的顶点和表示所述资源组之间的依赖关系的边；
基于所述依赖关系和包括所述系统的可用性和弹性的服务级协定（SLA）要求，从所述资源组中标识要在当前迭代中升级的一批一个或多个资源组；
使用选择的一种或多种升级方法对所标识批执行升级操作，所述升级方法处置所述系统的所述当前配置和升级的配置之间的转变期间的潜在不兼容性；以及
响应于失败的升级操作的反馈，迭代地更新所述一个或多个图表示以包括任何新请求的改变和恢复操作，标识要在下一迭代中升级的下一批一个或多个资源组，以及升级剩余的一个或多个资源组。
22.如权利要求21所述的网络节点，其中，创建所述一个或多个图表示进一步包括：
响应于所述升级请求，创建资源图作为所述资源、所述资源之间的依赖关系和所请求改变的表示；以及
通过基于所述依赖关系和要执行的升级方法收缩所述资源图来形成所述控制图。
23.如权利要求21所述的网络节点，其中，所述升级请求包括可彼此独立应用的改变集的集合，并且每个改变集包含相关改变，所述方法包括：
根据基础设施组件依赖关系的描述，相对于硬件或软件依赖关系而为缺失的改变检查每个改变集；以及
如果所述改变集不满足基础设施组件依赖关系，则向所述改变集添加补充改变。
24.如权利要求21所述的网络节点，进一步包括：
在当VM支持子系统中的资源从旧版本升级到新版本时的所述迭代过程的迭代中，将若干VM从计算主机的旧分区迁移到与所述旧分区不兼容的新分区，其中所述VM支持子系统包括以下中的一个或多个：管理程序、存储和控制器。
25.如权利要求24所述的网络节点，进一步包括：
基于有资格托管所述VM的新版本的计算主机的数量和为所述迭代期间所述VM的新版本的缩放和失败转移而预留的计算主机的数量，计算所述迭代中要迁移的VM的数量。
26.如权利要求24所述的网络节点，进一步包括：
根据对所述VM的反关联性分组要求，在所述迭代的多个子迭代中迁移所述VM。
27.如权利要求24所述的网络节点，进一步包括：
创建由所述计算主机的所述新分区托管的所述新版本的资源组成的所述VM支持子系统的新配置；以及
在所述计算主机的所述旧分区中并行维持所述旧版本的资源的所述当前配置，直到与所述新版本兼容的所有VM都从所述旧分区迁移到所述新分区。
28.如权利要求21所述的网络节点，进一步包括：
在所述升级操作期间，仅当所述系统中的现有资源不满足所述SLA要求时，才向所述系统添加附加资源。
29.如权利要求21所述的网络节点，其中，在所述迭代过程的每次迭代中，标识所述一批一个或多个资源组进一步包括：
基于所述系统中的依赖关系、所述系统的当前状态以及所述升级操作的排序，从与剩余改变关联的资源中消除不合格资源，以获得初始批资源；以及
从所述初始批中选择最后批资源作为所标识批，其中所述初始批中的剩余资源在所述迭代期间不升级，以由此处置所述迭代期间的潜在的向外缩放请求和潜在的失败。
30.如权利要求21所述的网络节点，其中，所述资源包括计算资源、存储资源和网络资源的组合。
31.如权利要求21所述的网络节点，其中，所述恢复操作包括以下中的一个或多个：重试操作和撤销操作。
32.如权利要求21所述的网络节点，其中，所述升级请求包括可彼此独立应用的改变集的集合，并且每个改变集包含相关改变，所述方法包括：
将给定改变集应用在对应于所述给定改变集的目标资源的撤销单元上；以及
如果所述给定改变集中的改变不能成功地应用于所述撤销单元中的目标资源，则复原所述给定改变集的已执行改变对所述撤销单元的影响。
33.如权利要求32所述的网络节点，其中，每个改变集被提供有一组重试参数，所述重试参数被用于确定来自所述改变集的改变是否能被成功地应用于资源，所述一组重试参数包括以下中的一个或多个：
最大重试阈值，其指定用于将来自所述改变集的改变应用于所述资源的重试尝试的最大数量；以及
最大完成期，其指定分配来完成所述改变集中所有改变的最大时间。
34.如权利要求32所述的网络节点，其中，每个改变集被提供有一组撤销参数，所述一组撤销参数包括以下中的一个或多个：
撤销版本，其指定当复原所述改变集对资源的影响时所述资源的版本；以及
撤销阈值，其指示在将所述改变集中的改变应用于所述撤销单元之后所述撤销单元中操作资源的所需数量。
35.如权利要求32所述的网络节点，进一步包括：
当在所述当前迭代中所述给定改变集中的改变不能成功地应用于所述撤销单元中的所述目标资源时，在下一迭代中自动地将所述给定改变集重新应用在所述撤销单元上。
36.一种网络节点，包括：
处理电路；以及
存储指令的存储器，所述指令由所述处理电路可执行以选择升级方法来处置从提供基础设施即服务（IaaS）的系统的当前配置到升级的配置的迭代升级过程期间的资源的潜在不兼容性，所述网络节点可操作以：
将具有所述潜在不兼容性的资源指配给相同升级单元，并将可兼容资源指配给不同升级单元；
至少部分基于所述升级单元中的资源之间的依赖关系的类型，选择每个升级单元的升级方法；以及
在所述迭代升级过程的每次迭代中升级一个或多个升级单元，其中每个升级单元在单次迭代中升级。
37.如权利要求36所述的网络节点，其中，选择每个升级单元的所述升级方法基于若干因素，所述若干因素包括以下中的一个或多个：
所述资源之间是否存在不兼容性，所述潜在不兼容性是否在具有对等依赖关系、赞助依赖关系或通信依赖关系的资源之间，所述通信依赖关系是否具有远程链路管理，以及是否有多于两个的组成资源参与到所述升级单元中的聚合依赖关系。
38.如权利要求36所述的网络节点，其中，所述升级方法是以下中之一：
拆分模式方法、不具有远程链路管理的第一修改拆分模式方法、具有远程链路管理的第二修改拆分模式方法、具有多个组成资源的第三修改拆分模式、部分并行全域方法和滚动升级方法。
39.如权利要求38所述的网络节点，其中：
所述拆分模式方法将升级单元的资源分成两个分区，所述两个分区包括第一分区和在所述第一分区之后升级的第二分区，并且所述两个分区中只有一个是活动的，直到所述两个分区两者都被升级，
所述第一修改拆分模式方法和所述第二修改拆分模式方法进一步将所述第二分区分成两个或更多分区，以在单独的分区中保持通信相关和赞助商资源，
所述第一修改拆分模式方法控制去激活和激活不兼容版本的资源的顺序，
所述第二修改拆分模式方法控制去激活和激活不兼容版本的资源之间的通信链路的顺序，
所述第三修改拆分模式方法将每个组成资源放置在单独的分区中，以及
所述滚动升级方法一次升级一个或多个升级单元，而其他升级单元提供所述系统的服务，所述升级单元中的每个包含单个资源。
40.如权利要求36所述的网络节点，其中，指配给升级单元的所述资源排除所述系统中的虚拟机（VM）。
CN201980065043.9A 2018-08-06 2019-07-24 云升级的管理的自动化 Pending CN112753017A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201862714917P 2018-08-06 2018-08-06
US62/714917 2018-08-06
US201962864096P 2019-06-20 2019-06-20
US62/864096 2019-06-20
PCT/IB2019/056340 WO2020031011A1 (en) 2018-08-06 2019-07-24 Automation of management of cloud upgrades

Publications (1)

Publication Number Publication Date
CN112753017A true CN112753017A (zh) 2021-05-04

Family

ID=68051849

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201980065043.9A Pending CN112753017A (zh) 2018-08-06 2019-07-24 云升级的管理的自动化

Country Status (4)

Country Link
US (1) US11886917B2 (zh)
EP (1) EP3834085A1 (zh)
CN (1) CN112753017A (zh)
WO (1) WO2020031011A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116781519A (zh) * 2023-08-23 2023-09-19 北京中电普华信息技术有限公司 系统升级方法及装置、存储介质及电子设备

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11907742B2 (en) 2020-04-02 2024-02-20 Vmware, Inc. Software-defined network orchestration in a virtualized computer system
US11561821B1 (en) * 2020-05-07 2023-01-24 Amazon Technologies, Inc. Controlling placement of virtualized resources based on desirability index for host pools
US20220004417A1 (en) * 2020-07-01 2022-01-06 Vmware, Inc. Logical network platform install and upgrade in a virtualized computer system
US11356382B1 (en) * 2020-09-30 2022-06-07 Amazon Technologies, Inc. Protecting integration between resources of different services using service-generated dependency tags
US11269620B1 (en) 2020-11-19 2022-03-08 Sap Se Zero downtime upgrade through delta deployment procedure using target software stack
US11237821B1 (en) * 2020-11-19 2022-02-01 Sap Se Configuring zero-downtime upgrades using automated development and test analysis
US11516094B2 (en) * 2020-12-03 2022-11-29 International Business Machines Corporation Service remediation plan generation

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020087734A1 (en) * 2000-12-29 2002-07-04 Marshall Donald Brent System and method for managing dependencies in a component-based system
US20040177244A1 (en) * 2003-03-05 2004-09-09 Murphy Richard C. System and method for dynamic resource reconfiguration using a dependency graph
US20120079502A1 (en) * 2010-09-27 2012-03-29 Microsoft Corporation Dependency-ordered resource synchronization
US9361092B1 (en) * 2015-03-09 2016-06-07 International Business Machines Corporation Recommending upgrade actions during migration
WO2017130030A1 (en) * 2016-01-29 2017-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Rolling upgrade with dynamic batch size
US20170371650A1 (en) * 2016-06-24 2017-12-28 Vmware, Inc. Upgrade analysis of a computer system
US20180067736A1 (en) * 2016-09-07 2018-03-08 Amplidata N.V. Outdated Resource Handling and Multiple-Version Upgrade of Cloud Software

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060130042A1 (en) * 2004-12-15 2006-06-15 Dias Daniel M Method and apparatus for dynamic application upgrade in cluster and grid systems for supporting service level agreements
US7814495B1 (en) * 2006-03-31 2010-10-12 V Mware, Inc. On-line replacement and changing of virtualization software
US8966474B2 (en) * 2007-04-30 2015-02-24 Hewlett-Packard Development Company, L.P. Managing virtual machines using shared image
US8434077B2 (en) 2007-10-18 2013-04-30 International Business Machines Corporation Upgrading virtual resources
US9141381B2 (en) * 2008-10-27 2015-09-22 Vmware, Inc. Version control environment for virtual machines
US8489753B2 (en) * 2009-07-20 2013-07-16 Hewlett-Packard Development Company, L.P. Apparatus and computer-implemented method for controlling migration of a virtual machine
US20120102480A1 (en) * 2010-10-20 2012-04-26 Microsoft Corporation High availability of machines during patching
US8910156B1 (en) * 2011-04-29 2014-12-09 Netapp, Inc. Virtual machine dependency
US8862927B2 (en) * 2011-08-09 2014-10-14 Symantec Corporation Systems and methods for fault recovery in multi-tier applications
US9626223B2 (en) * 2011-10-28 2017-04-18 Hewlett Packard Enterprise Development Lp Provisioning IaaS services
US8881136B2 (en) 2012-03-13 2014-11-04 International Business Machines Corporation Identifying optimal upgrade scenarios in a networked computing environment
US9459856B2 (en) 2013-01-02 2016-10-04 International Business Machines Corporation Effective migration and upgrade of virtual machines in cloud environments
US9141487B2 (en) * 2013-01-15 2015-09-22 Microsoft Technology Licensing, Llc Healing cloud services during upgrades
US9304793B2 (en) * 2013-01-16 2016-04-05 Vce Company, Llc Master automation service
GB2510874B (en) * 2013-02-15 2020-09-16 Ncr Corp Server system supporting remotely managed IT services
US20160364258A1 (en) * 2014-03-06 2016-12-15 Telefonaktiebolaget Lm Ericsson (Publ) Method for generating upgrade campaigns to upgrade virtualization facilities
US9336039B2 (en) * 2014-06-26 2016-05-10 Vmware, Inc. Determining status of migrating virtual machines
US20160099847A1 (en) * 2014-10-02 2016-04-07 Cisco Technology, Inc. Method for non-disruptive cloud infrastructure software component deployment
US9778926B2 (en) * 2014-10-30 2017-10-03 Google Inc. Minimizing image copying during partition updates
CN104572179B (zh) * 2014-12-19 2018-02-23 华为技术有限公司 一种基础设施即服务软件升级方法和装置
US10320892B2 (en) 2015-01-02 2019-06-11 Microsoft Technology Licensing, Llc Rolling capacity upgrade control
JP2016170669A (ja) * 2015-03-13 2016-09-23 富士通株式会社 負荷分散機能配備方法、負荷分散機能配備装置および負荷分散機能配備プログラム
US9680965B2 (en) * 2015-04-01 2017-06-13 Alcatel-Lucent Usa Inc. Software upgrades for offline charging systems within a network
US10268470B2 (en) 2016-08-26 2019-04-23 Nicira, Inc. Method and system for tracking progress and providing fault tolerance in automated upgrade of a network virtualization platform
US20180241617A1 (en) 2017-02-22 2018-08-23 Microsoft Technology Licensing, Llc System upgrade management in distributed computing systems
JP6987158B2 (ja) * 2017-06-09 2021-12-22 テレフオンアクチーボラゲット エルエム エリクソン（パブル） インフラストラクチャアップグレードを、ホストされるアプリケーション／仮想ネットワーク機能（ｖｎｆ）と協調させるための方法
US10782949B2 (en) * 2018-01-08 2020-09-22 International Business Machines Corporation Risk aware application placement modeling and optimization in high turnover DevOps environments
US10083059B1 (en) * 2018-03-19 2018-09-25 Capital One Services, Llc Method and system of hydrating of virtual machines

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020087734A1 (en) * 2000-12-29 2002-07-04 Marshall Donald Brent System and method for managing dependencies in a component-based system
US20040177244A1 (en) * 2003-03-05 2004-09-09 Murphy Richard C. System and method for dynamic resource reconfiguration using a dependency graph
US20120079502A1 (en) * 2010-09-27 2012-03-29 Microsoft Corporation Dependency-ordered resource synchronization
US9361092B1 (en) * 2015-03-09 2016-06-07 International Business Machines Corporation Recommending upgrade actions during migration
WO2017130030A1 (en) * 2016-01-29 2017-08-03 Telefonaktiebolaget Lm Ericsson (Publ) Rolling upgrade with dynamic batch size
US20170371650A1 (en) * 2016-06-24 2017-12-28 Vmware, Inc. Upgrade analysis of a computer system
US20180067736A1 (en) * 2016-09-07 2018-03-08 Amplidata N.V. Outdated Resource Handling and Multiple-Version Upgrade of Cloud Software

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116781519A (zh) * 2023-08-23 2023-09-19 北京中电普华信息技术有限公司 系统升级方法及装置、存储介质及电子设备
CN116781519B (zh) * 2023-08-23 2024-02-23 北京中电普华信息技术有限公司 系统升级方法及装置、存储介质及电子设备

Also Published As

Publication number Publication date
EP3834085A1 (en) 2021-06-16
US11886917B2 (en) 2024-01-30
US20210165694A1 (en) 2021-06-03
WO2020031011A1 (en) 2020-02-13

Similar Documents

Publication Publication Date Title
CN112753017A (zh) 云升级的管理的自动化
US10496503B2 (en) Healing cloud services during upgrades
US10754694B2 (en) Rolling upgrade with dynamic batch size
US10116735B2 (en) Service migration across cluster boundaries
KR20190041033A (ko) 서비스의 2차 위치에서의 작업의 재생 기법
CN111897558A (zh) 容器集群管理系统Kubernetes升级方法和装置
US10949111B2 (en) Updating operating system images of inactive compute instances
US20210089379A1 (en) Computer system
US11620121B1 (en) Controlling the approval of software updates for computing resources
CN112434008A (zh) 分布式数据库升级方法、设备及介质
US11295018B1 (en) File system modification
EP3316518A1 (en) Method and device for upgrading virtual network element, and computer storage medium
US20230229478A1 (en) On-boarding virtual infrastructure management server appliances to be managed from the cloud
CN115277398A (zh) 一种集群的网络配置方法和装置
US9798571B1 (en) System and method for optimizing provisioning time by dynamically customizing a shared virtual machine
EP3340048A1 (en) System and method for content - application split
US11461131B2 (en) Hosting virtual machines on a secondary storage system
Nabi et al. Rolling upgrade with dynamic batch size for iaas cloud
CN115277813B (zh) 超融合集群主机资源控制方法、系统、设备和可读介质
Nabi et al. An Approach for the Automation of IaaS Cloud Upgrade
US20240020108A1 (en) Cluster partition handling during upgrade of a highly available application hosted in a data center
CN115604101B (zh) 系统管理方法及相关设备
US11303562B1 (en) Dynamic high-availability architecture
US20230106414A1 (en) Managing updates to hosts in a computing environment based on fault domain host groups
CN109542588B (zh) 一种用于在云环境下管理虚拟设备的方法和装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination