Intelligent management method and system based on server cluster

Abstract

The invention relates to an intelligent management method and system based on a server cluster, and the method comprises the steps: a load balancing module employs a preset mode, and detects the health condition of a server node at preset time intervals; the node monitoring and alarming module monitors the resource use condition of each server node in real time; the intelligent fault detection module detects the resource use condition of the server node based on a pre-trained fault prediction model and outputs a fault prediction result; the resource management module predicts historical resource use data based on a time sequence model and actively adjusts resources; and the background management module dynamically displays a load state and a resource use condition, records a log and processes a fault. The intelligent management system based on the server cluster successfully predicts most faults and automatically repairs the faults, and the availability of the system is improved.

Description

Technical Field

[0001] The present invention relates to the field of server cluster management, and in particular to an intelligent management method and system based on server clusters. Background Art

[0002] As digital transformation deepens, enterprises' demand for computing resources continues to grow, and cloud computing and big data technologies have also been widely used. Today, various applications and services are highly dependent on the support of server clusters, such as e-commerce platforms, online education, and banking systems. These applications usually deploy large-scale server clusters in data centers or cloud environments to provide services with high reliability, low latency, and high availability. However, as the number of servers increases, the difficulty of cluster management increases significantly, and the technical challenges involved mainly include dynamic resource allocation, load balancing, fault detection and fault tolerance, and energy efficiency management.

[0003] At the same time, operation and maintenance automation has gradually become an industry trend. Traditional manual management and scripted operations are difficult to meet the management needs of large-scale server clusters. This has prompted the industry to introduce more intelligent technologies, such as machine learning, data analysis, and automated operation and maintenance tools, to improve the efficiency and accuracy of cluster management. Intelligent management of server clusters aims to maximize the stability and resource utilization of server clusters, reduce management costs, and optimize user experience through real-time monitoring, intelligent alarms, and automated processing.

[0004] Current server cluster management technology has developed many solutions, including monitoring and alarm systems, load balancers, resource management tools, etc. The most commonly used monitoring tools such as Nagios, Zabbix and Prometheus can monitor the consumption of various server resources (such as CPU, memory, disk and network) in real time. When the monitoring indicators reach the preset threshold, the alarm is triggered to notify the operation and maintenance personnel. These tools mostly rely on manual processing of alarm information, which requires manual judgment and intervention by the operation and maintenance personnel.

[0005] In terms of load balancing, traditional load balancers such as Nginx and HAProxy distribute requests to different server nodes through algorithms (such as polling, minimum number of connections, and weighted polling) to disperse the load pressure. However, these tools usually lack automated intelligent scheduling and cannot perceive server status changes in real time, resulting in unreasonable distribution and performance bottlenecks in scenarios with sudden load increases.

[0006] Existing resource management tools (such as Kubernetes and Mesos) can realize dynamic resource allocation in containerized environments, but their configuration is complex, management overhead is high, and they are suitable for specific cloud-native scenarios. They are not adaptable enough to traditional physical server clusters or virtual machine clusters. Therefore, in non-cloud-native environments, traditional server cluster management still faces challenges in terms of efficiency, intelligence, and automation. Summary of the invention

[0007] The present invention provides an intelligent management method and system based on a server cluster, aiming to solve at least one of the technical problems existing in the prior art.

[0008] The technical solution of the present invention is an intelligent management method based on server clusters, which is applied to an intelligent management system based on server clusters. The intelligent management system based on server clusters includes: a load balancing module, which periodically sends HTTP requests to server nodes through a combination of one or more of a polling algorithm, a minimum connection number algorithm, and a weighted polling algorithm, checks the health status of server cluster nodes, and dynamically adjusts strategies based on health check results; a node monitoring and alarm module, which is used to monitor the resource usage of each server node in real time and trigger an alarm when the set threshold is exceeded; an intelligent A fault detection module, wherein the intelligent fault detection module predicts faults of server nodes through machine learning algorithms based on historical data and real-time data, and provides an automatic repair function; a resource management module, wherein the resource management module dynamically adjusts cluster resources of server nodes by predicting resource requirements to ensure that the cluster of server nodes can provide sufficient resources during peak loads, and reduces the load of the database in the server nodes through cache optimization; a background management module, wherein the load balancing module, the node monitoring and alarm module, the intelligent fault detection module and the resource management module are respectively connected to the background management module, and the intelligent management method based on server clusters comprises the following steps:

[0009] S100, the load balancing module detects the health status of the server nodes at preset time intervals in a preset manner, and actively adjusts the load balancing strategy according to the health status of the server nodes;

[0010] S200, the node monitoring and alarm module monitors the resource usage of each server node in real time and triggers an alarm when it exceeds a set threshold;

[0011] S300, the intelligent fault detection module detects the resource usage of the server node based on the pre-trained fault prediction model and outputs the fault prediction result. When the fault prediction model predicts a node failure, the repair script is automatically executed to repair the fault. If the repair fails, an alarm is triggered;

[0012] S400, the resource management module predicts historical resource usage data based on a time series model and actively adjusts resources to ensure that sufficient resources are available during peak loads;

[0013] S500, the background management module dynamically displays the load status and resource usage, records logs and handles faults.

[0014] Further, the step S100 includes the following steps:

[0015] S110, the load balancing module uses a polling algorithm by default to make timing requests, including sending one or more combinations of HTTP requests, Ping commands and custom health check endpoints to the server nodes at regular intervals, obtaining the response time of the server nodes, and judging the health status of the node servers;

[0016] S120, if it is found that the response time of a server node exceeds the preset response time, the real-time load of the central processing unit CPU and memory of the node is determined through the real-time node monitoring data;

[0017] S130, if the node load is too high, the load balancing module will dynamically adjust the load balancing strategy, switching from the round-robin algorithm to the minimum connection number algorithm or the weighted polling algorithm;

[0018] S140, the load balancing module allocates server node tasks based on a minimum connection number algorithm or a weighted round-robin algorithm to alleviate the situation where the node load is too high;

[0019] S150: When the load of the node with excessive load drops to a preset range, the load balancing module switches back to allocating server node tasks based on the polling algorithm.

[0020] Furthermore, the polling algorithm distributes requests to each server node in sequence, and the pseudo code is:

[0021] node = nodes[index % len(nodes)]

[0022] index += 1

[0023] The minimum connection number algorithm calculates the number of connections of each server node in real time and distributes the request to the node with the least number of connections. The pseudo code is:

[0024] node = min(nodes, key=node.connections)

[0025] The weighted polling algorithm assigns weights according to the CPU and memory performance of the server node and distributes requests to high-weight nodes. The formula is:

[0026]

[0027] Among them, node represents the node, index represents the sequence number of the node, and len represents the number of nodes. represents the weight of node i, node.connections and Indicates the current number of connections.

[0028] Further, the step S200 includes the following steps:

[0029] S210, based on the monitoring tool Prometheus, regularly collect monitoring data of key indicators from the data collector Node Exporter preset on each server node, wherein the monitoring data at least includes CPU usage, memory usage, disk space usage and network delay;

[0030] S220, sending the monitoring data to the API server based on the HTTP protocol, and the API server storing the monitoring data in the MongoDB database or the search server Elasticsearch;

[0031] S230, respectively set alarm thresholds for CPU usage, memory usage, disk space usage, and network latency. When the monitoring data exceeds the alarm threshold, send an alarm message via Twilio or SendGrid and display it on the management panel.

[0032] S240: Merge, deduplicate and suppress the alarm information to avoid duplicate alarms.

[0033] Further, the step S300 includes the following steps:

[0034] S310, using a decision tree or random forest classification algorithm to train and obtain a fault prediction model;

[0035] S320, based on the monitoring tool Prometheus, collects historical data of server nodes, cleans and standardizes the historical data;

[0036] S330, inputting the CPU usage, memory usage, disk space usage and network delay of the server node into the trained fault prediction model, and the fault prediction model outputs the fault prediction result;

[0037] S340: When the fault prediction model predicts a fault, a repair script is automatically executed to perform repair. If the repair fails, an alarm notification is triggered. The repair script at least includes releasing server node memory and restarting the service.

[0038] Further, the step S400 includes the following steps:

[0039] S410, use the difference integrated moving average autoregressive model ARIMA or the long short-term memory network LSTM time series model to predict the historical node resource usage data and predict future resource demand;

[0040] S420, Dynamically adjust server cluster resources based on Kubernetes or Docker Swarm;

[0041] S430. For frequently accessed data, use the Redis database or the distributed high-speed cache system Memcached to optimize the cache, thereby reducing access delays and the burden on the database.

[0042] Further, the step S500 includes the following steps:

[0043] S510, based on Grafana or Kibana, the management panel of the background management module visually displays the monitoring data, load status and resource usage of each node;

[0044] S520. Store all fault log data in the search server Elasticsearch to facilitate quick query and fault tracing.

[0045] S530. The user views the alarm information through the background management module and performs fault handling and resource adjustment operations.

[0046] Furthermore, the present invention also proposes an intelligent management system based on a server cluster, which is used to execute the intelligent management method based on a server cluster. The intelligent management system based on a server cluster is connected to a server cluster, and the server cluster includes a plurality of server nodes. The intelligent management system based on a server cluster includes:

[0047] A load balancing module, which periodically sends HTTP requests to server nodes through a combination of one or more of a polling algorithm, a minimum connection number algorithm, and a weighted polling algorithm, checks the health status of server cluster nodes, and dynamically adjusts strategies based on health check results;

[0048] A node monitoring and alarm module, which is used to monitor the resource usage of each server node in real time and trigger an alarm when the set threshold is exceeded;

[0049] Intelligent fault detection module, which predicts server node faults based on historical data and real-time data through machine learning algorithms and provides automatic repair functions;

[0050] A resource management module, which dynamically adjusts the cluster resources of the server nodes by predicting resource requirements, ensuring that the cluster of server nodes can provide sufficient resources during peak loads, and reduces the load of the database in the server nodes through cache optimization;

[0051] The backend management module, the load balancing module, the node monitoring and alarm module, the intelligent fault detection module and the resource management module are respectively connected to the backend management module.

[0052] Further, in the node monitoring and alarm module, the resource usage of the server node includes at least the usage of the CPU, memory, and disk space of the server node;

[0053] In the intelligent fault detection module, the machine learning algorithm includes at least a decision tree and a random forest;

[0054] The background management module displays the monitoring data, load status and resource usage of each server node through Grafana or Kibana, and stores and maintains fault data through Elasticsearch.

[0055] Furthermore, the present invention also proposes a computer-readable storage medium on which program instructions are stored. When the program instructions are executed by a processor, the intelligent management method based on a server cluster is implemented.

[0056] The beneficial effects of the present invention are:

[0057] The intelligent management method and system based on server clusters have significantly improved the performance and stability of the system through the collaborative work of load balancing module, node monitoring and alarm module, intelligent fault detection module, resource management module and background management module. Load balancing and resource scheduling effectively avoid node overload problems and ensure efficient operation of the system. The intelligent management system based on server clusters successfully predicts most faults and automatically repairs them, improving system availability. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 The figure is an overall flow chart of the intelligent management method based on server clusters.

[0059] Figure 2 The flowchart of the intelligent management method based on server cluster is shown in FIG. DETAILED DESCRIPTION

[0060] The following will be combined with the embodiments and drawings to clearly and completely describe the concept, specific structure and technical effects of the present invention, so as to fully understand the purpose, scheme and effect of the present invention. It should be noted that the embodiments and features in the embodiments of this application can be combined with each other without conflict.

[0061] It should be noted that, unless otherwise specified, when a feature is referred to as being "fixed" or "connected" to another feature, it may be directly fixed or connected to the other feature, or it may be indirectly fixed or connected to the other feature. In addition, the descriptions of up, down, left, right, top, bottom, etc. used in the present invention are only relative to the relative positional relationship of the components of the present invention in the drawings.

[0062] In addition, unless otherwise defined, all technical and scientific terms used herein have the same meaning as those generally understood by those skilled in the art. The terms used in this specification are only for describing specific embodiments, not for limiting the present invention. The term "and / or" used herein includes any combination of one or more related listed items.

[0063] It should be understood that, although the terms first, second, third, etc. may be used to describe various elements in the present disclosure, these elements should not be limited to these terms. These terms are only used to distinguish elements of the same type from each other. For example, without departing from the scope of the present disclosure, the first element may also be referred to as the second element, and similarly, the second element may also be referred to as the first element.

[0064] Reference Figure 1 to Figure 2In some embodiments, the technical solution of the present invention is an intelligent management method based on server clusters, which is applied to an intelligent management system based on server clusters. The intelligent management system based on server clusters includes: a load balancing module, which periodically sends HTTP requests to server nodes through a combination of one or more of a polling algorithm, a minimum connection number algorithm, and a weighted polling algorithm, checks the health status of server cluster nodes, and dynamically adjusts strategies based on health check results; a node monitoring and alarm module, which is used to monitor the resource usage of each server node in real time, and trigger an alarm when the set threshold is exceeded. an intelligent fault detection module, which predicts faults of server nodes based on historical data and real-time data through machine learning algorithms and provides automatic repair functions; a resource management module, which dynamically adjusts cluster resources of server nodes by predicting resource requirements to ensure that the cluster of server nodes can provide sufficient resources during peak loads and reduces the load of databases in server nodes through cache optimization; a background management module, wherein the load balancing module, the node monitoring and alarm module, the intelligent fault detection module and the resource management module are connected to the background management module respectively, and the intelligent management method based on server clusters comprises the following steps:

[0065] S100, the load balancing module detects the health status of the server nodes at preset time intervals in a preset manner, and actively adjusts the load balancing strategy according to the health status of the server nodes;

[0066] S200, the node monitoring and alarm module monitors the resource usage of each server node in real time and triggers an alarm when it exceeds a set threshold;

[0067] S300, the intelligent fault detection module detects the resource usage of the server node based on the pre-trained fault prediction model and outputs the fault prediction result. When the fault prediction model predicts a node failure, the repair script is automatically executed to repair the fault. If the repair fails, an alarm is triggered;

[0068] S400, the resource management module predicts historical resource usage data based on a time series model and actively adjusts resources to ensure that sufficient resources are available during peak loads;

[0069] S500, the background management module dynamically displays the load status and resource usage, records logs and handles faults.

[0070] The beneficial effects of the present invention are:

[0071] The intelligent management method and system based on server clusters have significantly improved the performance and stability of the system through the collaborative work of load balancing module, node monitoring and alarm module, intelligent fault detection module, resource management module and background management module. Load balancing and resource scheduling effectively avoid node overload problems and ensure efficient operation of the system. The intelligent management system based on server clusters successfully predicts most faults and automatically repairs them, improving system availability.

[0072] The disadvantages of the existing technology include:

[0073] (1) High reliance on manual labor and low degree of automation: Although existing monitoring and management systems (such as Nagios, Zabbix, etc.) can monitor server status and trigger alarms, most alarm processing processes still rely on manual judgment and processing by operation and maintenance personnel, and cannot achieve automatic repair of faults. This reliance on manual operations is time-consuming and prone to human errors, and cannot meet the needs of automated management of large-scale server clusters.

[0074] (2) Lack of intelligent fault detection and diagnosis: Traditional monitoring systems usually use simple thresholds to determine whether to trigger an alarm, and fail to intelligently identify complex fault modes. For example, in load balancing and server resource management, existing technologies usually rely on preset thresholds and static configurations, and cannot dynamically adapt to real-time changes in server status, and are prone to poor performance under sudden loads or faults.

[0075] (3) Static load balancing and inability to be dynamically optimized: Traditional load balancers (such as Nginx and HAProxy) use static allocation algorithms (such as polling, minimum number of connections, etc.), which make it difficult to dynamically adjust according to the current operating status of the server. This can lead to problems such as uneven load or slow system response when the load suddenly increases or some servers fail.

[0076] (4) Inflexible resource management and allocation: Existing resource management tools (such as Kubernetes and Mesos) are suitable for containerized cloud-native environments, with complex configuration and low flexibility. Their application in non-cloud-native environments is limited, and they cannot effectively predict and dynamically adjust the resource requirements of traditional server clusters, resulting in waste or shortage of resources.

[0077] (5) Poor real-time monitoring and alarming: In traditional monitoring systems, there is a certain delay in data collection, analysis and alarming, and it is impossible to achieve true real-time monitoring. In the event of an abnormal server status, the alarm information may not be quickly conveyed to the operation and maintenance personnel, affecting the timely handling of the fault.

[0078] Compared with the prior art, the intelligent management method based on the server cluster of the present invention aims to improve the operation efficiency, stability and resource utilization of the server cluster through automated, intelligent and dynamic management methods. Realize highly automated server cluster management: The present invention reduces the reliance on manual operation through automated monitoring, intelligent fault detection and diagnosis. When the system detects a fault, it can automatically trigger the repair process to ensure the efficient and stable operation of the server cluster. Improve the intelligence and diagnostic efficiency of fault detection: The fault detection model is trained using a machine learning algorithm, which can identify complex fault modes in the server cluster and no longer rely on simple threshold judgments. At the same time, when the system detects an abnormal state, it can judge the fault type in real time, take appropriate measures quickly, and improve the accuracy and response speed of fault diagnosis. Realize dynamic optimization of load balancing: The load balancing module of the present invention can perceive the operating status of each server node in real time, and dynamically adjust the request allocation strategy according to the load situation to ensure that the load in the cluster is evenly distributed, optimize the response speed, and avoid performance bottlenecks. Flexible and efficient resource management and allocation: Predict resource requirements through machine learning algorithms such as time series analysis to achieve dynamic resource allocation. During peak hours, the system will increase resource supply in advance, and automatically reduce resource usage during off-peak hours, maximizing resource utilization and avoiding resource waste. Real-time monitoring and rapid alarm response: Based on real-time data collection of lightweight proxy programs and API server design of Flask framework, the present invention can achieve faster status monitoring and alarm mechanism, ensuring that when the server status is abnormal, the operation and maintenance team can be notified in real time, effectively improving the response speed of the system.

[0079] Specifically, the present invention reduces the reliance on manual intervention and improves the management efficiency of the server cluster through automated monitoring, intelligent alarm, load balancing and resource management functions. Automated data collection and analysis can continuously monitor the performance indicators of each server node. When an abnormality is detected, the system will automatically trigger an alarm to promptly remind the operation and maintenance personnel to handle it. A fault detection model trained by a machine learning algorithm is used to quickly locate the fault node and diagnose the possible fault type through automated data analysis and pattern recognition. After the system detects the risk of a fault, the system can trigger an automated repair script for rapid recovery and record the fault information for subsequent analysis and optimization of the fault detection strategy. The load balancing module monitors the load status of each node in real time, and automatically adjusts the allocation of requests according to the load balancing algorithm (such as polling method, minimum connection method) to ensure balanced request allocation. In addition, the system also uses a resource prediction model to analyze and predict resource requirements during peak periods in advance, and dynamically allocate resources to improve overall resource utilization and system stability. A dynamic resource management module and a configuration management module are provided. When a new node is added, the system automatically obtains its hardware and performance information, and automatically configures the resource allocation strategy according to the current cluster load status. At the same time, through automated configuration management, the system can automatically update the configuration files of each node, reducing the workload of manual configuration. An API server based on the Flask framework is introduced to realize real-time data collection and transmission on each node through a lightweight agent. Once the data exceeds the preset threshold, the system will immediately trigger an alarm and send a real-time notification to the operation and maintenance team through Webhook to ensure that fault information is obtained in the first time and improve the response speed. Machine learning algorithms such as time series analysis are used to predict future resource requirements, adjust resource allocation strategies in advance, and ensure that the system can adapt to resource requirements in different scenarios. For example, resource allocation is automatically increased before peak periods, and resource usage is reduced during off-peak periods, ensuring the flexibility of resource allocation and the operating efficiency of the system.

[0080] Further, the step S100 includes the following steps:

[0081] S110, the load balancing module uses a polling algorithm by default to make timing requests, including sending one or more combinations of HTTP requests, Ping commands and custom health check endpoints to the server nodes at regular intervals, obtaining the response time of the server nodes, and judging the health status of the node servers;

[0082] S120, if it is found that the response time of a server node exceeds the preset response time, the real-time load of the central processing unit CPU and memory of the node is determined through the real-time node monitoring data;

[0083] S130, if the node load is too high, the load balancing module will dynamically adjust the load balancing strategy, switching from the round-robin algorithm to the minimum connection number algorithm or the weighted polling algorithm;

[0084] S140, the load balancing module allocates server node tasks based on a minimum connection number algorithm or a weighted round-robin algorithm to alleviate the situation where the node load is too high;

[0085] S150: When the load of the node with excessive load drops to a preset range, the load balancing module switches back to allocating server node tasks based on the polling algorithm.

[0086] Specifically, Nginx and HAProxy are load balancing tools that mainly implement load distribution through the following algorithms:

[0087] Polling algorithm: distributes requests one by one in order, which is suitable for clusters with relatively uniform load balancing. It distributes requests to each node in order. It distributes requests in turn, maintains an index during calculation, and distributes each request to the next node. After reaching the last node, it starts from the beginning. The polling algorithm maintains a request index, and distributes each request to the next node until all nodes are polled, and then starts from the beginning:

[0088] nodes = ["node1", "node2", "node3"]

[0089] index = 0

[0090] def round_robin():

[0091] global index

[0092] node = nodes[index % len(nodes)]

[0093] index += 1

[0094] return node

[0095] Minimum connection number algorithm: Prioritize the node with the least number of connections to allocate requests, which is suitable for dynamic load environments. Each node maintains a connection number counter. The system checks the number of connections of each node in real time and allocates requests to the node with the least number of connections. Track the number of connections of each node in real time and allocate requests to the node with the least number of connections:

[0096] nodes = [{"name": "node1", "connections": 10}, {"name": "node2", "connections": 5}, {"name": "node3", "connections": 8}]

[0097] def min_connections():

[0098] return min(nodes, key=lambda node: node['connections'])

[0099] node_to_assign = min_connections()

[0100] print(f"Request assigned to {node_to_assign['name']}")

[0101] Weighted round-robin algorithm: allocates requests based on node weights, which is suitable for clusters with large performance differences between different servers. Set weights based on node performance (such as CPU, memory, etc.), and nodes with stronger performance are allocated more requests. Nodes are polled based on weights, and nodes with higher weights are allocated more requests.

[0102] nodes = [{"name": "node1", "weight": 2}, {"name": "node2", "weight":1}, {"name": "node3", "weight": 1}]

[0103] total_weight = sum(node['weight'] for node in nodes)

[0104] choice = random.randint(0, total_weight)

[0105] current_weight = 0

[0106] for node in nodes:

[0107] current_weight += node['weight']

[0108] if current_weight >= choice:

[0109] print(f"Request assigned to {node['name']}")

[0110] break

[0111] Furthermore, the polling algorithm distributes requests to each server node in sequence, and the pseudo code is:

[0112] node = nodes[index % len(nodes)]

[0113] index += 1

[0114] The minimum connection number algorithm calculates the number of connections of each server node in real time and distributes the request to the node with the least number of connections. The pseudo code is:

[0115] node = min(nodes, key=node.connections)

[0116] The weighted polling algorithm assigns weights according to the CPU and memory performance of the server node and distributes requests to high-weight nodes. The formula is:

[0117]

[0118] Among them, node represents the node, index represents the sequence number of the node, and len represents the number of nodes. represents the weight of node i, node.connections and Indicates the current number of connections.

[0119] The step S100 also includes a periodic health check mechanism and a dynamic adjustment strategy.

[0120] The periodic health check mechanism detects the health status of nodes through timed requests (such as Ping once per second). If the response time of the node exceeds the threshold (for example, more than 500ms), it is marked as unavailable. The health check method is to use HTTP requests, Ping commands or custom health check endpoints to regularly obtain node health data. The dynamic adjustment strategy is that the system should adjust the load balancing strategy based on real-time monitoring data (such as CPU usage, memory usage, etc.). When a node is overloaded, the system automatically switches to the minimum connection number algorithm or weighted polling algorithm to avoid overload.

[0121] Dynamically adjust the load balancing strategy. Regularly collect node performance data (such as CPU usage, memory usage, etc.) and switch the load balancing algorithm according to load changes. The load situation can be displayed on the system panel, allowing administrators to adjust it manually.

[0122] In a specific embodiment, the load balancing algorithm is implemented as follows:

[0123] Polling algorithm:

[0124] nodes = ["node1", "node2", "node3"]

[0125] index = 0

[0126] def round_robin():

[0127] global index

[0128] node = nodes[index % len(nodes)]

[0129] index += 1

[0130] return node

[0131] Minimum connection number algorithm:

[0132] nodes = [

[0133] {"name": "node1", "connections": 10},

[0134] {"name": "node2", "connections": 5},

[0135] {"name": "node3", "connections": 8} ]

[0137] def min_connections():

[0138] return min(nodes, key=lambda node: node['connections'])

[0139] node_to_assign = min_connections()

[0140] print(f"Assigned to node: {node_to_assign['name']}")

[0141] Further, the step S200 includes the following steps:

[0142] S210, based on the monitoring tool Prometheus, regularly collect monitoring data of key indicators from the data collector Node Exporter preset on each server node, wherein the monitoring data at least includes CPU usage, memory usage, disk space usage and network delay;

[0143] S220, sending the monitoring data to the API server based on the HTTP protocol, and the API server storing the monitoring data in the MongoDB database or the search server Elasticsearch;

[0144] S230, respectively set alarm thresholds for CPU usage, memory usage, disk space usage, and network latency. When the monitoring data exceeds the alarm threshold, send an alarm message via Twilio or SendGrid and display it on the management panel.

[0145] S240: Merge, deduplicate and suppress the alarm information to avoid duplicate alarms.

[0146] Specifically, Prometheus is used as a monitoring tool to regularly collect key indicators (such as CPU usage, memory, disk space, network latency, etc.) from each node. Node Exporter is deployed on each node as a data collector for Prometheus. It regularly collects system performance data and sends the collected monitoring data to the API server through the HTTP protocol. The API server stores the data in MongoDB or Elasticsearch.

[0147] Deploy a data collection agent (such as Prometheus) on each node to collect the following data at a certain frequency:

[0148] CPU usage: Use top or psutil library to calculate CPU usage:

[0149]

[0150] Memory usage: Read system memory information, the calculation formula is:

[0151]

[0152] Disk Space and I / O Monitoring: Read system disk usage and I / O status, calculate disk space utilization and I / O latency.

[0153] Data transmission and storage: The data is sent to the API server via HTTP protocol, and the collected data is stored using MongoDB database for subsequent analysis.

