Disaster recovery method and device for cloud service

Abstract

The embodiment of the application discloses a cloud service disaster recovery method and device, and relates to the field of cloud computing. A specific embodiment of the method comprises the following steps: monitoring whether a fault zone exists in at least two zones, wherein each zone of the at least two zones is deployed with an application program of a cloud service; in response to monitoring that the fault zone exists, determining whether the type of the fault is a preset type; and in response to determining that the type of the fault is the preset type, switching the application program running in the fault zone to run in a non-fault zone. The embodiment can realize automatic switching of the zone when the zone is faulty, thereby improving the reliability of the cloud service.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to disaster recovery methods and apparatus for cloud services. Background Technology

[0002] A data center is a globally collaborative network of specific devices used to transmit, accelerate, display, compute, and store data information over the internet infrastructure. A data center can be a multi-functional building capable of housing multiple servers and communication equipment. These devices are typically placed together because they share similar environmental and physical security requirements, and this arrangement facilitates maintenance. An availability zone can include at least one data center; therefore, an availability zone offers greater availability, fault tolerance, and scalability than a single data center, and users can choose an availability zone to create resources.

[0003] With the continuous popularization and development of cloud computing, cloud products developed using cloud computing technology have gained attention, resulting in an increasingly diverse range of cloud products. Elastic Compute Service (ECS), as a basic cloud computing service, can be used as conveniently and efficiently as resources such as water, electricity, and gas, and its applications are very widespread. Summary of the Invention

[0004] This application provides a disaster recovery method and apparatus for cloud services.

[0005] In a first aspect, embodiments of this application provide a disaster recovery method for cloud services, comprising: monitoring whether there is a faulty availability zone among at least two availability zones, wherein each of the at least two availability zones deploys an application for cloud services; in response to detecting a faulty availability zone, determining whether the type of the fault is a preset type; and in response to determining that the type of the fault is a preset type, switching the application running in the faulty availability zone to run in the non-faulty availability zone.

[0006] In some embodiments, switching an application running in a faulty availability zone to a non-faulty availability zone includes: forwarding a request to invoke the application running in the faulty availability zone to the non-faulty availability zone.

[0007] In some embodiments, forwarding a request to invoke an application running in a faulty availability zone to a non-faulty availability zone includes: determining the availability zone with the lowest load among the non-faulty availability zones; and forwarding the request to invoke an application running in the faulty availability zone to the availability zone with the lowest load.

[0008] In some embodiments, the method further includes: in response to determining that the type of the fault is not a preset type, outputting information about the availability zone of the fault and the type of fault.

[0009] In some embodiments, the deployment of the above-mentioned at least two availability zones includes the following steps: determining whether the cloud service application needs to call other applications, wherein the other applications are applications other than the cloud service application; in response to determining that other applications need to be called, deploying call ports for calling other applications in the above-mentioned at least two availability zones.

[0010] Secondly, embodiments of this application provide a disaster recovery device for cloud services, comprising: a monitoring unit configured to monitor whether there is a faulty availability zone among at least two availability zones, wherein each of the at least two availability zones deploys a cloud service application; a judgment unit configured to determine whether the type of the fault is a preset type in response to detecting a faulty availability zone; and a switching unit configured to switch the application running in the faulty availability zone to a non-faulty availability zone in response to determining that the type of the fault is a preset type.

[0011] In some embodiments, the switching unit is further configured to forward requests to invoke applications running in a faulty availability zone to a non-faulty availability zone.

[0012] In some embodiments, the switching unit is further configured to: determine the availability zone with the lowest load among the non-faulty availability zones; and forward requests to invoke applications running in the faulty availability zone to the availability zone with the lowest load.

[0013] In some embodiments, the above-described apparatus further includes an output unit configured to output information about the availability zone of the fault and the type of fault in response to determining that the type of the fault is not a preset type.

[0014] In some embodiments, the apparatus further includes a deployment unit, through which the deployment of the at least two availability zones is completed. The deployment unit is configured to: determine whether the application of the cloud service needs to call other applications, wherein the other applications are applications other than the application of the cloud service; and in response to determining that other applications need to be called, deploy call ports for calling other applications in the at least two availability zones.

[0015] Thirdly, embodiments of this application provide a server, including: one or more processors; and a storage device storing one or more programs thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any embodiment of the first aspect.

[0016] Fourthly, embodiments of this application provide a computer-readable medium having a computer program stored thereon that, when executed by a processor, implements the method as described in any embodiment of the first aspect.

[0017] The disaster recovery method and apparatus for cloud services provided in the above embodiments of this application can first monitor whether there is a faulty availability zone among at least two availability zones. Each of the at least two availability zones deploys at least one application for the cloud service. If a faulty availability zone is detected, it is further determined whether the type of fault is a preset type. If so, the application running in the faulty availability zone is switched to run in a fault-free availability zone. The method of this embodiment can achieve automatic availability zone switching when an availability zone fails, thereby improving the reliability of the cloud service. Attached Figure Description

[0018] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0019] Figure 1 This is an exemplary system architecture diagram in which one embodiment of this application can be applied;

[0020] Figure 2 This is a flowchart of one embodiment of a disaster recovery method for cloud services according to this application;

[0021] Figure 3 This is a schematic diagram of an application scenario of the disaster recovery method for cloud services according to this application;

[0022] Figure 4 This is a flowchart of yet another embodiment of the disaster recovery method for cloud services according to this application;

[0023] Figure 5 This is a schematic diagram of a structure of an embodiment of a disaster recovery device for cloud services according to this application;

[0024] Figure 6 This is a schematic diagram of the structure of a computer system suitable for implementing the server embodiments of this application. Detailed Implementation

[0025] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0026] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0027] Figure 1 An exemplary system architecture 100 is shown, which is an embodiment of the cloud service disaster recovery method or cloud service disaster recovery apparatus to which the present application can be applied.

[0028] like Figure 1 As shown, system architecture 100 may include availability zones 101, 102, and 103, network 104, and scheduling server 105. Network 104 serves as the medium for providing communication links between availability zones 101, 102, and 103 and scheduling server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0029] Availability zones 101, 102, and 103 interact with scheduling server 105 via network 104 to receive or send messages, etc. Cloud service applications can be deployed on availability zones 101, 102, and 103. Users can send invocation requests for these applications to scheduling server 105 via terminal devices (not shown in the figure) to use cloud services. After receiving the invocation request, scheduling server 105 can forward the request to the corresponding availability zone.

[0030] Availability zones 101, 102, and 103 can include multiple servers, each running different applications to process different types of data. The servers in Availability zones 101, 102, and 103, as well as the scheduling server 105, can be either hardware or software. When the servers are hardware, they can be implemented as a distributed server cluster or as a single server. When the servers are software, they can be implemented as multiple software programs or software modules (e.g., used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0031] It should be noted that the disaster recovery method for cloud services provided in this application embodiment is generally executed by the scheduling server 105, and correspondingly, the disaster recovery device for cloud services is generally set in the scheduling server 105.

[0032] It should be understood that Figure 1 The number of availability zones, networks, and scheduling servers shown is merely illustrative. Any number of availability zones, networks, and scheduling servers can be used depending on implementation needs.

[0033] Continue to refer to Figure 2The flowchart 200 illustrates an embodiment of a disaster recovery method for cloud services according to this application. The disaster recovery method for cloud services of this embodiment includes the following steps:

[0034] Step 201: Monitor at least two availability zones for the presence of faulty availability zones.

[0035] In this embodiment, the entity executing the disaster recovery method of cloud services (e.g. Figure 1 The scheduling server 105 shown can pre-deploy cloud services in at least two availability zones, enabling each availability zone to independently run all applications of the cloud service after deployment. The cloud service may include at least one application, and each availability zone enhances the cloud service for users by running these applications. It is understood that in actual application after deployment, availability zones can be used in conjunction, meaning different availability zones can run a subset of cloud service applications, and the applications run in different availability zones can be different. For example, availability zones A, B, and C may each run a subset of cloud service applications; for instance, availability zone A runs application 'a', availability zone B runs application 'b', and availability zone C runs application 'c'. Then, for application 'a', availability zone A can serve as its primary availability zone, and availability zones B and C can serve as its backup availability zones. When availability zone A is unavailable, both availability zones B and C can still run application 'a'. This improves the utilization and operational efficiency of availability zones in practical applications.

[0036] The executing entity can monitor for faulty availability zones in various ways. For example, it can monitor availability zones by receiving heartbeat messages from each availability zone. If the executing entity does not receive a heartbeat message after a preset interval, it considers the availability zone to be faulty. Alternatively, the executing entity can monitor processes or ports to detect whether each availability zone is faulty.

[0037] In some optional implementations of this embodiment, the executing entity can... Figure 2 The following steps (not shown) are used to deploy the above-mentioned at least two availability zones: determining whether the cloud service application needs to call other applications, wherein the other applications are applications other than the cloud service application; in response to determining that other applications need to be called, deploying call ports for calling other applications in at least two availability zones.

[0038] In this implementation, the executing entity can first determine whether each application of the cloud service needs to call other applications. These other applications may include, for example, database applications. If each application needs to call these other applications, the cloud service is called a strongly dependent service. If the executing entity determines that the cloud service is a strongly dependent service, it can deploy call ports for calling other applications in each availability zone. This ensures that, after a switchover, applications running in the unaffected availability zones can still call other applications normally.

[0039] Step 202: In response to the detection of a faulty availability zone, determine whether the fault type is a preset type.

[0040] If the executing entity detects a faulty Availability Zone (Availability Zone), it can first determine the type of fault. Fault types can include Availability Zone downtime, power outage, network outage, or network congestion. The executing entity can determine the fault type in various ways. For example, it can determine the fault type based on received information or process identifiers. The preset type mentioned above can be an overall Availability Zone failure, meaning every server in the Availability Zone is unavailable. Such faults could include, for example, Availability Zone downtime, power outage, or network outage. These faults could be caused by natural disasters or carrier failures.

[0041] Step 203: In response to determining that the type of fault is a preset type, switch the application running in the faulty availability zone to run in the non-faulty availability zone.

[0042] In this embodiment, if the executing entity determines that the type of fault is a preset type, it can switch the application running in the faulty availability zone to run in a non-faulty availability zone. Specifically, the executing entity can send instructions to a non-faulty availability zone to cause at least one server in the availability zone to run the applications that were running in the faulty availability zone.

[0043] In some optional implementations of this embodiment, step 203 can be specifically implemented by... Figure 2 The following steps, not shown, are used to achieve this: forwarding requests to applications running in a faulty availability zone to a non-faulty availability zone.

[0044] In this implementation, the executing entity can forward call requests for applications running in a faulty availability zone to a fault-free availability zone. In this way, the fault-free availability zone can handle the aforementioned call requests, thus not affecting the user's experience of using cloud services.

[0045] In some optional implementations of this embodiment, the executing entity can also... Figure 2The following steps, not shown, are used to implement request forwarding: Identify the least loaded availability zone among the non-faulty availability zones; forward requests that invoke applications running in the faulty availability zone to the least loaded availability zone.

[0046] In this implementation, the executing entity can select an availability zone based on the principle of load balancing. That is, the executing entity can choose the availability zone with the least load and then forward the call request to the availability zone with the least load, thereby improving the processing efficiency of each availability zone.

[0047] See also Figure 3 , Figure 3 This is a schematic diagram illustrating an application scenario of the disaster recovery method for cloud services according to this embodiment. Figure 3 In the application scenario, when the scheduling server 301 detects a power outage in availability zone 302, it can switch the application running in availability zone 302 to the unaffected availability zone 303 so that availability zone 303 can process the data processed by availability zone 302.

[0048] The disaster recovery method for cloud services provided in the above embodiments of this application first monitors whether there is a faulty availability zone among at least two availability zones. Each of these at least two availability zones deploys cloud service applications. If a faulty availability zone is detected, it is further determined whether the type of fault is a preset type. If so, the application running in the faulty availability zone is switched to run in a fault-free availability zone. This method of the present embodiment can achieve automatic availability zone switching when an availability zone fails, thereby improving the reliability of cloud services.

[0049] See also Figure 4 This illustrates flow 400 of another embodiment of a disaster recovery method for cloud services according to this application. For example... Figure 4 As shown, the disaster recovery method for cloud services in this embodiment may include the following steps:

[0050] Step 401: Monitor at least two availability zones for the presence of faulty availability zones.

[0051] Step 402: In response to the detection of a faulty availability zone, determine whether the fault type is a preset type.

[0052] Step 403: In response to determining that the type of fault is a preset type, switch the application running in the faulty availability zone to run in the non-faulty availability zone.

[0053] The principles of steps 401 to 403 are similar to those of steps 202 to 203, and will not be repeated here.

[0054] Step 404: In response to determining that the type of fault is not the preset type, output the information of the available area of ​​the fault and the type of fault.

[0055] In this embodiment, if the executing entity determines that the type of fault in the availability zone is not a preset type, it can output the information of the faulty availability zone and the type of fault. The information of the faulty availability zone may include its location, identifier, the time the fault occurred, etc. The executing entity can also output the type of fault. In this way, the maintenance personnel of the availability zone can adjust the servers in the availability zone based on the output information to alleviate or resolve the aforementioned fault.

[0056] The disaster recovery method for cloud services provided in the above embodiments of this application can promptly switch availability zones when an availability zone becomes unavailable, thereby improving the reliability of the availability zone. Alternatively, it can promptly output fault information for technical personnel to review.

[0057] Further reference Figure 5 As an implementation of the methods shown in the above figures, this application provides an embodiment of a disaster recovery device for cloud services, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0058] like Figure 5 As shown, the disaster recovery device 500 for cloud services in this embodiment includes: a monitoring unit 501, a judgment unit 502, and a switching unit 503.

[0059] Monitoring unit 501 is configured to monitor at least two availability zones for the presence of faulty availability zones. Each of the at least two availability zones has a cloud service application deployed in it.

[0060] The judgment unit 502 is configured to determine whether the type of fault is a preset type in response to the detection of a faulty availability zone.

[0061] Switching unit 503 is configured to switch an application running in a faulty availability zone to a non-faulty availability zone in response to determining that the type of the fault is a preset type.

[0062] In some optional implementations of this embodiment, the switching unit 503 may be further configured to forward requests to invoke applications running in a faulty availability zone to a non-faulty availability zone.

[0063] In some optional implementations of this embodiment, the switching unit 503 may be further configured to: determine the availability zone with the least load among the non-faulty availability zones; and forward requests to invoke applications running in the faulty availability zone to the availability zone with the least load.

[0064] In some optional implementations of this embodiment, the device 500 may further include Figure 5 The output unit, not shown, is configured to output information about the available area of ​​the fault and the type of fault in response to determining that the type of fault is not a preset type.

[0065] In some optional implementations of this embodiment, the device 500 may further include Figure 5 The deployment unit is not shown in the diagram. Deployment in at least two availability zones is accomplished through the deployment unit, which is configured to: determine whether the cloud service's application needs to call other applications, wherein the other applications are applications other than the cloud service's application; and, in response to determining that other applications need to be called, deploy call ports for calling other applications in at least two availability zones.

[0066] It should be understood that units 501 to 503 described in the disaster recovery device 500 for cloud services are respectively related to the reference Figure 2 The steps described in the method correspond to those in the previous section. Therefore, the operations and features described above for the disaster recovery method of cloud services are also applicable to device 500 and the units contained therein, and will not be repeated here.

[0067] The following is for reference. Figure 6 It illustrates an electronic device suitable for implementing embodiments of the present disclosure (e.g., Figure 1 A schematic diagram of the structure of the scheduling server 105)600. Figure 6 The server shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0068] like Figure 6 As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0069] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 6 Each box shown can represent a device or multiple devices as needed.

[0070] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by a processing device 601, it performs the functions defined in the methods of embodiments of this disclosure. It should be noted that the computer-readable medium described in embodiments of this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0071] The aforementioned computer-readable medium may be included in the aforementioned server; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: monitor at least two availability zones for the existence of a faulty availability zone, wherein each of the at least two availability zones deploys an application for cloud services; in response to detecting a faulty availability zone, determine whether the type of fault is a preset type; and in response to determining that the type of fault is a preset type, switch the application running in the faulty availability zone to run in a non-faulty availability zone.

[0072] Computer program code for performing the operations of embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0073] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0074] The units described in the embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including a monitoring unit, a judgment unit, and a switching unit. The names of these units do not necessarily limit the specific unit; for example, a monitoring unit may also be described as "a unit that monitors whether at least two availability zones have faulty availability zones."

[0075] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for disaster recovery of a cloud service, comprising: monitoring whether there is a failed availability zone in at least two availability zones, wherein each of the at least two availability zones is deployed with an application of the cloud service; in response to monitoring that there is a failed availability zone, determining whether a type of the failure is a preset type; in response to determining that the type of the failure is the preset type, switching the application running in the failed availability zone to run in an unfailed availability zone, comprising: determining a least-loaded availability zone in the unfailed availability zones, forwarding a request for invoking the application running in the failed availability zone to the least-loaded availability zone, and processing the invoking request by the least-loaded availability zone running the application.

2. The method of claim 1, wherein, The method further comprises: in response to determining that the type of the failure is not the preset type, outputting information of the failed availability zone and the type of the failure.

3. The method of claim 1, wherein, The deployment of the at least two availability zones comprises the following steps: determining whether the application of the cloud service needs to invoke other applications, wherein the other applications are applications other than the application of the cloud service; in response to determining that the other applications need to be invoked, deploying an invoking port for invoking the other applications in the at least two availability zones. 4.A device for disaster recovery of a cloud service, comprising: a monitoring unit configured to monitor whether there is a failed availability zone in at least two availability zones, wherein each of the at least two availability zones is deployed with an application of the cloud service; a judging unit configured to, in response to monitoring that there is a failed availability zone, determine whether a type of the failure is a preset type; a switching unit configured to, in response to determining that the type of the failure is the preset type, switch the application running in the failed availability zone to run in an unfailed availability zone, comprising: determining a least-loaded availability zone in the unfailed availability zones, forwarding a request for invoking the application running in the failed availability zone to the least-loaded availability zone, and processing the invoking request by the least-loaded availability zone running the application.

5. The apparatus of claim 4, wherein, The device further comprises: an output unit configured to, in response to determining that the type of the failure is not the preset type, output information of the failed availability zone and the type of the failure.

6. The apparatus of claim 4, wherein, The device further comprises a deployment unit, and the deployment of the at least two availability zones is completed by the deployment unit, and the deployment unit is configured to: determine whether the application of the cloud service needs to invoke other applications, wherein the other applications are applications other than the application of the cloud service; in response to determining that the other applications need to be invoked, deploy an invoking port for invoking the other applications in the at least two availability zones. 7.A server, comprising: one or more processors; a storage device having one or more programs stored thereon, when the one or more programs are executed by the one or more processors, the one or more processors implement the method of any one of claims 1-3.

8. A computer readable medium having stored thereon a computer program, wherein, The program is executed by the processor to implement the method of any one of claims 1-3.

Images