CN109842505A - A kind of cloud clustering fault processing method and processing device - Google Patents
A kind of cloud clustering fault processing method and processing device Download PDFInfo
- Publication number
- CN109842505A CN109842505A CN201711204632.XA CN201711204632A CN109842505A CN 109842505 A CN109842505 A CN 109842505A CN 201711204632 A CN201711204632 A CN 201711204632A CN 109842505 A CN109842505 A CN 109842505A
- Authority
- CN
- China
- Prior art keywords
- host
- heartbeat
- target host
- heartbeat information
- service
- 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
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 8
- 238000012545 processing Methods 0.000 title abstract description 5
- 238000000034 method Methods 0.000 claims abstract description 27
- 238000011084 recovery Methods 0.000 claims abstract description 7
- 238000001514 detection method Methods 0.000 claims description 15
- 238000004590 computer program Methods 0.000 claims description 5
- 230000008439 repair process Effects 0.000 claims description 3
- 230000006870 function Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 238000013135 deep learning Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 210000001503 joint Anatomy 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Landscapes
- Hardware Redundancy (AREA)
Abstract
The embodiment of the invention discloses a kind of cloud clustering fault processing method and processing devices to confirm the destination host failure if method includes: that the backup host of cloud cluster does not receive the heartbeat message of destination host within a preset period of time；The service for taking over the destination host continues to run, so that the destination host is restarted or repaired offline；If receiving the heartbeat message of the destination host, confirm that the destination host restores normal, and each service of operation is switched back into the destination host and is run.The backup host that the embodiment of the present invention passes through setting cloud cluster, the service of the destination host of the cloud cluster to be broken down by backup host adapter tube continues to run, and after destination host recovery, service is switched back into destination host operation, the function of backup host is more simple compared with ATS system, switch it is more convenient, to improve the operational efficiency of whole system.
Description
Technical Field
The embodiment of the invention relates to the technical field of rail transit, in particular to a cloud cluster fault processing method and device.
Background
High availability technology is a technology that is of increasing interest in the field of rail transit. The availability of a rail transit system is measured in terms of the mean time to failure, i.e. how long the computer system can operate normally on average, before a failure occurs.
The current rail transit system equipment centralized station is responsible for controlling and dispatching trains, and the centralized station comprises ATS (automatic train protection) extension, ZC, interlocking and other systems. In order to improve the availability of the system, the ATS, the ZC and the interlock adopt dual-computer hot standby. The dual-computer hot standby scheme has the advantages that when one server fails, the system can be switched to the standby server to operate immediately, and the system cannot be interrupted to operate due to service failure or system downtime.
However, the ATS is responsible for complex functions such as system scheduling planning, interfacing with a fare collection system, operating pressure prediction and train allocation, machine vision, machine learning, etc. In a certain line, a plurality of stations have huge passenger flow, and the ATS system can distribute trains of other stations with small flow to stations with large passenger flow. And the ATS deep learning function is used for learning and predicting the passenger flow of the next day or the next days through the butt joint with the ticket selling and checking system, and allocating an idle train to a station with large flow in advance.
In the existing method, the operation efficiency of the system is low due to the complex function of the ATS system in the centralized station.
Disclosure of Invention
Because the existing method has the problems, the embodiment of the invention provides a cloud cluster fault processing method and device.
In a first aspect, an embodiment of the present invention provides a cloud cluster fault handling method, including:
if the standby host of the cloud cluster does not receive heartbeat information of a target host within a preset time period, confirming that the target host fails;
taking over the service of the target host to continue running so as to enable the target host to carry out offline restart or repair;
and if the heartbeat information of the target host is received, confirming that the target host is recovered to be normal, and switching each running service back to the target host to run.
Optionally, if the standby host of the cloud cluster does not receive heartbeat information of the target host within a preset time period, before determining that the target host fails, the method further includes:
the standby host of the cloud cluster receives heartbeat information of the target host through the main heartbeat line, and if the main heartbeat line fails, the standby host receives the heartbeat information of the target host through the standby heartbeat line.
Optionally, the heartbeat message includes host hardware heartbeat information, host network heartbeat information, host operating system heartbeat information, application heartbeat information, and host and disk array connection heartbeat information.
Optionally, the method further comprises:
setting a detection time interval and detection times of heartbeat information in a heartbeat configuration file, and receiving the heartbeat information of a target host according to the heartbeat configuration file.
In a second aspect, an embodiment of the present invention further provides a cloud cluster fault processing apparatus, including:
the fault confirming module is used for confirming that the target host machine is in fault if the heartbeat information of the target host machine is not received within a preset time period;
the service takeover module is used for taking over the service of the target host to continue running so as to enable the target host to be restarted or repaired off line;
and the service recovery module is used for confirming that the target host recovers to be normal and switching each running service back to the target host to run if the heartbeat information of the target host is received.
Optionally, the apparatus further comprises:
and the heartbeat receiving module is used for receiving the heartbeat information of the target host through the main heartbeat line, and if the main heartbeat line fails, the heartbeat information of the target host is received through the standby heartbeat line.
Optionally, the heartbeat message includes host hardware heartbeat information, host network heartbeat information, host operating system heartbeat information, application heartbeat information, and host and disk array connection heartbeat information.
Optionally, the apparatus further comprises:
the file setting module is used for setting the detection time interval and the detection times of the heartbeat information in the heartbeat configuration file and receiving the heartbeat information of the target host according to the heartbeat configuration file.
In a third aspect, an embodiment of the present invention further provides an electronic device, including:
at least one processor; and
at least one memory communicatively coupled to the processor, wherein:
the memory stores program instructions executable by the processor, which when called by the processor are capable of performing the above-described methods.
In a fourth aspect, an embodiment of the present invention further provides a non-transitory computer-readable storage medium storing a computer program, which causes the computer to execute the above method.
According to the technical scheme, the standby host of the cloud cluster is set, the standby host takes over the service of the target host of the failed cloud cluster to continue running, and the service is switched back to the target host to run after the target host is recovered, so that the function of the standby host is simpler than that of an ATS (automatic train switching) system, the switching is more convenient, and the running efficiency of the whole system is improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to these drawings without creative efforts.
Fig. 1 is a schematic flow chart of a cloud cluster fault handling method according to an embodiment of the present invention;
fig. 2 is a schematic network connection diagram of a cloud cluster according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of a cloud cluster fault handling apparatus according to an embodiment of the present invention;
fig. 4 is a logic block diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
The following further describes embodiments of the present invention with reference to the accompanying drawings. The following examples are only for illustrating the technical solutions of the present invention more clearly, and the protection scope of the present invention is not limited thereby.
Fig. 1 shows a schematic flow chart of a cloud cluster fault processing method provided in this embodiment, including:
s101, if the standby host of the cloud cluster does not receive heartbeat information of the target host within a preset time period, determining that the target host fails.
The heartbeat message comprises host hardware heartbeat information, host network heartbeat information, host operating system heartbeat information, application program heartbeat information and host and disk array connection heartbeat information.
The cloud cluster comprises a plurality of hosts, each host is a server, operates corresponding service, and provides service for ATS (automatic train protection), ZC (zone controller), interlocking and other equipment. The cloud end adopts a plurality of servers to form a cluster, so that high availability, safe and stable operation of functions such as ATS (automatic transfer system) of the cloud end can be guaranteed.
The target host is a host running each service, and the standby host is a host running the service when the target host fails.
S102, taking over the service of the target host to continue running so as to enable the target host to be restarted or repaired off line.
Specifically, the standby host of the cloud cluster takes over the service of the target host to continue running, and the service is guaranteed to be uninterrupted. After the standby host takes over, the target host carries out operations such as off-line restarting or repairing and the like so as to recover the service function as soon as possible.
S103, if the heartbeat information of the target host is received, the target host is confirmed to be recovered to be normal, and each running service is switched back to the target host to run.
Specifically, once the target host can be normally served after being restarted or repaired, the heartache information is continuously sent to the standby host to inform the standby host that the functions of the standby host are normal, and after the standby host confirms that the target host is recovered to be normal, each running service is switched back to the target host to run.
The cloud cluster fault processing method provided by the embodiment is suitable for clusters of two or more rail transit cloud server centers. Multiple hosts (servers) work together, each running one or several services, each defining one or more standby hosts for a service, and when a host fails, the service running on it can be taken over by other hosts.
Specifically, the software on the host computer realizes automatic monitoring through heartbeat lines, and the condition of the operation of the other side is detected mutually through a heartbeat monitoring program, and the checked items are as follows: host hardware (CPU and peripherals), host network, host operating system, application programs, host and disk array connections. Meanwhile, the system can be automatically switched, and if a certain host confirms that the other host fails, the slave takes over the service of the host to continue running. In addition, the system can also automatically recover, and the fault host can be restarted off line after the normal host replaces the fault host to work. After the failed host is restarted, the failed host is connected with the original normal host through the heartbeat line, and the host is automatically switched back to the host after the repair is finished. The completion of the whole recovery process is automatically completed by the heartbeat.
In this embodiment, the standby host of the cloud cluster is set, the service of the target host of the cloud cluster with the fault is taken over to continue to operate through the standby host, and after the target host is recovered, the service is switched back to the target host to operate, and the function of the standby host is simpler than that of an ATS (automatic train maintenance) system, and the switching is more convenient, so that the operating efficiency of the whole system is improved.
Further, on the basis of the above embodiment of the method, before S101, the method further includes:
s100, receiving heartbeat information of a target host by a standby host of the cloud cluster through a main heartbeat line, and if the main heartbeat line fails, receiving the heartbeat information of the target host through a standby heartbeat line.
Specifically, the two heartbeat lines, namely the main heartbeat line and the passive heartbeat line, are included in this embodiment, and when the standby heartbeat line is adopted to prevent the main heartbeat line from failing, the heartbeat can still be normally transmitted through the standby heartbeat line.
Further, on the basis of the above embodiment of the method, the method further comprises:
s1001, setting a detection time interval and detection times of heartbeat information in a heartbeat configuration file, and receiving the heartbeat information of a target host according to the heartbeat configuration file.
By setting the heartbeat configuration file, a user can conveniently set the detection time interval and the detection times according to different requirements, the safety factor can be conveniently adjusted, and meanwhile, the standby host of the cloud cluster can conveniently read the heartbeat configuration file.
In the embodiment, each server (host) in the cloud cluster automatically detects and performs data communication through two heartbeat lines; the operation efficiency of the ATS of the ground equipment concentration station is improved through the cloud cluster; the cloud system is automatically switched and recovered, the system can be automatically restarted and recovered after being automatically switched, and the original host is switched back after the system is successfully restarted. The operation efficiency of the original ground equipment centralized station ATS is improved; the continuous, stable and stable operation of the cloud system is guaranteed; the automatic recovery of the cloud cluster is ensured.
For example, as shown in fig. 2, taking the minimum cluster device of the server device a and the server device B as an example, after the configuration of the primary server, the primary server records debug information of heartbeat, sets the heartbeat (monitoring) time to be 2 seconds, specifies that if the standby node does not receive the primary node heartbeat signal within 30 seconds, the standby node takes over the resources of the primary server, specifies that the time of the heartbeat delay is 10 seconds, and specifies that the standby node cannot receive the primary node heartbeat signal within 10 seconds, i.e., writes a warning log into the log, but does not switch the service. The steps of S101-S103 may be executed upon completion of the configuration. The reserved neglected time period after the system is started or restarted takes a value at least twice as large as dead time, a Udp port is used for broadcast/unicast communication, a network card eno16777736 is used for sending heartbeat detection M, and Udp multicast of a network card eth0 is used for organizing heartbeats, which is generally used when more than one standby node exists. Bcast, ucast and mcast respectively represent broadcasting, unicasting and multicasting, which are modes for organizing heartbeats, and any one of the modes is selected; the heartbeat is organized using udp unicast of the network card ens33, followed by the IP address of the dual peer IP address M. It should be noted that, the network connectivity condition may be tested by the ping gateway detecting whether the heartbeat is normal.
Fig. 3 shows a schematic structural diagram of a cloud cluster fault processing apparatus provided in this embodiment, where the apparatus includes: a failure confirmation module 301, a service takeover module 302, and a service restoration module 303, wherein:
the fault confirming module 301 is configured to confirm that the target host is faulty if heartbeat information of the target host is not received within a preset time period;
the service takeover module 302 is configured to take over the service of the target host to continue running, so that the target host is restarted or repaired offline;
the service recovery module 303 is configured to, if the heartbeat information of the target host is received, confirm that the target host recovers to be normal, and switch each running service back to the target host for running.
Specifically, if the heartbeat information of the target host is not received within a preset time period, the fault confirmation module 301 confirms that the target host is faulty; the service takeover module 302 takes over the service of the target host to continue running, so that the target host is restarted or repaired offline; if the service recovery module 303 receives the heartbeat information of the target host, it determines that the target host recovers to be normal, and switches each running service back to the target host to run.
In this embodiment, the standby host of the cloud cluster is set, the service of the target host of the cloud cluster with the fault is taken over to continue to operate through the standby host, and after the target host is recovered, the service is switched back to the target host to operate, and the function of the standby host is simpler than that of an ATS (automatic train maintenance) system, and the switching is more convenient, so that the operating efficiency of the whole system is improved.
Further, on the basis of the above embodiment of the apparatus, the apparatus further comprises:
and the heartbeat receiving module is used for receiving the heartbeat information of the target host through the main heartbeat line, and if the main heartbeat line fails, the heartbeat information of the target host is received through the standby heartbeat line.
Further, on the basis of the above device embodiment, the heartbeat message includes host hardware heartbeat information, host network heartbeat information, host operating system heartbeat information, application heartbeat information, and host and disk array connection heartbeat information.
Further, on the basis of the above embodiment of the apparatus, the apparatus further comprises:
the file setting module is used for setting the detection time interval and the detection times of the heartbeat information in the heartbeat configuration file and receiving the heartbeat information of the target host according to the heartbeat configuration file.
The cloud cluster fault processing apparatus described in this embodiment may be configured to execute the method embodiments, and the principle and the technical effect are similar, which are not described herein again.
Referring to fig. 4, the electronic device includes: a processor (processor)401, a memory (memory)402, and a bus 403;
wherein,
the processor 401 and the memory 402 complete communication with each other through the bus 403;
the processor 401 is configured to call program instructions in the memory 402 to perform the methods provided by the above-described method embodiments.
The present embodiments disclose a computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions which, when executed by a computer, enable the computer to perform the methods provided by the above-described method embodiments.
The present embodiments provide a non-transitory computer-readable storage medium storing computer instructions that cause the computer to perform the methods provided by the method embodiments described above.
The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
It should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.
Claims (10)
1. A cloud cluster fault processing method is characterized by comprising the following steps:
if the standby host of the cloud cluster does not receive heartbeat information of a target host within a preset time period, confirming that the target host fails;
taking over the service of the target host to continue running so as to enable the target host to carry out offline restart or repair;
and if the heartbeat information of the target host is received, confirming that the target host is recovered to be normal, and switching each running service back to the target host to run.
2. The method of claim 1, wherein before the standby host of the cloud cluster receives no heartbeat message of the target host within a preset time period and confirms that the target host fails, the method further comprises:
the standby host of the cloud cluster receives heartbeat information of the target host through the main heartbeat line, and if the main heartbeat line fails, the standby host receives the heartbeat information of the target host through the standby heartbeat line.
3. The method of claim 1, wherein the heartbeat messages include host hardware heartbeat information, host network heartbeat information, host operating system heartbeat information, application heartbeat information, and host disk array connectivity heartbeat information.
4. The method according to any one of claims 1-3, further comprising:
setting a detection time interval and detection times of heartbeat information in a heartbeat configuration file, and receiving the heartbeat information of a target host according to the heartbeat configuration file.
5. The utility model provides a high in clouds cluster fault handling device which characterized in that includes:
the fault confirming module is used for confirming that the target host machine is in fault if the heartbeat information of the target host machine is not received within a preset time period;
the service takeover module is used for taking over the service of the target host to continue running so as to enable the target host to be restarted or repaired off line;
and the service recovery module is used for confirming that the target host recovers to be normal and switching each running service back to the target host to run if the heartbeat information of the target host is received.
6. The apparatus of claim 5, further comprising:
and the heartbeat receiving module is used for receiving the heartbeat information of the target host through the main heartbeat line, and if the main heartbeat line fails, the heartbeat information of the target host is received through the standby heartbeat line.
7. The apparatus of claim 5, wherein the heartbeat message comprises host hardware heartbeat information, host network heartbeat information, host operating system heartbeat information, application heartbeat information, and host disk array connectivity heartbeat information.
8. The apparatus of any of claims 5-7, further comprising:
the file setting module is used for setting the detection time interval and the detection times of the heartbeat information in the heartbeat configuration file and receiving the heartbeat information of the target host according to the heartbeat configuration file.
9. An electronic device, comprising:
at least one processor; and
at least one memory communicatively coupled to the processor, wherein:
the memory stores program instructions executable by the processor, the processor invoking the program instructions to perform the method of any of claims 1 to 4.
10. A non-transitory computer-readable storage medium storing a computer program that causes a computer to perform the method according to any one of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711204632.XA CN109842505A (en) | 2017-11-27 | 2017-11-27 | A kind of cloud clustering fault processing method and processing device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711204632.XA CN109842505A (en) | 2017-11-27 | 2017-11-27 | A kind of cloud clustering fault processing method and processing device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109842505A true CN109842505A (en) | 2019-06-04 |
Family
ID=66880150
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711204632.XA Pending CN109842505A (en) | 2017-11-27 | 2017-11-27 | A kind of cloud clustering fault processing method and processing device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109842505A (en) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110502326A (en) * | 2019-08-27 | 2019-11-26 | 珠海格力电器股份有限公司 | Cloud service scheduling and recovering method based on fault detection and terminal equipment |
| CN110602339A (en) * | 2019-08-29 | 2019-12-20 | 深圳震有科技股份有限公司 | Fault detection method, system and storage medium based on voice gateway |
| CN111026586A (en) * | 2019-11-21 | 2020-04-17 | 通号城市轨道交通技术有限公司 | Main/standby state switching method and device for cluster equipment |
| CN111464389A (en) * | 2020-03-31 | 2020-07-28 | 云知声智能科技股份有限公司 | High-availability node fault detection method and device |
| CN112486750A (en) * | 2020-12-04 | 2021-03-12 | 深圳市捷顺科技实业股份有限公司 | Host fault processing method, device, control system and storage medium |
| CN113112619A (en) * | 2021-04-07 | 2021-07-13 | 高新现代智能系统股份有限公司 | Ticket checking method, ticket checking equipment, system and storage medium for online ticket card |
| CN113810227A (en) * | 2021-09-13 | 2021-12-17 | 阳光新能源开发有限公司 | Main and standby machine switching method and power station |
| CN114979688A (en) * | 2022-05-11 | 2022-08-30 | 北京大甜绵白糖科技有限公司 | Live broadcast data transmission system, method and device |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030018927A1 (en) * | 2001-07-23 | 2003-01-23 | Gadir Omar M.A. | High-availability cluster virtual server system |
| CN101645915A (en) * | 2008-08-06 | 2010-02-10 | 中兴通讯股份有限公司 | Disk array host channel daughter card, on-line switching system and switching method thereof |
| CN106656589A (en) * | 2016-12-13 | 2017-05-10 | 武汉船舶通信研究所 | Server dual hot backup system |
-
2017
- 2017-11-27 CN CN201711204632.XA patent/CN109842505A/en active Pending
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030018927A1 (en) * | 2001-07-23 | 2003-01-23 | Gadir Omar M.A. | High-availability cluster virtual server system |
| CN101645915A (en) * | 2008-08-06 | 2010-02-10 | 中兴通讯股份有限公司 | Disk array host channel daughter card, on-line switching system and switching method thereof |
| CN106656589A (en) * | 2016-12-13 | 2017-05-10 | 武汉船舶通信研究所 | Server dual hot backup system |
Non-Patent Citations (1)
| Title |
|---|
| 徐超群: "高可用集群系统关键技术的研究与实现", 《中国知网》 * |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110502326A (en) * | 2019-08-27 | 2019-11-26 | 珠海格力电器股份有限公司 | Cloud service scheduling and recovering method based on fault detection and terminal equipment |
| CN110602339A (en) * | 2019-08-29 | 2019-12-20 | 深圳震有科技股份有限公司 | Fault detection method, system and storage medium based on voice gateway |
| CN110602339B (en) * | 2019-08-29 | 2021-04-20 | 深圳震有科技股份有限公司 | Fault detection method, system and storage medium based on voice gateway |
| CN111026586A (en) * | 2019-11-21 | 2020-04-17 | 通号城市轨道交通技术有限公司 | Main/standby state switching method and device for cluster equipment |
| CN111026586B (en) * | 2019-11-21 | 2024-01-02 | 通号城市轨道交通技术有限公司 | Main and standby state switching method and device of cluster equipment |
| CN111464389A (en) * | 2020-03-31 | 2020-07-28 | 云知声智能科技股份有限公司 | High-availability node fault detection method and device |
| CN112486750A (en) * | 2020-12-04 | 2021-03-12 | 深圳市捷顺科技实业股份有限公司 | Host fault processing method, device, control system and storage medium |
| CN113112619A (en) * | 2021-04-07 | 2021-07-13 | 高新现代智能系统股份有限公司 | Ticket checking method, ticket checking equipment, system and storage medium for online ticket card |
| CN113112619B (en) * | 2021-04-07 | 2023-12-05 | 高新现代智能系统股份有限公司 | Ticket checking method, ticket checking equipment, system and storage medium for online ticket card |
| CN113810227A (en) * | 2021-09-13 | 2021-12-17 | 阳光新能源开发有限公司 | Main and standby machine switching method and power station |
| CN113810227B (en) * | 2021-09-13 | 2024-08-20 | 阳光新能源开发股份有限公司 | Main/standby machine switching method and power station |
| CN114979688A (en) * | 2022-05-11 | 2022-08-30 | 北京大甜绵白糖科技有限公司 | Live broadcast data transmission system, method and device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109842505A (en) | A kind of cloud clustering fault processing method and processing device | |
| US9141491B2 (en) | Highly available server system based on cloud computing | |
| CN101217353B (en) | A control method on multi-point dual redundancy system of call center | |
| CN106330475B (en) | Method and device for managing main and standby nodes in communication system and high-availability cluster | |
| CN102170342B (en) | IEC (integrated Ethernet chip) 104 communication host-standby switching method under high redundancy configuration | |
| CN102355366B (en) | Member-stacking device and method for managing member-stacking device at split stacking moment | |
| CN102710457B (en) | A kind of N+1 backup method of cross-network segment and device | |
| CN107404394B (en) | IPTV system disaster tolerance method and IPTV disaster tolerance system | |
| CN110677282B (en) | Hot backup method of distributed system and distributed system | |
| CN107729190B (en) | IO path failover processing method and system | |
| CN104639367A (en) | Method and system for implementing switching of master server and standby server | |
| CN103905247A (en) | Two-unit standby method and system based on multi-client judgment | |
| CN104317679B (en) | A kind of SCADA system is based on the communication fault-tolerance method of thread redundancy | |
| CN104079442A (en) | Real-time Ethernet based redundancy control device, as well as device redundancy system and method | |
| CN105068763B (en) | A kind of virtual machine tolerant system and method for storage failure | |
| CN102026042A (en) | Keep-alive and self-healing method and device for advanced telecom computing architecture control surface | |
| CN102664755B (en) | Control channel fault determining method and device | |
| CN103107904A (en) | Double-computer switching method of application server of ATS system control center | |
| CN102957565B (en) | A kind of processing method of multi-primary apparatus conflict and device | |
| CN102487332B (en) | Fault processing method, apparatus thereof and system thereof | |
| CN204406385U (en) | The management devices of computer system | |
| CN101557307B (en) | Dispatch automation system application state management method | |
| CN105490847A (en) | Real-time detecting and processing method of node failure in private cloud storage system | |
| CN105007293A (en) | Double master control network system and double writing method for service request therein | |
| CN102638369A (en) | Method, device and system for arbitrating main/standby switch |
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 | ||
| CB02 | Change of applicant information |
Address after: 100070 12 / F, block a, yard 1, South Automobile Museum Road, Fengtai District, Beijing Applicant after: CRSC URBAN RAIL TRANSIT TECHNOLOGY Co.,Ltd. Address before: 100070 11 floors, Block D, No. 1 South Road, Fengtai Auto Museum, Beijing Applicant before: BEIJING URBAN TRANSIT TECHNOLOGY Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190604 |
|
| RJ01 | Rejection of invention patent application after publication |