Priority-based cloud service differentiated high availability management method and system

Abstract

This invention discloses a priority-based differentiated high availability management method and system for cloud services. The method includes: Step S1, creating cloud service instances, scheduling different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategy, and classifying the cloud service instances by status; Step S2, each cloud service instance performs normal operation and status maintenance according to a preset scheduling strategy; Step S3, the controller monitors each cloud service instance in real time. If a cloud service instance is detected to have a fault, the controller decides on a recovery plan based on the high availability priority and current resource status of the cloud service instance and recovers the cloud service instance.

Description

Technical Field

[0001] This application belongs to the field of cloud computing and distributed system high availability technology, specifically referring to a priority-based cloud service differentiated high availability management method and system. Background Technology

[0002] With the widespread adoption of cloud computing, more and more enterprise applications (such as cloud PBXs) are being deployed on shared cloud infrastructure. High availability (HA) is a key feature that ensures the continuous and reliable operation of these services, and it is also a core value-added service provided by cloud service providers to users.

[0003] Traditional high availability solutions mainly have two modes:

[0004] Extensive cluster high availability: This approach treats the entire cluster or service as a whole for high availability assurance, with all user instances sharing the same redundant resources. For example, the entire PCE Hub cluster is designed as a high-availability architecture. Its disadvantages include: the inability to sell differentiated high-availability services to individual users, low resource utilization, and non-paying users also incurring the costs associated with redundant resources.

[0005] 1:1 Hot Standby Mode: A dedicated standby instance is allocated to each user application instance requiring high availability (such as a PCE virtual machine or container), forming a primary-standby pair. Disadvantages: Resource redundancy costs can reach 100%, standby instances are idle for extended periods, and infrastructure costs increase linearly with user scale, resulting in poor economic efficiency.

[0006] Therefore, the drawbacks of existing high-availability solutions are as follows: Decoupling of source and business value: The technical architecture cannot detect whether users have purchased high-availability services, leading to a disconnect between resource allocation and revenue. Unpaid users "free-ride," resulting in high costs for cloud service providers. Low resource utilization: Both extensive clusters and 1:1 hot standby suffer from severe resource waste, failing to maximize hardware resource utilization while ensuring SLAs. Rigid failover strategies: A lack of intelligent decision-making based on business priorities. In the event of a large-scale failure, all instances employ the same recovery strategy, failing to prioritize core paying users and potentially causing significant business losses. Huge state synchronization overhead: In cross-node or cross-availability zone scenarios, indiscriminate real-time synchronization of data across all instances consumes substantial network bandwidth and storage I / O, resulting in extremely high costs. Summary of the Invention

[0007] To overcome the shortcomings of existing technologies, this application provides a priority-based cloud service differentiated high availability management method and system, which can dynamically schedule according to user priorities, optimize backup costs, and achieve intelligent failover.

[0008] This invention provides a priority-based differentiated high availability management method for cloud services, the method comprising: Step S1: Create cloud service instances, schedule different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategy, and classify the cloud service instances according to their status. Step S2: Each cloud service instance performs normal operation and status maintenance according to the preset scheduling strategy; Step S3: The controller monitors each cloud service instance in real time. If a cloud service instance is detected to be faulty, the controller decides on a recovery plan based on the high availability priority and current resource status of the cloud service instance and recovers the cloud service instance.

[0009] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, step S1, which involves creating cloud service instances and scheduling different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategies, as well as classifying the cloud service instances by status, includes: Step S11: Create a cloud service instance based on the user's request information, which includes the user ID and high availability purchase identifier; Step S12: Query the contract and calculate the high availability priority of the cloud service instance based on the established cloud service instance; Step S13: Based on the calculated high availability priority, schedule different primary and backup instances for different cloud service instances according to the differentiated anti-affinity strategy.

[0010] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, step S2, in which each cloud service instance performs normal operation and status maintenance according to a preset scheduling strategy, includes: Step S21: Synchronize the status data of the cloud service instance according to the differentiated anti-affinity strategy; Step S22: Implement the hot status of the push cloud service instance; Step S23: Perform a health check on the cloud service instance.

[0011] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, in step S3, the controller monitors each cloud service instance in real time. If a cloud service instance is detected to have failed, the controller determines a recovery plan based on the high availability priority and current resource status of the cloud service instance and recovers the cloud service instance, including: Step S31: If the main Pod of the cloud service instance is detected to be disconnected, a decision on the switching and recovery plan is made based on the high availability priority and current resource status of the cloud service instance. Step S32a: Activate the hot standby Pod; Step S33a: Load the latest hot status; Step S34a: Update the service endpoint; Step S35a: Cloud service quickly recovers; Step S32b: Request backup resources; Step S33b: Allocate resources; Step S34b: Create a new Pod on the new node; Step S35b: Pull the latest snapshot; Step S36b: Return status data; Step S37b: Cloud service recovery; Step S32c: Send a fault alarm to the management system and wait for the management system to restore the cloud service.

[0012] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, the calculation formula for the high availability priority is as follows: ; in, For cloud service instances The high availability priority is typically normalized to [0, 1.0]. The contract factor is a Boolean or tier value. The contract factor directly reflects whether the user has purchased high availability services and their level. As a business importance factor, it is determined by the administrator based on the cloud service instance. Pre-defined services carried; This is a paid tier factor, linked to the product packages subscribed to by users, reflecting the overall value of the customer; The dynamic degradation factor is a decay function that varies with time or system load. ,in, As the initial value, The attenuation coefficient is... For cloud service instances Idle time or system-wide stress index; All are weighting coefficients, and satisfy the following conditions: ,in, It has the highest weight.

[0013] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, the differentiated anti-affinity strategy will differentiate cloud service instances... High availability priority Mapped to specific Pod anti-affinity rules, controlling the main cloud service instance. Backup cloud service instances The physical deployment locations include: Level 3: Configure to force anti-affinity across availability zones for primary cloud service instances. Backup cloud service instances They must be deployed in different physical data center rooms; Level 2: Configured to force cross-node anti-affinity, main cloud service instance Backup cloud service instances They must be deployed on different physical servers; Level 1: It is set to recommend cross-node anti-affinity, and the system scheduler will try to satisfy it first, but compromise is allowed when the cluster resources are fully loaded, and the main cloud service instance will be prioritized. Backup cloud service instances Deploy to the same node; Level 0: Set to unrestricted, main cloud service instance Backup cloud service instances It can share nodes with any other cloud service instance to maximize resource utilization.

[0014] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, the step of scheduling different primary and backup instances for different cloud service instances according to a differentiated anti-affinity strategy includes: like At this point, corresponding to level 3 or level 2, the system scheduler pre-configures a dedicated hot standby Pod on another node that satisfies strong anti-affinity. like At this level (Level 1), the system scheduler does not pre-configure a dedicated backup Pod, but instructs the synchronization engine to configure the backup Pod for this cloud service instance. Perform lazy synchronization; like At this point, corresponding to level 0, the system scheduler takes no action and only records cloud service instances. information.

[0015] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, the state classification of cloud service instances involves classifying cloud service instances... The operational data is categorized according to the degree of impact on business continuity and recovery speed requirements, and based on cloud service instances. High availability priority Different synchronization strategies and bandwidth budgets are allocated, including: Level S1: Set as hot state, defined as a state where the data is completely in memory and its loss would affect the current business; the recovery point target for Level S1 is ≈ 0, and the recovery time target is <30 seconds; Level S2: Set to a warm state, defined as configurations and data that are persisted but frequently updated; Level S2 recovery point target < 5 minutes, recovery time target < 2 minutes; Level S3: Set to cold state, defined as archived data that is static or accessed infrequently.

[0016] Furthermore, according to the priority-based differentiated high availability management method for cloud services provided in this application, the cloud service instance is classified into different states, and the controller also performs a synchronization budget, the value of which is related to the high availability priority. Positive correlation includes: High-priority cloud service instances: allocate high budgets for continuous, low-latency streaming synchronization of S1 status to their dedicated hot standby Pods; perform frequent incremental snapshots for S2 status; Low-to-medium priority cloud service instances: allocate low budgets, only perform periodic full snapshots of the S2 state and store them in shared object storage; do not perform cross-node synchronization for the S1 state; It also performs intelligent bandwidth management, including a synchronization engine that monitors network bandwidth at the cluster level and prioritizes high availability when bandwidth is tight. The synchronization rate of each instance is dynamically adjusted in descending order to ensure that the synchronization of high-priority instances is not affected.

