Information processing system, management device, management method, and program

Abstract

Provided is a call control system including a management device 30 that manages at least one virtual machine 10 that operates on a virtual infrastructure. The virtual machine 10 is provided with: a volume 12 in which an OS, middleware, and an application, which are not updated during operation, are disposed; a volume 13 in which data, which is updated during operation, is disposed; and a recovery unit 11 that sends a request for acquiring an image of the volume 13 to the management device 30. The management device 30 is provided with: a management unit 31 that creates the virtual machine 10 by disposing an image file including the OS, the middleware, and the application in the volume 12 and disposing an image file including the data that is updated during the operation of the virtual machine 10 in the volume 13; and a backup unit 32 that backs up the volume 13 in the form of an image file in response to an image acquisition request from the virtual machine 10. In the event of a software fault, the recovery unit 11 restarts software while progressively increasing the scope of initialization, and sends a volume creation request to the management device 30 when the scope of initialization has reached a prescribed level. The backup unit 32 creates a new volume 13 by using the image file in response to the volume creation request. The recovery unit 11 replaces the volume 13 with the new volume 13 created in response to the volume creation request.

Description

[Technical field]

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

[0002] A call control server is a server that provides telephone call services. Due to the nature of the service, high availability is required for call control servers. Current call control servers are built with dedicated hardware, but with the recent trend toward higher performance of commercially available hardware and system virtualization, migration to a virtual environment for call control servers is being considered. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Kawaguchi, et al., "Evaluation of Virtualization Technology for SIP Servers," IEICE Technical Report, vol. 117, no. 131, NS2017-70, pp.211-216, July 2017. [Non-Patent Document 2] Zhu, et al., "A Study on Partial Backup and Restore Methods in Virtual Environments," Proceedings of the IEICE General Conference, Communications Lecture Series 2, B-6-19, March 2019 Summary of the Invention [Problem to be solved by the invention]

[0004] The current call control server periodically backs up data to a file server. The backup file mainly contains information related to editing subscriber data and data that specifies the operation of the call control server alone. The backup file is acquired once a day. When recovering from a hardware failure, replacement hardware is prepared, the backup file is downloaded from the file server, and the replacement hardware is started and the backup file is read. Data backup and restoration are performed using the functions of the call control server.

[0005] When considering migrating call control servers to a virtual environment, data backup and restoration can be performed using the current method or by using the snapshot function of the virtual environment. The snapshot function is a function that saves the state of a volume held by a virtual machine at a certain point in time as an image file. The image file can be used to recreate the virtual machine at the time of the snapshot.

[0006] When using the current method, a backup file is acquired using a function of an application running on a virtual machine. During recovery, a virtual machine is created using the image file at startup, the backup file is downloaded from the file server, the software is started on the virtual machine, the virtual machine is operated as a call control server, and then the backup file is read into the virtual machine.

[0007] When using the snapshot function, an image file of the virtual machine that operates as the call control server is periodically taken. At the time of recovery, the image file taken by the snapshot is used to create a virtual machine. This image file contains the operating system (OS), middleware (MW), applications (APL), and data (corresponding to what is included in the backup file). Using the image file, it is possible to start up a virtual machine in the state it was in at the time the snapshot was taken.

[0008] When using the current method, it is necessary to load the backup file after creating a virtual machine, whereas when using the snapshot function, it is only necessary to create a virtual machine using the image file taken by the snapshot. In other words, the method using the snapshot function allows for faster recovery than the current method.

[0009] On the other hand, in the event of a software failure, the virtual machine operating as the call control server first restarts (resets) the software portion while gradually expanding the range of initialization in order to minimize the impact on services, and if recovery is not possible, the data to be read is replaced with a backup file and the software is restarted (data replacement restart). If recovery is not possible even after data replacement restart, the recovery work is handed over to maintenance personnel.

[0010] When using the current method, the virtual machine is not deleted and is left running, and the backup file is read and the data is replaced during data replacement restart. Therefore, the virtual machine's MW state remains up to date, and after the data is replaced with the backup file, the data replacement restart process continues.

[0011] However, when using the snapshot function, in order to replace the current data with data equivalent to the backup file during data replacement restart, it is necessary to delete the running virtual machine and then create a virtual machine using the image file taken by the snapshot. When a virtual machine is created using an image file, the state of the MW becomes the state it was in at the time of the snapshot. Therefore, the virtual machine loses information that the restart process at a stage prior to data replacement restart has already been repeatedly executed and was not restored, and there is a possibility that the restart process at a lower level stage will be executed again.

[0012] The present invention has been made in view of the above, and has an object to enable efficient recovery of a call control server in a virtual environment. [Means for solving the problem]

[0013] An information processing system according to one aspect of the present invention is an information processing system including a management device that manages one or more virtual machines that operate on a virtualization platform, the virtual machines each having a first volume in which software that is not updated during operation is allocated, a second volume in which data that is updated during operation is allocated, and For backups that request backups a backup and restore unit that transmits an image acquisition request to the management device, gradually expands an initialization range when a failure occurs and resumes the software, and transmits a volume creation request to the management device when the initialization range reaches a predetermined stage, and replaces the second volume with a new volume created in response to the volume creation request, and the management device includes a management unit that creates the virtual machine by placing a first image file in the first volume, the first image file including software that is not updated while the virtual machine is in operation, and a second image file in the second volume, the second image file including data that is updated while the virtual machine is in operation, and a backup and restore unit that creates the virtual machine by storing a request for updating the virtual machine from the virtual machine. For backup Backing up the second volume as the second image file in response to an image acquisition request, and The above and a backup / restore unit that creates the new volume by using the second image file in response to a volume creation request. Effect of the Invention

[0014] According to the present invention, a call control server in a virtual environment can be efficiently restored. [Brief description of the drawings]

[0015] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a call control system according to the present embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of the flow of the automatic recovery process. [Diagram 3] FIG. 3 is a diagram showing an example of restarting the automatic recovery process. [Figure 4] FIG. 4 is a diagram showing an example of how volumes are exchanged and then resumed. [Diagram 5] FIG. 5 is a diagram illustrating an example of how a virtual machine is created on alternative hardware. [Figure 6] FIG. 6 is a diagram illustrating an example of a recovery process in a comparative example. [Figure 7] FIG. 7 is a diagram illustrating an example of a hardware configuration of a device included in the call control system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] The call control system of this embodiment will be described with reference to Fig. 1. The call control system shown in Fig. 1 is a system constructed using a virtual environment. The call control system abstracts resources provided by hardware (not shown) and operates a virtual machine 10 as a call control server on a virtualization platform. The virtual machine 10 is created by a management device 30 and deleted by the management device 30. Although only one virtual machine 10 is shown in Fig. 1, multiple virtual machines 10 may be operating.

[0017] The management device 30 includes a management unit 31 , a backup unit 32 , and a storage unit 33 .

[0018] The management unit 31 creates a virtual machine 10, and stops and deletes an operating virtual machine 10. When creating a virtual machine 10, the management unit 31 places an image file including the OS, MW, and APL in a volume 12 of the virtual machine 10, and places an image file including data in a volume 13 of the virtual machine 10. In other words, the software (OS, MW, and APL) that operates the virtual machine 10 as a call control server and the data that is updated during operation are placed in separate volumes 12 and 13 of the virtual machine 10.

[0019] In response to an image acquisition request from the virtual machine 10, the backup unit 32 acquires an image file of the volume 13 of the virtual machine 10 in which data is placed as a snapshot, and stores the image file in the storage unit 33. The virtual machine 10 periodically transmits an image acquisition request to the management device 30 to back up the volume 13. The image file of the volume 13 acquired as a snapshot contains data equivalent to a conventional backup file.

[0020] The backup unit 32 creates the volume 13 from the image file stored in the storage unit 33 in response to a volume creation request from the virtual machine 10 .

[0021] The storage unit 33 holds image files including the OS, MW, and APL, and image files of the volume 13 including data.

[0022] The virtual machine 10 includes a recovery unit 11 and volumes 12 and 13 .

[0023] The volumes 12 and 13 are storage devices used by the virtual machine 10, and are configured as separate storage devices using resources provided by the virtualization infrastructure. The call control system can take snapshots of each of the volumes 12 and 13.

[0024] Image files including the OS, MW, and APL are placed in volume 12, and various software programs are started from volume 12. Since the OS, MW, and APL are updated only when functions are updated, it is basically unnecessary to periodically obtain image files of volume 12.

[0025] Data that is updated while the virtual machine 10 is operating is placed in the volume 13. Snapshots of the volume 13 are taken periodically by the management device 30. An image file of the volume 13 is managed by the management device 30.

[0026] The recovery unit 11 transmits an image acquisition request to the management device 30, for example, once a day, requesting a snapshot of the volume 13. When a software failure is detected, the recovery unit 11 resumes the software running on the virtual machine 10 while gradually expanding the initialization range. For example, the recovery unit 11 executes the resume process in stages, in the order of resuming the APL process, resuming the MW process, and rebooting the OS. If the software is not recovered even after the staged software resume, the recovery unit 11 performs data replacement resume. When data replacement resumes, the recovery unit 11 transmits a volume creation request to the management device 30 and replaces the volume 13 including the current data with a newly created volume. The newly created volume includes data equivalent to a backup file. The data is replaced in the order of the backup file and the boot guarantee file. The boot guarantee file is a file including initial data.

[0027] The recovery unit 11 holds information about the initialization range. Even when data replacement is resumed, the virtual machine 10 is not deleted, so the information about the initialization range held by the recovery unit 11 is not lost. The MW installed in the virtual machine 10 may function as the recovery unit 11.

[0028] Next, a flow of automatic recovery processing by the recovery unit 11 will be described with reference to the flowchart of Fig. 2. When the recovery unit 11 detects a software failure, it starts the automatic recovery processing shown in the flowchart of Fig. 2.

[0029] In step S11, the recovery unit 11 executes a restart in a specified initialization range. For example, the recovery unit 11 first executes a restart of the APL process.

[0030] In step S12, the recovery unit 11 judges whether or not the software failure has been recovered from. If the software failure has been recovered from, the automatic recovery process is terminated.

[0031] If recovery from the software failure has not been achieved, in step S13, the recovery unit 11 expands the scope of restart. For example, the recovery unit 11 expands the scope of restart in the order of APL process restart, MW restart, OS restart, and data replacement restart.

[0032] In step S14, the recovery unit 11 determines whether or not data replacement is necessary.

[0033] If data replacement is not required, the recovery unit 11 advances the process to step S11 and resumes at the specified stage. Figure 3 shows how software resumes when data replacement is not required. The recovery unit 11 resumes the APL, MW, and OS according to the stage, while leaving the data in volume 13 as the current data.

[0034] If data replacement is necessary, the recovery unit 11 transmits a volume creation request to the management device 30 in step S15.

[0035] When the volume is created, in step S16, the recovery unit 11 replaces the volume 13 with the newly created volume and executes the restart.

[0036] 4 shows the state of data replacement restart. When the management device 30 receives a volume creation request from the virtual machine 10, it creates a new volume 13 using an image file that includes data equivalent to the backup file. The recovery unit 11 replaces the volume 13 with the new volume 13 and executes the restart. For example, after replacing the volume 13, the recovery unit 11 executes the restart by rebooting the OS.

[0037] In step S17, the recovery unit 11 judges whether or not the software failure has been recovered from. If the software failure has been recovered from, the automatic recovery process is terminated.

[0038] If recovery is not achieved even after data replacement restart, in step S18, the recovery unit 11 contacts a maintenance person and has the recovery work handed over to the maintenance person. The maintenance person creates a virtual machine 10 on replacement hardware, for example. The replacement hardware is allocated by a virtualization platform. FIG. 5 shows how the virtual machine 10 is created on replacement hardware (not shown). When creating the virtual machine 10 on replacement hardware, the management device 30 also creates the virtual machine 10 by combining a plurality of image files. Specifically, an image file including an OS, MW, and APL is placed in volume 12, and an image file including data is placed in volume 13 to create the virtual machine 10. The data in volume 13 of the newly created virtual machine 10 is equivalent to the backup file of a snapshot taken the previous day.

[0039] Next, a comparative example in which data is backed up by snapshots without being divided into separate volumes will be described with reference to Fig. 6. In the comparative example, a snapshot of a volume including an OS, MW, APL, and data is taken as a backup.

[0040] In the event of a software failure, the virtual machine 50A attempts to recover by gradually restarting it. Until the OS is restarted, the restart is performed with the current data. If the OS is not recovered even after being restarted, data replacement is required. When replacing the data, the management device 70 deletes the virtual machine 50A and recreates the virtual machine 50B using an image file containing data equivalent to a backup file. The recreated virtual machine 50B has not only the data but also the state of the OS, MW, and APL at the time of the snapshot. The recreated virtual machine 50B has lost information about how far the automatic recovery process has progressed. Therefore, after the virtual machine 50B is created, there is a risk that the restart process at a stage that has already been executed in the virtual machine 50B will be executed again.

[0041] As described above, the virtual machine 10 includes the volume 12 in which the OS, MW, and APL that are not updated during operation are arranged, the volume 13 in which data that is updated during operation is arranged, and the recovery unit 11 that transmits an image acquisition request for the volume 13 to the management device 30. The management device 30 includes a management unit 31 that creates the virtual machine 10 by arranging an image file including the OS, MW, and APL in the volume 12 and an image file including data that is updated during operation of the virtual machine 10 in the volume 13, and a backup unit 32 that backs up the volume 13 as an image file in response to an image acquisition request from the virtual machine 10. The recovery unit 11 gradually expands the initialization range when a software failure occurs and resumes the software, and transmits a volume creation request to the management device 30 when the initialization range reaches a predetermined stage, and the backup unit 32 creates a new volume 13 using the image file in response to the volume creation request. The recovery unit 11 replaces the volume 13 with the new volume 13 created in response to the volume creation request. This allows recovery to be continued by replacing only the volume 13 where the data is located without rewinding the state of the recovery unit 11 (e.g., MW) that holds the initialization range, thereby preventing unnecessary re-execution of a resume process that has already been performed.

[0042] The devices included in the above-described call control system may be, for example, a general-purpose computer system including a central processing unit (CPU) 901, a memory 902, a storage 903, a communication device 904, an input device 905, and an output device 906, as shown in Fig. 7. In this computer system, the devices included in the call control system are realized by the CPU 901 executing a predetermined program loaded onto the memory 902. This program can be recorded on a computer-readable recording medium such as a magnetic disk, an optical disk, or a semiconductor memory, or can be distributed via a network.

[0043] Although the present embodiment has been described as a call control system that utilizes a virtual environment, the present invention can be applied to any information processing system that attempts to perform recovery using a backup file. [Explanation of symbols]

[0044] 10. Virtual Machine 11…Restoration Department 12,13…Volume 30…Management device 31…Management Department 32…Backup section 33…Storage section

Claims

1. An information processing system including a management device that manages one or more virtual machines that operate on a virtualization platform, The virtual machine includes: a first volume in which software that is not updated during operation is located; a second volume in which data that is updated during operation is located; a backup and restore unit that transmits a backup image acquisition request to the management device, requesting a backup of the second volume, and when a failure occurs, gradually expands an initialization range and restarts the software, and when the initialization range reaches a predetermined stage, transmits a volume creation request to the management device, and replaces the second volume with a new volume created in response to the volume creation request; The management device includes: a management unit that creates the virtual machine by placing a first image file, which includes software that is not updated during operation of the virtual machine, in a first volume, and placing a second image file, which includes data that is updated during operation of the virtual machine, in a second volume; a backup / restore unit that backs up the second volume as the second image file in response to the backup image acquisition request from the virtual machine, and creates the new volume using the second image file in response to the volume creation request from the virtual machine; Information processing system.

2. A management device that manages one or more virtual machines operating on a virtualization platform, a management unit that creates the virtual machine by placing a first image file, which includes software that is not updated during operation of the virtual machine, in a first volume, and placing a second image file, which includes data that is updated during operation of the virtual machine, in a second volume; a backup and restore unit that backs up the second volume as the second image file in response to an image acquisition request from the virtual machine, and creates a new volume using the second image file in response to a volume creation request from the virtual machine, When a failure occurs, the virtual machine gradually expands the initialization range and restarts the software, and when the initialization range reaches a predetermined stage, it transmits a volume creation request to the management device and replaces the second volume with a new volume created in response to the volume creation request. Management device.

3. A management method for managing one or more virtual machines operating on a virtualization platform, comprising: The management device: creating the virtual machine by placing a first image file in a first volume, the first image file including software that is not updated during operation of the virtual machine, and placing a second image file in a second volume, the second image file including data that is updated during operation of the virtual machine; backing up the second volume as the second image file in response to an image acquisition request from the virtual machine; creating a new volume using the second image file in response to a volume creation request from the virtual machine; When a failure occurs, the virtual machine gradually expands the initialization range and restarts the software, and when the initialization range reaches a predetermined stage, it transmits a volume creation request to the management device and replaces the second volume with a new volume created in response to the volume creation request. Management method.

4. A program for causing a computer to operate as each unit of the management device according to claim 2.

Images