Automatic selection of nodes to run tasks

Abstract

A method, computer program product, and computer system for implementing a task on a managed node. A specified task to be executed by an Ansible module on one or more managed nodes of two or more managed nodes is received. The one or more managed nodes are determined based on an attribute value of a hostDecision attribute of the Ansible module. The attribute value can be primaryNode, allNodes, or Dynamic, where primaryNode requests that the one or more managed nodes be primary nodes, allNodes requests that the one or more managed nodes be two or more managed nodes, and Dynamic requests that the one or more managed nodes be dynamically determined based on runtime information. The Ansible module is sent to the one or more managed nodes to execute the task on the one or more managed nodes.

Description

Technical Field

[0001] Embodiments of the present invention generally relate to the deployment of Ansible modules that execute tasks in an Ansible platform using an Ansible engine, and more particularly to selectively determining on which managed nodes tasks will be executed in scenarios where task execution will not be required on all managed nodes within an Ansible host group.

Background Art

[0002] Ansible is an information technology (IT) engine deployed on an Ansible IT platform. The Ansible engine, a software widely used in cloud platforms, automates application deployment by executing one or more tasks defined in an Ansible playbook using Ansible modules. One or more tasks are executed by Ansible modules on all managed nodes of a host group (hereinafter referred to as "host"). The host group is defined in the Ansible playbook. The managed nodes of the host are identified in the Ansible inventory.

[0003] An Ansible playbook is a text script typically written in Yet Another Markup Language (YAML). An Ansible playbook defines, in particular, the name of the playbook, one or more tasks to be executed, and the identification information of the host group in which the managed nodes are identified in the Ansible inventory.

[0004] A host may be category-specific within the system, and a managed node of a host is an instance of that category. Examples of host categories include web servers, database servers, mail servers, and storage repositories. For example, if a host is web server-specific, then each managed node of that host is a specific web server located at an address such as an Internet Protocol (IP) address.

[0005] The Ansible engine runs on an Ansible control node, which is specifically used to select managed nodes on which tasks will be executed, using Ansible playbooks and Ansible inventory as input.

[0006] Ansible roles provide a skeleton for an independent, reusable collection of modules, tasks, variables, files, and templates that can be automatically loaded into Ansible playbooks. Therefore, an Ansible playbook is a collection of Ansible roles. Ansible roles are independent of each other. Ansible Galaxy is a repository of Ansible roles.

[0007] Ansible collections are a distribution format for Ansible content. Ansible playbooks, roles, modules, and plugins can be packaged and distributed using Ansible collections.

[0008] Figure 1 shows an Ansible control node 110 that, using conventional technology, sends module 111 to each of the mutually independent managed nodes 1, 2, 3, and 4 of host group 150 using the Secure Shell (SSH) protocol to execute task 130 on each of them. Task 130 and host group 150 are defined in Ansible playbook 140. Managed nodes 1, 2, 3, and 4 of host group 150 are defined in Ansible inventory 160.

[0009] In the configuration shown in Figure 1, which is typically used in conventional technologies, managed nodes are independent and isolated so that automated actions performed by managed nodes do not affect each other. Therefore, a group of managed nodes will perform the same actions. Thus, in Ansible playbooks, a "host group" is used to easily perform the same task on a group of managed nodes.

[0010] The adoption and use of Ansible has been steadily increasing. Numerous different platforms have joined the Ansible ecosystem. These platforms bring managed nodes that can be visible to or from each other, and actions performed on one managed node may affect other managed nodes. A system in which managed nodes are visible to or from each other is shown as System S in this specification and is illustrated in Figure 1.

[0011] Figure 2 shows an Ansible control node 210 sending module 211 to managed nodes 1, 2, 3, and 4 using the SSH protocol, so that the Ansible module 211 can perform tasks on managed nodes 1, 2, 3, and 4, which are mutually visible to each other in host groups 251, 252, and 253, respectively, according to conventional technology.

[0012] Task 230 and host groups 251, 252, and 253 are defined in Ansible playbook 240. Managed nodes 1, 2, 3, and 4 of host groups 251, 252, and 253 are defined in Ansible inventory 260, with only host group 251 (OSGroup) being explicitly shown in Ansible inventory 260.

[0013] In Figure 2, Play1 in Ansible playbook 240 defines the host group OSGroup and the tasks to be executed on all OS operating systems within system S. The tasks include two commands, command1 and command2, each designed to not affect other OS operating systems.

[0014] Play2 in Ansible playbook 240 defines a task to be executed only once within a sysplex 265 encompassing the host group node1.bj.com and managed nodes 1 and 2. A sysplex refers to a cluster of independent instances of an OS operating system within a complex of multiple computers. Connectivity of managed nodes 1 and 2 to the coupling facility (CF) 270 allows them to share data via the coupling facility link.

[0015] Play 3 in Ansible playbook 240 specifies switching back to the host OSGroup to perform an independent action.

[0016] System S supports Ansible, allowing it to be deployed for hybrid cloud use. However, Ansible Playbook 240 may present two problems in particular:

[0017] The first problem with Ansible playbooks is that end users have to split a single logic process into multiple logic processes so that they can switch hosts, which means that playbooks for system S may look different from those for other platforms, resulting in a learning curve.

[0018] The second problem with Ansible playbooks is that the end user has to decide whether each task should be run once or on all systems S, which can lead to errors and reduced efficiency.

