Self-management configuration of information technology assets in information technology environment

Abstract

The embodiment of the invention relates to self-management configuration of information technology assets in an information technology environment. An apparatus includes at least one processing device configured to deploy an instance of a self-managed information technology asset configuration tool at a given of a plurality of information technology assets in an information technology infrastructure environment. The at least one processing device is further configured to determine a logical assignment order using an instance of a self-managed information technology asset configuration tool deployed on a given information technology asset, the logical dispatch order is to perform a configuration operation on at least one information technology asset of a plurality of information technology assets in an information technology infrastructure environment, wherein the logical dispatch order operates recursively across two or more levels of a processing hierarchy. The at least one processing device is further configured to configure an instance of a tool with a self-managed information technology asset deployed on a given information technology asset.

Description

Background Art

[0001] A support platform may be utilized to provide various services to a collection of managed computing devices. Such services may include, for example, troubleshooting and remediation of problems encountered on computing devices managed by the support platform. This may include periodically collecting information about the status of the managed computing devices, and using this information to troubleshoot and remediate problems. Such troubleshooting and remediation may include receiving requests for services that provide hardware and software components of the computing devices. For example, a user of a computing device may submit a service request to the support platform to troubleshoot and remediate problems with hardware and software components of the computing device. Such a request may be a service performed in accordance with a warranty or other type of service contract provided by the support platform to the user of the computing device. The support platform may also provide functionality for testing managed computing devices. Summary of the invention

[0002] Illustrative embodiments of the present disclosure provide techniques for self-managing configuration of information technology assets in an information technology environment.

[0003] In one embodiment, an apparatus includes at least one processing device, the processing device including a processor coupled to a memory. The at least one processing device is configured to deploy an instance of a self-managed information technology asset configuration tool at a given information technology asset among a plurality of information technology assets in an information technology infrastructure environment. The at least one processing device is also configured to utilize the instance of the self-managed information technology asset configuration tool deployed on the given information technology asset to determine a logical dispatch order for performing configuration operations on at least one of: (i) the given information technology asset and (ii) one or more other information technology assets among the plurality of information technology assets in the information technology infrastructure environment, wherein the logical dispatch order operates recursively across two or more levels of a processing hierarchy. The at least one processing device is also configured to utilize the instance of the self-managed information technology asset configuration tool deployed on the given information technology asset to perform configuration operations according to the determined logical dispatch order.

[0004] These and other illustrative embodiments include, but are not limited to, methods, apparatus, networks, systems, and processor-readable storage media. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a block diagram of an information handling system configured for self-managing configuration of information technology assets in an information technology environment in an illustrative embodiment.

[0006] Figure 2 is a flow chart of an exemplary process for self-managing configuration of information technology assets in an information technology environment in an illustrative embodiment.

[0007] Figure 3 A master node is shown managing the configuration of a set of slave nodes in an illustrative embodiment.

[0008] Figure 4 A recovery dispatch center is shown that is configured to perform restore and delete configuration operations in an illustrative embodiment.

[0009] Figure 5 A depth-first search recursive process flow for operating a recovery dispatch center in an illustrative embodiment is shown.

[0010] Figure 6 A recovery dispatch center configured with a pattern rule extractor for separation of logical workflow configuration and configuration data in configuration operations in an illustrative embodiment is shown.

[0011] Figure 7 A verification center is shown that is configured to process sensitive data in a configuration operation in an illustrative embodiment.

[0012] Figure 8 and Fig. 9 An example of a processing platform that may be used to implement at least a portion of an information handling system in an illustrative embodiment is shown. DETAILED DESCRIPTION

[0013] Illustrative embodiments will be described herein with reference to an exemplary information handling system and associated computers, servers, storage devices, and other processing devices. However, it should be understood that the embodiments are not limited to use with the specific illustrative system and device configurations shown. Therefore, the term "information handling system" as used herein is interpreted broadly to include, for example, processing systems including cloud computing and storage systems, as well as other types of processing systems including various combinations of physical and virtual processing resources. Thus, an information handling system may include, for example, at least one data center or other type of cloud-based system including one or more clouds that host tenants accessing cloud resources.

[0014] Figure 1An information handling system 100 configured according to an illustrative embodiment is shown. It is assumed that the information handling system 100 is built on at least one processing platform and provides functionality for self-managed configuration of information technology (IT) assets in an IT environment such as a distributed system (DS) cluster. As used herein, the term "self-managed configuration" refers to a configuration that can be performed by any one of a collection of IT assets without requiring any dedicated "master" node. The information handling system 100 includes one or more client devices 102 coupled to a network 104. An information technology (IT) infrastructure 105 is also coupled to the network 104, which includes a collection of IT assets 106-1, 106-2, 106-3, ... 106-N (collectively referred to as IT assets 106), a configuration database 108, and a support platform 110. The IT assets 106 may include physical and / or virtual computing resources in the IT infrastructure 105. Physical computing resources may include physical hardware, such as servers, storage systems, network devices, Internet of Things (IoT) devices, other types of processing and computing devices, including desktops, laptops, tablet computers, smart phones, etc. Virtual computing resources may include virtual machines (VMs), containers, and the like.

[0015] In some embodiments, the support platform 110 is used for enterprise systems. For example, an enterprise can subscribe to or otherwise utilize the support platform 110 to manage IT assets 106 of an IT infrastructure 105 operated by the enterprise. Enterprise users (e.g., software developers, test engineers, or other employees, customers, or users who may be associated with different client devices 102) can utilize the support platform 110 to develop self-managed IT asset configuration tools and deploy them to one or more IT assets 106. As used herein, the term "enterprise system" is intended to be broadly interpreted to include any system group or other computing device. For example, the IT assets 106 of the IT infrastructure 105 may provide part of one or more enterprise systems. A given enterprise system may also or alternatively include one or more client devices in the client device 102. In some embodiments, the enterprise system includes one or more data centers, a cloud infrastructure including one or more clouds, and the like. A given enterprise system, such as a cloud infrastructure, can host assets associated with multiple enterprises (e.g., two or more different enterprises, organizations, or other entities).

