DE102011116866A1 - Clustersystem und Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen - Google Patents

Clustersystem und Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen Download PDF

Info

Publication number
DE102011116866A1
DE102011116866A1 DE102011116866A DE102011116866A DE102011116866A1 DE 102011116866 A1 DE102011116866 A1 DE 102011116866A1 DE 102011116866 A DE102011116866 A DE 102011116866A DE 102011116866 A DE102011116866 A DE 102011116866A DE 102011116866 A1 DE102011116866 A1 DE 102011116866A1
Authority
DE
Germany
Prior art keywords
server computer
data
virtual
mass storage
virtual machine
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
DE102011116866A
Other languages
English (en)
Inventor
Henning Klein
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Technology Solutions Intellectual Property GmbH
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 DE102011116866A priority Critical patent/DE102011116866A1/de
Priority to PCT/EP2012/070770 priority patent/WO2013060627A1/de
Priority to US14/353,889 priority patent/US20140337847A1/en
Priority to JP2014537565A priority patent/JP5995981B2/ja
Priority to EP12777902.3A priority patent/EP2751683A1/de
Publication of DE102011116866A1 publication Critical patent/DE102011116866A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1479Generic software techniques for error detection or fault masking
    • G06F11/1482Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G06F11/1484Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error 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/202Error 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/2038Error 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error 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/202Error 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/2048Error 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16Error detection or correction of the data by redundancy in hardware
    • G06F11/20Error 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/2097Error 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

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 des zugehö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

  • 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 Virtualisierung 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 Benutzer 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 zuzugreifen. Alternativ kann auch ein konventioneller Fat-Client mit einer darauf installierten Terminalsoftware zum Zugriff auf die virtuelle Maschine verwendet werden. Alle von dem Benutzer gestarteten Programme werden innerhalb der virtuellen Maschine auf Seiten des Servercomputers und nicht auf dem Clientcomputer ausgeführt. Dabei greift die virtuelle Maschine 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 beispielsweise 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 virtuellen 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 Servercomputer 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 1 dargestellt. Im in der 1 dargestellten Beispiel werden drei virtuelle Maschinen 11a, 11b und 11c auf einen gemeinsamen Servercomputer 12 ausgeführt. Neben dem in der 1 dargestellten Servercomputer 12 sind weitere Servercomputer vorgesehen, die ebenfalls zur Ausführung der virtuellen Maschinen 11a bis 11c geeignet sind.
  • Jeder der virtuellen Maschinen 11a bis 11c ist ein eigener, virtueller Massenspeicher 13a bis 13c zugeordnet. Ein Hypervisor oder eine andere Virtualisierungssoftware des Servercomputers 12 emuliert für die virtuellen Maschinen 11 das Vorhandensein eines entsprechenden physikalischen Massenspeichers. Für ein auf der virtuellen Maschine 11a 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 11a bis 11c des Servercomputers 12 zentral durch den Speicherserver 16 beantwortet.
  • Ein Problem der in der 1 dargestellten Architektur liegt darin, dass sämtliche Speicherzugriffe aller virtuellen Maschinen 11a 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 11a 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 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 Maschine eine erste Kopie der Daten des zugeordneten virtuellen Massenspeichers auf dem wenigstens einen lokalen Massenspeicher eines ersten Servercomputers und eine zweite Kopie der Daten des zugeordneten virtuellen Massenspeichers auf dem wenigstens 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 aktiven 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 Massenspeichers 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ötige Transporte über ein Datennetzwerk vermieden, was die Latenzzeiten 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 Servercomputern in der Regel lokale Massenspeicher, insbesondere Festplatten, zum Start eines Host-Betriebssystems beziehungsweise 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 Massenspeicher 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 leistungsfä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 Synchronisationsmodul des ersten Servercomputers dazu eingerichtet, für einen bestimmten Zeitraum oder einen bestimmten Datenumfang 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 Datennetzwerk 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 Maschinen ü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 gleichzeitig 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 gesondert konfigurierten oder ausgerüsteten Datenservers oder Servercomputers verzichtet werden.
  • Gemäß einer weiteren vorteilhaften Ausgestaltung weist jeder der Mehrzahl der Servercomputer einen Filtertreiber auf, wobei der Filtertreiber dazu eingerichtet ist, Massenspeicherzugriffe von einer durch den wenigstens einen Prozessor des Servercomputers lokal ausgeführten virtuellen Maschine abzufangen 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 transaktionsorientiert durchgeführt.
  • Gemäß einer weiteren vorteilhaften Ausgestaltung umfasst das Verfahren zusätzlich die Schritte:
    • – Anhalten der ersten virtuellen Maschine auf dem ersten Servercomputer
    • – 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 Inkonsistenzen 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 Ausführungsbeispiele unter Bezugnahme auf die angehängten Figuren näher erläutert.
  • In den Figuren zeigen:
  • 1 eine Architektur eines Clustersystems mit einem gesonderten Speicherserver,
  • 2 eine Architektur eines Clustersystems gemäß einer Ausgestaltung der vorliegenden Erfindung,
  • 3 einen Clustersystem mit drei Servercomputern gemäß einer Ausgestaltung der vorliegenden Erfindung,
  • 4 ein Ablaufdiagramm eines Verfahrens zum parallelen Ausführen von zwei virtuellen Maschinen,
  • 5 ein Ablaufdiagramm eines Verfahrens zum Verschieben einer virtuellen Maschine sowie
  • 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 Komponenten 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.
  • 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 ähnelt dem Aufbau des Clustersystems 10 gemäß 1. Davon abweichend wird in der Architektur gemäß 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 11a auf dem ersten Servercomputer 12a ab. Neben der virtuellen Maschine 11a können weitere virtuelle Maschinen 11b bis 11c durch den ersten Servercomputer 12a bereitgestellt werden.
  • Weitere virtuellen Maschinen 11d bis 11f werden im Ausführungsbeispiel durch den Servercomputer 12b ausgeführt. Greift eine der virtuellen Maschinen 11d bis 11f auf einen ihr zugeordneten, 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 1 beschrieben, an den iSCSI-Initiator 14 weiter, sondern leitet die Anfrage an einen lokalen Massenspeicher 22b, insbesondere ein eingebautes Festplattenlaufwerk, des Servercomputers 12b um. Dabei ist auf dem lokalen Massenspeicher 22b jeweils eine erste Kopie 24d bis 24f der virtuellen Massenspeichers 13d bis 13f gespeichert. 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 11d bis 11f 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 verzichtet werden, was insbesondere die Latenzzeiten beim Massenspeicherzugriff der virtuellen Maschinen 11d bis 11f verringert.
  • Um eine Ausfallsicherheit gegenüber einem Versagen des Servercomputers 12b beziehungsweise der darin eingebauten Komponenten 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 lokalen 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 11d bis 11f auf den Servercomputer 12a.
  • Im Ausführungsbeispiel erfolgt eine Synchronisation der Kopien 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übertragung dabei wie unter Bezugnahme auf die 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 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 zweiten 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 daraufhin die zweite Kopien 25 der virtuellen Massenspeicher 13 auf dem lokalen Massenspeicher 22a.
  • Obwohl dies in der 2 aus Gründen der Übersichtlichkeit nicht dargestellt ist, sind den virtuellen Maschinen 11a bis 11c ebenfalls virtuelle Massenspeicher 13a bis 13c zugeordnet, deren Inhalte als erste Kopie 24 auf dem lokalen Massenspeicher 22a des ersten Servercomputers 12a und als zweite Kopie 25 auf mindestens einem lokalen Massenspeicher 22 eines anderen Servercomputers 12 gespeichert sind und in äquivalenter Weise synchronisiert werden.
  • 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 virtueller Massenspeicher 13 zugeordnet ist. Aus Gründen der Übersichtlichkeit sind die virtuellen Maschinen 11 und virtuellen Massenspeicher 13 in der 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 Synchronisationsmodul 32. Zusätzlich ist auf jedem der Servercomputer 12 eine Speicherserversoftware 33 zur Bereitstellung der Funktionalität eines konventionellen Speicherservers 16 eingerichtet. Die Speicherserversoftware 33 wird zu jedem Zeitpunkt 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 Verteilen 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 virtuellen 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äß 3 reicht die Speicherkapazität der lokalen Massenspeicher 22a bis 22c aus, um die virtuellen 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 virtuellen 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 Massenspeicher 13 entsprechend. Dies ist in der 3 für den ersten virtuellen Desktop 31a beispielhaft durch die Pfeile angedeutet. Umgekehrt werden Änderungen an den virtuellen Massenspeichern 13 der virtuellen Desktops 31c und 31d per Broadcast 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 Synchronisationsmoduls 32 oder des Administrationsservices 34 Block für Block übertragen.
  • Ein konkreter Ablauf der Synchronisation sowie ein Verschieben 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 4 bis 6 beschrieben.
  • 4 zeigt ein Ablaufdiagramm eines Verfahrens 40 zum Betrieb eines Clustersystems, beispielsweise eines der Clustersysteme 20 oder 30. In der linken Hälfte der 4 sind die Schritte dargestellt, die von einem ersten Servercomputer 12a des Clustersystems ausgeführt werden. In der rechten Hälfte der 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 Maschine 11a gestartet. Beispielsweise wird ein Windows-Betriebssystem für einen Benutzer gestartet, der mittels Desktop-Virtualisierung auf eine virtuelle Maschine 11a zugreift. In einem Schritt 42a empfängt eine Managementsoftware des Servercomputers 12a, beispielsweise ein auf dem Servercomputer 12a ausgeführter Hypervisor, eine Schreibanfrage der ersten virtuellen Maschine 11a. Beispielsweise möchte ein Benutzer ein geändertes Textdokument auf einem virtuellen Massenspeicher 13a seiner virtuellen Maschine 11a 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 11b auf einem zweiten Servercomputer 12b durchgeführt. Änderungen der zweiten virtuellen Maschine 11b 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 vorbestimmten zeit oder nach dem Auflaufen einer vorbestimmten Zahl von Änderungen, fast der erste Servercomputer 12a die bisher durch die virtuelle Maschine 11a vorgenommenen Änderungen zusammen und überträgt eine entsprechende erste Aktualisierungsnachricht an den zweiten Servercomputer 12b. Der zweite Servercomputer 12b empfängt die erste Aktualisierungsnachricht in einem Schritt 45b und aktualisiert seine Kopie des virtuellen Massenspeichers 13a der ersten virtuellen Maschine 11a entsprechend. Umgekehrt überträgt der zweite Servercomputer 12b in einem Schritt 44b die bisher aufgelaufenen Änderungen der zweiten virtuellen Maschine 11b an deren Kopie 24 des virtuellem Massenspeicher 13b auf dem lokalen Massenspeicher 22b und überträgt diese in Form einer zweiten Aktualisierungsnachricht an den ersten Servercomputer 12a. In einem Schritt 45a aktualisiert der erste Servercomputer 12a seine Kopie des virtuellen Massenspeichers 13b der zweiten virtuellen Maschine 11b entsprechend.
  • 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 4 sind die Schritte des ersten Servercomputers 12a auf der linken Seite der 5 und die Verfahrensschritte des zweiten Servercomputers 12b auf der rechten Seite der 5 abgebildet.
  • 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 Aktualisierungsnachricht 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 Maschine 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 Arbeitsspeichers von einer vorhandenen Clustersoftware, beispielsweise dem Administrationsservice 34 übertragen. In beiden Fällen startet die virtuelle Maschine 11 im Schritt 54 in genau demselben 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 Servercomputer 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 Servercomputers 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 Maschine 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 werden.
  • In den 6A und 6A ist der Ablauf eines möglichen Synchronisationsverfahren 60 zum Abgleichen von Kopien 24 und 25 eines virtuellen Massenspeichers 13 zwischen zwei verschiedenen 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, beispielsweise 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 Anforderung 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 lokalen ersten Kopie 24 des virtuellen Massenspeichers 13 beantwortet. 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 Belegungsliste im Arbeitsspeicher, in einer Tabelle des Synchronisationsmoduls 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 fortgesetzt.
  • 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 einer korrespondieren zweiten Kopie 25 auf dem lokalen Massenspeicher 22b des zweiten Servercomputers 12b synchronisiert. Hierzu werden insbesondere die Schritte 68 bis 75 gemäß 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 zusammengestellt.
  • In einem nachfolgenden Schritt 69 wird die Aktualisierungsnachricht von dem ersten Servercomputer 12a über das Datennetzwerk 15 an den zweiten Servercomputer 12b und gegebenenfalls zu weiteren Servercomputern 12 übertragen, die ebenfalls 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 Servercomputer 12a im Schritt 70 optional ab, ob der zweite Servercomputer 12b und gegebenenfalls weitere Servercomputer 12 die Synchronisation wie angefordert vorgenommen und bestätigt haben.
  • Parallel dazu empfängt der zweite Servercomputer 12b in einem Schritt 71 zunächst die im Schritt 69 verschickte Aktualisierungsnachricht und legt diese auf dem lokalen Massenspeicher 22b ab. Anhand der in der Aktualisierungsnachricht enthaltenen 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. Andernfalls 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 vorbestimmten 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 werden.
  • In der beschriebenen Ausgestaltung werden die Schritte 68 bis 75 durch das Synchronisationsmodul 32 oder den Administrationsservice 34 des ersten Servercomputer 12a koordiniert. Während 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 abgeschlossen 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 synchronisiert, so dass jede virtuelle Maschine 11 auf jedem Servercomputer 12 ausgeführt werden kann und gleichzeitig eine zusä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 Ausgestaltung 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 sichergestellt 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 besonders 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 Hochleistungsnetzwerkkomponenten und -festplatten sowie RAID-Systemen verzichtet werden.
  • Bezugszeichenliste
  • 10
    Clustersystem
    11
    virtuelle Maschine
    12
    Servercomputer
    13
    virtueller Massenspeicher
    14
    iSCSI-Initiator
    15
    Datennetzwerk
    16
    Speicherserver
    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 (10)

  1. 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 Massenspeicher (22b) eines zweiten Servercomputers (12b) der Mehrzahl von Servercomputern (12) gespeichert sind; – bei einem Ausführen einer aktiven virtuellen Maschine (11a) der Mehrzahl der virtuellen Maschinen (11) durch den wenigstens einen Prozessor des ersten Servercomputers (12a) Massenspeicherzugriffe der aktiven virtuellen Maschine (11a) auf den ihr zugeordneten wenigstens einen virtuellen Massenspeicher (13a) auf den lokalen Massenspeicher (22a) des ersten Servercomputers (12a) umgeleitet werden; – bei einem Ausführen der aktiven virtuellen Maschinen (11a) durch den wenigstens einen Prozessor des zweiten Servercomputers (12b) Massenspeicherzugriffe der aktiven virtuellen Maschine (11a) 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 (11a) über das Datennetzwerk (15) mit der zweiten Kopie (25a) beziehungsweise der ersten Kopie (24a) synchronisiert werden.
  2. 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 (11a) für einen bestimmten Zeitraum oder einen bestimmten Datenumfang zusammenzufassen und gemeinsam an den zweiten Servercomputer (12b) zu übertragen.
  3. Clustersystem (20, 30) nach Anspruch 2, bei dem eine Kopie (24a, 25a) der Daten des virtuellen Massenspeichers (13a) der aktiven virtuellen Maschine (11a) auf dem wenigstens 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 Servercomputers (12) mittels einer gemeinsamen Mitteilung an alle anderen Servercomputer (12) verteilt werden.
  4. 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 Servercomputer (12a) ausgeführte virtuelle Maschine (11a), 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.
  5. 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 wenigstens einen Prozessor des Servercomputers (12a) lokal ausgeführten virtuellen Maschine (11a) abzufangen und auf die erste Kopie (24a) der Daten des wenigstens einen virtuellen Massenspeichers (13a) auf dem lokalen Massenspeicher (22a) umzuleiten.
  6. Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen (11) auf einer Mehrzahl von Servercomputern (12) umfassend die Schritte: – Starten einer ersten virtuellen Maschine (11a) auf einem ersten Servercomputer (12a) mit einem ersten lokalen Massenspeicher (22a); – Starten einer zweiten virtuellen Maschine (11b) auf einem zweiten Servercomputer (12b) mit einem zweiten lokalen Massenspeicher (22b); – Empfangen einer ersten Schreibanforderung von der ersten virtuellen Maschine (11a); – 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 (11b); – 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).
  7. 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.
  8. 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.
  9. Verfahren nach einem der Ansprüche 6 bis 8, umfassend die weiteren Schritte: – Anhalten der ersten virtuellen Maschine (11a) auf dem ersten Servercomputer (12a); – Abwarten, bis der Schritt des Synchronisierens der ersten geänderten Daten abgeschlossen ist; – nachfolgendes Starten der ersten virtuellen Maschine (11a) auf dem zweiten Servercomputer (12b); – Empfangen einer dritten Schreibanforderung von der ersten virtuellen Maschine (11a); – 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).
  10. Verfahren nach einem der Ansprüche 6 bis 8, umfassend die weiteren Schritte: – Anhalten der ersten virtuellen Maschine (11a) auf dem ersten Servercomputer (12a); – zeitnahes Starten der ersten virtuellen Maschine (11a) auf dem zweiten Servercomputer (12b); – Empfangen einer Leseanforderung von der ersten virtuellen Maschine (11a) 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.
DE102011116866A 2011-10-25 2011-10-25 Clustersystem und Verfahren zum Ausführen einer Mehrzahl von virtuellen Maschinen Withdrawn DE102011116866A1 (de)

Priority Applications (5)

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
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
US14/353,889 US20140337847A1 (en) 2011-10-25 2012-10-19 Cluster system and method for executing a plurality of virtual machines
JP2014537565A JP5995981B2 (ja) 2011-10-25 2012-10-19 データ複製によるローカルデータストレージに基づくシェアード・ナッシングコンフィギュレーションにおけるバーチャルマシーンのマイグレーションのためのクラスタシステム及び方法
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 (1)

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

Publications (1)

Publication Number Publication Date
DE102011116866A1 true DE102011116866A1 (de) 2013-04-25

Family

ID=47073439

Family Applications (1)

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

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)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220018666A1 (en) * 2016-12-22 2022-01-20 Nissan North America, Inc. Autonomous vehicle service system

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US20080140982A1 (en) * 2006-10-05 2008-06-12 Holt John M Redundant multiple computer architecture
US20100228903A1 (en) * 2009-03-03 2010-09-09 Vmware, Inc. Block Map Based I/O Optimization for Storage Virtual Appliances

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
WO2006128112A2 (en) * 2005-05-25 2006-11-30 Terracotta, Inc. Clustering server providing virtual machine data sharing
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
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
EP1962192A1 (de) * 2007-02-21 2008-08-27 Deutsche Telekom AG Verfahren und System zur transparenten Migration des Speichers einer virtuellen Maschine
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
US8448167B2 (en) * 2009-02-19 2013-05-21 Hitachi, Ltd. Storage system, and remote copy control method therefor
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 情報処理システムおよびプログラム
US8352482B2 (en) * 2009-07-21 2013-01-08 Vmware, Inc. System and method for replicating disk images in a cloud computing based virtual machine file system
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
US20080140982A1 (en) * 2006-10-05 2008-06-12 Holt John M Redundant multiple computer architecture
US20100228903A1 (en) * 2009-03-03 2010-09-09 Vmware, Inc. Block Map Based I/O Optimization for Storage Virtual Appliances

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220018666A1 (en) * 2016-12-22 2022-01-20 Nissan North America, Inc. Autonomous vehicle service system

