CN113330723A - 混合计算环境中的补丁管理 - Google Patents
混合计算环境中的补丁管理 Download PDFInfo
- Publication number
- CN113330723A CN113330723A CN202080010744.5A CN202080010744A CN113330723A CN 113330723 A CN113330723 A CN 113330723A CN 202080010744 A CN202080010744 A CN 202080010744A CN 113330723 A CN113330723 A CN 113330723A
- Authority
- CN
- China
- Prior art keywords
- patches
- subset
- workload
- patch
- computing platform
- 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.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/62—Uninstallation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/656—Updates while running
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
- G06F8/658—Incremental updates; Differential updates
-
- 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/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- 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
- G06F9/5038—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 considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
-
- 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
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1433—Vulnerability analysis
-
- 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/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- Stored Programmes (AREA)
Abstract
介绍了用于管理对与计算平台相关联的工作负载执行补丁的技术。补丁标识符组件可以识别与计算平台相关联的工作负载。工作负载可以包括第一工作负载部分和第二工作负载部分,在第一工作负载部分上可以离线执行补丁的第一子集,在第二工作负载部分上可以在线执行补丁的第二子集。补丁管理组件可以针对第一工作负载部分,基于补丁的第一子集的补丁的漏洞评分,确定可以在离线时在维护时间窗口内执行的补丁的第一子集的一部分,并且可以针对第二工作负载部分确定可以在线时执行的补丁的第二子集。补丁管理组件可以根据补丁的重要性级别确定补丁的第一子集的补丁的漏洞评分。
Description
背景技术
本主题公开涉及计算机相关系统,更具体地,涉及混合计算环境中的补丁管理。
发明内容
以下呈现了提供对所公开主题的一个或多个实施例的基本理解的概要。该概要并不旨在识别重要或关键要素或描绘特定实施例或权利要求的任何范围。其唯一目的是以简化的形式呈现概念,作为稍后呈现的更详细描述的前奏。在本文描述的一个或多个实施例中,可以促进管理与计算系统的工作负载相关联的补丁的应用的系统、设备、结构、计算机实现的方法、装置或计算机程序产品。
根据一个实施例,一种计算机实现的方法包括由可操作地耦合到处理器的系统确定与计算平台相关联的工作负载,其中,工作负载包括第一工作负载部分,补丁的第一子集将在该第一工作负载部分上执行。计算机实施的方法还包括由系统基于补丁的第一子集的补丁漏洞评分确定在维护时间窗口内应用到第一工作负载部分的一部分的补丁的第二子集,其中补丁的第一子集包括补丁的该第二子集。
在一些实施例中,结合所公开的方法描述的元素可以以不同的形式体现,例如系统、计算机程序产品或另一种形式。
根据另一个实施例,一种系统可以包括存储计算机可执行组件的存储器;以及处理器,可操作地耦合到存储器,执行计算机可执行组件。计算机可执行组件可以包括:更新标识符组件,用于识别与计算平台相关联的工作负载,其中工作负载包括第一工作负载部分,更新的第一子集将在该第一工作负载部分上执行,以及第二工作负载部分,更新的第二子集将在第二工作负载部分上执行。计算机可执行组件还可以包括:更新管理组件,基于与第一工作负载部分相关联的更新的第一子集的更新漏洞评分确定在维护时间段内应用于第一工作负载部分的一部分的更新的第三子集,其中,更新的第一子集包括更新的第三子集。
在一些实施例中,结合所公开的系统描述的元素可以以不同的形式体现,例如计算机实现的方法、计算机程序产品或另一种形式。
这些和其他特征将从其说明性实施例的以下结合附图阅读的详细描述中变得明显。
附图说明
图1示出了根据所公开主题的各个方面和实施例的可用于在计算系统上有效地管理和应用补丁的示例性非限制性系统的框图。
图2描绘了根据所公开主题的各个方面和实施例的包括可以跨越多个维度的工作负载的示例非限制性计算系统的图。
图3呈现根据所公开主题的各个方面和实施例的用于在与补丁相关联的工作负载离线时在维护时间窗口期间应用补丁的示例补丁序列的框图。
图4示出了根据所公开主题的各个方面和实施例的与确定工作负载的资源和补丁管理之间的依赖关系的示例应用拓扑图。
图5描绘了根据所公开的主题的各个方面和实施例的关于与计算系统相关联的示例工作负载以及工作负载的资源和补丁管理之间的依赖关系的示例补丁选择的图。
图6示出了根据所公开主题的各个方面和实施例的示例补丁管理组件600的框图。
图7描绘了根据所公开主题的各个方面和实施例的用于管理与计算平台相关联的补丁的另一示例非限制性方法的流程图。
图8示出了根据所公开主题的各个方面和实施例的用于管理与计算平台相关联的补丁的另一示例非限制性方法的流程图。
图9图示了其中可以促进在此描述的一个或多个实施例的示例性、非限制性操作环境的框图。
具体实施方式
以下详细描述仅是说明性的,并非旨在限制实施例或实施例的应用或使用。此外,无意受前述背景或概述部分或详细说明部分中呈现的任何明示或暗示信息的约束。
现在参考附图来描述一个或多个实施例,其中相同的附图标记自始至终用于指代相同的元件。在以下描述中,出于解释的目的,阐述了许多具体细节以提供对一个或多个实施例的更透彻的理解。然而,很明显,在各种情况下,可以在没有这些具体细节的情况下实践一个或多个实施例。
恶意软件攻击可以使计算机相关系统瘫痪,并且可以使公司和其他实体在停机时间和恢复成本方面花费大量金钱(例如,数千美元、数万美元、数十万美元……)。通常,公司没有时间和资源来为数千个系统(例如,与计算机相关的系统)打补丁,而其他公司则投入了他们负担不起的时间和资源。
计算机相关系统的自动打补丁可以是一种成本有效的替代方案,以消除对计算机相关系统的手动打补丁以及不为计算机相关系统打补丁的风险。根据风险级别来衡量为计算机相关系统或其部分打补丁和不打补丁的成本是有用的和可取的,并且根据与风险相关的成本的这种衡量,确定何时执行补丁以及执行什么补丁。
关于打补丁的另一个考虑可以是打补丁时间通常不是常数,并且许多因素可以对打补丁有影响。系统的异质性(例如,平台、配置和系统部署应用的变化)会增加至少某些补丁失败的可能性,因为非标准系统可能相对难以测试。
又一个考虑可以是,在执行补丁的成本可以小于或等于不打补丁的成本的最早时间点,为与计算机相关的系统或其部分打补丁通常可以是更好的。一旦对计算机相关系统的漏洞利用公开可用,未打补丁的计算机相关系统的风险通常会明显增加(例如,显著增加)。
再一考虑可能是计算机相关系统的补丁有时可能具有缺陷。因此,在实施补丁后,可能需要能够验证补丁或实施补丁的计算机相关系统的性能是否可接受,并且,如果补丁或计算机相关系统的性能不可接受,可能需要在实施补丁之前回滚或撤消补丁以将与计算机相关的系统返回到其先前状态。
在对计算机相关系统的混合工作负载执行补丁时,可能存在进一步的重大挑战。计算条件和规格可以变化,工作负载也可以变化。混合工作负载可以由(例如,可以跨越)多个维度组成,例如,多云或多操作系统架构,云部署模型的类型(例如,传统计算基础设施、私有云或公共云;内部和外部;专用或共享;……),部署的类型(例如,裸机、虚拟机(VM)、容器、外部服务……),工作负载的类型(例如,批处理工作负载、事务工作负载、分析工作负载、高性能工作负载、数据库工作负载或中央处理单元(CPU)、磁盘或处理器密集型工作负载……),执行补丁的频率(例如,每月或月末补丁、补丁的季节性变化……)或开发和运营(DevOps)流程。此外,工作负载的多个层级(例如,节点)之间可能存在依赖关系。
此外,节点打补丁可以在线或实时执行,例如,关于集群或始终在线或离线,其中打补丁将在节点和相关联的应用离线时执行。另一个挑战可能是,通常会有一个有限的停机时间窗口,在该窗口中,可以在离线时在节点和相关应用上执行补丁。另一个需要考虑的挑战是,与补丁相关的重要性、优先级或漏洞(例如漏洞评分)可能存在差异,例如,某些补丁可能具有较高的重要性,而其他补丁可能具有中等级别的重要性,还有其他补丁可能具有相对较低级别的重要性。此外,需要注意的是,目前,用户(例如,客户)通常可以负责在适用基础设施范围内单独为操作系统、中间件和应用打补丁。
为此,本文的各种实施例涉及用于在计算环境,例如混合计算环境(例如,混合云计算环境)中管理补丁的技术。补丁标识符组件可以识别与计算平台相关联的工作负载。工作负载可以包括第一工作负载部分和第二工作负载部分,在第一工作负载部分上可以离线执行补丁的第一子集,在第二工作负载部分上可以在线执行补丁的第二子集。补丁管理组件(PMC)可以基于补丁的第一子集的补丁漏洞评分,为第一工作负载部分确定可以在维护时间窗口内在离线时对第一工作负载部分的一部分执行的补丁的第一子集的一部分(例如,第三子集),并且可以为第二工作负载部分确定可以在在线时可以执行的补丁的第二子集。PMC可以至少部分地基于补丁的相对重要性级别来确定补丁漏洞评分或补丁组(例如,补丁的不同分组)的组漏洞评分,以促进确定在维护时间窗口期间应用的补丁的第一子集的部分(例如,第三子集)以及应用到第二工作负载部分的补丁的第二子集。在一些实施例中,补丁的第三子集的至少一些补丁可以同时或彼此并行应用,或者补丁的第二子集的至少一些补丁可以同时或彼此、或与补丁的第三子集的至少一些补丁并行应用。
当第一工作负载部分离线时,补丁执行组件可以在维护时间窗口内对第一工作负载部分的该部分执行补丁的第三子集,并且对第二工作负载部分执行补丁的第二子集,其中第二工作负载部分可以在执行(例如应用)这样的补丁时在线。PMC可以验证应用的补丁和相关工作负载,同时仍在维护时间窗口内,以确保补丁和相关工作负载正常运行。如果PMC确定补丁未通过验证(例如,在应用补丁后,此类补丁或相关工作负载项目未正确执行),PMC可以在维护时间窗口内恢复补丁,以将工作负载项返回到应用补丁之前的先前状态。
现在将关于附图描述所公开主题的这些和其他方面和实施例。
图1示出了根据所公开主题的各个方面和实施例的示例性非限制性系统100的框图,该系统100可用于在计算系统上有效地管理和应用补丁。系统100可以包括可以包括各种组件的计算系统102。计算系统102可以包括一个或多个网络(例如,计算或通信网络)。在一些实施例中,计算系统102可以是多维的,其中计算系统102可以跨越多个维度并且可以包括可以跨越计算系统102的多个维度的工作负载(例如,混合工作负载)。例如,计算系统102可以包括多云或多操作系统架构,可以采用多维部署模型(例如,传统计算基础设施、私有云或公共云;内部和外部;专用或共享),可以使用可以跨越多层级或多维部署模型的多个部分的各种类型的组件或设备(例如,裸机、VM、容器、外部服务等),可以涉及可以跨越计算系统102的多个维度的各种类型的工作负载(例如,批处理工作负载、事务工作负载、分析工作负载、高性能工作负载、数据库工作负载或CPU、磁盘或处理器密集型工作负载……),可以包括DevOps过程或可以跨越计算系统102的多个维度的其他特征,如这里更充分地描述的。
计算系统102可以包括各种容器104、虚拟机(VM)106、物理机(PM)108、其他资源110和节点112,它们可以相互相关地布置或相互关联以形成计算系统102并提供各种服务(例如,与计算相关的服务和应用)。例如,各种容器104、VM 106、PM 108、其他资源110或节点112可以跨越计算系统102的多个维度并且可以排列成多个层级(例如,容器104可以在第一层级中并且可以与第二层级中的另一个容器104或VM 106相关联,或者另一个容器104或VM 106可以与第三层级中的另一个VM 106或PM 108相关联,...),如本文更充分地描述。根据各种实施例,容器104、VM 106、PM 108或其他资源110可以是节点112、可以是节点112的一部分或可以与节点112相关联。
在不同的时候,可能希望将补丁应用到计算机程序或相关联的数据以增强计算系统102。补丁可以是设计用于更新计算机程序或其支持数据、以修复或改进该计算机程序。补丁可以包括修复安全漏洞或其他错误,或者通过升级计算机程序来提高计算机程序的可用性或性能。节点上的补丁可以属于一个或多个层级,通常不限于操作系统(例如,第一类操作系统、第二类操作系统、第三类操作系统等),还可以应用于安装在节点上的软件(例如,应用、中间件或数据库)。
为了便于应用补丁,系统100可以包括补丁管理组件(PMC)114(也称为更新管理组件),可以管理(例如,控制)根据定义的补丁管理标准和关联的补丁管理算法将补丁应用到各种容器104、VM 106、PM 108、其他资源110、节点112、应用、关联数据等。PMC 114可以包括补丁标识符组件116(也称为更新标识符组件),可以识别或确定要执行的补丁(例如,在维护时间窗口期间),以及补丁执行组件118(也称为更新执行组件),可以在(或向)各种容器104、VM 106、PM 108、其他资源110、节点112、应用或相关联的数据等上执行或运行(例如,应用)补丁(例如,选定的补丁)。
当系统100的某些组件(例如,容器104、VM 106、PM 108或其他资源110或节点112……)在线时,可以在这些组件上执行一些补丁,而在系统100的某些组件(例如,某些容器104、VM 106、PM 108、其他资源110或节点112,...)离线前不能将某些补丁应用到这些组件。通常可以有相对较短的时间(例如,维护时间窗口),在此期间组件可以离线以应用补丁。此外,不同的补丁可以与不同级别的漏洞、优先级、重要性或风险相关联。因此,由于维护时间窗口可能是有限的,因此可能希望在维护时间窗口期间将某些补丁(例如,与更高级别的漏洞、优先级、重要性或风险相关的补丁)的应用优先于其他补丁(例如,与相对较低级别的漏洞、优先级、重要性或风险相关的补丁)。
根据各种实施例,对于给定的维护时间窗口,PMC 114可以识别工作负载,该工作负载包括在第一工作负载部分离线时对其应用补丁的第一工作负载部分和在第二工作负载部分在线时可以对其应用补丁的第二工作负载部分,可以根据定义的补丁管理标准和相关的补丁管理算法,至少部分基于与补丁相关联的漏洞评分,确定可以在维护时间窗口期间应用的补丁的子集,而第一工作负载部分处于离线状态(s),如本文更全面的描述。在确定要执行哪些补丁时(例如,在维护时间窗口期间),PMC 114可以考虑关于容器104、VM106、PM 108、其他资源110、节点112、应用等的各种特征,包括与将补丁应用到容器104、VM106、PM 108、其他资源110、节点112、应用等有关的特征。
例如,关于对与容器平台(例如,对于某些类型的容器平台)相关联的容器(例如,容器104)打补丁,通常不为正在运行的容器打补丁。相反,对于容器(例如,104),可以对容器使用的映像打补丁(例如,由补丁执行组件118),同时容器仍在运行(例如,在线),并且可以以新的已经打补丁的容器映像重启容器。当新容器(例如,新容器映像)启动时,可以关闭(例如,由PMC 114)在容器上运行的应用,因此,应用可能会因为容器映像打补丁而产生停止和启动时间。
关于为VM(例如,VM 106)打补丁,为VM打补丁可能导致应用的停止和启动时间,并且经常可能需要重启(例如,由PMC 114)。此外,在应用停止(例如,由PMC 114)之后,补丁执行组件118可以为VM(例如,VM 106)的VM实例(不是映像)打补丁,因此,在PMC 114重新启动应用之前,VM实例可能为VM的每个适用补丁产生打补丁的时间。
如所指示的,通常可以存在有限的窗口,在该窗口期间可以由补丁执行组件118执行离线补丁。例如,对于未集群的容器104或VM 106,可能存在有限的维护时间窗口(例如,维护停机时间窗口),在该窗口内打补丁过程可能导致应用的停止和启动时间以及容器104和VM 106的重新加载和重新启动时间。在这个有限的维护时间窗口内,VM 106可能会产生打补丁时间。由于在维护时间窗口期间可用的时间量有限(例如,相对较短),通常补丁执行组件118只能在维护时间窗口期间应用补丁的部分子集。关于对容器104打补丁,容器通常不会产生这个打补丁时间,因为可以在这个维护时间窗口之外为容器的镜像(例如,当容器104和其他资源在线时)打补丁。因此,对于容器104,补丁执行组件118通常可以将补丁(例如,可以应用所有补丁)应用到容器104(例如,在线或离线时)。
关于在线补丁,例如,对于某些类型的容器平台(例如,可以支持滚动更新的容器平台),补丁执行组件118(例如,由PMC 114管理)可以执行滚动更新(例如,滚动打补丁),其中可以使用复制控制器,复制控制器可以增加或减少新控制器和旧控制器上的副本计数,直到达到(例如,实现)所需(例如,正确)的副本数量。例如,一个Pod可以包括一个或多个容器。复制控制器可以确保在任何给定时间(例如,在一个或多个节点上同时运行)所需(例如,指定)数量的Pod副本(也称为副本计数或Pod副本)正在运行。复制控制器可以管理(例如,监督)跨多个节点的多个Pod。例如,如果复制控制器确定有太多的Pod,复制控制器可以终止额外的Pod,如果确定没有足够的Pod,复制控制器可以启动或创建更多的Pod。为了在没有服务中断的情况下更新服务,补丁执行组件118可以对Pod执行滚动更新,这可以一次更新一个Pod,而不是同时针对整个服务(例如,服务的所有Pod)进行。与服务(因此,该服务)相关联的工作负载部分可以继续运行,即使在更新期间的不同时间,在此工作负载部分上执行的一些节点(例如,属于副本计数)可以被关闭以对其打补丁。在一些实施例中,如果PMC 114确定关于一个Pod的副本计数大于1,则PMC 114可以确定该Pod可以被实时打补丁(例如,在线)。这可以通过使补丁执行组件118使用具有请求的批量大小的新的Pod实例增量地更新Pod实例来允许在零停机时间的情况下发生部署的更新。VM 106或容器104上的高可用性应用(例如,某些应用服务器)可以允许PMC 114,包括补丁执行组件118,执行自动应用滚动更新过程,该过程可以停止或暂停托管集群成员的每个应用服务器,在不停机的情况下对其执行更新。当升级软件或硬件时,高可用性灾难恢复(HADR)环境可以允许PMC114,包括补丁执行组件118,更新数据库相关软件(例如数据库产品软件)或更改(例如修改、调整)数据库配置参数,同时在整个滚动更新过程中保持数据库服务可用,仅当处理从一个数据库切换到另一个数据库时出现短暂的服务中断。
关于管理补丁,PMC 114还可以考虑计算系统102(例如,混合云计算系统)的其他特征或因素,根据定义的补丁管理标准,促进确定在给定时间段(例如,维护时间窗口)内实施哪些补丁。例如,对于混合云,混合云可以实现即插即用的方法来使用来自不同提供商或供应商的云平台和服务。这些云可以包括私有云或公共云或外部云或本地云,并且可以是或可以包括容器104、VM 106、PM 108等,如本文更全面地描述的。
在一些实施例中,计算系统102可以采用可以包括各种依赖关系(例如,层级之间的依赖关系)的多层级应用。多层级应用可以允许表示、应用处理、业务处理和数据管理功能在物理上分离。层级通常可以是层,一层在另一层之上,因为一层可以依赖于另一层。每一层都可以没有它上面的层而存在,并且可以利用该层下面的层来发挥作用。层级(例如层级层)之间的数据传输可以是架构的一部分。通过n层级系统的数据流的端到端可追溯性可能是一项具有挑战性的任务,当系统复杂性增加时,这会变得更加重要。每个层级本身都可以作为一个集群运行。
关于多层级应用、依赖关系以及离线和在线打补丁,离线层级和在线层级之间可能存在对于补丁而言可能重要(例如,重要)的依赖关系。当在维护时间窗口期间有第一层级要进行离线打补丁,而该第一层级又依赖于可以进行在线打补丁的另一层级时,对于第一层级离线执行补丁以满足维护时间窗口可能是可取的(例如,有用的)。当存在第一层级要对其进行在线打补丁,并且该第一层级又依赖于要对其进行离线打补丁的另一层级时,在与离线打补丁相关联的另一层级的持续时间内,与在线打补丁相关联的第一层级本质上可以被认为是离线的(例如,由PMC 114)。这可以允许识别可以在线打补丁的依赖关系树的分支,并且可以在用于离线打补丁的维护时间窗口期间对更多服务进行打补丁。
在某些实施例中,PMC 114可以理想地根据定义的补丁管理标准对各种资源(例如,容器104、VM 106、...)执行同时或并行地打补丁。关于可以使用相同PM 108的多个容器104和VM 106的同时打补丁,当其他应用正在使用这些机器(例如,VM 106)时,可能希望在云中不要过多地加载机器(例如,VM 106)。因此,PMC 114可以控制补丁以合乎需要地限制同时应用到机器(例如,VM 106)的补丁的数量。如果假设计算系统102的云以没有服务可以使用来自另一个应用的资源的方式共享,根据定义的补丁管理标准,采用补丁执行组件118的PMC 114可以潜在地开始为尽可能多的服务打补丁。
因此,关于所公开的主题,将补丁应用到工作负载的问题可以归结为找到补丁的子集,其中一部分可以在线应用而其他补丁要离线应用(例如,通过关闭应用),其中应用补丁的总时间不超过允许的维护时间窗口。关于应用补丁,除了执行补丁的实际执行时间外,如所披露的,应用补丁的时间量可以包括应用的停止和启动时间以及VM或容器的重新加载和重新启动时间。PMC 114的目标可以是优先化,并且PMC 114可以优先化,相较于优先级较低或不太紧急的应用补丁,将更高风险的漏洞和更紧急的应用补丁先打上。
PMC 114可以管理对具有跨混合云环境中的一组节点部署的多个资源的多层工作负载进行打补丁,其中工作负载可以包括跨节点混合部署的资源(例如,容器104、VM 106、PM 108……)。PMC 114还可以使一些资源能够对其他所需资源在离线时打补丁的同时,在线打补丁(例如,当确定可以执行这样的在线补丁时),并且同时确保可以在服务和应用以及计算系统102的关联组件在维护时间窗口内离线时对需要打补丁的服务和应用进行打补丁。例如,PMC 114可以处理(例如,管理)工作负载,包括在离线时将在维护时间窗口期间应用某些补丁的第一工作负载部分和在线时可以应用其他补丁的第二工作负载部分,同时或基本上同时在适用的维护时间窗口内优先考虑更高漏洞风险的补丁(例如,具有高漏洞或重要性评分或级别的补丁)。
在一些实施例中,PMC 114可以针对请求(例如,资源之间的请求)监视网络(例如,计算系统102的网络)以促进确定容器104、VM 106、PM 108、110其他资源或节点112等之间的工作负载依赖关系,其中工作负载依赖关系可以在第一种类型的项(例如,容器104)和另一种类型的项(例如,PM 108)或可以在相同类型的项(例如,第一个VM 106和第二个VM106)之间。资源之间的请求可以指示(例如,向PMC 114)资源之间的关联或一个资源是否依赖于另一资源、请求的类型或资源的层级或相关层级(例如,一个资源在一个层级(或层)中,而另一个资源在该层级之下的另一层级(或层)中)。
PMC 114可以至少部分地基于对请求的网络的监控或通过其他方式来确定容器104、VM 106、PM 108、其他资源110或节点112等之间的工作负载依赖关系,如本文所述。在一些实施例中,PMC 114可以至少部分地基于对请求的分析来确定或识别网络的拓扑结构,包括资源之间的依赖关系。此外,至少部分基于对请求的分析或通过确定此类工作负载依赖关系的其他手段,PMC 114可以确定或生成资源/节点之间的依赖关系树,其中,计算系统102或其一部分的依赖关系树可以具有允许PMC 114同时对多个服务打补丁的形状。PMC114可以利用依赖关系树来实现在给定的维护时间窗口中包括和执行更多补丁。
PMC 114可以至少部分地基于资源之间的工作负载依赖关系来确定工作负载。工作负载可以包括第一工作负载部分,第一工作负载部分可以是离线时(至少部分是由于此类工作负载项的工作负载依赖关系)在维护时间窗口内将由补丁的第一子集打补丁的工作负载项(例如,容器104、VM 106、PM 108、资源110或节点112、...),以及可以在线时由补丁的第二子集打补丁的第二个工作负载部分。补丁标识符组件116可以识别或确定要应用于工作负载的补丁或补丁的相对重要性级别(例如,漏洞评分)或与其相关的信息。
为了便于确定在给定的维护时间窗口内执行哪些补丁,PMC 114可以至少为补丁的第一子集确定漏洞评分,该补丁的第一子集希望在维护时间窗口期间在离线时对工作负载的第一工作负载部分执行。在一些实施例中,PMC 114还可以为补丁的第二子集确定漏洞评分,该补丁的第二子集可以在在线时对工作负载的第二工作负载部分执行。
考虑到在维护时间窗口期间可用的有限时间量,通常可能无法在维护时间窗口期间为第一工作负载部分执行补丁的第一子集中的所有补丁。PMC 114可以至少部分地基于补丁的第一子集或补丁的第二子集中每个补丁的重要性、优先级、漏洞或风险级别来确定补丁的第一子集或补丁的第二子集的补丁漏洞评分。在补丁的第一子集中,通常可以有一些补丁比其他补丁更重要。PMC 114可以通过优先化补丁以执行能够在维护时间窗口期间执行的补丁的第一子集中的更重要的补丁来最大化所解决的风险(例如,计算系统102或其一部分的风险,例如容器104、VM 106、PM 108、其他资源110、节点112、应用或数据……),并且可以选择要在维护时间窗口期间执行的更重要的补丁(例如,要在要执行的补丁的第三子集中)。
漏洞评分可以指示补丁重要性的变化。例如,PMC 114可以采用可以告知每个问题相对于每个补丁的严重程度的漏洞评分量表(例如,点量表),这可以允许PMC 114判断或确定每个补丁的问题的严重性并确定最重要的补丁是什么。漏洞评分量表可以基于对确切缺陷及其类型(或当前威胁级别,尽管在此类分析中可能会忽略当前威胁级别)的技术分析来考虑潜在风险。通用漏洞评分系统(CVSS)基础评分可以提供有关漏洞的额外指导,通过对漏洞的恒定方面进行评分来给出详细的严重性评级:例如,访问向量、访问复杂性、身份验证、机密性、完整性和可用性。在一些实施例中,PMC 114可以采用1到3的漏洞评分等级,其中1代表最重要的补丁而3代表最不重要的补丁。例如,1的值或评分可以表示与补丁相关的漏洞是高级别的,并且此类补丁具有更高的优先级,2的值或评分可以表明与补丁相关的漏洞为中等级别,并且此类补丁为相对中等优先级,3的值或评分可以表示与补丁相关的漏洞级别较低,并且此类补丁的优先级相对较低。应当理解和理解,在各种其他实施例中,PMC114可以采用其他漏洞、重要性或风险评分尺度,例如1到5(或10或100)的尺度,其中5(或10或100)表示最重要的补丁,1表示最不重要的补丁,反之亦然。
在某些实施例中,PMC 114可以使用期望的补丁管理算法至少部分地基于各个补丁的各个漏洞评分(对于每组补丁)来确定或将组漏洞评分分配给该组补丁,例如在此更全面地描述。例如,根据可以应用的一个补丁管理算法,PMC 114可以至少部分地基于各个补丁的各个漏洞评分(对于每组补丁)通过将基于几何级数总和的公式应用到各个漏洞评分确定(例如,计算)与第一工作负载部分或第二工作负载部分相关联的补丁组(例如,不同的补丁组)的组漏洞评分,如此处更充分地描述。PMC 114可以使用这样的公式来促进确保具有低漏洞评分的大量补丁最终不会比具有高漏洞评分的相对少量补丁具有更高的组漏洞评分,以便将更高的优先级放在具有更高的漏洞评分的补丁上。
在评估补丁的漏洞评分之后,PMC 114可以至少部分地基于补丁的第一子集或补丁的第二子集的补丁漏洞评分以及维护时间窗口,从与第一工作负载部分相关联的补丁的第一子集中确定可以应用于第一工作负载部分的一部分(例如,容器104、VM 106、PM 108、资源110或节点112的子集、...)的补丁的第三子集。例如,PMC 114可以根据所需的补丁管理算法(例如,使用公式或其他所需的补丁管理算法),确定与与第一工作负载部分或第二工作负载部分相关联的其他补丁组的组漏洞评分相比,与第一工作负载部分或第二工作负载部分相关联的哪组补丁具有最高组漏洞评分。PMC 114可以选择具有最高组漏洞评分的补丁组进行打补丁,其中,补丁组可以包括可以在维护时间窗口期间在离线时应用于第一工作负载部分的该部分的补丁的第三子集,或者可以在在线时应用于第二工作负载部分补丁的第二子集。
补丁执行组件118可以在维护时间窗口期间在第一工作负载部分的一部分上执行(例如,应用)补丁的第三子集。在一些实施例中,补丁执行组件118可以根据由PMC 114确定的网络拓扑以拓扑顺序执行补丁的第三子集的补丁。在某些实施例中,补丁执行组件118可以在多个工作负载项(例如,容器104、VM 106、PM 108、其他资源110、节点112、应用或数据……)上同时执行补丁的第三子集的补丁(例如,并行),包括在可用维护时间窗口内的第一工作负载部分的该部分的具有依赖关系的工作负载项。
PMC 114,包括补丁执行组件118,可以执行打补丁过程以促进执行补丁的第三子集,其中,打补丁过程可以包括停止和重新启动与第一工作负载部分的一部分相关联的资源以及重新启动与补丁的第三子集相关联的节点,如本文更充分地描述的。关于要打补丁的容器104,补丁执行组件118可以将补丁应用到容器104的容器映像,因为不可变容器实例通常不被打补丁。关于VM 106和PM 108,补丁执行组件118通常可以将补丁应用到VM 106或PM 108的VM或PM实例,而不一定是VM 106或PM 108的VM或PM映像。
补丁执行组件118还可以在第二工作负载部分上执行补丁的第二子集,其中补丁的第二子集可以在第二工作负载部分(或计算系统102的其他部分)在线时执行,或者可以在维护时间窗口之外或在维护时间窗口期间执行。在某些实施例中,补丁执行组件118可以同时(例如,并行地)对第二工作负载部分执行补丁的第二子集的全部或至少一部分补丁,其中在维护时间窗口期间对第一工作负载部分的该部分执行补丁的第三子集的一部分。
在一些实施例中,包括补丁执行组件118的PMC 114可以如下应用补丁(例如,补丁的第二和第三子集)。补丁执行组件118可以例如为可以实时打补丁(例如,在线)的相关服务发起实时打补丁(例如,在后台)以应用关于第二工作负载部分(例如,容器104(例如,Pod)、VM 106、PM 108、其他资源110、节点……)的补丁。
关于与离线执行的第一工作负载部分的部分相关联的补丁,对于第一工作负载部分的该部分的每个VM 106的Pod的子集和补丁的子集,补丁执行组件118可以在没有任何依赖关系的Pod(例如,容器104)和VM 106上发起打补丁,并且可以并行地对这样的Pod和VM进行打补丁(更新)。每当Pod或VM打了补丁,PMC 114可以更新可以打补丁的Pod和VM的列表,并且可以发起对Pod和VM列表上的Pod和VM进行打补丁。PMC 114,包括补丁执行组件118,可以继续这个公开的过程,直到所有期望的(例如,选择的)服务都被打上了补丁。
在执行补丁之后,PMC 114可以在维护时间窗口内验证针对第一工作负载部分或第二工作负载部分的一部分打的补丁以确保正确应用补丁,并且确保第一工作负载部分或第二工作负载部分的部分的补丁和相应项目以及整个计算系统在这些补丁被应用之后正确执行。例如,在应用一个或多个补丁后,PMC 114可以分析或检查与一个或多个补丁相关联或受其影响的应用、节点或资源等,以确定应用、节点或资源等是否满足已定义的补丁管理标准,该标准指示应用、节点或资源等处于定义的健康或可用的操作状态(例如,应用、节点或资源等是否正常、适当、可接受或最佳地运行,或至少运行良好以达到或超过规定的最低运行标准)。如果PMC 114确定应用、节点或资源等在应用了一个或多个补丁之后满足这样定义的补丁管理标准,PMC 114可以确定一个或多个补丁被验证。如果PMC 114确定特定补丁被验证,则PMC 114可以维护特定补丁。但是,为了响应确定无法验证特定补丁和相关工作负载项,PMC 114可以在维护时间窗口内恢复与工作负载项相关联的特定补丁,将工作负载项返回到应用特定补丁之前的先前状态。
关于补丁的第一子集中的其他补丁(例如,未应用的补丁),其未被PMC 114选择以在维护时间窗口期间执行,根据定义的补丁管理标准,PMC 114可以将在第一工作负载部分的其他部分上执行此类其他补丁推迟到下一个或将来的维护时间窗口。PMC 114可以确定或计算下一个维护时间窗口,在该时间窗口期间补丁执行组件118可以应用补丁的第一子集的其他补丁(或者其他补丁,如果有的话,可以随后可用或发现)。
参考图2(连同图1),图2描绘了根据所公开的主题的各个方面和实施例的包括可以跨越多个维度的工作负载的示例非限制性计算系统200的图。计算系统200(例如,基于混合云的计算平台)可以包括传统IT平台202、私有云计算平台204、和公共云计算平台206,并且因此可以跨越关于计算平台的多个维度。传统的IT平台202可以包括应用(app),例如包括应用208和210;应用服务器(app ser),包括应用服务器212和214;以及数据库(DB),包括数据库216和218。私有云计算平台204可以包括,例如,应用,包括应用220和222;应用服务器,包括应用服务器224和226;和数据库,包括数据库228和230。公共云计算平台206可以包括,例如,应用,包括应用232和234;应用服务器,包括应用服务器236和238;和数据库,包括数据库240和242。
在一些实施例中,计算云(例如,204、206)可以与不同的供应商(例如,第一供应商、第二供应商或第三供应商,……)相关联,因此可以跨越关于供应商和供应商类型(例如,供应商提供的服务类型)的多个维度。计算系统200还可以采用多种管理程序技术,例如,裸机管理程序技术、基于内核的VM(KVM)(例如,基于内核的管理程序技术)、基于微内核的管理程序技术、容器或单内核(unikernal)等,可以提供各种计算服务,因此可以跨越管理程序技术类型的多个维度。
工作负载还可以跨越多个维度,例如,关于计算平台(例如,传统IT平台202、私有云计算平台204或公共云计算平台206),计算或云服务供应商、管理程序技术、资源类型(例如,VM、容器、PM、节点或其他资源),其中每个工作负载可以在工作负载的资源之间具有自己的依赖关系(例如,工作负载的多层级节点之间的依赖关系)(或没有依赖关系)。例如,示例计算系统可以包括第一工作负载244、第二工作负载246和第三工作负载248。第一工作负载244可以包括可以跨越传统IT平台202和私有云计算平台204的VM(例如,仅VM),其中第一工作负载244的VM可以由传统IT平台202的数据库216和私有云计算平台204的应用220和应用服务器224实现或关联,其中,数据库216、应用220和应用服务器224可以实现为VM或VM形式。
第二工作负载246可以包括VM、PM和容器,并且可以跨越私有云计算平台204和公共云计算平台206。例如,第二工作负载246的VM可以由公共云计算平台206的应用服务器236(例如,实施为VM)、私有云计算平台204的数据库228(例如,实施为PM),以及公共云计算平台206的应用234(例如,实现为容器(Con))来实施或与其相关联。
第三工作负载248可以包括一个或多个容器(例如,仅容器),并且可以跨越私有云计算平台204和公共云计算平台206。例如,第三工作负载248的容器可以由私有云计算平台204的数据库230、公共云计算平台206的应用234和应用服务器238实现或与其相关联,其中,数据库230、应用234和应用服务器238可以实现为容器或容器形式。应当理解和理解,这些工作负载(例如,244、246、248)只是示例工作负载,并且根据各种实施例,除了这些示例工作负载和本文描述的其他工作负载之外,所公开的主题可以包括、涉猎或涉及各种不同类型的工作负载。
第一工作负载244、第二工作负载246和第三工作负载248可以提供资源之间关于离线打补丁(例如,由PMC 114和补丁执行组件118)的依赖关系的示例,其中,资源可以分布在一个或多个节点上,例如图2中所示(以及如附图中另外所示出的或本文中所描述的)。PMC 114可以确定或识别与工作负载(例如,244、246、248、……)相关联的工作负载的资源之间的依赖关系(例如,工作负载的多个层级的节点之间的依赖关系),便于确定在特定维护时间窗口内对特定工作负载执行哪些补丁(例如,相对于其他补丁的特定维护时间窗口,哪些补丁将被优先考虑和执行),包括根据定义的补丁管理标准确定哪些资源能够在不中断或干扰特定工作负载的情况下停止和启动(例如,以及相关的补丁管理算法),如本文更全面的描述。
参考图3(连同图1),图3呈现了根据所公开主题的各个方面和实施例的示例补丁序列300的框图,用于在与补丁相关联的工作负载离线时在维护时间窗口期间应用补丁。示例补丁序列300可以与示例工作负载相关。应当理解,示例补丁序列300只是可以与示例工作负载相关的一个示例补丁序列,并且,根据各种实施例,根据定义的补丁管理标准和相关联的补丁管理算法,可以(例如,由PMC)针对其他工作负载执行其他补丁序列,如本文所述。
当在维护时间窗口期间对与修补丁序列300相关联的示例工作负载执行补丁时,示例补丁序列300可以包括停止(例如,停止或暂停操作)与在维护时间窗口内要对其执行补丁的工作负载相关联的网络服务器,如补丁序列300的参考数字302所示。例如,PMC 114可以在维护时间窗口期间停止网络服务器。在补丁序列300的参考数字304,PMC 114可以停止(例如,停止或暂停操作)与工作负载相关联的应用服务器。在附图标记306,PMC 114可以验证与工作负载相关联的数据库的数据库备份(例如,可以验证或验证数据库已经被备份以保留存储在数据库中的数据)。例如,存储在数据库中的数据可以存储在一个或多个数据存储中,以便于备份存储在数据库中的数据。在附图标记308,PMC 114可以停止数据库。
在补丁序列300的附图标记310,补丁执行组件118可以将补丁应用到工作负载,其中补丁可以针对与工作负载相关联的操作系统、中间件或应用。在附图标记312,PMC 114可以重新启动(例如,重新启动或恢复其操作)与工作负载相关联的节点(例如,应用补丁的节点)。在附图标记314,PMC 114可以启动数据库。在附图标记316,PMC 114可以启动(例如,恢复操作)应用服务器。在附图标记318,PMC 114可以启动网络服务器。
在补丁序列300的附图标记320,PMC 114可以验证工作负载。例如,在维护时间窗口期间,当与工作负载关联的资源处于离线状态时,PMC 114可以验证工作负载和对工作负载执行的相关补丁,以验证或检验与工作负载和相关补丁相关的资源在补丁执行后是否正常运行(例如,Web服务器正常运行,应用服务器正常运行,数据库正常运行,包括恢复到数据库的数据,以及节点正常运行)。在验证过程中,如果PMC 114确定特定补丁或相关联的工作负载项或资源(例如,节点、网络服务器、应用服务器、数据库等)未正确执行或无法接受,执行补丁后,PMC 114可以在维护时间窗口期间恢复(例如,撤销)补丁,以将工作负载项或资源返回到执行补丁之前的先前状态,例如在此更全面地描述。无法验证的补丁可以在未来重新执行,例如,根据定义的补丁管理标准和相关的补丁管理算法,在补丁被修改为以期望的(例如,可接受的、合适的、改进的或最佳的)方式执行之后。
参考图4(连同图1),图4示出了根据所公开主题的各个方面和实施例的与确定工作负载的资源和补丁管理之间的依赖关系的示例应用拓扑400的图。云计算系统402可以包括各种资源和节点,这些资源和节点可以根据需要彼此相关地布置或彼此关联以形成可以提供各种所需的服务和应用云计算系统402。
在云计算系统402中,示例应用拓扑400可以包括可以与交易者应用相关联的交易者容器404,可以与社交网络应用相关联的社交网络服务(soc nw svc)容器副本406,可以与消费者忠诚度服务应用相关联的消费者忠诚度服务(忠诚度svc)容器副本408,以及可以与通信服务应用相关联的通信服务(comm svc)容器410。
交易者容器404可以是或者可以包括例如用户界面(UI),并且可以位于应用拓扑400的第一层级(例如,顶层或最高层)中。交易者容器404可以与(例如,通信地或可操作地连接到)投资组合容器412相关联,投资组合容器412可以位于应用拓扑400的第二层级中,其中,投资组合容器412可以是或可以包括服务器。投资组合容器412可以与数据库VM 414相关联,该数据库VM 414可以位于应用拓扑400中的投资组合容器412和交易者容器404之下的应用拓扑400的第三层级中,其中,数据库VM 414可以是或可以包括数据库或数据库应用或服务。投资组合容器412还可以与股票容器416相关联,股票容器416可以位于应用拓扑400中投资组合容器412和交易者容器404下方的应用拓扑400的第三层级中,其中股票容器416可以是或可以包括服务(例如,与股票有关的服务,例如股票交易)。
PMC 114可以分析网络、资源或节点或资源之间的请求,并且至少部分地基于该分析,可以识别或确定容器104、VM 106、PM 108、其他资源110或节点之间的依赖关系112等。例如,PMC 114可以监控网络的请求,可以分析此类请求,并且可以至少部分地基于分析的结果来确定或推断容器104、VM 106、PM 108、其他资源110或节点112等之间的依赖关系。例如,关于示例应用拓扑400,PMC 114可以确定交易者容器404、投资组合容器412、数据库VM414和股票容器416之间的依赖关系,包括确定交易者容器404在第一层级,投资组合容器412在第二层级,以及数据库VM 414和股票容器416在彼此相关的第三层级。
转向图5(连同图1),图5描绘了根据与所公开主题的各个方面和实施例的关于与计算系统相关联的示例工作负载以及工作负载的资源和补丁管理之间的依赖关系的示例补丁选择500的图。关于示例补丁选择500,PMC 114可以确定要选择执行的补丁,包括补丁的子集,其可以与工作负载的第一工作负载部分相关联,以根据定义的补丁管理标准和相关的补丁管理算法,考虑到工作负载资源之间的依赖关系(例如,工作负载多层级节点之间的依赖关系),工作负载项目和要执行的相关补丁的相对重要性、优先级或漏洞或其他因素,在维护时间窗口内当与工作负载的第一个工作负载部分相关联的资源、节点等处于离线状态时应用(例如,由补丁执行组件118),如本文更充分地描述的。PMC 114还可以确定与工作负载的第二工作负载部分相关联的补丁的另一子集,其可以在与第二工作负载部分相关联的资源、节点等在线时应用(例如,由补丁执行组件118)(例如,实时),其中可以在维护时间窗口内应用与第二工作负载部分相关联的补丁的另一子集或补丁的另一子集的至少一部分(例如,与执行与第一工作负载部分相关联的补丁同时或并行)。
PMC 114可以根据定义的补丁管理标准和相关的补丁管理算法,在给定的维护时间窗口内优先应用更高的漏洞补丁(例如,更紧急的应用补丁),如在此更充分描述的。例如,PMC 114可以处理(例如,管理)工作负载的补丁,包括在维护时间窗口期间在离线时将应用某些补丁的第一工作负载部分的至少一部分以及在线时可以应用其他补丁的第二工作负载部分(例如,同时或基本同时),在给定的维护时间窗口内优先考虑更高的漏洞补丁(例如,具有高漏洞或重要性评分或级别的补丁)。
关于示例补丁选择500,可能存在与各种应用相关联的工作负载,当工作负载的第一工作负载部分(例如,应用或相关资源,节点等)处于离线时,而第二个工作负载部分处于在线时在这些应用上可能需要在维护时间窗口(例如,适用的停机时间窗口)内执行补丁。应用可以包括例如通信服务(comm svc)应用502、消费者忠诚度服务(忠诚度svc)应用504、交易者应用506、投资组合应用508、数据库应用510、社交网络服务(soc nw svc)应用512和股票报价应用514。
关于应用(例如,502、504、506、508、510、512、514),至少部分地基于分析与应用相关联的资源和与工作负载相关联的补丁之间的依赖关系的结果,PMC 114可以确定或识别可能需要执行(例如,应用)此类补丁的各种补丁,可以确定维护时间窗口内第一工作负载离线时那些补丁中的哪些将应用于与第一工作负载部分相关联的资源(例如,容器104、VM106、PM 108、其他资源110)、节点(例如,节点112)等,并且可以确定第二个工作负载部分在线时哪些补丁可以应用于资源、节点等。关于与第一工作负载部分相关联并且将在维护时间窗口期间执行而与第一工作负载部分相关联的资源、节点等处于离线状态的补丁部分,PMC 114可以在维护时间窗口内确定可能希望为其执行此类补丁的补丁的相对(例如,不同的)重要性、优先级或漏洞(例如,高级、中级或低级)。但是,通常情况下,要应用的补丁可能比在维护时间窗口内应用的要多。例如,PMC 114可以确定或识别将针对通信服务应用502执行的补丁516和518,并且可以进一步确定补丁516和518是低级别补丁(例如,补丁516和518各自具有表明它们具有相对低级别的重要性、优先级或漏洞的漏洞评分)。PMC 114还可以确定或识别将针对消费者忠诚服务应用504执行的补丁520、522和524,并且可以进一步确定补丁520是高级别补丁(例如,补丁520的漏洞评分指示其具有高级别重要性、优先级或漏洞),补丁522是中等级别的补丁(例如,补丁522的漏洞评分指示其具有中等级别的重要性、优先级或漏洞),并且补丁524是低级别补丁(例如,补丁524的漏洞评分指示其具有相对较低的重要性、优先级或漏洞)。
PMC 114还可以确定或识别将针对交易者应用506执行的补丁526、528和530,并且进一步可以确定补丁526和528是高级别补丁,补丁530是低级别补丁。此外,PMC 114可以确定或识别将关于投资组合应用508执行的补丁532和534,并且进一步可以确定补丁532和534是中级别补丁。PMC 114还可以确定或识别将针对数据库应用510执行的补丁536、538和540,并且进一步可以确定补丁536是中级别补丁并且补丁538和540是低级别补丁。
PMC 114还可以确定或识别将针对社交网络服务应用512执行的补丁542和544,并且还可以确定补丁542是中级别补丁而补丁544是低级别补丁。PMC 114还可以确定或识别将针对股票报价应用514执行的补丁546、548和550,并且还可以确定补丁546是中级别补丁而补丁548和550是低级别补丁。
PMC 114可以分析补丁(例如,补丁516到550),确定和分析与工作负载相关的资源之间的依赖关系,确定在第一工作负载部分离线时要执行哪些补丁(例如补丁的子集),确定在第二工作负载部分在线时可以执行哪些补丁(例如,补丁的其他子集),确定补丁的漏洞评分或补丁的各个组(例如,分组)的组漏洞评分,并且根据定义的补丁管理标准和相关的补丁管理算法确定可以在维护时间窗口内执行并且具有比补丁的其他子集的其他整体漏洞评分更高(例如,最高)的总体漏洞评分的期望的(例如,最佳的、合适的或可接受的)补丁的子集。通过具有最高的总体漏洞评分(例如,最大化漏洞评分),这种期望的补丁的子集可以最小化或至少显着减少计算系统的漏洞。
在示例补丁选择500中,至少部分地基于分析结果,PMC 114可以确定,例如,补丁516和518可以是与通信服务应用502相关联的低级别补丁,补丁542和544分别可以是中等级别的补丁,以及与社交网络服务应序512相关联的低级别补丁可以与第二工作负载部分相关联并且可以在第二工作负载部分在线时应用(例如,在维护时间窗口内或在维护时间窗口外应用)。此外,至少部分地基于分析结果,PMC 114可以确定所需的补丁的子集(例如,具有最高的总体漏洞评分;能够在维护时间窗口内执行)可包括补丁520、522、524、526、528、530、532、534和536,但不包括补丁538、540、546、548和550。补丁执行组件118可以在维护时间窗口内应用与第一工作负载部分相关联的补丁的子集(例如,补丁520到536),而第一工作负载部分是离线的,并且可以在维护时间窗口内应用与第二工作负载部分相关联的其他的补丁的子集(例如,补丁516、518、542和544),同时第二工作负载部分是在线的,如本文更充分地描述的。
进一步关于图1,存在多个补丁管理算法,PMC 114可以利用或应用这些算法来确定在维护时间窗口期间要执行哪些补丁。根据一种补丁管理算法,PMC 114可以将VM的每个补丁视为单个条目,
其中,例如,如果在维护时间窗口内无法应用所有补丁,则可以优先考虑漏洞评分高的补丁;可以将每个容器(例如Pod)的所有补丁视为单个条目,其中应用此类补丁的时间量以及Pod中所有资源的开始和停止时间可以组合在一起,因为容器镜像是离线打补丁的。
作为停止和启动资源以为VM(例如,VM 106)上的特定应用服务器打补丁的时间量的示例,停止应用服务器大约需要两分钟,应用补丁大约需要一分钟,打完补丁需要大约四分钟启动应用服务器。如果一个应用服务器资源有多个补丁,PMC 114可以将这些补丁组合成一个条目,这样就不必多次停止和重新启动应用服务器来应用这些补丁。如果单独考虑应用服务器补丁,则通过多次重新启动可能造成过度使用时间量(例如,可能会超过维护时间窗口中的可用时间量)。请注意,该VM的重新启动时间可以作为单独的条目包含在0时间中以制作补丁。
根据这样的补丁管理算法,每个补丁可以包括以下属性:停止容器104、VM 106、PM108或其他资源110的时间量;重新启动容器104、VM 106、PM 108或其他资源110的时间量;应用补丁的时间量(对于容器104可以为零);补丁的重要性评分(例如,重要性或漏洞评分);与补丁相关的副本计数;和补丁的种类。在一些实施例中,当确定(例如,计算)补丁的重要性或漏洞评分时,PMC 114可以使用容器的几何级数和来计算重要性或漏洞评分。
以下可以是使用基于几何级数和的公式来确定(例如,计算)Pod的重要性评分的说明性非限制性示例。为了便于确定(例如,计算)Pod的更新的重要性或漏洞评分,关于每种类型的更新(例如,高重要性、中重要性或低重要性),PMC 114可以使用以下示例等式为该类型的更新确定重要性或漏洞评分(例如,单个重要性或漏洞评分):
其中x可以是具有重要性值的更新类型(2=高,3=中,4=低),nx可以是要应用于Pod的特定类型的更新数量。PMC 114可以通过将针对Pod的不同类型的更新确定的个体重要性或漏洞评分加在一起来确定Pod的所有更新的总(例如,整体或组)重要性或漏洞评分。例如,一个Pod可以有两个x=2的高重要性更新(例如补丁)和四个x=3的中等(重要性)更新。PMC 114可以将高重要性更新的重要性或漏洞评分确定为[(1/2)2+(1/2)3];可以将中等重要性更新的重要性或漏洞评分确定为[(1/3)2+(1/3)3+(1/3)4+(1/3)5];可以确定Pod更新的总重要性或漏洞评分为[(1/2)2+(1/2)3]+[(1/3)2+(1/3)3+(1/3)4+(1/3)5]。在确定容器或Pod的评分以及如何确定其评分时,最好不要让过多的较低重要性更新(例如,较低的漏洞更新或补丁)的总和压倒高重要性更新的总和。该补丁管理算法(以及本文公开的其他补丁管理算法)可以使高重要性更新(例如,高重要性更新的总和)不会被较低重要性更新(例如,相对较大数量的重要性较低的更新的总和)压倒。
在一些实施例中,PMC 114可以应用另一种补丁管理算法来促进根据定义的补丁管理标准确定期望的(例如,合适的、最佳的或至少几乎最佳的)补丁的子集以相对于维护时间窗口内的工作负载执行。例如,这种补丁管理算法可以提供用于确定要应用的理想的补丁的子集的动态编程解决方案并且可以如下表达。
PMC 114可以创建空的二维阵列K[(N+1)[(W+1)],其中N可以是更新(例如补丁)的总数,W可以是可以重新启动服务的窗口(例如维护时间窗口)的大小。PMC 114可以初始化这个数组,其中对于每个位置,这个数组的K[i][j]可以保存以下条目:给定i更新和窗口大小j,可以包含更新子集[1:i]和估计更新完成时间的映射,它可以给出窗口大小j的最大累积评分;在窗口大小j中可达到的最大累积评分;和线程映射,它可以包含跨多个线程的更新分布,以达到这个最大累积评分,其中线程映射也可以具有称为“实时”的特殊线程(例如,用于可以在线执行的更新)。解决方案可以是在K[(N+1)[(W+1)]位置的条目。
关于填充K和确定K[(N+1)[(W+1)],在阵列的每个K[i][j]处,PMC114可以将初始最大评分分配给K[i-1][j]的评分;可以将Pod的最佳子集初始化为等于K[i-1][j]处的子集,线程映射等于K[i-1][j]处的子集;可以检查是否可以将更新i添加到位于K[i-1][l]的更新子集中,其中l:0-j不超过窗口大小j;如果更新i可以添加到更新的子集中,则可以将添加到K[i-1][l]的所有新Pod/容器的评分相加,并与之前的最大评分进行比较;如果将所有新Pods/容器的评分加到K[i-1][l]上得到的评分大于之前的最大评分,可以更新三个条目;并且可以继续执行上述操作直到PMC 114已经尝试了所有l:0-j。PMC 114可以识别或确定与最大评分(例如,最大或最高漏洞评分)相关联的补丁的子集。
进一步关于检查以确定是否可以将更新i添加到更新的子集中,PMC 114可以获得或确定当前Pod/容器的所有依赖关系(例如,工作负载的多层级节点之间的依赖关系)的列表。PMC 114可以检查(例如,分析、评估)以确定是否可以实时(例如,在线)为当前Pod/容器的所有依赖关系打补丁。如果当前Pod/容器的所有依赖关系都可以实时打补丁,则PMC 114可以将它们添加到实时线程并更新评分(例如,漏洞评分)。如果当前的Pod/容器无法实时打补丁,但可以实时为某些依赖关系打补丁,PMC 114可以从活动线程中移除依赖关系并且可以将这样的依赖关系视为不能被实时打补丁的新依赖关系。对于每个依赖关系,如果线程中没有上一个依赖关系的时间,PMC 114可以将先前依赖关系结束的时间添加到线程,该线程可以在前一个依赖关系结束后最早完成依赖关系(例如按照贪婪调度),检查完成时间是否不超过j;并将当前依赖关系的评分添加到总评分中。
在某些实施例中,PMC 114可以通过列举补丁的所有可能子集、从该列表中过滤可行子集并确定补丁的可行子集并根据定义的补丁管理标准确定具有最高累计评分的补丁的可行子集确定理想的(例如,最重要的)补丁的子集。对于待处理的补丁总数m,子集的数量可以是2m。
在某些实施例中,PMC 114可以应用补丁管理算法(例如,算法1-getOptimalSubset,如本文所公开的)以促进根据定义的补丁管理标准确定期望的(例如,合适的或最佳的)补丁的子集以在维护时间窗口内针对工作负载执行。该补丁管理算法(例如,算法1)中使用的变量和函数的定义可以包括以下内容:W可以是离线窗口的大小;[p1,p2,p3,...pm]可以是待处理补丁的列表,其中待处理补丁的总数为m;[(depsDict)]可以是应用的依赖关系树(邻接表);K可以是一个二维数组,可以容纳子问题的解;scheduleCrit可以通过首先调度最长的关键路径来调度给定的补丁列表;scheduleGreedy可以以先到先服务器的方式贪婪地调度给定的补丁列表;并且schedPolicy可以是调度策略,它可以是贪婪的或关键的。
补丁管理算法可以表示如下:
whcrc P←所有待处理补丁的集合
Popl←具有最大评分的可行集合
W←离线窗口的大小
ThMap←给定数量线程上的补丁调度
(1)
该补丁管理算法(例如,算法1-getOptimalSubset)可以将补丁选择建模为背包(knapsack),使得打补丁的时间可以被视为补丁的权重,补丁的评分可以是补丁的值,总的离线窗口大小可以看作是背包(sack)的大小。该补丁管理算法(例如,由PMC 114实现)可以确定确保在W分钟内为最重要补丁打补丁的补丁的子集。该补丁管理算法(例如,由PMC 114实现)可以为每个补丁分配一个重要性评分,其目标是确定最大化累积评分的可行的补丁的子集。补丁管理算法可以解决同时补丁数量受到限制的情况。该补丁管理算法(例如,由PMC 114实现)可以在允许的线程数上以不违反依赖关系约束的方式调度补丁,例如,可以在停止服务和应用补丁之前关闭应用服务的依赖关系。为了找到接近最优的补丁调度,补丁管理算法(例如,由PMC 114实现的)可以使用多种技术中的一种,例如贪婪和关键路径。贪婪方法(scheduleGreedy)可以降低补丁管理算法的时间复杂度,它只是尝试将当前补丁拟合到先前选择的补丁的补丁调度中。关于关键路径调度(scheduleCrit),对于每个子问题K[i][j],关键路径调度(例如,由PMC 114实现)总是可以首先调度关键路径,然后将其从待处理的补丁中移除。这个关键路径调度过程可以递归地重复,直到没有剩余的补丁可以调度或者对时间W来说所有线程都被占用。
补丁管理算法(例如,如由PMC 114实现的)可以创建空的二维阵列K[(m+1)[(W+1)],其中m可以是更新(例如补丁)的总数,W可以是可以重新启动服务的窗口(例如维护时间窗口)的大小。PMC 114可以将此数组初始化为零,其中对于每个位置,该数组K[i][j]可以包含以下条目:给定i个更新和窗口大小j,一个可以包含更新子集[1:i]和估计更新完成时间的映射,它可以给出窗口大小j的最大累积评分;在窗口大小j中可达到的最大累积评分;和一个线程映射,它可以包含跨多个线程的更新分布,以达到这个最大累积评分。解决方案可以是在K[(m+1)[(W+1)]位置的条目。
关于填充K和确定K[(m+1)[(W+1)],在阵列的每K[i][j]处,PMC 114可以将初始最大评分分配给K[i-1][pw]的评分;可以将Pod的最佳子集初始化为等于K[i-1][j]处的子集,线程映射等于K[i-1][j]处的子集;并且可以检查是否可以将更新i添加到位于K[i-1][pw]的更新子集中,其中pw:0-j且不超过窗口大小j。可以使用贪婪算法或关键路径优先算法来检查是否可以添加更新i。如果更新i可以添加到更新的子集中,MC 114可以将所有添加到K[i-1][pw]的新Pod/容器的评分相加,并将其与之前的最大评分进行比较;如果将所有新Pods/容器的评分加到K[i-1][l]中得到的评分大于之前的最大评分,PMC 114可以更新这三个条目;并且PMC 114可以继续执行上述操作直到PMC 114已经尝试了所有pw:0-j。PMC 114可以识别或确定与最大评分(例如,最大或最高漏洞评分)相关联的补丁的子集。
对于每个依赖关系,如果线程中不存在前一个依赖关系的时间,PMC 114可以将前一依赖关系结束的时间添加到线程中,线程可以在前一依赖关系结束后最早完成依赖关系(例如,根据贪婪调度或关键路径调度),检查完成时间是否不超过j,并将当前依赖关系的评分加到总分中。
在某些实施例中,当对同时补丁(线程)没有限制时,PMC 114可以应用又一补丁管理算法。在这种情况下,不必解决作业调度和分区问题。对于部署在容器中的每个服务,PMC114可以只检查服务是否可以在给定的维护时间窗口内与其依赖关系一起重新启动,因为容器的总离线打补丁时间不依赖于正在应用的补丁。如果为容器应用补丁并重新启动其依赖关系的时间小于窗口大小W,它可以在维护时间窗口(例如,离线窗口)内打补丁。对于VM,离线打补丁时间可能取决于所应用的补丁。由于这对同时补丁没有限制,对于每个VM,PMC114可以运行或实施单独的背包算法来确定和选择可以在给定时间内应用的补丁的最佳子集。对于VM的这种单独的背包问题中的每一个,PMC 114还可以考虑重新启动依赖的时间,例如这里公开的。
图6示出了根据所公开主题的各个方面和实施例的示例PMC 600的框图。PMC 600可以包括补丁标识符组件602和补丁执行组件604,如在此处更充分地描述的,每个可以与相应的组件(例如,分别命名的组件)相同或相似或可以包括相同或相似的功能。
PMC 600可以包括可以控制(例如,管理)与PMC 600相关联的操作的操作管理器组件606。例如,操作管理器组件606可以促进生成指令以使PMC 600的组件执行操作,并且可以向PMC 600的组件(例如,补丁标识符组件602、补丁执行组件604、……、处理器组件618、数据存储620、……)传送指令以根据定义的补丁管理标准、定义的补丁管理算法(例如,如本文所描述的方法、系统和技术所公开、定义、引用、体现或指示的补丁管理算法),至少部分地基于指令促进PMC 600的组件的操作的执行。操作管理器组件606还可以促进控制PMC600的组件之间的数据流以及控制PMC 600与另一个组件或设备(例如,计算机、膝上型计算机或其他类型的计算或设备)之间的数据流。通信设备)与PMC 600相关联(例如,与之连接)。
PMC 600还可以包括例如拓扑标识符组件608、评分确定组件610、补丁选择器组件612、验证组件614和还原组件616。拓扑标识符组件608可以确定或识别与计算系统相关联的工作负载(例如,与基于云的混合计算系统相关联的混合工作负载)的拓扑。作为确定工作负载拓扑的一部分,拓扑标识符组件608可以确定或识别与工作负载相关联的节点或资源之间的依赖关系,以促进确定工作负载的依赖关系树,并促进有效地确定在维护时间窗口期间应用哪些补丁,确定应用补丁的顺序(例如,对第一个工作负载部分离线执行补丁),并且在维护时间窗口期间至少将补丁应用到工作负载的所需部分。
评分确定组件610可以根据定义的补丁管理标准和相关的适用补丁管理算法,至少部分基于分析漏洞或补丁重要性级别的结果(例如,高、中或低级别的漏洞)确定与工作负载相关联的补丁的补丁相关评分(例如,与工作负载相关的补丁的漏洞、重要性或风险评分,或与工作负载相关的补丁的子集的整体、累积或组漏洞、重要性或风险评分)。例如,评分确定组件610可以利用期望的补丁管理算法,例如,此处描述的补丁管理算法,以便于确定补丁的漏洞评分或与工作负载相关的补丁的子集(例如,不同组)的组漏洞评分。
补丁选择器组件612可以根据定义的补丁管理标准,至少部分地基于为与工作负载相关联的补丁确定的补丁相关评分或与工作负载相关的补丁的子集的总体或累积补丁相关评分,从补丁集合中选择或确定与工作负载相关联的补丁的子集以在维护时间窗口期间执行,其中补丁的子集的至少一部分将在工作负载的第一工作负载部分离线时应用,而补丁的子集的另一部分可在工作负载的第二工作负载部分在线时应用。例如,补丁选择器组件612可以根据适用的补丁管理算法,至少部分地基于确定与工作负载相关联的补丁的子集与与工作负载相关联的补丁的其他子集的其他组、总体或累积补丁相关评分相比具有最高的组、总体或累积补丁相关评分,从补丁集合中选择或确定与要在维护时间窗口期间执行的工作负载相关联的补丁的子集。
验证组件614可以分析在维护时间窗口期间而与第一工作负载部分相关联的资源、节点或应用等离线时应用于第一工作负载部分或第二工作负载部分的补丁或者可以分析与第一工作负载部分或第二工作负载部分相关联的资源、节点、应用或数据等,以确定和验证(例如,验证)与第一工作负载或第二工作负载部分相关联的补丁或资源、节点、应用或数据等是否在应用补丁之后适当地执行(例如,Web服务器正常运行,应用服务器正常运行,数据库正常运行,包括恢复到数据库的数据,以及节点正常运行)。如果验证组件614确定补丁未验证(例如,补丁或相关联的资源、节点、应用等未根据定义的补丁管理标准正确执行),则验证组件614可以生成并呈现可以指示这样的补丁未被验证的指示符(例如,未验证的指示符)。
还原组件616可以在维护时间窗口内恢复(例如,撤销)补丁以将工作负载项(例如,资源、节点、应用或数据等)返回到执行补丁之前的先前状态,以响应补丁未被验证的确定。例如,在维护时间窗口期间,还原组件616可以接收与补丁相关的无效指示符,其可以指示补丁未被验证。响应于接收到无效指示符,还原组件616可以在维护时间窗口内还原补丁,并且可以将工作负载项(例如,资源、节点、应用或数据等)返回到该工作负载项的先前状态,然后再将补丁应用于工作负载项。
处理器组件618可以与其他组件(例如,补丁标识符组件602、补丁执行组件604、操作管理器组件606、……或数据存储620、……)结合工作以促进执行PMC的各种功能600。处理器组件618可以采用一个或多个处理器、微处理器或控制器,这些处理器、微处理器或控制器可以处理与工作负载相关联的数据,例如与补丁、工作负载、云计算环境、漏洞评分、节点之间的依赖关系、资源、应用、操作系统、中间件、VM、PM、容器、资源、节点、定义的补丁管理标准、定义的补丁管理算法、流量、策略、协议、接口、工具或其他信息等相关的信息,以促进PMC 600的操作,如本文更全面地公开,并控制PMC600和与PMC 600相关联(例如,与之连接)的其他组件(例如,计算机、膝上型计算机或其他计算或通信设备)之间的数据流。
数据存储620可以存储数据结构(例如,用户数据、元数据)、代码结构(例如,模块、对象、散列、类、过程)或指令,与工作负载、应用、操作系统、中间件、VM、PM、容器、资源、节点、定义的补丁管理标准、定义的补丁管理算法、流量、策略、协议、接口、工具或其他信息相关联的与补丁、工作负载、云计算环境、漏洞评分、节点之间的依赖关系、资源等相关的信息,以促进控制与PMC 600相关的操作。在一个方面,处理器组件622可以在功能上耦合(例如,通过存储器总线)到数据存储624,以便至少部分地存储和检索期望操作或赋予功能给补丁标识符组件602的信息、补丁执行组件604、操作管理器组件606、……或数据存储620等或PMC 600的基本上任何其他操作方面。
本文中已经(或将要)相对于若干组件之间的交互描述系统或设备。应当理解,这样的系统和组件可以包括在其中指定的那些组件或子组件,某些指定的组件或子组件或附加的组件。子组件也可以被实现为通信耦合至其它组件而非包括在父组件中的组件。此外,一个或多个组件或子组件可以组合成提供聚合功能的单个组件。组件也可以与本文为了简洁起见未描述但本领域的技术人公知的一个或多个其他组件交互。
图7示出了根据所公开主题的各个方面和实施例的用于管理与计算平台相关联的补丁的示例非限制性方法700的流程图。方法700可以由例如包括或可操作地耦合到补丁标识符组件、PMC、补丁执行组件或处理器组件的系统来执行。为简洁起见,在此描述的其他实施例中采用的相似元件的重复描述被或可以被省略。
在702,可以确定与计算平台相关联的工作负载,其中,工作负载可以包括第一工作负载部分,在该第一工作负载部分上可以执行补丁的第一子集。补丁标识符组件或PMC可以识别或确定工作负载(例如,混合工作负载),并且可以识别第一工作负载部分(例如,适用的资源、节点或应用,...),其中补丁的第一子集可以在第一工作负载部分执行,并且同时计算平台(例如,混合云计算环境)的第一工作负载部分在维护时间窗口期间离线,并且还可以识别或确定第二工作负载部分,当第二工作负载部分在线时,可以在该第二工作负载部分上执行补丁的第二子集。
在704,可以至少部分地基于与第一工作负载相关联的补丁的第一子集的补丁的漏洞评分来确定在维护时间窗口内应用于第一工作负载部分的一部分的补丁的第三子集,其中补丁的第一子集可以包括补丁的第三子集。至少部分地基于与第一工作负载部分相关联的补丁的第一子集的补丁的漏洞评分,PMC可以确定在维护时间窗口内应用到第一工作负载部分的部分(例如,部分)的补丁的第三子集,其中计算平台或其适用部分离线。例如,PMC可以确定在维护时间窗口期间没有足够的时间在该维护时间窗口期间执行第一工作负载部分中的所有补丁。PMC至少可以确定与第一工作负载部分相关联的补丁的第一子集的补丁的漏洞评分。至少部分地基于补丁的漏洞评分,PMC可以从补丁的第一子集确定补丁的第三子集以在维护时间窗口内应用于第一工作负载部分的部分。补丁的第三子集中的至少一些补丁可以比补丁的第一子集中的其他补丁具有相对更高的漏洞评分,这些补丁未被PMC选择为补丁的第三子集中。
图8描绘了根据所公开主题的各个方面和实施例的用于管理与计算平台相关联的补丁的另一示例非限制性方法800的流程图。方法800可以由例如包括或可操作地耦合到补丁标识符组件、PMC、补丁执行组件或处理器组件的系统来执行。为简洁起见,在此描述的其他实施例中采用的相似元件的重复描述被或可以被省略。
在802,可以针对与资源相关联的请求监控网络以促进确定资源之间的工作负载依赖关系。PMC可以监控网络(例如,计算或通信网络)与资源(例如,容器、VM、PM、其他资源或节点)相关联的请求以促进确定资源之间的工作负载依赖关系,其中工作负载依赖关系可以在第一种类型的项(例如,节点)和另一种类型的项(例如,VM或PM)之间或可以在相同类型的项(例如,第一种VM)之间和第二个虚拟机)。
在804,可以至少部分地基于针对请求对网络的监控来确定资源之间的工作负载依赖关系。PMC可以至少部分地基于对网络对请求的监控或通过确定此类工作负载依赖关系的其他手段来确定资源之间的工作负载依赖关系,如本文所述。在一些实施例中,PMC可以至少部分地基于对网络对请求的监控来确定或识别网络的拓扑或依赖关系树,如本文所述。
在806,可以至少部分地基于工作负载依赖关系确定包括用于在离线时由补丁的第一子集打补丁的第一工作负载部分和用于在线时由补丁的第二子集打补丁的第二工作负载部分的工作负载。PMC可以至少部分地基于与工作负载相关联的依赖关系来确定工作负载。工作负载可以包括第一工作负载部分,第一工作负载部分可以是在离线时(例如,至少部分由于此类工作负载项的工作负载依赖关系)将由补丁的第一子集打补丁的工作负载项或资源(例如,容器、VM、PM、其他资源、节点等),以及可以在线时由补丁的第二子集打补丁的第二工作负载部分。
在808,可以至少针对与第一工作负载部分相关联的补丁的第一子集的补丁确定漏洞评分。PMC可以至少为要在工作负载的第一工作负载部分上执行的补丁的第一子集的补丁确定(例如,计算)漏洞评分。在一些实施例中,PMC还可以为补丁的第二子集确定补丁的漏洞评分。
在810,可以根据定义的补丁管理标准和相关的补丁管理算法,至少部分基于补丁的漏洞评分和维护时间窗口从与第一工作负载部分相关联的补丁的第一子集确定用于第一工作负载部分的一部分的补丁的第三子集。PMC可以根据定义的补丁管理标准和相关的补丁管理算法,至少部分基于补丁的漏洞评分和维护时间窗口从与第一工作负载相关联的补丁的第一子集中确定可以应用于第一工作负载部分的该部分(例如,容器、VM、PM、其他资源或节点的子集,...)的补丁的第三子集。工作量部分,如这里更充分地描述的。
在812,可以在维护时间窗口期间对第一工作负载部分的一部分执行补丁的第三子集,而与第一工作负载部分的该部分相关联的资源、节点等是离线的。补丁执行组件可以在维护时间窗口期间对第一工作负载部分的一部分执行(例如,应用)补丁的第三子集,而与第一工作负载部分的该部分相关联的资源、节点、应用等是离线的。在一些实施例中,PMC可以根据网络的拓扑以拓扑顺序执行补丁的第三子集的补丁。在某些实施例中,补丁执行组件可以在多个项目(例如,容器、VM、PM、其他资源或节点,……)上同时(例如,并行地)执行补丁的第三子集的补丁,包括在可用维护时间窗口内的第一工作负载部分的该部分的具有依赖关系的项。PMC和补丁执行组件可以执行打补丁过程,以方便执行补丁的第三子集,其中,打补丁过程可以包括停止和重新启动与第一工作负载部分的一部分相关联的资源以及重新启动与补丁的第三子集相关联的节点,如本文更充分地描述的。
在814,可以在维护时间窗口期间验证对第一工作负载部分的该部分进行的打补丁。PMC可以在维护时间窗口内验证对第一个工作负载部分进行的打补丁,以帮助确保正确应用补丁,并确保补丁和第一工作负载部分的相应项目,以及整个计算系统在应用此类补丁后都能正常运行。
在816,如果确定补丁不能针对第一工作负载部分的一部分的工作负载项进行验证,则可以在维护时间窗口,将工作负载项返回到打补丁之前的先前状态。PMC可以确定补丁是否针对工作负载项(例如,容器、VM、PM、其他资源或节点等)进行了验证。响应于确定无法针对工作负载项验证补丁,PMC或补丁执行组件可以在维护时间窗口内恢复工作负载项上的补丁,以将工作负载项返回到打补丁之前的先前状态。
在818,可以对第二工作负载部分执行补丁的第二子集。补丁执行组件可以在第二工作负载部分上执行补丁的第二子集,其中,补丁的第二子集可以在至少第二工作负载部分在线时执行,或者可以在维护时间窗口期间或维护时间窗口之外执行。在某些实施例中,补丁执行组件可以同时(例如,并行地)在第二工作负载部分上执行补丁的第二子集的至少一部分补丁,其中在维护时间窗口期间对第一工作负载部分的部分执行补丁的第三子集的一部分。
PMC还可以验证在第二工作负载部分上执行的补丁以促进确保补丁被正确应用,并确保第二工作负载部分的一部分的补丁和相应项目,以及整个计算系统在应用此类补丁后都能正常运行。PMC可以确定是否针对工作负载项验证了特定补丁。响应于确定无法针对工作负载项验证特定补丁,PMC或补丁执行组件可以恢复工作负载项上的补丁以将工作负载项返回到打补丁之前的先前状态。
为了解释的简单,方法或计算机实现的方法被描绘和描述为一系列动作。应当理解和领会,所公开的主题不受所示动作或动作顺序的限制,例如动作可以以各种顺序发生或同时发生,并且与本文未呈现和描述的其他动作一起发生。此外,根据所公开的主题,并非所有图示的动作都需要实施计算机实现的方法。此外,本领域技术人员将理解,计算机实现的方法可替代地通过状态图或事件表示为一系列相互关联的状态。此外,还应当理解,下文和本说明书通篇所公开的计算机实现的方法能够存储在制品上,以便于将这种计算机实现的方法传输和转移到计算机。如本文所用,术语制造品旨在涵盖可从任何计算机可读设备或存储介质访问的计算机程序。
为了提供所公开主题的各个方面的上下文,图9以及以下讨论旨在提供合适的环境的一般描述,在该环境中所公开的主题的各个方面可以被实施的。图9图示了示例性非限制性操作环境的框图,其中可以促进在此描述的一个或多个实施例。为简洁起见,在此描述的其他实施例中采用的相似元件的重复描述被或可以被省略。参考图9,用于实现本公开的各个方面的合适的操作环境900还可以包括计算机912。计算机912还可以包括处理单元914、系统存储器916和系统总线918。系统总线918将包括但不限于系统存储器916的系统组件耦合到处理单元914。处理单元914可以是各种可用处理器中的任何一个。双微处理器和其他多处理器架构也可以用作处理单元914。系统总线918可以是几种类型的总线结构中的任何一种,包括内存总线或内存控制器、外围总线或外部总线或使用任何各种可用总线架构的本地总线,包括但不限于工业标准架构(ISA)、微通道架构(MSA)、扩展ISA(EISA)、智能驱动电子(IDE)、VESA本地总线(VLB)、外围组件互连(PCI)、卡总线、通用串行总线(USB)、高级图形端口(AGP)、火线(IEEE 1394)和小型计算机系统接口(SCSI))。系统存储器916还可以包括易失性存储器920和非易失性存储器922。基本输入/输出系统(BIOS)包含在计算机912内的元件之间传输信息的基本例程,例如在启动期间,存储在非易失性存储器922中。
作为说明而非限制,非易失性存储器922可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)、闪存或非易失性随机存取存储器(RAM)(例如,铁电RAM(FeRAM))。易失性存储器920还可以包括随机存取存储器(RAM),其充当外部高速缓冲存储器。作为说明而非限制,RAM有多种形式可用,例如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双倍数据速率SDRAM(DDR SDRAM)、增强型SDRAM(ESDRAM)、Synchlink DRAM(SLDRAM)、直接Rambus RAM(DRRAM)、直接Rambus动态RAM(DRDRAM)和Rambus动态RAM(RDRAM)。
计算机912还可以包括可移动/不可移动、易失性/非易失性计算机存储介质。例如,图9示出了磁盘存储器924。磁盘存储器924还可以包括但不限于诸如磁盘驱动器、软盘驱动器、磁带驱动器、Jaz驱动器、Zip驱动器、LS-100驱动器、闪存卡或记忆棒。磁盘存储器924还可以包括单独的或与其他存储介质组合的存储介质,包括但不限于,
光盘驱动器,例如光盘ROM设备(CD-ROM)、CD可记录驱动器(CD-R驱动器)、CD可重写驱动器(CD-RW驱动器)或数字多功能磁盘ROM驱动器(DVD-ROM)。为了便于将磁盘存储器924连接到系统总线918,通常使用可移动或不可移动接口,例如接口926。图9还描绘了充当用户和在合适的操作环境900中描述的基本计算机资源之间的中介的软件。这种软件还可以包括,例如,操作系统928。可以存储在磁盘存储器924上的操作系统928用于控制和分配计算机912的资源。系统应用程序930利用操作系统928通过程序模块932和程序数据934对资源的管理,例如存储在系统存储器916或磁盘存储器924上。应当理解,本公开可以用各种操作系统或操作系统的组合来实现。用户通过输入设备936将命令或信息输入计算机912。输入设备936包括但不限于诸如鼠标、轨迹球、触控笔、触摸板、键盘、麦克风、操纵杆、游戏手柄、卫星天线、扫描仪、电视调谐卡、数码相机、数码摄像机的定点设备、网络摄像头等。这些和其他输入设备经由接口端口938通过系统总线918连接到处理单元914。接口端口938包括例如串行端口、并行端口、游戏端口和通用端口。串行总线(USB)。输出设备940使用一些与输入设备936相同类型的端口。因此,例如,USB端口可用于向计算机912提供输入,并将信息从计算机912输出到输出设备940。提供输出适配器942以说明存在一些输出设备940,例如监视器、扬声器和打印机,以及需要特殊适配器的其他输出设备940。作为说明而非限制,输出适配器942包括提供输出设备940和系统总线918之间的连接方法的视频和声卡。应该注意的是,其他设备或设备系统提供输入和输出能力,例如远程计算机944。
计算机912可以使用到一个或多个远程计算机(例如远程计算机944)的逻辑连接在联网环境中操作。远程计算机944可以是计算机、服务器、路由器、网络PC、工作站、基于微处理器的设备、对等设备或其他常见网络节点等,并且通常还可以包括许多或所有相对于计算机912描述的元素。为了简洁起见,仅示出了具有远程计算机944的存储器存储设备946。远程计算机944通过网络接口948逻辑连接到计算机912,然后通过通信连接950物理连接。网络接口948包括有线或无线通信网络,例如局域网(LAN)、广域网(WAN)、蜂窝网络等。LAN技术包括光纤分布式数据接口(FDDI)、铜线分布式数据接口(CDDI)、以太网、令牌环等。WAN技术包括但不限于点对点链路、电路交换网络如综合业务数字网络(ISDN)及其变体、分组交换网络和数字用户线路(DSL)。通信连接950是指用于将网络接口948连接到系统总线918的硬件/软件。虽然通信连接950是为了在计算机912内部说明清楚而示出的,但它也可以在计算机912外部。用于连接到网络接口948的硬件/软件也可以包括(仅出于示例目的)内部和外部技术,例如调制解调器,包括常规电话级调制解调器、电缆调制解调器和DSL调制解调器、ISDN适配器和以太网卡。
Claims (25)
1.一种系统,包括:
存储器,存储计算机可执行组件;以及
处理器,可操作地耦合到存储器并执行计算机可执行组件,计算机可执行组件包括:
补丁标识符组件,识别与计算平台相关联的工作负载,其中工作负载包括第一工作负载部分,其中补丁的第一子集将在第一工作负载部分上执行;以及
补丁管理组件,基于补丁的第一子集的补丁漏洞评分确定在维护时间窗口内针对第一工作负载部分的一部分执行的补丁的第二子集,其中补丁的第一子集包括补丁的第二子集。
2.根据权利要求1所述的系统,其中补丁标识符组件识别与一组补丁相关联的工作负载,其中工作负载包括第一工作负载部分和第二工作负载部分,其中该组补丁包括补丁的第一子集,包括补丁的第二子集,以及包括补丁的第三子集,并且其中补丁管理组件确定要针对第二工作负载部分执行的补丁的第三子集。
3.根据权利要求2所述的系统,其中计算平台是基于云的计算平台,并且其中计算机可执行组件包括补丁执行组件,补丁执行组件在维护时间窗口内、在基于云的计算平台的第一工作负载部分离线时针对第一工作负载部分的一部分执行补丁的第二子集,并且在基于云的计算平台的第二工作负载部分在线时,针对第二工作负载部分执行补丁的第三子集。
4.根据权利要求3所述的系统,其中补丁执行组件同时执行补丁的第二子集的补丁的至少一部分,其中基于云的计算平台包括节点和资源,其中节点包括与第一工作负载部分的第一层级相关联的第一节点和与第一工作负载部分的第二层级相关联的第二节点,并且其中第二节点依赖于第一节点。
5.根据权利要求3所述的系统,其中基于云的计算平台包括节点和资源,其中补丁管理组件确定工作负载的拓扑,包括确定跨基于云的计算平台的节点的依赖关系,并且基于拓扑确定针对第一工作负载部分的补丁的第二子集的执行的拓扑顺序,并且其中补丁执行组件根据拓扑顺序执行补丁的第二子集的补丁。
6.根据权利要求3所述的系统,其中补丁执行组件与补丁的第三子集的至少一个补丁同时地执行补丁的第二子集的至少另一个补丁。
7.根据权利要求1所述的系统,其中维护时间窗口为计算平台与第一工作负载部分相关的节点和资源离线的时间段。
8.根据权利要求1所述的系统,其中补丁管理组件基于补丁的定义的重要性级别确定与第一工作负载部分相关联的补丁的第一子集的补丁的漏洞评分,并且基于确定补丁的第二子集具有比补丁的其他子集的其他总漏洞评分更高的总漏洞评分确定补丁的第二子集。
9.根据权利要求1所述的系统,其中计算平台包括节点和资源,其中节点中的一个节点选自包括虚拟机、物理机和容器的节点组,并且其中补丁中的第一个补丁在虚拟机的虚拟机实例上执行,补丁的第二个补丁在物理机的物理机实例上执行,并且补丁的第三个补丁在容器的容器映像上执行。
10.根据权利要求1所述的系统,其中补丁管理组件暂停与补丁的第二子集相关联的节点和资源的操作,其中计算机可执行组件包括补丁执行组件,响应于操作的暂停针对节点和资源执行补丁的第二子集,并且其中补丁管理组件验证补丁的第二子集已成功执行,并且,响应于验证补丁的第二子集已成功执行,重新启动节点和资源的操作。
11.根据权利要求1所述的系统,其中补丁管理组件响应于针对应用执行的补丁的第二子集的补丁测试应用是否处于定义的健康运行状态,并且其中,响应于确定应用未处于定义的健康运行状态,补丁管理组件在维护时间窗口内恢复针对应用的补丁的实施,以将应用恢复到针对应用执行补丁之前存在的先前状态。
12.根据权利要求1所述的系统,其中计算平台是基于混合云的计算平台,并且其中工作负载是跨多个维度的混合工作负载并且与选自混合云计算平台的一组特征相关,包括多个云计算子平台、多个操作系统、云部署模型、资源部署类型、工作负载类型、工作负载的执行频率以及开发和运营流程。
13.根据权利要求1所述的系统,其中补丁管理组件识别在维护时间窗口期间未执行的未应用补丁并确定下一个维护时间窗口以执行至少一部分未应用补丁。
14.一种计算机实现的方法,包括:
由可操作地耦合到处理器的系统确定与计算平台相关联的工作负载,其中,工作负载包括第一工作负载部分,补丁的第一子集将在第一工作负载部分上执行;以及
由系统基于补丁的第一子集的补丁漏洞评分确定在维护时间窗口内应用到第一工作负载部分的一部分的补丁的第二子集,其中补丁的第一子集包括补丁的第二子集。
15.根据权利要求14所述的计算机实现的方法,其中工作负载包括第一工作负载部分和第二工作负载部分,其中确定工作负载包括确定与一组补丁相关的工作负载,其中该组补丁包括补丁的第一子集,包括补丁的第二子集,以及包括补丁的第三子集,并且其中方法还包括由系统确定要应用于第二工作负载部分的补丁的第三子集。
16.根据权利要求15所述的计算机实现的方法,其中计算平台是基于云的计算平台,并且其中方法进一步包括:
由系统在基于云的计算平台的第一工作负载部分的至少一部分离线时、在维护时间窗口内将补丁的第二子集应用到第一工作负载部分的一部分,其中并行应用补丁的第二子集的第一补丁和第二补丁,其中维护时间窗口为云计算平台与第一工作负载部分相关的节点和资源离线的时间段;以及
由系统在基于云的计算平台的第二工作负载部分在线时、将补丁的第三子集应用到第二工作负载部分,其中并行应用补丁的第三子集的第三补丁和第一补丁。
17.根据权利要求14所述的计算机实现的方法,还包括:
由系统基于定义的补丁的漏洞级别确定与第一工作负载部分相关联的补丁的第一子集的补丁的漏洞评分;以及
由系统确定补丁的第二子集具有比补丁的其他子集的其他总漏洞评分更高的总漏洞评分,其中确定在维护时间窗口内应用到第一工作负载部分的一部分的补丁的第二子集包括基于确定补丁的第二子集具有更高的总漏洞评分确定补丁的第二子集。
18.根据权利要求14所述的计算机实现的方法,还包括:
由系统暂停与补丁的第二子集相关联的节点和资源的操作;
由系统响应于操作的暂停向节点和资源应用补丁的第二子集;
由系统验证补丁的第二子集是否成功应用于节点和资源;以及
由系统响应于验证补丁的第二子集已成功应用于节点和资源,重新启动节点和资源的操作。
19.根据权利要求14所述的计算机实现的方法,还包括:
由系统响应于针对应用应用补丁的第二子集的补丁,执行测试以确定应用是否处于定义的可用操作状态;以及
由系统响应于确定应用未处于定义的可用操作状态,在维护时间窗口内恢复与应用相关的补丁的实施,以将应用恢复到针对应用应用补丁之前存在的先前状态。
20.一种促进管理计算平台打补丁的计算机程序产品,该计算机程序产品包括计算机可读存储介质,该计算机可读存储介质具有体现在其中的程序指令,该程序指令可由处理器执行以使得该处理器:
确定与计算平台相关联的工作负载,其中,工作负载包括第一工作负载部分,补丁的第一子集将在第一工作负载部分上执行;以及
基于补丁的第一子集的补丁漏洞评分确定在停机时间窗口内应用到第一工作负载部分的一部分的补丁的第二子集,其中补丁的第一子集包括补丁的第二子集。
21.根据权利要求20所述的计算机程序产品,其中工作负载包括第一工作负载部分和第二工作负载部分,其中确定工作负载包括确定与一组补丁相关的工作负载,其中该组补丁包括补丁的第一子集,包括补丁的第二子集,以及包括补丁的第三子集,其中计算平台是基于云的计算平台,其中程序指令可由处理器执行以使处理器执行:
确定应用于第二工作负载部分的补丁的第三子集;
在基于云的计算平台的第一工作负载部分的至少一部分离线时,将补丁的第二子集应用于停机时间窗口内的第一工作负载部分的一部分,其中同时应用补丁的第二子集的第一补丁和第二补丁,其中停机时间窗为云计算平台的与第一工作负载部分相关的节点和资源处于离线状态的时间段;并且
在基于云的计算平台的第二工作负载部分在线时,将补丁的第三子集应用到第二工作负载部分,其中同时应用补丁的第三子集的第三补丁和第一补丁。
22.一种系统,包括:
存储器,存储计算机可执行组件;以及
处理器,可操作地耦合到存储器并执行计算机可执行组件,计算机可执行组件包括:
更新标识符组件,用于识别与计算平台相关联的工作负载,其中工作负载包括第一工作负载部分,更新的第一子集将在第一工作负载部分上执行,以及第二工作负载部分,更新的第二子集将在第二工作负载部分上执行;以及
更新管理组件,基于与第一工作负载部分相关联的更新的第一子集的更新漏洞评分确定在维护时间段内应用于第一工作负载部分的一部分的更新的第三子集,其中,更新的第一子集包括更新的第三子集。
23.根据权利要求22所述的系统,其中更新标识符组件识别与一组更新相关联的工作负载,其中该组更新包括更新的第一子集,包括更新的第三子集,以及包括更新的第二子集,其中计算平台是基于混合云的计算平台,并且其中计算机可执行组件包括更新执行组件,更新执行组件在基于混合云的计算平台的第一工作负载部分的至少一部分处于离线状态时、在维护时间段内将更新的第三子集应用于第一工作负载部分,并在基于混合云的计算平台的第二工作负载部分在线时,将更新的第二子集应用到第二工作负载部分。
24.一种有促进管理计算平台的更新的计算机程序产品,该计算机程序产品包括计算机可读存储介质,该计算机可读存储介质具有体现在其中的程序指令,该程序指令可由处理器执行以使得该处理器:
识别与计算平台相关联的工作负载,其中工作负载包括第一工作负载部分,更新的第一子集将在第一工作负载部分上执行,以及第二工作负载部分,更新的第二子集将在第二工作负载部分上执行;以及
基于与第一工作负载部分相关联的更新的第一子集的更新漏洞评分确定在离线维护时间段内应用于第一工作负载部分的一部分的更新的第三子集,其中,更新的第一子集包括更新的第三子集。
25.根据权利要求24所述的计算机程序产品,其中计算平台是基于混合云的计算平台,其中识别工作负载包括识别与一组更新相关联的工作负载,其中该组更新包括更新的第一子集,包括更新的第三子集,以及包括更新的第二子集,其中该程序指令可由处理器执行以使得该处理器:
在基于混合云的计算平台的第一工作负载部分的至少一部分离线时,在离线维护时间段内将更新的第三子集应用到第一工作负载部分;以及
在基于混合云的计算平台的第二工作负载部分在线时,将更新的第二子集应用到在线工作负载。
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/259,205 US10754637B1 (en) | 2019-01-28 | 2019-01-28 | Patch management in a hybrid computing environment |
US16/259,205 | 2019-01-28 | ||
PCT/IB2020/050492 WO2020157607A1 (en) | 2019-01-28 | 2020-01-22 | Patch management in a hybrid computing environment |
Publications (2)
Publication Number | Publication Date |
---|---|
CN113330723A true CN113330723A (zh) | 2021-08-31 |
CN113330723B CN113330723B (zh) | 2023-06-27 |
Family
ID=71837640
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202080010744.5A Active CN113330723B (zh) | 2019-01-28 | 2020-01-22 | 混合计算环境中的补丁管理 |
Country Status (6)
Country | Link |
---|---|
US (1) | US10754637B1 (zh) |
JP (1) | JP7292786B2 (zh) |
CN (1) | CN113330723B (zh) |
DE (1) | DE112020000123T5 (zh) |
GB (1) | GB2593657A (zh) |
WO (1) | WO2020157607A1 (zh) |
Families Citing this family (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10997208B2 (en) | 2019-02-13 | 2021-05-04 | Sap Se | In-memory database-managed container volume replication |
US11422973B2 (en) * | 2019-03-06 | 2022-08-23 | Sap Se | Peer-to-peer delta image dispatch system |
US11403320B2 (en) | 2019-03-06 | 2022-08-02 | Sap Se | Elastic in-memory database provisioning on database-as-a-service |
US11119753B2 (en) | 2019-05-06 | 2021-09-14 | Paypal, Inc. | Distributed autonomous patching system |
US11003436B2 (en) * | 2019-10-15 | 2021-05-11 | Dell Products L.P. | Composable infrastructure update system |
US11200046B2 (en) * | 2019-10-22 | 2021-12-14 | Lenovo Enterprise Solutions (Singapore) Pte. Ltd. | Managing composable compute system infrastructure with support for decoupled firmware updates |
US11546354B2 (en) * | 2019-11-26 | 2023-01-03 | Kyndryl, Inc. | Network shutdown for cyber security |
US11550919B2 (en) * | 2020-02-24 | 2023-01-10 | EMC IP Holding Company LLC | Prioritizing patching of vulnerable components |
EP4115597A1 (en) | 2020-03-03 | 2023-01-11 | Level 3 Communications, LLC | Containing a faulty stimulus in a content delivery network |
CN112306626B (zh) | 2020-09-01 | 2024-04-05 | 北京京东尚科信息技术有限公司 | 用于更新云平台的方法和装置 |
US11513877B2 (en) * | 2020-09-22 | 2022-11-29 | Rockwell Automation Technologies, Inc. | Updating operational technology devices using container orchestration systems |
US11474873B2 (en) | 2020-09-22 | 2022-10-18 | Rockwell Automation Technologies, Inc. | Implementing serverless functions using container orchestration systems and operational technology devices |
US11973770B1 (en) * | 2020-12-09 | 2024-04-30 | Wiz, Inc. | Techniques for multi-tenant vulnerability scanning |
US11748241B2 (en) * | 2021-01-19 | 2023-09-05 | Dell Products, L.P. | Method and apparatus for generating simulated test IO operations |
US11645120B2 (en) * | 2021-02-09 | 2023-05-09 | Nokia Solutions And Networks Oy | Memory bandwidth allocation for multi-tenant FPGA cloud infrastructures |
US11599352B2 (en) | 2021-06-11 | 2023-03-07 | EMC IP Holding Company LLC | Method of creating an intelligent upgrade flow for a heterogeneous data center |
US11531592B1 (en) | 2021-06-11 | 2022-12-20 | EMC IP Holding Company LLC | Method and system for determining favorability of upgrade window |
US11561777B2 (en) * | 2021-06-11 | 2023-01-24 | EMC IP Holding Company LLC | System and method for intelligent update flow across inter and intra update dependencies |
US11909756B2 (en) * | 2021-08-12 | 2024-02-20 | Servicenow, Inc. | Automatic identification of change requests to address information technology vulnerabilities |
US11656864B2 (en) | 2021-09-22 | 2023-05-23 | International Business Machines Corporation | Automatic application of software updates to container images based on dependencies |
US20230119503A1 (en) * | 2021-10-18 | 2023-04-20 | Sophos Limited | Network configuration update |
KR102605212B1 (ko) * | 2021-10-22 | 2023-11-24 | 슈어소프트테크주식회사 | 동일 위치에 대한 다수의 패치들 중 최종 패치를 선택하는 방법 및 최종 패치 선택 모듈 |
US20230252157A1 (en) * | 2022-02-04 | 2023-08-10 | Oracle International Corporation | Techniques for assessing container images for vulnerabilities |
US20230351020A1 (en) * | 2022-04-27 | 2023-11-02 | Amdocs Development Limited | System, method, and computer program for orchestrating patching of microservices |
US20230376604A1 (en) * | 2022-05-19 | 2023-11-23 | Microsoft Technology Licensing, Llc | Determination of mitigation priority values of vulnerabilities in container images |
US11947342B1 (en) | 2022-09-19 | 2024-04-02 | Rockwell Automation Technologies, Inc. | Container registry and subscription service for industrial systems |
US11846918B1 (en) | 2022-09-22 | 2023-12-19 | Rockwell Automation Technologies, Inc. | Data driven digital twins for industrial automation device operation enhancement |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130047147A1 (en) * | 2011-08-16 | 2013-02-21 | Campbell McNeill | Virtual Machine Asynchronous Patch Management |
CN103366120A (zh) * | 2012-04-10 | 2013-10-23 | 中国信息安全测评中心 | 基于脚本的漏洞攻击图生成方法 |
CN104573525A (zh) * | 2014-12-19 | 2015-04-29 | 中国航天科工集团第二研究院七〇六所 | 一种基于白名单的专用信息服务软件漏洞修复系统 |
US20160103671A1 (en) * | 2014-10-08 | 2016-04-14 | International Business Machines Corporation | Analytical Software Patch Management |
CN107977579A (zh) * | 2017-12-19 | 2018-05-01 | 福建中金在线信息科技有限公司 | 一种管理漏洞信息的方法及装置 |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6847970B2 (en) | 2002-09-11 | 2005-01-25 | International Business Machines Corporation | Methods and apparatus for managing dependencies in distributed systems |
US20070169079A1 (en) | 2005-11-08 | 2007-07-19 | Microsoft Corporation | Software update management |
US20080178173A1 (en) * | 2007-01-23 | 2008-07-24 | Oracle International Corporation | Enhanced Flexibility in Deployment of Patches to Fix Errors in Pre-installed Software |
US8839221B2 (en) | 2007-09-10 | 2014-09-16 | Moka5, Inc. | Automatic acquisition and installation of software upgrades for collections of virtual machines |
JP5104628B2 (ja) | 2008-06-30 | 2012-12-19 | 株式会社三洋物産 | 遊技機 |
JP5206792B2 (ja) * | 2008-09-12 | 2013-06-12 | 富士通株式会社 | ソフトウェアパッチ適用方法、プログラム及び装置 |
US9158533B2 (en) * | 2012-01-16 | 2015-10-13 | International Business Machines Corporation | Manipulating source code patches |
US9047133B2 (en) | 2012-03-02 | 2015-06-02 | Vmware, Inc. | Single, logical, multi-tier application blueprint used for deployment and management of multiple physical applications in a cloud environment |
US10042625B2 (en) | 2015-03-04 | 2018-08-07 | International Business Machines Corporation | Software patch management incorporating sentiment analysis |
US9710253B2 (en) * | 2015-04-16 | 2017-07-18 | Commvault Systems, Inc. | Managing a software-patch submission queue |
JP6380461B2 (ja) * | 2016-06-02 | 2018-08-29 | 住友電気工業株式会社 | 中継装置、プログラム更新システム、およびプログラム更新方法 |
US9959111B2 (en) * | 2016-07-11 | 2018-05-01 | Sap Se | Prioritization of software patches |
US10073691B2 (en) | 2016-08-23 | 2018-09-11 | Cisco Technology, Inc. | Containerized upgrade in operating system level virtualization |
US10452387B2 (en) | 2016-09-16 | 2019-10-22 | Oracle International Corporation | System and method for partition-scoped patching in an application server environment |
CN107480533B (zh) * | 2017-08-08 | 2022-05-24 | 深圳市腾讯计算机系统有限公司 | 一种漏洞修复的方法、装置及存储介质 |
US10791137B2 (en) * | 2018-03-14 | 2020-09-29 | Synack, Inc. | Risk assessment and remediation |
-
2019
- 2019-01-28 US US16/259,205 patent/US10754637B1/en active Active
-
2020
- 2020-01-22 DE DE112020000123.7T patent/DE112020000123T5/de active Pending
- 2020-01-22 GB GB2110941.8A patent/GB2593657A/en not_active Withdrawn
- 2020-01-22 CN CN202080010744.5A patent/CN113330723B/zh active Active
- 2020-01-22 WO PCT/IB2020/050492 patent/WO2020157607A1/en active Application Filing
- 2020-01-22 JP JP2021542184A patent/JP7292786B2/ja active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20130047147A1 (en) * | 2011-08-16 | 2013-02-21 | Campbell McNeill | Virtual Machine Asynchronous Patch Management |
CN103366120A (zh) * | 2012-04-10 | 2013-10-23 | 中国信息安全测评中心 | 基于脚本的漏洞攻击图生成方法 |
US20160103671A1 (en) * | 2014-10-08 | 2016-04-14 | International Business Machines Corporation | Analytical Software Patch Management |
CN104573525A (zh) * | 2014-12-19 | 2015-04-29 | 中国航天科工集团第二研究院七〇六所 | 一种基于白名单的专用信息服务软件漏洞修复系统 |
CN107977579A (zh) * | 2017-12-19 | 2018-05-01 | 福建中金在线信息科技有限公司 | 一种管理漏洞信息的方法及装置 |
Non-Patent Citations (1)
Title |
---|
滕扬新等: "论WinXP补丁的另类修复", 《网络安全技术与应用》 * |
Also Published As
Publication number | Publication date |
---|---|
DE112020000123T5 (de) | 2021-08-26 |
WO2020157607A1 (en) | 2020-08-06 |
JP7292786B2 (ja) | 2023-06-19 |
GB202110941D0 (en) | 2021-09-15 |
CN113330723B (zh) | 2023-06-27 |
GB2593657A (en) | 2021-09-29 |
US20200249928A1 (en) | 2020-08-06 |
JP2022520005A (ja) | 2022-03-28 |
US10754637B1 (en) | 2020-08-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN113330723B (zh) | 混合计算环境中的补丁管理 | |
US11074057B2 (en) | System and method for determining when cloud virtual machines need to be updated | |
US11182220B2 (en) | Proactive high availability in a virtualized computer system | |
US10897497B2 (en) | Automated infrastructure updates in a cluster environment that includes containers | |
US11307939B2 (en) | Low impact snapshot database protection in a micro-service environment | |
US9479416B2 (en) | System and method for diagnosing information technology systems in multiple virtual parallel universes | |
US10282279B2 (en) | System and method for diagnosing information technology systems in multiple virtual parallel universes | |
US9535754B1 (en) | Dynamic provisioning of computing resources | |
US20150127970A1 (en) | Selected Virtual Machine Replication and Virtual Machine Restart Techniques | |
CN108139943B (zh) | 计算机负载的多个维度的准确生成 | |
US10534655B1 (en) | Job scheduling based on job execution history | |
US11989539B2 (en) | Continuous integration and deployment system time-based management | |
US10817278B1 (en) | Controlling the approval of software updates for computing resources | |
Boza et al. | A case for performance-aware deployment of containers | |
Posey et al. | Addressing the challenges of executing a massive computational cluster in the cloud | |
US11461131B2 (en) | Hosting virtual machines on a secondary storage system | |
US11907106B2 (en) | Code integration with time-variant test failure detection | |
US20220350596A1 (en) | Computing node allocation based on build process specifications in continuous integration environments | |
US20230333970A1 (en) | Smart test case execution cycle assignment mechanism | |
US11809309B2 (en) | Test result stability scoring in integration testing | |
US20230168918A1 (en) | Managing data access by communication protocols in continuous integration environments | |
US20240232018A1 (en) | Intended state based management of risk aware patching for distributed compute systems at scale | |
US20180285150A1 (en) | Phased start and stop of resources in a mainframe environment |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |