CN103995728A - 用于确定何时需要更新云虚拟机的系统和方法 - Google Patents

Abstract

本发明涉及一种用于确定何时需要更新云虚拟机的系统和方法。公开了一种用于基于虚拟机提供计算基础架构的方法（和结构）。一种虚拟机供应系统，当由处理器在网络上执行时：接收虚拟机请求作为输入；从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求；通过供应所选择的虚拟机映像以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及输出所述实例化后的虚拟机。一种映像更新系统基于更新成本而确定更新所述虚拟机映像和所述实例化后的虚拟机中的至少一个的更新计时。

Description

用于确定何时需要更新云虚拟机的系统和方法

技术领域

本发明一般地涉及更新云提供方提供的虚拟机。更具体地说，提供一种用于确定虚拟机服务更新的机制，包括例如确定更新虚拟机实例还是更新用于虚拟机实例化的底层虚拟机映像。

背景技术

云提供方的常规做法是发布一组虚拟机映像，消费者可以将这些映像实例化为云上的特定虚拟机实例，从而导致简化的体验和更快的价值实现。这些映像是虚拟资源、操作系统的组合，并且可能包括一个或多个软件产品。提供方必须确定要提供的最佳映像组，并且必须不断地评估何时需要更新。更新通常以补丁的形式呈现，并且纠正错误或安全漏洞或者引入新功能。

但是，如将解释的，将补丁应用于虚拟机映像所需的复杂性和工作量远高于为虚拟机实例打补丁所需的复杂性和工作量。这可归因于以下风险：不正确地修改配置、中断映像的云供应，或者阻止管理堆栈的正确操作。

如果未将补丁应用于映像，则必须在实例化阶段或者在实例化之后，将补丁应用于该映像的每个实例。该过程导致消耗计算机资源，并且客户可能接收云提供方尚未测试的初始实例。

因此，本发明的发明者认识到云供应领域中的一个新问题，其在于云提供方相对于虚拟机更新做出多个选择，甚至包括选择更新底层虚拟机映像还是更新虚拟机实例。其它更新决策包括确定此类更新的最佳计时（timing），假设云提供方不断地从软件供应方接收更新。

发明内容

鉴于常规系统的以上和其它示例性问题、缺点和劣势，本发明的一个示例性特性是提供一种用于基于与更新关联的成本而进行虚拟机更新决策的结构（和方法）。

本发明的另一个示例性特性是提供一种用于确定更新底层虚拟机映像的成本是否低于更新每个虚拟机实例的成本的方法。

本发明的另一个示例性特性是为云提供方提供一种用于计算虚拟机映像的最长更新时间（maximum update time）的机制。

本发明的另一个示例性特性是为云提供方提供一种用于仅根据当前未决补丁而确定是否需要立即更新映像或实例的机制。

在第一示例性方面，在此描述一种基于虚拟机提供计算基础架构的方法，包括提供由处理器在网络上执行的虚拟机供应系统。所述虚拟机供应系统：接收虚拟机请求作为输入；从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求；通过供应所选择的虚拟机映像以适应所述虚拟机请求以及通过删除和安装软件系统中的至少一个以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及响应于所输入的虚拟机请求而输出所述实例化后的虚拟机。一种映像更新系统基于更新成本而确定更新所述虚拟机映像和所述实例化后的虚拟机中的至少一个的更新计时。

在第二示例性方面，在此还描述一种系统，其包括至少一个处理器和存储设备，所述存储设备用于存储指令程序，所述指令程序允许所述至少一个处理器之一实现和执行一种映像更新方法，所述映像更新方法用于基于更新成本而确定更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的至少一个的更新计时。

在第三示例性方面，在此还描述一种非瞬时性计算机可读存储介质，其有形地包含机器可读指令程序，所述机器可读指令程序可由数字处理装置执行以执行一种实现和执行映像更新方法的方法，所述映像更新方法用于基于更新成本而确定更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的至少一个的更新计时。

附图说明

从以下参考附图的对本发明示例性实施例的详细描述，将更好地理解以上和其它目的、方面和优点，这些附图是：

图1示出本发明的一个示例性实施例的示例性流程图100；

图2示出2010年针对OpenSuSE11.1操作系统发布的补丁的大小和计数的示例性数据200；

图3示出2008年发布的选择IBM中间件修复包的示例性数据300；

图4示出示例性测试结果400，其指示未来更新映像时的平均天数，该平均天数取决于使用映像的请求的被高估的数量；

图5示出示例性测试结果500，其指示更新映像浪费的时间，该时间取决于使用映像的请求的被低估的数量；

图6示出示例性测试结果600，其指示管理员为何可能更喜欢针对更新设置预定的阈值天数；

图7示出示例性测试结果700，其指示在多长时间内未更新映像可以导致浪费大量时间；

图8示出示例性测试结果800，其通过呈现取决于映像更新概率故障的恢复浪费时间，指示应用于映像的错误补丁对实例的后续供应时间的影响；

图9示出将本发明纳入其中的示例性硬件/信息处理系统900；以及

图10示出用于存储根据本发明的方法的程序步骤的非瞬时性信号承载存储介质1000（例如，存储介质）。

具体实施方式

现在参考附图，更具体地说参考图1-10，现在将描述根据本发明的方法和结构的示例性实施例。

为了降低信息技术（IT）资本和运营支出，所有规模的组织都将其应用工作负载移动到云中。云在其具体技术和实现方面变化显著，但全部共享虚拟化作为基本支柱。虚拟化为云提供以下能力：在单个硬件单元中托管多个不同并独立的操作系统运行时。该特性连同可靠的界面（程序设计和/或图形）允许云消费者自由地动态创建和销毁云中的虚拟机实例（称为“云实例”）。

云以多种模型提供计算资源即服务，包括基础架构、平台和软件。基本模型称为基础架构即服务（IaaS），并且为云消费者提供操作系统实例，云消费者能够在这些实例上托管其中间件和应用。使用IaaS，云提供方通常提供一组通用启动映像，这些映像提供有效基础以便实现特定于消费者工作负载的进一步定制。云消费者还可以选择利用共同体构造的映像或者构造它们自己的定制映像。云消费者的目标是找到与其工作负载要求最密切匹配的映像，因此减少与进一步调整关联的手动工作量。

映像的管理和治理变得复杂起来，因为每个个体客户都提出他们自己的独特要求。软件在映像中的流通针对云提供方和云消费者均提出极富挑战性的问题。云消费者或云服务提供方双方都不会受益于过时或不安全的软件版本，因此，发明者认识到需要一种方法以便帮助各方确定应用软件补丁的最适当的频率和方法。本发明解决这种挑战，使云提供方和消费者都受益。

为了更准确地说明本问题，一旦已建立云的映像库，映像所有者就必须不断地监视相关补丁的可用性，并且确定应该更新哪些映像以及紧急程度如何。该活动是在整个操作系统和软件堆栈中应用最新错误、特性和安全补丁必需的。发明者认识到确定何时为映像打补丁很重要，因为必须将为映像打补丁所需的额外复杂性和时间与更新从该映像获得的未来实例的复杂性和时间进行权衡。

因此，本发明可以被视为提供一种用于新认识到的问题的解决方案，该问题涉及云服务提供方的更新。在一个方面，本发明解决以下问题：更新虚拟机实例还是更新在实例化后的虚拟机底层的虚拟机映像。此外，本发明可以用于确定提供下一个更新的最长时间，并且用于基于当前未决补丁而确定是否应立即更新映像。

本发明提供各种算法，这些算法帮助负责映像流通的各方确定在某个时间点，应该使用软件补丁更新哪些映像。在此描述的算法考虑更新映像或在实例化时动态更新每个实例所涉及的成本的若干方面。可以根据来自生产数据中心的历史请求数据来评估算法。

这些算法可以用于基于生产数据中心中实际经历的实例化请求频率和未完成补丁而标识何时应该更新映像。测试结果确定对映像实例化请求的预测对于以下操作至关重要：当考虑资源成本、错误补丁的风险以及为所有后续实例打补丁的成本时，确定映像可以保持不打补丁的时间长度。

更新映像面临的挑战

首先并且如所属技术领域很容易理解的，通过在多个托管资源之上提供层管理来构造云，这些托管资源能够快速并且动态地响应云管理的请求。虚拟化是行业标准技术，其允许对备用物理托管资源进行最有效的分区。

