JP2016177376A - Program, information processing device and information processing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To stop a processing part more easily than a method for allocating connection processing for processing a connection request from a user to a processing part having a small load.SOLUTION: A user distribution device 16 determines a VM (virtual machine) 12 in charge of log-in processing if a user has not logged in yet in the case of receiving a connection request from the user. In this determination processing, the user distribution device 16 selects a VM currently executing a job more preferentially than a VM that does not currently execute a job as a log-in destination among VMs 12 in an "activating" state where a job can be received with reference to VM information 22 and job information 24.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a program, an information processing apparatus, and an information processing method.

  2. Description of the Related Art In recent years, systems such as cloud computing services that allow users to use computing resources such as processors and memories possessed by service providers in the form of, for example, a charging method are becoming widespread. Such services generally have a so-called autoscaling function that automatically increases or decreases the computing resources used for processing for the user as necessary. For example, in a cloud service called Amazon EC2 (Elastic Compute Cloud), a virtual machine called an EC2 instance is allocated to a user, and the number of instances is automatically increased or decreased according to the processing load. Generally, increasing the number of instances is called “scale-out”, and decreasing the number is called “scale-in”. For example, when the service usage fee is determined according to the amount of resources used, the usage fee can be saved by automatically reducing the amount of resources used when the processing load is reduced.

  In the invention disclosed in Patent Document 1, the load balancer manages, for each allocated server, a means for estimating the load applied to the server by the service request from the header information of the service request packet and the estimated value. The load distribution based on the real-time load state of the server. Further, by providing a load estimation table generating means for performing load estimation in advance, unnecessary communication and load monitoring processing do not occur when the server system is operating, and the entire server system can be maintained at high performance.

  A load distribution system disclosed in Patent Literature 2 includes an information table that stores information of each of a plurality of servers, and a threshold holding unit that holds a threshold for maintaining each service level of the plurality of servers with respect to a processing status according to a request And a server management unit that monitors and manages the operational status of multiple servers, and when allocating requests to multiple servers, assigns requests from higher priority servers until the threshold is reached, according to the priorities of the multiple servers. A transfer destination determination unit; and a power control unit that performs power control of the plurality of servers in accordance with the processing status of each request of the plurality of servers. As described above, Patent Document 2 discloses that load distribution is performed among servers in order to maintain a service level, and that power control of these servers is performed.

  Patent Document 3 shows that the load of each server is predicted and scale-out or scale-in is performed according to the prediction. That is, in the system disclosed in this document, the load information collection unit collects the load of the physical server and the virtual server, associates each load with the time when the load is collected, and stores it in the load information table as load information. The load information selection unit selects past load information similar to the load at the current time from the load information table when the load to be managed deviates from the scale-out threshold value or the scale-in threshold value. The determination unit assumes that the load to be managed changes according to the selected load information, and performs scale-out or scale-in when it is predicted that the load to be managed will deviate from any threshold after that.

JP 2002-091936 A JP 2011-015196 A JP 2011-118525 A

  When load distribution is performed by a plurality of processing units, new processing requests are generally assigned to processing units with a low load. However, in this assignment method, there is a high possibility that some processing is always assigned to each processing unit. Therefore, even if the overall load is low, the processing unit is stopped and the number of processing units activated. It is difficult to reduce (scale in).

  An object of the present invention is to provide a mechanism that makes it easier to stop a processing unit as compared with a method in which connection processing for processing a connection request from a user is assigned to a processing unit with a low load.

  The invention according to claim 1 is directed to at least one processing unit capable of executing connection processing for processing a connection request from a user and data processing for processing data in response to the data processing request. , Status information holding means for holding data processing execution status information in each processing unit, a connection request received from a user to a processing unit that is executing data processing rather than a processing unit that is not executing data processing This is a program for functioning as a connection request assigning means for preferentially assigning, and a stopping means for stopping a processing unit that is not executing connection processing or data processing.

  The invention according to claim 2 further causes the computer to function as processing request holding means for holding the received data processing request in correspondence with the receiving order until it is assigned to any processing unit, and the connection request The assigning means is an assigned data processing request when assigning each data processing request in the processing request holding means to one of the processing units executing the data processing according to a predetermined rule. 2. The program according to claim 1, wherein the connection request is preferentially assigned to a processing unit whose execution timing of the corresponding data processing ends is later.

  According to a third aspect of the present invention, the connection request allocating unit is configured such that the time until the completion of the currently executed data processing in the processing unit is greater than the user's average connection time for the information processing apparatus set in advance. The program according to claim 1, wherein the connection request is assigned to a processing unit determined to be long.

  In the invention according to claim 4, each process is performed for one or more processing units each capable of executing a connection process for processing a connection request from a user and a data process for processing data in response to the data processing request. Information processing means for storing information on the execution status of data processing in a part, and a connection request received from a user is given priority over a processing part that is executing data processing over a processing part that is not executing data processing The information processing apparatus includes a connection request assigning means to be assigned to the terminal, and a stopping means for stopping the processing unit that is not executing the connection process or the data process.

  According to the fifth aspect of the present invention, each process is performed for one or more processing units each capable of executing a connection process for processing a connection request from a user and a data process for processing data in response to the data processing request. Providing status information holding means for holding information on the execution status of data processing in the section, and the connection request assigning means for executing the data processing of the connection request received from the user than the processing section not executing the data processing The information processing method includes a step of preferentially allocating to a processing unit therein, and a step of stopping a processing unit that is not executing connection processing or data processing.

  According to the first, fourth, or fifth aspect of the present invention, it is possible to make it easier to stop the processing unit as compared with a method in which connection processing for processing a connection request from a user is assigned to a processing unit with a low load.

  According to the second aspect of the present invention, it is possible to make it easier to stop the processing unit with the earlier timing of completing the execution of the data processing assigned according to the rule.

  According to the invention of claim 3, it is possible to easily stop the processing unit that finishes the job earlier than the time when the user is considered to be connected.

It is a figure which shows an example of the system configuration | structure of embodiment. It is a figure which shows an example of the data content of VM (virtual machine) information. It is a figure for demonstrating the state transition of VM. It is a figure which shows an example of the data content of job information. It is a figure which shows the example of the procedure of auto scale control. It is a figure which shows the example of the whole procedure of a user distribution process. It is a figure which shows the example of the procedure of a login destination determination process. It is a figure which shows the 1st example of the procedure which selects a login destination from VM of a starting state. It is a figure which shows the 2nd example of the procedure which selects a login destination from VM of a starting state. It is a figure which shows the 3rd example of the procedure which selects a login destination from VM of a starting state.

  An example of the system configuration of the embodiment will be described with reference to FIG.

  A job processing system 10 shown in FIG. 1 provides a service for executing a print job to a user who operates a client 30 such as a PC (personal computer) or a mobile terminal. The print job (hereinafter also simply referred to as “job”) is data processing performed to print document data to be printed designated by the user with a printer. The job processing system 10 receives document data from the client 30 via a network (not shown), converts the document data into print data in a data format that can be handled by a printer (not shown), and sends the converted print data via the network. To provide to the printer and execute printing.

  The job processing system 10 includes zero or more VMs (Virtual Machines) 12, and each of the VMs 12 executes a job corresponding to a print instruction from a user. The VM 12 may be constructed on, for example, an infrastructure provided by an IaaS (Infrastructure as a Service) provider. Similarly, the VM management device 14 and the user distribution device 16 to be described later may also be constructed on a virtual machine constructed on the infrastructure, and the shared storage 20 may be a storage on the infrastructure. .

  The job processing executed by the VM 12 includes processing for converting document data into print data, processing for transmitting the conversion result print data to a printer designated by the user, and converting document data into an image and extracting information from the image. And processing for transferring the processing result to another server.

  Each VM 12 executes user interface processing for processing a request from a user in addition to processing of an assigned job. The user interface process includes a login process for determining whether or not a user can connect to the job processing system 10 (login), a process for accepting setting of parameters (for example, print attributes such as the number of copies), and a job execution start request. This includes processing to receive, processing to receive a job status confirmation request, and provide job status information to the user.

  In this example, the processing requests received by the VM 12 from the user (client 30) include three types of login requests, job execution requests, and job status confirmation requests.

  When the login request is received from the client 30, the VM 12 to which the login request is assigned from the user distribution device 16 determines whether or not to allow the user to log in using user authentication information such as a password received from the client 30. If login is permitted, the user is logged in to the job processing system 10. A request from a logged-in user is received and processed by the VM 12 that has accepted the login. That is, the user can also be regarded as logging in to the VM 12.

  In the login state, for example, print data and print parameters are input to the VM 12 from the user (client 30). Then, the VM 12 issues a unique job identifier and stores the input information in the shared storage 20 in association with the job identifier (job information 24). Thereafter, when a job execution request is input from the client 30 to the VM 12, the VM 12 adds the job identifier to the end of the queue (print queue: not shown). When each VM 12 can accept the next job, it accepts the head job of the queue. Accordingly, the VM 12 that has received the login request or job execution request does not always execute the job according to the request.

  When the user wants to check the status of a job queued, the user requests confirmation of the job status. In response to this, a job status confirmation request is sent from the client 30 to the job processing system 10. Upon receiving this request, the VM 12 in the system 10 returns information indicating the current state of the job that is the request target to the client 30.

  When the user explicitly requests logout, or when no operation is performed for a predetermined time and a timeout occurs, the user's login state is canceled. If the user makes a request to the job processing system 10 after canceling the login, it is necessary to log in again. For example, if a user logs in, submits a job, makes a job execution request, the login is canceled, and then the user wants to know the status of the job, the user makes a login request again. After logging into the system 10, a job status confirmation request is made.

  The VM management device 14 is a device that manages the VM 12, and for example, activates the VM 12 in a stopped state or stops the VM 12 in an activated state (that is, an operating state). For example, the upper limit number of the activated VMs 12 in the job processing system 10 is determined by a contract between the operator of the job processing system 10 and the IaaS provider. Even when the activated VM 12 alone cannot sufficiently cope with the load, if the number of activated VMs does not reach the upper limit, the processing capacity of the system can be improved by activating the deactivated VM 12. Yes (scale out). Further, when the system load is reduced, the metered charge of the IaaS provider according to the number of the activated VMs 12 can be suppressed by stopping the activated VMs 12 (scale-in).

  The user distribution device 16 distributes (assigns) a request from the user (client 30) to one of the VMs 12. The procedure for determining the login request distribution destination will be described later with a specific example. Requests after login (for example, job execution requests and job status confirmation requests) are distributed to VMs 12 that have performed login processing using a conventional session maintenance technique, and overhead for passing session information between VMs 12 May be eliminated.

  The shared storage 20 is a storage device that is shared among the VM 12 group, the VM management device 14, and the user distribution device 16. The shared storage 20 stores VM information 22 and job information 24, and the VM 12 group, the VM management device 14, and the user distribution device 16 proceed with processing while referring to these information.

  FIG. 2 shows an example of the data contents of the VM information 22. In this example, the VM information 22 includes, for each VM 12, a “VM identifier” that uniquely identifies the VM 12, a “state” of the VM 12, a “maximum number of users” that the VM 12 can accept at the same time, The number of logged-in users (“logged-in users”), a list of user identifiers of currently logged-in users (“logged-in users”), the “maximum number of jobs” that the VM 12 can execute in parallel, and the VM 12 A list of job identifiers of currently executing jobs (“current job”) is registered. One row of the table shown in FIG. 2 is management information of the VM 12 corresponding to the row.

  “Maximum number of jobs” and “maximum number of users” are values determined in advance according to the processing capacity of each VM 12. In the illustrated example, these values are the same for all the VMs 12, but when the capabilities differ for each VM 12, those values also differ for each VM 12.

  As the “state” of the VM 12, an “idle” state may be provided in addition to the above-described “start” and “stop” states. The “activated” state is a state in which the VM 12 has been activated, that is, a state in which a job or user interface process can be executed. The “stop” state is a state where the VM 12 is stopped. The VM information 22 includes management information of the VM 12 in the “stopped” state, but the VM 12 does not already exist on the cloud computing infrastructure. In order for a VM 12 in a “stopped” state (existing only as management information) to execute a job or a user interface process (accepting a request from a user, etc.), a startup process for starting the VM 12 is necessary. Takes some time. The “idle” state is an intermediate state between the “start-up” state and the “stop” state, that is, a preparation stage for “stop”. In this state, the VM 12 has not yet stopped, but does not accept a new job and does not execute user interface processing. To perform these things, the VM 12 needs to return to the “activated” state. However, since the VM 12 in the “idle” state has not been stopped yet, it can return to the “started” state almost immediately without executing the start process, and a new job or user interface process can be executed.

  The contents of the VM information 22 are updated as needed by the VM management device 14, the user distribution device 16, and each VM 12. For example, when the VM management apparatus 14 changes the state of the VM 12, the “state” of the VM 12 in the VM information 22 is updated to the value after the transition. When the user distribution device 16 distributes a login request from a user to any VM 12, 1 is added to the “number of login users” of the VM 12 in the VM information 22. Further, when the VM 12 executes login processing to authenticate the user, the user identifier is added to the “login user” column. When a user who is logged in to the VM 12 logs out, the “number of login users” of the VM 12 is decremented by 1, and the user identifier of the user is deleted from the “login user” column. When the VM 12 acquires a new job from the queue and starts execution, the job identifier of the job is added to the “job being executed” column. When the VM 12 completes the execution of the job, the job identifier of the job is deleted from the “execution job” column.

  FIG. 3 shows state transitions among the three states “stop”, “start”, and “idle” in this example. First, the transition from “stop” to “start” occurs at the time of initial startup of the job processing system 10 or scale-out under the management of the VM management device 14. At the time of initial activation, the VM 12 having a predetermined lower limit number of standby VMs is activated and enters the “activated” state. In this example, the job processing system 10 can respond to a certain amount of requests immediately by always keeping at least the lower limit number of VMs 12 in the “activated” (or “idle”) state. The VM 12 in the “activated” state typically executes a job or user interface processing. When there is no user logged in to the VM 12 in the “activated” state, and the next job to be assigned to the VM 12 is not in the queue, the VM 2 transitions to the “idle” state. The VM 12 in the “idle” state returns to the “started” state in response to an idle release instruction from the VM management device 14. The idle release instruction is issued when the upper limit load (the maximum number of users or the maximum number of jobs) of the VM 12 group in the “activated” state is exceeded. Further, when a predetermined time elapses without receiving an idle release instruction after transition to the “idle” state, the VM 12 transitions to a “stop” state. However, if the VM 12 is “stopped” and the number of “started” or “idle” VMs falls below the lower limit number of standby VMs, the “idle” state is maintained without being “stopped”.

  FIG. 4 shows an example of the data content of the job information 24. The job information 24 includes, for each job, a “job identifier” that uniquely identifies the job, a user identifier of the user who submitted the job (“user”), a print image quality setting (“setting”) of the job, Information (“total page”) indicating the storage location (“input”) of print data to be printed in the job, the total processing load of the job (in other words, the time required for the VM 12 to process the job), Each item of the current “status” of the job and information indicating the processed amount of the job (“completion page”) is included. In this example, the load of job processing executed by the VM 12 is roughly proportional to the size of the image to be printed (paper size) and, of course, also proportional to the number of pages. For this reason, the total amount of processing load of the job and the processed amount are expressed as a combination of the paper size and the number of pages. For example, in the example of FIG. 4, the total processing load of the job “Job1” is 10 pages of A4 size, and the processing of 4 pages of A4 size has been completed at this time.

  The contents of the job information 24 are updated as needed by each VM 12. For example, when the VM 12 receives a job execution request from a user, a unique job identifier is generated, an entry corresponding to the job identifier is created in the job information 24, and the “user” that issued the request is included in the entry. The values of “setting” for the job (entered by the user before issuing the execution request), “input” indicating the print data storage location of the job, and “total page” of the job are registered. At this time, the job is in a “waiting for execution” state and is queued in the order in which execution requests are received. When one of the VMs 12 acquires a job in the queue and starts execution, the “status” of the job in the job information 24 is changed to “(executed by the VM 12)”, and the VM 12 Every time one page of the above process (for example, conversion to a printable data format) is completed, 1 is added to the number of pages of “completed page” of the job.

  Next, an example of autoscale control executed by the VM management apparatus 14 will be described with reference to FIG. The auto scale control means that the number of VMs 12 in the “activated” state is increased by starting the VM 12 (scale-out), or the number of VMs 12 in the “activated” or “idle” state is decreased by stopping the VM 12. (Scaling-in) control.

  The VM management apparatus 14 periodically repeats the process of FIG. In this process, first, a change in the total number of jobs being executed and jobs in the queue (waiting for processing) as compared with the previous process is determined (S10). If the total number has increased from the previous time, it is determined whether the total number is equal to or less than a threshold for the number of executable jobs (S12). This threshold is a threshold determined according to the total number of jobs that can be executed simultaneously by the job processing system 10. The total number is the sum of the “maximum number of jobs” of the VM 12 in the “activated” state. For example, the total value itself may be used as the threshold value, or a value obtained by multiplying the total number by a predetermined coefficient may be used as the threshold value. When the determination result in S12 is Yes, the job group of the current job processing system 10 can be processed without degrading the quality of service by the VM 12 group that is “running”, and therefore the number of VMs 12 need not be increased or decreased. In this case, the process of FIG.

  When the determination result in S12 is No, it is difficult for the job group of the current job processing system 10 to be processed without degrading the service quality only with the “active” VM 12 group. In this case, the VM management device 14 searches the VM information 22 for the VM 12 in the “idle” state (S14). When there is a VM 12 in the “idle” state (Yes in S14), the “idle” state of the VM 12 is canceled (S16). As a result, the VM 12 enters the “activated” state, and the number of “activated” VMs 12 that can accept and process a new job increases. Since the VM 12 that has been released from the “idle” state does not need to be activated, it immediately returns to the “activated” state, acquires a job from the queue, and processes it.

  If there are a plurality of “idle” VMs 12, one (or a predetermined number) is selected from them according to a preset selection criterion and “idle” is canceled. As selection criteria, for example, (a) criteria for selecting VM identifiers in ascending order, (b) criteria for selecting in descending order of activation timing, (c) criteria for selecting in ascending order of activation timing, etc. There is. These criteria are simple selection criteria that do not take into account the timing at which the VM 12 in the “idle” state can be scaled in. On the other hand, as an example of a selection criterion that takes into account the timing at which the scale-in can be performed, there is a criterion in which selection is made preferentially as the elapsed time from the transition to the “idle” state is shorter. Since the “idle” state is easily maintained when the elapsed time is long, it is unlikely that the VM 12 that can be scaled in a little will return to the “activated” state. As another example of the selection criterion, there is a criterion that among the “idle” VMs 12, the VM 12 having a longer remaining time until the processing of the job being executed is selected is preferentially selected. The longer the remaining time, the later the timing at which scale-in (transition to the “stop” state) becomes possible, so according to this criterion, the VM 12 that is more likely to scale in (short remaining time) returns to the “started” state. It is hard to happen. Here, as a value indicating the length of the remaining time, a value obtained by subtracting “completion page” from “total number of pages” of the job being executed by the VM 12 of “idle” from the VM information 22 and the job information 24. Use it. At this time, the “total number of pages” and the “completed pages” are converted into the number of pages in the reference paper size, and the above-described subtraction is performed.

  When the determination result in S14 is No (that is, there is no “idle” VM), the VM management apparatus 14 has reached the upper limit number of VMs 12 that can be activated, which is determined by a contract or the like, in the “activated” state. Or not (less than the upper limit number) (S18). When the result of this determination is No (less than the upper limit number), the VM management device 14 activates one (or a predetermined number) of VMs 12 in the “stop” state (scale-out) (S20). As a result, the activation process of the VM 12 is executed, and after the time necessary for the activation process has elapsed, the VM 12 enters the “activation” state and accepts and executes a new job.

  If it is determined in S10 that there is no change in the number of jobs between the previous time and the current time, the VM management apparatus 14 further sets the number of users logged in to the job processing system 10 ("number of login users" in FIG. 2). A change from the previous time is determined for the total number of the sum of all VMs) and the number of users waiting for login (login request is made but login is not yet permitted) (S22). If it is determined in S22 that the total number has increased from the previous time, the VM management apparatus 14 determines whether or not the total number exceeds a threshold value regarding the number of users that can be accepted by the job processing system 10 (S24). ). This threshold value is a threshold value that is determined according to the total number of logged-in users that can be simultaneously accepted by the job processing system 10. The total number is the sum of the “maximum number of users” of the VM 12 in the “activated” state. For example, the total value itself may be used as the threshold value, or a value obtained by multiplying the total number by a predetermined coefficient may be used as the threshold value. If the determination result in S24 is No, the user group currently logged in or waiting to log in can be accepted without degrading the quality of service by the “active” VM 12 group, and thus the number of VMs 12 need not be increased or decreased. In this case, the process of FIG.

  When the determination result in S24 is Yes, the currently logged-in or waiting-for-login user group cannot accept the service without degrading the service quality by the “active” VM 12 group. In this case, the VM management apparatus 14 attempts to increase the number of VMs 12 in the “activated” state by the processes of S14 to S20 described above.

  If it is determined in S22 that the total number of users who are logged in and waiting for login has decreased from the previous time or is the same as the previous time, the VM management apparatus 14 has no job to be executed next in the VM 12 in the “activated” state, Then, it is determined whether there is any user who is not logged in (S26). If there is no corresponding VM 12, the process ends. When there is a corresponding VM 12 (judgment result is Yes), the VM management device 14 changes the state of the VM 12 from “started” to “idle”, and sets a predetermined waiting time in a timer associated with the VM 12. Then, timing (countdown) is started (S28). This timer is reset when the VM 12 is returned to the “activated” state. When the remaining time of the timer becomes 0, the VM management apparatus 14 transitions the VM 12 to the “stop” state.

  Next, an example of processing executed by the user distribution device 16 will be described with reference to FIG. This process is started when the user operates the web browser on the client 30 to connect to the job processing system 10. In this case, the user distribution device 16 checks whether or not the connected user has been logged in, for example, by referring to the VM information 22 (FIG. 2) or using a general session management technique such as Cookie (see FIG. 2). S32). As a result of this investigation, if it is determined that the user has logged in (that is, logged in to any VM 12) (the determination result in S34 is Yes), the user is currently logged in with reference to the user distribution information. The VM 12 is specified (S36), and the process for the connection from the user is assigned to the specified VM 12 (S38). The user distribution information is information indicating the VM 12 to which a logged-in user has logged in. In this procedure, the connection request from the logged-in user is allocated to the VM 12 to which the user has logged in (ie, the session is maintained) using the user distribution information.

  In one example, the user distribution information referred to here is information on a correspondence relationship between the “VM identifier” and the “login user” in the VM information 22 (FIG. 2).

  As another example, a general session maintenance method such as Cookie may be used. In the case of session maintenance using Cookie, the job processing system 10 returns Cookie information including the session ID to the web browser as a response at the time of login. The web browser sends the cookie information to the job processing system 10 at the next HTTP request. The correspondence between the session ID and the VM identifier of the login VM 12 may be stored as user distribution information. If the cookie information is attached to the connection (HTTP request) from the web browser, the VM identifier corresponding to the session ID in the cookie information is obtained from the user distribution information, and the connection is made to the VM 12 corresponding to the VM identifier. Can be sorted. Also, if the web browser does not send a cookie, it means that the cookie has expired and the user's login status has timed out, that is, the user is not logged in (not logged in). it can.

  If it is determined in S34 that the connected user has not been logged in (that is, has not logged in), the user distribution device 16 executes the login destination determination process (S40; details will be described later), thereby determining the VM 12 of the login destination. The connection is distributed to the determined VM 12 (S38).

  Next, an example of the procedure of the login destination determination process will be described with reference to FIG. In this procedure, the VM 12 in the “activated” state is preferentially determined as the login destination over the VM 12 in the “idle” state.

  In this procedure, first, the user distribution device 16 refers to the VM information 22, and the VM 12 that is in the “activated” state and whose “number of login users” has not reached the “maximum number of users” is a candidate for a login destination. A candidate VM is extracted (S42). It is determined whether or not one or more candidate VMs have been extracted (S44). If one or more candidate VMs have been extracted, a login destination of the user is selected from the candidate VMs (S46). Several specific examples of the selection process in S46 will be described later.

  If it is determined in S44 that there is no candidate VM, the user distribution device 16 determines whether there is a VM 12 in the “idle” state (S48). If there is a VM 12 in the “idle” state, a user login destination is selected from the VMs 12 (S50). This selection may be performed in accordance with the same selection criteria as in selecting the release target of the “idle” state from the plurality of VMs 12 in the “idle” state in S16. When the VM 12 in the “idle” state as the login destination is selected, the “idle” state of the selected VM 12 is released, and thus the user distribution device 16 is returned to the VM 12 that has returned to the “activated” state. Allocates processing for connection requests from the user.

  If it is determined in S48 that there is no VM 12 in the “idle” state, the user distribution device 16 determines whether there is a VM 12 in the “stop” state in the VM information 22 (S52). The fact that there are VMs 12 in the “stop” state means that the number of VMs 12 in the “start” state has not reached the upper limit number of VMs 12 determined by a contract or the like. In this case, the user distribution device 16 selects the VM identifiers in ascending order, selects the stop timings in order from the earlier if started in the past, selects the stop timings in the late order, etc. A login destination is selected from the “stopped” VMs 12. Then, the activation process of the selected VM 12 is started (scale out). Since a certain amount of time is required for the activation process, an activation waiting process such as sending a message prompting the user to wait is executed (S54). When the activation process is completed, the VM 12 is caused to process the connection request of the user. If it is determined in S52 that no VM 12 is “stopped”, it means that the number of VMs 12 in the “started” state has reached the upper limit number of VMs 12 determined by the contract and the like. I can't. In this case, since the connection of the user is not accepted, an unacceptable response is returned to the client 30 (S56).

  Next, a specific example of the process for determining the user login destination from the candidate VMs in S46 will be described. The policy for selecting the login destination is to first select the former as a login destination when there is a candidate VM that is executing a job at the time of the selection and a candidate VM that is not executing a job. . When there are a plurality of candidate VMs executing the job, as a further policy, a policy of selecting the one with the latest timing at which the job execution is completed as the login destination may be used. The timing at which job execution ends may be the timing at which the job currently being executed ends, or it is assumed that job groups in the queue are sequentially assigned to candidate VM groups that are executing jobs. It may be the timing to end the execution of all jobs to which the jobs are assigned. Further, an estimated value of the time when the user is logged in to the VM 12 (an average login time L described later) may be taken into consideration. Several specific examples will be described below.

  First, the processing procedure shown in FIG. 8 will be described as a first example. In this processing procedure, a candidate VM that is presumed to be executing a job until the end is selected as a login destination.

  In this procedure, first, the user distribution device 16 determines whether there is a VM 12 that is executing a job among the candidate VMs (the VMs 12 in the “activated” state and less than the maximum number of users) (S60). In this case, the login destination of the user is determined according to a preset selection criterion (S62). As a selection criterion used here, for example, if there is a VM 12 in which other users are logged in among candidate VMs (however, the number of logged-in users is limited to those less than the maximum number of users), there is a criterion of selecting it. . According to this criterion, since a new login process is not assigned to a candidate VM to which the user has not logged in (this VM 12 has not executed a job), the VM 12 transitions to an “idle” state (and eventually) The direction of “stopping” is difficult to be hindered. Since user interface processing such as login processing generally has a lower load than job execution, service quality such as processing speed is unlikely to deteriorate even if users are concentrated within the maximum number of users. As another selection criterion, another criterion such as the above-described criterion (a), (b), or (c) may be used.

  When the determination result in S60 is Yes, the remaining time of the job being executed (that is, the time from the current time until the processing of the job is completed) with respect to the variable “total time” for each candidate VM being executed. Is set (S64). The variable “total time” indicates that each job in the queue at the time of the determination is distributed to each candidate VM during job execution in accordance with a preset job distribution rule. This is a variable for indicating the time required for finishing processing of all jobs to which candidate VMs are distributed. The example of FIG. 8 is an example in the case of using the job distribution rule that the VM 12 obtains the next job from the queue when the processing of one job is completed and the next job can be accepted. Note that it is assumed that a candidate VM that has not executed a job shifts to an “idle” state early and therefore does not go to the job queue. The remaining time of the job being executed can be obtained by referring to the VM information 22 and the job information 24 and subtracting the “completion page” from the “total page” of the job being executed by the candidate VM (the former and Subtract after converting the latter to the number of pages at the standard page size). The time required to execute the job is almost proportional to the paper (page) size and is also almost proportional to the number of pages. Therefore, the number of remaining pages of the job in terms of the standard page size (“total pages” − “completed pages”) Is approximately proportional to the time remaining until the job is completed. Therefore, the remaining page number in terms of the reference page size is used as an index value for the remaining time of the job.

  Next, the calculation processing of S68 to S72 is repeated until there are no uncalculated jobs (that is, the calculations of S68 to S72 have not yet been tried) among jobs in the queue (jobs waiting to be executed) (S66).

  In S68, the required time R of the uncalculated head job in the queue is estimated. In this estimation, the “total pages” of the job may be converted into the number of pages at the reference page size, and the conversion result may be used as the index value R for the required time. Next, in S70, the VM with the shortest total time is selected from the candidate VMs that are executing the job. The selected VM is a VM that is estimated to acquire (distribute) an uncalculated head job in the queue at the time of S70. In S72, the required time R estimated in S68 is added to the total time of the selected VM. This simulates job distribution.

  When the simulation of the distribution of the last job in the queue is completed, the determination result in S66 is No, and the user distribution device 16 selects the VM 12 with the longest total time as the distribution destination of the current login process (S74). ).

  According to the process of FIG. 8, the candidate VM that is estimated to be executing the job until the end is selected as the login destination of the current user. In this way, by concentrating login processing (and thus other user interface processing subsequent thereto) on the VM 12 that has a high possibility of executing the job to the end, the VM 12 that is not executing the job even in the activated state can be obtained. Since the user interface process is difficult to be assigned, it becomes easier to shift to the idle state, and thus easier to stop. Further, even in the VM 12 that is executing a job, the VM 12 in which the assigned job group ends earlier is less likely to be assigned the user interface process than the VM 12 that ends later, so that the VM 12 also shifts to an idle state relatively. It becomes easy.

  Next, another example of the process of S46 (login destination selection) will be described with reference to FIG. In this example, the user distribution device 16 obtains the remaining execution time R of the job being executed by each candidate VM, and selects the candidate VM having the longest remaining time (referred to as VM-R for convenience) (S80). Next, it is determined whether or not the remaining job execution time R of the selected candidate VM is longer than the average login time L of the user (S82). The average login time L is an average value of the time from when various users log in to the job processing system 10 (that is, one of the VMs 12) until the user logs out due to an explicit or no-operation timeout, and the job processing system 10 This is a value that the operational side of knows empirically. If the determination result in S82 is Yes, the candidate VM-R selected in S80 is selected as the login destination (S84). Otherwise, the login destination is selected according to the same criteria as the selection criteria used in S62 of the procedure of FIG. 8 (S86).

  As described above, in the processing procedure of FIG. 9, while the user who is going to distribute this time is considered to be logged in (that is, the average login time L), the user is considered to be a candidate VM that is considered not to end the job being executed. It will be distributed. Therefore, even if a job is being executed, it is difficult for a user to be assigned to a candidate VM that is likely to end execution while the user is logged in. Therefore, such a candidate VM is in an idle state (and thus in a stopped state). ). VMs other than the candidate VMs can further easily shift to the idle state or to the stopped state.

  Next, still another example of the processing of S46 (login destination selection) will be described with reference to FIG. In this example, the user distribution device 16 checks whether there is a candidate VM that is executing a job (S90), and if there is such a candidate VM, the remaining execution time of the job that is currently being executed A candidate VM-R with the longest R is obtained, and the obtained VM-R is selected as a login destination (S92). If there is no candidate VM during job execution, a login destination is selected according to the same criteria as the selection criteria used in S62 of the procedure of FIG. 8 (S94).

As described above, in the processing procedure of FIG. 10, the user is assigned to the candidate VM whose end is the slowest in the job currently being executed. Therefore, even if a job is being executed, it is difficult for a user to be assigned to a candidate VM that is considered to end the job currently being executed earlier than the VM-R. ). VMs that are not executing jobs or VMs other than candidate VMs can more easily transition to an idle state or to a stopped state.
The embodiments of the present invention have been described above. If a login process (or subsequent user interface process) is assigned to a VM 12 that is not executing a job, that VM 12 cannot be stopped (scaled in). In this embodiment, the VM 12 that is executing a job is given priority. Since the login destination is selected, the VM 12 that is not executing the job can easily scale in. Further, in this embodiment, since the login destinations are selected in order from the VM 12 that can be estimated that the job is executed until the latest, the VM 12 that finishes the job earlier than that becomes easier to scale in.

  In the above, an example in which the job processing system 10 provides a print job execution service to a user has been described. However, the job processing system 10 executes other jobs such as data processing and image transfer processing on a scanned image. It may be. In this case, the client 30 may be a scanner, a facsimile machine, a multifunction machine (an apparatus having functions such as a printer, a scanner, a copier, and a facsimile machine).

  Further, even in a system in which job processing and user interface processing are distributed and executed by physical computers rather than virtual machines, the computers of the above embodiment are used to start (scale out) or stop (scale in) those computers. Can be controlled.

  The VM 12, the VM management device 14, and the user distribution device 16 exemplified above are realized by, for example, causing a general-purpose computer to execute a program representing the processing of each device. Here, the computer includes, as hardware, a microprocessor such as a CPU, a memory (primary storage) such as a random access memory (RAM) and a read only memory (ROM), an HDD controller that controls an HDD (hard disk drive), Various I / O (input / output) interfaces, network interfaces that perform control for connection to a network such as a local area network, and the like have a circuit configuration connected via a bus, for example. Also, portable non-volatile recording of various standards such as a disk drive and a flash memory for reading and / or writing to a portable disk recording medium such as a CD or a DVD via the I / O interface, for example. A memory reader / writer for reading from and / or writing to a medium may be connected. A program in which the processing contents of each functional module exemplified above are described is stored in a fixed storage device such as a hard disk drive via a recording medium such as a CD or DVD, or via a communication means such as a network, and stored in a computer. Installed. The program stored in the fixed storage device is read into the RAM and executed by a microprocessor such as a CPU, thereby realizing the functional module group exemplified above. Some or all of these functional module groups are used as hardware circuits such as dedicated LSI (Large Scale Integration), ASIC (Application Specific Integrated Circuit), or FPGA (Field Programmable Gate Array). It may be configured.

10 job processing system, 12 VM (virtual machine), 14 VM management device, 16 user distribution device, 20 shared storage, 22 VM information, 24 job information, 30 clients.

Claims (5)

Computer
For each of one or more processing units capable of executing connection processing for processing a connection request from a user and data processing for processing data in response to the data processing request, Status information holding means for holding information,
A connection request assigning unit that preferentially assigns a connection request received from a user to a processing unit that is executing data processing over a processing unit that is not executing data processing;
Stop means for stopping a processing unit that is not performing connection processing or data processing,
Program to function as. The computer,
It further functions as a processing request holding means for holding the received data processing request in correspondence with the receiving order until it is assigned to any processing unit, and
The connection request assigning means assigns each data processing request in the processing request holding means to the assigned data when assigned to any of the processing units executing the data processing according to a predetermined rule. The connection request is preferentially assigned to a processing unit with a slower timing at which execution of data processing according to the processing request is completed,
The program according to claim 1. The connection request allocating unit is a processing unit that determines that the time until the completion of the currently executed data processing is longer than the user's average connection time for the information processing device set in advance. Assigning the connection request to
The program according to claim 1. For each of one or more processing units capable of executing connection processing for processing a connection request from a user and data processing for processing data in response to the data processing request, Status information holding means for holding information;
A connection request assigning means for preferentially assigning a connection request received from a user to a processing unit that is executing data processing over a processing unit that is not executing data processing;
Stop means for stopping a processing unit that is not executing connection processing or data processing;
An information processing apparatus including: For each of one or more processing units capable of executing connection processing for processing a connection request from a user and data processing for processing data in response to the data processing request, Providing status information holding means for holding information;
A step in which the connection request assigning means assigns a connection request received from a user preferentially to a processing unit that is executing data processing over a processing unit that is not executing data processing;
A step of stopping a processing unit that is not executing connection processing or data processing;
An information processing method including:

Images