[0017] This application also provides a priority-based differentiated high availability management system for cloud services, the system comprising: The instance creation and differentiated scheduling module is used to create cloud service instances, schedule different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategy, and classify the cloud service instances according to their status. The operation and status maintenance module is used to perform normal operation and status maintenance on each cloud service instance according to a preset scheduling strategy. The fault detection and intelligent switching module is used to detect each cloud service instance in real time. If a fault is detected in a cloud service instance, the controller decides on a recovery plan based on the high availability priority and current resource status of the cloud service instance and restores the cloud service instance.

[0018] The beneficial effects of this invention are as follows: This application provides a priority-based differentiated high availability management method and system for cloud services. This method uses dynamically calculated high availability priority (HA-Priority) as a unified metric. This priority integrates multiple factors such as user contracts, payment levels, and business importance. Based on high availability priority calculation and differentiated anti-affinity strategies, different cloud service instances are scheduled to implement different differentiated strategies. For example, high-priority instances have their primary and backup components forcibly deployed in different fault domains (e.g., different servers, different data centers); low-priority instances can share resources. The level and frequency of data synchronization are determined according to priority. Real-time hot synchronization of critical states is performed only for high-priority instances, while lower-priority instances use less costly lazy synchronization or snapshots. This significantly saves resources. Attached Figure Description

[0019] The technical solution and other beneficial effects of this application will become apparent from the following detailed description of specific embodiments in conjunction with the accompanying drawings.

[0020] Figure 1 This is a schematic diagram of the priority-based cloud service differentiated high availability management method provided in this embodiment.

[0021] Figure 2 This is a sequence diagram of the business process for the priority-based differentiated high availability management method for cloud services provided in this embodiment. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0023] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," "clockwise," and "counterclockwise," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0024] The following disclosure provides many different embodiments or examples for implementing different structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. Of course, these are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples; such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed. In addition, various specific examples of processes and materials are provided in this application, but those skilled in the art will recognize the application of other processes and / or the use of other materials.

[0025] The embodiments of this application will now be further described in conjunction with the accompanying drawings and specific implementation details.

[0026] Example 1: Figure 1 This is a schematic diagram of the priority-based cloud service differentiated high availability management method provided in this embodiment.

[0027] like Figure 1 As shown, the method includes: Step S1: Create cloud service instances, schedule different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategy, and classify the cloud service instances according to their status. Step S2: Each cloud service instance performs normal operation and status maintenance according to the preset scheduling strategy; Step S3: The controller monitors each cloud service instance in real time. If a cloud service instance is detected to be faulty, the controller decides on a recovery plan based on the high availability priority and current resource status of the cloud service instance and recovers the cloud service instance.

[0028] Figure 2 This is a sequence diagram of the business process for the priority-based differentiated high availability management method for cloud services provided in this embodiment.

[0029] like Figure 1 , Figure 2 As shown, step S1, which involves creating cloud service instances and scheduling different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategies, as well as classifying the status of cloud service instances, includes: Step S11: Create a cloud service instance based on the user's request information, which includes the user ID and high availability purchase identifier; Step S12: Query the contract and calculate the high availability priority of the cloud service instance based on the established cloud service instance; Step S13: Based on the calculated high availability priority, schedule different primary and backup instances for different cloud service instances according to the differentiated anti-affinity strategy.

[0030] Specifically, in this embodiment, the high availability priority (HA-Priority) means: quantifying the number of cloud service instances for a user. A comprehensive strength score for high availability assurance requirements. This value changes dynamically and directly determines the instance's resource scheduling strategy, spare resource allocation order, and state synchronization level. The formula for calculating the high availability priority is: ; in, For cloud service instances High availability priority, the value range is usually normalized to [0, 1.0].

[0031] This is the contract factor, a Boolean or tier value. The contract factor directly reflects whether a user has purchased high availability services and their level; for example... This indicates that HA has been purchased. This indicates that HA has not been purchased and only basic protection is provided.

[0032] As a business importance factor, it is determined by the administrator based on the cloud service instance. The pre-defined business functions are used to differentiate between production, testing, and other environments; for example... (represented as the core production system) This indicates an internal testing system.

[0033] This is a paid tier factor, linked to the product packages subscribed to by the user, reflecting the overall value of the customer; for example... This indicates the enterprise version of UP. , indicating the standard version EP.

[0034] This is a dynamic degradation factor, a decay function that changes over time or with system load. It's used to smoothly reduce the protection level of non-core or idle instances when resources are extremely scarce, freeing up resources for core instances. ,in, For the initial value (e.g., 1.0), The attenuation coefficient is... For cloud service instances Idle time or system-wide stress index.

[0035] All are weighting coefficients, and satisfy the following conditions: This reflects the relative importance of each factor, among which, It has the highest weight.

[0036] The meaning of the differentiated anti-affinity strategy is: to use different cloud service instances High availability priority Mapped to specific Pod anti-affinity rules, controlling the main cloud service instance. Backup cloud service instances The physical deployment locations include: Level 3: Configure to force anti-affinity across availability zones for primary cloud service instances. Backup cloud service instances It must be deployed in different physical data center server rooms to provide data center-level disaster recovery; in this embodiment, It can be set to 0.8.

[0037] Level 2: Configured to force cross-node anti-affinity, main cloud service instance Backup cloud service instances They must be deployed on different physical servers to prevent single points of failure; in this embodiment, It can be set to 0.5.

[0038] Level 1: It is set to recommend cross-node anti-affinity, and the system scheduler will try to satisfy it first, but compromise is allowed when the cluster resources are fully loaded, and the main cloud service instance will be prioritized. Backup cloud service instances Deployed to the same node; in this embodiment, It can be set to 0.2.

[0039] Level 0: Set to unrestricted, main cloud service instance Backup cloud service instances It can share nodes with any other cloud service instance to maximize resource utilization.

[0040] , Additional values ​​can be assigned as needed.

[0041] Specifically, in this embodiment, in the process of scheduling different primary and backup instances for different cloud service instances according to the differentiated anti-affinity strategy, a shared backup resource pool capacity model is also set up. This shared backup resource pool calculates the total amount of globally shared backup resources reserved to cope with unexpected failures. This model, based on probabilistic statistics rather than simple summation, is key to achieving cost optimization.

[0042] The calculation formula is as follows: ; in, The total computing resources (such as the number of CPU cores and GB of memory) that need to be reserved for sharing the backup resource pool.

[0043] For higher priority cloud service instances The amount of resources requested.

[0044] It is the threshold for determining whether an instance is eligible to use the shared pool (usually) = ).

[0045] This is an indicator function. The value is 1 when it is active, and 0 otherwise.

[0046] The coverage factor is a core optimization parameter. The settings are based on historical failure probabilities and business tolerance. For example, if at any given time the number of high-priority instances requiring simultaneous recovery does not exceed 20% of their total number, then... It can be set to 0.2. This means that the backup pool only needs to prepare 20% of the resources to cover most failure scenarios.

[0047] This is the cluster buffer coefficient. As a very small safety cushion, it is used to deal with low probability, exceeding Extreme cases of coverage or model error. For example: β = 0.05.

[0048] This represents the total available resources of the entire cluster.

[0049] The state classification of cloud service instances refers to classifying cloud service instances... The operational data is categorized according to the degree of impact on business continuity and recovery speed requirements, and based on cloud service instances. High availability priority Different synchronization strategies and bandwidth budgets are allocated, including: Level S1: Set as a hot state, defined as a state where data is entirely in memory and its loss would affect current business operations; such as: real-time call sessions, user registration information, and active WebSocket connections. The goal of Level S1 is to achieve a recovery point objective (RPO) ≈ 0 and a recovery time objective (RTO) < 30 seconds. Level S2: Set to a warm state, defined as persistent but frequently updated configurations and data; such as extension configurations, routing policies, and voicemail. The goal of Level S2 is a Recovery Point Objective (RPO) of <5 minutes and a Recovery Time Objective (RTO) of <2 minutes. Level S3: Set to a cold state, defined as archived data that is static or accessed infrequently. Examples include: operating system and application images, call logs (CDRs), and old recording files. The goal of Level S3 is to achieve a high Recovery Point Objective (RPO) (e.g., several hours) and an acceptable Recovery Time Objective (RTO) in the minutes.

[0050] Based on the cloud service instance, the controller performs state classification and also performs synchronization budgeting, the value of which is related to the high availability priority. Positive correlation includes: High-priority cloud service instances: allocate high budgets for continuous, low-latency streaming synchronization of S1 status to their dedicated hot standby Pods; perform frequent incremental snapshots for S2 status; Low-to-medium priority cloud service instances: allocate low budgets, only perform periodic full snapshots of the S2 state and store them in shared object storage; do not perform cross-node synchronization for the S1 state; It also performs intelligent bandwidth management, including a synchronization engine that monitors network bandwidth at the cluster level and prioritizes high availability when bandwidth is tight. The synchronization rate of each instance is dynamically adjusted in descending order to ensure that the synchronization of high-priority instances is not affected.

[0051] Therefore, combining Figure 2 In this embodiment, a cloud service instance is executed through step S1. The creation and differentiated scheduling of PCE instances involves a user or management system initiating a request to create a PCE instance, specifying whether to purchase HA services. Upon receiving the request, the high availability orchestration controller queries the user contract database, combines the request parameters, and dynamically calculates the cloud service instance's priority according to the high availability priority calculation formula. initial The controller will The instance resource requirements are sent to the Kubernetes scheduler along with scheduling constraints generated based on the differentiated anti-affinity policy.

[0052] The scheduler schedules the primary instance Pod to a suitable node (such as Node A) based on constraints.

[0053] The controller performs different primary and backup instance scheduling for different cloud service instances based on a differentiated anti-affinity strategy. Judgments include: like At this point, corresponding to level 3 or level 2, the system scheduler pre-configures a dedicated hot standby Pod on another node (such as Node Z) that satisfies strong anti-affinity. This hot standby Pod has loaded the image and some data, but is in a paused state and consumes only a small amount of memory.

[0054] like At this level (Level 1), the system scheduler does not pre-configure a dedicated backup Pod, but instructs the synchronization engine to configure the backup Pod for this cloud service instance. Perform lazy synchronization (i.e., periodic snapshot level S2 state).

[0055] like At this point, corresponding to level 0, the system scheduler takes no action and only records cloud service instances. information.

[0056] For instances that require synchronization, the intelligent synchronization engine determines the P based on their... i Establish corresponding data synchronization links based on status classification strategies.

[0057] like Figure 2 As shown, step S1, which involves creating cloud service instances, scheduling different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategies, and classifying the status of cloud service instances, further includes: like If HA is purchased, then: Step S14a: Schedule the main Pod to Node A; Step S15a: Pre-configure a dedicated hot standby Pod and schedule it to Node B with strong anti-affinity; Step S16a: Create a hot standby Pod on Node B (pause); Step S17a: Enable the "Hot Sync" channel and synchronize the S1 status to the hot standby Pod.

[0058] like If a user has not purchased HA but it is still important, then proceed as follows: Step S14b: Schedule the main Pod to Node A; Step S15b: Enable "Lazy Synchronization" and periodically take snapshots of the S2 state.

[0059] like If the user has not purchased HA and it is not important to them, then proceed as follows: Step S14c: Schedule the main Pod to Node A; Step S15c: Store only the base image, without stateful synchronization.

[0060] In step S2, each cloud service instance performs normal operation and status maintenance according to the preset scheduling policy. Specifically, the primary instance Pod runs normally and sends status data to the synchronization engine according to the preset policy. The synchronization engine processes data according to budget and policy: for high-priority instances, it pushes the S1 status to their hot standby Pods in real time; for all instances requiring backup, it periodically saves S2 snapshots to shared storage. The controller continuously performs health checks on the primary instance.

[0061] Step S2 specifically includes: Step S21: Synchronize the status data of the cloud service instance according to the differentiated anti-affinity strategy; Step S22 (if a hot standby Pod exists): Implement the hot status of the push cloud service instance; Step S23: Perform a health check on the cloud service instance.

[0062] In step S3, the controller monitors each cloud service instance in real time. If a cloud service instance is detected to be faulty, the controller determines a recovery plan based on the high availability priority and current resource status of the cloud service instance and initiates recovery for that instance. Specifically, if the controller detects that the primary instance Pod is disconnected (e.g., a node crash), it makes a switchover decision: the controller immediately queries the instance's... And the current resource status, and select a recovery plan: Option A (Fast Switchover): If the cloud service instance has a dedicated hot standby Pod ( (High), the controller immediately activates the hot standby Pod. The hot standby Pod loads the latest S1 state from memory and takes over the service IP. Its RTO is <10 seconds.

[0063] Option B (Pooled Recovery): If the cloud service instance does not have a dedicated hot standby Pod, but If the value exceeds the minimum threshold, the controller requests resources from the shared backup resource pool. The resource pool then... Resource allocation is queued based on rank. After acquiring resources, a new Pod is launched on the new node, and the latest S2 state snapshot of the rank is pulled from shared storage for restoration. Its RTO is ~60-90 seconds.

[0064] Option C (Resource Preemption and Queuing): If the shared pool resources are exhausted, and a new faulty instance... Higher than an instance that is being restored using pool resources. If this occurs, preemption is triggered. The recovery of the low-priority instance is interrupted, and resources are given to the high-priority instance. The preempted instance enters the waiting queue.

[0065] Option D (Low Guarantee Alarm): If When resources are extremely low and insufficient, the system only sends a fault alarm and does not automatically recover, waiting for manual intervention or when resources are idle.

[0066] Once the recovery is complete, the controller updates the service routes, directing user traffic to the new instance Pod.

[0067] Combination Figure 2 In this embodiment, step S3 further includes: Step S31: If the main Pod of the cloud service instance is detected to be disconnected, a decision on the switching and recovery plan is made based on the high availability priority and current resource status of the cloud service instance. If Option A is executed, then a dedicated hot standby Pod will be available. If it is high, then proceed as follows: Step S32a: Activate the hot standby Pod; Step S33a: Load the latest hot status; Step S34a: Update the server endpoint (IP / DNS); Step S35a: Cloud service fast recovery (RTO < 10 seconds).

[0068] If Option B is executed, i.e. there is no dedicated hot standby Pod, For medium to low levels, proceed as follows: Step S32b: Request backup resources; Step S33b: Allocate resources; Step S34b: Create a new Pod on the new node; Step S35b: Pull the latest snapshot (level S2 status); Step S36b: Return status data; Step S37b: Cloud service recovery (RTO < 90 seconds).

[0069] If option C is executed, i.e., resources are insufficient, If the minimum is reached, then proceed as follows: Step S32c: Send a fault alarm to the management system and wait for the management system to restore the cloud service.

[0070] This application provides a priority-based differentiated high availability management method and system for cloud services. This method uses dynamically calculated high availability priority (HA-Priority) as a unified metric. This priority integrates multiple factors such as user contracts, payment levels, and business importance. Based on high availability priority calculation and differentiated anti-affinity strategies, different cloud service instances are scheduled to implement different differentiated strategies. For example, high-priority instances have their primary and backup components forcibly deployed in different fault domains (e.g., different servers, different data centers); low-priority instances can share resources. The level and frequency of data synchronization are determined according to priority. Real-time hot synchronization of critical states is performed only for high-priority instances, while lower-priority instances use less costly lazy synchronization or snapshots. Furthermore, a tiered backup pool is adopted: abandoning the 1:1 dedicated backup machine, a globally shared backup resource pool is constructed. The allocation of backup resources follows the priority order, and high-priority instances can preempt backup resources from low-priority instances, significantly saving resources.

[0071] Example 2: This example also provides a priority-based differentiated high availability management system for cloud services, the system comprising: The instance creation and differentiated scheduling module is used to create cloud service instances, schedule different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategy, and classify the cloud service instances according to their status. The operation and status maintenance module is used to perform normal operation and status maintenance on each cloud service instance according to a preset scheduling strategy. The fault detection and intelligent switching module is used to detect each cloud service instance in real time. If a fault is detected in a cloud service instance, the controller decides on a recovery plan based on the high availability priority and current resource status of the cloud service instance and restores the cloud service instance.

[0072] Example 3: This embodiment also provides a computer terminal device for a priority-based cloud service differentiated high availability management method. The terminal device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the embodiments of the method described in Embodiment 1 of the present invention.

[0073] Furthermore, as an executable solution, the computer terminal device for the priority-based differentiated high availability management method for cloud services can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer terminal device for the priority-based differentiated high availability management method for cloud services may include, but is not limited to, processors and memory. Those skilled in the art will understand that the above-described composition of the computer terminal device for the priority-based differentiated high availability management method for cloud services is merely an example and does not constitute a limitation on the computer terminal device for the priority-based differentiated high availability management method for cloud services. It may include more or fewer components, or combine certain components, or different components. For example, the computer terminal device for the priority-based differentiated high availability management method for cloud services may also include input / output devices, network access devices, buses, etc., and this embodiment of the invention does not limit this.

[0074] Furthermore, as an executable solution, the processor 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. The general-purpose processor can be a microprocessor or any conventional processor. This processor serves as the control center of the computer terminal device for the priority-based differentiated high availability management method for cloud services, connecting various parts of the computer terminal device through various interfaces and lines.

[0075] The memory can be used to store the computer programs and / or modules. The processor, by running or executing the computer programs and / or modules stored in the memory and calling data stored in the memory, realizes various functions of the computer terminal device of the priority-based cloud service differentiated high availability management method. The memory may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application required for a function; the data storage area may store data created based on the use of the mobile phone, etc. In addition, the memory 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.

[0076] The present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the embodiments of the present invention.

[0077] If the modules / units integrated into the computer terminal device of the priority-based differentiated high availability management method for cloud services 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 of the present invention 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 a processor, 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), and software distribution media, etc.

[0078] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the present invention. Finally, it should be noted that in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0079] The above provides a detailed description of a priority-based cloud service differentiated high availability management method and system provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the technical solutions and core ideas of this application. Those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A priority-based differentiated high availability management method for cloud services, characterized in that, The method includes: Step S1: Create cloud service instances, schedule different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategy, and classify the cloud service instances according to their status. Step S2: Each cloud service instance performs normal operation and status maintenance according to the preset scheduling strategy; Step S3: The controller monitors each cloud service instance in real time. If a cloud service instance is detected to be faulty, the controller decides on a recovery plan based on the high availability priority and current resource status of the cloud service instance and recovers the cloud service instance.

2. The priority-based differentiated high availability management method for cloud services according to claim 1, characterized in that, Step S1 involves creating cloud service instances and scheduling different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategies, as well as classifying the status of cloud service instances, including: Step S11: Create a cloud service instance based on the user's request information, which includes the user ID and high availability purchase identifier; Step S12: Query the contract and calculate the high availability priority of the cloud service instance based on the established cloud service instance; Step S13: Based on the calculated high availability priority, schedule different primary and backup instances for different cloud service instances according to the differentiated anti-affinity strategy.

3. The priority-based differentiated high availability management method for cloud services according to claim 2, characterized in that, Step S2, in which each cloud service instance performs normal operation and status maintenance according to a preset scheduling strategy, includes: Step S21: Synchronize the status data of the cloud service instance according to the differentiated anti-affinity strategy; Step S22: Implement the hot status of the push cloud service instance; Step S23: Perform a health check on the cloud service instance.

4. The priority-based differentiated high availability management method for cloud services according to claim 3, characterized in that, In step S3, the controller monitors each cloud service instance in real time. If a cloud service instance is detected to be faulty, the controller determines a recovery plan based on the high availability priority and current resource status of the cloud service instance, and recovers the cloud service instance, including: Step S31: If the main Pod of the cloud service instance is detected to be disconnected, a decision on the switching and recovery plan is made based on the high availability priority and current resource status of the cloud service instance. Step S32a: Activate the hot standby Pod; Step S33a: Load the latest hot status; Step S34a: Update the service endpoint; Step S35a: Cloud service quickly recovers; Step S32b: Request backup resources; Step S33b: Allocate resources; Step S34b: Create a new Pod on the new node; Step S35b: Pull the latest snapshot; Step S36b: Return status data; Step S37b: Cloud service recovery; Step S32c: Send a fault alarm to the management system and wait for the management system to restore the cloud service.