[0154] In a specific embodiment, the alarm module sets thresholds, such as triggering an alarm when the CPU usage exceeds 90%, and triggering an alarm when the memory usage exceeds 80%. The alarm information is sent to the operation and maintenance personnel through Twilio or SendGrid. The alarm strategy includes deduplication and suppression. When multiple alarms belong to the same problem, duplicate alarms should be avoided. At the same time, an alarm merging mechanism is designed to ensure that it does not cause too much interference to the operation and maintenance personnel.

[0155] The implementation steps of the node monitoring and alarm module are as follows:

[0156] (1) Data collection and transmission: Deploy Prometheus Node Exporter to collect node data, and configure the Prometheus collection interval and target node:

[0157] scrape_configs:

[0158] - job_name: 'node'

[0159] static_configs:

[0160] - targets: ['node1:9100', 'node2:9100']

[0161] (2) The API server receives and stores data, uses Flask to build the API service, and stores the monitoring data in MongoDB

[0162] from flask import Flask, request

[0163] from pymongo import MongoClient

[0164] app = Flask(__name__)

[0165] client = MongoClient('mongodb: / / localhost:27017 / ')

[0166] db = client['metrics_db']

[0167] @app.route(' / metrics', methods=['POST'])

[0168] def store_metrics():

[0169] data = request.json

[0170] db.metrics.insert_one(data)

[0171] return 'Metrics stored', 200

[0172] (3) The alarm module sets a threshold and triggers an alarm when the CPU usage exceeds 90%:

[0173] from twilio.rest import Client

[0174] def send_alert(message):

[0175] client = Client("your_account_sid", "your_auth_token")

[0176] client.messages.create(

[0177] body=message,

[0178] from_='+1234567890',

[0179] to='+0987654321' )

[0181] (4) Alarm management and display: Alarms should be sent through Twilio or SendGrid and displayed on the management panel for operation and maintenance personnel to view.

[0182] In a specific embodiment, the node monitoring and alarm system is implemented as follows:

[0183] Collect CPU usage and trigger an alarm:

[0184] cpu_usage = 92 # Get the CPU usage

[0185] CPU_THRESHOLD = 90

[0186] if cpu_usage > CPU_THRESHOLD:

[0187] from twilio.rest import Client

[0188] client = Client("your_account_sid", "your_auth_token")

[0189] client.messages.create(

[0190] body=f"Warning: CPU usage has reached {cpu_usage}%",

[0191] from_="+1234567890", # Send number

[0192] to="+0987654321" # Receiving number )

[0194] Further, the step S300 includes the following steps:

[0195] S310, using a decision tree or random forest classification algorithm to train and obtain a fault prediction model;

[0196] S320, based on the monitoring tool Prometheus, collects historical data of server nodes, cleans and standardizes the historical data;

[0197] S330, inputting the CPU usage, memory usage, disk space usage and network delay of the server node into the trained fault prediction model, and the fault prediction model outputs the fault prediction result;

[0198] S340: When the fault prediction model predicts a fault, a repair script is automatically executed to perform repair. If the repair fails, an alarm notification is triggered. The repair script at least includes releasing server node memory and restarting the service.

[0199] The fault prediction model includes data collection and preprocessing: collecting performance data from each node (such as CPU usage, memory usage, disk I / O, etc.). Data preprocessing steps include data cleaning, missing value filling, outlier detection, and data standardization to ensure that the data is suitable for subsequent model training.

[0200] Feature engineering and data standardization: Extract features from data, which may include time series features (such as sliding average), statistical features (such as variance, kurtosis), etc. Data standardization ensures that different features are within the same scale range to avoid certain features dominating the model training.

[0201] Training fault detection model: The fault detection model is trained using machine learning algorithms such as decision trees, random forests, etc. The training data includes data of normal and fault states, and the model learns to distinguish between these states.

[0202] Real-time data input and fault prediction: Input real-time monitoring data into the trained model to predict whether the node has a risk of failure.

[0203] Fault prediction results: Based on the fault prediction results output by the model, the system decides whether to perform automatic repair or send an alarm notification.

[0204] Automatic repair and alarm: If a fault is detected, the system will automatically take repair measures (such as freeing up memory and restarting services). If the automatic repair fails, the system will trigger an alarm and notify the operation and maintenance personnel via SMS or email.

[0205] Specifically, historical data of nodes is collected from Prometheus, and data preprocessing is performed by cleaning and standardization to ensure that the data can be used as input for model training. A machine learning model is selected, and classification algorithms such as decision trees or random forests are used to train the fault prediction model. The input of the model is the performance indicators of the node (such as CPU usage, memory usage, etc.), and the output is the fault prediction result.

[0206] Data preprocessing: Obtain historical data from the node monitoring system, including CPU usage, memory usage, network latency, etc. Clean and standardize the data.

[0207] Model training: Decision Tree: Select appropriate features (such as CPU usage, memory usage, network latency) and use historical fault data to train the decision tree model.

[0208] Random Forest: Build multiple decision trees, vote on the results of each tree, and output the fault prediction results. The algorithm formula is as follows:

[0209] Where N is the number of decision trees, X is the input data, Represents the prediction result of the i-th tree.

[0210] Real-time fault detection: Real-time monitoring data is input into the model, and the model output predicts the risk of faults. When high risk is detected, fault repair operations are automatically performed (such as freeing up memory, restarting services, etc.).

[0211] Automatic repair and recording: The system automatically performs fault repair operations and records repair logs to facilitate subsequent analysis and optimization.

[0212] The node's operating data is input into the trained fault prediction model in real time to determine whether the node has failed.

[0213] When the fault prediction model predicts a fault, the repair script is automatically executed (such as releasing memory, restarting services, etc.). If the repair fails, an alarm is triggered to notify the operation and maintenance personnel.

[0214] The implementation steps of the intelligent fault detection module are:

[0215] (1) Data preprocessing and feature extraction:

[0216] Use Scikit-learn to normalize the data:

[0217] from sklearn.preprocessing import StandardScaler

[0218] scaler = StandardScaler()

[0219] scaled_data = scaler.fit_transform(raw_data)

[0220] (2) Use random forest to train fault detection model:

[0221] from sklearn.ensemble import RandomForestClassifier

[0222] model = RandomForestClassifier()

[0223] model.fit(X_train, y_train)

[0224] (3) Predicting real-time failures using Scikit-learn:

[0225] prediction = model.predict(real_time_data)

[0226] if prediction == 1: # 1 indicates a fault

[0227] perform_repair()

[0228] (4) Automatic repair:

[0229] Perform troubleshooting actions, such as freeing up memory or restarting services:

[0230] free -m

[0231] sync; echo 3 > / proc / sys / vm / drop_caches

[0232] (5) If the repair fails, an alarm is triggered to notify the operation and maintenance personnel.

[0233] In a specific embodiment, intelligent fault detection and repair is implemented as follows:

[0234] Train a random forest model:

[0235] from sklearn.ensemble import RandomForestClassifier

[0236] from sklearn.model_selection import train_test_split

[0237] import pandas as pd

[0238] # Assume that we have historical data: CPU usage, memory usage, etc., and corresponding fault labels (1 for fault, 0 for normal)

[0239] data = {

[0240] 'cpu_usage': [80, 90, 70, 95, 85],

[0241] 'memory_usage': [70, 80, 65, 90, 75],

[0242] 'fault': [0, 1, 0, 1, 0] # 0 means normal, 1 means fault

[0243] }

[0244] # Convert to DataFrame

[0245] df = pd.DataFrame(data)

[0246] # Features and labels

[0247] X = df[['cpu_usage', 'memory_usage']]

[0248] y = df['fault']

[0249] # Train the model

[0250] X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.3, random_state=42)

[0251] model = RandomForestClassifier()

[0252] model.fit(X_train, y_train)

[0253] # Use the model to predict failures

[0254] predictions = model.predict(X_test)

[0255] # Perform repairs or alerts based on prediction results

[0256] if predictions[0] == 1:

[0257] print("Failure risk detected, perform automatic repair or send alarm")

[0258] Further, the step S400 includes the following steps:

[0259] S410, use the difference integrated moving average autoregressive model ARIMA or the long short-term memory network LSTM time series model to predict the historical node resource usage data and predict future resource demand;

[0260] S420, Dynamically adjust server cluster resources based on Kubernetes or Docker Swarm;

[0261] S430. For frequently accessed data, use the Redis database or the distributed high-speed cache system Memcached to optimize the cache, thereby reducing access delays and the burden on the database.

[0262] Specifically, the resource management module includes: using time series models such as ARIMA or LSTM to predict historical resource usage data and predict future resource needs. Using Kubernetes or Docker Swarm to dynamically adjust cluster resources to ensure sufficient resources during peak loads. For frequently accessed data, use Redis or Memcached to optimize cache and reduce access latency and database burden.

[0263] Resource forecasting: Time series model (ARIMA): Based on historical resource usage data (CPU, memory, etc.), use the ARIMA model to forecast resources. The ARIMA model formula is as follows:

[0264]

[0265] in, is the predicted value at time t, and are model parameters, is the error term.

[0266] The ARIMA model requires that the input time series data is stationary. If the data is non-stationary, it needs to be differentiated to convert it into a stationary time series. For example, if the CPU usage data shows an upward trend in the long term, the difference operation can remove the trend component and make the data stationary.

[0267] ARIMA model parameter selection: ARIMA model has three key parameters: p (order of autoregressive term), d (order of difference), q (order of moving average term). These parameters are determined by analyzing the autocorrelation and partial autocorrelation of time series data.

[0268] ARIMA model training and fitting: Use historical data to train the ARIMA model, usually using the maximum likelihood estimation (MLE) method to fit the optimal parameters.

[0269] Predict future resource requirements: Use the trained ARIMA model to predict resource requirements for the next few periods (e.g., CPU usage for the next 7 days). This prediction helps the system schedule resources.

[0270] LSTM model: For non-stationary data, a long short-term memory network (LSTM) is used to predict resource requirements.

[0271] Data preprocessing and annotation of time series model (LSTM): The LSTM model requires that the input data is time series data arranged in chronological order. First, the data needs to be preprocessed, including normalization, to ensure that different features are at the same scale.

[0272] Constructing LSTM neural network structure model: LSTM is a model based on recurrent neural network (RNN), which is particularly suitable for long time series data. LSTM constructs a network structure through multiple input layers, hidden layers and output layers. Each hidden layer has a memory unit that can retain long-term information.

[0273] Model training and optimization: The LSTM model is optimized by training historical data. Common optimization algorithms include Adam or RMSProp. The training goal is to minimize the loss function (such as mean square error).

[0274] Predicting future resource requirements: The trained LSTM model can be used to predict resource requirements in the future, such as CPU, memory, etc. The system can adjust and optimize resources based on these prediction results.

[0275] Dynamic resource allocation: Use Kubernetes or Docker Swarm to dynamically allocate cluster resources based on prediction results, ensuring that additional nodes are started before peak periods and redundant resources are released during stable periods.

[0276] Cache optimization: For frequently accessed data, use Redis or Memcached for cache optimization to increase data access speed and reduce database pressure.

[0277] The steps to implement the resource management module are:

[0278] (1) Using the ARIMA model for resource forecasting:

[0279] from statsmodels.tsa.arima.model import ARIMA

[0280] model = ARIMA(data, order=(5,1,0))

[0281] model_fit = model.fit()

[0282] forecast = model_fit.forecast(steps=3)

[0283] (2) Use Kubernetes for resource scheduling and dynamic resource allocation:

[0284] kubectl scale deployment my-deployment --replicas=5

[0285] (3) Use Redis cache to optimize hot data:

[0286] import redis

[0287] r = redis.Redis(host='localhost', port=6379, db=0)

[0288] r.set('cpu_usage', 75)

[0289] In a specific embodiment, resource management and scheduling are implemented as follows:

[0290] Resource Forecasting Using ARIMA:

[0291] from statsmodels.tsa.arima.model import ARIMA

[0292] import numpy as np

[0293] import matplotlib.pyplot as plt

[0294] # Assume we have historical data (e.g. CPU usage)

[0295] data = [50, 55, 60, 58, 57, 59, 62, 64, 67, 65]

[0296] # Fit the data to the ARIMA model

[0297] model = ARIMA(data, order=(5, 1, 0))

[0298] model_fit = model.fit()

[0299] # Predicting future resource requirements

[0300] forecast = model_fit.forecast(steps=3)

[0301] print(f"Forecast CPU demand for the next 3 periods: {forecast}")

[0302] # Plot the prediction results

[0303] plt.plot(data, label='historical data')

[0304] plt.plot(range(len(data), len(data) + 3), forecast, label='Forecast data', linestyle='--')

[0305] plt.legend()

[0306] plt.show()

[0307] Further, the step S500 includes the following steps:

[0308] S510, based on Grafana or Kibana, the management panel of the background management module visually displays the monitoring data, load status and resource usage of each node;

[0309] S520. Store all fault log data in the search server Elasticsearch to facilitate quick query and fault tracing.

[0310] S530. The user views the alarm information through the background management module and performs fault handling and resource adjustment operations.

[0311] Specifically, the backend management system uses Grafana or Kibana to visualize the monitoring data, load status, and resource usage of each node, helping operation and maintenance personnel to view the system operation status in real time. All fault log data is stored in Elasticsearch for quick query and fault tracing. Operation and maintenance personnel can view alarm information through the backend system and perform operations such as fault handling and resource adjustment.

[0312] The final results and data are as follows:

[0313] (1) Load balancing module

[0314] Polling algorithm: As shown in Table 1, through the simulated traffic test, the system can evenly distribute requests and avoid overloading of some nodes.

[0315] Table 1:

[0316] node Request Allocation Quantity CPU usage Memory usage Number of connections node1 10 75% 65% 12 node2 10 80% 70% 8 node3 10 70% 60% 6

[0317] Weighted Round Robin Algorithm: As shown in Table 2, node 1 has higher performance, so it is assigned more requests.

[0318] Table 2:

[0319] node Weight Allocation Requests node1 2 14 node2 1 8 node3 1 8

[0320] (2) Node monitoring and alarm module

[0321] As shown in Table 3, the system successfully detected that the CPU usage exceeded **90%** and issued an alarm, and the alarm response time was 2 seconds.

[0322] Table 3:

[0323] node CPU usage Memory usage Alarm trigger time Alarm Type node1 92% 88% 2s High CPU warning node2 85% 80% No alarm normal node3 98% 95% 1s High Memory Warning

[0324] (3) Intelligent fault detection module

[0325] Fault Detection Accuracy: As shown in Table 4, through the random forest model, the system can correctly predict faults in 92% of cases and ensure timely repairs.

[0326] Table 4:

[0327] Prediction data Actual failure Prediction results 92% yes yes 85% no no 98% yes yes

[0328] Resource Management and Forecasting

[0329] As shown in Table 5, through the ARIMA model prediction, the system can accurately predict the resource requirements for the next three periods and adjust the resources in advance.

[0330] Table 5:

[0331] Forecast period Estimated CPU requirements Actual CPU requirements t+1 68% 70% t+2 69% 72% t+3 67% 66%

[0332] Furthermore, the present invention also proposes an intelligent management system based on a server cluster, which is used to execute the intelligent management method based on a server cluster. The intelligent management system based on a server cluster is connected to a server cluster, and the server cluster includes a plurality of server nodes. The intelligent management system based on a server cluster includes:

[0333] A load balancing module, which periodically sends HTTP requests to server nodes through a combination of one or more of a polling algorithm, a minimum connection number algorithm, and a weighted polling algorithm, checks the health status of server cluster nodes, and dynamically adjusts strategies based on health check results;

[0334] A node monitoring and alarm module, which is used to monitor the resource usage of each server node in real time and trigger an alarm when the set threshold is exceeded;

[0335] Intelligent fault detection module, which predicts server node faults based on historical data and real-time data through machine learning algorithms and provides automatic repair functions;

[0336] A resource management module, which dynamically adjusts the cluster resources of the server nodes by predicting resource requirements, ensuring that the cluster of server nodes can provide sufficient resources during peak loads, and reduces the load of the database in the server nodes through cache optimization;

[0337] The backend management module, the load balancing module, the node monitoring and alarm module, the intelligent fault detection module and the resource management module are respectively connected to the backend management module.

[0338] Further, in the node monitoring and alarm module, the resource usage of the server node includes at least the usage of the CPU, memory, and disk space of the server node;

[0339] In the intelligent fault detection module, the machine learning algorithm includes at least a decision tree and a random forest;

[0340] The background management module displays the monitoring data, load status and resource usage of each server node through Grafana or Kibana, and stores and maintains fault data through Elasticsearch.

[0341] Specifically, the goal of the load balancing module is to efficiently distribute client requests, avoid overloading a node in the cluster, and ensure high availability of the system. We need to design different load balancing algorithms that can dynamically adjust the request allocation strategy according to the load of the cluster. The node monitoring and alarm module monitors the resource usage of each node (such as CPU, memory, and disk space, etc.) in real time, and triggers an alarm when it exceeds the set threshold. Ensure that the system can detect potential problems and handle them in a timely manner. The intelligent fault detection module uses historical data and real-time data, uses machine learning algorithms (such as decision trees and random forests) to predict faults, and provides automatic repair functions. The resource management module dynamically adjusts cluster resources by predicting resource requirements. Ensure that the cluster can provide sufficient resources during load peaks and reduce database load through cache optimization.

[0342] The load balancing module is designed to reasonably distribute requests according to the load of cluster nodes to ensure system stability and performance. Polling algorithm: Applicable to situations where node performance is balanced, and requests are distributed in order. Minimum number of connections algorithm: Applicable to situations where load fluctuations are large, and requests are preferentially distributed to the node with the least current connections. Weighted polling algorithm: Applicable to clusters with large performance differences, and requests are distributed according to node performance (CPU, memory, etc.). Health check: Periodically check the node status through Ping or HTTP requests to ensure that requests are not distributed to unavailable nodes.

[0343] Design of node monitoring and alarm system, real-time monitoring of node resource usage, triggering alarms through thresholds, and notifying operation and maintenance personnel in a timely manner. Use Prometheus to collect data such as CPU, memory, and disk usage of each node. Trigger alarms by setting thresholds (such as CPU > 80%). Notify operation and maintenance personnel through Twilio SMS or SendGrid email. Design of intelligent fault detection module, using machine learning models to detect node faults and automatically repair them. Use historical data (CPU, memory, network latency, etc.) to train fault detection models (such as decision trees, random forests). Input the trained model with real-time monitoring data to automatically repair detected faults. Design of resource management module, predicting and dynamically scheduling cluster resources to avoid resource waste or shortage. Use ARIMA or LSTM time series models to predict future resource requirements. Use Kubernetes or Docker Swarm to automatically adjust resources to ensure that resources are allocated on demand.

[0344] Furthermore, the present invention also proposes a computer-readable storage medium on which program instructions are stored. When the program instructions are executed by a processor, the intelligent management method based on a server cluster is implemented.

[0345] The above is only a preferred embodiment of the present invention. The present invention is not limited to the above implementation. As long as the technical effect of the present invention is achieved by the same means, any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included in the scope of protection of the present disclosure. All should belong to the protection scope of the present invention. Within the protection scope of the present invention, its technical scheme and / or implementation method can have various modifications and changes.

Claims

