JP2006260591A - Content server, and content distribution management program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a content management device for properly processing distribution of a load for distribution of a content, by selecting a contents server for distributing the content requested by a client, based on a selection criterion defined by characteristic of the requested content. <P>SOLUTION: A server load distribution system for distribution-processing a distribution, of the content, to the client D1 by the plurality of content servers A2 is provided with a transferred-server determination policy setting means C12 for setting the selection criteria for determining the content server A2 for distributing the content in every characteristic of the each content, and a transferred-server determination means C13 for determining the content server A2 for distributing the content requested from the client D1, based on the selection criteria corresponding to the characteristic of the requested content. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

The present invention relates to server load distribution, and more particularly to WWW (World Wide
Web) A content management apparatus and a content management program for selecting an appropriate server in response to a request from a client for acquiring content for distribution such as content and video content, and transmitting the request to the selected server .

  In recent years, in the distribution of WWW content and moving image content via the Internet, various methods have been proposed for distributing the server load and shortening the response time received by the client by distributing the same content to a plurality of servers. .

  In such an environment where contents are distributed and arranged in the network, a server load distribution apparatus for determining to which server a request from a client for acquiring contents should be transmitted is necessary.

  As a prior art, Patent Document 1 (Japanese Patent Laid-Open No. 2001-101134) describes a device that predicts a server load for each service by simulation and distributes client requests so that the server does not become overloaded or overloaded. ing. In the apparatus described in this publication, the transfer destination server is selected by paying attention only to the server load, and the transfer destination server is selected for each service.

Japanese Patent Laid-Open No. 09-198346 discloses a method for selecting a transfer destination server in a client. The server selection method described in this publication is characterized in that a selection policy is stored in an inquiry message to the directory server in order to respond to various server selection requests from individual clients. Upon receiving the inquiry, the directory server selects an optimum server based on the selection policy stored in the message, and responds to the client. Since this method is a selection method in the client, the client has to introduce this method. If the server load balancer can support various selection criteria as in this method, the equivalent service can be realized transparently without changing the method in the client.
JP 2001-101134 A JP 09-198346 A

  However, the conventional techniques described above have the following problems.

  First, in the content server, there is a problem that the content is not necessarily grouped for each characteristic of the content, and if it is, only the static characteristic is used.

  The content in the content server is generally arranged so that it can be easily managed by the content manager, and is not grouped in terms of content characteristics. For example, under the “/ news /” directory related to news, news articles, photos, videos, and other content with different characteristics in terms of file size and media type are arranged together. It is normal. Also, dynamic characteristics (parameters) such as access frequency for each content are not considered. At this time, if the same content server is selected as the transfer destination for the “/ news /” directory in the server load balancing device on the client side, it may not necessarily be optimal from the viewpoint of content acquisition delay depending on the characteristics of the content There is. Therefore, the transfer destination server should be selected in units of content groups in which those having similar characteristics in terms of content size, access frequency, and the like are made into the same group.

  Second, since the server load balancer cannot change the selection criterion of the transfer destination server according to the characteristics of each content, there is a problem that effective load balancing cannot be realized.

  In the prior art, the selection criterion for the transfer destination server is fixed, and the selection criterion cannot be changed according to the characteristics of the content. For example, considering two types of content, small content and large content, the response time at the client is greatly affected by the delay in the transfer path for small size content, whereas the transfer time for large content. The available bandwidth is greatly affected. In such a case, the prior art cannot use different selection criteria for two or more different types of content.

  Thirdly, if each server load distribution device arranged on the client side independently selects a transfer destination server, the load may be concentrated on the same server, which may result in degradation of the distribution quality. was there.

  In particular, if access is concentrated on the same server in the case of continuous media content distribution such as stream or audio, the expected distribution quality cannot be obtained, and it is necessary to select the transfer destination server again. Furthermore, if all the connections that are being distributed are switched at the same time, there is a possibility that an oscillation phenomenon may occur in which the distribution quality deteriorates again due to the concentration of access to the new distribution server after switching and the switching of the distribution server is repeated.

  Fourth, a server load balancer that selects a transfer destination server in units of content or content groups needs to determine the transfer destination server by looking at the contents of the request from the client. There was a problem that it had to be realized.

  If a layer 7 switch is used, requests from clients can be distributed to transfer destination servers set in content units. However, the processing performance is lower than that of a device that performs switching in a low layer such as a layer 3 switch or a layer 4 switch. Is low and the cost is high. Therefore, it is desirable that an equivalent function can be realized by using a device that performs switching in a lower layer without having to look at the contents of the request more.

  A first object of the present invention is to solve the above-mentioned drawbacks of the prior art, and to manage content and content in the content server automatically and statically / dynamically according to the characteristics thereof To provide a management program.

  A second object of the present invention is to provide a content management apparatus and a content management program that can solve the above-mentioned drawbacks of the prior art and can change the selection criteria of a transfer destination server according to the characteristics of each content.

  A third object of the present invention is to provide a content management apparatus and a content management program that solve the above-mentioned drawbacks of the prior art and appropriately perform distributed processing so as not to concentrate on a specific server when distributing continuous media content. is there.

  A fourth object of the present invention is to provide a content management apparatus and a content management program that solve the above-mentioned drawbacks of the prior art and realize transfer destination server selection in units of content groups without requiring a layer 7 switch function. That is.

  In order to achieve the above object, according to the present invention, in a content server that distributes content, an actual resource value calculated as the resource information is selected for a node that selects a distribution destination of the content based on resource information about each server. A means for notifying the corrected value is provided.

  The present invention of claim 2 is a content distribution management program for managing content distribution of a content server that distributes content by controlling a computer, and a node that selects a content distribution destination based on resources of each server On the other hand, the present invention is characterized in that a function for notifying a value obtained by correcting an actual resource value calculated as resource information that can be used at present is provided.

  As described above, according to the present invention, the following effects are achieved.

  The effect of the present invention is to suppress the rapid concentration of requests from clients to the content server, and to prevent the determination of the transfer destination server from oscillating without converging in the request routing table of the server load balancer. .

  The reason is that, in the content server, the actual resource information calculated as currently available resource information is not necessarily returned as it is to the node that selects the content distribution destination based on the resource of each server. This is because it is possible to prevent a large number of the above nodes from selecting the same content server as a transfer destination at the same time by responding with a value obtained by correcting the resource value.

Next, embodiments of the present invention will be described in detail with reference to the drawings.
(First embodiment)
Referring to FIG. 1, the first embodiment of the present invention is realized by a content server A1 and a content management device B1. A client D1 accessing the content on the content server A1 is connected to the content management apparatus B1 via the backbone 1.

The content server A1 includes a content storage unit A11 and a dynamic parameter storage unit A16. The content storage unit A11 holds distribution content itself such as WWW content and moving image content, a program associated with the content, a database necessary for program execution, and the like. Each content is identified by an identifier from the client side. For example, HTTP (Hyper
In the Text Transfer Protocol, content is identified by a URL (Universal Resource Locator). The dynamic parameter storage unit A16 stores dynamic parameters (resource information) as dynamic characteristics such as access frequency and CPU load for each distribution content referred to by the content management apparatus B1. The contents of this dynamic parameter are sequentially updated by the content server A1. In the following description, the resource value does not need to be a numerical value that specifically indicates the access frequency, the CPU load, or the like, and may be information indicating the degree thereof.

  The content management apparatus B1 includes a classification policy setting unit B11, a content classification unit B12, and a content aggregation unit B13. The classification policy setting unit B11 groups the contents included in the content storage unit A11 according to their characteristics (static characteristics such as content type and size, and dynamic characteristics such as access frequency). Set the classification policy.

  Here, the classification policy stores information for roughly classifying content such as files, streams, and CGI (Common Gateway Interface) content for each type of media. Further, information for further classifying each classified type may be included. For example, a file is divided into three policies, large, medium, and small, according to its size, and a stream is divided into three, high, medium, and low, according to its transfer rate. There is a policy. Alternatively, it may be a policy based on dynamic characteristics such as high, medium, and low access frequency.

  FIG. 2 is an example of the classification policy table 101 indicating the classification policy set in the classification policy setting unit B11. For example, contents classified into files are classified into three groups of large, medium, and small according to their sizes, and groups classified into large sizes are divided into two groups of high and low according to their access frequency. are categorized. Furthermore, URLs to which content groups classified by the set policy are to be aggregated are shown.

  The content classification unit B12 classifies the content in the content storage unit A11 based on the classification policy set by the classification policy setting unit B11. At the time of classification, static parameters such as the type and size that can be acquired from each content itself, and dynamic parameters such as access frequency stored in the dynamic parameter storage unit A16 are referred to. For example, first, contents are classified for each type of media such as file, stream, and CGI. Next, when a finer classification policy is set for each type of media, the contents are classified into a plurality of content groups according to, for example, the file size and access frequency according to the policy.

  The content aggregating unit B13 aggregates the content for each content group based on the result of automatically classifying the content by the content classifying unit B12. Taking the case of a URL as an example, the URL is expressed using a directory in which content is arranged in the content storage unit A11. However, the contents in the content group created by the content classification unit B12 are not necessarily collected under the same directory, and the client D1 identifies which content group each content belongs to. Have difficulty. Therefore, the URL is rewritten so that the contents in the same content group are arranged under the same directory.

  In the example of the classification policy table 101 shown in FIG. 2, URLs to which classified content groups are to be aggregated are shown. For example, all content classified as CGI and classified as having a high load on the CPU is “/ It is changed to the directory of “cgi / high-load /”.

  FIG. 3 is a diagram for specifically explaining the URL rewriting process. For example, it is assumed that the content whose original directory path is “/pub/z.exe” should be collected under the directory “/ cgi / high-load /” after being classified according to the set policy. Then, content having a directory path “/cgi/high-load/z.exe” is generated as a symbolic link to “/pub/z.exe”. Also, all the reference links in the web page referring to “/pub/z.exe” are rewritten to the directory path after aggregation.

  Next, with reference to FIG. 4, the automatic grouping operation according to the content characteristics in the content management apparatus B1 in the present embodiment will be described in detail.

  In the content management apparatus B1, the content classification unit B12 reads the content classification policy set in the classification policy setting unit B11 (step S101 in FIG. 4), and each content in the content storage unit A11 according to the read classification policy. Are classified into a plurality of media types (step S102).

  When the content classification into the plurality of media types is completed, the content classification unit B12 classifies each content into a plurality of content groups for each classified media type (step S103). This step is classification according to detailed characteristics such as content size and access frequency, and refers to dynamic parameters such as access frequency stored in the dynamic parameter storage unit A16.

  When the classification into a plurality of media types and the classification into the content groups for each media type are completed, the contents are aggregated for each content group using the content aggregating unit B13 (step S104).

  In the present embodiment, the content management apparatus B1 has been described here as being realized in an independent node. However, as shown in FIG. 5, the content management apparatus B1 is a partial function of the content server A1. B1 can also be realized. In addition, it can be realized on any node including the server load distribution device C1 described in the second embodiment, and can also be realized as one function of the gateway device.

  Furthermore, in the above description, the case where one content server A1 is connected to the content management device B1 has been described. However, as shown in FIG. 6, a plurality of content servers A1 are connected to the content management device B1, and the content The management apparatus A1 may be configured to classify and manage content for each content server A1.

(Effects of the first embodiment)
Next, the effect of this embodiment will be described. In the present embodiment, the content management apparatus B1 automatically classifies content in the content server according to its characteristics. It is also a feature that this classification can be performed according to dynamic characteristics.

  Furthermore, content groups created as a result of classification are automatically aggregated. The contents in the content server are not grouped under the same directory for each characteristic from the beginning. For example, under the “/ news /” directory related to news, news articles, photos, videos, and other content with different characteristics in terms of file size and media type are arranged together. It is normal.

  According to the present embodiment, a group of contents having the same characteristics can be reconfigured under the same directory. When an optimum server is selected in this directory unit in a client-side server load balancer, which will be described later, according to the characteristics of the contents The optimum request routing can be realized with the minimum number of entries.

(Second Embodiment)
Next, a second embodiment of the present invention will be described in detail with reference to the drawings. Referring to FIG. 7, the second embodiment of the present invention is realized by a content server A2, a server load distribution device C1, and a client D1.

  The content server A2 includes a content storage unit A11 that stores various contents to be distributed, a request reception / content response unit A12, and a resource response unit A13.

  The request reception / content response unit A12 receives the request received from the client D1 side, and identifies the content to be responded to. Then, the content is transmitted to the client D1 side.

  The resource response unit A13 responds to the resource information acquisition request from the server load balancer C1, and responds with resource parameters such as the server load, the number of connections, and the link usage rate according to the request content. When the server load distribution device C1 does not make a resource information acquisition request to the content server A2, the resource response unit A13 can be omitted.

  The server load distribution device C1 includes a resource acquisition unit C11, a transfer destination server determination policy setting unit C12, a transfer destination server determination unit C13, a request routing table C14, a request reception unit C15, a request transfer unit C16, a content And a reception / transfer unit C17. This server load distribution device C1 can be realized as a partial function of a proxy server that centrally manages requests from a plurality of clients, for example.

The resource acquisition unit C11 includes resource information related to the content server, for example, resource information necessary for registration as a transfer destination server or request routing when the request routing table C14 is not registered as a transfer destination server or other candidate server. Resource information related to the transfer destination server and other candidate servers registered in the table C14 is acquired. As an example of resource information, RTT (round trip time;
Network resource parameters such as round trip time) and transfer throughput, and resource parameters related to the server itself such as the load on the web server and the number of connections. There are two main methods for acquiring resource information.

  One is a method (active type) of requesting and acquiring information such as the CPU load and the remaining bandwidth value up to the own node from the content server A2, and the other is from the content reception / transfer unit C17, This is a method (passive type) for acquiring the delay required to transfer the received content and the obtained transfer throughput. It is also possible to indirectly estimate the server's CPU load, the number of sessions, etc. using a passive method.

  Furthermore, it is possible to predict or extract other resource parameters from the acquired resource parameters. For example, (1) a content acquisition time measured for a small-sized content is regarded as RTT, and (2) a content acquisition time for CGI content with a large program execution load is considered as a server load. .

  The transfer destination server determination policy setting unit C12 sets the transfer destination server determination policy table 103 indicating a policy for selecting a transfer destination server according to the characteristics of each content.

  FIG. 8 is an example of the transfer destination server determination policy table 103 indicating the policy set in the transfer destination server determination policy setting unit C12. In the transfer destination server determination policy table 103, for content groups having file characteristics, the transfer throughput at the time of content acquisition is used, and a server having a value up to 60% on the basis of the server having the maximum value. Is selected as the destination server. For a content group having CGI characteristics, a value obtained by multiplying the CPU load by the RTT up to the server is used, and three servers are selected in ascending order.

  The transfer destination server determination unit C13 determines a transfer destination server from the resource parameters acquired by the resource acquisition unit C11 using the resource parameter set in the transfer destination server determination policy setting unit C12.

  The request routing table C14 is a table indicating to which server the request received by the request receiving unit C15 should be transferred. The entry in the table is written by the transfer destination server determination unit C13.

  FIG. 9 is a table 104 showing an example of the request routing table C14. According to this table 104, the IP address of the transfer destination server for the URL of the requested content is written.

  For example, an entry whose URL is “http://www.aaa.net/cgi/high/*” includes all entries including “http://www.aaa.net/cgi/high/” at the top of the URL. It is a URL prefix expression that represents a URL. The request corresponding to this entry is transferred to the content server having the IP address “10.2.5.2”. An entry whose URL corresponds to “http://www.ccc.com/file/small/*.jpg” is an entry of content under “http://www.ccc.com/file/small/”. Among them, all files having jpg as the file extension are supported. The request corresponding to this entry is transferred to the content server having the IP address “10.4.2.1” or the content server having the IP address “10.2.5.2”.

When a plurality of transfer destination server IP addresses are specified in this way, one of the servers is selected in round robin for each request, or weighted round robin (Weighted
Round Robin) or a weighted hash function can be used for selection according to the weight specified for each server, that is, the priority ratio.

  The request receiving unit C15 receives a request from the client D1, and analyzes the content. By analyzing the content of the request, the URL of the content requested by the client D1 is identified. Further, the server to which the request is to be transferred is resolved with reference to the request routing table C14 and passed to the request transfer unit C16.

  The request transfer unit C16 receives the content of the request to be transferred and the server information to be transferred from the request reception unit C15, and transfers the request to the content server A2.

  The content reception / transfer unit C17 receives the response content from the content server A2 in response to the request made by the request transfer unit C16, and transfers the content to the client D1.

  The client D1 issues a request to acquire content in the content server A2. The request is guided to the content server A2 designated by the server load balancer. Here, the client D1 indicates a plurality of clients instead of one.

  Next, with reference to FIGS. 10-12, the operation | movement which selects a transfer destination server in this Embodiment, changing a selection reference | standard according to the characteristic of each content in the server load distribution apparatus C1 is demonstrated in detail.

  First, the operation when the server load distribution device C1 receives a request for acquiring content from the client D1 will be described with reference to FIG.

  In the server load balancer C1, when the request receiving unit C15 receives a request from the client D1, the request is analyzed, and the URL of the requested content is identified (step S201 in FIG. 10).

  Next, the request receiving unit C15 checks whether there is an entry for the content in the request routing table 104 with respect to the identifier of the requested content (step S202).

  If there is an entry for the content in step S202, the request receiving unit C15 refers to the entry and reads the content server A2 to which the request is to be transferred (step S203). Then, the request transfer unit C16 receives the request to be transferred and the information of the content server A2 to be transferred from the request reception unit, and transfers the request to the content server A2 (step S204).

In step S202, if there is no entry for the content, the request is transferred to the default server (step S205), the transfer destination server is determined for the content group including the requested content, and the transfer destination is stored in the request routing table. The server entry is written (step S206). Here, the default server is a server corresponding to a destination IP address of an IP packet including the request as data, or an FQDN (Fully URL) of the URL in the request.
Qualified Domain Name: A server corresponding to an IP address resolved using a domain name server (DNS) from a fully qualified domain name.

  FIG. 11 is a flowchart for explaining in detail the operation corresponding to step S206.

  The transfer destination server determination unit C13 identifies to which content group the requested content belongs, and acquires a candidate server list for the content group (step S301 in FIG. 11). As an identification / acquisition method here, there are a method of inquiring the content management apparatus B1 using all or part of the URL in the request as a key, and a method of inquiring directly to the content server A2. Here, the candidate server is a server group extracted from all the content servers A2 that hold the content group or from all the content servers A2 that hold the content group.

  There is also a method of using a domain name server for content group identification and candidate server list acquisition for the URL. In this case, a unique FQDN is obtained for each content group, and a content server corresponding to each IP address resolved using the FQDN as a key is set as a candidate server. As an example of a method for generating a unique FQDN for each content group, when the URL for the requested content is “http://www.aaa.net/cgi/high/prog.cgi”, “high.cgi. There is a method in which “www.aaa.net” is set as the FQDN corresponding to the content group to which the content belongs, and the IP address of the candidate server is resolved using the FQDN as a key.

  Next, the transfer destination server determination unit C13 identifies which transfer destination server determination policy of the transfer destination server determination policy setting unit C12 corresponds to the content group, and reads the corresponding transfer destination server setting policy (step S302). ). For example, there are the following two methods for identifying this correspondence.

(1) When making an inquiry to the content management apparatus B1 in step 301, information on the content characteristics of the content group is also acquired at the time of inquiry.

(2) A table in which the content characteristics corresponding to the URL and the destination port number are mapped in the server load balancer C1 (for example, the content characteristic of the content group including cgi-bin in the URL is CGI, and the destination port number 554 Corresponding relationship that the content characteristic of a content group is a stream)

  Further, the transfer destination server determination unit C13 acquires resources by acquiring the content directly from the candidate server in order to determine the transfer destination server for the content group from the transfer destination server setting policy read in step S302. That is, it is checked whether or not passive resource measurement is necessary (step S303).

  As an example of the case where passive resource measurement is necessary, there is a case where resource parameters such as content transfer delay and transfer throughput are used for determining a transfer destination server. On the other hand, as an example when there is no need to perform passive resource measurement, resource parameters such as server load and link bandwidth are acquired by inquiry, and active resources used to determine the destination server using the results The case where a measurement is performed is mentioned. Note that the destination server may be determined by mixing passive resource measurement and active resource measurement.

  In step S303, when it is necessary to perform passive resource measurement to check the transfer destination server, the transfer destination server determination unit C13 writes the candidate server in the request routing table C14 (step S304).

  When the candidate server is written in the request routing table C14 in step S304, the request routing table C14 selects one content server from among the candidate servers as a transfer destination of the request for the content included in the content group.

  At this time, the request is forwarded to all candidate servers by selecting a forwarding destination by round robin. By distributing the request to each candidate server, the content reception / transfer unit C17 receives the content from each candidate server, and the resource acquisition unit C11 measures the transfer delay at that time (the amount of received content per unit time). In step S305, resource parameters such as transfer throughput can be known.

  Next, it is checked whether or not active type resource measurement is necessary (step S306). That is, when sufficient resource parameters cannot be obtained only by the passive resource measurement in step 305, the active resource measurement is performed in step S307, assuming that the active resource measurement is necessary.

  In step S303, when it is not necessary to perform the passive resource measurement to check the transfer destination server, or when it is determined in step 306 that the active resource measurement is necessary, the transfer destination server determination unit C13 determines the resource acquisition unit C11. Is used to measure and acquire the necessary resource parameters (step S307).

  When the resource parameter necessary for determining the transfer destination server is acquired in step S305 or step S307, the transfer destination server determination unit C13 determines the transfer destination server using the resource parameter and the transfer destination server setting policy read in step S301 ( Step S308). At this time, a plurality of content servers may be determined as transfer destination servers.

  Then, the entry of the determined transfer destination server is written as the request transfer destination for the corresponding content group in the request routing table C14 (step S309). When writing a plurality of entries, the ratio and weighting of requests transferred to each content server may be written simultaneously.

  When the transfer destination server is written in the request routing table C14 in step S309, the state shifts to a state in which the written entry is maintained (step S310).

  FIG. 12 is a flowchart for explaining in detail the operation corresponding to step S310.

  The request routing table C14 periodically checks whether a request for the transfer destination server entry to be maintained has been received within a predetermined time (step S401 in FIG. 12). If no request has been received for a certain period of time, the entry is deleted (step S404).

  If a request for the entry is received within a certain time, whether or not the candidate server for the entry has more than a preset threshold value compared to the resource value when the transfer destination server is determined. A check is made using the resource acquisition unit C11 (step S402). This check is for checking whether or not the transfer destination server determined in step S307 is still optimal. If there is no change greater than or equal to the threshold, the process returns to step S401 again.

  In step S402, if there is a change greater than or equal to the threshold value, the process returns to step S301, and the operation of determining the transfer destination server is performed again (step S403).

(Effect of the second embodiment)
Next, the effect of this embodiment will be described.

  In the present embodiment, the server load distribution apparatus determines a transfer destination server with a different policy for each content group and registers it in the request routing table. Conventionally, since the transfer destination server is selected based on the same standard for all content groups, it cannot be said that the optimal server is necessarily selected depending on the content group. In the present embodiment, the request from the client is always transferred to the optimum server by changing the selection criteria of the transfer destination server according to the characteristics of each content group. In particular, the server selection can be realized more effectively by combining with the first embodiment that automatically generates the content group according to the characteristics of the content.

(Third embodiment)
Next, a third embodiment of the present invention will be described in detail with reference to the drawings.

  Referring to FIG. 13, the third embodiment of the present invention is realized by a content server A3 and a server load distribution device C1.

  The content server A3 is different from the configuration of the content server A2 in the second embodiment in that it includes a resource response policy setting unit A14 and includes a resource response unit A15 instead of the resource response unit A13. Other configurations are the same as those of the second embodiment shown in FIG.

  The resource response policy setting unit A14 sets a policy for responding to a resource information acquisition request received from the server load balancer C1. Here, the policy is used to prevent excessive access from being concentrated on the content server. For example, it is assumed that the content server A3 receives resource information acquisition requests from a plurality of server load distribution devices when the CPU load of the own node is as low as 10%. At this time, if the CPU load value is replied to 10% for all the server load balancers, the server load balancer that receives this value determines that the CPU load of the content server A3 is sufficiently low, and the content server A3 May be selected for the server to which the request should be forwarded. As a result, the CPU load of the content server A3 may increase rapidly due to concentration of access, and sufficient server performance may not be provided. In the worst case, all the server load balancers that have selected the content server A3 as the transfer destination server detect the server performance degradation and select another content server as the transfer destination server again. This time, the content server selected again An oscillation phenomenon occurs in which the operation that performance deteriorates due to concentration of access is recursively repeated.

  A policy for preventing such concentration of access to a specific content server and an oscillation phenomenon is set. Here, as an example of a policy, the number of server load balancers that do not respond to a resource that exceeds a predetermined threshold within a certain period of time, or that simultaneously responds with a resource that exceeds a predetermined value within a certain period of time, is kept within a certain threshold. The contents etc. can be considered.

  FIG. 14 is an example of the resource response policy table 105 indicating policies set in the resource response policy setting unit A14. In this resource response policy table 105, the response policy is shown according to the type of resource. For example, regarding the CPU load, when the current CPU load is 0% to 30%, the actual CPU has a probability of 30%. Responds twice the value of the load (actual value is answered with a probability of 70%), and in the case of 30% to 60%, responds with a value of 1.5 times the actual CPU load with a probability of 50% In the case of 60% to 100%, the actual value is responded.

  The resource response unit A15 responds with the requested resource parameter to the resource information acquisition request from the server load balancing device C1 in the same manner as the resource response unit A13 in the first embodiment. However, at the time of resource response, the resource response policy set in the resource response policy setting unit A14 is referred to, and the resource value to be responded according to the policy is calculated.

  Next, with reference to FIG. 15, the operation when the content server A3 receives a resource acquisition request from the server load balancing device C1 in the present embodiment will be described in detail.

  When the resource response unit A15 in the content server A3 receives the resource information acquisition request from the server load balancer C1, the resource response unit A15 acquires a resource value corresponding to the requested resource parameter in the own node (step S501 in FIG. 15).

  Next, the resource response unit A15 acquires a resource response policy for the resource parameter from the resource response policy setting unit A14 (step S502).

  After step S502, the resource response unit A15 checks whether the resource parameter acquired in step S501 can be responded with its value (step S503).

  If it is determined in step S503 that the resource parameter can be responded with its value, the resource response unit A15 returns the resource parameter to the server load balancer C1 that has issued the resource information acquisition request (step S503). S505).

  If it is determined in step S503 that the resource parameter is not responded as it is, the resource response unit A15 calculates a resource value to respond based on the resource response policy for the resource parameter (step S504). Then, the calculated resource value is returned as the resource parameter to the server load balancer C1 that has made the resource information acquisition request (step S505).

(Effect of the third embodiment)
Next, the effect of this embodiment will be described. In the present embodiment, the content server does not always respond with actual resource information as it is to a resource information acquisition request from a plurality of server load balancing apparatuses arranged in the network, but rather with a set resource response policy. The resource value is corrected according to the response.

  Since each server load balancer determines the transfer destination server independently, when the actual resource information is responded as it is as in the prior art, a large number of server load balancers simultaneously select its own content server as the transfer destination server. There could be a sudden concentration of requests. By correcting the resource value and responding as in the present embodiment, it is possible to suppress rapid concentration of requests.

(Fourth embodiment)
Next, a fourth embodiment of the present invention will be described in detail with reference to the drawings.

  Referring to FIG. 16, the fourth embodiment of the present invention is realized by a content server A2 and a server load balancer C2.

  The server load balancer C2 includes a weight setting unit C19 in addition to the configuration of the server load balancer C1 in the second embodiment. Further, a request routing table C18 is used instead of the request routing table C14.

  The request routing table C18 has the same function as the request routing described in the second embodiment, but differs in that the transfer weight value is designated for each transfer destination server IP address in each entry. By using a weighted round robin, a weighted hash function, or the like, a server that responds to the request reception unit is selected at a ratio of weight values specified for each server.

  In the request routing table C14, servers that do not transfer requests are not registered, but in the request routing table C18, all candidate servers for the content group are registered. At this time, the server that does not transfer the request is registered with a weight of 0%. FIG. 17 shows a table 106 as an example of the request routing table C18.

  The weight setting unit C19 has a function of setting / changing the transfer weight value in the request routing table C18. In the request routing table 106 in FIG. 17, the transfer destination server IP addresses for “rtsp: //stream.bbb.org/live/*” are “10.5.1.1”, “10.7.1.1”, “10.4.2.1”. The weight values for “10.2.5.2” are 20%, 20%, 10%, and 50%, respectively, and the operation is performed to change them to, for example, 30%, 30%, 20%, and 20%, respectively.

  Next, with reference to FIG. 18, the operation | movement which prevents the load concentration to the specific server in the server load distribution apparatus C2 in this Embodiment is demonstrated in detail.

  The transfer destination server determination unit C13 acquires a resource for the transfer destination server registered using the resource acquisition unit C11 for each entry in the request routing table C18 (step S601 in FIG. 18). The type of resource to be acquired is set in the transfer destination server determination policy setting unit C12, and may be different for each entry.

  When the resource for each transfer destination server is acquired, the transfer destination server determination unit C13 next compares the acquired resource value for each server to determine whether the difference in resource value between the servers exceeds a preset threshold value. A determination is made (step S602). As an example of this discrimination criterion, “the maximum value of the resource value for each acquired server is at least twice as large as the minimum value”, “the difference between the maximum value and the minimum value of the transfer throughput for each acquired server is 1 Mbps or more. Or the like.

  In step S602, if the difference in resource value between servers does not exceed a preset threshold value, the weight value set in the request routing table C18 is not changed, but if it exceeds, the weight setting unit C19 obtains it. The weight value is reset according to the resource value that has been set (step S603).

  For example, it is assumed that server A, server B, and server C and three transfer destination servers are registered, and the weight values for each are 30%, 50%, and 20%. Assume that the transfer throughputs for the three acquired servers are 6 Mbps, 3 Mbps, and 1 Mbps, respectively. At this time, the weight value is changed to 60%, 30%, or 10% according to the transfer throughput ratio.

  However, changing the weight value in accordance with the ratio of the resource values in this way is not desirable from the viewpoint of preventing oscillation. In the case of the above example, after the weight change, the request to server A increases from 30% to 60%. However, if the ratio of requests to server A is also increased in other load balancers, the request received by server A The number increases rapidly, and the transfer throughput of the server A may be greatly reduced. Then, the weight value needs to be changed again, and the weight changing operation may oscillate without converging. In order to prevent oscillation, there is a method of limiting the rate of weight change using move_granularity without changing the weight value depending on the ratio of resource values. move_granularity is a parameter for suppressing a change in weight value once, and takes a value of 1.0 or less. In the above example, when the weight value for the server A is changed from 30% to 60% according to the ratio of the resource values, it corresponds to “move_granularity = 1.0”. For example, in the above example, when “move_granularity = 0.3”, the weight value is changed for server A by (60% −30%) × 0.3 = 9%. The later weight value is 39%. Similarly, for server B and server C, the changed weight values are 44% and 17%, respectively.

  By gradually changing the weight value using move_granularity in this way, it is possible to suppress a sudden increase / decrease in the number of requests received by a specific server, and to suppress oscillation. At this time, it is important to set the value of move_granularity so that oscillation does not occur. For example, a method of automatically adjusting move_granularity to a value that does not cause oscillation using feedback control is conceivable.

  The transfer destination server determination unit periodically executes the operations of steps S601 to S603 for each entry in the request routing table C18.

  The operation described with reference to FIG. 18 needs to use move_granularity and adjust its value so that oscillation does not occur. Next, the operation will be described in detail with respect to a method of suppressing a sudden change in the number of requests to the content server without adjusting the move_granularity (that is, with “move_granularity = 1.0”).

  Referring to FIG. 19, the operations up to step S602 are the same as those described with reference to FIG. In step S602, if the difference in resource value is equal to or greater than the threshold value, instead of immediately changing the weight value in step S603, the time for changing the weight value is determined (step S604 in FIG. 19). The time for changing the weight value is determined probabilistically. For example, it is possible to determine the time at a time between 0 minutes and 10 minutes later with equal probability.

  At the time determined in step S604, the resource acquisition unit C11 is used again to acquire a resource for the transfer destination server registered for each entry in the request routing table C18 (step S605). When resources for each transfer destination server are acquired again in step S605, the same operation as in step S602 is performed again, and it is determined whether the difference in resource value between the servers exceeds a preset threshold value (step S606).

  If the difference in resource value between servers does not exceed a preset threshold value in step S606, the process ends without changing the weight value set in the request routing table C18. The weight value is reset according to the resource value acquired again in step S605 by the part C19 (step S607).

  In this operation, instead of adjusting move_granularity, the time for resetting the weight value is delayed by a time that is probabilistically dispersed, thereby suppressing a rapid change in the number of requests to the content server. Further, it is determined whether or not to reset the wait value again at the delayed time, and if it is not necessary, the resetting is not performed, so that an unnecessary change operation of the wait value is suppressed and an effect of preventing oscillation can be obtained. .

(Effect of the fourth embodiment)
Next, the effect of this embodiment will be described.

  In the present embodiment, the weight value for the transfer destination server of each entry in the server load balancer is changed according to the acquired resource value. By changing the weight value gently using move_granularity, it is possible to suppress a sudden change in the number of requests to a certain content server. In addition, the same effect can be obtained by delaying the time for resetting the weight value by a probabilistic dispersed time instead of adjusting the move_granularity. In the third embodiment, the sudden change in the number of requests is realized on the content server side. However, in this embodiment, no change is required on the content server side, and the server load balancer side. To achieve the same function.

(Fifth embodiment)
Next, a fifth embodiment of the present invention will be described in detail with reference to the drawings.

  Referring to FIG. 20, the fifth embodiment of the present invention is realized by a content server A4, a server load distribution device C3, a client D2, and a domain name server E1.

  The content server A4 includes a content storage unit A11 and a request reception / content response unit A12. Each function and operation is as described in the second embodiment.

The server load distribution device C3 includes a packet receiving unit C25, a packet transfer unit C20, a packet routing table C21, a transfer destination server determination unit C22, an FQDN (Fully
Qualified Domain Name (fully qualified domain name) resolution unit C23 and address resolution unit C24.

  The packet receiving unit C25 receives the packet from the client D2, and checks the destination port number of the packet. When the checked destination port number is included in the preset value, the entry registered in the packet routing table C21 is referred to, and the IP of the content server A4 to which the packet is to be transferred from the destination IP address of the packet Look up the address.

  The packet transfer unit C20 rewrites the destination IP address of the packet received by the packet receiving unit C25 with the IP address of the content server A4 to be transferred, and transmits the IP address to the content server A4.

  It is also possible to transfer the packet by only rewriting the header at the layer 2 level without rewriting the IP address. Considering the case where Ethernet (registered trademark) is used as the layer 2 protocol, the MAC address of the content server A4 is resolved using the ARP from the IP address of the content server A4 to be transferred, and the destination IP address of the packet The packet is transferred with the resolved MAC address as the destination MAC address without rewriting. Hereinafter, for the sake of simplicity, only the case of rewriting the IP address and transferring the packet will be described.

  In the packet routing table C21, the IP address of the content server to which the packet is to be transferred is registered for the destination IP address / destination port number of the packet received by the packet receiving unit C25.

  FIG. 21 is a table 107 showing an example of the packet routing table C21. According to this table 107, for example, for a packet whose destination IP address is “10.1.1.1” and whose destination port number is “7070”, the content server whose destination IP address is “20.2.2.2” or “30.3.3.3 To the content server.

  At this time, instead of alternately selecting one of the two content servers for each packet, in order to connect the same connection to the same content server, a hash function with the same source IP address / source port number combination is used. A method of selecting a content server based on the generated hash value is used. Also, there is a method of storing a packet having the same IP address / port number as that of the packet so that the packet is transferred to the same server when the SYN flag of the TCP header of the received packet is received.

  The transfer destination server determination unit C22 determines a transfer destination server (content server A4) for a packet having a certain destination IP address / destination port number. Here, the method similar to that described in the transfer destination server determination unit C13 of the second embodiment can be applied to the determination of the transfer destination server. The determined transfer destination server is written as an entry in the packet routing table C21.

  The FQDN resolution unit C23, when the transfer destination server determination unit C22 determines the content server A4 to be a transfer destination of a packet having a certain destination IP address / destination port number, Queries the server E1.

  The address resolution unit C24, after the transfer destination server determination unit C22 resolves the FQDN for the destination IP address by the FQDN resolution unit C23 during the operation of determining the server that is the transfer destination of the packet having a certain destination IP address Then, a new FQDN is created using the resolved FQDN and the destination port number of the packet, and the IP address for the newly created FQDN is resolved. Here, the newly created FQDN must be unique for each destination IP address and destination port number of the packet. For example, when the resolved FQDN is “aaa.com” and the destination port number of the packet is “7070”, the IP address for the FQDN of “port7070.aaa.com” is resolved. Here, it is possible to resolve a plurality of IP addresses, and by using the FQDN resolution unit C23 and the address resolution unit C24, it is possible to obtain a list of IP addresses of candidate servers as transfer destinations of the packet. .

  The client D2 includes a request transmission unit D11 and an address resolution unit D12.

  The request transmission unit D11 transmits a request for acquiring content as an IP packet. At this time, the IP address corresponding to the FQDN of the URL is resolved from the URL, which is the identifier of the content to be acquired, using the address resolution unit D12, and the resolved IP address is set as the destination IP address of the IP packet to be transmitted. . The port number specified by the URL is set as the destination port number. For example, when transmitting a request for acquiring content whose URL is “http://aaa.com/pict.jpg:7070”, if the IP address for “aaa.com” is “10.1.1.1”, the destination A packet with an IP address of “10.1.1.1” and a destination port number of “7070” is transmitted.

  The address resolution unit D12 inquires of the domain name server E1 about the IP address using the FQDN portion of the URL of the content to be acquired as a key. The response from the domain name server E1 may include a plurality of IP addresses. In this case, any one entry is used as the IP address corresponding to the FQDN.

  The domain name server E1 includes an address / FQDN resolution table E11, an address response unit E12, and an FQDN response unit E13.

  The address / FQDN resolution table E11 is a table that is referred to when responding to the address resolution request and the FQDN resolution request received by the address response unit E12 and the FQDN response unit E13, and is a conversion table of “FQDN → IP address”. There are two tables, one address resolution table 108 and an FQDN resolution table 109 which is a conversion table of “IP address → FQDN”.

  FIG. 22 shows an example of the address / FQDN resolution table E11. The address / FQDN resolution table E11 includes two tables, an address resolution table 108 and an FQDN resolution table 109. As a feature of the address / FQDN resolution table E11, there may be a plurality of IP addresses that can be resolved for a certain FQDN in the address resolution table 108, but there is a resolution for a certain IP address in the FQDN resolution table 109. There must be one FQDN.

  At this time, if the FQDN is used as the content group identifier, the server load balancer C3 identifies the requested content group by resolving the FQDN from the destination IP address and destination port number of the packet received from the client D2. It becomes possible to do. Furthermore, by resolving the IP address from the FQDN, a candidate server list for the FQDN can be acquired. In other words, the requested content group can be identified only by analyzing the IP header and the transport layer (UDP / TCP) header, and there is no need to analyze the information of the higher layer.

  In response to the address resolution request received from the other node, the address response unit E12 refers to the address / FQDN resolution table using the FQDN included in the request message as a key, and responds with the resolved IP address.

  In response to the FQDN resolution request received from another node, the FQDN response unit E13 refers to the address / FQDN resolution table using the IP address included in the request message as a key, and responds with the resolved FQDN.

  Next, with reference to FIG. 23, in this Embodiment, the operation | movement at the time of transmitting the request | requirement which acquires the content with a client D2 is demonstrated in detail.

  The request transmission unit D11 extracts the FQDN from the URL of the content to be acquired (step S701 in FIG. 23). For example, when the URL is “http://aaa.com/pict.jpg:7070”, “aaa.com” corresponds to the FQDN part.

  Next, the IP address corresponding to the extracted FQDN is resolved through the address resolution unit D12 (step S702). At this time, the address resolution unit D12 makes an address resolution request to the domain name server E1 using the FQDN as a key.

  Finally, the request transmission unit D11 transmits a request packet for the content using the resolved IP address as the destination IP address (step S703).

  Next, with reference to FIG. 24, the operation when the server load distribution apparatus C3 receives a packet from the client D2 in the present embodiment will be described in detail.

  The packet receiver C25 analyzes the destination port number of the received packet and checks whether or not the analyzed destination port number matches a preset value (step S801 in FIG. 24).

  If the result of step S801 does not match the preset value, the packet receiver C25 processes the received packet as a normal packet (step S803). That is, the operation as a server load balancer is not performed.

  If the result of step S801 matches the preset value, the packet receiver C25 checks whether or not an entry corresponding to the destination IP address / destination port number of the received packet exists in the packet routing table C21 ( Step S802).

  If the entry exists as a result of step S802, the packet receiver C25 inquires the packet routing table C21 about the transfer destination server IP address in the entry (step S804).

  At this time, the packet routing table C21 responds with the IP address of the transfer destination server corresponding to the destination IP address / port number of the received packet. If a plurality of transfer destination server IP addresses are registered at this time, the packet routing table C21 will be described first. As described above, the IP address of the transfer destination server is returned so that the same connection is connected to the same content server by a method using a hash function or the like.

  When the packet receiving unit C25 receives the transfer destination server IP address from the packet routing table C21, the packet receiving unit C25 rewrites the destination address of the received packet with the transfer destination server IP address and transmits the received packet (step S805).

  If the entry does not exist as a result of step S802, the packet receiving unit C25 transfers the received packet to the original destination IP address without changing the destination IP address (step S806). Further, an optimum transfer destination server for the packet having the destination IP address / destination port number is determined, and an operation of writing an entry in the packet routing table C21 is performed (step S807). After step S806, until the transfer destination server is written in step S807, even if a packet having the destination IP address / destination port number is received, it is transferred as it is to the original destination IP address.

  FIG. 25 is a flowchart for explaining in detail the operation corresponding to step S807.

  The transfer destination server determination unit C22 resolves the FQDN for the destination IP address of the received packet via the FQDN resolution unit C23 (step S901 in FIG. 25). At this time, the FQDN resolution unit C23 transmits a FQDN resolution request to the domain name server E1 using the IP address as a key, and receives a response.

  When the FQDN is resolved in step S901, the transfer destination server determination unit C22 creates a new FQDN using the FQDN that was resolved in step S901 and the destination port number of the packet via the address resolution unit C24. The IP address corresponding to the FQDN is resolved (step S902). Here, the newly created FQDN must be unique for the combination of the destination IP address and the destination port number of the packet. For example, when the resolved FQDN is “aaa.com” and the destination port number of the packet is “7070”, the IP address for the FQDN of “port7070.aaa.com” is resolved.

  In step S902, a new FQDN is created using the FQDN resolved in step S901 and the destination port number of the packet, and the IP address is resolved to the domain name server using this newly created FQDN as a key. In addition to this, there is a method in which the FQDN solved in step S901 is directly used as a key. In this case, the FQDN itself solved in step S901 must be unique to the requested content group. Therefore, the destination IP address of the packet received by the server load balancer C3 needs to be given a unique value for each content group. In this case, in the packet routing table C21, the IP address of the transfer destination server need only be registered for the destination IP address only, and is registered for the destination IP address / destination port number combination. There is no need.

  Next, the transfer destination server determination unit C22 determines a transfer destination server from among the servers corresponding to the IP address solved in step S902 (step S903). Here, the detailed operation for determining the transfer destination server is the same as that in the second embodiment, and a description thereof will be omitted.

  When the transfer destination server is determined, the transfer destination server determination unit C22 writes the determined server IP address in the packet routing entry (step S904).

(Effect of 5th Embodiment)
Next, the effect of this embodiment will be described.

  In the present embodiment, the server load distribution device identifies the content group to which the requested content belongs using the domain name server from the destination IP address / destination port number of the packet, and becomes the optimum content server for the content group. Forward the packet. A conventional server load distribution device needs to have a function of analyzing the contents of a packet from a client and identifying which content the request is for. That is, it is necessary to use a layer 7 switch as a server load distribution device. The server load distribution apparatus according to the present embodiment can identify which content is a request only by examining only the destination IP address and destination port number of the packet. Therefore, it is realizable using a layer 4 switch. In general, the layer 7 switch has lower processing performance such as the number of connections per second, and the cost is higher. If this embodiment is applied and an equivalent function can be realized by a layer 4 switch, it can be said that there is an effect from the viewpoint of improving processing performance and reducing costs.

  Needless to say, the fifth embodiment and the content management apparatus of the first embodiment described above can be applied in combination. In that case, a port number is set instead of the aggregation URL in the classification policy table shown in FIG. 3 is replaced with a path with a port number such as “/cgi/high-load/z.exe:7070”.

  Embodiments of the present invention will be described below with reference to the drawings.

(First embodiment)
First, a first embodiment of the present invention will be described with reference to the drawings. Such an example corresponds to the second embodiment of the present invention.

  Referring to FIG. 7, the present embodiment is performed by a network constituted by a content server A2, a server load distribution device C1, and a client D1.

  In the transfer destination determination policy setting unit C12 in the server load balancer C1, the policies shown in the transfer destination server determination policy table 103 of FIG. 8 are set. Further, it is assumed that there is no entry registered in the request routing table C14 as an initial state.

  The client D1 transmits a request for acquiring the content identified by the URL “http://www.aaa.com/file/small/pict.gif” to the server side.

  The server load balancer C1 receives the request and analyzes the requested URL. Then, referring to the request routing table C14, since there is no entry for the URL, the request is transferred to the default content server. The IP address resolved by the domain name server from “www.aaa.com” that is the FQDN part of the URL is set as the default content server.

  After the request is transferred, the server load balancer C1 tries to create an entry of the transfer destination server for the content group to which the URL belongs in the request routing table C14.

  First, the transfer destination server determination unit C13 obtains a content group and a candidate server list for the URL by making an inquiry to a content management device that manages the content server A2.

  When the content management apparatus receives the inquiry, the content group corresponding to the URL has file characteristics and is identified by the URL prefix “http://www.aaa.com/file/small/*”. Responds with information indicating that there are three, “10.1.1.1”, “10.2.2.2”, and “10.3.3.3”.

  As another method for obtaining a candidate server list for the URL, an FQDN “small.file.www.aaa.com” is created from the URL, and a list of corresponding IP addresses is created using the FQDN as a key. There is also an example of querying the server. In this example, the domain name server responds that there are three IP addresses for the FQDN, “10.1.1.1”, “10.2.2.2”, and “10.3.3.3”.

  Next, the transfer destination server determination unit C13 refers to the transfer destination server determination policy setting unit C12 to check the transfer destination server determination policy for the content group, and for the content group having the file characteristics, A policy is used in which transfer throughput is used, and a server having a value up to 60% is selected as a transfer destination server on the basis of the server having the maximum value.

  In order to measure the transfer throughput from each candidate server according to the acquired policy, the transfer destination server determination unit C13 stores the URL pre-fix “http://www.aaa.com/file/small/*” in the request routing table C14. Three IP addresses "10.1.1.1", "10.2.2.2", and "10.3.3.3" are registered as transfer destination servers for requests having a fix. After registration, each request corresponding to the URL prefix from the client is transferred to the three servers in a round robin manner.

  The response content from the content server side in response to the request transferred to the three servers by round robin is received by the content reception / transfer unit C17. The resource acquisition unit C11 acquires the transfer throughput of the response content via the content reception / transfer unit C17, and passes the acquired information to the transfer destination server determination unit C13. Here, it is assumed that the transfer throughputs of the servers corresponding to “10.1.1.1”, “10.2.2.2”, and “10.3.3.3” are 1 Mbps, 7 Mbps, and 10 Mbps, respectively. Based on the policy in which the server having the maximum value is selected as a reference, a server having a value of up to 60% is selected as the transfer destination. Therefore, the transfer destination server determination unit C13 sets “10.2.2.2” and “10.3. Two servers corresponding to “3.3” are determined as transfer destinations. In addition, there are two transfer destination servers “10.2.2.2” and “10.3.3.3” for requests having the URL prefix “http://www.aaa.com/file/small/*” in the request routing table C14. Rewrite to Thereafter, the request corresponding to the URL prefix is transferred to the two servers in round robin.

(Second embodiment)
Next, a second embodiment of the present invention will be described with reference to the drawings. Such an example corresponds to the third embodiment of the present invention.

  Referring to FIG. 26, the present embodiment is performed by the content server 201 and the server load balancers 301 to 306. The content server 201 has the same configuration as the content server A3 in the third embodiment, and similarly the server load distribution devices 301 to 306 have the same configuration as the server load distribution device C1.

  In the content server 201, the resource response policy shown in the resource response policy table 105 in FIG. 14 is set. Here, it is assumed that the current CPU load in the content server 201 is 25%.

  Here, in order to determine the transfer destination server in the server load balancers 301 to 306, it is assumed that a resource acquisition request for CPU load is made to the content server 201 almost simultaneously from each server load balancer.

  In response to the resource acquisition requests from the first server load balancers 301 to 304, since the current CPU load is in the range of 0% to 30%, the actual CPU load is responded with a probability of 70%. Responds twice the actual CPU load with a probability of%. Here, 25% which is an actual CPU load is responded to the server load balancers 301 to 304, and 50% which is a value twice the actual CPU load for the server load balancers 305 and 306. To respond.

  If the content server 201 responds to the server load balancers 301 to 306 with 25% that is the actual CPU load, all the server load balancers determine that the CPU load on the content server 201 is sufficiently low, and the content server Since 201 is determined as the transfer destination server, there is a possibility that a load increase due to a sudden increase in requests may occur. In this embodiment, it is assumed that the server load distribution apparatuses 305 and 306 determine that the CPU load of the content server 201 is not sufficiently low and determine a content server other than the content server 201 as the transfer destination server. Therefore, a rapid load increase in the content server 201 is suppressed.

(Third embodiment)
Next, a third embodiment of the present invention will be described with reference to the drawings. Such an example corresponds to the fourth embodiment of the present invention.

  Referring to FIG. 27, the present embodiment is performed by the content servers 202 and 203 and the server load balancer 307. The content servers 202 and 203 have the same configuration as the content server A2 in the fourth embodiment, and similarly the server load distribution device 307 has the same configuration as the server load distribution device C2.

  First, in the request routing table in the server load balancer 307, as shown in the table 110 of FIG. 28, the transfer destination server IP address for “ftp://ftp.ccc.edu/pub/*” is “10.5”. .1.1 ”(corresponding to the content server 202) and“ 10.6.1.1 ”(corresponding to the content server 203), and the weight value for each is 90% and 10%.

  This weight value is reset according to the transfer throughput ratio from each server until the difference between the server having the maximum transfer throughput and the server having the minimum transfer throughput is within twice. Here, it is assumed that the transfer throughputs for the content servers 202 and 203 are 1 Mbps and 9 Mbps, respectively. At this time, assuming that “move_granularity = 1.0”, the weight values for the respective servers are reset as 90% → 10%, 10% → 90%, respectively. It is assumed that the ratio of request transfer to each server changes after the weight is reset, and the next throughput is 9 Mbps and 1 Mbps when the transfer throughput is measured next time. Then, the weight is set again, and the initial value returns to 10% → 90% and 90% → 10%. Thus, when the weight changing operation is recursively repeated and oscillates, it indicates that move_granularity is too large.

  Therefore, consider the case where “move_granularity = 0.5” in the above example. If the transfer throughput for the content servers 202 and 203 is 1 Mbps and 9 Mbps, respectively, the fluctuation amount of the weight value for each server is multiplied by 0.5 in the case of “move_granularity = 1.0”, and 90% → 50% Reset from 10% to 50%. It is assumed that the ratio of request transfer to each server changes after the weight is reset, and the next throughput is 7 Mbps and 3 Mbps when the transfer throughput is measured next time. Similarly, the respective weight values are reset from 50% to 60% and 50% to 40%. After the weight is reset, the transfer throughput for each server becomes 6 Mbps and 4 Mbps, and the difference between the server having the maximum transfer throughput and the server having the minimum transfer throughput is within twice, so the weight change operation is terminated. Thus, it is important to adjust move_granularity to an appropriate value so that the weight changing operation does not oscillate.

(Fourth embodiment)
Next, a fourth embodiment of the present invention will be described with reference to the drawings. Such an example corresponds to the fifth embodiment of the present invention.

  Referring to FIG. 20, the present embodiment is performed by a network including a content server A4, a server load distribution device C3, a client D2, and a domain name server E1.

  In the domain name server E1, an address resolution table 108 and an FQDN resolution table 109 shown in FIG. 22 are registered.

  It is assumed that the entry registered in the packet routing table C21 in the server load balancer C3 is empty in the initial state.

  The client D2 tries to transmit a request for acquiring the content identified by the URL “http://aaa.com/pict.jpg:7070” to the server side. At this time, an address resolution request is issued to the domain name server E1 using “aaa.com” which is the FQDN portion of the URL as a key. The domain name server E1 responds with “10.1.1.1” which is the corresponding IP address. Then, the client D2 transmits the request in the form of a packet having the resolved “10.1.1.1” as the destination IP address and “7070” specified by the URL as the destination port number.

  The server load distribution device C3 receives the packet from the client D2, and transfers the packet having the destination port number designated in advance to the transfer destination server IP address with reference to the packet routing table C21. In this case, “7070” is a preset destination port number and the packet routing table C21 is examined. Since there is no registered entry, the packet is transferred with the original destination IP address.

  After the packet transfer, the server load balancer C2 attempts to create a transfer destination server entry for the content group corresponding to the packet in the packet routing table C21. Until a transfer destination server entry is created, even if a packet having the same destination IP address / destination port number as the packet is received, it is transferred to the original destination IP address.

  An example of creating a transfer destination server entry for a content group corresponding to a packet in the packet routing table C21 will be described with reference to FIG. The request is transmitted from the client D2 in the form of a packet having “10.1.1.1” as the destination IP address and “7070” designated by the URL as the destination port number as described above.

  First, the transfer destination server determination unit C22 of the server load distribution device C2 issues an FQDN resolution request to the domain name server E1 using the destination IP address “10.1.1.1” as a key via the FQDN resolution unit C23. .

  Upon receiving the inquiry, the FQDN response unit E13 of the domain name server E1 responds with “aaa.com” that is the FQDN for “10.1.1.1”.

  Next, the transfer destination server determination unit C22 assigns the information of the destination port number “7070” to “aaa.com” that is the FQDN that is responded to the domain name server E1, via the address resolution unit C24, “port7070 An address resolution request is issued with the FQDN “.aaa.com” as a key. The newly created FQDN need only be unique to the destination IP address and destination port number of the packet, and may be “7070.port.aaa.com” in addition to this example. However, it is a condition that an entry corresponding to the FQDN to be created is also registered in the domain name server E1.

  Upon receiving the inquiry, the address response unit E12 of the domain name server E1 responds “10.1.1.1”, “20.2.2.2”, and “30.3.3.3”, which are addresses to “port7070.aaa.com”.

  Accordingly, the transfer destination server determination unit C22 determines that the destination IP addresses of the candidate servers for the packet having the destination IP address / destination port number “10.1.1.1/7070” are “10.1.1.1”, “20.2.2.2”, “30.3. 3.3 "is understood.

  Next, the transfer destination server determination unit C22 determines a transfer destination server to be registered in the packet routing table from the candidate servers. Here, it is assumed that a policy for selecting two servers in ascending order of CPU load is set as the transfer destination server decision policy. As a result of inquiring each server, the CPU of the server corresponding to “10.1.1.1” Assume that the load is 80%, the CPU load of the server corresponding to “20.2.2.2” is 30%, and the CPU load of the server corresponding to “30.3.3.3” is 50%.

  As a result, the transfer destination server determination unit C22 supports the server corresponding to “20.2.2.2” and “30.3.3.3” for the packet whose destination IP address / destination port number is “10.1.1.1/7070”. The server to be transferred is determined as a transfer destination and registered in the packet routing table C21 (see the packet routing table 107 in FIG. 21).

  After registering the entry in the packet routing table C21, the packet having the destination IP address / destination port number “10.1.1.1/7070” is redirected to the server having the IP address “20.2.2.2” or “30.3.3.3”. The

  The server load distribution system of each of the above embodiments includes the transfer destination server determination policy setting unit C12, the transfer destination server determination unit C13, C22, the FQDN resolution unit C23, and the address resolution unit C24 in the server load distribution devices C1 to C3. Functions, functions of the content classification unit B12 and content aggregation unit B13 in the content management device B1, functions of the resource response units A13 and A15 and resource response policy setting unit A14 in the content servers A1 to A4, and other functions. Of course, the content distribution management program A39, the content management program B19, and the server load distribution programs C29, C49, and C59 having various functions are loaded into the memory of the computer processing apparatus. be able to. The content distribution management program A39, content management program B19, and server load distribution programs C29, C49, C59 are stored in a magnetic disk, a semiconductor memory, or other recording media. Each function described above is realized by being loaded from the recording medium into the computer processing apparatus and controlling the operation of the computer processing apparatus.

  Although the present invention has been described with reference to the preferred embodiments and examples, the present invention is not necessarily limited to the above-described embodiments and examples, and various modifications can be made within the scope of the technical idea. Can be implemented.

  As described above, according to the present invention, the following effects are achieved.

  The first effect is that there is no need to manually perform the operation of classifying / aggregating the content in the content server for each content having the same characteristics.

  The reason is that by setting a policy for classifying / aggregating as the same content group in the content management apparatus, it is possible to automatically aggregate according to the static / dynamic characteristics of the content in the content server. Because it can.

  The second effect is that the server load distribution device can realize the optimum request routing according to the content characteristics with the minimum number of entries.

  This is because the content management apparatus automatically classifies / aggregates the content in the content server according to its static / dynamic characteristics.

  A third effect is that a request from a client can be transferred to an optimum server according to the characteristics of the requested content simply by passing through the server load distribution device.

  The reason is that in the server load balancer, for each content group, a transfer destination server is determined based on a selection criterion corresponding to the characteristics, and the determined transfer destination server is registered in the request routing table and received from the client. This is because by identifying which content group the request belongs to, the request can be transferred to the transfer destination server for the corresponding content group.

  The fourth effect is to suppress the rapid concentration of requests from clients to the content server and to prevent the determination of the transfer destination server from oscillating without converging in the request routing table of the server load balancer. .

  The first reason is that the content server does not always respond with actual resource information as it is to a resource information acquisition request from a plurality of server load distribution apparatuses arranged in the network, but rather with a set resource response. This is because, by correcting the resource value according to the policy and responding, it is possible to prevent a large number of server load balancers from simultaneously selecting the same content server as the transfer destination.

  The second reason is that, in the server load balancer, the weight value for each entry transfer destination server is changed according to the acquired resource value, and this weight value is changed gently using move_granularity. This is because a large number of server load distribution devices can be prevented from simultaneously selecting the same content server as a transfer destination.

  The third reason is that the server load balancer probabilistically sets the time for resetting the weight value instead of immediately resetting the weight value for the transfer destination server of each entry according to the acquired resource value. This is because it is possible to prevent a large number of server load distribution apparatuses from simultaneously selecting the same content server as a transfer destination by delaying the distributed time and resetting the weight value if necessary at the delayed time.

  The fifth effect is that the request from the client can be guided to the optimum content server by the layer 4 switch without using the layer 7 switch as the server load balancer, and the processing performance as the server load balancer is improved. Cost reduction can be achieved.

  The reason is that the server load balancer identifies the content group to which the requested content belongs using the domain name server from the destination IP address / destination port number of the packet received from the client, and the optimum content for the content group This is because it is not necessary to analyze the contents (such as URL) of the packet from the client by transferring the packet to the server.

It is a block diagram which shows the structure of the 1st Embodiment of this invention. It is a figure which shows the example of the classification policy set in the classification policy setting part of the 1st Embodiment of this invention. It is a figure which shows the example of the URL rewriting process which the content aggregation part of the 1st Embodiment of this invention performs. It is a flowchart which shows operation | movement of the content management apparatus of the 1st Embodiment of this invention. It is a figure which shows the example at the time of implement | achieving the content management apparatus of the 1st Embodiment of this invention as a one part function of a content server. It is a figure which shows the example with which several content servers are connected to the content management apparatus of the 1st Embodiment of this invention. It is a block diagram which shows the structure of the 2nd Embodiment of this invention. It is a figure which shows the example of the transfer destination server determination policy set in the transfer destination server determination policy setting part of the 2nd Embodiment of this invention. It is a figure which shows the example of the entry registered in the request routing table of the 2nd Embodiment of this invention. It is a flowchart which shows operation | movement when the server load distribution apparatus of the 2nd Embodiment of this invention receives a request from a client. It is a flowchart which shows the operation | movement which the transfer destination server determination part of the server load distribution apparatus of the 2nd Embodiment of this invention determines a transfer destination server. It is a flowchart which shows operation | movement when managing the entry registered into the request routing table in the server load distribution apparatus of the 2nd Embodiment of this invention. It is a block diagram which shows the structure of the 3rd Embodiment of this invention. It is a figure which shows the example of the resource response policy set in the resource response policy setting part of the 3rd Embodiment of this invention. It is a flowchart which shows operation | movement when the content server receives the resource acquisition request from the server load distribution apparatus in the 3rd Embodiment of this invention. It is a block diagram which shows the structure of the 4th Embodiment of this invention. It is a figure which shows the example of the entry registered in the request routing table of the 4th Embodiment of this invention. It is a flowchart which shows operation | movement of the server load distribution apparatus of the 4th Embodiment of this invention. It is another flowchart which shows operation | movement of the server load distribution apparatus of the 4th Embodiment of this invention. It is a block diagram which shows the structure of the 5th Embodiment of this invention. It is a figure which shows the example of the entry registered in the packet routing table of the 5th Embodiment of this invention. It is a figure which shows the example of the entry registered in the address / FQDN resolution table of the 5th Embodiment of this invention. It is a flowchart which shows the operation | movement at the time of the 5th Embodiment of this invention transmitting the request for a client to acquire content. It is a flowchart which shows operation | movement when the server load distribution apparatus receives the packet from a client in the 5th Embodiment of this invention. It is a flowchart which shows the operation | movement which creates an entry in a packet routing table in the 5th Embodiment of this invention. It is a network block diagram in the 2nd Example of this invention. It is a network block diagram in the 3rd Example of this invention. It is a figure which shows the example of the request routing table in a 3rd Example. It is a figure which shows the example in the case of creating the entry of the transfer destination server in the request routing table in a 4th Example.

Explanation of symbols

A1 to A4, 201 to 203 Content server A11 Content storage unit A12 Request reception / content response unit A13, A15 Resource response unit A14 Resource response policy setting unit A16 Dynamic parameter storage unit B1 Content management device B11 Classification policy setting unit B12 Content classification Unit B13 content aggregation unit C1 to C3, 301 to 307 server load distribution device C11 resource acquisition unit C12 transfer destination server determination policy setting unit C13 transfer destination server determination unit C14, C18, 104, 106, 110 request routing table C15 request reception unit C16 Request transfer unit C17 Content reception / transfer unit C19 Weight setting unit C20 Packet transfer unit C21, 107 Packet routing table C22 Transfer destination server decision Fixed unit C23 FQDN resolution unit C24 Address resolution unit C25 Packet reception unit D1, D2 Client D11 Request transmission unit D12 Address resolution unit E1 Domain name server E11 Address / FQDN resolution table 108 Address resolution table 109 FQDN resolution table E12 Address response unit E13 FQDN Response Unit 1 Backbone Network 101 Classification Policy Table 103 Transfer Destination Server Decision Policy Table 105 Resource Response Policy Table A39 Content Distribution Management Program B19 Content Management Program C29, C49, C59 Server Load Balancing Program

Claims (2)

In a content server that distributes content,
A content server comprising: means for notifying a node that selects a distribution destination of the content based on resource information about each server, a value obtained by correcting an actual resource value calculated as the resource information. In a content distribution management program for managing content distribution of a content server that distributes content by controlling a computer,
Content having a function of notifying a value obtained by correcting an actual resource value calculated as currently available resource information to a node that selects a distribution destination of the content based on a resource of each server Delivery management program.

Images