Available area traffic switching method and device, equipment, storage medium and program product

Abstract

The invention discloses an available area flow switching method, device and equipment, a storage medium and a program product, and the method comprises the steps: obtaining the operation state data of each available area deployed by a current service during the service operation period of an available area service system; wherein each service applies for a virtual IP address in each available area deployed by the service, and the virtual IP address and the unified access domain name of the service have an association relationship; determining the health condition of each available area according to the running state data; and when the health condition of any target available area meets a preset traffic switching condition, switching the traffic accessing the target available area to the health available area with the association relationship. By adopting the embodiment of the invention, the multi-dimensional state of the cluster can be monitored in real time, faults and health hidden dangers can be accurately identified, cross-available-area flow switching can be quickly completed, the fault recovery time can be shortened, and continuous and stable operation of services can be ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of cloud computing, and in particular to an availability zone traffic switching method, device, equipment, storage medium and program product. BACKGROUND

[0002] Cloud services refer to various applications and related business processes deployed in a cloud computing platform to provide access services for users through a network. Existing cloud services are basically deployed on a Kubernetes (container orchestration engine, K8s for short) cluster after containerization, and are deployed based on a shared K8s cluster. The services are mounted on a load balancer to achieve high-performance forwarding. Multiple availability zone networks are interconnected through a DCI (Data Center Interconnect) router. Multiple availability zones expose the same VIP (Virtual IP Address) to the outside through a load balancing service, and traffic is preferentially accessed in the availability zone. When the availability zone 1 fails and the VIP drainage is abnormal, the traffic is drained to the availability zone 2 through the DCI router.

[0003] However, the high availability of the entire cluster completely depends on the BGP (Border Gateway Protocol) and ECMP (Equal-Cost Multi-Path) network protocols, and the BGP protocol can only ensure network-level connectivity and cannot deeply check the real health status of the backend service. Therefore, even if the load balancing server cannot provide services due to performance bottlenecks or program crashes, the BGP will still consider it good and continue to forward traffic, causing user requests to be directed to a faulty node, resulting in problems such as access timeout, page loading failure, business operation lag, and transaction failure. SUMMARY

[0004] The purpose of the embodiments of the present application is to provide an availability zone traffic switching method, device, equipment, storage medium and program product, which can monitor the multi-dimensional state of the cluster in real time, accurately identify faults and health hazards, quickly complete cross-availability zone traffic switching and shorten the fault recovery time, and ensure the continuous and stable operation of the business.

[0005] To achieve the above-mentioned purpose, the embodiments of the present application provide an availability zone traffic switching method applied to an availability zone business system, the method comprising: During the operation of the business, obtaining running state data of each availability zone in which the current business is deployed; wherein each business applies for a virtual IP address in each availability zone in which it is deployed, and the virtual IP address has an association relationship with the uniform access domain name of the business; determining the health condition of each availability zone according to the running state data; When the health condition of any target availability zone satisfies a preset traffic switching condition, the traffic accessing the target availability zone is switched to a healthy availability zone having an association relationship.

[0006] As an improvement of the above scheme, the running state data comprises at least one of a performance index, a memory state, a network quality parameter and health check data.

[0007] As an improvement of the above scheme, the method further comprises: The traffic switching condition comprises at least one of: In the memory state, the available space of the disk of the availability zone is lower than a preset disk threshold; or, the memory leakage amount of the availability zone reaches a preset leakage threshold, and the remaining available memory is lower than a preset memory threshold; In the performance index, the CPU usage rate and / or the memory usage rate of the availability zone reaches a preset performance threshold; In the network quality parameter, the network quality score of the availability zone is lower than a preset network score threshold; In the health check data, the health check result of the availability zone satisfies an abnormality determination criterion.

[0008] As an improvement of the above scheme, a K8s cluster is deployed in the availability zone business system; wherein, the business is deployed in the K8s cluster after being containerized.

[0009] As an improvement of the above scheme, a load balancer is deployed in the availability zone business system; wherein, the load balancer provides at least one of the following services: Configuring four-layer load balancing for underlying businesses; Configuring four-layer plus seven-layer load balancing for console businesses, wherein, the seven-layer load balancing exposes the routing forwarding rule of the business to external access through the entrance of the K8s cluster.

[0010] As an improvement of the above scheme, the load balancer is determined according to the cluster capacity evaluated according to its performance baseline and accessed business, and is deployed in a plurality of availability zones in a clustered manner; wherein, each business applies for a virtual IP address in each availability zone where it is deployed through the four-layer load balancing of the availability zone.

[0011] To achieve the above object, an embodiment of the present application further provides an availability zone traffic switching device, comprising: A running state data acquisition module, configured to acquire running state data of each availability zone where a current business is deployed during business running; wherein, each business applies for a virtual IP address in each availability zone where it is deployed, and the virtual IP address has an association relationship with a uniform access domain name of the business; a health condition determining module configured to determine a health condition of each available zone according to the running state data; a flow switching module configured to switch flow accessing a target available zone to a healthy available zone having a correlation relationship when the health condition of the target available zone meets a preset flow switching condition.

[0012] To achieve the above object, the embodiment of the present application further provides an available zone flow switching device, comprising a processor, a memory and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to realize the available zone flow switching method according to any one of the above embodiments.

[0013] To achieve the above object, the embodiment of the present application further provides a computer readable storage medium, comprising a stored computer program, wherein the computer readable storage medium controls a device where the computer readable storage medium is located to execute the available zone flow switching method according to any one of the above embodiments when the computer program runs.

[0014] To achieve the above object, the embodiment of the present application further provides a computer program product, comprising computer instructions, wherein the computer instructions are executed by a processor to realize the available zone flow switching method according to any one of the above embodiments.

[0015] Compared with the prior art, the available zone flow switching method, device, equipment, storage medium and program product disclosed by the present application can monitor the multi-dimensional state of a cluster in real time, accurately identify faults and health hazards, quickly complete cross-available zone flow switching and shorten the fault recovery time, and guarantee the continuous and stable operation of a business. In addition, by dynamically monitoring the running state data, the limitation of traditional network protocols that can only detect network connectivity is broken, the resource, performance and network state of an available zone can be comprehensively perceived, the fault or sub-health state can be accurately identified, the problems of access timeout and business lag caused by flow flowing to an abnormal node can be avoided, and the reliability of business access can be greatly improved. At the same time, with the help of the preset correlation relationship, the flow can be quickly and directly switched, the flow of an abnormal available zone can be seamlessly migrated to a healthy available zone without manual intervention, the business continuity is guaranteed, the flow management logic of a multi-available zone business is simplified, the operation and maintenance cost is reduced, and the high-availability business demand of multi-available zone deployment in a cloud computing environment is adapted. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is an architecture diagram of an available zone business system provided by the embodiment of the present application; Figure 2 is a flowchart of an available zone flow switching method provided by the embodiment of the present application; Figure 3This is a structural block diagram of an availability zone traffic switching device provided in an embodiment of the present invention; Figure 4 This is a structural block diagram of an availability zone traffic switching device provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] See Figure 1 , Figure 1 This is an architecture diagram of the availability zone service system provided in this embodiment of the invention. The availability zone service system includes a K8s cluster, a load balancer cluster deployed in multiple availability zones, a dual-center gateway, and an eBPF monitoring and diagnostic module. The components and their interaction logic are as follows: 1. A Kubernetes (K8s) cluster is deployed in the availability zone service system; wherein, the service is containerized and deployed in the K8s cluster. For example, after being containerized, the service is deployed in the K8s cluster in the form of Pod (the smallest deployment unit in the K8s cluster), and the Pod has replicas in both availability zone 1 and availability zone 2 (each availability zone in the figure contains multiple Pods), thereby achieving high availability deployment of the service across availability zones.

[0019] 2. A load balancer is deployed in the availability zone service system; wherein the load balancer provides at least one of the following services: configuring layer 4 load balancing for underlying services; configuring layer 4 plus layer 7 load balancing for console services, wherein the layer 7 load balancer exposes the routing and forwarding rules of the services to external access through the entry point of the K8s cluster.

[0020] It's important to note that considering the native NodePort network access mode of Kubernetes and the load capacity of the kernel LVS (Linux Virtual Server), there is a 20% performance penalty, resulting in poor forwarding performance and high latency for business access. Therefore, for underlying business applications, a unified Layer 4 load balancing interface is provided, while for console applications, a Layer 4 plus Layer 7 load balancing interface is provided. Furthermore, the routing and forwarding rules of the business are exposed to the load balancer via Kubernetes ingress. Layer 4 load balancing and Layer 7 load balancing are two load balancing technologies based on the OSI (Open Systems Interconnection) network model. The core difference lies in the basis and processing capacity of traffic forwarding. Layer 4 load balancing corresponds to the transport layer (Layer 4) of the OSI model, forwarding traffic based on IP address and port number. Layer 7 load balancing corresponds to the application layer (Layer 7) of the OSI model, forwarding traffic based on application layer protocol content.

[0021] For example, a load balancer cluster is deployed in the availability zone service system. The cluster capacity is determined based on the load balancer performance baseline, the bandwidth of the access services, and the total access volume, and is deployed in a cluster in availability zone 1 and availability zone 2 (each availability zone in the figure contains a layer 4 load balancer and a layer 7 load balancer). The load balancer provides the following services: 2.1) Configure Layer 4 load balancing for the underlying services; For example, underlying services typically refer to systems or services that do not directly face end users but provide core support and foundational capabilities for upper-layer applications or other services. They usually run in the background, handling core tasks such as data storage, computation, message passing, and resource management. Examples include database services, caching services, message queue services, and storage services. These services typically have extremely high requirements for network latency, throughput, and stability, but lower requirements for the complex routing capabilities of the HTTP (Hypertext Transfer Protocol) protocol. Therefore, Layer 4 load balancing is suitable for traffic distribution to achieve optimal performance.

[0022] 2.1) Configure Layer 4 and Layer 7 load balancing for console services; For example, console services typically refer to interactive interfaces or applications that directly target end users (including system administrators, operations personnel, or ordinary users). They provide a visual entry point for operation, which users interact with through a browser or dedicated client. For example, access traffic could be via HTTP, HTTPS (Hypertext Transfer Protocol Secure), or WebSocket. Layer 7 load balancing exposes the service's routing and forwarding rules to external access through the Kubernetes cluster's ingress, enabling fine-grained traffic routing based on domain names and URLs (Uniform Resource Locators).

[0023] At the same time, each service applies for a virtual IP address through the Layer 4 load balancer of each availability zone in its deployment, as shown in the figure, availability zone 1 corresponds to VIP1 and availability zone 2 corresponds to VIP2, and establishes a relationship between the unified access domain name of the service and the VIP of each availability zone.

[0024] Furthermore, the load balancer's cluster capacity is determined based on its performance baseline and the access services, and it is deployed in a cluster across multiple availability zones.

[0025] For example, the performance baseline refers to the maximum performance metric that a single load balancer device or node can stably handle under a specific environment, such as the maximum number of concurrent connections, connections per second (CPS), and packets per second (PPS). Access service evaluation refers to analyzing the characteristics of service traffic that will pass through the load balancer, including peak traffic, average traffic, traffic type (short or long connections), and service level agreement (SLA).

[0026] By comparing the results of the access service assessment with the performance baseline, the required number of load balancer nodes can be calculated to meet the business demand, i.e., the cluster capacity. For example, if the assessment shows that the business needs to handle 1 million concurrent connections during peak periods, and the performance baseline of a single load balancer is 200,000 concurrent connections, then to meet the demand and leave some redundancy, the cluster capacity might be determined to be 6 nodes. These 6 load balancer nodes form a cluster, which provides services as a whole, sharing the same or a set of virtual IP addresses. Multi-AZ Deployment: To ensure the high availability of the load balancing service itself, these 6 nodes are not deployed in the same physical data center (i.e., the same availability zone), but are distributed across multiple independent availability zones. For example, 3 nodes are deployed in availability zone A and 3 in availability zone B. If one availability zone becomes unavailable due to power outages, network failures, or other reasons, the load balancer nodes in the other availability zone will immediately take over all traffic, ensuring uninterrupted service.

[0027] Furthermore, each service requests a virtual IP address in each availability zone it deploys in, through the layer 4 load balancer of the availability zone.

[0028] For example, suppose there is a user order system service. For high availability, the application server for this service is deployed in multiple availability zones, such as Availability Zone A and Availability Zone B. In Availability Zone A, a VIP is assigned to the user order system service, for example, 10.0.0.10. This VIP is provided by the load balancer cluster in Availability Zone A. All traffic destined for 10.0.0.10 will be received by the load balancer cluster in Availability Zone A and forwarded to the user order system application server deployed in Availability Zone A. Similarly, in Availability Zone B, a VIP is also assigned to it, for example, 10.0.0.11. This VIP is provided by the load balancer cluster in Availability Zone B. All traffic destined for 10.0.0.11 will be received by the load balancer cluster in Availability Zone B and forwarded to the user order system application server deployed in Availability Zone B.

[0029] 3. The system includes a dual-center gateway. When a user initiates a request through a domain name, the dual-center gateway will resolve the domain name and forward the request to the corresponding VIP in the availability zone according to the current health status of the availability zone. For example, in the figure, after the user request is resolved by the dual-center gateway, it can be routed to VIP1 in availability zone 1 or VIP2 in availability zone 2.

[0030] 4. Each availability zone deploys an eBPF (extended Berkeley Packet Filter) monitoring and diagnostic module, which is associated with an eBPF data aggregation unit. Simultaneously, the health check of the load balancer cluster involves three layers of logic (there is interaction between the Layer 4 and Layer 7 load balancers in each availability zone in the diagram): the eBPF monitoring and diagnostic module probes the health status of the Layer 4 load balancer; the Layer 4 load balancer probes the health status of the Layer 7 load balancer; and the Layer 7 load balancer probes the health status of the service backend Pods. The above health check data is reported to the eBPF monitoring and diagnostic module, which then correlates and analyzes the Layer 4 and Layer 7 health check data to ultimately assess the health status of each availability zone.

[0031] For example, eBPF is deployed on a load balancer server, primarily collecting information including performance data, disk memory information, network quality, and health checks. Furthermore, based on eBPF, data collection can be dynamically extended without restarting, modifying kernel code, or loading kernel modules. The eBPF data collection process includes: 1) Write eBPF code based on the data to be collected, and compile the code into eBPF bytecode; 2) Load the eBPF bytecode into the kernel using the syscall system call of BPF; 3) The kernel performs security checks on the eBPF bytecode and then compiles it into native machine code; 4) Attach eBPF programs to endpoints, such as system calls, function entry / exit, kernel tracepoints, network events, etc. 5) When the eBPF program on the connection point is triggered by an event, the callback function is called to run the eBPF program to collect data.

[0032] This architecture enables containerized cross-region deployment of services through a Kubernetes cluster, combined with the clustered deployment of a tiered load balancer and a VIP association mechanism, and further enhanced by the end-to-end health monitoring and diagnostics module of eBPF, ultimately achieving intelligent switching of service traffic across multiple availability zones and ensuring service continuity.

[0033] In this embodiment of the invention, a highly automated, highly available, and elastically scalable multi-availability zone business system is constructed by containerizing and deploying business applications in a Kubernetes cluster, combined with the clustered deployment of a layered load balancer. This allows the entire business system to enjoy the agility brought by containerization while possessing powerful traffic management, fault isolation, and disaster recovery capabilities. The system can intelligently perceive the health status of each availability zone and seamlessly redirect traffic to healthy availability zones when necessary by switching VIPs, thereby maximizing the continuity and stability of business operations, improving user experience, and enhancing overall system reliability. The Kubernetes cluster provides powerful container orchestration capabilities, ensuring flexibility and efficiency in business deployment and scaling. Simultaneously, targeted Layer 4 or Layer 4 plus Layer 7 load balancing services are configured for different types of business (underlying business and console business), and routing rules are exposed through the Kubernetes ingress, enabling fine-grained and efficient management of external traffic. This layered load balancing architecture not only optimizes traffic forwarding paths but also lays the foundation for subsequent health checks and traffic switching. Furthermore, the load balancer itself performs cluster capacity assessment and cross-region deployment based on performance baselines and traffic volume, and applies for independent virtual IP addresses for each service in each availability zone. These designs ensure the high availability and scalability of the load balancing service itself, avoid single points of failure, and provide the necessary network foundation for achieving availability zone-based traffic switching.

[0034] See Figure 2 , Figure 2 This is a flowchart of an availability zone traffic switching method provided by an embodiment of the present invention. The availability zone traffic switching method is applied to an availability zone business system, and the method includes steps S1 to S3.

[0035] S1. During business operation, obtain the operating status data of each availability zone where the current business is deployed; wherein, each business has applied for a virtual IP address in each availability zone where it is deployed, and the virtual IP address is associated with the unified access domain name of the business.

[0036] For example, operational status data indicates the real-time health status and operational load of an availability zone. During business operations, continuously or periodically monitoring and acquiring operational status data for each availability zone where the current business is deployed is crucial for real-time understanding of the health status and service capabilities of each availability zone. This is the foundation and prerequisite for intelligent traffic switching. Only by acquiring this data in a timely and accurate manner can a rapid judgment be made and traffic switching triggered when an availability zone experiences performance degradation, resource shortages, network anomalies, or service failures. This seamlessly redirects traffic accessing the abnormal availability zone to other healthy availability zones, thereby ensuring business continuity, stability, and high availability, and avoiding or reducing service interruptions or user experience degradation caused by single points of failure or localized problems. For example...Figure 1 The eBPF monitoring and diagnostic module is responsible for continuously collecting and summarizing the operational status data of Availability Zone 1 and Availability Zone 2, and performing analysis and diagnosis.

[0037] Furthermore, the operational status data includes at least one of performance metrics, memory status, network quality parameters, and health check data.

[0038] For example, the performance metrics can be CPU utilization, memory utilization, disk I / O, network throughput, etc., reflecting the server's workload. The memory status can be remaining memory size, available disk space, number of active connections, etc., reflecting the remaining capacity of system resources. Network quality parameters can be network latency (Round-Trip Time, RTT), packet loss rate, bandwidth utilization, etc., reflecting the communication quality of network links. The health check data includes at least one health check result from Layer 4 load balancing, Layer 7 load balancing, and business backend services. Layer 4 and Layer 7 load balancing have been explained above and will not be repeated here. Business backend services refer to the underlying applications or service clusters that directly carry core business logic and provide specific business functions. They are the traffic forwarding targets of the load balancer and are the core execution units of the business system. They do not directly face the access point of end users but receive and process requests through Layer 4 or Layer 7 load balancers. In this invention, the business backend services are containerized and deployed in the form of Pods in a K8s cluster, with replicas deployed in multiple availability zones. These include underlying business services (such as database clusters, cache clusters, message queue clusters, data computing clusters, etc.) and console business services (such as order management services, user management services, operation backend services, etc.). Their health status directly determines the availability of the business. Therefore, a Layer 7 load balancer is required to perform real-time health checks to ensure that traffic is forwarded only to normally functioning service instances.

[0039] In this embodiment of the invention, performance indicators can accurately pinpoint performance bottlenecks such as excessive CPU utilization and decreased processing efficiency; memory status can promptly detect resource risks such as memory leaks and insufficient available memory; and network quality parameters can effectively detect network problems such as abnormal network latency and packet loss rates. This data collection design ensures both comprehensive monitoring dimensions and flexibility in practical applications, avoiding misjudgments or omissions caused by single-dimensional monitoring. It provides reliable data support for accurately determining the health status of availability zones, thereby ensuring the scientific and timely nature of traffic switching decisions and guaranteeing the stability and continuity of multi-availability zone service operations from the data source.

[0040] S2. Determine the health status of each availability zone based on the aforementioned operational status data.

[0041] For example, health determination is performed on various indicators in the operational status data through the corresponding eBPF collection and analysis logic.

[0042] For performance metrics, the performance health of the load balancing service is analyzed based on data collected by the eBPF Profile (performance analyzer). The eBPF program periodically samples each online CPU of the load balancing forwarding service through perf events, capturing the execution flow, stack backtrace information, and execution time of kernel and user-space functions. After processing by the user-space program, this data is reported to the eBPF monitoring and diagnostic module. For example, the kernel-space eBPF program uses perf events to periodically sample the stacks of load balancing-related processes, thereby capturing the program's execution flow and storing the data in a RingBuffer for the user-space eBPF profile program to read and process. The user-space eBPF program is responsible for setting perf events for each online CPU in the load balancing process and loading the eBPF program onto the load balancing forwarding performance events. It also displays and processes the stack backtrace information collected by the eBPF kernel program and sends relevant performance data to the eBPF monitoring and diagnostic module. If the analysis finds that CPU utilization remains consistently high, the execution latency of core forwarding functions exceeds a preset threshold, or there is a performance bottleneck caused by function execution blocking, then the performance metrics of the availability zone are determined to be substandard, and its health status is abnormal.

[0043] For memory status, the health of resources is assessed using monitoring data from eBPF memleak (a memory leak detection tool). eBPF memleak tracks memory allocation and deallocation requests for the load balancing service, collects the call stack for each allocation, and records important information such as the caller's process PID (Process IDentifier), the allocated memory address, and the size of the allocated memory. This summary indicates which call stacks performed allocation but were not subsequently deallocated, and records the size and quantity of this undealt memory. This helps identify the source of memory leaks in the load balancing service. For example, this tool uses uprobe (a technique that inserts probe points at the entry and exit points of user-space functions) to track the entry and exit events of user-space memory allocation functions such as malloc (memory allocation) and calloc (contiguous allocation). It also monitors calls to kernel-space functions such as kmalloc (kernel memory allocation) using tracepoints (static probes pre-defined in the kernel for tracking kernel events). It can dynamically track specific events during kernel runtime without recompiling the kernel or loading kernel modules. It collects information such as the process PID, memory address, allocation size, and call stack for each memory allocation. The eBPF monitoring and diagnostic module analyzes this data to identify call stacks of unreleased memory, count the size and quantity of unreleased memory, and if a clear memory leak trend is detected and the remaining available memory is below a preset threshold, the memory status of that availability zone is determined to be abnormal.

[0044] For network quality parameters, network health is assessed based on TCP (Transmission Control Protocol) connection data collected by the eBPF tcprtt (TCP Round Trip Time Analysis Tool). First, a hash-type eBPF map (eBPF mapping for kernel-user space data sharing) is defined to store RTT statistics. Next, an eBPF program is defined, which is called every time the kernel processes TCP packet reception. In this program, TCP connections are first filtered based on filtering conditions (source / destination IP address and port). If the conditions are met, the corresponding key (source IP, destination IP, or 0) is selected according to the set parameters. Then, the corresponding histogram (used for statistical data distribution) is looked up or initialized in the map. Next, the srtt_us (smoothed round-trip time in microseconds) field of the TCP connection is read. This field represents the smoothed RTT value in microseconds. Then, this RTT value is converted to logarithmic form and stored as a slot in the histogram. If the `show_ext` parameter (a parameter of the `tcprtt` tool used to control the output of more detailed connection information to aid analysis) is set, the RTT value and counter will also be accumulated into the `latency` and `cnt` fields of the histogram. `tcprtt` is mounted to the kernel-mode `tcp_rcv_established` function, which is the main function in the kernel for handling TCP data reception and is called when the TCP connection is in the `ESTABLISHED` state. When a TCP connection is established, `tcprtt` automatically selects the appropriate execution function based on the current system status. Within the execution function, `tcprtt` collects basic information about the TCP connection, such as source address, destination address, source port, destination port, and latency, and updates this information in the BPF map. After execution, `tcprtt` sends the collected information to the eBPF monitoring and diagnostic module through a user-mode eBPF program. Through this processing, the RTT of each TCP connection can be statistically analyzed, thereby better evaluating the network quality of the load balancing service. If statistical analysis shows that the average / peak RTT of each TCP connection exceeds the preset network threshold, or that abnormal packet loss rate or bandwidth usage leads to a decline in network transmission quality, then the network quality parameters of the availability zone are deemed to be substandard.

[0045] Load balancer health check data is generated automatically by periodically sending requests to backend services to test their operational status and determining the availability of backend servers. Load balancers only forward traffic to healthy backend services, avoiding those in an abnormal state, thus improving business reliability. When an abnormal backend service recovers to a healthy state, the elastic load balancer will forward traffic to that service normally. Load balancer health checks include three aspects: health checks by the eBPF monitoring and diagnostic module probing Layer 4 load balancers, health checks by Layer 4 load balancers probing Layer 7 load balancers, and health checks by Layer 7 load balancers probing business backend services. Finally, the load balancer health checks report the collected Layer 4 and Layer 7 health check data to the eBPF monitoring and diagnostic module, which then correlates the Layer 4 and Layer 7 health check data. Through these three layers of health checks, the system can comprehensively monitor the health status of the entire service chain from top to bottom. If a problem occurs in any link, it can be detected and addressed promptly (such as switching traffic or issuing alerts), thereby maximizing service availability.

[0046] For example, the present invention provides examples of the above three health checks: 1) The health check of a Layer 4 load balancer is a monitoring of the Layer 4 load balancer's own status. This is usually not done by the Layer 4 load balancer itself, but by the eBPF monitoring and diagnostic module. The eBPF monitoring and diagnostic module will periodically attempt to establish a connection with the service port of the Layer 4 load balancer. If the connection is successful, it means that the load balancer node is active. Alternatively, it will send an ICMP Echo request (i.e., Ping command) to the IP address of the Layer 4 load balancer to check its network layer reachability. If the probe fails consecutively within a certain period of time (e.g., 3 times) (connection timeout or different Ping results), it is considered that the Layer 4 load balancer node or its availability zone is abnormal. 2) Layer 4 load balancers probe the health checks of Layer 7 load balancers. This layer check occurs within the load balancer cluster and is initiated by the Layer 4 load balancer to confirm whether its backend Layer 7 load balancers are working properly. The Layer 4 load balancer periodically sends an HTTP GET or HEAD request to a preset health check URL of the Layer 7 load balancer. If the received HTTP response code is normal, the load balancer is considered healthy; otherwise, it is considered unhealthy. 3) Layer 7 load balancer detects the health checks of the business backend services. This is the innermost check, which is initiated by the Layer 7 load balancer to directly detect whether the business containers (Pods) behind them are providing services normally. The Layer 7 load balancer sends a request to the health check interface of each business Pod. This interface is usually provided by the business application itself and is used to report the internal status of the application. Then, it relies on the HTTP response code to determine whether it is healthy.

[0047] In this embodiment of the invention, through comprehensive analysis and quantitative evaluation of the above four types of indicators, the health status of each availability zone is finally determined, providing an accurate basis for subsequent traffic switching decisions.

[0048] S3. When the health status of any target availability zone meets the preset traffic switching conditions, the traffic accessing the target availability zone will be switched to a healthy availability zone with an associated relationship.

[0049] For example, the traffic switching conditions include at least one of the following: 1) In the memory state, the available disk space of the availability zone is lower than a preset disk threshold; or, the memory leakage of the availability zone reaches a preset leakage threshold, and the remaining available memory is lower than a preset memory threshold. For example, when an abnormality is detected in the disk space of Availability Zone 1, an Availability Zone switch is immediately completed, the VIP address of Availability Zone 2 is returned to the dual-center gateway, and an alarm message is generated. Alternatively, when a memory leak is diagnosed in Availability Zone 1 and the memory is below the threshold, an Availability Zone switch is immediately completed, and the VIP address of Availability Zone 2 is returned to the dual-center gateway. If memory leaks are detected in multiple Availability Zones, the overall health score of the cluster is determined based on a weighted calculation of at least two of the following operational status data: performance indicators, memory status, and network quality parameters. Traffic is then switched to the Availability Zone with the higher score, while memory allocation and release requests are tracked, and the call stack for each allocation is collected. This information can then be analyzed to identify call stacks where memory allocation was performed but release was not, thus pinpointing the source of the memory leak.

[0050] 2) Among the performance metrics, the CPU utilization and / or memory utilization of the availability zone reach the preset performance threshold; For example, if the CPU utilization of Availability Zone 1 exceeds 85% for 5 consecutive minutes, or the memory utilization exceeds 90% for 5 consecutive minutes (these percentages are the preset performance thresholds), the system determines that the performance indicators of that Availability Zone have met the conditions to trigger traffic switching. At this time, the system will immediately initiate the traffic switching process, switching user requests originally directed to Availability Zone 1 to Availability Zone 2, and returning the VIP address of Availability Zone 2 to the dual-center gateway. Simultaneously, an alarm message will be generated to notify the operations and maintenance personnel. Furthermore, the system will automatically trace the operation status and performance bottlenecks of the load balancer program. For example, it will use data such as the execution time and call stack of kernel functions and user-space functions captured by the eBPF Profile analysis tool to help development and operations personnel perform cluster performance analysis and locate the specific reasons for excessive CPU or memory utilization, such as abnormal consumption of a certain application or improper configuration.

[0051] 3) Among the network quality parameters, the network quality score of the availability zone is lower than the preset network score threshold; For example, if the network quality score of Availability Zone 1 is diagnosed as being lower than the set standard threshold (e.g., the maximum network quality score is 100, the preset threshold is 80, and Availability Zone 1's current network quality score is 75), then the network quality parameters of that Availability Zone are determined to be unsatisfactory. In this case, the system will immediately perform an Availability Zone switchover, returning the VIP address of Availability Zone 2 to the dual-center gateway to ensure that user requests can be transmitted through a healthy network link, while simultaneously generating an alarm message. For instance, the network quality score integrates multiple network metrics, such as the average RTT (Round-Trip Time) of TCP connections collected by the eBPF tcprtt tool, packet loss rate, and bandwidth fluctuations. If a significant increase in the average RTT is detected in the network link from Availability Zone 1 to the user end or to the backend data center, such as from the normal 10ms to 100ms, or if persistent packet loss occurs, such as a packet loss rate exceeding 10%, these will all lead to a decrease in the network quality score. When the score is lower than the preset threshold, it means that the network quality of that Availability Zone may affect user experience or the normal operation of business, thus requiring a traffic switchover.

[0052] 4) In the health check data, the health check results of the availability zone meet the anomaly judgment criteria; the anomaly judgment criteria are at least one of the following: a. Within a preset time window, the number of failures of the health check reaches a preset threshold; b. In any health check stage, the proportion of backend service instances in an abnormal state reaches or exceeds a preset proportion threshold.

[0053] For example, when an abnormal health check status is detected in an availability zone, the health check includes the eBPF monitoring and diagnostic module's health check of the Layer 4 load balancer, the Layer 4 load balancer's check of the Layer 7 load balancer, and the Layer 7 load balancer's health check of the service backend itself. The impact of the abnormal status on traffic forwarding is assessed. For example, when the number of health check failures reaches 3, or when more than 50% of the services in the backend of the health check are abnormal, the health check result of availability zone 1 is determined to meet the abnormal judgment criteria. At this time, the availability zone switch is immediately completed, the VIP address of availability zone 2 is returned to the dual-center gateway, alarm information is generated, and the network connectivity and service availability of each stage of abnormal health checks are traced and analyzed to facilitate quick tracing of the source of the abnormality.

[0054] In this embodiment of the invention, the availability zone service system monitors the multi-dimensional status of the cluster in real time, accurately identifies faults and potential health issues, quickly completes cross-availability zone traffic switching, and shortens fault recovery time, ensuring continuous and stable service operation. Furthermore, by dynamically monitoring operational status data, it overcomes the limitations of traditional network protocols that only detect network connectivity. It can comprehensively perceive the resources, performance, and network status of the availability zone, accurately identify faults or sub-health states, and avoid access timeouts and service interruptions caused by traffic flowing to abnormal nodes, significantly improving the reliability of service access. Simultaneously, by leveraging preset associations, it achieves rapid targeted traffic switching, seamlessly migrating traffic from abnormal availability zones to healthy availability zones without manual intervention, ensuring service continuity. It also simplifies the traffic management logic for multi-availability zone services, reduces operational costs, and adapts to the high-availability service requirements of multi-availability zone deployments in cloud computing environments.

[0055] See Figure 3 , Figure 3 This is a structural block diagram of an availability zone traffic switching device 100 provided in an embodiment of the present invention, applied to an availability zone service system. The availability zone traffic switching device 100 includes: The operation status data acquisition module 11 is used to acquire the operation status data of each availability zone where the current service is deployed during the operation of the service; wherein, each service applies for a virtual IP address in each availability zone where it is deployed, and the virtual IP address is associated with the unified access domain name of the service; Health status determination module 12 is used to determine the health status of each availability zone based on the operating status data; The traffic switching module 13 is used to switch traffic accessing the target availability zone to a healthy availability zone with which there is a relationship when the health status of any target availability zone meets the preset traffic switching conditions.

