A management system and method for controlling a dynamic system configuration

Abstract

The present invention relates to a management system (100) for controlling a dynamic system configuration. The management system (100) is configured to analyse current and past configurations of a multi-component computing system using a machine learning model. The machine learning model predicts future demands for the multi-component computing system's resources, thereby generating optimised configuration settings to be deployed in the multi-component computing system's environment. The management system (100) comprises a plurality of data collection agents or DCAs (10), a unified metrics collector or UMC (20), a metrics pre-processor or MPP (30), an intelligent analysis module or IAM (40), an execution engine or EE (50), and a plurality of configurator agents or CAs (60).

Description

[0001] A MANAGEMENT SYSTEM AND METHOD FOR CONTROLLING A DYNAMIC SYSTEM CONFIGURATION

[0002] FIELD OF INVENTION

[0003] The present invention relates to a management system and method for controlling a dynamic system configuration. More particularly, the present invention relates to a management system and method for controlling a dynamic system configuration based on a prediction of resource utilisation using a machine learning model.

[0004] BACKGROUND OF THE INVENTION

[0005] Computational systems are engineered to manage a broad range of tasks, from simple calculations to complex data analysis. Their effectiveness, however, is highly dependent on their configuration. This encompasses hardware specifications, operating system adjustments, network configurations, and application settings. Attaining an optimal configuration is crucial for ensuring the systems to operate at peak performance. By assessing system performance and pinpointing areas for improvement, more efficient resource utilisation can be achieved. In view of this, various systems and methods have been developed to enhance computational systems by configuring their settings, software, and hardware components.

[0006] One example of such systems and methods is disclosed in a United States Patent Publication No. US11341025 B2. This publication discloses the use of a processor configured to receive at least one log message denoting an event associated with at least one application executing in its system. A machine learning model is utilised to generate a predicted log message, wherein the predicted log message represents a prediction of a subsequent log message to be received from the application. The processor is also configured to determine metric data associated with the predicted log message, wherein the metric data is further used to determine a tuning profile comprising one or more parameters associated with a past system configuration. A current system configuration of the system is then modified using the one or more parameters of the tuning profile.

[0007] Although various systems and methods have been developed to optimise the configuration of computational systems, the algorithms employed are typically limited to the known or readily available information in the systems. As such, most of them are not designed to handle dynamic analysis and decision-making that requires an interaction with the systems’ environment. This limitation is especially critical in multi-layered complex systems, where inadequate management of a large volume of transactional data processed asynchronously can significantly impact resource utilisation within the systems. Such inefficiencies can be problematic when handling complex or time-sensitive tasks that require a high level of precision and speed. As such, ensuring computing systems are efficiently set up is vital for maximising resource utilisation efficiency and reducing the risk of errors and data loss. Therefore, there is a need to address the abovementioned drawbacks.

[0008] SUMMARY OF INVENTION

[0009] According to one aspect of the present invention, a management system (100) for controlling a dynamic system configuration is provided. The management system (100) comprises a plurality of data collection agents or DCAs (10) configured to collect a plurality of parameter data from a plurality of configurable components (2). The management system (100) is characterised in that the management system (100) further comprises a unified metrics collector or UMC (20) configured to transform and unify the plurality of parameter data into a standardised data format, wherein the UMC (20) is connected to the DCAs (10); a metrics pre-processor or MPP (30) configured to perform data pre-processing on the plurality of parameter data, wherein the MPP (30) is connected to the UMC (20); and an intelligent analysis module or IAM (40) configured to analyse the plurality of parameter data to generate optimised configuration settings using a machine learning model, wherein the IAM (40) is connected to the MPP (30).

[0010] Preferably, the management system (100) further comprises an execution engine or EE (50) configured to coordinate the deployment of the optimised configuration settings, wherein the EE (50) is connected to the IAM (40).

[0011] Preferably, the management system (100) further comprises a plurality of configurator agents or CAs (60) configured to implement the optimised configuration settings, wherein the plurality of CAs (60) is connected to the EE (50). According to another aspect of the present invention, a method for controlling a dynamic system configuration is provided. The method is characterised by the steps of collecting a plurality of parameter data from a plurality of configurable components (2) by a plurality of data collection agents or DCAs (10); transforming and unifying the plurality of parameter data into a standardised data format by a unified metrics collector or UMC (20); pre-processing the standardised data by a metrics pre-processor or MPP (30); analysing the data using a machine learning model to generate optimised configuration settings by an intelligent analysis module or IAM (40); coordinating the deployment of the optimised configuration settings by an execution engine or EE (50); and implementing the optimised configuration settings by a plurality of configurator agents or CAs (60).

[0012] Preferably, the step of transforming and unifying the plurality of parameter data by the UMC (20) further comprises determining whether the data come from multiple sources; performing data tagging if the data comes from multiple sources; filtering the data based on pre-determined criteria; enriching the data to add or extract additional contextual information; determining if the data is in a standard format; parsing the data if the data is not in a standard format; and unifying the data into a single time-series data format.

[0013] Preferably, the step of pre-processing the plurality of standardised parameter data by the MPP (30) further comprises splitting the data according to a component’s key; performing data preprocessing; and merging the data into a single data frame.

[0014] Preferably, the step of performing data preprocessing includes performing either data cleaning, data transformation, data encoding, data aggregation, feature engineering, data serialisation, or any combination thereof.

[0015] Preferably, the step of analysing the plurality of pre-processed parameter data using the machine learning model to generate the optimised configuration settings by the IAM (40) further comprises determining if the method is in its first iteration; if the method is in its first iteration, listening to input data from the MPP (30); defining a reward policy; and determining executable actions to perform. Preferably, if the method is in its subsequent iteration, the step comprises listening to new input data from the MPP (30); evaluating the new input data against the reward policy; receiving a reward or punishment based on the performance of the optimised configuration settings; updating the reward policy; and determining the next executable actions to perform.

[0016] Preferably, the step of coordinating the deployment of the optimised configuration settings by the EE (50) further comprises performing data segmentation; and performing data mapping.

[0017] Preferably, the step of implementing the optimised configuration settings by the CAs (60) further comprises applying the optimised configuration settings by updating the current configuration settings of the respective configurable components (2); monitoring for the next scheduled update at pre-determined time intervals; checking if an instruction from the EE (50) to perform a new configuration settings update is received; and if the instruction from the EE (50) is received, repeating the steps of applying the optimised configuration settings, monitoring for the next scheduled update, and checking the instruction from the EE (50).

[0018] BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.

[0020] FIG. 1 illustrates a block diagram of a management system (100) for controlling a dynamic system configuration according to an embodiment of the present invention.

[0021] FIG. 2 illustrates a flowchart of a method for controlling a dynamic system configuration according to an embodiment of the present invention.

[0022] FIG. 3 illustrates a flowchart of the sub-steps of transforming and unifying parameter data by a Unified Metrics Collector or UMC (20) as done in the method of FIG. 2. FIG. 4 illustrates a flowchart of the sub-steps for pre-processing standardised parameter data by a Metrics Pre-Processor or MPP (30) as done in the method of FIG. 2.

[0023] FIG. 5 illustrates a flowchart of the sub-steps for generating optimised configuration settings by an Intelligent Analysis Module or IAM (40) as done in the method of FIG. 2.

[0024] FIG. 6 illustrates a flowchart of the sub-steps for coordinating the deployment of the optimised configuration settings by an Execution Engine or EE (50) as done in the method of FIG. 2.

[0025] FIG. 7 illustrates a flowchart for the sub-steps for executing the optimised configuration settings by a plurality of Configurator Agents or CAs (60) as done in the method of FIG.

[0026] 2.

[0027] DESCRIPTION OF THE PREFERRED EMBODIMENT

[0028] A preferred embodiment of the present invention will be described herein below with reference to the accompanying drawings. In the following description, well known functions or constructions are not described in detail since they would obscure the description with unnecessary detail.

[0029] Reference is initially made to FIG. 1 , wherein FIG. 1 illustrates a block diagram of a management system (100) for controlling a dynamic system configuration according to an embodiment of the present invention. The system (100) is configured to analyse current and past configurations of the multi-component computing system using a machine learning model. The machine learning model predicts future demands for the multi-component computing system's resources, thereby generating optimised configuration settings to be deployed in the multi-component computing system's environment. This enables the multi-component computing system to allocate and deallocate resources based on real-time demand, utilising optimal settings tailored to the specific workload and environmental conditions.

[0030] While the exemplary embodiments discussed herein may be implemented for various multi-component computing systems, for illustrative purposes, the embodiments of this present invention will be discussed in the context of controlling a dynamic system configuration in a blockchain computing system. As seen in FIG. 1 , the blockchain computing system includes a plurality of client applications (1 ) and a plurality of configurable components (2). Client applications (1) may refer to any software or interface that interacts with the blockchain system. Configurable components (2) may refer to any hardware, software, or middleware that may be adjusted or optimised by the management system (100) to enhance the performance of the blockchain system. For example, the configurable components (2) include but are not limited to load balancers, blockchain computational resources, blockchain nodes, virtual machines, etc. These configurable components (2) may be monitored for their performance metrics using a monitoring and alerting toolkit. Additional components within the blockchain system may either be directly connected to the configurable components (2) or remain unconnected.

[0031] The management system (100) comprises a plurality of data collection agents or DCAs (10), a unified metrics collector or UMC (20), a metrics pre-processor or MRP (30), an intelligent analysis module or IAM (40), an execution engine or EE (50), and a plurality of configurator agents or CAs (60).

[0032] The DCAs (10) are located within each configurable component (2). The DCAs (10) are configured to collect a plurality of parameter data from the configurable components (2). The parameter data include but are not limited to current configurations and metrics data such as CPU usage, memory allocation, network statistics, ledger blockchain height, number of deliver requests that have been completed, number of transactions processed, error messages, etc. The DCAs (10) may be a custom code, a third-party tool agent integrated into the multi-component computing system, a built-in system daemon, etc. The DCAs (10) may operate as a single agent or multiple agents within each configurable component (2), wherein each agent may be tasked with collecting specific parameters relevant to the configurable component (2). For instance, a first DCA agent may be configured to collect the current configurations of a first configurable component, a second DCA agent may be configured to collect error and warning information of the first configurable component, a third DCA agent may be configured to collect the metric data of the first configurable component, etc. The UMC (20) is connected to the DCAs (10). The UMC (20) is configured to transform and unify the parameter data received from the DCAs (10) into a single, standardised data format. The UMC (20) includes a plurality of listener services and a unifier service. The listener services are configured as a passive component that listens for incoming parameter data from multiple DCAs (10) and transforms the parameter data into a standardised format. The transformation includes actions such as data tagging, data filtering, contextual enrichment, data extraction, and data parsing. For instance, the parameter data transmitted by multiple DCAs (10) may initially be in various formats such as text streams, binary data, comma-separated values or CSV, etc. The listener services convert these parameter data into a standardised format such as a JavaScript Object Notation or JSON format. The unifier service is configured to parse and unify the parameter data coming from multiple listener services into a single time series data format.

[0033] The MRP (30) is connected to the UMC (20). The MPP (30) is configured to perform data pre-processing on the standardised parameter data received from the UMC (20). The data pre-processing is performed to prepare the data as inputs to the machine learning model. The data pre-processing includes techniques such as data cleaning, data transformation, data encoding, data aggregation, feature engineering, and data deserialisation.

[0034] The IAM (40) is connected to the MPP (30). The IAM (40) is configured to analyse the pre-processed parameter data received from the MPP (30) to generate the optimised configuration settings using the machine learning model. To generate the optimised configuration settings, the IAM (40) learns from past configuration settings, metrics data, and current data inputs collected in the multi-component computing system’s environment to make predictions on what the optimised settings may be. The IAM (40) employs a reinforcement learning technique for its machine learning model, enabling it to make decisions based on feedback from its environment through multiple iterations.

[0035] In reinforcement learning, an agent within the IAM (40) learns to make decisions by performing executable actions based on a reward policy. The reward policy is a strategy or rule that the agent employs to determine what executable actions to perform given a particular state in the multi-component computing system’s environment. The agent refines this policy through multiple iterations, wherein the agent receives automatic feedback for a particular action in the form of rewards or punishments from the management system (100). The rewards or punishments may be in the form of scalar values. The agent would then adjust the policy accordingly, thus continually learning from the rewards or punishments it receives with a goal of maximising the cumulative rewards. In a preferred embodiment, these rewards or punishments are defined by comparing the performance of newly deployed configuration settings to the previously deployed configuration settings. The agent may refine the policy using algorithms such as Q-learning, Policy Gradients, or Deep Q- Networks.

[0036] The EE (50) is connected to the IAM (40). The EE (50) is configured to process and coordinate the deployment of the optimised configuration settings received from the IAM (40) to the respective CAs (60). The EE (50) includes a repository that stores all optimised configuration settings provided by the IAM (40) and transmits instructions that direct the respective CAs (60) to implement the optimised configuration settings. To coordinate the deployment of the configuration settings, the EE (50) performs actions that include data segmentation and data mapping. Data segmentation is performed to splice bulk configuration settings data into smaller, manageable segments while data mapping is performed to map these segmented data to the respective CAs (60). Additionally, the EE (50) is further configured with necessary access credentials to transmit these configuration settings to the appropriate CAs (60), ensuring each configurable component (2) receives the correct configuration settings.

[0037] The CAs (60) are located within each configurable component (2) and are connected to the EE (50). The CAs (60) are configured to implement the deployed configuration settings received from the EE (50) within the multi-component computing system’s environment. As the CAs (60) receive the instructions from the EE (50), the CAs (60) implement the configuration settings by updating or changing the current configurations of the respective configurable components (2).

[0038] Reference is now made to FIG. 2 which illustrates a flowchart of a method for controlling a dynamic system configuration according to an embodiment of the present invention. The method initially begins with a manual configuration of the multicomponent computing system as in step 300, whereby a user manually sets up the configurable components (2) for the operation of the multi-component computing system. Next, each of the DCA (10) collects the parameter data from the configurable components (2) as in step 301. The DCAs (10) then transmit the collected parameter data to the UMC (20).

[0039] Once the UMC (20) receives the collected parameter data, the UMC (20) proceeds to transform and unify the parameter data into a single, standardised data format as in step 302. Within the UMC (20), the listener services receive the collected parameter data from multiple DCAs (10) and transform the data into a standardised format. Subsequently, the unifier service parses and unifies the data that are coming from the multiple listener services into a single time-series data format. The sub-steps of transforming and unifying the parameter data will be described in detail in relation to FIG. 3.

[0040] Thereon, the UMC (20) transmits the standardised parameter data to the MPP (30), preferably in batches. The MPP (30) then proceeds to pre-process the standardised parameter data as in step 303. The data pre-processing is performed to fine-tune the standardised parameter data by filtering out any noises, refining all relevant data, and converting and merging the data into a single data frame. The substeps of pre-processing the standardised parameter data will be described in detail in relation to FIG. 4.

[0041] Once the parameter data has been pre-processed, the UMC (30) transmits the pre-processed parameter data to the IAM (40). The IAM (40) then analyses the pre- processed parameter data to generate the optimised configuration settings as in step 304. The IAM (40) utilises the machine learning model to learn from past configuration settings, metrics data, and current data inputs collected in the multi-component computing system. Based on the learning process, the IAM (40) develops and refines the reward policy used to determine the executable actions to perform given a particular state of the multi-component computing system. The sub-steps of generating the optimised configuration settings will be described in detail in relation to FIG. 5.

