Computer control device

Abstract

Provided is a computer control device (50) with which it is easy to safely manage data handled by a container storing an application. Data stored in the container is prevented from being lost or modified while the container is stopped. A distributed database (10c) is disposed in each container (10-1 to 10-3), and a cluster is constituted by a combination of the distributed databases (10c) in the plurality of containers. The plurality of distributed databases (10c) within the cluster are linked, thus enabling the restoration of correct data when the containers (10) are restarted. Authentication processing is performed using ID information and key information when rewriting data, and history information is stored as a log. Data synchronization is performed periodically among the plurality of databases in the cluster.

Description

Computer Control Device

[0001] The present invention relates to a computer control device that uses an application program stored in a container, and in particular to a technique for ensuring the safety of the data that is handled.

[0002] BACKGROUND ART Application containerization technology is known as one of the technologies for virtualizing various applications that run on operating systems (OSs) in various computer systems.

[0003] For example, containerized applications can be executed by using a container engine such as "Docker" described in Non-Patent Document 1. Such a container packages the application program together with the execution environment for executing it. Containerized applications have the advantage that they can be transferred and executed in a different environment without any changes.

[0004] Non-Patent Document 2 describes automation technology related to containers, that is, a tool for orchestration called "kubernetes." Non-Patent Document 3 describes distributed database technology.

[0005] Docker, "Docker Builds: Now Lightning Fast", Internet<URL:https: / / www.docker.com / > kubernetes, "Production-Grade Container Orchestration", Internet<URL:https: / / kubernetes.io / > GLUSTER, "Storage for your cloud", Internet<URL:https: / / www.gluster.org / >

[0006] FIG. 1 shows an example of the configuration of an environment in which a containerized application is used. As shown in FIG. 1, a container 10 includes an application unit 11 and configuration information 12. The application unit 11 is realized by a processor (not shown) executing a program that embodies the functions of a predetermined application. The configuration information 12 includes various data necessary for the operation of the application unit 11 for each container. The application program for realizing the application unit 11 of such a container 10 is executed on the host OS unit 20 via a predetermined container engine.

[0007] Incidentally, data stored in the container 10 is lost when the operation of the container 10 is terminated. Therefore, if the container 10 crashes, data such as the setting information 12 required for the operation of the application of the container 10 may be lost.

[0008] As a countermeasure against the above-described data loss, it is generally assumed that a nonvolatile memory on the host side is utilized. That is, as shown in Fig. 1, when the storage 25 available to the host OS unit 20 includes a nonvolatile memory 25a, the nonvolatile memory 25a is mounted as the storage 13 of the container 10.

[0009] This allows data such as the setting information 12 required for the operation of the application of the container 10 to be saved in the storage 13, i.e., in the nonvolatile memory 25a, before the data is lost. Therefore, it becomes possible to restore the lost data in the container 10 by using the data stored in the nonvolatile memory 25a.

[0010] However, while the operation of the container 10 is stopped, there is a possibility that the data stored in the nonvolatile memory 25a may be tampered with. For example, the data in the nonvolatile memory 25a may be tampered with due to an erroneous input by an operator operating the host OS unit 20 or an attack by a malicious user. However, since the stopped container 10 has no choice but to restore its own data by relying on the data in the nonvolatile memory 25a, there is a possibility that the container 10 may malfunction due to data tampering.

[0011] In reality, for example, the owner or manager of the equipment on the host OS unit 20 side may be different from the owner or manager of the container 10 side. Therefore, it is difficult for the owner or manager of the container 10 side to ensure safety in a situation where the container 10 operates correctly.

[0012] The present invention has been made in view of the above circumstances, and has an object to provide a computer control device that can easily and safely manage data handled by a container.

[0013] The present invention is a computer control device that allows one or more containers containing an application program and predetermined setting information required in the operating environment of the application to run on a desired computer system, characterized in that it has: a plurality of containers arranged therein; a distributed database that holds management data for each container inside the container; and a cluster control unit that manages the management data of the distributed database so that it is linked between the plurality of containers, maintains the confidentiality of the data in the container, and prevents or detects unauthorized tampering of data from outside the container.

[0014] The computer control device of the present invention makes it easy to safely manage data handled by containers. That is, by sharing and linking the managed data among the distributed databases in multiple containers, it becomes easy to prevent and detect unauthorized data tampering from outside the container.

