Patch management in a hybrid data management environment

Abstract

System (100), comprising: a working memory that stores components executable by a computer; and a processor that is operatively connected to the main memory, which executes computer-executable components, wherein the computer-executable components include: a patch identification component (116) that identifies a workload which belongs to a set of patches which belongs to a hybrid cloud-based data processing platform, wherein the workload has a first workload part for which a first subset of patches is to be performed, and a second workload part; a patch management component (114) that: a second subset of patches is determined, which is to be executed with respect to a part of the first workload part based on hazard assessments of patches of the first subset of patches within a maintenance window, wherein the first subset of patches includes the second subset of patches, a third subset of patches is determined to be executed with respect to the second workload part, wherein the set of patches comprises the first subset of patches, the second subset of patches, and the third subset of patches; and a patch execution component (118) that executes the second subset of patches with respect to the part of the first workload part within the maintenance window while the first workload part of the cloud-based hybrid computing platform is offline, and executes the third subset of patches with respect to the second workload part while the second workload part of the cloud-based hybrid computing platform is online.

Description

BACKGROUND

[0001] The present disclosure relates to systems connected with a computer and, in particular, to patch management in a hybrid data processing environment.

[0002] US 2016 / 0103673A1 discloses a method in which computer systems are grouped according to their characteristics and each group is assigned adapted bundles of software patches to achieve maximum patch coverage.

[0003] DE 11 2013 000 368 T5 discloses a computer device and a computer-implemented method that are configured to automatically split a source code patch with multiple modification instructions into sub-patches whose sequential application corresponds to the original patch.

[0004] US 2016 / 0 306 618 A1 discloses a system in which a build server selects software patches not in arrival order, but based on dynamically calculated priority values ​​derived from the attributes of the respective patches.

[0005] US 2016 / 0004528A1 discloses a method for efficiently updating multiple computer systems in heterogeneous environments, using a custom installer on each device to identify, retrieve, and apply software patches in parallel. SUMMARY

[0006] The object of the invention is to provide two systems, a computer-implemented method and two computer program products for patch management in a hybrid data processing environment.

[0007] The following summary is intended to provide a basic understanding of one or more embodiments of the disclosed subject matter. This summary is not intended to identify central or critical elements or to define any kind of scope of the specific embodiments or any kind of scope of the claims. Rather, its sole purpose is to present concepts in a simplified form as an introduction to the more detailed description presented later. One or more embodiments described here include systems, units, structures, computer-implemented methods, devices, or computer program products that enable the management of an application of patches belonging to a workload of a data processing system.

[0008] According to one embodiment, a computer-implemented method includes the determination of a workload belonging to a data processing platform by a system operatively connected to a processor, wherein the workload comprises a first workload segment for which a first subset of patches is to be applied. The computer-implemented method further includes the determination of a second subset of patches by the system, which is to be applied to a portion of the first workload segment within a maintenance time window based on hazard assessments of patches from the first subset of patches, wherein the first subset of patches comprises the second subset of patches.

[0009] In some embodiments, the elements described in connection with the disclosed methods may be included in various forms, e.g. as a system, a computer program product, or another form.

[0010] According to another embodiment, a system may have a main memory that stores computer-executable components; and a processor operatively connected to the main memory that executes computer-executable components. The computer-executable components may include an update identification component that identifies a workload belonging to a data processing platform, wherein the workload comprises a first workload part for which a first subset of updates is to be performed, and a second workload part for which a second subset of updates is to be performed.The computer-executable components may also include an update management component that determines a third subset of updates to be applied to a portion of the first workload portion within a maintenance period, based on hazard assessments of updates to the first subset of updates belonging to the first workload portion, wherein the first subset of updates includes the third subset of updates.

[0011] In some embodiments, elements described in connection with the disclosed systems can be implemented in various forms, e.g. as a computer-implemented method, a computer program product, or another form.

[0012] These and other features will become apparent from the following detailed description of illustrative embodiments thereof, which should be read in conjunction with the accompanying drawings. DESCRIPTION OF THE DRAWINGS Fig. Figure 1 illustrates, according to various aspects and embodiments of the disclosed subject matter, a block diagram of a non-restrictive example system that can be used to efficiently manage patches and apply them to a data processing system. Fig. Figure 2 represents, according to various aspects and embodiments of the disclosed subject matter, a diagram of a non-restrictive example data processing system that has workloads which can span multiple dimensions. Fig. Figure 3 shows, according to various aspects and embodiments of the disclosed subject matter, a block diagram of an example patch sequence for applying patches during a maintenance window while the workload associated with the patches is offline. Fig. Figure 4 illustrates, according to various aspects and embodiments of the disclosed subject matter, a diagram of an example application topology in connection with determining dependencies between resources of a workload and a patch management system. Fig. Figure 5 presents, according to various aspects and embodiments of the disclosed subject matter, a diagram of an example patch selection with respect to an example workload belonging to a data processing system, in conjunction with dependencies between workload resources and a patch management system. Fig. Figure 6 illustrates a block diagram of an example patch management component 600 according to different aspects and embodiments of the disclosed subject matter. Fig. Section 7 presents, according to various aspects and embodiments of the disclosed subject matter, a flowchart of a further non-restrictive example method for managing patches belonging to a data processing platform. Fig. Figure 8 shows, according to various aspects and embodiments of the disclosed subject matter, a flowchart of a further non-restrictive example method for managing patches belonging to a data processing platform. Fig. Figure 9 illustrates a block diagram of a non-restrictive example operating environment in which one or more embodiments described here can be enabled. DETAILED DESCRIPTION

[0013] The following detailed description serves only for illustration and is not intended to limit embodiments or any application or use of embodiments. Furthermore, no binding effect is intended by any express or implied information contained in the preceding sections "Background" or "Summary" or in the section "Detailed Description".

[0014] One or more embodiments will now be described with reference to the drawings, where identical reference numerals are intended to denote identical elements. For the purpose of clarification, numerous specific details are presented in the following description to provide a more thorough understanding of the one or more embodiments. However, it should be obvious in several cases that the one or more embodiments can also be implemented without these specific details.

[0015] Malware attacks can cause systems connected to a computer to fail, resulting in significant downtime and recovery costs (e.g., thousands, tens of thousands, hundreds of thousands of dollars) for businesses and other entities. Businesses typically lack the time and resources to patch thousands of systems (e.g., systems connected to a computer), while others spend time and resources they don't actually have to do so.

[0016] Automated patching of computer-related systems can be a cost-effective alternative to manual patching of computer-related systems and to the risks associated with not patching them. It can be useful and desirable to weigh the costs of patching or not patching computer-related systems, or parts thereof, against the level of risk and, based on such a cost-risk assessment, to determine when and which patches should be applied.

[0017] Another consideration regarding patching is that patching time is generally not a constant and that a number of factors can affect it. The diversity of systems (e.g., differences in platforms, configurations, and deployed applications) can increase the likelihood that at least some patches will fail, as non-standard systems can be relatively difficult to test.

[0018] Another consideration is that it is generally better to patch computer-related systems or parts thereof as early as possible, when the cost of patching is lower than or equal to the cost of not patching. The risk to unpatched computer-related systems can typically increase considerably (e.g., dramatically) once an exploit for a computer-related system or systems becomes publicly available.

[0019] Another consideration is that patches for computer-related systems can sometimes contain errors. Consequently, it may be desirable to be able to validate that a patch, or the computer-related system for which the patch was implemented, functions acceptably after the patch is implemented. Furthermore, if the patch or the computer-related system does not function acceptably, it may be desirable to revert or undo the patch, restoring the computer-related system to its previous state before the patch was implemented.

[0020] Applying patches to hybrid workloads of systems connected to a computer can present further and significant challenges. For example, different data processing conditions and specifications may exist, and the workloads themselves can vary. A hybrid workload can consist of (or span) multiple dimensions, including, for example, a multi-cloud or multi-operating-system architecture, a type of cloud deployment model (e.g., traditional data processing infrastructure, private cloud, or public cloud; on-premises or shared; dedicated or shared, etc.), a type of deployment (e.g., bare-metal machine, virtual machine (VM), container, external service, etc.), and a type of workload (e.g.,Batch workloads, transactional workloads, analytical workloads, high-performance workloads, database workloads, or workloads with high demands on the central processing unit (CPU), hard drive, or processor, etc.), patching frequency (e.g., monthly or end-of-month patching, patching with varying variability, etc.), or development and operations (DevOps) processes. Dependencies may also exist between different stages (e.g., nodes) of the workload.

[0021] Furthermore, patching of nodes can be performed online or live, for example, in the context of a clustered or always-online service, or offline, in which case the patching must be carried out while the nodes and the associated application(s) are offline. Another challenge is that there is typically a limited downtime window available during which patches can be performed on nodes and associated applications while offline. A further challenge to consider is that the importance, priority, or severity (e.g., risk score) associated with patches can vary, as some patches may have a high level of importance, others a medium level, and still others a relatively low level of importance.It should also be mentioned that currently it is usually the responsibility of users (e.g. customers) to patch the operating system, middleware and applications separately within the limits of the infrastructure in question.

[0022] For this purpose, the various embodiments herein refer to methods for managing patches in a data processing environment, such as a hybrid data processing environment (e.g., a hybrid cloud computing environment). A patch identification component can identify a workload belonging to a data processing platform. The workload can have a first workload portion for which a first subset of patches can be applied offline, and a second workload portion for which a second subset of patches can be applied online. A patch management component (PMC) can define a subset (e.g.,The PMC can determine a third subset of patches from the first subset that can be applied within a maintenance window, based on the hazard ratings of patches from the first subset, for a portion of the first workload while offline. It can also determine the second subset of patches for the second workload that can be applied while online. The PMC can determine, at least partially, the hazard ratings of individual patches or group hazard ratings of patches (e.g., different patch groupings) based on their relative importance. This allows it to identify the portion (e.g., the third subset) of the first subset of patches to be applied during the maintenance window, as well as the second subset of patches to be applied to the second workload.In some embodiments, at least some of the patches of the third subset of patches can be applied simultaneously or in parallel to each other, or at least some of the patches of the second subset of patches can be applied simultaneously or in parallel to each other or to at least some of the patches of the third subset of patches.

[0023] A patch execution component can, within the maintenance window, execute the third subset of patches for the first workload segment while the first workload segment is offline, and execute the second subset of patches for the second workload segment while the second workload segment can be online during these patch executions (e.g., applied). The PMC can validate the applied patches and the associated workload while still within the maintenance window to ensure that the patches and the associated workload are functioning correctly. If the PMC determines that a patch is not being validated (e.g., that such a patch or one or more workload elements are not functioning correctly after the patch is applied), the PMC can retract the patch within the maintenance window to correct the one or more workload elements in its or the other workload elements.to restore their previous state before the patch was applied.

[0024] These and other aspects and embodiments of the disclosed subject matter will now be described with reference to the drawings.

[0025] Fig. Figure 1 illustrates, according to various aspects and embodiments of the disclosed subject matter, a block diagram of a non-restrictive example system 100 that can be used to efficiently manage and apply patches to a data processing system. The system 100 may include a data processing system 102, which may have various components. The data processing system 102 may include one or more networks (e.g., data processing or data transmission networks). In some embodiments, the data processing system 102 may be multidimensional, spanning multiple dimensions and including workloads (e.g., hybrid workloads) that can span the multiple dimensions of the data processing system 102.For example, the data processing system 102 can have a multi-cloud or multi-operating-system architecture, can provide a multi-dimensional deployment model (e.g., traditional data processing infrastructure, private cloud or public cloud; on-premises or external premises; dedicated or shared, etc.), can use different types of components or units (e.g., bare-metal machine, VM, container, external service, etc.) that can span multiple stages or multiple parts of the multi-dimensional deployment model, and can support different types of workloads (e.g., batch workload, transactional workload, analytics workload, high-performance workload, database workload, or a workload with high CPU, disk, or processor requirements, etc.).) which can span the multiple dimensions of the data processing system 102, may include DevOps processes or other features that can span the multiple dimensions of the data processing system 102, as described in more detail here.