5. The priority-based differentiated high availability management method for cloud services according to any one of claims 1-4, characterized in that, The formula for calculating the high availability priority is as follows: ； in, For cloud service instances The high availability priority is typically normalized to [0, 1.0]. The contract factor is a Boolean or ladder value. The contract factor directly reflects whether the user has purchased high availability services and their level. As a business importance factor, it is determined by the administrator based on the cloud service instance. The services it carries are pre-defined; This is a paid tier factor, linked to the product packages subscribed to by users, reflecting the overall value of the customer; The dynamic degradation factor is a decay function that varies with time or system load. ,in, As the initial value, The attenuation coefficient is... For cloud service instances Idle time or system-wide stress index; All are weighting coefficients, and satisfy the following conditions: ,in, It has the highest weight.

6. The priority-based differentiated high availability management method for cloud services according to claim 5, characterized in that, The differentiated anti-affinity strategy will target different cloud service instances. High availability priority Mapped to specific Pod anti-affinity rules, controlling the main cloud service instance. Backup cloud service instances The physical deployment locations include: Level 3: Configure to force cross-availability zone anti-affinity for primary cloud service instances. Backup cloud service instances They must be deployed in different physical data center rooms; Level 2: Configured to force cross-node anti-affinity, main cloud service instance Backup cloud service instances They must be deployed on different physical servers; Level 1: It is set to recommend cross-node anti-affinity, and the system scheduler will try to satisfy it first, but compromise is allowed when the cluster resources are fully loaded, and the main cloud service instance will be prioritized. Backup cloud service instances Deploy to the same node; Level 0: Set to unrestricted, main cloud service instance Backup cloud service instances It can share nodes with any other cloud service instance to maximize resource utilization.

7. The priority-based differentiated high availability management method for cloud services according to claim 6, characterized in that, The method of scheduling different primary and backup instances for different cloud service instances based on a differentiated anti-affinity strategy includes: like At this point, corresponding to level 3 or level 2, the system scheduler pre-configures a dedicated hot standby Pod on another node that satisfies strong anti-affinity. like At this level (Level 1), the system scheduler does not pre-configure a dedicated backup Pod, but instructs the synchronization engine to configure the backup Pod for this cloud service instance. Perform lazy synchronization; like At this point, corresponding to level 0, the system scheduler takes no action and only records cloud service instances. information.

8. The priority-based differentiated high availability management method for cloud services according to claim 7, characterized in that, The state classification of cloud service instances is to classify cloud service instances... The operational data is categorized according to the degree of impact on business continuity and recovery speed requirements, and based on cloud service instances. High availability priority Different synchronization strategies and bandwidth budgets are allocated, including: Level S1: Set as hot state, defined as a state where the data is completely in memory and its loss would affect the current business; the recovery point target for Level S1 is ≈ 0, and the recovery time target is <30 seconds; Level S2: Set to a warm state, defined as configurations and data that are persisted but frequently updated; Level S2 recovery point target < 5 minutes, recovery time target < 2 minutes; Level S3: Set to cold state, defined as archived data that is static or accessed infrequently.

9. The priority-based differentiated high availability management method for cloud services according to claim 8, characterized in that, Based on the cloud service instance, the controller performs state classification and also performs synchronization budgeting, the value of which is related to the high availability priority. Positive correlation includes: High-priority cloud service instances: allocate high budgets for continuous, low-latency streaming synchronization of S1 status to their dedicated hot standby Pods; perform frequent incremental snapshots for S2 status; Low-to-medium priority cloud service instances: allocate low budgets, only perform periodic full snapshots of the S2 state and store them in shared object storage; do not perform cross-node synchronization for the S1 state; It also performs intelligent bandwidth management, including a synchronization engine that monitors network bandwidth at the cluster level and prioritizes high availability when bandwidth is tight. The synchronization rate of each instance is dynamically adjusted in descending order to ensure that the synchronization of high-priority instances is not affected.

10. A priority-based differentiated high availability management system for cloud services, characterized in that, The system includes: The instance creation and differentiated scheduling module is used to create cloud service instances, schedule different cloud service instances based on high availability priority calculation and differentiated anti-affinity strategy, and classify the cloud service instances according to their status. The operation and status maintenance module is used to perform normal operation and status maintenance on each cloud service instance according to a preset scheduling strategy. The fault detection and intelligent switching module is used to detect each cloud service instance in real time. If a fault is detected in a cloud service instance, the controller decides on a recovery plan based on the high availability priority and current resource status of the cloud service instance and restores the cloud service instance.

Images