虚拟机（VM）是虚拟化后的主机的逻辑分区。在云的上下文中，VM在以下讨论中称为“云实例”或简称“实例”。实例为组织的应用基础架构提供基本构件。与传统的数据中心一样，各种更高级的软件系统（例如，代理、中间件和应用）具有特定的要求，这些要求从资源（例如，CPU、存储器、磁盘）和软件角度（例如，OS类型、版本、配置、中间件）推动对各种实例配置的需要。

因此，出于呈现本发明概念的目的，云可以被视为基于虚拟机的计算基础架构，并且云服务是通过诸如因特网之类的网络使得这种计算基础架构可用于消费者的方法或实体。

通用的虚拟化实践是将这些资源和软件组合保存到可重用的软件包（称为“映像”）。因此，映像能够作为新实例的基础而重复使用，并且导致提高供应性能以及增加生成的实例配置的一致性。可以在云中选择的映像的可访问性、多样性和质量为云提供方提供主要的独特优势，为云消费者提供增加的吸引力。

一个此类实例是Amazon在其“非受管”IaaS弹性计算云（EC2）中创建的活跃社区（active community），其中个体、第三方供应商和Amazon本身贡献Amazon机器映像（AMI）以供所有EC2消费者使用。云消费者自由搜索AMI库并选择与其应用要求最匹配的映像。

活跃映像管理是降低复杂性所需的，并且确保云提供方和消费者从映像获得最大利益。例如，将描述的一种主要复杂性是需要权衡将补丁（例如，用于错误、安全性、特性）应用于映像的成本与在供应每个新实例期间动态应用补丁的成本。因为还将讨论其它更新问题和选项，所以本发明应该被视为一种总体上以考虑各种更新成本的方式提供要由云提供方实现的虚拟机更新的机制。

A.映像以及受管与非受管云

另一个云识别层以受管或非受管云服务的形式呈现。非受管云服务提供基础架构，并且依赖于消费者为其实例执行全天候管理活动。在受管云服务中，提供方超越实例-系统管理程序障碍，并且提供诸如性能监视、可用性监视、许可管理和补丁管理之类的传统服务。受管服务水平针对实例施加其它条件和约束，必须满足这些条件和约束以便继续获得利益。例如，如果云消费者要卸载监视代理，则他们很可能使其服务水平协议无效。

受管云模型中的映像实例化通常远比非受管云的映像实例化复杂。必须通过完成供应和随后向消费者发布实例，实现受管云实施的其它代理和安全策略。这些项目通常遍布映像和用于创建实例的代码。例如，可以在符合受管云的映像中捕获操作系统安全设置，并且可以在供应时通过代码完成安装监视代理和向监视基础架构注册。从打补丁的角度看，显然管理代理的功能和负责实例化映像的代码都对补丁引入的任何更改敏感。

图1示出常见情形100，其中应用所有者定义支持他/她的特定应用所需的配置（结果是请求101）。然后必须选择云映像（102）以便充当请求的基础，其中考虑操作系统以及任何其它所需的软件组件或配置。然后实例化所选择的映像（103）并且执行动态修改（104），以便安装缺少的软件或者卸载不必要的软件（例如，由于许可问题）。

这是过程中用于应用任何未完成的操作系统或软件补丁的固有点，因为在该点，实例与原始请求更密切匹配并且还包含最新补丁。但是，在实例化点的这种更新将花费时间，并且不便于消费者立即实例化虚拟机，因此更新底层映像而不是每次均实例化可能成本较低。

图1示出虚拟机供应系统105，其允许客户端请求和实例化虚拟机。图1还示出云提供方基础架构的另一个重要组件，该组件是映像更新系统106，提供它用作本发明的组件。该组件106负责从软件维护者处接收有关已经发布哪个补丁以及该补丁用途的信息107。该信息以及对未来实例请求的预测108和在此描述的各种算法能够使云提供方确定（109）更新管理决策，例如为映像打补丁（110）何时好于允许安装补丁作为供应的最终步骤（111）。