[0042] Next, the IAM (40) transmits the optimised configuration settings to the EE (50), wherein the EE (50) then stores and coordinates the deployment of the optimised configuration settings as in step 305. The EE (50) also transmits an instruction that directs the respective CAs (60) to implement the optimised configuration settings. To prepare the optimised configuration settings for deployment, the EE (50) performs actions that include data segmentation and data mapping. The sub-steps of coordinating the deployment of the optimised configuration settings will be described in detail in relation to FIG. 6.

[0043] Upon receiving the instruction from the EE (50), the respective CAs (60) then proceed to implement the optimised configuration settings as in step 306. This is done by updating or changing the current configuration settings of the configurable components (2) to the optimised configuration settings received from the EE (50). The sub-steps of implementing the optimised configuration settings will be described in detail in relation to FIG. 7. Steps 301 to 306 are then repeated until a stopping criterion is met.

[0044] Reference is now made to FIG. 3 which illustrates a flowchart of the sub-steps of transforming and unifying the parameter data by the UMC (20) as done in step 302 of the method of FIG. 2. Initially, when the listener services receive the incoming parameter data, the listener services determine whether the data come from multiple sources as in step 3021 . If the listener services determine that the data does not come from multiple sources, the listener services proceed to filter the data based on predetermined criteria as in step 3022. By filtering the data, the listener services are able to focus on data that are of interest or represent significant events that need attention. For example, the pre-determined criteria may be the severity of the log entries of the data such as warnings, errors, etc. Log entries that are marked with severity levels such as "ERROR" or "WARNING" are separated from less critical "INFO" logs for prioritised processing by the listener services.

[0045] On the other hand, if the listener services determine that the data comes from multiple sources, the listener services perform data tagging as in step 3023. During data tagging, each log entry for the data is labelled with metadata identifying its source in order to maintain data traceability. For example, if logs are received from multiple blockchain nodes, the listener services tag each entry with the node's identifier. Once the data has been tagged, the listener services proceed to filter the data as done in step 3022. Once the data has been filtered, the listener services enrich the data to add or extract additional contextual information from each log entry as in step 3024. In the context of the blockchain system, data enrichment is performed to add transaction contexts, such as timestamps, block confirmation times, and other necessary details. For example, an error log entry labelled 'UNKNOWN' with a message stating "Stream removed" and an error code '2' might indicate an issue with a stream in the blockchain framework setup. To make this log entry contextual, it may be enriched by adding information about specific peers in the blockchain network that encountered the error, a unique identifier for the transaction processed at the time of the error, etc.

[0046] Thereon, the listener services proceed to determine if the data is in a standard format as in step 3025. If the listener services determine that the data is in the standard format, the listener services transmit the data to the unifier service, wherein the unifier service unifies the data that are coming from multiple listener services into a single time-series data format as in step 3026. On the other hand, if the listener services determine that the data is not in a standard format, the listener services parse the data as in step 3027. The data parsing is performed to convert the data that are in formats such as text streams, binary data, or CSV data into a standardised structured format such as JSON. After the data has been parsed, the unifier service proceeds to unify the data into a single time-series data format as in step 3026.

[0047] Reference is now made to FIG. 4 which illustrates a flowchart of the sub-steps for pre-processing the standardised parameter data by the MRP (30) as done in step 303 of the method of FIG. 2. Initially, the MPP (30) receives batches of data that is in the time-series format from the UMC (20). The MPP (30) then proceeds to split the data according to a component’s key as in step 3031 . A component's key refers to a unique identifier paired with a value. In the context of the blockchain system, each node is assigned a unique key, such as a node ID, that tags collected data. The MPP (30) uses these keys to split and pre-process each node's data individually, ensuring organised and efficient data handling through the ‘key-value’ system. Next, the MPP (30) performs the data pre-processing as in step 3032, wherein the data preprocessing includes techniques such as data cleaning, data transformation, data encoding, data aggregation, feature engineering, and data serialisation. Data cleaning is performed to remove or correct invalid data and missing values. Data transformation is performed to normalise the data. Data encoding is performed to convert categorical variables into a numerical format that can be processed by the machine learning model. Data aggregation is performed to combine data from multiple sources and select the most informative features for the machine learning model. Feature engineering is performed to modify existing features or create new features to enhance the model's ability to make accurate predictions. Data deserialisation is performed to convert the data from time-series data into a data frame.

[0048] It is to be understood that the execution of each of the pre-processing techniques is not mandatory. Instead, they may be applied as needed, based on the data's specific characteristics for the purpose of analysis and processing by the machine learning model. For instance, the data cleaning technique may not need to be performed if there are no missing values in the data. Similarly, the data transformation technique may be kept minimal if all data is in numerical format and on the same scale.

[0049] After the data has been pre-processed, the MRP (30) proceeds to merge the data into a single data frame as in step 3033, wherein the data frame is now cleaned, transformed, and appropriately formatted for the training and analysis by the IAM (40).

[0050] Reference is now made to FIG. 5 which illustrates a flowchart of the sub-steps for generating the optimised configuration settings by the IAM (40) as done in step 304 of the method of FIG. 2. Initially, the IAM (40) determines if the method is in its first iteration as in step 3041. If the method is in its first iteration, the agent of the IAM (40) listens to input data from the MPP (30) as in step 3042. In this context, the input data includes the current state and parameter data of the multi-component computing system. The agent then defines the reward policy as in step 3043. The reward policy outlines the strategy or rule that the agent uses to determine the executable actions to perform given the particular state of the multi-component computing system. The reward policy may be defined using algorithms such as random policy, heuristic-based, or derived from prior knowledge. Based on the reward policy, the agent determines the executable actions to perform as in step 3044. For example, in the first iteration, the executable actions include generating and transmitting the optimised configuration settings to the EE (50) for deployment. In this first iteration, the agent of the IAM (40) does not receive any rewards or punishments. Thereon, the sub-step continues to step 305 of the method of FIG. 2, which is to store and coordinate the deployment of the optimised configuration settings by the EE (50).

[0051] On the other hand, if the IAM (40) determines that the method is in its subsequent iteration, the agent of the IAM (40) listens to new input data from the MPP (30) as in step 3045. In this context, the new input data includes the current state and parameter data of the multi-component computing system as well as the outcomes from the previously deployed configuration settings in the multi-component computing system’s environment. The agent of the IAM (40) then evaluates the new input data against the reward policy as in step 3046. During the evaluation, the agent compares current performance of the multi-component computing system when using the deployed configuration settings against baseline data or performance data of previously deployed configuration settings. From the evaluation, the agent then automatically receives a reward or punishment from the management system (100) as in step 3047. For example, if the deployed configuration settings result in a good performance of the multi-component computing system, the agent receives a reward. However, if the configuration settings result in a bad performance of the multicomponent computing system, the agent receives a punishment. Based on the reward or punishment, the agent updates its reward policy as in step 3048. The updated reward policy outlines the next executable actions to be performed by the agent.

[0052] Next, the agent determines the next executable actions to perform as in step 3049. The next executable actions may vary depending on the state of the multicomponent computing system. For example, the agent may retain its current configuration settings if they result in a good performance of the multi-component computing system. Alternatively, the agent may generate and transmit new optimised configuration settings to the EE (50) if improvements to the performance of the multicomponent computing system are needed. As such, the reward policy is continuously refined over multiple iterations as the agent learns from the rewards or punishments it receives. Thereon, the sub-step continues to step 305 of the method of FIG. 2, which is to store and coordinate the deployment of the optimised configuration settings by the EE (50). An example is provided herein to illustrate the scenario of generating the optimised configuration settings by the IAM (40) in the context of the blockchain system. During the first iteration, the IAM (40) receives inputs from the MPP (30) that include parameter data such as transaction throughput, block validation time, and network congestion level from the blockchain system. In this first iteration, the reward policy may be defined to prioritise increasing throughput if the block validation time is below a certain threshold, as this indicates that the blockchain system is able to handle more transactions. The IAM (40) then proceeds to set the reward policy and determines the appropriate executable actions to perform, which includes generating settings to adjust the difficulty of a cryptographic puzzle for block validation to increase transaction processing speed without compromising security.

[0053] Next, the agent of the IAM (40) sends the configuration settings to the EE (50) for deployment. The EE (50) then coordinates the deployment of the configuration settings to the CAs (60) in the blockchain system, wherein the CAs (60) are required to adjust the settings of the configurable components (2) to comply with the reward policy. During this initial iteration, no immediate reward or punishment is received as its outcomes are not yet known.

[0054] In the subsequent iteration, new parameter data and outcomes that reflect changes in the blockchain system’s performance due to the executable actions taken on the reward policy, are collected. The agent then evaluates the performance of the blockchain system by comparing current performance against baseline data or performance data of previously deployed configuration settings. The agent automatically receives a reward or punishment based on the comparison result. For example, if the deployed configuration settings improve the performance of the blockchain system without compromising security, for instance, faster transactions without an increase in failed or fraudulent transactions, the agent receives a positive reward. Conversely, if the performance of the blockchain system degrades or security issues arise, the agent receives a punishment.

[0055] Over the course of multiple iterations, the agent of the IAM (40) updates its policy based on the rewards or punishments it receives. For instance, if increasing transaction throughput leads to network congestion, the agent learns to modify its approach, possibly by not increasing throughput as much under similar conditions in the future. The IAM (40) continuously adjusts its policy over multiple iterations, with the goal of maximising the cumulative rewards.

[0056] FIG. 6 illustrates a flowchart of the sub-steps for coordinating the deployment of the optimised configuration settings by the EE (50) as done in step 305 of the method of FIG. 2. Initially, when the EE (50) receives the optimised configuration settings from the IAM (40), the EE (50) proceeds to perform data segmentation as in step 3051 . The data segmentation is performed to splice the bulk configuration data into smaller, manageable segments.

[0057] Next, the EE (50) performs data mapping to map the segmented configuration data to the respective CAs (60) as in step 3052. To perform the data mapping, the EE (50) initially prepares the data for transmission. For example, the EE (50) converts the data that is in JSON format to a tabular format, whereby each row includes a unique key value to map each segmented configuration data to its respective CAs (60). The EE (50) also sets up the necessary access credentials to send the latest configuration settings to the respective CAs (60). For example, if the data has to be transmitted using a Secure Shell or SSH method, a username and password for the CAs (60) have to be provided. The EE (50) then proceeds to transmit the optimised configuration settings to the respective CAs (60) via an application programming interface or API endpoint.

[0058] Reference is now made to FIG. 7 which illustrates a flowchart for the sub-steps for implementing the optimised configuration settings by the respective CAs (60) as done in step 306 of the method of FIG. 2. Initially, when the respective CAs (60) receive the optimised configuration settings from the EE (50) via the API endpoint, each of the CAs (60) applies these configuration settings by updating or changing the current configuration settings of the respective configurable components (2) as in step 3061.

[0059] Once the CAs (60) have applied the configuration changes, the CAs (60) periodically monitor for the next scheduled update at pre-determined time intervals as in step 3062. At the next scheduled update, the CAs (60) check if they receive the instruction from the EE (50) to perform a new configuration settings update as in step 3063. If the CAs (60) receive the instruction from the EE (50) to perform a new configuration settings update, steps 3061 to 3063 are repeated. On the other hand, if the CAs (60) do not receive the instruction from the EE (50) to perform a new configuration settings update, the sub-steps end.

[0060] While embodiments of the invention have been illustrated and described, it is not intended that these embodiments illustrate and describe all possible forms of the invention. Rather, the words used in the specifications are words of description rather than limitation and various changes may be made without departing from the scope of the invention.

Claims

