JP7340956B2 - Redundant system and data synchronization method - Google Patents

Description

The present invention relates to a technology for synchronizing data between multiple controllers forming a redundant system.

BACKGROUND ART Conventionally, in process control systems used for process control of plants and the like, when high reliability is required, a configuration having a redundant structure in which a plurality of controllers are provided has been used. In this way, by making the system redundant by multiplexing controllers, the system can operate more stably. Conventional plant control systems with such a redundant structure include, for example, a first controller that operates as an active system and a second controller that operates as a standby system, and when an abnormality occurs in the first controller, the system Switch the second controller that was the system to the active system. Generally, in such a redundant system, a process is performed to synchronize data between two devices so that the two devices hold data with the same content (for example, see Patent Document 1).

Japanese Patent Application Publication No. 05-089072

Several methods are known for synchronizing data between devices that make up a redundant system. However, in a facility monitoring system that monitors multiple monitored devices installed in facilities such as buildings, problems occur when data is synchronized between two controllers using these general-purpose technologies. There are cases.

For example, a facility monitoring system has a duplex configuration with two controllers, each controller having its own database. The database includes data that is relatively important in the facility monitoring system, such as data collected from monitored equipment (hereinafter referred to as "monitoring points") indicating the current value of the monitoring point, or data that is updated frequently. is stored.

The controller performs update transactions when updating these data in the database. When the update transaction is successfully completed (committed), the controller writes the data to the database and completes the database update. On the other hand, if any failure occurs during execution of an update transaction, the controller invalidates the update and returns the database to its pre-update state. Therefore, it is originally undesirable for the data in the middle of updating to be synchronized with the other controller.

However, when data is synchronized between two controllers using a general-purpose technique, incomplete data that is being updated may be synchronized with the database of the other controller depending on the method. Furthermore, in this case, if the other controller attempts to restore the database containing the incomplete data, there is a risk that the database itself will be destroyed.

The present invention was made to solve the above-mentioned problems, and its purpose is to accurately synchronize data between a plurality of controllers.

The redundant system according to the present invention is composed of a plurality of controllers, each controller has a different synchronization method, and a plurality of synchronization units that synchronize obtained data with data of a standby controller, and In the case of a system, the output section outputs the obtained data to one of a plurality of synchronization sections according to the type of the data, and the output section outputs the obtained data to one of the plurality of synchronization sections according to the type of the data. If the first data has the highest importance or update frequency in the redundant system, the first data is output to the database synchronization module, which is one of the plurality of synchronization units, and the database synchronization module If the update of the database of the machine based on the first data is completed normally, the copy of the first data is sent to the standby controller, and the update of the database of the machine based on the first data is completed successfully. If the process does not end, the copy of the first data is not sent to the standby controller .

According to the present invention, with the above configuration, data can be accurately synchronized between a plurality of controllers.

1 is a diagram showing a configuration example of a redundant system according to Embodiment 1. FIG. 5 is a diagram illustrating an example of data types and setting contents of a setting unit in the first embodiment. FIG. FIG. 3 is a diagram showing an example of the configuration of software installed in the controller in the first embodiment. FIG. 3 is a diagram showing a flow of first update data or a copy thereof in the first embodiment. FIG. 3 is a diagram showing a flow of second update data or a copy thereof in the first embodiment. 7 is a diagram showing the flow of third update data in the first embodiment. FIG. 7 is a flowchart showing the flow of synchronization processing by the controller in the first embodiment.

Embodiments of the present invention will be described in detail below with reference to the drawings.
Embodiment 1.
FIG. 1 shows an example of the configuration of a redundant system according to Embodiment 1 of the present invention. The redundant system 1 includes a plurality of (two in this case) controllers 10 (10A, 10B), a plurality of monitoring points 200, and a monitoring device (not shown). The controllers 10A and 10B, each monitoring point 200, and the monitoring device are connected via a system bus 150 so that they can communicate with each other. Here, since the controller is configured with two controllers, the redundant system 1 will be described as a duplex system 1. However, the number of controllers does not necessarily have to be two, and may be three or more as long as any one controller can operate as an active system.

The duplex system 1 has a duplex function. The duplication function is a function that monitors and controls the monitoring point 200 using two controllers 10A and 10B. That is, in the duplex system 1, the controller 10A is normally operated as the active system and the controller 10B is operated as the standby system, and the active controller 10A performs processing such as monitoring and controlling the monitoring points 200, and collecting data. conduct. The controller 10A includes an SSD (Solid State Drive) 20A in which a database 25A is constructed, and the controller 10A stores data collected from the monitoring points 200 in the database 25A in the SSD 20A.

The duplication function also manages database synchronization. For example, in the duplex system 1, when the standby controller 10B starts up while the active controller 10A is started, the standby controller 10B requests the active controller 10A to copy the database 25A. Upon receiving this request, the controller 10A transmits a copy of the database 25A to the controller 10B. When the controller 10B receives the copy of the database 25A from the controller 10A, the controller 10B uses the copy to construct the database 25B in the SSD 20B included in the controller 10B.

Thereafter, each time the controller 10A completes updating the database 25A, it sends a copy of the updated data to the controller 10B. Controller 10B writes a copy of the update data received from controller 10A to database 25B, and completes the update of database 25B. In this way, the duplex system 1 synchronizes the databases 25A and 25B.

Further, in the duplex system 1, when a problem such as a failure occurs in the active controller 10A, the standby controller 10B is switched to the active controller. The controller 10B that has been switched to the active system continues processing such as monitoring and controlling the monitoring point 200, and collecting data, and stores the data collected from the monitoring point 200 in the database 25B in the SSD 20B.

Here, in the first embodiment, the controllers 10A and 10B classify various data including data stored in the databases 25A and 25B into a plurality of types and store them in the SSDs 20A and 20B. Next, the types of data stored in the SSDs 20A and 20B will be explained with reference to FIG.

For example, as shown in FIG. 2, the SSD 20A stores data divided into three types: "first data," "second data," and "third data." Here, the "first data" refers to "data that is stored in the database 25A and is synchronized with the data in the database 25B," and the "second data" refers to "data that is not stored in the database 25A but is stored in the SSD 20B." data that is synchronized with the data of Further, the "third data" is "data that is not synchronized with the data of the SSD 20B."

This classification is determined based on, for example, the importance of data in the duplex system 1 or the update frequency of data in the duplex system 1, with "first data" having the highest importance or update frequency, followed by The importance or update frequency increases in the order of "second data" and finally "third data."

The "first data" includes, for example, the current value collected from the monitoring point 200 (for example, the detected temperature if the point 200 is a temperature sensor), an event log related to the monitoring point 200 (for example, what time and minute at the point 200 (failure occurred), etc. These data are considered to have relatively high importance in the duplex system 1 and are updated frequently. Therefore, in the duplex system 1, these data are handled as one type, and these data are stored in the database 25A and synchronized with the data in the database 25B.

The "second data" includes, for example, various setting data regarding the controller 10A, data regarding software and hardware licenses installed in the controller 10A, data regarding the system configuration of the duplex system 1, and the like. Although these data are not as important or updated as highly as the first data in the duplex system 1, it is considered to be data that should be synchronized with the SSD 20B. Therefore, in the duplex system 1, these data are treated as one type, and although these data are not stored in the database 25A, they are synchronized with the data in the SSD 20B.

The "third data" includes, for example, programs related to the OS of the controller 10A, various application programs installed on the controller 10A, system logs of the controller 10A, unique information of the hardware installed on the controller 10A, etc. It will be done. Since these data are considered to be data that do not need to be synchronized with the SSD 20B, the duplex system 1 treats these data as one type, and these data are not synchronized with the data of the SSD 20B. .

The controller 10A also includes a setting section 45A, as shown in FIG. The setting unit 45A is set to determine how the first data and second data described above are to be synchronized with the data in the SSD 20B. The setting unit 45A is configured, for example, in a memory (not shown) included in the controller 10A.

For example, the setting unit 45A is set to synchronize the first data with the data of the SSD 20B (database 25B) using the duplication function provided in the duplication system 1. Similarly, the setting unit 45A is set to synchronize the second data with the data of the SSD 20B using DRBD (Distributed Replicated Block Device, registered trademark), which is widely known as a data synchronization method. Note that the setting unit 45A may be set that the third data is not synchronized with the data of the SSD 20B.

Note that the types of data, their specific examples, and the synchronization method for each type of data described here may be determined by the user (administrator) at the design stage of the controller 10A, for example. Further, the DRBD illustrated as the second data synchronization method is just an example, and the second data synchronization method may be other methods.

Furthermore, although a detailed explanation will be omitted, the SSD 20B included in the standby controller 10B also has the same configuration as the SSD 20A described above. That is, data is also stored in the SSD 20B divided into "first data", "second data", and "third data". Further, the controller 10B includes a setting section 45B in which the same contents as the above-mentioned setting section 45A are set.

Next, an example of the configuration of software installed in the controllers 10A and 10B will be described with reference to FIG. 3. As shown in FIG. 3, the controller 10A and the controller 10B basically have the same software configuration. In FIG. 3, solid line arrows indicate the flow of data that updates the above-mentioned "first data" (hereinafter referred to as "first update data"), and dashed line arrows indicate the flow of "second data". The flow of data to be updated (hereinafter referred to as "second update data") is shown, and the dashed-dotted arrow indicates data to update "third data" (hereinafter referred to as "third update data"). ) shows the flow.