[0016] Client device 102 may include, for example, a physical computing device such as an IoT device, a mobile phone, a laptop computer, a tablet computer, a desktop computer, or other types of devices used by enterprise members in any combination. Such devices are examples of what are more generally referred to as "processing devices" herein. Some of these processing devices are also generally referred to as "computers" herein. Client device 102 may also or alternatively include virtual computing resources such as VMs, containers, etc.

[0017] In some embodiments, client device 102 includes a corresponding computer associated with a particular company, organization, or other enterprise. Thus, client device 102 can be considered an example of an asset of an enterprise system. In addition, at least a portion of information processing system 100 may also be referred to herein as collectively comprising one or more "enterprises." As will be appreciated by those skilled in the art, many other operational scenarios involving various types and arrangements of processing nodes are possible.

[0018] The network 104 is assumed to include a global computer network such as the Internet, although other types of networks may be part of the network 104, including a wide area network (WAN), a local area network (LAN), a satellite network, a telephone or wired network, a cellular network, a wireless network such as a WiFi or WiMAX network, or various portions or combinations of these and other types of networks. In some embodiments, it is assumed that the IT assets 106 of the IT infrastructure 105 are part of a separate local network that can be used for automatic configuration using the self-managed IT asset configuration tool 160.

[0019] The configuration database 108 is configured to store and record various information used by the support platform 110 and / or the self-managed IT asset configuration tool 160. Such information may include, for example, a dispatch profile for controlling dispatch at different layers or levels (e.g., base level, domain level, module level). Such information may also include pattern rules for determining how to separate logical workflow configurations and configuration data, rules for handling sensitive data, and the like. In some embodiments, one or more storage systems for implementing the configuration database 108 include a scale-out all-flash content-addressable storage array or other type of storage array. Various other types of storage systems may be used, and the term "storage system" used herein is intended to be interpreted broadly and should not be construed as being limited to content-addressable storage systems or flash-based storage systems. A given storage system used extensively herein may include, for example, network-attached storage (NAS), storage area network (SAN), direct-attached storage (DAS), and distributed DAS, as well as combinations of these and other storage types, including software-defined storage.

[0020] Other specific types of storage products that may be used to implement the storage system in the illustrative embodiments include all-flash and hybrid flash storage arrays, software-defined storage products, cloud storage products, object-based storage products, and scale-out NAS clusters. In the illustrative embodiments, a combination of multiple of these and other storage products may also be used to implement a given storage system.

[0021] although Figure 1 Not explicitly shown, one or more input-output devices such as a keyboard, display, or other types of input-output devices may be used to support one or more user interfaces to support platform 110, as well as to support communications between support platform 110 and other related systems and devices not explicitly shown.

[0022] The support platform 110 may be provided as a cloud service accessible by one or more client devices 102 to allow its users to develop and deploy self-managed IT asset configuration tools on IT assets 106 of the IT infrastructure 105. In some embodiments, it is assumed that the client device 102 is associated with a system administrator, IT manager, or other authorized person responsible for managing the IT assets 106. In some embodiments, the IT assets 106 of the IT infrastructure 105 are owned or operated by the same enterprise that operates the support platform 110. In other embodiments, the IT assets 106 of the IT infrastructure 105 may be owned or operated by one or more enterprises that are different from the enterprise that operates the support platform 110 (e.g., the first enterprise provides support for multiple different customers, enterprises, etc.). A variety of other examples are also possible.

[0023] In some embodiments, the client devices 102 and / or IT assets 106 of the IT infrastructure 105 may implement a host agent that is configured to automatically transmit information to / from the support platform 110 or to / from an instance of the self-managed IT asset configuration tool 160. It should be noted that the term "host agent" is generally used herein to include automated entities such as software entities running on processing devices. Therefore, the host agent need not be a human entity.

[0024] Assumptions Figure 1 The support platform 110 and IT assets 106 in the embodiment are implemented using at least one processing device. Each such processing device generally includes at least one processor and associated memory, and implements one or more functional modules or logic for controlling certain features of the support platform 110 or IT assets 106. Figure 1In an embodiment, the support platform 110 implements self-managed IT asset configuration tool development logic 112 and self-managed IT asset configuration tool deployment logic 114. The self-managed IT asset configuration tool development logic 112 is configured to provide an interface (e.g., a graphical user interface (GUI)) that allows a user of the client device 102 to define or develop one or more self-managed IT asset configuration tools, possibly based on information stored in the configuration database 108. The self-managed IT asset configuration tool deployment logic 114 allows a user of the client device 102 to deploy the developed self-managed IT asset configuration tool to one or more IT assets in the IT assets 106 of the IT infrastructure 105. Figure 1 In the example of , the self-managed IT asset configuration tool 160 is deployed on IT asset 106-1 and is used to automatically configure other IT assets 106 in the IT assets 106 (e.g., IT assets 106-2, 106-3, ... 106-N). However, it should be noted that multiple instances of the self-managed IT asset configuration tool 160 can be deployed on multiple IT assets 106 as needed. It is not necessary to use a single IT asset of the IT assets 106 as the "management" node of the IT infrastructure 105. Instead, any IT asset 106 on which the self-managed IT asset configuration tool 160 is deployed can use its tool instance to automatically configure one or more other IT assets 106 in the IT assets 106 (e.g., some of the IT assets 106 that are newly added, have been damaged and need to be recovered).

[0025] exist Figure 1 In an embodiment, an instance of a self-managed IT asset configuration tool 160 is deployed on IT asset 106-1. The self-managed IT asset configuration tool 160 implements configuration dispatch logic 162, sensitive data handling logic 164, and logical workflow and configuration data separation logic 166. The configuration dispatch logic 162 is configured to determine a logical dispatch order for configuration operations on two or more levels of a processing hierarchy, where the configuration operations can recursively operate across two or more levels of the processing hierarchy. The sensitive data handling logic 164 is configured to verify components of a system configuration including sensitive data such as license data, encryption data, etc. The logical workflow and configuration data separation logic 166 is configured to control how to reconstruct configuration data (e.g., user data) at a module level of a processing hierarchy according to a representational state transfer (RESTful) solution rule that is independent of the logical workflow (e.g., the determined logical dispatch order).

[0026] At least portions of the self-managed IT asset configuration tool development logic 112, the self-managed IT asset configuration tool deployment logic 114, the self-managed IT asset configuration tool 160, the configuration dispatch logic 162, the sensitive data handling logic 164, and the logical workflow and configuration data separation logic 166 may be implemented at least in part in the form of software stored in a memory and executed by a processor.

[0027] It should be understood that Figure 1 The specific arrangements of the client devices 102, IT infrastructure 105, configuration database 108, and support platform 110 shown in the embodiments are presented as examples only, and alternative arrangements may be used in other embodiments. As described above, for example, in some embodiments, the support platform 110 (or portions of its components, such as one or more of the self-managed IT asset configuration tool development logic 112 and the self-managed IT asset configuration tool deployment logic 114) may be implemented internally to one or more client devices 102 and / or IT infrastructure 105. In addition, multiple instances of the self-managed IT asset configuration tool 160 (or portions or components thereof, such as one or more of the configuration dispatch logic 162, the sensitive data handling logic 164, and the logical workflow and configuration data separation logic 166) may be deployed on multiple IT assets 106 as needed. As will be described in further detail below, the support platform 110 and other portions of the information processing system 100 may be part of a cloud infrastructure.

[0028] Assumptions Figure 1 The support platform 110 and other components of the information processing system 100 in the embodiment are implemented using at least one processing platform, which includes one or more processing devices, each of which has a processor coupled to a memory. Such a processing device can illustratively include a specific arrangement of computing, storage, and network resources.

[0029] The client devices 102, IT infrastructure 105, configuration database 108, and support platform 110, or components thereof, may be implemented on respective different processing platforms, although many other arrangements are possible. For example, in some embodiments, support platform 110 and at least portions of one or more of client devices 102, IT infrastructure 105, and / or configuration database 108 are implemented on the same processing platform. Thus, a given one of the client devices 102 may be implemented at least in part within at least one processing platform that implements at least a portion of support platform 110.

[0030] The term "processing platform" as used herein is intended to be broadly interpreted to include, but is not limited to, multiple groups of processing devices and associated storage systems configured to communicate over one or more networks. For example, a distributed implementation of the information processing system 100 is possible, where certain components of the system reside in a data center in a first geographic location, while other components of the system reside in one or more other data centers in one or more other geographic locations that are potentially remote from the first geographic location. Therefore, in some implementations of the information processing system 100, the client devices 102, IT infrastructure 105, IT assets 106, configuration databases 108, and support platforms 110, or portions or components thereof, may reside in different data centers. Many other distributed implementations are also possible. The support platform 110 may also be implemented in a distributed manner across multiple data centers.

[0031] The following will be combined Figure 8 and Fig. 9 Additional examples of processing platforms used to implement support platform 110 and other components of information handling system 100 in the illustrative embodiments are described in greater detail.

[0032] It should be understood that Figure 1 The specific set of elements shown in the for self-management configuration of IT assets in an IT environment is presented only as an illustrative example, and additional or alternative elements may be used in other embodiments. Therefore, another embodiment may include additional or alternative systems, devices and other network entities, as well as different arrangements of modules and other components.

[0033] It should be understood that these and other features of the illustrative embodiments are presented by way of example only and should not be construed as limiting in any way.

[0034] Now refer to Figure 2 The flowchart of describes in more detail an exemplary process for self-management configuration of IT assets in an IT environment. It should be understood that this particular process is only an example, and additional or alternative processes for self-management configuration of IT assets in an IT environment may be used in other embodiments.

[0035] In this embodiment, the process includes steps 200 to 204. These steps are assumed to be performed by the self-managed IT asset configuration tool 160 using the configuration dispatch logic 162, the sensitive data handling logic 164, and the logical workflow and configuration data separation logic 166. The process begins at step 200, where an instance of the self-managed IT asset configuration tool (e.g., the self-managed IT asset configuration tool 160) is deployed at a given IT asset (e.g., IT asset 106-1) among a plurality of IT assets (e.g., IT assets 106) in an IT infrastructure environment (e.g., IT infrastructure 105). The given IT asset can be any one of the plurality of IT assets in the IT infrastructure environment (e.g., the given IT asset need not be a dedicated "management" node). One or more additional instances of the self-managed IT asset configuration tool can be deployed on one or more other arbitrary IT assets among the plurality of IT assets in the IT infrastructure environment. In step 202, a logical dispatch order is determined using an instance of a self-managed IT asset configuration tool deployed on a given IT asset for performing configuration operations on at least one of: (i) the given IT asset and (ii) one or more other IT assets of a plurality of IT assets in an IT infrastructure environment. The logical dispatch order operates recursively across two or more levels of a processing hierarchy. In step 204, the configuration operations are performed according to the determined logical dispatch order using the instance of the self-managed IT asset configuration tool deployed on the given IT asset. In some embodiments, the plurality of IT assets are part of a distributed system cluster, and the configuration operations are performed on a local network interconnecting the plurality of IT assets in the distributed system cluster.

[0036] For at least one of: (i) a given IT asset and (ii) one or more other IT assets among a plurality of IT assets in an IT infrastructure environment, the configuration operation may include a restore configuration operation for provisioning a configuration on at least one of: (i) the given IT asset and (ii) one or more other IT assets among a plurality of IT assets in an IT infrastructure environment. The logical dispatch order for the restore configuration operation may recursively operate from a lowest level in two or more levels of a processing hierarchy to a highest level in two or more levels of the processing hierarchy. For at least one of: (i) the given IT asset and (ii) one or more other IT assets among a plurality of IT assets in an IT infrastructure environment, the configuration operation may alternatively include a delete configuration operation for removing a configuration previously provisioned on at least one of: (i) the given IT asset and (ii) one or more other IT assets among a plurality of IT assets in an IT infrastructure environment. The logical dispatch order for the delete configuration operation may recursively operate from a highest level in two or more levels of a processing hierarchy to a lowest level in two or more levels of the processing hierarchy.

[0037] The logical dispatch sequence may be recursively operated across two or more levels of the processing hierarchy using a depth-first search recursive (DFSR) algorithm. For a specified type of IT asset, the two or more levels of the processing hierarchy may include: a first level specifying a first logical dispatch sequence for two or more basic system components, each of the two or more basic system components affecting the overall behavior of the specified type of IT asset; a second level specifying a second logical dispatch sequence for two or more domains, each of the two or more domains including one or more domain system components, the two or more domains including at least a first domain having one or more dependencies with at least a second domain; and a third level specifying a third logical dispatch sequence for two or more modules, each of the two or more modules being associated with at least one of the domain system components. The first, second, and third logical dispatch sequences may be defined in a JavaScript Object Notation (JSON) settings file. For a given one of the two or more modules, the third logical dispatch sequence may specify that configuration data from one or more domain system components associated with the given module is processed according to a set of representational state transfer (RESTful) request pattern rules for reconstructing user data to instantiate a configuration of the given module. For a given one of the two or more modules associated with the two or more domain system components, the third logical dispatch sequence may specify utilizing an idempotent processing operation that allows re-entrant configuration of the same entry point of the given module for each of the two or more domain system components.

[0038] Performing configuration operations according to the determined logical dispatch order may include identifying one or more components of the system configuration that include sensitive data, and validating the identified one or more system configuration components prior to processing the identified one or more system components specified in the determined logical dispatch order. The sensitive data may include at least one of licensing data and encrypted data.

[0039] Development and operations (DevOps) tools can be used for continuous integration and continuous delivery (CICD) systems. DevOps tools can provide a platform for automatically deploying and configuring servers or other IT assets, especially for large server groups or other IT assets (e.g., server or other IT asset clusters). Illustrative embodiments provide technical solutions for automatically configuring servers or other IT assets in a distributed system (DS) cluster. In some embodiments, one or more representational state transfer (REST) ​​application programming interfaces (APIs) are used, with a RESTful module for automatically configuring backup and / or recovery operations of servers or other IT assets in a DS cluster. Advantageously, some embodiments do not require the use of a "master" control module and can therefore easily replace any DevOps configuration management method. In addition, although various embodiments are described with respect to a DS cluster, the technical solutions described herein can be more widely applied to servers or other IT assets that are not part of a DS cluster.

[0040] In one approach, DevOps tools can be used to manage groups of servers or other IT assets with groups of configuration files (such as salt files) by defining settings files to perform configuration operations. The salt host is a primary controller (e.g., a "master" node) that is not allowed to go offline. Taking salt as an example, the salt host sends commands to the "slave" node (e.g., via ZeroMQ), and the slave node reads the command from the message queue (MQ) bus and then hands it over to the slave handler to execute the command. After the command is executed, the result is returned to the master node via the MQ bus. The salt client polls the walking job and the job results are output to a virtual console (e.g., a TTY console). Figure 3 A system 300 implementing the method is shown, wherein a master node 301 communicates with various slave nodes 303-1, 303-2, 303-3, 303-4, and 303-5 running different platforms (eg, Linux, Solaris, FreeBSD, Windows, and OS X, respectively). Figure 3The salt file 310 used is also shown. Most DevOps tools (e.g., puppet, ansible, chef, etc.) work using this method. One advantage of this method is that the DevOps platform can efficiently perform configuration, backup, or recovery when dealing with a large number of servers or other IT assets in a cluster. However, this method also has various disadvantages, including the complexity of setting up a DevOps platform. Another disadvantage of this method is that management is highly dependent on the master node. If the master node crashes or otherwise goes offline, the entire service platform will not be able to manage the configuration, backup, and recovery of servers or other IT assets. Another disadvantage is that the configuration of the master node may depend on externally initiated behavior on one or more public networks. This will expose the operation to the public and bring security risks.

[0041] The illustrative embodiments provide technical solutions for configuring, backing up, and restoring servers or other IT assets that do not rely on any "master" node. Instead, the technical solution allows configuration, backup, and recovery to be performed in a local network without exposing data to the public, and allows automatic configuration of servers or other IT assets (e.g., in a DS cluster). In some embodiments, a RESTful module is provided to back up and / or restore system configurations between different servers or other IT assets (also referred to as nodes) in a cluster. Compared with the use of DevOps tools, these technical solutions greatly simplify configuration operations. However, it should be noted that the technical solution can be used in conjunction with DevOps tools, such as DevOps tools that use RESTful API calls to perform management functions. By implementing RESTful API calls, the technical solutions described herein can store system configurations and data in files or databases, and users can encrypt sensitive data and then read and decrypt the data through POST / PUT RESTful API operations to restore the data to the system. These technical solutions advantageously provide a method for implementing backup and recovery modules for many fields using RESTful APIs.

[0042] A common module, referred to herein as a Recovery Dispatch Center (RDC), is designed to address coupling and cross-coupling between components. Figure 4A system 400 is shown implementing an RDC 401 having three processing levels (also referred to as processing layers) - a base level or layer 403, a domain level or layer 405, and a module level or layer 407. IT assets have a base level configuration, a component level configuration, and a module level configuration. This means that when configuring an IT asset, processing should start from the lowest level and proceed to higher levels in the hierarchy (e.g., starting from the base level 403, then proceeding to the domain level 405, then proceeding to the module level 407). When erasing the configuration of an IT asset, processing should start from the highest level in reverse and proceed to lower levels in the hierarchy (e.g., starting from the module level 407, then proceeding to the domain level 405, then proceeding to the base level 403). The RDC 401 is configured with mappings that follow these rules and is designed to focus on logically managing the entire workflow.

[0043] The basic level 403 handles the basic configuration of IT assets that affects the behavior of the entire IT asset. For example, the network configuration enables the IT asset to access other IT assets through one or more networks. The operator should identify which components operate on the basic level 403 and then define them and their dispatch logic sequence in one or more basic level 403 settings files (e.g., one or more JavaScript Object Notation (JSON) files). Figure 4 In the example of , the basic level 403 dispatch logic sequence includes network 403-1, provider 403-2, region 403-3, and next component 403-4. It should be noted that there may be more or fewer basic level 403 components in the dispatch logic sequence before reaching the next component 403-4.

[0044] The domain level 405 handles domain farm configuration. A domain farm can include many components. Similar to the base level 403, an operator can identify components that operate at the domain level 405, and then define them and their dispatch logic sequence in one or more domain level 405 settings files (e.g., one or more JSON files). The difference with the domain level 405 is that there may be dependencies between domains or between components within a domain. Such dependencies should be defined in the domain level 405 settings files, and RDC401 will follow the dependency logic to perform the domain level 405 configuration. Figure 4 In the example of , the domain level 405 dispatch logic sequence includes component 1 405-1, component 2 405-2, and target component 405-3. It should be noted that there may be more or fewer components in the dispatch logic sequence before reaching the target component 405-3.

[0045] The module level 407 handles module configuration. A module can be part of one or more components. The module level 407 is important to the entire workflow and processes configuration data from domain components of the domain level 405 and reconstructs user data to satisfy the RESTful request pattern to perform configuration operations. Inside the module level 407, there can be logical workflow configurations and configurations or user data mixed together. How to resolve this mixture of logical workflow configurations and configurations or user data will be discussed in more detail below. The operator can define different modules and their dispatch logic sequence in one or more module level 407 setting files (for example, one or more JSON files). In Figure 4 In the example of , the module level 407 dispatch logic sequence includes component start 407-S, part 1 407-1, part 2 407-2, and component completion 407-D. It should be noted that there may be more or fewer parts between component start 407-S and component completion 407-D.

[0046] Different setting files (e.g., JSON files) at the base level 403, domain level 405, and module level 407 determine the entire logical behavior of the configuration (e.g., backup, restore, delete) workflow. By modifying the setting files, users can easily change the configuration workflow dynamically without changing any code.

[0047] Figure 4 Also shown are a perform restore operation 409 and a perform delete operation 411. Perform restore operation 409 includes a basic restore 409-1 using base level 403. Perform restore operation 409 also includes, for each item in the component list, restoring 409-2 the item using domain level 405. Perform restore operation 409 also includes a restore workflow 409-3 using module level 407. Each of 409-1, 409-2, and 409-3 can use one or more POST / PUT REST API calls. Perform delete operation 411 includes module level delete 411-1, domain level delete 411-2, and base level delete 411-3. Each of 411-1, 411-2, and 411-3 can use one or more delete REST API calls.

[0048] The base level 403, domain level 405 and module level 407 use one or more algorithms implemented by RDC 401 to cooperate with each other and work across components. In some embodiments, RDC 401 uses a depth-first search recursive (DFSR) algorithm that starts from the base level 403 and advances from the base level 403 to the domain level 405 and then to the module level 407 components. Some components have cross-dependencies, and based on DFSR, RDC 401 will process subordinate module level 407 components. After completing the module level 407 configuration, RDC 401 will recursively return to the domain level 405 and then return to the base level 403. If the base level 403 has a dependency module, RDC 401 will also process this dependency module to complete the configuration before acquisition and then return to the beginning. Advantageously, it does not matter which layer or component the process starts from, because the DFSR algorithm will find any dependency and then return to the entry. Therefore, the DFSR algorithm will always be able to complete the configuration on the target component.

[0049] Figure 5A process flow 500 for implementing DFSR algorithm routing using RDC 401 is shown. The process flow 500 begins with starting a backup / restore operation in step 501 and making a dispatch to the base level 403 in step 503. In step 505, the base sequence components are run. It should be noted that step 505 can be repeated one or more times until all base sequence components have been run. In step 507, a decision is made as to whether to continue dispatching in the domain level 405. If the result of step 507 is yes, the domain sequence components are run in step 509. It should be noted that step 509 can be repeated one or more times until all domain sequence components have been run. If the result of step 507 is no or after step 509, the process flow 500 proceeds to step 511, in which a decision is made as to whether to continue dispatching in the module level 407. If the result of step 511 is yes, the module rules are run in step 513. This includes obtaining the rule for dispatching the module currently being processed (e.g., "dispatch itself rule") from the backup / restore component 515, and then dispatching the module currently being processed. Once completed, a confirmation of the module currently being processed is provided to the backup / restore component 515 (e.g., "dispatch itself completed"). As described above, step 513 can be repeated one or more times until all module sequence components have been run. When step 513 is completed, the process flow 500 advances to the next domain and returns to step 507. When the domain sequence component is completed in step 509, the process flow 500 advances to the next basic level and returns to step 505. When all basic sequence components are completed in step 505, the process flow 500 advances to the backup / restore component 515. When the backup / restore component 515 determines that all dispatches are completed, the backup / restore operation is completed in step 517.

[0050] The process for resolving reconfiguration conflicts when cross-decoupled components will now be described. When the DFSR algorithm processes across components, it will return to the startup module after the dependency configuration is complete. In this case, some module configurations may have multiple opportunities to reconfigure, which is called reentry configuration (RC). To allow RC, some embodiments first use PUT and then POST operations because the PUT operation is idempotent and allows RC to reach the same entry point. Now, cross-component processing is no longer a problem when jumping between dependency modules. After multiple RC events occur in the target component, the target component will always complete its configuration. The next difficulty is how to handle logical configuration when dealing with cross-dependencies. This may be mixed into the cross-component workflow and become extremely complicated.

[0051] Now, the processing mixture of logic configuration and configuration data will be described. In order to solve the problem of logic and data mixture, some embodiments separate the logic configuration from the configuration data. The solution rule executor (SRE) is designed to handle such problems. Figure 6 An example of a system 600 including an RDC 601 implementing an SRE 605 (e.g., which works at the module level 407 of the overall RDC workflow) is shown. As a user proceeds through the configuration workflow, user data is obtained in block 603 and then fed to the SRE 605. Within the SRE 605, only configuration data is processed to satisfy the RESTful request pattern of the module currently being processed. Each module may define its own data pattern processing rules (e.g., in Figure 6 In the example, the schema JSON rule 650 is shown. The SRE 605 reads from the schema JSON rule set 650 in box 605-1 (e.g., for the module currently being processed), and reconstructs the data in box 605-2 to satisfy the RESTful request scheme specified by the rules read in box 605-1. Then, in box 605-3, the reconstructed data is sent back to the entire RDC workflow. Then, in step 607, the data is sent via a RESTful PUT / POST operation. Therefore, the logical configuration workflow is completely separated from the configuration data. The RDC 601 controls the logical workflow, while the SRE 605 only reconstructs the configuration data.

[0052] The processing of sensitive data will now be described. A system or other IT asset may include various sensitive data, such as license data, SPN data, authentication data, and the like. The Verification Center (VC) is designed to support verification functions for processing sensitive data (e.g., license verification, certificate verification, sensitive data encryption / decryption, and the like). VC may use a mapping table to indicate features and sensitive data. The mapping table defines which data needs to be considered sensitive data, which data needs to be verified based on features, which data should be encrypted / decrypted for users, and the like. The mapping table may be edited so that VC can easily adapt to changes without having to change the code, thereby allowing operators to easily manage all applicable rules. VC may operate or work before the configuration workflow, and any component may be processed by VC before the configuration workflow begins. Based on VC rules, different verifications and / or data encryption / decryption are performed. Figure 7A system 700 implementing VC 701 for license validation is shown, including a validation setup file 703 (e.g., a JSON file) and a validation global script 705 (e.g., vc_setup.py) for supplying a license workflow class context manager 707. The license workflow class context manager 707 implements a license validation function 771 of a VC license class, singleton class, and / or singleton instance 773 based on a set of input arguments 709 (e.g., actions, modules, job identifiers (IDs), etc.).

[0053] The technical solution described herein provides various technical advantages, including in providing self-managed workers. When working in a distributed system cluster, any given IT asset in the cluster (e.g., any one IT asset in the cluster) can act as a service configuration node, which means that a given IT asset can perform configuration operations on other IT assets in the cluster through a local network that interconnects the IT assets in the cluster. For example, consider a new IT asset that joins a given cluster. Any other IT asset in a given cluster can act as a service configuration node to automatically configure the new IT asset using its data (e.g., using a RESTful API request). The technical solution also advantageously does not rely on a "master" control of the configuration of the IT asset. The technical solution does not require any master node to perform configuration operations. Any IT asset can perform configuration operations (e.g., as a crontab job) to automatically implement backup / restore or other configuration operations. The technical solution also advantageously provides an alternative to DevOps. DevOps tools like salt can use a "one command" approach to IT asset configuration or deployment instead of writing complex salt SLS files.

[0054] The technical solutions in some embodiments provide a RESTful solution for realizing automatic configuration within IT assets of a distributed system, as well as automatic configuration of IT assets that are not part of a distributed system. RDC solves the problem of configuring workflows across layers and components, while SRE is used to separate workflow logic configuration from configuration or user data to solve the problem of mixing logical workflow configuration and configuration or user data. VC provides verification functions and functions for processing sensitive data. Therefore, the technical solutions in some embodiments implement a self-management method for backup / recovery and other configuration operations without relying on the main control module. Therefore, these technical solutions can be used as an alternative configuration route for any DevOps tool.

[0055] It should be understood that the specific advantages described above and elsewhere herein are associated with specific illustrative embodiments and need not exist in other embodiments. In addition, the specific types of information processing system features and functions shown in the drawings and described above are merely exemplary, and many other arrangements may be used in other embodiments.

[0056] Now refer to Figure 8 and Fig. 9 Illustrative embodiments of processing platforms for implementing functionality for self-managing configuration of IT assets in an IT environment are described in more detail. Although described in the context of system 100, in other embodiments, these platforms may also be used to implement at least portions of other information processing systems.

[0057] Figure 8 An example processing platform including a cloud infrastructure 800 is shown. The cloud infrastructure 800 includes a plurality of processing platforms that can be used to implement Figure 1 The cloud infrastructure 800 includes a combination of physical and virtual processing resources of at least a portion of the information processing system 100 in the cloud. The cloud infrastructure 800 includes a plurality of virtual machines (VMs) and / or a collection of containers 802-1, 802-2, ... 802-L implemented using a virtualization infrastructure 804. The virtualization infrastructure 804 runs on a physical infrastructure 805 and illustratively includes one or more hypervisors and / or operating system-level virtualization infrastructure. The operating system-level virtualization infrastructure illustratively includes a kernel control group of a Linux operating system or other type of operating system.

[0058] The cloud infrastructure 800 also includes a set of applications 810-1, 810-2, ... 810-L that run on a corresponding one of the sets of VMs / containers 802-1, 802-2, ... 802-L under the control of a virtualization infrastructure 804. The set of VMs / containers 802 may include a corresponding VM, a set of one or more containers, or a set of one or more containers running in a VM.

[0059] exist Figure 8 In some implementations of the embodiments, the VM / container set 802 includes corresponding VMs implemented using a virtualization infrastructure 804 including at least one hypervisor. A hypervisor platform can be used to implement a hypervisor within the virtualization infrastructure 804, wherein the hypervisor platform has an associated virtual infrastructure management system. The underlying physical machine may include one or more distributed processing platforms including one or more storage systems.

[0060] exist Figure 8 In other implementations of the embodiment, the VM / container set 802 includes a corresponding container implemented using a virtualization infrastructure 804, which provides operating system-level virtualization functions, such as support for Docker containers running on a bare metal host or Docker containers running on a VM. The container is illustratively implemented using a corresponding kernel control group of the operating system.

[0061] As is apparent from the above, one or more processing modules or other components of system 100 may each run on a computer, server, storage device, or other processing platform element. A given such element may be viewed as an example of what is more generally referred to herein as a "processing device." Figure 8 The cloud infrastructure 800 shown may represent at least a portion of a processing platform. Another example of such a processing platform is Fig. 9 A processing platform 900 is shown.

[0062] Processing platform 900 in this embodiment comprises a portion of system 100 and includes a plurality of processing devices, denoted as 902 - 1 , 902 - 2 , 902 - 3 , . . . 902 -K, which communicate with each other via a network 904 .

[0063] Network 904 may include any type of network including, for example, a global computer network such as the Internet, a WAN, a LAN, a satellite network, a telephone or wired network, a cellular network, a wireless network such as a WiFi or WiMAX network, or various portions or combinations of these and other types of networks.

[0064] The processing device 902 - 1 in the processing platform 900 includes a processor 910 coupled to a memory 912 .

[0065] The processor 910 may include a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a central processing unit CPU, a graphics processing unit GPU, a tensor processing unit TPU, a video processing unit VPU or other types of processing circuits, as well as parts or combinations of these circuit elements.

[0066] The memory 912 may include any combination of random access memory (RAM), read-only memory (ROM), flash memory, or other types of memory. The memory 912 and other memories disclosed herein should be viewed as illustrative examples of what is more generally referred to as a "processor-readable storage medium" that stores executable program code for one or more software programs.

[0067] Articles comprising such processor-readable storage media are considered to be illustrative embodiments. A given such article may include, for example, any storage array, storage disk, or integrated circuit containing RAM, ROM, flash memory or other electronic memory, or various other types of computer program products. The term "article" as used herein should be understood to not include transient propagation signals. Many other types of computer program products including processor-readable storage media may be used.

[0068] Also included in the processing device 902-1 is a network interface circuit 914 for interfacing the processing device with the network 904 and other system components, and may include a conventional transceiver.

[0069] It is assumed that the other processing devices 902 of the processing platform 900 are configured in a manner similar to the processing device 902 - 1 shown in the figure.

[0070] Likewise, the particular processing platform 900 shown in the figure is presented only as an example, and system 100 may include additional or alternative processing platforms, as well as any combination of many different processing platforms, each such platform including one or more computers, servers, storage devices, or other processing devices.

[0071] For example, other processing platforms for implementing the illustrative embodiments may include a converged infrastructure.

[0072] Therefore, it should be understood that in other embodiments, different arrangements of additional or alternative elements may be used.At least a subset of these elements may be implemented collectively on a common processing platform, or each such element may be implemented on a separate processing platform.

[0073] As previously mentioned, the components of the information handling system disclosed herein may be implemented at least in part in the form of one or more software programs stored in a memory and executed by a processor of a processing device. For example, at least part of the functionality disclosed herein for self-management configuration of IT assets in an IT environment is illustratively implemented in the form of software running on one or more processing devices.

[0074] It should be emphasized again that the above embodiments are presented for illustrative purposes only. Many variations and other alternative embodiments may be used. For example, the disclosed technology may be applied to various other types of information processing systems, information technology assets, etc. In addition, the specific configurations of the system and device elements illustratively shown in the accompanying drawings and the associated processing operations may be changed in other embodiments. In addition, the various assumptions made in the description of the illustrative embodiments above should also be regarded as exemplary, rather than requirements or limitations of the present disclosure. Many other optional embodiments within the scope of the appended claims will be clear to those skilled in the art.

Claims

1. A device comprising: at least one processing device including a processor coupled to a memory; The at least one processing device is configured to: deploying an instance of a self-managing information technology asset configuration tool at a given information technology asset among a plurality of information technology assets in an information technology infrastructure environment; determining, utilizing said instance of said self-managed information technology asset configuration tool deployed on said given information technology asset, a logical dispatch order for performing configuration operations on at least one of: (i) said given information technology asset and (ii) one or more other information technology assets of said plurality of information technology assets in said information technology infrastructure environment, wherein said logical dispatch order operates recursively across two or more levels of a processing hierarchy; and The configuration operations are performed according to the determined logical dispatch order using the instance of the self-managing information technology asset configuration tool deployed on the given information technology asset. 2 . The apparatus of claim 1 , wherein the given information technology asset comprises any one of the plurality of information technology assets in the information technology infrastructure environment.

3. An apparatus according to claim 2, wherein one or more additional instances of the self-managed information technology asset configuration tool are deployed on one or more other arbitrary information technology assets among the plurality of information technology assets in the information technology infrastructure environment.

4. The apparatus of claim 1, wherein the plurality of information technology assets are part of a distributed system cluster, and wherein the configuration operation is performed on a local network interconnecting the plurality of information technology assets in the distributed system cluster.

5. The device according to claim 1, wherein: For at least one of the following: (i) the given information technology asset and (ii) one or more other information technology assets among the multiple information technology assets in the information technology infrastructure environment, the configuration operation includes a recovery configuration operation for provisioning the configuration on at least one of the following: (i) the given information technology asset and (ii) one or more other information technology assets among the multiple information technology assets in the information technology infrastructure environment.

6. The apparatus of claim 5, wherein the logical dispatch order of the restore configuration operations operates recursively from a lowest level of the two or more levels of the processing hierarchy to a highest level of the two or more levels of the processing hierarchy.

7. The device according to claim 1, wherein: For at least one of the following: (i) the given information technology asset and (ii) one or more other information technology assets among the multiple information technology assets in the information technology infrastructure environment, the configuration operation includes a delete configuration operation for removing the configuration previously provisioned on at least one of the following: (i) the given information technology asset and (ii) one or more other information technology assets among the multiple information technology assets in the information technology infrastructure environment.

8. The apparatus of claim 7, wherein the logical dispatch order of the delete configuration operations operates recursively from a highest level of the two or more levels of the processing hierarchy to a lowest level of the two or more levels of the processing hierarchy.

9. The apparatus of claim 1, wherein the logical dispatch order utilizes a depth-first search recursive DFSR algorithm to recursively operate across the two or more levels of the processing hierarchy.

10. The apparatus of claim 1, wherein for a given type of information technology asset, the two or more levels of the processing hierarchy include: a first level specifying a first logical dispatch sequence for two or more basic system components, each of the two or more basic system components affecting an overall behavior of information technology assets of the specified type; a second level specifying a second logical dispatch sequence for two or more domains, the two or more domains each including one or more domain system components, the two or more domains including at least a first domain, the first domain having one or more dependencies with at least a second domain; as well as A third level specifies a third logical dispatch sequence for two or more modules, each of the two or more modules being associated with at least one of the domain system components.

11. The apparatus of claim 10, wherein the first logic dispatch sequence, the second logic dispatch sequence, and the third logic dispatch sequence are defined in a JavaScript Object Notation (JSON) settings file.

12. An apparatus according to claim 10, wherein, for a given module among the two or more modules, the third logical dispatch sequence specifies that configuration data from one or more of the domain system components associated with the given module is processed according to a set of representational state transfer RESTful request pattern rules for reconstructing user data to instantiate the configuration of the given module.

13. The apparatus of claim 10 , wherein, for a given module of the two or more modules associated with two or more domain system components, the third logical dispatch sequence specifies utilizing an idempotent processing operation that allows for re-entrant configuration of the same entry point of the given module of each of the two or more domain system components.

14. The apparatus of claim 1 , wherein performing the configuration operations according to the determined logical dispatch order comprises: identifying one or more components of a system configuration that includes sensitive data, wherein the sensitive data includes at least one of licensing data and encryption data; as well as Prior to processing the identified one or more components of the system as specified by the determined logical dispatch order, the identified one or more components of the system configuration are validated.

15. A computer program product comprising a non-transitory processor-readable storage medium having stored therein program code of one or more software programs, wherein the program code, when executed by at least one processing device, causes the at least one processing device to: deploying an instance of a self-managing information technology asset configuration tool at a given information technology asset among a plurality of information technology assets in an information technology infrastructure environment; determining, utilizing said instance of said self-managed information technology asset configuration tool deployed on said given information technology asset, a logical dispatch order for performing configuration operations on at least one of: (i) said given information technology asset and (ii) one or more other information technology assets of said plurality of information technology assets in said information technology infrastructure environment, wherein said logical dispatch order operates recursively across two or more levels of a processing hierarchy; and The configuration operations are performed according to the determined logical dispatch order using the instance of the self-managing information technology asset configuration tool deployed on the given information technology asset.

16. The computer program product of claim 15, wherein the plurality of information technology assets are part of a distributed system cluster, and wherein the configuration operations are performed on a local network interconnecting the plurality of information technology assets in the distributed system cluster.

17. The computer program product of claim 15, wherein for a specified type of information technology asset, the two or more levels of the processing hierarchy include: a first level specifying a first logical dispatch sequence for two or more basic system components, each of the two or more basic system components affecting an overall behavior of information technology assets of the specified type; a second level specifying a second logical dispatch sequence for two or more domains, the two or more domains each including one or more domain system components, the two or more domains including at least a first domain, the first domain having one or more dependencies with at least a second domain; as well as A third level specifies a third logical dispatch sequence for two or more modules, each of the two or more modules being associated with at least one of the domain system components.

18. A method comprising: deploying an instance of a self-managing information technology asset configuration tool at a given information technology asset among a plurality of information technology assets in an information technology infrastructure environment; determining, utilizing said instance of said self-managed information technology asset configuration tool deployed on said given information technology asset, a logical dispatch order for performing configuration operations on at least one of: (i) said given information technology asset and (ii) one or more other information technology assets of said plurality of information technology assets in said information technology infrastructure environment, wherein said logical dispatch order operates recursively across two or more levels of a processing hierarchy; and utilizing said instance of said self-managed information technology asset configuration tool deployed on said given information technology asset to perform said configuration operations in accordance with said determined logical dispatch order; Wherein the method is performed by at least one processing device comprising a processor coupled to a memory.

19. The method of claim 18, wherein the plurality of information technology assets are part of a distributed system cluster, and wherein the configuration operation is performed on a local network interconnecting the plurality of information technology assets in the distributed system cluster.

20. The method of claim 18, wherein for a given type of information technology asset, the two or more levels of the processing hierarchy include: a first level specifying a first logical dispatch sequence for two or more basic system components, each of the two or more basic system components affecting an overall behavior of information technology assets of the specified type; a second level specifying a second logical dispatch sequence for two or more domains, the two or more domains each including one or more domain system components, the two or more domains including at least a first domain, the first domain having one or more dependencies with at least a second domain; as well as A third level specifies a third logical dispatch sequence for two or more modules, each of the two or more modules being associated with at least one of the domain system components.

Images