JP2009289054A - Server computer for cluster system, and application clustering possibility determination support program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide information, which shows conditions of accessing server unique information having possibility of disturbing the clustering of an application, to a user. <P>SOLUTION: A hook mechanism 222 of a hook library mechanism 22 hooks the calling of an application program interface (API) for performing access from an application 130 to server unique information based on a hook library stored in a hook library storage part 221. The hook mechanism 222 performs hooked calling. An access management mechanism 224 records access to the server unique information based on the hooked calling of the API in an access management table 223. A state notification mechanism 226 notifies a user of information, shown by the access management table 223, which shows the circumstances of access from the application 130 to the server unique information. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a server computer used in a cluster system, and more particularly to a server computer for a cluster system and an application clusterability determination support program suitable for supporting determination of the possibility of application clustering.

  Conventionally, a cluster system including a plurality of server computers (servers) is known. A feature of this cluster system is that services provided to a user by executing an application (specific application) continue to be provided to the user even if the application or a server that executes the application fails. There is in point that can.

  In a cluster system, a server among a plurality of servers constituting the system serves as an active server and executes an application. In the cluster system, when a failure occurs in the application itself or the server that executes the application, the same application is re-executed on another server that constitutes the system, so that the service provided to the user can be continued. The In the following description, not only a server in which a failure has occurred but also a server that executes an application in which a failure has occurred is referred to as a failure server. On the other hand, a server that re-executes an application, that is, a server that takes over execution (service) of an application is called a takeover destination server.

  The cluster system is provided with a mechanism for preventing the user who receives the service from being aware that the server that executes the application has changed due to a failure. According to this mechanism, in order to continue the service as described above, that is, in order to maintain the continuity of the service, the data used by the application is shared between the servers constituting the system. In addition, the environment (indicating environment information) is also taken over so that the failed server and the takeover destination server operate under the same conditions as much as possible.

  In order to be able to use an application in such a cluster system, that is, to be able to cluster an application (cluster configuration), several conditions are required. For example, when the server that executes an application changes for service continuation, the application has information specific to the hardware (HW) or server, for example, a host ID (Host ID), a MAC (Media Access Control) address (physical address) If the operation depends on server-specific information such as a server serial number, the application may not be clustered. That is, access to server-specific information that occurs inside an application may hinder the clustering of the application. For this reason, it has been common for users using the application to determine the possibility of clustering using a check sheet that summarizes the confirmation points necessary to determine the possibility of application clustering. Met.

Incidentally, an application generally calls (calls) a function (application program interface: API) in order to execute a target process. If the function name (API name) of the function (API) called by the application is replaced with another name and a function having the same name as the replaced function name is executed, the function can be changed without changing the function. It can be expanded (see, for example, Patent Document 1).
JP-A-11-110194

  Server-specific information such as the host ID, the MAC address, and the server serial number described above can be used as information used for determination that application clustering is possible. Such server-specific information is generally included in data (shared data) shared by a plurality of servers constituting the cluster system.

  However, server-specific information includes information that can be independently determined by the user from the external specifications and functions of the application, and internal information that is not disclosed to the user and cannot be understood by an application developer. It is difficult for a user (end user) to completely check access to internal server-specific information, that is, server-specific information hidden from the outside. Even if it is determined that application clustering is possible by prior verification of server-specific information hidden from the outside, there may be a problem in a specific usage method of the application during operation. Similarly, there may be a problem when the specification changes after updating the OS or application. For this reason, it is difficult to confirm whether or not application clustering is possible by considering only the server verification information in advance, considering all possibilities.

  The present invention has been made in consideration of the above circumstances, and its purpose is information indicating the status of access to server-specific information that is hidden inside the application and may hinder application clustering. Is to provide a cluster system server computer and an application clusterability possibility determination support program.

  According to one aspect of the present invention, a server computer for a cluster system capable of executing a specific application for providing a service to a user is provided. The server computer for a cluster system includes a system library storage unit that stores in advance a system library including a set of first application program interfaces for acquiring server-specific information unique to the server computer, and the first application program In response to the interface call, the application program interface providing means for providing the first application program interface to the caller and the first application program interface are associated with the first application program interface, and the first application program interface is hooked Hook library memory that pre-stores a hook library that includes a second set of application program interfaces that define the operation at the time And hook means for hooking a call to the first application program interface from the specific application based on the hook library stored in the hook library storage means, the hook library being hooked in the hook library Hook means for calling the hooked first application program interface in accordance with the second application program interface associated with one application program interface, and calling the first application program interface from the specific application And an access management table used to record access to the server specific information based on the first means by the hook means. An access management means for recording, in the access management table, access to the server-specific information based on the call to the first application program interface when the application program interface call is hooked; and the access management table And status notification means for notifying the user of information indicating the status of access to the server specific information from the specific application.

  According to the present invention, in the operating state of a specific application, access to server-specific information that is used hidden inside the specific application (that is, to server-specific information that may hinder the clustering of the specific application) The server can be used by the user to determine the possibility of clustering of the specific application by hooking the call from the specific application (call of the first application program interface) for Information indicating the status of access to the unique information can be provided.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is a block diagram showing a hardware configuration of a server computer for a cluster system according to an embodiment of the present invention.

  In FIG. 1, a server computer (hereinafter referred to as a server) 10 includes a CPU 11 and a main memory 12. The server 10 is connected to an external storage device 13 such as a magnetic disk device. The external storage device 13 is disposed in a housing (not shown) of the server 10. That is, the server 10 has an external storage device 13 in addition to the CPU 11 and the main memory 12.

  An application 130 is stored in the external storage device 13. The application 130 is a specific application program (specific application) used to provide a service to a client terminal (user) using the cluster system. The application 130 is loaded (read) and executed in the main memory 12 of the server 10.

  The external storage device 13 also stores an application clustering possibility determination support program 131 that is used to support determination of the possibility of clustering of the application 130. The program 131 is loaded into the main memory 12 of the server 10 and executed.

FIG. 2 is a block diagram mainly showing a functional configuration of the server 10 shown in FIG.
The server 10 includes a system library mechanism 21 and a hook library mechanism 22 as shown in FIG.

  The system library mechanism 21 includes a system library storage unit 211 and an application program interface providing mechanism (API providing mechanism) 212. The system library mechanism 21 is provided in, for example, an operating system (OS) (not shown) of the server 10.

  The system library storage unit 211 stores a system library used to provide a function (application program interface: API) to a caller according to a standard call (function call) such as a system call. The system library is a set of various functions (system function or system life library function) that can be referred to from the outside by the above call. The system library storage unit 211 is realized by using a part of the storage area of the external storage device 13 shown in FIG.

  The API providing mechanism 212 calls a function (API) designated from the system library stored in the system library storage unit 211 in response to a function (API) call from the application 130 or the hook mechanism 23 described later. The API providing mechanism 212 provides a called function (API) to the caller.

  The hook library mechanism 22 includes a hook library storage unit 221, a hook mechanism 222, an access management table 223, an access management mechanism 224, a state determination mechanism 225, and a state notification mechanism 226.

  The hook library storage unit 221 stores a hook library. The hook library is a system function (API) that is prepared for each piece of information specific to the server 10 (server specific information), for example, among the set of system functions that constitute the system library, and is used for accessing the server specific information. This is a set of hook functions prepared in advance corresponding to the set. Each hook function (second function) included in the hook library is stored in the hook library storage unit 221 in association with the function name of the system function (first function) corresponding to the hook function. The hook library storage unit 221 is realized by using a part of the storage area of the external storage device 13 shown in FIG. In order to speed up library reference, the system library and the hook library stored in the external storage device 13 (the system library storage unit 211 and the hook library storage unit 221) are stored in the external storage device 13 when the server 10 is started. Alternatively, it may be configured to be loaded into a predetermined area of the main memory 12.

  The hook mechanism 222 hooks a call (call) of a function (first function) from the application 130. The hook mechanism 222 calls a hook function associated with a system function having a function name specified by a function call hooked by itself, and together with the access management mechanism 224, the state determination mechanism 225, and the state notification mechanism 226, the hook mechanism Performs processing specific to the function.

  Processing unique to the hook function is roughly divided into first to fifth processing. The first process is a process for calling the system function designated by the function call hooked by the hook mechanism 222 from the system library mechanism 21. The second process is a process for returning the processing result (return value) of the called system function to the application 130. The hook mechanism 222 executes the first and second processes.

  The access management table 223 is used to manage access (reference) from the application 130 to the specific information for each predetermined server specific information. Here, server-specific information unique to the server 10 that the server 10 has (assigned to the server 10), such as a host ID (Host ID), MAC address, and server serial number, is managed by the access management table 223. . The access management table 223 is realized using, for example, a part of the storage area of the main memory 12 shown in FIG. A system function (API) for accessing each server-specific information is predetermined.

FIG. 3 shows an example of the data structure of the access management table 223 shown in FIG.
The access management table 223 includes a group of entries for holding the number of accesses to the specific information for each predetermined server specific information. Each entry of the access management table 223 includes columns (server specific information column and access count column) for holding server specific information and the number of accesses (the number of accesses to the specific information). That is, the access management table 223 holds the number of accesses to the specific information in association with each predetermined server specific information.

  Referring again to FIG. 2, the access management mechanism 224 calls the function (API) in response to the function call hooked by the hook mechanism 222, and executes the called function (API) to identify the unique information ( When the server specific information) 23 is accessed (referenced), the third process is executed. The third process is a process for incrementing the access count (reference count) associated with the specific information 23 in the access management table 223 by one. Here, it is assumed that the server specific information 23 is stored in the external storage device 13.

  The state determination mechanism 225 performs a process (fourth process) for determining whether the number of accesses exceeds a threshold by monitoring the number of accesses for each server-specific information held in the access management table 223. To do. The status notification mechanism 226 generates information (access status information) indicating the status of access to the server-specific information from the application 130, and notifies the user of the generated information (fifth processing). Execute. In the present embodiment, the state notification mechanism 226 notifies the user (for example, a system administrator) server-specific information associated with the number of accesses determined to have exceeded the threshold by the state determination mechanism 225 as the access status information. The

  Next, the operation of the present embodiment will be described with reference to the flowchart of FIG. 4, taking as an example a case where the system function fun1 () is called from the application 130 operating on the server 10. .

  Conventionally, the application 130 operating on the server 10 executes a system call by linking the system library mechanism 21 (the system library stored in the system library storage unit 211) to the application 130 itself. . On the other hand, in the present embodiment, the hook library mechanism 22 is logically arranged between the application 130 and the system library mechanism 21.

  It is assumed that the system function (API) fun1 () is called from the application 130 (step S1). Then, the hook mechanism 222 of the hook library mechanism 22 hooks the call of fun1 () based on the hook library stored in the hook library storage unit 221 as described below (step S2).

  The system function fun1 () is assumed to be an API (application program interface) for accessing information (server specific information) 23 unique to the server 10. When this server specific information 23 is, for example, a host ID, the system function fun1 () is an API called getostid ().

  The call of the system function fun1 () includes the function name of the fun1 () and an argument. It is assumed that the hook function FUN1 () is set in the hook library stored in the hook library storage unit 221 in association with the function name of fun1 (). In this case, the hook mechanism 222 hooks the call of fun1 () from the application 130. As a result, the hook library mechanism 22 prevents the application 130 from linking the system library mechanism 21 to the application 130 itself. Such an operation of hooking a function call is realized by using a library hook technique as described in Patent Document 1.

  If the hook function is not stored in the hook library in association with the function name of fun1 (), the hook mechanism 222 does not hook the call of fun1 (). In this case, the call of fun1 () is input to the API providing mechanism 212 of the system library mechanism 21.

  When hooking the call to the system function fun1 () (step S2), the hook mechanism 222 calls the hook function FUN1 () set in the hook library in association with the function name of the hooked fun1 () (step S3). ). That is, instead of calling the system function fun1 () from the system library stored in the system library storage unit 211 in response to the call of fun1 () from the application 130, the hook stored in the hook library storage unit 221. The hook function FUN1 () is called from the library.

  When fun1 () is an API (system function) called getostid (), for example, GETHOSTID () is used as the hook function (hook library function) FUN1 () prepared in the hook library.

  When the hook function FUN1 () (for example, GETHOSTID ()) is called by the hook mechanism 222, the hook library mechanism 22 performs processing unique to the hook function FUN1 () according to the hook function FUN1 (). The access management mechanism 224, the state determination mechanism 225, and the state notification mechanism 226 are executed as follows.

  First, the hook mechanism 222 notifies the access management mechanism 224 of server-specific information 23 to be accessed by executing the system function fun1 () having the function name specified by the function call hooked by itself. Note that the server specific information 23 to be accessed by executing the system function fun1 () is predetermined. Therefore, the hook library may be configured so that not only the hook function FUN1 () but also the server specific information 23 is set in association with the function name of fun1 ().

  Based on the notified server specific information 23, the access management mechanism 224 increments the number of accesses held in the access management table 223 in association with the specific information 23 by 1 (step S4). Therefore, if fun1 () is the above-mentioned gethotid (), the access count held in association with the host ID in the access management table 223 is incremented by one.

  As described above, in this embodiment, although the server-specific information is accessed by the application 130 not involving the user, that is, the hidden server-specific information is accessed regardless of the hidden server-specific information. The access to the server specific information can be recorded in the access management table 223.

  The state determination mechanism 225 determines whether the access count (count value) counted up by the access management mechanism 224 exceeds a predetermined threshold (step S5).

  If the number of accesses after counting up does not exceed the threshold (step S5 is NO), the control is immediately returned to the hook mechanism 222. Then, the hook mechanism 222 calls fun1 () hooked by itself instead of the application 130 (step S6). In response to the call of fun1 () from the hook mechanism 222, the API providing mechanism 212 of the system library mechanism 21 calls and executes the fun1 () from the system library stored in the system library storage unit 211 ( Step S7). As described above, the call of fun1 () hooked by the hook mechanism 222 is performed by the hook mechanism 222, so that the fun1 () becomes the system library mechanism in the same manner as when fun1 () is called from the application 130 in the related art. 21 API providing mechanisms 212. Thereby, access to the server specific information 23 (referring to the server specific information 23) is performed (step S8).

  The API providing mechanism 212 returns the execution result of fun1 () called by the hook mechanism 222, that is, the result of access to the server specific information 23, as a return value to the calling hook mechanism 222. The hook mechanism 222 returns the return value (server specific information 23) returned from the API providing mechanism 212 to the application 130. As described above, in the present embodiment, the result of executing fun1 () in response to the call of fun1 () from the application 130 is used as the return value (server specific information 23) for the call of fun1 () as a hook library mechanism. 22 (the hook library mechanism 22) is returned to the application 130 (step S9).

  The application 130 performed a return value (server specific information 23) returned from the system library mechanism 21 (internal API providing mechanism 212) via the hook library mechanism 22 (internal hook mechanism 222). Received as a return value (server-specific information 23) for the fun1 () call. As a result, the application 130 can perform processing using the received return value (server specific information 23) without being affected by the operation of the hook library mechanism 22 (the hook mechanism 222 therein). That is, in the present embodiment, the operation of the hook library mechanism 22 does not affect the operation of the application 130 at all.

  The above operations are executed each time a system function is called by the application 130. Eventually, it is assumed that the number of accesses held in the access management table 223 in association with the server specific information 23 exceeds the threshold value as a result of several calls of fun1 () from the application 130. In this case, the state determination mechanism 225 determines YES in step S5, and passes control to the state notification mechanism 226.

  Then, the status notification mechanism 226 generates information indicating that the number of accesses to the server specific information 23 has exceeded the threshold, and uses the generated information as information indicating the status of access to the server specific information from the application 130. For example, the user (system administrator) is notified by e-mail (step S10). From this notification, when the application 130 currently being executed has a high possibility of affecting clustering, that is, when the failure of the application 130 or the failure of the server 10 executing the application 130 occurs, It can be determined that it is difficult to continue the service provided to the user by executing the application 130.

  When the state notification mechanism 226 makes the above notification, the state notification mechanism 226 returns control to the hook mechanism 222. As a result, the steps S6 to S9 are performed as in the case where the number of accesses after counting up does not exceed the threshold value.

  Note that notification means other than e-mail can be used to notify the user that the number of accesses to the server-specific information 23 has exceeded the threshold from the state notification mechanism 226. For example, the state notification mechanism 226 may write information indicating that the number of accesses to the server specific information 23 exceeds a threshold value in a specific file that can be referred to by the user through the client terminal.

  Further, the state determination mechanism 225 is not always necessary. Here, the access management mechanism 224 of the hook library mechanism 22 manages, for example, the number of times server-specific information is accessed by the application 130 over the execution period of the application 130 or, for example, for a certain period from the start of the application 130. It shall be recorded in the table 223. In this case, the status notification mechanism 226 may notify the user (system administrator) of the contents of the access management table 223 as information indicating the status of access to the server specific information from the application 130 after the above period. Further, after the above period, the state notification mechanism 226 may cooperate with the state determination mechanism 225 to select entry information with the access count of 1 or more from the access management table 223 and notify the user. Based on the notification from the status notification mechanism 226, the user determines whether the currently executing application 130 performs hidden access to server-specific information that may affect clustering. Of course, the greater the number of accesses, the greater the potential impact on application 130 clustering.

  Further, a function name column used to hold a function name of a system function for accessing server-specific information may be added to each entry of the access management table 223. In other words, the access management table 223 holds the number of accesses to the specific information in association with each pair of predetermined server specific information and a function name of a system function for accessing the specific information. It doesn't matter. In this case, the hook mechanism 222 may notify the access management mechanism 224 of the function name specified by the function call hooked by itself. Based on the notified function name, the access management mechanism 224 can count up the number of accesses held in the access management table 223 in association with the function name.

[First Modification]
Next, a first modification of the above embodiment will be described with reference to FIG.

  First, the feature of the above-described embodiment is that, as the number of accesses to the server-specific information increases, the possibility of the application 130 being affected by clustering increases. It is to notify the user. On the other hand, the feature of the first modification is that the server-specific information is also changed when the server that executes the application 130 is switched (that is, at the time of failover). In other words, the server 10 alone is verified without switching the server. That is, the feature of the first modification is that the simulation at the time of failover is performed by the active server 10 alone.

  FIG. 5 is a block diagram mainly showing a functional configuration of the server 10 applied in the first modification. 5, elements equivalent to those in FIG. 2 are denoted by the same reference numerals.

  In the server 10 shown in FIG. 5, unlike the above embodiment, a hook library mechanism 22 a is used instead of the hook library mechanism 22. The hook library mechanism 22a includes a hook library storage unit 221, a hook mechanism 222, an access management table 223a, an access management mechanism 224, a state determination mechanism 225, a state notification mechanism 226, and a unique information replacement mechanism 227. That is, the hook library mechanism 22a is obtained by adding the unique information replacement mechanism 227 to the hook library mechanism 22 shown in FIG. 2 and using the access management table 223a instead of the access management table 223 shown in FIG. Note that the functions of the state determination mechanism 225 and the state notification mechanism 226 are different from those of the above-described embodiment as described later.

  The unique information replacement mechanism 227 sets a return value (server unique information 23) to be returned to the application 130 in response to a call to the system function fun1 () for accessing the server unique information from the application 130 by a predetermined dummy. Replace with specific information (dummy information).

  FIG. 6 shows an example of the data structure of the access management table 223a. Each entry of the access management table 223a includes a first status column and a second status column for holding the status of the application 130 in addition to the server specific information column and the access count column. The first status column is used to hold the status of the application 130 when the server specific information 23 is returned to the application 130 without being replaced with dummy information. The second status column is used to hold the status of the application 130 when dummy information is returned to the application 130 instead of the server specific information 23.

  When failover occurs in the cluster system, the server-specific information is also changed as described above. Whether the change of the server specific information affects the application 130 can be confirmed by actually generating a failover. However, for that purpose, it is necessary to actually construct a cluster system using a plurality of servers.

  Therefore, assuming that a failover has occurred, the application 130 is restarted on the single server 10, and the server-specific information accessed by the application 130 (information unique to the server 10) is changed. It is conceivable to apply a method for confirming the operation of. However, if the server-specific information itself accessed by the application 130 is changed, there is a possibility that it affects other than the application 130 (that is, the application 130 that is the target of operation confirmation). For this reason, said method cannot be implemented easily.

  On the other hand, in the above embodiment, when the application 130 operates, the call of the system function fun1 () from the application 130 is hooked by the hook mechanism 222 of the hook library mechanism 22. Based on the hooked call, the system function fun1 () is actually called from the system library and the system function fun1 () is executed, thereby accessing information specific to the server 10 (server specific information 23). Is done. The server specific information 23 to be accessed is determined in advance. Therefore, in the above-described embodiment, when the call of the system function fun1 () from the application 130 is hooked by the hook mechanism 222 of the hook library mechanism 22, the server specific information 23 to be accessed by the application 130 at that time. Can be recognized (specified). The value of the server specific information 23 itself can be confirmed independently of the application 130 by the function of the OS.

  Therefore, in the first modified example, by utilizing this feature, a mechanism for verifying whether the change of the server specific information affects the application 130 by the server 10 alone is realized. Specifically, the unique information is replaced with dummy information (dummy unique information) only when the application 130 linked with the hook library refers to the unique information by calling a system function for accessing the server unique information. As a result, the above mechanism is realized. According to this mechanism, for example, from the state of the server 10 when the server specific information is replaced with dummy information, a cluster system is not constructed using a plurality of servers including the server 10, and the other on the server 10 It is possible to confirm whether the application (specific application) 130 greatly depends on the server-specific information, that is, the possibility of the application 130 having a great influence on clustering is not affected.

  The behavior of the application when the change of the server specific information affects the application is different for each application. For example, a change in the server specific information may cause a state where the application 130 cannot be started, an error in accessing the server specific information in the application 130, or an operation error in the application 130 itself. In such an application 130, by comparing the state of the application 130 before the change of the server specific information with the state of the application 130 after the change of the server specific information, the influence of the change of the server specific information on the application 130 is affected. It is possible to judge the degree.

  Hereinafter, the operation of the first modification will be described with reference to the flowchart of FIG. In FIG. 7, the same reference numerals are assigned to the processing steps equivalent to those in the flowchart of FIG.

  First, it is assumed that the system function fun1 () is called from the application 130 (step S1). In this case, the hook mechanism 222 of the hook library mechanism 22 hooks the call of fun1 () based on the hook library as in the above embodiment (step S2). Next, the hook library mechanism 22 calls the hook function FUN1 () set in the hook library in association with the function name of the hooked fun1 () (step S3). Then, the access management mechanism 224 increments the number of accesses held in the access management table 223 by 1 in association with the server specific information 23 to be accessed by executing the system function fun1 () (step S4).

  Next, the state determination mechanism 225 is activated. Based on the call of fun1 () hooked by the hook mechanism 222, the state determination mechanism 225 uses the server unique information 23 to be accessed by executing the fun1 () as dummy unique information (dummy information). It is determined whether to replace with (step S11). This determination is made based on, for example, whether the access count (count value) counted up by the access management mechanism 224 exceeds 1.

  If the number of accesses is 1, that is, if it does not exceed 1, the state determination mechanism 225 determines that replacement with dummy information (response with dummy information) is unnecessary (NO in step S11). ). In this case, the hook mechanism 222 calls fun1 () hooked by itself (step S6). Subsequent operations are the same as in the above embodiment, and fun1 () is called from the system library, and the server-specific information 23 is accessed by executing fun1 () (steps S6 to S8). Then, the accessed server specific information 23 is returned to the application 130 via the hook library mechanism 22 (the hook library mechanism 22) as a return value for the call of fun1 () (step S9). Then, the state determination mechanism 225 collects the state of the application 130 to which the server specific information 23 is returned, and obtains information indicating the collected state (first state information) as the access in which the specific information 23 is held. It is set in the first status column of the entry of the management table 223a (steps S12 and S13). Note that the technique itself for collecting the state of the application 130 has been known so far, and the description thereof will be omitted.

  On the other hand, if the number of accesses exceeds 1, the state determination mechanism 225 determines that replacement with dummy information is necessary (YES in step S11). In this case, the state determination mechanism 225 activates the unique information replacement mechanism 227.

  Then, the unique information replacement mechanism 227 passes predetermined dummy information (dummy unique information) to the hook mechanism 222 as a return value for the call of fun1 () (step S14). This means that in response to the call of fun1 () from the application 130, the server-specific information 23 that is accessed and returned to the application 130 when the fun1 () is actually executed is replaced (changed) with dummy information. ).

  The hook mechanism 222 passes the dummy information passed from the unique information replacement mechanism 227 to the application 130 as a return value corresponding to the call of fun1 () from the application 130. Then, the state determination mechanism 225 collects the state of the application 130 for which dummy information is returned, and obtains information indicating the collected state (second state information) as access management in which the server-specific information 23 is held. It is set in the second status column of the entry in the table 223a (steps S15 and S16).

  Next, the state determination mechanism 225 sets the second state information set in the second state column to the first state column set in the entry of the access management table 223a including the second state column. By comparing with the state information of 1, it is determined whether the dummy information (that is, the change of the server specific information) has affected the behavior of the application 130 (steps S17 and S18). The state notification mechanism 226 notifies the user of the determination result of the state determination mechanism 225 by the same method as in the above embodiment (step S19).

  In addition, in order to be able to confirm the case where the application 130 itself cannot be started due to the change to dummy information assuming failover, the application 130 may be restarted after the application 130 is once started. Here, when the application 130 is first started, the dummy information is not changed, and when the application 130 is restarted after the application 130 is stopped, that is, when the application 130 is restarted, the first time. The dummy information may be changed by accessing As a result, it is possible to examine the influence of the change to the dummy information on the activation of the application 130, that is, the influence on the activation of the application 130 when the server that executes the application 130 is switched due to the occurrence of failover.

  In the first modified example, in order to confirm the influence on the clustering of the application 130 with respect to the use of hidden server-specific information, a system function call for accessing server-specific information from the application 130 is hooked by the hook library mechanism 22a. The server-specific information to be referred to by the application 130 is replaced with dummy information (dummy unique information). If the use of server-specific information that has an effect has been confirmed in advance, if the dummy information is always used by using the mechanism for replacing the specific information described above, changes in the server-specific information due to server changes are concealed. Thus, the application 130 can be operated. The reason is as follows.

  First, a cluster system composed of a plurality of servers, for example, two servers # 1 and # 2 is assumed. The configurations of the servers # 1 and # 2 are the same as those of the server 10 in the first modified example. It is assumed that server-specific information unique to servers # 1 and # 2 is A and B, respectively, and dummy information is C.

  In this case, when the above-described application 130 operates on the server # 1 or # 2 and refers to the server-specific information, the dummy information C is returned to the application 130 by the hook library mechanism 22. As a result, the application 130 operates using the dummy information C regardless of whether the application 130 operates on the server # 1 or # 2. Therefore, the change of the server specific information due to the server change is concealed.

[Second Modification]
Next, a second modification of the above embodiment will be described with reference to FIGS.
The feature of the second modification is that a specific access pattern including server-specific information access from the application 130 is detected in the hook library mechanism 22a.

  First, as a general check operation when the application 130 is activated, the server 10 is identified by referring to a host ID unique to the server 10 on which the application 130 operates. The operation at the time of starting the application 130 is normally performed in the following procedure.

(1) Start the application 130.
(2) The host ID, which is information unique to the application 130, is read out by calling the system function getostid ().

  (3) The recorded host ID is read from the setting data (setting file data) of the application 130 by calling the read function read (fd, data). Here, fd and data in the read function are arguments, and the position of the data (host ID) to be read (ie, the read destination) and the position where the read data should be stored (ie, the storage location of the read data). ). In this case, data (host ID) recorded in “fd” is read and stored in “data”.

(4) The host ID read by calling getostid () is compared with the data read by calling read (fd, data).
(5) As a result of the comparison, if both data match, it is determined that the application 130 has been started on a normal server (that is, the application 130 has started normally). On the other hand, if the two data do not match, it is determined that the application 130 has been activated by an unauthorized server, and the activation of the application 130 has failed.

  In the second modification, each call of the read function read (fd, data), the system function gestostid (), and the write function write (fd, data) is called by the hook mechanism 222 of the hook library mechanism 22a. Is stored in advance in the hook library storage unit 221 of the hook library mechanism 22a. fd in the write function is an argument and indicates, for example, the position in the setting file (that is, the data write destination) where the data is to be written (recorded), and data is the position where the data is stored (that is, the data is written). Data storage source).

  When the read (fd, data) is hooked by the hook mechanism 222, the state determination mechanism 225 of the hook library storage unit 221 provides the API of the system library mechanism 21 to the storage location specified by data by calling getostid (). It is determined whether there is a host ID that matches the return value (host ID) returned from the mechanism 212. When the write (fd, data) is hooked by the hook mechanism 222, the state determination mechanism 225 also returns a return value (returned from the API providing mechanism 212 to the write destination specified by fd by calling getostid ()) ( It is determined whether there is a host ID that matches (host ID).

  The state determination mechanism 225 determines whether a specific condition is satisfied from these determination results. The specific condition is that gestidid () and read are called, and the same host ID is read by executing both functions. In addition, write is called between gestostid () and read, and the write of the write This is a specific access pattern in which the host ID is not included in the same write destination (fd) as in the case of read.

  The unique information replacement mechanism 227 determines that the specific condition is satisfied by the state determination mechanism 225, and when the application 130 is restarted and the call to getestid () from the application 130 is hooked by the hook mechanism 222. The dummy information is passed to the hook mechanism 222. That is, the unique information replacement mechanism 227 passes dummy information (for example, a host ID different from the host ID recognized in advance by the application 130) to the hook mechanism 222 as a return value for the call to getostid (). The hook mechanism 222 returns the dummy information passed from the unique information replacement mechanism 227 to the application 130 as a return value for the call to getostid (). The state determination mechanism 225 determines whether the dummy information has affected the behavior of the application 130 according to whether the activation of the application 130 has failed in the same manner as in the first modification.

  Obviously, when the access pattern from the application 130 matches that of the check operation when the application 130 is activated, the specific condition is not satisfied. In this case, the replacement with dummy information by the unique information replacement mechanism 227 is not performed. The reason is that even if replacement with dummy information is performed, dummy information is written to fd by the write function, and the dummy information written to the fd may be read by the read function. That is, the replacement with dummy information does not result in a simulation on the single server 10 assuming the occurrence of failover.

  Depending on the application 130, the order of the above (2) and (3), that is, the order of gestostid and read may be reversed. If the gettestid is first, as in the above example, the read data may be recorded in the hook library mechanism 22, for example, in the state determination mechanism 225 when the getostid is executed. On the other hand, when read is first, the host ID may be registered in advance in, for example, the state determination mechanism 225 as a monitoring (confirmation) target.

[Third Modification]
Next, a third modification of the above embodiment will be described with reference to FIGS.
In the third modification, it is assumed that the host ID is referred to after the general check operations (1) to (5) when the application 130 is started as described above. More specifically, in the third modification, when data handled by the application 130 is encrypted and recorded in the external storage device 13, information unique to the server 10 as an encryption key, for example, the host of the server 10 ID shall be used.

In this case, the application 130 generally executes the following processing following the above check operations (1) to (5).
(6) Reading host ID
(7) Encrypt any data using the read host ID as a key
(8) Writing (recording) the encrypted data to the external storage device 13
When data writing continues, the above processes (6) to (7) are repeated.

On the other hand, when reading data recorded in the external storage device 13, the application 130 executes the following processing.
(9) Reading data (encrypted data) from the external storage device 13
(10) Reading host ID
(11) Decoding of the read data using the read host ID as a key When the reading of data continues, the above processes (9) to (11) are repeated.

  As described above, the processes (6) to (8) and (9) to (11) are repeated according to the behavior of the application 130. Here, it is assumed that these processes are repeated and the host ID is read out each time. Therefore, the access management mechanism 224 records the access number of the host ID read by gestostid, the data read count by read, and the data write count by write in the access management table 223a, and a log (not shown). Record on the table. Note that the data structure of the access management table 223a is different from that shown in FIG. 6, and each entry of the access management table 223a includes a function name column in place of the server specific information column. Specifically, it is assumed that the access management table 223a includes entries in which function names of “gestid”, “read”, and “write” are set in the function name column.

  The state determination mechanism 225 determines whether access by calling “gestidid” and “read” or “gestidid” and “write” is repeated in a state close in time from the access management table 223a and the log table. This determination includes a threshold indicating the degree of proximity (first threshold) for determining whether they are close in time and a threshold for the number of repetitions (second threshold) for determining that they are repeated. Used.

  Here, the operation of encrypting 1000-character data with the host ID and writing the encrypted data to the external storage device 13, or reading the encrypted data written to the external storage device 13 and using the host ID It is assumed that a decoding operation is performed. Further, it is assumed that the data writing or reading (writing / reading) operation is not performed once for 1000 characters of data but is performed 10 times in units of 100 characters, for example. In this case, at first, reading of the host ID and writing of 100 characters of data, or reading of the host ID and reading of 100 characters of data are continuously performed. Based on this premise, the above-described determination by the state determination mechanism 225 is performed.

  First, it is determined whether the reading of the host ID and the first data writing / reading are close (continuing). Thereafter, when data writing / reading is executed, the data writing / reading is repeated for the same “fd”, that is, continuous (adjacent) data writing / reading is observed. In this case, the state determination mechanism 225 determines that the data writing / reading is affected by the host ID that is read first.

  If the state determination mechanism 225 determines that the access by calling gestostid and read or the access by calling gestostid and write is repeated in a state close in time, the state determination mechanism 225 estimates that these accesses are dependent. Therefore, the hook mechanism 222 uses the true host as a return value for the get id to be returned to the application 130 according to the timing and order of the access measured in advance while the access by calling the get id and write is repeated in close proximity in time. ID is used. On the other hand, while the access by calling calls to getidid and read is repeated close in time, the hook mechanism 222 uses dummy information as a return value for the getidid to be returned to the application 130 in accordance with the access timing and order measured in advance. Is used.

  Then, the application 130 fails to decrypt the read data in the repeated access by calling “gestidid” and “read”. In this case, the application 130 outputs a read error to a log file that represents the execution history of the application 130. The state determination mechanism 225 can determine that the application 130 cannot be clustered by referring to the log file. Note that the status notification mechanism 226 may notify the user of this log file so that the user can determine that the application 130 cannot be clustered.

  In addition, this invention is not limited to the said embodiment or its modification example as it is, A component can be deform | transformed and embodied in the range which does not deviate from the summary in an implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment or its modification. For example, you may delete a some component from all the components shown by embodiment or its modification.

The block diagram which shows the hardware constitutions of the server computer for cluster systems which concerns on one Embodiment of this invention. The block diagram which mainly shows a function structure of the server computer shown by FIG. The figure which shows the data structure example of the access management table 223 shown by FIG. The flowchart for demonstrating the operation | movement of the embodiment. The block diagram which mainly shows a function structure of the server computer applied in the 1st modification of the embodiment. FIG. 6 is a diagram showing an example data structure of an access management table 223a shown in FIG. The flowchart for demonstrating operation | movement of the said 1st modification.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 10 ... Server (server computer for cluster systems), 11 ... CPU, 12 ... Main memory, 13 ... External storage device, 21 ... System library mechanism, 22 ... Hook library mechanism, 23 ... Server specific information, 130 ... Application (specific application) , 131 ... Application clusterability determination support program, 211 ... System library storage unit, 212 ... API (application program interface) providing mechanism, 221 ... Hook library storage unit, 222 ... Hook mechanism, 223, 223a ... Access management table 224 ... access management mechanism, 225 ... state determination mechanism, 226 ... state notification mechanism, 227 ... specific information replacement mechanism.

Claims (5)

In a server computer for a cluster system that can execute a specific application to provide services to users,
System library storage means for storing in advance a system library including a set of first application program interfaces for acquiring server-specific information specific to the server computer;
Application program interface providing means for receiving a call to the first application program interface and providing the first application program interface to a caller;
Hook library storage means pre-stored with a hook library including a set of second application program interfaces associated with the first application program interface and defining an operation when the first application program interface is hooked; ,
Hook means for hooking a call to the first application program interface from the specific application based on the hook library stored in the hook library storage means, wherein the first hooked in the hook library Hook means for invoking the hooked first application program interface according to the second application program interface associated with the application program interface;
An access management table used to record access to the server specific information based on a call of the first application program interface from the specific application;
An access management means for recording access to the server specific information based on the call of the first application program interface in the access management table when the call of the first application program interface is hooked by the hook means; ,
A server computer for a cluster system, comprising: status notification means for notifying a user of information indicating a status of access to the server-specific information from the specific application indicated by the access management table. The access management table has an entry for recording the number of accesses to the server specific information, prepared for each server specific information,
The access management means corresponds to server-specific information that is accessed based on the hooked first application program interface call when the hook application hooks the first application program interface call. The server computer for a cluster system according to claim 1, wherein the number of accesses recorded in the entry of the access management table is incremented. Further comprising state determination means for determining whether the number of accesses after being incremented by the access management means exceeds a predetermined threshold,
The cluster system according to claim 2, wherein the state notification unit notifies the user of the determination result of the state determination unit as information indicating a status of access to the server specific information from the specific application. Server computer. When the call of the first application program interface is hooked by the hook means, instead of the server specific information to be accessed based on the call of the first application program interface, the server specific information is A unique information replacement means for returning the specific information of the different dummy to the specific application by the hook means as a return value for calling the first application program interface;
The state determination means monitors the operating state of the specific application to which the dummy unique information is returned, and determines whether there is an adverse effect during cluster configuration of the specific application based on whether or not an abnormality has occurred. The server computer for a cluster system according to any one of claims 1 to 3. A server computer for a cluster system capable of executing a specific application for providing a service to a user, including a set of first application program interfaces for acquiring server-specific information specific to the server computer A system library storing means for storing a system library in advance; an application program interface providing means for receiving a call to the first application program interface and providing the first application program interface to a caller; and the first application A second application program interface which is associated with the program interface and defines an operation when the first application program interface is hooked Hook library storage means for storing a hook library in advance, including a set of face, the cluster system for a server computer including an access management table,
Hooking a call to the first application program interface from the specific application based on the hook library stored in the hook library storage means;
Invoking the hooked first application program interface;
Recording the access to the server specific information based on the hooked first application program interface call in the access management table;
An application clusterability determination support program for executing a step of notifying a user of information indicating a status of access to the server-specific information from the specific application indicated by the access management table.

Images