[0019] Furthermore, in hybrid cloud scenarios, Ansible is one of the most popular Infrastructure as Code (IaC) tools. An Ansible playbook is an IaC artifact. In the ideal case, the same IaC artifact provisions the same infrastructure. However, for the reasons mentioned above regarding Figure 2, it becomes difficult to continue using the same IaC artifact (i.e., Ansible playbook) when automation shifts from the public cloud to an on-premises environment.

[0020] Figures 3A and 3B show the conventional Ansible playbook 310 and Ansible inventory 361 for a public cloud 330, and the conventional Ansible playbook 320 and Ansible inventory 362 for an on-premises ("On-Prem") environment 340. Ansible playbooks 310 and 320 are different playbooks.

[0021] Sysplex 365 includes Managed Node 1 and Managed Node 2. Connectivity of Managed Nodes 1 and 2 to the Coupling Facility (CF) 370 allows Managed Nodes 1 and 2 to share data via the Coupling Facility Link.

[0022] In a public cloud (330), since the OS operating systems are isolated from each other, tasks within Ansible playbook (310) are considered executable on all OS operating systems. In an on-premises environment (340), since the OS operating systems may reside within the same sysplex, tasks within Ansible playbook (320) should be executed only once on a specific OS operating system. Therefore, different playbooks are used for public cloud and on-premises environments, which is inefficient and creates vulnerabilities to errors.

[0023] In summary, traditional Ansible lacks sufficient flexibility and analytical capabilities to address the impact of cross-managed nodes, which can lead to problems such as a high learning curve for creating cross-managed node automations, low productivity in creating cross-managed node automations, error-prone automation scripts, and inconsistent IaC code in hybrid cloud scenarios. [Overview of the Initiative]

[0024] Embodiments of the present invention provide a method for implementing tasks on managed nodes, a computer program product, and a computer system. One or more processors of the Ansible engine in an Ansible control node in the computer system receive definitions of tasks to be executed by Ansible modules on one or more managed nodes among a host's multiple managed nodes.

[0025] One or more processors determine one or more managed nodes based on the attribute value of the hostDecision attribute of the Ansible module. The attribute value is selected from a group consisting of primaryNode, allNodes, and Dynamic. primaryNode requires that one or more managed nodes consist of primary nodes selected from a plurality of managed nodes. allNodes requires that one or more managed nodes consist of a plurality of managed nodes. Dynamic requires that one or more managed nodes be dynamically determined based on runtime information including the current status of one or more factors regarding the managed nodes among the plurality of managed nodes obtained by the primary node.

[0026] One or more processors send the Ansible module to one or more managed nodes to execute tasks on the one or more managed nodes.

Brief Description of the Drawings

[0027] [Figure 1] An Ansible control node is shown that uses the Secure Shell (SSH) protocol to send a module to mutually independent managed nodes of a host group so that the module executes tasks on the managed nodes according to the prior art. [Figure 2] An Ansible control node is shown that uses the SSH protocol to send a module to visible managed nodes of a host group so that the module executes tasks on the managed nodes according to the prior art. [Figure 3A] An Ansible playbook for a public cloud is shown according to the prior art. [Figure 3B] An Ansible playbook for an on-premises ("On-Prem") environment is shown according to the prior art. [Figure 4] Shows an Ansible control node according to an embodiment of the present invention. [Figure 5] It is a flowchart describing a method for implementing a task on a managed node according to an embodiment of the present invention. [Figure 6] It is a flowchart describing a method for processing the hostDecision attribute according to an embodiment of the present invention. [Figure 7] Shows a computer system according to an embodiment of the present invention. [Figure 8] Shows a cloud computing environment according to an embodiment of the present invention. [Figure 9] Shows an abstraction model layer according to an embodiment of the present invention.

Mode for Carrying Out the Invention

[0028] Embodiments of the present invention automatically select Ansible managed nodes to avoid cross-host influence. The Ansible engine is extended by supporting the determination of static or dynamic primary nodes for the Ansible inventory. The Ansible engine is further extended to introduce a new attribute hostDecision for Ansible modules, and the value of hostDecision shall be primaryNode, allNodes, or Dynamic. The hostDecision attribute is used to select managed nodes statically or dynamically based on various different factors.

[0029] In various embodiments, the Ansible engine relies on the `hostDecision` attribute, which is specific to an Ansible module configured to perform a particular task, to statically or dynamically determine which managed node in a group of managed nodes should execute a particular task defined in an Ansible playbook. An Ansible module is a computer program (i.e., software) configured to perform a particular task. Thus, an Ansible module executes a particular task on a managed node by running as software on one or more computer processors on the managed node. The `hostDecision` attribute can have values ​​of "primaryNode", "allNodes", and "Dynamic".

[0030] If the hostDecision attribute is set to "primaryNode", the task will run only on the primary node among the nodes in the host group.

[0031] If the hostDecision attribute is set to "allNodes", the task will run on all nodes in the host group.

[0032] If the hostDecision attribute is set to "Dynamic," the one or more nodes (within a host group) on which the task will run are dynamically determined based on the current status of one or more factors relating to the host's managed nodes, including, in particular, the central processing unit (CPU) capacity weight, system environment variables, health status, workload, and busy status.

[0033] Figure 4 shows an Ansible control node 410 according to an embodiment of the present invention.

[0034] The Ansible control node 410 includes an Ansible Galaxy 470, an Ansible playbook 440, an Ansible inventory 460, an Ansible engine 480, a dynamic primary node determination 490, and a configuration file 450. In one embodiment, the dynamic primary node determination 490 is located outside the Ansible engine 480, as shown in the figure. In another embodiment, the dynamic primary node determination 490 is located inside the Ansible engine 480.

[0035] Ansible Galaxy 470 includes Ansible modules 411, 412, 413, and 414, and may also include plugins 416 and 417, which are invokeable by the Ansible engine 480 to perform specialized functions requested or required by the Ansible engine 480 in relation to the task being performed.

[0036] Ansible inventory 460 defines host group 450, as well as managed nodes 1, 2, 3, and 4, identified by "node1.bj.com", "node2.bj.com", "node3.bj.com", and "node4.bj.com", respectively.

[0037] Ansible playbook 440 specifies a host group 450 ("hostGroup"), task 430 (including tasks 431, 432, 433, and 434), and Ansible modules 411, 412, 413, and 414 configured to execute tasks 431, 432, 433, and 434, respectively.

[0038] The Ansible engine 480 sends modules 411, 412, 413, and 414 to the managed node location 465 of managed nodes 1, 2, 3, and 4 using the Secure Shell (SSH) protocol, so that each module performs its module-specific task 430 on one or more of the managed nodes 1, 2, 3, and 4, depending on the hostDecision attribute of each module. Managed node 1 is the primary node in the example in Figure 4.

[0039] In one embodiment, for each Ansible module, the Ansible module's hostDecision attribute value is received by the Ansible engine 480 from any source among various sources, including, in particular, the Ansible module's developer, the Ansible module's user, the initiator or user of the task to be performed by the Ansible module, or the primary node or a subset of the group of nodes on which the task will be performed.

[0040] In one embodiment, the configuration file 450 defines the hostDecision attribute value for each module (module 1: primaryNode; module 2: allNodes; module 3: primaryNode; module 4: Dynamic).

[0041] Therefore, Ansible module 411 has the hostDecision attribute value of "primaryNode". Module 412 has the hostDecision attribute value of "allNodes". Module 413 has the hostDecision attribute value of "primaryNode". Module 414 has the hostDecision attribute value of "Dynamic".

[0042] In one embodiment, a dynamic primary node determination 490 under the control of the Ansible engine 480 may be used to determine which managed node is the primary node.

[0043] In embodiments of the present invention, the end user 435 may statically define the primary node of the host group 450 in the Ansible inventory 460, or the Ansible engine 480 may dynamically determine the primary node using an additional primary node determination module 490. In Figure 4, managed node 1 is the primary node, as shown in managed node location 465 and Ansible inventory 460.

[0044] If the hostDecision attribute value of a module performing a specific task is "primaryNode," then the primary node is the only managed node in the host group on which that particular task can be executed. Therefore, an Ansible task in which the relevant module has hostDecision=primaryNode will not be executed on any other managed nodes in the same host group.

[0045] There are two methods for determining which managed node is the primary node: a static method and a dynamic method.

[0046] In the static method for determining which managed node is the primary node, the end user 435 statically defines the primary node of host group 450 in the Ansible inventory 460, resulting in the primary node being defined in host group 450 within the Ansible inventory 460 as shown in the diagram. The primary node can also be defined in the managed node location 465 as shown in the diagram. The Ansible engine 480 receives the primary node identification information either directly from the user or from storage within the Ansible control node 410, such as from the Ansible inventory 460 or a configuration file 450.

[0047] In a dynamic method for determining which managed node is the primary node, the Ansible engine 480 may dynamically determine the primary node using an additional primary node determination module 490, resulting in the primary node being defined in managed node location 465 and further stored in configuration file 450 and other storage locations within the Ansible control node 410.

[0048] There are two types of dynamic processes that determine which managed node is the primary node based on the current status of one or more factors related to the host's managed nodes.

[0049] In the first type of dynamic processing that determines which managed node is the primary node, the managed nodes are on a public cloud with a node group, for example, [nodeGroup1]node1.cloud.com and node2.cloud.com, where node1 and node2 are standalone nodes typically used as pre-test environments and may be isolated from each other. This first type of "dynamic" processing identifies which managed node is the primary node for node1.cloud.com and which managed node is the primary node for node2.cloud.com. From an implementation perspective, a specific process is executed on both node1 and node2. In this public cloud case, since node1 and node2 are isolated from each other and do not recognize each other, node1 will consider itself the primary node and node2 will consider itself the primary node. Therefore, the dynamic processing returns node1 as the primary node for node1 to the Ansible engine 480. Similarly, the dynamic processing returns node2's primary node to the Ansible engine 480 as node2. The Ansible engine 480 stores the primary node's identification information in the Ansible inventory 460 and configuration file 450.

[0050] Later, when the Ansible engine 480 starts executing a task, if the "hostDecision" of a particular task is "primaryNode", the task on node1 will run on node1, and the same task on node2 will run on node2. In other words, the same task will run on all nodes within "nodeGroup1".

[0051] In the second type of dynamic processing to determine which managed node is the primary node, the managed nodes are in an on-premises ("On-Prem") environment with, for example, a node group [nodeGroup2]node3.customer.com and node4.customer.com, where node3 and node4 are in the customer's data center. If node3 and node4 are in system S, it is very likely that node3 and node4 are in the same sysplex, which means that node3 and node4 may be aware of and influence each other. Because node3 and node4 share the same sysplex, some tasks can only be executed once (i.e., on either node3 or node4). During the "dynamic" processing, node3 and node4 are aware of each other because they are in the same sysplex. Therefore, it is conceivable that the primary node can be dynamically determined based on the current status of one or more factors regarding the managed nodes of the host, and in this example, the managed nodes are node3 and node4. One or more factors relating to a host's managed node include, in particular, the central processing unit (CPU) capacity weight, system environment variables, and health status.