作为管理虚拟机更新的一个方面，该信息可以通过考虑为每个实例打补丁的成本与为映像打补丁的成本，指导云和映像管理员定义最低成本补丁计划。显然，随着补丁数量的累积，安装时间增加，并且破坏映像或管理代理的合规性的风险也增加。以下部分讨论更新映像与实例面临的挑战的某些主要差异。

B.更新实例和映像的差异

将补丁应用于操作系统或软件块的过程需要从提供方处获取补丁，评估相关性和依赖性，并且最后应用补丁以便修改现有的已安装文件。可能需要重新引导以便激活和验证补丁引入的更改。

此时，注意更新实例或映像可以是完全自动的，或者可以包括来自管理员的手动输入，具体取决于补丁的性质。可以在接收软件补丁时很容易地确定这些特征。在此描述的算法本身在其计算中考虑自动和/或手动更新方面，如通过与每个更新关联的成本所标识的那样。

下面的示例性算法1定义更新映像所需的典型步骤，这些步骤对于单个补丁而言可以相当复杂并且耗时。该算法考虑离线和在线打补丁技术。离线提供以下能力：在不实例化静止映像的情况下为该映像打补丁。在线需要实例化映像并且可通过传统的连接方法访问映像。

算法1：更新映像的过程：

Input:patchList

imageList←cloud.getImpactedImages(patchList)

foreach image in imageList do

if offline patch required then

mount image

apply offline patches

run unit tests

unmount image

if online patch required then

instantiate the image

apply online patches

if reboot required then

reboot

run unit tests

reset/generalize image

shutdown

convert to image

publish to image library

在受管云环境中，重要的是遵循该过程以便降低错误映像进入云系统的风险。发布错误映像可导致多个问题，包括：

·供应故障，由于映像未满足供应代码的要求而导致；

·实例化之后的合规性故障；

·一个或多个管理代理故障，从而危及提供方支持服务水平的能力；以及

·消费者接收无功能的实例。

在下面提供的示例性算法2中概述更新实例的过程。该过程类似于用于映像的过程，但风险降低的对象从云提供方转移到消费者，并且最终转移到应用所有者。当处理初始供应时，云消费者主要专注于快速获得其实例，以便他们可以开始部署其应用。该过程与为已经运行应用的实例打补丁形成对比，后者关注的问题显然是确保应用继续按预期运行，并且确保对于最终用户没有计划外中断。按照该原则，云提供方甚至可以提供一种机制，该机制从最终用户处请求执行更新的权限（在初始实例化之前或者在中断已经部署的实例化之前执行更新），从而为最终用户提供对实例化后的虚拟机的可用性和更新状态的某种程度的控制。

算法2：更新实例的过程：

Input:patchList

instanceList←cloud.getImpactedInstances(patchList)

foreach instance in instanceList do

if instance is offline then

bring instance online

apply online patches

if reboot required then

reboot

if instance was offline then

bring instance offline

performance instance smoke test

notify instance owner of patch results

在两种情形中，无法正确应用补丁的后果很严重，但是从云提供方的角度看，认为在映像情况下应用补丁的成本远高于在实例情况下应用补丁的成本。下一部分概述操作系统和软件中的打补丁频率，以便更好地了解问题的复杂性。

C.补丁发布特征的实例

补丁的分发和特征针对不同的软件类型（例如，操作系统、中间件）和供应商（例如，那些被视为企业任务关键的供应方-爱好开源的供应方）而有所不同。根据安装频率或者在应用拓扑中的位置，某些软件本身的性质使得它们更可能需要发现的补丁。某些产品采用固定计划，其中累积补丁并且以更大的聚合补丁进行应用（例如，用于IBM DB2的修复包）。

其它补丁（如用于Linux分发的那些补丁）频繁发布，这是由于Linux的共同体驱动的性质、分发中的大量软件包以及通过公共软件包管理分发的稳健性所致。下面的表I提供五个版本的OpenSuSE操作系统的补丁统计的汇总。表项“补丁/月”描述每个操作系统版本每个月的总补丁数。

表I

OPENSUSE版本11.1、11.2、11.3、11.4、12.1的汇总补丁统计。

图2示出示例性数据200，其突出补丁到达时间以及包括在时间段中的补丁总大小的波动。当更广泛地检查数据时，每个月平均发布323个补丁，其中最常见的是java，其在版本的生命周期内平均发布219个补丁。补丁大小本身变化很大，中等大小为67KB，而最大大小为115MB。作为一个简单的实践，可以从该图中看到，将映像更新延迟为每月一次（固定计划）将导致可能在实例化期间应用数百MB的补丁。

图3示出示例性数据300，其针对包括应用服务器（IBM WebSphereApplication Server）和数据库服务器（IBM DB2）的更大中间件软件的主要版本的打补丁频率。中间件产品显然显示不同于底层操作系统的模式，但在中间操作系统软件包的发布频率方面类似。通常，根据对来自IBM的15个产品的分析，发明者观察到平均每五个月发布一个补丁，最频繁的发布是每2.5个月一次。每个版本的补丁数量还根据产品的生命周期（所见到的最大数量是23（超过7年））而变化。

最后，通常观察到中间件补丁明显大于操作系统软件包，平均大小达到数百MB。当供应商（例如，IBM）在发布下一个修复包的预计日期之前发布时，补丁的可预测性还会更好。在此，一个主要的区别是软件修复包通常包含许多个体补丁，而操作系统补丁基于个体组件。

映像更新算法

如上一部分中描述的，与更新实例和映像关联的过程和成本完全不同。在此示例性算法中包括这两个方面以便确定何时应更新映像。

算法3：用于确定更新映像的最长时间的伪代码：

Input:reqList,patchList,image

Output:maximumUpdateTime

1iPatchList←patchList.getPatches(image)

2patchICost←iPatchList.getImageCost(image)

3patchRCost←iPatchList.getReqCost(image)

4nReqs←0

5maximumUpdateTime←0

6foreach time unit t do

7maximumUpdateTime←maximumUpdateTime+t

8nReqs←nReqs+reqList.getFutureReqs(image,t)

9if patchICost<nFutureReqs*patchRCost*k then

10return maximumUpdateTime

11return-1

上面的示例性算法3表示用于在需要将一组更新应用于映像时确定最长更新时间的伪代码。该算法可以以固定时间间隔执行，或者在管理系统接收新补丁时动态执行。这缓解对尝试预测未来补丁到达时间的需要。该算法具有以下输入变量：

·reqList：对供应实例的先前请求。每个请求包含所需的操作系统、软件堆栈和其它配置参数；

·patchList：用于下载和应用操作系统和软件更新的描述和链接；

·image：要评估的映像。

该算法首先初始化iPatchList（第1行），这包括patchList中被视为与映像相关的补丁。此后，设置两个更新成本（第2-3行）：patchTCost和patchRCost，它们表示将补丁iPatchList应用于映像以及从该映像供应的实例的成本。

云提供方可以很容易地获得对应用补丁的成本的估计，如在算法3中使用的那样，注意上面的算法1和算法2提供通常用于应用补丁的步骤。因此，根据云提供方自己的操作和过程，云提供方可以很容易地使用有关先前的映像和实例更新的历史数据，以便根据补丁大小或其它相关参数（例如复杂性等），针对任何接收的补丁产生成本估计。

然后在算法3中，根据时间的推进，使用循环将映像和实例更新成本相比较（第6-10行）。该时间t可以是小时、天、周等。针对每次循环迭代，更新未来请求数量nReqs（第8行）。

然后执行测试以便判定更新映像的成本是否低于更新来自该映像的所有未来实例的成本（第9行）。如果成本较低，则返回最长更新时间（第10行）。使用k因数补偿成本可能针对每个供应的实例而改变的事实（第9行）。注意，该因数k还可通过有关更新的历史数据获得，并且提供对于每个云服务提供方而言可能唯一的参数。

值得注意的是，算法3考虑单个映像的评估。但是，一种可能的情形是系统管理员想要知道一组映像的最长更新时间。对于这种情形，可以比较两个额外变量，它们用于存储更新所有映像的总成本以及更新所有实例的总成本，并且当第一个变量低于第二个变量时，返回最长更新时间。

此外，注意可以实现算法3的计算，以便针对云服务提供方自动发生。例如，在图1中示例性地示出的映像更新系统105可以被配置为在接收新更新时不断地更新该计算，并且使这些更新后的计算可用于云服务提供方管理员和/或自动执行适当的更新。

此外，系统管理员可能有兴趣确定是否应该立即更新实例。下面的算法4提供此类答案并且是算法3的变型。在该变型中，算法4可以以预定时间间隔执行或者每当新补丁到达时自动执行。

算法4：用于确定是否需要立即更新映像的伪代码（仅考虑未决补丁）：

Input:reqList,patchList,image,timeInFuture

Output:UpdateNow(Boolean)

1iPatchList←patchList.getPatches(image)

2patchICost←iPatchList.getImageCost(image)

3patchRCost←iPatchList.getReqCost(image)

4nFutureReqs←reqList.getFutReqs(image,timeInFuture)

5if patchICost<nFutureReqs*patchRCost*k then

6return true

7return false

算法4在多个方面不同于算法3。例如，算法3在未来时间范围内评估补丁，这可以有利于实现规划目的。算法4着眼于当前时间，这可以用于以下情况：管理员怀疑算法3生成的预测可能不准确。因此，算法4可以用作算法3的确认机制。此外，如上所述，算法4可以在接收任何新补丁时自动执行，从而可能设置立即更新（无论自动还是手动）。

所属技术领域的普通技术人员应该理解，映像更新算法的原理是：通过预测请求并且使用有关与更新映像或实例关联的成本的信息，可以确定何时应该更新映像。该知识缩短与将补丁应用于映像关联的时间，并且减小对基于映像的未来实例的影响。

在一篇简短描述本发明各个方面的待发布论文中，提供了展示原理合理的实验结果。该论文的内容在此引入作为参考。

但是，无需获得该论文中讨论的有关实验结果的设置和原理的细节，基于对浪费的时间百分比的计算，可以从这些实验结果认识到由本发明产生的多个优点和其它方面。下面的表II示出该评估的实验参数和值的汇总。假设请求的到达时间遵循齐夫（Zipf）分布。

作为一个实例，第一分析考虑对未来请求的预测的准确性。这是关键参数，因为预测的准确性主要取决于数据中心及其工作负载。在该评估中，发明者分析对未来请求数量的高估和低估。

对未来请求的高估。

这是谨慎管理的情形，其中高估未来请求数量的值。高估得越高，需要更新映像的日期就越早。在图4中示出该行为，该图示出未来更新映像时的平均天数（包括标准差条），该平均天数取决于使用映像的请求的被高估的数量。未来更新映像时的天数随着高估而减小，直到它到达某个点，在该点算法确定需要在“下一天”更新映像。因此，如果高估请求，则即使具有很少的请求，也会更频繁地更新映像。

提早映像更新可以浪费大量时间和资源，如图5中所示。该图示出更新映像浪费的时间，该时间取决于使用映像的请求的被低估的数量。可以注意，当高估很高时，类似于天数度量，浪费的时间达到阈值。这可以通过在很低和很高的高估下比较标准差条而观察到。发生这种情况的原因是未来需要更新映像时的天数停止减小，从而更接近于“下一天”现象。结果还示出用于高估的约为10%的公差，以便确定更新映像的最长时间。

对未来请求的低估。

这是更宽松管理的情形，其中低估未来请求数量的值。在这种情况下，低估得越多，更新映像就越晚。在图6中示出该行为，其中示出未来更新映像时的天数，该天数取决于使用映像的请求的被低估的数量。

可以注意与高估情形的差异。在此，低估的变化最多仅达到99%，因为值100%表示没有未来请求。低估与高估的主要差异在于：根据请求到达预测的质量，算法可以确定几个月之后才必需更新。即，对天数的影响非常高，如可以在图6中所示的曲线中观察到的那样。根据这种情形，这可能可接受，但系统管理员可能考虑包括用于更新映像的天数的阈值，因为可以分析随时间的实际更新到达数据，以便确定是否出现不可接受的更新周期。

即，如图7中所示，长时间未更新映像可导致浪费大量时间。该图示出更新实例浪费的时间，该时间取决于使用此类映像的请求的被低估的数量。类似于天数度量，浪费的时间遵循指数曲线，这是由于错误预测极少数请求所致，这导致更新更多的实例，而不是仅更新将生成这些实例的映像。结果还示出用于低估的约为5%的公差，以便确定更新映像的最长时间。

执行错误补丁的风险。

研究的另一个因素是应用于映像的错误补丁对实例的后续供应时间的影响，图8示出恢复浪费时间，其取决于映像更新概率故障。在该评估中，概率从0.5变化为1.0。可以注意，当存在映像更新危及未来实例的高风险时，恢复这些实例的时间可能相当高。考虑使用一天检测由于映像的错误补丁导致的实例错误，获得在此提供的结果。如果检测问题的时间很长并且需要重新创建实例，则恢复浪费时间可能更高并且更昂贵。

按照这些原则，注意算法3和算法4的k因数为每个服务提供方提供一种机制，以便调整和优化在测试本发明概念期间标识的此类参数，如上面讨论的那样。

示例性硬件实现

图9示出根据本发明并且优选地具有至少一个处理器或中央处理单元（CPU）911的信息处理/计算机系统的典型硬件配置900。

CPU911通过系统总线912与以下各项互连：随机存取存储器（RAM）914、只读存储器（ROM）916、输入/输出（I/O）适配器918（用于将诸如磁盘机921和磁带驱动器940之类的外围设备连接到总线912）、用户接口适配器922（用于将键盘924、鼠标926、扬声器928、麦克风932和/或其它用户接口设备连接到总线912）、通信适配器934（用于将信息处理系统连接到数据处理网络、因特网、内联网、个人区域网络（PAN）等）以及显示适配器936（用于将总线912连接到显示设备938和/或打印机939，例如数字打印机等）。读取器/扫描仪941也可以连接到总线912。

除了上面描述的硬件/软件环境之外，本发明的不同方面包括一种用于执行上面方法的计算机实现的方法。作为一个实例，该方法可以在上面讨论的特定环境中实现。

例如可以通过运行由数字数据处理装置体现的计算机而实现这种方法，以便执行一系列机器可读指令。这些指令可以位于各种类型的非瞬时性信号承载存储介质中，其中“信号承载”意味着指令有形地嵌入存储介质中，以便可以认为嵌入介质中的指令与执行指令的机器之间具有功能性。

因此，本发明的这方面涉及编程产品，包括有形地包含机器可读指令程序的非瞬时性信号承载存储介质，所述机器可读指令程序可由包括上面的CPU911和硬件的数字数据处理器执行，以便执行本发明的方法。

该存储介质例如可以包括包含在CPU911中或者与CPU911关联的RAM，例如由快速访问存储装置表示。备选地，指令可以包含在另一个信号承载存储介质中，例如可以直接或间接由CPU911访问的数据存储磁盘1000或光盘1002（图10），这可以被视为用于存储计算机程序指令的独立存储设备。

无论包含在磁盘1000、1002、计算机/CPU911还是其它位置中，指令都可以存储在各种机器可读数据存储介质中，例如DASD存储装置（例如，常规“硬盘驱动器”或RAID阵列）、磁带、电子只读存储器（例如，ROM、EPROM或EEPROM）、光存储器件（例如，CD-ROM、WORM、DVD、数字光学磁带等）、纸质“穿孔”卡或者其它合适的信号承载存储介质，包括传输硬件、通信链路和无线中的存储器件，并且包括不同的格式（例如数字和模拟）。在本发明的一个示例性实施例中，机器可读指令可以包括软件目标代码。

最后，还要注意映像是云中的关键组件，因为根据封装应用所需的整个软件堆栈的映像来供应实例。需要通过定期应用补丁维护这些映像，以便例如避免可以危及客户资源和信息的安全漏洞，或者添加新的软件特性。确定何时为映像打补丁很重要，因为必须将为映像打补丁所需的额外复杂性和时间与更新实例的复杂性和时间进行权衡。

本发明引入算法，以便帮助负责映像流通的各方确定应该使用软件补丁更新哪些映像，以及应该何时进行这些更新。在供应过程中，算法考虑与执行映像或实例的更新关联的成本的多个方面。根据使用来自生产数据中心和关联的软件配置的数据的评估结果，标识了解更新映像和实例涉及的实际成本的重要性。当映像更新成本远高于实例更新时，预测未来请求是基础，用于确定映像可以保持过时多长时间以便节省更新映像的工作量。但是，针对更新映像或更新实例执行错误决策浪费的成本主要取决于对未来请求的预测。