<Example of software configuration of controller 10A>
Various applications 51A, a database synchronization module 52A, a database management system (DBMS) 53A, a file system 54A, a DRBD 55A, a disk driver 56A, and a communication driver 57A are installed in the controller 10A.

The various applications 51A have a function of receiving first update data, second update data, and third update data, and also have a function of processing each received update data.

For example, the various applications 51A accept data collected from the monitoring points 200 indicating the current value of the points 200 as first update data, and process the data as appropriate. Further, the various applications 51A accept, for example, data regarding the system configuration of the duplex system 1 inputted by the user via an input unit (not shown) as second update data, and process the data as appropriate. Further, the various applications 51A receive, for example, data related to the OS-related program of the controller 10A received by the controller 10A via a network (not shown) as third update data, and process the data as appropriate.

Furthermore, the various applications 51A have a function of outputting the processed data to one of two synchronization units (database synchronization module 52A, DRBD 55A) to be described later, based on the settings of the setting unit 45A.

For example, after processing the first update data, the various applications 51A output the processed first update data to the database synchronization module 52A. Furthermore, after processing the second update data, the various applications 51A output the processed second update data to the DRBD 55A. In the illustrated example, the various applications 51A output the second update data to the DRBD 55A via the file system 54A. However, when the various applications 51A process the third update data, they do not output the processed third update data to any of the synchronization units (database synchronization module 52A, DRBD 55A) and output it to the file system 54A. Output. Here, the various applications 51A constitute the "output section" of the present invention.

The database synchronization module 52A has a function of outputting the first update data output by the various applications 51A to the database management system 53A, and also sends a copy of the first update data to the controller 10B via the communication driver 57A. It has the function of Here, the database synchronization module 52A constitutes the "synchronization unit" of the present invention.

The database management system (DBMS) 53A performs processing necessary to manage the database 25A, such as storing data in the database 25A and reading data from the database 25A. The DBMS 53A executes an update transaction to update the database 25A based on the first update data output by the database synchronization module 52A. When the update transaction is normally completed (committed), the DBMS 53A outputs the first update data to the file system 54A.

The file system 54A manages data stored in the SSD 20A as files, and provides various functions such as a file storage function and an encryption function. Here, the file system 54A outputs the first update data output from the DBMS 53A to the disk driver 56A. Further, the file system 54A outputs the second update data output from the various applications 51A to the DRDB 55A, and outputs the third update data output from the various applications 51A to the disk driver 56A.

DRBD55A is general-purpose software that has a function of replicating the SSD 20A over the network in real time. The DRBD 55A outputs the second update data output by the file system 54A to the disk driver 56A. Further, the DRBD 55A outputs a copy of the second update data to the communication driver 57A. Here, the DRBD 55A constitutes the "synchronization section" of the present invention.

The disk driver 56A is software that allows the SSD 20 to be controlled by the OS. This disk driver 56A causes the SSD 20A to store the first update data and third update data output by the file system 54A, and the second update data output by the DRBD 55A. At this time, the first update data is stored in the database 25A in the SSD 20A.

The communication driver 57A is software that allows the OS to control a network interface card (NIC) (not shown) included in the controller 10A. This communication driver 57A sends a copy of the first update data output by the database synchronization module 52A and a copy of the second update data output by the DRBD 55A to a standby controller 10B connected via the network, which will be described later. It is sent to driver 57B.

<Example of software configuration of controller 10B>
Various applications 51B, a database synchronization module 52B, a database management system (DBMS) 53B, a file system 54B, a DRBD 55B, a disk driver 56B, and a communication driver 57B are installed in the controller 10B. Note that the database management system (DBMS) 53B, file system 54B, disk driver 56B, and communication driver 57B are the same as those installed in the controller 10A, so their descriptions are omitted here.

The various applications 51B have a function of receiving first update data, second update data, and third update data, and also have a function of processing each received update data. Further, the various applications 51B have a function of outputting the processed data to one of two synchronization units (database synchronization module 52B, DRBD 55B) to be described later, based on the settings of the setting unit 45B.

Note that in the standby controller 10B, the various applications 51B accept the third update data and process it as appropriate. In addition, since the standby controller 10B receives the third update data, the various applications 51B do not output the processed third update data to any synchronization unit (database synchronization module 52B, DRBD 55B). Output to file system 54B. Thereafter, the third update data output to the file system 54B is written to the SSD 20B via the disk driver 56B. Here, the various applications 51B constitute the "output section" of the present invention.

The database synchronization module 52B has a function of receiving, via the communication driver 57B, a copy of the first update data transmitted from the database synchronization module 52A of the controller 10A via the communication driver 57A. Further, the database synchronization module 52B writes a copy of the received first update data to the database 25B via the DBMS 53B, the file system 54B, and the disk driver 56B, and completes the update of the database 25B. Here, the database synchronization module 52B constitutes the "synchronization section" of the present invention.

The DRBD 55B has a function of receiving, via the communication driver 57B, a copy of the second update data transmitted from the DRDB 55A of the controller 10A via the communication driver 57A. The DRDB 55B writes a copy of the received second update data to the SSD 20B via the disk driver 56B, and completes the update of the SSD 20B. Here, the DRBD 55B constitutes the "synchronization unit" of the present invention.

Next, specific data flows for each type will be explained with reference to FIGS. 4 to 7. FIG. 4 shows a flow of first update data or a copy thereof, FIG. 5 shows a flow of second update data or a copy thereof, and FIG. 6 shows a flow of third update data. FIG. 7 is a flowchart showing the flow of synchronization processing by the controller.

<First update data>
FIG. 4 shows the flow of first update data or a copy thereof. First, as shown in step ST1 in FIG. 7, the various applications 51A accept data such as the current value of the point 200 collected from the monitoring point 200 as first update data (reference numeral 1a in FIG. 4).

The various applications 51A process the received first update data as appropriate (step ST2), and refer to the setting unit 45A to confirm a synchronization method for the processed first update data (step ST3). Since the first update data is set to be synchronized by the duplication function (step ST4), the various applications 51A output the first update data to the database synchronization module 52A based on the settings (1b). . The database synchronization module 52A obtains a copy of the first update data and outputs the first update data to the DBMS 53A (1c).

The DBMS 53A executes an update transaction for the database 25A based on the first update data, and when the update transaction is successfully completed (committed), the first update data is transferred to the SSD 20A via the file system 54A and the disk driver 56A. The update of the database 25A is completed (1d to 1f).

Further, when the database 25A is updated by the DBMS 53A, the database synchronization module 52A transmits a copy of the acquired first update data to the controller 10B via the communication driver 57A (1g, 1h).

In the controller 10B, the database synchronization module 52B receives the copy of the first update data via the communication driver 57B (1i). The database synchronization module 52B writes a copy of the received first update data to the database 25B via the DBMS 53B, the file system 54B, and the disk driver 56B, and completes the update of the database 25B (1j to 1m).

Note that if the update transaction of the database 25A based on the first update data cannot be completed due to some abnormality, the DBMS 53A executes rollback processing and invalidates the update of the database 25A. In this case, database synchronization module 52A does not send a copy of the first update data to controller 10B.

In this way, the duplex system 1 writes the first update data to the database 25A and writes a copy of the first update data to the database 25B, thereby synchronizing the databases 25A and 25B. In particular, when the update transaction based on the first update data is successfully completed in the controller 10A, the duplex system 1 transmits a copy of the first update data to the controller 10B, and the controller 10B sends the received copy of the first update data to the controller 10B. A copy of the update data of No. 1 is written to the database 25B. Thereby, the duplex system 1 can avoid synchronizing data that is highly important or frequently updated for the system in an incomplete state, and can accurately synchronize data.

<Second update data>
FIG. 5 shows the flow of the second update data or its copy. First, the various applications 51A, as shown in step ST1 in FIG. 5 code 2a).

The various applications 51A process the received second update data as appropriate (step ST2), and refer to the setting unit 45A to check the synchronization method for the second update data (step ST3). Since the second update data is set to be synchronized by the DRBD (step ST5), the various applications 51A output the second update data to the DRBD 55A via the file system 54A based on the settings (step ST5). 2b, 2c). The DRBD 55A obtains a copy of the second update data, writes the second update data to the SSD 20A via the disk driver 56A, and completes the update of the SSD 20A (2d, 2e).

Furthermore, upon completing the update of the SSD 20A, the DRBD 55A transmits a copy of the second update data to the controller 10B via the communication driver 57A (2f, 2g).

In the controller 10B, the DRBD 55B receives the copy of the second update data via the communication driver 57B (2h). Then, the DRBD 55B writes a copy of the received second update data to the SSD 20B via the disk driver 56B, and completes the update of the SSD 20B (2i, 2j).

DRBD has the advantage of being able to copy data in real time and being compatible with any file system. On the other hand, with DRDB, if a network failure occurs while a copy of the data is being sent, there is a risk that the file may be damaged, and data can be guaranteed in units of blocks that make up files, but data cannot be guaranteed in units of files. There are also disadvantages such as.

Therefore, the duplication system 1 handles data that is considered to be less important or less frequently updated than the first data as second data, and synchronizes the second data using a general-purpose technology such as DRBD. As a result, the duplication system 1 can differentiate the synchronization method between the first data and the second data, and can appropriately and easily synchronize the data using a method commensurate with the importance or update frequency. can.

<Third update data>
FIG. 6 shows the flow of the third update data. First, as shown in step ST1 in FIG. 7, the various applications 51A accept, as third update data, data related to the OS-related program of the controller 10A, which is received by the controller 10A via a network (not shown), for example. 6 code 3a).

The various applications 51A process the received third update data as appropriate (step ST2), and refer to the setting unit 45A to check the synchronization method for the third update data (step ST3). Since the third update data is set not to be synchronized with the SSD 20B (step ST6), the various applications 51A transfer the third update data to the synchronization unit (database synchronization module 52A, It is not output to the DRBD 55A) but is output to the file system 54A (3b). The file system 54A writes the third update data to the SSD 20A via the disk driver 56A, and completes the update of the SSD 20A (3c, 3d).

Furthermore, in the controller 10B, the various applications 51B similarly accept data regarding the OS-related programs of the controller 10B as third update data (3e). The various applications 51B process the received third update data as appropriate (step ST2), and refer to the setting unit 45B to check the synchronization method for the third update data (step ST3). Since the third data is set not to be synchronized with the SSD 20A (step ST6), the various applications 51B transfer the third update data to the synchronization unit (database synchronization module 52B, DRBD 55B) based on the setting. ), but outputs to the file system 54B (3f). The file system 54B writes the third update data to the SSD 20B via the disk driver 56B, and completes the update of the SSD 20B (3g, 3h).

