JOB MANAGEMENT PROGRAM, JOB MANAGEMENT SYSTEM, AND JOB MANAGEMENT METHOD

Abstract

To timely change a host group managed by job management software when collaborating the job management software with a cloud service.SOLUTION: A job operation system 9 extracts host information on an autoscale target and an autoscale type by a function service 3 included in the cloud service 9A with autoscale of any of job execution servers 5 as a trigger when collaborating a schedule server 4, which executes batch processing in which a plurality of jobs is executed in a predetermined order by distributing the processing to a plurality of job execution servers 5, with a cloud service 9A with an autoscale function. The job operation system 9 changes host group information 41 in the schedule server 4 on the basis of the extracted host information and autoscale type.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a job operation program and the like. [Background technology]

[0002] In recent years, with the spread of public clouds, the use of on-premise to cloud is also increasing in the field of job management. Job management refers to controlling the start and end of multiple jobs, and monitoring and reporting the execution status of each job. Jobs include batch processing. By using the auto-scaling function of the cloud for job management, a highly reliable system that takes advantage of elasticity can be easily built. Examples of such clouds include Amazon EC2 (Amazon Elastic Compute Cloud) (registered trademark) and Microsoft Azure (registered trademark).

[0003] However, the distributed processing and auto-scaling functions provided by the cloud are designed for online processing, and are known to be unsuitable for offline batch processing. Therefore, instead of using the distributed processing and auto-scaling functions provided by the cloud, job management software is used that prepares in advance the number of resources required for batch processing by the number of execution servers, and then performs distributed execution. One example of job management software is Systemwalker Operation Manager (registered trademark).

[0004] Figure 9 is a reference diagram showing distributed execution using job management software. As shown in Figure 9, the number of execution servers required for batch processing is prepared in advance. Then, in the schedule server on which the job management software is installed, for example, an operations manager registers information about the number of execution servers required for batch processing in a host group in advance. The job management software on the schedule server then finds the execution server with the least load and submits the specified job, thereby achieving distributed processing.

[0005] Regarding load balancing, a load balancing control method has been disclosed for a distributed processing system that monitors the load status of each of multiple host computers and distributes and executes business processing across multiple host computers based on the monitoring results (see, for example, Patent Documents 1 and 2).

[0006] However, because the maximum number of execution servers available are always in operation, there is a problem in that the resources of the unused execution servers are wasted. This requires coordination between the distributed execution function of the job management software and the auto-scaling function provided by the cloud.

[0007] Fig. 10 is a reference diagram of a simple link between job management software and a cloud. As shown in Fig. 10, a system is shown in which the distributed execution function of the job management software is linked with the auto-scaling function of the cloud. In this system, <1> The cloud's auto-scaling function performs auto-scaling based on triggers obtained based on resource planning and metrics. <2> The operations administrator checks the host names of the execution servers that have been added or removed by autoscaling. <3> The operations manager edits the host groups of the scheduling server, and the job management software of the schedule server distributes and executes jobs based on the host groups. [Prior art documents] [Patent documents]

[0008] [Patent Document 1] Japanese Patent Application Publication No. 4-267465 [Patent Document 2] JP 2011-13870 A Summary of the Invention [Problem to be solved by the invention]

[0009] However, simply linking the job management software with the cloud poses the problem that the host groups managed by the job management software cannot be changed in a timely manner. That is, the operations manager must manually check the host names of the execution servers that have been added or removed by autoscaling and edit the host groups, so the host groups cannot be changed in a timely manner.

[0010] In one aspect, the present invention aims to change a host group managed by a job management software in a timely manner when the job management software and a cloud are linked. [Means for solving the problem]

[0011] In one aspect, when a schedule server that distributes batch processing to execute a plurality of jobs in a predetermined order across a plurality of machines is linked to a cloud service equipped with an auto-scaling function, the job operation program causes a computer to execute a process in which, when auto-scaling of any of the machines is triggered, the program extracts host information and auto-scaling type of the auto-scaling target using a function service included in the cloud service, and changes the host list in the schedule server based on the extracted host information and auto-scaling type. Effect of the Invention

[0012] According to one embodiment, the host list can be changed in a timely manner. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is a diagram illustrating an example of a functional configuration of a job operation system according to an embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of a processing sequence of the job operation system according to the embodiment. [Diagram 3] FIG. 3 is a diagram illustrating an example of a flowchart of a function service process according to the embodiment. [Figure 4]FIG. 4 is a diagram illustrating an example of event information regarding the occurrence of auto-scaling. [Diagram 5] FIG. 5 is a diagram showing an example of a request to add a configuration host. [Figure 6] FIG. 6 is a diagram showing an example of a configuration host deletion request. [Figure 7] FIG. 7 is a diagram illustrating the effect of job operation according to the embodiment. [Figure 8] FIG. 8 is a diagram illustrating an example of a hardware configuration. [Figure 9] FIG. 9 is a reference diagram showing distributed execution using job management software. [Figure 10] FIG. 10 is a reference diagram showing a simple link between job management software and the cloud. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, embodiments of a job management program, a job management system, and a job management method disclosed in the present application will be described in detail with reference to the accompanying drawings. Note that the present invention is not limited to the embodiments. EXAMPLES

[0015] FIG. 1 is a diagram showing an example of a functional configuration of a job operation system according to an embodiment. As shown in FIG. 1, the job operation system 9 operates jobs by linking a job management system 9B with a cloud service 9A. The job management system 9B distributes and executes batch processing, which executes a plurality of jobs in a predetermined order, among a plurality of job execution servers 5. The cloud service 9A is a service equipped with an auto-scaling function 1. Then, the job operation system 9 extracts host information and auto-scaling type of the job execution server 5 to be auto-scaled by a function service 3 included in the cloud service 9A, triggered by auto-scaling of any of the job execution servers 5. Then, the job operation system 9 changes the host group information 41 in the schedule server 4 based on the extracted host information and auto-scaling type. Note that the plurality of job execution servers 5 configured in the job management system 9B are installed on a cloud. Also, it is preferable that the schedule server 4 configured in the job management system 9B is installed on a cloud.

[0016] The cloud service 9A has an auto-scaling function 1, a monitoring function 2, and a function service 3. The cloud service 9A generates, for example, the following information before operation. The cloud service 9A generates instances corresponding to the multiple job execution servers 5, and generates templates of the instances. The cloud service 9A sets the instances to be auto-scaled. The cloud service 9A sets the auto-scaling rules. The auto-scaling rules are determined, for example, from a specified date and time defined as a resource plan or metrics such as the average CPU usage rate of the job execution servers 5.

[0017] The auto-scaling function 1 auto-scales the job execution servers 5 at the distribution destinations, triggered by the resource plan and metrics indicated by the auto-scaling rules. Auto-scaling includes "scale-in" to reduce the number of job execution servers 5 that make up the job operation system 9, and "scale-out" to increase the number of job execution servers 5.

[0018] Furthermore, the auto-scaling function 1 deletes the job execution server 5 that is the target of scale-in based on a function that delays the period from when scale-in occurs until the machine that is the target of scale-in is actually deleted. The delay function can be achieved by using a setting for a lifecycle hook (pause of deletion), for example. The time for pausing deletion can be, for example, one hour as the default and two hours as the maximum. This enables the auto-scaling function 1 to prevent the instance from being deleted at the same time as the scale-in. The delay function is set by the operations manager. This enables the auto-scaling function 1 to prevent abnormal completion of batch processing that is being executed on the job execution server 5 by disconnecting it due to scale-in.

[0019] The monitoring function 2 monitors events. For example, the monitoring function 2 acquires an event of auto-scaling occurrence. Then, the monitoring function 2 launches a change request function for the host group uploaded to the function service 3, and sends event information as a parameter. The event information here is information about the event of auto-scaling occurrence, and includes, for example, a virtualization instance ID and an auto-scaling type corresponding to the job execution server 5 that is the target of auto-scaling. The auto-scaling type can be information indicating scale-in or information indicating scale-out.

[0020] The function service 3 has a host group change request function 31 operable. The host group change request function 31 is uploaded to the function service 3 in advance. For example, the change request function 31 started by the monitoring function 2 extracts the virtualization instance ID of the auto-scaling target from the event information passed as a parameter at the time of starting. The change request function 31 obtains a host name from the extracted virtualization instance ID using a tool provided by the cloud service 9A. The host name here refers to a private IPv4 address assigned when the instance is generated, for example. An example of such a tool is an SDK (Software Development Kit). In addition, the change request function 31 extracts an auto-scaling type from the event information. Then, if the extracted auto-scaling type is scale-in, the change request function 31 transmits a request to the schedule server 4 to delete the obtained host name from the configuration host. If the extracted auto-scaling type is scale-out, the change request function 31 transmits a request to the schedule server 4 to add the obtained host name to the configuration host.

[0021] The schedule server 4 includes host group information 41 , a reception unit 42 , and a change unit 43 .

[0022] The host group information 41 manages host groups. A host group is a collection of host names corresponding to job execution servers 5 configured to execute batch processing. Batch processing executes multiple jobs in a predetermined order. The host group information 41 is generated before operation by using instances generated by the cloud service 9A as constituent hosts. As an example, "host A, host B, host C" is stored in the host group information 41. Here, host A, host B, and host C are host names corresponding to the job execution servers 5, respectively. For example, when the job execution server 5 corresponding to host C is scaled in by the auto-scaling function 1, the schedule server 4 deletes host C from the host group information 41 at the timing of receiving a request to change the constituent hosts from the change request function 31.

[0023] The reception unit 42 receives a request to change a constituent host sent from the function service 3. For example, the reception unit 42 receives a request to delete a constituent host with a host name as a parameter. The reception unit 42 also receives a request to add a constituent host with a host name as a parameter.

[0024] The change unit 43 changes the host group information 41. For example, when a request to delete a host name of a constituent host is received by the reception unit 42, the change unit 43 executes a process of deleting the host name from the host group information 41. In addition, when a request to add a host name of a constituent host is received by the reception unit 42, the change unit 43 executes a process of adding the host name to the host group information 41. This allows the change unit 43 to change the host group information 41 managed by the schedule server 4 in a timely manner.

[0025] [Job operation system processing sequence] 2 is a diagram showing an example of a processing sequence of the job operation system according to the embodiment. Note that host group information 41 is generated in the schedule server 4. The schedule server 4 distributes and executes batch processing, which executes a plurality of jobs in a predetermined order, among a plurality of job execution servers 5.

[0026] First, in the auto-scaling function 1, the operations manager sets a function to delay the period from when scale-in occurs until deletion (S10). The auto-scaling function 1 auto-scales the job execution servers 5 at the distribution destinations, triggered by resource plans and metrics (S20).

[0027] The monitoring function 2 acquires an event that auto-scaling has occurred (S30). Then, the monitoring function 2 starts a change request function for the host group (S40). In addition, the monitoring function 2 transmits event information that auto-scaling has occurred.

[0028] The function service 3 uses a host group change request function to request a change to the constituent hosts of the host group (S50). Note that a flowchart of the processing of the function service 3 will be described later.

[0029] The schedule server 4 accepts a request to change a constituent host (S60). For example, the reception unit 42 accepts a request to delete a constituent host with a host name as a parameter. The reception unit 42 also accepts a request to add a constituent host with a host name as a parameter.

[0030] Then, the schedule server 4 executes a process of adding or deleting a constituent host of the host group in response to the request to change the constituent host (S70). For example, when a request to delete a host name of a constituent host is received, the change unit 43 executes a process of deleting the host name from the host group information 41. Also, when a request to add a host name of a constituent host is received, the change unit 43 executes a process of adding the host name to the host group information 41.

[0031] Thereafter, the schedule server 4 distributes the batch processing to the job execution servers 5 based on the host group information 41 (S80).

[0032] [Function service processing flowchart] 3 is a diagram showing an example of a flowchart of the processing of the function service according to the embodiment, in which the monitoring function 2 transmits event information as a parameter and starts the host group change request function 31.

[0033] 3, the started change request function 31 extracts a virtualization instance ID from the received event information (step S51). The change request function 31 obtains a host name from the virtualization instance ID, for example, by using an SDK (step S52). The change request function 31 extracts an auto-scaling type from the event information (step S53).

[0034] Then, the change request function 31 determines whether the auto scaling type is scale-out (Step S54). If it is determined that the auto scaling type is scale-out (Step S54; Yes), the change request function 31 sends a configuration host addition request for the acquired host name to the schedule server 4 (Step S55). Then, the change request function 31 ends the process.

[0035] On the other hand, if it is determined that the auto-scaling type is scale-in (Step S54; No), the change request function 31 sends a configuration host deletion request for the acquired host name to the schedule server 4 (Step S56). Then, the change request function 31 ends the process.

[0036] [Example of event information] Here, the event information of auto-scaling occurrence will be described with reference to FIG. 4. FIG. 4 is a diagram showing an example of event information of auto-scaling occurrence. In FIG. 4, the event information of auto-scaling occurrence is expressed in JSON format. Here, the case is one in which auto-scaling function 1 has performed scale-out for virtualization instance ID "abcdef". Then, the monitoring function 2 obtains event information of scale-out occurrence as shown in FIG. 4 for virtualization instance ID "abcdef".

[0037] In the event information shown in Figure 4, "12345" is set as the event ID. Additionally, "Scale out", which indicates scale out, is set as the auto-scaling type. "abcdef" is set as the virtualization instance ID.

[0038] [Example of a request to add a configuration host] An example of a request to add a constituent host will now be described with reference to Fig. 5. Fig. 5 is a diagram showing an example of a request to add a constituent host. In Fig. 5, the request to add a constituent host is written in HTML (Hyper Text Markup Language). Here, the change request function 31 sends a request to the schedule server 4 to add the host name "VMabcdef" to the constituent hosts.

[0039] In the request to add a configuration host shown in FIG. 5, "hostgroup1" is set as the host group name to be changed, and "VMabcdef" is set as the host name to be added to the configuration host.

[0040] [Example of a request to delete a configuration host] An example of a configuration host deletion request will now be described with reference to Fig. 6. Fig. 6 is a diagram showing an example of a configuration host deletion request. In Fig. 6, the configuration host deletion request is written in HTML. Here, the change request function 31 sends a request to schedule server 4 to delete the host name "VMabcdef" from the configuration hosts.

[0041] In the request to delete a configuration host shown in FIG. 6, "hostgroup1" is set as the host group name to be changed, and "VMabcdef" is set as the host name to be deleted from the configuration hosts.

[0042] [Effects of job operation] FIG. 7 is a diagram showing the effect of job operation according to the embodiment. As shown in FIG. 7, the job operation system 9 links the job management system 9B with the auto-scaling of the cloud service 9A. Therefore, the schedule server 4 of the job management system 9B can automatically add and delete the host group that manages the job execution server 5 that is the distributed execution destination. That is, the schedule server 4 can change the host group that manages the job execution server 5 in a timely manner. In addition, by using a function that delays the deletion of a machine due to the scale-in of the auto-scaling, it becomes possible to control the job that is being distributed. That is, the auto-scaling function (auto-scaling function 1) makes it possible to prevent abnormal completion of the batch processing being executed on the job execution server 5. As a result, the job operation system 9 can increase or decrease the number of job execution servers 5 in the host group according to the status of the machine, such as not being used, so that the job can be operated with the optimal amount of resources.

[0043] [Effects of the embodiment] According to the above embodiment, the job operation system 9 links the schedule server 4, which distributes and executes batch processing, in which multiple jobs are executed in a predetermined order, to multiple job execution servers 5, with the cloud service 9A equipped with the auto-scaling function 1. When any of the job execution servers 5 is auto-scaled, the cloud service 9A extracts host information and auto-scaling type of the auto-scaling target using the function service 3 included in the cloud service 9A. The schedule server 4 changes the host group information 41 based on the extracted host information and auto-scaling type. According to this configuration, the job operation system 9 links the schedule server 4 with the cloud service 9A equipped with the auto-scaling function 1, thereby making it possible to timely change the host group information 41 managed by the schedule server 4.

[0044] Furthermore, according to the above embodiment, the cloud service 9A uses a function in the function service 3 that requests a change to the host group information 41 to extract the instance identifier and auto-scaling type of the job execution server 5 that is the auto-scaling target from the auto-scaling event information, and obtains the host information of the job execution server 5 from the extracted instance identifier. Then, the cloud service 9A sends a change request for the host group information 41 according to the extracted auto-scaling type to the schedule server 4 using the function that requests a change to the host group information 41. With this configuration, the job operation system 9 can link the auto-scaling of the schedule server 4 and the cloud service 9A by using a function of the function service 3, and can change the host group information 41 of the schedule server 4 in a timely manner.

[0045] Furthermore, according to the above embodiment, the schedule server 4 changes the host group information 41 at the timing when it receives a request to change the host group information 41. With this configuration, the schedule server 4 can change the host group information 41 in real time.

[0046] Furthermore, according to the above embodiment, when auto-scaling is scale-in indicating deletion, the auto-scaling function 1 executes auto-scaling to delete the job execution server 5 based on the setting of the delay time from the trigger of auto-scaling to the deletion of the job execution server 5 that is the target of auto-scaling. With this configuration, the job operation system 9 can prevent abnormal completion of batch processing being executed on the job execution server 5 by using the setting of the delay time of auto-scaling.

[0047] [others] The auto-scaling function 1, the monitoring function 2, and the function service 3 in the cloud service 9A may each be executed by an information processing device or a virtual machine on the cloud service 9A. Also, the auto-scaling function 1, the monitoring function 2, and the function service 3 in the cloud service 9A may each be executed by one information processing device or a virtual machine on the cloud service 9A.

[0048] In the above embodiment, each component of the schedule server 4 is not necessarily physically configured as shown in the figure. In other words, the specific form of distribution and integration of the schedule server 4 is not limited to that shown in the figure, and all or part of it can be functionally or physically distributed and integrated in any unit according to various loads, usage conditions, etc. For example, the change unit 43 may be distributed into a first change unit that executes a process of adding a constituent host and a second change unit that executes a process of deleting a constituent host. Also, the reception unit 42 and the change unit 43 may be integrated.

[0049] Moreover, the various processes described in the above embodiment can be realized by executing a prepared program on a computer such as a personal computer or a workstation. Therefore, an example of the hardware configuration of the schedule server 4 that is responsible for a part of the job operation program that realizes the same functions as the job operation system 9 shown in Fig. 1 will be described below. Note that the auto-scaling function 1, the monitoring function 2, and the function service 3 that are responsible for the other parts of the job operation program that realizes the same functions as the job operation system 9 shown in Fig. 1 also have the same hardware configuration, so their description will be omitted. Fig. 8 is a diagram for explaining an example of the hardware configuration.

[0050] As shown in Fig. 8, the schedule server 4 includes a communication device 100, a hard disk drive (HDD) 110, a memory 120, and a processor 130. The components shown in Fig. 8 are connected to each other via a bus or the like.

[0051] The communication device 100 is a network interface card or the like, and communicates with other devices. The HDD 110 stores programs and DBs that operate the functions shown in FIG.

[0052] Processor 130 is equipped with a cache memory, and reads out a program that executes the same processes as the respective processing units shown in FIG. 1 from HDD 110 or the like and loads it into memory 120, thereby operating a process that executes each function described in FIG. 1 or the like. For example, this process executes a function similar to that of each processing unit of schedule server 4. Specifically, processor 130 reads out a program having the same functions as reception unit 42, change unit 43, etc. from HDD 110 or the like. Then, processor 130 executes a process that executes the same processes as reception unit 42, change unit 43, etc.

[0053] In this way, the schedule server 4 operates as an information processing device that executes part of the job operation method by reading and executing the program. The schedule server 4 can also realize functions similar to those of the above-mentioned embodiment by reading the program from a recording medium using a media reading device and executing the read program. Note that the program in these other embodiments is not limited to being executed by the schedule server 4. For example, the present invention can be similarly applied to cases where another computer or server executes the program, or where these cooperate to execute the program.

[0054] This program can be distributed via a network such as the Internet. This program can also be recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, a magneto-optical disk (MO), or a digital versatile disk (DVD), and can be executed by being read out from the recording medium by a computer.

[0055] The following supplementary notes are further disclosed regarding the embodiments including the above examples.

[0056] (Supplementary Note 1) When a schedule server that distributes batch processing to multiple machines to execute multiple jobs in a predetermined order is linked to a cloud service equipped with an auto-scaling function, the auto-scaling of any machine is triggered by a function service included in the cloud service to extract host information and auto-scaling type that are the target of auto-scaling, Based on the extracted host information and autoscaling type, the host list is updated on the schedule server. A job operation program that causes a computer to execute processing.

[0057] (Additional Note 2) The extraction process includes, in the function service, extracting the instance identifier and auto-scaling type of the auto-scaling target machine from the auto-scaling event information using a function that requests a change to the host list, and obtaining host information of the machine from the extracted instance identifier; A request to change the host list according to the extracted auto-scaling type is sent from the function to the schedule server. 2. The job operation program according to claim 1,

[0058] (Note 3) The process of changing the host list is performed by the schedule server at the timing when the schedule server receives a request to change the host list. 3. A job operation program according to claim 2,

[0059] (Additional Note 4) When the auto-scaling is a scale-in indicating deletion, the auto-scaling function executes auto-scaling to delete the machine based on a delay time setting from the trigger of auto-scaling to the deletion of the machine that is the target of auto-scaling. 2. The job operation program according to claim 1,

[0060] (Note 5) The delay time setting is a lifecycle hook function that temporarily stops the deletion of the machine. 5. A job operation program according to claim 4.

[0061] (Appendix 6) A schedule server that distributes and executes batch processing for executing multiple jobs in a predetermined order across multiple machines; A cloud service equipped with an auto-scaling function, When the schedule server is linked with the cloud service, the cloud service, when auto-scaling of any machine is triggered, extracts host information and an auto-scaling type of an auto-scaling target using a function service included in the cloud service; The schedule server updates the host list based on the extracted host information and auto-scaling type. A job management system comprising:

[0062] (Appendix 7) When a schedule server that distributes batch processing to execute multiple jobs in a predetermined order across multiple machines is linked to a cloud service equipped with an auto-scaling function, the auto-scaling of any of the machines is triggered by a function service included in the cloud service extracting host information and auto-scaling type that are the targets of auto-scaling, Based on the extracted host information and autoscaling type, the host list is updated on the schedule server. A job operation method in which processing is carried out by a computer. [Explanation of symbols]

[0063] 1. Auto-scaling function 2. Monitoring Function 3 Function Services 31 Change Request Functions 4 Schedule Server 41 Host Group Information 42 Reception 43 Changes 5 Job execution server 9 Job Operation System 9A Cloud Services 9B Job Management System

Claims

1. When a schedule server that distributes batch processing, in which a plurality of jobs are executed in a predetermined order, across a plurality of machines is linked to a cloud service equipped with an auto-scaling function, the auto-scaling of any of the machines is triggered by extracting host information and an auto-scaling type that are the target of the auto-scaling using a function service included in the cloud service; Based on the extracted host information and autoscaling type, the host list is updated on the schedule server. A job operation program that causes a computer to execute processing.

2. The extraction process includes, in the function service, extracting an instance identifier and an auto-scaling type of the auto-scaling target machine from the auto-scaling event information using a function that requests a change to the host list, and obtaining host information of the machine from the extracted instance identifier; A request to change the host list according to the extracted auto-scaling type is sent from the function to the schedule server.

2. The job management program according to claim 1.

3. The process of changing the host list is performed by the schedule server at a timing when the schedule server receives a request to change the host list.

3. The job management program according to claim 2.

4. The auto-scaling function executes auto-scaling to delete a machine based on a delay time setting from the trigger of auto-scaling to the deletion of the machine that is the target of auto-scaling, when the auto-scaling is a scale-in indicating deletion.

2. The job management program according to claim 1.

5. A schedule server that distributes and executes batch processing for executing a plurality of jobs in a predetermined order among a plurality of machines; A cloud service equipped with an auto-scaling function, When the schedule server is linked with the cloud service, the cloud service, when auto-scaling of any machine is triggered, extracts host information and an auto-scaling type of an auto-scaling target using a function service included in the cloud service; The schedule server updates the host list based on the extracted host information and auto-scaling type. A job management system comprising:

6. When a schedule server that distributes batch processing, which causes a plurality of jobs to be executed in a predetermined order, to execute the batch processing across a plurality of machines is linked to a cloud service equipped with an auto-scaling function, the auto-scaling of any of the machines is triggered by extracting host information and an auto-scaling type that are the target of the auto-scaling using a function service included in the cloud service; Based on the extracted host information and autoscaling type, the host list is updated on the schedule server. A job operation method in which processing is carried out by a computer.

Images