1. An intelligent management method based on a server cluster, wherein the intelligent management method based on a server cluster is applied to an intelligent management system based on a server cluster, and the intelligent management system based on a server cluster includes: A load balancing module, wherein the load balancing module periodically sends HTTP requests to the server nodes through a combination of one or more of a polling algorithm, a minimum connection number algorithm, and a weighted polling algorithm, checks the health status of the server cluster nodes, and dynamically adjusts the strategy based on the health check results; a node monitoring and alarm module, wherein the node monitoring and alarm module is used to monitor the resource usage of each server node in real time and trigger an alarm when the set threshold is exceeded; an intelligent fault detection module, wherein the intelligent fault detection module predicts the faults of the server nodes based on historical data and real-time data through a machine learning algorithm and provides an automatic repair function; a resource management module, wherein the resource management module dynamically adjusts the cluster resources of the server nodes by predicting resource requirements to ensure that the cluster of server nodes can provide sufficient resources at peak loads, and reduces the load of the database in the server nodes through cache optimization; a background management module, wherein the load balancing module, the node monitoring and alarm module, the intelligent fault detection module, and the resource management module are respectively connected to the background management module, and wherein the intelligent management method based on the server cluster comprises the following steps: S100, the load balancing module detects the health status of the server nodes at preset time intervals in a preset manner, and actively adjusts the load balancing strategy according to the health status of the server nodes; S200, the node monitoring and alarm module monitors the resource usage of each server node in real time and triggers an alarm when it exceeds a set threshold; S300, the intelligent fault detection module detects the resource usage of the server node based on the pre-trained fault prediction model and outputs the fault prediction result. When the fault prediction model predicts a node failure, the repair script is automatically executed to repair the fault. If the repair fails, an alarm is triggered; S400, the resource management module predicts historical resource usage data based on a time series model and actively adjusts resources to ensure that sufficient resources are available during peak loads; S500, the background management module dynamically displays the load status and resource usage, records logs and handles faults.

2. The intelligent management method based on server cluster according to claim 1, characterized in that: The step S100 includes the following steps: S110, the load balancing module uses a polling algorithm by default to make timing requests, including sending one or more combinations of HTTP requests, Ping commands and custom health check endpoints to the server nodes at regular intervals, obtaining the response time of the server nodes, and judging the health status of the node servers; S120, if it is found that the response time of a server node exceeds the preset response time, the real-time load of the central processing unit CPU and memory of the node is determined through the real-time node monitoring data; S130, if the node load is too high, the load balancing module will dynamically adjust the load balancing strategy, switching from the round-robin algorithm to the minimum connection number algorithm or the weighted polling algorithm; S140, the load balancing module allocates server node tasks based on a minimum connection number algorithm or a weighted round-robin algorithm to alleviate the situation where the node load is too high; S150: When the load of the node with excessive load drops to a preset range, the load balancing module switches back to allocating server node tasks based on the polling algorithm.

3. The intelligent management method based on server cluster according to claim 2 is characterized in that: The polling algorithm distributes requests to each server node in sequence. The pseudo code is: node = nodes[index % len(nodes)] index += 1 The minimum connection number algorithm calculates the number of connections of each server node in real time and distributes the request to the node with the least number of connections. The pseudo code is: node = min(nodes, key=node.connections) The weighted polling algorithm assigns weights according to the CPU and memory performance of the server node and distributes requests to high-weight nodes. The formula is: ； Among them, node represents the node, index represents the sequence number of the node, and len represents the number of nodes. represents the weight of node i, node.connections and Indicates the current number of connections.

4. The intelligent management method based on server cluster according to claim 1, characterized in that: The step S200 includes the following steps: S210, based on the monitoring tool Prometheus, regularly collect monitoring data of key indicators from the data collector NodeExporter preset on each server node, wherein the monitoring data at least includes CPU usage, memory usage, disk space usage and network delay; S220, sending the monitoring data to the API server based on the HTTP protocol, and the API server storing the monitoring data in the MongoDB database or the search server Elasticsearch; S230, respectively set alarm thresholds for CPU usage, memory usage, disk space usage, and network latency. When the monitoring data exceeds the alarm threshold, send an alarm message via Twilio or SendGrid and display it on the management panel. S240: Merge, deduplicate and suppress the alarm information to avoid duplicate alarms.

5. The intelligent management method based on server cluster according to claim 1, characterized in that: The step S300 includes the following steps: S310, using a decision tree or random forest classification algorithm to train and obtain a fault prediction model; S320, based on the monitoring tool Prometheus, collects historical data of server nodes, cleans and standardizes the historical data; S330, inputting the CPU usage, memory usage, disk space usage and network delay of the server node into the trained fault prediction model, and the fault prediction model outputs the fault prediction result; S340: When the fault prediction model predicts a fault, a repair script is automatically executed to perform repair. If the repair fails, an alarm notification is triggered. The repair script at least includes releasing server node memory and restarting the service.

6. The intelligent management method based on server cluster according to claim 1, characterized in that: The step S400 includes the following steps: S410, use the difference integrated moving average autoregressive model ARIMA or the long short-term memory network LSTM time series model to predict the historical node resource usage data and predict future resource demand; S420, Dynamically adjust server cluster resources based on Kubernetes or Docker Swarm; S430. For frequently accessed data, use the Redis database or the distributed high-speed cache system Memcached to optimize the cache, thereby reducing access delays and the burden on the database.

7. The intelligent management method based on server cluster according to claim 1, characterized in that: The step S500 includes the following steps: S510, based on Grafana or Kibana, the management panel of the background management module visually displays the monitoring data, load status and resource usage of each node; S520. Store all fault log data in the search server Elasticsearch to facilitate quick query and fault tracing. S530. The user views the alarm information through the background management module and performs fault handling and resource adjustment operations.

8. An intelligent management system based on a server cluster, used to execute the intelligent management method based on a server cluster as claimed in any one of claims 1 to 7, wherein the intelligent management system based on a server cluster is connected to a server cluster, wherein the server cluster includes a plurality of server nodes, and wherein: The intelligent management system based on server cluster includes: A load balancing module, which periodically sends HTTP requests to server nodes through a combination of one or more of a polling algorithm, a minimum connection number algorithm, and a weighted polling algorithm, checks the health status of server cluster nodes, and dynamically adjusts strategies based on health check results; A node monitoring and alarm module, which is used to monitor the resource usage of each server node in real time and trigger an alarm when the set threshold is exceeded; Intelligent fault detection module, which predicts server node faults based on historical data and real-time data through machine learning algorithms and provides automatic repair functions; A resource management module, which dynamically adjusts the cluster resources of the server nodes by predicting resource requirements, ensuring that the cluster of server nodes can provide sufficient resources during peak loads, and reduces the load of the database in the server nodes through cache optimization; The backend management module, the load balancing module, the node monitoring and alarm module, the intelligent fault detection module and the resource management module are respectively connected to the backend management module.

9. The intelligent management system based on server cluster according to claim 8, characterized in that: In the node monitoring and alarm module, the resource usage of the server node includes at least the usage of the CPU, memory, and disk space of the server node; In the intelligent fault detection module, the machine learning algorithm includes at least a decision tree and a random forest; The background management module displays the monitoring data, load status and resource usage of each server node through Grafana or Kibana, and stores and maintains fault data through Elasticsearch.

10. A computer-readable storage medium having program instructions stored thereon, wherein the program instructions, when executed by a processor, implement the method as claimed in any one of claims 1 to 7.

Images