Management device, management method, and management program

Abstract

In a production environment (E1), an autonomous management system (MS) detects a change in a parameter file (PF). In response to detecting a change in the parameter file (PF), the autonomous management system (MS) updates a parameter file (f1) included in a DB container (Cr1) according to the change, and writes content of the change to a parameter table (T1) provided in a database (DB1) included in the DB container (Cr1). In a disaster response environment (E2), an autonomous management system (MS') detects a change in a parameter table (T1') in a database (DB1') included in a DB container (Cr1'). In response to detecting a change in the parameter table (T1'), the autonomous management system (MS') updates a parameter file (PF') according to the change.

Description

Management device, management method, and management program

[0001] The present invention relates to a management device, a management method, and a management program.

[0002] Traditionally, disaster recovery (DR) measures for business systems have been important in preparation for unforeseen events such as natural disasters and man-made disasters. For example, in systems that require high availability, a hot standby system is used to operate a DR environment separate from the production environment, and in the event of a disaster, the production environment is switched over to the DR environment. Also, containerized databases are becoming more popular to reduce the costs of system operation and management.

[0003] In one prior art technique, a primary database system determines from a query request from a client application that the workload from the query can be shifted to a secondary database system, and instructs the client application to instruct the secondary database system to execute the query. Another technique involves assigning a token and a unique sequence number in response to each write operation at the primary site, transmitting the token and update data to the remote site, and using the sequence number to establish the sequence and define gaps in the sequence to identify missing update data.

[0004] JP 2018-088235 JP JP 6-290125 JP

[0005] However, with conventional technology, it is difficult to properly manage parameter information related to the management of containers, including databases, which is referenced by a management unit (e.g., an autonomous management system) that manages containers deployed in each environment, such as a production environment or a disaster recovery environment.

[0006] In one aspect, the present invention aims to appropriately manage parameter information related to management of containers including databases.

[0007] In one embodiment, a management device is provided that has a control unit that executes the following processing: in the first environment, of redundant first and second environments, detects a change in management parameter information related to the management of a first container including a database, which is referenced by a management unit that manages containers deployed in the first environment; and, in response to detecting the change, updates control parameter information related to the control of the first container, which is contained in the first container and referenced by the first container, in accordance with the change, and writes the content of the change to change history information provided in the database; and in the second environment, detects a change in change history information in a database contained in a second container that is deployed in the second environment and synchronized with the first container by a data synchronization function; and, in response to detecting the change, updates management parameter information related to the management of the second container, which is referenced by a management unit that manages containers deployed in the second environment, in accordance with the change.

[0008] According to one aspect of the present invention, it is possible to appropriately manage parameter information related to management of containers including databases.

[0009] FIG. 1 is an explanatory diagram illustrating an example of a management method according to an embodiment. FIG. 2 is an explanatory diagram illustrating an example of a system configuration of an information processing system 200. FIG. 3 is a block diagram illustrating an example of a hardware configuration of an information processing device 201, etc. FIG. 4 is a block diagram illustrating an example of a functional configuration of the information processing device 201 in the production environment E1. FIG. 5 is a block diagram illustrating an example of a functional configuration of the information processing device 202 in the disaster recovery environment E2. FIG. 6 is an explanatory diagram illustrating an example of the operation of the information processing system 200. FIG. 7 is an explanatory diagram illustrating an example of transaction processing accompanying a change in a parameter file PF. FIG. 8 is a sequence diagram illustrating an example of the operation in the production environment E1. FIG. 9 is a sequence diagram illustrating an example of the operation in the disaster recovery environment E2. FIG. 10 is an explanatory diagram illustrating an example of the contents stored in a parameter table T1. FIG. 11 is an explanatory diagram illustrating an example of updating the parameter table T1. FIG. 12 is a flowchart illustrating an example of a DB container deployment process procedure for the information processing device 201 in the production environment E1. FIG. 13 is a flowchart illustrating an example of a management process procedure for the information processing device 201 in the production environment E1. Fig. 14 is a flowchart showing an example of a management processing procedure for the information processing device 202 in the disaster recovery environment E2. Fig. 15 is a flowchart showing an example of a promotion processing procedure for the information processing device 202 in the disaster recovery environment E2. Fig. 16 is an explanatory diagram showing an example of container deployment in each environment. Fig. 17 is an explanatory diagram showing a specific example of a parameter file PF.

[0010] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, with reference to the accompanying drawings, a management apparatus, a management method, and a management program according to embodiments of the present invention will be described in detail.

[0011] 1 is an explanatory diagram showing an example of a management method according to an embodiment. In FIG. 1, a management device 101 is a computer that manages containers. A container corresponds to a user space isolated from others, created by dividing the kernel of an OS (Operating System), and operates as one of the OS processes.

[0012] For example, a container is a package that contains an application, middleware, a library, and so on. Each container is controlled based on, for example, a parameter file. Because general application containers operate independently, even if a container goes down while a process is running, the same process can still be executed according to the parameter file.

[0013] On the other hand, there are cases where not only applications but also databases (DBs) are containerized. Unlike application containers, DB containers (database containers) hold data and therefore require continuous operation. For this reason, databases are deployed in a redundant configuration, and control is exercised to synchronize data across multiple DB containers.

[0014] Conventionally, there are container orchestration tools that automatically manage container deployment, scaling, and the like in order to reduce costs associated with container operation management. Kubernetes (k8s), for example, is an example of a container orchestration tool. Kubernetes is a registered trademark.

[0015] Furthermore, when building a business system in a K8s environment, there is a technology (autonomous management system) that creates, modifies, and deletes parameter files for each container based on a parameter file that centrally manages the business system settings. The parameter file includes, for example, container configuration information and database settings (e.g., authentication information such as passwords). Furthermore, the autonomous management system may autonomously determine optimal parameters based on the operational status of the business system and reflect them in the container.

[0016] Here, it is important to implement disaster prevention measures for business systems in order to continue business (operations) even if unforeseen events such as natural disasters or man-made disasters occur. For example, a hot standby system can be used to operate a disaster recovery environment (disaster recovery environment) separate from the production environment, and in the event of a disaster, business operations can be continued by switching from the production environment to the disaster recovery environment.

[0017] On the other hand, in business systems that use containers including databases, in order to perform operations equivalent to those in the production environment in the event of a disaster, it is necessary to have the same parameter files and data in the production environment and the disaster recovery environment. For example, the database itself synchronizes data using methods such as streaming replication.

[0018] Streaming replication is a technology for synchronizing data in real time. With streaming replication, not only database data but also parameter information reflected in the database is synchronized. For example, by transferring database update information in the production environment to the disaster recovery environment in real time, it is possible to keep the databases in the production environment and disaster recovery environment in the same state.

[0019] In addition, in business systems in K8s environments, the autonomous management system manages containers based on parameter files. Therefore, by creating a backup of the parameter file referenced by the autonomous management system in the production environment and restoring it to the disaster recovery environment, it is possible to maintain the same parameter file as in the production environment in the disaster recovery environment.

[0020] Existing technologies for maintaining the same parameter files in the disaster recovery environment as in the production environment include, for example, a backup and restore tool that periodically backs up and restores the entire K8s environment, and a centralized management tool that centrally manages parameter files and applies them to both the production environment and the disaster recovery environment.

[0021] However, with conventional technology, it is difficult to properly manage parameter files related to the management of containers including databases (DB containers) referenced by the autonomous management system. For example, depending on the timing of backups, there may be a discrepancy between the parameter files used by the autonomous management system in a disaster recovery environment and the parameter information reflected in the DB container.

[0022] Parameter information for DB containers is synchronized in real time from the production environment to the disaster recovery environment using streaming replication. However, with existing backup and restore tools, the parameter files used by the autonomous management system are backed up at user-specified times and restored to the disaster recovery environment.

[0023] For this reason, if the production environment goes down before a backup of the parameter file used by the autonomous management system in the production environment is made, parameter information may become out of sync in the disaster recovery environment. For example, in a disaster recovery environment, parameter information in DB containers is updated by streaming replication, but the parameter file used by the autonomous management system may not be updated, resulting in a discrepancy.

[0024] In this case, even if the production environment is switched to the disaster recovery environment when a disaster occurs, the autonomous management system cannot manage the operation of the containers. For example, if the database password is not transmitted to the parameter file of the autonomous management system, the autonomous management system cannot connect to the database after switching from the production environment to the disaster recovery environment, and the operation of the database cannot be managed.

[0025] To prevent such discrepancies using existing technology, it is necessary to create a backup as soon as parameter information is changed in the production environment. However, parameter information changes in the production environment are not only performed manually by system administrators, but also autonomously by autonomous management systems.

[0026] As a result, system administrators must not only manually change parameter information, but also monitor changes to parameter information made by the autonomous management system and manually create backups.However, changes made by the autonomous management system are made irregularly depending on the operational status of the business system, making it difficult to determine the timing for backup execution.

[0027] In this way, creating backups manually by system administrators and others complicates operational management and poses the risk of human error, such as entering incorrect commands. Furthermore, existing centralized management tools do not anticipate the ability to pull parameter information that changes autonomously in the production environment and push it to the disaster recovery environment (there are restrictions on the direction of information).

[0028] Therefore, in this embodiment, a management method for appropriately managing parameter information related to the management of containers including databases (DB containers) will be described. Here, an example of processing by the management device 101 will be described. The management device 101 is arranged in each of a first environment 110 and a second environment 120, which are made redundant. The first environment 110 is, for example, a production environment. The second environment 120 is a disaster recovery (disaster countermeasure) environment.

[0029] Here, the management device 101 arranged in the first environment 110 is referred to as the "first management device 101-1," and the management device 101 arranged in the second environment 120 is referred to as the "second management device 101-2."

[0030] In the first environment 110, the first management device 101-1 detects a change in management parameter information 112 referenced by a management unit 111. The management unit 111 manages containers deployed in the first environment 110. The management unit 111 corresponds to, for example, an autonomous management system. The management parameter information 112 is information related to the management of a first container 113. The first container 113 is a container (DB container) deployed in the first environment 110 and including a database 114.

[0031] The management parameter information 112 includes, for example, configuration information of the first container 113 and parameter values ​​set in a database 114 included in the first container 113. The configuration information of the first container 113 includes, for example, specifications of the CPU (Central Processing Unit) and memory of the first container 113.

[0032] The parameter set in the database 114 is, for example, a password for connecting to the database 114. The management parameter information 112 is changed, for example, manually by a system administrator or by the management unit 111 depending on the operational status of the business system.

[0033] Upon detecting a change in the management parameter information 112, the first management device 101-1 updates the control parameter information 115 contained in the first container 113 in accordance with the change, and writes the details of the change to the change history information 116 provided in the database 114.

[0034] The control parameter information 115 is information related to the control of the first container 113, which is referenced by the first container 113. The control parameter information 115 includes, for example, configuration information of the first container 113 and parameter values ​​set in the database 114 included in the first container 113.

[0035] The first container 113 is controlled based on control parameter information 115. In the first environment 110, if a discrepancy occurs in the information related to the first container 113 between the management parameter information 112 referenced by the management unit 111 and the control parameter information 115 in the first container 113, the management unit 111 will not be able to appropriately manage the operation of the first container 113.

[0036] Therefore, when the management parameter information 112 is changed, the first management device 101-1 updates the control parameter information 115 in the first container 113 in accordance with the change. Furthermore, the first management device 101-1 writes the content of the change to the management parameter information 112 into change history information 116 in the database 114.

[0037] In the second environment 120, the second management device 101-2 detects a change in the change history information 126 in the database 124 included in the second container 123. Here, the second container 123 is a container (DB container) that is deployed in the second environment 120 and synchronized with the first container 113 by a data synchronization function.

[0038] The data synchronization function is, for example, streaming replication, which performs real-time data synchronization between a first container 113 (synchronization source) in the first environment 110 and a second container 123 (synchronization destination) in the second environment 120.

[0039] This updates the control parameter information 125 and change history information 126 in the second container 123. The control parameter information 125 is information related to the control of the second container 123 that is referenced by the second container 123, and corresponds to the control parameter information 115 of the first container 113. The change history information 126 is information corresponding to the change history information 116 of the first container 113.

[0040] In response to detecting a change in the change history information 126, the second management device 101-2 updates the management parameter information 122 referenced by the management unit 121 in accordance with the change. The management unit 121 manages containers deployed in the second environment 120. The management unit 121 corresponds to, for example, an autonomous management system. The management parameter information 122 is information related to the management of the second container 123, and is information corresponding to the management parameter information 112 of the first environment 110.

[0041] In this way, the second management device 101-2 can utilize a data synchronization function (e.g., streaming replication) to detect changes to the parameter information (management parameter information 112, control parameter information 115) in the first environment 110 from the change history information 126, and update the management parameter information 122 in the second environment 120.

[0042] For these reasons, the management device 101 (first management device 101-1, second management device 101-2) can appropriately manage parameter information related to the management of DB containers (first container 113, second container 123). For example, the management device 101 can prevent discrepancies from occurring between the control parameter information 125 in the second container 123 and the management parameter information 122 referenced by the management unit 121 in the second environment 120.

[0043] As a result, when changing the configuration of the first environment 110 (e.g., a production environment), the management device 101 eliminates the need for a system administrator or the like to manually change the configuration of the second environment 120 (e.g., a disaster recovery environment), thereby reducing operational management costs and human error (operational mistakes).

[0044] Furthermore, when switching from the first environment 110 to the second environment 120 in the event of a disaster or the like, the management device 101 can appropriately perform operation management of the database 124 in the second container 123. For example, the management device 101 can avoid a situation in which the management unit 121 cannot connect to the database 124 and perform operation management, which occurs when authentication information such as a password is not transmitted to the management unit 121.

[0045] (System Configuration Example of Information Processing System 200) Next, a system configuration example of the information processing system 200 including the management device 101 shown in Fig. 1 will be described. Here, the case where the management device 101 shown in Fig. 1 is applied to the information processing devices 201 and 202 in the information processing system 200 will be described as an example.

[0046] Fig. 2 is an explanatory diagram showing an example of the system configuration of an information processing system 200. In Fig. 2, the information processing system 200 includes an information processing device 201, an information processing device 202, and an administrator terminal 203. In the information processing system 200, the information processing device 201, the information processing device 202, and the administrator terminal 203 are connected via a wired or wireless network 210. The network 210 is, for example, the Internet, a LAN (Local Area Network), or a WAN (Wide Area Network).

[0047] Here, the information processing device 201 is a computer in the production environment E1. The production environment E1 is an environment in which a system actually used by a user operates. The system is, for example, a business system. The first management device 101-1 shown in FIG. 1 corresponds to, for example, the information processing device 201. Furthermore, the first environment 110 shown in FIG. 1 corresponds to, for example, the production environment E1.

[0048] The information processing apparatus 201 can execute one or more containers Cr. A container Cr is, for example, a DB container or an application container. A DB container is a container that includes a database. An application container is a container that does not include a database.

[0049] The information processing device 201 is also capable of executing an autonomous management system MS. The autonomous management system MS is software that manages containers Cr deployed in the production environment E1. The information processing device 201 is realized, for example, by one or more servers.

[0050] The information processing device 202 is a computer in the disaster recovery environment E2. The production environment E1 and the disaster recovery environment E2 are made redundant for disaster recovery purposes. The disaster recovery environment E2 is a standby system synchronized with the production environment E1 (operational system). The disaster recovery environment E2 operates so that it can be immediately switched over from the production environment E1 in the event of a disaster. The second management device 101-2 shown in FIG. 1 corresponds to, for example, the information processing device 202. Furthermore, the second environment 120 shown in FIG. 1 corresponds to, for example, the disaster recovery environment E2.

[0051] The information processing device 202 is capable of executing one or more containers Cr'. The containers Cr' correspond to the containers Cr in the production environment E1. The information processing device 202 is also capable of executing an autonomous management system MS'. The autonomous management system MS' is software that manages the containers Cr' deployed in the disaster recovery environment E2. The information processing device 202 is realized, for example, by one or more servers.

[0052] The administrator terminal 203 is a computer used by a system administrator of the information processing system 200. The administrator terminal 203 is, for example, a PC (Personal Computer) or a tablet PC.

[0053] (Example of Hardware Configuration of Information Processing Devices 201, etc.) Next, a description will be given of an example of the hardware configuration of the information processing devices 201 and 202. Here, the information processing devices 201 and 202 will be referred to as "information processing devices 201, etc."

[0054] 3 is a block diagram showing an example of the hardware configuration of the information processing device 201, etc. In Fig. 3, the information processing device 201, etc. includes a CPU 301, a memory 302, a disk drive 303, a disk 304, a communication I / F (Interface) 305, a portable recording medium I / F 306, and a portable recording medium 307. Furthermore, each component is connected to each other via a bus 300.

[0055] Here, the CPU 301 is responsible for overall control of the information processing device 201, etc. The CPU 301 may have multiple cores. The memory 302 includes, for example, a read-only memory (ROM), a random access memory (RAM), and a flash ROM. Specifically, for example, the flash ROM stores an OS program, the ROM stores application programs, and the RAM is used as a work area for the CPU 301. The programs stored in the memory 302 are loaded into the CPU 301, causing the CPU 301 to execute the coded processes.

[0056] The disk drive 303 controls the reading and writing of data from and to the disk 304 under the control of the CPU 301. The disk 304 stores data written under the control of the disk drive 303. The disk 304 is, for example, a magnetic disk or an optical disk.

[0057] The communication I / F 305 is connected to the network 210 via a communication line, and is connected to an external computer via the network 210. The communication I / F 305 serves as an interface between the network 210 and the inside of the device, and controls input and output of data from and to the external computer. The communication I / F 305 is, for example, a modem or a LAN adapter.

[0058] The portable recording medium I / F 306 controls reading and writing of data from and to the portable recording medium 307 under the control of the CPU 301. The portable recording medium 307 stores data written under the control of the portable recording medium I / F 306. The portable recording medium 307 is, for example, a CD (Compact Disc)-ROM, a DVD (Digital Versatile Disk), or a USB (Universal Serial Bus) memory.

[0059] Note that the information processing device 201, etc. may have, for example, an input device, a display, etc. in addition to the above-mentioned components. Furthermore, the information processing device 201, etc. may not have, for example, the portable recording medium I / F 306 and the portable recording medium 307 among the above-mentioned components. Furthermore, the administrator terminal 203 shown in FIG. 2 can also be realized with the same hardware configuration as the information processing device 201, etc. However, the administrator terminal 203 has, for example, an input device, a display, etc. in addition to the above-mentioned components.

[0060] (Example of Functional Configuration of Information Processing Apparatus 201) Next, an example of the functional configuration of the information processing apparatus 201 in the production environment E1 will be described.

[0061] FIG. 4 is a block diagram showing an example of the functional configuration of the information processing device 201 in the production environment E1. In FIG. 4, the information processing device 201 includes a creation unit 401, a first detection unit 402, and a first update unit 403. The creation unit 401 to the first update unit 403 are functions that constitute the control unit 400, and specifically, the functions are realized by, for example, having the CPU 301 execute a program stored in a storage device such as the memory 302, disk 304, or portable recording medium 307 of the information processing device 201 shown in FIG. 3, or by the communication I / F 305. The processing results of each functional unit are stored in a storage device such as the memory 302 or disk 304. More specifically, for example, each functional unit may be realized by the autonomous management system MS shown in FIG. 2.

[0062] In the following description, any DB container among the containers Cr in the production environment E1 may be referred to as "DB container Cr#." Furthermore, a database included in a DB container Cr# may be referred to as "database DB#." Furthermore, among the containers Cr' in the disaster recovery environment E2, a DB container that corresponds to a DB container Cr# in the production environment E1 may be referred to as "DB container Cr#'."

[0063] The DB container Cr# in the production environment E1 is synchronized with the DB container Cr#' in the disaster recovery environment E2 using a data synchronization function. However, the DB container Cr# is the synchronization source and the DB container Cr# is the synchronization destination. The data synchronization function is, for example, streaming replication.

[0064] With streaming replication, for example, by transferring update information for DB container Cr# to DB container Cr#' in real time, it is possible to maintain the databases of DB container Cr# and DB container Cr#' in the same state. For example, update information for DB container Cr# is saved as a WAL (Write-Ahead Log, transaction log). With streaming replication, this WAL is transferred to DB container Cr#' in real time, and the WAL is applied in DB container Cr#'.

[0065] When deploying a DB container Cr# in the production environment E1, the creation unit 401 creates a parameter table T# in a database DB# included in the DB container Cr#. The parameter table T# stores changes to parameter information related to the management of the container Cr deployed in the production environment E1. The change history information 116 shown in FIG. 1 corresponds to, for example, the parameter table T#.

[0066] The parameter information includes, for example, configuration information of the DB container Cr# and parameter values ​​set in the database DB# included in the DB container Cr#. The configuration information of the DB container Cr# indicates, for example, the CPU and memory specifications of the DB container Cr#. The parameters set in the database DB# include, for example, the password and specifications of the database DB#. The parameter information initially registered in the parameter table T# is specified, for example, by a system administrator.

[0067] For example, assume that a DB container Cr1 as shown in Fig. 6 (described later) is deployed in a production environment E1. In this case, the creation unit 401 creates a parameter table T1 in a database DB1 included in the DB container Cr1. To explain in more detail, for example, the creation unit 401 creates the parameter table T1 using the following CREATE TABLE statement:

[0068] CREATE TABLE statement = create table update_parameter (param_name text, param_value_text, create_at timestamp, param_value_updated_text, , update_at timestamp);

[0069] The contents stored in the parameter table T1 will be described later with reference to FIG. 10. Note that "param_name text" corresponds to the "parameter name" shown in FIG. 10, which will be described later. "param_value_text" corresponds to the "value" shown in FIG. 10. "create_at timestamp" corresponds to the "timestamp" shown in FIG. 10. "param_value_updated_text" corresponds to the "updated value" shown in FIG. 10. "update_at timestamp" corresponds to the "updated timestamp" shown in FIG. 10.

[0070] The first detection unit 402 detects changes to the parameter file PF referenced by the autonomous management system MS. Here, the autonomous management system MS is a management unit that manages containers Cr deployed in the production environment E1 (see FIG. 2). The parameter file PF is parameter information (management parameter information) related to the management of the containers Cr deployed in the production environment E1.

[0071] For example, the parameter file PF includes parameter information related to the management of DB containers Cr# deployed in the production environment E1. The parameter file PF also includes parameter information related to the management of application containers deployed in the production environment E1. The parameter file PF is changed by a system administrator using, for example, the administrator terminal 203 shown in FIG. 2. The parameter file PF may also be autonomously changed by the autonomous management system MS depending on, for example, the operational status of the business system running in the production environment E1.

[0072] Specifically, for example, the first detection unit 402 periodically checks the contents of the parameter file PF at regular intervals. The regular interval can be set arbitrarily, for example, to a few seconds. The first detection unit 402 then compares the latest stored contents of the parameter file PF with the immediately preceding stored contents.

[0073] If there is a difference between the latest stored content and the immediately preceding stored content, the first detection unit 402 detects a change in the parameter file PF. On the other hand, if there is no difference between the latest stored content and the immediately preceding stored content, the first detection unit 402 does not detect a change in the parameter file PF.

[0074] The first detection unit 402 may also detect a change to the parameter file PF by detecting a change process to the parameter file PF by a system administrator using the administrator terminal 203. The first detection unit 402 may also detect a change to the parameter file PF by detecting an autonomous change process to the parameter file PF by the autonomous management system MS.

[0075] When a change in the parameter file PF is detected, the first update unit 403 updates the parameter file f# included in the DB container Cr# in accordance with the change, and writes the details of the change to a parameter table T# provided in the database DB#. Here, the parameter file f# is information related to the control of the DB container Cr# (control parameter information) that is referenced by the DB container Cr#.

[0076] The parameter file f# includes, for example, configuration information for the DB container Cr# and parameter values ​​set for the database DB# included in the DB container Cr#. The DB container Cr# is controlled based on the parameter file f#. More specifically, for example, the first update unit 403 writes to the parameter table T# using the following INSERT statement:

[0077] INSERT statement = INSERT into update_parameter (update value, update timestamp) VALUES (updated value, updated time);

[0078] An example of updating the parameter table T1 will be described later with reference to FIG.

[0079] In addition, when the first update unit 403 writes the contents of the detected changes to the parameter file PF to the parameter table T#, if the first update unit 403 fails to update the parameter file f# in accordance with the changes, the first update unit 403 may not write the contents of the changes to the parameter table T#.

[0080] Specifically, for example, in response to detecting a change in the parameter file PF, the first update unit 403 acquires the changed parameter information from the parameter file PF. Then, using the changed parameter information, the first update unit 403 performs, within one transaction, a process of updating the parameter file f# in the DB container Cr# and a process of writing the changed parameter information to the parameter table T# in the database DB#.

[0081] As a result, if updating of parameter file f# fails, the changes to parameter file PF are not written to parameter table T#. Similarly, if writing of changes to parameter file PF to parameter table T# fails, updating of parameter file f# is not performed.

[0082] Furthermore, in response to detecting a change in the parameter file PF, the first update unit 403 may further update, in accordance with the change, a parameter file included in another container other than the DB container Cr# among the containers Cr deployed in the production environment E1. The other container is, for example, an application container that does not include a database.

[0083] The parameter file included in the other container is information (control parameter information) related to the control of the other container that is referenced by the other container. As a result, the first update unit 403 reflects the changes in the parameter file PF in the parameter files of the other containers (e.g., application containers).

[0084] In disaster recovery environment E2, when a change is detected in parameter table T#' in database DB#' contained in DB container Cr#', which is synchronized with DB container Cr# by the data synchronization function, the parameter file PF' referenced by the autonomous management system MS' is updated in accordance with the change.

[0085] (Example of Functional Configuration of Information Processing Apparatus 202) Next, an example of the functional configuration of the information processing apparatus 202 in the disaster recovery environment E2 will be described.

[0086] FIG. 5 is a block diagram illustrating an example of the functional configuration of the information processing device 202 in the disaster response environment E2. In FIG. 5, the information processing device 202 includes a second detection unit 501 and a second update unit 502. The second detection unit 501 to the second update unit 502 function as the control unit 500, and specifically, the functions are realized by, for example, having the CPU 301 execute a program stored in a storage device such as the memory 302, disk 304, or portable recording medium 307 of the information processing device 202 shown in FIG. 3, or by the communication I / F 305. The processing results of each functional unit are stored in a storage device such as the memory 302 or disk 304. More specifically, for example, each functional unit may be realized by the autonomous management system MS' shown in FIG. 2.

[0087] The second detection unit 501 detects changes to a parameter table T#' in a database DB#' included in a DB container Cr#'. The DB container Cr#' is deployed in the disaster recovery environment E2 and is synchronized with the DB container Cr# in the production environment E1 by a data synchronization function (for example, streaming replication).

[0088] Parameter table T#' is synchronized with parameter table T# in database DB included in DB container Cr# of production environment E1 by a data synchronization function (e.g., streaming replication). The change history information 126 shown in FIG. 1 corresponds to parameter table T#', for example.

[0089] Specifically, for example, the second detection unit 501 periodically checks the contents of the parameter table T#' at regular intervals. The regular interval can be set arbitrarily, for example, to a few seconds. The second detection unit 501 then compares the latest stored contents of the parameter table T#' with the immediately preceding stored contents.

[0090] Here, if there is a difference between the latest stored content and the immediately preceding stored content, the second detection unit 501 detects a change in the parameter table T#'. On the other hand, if there is no difference between the latest stored content and the immediately preceding stored content, the second detection unit 501 does not detect a change in the parameter table T#'.

[0091] In response to the detection of a change in the parameter table T#', the second update unit 502 updates the parameter file PF' referenced by the autonomous management system MS' in accordance with the change. Here, the autonomous management system MS' is a management unit that manages the container Cr' deployed in the disaster recovery environment E2 (see FIG. 2).

[0092] The parameter file PF' is parameter information (management parameter information) related to the management of the container Cr' deployed in the disaster recovery environment E2. For example, the parameter file PF' includes parameter information related to the management of the DB container Cr#' deployed in the disaster recovery environment E2. The parameter file PF' also includes parameter information related to the management of the application container deployed in the disaster recovery environment E2.

[0093] Specifically, for example, in response to detecting a change in the parameter table T#', the second update unit 502 acquires the changed parameter information from the parameter table T#'. Then, the second update unit 502 updates the parameter file PF' using the acquired changed parameter information.

[0094] At this time, the second update unit 502 may, for example, recursively update the parameter file PF' using both the old and new parameter values ​​until successful, in order to ensure that the changes to the parameter table T#' are reflected in the parameter file PF'.

[0095] Here, parameter file f#' in DB container Cr#' is synchronized with parameter file f# in DB container Cr# in production environment E1 by a data synchronization function (for example, streaming replication). However, there is a possibility that parameter file f#' is not synchronized with parameter file f# due to some kind of malfunction.

[0096] Therefore, if the second update unit 502 has successfully updated the parameter file PF', it may update the parameter file f#' in the DB container Cr#' in accordance with the detected change in the parameter table T#'. In this way, the second update unit 502 reliably prevents a discrepancy from occurring between the parameter file PF' referenced by the autonomous management system MS' and the parameter file f#' in the DB container Cr#'.

[0097] Furthermore, if the second update unit 502 has successfully updated the parameter file PF', it may also update a parameter file included in another container other than the DB container Cr#' among the containers Cr' deployed in the disaster recovery environment E2 in accordance with the detected change in the parameter table T#'. In this way, the second update unit 502 reflects the updated contents of the parameter file PF' in the parameter files of other containers (for example, application containers).

[0098] In addition, taking into consideration the possibility that parameter file f#' is not synchronized with parameter file f# due to some kind of malfunction, the second update unit 502 may determine whether changes with the same content as those in parameter table T#' are reflected in parameter file f#' before updating parameter file PF'.

[0099] Reflecting the same changes as those in parameter table T#' means that the same changes have been made to the same changes as those in parameter table T#'. Here, if the changes are reflected in parameter file f#', the second update unit 502 may update parameter file PF'. On the other hand, if the changes are not reflected in parameter file f#', the second update unit 502 may not update parameter file PF'.

[0100] In the production environment E1, when a change is detected in the parameter file PF referenced by the autonomous management system MS, the parameter file f# contained in the DB container Cr# is updated in accordance with the change, and the contents of the change are written to the parameter table T# in the database DB#.

[0101] The information processing device 201 may have the functional units (second detection unit 501, second update unit 502) of the information processing device 202 shown in FIG. 5. When the information processing device 201 is placed in the disaster recovery environment E2, the functional units (second detection unit 501, second update unit 502) perform processing. The information processing device 202 may have the functional units (creation unit 401 to first update unit 403) of the information processing device 201 shown in FIG. 4. When the information processing device 202 is placed in the production environment E1, the functional units (creation unit 401 to first update unit 403) perform processing.

[0102] (Example of operation of information processing system 200) Next, an example of operation of the information processing system 200 will be described. Here, it is assumed that a DB container Cr1 in the production environment E1 and a DB container Cr1' in the disaster recovery environment E2 are synchronized by streaming replication (data synchronization function). In addition, an example will be described in which the functional units of the information processing device 201 placed in the production environment E1 are realized by an "autonomous management system MS," and the functional units of the information processing device 202 placed in the disaster recovery environment E2 are realized by an "autonomous management system MS'."

[0103] 6 is an explanatory diagram showing an example of the operation of the information processing system 200. Fig. 6 shows a production environment E1 and a disaster recovery environment E2 within the information processing system 200. Assume that the parameter file PF is changed in the production environment E1 by the system administrator 600 or the autonomous management system MS.

[0104] In this case, the autonomous management system MS detects the change in the parameter file PF. In response to detecting the change in the parameter file PF, the autonomous management system MS updates the parameter file f1 contained in the DB container Cr1 in accordance with the change, and writes the details of the change to the parameter table T1 provided in the database DB1.

[0105] For example, suppose that the setting value of the parameter "param1" in the database DB1 in the parameter file PF is changed from "aaa" to "bbb." In this case, the autonomous management system MS changes the value of "param1" in the parameter file f1 contained in the DB container Cr1 from "aaa" to "bbb."

[0106] The autonomous management system MS also writes to the parameter table T1 in the database DB1 that the value of "param1" has been changed from "aaa" to "bbb." At this time, the autonomous management system MS performs the update process of the parameter file f1 and the write process to the parameter table T1 within a single transaction, as shown in FIG.

[0107] 7 is an explanatory diagram showing an example of transaction processing accompanying a change in the parameter file PF. In Fig. 7, when the autonomous management system MS detects a change in the parameter file PF, it performs, within a single transaction, a process of making changes to the parameter file f1 in accordance with the change (update process) and a process of writing the contents of the change to the parameter table T1 (write process).

[0108] At this time, if the autonomous management system MS is unable to write the changes to the parameter table T1, it does not change the parameter file f1. Also, if the autonomous management system MS is unable to change the parameter file f1, it does not write the changes to the parameter table T1.

[0109] This allows the autonomous management system MS to prevent discrepancies in the changes between the parameter file f1 and the parameter table T1.

[0110] Returning to the explanation of Figure 6, when a change is made to the parameter file PF and the parameter file f1 is updated and written to the parameter table T1, information is propagated from the production environment E1 to the disaster recovery environment E2 via streaming replication, and the DB container Cr1 in the production environment E1 and the DB container Cr1' in the disaster recovery environment E2 are synchronized.

[0111] As a result, in the disaster recovery environment E2, the autonomous management system MS' detects a change to the parameter table T1' in the database DB1' contained in the DB container Cr1'. In response to detecting the change to the parameter table T1', the autonomous management system MS' updates the parameter file PF' in accordance with the change.

[0112] For example, the autonomous management system MS' obtains changed parameter information from the parameter table T1'. Here, parameter information indicating that the value of "param1" has been changed from "aaa" to "bbb" is obtained from the parameter table T1'. Then, the autonomous management system MS' changes the value of "param1" in the parameter file PF' from "aaa" to "bbb."

[0113] Furthermore, the autonomous management system MS' may update the value of "param1" in the parameter file f1' of the DB container Cr1' to "bbb." However, if streaming replication is performed normally between the DB container Cr1 in the production environment E1 and the DB container Cr1' in the disaster recovery environment E2, the value of "param1" in the parameter file f1' will already be changed to "bbb."

[0114] This allows the autonomous management system MS' to eliminate any discrepancy between the parameter file PF' it uses and the parameter file f1' in the DB container Cr1', and to reflect changes to the parameter file PF in the production environment E1 in the parameter file PF' in the disaster recovery environment E2.

[0115] Here, an example of operation in each environment (production environment E1, disaster recovery environment E2) will be described using the sequence diagrams of Figures 8 and 9. Here, an example will be described in which the system administrator 600 changes the parameter file PF referenced by the autonomous management system MS.

[0116] 8 is a sequence diagram showing an example of operation in the production environment E1. In the sequence diagram of Fig. 8, first, the system administrator 600 changes the parameter file PF using the administrator terminal 203 (see Fig. 2) (step S801).

[0117] The autonomous management system MS detects the change in the parameter file PF (step S802). At this time, the autonomous management system MS acquires the changed parameter information from the parameter file PF. Then, the autonomous management system MS uses the changed parameter information to update the parameter file f1 of the DB container Cr1 and writes the changes to the parameter table T1 of the DB container Cr1 (step S803).

[0118] After this, information is propagated from the production environment E1 to the disaster recovery environment E2 using a data synchronization function (streaming replication), and the DB container Cr1 in the production environment E1 and the DB container Cr1' in the disaster recovery environment E2 are synchronized.

[0119] 9 is a sequence diagram showing an example of operation in the disaster recovery environment E2. In the sequence diagram of FIG. 9, the autonomous management system MS' detects a change in the parameter table T1' of the DB container Cr1' (step S901). At this time, the autonomous management system MS' obtains the changed parameter information from the parameter table T1'.

[0120] The autonomous management system MS' then updates the parameter file PF' using the changed parameter information (step S902). If the autonomous management system MS' has successfully updated the parameter file PF', it updates the parameter file f1' in the DB container Cr1' using the changed parameter information (step S903).

[0121] As a result, the system administrator 600 can automatically make the production environment E1 and the disaster recovery environment E2 have the same configuration simply by changing the parameter file PF used by the autonomous management system MS of the production environment E1. This eliminates the need for the system administrator 600 to manually change the configuration in the disaster recovery environment E2 when changing the configuration of the production environment E1, thereby reducing the costs associated with operational management and reducing human error (operational mistakes).

[0122] (Stored Contents of Parameter Table T#) Next, the stored contents of the parameter table T# will be described with reference to Fig. 10. Here, the parameter table T1 provided in the database DB1 included in the DB container Cr1 shown in Fig. 6 will be described as an example.

[0123] 10 is an explanatory diagram showing an example of the contents stored in parameter table T1. In Fig. 10, parameter table T1 has fields for parameter name, value, timestamp, update value, and update timestamp, and by setting information in each field, change history information (e.g., change history information 1000-1 to 1000-5) is stored as records.

[0124] Here, the parameter name is the name of a parameter related to the management of the container Cr deployed in the production environment E1. The parameters include, for example, configuration information of the DB container Cr1 (such as the DB container's memory and CPU) and parameters set for the database DB1 included in the DB container Cr1 (such as the DB password and DB memory). The value is the value of the parameter.

[0125] The timestamp indicates the date and time when the parameter was initially registered in the parameter table T1. For example, the parameter table T1 is created when the DB container Cr1 is deployed to the production environment E1. In this case, the timestamp is the date and time when the DB container Cr1 is deployed.

[0126] However, if a new parameter is added after the DB container Cr1 is deployed, the timestamp of the parameter may be, for example, the date and time when the new parameter was added. The update value is the value of the updated parameter. The update timestamp indicates the date and time when the parameter value was updated.

[0127] The parameter table T1 is replicated using a data synchronization function (streaming replication) and stored in the database DB1' of the DB container Cr1' deployed in the disaster recovery environment E2. As a result, the parameter names become the names of the parameters related to the management of the container Cr' deployed in the disaster recovery environment E2.

[0128] Next, an example of updating the parameter table T1 will be described with reference to FIG.

[0129] 11 is an explanatory diagram showing an example of updating the parameter table T1, in which change history information 1000-2 and 1000-4 in the parameter table T1 have been updated (the bold parts in FIG. 11).

[0130] In change history information 1000-2, an updated value of "400 MB" and an updated timestamp of "2023-06-10 00:00:00.000000" are written for the parameter named "DB container memory." This entry indicates that the value of the parameter named "DB container memory" was changed to the updated value of "400 MB" at the updated timestamp "2023-06-10 00:00:00.000000."

[0131] In change history information 1000-4, for the parameter name "DB memory", an updated value of "200 MB" and an updated timestamp of "2023-06-10 00:00:00.000000" are written. This entry indicates that the value of the parameter name "DB memory" was changed to the updated value of "200 MB" at the updated timestamp "2023-06-10 00:00:00.000000".

[0132] The write to the parameter table T1 is propagated to the parameter table T1' in the DB container Cr1' in the disaster recovery environment E2 by the data synchronization function (streaming replication). As a result, the autonomous management system MS' in the disaster recovery environment E2 detects the change to the parameter table T1'.

[0133] (Various Processing Procedures of Information Processing Device 201 in Production Environment E1) Next, various processing procedures of the information processing device 201 in the production environment E1 will be described. The various processes of the information processing device 201 are executed by, for example, the autonomous management system MS of the production environment E1.

[0134] First, the DB container deployment process procedure of the information processing device 201 in the production environment E1 will be described with reference to FIG.

[0135] 12 is a flowchart illustrating an example of a DB container deployment process performed by the information processing device 201 in the production environment E1. In the flowchart of FIG. 12, the information processing device 201 first deploys a DB container Cr# in the production environment E1 based on the parameter file PF (step S1201).

[0136] The parameter file PF is created by, for example, a system administrator and input to the information processing device 201 (initial setting).

[0137] Then, the information processing device 201 references the parameter file PF and creates a parameter table T# in the database DB# contained in the DB container Cr# deployed in the production environment E1 (step S1202), and terminates the series of processes according to this flowchart.

[0138] As a result, when the information processing device 201 deploys a DB container Cr# in the production environment E1, it can create a parameter table T# in the database DB# of the DB container Cr# to write changes to the parameter file PF.

[0139] Next, a management process procedure for the information processing device 201 in the production environment E1 will be described with reference to FIG.

[0140] 13 is a flowchart showing an example of a management processing procedure for the information processing device 201 in the production environment E1. In the flowchart of FIG. 13, first, the information processing device 201 determines whether or not a change in the parameter file PF used by the autonomous management system MS has been detected (step S1301).

[0141] Here, the information processing device 201 waits to detect a change in the parameter file PF (step S1301: No). If the information processing device 201 detects a change in the parameter file PF (step S1301: Yes), the information processing device 201 acquires the changed parameter information from the parameter file PF (step S1302).

[0142] Next, the information processing device 201 updates the parameter file f# in the DB container Cr# using the changed parameter information (step S1303), and then determines whether the updating of the parameter file f# in the DB container Cr# was successful (step S1304).

[0143] If updating of parameter file f# fails (step S1304: No), the information processing device 201 ends the series of processes according to this flowchart. On the other hand, if updating of parameter file f# is successful (step S1304: Yes), the information processing device 201 uses the changed parameter information to write the changes to parameter file PF to parameter table T# in database DB# (step S1305), and ends the series of processes according to this flowchart.

[0144] This allows the information processing device 201 to update the parameter file f# and write to the parameter table T# in response to changes to the parameter file PF. As a result, by data synchronization between the DB container Cr1 in the production environment E1 and the DB container Cr1' in the disaster recovery environment E2, the changes to the parameter file PF in the production environment E1 are propagated to the parameter file f#' and parameter table T1' in the DB container Cr1' in the disaster recovery environment E2.

[0145] In addition, the information processing device 201 can prevent discrepancies in the changes between the parameter file f1# and the parameter table T# by writing to the parameter table T# only if the update of the parameter file f# in the DB container Cr# is successful.

[0146] If updating the parameter file f# fails in step S1304, the information processing device 201 may execute error processing. In the error processing, for example, an error notification is sent to the administrator terminal 203 indicating that the parameter file f# in the DB container Cr# could not be updated in response to a change to the parameter file PF. As a result, the system administrator can take some kind of action to resolve the discrepancy between the parameter file PF in the production environment E1 and the parameter file f# in the DB container Cr#. Furthermore, if writing to the parameter table T# fails in step S1305, the information processing device 201 may also execute error processing.

[0147] (Various Processing Procedures of the Information Processing Device 202 in the Disaster Response Environment E2) Next, a description will be given of various processing procedures of the information processing device 202 in the disaster response environment E2. The various processes of the information processing device 202 are executed by, for example, the autonomous management system MS' in the disaster response environment E2.

[0148] First, the management process procedure for the information processing device 202 in the disaster recovery environment E2 will be described with reference to FIG.

[0149] 14 is a flowchart showing an example of a management processing procedure for the information processing device 202 in the disaster recovery environment E 2. In the flowchart of FIG. 14, the information processing device 202 first determines whether or not a change has been detected in the parameter table T#' in the database DB#' included in the DB container Cr#' (step S1401).

[0150] Here, the information processing device 202 waits to detect a change in the parameter table T#' (step S1401: No). If the information processing device 202 detects a change in the parameter table T#' (step S1401: Yes), it acquires the changed parameter information from the parameter table T#' (step S1402).

[0151] Next, the information processing device 202 refers to the changed parameter information and determines whether the parameter file f#' in the DB container Cr#' reflects the same changes as those in the parameter table T#' (step S1403). If the changes are reflected in the parameter file f#' (step S1403: Yes), the information processing device 202 uses the changed parameter information to update the parameter file PF' used by the autonomous management system MS' (step S1404).

[0152] The information processing device 202 then determines whether the parameter file PF' has been successfully updated (step S1405). If the parameter file PF' has been successfully updated (step S1405: Yes), the information processing device 202 updates the parameter files in other containers in the disaster recovery environment E2 using the changed parameter information (step S1406), and ends the series of processes according to this flowchart.

[0153] If the change is not reflected in parameter file f#' in step S1403 (step S1403: No), the information processing device 202 executes error processing (step S1407) and ends the series of processes according to this flowchart. In this error processing, for example, an error notification indicating that the change has not been reflected in parameter file f#' in DB container Cr#' is sent to the administrator terminal 203.

[0154] If the update of the parameter file PF' fails in step S1405 (step S1405: No), the information processing device 202 executes error processing (step S1407) and ends the series of processing steps according to this flowchart. In this error processing, for example, an error notification is sent to the administrator terminal 203 to inform the administrator that the changes have not been reflected in the parameter file PF' used by the autonomous management system MS'.

[0155] The information processing device 202 may omit the processing of step S1403. In this case, in step S1406, the information processing device 202 may update the parameter files included in each container Cr′ (including DB container Cr#′) in the disaster recovery environment E2 using the changed parameter information.

[0156] This allows the information processing device 202 to eliminate the discrepancy between the parameter file PF' used by the autonomous management system MS' and the parameter file f#' in the DB container Cr#', and reflect changes to the parameter file PF in the production environment E1 in the parameter file PF' in the disaster recovery environment E2.

[0157] The promotion process procedure for the information processing apparatus 202 in the disaster recovery environment E2 will be described with reference to FIG.

[0158] 15 is a flowchart showing an example of a process for upgrading the information processing device 202 in the disaster recovery environment E2. In the flowchart of FIG. 15, the information processing device 202 determines whether a request for upgrading the disaster recovery environment E2 has been received (step S1501). The request for upgrading the disaster recovery environment E2 is made, for example, by the system administrator executing a command requesting the upgrade on the administrator terminal 203.

[0159] Here, the information processing apparatus 202 waits for receipt of a request to promote the disaster recovery environment E2 (step S1501: No). If the information processing apparatus 202 receives a request to promote the disaster recovery environment E2 (step S1501: Yes), the information processing apparatus 202 kicks off promotion processing for DB container Cr#' (step S1502).

[0160] Then, the information processing apparatus 202 synchronizes the unsynchronized parameter information in the parameter table T#' with the parameter files in each container Cr' (step S1503), and ends the series of processes according to this flowchart.

[0161] As a result, the information processing device 202 can switch the DB container Cr' from the standby system to the production system in response to a promotion request from a system administrator, etc. Furthermore, by synchronizing unsynchronized parameter information, the information processing device 202 can eliminate discrepancies between the parameter file PF' and the parameter files in each container Cr' even if a situation occurs in which the management process as shown in Fig. 14 does not complete normally due to some kind of malfunction caused by the occurrence of a disaster, for example.

[0162] (Example) Next, a description will be given of an example of the information processing system 200. First, an example of container deployment in each environment (production environment E1, disaster recovery environment E2) will be described.

[0163] Fig. 16 is an explanatory diagram showing an example of container deployment in each environment. In Fig. 16, DB container Cr1, application container Cr2, and application container Cr3 are deployed in production environment E1. DB container Cr1 includes database DB1 and parameter file f1. Database DB1 has parameter table T1. DB container Cr1 is controlled based on parameter file f1.

[0164] The application container Cr2 includes a parameter file f2 and is controlled based on the parameter file f2. The application container Cr3 includes a parameter file f3 and is controlled based on the parameter file f3.

[0165] The production environment E1 also includes an autonomous management system MS, which manages the DB container Cr1, application container Cr2, and application container Cr3 by referencing the parameter file PF.

[0166] Disaster recovery environment E2 is deployed with DB container Cr1', application container Cr2', and application container Cr3'. DB container Cr1' corresponds to DB container Cr1 in production environment E1. Application container Cr2' corresponds to application container Cr2 in production environment E1. Application container Cr3' corresponds to application container Cr3 in production environment E1.

[0167] Furthermore, an autonomous management system MS' is placed in the disaster recovery environment E2. The autonomous management system MS' manages a DB container Cr1', an application container Cr2', and an application container Cr3' by referencing a parameter file PF'.

[0168] Here, a specific example of the parameter file PF will be described with reference to FIG.

[0169] 17 is an explanatory diagram showing a specific example of the parameter file PF. In Fig. 17, the parameter file PF is information related to the management of the DB container Cr1, application container Cr2, and application container Cr3, which is referenced by the autonomous management system MS.

[0170] The parameter file PF includes configuration information of DB containers and parameter settings of the databases included in the DB containers (e.g., parameter information 1701). The parameter file PF also includes configuration information of application containers (e.g., parameter information 1702).

[0171] When constructing the production environment E1, the autonomous management system MS deploys each container Cr (DB container Cr1, application container Cr2, application container Cr3) based on, for example, a parameter file PF. The parameter files (parameter files f1 to f3) included in each container Cr are created based on the parameter file PF.

[0172] For example, parameter file f1 includes the same parameter values ​​as parameter information 1701. Parameter files f2 and f3 include the same parameter values ​​as parameter information 1702. However, parameter file f1 may include the same parameter values ​​as parameter information 1702. Parameter files f2 and f3 may include the same parameter values ​​as parameter information 1701.

[0173] The parameter file PF' in the disaster recovery environment E2 corresponds to the parameter file PF in the production environment E1.

[0174] When constructing the disaster recovery environment E2, the autonomous management system MS' deploys each container Cr' (DB container Cr1', application container Cr2', application container Cr3') based on, for example, a parameter file PF'. The parameter files (parameter files f1', f2', f3') included in each container Cr' are created based on the parameter file PF'.

[0175] Furthermore, the DB container Cr1 in the production environment E1 and the DB container Cr1' in the disaster recovery environment E2 are synchronized in real time by streaming replication.

[0176] Here, it is assumed that in the production environment E1, the administrator terminal 203 (system administrator) has changed the parameter file PF used by the autonomous management system MS.

[0177] In this case, the autonomous management system MS detects the change in the parameter file PF and acquires the changed parameter information from the parameter file PF. Then, the autonomous management system MS uses the changed parameter information to update the parameter files (parameter files f1 to f3) of each container Cr (DB container Cr1, application container Cr2, application container Cr3), and writes the changes to the parameter table T1 of the DB container Cr1.

[0178] This allows the autonomous management system MS to eliminate discrepancies between the parameter file PF and the parameter files in each container Cr when the parameter file PF used by the autonomous management system MS is changed in the production environment E1.

[0179] When the parameter file f1 of the DB container Cr1 is updated and the changes are written to the parameter table T1 of the DB container Cr1, the parameter table T1' of the DB container Cr1' in the disaster recovery environment E2 is synchronized with the parameter table T1 through streaming replication.

[0180] The autonomous management system MS' periodically checks the parameter table T1' in the DB container Cr1' and detects any changes to the parameter table T1'. The autonomous management system MS' obtains the changed parameter information from the parameter file PF'. The autonomous management system MS' then updates the parameter file PF' using the changed parameter information.

[0181] If the autonomous management system MS' successfully updates the parameter file PF', it uses the changed parameter information to update the parameter files (parameter files f1' to f3') contained in each container Cr' (DB container Cr1', application container Cr2', application container Cr3').

[0182] This allows the information processing device 202 to reflect changes to the parameter file PF in the production environment E1 in the parameter file PF' in the disaster recovery environment E2, and eliminates discrepancies between the parameter file PF' of the autonomous management system MS' and the parameter files in each container Cr'.

[0183] As described above, the information processing device 201 according to the embodiment can detect changes to the parameter file PF referenced by the autonomous management system MS in the production environment E1. The autonomous management system MS is a management unit that manages containers Cr deployed in the production environment E1. The parameter file PF is information related to the management of DB containers Cr# (management parameter information), and includes, for example, configuration information for the DB containers Cr# and parameter values ​​set in the databases DB# included in the DB containers Cr#. Furthermore, the information processing device 201 can update the parameter file f# included in the DB containers Cr# in accordance with the changes and write the contents of the changes to a parameter table T# provided in the database DB# in response to detecting a change to the parameter file PF.

[0184] As a result, when the parameter file PF in the production environment E1 is changed, the information processing device 201 can update the parameter file f# of the DB container Cr# in accordance with the change and write the changes to the parameter table T#. Therefore, even if the parameter file PF is changed, the information processing device 201 can eliminate discrepancies between the parameter file PF and the parameter file f# of the DB container Cr#. Furthermore, the information processing device 201 can propagate changes to the parameter file PF to the disaster recovery environment E2 by utilizing data synchronization between the production environment E1 and the disaster recovery environment E2.

[0185] Furthermore, the information processing device 202 can detect changes to the parameter table T#' in the database DB#' contained in the DB container Cr#' in the disaster recovery environment E2. The DB container Cr#' is a container that is deployed in the disaster recovery environment E2 and is synchronized with the DB container Cr# in the production environment E1 using a data synchronization function. The data synchronization function is, for example, streaming replication. Furthermore, the information processing device 202 can update the parameter file PF' referenced by the autonomous management system MS' in response to detecting a change to the parameter table T#'. The autonomous management system MS' is a management unit that manages the container Cr' deployed in the disaster recovery environment E2.

[0186] This allows the information processing device 202 to eliminate the discrepancy between the parameter file PF' used by the autonomous management system MS' and the parameter file f#' in the DB container Cr#', and reflect changes to the parameter file PF in the production environment E1 in the parameter file PF' in the disaster recovery environment E2.

[0187] Furthermore, according to the information processing device 201, in the production environment E1, when writing the contents of a detected change in the parameter file PF to the parameter table T#, if updating the parameter file f# in accordance with the change fails, it is possible to prevent the contents of the change from being written to the parameter table T#.

[0188] This allows the information processing device 201 to reliably prevent discrepancies from occurring between the parameter file PF referenced by the autonomous management system MS and the parameter file f# of the DB container Cr#.

[0189] Furthermore, according to the information processing device 202, if the parameter file PF' is successfully updated in the disaster recovery environment E2, the parameter file f#' in the DB container Cr#' can be updated in accordance with the detected changes to the parameter table T#'.

[0190] This allows the information processing device 202 to reliably prevent discrepancies from occurring between the parameter file PF' referenced by the autonomous management system MS' and the parameter file f#' in the DB container Cr#'.

[0191] Furthermore, according to the information processing device 201, in response to detecting a change in the parameter file PF in the production environment E1, it is possible to further update, in response to the change, parameter files included in another container other than the DB container Cr# among the containers Cr deployed in the production environment E1. The other container is, for example, an application container that does not include a database.

[0192] This allows the information processing apparatus 201 to reflect the changes made to the parameter file PF in the parameter files of other containers in the production environment E1.

[0193] Furthermore, according to the information processing device 202, if the parameter file PF' is successfully updated in the disaster recovery environment E2, the parameter files contained in other containers Cr' deployed in the disaster recovery environment E2 that are different from the DB container Cr#' can be updated in accordance with the detected changes to the parameter table T#'.

[0194] This allows the information processing device 202 to reflect the updated contents of the parameter file PF' in the parameter files of other containers in the disaster recovery environment E2.

[0195] For these reasons, information processing devices 201 and 202 can appropriately manage parameter information (parameter file PF, parameter file f#, parameter file PF', parameter file f#') related to the management of containers (DB containers Cr#, Cr#') containing databases (databases DB#, DB#') in the redundant production environment E1 and disaster recovery environment E2.

[0196] Furthermore, with the information processing devices 201 and 202, when changing the configuration of the production environment E1, the system administrator does not need to manually change the configuration of the disaster recovery environment E2, thereby reducing operational management costs and human error (operational mistakes). For example, by utilizing a streaming replication function that enables real-time synchronization, the system administrator can complete setup simply by deploying a DB container, without having to deploy a separate module dedicated to parameter synchronization.

[0197] Furthermore, by utilizing the streaming replication function, when parameter information in the production environment E1 is changed, the changed parameter information is automatically transmitted to the disaster recovery environment E2. Therefore, even if the production environment E1 goes down, the operational environment can be reproduced based on the parameter information contained in the disaster recovery environment E2.

[0198] In addition, according to the information processing devices 201 and 202, when switching from the production environment E1 to the disaster recovery environment E2 in the event of a disaster, it is possible to avoid a situation in which the autonomous management system MS' is unable to connect to the database DB#' in the DB container Cr#' and is therefore unable to perform operational management due to authentication information such as the password for the database DB# not being transmitted.

[0199] In the above description, a system (for example, a business system) is realized using containers (containers Cr and Cr') that include applications and databases, but this is not limiting. For example, a system may be realized using virtual machines that include applications and databases.

[0200] The management method described in this embodiment can be realized by executing a prepared program on a computer such as a personal computer or a workstation. This management program is recorded on a computer-readable recording medium such as a hard disk, flexible disk, CD-ROM, DVD, or USB memory, and is executed by being read from the recording medium by the computer. This management program may also be distributed via a network such as the Internet.

[0201] The information processing devices 201 and 202 described in this embodiment can also be realized by application-specific ICs such as standard cells or structured ASICs (Application Specific Integrated Circuits), or PLDs (Programmable Logic Devices) such as FPGAs.

[0202] 101 Management device 101-1 First management device 101-2 Second management device 110 First environment 111, 121 Management unit 112, 122 Management parameter information 113 First container 114, 124 Database 115, 125 Control parameter information 116, 126 Change history information 120 Second environment 123 Second container 200 Information processing system 201, 202 Information processing device 203 Administrator terminal 210 Network 300 Bus 301 CPU 302 Memory 303 Disk drive 304 Disk 305 Communication I / F 306 Portable recording medium I / F 307 Portable recording medium 400, 500 Control unit 401 Creation unit 402 First detection unit 403 First update unit 501 Second detection unit 502 Second update unit 600 System administrator 1701, 1702 Parameter information

Claims

1. A management device comprising: a control unit that executes the following processes: in the first environment, detects a change in management parameter information relating to management of a first container including a database, which is referenced by a management unit that manages containers deployed in the first environment; and in response to detecting the change, updates control parameter information relating to control of the first container, which is contained in the first container and referenced by the first container, in accordance with the change, and writes the content of the change to change history information provided in the database; and in the second environment, detects a change in change history information in a database contained in a second container that is deployed in the second environment and synchronized with the first container by a data synchronization function; and in response to detecting the change, updates management parameter information relating to management of the second container, which is referenced by a management unit that manages containers deployed in the second environment, in accordance with the change.

2. The control unit of the management device described in claim 1, characterized in that, in the first environment, when writing the content of the detected change to the change history information, if updating the control parameter information in accordance with the change fails, the control unit does not write the content of the change to the change history information.

3. The management device described in claim 1, characterized in that when the control unit successfully updates the management parameter information related to the management of the second container in the second environment, the control parameter information related to the control of the second container, which is contained in the second container and referenced by the second container, is updated in accordance with the detected change in the change history information.

4. The management device described in claim 3, characterized in that the control unit, in the first environment, in response to detecting a change in the management parameter information, further updates control parameter information related to the control of another container that is included in a container different from the first container among the containers deployed in the first environment and referenced by the other container in response to the change, and in the second environment, if the updating of the management parameter information is successful, updates control parameter information related to the control of the other container that is included in a container different from the second container among the containers deployed in the second environment and referenced by the other container in response to the detected change in the change history information.

5. The management device described in claim 1, characterized in that the management parameter information related to the management of the first container includes configuration information of the first container and parameter values ​​set in a database contained in the first container.

6. The management device according to claim 1, wherein the data synchronization function is streaming replication.

7. The management device according to claim 1, characterized in that the first environment is a production environment, and the second environment is a disaster recovery environment.

8. A management method comprising: in a first environment and a second environment that are redundant, a computer executes a process of: detecting, in the first environment, a change in management parameter information related to management of a first container including a database, which is referenced by a management unit that manages a container deployed in the first environment; and, in response to detecting the change, updating control parameter information related to control of the first container, which is included in the first container and referenced by the first container, in response to the change, and writing the content of the change to change history information provided in the database; and, in the second environment, in response to detecting a change in change history information in a database included in a second container that is deployed in the second environment and synchronized with the first container by a data synchronization function, updating management parameter information related to management of the second container, which is referenced by the management unit that manages the container deployed in the second environment, in response to the change.

9. A management method characterized by being executed by a computer to perform the following processes: in a first environment and a second environment that are redundant, in the first environment, in response to detection of a change in management parameter information related to management of a first container including a database referenced by a management unit that manages containers deployed in the first environment, control parameter information related to control of the first container that is included in the first container and referenced by the first container is updated in response to the change, and the content of the change is written to change history information provided in the database; and in the second environment, in response to detection of the change, updating management parameter information related to management of the second container that is referenced by a management unit that manages containers deployed in the second environment in response to the change.

10. A management program comprising: a first environment and a second environment that are redundant; in the first environment, the program detects a change in management parameter information related to management of a first container including a database, which is referenced by a management unit that manages a container deployed in the first environment; and in response to the detection of the change, updates control parameter information related to control of the first container, which is included in the first container and referenced by the first container, in accordance with the change, and writes the content of the change in change history information provided in the database; and in the second environment, the program causes management parameter information related to management of the second container, which is referenced by the management unit that manages the container deployed in the second environment, to be updated in accordance with the change in response to the detection of a change in change history information in a database included in a second container that is deployed in the second environment and synchronized with the first container by a data synchronization function.

11. A management program characterized by causing a computer to execute processes of: in a first environment and a second environment that are redundant, in the first environment, in response to detection of a change in management parameter information related to management of a first container including a database referenced by a management unit that manages containers deployed in the first environment, control parameter information related to control of the first container that is included in the first container and referenced by the first container is updated in response to the change, and the content of the change is written to change history information provided in the database; and in the second environment, detecting a change in change history information in a database included in a second container that is deployed in the second environment and synchronized with the first container by a data synchronization function, and in response to detection of the change, updating management parameter information related to management of the second container that is referenced by a management unit that manages containers deployed in the second environment in response to the change.

Images