JPH08137778A - Server client system - Google Patents

Abstract

PURPOSE: To realize complete position transmission and to prevent the congestion of entrance processes owing to the deviation of the definition of a client node by distributing the address of the entrance process in the middle wear of a client node from a middle wear-side. CONSTITUTION: The client node 1 is provided with a means 3 broadcasting the request message of the entrance process address to a connected network, an acquirement processing means 4 acquiring the entrance process address corresponding to the request message existing on the network and an address definition means 41 storing the acquired entrance process address. A server node 2 is provided with a means for taking in the message from the network, an allocation decision means 52 obtaining the entrance process address fitted to the request by calculation and a notice means 51 returning the entrance process address to the network.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a server client system in which a plurality of clients and servers are connected to a network. Here, the client is a computer program that requests the server for the necessary work, and the server is a computer program that executes the requested work.

[0002]

2. Description of the Related Art In a distributed environment connected by a network,
There is software (hereinafter referred to as "middleware") that provides a location-transparent client / server environment. Here, the position transparency means that the client can request the network to execute the job without knowing the address of the server executing the job.

In such middleware, a client specifies a server of a communication partner by a friendly name such as a service name or a server name. Although several methods have been realized as methods for realizing such location transparency of servers and services, the basic method is to use an entrance process of a system such as a directory service with a fixed address. In other words, the address of the directory service must be decided.

The system's entrance process (hereinafter, simply referred to as "entrance process") may be the server process itself depending on its implementation. However, if there is only one entrance process in the system, the entrance process is present. When its own processing is heavy or there are many requests from clients, congestion occurs due to the ingress process. Moreover, the entire system is greatly affected by a failure of an entrance process or a communication path.

In order to deal with this, there is middleware in which a plurality of ingress processes can be arranged. However, in these middlewares, the client node statically defines the address of one ingress process on the network in a file etc. (that is, the ingress process is not position transparent). Proper distribution prevents the inability to communicate with a certain ingress process from affecting the entire system and prevents congestion by the ingress process.

Here, as an example of a conventional client server system, a tuxedo (TUXEDO) (trademark) will be described with reference to FIG. The tuxedo is a transaction processing monitor that provides a service to a client by the following management process group and management information and a server process described by a user. In the figure, N
W is a network, CN is a client node, and SN is a server node.

The management process that constitutes the tuxedo is shown below. WSC: It exists on the workstation where the client operates, and the request from the client is sent to the W on the server machine.
Throw to SL. The address of the WSL to which the WSC throws the request is predefined. WSL: Exists on the server machine. In response to the request from the WSC, the address of the WSH that establishes the connection is returned.

WSH: Exists on the server machine. It refers to the management information and throws the request from the WSC to the appropriate server process. If the appropriate server process does not exist in the same server machine as itself, it is thrown to the server process on another server machine via the BRIDGE process. BRIDGE: When WSH transfers a request to a server on another node because it receives a service request not provided by the server on its own node, or when the corresponding server on its own node is busy, The process of acting for communication.

DBBL: It exists in a master machine (a machine that performs management and maintenance operations of the tuxedo system among machines that compose the tuxedo system), and monitors all BBLs on the network. The failure of each node is detected, and the latest state of the BB of each node is collected and distributed. It also provides the administrator of the tuxedo system with the management and maintenance functions of the tuxedo system using the machine console as an interface.

BBL: B existing on each node and on the node
Manage B. It also detects failures in the server process and tuxedo management process on the local node. BB: A shared memory that stores information for the tuxedo management process to request a service from an appropriate server and statistical information for the tuxedo manager to monitor the system. For example, the storage information of the server and the service, the load information of the server and the service, and the like are stored.

A request flow in the tuxedo system shown in FIG. 19 will be described below. Note that the reference numerals in the following description and the reference numerals in the drawings match. The user requests service A from the client (WS). The WSC on the client requests service A to the WSL defined as its communication partner.

The WSL selects an appropriate WSH that establishes a connection with the client and replies with its address. Upon receiving the request from the WSC, the WSH refers to the server and service placement information described in the BB on its own node to search for the server providing the service A.

In this case, since there is no server providing the service A on the own node, the BR of the own node is
Request the IDGE to transfer the request to the server node SN ₂ . Server node SN instructed by WSH of own node
Forward the request to the BRIDGE of ₂ . The service A is requested to the server V designated by the request source BRIDGE.

After that, the server V processes the request of the service A, and the result is notified to the user by the route reverse to the request.

[0015]

The method of arranging a plurality of inlet processes described above has the following problems. 1. Since at least the address of the directory service must be decided, perfect location transparency cannot be realized.

2. A client node that has an entry process definition that cannot communicate for some reason cannot execute a new service request until communication with the entry process is restored. 3. Moreover, the load distribution of the processor in which the entrance process exists depends on the definition of the client node. Generally, there are many client nodes, their locations are physically separated, and the administrators are often different. In such an environment, it is difficult to balance the definition of each client node. As the system gets larger, the situation gets worse.

An object of the present invention is to realize complete position transparency by distributing the address of the middleware entry process of the client node from the middleware side. Another object of the present invention is to prevent the congestion of the ingress process due to the bias of the definition of the client node by distributing the address of the ingress process of the middleware of the client node from the middleware side.

[0018]

Means for achieving the above object of the present invention will be described below with reference to FIGS. 1 and 2. In each of the following figures, a solid line frame represents a process, and a broken line frame represents data. FIG. 2 shows the whole client-server system. In the figure, a plurality of client nodes CN _{1 to} CN ₄ and a plurality of server nodes SN ₁ and SN ₂ are connected to a network NS. In this system, one server manages a group of clients, and a plurality of subsystems SS ₁ and SS ₂ are configured for the entire client server system.

The server node SN has a server part process 2 and node information collecting means 7. Client node C
N has a client part process 1. Of these server part nodes, as a server that determines the entrance process address, one of the servers becomes the master,
Another server becomes a replica. FIG. 1 shows details of the address allocation client unit 1 and the address allocation server unit 2 in the system of FIG. The illustrated server unit 2 is not a server that executes the work requested by the client, but a server that teaches the ingress process address to the client.

The address allocation client unit 1 comprises an entrance process address acquisition means 3 and an entrance process address change means 4. Entrance process address changing means 4
Has an address definition 41. The ingress process address acquisition means 3 provides a program interface and a command interface for acquiring an ingress process address in a client node, and acquires an address of an ingress process using an ingress process address acquisition protocol. The acquired address is reflected in the client node by the entrance process address changing means 4.

The operation timing of this means may be that the client-server communication is disabled due to some failure at the time of setting up the client node, or the response between the client-server communication is significantly reduced for some reason. is there. The ingress process address changing means 4 is a means for statically and dynamically changing the address of the ingress process on the client node according to the received address.

The address allocation server unit 2 includes an entrance process address allocation unit 5, a server unit maintenance unit 6, and management information 8.
It is equipped with. The entrance process address assigning unit 5 is a group of tools for constructing a database, an algorithm, and a database for notifying the entrance process address, and includes an entrance process address notifying unit 51, an entrance process assignment determining unit 52, and a system state management. Means 53 are included.

The entrance process address notifying means 51 notifies the address of an appropriate entrance process using the entrance process address definition acquisition protocol. The trigger of the notification is the request from the ingress process address acquisition unit 3 and the server node such as congestion caused by the ingress process, a new network interface added and the number of interfaces increased, the number of server processes increased, and the server node moved. This is a case where a state change occurs and the entrance process address allocation determining unit 52 determines that address notification is necessary.

Entrance process address allocation determining means 52
Determines the position of the entrance process used by the client node from the state of the server node and the relationship between the server node and the client node. The process allocation decision is triggered when the request from the entrance process address acquisition unit 3 and the state of the server node and the relationship between the server node and the client node change.

The system status management means 53 maintains management information 8 for indicating the status of the entire system. This information includes system configuration information, client information, subsystem information, and system status information. These pieces of information are used as a judgment factor for assigning the interface to the client. The contents of the management information are as shown in FIG. 17, and the system status information is macro information about the load or status of the nodes and interfaces in the system, and serves as data for determining interface allocation. The subsystem information also includes subsystem configuration information such as which computer belongs to which subsystem, the load / state of a node or interface in the subsystem, and the configuration information of its own server unit.

Explaining the server maintenance means 6,
The server unit 2 can have a plurality of instances in the system for load balancing and high availability. The server unit maintenance means 6 mutually monitors the plurality of instances to detect the crash of the server unit C and perform recovery. Also, each instance is assigned a subset (subsystem) of the system, and collects information by using the server part maintenance protocol. The server maintenance means 6 is
It provides a means to exchange information in this subsystem with each other. The system state information management means 53 maintains the system state information based on the information obtained by this exchange.

The node information collecting means 7 collects information closed in a node, which is one computer connected to the network, and collects the information collected in the server unit that manages the subsystem to which the node belongs to the node information notification protocol. To notify.

[0028]

When the client node CN is set up, the entrance process address notification request is sent to the entrance process address assigning means 5 of the server unit 2 via the command / program interface provided by the entrance process address acquiring means 3 of the client unit 1.

Upon receiving the address notification request from the client node CN, the server unit 2 uses the entrance process address assignment determining means 52 to determine the address of the appropriate entrance process and notifies the client of the address. Server part 2
The client unit 1 that has received the notification from the above uses the entrance process address assigning unit 5 and causes the entrance process address changing unit 4 to reflect the notified entrance process address in its own address definition 41.

In the present invention, it is not necessary to define the address of the server unit 2 in the client node CN. In other words, position transparency regarding the server is realized. This is done by using a broadcast when the client first makes a request to the server, and the server section of the master that receives the request sends it back with the address of the server section to be used next. Thereby, it is possible to provide the position transparency of the server unit.

[0031]

EXAMPLE An example of the client server system of the present invention will be described with reference to FIGS. 3 and 4, a solid thick line arrow indicates that data is referred to, and a broken line arrow indicates that data is updated. 3 shows the process structure of the client unit, and FIG. 4 shows
The structure of a server process is shown. 5 to 17 are flowcharts for explaining the operation of the circuits of FIGS.

In FIG. 3, 11 is a client part process, 16 is an address setup command process,
Reference numeral 17 indicates client setup information. The client part process 11 uses the message receiving thread 1
2, the address reflection processing thread 13, the address acquisition processing thread 14, and the address information 15 of the server unit.

FIG. 4 shows a part of the server node 21.
Indicates server part processes 21 and 31, and node information collection process 31. The server process 21 includes an allocation calculation thread 22, a state monitoring thread 23, and a state management thread 2.
4, system status information 25, system configuration information 26, subsystem information 27, and client information 28. The state monitoring thread 23 and the state management thread 24 are
The maintenance means 6 of FIG. 1 is configured. The contents of the management information 25 to 28 are as shown in FIG.

The node information collecting process 31 includes a control thread 32, an information collecting thread 33, and in-node load information 3.
4. Has notification destination server address information 35. The operation at the time of setting up the client process 11 will be described with reference to FIGS. FIG. 5 shows the operation of the client part process 11. In step S51, the address acquisition processing thread 14 refers to the address information 15 of the server unit and determines whether or not the address of the server that executes the requested work is known. Since the client unit does not know the address at first, the process proceeds to step S52, and the address notification of the entrance process is broadcast to the network NW.

Note that once the subsequent process is completed and the entrance process address is obtained, it will be recorded in the address information 15 of the server section. Therefore, when setting up thereafter, the process proceeds from step S51 to step S53. , Specify the address of the server and request the address notification of the entrance process. FIG. 6 shows the server process 2
The operation of the allocation calculation thread 22 of No. 1 is shown. When a request existing on the network is fetched, it is determined in step S61 whether the request is a broadcast request. If No, the process proceeds to step S63, but Ye
If s, it is determined in step S62 whether or not the user is the master. If No, the process ends. Yes
If so, the process proceeds to step S63.

In step S63, the system state information 2
5. Calculate entrance allocation with reference to FIG. Further, the client information 28 is updated according to the calculation result. Step S
At 64, the state management thread 24 determines whether the load on the assigned server is high. If the load is not high, the process proceeds to step S67, and if the load is high, the process is step S6.
Go to 5.

In step S65, the system state information 2
5, the server allocation is calculated. Then, the client information 28 is updated according to the result. Further, in step S66, the server address of the replica of FIG. 7 is notified of the client address. The replica server unit that has received the notification updates the address table of its own client information 28 in step S71 of FIG.

Returning to FIG. 6, the ingress process address and the server address from the next time are returned to the client which issued the request in step S67. In the client unit of FIG. 5, the address acquisition processing thread 14 updates the address information 15 of the server unit and the address reflection processing thread 13 updates the client setup information 17 in step S54. Further, step S54 also operates by the notification from step S134 of FIG. 13 described later.

Next, the starting operation of the server unit will be described with reference to FIGS. FIG. 8 shows the node information collection process 31.
The operation of the control thread 32 will be described. In this flow, the operation is triggered by activation by a command at the time of node booting, rexec, or the like. In step S81, process initialization such as control table creation and thread creation is performed. In step S82, step S1 in FIG.
It waits for the arrival of the message for requesting activation of the server unit at 47. When the message arrives, the server unit is activated in step S83. In step S84, the address of the newly awakened server is notified to the creation request source, and step S82
Return to and wait for the message to arrive again.

FIG. 9 shows the operation of the allocation calculation thread 22 of the server process 21. First, step S91
Then, process initialization such as control table creation and thread creation is performed. In step S92, it is determined whether or not the master is cold started. If No,
It proceeds to step S97. In the case of Yes, step S9
3, the master version number is initialized, and server part address setting requests are issued to all nodes.

In step S94, it is determined whether or not there is a replica creation definition. If not, the service is started in step S96. If so, in step S95, the node information collection process is requested to start a replica, and the process proceeds to step S96. In step S97, the system waits for a notification of system status information from the activation request source, and when the notification is received, the process proceeds to step S98.

In step S98, it is determined whether the notification is a restart of the master. If No, the process proceeds to step S96. If Yes, the version number is updated in step S99, and all server units are notified. Then, the process proceeds to step S96 to start the service. Step S9
The service No. 6 will be described later with reference to FIG.

10 and 11 explain the operation of collecting node information. FIG. 10 illustrates the operation of the information collection thread 33 of the node information collection process 31. Step S1
In 01, the process waits for the elapse of a certain time, and the process proceeds to step S102 every certain time. In step S102, the load information of the application service in the node is acquired using the system information notification function interface of the middleware. This is a middleware-dependent process. In step S103, the load information of the processor in the node is acquired. This is an OS-dependent process.

In step S104, it is determined whether or not the change in the load condition exceeds the threshold value, or I'm alive (I'm ali
It is determined whether it is time to notify ve). If No, the process returns to step S101 and waits again for a certain period of time. If Yes, in step S105, the server unit of FIG. 11 (which will be described later) that manages the alive or the alive + change in load is notified according to the situation.

FIG. 11 illustrates the operation of the status information management thread 24 of the server section. In step S111, the arrival of the message is waited, and when the notification in step S105 of FIG. 9 is received, the process proceeds to step S112. Step S1
At 12, the aim-alive information in the subsystem information 27 of the node is updated. In step S113, it is determined whether the load has changed. If No, the process returns to step S111 to wait for the arrival of a message. Yes
If so, the load information of the node is reflected in the system state information 25 in step S114. Then, the process returns to step S111.

12 to 16 explain the operation when the state of the node changes. FIG. 12 illustrates the operation of the status monitoring thread 23 of the server process 21. Step S12
In 1, the process waits for a certain period of time, and the process proceeds to step S122 every certain period of time. In step S122, it is determined whether or not there is a node whose load exceeds the threshold time for a plurality of subsystems being managed, or whether an im-alive notification does not arrive for the threshold time. It is determined whether there is a node.

If No, the process proceeds to step S124
If Yes, the process proceeds to step S123. Step S
At 123, the allocation calculation thread of the server unit of FIG. 12 described later is requested to change the address allocation. Step S124
Now, restart the information gathering process. Step S12
At 5, it is determined whether or not the restart has failed. If No, the process proceeds to step S127. If Yes, it is determined that the node has crashed, the node information is deleted in step S126, and the process proceeds to step S127.

In step S127, it is determined whether or not the change in the status of the managed subsystem exceeds a threshold value or it is time to notify the im-alive. N
If it is o, the process returns to step S121. If Yes, in step S128, all other server units are notified of the alive or the alive + state change according to the situation. By this notification, the operation of FIG. 14 described later is started.

FIG. 13 illustrates the operation of the allocation calculation thread 22 of the server process 21. In step S131, the arrival of the request message in step S123 of FIG. 11 or the message from step S96 of FIG. 9 is waited for. When the request arrives, step S132
Then, it is determined whether the message is a notification about a node associated with his client. If No, the process returns to step S131 to wait for the arrival of a message again. If Yes, the process proceeds to step S133.

In step S133, referring to the system state information 25, the entrance allocation is calculated for all the related clients, and the client information 28 is calculated according to the result.
To update. In step S134, all the related clients are notified of the new entrance address. This notification is
Step S54 of FIG. 5 in the client part process
Go to. Then, it returns to step S131 and waits for the arrival of a message.

FIG. 14 illustrates the operation of the state management thread 24 of the server process 21. In step S141, the message from step S128 in FIG. 12 is waited for. When the message arrives, the state of the entire system is updated in step S142, and the IMMALIVE time of each server unit is updated in step S143. Step S14
In 4, it is determined whether or not there is a crashed server unit. If No, the process returns to step S141, and if Yes, the process proceeds to step S145 to determine whether or not the user is the master. If Yes, step S14
Proceed to 7. If No, it is determined in step S146 whether or not the user is the next master and the current master has crashed. If No, the process returns to step S141. If Yes, the process proceeds to step S148.

In step S147, step S of FIG.
82 and step S97 of FIG. 9 to notify the message,
Restart the crashed replica, step S149
Go to. Similarly, in step S148, the crashed master is restarted, and the process proceeds to step S149. In step S149, it is determined whether or not the replica or master is restarted. If Yes, the process returns to step S141. If No, the process proceeds to step S140 to reconfigure the subsystem and create the order between replicas. In step S141, the allocation calculation thread of each server unit, which will be described later with reference to FIG. 14, is requested to change the subsystem and rank, and the process returns to step S141.

FIG. 15 illustrates the operation of the allocation calculation thread 22 of the server process 21. Upon receiving the request from step S151 in FIG. 14 described above, step S155
In step S161 of FIG. 16, which will be described later, the newly incorporated node is notified of its own address, and the process returns to step S141 of FIG. FIG. 16 describes the operation of the control thread 32 of the node information collection process 31.

In response to the notification from step S155 in FIG. 15 described above, in step S161, the notification destination server address information 35 is changed to the address of the notification destination server unit. Then, it returns to step S141 of FIG. FIG. 18 shows the configuration when the present invention is applied to the tuxedo system described in the above description of the conventional example. 18, parts having the same functions as those in FIG. 19 of the above-mentioned conventional example are designated by the same reference numerals, and duplicated description will be omitted.

In this embodiment, the client part process 11 is provided in each of the client nodes CN _{1 to} CN ₄ . A server part process 21 and a node information collecting process 31 are arranged in one server node SN ₁ .
Node information collection process 3 is performed on the other server node SN _2.
Only 1 is placed. The operations of the client unit process 11, the server unit process 21, and the node information collecting process 31 of FIG. 18 have already been described, and thus the description thereof is omitted here.

As described above, even when the present invention is applied to the tuxedo system, complete position transparency can be realized by distributing the address of the middleware entry process of the client node from the middleware side. Further, it is possible to prevent the congestion of the ingress process due to the bias of the definition of the client node.

[0057]

According to the present invention, the following effects can be obtained. By distributing the address of the entry process of the middleware of the client node from the middleware side, complete position transparency can be realized. The definition of the client node can be automatically changed according to the failure or load status of the entrance process itself and the node of the entrance process.

By distributing the address of the middleware entry process of the client node from the middleware side, it is possible to prevent the congestion of the entry process due to the bias of the definition of the client node which has been apt to occur conventionally. Since the system administrator does not need to adjust the address of the ingress process between client nodes, the burden on the system administrator can be lightened, and at the same time the possibility of performance degradation and system outage due to definition adjustment errors between client nodes is reduced It can contribute to stable operation of the system.

[Brief description of drawings]

FIG. 1 is a conceptual diagram showing a logical structure of the present invention.

FIG. 2 is a block diagram showing the entire client-server system of the present invention.

FIG. 3 is a block diagram showing a client unit according to the embodiment of this invention.

FIG. 4 is a block diagram showing a server unit according to the embodiment of this invention.

FIG. 5 is a flowchart (No. 1) explaining the setup operation of the client unit process according to the embodiment of this invention.

FIG. 6 is a flowchart (part 2) explaining the setup operation of the client process according to the embodiment of this invention.

FIG. 7 is a flowchart (No. 3) explaining the setup operation of the client process according to the embodiment of this invention.

FIG. 8 is a flowchart (part 1) explaining the startup operation of the server process according to the embodiment of this invention.

FIG. 9 is a flowchart (No. 2) for explaining the startup operation of the server process according to the embodiment of this invention.

FIG. 10 is a flowchart (part 1) explaining the operation of collecting node information according to the embodiment of this invention.

FIG. 11 is a flowchart (part 2) explaining the operation of collecting node information according to the embodiment of this invention.

FIG. 12 is a flowchart (No. 1) for explaining the operation when the state of the node changes according to the embodiment of this invention.

FIG. 13 is a flowchart (part 2) explaining the operation when the state of the node changes according to the embodiment of this invention.

FIG. 14 is a flowchart (No. 3) explaining the operation when the state of the node according to the exemplary embodiment of the present invention changes.

FIG. 15 is a flowchart (No. 4) explaining the operation when the state of the node according to the exemplary embodiment of the present invention changes.

FIG. 16 is a flowchart (No. 5) explaining the operation when the state of the node according to the exemplary embodiment of the present invention changes.

FIG. 17 is a diagram for explaining the contents of management information in the embodiment of the present invention.

FIG. 18 is a block diagram of a system in which the present invention is applied to a tuxedo system.

FIG. 19 is a block diagram showing a conventional tuxedo system.

[Explanation of symbols]

 NW ... Network CN ... Client node SN ... Server node SS ... Subsystem 1 ... Address assignment client unit 2 ... Address assignment server unit 3 ... Ingress process address acquisition unit 4 ... Ingress process address changing unit 41 ... Address definition 5 ... Ingress process address Assigning means 51 ... Ingress process address notifying means 52 ... Ingress process address allocation determining means 53 ... System state managing means 6 ... Server part maintaining means 7 ... Node information collecting means 8 ... Management information 11 ... Client part process 12 ... Message receiving thread 13 Address reflection processing thread 14 Address acquisition processing thread 15 Address information of server section 16 Address setup command process 17 Client setup information 21 Server section process 22 Computational thread 23 ... Status monitoring thread 24 ... Status management thread 25 ... System status information 26 ... System configuration information 27 ... Subsystem information 28 ... Client information 31 ... Node information collecting process 32 ... Control thread 33 ... Information collecting thread 34 ... In node Load information 35 ... Notification destination server address information

Claims (5)

[Claims] 1. A means for broadcasting a request message of an ingress process address to a connected network, an acquisition processing means for acquiring an ingress process address corresponding to the request message existing on the network, and an acquired ingress process. A client comprising an address definition for storing an address. 2. A means for receiving a message from a network, a means for obtaining an ingress process address matching the request when the message is an ingress process address request, and a notification means for returning the ingress process address to the network. A server characterized by: 3. A server client system in which the client according to claim 1 and the server according to claim 2 are connected on a network. 4. A means for receiving a message from a network, a means for monitoring a system state, and when the received message is an ingress process address request, an ingress process address matching the request is obtained by calculation, and the monitoring means is further provided. A server comprising: an acquisition means for changing the ingress process address according to the system status information obtained by the above, and a notification means for returning the ingress process address to the network. 5. A server client system in which the client according to claim 1 and the server according to claim 4 are connected on a network.