用于确定何时需要更新云虚拟机的系统和方法
【专利摘要】本发明涉及一种用于确定何时需要更新云虚拟机的系统和方法。公开了一种用于基于虚拟机提供计算基础架构的方法（和结构）。一种虚拟机供应系统，当由处理器在网络上执行时：接收虚拟机请求作为输入；从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求；通过供应所选择的虚拟机映像以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及输出所述实例化后的虚拟机。一种映像更新系统基于更新成本而确定更新所述虚拟机映像和所述实例化后的虚拟机中的至少一个的更新计时。
【专利说明】用于确定何时需要更新云虚拟机的系统和方法
【技术领域】
[0001]本发明一般地涉及更新云提供方提供的虚拟机。更具体地说，提供一种用于确定虚拟机服务更新的机制，包括例如确定更新虚拟机实例还是更新用于虚拟机实例化的底层虚拟机映像。
【背景技术】
[0002]云提供方的常规做法是发布一组虚拟机映像，消费者可以将这些映像实例化为云上的特定虚拟机实例，从而导致简化的体验和更快的价值实现。这些映像是虚拟资源、操作系统的组合，并且可能包括一个或多个软件产品。提供方必须确定要提供的最佳映像组，并且必须不断地评估何时需要更新。更新通常以补丁的形式呈现，并且纠正错误或安全漏洞或者引入新功能。
[0003]但是，如将解释的，将补丁应用于虚拟机映像所需的复杂性和工作量远高于为虚拟机实例打补丁所需的复杂性和工作量。这可归因于以下风险:不正确地修改配置、中断映像的云供应，或者阻止管理堆栈的正确操作。
[0004]如果未将补丁应用于映像，则必须在实例化阶段或者在实例化之后，将补丁应用于该映像的每个实例。该过程导致消耗计算机资源，并且客户可能接收云提供方尚未测试的初始实例。
[0005]因此，本发明的
【发明者】认识到云供应领域中的一个新问题，其在于云提供方相对于虚拟机更新做出多个选择，甚至包括选择更新底层虚拟机映像还是更新虚拟机实例。其它更新决策包括确定此类更新的最佳计时(timing)，假设云提供方不断地从软件供应方接收更新。
【发明内容】
[0006]鉴于常规系统的以上和其它示例性问题、缺点和劣势，本发明的一个示例性特性是提供一种用于基于与更新关联的成本而进行虚拟机更新决策的结构(和方法)。
[0007]本发明的另一个示例性特性是提供一种用于确定更新底层虚拟机映像的成本是否低于更新每个虚拟机实例的成本的方法。
[0008]本发明的另一个示例性特性是为云提供方提供一种用于计算虚拟机映像的最长更新时间(maximum update time)的机制。
[0009]本发明的另一个示例性特性是为云提供方提供一种用于仅根据当前未决补丁而确定是否需要立即更新映像或实例的机制。
[0010]在第一示例性方面，在此描述一种基于虚拟机提供计算基础架构的方法，包括提供由处理器在网络上执行的虚拟机供应系统。所述虚拟机供应系统:接收虚拟机请求作为输入；从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求；通过供应所选择的虚拟机映像以适应所述虚拟机请求以及通过删除和安装软件系统中的至少一个以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及响应于所输入的虚拟机请求而输出所述实例化后的虚拟机。一种映像更新系统基于更新成本而确定更新所述虚拟机映像和所述实例化后的虚拟机中的至少一个的更新计时。
[0011 ] 在第二示例性方面，在此还描述一种系统，其包括至少一个处理器和存储设备，所述存储设备用于存储指令程序，所述指令程序允许所述至少一个处理器之一实现和执行一种映像更新方法，所述映像更新方法用于基于更新成本而确定更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的至少一个的更新计时。
[0012]在第三示例性方面，在此还描述一种非瞬时性计算机可读存储介质，其有形地包含机器可读指令程序，所述机器可读指令程序可由数字处理装置执行以执行一种实现和执行映像更新方法的方法，所述映像更新方法用于基于更新成本而确定更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的至少一个的更新计时。
【专利附图】
【附图说明】
[0013]从以下参考附图的对本发明示例性实施例的详细描述，将更好地理解以上和其它目的、方面和优点，这些附图是:
[0014]图1示出本发明的一个示例性实施例的示例性流程图100 ；
[0015]图2示出2010年针对OpenSuSEll.1操作系统发布的补丁的大小和计数的示例性数据200 ；
[0016]图3示出2008年发布的选择IBM中间件修复包的示例性数据300 ；
[0017]图4示出示例性测试结果400，其指示未来更新映像时的平均天数，该平均天数取决于使用映像的请求的被高估的数量；
[0018]图5示出示例性测试结果500，其指示更新映像浪费的时间，该时间取决于使用映像的请求的被低估的数量；
[0019]图6示出示例性测试结果600，其指示管理员为何可能更喜欢针对更新设置预定的阈值天数；
[0020]图7示出示例性测试结果700，其指示在多长时间内未更新映像可以导致浪费大量时间；
[0021]图8示出示例性测试结果800，其通过呈现取决于映像更新概率故障的恢复浪费时间，指示应用于映像的错误补丁对实例的后续供应时间的影响；
[0022]图9示出将本发明纳入其中的示例性硬件/信息处理系统900 ;以及
[0023]图10示出用于存储根据本发明的方法的程序步骤的非瞬时性信号承载存储介质1000 (例如，存储介质)。
【具体实施方式】
[0024]现在参考附图，更具体地说参考图1-10，现在将描述根据本发明的方法和结构的示例性实施例。
[0025]为了降低信息技术(IT)资本和运营支出，所有规模的组织都将其应用工作负载移动到云中。云在其具体技术和实现方面变化显著，但全部共享虚拟化作为基本支柱。虚拟化为云提供以下能力:在单个硬件单元中托管多个不同并独立的操作系统运行时。该特性连同可靠的界面(程序设计和/或图形)允许云消费者自由地动态创建和销毁云中的虚拟机实例(称为“云实例”)。
[0026]云以多种模型提供计算资源即服务，包括基础架构、平台和软件。基本模型称为基础架构即服务(IaaS)，并且为云消费者提供操作系统实例，云消费者能够在这些实例上托管其中间件和应用。使用IaaS，云提供方通常提供一组通用启动映像，这些映像提供有效基础以便实现特定于消费者工作负载的进一步定制。云消费者还可以选择利用共同体构造的映像或者构造它们自己的定制映像。云消费者的目标是找到与其工作负载要求最密切匹配的映像，因此减少与进一步调整关联的手动工作量。
[0027]映像的管理和治理变得复杂起来，因为每个个体客户都提出他们自己的独特要求。软件在映像中的流通针对云提供方和云消费者均提出极富挑战性的问题。云消费者或云服务提供方双方都不会受益于过时或不安全的软件版本，因此，
【发明者】认识到需要一种方法以便帮助各方确定应用软件补丁的最适当的频率和方法。本发明解决这种挑战，使云提供方和消费者都受益。
[0028]为了更准确地说明本问题，一旦已建立云的映像库，映像所有者就必须不断地监视相关补丁的可用性，并且确定应该更新哪些映像以及紧急程度如何。该活动是在整个操作系统和软件堆栈中应用最新错误、特性和安全补丁必需的。
【发明者】认识到确定何时为映像打补丁很重要，因为必须将为映像打补丁所需的额外复杂性和时间与更新从该映像获得的未来实例的复杂性和时间进行权衡。
[0029]因此，本发明可以被视为提供一种用于新认识到的问题的解决方案，该问题涉及云服务提供方的更新。在一个方面，本发明解决以下问题:更新虚拟机实例还是更新在实例化后的虚拟机底层的虚拟机映像。此外，本发明可以用于确定提供下一个更新的最长时间，并且用于基于当前未决补丁而确定是否应立即更新映像。
[0030]本发明提供各种算法，这些算法帮助负责映像流通的各方确定在某个时间点，应该使用软件补丁更新哪些映像。在此描述的算法考虑更新映像或在实例化时动态更新每个实例所涉及的成本的若干方面。可以根据来自生产数据中心的历史请求数据来评估算法。
[0031]这些算法可以用于基于生产数据中心中实际经历的实例化请求频率和未完成补丁而标识何时应该更新映像。测试结果确定对映像实例化请求的预测对于以下操作至关重要:当考虑资源成本、错误补丁的风险以及为所有后续实例打补丁的成本时，确定映像可以保持不打补丁的时间长度。
[0032]更新映像面临的挑战
[0033]首先并且如所属【技术领域】很容易理解的，通过在多个托管资源之上提供层管理来构造云，这些托管资源能够快速并且动态地响应云管理的请求。虚拟化是行业标准技术，其允许对备用物理托管资源进行最有效的分区。
[0034]虚拟机(VM)是虚拟化后的主机的逻辑分区。在云的上下文中，VM在以下讨论中称为“云实例”或简称“实例”。实例为组织的应用基础架构提供基本构件。与传统的数据中心一样，各种更高级的软件系统(例如，代理、中间件和应用)具有特定的要求，这些要求从资源(例如，CPU、存储器、磁盘)和软件角度(例如，OS类型、版本、配置、中间件)推动对各种实例配置的需要。
[0035]因此，出于呈现本发明概念的目的，云可以被视为基于虚拟机的计算基础架构，并且云服务是通过诸如因特网之类的网络使得这种计算基础架构可用于消费者的方法或实体。
[0036]通用的虚拟化实践是将这些资源和软件组合保存到可重用的软件包(称为“映像”)。因此，映像能够作为新实例的基础而重复使用，并且导致提高供应性能以及增加生成的实例配置的一致性。可以在云中选择的映像的可访问性、多样性和质量为云提供方提供主要的独特优势，为云消费者提供增加的吸引力。
[0037]一个此类实例是Amazon在其“非受管” IaaS弹性计算云(EC2)中创建的活跃社区(active community),其中个体、第三方供应商和Amazon本身贡献Amazon机器映像(AMI)以供所有EC2消费者使用。云消费者自由搜索AMI库并选择与其应用要求最匹配的映像。
[0038]活跃映像管理是降低复杂性所需的，并且确保云提供方和消费者从映像获得最大利益。例如，将描述的一种主要复杂性是需要权衡将补丁 (例如，用于错误、安全性、特性)应用于映像的成本与在供应每个新实例期间动态应用补丁的成本。因为还将讨论其它更新问题和选项，所以本发明应该被视为一种总体上以考虑各种更新成本的方式提供要由云提供方实现的虚拟机更新的机制。
[0039]A.映像以及受管与非受管云
[0040]另一个云识别层以受管或非受管云服务的形式呈现。非受管云服务提供基础架构，并且依赖于消费者为其实例执行全天候管理活动。在受管云服务中，提供方超越实例-系统管理程序障碍，并且提供诸如性能监视、可用性监视、许可管理和补丁管理之类的传统服务。受管服务水平针对实例施加其它条件和约束，必须满足这些条件和约束以便继续获得利益。例如，如果云消费者要卸载监视代理，则他们很可能使其服务水平协议无效。
[0041]受管云模型中的映像实例化通常远比非受管云的映像实例化复杂。必须通过完成供应和随后向消费者发布实例，实现受管云实施的其它代理和安全策略。这些项目通常遍布映像和用于创建实例的代码。例如，可以在符合受管云的映像中捕获操作系统安全设置，并且可以在供应时通过代码完成安装监视代理和向监视基础架构注册。从打补丁的角度看，显然管理代理的功能和负责实例化映像的代码都对补丁引入的任何更改敏感。
[0042]图1示出常见情形100，其中应用所有者定义支持他/她的特定应用所需的配置(结果是请求101)。然后必须选择云映像(102)以便充当请求的基础，其中考虑操作系统以及任何其它所需的软件组件或配置。然后实例化所选择的映像(103)并且执行动态修改
(104)，以便安装缺少的软件或者卸载不必要的软件(例如，由于许可问题)。
[0043]这是过程中用于应用任何未完成的操作系统或软件补丁的固有点，因为在该点，实例与原始请求更密切匹配并且还包含最新补丁。但是，在实例化点的这种更新将花费时间，并且不便于消费者立即实例化虚拟机，因此更新底层映像而不是每次均实例化可能成本较低。
[0044]图1示出虚拟机供应系统105，其允许客户端请求和实例化虚拟机。图1还示出云提供方基础架构的另一个重要组件，该组件是映像更新系统106，提供它用作本发明的组件。该组件106负责从软件维护者处接收有关已经发布哪个补丁以及该补丁用途的信息107。该信息以及对未来实例请求的预测108和在此描述的各种算法能够使云提供方确定(109)更新管理决策，例如为映像打补丁( 110)何时好于允许安装补丁作为供应的最终步骤(111)。
[0045]作为管理虚拟机更新的一个方面，该信息可以通过考虑为每个实例打补丁的成本与为映像打补丁的成本，指导云和映像管理员定义最低成本补丁计划。显然，随着补丁数量的累积，安装时间增加，并且破坏映像或管理代理的合规性的风险也增加。以下部分讨论更新映像与实例面临的挑战的某些主要差异。
[0046]B.更新实例和映像的差异
[0047]将补丁应用于操作系统或软件块的过程需要从提供方处获取补丁，评估相关性和依赖性，并且最后应用补丁以便修改现有的已安装文件。可能需要重新引导以便激活和验证补丁引入的更改。
[0048]此时，注意更新实例或映像可以是完全自动的，或者可以包括来自管理员的手动输入，具体取决于补丁的性质。可以在接收软件补丁时很容易地确定这些特征。在此描述的算法本身在其计算中考虑自动和/或手动更新方面，如通过与每个更新关联的成本所标识的那样。
[0049]下面的示例性算法I定义更新映像所需的典型步骤，这些步骤对于单个补丁而言可以相当复杂并且耗时。该算法考虑离线和在线打补丁技术。离线提供以下能力:在不实例化静止映像的情况下为该映像打补丁。在线需要实例化映像并且可通过传统的连接方法访问映像。
[0050]算法1:更新映像的过程:
[0051 ] Input: patchList
[0052]imageList 一 cloud, getlmpactedlmages(patchList)
[0053]foreach image in imageList do
[0054]if offline patch required then
[0055]mount image
[0056]apply offline patches
[0057]run unit tests
[0058]unmount image
[0059]if online patch required then
[0060]instantiate the image
[0061]apply online patches
[0062]if reboot required then
[0063]reboot
[0064]run unit tests
[0065]reset/generalize image
[0066]shutdown
[0067]convert to image
[0068]publish to image library
[0069]在受管云环境中，重要的是遵循该过程以便降低错误映像进入云系统的风险。发布错误映像可导致多个问题，包括:
[0070].供应故障，由于映像未满足供应代码的要求而导致；
[0071].实例化之后的合规性故障；
[0072].—个或多个管理代理故障，从而危及提供方支持服务水平的能力；以及[0073].消费者接收无功能的实例。
[0074]在下面提供的示例性算法2中概述更新实例的过程。该过程类似于用于映像的过程，但风险降低的对象从云提供方转移到消费者，并且最终转移到应用所有者。当处理初始供应时，云消费者主要专注于快速获得其实例，以便他们可以开始部署其应用。该过程与为已经运行应用的实例打补丁形成对比，后者关注的问题显然是确保应用继续按预期运行，并且确保对于最终用户没有计划外中断。按照该原则，云提供方甚至可以提供一种机制，该机制从最终用户处请求执行更新的权限(在初始实例化之前或者在中断已经部署的实例化之前执行更新)，从而为最终用户提供对实例化后的虚拟机的可用性和更新状态的某种程度的控制。
[0075]算法2:更新实例的过程:
[0076]Input: patchList
[0077]instanceList 一 cloud, getlmpactedlnstances (patchList)
[0078]foreach instance in instanceList do
[0079]if instance is offline then
[0080]bring instance online
[0081]apply online patches
[0082]if reboot required then
[0083]reboot
[0084]if instance was offline then
[0085]bring instance offline
[0086]performance instance smoke test
[0087]notify instance owner of patch results
[0088]在两种情形中，无法正确应用补丁的后果很严重，但是从云提供方的角度看，认为在映像情况下应用补丁的成本远高于在实例情况下应用补丁的成本。下一部分概述操作系统和软件中的打补丁频率，以便更好地了解问题的复杂性。
[0089]C.补丁发布特征的实例
[0090]补丁的分发和特征针对不同的软件类型(例如，操作系统、中间件)和供应商(例如，那些被视为企业任务关键的供应方-爱好开源的供应方)而有所不同。根据安装频率或者在应用拓扑中的位置，某些软件本身的性质使得它们更可能需要发现的补丁。某些产品采用固定计划，其中累积补丁并且以更大的聚合补丁进行应用(例如，用于IBM DB2的修复包)。
[0091]其它补丁(如用于Linux分发的那些补丁)频繁发布,这是由于Linux的共同体驱动的性质、分发中的大量软件包以及通过公共软件包管理分发的稳健性所致。下面的表I提供五个版本的OpenSuSE操作系统的补丁统计的汇总。表项“补丁 /月”描述每个操作系统版本每个月的总补丁数。
[0092]表I
[0093]OPENSUSE 版本 11.1、11.2、11.3、11.4、12.1 的汇总补丁统计。
[0094]类另l]-平均值-最大值-中间值-
软件包/版本125613941245补丁 / 版本625693295842
补丁 /软件包32195
补丁 / 月475541348
大小/补丁 (KB)1,598114,68867
[0095]图2示出示例性数据200，其突出补丁到达时间以及包括在时间段中的补丁总大小的波动。当更广泛地检查数据时，每个月平均发布323个补丁，其中最常见的是java，其在版本的生命周期内平均发布219个补丁。补丁大小本身变化很大，中等大小为67KB，而最大大小为115MB。作为一个简单的实践，可以从该图中看到，将映像更新延迟为每月一次(固定计划)将导致可能在实例化期间应用数百MB的补丁。
[0096]图3示出示例性数据300，其针对包括应用服务器(IBM WebSphere ApplicationServer)和数据库服务器(IBM DB2)的更大中间件软件的主要版本的打补丁频率。中间件产品显然显示不同于底层操作系统的模式，但在中间操作系统软件包的发布频率方面类似。通常，根据对来自IBM的15个产品的分析，
【发明者】观察到平均每五个月发布一个补丁，最频繁的发布是每2.5个月一次。每个版本的补丁数量还根据产品的生命周期(所见到的最大数量是23 (超过7年))而变化。
[0097]最后，通常观察到中间件补丁明显大于操作系统软件包，平均大小达到数百MB。当供应商(例如，IBM)在发布下一个修复包的预计日期之前发布时，补丁的可预测性还会更好。在此，一个主要的区别是软件修复包通常包含许多个体补丁，而操作系统补丁基于个体组件。
[0098]映像更新算法
[0099]如上一部分中描述的，与更新实例和映像关联的过程和成本完全不同。在此示例性算法中包括这两个方面以便确定何时应更新映像。
[0100]算法3:用于确定更新映像的最长时间的伪代码:
[0101]InputireqListj patchList, image
[0102]Output: max i mumUp da t e T ime
[0103]IiPatchList 一 patchList.getPatches(image)
[0104]2patchICost 一 iPatchList.getlmageCost(image)
[0105]3patchRCost — iPatchList.getReqCost(image)
[0106]4nReqs — 0
[0107]5maximumUpdateTime — 0
[0108]6foreach time unit t do
[0109]7maximumUpdateTime 一 maximumUpdateTime+t[0110]8nReqs 一 nReqs+reqList.getFutureReqs (image, t)
[0111]9if patchICost〈nFutureReqs*patchRCost*k then
[0112]IOreturn max i mumUp da t e T ime
[0113]llreturn-1
[0114]上面的示例性算法3表示用于在需要将一组更新应用于映像时确定最长更新时间的伪代码。该算法可以以固定时间间隔执行，或者在管理系统接收新补丁时动态执行。这缓解对尝试预测未来补丁到达时间的需要。该算法具有以下输入变量:
[0115].reqList:对供应实例的先前请求。每个请求包含所需的操作系统、软件堆栈和其它配置参数；
[0116].patchList:用于下载和应用操作系统和软件更新的描述和链接；
[0117].image:要评估的映像。
[0118]该算法首先初始化iPatchList (第I行),这包括patchList中被视为与映像相关的补丁。此后，设置两个更新成本(第2-3行):patchTCost和patchRCost,它们表示将补丁iPatchList应用于映像以及从该映像供应的实例的成本。
[0119]云提供方可以很容易地获得对应用补丁的成本的估计，如在算法3中使用的那样，注意上面的算法I和算法2提供通常用于应用补丁的步骤。因此，根据云提供方自己的操作和过程，云提供方可以很容易地使用有关先前的映像和实例更新的历史数据，以便根据补丁大小或其它相关参数(例如复杂性等)，针对任何接收的补丁产生成本估计。
[0120]然后在算法3中，根据时间的推进，使用循环将映像和实例更新成本相比较(第6-10行)。该时间t可以是小时、天、周等。针对每次循环迭代,更新未来请求数量nReqs(第8行)。
[0121]然后执行测试以便判定更新映像的成本是否低于更新来自该映像的所有未来实例的成本(第9行)。如果成本较低，则返回最长更新时间(第10行)。使用k因数补偿成本可能针对每个供应的实例而改变的事实(第9行)。注意，该因数k还可通过有关更新的历史数据获得，并且提供对于每个云服务提供方而言可能唯一的参数。
[0122]值得注意的是，算法3考虑单个映像的评估。但是，一种可能的情形是系统管理员想要知道一组映像的最长更新时间。对于这种情形，可以比较两个额外变量，它们用于存储更新所有映像的总成本以及更新所有实例的总成本，并且当第一个变量低于第二个变量时，返回最长更新时间。
[0123]此外，注意可以实现算法3的计算，以便针对云服务提供方自动发生。例如，在图1中示例性地示出的映像更新系统105可以被配置为在接收新更新时不断地更新该计算，并且使这些更新后的计算可用于云服务提供方管理员和/或自动执行适当的更新。
[0124]此外，系统管理员可能有兴趣确定是否应该立即更新实例。下面的算法4提供此类答案并且是算法3的变型。在该变型中，算法4可以以预定时间间隔执行或者每当新补丁到达时自动执行。
[0125]算法4:用于确定是否需要立即更新映像的伪代码(仅考虑未决补丁):
[0126]Input:reqList，patchList, image, timelnFuture
[0127]Output: UpdateNow (Boolean)
[0128]IiPatchList — patchList.getPatches(image)[0129]2patchICost 一 iPatchList.getlmageCost(image)
[0130]3patchRCost — iPatchList.getReqCost(image)
[0131]4nFutureReqs 一 reqList.getFutReqs(image, timelnFuture)
[0132]5if patchICost〈nFutureReqs*patchRCost*k then
[0133]6return true
[0134]7return false
[0135]算法4在多个方面不同于算法3。例如，算法3在未来时间范围内评估补丁，这可以有利于实现规划目的。算法4着眼于当前时间，这可以用于以下情况:管理员怀疑算法3生成的预测可能不准确。因此，算法4可以用作算法3的确认机制。此外，如上所述，算法4可以在接收任何新补丁时自动执行，从而可能设置立即更新(无论自动还是手动)。
[0136]所属【技术领域】的普通技术人员应该理解，映像更新算法的原理是:通过预测请求并且使用有关与更新映像或实例关联的成本的信息，可以确定何时应该更新映像。该知识缩短与将补丁应用于映像关联的时间，并且减小对基于映像的未来实例的影响。
[0137]在一篇简短描述本发明各个方面的待发布论文中，提供了展示原理合理的实验结果。该论文的内容在此引入作为参考。
[0138]但是，无需获得该论文中讨论的有关实验结果的设置和原理的细节，基于对浪费的时间百分比的计算，可以从这些实验结果认识到由本发明产生的多个优点和其它方面。下面的表1I示出该评估的实验参数和值的汇总。假设请求的到达时间遵循齐夫(Zipf)分布。
[0139]
【权利要求】
1.一种基于虚拟机提供计算基础架构的方法，所述方法包括: 提供由处理器在网络上执行的虚拟机供应系统，所述虚拟机供应系统: 接收虚拟机请求作为输入； 从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求； 通过供应所选择的虚拟机映像以适应所述虚拟机请求以及通过删除和安装软件系统中的至少一个以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及 响应于所输入的虚拟机请求而输出所述实例化后的虚拟机；以及提供映像更新系统，其用于基于更新成本而确定更新所述虚拟机映像和所述实例化后的虚拟机中的至少一个的更新计时。
2.根据权利要求1的方法，其中基于所确定的更新计时而自动发生所述更新。
3.根据权利要求1的方法，其中更新时间确定步骤确定是更新虚拟机映像还是更新从所述虚拟机映像实例化的每个虚拟机。
4.根据权利要求3的方法，其中所述映像更新系统基于对未来请求的预测，通过评估更新所述虚拟机映像的成本是否低于在供应时更新未来虚拟机的成本而确定是否为虚拟机的操作系统和软件堆栈中的至少一个打补丁。
5.根据权利要 求1的方法，其中所述映像更新系统确定所述虚拟机映像库中的每个所述虚拟机映像的未来最长更新时间。
6.根据权利要求5的方法，其中所述映像更新系统确定所述库中的一组映像的所述未来最长更新时间。
7.根据权利要求5的方法，还包括: 提供所述未来最长更新时间作为输出信号，以便向所述计算基础架构的管理员指示所述未来最长更新时间； 接收并存储来自所述管理员的输入，所述输入指示用于更新所述映像的天数的阈值；以及 使用所述阈值更新所述映像。
8.根据权利要求1的方法，其中所述映像更新系统仅基于当前未决更新而判定是否应立即更新实例化后的虚拟机。
9.根据权利要求8的方法，其中当来自软件供应方的新的更新到达时，发生立即更新的判定。
10.根据权利要求8的方法，其中立即更新的判定提供用于确定所述虚拟机映像的未来最长更新时间的确认机制。
11.一种用于基于虚拟机提供计算基础架构的系统，所述系统包括被配置为执行权利要求I至10中的任一权利要求的方法步骤的装置。
12.—种系统,包括: 至少一个处理器；以及 存储设备，其用于存储指令程序，所述指令程序允许所述至少一个处理器之一实现和执行一种映像更新方法，所述映像更新方法用于基于更新成本而确定更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的至少一个的更新计时。
13.根据权利要求12的系统，其中所述存储设备进一步存储指令程序，所述指令程序允许所述至少一个处理器之一实现和执行一种虚拟机供应系统，所述系统还包括输入端口以便从网络上的用户接收针对虚拟机请求的输入， 其中所述虚拟机供应系统: 通过所述输入端口接收虚拟机请求作为输入； 从虚拟机映像库中检索虚拟机映像以适应所述虚拟机请求； 通过供应所选择的虚拟机映像以适应所述虚拟机请求以及通过删除和安装软件系统中的至少一个以适应所述虚拟机请求而从所选择的虚拟机映像构造实例化后的虚拟机；以及 响应于所输入的虚拟机请求而输出所述实例化后的虚拟机。
14.根据权利要 求13的系统，其中所述虚拟机供应系统根据所确定的更新计时而自动更新虚拟机映像和从所述虚拟机映像实例化的虚拟机中的所述至少一个。
15.根据权利要求14的系统，其中更新时间确定包括以下操作中的至少一个: 确定是更新虚拟机映像还是更新从所述虚拟机映像实例化的每个虚拟机； 确定所述虚拟机映像库中的每个所述虚拟机映像的未来最长更新时间；以及 仅基于当前未决更新而判定是否应立即更新实例化后的虚拟机。
【文档编号】H04L29/08GK103995728SQ201410048963
【公开日】2014年8月20日 申请日期:2014年2月12日 优先权日:2013年2月14日
【发明者】M·D·德阿桑考, M·A·S·内托, L·兰嘉纳拉亚纳 申请人:国际商业机器公司