Also Published As

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

Similar Documents

Publication Publication Date Title
DE112011103666B4 (de) Speicherverwaltung in Cluster-Datenverarbeitungssystemen
DE112014006605B4 (de) Speichersystem
DE602004008028T2 (de) Verfahren zum dynamischen Transferieren zwischen Servern für virtuelle Dateiserver
DE69724846T2 (de) Mehrweg-Ein/Ausgabespeichersysteme mit Mehrweg-Ein/Ausgabeanforderungsmechanismus
DE10134492B4 (de) Ausfallübernahme des Dateimanagementsystems in einem Rechnercluster
DE112016001295T5 (de) Neusynchronisieren auf ein erstes Speichersystem durch Spiegeln des ersten Speichersystems nach einem Failover zu einem zweiten Speichersystem
DE602004005344T2 (de) Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort
DE112018002951B4 (de) Verwenden eines spurformatcodes in einem cache-steuerblock für eine spur in einem cache, um lese- und schreibanforderungen in bezug auf die spur im cache zu verarbeiten
DE60111072T2 (de) Verfahren und vorrichtung zur parallelen nachrichtenübermittlung in echtzeit von dateisegmentierten
US6618818B1 (en) Resource allocation throttling in remote data mirroring system
US7562250B2 (en) Resource allocation throttling in remote data mirroring system
DE112010004931B4 (de) Mehrphasige Wiederherstellung von Dateisystemen mit Selektiver Bedarfsweiser Verfügbarkeit von Daten
DE112011104471T5 (de) Verfahren zur Failover-Verwaltung von virtuellen Maschinen und System zum Unterstützen desselben
DE102013101863A1 (de) Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen
DE102013209528A1 (de) Benutzergesteuerte Replikation in einem System für synchronisierte Objektreplikationen
DE112012001660T5 (de) Speicher-Checkpointing in einem System gespiegelter virtueller Maschinen
DE112014001873T5 (de) Replikation für Hot-Standby-Online-Datenbank
DE10393771T5 (de) Schnelle Datensicherungsspeicherung und schnelle Datenwiederherstellung (FBSRD)
DE112013005758T5 (de) Verfahren und Vorrichtung zur Notfallwiederherstellungsvirtualisierung
DE102004056216A1 (de) Fernkopiersystem und Speichersystem
DE112011100564B4 (de) Einfügen eines Flash-Zwischenspeichers in große Speichersysteme
DE112014006156T5 (de) Datenmigrationsverfahren eines Speichersystems
DE112009004772T5 (de) System für eine steuerung der version von virtuellen platten
DE602004006224T2 (de) Verfahren und Vorrichtung zur Datensynchronisierung eines verteilten Datenbanksystems
DE102012108117A1 (de) Hochverfügbares Rechnersystem, Arbeitsverfahren und dessen Verwendung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R084 Declaration of willingness to licence

Effective date: 20131219

R016 Response to examination communication
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee