WO2012174713A1 - 一种分布式运行网络管理系统及其容错的方法 - Google Patents
一种分布式运行网络管理系统及其容错的方法 Download PDFInfo
- Publication number
- WO2012174713A1 WO2012174713A1 PCT/CN2011/076065 CN2011076065W WO2012174713A1 WO 2012174713 A1 WO2012174713 A1 WO 2012174713A1 CN 2011076065 W CN2011076065 W CN 2011076065W WO 2012174713 A1 WO2012174713 A1 WO 2012174713A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- module
- server
- operation log
- database
- log
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/04—Network management architectures or arrangements
- H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0695—Management of faults, events, alarms or notifications the faulty arrangement being the maintenance, administration or management system
Definitions
- the present invention relates to the field of communication network technologies, and in particular, to a distributed operation network management system and a method for fault tolerance thereof. Background technique
- the network management system is the control center and data center of the communication network, and is usually running on your server. At present, the cost of improving the computing power of a single server is increasing.
- the distributed operation is generally used in the industry to further improve the management capability of the network management system.
- An important problem to be considered in the distributed network management system is fault tolerance.
- Service B depends on Service A.
- Data, and module A and module B are respectively running on different servers, each having its own database; when the data of service A changes, an unexpected situation occurs, the network management system suddenly stops, and service B is too late to be based on service A. Change the subsequent changes; After the network management system is restarted, the service B can only know that its own data has been inconsistent with the data of the service A. In this case, it is necessary to consider the fault tolerance mentioned above. Summary of the invention
- the main object of the present invention is to provide a distributed operation network management system and a fault tolerance method thereof, which can solve the fault tolerance problem of the distributed operation network management system.
- the technical solution of the present invention is achieved as follows:
- a method for distributed fault tolerance of a network management system comprising:
- the first module running on the first server running the distributed network management system starts, according to the operation log of the modules of each server, determines whether it is inconsistent with the modules running on other servers;
- the first module executes the determined recovery plan, generates and updates its own operational logs, and then restarts itself.
- the method further includes:
- the module of each server When the module of each server receives the operation of the client, the operation result and the operation log are simultaneously stored in the database of each server by using a data transaction manner;
- the operation log includes an operation serial number, an operation command code, an operation object, and an operation specific content.
- the determining, according to the operation log of the module of each server, whether the self is inconsistent with the module running on the other server is:
- the first module reads and analyzes an operation log in the first server database, and determines an operation serial number of the module related to itself in the last received operation log;
- the operation log after the operation serial number of the module related to the self recorded by the first server in the other server database is read and analyzed, and the recovery plan is determined to be full recovery or incremental recovery according to service requirements.
- the first module executes the recovery plan, generates and updates its own operation log as:
- the first module abandons its own operation log in the database, re-analyzes with the operation log of the module that is inconsistent with itself, generates and updates its own operation record;
- the first module executes the recovery plan, generates and updates its own operation log as:
- the first module analyzes an operation log of a module that is not stored in the database and is inconsistent with itself, simulates an operation that should be performed after receiving the operation log, and generates and updates its own operation log.
- a distributed running network management system comprising at least two servers; each of the servers running at least one module;
- the first module running on the first server is configured to determine, according to the operation log of the module of each server, whether the device is inconsistent with the module running on the other server; if there is an inconsistency, the analysis is inconsistent with the self.
- the operation log of the module and formulate a recovery plan according to business needs; execute the recovery plan, generate and update its own operation log, and restart itself.
- the server is configured to set a format of an operation log of the distributed network management system, where the operation log includes an operation serial number, an operation command code, an operation object, and operation specific content;
- the server further includes a database
- the module running on the server is specifically used to receive the operation of the client, According to the transaction mode, the operation result and the operation log are simultaneously stored in the database of the server.
- the first module is specifically configured to read and analyze an operation log in the first server database, determine an operation serial number of a module related to itself in the last received operation log, and read and analyze the other
- the operation log of the module related to the first module in the server database determining the operation serial number of the last operation log of the module; comparing whether the operation serial number determined by the database is consistent with the operation serial number determined by other server databases, if not consistent , to determine that it is inconsistent with the modules running on other servers.
- the first module is specifically configured to read and analyze an operation log of the operation serial number recorded by the first server and the operation serial number of the related module in the other server database, and determine a recovery plan as a full amount according to service requirements. Recovery or incremental recovery.
- the first module is specifically configured to re-analyze the operation log of the module in the database when the recovery plan is determined to be full recovery, and re-analyze the operation log of the module that is inconsistent with itself, and generate and update its operation log.
- the recovery plan is incremental recovery
- the operation log of the module that is not stored in the database and is inconsistent with itself is analyzed, and the operation that should be performed after receiving the operation log is simulated, and the operation information of the module is generated and updated.
- the present invention determines whether there is an inconsistency between the modules, and automatically restores the existing inconsistencies by formulating a recovery plan, and solves the problem of the distributed operation network management system.
- the fault-tolerant problem avoids the occurrence of erroneous results of distributed operation of the network management system under abnormal conditions.
- FIG. 1 is a schematic flowchart of a method for implementing fault tolerance of a distributed operation network management system according to the present invention
- FIG. 2 is a schematic structural diagram of a simple distributed operation network management system for implementing the method shown in FIG.
- FIG. 3 is a schematic structural diagram of a distributed operation network management system according to the present invention. detailed description
- the basic idea of the present invention is: The first module running on the first server is started, and according to the operation log of the module of each server, it is determined whether it is inconsistent with the modules running on other servers; if there is an inconsistency, the analysis and the self are analyzed. There is an inconsistent operation of the module, and a recovery plan is prepared according to business needs; the first module executes the determined recovery plan, generates and updates its own operation log, and then restarts itself.
- the distributed running network management system to which the present invention is applied includes multiple servers, each server running at least one module, each module having a corresponding operation log; the first server may be a distributed running network management system Any one of the servers except the first server is called another server; assuming that one module runs on each server, the module running on the first server is called the first module.
- FIG. 1 is a flowchart showing a method for implementing fault tolerance of a distributed operation network management system according to the present invention. As shown in FIG. 1, the method includes the following steps:
- Step 101 The first module running on the first server of the distributed network management system is started, and according to the operation log of the module of each server, it is determined whether it is inconsistent with the modules running on other servers;
- the first module reads and analyzes the operation log in the first server database, determines the operation serial number of the module related to itself recorded in the last received operation log; reads and analyzes the other server. An operation log of the module related to the first module in the database, and determining an operation serial number of the last operation log of the module;
- the method further includes: presetting the format of the operation log of the distributed network management system; wherein the operation log includes an operation serial number, an operation command code, an operation object, and an operation. specific contents;
- each module in the distributed operation network management system uses the data transaction manner to store the operation result and the operation log in the database of each server at the same time.
- Step 102 If there is an inconsistency, the first module analyzes an operation log of the module that is inconsistent with itself, and formulates a recovery plan according to the service requirement;
- the operation log after the operation serial number of the module related to the first server recorded by the first server in the other server database is read and analyzed, and the recovery plan is determined to be full recovery or incremental recovery according to service requirements; Ground, when there is time requirement for recovery time, the recovery plan is generally determined to be incremental recovery, and in other cases, the recovery plan is determined to be full recovery.
- Step 103 The first module executes the determined recovery plan, generates and updates its own operation log, and restarts itself;
- the first module relinquishes its own operation log in the database, re-analyzes with the operation log of the module that is inconsistent with itself, generates and updates its operation log, and then re- start up;
- the first module analyzes an operation log of a module that is not stored in the database and is inconsistent with itself, simulates an operation that should be performed after receiving the operation log, generates and updates its own operation. Log, then restart.
- the distributed running network management system runs on two servers: server A and server B; wherein, server A runs module A, server A's database is database A; server B runs module B, server B.
- the database is database B; module B depends on the data of module A; module A and database A are located on the same server, and are operating With the support of the system and commercial database software, there is no inconsistency between the two.
- inconsistency may occur between module A and module B, such as: The operation of a certain customer, after the processing of module A, the next operation needs to be performed by module B; after the processing of module A is completed, module B I just started processing, but before I can store the processing result in database B, Server B suddenly crashes.
- module A and module B will be inconsistent at the service level; in this case, the distribution shown in Figure 2
- the running network management system performs the method described in FIG. 1, and the specific implementation steps are as follows:
- the first step is to preset a format of an operation log of the distributed network management system, where the operation log includes at least an operation serial number, an operation command code, an operation object, and an operation specific content; the operation record is saved and maintained in the database;
- the module B performs the next processing, and when the operation result is stored in the database, the database transaction is used to ensure that the operation result and the operation log are successfully loaded into the database at the same time or the storage is unsuccessful at the same time;
- the operation log of the operation of the module A that triggers the operation of the operation record of the module B is recorded.
- the operation log of the module B can be as shown in Table 2:
- the fourth step each time module B is restarted, it is determined according to the operation log whether it is Module A is inconsistent;
- module B reads and analyzes its own operation log, and determines the operation serial number of the operation log of the last received module A.
- the obtained operation serial number is defined as the serial number X;
- module B reads and analyzes the operation log of module A, and determines the operation serial number of the last operation log of module A.
- the obtained operation serial number is defined as the serial number Y;
- serial number X and Y are compared. If they are the same, it means that there is no inconsistency between module B and module A. If they are not the same, it means that module B is inconsistent with module A.
- the operation log of the module A is read and analyzed, and the location where the serial number X is located is found; the operation log after the serial number X is read, and the recovery plan is prepared according to the business needs; here, the recovery plan is roughly divided into two types: full recovery And incremental recovery;
- module B When it is determined that the recovery plan is full recovery, as long as module B is inconsistent with module A, module B performs a full analysis, abandons all its operation logs, and reanalyzes based on the operation of module A, generating and Update its own operation log.
- the operation serial number of module A recorded in the operation log is the maximum value of the operation serial number recorded by module A, and module B restarts.
- the full recovery plan takes a long time, but the analysis logic is simple. ;
- module B analyzes the operation information of module A that is not stored, and simulates the operations that should be performed after receiving the operation logs step by step, generates and updates its own operation log, and the operation log
- the operation serial number of module A recorded in is the maximum value of the operation serial number recorded by module A, and module B is restarted; the incremental recovery plan takes less time, but the analysis logic is more complicated.
- FIG. 3 shows the structure of the distributed operation network management system of the present invention.
- the system includes at least two servers, and FIG. 3 shows the first server and the second server.
- each server is connected to each other; at least one module is run on each server, and servers running related modules are connected to each other.
- the related modules refer to modules having dependencies on the operations between the modules; Only the refinement structure of the first server is shown, it should be understood that other servers are similar in structure to the first server;
- the first module running on the first server is configured to determine, according to the operation log of the module of each server, whether the device is inconsistent with the module running on the other server; if there is an inconsistency, the analysis is inconsistent with the self.
- the operation log of the module, and according to the business needs to develop a recovery plan; execute the recovery plan, generate and update its own operation log, and restart itself.
- the server is configured to set a format of an operation log of the distributed network management system, where the operation log includes an operation serial number, an operation command code, an operation object, and operation specific content;
- the server further includes a database
- the module running on the server is specifically configured to store the operation result and the operation log into the database of the server at the same time when receiving the operation of the client.
- the first module is specifically configured to read and analyze an operation log in the first server database, determine an operation serial number of a module related to itself in the last received operation log, and read and analyze the other The operation log of the module related to the first module in the server database, determining the operation serial number of the last operation log of the module; comparing whether the operation serial number determined by the database is consistent with the operation serial number determined by other server databases, if not consistent , to determine that it is inconsistent with the modules running on other servers.
- the first module is specifically configured to read and analyze an operation log of the operation serial number recorded by the first server and the operation serial number of the related module in the other server database, and determine a recovery plan as a full amount according to service requirements. Recovery or incremental recovery.
- the first module is specifically configured to: when it is determined that the recovery plan is full recovery, The operation log of the database itself is re-analyzed based on the operation log of the module that is inconsistent with itself, and generates and updates its own operation log. When it is determined that the recovery plan is incremental recovery, the unstored data in the analysis database is inconsistent with itself.
- the operation log of the module simulate the operation that should be done after receiving the operation log, generate and update its own operation record.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
本发明提供了一种分布式运行网络管理系统及其容错的方法，所述方法包括：运行于第一服务器上的第一模块启动，根据各服务器的模块的操作日志，判断自身是否与运行于其他服务器上的模块存在不一致；存在不一致时，分析与自身存在不一致的模块的操作日志，并根据业务需要制定恢复计划；所述第一模块执行所确定的恢复计划，生成并更新自身的操作日志，之后重启自身。本发明根据分布式运行网络管理系统的各服务器的模块的操作日志，确定各模块之间是否存在不一致，并对存在的不一致通过制定恢复计划，进行自动恢复，解决了分布式运行网络管理系统的容错问题，避免了异常情况下，网络管理系统分布式运行的错误结果的发生。
Description
一种分布式运行网络管理系统及其容错的方法 技术领域
本发明涉及通信网络技术领域， 尤其涉及一种分布式运行网络管理系 统及其容错的方法。 背景技术
网络管理系统是通信网络的控制中心和数据中心， 一般运行在 贵的 服务器上。 目前提高单个服务器的运算能力的成本越来越高， 业界普遍会 釆用分布式运行来进一步提高网络管理系统的管理能力， 而分布式运行的 网络管理系统需要考虑的一个重要问题就是容错问题。
在单服务器运行的环境下， 即使发生突发事故， 也可以通过商业数据 库来保证数据的一致和正确； 但是在分布式运行的环境下， 为了提高效率， 对于数据流也通常进行分布， 每个服务器都有自己的数据库， 发生突发事 故后， 不能确保不同服务器的数据库中数据的一致性， 这里的一致不是指 数据等同， 而是指业务层面上的一致； 比如： 业务 B依赖业务 A的数据， 且模块 A和模块 B分别运行在不同的服务器上， 各自有自己的数据库； 当 业务 A的数据发生改变后， 发生突发情况， 网络管理系统突然停掉， 业务 B来不及根据业务 A的改变做后续的变更； 当网络管理系统重新启动之后， 业务 B仅仅凭借自身是无法得知自己的数据已经与业务 A的数据不一致， 此时， 就需要考虑前面提到容错问题。 发明内容
有鉴于此， 本发明的主要目的在于提供一种分布式运行网络管理系统 及其容错的方法， 能够解决分布式运行网络管理系统的容错问题。
为达到上述目的， 本发明的技术方案是这样实现的：
一种分布式运行网络管理系统容错的方法， 所述方法包括：
运行于分布式运行网络管理系统的第一服务器上的第一模块启动， 根 据各服务器的模块的操作日志， 判断自身是否与运行于其他服务器上的模 块存在不一致；
存在不一致时， 分析与自身存在不一致的模块的操作日志， 并根据业 务需要制定恢复计划；
所述第一模块执行所确定的恢复计划， 生成并更新自身的操作曰志， 之后重启自身。
进一步地， 在所述运行于第一服务器上的第一模块启动之前， 所述方 法还包括：
设置所述分布式网络管理系统的操作日志的格式；
所述各服务器的模块接收到客户的操作时， 釆用数据事务的方式， 将 操作结果和操作日志同时存入各服务器的数据库；
其中， 所述操作日志包括操作流水号、 操作命令码、 操作对象、 操作 具体内容。
其中， 所述根据各服务器的模块的操作日志， 判断自身是否与运行于 其他服务器上的模块存在不一致为：
第一模块读取和分析第一服务器数据库中的操作日志， 确定最后接收 到的操作日志中与自身相关模块的操作流水号；
读取和分析所述其他服务器数据库中与第一模块相关的模块的操作日 志， 确定所述模块的最后一个操作日志的操作流水号；
比较自身数据库确定的操作流水号与其他服务器数据库确定的操作流 水号是否一致， 若不一致， 则确定自身与运行于其他服务器上的模块存在 不一致。
其中， 所述分析与自身不一致的模块的操作日志， 根据业务需要制定 恢复计划为：
读取和分析所述其他服务器数据库中、 所述第一服务器记录的与自身 相关模块的操作流水号之后的操作日志， 根据业务需要确定恢复计划为全 量恢复或增量恢复。
其中， 当确定恢复计划为全量恢复时， 所述第一模块执行所述恢复计 划， 生成并更新自身的操作日志为：
所述第一模块放弃数据库中自身的操作日志， 以与自身存在不一致的 模块的操作日志为准重新分析， 生成并更新自身的操作曰志；
当确定恢复计划为增量恢复时， 所述第一模块执行所述恢复计划， 生 成并更新自身的操作日志为：
所述第一模块分析数据库中未存储的与自身存在不一致的模块的操作 日志， 模拟收到所述操作日志后应做的操作， 生成并更新自身的操作日志。
一种分布式运行网络管理系统， 所述系统包括至少两个服务器； 所述 每个服务器上至少运行一个模块； 其中，
所述运行于第一服务器上的第一模块， 用于在启动时根据各服务器的 模块的操作日志， 判断自身是否与运行于其他服务器上的模块存在不一致； 若存在不一致， 分析与自身存在不一致的模块的操作日志， 并根据业务需 要制定恢复计划； 执行所述恢复计划， 生成并更新自身的操作日志， 重启 自身。
其中， 所述服务器， 用于设置所述分布式网络管理系统的操作日志的 格式； 其中， 所述操作日志包括操作流水号、 操作命令码、 操作对象、 操 作具体内容；
所述服务器进一步包括数据库；
所述运行于服务器上的模块， 具体用于接收到客户的操作时， 釆用数
据事务的方式， 将操作结果和操作日志同时存入所述服务器的数据库。 其中， 所述第一模块， 具体用于读取和分析所述第一服务器数据库中 的操作日志， 确定最后接收到的操作日志中与自身相关模块的操作流水号； 读取和分析所述其他服务器数据库中与第一模块相关的模块的操作日志， 确定所述模块的最后一个操作日志的操作流水号； 比较自身数据库确定的 操作流水号与其他服务器数据库确定的操作流水号是否一致， 若不一致， 则确定自身与运行于其他服务器上的模块存在不一致。
其中， 所述第一模块， 具体用于读取和分析所述其他服务器数据库中、 所述第一服务器记录的与自身相关模块的操作流水号之后的操作日志， 根 据业务需要确定恢复计划为全量恢复或增量恢复。
其中， 所述第一模块， 具体用于当确定恢复计划为全量恢复时， 放弃 数据库中自身的操作日志， 以与自身存在不一致的模块的操作日志为准重 新分析， 生成并更新自身的操作日志； 当确定恢复计划为增量恢复时， 分 析数据库中未存储的与自身存在不一致的模块的操作日志， 模拟收到所述 操作日志后应做的操作， 生成并更新自身的操作曰志。
本发明根据分布式运行网络管理系统中各服务器的模块的操作日志， 确定各模块之间是否存在不一致， 并对存在的不一致通过制定恢复计划， 进行自动恢复， 解决了分布式运行网络管理系统的容错问题， 避免了异常 情况下， 网络管理系统分布式运行的错误结果的发生。 附图说明
图 1为本发明分布式运行网络管理系统容错的方法实现流程示意图； 图 2为实现图 1所示方法的简单分布式运行网络管理系统的结构示意 图；
图 3为本发明分布式运行网络管理系统的结构示意图。
具体实施方式
本发明的基本思想为： 运行于第一服务器上的第一模块启动， 根据各 服务器的模块的操作日志， 判断自身是否与运行于其他服务器上的模块存 在不一致； 存在不一致时， 则分析与自身存在不一致的模块的操作曰志， 并根据业务需要制定恢复计划； 所述第一模块执行所确定的恢复计划， 生 成并更新自身的操作日志， 之后重启自身。
本发明所应用的分布式运行网络管理系统中包括多个服务器， 每个服 务器上运行有至少一个模块， 每个模块有对应的操作日志； 所述的第一服 务器可以是分布式运行网络管理系统中任意一台服务器， 除第一服务器以 外的服务器称为其他服务器； 假设每个服务器上运行一个模块， 那么， 运 行于第一服务器上的模块称为第一模块。
为使本发明的目的、 技术方案和优点更加清楚明白， 以下举实施例并 参照附图， 对本发明进一步详细说明。
图 1 示出了本发明分布式运行网络管理系统容错的方法实现流程， 如 图 1所示， 所述方法包括下述步骤：
步骤 101 ,运行于分布式运行网络管理系统的第一服务器上的第一模块 启动， 根据各服务器的模块的操作日志， 判断自身是否与运行于其他服务 器上的模块存在不一致；
具体地， 本步骤中， 第一模块读取和分析第一服务器数据库中的操作 日志， 确定最后接收到的操作日志中记录的与自身相关模块的操作流水号； 读取和分析所述其他服务器数据库中所述与第一模块相关的模块的操 作日志， 确定所述模块的最后操作日志的操作流水号；
比较自身数据库确定的操作流水号与其他服务器数据库确定的操作流 水号是否一致， 若不一致， 则确定自身与运行于其他服务器上的模块存在 不一致。
另外， 应当理解， 在步骤 101 之前， 所述方法还包括： 预先设置所述 分布式网络管理系统的操作日志的格式； 其中， 所述操作日志包括操作流 水号、 操作命令码、 操作对象、 操作具体内容；
所述分布式运行网络管理系统中各模块在接收到客户的操作时， 釆用 数据事务的方式， 将操作结果和操作日志同时存入各服务器的数据库。
步骤 102, 若存在不一致， 第一模块分析与自身存在不一致的模块的操 作日志， 并根据业务需要制定恢复计划；
本步骤中， 读取和分析所述其他服务器数据库中、 所述第一服务器记 录的与自身相关模块的操作流水号之后的操作日志， 根据业务需要确定恢 复计划为全量恢复或增量恢复； 具体地， 当对恢复时间有时间要求时， 一 般将恢复计划确定为增量恢复，其余情况下，将恢复计划确定为全量恢复。
步骤 103 , 所述第一模块执行所确定的恢复计划， 生成并更新自身的操 作日志， 自身进行重新启动；
具体地， 当确定恢复计划为全量恢复时， 所述第一模块放弃数据库中 自身的操作日志， 以与自身存在不一致的模块的操作日志为准重新分析， 生成并更新自身的操作日志， 然后重新启动；
当确定恢复计划为增量恢复时， 所述第一模块分析数据库中未存储的 与自身存在不一致的模块的操作日志， 模拟收到所述操作日志后应做的操 作， 生成并更新自身的操作日志， 然后重新启动。
下面结合图 2示出的简单分布式运行网络管理系统对上述方法进行具 体说明。
参照图 2, 该分布式运行网络管理系统运行在两个服务器上： 服务器 A 和服务器 B; 其中， 服务器 A上运行模块 A, 服务器 A的数据库为数据库 A; 服务器 B上运行模块 B, 服务器 B的数据库为数据库 B; 模块 B依赖 于模块 A的数据； 模块 A和数据库 A由于位于同一台服务器上， 且在操作
系统和商业数据库软件的支持下， 两者不会发生不一致的情况。 在突发情况下， 模块 A和模块 B之间可能发生不一致， 如： 某个客户 的操作， 在模块 A处理完之后， 需要由模块 B进行下一步操作； 当模块 A 处理完成之后， 模块 B刚刚开始处理， 但还没来得及将处理结果存入数据 库 B时， 服务器 B突然宕机， 如此， 模块 A和模块 B在业务层面上就会存 在不一致； 这种情况下， 图 2所示的分布式运行网络管理系统执行图 1所 述的方法， 具体实现步骤如下：
第一步， 预先设置分布式运行网络管理系统的操作日志的格式， 所述 操作日志至少包括操作流水号、 操作命令码、 操作对象、 操作具体内容； 操作曰志在数据库中保存维护；
第二步， 模块 A每次接收到客户的操作时， 将操作结果入库的时候， 釆用数据库事务的方式， 保证操作结果和操作日志同时入库成功或同时入 库不成功；
这里， 模块 A的操作日志可以如表 1所示:
表 1
第三步， 模块 B在模块 A处理完毕后， 进行下一步处理， 将操作结果 入库的时候， 釆用数据库事务的方式， 保证操作结果和操作日志同时入库 成功或同时入库不成功；
具体地， 模块 B的操作日志中记录有触发该条操作的模块 A的操作曰 志的操作流水号， 这里， 模块 B的操作日志可以如表 2所示：
表 2
第四步， 每次模块 B重新启动的时候， 根据操作日志判断自身是否与
模块 A存在不一致；
具体地， 首先， 模块 B读取和分析自身的操作日志， 确定最后接收到 的模块 A的操作日志的操作流水号， 这里， 将得到的操作流水号定义为流 水号 X；
然后， 模块 B读取和分析模块 A的操作日志， 确定模块 A最后的操作 日志的操作流水号， 这里， 将得到的操作流水号定义为流水号 Y;
最后， 比较流水号 X和 Y, 如果二者相同， 则表示模块 B和模块 A不 存在不一致； 如果不相同， 则表示模块 B存在与模块 A的不一致。
第五步， 若模块 B存在与模块 A的不一致， 则根据业务需要制定恢复 计划；
具体地， 读取和分析模块 A的操作日志， 找到流水号 X所在的位置； 读取流水号 X之后的操作日志， 根据业务需要制定恢复计划； 这里， 恢复 计划大致分为两种： 全量恢复和增量恢复；
当确定恢复计划为全量恢复时，则只要模块 B存在与模块 A的不一致， 模块 B则做一次全量分析， 放弃自身的所有操作日志， 以模块 A的操作曰 志为准进行重新分析， 生成并更新自身的操作日志， 所述操作日志中记录 的模块 A的操作流水号是模块 A记录的操作流水号的最大值，模块 B进行 重新启动； 全量恢复计划耗时比较长， 但分析逻辑较为简单；
当确定恢复计划为增量恢复时， 则模块 B分析没有存储的模块 A的操 作曰志， 一步步模拟收到这些操作日志后应做的操作， 生成并更新自身的 操作日志， 所述操作日志中记录的模块 A的操作流水号是模块 A记录的操 作流水号的最大值， 模块 B进行重新启动； 增量恢复计划耗时较短， 但分 析逻辑较为复杂。
图 3示出了本发明分布式运行网络管理系统的结构， 如图 3所示， 所 述系统包括至少两个服务器，如图 3示出了第一服务器、第二服务器
直至第 n服务器， 各服务器相互连接； 所述每个服务器上至少运行一个模 块， 运行有相关模块的服务器相互连接， 这里， 相关模块是指模块之间的 操作具有依赖等关系的模块； 图 3 中仅示出了第一服务器的细化结构， 应 当理解， 其他服务器与第一服务器的结构类似； 其中，
所述运行于第一服务器上的第一模块， 用于在启动时根据各服务器的 模块的操作日志， 判断自身是否与运行于其他服务器上的模块存在不一致； 若存在不一致， 分析与自身存在不一致的模块的操作日志， 并根据业务需 要制定恢复计划； 执行所述恢复计划， 生成并更新自身的操作日志， 自身 进行重启。
进一步地， 所述服务器， 用于设置所述分布式网络管理系统的操作日 志的格式； 其中， 所述操作日志包括操作流水号、 操作命令码、 操作对象、 操作具体内容；
所述服务器进一步包括数据库；
所述运行于服务器上的模块， 具体用于接收到客户的操作时， 釆用数 据事务的方式， 将操作结果和操作日志同时存入所述服务器的数据库。
其中， 所述第一模块， 具体用于读取和分析所述第一服务器数据库中 的操作日志， 确定最后接收到的操作日志中与自身相关模块的操作流水号； 读取和分析所述其他服务器数据库中与第一模块相关的模块的操作日志， 确定所述模块的最后一个操作日志的操作流水号； 比较自身数据库确定的 操作流水号与其他服务器数据库确定的操作流水号是否一致， 若不一致， 则确定自身与运行于其他服务器上的模块存在不一致。
其中， 所述第一模块， 具体用于读取和分析所述其他服务器数据库中、 所述第一服务器记录的与自身相关模块的操作流水号之后的操作日志， 根 据业务需要确定恢复计划为全量恢复或增量恢复。
其中， 所述第一模块， 具体用于当确定恢复计划为全量恢复时， 放弃
数据库中自身的操作日志， 以与自身存在不一致的模块的操作日志为准重 新分析， 生成并更新自身的操作日志； 当确定恢复计划为增量恢复时， 分 析数据库中未存储的与自身存在不一致的模块的操作日志， 模拟收到所述 操作日志后应做的操作， 生成并更新自身的操作曰志。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的保 护范围。
Claims
1、 一种分布式运行网络管理系统容错的方法， 其特征在于， 所述方法 包括：
运行于分布式运行网络管理系统的第一服务器上的第一模块启动， 根 据各服务器的模块的操作日志， 判断自身是否与运行于其他服务器上的模 块存在不一致；
存在不一致时， 分析与自身存在不一致的模块的操作日志， 并根据业 务需要制定恢复计划；
所述第一模块执行所确定的恢复计划， 生成并更新自身的操作曰志， 之后重启自身。
2、 根据权利要求 1所述的方法， 其特征在于， 在所述运行于第一服务 器上的第一模块启动之前， 所述方法还包括：
设置所述分布式网络管理系统的操作日志的格式；
所述各服务器的模块接收到客户的操作时， 釆用数据事务的方式， 将 操作结果和操作日志同时存入各服务器的数据库；
其中， 所述操作日志包括操作流水号、 操作命令码、 操作对象、 操作 具体内容。
3、 根据权利要求 1或 2所述的方法， 其特征在于， 所述根据各服务器 的模块的操作日志， 判断自身是否与运行于其他服务器上的模块存在不一 致为：
第一模块读取和分析第一服务器数据库中的操作日志， 确定最后接收 到的操作日志中与自身相关模块的操作流水号；
读取和分析所述其他服务器数据库中与第一模块相关的模块的操作日 志， 确定所述模块的最后一个操作日志的操作流水号；
比较自身数据库确定的操作流水号与其他服务器数据库确定的操作流 水号是否一致， 若不一致， 则确定自身与运行于其他服务器上的模块存在 不一致。
4、 根据权利要求 1所述的方法， 其特征在于， 所述分析与自身不一致 的模块的操作日志， 根据业务需要制定恢复计划为：
读取和分析所述其他服务器数据库中、 所述第一服务器记录的与自身 相关模块的操作流水号之后的操作日志， 根据业务需要确定恢复计划为全 量恢复或增量恢复。
5、 根据权利要求 4所述的方法， 其特征在于， 当确定恢复计划为全量 恢复时， 所述第一模块执行所述恢复计划， 生成并更新自身的操作日志为： 所述第一模块放弃数据库中自身的操作日志， 以与自身存在不一致的 模块的操作日志为准重新分析， 生成并更新自身的操作曰志；
当确定恢复计划为增量恢复时， 所述第一模块执行所述恢复计划， 生 成并更新自身的操作日志为：
所述第一模块分析数据库中未存储的与自身存在不一致的模块的操作 日志， 模拟收到所述操作日志后应做的操作， 生成并更新自身的操作日志。
6、 一种分布式运行网络管理系统， 其特征在于， 所述系统包括至少两 个服务器； 所述每个服务器上至少运行一个模块； 其中，
所述运行于第一服务器上的第一模块， 用于在启动时根据各服务器的 模块的操作日志， 判断自身是否与运行于其他服务器上的模块存在不一致； 若存在不一致， 分析与自身存在不一致的模块的操作日志， 并根据业务需 要制定恢复计划； 执行所述恢复计划， 生成并更新自身的操作日志， 重启 自身。
7、 根据权利要求 6所述的系统， 其特征在于， 所述服务器， 用于设置 所述分布式网络管理系统的操作日志的格式； 其中， 所述操作日志包括操 作流水号、 操作命令码、 操作对象、 操作具体内容； 所述服务器进一步包括数据库；
所述运行于服务器上的模块， 具体用于接收到客户的操作时， 釆用数 据事务的方式， 将操作结果和操作日志同时存入所述服务器的数据库。
8、 根据权利要求 6或 7所述的系统， 其特征在于， 所述第一模块， 具 体用于读取和分析所述第一服务器数据库中的操作日志， 确定最后接收到 的操作日志中与自身相关模块的操作流水号； 读取和分析所述其他服务器 数据库中与第一模块相关的模块的操作日志， 确定所述模块的最后一个操 作曰志的操作流水号； 比较自身数据库确定的操作流水号与其他服务器数 据库确定的操作流水号是否一致， 若不一致， 则确定自身与运行于其他服 务器上的模块存在不一致。
9、 根据权利要求 6所述的系统， 其特征在于， 所述第一模块， 具体用 于读取和分析所述其他服务器数据库中、 所述第一服务器记录的与自身相 关模块的操作流水号之后的操作日志， 根据业务需要确定恢复计划为全量 恢复或增量恢复。
10、 根据权利要求 9所述的系统， 其特征在于， 所述第一模块， 具体 用于当确定恢复计划为全量恢复时， 放弃数据库中自身的操作日志， 以与 自身存在不一致的模块的操作日志为准重新分析， 生成并更新自身的操作 日志； 当确定恢复计划为增量恢复时， 分析数据库中未存储的与自身存在 不一致的模块的操作日志， 模拟收到所述操作日志后应做的操作， 生成并 更新自身的操作曰志。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2011/076065 WO2012174713A1 (zh) | 2011-06-21 | 2011-06-21 | 一种分布式运行网络管理系统及其容错的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2011/076065 WO2012174713A1 (zh) | 2011-06-21 | 2011-06-21 | 一种分布式运行网络管理系统及其容错的方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2012174713A1 true WO2012174713A1 (zh) | 2012-12-27 |
Family
ID=47421979
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2011/076065 WO2012174713A1 (zh) | 2011-06-21 | 2011-06-21 | 一种分布式运行网络管理系统及其容错的方法 |
Country Status (1)
| Country | Link |
|---|---|
| WO (1) | WO2012174713A1 (zh) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1812331A (zh) * | 2004-12-24 | 2006-08-02 | 中兴通讯股份有限公司 | 一种实时体现网管前后台数据不一致的方法 |
| CN101155074A (zh) * | 2006-09-29 | 2008-04-02 | 株式会社日立制作所 | 通信日志管理系统 |
| CN101588269A (zh) * | 2009-06-17 | 2009-11-25 | 中兴通讯股份有限公司 | 一种设备配置数据自动上载到网管的方法和系统 |
-
2011
- 2011-06-21 WO PCT/CN2011/076065 patent/WO2012174713A1/zh active Application Filing
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1812331A (zh) * | 2004-12-24 | 2006-08-02 | 中兴通讯股份有限公司 | 一种实时体现网管前后台数据不一致的方法 |
| CN101155074A (zh) * | 2006-09-29 | 2008-04-02 | 株式会社日立制作所 | 通信日志管理系统 |
| CN101588269A (zh) * | 2009-06-17 | 2009-11-25 | 中兴通讯股份有限公司 | 一种设备配置数据自动上载到网管的方法和系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110287052B (zh) | 一种异常任务的根因任务确定方法及装置 | |
| US9223985B2 (en) | Risk assessment of changing computer system within a landscape | |
| US8719232B2 (en) | Systems and methods for data integrity checking | |
| CN104346454B (zh) | 基于Oracle数据库的数据一致性校验方法 | |
| US20110154092A1 (en) | Multistage system recovery framework | |
| US10866866B2 (en) | Query fault processing method and processing apparatus | |
| US8086909B1 (en) | Automatic core file upload | |
| US20060004839A1 (en) | Method and system for data processing with data replication for the same | |
| Lu et al. | Cloud API issues: an empirical study and impact | |
| US20160034337A1 (en) | Failure Mode Identification and Reporting | |
| CN110063042A (zh) | 一种数据库故障的响应方法及其终端 | |
| CN113779149A (zh) | 消息处理方法、装置、电子设备及可读存储介质 | |
| CN111198920B (zh) | 一种基于数据库同步确定对比表快照的方法及装置 | |
| US20160147612A1 (en) | Method and system to avoid deadlocks during a log recovery | |
| CN111124724B (zh) | 一种分布式块存储系统的节点故障测试方法及装置 | |
| CN112506928A (zh) | 一种验证备份数据有效性的方法和装置 | |
| CN116303371A (zh) | 跨架构数据计算方法及装置、电子设备及存储介质 | |
| WO2012174713A1 (zh) | 一种分布式运行网络管理系统及其容错的方法 | |
| CN114490570A (zh) | 生产数据同步方法、装置、数据同步系统及服务器 | |
| JP6504611B2 (ja) | 監視装置、情報監視システム、監視装置の制御方法、及びプログラム | |
| CN110489208B (zh) | 虚拟机配置参数核查方法、系统、计算机设备和存储介质 | |
| CN109669867B (zh) | 测试装置、自动化测试方法和计算机可读存储介质 | |
| CN105765908A (zh) | 一种多站点自动更新方法、客户端和系统 | |
| US11907205B1 (en) | Generic parity solution for highly dynamic sources | |
| CN112860492B (zh) | 一种适用于核心系统的自动化回归测试方法及系统 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 11868104 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |
|
| 122 | Ep: pct application non-entry in european phase |
Ref document number: 11868104 Country of ref document: EP Kind code of ref document: A1 |