Job management system, information processing program, and information processing method

Abstract

To surely execute failover of a job management device.SOLUTION: When receiving a first request for requesting the start of the execution of a job in which identification information IDa is designated from a job management device 11, a relay system 20 transfers the first request to a job execution system 30, and receives returned identification information IDb, and stores the identification information IDa and IDb in a storage part 21 in association with each other. Further, the relay system 20 transmits, to the job execution system 30, a third request for requesting the state information by designating the identification information IDb, and stores the returned state information in the storage unit 21 in association with the identification information IDa. When the operation of the job management apparatus 11 is stopped, the job management apparatus 12 takes over, from the job management apparatus 11, the execution of the monitoring process of designating the identification information IDa and transmitting the request for the state information to the relay system 20.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a job management system, an information processing program, and an information processing method. [Background technology]

[0002] In recent years, there have been many cases where jobs for various business processes are executed on cloud services, and high availability is required when such jobs are executed on cloud services.

[0003] The following techniques have been proposed for job management. For example, a server system has been proposed in which a schedule management server is selected from multiple servers each having a job registration request function, and if an abnormality occurs in the schedule management server, a server that will execute the schedule management function in place of the schedule management server is determined according to a predetermined priority order. Another proposed job execution system is one in which, when a job execution server switches over while a job is being executed, a standby server collects job execution status information from the job execution server, determines a restart point for the job flow based on the job execution status information, and instructs the job execution server to continue the job from the restart point.

[0004] Furthermore, as a related technology, a system has been proposed in which, when a request proxy device that proxies requests from a requesting terminal to a first server detects a failure in the first server, it reads terminal request information from a request information management terminal and sends it to a second server, and the second server continues processing the transaction that constitutes the request from the requesting terminal using the terminal request information. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2007-249674 [Patent Document 2] Japanese Patent Application Laid-Open No. 2010-140106 [Patent Document 3] Japanese Patent Application Laid-Open No. 2008-27189 Summary of the Invention [Problem to be solved by the invention]

[0006] The process of having a cloud service execute a job in response to a request from a job management device is performed, for example, as follows: When the job management device requests the start of job execution, the cloud service starts executing the requested job. Thereafter, the job management device periodically obtains status information indicating the execution status of the job from the cloud service, and monitors the job until execution is complete.

[0007] Furthermore, if an operational job management device is unable to continue normal operation or stops due to an abnormality while a job is being executed, a standby job management device will transition to the operational system and take over the job monitoring process. In this case, there is a problem as to what process is required to ensure that the job management device that has transitioned to the operational system can reliably take over the job monitoring process.

[0008] For example, when a cloud service starts executing a requested job, the cloud service assigns unique identification information to the job. In order to obtain job status information from the cloud service, it is necessary to specify the target job using the identification information assigned by the cloud service. However, there is a problem in that it is difficult for a job management device that has transitioned from a standby system to an active system to recognize this identification information.

[0009] In one aspect, the present invention aims to provide a job management system, an information processing program, and an information processing method that enable a job management device to reliably perform a failover. [Means for solving the problem]

[0010] In one proposal, a job management system is provided that includes a first job management device, a second job management device, a relay system, and a job execution system. The first job management device performs an execution request process that transmits a first request specifying first identification information for identifying the job and requesting the start of job execution, and a monitoring process that, after transmitting the first request, repeatedly transmits a second request specifying the first identification information and requesting status information indicating the execution status of the job until the status information transmitted in response to the second request indicates the end of job execution. The second job management device takes over execution of the monitoring process from the first job management device using the first identification information. The relay system, upon receiving a first request from the first job management device, forwards the first request to a job execution system that executes the job, receives second identification information for identifying the job from the job execution system, associates the first identification information with the second identification information and stores them in a storage unit, transmits a third request to the job execution system specifying the second identification information and requesting status information, associates the status information transmitted from the job execution system with the first identification information and stores it in a storage unit, and, upon receiving the second request from the first job management device or a fourth request from the second job management device specifying the first identification information, executes a relay process in which the relay system retrieves the status information associated with the first identification information from the storage unit and transmits it to the sender of the second request or the fourth request. Upon receiving the second request from the relay system, the job execution system starts execution of the job, assigns the second identification information to the job and transmits it to the relay system, and upon receiving the third request from the relay system, transmits job status information to the relay system.

[0011] In one proposal, an information processing program is provided that causes a computer to execute the following relay process. In the relay process, when a first request requesting the start of job execution, which specifies first identification information for identifying the job, is received from a first job management device, the first request is transferred to a job execution system that executes the job, second identification information for identifying the job is received from the job execution system, and the first identification information and the second identification information are associated and stored in a storage unit. In addition, in the relay process, a third request specifying the second identification information and requesting status information indicating the execution status of the job is sent to the job execution system, and the status information sent from the job execution system is associated with the first identification information and stored in the storage unit. In addition, in the relay process, when a second request specifying the first identification information and requesting status information is received from the first job management device, the status information associated with the first identification information is obtained from the storage unit and sent to the first job management device. In addition, in the relay process, when a fourth request specifying the first identification information is received from a second job management device that has taken over the monitoring process of monitoring the job execution status from the first job management device, the status information associated with the first identification information is obtained from the storage unit and sent to the second job management device.

[0012] Furthermore, one idea provides an information processing method in which a computer executes processing similar to the processing based on the above-mentioned information processing program. [Effects of the Invention]

[0013] In one aspect, a failover of the job management device can be reliably executed. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 illustrates a job management system according to a first embodiment. [Figure 2] FIG. 1 is a diagram illustrating a comparative example of a job management system. [Figure 3] FIG. 10 illustrates an example of the configuration of a job management system according to a second embodiment. [Figure 4] FIG. 2 illustrates a hardware configuration of a physical machine. [Figure 5] FIG. 2 is a diagram illustrating an example of the configuration of processing functions included in a job management system. [Figure 6] FIG. 4 illustrates an example of the data configuration of a job management table. [Figure 7] FIG. 10 illustrates an example of the data configuration of a relay job management table. [Figure 8] FIG. 10 illustrates an example of an operation at the start of job execution. [Figure 9] FIG. 10 illustrates an example of an operation during job execution. [Figure 10] FIG. 10 illustrates an example of a failover operation. [Figure 11] 10 is a flowchart illustrating an example of a job execution management process by a job scheduler. [Figure 12] 10 is a flowchart illustrating an example of a job monitoring process by a job scheduler. [Figure 13] 10 is a flowchart illustrating an example of a job execution management process performed by a relay processing unit. [Figure 14] 10 is a flowchart illustrating an example of a job monitoring process performed by a relay processing unit. [Figure 15] 10 is a flowchart illustrating an example of a forced termination process performed by a job scheduler. [Figure 16] 10 is a flowchart illustrating an example of a forced termination process performed by a relay processing unit. [Figure 17] 10 is a flowchart illustrating an example of processing by a job scheduler after a failover. [Figure 18] 10 is a flowchart illustrating an example of a monitoring request response process performed by a relay processing unit. [Figure 19] FIG. 10 is a diagram illustrating a process when an abnormality occurs in a relay processing unit. [Figure 20] 10 is a flowchart illustrating an example of processing performed by a management unit when an abnormality occurs in a relay processing unit. [Figure 21] 10 is a flowchart illustrating an example of processing by a job scheduler when an abnormality occurs in a relay processing unit. [Figure 22] FIG. 10 is a first diagram showing an example of starting and deleting a relay processing unit. [Figure 23] FIG. 10 is a second diagram showing an example of starting and deleting a relay processing unit. [Figure 24] FIG. 10 illustrates a tenant-occupied relay processing unit. [Figure 25] FIG. 10 illustrates a tenant-shared relay processing unit. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. [First embodiment] 1 is a diagram showing a job management system according to a first embodiment of the present invention, which includes job management devices 11 and 12, a relay system 20, and a job execution system 30.

[0016] The job management devices 11 and 12 are physical machines (e.g., server computers) or virtual machines. The job management devices 11 and 12 cause the job execution system 30 to execute jobs via the relay system 20. One of the job management devices 11 and 12 operates as an active system, and the other operates as a standby system. When the active job management device stops, the standby job management device transitions to the active system and takes over the processing that was being executed by the stopped job management device (failover).

[0017] The relay system 20 is a computer system including one or more physical machines (e.g., server computers). The relay system 20 relays a job execution start request sent from the job management device 11 to the job execution system 30. The relay system 20 also holds information required when the job management devices 11 and 12 fail over.

[0018] The job execution system 30 is a computer system including one or more physical machines (e.g., server computers). The job execution system 30 is, for example, a cloud system provided by a cloud service. The job execution system 30 executes a job in response to a request transmitted from the job management device 11 via the relay system 20.

[0019] An example of processing by the job management system from a state in which the job management device 11 is the active system and the job management device 12 is the standby system will be described below. The job management device 11 of the operational system specifies identification information IDa for identifying a job and transmits a first request requesting the start of execution of the job to the relay system 20 (step S1a). The identification information IDa is information for identifying a job on the job management device 11, 12 side, and here, it is assumed that "JB1" is set as the identification information IDa as an example.

[0020] When the relay system 20 receives the first request with the identification information IDa "JB1" set therein, it transfers the first request to the job execution system 30 and requests the job execution system 30 to start executing the job (step S1b). However, the identification information IDa "JB1" does not have to be set in the transferred request.

[0021] When the job execution system 30 receives the first request, it starts executing the job (step S1c), assigns identification information IDb to the job that has started execution, and sends it to the relay system 20 (step S1d). The identification information IDb is information for identifying the job on the job execution system 30 side, and is assigned independently of the identification information IDa. Here, it is assumed that "JB2" is assigned as the identification information IDb.

[0022] When the relay system 20 receives the identification information IDb "JB2" from the job execution system 30, it stores the identification information IDb "JB2" in the storage unit 21 in association with the identification information IDa "JB1" received in step S1a (step S1e).

[0023] Note that status information indicating the execution status of the job is also registered in association with the identification information IDa "JB1" in the storage unit 21. At the time of step S1e, for example, information indicating that the job is waiting to be executed may be registered as the status information.

[0024] After sending the first request, the job management device 11 sends a second request to the relay system 20, specifying the identification information IDa "JB1" and requesting status information of the job (step S2a). Upon receiving the second request, the relay system 20 acquires the status information associated with the identification information IDa "JB1" from the storage unit 21, and sends the acquired status information to the job management device 11 (step S2b).

[0025] The relay system 20 obtains the latest status information at the time of receiving the second request from the storage unit 21 and transmits it. In the example of Fig. 1, the second request is transmitted in step S2a after the status information is updated in step S3c (described later). Therefore, in step S2b, the status information updated in step S3c is transmitted to the job management device 11.

[0026] The job management device 11 repeatedly transmits the second request, for example, at regular time intervals, until the status information indicates that the job has been executed. Therefore, the processes of steps S2a and S2b are repeatedly executed until the status information indicates that the job has been executed. In this way, the job management device 11 manages the execution of the job using the identification information IDa.

[0027] Meanwhile, the relay system 20 specifies the identification information IDb "JB2" and sends a third request to the job execution system 30 requesting status information of the job (step S3a). When the job execution system 30 receives the third request, it sends status information indicating the execution status of the job to the relay system 20 (step S3b). For example, if the job is currently being executed, status information indicating that the job is currently being executed is sent, and if the job execution has finished, status information indicating that the job has finished is sent. The relay system 20 registers the received status information in the storage unit 21 and updates the registered status information (step S3c).

[0028] The relay system 20 repeatedly transmits the third request, for example, at regular time intervals, until the status information indicates that the job has been executed. Therefore, the processes of steps S3a to S3c are repeatedly executed until the status information indicates that the job has been executed. In this way, the relay system 20 manages the execution of the job using the identification information IDb.

[0029] Now, suppose that an abnormality occurs in the job management device 11 while the job is being executed. In this case, a failover is performed, and the job management device 12 transitions from a standby system to an active system. The job management device 12 that has transitioned to the active system takes over the management process of the job that the job management device 11 was executing, using the identification information IDa.

[0030] Specifically, job management device 12 specifies identification information IDa "JB1" and transmits a fourth request requesting status information of the job to relay system 20 (step S4a). When relay system 20 receives the fourth request, it acquires status information associated with identification information IDa "JB1" from storage unit 21 and transmits the acquired status information to job management device 12 (step S4b). If the status information indicates that the job is being executed, job management device 12 determines that the job management process needs to continue, and repeats the transmission of the fourth request in step S4a, as in step S2a. As a result, job management device 12 takes over the job management process that job management device 11 was executing.

[0031] In the above job management system, the relay system 20 processes the job identification information IDa assigned by the job management devices 11 and 12 and the job identification information IDb assigned by the job execution system 30, and the linked information is managed in the storage unit 21. Therefore, after starting job execution, the job management devices 11 and 12 can grasp the job execution status using only the identification information IDa, without recognizing the identification information IDb. Even if a job management device failover occurs, the job management device 12 that has transitioned to the active system can grasp the job execution status using only the identification information IDa and take over job management processing. Therefore, the job management device failover can be reliably executed.

[0032] Second Embodiment Next, a job management system according to a second embodiment will be described. In the following description, a comparative example of a job management system will be described first with reference to Fig. 2, and the job management system according to the second embodiment will be described from Fig. 3 onwards.

[0033] 2 is a diagram showing a comparative example of a job management system, which includes redundant job management machines 110 and 120 and a job execution machine 301. The job management machines 110 and 120 are devices that manage the execution of jobs in the job execution machine 301. The job management machines 110 and 120 may be physical machines such as server computers, or may be virtual machines. The job management machines 110 and 120 include job schedulers 111 and 121, respectively.

[0034] Furthermore, one of the job management machines 110, 120 operates as an active system, and the other operates as a standby system. When the operation of the active job management machine stops, a failover is performed, the standby job management machine transitions to the active system, and the new active job management machine takes over job execution management processing. To improve availability, it is desirable that the job management machines 110, 120 be realized as physical machines or virtual machines in different data centers or data center groups, for example.

[0035] Furthermore, a storage 103 that can be commonly accessed by these machines is connected to the job management machines 110 and 120. Job definition information 103a that defines jobs to be executed is stored in the storage 103. Job schedulers 111 and 121 of the job management machines 110 and 120 schedule jobs to be executed by a job execution machine 301 based on the job definition information 103a, and control the execution of jobs in the job execution machine 301.

[0036] In practice, the storage 103 may be provided separately for each of the job management machines 110 and 120. For example, there may be a storage included in the same data center or data center group as the job management machine 110, and a storage included in the same data center or data center group as the job management machine 120. These storages only need to store the same job definition information 103a.

[0037] The job execution machine 301 is a physical machine or a virtual machine built in a predetermined job execution environment 300, and executes jobs according to external commands. In the example of Fig. 2, the job execution machine 301 is equipped with a job execution agent 301a that receives requests from the job schedulers 111 and 121 and causes the job execution machine 301 to execute jobs.

[0038] In the above job management system, the job schedulers 111 and 121 send job-related requests to the job execution agent 301a, and the job execution agent 301a returns a response. By deploying the job execution agent 301a in the job execution machine 301, it becomes possible for the job schedulers 111 and 121 and the job execution agent 301a to perform independent communication on the job execution request side, regardless of the job execution environment 300.

[0039] 2 will be described below, taking as an example the case where the job management machine 110 is the operational system. The job scheduler 111 of the operational job management machine 110 sends an execution request to the job execution agent 301a of the job execution machine 301, requesting the start of job execution, based on the job definition information 103a. The job execution agent 301a causes the job execution machine 301 to execute the job in accordance with the request. At the same time, the job execution agent 301a generates job execution information 302a and saves it in the storage 302 included in the job execution environment 300. The job execution information 302a includes, for example, a job status indicating the execution status of the job, and is saved in the storage 302 in a format linked to the job identification information specified by the job execution request side.

[0040] The job execution agent 301a monitors the execution status of jobs that have started execution and updates the job status in the job execution information 302a according to the monitoring results. Meanwhile, after execution of a job has started, the job scheduler 111 periodically sends a request to the job execution agent 301a to obtain the job status of that job. When the job scheduler 111 determines from the job status returned from the job execution agent 301a that job execution has been completed, it sends an execution request to the job execution agent 301a to request that the job execution agent 301a start executing the next job.

[0041] If the job management machine 110 abnormally stops, the job management machine 120 transitions from a standby system to an active system. The job scheduler 121 of the job management machine 120 sends a request to the job execution agent 301a to obtain the job status of the job whose execution has not yet been completed. The job execution agent 301a returns the job status of the job to the job scheduler 121 based on the job execution information 302a stored in the storage 302. If the job scheduler 121 determines from the job status that the job execution has not yet been completed, it periodically sends a request to obtain the job status as described above and continues the job execution management process.

[0042] In this way, the job execution agent 301a stores the job execution information 302a in a format linked to the job identification information specified by the job execution request side. This allows the job scheduler of the job management machine that has newly transitioned to the active system to take over the execution management process for jobs that have not yet been executed, even if a failover occurs in the job management machine.

[0043] However, when a job is executed in a system provided by a cloud service (a cloud system), the device corresponding to the job execution machine 301 is managed by the cloud system provider. Therefore, the user, who is the job execution requester, generally cannot deploy a job execution agent 301a in the cloud system. For example, when a cloud system executes a new job, it generates job execution information in a format determined by the cloud service. Therefore, the job execution requester cannot associate the generated job execution information with the job identification information (job ID) specified by the job execution requester. As a result, when a failover occurs in the job management machine, there is a problem in that it is not possible to take over the execution management process for jobs that have not yet been executed.

[0044] Specifically, the job execution information generated by the cloud system includes identification information (execution ID) that the cloud system uses to identify the job. If the job execution agent 301a cannot be deployed, the job execution requesting side cannot associate the generated execution ID with the job ID specified by the job execution requesting side. Therefore, when a failover occurs, the job scheduler of the job management machine that has newly transitioned to the active system cannot recognize the execution ID of the job to be monitored, and cannot take over the execution management process for that job.

[0045] In this way, when a job is executed in a cloud system, the job execution agent 301a cannot be deployed, which raises the issue of how to manage the information required to take over the job execution management process so that the job management machine can obtain it after a failover.

[0046] In recent years, data-driven businesses have been gaining attention for their growth and competitiveness, using digital technology to gain data-based insights and make business decisions. To secure a competitive advantage in such data-driven businesses, it is necessary to build a rapid data utilization platform on cloud services. Against this backdrop, high availability is required when running business jobs on cloud services.

[0047] In addition, as more and more businesses operate by combining multiple cloud services, there is a growing need to manage the execution of jobs across these multiple cloud services. Furthermore, as business systems become more complex due to the integration of multiple cloud services, the time required to recover from abnormalities increases, so high availability is required to reduce operational burdens.

[0048] Fig. 3 is a diagram illustrating an example of the configuration of a job management system according to the second embodiment. The job management system illustrated in Fig. 3 is a system for executing jobs in one or more cloud services, and includes redundant job management machines 110 and 120, a relay system 200, and cloud systems 310, 320, and 330.

[0049] The job management machines 110 and 120 are examples of the job management devices 11 and 12 in Fig. 1. The relay system 200 is an example of the relay system 20 in Fig. 1. The cloud systems 310, 320, and 330 are examples of the job execution system 30 in Fig. 1.

[0050] The job management machines 110 and 120 are devices that manage the execution of jobs in the cloud systems 310, 320, and 330. One of the job management machines 110 and 120 operates as an active system, and the other operates as a standby system. When the operation of the active job management machine stops, a failover occurs, the standby job management machine becomes the active system, and the new active job management machine takes over the job execution management process. In the following explanation, it is assumed that in the initial state, the job management machine 110 is the active system and the job management machine 120 is the standby system.

[0051] The job management machines 110 and 120 are, for example, physical machines or virtual machines provided by a cloud service. In this case, the job management machine 110 is a physical machine or virtual machine realized in a data center group 101, and the job management machine 120 is a physical machine or virtual machine realized in a data center group 102 different from the data center group 101. The data center groups 101 and 102 are management units of data centers in the cloud service, such as availability zones in AWS (Amazon Web Service, registered trademark). Furthermore, the job management machines 110 and 120 belong to the same tenant. In other words, the job management machines 110 and 120 are under the contract of the same user in the cloud service.

[0052] Cloud systems 310, 320, and 330 are computer systems that respectively realize individual cloud services A, B, and C. Cloud systems 310, 320, and 330 have a job execution function and execute job-related processing in response to requests received via, for example, a REST API (Representational State Transfer Application Programming Interface). Note that while the job management system in FIG. 3 includes three cloud systems 310, 320, and 330 as an example, the job management system may include one or more cloud systems that have a job execution function.

[0053] The relay system 200 is a computer system including one or more physical machines, and relays communications between the job management machines 110 and 120 and the cloud systems 310, 320, and 330.

[0054] Here, the hardware configuration of the physical machines included in the relay system 200 will be described. Fig. 4 is a diagram showing the hardware configuration of a physical machine. A physical machine 50 is realized, for example, as a computer as shown in Fig. 4. The physical machine 50 shown in Fig. 4 includes a processor 51, a random access memory (RAM) 52, a hard disk drive (HDD) 53, a graphics processing unit (GPU) 54, an input interface (I / F) 55, a reader 56, and a network interface (I / F) 57.

[0055] The processor 51 (processor circuit) performs overall control of the entire physical machine 50. The processor 51 is, for example, a central processing unit (CPU), a micro processing unit (MPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), or a programmable logic device (PLD). The processor 51 may also be a combination of two or more elements of a CPU, an MPU, a DSP, an ASIC, or a PLD.

[0056] The RAM 52 is used as a main storage device of the physical machine 50. The RAM 52 temporarily stores at least a part of the OS (Operating System) program and application programs to be executed by the processor 51. The RAM 52 also stores various data necessary for processing by the processor 51.

[0057] The HDD 53 is used as an auxiliary storage device for the physical machine 50. The HDD 53 stores an OS program, application programs, and various data. Note that other types of non-volatile storage devices, such as an SSD (Solid State Drive), can also be used as the auxiliary storage device.

[0058] A display device 61 is connected to the GPU 54. The GPU 54 displays an image on the display device 61 in accordance with an instruction from the processor 51. The display device 61 may be a liquid crystal display or an organic EL (ElectroLuminescence) display.

[0059] An input device 62 is connected to the input interface 55. The input interface 55 transmits a signal output from the input device 62 to the processor 51. Examples of the input device 62 include a keyboard and a pointing device. Examples of the pointing device include a mouse, a touch panel, a tablet, a touch pad, and a trackball.

[0060] A portable recording medium 63 is detachably attached to the reading device 56. The reading device 56 reads data recorded on the portable recording medium 63 and transmits it to the processor 51. The portable recording medium 63 may be an optical disk, a semiconductor memory, or the like.

[0061] The network interface 57 transmits and receives data to and from other devices via the network 64 . The above hardware configuration can realize the processing functions of the physical machine 50 included in the relay system 200. Note that the physical machines included in the data center groups 101 and 102 and the cloud systems 310, 320, and 330 may also have the same hardware configuration as in FIG.

[0062] FIG. 5 is a diagram illustrating an example of the configuration of processing functions provided in the job management system. The job management machines 110 and 120 are respectively equipped with job schedulers 111 and 121. The processing of the job scheduler 111 is realized, for example, by a processor of the job management machine 110 executing a predetermined program. Similarly, the processing of the job scheduler 121 is realized, for example, by a processor of the job management machine 120 executing a predetermined program.

[0063] A storage unit 130 that can be commonly accessed by the job management machines 110 and 120 is connected to the job management machines 110 and 120. The storage unit 130 is a storage area secured in a non-volatile storage device. In practice, for example, a storage area of ​​the storage unit 130 may be secured in each of a storage device provided in the data center group 101 and a storage device provided in the data center group 102, and data may be mirrored between these storage areas.

[0064] The storage unit 130 stores job definition information and a job management table. The job definition information includes various parameters related to jobs to be executed by the cloud systems 310, 320, and 330. The job management table is generated for each job whose execution is requested, and includes a job ID, job status, and the like. The job schedulers 111 and 121 schedule jobs to be executed based on the job definition information, and transmit job execution requests and monitoring requests to the relay system 200.

[0065] The cloud systems 310, 320, and 330 include job execution units 311, 321, and 331, respectively. The processing of the job execution unit 311 is realized, for example, by a processor of a physical machine included in the cloud system 310 executing a predetermined program. Similarly, the processing of the job execution unit 321 is realized, for example, by a processor of a physical machine included in the cloud system 320 executing a predetermined program. Furthermore, the processing of the job execution unit 331 is realized, for example, by a processor of a physical machine included in the cloud system 330 executing a predetermined program. The job execution units 311, 321, and 331 execute jobs in response to requests from the relay system 200, and return information indicating the execution status and execution results.

[0066] Relay system 200 comprises relay processing unit 210, storage unit 220, and management unit 230. The processing of relay processing unit 210 and management unit 230 is realized, for example, by a processor of a physical machine included in relay system 200 executing a predetermined program. The processing of relay processing unit 210 and management unit 230 may also be executed by processors of different physical machines included in relay system 200. Storage unit 220 is a storage area secured in a non-volatile storage device included in relay system 200.

[0067] When relay processing unit 210 receives a job execution request from job scheduler 111 or 121, it transfers the execution request to the cloud system that is the job execution destination (one of cloud systems 310, 320, or 330) and starts execution of the job. At this time, relay processing unit 210 acquires job identification information (execution ID) assigned to the job from the cloud system that is the job execution destination. Then, relay processing unit 210 newly registers a record that associates the acquired execution ID with the job ID specified by job scheduler 111 or 121 in the relay job management table in storage unit 220.

[0068] When a job starts to be executed in a cloud system, relay processor 210 periodically acquires a job status indicating the execution state of the job from the cloud system where the job is executed, and writes the acquired job status into the relay job management table until the job is completed. When acquiring the job status, the execution ID of the job to be monitored is specified. Meanwhile, job schedulers 111 and 121 periodically request relay processor 210 to acquire the job status by specifying the job ID of the job. In response to this request, relay processor 210 returns the job status written into the relay job management table to job schedulers 111 and 121. This type of job monitoring process continues until the job status indicates that the job is completed.

[0069] Through the above processing by relay processor 210, the job ID specified by job scheduler 111, 121 and the execution ID assigned by the cloud system where the job is to be executed are managed in association with each other. This allows job schedulers 111, 121 to grasp the execution status of a job by specifying the job ID to relay processor 210. With this configuration, as will be described later, failover of job management machines 110, 120 can be easily and reliably performed.

[0070] Management unit 230 manages the operation of relay processing unit 210. For example, multiple relay processing units 210 may be started depending on the number of jobs requested to be executed by job schedulers 111 and 121. Relay processing unit 210 creates (starts) or deletes relay processing units 210 depending on the number of jobs.

[0071] Here, relay processing unit 210 is realized by a virtual execution environment constructed in relay system 200. This makes it easier to create and delete relay processing units 210 compared to when multiple relay processing units 210 are realized by individual physical machines or virtual machines.

[0072] For example, relay processing unit 210 is realized as a container. Container virtualization technology is a technology for building an execution environment for independent applications on a virtualized OS. Containers are virtual user spaces isolated from each other in the execution environment of the OS. These user spaces are provided as groups of resources isolated from each other for application execution. For example, individual memory spaces are allocated to containers. Furthermore, when relay processing unit 210 is a container, the processing of management unit 230 is realized by management software that manages the container. Creating (starting) a container is equivalent to starting a process on an OS, and is therefore faster than starting a hypervisor-type virtual machine.

[0073] Furthermore, relay processing unit 210 may be realized by executing a program called a serverless function. Execution of the serverless function provides a serverless environment in which a program can be executed without constructing a physical server.

[0074] Next, a job management table stored in the storage unit 130 on the job execution request side will be described below. Fig. 6 is a diagram showing an example of the data configuration of the job management table. A record for each job requested for execution by the job schedulers 111 and 121 is registered in the job management table 131. Each record includes a job ID, a job status, connection information, and response information.

[0075] The job ID is identification information assigned by the job execution requester to the job whose execution has been requested. The job status is information indicating the execution state of the job. For example, the job status may be one of the following: "Waiting for execution" indicating that the job is waiting to start execution, "Running" indicating that the job is currently being executed, "Completed normally" indicating that the job has completed successfully, "Completed abnormally" indicating that the job has completed abnormally, or "Completed forcibly" indicating that the job has been forcibly terminated.

[0076] The connection information is information for connecting to a cloud system for job execution, and includes, for example, job execution request information, job monitoring request information, and job abort request information.

[0077] The execution request information is information about an execution request that requests the start of job execution, and includes, for example, a connection destination URL (Uniform Resource Locator) of the cloud system, a method name of HTTP (Hyper Text Transfer Protocol), authentication information, and an HTTP request header.

[0078] The monitoring request information is information related to a monitoring request for obtaining a job status. The monitoring request information includes the cloud system connection URL, the HTTP method name, the HTTP request header, the number of polls and the polling interval when polling the monitoring request, the monitoring end condition, and the condition for determining whether the job is successful. The monitoring request information is registered in the record only if the job for which execution has been requested is a job that requires polling of the monitoring request after the execution request is sent. The monitoring request information is also sent to the relay processing unit 210 together with the execution request.

[0079] The forced termination request information is information about a forced termination request that requests the forced termination of a job, and includes, for example, a connection URL of the cloud system and an HTTP method name.

[0080] The response information is information included in the response returned from the cloud system in response to a request, and is acquired from relay processing unit 210. The response information includes an execution ID assigned by the cloud system and a job status returned from the cloud system that indicates the execution status of the job.

[0081] Next, a description will be given of the relay job management table stored in the storage unit 220 of the relay system 200. Fig. 7 is a diagram showing an example of the data configuration of the relay job management table. The relay job management table 221 registers a record for each job requested to be executed by the job schedulers 111 and 121. Each record includes a job ID, a tenant ID, an execution ID, a job status, monitoring request information, and response information.

[0082] The job ID is identification information assigned to a job by the job execution requester. The tenant ID is identification information of the tenant that requested the job execution. Since the job ID is identification information assigned by the tenant, when jobs are requested by multiple tenants, each job is identified by the combination of the job ID and the tenant ID.

[0083] The execution ID is identification information assigned by the cloud system to a job that has been executed in response to an execution request. In this way, the relay job management table 221 manages the execution ID used by the cloud system to identify a job, in association with the job ID and tenant ID used by the tenant to identify the job.

[0084] The job status is information that indicates the execution status of a job. This job status is information that is referenced by the job execution request side. For example, one of the aforementioned "waiting for execution," "running," "completed normally," "completed abnormally," or "forced termination" is registered as the job status.

[0085] The monitoring request information is information related to a monitoring request, and is sent from the job schedulers 111 and 121 together with an execution request for starting the execution of a job, and is registered in a record of the relay job management table 221.

[0086] The response information is information included in the response sent from the cloud system in response to a request. The response information includes an execution ID and a job status. For example, the job status may be "Running" to indicate that the job is running, "Completed Successfully" to indicate that the job has completed successfully, or "Completed Abnormally" to indicate that the job has completed abnormally.

[0087] Next, the operation of the job management system when a job is executed or when a failover occurs during job execution will be described with reference to Figures 8 to 10. In Figures 8 and 9, it is assumed that the job management machine 110 is the operational system and the job management machine 120 is the standby system. In the following description, it is assumed that the cloud system 310 is made to execute the job, as an example.

[0088] 8 shows an example of operation when a job starts to be executed. Job scheduler 111 of job management machine 110 sends an execution request to relay processor 210 to cause cloud system 310 to start executing the job (step S11). At this time, job scheduler 111 sets the job ID and tenant ID assigned to the job to be executed in the execution request. Job scheduler 111 also adds a record to job management table 131 and writes the job ID to that record.

[0089] Relay processing unit 210 transfers the execution request to cloud system 310, requesting that the job be started (step S12). Job execution unit 311 of cloud system 310 starts the job execution, assigns an execution ID to the job, and returns a response including this execution ID and a job status indicating "in progress" to relay processing unit 210 (step S13).

[0090] The relay processing unit 210 adds a record to the relay job management table 221 and writes the job ID, tenant ID, execution ID, and response information to the record (step S14). The response information includes the job status in the response returned in step S13. In practice, the addition of the record to the relay job management table 221 and the writing of the job ID and tenant ID may be performed at the time the execution request is received.

[0091] After this, the job is monitored as shown in Fig. 9. Fig. 9 is a diagram showing an example of the operation during job execution. After transmitting the job execution request, relay processor 210 polls cloud system 310, the job execution destination, for a monitoring request to acquire the job status. An execution ID is set in this monitoring request, thereby specifying the job to be monitored.

[0092] 9, relay processing unit 210 sends a monitoring request specifying an execution ID to cloud system 310 (step S21a). If job execution unit 311 of cloud system 310 is currently executing a job, it returns a response to relay processing unit 210 that includes a job status indicating "currently executing" (step S22a). Relay processing unit 210 updates the job status of the corresponding record in relay job management table 221 based on the job status included in the response (step S23a).

[0093] If the job status is "in progress", relay processing unit 210 sends a monitoring request specifying the execution ID to cloud system 310 after a certain time has passed (step S21b). If the job is being executed, job execution unit 311 of cloud system 310 returns a response including a job status indicating "in progress" to relay processing unit 210 (step S22b). Relay processing unit 210 updates the job status of the corresponding record in relay job management table 221 based on the job status included in the response (step S23b).

[0094] In this way, relay processing unit 210 continues to poll cloud system 310 for monitoring requests until the job status becomes "completed normally" or "completed abnormally."

[0095] On the other hand, after sending a job execution request, job scheduler 111 also polls relay processor 210 with a monitoring request to acquire the job status. This monitoring request specifies the job to be monitored by setting a job ID and a tenant ID.

[0096] 9, job scheduler 111 transmits a monitoring request in which a job ID and a tenant ID are set to relay processor 210 (step S31a). Relay processor 210 identifies a record including the set job ID and tenant ID from relay job management table 221, and returns the job status registered in the identified record to job scheduler 111 (step S32a).

[0097] If the job status is "in progress," relay processing unit 210 sends a monitor request in which the job ID and tenant ID are set to relay processing unit 210 after a certain period of time (step S31b). Relay processing unit 210 identifies a record including the set job ID and tenant ID from relay job management table 221, and returns the job status registered in the identified record to job scheduler 111 (step S32b).

[0098] In this way, job scheduler 111 continues to poll relay processing unit 210 for monitoring requests until the job status becomes "completed normally" or "completed abnormally." When the job status becomes "completed normally" or "completed abnormally," job scheduler 111 ends its monitoring process for this job.

[0099] Next, a description will be given of a failover process when the job management machine 110 abnormally stops during job monitoring processing by the job scheduler 111. Fig. 10 is a diagram showing an example of the failover operation.

[0100] Relay processing unit 210 continues the job monitoring process shown in Fig. 9. In the example of Fig. 10, relay processing unit 210 sends a monitoring request specifying an execution ID to cloud system 310 (step S21c). Job execution unit 311 of cloud system 310 returns a response including the job status to relay processing unit 210 (step S22c). Relay processing unit 210 updates the job status of the corresponding record in relay job management table 221 based on the job status included in the response (step S23c).

[0101] On the other hand, when job management machine 120 detects that job management machine 110 has abnormally stopped, it transitions from a standby system to an active system (step S41). Job scheduler 121 of job management machine 120 obtains the job ID of the job being executed from job management table 131, and sends a monitoring request in which this job ID and tenant ID are set to relay processor 210 (step S42). Relay processor 210 identifies a record including the set job ID and tenant ID from relay job management table 221, and returns the job status registered in the identified record to job scheduler 121 (step S43).

[0102] This allows job scheduler 121 to recognize the execution status of the job and execute processing according to that status. For example, if the job status is "executing," job scheduler 121 continues polling the relay processing unit 210 for monitoring requests until the job status changes to "completed normally" or "completed abnormally." In other words, job scheduler 121 can take over monitoring processing of the job being executed from job scheduler 111.

[0103] As described above, in this embodiment, the storage unit 220 of the relay system 200 associates an execution ID used by the cloud system to identify a job with a job ID and a tenant ID used by the tenant to identify a job, and stores the associated IDs. This allows the information required for the failed-over job management machine to take over the job monitoring process to be stored in the storage unit 220 of the relay system 200. Therefore, the job scheduler of the failed-over job management machine can obtain the job status using the job ID assigned by the job execution requesting side, without using the execution ID assigned by the cloud system that is the job execution destination. As a result, the job scheduler of the failed-over job management machine can easily and reliably take over the monitoring process of the job that is currently being executed.

[0104] Next, the processing of job schedulers 111 and 121 and relay processing unit 210 will be described using flowcharts. Fig. 11 is a flowchart showing an example of job execution management processing by a job scheduler. The processing in Fig. 11 is executed when the job scheduler 111 of the operational job management machine 110 causes the cloud system 310 to start executing a new job. Here, it is assumed that the job is executed by the cloud system 310.

[0105] [Step S51] The job scheduler 111 adds a record to the job management table 131, assigns a job ID to the job to be executed, and writes the job ID in the added record. The job scheduler 111 also obtains connection information for job execution management from the job definition information and writes it in the connection information field of the added record. The job scheduler 111 also writes "Waiting for execution" in the job status field of the added record. The job scheduler 111 then reads the connection information.

[0106] [Step S52] Using the authentication information included in the read connection information, the job scheduler 111 executes authentication processing with the cloud system 310. If the authentication processing is successful, the process proceeds to step S53.

[0107] [Step S53] The job scheduler 111 sends an execution request to the relay processor 210 to cause the cloud system 310 to start executing the job. The execution request sent includes the job ID, tenant ID, and connection information.

[0108] [Step S54] Job scheduler 111 determines whether an abnormality has occurred in the response from relay processing unit 210 to the execution request. For example, if no response is sent from relay processing unit 210 or a response indicating an abnormality is sent, it is determined that an abnormality has occurred, and processing proceeds to step S55. On the other hand, if a normal response is sent from relay processing unit 210, processing proceeds to step S56.

[0109] [Step S55] The job scheduler 111 executes a process to be performed when an abnormality occurs in the relay processing unit 210. In this process, the execution request is retransmitted. Details of the process in step S55 will be described with reference to FIG.

[0110] [Step S56] The job scheduler 111 updates the job status of the record added to the job management table 131 in step S51 to "in progress." [Step S57] The job scheduler 111 determines whether the connection information includes monitoring request information. If monitoring request information is included, the process proceeds to step S58. If not, the process proceeds to step S59.

[0111] [Step S58] The job scheduler 111 executes job monitoring processing by polling the monitoring request to acquire the job status. Details of the processing in step S58 will be described with reference to FIG.

[0112] [Step S59] The job scheduler 111 transmits a response acquisition request for acquiring response information to the relay processor 210. The transmitted response acquisition request contains the same job ID and tenant ID as in step S53.

[0113] Upon receiving the response acquisition request, the relay processing unit 210 identifies a record in which the job ID and tenant ID are registered from the relay job management table 221, extracts response information from the identified record, and returns the response information to the job scheduler 111.

[0114] [Step S60] The job scheduler 111 writes the response information returned from the relay processor 210 in the response information field of the record added to the job management table 131 in step S51.

[0115] [Step S61] Based on the job status included in the response information, the job scheduler 111 updates the job status of the record added to the job management table 131 in step S51 to "completed normally" or "completed abnormally."

[0116] 12 is a flowchart showing an example of a job monitoring process by the job scheduler, which corresponds to the process in step S58 in FIG. <Step S71> The job scheduler 111 sends a monitoring request for acquiring the job status to the relay processor 210. The sent monitoring request includes the job ID and tenant ID.

[0117] [Step S72] Job scheduler 111 determines whether an abnormality has occurred in the response from relay processing unit 210 to the monitoring request. For example, if no response is sent from relay processing unit 210 or if a response indicating an abnormality is sent, it is determined that an abnormality has occurred, and processing proceeds to step S73. On the other hand, if a normal response is sent from relay processing unit 210, processing proceeds to step S74.

[0118] [Step S73] The job scheduler 111 executes a process to deal with the abnormality in the relay process unit 210. In this process, the monitoring request is retransmitted. Details of the process in step S73 will be described with reference to FIG. 21.

[0119] [Step S74] The job scheduler 111 determines whether the job status included in the response to the monitoring request is "in progress." If the job status is "in progress," the process proceeds to step S75. On the other hand, if the job status is "completed normally" or "completed abnormally," the job monitoring process ends, and the process proceeds to step S59 in FIG. 11.

[0120] [Step S75] The job scheduler 111 extracts the polling interval from the monitoring request information included in the connection information, and goes into sleep mode for the time indicated by the polling interval. After this time has elapsed, the sleep mode is canceled, and the process returns to step S71.

[0121] FIG. 13 is a flowchart showing an example of job execution management processing by the relay processing unit. [Step S81] The relay processor 210 receives an execution request for executing a job from the job scheduler 111. In this example, it is assumed that the relay processor 210 has received an execution request for causing the cloud system 310 to execute a job. This received request was sent from the job scheduler 111 in step S53 of FIG. 11. The relay processor 210 extracts the job ID, tenant ID, and connection information from the received execution request.

[0122] [Step S82] The relay processor 210 adds a record to the relay job management table 221, and writes the job ID and tenant ID extracted in step S81 into the added record. Furthermore, if the connection information extracted in step S81 includes monitoring request information, the relay processor 210 writes this monitoring request information into the added record. Furthermore, the relay processor 210 writes "Waiting for execution" in the job status field of the added record.

[0123] <Step S83> The relay processor 210 transfers the received execution request to the cloud system 310 that is the job execution destination. <Step S84> The relay processor 210 receives a response to the execution request from the cloud system 310, and writes the information contained in the response into the response information field of the added record.

[0124] [Step S85] The relay processor 210 extracts the execution ID from the response information and writes it in the execution ID field of the added record. The relay processor 210 also updates the job status of the added record to “In Progress.”

[0125] [Step S86] The relay processor 210 determines whether monitoring request information is registered in the added record (whether it was written in step S82). If monitoring request information is registered, the process proceeds to step S87; if not, the job execution management process ends.

[0126] [Step S87] The relay processor 210 performs job monitoring processing by polling for monitoring requests to obtain job status. Details of the processing in step S87 will be described with reference to FIG.

[0127] 14 is a flowchart showing an example of job monitoring processing by the relay processing unit, which corresponds to the processing in step S87 in FIG. [Step S91] The relay processing unit 210 reads the monitoring request information from the record added to the relay job management table 221 in step S82 of FIG.

[0128] [Step S92] Based on the monitoring request information, the relay processor 210 sends a monitoring request to acquire the job status to the cloud system 310. The execution ID registered in the added record is set in the sent monitoring request.

[0129] [Step S93] The relay processor 210 receives a response to the monitoring request from the cloud system 310, and writes the information contained in the response into the response information field of the added record.

[0130] <Step S94> The relay process unit 210 extracts the job status from the response information, and updates the job status of the added record based on the extracted job status.

[0131] [Step S95] Relay processor 210 determines whether the updated job status satisfies the monitoring termination condition included in the monitoring request information. If the job status is "Completed normally" or "Completed abnormally," it is determined that the monitoring termination condition is met, and job monitoring processing ends. On the other hand, if the job status is "In progress," it is determined that the monitoring termination condition is not met, and processing proceeds to step S96.

[0132] [Step S96] Relay processing unit 210 extracts the polling count from the monitoring request information and determines whether the number of executions of step S92 (the number of times monitoring requests have been sent) has reached the polling count. If the number of transmissions is less than the polling count, the process proceeds to step S97. If the number of transmissions has reached the polling count, the process proceeds to step S98.

[0133] [Step S97] The relay processor 210 extracts the polling interval from the monitoring request information and goes into sleep mode for the time indicated by the polling interval. Once this time has elapsed, the sleep mode is cancelled and the process proceeds to step S92.

[0134] [Step S98] In this case, the job execution has not been completed even after the specified number of monitoring requests have been sent. In this case, the relay processor 210 stops sending monitoring requests and updates the job status of the added record to "abnormal completion."

[0135] Next, the forced termination process of a job will be described with reference to Figures 15 and 16. The job scheduler 111 can request the forced termination of a job at any timing between the time when the job execution is requested and the time when the completion of the execution is recognized.

[0136] FIG. 15 is a flowchart showing an example of a forced termination process by a job scheduler. [Step S101] The job scheduler 111 transmits a forced termination request to the relay processor 210, requesting forced termination of a job in the cloud system 310. The transmitted forced termination request includes a job ID and a tenant ID that identify the job.

[0137] [Step S102] Job scheduler 111 determines whether an abnormality has occurred in the response from relay processing unit 210 to the abort request. For example, if no response is sent from relay processing unit 210 or if a response indicating an abnormality is sent, it is determined that an abnormality has occurred, and processing proceeds to step S103. On the other hand, if a normal response is sent from relay processing unit 210, processing proceeds to step S104.

[0138] [Step S103] Job scheduler 111 executes a process to deal with the abnormality of relay process unit 210. In this process, the forced termination request is resent. Details of the process of step S103 will be described with reference to FIG.

[0139] [Step S104] The job scheduler 111 transmits a response acquisition request for acquiring response information to the relay processor 210. The transmitted response acquisition request contains the same job ID and tenant ID as in step S101.

[0140] <Step S105> The job scheduler 111 writes the response information returned from the relay processor 210 into the response information field of the corresponding record in the job management table 131.

[0141] [Step S106] The job scheduler 111 updates the job status of the corresponding record in the job management table 131 to "forced termination." FIG. 16 is a flowchart showing an example of a forced termination process performed by the relay processing unit.

[0142] [Step S111] Upon receiving the forced termination request sent from the job scheduler 111 in step S101 of FIG. 15, the relay processor 210 extracts the job ID and tenant ID from the forced termination request.

[0143] [Step S112] The relay processor 210 identifies a record in which the extracted job ID and tenant ID are registered from the relay job management table 221. The relay processor 210 extracts the execution ID from the identified record, and sends a forced termination request to the cloud system 310, with the extracted execution ID set.

[0144] <Step S113> The relay processor 210 receives a response to the forced termination request from the cloud system 310, and writes the information contained in the response into the response information field of the identified record.

[0145] <Step S114> The relay processing unit 210 updates the job status of the identified record to "forced termination." Although not shown, thereafter, relay processor 210 receives the response acquisition request sent from job scheduler 111 in step S104 of Figure 15. Relay processor 210 extracts the job ID and tenant ID from the response acquisition request, and identifies a record in which the extracted job ID and tenant ID are registered from relay job management table 221. Relay processor 210 extracts response information from the identified record and returns it to job scheduler 111.

[0146] Next, with reference to FIG. 17, a process will be described in which the job management machine 110 stops and the job management machine 120 transitions from the standby system to the active system (failover occurs). FIG. 17 is a flowchart showing an example of processing by a job scheduler after a failover.

[0147] [Step S121] The job scheduler 121 of the job management machine 120 that has transitioned from the standby system to the active system after failover searches for jobs with a job status of "RUNNING" in the job management table 131. If a matching job is found, the process proceeds to step S123; if not, the process proceeds to step S122.

[0148] [Step S122] The job scheduler 121 executes job execution management processing (corresponding to the processing in FIG. 11) for the next job to be executed. The processing from step S123 onwards is carried out for each job whose job status is "in progress".

[0149] [Step S123] The job scheduler 121 extracts the job ID from the record of the job in question in the job management table 131, and sends a monitoring request to the relay processor 210 in which the extracted job ID and tenant ID are set.

[0150] [Step S124] The job scheduler 121 receives a response to the monitoring request and extracts the job status from the response. If the job status is "completed normally" or "completed abnormally," the process proceeds to step S128. If the job status is neither "completed normally" nor "completed abnormally," the process proceeds to step S125.

[0151] [Step S125] If the job status is "in progress", the process proceeds to step S126; if the job status is not "in progress", the process proceeds to step S127.

[0152] [Step S126] The job scheduler 121 executes the job monitoring process for the job in question, as shown in Fig. 12. In this case, the failed-over job scheduler 121 can take over the job monitoring process for the running job from the job scheduler 111, using only the job ID and tenant ID specified by the job execution requester, without using the execution ID specified by the cloud system.

[0153] [Step S127] In this case, a failover occurs immediately after the execution of the forced termination process (FIG. 15) for the job begins, and the forced termination request does not reach relay process unit 210. In this case, job scheduler 121 executes the forced termination process shown in FIG. 15 for the job.

[0154] [Step S128] The job scheduler 121 transmits a response acquisition request for acquiring response information to the relay processor 210. The transmitted response acquisition request contains the same job ID and tenant ID as in step S123.

[0155] Upon receiving the response acquisition request, the relay processing unit 210 identifies a record in which the job ID and tenant ID are registered from the relay job management table 221, extracts response information from the identified record, and returns the response information to the job scheduler 111.

[0156] <Step S129> The job scheduler 121 writes the response information returned from the relay processor 210 into the response information field of the record for the job in question in the job management table 131.

[0157] <Step S130> Based on the job status included in the response information, the job scheduler 121 updates the job status of the record to "completed normally" or "completed abnormally."

[0158] FIG. 18 is a flowchart illustrating an example of a monitoring request response process performed by the relay processing unit. [Step S141] Relay processor 210 receives a monitoring request from job scheduler 111 or job scheduler 121. The monitoring request is, for example, the request sent in step S71 in FIG. 12 or step S123 in FIG.

[0159] [Step S142] The relay processing unit 210 extracts the job ID and tenant ID from the received monitoring request. The relay processing unit 210 identifies a record in the relay job management table 221 that includes the extracted job ID and tenant ID, and extracts the job status from the identified record.

[0160] <Step S143> The relay processor 210 returns the extracted job status to the job scheduler that sent the monitoring request. In the job management system according to this embodiment, the availability of the job management machines 110 and 120 is increased, but availability is also required for the relay processing unit 210. It is conceivable to provide redundancy for the relay processing unit 210 using a separate physical machine, but this would increase the time required for failover and the cost of the redundancy device. In contrast, in this embodiment, as described above, the relay processing unit 210 is realized by a virtual execution environment using containers and serverless functions. This makes it possible to reduce device costs and quickly start up the relay processing unit 210 that takes over processing.

[0161] Figure 19 shows the processing that occurs when an abnormality occurs in the relay processing unit. In the example of Figure 19, it is assumed that an abnormality occurs in relay processing unit 210 and its operation stops. In this case, management unit 230 deletes relay processing unit 210 and starts up new relay processing unit 210a. Relay processing unit 210a takes over the processing of relay processing unit 210 while referencing relay job management table 221 that was referenced by the original relay processing unit 210. As a result, processing of jobs for which the original relay processing unit 210 had accepted requests is continued by the new relay processing unit 210a.

[0162] FIG. 20 is a flowchart showing an example of processing by the management unit when an abnormality occurs in the relay processing unit. [Step S151] The management unit 230 detects that the relay processing unit 210 has stopped abnormally. [Step S152] Manager 230 deletes the stopped relay processor 210 and starts a new relay processor 210a. The started relay processor 210a takes over processing of jobs for which the stopped relay processor 210 had been accepting requests. Any requests subsequently sent from job management machines 110 and 120 are received by the started relay processor 210a.

[0163] Fig. 21 is a flowchart showing an example of processing by the job scheduler when an abnormality occurs in the relay processing unit. The processing in Fig. 21 corresponds to the processing in step S55 in Fig. 11, step S73 in Fig. 12, and step S103 in Fig. 15, and is executed by either job scheduler 111 or 112.

[0164] [Step S161] The job scheduler goes into a sleep state for a predetermined time. After the predetermined time has elapsed, the sleep state is canceled and the process proceeds to step S162. [Step S162] The job scheduler resends the request to relay processor 210. In step S55, the job execution request sent in step S53 is resent. In step S73, the monitoring request sent in step S71 is resent. In step S103, the abort request sent in step S101 is resent.

[0165] [Step S163] The job scheduler determines whether an abnormality has occurred in the response from relay processing unit 210 to the transmitted request. For example, if no response is transmitted from relay processing unit 210, or if a response indicating an abnormality is transmitted, it is determined that an abnormality has occurred, and processing proceeds to step S164. On the other hand, if a normal response is transmitted from relay processing unit 210, processing proceeds to step S165.

[0166] [Step S164] The job scheduler determines whether the number of retransmissions of the request (the number of times step S162 has been executed) has reached a predetermined upper limit. If the number of retransmissions is less than the upper limit, the process proceeds to step S161. On the other hand, if the number of retransmissions has reached the upper limit, a timeout occurs and the process ends.

[0167] [Step S165] If an abnormality occurs during the job execution management process (in the case of step S55), the process proceeds to step S56 in Fig. 11. On the other hand, if an abnormality does not occur during the job execution management process, the process proceeds to step S166.

[0168] [Step S166] If an abnormality occurs during the monitoring process (in the case of step S73), the process proceeds to step S74 in Fig. 12. On the other hand, if an abnormality occurs during the forced termination process (in the case of step S103), the process proceeds to step S104 in Fig. 15.

[0169] Here, for example, if relay processing unit 210 abnormally stops in step S151 of Figure 20, an abnormality occurs in the response to a request from the job scheduler, and the job scheduler starts the processing of Figure 21. In Figure 21, the request is resent to relay processing unit 210 at predetermined time intervals. Then, if new relay processing unit 210a starts up (corresponding to step S152 of Figure 20) and sends back a normal response before the number of retries reaches the upper limit, the job scheduler continues processing with the new relay processing unit 210a as the request destination. This processing allows the job scheduler to continue job execution management processing without recognizing the abnormal shutdown or failover of the relay processing unit to which the request is sent.

[0170] Next, the activation and deletion of relay processing unit 210 will be further explained. One possible method for activating relay processing unit 210 is to generate and activate a separate relay processing unit 210 for each job requested by job management machine 110, 120 to start execution of that job. However, starting and stopping relay processing unit 210 requires a certain amount of time and resources. If a relay processing unit 210 is generated for each job, a large number of relay processing units 210 will be activated, which will require startup time and consume resources each time. This will increase the processing load on relay system 200 and may slow down the processing speed of the entire job management system.

[0171] Therefore, in this embodiment, an upper limit is set for the number of jobs that one relay processing unit 210 can process, and if a job that exceeds the upper limit occurs, a new relay processing unit 210 is started and the new relay processing unit 210 is assigned to process the job.

[0172] Figure 22 is a first diagram showing an example of starting and deleting a relay processor. In Figure 22 and the following Figure 23, as an example, the upper limit of the number of jobs that one relay processor will handle is set to six. Also, the "requests" shown in Figures 22 and 23 correspond to one job, and include an execution request, a monitoring request, a forced termination request, and a response acquisition request.

[0173] 22, relay processing unit 210 is processing five job requests from job management machine 110. From this state C1, suppose that execution of a new job is requested, increasing the number of job requests. In state C2, the total number of jobs becomes eight. When the number of jobs reaches seven, management unit 230 starts a new relay processing unit 210b and has the new relay processing unit 210b process job requests from the seventh job onwards.

[0174] Suppose that some jobs are subsequently completed and job requests decrease. In state C3, the number of jobs handled by relay processing unit 210 has decreased to four, and the number of jobs handled by relay processing unit 210b has decreased to one. In other words, the total number of jobs currently being executed has decreased to five. If the total number of jobs currently being executed remains at or below the upper limit of six for a certain period of time, management unit 230 deletes one of the relay processing units and assigns the other relay processing unit to process the currently executing jobs. In the example of FIG. 22, after a certain period of time has elapsed, as in state C4, relay processing unit 210b is deleted and the currently executing jobs are processed by relay processing unit 210.

[0175] Such auto-scaling control by the management unit 230 reduces the number of relay processing units 210 activated, reducing the processing time and resource consumption overhead for activation and deletion. As a result, the processing load on the relay system 200 can be reduced, and a decrease in the processing speed of the entire job management system can be prevented. Furthermore, by setting an upper limit on the number of jobs that one relay processing unit 210 can process, the processing load can be distributed among the relay processing units 210, reducing the processing load on each relay processing unit 210.

[0176] Figure 23 is a second diagram showing an example of starting and deleting a relay processor. In state C11 of Figure 23, no job request has occurred. In this state, management unit 230 does not start relay processor 210. When a job request occurs thereafter, as in state C12, management unit 230 starts relay processor 210, and has the started relay processor 210 receive the job request and process the job.

[0177] Thereafter, as in state C13, it is assumed that the execution of the job has finished and the number of jobs being executed has become 0. If the state in which the number of jobs being executed remains 0 for a certain period of time, management unit 230 deletes relay processing unit 210, as in state C14.

[0178] In this way, by starting the relay processor 210 only when a job request occurs, it is possible to eliminate wasted resources and improve the utilization efficiency of the relay system 200. For example, if the relay processor 210 is started for each tenant as will be explained in the following FIG. 24, it is possible to start the relay processor 210 only for the tenant for which a job request has occurred. This improves the utilization efficiency of the resources of the relay system 200.

[0179] Next, the relationship between tenants and relay processing units 210 will be described. Relay system 200 is capable of providing tenant-occupied relay processing units 210 and tenant-shared relay processing units 210. Customers can select whether to use the tenant-occupied or tenant-shared relay processing unit 210.

[0180] Fig. 24 is a diagram showing a tenant-exclusive relay processing unit. In the example of Fig. 24, there are an operational job management machine 110a and a standby job management machine 120a belonging to tenant T1, and an operational job management machine 110b and a standby job management machine 120b belonging to tenant T2. Job management machine 110a includes job scheduler 111a, and job management machine 120a includes job scheduler 121a. Job management machine 110b includes job scheduler 111b, and job management machine 120b includes job scheduler 121b.

[0181] 24, relay processing unit 210c occupied by tenant T1 and relay processing unit 210d occupied by tenant T2 are active. Relay processing unit 210c executes processing in response to a job request from job scheduler 111a (or job scheduler 121a). As the number of jobs increases, relay processing units 210c1, 210c2, ... occupied by tenant T1 may be activated. Meanwhile, relay processing unit 210d executes processing in response to a job request from job scheduler 111b (or job scheduler 121b). As the number of jobs increases, relay processing units 210d1, 210d2, ... occupied by tenant T2 may be activated.

[0182] In such a tenant-occupied relay processing unit, job processing can be executed without being affected by processing loads from other tenants or by system maintenance or updates in other tenants.

[0183] FIG. 25 is a diagram illustrating a tenant-shared relay processor. In the example of FIG. 25, job management machines 110a, 120a, 110b, and 120b similar to those in FIG. 24 exist. However, unlike FIG. 24, in FIG. 25, relay processor 210e shared by tenants T1 and T2 is activated. Relay processor 210e executes processing in response to job requests from job scheduler 111a (or job scheduler 121a) and job requests from job scheduler 111b (or job scheduler 121b). Furthermore, as the number of jobs increases, relay processors 210e1, 210e2, and so on shared by tenants T1 and T2 may be activated.

[0184] Such a tenant-shared relay processing unit makes it possible to reduce the costs of introducing and operating a system for each tenant. The processing functions of the devices shown in the above embodiments (e.g., job management devices 11 and 12, relay system 20, job execution system 30, job management machines 110 and 120, relay system 200, and cloud systems 310, 320, and 330) can be realized by a computer. In this case, a program describing the processing content of the functions that each device should have is provided, and the processing functions are realized on the computer by executing the program. The program describing the processing content can be recorded on a computer-readable recording medium. Examples of computer-readable recording media include magnetic storage devices, optical discs, and semiconductor memories. Examples of magnetic storage devices include hard disk drives (HDDs) and magnetic tapes. Examples of optical discs include CDs (Compact Discs), DVDs (Digital Versatile Discs), and Blu-ray Discs (BD, registered trademark).

[0185] When distributing a program, for example, the program is recorded on a portable recording medium such as a DVD or CD and sold. Alternatively, the program can be stored in a storage device of a server computer and transferred from the server computer to other computers via a network.

[0186] A computer that executes a program stores, for example, a program recorded on a portable recording medium or a program transferred from a server computer in its own storage device. The computer then reads the program from its own storage device and executes processing in accordance with the program. Note that the computer can also read the program directly from a portable recording medium and execute processing in accordance with that program. The computer can also execute processing in accordance with the program received each time a program is transferred from a server computer connected via a network. [Explanation of symbols]

[0187] 11,12 Job management device 20 Relay System 21 Memory section 30 Job Execution System IDa, IDb Identification information Steps S1a to S1e, S2a, S2b, S3a to S3c, S4a, and S4b

Claims

1. a first job management device that executes an execution request process of transmitting a first request specifying first identification information for identifying a job and requesting that execution of the job be started; and a monitoring process of repeatedly transmitting, after the first request, a second request specifying the first identification information and requesting status information indicating an execution status of the job, until the status information transmitted in response to the second request indicates that execution of the job has been completed; a second job management device that takes over execution of the monitoring process from the first job management device using the first identification information; a relay system that executes a relay process to, upon receiving the first request from the first job management device, transfer the first request to a job execution system that executes the job, receive second identification information for identifying the job from the job execution system, associate the first identification information with the second identification information and store the same in a storage unit, transmit a third request to the job execution system that specifies the second identification information and requests the status information, associates the status information transmitted from the job execution system with the first identification information and stores the same in the storage unit, and, upon receiving the second request from the first job management device or a fourth request from the second job management device that specifies the first identification information, retrieves the status information associated with the first identification information from the storage unit and transmits the status information to a sender of the second request or the fourth request; the job execution system, upon receiving the second request from the relay system, starts execution of the job, assigns the second identification information to the job and transmits the second identification information to the relay system, and, upon receiving the third request from the relay system, transmits the status information of the job to the relay system; A job management system having:

2. the second job management device transmits the second request to the relay system when the operation of the first job management device stops, and if the status information transmitted from the relay system indicates that the job is being executed, repeatedly transmits the second request until the status information transmitted from the relay system indicates that the job has been executed. The job management system according to claim 1 .

3. the relay processing is executed by a virtual first execution environment constructed in the relay system, When an abnormality occurs in the first execution environment, the relay system deletes the first execution environment, constructs a new virtual second execution environment, and causes the second execution environment to take over the relay process. The job management system according to claim 1 .

4. the first and second execution environments are containers or serverless functions; The job management system according to claim 3 .

5. the relay system causes the first execution environment to execute the relay processing for a predetermined number or less of the jobs; When a request is made to start execution of the jobs exceeding the predetermined number, a virtual third execution environment is newly constructed, and the relay processing for the jobs exceeding the predetermined number is executed in the third execution environment. The job management system according to claim 3 .

6. when the total number of jobs for which the relay processing is being executed by the first execution environment and the third execution environment becomes equal to or less than the predetermined number, the relay system causes the first execution environment to execute the relay processing for the jobs, and deletes the third execution environment. The job management system according to claim 5 .

7. and when there are a plurality of combinations of the first and second job management devices, the relay system executes the relay process in response to requests from the plurality of combinations using the common first execution environment. The job management system according to claim 3 .

8. and when there are a plurality of combinations of the first and second job management devices, the relay system executes the relay process in response to requests from each of the plurality of combinations using the individual first execution environment. The job management system according to claim 3 .

9. On the computer, when receiving, from a first job management device, a first request for starting execution of a job, in which first identification information for identifying the job is specified, transferring the first request to a job execution system that executes the job, receiving second identification information for identifying the job from the job execution system, and storing the first identification information and the second identification information in a storage unit in association with each other; transmitting a third request to the job execution system, specifying the second identification information and requesting status information indicating an execution status of the job, and storing the status information transmitted from the job execution system in the storage unit in association with the first identification information; when a second request specifying the first identification information and requesting the status information is received from the first job management device, the status information associated with the first identification information is acquired from the storage unit and transmitted to the first job management device; when receiving a fourth request specifying the first identification information from a second job management device that has taken over the monitoring process of monitoring the execution status of the job from the first job management device, acquiring the status information associated with the first identification information from the storage unit and transmitting the status information to the second job management device; An information processing program that executes relay processing.

10. the relay process is executed by a virtual first execution environment constructed on the computer, The computer, When an abnormality occurs in the first execution environment, the first execution environment is deleted and a virtual second execution environment is newly constructed, and the relay process is taken over by the second execution environment.

10. The information processing program according to claim 9, further causing processing to be executed.

11. The computer when receiving, from a first job management device, a first request for starting execution of a job, in which first identification information for identifying the job is specified, transferring the first request to a job execution system that executes the job, receiving second identification information for identifying the job from the job execution system, and storing the first identification information and the second identification information in a storage unit in association with each other; transmitting a third request to the job execution system, specifying the second identification information and requesting status information indicating an execution status of the job, and storing the status information transmitted from the job execution system in the storage unit in association with the first identification information; when a second request specifying the first identification information and requesting the status information is received from the first job management device, the status information associated with the first identification information is acquired from the storage unit and transmitted to the first job management device; when receiving a fourth request specifying the first identification information from a second job management device that has taken over the monitoring process of monitoring the execution status of the job from the first job management device, acquiring the status information associated with the first identification information from the storage unit and transmitting the status information to the second job management device; An information processing method for performing relay processing.

Images