CLAIMS1. A management system (100) for controlling a dynamic system configuration comprises: a) a plurality of data collection agents, DCAs (10) configured to collect a plurality of parameter data from a plurality of configurable components (2), characterised in that the management system (100) further comprises: b) a unified metrics collector, UMC (20) configured to transform and unify the plurality of parameter data into a standardised data format, wherein the UMC (20) is connected to the DCAs (10); c) a metrics pre-processor, MPP (30) configured to perform data preprocessing on the plurality of standardised parameter data, wherein the MPP (30) is connected to the UMC (20); and d) an intelligent analysis module, IAM (40) configured to analyse the plurality of pre-processed parameter data to generate optimised configuration settings using a machine learning model, wherein the IAM (40) is connected to the MPP (30).

2. The management system (100) as claimed in claim 1 , wherein the management system (100) further comprises an execution engine, EE (50) configured to coordinate deployment of the optimised configuration settings, and wherein the EE (50) is connected to the IAM (40).

3. The management system (100) as claimed in claim 2, wherein the management system (100) further comprises a plurality of configurator agents, CAs (60) configured to implement the optimised configuration settings, and wherein the plurality of CAs (60) is connected to the EE (50).

4. A method for controlling a dynamic system configuration is characterised by the steps of: a) collecting a plurality of parameter data from a plurality of configurable components (2) by a plurality of data collection agents, DCAs (10); b) transforming and unifying the plurality of parameter data into a standardised data format by a unified metrics collector, UMC (20); c) pre-processing the plurality of standardised parameter data by a metrics pre-processor, MPP (30);d) analysing the plurality of pre-processed parameter data using a machine learning model to generate optimised configuration settings by an intelligent analysis module, IAM (40); e) coordinating the deployment of the optimised configuration settings by an execution engine, EE (50); and f) implementing the optimised configuration settings by a plurality of configurator agents, CAs (60).

5. The method as claimed in claim 4, wherein the step of transforming and unifying the plurality of parameter data by the UMC (20) further comprises: a) determining whether the data come from multiple sources; b) performing data tagging if the data comes from multiple sources; c) filtering the data based on pre-determined criteria; d) enriching the data to add or extract additional contextual information; e) determining if the data is in a standard format; f) parsing the data if the data is not in a standard format; and g) unifying the data into a single time-series data format.

6. The method as claimed in claim 4, wherein the step of pre-processing the plurality of standardised parameter data by the MPP (30) further comprises: a) splitting the data according to a component’s key; b) performing data preprocessing; and c) merging the data into a single data frame.

7. The method as claimed in claim 6, wherein the step of performing data preprocessing includes performing either data cleaning, data transformation, data encoding, data aggregation, feature engineering, data serialisation, or any combination thereof.

8. The method as claimed in claim 4, wherein the step of analysing the plurality of pre-processed parameter data using the machine learning model to generate the optimised configuration settings by the IAM (40) further comprises: a) determining if the method is in its first iteration; b) if the method is in its first iteration, listening to input data from the MPP (30); c) defining a reward policy; andd) determining executable actions to perform.

9. The method as claimed in claim 8, wherein if the method is in its subsequent iteration, the step comprises: a) listening to new input data from the MPP (30); b) evaluating the new input data against the reward policy; c) receiving a reward or punishment based on the performance of the optimised configuration settings; d) updating the reward policy; and e) determining the next executable actions to perform.

10. The method as claimed in claim 4, wherein the step of coordinating the deployment of the optimised configuration settings by the EE (50) further comprises: a) performing data segmentation; and b) performing data mapping.1 1 . The method as claimed in claim 4, wherein the step of implementing the optimised configuration settings by the CAs (60) further comprises: a) applying the optimised configuration settings by updating the current configuration settings of the respective configurable components (2); b) monitoring for the next scheduled update at pre-determined time intervals; c) checking if an instruction from the EE (50) to perform a new configuration settings update is received; and d) repeating steps (a) to (c) if the instruction from the EE (50) to perform a new configuration settings update is received.

Images