[0052] As an example of using CPU capacity weights to dynamically determine the primary node, system S may include multiple nodes, each assigned a different CPU capacity. In one embodiment, the node assigned the largest CPU capacity is determined to be the primary node.

[0053] As an example of using system environment variables to dynamically determine the primary node, system S may include multiple nodes, each with a specified software product installed (e.g., CICS (a registered trademark of IBM), DB2 (a registered trademark of IBM)). In one embodiment, the node with the latest version of the software product installed is determined to be the primary node.

[0054] As an example of using health status to dynamically determine the primary node, system S may include the health status of multiple products (i.e., hardware products, software products, and combinations thereof) installed on each node. The health status of each product is scored to reflect the degree to which the product complies with hardware requirements, system requirements, security requirements, etc. In one embodiment, the node with the highest health status score is determined to be the primary node.

[0055] If the hostDecision attribute is Dynamic, embodiments of the present invention determine the managed node on which the task will be performed.

[0056] In one embodiment, the decision of which managed node the task should run on may be made by the primary node after the Ansible engine has sent the module to run the task to the primary node, according to the module's hostDecision attribute. The primary node may dynamically determine which managed node the task should run on based on runtime information, including the current status of one or more factors, in particular, such as system environment variables, health data, and workload status. The primary node then returns to the Ansible engine a list of one or more target nodes on which the task should run. The Ansible engine then stores the returned list of one or more target nodes in a storage area within the Ansible control node, and the list of target nodes in that storage area may be accessed later by the Ansible engine.

[0057] In one embodiment, the decision of which managed node a task should be executed on may be made by the Ansible engine after it has received runtime information from the primary node, including, in particular, system environment variables, health data, and workload status. The Ansible engine then stores the returned list of one or more target nodes in a storage area within the Ansible control node, and the list of target nodes in that storage area may be accessed later by the Ansible engine.

[0058] The following example shows how the Ansible engine determines which node a given task will run on when hostDecision is Dynamic.

[0059] The Ansible inventory for this example is as follows: [nodeGroup3] node5.customer1.com node6.customer1.com node7.customer1.com

[0060] The primary node is node5.

[0061] The Ansible playbook for this example is as follows: Play 1: host:nodeGroup3 -Task1(Call Ansible module1 (the hostDecision of module1 is "primaryNode")) -Task2(Call Ansible module2 (the hostDecision for module2 is "allNodes")) -Task3(Call Ansible module3 (the hostDecision for module3 is "Dynamic"))

[0062] When the Ansible engine executes Task1, Task1 should only run on the primary node, and since the primary node is node5, Task1 will only run on node5.

[0063] When the Ansible engine executes Task2, Task2 runs on all nodes (node5, node6, node7).

[0064] When the Ansible engine executes Task3, Task3 triggers a "dynamic" process that dynamically identifies the target node on which Task3 should run. This process is performed using specific logic, which determines the target node based on, but is not limited to, workload balancing, health status, software installation version, and system environment variables.

[0065] Which of the aforementioned factors (workload balancing, health status, software installation version, system environment variables) are used, and how they are used, depends on the implementation of each module. For example, suppose the logic returns node5 and node7 as target nodes. As a result, Task3 will run only on node5 and node7, and not on all nodes. As an example, these factors may be used in system S as follows:

[0066] In this example, regarding the workload balancing factor, Task3 executes a batch job. The primary node, node5, can investigate the current CPU utilization of each node. Since the batch job only needs to run once, and it doesn't matter which node within the same sysplex (node5, node6, and node7 are in the same sysplex) the job should run on, dynamic processing will return node7 as the target node if node7 has the lowest CPU utilization. As a result, Task3 will run only on node7 to implement workload balancing.

[0067] In this example, regarding the health status factor, Task3 deploys a new CICS (IBM registered trademark) application to a node. The application should not be deployed to a CICS (IBM registered trademark) server that is not currently healthy. Therefore, dynamic processing can check the health status of the CICS (IBM registered trademark) servers within each node (e.g., through HealthCheck technology) and return only nodes with healthy CICS (IBM registered trademark) servers, which is a subset of nodes and does not include all nodes. Thus, Task3 is executed only on the returned subset of nodes, not on all nodes.

[0068] In this example, regarding the software installation version factor, Task 3 deploys a CICS (IBM registered trademark) application to a node. A CICS (IBM registered trademark) application may be deployed to any node having a CICS (IBM registered trademark) version number equal to or greater than the specified minimum CICS (IBM registered trademark) version number. Dynamic processing may scan the CICS (IBM registered trademark) version for each node and then return one or more nodes that meet the aforementioned minimum version requirement.

[0069] In this example, regarding the system environment variable factor, Task3 applies a patch if the specified system environment variable has an ON value. Dynamic processing scans the specified system environment variables of each node. If the specified system environment variables of node6 and node7 are ON, and those of node5 are not, node6 and node7 are returned as target nodes, and Task3 is executed only on node6 and node7.

[0070] Figure 5 is a flowchart illustrating a method for implementing a task on a managed node according to an embodiment of the present invention. The method in Figure 5 includes steps 510 to 530.

[0071] Step 510 involves one or more processors of the Ansible engine within the Ansible control node in the computer system receiving a specification for a task to be performed by an Ansible module on one or more managed nodes of a host.