[0015] 1 is a block diagram showing an example of the configuration of an environment in which a containerized application is used. FIG. 2 is a block diagram showing main components of a computer system including a computer control device according to an embodiment of the present invention. FIG. 3 is a flowchart showing an example of processing when a container is restarted in a computer control device according to an embodiment of the present invention. FIG. 4 is a flowchart showing an example of processing that is periodically executed in a computer control device according to an embodiment of the present invention. FIG. 5 is a block diagram showing an example of information that is passed when a new container joins a cluster. FIG. 6 is a flowchart showing an example of operation when a new container joins a cluster. FIG. 7 is a block diagram showing an example of processing when data is registered in a cluster. FIG. 8 is a flowchart showing an example of operation when data is registered in a cluster.

[0016] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the accompanying drawings. <Configuration of Computer Control Device> Figure 2 shows the main components of a computer system including a computer control device according to an embodiment of the present invention.

[0017] 2 has three or more independent containers 10-1, 10-2, 10-3, etc. arranged as containers 10 for storing applications. Each of the containers 10-1, 10-2, 10-3, etc. incorporates an application section 10a, a setting information storage section 10b, and a distributed database 10c.

[0018] The application unit 10a is a functional unit realized by executing an application program. The setting information storage unit 10b stores setting information of the operating environment necessary for the application in the container to operate, i.e., configuration information.

[0019] As a typical example, when an agent application for controlling a server that manages an optical transmission device as a host is stored in the container 10, information on the setting environment of the optical module in the optical transmission device to be controlled by the host, such as the application ID, "laser poser," etc., is stored in the setting information storage unit 10b.

[0020] The distributed database 10c is a special database provided to prevent data loss of the setting information stored in the setting information storage unit 10b in the container 10, and is stored in, for example, a non-volatile memory. In addition, to enable safe data management, a distributed database cluster 30 is configured by combining multiple distributed databases 10c stored in different containers 10.

[0021] Each distributed database 10c belonging to the distributed database cluster 30 cooperates with the distributed databases 10c in other containers 10 and stores the settings of all the containers 10 in the distributed database cluster 30.

[0022] 2, each of the host OS units 20-1, 20-2, 20-3, etc. includes a database setting storage unit 21-1, 21-2, 21-3, etc. Each of the database setting storage units 21-1, 21-2, 21-3, etc. stores information required to access data in each distributed database 10c in the same distributed database cluster 30, for example, address information of the distributed database 10c for each container 10.

[0023] The cluster control unit 33 controls all distributed databases 10c in the same distributed database cluster 30 so that they can work together to manage data appropriately. In practice, the communication node to which one (representative) of the multiple containers 10 constituting the same distributed database cluster 30 belongs has the functions of the cluster control unit 33. Alternatively, a special controller having the functions of the cluster control unit 33 is installed on the computer system, separate from the container 10. Note that if there is one or more of the multiple database setting storage units 21-1, 21-2, 21-3, ..., the cluster control unit 33 can manage the distributed database cluster 30. In other words, the cluster control unit 33 links two or more distributed databases 10c as a cluster. Each distributed database 10c stores the information necessary to restore the setting information in all containers 10-1 to 10-3 included in the cluster.

[0024] The distributed database 10c in each container 10 belonging to the distributed database cluster 30 periodically performs synchronization processing with the distributed databases 10c of other containers 10 in the same cluster via a communication path 31, and manages the data so that it is consistent with each other. Furthermore, when rewriting data in each distributed database 10c, authentication processing is performed to prevent unauthorized rewriting, and log information related to the history of data rewrites is created and saved. By acquiring the log information, it is possible to prevent synchronization errors between multiple distributed databases 10c.

[0025] When a stopped container 10 is restarted, the container 10 accesses the data in the distributed database 10c of the other containers 10 that are running based on the data stored in the database setting storage unit 21, and reconstructs the contents of the distributed database 10c in the restarted container 10 from this data. Then, based on the contents of the distributed database 10c in the container 10, the configuration information in the configuration information storage unit 10b in the container 10 is restored. The above processing is performed, for example, by the cluster control unit 33. In other words, when a container 10 included in a cluster to be managed is restarted from a stopped state, the cluster control unit 33 obtains management data from the distributed database 10c in the other containers included in this cluster, reconstructs the data in the distributed database 10c in its own container, and restores the configuration information based on the distributed database 10c in its own container. A detailed operational example is described below.

[0026] <Processing at Restart> The flow of processing at the time of restarting a container is shown in Fig. 3. For example, when the container 10-1 shown in Fig. 2 is stopped for some reason and then restarted, the processing in Fig. 3 is executed with the container 10-1 as the local container. The processing in Fig. 3 will be described below.