[0026] The data processing system 102 can comprise various containers 104, virtual machines (VMs) 106, physical machines (PMs) 108, other resources 110, and nodes 112, which can be arranged relative to one another or be related to one another to form the data processing system 102 and provide various services (e.g., data processing-related services and applications). For example, the various containers 104, VMs 106, PMs 108, other resources 110, or nodes 112 can span multiple dimensions of the data processing system 102 and be arranged in multiple levels (e.g., a container 104 can be in a first level and belong to another container 104 or VM 106 in a second level, or the other container 104 or VM 106 can belong to another VM 106 or PM 108 in a third level, and so on).), as described in more detail here. According to various embodiments, a container 104, a VM 106, a PM 108, or another resource 110 can be a node 112, be part of it, or belong to it.

[0027] At various times, it may be desirable to apply patches to computer programs or associated data to improve the data processing system 102. A patch can be a software element designed to update, correct errors, or improve a computer program or the data supporting it. A patch may include fixing security vulnerabilities or other errors, or improving the usability or performance of the computer program through updates to the computer program. Patches for a node, which may belong to one or more levels, are not usually limited to the operating system (e.g., a first type of operating system, a second type of operating system, a third type of operating system, etc.) but may also be applied to the software (e.g., application, middleware, or database) installed on the node.