本发明中提供的结果表示选择用于评估映像更新算法的工作负载。但是，还讨论了执行分析必需的步骤，映像管理者可以利用该分析，使用不同设置来执行有关何时需要更新映像的更有效决策。这对于受管云而言尤其重要，其中客户期望高水平的服务质量和映像质量来供应其实例。

尽管根据单个示例性实施例描述了本发明，但所属技术领域的技术人员将认识到，可以使用在所附权利要求的精神和范围内的修改来实现本发明。

进一步，注意申请人的目的是包含所有权利要求元素的等效物，即使以后在诉讼期间被修改。

Claims (15)

1.一种基于虚拟机提供计算基础架构的方法，所述方法包括：

提供由处理器在网络上执行的虚拟机供应系统，所述虚拟机供应系统：

接收虚拟机请求作为输入；

从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求；

通过供应所选择的虚拟机映像以适应所述虚拟机请求以及通过删除和安装软件系统中的至少一个以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及

响应于所输入的虚拟机请求而输出所述实例化后的虚拟机；以及提供映像更新系统，其用于基于更新成本而确定更新所述虚拟机映像和所述实例化后的虚拟机中的至少一个的更新计时。

2.根据权利要求1的方法，其中基于所确定的更新计时而自动发生所述更新。

3.根据权利要求1的方法，其中更新时间确定步骤确定是更新虚拟机映像还是更新从所述虚拟机映像实例化的每个虚拟机。

4.根据权利要求3的方法，其中所述映像更新系统基于对未来请求的预测，通过评估更新所述虚拟机映像的成本是否低于在供应时更新未来虚拟机的成本而确定是否为虚拟机的操作系统和软件堆栈中的至少一个打补丁。

5.根据权利要求1的方法，其中所述映像更新系统确定所述虚拟机映像库中的每个所述虚拟机映像的未来最长更新时间。

6.根据权利要求5的方法，其中所述映像更新系统确定所述库中的一组映像的所述未来最长更新时间。

7.根据权利要求5的方法，还包括：

提供所述未来最长更新时间作为输出信号，以便向所述计算基础架构的管理员指示所述未来最长更新时间；

接收并存储来自所述管理员的输入，所述输入指示用于更新所述映像的天数的阈值；以及

使用所述阈值更新所述映像。

8.根据权利要求1的方法，其中所述映像更新系统仅基于当前未决更新而判定是否应立即更新实例化后的虚拟机。

9.根据权利要求8的方法，其中当来自软件供应方的新的更新到达时，发生立即更新的判定。

10.根据权利要求8的方法，其中立即更新的判定提供用于确定所述虚拟机映像的未来最长更新时间的确认机制。

11.一种用于基于虚拟机提供计算基础架构的系统，所述系统包括被配置为执行权利要求1至10中的任一权利要求的方法步骤的装置。

12.一种系统，包括：

至少一个处理器；以及

存储设备，其用于存储指令程序，所述指令程序允许所述至少一个处理器之一实现和执行一种映像更新方法，所述映像更新方法用于基于更新成本而确定更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的至少一个的更新计时。

13.根据权利要求12的系统，其中所述存储设备进一步存储指令程序，所述指令程序允许所述至少一个处理器之一实现和执行一种虚拟机供应系统，所述系统还包括输入端口以便从网络上的用户接收针对虚拟机请求的输入，

其中所述虚拟机供应系统：

通过所述输入端口接收虚拟机请求作为输入；

从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求；

通过供应所选择的虚拟机映像以适应所述虚拟机请求以及通过删除和安装软件系统中的至少一个以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及

响应于所输入的虚拟机请求而输出所述实例化后的虚拟机。

14.根据权利要求13的系统，其中所述虚拟机供应系统根据所确定的更新计时而自动更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的所述至少一个。

15.根据权利要求14的系统，其中更新时间确定包括以下操作中的至少一个：

确定是更新虚拟机映像还是更新从所述虚拟机映像实例化的每个虚拟机；

确定所述虚拟机映像库中的每个所述虚拟机映像的未来最长更新时间；以及

仅基于当前未决更新而判定是否应立即更新实例化后的虚拟机。