[0027] For example, in step S11, the cluster control unit 33 obtains the address of the distributed database 10c in another running container, such as container 10-2, from the database setting storage unit 21-1 in the host OS unit 20-1. Then, in step S12, the cluster control unit 33 obtains necessary information from the distributed database 10c of the other container. Note that a container to be restarted also needs to be authenticated before rejoining the cluster. When a restarted container rejoins a cluster, authentication is performed using a combination of its own ID and key information stored in non-volatile memory, and only if authentication is successful will the container be incorporated into the cluster and restarted. Furthermore, if authentication fails, for example because the ID is rewritten during the container's restart, the container will join the cluster as a new container.

[0028] For example, the cluster control unit 33 reconstructs the contents of the distributed database 10c of its own container and the distributed database cluster 30 in step S13 based on the information acquired in step S12.

[0029] The container to be restarted, i.e., the container 10-1 or the cluster control unit 33, restores the setting information in the setting information storage unit 10b in the container 10-1 based on the contents of the distributed database 10c in step S14. As a result, the setting information in the setting information storage unit 10b is restored to the same state as before the container 10-1 was stopped.

[0030] <Periodic Processing> The periodic processing is shown in Fig. 4. The cluster control unit 33 periodically executes the processing of step S15 shown in Fig. 4. That is, the cluster control unit 33 periodically performs processing through communication using the communication path 31 so that the contents of all distributed databases 10c included in the distributed database cluster 30 are synchronized, that is, matched or consistent. During this synchronization processing, by referencing log information created when data in the distributed database 10c is rewritten, the data contents can be synchronized so that they match the correct latest information.

[0031] <Prevention of Registration of Unauthorized Data> In order to ensure the security of the data handled by the container 10, it is necessary to prevent, for example, a malicious user from registering unauthorized data in each distributed database 10c of the distributed database cluster 30. Therefore, the computer control device of this embodiment performs the following processing.

[0032] -<Operation when joining a cluster> Fig. 5 shows an example of information to be passed when a new container joins the distributed database cluster 30. Fig. 5 assumes a situation in which a distributed database 10c in a container 10-X is about to newly join a distributed database cluster 30 that is already running on multiple containers 10-1 to 10-N.

[0033] As shown in Figure 5, in this embodiment, the application unit 10a of each container 10 previously stores key information 10d. This key information 10d is configured as information such as a private key and a public key. Furthermore, it is necessary to prevent this key information 10d from being lost when the container is restarted. Therefore, for example, the key information 10d is implemented as part of the code within the program.

[0034] As shown in Figure 5, in this embodiment, when a distributed database 10c in a container 10-X newly joins the distributed database cluster 30, the key information 10d on the container 10-X side is sent to the distributed database cluster 30 side, and ID information 35 is sent from the distributed database cluster 30 side to the container 10-X side.

[0035] An example of the operation when a new container joins the distributed database cluster 30 is shown in Fig. 6. The example of the operation shown in Fig. 6 will be explained below. In step S21, the container 10-X, which is the join requesting side, sends a join request including its own key information 10d to the distributed database cluster 30 via the host OS unit 20.

[0036] The distributed database cluster 30 determines the ID information 35 to be issued to the requesting side in step S22, and registers the combination of this ID information 35 and the key information 10d received from the requesting side in the distributed database 10c on the distributed database cluster 30.

[0037] The distributed database cluster 30 sends the participation approval to the requesting container 10-X together with the ID information 35 assigned in step S23. The participation requesting container 10-X stores its own ID information 35 received in step S24 on the host OS unit 20 side.

[0038] When a container 10 that previously participated in the distributed database cluster 30 is stopped due to a failure or the like and then restarts and rejoins the distributed database cluster 30, the container 10 requests rejoining the cluster using a combination of its own ID information 35 already registered on the host OS unit 20 and the key information used when joining the cluster. In other words, the cluster control unit 33 has an authentication function that prevents unauthorized writing by executing an authentication process when rewriting data in each distributed database 10c, and a log function that saves history information of data rewriting as a log.

[0039] -<Processing when registering data> Fig. 7 shows an example of the processing when registering data in the distributed database cluster 30. As shown in Fig. 7, a container 10-X requesting data registration in the distributed database cluster 30 issues an authentication query 41 that combines its own ID information 35 and key information 10d. The container 10-X is located in the host OS unit 20.

[0040] The distributed database cluster 30 verifies the authentication query 41 input from the requesting side based on the authentication verification data 42, i.e., the combination of the ID information 35 and key information 10d registered in advance on the cluster side. If the authentication of the authentication query 41 is successfully completed, the distributed database cluster 30 permits the registration of the registration target data 43 on the requesting side.

[0041] Fig. 8 shows an example of the operation when registering data in the distributed database cluster 30. As shown in Fig. 8, the container 10-X on the registration requesting side sends a data registration request including ID information 35 and key information 10d to the distributed database cluster 30 in step S31.

[0042] When the distributed database cluster 30 receives the data registration request in step S32, it verifies the authentication query 41 based on the combination of key information 10d and ID information 35 that have been registered in advance on the cluster side. If the authentication is completed successfully, the distributed database cluster 30 proceeds to the processing of steps S33 to S34. In step S34, the distributed database cluster 30 registers the registration target data 43 and saves the registration history as log information.

[0043] <Features of the Present Invention> Characteristic features of the computer control device of the present invention are listed below in [1] to [4]. [1] A computer control device (50) capable of running one or more containers containing application programs and predetermined setting information required in the operating environment of the application on a desired computer system, the computer control device (50) comprising: a plurality of distributed databases (10c) each holding management data for a plurality of arranged containers (10-1, 10-2, 10-3, ...), and a cluster control unit (33) that manages the management data of the plurality of distributed databases (10c) so that the management data is linked between the plurality of containers, maintains confidentiality of data in each of the containers (setting information holding unit 10b), and has a function to prevent or detect unauthorized data tampering from outside each of the containers.

[0044] The computer control device having the configuration described in [1] above can prevent the configuration information of the container from being tampered with by an operator's erroneous operation or malicious unauthorized operation. Therefore, even if, for example, the administrator of the container is different from the administrator of the host device that actually runs the container, the data handled by each container can be managed correctly.

[0045] [2] The computer control device (50) described in [1] above, wherein three or more of the containers are arranged, the cluster control unit (33) links the three or more distributed databases (10c) as a cluster, and each of the distributed databases (10c) holds information necessary for restoring the setting information in all of the containers included in the cluster.

[0046] According to the computer control device having the configuration [2] above, if data is lost or tampered with in any one of the containers included in the cluster, it becomes easy to restore the lost or tampered data to its original correct state.

[0047] [3] The cluster control unit (33) has an authentication function that prevents unauthorized writing by performing authentication processing when rewriting data in each distributed database (10c), and a log function that saves historical information of data rewriting as a log (steps S31 to S34), the computer control device (50) described in [1] above.

[0048] According to the computer control device having the configuration [3] above, the authentication function can prevent malicious users from registering invalid data. Furthermore, by using the history information stored by the log function, it becomes easy to properly synchronize the data in the multiple distributed databases (10c).

[0049] [4] When one container included in a cluster to be managed is restarted from a stopped state, the cluster control unit (33) obtains the management data from the distributed database (10c) in another container included in the cluster, reconstructs the data of the distributed database (10c) in its own container, and restores the configuration information based on the distributed database (10c) in its own container (steps S11 to S14), the computer control device (50) described in [1] above.

[0050] According to the computer control device having the configuration [4] above, when the container is restarted from a stopped state, the necessary data is obtained from other containers operating within the cluster and the data in the distributed database is reconstructed, so that the configuration information can be correctly restored to the same state as before the container was stopped.

[0051] 10, 10-1, 10-2, 10-3, 10-X Container 10a Application section 10b Setting information storage section 10c Distributed database 10d Key information 11 Application section 12 Setting information 13 Storage 20, 20-1, 20-2, 20-3 Host OS section 21, 21-1, 21-2, 21-3 Database setting storage section 25 Storage 30 Distributed database cluster 31 Communication path 33 Cluster control section 35 ID information 41 Authentication query 42 Authentication verification data 43 Data to be registered 50 Computer control device

Claims

1. A computer control device that allows one or more containers containing application programs and predetermined setting information required in the operating environment of the application to run on a desired computer system, the computer control device comprising: a plurality of distributed databases that each hold management data for a plurality of deployed containers; and a cluster control unit that manages the management data of the plurality of distributed databases so that it is linked between the plurality of containers, maintains the confidentiality of the data within the containers, and prevents or detects unauthorized tampering with the data from outside the containers.

2. The computer control device described in claim 1, wherein three or more of the containers are arranged, the cluster control unit links the three or more distributed databases as a cluster, and each of the distributed databases holds information necessary to restore the configuration information in all of the containers included in the cluster.

3. The computer control device according to claim 1, wherein the cluster control unit has an authentication function that prevents unauthorized writing by executing an authentication process when rewriting data in each of the distributed databases, and a log function that saves historical information about data rewriting as a log.

4. The computer control device according to claim 1, wherein when one container included in a managed cluster is restarted from a stopped state, the cluster control unit obtains the management data from the distributed database in another container included in the cluster, reconstructs the data in the distributed database in its own container, and restores the configuration information based on the distributed database in its own container.

Images