KR100907946B1 - Dynamic Hashing Based Load Balancing System and Its Method - Google Patents

Abstract

The present invention has been made to solve the technical problem of the hashing algorithm of the conventional load balancer, and it is a session-based algorithm while taking infinite session processing capacity and high-speed processing speed with only a small amount of memory designated as an advantage of the hashing algorithm. As the hashing value is changed due to the sophistication of load balancing and the redistribution when the server is added / deleted or the server is overloaded, the problem of not guaranteeing the connectivity between the user and the server and the problem of degrading the caching effect are solved. The present invention relates to a load balancing system based on dynamic hashing that provides high performance even in a small system having a low specification.

The present invention is installed in front of the servers for load balancing to receive the request of the user 101 to the server and delivers to the server; The system has more hashing values than the number of servers; The hashing value is properly distributed to each server; Calculates a hashing value using some information of the user 101's request; Sends a request of the user 101 to a server having the corresponding hashing value; Load balancing is performed by allocating a portion of the hashing value of each server to the added server when the server is added; Distributes the hashing value of the server to other servers when the server is deleted / failed; If excessive requests are concentrated on one server, some of the hashing values are moved to other servers to balance the load appropriately; If excessive load is concentrated on a particular hashing value, it is then distributed among multiple servers; Such a series of tasks are processed at a time interval by scheduling so that the request of the user 101 is naturally passed from the server having the hashing value to the other server; For the purpose of sticking between the request of the user 101 and the server, the session of the user 101 is identified for the hashing value passed to another server, and the connection between the user 101 request and the server is maintained for a predetermined time. A system that includes applying hashing based load balancing only for new sessions.

Description

Dynamic Hashing based Load Balancing System and Its Method

The present invention relates to a hashing-based load balancer, and more particularly, to fine-tune load balancing, which is an advantage of session-based algorithms, while maintaining low memory utilization, infinite session processing capacity, and high throughput. When adding / deleting / overloading servers and servers, changes in hashing function ensures connectivity between users and servers and improves caching effects. Therefore, it provides an efficient load balancer through a simple load balancing algorithm. A dynamic hashing based load balancing system and method thereof are provided.

In general, there are Layer 4 methods for load balancing based on IP addresses and ports, and Layer 7 methods for load balancing addresses using identifiers in applications such as HTTP URLs and cookies. Regardless of which information is used as the address, all the load balancers use the same load balancing algorithm. Representative techniques include round-robin, least connection, load balancing based on response time, load balancing using server status or load information. Use them.

1 is a block diagram illustrating a general situation in which a conventional load balancer is used. In general, load balancing techniques are a technique for properly distributing connections between a request of a user 101 or a user 101 and servers 1, 2, 3, (104, 105, and 106) to a server. Units are called sessions or connections. Since these algorithms allocate and use a certain amount of memory per session in the load balancer, the number of sessions increases when the request of the user 101 or the user 101 increases, and the memory usage of the load balancer increases proportionally. In order to find a session at high speed, we introduce a hashing technique to find a session.

However, this session-based load balancing method finds infinite sessions within a finite hashing table. When the number of sessions increases due to many users 101, the search time increases in proportion to the load balancer processing speed. The disadvantage is that the limit is proportional to the size of the finite memory.

In addition, the load balancers 103 together with the load distribution between the servers 1, 2, 3 (104, 105, 106) if the user 101 connection or identification information cannot be shared between the application servers 1, 2, 3 (104, 105, 106). The stickiness between the user 101 and the servers 1, 2, 3 (104, 105, 106) must be maintained. In this case, when the user 101 attempts to access the server or requests information from the user 101 side, his identification information should be attached and sent, and the load balancer 103 should keep the identification information for a certain time, and within a certain time. When a request with the identification information comes in, it must be delivered to the same server. If connectivity is not guaranteed in such a situation, a problem arises in that the application cannot be used normally. This is one of the reasons why session-based load balancing algorithms are often used.

The hashing algorithm, which does not belong to the session-based load balancing algorithm, uses a hashing function based on the number of load balancing target servers. Instead of recording a session, the hashing algorithm judges the value from the hashing function as the load balancing result and requests the user 101 to the server. To pass. In the above method, the request of the user 101 and the user 101 is converted into a hashing value through a hashing function of information such as a source IP address, a source IP address and a port, an HTTP cookie, a URL, and a URI. To select the server.

For example, a conventional server load balancing method using a hashing algorithm will be described.

Suppose there are six servers in a server group, server 0, server 1, .. server 5. Modulo 6 is applied to the source IP address value in the user's request packet, and the corresponding server is determined by the result value (0 ~ 5).

Since the hashing-based load balancing algorithm uses a hashing function unlike the session-based load balancing algorithm, it does not consider the load information of the server at all and does not allocate a session for each of the user 101 and the request of the user 101. Even if the number of requests of the user 101 or the user 101 increases, there is no increase in the memory in the load balancer, and thus there is an advantage that the user 101 or the user 101 may process requests indefinitely.

In addition, since the request of the user 101 or the user 101 is transmitted only to a specific server, the connection security and the caching effect of the server may be increased.

However, since the servers 104, 105, and 106 are determined by the hashing value, the load distribution is not sophisticated, and when the input value of the hashing function uses only the source IP address, the proxy or source network address translation (SNAT) is used. The requests of the users 101 who came through are seen as one user 101 and the load is concentrated on a specific server. In addition, when a server add / delete / failure occurs, the algorithm using the hashing function based on the number of servers changes the hashing function due to the change in the number of available servers, resulting in a change in the connection between the user's request and the server. As a result, there is a problem in that it does not guarantee the stickiness between the user 101 or the user 101 and the server, which may have a problem that the connection is disconnected or the application malfunctions according to the characteristics of the server application.

When using a hashing-based algorithm, even if any server in the server group becomes overloaded and needs to relocate some of the sessions that the server was in charge to another server, the request of the user 101 or the user 101 described above. There is a problem that does not guarantee the stickiness between the server and the server.

In the existing hashing-based load balancing algorithm, if the number of available servers in the server group is changed, the hashing function is changed to break the stickness between the user and the server. The situation in which the number of servers changes is largely divided into three. A situation where a failure occurs in a server, the average server load in the server group is too low, or the server is deleted when the server is down for maintenance server purposes, and the server load in the server group is too high. . Another situation where the number of servers remains unchanged, but stickiness is broken, can occur when a particular server in a server group is too heavy to redistribute user requests to other servers. In any of the above situations, if any server fails, connection security cannot be maintained even if a session-based load balancing algorithm is used.

Hashing based load balancing techniques are known in the art. For example, since the patent specification relating to the overload control method and apparatus of the load balancing system of Patent No. 0713625 registered on April 25, 2007 is also described, a detailed description of the hashing-based load balancing technique is omitted here.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-mentioned problems of the prior art, and an object of the present invention is to provide a method of session-based algorithms while maintaining low memory utilization, infinite session processing capability, and high processing speed. It is a dynamic hashing-based load balancing system that guarantees connectivity between users and servers and improves caching effect due to the sophistication of load balancing and changes in the hashing function during server addition / deletion / overload.

Another object of the present invention is to provide a load balancing system based on a dynamic hashing that provides an efficient load balancer through a simple load balancing algorithm, thereby providing a high performance function even in a small system.

It is still another object of the present invention to maintain the low memory utilization, infinite session processing capability, and high processing speed of the hashing algorithm, while the load balancing sophistication and server addition / deletion / overload are advantages of the session-based algorithm. It is to provide a load balancing method based on dynamic hashing that guarantees connectivity between user and server and improves caching effect by changing hashing function.

It is still another object of the present invention to provide an efficient load balancer through a simple load balancing algorithm, thereby providing a load balancing method based on dynamic hashing that provides high performance to a small system.

Dynamic hashing-based load balancing system of the present invention for achieving the above object is a hashing-based load balancer that distributes the user's request to the server groups, and calculates any information in the user's request as a hashing value Hashing value extractor; A hashing table for selecting one of the server groups that can be processed using the calculated hashing value, and moving the hashing value to change the selected one server upon addition / deletion / fault / overload of the server; When adding / deleting one server in a server group or when one server is overloaded, the hashing value movement time is changed to dynamically change the connection relationship between the hashing value and the server while ensuring the connectivity between the user request and the servers in the server group. A hashing value movement information table including information on a state in which a hashing value can be moved, such as a session recording time and an overload state information on the hashing value; A session table capable of recording session information on a user request for a predetermined time in order to smoothly move a hashing value when adding / deleting or overloading a server; By selecting one of the server groups to which the user's request will be delivered while using the information of the tables or updating the information of the tables, periodically checking the status of the servers and removing the selected server from the candidate when a failure occurs. It is characterized by comprising a load distribution control and fault monitoring unit.

In the dynamic hashing-based load balancing system of the present invention, the hashing value extractor may use any part of information in the user request information for the hashing value calculation; This information is characterized in that the IP address, TCP / UDP port, Cookie, URL, or URI included in HTTP.

In the dynamic hashing-based load balancing system of the present invention, the load balancing control and fault monitoring unit distributes the hashing value processed by the server evenly to the remaining load balancing target server when one server in the load balancing server group fails. To this end, the hashing value may be evenly distributed or the number of hashing values may be evenly distributed by using the load information average value for each hashing value.

In the dynamic hashing-based load balancing system of the present invention, in order to distribute the hashing value processed by the server evenly to the remaining load balancing target servers when one load server in the load balancing control and fault monitoring unit is deleted, The hashing value may be evenly distributed or the number of hashing values may be evenly distributed by using an average value of load information for each hashing value.

In the load balancing system based on the dynamic hashing of the present invention, the load balancing control and fault monitoring unit distributes the hashing values processed by the servers evenly to the newly added server when the new server 4 is added in the load balancing server group. The hashing value may be evenly distributed or the number of hashing values may be evenly distributed by using the load information average value for the hashing value.

In the dynamic hashing-based load balancing system of the present invention, the load balancing control and fault monitoring unit can continue to process the specific server in the server group, but when the load exceeds the primary overload threshold specified in the hashing value movement information table, The load information of the hashing value of the server may be used to distribute hashing values having a smaller load among them to servers having a smaller load than the server.

The dynamic hashing-based load balancing system of the present invention also has exceeded the secondary overload threshold specified in the hashing value movement information table, in which the load balancing control and fault monitoring unit cannot be processed by a specific server in the load balancing server group. In this case, the specific server finds a hashing value causing an overload and sequentially distributes a user request coming into the hashing value to all or small load servers.

The dynamic hashing-based load balancing system of the present invention also has more hashing values than the number of servers in the server group in the hashing table, and the servers in the server group operating due to the failure / deletion / addition of any one server in the server group. In a server reassignment situation that involves changing the number or redistributing load to another server when one server is overloaded, the hashing values in the hashing table are assigned to one of the server groups without changing the size of the hashing value. By dynamically changing, the server is reassigned by moving the hash value.

The dynamic hashing-based load balancing system of the present invention also has more hashing values than the number of servers in the server group in the hashing table, and the number of servers operating due to the deletion / addition of any one server in the server group is changed or either. Do not move all hashing values to other server without any specified time in server reassignment situation including load redistribution to other server in case of overload of server, and user's request and server are not disconnected. It is characterized in that the movement based on any specified time.

The dynamic hashing-based load balancing system of the present invention also has more hashing values than the number of server groups in the hashing table, and the number of servers operating due to the deletion / addition of any one server in the server group is changed or In server reassignment, including the case where the server redistribution is to be redistributed to other servers in case of overload, the user's request from the time when the server reassignment occurs until the end of hashing value movements is maintained. It operates a session table for storing and referencing connection information with the server.

The dynamic hashing-based load balancing method of the present invention also has more hashing values than the number of servers in the server group in the hashing table, and the number of servers operating due to the deletion / addition of any one server in the server group is changed or In a server reassignment situation including load redistribution to another server in the event of an overload in one server, the user who has entered the hashing value for a specified time with respect to the hashing value decided to move to another server to ensure user connectivity. Generate session information for the request; The generated session information is maintained for a predetermined time; If the user's request for an existing session comes within a certain time, the session is further maintained for a specified time; Maintain a connection with a server for a specified time for the session being held; For a request of a user who is not registered to the session within the specified time for which the existing session maintains the connection with the server, any information in the user's request is calculated as a hashing value and the server can select a processable server using the calculated hashing value. Forwarding the user's request by a hashing method; The user's request in which the session is recorded is calculated as a hashing value of the user's request after a certain period of time, and a new server or another server by a hashing method of selecting a server that can be processed using the calculated hashing value. Characterized in that delivered to.

delete

The dynamic hashing-based load balancing system and method thereof of the present invention are different from the conventional method (unbalance of load) in which user requests are distributed unevenly among servers in server addition / deletion / failure / overload situations. Evenly distributes requests between servers (evenly load). In addition, dynamic hashing-based load balancing system and its method are continuously connected between user request and server regardless of the situation, unlike the existing method in which a continuous connection relationship between a user request and a server cannot be established in a server add / delete / fault / overload situation. The connection is established.

Hereinafter, the present invention will be described in more detail with reference to the accompanying drawings.

1 shows a general situation in which a conventional load balancer 103 is used. When the user 101 requests a web service through the Internet network 102, the load balancer 103 installed in front of the server 1 104, the server 2 105, and the server 3 106 makes the request most quickly. The request of the user 101 is sent to the server capable of processing. In this case, when hashing is used in the load balancing policy, requests of the same user 101 may be mapped 1: 1 to the same server. For example, if the server 1 104 processes the user 101 request 1, the server 1 104, which has processed this, is processed again when the user 101 request 1 is requested again.

2 is a block diagram illustrating a structure of a conventional hashing-based load balancer 200. The conventional load balancer 200 includes a hashing value extractor 220, a hashing table 230, a load balancing control and a fault monitoring unit 210.

The hashing value extractor 220 is responsible for calculating arbitrary information as a hashing value in a user's request, and the hashing table 230 is responsible for selecting a server that can be processed using the calculated hashing value. . The load balancing control and fault monitoring unit 210 selects a target server to which a user request is delivered from among several servers using hashing table information, and periodically checks the state of the servers to exclude the server from candidates when a failure occurs. In charge of the function.

3 is a block diagram illustrating a conventional hashing-based load balancer 320 to process a user's request 310. The load balancer 320 extracts a hashing value of 1 from the user request 310 information through the hashing value extractor 321, and finds the server 330 2 assigned to the hashing value 1 in the hashing table 322. It sends a request to the server (330) 2.

4 is a block diagram showing the structure of the load balancer 400 based on the dynamic hashing of the present invention.

The dynamic hashing-based load balancer 400 according to the present invention includes a hashing value extractor 420, a hashing table 430, a hashing value movement information table 440, a session table 450, a load balancing control and a fault monitoring unit ( 410).

 The hashing value extractor 420 is responsible for calculating arbitrary information as a hashing value in a user's request, and the hashing table 430 is responsible for selecting a server that can be processed using the calculated hashing value. .

The hashing value movement information table 440 is a hashing value movement time and a session recording time to dynamically change the connection relationship between the hashing value and the server while ensuring connectivity between the user request and the server when a server is added / deleted or overloaded. And situation information in which the hashing value can move, such as overload state information for the hashing value.

The session table 450 records session information on a user request for a predetermined time in order to smoothly move a hashing value when a server is added / deleted or overloaded. The load balancing control and failure monitoring unit 410 checks the status of the servers periodically by selecting one of a plurality of servers to which the user request is to be delivered while using the table information or updating the table information. Responsible for removing the server from the candidate.

5 is a block diagram illustrating a process of processing a user's request 510 by the dynamic hashing-based load balancer.

In the general situation in which the situation such as server deletion / failure / addition / overload does not occur, the process of processing the user's request 510 by the dynamic hashing-based load balancer 400 of the present invention is performed by the conventional load balancer 320. Same as the process of processing the request 310. The load balancer 400 extracts a hashing value of 5 through the hashing value extractor 420 from the user request 510 information, and extracts the server 2 of the server group 530 assigned to the hashing value 5 from the hashing table 430. Finds and sends the user's request (510) to server 2.

However, in special situations such as server deletion / fault / addition / overload of the server group 530, FIG. 7, 8, 9, and 10 illustrating an embodiment of the present invention will be followed.

6A and 6B are block diagrams illustrating the structure of the hashing value movement information table 440 and the session table 450 in the load balancer based on the dynamic hashing of the present invention.

The hashing value movement information table 440 includes a movement time, a session recording time, a threshold value of one overload level, and a threshold value of two overload levels. The movement time represents the time taken for the actual hashing value to move by scheduling, and the session recording time represents the time for recording the session of the hashing value to be moved. The hashing value whose movement is determined according to the situation of the server should be moved to another server within 60 seconds by the scheduling time. The session recording time is used as a criterion for determining whether or not the corresponding hashing value may be moved. The load balancer determines that the session does not need to be maintained any longer when there is no request for 60 seconds based on the session recording time and moves only the hashing value. The overload threshold is a value that is compared with the load of the server. If the load of the server is between the threshold 80 of the first stage of overload and the threshold 100 of the second stage of overload, the load balancer determines that the server is in the first stage of overload. In addition, if the load of the server is equal to the threshold value 100 of the second stage of overload, the load balancer determines that the server is in the second stage of overload. The session table 450 is composed of a source address and port, a destination address and port, a real server address and port, and a hashing value.

The general hashing-based load balancing method recalculates the hashing value by using the number of available servers in case of server deletion / failure and addition, so that the connection state of the previous user and server is not preserved but recalculated. Is changed. In this case, in the case of a web application, the user's connection is terminated, and in the case of a caching server, the hit rate decreases rapidly. 7 and 8 illustrate a method of minimizing recalculation of hashing values in case of deletion / failure and addition of a server to solve this problem.

FIG. 7 is a block diagram illustrating an operation process of processing a deletion / failure of a server using the dynamic hashing-based load balancer 400 of the present invention. For example, if server 3 is deleted or fails, the hashing values that server 3 handled are transferred to servers 1 and 2. In this example, the hashing values 6 and 7 handled by server 3 are moved to server 1 (arrows 721 and 722), and the hashing values 8 handled by server 3 are transferred to server 2 (arrows 723). In case of server failure, the guarantee of connectivity between the user request and the server is broken, so the above hashing value movement occurs. On the other hand, in the case of server deletion, the hashing value movement can be gradually performed to guarantee user request and connectivity with the server. When the server needs to be deleted, information about the incoming session for a certain period of time is recorded in the session table. After that, when a user request comes in, the session table is searched to determine whether or not it is an existing session.

If the session is new, for example, if the hashing value is 8, the server 2 is allocated according to the reassignment principle. If it is an existing session, it is determined whether a request comes in within a certain time. If the user request comes in again for a certain time, it is assigned to the existing server 3 (this is determined by the step F123 of FIG. 11). The information of the server 3 is registered in the corresponding session, and the actual session is registered in the session table 450 of FIG. 6B. The server address / port field contains information about server 3),

If the request comes in after a certain period of time, it is determined that the session does not need to be maintained. For example, if the hashing value is 8, the server 2 is allocated according to the reassignment principle. If all the requests processed by the existing server 3 are finished and the server 3 is no longer responsible, the server 3 is deleted. In the process of moving a hashing value when deleting a server, the hashing value is gradually moved by using hashing movement time and session recording time information in the hashing value movement information table 440. The session table runs only temporarily for hashing value movement.

8 is a block diagram illustrating an operation process of processing the addition of a server using the dynamic hashing-based load balancer 400 of the present invention. For example, when Server 4 is added, the hashing values of the existing servers are transferred to the new Server 4. In the example, the hashing value 5 processed by server 2 is transferred to server 4 (832) (arrow 821), and the hashing value 8 processed by server 3 is transferred to server 4 (832) (arrow 822). Here, the hashing value movement is also processed in the same manner as the gradual movement method using the hashing value movement information table 440 information described in the server deletion process of FIG. 7 to ensure the connection security between the user request and the server.

In general hashing-based load balancing, a user's request is overloaded with one or some servers, so the performance of the overall servers tends to depend on the server to which the request is overloaded. 9 and 10 relate to a method in which servers uniformly handle a user's request in a situation where request overload occurs to solve this problem.

9 is a block diagram illustrating an operation process of processing a server when a primary overload, which is an overload state, may be processed by the server using the dynamic hashing-based load balancer 400. For example, when a user's request 921 is entered and server 2 941 receives a primary overload, the server 942 moves to another server among the hashing values that server 2 processes. The threshold of primary overload is specified in the hashing value movement information table 440 of FIG. In this example, the hashing value 3 being processed by server 2941 moves to server 1 (arrow 931), and the hashing value 5 moves to server 3 (arrow 932) to distribute the user's requests evenly to the servers. After moving the hashing value, all servers have a load of 100). Here, the hashing value movement is also processed in the same manner as the progressive movement method using the hashing value movement information table 440 information described in the server deletion process of FIG. 7 in order to guarantee the connection security between the user request and the server.

FIG. 10 is a block diagram illustrating an operation process of processing a secondary overload, which is an overload state in which a server can no longer be processed using the dynamic hashing-based load balancer 400. For example, if server 2 941 is subjected to secondary overload, server 2 cannot handle it by itself and redistributes it in the form of round robin with other servers. The threshold of secondary overload is specified in the hashing value movement information table 440 of FIG. 6, for example 100. If server 2 receives a request 1021 with a hashing value of 4 that cannot be handled by itself and determines that it is a secondary overload, then the user request coming to hashing value 4 determines the server in a scheduling manner (round robin). 11 F140 step).

For example, the first request is handled by server 1 (arrow 1031), the second request is handled by server 2 (arrow 1032), the third request is handled by server 3 (arrow 1033), and the fourth request is Server 1 is distributed by processing again (arrow 1031).

The dynamic hashing-based load balancing technique of the present invention will be described in detail with reference to FIGS. 11, 12, and 13.

11 is a flowchart illustrating an overall session processing process for a user request according to an embodiment of the present invention.

F101: Start the whole operation.

F110: Receive a session.

F120: Check whether there is a corresponding session in the session table.

F121: If the session exists in the session table, check if the session has expired.

F122: Discard the session information if the session has expired.

F123: If the session has not expired, select the server recorded in the session table.

F130: If there is no session in the session table, the hashing value is calculated and the server is selected.

F140: Verify that load balancing for hashing values is round robin.

F141: If the load balancing for hashing value is round robin, choose server as round robin.

F150: If the load balancing for hashing value is not round robin, check if session recording for hashing value is enabled.

F151: End session recording if session recording for hashing value is activated.

F152: Record the session.

F160: Send a session.

F170: End the whole operation.

FIG. 12 is a flowchart illustrating managing a state change of a server before calculating the hashing value of FIG. 11 and selecting a server (F130) according to an exemplary embodiment of the present invention.

F201: Start overall operation.

F210: Check if the server has been deleted.

F211: If the server is deleted, distribute the deleted server's hashing value to the remaining servers. A specific example follows FIG. 7.

F220: If the server has not been deleted, check if there is a failed server.

F221: If there is a failed server, distribute the failed server's hashing value to the remaining servers. A specific example follows FIG. 7.

F230: If the failed server does not exist, check if the server has been added.

F231: If a server has been added, set the session to record the hashing value to move from the existing server to the added server. A specific example follows FIG. 8.

F232: Select hashing value to send to added server according to load rate and condition of existing server.

F240: If no server has been added, verify that the server's status is Overload 1, which the server can handle.

F241: If the server state is overload state 1 that the server can handle, select a hashing value to move according to the load rate and state of the servers. A specific example follows FIG. 9.

F242: The hashing value to move gradually moves according to the scheduling policy.

F250: If the server's state is not overload state 1 that the server can handle, check whether the server's state is overload state 2, which the server cannot handle.

F251: If the state of the server is an overload state 2 that the server cannot handle, the scheduling is performed by changing the hashing value of the overload state to round robin. A specific example follows FIG. 10.

13 is a flowchart illustrating an operation of moving a hashing value (F242) according to the scheduling policy of FIG. 12 according to an embodiment of the present invention.

F301: Start overall operation.

F310: Check if there is a hashing value that started recording the session.

F311: If there is a hashing value that started recording the session, check whether the session recording time for the hashing value has expired.

F312: If the session recording time for the hashing value has expired, stop recording the session for the hashing value.

F320: If no hashing value starts the session recording, check if there is a hashing value to move to another server.

F321: If there is a hashing value to move to another server, the hashing value is moved according to a specified scheduling method.

The load balancing scheme based on dynamic hashing of the present invention distributes the user's request evenly among the servers in the addition / deletion / failure / overload of the server (even load balancing) and establishes a continuous connection relationship between the user's request and the server. Be sure to This distribution and connection guarantees stable service without delays due to server addition / deletion / failure / overload to all users who use the server.

Although the invention has been described in detail only with respect to the described embodiments, it will be apparent to those skilled in the art that various changes or modifications can be made within the spirit and scope of the invention, and such changes or modifications are consequently attached to the appended claims. It will have to belong to the scope of.

1 is a block diagram illustrating a general situation in which a conventional load balancer is used.

2 is a block diagram showing the structure of a conventional hashing-based load balancer.

3 is a block diagram illustrating a conventional hashing-based load balancer processing a user request.

4 is a block diagram showing the structure of a load balancer based on dynamic hashing according to the present invention.

5 is a block diagram illustrating a process of processing a user's request by the load balancing based on the dynamic hashing according to the present invention.

6A and 6B are block diagrams illustrating the structure of the hashing value movement information table and the session table in the load balancing based on the dynamic hashing of the present invention.

7 is a block diagram illustrating an operation process of processing a deletion / failure of a server using a dynamic hashing-based load balancer according to the present invention.

FIG. 8 is a block diagram illustrating an operation process of adding a server using a dynamic hashing-based load balancer according to the present invention.

FIG. 9 is a block diagram illustrating an operation process of processing a server when the first overload, which is an overload state, may be processed by the server using the dynamic hashing-based load balancer.

FIG. 10 is a block diagram illustrating an operation process of processing a secondary overload, which is an overload state in which a server can no longer continue using the dynamic hashing-based load balancer of the present invention.

11 is a flowchart illustrating an overall session processing process for a user request according to an embodiment of the present invention.

FIG. 12 illustrates a flowchart of managing a state change of a server before calculating the hashing value of FIG. 11 and selecting a server according to an exemplary embodiment of the present invention.

13 is a flowchart illustrating an operation of moving a hashing value according to the scheduling policy of FIG. 12 according to an exemplary embodiment of the present invention.

<Description of the symbols for the main parts of the drawings>

400: load balancer

410: load distribution control and fault monitoring unit

420: hashing value extractor

430 hashing table

440: hashing value movement information table

450: session table

Claims (11)

In the hashing-based load balancer for distributing the user's request to the server groups 530, A hashing value extractor 420 that calculates arbitrary information as a hashing value in a user's request; A hashing that selects one server among the server groups 530 that can be processed using the calculated hashing value, and moves the hashing value to change the selected one server upon addition / deletion / fault / overload of the server. Table 430; Dynamically changing the connection between the hashing value and the server while ensuring connectivity between the user's request and the servers in the server group 530 when adding / deleting one server in the server group 530 or when one server is overloaded A hashing value movement information table 440 including information on a situation in which a hashing value can be moved, such as a hashing value movement time, a session recording time, and an overload state information on the hashing value; A session table 450 capable of recording session information on a user request for a predetermined time in order to smoothly move the hashing value when the server is added / deleted or overloaded; By selecting one of the server groups 530 as a target server to which a user request is to be delivered while using the information of the tables 430, 440, 450 or updating the information of the tables 430, 440, 450, Dynamic hashing-based load balancing system, characterized in that the load balancing control and failure monitoring unit comprising a function to exclude the selected server when the failure occurs by checking the status. 2. The hashing value extractor (420) of claim 1, wherein the hashing value extractor (420) may use any part of the information in the user request information to calculate the hashing value; This information may be an IP address, a TCP / UDP port, a cookie, a URL, or a URI included in HTTP. 2. The load balancing control and failure monitoring unit 410 of claim 1, wherein the server 3 741 processes a hashing value when one server 3 741 in the load balancing server group 530 fails. A dynamic hashing-based load balancing system, characterized in that the hashing values are evenly distributed or the number of hashing values are evenly distributed using the load information average value for each hashing value in order to distribute the remaining load balancing target servers evenly. 2. The load balancing control and fault monitoring unit 410 is configured to perform a hashing value processed by the server 3 741 when one random server 3 741 in the load balancing server group 530 is deleted. A dynamic hashing-based load balancing system, characterized in that the hashing values are evenly distributed or the number of hashing values are evenly distributed using the load information average value for each hashing value in order to distribute the remaining load balancing target servers evenly. 2. The load balancing control and fault monitoring unit 410 of claim 1, wherein the new server 4 (832) in the load balancing server group 530 is added to the server 4 (the new hashing value processed) And evenly distribute the hashing value or evenly distribute the number of hashing values by using the load information average value for each hashing value. 2. The load balancing control and fault monitoring unit 410 is configured to perform processing by a specific server 2 941 in the load balancing server group 530, but the load is assigned to the hashing value movement information table 440. When the first overload threshold is exceeded, the load information of the hashing value of the server 2941 is used to distribute hashing values having the smaller load among the servers having the less load than the server 2941. Dynamic hashing based load balancing system. 2. The hashing value movement information table 440 of claim 1, wherein the load balancing control and fault monitoring unit 410 is in a state in which the specific server 2941 in the load balancing server group 530 cannot continue processing. When the second overload threshold specified in the above is exceeded, the server 2941 finds a hashing value causing the overload, and sequentially distributes user requests coming to the hashing value to all or lightly loaded servers. Dynamic hashing based load balancing system. The server of claim 1, wherein the hashing table 430 has more hashing values than the number of servers in the server group 530, and the server operates due to the failure / deletion / addition of any one server in the server group 530. In the server reassignment situation including the case where the number of servers in the group 530 is changed or when one server is overloaded, the hashing values in the hash table 430 are not changed. Dynamic hashing-based load balancing system, characterized in that by dynamically changing any of the assigned server in the group (530), by relocating the server through the hashing value movement. The method of claim 1, wherein the hashing table 430 has more hashing values than the number of servers in the server group 530, and the number of servers operated by deleting / adding any one server in the server group 530 is changed. In the server reassignment situation, including when a server is overloaded or redistributing the load to another server, all the hashing values are not moved to another server without any specified time, Dynamic hashing-based load balancing system, characterized in that moving based on a predetermined time so as not to break. The method according to claim 1, wherein the hashing table 430 has more hashing values than the number of server groups 530, and the number of servers operating due to the deletion / addition of any one server in the server group 530 is changed. Server relocation, including when you want to redistribute load to another server when one server is overloaded Dynamic hashing-based load balancing method characterized by operating a session table (450) for storing and referencing the user's request and connection information with the server. The method of claim 1, wherein the hashing table 430 has more hashing values than the number of servers in the server group 530, and the number of servers operating due to the deletion / addition of any one server in the server group 530. In a server reassignment situation, including a case where a load is to be redistributed to another server when a change is made or when one server is overloaded, the hashing value is determined for the time specified for the hashing value determined to be moved to another server to ensure user connectivity. Generate session information about a request of an incoming user; The generated session information is maintained for a predetermined time; If the user's request for an existing session comes within a certain time, the session is further maintained for a specified time; Maintain a connection with a server for a specified time for the session being held; For a request of a user who is not registered to the session within the specified time for which the existing session maintains the connection with the server, any information in the user's request is calculated as a hashing value and the server can select a processable server using the calculated hashing value. Forwarding the user's request by a hashing method; The user's request in which the session is recorded is calculated as a hashing value of the user's request after a certain period of time, and a new server or another server by a hashing method of selecting a server that can be processed using the calculated hashing value. Dynamic hashing-based load balancing system, characterized in that the transfer to.

Images