Nginx cluster operation method and device, storage medium and program product

Abstract

The embodiment of the invention discloses an Nginx cluster operation method and device, a storage medium and a program product. The method comprises the following steps: adding equipment information of a load balancing server in a determined default server; configuring a default server to generate a default configuration file, and performing synchronous configuration on the load balancing server based on the file to form an Nginx cluster; determining a management server from the Nginx cluster, wherein the management server determines a master server and a slave server from the Nginx cluster; when the master server is abnormal, deleting the abnormal master server from the Nginx cluster, and re-determining the master server and the slave server; when the slave server is abnormal, the abnormal slave server is deleted from the Nginx cluster and restarted; and when the abnormal server is recovered to be normal, adding the recovered server into the Nginx cluster again. According to the method, the construction difficulty of the Nginx cluster can be reduced through a synchronous configuration mechanism, and the management difficulty of the Nginx cluster is simplified through an election mechanism and exception monitoring.

Description

Technical Field

[0001] The present disclosure relates to the field of network security technology, and in particular to an Nginx cluster operation method, device, storage medium, and program product. Background Art

[0002] As a popular high-performance HTTP and reverse proxy web server, Nginx plays an important role in a variety of application scenarios. In addition to basic web service functions, Nginx also supports IMAP / POP3 / SMTP services, further expanding its application scope.

[0003] However, the construction of Nginx cluster mainly relies on manual installation and configuration of Nginx server and some auxiliary tools. This process involves complex configuration file editing, network parameter setting and cluster node management, which is cumbersome and error-prone. It can be seen that in practical applications, especially in large-scale cluster environments, the construction and management of Nginx clusters face a series of challenges. Summary of the invention

[0004] In view of this, the embodiments of the present disclosure provide an Nginx cluster operation method, device, storage medium, and program product, which can reduce the difficulty of building an Nginx cluster through a synchronous configuration mechanism, and simplify the management difficulty of an Nginx cluster through an election mechanism and abnormal monitoring.

[0005] In a first aspect, the embodiments of the present disclosure provide an Nginx cluster operation method, which adopts the following technical solutions:

[0006] Determine a default server and multiple load balancing servers;

[0007] Add the device information of the load balancing server to the default server;

[0008] Configuring the default server to generate a default configuration file;

[0009] Based on the default configuration file, the load balancing server is synchronously configured, and the default server and the load balancing server form an Nginx cluster;

[0010] Determine a management server from the Nginx cluster, wherein the management server determines a master server and at least one slave server from the Nginx cluster;

[0011] When an abnormality occurs in the master server, the abnormal master server is deleted from the Nginx cluster, and the master server and the slave server are re-determined;

[0012] When an exception occurs in the slave server, the abnormal slave server is deleted from the Nginx cluster and the abnormal slave server is restarted;

[0013] When the abnormal master server or the abnormal slave server returns to normal, the restored master server or slave server is re-added to the Nginx cluster.

[0014] Optionally, configuring the default server to generate a default configuration file includes:

[0015] Extract the common code from the first configuration file of the keepalive service software and the second configuration file of the Zabbix monitoring system;

[0016] Building a common configuration file based on the common code;

[0017] Screening out useless codes from the extracted first configuration file and the second configuration file;

[0018] Combining the default configuration file, the first configuration file after the screening process, and the second configuration file to form a functional configuration file;

[0019] Configuring the function configuration file into the default server;

[0020] Filtering out a number of available project templates from a plurality of configuration templates of the default server;

[0021] Based on the plurality of available project templates, generating a third configuration file;

[0022] The function configuration file and the third configuration file are combined into a default configuration file.

[0023] Optionally, the synchronously configuring the load balancing server based on the default configuration file includes:

[0024] Synchronously configuring the function configuration file in the default configuration file to the Nginx instance of the load balancing server;

[0025] Based on the third configuration file in the default configuration file, select a plurality of applicable templates from a plurality of configuration templates of the load balancing server;

[0026] Apply the above templates to Nginx configuration.

[0027] Optionally, determining the management server from the Nginx cluster includes:

[0028] Get the latest update time and current version number of each server in the Nginx cluster;

[0029] Obtaining a configuration score for each server according to the latest update time and the current version number;

[0030] Determine the server with the highest configuration score as the management server;

[0031] The calculation formula of the configuration score is:

[0032] AF i =W1*RT i +W2*D i ;

[0033] Where i is the serial number of the server in the Nginx cluster; AF i Score the configuration of the i-th server; W1 and W2 are the preset weights; RT i is the latest update time of the i-th server; D i It is the current version number of the i-th server YY+242163P.

[0034] Optionally, the management server determines a master server and at least one slave server from the Nginx cluster, including:

[0035] Determine a plurality of servers to be selected from the Nginx cluster, wherein the plurality of servers to be selected do not include the management server, the abnormal master server, and the abnormal slave server;

[0036] Sending the status information of the candidate server to the management server;

[0037] The management server obtains the status score of the candidate server according to the status information and the preset marking time;

[0038] The candidate server with the highest status score is determined as the master server, and the remaining candidate servers are determined as slave servers.

[0039] Optionally, the Nginx cluster operation method further includes:

[0040] When the management server does not receive the heartbeat signal sent by the main server within the first preset time, it is determined that an abnormality occurs in the main server;

[0041] The marking time of the abnormal master server is modified, wherein the modified marking time of the abnormal master server is the time from receiving the last heartbeat signal sent by the abnormal master server to determining that the abnormal master server has returned to normal.

[0042] Optionally, the Nginx cluster operation method further comprises: when the management server does not receive the heartbeat signal of the slave server within a second preset time, attempting to verify the slave server;

[0043] When the verification attempt fails, determining that an abnormality occurs in the slave server, and performing feasibility verification on the abnormal slave server;

[0044] Modify the marking time of the abnormal slave server, where the marking time after the abnormal slave server is modified is the time from the start of the feasibility verification to the end of the feasibility verification.

[0045] In a second aspect, the disclosed embodiment further provides an Nginx cluster operation system, which adopts the following technical solution:

[0046] A first determination module is used to determine a default server and multiple load balancing servers;

[0047] Information adding module, used to add the device information of the load balancing server in the default server;

[0048] A file generation module is used to configure the default server and generate a default configuration file;

[0049] Configuration synchronization module, used to synchronize the configuration of the load balancing server based on the default configuration file. The default server and the load balancing server form an Nginx cluster;

[0050] The second determination module is used to determine a management server from the Nginx cluster, and the management server determines a master server and at least one slave server from the Nginx cluster;

[0051] The redetermining module is used to delete the abnormal master server from the Nginx cluster and redetermine the master server and slave server when an abnormality occurs in the master server;

[0052] The delete restart module is used to delete the abnormal slave server from the Nginx cluster and restart the abnormal slave server when an exception occurs in the slave server;

[0053] The rejoin module is used to rejoin the restored master server or slave server to the Nginx cluster after the abnormal master server or slave server returns to normal.

[0054] In a third aspect, the embodiments of the present disclosure further provide a computer device, which adopts the following technical solution:

[0055] The computer device comprises:

[0056] at least one processor; and,

[0057] a memory communicatively connected to the at least one processor; wherein,

[0058] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any of the Nginx cluster operation methods described above.

[0059] In a fourth aspect, an embodiment of the present disclosure further provides a computer-readable storage medium, which stores computer instructions, and the computer instructions are used to enable a computer to execute any of the above-mentioned Nginx cluster operation methods.

[0060] In a fifth aspect, an embodiment of the present disclosure further provides a computer program product, including a computer program / instruction, which implements the steps of any of the above methods when executed by a processor.

[0061] The Nginx cluster operation method provided by the embodiment of the present disclosure selects a default server, adds the device information of the load balancing server in the default server, builds the connection between the default server and the load balancing server, and realizes preliminary integration of multiple servers, which provides convenient conditions for subsequent server configuration. Through the generation of the default configuration file and the automatic synchronization configuration of the load balancing server, an Nginx cluster is formed. This automation mechanism effectively reduces the manual operation of the user, reduces the workload of the user, ensures the consistency and coordination of all servers, so as to avoid performance bottlenecks or service interruptions caused by inconsistent configuration, so that requests can be evenly distributed to multiple servers, thereby improving the overall performance and response speed of the system. By selecting a management server, the system can centrally manage the entire Nginx cluster, and the management server is responsible for determining the master server and the slave server from the Nginx cluster, simplifying the management and maintenance of the cluster. When an abnormality occurs in the master server, the system can automatically delete it from the cluster and re-divide the master server and the slave server, ensuring that even if the master server fails, the cluster can continue to provide services, thereby improving the availability of the system. When an abnormality occurs in the slave server, the system can automatically delete it from the cluster and restart it, so that the abnormal slave server can recover quickly, reducing the impact of single point failures on the system. When the abnormal master server or slave server returns to normal, the system can automatically rejoin it to the cluster, ensuring the dynamic expansion capability of the cluster and enabling the system to quickly return to normal. In summary, this method implements a series of operational processes such as Nginx cluster construction, master server election, abnormal monitoring, and abnormal recovery, significantly reducing operation and maintenance costs and improving operation and maintenance efficiency.

[0062] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the following preferred embodiments are specifically cited and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0064] Figure 1 A flowchart of the Nginx cluster operation method provided by the embodiment of the present disclosure;

[0065] Figure 2 A method for generating a default configuration file provided in an embodiment of the present disclosure;

[0066] Figure 3 A block diagram of the operating principle of the default server provided in the embodiment of the present disclosure;

[0067] Figure 4 A flowchart of a management server screening method provided by an embodiment of the present disclosure;

[0068] Figure 5 A flowchart of a method for determining an abnormality of a primary server provided in an embodiment of the present disclosure;

[0069] Figure 6 A flowchart of a method for determining an abnormality from a server provided in an embodiment of the present disclosure;

[0070] Figure 7 A schematic diagram of a process flow of a feasibility verification method provided in an embodiment of the present disclosure;

[0071] Figure 8 A block diagram of the Nginx cluster operation system provided in the embodiment of the present disclosure;

[0072] Fig. 9 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0073] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0074] It should be clear that the following embodiments of the present disclosure are described by specific specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that the following embodiments and features in the embodiments can be combined with each other in the absence of conflict. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of the present disclosure.

[0075] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein may be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on the present disclosure, it should be understood by those skilled in the art that an aspect described herein may be implemented independently of any other aspect, and two or more of these aspects may be combined in various ways. For example, any number of aspects described herein may be used to implement the device and / or practice the method. In addition, other structures and / or functionalities other than one or more of the aspects described herein may be used to implement this device and / or practice this method.

[0076] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present disclosure. The drawings only show components related to the present disclosure rather than being drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component may be changed arbitrarily, and the component layout may also be more complicated.

[0077] Additionally, in the following description, specific details are provided to facilitate a thorough understanding of the examples. However, it will be understood by those skilled in the art that the aspects described may be practiced without these specific details.

[0078] Reference Figure 1 The present disclosure provides an Nginx cluster operation method, comprising the following steps:

[0079] S1: Determine a default server and multiple load balancing servers;

[0080] S2: Add the device information of the load balancing server in the default server;

[0081] S3: Configure the default server and generate a default configuration file;

[0082] S4: Based on the default configuration file, the load balancing server is synchronously configured. The default server and the load balancing server form an Nginx cluster.

[0083] S5: Determine the management server from the Nginx cluster, and the management server determines a master server and at least one slave server from the Nginx cluster;

[0084] S6: When an exception occurs in the master server, the abnormal master server is deleted from the Nginx cluster, and the master server and slave server are re-determined;

[0085] S7: When an exception occurs in the slave server, the abnormal slave server is deleted from the Nginx cluster and the slave server is restarted;

[0086] S8: When the abnormal master server or the abnormal slave server returns to normal, the restored master server or slave server is re-added to the Nginx cluster.

[0087] The disclosed Nginx cluster operation method selects a default server, adds the device information of the load balancing server in the default server, builds the connection between the default server and the load balancing server, realizes the preliminary integration of multiple servers, and provides convenient conditions for the subsequent server configuration. Through the generation of the default configuration file and the automatic synchronization configuration of the load balancing server, the Nginx cluster is formed. This automation mechanism effectively reduces the manual operation of the user, reduces the workload of the user, ensures the consistency and coordination of all servers, avoids the performance bottleneck or service interruption caused by inconsistent configuration, and enables the request to be evenly distributed to multiple servers, thereby improving the overall performance and response speed of the system. By selecting a management server, the system can centrally manage the entire Nginx cluster, and the management server is responsible for determining the master server and the slave server from the Nginx cluster, simplifying the management and maintenance of the cluster. When the master server is abnormal, the system can automatically delete it from the cluster and re-divide the master server and the slave server, ensuring that even if the master server fails, the cluster can continue to provide services, thereby improving the availability of the system. When the slave server is abnormal, the system can automatically delete it from the cluster and restart it, so that the abnormal slave server can recover quickly, reducing the impact of single point failure on the system. When the abnormal master server or slave server returns to normal, the system can automatically rejoin it to the cluster, ensuring the dynamic expansion capability of the cluster and enabling the system to quickly return to normal.

[0088] In summary, this method implements a series of operational processes such as Nginx cluster construction, master server election, abnormal monitoring, and abnormal recovery. Through automated configuration, synchronization, and fault handling mechanisms, the system can significantly reduce operation and maintenance costs, reduce user manual intervention, reduce the possibility of human errors, and improve operation and maintenance efficiency. Through automatic failover and restart mechanisms, the system can quickly restore services and reduce downtime caused by server abnormalities, thereby reducing operation and maintenance costs.

[0089] In S1, start the server through the automated script and perform basic configuration, such as network settings and Nginx installation. Access the server's IP address through the browser to verify whether the server is correctly configured and working properly. If the access is successful, it means that the configuration is successful. If the access fails, update the configuration. The server with the initial successful access or the best performance is the default server, and the remaining servers are load balancing servers.

[0090] In S2, the default server is extended based on the Zabbix monitoring platform page, and the Manage module (management platform) is set in the default server. The Manage module provides a friendly user interface for users to adjust configurations, set monitoring items, and manage alarm notifications. When building a cluster, users add the device information of the load balancing server through the Manage module, successfully establish a communication bridge between the two, and achieve initial integration between servers, laying the foundation for building an Nginx cluster and forming the prototype of the cluster. Among them, Zabbix is ​​an open source monitoring system used to monitor the health of networks and applications; YY+242163P

[0091] Device information includes but is not limited to IP address and MAC address.

[0092] In S3, refer to Figure 2 The default configuration file generation method shown in the figure, "Configure the default server and generate the default configuration file" includes the following steps:

[0093] S31: extracting common codes from the first configuration file of the keepalive service software and the second configuration file of the Zabbix monitoring system;

[0094] S32: Building a common configuration file based on the common code;

[0095] S33: Screening out useless codes from the extracted first configuration file and the second configuration file;

[0096] S34: combining the default configuration file, the first configuration file after the screening process, and the second configuration file to form a function configuration file;

[0097] S35: configure the function profile to the default server;

[0098] S36: Filter out a number of available project templates from multiple configuration templates of the default server;

[0099] S37: Generate a third configuration file based on a number of available project templates;

[0100] S38: Combine the function profile and the third profile into a default profile.

[0101] In S31, the configuration file of the Keepalived service software is called the first configuration file, and the configuration file of the Zabbix monitoring system is called the second configuration file, and the common code in the first configuration file and the second configuration file is queried and extracted. The common code is the code part that is reused in the Keepalived and Zabbix configuration files, such as common configuration instructions, variable definitions, log records, etc.

[0102] In S32, the common code is stored in a preset empty file to form a common configuration file, such as common_config.conf.

[0103] In S33, after extracting the common code in the first configuration file and the second configuration file, the code function analysis is performed on the first configuration file and the second configuration file, useless code is filtered out according to actual needs, and the required code parts are retained, for example, VRRP (Virtual Routing Redundancy Protocol) related code in Keepalived is retained, and monitoring plug-in and API related code in Zabbix is ​​retained.

[0104] In S34, the default configuration file, the first configuration file after the screening process, and the second configuration file are combined into a functional configuration file, such as functional_config.conf. Note that during the combination process, the compatibility between the various configuration files is ensured.

[0105] In S35, when configuring the function profile to the default server, an abstraction layer or adaptation layer is built on the basis of the function profile to solve the compatibility problem between the function profile and the default server. In the abstraction layer or adaptation layer, the required code can be further filtered and other codes can be edited, and the keepalive service software, Zabbix monitoring system and Nginx integration related parts are retained to improve the maintainability of the code. YY+242163P

[0106] Protective nature.

[0107] In S36, for each server, the number of configuration templates is consistent with the number of projects. Therefore, the required project types can be determined according to actual needs, and corresponding templates can be screened out from multiple configuration templates according to the project types. The screened templates are called available project templates.

[0108] In S37, a script is used to read each selected available project template one by one, and replace them according to predefined variables and placeholders, and the processed template content is combined into a new configuration file, such as project_config.conf, and recorded as the third configuration file.

[0109] In S38, the function configuration file and the third configuration file are combined to form a default configuration file, such as default_config.conf, which includes the functions required by the Keepalived service software, the functions required by the Zabbix monitoring system, and the project requirement configuration.

[0110] In S4, the load balancing server performs synchronous configuration according to the default configuration file by calling the interface of the load balancing server or actively pushing the default server. Specifically, the load balancing server configures the function configuration file in the default configuration file to the local Nginx instance, screens multiple local configuration templates according to the third configuration file in the default configuration file, obtains several applicable templates, applies several applicable templates to the Nginx configuration, realizes the customization of Nginx behavior, and performs syntax checking and configuration validity verification before applying the new configuration to ensure that it is correct. Through this method, the user only needs to perform a comprehensive configuration of the default server once, and the load balancing server can automatically adjust the local configuration according to the configuration of the default server, thereby reducing the user's workload while achieving the uniformity between the default server and the load balancing server.

[0111] A Function module is set up in each server. The Function module mainly uses the relevant source code in Nginx and is responsible for implementing the specific functions of HTTP and reverse proxy WEB servers, including processing requests from clients or browsers, forwarding, load balancing or caching according to the configuration, providing stable WEB services, and ensuring that users can access and use the system normally.

[0112] The related functions of the Keepalived service software form a Starter module (startup module) in each server. The Starter module mainly uses the relevant source code in Keepalive to implement the functions of selecting and restarting the Function module. When the system starts or a failure occurs, the Starter module is responsible for starting or restarting the Function module to ensure the availability of the service, implement the master-slave switching mechanism, and ensure the continuity of the service.

[0113] The relevant functions of the Zabbix monitoring system form a Monitor module (monitor) in each server. The Monitor module is responsible for collecting performance data, operating status and other information of the Function module, and sending it to the Controller module for processing. It can also detect abnormal conditions of the system in a timely manner, such as performance degradation and service interruption.

[0114] The corresponding alarm notification is triggered.

[0115] A Controller module is set in each server. The Controller module is the center of the entire system and coordinates the interaction and data flow between modules. Specifically, the Controller module is responsible for receiving the monitoring data sent by the Monitor module, processing and analyzing it, and extracting key information. Based on the feedback from the Monitor module, the Controller module provides data support for the real-time monitoring of the Manage module. The Controller module also has the function of calling the Starter module, restarting the Function module or adjusting its configuration as needed.

[0116] The configured load balancing server and the default server form an Nginx cluster, which can also be called a lightweight HTTP and reverse proxy WEB server cluster.

[0117] Reference Figure 3The operating principle block diagram of the default server shown includes the Manage module, Controller module, Monitor module, Starter module and Function module. Compared with the default server, the Manage module can be configured for the load balancing server without using the Manage module. The Manage module of the default server can be used for users. The Manage module can also be configured for the load balancing server. At this time, the Manage module is used to visualize the relevant data information of the load balancing server and facilitate users to configure the load balancing server separately. Adjust the communication mechanism between the modules of the server to achieve seamless docking and ensure the accuracy and efficiency of data transmission. This modular structure design ensures that the modules are logically independent of each other, but can work together at runtime, which can not only improve the stability and reliability of the Nginx cluster, but also facilitate cluster management and improve overall work efficiency.

[0118] Note that the aforementioned distinction between the default server and the load balancing server is for the purpose of quickly building an Nginx cluster. The management server, master server, and slave server described later can be any one or more of the default server and the load balancing server.

[0119] In S5, refer to Figure 4 The flowchart of the management server screening method shown in the figure includes the following steps to determine the management server from the Nginx cluster:

[0120] S51: Get the latest update time and current version number of each server in the Nginx cluster;

[0121] S52; obtaining a configuration score of each server according to the latest update time and the current version number;

[0122] S53: Determine the server with the highest configuration score as the management server.

[0123] In S51, the latest update time is the timestamp of the last update of the server configuration. In Nginx, this means configuration changes, certificate updates, or adjustments to load balancing policies.

[0124] In S52, the calculation formula of the configuration score is as follows:

[0125] AF i =W1*RT i +W2*D i ;(Formula 1)

[0126] In formula 1, i is the serial number of the server in the Nginx cluster; AF i Score the configuration of the i-th server; W1 and W2 are the preset weights; RT iis the latest update time of the i-th server; D i is the current version number of the i-th server.

[0127] In S53, the highest configuration score means that the server with the latest configuration and data version can be selected as the management server, which can ensure that the management server has the latest cluster status information, so as to manage other servers more effectively. The real-time performance of the management server is crucial to the response speed and fault recovery of the cluster. Selecting the server with the latest configuration as the management server can reduce latency and improve the overall performance of the cluster. In a distributed system, data consistency is a core issue. Selecting a server with the latest data version as the management server helps maintain data consistency in the cluster.

[0128] After the management server is screened out, the management server, the master server with confirmed abnormality, and the slave server with confirmed abnormality are excluded from the Nginx cluster, and the remaining servers are the servers to be selected.

[0129] The Monitor module of each candidate server sends its own status information and preset marking time to the Monitor module of the management server, and the Monitor module of the management server sends the status information and marking time of each candidate server to its own Starter module. The status information includes the device identification of the candidate server, several performance indicators and several health indicators. The Starter module creates an election list based on the device identification of the candidate server.

[0130] According to the election list, the Starter module of the management server calculates the status score of each candidate server based on several performance indicators, several health indicators and marking time. Among them, the several performance indicators include at least one of CPU usage, memory usage, network bandwidth and disk I / O; the several health indicators include at least one of response time, error rate, load balancing status and the number of errors in the system log.

[0131] When the marking time is equal to 0, the calculation formula of the state score is as follows:

[0132]

[0133] In formula 2, j is the sequence number of the server to be selected; BF j is the status score of the jth candidate server; m is the type number of the performance indicator, m≤M; M is the total number of performance indicator types; S jm is the value of the mth performance indicator of the jth server to be selected; ω mis the weight of the mth performance indicator; n is the type number of the health indicator; N is the total number of health indicator types, n≤N; N is the total number of health indicator types; P jn Take the value of the nth health indicator of the jth candidate server; ω n is the weight of the nth health indicator; CT j is the marking time of the jth candidate server.

[0134] When the marking time is greater than 0, the calculation formula of the status score is as follows:

[0135]

[0136] In Formula 3, B is the preset basic prohibition times; F is the timeout factor, which indicates the ratio of the increase in the number of prohibited elections for each unit increase in the timeout time, which can be set according to the system's requirements for stability and responsiveness; X is the number of times the candidate server re-participates in the division of the master server and the slave server after it is determined to be abnormal and then returns to normal (i.e., the number of times it re-participates in the election of the master server); θ is the preset unit score, for example, θ is 30; is the floor function; max(·) is the maximum value function.

[0137] The server with the highest status score is selected as the master server, and the remaining servers are determined as slave servers. The election results are broadcast to all servers in the cluster. This method can ensure that the elected master server performs well in terms of performance and health status. When the value is less than 0 and the j-th candidate server does not have another abnormality, the marking time of the j-th candidate server is reset to 0.

[0138] The initial value of the marking time is 0. After the primary server and the secondary server are divided, the value of the marking time will change as the abnormality of the server is determined.

[0139] Among them, refer to Figure 5 The flowchart of the method for determining the abnormality of the main server is shown. The method for determining whether the main server is abnormal includes:

[0140] S61: Determine whether the management server receives the heartbeat signal of the main server within the first preset time; if so, execute S62; if not, execute S63;

[0141] S62: Determine that no abnormality occurs in the primary server;

[0142] S63: Determine whether an abnormality occurs in the main server.

[0143] In the above, the Function module of the main server will periodically send a heartbeat signal to the Monitor module of the management server. If the Monitor module does not receive the heartbeat signal within the first preset time, it means that an abnormality has occurred in the main server, and the abnormal main server will be deleted from the Nginx cluster. Other servers can be notified to suspend work before determining a new main server, that is, temporarily not processing new requests to avoid system errors caused by the lack of main server abnormalities. Different threads can also be started to process new requests and elect new main servers at the same time. The abnormal main server is also marked as untrusted, and the marking time of the abnormal main server is modified. The modified marking time is the time from receiving the last heartbeat signal sent by the abnormal main server to determining that the abnormal main server has returned to normal. At the same time, the Monitor module of the abnormal main server issues a high-level alarm to remind users to repair the abnormal main server.

[0144] If the Monitor module of the management server receives the heartbeat signal within the first preset time, it means that the main server has no abnormality and there is no need to modify the marking time of the main server. The first preset time is 3YY+242163P

[0145] Heartbeat time.

[0146] Among them, refer to Figure 6 The flowchart of the slave server exception determination method is shown. The method for determining whether an exception occurs in the slave server includes:

[0147] S71: Determine whether the management server receives a heartbeat signal from the server within a second preset time; if so, execute S72; if not, execute S73;

[0148] S72: Determine that no abnormality occurs from the server;

[0149] S73: Attempt to verify the slave server; if the verification attempt succeeds, execute S72; if the verification attempt fails, execute S74;

[0150] S74: It is determined that an abnormality has occurred from the server.

[0151] In S71 and S72, the Function module of the slave server periodically sends a heartbeat signal to the Monitor module of the management server. If the Monitor module receives the heartbeat signal within the second preset time, it means that no abnormality has occurred in the slave server and there is no need to modify the marking time of the slave server. The second preset time is greater than three consecutive heartbeat times.

[0152] In S73, if the Monitor module does not receive the heartbeat signal within the second preset time, it checks whether the slave server can successfully restart itself (i.e., tries to verify). If the slave server can successfully restart itself within the third preset time, it is determined that no abnormality has occurred in the slave server; if the slave server does not successfully restart itself within the third preset time, it is determined that an abnormality has occurred in the slave server, and the abnormal slave server is marked as a risky state. The Monitor module of the abnormal slave server issues a low-level alarm, and the slave server is deleted from the Nginx cluster.

[0153] Furthermore, when the verification attempt fails, the Monitor module of the management server also notifies its Controller module to perform feasibility verification on the abnormal slave server and records the start time and end time of the feasibility verification. The marking time of the abnormal slave server is modified, and the modified marking time is the time from the start of the feasibility verification to the end of the feasibility verification.

[0154] Reference Figure 7 The flowchart of the feasibility verification method shown in the figure includes the following steps:

[0155] S75: Restart the auxiliary abnormal slave server; if the restart is successful, execute S76; if the restart fails, execute S77;

[0156] S76: Determine that the feasibility verification is completed;

[0157] S77: sending a heartbeat signal to the abnormal slave server through the management server at every fourth preset time interval;

[0158] S78: Determine whether the abnormal slave server responds to the heartbeat signal; if so, execute S76; if not, return to S77 and continue the heartbeat verification;

[0159] YY+242163P

[0160] In S75 and S76, the Controller module of the management server calls its own Starter module, and the Starter module assists in restarting the abnormal slave server. If the restart is successful, the feasibility verification is determined to be completed, the risk status mark is canceled, and it is indicated that the recovery operation of the abnormal slave server is completed.

[0161] In S77 and S78, when the auxiliary restart is unsuccessful, the risk status of the abnormal slave server is modified to an untrusted state, and the Monitor module of the abnormal slave server issues a high-level alarm to remind the user to repair the abnormal slave server. Before the repair is completed, the management server sends a heartbeat signal, i.e., a heartbeat verification, to the abnormal slave server at every fourth preset time interval. If the abnormal slave server correctly responds to the heartbeat signal, it is determined that the feasibility verification is completed. If it does not correctly respond to the heartbeat signal, the heartbeat verification is continued through the management server.

[0162] Through the above method, it is possible to determine whether an abnormality occurs according to the response of the master server and the slave server to the heartbeat signal, and after determining that an abnormality occurs in the master server and the slave server, the corresponding marking time is recorded, and the state score of the abnormal server (i.e., the abnormal master server and / or the abnormal slave server) participating in the election is limited according to the marking time, so as to achieve the purpose of limiting the abnormal server from being elected as the master server within a certain period of time, thereby reducing the impact of the abnormal server on the system reliability. Since the master server has a greater impact on the normal operation of the system, the abnormal judgment of the master server is relatively strict, so as to avoid the overall operation of the Nginx cluster caused by the master server. Since the slave server has a smaller impact on the normal operation of the system, the abnormal judgment of the slave server is relatively loose, and the modification of the marking time of the abnormal master server and the abnormal slave server is different, which in turn affects the subsequent election of the new master server.

[0163] In S7, when the recovery operation of the abnormal server is completed, the abnormal server sends a recovery signal to the management server. After receiving the recovery signal, the management server sends a heartbeat signal to the abnormal server. If the abnormal server does not respond, the recovery is determined to be failed, and the user is reminded to continue repairing; if the abnormal server responds, the abnormal server is determined to be restored to normal, the untrusted state mark of the abnormal server is cancelled, and the restored abnormal server is re-added to the Nginx cluster. The above method can verify the authenticity of the recovery of the abnormal server to ensure its performance and stability after it resumes normal operation.

[0164] Optionally, more key indicators can be monitored in real time, such as request response time, throughput, error rate, etc., and monitoring data can be deeply analyzed to extract useful information, provide data support for system optimization, and provide flexible alarm strategy settings to meet the needs of different users. Specifically, according to the alarm strategy, when a server failure is detected, the corresponding alarm is triggered in time. Different alarm triggering conditions correspond to different notification channels, such as email, SMS, WeChat, etc. Use the Manage module to visualize data, add more practical configuration options and data display methods, such as charts, dashboards, etc., so that users can manage and monitor clusters more easily and intuitively.

[0165] YY+242163P

[0166] Through the architectural design and interactive relationship of this method, the advantages of nginx, keepalive and Zabbix are combined to optimize the fault detection algorithm and recovery strategy, especially in high-concurrency scenarios. It not only realizes the efficient management and maintenance of the Nginx cluster, ensures the stability and reliability of the system, but also reduces the difficulty of user operation. At the same time, through the collaborative work of the Monitor module, the Controller module and the Starter module, the system can detect and handle faults in a timely manner, improve the self-recovery ability of the system, and before applying the above technical solutions to actual scenarios, through stress testing and fault simulation experiments, verify the optimization effect, identify performance bottlenecks, adjust the parameters in the solution, and optimize system operation.

[0167] Reference Figure 8 The present disclosure provides an Nginx cluster operation system, including:

[0168] A first determination module 101 is used to determine a default server and multiple load balancing servers;

[0169] An information adding module 102 is used to add device information of a load balancing server to a default server;

[0170] The file generation module 103 is used to configure the default server and generate a default configuration file;

[0171] Configuration synchronization module 104, used to synchronize the configuration of the load balancing server based on the default configuration file, and the default server and the load balancing server form an Nginx cluster;

[0172] The second determination module 105 is used to determine a management server from the Nginx cluster, and the management server determines a master server and at least one slave server from the Nginx cluster;

[0173] A re-determination module 106 is used to delete the abnormal main server from the Nginx cluster and re-determine the main server and the slave server when an abnormality occurs in the main server;

[0174] The deletion and restart module 107 is used to delete the abnormal slave server from the Nginx cluster and restart the abnormal slave server when an abnormality occurs in the slave server;

[0175] The rejoining module 108 is used to rejoin the restored master server or slave server to the Nginx cluster after the abnormal master server or the abnormal slave server returns to normal.

[0176] The various variations and specific examples of the Nginx cluster operation method provided above are also applicable to the Nginx cluster operation system provided in the present disclosure. Through the above detailed description of the Nginx cluster operation method, those skilled in the art can clearly know the implementation method of the Nginx cluster operation system. For the sake of brevity of the specification, it will not be described in detail here.

[0177] The computer device according to the embodiment of the present disclosure includes a memory and a processor. The memory is used to store non-temporary computer-readable instructions. Specifically, the memory may include one or more computer program products, and the computer program product may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include a random access memory (RAM) and / or a cache memory (cache), etc. The non-volatile memory may, for example, include a read-only memory (ROM), a YY+242163P hard disk, a flash memory, etc.

[0179] The processor may be a central processing unit (CPU) or other forms of processing units having data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of the present disclosure, the processor is used to run the computer-readable instructions stored in the memory, so that the computer device performs all or part of the steps of the Nginx cluster operation method of each embodiment of the present disclosure.

[0180] Those skilled in the art should be able to understand that in order to solve the technical problem of how to obtain a good user experience, the present embodiment may also include well-known structures such as a communication bus and an interface, and these well-known structures should also be included in the protection scope of the present disclosure.

[0181] like Fig. 9 A schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure is shown, which is a schematic diagram of the structure of a computer device suitable for implementing the embodiment of the present disclosure. Fig. 9 The computer device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0182] like Fig. 9 As shown, the computer device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) or a program loaded from a storage device into a random access memory (RAM). In the RAM, various programs and data required for the operation of the computer device are also stored. The processor, ROM, and RAM are connected to each other via a bus. An input / output (I / O) interface is also connected to the bus.

[0183] Typically, the following devices can be connected to the I / O interface: input devices such as sensors or visual information acquisition devices; output devices such as display screens; storage devices such as tapes, hard disks, etc.; and communication devices. The communication device can allow the computer device to communicate with other devices (such as edge computing devices) wirelessly or by wire to exchange data. Fig. 9 A computer device having various devices is shown, but it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed instead.

[0184] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processor, all or part of the steps of the Nginx cluster operation method of the embodiment of the present disclosure are executed.

[0185] For detailed description of this embodiment, reference may be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0187] According to the computer-readable storage medium of the embodiment of the present disclosure, non-transitory computer-readable instructions are stored thereon. When the non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the Nginx cluster operation method of each embodiment of the present disclosure are executed.

[0188] The above-mentioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or mobile hard disk), media with built-in rewritable non-volatile memory (e.g., memory card) and media with built-in ROM (e.g., ROM box).

[0189] For detailed description of this embodiment, reference may be made to the corresponding descriptions in the aforementioned embodiments, which will not be repeated here.

[0190] The basic principles of the present disclosure are described above in conjunction with specific embodiments. However, it should be noted that the advantages, strengths, effects, etc. mentioned in the present disclosure are only examples and not limitations, and it cannot be considered that these advantages, strengths, effects, etc. are required by each embodiment of the present disclosure. In addition, the specific details disclosed above are only for the purpose of illustration and ease of understanding, and are not limitations. The above details do not limit the present disclosure to the necessity of adopting the above specific details to be implemented.

[0191] In the present disclosure, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. The block diagrams of the devices, devices, equipment, and systems involved in the present disclosure are only illustrative examples and are not intended to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagram. As will be appreciated by those skilled in the art, these devices, devices, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open words, referring to "including but not limited to", and can be used interchangeably with them. The words "or" and "and" used here refer to the words "and / or" and can be used interchangeably with them, unless the context clearly indicates otherwise. The words "such as" used here refer to the phrase "such as but not limited to", and can be used interchangeably with them.

[0192] Additionally, as used herein, "or" used in a list of items beginning with "at least one" indicates a separate list, so that, for example, a list of "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not mean that the example described is preferred or better than other examples.

[0193] It should also be noted that in the system and method of the present disclosure, each component or each step can be decomposed and / or recombined. Such decomposition and / or recombination should be regarded as equivalent solutions of the present disclosure.

[0195] Various changes, substitutions, and modifications of the techniques described herein may be made without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of the present disclosure is not limited to the specific aspects of the processes, machines, manufactures, compositions of events, means, methods, and actions described above. Currently existing or later to be developed processes, machines, manufactures, compositions of events, means, methods, or actions that perform substantially the same functions or achieve substantially the same results as the corresponding aspects described herein may be utilized. Thus, the appended claims include such processes, machines, manufactures, compositions of events, means, methods, or actions within their scope.

[0196] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of the present disclosure. Therefore, the present disclosure is not intended to be limited to the aspects shown herein, but rather to the widest scope consistent with the principles and novel features disclosed herein.

[0197] The above description has been given for the purpose of illustration and description. In addition, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although multiple example aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, changes, additions and sub-combinations thereof.

Claims

1. A Nginx cluster operation method, characterized in that: include: Determine a default server and multiple load balancing servers; Add the device information of the load balancing server to the default server; Configuring the default server to generate a default configuration file; Based on the default configuration file, the load balancing server is synchronously configured, and the default server and the load balancing server form an Nginx cluster; Determine a management server from the Nginx cluster, and the management server determines a master server and at least one slave server from the Nginx cluster; When an abnormality occurs in the master server, the abnormal master server is deleted from the Nginx cluster, and the master server and the slave server are re-determined; When an exception occurs in the slave server, the abnormal slave server is deleted from the Nginx cluster and the abnormal slave server is restarted; When the abnormal master server or the abnormal slave server returns to normal, the restored master server or slave server is re-added to the Nginx cluster.

2. The Nginx cluster operation method according to claim 1, characterized in that: The configuring the default server to generate a default configuration file includes: Extract the common code from the first configuration file of the keepalive service software and the second configuration file of the Zabbix monitoring system; Building a common configuration file based on the common code; Screening out useless codes from the extracted first configuration file and the second configuration file; Combining the default configuration file, the first configuration file after the screening process, and the second configuration file to form a functional configuration file; Configuring the function configuration file into the default server; Filtering out a number of available project templates from a plurality of configuration templates of the default server; Based on the plurality of available project templates, generating a third configuration file; The function configuration file and the third configuration file are combined into a default configuration file.

3. The Nginx cluster operation method according to claim 2, characterized in that: The synchronously configuring the load balancing server based on the default configuration file includes: Synchronously configuring the function configuration file in the default configuration file to the Nginx instance of the load balancing server; Based on the third configuration file in the default configuration file, select a plurality of applicable templates from a plurality of configuration templates of the load balancing server; Apply the above templates to Nginx configuration.

4. The Nginx cluster operation method according to claim 1, characterized in that: Determining the management server from the Nginx cluster includes: Get the latest update time and current version number of each server in the Nginx cluster; Obtaining a configuration score for each server according to the latest update time and the current version number; Determine the server with the highest configuration score as the management server; The calculation formula of the configuration score is: OF i =W1*RT i +W2*D i ; Where i is the serial number of the server in the Nginx cluster; AF i Score the configuration of the i-th server; W1 and W2 are the preset weights; RT i is the latest update time of the i-th server; D i is the current version number of the i-th server.

5. The Nginx cluster operation method according to claim 1, characterized in that: The management server determines a master server and at least one slave server from the Nginx cluster, including: Determine a plurality of servers to be selected from the Nginx cluster, wherein the plurality of servers to be selected do not include the management server, the abnormal master server, and the abnormal slave server; Sending the status information of the candidate server to the management server; The management server obtains the status score of the candidate server according to the status information and the preset marking time; The candidate server with the highest status score is determined as the master server, and the remaining candidate servers are determined as slave servers.

6. The Nginx cluster operation method according to claim 5, characterized in that: Also includes: When the management server does not receive the heartbeat signal sent by the main server within the first preset time, it is determined that an abnormality occurs in the main server; The marking time of the abnormal master server is modified, wherein the modified marking time of the abnormal master server is the time from receiving the last heartbeat signal sent by the abnormal master server to determining that the abnormal master server has returned to normal.

7. The Nginx cluster operation method according to claim 5, characterized in that: Also includes: YY+242163P When the management server does not receive the heartbeat signal of the slave server within the second preset time, attempting to verify the slave server; When the verification attempt fails, determining that an abnormality occurs in the slave server, and performing feasibility verification on the abnormal slave server; Modify the marking time of the abnormal slave server, where the marking time after the abnormal slave server is modified is the time from the start of the feasibility verification to the end of the feasibility verification.

8. A computer device, characterized in that: The computer device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the Nginx cluster operation method described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, which are used to enable a computer to execute the Nginx cluster operation method described in any one of claims 1-7.

10. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images