[0072] Step 520 determines one or more managed nodes by one or more processors based on the attribute value of the hostDecision attribute of the Ansible module, the attribute value is selected from the group consisting of primaryNode, allNodes, and Dynamic, primaryNode requests that one or more managed nodes consist of primary nodes selected from multiple managed nodes, allNodes requests that one or more managed nodes consist of multiple managed nodes, and Dynamic requests that one or more managed nodes be dynamically determined based on runtime information obtained by the primary node, including the current status of one or more factors regarding the managed nodes among the multiple managed nodes.

[0073] Step 530 involves one or more processors sending an Ansible module to one or more managed nodes to execute a task on one or more managed nodes.

[0074] Figure 6 is a flowchart illustrating a method for processing the hostDecision attribute according to an embodiment of the present invention. The flowchart in Figure 6 includes steps 610 to 670.

[0075] Step 610 involves the Ansible engine determining whether the hostDecision attribute has the attribute value of allNodes.

[0076] If step 610 determines that the hostDecision attribute has the attribute value allNodes, then in step 620 the Ansible module executes the task on all of the host's multiple managed nodes.

[0077] If step 610 does not determine that the hostDecision attribute has the attribute value allNodes, then the hostDecision attribute is primaryNode or Dynamic, and step 630 is then performed.

[0078] Step 630 determines the primary node by step 631, step 632, or step 633.

[0079] Step 631 involves one or more processors in the Ansible control node receiving the primary node's identification information from the Ansible inventory, which stores the identification information of multiple managed nodes and primary nodes.

[0080] Step 632 involves receiving the dynamic identification of the primary node by one or more processors, where the multiple managed nodes are located on a public cloud such that the managed nodes among the multiple managed nodes are isolated from each other, and receiving the dynamic identification of the primary node includes receiving notification from each managed node that each managed node is the primary node.

[0081] Step 633 involves receiving dynamic identification information for the primary node by one or more processors, where the multiple managed nodes are in the same sysplex in an on-premises environment such that each managed node among the multiple managed nodes is aware of the presence of the other managed nodes among the multiple managed nodes, and receiving dynamic identification information for the primary node includes receiving dynamic identification information for the primary node through a dynamic determination of the primary node based on the current status of one or more factors relating to the managed node among the multiple primary nodes. In one embodiment, one or more factors relating to the managed node include central processing unit (CPU) capacity weight, system environment variables, and health status.

[0082] Step 640 involves the Ansible engine determining whether the hostDecision attribute has the attribute value of primaryNode or Dynamic.

[0083] If step 640 determines that the hostDecision attribute has the attribute value of primaryNode, then in step 650 the Ansible module executes the task on the primary node.

[0084] If step 640 determines that the hostDecision attribute has an attribute value of Dynamic, then step 660 is executed next.

[0085] Step 660 dynamically determines, by one or more processors, which managed node on which the task will be executed, based on runtime information including the current status of one or more factors relating to the managed node among the multiple managed nodes. In one embodiment, one or more factors relating to the managed node include system environment variables, health data, and workload status.

[0086] In step 670, the Ansible module executes the task on one or more managed nodes that were dynamically determined in step 660.

[0087] In one embodiment, dynamically determining one or more managed nodes on which a task is performed includes the primary node dynamically determining one or more managed nodes based on runtime information, and then receiving a list of one or more managed nodes from the primary node by one or more processors.

[0088] In one embodiment, dynamically determining one or more managed nodes on which a task is executed includes receiving runtime information from a primary node by one or more processors, and dynamically determining one or more managed nodes by one or more processors based on the runtime information received from the primary node.

[0089] In one embodiment, the Ansible control node includes an inventory file that defines the hostDecision attribute of the Ansible module.

[0090] In one embodiment, the Ansible control node further includes an Ansible Galaxy, which includes Ansible modules and plug-ins configured to perform specialized functions requested or required by the Ansible engine in relation to the task being performed.

[0091] In one embodiment, the Ansible module executes tasks on one or more managed nodes.

[0092] Figure 7 shows a computer system 90 according to an embodiment of the present invention.

[0093] The computer system 90 includes a processor 91, an input device 92 coupled to the processor 91, an output device 93 coupled to the processor 91, and memory devices 94 and 95, respectively, coupled to the processor 91. The processor 91 represents one or more processors and may represent a single processor or multiple processors. The input device 92 may be a keyboard, mouse, camera, touchscreen, etc., or a combination thereof. The output device 93 may be a printer, plotter, computer screen, magnetic tape, removable hard disk, flexible disk, etc., or a combination thereof. The memory devices 94 and 95 may be a hard disk, flexible disk, magnetic tape, optical storage such as a compact disc (CD) or digital video disc (DVD), dynamic random access memory (DRAM), read-only memory (ROM), or a combination thereof, respectively. The memory device 95 includes computer code 97. The computer code 97 includes an algorithm that performs embodiments of the present invention. The processor 91 executes the computer code 97. Memory device 94 contains input data 96. Input data 96 contains input requested by computer code 97. Output device 93 displays output from computer code 97. One or both of memory devices 94 and 95 (or one or more other memory devices such as read-only memory device 98) may contain algorithms and may be used as computer-readable media (or computer-readable media or program storage devices) in which computer-readable program code is embodied, or other data is stored, or both, and the computer-readable program code includes computer code 97. In general, computer program products (or manufactured products) of computer system 90 may include computer-readable media (or program storage devices).

[0094] In some embodiments, rather than being stored in and accessed from a hard drive, optical disk, or other writable, rewritable, or removable hardware memory device 95, the stored computer program code 99 (including, for example, algorithms) may be stored on a static, non-removable, read-only storage medium such as a read-only memory (ROM) device 98, or may be accessed directly by the processor 91 from such static, non-removable, read-only medium 98. Similarly, in some embodiments, the stored computer program code 97 may be stored as computer-readable firmware 98, or may be accessed directly by the processor 91 from such firmware 98 rather than from a more dynamic or removable hardware data storage device 95 such as a hard drive or optical disk.

[0095] Furthermore, any component of the present invention may be created, integrated, hosted, maintained, deployed, managed, and serviced by a service supplier offering to improve software technology related to cross-reference metrics associated with plug-in components, generate software code modules, and enable the operational functionality of target cloud components. Thus, the present invention discloses a process for deploying, creating, integrating, hosting, or maintaining, or a combination thereof, a computing infrastructure, which includes integrating computer-readable code into a computer system 90, and the code combined with the computer system 90 can perform a method for improving software technology related to cross-reference metrics associated with plug-in components, generating software code modules, and enabling the operational functionality of target cloud components. In another embodiment, the present invention provides a business method for performing the process steps of the present invention on the basis of a contract, advertising, or commission, or a combination thereof. That is, a service provider such as a solution integrator may offer to perform a process for improving software technology related to cross-reference metrics associated with plug-in components, generating software code modules, and enabling the operational functionality of target cloud components. In this case, the service supplier may create, maintain, and support computer infrastructure for one or more customers to perform the process steps of the present invention. In return, the service supplier may receive payments from one or more customers in accordance with a contract or fee arrangement or both, or from the sale of promotional content to one or more third parties, or both.

[0096] Figure 7 shows computer system 90 as a specific configuration of hardware and software, but any configuration of hardware and software that would be known to those skilled in the art may be used with the specific computer system 90 in Figure 7 for the purposes described above. For example, memory devices 94 and 95 may not be independent memory devices but may be part of a single memory device.

[0097] The present invention may be a system, method, or computer program product, or a combination thereof, integrated at any possible level of technical detail. The computer program product may include one or more computer-readable storage media having computer-readable program instructions that cause a processor to perform each aspect of the present invention.

[0098] A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, or a semiconductor storage device. A computer-readable storage medium can be a tangible device capable of holding and storing instructions used by an instruction execution device. A computer-readable storage medium may, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the aforementioned. A non-exclusive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, flexible disks, punch cards, or mechanically encoded devices such as raised structures in grooves on which instructions are recorded, and any suitable combination of the foregoing. When used in this specification, computer-readable storage media shall not be construed as signals that are essentially transient, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0099] The computer-readable program instructions described in this specification are downloadable from computer-readable storage media to individual computing / processing devices, or to external computers or external storage devices via networks such as the Internet, local area networks, wide area networks, or wireless networks, or a combination thereof. The network may include copper transmission cables, optical fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. Each computing / processing device's network adapter card or network interface receives computer-readable program instructions from the network and transfers them for storage on computer-readable storage media within the individual computing / processing device.

[0100] The computer-readable program instructions that perform the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, or similar, and procedural programming languages ​​such as the C programming language or similar. The computer-readable program instructions may run entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it may be connected to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, to carry out each aspect of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuit.

[0101] Each aspect of the present invention is described in this specification with reference to flowcharts or block diagrams, or both, of methods, apparatus (systems), and computer program products according to embodiments of the present invention. Naturally, each block in a flowchart or block diagram, or both, and any combination of multiple blocks in a flowchart or block diagram, or both, can be implemented using computer-readable program instructions.

[0102] Such computer-readable program instructions may also be provided to a computer processor or other programmable data processing device to bring a machine to life, so that the instructions are executed by the processor of the computer or other programmable data processing device to create means for implementing one or more blocks in a flowchart or block diagram or both. Such computer-readable program instructions, which can instruct a computer, programmable data processing device, or other device, or a combination thereof, to function in a particular way, may also be stored on a computer-readable storage medium so that the computer-readable storage medium storing the instructions contains a product containing instructions that implement each aspect of the functions / operations defined in one or more blocks in a flowchart or block diagram or both.

[0103] Furthermore, computer-readable program instructions can be loaded into a computer, other programmable data processing device, or other device to result in a process implemented in the computer, such that a series of operational steps are performed on the computer, other programmable device, or other device, and the instructions executed on the computer, other programmable device, or other device can implement a function / operation defined in one or more blocks of a flowchart or block diagram, or both.

[0104] The flowcharts and block diagrams in each drawing illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this context, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction containing one or more executable instructions that implement a defined logical function(s). In some alternative implementations, the functions shown in a block may occur in a different order than those shown in the drawings. For example, depending on the relevant functionality, two consecutively shown blocks may actually be implemented as a single step, executed simultaneously, executed virtually simultaneously, executed partially or entirely in overlapping timelines, or each block may be executed in reverse order. Furthermore, it should be noted that each block in a block diagram or flowchart, or both, and any combination of multiple blocks in a block diagram or flowchart, or both, can be implemented by a dedicated hardware-based system that performs a defined function or operation or a combination of dedicated hardware and computer instructions.

[0105] The computer program product of the present invention includes one or more computer-readable hardware storage devices storing computer-readable program code, the program code including instructions that can be executed by one or more processors of a computer system to implement the method of the present invention.

[0106] The computer system of the present invention comprises one or more processors, one or more memories, and one or more computer-readable hardware storage devices, wherein the one or more hardware storage devices include program code executable by one or more processors via one or more memories to implement the method of the present invention.

[0107] Cloud computing environment Naturally, although this disclosure includes a detailed description of cloud computing, the implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the present invention can be implemented in relation to any other type of computing environment, whether currently known or to be developed in the future.

[0108] Cloud computing is a service delivery model that provides on-demand, convenient network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and deployed with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0109] The features are as follows:

[0110] On-demand self-service: Cloud consumers can unilaterally provision computing power, such as server time and network storage, automatically as needed, without the need for human interaction with service providers.

[0111] Extensive network access: Each capability is available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0112] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated as needed. Generally, consumers have a sense of location independence in that they have no control or knowledge of the exact location of the resources provided, although at a higher level of abstraction they may be able to specify a location (e.g., country, state, or data center).

[0113] Rapid Scale: Each capacity can be provisioned quickly and flexibly, in some cases automatically, to scale out rapidly, and released quickly to scale in rapidly. Often, consumers perceive each capacity available for provisioning as unlimited, and can purchase any quantity at any time.

[0114] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metric capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage is monitorable, controllable, and reportable, providing transparency to both service providers and consumers.

[0115] The service model is as follows:

[0116] Software as a Service (SaaS): The ability offered to consumers is the use of a provider's applications running on cloud infrastructure. These applications are accessible from various client devices via thin-client interfaces such as web browsers (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, and storage, nor even the capabilities of individual applications, with the exception of limited user-specific application configuration settings.

[0117] Platform as a Service (PaaS): The ability provided to consumers is to deploy applications they have created or obtained, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage, but they do control the deployed applications and, in some cases, the configuration of the application hosting environment.

[0118] Infrastructure as a Service (IaaS): The ability provided to consumers is the provisioning of processing, storage, networking, and other basic computing resources, on which consumers can deploy and run any software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do control the operating system, storage, deployed applications, and, in some cases, select networking components (e.g., host firewalls).

[0119] The deployment model is as follows:

[0120] Private Cloud: Cloud infrastructure is operated for a specific organization only. It can be managed by the organization or a third party and may reside on-premises or off-premises.

[0121] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance awareness). It can be managed by an organization or a third party and may reside on-premises or off-premises.

[0122] Public Cloud: Cloud infrastructure is made available to the public or large industry groups and is owned by organizations that sell cloud services.

[0123] Hybrid Cloud: Cloud infrastructure is a combination of two or more clouds (private, community, or public), where each cloud remains a unique entity, but is bound together by standard or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0124] Cloud computing environments are service-oriented and focus on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0125] Refer to Figure 8 below, which shows an illustrative cloud computing environment 50. As shown in the figure, the cloud computing environment 50 includes one or more cloud computing nodes 40, and local computing devices used by cloud consumers, such as personal digital assistants (PDAs) or mobile phones 54A, desktop computers 54B, laptop computers 54C, or automotive computer systems 54N, or a combination thereof, can communicate with the cloud computing nodes 40. The nodes 40 may communicate with each other. The nodes 40 may be physically or virtually grouped in one or more networks, such as the private, community, public, or hybrid clouds, or a combination thereof (not shown). This allows the cloud computing environment 50 to provide infrastructure, platforms, or software, or a combination thereof, as a service, without requiring cloud consumers to maintain resources on their local computing devices for them. Naturally, the types of computing devices 54A-N shown in Figure 8 are for illustrative purposes only, and the computing node 40 and the cloud computing environment 50 can communicate with any type of computerized device via any type of network or network addressable connection (e.g., using a web browser) or both.

[0126] Refer to Figure 9 below. It shows a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 8). It should be understood that the components, layers, and functionalities shown in Figure 9 are for illustrative purposes only, and embodiments of the present invention are not limited thereto. As shown in the figure, the following layers and corresponding functionalities are provided.

[0127] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include a mainframe 61, RISC (Reduced Instruction Set Computer Architecture) based servers 62, 63, blade servers 64, storage devices 65, and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0128] The virtualization layer 70 provides an abstraction layer that may offer virtual entities such as virtual servers 71, virtual storage 72, virtual networks 73 including virtual private networks, virtual applications and operating systems 74, and virtual clients 75.

[0129] For example, the management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computing and other resources used to perform tasks within the cloud computing environment. Measurement and pricing 82 provides tracking of costs as resources are used within the cloud computing environment and billing or invoicing for the consumption of such resources. For example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, as well as protection of data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 87 provides allocation and management of cloud computing resources to ensure that the required service levels are met. Service Level Agreement (SLA) planning and achievement 88 provides proactive preparation and procurement of cloud computing resources for which future demands are anticipated in accordance with the SLA.

[0130] The workload layer 101 provides examples of functionalities that may be the purpose for which a cloud computing environment is used. Examples of workloads and functionalities that may be provided from this layer include mapping and navigation 31, software development and lifecycle management 32, virtual classroom education delivery 33, data analytics processing 34, transaction processing 35, and task implementation on managed nodes 36.

[0131] The examples and embodiments of the present invention described herein are presented for illustrative purposes only and should not be construed as exhaustive. While embodiments of the present invention are described herein for illustrative purposes, numerous variations and modifications will be apparent to those skilled in the art. The description of the present invention herein explains the principles underlying these examples and embodiments in order to demonstrate practical applications of the present invention and technical improvements of the present invention compared to known technologies, computer systems, or products, or combinations thereof.

Claims

1. A method for implementing tasks on managed nodes, In a computer system, one or more processors of the Ansible engine within an Ansible control node receive from a script within the Ansible control node the definition of a task to be executed by an Ansible module on one or more managed nodes of a host. The determination of one or more managed nodes by one or more processors based on the attribute value of the hostDecision attribute of the Ansible module, wherein the attribute value is selected from the group consisting of primaryNode, allNodes, and Dynamic, primaryNode requests that the one or more managed nodes consist of primary nodes selected from the plurality of managed nodes, allNodes requests that the one or more managed nodes consist of the plurality of managed nodes, and Dynamic requests that the one or more managed nodes be dynamically determined based on runtime information obtained by the primary node, including the current status of one or more factors relating to the managed nodes among the plurality of managed nodes, and the determination of Sending the Ansible module to the one or more managed nodes by the one or more processors so that the task can be executed on the one or more managed nodes: Methods that include...

2. The method according to claim 1, wherein the attribute value is either primaryNode or Dynamic.

3. The identification information of the primary node is received by one or more processors from the Ansible inventory within the Ansible control node. The method according to claim 2, wherein the Ansible inventory stores the identification information of the plurality of managed nodes and the primary node.

4. The static identification information of the primary node, stored in the Ansible inventory by the end user, is received from the end user by one or more processors. The method according to claim 3, including the method described in claim 3.

5. The one or more processors receive dynamic identification information of the primary node from each managed node. The method according to claim 2, including the method described in claim 2.

6. The plurality of managed nodes are located on a public cloud such that the managed nodes among the plurality of managed nodes are isolated from each other, and the reception of the dynamic identification information of the primary node is To receive notification from each of the aforementioned managed nodes that each of the aforementioned managed nodes is the primary node. The method according to claim 5, including the method described in claim 5.

7. The plurality of managed nodes are located in the same sysplex within an on-premises environment such that each of the managed nodes is aware of the presence of the other managed nodes, and the method is The dynamic identification information of the primary node is determined by one or more processors through the dynamic determination of the primary node based on the current status of one or more factors relating to the managed node among multiple managed nodes. The method according to claim 2, including the method described in claim 2.

8. The method according to claim 7, wherein the one or more factors relating to the managed node include a central processing unit (CPU) capacity weight, a system environment variable, and a health status.

9. The method according to claim 2, wherein the attribute value is primaryNode.

10. The attribute value is Dynamic, and the method is The one or more managed nodes on which the task is executed are dynamically determined by one or more processors based on runtime information including the current status of one or more factors relating to the managed node among the plurality of managed nodes. The method according to claim 2, including the method described in claim 2.

11. The method according to claim 10, wherein the one or more factors relating to the managed node include system environment variables, health data, and workload status.

12. The dynamic determination of the one or more managed nodes on which the task is performed is After the primary node dynamically determines one or more managed nodes based on the runtime information, the list of one or more managed nodes is received from the primary node by one or more processors. The method according to claim 10, including the method described in claim 10.

13. The dynamic determination of the one or more managed nodes on which the task is performed is The runtime information is received from the primary node by one or more processors, Based on the runtime information received from the primary node, one or more processors dynamically determine one or more managed nodes. The method according to claim 10, including the method described in claim 10.

14. The method according to claim 1, wherein the Ansible control node further includes a configuration file that defines the hostDecision attribute of the Ansible module.

15. The method according to claim 1, further comprising an Ansible Galaxy, wherein the Ansible control node includes the Ansible module and a plug-in configured to perform specialized functions requested or required by the Ansible engine in relation to the task being performed.

16. Executing the task using the Ansible module on one or more of the managed nodes. The method according to claim 1, including the method described in claim 1.

17. A computer program comprising computer-readable program code, wherein the program code comprises instructions executable by one or more processors of the Ansible engine in an Ansible control node in a computer system to implement a method of implementing a task on a managed node, and the method is The following is a process in which one or more processors receive from a script within the Ansible control node the definition of a task to be executed by an Ansible module on one or more of the host's multiple managed nodes: The determination of one or more managed nodes by one or more processors based on the attribute value of the hostDecision attribute of the Ansible module, wherein the attribute value is selected from a group consisting of primaryNode, allNodes, and Dynamic, primaryNode requests that the one or more managed nodes consist of primary nodes selected from the plurality of managed nodes, allNodes requests that the one or more managed nodes consist of the plurality of managed nodes, and Dynamic requests that the one or more managed nodes be dynamically determined based on runtime information obtained by the primary node, including the current status of one or more factors relating to the managed nodes among the plurality of managed nodes, and the determination of Sending the Ansible module to the one or more managed nodes by the one or more processors so that the task can be executed on the one or more managed nodes: A computer program that includes [this].

18. A computer-readable storage medium recording the computer program described in claim 17.

19. A computer system comprising one or more processors of an Ansible engine in an Ansible control node, one or more memories, and one or more computer-readable hardware storage devices, wherein the one or more hardware storage devices include program code executable by the one or more processors via the one or more memories to implement a method for implementing tasks on a managed node, and the method is The following is a process in which one or more processors receive a definition of a task to be executed by one or more of the host's managed nodes from a script within the Ansible control node: The determination of one or more managed nodes by one or more processors based on the attribute value of the hostDecision attribute of an Ansible module configured to execute the task on the plurality of managed nodes, wherein the attribute value is selected from a group consisting of primaryNode, allNodes, and Dynamic, where primaryNode requests that the one or more managed nodes consist of primary nodes selected from the plurality of managed nodes, allNodes requests that the one or more managed nodes consist of the plurality of managed nodes, and Dynamic requests that the one or more managed nodes be dynamically determined based on runtime information obtained by the primary node, including the current status of one or more factors relating to the managed nodes among the plurality of managed nodes, Sending the Ansible module to the one or more managed nodes by the one or more processors so that the task can be executed on the one or more managed nodes: A computer system that includes [a certain feature].

Images