用于所选择的虚拟机复制和虚拟机重新启动的方法和系统的制作方法
【技术领域】
[0001] 本发明的实施例一般涉及信息技术，更具体地，涉及虚拟机（VM)管理。
【背景技术】
[0002] 故障恢复场景在VM管理的背景下提出了很多挑战。VM和/或服务的高可用性和 灾难恢复可通过复制和/或重新启动成为可能。中央处理单元（CPU)、内存和存储器可以都 被包括在复本中。云中的VM的完全复制需要所有被复制的VM的CPU、内存状态和存储器， 这将产生高的开销成本。因此，需要选择特定的一组VM以在故障恢复场景中复制以减小开 销成本。
[0003] 另外，当资源不充足时，并非所有的故障VM都可以被重新启动。而且，当资源充足 时，由于计算资源将可能造成瓶颈，因此，重新启动所有故障VM可能花费很长时间。因此， 需要选择特定的一组VM以比系统中的其它VM更早重新启动。
【发明内容】
[0004] 在本发明的一个方面中，提供了用于所选择的VM复制和VM重新启动的技术。典型 的计算机实现的方法可包括以下步骤：在识别系统中包括多个VM的集合中的一个或多个 故障VM之前，从该包括多个VM的集合中选择将被复制的包括一个或多个VM的子集；在识 别包括多个VM的集合中的一个或多个故障VM之前，复制包括一个或多个VM的子集；在识 别系统中包括多个VM的集合中的一个或多个故障VM后，选择将被重新启动的包括所识别 的一个或多个故障VM的子集；以及在识别包括多个VM的集合中的一个或多个故障VM后， 重新启动包括所识别的一个或多个故障VM的子集。
[0005] 本发明或其要素的另一方面可以采用有形地体现计算机可读指令的制造品的形 式实现，其中该计算机可读指令在实现时使计算机执行如在此所描述的多个方法步骤。另 夕卜，本发明或其要素的另一方面可以采用包括存储器和至少一个耦合到存储器并被配置为 执行所指明的方法步骤的处理器的装置的形式实现。更进一步地，本发明或其要素的另一 方面可以采用用于执行在此描述的方法步骤的装置或其要素的形式实现；该装置可以包括 硬件模块或硬件和软件模块的组合，其中软件模块被存储在有形的计算机可读存储介质中 (或多个这种介质中）。
[0006] 本发明的这些和其它目的、特性和优点将从以下的本发明的说明性实施例的具体 描述中变得明显，其将结合附图一起阅读。
【附图说明】
[0007] 图1是示出根据本发明的实施例的示例实施例的示意图；
[0008] 图2是示出根据本发明的实施例的示例实施例的示意图；
[0009] 图3是示出根据本发明的实施例的技术的流程图；
[0010] 图4是示出根据本发明的实施例的技术的流程图；
[0011]图5是示出其上可实现本发明的至少一个实施例的典型计算机系统的系统图。
【具体实施方式】
[0012] 如在此所描述的，本发明的一个方面包括在增强具有相互依赖的组件的服务的可 用性中用于所选择的VM复制和VM重新启动的技术。例如，本发明的至少一个实施例包括 所选择的VM复制，其可以是主动式（proactive)的（S卩，包括在故障前采取的措施）。在这 种实施例中，一定数量的空闲资源被留出，并选择将要在空闲资源中被复制的VM集合以在 发生故障时最大化服务值。在本发明的至少一个实施例中，这些资源在应用或云系统执行 之前和/或应用或云系统执行时被用户或系统管理员留出。这种实施例中的复制因子是可 配置的。被留出作为空闲资源的资源的百分比也是可配置的，并可基于用于复制的资源开 销与可用性增强之间的权衡。
[0013] 另外，本发明的至少一个实施例包括所选择的VM重新启动，其可以是反应式的 (即，包括当故障VM没有复本时在故障后采取的措施）。在这种实施例中，选择将被重新启 动的故障VM的集合以在计算能力（如果需要，还包括用于镜像复制的网络带宽容量）的约 束下最大化服务值。
[0014] 在所选择的VM复制和/或所选择的VM重新启动中，VM组可以被形成和/或被识 别以遵守复合应用中共同有助于服务的提供的VM之间的依赖关系。根据本发明的一个或 多个实施例，选择用于复制和/或重新启动的VM可以在多个环境内执行。例如，在一个这 种环境中，每一个VM在组中对于服务的提供都是同等重要的。另外，在另一个这种环境中， 每一个VM在组内对于服务的提供都被分配一个权重。另外，本发明的至少一个实施例包括 基于有关应用的企业优先级和单独VM的故障行为的组合信息而从组中选择有故障倾向的 VM以用于复制。
[0015] 图1是示出根据本发明的实施例的示例实施例的示意图。举例说明，图1描绘了 由用户和/或云提供者设置的服务水平协议（SLA) 102,其可基于和/或来源于包括可用性 SLA、商业或企业值和/或优先级、VM类型、性能SLA(诸如响应时间，吞吐量等）、管理员指 定的计算方法等因素。SLA102被提供给服务值估计引擎104,其与所选择的复制/重新启 动引擎（SR2引擎）106进行交互。服务值估计引擎104通过按照由用户和/或系统管理员 指定的公式从诸如以上所列出的因素中计算服务值。
[0016] 在常态行为期间，在系统中没有故障，服务值估计引擎104向（SR2引擎106的）所 选择的复制组件107提供输入，所选择的复制组件107利用该输入以确定哪个VM应当在空 闲资源中复制。然后，如果发生VM的故障，则所选择的复制组件107确定是否所有的故障 VM都有复本可用；如果复本可用，则该复本成为故障VM的主用VM;如果任意一个复本不可 用，则那些具有可用复本的故障VM使得它们的复本成为主用VM，而那些没有可用复本的故 障VM被（SR2引擎106的）所选择的重新启动组件109重新启动。该过程被表示为图1中 在所选择的复制组件107和所选择的重新启动组件109的右侧的两个箭头。
[0017] 在所选择的重新启动组件重新启动故障VM期间，服务值估计引擎的输入用于确 定VM的重新启动的优先级和顺序（如通过图1中从服务值估计引擎104到所选择的重新 启动组件109的ft]头表。在所有故障VM被重新启动后，在系统中没有故障，并且系统在 无故障状态下正常执行。然后，所选择的复制组件107重新开始选择哪些VM将被复制的任 务（这通过图1中从所选择的重新启动组件109到所选择的复制组件107的箭头表示）。
[0018] 在本发明的至少一个实施例中，SR2引擎106包括处理服务组件和/或VM之间的 依赖关系的能力。在本发明的至少一个示例实施例中，对于任何运行中的VMV，存在至少一 个v起作用的可用服务。如在此所指出的，用户和服务提供者具有灵活地定义服务值和分 配适当值的能力。
[0019] 如在此详细描述的，本发明的一个或多个实施例的目的是当考虑故障行为时达到 最大服务值。如在此描述的，SR2引擎106的所选择的复制组件107最小化高价值服务故障 的可能性。根据本发明的一个或多个实施例，故障发生在个别VM上而不是一次发生在服务 的所有VM上。另外，VM故障是随机过程，没有必要使服务的所有VM都被复制（除非客户 要求用于灾难恢复（DR)的复制策略）。
[0020] SR2引擎106的所选择的重新启动组件109在任何相关资源约束的背景下最大化 被恢复的服务的值。
[0021] 图2是示出根据本发明的实施例的示例实施例的示意图。举例说明，图2描绘了 SR2引擎106,其从故障检测器组件202接收输入。故障检测器组件202与诸如管理程序 1(H1)204(其包括vmll和vml2)、管理程序2(H2)206(其包括vm21和vm22)和管理程序 3 (H3) 208 (包括m31和vm32)的管理程序进行交互。故障检测器组件202检测VM的任何 故障，并将所检测到的故障通知SR2引擎106。另外，基于由故障检测器组件202提供的输 入，SR2引擎106向相关的管理程序（例如，管理程序204、206和208)提供输入和/或指 令。SR2引擎的所选择的复制组件和所选择的重新启动组件确定哪些VM复本应当被识别为 主用VM和/或哪些VM应当被重新启动，并还请求相关的管理程序执行主用VM识别和VM 重新启动。
[0022] 图3是示出根据本发明的实施例的技术的流程图。步骤302包括使用所选择的复 制算法周期性地选择和复制某些VM。例如，所选择的复制算法可选择VM的集合并复制所选 择的VM的集合。在所选择的复制中可以考虑多个因素，这些因素是用于在图3的流程图中 描绘的架构的值和/或输入。
[0023] 举例说明，假设存在服务路径知识以及哪些服务路径更重要。在本发明的至少一 个实施例中，监控和/或追踪工具可用于此目的。这种知识还可以从用户输入，其表示值分 配阶段。
[0024] 另外，在起点处，假设每个VM至少有主用副本在运行。如果VM发生故障，则步骤 304包括确定故障VM是否有实时（live)复本。如果故障VM有实时复本，则在步骤306中， 该复本成为主用，流程返回流程图的起点。另外，如在此使用的，成为主用（以及其各种类 似表述）表明复本代替故障VM。当复本变成主用时，故障VM不存在。如果故障VM没有复 本，则流程继续到所选择的重新启动阶段（到步骤308)。如在此详细描述的，本发明的至少 一个实施例包括检测VM故障和检测是否有实时复本在运行的检测器。
[0025] 步骤308包括运行所选择的重新启动算法以重新启动故障VM并恢复服务路径。本 发明的至少一个实施例包括最大化所恢复的服务路径的值而尽可能多地满足SLA。该值可 例如包括满足SLA的测量。如果没有可用于重新启动故障VM的资源，则实