[0056] It is worth noting that the working process of each module in the availability zone traffic switching device 100 described in the embodiments of the present invention can refer to the working process of the availability zone traffic switching method described in the above embodiments, and will not be repeated here.

[0057] See Figure 4 , Figure 4 This is a structural block diagram of an availability zone traffic switching device 200 provided in an embodiment of the present invention. The availability zone traffic switching device 200 includes a processor 21, a memory 22, and a computer program stored in the memory 22 and executable on the processor 21. When the processor 21 executes the computer program, it implements the steps in the above-described embodiments of the availability zone traffic switching methods.

[0058] For example, the computer program may be divided into one or more modules / units, which are stored in the memory 22 and executed by the processor 21 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program in the availability zone traffic switching device 200.

[0059] The availability zone traffic switching device 200 may include, but is not limited to, a processor 21 and a memory 22. Those skilled in the art will understand that the schematic diagram is merely an example of the availability zone traffic switching device 200 and does not constitute a limitation on the availability zone traffic switching device 200. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the availability zone traffic switching device 200 may also include input / output devices, network access devices, buses, etc.

[0060] The processor 21 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor. The processor 21 is the control center of the availability zone traffic switching device 200, connecting all parts of the availability zone traffic switching device 200 via various interfaces and lines.

[0061] The memory 22 can be used to store the computer programs and / or modules. The processor 21 implements various functions of the availability zone traffic switching device 200 by running or executing the computer programs and / or modules stored in the memory 22 and calling the data stored in the memory 22. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0062] If the modules / units integrated in the availability zone traffic switching device 200 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by the processor 21, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0063] Furthermore, the present invention also provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the availability zone traffic switching method as described in any of the above embodiments.

[0064] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for switching traffic within an availability zone, characterized in that, The method, applied to availability zone business systems, includes: During business operations, the operational status data of each availability zone where the current business is deployed is obtained; wherein, each business has applied for a virtual IP address in each availability zone where it is deployed, and the virtual IP address is associated with the unified access domain name of the business; The health status of each availability zone is determined based on the aforementioned operational status data; When the health status of any target availability zone meets the preset traffic switching conditions, traffic accessing the target availability zone will be switched to a healthy availability zone with an associated relationship.

2. The availability zone traffic switching method as described in claim 1, characterized in that, The operational status data includes at least one of performance metrics, memory status, network quality parameters, and health check data.

3. The availability zone traffic switching method as described in claim 2, characterized in that, The traffic switching conditions include at least one of the following: In the memory state, the available disk space of the availability zone is lower than a preset disk threshold; or, the memory leakage of the availability zone reaches a preset leakage threshold, and the remaining available memory is lower than a preset memory threshold. Among the performance metrics, the CPU utilization and / or memory utilization of the availability zone reaches a preset performance threshold. Among the network quality parameters, the network quality score of the availability zone is lower than the preset network score threshold. In the health check data, the health check results of the available area meet the abnormality judgment criteria.

4. The availability zone traffic switching method as described in claim 1, characterized in that, The availability zone service system deploys a Kubernetes cluster; wherein, the service is containerized and deployed in the Kubernetes cluster.

5. The availability zone traffic switching method as described in claim 4, characterized in that, A load balancer is deployed in the availability zone service system; wherein the load balancer provides at least one of the following services: Configure a Layer 4 load balancer for the underlying services; Configure a Layer 4 and Layer 7 load balancer for the console service. The Layer 7 load balancer exposes the routing and forwarding rules of the service to external access through the entry point of the K8s cluster.

6. The availability zone traffic switching method according to claim 5, characterized in that, The load balancer is clustered and its capacity is determined based on its performance baseline and the access services. It is deployed in clusters across multiple availability zones. Each service requests a virtual IP address in each availability zone through the layer 4 load balancer of that availability zone.

7. An availability zone traffic switching device, characterized in that, Applied to availability zone business systems, including: The operation status data acquisition module is used to acquire the operation status data of each availability zone where the current service is deployed during the operation of the service; wherein, each service applies for a virtual IP address in each availability zone in which it is deployed, and the virtual IP address is associated with the unified access domain name of the service; The health status determination module is used to determine the health status of each availability zone based on the operational status data. The traffic switching module is used to switch traffic accessing the target availability zone to a healthy availability zone with which it has a relationship when the health status of any target availability zone meets the preset traffic switching conditions.

8. An availability zone traffic switching device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor, when executing the computer program, implements the availability zone traffic switching method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the availability zone traffic switching method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the availability zone traffic switching method as described in any one of claims 1 to 6.

Images