JP2015225510A - Backup system and backup method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To improve processing performance and to reduce hardware cost at the same time.SOLUTION: A backup system constructed on a virtual infrastructure includes: a virtual volume to which at least one of a plurality of physical volumes different in performance is allocated and which is accessed by each of a plurality of virtual processing entities; and a virtual machine monitor which identifies a virtual processing entity of an access source when an access to the virtual volume is detected, and allocates a physical volume suitable to a processing kind of the identified virtual processing entity to a virtual volume.

Description

  The present invention relates to a backup system and a backup method for backing up a user system.

  A technique called replication is known in which write information to a master volume (MV) of a user system is sent to a backup system and written to a replication volume (RV) set as a MV pair. In recent years, the number of users using replication has increased. As the number of users increases, the hardware configuration of the backup system may increase in scale.

  Therefore, in order to prevent the hardware configuration from becoming large-scale, a measure for constructing a backup system on a virtual infrastructure can be considered. In such a backup system, replication data transmitted from the storage system of the user system is received by a “replication-dedicated virtual machine” operating on the hypervisor of the backup system, and written to an RV (virtual RV) that is a virtual volume. It is. In addition, the virtual RV that has been replicated is used by the “normal virtual machine” when the user system goes down. That is, the virtual RV is accessed from both the replication-dedicated virtual machine and the normal virtual machine.

  However, the access characteristics of each virtual machine are greatly different. The replication-dedicated virtual machine performs continuous writing to the virtual RV but does not perform any reading (that is, the written data is never used). Further, the write speed to the virtual RV by the replication dedicated virtual machine is sufficiently higher than the speed of the communication line used for replication, so the write speed to the virtual RV does not become a bottleneck in the replication process. For these reasons, the virtual RV being replicated does not necessarily have to be assigned to a high-speed physical volume. Rather, in order to reduce the hardware cost, it is desirable that the virtual RV during replication is allocated to a physical volume that is inexpensive and has a large capacity (emphasizing features other than speed), for example.

  On the other hand, a normal virtual machine (that is, a virtual machine that has inherited the business of the user system) performs not only writing but also reading from the virtual RV. Furthermore, since the bottleneck that existed at the time of replication disappears, the access speed to the virtual RV greatly affects the performance of the virtual machine. For this reason, it is desirable that the virtual RV in normal use is allocated to a high-speed physical volume.

  Patent Document 1 describes a technique for moving data between tiers of a tiered storage pool (the higher the storage tier, the higher the access speed).

  Patent Literature 2 describes a virtualization switch that automatically determines the type of a connected host based on acquired host management information.

JP 2013-196290 A (Page Nos. 9 and 11) JP 2007-249446 A (Page No. 10)

  However, the existing hypervisor does not have a means for distinguishing between a replication-dedicated virtual machine and a normal virtual machine. Therefore, in a general backup system, a virtual RV cannot be assigned to a desired physical volume. As a result, it is difficult to reduce the hardware cost of the backup system while maintaining the processing performance.

  Thus, for example, a method of selecting a physical volume based on the write frequency is conceivable. In this case, a high-speed physical volume is always assigned to a virtual RV that is being written continuously (that is, having a high writing frequency) during replication. However, as described above, during replication, other factors are rather a bottleneck, and the processing of replication itself does not necessarily have to be performed at high speed. That is, the above method cannot reduce the hardware cost of the backup system.

  Further, the movement of data between storage tiers in Patent Document 1 is performed according to performance information such as data access frequency and physical disk response performance. Therefore, in the case of Patent Document 1, the hardware cost of the backup system cannot be reduced as in the above method.

  Patent Document 2 merely describes a technique for automatically determining the type of a connected host, and clarifies virtual machines (replication-dedicated virtual machine and normal virtual machine) generated when performing replication. Can not be distinguished. Therefore, also in Patent Document 2, the hardware cost of the backup system cannot be reduced.

  The present invention has been made to solve the above problems, and an object of the present invention is to provide a backup system and a backup method capable of achieving both improvement in processing performance and reduction in hardware cost.

  The backup system of the present invention is a backup system constructed on a virtualization platform, and is assigned with at least one of a plurality of physical volumes having different performances and is accessed from each of a plurality of virtual processing entities. And a virtual machine monitor that identifies the virtual processing subject of the access source when the access to the virtual volume is detected, and assigns the physical volume suitable for the processing type of the identified virtual processing subject to the virtual volume; Is provided.

  The backup method of the present invention is a backup method in a backup system constructed on a virtualization infrastructure, and is assigned with at least one of a plurality of physical volumes having different performances and is accessed from each of a plurality of virtual processing entities. When the access to the virtual volume is detected, the virtual processing subject of the access source is specified, and the physical volume suitable for the processing type of the specified virtual processing subject is assigned to the virtual volume It is characterized by.

  According to the present invention, both improvement in processing performance and reduction in hardware cost can be achieved.

It is a block diagram which shows the structural example of the operation system which concerns on the 2nd Embodiment of this invention. It is a data block diagram which shows the data structure of a write command. It is a data block diagram of a replication pair management table. It is a data block diagram of a virtual volume management table. It is a data block diagram of a virtual machine management table. It is a data block diagram of a physical volume characteristic table. 2 is a flowchart for explaining an operation example of the hypervisor shown in FIG. 1 (specifically, an operation example of starting a replication-dedicated virtual machine). 3 is a flowchart for explaining an operation example of a controller (user side storage apparatus) shown in FIG. 1. FIG. 1 is a diagram for explaining an operation example of the backup host shown in FIG. 1 (specifically, an operation example in which a write command transmitted to a backup system is converted based on a replication pair management table and written to a virtual RV). It is a flowchart. 2 is a flowchart for explaining an operation example of the hypervisor shown in FIG. 1 (specifically, an operation example in which a write command for a virtual volume is converted into a write command for a physical volume and written to the physical volume). It is a block diagram which shows the structural example of the operation system which concerns on the 3rd Embodiment of this invention. 12 is a flowchart for explaining an operation example of the hypervisor shown in FIG. 11 (specifically, an operation example in which a write command for a virtual volume is converted into a write command for a physical volume and written to the physical volume). It is a block diagram which shows the structural example of the operation system which concerns on the 4th Embodiment of this invention. 13 is a flowchart for explaining an operation example of the hypervisor shown in FIG. 12 (specifically, an operation example in which a write command for a virtual volume is converted into a write command for a physical volume and written to the physical volume).

[First Embodiment]
The backup system according to the first embodiment of the present invention is constructed on a virtualization platform. The backup system includes a virtual volume and a virtual machine monitor. A virtual volume is assigned with at least one of a plurality of physical volumes having different performances and is accessed from each of a plurality of virtual processing entities. When the virtual machine monitor detects access to the virtual volume, the virtual machine monitor identifies the virtual processing subject of the access source and allocates a physical volume suitable for the processing type of the identified virtual processing subject to the virtual volume.

In the first embodiment described above, a physical volume suitable for the processing type of the virtual processing subject is allocated to the virtual volume. Therefore, further improvement of performance is expected in one process, and correction of overs spec is expected in another process. Thereby, the situation where an expensive and high-performance physical volume is used more than necessary is also avoided. In summary, according to the first embodiment, it is possible to achieve both improvement in processing performance and reduction in hardware cost.
[Second Embodiment]
(Description of configuration)
FIG. 1 is a block diagram showing a configuration example of an operation system 10 according to the second embodiment of the present invention. The operation system 10 includes a user system 20 and a backup system 30.

  The user system 20 includes a user side host 101 and a user side storage device 102.

  The user side storage apparatus 102 includes a controller 103 and an MV (master volume) 105.

  The MV 105 is a physical volume in which business data used in the user system 20 is written.

  The controller 103 writes business data to the MV 105. The controller 103 includes replication data transmission means 104.

  The replication data transmission unit 104 receives a write command 200 for business data from the controller 103. The replication data transmission means 104 receives the received write command 200, replication control information (information regarding the synchronization start / stop of the MV 105 and virtual RV 134), and heartbeat information for determining the operating state of the user system 20. It transmits to the replication data receiving means 113.

  FIG. 2 is a data configuration diagram of the write command 200. The write command 200 includes at least a write volume 201, a write start point address 202, a write image length 203, and a write image 204. The write volume 201 and the write start point address 202 are information regarding physical volumes recognized by the user-side storage apparatus 102. When the user-side storage apparatus 102 receives the write command 200 from the user-side host 101, the write image length starting from the physical volume address of the write start point address 202 of the physical volume specified by the write volume 201 A write image 204 (that is, specific contents of business data) is written in the range 203.

  The backup system 30 includes a backup side host 111 and a backup side storage device 131. The backup system 30 is constructed on a virtualization platform. Specifically, the backup side host 111 includes a hypervisor 118 (virtual machine monitor) and a plurality of virtual machines operating on the hypervisor 118. In the present embodiment, an example in which one of a plurality of virtual machines is a replication-dedicated virtual machine 112 and another virtual machine is a normal virtual machine 116 is taken as an example.

  The hypervisor 118 can create a virtual computer (virtual machine) that behaves like computer hardware by software, and can operate various types of operating systems (OSs) on the virtual machine.

  The replication-only virtual machine 112 writes the write image 204 (that is, specific contents of the business data) to the virtual RV 134 defined as the replication pair of the MV 105 by executing the write command received from the user system 20. .

  The replication dedicated virtual machine 112 includes a replication data receiving unit 113, a replication writing unit 114, and a replication pair management table 115.

  The replication data receiving unit 113 receives information (write command 200, replication control information, heartbeat information) transmitted from the replication data transmitting unit 104 and outputs the information to the replication writing unit 114.

  The replication writing unit 114 converts the replication data input from the replication data receiving unit 113 into a logical volume of the replication pair based on the definition of the replication pair management table 115, and transmits it to the virtual volume writing unit 119 of the hypervisor 118. To do.

  FIG. 3 is a data configuration diagram of the replication pair management table 115. The replication pair management table 115 is a management table that defines the relationship between a master volume (physical volume) 301 and a replication volume (virtual volume) 302 that is a replication pair of the master volume. For example, FIG. 3 illustrates a case where the replication pair of MV1 is virtual RV1, and the replication pair of MV2 is virtual RV2.

  The normal virtual machine 116 is a virtual machine that takes over the work of the user system 20 when the user system 20 goes down. The succeeded business is specifically executed by a business AP (application) 117 on the normal virtual machine 116.

  In the present embodiment, the identification name (VM name) of the replication-only virtual machine 112 is “VM1” and its VM type is “replication-only”, and the identification name (VM name) of the normal virtual machine 116 is “VM2”. As an example, the VM type is “normal”.

  The hypervisor 118 executes at least management of virtual machine activation and management of resources necessary for the operation of the virtual machine including the virtual volume. The hypervisor 118 includes a replication-dedicated virtual machine starting unit 121, a normal virtual machine starting unit 122, a virtual volume writing unit 119, and a writing source specifying unit 120.

  The replication dedicated virtual machine starting unit 121 starts the replication dedicated virtual machine 112 and each unit operating in the replication dedicated virtual machine 112.

  The normal virtual machine activation unit 122 activates the normal virtual machine 116.

  Based on the virtual volume management table 124, the virtual volume writing means 119 determines whether or not the write command can be written to the virtual volume, and writes the write command to the physical volume that can be recognized by the backup storage device 131. And conversion to the backup storage device 131 is executed. Further, the virtual volume writing unit 119 determines the write source characteristics based on the write source determination unit 120 and the physical volume characteristic table 125 when the physical volume area corresponding to the virtual volume write destination is not allocated. Allocate space on a suitable physical volume.

  The backup side host 111 further includes a virtual volume management table 124, a virtual machine management table 123, and a physical volume characteristic table 125.

  FIG. 4 is a data configuration diagram of the virtual volume management table 124. The virtual volume management table 124 is a management table for managing the correspondence between virtual volumes and physical volumes. The virtual volume management table 124 is updated when the virtual volume writing unit 119 determines the correspondence between the virtual volume and the physical volume, and the virtual volume writing unit 119 issues a write command to the virtual volume as a physical volume write command. Referenced when converting to. The virtual volume management table 124 includes at least a virtual volume 401, a logical address 402, a physical volume 403, and a physical address 404.

  FIG. 5 is a data configuration diagram of the virtual machine management table 123. The virtual machine management table 123 is a management table for managing virtual machines and their types. Specifically, the virtual machine management table 123 includes a VM name 501 and a VM type 502. The name of the virtual machine is set as the VM name. Here, the name of the virtual machine is a name that can uniquely identify the virtual machine. The VM type 502 is set with a virtual machine type (for example, a replication-dedicated virtual machine and a normal virtual machine). For example, FIG. 5 illustrates a case where the VM type 502 of the virtual machine whose VM name 501 is “VM1” is “replication only” and the VM type 502 of the virtual machine whose VM name 501 is “VM2” is “normal”. Illustrated.

  FIG. 6 is a data configuration diagram of the physical volume characteristic table 125. The physical volume characteristic table 125 is a management table for managing the volume characteristics of the backup storage apparatus 131. The physical volume characteristic table 125 is used for determination when the virtual volume writing unit 119 allocates a physical volume to a virtual volume. When managing volume performance and capacity as characteristics, the physical volume characteristics table 125 has attributes of volume name 601, speed 602, capacity 603, but may have other characteristics. The characteristic information can be acquired from the backup storage apparatus 131, but the result of benchmarking the characteristics of each volume by the hypervisor 118 can also be recorded.

  The backup side storage device 131 includes a first volume 133, a second volume 142, and a controller 132.

  The first volume 133 and the second volume 142 are physical volumes assigned to the virtual volume. In order to cope with various write characteristics, the first volume 133 and the second volume 142 can have different performance and capacity. For example, in the present embodiment, the first volume 133 is an inexpensive and large-capacity HDD (Hard Disk Drive) specialized for capacity unit price, and the SSD (Solid State Drive) specialized for high-speed access is the second volume 142. ). The selection of the write volume according to the characteristics of the physical volume may be executed by the controller 132 or may be executed by the hypervisor 118 that has acquired information from the backup storage device 131. In the following description, a case where the hypervisor 118 selects a write volume based on the physical volume characteristic table 125 is taken as an example.

  The virtual RV 134 is a virtual volume that forms a replication pair with the MV 105. In the virtual RV 134, data written to the MV 105 is regularly reflected (that is, replicated). When it is difficult to continue the business in the user system 20, the normal virtual machine 116 continues the business of the user system 20 by using the business data stored in the virtual RV 134. The virtual RV 134 is managed by the hypervisor 118, and the management information is recorded in the virtual volume management table 124. Since the virtual RV 134 is a logical volume, it may be divided and allocated on the physical volume, or the physical volume may not be allocated to an unused area.

  Since the virtual VOL 141 includes data (for example, OS) that does not need to be transmitted from the user system 20, a replication pair is not set (that is, not used as a virtual RV). The virtual VOL 14 receives access from the hypervisor 118 or a virtual machine (replication dedicated virtual machine 112, normal virtual machine 116) as necessary.

The controller 132 writes data to the first volume 133 and the second volume 142. The instruction used for writing is the above-described writing instruction 200.
(Description of operation)
FIG. 7 is a flowchart for explaining an operation example of the hypervisor 118 shown in FIG. 1 (specifically, an operation example of starting the replication-dedicated virtual machine 112).

  The replication dedicated virtual machine starting unit 121 generates the replication dedicated virtual machine 112 (step S701). The replication dedicated virtual machine starting unit 121 registers the generated replication dedicated virtual machine 112 in the virtual machine management table 123 (step S702). Specifically, the replication-dedicated virtual machine activation unit 121 registers “VM1”, which is the name of the replication-dedicated virtual machine 112, in the VM name 501 and the VM type 502 (that is, a replication-dedicated virtual machine). ). Finally, the replication dedicated virtual machine starting unit 121 starts the replication receiving unit 113 and the replication writing unit 114 necessary for processing the replication data (step S703).

  FIG. 8 is a flowchart for explaining an operation example of the controller 103 shown in FIG. When writing to the user-side storage apparatus 102 is executed by the user-side host 101, the controller 103 receives a write command from the user-side host 101 (step S801). The replication data transmission unit 104 transmits the received write command to the replication data reception unit 113 (step S802). The backup system 30 performs writing to the virtual RV based on the received write command. Details of the writing process to the virtual RV will be described later. In this case, the writing to the virtual RV is “synchronous writing”. The controller 103 executes a write process to the MV 105 based on the write command (step S803). After writing to the MV 105, the controller 103 waits for a “virtual RV write completion notification” returned from the backup system 30 (step S804). When the “virtual RV write completion notification” is received, the controller 103 returns a “write response” to the user-side host 101 (step S805).

  If the writing of the user system 20 and the backup system 30 is not synchronized, the waiting process in step S804 can be omitted.

  9 shows an operation example of the backup-side host 111 shown in FIG. 1 (specifically, an operation in which a write command transmitted to the backup system 30 is converted based on the replication pair management table 115 and written to the virtual RV 134) It is a flowchart for demonstrating an example.

  The replication data receiving unit 113 receives the write command transmitted from the user system 20 (step S901). Here, the write command received by the replication data receiving means 113 describes writing to the MV 105 that is a physical volume. The replication writing unit 114 refers to the replication pair management table 115, identifies the virtual RV set in the replication pair, and changes the write volume described in the received write command from “MV” to “virtual”. RV "(step S902). The replication writing unit 114 transmits the converted write command to the hypervisor 118 (step S903). The write command transmitted to the hypervisor 118 is written to the physical volume (for example, the first volume 133) by the virtual volume writing unit 119. When the writing to the virtual RV is completed, a virtual RV writing completion notification is transmitted to the user system 20 via the replication data receiving unit 113 (step S904).

  As in the case of FIG. 8, when the writing of the user system 20 and the backup system 30 is not synchronized, the transmission process in step S904 can be omitted.

  FIG. 10 is a flowchart for explaining an operation example of the hypervisor 118 shown in FIG. 1 (specifically, an operation example in which a write command for a virtual volume is converted into a write command for a physical volume and written to the physical volume). is there.

  The virtual volume writing means 119 that has received the write command, based on the virtual volume management table 124 (FIG. 4), has the virtual volume described in the write command and the write start point address of which physical address of which physical volume. Is identified (step S1001). Further, the virtual volume writing unit 119 specifies the writing source virtual machine using the writing source specifying unit 120 (step S1002). The hypervisor 118 determines the type of the identified virtual machine based on the virtual machine management table 123 (FIG. 5) (step 1003).

  If the identified virtual machine type is “normal”, the hypervisor 118 checks whether a physical area is allocated to the virtual volume area (step S1004). In the case of an unallocated area (No in step S1004), the hypervisor 118 searches for a physical volume with a higher write speed from the physical volume characteristics table (FIG. 6) (step S1005). The hypervisor 118 allocates a virtual volume area to the searched physical volume area (step S1006).

  On the other hand, if the area to be written has already been allocated (Yes in step S1004), the hypervisor 118 searches the physical volume characteristics table 125 (FIG. 6) for the physical volume to which the area is allocated, and determines the physical volume. Understand volume characteristics. The hypervisor 118 determines whether or not the grasped characteristic matches the characteristic of the writing source (step S1007). If it does not match the characteristics of the writing source (No in step S1007), it means that a physical volume with a low writing speed is allocated to the virtual volume. Therefore, in order to improve the operating speed of the business AP 117 operating on the normal virtual machine 116, the area is moved to a physical volume with a high writing speed (step S1008). Finally, the hypervisor 118 performs writing to the area of the physical volume allocated through these processes (step S1009).

Note that, as a result of the virtual machine type determination in step S1003, if the specified virtual machine type is “replication only”, the processes in steps S1010 to 1014 are executed. In this case, each processing of steps S1010 to 1014 is the same as that of steps S1004 to 1008, except that the movement to the physical volume in step S1014 is different from the step S1008 in that it is an area movement to a physical volume with priority for capacity. Since it is the same as each process, the description about these processes is abbreviate | omitted.
(Explanation of effect)
In the second embodiment described above, the type of the virtual machine that uses the virtual RV (replication processing or normal business execution of the user system 20) is grasped, and the virtual RV is suitable for the usage form of each virtual machine. A physical volume with performance is allocated. Accordingly, a further improvement in performance is expected in a certain processing type (for example, normal business execution of the user system 20), and correction of overspec is expected in another processing (for example, replication processing). Thereby, the situation where an expensive and high-performance physical volume is used more than necessary is also avoided. In summary, according to the second embodiment, it is possible to achieve both improvement in processing performance and reduction in hardware cost.

In the second embodiment described above, the case where the physical volume selection according to the writing source is selected by the hypervisor 118 is shown. However, the selection may be performed by the backup storage device 131. . At this time, the write characteristic information may be added to the write command passed to the backup storage device 131.
[Third Embodiment]
FIG. 11 is a block diagram illustrating a configuration example of an operation system 800 according to the third embodiment of the present invention. In the second embodiment, the type assigned to each virtual machine is used to determine the write characteristics of the virtual machine. In contrast, in the third embodiment, as shown in FIG. 11, an interface used for replication writing (replication dedicated interface) and an interface used for normal writing (normal interface) are provided separately. . In this case, the determination of the writing source is made based on the interface used.

  In FIG. 11, the components other than the normal virtual machine 802, the hypervisor 804, the replication dedicated interface 806, and the normal interface 808 are the same as the components in FIG. Therefore, regarding these components, the same reference numerals as those in FIG. 1 are given in FIG. 11, and descriptions thereof are omitted.

  The normal virtual machine 802 is a virtual machine in which the replication-only virtual machine 112 and the normal virtual machine 116 are combined into one in the second embodiment. Therefore, only one virtual machine operates in the third embodiment. Each component of the normal virtual machine 802 is the same as that in the second embodiment.

  The replication dedicated interface 806 is generated by the hypervisor 804 and is used when writing replication data to the virtual volume.

  The normal interface 808 is generated by the hypervisor 804 and used when writing data other than replication.

  FIG. 12 is a flowchart for explaining an operation example of the hypervisor 804 shown in FIG. 11 (specifically, an operation example in which a write command for a virtual volume is converted into a write command for a physical volume and written to the physical volume). is there.

  Regarding the operation, FIG. 12 (third embodiment) differs from FIG. 10 (second embodiment) only in two points described below. The first point is that step S1002 (specification of the writing source virtual machine) in FIG. 10 is changed to step S1201 (specifying the writing source interface) in FIG. The second point is that step S1003 (virtual machine type determination) in FIG. 10 is changed to step S1202 (interface determination) in FIG.

According to the third embodiment described above, the same effect as the second embodiment (both improvement in processing performance and reduction in hardware cost) is achieved. Furthermore, according to the third embodiment, a dedicated virtual machine for performing the replication process becomes unnecessary, and the control of the backup system 30 can be simplified.
[Fourth Embodiment]
FIG. 13 is a block diagram illustrating a configuration example of an operation system 900 according to the fourth embodiment of the present invention. A feature of the fourth embodiment is that the replication processing is executed on the hypervisor 902 instead of on the virtual machine. In other words, in the fourth embodiment, all the components included in the replication-dedicated virtual machine 112 in FIG. 1 are basically included in the hypervisor 902. In the case of the fourth embodiment, since the replication process is directly executed by the hypervisor 902 itself, there is no need to start the replication dedicated virtual machine 112. Therefore, as shown in FIG. 13, the replication-dedicated virtual machine starting unit 121 has been deleted.

  In the fourth embodiment, the main body (writing source) that performs writing to the virtual RV 134 is the replication writing unit 119 in the hypervisor 902 or the normal virtual machine 116. Therefore, the determination of the write source in the fourth embodiment is nothing but to determine whether the write source is the replication writing unit 119 or the normal virtual machine 116.

  FIG. 14 is a flowchart for explaining an operation example of the hypervisor 902 shown in FIG. 12 (specifically, an operation example in which a write command for a virtual volume is converted into a write command for a physical volume and written to the physical volume). is there.

  Regarding the operation, FIG. 14 (fourth embodiment) differs from FIG. 10 (second embodiment) only in two points described below. The first point is that step S1002 (identification of the write source virtual machine) in FIG. 10 is changed to step S1401 (identification of the write subject) in FIG. The second point is that step S1003 (virtual machine type determination) in FIG. 10 is changed to step S1402 (write subject determination) in FIG.

  According to the fourth embodiment described above, the same effect as the second embodiment (both improvement in processing performance and reduction in hardware cost) is achieved. Furthermore, according to the fourth embodiment, it is possible to separate the replication processing from the operation of the virtual machine.

  Further, a program for realizing all or a part of the functions of the respective embodiments described above is recorded on a computer-readable recording medium, and the program recorded on the recording medium is read into a computer system and executed. The processing of each unit may be performed as necessary.

  As an example of the “computer system”, for example, a CPU (Central Processing Unit) can be cited.

  The “computer-readable recording medium” is, for example, a non-transitory storage device. Examples of the non-temporary storage device include a magneto-optical disk, a portable medium such as a ROM (Read Only Memory), a nonvolatile semiconductor memory, and a hard disk built in a computer system. The “computer-readable recording medium” may be a temporary storage device. As an example of a temporary storage device, for example, a communication line in the case of transmitting a program via a network such as the Internet or a communication line such as a telephone line, or a volatile memory inside a computer system can be cited.

  Further, the program may be for realizing a part of the above-described functions, and may be capable of realizing the above-described functions in combination with a program already recorded in the computer system. .

  As mentioned above, although this invention was demonstrated using each embodiment, the technical scope of this invention is not limited to description of said each embodiment. It is obvious to those skilled in the art that various modifications or improvements can be added to the above embodiments. Therefore, it is needless to say that embodiments with such changes or improvements are also included in the technical scope of the present invention. The numerical values and names of the components used in the embodiments described above are illustrative and can be changed as appropriate.

DESCRIPTION OF SYMBOLS 10 Operation system 20 User system 30 Backup system 101 User side host 102 User side storage apparatus 103 Controller 104 Replication data transmission means 105 MV
DESCRIPTION OF SYMBOLS 111 Backup side host 112 Replication exclusive virtual machine 113 Replication data receiving means 114 Replication writing means 115 Replication pair management table 116 Normal virtual machine 118 Hypervisor 119 Virtual volume writing means 120 Write source specifying means 121 Replication dedicated virtual machine starting means 122 normal virtual machine starting means 123 virtual machine management table 124 virtual volume management table 125 physical volume characteristic table 131 backup side storage device 132 controller 133 first volume 134 virtual RV
141 Virtual VOL
142 Second volume 200 Write command 201 Write volume 202 Write start point address 203 Write image length 204 Write image 301 Master volume 302 Replication volume 401 Virtual volume 402 Logical address 403 Physical volume 404 Physical address 501 VM name 502 VM type 601 Volume name 602 Speed 603 Capacity 800 Operation system 802 Normal virtual machine 804 Hypervisor 806 Replication dedicated interface 808 Normal interface 900 Operation system 902 Hypervisor

Claims (7)

A backup system built on a virtualization platform,
A virtual volume to which at least one of a plurality of physical volumes having different performance is allocated and accessed from each of a plurality of virtual processing entities;
A virtual machine monitor that, when detecting access to the virtual volume, identifies the virtual processing subject of the access source, and assigns the physical volume suitable for the processing type of the identified virtual processing subject to the virtual volume;
A backup system comprising:   When the physical volume already assigned to the virtual volume when the access is detected is not a physical volume suitable for the processing type, the virtual machine monitor assigns a physical volume suitable for the processing type to the virtual volume. The backup system according to claim 1. The virtual volume is a virtual replication volume that stores data obtained by replicating a master volume of a user system,
3. The backup system according to claim 2, wherein the plurality of physical volumes are a first physical volume and a second physical volume having an access speed lower than that of the first physical volume but a larger storage capacity.   The plurality of virtual processing entities are a first virtual machine whose processing type is the replication processing, and a second virtual machine whose processing type is a process for performing a task on the user system side on the backup system side. The backup system according to claim 3.   5. The backup system according to claim 4, wherein, when the access source is the first virtual machine, the virtual machine monitor allocates the second physical volume to the virtual replication volume.   The backup system according to claim 4 or 5, wherein, when the access source is the second virtual machine, the virtual machine monitor allocates the first physical volume to the virtual replication volume. A backup method in a backup system built on a virtualization platform,
Providing at least one of a plurality of physical volumes having different performances and providing a virtual volume accessed from each of a plurality of virtual processing entities;
When detecting access to the virtual volume, specify the virtual processing subject of the access source,
A backup method characterized by allocating the physical volume suitable for the identified processing type of the virtual processing subject to the virtual volume.

Images