Cluster system based on domestic VPX server and method for attaching VIP to application service

Abstract

The invention discloses a domestic VPX server-based cluster system and an application service VIP attachment method, and relates to the field of domestic information systems. The system comprises three computing modules, each computing module adopts a domestic processor, each computing module is provided with a Nomad server and a Consul server, the computing modules are converted into a management node mode, and a one-master two-slave architecture is formed through a master selection mechanism; a Nomad client and a Consul client are respectively operated on each computing module, and the computing modules are converted into computing node modes, so that the computing modules have both management and computing functions. During work, a Nomad cluster is constructed based on a domestic VPX server, mixed arrangement and full-life-cycle management of containerized application services and traditional application services are achieved, resource management and high service availability are supported, and reliable and stable operation of an information system is guaranteed; meanwhile, a VIP function is provided for the application service, and transparent and non-inductive access of an external client or the application service is supported when the application service is migrated.

Description

Technical Field

[0001] The patent of this invention relates to the field of domestic information systems, and in particular to a cluster system based on domestic VPX servers and a method for attaching VIP to application services. Background Art

[0002] With the rise and maturity of cloud-native technologies, container orchestration tools like Kubernetes have become the standard for cloud-native operating systems, supporting containerized applications and providing rich, comprehensive cloud service capabilities. Furthermore, there remains a demand for general-purpose high-availability clusters supporting 1+1 and N+M models, offering resource and service management capabilities while also providing dual- or multi-machine hot standby to ensure application and service availability. However, domestic information systems face the following shortcomings: Firstly, limited by the cost, complexity, and real-time requirements of existing application services, not every application can quickly transition to containerization. Secondly, due to the limitations of domestic VPX server architectures, the number of compute modules that can be accommodated and the configuration of individual compute modules are limited. Consequently, domestic information systems built on clusters lack the ability to quickly boot up or migrate services in the event of hardware failures in mobile scenarios. Furthermore, from an application perspective, ensuring that applications running on clusters have unique, global VIP addresses (i.e., virtual IP addresses) that persist across application restarts or node migrations within the cluster remains a challenge. Summary of the Invention

[0003] In view of the above problems, the present invention provides a service VIP implementation method based on Nomad cluster and an application service VIP attachment method.

[0004] The technical solution of the present invention is: a cluster system based on domestic VPX servers, comprising three computing modules, each of which uses a domestic processor. Each computing module deploys a Nomad server and a Consul server, transforming the computing module into a management node mode. Through the master election mechanism, a "1 master 2 slaves" architecture is formed. Run the Nomad client and Consul client on each computing module, converting the computing module into computing node mode, so that the computing module has both management and computing functions; The Nomad server and Nomad client form a Nomad cluster. The Nomad server in the Nomad cluster supports cluster deployment mode, which is used to accept user jobs and delegate tasks to the Nomad client. The client is responsible for running the tasks assigned to this node; The Consul server and Consul client form a Consul cluster. The Consul cluster is used for service discovery and configuration of distributed systems; The client-server in the Nomad cluster and Consul cluster respectively adopts the RPC communication mechanism. When an application service is created in the Nomad cluster, it is automatically registered with the Consul cluster to support the service discovery function.

[0005] It also includes a MetalLB module, which runs on the Nomad cluster to form a MetalLB service.

[0006] The MetalLB module is implemented in GO language and runs on the Nomad cluster in the form of a Job with "System" type and "raw_exec" task driver, forming a MetalLB service. Each Nomad client node runs the MetalLB service and monitors the application services in the Consul cluster through the Watch method of the local Consul client, so that the MetalLB service can perceive the creation, update and deletion operations of the application services in the Consul cluster, thereby providing VIP functions for the application services.

[0007] The MetalLB module includes four submodules: VIP validity judgment, attachment, load balancing and health check. in, The VIP validity judgment submodule is used to detect the legitimacy of the VIP address; The VIP attachment submodule is used to attach the VIP to the activated network card of the node where the application service is located or the master node; The VIP load balancing submodule is used for multi-copy services; The VIP health detection submodule is used to periodically check the health status of VIPs.