[0028] To enable the application of patches, the system 100 can have a Patch Management Component (PMC) 114 (also referred to as an Update Management Component) that can manage (e.g., control) the application of patches to the various containers 104, VMs 106, PMs 108, other resources 110, nodes 112, applications, associated data, etc., according to defined patch management criteria and one or more associated patch management algorithms. The PMC 114 can have a Patch Identification Component 116 (also referred to as an Update Identification Component) that can identify or determine patches that need to be applied (e.g., during a maintenance window), and a Patch Execution Component 118 (also referred to as an Update Execution Component) that can execute patches (e.g.,can perform or execute (or perform or execute in these) selected patches for the various containers 104, VMs 106, PMs 108, other resources 110, nodes 112, applications or associated data, etc. (e.g., apply).

[0029] Some patches can be applied to certain components (e.g., container 104, VM ​​106, PM 108, other resource 110, or node 112, etc.) of system 100 while those components are online, whereas certain patches can only be applied to specific components (e.g., specific container 104, VM ​​106, PM 108, other resource 110, or node 112, etc.) of system 100 when those specific components are taken offline. Typically, there is a relatively short period of time (e.g., a maintenance window) during which components can be taken offline to apply patches. Furthermore, different patches may have different levels of vulnerability, priority, importance, or risk. Since the maintenance window may be limited, it may therefore be desirable to apply some patches (e.g.,Prioritize patches that have a higher level of hazard, priority, importance, or risk over other patches (e.g., patches that have a comparatively lower level of hazard, priority, importance, or risk) during the maintenance window.

[0030] According to various embodiments, the PMC 114 can identify, for a given maintenance window, a first workload segment to which patches are to be applied while the first workload segment is offline, and a second workload segment to which patches can be applied while the second workload segment is online. Based at least partially on hazard assessments associated with the patches, defined patch management criteria, and one or more patch management algorithms, it can determine a subset of patches that can be applied during the maintenance window while the first workload segment is offline, as described in more detail here. When determining which patches to apply (e.g., during a maintenance window), the PMC 114 can consider various characteristics relating to the containers 104, the VMs 106, the PMs 108, the other resources 110, the nodes 112, applications, etc.take into account features such as those relating to the application of patches to the containers 104, the VMs 106, the PMs 108, the other resources 110, the nodes 112, applications, etc.

[0031] For example, when patching containers (e.g., container 104) belonging to a container platform (e.g., certain types of container platforms), currently running containers are generally not patched. Instead, for a container (e.g., 104), the image used by the container can be patched (e.g., by the Patch Execution Component 118) while the container is still running (e.g., online), and the container can then be restarted with the new, patched container image. The application running in the container may be terminated (e.g., by PMC 114) when the new container (e.g., a new container image) is started, and thus the application, in conjunction with patching the container image, may cause a stop and start time.

[0032] Regarding patching VMs (e.g., VM 106), patching a VM can cause a start and stop time for the application and often requires a warm restart (e.g., by PMC 114). After the application is stopped (e.g., by PMC 114), the patch execution component 118 can additionally patch the VM instance (not the image) of a VM (e.g., VM 106). Thus, the VM instance can cause the patch time for each of the relevant patches for the VM before PMC 114 restarts the application.

[0033] As mentioned, there can typically be a limited window during which offline patching can be performed by the Patch Execution Component 118. For example, there might be a limited maintenance window (e.g., a maintenance downtime window) for the non-clustered Containers 104 or the VMs 106, within which the patching process can cause application stop and start times, as well as warm start and restart times for Containers 104 and VMs 106. Patching can occur within this limited maintenance window for VMs 106. Due to the limited (e.g., relatively short) time available during the maintenance window, Patch Execution Component 118 can typically only apply a subset of the patches during that window.Regarding patching container 104, the containers do not typically cause this patch time because the container images can be patched outside of this maintenance window (e.g., while container 104 and other resources are online). Therefore, for container 104, the patch execution component 118 can typically apply patches to container 104 (e.g., in an online or offline state) (e.g., it can apply all patches).

[0034] Regarding online patching, for example, for certain types of container platforms (e.g., container platforms that support rolling updates), the Patch Execution Component 118 (managed, for example, by PMC 114) can perform a rolling update (e.g., rolling patching), using replication controllers that increment or decrement the replica counter in the new and old controllers until the desired (e.g., correct) number of replicas is reached. For example, a pod can contain one or more containers. A replication controller can ensure that at any given time, a desired (e.g., specified) number of pod replicas (also referred to as a replica counter or copies of the pods) are running (e.g., running on one or more nodes concurrently).The replication controller can manage (e.g., monitor) multiple pods across multiple nodes. For example, if the replication controller detects that there are too many pods, it can terminate the excess pods; conversely, if it detects that there are not enough pods, it can start or create more. To update a service without causing downtime, Patch Execution Component 118 can perform a rolling update for the pods, updating one pod at a time instead of updating the entire service (e.g., all pods of the service) simultaneously. The workload portion associated with the service (and thus the service itself) can continue to function, even though at various times during the update some of the nodes (e.g.,The nodes belonging to the replica counter that execute this workload portion can be taken offline for patching. If the PMC 114 determines that the replica counter is greater than one with respect to a pod, the PMC 114 can, in some implementations, determine that the pod can be patched live (e.g., online). This allows deployment updates to be performed without downtime, as the patch execution component 118 incrementally updates pod instances with new instances that have a requested batch size. High-availability applications (e.g., certain application servers) in the VMs 106 or the containers 104 can be assigned to the PMC 114, such as...Patch Execution Component 118 enables an automated application deployment update process that can stop or pause any application server hosting a cluster member requiring an update without causing application downtime. A High Availability Disaster Recovery (HADR) environment can, when updating software or hardware, enable PMC 114, such as Patch Execution Component 118, to update database-related software (e.g., database product software) or to modify or adjust database configuration parameters. The database service remains available throughout the rolling update process, with only a brief service interruption when processing switches from one database to another.

[0035] In conjunction with patch management, the PMC 114 can also consider other characteristics or factors of the data processing system 102 (e.g., a hybrid cloud data processing system) to determine which patches should be applied during a specific time period (e.g., during a maintenance window) according to the defined patch management criteria. For example, in a hybrid cloud, a plug-and-play approach can be implemented to use cloud platforms and services from different providers or manufacturers. These clouds can be private or public, or located on external or internal premises, and can include containers 104, VMs 106, PMs 108, etc., as described in more detail below.

[0036] In some implementations, the data processing system can provide 102 multi-level applications that may have various dependencies (e.g., dependencies between levels). Multi-level applications allow the presentation, application processing, business processing, and data management functions to be physically separated. The levels can typically be stacked on top of each other, as one level can depend on another. Each level can exist independently of the levels above it and rely on the levels below it to function. Data transfer between levels (e.g., tiered layers) can be part of the architecture. End-to-end traceability of data flows through systems with n levels can be a challenging task, which can become even more critical as the complexity of the systems increases. Each individual level can be implemented as a cluster.

[0037] Regarding multi-tiered applications, dependencies, and offline / online patching, dependencies between offline and online levels can be significant (e.g., important) for patching. If there is a first level that requires offline patching during a maintenance window, and this first level in turn depends on another level that can be patched online, it may be desirable (e.g., useful) to perform the patches for the first level offline to comply with the maintenance window. If there is a first level that requires online patching, and this first level in turn depends on another level that requires offline patching, the first level, which is subject to online patching, can be considered essentially offline (e.g., by PMC 114) for the duration of the other level, which is subject to offline patching.This can make it possible to identify branches of a dependency tree that can be patched online, and can allow more services to be patched during the offline patching maintenance window.

[0038] In certain embodiments, the PMC 114 can preferably perform simultaneous or parallel patching of various resources (e.g., Container 104, VMs 106, etc.) according to the defined patch management criteria. Regarding the simultaneous patching of multiple Container 104 and VMs 106 that can use the same PMs 108, it may be desirable to avoid overburdening the machines (e.g., VMs 106) in the cloud if such machines are also used by other applications. Accordingly, the PMC 114 can control patching to preferably limit the number of simultaneous patches applied to the machines (e.g., VMs 106).Assuming that a cloud of the data processing system 102 is shared in such a way that no service can use resources of another application, the PMC 114, which provides the patch execution component 118, may start patching as many services as desired according to the defined patch management criteria.

[0039] Thus, with respect to the disclosed subject matter, the problem of applying patches to a workload can be reduced to finding a subset of patches, some of which can be applied online while others must be applied offline (e.g., by terminating one or more applications), provided that the total time required to apply the patches does not exceed the permissible maintenance window. With respect to applying a patch, the time required to apply the patch, as disclosed, can include, in addition to the actual execution time for applying the patch, the application stop and start time and the warm start and restart time for the VM or container.One goal of PMC 114 may be prioritization, and PMC 114 may prioritize by giving precedence to threats with higher risk and more urgent application patches over lower priority or less urgent application patches.

[0040] The PMC 114 can manage patching of a multi-tiered workload with multiple resources deployed across a group of nodes in a hybrid cloud environment. Workloads can have resources deployed across a mix of nodes (e.g., containers 104, VMs 106, PMs 108, etc.). The PMC 114 can also allow some resources to be patched online (e.g., if it determines that online patching is possible) while other desired resources are patched offline. It ensures that the services and applications requiring patching can be patched while the services and applications, along with related components of the 102 compute system, are offline within a maintenance window.For example, the PMC 114 can process (e.g., manage) the workload, which has the first part of the workload for which certain patches are to be applied during the maintenance window while offline, and the second part of the workload for which other patches can be applied while online, at the same time or at substantially the same time, while prioritizing patches with a higher risk of hazard (e.g., patches with a high hazard or importance rating or a high level of hazard or importance) within the relevant maintenance window.

[0041] In some embodiments, the PMC 114 can monitor the network (e.g., the network of the data processing system 102) for requests (e.g., requests between resources) to enable the identification of workload dependencies between the containers 104, the VMs 106, the PMs 108, the other resources 110, or the nodes 112, etc. A workload dependency can exist between a first type of element (e.g., the container 104) and one or more other types of elements (e.g., the PM 108), or between elements of the same type (e.g., a first VM 106 and a second VM 106). A request between resources can indicate (e.g., to the PMC 114) whether a relationship exists between the resources or whether one resource is dependent on another, and it can specify the type of request or the levels or relative levels of the resources (e.g.,whether one resource is in one level (or layer) and the other resource is in another level (or layer) below the first level).

[0042] The PMC 114 can determine the workload dependencies between the containers 104, the VMs 106, the PMs 108, the other resources 110, or the nodes 112, etc., at least partially by monitoring the network for requirements or by other means of determining such workload dependencies, as described here. In some embodiments, the PMC 114 can determine or identify the network topology, such as dependencies between resources, at least partially by analyzing the requirements.At least partially based on analyzing requirements or through other means of identifying such workload dependencies, PMC 114 can also identify or generate a dependency tree between resources / nodes. The dependency tree for Data Processing System 102, or a portion thereof, can have a form that allows PMC 114 to patch multiple services simultaneously. PMC 114 can use the dependency tree to include and apply more patches within the specified maintenance window.

[0043] The PMC 114 can determine the workload, at least partially, based on workload dependencies between resources. The workload can consist of a first part, which may be workload elements (e.g., containers 104, VMs 106, PMs 108, resources 110, or nodes 112, etc.) that need to be patched with a first subset of patches within a maintenance window while offline (e.g., at least partially due to workload dependencies of such workload elements), and a second part, which can be patched with a second subset of patches while online. The Patch Identification Component 116 can identify or determine patches to be applied to the workload, the relative importance levels (e.g., risk ratings) of the patches, or related information.

[0044] To enable the determination of which patches should be applied for a specific maintenance window, the PMC 114 can determine hazard assessments for at least a first subset of patches, which should preferably be applied during the maintenance window for the first part of the workload in the offline state. In some embodiments, the PMC 114 can also determine hazard assessments for a second subset of patches, which can be applied for the second part of the workload in the online state.

[0045] Given the limited time available during the maintenance window, it may often not be possible to apply all patches in the first subset of patches for the first part of the workload within that window. PMC 114 can determine the hazard ratings of the patches in the first subset or the second subset of patches, at least in part, based on the importance, priority, hazard, or risk level of each patch in that subset or subset. Typically, there may be some patches in the first subset that require more urgent application than others. PMC 114 can assess the risk in question (e.g., the risk to the data processing system 102 or a part thereof, such as the container 104, the VM 106, the PM 108, the other resource 110, the node 112, an application, or data, etc.).) maximize by prioritizing the patches to perform the more important patches of the first subset of patches that can be performed during the maintenance window, and can select the more important patches to be performed during the maintenance window (so that they are included, for example, in a third subset of patches to be performed).

[0046] Threat ratings can indicate differences in the importance of patches. For example, PMC 114 may use a threat rating scale (e.g., a point scale) that indicates how serious each problem is in relation to each patch, enabling PMC 114 to assess or determine the severity of the problem for each patch and identify which patches are the most critical. The threat rating scale may incorporate the potential risk based on a technical analysis of the specific vulnerability and its nature (or a current threat level, although such an analysis may also omit the current threat level).The baseline scores of a Common Vulnerability Scoring System (CVSS) can provide additional guidance on a vulnerability and a detailed severity assessment by evaluating the constant aspects of a vulnerability: e.g., access vector, access complexity, authorization checks, confidentiality, integrity, and availability. In some implementations, PMC 114 may use a vulnerability rating scale from 1 to 3, where 1 represents the most critical patching and 3 the least critical patching.For example, a value or rating of 1 may indicate that the hazard associated with a patch is of a high degree; a value or rating of 2 may indicate that the hazard associated with a patch is of a medium degree and that such a patch has a relatively medium priority; and a value or rating of 3 may indicate that the hazard associated with a patch is of a low degree and that such a patch has a relatively lower priority. It should be understood and taken into account that in various other embodiments, PMC 114 may use other hazard, importance, or risk assessment scales, such as a scale from 1 to 5 (or 10 or 100), where 5 (or 10 or 100) represents the most important patch and 1 the least important patch, or vice versa.

[0047] In certain embodiments, the PMC 114 can, using a desired patch management algorithm, determine or assign group hazard ratings for groups of patches, at least partially based on the individual hazard ratings of the individual patches (for each group of patches), as described in more detail here. For example, according to a patch management algorithm that can be applied, the PMC 114 can determine (e.g., calculate) group hazard ratings for groups of patches (e.g., different groupings of patches) belonging to the first workload part or the second workload part, at least partially based on the individual hazard ratings of the individual patches (for each group of patches), by applying a formula based on the sum of geometric series to the individual hazard ratings, as described in more detail here.PMC 114 can use such a formula to ensure that a large number of patches with low hazard ratings do not ultimately have a higher group hazard rating than a relatively small number of patches with high hazard ratings, thereby giving higher priority to patches with higher hazard ratings.

[0048] After evaluating the risk scores of the patches, PMC 114 can, at least partially, determine a third subset of patches based on the risk scores of the patches in the first subset or the second subset and the maintenance window. This third subset can then be applied to a portion (e.g., a subset of Container 104, VMs 106, PMs 108, resources 110, or nodes 112, etc.) of the first workload portion from the first subset of patches that belongs to the first workload portion. For example, PMC 114 can, according to the desired patch management algorithm (e.g.,(Using the formula or another desired patch management algorithm) determine which group of patches belonging to the first workload part or the second workload part has the highest group hazard rating compared to the group hazard ratings of the other groups of patches belonging to the first workload part or the second workload part. PMC 114 can select the group of patches with the highest group hazard rating for patching. This group of patches can be the third subset of patches that can be applied to the portion of the first workload part offline during the maintenance window, or the second subset of patches that can be applied to the second workload part online.

[0049] Patch execution component 118 can execute (e.g., apply) the third subset of patches for the portion of the first workload during the maintenance window. In some embodiments, patch execution component 118 can execute the patches of the third subset of patches in topological order according to the network topology, as determined by PMC 114. In certain embodiments, patch execution component 118 can execute patches of the third subset of patches simultaneously (e.g., in parallel) within the available maintenance window for multiple workload elements (e.g., the containers 104, the VMs 106, the PMs 108, the other resources 110, or the nodes 112, applications, or data, etc.), such as elements with dependencies, of the portion of the first workload.

[0050] The PMC 114 and the Patch Execution Component 118 can perform the patching process to enable the application of the third subset of patches. This patching process may involve stopping and restarting resources belonging to the first part of the workload and warm-starting nodes belonging to the third subset of patches, as described in more detail here. Regarding the containers 104 to be patched, the Patch Execution Component 118 can apply patches to the container images of the containers 104, since immutable container instances are not typically patched. With regard to VMs 106 and PMs 108, the patch execution component 118 can typically apply patches to the VM or PM instances of VMs 106 or PMs 108, and not necessarily to the VM or PM images of VMs 106 or PMs 108.

[0051] The patch execution component 118 can also execute the second subset of patches for the second workload part, whereby the second subset of patches can be executed while the second workload part (or another part of the data processing system 102) is online, or outside the maintenance window or during the maintenance window. In certain embodiments, the patch execution component 118 can execute all or at least some of the patches of the second subset of patches for the second workload part simultaneously (e.g., in parallel), with some of the patches of the third subset of patches being executed during the maintenance window for the part of the first workload part.

[0052] In some implementations, the PMC 114, such as the Patch Execution Component 118, can apply patches (e.g., second and third sets of patches) as follows. The Patch Execution Component 118 can initiate live patching (e.g., in the background) to apply patches to the second part of the workload (e.g., the containers 104 (e.g., pods), the VMs 106, the PMs 108, the other resources 110, nodes, etc.), for example, to associated services that can be patched live (e.g., online). With regard to patching associated with the part of the first workload part that is performed offline, the patch execution component 118 can initiate patching for a subset of pods and a subset of patches for each VM 106 of the part of the first workload part, for the pods (e.g., the containers 104) and the VMs 106 that have no dependencies, and can patch (e.g., update) such pods and VMs in parallel.Whenever a pod or VM is patched, PMC 114 can update the list of pods and VMs that can be patched and can initiate patching for the pods and VMs on that list. PMC 114, such as the Patch Execution Component 118, can continue this exposed process until all desired (e.g., selected) services have been patched.

[0053] After applying the patches, the PMC 114 can validate the patching of the portion of the first or second workload within the maintenance window to ensure that the patches were applied correctly and that the patches, the affected elements of the portion of the first or second workload, and the data processing system as a whole function correctly after such patches have been applied. For example, after one or more patches have been applied, the PMC 114 can analyze or examine one or more applications, one or more nodes, or one or more resources, etc., that are associated with or affected by the one or more patches to determine whether the one or more applications, the one or more nodes, or the one or more resources are functioning correctly.The multiple resources meet defined patch management criteria that indicate that the one or more applications, the one or more nodes, or the one or more resources, etc., are in a defined sound or functioning operational state (e.g., that the one or more applications, the one or more nodes, or the one or more resources, etc., are functioning properly, reasonably, acceptably, or optimally, or at least functioning well enough to meet or exceed defined minimum operating standards). If PMC 114 determines that the one or more applications, the one or more nodes, or the one or more resources, etc., meet such defined patch management criteria after the one or more patches have been applied, PMC 114 may determine that the one or more patches are validated.If PMC 114 determines that a specific patch is being validated, PMC 114 may retain that patch. However, in response to a determination that a specific patch and one or more associated workload elements cannot be validated, PMC 114 may, within the maintenance window, roll back the specific patch associated with the one or more workload elements to their previous state before the specific patch was applied.

[0054] With regard to the other patches (e.g., unapplied patches) of the first subset of patches that were not selected by PMC 114 to be applied during the maintenance window, PMC 114 may, according to the defined patch management criteria, defer the application of such other patches for the remaining portion of the first workload to a future maintenance window. PMC 114 may determine or calculate a future maintenance window during which Patch Execution Component 118 can apply the other patches of the first subset of patches (or, if applicable, other patches that may subsequently become available or be determined).

[0055] With reference to Fig. 2 (as well as Fig. 1) represents Fig. 2. According to various aspects and embodiments of the disclosed subject matter, a diagram of a non-limiting example data processing system 200 is presented, which has workloads that can span multiple dimensions. The data processing system 200 (e.g., a hybrid cloud-based data processing platform) can have a conventional IT platform 202, a private cloud computing platform 204, and a public cloud computing platform 206, and can thus span multiple dimensions with respect to data processing platforms. The conventional IT platform 202 can, for example, have applications (App) such as applications 208 and 210, application servers (App Ser) such as application servers 212 and 214, and databases (DB) such as databases 216 and 218. The private cloud computing platform 204 can, for example, have applications such as applications 220 and 222, application servers such as...Application servers 224 and 226 and databases such as databases 228 and 230 may be present. The public IT platform 206 may, for example, host applications such as applications 232 and 234, application servers such as application servers 236 and 238, and databases such as databases 240 and 242.

[0056] In some implementations, the data processing clouds (e.g., 204, 206) can belong to different providers (e.g., a first provider, a second provider, a third provider, etc.) and can thus span multiple dimensions (e.g., types of services provided by providers) with respect to providers and types of providers. The data processing system 200 can also use multiple hypervisor technologies, such as bare-metal hypervisor technology, kernel-based VM (KVM) (e.g., a kernel-based hypervisor technology), microkernel-based hypervisor technology, containers, or unikernel, etc., which can provide different data processing services and thus span multiple dimensions with respect to types of hypervisor technologies.

[0057] Workloads can also span multiple dimensions, for example, in terms of data processing platforms (e.g., the traditional IT platform 202, a private cloud computing platform 204, or a public cloud computing platform 206), data processing or cloud service providers, hypervisor technologies, and types of resources (e.g., VM, container, PM, node, or other resources). Each workload can have its own dependencies between resources (e.g., dependencies between nodes of multiple workload levels) (or no dependencies at all). For example, the sample data processing system can have a first workload 244, a second workload 246, and a third workload 248. The first workload 244 can have one or more VMs (e.g., just VM), which can span the traditional IT platform 202 and the private cloud computing platform 204.the multiple VMs of the first workload 244 can be implemented by or be part of the database 216 of the traditional IT platform 202, as well as the application 220 and the application server 224 of the private cloud computing platform 204, wherein the database 216, the application 220 and the application server 224 can be implemented as VMs or in VM form.

[0058] The second workload 246 can consist of a VM, a PM, and a container, and can span the private cloud computing platform 204 and the public cloud computing platform 206. For example, the VM of the second workload 246 can be implemented by or be associated with the application server 236 (which is implemented, for example, as a VM) of the public cloud computing platform 206, the database 228 (which is implemented, for example, as a PM) of the private cloud computing platform 204, and the application 234 (which is implemented, for example, as a container (Con)) of the public cloud computing platform 206.

[0059] The third workload 248 can have one or more containers (e.g., only containers) and can span the private cloud computing platform 204 and the public cloud computing platform 206. For example, the one or more containers of the third workload 248 can be implemented by or be associated with the database 230 of the private cloud computing platform 204 and the application 234 and application server 238 of the public cloud computing platform 206, where the database 230, the application 234, and the application server 238 can be implemented as containers or in container form. It should be understood and considered that these workloads (e.g.,244, 246, 248) are only example workloads and that the disclosed subject matter, according to various embodiments, may also have, refer to or contain various other types of workloads in addition to or as an alternative to these example workloads and other workloads described herein.

[0060] The first workload 244, the second workload 246, and the third workload 248 can be examples of dependencies between resources with respect to offline patching (e.g., by the PMC 114 and the patch execution component 118), where the resources can be distributed across one or more nodes, as in Fig. 2 is illustrated (and as otherwise illustrated in the drawings or described here). According to the defined patch management criteria (and, for example, the associated patch management algorithm), the PMC 114 can determine or identify the dependencies between workload resources (e.g., dependencies between nodes of multiple workload levels) belonging to the workloads (e.g., 244, 246, 248, ...) to enable the determination of which patches should be applied to specific workloads during a particular maintenance window (e.g., which patches should be prioritized and applied over other patches with respect to that specific maintenance window). This includes determining which resources can be stopped and started without interrupting or disrupting a specific workload, as described in more detail here.

[0061] With reference to Fig. 3 (as well as Fig. 1) shows Fig. 3. According to various aspects and embodiments of the disclosed subject matter, a block diagram of an example patch sequence 300 for applying patches during a maintenance window while the workload associated with the patches is offline is provided. The example patch sequence 300 may refer to an example workload. It should be understood and considered that the example patch sequence 300 is only an example patch sequence that may refer to the example workload, and that according to various embodiments, other patch sequences (e.g., by the PMC) may be performed with respect to other workloads according to the defined patch management criteria and the associated patch management algorithm, as described herein.

[0062] When applying patches to the sample workload associated with patch sequence 300 during the maintenance window, sample patch sequence 300 may involve stopping a web server (e.g., terminating or suspending its operation) that belongs to the workload being patched during the maintenance window, as indicated by reference 302 of patch sequence 300. For example, PMC 114 may stop the web server during the maintenance window. Reference 304 of patch sequence 300 indicates that PMC 114 may stop an application server associated with the workload (e.g., terminate or suspend its operation). Reference 306 indicates that PMC 114 may validate a database backup of a database associated with the workload (e.g., it may validate or verify that the database was backed up to preserve the data stored in the database).For example, the data stored in the database can be stored in one or more data stores to enable data backup. Reference number 308 allows PMC 114 to stop the database.

[0063] At reference number 310 of patch sequence 300, patch execution component 118 can apply the patches to the workload, whereby the patches can be applied to the operating system, middleware, or application belonging to the workload. At reference number 312, PMC 114 can restart the nodes belonging to the workload (e.g., the nodes to which the patches are applied) (e.g., warm restart or resume operation). At reference number 314, PMC 114 can start the database. At reference number 316, PMC 114 can start the application server (e.g., resume operation). At reference number 318, PMC 114 can start the web server.

[0064] At reference number 320 of patch sequence 300, PMC 114 can validate the workload. During the maintenance window and while the resources associated with the workload are offline, PMC 114 can, for example, validate the workload and associated patches applied to the workload to validate or verify that the resources and patches associated with the workload are functioning appropriately after the patches are applied (e.g., that a web server is functioning appropriately, that an application server is functioning appropriately, that a database is functioning appropriately, such as restoring data to the database, and that nodes are functioning appropriately). If, during the validation process, PMC 114 determines that one or more specific patches, one or more associated workload elements, or one or more associated resources (e.g.,If a node (web server, application server, database, etc.) does not function properly or acceptably after the patch has been applied, PMC 114 can roll back (i.e., undo) the one or more patches during the maintenance window to restore the one or more workload elements or resources to a previous state before the patch was applied, as described in more detail here. A patch that cannot be validated can be reapplied at a future time, for example, after the patch has been modified to function in a desired (e.g., acceptable, suitable, improved, or optimal) manner according to the defined patch management criteria and the associated patch management algorithm.

[0065] With reference to Fig. 4 (as well as Fig. 1) illustrates Fig. 4. According to various aspects and embodiments of the disclosed subject matter, a diagram of an example application topology 400 in conjunction with determining dependencies between resources of a workload and patch management. A cloud computing system 402 can have various resources and nodes that can be arranged in relation to each other or be related to each other as desired to form the cloud computing system 402, which can provide various desired services and applications.

[0066] In the Cloud Computing System 402, the example application topology 400 can have a merchant container 404, which can be associated with a merchant application, a container replica 406 for a social networking service (soc nw svc), which can be associated with a social networking application, a container replica 408 for a customer loyalty service (loyalty svc), which can be associated with a customer loyalty service application, and a container 410 for a data transfer service (comm svc), which can be associated with a data transfer service application.

[0067] The merchant container 404 can, for example, be or have a user interface (UI) and can reside in a first level (e.g., a top-level or highest level) of the application topology 400. The merchant container 404 can belong to a portfolio container 412 (e.g., communicatively coupled or functionally connected to it), which can reside in a second level of the application topology 400, where the portfolio container 412 can be or have a server. The portfolio container 412 can belong to a database VM 414, which can reside in a third level of the application topology 400, below the portfolio container 412 and the merchant container 404, where the database VM 414 can be or have a database, a database application, or a database service.The portfolio container 412 can also belong to a stock container 416, which can be located in the third level of the application topology 400 below the portfolio container 412 and the trader container 404 in the application topology 400, where the stock container 416 can be or have a service (e.g., a service related to stocks, such as stock trading).

[0068] The PMC 114 can analyze the network, resources, or nodes or requests between resources and can, at least partially, identify or determine dependencies between containers 104, VMs 106, PMs 108, other resources 110, or nodes 112, etc., based on this analysis. For example, the PMC 114 can monitor the network for requests, analyze such requests, and, at least partially, determine or derive dependencies between containers 104, VMs 106, PMs 108, other resources 110, or nodes 112, etc., based on the results of this analysis. With respect to the example application topology 400, the PMC 114 can, for example, determine the dependencies between the trader container 404, the portfolio container 412, the database VM 414, and the stock container 416, considering their relative positions, for example.Determine that the trader container 404 is in the first stage, that the portfolio container 412 is in the second stage, and that the database VM 414 and the stock container 416 are in the third stage.

[0069] With reference to Fig. 5 (as well as Fig. 1) represents Fig. 5. According to various aspects and embodiments of the disclosed subject matter, a diagram of an example patch selection 500 with respect to an example workload belonging to a data processing system, in conjunction with dependencies between resources of the workload and a patch management system, is presented. With respect to the example patch selection 500, the PMC 114 can determine the patches to be selected for execution, e.g., a subset of patches that may belong to a first workload part of the workload, which is to be applied (e.g., by the patch execution component 118) within a maintenance window while resources, nodes, etc., belonging to the first workload part of the workload are offline, wherein, according to the defined patch management criteria and the associated patch management algorithm, dependencies between resources of the workload (e.g.,Dependencies between nodes of multiple workload levels, the relative importance, priority, or vulnerability of the workload elements and associated patches to be performed, or other factors are taken into account, as described in more detail here. PMC 114 can also identify a further subset of patches belonging to a second workload portion that can be applied (e.g., by Patch Execution Component 118) while the resources, nodes, etc., belonging to the second workload portion are online (e.g., live), and the further subset of patches, or at least a portion of the further subset of patches belonging to the second workload portion, can be applied within the maintenance window (e.g., concurrently or in parallel with the application of patches belonging to the first workload portion).

[0070] The PMC 114 can prioritize patches with a higher risk (e.g., more urgent application patches) within a specific maintenance window according to the defined patch management criteria and the associated patch management algorithm, as described in more detail here. For example, the PMC 114 can process (e.g., manage) patching of a workload that includes at least a portion of the first workload segment, for which specific patches are to be applied offline during the maintenance window, and a second workload segment, for which other patches can be applied online (e.g., at the same time or substantially at the same time), in order to prioritize patches with a higher risk (e.g., patches with a higher risk or importance rating or a higher risk or importance level) within the specified maintenance window.

[0071] Regarding the example patch selection 500, there may be a workload belonging to a variety of applications for which it may be desirable to perform patches within a maintenance window (e.g., a relevant downtime window) when the first part of the workload (e.g., the applications or associated resources, nodes, etc.) is offline and the second part is online. For example, the applications might include a 502 application for a data transmission service (comm svc), a 504 application for a customer loyalty service (loyalty svc), a 506 application for a merchant service, a 508 application for a portfolio service, a 510 application for a database service, a 512 application for a social networking service (soc nw svc), and a 514 application for a stock quote service.

[0072] With regard to the applications (e.g., 502, 504, 506, 508, 510, 512, 514), PMC 114 can, at least partially, determine or identify various patches for which it may be desirable to perform (e.g., apply) based on the results of analyzing the dependencies between resources belonging to the applications. It can determine which of these patches should be applied to the resources (e.g., containers 104, VMs 106, PMs 108, other resources 110), nodes (e.g., nodes 112), etc., belonging to the first workload segment within the maintenance window while the first workload segment is offline, and it can determine which of these patches can be applied to the resources, nodes, etc., while the second workload segment is online.Regarding the portion of patches belonging to the first workload segment that need to be applied during the maintenance window while the resources, nodes, etc., belonging to the first workload segment are offline, PMC 114 can determine the relative (e.g., differing) importance, priority, or severity (e.g., high, medium, or low severity) of the patches for which it might be desirable to apply such patches within the maintenance window. However, there may often be more patches to be applied than can be applied within the maintenance window. For example, PMC 114 may determine or identify patches 516 and 518 that need to be applied with respect to Data Transmission Service Application 502, and may further determine that patches 516 and 518 are low-severity patches (if patches 516 and 518 are, for example,each has hazard ratings indicating that it has a relatively low level of importance, priority, or hazard). The PMC 114 can also determine or identify patches 520, 522, and 524 to be performed in relation to the Customer Loyalty Service application 504, and can further determine that patch 520 is a high-grade patch (e.g., that patch 520 has a hazard rating indicating that it has a high level of importance, priority, or hazard), that patch 522 is a medium-grade patch (e.g., that patch 522 has a hazard rating indicating that it has a medium level of importance, priority, or hazard), and that patch 524 is a low-grade patch (e.g., that patch 524 has a hazard rating indicating that it has a relatively low level of importance, priority, or hazard).

[0073] PMC 114 can further determine or identify patches 526, 528, and 530 to be performed in relation to the trader application 506, and can further determine that patches 526 and 528 are high-level patches and patch 530 is a low-level patch. Furthermore, PMC 114 can determine or identify patches 532 and 534 to be performed in relation to the portfolio application 508, and can further determine that patches 532 and 534 are medium-level patches. The PMC 114 can also detect or identify patches 536, 538 and 540 that need to be applied to database application 510, and can further determine that patch 536 is a medium-level patch and patches 538 and 540 are low-level patches.

[0074] PMC 114 can further determine or identify Patches 542 and 544 to be performed in relation to the Social Networking Service Application 512, and can further determine that Patch 542 is a medium-degree patch and Patch 544 is a low-degree patch. PMC 114 can further determine or identify Patches 546, 548, and 550 to be performed in relation to the Stock Price Application 514, and can further determine that Patch 546 is a medium-degree patch and Patches 548 and 550 are low-degree patches.

[0075] The PMC 114 can analyze the patches (e.g., patches 516 to 550) according to the defined patch management criteria and the associated patch management algorithm, determine and analyze dependencies between the resources associated with the workload, determine which patches (e.g., which subset of patches) should be applied while the first part of the workload is offline, determine which patches (e.g., which other subset of patches) can be applied while the second part of the workload is online, determine the hazard ratings of the patches or the group hazard ratings of different groups (e.g., groupings) of patches, and determine a desired (e.g., optimal, suitable, or acceptable) subset of patches that can be applied within the maintenance window and has an overall hazard rating that is higher (e.g., the highest) than the other overall hazard ratings of other subsets of patches.By ensuring that such a desired subset of patches has the highest overall risk rating (e.g., maximizes the risk value), it can minimize or at least significantly reduce the risks to the data processing system.

[0076] In the case of example patch selection 500, PMC 114 can determine, at least partially, based on the analysis results, for example, that patches 516 and 518, which may be low-level patches belonging to the data transmission service application 502, and patches 542 and 544, which may be a medium-level and a low-level patch, respectively, belonging to the social networking service application 512, belong to the second workload portion and can be applied while that workload portion is online (e.g., within or outside the maintenance window). Furthermore, PMC 114 can determine, at least partially, based on the analysis results, that the desired subset of patches (e.g., the one belonging to the second workload portion) can be applied while that workload portion is online.the highest overall risk score; which can be performed within the maintenance window) may contain patches 520, 522, 524, 526, 528, 530, 532, 534, and 536, but not patches 538, 540, 546, 548, and 550. Patch execution component 118 can apply the subset of patches (e.g., patches 520 through 536) belonging to the first workload segment within the maintenance window while the first workload segment is offline, and can apply the other subset of patches (e.g., patches 516, 518, 542, and 544) belonging to the second workload segment within the maintenance window while the second workload segment is online, as described in more detail here.

[0077] With further reference to Fig. There are several patch management algorithms that PMC 114 can use or apply to determine which patches need to be applied within a maintenance window. According to one patch management algorithm, PMC 114 can treat each patch for a VM as a single entry, prioritizing, for example, patches with a high risk rating if not all patches can be applied during the maintenance window. It can also treat all patches for each container (e.g., a pod) as a single entry, combining the time frame for applying such patches with the start and stop times for all resources in a pod, since container images are patched offline.

[0078] As an example of the time required to stop and start a resource to patch a specific application server in a VM (e.g., VM 106), it might take approximately two minutes to stop the application server, about one minute to apply the patch, and about four minutes to start the application server after the patch has been applied. If there are multiple patches for an application server resource, PMC 114 can combine these patches into a single entry, so the application server does not need to be stopped and started multiple times to apply these patches. If the application server patches are considered separately, the time frame can be fully utilized (e.g., exceeding the time available in the maintenance window) by including the restarts multiple times. Note that the restart time for the VM can be included as a separate entry, with a time of zero allocated for applying the patch.

[0079] According to such a patch management algorithm, each patch can have the following attributes: the time to stop container 104, VM ​​106, PM 108, or other resource 110; the time to restart container 104, VM ​​106, PM 108, or other resource 110; the time to apply the patch (which can be zero for container 104); the importance score (e.g., the severity or threat score) for the patch; a replica counter associated with the patch; and the patch type. In some implementations, PMC 114 can calculate the importance or threat score using a sum of geometric series for containers when determining (e.g., calculating) it.

[0080] The following explanations can be an illustrative, non-limiting example of determining (e.g., calculating) an importance rating for a pod using a formula based on a sum of geometric series. To enable the determination (e.g., calculation) of the importance or hazard ratings of updates for a pod with respect to each type of update (e.g., high importance, medium importance, low importance), PMC 114 can determine an importance or hazard rating (e.g., a single importance or hazard rating) for that type of update using the following example equation: ∑i=2nx+1(1 / x)i where x can be the type of update with an importance value (2 = high, 3 = medium, 4 = low) and nx can be the number of updates of that type to be applied to the pod. The PMC 114 can determine the summed importance or hazard score (e.g., the overall or group score) for all updates to the pod by adding the individual importance or hazard scores determined for the different types of updates to the pod. For example, a pod might have two updates (e.g., patches) of high importance with x = 2 and four updates of medium importance with x = 3. The PMC 114 can express the importance or hazard score for the update of high importance as [(1 / 2) 2 + (1 / 2) 3 ] determine; can the importance or risk rating of updates with a medium importance as [(1 / 3) 2 + (1 / 3)3 + (1 / 3) 4 + (1 / 3) 5 ] determine; and can determine the overall importance or hazard rating for the updates for the pod as [(1 / 2) 2 + (1 / 2) 3 ] + [(1 / 3) 2 + (1 / 3) 3 + (1 / 3) 4 + (1 / 3) 5When determining a score for a container or pod and defining how such a score should be determined, it may be desirable to avoid a situation where the sum of too many low-severity updates (e.g., updates or patches with a lower threat level) significantly exceeds the sum of high-severity updates. This patch management algorithm (as well as other patch management algorithms disclosed here) can ensure that there are not significantly more low-severity updates (e.g., the sum of a relatively large number of low-severity updates) than high-severity updates (e.g., the sum of high-severity updates).

[0081] In some embodiments, the PMC 114 can apply an additional patch management algorithm, according to the defined patch management criteria, to enable the determination of a desired (e.g., suitable, optimal, or at least near-optimal) subset of patches to be applied with respect to a workload within a maintenance window. Such a patch management algorithm can provide a dynamic programming solution for determining a desired subset of patches to apply and can be expressed, for example, as follows.

[0082] The PMC 114 can generate an empty, two-dimensional array K[(N + 1)[(W + 1)], where N can be the total number of updates (e.g., patches) and W can be the size of the window (e.g., the maintenance window) in which a warm restart of the services can occur. The PMC 114 can initialize this array, which, for each position K[i][j], can contain the following entries: for i updates and a window size j, an allocation that can contain a subset of updates [1:i] and the estimated completion times of the updates, from which a cumulative maximum score for window size j can be derived; a cumulative maximum score achievable in window size j; and a thread allocation that can contain a distribution of updates across multiple threads to achieve this cumulative maximum score, where the thread allocation can include a special thread, which can also be referred to as "live" (e.g., the maintenance window).B. for updates that can be performed online). The solution can be the entry at position K[(N + 1)[( W + 1)].

[0083] Regarding the population of K and the determination of K[(N + 1)[(W + 1)], PMC 114 can assign the original maximum score to the score of K[i - 1][j] for each K[i][j] of the array; can initialize the best subset of pods so that it equals the subset at K[i - 1][j] and the thread allocation equals K[i - 1][j]; can check if an update i can be added to the subset at K[i - 1][j] where l : 0 - j without exceeding the window size j; if the update i can be added to the subset of updates, can add the scores of all new pods / containers added to K[i - 1][j] and compare this to the previous maximum score; The system can update the three entries if the score obtained from adding the scores of all new pods / containers K[i - 1][ / ] is greater than the previous maximum score;and can continue performing the above operations until the PMC 114 has tested all l: 0 - j. The PMC 114 can identify the subset of patches or determine which one belongs to the maximum rating (e.g., the maximum or highest hazard rating).

[0084] With further reference to a check to determine whether an update i can be added to the subset of updates, PMC 114 can obtain or determine a list of all dependencies of the current pod / container (e.g., dependencies between nodes of multiple workload levels). PMC 114 can check (e.g., analyze, evaluate) to determine whether all dependencies of the current pod / container can be patched live (e.g., online). If all dependencies of the current pod / container can be patched live, PMC 114 can add them to the live thread and update the score (e.g., the hazard score). If the current pod / container cannot be patched live, but some of the dependencies can, PMC 114 can remove the dependencies from the live thread and treat such dependencies as new dependencies that cannot be patched live.If the time of the previous dependency is not available in the thread, PMC 114 can, with respect to each dependency, add the time at which the previous dependency ends to the thread that can complete a dependency no earlier than after the end of the previous dependency (e.g., according to greedy scheduling), check if the completion time does not exceed j; and add the score of the current dependency to the overall score.

[0085] In certain embodiments, the PMC 114 can determine a desired (e.g., the most important) subset of patches by listing all possible subsets of patches according to the defined patch management criteria, filtering out possible subsets from this list, and determining the possible subset of patches with the highest cumulative rating. For a total of m outstanding patches, the number of subsets can be 2 m be.

[0086] In certain embodiments, the PMC 114 can apply a patch management algorithm (e.g., Algorithm 1 - getOptimalSubset, as disclosed herein) according to the defined patch management criteria to enable the determination of a desired (e.g., suitable or optimal) subset of patches to be applied to a workload within a maintenance window. Definitions of variables and functions used in this patch management algorithm (e.g., Algorithm 1) can include: W can be the size of the offline window; [p1, p2, p3, ...[pm] can be the list of pending patches, where the total number of pending patches is m; [(depsDict)] can be the application's dependency tree (neighborhood list); K can be a two-dimensional array that may contain the solution for subproblems; scheduleCrit can schedule the appropriate list of patches by scheduling the longest critical path first; scheduleGreedy can schedule the appropriate list of patches according to the greedy principle in order of their occurrence; and schedPolicy can be the scheduling policy, which can follow either the greedy method or the critical path method.

[0087] The patch management algorithm can be expressed as follows:

[0088] This patch management algorithm (e.g., Algorithm 1 - getOptimalSubset) can model patch selection as a knapsack in such a way that the patching time can be considered the patch's weight, the patch's score can be its value, and the total size of the offline window can be treated as the knapsack's size. This patch management algorithm (as implemented, for example, by PMC 114) can determine the subset of patches that ensures patches of maximum importance are applied within W minutes. This patch management algorithm (as implemented, for example, by PMC 114) can assign an importance score to each patch to determine a possible subset of patches that maximizes the cumulative score. The patch management algorithm can provide a solution for cases where the number of concurrent patches is limited.This patch management algorithm (as implemented, for example, by PMC 114) can schedule patches across the allowed number of threads in such a way that no dependency constraints are violated, for example, by disabling elements that depend on an application service before the service is stopped and patches are applied. To achieve near-optimal patch scheduling, the patch management algorithm (as implemented, for example, by PMC 114) can use one of several methods, such as a greedy method or a critical path method. The greedy approach (scheduleGreedy) can reduce the timing complexity of the patch management algorithm and simply attempts to fit the current patch into the patch schedule of previously selected patches. Regarding critical path scheduling (scheduleCrit), scheduling based on the critical path (as implemented, for example, by PMC 114) can be used to determine the most suitable patches for each thread.(implemented by PMC 114) for each subproblem K[i][j], always first plan the critical path and then remove it from the pending patches. This critical path planning process can be repeated recursively until there are no more patches to plan or until all threads are occupied for time W.

[0089] The patch management algorithm (as implemented, for example, by PMC 114) can generate an empty, two-dimensional array K[(m + 1)[(W + 1)], where m can be the total number of updates (e.g., patches) and W can be the size of the window (e.g., the maintenance window) in which a warm restart of the services can occur. PMC 114 can initialize this array to zero, and for each position K[i][j], this array can contain the following entries: for i updates and a window size j, an allocation that can contain a subset of updates [1:i] and the estimated completion times of the updates, from which a cumulative maximum score for window size j can be derived; a cumulative maximum score achievable in window size j; and a thread allocation that can contain a distribution of updates across multiple threads to achieve this cumulative maximum score.The solution can be the entry at position K[(m + 1)[(W + 1)].

[0090] Regarding the population of K and the determination of K[(N + 1)[(W + 1)], PMC 114 can assign the original maximum score to the score of K[i - 1][pw] for each K[i][j] in the array; it can initialize the best subset of pods so that it equals the subset at K[i - 1][j] and the thread allocation equals K[i - 1][j]; it can check if an update i can be added to the subset at K[i - 1][pw], where pw: 0 - j, without exceeding the window size j. This check to see if an update i can be added can be performed using a greedy algorithm or an algorithm that processes the critical path first.If update i can be added to the subset of updates, PMC 114 can add the scores of all new pods / containers added to K[i - 1][pw] and compare this to the previous maximum score; if the score obtained from adding the scores of all new pods / containers K[i - 1][j] is greater than the previous maximum score, PMC 114 can update the three entries; and PMC 114 can continue to perform the above operations until PMC 114 has tested all pw: 0 - j. PMC 114 can identify the subset of patches or determine which one belongs to the maximum score (e.g., the maximum or highest hazard score).

[0091] If the time of the previous dependency is not available in the thread, PMC 114 can, with respect to each dependency, add the time at which the previous dependency ends to the thread that can complete a dependency no earlier than after the end of the previous dependency (e.g., according to greedy scheduling or critical path scheduling), check if the completion time does not exceed j, and add the score of the current dependency to the total score.

[0092] In certain implementations, PMC 114 can apply an additional patch management algorithm if there is no limit to the number of concurrent patches (threads). In this case, the task scheduling and distribution problem does not need to be addressed. For each service deployed in a container, PMC 114 can simply check whether the service, along with its dependencies, can be restarted within the specified maintenance window, since the total offline time required to patch a container is independent of the patches applied. If the time required to apply patches to a container and restart its dependents is less than the window size W, it can be patched during the maintenance window (e.g., an offline window). For virtual machines (VMs), the offline patch time may depend on the patches applied.Since this cannot be a limit on the number of concurrent patches, the PMC 114 can execute or implement a separate knapsack algorithm for each VM to determine and select an optimal subset of patches that can be applied within the given timeframe. For each of these separate knapsack problems for VMs, the PMC 114 can also consider the time required to restart the dependent elements, as revealed here.

[0093] Fig. Figure 6 illustrates a block diagram of an example PMC 600 according to various aspects and embodiments of the disclosed subject matter. The PMC 600 can include a patch identification component 602 and a patch execution component 604, which may be identical to or similar to corresponding components (e.g., appropriately named components), or which may have the same or similar functionality as corresponding components, as described in more detail here.

[0094] The PMC 600 can contain an operations management component 606 that can control (e.g., manage) operations belonging to the PMC 600. For example, the operations management component 606 can enable the generation of instructions so that components of the PMC 600 can perform operations, and can transmit instructions to components (e.g., the patch identification component 602, the patch execution component 604, etc., a processor component 618, a data storage device 620, etc.) of the PMC 600 to enable, at least partially based on the instructions, the performance of operations by the components of the PMC 600 according to the defined patch management criteria and the defined patch management algorithms (e.g., the patch management algorithms as disclosed, defined, set forth, contained, or specified herein by the procedures, systems, and methods described herein).The Operations Management Component 606 can also enable control of data flow between the components of the PMC 600 and control of data flow between the PMC 600 and one or more other components or units (e.g., a computer, a laptop computer, or another type of data processing or data transmission unit) that belong to (e.g., are connected to) the PMC 600.

[0095] The PMC 600 can also include, for example, a topology discovery component 608, an evaluation component 610, a patch selection component 612, a validation component 614, and a rollback component 616. The topology discovery component 608 can discover or identify the topology of a workload belonging to a data processing system (e.g., a hybrid workload belonging to a cloud-based hybrid data processing system). As part of discovering the workload's topology, the topology discovery component 608 can discover or identify dependencies between nodes or resources belonging to the workload. This enables the discovery of a dependency tree for the workload and facilitates the efficient determination of which patches to apply during the maintenance window, as well as the determination of the order in which patches should be applied.that patches for the first part of the workload are performed offline) and to allow patches to be applied to at least one desired part of the workload during the maintenance window.

[0096] The evaluation component 610 can, according to the defined patch management criteria and the associated patch management algorithm, determine patch ratings associated with a workload (e.g., hazard, importance, or risk ratings for patches belonging to the workload, or an overall, cumulative, or group hazard, importance, or risk rating for subsets of patches belonging to the workload), at least partially based on the results of analyzing the hazard or risk levels of patches (e.g., high, medium, or low hazard). For example, the evaluation component 610 can use a desired patch management algorithm, such as one described here, to determine hazard ratings for patches or group hazard ratings for subsets (e.g.,to allow different groups) of patches that are related to the workload.

[0097] The patch selection component 612 can, according to the defined patch management criteria, select a subset of patches from the set of patches belonging to the workload to be executed during a maintenance window, based at least partially on the patch-related ratings determined for the patches belonging to the workload or on the total or cumulative ratings associated with a patch for subsets of patches belonging to the workload, wherein at least one part of the subset of patches must be applied while a first part of the workload is offline, and wherein another part of the patches can be applied while a second part of the workload is online.For example, according to the relevant patch management algorithm, the patch selection component 612 can select or determine the subset of patches from the set of patches belonging to the workload to be executed, at least partially, during a maintenance window based on a determination that the subset of patches belonging to the workload has the highest group, total, or cumulative patch-related score compared with other subsets of patches belonging to the workload.

[0098] The validation component 614 can analyze the patches applied to the first or second workload part during the maintenance window, or it can analyze the resources, nodes, applications, or data, etc., belonging to the first or second workload part while those resources, nodes, applications, etc., are offline, to determine and validate (e.g., verify) that the patches or the resources, nodes, applications, or data, etc., belonging to the first or second workload part are functioning properly after the patches are applied (e.g., that a web server is functioning properly, that an application server is functioning properly, that a database is functioning properly, such as restoring data to the database, and that nodes are functioning properly).If the validation component 614 determines that a patch is not validated (e.g., that the patch or the associated resource, node, application, etc., does not function properly according to the defined patch management criteria), the validation component 614 can generate and submit an indicator (e.g., an unvalidated indicator) that can indicate that such a patch is not validated.

[0099] In response to a detection that the patch is not validated, the rollback component 616 can roll back (i.e., undo) a patch within the maintenance window to revert one or more workload elements (e.g., one or more resources, one or more nodes, applications, or data, etc.) to a previous state before the patch was applied. For example, during the maintenance window, the rollback component 616 may receive a "non-validation" indicator related to a patch, which may indicate that the patch is not validated. In response to receiving the "non-validation" indicator, the rollback component 616 can roll back the patch within the maintenance window and revert the one or more workload elements (e.g., the one or more resources, the one or more nodes, applications, or data, etc.) to a previous state.to reset several such workload elements before the patch was applied to the one or more workload elements.

[0100] The 618 processor component can work together with other components (e.g., the 602 patch identification component, the 604 patch execution component, the 606 operations management component, etc., or the 620 data store, etc.) to enable the various functions of the 600 PMC to be performed. The 618 processor component can use one or more processors, microprocessors, or controllers capable of processing data such as information relating to patches, workloads, cloud computing environments, threat assessments, dependencies between nodes, resources, etc., which are associated with a workload, applications, operating systems, middleware, VMs, PMs, containers, resources, nodes, defined patch management criteria, defined patch management algorithms, traffic flows, policies, protocols, interfaces, tools or other information to enable the operation of the PMC 600, as disclosed in more detail, and to control a data flow between the PMC 600 and other components (e.g. a computer, a laptop computer or other data processing or data transmission unit) that are associated with (e.g. connected to) the PMC 600.

[0101] The 620 data store can store data structures (e.g., user data, metadata), one or more code structures (e.g., modules, objects, hash values, classes, procedures) or instructions, information relating to patches, workloads, cloud computing environments, risk assessments, dependencies between nodes, resources, etc., belonging to a workload, applications, operating systems, middleware, VMs, PMs, containers, resources, nodes, defined patch management criteria, defined patch management algorithms, traffic flows, policies, protocols, interfaces, tools, or other information to enable the control of operations belonging to the PMC 600. In one aspect, the 622 processor component (e.g.,(via a working memory bus) are functionally coupled to the data store 624 to store and retrieve information desired to perform a functionality or substantially all other operational aspects of the PMC 600, or to transfer at least part of it to the patch identification component 602, the patch execution component 604, the operations management component 606, etc., or the data store 620, etc.

[0102] The systems or units described here are (or will be described) in terms of an interaction between several components. It should be clear that such systems and components may contain the components or subcomponents listed here, some of the listed components or subcomponents, or additional components. Subcomponents could also be implemented as components that are not contained within higher-level components but are communicatively coupled with other components. Furthermore, one or more components or subcomponents can be combined into a single component to create a composite functionality. The components may also interact with one or more other components, which are not described separately here for the sake of brevity but are known to those skilled in the art.

[0103] Fig. Figure 7 illustrates, according to various aspects and embodiments of the disclosed subject matter, a flowchart of a further non-limiting example method 700 for managing patches belonging to a data processing platform. Method 700 can, for example, be carried out by a system that includes or is operatively connected to a patch identification component, a patch execution component, or a processor component. For the sake of brevity, a repeated description of identical elements used in other embodiments described herein is omitted or can be omitted.

[0104] In 702, a workload belonging to a data processing platform can be identified, where the workload can have an initial workload portion for which an initial subset of patches can be applied. The Patch Identification Component (PMC) can identify or discover the workload (e.g., a hybrid workload) and can identify the initial workload portion (e.g., relevant resources, nodes, or applications, etc.) for which the initial subset of patches can be applied during a maintenance window while the initial workload portion of the data processing platform (e.g., a hybrid cloud computing environment) is offline. It can also identify or discover a second workload portion for which a second subset of patches can be applied while the second workload portion is online.

[0105] In 704, a third subset of patches to be applied to a portion of the first workload within the maintenance window can be determined, at least partially, based on hazard assessments of patches from the first subset of patches belonging to the first workload portion. The first subset of patches may include the third subset of patches. The PMC can determine, at least partially, based on hazard assessments of patches from the first subset of patches belonging to the first workload portion, the third subset of patches to be applied to the portion (e.g., part) of the first workload within the maintenance window while the data processing platform or the relevant portion thereof is offline. For example, the PMC may determine that there is insufficient time available during the maintenance window to apply all patches in the workload portion.The PMC can determine at least the hazard ratings of the first subset of patches belonging to the first workload segment. Based at least partially on the hazard ratings of the patches, the PMC can determine from the first subset that the third subset of patches must be applied to that segment of the first workload within the maintenance window. At least some of the patches in the third subset may have a relatively higher hazard rating than other patches in the first subset that the PMC did not select to be included in the third subset.

[0106] Fig. Section 8 presents, according to various aspects and embodiments of the disclosed subject matter, a flowchart of a further non-limiting example method 800 for managing patches belonging to a data processing platform. Method 800 can, for example, be carried out by a system that includes or is operatively connected to a patch identification component, a patch execution component, or a processor component. For the sake of brevity, a repeated description of identical elements used in other embodiments described herein is omitted or can be omitted.

[0107] In 802, a network can be monitored for requests belonging to resources to enable the identification of workload dependencies between resources. The PMC can monitor the network (e.g., a data processing or data transmission network) for requests belonging to resources (e.g., containers, VMs, PMs, other resources, or nodes) to enable the identification of workload dependencies between resources. A workload dependency can exist between a first type of element (e.g., a node) and one or more other types of elements (e.g., a VM or PM), or between elements of the same type (e.g., a first VM and a second VM).

[0108] In 804, the workload dependencies between resources can be determined at least partially based on monitoring the network for requirements. The PMC can determine the workload dependencies between resources at least partially based on monitoring the network for requirements or by other means of determining such workload dependencies, as described herein. In some embodiments, the PMC can determine or identify the network topology or dependency tree at least partially based on monitoring the network for requirements, as described herein.

[0109] In 806, a workload that has a first workload part to be patched by a first subset of patches in the offline state and a second workload part to be patched by a second subset of patches in the online state can be determined at least partially based on workload dependencies. The PMC can determine the workload at least partially based on the dependencies associated with the workload. The workload can have a first workload part, which may consist of workload elements or resources (e.g., containers, VMs, PMs, resources, nodes, etc.) that are to be patched by the first subset of patches in the offline state (e.g., at least partially due to workload dependencies of such workload elements), and a second workload part that can be patched by the second subset of patches in the online state.

[0110] In 808, hazard ratings can be determined at least for patches of a first subset of patches belonging to the first part of the workload. The PMC can determine (e.g., calculate) the hazard ratings at least for patches of the first subset of patches to be applied to the first part of the workload. In some embodiments, the PMC can also determine the hazard ratings of patches of the second subset of patches.

[0111] In 810, a third subset of patches can be determined, at least partially, based on the threat assessments of the patches and a maintenance window, according to the defined patch management criteria and an associated patch management algorithm. This third subset can be applied to a portion of the first workload from the first subset of patches belonging to the first workload. The PMC can then determine, at least partially, based on the defined patch management criteria and an associated patch management algorithm, the third subset of patches that can be applied to the portion (e.g., a subset of containers, VMs, PMs, other resources, or nodes, etc.) of the first workload from the first subset of patches belonging to the first workload, as described in more detail here.

[0112] In 812, the third subset of patches for the portion of the first workload can be performed during the maintenance window while the resources, nodes, etc., belonging to that portion of the first workload are offline. The patch execution component can perform (e.g., apply) the third subset of patches for that portion of the first workload during the maintenance window while the resources, nodes, applications, etc., of that portion of the first workload are offline. In some embodiments, the PMC can perform the patches of the third subset of patches in topological order according to the network topology. In certain embodiments, the patch execution component can perform patches of the third subset of patches simultaneously (e.g., in parallel) for multiple elements within the available maintenance window.Containers, VMs, PMS, other resources or nodes, etc.), such as elements with dependencies, perform the patching of the first workload portion. The PMC and the patch execution component can perform the patching process to enable the third subset of patches to be applied. This patching process may involve stopping and restarting resources belonging to the first workload portion and warm-starting nodes belonging to the third subset of patches, as described in more detail here.

[0113] In section 814, the patching of the first workload part can be validated during the maintenance window. The PMC can validate the patching of the first workload part within the maintenance window to ensure that the patches were applied correctly and to ensure that the patches, the affected elements of the first workload part, and the data processing system as a whole function correctly after such patches have been applied.

[0114] If, in error 816, it is determined that a patch cannot be validated for one or more workload elements of the first workload part, the patch can be rolled back for those workload elements within the maintenance window to restore them to a previous state before the patching. The PMC can determine whether the patch is validated with respect to the workload elements (e.g., one or more containers, VMs, PMs, other resources, or nodes, etc.). In response to the determination that the patch cannot be validated with respect to the workload elements, the PMC or the patch execution component can roll back the patch for those workload elements within the maintenance window to restore them to a previous state before the patching.

[0115] In 818, the second subset of patches for the second workload segment can be executed. The patch execution component can execute the second subset of patches for the second workload segment, whereby the second subset of patches can be executed while at least the second workload segment is online, or during or outside the maintenance window. In certain embodiments, the patch execution component can execute at least some of the patches of the second subset of patches for the second workload segment simultaneously (e.g., in parallel), with some of the patches of the third subset of patches being executed during the maintenance window for the first workload segment.

[0116] The PMC can also validate the patches applied to the second part of the workload to ensure that the patches were applied correctly and that the patches, the affected elements of the second part of the workload, and the data processing system as a whole function correctly after such patches are applied. The PMC can determine whether a particular patch has been validated with respect to one or more workload elements. In response to a determination that the particular patch cannot be validated with respect to the one or more workload elements, the PMC or the patch execution component can roll back the patch for the one or more workload elements to restore them to a previous state before the patching.

[0117] To simplify the explanation, the computer-implemented processes are presented and described as a sequence of actions. It should be understood and considered that the disclosed subject matter is not limited by the actions shown or by the sequence of actions, but that actions can, for example, occur in different sequences or simultaneously, as well as in conjunction with other actions not shown or described here. Furthermore, it may not be necessary to implement the computer-implemented processes according to the disclosed subject matter. Additionally, the person skilled in the art knows and understands that the computer-implemented processes could alternatively be represented by a state diagram or by state results as a sequence of interrelated states.Furthermore, it should be taken into account that the computer-implemented methods disclosed below and throughout this description can be stored in a manufactured item to enable the forwarding and transfer of such computer-implemented methods to other computers. The term "manufactured item" here refers to a computer program that can be accessed by any computer-readable unit or storage medium.

[0118] In order to put the various aspects of the disclosed subject matter into context, the following should be considered: Fig. 9 and the following discussion provide a general description of a suitable environment in which the various aspects of the disclosed subject matter can be realized. Fig. Figure 9 illustrates a block diagram of a non-restrictive example operating environment in which one or more of the embodiments described herein can be implemented. For the sake of brevity, repeated descriptions of identical elements used in other embodiments described herein are omitted or can be omitted. With reference to Fig. 9 A suitable operating environment 900 for realizing various aspects of this disclosure may also include a computer 912. The computer 912 may also include a processing unit 914, a system memory 916, and a system bus 918. The system bus 918 connects system components, such as the system memory 916, but is not limited to it, to the processing unit 914. The processing unit 914 may be any of the various available processors. Dual-core microprocessors and other multiprocessor architectures may also be used as the processing unit 914. The system bus 918 may be any of several types of one or more bus structures, e.g.The memory bus or memory controller, a peripheral bus or external bus, or a local bus, can be any of a variety of available bus architectures, including, but not limited to, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), CardBus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), FireWire (IEEE 1394), and Small Computer Systems Interface (SCSI). The system memory 916 can also include volatile memory 920 and non-volatile memory 922. The Basic Input / Output System (BIOS), which contains the basic routines for transferring data between elements within the computer 912, for example, during startup, is stored in the non-volatile memory 922.For illustrative purposes and not as a limitation, the non-volatile memory 922 can include a read-only memory (ROM), a programmable ROM (PROM), an electrically programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), flash memory, or non-volatile random access memory (RAM) (e.g., ferroelectric RAM, FeRAM). The non-volatile memory 920 can also include random access memory (RAM) that serves as external cache memory. For illustrative purposes and not as a limitation, RAM is available in many forms, e.g.as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (DRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), Direct Rambus RAM (DRRAM), Direct Rambus Dynamic RAM (DRDRAM) and Rambus Dynamic RAM (RDRAM).

[0119] The Computer 912 may also contain removable / non-removable, volatile / non-volatile computer storage media. Fig. Figure 9, for example, shows a disk storage unit 924. The disk storage unit 924 can also contain units such as a magnetic disk drive, a tape drive, a Jaz drive, a Zip drive, an LS-100 drive, a flash memory card, or a memory stick. The disk storage unit 924 can also contain storage media, either separately or in combination with other storage media, for example, but not limited to, an optical drive such as a compact disc-ROM unit (CD-ROM), a CD-recording drive (CD-R drive), a CD-rewritable drive (CD-RW drive), or a digital versatile disc-ROM drive (DVD-ROM). To enable the disk storage unit 924 to connect to the system bus 918, a removable or non-removable interface, such as the interface 926, is typically used. Fig.9 also represents software that acts as an intermediary between users and the basic computer resources described in the appropriate operating environment 900. Such software may, for example, also include an operating system 928. The operating system 928, which may be stored on disk storage 924, serves to control and allocate resources of the computer 912. System applications 930 take advantage of the management of resources by the operating system 928 through program modules 932 and program data 934, which are stored, for example, either in the system memory 916 or on disk storage 924. It should be obvious that this disclosure can be realized with various operating systems or combinations of operating systems. A user enters commands or information into the computer 912 via one or more input units 936. The input units 936 include a pointing unit such as, for example,A mouse, a trackball, a pen, a keypad, a keyboard, a microphone, a joystick, a gamepad, a satellite dish, a scanner, a TV tuner card, a digital camera, a digital video camera, a webcam, and the like, but not limited to these. These and other input devices are connected to the processing unit 914 via the system bus 918 and one or more interface ports 938. The one or more interface ports 938 include, for example, a serial port, a parallel port, a game port, and a Universal Serial Bus (USB). One or more output units 940 use some of the same type of ports as the one or more input units 936. Thus, a USB port can be used, for example, to provide input to the computer 912 and to output data from the computer 912 to an output unit 940.An output adapter 942 is provided to illustrate that, in addition to other output units 940, some output units 940, such as monitors, speakers, and printers, require special adapters. For illustrative purposes, and not as a limitation, the output adapters 942 include video and sound cards that provide a method for connecting the output unit 940 to the system bus 918. It should be noted that other units or systems of units, such as one or more remotely located computers 944, provide both input and output capabilities.

[0120] The 912 computer can be operated in a networked environment using logic links to one or more remotely located computers, such as the one or more remotely located 944 computers.

[0121] The one or more remotely located computers 944 can be a computer, a server, a router, a network PC, a workstation, a microprocessor-based device, a peer unit, or any other common network node and the like, and can usually also include many or all of the elements described in connection with the computer 912. For brevity, the one or more remotely located computers 944 are illustrated with only a memory unit 946. The one or more remotely located computers 944 can be logically connected to the computer 912 via a network interface 948 and then physically connected via a data link 950. The network interface 948 includes wired or wireless data transmission networks such as local area networks (LANs), wide area networks (WANs), cellular networks, etc.LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring, and the like. WAN technologies include point-to-point connections, circuit-switched networks such as Integrated Services Digital Networks (ISDN) and variations thereof, packet-switched networks, and Digital Subscriber Lines (DSL). The one or more data connections 950 refer to the hardware / software used to connect the network interface 948 to the system bus 918. Although the data connection 950 is shown inside the computer 912 for clarity, it could also be located outside the computer 912. The hardware / software for connecting to the network interface 948 could also include internal and external technologies, such as modems.Common telephone modems, cable modems and DSL modems, ISDN adapters and Ethernet cards, although this is only an example.

Claims

[1] System (100), comprising: a working memory that stores components executable by a computer; and a processor that is operatively connected to the main memory, which executes computer-executable components, wherein the computer-executable components include: a patch identification component (116) that identifies a workload which belongs to a set of patches which belongs to a hybrid cloud-based data processing platform, wherein the workload has a first workload part for which a first subset of patches is to be performed, and a second workload part; a patch management component (114) that: a second subset of patches is determined, which is to be executed with respect to a part of the first workload part based on hazard assessments of patches of the first subset of patches within a maintenance window, wherein the first subset of patches includes the second subset of patches, a third subset of patches is determined to be executed with respect to the second workload part, wherein the set of patches comprises the first subset of patches, the second subset of patches, and the third subset of patches; and a patch execution component (118) that executes the second subset of patches with respect to the part of the first workload part within the maintenance window while the first workload part of the cloud-based hybrid computing platform is offline, and executes the third subset of patches with respect to the second workload part while the second workload part of the cloud-based hybrid computing platform is online. [2] System (100) according to claim 1, wherein the patch execution component (118) executes at least a part of the patches of the second subset of patches simultaneously, wherein the hybrid cloud-based data processing platform comprises nodes and resources, wherein the nodes comprise a first node belonging to a first stage of the first workload part and a second node belonging to a second stage of the first workload part, and wherein the second node is dependent on the first node. [3] System (100) according to claim 1, wherein the hybrid cloud-based data processing platform comprises nodes and resources, wherein the patch management component (114) determines a workload topology, comprising determining dependencies across the nodes of the hybrid cloud-based data processing platform, and wherein, based on the topology, it determines a topological sequence for executing the second subset of patches with respect to the first part of the workload, and wherein the patch execution component (118) executes the patches of the second subset of patches according to the topological sequence. [4] System (100) according to claim 1, wherein the patch execution component (118) executes at least a part of the second subset of patches simultaneously with at least one further patch of the third subset of patches. [5] System (100) according to claim 1, wherein the maintenance window is a period of time during which the nodes and resources of the cloud-based hybrid data processing platform belonging to the first workload part are offline. [6] System (100) according to claim 1, wherein the patch management component (114) determines the hazard ratings of the patches of the first subset of patches belonging to the first workload part based on defined importance levels of the patches and determines the second subset of patches based on a determination that the second subset of patches has a higher overall hazard rating than other subsets of patches. [7] System (100) according to claim 1, wherein the hybrid cloud-based data processing platform comprises nodes and resources, wherein a node of the nodes is selected from a group of nodes consisting of a virtual machine, a physical machine and a container, and wherein a first patch of the patches is executed for a virtual machine instance of the virtual machine, a second patch of the patches is executed for a physical machine instance of the physical machine and a third patch of the patches is executed for a container image of the container. [8] System (100) according to claim 1, wherein the patch management component (114) suspends the operation of nodes and resources belonging to the second subset of patches, wherein the computer-executable components include a patch execution component (118) that executes the second subset of patches with respect to the nodes and resources in response to the suspension of operation, and wherein the patch management component (114) validates that the second subset of patches has been successfully executed, and in response to the validation that the second subset of patches has been successfully executed, restarts the operation of the nodes and resources. [9] System (100) according to claim 1, wherein the patch management component (114), in response to the execution of a patch from the second subset of patches with respect to the application, tests whether the application is in a defined proper operating state, and wherein, in response to a determination that the application is not in a defined proper operating state, the patch management component rolls back the implementation of the patch with respect to the application within the maintenance time window in order to restore the application to a previous state that existed before the patch was executed with respect to the application. [10] System (100) according to claim 1, wherein the workload is a hybrid workload spanning multiple dimensions and relating to features selected from a group of features of the hybrid cloud-based data processing platform, consisting of a number of cloud-based data processing sub-platforms, a number of operating systems, a type of cloud deployment model, a work of resource provisioning, a type of workload, a frequency of workload execution, and development and operational processes. [11] System (100) according to claim 1, wherein the patch management component (114) identifies unapplied patches that were not executed during the maintenance window and determines a next maintenance window to execute at least some of the unapplied patches. [12] A computer-implemented method comprising: Determining a workload belonging to a set of patches belonging to a hybrid cloud-based computing platform by a system connected to a processor, wherein the workload has a first workload part for which a first subset of patches is to be performed, and has a second workload component; Determining a second subset of patches by the system, which is to be applied within a maintenance time window based on hazard assessments of patches from the first subset of patches to a portion of the first workload portion, wherein the first subset of patches includes the second subset of patches; Determining a third subset of patches by the system to be applied to the second workload part, wherein the set of patches comprises the first subset of patches, the second subset of patches, and the third subset of patches; Applying the second subset of patches by the system within the maintenance window to the portion of the first workload while at least part of the first workload of the hybrid cloud-based computing platform is offline; and The system applies the third subset of patches to the second workload part while the second workload part of the hybrid cloud-based data processing platform is online. [13] A computer-implemented method according to claim 12, wherein a first patch and a second patch of the second subset of patches are applied in parallel, and wherein the maintenance window is a period of time during which the cloud-based hybrid data processing platform nodes and resources belonging to the first workload part are offline, and wherein a third patch of the third subset of patches and the first patch are applied in parallel. [14] A computer-implemented method according to claim 12, further comprising: Determining the hazard ratings of the patches in the first subset of patches belonging to the first workload component, by the system, based on defined hazard levels of the patches; and Determining by the system that the second subset of patches has a higher overall hazard rating than other subsets of patches, wherein determining the second subset of patches to be applied to the part of the first workload within the maintenance time window involves determining the second subset of patches based on the finding that the second subset of patches has the higher overall hazard rating. [15] A computer-implemented method according to claim 12, further comprising: The system suspends the operation of nodes and resources belonging to the second subset of patches; The system applies the second set of patches to the nodes and resources in response to the shutdown; The system verifies that the second subset of patches has been successfully applied to the nodes and resources; and In response to verifying that the second subset of patches was successfully applied to the nodes and resources, the system restarts the operation of the nodes and resources. [16] A computer-implemented method according to claim 12, further comprising: In response to a patch from the second subset of patches being applied to an application, the system performs a test to determine whether the application is in a defined, functional operating state; and In response to a determination that the application is not in the defined, functional operating state, the system will revert the implementation of the patch with respect to the application within the maintenance time window in order to restore the application to a previous state that existed before the patch was applied. [17] Computer program product enabling the management of patching for a hybrid cloud-based data processing platform, wherein the computer program product comprises a computer-readable storage medium containing program instructions, wherein the program instructions are executable by a computer system to cause the processor to: to identify a workload that belongs to a set of patches belonging to the hybrid cloud-based computing platform, wherein the workload has a first workload part for which a first subset of patches is to be performed, and a second workload part; to determine a second subset of patches to be applied within a downtime window based on hazard assessments of patches from the first subset of patches to a portion of the first workload portion, wherein the first subset of patches includes the second subset of patches; to determine a third subset of patches to be applied to the second workload part, wherein the set of patches comprises the first subset of patches, the second subset of patches, and the third subset of patches; to apply the second set of patches within the downtime window to the portion of the first workload while at least part of the first workload of the hybrid cloud-based computing platform is offline; and to apply the third subset of patches to the second workload part while the second workload part of the cloud-based data processing platform is online. [18] Computer program product according to claim 17, wherein a first patch and a second patch of the second subset of patches are applied simultaneously and wherein the downtime window is a period of time during which the nodes and resources of the cloud-based hybrid data processing platform belonging to the first workload part are offline, wherein a third patch of the third subset of patches and the first patch are applied simultaneously. [19] System, exhibiting: a working memory that stores components executable by a computer; and a processor that is operatively connected to the main memory, which executes computer-executable components, wherein the computer-executable components include: an update identification component that identifies a workload belonging to a set of updates belonging to a hybrid data processing platform, wherein the workload has a first workload part for which a first subset of updates is to be performed and a second workload part for which a second subset of updates is to be performed; an update management component that identifies a third subset of updates to be applied to a portion of the first workload within a maintenance period, based on hazard assessments of updates from the first subset of updates belonging to the first workload portion, wherein the first subset of updates includes the third subset of updates, and the set of updates includes the first subset of updates, the second subset of updates, and the third subset of updates; and an update execution component that applies the third subset of updates within the maintenance period to the first workload part while at least part of the first workload part of the cloud-based hybrid computing foundation is offline, and applies the second subset of updates to the second workload part while the second workload part of the cloud-based hybrid computing platform is online. [20] System according to claim 19, wherein the maintenance window is a period of time during which the nodes and resources of the cloud-based hybrid data processing platform belonging to the first workload part are offline. [21] System according to claim 19, wherein a first patch and a second patch of the second subset of patches are applied simultaneously and wherein the downtime window is a period of time during which the node and resources of the cloud-based hybrid data processing platform belonging to the first workload part are offline, wherein a third patch of the third subset of patches and the first patch are applied simultaneously. [22] Computer program product enabling the management and updating of a hybrid cloud-based data processing platform, wherein the computer program product comprises a computer-readable storage medium containing program instructions, wherein the program instructions are executable by a computer system to cause the processor to: to identify a workload belonging to a set of updates belonging to a data processing platform, wherein the workload has a first workload part for which a first subset of updates is to be performed, and a second workload part for which a second subset of updates is to be performed; to determine a third subset of updates to be applied to a part of the first workload part within an offline maintenance period based on hazard assessments of updates of the first subset of updates belonging to the first workload part, wherein the first subset of updates includes the third subset of updates and the set of updates includes the first subset of updates, the second subset of updates and the third subset of updates; to apply the third subset of updates within the offline maintenance period to the first workload portion while at least part of the first workload portion of the hybrid cloud-based computing platform is offline; and to apply the second subset of updates to the online workload while the second part of the workload of the hybrid cloud-based data processing platform is online. [23] Computer program product according to claim 22, wherein the maintenance window is a period of time during which the nodes and resources of the cloud-based hybrid data processing platform belonging to the first workload part are offline. [24] Computer program product according to claim 22, wherein the hybrid cloud-based data processing platform comprises nodes and resources, wherein a node of the nodes is selected from a group of nodes consisting of a virtual machine, a physical machine and a container, and wherein a first patch of the patches is executed for a virtual machine instance of the virtual machine, a second patch of the patches is executed for a physical machine instance of the physical machine and a third patch of the patches is executed for a container image of the container. [25] System according to claim 22, wherein a first patch and a second patch of the second subset of patches are applied simultaneously and wherein the downtime window is a period of time during which the node and resources of the cloud-based hybrid data processing platform belonging to the first workload part are offline, wherein a third patch of the third subset of patches and the first patch are applied simultaneously.

Images