CN116996174A - Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium - Google Patents

Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium Download PDF

Info

Publication number
CN116996174A
CN116996174A CN202311105494.5A CN202311105494A CN116996174A CN 116996174 A CN116996174 A CN 116996174A CN 202311105494 A CN202311105494 A CN 202311105494A CN 116996174 A CN116996174 A CN 116996174A
Authority
CN
China
Prior art keywords
available areas
service
application layer
end service
available
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202311105494.5A
Other languages
Chinese (zh)
Inventor
刘昌臻
朱明�
丁霞
王世杰
付虹博
何辉雄
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tianyi IoT Technology Co Ltd
Original Assignee
Tianyi IoT Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tianyi IoT Technology Co Ltd filed Critical Tianyi IoT Technology Co Ltd
Priority to CN202311105494.5A priority Critical patent/CN116996174A/en
Publication of CN116996174A publication Critical patent/CN116996174A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/22Arrangements for detecting or preventing errors in the information received using redundant apparatus to increase reliability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The embodiment of the application discloses a disaster recovery method, device, equipment and medium based on a multi-availability-zone internet of things platform. The method comprises the following steps: deploying different multiple available areas for clusters in a data layer; the nodes of the Kubernetes cluster in the application layer are evenly distributed in a plurality of available areas; deploying the ELB and load balancing component in a plurality of the available areas in the traffic layer; and if the back-end service is received, distributing the back-end service to a plurality of available areas of the application layer through the ELB and/or the load balancing component, and processing the back-end service by the plurality of available areas of the application layer. By implementing the method of the embodiment of the application, the problem of poor disaster recovery capability of the Internet of things can be solved, and the automatic switching of the service when the AZ level fault occurs can be realized.

Description

Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium
Technical Field
The application relates to the technical field of disaster recovery, in particular to a method, a device, equipment and a medium for disaster recovery based on a platform of an internet of things in a plurality of available areas.
Background
Along with the development of science and technology, people rely on the internet of things, so that service continuity needs to be ensured as much as possible in the face of various catastrophic events or faults, so that disaster recovery technology also develops rapidly, and a disaster recovery mode of two places and three centers of the same-city double centers and different-place disaster recovery centers appears.
Disclosure of Invention
The embodiment of the application provides a disaster recovery method, device, equipment and medium for an Internet of things platform based on multiple available areas, and aims to solve the problem of poor disaster recovery capacity of the Internet of things in the prior art.
In a first aspect, an embodiment of the present application provides a disaster recovery method for an internet of things platform based on multiple available areas, including: deploying different multiple available areas for clusters in a data layer; the nodes of the Kubernetes cluster in the application layer are evenly distributed in a plurality of available areas; deploying the ELB and load balancing component in a plurality of the available areas in the traffic layer; and if the back-end service is received, distributing the back-end service to a plurality of available areas of the application layer through the ELB and/or the load balancing component, and processing the back-end service by the plurality of available areas of the application layer.
In a second aspect, an embodiment of the present application further provides a disaster recovery device for an internet of things platform based on multiple available areas, including: the deployment unit is used for deploying different multiple available areas of the clusters in the data layer; the distribution unit is used for evenly distributing the nodes of the Kubernetes cluster in the application layer to a plurality of available areas; an opening unit, configured to deploy the ELB and the load balancing component to a plurality of the available areas in the traffic layer; and the distribution unit is used for distributing the back-end service to a plurality of available areas of the application layer through the ELB and/or the load balancing component if the back-end service is received, and processing the back-end service by the plurality of available areas of the application layer.
In a third aspect, an embodiment of the present application further provides a computer device, which includes a memory and a processor, where the memory stores a computer program, and the processor implements the method when executing the computer program.
In a fourth aspect, embodiments of the present application also provide a computer readable storage medium storing a computer program comprising program instructions which, when executed by a processor, implement the above-described method.
The embodiment of the application provides a disaster recovery method, device, equipment and medium based on a multi-availability-zone Internet of things platform. Wherein the method comprises the following steps: deploying different multiple available areas for clusters in a data layer; the nodes of the Kubernetes cluster in the application layer are evenly distributed in a plurality of available areas; deploying the ELB and load balancing component in a plurality of the available areas in the traffic layer; and if the back-end service is received, distributing the back-end service to a plurality of available areas of the application layer through the ELB and/or the load balancing component, and processing the back-end service by the plurality of available areas of the application layer. According to the embodiment of the application, the clusters in the data layer are deployed across the multiple available areas, so that the data are stored and backed up in the multiple available areas, the nodes of the Kubernetes clusters of the application layer are evenly distributed in the multiple available areas, the multiple available areas have the capability of running programs, and the back-end service is distributed to the multiple available areas in the application layer through the ELB and the load balancing component, so that the back-end service can be synchronized in the multiple available areas, the problems of isolation, disaster tolerance and elasticity of the Internet of things platform are jointly solved, the automatic service switching is realized when an AZ-level fault occurs, and clients do not feel.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic flow chart of a disaster recovery method based on a platform of internet of things in a multi-available area according to an embodiment of the present application;
fig. 2 is a schematic sub-flowchart of a disaster recovery method based on a platform of internet of things in a multi-available area according to an embodiment of the present application;
fig. 3 is a schematic sub-flowchart of a disaster recovery method based on a platform of internet of things in a multi-available area according to an embodiment of the present application;
fig. 4 is a structural deployment diagram of a disaster recovery method based on a platform of the internet of things in a multi-available area according to an embodiment of the present application;
FIG. 5 is a schematic block diagram of a disaster recovery device for an Internet of things platform based on multiple available areas according to an embodiment of the present application;
fig. 6 is a schematic block diagram of a computer device according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
It should be understood that the terms "comprises" and "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is also to be understood that the terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.
It should be further understood that the term "and/or" as used in the present specification and the appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes such combinations.
Referring to fig. 1, fig. 1 is a flow chart of a disaster recovery method for an internet of things platform based on multiple available areas according to an embodiment of the present application. The disaster recovery method based on the multi-available-area Internet of things platform in the embodiment can be applied to a disaster recovery scheme of the Internet of things platform, and the disaster recovery scheme in the prior art is modified from a data layer, a traffic layer and an application layer, so that AZ (available area) level disaster recovery multi-activity capability is provided from network access, application service, component service to a database service end-to-end, and business can be automatically switched when AZ level faults occur, so that influence on customers is avoided.
Fig. 1 is a flow chart of a disaster recovery method based on a platform of internet of things in a multi-available area according to an embodiment of the present application. As shown, the method includes the following steps S110-S140.
S110, deploying different multiple available areas for clusters in the data layer.
In this embodiment, the data layer has a database cluster for an architecture of the internet of things; the cluster is a computer system that can be connected by a set of loosely-integrated computer software and/or hardware to perform computing work in a highly-tightly coordinated manner; the plurality of available areas refer to data centers which are isolated from each other in the same area and have independent power supply and networks. The three available areas are the smallest deployment areas, which are interconnected by high-speed networks within different failure domains. Clusters in a traffic layer in an internet of things architecture are deployed in a plurality of available areas, which in this embodiment are 3 available areas. By disposing different multiple available areas of the clusters in the data layer, the data in the data layer can be synchronized with the multiple available areas, and synchronization and backup of the data are completed, so that when one available area fails, other available areas can still maintain normal operation.
In one embodiment, as shown in FIG. 2, the step S110 further includes steps S111-S113.
S111, deploying the distributed object storage clusters in a plurality of available areas by adopting a preset node distribution method;
s112, deploying the distributed database cluster and the distributed cache cluster in a plurality of available areas by adopting a preset node deployment mode;
s113, deploying the Hadoop clusters in a plurality of available areas by adopting a preset copy framework mode.
In this embodiment, the object storage cluster refers to a cluster formed by a service for storing any object. The database cluster means that at least two or more database servers are utilized to form a virtual single database logical image so as to provide transparent data service for clients, for example, mysql distributed cluster and Redis database are both database clusters. The cache cluster refers to a ring-shaped cluster which is formed by one or more cache main services and stores distributed data together. The distributed computing mode is that tasks are obtained from one or more computer nodes, the tasks are divided into acceptable micro tasks, and one task is completed jointly by the distributed computing mode and a plurality of computer networks according to different computing functions applied to different computer nodes. The Hadoop cluster is a distributed system of computers that work cooperatively to store and process large-scale data sets. The preset node distribution method is to uniformly distribute nodes in the distributed object storage cluster in a plurality of available areas, for example, six nodes and 3 available areas in the distributed object storage cluster, then each available area is distributed with two data nodes, and if 4 nodes can be normally used after a single available area fails, the remaining available nodes are more than one half of the distributed object storage nodes, so that normal storage and calling of objects in a data layer can be ensured. The preset node deployment mode is a master-slave mode, wherein one master-slave mode means that two slave nodes synchronously perform data synchronization on one master node, specifically, one node in the distributed cache cluster and the distributed database cluster is used as a master node to be placed in an available area, and the remaining two available areas are used for placing slave nodes. The distributed cache Cluster adopts a Cluster mode (the Cluster is a Cluster mode, and the Cluster manages data through a slicing mode and has the capabilities of data replication, fault transfer and traffic scheduling among slices). The preset copy frame mode is that a 3-copy mode is stored in different RACK (RACK refers to a frame structure used for storing and organizing electronic equipment in a data center), specifically, RACK is stored in different three available areas, the Hadoop cluster is stored in RACK according to a three-copy mode, and three copies refer to the storage of copying three copies of data on a network. The distributed object storage clusters, the distributed database clusters and the distributed cache clusters are deployed in a plurality of available areas by using different preset methods, and the Hadoop clusters are deployed in a plurality of available areas by adopting a preset copy framework mode, so that the availability and the load balancing capability of data can be improved, and meanwhile, the reading speed of the data can be improved, and when a master node breaks down, master-slave switching can be realized by lifting a slave node to be the master node, so that the availability and consistency of the data are ensured, and meanwhile, the loss of the data can be avoided.
S120, evenly distributing the nodes of the Kubernetes cluster in the application layer to a plurality of available areas.
In this embodiment, the application layer is a service system established based on the platform of the internet of things, for example, energy management, fire control monitoring, intelligent park, etc., and is a link that the internet of things really generates value for users and solves the core demands of the users. The Kubernetes cluster is a cluster of nodes running a containerized application. The nodes of the Kubernetes cluster in the application layer are uniformly distributed in a plurality of available areas, for example, 18 nodes and three available areas, and then each available area is distributed with 6 nodes. The nodes of the Kubernetes cluster are evenly distributed in the plurality of available areas, so that the plurality of available areas have the service processing capability, and if one of the available areas fails, the rest available areas can still process the service normally.
In this embodiment, the method further includes adding ECSs of the plurality of available areas to nodes of the Kubernetes cluster. Wherein the ECS is a flexible computing service, and the ECS can provide a stable and reliable cloud computing infrastructure. And adding ECSs of a plurality of available areas on the nodes of the Kubernetes cluster, specifically, the cluster nodes are distributed in a plurality of available areas, node A is added in an a available area, ESCs of the a available area are added in the node A, node B is added in a c available area, and ESCs of the c available area are added in the node B.
In this embodiment, the method further includes scheduling the microservices of the application layer in a plurality of the available areas in a multi-instance manner; and deploying the access service, the message queue and the CCSE in the application layer in a plurality of available areas, wherein each service module is stateless and deployed on the CCSE. The micro service is a service which focuses on single responsibility and business function, has independent processes, can be independently operated, and is in interactive communication with external service through HTTP; the multiple instances are multiple instances when there are multiple work items or activity instances for an activity in one flow instance, and the CCSE is a common communication switching device. The micro-service in the application layer adopts a multi-instance mode, free scheduling in a plurality of available areas can be realized, access service, message queues and CCSE in the application layer are all deployed into clusters which can be scheduled in the plurality of available areas, and the service module without a state of the service module can operate in any one of the available areas and is deployed on the CCSE. In summary, by adding a plurality of ECSs of the available areas to the nodes of the Kubernetes cluster in the application layer and setting the deployment of other clusters, the application layer of the available area can still normally maintain operation when the application layer of the available area fails, so that the user does not feel the failure.
S130, the ELB and the load balancing component are deployed in a plurality of available areas in a traffic layer.
In this embodiment, the ELB is an Elastic LoadBalance (CT-ELB) that can extend service capability of an application system to the outside by automatically distributing access traffic to multiple cloud hosts. The load balancing component is composed of a plurality of servers in a symmetrical mode, can independently provide services to the outside without assistance of other servers, and comprises a plurality of components such as nginx, haproxy, LVS. For example, the LVS may be deployed in a traffic layer in a master-slave manner, and the ELB may be turned on, and the ELB and the load balancing component may be deployed in the traffic layer, which is not limited. By deploying the ELB and the load balancing component in a plurality of the available areas in the traffic layer, the traffic layer can realize the traffic crossing of multiple available areas by means of the crossing available area deployment capability of the ELB.
And S140, if the back-end service is received, distributing the back-end service to a plurality of available areas of the application layer through the ELB and/or the load balancing component, and processing the back-end service by the plurality of available areas of the application layer.
In this embodiment, the backend service is responsible for managing data of an application program, including storing, reading, updating, and deleting data. Data manipulation and querying may be performed in interaction with a database or other data storage system. Specifically, if the backend service initiated by the user or the device is received, the backend service is distributed to a plurality of available areas of the application layer through the ELB and the load balancing component, fig. 4 is a structural deployment diagram, and if the backend service initiated by the user is shown in fig. 4, the short enough service can be sent to a plurality of available areas of the application layer according to the ELB and the rginx, and then the data in the data layer is called by a cluster deployed in the available areas to process the data. Traffic may be synchronized to multiple availability zones through use of the ELB and/or the load balancing component.
In one embodiment, as shown in FIG. 3, the step S140 further includes steps S141-S142.
S141, judging the service type of the back-end service;
and S142, if the service type is an access request, distributing the back-end service to a plurality of available areas of the application layer through the ELB and the Nginx.
In this embodiment, the nginnx is the load balancing component. Judging the service type of the back-end service, specifically, the service type of the back-end service may be judged according to a server port of the back-end service, for example, if the port is web initiated, the back-end service may be judged to be an access request service sent by a user through a public network DNS. As shown in fig. 4, different forwarding modes may be performed according to the determined service type. It should be noted that, the service types of the back-end service initiated by the internal system through the ELB intranet address and the back-end service sent by the user through the public network DNS are both access requests. And if the service type is an access request, distributing the back-end service to the Nginx of each available area in the traffic layer through the ELB, and then sending the back-end service to a plurality of the available areas of the application layer through the Nginx. By judging the service type of the back-end service, a more suitable distribution mode can be executed according to different service types.
In an embodiment, as shown in fig. 3, the step S140 further includes a step S143.
And S143, if the service type is a TCP-based protocol initiated by the equipment, distributing the back-end service to a plurality of available areas of the application layer through the ELB and the haproxy.
In this embodiment, the haproxy is the load balancing component, and the TCP is a transmission control protocol (TCP, transmission Control Protocol) that is a connection-oriented, reliable, byte-stream-based transport layer communication protocol. If the service type is judged to be a TCP-based protocol initiated by a device according to a port of a back-end service, such as an MQTT protocol, or a TLS protocol (secure transport layer protocol) on a TCP layer protocol, distributing the back-end service to a plurality of available areas of the application layer through the ELB and the haproxy, specifically, sending the back-end service to the haproxy in the traffic layer through the ELB, and then distributing the back-end service to EMQ in a plurality of available areas of the application layer through the haproxy, wherein the EMQ is an open source Internet of things MQTT message server; in the case of a protocol on the TCP layer protocol, but not the TLS protocol, the backend service is distributed directly by the ELB to EMQs in a plurality of the available regions of the application layer. And distributing the back-end service initiated by the device to a plurality of available areas of the application layer by the ELB and the haproxy, so that the back-end service is synchronous with the plurality of available areas.
In an embodiment, as shown in fig. 3, the step S140 further includes a step S144.
And S144, if the service type is a UDP-based protocol initiated by equipment, distributing the back-end service to a plurality of available areas of the application layer through pgw and the LVS.
In this embodiment, the UDP protocol is the user datagram protocol (UDP, user Datagram Protocol), which provides a method for an application to send encapsulated IP packets without establishing a connection. The pgw is a packet gateway. The LVS is a Linux virtual server and is one of the load balancing components. If the service type is a UDP-based protocol initiated by a device, such as LWM2M protocol, the backend service is directly sent to the LVS in the traffic layer through pgw, and then the LVS distributes the backend service to the EMQ in the multiple available areas of the application layer. Through pgw and the LVS, a UDP-based protocol can be sent to a plurality of available areas of the application layer, so that the back-end service synchronization in the plurality of available areas is realized. So that the remaining available areas can still normally process the back-end service when one available area fails.
Fig. 5 is a schematic block diagram of a disaster recovery device 200 for an internet of things platform based on multiple available areas according to an embodiment of the present application. As shown in fig. 5, the present application further provides a disaster recovery device for an internet of things platform based on multiple available areas, corresponding to the above disaster recovery method for an internet of things platform based on multiple available areas. The multi-usable-area-based internet of things platform disaster recovery device comprises a unit for executing the multi-usable-area-based internet of things platform disaster recovery method, and the device can be configured in a desktop computer, a tablet computer, a portable computer, and other terminals. Specifically, referring to fig. 5, the disaster recovery device for an internet of things platform based on multiple available areas includes a deployment unit 210, a distribution unit 220, an opening unit 230, and a distribution unit 240.
A deployment unit 210, configured to deploy clusters in the data layer into different multiple available areas.
In one embodiment, the deployment unit 210 includes a first deployment unit, a second deployment unit, and a third deployment unit.
The first deployment unit is used for deploying the distributed object storage clusters in a plurality of available areas by adopting a preset node distribution method;
the second deployment unit is used for deploying the distributed database cluster and the distributed cache cluster in a plurality of available areas by adopting a preset node deployment mode;
and the third deployment unit is used for deploying the Hadoop clusters in a plurality of available areas by adopting a preset copy framework mode.
A distribution unit 220, configured to evenly distribute the nodes of the Kubernetes cluster in the application layer over a plurality of the available areas.
In an embodiment, the distribution unit 220 comprises an adding unit.
And the adding unit is used for adding ECSs of a plurality of available areas on the nodes of the Kubernetes cluster.
An opening unit 230, configured to deploy the ELB and the load balancing component to a plurality of the available areas in the traffic layer;
and the distributing unit 240 is configured to, when receiving a back-end service, distribute, by the ELB and/or the load balancing component, the back-end service to a plurality of the available areas of the application layer, and process the back-end service by the plurality of the available areas of the application layer.
In one embodiment, the distributing unit 240 includes a judging unit, a first distributing unit, a second distributing unit, and a third distributing unit.
The judging unit is used for judging the service type of the back-end service;
and the first distribution unit is used for distributing the back-end service to a plurality of available areas of the application layer through the ELB and the Nginx if the service type is an access request.
And the second distributing unit is used for distributing the back-end service to a plurality of available areas of the application layer through the ELB and the haproxy if the service type is a TCP-based protocol initiated by equipment.
And the third distributing unit is used for distributing the back-end service to a plurality of available areas of the application layer through pgw and the LVS if the service type is a UDP-based protocol initiated by equipment.
It should be noted that, as can be clearly understood by those skilled in the art, the specific implementation process of the disaster recovery device 200 and the units based on the internet of things platform in the multiple available areas can refer to the corresponding description in the foregoing method embodiment, and for convenience and brevity of description, the description is omitted herein.
The disaster recovery device based on the internet of things platform with multiple available areas can be implemented as a form of a computer program, and the computer program can be run on a computer device as shown in fig. 6.
Referring to fig. 6, fig. 6 is a schematic block diagram of a computer device according to an embodiment of the present application. The computer device 500 may be a terminal or a server, where the terminal may be an electronic device with a communication function, such as a smart phone, a tablet computer, a notebook computer, a desktop computer, a personal digital assistant, and a wearable device. The server may be an independent server or a server cluster formed by a plurality of servers.
With reference to FIG. 6, the computer device 500 includes a processor 502, memory, and a network interface 505 connected by a system bus 501, where the memory may include a non-volatile storage medium 503 and an internal memory 504.
The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform a multi-availability zone based internet of things platform disaster recovery method.
The processor 502 is used to provide computing and control capabilities to support the operation of the overall computer device 500.
The internal memory 504 provides an environment for the execution of a computer program 5032 in the non-volatile storage medium 503, which computer program 5032, when executed by the processor 502, causes the processor 502 to perform a disaster recovery method based on the multi-availability zone internet of things platform.
The network interface 505 is used for network communication with other devices. It will be appreciated by those skilled in the art that the architecture shown in fig. 6 is merely a block diagram of some of the architecture relevant to the present inventive arrangements and is not limiting of the computer device 500 to which the present inventive arrangements may be implemented, as a particular computer device 500 may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.
Wherein the processor 502 is adapted to run a computer program 5032 stored in a memory for implementing the steps of the above method.
It should be appreciated that in embodiments of the present application, the processor 502 may be a central processing unit (Central Processing Unit, CPU), the processor 502 may also be other general purpose processors, digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), off-the-shelf Programmable gate arrays (FPGAs) or other Programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or the like. Wherein the general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
Those skilled in the art will appreciate that all or part of the flow in a method embodying the above described embodiments may be accomplished by computer programs instructing the relevant hardware. The computer program comprises program instructions, and the computer program can be stored in a storage medium, which is a computer readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the flow steps of the embodiments of the method described above.
Accordingly, the present application also provides a storage medium. The storage medium may be a computer readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. The program instructions, when executed by a processor, cause the processor to perform the steps of the method as described above.
The storage medium may be a U-disk, a removable hard disk, a Read-Only Memory (ROM), a magnetic disk, or an optical disk, or other various computer-readable storage media that can store program codes.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the device embodiments described above are merely illustrative. For example, the division of each unit is only one logic function division, and there may be another division manner in actual implementation. For example, multiple units or components may be combined or may be integrated into another system, or some features may be omitted, or not performed.
The steps in the method of the embodiment of the application can be sequentially adjusted, combined and deleted according to actual needs. The units in the device of the embodiment of the application can be combined, divided and deleted according to actual needs. In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.
The integrated unit may be stored in a storage medium if implemented in the form of a software functional unit and sold or used as a stand-alone product. Based on such understanding, the technical solution of the present application is essentially or a part contributing to the prior art, or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a terminal, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application.
While the application has been described with reference to certain preferred embodiments, it will be understood by those skilled in the art that various changes and substitutions of equivalents may be made and equivalents will be apparent to those skilled in the art without departing from the scope of the application. Therefore, the protection scope of the application is subject to the protection scope of the claims.

Claims (10)

1. The disaster recovery method based on the multi-availability-zone Internet of things platform is characterized by comprising the following steps:
deploying different multiple available areas for clusters in a data layer;
the nodes of the Kubernetes cluster in the application layer are evenly distributed in a plurality of available areas;
deploying the ELB and load balancing component in a plurality of the available areas in the traffic layer;
and if the back-end service is received, distributing the back-end service to a plurality of available areas of the application layer through the ELB and/or the load balancing component, and processing the back-end service by the plurality of available areas of the application layer.
2. The method of claim 1, wherein the cluster comprises: the step of deploying different multiple available areas for the clusters in the data layer comprises the following steps:
deploying the distributed object storage clusters in a plurality of available areas by adopting a preset node distribution method;
deploying the distributed database cluster and the distributed cache cluster in a plurality of available areas by adopting a preset node deployment mode;
and deploying the Hadoop clusters in a plurality of available areas by adopting a preset copy framework mode.
3. The method of claim 1, wherein the step of evenly distributing nodes of Kubernetes clusters in an application layer over a plurality of the available regions comprises:
and adding ECSs of a plurality of available areas on the nodes of the Kubernetes cluster.
4. The method of claim 1, wherein the load balancing component comprises: -ng nx, said step of distributing said backend services into a plurality of said available areas of said application layer by said ELB and/or said load balancing component, comprising:
judging the service type of the back-end service;
and if the service type is an access request, distributing the back-end service to a plurality of available areas of the application layer through the ELB and the Nginx.
5. The method of claim 4, wherein the load balancing component comprises: and after the step of judging the service type of the back-end service, the method further comprises the steps of:
and if the service type is a TCP-based protocol initiated by equipment, distributing the back-end service to a plurality of available areas of the application layer through the ELB and the haproxy.
6. The method of claim 4, wherein the load balancing component comprises: LVS, after the step of judging the service type of the back-end service, further comprises:
and if the service type is a device initiated UDP based protocol, distributing the backend service to a plurality of available areas of the application layer through pgw and the LVS.
7. The method according to claim 1, characterized in that:
scheduling the microservices of the application layer in a plurality of available areas in a multi-instance mode;
and deploying the access service, the message queue and the CCSE in the application layer in a plurality of available areas, wherein each service module is stateless and deployed on the CCSE.
8. The utility model provides a based on multi-availability district thing networking platform disaster recovery device which characterized in that includes:
the deployment unit is used for deploying different multiple available areas of the clusters in the data layer;
the distribution unit is used for evenly distributing the nodes of the Kubernetes cluster in the application layer to a plurality of available areas;
an opening unit, configured to deploy the ELB and the load balancing component to a plurality of the available areas in the traffic layer;
and the distribution unit is used for distributing the back-end service to a plurality of available areas of the application layer through the ELB and/or the load balancing component if the back-end service is received, and processing the back-end service by the plurality of available areas of the application layer.
9. A computer device, characterized in that it comprises a memory on which a computer program is stored and a processor which, when executing the computer program, implements the method according to any of claims 1-7.
10. A storage medium storing a computer program comprising program instructions which, when executed by a processor, implement the method of any one of claims 1-7.
CN202311105494.5A 2023-08-30 2023-08-30 Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium Pending CN116996174A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311105494.5A CN116996174A (en) 2023-08-30 2023-08-30 Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311105494.5A CN116996174A (en) 2023-08-30 2023-08-30 Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium

Publications (1)

Publication Number Publication Date
CN116996174A true CN116996174A (en) 2023-11-03

Family

ID=88523256

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311105494.5A Pending CN116996174A (en) 2023-08-30 2023-08-30 Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium

Country Status (1)

Country Link
CN (1) CN116996174A (en)

Similar Documents

Publication Publication Date Title
US10735509B2 (en) Systems and methods for synchronizing microservice data stores
TWI724106B (en) Business flow control method, device and system between data centers
US11354336B2 (en) Fault-tolerant key management system
CN107707393B (en) Multi-active system based on Openstack O version characteristics
CN112671882B (en) Same-city double-activity system and method based on micro-service
EP2347563B1 (en) Distributed master election
US7370336B2 (en) Distributed computing infrastructure including small peer-to-peer applications
EP1963985B1 (en) System and method for enabling site failover in an application server environment
US20190235979A1 (en) Systems and methods for performing computing cluster node switchover
CN113572831B (en) Communication method, computer equipment and medium between Kubernetes clusters
US9992058B2 (en) Redundant storage solution
US10652100B2 (en) Computer system and method for dynamically adapting a software-defined network
CN115576655B (en) Container data protection system, method, device, equipment and readable storage medium
CN113709220B (en) High-availability implementation method and system of virtual load equalizer and electronic equipment
WO2012171346A1 (en) Telephone number mapping-domain name system (enum-dns) and disaster tolerance method thereof
CN114338670A (en) Edge cloud platform and three-level cloud control platform for internet traffic with same
WO2012037310A1 (en) System including a middleware machine environment
CN110351122B (en) Disaster recovery method, device, system and electronic equipment
CN112231399A (en) Method and device applied to graph database
CN115967611B (en) Cross-domain switching processing method, device, equipment and storage medium
CN116996174A (en) Multi-availability-zone-based Internet of things platform disaster recovery method, device, equipment and medium
Shih et al. Service recovery for large scale distributed publish and subscription services for cyber-physical systems and disaster management
CN114666087B (en) Safety redundancy
Taniguchi et al. Architecture of Connectivity-aware Redundancy Control Module for Distributed Resource Management in InfaaS-AP
Lin et al. Dual-uCPE for High-Availability Retailer Services with Fault Toleranceand Load Balancing

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination