[go: up one dir, main page]

WO2024190043A1 - プログラム、情報処理方法および情報処理装置 - Google Patents

プログラム、情報処理方法および情報処理装置 Download PDF

Info

Publication number
WO2024190043A1
WO2024190043A1 PCT/JP2023/046854 JP2023046854W WO2024190043A1 WO 2024190043 A1 WO2024190043 A1 WO 2024190043A1 JP 2023046854 W JP2023046854 W JP 2023046854W WO 2024190043 A1 WO2024190043 A1 WO 2024190043A1
Authority
WO
WIPO (PCT)
Prior art keywords
node
standby
machine
operational
job
Prior art date
Application number
PCT/JP2023/046854
Other languages
English (en)
French (fr)
Inventor
良太 金谷
幸大 竹内
明伸 高石
直己 小島
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Publication of WO2024190043A1 publication Critical patent/WO2024190043A1/ja

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/656—Updates while running

Definitions

  • the present invention relates to a program, an information processing method, and an information processing device.
  • Cloud systems lend computing resources such as physical machines and virtual machines to users, and run the application programs used by the users on those computing resources.
  • a synchronization method has been proposed in which, in a cluster system including an active node and a standby node, the active node generates synchronization data and stores it in an external memory unit, while also sending an instruction to start the standby node to the control device.
  • the control device starts the standby node when it receives the start instruction.
  • the standby node obtains the synchronization data from the external memory unit, and reflects the updates indicated by the synchronization data in the memory unit of the standby node.
  • a standby node may be started every time synchronization data is generated on the production node, and the synchronization data may be reflected on the standby node.
  • running the standby node every time such synchronization processing is performed consumes computing resources for that amount of time. As a result, in addition to the job that the user actually wants to execute, additional costs due to the synchronization processing are incurred.
  • the present invention aims to efficiently improve availability.
  • a program causes a computer to execute the following process.
  • the computer places common data used in common for the execution of jobs corresponding to each of the multiple users in a first storage unit accessed by an active node used for a job corresponding to a first user among the multiple users, and in a second storage unit accessed by a standby node corresponding to the active node.
  • the computer writes unique data of the job corresponding to the first user, which is updated by the first user in response to the execution of the job by the active node, to a shared storage shared by the active node and the standby node, and stops the standby node while the active node is operating.
  • the computer starts the standby node and performs settings that enable the standby node to read the unique data from the shared storage.
  • an information processing method is provided.
  • an information processing device having a communication unit and a processing unit is provided.
  • FIG. 1 is a diagram illustrating an information processing apparatus according to a first embodiment.
  • FIG. 1 illustrates an example of a cloud system according to a second embodiment.
  • FIG. 2 illustrates an example of hardware of a physical machine.
  • FIG. 2 is a diagram illustrating an example of network connection relationships in a cloud system.
  • FIG. 2 illustrates an example of functions of a cloud system.
  • FIG. 13 illustrates an example of a management table.
  • FIG. 13 illustrates an example of mounting a shared storage by an operational machine and a standby machine.
  • 11 is a flowchart illustrating an example of switching between active and standby machines.
  • FIG. 13 illustrates an example of machine creation according to the third embodiment;
  • FIG. 13 illustrates an example of a management table.
  • FIG. 13 illustrates an example of editing a management table using a serverless function.
  • FIG. 13 is a diagram illustrating an example of load balancer control using a serverless function.
  • 13 is a flowchart illustrating an example of preparing a service upgraded machine.
  • 11 is a flowchart illustrating an example of a service upgraded machine creation.
  • 13 is a flowchart illustrating an example of updating a machine type in a management table.
  • FIG. 13 is a diagram showing a specific example of updating a machine type in the management table.
  • 13 is a flowchart illustrating an example of service upgrade control.
  • 13 is a flowchart illustrating an example of a service upgrade availability determination.
  • 11 is a flowchart showing an example of each step of failover processing.
  • FIG. 13 is a diagram illustrating an example of load balancer control using a serverless function.
  • 13 is a flowchart illustrating an example of preparing a service upgraded machine.
  • 11 is a flowchart
  • FIG. 1 is a diagram illustrating an information processing apparatus according to a first embodiment.
  • the information processing device 10 is connected to an information processing system 20.
  • the information processing device 10 may be included in the information processing system 20.
  • the information processing system 20 allows a plurality of nodes realized by a plurality of physical machines or a plurality of virtual machines to be used by a user.
  • the information processing system 20 is used by a plurality of users.
  • the information processing device 10 may be referred to as a computer.
  • the information processing system 20 may be referred to as a cloud system.
  • the users may be referred to as tenants.
  • the nodes included in the information processing system 20 execute jobs related to the services used by the user.
  • the user uses the nodes included in the information processing system 20 by using the access source node 30.
  • the access source node 30 may be a terminal device used by the user, such as a smartphone, tablet, or PC (Personal Computer), or it may be a physical machine or virtual machine included in the information processing system 20.
  • the information processing device 10 controls multiple nodes included in the information processing system 20.
  • the information processing device 10 has a memory unit 11, a processing unit 12, and a communication unit 13.
  • the memory unit 11 may be a volatile semiconductor memory such as a RAM (Random Access Memory), or a non-volatile storage such as a HDD (Hard Disk Drive) or flash memory.
  • the memory unit 11 stores data used for processing by the processing unit 12.
  • the processing unit 12 is, for example, a processor such as a CPU (Central Processing Unit), a GPU (Graphics Processing Unit), or a DSP (Digital Signal Processor). However, the processing unit 12 may also include electronic circuits for specific purposes such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).
  • the processor executes programs stored in a memory such as a RAM (which may be the memory unit 11).
  • a collection of multiple processors is sometimes called a "multiprocessor" or simply a "processor.”
  • the communication unit 13 is a communication interface used for communication with each node included in the information processing system 20.
  • the processing unit 12 communicates with each node via the communication unit 13.
  • the information processing system 20 has an active node 21, a standby node 22, a first storage unit 23, a second storage unit 24, a shared storage 25, and a relay node 26.
  • the active node 21 is an active node that executes a job of a first user among a plurality of users.
  • the standby node 22 is a standby node that corresponds to the active node 21. Taking into consideration the influence of disasters and the like, the active node 21 and the standby node 22 may be provided at geographically separated bases such as data centers.
  • the first storage unit 23 is a local storage of the operational node 21 that is accessed by the operational node 21.
  • a storage area such as an HDD or SSD allocated to the operational node 21 is used for the first storage unit 23.
  • the second storage unit 24 is a local storage of the standby node 22 that is accessed by the standby node 22.
  • a storage area such as an HDD or SSD allocated to the standby node 22 is used for the second storage unit 24.
  • the shared storage 25 is a storage shared by the operational node 21 and the standby node 22, and can be mounted on the operational node 21 and the standby node 22.
  • the shared storage 25 has a storage device such as an HDD or SSD, and provides the storage area of the storage device to the operational node 21 and the standby node 22.
  • the shared storage 25 is mounted from the operational node 21 and the standby node 22 via the network.
  • the relay node 26 is a node that relays access from the access source node 30 to the operation node 21 or the standby node 22. When a job is run on the operation node 21, the relay node 26 transfers the request from the access source node 30 to the operation node 21. When a job is run on the standby node 22, the relay node 26 transfers the request from the access source node 30 to the standby node 22.
  • the processing unit 12 communicates with the operational node 21 and the standby node 22 via the communication unit 13, and controls the operational node 21 and the standby node 22 as follows.
  • the control described below may be realized by the processing unit 12 executing a lightweight program called a serverless function in a cloud system, for example.
  • the processing unit 12 places common data in the first storage unit 23 and the second storage unit 24, which is used in common to execute jobs corresponding to multiple users.
  • the common data is, for example, a job management software program that manages jobs, such as defining and executing jobs.
  • Each user can use the software's functions to define processing related to a service that they wish to use as a job, and have the node they use execute that job.
  • the processing unit 12 When the active node 21 and the standby node 22 are each realized by a virtual machine, the processing unit 12 creates the active node 21 and the standby node 22 using a virtual machine image that includes the common data. This allows the processing unit 12 to place the common data in the first storage unit 23 that is assigned to the active node 21 based on the virtual machine image, and in the second storage unit 24 that is assigned to the standby node 22 based on the virtual machine image.
  • the processing unit 12 causes the operation node 21 to write unique data, which is updated by the first user or in response to the execution of a job corresponding to the first user by the operation node 21, to the shared storage 25.
  • Unique data is user-specific data used for job execution.
  • the unique data of the first user includes, for example, at least one of job definition information indicating the content of the job defined by the first user and job status information indicating the execution status and execution result of the job.
  • the job definition information is updated by the first user according to the content of the job to be executed.
  • the job status information is updated according to the execution status of the job.
  • the processing unit 12 stops the standby node 22 while the operation node 21 is operating.
  • the processing unit 12 mounts the shared storage 25 on the operation node 21, thereby enabling the operation node 21 to write unique data directly to the shared storage 25.
  • the processing unit 12 stops the standby node 22 created from the virtual machine image and maintains the standby node 22 in a startable state.
  • the processing unit 12 When switching the job execution subject from the active node 21 to the standby node 22, the processing unit 12 starts the standby node 22 and performs settings that enable the standby node 22 to read the unique data from the shared storage 25. Specifically, the processing unit 12 mounts the shared storage 25 on the standby node 22, thereby enabling the standby node 22 to read the unique data.
  • the processing unit 12 detects an abnormality that makes it impossible to continue job operation on the operational node 21, such as a software error in the operational node 21, it switches the job execution subject from the operational node 21 to the standby node 22.
  • the processing unit 12 unmounts the shared storage 25 from the operational node 21 and mounts the shared storage 25 on the started standby node 22.
  • a specified storage area in which unique data of the shared storage 25 is written is mounted to a mount point of the standby node 22.
  • the standby node 22 can then read the unique data written in the shared storage 25 via the mount point.
  • the standby node 22 takes over and executes the job from the operational node 21 based on the common data stored in the second storage unit 24 and the unique data stored in the shared storage 25.
  • the processing unit 12 When switching from the active node 21 to the standby node 22, the processing unit 12 performs a setting on the relay node 26 to switch the access destination of the access source node 30 from the active node 21 to the standby node 22. For example, before unmounting the shared storage 25 from the active node 21, the processing unit 12 deletes the information of the active node 21 (e.g., a host name or an IP (Internet Protocol) address) from the connection destination information held by the relay node 26.
  • the connection destination information indicates the forwarding destination of the request by the relay node 26, and information such as the IP address of the forwarding destination is registered in association with information such as the IP address of the request sender.
  • the processing unit 12 adds the information of the standby node 22 (e.g., a host name or an IP address) to the connection destination information held by the relay node 26.
  • the standby node 22 continues to provide services to the first user.
  • common data commonly used in the execution of jobs of each user is placed in the first storage unit 23 accessed by the active node 21 and the second storage unit 24 accessed by the standby node 22.
  • Job-specific data corresponding to the first user which is updated in response to job execution by the active node 21 or by the first user, is written to the shared storage 25, and the standby node 22 is stopped while the active node 21 is operating.
  • the standby node 22 is started. Then, settings are made to enable the standby node 22 to read the unique data from the shared storage 25.
  • the shared storage 25 is shared by both the active node 21 and the standby node 22 by making it mountable from both nodes, the shared storage 25 is shared by the active node 21 and the standby node 22 via the network. For this reason, if a relatively large amount of data is read from the shared storage 25 to the standby node 22 during switching, it may take a long time to read the data. This may cause a delay in completing the switching, affecting availability.
  • the information processing device 10 places common data in the first storage unit 23 of the active node 21 and the second storage unit 24 of the standby node 22, and writes unique data other than the common data to the shared storage 25. This reduces the amount of data read from the shared storage 25 by the standby node 22 at the time of switching, compared to writing both common data and unique data to the shared storage 25. As a result, for example, the time required from detection of an abnormality in the active node 21 to resuming a job related to the service by the standby node 22 is reduced, and quick switching from the active node 21 to the standby node 22 can be performed.
  • the information processing device 10 can reduce delays during switching and omit the synchronization process, compared to a method in which the standby node 22 is started and the synchronization process is performed each time the synchronization process is performed. Therefore, the information processing device 10 can ensure availability while reducing the cost associated with running the standby node 22.
  • FIG. 2 illustrates an example of a cloud system according to the second embodiment.
  • Cloud system 2 provides cloud services.
  • AWS Amazon Web Services
  • AWS is a registered trademark.
  • Amazon is a registered trademark.
  • Cloud system 2 may provide other cloud services.
  • Cloud system 2 has physical machines 100, 100a, ....
  • the physical machines 100, 100a, ... are servers having computing resources provided to users.
  • cloud system 2 further includes a large amount of hardware such as network devices and storage devices.
  • Cloud system 2 lends resources such as the physical machines 100, 100a, ..., network devices, and storage devices to users and makes them available for use by the users.
  • the cloud system 2 charges the user a fee according to the performance, amount, and usage time of the resources used by the user.
  • the fee is an example of the user's costs associated with using the cloud system 2.
  • the cost may be another indicator, such as power consumption or an electricity bill according to the power consumption.
  • the cloud system 2 is connected to the Internet 3.
  • a terminal device 4 is also connected to the Internet 3.
  • the terminal device 4 is a client computer operated by a user.
  • the user can use the services of the cloud system 2 by operating the terminal device 4.
  • a tenant a user or a group of users who use the cloud system 2 will be referred to as a tenant.
  • FIG. 3 is a diagram illustrating an example of hardware of a physical machine.
  • the physical machine 100 has a processor 101, a RAM 102, a HDD 103, a GPU 104, an input interface 105, a media reader 106, and a communication interface 107. These units of the physical machine 100 are connected to a bus inside the physical machine 100.
  • the processor 101 corresponds to the processing unit 12 of the first embodiment.
  • the RAM 102 or the HDD 103 corresponds to the storage unit 11 of the first embodiment.
  • the communication interface 107 corresponds to the communication unit 13 of the first embodiment.
  • the processor 101 is an arithmetic device that executes program instructions.
  • the processor 101 is, for example, a CPU.
  • the processor 101 loads at least a portion of the programs and data stored in the HDD 103 into the RAM 102 and executes the programs.
  • the processor 101 may include multiple processor cores.
  • the physical machine 100 may also have multiple processors. The processing described below may be executed in parallel using multiple processors or processor cores. A collection of multiple processors may also be called a "multiprocessor" or simply a "processor.”
  • RAM 102 is a volatile semiconductor memory that temporarily stores programs executed by processor 101 and data used by processor 101 for calculations. Note that physical machine 100 may be equipped with a type of memory other than RAM, and may be equipped with multiple memories.
  • HDD 103 is a non-volatile storage device that stores software programs such as the OS (Operating System), middleware, and application software, as well as data.
  • OS Operating System
  • middleware middleware
  • application software application software
  • physical machine 100 may also be equipped with other types of storage devices, such as flash memory or SSDs (Solid State Drives), and may also be equipped with multiple non-volatile storage devices.
  • the GPU 104 outputs images to a display 111 connected to the physical machine 100 in accordance with instructions from the processor 101.
  • the display 111 can be any type of display, such as a CRT (Cathode Ray Tube) display, a Liquid Crystal Display (LCD), a plasma display, or an Organic Electro-Luminescence (OEL) display.
  • CTR Cathode Ray Tube
  • LCD Liquid Crystal Display
  • OEL Organic Electro-Luminescence
  • the input interface 105 acquires an input signal from an input device 112 connected to the physical machine 100 and outputs it to the processor 101.
  • the input device 112 may be a pointing device such as a mouse, a touch panel, a touch pad, or a trackball, a keyboard, a remote controller, or a button switch.
  • multiple types of input devices may be connected to the physical machine 100.
  • the media reader 106 is a reading device that reads programs and data recorded on the recording medium 113.
  • the recording medium 113 for example, a magnetic disk, an optical disk, a magneto-optical disk (MO: Magneto-Optical disk), a semiconductor memory, etc. can be used.
  • Magnetic disks include flexible disks (FD: Flexible Disks) and HDDs.
  • Optical disks include CDs (Compact Discs) and DVDs (Digital Versatile Discs).
  • the media reader 106 copies, for example, the programs and data read from the recording medium 113 to another recording medium such as the RAM 102 or the HDD 103.
  • the read programs are executed, for example, by the processor 101.
  • the recording medium 113 may be a portable recording medium, and may be used to distribute programs and data.
  • the recording medium 113 and the HDD 103 may be referred to as computer-readable recording media.
  • the communication interface 107 is connected to the network 114 and communicates with other information processing devices via the network 114.
  • the communication interface 107 may be a wired communication interface connected to a wired communication device such as a switch or a router, or a wireless communication interface connected to a wireless communication device such as a base station or an access point.
  • the network 114 is an internal network of the cloud system 2.
  • FIG. 4 is a diagram illustrating an example of network connections in a cloud system.
  • Cloud system 2 has region 2a, virtual private cloud (VPC) 2b, and availability zones (AZ) 2c1 and 2c2.
  • VPC virtual private cloud
  • AZ availability zones
  • Region 2a is an area that has multiple data centers.
  • VPC 2b is a virtual network for a tenant that is constructed in cloud system 2 within region 2a.
  • VPCs are logically separated for each tenant. In other words, multiple VPCs can exist for multiple tenants.
  • AZs 2c1 and 2c2 are collections of one or more data centers located within region 2a. Although not shown in the figure, AZs 2c1 and 2c2 include subnets, which are the management units of the networks used by the tenants.
  • the cloud system 2 has a monitoring node 40, a serverless function execution node 50, a machine image management node 60, a management DB (DataBase) 70, an Internet gateway 80, and a load balancer 90.
  • the monitoring node 40 detects events by monitoring the virtual machines used by the tenants, and instructs the serverless function execution node 50 to execute a serverless function in response to the event.
  • the serverless function execution node 50 executes serverless functions. Processing by serverless functions includes control such as starting and stopping a tenant's virtual machine and changing the settings of the load balancer 90. Different serverless functions may be prepared in advance for each type of control, and a serverless function according to the type of control to be executed may be executed.
  • the machine image management node 60 manages the machine images of the virtual machines used by the tenants.
  • a machine image is data used to start up a virtual machine.
  • the monitoring node 40, the serverless function execution node 50, and the machine image management node 60 are arranged, for example, in a network at the same level as the region 2a in the cloud system 2.
  • the network of the region 2a is connected to the network of the VPC 2b.
  • the monitoring node 40, the serverless function execution node 50, and the machine image management node 60 can communicate with nodes in the VPC 2b via the network of the region 2a.
  • the management DB 70 stores data used in the processing of the monitoring node 40 and the server-less function execution node 50.
  • the management DB 70 is placed in the network of region 2a.
  • the Internet gateway 80 is a node that is connected to the Internet 3 and relays communications between the Internet 3 and nodes within the VPC 2b.
  • the Internet gateway 80 is provided in the region 2a.
  • the load balancer 90 is a node that relays communications between the Internet gateway 80 and the virtual machines in AZs 2c1 and 2c2.
  • the load balancer 90 receives tenant requests sent by terminal devices 4 via the Internet gateway 80, and controls the allocation of the requests to the virtual machines in AZs 2c1 and 2c2.
  • the load balancer 90 is provided in VPC 2b.
  • the AZ2c1 has an operational machine 200 and storage 201.
  • the operational machine 200 is an operational virtual machine used by a tenant corresponding to VPC2b, and executes jobs related to the services used by the tenant.
  • the storage 201 is local storage for the operational machine 200.
  • the AZ2c2 has a standby machine 300 and a storage 301.
  • the standby machine 300 is a standby virtual machine corresponding to the operational machine 200.
  • the standby machine 300 is used by a tenant corresponding to VPC2b.
  • the standby machine 300 is stopped when the operational machine 200 is operating. If the standby machine 300 is stopped, the computing resources of the standby machine 300 are not used, so no charge is made to the tenant.
  • the standby machine 300 is started when an abnormality occurs in the operational machine 200, and takes over and executes the job of the operational machine 200.
  • the storage 301 is a local storage of the standby machine 300.
  • the control of switching the operation of the operational machine 200 to the standby machine 300 is called a failover. As described later, a failover is also used when upgrading machines.
  • VPC2b is provided with shared storage 400 that can be accessed from the operational machine 200 and the standby machine 300 via a network within VPC2b.
  • the shared storage 400 can be mounted from the operational machine 200 and the standby machine 300.
  • the shared storage 400 stores data to be handed over to the standby machine 300 when switching from the operational machine 200 to the standby machine 300.
  • the monitoring node 40, the serverless function execution node 50, and the machine image management node 60 are realized by physical machines included in the physical machines 100, 100a, ....
  • the monitoring node 40, the serverless function execution node 50, and the machine image management node 60 may be realized by virtual machines executed using the hardware resources of the physical machines.
  • the monitoring node 40, the serverless function execution node 50, and the machine image management node 60 may be realized by a single physical machine, or by different physical machines.
  • the Internet gateway 80 and the load balancer 90 are realized by a communication device included in the cloud system 2, the physical machine, or a virtual machine on the physical machine.
  • the operational machine 200 and the standby machine 300 are virtual machines executed using the hardware resources of the physical machines included in the physical machines 100, 100a, ....
  • the storage 201 is realized by a storage area such as an HDD or SSD of the physical machine allocated to the operational machine 200.
  • the storage 301 is realized by a storage area such as an HDD or SSD of the physical machine allocated to the standby machine 300.
  • the management DB 70 is realized by a storage device having physical machines, HDDs, SSDs, etc. included in the region 2a.
  • the shared storage 400 is realized by a storage device that can be accessed by the operational machine 200 and the standby machine 300 via the network of VPC2b.
  • the storage device includes HDDs, SSDs, etc.
  • a portion of the memory area of the storage device is assigned as the shared storage 400 to the tenant corresponding to VPC2b.
  • FIG. 5 illustrates an example of functions of a cloud system.
  • the cloud system 2 has a monitoring unit 41 and a serverless function 51.
  • the monitoring unit 41 is realized by a processor of the monitoring node 40 executing a program stored in the RAM of the monitoring node 40.
  • the serverless function 51 is realized by a processor of the serverless function execution node 50 executing a lightweight program stored in the RAM of the serverless function execution node 50.
  • the monitoring unit 41 monitors the operational machine 200, and when it detects an abnormality in the operational machine 200, it causes the serverless function execution node 50 to start the serverless function 51. When a failover is performed by the serverless function 51, the monitoring unit 41 monitors the standby machine 300 that has become the new job executor (new operational machine).
  • the serverless function 51 performs a failover. During a failover, the serverless function 51 unmounts the shared storage 400 from the production machine 200, starts the standby machine 300, mounts the shared storage on the standby machine 300, and changes the destination to which requests are allocated by the load balancer 90. Note that these processes of the serverless function 51 may be shared and performed by multiple serverless functions.
  • storage 201 and storage 301 store tenant common data related to jobs executed by operational machine 200 and standby machine 300.
  • Tenant common data is data commonly used in the execution of jobs of multiple tenants, and is a software program that is the foundation for executing each tenant's job.
  • Each tenant can use the software functions to define processing related to the service they wish to use as a job, and have the node they use execute that job.
  • the shared storage 400 also stores tenant-specific data that is updated in response to the execution of a job by the production machine 200.
  • the tenant-specific data is information that indicates the state (job state) and definition (job definition) of a job.
  • the job definition may include the processing content of the job and the execution schedule of the job.
  • the job definition is updated by the tenant in response to the content of the job that the tenant wishes to execute.
  • the job state may include the execution results of the job so far.
  • the job state is updated in response to the execution of a job by the production machine 200.
  • the shared storage 400 may include standard storage, which has a relatively low usage fee, and high-speed storage, which has a higher usage fee than the standard storage. In that case, for example, among the tenant-specific data, job definition data, which is updated relatively infrequently, may be stored in the standard storage, and job status data, which is updated relatively frequently, may be stored in the high-speed storage. This reduces the cost of using the shared storage 400 by tenants while minimizing the impact on operations.
  • the management DB 70 also stores a management table 71 used to control failover.
  • the management table 71 is used to manage the operating status and machine images of the operational and standby machines for each tenant, including the operational machine 200 and the standby machine 300.
  • FIG. 6 illustrates an example of the management table.
  • the management table 71 includes the following fields: tenant ID (identifier), tenant status, machine ID, machine type, and image ID.
  • tenant ID is registered in the tenant ID field.
  • the tenant ID is identification information of a tenant.
  • the tenant status is registered in the tenant status item.
  • the tenant status indicates the state of the service upgrade for the tenant.
  • the tenant status is set to "normal” or "patch.”
  • the tenant status "normal” indicates a normal operating state.
  • the tenant status "patch” indicates a state in which a service upgraded machine, described below, has been prepared.
  • the machine ID field contains a machine ID, which is identification information for a virtual machine.
  • the machine type is registered in the machine type field.
  • the machine type indicates the type of virtual machine.
  • the machine type "production” indicates an operational machine.
  • the machine type "standby” indicates a standby machine.
  • the machine type “standby_new” indicates a standby machine whose service has been upgraded.
  • the machine type “production_new” indicates an operational machine whose service has been upgraded.
  • the machine type “standby_old” indicates a standby machine immediately before switching due to failover, i.e., an old standby machine.
  • the machine type “production_old” indicates an operational machine immediately before switching due to failover, i.e., an old operational machine.
  • the image ID is identification information of the machine image from which the virtual machine corresponding to the machine ID is created, and is used to obtain the data body of the machine image.
  • the management table 71 holds a tenant status of "normal” for the tenant ID "1".
  • the management table 71 has a record of the machine type "production” and the image ID "imageXXX1" for the machine ID "1”. This record is data indicating the operational machine 200.
  • the management table 71 has a record of the machine ID "2", the machine type "standby", and the image ID "imageXXX1" for the tenant ID "1". This record is data indicating the standby machine 300.
  • FIG. 7 is a diagram showing an example of mounting a shared storage by the active and standby machines.
  • the standby machine 300 When the production machine 200 is running, the standby machine 300 is stopped. In this case, the shared storage 400 is mounted on the production machine 200. When the standby machine 300 is stopped, the shared storage 400 is not mounted on the standby machine 300, that is, it is in an unmounted state with respect to the standby machine 300.
  • the production machine 200 writes the job definition and job status to the shared storage 400 as tenant-specific data. In response to input of a change to the job definition by the tenant, the production machine 200 updates the job definition included in the tenant-specific data of the shared storage 400. In addition, in response to execution of a job, the production machine 200 updates the job status included in the tenant-specific data of the shared storage 400.
  • the shared storage 400 is unmounted from the production machine 200. Then, the standby machine 300 is started, and the shared storage 400 is mounted on the standby machine 300. The standby machine 300 is then able to read from the shared storage 400 the latest tenant-specific data written by the production machine 200. The standby machine 300 takes over and executes the job from the production machine 200 based on the tenant common data stored in the storage 301 and the tenant-specific data stored in the shared storage 400.
  • FIG. 8 is a flowchart showing an example of switching between active and standby machines.
  • the monitoring unit 41 detects an abnormality in a service related to job execution in the operational machine 200.
  • the monitoring unit 41 instructs the serverless function execution node 50 to execute a serverless function 51. Then, the serverless function 51 is started, and the following process is executed.
  • the serverless function 51 obtains the tenant ID corresponding to the operational machine 200 and the machine ID of the machine of the machine type "standby" from the management table 71.
  • the machine type "standby” may be abbreviated as “type: standby”.
  • the serverless function 51 deletes the connection destination of the load balancer 90. Specifically, the serverless function 51 deletes the production machine 200 from the destination of requests forwarded by the load balancer 90.
  • the serverless function 51 stops the relevant service of the machine having the machine ID of the machine type “production”, i.e., the operational machine 200.
  • the serverless function 51 unmounts the shared storage 400 of the machine with the machine ID of the machine type “production”, that is, the production machine 200.
  • the serverless function 51 starts up the machine with the machine ID of the machine type “standby”, that is, the standby machine 300.
  • the serverless function 51 mounts the shared storage 400 on the machine with the machine ID of the machine type “standby”, that is, the standby machine 300.
  • the serverless function 51 starts the corresponding service of the machine having the machine ID of the machine type “standby”, i.e., the standby machine 300.
  • the serverless function 51 adds the standby machine 300 to the connection destinations of the load balancer 90. As a result, requests from the tenants are distributed to the standby machine 300 by the load balancer 90.
  • the serverless function 51 updates the management table 71. Specifically, the serverless function 51 changes the machine type of the standby machine 300 to "production”. The serverless function 51 also stops the production machine 200 and changes the machine type of the production machine 200 to "standby”. Then, the switch from the production machine 200 to the standby machine 300 is completed.
  • data linkage between the operational machine 200 and the standby machine 300 is performed using the shared storage 400 under the control of the serverless function 51.
  • the standby machine 300 can directly read the unique data updated by the operational machine 200 from the shared storage 400. This eliminates the need to perform periodic data synchronization processing between the operational machine 200 and the standby machine 300, and it is sufficient to start the standby machine 300 when switching from the operational machine 200 to the standby machine 300.
  • the shared storage 400 is shared by the operational machine 200 and the standby machine 300 via the network. For this reason, if the standby machine 300 is made to read a relatively large amount of data from the shared storage 400 during switching, it may take a long time to read that data. This will cause a delay in completing the switching, affecting availability.
  • the serverless function 51 places tenant common data in the storage 201 of the production machine 200 and the storage 301 of the standby machine 300, and writes tenant-specific data to the shared storage 400. This reduces the amount of data read from the shared storage 400 by the standby machine 300 at the time of switching, compared to writing both tenant common data and tenant-specific data to the shared storage 400. As a result, the time required from detection of an abnormality in the production machine 200 to the standby machine 300 resuming a job related to the service is reduced, and switching from the production machine 200 to the standby machine 300 can be performed quickly.
  • the tenant common data is not stored in the shared storage 400
  • the memory resources allocated to the shared storage 400 can be reduced compared to storing both the tenant common data and the tenant specific data in the shared storage 400.
  • the standby machine 300 can obtain the latest tenant specific data from the shared storage 400 and continue job operations.
  • the failover process exemplified in the second embodiment is used when upgrading the services provided by the operational machine 200.
  • the hardware and functions of the cloud system 2 in the third embodiment are similar to those exemplified in Figures 2 to 5, and therefore a description thereof will be omitted.
  • FIG. 9 illustrates an example of machine creation according to the third embodiment.
  • AZ2c1 has a service-upgraded machine 200a in addition to the operational machine 200 and storage 201.
  • the service-upgraded machine 200a is a virtual machine in which an upgraded program of the service provided by the operational machine 200 is installed.
  • the service-upgraded machine 200a is created using a machine image 61.
  • the machine image 61 is image data of the virtual machine in which the upgraded program is installed.
  • the service-upgraded machine 200a also has local storage, and the upgraded program is stored in the local storage as tenant common data.
  • AZ2c2 has a service-upgraded machine 300a in addition to a standby machine 300 and storage 301.
  • the service-upgraded machine 300a is a virtual machine on which an upgraded program for the service provided by the operational machine 200 is installed.
  • the service-upgraded machine 300a is also created using a machine image 61.
  • the service-upgraded machine 300a also has local storage, and the upgraded program is stored in the local storage as tenant common data.
  • the service upgraded machine 200a is used as a new standby system (new standby system).
  • the service upgraded machine 300a is used as a new operational system (new operational system).
  • machine image 61 contains tenant common data, which is the upgraded program, but does not contain tenant specific data. For this reason, machine image 61 can be reused for multiple tenants. This eliminates the need to create machine image 61 for each tenant, making it possible to more efficiently deploy virtual machines that have undergone service upgrades.
  • the service-upgraded machines 200a and 300a are created from the machine image 61, started, and then immediately stopped and maintained in a startable state.
  • the serverless function 51 manages the service-upgraded machines 200a and 300a as follows.
  • FIG. 10 illustrates an example of the management table.
  • a management table 71a illustrates an example in which information on the service-upgraded machines 200a and 300a has been added to the management table 71.
  • the items included in the management table 71a are the same as those included in the management table 71.
  • the management table 71a holds a tenant status of "patch” for the tenant ID "1".
  • the tenant status "patch” indicates that the service upgraded machines 200a and 300a are prepared.
  • the management table 71a holds a record of the machine ID "3", the machine type "standby_new", and the image ID "imageXXX2" for the tenant ID "1". This record is data indicating the service upgraded machine 200a.
  • the management table 71a holds a record of the machine ID "4", the machine type "production_new”, and the image ID "imageXXX2" for the tenant ID "1".
  • This record is data indicating the service upgraded machine 300a.
  • the image ID "imageXXX2" indicates the machine image 61.
  • the management table 71a also shows an example in which data related to a virtual machine of a tenant with a tenant ID of "2" is registered.
  • FIG. 11 is a diagram illustrating an example of editing the management table by the serverless function.
  • the serverless function 51 registers information about the service-upgraded machines 200a, 300a in the management table 71a.
  • the service upgraded machines 200a and 300a are created while the operational machine 200 is in a booted state and running. After being created, both the service upgraded machines 200a and 300a are stopped. In this way, the serverless function 51 prepares the service upgraded machines 200a and 300a in AZ2c1 and 2c2, respectively.
  • FIG. 12 illustrates an example of load balancer control using a serverless function.
  • the serverless function 51 switches the job execution subject from the current operational machine 200 to the service-upgraded machine 300a (new operational machine) during a time period when the operational machine 200 is not executing jobs. Specifically, the serverless function 51 unmounts the shared storage 400 from the operational machine 200 based on the management table 71a, and stops the operational machine 200. Next, the serverless function 51 starts the service-upgraded machine 300a, and mounts the shared storage 400 on the service-upgraded machine 300a.
  • the serverless function 51 configures the load balancer 90 to switch the forwarding destination of the tenant's requests from the production machine 200 to the service upgraded machine 300a.
  • the serverless function 51 rewrites the host name or IP address of the production machine 200 in the production machine connection destination information held by the load balancer 90 to the host name or IP address of the service upgraded machine 300a.
  • the load balancer 90 has standby machine connection destination information
  • the host name or IP address of the standby machine 300 in the standby machine connection destination information may be rewritten to the host name or IP address of the service upgraded machine 200a.
  • the serverless function 51 switches operation from the operational machine 200 to the service-upgraded machine 300a.
  • a description will be given of a procedure for switching from the operational machine 200 to the service-upgraded machine 300a.
  • the procedure will be described below for the tenant with the tenant ID "1", but the procedure is similar for the other tenants.
  • FIG. 13 is a flow chart showing an example of preparing a service upgraded machine.
  • the monitoring unit 41 starts the serverless function 51 to execute the following procedure.
  • the instruction to create a virtual machine may be input to the machine image management node 60, and the machine image management node 60 may start the serverless function 51 to execute the following procedure.
  • the serverless function 51 creates a service-upgraded machine. Details of the creation of the service-upgraded machine will be described later. The creation of the service-upgraded machine is executed while the production machine 200 is running a job.
  • the serverless function 51 updates the machine type in the management table. The details of the machine type update will be described later.
  • the serverless function 51 updates the tenant status in the management table. For example, the serverless function 51 updates the tenant status corresponding to the tenant ID “1” from “normal” to “patch.” Then, preparation of the service-upgraded machine is completed.
  • Management table 71a in FIG. 10 illustrates an example of a management table at the stage immediately prior to the machine type update in step S21, when the tenant status update in step S22 is performed before the machine type update in step S21.
  • FIG. 14 is a flow chart illustrating an example of creating a service upgraded machine. Creating a service-upgraded machine corresponds to step S20. (S30) The serverless function 51 obtains information on the machines of the machine types “production” and “standby” corresponding to the tenant ID “1”, that is, the production machine 200 and the standby machine 300, from the management table 71.
  • the serverless function 51 acquires a machine of the machine type “standby”, that is, a subnet in which the standby machine 300 exists.
  • the serverless function 51 creates a machine of the machine type “production_new”, i.e., the service-upgraded machine 300a, in the subnet acquired in step S31 from the service-upgraded machine image 61.
  • the serverless function 51 creates the service-upgraded machine 300a in, for example, AZ2c2 different from AZ2c1 where the current operational machine 200 exists.
  • the serverless function 51 stops the service upgraded machine 300a (machine of machine type "production_new") because the service upgraded machine 300a is started by the creation of step S32.
  • the serverless function 51 obtains the subnet in which the machine of the machine type “production”, i.e., the operational machine 200, exists.
  • the serverless function 51 creates a machine of the machine type “standby_new”, i.e., the service upgraded machine 200a, from the service upgraded machine image 61 in the subnet acquired in step S34.
  • the serverless function 51 creates the service upgraded machine 200a in, for example, AZ2c1 different from AZ2c2 in which the service upgraded machine 300a, which will be the new operational system, exists.
  • the serverless function 51 stops the service upgraded machine 200a (machine of machine type "standby_new") created in step S35 because the service upgraded machine 200a is to be started.
  • the serverless function 51 adds information about the service-upgraded machines 200a and 300a to the management table 71. Then, the creation of the service-upgraded machine is completed.
  • FIG. 15 is a flowchart showing an example of updating the machine type in the management table. Updating the machine type in the management table corresponds to step S21. (S40) The serverless function 51 obtains the machine type of each machine corresponding to the tenant ID “1”.
  • the serverless function 51 updates the machine type of each virtual machine of tenant "1" included in the management table after the update in step S37 as follows: The serverless function 51 updates the machine type "production” to "production_old”. The serverless function 51 updates the machine type "standby_new” to "standby”. The serverless function 51 updates the machine type "standby” to "standby_old”. The serverless function 51 updates the machine type "production_new" to "production”. Then, the machine type update in the management table is completed.
  • FIG. 16 is a diagram showing a specific example of updating the machine type in the management table.
  • the serverless function 51 updates the management table 71 to a management table 71b in step S37.
  • the serverless function 51 updates the management table 71b to a management table 71c by the procedure illustrated in FIG. 15.
  • the management table 71c shows the management table after the update in step S41.
  • the serverless function 51 executes step S22 to update the tenant status of the management table 71c from "normal" to "patch”.
  • the management table 71d shows a state in which the tenant status of the management table 71c is updated from "normal" to "patch".
  • FIG. 17 is a flowchart showing an example of service upgrade control.
  • the procedure below is described as being executed by the serverless function 51, but the procedure below may be executed by a serverless function different from the serverless function 51 that executes the preparation of a service-upgraded machine.
  • the serverless function 51 is periodically started by a predetermined resident process to execute the procedure below.
  • the resident process may be executed by the monitoring node 40, for example, or the serverless function execution node 50.
  • the serverless function 51 obtains the tenant status of the relevant tenant from the management table 71c. Note that, as an example, the procedure for the tenant with tenant ID "1" is shown, but the same procedure applies to other tenants.
  • the serverless function 51 determines whether the tenant status is "patch”. If the tenant status is "patch”, processing proceeds to step S53. If the tenant status is not "patch”, that is, if the tenant status is "normal”, processing proceeds to step S52.
  • step S52 The serverless function 51 waits for a certain period of time. Note that in step S52, the resident process may wait for a certain period of time and then start the serverless function 51 after the certain period of time has elapsed. Then, the process proceeds to step S50.
  • the serverless function 51 determines whether or not the service can be upgraded. Details of the service upgrade determination will be described later. If the serverless function 51 determines that the service can be upgraded in the service upgrade determination, the process proceeds to step S54.
  • the serverless function 51 deletes the connection destination of the load balancer 90. Specifically, the serverless function 51 deletes the information of the production machine 200 of the corresponding tenant from the connection destination of the load balancer 90.
  • the serverless function 51 executes each failover process. The details of each failover process will be described later.
  • Each failover process updates the management table 71c, and preparations are made to add the new operational virtual machine to the connection destination of the load balancer 90.
  • the serverless function 51 adds the new operational system to the connection destinations of the load balancer 90. Specifically, the serverless function 51 adds information about the service upgraded machine 300a, which is the virtual machine of the new operational system, to the connection destinations of the load balancer 90.
  • step S57 The serverless function 51 updates the tenant status in the management table for the relevant tenant to "normal". Then, processing proceeds to step S50. In the next step S50 and subsequent steps, service upgrade control is performed for the next tenant.
  • FIG. 18 is a flowchart showing an example of a service upgrade permission determination.
  • the determination as to whether or not the service can be upgraded corresponds to step S53.
  • the serverless function 51 acquires the execution status of the job of the corresponding tenant.
  • the serverless function 51 may acquire the execution status of the job from the operational machine 200.
  • the operational machine 200 may acquire information on the job execution status stored in the shared storage 400 and provide it to the serverless function 51.
  • the serverless function 51 obtains the schedule of the job.
  • the serverless function 51 may obtain the job schedule from the production machine 200.
  • the production machine 200 may obtain job definition information stored in the shared storage 400, and provide the schedule information included in the job definition information to the serverless function 51.
  • the serverless function 51 determines whether or not a service upgrade is currently possible based on the job execution status and job schedule acquired in steps S60 and S61. If a service upgrade is currently possible, the service upgrade feasibility determination ends. If a service upgrade is currently not possible, the process proceeds to step S63. For example, the serverless function 51 may determine that a service upgrade is currently not possible when a job is currently being executed in the production machine 200 or when the time until the start of job execution is approaching within a predetermined time. On the other hand, the serverless function 51 may determine that a service upgrade is currently possible when a job is not currently being executed in the production machine 200 and the time until the start of job execution is later than a predetermined time from the current time. The predetermined time used in the determination in step S62 is determined in advance according to the time required for failover.
  • the serverless function 51 waits for a certain period of time. Then, the process proceeds to step S60. In this way, the serverless function 51 determines the timing of execution of a failover in a service upgrade so that the job by the operational machine 200 is not interrupted or not executed according to schedule, thereby reducing the influence of the operational machine 200 on the job operation.
  • FIG. 19 is a flowchart showing an example of each step of failover processing.
  • Each step of the failover process corresponds to step S55.
  • the serverless function 51 obtains, from the management table 71c, the machine IDs of the machine types “production_old” and “production” corresponding to the tenant ID of the processing target tenant.
  • the serverless function 51 stops the service of the machine having the machine ID of the machine type “production_old”, that is, the operational machine 200.
  • the serverless function 51 unmounts the shared storage 400 of the machine having the machine ID of the machine type “production_old”, that is, the production machine 200.
  • the serverless function 51 starts the machine with the machine ID of the machine type “production”, that is, the service-upgraded machine 300a.
  • the serverless function 51 mounts the shared storage 400 on the machine with the machine ID of the machine type "production", that is, the service upgraded machine 300a.
  • the serverless function 51 starts the service of the machine with the machine ID of the machine type "production", i.e., the service-upgraded machine 300a.
  • the serverless function 51 stops the machine with the machine ID of the machine type “production_old”, that is, the production machine 200.
  • the serverless function 51 deletes the machines having the machine IDs of the machine types “production_old” and “standby_old”, i.e., the production machine 200 and the standby machine 300.
  • the serverless function 51 deletes the information about the machines with the machine IDs of the machine types "production_old” and "standby_old", i.e., the production machine 200 and the standby machine 300, from the management table 71c. Then, each failover process ends.
  • the service upgraded machine 300a can directly read the tenant-specific data updated by the operational machine 200 from the shared storage 400.
  • tenant common data is stored in the local storage of the service upgraded machine 300a. Therefore, the service upgraded machine 300a can take over and execute service jobs from the operational machine 200 based on the tenant common data and the tenant-specific data.
  • the serverless function 51 can efficiently perform switching from the production machine 200 to the service-upgraded machine 300a by sharing unique data between the two machines via the shared storage 400.
  • the amount of data read from the shared storage 400 by the service-upgraded machine 300a at the time of switching is reduced compared to writing both tenant common data and tenant specific data to the shared storage 400.
  • the time required for the service-upgraded machine 300a to resume a job related to the service instead of the production machine 200 is reduced, and switching from the production machine 200 to the service-upgraded machine 300a can be performed quickly.
  • FIG. 20 is a diagram showing a comparative example.
  • the comparative example is a case where data is synchronized between each virtual machine in AZ 2c1, 2c2 using external storage 5b provided by cloud system 2, instead of shared storage 400 that can be mounted on each virtual machine in AZ 2c1, 2c2.
  • External storage 5b is provided in a relatively higher network than cloud system 2, and cannot be mounted on each virtual machine in AZ 2c1, 2c2.
  • External storage 5b is accessed by management node 5a.
  • Management node 5a is provided in a network at the same hierarchical level as monitoring node 40, serverless function execution node 50, and machine image management node 60, for example.
  • AZ2c1 has a monitoring unit 210.
  • the monitoring unit 210 monitors the operational machine 200 and cooperates with the management node 5a.
  • the monitoring unit 210 may be realized by the operational machine 200, or may be realized by a virtual machine in AZ2c1 that is different from the operational machine 200.
  • AZ2c2 has a monitoring unit 310.
  • the monitoring unit 310 monitors the standby machine 300 and cooperates with the management node 5a.
  • the monitoring unit 310 may be realized by the standby machine 300, or may be realized by a virtual machine in AZ2c2 that is different from the standby machine 300. For example, when the monitoring unit 210 detects an abnormality in the operational machine 200, it instructs the management node 5a to switch from the operational machine 200 to the standby machine 300.
  • the operational machine 200 writes both tenant common data (programs) and tenant specific data (job definitions and job status) to the local storage 201. Then, when the tenant common data or tenant specific data in the storage 201 is updated, the updated data is written to the external storage 5b for synchronization with the standby machine 300.
  • the management node 5a When performing synchronization, the management node 5a starts the standby machine 300.
  • the started standby machine 300 obtains the latest data from the external storage 5b and reflects it in the local storage 301.
  • the serverless function execution node 50 uses the shared storage 25 to coordinate data between the operational machine 200 and the standby machine 300.
  • the standby machine 300 can read the unique data updated by the operational machine 200 from the shared storage 400. This eliminates the need to perform data synchronization processing between the operational machine 200 and the standby machine 300 periodically or each time data is updated, and it is sufficient to start the standby machine 300 when switching from the operational machine 200 to the standby machine 300.
  • the shared storage 400 is shared between the operational machine 200 and the standby machine 300 by making it mountable from both machines, the shared storage 400 is shared by the operational machine 200 and the standby machine 300 via a network. For this reason, if a relatively large amount of data is read from the shared storage 400 to the standby machine 300 during switching, it may take a long time to read the data. This will cause a delay in completing the switchover and affect availability.
  • the serverless function execution node 50 arranges tenant common data in the storage 201 of the production machine 200 and the storage 301 of the standby machine 300, and writes tenant specific data to the shared storage 400. This reduces the amount of data read from the shared storage 400 by the standby machine 300 at the time of switching, compared to writing both tenant common data and tenant specific data to the shared storage 400. As a result, for example, the time required from detection of an abnormality in the production machine 200 to the standby machine 300 resuming a job related to the service is reduced, and switching from the production machine 200 to the standby machine 300 can be performed quickly.
  • the serverless function execution node 50 can reduce unnecessary costs associated with the execution of the standby machine 300 and speed up failover by omitting the synchronization process. In other words, the serverless function execution node 50 can efficiently improve the availability of the services provided by the operational machine 200.
  • tenant common data is not stored in the shared storage 400
  • memory resources allocated to the shared storage 400 can be reduced compared to storing both tenant common data and tenant specific data in the shared storage 400.
  • the switching from the operational machine 200 to the service-upgraded machine 300a has the same advantages as the switching from the operational machine 200 to the standby machine 300. That is, even in the third embodiment, the serverless function execution node 50 can efficiently improve the availability of the service provided by the operational machine 200.
  • the serverless function execution node 50 does not require the job operation by the operational machine 200 to be stopped in order to perform a service upgrade. In other words, the serverless function execution node 50 can smoothly switch to the service-upgraded machine 300a while minimizing the impact on job operation.
  • the processor 101 used in the serverless function execution node 50 executes the following processes.
  • the following processes may be realized by the processor 101 executing a program corresponding to the serverless function 51.
  • the processor 101 places common data used in common for the execution of jobs corresponding to each of the multiple users in each of the first storage unit of the active node and the second storage unit of the standby node used for a job corresponding to a first user among the multiple users.
  • the processor 101 writes unique data of the job corresponding to the first user, which is updated in response to the execution of the job by the active node or by the first user, from the active node to the shared storage.
  • the processor 101 mounts the shared storage on the active node and specifies the shared storage as the write destination for the unique data, thereby causing the active node to write the unique data to the shared storage.
  • the processor 101 stops the standby node while the active node is operating.
  • the processor 101 switches the execution subject of the job from the active node to the standby node, it starts the standby node and performs settings that enable the standby node to read the unique data from the shared storage.
  • the processor 101 communicates with the active node and the standby node via the communication interface 107.
  • the shared storage can be mounted on an active node and a standby node.
  • the processor 101 mounts the shared storage on the standby node.
  • the processor 101 can easily realize data sharing between the active node and the standby node. For example, the processor 101 can simply input a mount command to the OS of the standby node via the communication interface 107 and execute the command, eliminating the need to install special software for data sharing into the active node or the standby node.
  • the processor 101 unmounts the shared storage from the active node before mounting the shared storage on the standby node.
  • the processor 101 Before unmounting the shared storage from the active node, the processor 101 also deletes the information about the active node from the connection destination information held by the relay node.
  • the relay node is a node that relays a request sent by an access source node such as the terminal device 4 to the active node or the standby node.
  • the load balancer 90 is an example of a relay node. Then, after mounting the shared storage on the standby node, the processor 101 adds the information about the standby node to the connection destination information held by the relay node.
  • the processor 101 can set the request from the accessing node to be distributed to the standby node instead of the active node.
  • the processor 101 can also prevent the request from being transferred to the active node or the standby node during the switchover.
  • the common data is, for example, a program such as job management software that runs a job, that is, a specified program.
  • the processor 101 may prepare a new node with an upgraded specified program on the cloud system 2 and stop the new node.
  • the processor 101 may start the new node and perform settings that enable the new node to read unique data from the shared storage. For example, in settings that enable the new node to read unique data, the processor 101 mounts the shared storage on the new node.
  • the above-mentioned service-upgraded machine 300a is an example of a new node.
  • the new node is prepared by creating a new node on the cloud system 2 based on the machine image data corresponding to the new node.
  • the processor 101 may record in a management table used for managing nodes that the new node has been prepared for the operational node. For example, the tenant status "patch" in the management table 71a indicates that a new node has been prepared.
  • the processor 101 determines the timing for switching the job execution entity from the operational node to the new node according to the job execution status of the operational node. For example, the processor 101 may obtain the job execution schedule from the job definition information of the operational node, identify free time when the job is not executed, and determine the time included in the free time as the timing for switching.
  • the processor 101 deletes the information of the operational node in the management table and sets the new node as the new operational node.
  • the processor 101 can minimize the impact on job execution that accompanies switching from the active node to the new node, and can appropriately manage the virtual machine that is currently active using the management table.
  • the production node may also operate in a first availability zone (e.g., AZ2c1).
  • the standby node may operate in a second availability zone (e.g., AZ2c2).
  • the processor 101 may prepare a new node in one of the first and second availability zones, and prepare a standby node corresponding to the new node in the other availability zone.
  • the processor 101 can increase fault tolerance against failures in the availability zones and improve the availability of services.
  • the first availability zone may be said to be a collection of one or more first data centers to which the operational nodes are assigned, or may be said to be a zone to which the one or more first data centers belong.
  • the second availability zone may be said to be a collection of one or more second data centers to which the standby nodes are assigned, or may be said to be a zone to which the one or more second data centers belong.
  • the common data is, for example, a specified program that runs a job.
  • the specific data is, for example, information used by the specified program that indicates the job definition and the job status.
  • the processor 101 is particularly effective in improving the availability of services provided by operational nodes and standby nodes that perform job management using a specified program.
  • the processor 101 can efficiently improve the availability of job management services provided by operational nodes.
  • Information processing in the first embodiment can be realized by having the processing unit 12 execute a program.
  • Information processing in the second embodiment can be realized by having the processor 101 execute a program.
  • the program can be recorded on a computer-readable recording medium 113.
  • the program can be distributed by distributing the recording medium 113 on which it is recorded.
  • the program may also be stored in another computer and distributed via a network.
  • the computer may store (install) the program recorded on the recording medium 113 or a program received from another computer in a storage device such as the RAM 102 or HDD 103, and then read and execute the program from the storage device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Hardware Redundancy (AREA)

Abstract

【課題】可用性を効率的に向上する。 【解決手段】処理部１２は、運用系ノード２１によりアクセスされる第１記憶部２３および待機系ノード２２によりアクセスされる第２記憶部２４それぞれに、複数のユーザのジョブの実行に共通に用いられる共通データを配置する。処理部１２は、運用系ノード２１によるジョブの実行に応じて、または、第１ユーザにより更新される、第１ユーザに対応するジョブの固有データを、運用系ノードおよび待機系ノードにより共有される共有ストレージ２５に書き込ませる。処理部１２は、運用系ノード２１の稼働中には待機系ノード２２を停止状態とする。処理部１２は、ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える際に、待機系ノード２２を起動し、共有ストレージ２５からの、待機系ノード２２による固有データの読み取りを可能にする設定を行う。

Description

プログラム、情報処理方法および情報処理装置
　本発明はプログラム、情報処理方法および情報処理装置に関する。
　近年、アプリケーションプログラムを実行する情報処理環境をユーザが自ら所有する代わりに、サービス事業者のもつ情報処理環境をネットワーク経由で利用することが増えている。ネットワーク経由で情報処理環境を利用させる情報処理システムはクラウドシステムと言われることがある。クラウドシステムは、物理マシンや仮想マシンなどの計算リソースをユーザに貸し出し、ユーザが利用するアプリケーションプログラムをその計算リソース上で実行する。
　ところで、情報処理システムではサービスの可用性の向上が図られている。例えば、地震や火災といった災害が発生した場合のデータロストに備えて、複数のサイトに配置された複数ストレージシステム間でデータを多重化して保持するシステムの提案がある。
　また、メインサイトのマスタストレージ装置にマスタデータを格納し、リモートサイトのリモートストレージ装置にマスタデータのバックアップであるバックアップデータを格納するディザスタリカバリシステムの提案がある。
　また、運用系仮想サーバがハートビートを受信せず、サービスが稼働している場合には、待機系のシステムを再起動することで、スプリットブレインの問題を回避するサービス継続システムの提案がある。
　更に、アクティブノードとスタンバイノードとを含むクラスタシステムで、アクティブノードが同期データを生成して外部記憶部に記憶させるとともに、スタンバイノードの起動指示を制御装置へ送信する同期方法の提案がある。提案の同期方法では、制御装置は、起動指示を受信した場合にスタンバイノードを起動する。スタンバイノードは、外部記憶部から同期データを取得し、同期データにより示される更新内容をスタンバイノードの記憶部に反映させる。
特開２０２１－３３７８２号公報 特開２０１７－１７４１０７号公報 特開２０１９－１９７３５２号公報 国際公開第２０１７／０４７０６５号
　上記提案のように、運用系ノードで同期データが生成されるたびに待機系ノードを起動して、同期データを待機系ノードへ反映させることがある。しかし、このような同期処理のたびに待機系ノードを実行すると、その分の計算リソースが消費される。このため、ユーザが本来実行したいジョブの他に、同期処理による余計なコストが発生する。
　１つの側面では、本発明は、可用性を効率的に向上することを目的とする。
　１つの態様では、プログラムが提供される。このプログラムは、コンピュータに次の処理を実行させる。コンピュータは、複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、複数のユーザそれぞれに対応するジョブの実行に共通に用いられる共通データを配置する。コンピュータは、運用系ノードによるジョブの実行に応じて、または、第１ユーザにより更新される、第１ユーザに対応するジョブの固有データを、運用系ノードおよび待機系ノードにより共有される共有ストレージに書き込ませるとともに、運用系ノードの稼働中には待機系ノードを停止状態にする。コンピュータは、ジョブの実行主体を運用系ノードから待機系ノードに切り替える際に、待機系ノードを起動し、共有ストレージからの、待機系ノードによる固有データの読み取りを可能にする設定を行う。
　また、１つの態様では、情報処理方法が提供される。また、１つの態様では、通信部と処理部とを有する情報処理装置が提供される。
　１つの側面では、可用性を効率的に向上できる。
第１の実施の形態の情報処理装置を説明する図である。 第２の実施の形態のクラウドシステムの例を示す図である。 物理マシンのハードウェア例を示す図である。 クラウドシステムのネットワーク接続関係の例を示す図である。 クラウドシステムの機能例を示す図である。 管理テーブルの例を示す図である。 運用系／待機系マシンによる共有ストレージのマウント例を示す図である。 運用系／待機系マシンの切り替えの例を示すフローチャートである。 第３の実施の形態のマシン作成例を示す図である。 管理テーブルの例を示す図である。 サーバレス関数による管理テーブルの編集例を示す図である。 サーバレス関数によるロードバランサの制御例を示す図である。 サービスアップグレード済マシン用意の例を示すフローチャートである。 サービスアップグレード済マシン作成の例を示すフローチャートである。 管理テーブルのマシンタイプ更新の例を示すフローチャートである。 管理テーブルのマシンタイプ更新の具体例を示す図である。 サービスアップグレード制御の例を示すフローチャートである。 サービスアップグレード可否判定の例を示すフローチャートである。 フェールオーバの各処理の例を示すフローチャートである。 比較例を示す図である。
　以下、本実施の形態について図面を参照して説明する。
　［第１の実施の形態］
　第１の実施の形態を説明する。
　図１は、第１の実施の形態の情報処理装置を説明する図である。
　情報処理装置１０は、情報処理システム２０に接続される。情報処理装置１０は、情報処理システム２０に含まれてもよい。情報処理システム２０は、複数の物理マシンや複数の仮想マシンで実現される複数のノードをユーザにより利用可能にする。情報処理システム２０は、複数のユーザにより利用される。なお、情報処理装置１０はコンピュータと言われてもよい。情報処理システム２０はクラウドシステムと言われてもよい。ユーザはテナントと言われてもよい。
　情報処理システム２０に含まれるノードは、ユーザにより利用されるサービスに係るジョブを実行する。例えば、ユーザは、アクセス元ノード３０を用いて、情報処理システム２０に含まれるノードを利用する。アクセス元ノード３０は、ユーザが使用するスマートフォン、タブレットおよびＰＣ（Personal Computer）などの端末装置でもよいし、情報処理システム２０に含まれる物理マシンまたは仮想マシンでもよい。
　情報処理装置１０は、情報処理システム２０に含まれる複数のノードを制御する。情報処理装置１０は、記憶部１１と処理部１２と通信部１３を有する。記憶部１１は、ＲＡＭ（Random Access Memory）などの揮発性の半導体メモリでもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性ストレージでもよい。記憶部１１は、処理部１２の処理に用いられるデータを記憶する。
　処理部１２は、例えば、ＣＰＵ（Central Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＤＳＰ（Digital Signal Processor）などのプロセッサである。ただし、処理部１２は、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの特定用途の電子回路を含んでもよい。プロセッサは、ＲＡＭなどのメモリ（記憶部１１でもよい）に記憶されたプログラムを実行する。複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
　通信部１３は、情報処理システム２０に含まれる各ノードとの通信に用いられる通信インタフェースである。例えば、処理部１２は、通信部１３を介して各ノードと通信する。
　情報処理システム２０は、運用系ノード２１、待機系ノード２２、第１記憶部２３、第２記憶部２４、共有ストレージ２５および中継ノード２６を有する。運用系ノード２１は、複数のユーザのうちの第１ユーザのジョブを実行する運用系のノードである。待機系ノード２２は、運用系ノード２１に対応する待機系のノードである。運用系ノード２１および待機系ノード２２は、災害などの影響を考慮して、地理的に離れたデータセンタなどの拠点に設けられてもよい。
　第１記憶部２３は、運用系ノード２１によりアクセスされる、運用系ノード２１のローカルストレージである。第１記憶部２３には、運用系ノード２１に割り当てられた、ＨＤＤやＳＳＤなどの記憶領域が用いられる。第２記憶部２４は、待機系ノード２２によりアクセスされる、待機系ノード２２のローカルストレージである。第２記憶部２４には待機系ノード２２に割り当てられた、ＨＤＤやＳＳＤなどの記憶領域が用いられる。共有ストレージ２５は、運用系ノード２１および待機系ノード２２により共有されるストレージであり、運用系ノード２１および待機系ノード２２にマウント可能である。共有ストレージ２５は、ＨＤＤやＳＳＤなどの記憶装置を有し、当該記憶装置の記憶領域を運用系ノード２１や待機系ノード２２に提供する。共有ストレージ２５は、運用系ノード２１および待機系ノード２２からネットワーク経由でマウントされる。
　中継ノード２６は、アクセス元ノード３０からのアクセスを、運用系ノード２１または待機系ノード２２へ中継するノードである。運用系ノード２１でジョブ運用する場合、中継ノード２６はアクセス元ノード３０からの要求を運用系ノード２１へ転送する。待機系ノード２２でジョブ運用する場合、中継ノード２６はアクセス元ノード３０からの要求を待機系ノード２２へ転送する。
　上記のように、情報処理システム２０では、運用系ノード２１に対して待機系ノード２２を設けることで、運用系ノード２１での異常発生時などに、待機系ノード２２での運用に切り替えることができる。このとき、処理部１２は、運用系ノード２１および待機系ノード２２と通信部１３を介して通信し、運用系ノード２１および待機系ノード２２を次のように制御する。下記の制御は、例えばクラウドシステムにおけるサーバレス関数と呼ばれる軽量プログラムを、処理部１２が実行することで実現されてもよい。
　処理部１２は、第１記憶部２３および第２記憶部２４それぞれに、複数のユーザそれぞれに対応するジョブの実行に共通に用いられる共通データを配置する。共通データは、例えばジョブの定義および実行などのジョブ管理を行うジョブ管理ソフトウェアのプログラムである。各ユーザは、当該ソフトウェアの機能により自身が利用したいサービスに関する処理をジョブとして定義し、自身が利用するノードに当該ジョブを実行させることができる。
　運用系ノード２１および待機系ノード２２がそれぞれ仮想マシンで実現される場合、処理部１２は、共通データを含む仮想マシンイメージを用いて運用系ノード２１および待機系ノード２２を作成する。これにより、処理部１２は、仮想マシンイメージを基に運用系ノード２１に割り当てられる第１記憶部２３、および、仮想マシンイメージを基に待機系ノード２２に割り当てられる第２記憶部２４それぞれに共通データを配置することができる。
　処理部１２は、運用系ノード２１による、第１ユーザに対応するジョブの実行に応じて、または、第１ユーザにより更新される固有データを、運用系ノード２１により共有ストレージ２５に書き込ませる。固有データは、ジョブの実行に用いられる、ユーザ固有のデータである。第１ユーザの固有データは、例えば第１ユーザにより定義されたジョブの内容を示すジョブ定義情報、および、ジョブの実行状態や実行結果を示すジョブ状態情報の少なくとも何れかを含む。ジョブ定義情報は、実行するジョブの内容に応じて、第１ユーザにより更新される。ジョブ状態情報は、ジョブの実行状況に応じて更新される。また、処理部１２は、運用系ノード２１の稼働中には待機系ノード２２を停止状態にする。具体的には、処理部１２は、運用系ノード２１に共有ストレージ２５をマウントすることで、運用系ノード２１により固有データを共有ストレージ２５に直接書き込み可能にする。また、待機系ノード２２が仮想マシンで実現される場合、処理部１２は、仮想マシンイメージから作成した待機系ノード２２を停止させ、待機系ノード２２を起動可能な状態に維持する。
　処理部１２は、ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える際に、待機系ノード２２を起動し、共有ストレージ２５からの、待機系ノード２２による固有データの読み取りを可能にする設定を行う。具体的には、処理部１２は、待機系ノード２２に共有ストレージ２５をマウントすることで固有データを待機系ノード２２により読み取り可能にする。
　例えば、処理部１２は、運用系ノード２１におけるソフトウェアのエラーなど、運用系ノード２１でジョブ運用を継続できない異常を検知すると、ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える。このとき、処理部１２は、共有ストレージ２５を運用系ノード２１からアンマウントし、起動させた待機系ノード２２に共有ストレージ２５をマウントする。これにより、例えば共有ストレージ２５の固有データが書き込まれた所定の記憶領域が、待機系ノード２２のマウントポイントにマウントされる。すると、待機系ノード２２は、当該マウントポイントを介して、共有ストレージ２５に書き込まれた固有データを読み取ることができる。待機系ノード２２は、第２記憶部２４に記憶される共通データおよび共有ストレージ２５に記憶される固有データに基づいて、運用系ノード２１からジョブを引き継いで実行する。
　なお、処理部１２は、運用系ノード２１から待機系ノード２２への切り替えを行う場合、アクセス元ノード３０によるアクセス先を運用系ノード２１から待機系ノード２２へ切り替える設定を中継ノード２６に対して行う。例えば、処理部１２は、共有ストレージ２５を運用系ノード２１からアンマウントする前に、中継ノード２６が保持する接続先情報から運用系ノード２１の情報（例えばホスト名またはＩＰ（Internet Protocol）アドレス）を削除する。ここで、接続先情報は、中継ノード２６によるリクエストの転送先を示し、例えば、リクエストの送信元のＩＰアドレスなどの情報に対応付けて、転送先のＩＰアドレスなどの情報が登録される。そして、処理部１２は、待機系ノード２２に共有ストレージ２５をマウントした後に、中継ノード２６が保持する接続先情報に待機系ノード２２の情報（例えばホスト名またはＩＰアドレス）を追加する。これにより、運用系ノード２１で異常が発生しても、待機系ノード２２により第１ユーザへのサービスの提供が継続される。
　第１の実施の形態の情報処理装置１０によれば、運用系ノード２１によりアクセスされる第１記憶部２３および待機系ノード２２によりアクセスされる第２記憶部２４それぞれに、各ユーザのジョブの実行に共通に用いられる共通データが配置される。運用系ノード２１によるジョブの実行に応じて、または、第１ユーザにより更新される、第１ユーザに対応するジョブの固有データが共有ストレージ２５に書き込まれるとともに、運用系ノード２１の稼働中には待機系ノード２２が停止状態とされる。ジョブの実行主体を運用系ノード２１から待機系ノード２２に切り替える際に、待機系ノード２２が起動される。そして、共有ストレージ２５からの、待機系ノード２２による固有データの読み取りを可能にする設定が行われる。
　これにより、情報処理装置１０は、サービスの可用性を効率的に向上できる。具体的には次の通りである。
　運用系ノード２１と待機系ノード２２とのデータの連携は共有ストレージ２５を用いて行われる。待機系ノード２２は、運用系ノード２１が更新した固有データを共有ストレージ２５から読み取れる。このため、運用系ノード２１と待機系ノード２２とで定期的な、あるいは、データ更新毎のデータの同期処理を行わなくてよくなり、運用系ノード２１から待機系ノード２２へ切り替えるときに待機系ノード２２を起動させればよい。
　ただし、共有ストレージ２５を運用系ノード２１および待機系ノード２２からマウント可能とするなどの方法により両ノードで共有する場合、共有ストレージ２５は、運用系ノード２１および待機系ノード２２によりネットワーク経由で共有される。このため、切り替え時に共有ストレージ２５から待機系ノード２２へ比較的多量のデータを読み取らせると、当該データの読み取りに時間がかかる可能性がある。これは、切り替え完了の遅延の原因になり可用性に影響する。
　そこで、情報処理装置１０は、運用系ノード２１の第１記憶部２３および待機系ノード２２の第２記憶部２４それぞれに共通データが配置され、共有ストレージ２５には共通データ以外の固有データが書き込まれるようにする。これにより、共有ストレージ２５に共通データおよび固有データの両方を書き込むよりも、切り替え時において待機系ノード２２により共有ストレージ２５から読み取るデータ量が低減される。その結果、例えば運用系ノード２１の異常検知から待機系ノード２２によりサービスに係るジョブを再開までに要する時間が低減され、運用系ノード２１から待機系ノード２２への迅速な切り替えを行えるようになる。
　こうして、情報処理装置１０は、同期処理の都度、待機系ノード２２を起動して同期処理を行う方法に比べて、切り替え時の遅延を抑えて、当該同期処理を省略することができる。このため、情報処理装置１０は、待機系ノード２２の実行に係るコストを抑制しつつ可用性を確保できる。
　更に、共通データが共有ストレージ２５に保存されないので、共通データおよび固有データの両方を共有ストレージ２５に保存するよりも、共有ストレージ２５として割く記憶リソースを低減できるという利点もある。また、運用系ノード２１が異常により停止した場合でも、待機系ノード２２により共有ストレージ２５から最新の固有データを取得して、ジョブ運用を継続できるという利点もある。
　［第２の実施の形態］
　次に、第２の実施の形態を説明する。
　図２は、第２の実施の形態のクラウドシステムの例を示す図である。
　クラウドシステム２は、クラウドサービスを提供する。クラウドサービスの一例として、ＡＷＳ（Amazon Web Services）がある。ＡＷＳは登録商標である。Ａｍａｚｏｎは登録商標である。ただし、クラウドシステム２は、他のクラウドサービスを提供してもよい。クラウドシステム２は、物理マシン１００，１００ａ，…を有する。物理マシン１００，１００ａ，…は、ユーザに提供される計算リソースを有するサーバである。図示を省略しているが、クラウドシステム２は、更に、ネットワーク機器やストレージ装置などのハードウェアを多数含む。クラウドシステム２は、物理マシン１００，１００ａ，…、ネットワーク機器およびストレージ装置などのリソースをユーザに貸し出し、ユーザにより利用可能にする。
　クラウドシステム２は、ユーザが利用したリソースの性能、量および利用時間などに応じた料金をユーザに課する。当該料金は、クラウドシステム２の利用に伴うユーザのコストの一例である。ただし、当該コストは、消費電力や消費電力に応じた電気代などの他の指標でもよい。
　クラウドシステム２は、インターネット３に接続される。また、インターネット３には、端末装置４が接続される。端末装置４は、ユーザが操作するクライアントコンピュータである。ユーザは端末装置４を操作して、クラウドシステム２のサービスを利用することができる。ここで、クラウドシステム２を利用するユーザまたはユーザのグループを、以下ではテナントと言う。
　図３は、物理マシンのハードウェア例を示す図である。
　物理マシン１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、ＧＰＵ１０４、入力インタフェース１０５、媒体リーダ１０６および通信インタフェース１０７を有する。物理マシン１００が有するこれらのユニットは、物理マシン１００の内部でバスに接続されている。プロセッサ１０１は、第１の実施の形態の処理部１２に対応する。ＲＡＭ１０２またはＨＤＤ１０３は、第１の実施の形態の記憶部１１に対応する。通信インタフェース１０７は、第１の実施の形態の通信部１３に対応する。
　プロセッサ１０１は、プログラムの命令を実行する演算装置である。プロセッサ１０１は、例えばＣＰＵである。プロセッサ１０１は、ＨＤＤ１０３に記憶されたプログラムやデータの少なくとも一部をＲＡＭ１０２にロードし、プログラムを実行する。なお、プロセッサ１０１は複数のプロセッサコアを含んでもよい。また、物理マシン１００は複数のプロセッサを有してもよい。以下で説明する処理は複数のプロセッサまたはプロセッサコアを用いて並列に実行されてもよい。また、複数のプロセッサの集合を「マルチプロセッサ」または単に「プロセッサ」と言うことがある。
　ＲＡＭ１０２は、プロセッサ１０１が実行するプログラムやプロセッサ１０１が演算に用いるデータを一時的に記憶する揮発性の半導体メモリである。なお、物理マシン１００は、ＲＡＭ以外の種類のメモリを備えてもよく、複数個のメモリを備えてもよい。
　ＨＤＤ１０３は、ＯＳ（Operating System）やミドルウェアやアプリケーションソフトウェアなどのソフトウェアのプログラム、および、データを記憶する不揮発性の記憶装置である。なお、物理マシン１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の記憶装置を備えてもよく、複数の不揮発性の記憶装置を備えてもよい。
　ＧＰＵ１０４は、プロセッサ１０１からの命令に従って、物理マシン１００に接続されたディスプレイ１１１に画像を出力する。ディスプレイ１１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）、プラズマディスプレイ、有機ＥＬ（ＯＥＬ：Organic Electro-Luminescence）ディスプレイなど、任意の種類のディスプレイを用いることができる。
　入力インタフェース１０５は、物理マシン１００に接続された入力デバイス１１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１１２としては、マウス、タッチパネル、タッチパッド、トラックボールなどのポインティングデバイス、キーボード、リモートコントローラ、ボタンスイッチなどを用いることができる。また、物理マシン１００に、複数の種類の入力デバイスが接続されていてもよい。
　媒体リーダ１０６は、記録媒体１１３に記録されたプログラムやデータを読み取る読み取り装置である。記録媒体１１３として、例えば、磁気ディスク、光ディスク、光磁気ディスク（ＭＯ：Magneto-Optical disk）、半導体メモリなどを使用できる。磁気ディスクには、フレキシブルディスク（ＦＤ：Flexible Disk）やＨＤＤが含まれる。光ディスクには、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）が含まれる。
　媒体リーダ１０６は、例えば、記録媒体１１３から読み取ったプログラムやデータを、ＲＡＭ１０２やＨＤＤ１０３などの他の記録媒体にコピーする。読み取られたプログラムは、例えば、プロセッサ１０１によって実行される。なお、記録媒体１１３は可搬型記録媒体であってもよく、プログラムやデータの配布に用いられることがある。また、記録媒体１１３やＨＤＤ１０３を、コンピュータ読み取り可能な記録媒体と言うことがある。
　通信インタフェース１０７は、ネットワーク１１４に接続され、ネットワーク１１４を介して他の情報処理装置と通信する。通信インタフェース１０７は、スイッチやルータなどの有線通信装置に接続される有線通信インタフェースでもよいし、基地局やアクセスポイントなどの無線通信装置に接続される無線通信インタフェースでもよい。なお、ネットワーク１１４は、クラウドシステム２の内部ネットワークである。
　物理マシン１００ａを含む、クラウドシステム２の他の物理マシンや、端末装置４も物理マシン１００と同様のハードウェアにより実現される。
　図４は、クラウドシステムのネットワーク接続関係の例を示す図である。
　クラウドシステム２は、リージョン２ａ、仮想プライベートクラウド（ＶＰＣ：Virtual Private Cloud）２ｂおよびアベイラビリティゾーン（ＡＺ：Availability Zone）２ｃ１，２ｃ２を有する。
　リージョン２ａは、複数のデータセンタを有する地域である。ＶＰＣ２ｂは、リージョン２ａ内において、クラウドシステム２に構築された、テナントの仮想ネットワークである。ＶＰＣはテナントごとに論理的に分離される。すなわち、複数のテナントに対して複数のＶＰＣが存在し得る。ＡＺ２ｃ１，２ｃ２は、それぞれリージョン２ａ内に立地する１以上のデータセンタの集合である。図示を省略しているが、ＡＺ２ｃ１，２ｃ２は、テナントが利用するネットワークの管理単位であるサブネットを含む。
　クラウドシステム２は、監視ノード４０、サーバレス関数実行ノード５０、マシンイメージ管理ノード６０、管理ＤＢ（DataBase）７０、インターネットゲートウェイ８０およびロードバランサ９０を有する。
　監視ノード４０は、テナントが利用する仮想マシンを監視することでイベントを検知し、当該イベントに応じてサーバレス関数実行ノード５０によるサーバレス関数の実行を指示する。
　サーバレス関数実行ノード５０は、サーバレス関数を実行する。サーバレス関数による処理には、テナントの仮想マシンの起動および停止などやロードバランサ９０の設定変更などの制御がある。制御内容ごとに異なるサーバレス関数が予め用意され、実行する制御内容に応じたサーバレス関数が実行されてもよい。
　マシンイメージ管理ノード６０は、テナントが利用する仮想マシンのマシンイメージを管理する。マシンイメージは、仮想マシンの起動に用いられるデータである。
　監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、例えばクラウドシステム２におけるリージョン２ａと同位のネットワークに配置される。リージョン２ａのネットワークは、ＶＰＣ２ｂのネットワークと接続される。監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、リージョン２ａのネットワークを介して、ＶＰＣ２ｂ内のノードと通信し得る。
　管理ＤＢ７０は、監視ノード４０やサーバレス関数実行ノード５０の処理に用いられるデータを記憶する。管理ＤＢ７０は、リージョン２ａのネットワークに配置される。
　インターネットゲートウェイ８０は、インターネット３に接続され、インターネット３とＶＰＣ２ｂ内のノードとの通信を中継するノードである。インターネットゲートウェイ８０は、リージョン２ａに設けられる。
　ロードバランサ９０は、インターネットゲートウェイ８０とＡＺ２ｃ１，２ｃ２内の仮想マシンとの間の通信を中継するノードである。ロードバランサ９０は、端末装置４により送信されるテナントのリクエストを、インターネットゲートウェイ８０を介して受信し、ＡＺ２ｃ１，２ｃ２内の仮想マシンへ振り分ける制御を行う。ロードバランサ９０は、ＶＰＣ２ｂに設けられる。
　ＡＺ２ｃ１は、運用系マシン２００とストレージ２０１とを有する。運用系マシン２００は、ＶＰＣ２ｂに対応するテナントにより利用される運用系の仮想マシンであり、当該テナントが利用するサービスに係るジョブを実行する。ストレージ２０１は、運用系マシン２００のローカルストレージである。
　ＡＺ２ｃ２は、待機系マシン３００とストレージ３０１とを有する。待機系マシン３００は、運用系マシン２００に対応する待機系の仮想マシンである。待機系マシン３００は、ＶＰＣ２ｂに対応するテナントにより利用される。待機系マシン３００は、運用系マシン２００の稼働時には停止状態とされる。待機系マシン３００が停止されていれば、待機系マシン３００の分の計算リソースは使用されないため、テナントへの課金は生じない。待機系マシン３００は、運用系マシン２００の異常時に起動され、運用系マシン２００のジョブを引き継いで実行する。ストレージ３０１は、待機系マシン３００のローカルストレージである。ここで、運用系マシン２００での運用を待機系マシン３００に切り替える制御は、フェールオーバと言われる。後述されるように、フェールオーバは、マシンアップグレードの際にも用いられる。
　ＶＰＣ２ｂには、運用系マシン２００および待機系マシン３００からＶＰＣ２ｂ内のネットワークを介してアクセス可能な共有ストレージ４００が設けられる。共有ストレージ４００は、運用系マシン２００および待機系マシン３００からマウント可能である。共有ストレージ４００には、運用系マシン２００から待機系マシン３００への切り替えの際に、待機系マシン３００へ引き継ぐデータが格納される。
　ここで、監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、物理マシン１００，１００ａ，…に含まれる物理マシンにより実現される。監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、当該物理マシンのハードウェアリソースを用いて実行される仮想マシンにより実現されてもよい。監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０は、１つの物理マシンによって実現されてもよいし、異なる物理マシンによって実現されてもよい。インターネットゲートウェイ８０やロードバランサ９０は、クラウドシステム２に含まれる通信装置や当該物理マシン、あるいは、当該物理マシン上の仮想マシンにより実現される。
　運用系マシン２００および待機系マシン３００は、物理マシン１００，１００ａ，…に含まれる物理マシンのハードウェアリソースを用いて実行される仮想マシンである。ストレージ２０１は運用系マシン２００に割り当てられる物理マシンのＨＤＤやＳＳＤなどの記憶領域により実現される。ストレージ３０１は待機系マシン３００に割り当てられる物理マシンのＨＤＤやＳＳＤなどの記憶領域により実現される。管理ＤＢ７０は、リージョン２ａに含まれる物理マシンやＨＤＤやＳＳＤなどを有するストレージ装置により実現される。
　共有ストレージ４００は、運用系マシン２００および待機系マシン３００によりＶＰＣ２ｂのネットワーク経由でアクセス可能なストレージ装置により実現される。当該ストレージ装置は、ＨＤＤやＳＳＤなどを有する。例えば、当該ストレージ装置の記憶領域の一部が、共有ストレージ４００として、ＶＰＣ２ｂに対応するテナントに割り当てられる。
　図５は、クラウドシステムの機能例を示す図である。
　クラウドシステム２は、監視部４１およびサーバレス関数５１を有する。監視部４１は、監視ノード４０のプロセッサが監視ノード４０のＲＡＭに記憶されたプログラムを実行することで実現される。サーバレス関数５１は、サーバレス関数実行ノード５０のプロセッサがサーバレス関数実行ノード５０のＲＡＭに記憶された軽量プログラムを実行することで実現される。
　監視部４１は、運用系マシン２００を監視し、運用系マシン２００の異常を検知すると、サーバレス関数実行ノード５０によりサーバレス関数５１を起動させる。監視部４１は、サーバレス関数５１によりフェールオーバが行われると、新たにジョブの実行主体（新運用系）となった待機系マシン３００の監視を行う。
　サーバレス関数５１は、フェールオーバを行う。フェールオーバの際、サーバレス関数５１は、運用系マシン２００からの共有ストレージ４００のアンマウント、待機系マシン３００の起動、待機系マシン３００への共有ストレージのマウント、ロードバランサ９０によるリクエストの振り分け先の変更を行う。なお、サーバレス関数５１のこれらの処理は、複数のサーバレス関数により分担して行われてもよい。
　ここで、ストレージ２０１およびストレージ３０１には、運用系マシン２００および待機系マシン３００で実行されるジョブに係るテナント共通データが格納される。テナント共通データは、複数のテナントそれぞれのジョブの実行に共通に用いられるデータであり、各テナントのジョブを実行するための基盤のソフトウェアのプログラムである。各テナントは、当該ソフトウェアの機能により自身が利用したいサービスに関する処理をジョブとして定義し、自身が利用するノードに当該ジョブを実行させることができる。
　また、共有ストレージ４００には、運用系マシン２００のジョブの実行などに応じて更新される、テナント固有データが格納される。テナント固有データは、ジョブの状態（ジョブ状態）や定義（ジョブ定義）を示す情報である。ジョブ定義は、ジョブの処理内容やジョブの実行スケジュールを含み得る。ジョブ定義は、テナントが実行したいジョブの内容に応じて、当該テナントによって更新される。ジョブ状態は、これまでのジョブの実行結果を含み得る。ジョブ状態は、運用系マシン２００によるジョブの実行に応じて更新される。
　テナント共通データを共有ストレージ４００に配置しないことで、共有ストレージ４００として使用される記憶容量を節約できる。共有ストレージ４００は、利用料が比較的安価な標準ストレージと、標準ストレージよりも利用料が高い高速ストレージを含むことがある。その場合、例えば、テナント固有データのうち、比較的更新頻度の少ないジョブ定義のデータを標準ストレージに保存し、比較的更新頻度の多いジョブ状態のデータを高速ストレージに保存するようにしてもよい。これにより、運用への影響を抑えながら、テナントによる共有ストレージ４００の利用コストが低減される。
　また、管理ＤＢ７０は、フェールオーバの制御に用いられる管理テーブル７１を記憶する。管理テーブル７１は、運用系マシン２００および待機系マシン３００を含む、テナントごとの運用系／待機系マシンの稼働状態やマシンイメージの管理に用いられる。
　図６は、管理テーブルの例を示す図である。
　管理テーブル７１は、テナントＩＤ（IDentifier）、テナントステータス、マシンＩＤ、マシンタイプおよびイメージＩＤの項目を含む。テナントＩＤの項目には、テナントＩＤが登録される。テナントＩＤはテナントの識別情報である。
　テナントステータスの項目には、テナントステータスが登録される。テナントステータスは、テナントに対するサービスアップグレードの状態を示す。テナントステータスには「ｎｏｒｍａｌ」または「ｐａｔｃｈ」が設定される。テナントステータス「ｎｏｒｍａｌ」は通常運用している状態を示す。テナントステータス「ｐａｔｃｈ」は、後述されるサービスアップグレード済マシンを用意済の状態を示す。
　マシンＩＤの項目には、マシンＩＤが登録される。マシンＩＤは、仮想マシンの識別情報である。
　マシンタイプの項目には、マシンタイプが登録される。マシンタイプは、仮想マシンの種類を示す。マシンタイプ、すなわち、仮想マシンの種類には次の６種類がある。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」は、運用系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ」は、待機系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」は、サービスアップグレード済の待機系マシンを示す。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」は、サービスアップグレード済の運用系マシンを示す。マシンタイプ「ｓｔａｎｄｂｙ＿ｏｌｄ」は、フェールオーバによる切り替え直前の待機系マシン、すなわち、旧待機系マシンを示す。マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」は、フェールオーバによる切り替え直前の運用系マシン、すなわち、旧運用系マシンを示す。
　イメージＩＤは、マシンＩＤに対応する仮想マシンの作成元のマシンイメージの識別情報である。イメージＩＤは、マシンイメージのデータ本体の取得に用いられる。
　例えば、管理テーブル７１は、テナントＩＤ「１」に対してテナントステータス「ｎｏｒｍａｌ」を保持する。また、管理テーブル７１は、マシンＩＤ「１」に対して、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」、イメージＩＤ「ｉｍａｇｅＸＸＸ１」のレコードを有する。当該レコードは、運用系マシン２００を示すデータである。また、管理テーブル７１は、テナントＩＤ「１」に対して、マシンＩＤ「２」、マシンタイプ「ｓｔａｎｄｂｙ」、イメージＩＤ「ｉｍａｇｅＸＸＸ１」のレコードを有する。このレコードは、待機系マシン３００を示すデータである。
　管理テーブル７１には、他のテナントが利用する仮想マシンのレコードも同様に登録され得る。
　図７は、運用系／待機系マシンによる共有ストレージのマウント例を示す図である。
　運用系マシン２００が稼働中の場合、待機系マシン３００は停止される。この場合、共有ストレージ４００は、運用系マシン２００にマウントされる。待機系マシン３００が停止中の場合、共有ストレージ４００は、待機系マシン３００にはマウントされていない状態、すなわち、待機系マシン３００に対してはアンマウントの状態となる。運用系マシン２００は、ジョブ定義およびジョブ状態をテナント固有データとして共有ストレージ４００に書き込む。運用系マシン２００は、テナントによるジョブ定義の変更の入力に応じて、共有ストレージ４００のテナント固有データに含まれるジョブ定義を更新する。また、運用系マシン２００は、ジョブの実行に応じて、共有ストレージ４００のテナント固有データに含まれるジョブ状態を更新する。
　運用系マシン２００から待機系マシン３００への切り替えが行われる場合、共有ストレージ４００は運用系マシン２００からアンマウントされる。そして、待機系マシン３００が起動され、共有ストレージ４００は待機系マシン３００にマウントされる。すると、待機系マシン３００は、共有ストレージ４００から、運用系マシン２００により書き込まれた最新のテナント固有データを読み取り可能になる。待機系マシン３００は、ストレージ３０１に記憶されるテナント共通データおよび共有ストレージ４００に記憶されるテナント固有データに基づいて、運用系マシン２００からジョブを引き継いで実行する。
　次に、運用系マシン２００から待機系マシン３００への切り替えの処理手順を説明する。以下では、テナントＩＤ「１」のテナントに関する手順を説明するが、他のテナントに対しても同様の手順となる。
　図８は、運用系／待機系マシンの切り替えの例を示すフローチャートである。
　（Ｓ１０）監視部４１は、運用系マシン２００における、ジョブの実行に係るサービスの異常を検知する。監視部４１は、サーバレス関数実行ノード５０にサーバレス関数５１の実行を指示する。すると、サーバレス関数５１が起動され、下記の処理が実行される。
　（Ｓ１１）サーバレス関数５１は、管理テーブル７１から、運用系マシン２００に対応するテナントＩＤとマシンタイプ「ｓｔａｎｄｂｙ」のマシンのマシンＩＤとを取得する。ここで、図中、マシンタイプ「ｓｔａｎｄｂｙ」を、「ｔｙｐｅ：ｓｔａｎｄｂｙ」のように略記することがある。
　（Ｓ１２）サーバレス関数５１は、ロードバランサ９０の接続先を削除する。具体的には、サーバレス関数５１は、ロードバランサ９０によるリクエストの転送先から、運用系マシン２００を削除する。
　（Ｓ１３）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤのマシン、すなわち、運用系マシン２００の該当のサービスを停止させる。
　（Ｓ１４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤのマシン、すなわち、運用系マシン２００の共有ストレージ４００をアンマウントする。
　（Ｓ１５）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシンＩＤのマシン、すなわち、待機系マシン３００を起動させる。
　（Ｓ１６）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシンＩＤのマシン、すなわち、待機系マシン３００に、共有ストレージ４００をマウントする。
　（Ｓ１７）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシンＩＤのマシン、すなわち、待機系マシン３００の該当のサービスを起動させる。
　（Ｓ１８）サーバレス関数５１は、ロードバランサ９０の接続先に待機系マシン３００を追加する。これにより、テナントのリクエストがロードバランサ９０によって待機系マシン３００へ振り分けられるようになる。
　（Ｓ１９）サーバレス関数５１は、管理テーブル７１を更新する。具体的には、サーバレス関数５１は、待機系マシン３００のマシンタイプを「ｐｒｏｄｕｃｔｉｏｎ」に変更する。また、サーバレス関数５１は、運用系マシン２００を停止させ、運用系マシン２００のマシンタイプを「ｓｔａｎｄｂｙ」に変更する。そして、運用系マシン２００から待機系マシン３００への切り替えが終了する。
　第２の実施の形態のクラウドシステム２では、サーバレス関数５１の制御により、運用系マシン２００と待機系マシン３００とのデータの連携は共有ストレージ４００を用いて行われる。待機系マシン３００は、運用系マシン２００が更新した固有データを共有ストレージ４００から直接読み取れる。このため、運用系マシン２００と待機系マシン３００とで定期的なデータの同期処理を行わなくてよくなり、運用系マシン２００から待機系マシン３００へ切り替えるときに待機系マシン３００を起動させればよい。
　ただし、共有ストレージ４００は、運用系マシン２００および待機系マシン３００によりネットワーク経由で共有される。このため、切り替え時に共有ストレージ４００から待機系マシン３００へ比較的多量のデータを読み取らせると、当該データの読み取りに時間がかかる可能性がある。これは、切り替え完了の遅延の原因になり可用性に影響する。
　そこで、サーバレス関数５１は、運用系マシン２００のストレージ２０１および待機系マシン３００のストレージ３０１それぞれにテナント共通データを配置し、共有ストレージ４００にはテナント固有データが書き込まれるようにする。これにより、共有ストレージ４００にテナント共通データおよびテナント固有データの両方を書き込むよりも、切り替え時において待機系マシン３００により共有ストレージ４００から読み取るデータ量が低減される。その結果、運用系マシン２００の異常検知から待機系マシン３００によりサービスに係るジョブを再開までに要する時間が低減され、運用系マシン２００から待機系マシン３００への迅速な切り替えを行えるようになる。
　こうして、同期処理の都度、待機系マシン３００を起動して同期処理を行わずに済み、待機系マシン３００の実行に係る余計なコストを削減するとともに、待機系マシン３００への切り替えを高速化できる。すなわち、運用系マシン２００により提供されるサービスの可用性が効率的に向上される。
　更に、テナント共通データが共有ストレージ４００に保存されないので、テナント共通データおよびテナント固有データの両方を共有ストレージ４００に保存するよりも、共有ストレージ４００として割く記憶リソースを低減できるという利点もある。また、運用系マシン２００が異常により停止した場合でも、待機系マシン３００により共有ストレージ４００から最新のテナント固有データを取得して、ジョブ運用を継続できる利点もある。
　［第３の実施の形態］
　次に、第３の実施の形態を説明する。前述の第２の実施の形態と相違する事項を主に説明し、共通する事項の説明を省略する。
　第３の実施の形態では、第２の実施の形態で例示したフェールオーバの処理を、運用系マシン２００により提供されるサービスのアップグレード時に利用する例を説明する。第３の実施の形態のクラウドシステム２のハードウェアや機能は、図２～図５で例示したハードウェアや機能と同様であるため説明を省略する。
　図９は、第３の実施の形態のマシン作成例を示す図である。
　ＡＺ２ｃ１は、運用系マシン２００およびストレージ２０１に加えて、サービスアップグレード済マシン２００ａを有する。サービスアップグレード済マシン２００ａは、運用系マシン２００が提供するサービスの、アップグレード後のプログラムがインストールされた仮想マシンである。サービスアップグレード済マシン２００ａは、マシンイメージ６１を用いて作成される。マシンイメージ６１は、当該アップグレード後のプログラムがインストールされた仮想マシンのイメージデータである。図示を省略しているが、サービスアップグレード済マシン２００ａもローカルストレージを有し、当該ローカルストレージにアップグレード後のプログラムがテナント共通データとして格納される。
　ＡＺ２ｃ２は、待機系マシン３００およびストレージ３０１に加えて、サービスアップグレード済マシン３００ａを有する。サービスアップグレード済マシン３００ａは、運用系マシン２００が提供するサービスの、アップグレード後のプログラムがインストールされた仮想マシンである。サービスアップグレード済マシン３００ａも、マシンイメージ６１を用いて作成される。図示を省略しているが、サービスアップグレード済マシン３００ａもローカルストレージを有し、当該ローカルストレージにアップグレード後のプログラムがテナント共通データとして格納される。
　例えば、サービスアップグレード済マシン２００ａは、新たな待機系（新待機系）として用いられる。また、サービスアップグレード済マシン３００ａは、新たな運用系（新運用系）として用いられる。
　なお、マシンイメージ６１は、アップグレード後のプログラムであるテナント共通データを含むがテナント固有データを含まない。このため、マシンイメージ６１は、複数のテナントに対して使い回すことができる。よって、マシンイメージ６１をテナントごとに作成しなくてよいため、サービスアップグレード済の仮想マシンの配備を効率化できる。
　サービスアップグレード済マシン２００ａ，３００ａは、マシンイメージ６１から作成されて起動された直後に停止されて起動可能な状態のまま維持される。サーバレス関数５１は、サービスアップグレード済マシン２００ａ，３００ａを次のように管理する。
　図１０は、管理テーブルの例を示す図である。
　管理テーブル７１ａは、サービスアップグレード済マシン２００ａ，３００ａの情報が管理テーブル７１に追加された場合を例示する。管理テーブル７１ａに含まれる項目は、管理テーブル７１に含まれる項目と同様である。
　例えば、管理テーブル７１ａは、テナントＩＤ「１」に対して、テナントステータス「ｐａｔｃｈ」を保持する。テナントステータス「ｐａｔｃｈ」は、前述のように、サービスアップグレード済マシン２００ａ，３００ａを用意済の状態を示す。また、管理テーブル７１ａは、テナントＩＤ「１」に対して、マシンＩＤ「３」、マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」、イメージＩＤ「ｉｍａｇｅＸＸＸ２」のレコードを保持する。当該レコードは、サービスアップグレード済マシン２００ａを示すデータである。また、管理テーブル７１ａは、テナントＩＤ「１」に対して、マシンＩＤ「４」、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」、イメージＩＤ「ｉｍａｇｅＸＸＸ２」のレコードを保持する。当該レコードは、サービスアップグレード済マシン３００ａを示すデータである。ここで、イメージＩＤ「ｉｍａｇｅＸＸＸ２」は、マシンイメージ６１を示す。
　なお、管理テーブル７１ａでは、テナントＩＤ「２」のテナントの仮想マシンに関するデータが登録される例も示されている。
　図１１は、サーバレス関数による管理テーブルの編集例を示す図である。
　サーバレス関数５１は、マシンイメージ６１からサービスアップグレード済マシン２００ａ，３００ａが作成されると、サービスアップグレード済マシン２００ａ，３００ａの情報を管理テーブル７１ａに登録する。
　サービスアップグレード済マシン２００ａ，３００ａの作成は、運用系マシン２００を起動状態として、運用系マシン２００を稼働させたまま行われる。サービスアップグレード済マシン２００ａ，３００ａは、何れも作成後に停止状態とされる。このようにして、サーバレス関数５１は、ＡＺ２ｃ１，２ｃ２にそれぞれサービスアップグレード済マシン２００ａ，３００ａを用意する。
　図１２は、サーバレス関数によるロードバランサの制御例を示す図である。
　サーバレス関数５１は、運用系マシン２００によるジョブ実行が行われない時間帯に、ジョブの実行主体を現在の運用系マシン２００からサービスアップグレード済マシン３００ａ（新運用系）に切り替える。具体的には、サーバレス関数５１は、管理テーブル７１ａに基づいて、運用系マシン２００から共有ストレージ４００をアンマウントし、運用系マシン２００を停止させる。次に、サーバレス関数５１は、サービスアップグレード済マシン３００ａを起動させ、共有ストレージ４００をサービスアップグレード済マシン３００ａにマウントする。
　そして、サーバレス関数５１は、管理テーブル７１ａに基づいて、テナントのリクエストの転送先を、運用系マシン２００からサービスアップグレード済マシン３００ａに切り替える設定を、ロードバランサ９０に対して行う。例えば、サーバレス関数５１は、ロードバランサ９０が保持する運用系マシン接続先情報における運用系マシン２００のホスト名またはＩＰアドレスを、サービスアップグレード済マシン３００ａのホスト名またはＩＰアドレスに書き換える。また、ロードバランサ９０が待機系マシン接続先情報を有する場合、待機系マシン接続先情報における待機系マシン３００のホスト名またはＩＰアドレスを、サービスアップグレード済マシン２００ａのホスト名またはＩＰアドレスに書き換えてもよい。
　このようにして、サーバレス関数５１により、運用系マシン２００での運用からサービスアップグレード済マシン３００ａでの運用への切り替えが行われる。
　次に、運用系マシン２００からサービスアップグレード済マシン３００ａへの切り替えの処理手順を説明する。以下では、テナントＩＤ「１」のテナントに関する手順を説明するが、他のテナントに対しても同様の手順となる。
　図１３は、サービスアップグレード済マシン用意の例を示すフローチャートである。
　下記の手順は、マシンイメージ６１からの仮想マシンの作成指示が監視部４１に入力されると、監視部４１によりサーバレス関数５１が起動されて実行される。当該仮想マシンの作成指示は、マシンイメージ管理ノード６０に入力されてもよく、マシンイメージ管理ノード６０によりサーバレス関数５１が起動されて、下記の手順が実行されてもよい。
　（Ｓ２０）サーバレス関数５１は、サービスアップグレード済マシン作成を行う。サービスアップグレード済マシン作成の詳細は後述される。サービスアップグレード済マシン作成は、運用系マシン２００によるジョブ運用中に実行される。
　（Ｓ２１）サーバレス関数５１は、管理テーブルのマシンタイプ更新を行う。マシンタイプ更新の詳細は後述される。
　（Ｓ２２）サーバレス関数５１は、管理テーブルのテナントステータス更新を行う。例えば、サーバレス関数５１は、テナントＩＤ「１」に対応するテナントステータスを「ｎｏｒｍａｌ」から「ｐａｔｃｈ」に更新する。そして、サービスアップグレード済マシン用意が終了する。
　図１０の管理テーブル７１ａは、ステップＳ２２のテナントステータスの更新が、ステップＳ２１のマシンタイプ更新の前に行われる場合の、当該マシンタイプ更新の直前の段階の管理テーブルを例示している。
　図１４は、サービスアップグレード済マシン作成の例を示すフローチャートである。
　サービスアップグレード済マシン作成は、ステップＳ２０に相当する。
　（Ｓ３０）サーバレス関数５１は、管理テーブル７１から、テナントＩＤ「１」に対応するマシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」、「ｓｔａｎｄｂｙ」のマシン、すなわち、運用系マシン２００、待機系マシン３００の情報を取得する。
　（Ｓ３１）サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」のマシン、すなわち、待機系マシン３００が存在するサブネットを取得する。
　（Ｓ３２）サーバレス関数５１は、ステップＳ３１で取得したサブネットに、サービスアップグレード済のマシンイメージ６１から、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」のマシン、すなわち、サービスアップグレード済マシン３００ａを作成する。ここで、サーバレス関数５１は、例えば現在の運用系マシン２００が存在するＡＺ２ｃ１とは異なるＡＺ２ｃ２に、サービスアップグレード済マシン３００ａを作成する。
　（Ｓ３３）サーバレス関数５１は、ステップＳ３２の作成によりサービスアップグレード済マシン３００ａ（マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」のマシン）が起動するため、サービスアップグレード済マシン３００ａを停止させる。
　（Ｓ３４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」のマシン、すなわち、運用系マシン２００が存在するサブネットを取得する。
　（Ｓ３５）サーバレス関数５１は、ステップＳ３４で取得したサブネットに、サービスアップグレード済のマシンイメージ６１から、マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」のマシン、すなわち、サービスアップグレード済マシン２００ａを作成する。ここで、サーバレス関数５１は、例えば、新運用系となるサービスアップグレード済マシン３００ａが存在するＡＺ２ｃ２とは異なるＡＺ２ｃ１に、サービスアップグレード済マシン２００ａを作成する。
　（Ｓ３６）サーバレス関数５１は、ステップＳ３５において作成したサービスアップグレード済マシン２００ａ（マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」のマシン）が起動するため、サービスアップグレード済マシン２００ａを停止させる。
　（Ｓ３７）サーバレス関数５１は、サービスアップグレード済マシン２００ａ，３００ａの情報を管理テーブル７１に追加する。そして、サービスアップグレード済マシン作成が終了する。
　図１５は、管理テーブルのマシンタイプ更新の例を示すフローチャートである。
　管理テーブルのマシンタイプ更新は、ステップＳ２１に相当する。
　（Ｓ４０）サーバレス関数５１は、テナントＩＤ「１」に対応する各マシンのマシンタイプを取得する。
　（Ｓ４１）サーバレス関数５１は、ステップＳ３７の更新後の管理テーブルに含まれるテナント「１」の各仮想マシンのマシンタイプを次のように更新する。サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ」を「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」に更新する。サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ＿ｎｅｗ」を「ｓｔａｎｄｂｙ」に更新する。サーバレス関数５１は、マシンタイプ「ｓｔａｎｄｂｙ」を「ｓｔａｎｄｂｙ＿ｏｌｄ」に更新する。サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｎｅｗ」を「ｐｒｏｄｕｃｔｉｏｎ」に更新する。そして、管理テーブルのマシンタイプ更新が終了する。
　図１６は、管理テーブルのマシンタイプ更新の具体例を示す図である。
　サーバレス関数５１は、ステップＳ３７で管理テーブル７１を管理テーブル７１ｂに更新する。サーバレス関数５１は、図１５で例示した手順により、管理テーブル７１ｂを管理テーブル７１ｃに更新する。管理テーブル７１ｃは、ステップＳ４１における更新後の管理テーブルを示す。その後、サーバレス関数５１は、ステップＳ２２を実行することで、管理テーブル７１ｃのテナントステータス「ｎｏｒｍａｌ」を「ｐａｔｃｈ」に更新する。管理テーブル７１ｄは、管理テーブル７１ｃのテナントステータス「ｎｏｒｍａｌ」を「ｐａｔｃｈ」に更新した状態を示す。
　図１７は、サービスアップグレード制御の例を示すフローチャートである。
　下記の手順の実行主体をサーバレス関数５１として記載するが、下記の手順はサービスアップグレード済マシン用意を実行するサーバレス関数５１とは異なるサーバレス関数により実行されてもよい。例えば、サーバレス関数５１は所定の常駐プロセスにより定期的に起動されて、下記の手順を実行する。当該常駐プロセスは、例えば監視ノード４０で実行されてもよいし、サーバレス関数実行ノード５０で実行されてもよい。
　（Ｓ５０）サーバレス関数５１は、管理テーブル７１ｃから、該当のテナントのテナントステータスを取得する。なお、一例として、テナントＩＤ「１」のテナントに対する手順を示すが、他のテナントに対しても同様の手順となる。
　（Ｓ５１）サーバレス関数５１は、テナントステータスが「ｐａｔｃｈ」であるか否かを判定する。テナントステータスが「ｐａｔｃｈ」の場合、ステップＳ５３に処理が進む。テナントステータスが「ｐａｔｃｈ」ではない場合、すなわち、テナントステータスが「ｎｏｒｍａｌ」の場合、ステップＳ５２に処理が進む。
　（Ｓ５２）サーバレス関数５１は、一定時間待機する。なお、ステップＳ５２では、常駐プロセスが一定時間待機し、一定時間経過後にサーバレス関数５１を起動するようにしてもよい。そして、ステップＳ５０に処理が進む。
　（Ｓ５３）サーバレス関数５１は、サービスアップグレード可否判定を行う。サービスアップグレード可否判定の詳細は後述される。サーバレス関数５１は、サービスアップグレード可否判定において、サービスアップグレードが可能と判定されると、ステップＳ５４に処理を進める。
　（Ｓ５４）サーバレス関数５１は、ロードバランサ９０の接続先を削除する。具体的には、サーバレス関数５１は、ロードバランサ９０の接続先から、該当のテナントの運用系マシン２００の情報を削除する。
　（Ｓ５５）サーバレス関数５１は、フェールオーバの各処理を実行する。フェールオーバの各処理の詳細は後述される。フェールオーバの各処理により、管理テーブル７１ｃが更新され、ロードバランサ９０の接続先に新運用系の仮想マシンを追加する準備が整う。
　（Ｓ５６）サーバレス関数５１は、ロードバランサ９０の接続先に新運用系を追加する。具体的には、サーバレス関数５１は、新運用系の仮想マシンである、サービスアップグレード済マシン３００ａの情報を、ロードバランサ９０の接続先に追加する。
　（Ｓ５７）サーバレス関数５１は、該当のテナントについて、管理テーブルのテナントステータスを「ｎｏｒｍａｌ」に更新する。そして、ステップＳ５０に処理が進む。次のステップＳ５０以降の手順では、次のテナントに対するサービスアップグレード制御が行われる。
　図１８は、サービスアップグレード可否判定の例を示すフローチャートである。
　サービスアップグレード可否判定は、ステップＳ５３に相当する。
　（Ｓ６０）サーバレス関数５１は、該当のテナントのジョブの実行状態を取得する。例えば、サーバレス関数５１は、運用系マシン２００からジョブの実行状態を取得してもよい。例えば、運用系マシン２００は、共有ストレージ４００に格納されているジョブ実行状態の情報を取得し、サーバレス関数５１に提供してもよい。
　（Ｓ６１）サーバレス関数５１は、当該ジョブのスケジュールを取得する。例えば、サーバレス関数５１は、運用系マシン２００からジョブのスケジュールを取得してもよい。例えば、運用系マシン２００は、共有ストレージ４００に格納されているジョブ定義の情報を取得し、ジョブ定義の情報に含まれるスケジュールの情報をサーバレス関数５１に提供してもよい。
　（Ｓ６２）サーバレス関数５１は、ステップＳ６０，Ｓ６１で取得したジョブ実行状態およびジョブのスケジュールに基づいて、現在、サービスアップグレードが可能であるか否かを判定する。現在、サービスアップグレードが可能な場合、サービスアップグレード可否判定が終了する。現在、サービスアップグレードが不可能な場合、ステップＳ６３に処理が進む。例えば、サーバレス関数５１は、運用系マシン２００でジョブを実行中の場合またはジョブの実行開始までの時刻が所定時間内に迫っている場合に、現在、サービスアップグレードが不可能であると判定してもよい。一方、サーバレス関数５１は、運用系マシン２００でジョブを実行中でなく、かつ、ジョブの実行開始までの時刻が現時点から所定時間よりも後である場合に、現在、サービスアップグレードが可能と判定してもよい。なお、ステップＳ６２の判定に用いられる所定時間は、フェールオーバの所要時間に応じて予め定められる。
　（Ｓ６３）サーバレス関数５１は、一定時間待機する。そして、ステップＳ６０に処理が進む。
　このように、サーバレス関数５１は、運用系マシン２００によるジョブが中断されたり、スケジュール通りに実行されなかったりすることがないように、サービスアップグレードにおけるフェールオーバの実行タイミングを決定する。これにより、運用系マシン２００によるジョブ運用への影響が低減される。
　図１９は、フェールオーバの各処理の例を示すフローチャートである。
　フェールオーバの各処理は、ステップＳ５５に相当する。
　（Ｓ７０）サーバレス関数５１は、処理対象のテナントのテナントＩＤに対応するマシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｐｒｏｄｕｃｔｉｏｎ」のマシンＩＤを、管理テーブル７１ｃから取得する。
　（Ｓ７１）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」のマシンＩＤのマシン、すなわち、運用系マシン２００のサービスを停止する。
　（Ｓ７２）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」のマシンＩＤのマシン、すなわち、運用系マシン２００の共有ストレージ４００をアンマウントする。
　（Ｓ７３）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｉｔｏｎ」のマシンＩＤのマシン、すなわち、サービスアップグレード済マシン３００ａを起動する。
　（Ｓ７４）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｉｔｏｎ」のマシンＩＤのマシン、すなわち、サービスアップグレード済マシン３００ａに共有ストレージ４００をマウントする。
　（Ｓ７５）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｉｔｏｎ」のマシンＩＤのマシン、すなわち、サービスアップグレード済マシン３００ａのサービスを起動する。
　（Ｓ７６）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」のマシンＩＤのマシン、すなわち、運用系マシン２００を停止する。
　（Ｓ７７）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｓｔａｎｄｂｙ＿ｏｌｄ」それぞれのマシンＩＤのマシン、すなわち、運用系マシン２００および待機系マシン３００を削除する。
　（Ｓ７８）サーバレス関数５１は、マシンタイプ「ｐｒｏｄｕｃｔｉｏｎ＿ｏｌｄ」、「ｓｔａｎｄｂｙ＿ｏｌｄ」それぞれのマシンＩＤのマシン、すなわち、運用系マシン２００および待機系マシン３００の情報を管理テーブル７１ｃから削除する。そして、フェールオーバの各処理が終了する。
　こうして、管理テーブル７１ｃから旧運用系の仮想マシン、および、旧待機系の仮想マシンの情報が削除され、その後、ステップＳ５７により該当のテナントのテナントステータスが「ｐａｔｃｈ」から「ｎｏｒｍａｌ」に変更される。サービスアップグレード済マシン３００ａは、運用系マシン２００により更新されたテナント固有データを共有ストレージ４００から直接読み取ることができる。また、サービスアップグレード済マシン３００ａのローカルストレージには、テナント共通データが格納されている。このため、サービスアップグレード済マシン３００ａは、テナント共通データとテナント固有データとに基づいて、運用系マシン２００からサービスのジョブを引き継いで実行することができる。
　このように、サーバレス関数５１は、運用系マシン２００からサービスアップグレード済マシン３００ａへの切り替えの際にも、共有ストレージ４００を介して両マシンによる固有データの共有を行うことで、当該切り替えを効率的に行える。例えば、共有ストレージ４００にテナント共通データおよびテナント固有データの両方を書き込むよりも、切り替え時においてサービスアップグレード済マシン３００ａにより共有ストレージ４００から読み取るデータ量が低減される。その結果、運用系マシン２００の代わりにサービスアップグレード済マシン３００ａによりサービスに係るジョブを再開までに要する時間が低減され、運用系マシン２００からサービスアップグレード済マシン３００ａへの迅速な切り替えを行えるようになる。
　次に、第２の実施の形態および第３の実施の形態に対する比較例を説明する。
　図２０は、比較例を示す図である。
　比較例は、ＡＺ２ｃ１，２ｃ２内の各仮想マシンにマウント可能な共有ストレージ４００ではなく、クラウドシステム２が提供する外部ストレージ５ｂを用いて、ＡＺ２ｃ１，２ｃ２内の各仮想マシンでデータを同期する場合である。外部ストレージ５ｂは、クラウドシステム２の比較的上位のネットワークに設けられ、ＡＺ２ｃ１，２ｃ２内の各仮想マシンにマウントすることはできない。外部ストレージ５ｂは、管理ノード５ａによりアクセスされる。管理ノード５ａは、例えば監視ノード４０、サーバレス関数実行ノード５０およびマシンイメージ管理ノード６０と同じ階層のネットワークに設けられる。
　比較例では、ＡＺ２ｃ１は監視部２１０を有する。監視部２１０は、運用系マシン２００を監視し、管理ノード５ａと連携する。監視部２１０は、運用系マシン２００により実現されてもよいし、ＡＺ２ｃ１内の、運用系マシン２００とは異なる仮想マシンにより実現されてもよい。同様に、ＡＺ２ｃ２は監視部３１０を有する。監視部３１０は、待機系マシン３００を監視し、管理ノード５ａと連携する。監視部３１０は、待機系マシン３００により実現されてもよいし、ＡＺ２ｃ２内の、待機系マシン３００とは異なる仮想マシンにより実現されてもよい。例えば、監視部２１０は、運用系マシン２００の異常を検知すると、管理ノード５ａにより運用系マシン２００から待機系マシン３００への切り替えを指示する。
　ここで、比較例の構成では、運用系マシン２００は、ローカルのストレージ２０１に、テナント共通データ（プログラム）およびテナント固有データ（ジョブ定義およびジョブ状態）の両方を書き込む。そして、ストレージ２０１におけるテナント共通データやテナント固有データが更新されると、待機系マシン３００との同期のために、更新後のデータが外部ストレージ５ｂに書き込まれる。
　管理ノード５ａは、同期を行う際に、待機系マシン３００を起動させる。起動した待機系マシン３００は、外部ストレージ５ｂから最新のデータを取得し、ローカルのストレージ３０１に反映させる。
　しかし、このように同期処理のたびに、待機系マシン３００を実行すると計算リソースが消費され、テナントが本来実行したいジョブの他に、同期処理のためのコストが発生するという問題がある。
　すなわち、比較例の方法では、可用性は維持できるが外部ストレージ５ｂに更新がある毎に待機系マシン３００を起動するため、待機系マシン３００の起動時間が増加する分、運用コストの増加が起きる。
　そこで、第２の実施の形態で例示したように、サーバレス関数実行ノード５０は、運用系マシン２００と待機系マシン３００とのデータの連携が、共有ストレージ２５を用いて行われるようにする。待機系マシン３００は、運用系マシン２００が更新した固有データを共有ストレージ４００から読み取れる。これにより、運用系マシン２００と待機系マシン３００との間で定期的な、あるいは、データ更新毎のデータの同期処理を行わなくてよくなり、運用系マシン２００から待機系マシン３００へ切り替えるときに待機系マシン３００を起動させればよい。
　ただし、共有ストレージ４００を運用系マシン２００および待機系マシン３００からマウント可能とするなどの方法により両マシンで共有する場合、共有ストレージ４００は、運用系マシン２００および待機系マシン３００によりネットワーク経由で共有される。このため、切り替え時に共有ストレージ４００から待機系マシン３００へ比較的多量のデータを読み取らせると、当該データの読み取りに時間がかかる可能性がある。これは、切り替え完了の遅延の原因になり可用性に影響する。
　そこで、サーバレス関数実行ノード５０は、運用系マシン２００のストレージ２０１および待機系マシン３００のストレージ３０１それぞれにテナント共通データが配置され、共有ストレージ４００にはテナント固有データが書き込まれるようにする。これにより、共有ストレージ４００にテナント共通データおよびテナント固有データの両方を書き込むよりも、切り替え時において待機系マシン３００により共有ストレージ４００から読み取るデータ量が低減される。その結果、例えば運用系マシン２００の異常検知から待機系マシン３００によりサービスに係るジョブを再開までに要する時間が低減され、運用系マシン２００から待機系マシン３００への迅速な切り替えを行えるようになる。
　こうして、サーバレス関数実行ノード５０は、同期処理の都度、待機系マシン３００を起動して同期処理を行う方法に比べて、当該同期処理を省略することで待機系マシン３００の実行に係る余計なコストを削減するとともに、フェールオーバを高速化できる。すなわち、サーバレス関数実行ノード５０は、運用系マシン２００により提供されるサービスの可用性を効率的に向上できる。
　更に、テナント共通データが共有ストレージ４００に保存されないので、テナント共通データおよびテナント固有データの両方を共有ストレージ４００に保存するよりも、共有ストレージ４００として割く記憶リソースを低減できるという利点もある。
　第３の実施の形態で例示した、運用系マシン２００からサービスアップグレード済マシン３００ａへの切り替えの際も、運用系マシン２００から待機系マシン３００への切り替えと同様の利点がある。すなわち、第３の実施の形態においても、サーバレス関数実行ノード５０は、運用系マシン２００により提供されるサービスの可用性を効率的に向上できる。
　また、ジョブ実行では高頻度でデータ書き込みが発生するため、比較例の方法では、待機系マシン３００のストレージ３０１の更新を行う頻度が多くなり、待機系マシン３００の起動状態が続く。よって、サービスアップグレードのための隙間時間が確保できないため、ジョブ運用を止める必要がある。また、ジョブ運用を止めるため、サービスアップグレードのためにテナントとの時間調整の手間がかかる問題もある。
　一方、第３の実施の形態で例示したように、サーバレス関数実行ノード５０によれば、サービスアップグレードのために運用系マシン２００によるジョブ運用を止めなくて済む。すなわち、サーバレス関数実行ノード５０は、ジョブ運用への影響を抑えて、サービスアップグレード済マシン３００ａへの円滑な切り替えを行える。
　以上説明したように、サーバレス関数実行ノード５０に用いられるプロセッサ１０１は次の処理を実行する。下記の処理は、プロセッサ１０１がサーバレス関数５１に相当するプログラムを実行することで実現されてもよい。
　プロセッサ１０１は、複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードの第１記憶部および待機系ノードの第２記憶部それぞれに、複数のユーザそれぞれに対応するジョブの実行に共通に用いられる共通データを配置する。プロセッサ１０１は、運用系ノードによるジョブの実行に応じて、または第１ユーザにより更新される、第１ユーザに対応するジョブの固有データを運用系ノードから共有ストレージに書き込ませる。例えば、プロセッサ１０１は、運用系ノードに共有ストレージをマウントし、固有データの書き込み先を共有ストレージに指定することで、運用系ノードにより固有データを共有ストレージに書き込ませる。それとともに、プロセッサ１０１は、運用系ノードの稼働中には待機系ノードを停止状態とする。プロセッサ１０１は、ジョブの実行主体を運用系ノードから待機系ノードに切り替える際に、待機系ノードを起動し、共有ストレージからの、待機系ノードによる固有データの読み取りを可能にする設定を行う。
　これにより、プロセッサ１０１は、サービスの可用性を効率的に向上できる。例えば、同期処理のために運用系ノードの稼働中に待機系ノードを起動させずに済み、待機系ノードの実行時間を減らせる。よって、待機系ノードの利用に伴うコストが低減される。また、待機系ノードは、切り替え時に共有ストレージから固有データを読み取ればよく、共有ストレージから共通データを読み取らなくてよい。このため、切り替え時のデータ読み込みの時間が短縮され、切り替えの高速化が図られる。なお、運用系マシン２００は、運用系ノードの一例である。待機系マシン３００は、待機系ノードの一例である。ストレージ２０１は、第１記憶部の一例である。ストレージ３０１は、第２記憶部の一例である。運用系マシン２００および待機系マシン３００に対応する共有ストレージは、共有ストレージ４００である。また、ユーザは、テナントと言われてもよい。更に、プロセッサ１０１は、通信インタフェース１０７を介して、運用系ノードや待機系ノードと通信する。
　例えば、共有ストレージは、運用系ノードおよび待機系ノードにマウント可能である。プロセッサ１０１は、待機系ノードによる固有データの読み取りを可能にする設定では、共有ストレージを待機系ノードにマウントする。
　これにより、プロセッサ１０１は、運用系ノードと待機系ノードとのデータ共有を容易に実現できる。例えば、プロセッサ１０１は、通信インタフェース１０７を介して、待機系ノードのＯＳへマウントコマンドを入力して実行させればよく、データ共有のために特別なソフトウェアを運用系ノードや待機系ノードへ導入しなくて済む。
　プロセッサ１０１は、待機系ノードによる固有データの読み取りを可能にする設定では、共有ストレージを待機系ノードにマウントする前に、運用系ノードから共有ストレージをアンマウントする。
　これにより、プロセッサ１０１は、運用系ノードおよび待機系ノードの両方から共有ストレージに保持される固有データが更新されることを防ぎ、固有データの整合性を保てる。
　また、プロセッサ１０１は、運用系ノードから共有ストレージをアンマウントする前に、中継ノードが保持する接続先情報から運用系ノードの情報を削除する。ここで、中継ノードは、端末装置４などのアクセス元ノードにより送信されるリクエストを運用系ノードや待機系ノードへ中継するノードである。ロードバランサ９０は、中継ノードの一例である。そして、プロセッサ１０１は、共有ストレージを待機系ノードにマウントした後に、中継ノードが保持する接続先情報に待機系ノードの情報を追加する。
　これにより、プロセッサ１０１は、アクセス元ノードのリクエストが、運用系ノードに代えて、待機系ノードに振り分けられるように設定できる。また、プロセッサ１０１は、切り替えの最中に、運用系ノードや待機系ノードへリクエストが転送されることを防げる。
　また、共通データは、例えばジョブを動作させるジョブ管理ソフトウェアなどのプログラム、すなわち、所定プログラムである。プロセッサ１０１は、所定プログラムをアップグレードした新ノードをクラウドシステム２上に用意して停止状態としてもよい。プロセッサ１０１は、ジョブの実行主体を運用系ノードから新ノードに切り替える際に、新ノードを起動し、共有ストレージからの、新ノードによる固有データの読み取りを可能にする設定を行ってもよい。例えば、プロセッサ１０１は、新ノードによる固有データの読み取りを可能にする設定では、共有ストレージを新ノードにマウントする。前述のサービスアップグレード済マシン３００ａは新ノードの一例である。
　これにより、プロセッサ１０１は、サービスの可用性を効率的に向上できる。例えば、切り替え時だけ新ノードを起動させればよいので、同期処理のために運用系ノードの稼働中に新ノードを起動させずに済み、新ノードの実行時間を減らせる。よって、新ノードの利用に伴うコストが低減される。また、新ノードは、切り替え時に共有ストレージからテナント固有データを読み取ればよく、共有ストレージから共通データを読み取らなくてよい。このため、切り替え時のデータ読み込みの時間が短縮され、切り替えの高速化が図られる。なお、新ノードの用意は、当該新ノードに対応するマシンイメージのデータに基づいてクラウドシステム２上に新ノードを作成することで行われる。
　プロセッサ１０１は、新ノードを用意すると、ノードの管理に用いられる管理テーブルに、運用系ノードに対して新ノードを用意済であることを記録してもよい。例えば、管理テーブル７１ａにおけるテナントステータス「ｐａｔｃｈ」は新ノードを用意済であることを示す。プロセッサ１０１は、管理テーブルに基づいて新ノードを用意済であることを検出すると、運用系ノードのジョブの実行状況に応じてジョブの実行主体を運用系ノードから新ノードに切り替えるタイミングを決定する。例えば、プロセッサ１０１は、運用系ノードによるジョブの定義情報からジョブの実行スケジュールを取得し、当該ジョブが実行されない空き時間を特定し、当該空き時間に含まれる時刻を切り替えのタイミングとして決定してもよい。プロセッサ１０１は、決定したタイミングにおいてジョブの実行主体を運用系ノードから新ノードに切り替える際に、管理テーブルにおいて、運用系ノードの情報を削除し、新ノードを新たな運用系として設定する。
　これにより、プロセッサ１０１は、運用系ノードから新ノードへの切り替えに伴うジョブの実行への影響を抑えて、管理テーブルにより現在運用系となっている仮想マシンを適切に管理できる。
　また、運用系ノードは、第１アベイラビリティゾーン（例えばＡＺ２ｃ１）で動作してもよい。待機系ノードは、第２アベイラビリティゾーン（例えばＡＺ２ｃ２）で動作してもよい。この場合、プロセッサ１０１は、第１アベイラビリティゾーンおよび第２アベイラビリティゾーンのうちの一方のアベイラビリティゾーンに新ノードを用意し、他方のアベイラビリティゾーンに新ノードに対応する待機系のノードを用意してもよい。
　このように、プロセッサ１０１は、運用系／待機系マシンを異なるアベイラビリティゾーンに配置することで、アベイラビリティゾーンでの障害に対する耐障害性を高め、サービスの可用性を向上させることができる。なお、第１アベイラビリティゾーンは、運用系ノードが割り当てられる１以上の第１データセンタの集合と言われてもよいし、当該１以上の第１データセンタが属するゾーンと言われてもよい。第２アベイラビリティゾーンは、待機系ノードが割り当てられる１以上の第２データセンタの集合と言われてもよいし、当該１以上の第２データセンタが属するゾーンと言われてもよい。
　また、共通データは、例えばジョブを動作させる所定プログラムである。また、固有データは、例えば当該所定プログラムによって使用される、ジョブの定義およびジョブの状態を示す情報である。
　このように、プロセッサ１０１は、所定プログラムによりジョブ管理を行う運用系ノードや待機系ノードにより提供されるサービスの可用性の向上に特に有効である。プロセッサ１０１は、運用系ノードにより提供されるジョブ管理のサービスの可用性を効率的に向上できる。
　なお、第１の実施の形態の情報処理は、処理部１２にプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体１１３に記録できる。
　例えば、プログラムを記録した記録媒体１１３を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体１１３に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
　１０　情報処理装置
　１１　記憶部
　１２　処理部
　１３　通信部
　２０　情報処理システム
　２１　運用系ノード
　２２　待機系ノード
　２３　第１記憶部
　２４　第２記憶部
　２５　共有ストレージ
　２６　中継ノード
　３０　アクセス元ノード

Claims (17)

  1. 　コンピュータに、
    　複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および前記運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、
    　前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、
    　前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う、
    　処理を実行させるプログラム。
  2. 　前記共有ストレージは、前記運用系ノードおよび前記待機系ノードにマウント可能であり、
    　前記設定では、前記共有ストレージを前記待機系ノードにマウントする、
    　処理を前記コンピュータに実行させる請求項１記載のプログラム。
  3. 　前記設定では、前記共有ストレージを前記待機系ノードにマウントする前に、前記運用系ノードから前記共有ストレージをアンマウントする、
    　処理を前記コンピュータに実行させる請求項２記載のプログラム。
  4. 　前記運用系ノードから前記共有ストレージをアンマウントする前に、アクセス元ノードにより送信されるリクエストを前記運用系ノードへ中継する中継ノードが保持する接続先情報から前記運用系ノードの情報を削除し、
    　前記共有ストレージを前記待機系ノードにマウントした後に、前記接続先情報に前記待機系ノードの情報を追加する、
    　処理を前記コンピュータに実行させる請求項３記載のプログラム。
  5. 　前記共通データは、前記ジョブを動作させる所定プログラムであり、
    　前記所定プログラムをアップグレードした新ノードを用意して停止状態とし、
    　前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記新ノードを起動し、前記共有ストレージからの、前記新ノードによる前記固有データの読み取りを可能にする設定を行う、
    　処理を前記コンピュータに実行させる請求項１記載のプログラム。
  6. 　前記新ノードを用意すると、ノードの管理に用いられる管理テーブルに、前記運用系ノードに対して前記新ノードを用意済であることを記録し、
    　前記管理テーブルに基づいて前記新ノードを用意済であることを検出すると、前記運用系ノードの前記ジョブの実行状況に応じて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替えるタイミングを決定し、
    　決定した前記タイミングにおいて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記管理テーブルにおいて、前記運用系ノードの情報を削除し、前記新ノードを新たな運用系として設定する、
    　処理を前記コンピュータに実行させる請求項５記載のプログラム。
  7. 　前記運用系ノードは、第１アベイラビリティゾーンで動作し、
    　前記待機系ノードは、第２アベイラビリティゾーンで動作し、
    　前記第１アベイラビリティゾーンおよび前記第２アベイラビリティゾーンのうちの一方のアベイラビリティゾーンに前記新ノードを用意し、他方のアベイラビリティゾーンに前記新ノードに対応する待機系のノードを用意する、
    　処理を前記コンピュータに実行させる請求項５記載のプログラム。
  8. 　前記共通データは、前記ジョブを動作させる所定プログラムであり、
    　前記固有データは、前記所定プログラムによって使用される、前記ジョブの定義および前記ジョブの状態を示す情報である、
    　請求項１記載のプログラム。
  9. 　コンピュータが、
    　複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードによりアクセスされる第１記憶部および前記運用系ノードに対応する待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、
    　前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、
    　前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う、
    　情報処理方法。
  10. 　複数のユーザのうちの第１ユーザに対応するジョブに用いられる運用系ノードおよび前記運用系ノードに対応する待機系ノードとの通信に用いられる通信部と、
    　前記運用系ノードによりアクセスされる第１記憶部および前記待機系ノードによりアクセスされる第２記憶部それぞれに、前記複数のユーザそれぞれに対応する前記ジョブの実行に共通に用いられる共通データを配置し、前記運用系ノードによる前記ジョブの実行に応じて、または、前記第１ユーザにより更新される、前記第１ユーザに対応する前記ジョブの固有データを、前記運用系ノードおよび前記待機系ノードにより共有される共有ストレージに書き込ませるとともに、前記運用系ノードの稼働中には前記待機系ノードを停止状態とし、前記ジョブの実行主体を前記運用系ノードから前記待機系ノードに切り替える際に、前記待機系ノードを起動し、前記共有ストレージからの、前記待機系ノードによる前記固有データの読み取りを可能にする設定を行う処理部と、
    　を有する情報処理装置。
  11. 　前記共有ストレージは、前記運用系ノードおよび前記待機系ノードにマウント可能であり、
    　前記設定では、前記共有ストレージを前記待機系ノードにマウントする、請求項１０記載の情報処理装置。
  12. 　前記設定では、前記共有ストレージを前記待機系ノードにマウントする前に、前記運用系ノードから前記共有ストレージをアンマウントする、請求項１１記載の情報処理装置。
  13. 　前記処理部は、
    　前記運用系ノードから前記共有ストレージをアンマウントする前に、アクセス元ノードにより送信されるリクエストを前記運用系ノードへ中継する中継ノードが保持する接続先情報から前記運用系ノードの情報を削除し、
    　前記共有ストレージを前記待機系ノードにマウントした後に、前記接続先情報に前記待機系ノードの情報を追加する、請求項１２記載の情報処理装置。
  14. 　前記共通データは、前記ジョブを動作させる所定プログラムであり、
    　前記処理部は、
    　前記所定プログラムをアップグレードした新ノードを用意して停止状態とし、
    　前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記新ノードを起動し、前記共有ストレージからの、前記新ノードによる前記固有データの読み取りを可能にする設定を行う、請求項１０記載の情報処理装置。
  15. 　前記処理部は、
    　前記新ノードを用意すると、ノードの管理に用いられる管理テーブルに、前記運用系ノードに対して前記新ノードを用意済であることを記録し、
    　前記管理テーブルに基づいて前記新ノードを用意済であることを検出すると、前記運用系ノードの前記ジョブの実行状況に応じて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替えるタイミングを決定し、
    　決定した前記タイミングにおいて前記ジョブの実行主体を前記運用系ノードから前記新ノードに切り替える際に、前記管理テーブルにおいて、前記運用系ノードの情報を削除し、前記新ノードを新たな運用系として設定する、請求項１４記載の情報処理装置。
  16. 　前記運用系ノードは、第１アベイラビリティゾーンで動作し、
    　前記待機系ノードは、第２アベイラビリティゾーンで動作し、
    　前記処理部は、
    　前記第１アベイラビリティゾーンおよび前記第２アベイラビリティゾーンのうちの一方のアベイラビリティゾーンに前記新ノードを用意し、他方のアベイラビリティゾーンに前記新ノードに対応する待機系のノードを用意する、請求項１４記載の情報処理装置。
  17. 　前記共通データは、前記ジョブを動作させる所定プログラムであり、
    　前記固有データは、前記所定プログラムによって使用される、前記ジョブの定義および前記ジョブの状態を示す情報である、請求項１０記載の情報処理装置。
PCT/JP2023/046854 2023-03-13 2023-12-27 プログラム、情報処理方法および情報処理装置 WO2024190043A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2023-038328 2023-03-13
JP2023038328A JP2024129247A (ja) 2023-03-13 2023-03-13 プログラム、情報処理方法および情報処理装置

Publications (1)

Publication Number Publication Date
WO2024190043A1 true WO2024190043A1 (ja) 2024-09-19

Family

ID=92754575

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/046854 WO2024190043A1 (ja) 2023-03-13 2023-12-27 プログラム、情報処理方法および情報処理装置

Country Status (2)

Country Link
JP (1) JP2024129247A (ja)
WO (1) WO2024190043A1 (ja)

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FUNADA, YASUNOBU: "Fundamentals of clustering technology and Installation steps/guideline of costs", DB MAGAZINE, vol. 2005, no. 3, 1 March 2005 (2005-03-01), pages 81 - 85, XP009558686 *
KOBUNA, MICHINARI: "Corresponding the latest server OS. Windows network strategy. Part 10: Reducing server downtime", NIKKEI NETWORK, NIKKEI BPSHA, TOKYO, JP, no. 213, 28 December 2017 (2017-12-28), JP , pages 86 - 91, XP009557681, ISSN: 1345-482X *

Also Published As

Publication number Publication date
JP2024129247A (ja) 2024-09-27

Similar Documents

Publication Publication Date Title
CN112099918B (zh) 容器化环境中的集群的实时迁移
CN114341792B (zh) 存储集群之间的数据分区切换
US10838829B2 (en) Method and apparatus for loading data from a mirror server and a non-transitory computer readable storage medium
CN108475251B (zh) 针对容器的虚拟网络、热交换、热缩放与灾难恢复
JP5015351B2 (ja) 実行プログラムによる非ローカルブロックデータストレージへの信頼性の高いアクセスの実現
JP4467624B2 (ja) ソフトウェアアップデート管理プログラム、ソフトウェアアップデート管理装置、およびソフトウェアアップデート管理方法
RU2653292C2 (ru) Перенос служб через границы кластеров
EP2923272B1 (en) Distributed caching cluster management
US11249788B2 (en) Cloud management platform, and virtual machine management method and system
US20100011238A1 (en) Information processing system and data recovery method
US9733989B1 (en) Non-disruptive load-balancing of virtual machines between data centers
JP2019016135A (ja) 情報処理システム、情報処理システムの制御プログラム及び情報処理システムの制御方法
US9262323B1 (en) Replication in distributed caching cluster
WO2012051845A1 (zh) 一种数据迁移的方法及系统
JP2015075898A (ja) 処理再開方法、処理再開プログラムおよび情報処理システム
JP2014044553A (ja) プログラム、情報処理装置および情報処理システム
US11397752B1 (en) In-memory ingestion for highly available distributed time-series databases
JP6365085B2 (ja) データ移行方法及びデータ移行装置
JP7216888B2 (ja) 更新装置、更新方法およびプログラム
CN112711469A (zh) 云主机迁移方法、装置、计算机设备和存储介质
JP5491934B2 (ja) サーバ装置、及び情報処理システムの制御方法、並びにプログラム
WO2024190043A1 (ja) プログラム、情報処理方法および情報処理装置
CN117851352A (zh) 一种基于TiDB分布式集群的环境管理系统及方法
WO2006043322A1 (ja) サーバ管理プログラム、サーバ管理方法、およびサーバ管理装置
CN115878269A (zh) 集群迁移方法、相关装置及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23927645

Country of ref document: EP

Kind code of ref document: A1