Cluster system based on domestic VPX server and application service attached VIP method

Abstract

This invention relates to the field of domestic information systems and describes a cluster system and application service VIP attachment method based on domestically produced VPX servers. It comprises three computing modules, each using a domestically produced processor. Each module deploys a Nomad server and a Consul server, transforming the computing modules into management node mode. A master-slave architecture is formed through a master election mechanism. Each computing module runs a Nomad client and a Consul client, transforming the module into a computing node mode, thus enabling it to perform both management and computational functions. In this work, the invention constructs a Nomad cluster based on domestically produced VPX servers, achieving hybrid orchestration and full lifecycle management of containerized and traditional application services. It supports resource management and high service availability, ensuring the reliable and stable operation of the information system. Simultaneously, it provides VIP functionality for application services, enabling transparent and seamless access by external clients or application services during application service migration.

Description

Technical Field

[0001] This invention patent relates to the field of domestic information systems, and in particular to a cluster system based on a domestic VPX server and a method for attaching VIPs to application services. Background Technology

[0002] Currently, on the one hand, with the rise and maturity of cloud-native technologies, container orchestration tools represented by Kubernetes have become the standard for cloud-native operating systems, supporting containerized application operation and providing rich and comprehensive cloud service capabilities. On the other hand, there is still a certain demand for general-purpose high-availability clusters that support 1+1, N+M, and other modes, providing resource and service management functions while offering dual-machine or multi-machine hot standby capabilities to ensure the availability of application services. However, in the field of domestic information systems, the following shortcomings exist: Firstly, due to limitations in the cost, complexity, and real-time requirements of transforming existing application services, not every application can quickly transition to containerization. Secondly, due to the limitations of domestic VPX server architecture, the number of computing modules that can be accommodated and the configuration of a single computing module are limited. In mobile scenarios, domestic information systems built on clusters do not have the ability to start quickly or migrate services quickly in case of hardware failure. In addition, from an application perspective, how to ensure that application services running on the cluster have a unique, global VIP address (i.e., Virtual IP Address) that does not change due to application service restarts or node migrations within the cluster is a current challenge. Summary of the Invention

[0003] To address the above problems, this invention provides a method for implementing a service VIP based on a Nomad cluster and a method for attaching an application service to a VIP.

[0004] The technical solution of this invention is: a cluster system based on a domestically produced VPX server, comprising three computing modules, each using a domestically produced processor. Each computing module deploys a Nomad server and a Consul server, transforming the computing module into a management node mode. Through a master election mechanism, a "1 master 2 slave" architecture is formed. The Nomad client and Consul client are run on each computing module to transform the computing module into a 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 Nomad clients. The client is responsible for running the tasks assigned to its node. The Consul server and Consul client form a Consul cluster. The Consul cluster is used for service discovery and configuration in distributed systems. The client-server communication mechanism in the Nomad cluster and Consul cluster is RPC. Application services created in the Nomad cluster are automatically registered with the Consul cluster, supporting service discovery.

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

[0006] The MetalLB module is implemented in Go and runs on the Nomad cluster as a Job of type "System" with task-driven "raw_exec" to form a MetalLB service. Each Nomad client node runs this MetalLB service and monitors the application services in the Consul cluster through the Watch method of the local Consul client. This allows the MetalLB service to be aware of the creation, update, and deletion operations of application services in the Consul cluster, thereby providing VIP functionality for the application services.

[0007] The MetalLB module includes four sub-modules: VIP validity determination, attachment, load balancing, and health check. in, The VIP validity check submodule is used to check the legality of the VIP address; The VIP Attach submodule is used to attach a VIP to the active network interface card of the node where the application service is located or the master node. The VIP load balancing submodule is used for multi-replica services; The VIP health check submodule is used to periodically check the health status of VIPs.

[0008] The VIP validity determination submodule includes: First, retrieve the VIP address corresponding to the VIP tag in the Job associated with the application service. Then, determine whether the value is in the IP address pool. If it is not in the pool, indicate that the VIP address is out of range and is therefore invalid. Otherwise, use the Consul client on the local node to retrieve all used service VIP information from the Consul KV 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, check if the IP address can be pinged. If it can be pinged, indicate that the IP address is being used by another application service and is invalid. If it cannot be pinged, follow the retry mechanism and ping it twice more. If it cannot be pinged three times in a row, it means that the VIP is available and the information of the VIP in the KV is deleted. If it does not exist, the IP address is pinged to determine if it is valid. If it is pingable, the IP address is indicated as already in use and therefore invalid. If it is not pingable, the VIP is available.

[0009] The VIP attachment submodule includes: First, a UDP request is sent using the .net base library, and the local IP address is obtained from the returned UDP connection. Second, all network interfaces on the local machine are obtained using the IP command. Then, based on the comparison, the local network interface corresponding to the IP address is determined, i.e., the active network interface corresponding to the IP address. For single-replica application services, after obtaining the active network interface card (NIC) of the node where the application service is located, the VIP attachment submodule attaches the VIP to the active NIC using the IP addr add method. After the addition is completed, the MAC address of the NIC where the VIP is located can be discovered based on the ARP protocol to enable communication. At the same time, the VIP is added to the Consul KV storage to mark that the VIP has been used in the IP address pool. For multi-replica application services, the VIP attachment submodule retrieves all healthy service instances of the service from the Consul cluster based on the name of the application service, sorts them using the sort() function based on the name of the node where the service instance is located, selects the first node in the sequence as the master node, and attaches the VIP to the active network interface card of that node.

[0010] The VIP load balancing submodule includes: When load balancing is detected in the application service label of the Consul cluster, the iptables command and IPVS base library are invoked. Based on the VIP, service port, service type and configuration information of all healthy instances of the service, iptables rules and IPVS rules are created on the VIP attached node. This node is then used as the application service access entry point. User requests are translated through iptables NAT and then distributed to different service replicas based on IPVS rules. That is, they are forwarded to this node or other nodes running the application service for processing, thereby supporting load balancing of multi-replica application services.

[0011] The VIP health monitoring submodule includes two coroutines, among which, Coroutine 1: Periodically checks whether the local Client service is running normally by accessing the healthy interface of the local Consul client. If it fails three times in a row, the local Consul client is determined to be abnormal. Then, the VIP health detection submodule will delete the VIP information that has been added to this node in the memory stored by the VIP attachment submodule. Coroutine 2: Periodically check whether the activated network interface card and Consul KV contain a VIP; First, obtain the VIP information stored in Consul KV: VIP / node / bound service name, filter out the VIP of this node based on the node information, and then check whether the activated network interface card of this node contains the VIP; If it is included, the health check is passed; If not, then further determine whether the VIP corresponding to the service can be pinged: ① If ping fails, reattach the VIP to the active network card on this node, and then update the IPtables and IPVS rules of this node synchronously according to the virtual.ip.slb label of the application service; ② If the ping is successful, the VIP information is deleted from the Consul KV storage; at the same time, the Nomad cluster high availability mechanism is triggered, and the application service is recreated on other healthy nodes according to the original VIP based on the scheduling policy.

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

[0013] The application service attaching VIP method based on domestic VPX servers, employing the aforementioned cluster system based on domestic VPX servers, includes: (1) MetalLB service initialization When the Nomad cluster starts, the MetalLB service performs initialization synchronously. After starting, the MetalLB service obtains the IP address pool of the VIP range value set in the Job, and checks whether the IP address pool exists and whether the start and end values ​​are in the correct format. If it does not exist or the format is incorrect, the startup fails and the service ends. (2) VIP allocation for application services a) The Nomad cluster loads the Job task corresponding to the application service, executes the application service creation process, and confirms the service discovery backend based on the Provider field in the Service field of the application service Job. It also registers the application service in the Consul cluster using the local Consul client. The registration information is the information in the JobService field, including the tag. b) When the MetalLB service detects that an application service has been registered to the Consul cluster in "listening" mode, it reads the Job tag to determine whether the application service has enabled a VIP. If not, it creates one directly. If enabled, it calls the VIP validity judgment module to determine whether the VIP address specified by "virtual.ip.address" is available. If available, it determines the master node based on all healthy instances, adds VIP information to the activated network interface card and KV storage on the master node, and determines whether to start load balancing based on the "virtual.ip.slb" tag. If enabled, it creates Iptables and Ipvs rules to achieve load balancing. (3) VIP health status check for application services The MetalLB service periodically performs health checks on the application service VIP status. If the health status is abnormal, it indicates that the application service has experienced a network failure. The VIP is reattached or the Nomad cluster high availability mechanism is triggered, and the application service is recreated on other healthy nodes according to the original VIP based on the scheduling policy. (4) Application Service VIP Update When Nomad cluster performs application service updates, the MetalLB service checks whether the VIP for the service exists on the local node. If it does not exist, it executes the logic to add the service; if it does exist, it checks whether the VIP function should be disabled after the update. a) If you disable the VIP feature, delete the previously added VIPs, and also delete any existing load balancing rules; b) If the VIP function is not disabled, recalculate the master node based on healthy service instances and determine whether this node is still the master node; ① If this node is no longer the master node, delete the previously added VIP; at the same time, delete any existing load balancing rules as well. ② If the master node remains unchanged, compare whether the value of the VIP has changed after the update; if it has changed, delete the previous VIP and load balancing rule, and then execute the logic to add the service; if the value has not changed, observe whether load balancing is enabled, and if so, update the load balancing rule; if only load balancing is disabled, delete the load balancing rule. (5) Deletion of VIP application service When a Nomad cluster deletes or stops an application service, it removes the service from the Consul cluster. At the same time, the MetalLB service checks whether the VIP of the service exists on the local node. If it does, it deletes the VIP information and load balancing rules from the active network interface card and ConsulKV storage.

[0014] In its operation, this invention builds a Nomad cluster based on domestic VPX servers, enabling hybrid orchestration and full lifecycle management of containerized application services and traditional application services. It supports resource management and high service availability, ensuring the reliable and stable operation of information systems. At the same time, it provides VIP functionality for application services, enabling external clients or application services to access them transparently and seamlessly when application services are migrated. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the Chinese-made VPX server of this invention. Figure 2 This is a schematic diagram illustrating the deployment of the Nomad cluster, Consul cluster, and MetalLB module in this invention. Figure 3 This is a flowchart of the method for attaching a VIP to an application service in this invention. Detailed Implementation

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0017] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0018] This invention provides a cluster system based on a domestically produced VPX server, comprising three computing modules, each using a domestically produced processor. Each computing module deploys a Nomad server and a Consul server, transforming the computing module into a management node mode. Through a master election mechanism, a "1 master 2 slave" architecture is formed. The Nomad client and Consul client are run on each computing module to transform the computing module into a 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 Nomad clients. The client is responsible for running the tasks assigned to its node. The Consul server and Consul client form a Consul cluster. The Consul cluster is used for service discovery and configuration in distributed systems. The client-server communication mechanism in the Nomad cluster and Consul cluster is RPC. Application services created in the Nomad cluster are automatically registered with the Consul cluster, supporting service discovery.

[0019] like Figure 1 As shown, the domestic server adopts the VPX architecture design, which includes three computing modules. Each computing module uses domestic processors such as Phytium, Loongson and Kunpeng, with no less than 8GB of memory, no less than 1TB of disk capacity, and the operating system is NeoKylin / GalaxyKylin server operating system, supporting multiple network cards.

[0020] like Figure 2 As shown, a Nomad cluster is deployed in cluster mode. The three computing modules are deployed with Nomad servers and Consul servers respectively, transforming each computing module into a three-management-node model. A master-slave election mechanism (such as Raft algorithm) is used to form a "1 master 2 slave" architecture, supporting high availability of the management nodes. Simultaneously, Nomad clients and Consul clients run on the three computing modules, transforming each module into a three-computing-node model. This means the computing modules combine management and computing functions and support online dynamic scaling of computing nodes. The client-server communication between the Nomad and Consul clusters uses an RPC mechanism. Application services created on the Nomad cluster are automatically registered with the Consul cluster, supporting service discovery.

[0021] The MetalLB module is implemented in Go and runs as a "System" type job with a "raw_exec" task driver on the Nomad cluster, forming the MetalLB service. Each Nomad client node runs this service, which monitors application services in the Consul cluster via the Watch method of the local Consul client. This allows the service to be aware of application service creation, update, and deletion operations in the Consul cluster, thus providing VIP functionality to application services. The MetalLB service is defined using the HCL format job, as follows: The MetalLB service configures the available VIP address pool using environment variables. The VIP start and end values ​​must be within the same network segment as the physical IP of the compute module, and the VIP specified by the application service must be within this address pool range. The MetalLB service identifies whether an application service needs to configure a VIP and support load balancing functionality through the "virtual.ip.address" and "virtual.ip.slb" tags, as follows: "virtual.ip.address=" is the fixed key of the VIP tag, and IP3 is a variable value, representing the VIP value provided externally when the application service is created; the "virtual.ip.slb" tag indicates that the application service supports load balancing function. This tag must be used in conjunction with the VIP tag and will not work when used alone; if the application service configuration file does not contain "tags" or the "tags" VIP tag, the VIP function will not be provided when the application service is created.

[0022] The Nomad cluster, Consul cluster, and MetalLB module are based on domestic VPX servers. The MetalLB module includes four sub-modules: VIP validity determination, 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 or traditional applications. It adopts a pluggable driver framework to support workload scheduling with multiple driver modes, including containers, native executables, and batch applications, and supports cross-datacenter scheduling to meet the needs of hybrid deployment and management of containerized and traditional applications.

[0024] The core functionality of this cluster is implemented by a single binary program that supports both client and server operating modes. It is fully self-contained, requiring no external services for storage or coordination, and automatically handles application service and node failures.

[0025] Compared to general task orchestration tools such as Kubernetes, this cluster is more lightweight and optimized in terms of system architecture. It cuts off or simplifies unnecessary business designs and functional components, integrates only the necessary and fewer components, supports rapid function integration and component replacement and upgrade, and meets 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. Under the premise of ensuring a highly available architecture, it acts as the "brain" to accept user jobs and delegate tasks to clients. The clients are responsible for running the tasks assigned to their local nodes. The Consul cluster is mainly used for service discovery and configuration in distributed systems. This cluster achieves service discovery functionality through seamless integration with the Nomad cluster. Services running on the Nomad cluster can register themselves with the Consul cluster and store them in the Consul KV store so that other services on the Nomad cluster can discover the services they need to connect to.

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

[0027] The VIP validity check submodule is primarily used to check the legitimacy of VIP addresses. First, it retrieves the VIP address corresponding to the VIP tag in the Job associated with the application service. Then, it checks if this value is within the IP address pool. If it is not in the pool, it indicates that the VIP address is out of range and therefore invalid. Otherwise, it uses the local node's Consul client to retrieve all used service VIP information from the Consul KV storage and compares it with the current service VIP in a loop to determine if 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. If it can be pinged, indicate 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 2 more times. If it cannot be pinged 3 times in a row, it means that the VIP is available and delete the information of the VIP in the KV.

[0029] (2) If it does not exist, determine whether the IP address can be pinged by Ping. If it can be pinged (once), it will indicate that the IP address has been used and is therefore invalid. If it cannot be pinged (once), the VIP is available.

[0030] The VIP Attach 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 via the net library and obtains the local IP address from the returned UDP connection. Second, it retrieves all local NICs using the IP command. Then, based on comparison, it determines the local NIC corresponding to the IP address, i.e., the active NIC. For single-replica application services, after obtaining the active NIC of the node hosting the application service, this module attaches the VIP to the active NIC using the `IP addr add` method. After addition, communication is achieved by discovering the MAC address of the NIC hosting the VIP using the ARP protocol. Simultaneously, the VIP is added to the Consul KV store, marking that the VIP is in use in the IP address pool. For multi-replica application services, this module retrieves all healthy service instances of the service from the Consul cluster based on the service service name. It then sorts the service instances using the `sort()` function based on the node names, 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 primarily used for multi-replica services. Enabling this feature is not recommended for single-replica application services, as there is only one service instance and no other load. For multi-replica application services, when this module detects that an application service in the Consul cluster uses load balancing (Label=LB), it calls iptables commands and the IPVS library. Based on the VIP, service port, service type (TCP / UDP), and configuration information of all healthy instances of the service, it creates iptables rules and IPVS rules on the VIP-attached node (master node). This node becomes the application service access entry point. User requests are translated through iptables NAT and then distributed to different service replicas based on IPVS rules, i.e., forwarded to this node or other nodes running the application service for processing. This supports load balancing for multi-replica application services and achieves service load balancing functionality.

[0032] The VIP health check submodule is mainly used to periodically check the health status of VIPs to ensure that they are available. It is implemented using two coroutines. Coroutine 1: Periodically (default 5 seconds) checks the local Consul client's healthy interface to determine if the local Client service is running normally. If it fails three times consecutively, the local Consul client is considered abnormal. This module then cyclically deletes VIPs already added to the local node from the VIP attachment submodule's memory. On one hand, it uses the `ip addr del` command to delete VIPs on the active network interface; on the other hand, it uses the `iptables` command and the ipvs base library to delete IPtables / IPVS rule information. Coroutine 2: Periodically (default 5 seconds) checks whether the active network interface and Consul KV contain the VIP. First, it retrieves the VIP information stored in the Consul KV: VIP / node / bound service name. Based on the node information, it filters out the VIPs for the local node and then checks whether the active network interface of the local node contains the VIP. a) If it contains the VIP, the health check passes. b) If it does not contain the VIP, it further checks whether the VIP corresponding to the service can be pinged. ① If ping fails, reattach the VIP to the active network card on this node, and then update the IPtables and IPVS rules of this node synchronously according to the virtual.ip.slb label of the application service; ② If a ping is successful, the VIP information is deleted from the Consul KV storage; at the same time, the Nomad cluster high availability mechanism is triggered, and the application service is recreated on other healthy nodes according to the original VIP based on the scheduling policy to ensure the high availability of the application service.

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

[0034] like Figure 3 As shown, the method for attaching VIPs to application services based on domestic VPX servers, using the aforementioned cluster system based on domestic VPX servers, 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 starts, the MetalLB service performs initialization synchronously. After starting, the MetalLB service obtains the IP address pool of the VIP range set in the Job, and checks whether the IP address pool exists and whether the start and end values ​​are in the correct format. If it does not exist or the format is incorrect, the startup fails and the service exits.

[0035] (2) VIP allocation for application services a) The Nomad cluster loads the Job task corresponding to the application service, executes the application service creation process, and confirms the service discovery backend based on the Provider field in the Service field of the application service Job. It then uses the local Consul client to register the application service in the Consul cluster. The registration information is the information in the JobService field, which includes the tag.

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

[0037] (3) VIP health status check for application services The MetalLB service periodically performs health checks on the application service VIP status. If the health status is abnormal, it indicates that the application service has experienced a network failure. The VIP is then reattached or the Nomad cluster high availability mechanism is triggered, and the application service is recreated on another healthy node according to the original VIP, ensuring high availability of the application service.

[0038] (4) Application Service VIP Update When an application service is updated in a Nomad cluster, the MetalLB service checks whether the VIP for that service exists on the local node. If it does not exist, it executes the logic to add the service; otherwise, it checks whether the updated service should disable the VIP function.

[0039] a) If you disable the VIP feature, delete the previously added VIPs, and also delete any existing load balancing rules; b) If the VIP function is not disabled, recalculate the master node based on healthy service instances and determine whether this 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, delete any existing load balancing rules as well.

[0041] ② If the master node remains unchanged, compare whether the value of the VIP has changed after the update. If it has changed, delete the previous VIP and load balancing rule, and then execute the logic to add the service; if the value has not changed, observe whether load balancing is enabled, and if so, update the load balancing rule; if only load balancing is disabled, delete the load balancing rule.

[0042] (5) Deletion of VIP application service When a Nomad cluster deletes or stops an application service, it removes the service from the Consul cluster. At the same time, the MetalLB service checks whether the VIP of the service exists on the local node. If it does, it deletes the VIP information and load balancing rules from the active network interface card and ConsulKV storage.

[0043] In practical use, this invention addresses the need for mixed deployment, orchestration, and management of containerized applications and traditional (binary) applications; it considers the requirement for domestically developed information systems built on clusters in mobile scenarios to have rapid startup and quick service migration in case of hardware failure; it also addresses the need for application services running on the cluster to have a unique, global VIP address that does not change due to application service restarts or node migrations within the cluster, i.e., remains transparent to external clients or services; and it supports this VIP as a service access entry point for multi-replica services to achieve load balancing.

[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 it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A cluster system based on domestically produced VPX servers, comprising three computing modules, each using a domestically produced processor. Its features are, Each computing module deploys a Nomad server and a Consul server, transforming the computing module into a management node mode. Through a master election mechanism, a "1 master 2 slave" architecture is formed. The Nomad client and Consul client are run on each computing module to transform the computing module into a 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 Nomad clients. The client is responsible for running the tasks assigned to its node. The Consul server and Consul client form a Consul cluster. The Consul cluster is used for service discovery and configuration in distributed systems. The client-server communication mechanism in the Nomad cluster and Consul cluster is RPC. Application services created in the Nomad cluster are automatically registered with the Consul cluster, supporting service discovery. It also includes the MetalLB module, which runs on the Nomad cluster to form the MetalLB service; The MetalLB module includes four sub-modules: VIP validity determination, attachment, load balancing, and health check. in, The VIP validity check submodule is used to check the legality of the VIP address; The VIP Attach submodule is used to attach a VIP to the active network interface card of the node where the application service is located or the master node. The VIP load balancing submodule is used for multi-replica services; The VIP health check submodule is used to periodically check the health status of VIPs.

2. The cluster system based on a domestically produced VPX server according to claim 1, characterized in that, The MetalLB module is implemented in Go and runs on the Nomad cluster as a "System" type job with "raw_exec" as the task driver, forming a MetalLB service. Each Nomad client node runs this MetalLB service and monitors the application services in the Consul cluster through the Watch method of the local Consul client. This allows the MetalLB service to be aware of the creation, update, and deletion operations of application services in the Consul cluster, thereby providing VIP functionality for the application services.

3. The homegrown VPX server-based cluster system of claim 1, wherein, The VIP validity determination submodule includes: First, retrieve the VIP address corresponding to the VIP tag in the Job associated with the application service. Then, determine whether the value is in the IP address pool. If it is not in the pool, indicate that the VIP address is out of range and is therefore invalid. Otherwise, use the Consul client on the local node to retrieve all used service VIP information from the Consul KV 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, check if the IP address can be pinged. If it can be pinged, indicate that the IP address is being used by another application service and is invalid. If it cannot be pinged, follow the retry mechanism and ping it twice more. If it cannot be pinged three times in a row, it means that the VIP is available and the information of the VIP in the KV is deleted. If it does not exist, the IP address is pinged to determine if it is valid. If it is pingable, the IP address is indicated as already in use and therefore invalid. If it is not pingable, the VIP is available.

4. The homegrown VPX server-based cluster system of claim 1, wherein, The VIP attachment submodule includes: First, a UDP request is sent using the .net base library, and the local IP address is obtained from the returned UDP connection. Second, all network interfaces on the local machine are obtained using the IP command. Then, based on the comparison, the local network interface corresponding to the IP address is determined, i.e., the active network interface corresponding to the IP address. For single-replica application services, after obtaining the active network interface card (NIC) of the node where the application service is located, the VIP attachment submodule attaches the VIP to the active NIC using the IP addr add method. After the addition is completed, the MAC address of the NIC where the VIP is located can be discovered based on the ARP protocol to enable communication. At the same time, the VIP is added to the Consul KV storage to mark that the VIP has been used in the IP address pool. For multi-replica application services, the VIP attachment submodule retrieves all healthy service instances of the service from the Consul cluster based on the name of the application service, sorts them using the sort() function based on the name of the node where the service instance is located, selects the first node in the sequence as the master node, and attaches the VIP to the active network interface card of that node.

5. The homegrown VPX server-based cluster system of claim 1, wherein, The VIP load balancing submodule includes: When load balancing is detected in the application service label of the Consul cluster, the iptables command and the IPVS base library are invoked. Based on the VIP, service port, service type and configuration information of all healthy instances of the service, iptables rules and IPVS rules are created on the VIP attached node. This node is then used as the application service access entry point. User requests are translated through iptablesNAT and then distributed to different service replicas based on the IPVS rules. That is, they are forwarded to this node or other nodes running the application service for processing, thereby supporting load balancing of multi-replica application services.

6. The homegrown VPX server-based cluster system of claim 1, wherein, The VIP health monitoring submodule includes two coroutines, among which, Coroutine 1: Periodically checks whether the local Client service is running normally by accessing the healthy interface of the local Consul client. If it fails three times in a row, the local Consul client is determined to be abnormal. Then, the VIP health detection submodule will delete the VIP information that has been added to this node in the memory stored by the VIP attachment submodule. Coroutine 2: Periodically check whether the activated network interface card and Consul KV contain a VIP; First, obtain the VIP information stored in Consul KV: VIP / node / bound service name, filter out the VIP of this node based on the node information, and then check whether the activated network interface card of this node contains the VIP; If it is included, the health check is passed; If not, then further determine whether the VIP corresponding to the service can be pinged: ① If ping fails, reattach the VIP to the active network card on this node, and then update the IPtables and IPVS rules of this node synchronously according to the virtual.ip.slb label of the application service; ② If the ping is successful, the VIP information is deleted from the Consul KV storage; at the same time, the Nomad cluster high availability mechanism is triggered, and the application service is recreated on other healthy nodes according to the original VIP based on the scheduling policy.

7. The homegrown VPX server-based cluster system of claim 1, wherein, It also includes other computing modules, Run the Nomad client and Consul client on the other computing modules respectively to convert the computing modules into computing node mode.

8. A method for attaching VIPs to application services based on domestically produced VPX servers, employing a cluster system based on domestically produced VPX servers as described in any one of claims 1-7, characterized in that... include: (1) MetalLB service initialization When the Nomad cluster starts, the MetalLB service performs initialization synchronously. After starting, the MetalLB service obtains the IP address pool of the VIP range value set in the Job, and checks whether the IP address pool exists and whether the start and end values ​​are in the correct format. If it does not exist or the format is incorrect, the startup fails and the service ends. (2) VIP allocation for application services a) The Nomad cluster loads the Job task corresponding to the application service, executes the application service creation process, and confirms the service discovery backend based on the Provider field in the Service field of the application service Job. It also registers the application service in the Consul cluster using the local Consul client. The registration information is the information in the JobService field, including the tag. b) When the MetalLB service detects that an application service has been registered to the Consul cluster based on the "listening" mode, it reads the Job tag to determine whether the application service has enabled VIP; If not enabled, it will be created directly; If enabled, the VIP validity determination module is called to determine whether the VIP address specified by "virtual.ip.address" is available. If available, the master node is determined based on all healthy instances. The VIP information is added to the activated network interface card and KV storage on the master node. The load balancing is then determined based on the "virtual.ip.slb" label. If enabled, Iptables and Ipvs rules are created to achieve load balancing. (3) VIP health status check for application services The MetalLB service periodically performs health checks on the application service VIP status. If the health status is abnormal, it indicates that the application service has experienced a network failure. The VIP is reattached or the Nomad cluster high availability mechanism is triggered, and the application service is recreated on other healthy nodes according to the original VIP based on the scheduling policy. (4) Application Service VIP Update When Nomad cluster performs application service updates, the MetalLB service checks whether the VIP for the service exists on the local node. If it does not exist, it executes the logic to add the service; if it does exist, it checks whether the VIP function should be disabled after the update. a) If you disable the VIP feature, delete the previously added VIPs, and also delete any existing load balancing rules; b) If the VIP function is not disabled, recalculate the master node based on healthy service instances and determine whether this node is still the master node; ① If this node is no longer the master node, delete the previously added VIP; at the same time, delete any existing load balancing rules as well. ② If the master node remains unchanged, compare whether the value of the VIP has changed after the update; if it has changed, delete the previous VIP and load balancing rule, and then execute the logic to add the service. If the value does not change, observe whether load balancing is enabled. If it is enabled, update the load balancing rules. If only load balancing is disabled, delete the load balancing rules. (5) Deletion of VIP application service When a Nomad cluster deletes or stops an application service, it removes the service from the Consul cluster. At the same time, the MetalLB service checks whether the VIP of the service exists on the local node. If it does, it deletes the VIP information and load balancing rules from the active network interface card and Consul KV storage.

Images