In the first embodiment, an example in which the controller 10A is operating as an active system has been described above. However, if an abnormality occurs in the controller 10A and the controller 10B is switched from the standby system to the active system, the controller 10B may perform processing in the same manner as the controller 10A described above. Furthermore, even if a redundant system is configured with three or more controllers, any one controller only needs to operate as the active system, and the active system controller is connected to other standby system controllers. Then, you can synchronize the data in the same way as above.

As described above, according to the first embodiment, the redundant system 1 is configured by two controllers 10A and 10B, and the controllers 10A and 10B use different synchronization methods and transfer the obtained data to the standby system. A plurality of synchronization units (database synchronization module 52A, DRBD55A, or database synchronization module 52B, DRBD55B) that synchronizes with data of the controller, and when the own device is the active system, the obtained data is synchronized with multiple synchronization units according to the type of the data. and an output section (various applications 51A or 51B) that outputs to one of the synchronization sections of. Thereby, the duplex system 1 can accurately synchronize data between the controllers 10A and 10B.

Further, according to the first embodiment, the output unit outputs the data to one of the plurality of synchronization units depending on the importance of the obtained data or the update frequency of the data. Thereby, the duplex system 1 can select an appropriate synchronization method depending on the importance or update frequency of data in the system.

Further, according to the first embodiment, when the obtained data is data that is not synchronized with the data of the standby controller, the output unit does not output the data to any of the plurality of synchronization units. Thereby, the duplex system 1 can differentiate between the necessity of synchronization and reduce the processing load on the controllers 10A and 10B while avoiding unnecessary data synchronization.

Note that within the scope of the present invention, any constituent elements of the embodiments may be modified or any constituent elements may be omitted from the embodiments.

1 Duplex system (redundant system)
10 Controller 10A Active system controller 10B Standby system controllers 20A, 20B SSD
25A, 25B Database 45A, 45B Setting section 51A, 51B Various applications (output section)
52A, 52B Database synchronization module (synchronization section)
53A, 53B Database management system (DBMS)
54A, 54B File system 55A, 55B DRBD (synchronization part)
56A, 56B Disk driver 57A, 57B Communication driver 150 System bus 200 Monitoring point

Claims (4)

A redundant system composed of multiple controllers,
Each of the controllers is
A plurality of synchronization units that use different synchronization methods and synchronize the obtained data with data of a standby controller;
an output unit that outputs the obtained data to one of the plurality of synchronization units according to the type of the data when the own machine is the active system;
Equipped with
If the type of the obtained data is first data whose importance or update frequency is the highest in the redundant system, the output unit outputs the first data from among the plurality of synchronization units. Output to the database synchronization module, which is one of the
The database synchronization module transmits a copy of the first data to a standby controller when updating the database of the own device based on the first data, and updates the database of the own device based on the first data. If the update of the database does not complete normally, the copy of the first data is not sent to the standby controller.
A redundant system characterized by: If the type of the obtained data is second data whose importance or update frequency is next to the first data in the redundant system, the output unit outputs the second data. Output the data to DRBD (registered trademark), which is one of the multiple synchronization units,
When the DRBD finishes updating the data in its own SSD based on the second data, the DRBD transmits a copy of the second data to a standby controller.
The redundant system according to claim 1, characterized in that: 2. The output unit is characterized in that, when the obtained data is data that is not synchronized with data of a standby controller, the output unit does not output the data to any of the plurality of synchronization units. The redundant system described in 2. A data synchronization method using multiple controllers configuring a redundant system, the method comprising:
Each of the controllers is
These synchronization methods are different from each other, and include multiple synchronization units that synchronize the obtained data with the data of the standby controller.
The output unit outputs the obtained data to one of the plurality of synchronization units according to the type of the data when the own machine is the active system,
If the type of the obtained data is first data whose importance or update frequency is the highest in the redundant system, the output unit outputs the first data from among the plurality of synchronization units. Output to the database synchronization module, which is one of the
The database synchronization module transmits a copy of the first data to a standby controller when updating the database of the own device based on the first data, and updates the database of the own device based on the first data. If the update of the database does not complete normally, the copy of the first data is not sent to the standby controller.
A data synchronization method characterized by:

Images