WO2013060627A1 - Cluster system und verfahren zur migration von virtuellen maschinen in einer shared nothing konfiguration basierend auf lokaler datenspeicherung mit datenreplikation - Google Patents

Cluster system und verfahren zur migration von virtuellen maschinen in einer shared nothing konfiguration basierend auf lokaler datenspeicherung mit datenreplikation Download PDF

Info

Publication number
WO2013060627A1
WO2013060627A1 PCT/EP2012/070770 EP2012070770W WO2013060627A1 WO 2013060627 A1 WO2013060627 A1 WO 2013060627A1 EP 2012070770 W EP2012070770 W EP 2012070770W WO 2013060627 A1 WO2013060627 A1 WO 2013060627A1
Authority
WO
WIPO (PCT)
Prior art keywords
server computer
data
virtual
virtual machine
local
Prior art date
Application number
PCT/EP2012/070770
Other languages
English (en)
French (fr)
Inventor
Henning Klein
Original Assignee
Fujitsu Technology Solutions Intellectual Property Gmbh
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 Fujitsu Technology Solutions Intellectual Property Gmbh filed Critical Fujitsu Technology Solutions Intellectual Property Gmbh
Priority to JP2014537565A priority Critical patent/JP5995981B2/ja
Priority to US14/353,889 priority patent/US20140337847A1/en
Priority to EP12777902.3A priority patent/EP2751683A1/de
Publication of WO2013060627A1 publication Critical patent/WO2013060627A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • 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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • 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
    • G06F11/202—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 where processing functionality is redundant
    • G06F11/2038—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 where processing functionality is redundant with a single idle spare processing component
    • 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
    • G06F11/202—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 where processing functionality is redundant
    • G06F11/2048—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 where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • 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
    • G06F11/2097—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 maintaining the standby controller/processing unit updated

Definitions

  • the invention relates to a cluster system comprising a plurality of server computers and a data network for executing a plurality of virtual machines. Moreover, the invention relates to a method for executing a plurality of virtual machines on a plurality of server computers.
  • virtualization In the field of electronic data processing, virtualization is taken to mean the parallel operation of several, possibly different operating systems on at least partially shared resources of a computer, in particular its processor, main memory and mass storage, under the control of a virtualization software such as, in particular, a hypervisor.
  • a virtualization software such as, in particular, a hypervisor.
  • Different types of Virtuali ⁇ tion are known from the prior art.
  • the so-called desktop virtualization is an existing client transfer installation of a user on a virtual machine or a new virtual machine for Benut ⁇ zer furnished.
  • the client installation virtual machine such as an operating system with associated user-specific software, runs from a server computer on a data network.
  • the user himself uses a particularly simple design client computer, particularly a so-called thin or zero client to zuzugrei over the data network to the virtual machine ⁇ fen.
  • a conventional fat client can also be used terminal software installed on it to access the virtual machine. All programs started by the Benut ⁇ zer be the within the virtual machine on the part of the server computer and not on
  • the virtual Maschi ⁇ ne accesses resources of the server computer as processor or memory resources to execute the user programs.
  • server virtualization a service provided by a server computer is encapsulated in a virtual machine. In this way it is beispielswei ⁇ se possible to run a web server and a mail server, each requiring different execution environments on a single physical server computer.
  • connection broker In order to achieve a uniform utilization of the available server computers, an allocation of virtual machines to server computers is generally controlled by a so-called connection broker or a similar management tool.
  • the Connection Broker provides, among other things, that re-starting virtual machines are launched on a Ser ⁇ vercomputer who still has sufficient resources for their execution.
  • known virtualization systems require a separate storage server that can be reached by all server computers of a cluster system in order to enable the execution of a virtual machine on any server computer.
  • FIG. 1 One possible architecture of a virtualization system is shown by way of example in FIG.
  • three virtual machines IIa, IIb and 11c executed on a common server computer 12.
  • server computers are provided, which are likewise suitable for executing the virtual machines IIa to 11c.
  • Each of the virtual machines IIa to 11c is associated with its own virtual mass storage 13a to 13c.
  • a hypervisor or other virtualization software of the server computer 12 emulates the virtual machines 11
  • the virtual mass memory 13a For an operating system running on the virtual machine IIa, the virtual mass memory 13a thus appears, for example, as a local SCSI hard disk.
  • the virtualization software calls a so-called iSCSI initiator 14.
  • the iSCSI initiator 14 recognizes that access to the virtual mass storage 13a is desired and forwards a corresponding SCSI request over a data network 15 to a separate storage server 16.
  • On the storage server 16 runs a control software, which provides a so-called iSCSI target 17 for inquiries of the iSCSI initiators 16.
  • the iSCSI target 17 forwards the received requests to a hard disk drive 18 of the storage server 16. In this way, inquiries of all machines IIa to 11c of the server computer 12 are answered centrally by the storage server 16.
  • a problem of the architecture shown in FIG. 1 is that all memory accesses of all virtual machines IIa to 11c always take place via the data network 15 and are answered by one or a few hard disk drives 18 of the storage server 16. Thus competing the virtual machines IIa to 11c by bandwidth in the data network 15. In addition, concurrent requests can be answered only sequentially by the storage server 16.
  • the cluster system 10 shown in FIG. 1 is expanded by the addition of further server computers 12 for executing further virtual machines 11, not only the demand for storage capacity on the hard disk drive 18 of the storage server 16, but also that associated with the access to the virtual mass storage 13 increases latency.
  • the object of the present invention is to describe a cluster system and a working method for a cluster system, in which the latency for accessing virtual mass storage of a virtual machine is reduced.
  • the solutions described for the flexible extension of cluster systems without the associated loss of performance of known systems should be suitable.
  • a cluster system is described.
  • the cluster system has a plurality of server computers, each with at least one processor, at least one local mass memory and at least one network component, and a data network, via which the network components of the plurality of server computers are data-coupled.
  • the cluster system is configured to execute a plurality of virtual machines, wherein each of the virtual machines is assigned at least one virtual mass storage.
  • each virtual machine ma- a first copy of the data of the associated virtual ground memory on the at least one local Massenspei ⁇ cher a first server computer, and a second copy of the data of the assigned virtual ground memory on the GR stored at least one local mass storage of a second server computer of the plurality of server computers.
  • an active virtual machine of the plurality of virtual machines is executed by the at least one processor of the first server computer, data accesses of the active virtual machine are transferred to the at least one virtual mass memory assigned to the local mass memory of the first server computer.
  • copies of the virtual mass storage are placed on at least two server computers.
  • the local mass storage of the server computers are used as virtual mass storage for the virtual machines.
  • Through local mass memory accesses UNNE ⁇ ge transports are avoided over a data network, which the laser tenz Rail reduced data access and the number of
  • local changes are synchronized from one server computer to the other server computer.
  • the invention makes use of the fact that in Ser ⁇ vercomputern usually local mass storage, especially hard drives, the start of a host operating system ⁇ relationship as a hypervisor are present. Their performance is usually broke, however, since the operating system or the hypervisor of the server computer occupies a relatively lower storage volume and requires only a few accesses to the local mass storage.
  • each of the plurality of server computers has a synchronization module.
  • the Syn ⁇ chronisationsmodul the first server computer is to be rich ⁇ tet, for a specific period or a specific dA of the active virtual machine tenrise the changes to the first copy of the data of the virtual ground memory summarize and transferred together to the second server computer. Consolidating changes can further reduce network traffic over a data network used for pairing.
  • the storage server software is configured to provide the content of the virtual mass storage of the plurality of virtual machines via the data network.
  • Running storage server software through a clustered server computer simplifies virtual storage synchronization, improves compatibility with existing virtualization systems, and at the same time ensures that a virtual machine can successfully boot on any clustered server computer.
  • virtualizing a storage server may be omitted vercomputers to the additional provision of a geson ⁇ changed configured or equipped data server or Ser.
  • each of the plurality of server computer a filter driver, wherein the filter driver is adapted to ERS from a virtual through the at least one processor of the server computer running locally machine ⁇ catch mass storage accesses and to the first copy of the data of at least redirect a virtual mass storage on the local storage.
  • a method for executing a plurality of virtual machines on a plurality of server computers comprises the steps:
  • a local storage of data of virtual machines is effected while at the same time producing a redundancy on a respective other local mass memory of a second server computer.
  • the synchronization of the first data or the second data is summarized in packets and / or transakti ⁇ onsorientiert performed.
  • the method additionally comprises the steps:
  • FIG. 1 shows an architecture of a cluster system having a ge ⁇ secreted storage server
  • Figure 2 shows an architecture of a cluster system according to a
  • FIG. 4 is a flow chart of a method for parallel
  • FIG. 5 shows a flow chart of a method for moving a virtual machine as well as
  • FIGS. 6A and 6B show a flow chart of a method for
  • FIG. 2 shows a cluster system 20 with a first server computer 12a, a second server computer 12b and further server computers 12, not shown in detail.
  • the server computers 12 are connected to one another via a common data network 15.
  • further virtual machines IIb to 11c can be provided by the first server computer 12a.
  • a filter driver 21 intercepts the corresponding mass storage access.
  • the filter driver 21 does not forward the storage request, as described with reference to Figure 1, the iSCSI initiator 14 on, but forwards the request to a local mass memory 22b, in particular a built-in hard ⁇ disk drive of the server computer 12B.
  • a first copy 24d to 24f of the virtual mass memory 13d to 13f is stored on the local mass memory 22b.
  • the copies 24d to 24f are copies of a so-called virtual hard disk container used by a virtualization layer 23.
  • the virtual machines ldd to 11f are not moved from the server computer 12b to one of the other server computers 12, all accesses are made via the filter driver 21 to the local first copies 24d to 24f of the local mass memory 22b of the server computer 12b. It can therefore be dispensed largely ⁇ ver on access to the data network 15, which lld particular the latencies Mas ⁇ sen amidzugriff virtual machine reduced to IIf.
  • the contents of the virtual mass storage 13d to 13f stored in the copies 24d-24f on the local mass storage 22b are mirrored in at least one remote mass storage, in the embodiment, the local mass storage 22a of the first server computer 12a, in second copies 25d to 25f. This allows at the same time the Move any or all of the virtual machines lld to llf to the server computer 12a.
  • a synchronization of the copies 24 and 25 takes place through a background task that is regularly executed on each of the server computers 12.
  • a background task that is regularly executed on each of the server computers 12.
  • the memory server software executed on the first server computer 12a provides the virtual mass memories 13d to 13f via the data network 15, as explained with reference to FIG. These are integrated by the other server computers 12, in particular the second server computer 12b as network drives.
  • the background task running on the two ⁇ th server computer 12b then adjusts the first copies from 24d to 24f with the information provided over the data network 15 second copies 25d to 25f of the virtual mass storage 13d to 13f.
  • all changes to a first copy 24 for a particular period of, for example, 15 seconds or one minute, or to some extent, such as changed blocks or sectors with a total size of one megabyte, are summarized in an update message and collected or block by block iSCSI initiator 14 to the iSCSI target 17 of the first server computer 12a.
  • synchronization can also take place if a particularly low utilization of the first or second computer system 12a or 12b, of the data network 15 and / or the mass memory 22a or 22b is detected.
  • the iSCSI target 17 of the first server computer 12a updated ⁇ it towards the second copies 25 of the virtual ground memory 13 22a on the local mass storage.
  • Copy 25 are stored on at least one local mass storage 22 of another server computer 12 and are synchronized in equiv ⁇ ter way.
  • FIG. 3 shows another exemplary cluster system 30 used for desktop virtualization.
  • the cluster system 30 in the illustrated embodiment comprises three server computers 12a to 12c through which a total of six virtual desktops 31a to 31f are provided.
  • Each of the virtual desktop 31 is implemented by an assigned virtual machine 11, which is associated with at least a vir tual ⁇ mass storage. 13
  • the virtual machines 11 and virtu ⁇ economic mass memory 13 in the Figure 3 are not shown.
  • each server computer 12 includes one or more local mass storage 22, such as in particular an internal hard disk, tion module a filter driver 21 and a synchrotron 32.
  • a storage server software 33 for providing the functionality of a conventional storage server 16 a ⁇ directed.
  • the memory server software 33 is updated at any time point, however, only by one of the three server computers 12a to 12c executed, for example, the first server computer 12a.
  • the storage server software 33 is activated on one of the other server computers 12b or 12c by an administration service 34, so that this server computer 12b or 12c can take over the function of the server computer 12a at any time.
  • the administration service 34 further serves to distribute the virtual desktops 31 to the server computers 12.
  • the virtual desktops 31a to 31f are evenly distributed over the three server computers 12a to 12c.
  • the virtual desktops 31a and 31b are hosted by the first server computer 12a, the virtual desktops 31c and 31d by the second server computer 12b, and the virtual desktops 31e and 31f by the third server computer 12c.
  • the Speicherkapazi- ranges ty of the local mass storage 22a to 22c to the reproach virtu ⁇ economic mass memory 13 of each of the virtual desktop 31a to 31f.
  • the virtual mass memories 13 of the virtual desktops 31a to 31f are stored on each of the mass memories 22a to 22c in copy.
  • the administration service 34 and the synchronization module 32 in each case a synchronization of the contents of the virtual mass storage 13 takes place.
  • changes are made to the contents of the virtual mass storage 13 by the virtual desktops 31a and 316 active on the first server computer 12a 31b are distributed to the server computers 12b and 12c via a broadcast message of the data network 15.
  • the server computers 12b and 12c then update their corresponding copies of the associated virtual mass memory 13 accordingly. This is exemplified by the arrows angedeu ⁇ tet in the Figure 3 for the first virtual desktop 31a.
  • changes to the virtual mass storages 13 of the virtual desktops 31c and 31d are broadcast by the second server computer 12b to the server computers 12a and 12c.
  • the changes of the virtual mass memories 13 of the virtual desktops 31e and 31f are respectively transmitted from the third server computer 12c to the server computers 12a and 12b.
  • the requirements used for synchronization are not synchronized in one embodiment, immediately, but at the request of the synchronization ⁇ module 32 or the administration services are transmitted block by block 34.
  • FIG. 4 shows a flow chart of a method 40 for operating a cluster system, for example one of the cluster systems 20 or 30.
  • the left half of FIG. 4 shows the steps taken by a first server computer 12a of the cluster system.
  • the steps are shown, which are executed by a second server computer 12b. Because of the parallel execution of the method steps on two different server computers 12, they do not run synchronously with respect to one another in terms of time. Only in the synchronization of changes to contents of a virtual mass memory 13, a synchronization described in more detail below between the first server computer 12a and the second server computer 12b takes place.
  • a first virtual Maschi ⁇ ne IIa starts.
  • a Windows operating system is started for a user who uses
  • a management software of the server computer 12a for example, executed on the server ⁇ computer hypervisor 12a, a write request of the first virtual machine receives IIa.
  • a user Be ⁇ a modified text document would like to put on a virtual Mas ⁇ sen Grande 13a of its virtual machine IIa.
  • This request is first implemented locally in step 43a.
  • the write command is intercepted by a filter driver 21 of the server computer 12a and transferred to a local
  • a step 44a for example, after a predetermined time or after the emergence of a predetermined number of changes, almost the first server computer 12a, the previously made by the virtual machine IIa ⁇ nde ⁇ stanchions and transmits a corresponding first Aktua ⁇ lleitersnachricht to the second server computer 12b.
  • the second server computer 12b receives the first update ⁇ object in a step 45b, and updates its copy of the virtual mass storage 13a of the first virtual machine IIa accordingly.
  • the second Ser ⁇ vercomputer 12b transmits in step 44b with the accumulated changes in the second virtual machine IIb at the copy 24 of the virtual mass storage 13b on the local mass storage 22b and transmits it in the form of a second Aktua ⁇ ltechniksnachricht to the first server computer 12a.
  • the first server computer 12a updates its copy of the virtual mass memory 13b of the second virtual machine IIb accordingly.
  • FIG. 5 schematically shows a method 50 for moving a virtual machine 11 from a first server computer 12a to a second server computer 12b.
  • the steps of the first server computer 12a on the lin ⁇ -hand side of Figure 5 and the process steps of the second server computer 12b on the right side of the figure 5 make ⁇ forms.
  • a first step 51 the execution of the virtual machine 11 is stopped on the first computer 12a. For example, by an administration service 34 or no more processor time allocated to a hypervisor of the virtual machine 11.
  • the update message is transmitted from the first server computer 12a to the second server computer 12b. This updates in a step 53 its local copy 25 of the virtual mass memory 13 of the virtual machine 11 in accordance with the changes of the update message.
  • a step 54 the execution of the virtual machine 11 on the second server computer 12b can be continued.
  • the update message and / or on the virtual mass storage device 13 and the current status of the work memory of the virtual Ma ⁇ machine 11 is included, so that it is synchronized in steps 52 and 53 between the server computers 12a and 12b.
  • the current state of the Häspei ⁇ Chers from an existing cluster software, such as the Administration Service 34 is transmitted.
  • the virtual machine 11 starts in step 54 in exactly the same state in which it was stopped in step 51, for example with the execution of the same applications and the same opened documents.
  • the synchronization of the virtual mass memory 13 between a local mass memory 22a of the first server computer 12a and a local mass memory 22b of the second server computer 12b is performed in parallel to the operation of the virtual machine 11. For example, portions or the entire contents of the virtual mass storage 13 may be transferred to the second server computer 12b prior to stopping the virtual machine 11.
  • FIGS. 6A and 6B schematically show the sequence of a possible synchronization method 60 for aligning copies 24 and 25 of a virtual mass memory 13 between two different server computers 12a and 12b.
  • a timer or other counter of the first server computer 12a is reset.
  • a subsequent step 62 it is checked whether a predetermined time interval T, for example a time interval of one minute, already expired or a counting, Example ⁇ , a change of 1000 blocks or sectors of a virtual mass storage device 13 is already occurred. Is this if not, a check is made in step 63 as to whether a read or write request of a locally executed virtual machine 11 has been detected by the second server computer 12a. If this is not the case, the method is continued in step 62.
  • T for example a time interval of one minute, already expired or a counting, Example ⁇
  • step 64th If it is a read request, the corresponding read request is forwarded to the local mass memory 22a of the server computer 12a in step 65 and responded to by this on the basis of a lo ⁇ cal first copy 24 of the virtual mass memory 13 ⁇ . Since no inconsistency between different copies 24 and 25 of the virtual mass memory 13 is caused by a read request, the method can be continued without performing further measures in step 62.
  • a block or sector of the local copy of the virtual mass memory 13 to be written in a suitable data structure is marked as changed in a step 66.
  • a step 66 For example, stores the filter driver 21 in a Bele ⁇ supply list in memory in a table of the synchronization of the module 32 or in appropriate metadata of the associated file system, a local address of each block overwritten.
  • the write request is performed in step 67 on the local mass storage 22a of the server computer 12a, and the process is continued in step 62.
  • step 62 If the predetermined synchronization event finally occurs in step 62, the first copy 24 of the virtual Mass storage 13 on the local mass storage 22a with ei ⁇ ner corresponding second copy 25 on the local mass storage 22b of the second server computer 12b synchronized.
  • steps 68 to 75 according to FIG. 6B are used in particular.
  • the first server computer 12a assembles an update message with all the changed contents of the virtual mass memory 13. For example, the contents of all the blocks or sectors marked as changed in step 66 of the first copy 24 of the virtual mass memory 13 together with suitable address information are combined in an update message .
  • a subsequent step 69 the update ⁇ message from the first server computer 12a via the data network 15 to the second server computer 12b and optionally transferred to the other server computers 12, which likewise hold a local copy of the virtual ground memory 13 of the virtual machine 11.
  • the transmission preferably takes place by means of a
  • the first server ⁇ computer 12a waits in step 70 optionally from whether the second server computer 12b and possibly other server computer 12 has made the synchronization as requested and confirmed ha ⁇ ben.
  • the second server computer 12b receives in a step 71, the first sent in step 69 Aktualisie ⁇ approximately object and stores them on the local mass storage 22b. Based on the containing ⁇ nen in the update message information has been verified, the second server computer 12b whether he holds a local copy 25 of the virtual mass storage 13 of the virtual machine 11. If this is the case, it takes over the changed blocks or sectors in a step 72, so that subsequently the second copy 25 of the virtual mass memory 13 of the virtual machine 11 on the local mass storage 22b of the second server computer 12b in accordance with the first copy 24 the local mass storage 22a of the first server computer 12a. If an error occurs, such as an interruption of the power supply, the update may be repeated or continued based on the data stored locally at a later time.
  • a step 73 it is optionally checked whether problems occurred during the synchronization. For example, the update message may have been received only incompletely or incorrectly. If this is the case, it will be in one
  • Step 74 requests the retransmission of the update message from the first server computer 12a. Otherwise, an acknowledgment message about the synchronization of the local mass memory 22b is preferably created.
  • This confirmation message is received by the first server computer 12a in a step 75, whereby the synchronization process is completed and the method is continued again in step 61. Is readied for a ⁇ agreed period, however, no acknowledgment message from the second server computer 12b receive the first server computer goes 12a on the assumption that the synchronization was not successful and sends in step 69, again an update message.
  • the execution of the synchronization can also be coordinated by a central service of the storage server software .
  • the state of the first copy 24 is frozen. For example, further write accesses are exposed on the first copy 24 or locally cached until the synchronization is Tar ⁇ closed by a filter driver.
  • all of the virtual mass storage 13 11 maintained for each virtual machine on all the local mass memory 22 of each server computer 12 in a cluster system and syn- together ized so that each virtual machine 11 can be run on any server ⁇ computer 12 and simultaneously to ⁇ additional data redundancy is created.
  • virtual mass memories 13 are held by a subset of the virtual machines 11 on a subset of the server computers 12, so that the corresponding virtual machines 11 can be executed on each of the server computers 12 of the subgroup.
  • Ausgestal ⁇ tung is a compromise with respect to the requirement on the size of the local storage 22 and the flexibility of the execution of the each virtual machine 11.
  • exactly two copies of a virtual ground memory 13 exist on two different server computers 12a and 12b, so the redundant execution of each virtual machine 11 in the event of failure of any server computer 12 embarkge ⁇ is. The approach described leads to a number of others
  • the server computer must 12 on which the storage server software runs 33, no longer be ⁇ Sonder be secured against outages because its function of each server computer 12 of the cluster system can be adopted. Due to the simultaneous distribution of data accesses to a plurality of mass storage devices can be dispensed with the use of special hardware, such as in particular high ⁇ network components and hard drives, and RAID systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Hardware Redundancy (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Die Erfindung betrifft ein Clustersystem (20, 30) aufweisend eine Mehrzahl von Servercomputern (12) und ein Datennetzwerk (15). Das Clustersystem (20, 30) ist zum Ausführen einer Mehrzahl von virtuellen Maschinen (11) eingerichtet, wobei jeder der virtuellen Maschinen (11) wenigstens ein virtueller Massenspeicher (13) zugeordnet ist. Dabei wird für jede virtuelle Maschine (11) eine erste Kopie (24) der Daten des zugehörigen virtuellen Massenspeichers (13) auf wenigstens einem lokalen Massenspeicher (22a) eines ersten Servercomputers (12a) und eine zweite Kopie (25) der Daten deszugehörigen virtuellen Massenspeicher (13) auf wenigstens einem lokalen Massenspeicher (22b) eines zweiten Servercomputers (12b) gespeichert. Darüber hinaus betrifft die Erfindung ein Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen (11) auf einer Mehrzahl von Servercomputern (12).

Description

Beschreibung
CLUSTER SYSTEM UND VERFAHREN ZUR MIGRATION VON VIRTUELLEN MASCHINEN IN EINER SHARED NOTHING KONFIGURATION BASIEREND AUF LOKALER DATENSPEICHERUNG MIT DATENREPLIKATION
Die Erfindung betrifft ein Clustersystem aufweisend eine Mehrzahl von Servercomputern und ein Datennetzwerk zum Ausführen einer Mehrzahl von virtuellen Maschinen. Darüber hinaus betrifft die Erfindung ein Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen auf einer Mehrzahl von Servercomputern .
Als Virtualisierung wird im Bereich der elektronischen Datenverarbeitung der parallele Betrieb von mehreren, gegebenenfalls unterschiedlichen Betriebssystemen auf zumindest teilweise gemeinsamen Ressourcen eines Computers, insbesondere dessen Prozessor, Haupt- und Massenspeicher, unter der Kontrolle einer Virtualisierungssoftware wie insbesondere eines Hypervisors verstanden. Unterschiedliche Arten der Virtuali¬ sierung sind aus dem Stand der Technik bekannt.
Bei der so genannten Desktop-Virtualisierung (englisch Virtual Desktop Infrastructure - VDI) wird eine bestehende Client- Installation eines Benutzers auf eine virtuelle Maschine übertragen oder eine neue virtuelle Maschine für einen Benut¬ zer eingerichtet. Die virtuelle Maschine mit der Client- Installation, beispielsweise ein Betriebssystem mit zugehöriger, benutzerspezifischer Software, wird von einem Servercomputer in einem Datennetzwerks ausgeführt. Der Benutzer selber benutzt einen besonders einfach aufgebauten Clientcomputer, insbesondere einen so genannten Thin- oder Zero-Client, um über das Datennetzwerk auf die virtuelle Maschine zuzugrei¬ fen. Alternativ kann auch ein konventioneller Fat-Client mit einer darauf installierten Terminalsoftware zum Zugriff auf die virtuelle Maschine verwendet werden. Alle von dem Benut¬ zer gestarteten Programme werden innerhalb der virtuellen Maschine auf Seiten des Servercomputers und nicht auf dem
Clientcomputer ausgeführt. Dabei greift die virtuelle Maschi¬ ne zum Ausführen der Benutzerprogramme auf Ressourcen des Servercomputers wie Prozessor- oder Speicherressourcen zu.
Auch andere Arten der Virtualisierung, insbesondere die so genannte Servervirtualisierung, sind grundsätzlich bekannt. Bei der Servervirtualisierung wird eine von einem Servercomputer zur Verfügung gestellten Dienstleistung in einer virtuelle Maschine gekapselt. Auf diese Weise ist es beispielswei¬ se möglich, einen Webserver und einen Mailserver, die jeweils unterschiedliche Ausführungsumgebungen benötigen, auf einem gemeinsamen physikalischen Servercomputer auszuführen.
Um eine gleichmäßige Auslastung der zur Verfügung stehenden Servercomputer zu erreichen, wird eine Zuteilung von virtuel- len Maschinen zu Servercomputern in der Regel durch einen so genannten Connectionbroker oder ein ähnliches Managementwerkzeug gesteuert. Der Connectionbroker sorgt unter anderem dafür, dass neu zu startende virtuelle Maschinen auf einem Ser¬ vercomputer gestartet werden, der noch ausreichend Ressourcen zu ihrer Ausführung zur Verfügung hat. Dabei setzen bekannte Virtualisierungssysteme einen gesonderten, von allen Servercomputern eines Clustersystems erreichbaren Speicherserver voraus, um die Ausführung einer virtuellen Maschine auf einem beliebigen Servercomputer zu ermöglichen.
Eine mögliche Architektur eines Virtualisierungssystem ist beispielhaft in der Figur 1 dargestellt. Im in der Figur 1 dargestellten Beispiel werden drei virtuelle Maschinen IIa, IIb und 11c auf einen gemeinsamen Servercomputer 12 ausgeführt. Neben dem in der Figur 1 dargestellten Servercomputer 12 sind weitere Servercomputer vorgesehen, die ebenfalls zur Ausführung der virtuellen Maschinen IIa bis 11c geeignet sind.
Jeder der virtuellen Maschinen IIa bis 11c ist ein eigener, virtueller Massenspeicher 13a bis 13c zugeordnet. Ein Hyper- visor oder eine andere Virtualisierungssoftware des Server- Computers 12 emuliert für die virtuellen Maschinen 11 das
Vorhandensein eines entsprechenden physikalischen Massenspeichers. Für ein auf der virtuellen Maschine IIa ausgeführtes Betriebssystem erscheint der virtuelle Massenspeicher 13a somit beispielsweise als eine lokale SCSI-Festplatte. Beim Zugriff auf den virtuellen Massenspeicher 13a ruft die Virtualisierungssoftware einen so genannten iSCSI-Initiator 14 auf. Der iSCSI-Initiator 14 erkennt, dass ein Zugriff auf den virtuellen Massenspeicher 13a gewünscht ist und leitet eine entsprechende SCSI-Anfrage über ein Datennetzwerk 15 an einen gesonderten Speicherserver 16 weiter. Auf dem Speicherserver 16 läuft eine Steuersoftware, die ein so genanntes iSCSI- Targets 17 für Anfragen der iSCSI-Initiatoren 16 bereitstellt. Das iSCSI-Target 17 leitet die empfangenen Anfragen an ein Festplattenlaufwerk 18 des Speicherservers 16 weiter. Auf diese Weise werden Anfragen sämtlicher Maschinen IIa bis 11c des Servercomputers 12 zentral durch den Speicherserver 16 beantwortet.
Ein Problem der in der Figur 1 dargestellten Architektur liegt darin, dass sämtliche Speicherzugriffe aller virtuellen Maschinen IIa bis 11c stets über das Datennetzwerk 15 stattfinden und von einer oder wenigen Festplattenlaufwerken 18 des Speicherservers 16 beantwortet werden. Somit konkurrieren die virtuellen Maschinen IIa bis 11c um Bandbreite in dem Datennetzwerk 15. Zudem können konkurrierende Anfragen nur nacheinander durch den Speicherserver 16 beantwortet werden. Wird das in der Figur 1 dargestellte Clustersystem 10 durch das Zufügen weiterer Servercomputer 12 zum Ausführen weiterer virtueller Maschinen 11 erweitert, wächst nicht nur die Anforderung nach Speicherkapazität auf dem Festplattenlaufwerk 18 des Speicherservers 16, sondern auch die mit dem Zugriff auf die virtuellen Massenspeicher 13 verbundene Latenzzeit.
Aufgabe der vorliegenden Erfindung ist es, ein Clustersystem und ein Arbeitsverfahren für ein Clustersystem zu beschreiben, bei dem die Latenzzeit für den Zugriff auf virtuelle Massenspeicher einer virtuellen Maschine verringert wird. Bevorzugt sollen sich die beschriebenen Lösungen zur flexiblen Erweiterung von Clustersystemen ohne die damit einhergehenden Leistungseinbußen bekannter Systeme eignen. Gemäß einem ersten Aspekt der Erfindung wird ein Clustersystem beschrieben. Das Clustersystem weist eine Mehrzahl von Servercomputern mit jeweils wenigstens einem Prozessor, wenigstens einem lokalen Massenspeicher sowie wenigstens einer Netzwerkkomponente, und ein Datennetzwerk auf, über das die Netzwerkkomponenten der Mehrzahl von Servercomputern datentechnisch gekoppelt sind. Das Clustersystem ist zum Ausführen einer Mehrzahl von virtuellen Maschinen eingerichtet, wobei jeder der virtuellen Maschinen wenigstens ein virtueller Massenspeicher zugeordnet ist. Dabei sind für jede virtuelle Ma- schine eine erste Kopie der Daten des zugeordneten virtuellen Massenspeichers auf dem wenigstens einen lokalen Massenspei¬ cher eines ersten Servercomputers und eine zweite Kopie der Daten des zugeordneten virtuellen Massenspeichers auf dem we- nigstens einen lokalen Massenspeicher eines zweiten Servercomputers der Mehrzahl von Servercomputern gespeichert. Beim Ausführen einer aktiven virtuellen Maschine der Mehrzahl von virtuellen Maschinen durch den wenigstens einen Prozessors des ersten Servercomputers werden Datenzugriffe der aktiven virtuellen Maschine auf den ihr zugeordneten wenigstens einen virtuellen Massenspeicher auf den lokalen Massenspeicher des ersten Servercomputers umgeleitet. Beim Ausführen der aktiven virtuellen Maschine durch den wenigstens einen Prozessor des zweiten Servercomputers werden Massenspeicherzugriffe der ak¬ tiven virtuellen Maschine auf den ihr zugeordneten wenigstens einen virtuellen Massenspeicher auf den lokalen Massenspeicher des zweiten Servercomputers umgeleitet. Änderungen der ersten oder der zweiten Kopie der Daten des virtuellen Mas- senspeichers der aktiven virtuellen Maschine werden dabei über das Datennetzwerk mit der zweiten beziehungsweise der ersten Kopie synchronisiert.
In dem offenbarten Clustersystem werden Kopien der virtuellen Massenspeicher auf wenigstens zwei Servercomputern abgelegt. Die lokalen Massenspeicher der Servercomputer werden dabei als virtuelle Massenspeicher für die virtuellen Maschinen verwendet. Durch lokale Massenspeicherzugriffe werden unnöti¬ ge Transporte über ein Datennetzwerk vermieden, was die La- tenzzeiten von Datenzugriffen verringert und die Anzahl der
Zugriffe auf die lokalen Massenspeicher der Mehrzahl von Servercomputern verteilt. Zur Vermeidung von Dateninkonsistenzen und zur Ermöglichung der Verschiebung von virtuellen Maschinen von einem Servercomputer auf den anderen werden die lokal durchgeführten Änderungen von einem Servercomputer auf den anderen Servercomputer synchronisiert. Die Erfindung macht sich die Erkenntnis zunutze, dass in Ser¬ vercomputern in der Regel lokale Massenspeicher, insbesondere Festplatten, zum Start eines Host-Betriebssystems beziehungs¬ weise eines Hypervisors vorhanden sind. Deren Leistung liegt in der Regel jedoch brach, da das Betriebssystem beziehungsweise der Hypervisor des Servercomputers ein verhältnismäßig geringeres Speichervolumen einnimmt und nur wenige Zugriffe auf den lokalen Massenspeicher erfordert. Im Ergebnis wird durch das beschriebene Clustersystem eine Verringerung der Latenzzeit beim Zugriff auf virtuelle Mas¬ senspeicher einer virtuellen Maschine bewirkt, wobei gleichzeitig eine verbesserte Skalierbarkeit des Clustersystems insgesamt hergestellt wird. Insbesondere wächst sowohl die Leistung als auch die Kapazität der zur Verfügung stehenden
Massenspeicher durch das Hinzufügen von weiteren Servercomputern an, ohne dass hierzu gesonderte und besonders leistungs¬ fähige Speicherserver erforderlich werden. Zur effektiven Durchführung der Synchronisierung weist in einer bevorzugten Ausgestaltung jeder der Mehrzahl der Servercomputer ein Synchronisationsmodul auf. Dabei ist das Syn¬ chronisationsmodul des ersten Servercomputers dazu eingerich¬ tet, für einen bestimmten Zeitraum oder einen bestimmten Da- tenumfang die Änderungen der ersten Kopie der Daten des virtuellen Massenspeichers der aktiven virtuellen Maschine zusammenzufassen und gemeinsam an den zweiten Servercomputer zu übertragen. Durch die Zusammenfassung von Änderungen kann der Netzwerkverkehr über ein zur Kopplung verwendetes Datennetz- werk weiter reduziert werden.
Gemäß einer weiteren vorteilhaften Ausgestaltung wird durch wenigstens einen der Servercomputer, insbesondere durch eine auf dem wenigstens einen Servercomputer ausgeführte virtuelle Maschine, eine Speicherserversoftware ausgeführt. Dabei ist die Speicherserversoftware dazu eingerichtet ist, den Inhalt der virtuellen Massenspeicher der Mehrzahl von virtuellen Ma- schinen über das Datennetzwerk bereitzustellen. Durch die Ausführung einer Speicherserversoftware durch einen Servercomputer des Clustersystems wird die Synchronisation der virtuellen Massenspeicher vereinfacht, eine Kompatibilität mit bestehenden Virtualisierungssystemen verbessert und gleich- zeitig sichergestellt, dass eine virtuelle Maschine auf einem beliebigen Servercomputer des Clustersystems erfolgreich gestartet werden kann. Durch die Virtualisierung eines Speicherservers kann auf die zusätzliche Vorsehung eines geson¬ dert konfigurierten oder ausgerüsteten Datenservers oder Ser- vercomputers verzichtet werden.
Gemäß einer weiteren vorteilhaften Ausgestaltung weist jeder der Mehrzahl der Servercomputer einen Filtertreiber auf, wobei der Filtertreiber dazu eingerichtet ist, Massenspeicher- Zugriffe von einer durch den wenigstens einen Prozessor des Servercomputers lokal ausgeführten virtuellen Maschine abzu¬ fangen und auf die erste Kopie der Daten des wenigstens einen virtuellen Massenspeichers auf dem lokalen Massenspeicher umzuleiten .
Gemäß einem zweiten Aspekt der Erfindung wird ein Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen auf einer Mehrzahl von Servercomputern beschrieben. Das Verfahren umfasst die Schritte:
- Starten einer ersten virtuellen Maschine auf einem ersten Servercomputer mit einem ersten lokalen Massenspeicher - Starten einer zweiten virtuellen Maschine auf einem zweiten Servercomputer mit einem zweiten lokalen Massenspeicher
- Empfangen einer ersten Schreibanforderung von der ersten virtuellen Maschine
- Durchführen der ersten Schreibanforderung zur Änderung von ersten Daten auf dem ersten lokalen Massenspeicher
- Empfangen einer zweiten Schreibanforderung von der zweiten virtuellen Maschine
- Durchführen der zweiten Schreibanforderung zur Änderung von zweiten Daten auf dem zweiten lokalen Massenspeicher
- Synchronisieren der geänderten ersten Daten zwischen dem ersten Servercomputer und dem zweiten Servercomputer über ein Datennetzwerk und
- Synchronisieren der geänderten zweiten Daten zwischen dem zweiten Servercomputer und dem ersten Servercomputer über das Datennetzwerk.
Durch die beschriebenen Verfahrensschritte wird eine lokale Speicherung von Daten virtueller Maschinen bei gleichzeitiger Herstellung einer Redundanz auf jeweils einem anderen lokalen Massenspeicher eines zweiten Servercomputers bewirkt.
Gemäß unterschiedlichen Ausgestaltungen des Verfahrens wird die Synchronisation der ersten Daten beziehungsweise der zweiten Daten paketweise zusammengefasst und/oder transakti¬ onsorientiert durchgeführt.
Gemäß einer weiteren vorteilhaften Ausgestaltung umfasst das Verfahren zusätzlich die Schritte:
- Anhalten der ersten virtuellen Maschine auf dem ersten ServerComputer _
- y —
- Warten, bis der Schritt des Synchronisierens der ersten geänderten Daten abgeschlossen ist, und
- nachfolgendes Starten der ersten virtuellen Maschine auf dem zweiten Servercomputer.
Durch die genannten Schritte kann eine virtuelle Maschine von einem Servercomputer auf einen anderen Servercomputer des Clustersystems übertragen werden, ohne dass es zu Inkon- sistenzen in den Daten des virtuellen Massenspeichers kommt.
Weitere vorteilhafte Ausgestaltungen der Erfindung sind in den angehängten Patentansprüchen sowie der nachfolgenden Beschreibung von Ausführungsbeispielen offenbart. Die Erfindung wird nachfolgend anhand unterschiedlicher Aus¬ führungsbeispiele unter Bezugnahme auf die angehängten Figu¬ ren näher erläutert.
In den Figuren zeigen:
Figur 1 eine Architektur eines Clustersystems mit einem ge¬ sonderten Speicherserver,
Figur 2 eine Architektur eines Clustersystems gemäß einer
Ausgestaltung der vorliegenden Erfindung, einen Clustersystem mit drei Servercomputern gemäß einer Ausgestaltung der vorliegenden Erfindung, Figur 4 ein Ablaufdiagramm eines Verfahrens zum parallelen
Ausführen von zwei virtuellen Maschinen, Figur 5 ein Ablaufdiagramm eines Verfahrens zum Verschieben einer virtuellen Maschine sowie
Figuren 6A und 6B ein Ablaufdiagramm eines Verfahrens zum
Synchronisieren von virtuellen Massenspeichern.
In der nachfolgenden, ausführlichen Beschreibung werden einheitliche Bezugszeichen für gleiche oder gleichartige Kompo¬ nenten unterschiedlicher Ausführungsbeispiele verwendet. Dar¬ über hinaus werden unterschiedliche Instanzen gleichartiger Komponenten durch das Anhängen eines alphabetischen Suffixes unterschieden. Sofern die Beschreibung nicht auf eine besondere Instanz einer Komponente bezogen ist, wird das jeweilige Bezugszeichen ohne das angehängte Suffix verwendet.
Figur 2 zeigt ein Clustersystem 20 mit einem ersten Servercomputer 12a, einem zweiten Servercomputer 12b sowie weiteren, nicht im Detail dargestellten Servercomputern 12. Die Servercomputer 12 sind über ein gemeinsames Datennetzwerk 15 miteinander verbunden. Der Aufbau des Clustersystems 20 äh¬ nelt dem Aufbau des Clustersystems 10 gemäß Figur 1. Davon abweichend wird in der Architektur gemäß Figur 2 kein gesonderter Speicherserver eingesetzt. Stattdessen läuft im dargestellten Ausführungsbeispiel aus Kompatibilitätsgründen auf dem Servercomputer 12a eine Speicherserversoftware in einer virtuellen Maschine IIa auf dem ersten Servercomputer 12a ab. Neben der virtuellen Maschine IIa können weitere virtuelle Maschinen IIb bis 11c durch den ersten Servercomputer 12a bereitgestellt werden.
Weitere virtuellen Maschinen lld bis llf werden im Ausführungsbeispiel durch den Servercomputer 12b ausgeführt. Greift eine der virtuellen Maschinen lld bis llf auf einen ihr zuge- ordneten, virtuellen Massenspeicher 13d bis 13f zu, fängt ein Filtertreiber 21 den entsprechenden Massenspeicherzugriff ab. Der Filtertreiber 21 leitet die Speicheranfrage nicht, wie unter Bezugnahme auf die Figur 1 beschrieben, an den iSCSI- Initiator 14 weiter, sondern leitet die Anfrage an einen lokalen Massenspeicher 22b, insbesondere ein eingebautes Fest¬ plattenlaufwerk, des Servercomputers 12b um. Dabei ist auf dem lokalen Massenspeicher 22b jeweils eine erste Kopie 24d bis 24f der virtuellen Massenspeichers 13d bis 13f gespei- chert. Im Ausführungsbeispiel handelt es sich bei den Kopien 24d bis 24f um Kopien eines von einer Virtualisierungsschicht 23 verwendeten, so genannten virtuellen Festplattencontainers . Solange die virtuellen Maschinen lld bis llf nicht von dem Servercomputer 12b auf einen der anderen Servercomputer 12 verschoben werden, erfolgen sämtliche Zugriffe über den Filtertreiber 21 auf die lokalen ersten Kopien 24d bis 24f des lokalen Massenspeichers 22b des Servercomputers 12b. Somit kann auf Zugriffe auf das Datennetzwerk 15 weitgehend ver¬ zichtet werden, was insbesondere die Latenzzeiten beim Mas¬ senspeicherzugriff der virtuellen Maschinen lld bis llf verringert . Um eine Ausfallsicherheit gegenüber einem Versagen des Servercomputers 12b beziehungsweise der darin eingebauten Kompo¬ nenten wie insbesondere des lokalen Massenspeichers 22b zu gewährleisten, werden die Inhalte der virtuellen Massenspeicher 13d bis 13f, die in den Kopien 24d bis 24f auf dem loka- len Massenspeicher 22b gespeichert sind, auf wenigstens einem entfernten Massenspeicher, im Ausführungsbeispiel dem lokalen Massenspeicher 22a des ersten Servercomputers 12a, in zweiten Kopien 25d bis 25f gespiegelt. Dies ermöglicht zugleich die Verschiebung einzelner oder aller der virtuellen Maschinen lld bis llf auf den Servercomputer 12a.
Im Ausführungsbeispiel erfolgt eine Synchronisation der Ko- pien 24 und 25 durch einen Hintergrundtask, der regelmäßig auf jedem der Servercomputer 12 ausgeführt wird. Zur Vereinfachung der Synchronisation und zum Erhalt einer Kompatibilität mit bestehenden Clustersoftware erfolgt die Datenübertra¬ gung dabei wie unter Bezugnahme auf die Figur 1 beschrieben mittels eines iSCSI-Initiator 14 auf Seiten des zweiten Servercomputers 12b und eines iSCSI-Targets 17 auf Seiten des ersten Servercomputers 12a, der die Speicherserversoftware ausführt. Die auf dem ersten Servercomputer 12a ausgeführte Speicherserversoftware stellt, wie unter Bezugnahme auf die Figur 1 erläutert, die virtuellen Massenspeicher 13d bis 13f über das Datennetzwerk 15 zur Verfügung. Diese werden von den übrigen Servercomputern 12, insbesondere dem zweiten Servercomputer 12b als Netzlaufwerke eingebunden. Der auf dem zwei¬ ten Servercomputer 12b ausgeführte Hintergrundtask gleicht dann die ersten Kopien 24d bis 24f mit den über das Datennetzwerk 15 bereitgestellten zweiten Kopien 25d bis 25f der virtuellen Massenspeicher 13d bis 13f ab.
Bevorzugt werden alle Änderungen an einer ersten Kopie 24 für einen bestimmten Zeitraum von beispielsweise 15 Sekunden oder einer Minute oder in einem bestimmten Umfang, beispielsweise geänderten Blöcke oder Sektoren mit einer Gesamtgröße von einem Megabyte, in einer Update-Nachricht zusammengefasst und gesammelt oder blockweise über den iSCSI-Initiator 14 an des iSCSI-Target 17 des ersten Servercomputers 12a übertragen.
Alternativ kann eine Synchronisation auch dann erfolgen, wenn eine besonders niedrige Auslastung des ersten oder zweiten Computersystems 12a bzw. 12b, des Datennetzwerkes 15 und/oder der Massenspeicher 22a bzw. 22b erkannt wird. Das iSCSI- Target 17 des ersten Servercomputers 12a aktualisiert darauf¬ hin die zweite Kopien 25 der virtuellen Massenspeicher 13 auf dem lokalen Massenspeicher 22a.
Obwohl dies in der Figur 2 aus Gründen der Übersichtlichkeit nicht dargestellt ist, sind den virtuellen Maschinen IIa bis 11c ebenfalls virtuelle Massenspeicher 13a bis 13c zugeord¬ net, deren Inhalte als erste Kopie 24 auf dem lokalen Massen- Speicher 22a des ersten Servercomputers 12a und als zweite
Kopie 25 auf mindestens einem lokalen Massenspeicher 22 eines anderen Servercomputers 12 gespeichert sind und in äquivalen¬ ter Weise synchronisiert werden.
Figur 3 zeigt ein weiteres beispielhaftes Clustersystem 30, das für eine Desktop-Virtualisierung verwendet wird. Das Clustersystem 30 umfasst im dargestellten Ausführungsbeispiel drei Servercomputer 12a bis 12c, durch die insgesamt sechs virtuelle Desktops 31a bis 31f bereitgestellt werden. Jeder der virtuellen Desktops 31 wird durch eine ihm zugeordnete virtuelle Maschine 11 implementiert, der wenigstens ein vir¬ tueller Massenspeicher 13 zugeordnet ist. Aus Gründen der Übersichtlichkeit sind die virtuellen Maschinen 11 und virtu¬ ellen Massenspeicher 13 in der Figur 3 jedoch nicht dargestellt.
Im Ausführungsbeispiel umfasst jeder Servercomputer 12 eine oder mehrere lokale Massenspeicher 22, wie insbesondere eine interne Festplatte, einen Filtertreiber 21 sowie ein Synchro- nisationsmodul 32. Zusätzlich ist auf jedem der Servercompu¬ ter 12 eine Speicherserversoftware 33 zur Bereitstellung der Funktionalität eines konventionellen Speicherservers 16 ein¬ gerichtet. Die Speicherserversoftware 33 wird zu jedem Zeit- punkt jedoch nur durch einen der drei Servercomputer 12a bis 12c ausgeführt, beispielsweise den ersten Servercomputer 12a. Bei Ausfall des ersten Servercomputers 12a wird durch einen Administrationsservice 34 die Speicherserversoftware 33 auf einem der anderen Servercomputer 12b oder 12c aktiviert, so dass dieser Servercomputer 12b beziehungsweise 12c jederzeit die Funktion des Servercomputers 12a übernehmen kann.
Der Administrationsservice 34 dient des Weiteren zum Vertei- len der virtuellen Desktops 31 auf die Servercomputer 12. Im dargestellten Ausführungsbeispiel sind die virtuellen Desktops 31a bis 31f gleichmäßig über die drei Servercomputer 12a bis 12c verteilt. Insbesondere werden die virtuellen Desktops 31a und 31b durch den ersten Servercomputer 12a, die virtuel- len Desktops 31c und 31d durch den zweiten Servercomputer 12b und die virtuellen Desktops 31e und 31f durch den dritten Servercomputer 12c gehostet.
Im Clustersystem 30 gemäß Figur 3 reicht die Speicherkapazi- tät der lokalen Massenspeicher 22a bis 22c aus, um die virtu¬ ellen Massenspeicher 13 jedes der virtuellen Desktops 31a bis 31f vorzuhalten. Um die Ausführung jedes der virtuellen Desktops 31a bis 31e auf jedem der Servercomputer 12a bis 12c zu ermöglich, sind die virtuellen Massenspeicher 13 der virtuel- len Desktops 31a bis 31f auf jedem der Massenspeicher 22a bis 22c in Kopie gespeichert. Mittels des Administrationsservice 34 und des Synchronisationsmoduls 32 erfolgt dabei jeweils eine Synchronisierung der Inhalte der virtuellen Massenspeicher 13.
Im dargestellten Ausführungsbeispiel werden Änderungen am Inhalt der virtuellen Massenspeicher 13, die durch die auf dem ersten Servercomputer 12a aktiven virtuellen Desktops 31a und 31b verursacht werden, über eine Broadcast-Mitteilung des Datennetzwerks 15 an die Servercomputer 12b und 12c verteilt. Die Servercomputer 12b und 12c aktualisieren dann ihre korrespondierenden Kopien der zugehörigen virtuellen Massenspei- eher 13 entsprechend. Dies ist in der Figur 3 für den ersten virtuellen Desktop 31a beispielhaft durch die Pfeile angedeu¬ tet. Umgekehrt werden Änderungen an den virtuellen Massenspeichern 13 der virtuellen Desktops 31c und 31d per Broad- cast von dem zweiten Servercomputer 12b an die Servercomputer 12a und 12c übertragen. Die Änderungen der virtuellen Massenspeicher 13 der virtuellen Desktops 31e und 31f werden entsprechend von dem dritten Servercomputer 12c an die Servercomputer 12a und 12b übertragen. Um die Bandbreite der einzelnen lokalen Massenspeicher 12 zwischen durch die Synchronisation verursachte und durch einen lokalen Nutzer des Massenspeichers 12 verursachten
Zugriffen fair zu verteilen, werden die zur Synchronisation verwendeten Anforderungen in einer Ausgestaltung nicht sofort synchronisiert, sondern auf Anforderung des Synchronisations¬ moduls 32 oder des Administrationsservices 34 Block für Block übertragen .
Ein konkreter Ablauf der Synchronisation sowie ein Verschie- ben von virtuellen Maschinen 11 und damit den durch Sie bereitgestellten virtuellen Desktops 31 von einem Servercomputer 12 auf einen anderen Servercomputer 12 wird nachfolgend anhand der Flussdiagramme der Figuren 4 bis 6 beschrieben. Figur 4 zeigt ein Ablaufdiagramm eines Verfahrens 40 zum Be¬ trieb eines Clustersystems , beispielsweise eines der Cluster- systeme 20 oder 30. In der linken Hälfte der Figur 4 sind die Schritte dargestellt, die von einem ersten Servercomputer 12a des Clustersystems ausgeführt werden. In der rechten Hälfte der Figur 4 sind die Schritte dargestellt, die von einem zweiten Servercomputer 12b ausgeführt werden. Wegen der parallelen Ausführung der Verfahrensschritte auf zwei unterschiedlichen Servercomputern 12 laufen diese zeitlich nicht synchronisiert zueinander ab. Lediglich bei der Synchronisation von Änderungen an Inhalten eines virtuellen Massenspeichers 13 findet eine nachfolgend näher beschriebene Synchronisation zwischen dem ersten Servercomputer 12a und dem zweiten Servercomputer 12b statt.
In einem ersten Schritt 41a wird eine erste virtuelle Maschi¬ ne IIa gestartet. Beispielsweise wird ein Windows- Betriebssystem für einen Benutzer gestartet, der mittels
Desktop-Virtualisierung auf eine virtuelle Maschine IIa zu¬ greift. In einem Schritt 42a empfängt eine Managementsoftware des Servercomputers 12a, beispielsweise ein auf dem Server¬ computer 12a ausgeführter Hypervisor, eine Schreibanfrage der ersten virtuellen Maschine IIa. Beispielsweise möchte ein Be¬ nutzer ein geändertes Textdokument auf einem virtuellen Mas¬ senspeicher 13a seiner virtuellen Maschine IIa ablegen. Diese Anforderung wird im Schritt 43a zunächst lokal umgesetzt. Zu diesem Zweck wird der Schreibbefehl durch einen Filtertreiber 21 des Servercomputers 12a abgefangen und in einen lokalen
Schreibbefehl für den lokalen Massenspeicher 22a umgewandelt.
Parallel dazu werden in den Verfahrensschritten 41b bis 43b entsprechende Operationen für eine zweite virtuelle Maschine IIb auf einem zweiten Servercomputer 12b durchgeführt. Ände¬ rungen der zweiten virtuellen Maschine IIb an dem virtuellen Massenspeicher 13b werden dabei zunächst wiederum auf einem lokalen Massenspeicher 22b des zweiten Servercomputers 12b durchgeführt .
In einem Schritt 44a, beispielsweise nach Ablauf einer vorbe- stimmten Zeit oder nach dem Auflaufen einer vorbestimmten Zahl von Änderungen, fast der erste Servercomputer 12a die bisher durch die virtuelle Maschine IIa vorgenommenen Ände¬ rungen zusammen und überträgt eine entsprechende erste Aktua¬ lisierungsnachricht an den zweiten Servercomputer 12b. Der zweite Servercomputer 12b empfängt die erste Aktualisierungs¬ nachricht in einem Schritt 45b und aktualisiert seine Kopie des virtuellen Massenspeichers 13a der ersten virtuellen Maschine IIa entsprechend. Umgekehrt überträgt der zweite Ser¬ vercomputer 12b in einem Schritt 44b die bisher aufgelaufenen Änderungen der zweiten virtuellen Maschine IIb an deren Kopie 24 des virtuellem Massenspeicher 13b auf dem lokalen Massenspeicher 22b und überträgt diese in Form einer zweiten Aktua¬ lisierungsnachricht an den ersten Servercomputer 12a. In einem Schritt 45a aktualisiert der erste Servercomputer 12a seine Kopie des virtuellen Massenspeichers 13b der zweiten virtuellen Maschine IIb entsprechend.
Figur 5 zeigt schematisch ein Verfahren 50 zum Verschieben einer virtuellen Maschine 11 von einem ersten Servercomputer 12a zu einem zweiten Servercomputer 12b. Wie in der Figur 4 sind die Schritte des ersten Servercomputers 12a auf der lin¬ ken Seite der Figur 5 und die Verfahrensschritte des zweiten Servercomputers 12b auf der rechten Seite der Figur 5 abge¬ bildet .
In einem ersten Schritt 51 wird die Ausführung der virtuellen Maschine 11 auf dem ersten Computer 12a angehalten. Beispielsweise wird durch einen Administrationsservice 34 oder einen Hypervisor der virtuellen Maschine 11 keine weitere Prozessorzeit mehr zugeteilt.
In einem Schritt 52 werden dann die bis dahin aufgelaufenen Änderungen an einem virtuellen Massenspeicher 13, der der virtuellen Maschine 11 zugeordnet ist, in einer Aktualisie¬ rungsnachricht zusammengefasst . Die Aktualisierungsnachricht wird von dem ersten Servercomputer 12a an den zweiten Servercomputer 12b übertragen. Dieser aktualisiert in einem Schritt 53 seine lokale Kopie 25 des virtuellen Massenspeichers 13 der virtuellen Maschine 11 entsprechend den Änderungen der Aktualisierungsnachricht .
Sodann kann in einem Schritt 54 die Ausführung der virtuellen Maschine 11 auf dem zweiten Servercomputer 12b fortgeführt werden. In einer Ausgestaltung ist in der Aktualisierungsnachricht und/oder auf dem virtuellen Massenspeicher 13 auch der aktuelle Zustand des Arbeitsspeichers der virtuellen Ma¬ schine 11 enthalten, so dass dieser in den Schritten 52 und 53 zwischen den Servercomputern 12a und 12b synchronisiert wird. Alternativ wird der aktuelle Zustand des Arbeitsspei¬ chers von einer vorhandenen Clustersoftware, beispielsweise dem Administrationsservice 34 übertragen. In beiden Fällen startet die virtuelle Maschine 11 im Schritt 54 in genau dem- selben Zustand, in dem sie im Schritt 51 gestoppt wurde, also beispielsweise mit der Ausführung derselben Anwendungen und denselben geöffneten Dokumenten. Für einen Nutzer der virtuellen Maschine 11 ist somit kein Unterschied zwischen der Ausführung der virtuellen Maschine 11 auf dem ersten Server- Computer 12a beziehungsweise dem zweiten Servercomputer 12b wahrnehmbar . In einer weiteren, nicht dargestellten Ausgestaltung wird die Synchronisation des virtuellen Massenspeichers 13 zwischen einem lokalen Massenspeicher 22a des ersten Servercomputers 12a und einem lokalen Massenspeicher 22b des zweiten Server- Computers 12b parallel zum Betrieb der virtuellen Maschine 11 vorgenommen. Beispielsweise können Teile oder der gesamte Inhalt des virtuellen Massenspeichers 13 vor dem Anhalten der virtuellen Maschine 11 im an den zweiten Servercomputer 12b übertragen werden. Es ist auch möglich, die virtuelle Maschi- ne 11 zeitnah zum Anhalten der virtuellen Maschine 11 auf dem ersten Servercomputer 12a auf dem zweiten Servercomputer 12b zu starten, und eine Synchronisation des zugehörigen virtuellen Massenspeichers 13 erst nachfolgend, das heißt während der Ausführung der virtuellen Maschine 11 durch den zweiten Servercomputer 12b, vorzunehmen. Gegebenenfalls können dabei Inhalte, die noch nicht auf dem lokalen Massenspeicher 22b des zweiten Servercomputers 12b übertragen wurden, für eine Übergangszeit über das Datennetzwerk 15 von dem lokalen Massenspeicher 22a des ersten Servercomputers 12a gelesen wer- den.
In den Figuren 6A und 6B ist der Ablauf eines möglichen Synchronisationsverfahren 60 zum Abgleichen von Kopien 24 und 25 eines virtuellen Massenspeichers 13 zwischen zwei verschiede- nen Servercomputern 12a und 12b schematisch dargestellt.
In einem ersten Schritt 61 wird ein Zeitgeber oder sonstiger Zähler des ersten Servercomputers 12a zurückgesetzt. In einem nachfolgenden Schritt 62 wird überprüft, ob ein vorbestimmtes Zeitintervall T, beispielsweise ein Zeitintervall von einer Minute, bereits abgelaufen oder ein Zählereignis, beispiels¬ weise eine Änderung von 1000 Blöcken oder Sektoren eines virtuellen Massenspeichers 13 bereits eingetreten ist. Ist dies nicht der Fall, wird in einem Schritt 63 überprüft, ob eine Lese- oder Schreibanforderung einer lokal ausgeführten virtuellen Maschine 11 von dem zweiten Servercomputer 12a erfasst wurde. Ist dies nicht der Fall, wird das Verfahren im Schritt 62 fortgesetzt.
Andernfalls wird im Schritt 64 die Art der erfassten Anforde¬ rung der virtuellen Maschine 11 überprüft. Handelt es sich um eine Leseanforderung, wird im Schritt 65 die entsprechende Leseanforderung an den lokalen Massenspeicher 22a des Servercomputers 12a weitergeleitet und von diesem anhand einer lo¬ kalen ersten Kopie 24 des virtuellen Massenspeichers 13 be¬ antwortet. Da durch eine Leseanforderung keine Inkonsistenz zwischen unterschiedlichen Kopien 24 und 25 des virtuellen Massenspeichers 13 verursacht werden, kann das Verfahren ohne die Durchführung weiterer Maßnahmen im Schritt 62 fortgesetzt werden .
Wird im Schritt 64 jedoch erkannt, dass ein Schreibbefehl vorliegt, wird in einem Schritt 66 ein zu schreibender Block oder Sektor der lokalen Kopie des virtuellen Massenspeichers 13 in einer geeigneten Datenstruktur als geändert markiert. Beispielsweise speichert der Filtertreiber 21 in einer Bele¬ gungsliste im Arbeitsspeicher, in einer Tabelle des Synchro- nisationsmoduls 32 oder in geeigneten Metadaten des zugehörigen Dateisystems eine Adresse eines jeden lokal überschrieben Blocks. Nachfolgend wird die Schreibanforderung im Schritt 67 auf dem lokalen Massenspeicher 22a des Servercomputers 12a durchgeführt und das Verfahren wiederum im Schritt 62 fortge- setzt.
Tritt das vorbestimmte Synchronisierungsereignis im Schritt 62 schließlich ein, wird die erste Kopie 24 des virtuellen Massenspeichers 13 auf dem lokalen Massenspeicher 22a mit ei¬ ner korrespondieren zweiten Kopie 25 auf dem lokalen Massenspeicher 22b des zweiten Servercomputers 12b synchronisiert. Hierzu werden insbesondere die Schritte 68 bis 75 gemäß Figur 6B verwendet.
In einem Schritt 68 stellt der erste Servercomputer 12a eine Aktualisierungsnachricht mit sämtlichen geänderten Inhalten des virtuellen Massenspeichers 13 zusammen. Beispielsweise werden die Inhalte sämtlicher in der im Schritt 66 als geändert markierte Blöcke oder Sektoren der ersten Kopie 24 des virtuellen Massenspeichers 13 zusammen mit geeigneten Adressinformationen in einer Aktualisierungsnachricht zusammenge¬ stellt.
In einem nachfolgenden Schritt 69 wird die Aktualisierungs¬ nachricht von dem ersten Servercomputer 12a über das Datennetzwerk 15 an den zweiten Servercomputer 12b und gegebenenfalls zu weiteren Servercomputern 12 übertragen, die eben- falls eine lokale Kopie des virtuellen Massenspeichers 13 der virtuellen Maschine 11 vorhalten. Zur Reduktion von Netzwerkverkehr erfolgt die Übertragung bevorzugt mittels eines
Broadcast-Mechanismus . Nachfolgend wartet der erste Server¬ computer 12a im Schritt 70 optional ab, ob der zweite Server- Computer 12b und gegebenenfalls weitere Servercomputer 12 die Synchronisation wie angefordert vorgenommen und bestätigt ha¬ ben .
Parallel dazu empfängt der zweite Servercomputer 12b in einem Schritt 71 zunächst die im Schritt 69 verschickte Aktualisie¬ rungsnachricht und legt diese auf dem lokalen Massenspeicher 22b ab. Anhand der in der Aktualisierungsnachricht enthalte¬ nen Informationen überprüft der zweite Servercomputer 12b, ob er eine lokale Kopie 25 des virtuellen Massenspeichers 13 der virtuellen Maschine 11 vorhält. Ist dies der Fall, übernimmt er die geänderten Blöcke oder Sektoren in einem Schritt 72, so dass sich nachfolgend die zweite Kopie 25 des virtuellen Massenspeichers 13 der virtuellen Maschine 11 auf dem lokalen Massenspeicher 22b des zweiten Servercomputers 12b in Übereinstimmung mit der ersten Kopie 24 auf dem lokalen Massenspeicher 22a des ersten Servercomputers 12a befindet. Tritt dabei ein Fehler auf, wie beispielsweise eine Unterbrechung der Stromversorgung, kann die Aktualisierung anhand der lokal gespeicherten Daten zu einem späteren Zeitpunkt wiederholt oder fortgesetzt werden.
In einem Schritt 73 wird optional überprüft, ob während der Synchronisation Probleme auftraten. Beispielsweise kann die Aktualisierungsnachricht nur unvollständig oder fehlerhaft empfangen worden sein. Ist dies der Fall, wird in einem
Schritt 74 die erneute Übertragung der Aktualisierungsnachricht von dem ersten Servercomputer 12a angefordert. Andern- falls wird bevorzugt eine Bestätigungsnachricht über die durchgeführte Synchronisation des lokalen Massenspeichers 22b erstellt. Diese Bestätigungsnachricht wird in einem Schritt 75 von dem ersten Servercomputer 12a empfangen, womit der Synchronisationsvorgang abgeschlossen ist und das Verfahren erneut im Schritt 61 fortgesetzt wird. Wird nach einem vorbe¬ stimmten Zeitraum dagegen keine Bestätigungsnachricht von dem zweiten Servercomputer 12b empfangen, geht der erste Servercomputer 12a davon aus, dass die Synchronisation nicht erfolgreich durchgeführt wurde und sendet im Schritt 69 erneut eine Aktualisierungsnachricht aus. Alternativ oder zusätzlich kann die Durchführung der Synchronisation auch durch einen zentralen Dienst der Speicherserversoftware koordiniert wer¬ den . In der beschriebenen Ausgestaltung werden die Schritte 68 bis 75 durch das Synchronisationsmodul 32 oder den Administrati¬ onsservice 34 des ersten Servercomputer 12a koordiniert. Wäh- rend der Aktualisierung wird der Zustand der ersten Kopie 24 eingefroren. Beispielsweise werden durch einen Filtertreiber weitere Schreibzugriffe auf die erste Kopie 24 ausgesetzt oder lokal zwischengespeichert, bis die Synchronisation abge¬ schlossen ist.
Die beschriebenen Clustersysteme und Arbeitsverfahren lassen sich in vielfältiger Weise miteinander kombinieren und ergänzen, um unterschiedliche Ausgestaltungen der Erfindung in Abhängigkeit der vorherrschenden Anforderungen zu erhalten.
In einer beispielhaften Ausgestaltung werden sämtliche virtuelle Massenspeicher 13 jeder virtuellen Maschine 11 auf sämtlichen lokalen Massenspeicher 22 eines jeden Servercomputers 12 eines Clustersystems vorgehalten und miteinander synchro- nisiert, so dass jede virtuelle Maschine 11 auf jedem Server¬ computer 12 ausgeführt werden kann und gleichzeitig eine zu¬ sätzliche Datenredundanz geschaffen wird. In einer anderen Ausgestaltung werden virtuelle Massenspeicher 13 von einer Untermenge der virtuellen Maschinen 11 auf einer Untergruppe der Servercomputer 12 vorgehalten, so dass die entsprechenden virtuellen Maschinen 11 auf jedem der Servercomputer 12 der Untergruppe ausgeführt werden können. Bei dieser Ausgestal¬ tung handelt es sich um einen Kompromiss bezüglich der Anforderung an die Größe der lokalen Massenspeicher 22 und der Flexibilität der Ausführung der einzelnen virtuellen Maschinen 11. In einer weiteren Ausgestaltung existieren jeweils genau zwei Kopien eines virtuellen Massenspeichers 13 auf zwei unterschiedlichen Servercomputern 12a und 12b, sodass die redundante Ausführung einer jeden virtuellen Maschine 11 beim Ausfall eines beliebigen Servercomputers 12 sicherge¬ stellt ist. Der beschriebene Ansatz führt zu einer Reihe von weiteren
Vorteilen. Beispielsweise muss der Servercomputer 12, auf dem die Speicherserversoftware 33 ausgeführt wird, nicht mehr be¬ sonders gegen Ausfälle gesichert werden, weil seine Funktion von jedem Servercomputer 12 des Clustersystems übernommen werden kann. Durch die gleichzeitige Verteilung von Datenzugriffen auf eine Mehrzahl von Massenspeichern kann auf den Einsatz von Spezialhardware, wie insbesondere Hochleistungs¬ netzwerkkomponenten und -festplatten sowie RAID-Systemen verzichtet werden.
Bezugs zeichenliste
10 Clustersystem
11 virtuelle Maschine
12 ServerComputer
13 virtueller Massenspeicher
14 iSCSI-Initiator
15 Datennetzwerk
16 SpeieherServer
17 iSCSI-Target
18 Festplattenlaufwerk
20 Clustersystem
21 Filtertreiber
22 lokaler Massenspeicher
23 VirtualisierungsSchicht
24 erste Kopie des virtuellen Massenspeichers
24 zweite Kopie des virtuellen Massenspeichers
30 Clustersystem
31 virtueller Desktop
32 Synchronisationsmodul
33 SpeicherserverSoftware
34 AdministrationsService

Claims

Patentansprüche
Clustersystem (20, 30), aufweisend
eine Mehrzahl von Servercomputern (12) mit jeweils wenigstens einem Prozessor, wenigstens einem lokalen Massenspeicher (22) und wenigstens einer Netzwerkkomponente; und
ein Datennetzwerk (15), über das die Netzwerkkomponenten der Mehrzahl von Servercomputern (12) datentechnisch gekoppelt sind;
wobei
das Clustersystem (20, 30) zum Ausführen einer Mehrzahl von virtuellen Maschinen (11) eingerichtet ist;
jeder der virtuellen Maschinen (11) wenigstens ein virtueller Massenspeicher (13) zugeordnet ist;
für jede virtuelle Maschine (11) eine erste Kopie (24) der Daten des zugeordneten virtuellen Massenspeichers
(13) auf dem wenigstens einen lokalen Massenspeicher
(22a) eines ersten Servercomputers (12a) und eine zweite Kopie (25) der Daten des zugeordneten virtuellen Massenspeichers (13) auf dem wenigstens einen lokalen Massen¬ speicher (22b) eines zweiten Servercomputers (12b) der Mehrzahl von Servercomputern (12) gespeichert sind;
bei einem Ausführen einer aktiven virtuellen Maschine
(IIa) der Mehrzahl der virtuellen Maschinen (11) durch den wenigstens einen Prozessor des ersten Servercomputers
(12a) Massenspeicherzugriffe der aktiven virtuellen Ma¬ schine (IIa) auf den ihr zugeordneten wenigstens einen virtuellen Massenspeicher (13a) auf den lokalen Massenspeicher (22a) des ersten Servercomputers (12a) umgelei¬ tet werden;
bei einem Ausführen der aktiven virtuellen Maschinen (IIa) durch den wenigstens einen Prozessor des zweiten Servercomputers (12b) Massenspeicherzugriffe der aktiven virtuellen Maschine (IIa) auf den ihr zugeordneten wenigstens einen virtuellen Massenspeicher (13a) auf den lokalen Massenspeicher (22b) des zweiten Servercomputers (12b) umgeleitet werden; und
Änderungen der ersten Kopie (24a) und der zweiten Kopie (25a) der Daten des virtuellen Massenspeichers (13a) der aktiven virtuellen Maschine (IIa) über das Datennetzwerk (15) mit der zweiten Kopie (25a) beziehungsweise der ers¬ ten Kopie (24a) synchronisiert werden.
Clustersystem (20, 30) nach Anspruch 1, bei dem jeder der Mehrzahl der Servercomputer (12) ein Synchronisationsmodul (32) aufweist, wobei das Synchronisationsmodul (32) des ersten Servercomputers (12a) dazu eingerichtet ist, die Änderungen der ersten Kopie (24a) der Daten des virtuellen Massenspeichers (13a) der aktiven virtuellen Maschine (IIa) für einen bestimmten Zeitraum oder einen bestimmten Datenumfang zusammenzufassen und gemeinsam an den zweiten Servercomputer (12b) zu übertragen.
Clustersystem (20, 30) nach Anspruch 2, bei dem eine Kopie (24a, 25a) der Daten des virtuellen Massenspeichers (13a) der aktiven virtuellen Maschine (IIa) auf dem we¬ nigstens einen lokalen Massenspeicher (22) eines jeden Servercomputers (12) der Mehrzahl von Servercomputern (12) gespeichert ist und die Änderungen der ersten Kopie (24a) von dem Synchronisationsmodul (32) des lokalen Ser¬ vercomputers (12) mittels einer gemeinsamen Mitteilung an alle anderen Servercomputer (12) verteilt werden.
Clustersystem (20, 30) nach einem der Ansprüche 1 bis 3, bei dem durch wenigstens einen der Servercomputer (12a), insbesondere durch eine auf dem wenigstens einen Server¬ computer (12a) ausgeführte virtuelle Maschine (IIa), eine Speicherserversoftware (33) ausgeführt wird, wobei die Speicherserversoftware (33) dazu eingerichtet ist, den Inhalt der virtuellen Massenspeicher (13) der Mehrzahl von virtuellen Maschinen (11) über das Datennetzwerk (15) bereitzustellen.
Clustersystem (20, 30) nach Anspruch 4, bei dem jeder der Mehrzahl der Servercomputer (12) einen Filtertreiber (21) aufweist, wobei der Filtertreiber (21) dazu eingerichtet ist, Massenspeicherzugriffe von einer durch den wenigs¬ tens einen Prozessor des Servercomputers (12a) lokal aus¬ geführten virtuellen Maschine (IIa) abzufangen und auf die erste Kopie (24a) der Daten des wenigstens einen vir¬ tuellen Massenspeichers (13a) auf dem lokalen Massenspei¬ cher (22a) umzuleiten.
Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen (11) auf einer Mehrzahl von Servercomputern (12) umfassend die Schritte:
Starten einer ersten virtuellen Maschine (IIa) auf einem ersten Servercomputer (12a) mit einem ersten lokalen Massenspeicher (22a) ;
Starten einer zweiten virtuellen Maschine (IIb) auf einem zweiten Servercomputer (12b) mit einem zweiten lokalen Massenspeicher (22b) ;
Empfangen einer ersten Schreibanforderung von der ersten virtuellen Maschine (IIa);
Durchführen der ersten Schreibanforderung zur Änderung von ersten Daten auf dem ersten lokalen Massenspeicher (22a) ; Empfangen einer zweiten Schreibanforderung von der zweiten virtuellen Maschine (IIb);
Durchführen der zweiten Schreibanforderung zur Änderung von zweiten Daten auf dem zweiten lokalen Massenspeicher (22b) ;
Synchronisieren der geänderten ersten Daten zwischen dem ersten Servercomputer (12a) und dem zweiten Servercomputer (12b) über ein Datennetzwerk (15); und
Synchronisieren der geänderten zweiten Daten zwischen dem zweiten Servercomputer (12b) und dem ersten Servercomputer (12a) über das Datennetzwerk (15) .
Verfahren nach Anspruch 6, bei dem die Schritte des Synchronisierens der geänderten ersten und der geänderten zweiten Daten folgende Teilschritte umfassen:
Übertragen der geänderten ersten beziehungsweise zweiten Daten von dem ersten Servercomputer (12a) zu dem zweiten Servercomputer (12b) beziehungsweise von dem zweiten Servercomputer (12b) an den ersten Servercomputer (12a); Zwischenspeichern der übertragenen Daten auf dem lokalen zweiten beziehungsweise ersten Massenspeicher (22b, 22a) ; und
Schreiben der überprüften Daten auf den lokalen zweiten Massenspeicher (22b) beziehungsweise den lokalen ersten Massenspeicher (22a) , nachdem die übertragenen Daten vollständig zwischengespeichert wurden.
Verfahren nach Anspruch 6 oder 7, bei dem die Schritte des Synchronisierens der geänderten ersten und der geänderten zweiten Daten zusätzliche folgende Teilschritte umfasst : Markieren der geänderten ersten Daten beziehungsweise ge änderten zweiten Daten auf dem ersten Massenspeicher
(22a) beziehungsweise dem zweiten Massenspeicher (22b) ; Senden einer Bestätigung über das Schreiben der geänderten Daten von dem zweiten Servercomputer (12b) an den ersten Servercomputer (12a) beziehungsweise von dem ersten Servercomputer (12a) an den zweiten Servercomputer
(12b) ; und
Löschen der Markierung der geänderten Daten auf dem ersten lokalen Massenspeicher (22a) beziehungsweise dem zweiten lokalen Massenspeicher (22b) , nachdem die Bestätigung von dem zweiten Servercomputer (12b) beziehungsweise dem ersten Servercomputer (12a) empfangen wurde.
Verfahren nach einem der Ansprüche 6 bis 8, umfassend die weiteren Schritte:
Anhalten der ersten virtuellen Maschine (IIa) auf dem ersten Servercomputer (12a);
Abwarten, bis der Schritt des Synchronisierens der ersten geänderten Daten abgeschlossen ist;
nachfolgendes Starten der ersten virtuellen Maschine (IIa) auf dem zweiten Servercomputer (12b);
Empfangen einer dritten Schreibanforderung von der ersten virtuellen Maschine (IIa);
Durchführen der dritten Schreibanforderung zur Änderung von dritten Daten auf dem zweiten lokalen Massenträger (22b) ; und
Synchronisieren der geänderten dritten Daten zwischen dem zweiten Servercomputer (12b) und dem ersten Servercomputer (12a) über das Datennetzwerk (15) . Verfahren nach einem der Ansprüche 6 bis 8, umfassend die weiteren Schritte:
Anhalten der ersten virtuellen Maschine (IIa) auf dem ersten Servercomputer (12a);
zeitnahes Starten der ersten virtuellen Maschine (IIa) auf dem zweiten Servercomputer (12b);
Empfangen einer Leseanforderung von der ersten virtuellen Maschine (IIa) durch den zweiten Servercomputer (12b); Bereitstellen der angeforderten Daten durch den zweiten lokalen Massenträger (22b) , wenn der Schritt des Synchronisierens der ersten geänderten Daten abgeschlossen ist; und
Umlenken der Leseanforderung an den ersten Servercomputer (12a) und Bereitstellen der angeforderten Daten durch den ersten lokalen Massenspeicher (22a) , wenn der Schritt des Synchronisierens der ersten geänderten Daten noch nicht abgeschlossen ist.
PCT/EP2012/070770 2011-10-25 2012-10-19 Cluster system und verfahren zur migration von virtuellen maschinen in einer shared nothing konfiguration basierend auf lokaler datenspeicherung mit datenreplikation WO2013060627A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2014537565A JP5995981B2 (ja) 2011-10-25 2012-10-19 データ複製によるローカルデータストレージに基づくシェアード・ナッシングコンフィギュレーションにおけるバーチャルマシーンのマイグレーションのためのクラスタシステム及び方法
US14/353,889 US20140337847A1 (en) 2011-10-25 2012-10-19 Cluster system and method for executing a plurality of virtual machines
EP12777902.3A EP2751683A1 (de) 2011-10-25 2012-10-19 Cluster system und verfahren zur migration von virtuellen maschinen in einer shared nothing konfiguration basierend auf lokaler datenspeicherung mit datenreplikation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102011116866A DE102011116866A1 (de) 2011-10-25 2011-10-25 Clustersystem und Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen
DE102011116866.8 2011-10-25

Publications (1)

Publication Number Publication Date
WO2013060627A1 true WO2013060627A1 (de) 2013-05-02

Family

ID=47073439

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/070770 WO2013060627A1 (de) 2011-10-25 2012-10-19 Cluster system und verfahren zur migration von virtuellen maschinen in einer shared nothing konfiguration basierend auf lokaler datenspeicherung mit datenreplikation

Country Status (5)

Country Link
US (1) US20140337847A1 (de)
EP (1) EP2751683A1 (de)
JP (1) JP5995981B2 (de)
DE (1) DE102011116866A1 (de)
WO (1) WO2013060627A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3559601B1 (de) * 2016-12-22 2024-06-12 Nissan North America, Inc. Dienstsystem eines autonomen fahrzeugs
US11030216B2 (en) 2018-01-08 2021-06-08 International Business Machines Corporation Replicating non-supported data types using an existing supported replication format
US11755228B1 (en) * 2019-12-16 2023-09-12 Stripe, Inc. Global heterogeneous data mirroring

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1962192A1 (de) * 2007-02-21 2008-08-27 Deutsche Telekom AG Verfahren und System zur transparenten Migration des Speichers einer virtuellen Maschine
US20110022574A1 (en) * 2009-07-21 2011-01-27 Vmware, Inc. System and Method for Replicating Disk Images in a Cloud Computing Based Virtual Machine File System

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2667818B2 (ja) * 1986-10-09 1997-10-27 株式会社日立製作所 トランザクション処理方法
US6230185B1 (en) * 1997-07-15 2001-05-08 Eroom Technology, Inc. Method and apparatus for facilitating communication between collaborators in a networked environment
US6810411B1 (en) * 1999-09-13 2004-10-26 Intel Corporation Method and system for selecting a host in a communications network
US7155483B1 (en) * 2001-08-07 2006-12-26 Good Technology, Inc. Apparatus and method for conserving bandwidth by batch processing data transactions
US20030177174A1 (en) * 2002-03-14 2003-09-18 International Business Machines Corporation Target resource allocation in an iSCSI network environment
US20030229689A1 (en) * 2002-06-06 2003-12-11 Microsoft Corporation Method and system for managing stored data on a computer network
US7307948B2 (en) * 2002-10-21 2007-12-11 Emulex Design & Manufacturing Corporation System with multiple path fail over, fail back and load balancing
JP4012517B2 (ja) * 2003-04-29 2007-11-21 インターナショナル・ビジネス・マシーンズ・コーポレーション 仮想計算機環境におけるロックの管理
EP1692602A4 (de) * 2003-10-31 2007-10-24 Landmark Technology Partners I Intelligentes client-architektur-computersystem und -verfahren
US7177782B2 (en) * 2004-06-18 2007-02-13 Lenovo (Singapore) Pte. Ltd. Methods and arrangements for capturing runtime information
US20060271557A1 (en) * 2005-05-25 2006-11-30 Terracotta, Inc. Database Caching and Invalidation Based on Detected Database Updates
US20070094659A1 (en) * 2005-07-18 2007-04-26 Dell Products L.P. System and method for recovering from a failure of a virtual machine
US8209363B2 (en) * 2007-10-09 2012-06-26 Cleversafe, Inc. File system adapted for use with a dispersed data storage network
US7370164B1 (en) * 2006-03-21 2008-05-06 Symantec Operating Corporation Backup of virtual machines from the base machine
US7971005B2 (en) * 2006-10-05 2011-06-28 Waratek Pty Ltd. Advanced contention detection
US9189265B2 (en) * 2006-12-21 2015-11-17 Vmware, Inc. Storage architecture for virtual machines
US7673113B2 (en) * 2006-12-29 2010-03-02 Intel Corporation Method for dynamic load balancing on partitioned systems
JP5246388B2 (ja) * 2007-03-08 2013-07-24 日本電気株式会社 仮想装置構成システム、及びその方法
JP4468426B2 (ja) * 2007-09-26 2010-05-26 株式会社東芝 高可用システム及び実行状態制御方法
JP4479930B2 (ja) * 2007-12-21 2010-06-09 日本電気株式会社 ノードシステム、サーバ切換え方法、サーバ装置、データ引き継ぎ方法、およびプログラム
JP2009163563A (ja) * 2008-01-08 2009-07-23 Klab Inc コンピュータ・システムとそのセットアップ方法および復旧方法、並びに、外部記憶媒体
US8255806B2 (en) * 2008-09-15 2012-08-28 Vmware, Inc. Unified secure virtual machine player and remote desktop client
JP5227125B2 (ja) * 2008-09-24 2013-07-03 株式会社日立製作所 ストレージシステム
JP5124430B2 (ja) * 2008-12-04 2013-01-23 株式会社エヌ・ティ・ティ・データ 仮想マシンの移行方法、サーバ、及び、プログラム
JP2010152591A (ja) * 2008-12-25 2010-07-08 Nec Corp データベースシステム、データ処理方法及びデータ処理プログラム
US9058118B1 (en) * 2008-12-31 2015-06-16 Symantec Corporation Techniques for synchronizing and/or consolidating storage areas
WO2010095174A1 (en) * 2009-02-19 2010-08-26 Hitachi, Ltd. Storage system, and remote copy control method therefor
US8578083B2 (en) * 2009-03-03 2013-11-05 Vmware, Inc. Block map based I/O optimization for storage virtual appliances
US9037718B2 (en) * 2009-03-25 2015-05-19 Ntt Docomo, Inc. Method and apparatus for live replication
US9213651B2 (en) * 2009-06-16 2015-12-15 Vmware, Inc. Synchronizing a translation lookaside buffer with page tables
JP2011003030A (ja) * 2009-06-18 2011-01-06 Toshiba Corp 情報処理システムおよびプログラム
JP2011060055A (ja) * 2009-09-11 2011-03-24 Fujitsu Ltd 仮想計算機システム、仮想マシンの復旧処理方法及びそのプログラム
CN102081552A (zh) * 2009-12-01 2011-06-01 华为技术有限公司 一种物理机到虚拟机的在线迁移方法、装置和系统
US9032398B2 (en) * 2010-07-12 2015-05-12 Vmware, Inc. Online classification of memory pages based on activity level represented by one or more bits
US8533258B2 (en) * 2010-10-20 2013-09-10 Microsoft Corporation Bidirectional synchronization with CRM applications
US8756602B2 (en) * 2010-11-14 2014-06-17 Brocade Communications Systems, Inc. Virtual machine and application migration over local and wide area networks without timeout
US9201612B1 (en) * 2011-10-20 2015-12-01 Amazon Technologies, Inc. Utilizing shared storage for efficient VM-HA
US9280428B2 (en) * 2013-04-23 2016-03-08 Neftali Ripoll Method for designing a hyper-visor cluster that does not require a shared storage device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1962192A1 (de) * 2007-02-21 2008-08-27 Deutsche Telekom AG Verfahren und System zur transparenten Migration des Speichers einer virtuellen Maschine
US20110022574A1 (en) * 2009-07-21 2011-01-27 Vmware, Inc. System and Method for Replicating Disk Images in a Cloud Computing Based Virtual Machine File System

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "NexentaStor VM Data Center User Guide Version 3.0", 1 January 2010 (2010-01-01), pages 1 - 38, XP055046629, Retrieved from the Internet <URL:http://info.nexenta.com/rs/nexenta/images/doc_3.0_vmdc-userguide.pdf> [retrieved on 20121204] *

Also Published As

Publication number Publication date
JP2015501032A (ja) 2015-01-08
DE102011116866A1 (de) 2013-04-25
US20140337847A1 (en) 2014-11-13
JP5995981B2 (ja) 2016-09-21
EP2751683A1 (de) 2014-07-09

Similar Documents

Publication Publication Date Title
DE112011103666B4 (de) Speicherverwaltung in Cluster-Datenverarbeitungssystemen
DE10134492B4 (de) Ausfallübernahme des Dateimanagementsystems in einem Rechnercluster
DE602004008028T2 (de) Verfahren zum dynamischen Transferieren zwischen Servern für virtuelle Dateiserver
DE60111072T2 (de) Verfahren und vorrichtung zur parallelen nachrichtenübermittlung in echtzeit von dateisegmentierten
DE112016001295T5 (de) Neusynchronisieren auf ein erstes Speichersystem durch Spiegeln des ersten Speichersystems nach einem Failover zu einem zweiten Speichersystem
DE112011104471T5 (de) Verfahren zur Failover-Verwaltung von virtuellen Maschinen und System zum Unterstützen desselben
DE112014006605B4 (de) Speichersystem
US6442706B1 (en) Resource allocation throttle for remote data mirroring system
DE69724846T2 (de) Mehrweg-Ein/Ausgabespeichersysteme mit Mehrweg-Ein/Ausgabeanforderungsmechanismus
DE602005001041T2 (de) Speicherauszugssystem
US7103797B1 (en) Resource allocation throttling in remote data mirroring system
DE60214234T2 (de) Verfahren und apparate zum implementieren einer glasfaservermittlungseinheit mit hoher verfügbarkeit
DE602005002532T2 (de) Cluster-datenbank mit ferndatenspiegelung
DE112010004931T5 (de) Mehrphasige Wiederherstellung von Dateisystemen mit SelektiverBedarfsweiser Verfügbarkeit von Daten(
DE19924900A1 (de) Verfahren und Vorrichtung für Katastrophen-Behebung von Dateisystemen
DE102013209528A1 (de) Benutzergesteuerte Replikation in einem System für synchronisierte Objektreplikationen
DE202014010953U1 (de) Gruppierung von Objekten in einem verteilten Datenspeichersystem basierend auf Protokollen und Platzierungsrichtlinien
DE19924822A1 (de) Verfahren und Vorrichtung für Katastrophen-Behebung von Dateisystemen
DE60313468T2 (de) Speicherdienste und -systeme
DE102013101863A1 (de) Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen
EP2772856B1 (de) Verfahren zum Ausführen von Tasks auf einem Produktions-Computersystem sowie Datenverarbeitungssystem
DE112020002834T5 (de) Spiegeln von schreiboperationen zwischen datenspeichereinheiten
DE602004006224T2 (de) Verfahren und Vorrichtung zur Datensynchronisierung eines verteilten Datenbanksystems
DE112009004772T5 (de) System für eine steuerung der version von virtuellen platten
CN104917843A (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: 12777902

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2014537565

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14353889

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE