JP2005250909A - Matching property keeping system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system enabling an operation manager in a distributed system to perform a changing operation considering matching property of the system without referring to relevant information such as a system specification or a product manual. <P>SOLUTION: A specified server writes, prior to changing a parameter under itself, change information for the parameter to a change request list, and transmits, when the influence by the change of the parameter under itself reaches a parameter under the other server, the change request list to the other server. The other server transmits, when the influence does not reach a parameter under another server and satisfies a predetermined condition, the change request list to a management console. The management console transmits, when approval of the change request list is inputted, the change request list after approval to successively transfer it to each server, and the specified server executes the change of the parameter under itself according to the change request list. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a technique for automatically performing a change operation in any server and a change operation in another server that occurs in association with the change operation in a system including a plurality of servers.

  With the spread of Internet technology, the interoperability of systems has increased, and there are increasing cases in which a plurality of systems that have been independently constructed in the past cooperate to provide functions to users. In such a system, since a plurality of middleware products provided by various vendors are combined, there are many setting parameters for individual middleware to be designed.

  In such a system, when a change work is planned, it is necessary to conduct an impact investigation with a product manual and expert assistance based on the system design document, and to make a change plan with much effort.

  In addition, in the operation phase where the designer is absent or outsourced operation, the change work is limited to the scope of operation procedure manuals and routine scripts that have been prepared in advance. There were cases where it was difficult to carry out routine change work, or a change work error caused trouble due to the difference between the design document and the actual system.

As a method of solving such a problem, there is a method of obtaining a related design object affected by a changed design object and deriving and displaying the influence content (see, for example, Patent Document 1).
JP-A-7-141405

  However, the conventional technology represented by the above-mentioned Patent Document 1 is effective in one apparatus, but in a distributed system in which a plurality of systems are linked, the affected design area cannot be specified, and thus the affected related design object is specified. Can not do it.

  In light of these problems, in the present invention, in a distributed system, an operation administrator can perform a change operation taking into consideration the consistency of the system without referring to related information such as a system design document and a product manual. The purpose is to provide such a mechanism.

The present invention has been made to solve the above-described problem, and is a consistency maintenance system including a plurality of servers and a management console, before a specific server changes its own parameters. Means for writing change information relating to the parameter to the change request list, means for examining whether or not the influence of the change of the parameters under its control affects the parameters under the other servers, and the influence is under the control of other servers. Means for writing change information relating to the parameter to the change request list, and transmitting the change request list after the writing to the other server. The change request list from other servers is affected by the change in the parameters under its own means and the parameters under its own server. If the influence affects parameters under other servers, the change information regarding the parameters is written in the change request list, and the change request list after the writing is stored in the other server. And means for transmitting the change request list to the management console when the influence does not reach parameters under other servers and the conditions for transmitting the change request list to the management console are satisfied. The management console prompts the user to input means for receiving a change request list from the other server and whether to approve change information written in the change request list. And the approval of the change information written in the change request list, the change request list after the approval is sent to each server. Means for transmitting the data to be sequentially transferred to the specific server and the other server, the means for receiving the change request list from the management console, and the subordinates written in the change request list. And a means for executing a change of the parameters under its control according to the change information regarding the parameters.

  According to the present invention, when the influence of the change of the parameters under its own influences the parameters under the other servers, the change information regarding the parameters is written in the change request list, and the change request list after the writing is changed to other parameters. Similarly, when other servers affect the parameters under other servers as well, the change information related to those parameters is written to the change request list. Change request lists are sent to other servers. Thereafter, the same processing is performed. Each server automatically executes the change of the parameters under its control in accordance with the change information regarding the parameters under its control written in the change request list.

  Therefore, the operation manager can perform a change operation taking into consideration the consistency of the system without referring to related information such as a system design document and a product manual.

  In the above consistency maintenance system, for example, the change information regarding the parameter includes parameter designation information for specifying the parameter, a value before the change of the parameter, a value to be changed of the parameter, and a change of the parameter from before the change. The operation specifying information for specifying the operation to be executed to change to the scheduled value is included.

  This is an example of change information regarding a parameter. Therefore, other change information may be used.

  In the consistency maintenance system, for example, the management console further includes means for prompting the user to select another change request list to be combined with the change request list from the other server, and the other change request. And means for combining the change information written in the other change request list with the change information written in the change request list from the other server when the list is selected.

  In this way, by combining a plurality of change operations according to the degree of influence, it is possible to reduce duplicate work at the time of change and optimize the change work.

  Moreover, this invention can be specified as follows as invention of a method.

Before changing a parameter under its own control, the step of writing change information about the parameter to the change request list and checking whether the influence of the change of the parameter under its own affects the parameters under other servers And when the influence affects a parameter under another server, the change information regarding the parameter is written in the change request list, and the change request list after the writing is transmitted to another server; The step of receiving the change request list from the server and whether or not the influence of the change of the parameter under its own affects the parameter under the other server when the change request list from the other server is received. The step of checking, and if the effect affects a parameter under another server, the change information regarding the parameter , Writing to the change request list, and sending the change request list after writing to another server, and sending the change request list to the management console when the influence does not affect parameters under other servers. When the condition for performing is satisfied, a step of transmitting the change request list to the management console, a step of receiving the change request list from the management console, and a parameter under its own written in the change request list Executing a change of parameters under its control according to the change information.

  A step of receiving a change request list from a predetermined server, a step of prompting the user to input whether or not to approve change information written in the change request list, and a change written in the change request list And a step of transmitting the change request list after the approval for sequential transfer to each of the servers when the information is approved.

  Further, the present invention can be specified as the invention of a program as follows.

  Before changing the parameters under its own server, the means for writing the change information about the parameter to the change request list and whether the influence of the change of the parameters under its own affects the parameters under other servers And means for writing change information relating to the parameter to the change request list and transmitting the changed request list to the other server when the influence affects a parameter under another server. When receiving a change request list from another server and a change request list from another server, whether or not the influence of the change of the parameters under its own affects the parameters under the other server If the effect affects a parameter under another server, change information related to the parameter is changed to the change. Means for writing to the request list, and sending the change request list after this writing to another server, and for sending the change request list to the management console, where the influence does not affect parameters under other servers When the condition is satisfied, the change request list is transmitted to the management console, the change request list is received from the management console, and the change information regarding the parameters under its control written in the change request list A program for functioning as a means for executing changes of parameters under its control.

  Means for receiving a change request list from a predetermined server, means for prompting a user to approve whether or not to approve change information written in the change request list, and A program for functioning as means for transmitting, in order to sequentially transfer the change request list after the approval to each of the servers, when the approval of the written change information is input.

  The present invention can be specified as the invention of the server as follows.

Before changing the parameters under its own control, check whether the change information related to the parameter is written to the change request list and whether the effect of the change of the parameter under its own affects the parameters under other servers. And means for writing the change information regarding the parameter to the change request list, and transmitting the change request list after the writing to the other server when the influence affects the parameters under the other server. When receiving a change request list from a server and a change request list from another server, whether or not the influence of the change of the parameters under its own affects the parameters under the other server. Means for checking, and when the influence affects a parameter under another server, change information related to the parameter is sent to the change request list. And a means for transmitting the change request list after the writing to another server, and a condition for the influence not to affect the parameters under the other server and for transmitting the change request list to the management console. If satisfied, the change request list is transmitted to the management console, the change request list is received from the management console, and the change information about the parameters under its control written in the change request list And a means for executing a parameter change under control of the server.

  The present invention can be specified as the invention of the management console as follows.

  Means for receiving a change request list from the server; means for prompting a user to enter whether or not to approve change information written in the change request list; and a change written in the change request list A management console comprising: means for transmitting the change request list after the approval in order to sequentially transfer the information to the respective servers when approval of the information is input;

  Moreover, in order to solve the said subject, the following means are taken.

  Change operations performed on each server are automatically detected, and an impact investigation is always performed on the entire system before actual settings are changed. The impact of changes is assessed by evaluating the impact of related subsystems based on the dependency DB and implementation parameter DB of each server that makes up the system, and the information is distributed in an autonomous and distributed manner. By doing so, it is implemented without using the system design document. In the course of investigating the impact of changes, a change procedure taking into account system consistency is automatically generated based on the change operation (execution command) of each parameter. The generated change procedure is aggregated in the operation management console as a change request, and optimization of system operation (reduction of change number and reduction of downtime) is realized by combining a plurality of change operations.

According to the present invention, it is possible for an operation manager to perform a change operation taking into consideration the consistency of the system without referring to related information such as a system design document and a product manual. In addition, by incorporating in advance the design content that was previously described in the design document as a dependency rule in the implementation system, the change operation of the other part of the system that occurs with one change operation is automatically generated, It becomes possible to realize a consistent change operation in the entire system.

  Further, by combining a plurality of change operations according to the degree of influence, it is possible to reduce duplicate work at the time of change and optimize the change work. In addition, by forcing a change operation based on approval systematically, it is possible to suppress an inadvertent trouble caused by an operation error or a security breach. Furthermore, in addition to the information in the design document and product manual, record the impact (execution time, load, problems at the time of change) when the operation is performed, and use it as a judgment material for the next operation. Is possible. In addition, when there is a system-specific problem in the operation procedure, the operation can be continuously improved by updating it as special dependency information.

Hereinafter, a consistency maintenance system according to an embodiment of the present invention will be described with reference to the drawings.
(Schematic configuration of consistency maintenance system)
FIG. 1 is a diagram for explaining a schematic configuration of the consistency maintenance system of the present embodiment.

  The system of this embodiment includes a plurality of servers (in FIG. 1, WEB server, F / W server, AP server, and DB server are illustrated) and a management console.

Each is connected to a network such as a LAN (Local Area Network) and has a function of performing data communication with each other via the network.
(Schematic configuration of each server)
Each server functions as a server when an information processing apparatus such as a workstation executes a server program installed in a storage device such as a hard disk device connected (internally or externally) thereto. As shown in FIG. 2, in each server, a change detection program, a change impact investigation program, a change program, and the like are installed in the storage device. As shown in FIG. 3, in each server, a change program management table, an implementation parameter database, a dependency database, and the like are stored in the storage device.
(Schematic configuration of the management console)
The management console functions as a management console when an information processing device such as a workstation executes a predetermined program installed in a storage device such as a hard disk device connected (internally or externally) thereto. As shown in FIG. 2, a change approval program or the like is installed in the storage device of the management console. As shown in FIG. 3, the management console stores a business management table, a change operation management table, and the like in its storage device.

  The management console also includes input devices such as a keyboard and a mouse, and image display devices such as a liquid crystal display and a CRT display.

FIG. 4A, FIG. 4B, and FIG. 5 illustrate actual data of each database. FIG. 6 shows each database more simply.
(Change request list overview)
The change request list includes items such as user information, a change parameter area, a forwarding route management area, an operation area before change, and an operation area after change (see the bottom right part of FIGS. 16A and 16B).

  The user information is information that is referred to when determining whether to approve a change presented by the change request list, such as a command input date and time, an urgency level, and a change reason.

The change parameter area is information related to a location that is changed by a command input in the target server, such as an operation ID, an implementation URI, before the change, after the change, and an operation. For example, 001, / w3sv / F3FMwww / environment definition 1 / parameter 2, “80”, “8080”, unprocessed are written.

The forwarding route management area is information related to a server through which the change request list passes, such as a revision number (number of relay servers) and a relay server name. For example, revision number: 2, w3sv (2
) ⇒ written as fwsv. 17A and 17B are examples of the change request list held by the server (w3sv). In this example, the server that receives the change request list is itself (w3sv) and the next server (fwsv). This indicates that the revision number is 2, and that the change request list is sent from the server (w3sv) to the server (fwsv).

  The pre-change operation area is information for specifying an operation to be executed before the change. For example, as shown in the bottom right part of FIG. 17B, data is written as F3FMwww001. This identifies ippstopsv.exe as the operation to be performed before the change.

The post-change operation area is information for specifying an operation to be executed after the change. For example, as shown in the lowermost right part of FIG. 17B, data is written as F3FMwww002. This specifies ippstartsv.exe as the operation to be performed after the change.
(Outline of operation of consistency maintenance system)
Next, an outline of the operation of the consistency maintenance system configured as described above will be described with reference to FIG.

As shown in FIG. 1, the operation of the system is as follows: a. Change detection, b. Investigation / propagation, c. Analysis / approval, d. There are roughly four types of change execution.
(A. Outline of change detection)
Assume that the user changes a parameter under the server (for example, a parameter included in a definition file under the AP server) in any of the servers (exemplifies the AP server in FIG. 1). In this case, in the server, parameter designation information such as a URI for designating the changed parameter, a value before the change of the parameter (for example, port number 80), a value to be changed of the parameter (for example, port number 8080), etc. Create a change request list that has been detected and written.
(B. Survey / Propagation Overview)
In any server (example of AP server in FIG. 1), before changing a parameter (for example, port number) under the server, whether or not the influence of the change of the parameter affects the parameters under the other server. Check (refer to self dependency DB).

  If the effect affects parameters under other servers (for example, parameters included in the definition file under the FW server), change information related to the parameters (for example, a URI specifying a parameter included in the definition file under the FW server) The parameter designation information, the value before the change of the parameter, the value to be changed of the parameter, etc. are written (added and written) to the change request list.

  Then, the change request list after writing is transmitted to another server (for example, FW server) affected by the change.

  In another server (for example, FW server), the change request list transmitted earlier is received, and parameters under its own (for example, parameters specified by parameter specifying information such as URI written in the change request list) It is checked whether or not the influence of the change affects parameters under other servers (refer to its own dependency DB).

  If the effect affects parameters under other servers (for example, parameters included in definition files under the Web server), change information related to the parameters (for example, parameters such as URIs that specify parameters included in definition files under the Web server) The designation information, the value before the change of the parameter, the value to be changed of the parameter, etc.) are written (added and written) to the change request list received earlier. Then, the change request list after writing is transmitted to another server (for example, a Web server) affected by the change.

  Other servers (for example, Web servers) receive the change request list sent earlier, as described above, and are specified by parameter specification information such as a URI (for example, a URI written in the change request list) under its own control. (Refer to its own dependency DB) to determine whether or not the influence of the change in the parameters) affects the parameters under other servers.

When the influence does not reach the parameters under other servers and the conditions for transmitting the change request list to the management console are satisfied, the change request list is transmitted to the management console. If the effect affects parameters under other servers, the change information related to the parameters is written (added and written) to the change request list received earlier, and the change request list after this writing is It will be sent to other servers that are affected.
(C. Summary of analysis / approval)
The management console receives a change request list from another server (example of the Web server in FIG. 1) and displays the change information written in the change request list on an image display device such as a liquid crystal display. The user is prompted to input whether or not to approve the change information.

When it is input to approve the change information, the change request list after approval is transmitted to sequentially transfer each server (AP server, F / W server, and Web server in FIG. 1 as an example). .
(D. Change execution)
Each server (AP server, F / W server, and Web server in FIG. 1 exemplarily shows a change request list received from the management console, and change information related to its own parameters written in the change request list. To change the parameters under its control.

  Next, an outline of the operation of this system will be described with reference to FIGS. 7A and 7B.

In FIG. 7A and FIG. 7B, for simplicity of explanation, unlike FIG.
And fw-sv.

7A and 7B, a. The change detection corresponds to execution of a change command (S100), detection of a change command (S101), and creation of a change request list (S102). 7A and 7B, b. Corresponding to investigation / propagation is change impact investigation 1 (S103), change impact investigation 2 (S104), and change request list forwarding (S104). Hereinafter, these processes will be described. Hereinafter, these processes will be described.
(Change command execution (S100))
It is assumed that the target server (w3-sv) has executed correction (or execution of a setting change command) of parameters included in its own definition file. For example, it is assumed that the person in charge of operation modifies the reception port number included in the definition file under his / her own in the Web server from 80 to 8080 and executes the Web server restart command.
(Change command detection (S101))
When the target server (w3-sv) detects that the correction in S100 is a change to the system, the target server (w3-sv) interrupts the execution, specifies the scheduled change parameter, and generates a change request list. For example, the change detection program of the target server detects a Web server restart command, and specifies that the scheduled change parameter is a port number from the update contents of the definition file.
(Creation of change request list (S102))
The target server (w3-sv) generates a change request list for the port number (scheduled change parameter) specified in S101.
(Investigation of change impact 1 (S103))
The target server (w3-sv) refers to the implementation parameter DB, checks whether there is a reference destination, and performs processing according to the update rule. For example, since there is no reference destination for the port number (scheduled change parameter), a port number change command is generated (written) in the change operation area in the change request list, and the change operation completion flag is set.
(Investigation of change impact 2 (S104))
The target server (w3-sv) refers to the dependency DB, extracts the reference source parameter of the scheduled change parameter, and processes it according to the dependency rule. For example, since the port number (scheduled change parameter) is referred to by the F / W filtering port number, the F / W filtering port number is added to the change scheduled parameter in the change request list, and the forwarding in the list is performed. An F / W server is added to the route, and the revision number is counted up.
(Forwarding change request list (S105))
The target server (w3-sv) writes the revision that has been processed, the next forward route,
Send the change request list to the approval console. For example, the current revision is written in the forwarding route management area of the current server, and the change request list is sent to the console and the next forwarding destination.

At the next forwarding destination (exemplified fw-sv in FIGS. 7A and 7B), b. The same processing as in the investigation / propagation is executed. Hereinafter, these processes will be described.
(Change impact investigation 1 (the same processing as S103))
When the target server (fw-sv) receives the change request list from the target server (w3-sv), the target server (fw-sv) refers to the implementation parameter DB, checks whether there is a reference destination, and processes it according to the update rule. For example, since there is no reference destination for the filter port (scheduled change parameter), a port number change command is generated (written) in the change operation area in the change request list, and the change operation completion flag is set.
(Change impact survey 2 (same processing as S104))
The target server (fw-sv) refers to the dependency DB, extracts the reference source parameter of the parameter to be changed, and processes it according to the dependency rule. For example, since there is no reference parameter, the forwarding route is not changed and the revision is not updated.
(Forwarding change request list (same processing as S105))
The target server (fw-sv) writes the revision that has been processed, and sends the change request list to the next forward route and the approval console. For example, the current revision is written in the forward route management area of the current server, and if all revision numbers are the same, an approval request is sent to the console.
(Approval request (S106))
The target server (fw-sv) writes the processed revision to the change request list, and transmits this change request list to the next forwarding route or management console.

Thereafter, c. Analysis / approval, d. Change execution is executed.
(Details of operation of consistency maintenance system)
Next, operation details of the consistency maintaining system configured as described above will be described with reference to FIGS.
(A. Change detection details)
FIG. 8 is a diagram for explaining change detection in, for example, w3-sv among the two servers (w3-sv and fw-sv) exemplified as a plurality of servers in FIGS. 7A and 7B.

As shown in FIG. 8, when a command is input in the target server (here, w3-sv) (S110), the target program (executed by the command) is analyzed (S112). As a result of the analysis, if the target program is not a change / start program (S112: No), the subsequent process is terminated and the input command is executed (S113).

  On the other hand, if the target program is a change / start program (S112: Yes), it is further determined whether or not it is a change program (S114).

  If the result of the determination is that the program is not a change program (S114: No), the definition file is checked for change (S115). If the definition file is not changed as a result of the check (S116: No), the subsequent processing is terminated and the input command is executed (S113).

  On the other hand, if the definition file is to be changed (S116: Yes), the parameter to be changed is specified and the input command is executed (S117). Similarly, when the determination result in S114 is a change program (S114: Yes), the change-scheduled parameter is specified and the input command is executed (S117).

Next, a command suspension notification is performed via an image display device connected to the server (here, w3-sv) (S118). In response to this notification, when the system administrator inputs an input of the change contents from an input device connected to the server (here, w3-sv), a change list is generated, and the change scheduled parameter specified in S117 is displayed. The message is transmitted to another server (fw-sv in this case) affected by the change (S119).
(B. Survey / Propagation details)
FIG. 9 is a diagram for explaining the investigation / propagation in fw-sv, for example, among the two servers (w3-sv and fw-sv) exemplified as a plurality of servers in FIGS. 7A and 7B.

As shown in FIG. 9, the target server (here, fw-sv) receives the change request list transmitted from S108 in S108, and changes the processing target from this change request list. One schedule parameter is specified (S120).

  Next, the presence / absence of a reference destination is checked by referring to the mounting parameter DB (S121). As illustrated in FIG. 3, the mounting parameter DB includes a correspondence relationship between parameters and reference destinations. Therefore, the presence / absence of a reference destination can be checked by referring to the mounting parameter DB.

  If there is no reference destination as a result of the check (S122: No), a change command is generated, and the change command and completion flag are added to the change request list (S123). As illustrated in FIG. 3, the mounting parameter DB includes a correspondence relationship between parameters and change commands (pre-change operation ID and post-change operation ID). Therefore, it is possible to generate (read out) a change command by referring to the mounting parameter DB.

  Next, the presence / absence of the reference source is checked by referring to the dependency DB (S124). The dependency relationship DB includes a correspondence relationship between the original mounting parameter (referenced side) and the dependent mounting parameter (referenced side). Therefore, the presence / absence of a reference source (referring side) can be checked by referring to the dependency DB.

  As a result of the check, if there is a reference source (S125: Yes), the reference source parameter is added as a change schedule to the change parameter area in the change request list (S126). Next, the reference source is added to the forwarding route management area in the change request list (S127), and the revision number is further counted up (S128).

If the next parameter of the local server (here, fw-sv) is selected in the change request list (S129: Yes), the processing from S121 onward is repeated in the same manner as described above. On the other hand, if all the parameters of the own server have been selected and there is no parameter to be selected, the next parameter is not selected (S129: No), the progress is notified to the console (S130), and the change list is sent to the next host. (S119).

  The change request list is controlled so as to finally reach the management console (described later).

Next, the processing when there is a reference destination as a result of the check in S121 (S122: Yes) will be briefly described. In this case (S122: Yes), it is determined whether or not the reference destination has been processed in the change request list (S132). As a result, if it is determined that the processing has been completed (S132: Yes), the processing from S124 onward is performed. On the other hand, if it is determined that it has not been processed (S132: No), the parameter to be changed in the change request list is changed to the reference destination parameter (S133). Next, the reference destination is added to the forwarding route management area in the change request list (S134), and the revision number is further counted up (S135). Thereafter, the processing from S129 onwards is performed.
(C. Analysis / approval details)
We explained that the change request list finally reaches the management console. FIG. 10 is a diagram for explaining processing in the management console that has received this change request list.

  The management console receives the change request list from any server, and specifies the affected function range from this change request list (S136). For this identification, the change operation management table is referred. As shown in FIG. 3, the change operation management table includes a correspondence relationship between the change operation ID and the influence implementation parameter. Therefore, by referring to the change operation management table, it is possible to obtain the influence implementation parameter corresponding to the operation ID written in the pre-change operation area and the post-change operation area in the change request list received earlier. ing. As a result, the affected function range is specified.

  When the affected function range is specified, the affected business name is identified with reference to the business management table (S137). As shown in FIG. 3, the business management table includes a correspondence relationship between the influence implementation parameter and the business name. Therefore, by referring to this business table, it is possible to obtain a business name corresponding to the influence implementation parameter specified in S137.

  When the business name is specified, the unapproved change request list (database) is referred to, and the change request lists that can include the change operation are combined (S138). The unapproved change request list (database) stores an unapproved change request list as will be described later. The change request list stored here can be browsed by, for example, a system administrator via the screen illustrated in FIG.

  When a system administrator who browses the screen illustrated in FIG. 11 executes a predetermined operation, a list of unapproved change requests is displayed for each affected range (S139). FIG. 12 shows a display example of this list. The screen illustrated in FIG. 12 includes a business impact display and the like. When a change request to be approved is selected on this screen, the screen transitions to an analysis screen (see FIG. 13) that displays the detailed contents of the change request. This screen displays details of the list of individual change requests. If necessary, the parameter change history can be referred to based on the information in the mounting parameter DB of each server.

  A system administrator or the like can select another “combination target selection” button on the same screen to display a request selection screen and combine another change request.

  In this case (S140: Yes), the combination screen shown in FIG. 14 is displayed, and the change request lists designated by the user are combined (S141). FIG. 24 shows an example in which the change request list 1 and the change request list 2 are combined. The actual change operation is displayed on the combined screen. Change operations with the same level of influence can be combined, and a new change operation that optimizes the work of multiple change operations can be generated and executed.

On the other hand, when the system administrator or the like presses the “approval” button in the analysis screen illustrated in FIG. 13, an approved change request list is created (S143), and the approved change request list is transmitted. Registration is started in a predetermined database and management is started (S144).
(D. Change execution details)
The change request list created and sent as described above returns to the management console through all the servers to be changed.

As shown in FIG. 15, each server receives a change request list, executes a change command in the change request list, updates the change list (S146), notifies the console of the progress (S147), and next The change request list is transmitted to the server (S148).
(Example of consistency maintenance system)
Next, in the system shown in FIGS. 7A and 7B (a system including two servers (w3sv and fwsv) and a management console as a plurality of servers) a. Change detection, b. Investigation / propagation, c. Analysis / approval, d. An outline of an embodiment such as execution of change will be described with reference to FIGS.
(A. Outline of Example of Change Detection)
As shown in FIG. 16A and FIG. 16B, in any server (w3sv in FIG. 16A and FIG. 16B is illustrated), the user changes the parameters under that server (for example, parameters included in the definition file under the w3sv server) Suppose that In this case, in the w3sv, parameter designation information such as a URI for designating the changed parameter, a value before the change of the parameter (for example, port number 80), a planned change value of the parameter (for example, port number 8080), and the like Create a change request list that has been detected and written.
(B. Overview of Examples of Investigation / Propagation)
As shown in FIG. 17A, FIG. 17B, FIG. 18A, and FIG. 18B, in any server (w3sv is illustrated in FIG. 17A and FIG. 17B, fwsv is illustrated in FIG. 18A and FIG. 18B), Before changing the port number), it is checked whether or not the influence of the parameter change affects the parameters under other servers.

  If the effect affects parameters under other servers (examples of parameters included in the definition file under fwsv in FIGS. 17A and 17B, examples in which there are no such parameters in FIGS. 18A and 18B), the parameters 17A and 17B, the parameter specification information such as URI for specifying the parameter included in the definition file under fwsv in FIG. 17A, the value before the change of the parameter, the value to be changed of the parameter, etc. Write to the change request list (add and write).

  Then, the change request list after the writing is transmitted to another server (exemplified by fwsv in FIGS. 17A and 17B) affected by the change.

  The other server (exemplarily fwsv in FIG. 18A and FIG. 18B) receives the change request list sent earlier, and uses its subordinate parameters (for example, parameter designation information such as URI written in the change request list). Check whether the effect of changing the specified parameter affects parameters under other servers.

  If the effect affects parameters under other servers (change information related to the parameter is written (added and written) to the change request list received earlier.) Thereafter, the same processing as described above is performed in the other servers, that is, the change request list is transmitted to the other servers affected by the change. 18A and 18B exemplify the case where there is no parameter that affects such, and fwsv does not transmit the change request list to other servers.

On the other hand, in other servers (examples of fwsv in FIGS. 18A and 18B), the change does not affect the parameters under the other servers, and the conditions for sending the change request list to the management console are satisfied. Send the request list to the management console without sending it to other servers.
(C. Summary of Examples of Analysis / Approval)
As shown in FIGS. 19 and 20, the management console receives the change request list from another server (exemplarily the fwsv server in FIGS. 18A and 18B), and the change information written in the change request list Is displayed on an image display device such as a liquid crystal display, and the user is prompted to input whether or not to approve the change information.

When the approval of the change information is input, the change request list after the approval is transmitted for sequentially transferring to each server (w3sv, fwsv) through which the change request list has passed.
(D. Outline of Example of Execution of Change)
As shown in FIG. 21 to FIG. 23, each server (w3sv, fwsv) receives the change request list from the management console, and in accordance with the change information related to the parameters under its control written in the change request list. Change the parameters under.

Next, in the system shown in FIGS. 7A and 7B (a system including two servers (w3sv and fwsv) and a management console as a plurality of servers) a. Change detection, b. Investigation / propagation, c. Analysis / approval, d. Details of the embodiment such as execution of change will be described with reference to FIGS. 16 to 23.
(A. Details of change detection example)
16A and 16B are sequence diagrams for explaining an example of change detection.

  As shown in FIGS. 16A and 16B, in the target server (w3sv in FIGS. 16A and 16B is illustrated), the user changed port = 80 in the environment definition file under the target server to port = 8080 (rewrite) (S200).

Next, when the user inputs a Web server stop command (example ippstopsv.exe in FIGS. 16A and 16B) in the target server (example w3sv in FIGS. 16A and 16B) (S2
01) The change detection program (operation program) specifies an execution program (example ippstopsv.exe in FIGS. 16A and 16B) from the input command (S202).

The change detection program refers to the change program management table and checks whether or not the identified execution program (example ippstopsv.exe in FIGS. 16A and 16B) exists in the program identifier column of the table (S203). ).

Here, it is assumed that the specified execution program (example ippstopsv.exe in FIGS. 16A and 16B) does not exist in the program identifier column of the changed program management table.

  In this case, the change detection program executes the input Web server stop command as it is (without performing the following processing) (S204). As a result, the Web server software is stopped (S205).

  Next, when the user inputs a Web server start command (example ippstartsv.exe in FIGS. 16A and 16B) in the target server (example w3sv in FIGS. 16A and 16B) (S206), a change detection program (operation) The program) specifies an execution program (example ippstartsv.exe in FIGS. 16A and 16B) from the input command (S207).

  The change detection program refers to the change program management table to check whether or not the identified execution program (example ippstartsv.exe in FIGS. 16A and 16B) exists in the program identifier column of the table (S208). ).

  Here, it is assumed that the specified execution program (example ippstartsv.exe in FIGS. 16A and 16B) exists in the program identifier column of the changed program management table.

In this case, the change detection program refers to the change program management table and determines the program type (definition file in FIGS. 16A and 16B) corresponding to the identified execution program (example ippstartsv.exe in FIGS. 16A and 16B). (Example) is confirmed (S209).

  If it is confirmed that the program type is a definition file, the change detection program identifies the affected part of the mounting parameter DB by the program name (F3FMwww is illustrated in FIGS. 16A and 16B) corresponding to the identified execution program (program identifier). Specify (S210).

  Next, the change detection program recursively searches for the presence / absence of a change for all the identifiers in the identified affected part by the following method (S211).

  That is, the change detection program compares the actual setting information of the software for each identified identifier, detects the changed portion, and changes the actual setting information to the information before the change (S212). Here, port = 8080 in the environment definition file under the target server (illustrated as w3sv in FIGS. 16A and 16B) is rewritten to port = 80 (returns to the original).

  The change detection program checks all changes and confirms that there are no other changes, and then executes the command input in S206 (example ippstartsv.exe in FIGS. 16A and 16B) (S213). As a result, the Web server software is started (S214).

  When the Web server software is started, the change detection program notifies the user that the change has been suspended by performing a predetermined display on the display, etc., and if necessary, the degree of urgency and the reason for the change Is prompted (S215). In response to this notification, when the user inputs the degree of urgency and the reason for change (S216), the change detection program writes the input contents in the change request list (S217).

Then, the change detection program generates a mounting URI (w3sv / F3FMwww / environment definition 1 / parameter 2 / in FIG. 16A and FIG. 16B) that is a change content from the mounting parameter DB (S2
18) A change request list is created on the basis of this implementation URI and change contents (value 80 before change and value 8080 scheduled to be changed in the figure). That is, the change detection program includes its implementation URI (w3sv / F3FMwww / environment definition 1 / parameter 2 / in FIG. 16A and FIG. 16B) and change contents (FIG. 1).
6A, the value 80 before change and the value 8080 to be changed in FIG. 16B are written in the change request list.

  Then, the change detection program adds the forwarding route management area to the change request list, and transmits this change request list to the change impact investigation program (S219).

As explained above, a. Parameter designation information such as URI that designates a parameter that the user has changed (attempted to change) upon detection of change (w3sv / F3FMwww / environment definition 1 / parameter 2 / in FIGS. 16A and 16B), and the parameter A value before change and a value to be changed for the parameter (value 80 before change and value 8080 to be changed in FIGS. 16A and 16B) are detected, and a change request list in which these values are written is created.

In addition, a. The change request list is automatically generated by the change detection, but the change request list may be generated by the user inputting and writing the items written in the change request list each time. Good.
(B. Detailed Example of Investigation / Propagation Part 1)
FIG. 17A, FIG. 17B, and FIG. 18A, FIG. 18B are sequence diagrams for explaining an example of a change impact investigation.

As shown in FIGS. 16A and 16B, when the change detection program transmits a change request list in the target server (illustrating w3sv in FIGS. 16A and 16B) (S219), first, the target server (FIG. 17A, FIG. The change impact investigation program (exemplarily w3sv in 17B) receives the change request list from the change detection program, reads it, and starts processing (S220). This will be specifically described below.

  In the target server (w3sv in FIG. 17A and FIG. 17B exemplarily), the change impact investigation program refers to the received change request list, and the implementation URI with the unprocessed flag in the list is the own server (FIG. 17A). , Whether w3sv in FIG. 17B is applicable) is confirmed (S221).

As shown in FIGS. 17A and 17B, “001, / w3sv / F3FMwww / environment definition 1 / parameter 2,“ 80 ”,“ 8080 ”, unprocessed” is written in the change request list. This indicates that the implementation URI with the unprocessed flag corresponds to the own server (w3sv).

  In this case, the change impact research program refers to the mounting parameter DB and checks whether or not the reference mounting parameter is set in the corresponding mounting URI (S222). As shown in FIG. 3, FIG. 4A, and FIG. 4B, the mounting parameter DB is hierarchically configured so that it is possible to confirm whether or not a reference destination mounting parameter is set based on the mounting URI.

  Therefore, the change impact investigation program can determine whether or not the reference parameter is set in the corresponding mounting URI by checking the mounting parameter DB (S222).

  Here, description will be made assuming that the reference destination is not set.

  In this case, in the target server (exemplarily w3sv in FIGS. 17A and 17B), the change impact investigation program refers to its own implementation parameter DB and the operation ID before change (exemplifies F3FMwww001 in FIGS. 17A and 17B). The post-change operation ID (F3FMwww002 in FIGS. 17A and 17B is illustrated) is added to the pre-change operation area and post-change operation area in the change request list (S223).

As shown in FIGS. 3, 4A, and 4B, the implementation parameter DB can obtain the pre-change operation ID and post-change operation ID corresponding to “w3sv / F3FMwww / environment definition 1 / parameter 2” in the change request list. In order to do so, an identifier (example of w3-sv in FIGS. 4A and 4B), a type of server software (example of F3FMwww in FIGS. 4A and 4B), environment definition (example of environment definition file 1 in FIG. 4),
It is hierarchically configured such as parameters (examples of parameter 1 and parameter 2 in FIGS. 4A and 4B), an operation ID before change, and an operation ID after change.

Therefore, the change impact investigation program refers to this implementation parameter DB, so that the pre-change operation ID (example F3FMwww001 in FIGS. 4A and 4B) and the post-change operation ID (example F3FMwww002 in FIGS. 4A and 4B) are shown. It is possible to obtain. When the pre-change operation ID (example F3FMwww001 in FIGS. 17A and 17B) and post-change operation ID (example F3FMwww002 in FIGS. 17A and 17B) are added to the change request list, the change impact investigation program The operation flag for the mounted URI (/ w3sv / F3FMwww / environment definition 1 / parameter 2) is changed to “processed” (S224). As a result, “/ w3sv / F3FMwww / environment definition 1 / parameter 2,“ 80 ”,“ 8080 ”, unprocessed” in the change request list becomes “/ w3sv / F3FMwww / environment definition 1 / parameter 2,“ 80 ”. , “8080”, processed ”.

Next, the change impact investigation program checks whether or not the implementation URI (/ w3sv / F3FMwww / environment definition 1 / parameter 2) in the change request list is registered in the dependency DB (S225). This confirms whether or not the parameter specified by the mounted URI is referenced from other sources, that is, whether or not the influence of the change of the parameter specified by the mounted URI affects the parameters under other servers. Do (to find out).

As shown in FIG. 3 and FIG. 5, the dependency DB is the original implementation parameter (/ w3-sv / f3fmwww /
It includes the correspondence between environment definition file 1 / parameter 2) and dependent implementation parameters (example / fw-sv / safegate / condition setup / filtering definition 1 in the figure). This indicates that the original mounting parameter is referred to from the dependent mounting parameter, that is, the influence of the change of the original mounting parameter extends to parameters under other servers (fw-sv servers in FIGS. 4A and 4B).

17A and 17B, the change request list includes an implementation URI (FIG. 17A) in which the effect of the change extends to parameters under other servers (fw-sv server in FIGS. 4A and 4B).
In FIG. 17B, / w3sv / F3FMwww / environment definition (file) 1 / parameter 2) is registered in the dependency DB.

  In this case, the change impact investigation program adds the dependent implementation URI (/ fwsv / safegate / condition setup / filtering definition 1) to the change request list (S226).

Next, the change impact investigation program calculates the host name from the added implementation URI (FIG. 17A,
In FIG. 17B, the fwsv server is selected) and added to the forwarding route management area in the change request list, and the revision number is counted up (S227).

At the same time, the change impact investigation program writes the revision number 2 (exemplified w3sv (2) in FIG. 17A and FIG. 17B) to the forwarding destination local server (exemplified w3sv server in FIG. 17A and FIG. 17B). (S228). 17A and 17B, (2) of w3sv (2) indicates that the change request list has been processed in the server (illustrated by w3sv in FIGS. 17A and 17B) at the time of revision number 2.

  Then, the change impact investigation program sends the change request list to the management console and the next forwarding destination (here, fwsv written in the forwarding route management area) (S229, S230).

  As explained above, b. As a result of investigation / propagation, the target server (example of s3sv server in FIGS. 17A and 17B) is changed, and parameters under the server (parameter 2 specified by the URI in the change request list in FIGS. 17A and 17B) are changed. Before the determination, it is checked whether or not the influence of the parameter change affects the parameters under other servers (S225).

  When the influence affects parameters under other servers (filtering definition 1 under the fwsv server in FIGS. 17A and 17B), change information regarding the parameters (filtering definition 1 under the fwsv server in FIGS. 17A and 17B) The URI to be specified, the value 80 before the parameter change, the value 8080 to be changed for the parameter, and the like are written (added) to the previous change request list (S226).

Then, the change request list after writing is transmitted to another server affected by the influence (the fwsv server in FIGS. 17A and 17B is exemplified) (S229).
(B. Detailed Example of Investigation / Propagation Part 2)
As shown in FIGS. 18A and 18B, when the change impact investigation program transmits a change request list in the target server (illustrating w3sv in FIGS. 18A and 18B) (S229), the target server (in FIGS. 18A and 18B). The change impact investigation program (exemplarily fwsv) receives the change request list, reads it, and starts processing (S231). This will be specifically described below.

  In the target server (exemplified by fwsv in FIGS. 18A and 18B), the change impact investigation program refers to the received change request list, and the implementation URI with the unprocessed flag in the list is the own server (FIG. 18A). In FIG. 18B, fwsv is illustrated as an example) (S232).

As shown in FIGS. 18A and 18B, “002, / fwsv / safegate / condition setup / filtering definition 1,“ 80 ”,“ 8080 ”, unprocessed” is written in the change request list. this is,
Indicates that the implementation URI with the unprocessed flag corresponds to the local server (fwsv).

In this case, the change impact investigation program refers to the implementation parameter DB to determine whether or not the reference implementation parameter is set in the corresponding implementation URI (here / fwsv / safegate / condition setup / filtering definition 1). (S233). As shown in FIG. 3, FIG. 4A, and FIG. 4B, the mounting parameter DB is hierarchically configured so that it is possible to confirm whether or not a reference destination mounting parameter is set based on the mounting URI.

  Therefore, the change impact investigation program can determine whether or not the reference parameter is set in the corresponding mounting URI by checking the mounting parameter DB (S233).

Here, the description will be made assuming that the reference destination (/ w3sv / F3FMwww / environment definition 1 / parameter 2) is set.

In this case, in the target server (exemplarily fwsv in FIGS. 18A and 18B), the change impact investigation program refers to its own implementation parameter DB and refers to its implementation parameter (/ w3sv / F3FMwww / environment definition 1 / Check whether parameter 2) is included in the request list and whether it has been processed.

As shown in FIGS. 18A and 18B, the change request list includes “001, / w3sv / F3FMwww / environment definition 1 / parameter 2,“ 80 ”,“ 8080 ”, processed”. Then, it is confirmed that the reference destination implementation parameter is included and has been processed (S234).

  In this case, in the target server (exemplarily fwsv in FIGS. 18A and 18B), the change impact investigation program refers to its own implementation parameter DB, and the pre-change operation ID (exemplifies safegate001 in FIGS. 18A and 18B). Then, the post-change operation ID (example of safegate 002 in FIGS. 18A and 18B) is added to the pre-change operation area and post-change operation area in the change request list (S235).

As shown in FIG. 3 (the same applies to FIGS. 4A and 4B), the implementation parameter DB is the pre-change operation I corresponding to “/ fwsv / safegate / condition setup / filtering definition 1” in the change request list.
In order to obtain D and the post-change operation ID, the identifier, the type of server software, the environment definition, the parameters, the pre-change operation ID, and the post-change operation ID are hierarchically configured.

Therefore, the change impact investigation program refers to this implementation parameter DB, so that the pre-change operation ID (example of safegate001 in FIGS. 18A and 18B) and the post-change operation ID (FIG. 18A,
In FIG. 18B, safegate 002 is exemplified).

Pre-change operation ID (example of safegate001 in FIGS. 18A and 18B) and post-change operation ID (FIG. 1)
8A, example of safegate002 in FIG. 18B) is added to the change request list, the change impact investigation program sets the operation flag for the implementation URI (/ fwsv / safegate / condition setup / filtering definition 1) in the change request list to “processed” (S236). As a result, “002, / fwsv / safegate / condition setup / filtering definition 1,“ 80 ”,“ 8080 ”, unprocessed” in the change request list becomes “002, / fwsv / safegate / condition setup / filtering definition 1 , “80”, “8080”, processed ”.

Next, the change impact investigation program executes the implementation URI (/ fwsv / safegate /
It is confirmed whether or not the condition setup / filtering definition 1) is registered in the dependency DB (S237). This is whether or not the filtering definition (parameter) specified by the implementation URI is referenced from other sources, that is, whether or not the effect of changing the parameter specified by the implementation URI affects the parameters under other servers. This is done to check (inspect).

  Here, description will be made assuming that the implementation URI (/ fwsv / safegate / condition setup / filtering definition 1) in the change request list is not registered in the dependency DB.

In this case, the change impact investigation program executes revision number 2 (exemplified by fwsv (2) in the figure) processed by the local server (exemplified by fwsv in FIGS. 18A and 18B) in the forwarding route management area in the change request list. Is written (S238). Note that in the forward route management area of the change request list shown in FIGS. 18A and 18B, (2) of fwsv (2) indicates that the change request list was processed in the server (fwsv) at the time of revision number 2. Indicates.

  Then, the change impact investigation program determines whether or not all forwarding destinations are processed with the same revision number, and if this condition is satisfied, sends a change request list to the management console (S239). Here, w3sv (2) and fwsv (2) have the same revision number 2 in the forwarding route management area of the change request list shown in FIGS. 18A and 18B.

  Therefore, the change impact investigation program transmits the change request list to the management console. If the revision numbers are different, such as w3sv (2) and fwsv (3), the change impact investigation program sends a change request list to the server (w3sv). In this case, the change impact investigation program for the server (w3sv) executes the prescribed process and performs the process on the local server (illustrated w3sv in the figure) as w3sv (3) and fwsv (3). Revision number 3 is written. Then, when the same processing as S239 described above, that is, when all the forwarding destinations are processed with the same revision number, the change request list is transmitted to the management console.

  As explained above, b. As a result of the investigation / propagation, the other server (exemplarily fwsv in FIGS. 18A and 18B) receives the change request list transmitted from the target server (exemplary w3sv in FIGS. 18A and 18B). It is checked whether or not the influence of the change of the parameter (for example, the filtering definition 1 that is a parameter specified by the URI written in the change request list) affects the parameters under other servers (S237).

  18A and 18B exemplify a case where there is no parameter that affects such a situation (S237), the fwsv server does not transmit the change request list to another server.

That is, in this case, in other servers (exemplarily the fwsv server in FIGS. 18A and 18B), the influence does not reach the parameters under the other servers (there is no such parameter in S237), and the change request list is Since the conditions for transmission to the management console are satisfied (the same revision number in S238), the change request list is transmitted to the management console without being transmitted to other servers (S239).
(C. Details of Examples of Analysis / Approval)
19 and 20 are sequence diagrams for explaining the change approval process.

  As shown in FIG. 19, when the change impact investigation program transmits a change request list in the target server (exemplarily fwsv in FIG. 19) (S239), the change approval program of the management console receives the change request list. The process is started (S240). This will be specifically described below.

In the management console, the change approval program refers to the change operation management table, and the change operation IDs written in the operation area before change and the operation area after change in the change request list (F3FMwww001, safegate001, safegate002, F3FMwww002) is extracted from the influence implementation parameter and added to the change request list (S241).

  As shown in FIGS. 3 and 5, the change operation management table includes a correspondence relationship between the change operation ID and the affected implementation parameter. Therefore, the change approval program refers to the change operation management table, and the effect implementation parameter (/ w3sv / F3FMwww /, // corresponding to the change operation ID written in the pre-change operation area and the post-change operation area, respectively. fwsv / safegate /, / fwsv / safegate /, / w3sv / F3FMwww /) can be extracted.

  Next, the change approval program refers to the business management table and checks whether or not the related mounting parameter including the specified mounting parameter has an affected mounting parameter (S242).

  Here, the description will be made assuming that there is no such effect mounting parameter.

  In this case, the change approval program refers to the business management table, searches for related implementation parameters, and identifies the business name (S243). The change approval program merges the affected implementation parameters before and after the change in the request list when there is an inclusive relationship between the preceding and following affected implementation parameters (S244). For example, the processing from S136 to S144 described above with reference to FIG. 10 is performed.

  Next, the change approval program calculates an estimated influence time for the pre-change operation and the post-change operation in the change request list based on the information in the change operation management table (S245). Then, the change approval program displays the request name, the request date and time, the affected business name, and the estimated affected time to the user (S246). If a user such as an administrator who has viewed the display determines that there is no problem, the user approves the change request list (S247). For example, an approval command is input to the management console.

  When the change request list is approved, the change approval program uses the change operation management table to change each change operation ID in the change request list (here, /, ippstopsv.exe, /, stop safegate, / , start safegate, /,ippstartsv.exe) is added (S248).

  When this addition is completed, the change approval program sends the change request list to the destination (here w3sv) of the first implementation URI of the pre-change operation (S249).

  As described above, by the change approval process, the management console receives the change request list from another server (exemplarily the fwsv server in FIG. 19) and displays the change information written in the change request list. The user is prompted to input whether or not to approve the change information (change due to) by displaying it on an image display device such as a liquid crystal display connected to the management console (S246).

When it is input to approve the change information (S247), the change request list after the approval is transmitted for sequentially transferring to each server (s3sv, fwsv) through which the change request list has passed (S249).
(D. Details of execution example of change execution)
21 to 23 are sequence diagrams for explaining an example of the change execution process.

  As shown in FIGS. 21A and 21B, when the management console transmits the change request list (S249), the change program of the target server (illustrated by w3sv in FIGS. 21A and 21B) receives the change request list, And start processing (S250). This will be specifically described below.

  The change program refers to the received change request list, executes (executes) the first line of the pre-change operation (F3FMwww001 / w3sv / F3FMwww /, ippstopsv.exe in FIG. 21), and adds a processed flag ( S251). As a result, the Web server software is stopped (S252).

When the execution of the first line is completed, the change program refers to the forwarding route management area in the change request list, grasps the next forwarding destination (fwsv), and sends the change request list to this forwarding destination. (S252)
When w3sv transmits the change request list (S252), the change program of the target server (exemplified by fwsv in FIGS. 21A and 21B) receives the change request list, reads it, and starts processing (S253). This will be specifically described below.

The change program refers to the received change request list, executes (executes) the first line (safegate001 / fwsv / safegate / stop safegate in FIGS. 22A and 22B) of the pre-change operation, and adds a processed flag. (S254). As a result, all pre-change operations to be performed by the user have been completed, so the change request area is set to the next forwarding destination (w3sv in FIG. 22A and FIG. 22B is illustrated) as the change request in the change request list. The list is transmitted (S255).

  When the target server (exemplifies fwsv in FIGS. 22A and 22B) transmits the change request list (S255), the change program of the target server (w3sv in FIGS. 21A and 21B) receives the change request list and receives it. Reading and processing are started (S256). This will be specifically described below.

  The change program refers to the received change request list, and changes the setting based on the identifier information of its own mounting parameter DB (S257). As a result, the port number is changed from 80 to 8080. Then, the implementation parameter URI executed in the change request list is changed to completion (S258).

  Because all the pre-change operations that should be performed by this setting change have been completed, the incomplete implementation URI of the change parameter area in the change request list is set to the next forwarding destination (fwsv in FIGS. 21A and 21B). Then, the change request list is transmitted (S259).

  When the target server (illustrating w3sv in FIGS. 22A and 22B) transmits the change request list (S260), the change program of the target server (fwsv in FIGS. 22A and 22B) receives the change request list and receives it. Reading and processing are started (S260). This will be specifically described below.

  The change program refers to the received change request list and changes the setting based on the information of the identifier of its own mounting parameter DB (S261). As a result, the port number is changed from 80 to 8080. Then, the executed implementation parameter URI in the change request list is changed to completion (S262).

  Because all the pre-change operations and mounting parameters that should be performed by this setting change have been completed, the change request list is transmitted with the uncompleted post-change operation as the next forwarding destination (S264).

Here, the self receives the change request list, reads it, and starts processing (S26).
4).

  In this case, the change program refers to the received change request list, executes (executes) the first line of the post-change operation, and adds a processed flag (S265). This starts the program (S266).

  As a result, since all the pre-change operations and implementation parameters that should be performed by the self are completed, the uncompleted post-change operation is set as the next forwarding destination (w3sv is illustrated in FIGS. 23A and 23B) and the change request list is displayed. Transmit (S267).

When the target server (exemplifies fwsv in FIGS. 23A and 23B) transmits the change request list (S2
67) The change program of the target server (exemplarily w3sv in FIGS. 23A and 23B) receives the change request list, reads it, and starts processing (S268).

  Specifically, referring to the change request list, since all the pre-change operations and the implementation parameters that should be performed by the self have been completed, an uncompleted post-change operation is performed and a processed flag is added (S269). . As a result, the Web server software starts (S270).

  Next, since the pre-change operation, the implementation parameters, and the post-change operation are all completed, a bureaucracy report is notified to the management console (S271). Thereby, the changing operation is completed.

  As explained above, d. By executing the change, each server (s3sv, fwsv, etc.) receives the change request list from the management console in sequence, and changes its own subordinates according to the change information about its subordinate parameters written in the change request list. The parameter is changed (S252, S261, etc.).

  The present invention can be implemented in various other forms without departing from the spirit or main features thereof. For this reason, said embodiment is only an illustration in all the points, and is not interpreted limitedly.

  The present invention can also be specified as follows.

(Appendix)
(Appendix 1) A system that includes a plurality of servers and a management console, and before a specific server changes a parameter under its control, means for writing change information regarding the parameter in a change request list; Means for examining whether or not the influence of the change of the parameters under its own affects the parameters under the other servers, and when the influence affects the parameters under the other servers, the change request regarding the parameters is sent to the change request. Means for writing to the list, and sending the change request list after the writing to the other server, wherein the other server receives the change request list from the specific server; Means for checking whether or not the influence of the change of the subordinate parameter affects the parameters of the other server; In the case of a parameter, the change information related to the parameter is written in the change request list, the change request list after the writing is transmitted to the other server, and the influence does not affect the parameters under the other server. And when the condition for transmitting the change request list to the management console is satisfied, means for transmitting the change request list to the management console, wherein the management console receives a change request from the other server. Means for receiving a list, means for prompting a user to input whether to approve change information written in the change request list, and approving the change information written in the change request list. Means for transmitting the change request list after the approval for sequential transfer to each of the servers. The server and other servers execute the change of the parameters under their control according to the means for receiving the change request list from the management console and the change information regarding the parameters under its control written in the change request list. A consistency maintenance system comprising: means.

  (Additional remark 2) The change information regarding the parameter includes parameter specification information for specifying the parameter, a value before the change of the parameter, a value to be changed for the parameter, and a value to which the parameter is to be changed from before the change. The consistency maintenance system according to supplementary note 1, including operation specifying information for specifying an operation to be executed for the purpose.

  (Supplementary Note 3) When the management console further selects means for prompting the user to select another change request list to be combined with the change request list from the other server, and the other change request list is selected, The consistency maintenance system according to claim 1, further comprising means for combining the change information written in the other change request list with the change information written in the change request list from the other server.

  (Appendix 4) Before changing the parameters under its own control, the step of writing the change information regarding the parameter to the change request list, and whether the change of the parameters under its own control affects the parameters under other servers And when the influence affects a parameter under another server, the change information regarding the parameter is written in the change request list, and the change request list after the writing is transmitted to another server. When receiving a change request list from another server and whether a change request list from another server is received, whether the change of the parameters under its own affects the parameters under the other server Whether or not the effect affects parameters under other servers. And writing the change information to the change request list, sending the change request list after the writing to another server, and the influence does not affect parameters under other servers, and the change request list is When the condition for sending to the management console is satisfied, the step of sending the change request list to the management console, the step of receiving the change request list from the management console, and the self request written in the change request list Executing a change of the parameters under its control according to the change information regarding the parameters under control thereof.

  (Supplementary Note 5) A step of receiving a change request list from a predetermined server, a step of prompting the user to input whether or not to approve change information written in the change request list, And a step of transmitting the approved change request list for sequential transfer to each of the servers when the written change information is input to be approved.

(Appendix 6) Before changing the parameters under its own control, the server writes the change information regarding the parameters to the change request list, and the effect of the change of the parameters under its own When the influence affects a parameter under another server, the change information regarding the parameter is written in the change request list, and the change request list after writing is sent to the other server. When the means for sending, the change request list from another server, the means for receiving, and the change request list from another server are received, the influence of the change of the parameters under its own is affected by the parameters under the other server Means for checking whether or not the above-mentioned influence is present, and when the influence affects a parameter under another server, change information regarding the parameter To the change request list, and to send the change request list after the write to another server, the influence does not affect the parameters under the other server, and the change request list is sent to the management console. Means for transmitting the change request list to the management console when receiving the condition for transmission, means for receiving the change request list from the management console, and parameters under its control written in the change request list A program for functioning as a means for executing a change of parameters under its control in accordance with the change information regarding.

(Supplementary note 7) means for receiving a management console, a change request list from a predetermined server;
If the means for prompting the user to input whether or not to approve the change information written in the change request list and approving the change information written in the change request list are input, A program for causing a later change request list to function as means for transmitting in order to sequentially transfer the change request list to each of the servers. .

  (Appendix 8) Before changing the parameters under its own control, the means for writing the change information about the parameter to the change request list, and whether the influence of the change of the parameters under its own control affects the parameters under other servers And when the influence affects a parameter under another server, a change information regarding the parameter is written in the change request list, and the change request list after the writing is transmitted to another server. And the means for receiving the change request list from another server, and if the change request list from another server is received, whether the influence of the change of the parameters under its own affects the parameters under the other server Means for checking whether or not, and when the influence affects a parameter under another server, change information regarding the parameter is Means for writing in the update request list, and sending the change request list after the write to another server, and for sending the change request list to the management console without the influence affecting parameters under other servers If the above condition is satisfied, means for transmitting the change request list to the management console, means for receiving the change request list from the management console, and change information regarding the parameters under its control written in the change request list And a means for executing a change of parameters under its control.

(Appendix 9)
Means for receiving a change request list from the server described in appendix 8, means for prompting a user to input whether to approve change information written in the change request list, and the change request list A management console comprising: means for transmitting, in order to sequentially transfer the change request list after the approval to each of the servers when the approval of the change information written in is input.

According to the present invention, it is possible for an operation manager to perform a change operation taking into consideration the consistency of the system without referring to related information such as a system design document and a product manual. In addition, by incorporating in advance the design content that was previously described in the design document as a dependency rule in the implementation system, the change operation of the other part of the system that occurs with one change operation is automatically generated, It becomes possible to realize a consistent change operation in the entire system.

Further, by combining a plurality of change operations according to the degree of influence, it is possible to reduce duplicate work at the time of change and optimize the change work. In addition, by forcing a change operation based on approval systematically, it is possible to suppress an inadvertent trouble caused by an operation error or a security breach. Furthermore, in addition to the information in the design document and product manual, record the impact (execution time, load, problems at the time of change) when the operation is performed, and use it as a judgment material for the next operation. Is possible. In addition, when there is a system-specific problem in the operation procedure, the operation can be continuously improved by updating it as special dependency information.

It is a figure for demonstrating the characteristic of this invention in contrast with the prior art. It is an example of a program used in the consistency maintenance system which is one Embodiment of this invention. It is an example of the database etc. which are used in the consistency maintenance system which is one embodiment of the present invention. It is an example of the database etc. which are used in the consistency maintenance system which is one embodiment of the present invention. It is an example of the database etc. which are used in the consistency maintenance system which is one embodiment of the present invention. It is an example of the database etc. which are used in the consistency maintenance system which is one embodiment of the present invention. It is an example of the database etc. which are used in the consistency maintenance system which is one embodiment of the present invention. It is a flowchart for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a flowchart for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a flowchart for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a flowchart for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a flowchart for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is an example of a screen displayed at the time of approval in the management console included in the consistency maintenance system which is one embodiment of the present invention. It is an example of a screen displayed at the time of approval in the management console included in the consistency maintenance system which is one embodiment of the present invention. It is an example of a screen displayed at the time of approval in the management console included in the consistency maintenance system which is one embodiment of the present invention. It is an example of a screen displayed at the time of approval in the management console included in the consistency maintenance system which is one embodiment of the present invention. It is a flowchart for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a sequence for demonstrating operation | movement of the consistency maintenance system which is one Embodiment of this invention. It is a figure for demonstrating the combination process of the change operation in the management console included by the consistency maintenance system which is one Embodiment of this invention.

Claims (5)

A system including a plurality of servers and a management console,
A specific server
Before changing a parameter under its control, a means for writing change information related to the parameter to a change request list;
A means for checking whether or not the influence of the change of the parameters under its own affects the parameters under the other servers;
Means for writing the change information regarding the parameter to the change request list when the influence affects the parameters under the other server, and transmitting the change request list after the writing to the other server;
With
The other server is
Means for receiving a change request list from the specific server;
A means for checking whether or not the influence of the change of the parameters under its own affects the parameters under the other servers;
Means for writing the change information regarding the parameter to the change request list when the influence affects the parameters under the other server, and transmitting the change request list after the writing to the other server;
Means for transmitting the change request list to the management console when the influence does not reach parameters under other servers and satisfies the condition for transmitting the change request list to the management console;
With
The management console is
Means for receiving a change request list from the other server;
Means for prompting the user to enter whether to approve change information written in the change request list;
Means for transmitting the change request list after the approval to be sequentially transferred to each of the servers when it is inputted to approve the change information written in the change request list;
With
The specific server and other servers are
Means for receiving a change request list from the management console;
Means for executing the change of the parameters under its own according to the change information regarding the parameters under its own written in the change request list;
Consistency maintenance system comprising. The change information about the parameter is executed to change the parameter designation information for specifying the parameter, the value before the change of the parameter, the value to be changed of the parameter, and the parameter to the value to be changed from before the change. Contains operation identification information that identifies the operation to be performed,
The consistency maintenance system according to claim 1. The management console further includes:
Means for prompting the user to select another change request list to be combined with the change request list from the other server;
Means for combining the change information written in the other change request list with the change information written in the change request list from the other server when the other change request list is selected;
The consistency maintenance system of Claim 1 provided with. Writing change information about the parameter to the change request list before changing the parameter under its control;
A step of examining whether or not the influence of the change of the parameters under its own affects the parameters under the other servers;
When the influence affects a parameter under another server, writing the change information regarding the parameter in the change request list, and sending the changed change request list to the other server;
Receiving a change request list from another server;
When receiving a change request list from another server, a step of checking whether or not the influence of the change of the parameters under its own affects the parameters under the other server;
When the influence affects a parameter under another server, writing change information regarding the parameter to the change request list, and sending the changed change list after writing to another server;
A step of transmitting the change request list to the management console when the influence does not reach parameters under other servers and the condition for transmitting the change request list to the management console is satisfied;
Receiving a change request list from the management console;
Executing the change of the parameters under its own according to the change information regarding the parameters under its own written in the change request list;
A method for maintaining consistency. Receiving a change request list from a given server;
Prompting the user to enter whether to approve change information written to the change request list;
When it is input to approve the change information written in the change request list, the change request list after the approval is transmitted to be sequentially transferred to the servers;
A method for maintaining consistency.

Images