[0008] The VIP validity judgment submodule includes: First, obtain the VIP address corresponding to the VIP tag in the Job associated with the application service, and then determine whether the value is in the IP address pool. If it is not in the pool, it will prompt that the VIP address is out of range, that is, an invalid VIP address; otherwise, use the local node Consul client to obtain all used service VIP information from the ConsulKV storage, and compare it with the service VIP in a loop to determine whether the IP address is already in the KV storage of the Consul cluster; If it exists, use the ping method to determine whether the IP address is ping-able. If it is ping-able, it will be prompted that the IP address is already used by other application services and the IP address is invalid. If it is not ping-able, according to the retry judgment mechanism, ping twice more. If it fails to ping three times in a row, it means that the VIP is available and the VIP information in the KV is deleted. If it does not exist, the VIP is checked through pinging to see if the IP address is ping-able. If it is ping-able, it indicates that the IP address is already in use and is invalid. If it is not ping-able, the VIP is available.

[0009] The VIP attachment submodule includes: First, a UDP request is sent through the net base library and the local IP address is obtained from the returned UDP connection. Second, all local network cards are obtained through the IP command. Then, based on the comparison, the local network card corresponding to the IP address is obtained, that is, the active network card corresponding to the IP address. For single-copy application services, the VIP attachment submodule obtains the activated network card of the node where the application service is located, and then attaches the VIP to the activated network card through the IP addr add method. After the addition is completed, the MAC address of the network card where the VIP is located can be discovered based on the ARP protocol to achieve communication; at the same time, the VIP is added to the Consul KV storage and the VIP in the IP address pool is marked as used; For multi-replica application services, the VIP attachment submodule obtains all healthy service instances of the service from the Consul cluster based on the name of the application service, sorts them based on the name of the node where the service instance is located using the sort() function, selects the first node in the sequence as the primary node, and attaches the VIP to the active network card of the node.

[0010] The VIP load balancing submodule includes: When load balancing is found in the application service label in the Consul cluster, by calling the iptables command and the ipvs basic library, according to the configuration information of the VIP, service port, service type and all healthy instances of the service, iptables rules and IPVS rules are created on the VIP attachment node and the node is used as the access entrance of the application service. After the user request is converted through IPtables NAT, it is distributed to different service copies based on the IPVS rules, that is, forwarded to this node or other nodes running the application service for processing, thereby supporting load balancing of multi-copy application services.

[0011] The VIP health detection submodule includes two coroutines, where: Coroutine 1: Periodically accesses the healthy interface of the local Consul client to determine whether the local Client service is running normally. If it is abnormal for three consecutive times, the local Consul client is determined to be abnormal. The VIP health detection submodule then cyclically deletes the VIP information added to the node in the memory stored by the VIP attachment submodule. Coroutine 2: Periodically checks whether the active network card and Consul KV contain a VIP. First, obtain the VIP information stored in Consul KV: VIP / node / bound service name. Filter the VIP of the current node based on the node information, and then check whether the active network card of the current node contains the VIP. If included, the health check passes; If not, further determine whether the VIP corresponding to the service can be pinged: ① If the ping fails, reattach the VIP to the active network card of the node, and then update the IPtables and IPVS rules of the node according to the virtual.ip.slb tag of the application service. ②If the ping is successful, the VIP information will be deleted from the Consul KV storage; at the same time, the Nomad cluster high availability mechanism will be triggered, and the application service will be re-created according to the original VIP on other healthy nodes based on the scheduling strategy.

[0012] It also includes other computing modules, Run the Nomad client and Consul client on other computing modules to convert the computing modules into computing node mode.

[0013] The method for attaching a VIP to an application service based on a domestic VPX server adopts the cluster system based on the domestic VPX server, including: (1) MetalLB service initialization When the Nomad cluster is started, the MetalLB service is initialized synchronously. After the MetalLB service is started, it obtains the VIP range value IP address pool set in the Job, checks whether the IP address pool exists, and whether the start and end value formats are correct. If the IP address pool does not exist or the format is incorrect, the startup fails and the service exits. (2) Application service VIP allocation a) The Nomad cluster loads the Job task corresponding to the application service and executes the application service creation process. The Nomad cluster identifies the service discovery backend based on the Provider field in the Service field of the application service Job and registers the application service in the Consul cluster using the local Consul client. The registration information is the information in the JobService field, including tags. b) When the MetalLB service detects that an application service is registered with the Consul cluster based on the "listening" mode, it reads the Job tag to determine whether the application service has VIP enabled. If not, it creates it directly. If it is enabled, it calls the VIP validity judgment module to determine whether the VIP address specified by "virtual.ip.address" is available. If it is available, it determines the master node based on all healthy instances, adds VIP information to the master node's activated network card and KV storage, and determines whether to start load balancing based on the "virtual.ip.slb" tag. If it is enabled, it creates Iptables and Ipvs rules to achieve load balancing. (3) Application service VIP health status check The MetalLB service periodically performs health checks on the application service VIP status. If the health status is abnormal, it indicates that a network failure has occurred in the application service. The VIP is reattached or the Nomad cluster high availability mechanism is triggered. The application service is re-created on another healthy node according to the original VIP based on the scheduling policy. (4) Application Service VIP Update When the Nomad cluster executes an application service update, the MetalLB service determines whether the VIP of the service exists on the local node. If not, the logic of adding the service is executed. If it exists, it determines whether the VIP function of the updated service is disabled. a) If you disable the VIP function and delete the previously added VIP, the existing load balancing rules will also be deleted; b) If the VIP function is not disabled, recalculate the master node based on healthy service instances to determine whether the current node is still the master node; ① If the node is no longer the master node, delete the previously added VIP; at the same time, the existing load balancing rules are also deleted; ② If the master node remains unchanged, compare the updated VIP value to see if it has changed; if so, delete the previous VIP and load balancing rules, and then execute the logic for adding services; if the value does not change, observe whether load balancing is enabled, enable and update the load balancing rules; if only load balancing is disabled, delete the load balancing rules; (5) Application Service VIP Deletion When the Nomad cluster deletes or stops an application service, the Nomad cluster deletes the service from the Consul cluster. At the same time, the MetalLB service determines whether the VIP of the service exists on this node. If so, it deletes the VIP information and load balancing rules from the active network card and ConsulKV storage.

[0014] During operation, the present invention builds a Nomad cluster based on domestic VPX servers to achieve hybrid orchestration and full life cycle management of containerized application services and traditional application services, support resource management and high availability of services, and ensure the reliable and stable operation of the information system; at the same time, it provides VIP functions for application services and supports transparent and seamless access by external clients or application services when application services are migrated. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 This is a schematic diagram of the VPX server made in China in the present invention. Figure 2 This is a schematic diagram of the deployment of the Nomad cluster, Consul cluster, and MetalLB module in the present invention. Figure 3 This is a flow chart of the method for attaching VIP to application services in the present invention. DETAILED DESCRIPTION

[0016] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, the specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0017] In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0018] The present invention provides a cluster system based on domestic VPX servers, which includes three computing modules, each of which uses a domestic processor. Each computing module deploys a Nomad server and a Consul server, transforming the computing module into a management node mode. Through the master election mechanism, a "1 master 2 slaves" architecture is formed. Run the Nomad client and Consul client on each computing module, converting the computing module into computing node mode, so that the computing module has both management and computing functions; The Nomad server and Nomad client form a Nomad cluster. The Nomad server in the Nomad cluster supports cluster deployment mode, which is used to accept user jobs and delegate tasks to the Nomad client. The client is responsible for running the tasks assigned to this node; The Consul server and Consul client form a Consul cluster. The Consul cluster is used for service discovery and configuration of distributed systems; The client-server in the Nomad cluster and Consul cluster respectively adopts the RPC communication mechanism. When an application service is created in the Nomad cluster, it is automatically registered with the Consul cluster to support the service discovery function.

[0019] like Figure 1 As shown, the domestic server adopts the VPX architecture design and includes 3 computing modules. Each computing module uses domestic processors such as Feiteng, Loongson and Kunpeng, with a memory of no less than 8GB and a disk capacity of no less than 1TB. The operating system is the Zhongbid Kylin / Galaxy Kylin server operating system and supports multiple network cards.

[0020] like Figure 2 As shown, a Nomad cluster is deployed in cluster mode. Three compute modules are deployed with a Nomad server and a Consul server, transforming the compute modules into three management nodes. A master election mechanism (such as the Raft algorithm) creates a "one master, two slaves" architecture, supporting high availability of the management nodes. Simultaneously, the Nomad client and Consul client run on each of the three compute modules, transforming the compute modules into three compute nodes. This means the compute modules perform both management and computing functions, supporting dynamic online scaling of compute nodes. The client-server communication between the Nomad and Consul clusters uses RPC. Application services created in the Nomad cluster are automatically registered with the Consul cluster, supporting service discovery.

[0021] The MetalLB module is implemented in Go and runs on a Nomad cluster as a "System" job with a "raw_exec" task driver. This forms the MetalLB service, which runs on every Nomad client node. It monitors application services in the Consul cluster through the local Consul client's Watch method, allowing the service to detect application service creation, update, and deletion operations in the Consul cluster, thereby providing VIP functionality for the application services. The MetalLB service is defined using an HCL-formatted job as follows: The MetalLB service configures an available VIP address pool using environment variables. The VIP start and end values ​​must be in the same network segment as the compute module's physical IP address. The VIP specified by the application service must be within this address pool. The MetalLB service uses the "virtual.ip.address" and "virtual.ip.slb" tags to identify whether the application service requires VIP configuration and load balancing support, as follows: "virtual.ip.address=" is the fixed key of the VIP tag, and IP3 is a variable value, representing the external VIP value specified when creating the application service. The "virtual.ip.slb" tag indicates that the application service supports the load balancing function. This tag must be used with the VIP tag and will not be effective when used alone. If the application service configuration file does not contain the "tags" or "tags" VIP tag, the VIP function will not be provided when the application service is created.

[0022] Based on the Nomad cluster, Consul cluster and MetalLB module of the domestic VPX server, the MetalLB module includes four sub-modules: VIP validity judgment, attachment, load balancing and health check.

[0023] Nomad cluster is a lightweight and flexible cluster management and service orchestration system that provides a simple and unified workflow for deploying and managing containerized applications or traditional applications. It uses a plug-in driver framework to support workload scheduling in multiple driver modes such as containers, native executable programs, and batch applications, and supports cross-data center scheduling to meet the needs of hybrid deployment and management of containerized applications and traditional applications.

[0024] The core functions of the cluster are implemented by a binary program that supports both client and server operating modes. It is fully self-contained and does not require external services for storage or coordination of tasks. It automatically handles application service and node failures.

[0025] Compared with general-purpose task orchestration tools such as Kubernetes, this cluster is more lightweight and optimized in terms of system architecture. It trims or simplifies non-essential business designs and functional components, integrating only the necessary components. This supports rapid function integration and component replacement and upgrade, meeting the needs of targeted function expansion or replacement in different scenarios. In terms of installation and deployment, some core capabilities are integrated and packaged into a small number of binary files, reducing external dependencies, the number of component processes, and communication between component processes and even across nodes. The Nomad cluster server supports cluster deployment mode. While ensuring a high-availability architecture, it acts as the "brain" to accept user jobs and delegate tasks to clients. Clients are responsible for running tasks assigned to their nodes. The Consul cluster is primarily used for service discovery and configuration of distributed systems. This cluster implements service discovery through seamless integration with the Nomad cluster. Services running on the Nomad cluster can register themselves with the Consul cluster and store data in the Consul KV storage, allowing other services on the Nomad cluster to discover the services they need to connect to.

[0026] The MetalLB module includes four sub-modules: VIP validity judgment, attachment, load balancing, and health check. It provides a global, unique VIP address for application services on the Nomad cluster, enabling transparent access by clients or application services outside the Nomad cluster.

[0027] The VIP validity check submodule is mainly used to check the legitimacy of the VIP address. First, it obtains the VIP address corresponding to the VIP tag in the Job associated with the application service, and then determines whether the value is in the IP address pool. If it is not in the pool, it prompts that the VIP address is out of range and invalid. Otherwise, it uses the local node Consul client to obtain all used service VIP information from the ConsulKV storage, and compares it with the service VIP in a loop to determine whether the IP address is already in the Consul cluster's KV storage.

[0028] (1) If it exists, determine whether the IP address can be pinged through. If it can be pinged, it will prompt that the IP address has been used by other application services and the IP address is invalid. If it cannot be pinged, according to the retry judgment mechanism (the default maximum number of attempts is 3), ping it twice again. If it cannot be pinged for 3 consecutive times, it means that the VIP is available and the VIP information in the KV is deleted.

[0029] (2) If it does not exist, the IP address is determined by pinging. If it can be pinged (once), it is prompted that the IP address has been used and is an invalid IP address; if it cannot be pinged (once), the VIP is available.

[0030] The VIP attachment submodule is primarily used to attach a VIP to the active network interface card (NIC) of the node hosting the application service or the master node. First, it sends a UDP request through the net library and retrieves the local IP address from the returned UDP connection. Second, it uses the IP command to retrieve all local NICs. Finally, based on a comparison, it determines the local NIC corresponding to the IP address, i.e., the active NIC corresponding to the IP address. For single-replica application services, after obtaining the active NIC of the application service's node, the module attaches the VIP to the active NIC using the IP addr add method. Once attached, the MAC address of the NIC hosting the VIP is discovered using the ARP protocol to enable communication. Simultaneously, the VIP is added to the Consul KV storage, marking the VIP as in use in the IP address pool. For multi-replica application services, the module retrieves all healthy service instances from the Consul cluster based on the application service name, sorts them by the node names using the sort() function, selects the first node in the sequence as the master node, and attaches the VIP to the active NIC of that node.

[0031] The VIP load balancing submodule is mainly used for multi-replica services. For single-replica application services, it is not recommended to enable this function because there is only one service instance and no other load. For multi-replica application services, when this module finds that load balancing (Label=LB) is used in the application service label in the Consul cluster, it calls the iptables command and the ipvs basic library. Based on the configuration information such as VIP, service port, service type (TCP / UDP) and all healthy instances of the service, it creates iptables rules and IPVS rules on the VIP attachment node (master node) and uses this node as the access entrance for the application service. After user requests are converted through IPtables NAT, they are distributed to different service replicas based on IPVS rules, that is, forwarded to this node or other nodes running the application service for processing, thereby supporting load balancing of multi-replica application services and realizing service load balancing.

[0032] The VIP health check submodule is primarily responsible for periodically checking the health of VIPs and ensuring their availability. It is implemented using two coroutines. Coroutine 1: Periodically (default 5 seconds) accesses the local Consul client's healthy interface to determine whether the local client service is operating normally. If it fails three times in a row, the local Consul client is deemed abnormal. This module then cyclically deletes the VIP information already added to the node from the VIP attachment submodule's memory. First, it uses the ip addr del command to delete the VIP on the active network interface card. Second, it uses the iptables command and the ipvs library to delete IPtable / IPVS rule information. Coroutine 2: Periodically (default 5 seconds) checks the existence of the VIP in the active network interface card and Consul KV. First, it retrieves the VIP information stored in Consul KV: VIP / node / bound service name. It then filters the node's VIP based on the node information. Then, it checks whether the node's active network interface card contains the VIP. If so, the health check passes. If not, it further determines whether the VIP corresponding to the service can be pinged: ① If the ping fails, reattach the VIP to the active network card of the node, and then update the IPtables and IPVS rules of the node according to the virtual.ip.slb tag of the application service. ②If the ping is successful, the VIP information will be deleted from the Consul KV storage. At the same time, the Nomad cluster high availability mechanism will be triggered, and the application service will be re-created according to the original VIP on other healthy nodes according to the scheduling strategy to ensure high availability of the application service.

[0033] The application also includes other computing modules. Run the Nomad client and Consul client on other computing modules to convert the computing modules into computing node mode.

[0034] like Figure 3 As shown, the method for attaching VIP to application services based on domestic VPX servers adopts the cluster system based on domestic VPX servers, which mainly includes MetalLB service initialization, application service VIP allocation, application service VIP health status check, application service VIP update and application service VIP deletion. The specific process is as follows: (1) MetalLB service initialization When the Nomad cluster is started, the MetalLB service is initialized synchronously. After the MetalLB service is started, it obtains the VIP range value IP address pool set in the Job, determines whether the IP address pool exists, and whether the start value and end value formats are correct. If the IP address pool does not exist or the format is incorrect, the startup fails and the service exits.

[0035] (2) Application service VIP allocation a) The Nomad cluster loads the Job task corresponding to the application service and executes the application service creation process. The Nomad cluster identifies the service discovery backend based on the Provider field in the Service field of the application service Job and uses the local Consul client to register the application service in the Consul cluster. The registration information is the information in the JobService field, including tags.

[0036] b) When the MetalLB service detects an application service registered with the Consul cluster in "listening" mode, it reads the Job tag to determine whether the application service has VIP enabled. If not, it creates it directly. If enabled, it calls the VIP validity determination module to determine whether the VIP address specified by "virtual.ip.address" is available. If it is available, it determines the master node based on all healthy instances, adds VIP information to the master node's active network card and KV storage, and determines whether to enable load balancing based on the "virtual.ip.slb" tag. If it is enabled, it creates Iptables and Ipvs rules to achieve load balancing.

[0037] (3) Application service VIP health status check The MetalLB service periodically performs health checks on the application service VIP. If the health status is abnormal, it indicates a network failure. The VIP is reattached or the Nomad cluster high-availability mechanism is triggered. The application service is re-created on another healthy node with the original VIP according to the scheduling policy to ensure high availability of the application service.

[0038] (4) Application Service VIP Update When the Nomad cluster executes an application service update, the MetalLB service determines whether the VIP of the service exists on this node. If not, the logic of adding the service is executed; if it exists, it determines whether the VIP function of the updated service is disabled.

[0039] a) If you disable the VIP function and delete the previously added VIP, the existing load balancing rules will also be deleted; b) If the VIP function is not disabled, the master node is recalculated based on healthy service instances to determine whether the current node is still the master node.

[0040] ① If this node is no longer the master node, delete the previously added VIP; at the same time, the existing load balancing rules are also deleted.

[0041] ② If the master node remains unchanged, compare the updated VIP value to see if it has changed. If so, delete the previous VIP and load balancing rules, then execute the logic for adding the service. If the value remains unchanged, check whether load balancing is enabled, and enable and update the load balancing rules. If only load balancing is disabled, delete the load balancing rules.

[0042] (5) Application Service VIP Deletion When the Nomad cluster deletes or stops an application service, the Nomad cluster deletes the service from the Consul cluster. At the same time, the MetalLB service determines whether the VIP of the service exists on this node. If so, it deletes the VIP information and load balancing rules from the active network card and ConsulKV storage.

[0043] In actual use, the present invention meets the needs of mixed deployment, orchestration, and management of containerized applications and traditional applications (binary); taking into account the needs of domestic information systems built on clusters in mobile scenarios that should have fast startup and rapid service migration in the event of hardware failure; and the application services running on the cluster need to have a unique, global VIP address, which does not change due to restart or node migration of the application service in the cluster, that is, it remains transparent to external clients or services; at the same time, for multi-copy services, the VIP is supported as a service access portal to achieve load balancing function.

[0044] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that the technical solutions of the present invention may be modified or replaced by equivalents without departing from the spirit and scope of the technical solutions of the present invention, which should all be included in the scope of the claims of the present invention.

Claims

1. The cluster system based on domestic VPX servers includes three computing modules, each of which uses domestic processors. It is characterized by: Each computing module deploys a Nomad server and a Consul server, transforming the computing module into a management node mode. Through the master election mechanism, a "1 master 2 slaves" architecture is formed. Run the Nomad client and Consul client on each computing module, converting the computing module into computing node mode, so that the computing module has both management and computing functions; The Nomad server and Nomad client form a Nomad cluster. The Nomad server in the Nomad cluster supports cluster deployment mode, which is used to accept user jobs and delegate tasks to the Nomad client. The client is responsible for running the tasks assigned to this node; The Consul server and Consul client form a Consul cluster. The Consul cluster is used for service discovery and configuration of distributed systems; The client-server in the Nomad cluster and Consul cluster respectively adopts the RPC communication mechanism. When an application service is created in the Nomad cluster, it is automatically registered with the Consul cluster to support the service discovery function.

2. The cluster system based on domestic VPX servers according to claim 1 is characterized in that: It also includes a MetalLB module, which runs on the Nomad cluster to form a MetalLB service.

3. The cluster system based on domestic VPX servers according to claim 2 is characterized in that: The MetalLB module is implemented in GO language and runs on the Nomad cluster in the form of a Job with "System" type and "raw_exec" task driver, forming a MetalLB service. Each Nomad client node runs the MetalLB service and monitors the application services in the Consul cluster through the Watch method of the local Consul client, so that the MetalLB service can perceive the creation, update and deletion operations of the application services in the Consul cluster, thereby providing VIP functions for the application services.

4. The cluster system based on domestic VPX servers according to claim 2, characterized in that: The MetalLB module includes four submodules: VIP validity judgment, attachment, load balancing and health check. in, The VIP validity judgment submodule is used to detect the legitimacy of the VIP address; The VIP attachment submodule is used to attach the VIP to the activated network card of the node where the application service is located or the master node; The VIP load balancing submodule is used for multi-copy services; The VIP health detection submodule is used to periodically check the health status of VIPs.

5. The cluster system based on domestic VPX servers according to claim 4 is characterized in that: The VIP validity judgment submodule includes: First, obtain the VIP address corresponding to the VIP tag in the Job associated with the application service, and then determine whether the value is in the IP address pool. If it is not in the pool, it will prompt that the VIP address is out of range, that is, an invalid VIP address; otherwise, use the local node Consul client to obtain all used service VIP information from the ConsulKV storage, and compare it with the service VIP in a loop to determine whether the IP address is already in the KV storage of the Consul cluster; If it exists, use the ping method to determine whether the IP address is ping-able. If it is ping-able, it will be prompted that the IP address is already used by other application services and the IP address is invalid. If it is not ping-able, according to the retry judgment mechanism, ping twice more. If it fails to ping three times in a row, it means that the VIP is available and the VIP information in the KV is deleted. If it does not exist, the VIP is checked through pinging to see if the IP address is ping-able. If it is ping-able, it indicates that the IP address is already in use and is invalid. If it is not ping-able, the VIP is available.

6. The cluster system based on domestic VPX servers according to claim 4, characterized in that: The VIP attachment submodule includes: First, a UDP request is sent through the net base library and the local IP address is obtained from the returned UDP connection. Second, all local network cards are obtained through the IP command. Then, based on the comparison, the local network card corresponding to the IP address is obtained, that is, the active network card corresponding to the IP address. For single-copy application services, the VIP attachment submodule obtains the activated network card of the node where the application service is located, and then attaches the VIP to the activated network card through the IP addr add method. After the addition is completed, the MAC address of the network card where the VIP is located can be discovered based on the ARP protocol to achieve communication; at the same time, the VIP is added to the Consul KV storage and the VIP in the IP address pool is marked as used; For multi-replica application services, the VIP attachment submodule obtains all healthy service instances of the service from the Consul cluster based on the name of the application service, sorts them based on the name of the node where the service instance is located using the sort() function, selects the first node in the sequence as the primary node, and attaches the VIP to the active network card of the node.

7. The cluster system based on domestic VPX servers according to claim 4, characterized in that: The VIP load balancing submodule includes: When load balancing is found in the application service label in the Consul cluster, by calling the iptables command and the ipvs basic library, according to the VIP, service port, service type and the configuration information of all healthy instances of the service, iptables rules and IPVS rules are created on the VIP attachment node and the node is used as the access entrance of the application service. After the user request is converted through IPtablesNAT, it is distributed to different service copies based on the IPVS rules, that is, forwarded to this node or other nodes running the application service for processing, thereby supporting load balancing of multi-copy application services.

8. The cluster system based on domestic VPX servers according to claim 4, characterized in that: The VIP health detection submodule includes two coroutines, where: Coroutine 1: Periodically accesses the healthy interface of the local Consul client to determine whether the local Client service is running normally. If it is abnormal for three consecutive times, the local Consul client is determined to be abnormal. The VIP health detection submodule then cyclically deletes the VIP information added to the node in the memory stored by the VIP attachment submodule. Coroutine 2: Periodically checks whether the active network card and Consul KV contain a VIP. First, obtain the VIP information stored in Consul KV: VIP / node / bound service name. Filter the VIP of the current node based on the node information, and then check whether the active network card of the current node contains the VIP. If included, the health check passes; If not, further determine whether the VIP corresponding to the service can be pinged: ① If the ping fails, reattach the VIP to the active network card of the node, and then update the IPtables and IPVS rules of the node according to the virtual.ip.slb tag of the application service. ②If the ping is successful, the VIP information will be deleted from the Consul KV storage; at the same time, the Nomad cluster high availability mechanism will be triggered, and the application service will be re-created according to the original VIP on other healthy nodes based on the scheduling strategy.

9. The cluster system based on domestic VPX servers according to claim 1, characterized in that: It also includes other computing modules, Run the Nomad client and Consul client on other computing modules to convert the computing modules into computing node mode.

10. A method for attaching a VIP to an application service based on a domestic VPX server, using the cluster system based on a domestic VPX server as described in any one of claims 1 to 9, characterized in that: include: (1) MetalLB service initialization When the Nomad cluster is started, the MetalLB service is initialized synchronously. After the MetalLB service is started, it obtains the VIP range value IP address pool set in the Job, checks whether the IP address pool exists, and whether the start and end value formats are correct. If the IP address pool does not exist or the format is incorrect, the startup fails and the service exits. (2) Application service VIP allocation a) The Nomad cluster loads the Job task corresponding to the application service and executes the application service creation process. The Nomad cluster identifies the service discovery backend based on the Provider field in the Service field of the application service Job and registers the application service in the Consul cluster using the local Consul client. The registration information is the information in the JobService field, including tags. b) When the MetalLB service detects that the application service is registered with the Consul cluster based on the "listening" mode, it reads the Job tag to determine whether the application service has VIP enabled; If not enabled, create it directly; If enabled, the VIP validity judgment module is called to determine whether the VIP address specified by "virtual.ip.address" is available. If it is available, the master node is determined based on all healthy instances, and the VIP information is added to the master node's activated network card and KV storage. The "virtual.ip.slb" tag is used to determine whether to enable load balancing. If enabled, Iptables and Ipvs rules are created to achieve load balancing. (3) Application service VIP health status check The MetalLB service periodically performs health checks on the application service VIP status. If the health status is abnormal, it indicates that a network failure has occurred in the application service. The VIP is reattached or the Nomad cluster high availability mechanism is triggered. The application service is re-created on another healthy node according to the original VIP based on the scheduling policy. (4) Application Service VIP Update When the Nomad cluster executes an application service update, the MetalLB service determines whether the VIP of the service exists on the local node. If not, the logic of adding the service is executed. If it exists, it determines whether the VIP function of the updated service is disabled. a) If you disable the VIP function and delete the previously added VIP, the existing load balancing rules will also be deleted; b) If the VIP function is not disabled, recalculate the master node based on healthy service instances to determine whether the current node is still the master node; ① If the node is no longer the master node, delete the previously added VIP; at the same time, the existing load balancing rules are also deleted; ② If the master node remains unchanged, compare the updated VIP value to see if it has changed; if so, delete the previous VIP and load balancing rules, and then execute the logic for adding the service; If the value does not change, check whether load balancing is enabled, and enable and update the load balancing rules; if load balancing is only disabled, delete the load balancing rules; (5) Application Service VIP Deletion When the Nomad cluster deletes or stops an application service, it deletes the service from the Consul cluster. At the same time, the MetalLB service determines whether the VIP of the service exists on this node. If so, it deletes the VIP information and load balancing rules from the active network card and Consul KV storage.

Images