WO2012063301A1 - Computer system, multitenant control method, and multitenant control program - Google Patents

Abstract

This computer system is provided with: a client device that issues a transaction processing request; and a server device that issues a transaction process corresponding to the transaction processing request issued by the client device. The server device is provided with: a transaction management table that, for each type of transaction processing request, associates ID information of the transaction processing request with a connection path to another resource to which to connect when executing the transaction process corresponding to the transaction processing request; a reception unit that receives the transaction processing request issued by the client device; and a connection management unit that, each time a transaction processing request is received by the reception unit, refers to the transaction management table, and using the connection path corresponding to the type of transaction processing request received, connects to the other resource corresponding to the connection path.

Description

Computer system, multi-tenant control method, and multi-tenant control program

The present invention relates to a computer system, a multi-tenant control method, and a multi-tenant control program.

A so-called multi-tenant system in which a plurality of user companies share and use the same business system is known (see Non-Patent Document 1 and Non-Patent Document 2).

Each user company using a multi-tenant system shares the business system with other user companies, thereby reducing the costs associated with computing resources and operations compared to building their own business system alone. Can do. Various inventions have been made in relation to such a multi-tenant system (see Patent Document 1 and Patent Document 2).

Patent Document 1 discloses a technology in which independent resources (calculation resources) are allocated to a plurality of user companies, and the allocation is automatically changed in real time according to a load. Patent Document 2 discloses a technique for changing test setting information to production setting information for the purpose of adapting a test environment to a production environment.

Japanese Patent Laid-Open No. 2002-24192 JP 2010-86110 A

By the way, with the technique disclosed in Patent Document 1, for example, when changing the resource allocation destination from company A to company B, the resources allocated to company A are once assigned to company B and then allocated to company B.

However, since resources are not allocated once in this way, there is a problem that resources cannot be allocated flexibly and quickly to each user company.

Further, when a resource allocated to the company A (for example, an application server, hereinafter referred to as “AP server”) is allocated to the company B without being assigned, the problem described below occurs. That is, in this case, processing requests for the company A and processing requests for the company B can be mixed on the AP server. Then, especially when the process for the company A and the process for the company B are connected to different resources (for example, a database server; hereinafter referred to as “DB server”), the AP server responds to a process request for the company A. On the other hand, an error response is made and the service level for the company A is lowered.

In addition, the technology disclosed in Patent Document 1 has a complicated configuration in which a load balancer is provided between the AP server and the DB server.

The present invention provides a computer system, a multi-tenant control method, and a multi-tenant control program capable of changing resource allocation flexibly and quickly with a simple configuration in consideration of the above-described problems. Objective.

A typical example of the invention disclosed in the present application is as follows. That is, a computer system comprising: a client device that issues a transaction processing request; and a server device that executes a transaction process corresponding to the transaction processing request issued by the client device, wherein the server device For each type of processing request, a transaction management table that associates the identification information of the transaction processing request with a connection path to another resource to be connected when executing the transaction processing corresponding to the transaction processing request; A receiving unit that receives a transaction processing request issued by the client device, and each time a transaction processing request is received by the receiving unit, the transaction management table is referred to and the received transaction processing request is received. Using the connection path corresponding to the type of emission processing request, characterized by comprising a connection management unit to be connected to other resources corresponding to the connection path, the.

According to the present invention, resource allocation can be changed flexibly and quickly with a simple configuration.

It is a conceptual diagram of the business processing in the application sharing system of the AP server of the embodiment of the present invention. It is a figure which shows the structural example of the computer system of the multitenant system of the 1st Embodiment of this invention. It is a block diagram which shows the structural example of AP server of the 1st Embodiment of this invention. It is a block diagram which shows the structural example of DB server of the 1st Embodiment of this invention. It is a figure explaining the principle of the multi-tenant control method of the 1st Embodiment of this invention. It is a block diagram which shows the structural example of the computer of the 1st Embodiment of this invention. It is a 1st figure explaining the production | generation method of the transaction management table of the 1st Embodiment of this invention. It is a 2nd figure explaining the production | generation method of the transaction management table of the 1st Embodiment of this invention. It is a 3rd figure explaining the production | generation method of the transaction management table of the 1st Embodiment of this invention. It is a 4th figure explaining the production | generation method of the transaction management table of the 1st Embodiment of this invention. It is a flowchart which shows the process sequence of the business UAP of the 1st Embodiment of this invention. It is a figure for demonstrating operation | movement of the DB server connection management part of the 1st Embodiment of this invention. It is a flowchart which shows the 1st example of the process sequence of the server reconnection of the 1st Embodiment of this invention. It is a flowchart which shows the 2nd example of the process sequence of the server reconnection of the 1st Embodiment of this invention. It is a flowchart which shows the 3rd example of the process sequence of the server reconnection of the 1st Embodiment of this invention. It is a figure which shows the structural example of the computer system of the multitenant system of the 2nd Embodiment of this invention. It is a block diagram which shows the structural example of the DB server of the 2nd Embodiment of this invention. It is a figure for demonstrating operation | movement of the DB server connection management part of the 2nd Embodiment of this invention. It is a figure which shows another example of the transaction management table of the 2nd Embodiment of this invention. It is a figure which shows another example of the transaction management table of the 2nd Embodiment of this invention. It is a flowchart which shows the 1st example of the process sequence of the server reconnection of the 2nd Embodiment of this invention. It is a flowchart which shows the 2nd example of the process sequence of the server reconnection of the 2nd Embodiment of this invention. It is a flowchart which shows the 3rd example of the process sequence of the server reconnection of the 2nd Embodiment of this invention. It is a block diagram which shows the structural example of the computer of the 3rd Embodiment of this invention. It is a figure for demonstrating the 1st example of the identification method of the classification of the transaction processing request of each embodiment of this invention. It is a figure for demonstrating the 2nd example of the identification method of the classification of the transaction processing request of each embodiment of this invention. It is a figure for demonstrating the 1st example of the calling method of the DB server connection management part of each embodiment of this invention. It is a figure for demonstrating the 2nd example of the calling method of the DB server connection management part of each embodiment of this invention. It is a block diagram which shows another example of a structure of AP server of each embodiment of this invention. It is a block diagram which shows another example of a structure of AP server of each embodiment of this invention. It is a block diagram which shows another example of a structure of DB server of each embodiment of this invention. It is a block diagram which shows another example of a structure of DB server of each embodiment of this invention.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a conceptual diagram of business processing in the application sharing method of the AP server 103 according to the embodiment of this invention. The AP server 103 is a multi-tenant server device that can be used by a plurality of user companies (hereinafter referred to as “tenants”). The AP server 103 includes an AP common processing unit 104, a customization unit 105, middleware 106, and an OS (Operating System) 107.

The AP common processing unit 104 is an application program that executes common processing among tenants. The AP common processing unit 104 first receives a transaction processing request 101 from each tenant (not shown).

The customization unit 105 is an application program that is customized for each tenant and executes processing for each tenant. The customization unit 105 includes a processing unit 105a for tenant α that executes processing for tenant α and a processing unit 105b for tenant β that executes processing for tenant β.

For example, when the processing request 101 is issued by the tenant α, the processing unit 105a for the tenant α executes the processing. On the other hand, when the processing request 101 is issued by the tenant β, the processing unit 105b for the tenant β executes the processing.

The AP common processing unit 104 returns the result processed by the customization unit 105 (processing result 102) to the response transmission destination.

The AP common processing unit 104 and the customization unit 105 as described above operate on the middleware 106 and the OS 107 that are shared and used by a plurality of tenants.

(First embodiment)
FIG. 2 is a diagram illustrating a configuration example of the multi-tenant computer system 1 according to the first embodiment of this invention. This computer system 1 is a multi-tenant environment for tenants α and β.

The computer system 1 shown in FIG. 2 includes terminals 206a and 206b, a load balancer 209, a plurality of Web servers 210a and 210b, a plurality of AP servers 211a and 211b, and a plurality of DB servers 212a and 212b.

The terminal 206a is a client terminal (computer device) used by the user of the tenant α. On the other hand, the terminal 206b is a client terminal used by the user of the tenant β. These terminals 206 a and 206 b are connected to a WAN (Wide Area Network) 208 via a network line 207. The terminals 206a and 206b issue transaction processing requests (processing requests for data reference etc. of the DB servers 212a and 212b) based on user instructions.

The load balancer 209 is a load balancer that evenly allocates processing requests for transactions issued by the terminals 206a and 206b to the plurality of Web servers 210a and 210b.

The Web server 210a is a Web server device for the tenant α that processes a request by the user of the tenant α. On the other hand, the Web server 210b is a Web server device for the tenant β that processes a request by the user of the tenant β.

The AP server 211a is an application server device for the tenant α that processes requests from the Web server 210a. On the other hand, the AP server 211b is an application server device for the tenant β that processes the request from the Web server 210b. The configuration of the AP servers 211a and 211b will be described later.

The DB server 212a is a database server for tenant α. Only the AP server 211a can be connected to the DB server 212a. On the other hand, the DB server 212b is a database server for the tenant β. Only the AP server 211b can be connected to the DB server 212b. The configuration of the DB servers 212a and 212b will be described later.

With the configuration described above, in the computer system 1, the terminals 206a and 206b issue a message related to a transaction processing request. The issued electronic message is transmitted to the corresponding Web servers 210a and 210b through the network line 207 and the like. The Web servers 210a and 210b that have received the electronic message transmit the corresponding AP servers 211a and 211b. Thereafter, the AP servers 211a and 211b connect to the DB servers 212a and 212b, respectively, and execute transaction processing corresponding to the received electronic message.

FIG. 3 is a block diagram illustrating a configuration example of the AP server 211a (211b) according to the first embodiment of this invention.

As shown in FIG. 3, the AP server 211a (211b) shares the OS 107 and middleware 106 among the tenants, and shares part or all of the AP 104 between the tenants. The AP 104 includes processing units 105a and 105b for the tenants α and β. Such a configuration is effective in terms of cost merit and AP maintainability.

With such a configuration, the AP server 211a (211b) functions as a common entrance that accepts transaction processing requests from the tenants α and β, and can execute both transaction processing requests for the tenants α and β. it can. That is, the AP server 211a (211b) can switch between the tenant α and the tenant β.

FIG. 4 is a block diagram illustrating a configuration example of the DB servers 212a and 212b according to the first embodiment of this invention.

4, the DB server 212a includes a DB table 203a, a DBMS (DataBase Management System) instance 204a, and an OS 205a. Similarly, the DB server 212b includes a DB table 203b, a DBMS instance 204b, and an OS 205b.

DB tables 203a and 203b are database tables exclusively owned by tenant α and tenant β. The DBMS instances 204a and 204b are database management system instances exclusively owned by the tenant α and the tenant β. The OSs 205a and 205b are operating systems dedicated to the tenant α and the tenant β, respectively.

As described above, the DB servers 212a and 212b are an individual DB system that separates all of the OS, the DBMS instance, and the DB table for each tenant. This individual DB method is particularly effective when each tenant is a financial institution or medical institution and the data to be stored in the DB servers 212a and 212b requires high confidentiality such as customer management data.

FIG. 5 is a diagram for explaining the principle of the multi-tenant control method according to the embodiment of the present invention. According to the present embodiment, the AP server 103 in FIG. 1 includes the business UAP processing unit 301 and the DB server connection management unit 302 shown in FIG.

The business UAP processing unit 301 processes a UAP (User Application Program) in response to a transaction processing request issued by each tenant (not shown). The business UAP processing unit 301 reflects the change when the DB server connection management unit 302 changes the connection destination DB server while processing the UAP.

The DB server connection management unit 302 refers to the transaction management table 303 to determine connection destination DB servers 212a and 212b corresponding to the types of transaction processing requests (for example, types of tenants α and β).

Details of these business UAP processing unit 301 and DB server connection management unit 302 will be described later. The business UAP processing unit 301 and the DB server connection management unit 302 can change the allocation of resources (here, the connection destination DB servers 212a and 212b) flexibly and quickly with a simple configuration.

FIG. 6 is a block diagram illustrating a configuration example of the computer 401 according to the first embodiment of this invention. This computer 401 corresponds to the AP server 103 of FIG. The computer 401 is a computer device including a main storage device 402, a CPU (Central Processing Unit) 403, an output device 404, an input device 405, an auxiliary storage device 419, and a drive device 420, which are mutually connected by a bus.

The main storage device 402 is a storage device such as a RAM (Random Access Memory) that reads and stores programs such as the OS 406 and the online system 407 stored in the auxiliary storage device 419 when the computer 401 is activated. The main storage device 402 also stores files necessary for program execution.

The CPU 403 is an arithmetic processing device that executes a program stored in the main storage device 402. The output device 404 is an output device (for example, a display) that provides a user interface. The input device 405 is an input device (for example, a keyboard or a mouse) that provides a user interface.

The auxiliary storage device 419 is a storage device such as an HDD (Hard Disk Drive) that stores programs, files, data, and the like. The drive device 420 is a device that reads a program stored in the storage medium 421. The program read by the drive device 420 is installed in the auxiliary storage device 419. The storage medium 421 is a storage medium such as a USB (Universal Serial 、 Bus) memory or an SD memory card in which the above-described program is recorded.

Hereinafter, the online system 407 will be described. The online system 407 includes a message reception unit 409, a message transmission unit 411, a UAP control unit 412, a business UAP processing unit 301, and a DB server connection management unit 302. The online system 407 corresponds to the AP common processing unit 104, the customization unit 105, and the middleware 106 in FIG.

The message receiving unit 409 receives the input message 408 transmitted from each tenant that is the processing request source. The received input message 408 is sent to the UAP control unit 412. The execution UAP determination unit 413 determines a user application to be executed based on the input message 408. The scheduler 414 schedules the user application to be executed.

The business UAP processing unit 301 executes a user application to be executed according to the schedule generated by the scheduler 414.

Specifically, first, the DB server connection management unit 302 is called, and the tenant information corresponding to the input message 408 (information of the tenant that transmitted the input message 408) is passed to the DB server connection management unit 302. Then, the tenant information receiving unit 415 receives this tenant information. Thereafter, the target server search unit 416 searches the DB server corresponding to the tenant information with reference to the transaction management table 303. The transaction management table 303 is a table for managing correspondence information between tenant information and a connection destination DB server. Thereafter, the server reconnecting unit 417 connects to the searched DB server when the DB server searched by the target server searching unit 416 and the DB server that has already been connected are different.

In this way, the DB server connection management unit 302 establishes a connection with a connection destination DB server (not shown) according to the input message 408. Thereafter, the business UAP processing unit 301 refers to the DB server with which the connection has been established, and executes the user application to be executed.

The UAP control unit 412 sets the output message 410 to be transmitted to the response transmission destination based on the processing result of the business UAP processing unit 301. The message transmission unit 411 transmits the set output message 410 to the response transmission destination.

FIG. 7A is a first diagram illustrating a method for generating the transaction management table 303 according to the first embodiment of this invention.

The definition file 501 shown in FIG. 7A defines that a transaction processing request from the tenant α is connected to the DB server D1, and a transaction processing request from the tenant β is connected to the DB server D2. It is a file.

The definition file 501 is stored in the auxiliary storage device 419. The CPU 403 generates a transaction management table 303 based on the definition file 501 stored in the auxiliary storage device 419.

FIG. 7B is a second diagram illustrating the method for generating the transaction management table 303 according to the first embodiment of this invention.

The command statement 502 shown in FIG. 7B indicates that the transaction processing request from the tenant α is connected to the DB server D1, and the transaction processing request from the tenant β is connected to the DB server D2.

The command statement 502 is input by the input device 405. The CPU 403 generates a transaction management table 303 based on the input command statement 502.

FIG. 7C is a third diagram illustrating a method for generating the transaction management table 303 according to the first embodiment of this invention.

The command statement 503 shown in FIG. 7C indicates that the transaction processing request from the tenant α is connected to the DB server D1, and the transaction processing request from the tenant β is connected to the DB server D2.

The command statement 503 is input interactively by the input device 405 on the screen displayed on the output device 404 (display). The CPU 403 generates a transaction management table 303 based on the input command statement 503.

FIG. 7D is a fourth diagram illustrating a method for generating the transaction management table 303 according to the first embodiment of this invention.

A GUI (Graphical User Interface) 504 shown in FIG. 7D allows a combination of a tenant (Key) and a connection destination DB server (Host) to be selected by a list box.

The GUI 504 is displayed on the output device 404 (display). The user inputs the correspondence between the tenant and the DB server by using the input device 405 on the screen of the GUI 504. The CPU 403 generates a transaction management table 303 based on the user input.

FIG. 8 is a flowchart showing the processing procedure of the business UAP according to the embodiment of the present invention. Here, the processing procedure of the business UAP executed in the online system 407 will be described.

First, in step S601, the UAP control unit 412 receives the input message 408 received by the message reception unit 409 (S601). Next, in step S602, the UAP control unit 412 starts a transaction corresponding to the input message 408 (S602).

Thereafter, in step S603, the execution UAP determination unit 413 specifies the tenant information corresponding to the input message 408 received in step S601, that is, the tenant from which the input message 408 has been transmitted (S603). The process in step S603 will be described later with reference to FIGS. 17A and 17B.

Thereafter, in step S604, the business UAP processing unit 301 calls the DB server connection management unit 302 (S604). In S604, the business UAP processing unit 301 calls the DB server connection management unit 302 and passes the tenant information specified in Step S603 to the DB server connection management unit 302. The DB server connection management unit 302 determines a DB server to be connected based on the received tenant information. A method for calling the DB server connection management unit 302 will be described later with reference to FIGS. 18A and 18B. A method for determining a DB server to be connected will be described with reference to FIGS. 9 and 10A to 10C.

Thereafter, in steps S605 to S607, the business UAP processing unit 301 executes the respective SQL statements in the input message 408 for the DB server that has been determined as the DB server to be connected in step S604 and has been connected (S605). To S607). Thereafter, in step S608, the UAP control unit 412 commits the transaction started in step S602 (S608).

Thereafter, in step S609, the UAP control unit 412 sets the output message 410 to be transmitted to the response transmission destination based on the processing result of the business UAP processing unit 301 (S609). The set output message 410 is transmitted to the response transmission destination by the message transmission unit 411.

Through the above processing, the online system 407 determines a DB server to be connected based on the received input message 408 every time an input message 408, that is, a transaction processing request is received. Thereby, even if transaction processing requests from the tenants α and β are mixed in the AP servers 211a and 211b, the allocation of the DB servers 213a and 213b can be changed flexibly and quickly.

In this online system 407, each AP server 211a, 211b determines a DB server to be connected based on the received input message 408 (transaction processing request), but this is not a limitation. For example, each of the Web servers 210a and 210b may determine the AP servers 211a and 211b to be connected based on the received input message 408, or can be applied to other forms.

FIG. 9 is a diagram for explaining the operation of the DB server connection management unit 302 according to the first embodiment of this invention. The flowchart on the left side of FIG. 9 shows the control logic of the tenant information receiving unit 415, the target server search unit 416, and the server reconnection unit 417. The table on the right side of FIG. 9 shows an example of the transaction management table 303.

As shown in Table 701, the transaction management table 303 associates that the connection destination DB server when the tenant is α is D1, and the connection destination DB server when the tenant is β is D2. Yes. That is, the transaction management table 303 is a connection between the tenant, which is information for identifying a transaction processing request, and other resources (in this case, a DB server) to be connected when executing the transaction processing corresponding to the transaction processing request. Manages correspondence information between host names that are paths. Hereinafter, the left flowchart will be described.

First, in step S701, the tenant information receiving unit 415 receives tenant information corresponding to the input message 408 from the business UAP processing unit 301 (S701).

Next, in step S702, the target server search unit 416 refers to the transaction management table 303, searches for and selects a connection destination DB server corresponding to the tenant received in step S701 (S702). In the example of FIG. 7, when the tenant information received in step S701 indicates the tenant α, the connection destination DB server D1 is selected. On the other hand, if the tenant information received in step S701 indicates the tenant β, the connection destination DB server D2 is selected.

Thereafter, in step S703, the server reconnection unit 417 determines whether or not the connection destination DB server selected in step S702 is different from the currently connected connection destination DB server (S703). When the selected connection destination DB server is different from the currently connected connection destination DB server (YES in S703), the server reconnection unit 417 connects to the new connection destination DB server (S704). Step S704 will be described later in detail with reference to FIGS. 10A to 10C. On the other hand, if the selected connection destination DB server is the same as the currently connected connection destination DB server (NO in S703), there is no need to change the connection destination DB server, so the server reconnection unit 417 does nothing. The process ends without executing.

FIG. 10A is a flowchart illustrating a first example of a server reconnection processing procedure according to the first embodiment of this invention. Here, a first example of the process in step S704 in FIG. 9, that is, the process in which the server reconnection unit 417 connects to a new connection destination DB server will be described.

First, in step S801, the server reconnection unit 417 discards the connection with the currently established connection destination DB server (S801). In step S802, the server reconnection unit 417 establishes a connection with the connection destination DB server corresponding to the type of transaction processing request (S802). Here, the connection with the connection destination DB server selected in step S702 of FIG. 9 is established. Thereafter, in step S803, the server reconnection unit 417 declares the connection established in step S802 as a connection to be actually used (S803).

Through the processing described above, the server reconnection unit 417 can connect to a new connection destination DB server without increasing the number of connections of the connection destination DB server.

FIG. 10B is a flowchart illustrating a second example of the server reconnection processing procedure according to the first embodiment of this invention. Here, a second example of the process in step S704 of FIG. 9, that is, the process in which the server reconnection unit 417 connects to a new connection destination DB server will be described.

First, in step S804, the server reconnecting unit 417 holds the connection with the currently established connection destination DB server (S804). Next, in step S805, the server reconnection unit 417 establishes a connection with the connection destination DB server corresponding to the type of the transaction processing request separately from the connection held in step S804 (S805). Here, a new connection is established with the connection destination DB server selected in step S702 of FIG. Thereafter, in step S806, the server reconnection unit 417 declares the connection established in step S805 as a connection to be actually used (S806).

Through the processing described above, the server reconnection unit 417 is connected to the new connection destination DB server while maintaining the connection with the currently established connection destination DB server. Therefore, the connection with the connection destination DB server that is currently established can be reused.

FIG. 10C is a flowchart illustrating a third example of a server reconnection processing procedure according to the first embodiment of this invention. Here, a third example of the process in step S704 in FIG. 9, that is, the process in which the server reconnection unit 417 connects to a new connection destination DB server will be described.

First, in step S807, the server reconnection unit 417 determines whether or not there is a connection corresponding to the type of transaction processing request among the connections with a plurality of currently established connection destination DB servers (connection destination DB server group). Is determined (S807). If there is no connection corresponding to the type of transaction processing request (NO in S807), the process proceeds to step S808.

In step S808, the server reconnection unit 417 determines whether or not the number of currently established connections is greater than a predetermined threshold (S808). The threshold here is the maximum number of connections that the business UAP processing unit 301 can tolerate.

If the number of currently established connections is greater than the threshold (YES in S808), the number of connections cannot be increased, so the process proceeds to step S809, where the server reconnection unit 417 determines the number of connections that are currently established. Among them, the connection with a long elapsed time from the last use (LRU: Least Recently Used) is discarded (S809).

On the other hand, if the number of currently established connections is smaller than the threshold value (NO in S808), the number of connections can be increased, so the process proceeds to step S810, and the server reconnection unit 417 first establishes the currently established connection. Is held (S810). Thereafter, the process proceeds to step S811, and the server reconnection unit 417 establishes a connection with the connection destination DB server corresponding to the type of the transaction processing request (S811). Here, a new connection is established with the connection destination DB server selected in step S702 of FIG.

If there is a connection corresponding to the type of transaction processing request in step S807 (YES in step S807), the process advances to step S812, and the server reconnection unit 417 changes the currently established connection to the type of transaction processing request. Is switched to the connection corresponding to (S807). Here, the connection is switched to the connection destination DB server selected in step S702 of FIG.

In step S813, the server reconnection unit 417 declares the connection established in step S811 or the connection switched in step S812 as a connection to be actually used (S813).

Through the processing described above, the server reconnection unit 417 can connect to a new connection destination DB server without increasing the number of connections of the connection destination DB server to a certain number or more. Further, the connection to the new connection destination DB server is made while maintaining the connection with the connection destination DB server that is currently established. Therefore, the connection with the connection destination DB server that is currently established can be reused.

According to the first embodiment described above, even when processing requests for the tenant α and processing requests for the tenant β are mixed in each AP server 211a (211b), it is flexible and quick with a simple configuration. The allocation of the DB servers 213a and 213b can be changed.

(Second Embodiment)
In the first embodiment described above, a mode has been described in which one DB server is provided for each tenant (see FIG. 2, the DB server 212 a for the tenant α and the DB server 212 b for the tenant β). Here, a mode in which a plurality of DB servers are provided for each tenant will be described. In the following description, the same components as those in the first embodiment described above are denoted by the same reference numerals, and redundant description is omitted as appropriate.

FIG. 11 is a diagram illustrating a configuration example of the multi-tenant computer system 1 according to the second embodiment of this invention. This computer system 1 is a multi-tenant environment for tenants α and β. Here, the same components as those in FIG. 2 are denoted by the same reference numerals, and redundant description will be omitted as appropriate.

As shown in FIG. 11, a plurality of DB servers 213a and 213b are provided. Each DB server 213a is a database server for tenant α. Only the AP server 211a can be connected to each DB server 213a. On the other hand, each DB server 213b is a database server for tenant β. Only the AP server 211b can be connected to each DB server 212b. The configuration of the DB servers 213a and 213b will be described later.

With the configuration described above, in the computer system 1, the terminals 206a and 206b issue a message related to a transaction processing request. The issued electronic message is transmitted to the corresponding Web servers 210a and 210b through the network line 207 and the like. The Web servers 210a and 210b that have received the electronic message transmit the corresponding AP servers 211a and 211b. Thereafter, the AP servers 211a and 211b connect to the DB servers 213a and 213b, respectively, and execute transaction processing corresponding to the received electronic message.

Since the configuration of the AP servers 211a and 211b according to the second embodiment of the present invention is the same as that of the first embodiment (see FIG. 3), description thereof is omitted here.

FIG. 12 is a block diagram illustrating a configuration example of the DB servers 213a and 213b according to the second embodiment of this invention. Here, the same components as those in FIG. 4 are denoted by the same reference numerals, and redundant description will be omitted as appropriate.

12, the DB server 213a includes a DB table 203a, a DBMS instance 204a, and an OS 205a. Similarly, the DB server 213b includes a DB table 203b, a DBMS instance 204b, and an OS 205b.

In this way, each of the plurality of DB servers 213a and 213b is an individual DB system that separates all of the OS, DBMS instances, and DB tables for each tenant. This individual DB method is particularly effective when each tenant is a financial institution or medical institution and the data to be stored in the DB servers 213a and 213b requires high confidentiality such as customer management data.

Since the configuration of the computer 401 according to the second embodiment of the present invention is the same as that of the first embodiment (see FIG. 6), the description thereof is omitted here.

FIG. 13 is a diagram for explaining the operation of the DB server connection management unit 302 according to the second embodiment of this invention. The flowchart on the left side of FIG. 13 shows the control logic of the tenant information receiving unit 415, the target server search unit 416, and the server reconnection unit 417. The table on the right side of FIG. 13 shows an example of the transaction management table 303.

In the transaction management table 303, as shown in the table 1001, the connection destination DB servers when the tenant is α are D1 (load level 0), D2 (load level 2), and D3 (load level 2). The connection destination DB server in the case of β is associated with D4 (load level 1) and D5 (load level 1). The load level is an index indicating the degree of load on each connection destination DB server. For example, it is determined based on the number of requests per time sent to each connection destination DB server.

That is, the transaction management table 303 is a connection between the tenant, which is information for identifying a transaction processing request, and other resources (in this case, a DB server) to be connected when executing the transaction processing corresponding to the transaction processing request. It manages correspondence information between host names that are paths and load levels. The load level is used to select one connection path from a plurality of connection paths. Details will be described later. Since the flowchart on the left side is the same as the flowchart of FIG. 9, the description thereof is omitted here.

FIG. 14A is a diagram showing another example of the transaction management table 303 according to the second embodiment of this invention.

As shown in a table 1002, the transaction management table 303 includes a tenant, which is information for identifying a transaction processing request, and other resources (here, a DB server) to be connected when executing a transaction processing corresponding to the transaction processing request. The correspondence information between the host name, which is a connection path to (), and the number of connections is managed. The number of connections is an index indicating the degree of resource occupancy (here, the number of simultaneous connections) in each connection destination DB server. This number of connections is used to select one connection path from a plurality of connection paths, similar to the load level described above. Details will be described later.

FIG. 14B is a diagram showing another example of the transaction management table 303 according to the second embodiment of this invention.

As shown in a table 1003, the transaction management table 303 includes a tenant, which is information for identifying a transaction processing request, and other resources (here, a DB server) to be connected when executing a transaction processing corresponding to the transaction processing request. The correspondence information between the host name which is the connection path to the account number and the account number key range is managed. The account number key range is an index indicating the range of data stored in each connection destination DB server. This account number key range is used to select one connection path from a plurality of connection paths, similarly to the load level and the number of connections described above. Details will be described later.

FIG. 15A is a flowchart illustrating a first example of a server reconnection processing procedure according to the second embodiment of this invention. Here, a first example of the process in step S704 in FIG. 13, that is, the process in which the server reconnection unit 417 connects to a new connection destination DB server will be described. Here, the same components as those in FIG. 10A are denoted by the same reference numerals, and redundant description will be omitted as appropriate.

In step S1102, the server reconnection unit 417 refers to the transaction management table 303 (see FIG. 13), and among the connection destination DB servers corresponding to the transaction processing request type, any one connection destination with the lowest load level. A connection with the DB server is established (S1102). Here, a connection is established with the connection destination DB server having the lowest load level among the connection destination DB servers selected in step S702 of FIG.

Through the processing described above, the server reconnection unit 417 selects and connects one connection destination DB server with the lowest load level from a plurality of connection destination DB servers without increasing the number of connections of the connection destination DB servers. be able to.

FIG. 15B is a flowchart illustrating a second example of a server reconnection processing procedure according to the second embodiment of this invention. Here, a second example of the process in step S704 of FIG. 13, that is, the process in which the server reconnection unit 417 connects to a new connection destination DB server will be described. In addition, the same code | symbol is attached | subjected to the component similar to FIG. 10B here, and the overlapping description is abbreviate | omitted suitably.

In step S1105, the server reconnection unit 417 refers to the transaction management table 303 (see FIG. 13), and apart from the connection held in step S804, among the connection destination DB servers corresponding to the transaction processing request type, A connection with any one connection destination DB server having the lowest load level is established (S1105). Here, a connection is newly established with the connection destination DB server having the lowest load level among the connection destination DB servers selected in step S702 of FIG.

Through the processing described above, the server reconnection unit 417 selects one connection destination DB server having the lowest load level from the plurality of connection destination DB servers while maintaining the connection with the currently established connection destination DB server. Connected. Therefore, the connection with the connection destination DB server that is currently established can be reused.

FIG. 15C is a flowchart illustrating a third example of a server reconnection processing procedure according to the second embodiment of this invention. Here, a third example of the process in step S704 in FIG. 13, that is, the process in which the server reconnection unit 417 connects to a new connection destination DB server will be described. In addition, the same code | symbol is attached | subjected to the component similar to FIG. 10C here, and the overlapping description is abbreviate | omitted suitably.

In step S1111, the server reconnection unit 417 refers to the transaction management table 303 (see FIG. 13), and among the connection destination DB servers corresponding to the transaction processing request type, any one connection destination with the lowest load level. A connection with the DB server is established (S1111). Here, a connection is newly established with the connection destination DB server having the lowest load level among the connection destination DB servers selected in step S702 of FIG.

Through the processing described above, the server reconnection unit 417 selects one connection destination DB server having the lowest load level from the plurality of connection destination DB servers without increasing the number of connections of the connection destination DB servers to a certain number or more. Can be connected. Further, the connection to the new connection destination DB server is made while maintaining the connection with the connection destination DB server that is currently established. Therefore, the connection with the connection destination DB server that is currently established can be reused.

Note that, in steps S1102, S1105, and S1111 of the flowcharts shown in FIGS. 15A to 15C, the transaction management table 303 in FIG. 13 is referred to, but this is not a limitation.

For example, referring to the transaction management table 303 in FIG. 14A, a connection with any one connection destination DB server having the smallest number of connections may be established from a plurality of connection destination DB servers corresponding to the type of transaction processing request. . As a result, the connection with the connection destination DB server can be appropriately changed according to the resource exclusive status of each connection destination DB server.

Further, referring to the transaction management table 303 in FIG. 14B, the connection from the plurality of connection destination servers corresponding to the transaction processing request type to the connection destination server of the account number key range including the account number related to the transaction processing request. It may be established. Thereby, according to the range of the data stored in each connection destination DB server, a connection with a connection destination DB server can be changed appropriately.

(Third embodiment)
In the first embodiment and the second embodiment described above, the form in which the business UAP processing unit 301 (see FIG. 6) cooperates with the DB server connection management unit 302 has been described. Here, a mode in which the UAP control unit 412 cooperates with the DB server connection management unit 302 will be described.

FIG. 16 is a block diagram illustrating a configuration example of a computer 401 according to the third embodiment of this invention. This computer 401 corresponds to the AP server 103 of FIG. The computer 401 is a computer device that includes a main storage device 402, a CPU 403, an output device 404, an input device 405, an auxiliary storage device 419, and a drive device 420 that are connected to each other via a bus.

Here, the same components as those in FIG. 6 are denoted by the same reference numerals, and redundant description will be omitted as appropriate.

Hereinafter, the online system 407 shown in FIG. 16 will be described. In the online system 407, unlike the above-described first and second embodiments, the UAP control unit 412 includes a DB connection unit 418, and the UAP control unit 412 and the DB server connection management unit 302 cooperate with each other.

The message receiving unit 409 receives the input message 408 transmitted from each tenant that is the processing request source. The received input message 408 is sent to the UAP control unit 412. The execution UAP determination unit 413 determines a user application to be executed based on the input message 408. At this time, the DB connection unit 418 calls the DB server connection management unit 302 and passes the tenant information corresponding to the input message 408 to the DB server connection management unit 302. On the other hand, the scheduler 414 schedules user applications to be executed.

Then, the tenant information receiving unit 415 receives this tenant information. Thereafter, the target server search unit 416 searches the DB server corresponding to the tenant information with reference to the transaction management table 303. Thereafter, the server reconnecting unit 417 connects to the searched DB server when the DB server searched by the target server searching unit 416 and the DB server that has already been connected are different.

In this way, the DB server connection management unit 302 establishes a connection with a connection destination DB server (not shown) according to the input message 408. Thereafter, when the connection with the DB server is established by the DB server connection management unit 302, the DB connection unit 418 passes information indicating that the connection is established to the business UAP processing unit 301. Thereafter, the business UAP processing unit 301 refers to the DB server to which the connection is established, and executes the user application to be executed according to the schedule generated by the scheduler 414.

The UAP control unit 412 sets the output message 410 to be transmitted to the response transmission destination based on the processing result of the business UAP processing unit 301. The message transmission unit 411 transmits the set output message 410 to the response transmission destination.

FIG. 17A is a diagram for explaining a first example of a method for specifying the type of transaction processing request according to each embodiment of the present invention. Here, a method (1301) in which the execution UAP determination unit 413 identifies the transmission source tenant based on the specific field in the input message 408 in step S603 in FIG. 8 will be described.

In the example shown in FIG. 17A, when the field value of the bank code in the input message 408 is the bank code 1, the execution UAP determination unit 413 specifies that the transmission source tenant is α. On the other hand, when the field value of the bank code in the input message 408 is the bank code 2, it is specified that the transmission source tenant is β.

FIG. 17B is a diagram for describing a second example of the method for specifying the type of transaction processing request according to each embodiment of the present invention. Here, a method (1302) in which the execution UAP determination unit 413 identifies the transmission source tenant based on the URL (Universal Resource Location) included in the input message 408 in step S603 in FIG. 8 will be described.

In the example illustrated in FIG. 17B, the execution UAP determination unit 413 specifies that the transmission source tenant is α when the URL included in the input message 408 includes the character string “alpha-bank”. On the other hand, when the URL included in the input message 408 includes the character string “beta-bank”, it is specified that the transmission source tenant is β.

FIG. 18A is a diagram for describing a first example of a calling method of the DB server connection management unit 302 according to each embodiment of the present invention. Here, a method will be described in which the business UAP processing unit 301 calls the DB server connection management unit 302 and passes tenant information to the DB server connection management unit 302 in step S604 of FIG.

In the example shown in FIG. 18A, the business UAP processing unit 301 calls the DB server connection management unit 302 using tenant information as an argument key (1401).

FIG. 18B is a diagram for explaining a second example of the calling method of the DB server connection management unit 302 according to each embodiment of the present invention. Here, a method will be described in which the business UAP processing unit 301 calls the DB server connection management unit 302 and passes tenant information to the DB server connection management unit 302 in step S604 of FIG.

18B, the business UAP processing unit 301 calls the DB server connection management unit 302 using the input message 408 as an argument. In this case, the called DB server connection management unit 302 analyzes the input message 408 and extracts tenant information corresponding to the input message 408 (1402).

19A and 19B are diagrams showing another example of the configuration of the AP server 211a (211b) according to each embodiment of the present invention.

As shown in FIG. 19A, the OS 1505a, 1505b, middleware 1504a, 1504b, and AP 1503a, 1503b may all be separated for each tenant (1502a, 1502b). In addition, as illustrated in FIG. 19B, the OS 107 may be shared among tenants, and the middleware 1504a and 1504b and the APs 1503a and 1503b may be separated for each tenant (1502a and 1502b).

20A and 20B are block diagrams showing another example of the configuration of the DB servers 212a and 212b according to the embodiments of the present invention.

As shown in FIG. 20A, the OS 1608 and the DBMS instance 1605 may be shared among tenants, and the DB tables 203a and 203b may be separated for each tenant. Further, as shown in FIG. 20B, a configuration of a shared schema method in which the OS 1608, the DBMS instance 1605, and the DB table 1607 are all shared among tenants may be adopted.

Although the present invention has been described in detail with reference to the accompanying drawings, the present invention is not limited to such specific configurations, and various modifications and equivalents within the spirit of the appended claims Includes configuration.

The present invention relates to a computer system, and is particularly useful for a so-called multi-tenant system in which a plurality of user companies share and use the same business system.

Claims (10)

1. A computer system comprising: a client device that issues a transaction processing request; and a server device that executes a transaction processing corresponding to the transaction processing request issued by the client device,
   The server device
   For each type of transaction processing request, a transaction management table in which identification information of the transaction processing request is associated with a connection path to another resource to be connected when executing the transaction processing corresponding to the transaction processing request. When,
   A receiving unit for receiving a transaction processing request issued by the client device;
   Each time a transaction processing request is received by the receiving unit, the transaction management table is referred to, and the connection path corresponding to the type of the received transaction processing request is used to connect to another resource corresponding to the connection path. A connection manager,
   A computer system characterized by comprising:
2. When the connection management unit is connected to the other resource, the connection is currently established with the predetermined resource, and the connection path related to the connection does not correspond to the type of the transaction processing request ,
   2. The computer according to claim 1, wherein the connection established at present is discarded, and the connection path corresponding to the type of the transaction processing request is used to connect to another resource corresponding to the connection path. system.
3. When the connection management unit connects to the other resource, a plurality of connections are currently established with a predetermined resource group, and each connection path related to the plurality of connections If it does not correspond to the request type,
   Of the currently established connections, discard the connection with the longest elapsed time since the last use, and use the connection path corresponding to the type of the transaction processing request to transfer to another resource corresponding to the connection path. The computer system according to claim 1, wherein the computer system is connected.
4. When the connection management unit is connected to the other resource, the connection is currently established with the predetermined resource, and the connection path related to the connection does not correspond to the type of the transaction processing request ,
   2. The connection established according to claim 1, wherein the currently established connection is held and a new connection is made to another resource corresponding to the connection path using the connection path corresponding to the type of the transaction processing request. Computer system.
5. The transaction management table holds load information of each of the plurality of other resources when there are a plurality of other resources to be connected,
   The connection management unit uses the connection path to the other resource with the lowest load among a plurality of other resources corresponding to the type of the received transaction processing request to set the other resource with the lowest load. The computer system according to claim 1, wherein the computer system is connected.
6. When there are a plurality of other resources to be connected, the transaction management table holds resource exclusiveness information of each of the plurality of other resources,
   The connection management unit uses a connection path to another resource having the lowest resource occupancy among a plurality of other resources corresponding to the type of the received transaction processing request, and has the smallest resource occupancy The computer system according to claim 1, wherein the computer system is connected to another resource.
7. The transaction management table includes, for each type of transaction processing request and processing target data, identification information of the transaction processing request, and other resources to be connected when executing the transaction processing corresponding to the transaction processing request. Map the connection path,
   The connection management unit corresponds to the type of the received transaction processing request and corresponds to the connection path using a connection path to another resource in which processing target data of the transaction processing request is stored. The computer system according to claim 1, wherein the computer system is connected to another resource.
8. 2. The computer system according to claim 1, wherein the other resource is a database server, and the server device is an application server that connects to the database server and executes transaction processing.
9. A multi-tenant control method in a computer system comprising: a client device that issues a transaction processing request; and a server device that executes a transaction processing corresponding to the transaction processing request issued by the client device,
   The server device
   For each type of transaction processing request, a transaction management table in which identification information of the transaction processing request is associated with a connection path to another resource to be connected when executing the transaction processing corresponding to the transaction processing request. Hold
   The method
   The server device is
   Receiving a transaction processing request issued by the client device;
   Each time a transaction processing request is received according to the receiving procedure, the transaction management table is referenced, and the connection path corresponding to the type of the received transaction processing request is used to connect to another resource corresponding to the connection path. And the steps to
   A multi-tenant control method comprising:
10. A multi-tenant control program executed in a computer system including a client device that issues a transaction processing request and a server device that executes a transaction processing corresponding to the transaction processing request issued by the client device,
    The server device
    For each type of transaction processing request, a transaction management table in which identification information of the transaction processing request is associated with a connection path to another resource to be connected when executing the transaction processing corresponding to the transaction processing request. Hold
    The program is
    Receiving a transaction processing request issued by the client device;
    Each time a transaction processing request is received according to the receiving procedure, the transaction management table is referenced, and the connection path corresponding to the type of the received transaction processing request is used to connect to another resource corresponding to the connection path. And the steps to
    Is executed by the server device.

Images