DE112011103026T5 - Bedarfsgesteuertes Streaming von Abbildern virtueller Maschinen - Google Patents

Bedarfsgesteuertes Streaming von Abbildern virtueller Maschinen Download PDF

Info

Publication number
DE112011103026T5
DE112011103026T5 DE112011103026T DE112011103026T DE112011103026T5 DE 112011103026 T5 DE112011103026 T5 DE 112011103026T5 DE 112011103026 T DE112011103026 T DE 112011103026T DE 112011103026 T DE112011103026 T DE 112011103026T DE 112011103026 T5 DE112011103026 T5 DE 112011103026T5
Authority
DE
Germany
Prior art keywords
image
computer
virtual machine
data
ods
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.)
Granted
Application number
DE112011103026T
Other languages
English (en)
Other versions
DE112011103026B4 (de
Inventor
Chunqiang Tang
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
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 International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112011103026T5 publication Critical patent/DE112011103026T5/de
Application granted granted Critical
Publication of DE112011103026B4 publication Critical patent/DE112011103026B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • 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
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • 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
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)
  • Television Signal Processing For Recording (AREA)

Abstract

Ein bedarfsgesteuertes Abbild-Streaming (ODS) kann in einem Aspekt sowohl einen Vorgang des Erstellens einer Kopie beim Schreiben als auch einen Vorgang des Erstellens einer Kopie beim Lesen durchführen, um Daten auf einem Remote-Speicher-Server schrittweise auf eine lokale Festplatte eines Host zu übertragen. Ein Vorablesezugriff kann durchgeführt werden, während die Ressourcen ansonsten im Leerlauf sind, um Daten vom Remote-Speicher-Server auf die lokale Festplatte des Host zu übertragen. Ein neues Abbildformat und der entsprechende Blockeinheitentreiber für einen Hypervisor oder dergleichen können ebenfalls bereitgestellt werden. Das Abbildformat des ODS kann eine Kopfzeile und eine Bitmap beinhalten, die anzeigt, ob sich die Datensektoren auf einer lokalen Festplatte oder einem Remote-Speicher-Server befinden, und einen Abbild-Inhalt, der beispielsweise im Ursprungsformat gespeichert ist.

Description

  • GEBIET
  • Die vorliegende Anmeldung bezieht sich im Allgemeinen auf Computersysteme und insbesondere auf bedarfsgesteuertes Streaming von Abbildern virtueller Maschinen, beispielsweise für eine Cloud-Umgebung oder dergleichen.
  • HINTERGRUND
  • Bei einer Cloud-Computing-Umgebung kann der von einer virtuellen Maschine (VM) benötigte Blockeinheitenspeicher aus mehreren Quellen zugewiesen werden: Direktzugriffsspeicher (DAS, d. h. lokale Festplatte) des Host, Netzzugriffsspeicher (NAS, z. B. NFS) oder Speichernetzwerk (Storage Area Network (SAN)). Diese Optionen sind mit unterschiedlicher Leistung, Zuverlässigkeit und Verfügbarkeit zu unterschiedlichen Kosten verbunden.
  • Bei einem derzeit bekannten VM-Erstellungsverfahren wird die gesamte VM-Datei im Ursprungsformat (raw format, eine Byte-für-Byte-Kopie des Inhalts der physischen Blockeinheit) von einer in einem NAS gespeicherten Nur-Lese-Abbildvorlage in einen DAS eines Host kopiert. Nur dann könnte die VM des Host gebootet und ausgeführt werden. Diese Methodik ist mit einem Zeitaufwand für das Kopieren der gesamten Abbildvorlage in den DAS und somit mit einer langen Verzögerung verbunden, bis die neue VM gestartet und verwendet werden kann.
  • Bei einem weiteren bekannten Verfahren wird im DAS des Host lediglich ein Vorgang der Kopie beim Schreiben (Copy-on-Write) durchgeführt, d. h., nur geänderte Dateien werden im DAS gespeichert, nichtgeänderte Dateien hingegen werden stets aus dem Sicherungsabbild gelesen. Beim Verwenden einer im NAS als Sicherungsabbild gespeicherten Abbildvorlage kann eine VM womöglich schneller erstellt werden, da die Abbildvorlage beim Erstellen einer neuen VM nicht aus dem NAS in den DAS kopiert werden muss. Allerdings kann das wiederholte Lesen von nichtgeänderten Daten aus dem NAS übermäßigen Netzwerkdatenverkehr und E/A-Last im Share-NAS-Server erzeugen. Dies ist insbesondere bei einer Cloud-Umgebung mit mehreren VMs der Fall. Bei einem solchen Verfahren kann es erforderlich sein, dass die Cloud-Umgebung das Netzwerk und den NAS-Server mit jeweils ausreichender Kapazität für das Handhaben einer solchen Datenverkehrsmenge und E/A-Last bereitstellt.
  • Als weiteren Gesichtspunkt können die bestehenden Hypervisoren eine VM nur dann migrieren, wenn deren Abbilddatei in einem NAS gespeichert ist. Womöglich weil eine auf einem DAS laufende VM nicht migriert werden kann, kann ein Cloud-Anbieter den Benutzer einfach über einen anstehenden Wartungsvorgang auf einem Host benachrichtigen und auffordern, die Folgen eines VM-Verlusts zu akzeptieren. Das kann für den Cloud-Diensteanbieter zwar einfach sein, für Cloud-Benutzer unter Umständen aber nicht wünschenswert.
  • KURZE ZUSAMMENFASSUNG
  • Es werden ein Verfahren und ein System für ein bedarfsgesteuertes Streaming von Abbildern virtueller Maschinen bereitgestellt. In einem Aspekt kann das Verfahren das Kopieren von mit einer ausgewählten virtuellen Maschine verknüpften Abbild-Metadaten von einem Speicher-Server, auf dem eine oder mehrere Abbildvorlagen (auch als Sicherungsabbilder bezeichnet) gespeichert sind, die jeweils einer oder mehreren virtuellen Maschinen entsprechen, in einen lokalen Speicher eines Host-Computers beinhalten, wobei der lokale Speicher des Host-Computers zunächst kein Abbild der ausgewählten virtuellen Maschine enthält. Das Verfahren kann auch das Booten der ausgewählten virtuellen Maschine im Host-Computer unter Verwendung der kopierten Abbild-Metadaten beinhalten, wodurch es der ausgewählten virtuellen Maschine ermöglicht wird, Daten aus der Abbildvorlage auf dem Speicher-Server zu lesen, die erforderlich sind, um das Ausführen der ausgewählten virtuellen Maschine auf dem Host-Computer fortzusetzen, wenn die benötigten Daten nicht im lokalen Speicher des Host-Computers gespeichert sind. Das Verfahren kann darüber hinaus das Kopieren der gelesenen Daten der Abbildvorlage vom Speicher-Server in den lokalen Speicher des Host-Computers beinhalten, wenn die gelesenen Daten der Abbildvorlage nicht in dem lokalen Speicher des Host-Computers gespeichert sind. Nachfolgende Lesevorgänge der gleichen Daten werden aus dem lokalen Speicher des Host-Computers durchgeführt. Das Verfahren kann auch das Setzen eines Bit in einer Bitmap beinhalten, um anzuzeigen, dass die gelesenen Daten im lokalen Speicher des Host-Computers gespeichert sind. Das Verfahren kann darüber hinaus noch das Nutzen einer Ressourcen-Leerlaufzeit beinhalten, um Daten der mit der ausgewählten virtuellen Maschine verknüpften Abbildvorlage (Sicherungsabbild) aus dem Speicher-Server in den lokalen Speicher des Host-Computers bereitzustellen (sog. „Prefetching”).
  • Ein Verfahren zum bedarfsgesteuerten Streaming von Abbildern virtueller Maschinen kann in einem weiteren Aspekt das Kopieren von mit einer virtuellen Maschine verknüpften Abbild-Metadaten von einem Quell-Computer, auf dem ein der virtuellen Maschine entsprechendes Abbild gespeichert ist, auf einen Ziel-Computer beinhalten, wobei der Ziel-Computer das Abbild der virtuellen Maschine zunächst nicht enthält. Das Verfahren kann darüber hinaus das Booten der virtuellen Maschine im Ziel-Computer unter Verwendung der kopierten Abbild-Metadaten und das Ermöglichen beinhalten, dass die virtuelle Maschine im Ziel-Computer Daten des Abbilds im Quell-Computer liest, die erforderlich sind, um das Ausführen der virtuellen Maschine im Ziel-Computer fortzusetzen, wenn die benötigten Daten des Abbilds nicht im Ziel-Computer gespeichert sind. Das Verfahren kann darüber hinaus das Kopieren der gelesenen Daten des Abbilds vom Quell-Computer auf den Ziel-Computer beinhalten, wenn die gelesenen Daten des Abbildes nicht im Ziel-Computer gespeichert sind, wobei bei nachfolgenden Lesevorgängen der gleichen Daten die kopierten Daten im Ziel-Computer gelesen werden. Das Verfahren kann ferner das Setzen eines Bit in einer Bitmap beinhalten, um anzuzeigen, dass die gelesenen Daten im Ziel-Computer gespeichert sind.
  • Ein System für das bedarfsgesteuerte Streaming von Abbildern virtueller Maschinen kann in einem Aspekt einen Ziel-Computer beinhalten, der zum Kopieren von mit einer virtuellen Maschine verknüpften Abbild-Metadaten von einem Quell-Computer funktionsfähig ist, auf dem eine der virtuellen Maschine entsprechende Abbildvorlage gespeichert ist, wobei der Ziel-Computer die Abbildvorlage der virtuellen Maschine zunächst nicht enthält und eine Speichereinheit, die lokal an den Ziel-Computer angeschlossen ist. Der Ziel-Computer kann darüber hinaus funktionsfähig sein, um die virtuelle Maschine im Ziel-Computer unter Verwendung der kopierten Abbild-Metadaten zu booten und es der virtuellen Maschine im Ziel-Computer zu ermöglichen, Daten der Abbildvorlage im Quell-Computer zu lesen, die erforderlich sind, um das Ausführen der virtuellen Maschine im Ziel-Computer fortzusetzen, wenn die benötigten Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind. Der Ziel-Computer kann darüber hinaus funktionsfähig sein, um die gelesenen Daten der Abbildvorlage aus dem Quell-Computer in die lokal im Ziel-Computer angeschlossene Speichereinheit zu kopieren, wenn die gelesenen Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind, wobei nachfolgende Lesevorgänge der gleichen Daten aus der lokal im Ziel-Computer angeschlossenen Speichereinheit durchgeführt werden. Der Ziel-Computer kann darüber hinaus zum Setzen eines Bit in einer Bitmap funktionsfähig sein, um anzuzeigen, dass die gelesenen Daten im Ziel-Computer gespeichert sind.
  • Ferner kann ein computerlesbares Speichermedium bereitgestellt sein, auf dem ein Programm mit Anweisungen gespeichert ist, das von einer Maschine ausführbar ist, um eine oder mehrere hier beschriebene Verfahren durchzuführen.
  • Im Folgenden sind weitere Merkmale sowie die Struktur und der Betrieb verschiedener Ausführungsformen unter Bezugnahme auf die beiliegenden Zeichnungen ausführlich beschrieben. In den Zeichnungen bezeichnen gleiche Bezugszeichen identische oder funktional ähnliche Elemente.
  • KURZE BESCHREIBUNG DER MEHREREN ANSICHTEN DER ZEICHNUNGEN
  • 1 ist ein Schaubild, das Systemkomponenten und einen Betriebsablauf zeigt, der beim bedarfsgesteuerten Streaming von virtuellen Maschinen (VM) der vorliegenden Offenbarung gemäß einer Ausführungsform durchgeführt wird.
  • 2 zeigt eine vereinfachte Ansicht eines ODS-Abbildformats gemäß einer Ausführungsform der vorliegenden Offenbarung.
  • 3 ist einen ODS-Treiber in einem KVM/QEMU-Stack gemäß einer Ausführungsform der vorliegenden Offenbarung.
  • Die 4A und 4B zeigen einen Vergleich einer VM-Erstellung unter Verwendung eines Ursprungsabbilds und eines ODS-Abbilds gemäß einer Ausführungsform der vorliegenden Offenbarung.
  • 5 zeigt Systemkomponenten und einen Betriebsablauf für eine Live-Migration einer virtuellen Maschine mit einem lokalen Speicher durch das ODS der vorliegenden Offenbarung.
  • 6 ist ein Ablaufplan, der ein Verfahren gemäß einer Ausführungsform zum Erstellen einer neuen VM zeigt.
  • 7 ist ein Ablaufplan, der ein Verfahren gemäß einer Ausführungsform für die Live-Migration einer neuen VM zeigt.
  • Die 8A bis 8D zeigen mögliche unterschiedliche Anwendungsfälle unterschiedlicher Merkmale des ODS der vorliegenden Offenbarung gemäß einer Ausführungsform.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Ein bedarfsgesteuertes Abbild-Streaming (ODS) für Abbilder virtueller Maschinen kann bei einer Ausführungsform der vorliegenden Offenbarung einen Vorgang des Erstellens einer Kopie beim Schreiben (CoW), einen Vorgang des Erstellens einer Kopie beim Lesen (CoR) und einen Vorablesezugriff durchführen. Der Vorgang des Erstellens einer Kopie beim Schreiben vermeidet, dass ein Datensektor wiederholt aus einem Remote-Speicher-Server (z. B. Netzzugriffsspeicher, NAS) gelesen wird, indem eine Kopie des zurückgegebenen Sektors auf der lokalen Festplatte (z. B. Direktzugriffsspeicher, DAS) der Computer-Host-Maschine zur Verwendung gespeichert wird. Beim Vorablesezugriff wird eine Leerlaufzeit genutzt, um den Rest des Abbilds, auf den von der virtuellen Maschine nicht zugegriffen wurde, von einem Remote-Speicher-Server (z. B. NAS) auf die lokale Festplatte (z. B. DAS) zu kopieren. Während der Vorgänge des Erstellens einer Kopie beim Schreiben und des Erstellens einer Kopie beim Lesen stellt die vorliegende Offenbarung bei einer Ausführungsform das Aktualisieren sowohl von Daten als auch Metadaten auf einer Festplatte bereit, wobei die Metadaten anzeigen, dass die Daten jetzt auf der lokalen Festplatte (z. B. DAS) und nicht auf dem Remote-Speicher-Server (z. B. NAS) gespeichert sind.
  • Das ODS der vorliegenden Offenbarung kann bei einer Ausführungsform ein neues Abbildformat und den entsprechenden Blockeinheitentreiber für QEMU beinhalten. Das ODS der vorliegenden Offenbarung kann bei einer Ausführungsform für virtuelle Maschinen konzipiert sein, deren Abbilder im Direktzugriffsspeicher des Host-Computers gespeichert sind. Die Hauptanwendungsfälle des ODS können (1) das sofortige Erstellen einer virtuellen Maschine (VM) im Direktzugriffsspeicher (z. B. DAS, d. h. lokale Festplatte des Host), ohne dass auf den Abschluss des Kopiervorgangs der Abbildvorlage der VM vom Remote-Speicher-Server in den DAS gewartet wird, und (2) die Live-VM-Migration zwischen Maschinen, die DAS verwenden, um VMs zu betreiben, beinhalten.
  • Das ODS der vorliegenden Offenbarung kann gemäß einer Ausführungsform sowohl einen Vorgang des Erstellens einer Kopie beim Schreiben als auch einen Vorgang des Erstellens einer Kopien beim Lesen durchführen, um Daten schrittweise vom Remote-Speicher-Server auf die lokale Festplatte eines Host zu übertragen. Bei einer Cloud-Umgebung mit einer großen Anzahl von VMs vermeidet der Vorgang des Erstellens einer Kopie beim Lesen, dass der gleiche Datensektor wiederholt aus dem Remote-Speicher-Server gelesen, wodurch übermäßiger Netzwerkdatenverkehr oder Eingabe-/Ausgabe-(E/A-)Last im Speicher-Server erzeugt werden kann. Das ODS der vorliegenden Offenbarung kann gemäß einer Ausführungsform auch einen Vorablesezugriff durchführen. Es identifiziert Leerlaufzeit, um noch unberührte Abbilddaten vom Remote-Speicher-Server auf die lokale Festplatte des Host zu kopieren. Das Abbildformat des ODS kann bei einer Ausführungsform (1) eine Kopfzeile, (2) eine Bitmap, die anzeigt, ob die Datensektoren auf einer lokalen Festplatte oder im Remote-Speicher-Server liegen, und (3) den im Ursprungsformat gespeicherten Abbildinhalt beinhalten.
  • 1 ist ein Schaubild, das Systemkomponenten und einen Betriebsablauf zeigt, der vom bedarfsgesteuerten Streaming von virtuellen Maschinen (VM) der vorliegenden Offenbarung gemäß einer Ausführungsform durchgeführt wird. Ein Speicher-Server 102 speichert eine oder mehrere Abbildvorlagen 104 einer oder mehrerer entsprechender virtueller Maschinen. Der Speicher-Server 102 ist in Bezug auf einen Host-Computer 108, der eine virtuelle Maschine 106 betreibt und über ein Netzwerk 110 verbunden ist, entfernt angeordnet. Ein Beispiel für den Speicher-Server 102 kann ein NAS-Server sein. Der Speicher-Server 102 kann gemeinsam genutzt werden (z. B. ein gemeinsam genutzter Speicher-Server, SONAS) und kann über ein Network File System (NFS) exportierte Abbildvorlagen beinhalten. Ein Beispiel für eine lokale Festplatte 112 kann DAS sein. Ein DAS kann als flüchtiger Speicher angesehen werden, wogegen der NAS als flüchtiger Speicher erachtet werden kann. Ein flüchtiger Speicher kann verwendet werden, um ein Festplattenabbild einer VM, das das Stammdateisystem enthält, zu speichern. Wenn die VM erlischt, gehen Daten in einem flüchtigen Speicher verloren. Optional kann ein Benutzer einen permanenten Speicher an eine VM anschließen. Ein permanenter Speicher besteht über die Lebensdauer einer VM hinaus und kann beispielsweise verwendet werden, um permanente Daten einer zugehörigen Datenbank zu speichern. Bei einer Cloud-Umgebung wird ein flüchtiger Speicher von den lokalen Festplatten eines Host bereitgestellt, möglicherweise ohne Hardware-RAID.
  • VMs können auf der Grundlage von Nur-Lese-Abbildvorlagen 104 erstellt werden, die auf einem Speicher-Server 102 gespeichert und für alle Hosts (z. B. Computer oder Maschine, der bzw. die VMs betreibt oder auf dem bzw. der VMs ausgeführt werden) zugänglich sind. Eine virtuelle Festplatte 114 einer VM kann als reguläre Datei 116 im Dateisystem des Host gespeichert werden. Ein Host-Computer (ein Rechenknoten) 108 kann einen Hypervisor wie KVM beinhalten. Ein Hypervisor (oder ein VM-Monitor) ist eine Software-Komponente, die ermöglicht, dass mehrere Betriebssysteme gleichzeitig auf einer bestimmten Maschine (Hardware oder Prozessor) ausgeführt werden können. Je nach Hypervisor können mehrere Formate für virtuelle Festplatten 114 unterstützt werden. Beispielsweise unterstützt KVM/QEMU mehrere Formate für virtuelle Festplatten. KVM ist eine Linux-Kernel-Virtualisierungsinfrastruktur. Sie nutzt QEMU für die E/A-Emulation. Ein Ursprungsformat ist eine Byte-für-Byte-Kopie des in einer regulären Datei gespeicherten Inhalts einer physischen Blockeinheit. QCOW2 ist ein weiteres Abbildformat, das vom QEMU unterstützt wird. Das QCOW2-Abbild speichert nur geänderte Daten, nichtgeänderte Daten werden hingegen stets aus dem Sicherungsabbild (d. h. Speicher-Server, z. B. NAS) gelesen.
  • Zunächst enthält die lokale Festplatte 112 des Host-Computers 108 keine Abbildvorlage zum Ausführen einer ausgewählten virtuellen Maschine 106. Das ODS der vorliegenden Offenbarung kopiert gemäß einer Ausführungsform in Reaktion auf den Empfang einer Anweisung zum Starten oder Booten einer VM 106 kleine Abbild-Metadaten 118 vom Speicher-Server 104 auf die lokale Festplatte 112, wie bei 116 gezeigt. Die Abbild-Metadaten beinhalten eine Kopfzeile und eine Bitmap. Die Kopfzeile identifiziert die Abbildvorlage, und die Bitmap wird verwendet, um jene Abschnitte (z. B. Sektoren) der Abbildvorlage zu identifizieren, die lokal gespeichert sind. Im Ausgangszustand identifiziert die Bitmap gemäß einer Ausführungsform die Sektoren der Abbildvorlage, die zur Gänze mit Nullen gefüllt sind. Zur Laufzeit besteht kein Bedarf, diese mit Nullen gefüllten Sektoren vom Speicher-Server 104 auf der lokalen Festplatte 112 zu kopieren. Das ODS der vorliegenden Offenbarung kann bei einer weiteren Ausführungsform den Schritt des Kopierens von kleinen Abbild-Metadaten 118 aus dem Speicher-Server 104 auf die lokale Festplatte 112 auslassen, wie bei 116 gezeigt. In diesem Fall werden die Metadaten auf der lokale Festplatte 112 völlig neu erstellt, wobei alle Bits in der Bitmap so gesetzt werden, dass sie anzeigen, dass kein Datensektor lokal gespeichert ist. Die formale Ausführungsform hat den Vorteil, dass keine mit Nullen gefüllten Sektoren in die Abbildvorlage kopiert werden. Die VM 106 wird unter Verwendung der Abbild-Metadaten 118 gebootet, und wenn die VM 106 auf zusätzliche Daten 104 zugreift und diese aus dem Speicher-Server 102 liest, um sich zu booten und auszuführen, werden diese Daten als lokales Abbild 116 ebenfalls auf der lokale Festplatte 112 kopiert oder dort gespeichert. Das eine oder die mehreren Bits in der Bitmap werden ebenfalls aktualisiert, so dass sie anzeigen, dass die entsprechenden Datenabschnitte oder -sektoren der Abbildvorlage 104 lokal gespeichert wurden. Das nächste Mal, wenn die VM 106 auf die gleichen Daten zugreifen muss, wird die lokal gespeicherte Version verwendet und nicht über ein Netzwerk auf die Abbildvorlage 104 im Speicher-Server 102 zugegriffen.
  • Der Laufzeitbetrieb des ODS der vorliegenden Offenbarung kann die asynchronen Vorgänge des Erstellens einer Kopie beim Lesen, des Erstellens einer Kopie beim Schreiben und Vorablesezugriffe an Abbilddaten über das Netzwerk im Hintergrund beinhalten. Bei einem asynchronen Erstellen einer Kopie beim Lesen ruft ein um das ODS der vorliegenden Offenbarung erweiterter Hypervisor auf der Host-Maschine 108, wenn die VM 106 einen Sektor das erste Mal liest, den Sektor über das Netzwerk 110 aus dem Remote-Speicher-Server 102 ab. Im Hintergrund speichert der um das ODS der vorliegenden Offenbarung erweiterte Hypervisor im Host-Computer 108 bei einer Ausführungsform den Sektor in seiner lokalen ODS-Datei 116 und setzt die Bitmap entsprechend. Die Bitmap ist Teil des ODS-Abbilds und wird auf der lokalen Festplatte gespeichert. Bei nachfolgenden Lesevorgängen des Sektors werden die Daten bei einer Ausführungsform der vorliegenden Offenbarung stets direkt aus der lokalen ODS-Datei 116 bezogen. Um direkt auf die lokale Festplatte zu schreiben (Erstellen einer Kopie beim Schreiben), wenn die VM einen Sektor schreibt, schreibt der um das ODS der vorliegenden Offenbarung erweiterte Hypervisor im Host-Computer 108 gemäß einer Ausführungsform direkt in die lokale ODS-Datei 116, ohne dass 4 KB Daten aus dem Speicher-Server 102 abgerufen werden müssen. Das ODS der vorliegenden Offenbarung kann gemäß einer Ausführungsform auch einen Vorablesezugriff von Abbilddaten über das Netzwerk im Hintergrund durchführen. Im Rahmen einer konfigurierbaren Richtlinie kann der um das ODS der vorliegenden Offenbarung erweiterte Hypervisor im Host-Computer 108 als Hintergrundoperation gemäß einer Ausführungsform die gesamten Ursprungsabbilddaten 104 über das Netzwerk 110 mittels Streaming vorab lesen und die Daten in der lokalen ODS-Datei 116 speichern. Beispielsweise kann eine Vorablesezugriff-Richtlinie vorgeben, dass der Vorablesezugriff beginnen kann, nachdem die VM 106 für 12 Stunden ausgeführt wurde, sowie um Mitternacht, wenn die Arbeitslast im Netzwerk 110 und im Speicher-Server 102 gering ist. Folglich werden gemäß dieser beispielhaften Richtlinie keine Daten für eine VM vorab gelesen, deren Lebensdauer unter 12 Stunden liegt. Die Richtlinie kann gemäß einer Ausführungsform von einem Systemadministrator oder anderen Benutzern festgelegt werden.
  • 2 zeigt eine vereinfachte Ansicht eines ODS-Abbildformats gemäß einer Ausführungsform der vorliegenden Offenbarung. Eine virtuelle Festplatte im ODS-Format kann in 2 jeder VM zugeordnet werden, die auf einer Host-Maschine oder einem Host-Computer ausgeführt wird. In einem Aspekt basiert das ODS-Abbild auf einem Nur-Lese-Sicherungsabbild. Die ODS-Kopfzeile 202 speichert einen Verweis zum Sicherungsabbild 206, um die Abbildvorlage der virtuellen Maschine zu identifizieren. Ein Sicherungsabbild bezieht sich auf eine im permanenten Speicher gespeicherte Abbildvorlage einer virtuellen Maschine. Der Verweis kann der Dateiname der Abbildvorlage der virtuellen Maschine sein, z. B. eine Zeichenfolge, die den Namen des Ursprungsabbilds speichert, auf dem das ODS-Abbild basiert. Andere Verweise können verwendet werden, um die Abbildvorlage der virtuellen Maschine zu identifizieren. Das ODS-Abbildformat kann darüber hinaus eine Bitmap 204 beinhalten, beispielsweise mit einem Bit für jeden Datensektor im Abbild der virtuellen Festplatte. Das Bit zeigt an, ob der aktuelle Inhalt des entsprechenden Sektors im ODS-Abbild oder im Sicherungsabbild gespeichert ist. Beispielsweise wird ein Bit auf 1 gesetzt, wenn sein entsprechender Sektor bereits vom Ursprungsabbild in das ODS-Abbild kopiert wurde, oder wenn der Sektor von der VM bereits lokal geschrieben wurde. Die Größe der Bitmap ist bei einer Ausführungsform der vorliegenden Offenbarung proportional zur Größe der Abbildvorlage. Ein ODS-Blockeinheitentreiber ist beispielsweise in QEMU umgesetzt, der das ODS-Format unterstützt und von der VM ausgegebene Festplatten-Eingabe-/Ausgabe-Anfragen (E/A-Anfragen) bearbeitet. Der Speicherplatz für die Abbilddaten 208 kann zunächst leer sein; zu Beginn liegen keine Daten vor und es muss kein Speicherplatz reserviert werden. Die Größe des Speicherplatzes für die Abbilddaten 208 kann genauso groß wie jener der Abbildvorlage werden, aus der die Abbilddaten kopiert werden.
  • Das ODS-Abbildformat kann darüber hinaus Speicherplatz für erweiterte Festplattendaten 210 beinhalten. Der Speicherplatz für erweiterte Festplattendaten 210 kann willkürlicher Größe sein, und die Größe kann jederzeit verändert werden, um eine Größenänderung des Abbilds zu unterstützen. In einem Vorlagen-Abbild sind für diesen Speicherplatz 210 keine entsprechenden Daten vorhanden. Ferner wird keine Bitmap benötigt, die den Daten in diesem Speicherplatz 210 entspricht. Somit hängt die Größe der Bitmap nicht von der Größe des Speicherplatzes für die erweiterten Festplattendaten 210 ab; eine Größenänderung des ODS-Abbilds bedingt durch den Speicherplatz für die erweiterten Festplattendaten 210 beeinflusst die Bitmap nicht. Die Größenänderung eines ODS-Abbilds, um „Speicherplatz für erweiterte Festplattendaten” zu schaffen, ist unabhängig von der Größe der „erweiterten Festplattendaten” eine konstante Zeitoperation. Es muss lediglich das Feld „disk_size” in der „Kopfzeile” eines ODS-Abbilds verändert werden. Die Daten in diesem Speicherplatz 210 können nur lokal verwendet werden. Der Speicherplatz für erweiterte Festplattendaten ist optional.
  • Um eine neue VM zu starten, erstellt der Host auf seiner lokalen Festplatte (z. B. DAS) ein ODS-Abbild, dessen Verweis auf ein Sicherungsabbild auf die im Speicher-Server (z. B. NAS) gespeicherte Abbildvorlage 206 zeigt. Beispielsweise kann ein ODS-Abbild, das nur die Kopfzeile und die Bitmap enthält, auf die lokale Festplatte (z. B. DAS) kopiert werden. Die VM kann dann sofort gebootet werden, ohne dass Abbilddaten (Vorlagen-Abbild) vom Speicher-Server (z. B. NAS) auf die lokale Festplatte (z. B. DAS) kopiert werden, d. h., der Abschnitt 208 „Speicherplatz für Festplattendaten” des ODS-Abbilds ist zu Beginn leer. Beispielsweise kann die Bitmap für ein Original-Ursprungsabbild von 10 Gigabyte (GB) nur 2,5 Megabyte (MB) groß sein. Nur die 2,5-MB-Bitmap plus die kleinen Kopfzeilenfelder müssen über das Netzwerk kopiert werden, wenn eine neue VM erstellt und gebootet wird. Bei Bearbeitung einer Festplatten-Schreibanfrage von der VM kann der ODS-Treiber des QEMU die Daten im ODS-Abbild 208 speichern und die Bitmap 204 entsprechend aktualisieren. Dieses Verhalten wird als „Erstellen einer Kopie beim Schreiben” bezeichnet.
  • Beim Bearbeiten einer Festplatten-Leseanfrage von der VM überprüft der ODS-Treiber die Bitmap 204, um zu ermitteln, ob sich die angeforderten Daten im ODS-Abbild befinden. Ist dies der Fall, werden die Daten aus dem ODS-Abbild gelesen und an die VM zurückgegeben. Ist dies nicht der Fall, werden die Daten aus dem Sicherungsabbild 206 gelesen und an die VM zurückgegeben. Während die VM die zurückgegebenen Daten weiterhin im Hintergrund bearbeitet, wird eine Kopie der zurückgegebenen Daten im ODS-Abbild 208 gespeichert, und die Bitmap 204 wird entsprechend aktualisiert, so dass die Daten bei künftige Leseanfragen für die gleichen Daten aus dem ODS-Abbild von der lokalen Festplatte (z. B. DAS) und nicht aus dem Sicherungsabbild 208 im Speicher-Server (z. B. NAS) bezogen werden. Dieses Verhalten wird als „Erstellen einer Kopie beim Lesen” bezeichnet. Bei diesem Verhalten des Erstellens einer Kopie beim Lesen kann ein Datensektor höchstens einmal aus dem Speicher-Server (z. B. NAS) gelesen werden, wodurch übermäßiger Netzwerkdatenverkehr und E/A-Last im Speicher-Server (z. B. NAS) besser vermieden werden können.
  • Beim Vorgang des Erstellens einer Kopie beim Lesen wird der Inhalt des Sicherungsabbilds 206 schrittweise vom Speicher-Server (z. B. NAS) auf die lokale Festplatte (z. B. DAS) des Host-Computers migriert. Der Vorablesemechanismus des ODS kann darüber hinaus Leerlaufressourcen nutzen, um die Datenmigration zu beschleunigen. Tabelle 1 zeigt ein Beispiel für das ausführliche Layout eines ODS-Abbilds auf einer Festplatte gemäß einer Ausführungsform der vorliegenden Offenbarung. Tabelle 1
    Figure 00120001
    Figure 00130001
  • Im Abschnitt „disk_data” können Festplatteninhalte im Ursprungsformat gespeichert werden. Der Inhalt des Sektors mit der logischen Blockadresse LBA = n kann unter disk_data[n*512] gespeichert werden, wobei 512 die Sektorgröße ist.
  • 3 ist ein ODS-Treiber in einem KVM/QEMU-Stack (ein beispielhafter Hypervisor) gemäß einer Ausführungsform der vorliegenden Offenbarung. Ein Betriebssystem-Kernel 302, z. B. ein Linux-Kernel, kann auf einem Hardware-Prozessor 304 ausgeführt werden. Der Betriebssystem-Kernel 302 kann eine Vielzahl von Hypervisor-Programmen ausführen, z. B. KVM, eine unterschiedliche Anbieterversion von KVM usw. Ein weiteres Beispiel für einen Hypervisor ist Xen. Ein Hypervisor-Programm 306 (z. B. KVM) ermöglicht, dass eine virtuelle Maschine 310 im Hardware-Prozessor 304 ausgeführt werden kann. Darüber hinaus kann ein Hypervisor-Programm 306 mehrere virtuelle Abbildformate 308 unterstützen, z. B. raw, qcow2 und das ODS der vorliegenden Offenbarung. Beim Booten einer virtuellen Maschine 310 versucht die virtuelle Maschine, den ersten Sektor (z. B. 512 Kilobyte (KB)) auf der entsprechenden virtuellen Festplatte zu lesen (die Abbildformate 308 auf einer lokalen Festplatte). Ein Hypervisor-Programm, das erweitert wurde, um mit der Funktion des ODS der vorliegenden Offenbarung zu funktionieren, erkennt, dass das ODS-Abbild noch nicht auf der virtuellen Festplatte (lokale Festplatte) vorhanden ist und beginnt mit der ODS-Methodik der vorliegenden Offenbarung (führt diese aus). Beim ODS der vorliegenden Offenbarung wird ein Streaming der erforderlichen Daten durchgeführt, wie hier beschrieben, wobei die VM gemäß einer Ausführungsform beinahe sofort gebootet wird. Für die Umsetzung kann ein Hypervisor-Benutzeradressbereichs-Programm (z. B. ein qemu-kvm-Benutzeradressbereichs-Programm) verändert werden, um ods.c und ods.h hinzuzufügen, ohne andere Codes dabei zu verändern. Insbesondere sind keine Änderungen im Kernel des Computerknotens (z. B. Linux) erforderlich.
  • Die 4A und 4B zeigen Vergleiche hinsichtlich der VM-Erstellung unter Verwendung eines Ursprungsabbilds und eines ODS-Abbilds. Im gezeigten Beispiel werden drei VMs gleichzeitig erstellt. Wie in 4A ersichtlich, muss beim VM-Erstellungsverfahren unter Verwendung des Ursprungsabbildformats gewartet werden, bis eine gesamte Abbildvorlage vom Speicher-Server (z. B. NAS) auf die lokale Festplatte (z. B. DAS) kopiert worden ist, und erst dann wird die VM gebootet. Dies ist sogar der Fall, wenn ein Großteil der kopierten Abbilddaten während des VM-Bootvorgangs nicht erforderlich ist und während der gesamten Lebensdauer der VM womöglich nicht einmal auf diesen zugegriffen wird. Das ODS-Erstellungsverfahren der vorliegenden Offenbarung gemäß einer Ausführungsform ist in 4B gezeigt. Das ODS bootet die VM sofort, ohne dass sich Abbilddaten auf der lokalen Festplatte (z. B. DAS) befinden, und kopiert Daten nach Bedarf, d. h., wenn die VM darauf zugreift, vom Speicher-Server (z. B. NAS) auf die lokale Festplatte (z. B. DAS) des Host. Darüber hinaus identifiziert der Vorablesezugriff-Mechanismus des ODS Ressourcen-Leerlaufzeit, um den Rest des Abbilds oder Abschnitte des Abbilds, auf den bzw. auf die die VM noch nicht zugegriffen hat, vom Speicher-Server (z. B. NAS) auf die lokale Festplatte (z. B. DAS) zu kopieren. Der Vorablesezugriff kann dahingehend konservativ sein, dass das ODS, wenn es einen Konflikt bei Ressourcen erkennt (z. B. Speicher-Server, lokale Festplatte oder Netzwerk), den Vorablesezugriff vorübergehend anhalten und später wiederaufnehmen kann, wenn sich der Stau aufgelöst oder verringert hat. Bei einer weiteren Ausführungsform kann die vorliegende Offenbarung, nachdem Abbildvorlagen mithilfe des Vorablesezugriffs zur Gänze auf die lokale Festplatte kopiert wurden, gängige Abbildvorlagen auf einer lokalen Festplatte (z. B. DAS) des Host zwischenspeichern, so dass die zwischengespeicherten Abbildvorlagen zur sofortigen Erstellung von neuen VMs verwendet werden können, d. h., der Abbild-Kopierschritt wird bei einem Treffer im Cachespeicher übersprungen.
  • Das ODS der vorliegenden Offenbarung führt gemäß einer Ausführungsform einen Vorgang des Erstellens einer Kopie beim Lesen aus, um Datensektoren nach Datenbedarf vom Speicher-Server (z. B. NAS) in einen lokalen Speicher (z. B. DAS) zu übertragen. Optional kann beim ODS ein Vorablesezugriff aktiviert werden, um noch unberührte Datensektoren mithilfe nichtgenutzter Ressourcen im Leerlauf vom Speicher-Server (z. B. 1 bei 102) in den lokalen Speicher (z. B. 1 bei 112) zu kopieren. Das ODS der vorliegenden Offenbarung kann gemäß einer Ausführungsform auch einen Vorablesezugriff des gesamten Abbilds durchführen. Beim Vorablesezugriff des gesamten Abbilds nutzt das ODS der vorliegenden Offenbarung gemäß einer Ausführungsform Leerlaufressourcen, um das gesamte Abbild sequentiell, beispielsweise vom ersten Datensektor zum letzten Datensektor, vom Speicher-Server (z. B. NAS) in einen lokalen Speicher (z. B. DAS) zu kopieren. Gemäß einer Ausführungsform können Datensektoren, auf die noch nicht zugegriffen wurde und die eng mit Datensektoren in Zusammenhang stehen, auf die bereits zugegriffen wurde, bei einem standortbasierten Vorablesezugriff optional vorab gelesen werden, anstatt das gesamte Abbild einem sequentiellen Vorablesezugriff zu unterziehen. Gemäß einer Ausführungsform können Datensektoren, auf die noch nicht zugegriffen wurde, bei einem profilbasierten Vorablesezugriff optional entsprechend einem offline erstellten Abbildvorlagenprofil vorab gelesen werden. Das Profil kann die Reihenfolge des Vorablesezugriffes für Datensektoren auf der Grundlage ihrer Wichtigkeit priorisieren oder Datensektoren identifizieren, auf die für gewöhnlich gemeinsam zugegriffen wird, d. h., es wird ein Arbeitssatz unter Verwendung der Caching-Terminologie erstellt. Wenn ein Datensektorstatus bereits Sin_ods ist, wird dieser Datensektor beim Vorablesezugriff übersprungen. Nach abgeschlossenem Vorablesezugriff setzt es eine Markierung, z. B. all_data_in_ods_image, im ODS-Abbild (siehe z. B. Tabelle 1). Dann können alle gelesenen und geschriebenen, von der VM ausgegebenen Anfragen direkt im disk_data-Abschnitt des ODS-Abbilds arbeiten, ohne dass die Bitmap überprüft oder aktualisiert werden muss, da von vornherein bekannt ist, dass Daten im Sicherungsabbild nicht mehr benötigt werden.
  • Da die Daten, die vorab gelesen werden, nicht dringend benötigt werden, wird im Rahmen des Vorablesezugriffs versucht, Konflikte mit Ressourcen wie Prozessoren (z. B. CPU), Festplatten (z. B. DAS, NAS) und Netzwerk zu vermeiden. Der ODS-Treiber überwacht die Reaktionszeit Tr für das Lesen von Daten aus einem Speicher-Server (z. B. NAS) sowie die Reaktionszeit Tw für das Schreiben von Daten auf eine lokale Festplatte (z. B. DAS). Wenn Tr < Cr und Tw < Cw, setzt der ODS-Treiber den Vorablesezugriff fort, wobei Cr und Cw zwei konstante Grenzwerte sind, z. B. Cr = 30 Millisekunden (ms) und Cw = 30 ms. Wenn eine Reaktionszeit über dem Grenzwert liegt, generiert er eine zufällige Zahl, um eine Entscheidung darüber zu treffen, ob der Vorablesezugriff angehalten werden soll. Bei einer Ausführungsform setzt er den Vorablesezugriff mit einer 50%igen Wahrscheinlichkeit fort und hält ihn mit einer 50%igen Wahrscheinlichkeit für einen fixen Zeitraum an. Wenn er sich für ein Anhalten des Vorablesezugriffs entscheidet, setzt er diesen später fort, um zu überprüfen, ob sich der Ressourcenkonflikt aufgelöst hat, indem er eine kleine Datenmenge versuchsweise von einem Speicher-Server (z. B. NAS) auf eine lokale Festplatte (z. B. DAS) kopiert. Er überwacht die Reaktionszeiten und entscheidet, ob der Vorablesezugriff fortgesetzt oder weiter pausiert wird.
  • Da die Entscheidung über ein Anhalten des Vorablesezugriffs willkürlich erfolgt, wenn die Reaktionszeit über dem Grenzwert liegt, halten bei einer Ausführungsform der vorliegenden Offenbarung 50% der aktiv einen Vorablesezugriff ausführenden ODS-Instanzen, wenn mehrere ODS-Instanzen miteinander konkurrieren, den Vorablesezugriff nach jedem Durchlauf einer Vorablesezugriff-Operation an, bis entweder alle ODS-Instanzen den Vorablesezugriff einstellen oder der Engpass der Ressourcen aufgehoben ist.
  • Um Störungen zu verringern, werden die Reaktionszeiten als exponentielle gleitende Durchschnitte berechnet. T (n+1) / r = 0.9T (n) / r + 0.1Sr_new_sample (1) T (n+1) / w = 0.9T (n) / w + 0.1Sw_new_sample (2)
  • Im Gegensatz zu Ressourcenverwaltungssystemen, die mehrere gleichzeitige Festplatten-E/A-Anfragen senden, kann der Vorablesezugriff beim ODS der vorliegenden Offenbarung gemäß einer Ausführungsform in Bezug auf die Ressourcennutzung konservativ sein. Beispielsweise behält es höchstens eine ausstehende Leseanfrage an das Sicherungsabbild auf einem Speicher-Server (z. B. NAS) und höchstens eine ausstehende Schreibanfrage für das ODS-Abbild auf einer lokalen Festplatte (z. B. DAS). Nachdem es einige Datensektoren aus dem Speicher-Server (z. B. NAS) vorab gelesen hat, sendet es die nächste Leseanfrage sofort an den Speicher-Server (z. B. NAS) und schreibt gleichzeitig die zuvor zurückgegebenen Daten auf die lokale Festplatte (z. B. DAS). Wenn die Netzwerklatenz gering ist (wie es bei Rechenzentren der Fall ist) und das System konfliktfrei ist, kann es entweder den Speicher-Server (z. B. NAS) oder die lokale Festplatte (z. B. DAS) zu dessen vollständiger Nutzung ansteuern.
  • Eine Richtlinie kann festgelegt werden, um den Beginn des Vorablesezugriffs zu steuern. Beispielsweise kann der Vorablesezugriff beim Anwendungsfall einer schnellen VM-Erstellung so konfiguriert sein, dass er 12 Stunden nach der VM-Erstellung startet, so dass bei kurzlebigen VMs kein Vorablesezugriff durchgeführt wird. Bei einer VM-Migration kann der Vorablesezugriff so konfiguriert sein, dass er sofort nach der VM-Migration startet, so dass die Migration des Abbilds an der virtuellen Festplatte früher beendet werden kann.
  • Das ODS der vorliegenden Offenbarung kann gemäß einer weiteren Ausführungsform bei der Live-VM-Migration verwendet werden. In einer Cloud-Umgebung beispielsweise verbessert die Funktion der Live-VM-Migration die Cloud-Wartung und den Cloud-Betrieb erheblich. Mit der Zeit ist es beispielsweise unvermeidbar, dass ein Host einer Hardware-Wartung (z. B. Ersetzen eines unzuverlässigen CPU-Lüfters) oder einer Software-Wartung (z. B. Ausführen eines Sicherheits-Patches für den Hypervisor; bei KVM ist der Hypervisor Linux) unterzogen wird. Einige Wartungsvorgänge machen einen Neustart des Host erforderlich und können zu Ausfallzeiten von im Host ausgeführten VMs führen. Dank der Funktion der Live-VM-Migration können die betroffenen VMs auf andere Hosts migriert werden, bevor der Wartungsvorgang startet, so dass es zur keiner für den Benutzer wahrnehmbaren Ausfallzeit kommt.
  • Um eine VM von einem Quell-Host auf einen Ziel-Host zu migrieren, erfordern alle bestehenden Hypervisoren (darunter KVM, Xen und VMware), dass die Abbild-Datei der VM in einem gemeinsam genutzten Speicher gespeichert wird, auf den sowohl der Quell-Host als auch der Ziel-Host zugreifen kann. Sogar bei DAS ist es immer noch möglich, die Abbild-Datei der VM im Quell-Host für den Ziel-Host zugänglich zu machen (z. B. durch NFS), so dass die VM-Migration erfolgreich abgeschlossen werden kann. In diesem Fall werden jedoch alle von der VM im Ziel-Host erzeugten Festplatten-F/A-Anfragen an den Quell-Host geleitet und von diesem verarbeitet. Wird der Quell-Host neu gebootet, steht die Abbild-Datei nicht mehr zur Verfügung und die im Ziel-Host ausgeführte VM versagt.
  • Das ODS der vorliegenden Offenbarung unterstützt bei einer Ausführungsform die Live-Migration einer VM, die auf einer lokalen Festplatte (z. B. DAS) eines Host ausgeführt wird. 5 zeigt Systemkomponenten und einen Betriebsablauf für eine Live-Migration einer virtuellen Maschine mit einem lokalen Speicher durch das ODS der vorliegenden Offenbarung. Ein Quell-Host ist ein physischer Computer oder eine physische Maschine und führt eine VM 508 unter Verwendung des ODS-Abbilds 504 der VM auf deren lokaler Festplatte 510 aus. Ein Ziel-Host 506 ist ein weiterer physischer Computer oder eine weitere physische Maschine, auf den bzw. die die VM 508 migriert wird. Der besseren Erläuterung wegen wird die VM 508 im Quell-Host 502 als Quell-VM bezeichnet; die VM im Ziel-Host 506 wird als Ziel-VM 512 bezeichnet. Vor Beginn der Migration exportiert der Quell-Host 502 die Abbild-Datei 504 der VM über NFS auf den Ziel-Host, so dass der Ziel-Host über das Netzwerk auf die Abbild-Datei zugreifen kann. Der Ziel-Host 506 erstellt auf seiner lokalen Festplatte 514 (z. B. DAS) ein ODS-Abbild 516 mit einem Kopfzeilenfeld der Metadaten des ODS-Abbilds, das auf die vom Quell-Host exportierte Abbild-Datei als Sicherungsabbild verweist oder zeigt. Die VM 508 kann dann sofort migriert werden, ohne dass die Abbild-Datei 504 der VM tatsächlich vom Quell-Host 502 auf den Ziel-Host 506 kopiert werden muss. Das heißt, dass die Ziel-VM 512 im Ziel-Host 506 unter ausschließlicher Verwendung des ODS-Abbilds 516 gebootet werden kann, das zunächst nur einen Verweis auf ein Sicherungsabbild beinhaltet. Während die Ziel-VM 512 ununterbrochen im Ziel-Host 506 ausgeführt wird, ermöglicht das ODS der vorliegenden Offenbarung gemäß einer Ausführungsform, dass die Ziel-VM 512 Daten durch Erstellen einer Kopie beim Lesen einbringt. Darüber hinaus führt das ODS der vorliegenden Offenbarung gemäß einer Ausführungsform einen Vorablesezugriff durch, um den Rest des Abbilds vom Quell-Host 502 auf den Ziel-Host 506 zu kopieren. Nach abgeschlossenem Vorablesezugriff wird die Abbild-Datei 504 der VM vollständig auf den Ziel-Host 506 kopiert und die Ziel-VM 512 ist in keiner Weise mehr vom Quell-Host 502 abhängig. Der Quell-Host 502 kann dann zu Wartungszwecken heruntergefahren werden.
  • Bei den oben beschriebenen ODS-Vorgängen für die Live-Migration von virtuellen Maschinen mit lokalem Speicher kann eine VM sofort migriert werden, ohne dass Daten im lokalen Speicher bewegt werden. Eine migrierte VM (Ziel-VM) kann weiterhin am neuen Speicherort ausgeführt werden, und Daten können nach Bedarf der Ziel-VM kopiert werden. Die von der Ziel-VM erzeugten Schreibvorgänge werden lokal gespeichert. Die Leerlaufzeit für Ressourcen wird genutzt, um im Ausgangs-Host (Quell-Host) zurückgelassene Daten vorab zu lesen. Nachdem alle Daten vom Quell-Host auf den Ziel-Host vorab gelesen wurden, wird die Migration abgeschlossen.
  • 6 ist ein Ablaufplan, der ein Verfahren für das bedarfsgesteuerte Streaming von Abbildern virtueller Maschinen gemäß einer Ausführungsform zum Erstellen einer neuen VM zeigt. Bei 602 kann das Verfahren das Kopieren von mit einer ausgewählten virtuellen Maschine verknüpften Abbild-Metadaten von einem Speicher-Server in den lokalen Speicher eines Host-Computers beinhalten, auf dem eine oder mehrere Abbildvorlagen gespeichert sind, die jeweils einer oder mehreren virtuellen Maschinen entsprechen. Der lokale Speicher des Host-Computers beinhaltet zunächst keine Abbildvorlage der ausgewählten virtuellen Maschine. Bei 604 kann das Verfahren das Booten der ausgewählten virtuellen Maschine im Host-Computer unter Verwendung der kopierten Abbild-Metadaten beinhalten. Bei 606 kann das Verfahren das Ermöglichen beinhalten, dass die ausgewählte virtuelle Maschine Daten aus der Abbildvorlage auf dem Speicher-Server liest, die erforderlich sind, um das Ausführen der ausgewählten virtuellen Maschine im Host-Computer fortzusetzen, wenn die benötigten Daten nicht im lokalen Speicher des Host-Computers gespeichert sind. Bei 608 kann das Verfahren das Kopieren der gelesenen Daten der Abbildvorlage vom Speicher-Server in den lokalen Speicher des Host-Computers beinhalten, wenn die gelesenen Daten der Abbildvorlage nicht im lokalen Speicher des Host-Computers gespeichert sind. Nachfolgende Lesevorgänge der gleichen Daten werden aus dem lokalen Speicher des Host-Computers durchgeführt. Bei 610 kann das Verfahren auch das Setzen eines Bit in eine Bitmap beinhalten, um anzuzeigen, dass die gelesenen Daten im lokalen Speicher des Host-Computers gespeichert sind. Bei 612 werden Datenschreibvorgänge in die Abbildvorlage durch die ausgewählte virtuelle Maschine in den lokalen Speicher des Host-Computers geschrieben. Bei 614 kann die Ressourcen-Leerlaufzeit verwendet werden, um mit der ausgewählten virtuellen Maschine verknüpfte Daten der Abbildvorlage aus dem Speicher-Server in den lokalen Speicher des Host-Computers vorab zu lesen. In einem weiteren Aspekt können die Reaktionszeiten während des Abbild-Vorablesezugriffs überwacht werden, und der Vorablesezugriff kann vorübergehend angehalten werden, wenn eine lange Reaktionszeit ermittelt wird, beispielsweise wenn eine Reaktionszeit einen Grenzwert überschreitet.
  • In einem Aspekt beinhalten die Abbild-Metadaten, die vom Speicher-Server kopiert werden, zunächst einen Verweis auf die Abbildvorlage. Die Abbild-Metadaten können im lokalen Speicher des Host-Computers um eine Bitmap erweitert werden, die ein Bit einem entsprechenden Sektor der Abbildvorlage zuordnet. In einem weiteren Aspekt können die vom Speicher-Server kopierten Abbild-Metadaten neben dem Verweis auf die Abbildvorlage auch diese Bitmap beinhalten. Das entsprechende Bit in der Bitmap für die zur Ausführung der virtuellen Maschine erforderlichen Daten wird überprüft, um zu ermitteln, ob die zur Ausführung der ausgewählten virtuellen Maschine benötigten Daten der Abbildvorlage im lokalen Speicher des Host-Computers gespeichert sind. Je nach Bit in der Bitmap liest die ausgewählte virtuelle Maschine die Abbildvorlage im Speicher-Server oder die kopierte Abbildvorlage im lokalen Speicher des Host-Computers. Der Speicher-Server und der Host-Computer können Computer in einer Cloud-Umgebung sein, wobei beispielsweise eine Vielzahl von virtuellen Maschinen für Clients in der Cloud installiert ist.
  • 7 ist ein Ablaufplan, der ein Verfahren für ein bedarfsgesteuertes Streaming von virtuellen Maschinen zeigt, beispielsweise für eine VM-Live-Migration. Bei 702 kann das Verfahren das Kopieren von mit einer virtuellen Maschine verknüpften Abbild-Metadaten von einem Quell-Computer auf einen Ziel-Computer beinhalten, auf dem eine Abbildvorlage gespeichert ist, die der virtuellen Maschine entspricht. Der Ziel-Computer enthält die Abbildvorlage der virtuellen Maschine zunächst nicht. Bei 704 kann das Verfahren das Booten der virtuellen Maschine im Ziel-Computer unter dem Verwenden der kopierten Abbild-Metadaten beinhalten. Bei 706 kann das Verfahren das Ermöglichen beinhalten, dass die virtuelle Maschine im Ziel-Computer Daten der Abbildvorlage im Quell-Computer liest, die erforderlich sind, um das Ausführen der virtuellen Maschine im Ziel-Computer fortzusetzen, wenn die erforderlichen Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind. Bei 708 kann das Verfahren das Kopieren der gelesenen Daten der Abbildvorlage vom Quell-Computer auf den Ziel-Computer beinhalten, wenn die gelesenen Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind. Die nachfolgenden Lesevorgänge der gleichen Daten werden aus den kopierten Daten im Ziel-Computer durchgeführt. Bei 710 kann das Verfahren das Setzen eines Bits in eine Bitmap beinhalten, um anzuzeigen, dass die gelesenen Daten im Ziel-Computer gespeichert sind. Bei 712 werden Datenschreibvorgänge der virtuellen Maschine in den Ziel-Computer geschrieben. Bei 714 kann die Ressourcen-Leerlaufzeit genutzt werden, um mit der virtuellen Maschine verknüpfte Daten der Abbildvorlage aus dem Quell-Computer in den Ziel-Computer vorab zu lesen.
  • In einem Aspekt beinhalten die Abbild-Metadaten, die vom Quell-Computer kopiert werden, zunächst einen Verweis auf die Abbildvorlage. Die Abbild-Metadaten können im Ziel-Computer um eine Bitmap erweitert werden, die ein Bit einem entsprechenden Sektor der Abbildvorlage zuordnet. In einem weiteren Aspekt können die vom Quell-Computer kopierten Abbild-Metadaten neben dem Verweis auf die Abbildvorlage auch diese Bitmap beinhalten. Das entsprechende Bit in der Bitmap für die zur Ausführung der virtuellen Maschine erforderlichen Daten wird überprüft, um zu ermitteln, ob die zur Ausführung der virtuellen Maschine benötigten Daten im Ziel-Computer gespeichert sind. Je nach Bit in der Bitmap liest die virtuelle Maschine die Abbildvorlage im Quell-Computer oder die kopierte Abbildvorlage im Ziel-Computer. Das in 7 gezeigte Verfahren kann für eine Live-Migration der virtuellen Maschine direkt vom Quell-Computer auf den Ziel-Computer durchgeführt werden, ohne dass ein separater Speicher-Server verwendet werden muss. Die VM kann sofort migriert werden, ohne dass ihre Abbild-Datei migriert wird. Während die VM ununterbrochen im Ziel-Host ausgeführt wird, kann das ODS der vorliegenden Offenbarung gemäß einer Ausführungsform einen Vorgang des Erstellens einer Kopie beim Lesen und einen Vorablesezugriff durchführen, um die Abbild-Datei schrittweise vom Quell-Host auf den Ziel-Host zu migrieren. Nach abgeschlossenem Vorablesezugriff ist die VM nicht länger vom Quell-Host abhängig, der für Wartungszwecke heruntergefahren werden kann.
  • In einem Aspekt können die Merkmale des ODS (Erstellen einer Kopie beim Schreiben, Erstellen einer Kopie beim Lesen und Vorablesezugriff) einzeln aktiviert werden, um unterschiedliche Anwendungsfälle zu unterstützen. Die 8A bis 8D zeigen mögliche unterschiedliche Anwendungsfälle unterschiedlicher Merkmale des ODS der vorliegenden Offenbarung gemäß einer Ausführungsform. In 8A ist im ODS nur die Funktion des Erstellens einer Kopie beim Schreiben aktiviert. Diese einfachste Grundkonfiguration kann mit den folgenden Vorteilen als Ersatz für das bestehende COW-Abbildformat des QEMU verwendet werden: 1) ODS berücksichtigt die cache=none-Option und cache=writethrough-Option des QEMU und garantiert die Datenintegrität bei einem Stromausfall. 2) Der Bitmap-Abschnitt und der Festplattendaten-Abschnitt des ODS werden am Seitenrand korrekt ausgerichtet und bieten ausgezeichnete Leistung. Beim Setup von 8, das sowohl eine Cloud- als auch Nicht-Cloud-Umgebung sein kann, sind die Speicheroptionen für das ODS-Abbild und die Abbildvorlage flexibel. Beide können auf einer oder mehreren lokalen Festplatten (z. B. DAS) des Host gespeichert werden, beide können auf einem Speicher-Server (z. B. NAS) gespeichert werden oder eine wird auf einer oder mehreren lokalen Festplatten (z. B. DAS) des Host und die andere auf einem Speicher-Server (z. B. NAS) gespeichert.
  • Die Setups der 8B und 8C können sich für eine Cloud-Umgebung eignen, wobei eine Abbildvorlage auf einem Speicher-Server (z. B. NAS) und das ODS-Abbild auf einer lokalen Festplatte (z. B. DAS) des Host-Computers gespeichert wird. Sie unterstützen eine schnelle VM-Erstellung und können den Inhalt der Abbildvorlage schrittweise in das ODS-Abbild migrieren, um eine übermäßige Last im Netzwerk und im Speicher-Server (z. B. DAS) zu vermeiden.
  • 8D zeigt ein Setup, wobei die Abbildvorlage auf einem Speicher-Server (z. B. NAS) gespeichert wird, und die drei ODS-Abbilder auf einer lokalen Festplatte (z. B. DAS) eines Host-Computers gespeichert werden. Dieses Setup ermöglicht mehreren VMs, unterschiedliche ODS-Abbilder des Erstellens einer Kopie beim Schreiben zu verwenden und gleichzeitig eine einzelne Nur-Lese-Kopie des „ODS (Erstellen einer Kopie beim Lesen + Vorablesen)”-Abbilds gemeinsam zu nutzen, die im lokalen Speicher (z. B. DAS) einen Spiegel des Inhalts der Abbildvorlage bietet. Bei diesem Setup wird das mehrfache Kopieren des Inhalts der Abbildvorlage jeweils für eine andere VM von einem Remote-Netzwerkspeicher-Server (z. B. NAS) in einen lokalen Speicher (z. B. DAS) eines Host vermieden.
  • Die vorliegende Offenbarung stellt auch die Datenintegrität bereit. Man nehme an, dass die folgenden Ereignisse hintereinander auftreten: (1) die VM sendet eine Festplatten-Schreibanfrage; (2) der ODS-Treiber (nach gewisser Verarbeitung) bestätigt den erfolgreichen Abschluss des Schreibvorgangs; und (3) die Stromzufuhr des Host wird sofort unterbrochen. Nachdem die Stromzufuhr wiederhergestellt ist, sollte bei dem nächsten Lesevorgang der VM des gleichen Sektors der vor dem Ausfall geschriebene Inhalt bezogen werden.
  • Tabelle 1 (oben) zeigt ein beispielhaftes Layout für ein ODS-Abbild auf einer Festplatte gemäß einer Ausführungsform der vorliegenden Offenbarung. Das ODS der vorliegenden Offenbarung bewahrt gemäß einer Ausführungsform die Datenintegrität unabhängig vom Zeitpunkt des Stromausfalls. Beispielsweise wenn ein Vorgang des Erstellens einer Kopie beim Schreiben und ein Vorgang des Erstellens einer Kopie beim Lesen ausgeführt wird, kann das ODS der vorliegenden Offenbarung bei einer Ausführungsform die Festplattendaten und die Bitmap getrennt aktualisieren. Bei einem Stromausfall zwischen den beiden Aktualisierungen wird die Datenintegrität bei der vorliegenden Offenbarung gemäß einer Ausführungsform weiterhin nicht beeinträchtigt, wie im Folgenden erläutert.
  • Ein Bit in der Bitmap kann in einem von zwei Status vorliegen, Sin_backing=0 oder Sin_ods=1, was bedeutet, dass sich der Inhalt des entsprechenden Sektors im Sicherungsabbild bzw. im ODS-Abbild befindet. Ein Status eines Sektors kann sich nur von Sin_backing zu Sin_ods und niemals von Sin_ods zu Sin_backing ändern. Es gibt zwei Szenarien, die den Status eines Sektors von Sin_backing zu Sin_ods ändern können: Erstellen einer Kopie beim Schreiben und Erstellen einer Kopie beim Lesen.
  • Ein Vorgang des Erstellens einer Kopie beim Schreiben wird durchgeführt, wenn das ODS eine Festplatten-Schreibanfrage von der VM bearbeitet. Der Kürze wegen wird bei der folgenden Erörterung davon ausgegangen, dass die Schreibanfrage sich über zwei Festplattensektoren (d1, d2) erstreckt. Man nehme an, bit(d1) und bit(d2) bezeichnen die Status von d1 bzw. d2 in der Bitmap. Es sei ferner angenommen, dass vor dem Schreibvorgang bit(d1) = Sin_backing und bit(d2) = Sin_backing gilt. Andere Fälle, bei denen mehr Datensektoren und unterschiedliche Ausgangstatus berücksichtigt werden, können ähnlich wie im folgenden Beispiel analysiert werden.
  • Das Bearbeiten der Schreibanfrage beim ODS kann den folgenden Operationsablauf beinhalten:
    • • ODS-W1: Die VM gibt eine Schreibanfrage für zwei Sektoren (d1, d2) aus.
    • • ODS-W2: Der ODS-Treiber speichert d1 im disk_data-Abschnitt des ODS auf der Festplatte.
    • • ODS-W3: Der ODS-Treiber speichert d2 im disk_data-Abschnitt des ODS auf der Festplatte.
    • • ODS-W4: Der ODS-Treiber aktualisiert bit(d1) von Sin_backing auf Sin_ods.
    • • ODS-W5: Der ODS-Treiber aktualisiert bit(d2) von Sin_backing auf Sin_ods.
    • • ODS-W6: Der ODS-Treiber bestätigt den Abschluss des Schreibvorgangs gegenüber der VM.
  • Es sei angemerkt, dass bit(d1) und bit(d2) zum gleichen Sektor gehören können und ODS-W4 und ODS-W5 somit im Rahmen einer einzelnen Aktualisierung durchgeführt werden können. Für eine Worst-Case-Analyse sind ODS-W4 und ODS-W5 zu trennen.
  • Der Host kann nach jedem der obigen Schritte ausfallen. Die vorliegende Offenbarung zeigt, dass das ODS die Datenintegrität ausfallunabhängig bewahrt. Insbesondere führt das ODS im Vergleich zu möglichen Szenarien beim Ursprungsabbildformat zu keiner weiteren Erschwernis. Das heißt, dass die Datenintegrität beim ODS zumindest genauso gut wie die Datenintegrität im Ursprungsabbildformat ist.
  • Wenn die VM das Ursprungsabbildformat verwendet, beinhaltet das Bearbeiten dieser Festplattenschreibung den folgenden Operationsablauf:
    • • RAW-W1: Die VM gibt eine Schreibanfrage für zwei Sektoren (d1, d2) aus.
    • • RAW-W2: Der Ursprungs-Treiber (RAW driver) speichert d1 auf der Festplatte.
    • • RAW-W3: Der Ursprungs-Treiber speichert d2 auf der Festplatte.
    • • RAW-W4: Der ODS-Treiber bestätigt den Abschluss des Schreibvorgangs gegenüber der VM.
  • Vor dem Schreibvorgang der VM werden die „alten” Inhalte von d1 und d2 im Sicherungsabbild gespeichert. Nach dem Schreibvorgang der VM werden deren „neue” Inhalte im ODS-Abbild gespeichert. Die Ausfallsszenarien bei ODS im Einzelnen:
    • • Ausfall nach ODS-W1. In diesem Fall entspricht das Verhalten des ODS einem Stromausfall beim Ursprungsabbildformat nach RAW-W1. Dadurch wird erzielt, dass der Schreibvorgang einfach verloren geht, was ein zulässiges, korrektes Verhalten ist, da der Treiber den Abschluss des Schreibvorgangs gegenüber der VM noch nicht bestätigt hat.
    • • Ausfall nach ODS-W2. In diesem Fall wird d1 in das ODS-Abbild geschrieben, aber bit(d1) wird nicht aktualisiert und bleibt Sin_backing. Nachdem die Stromzufuhr wiederhergestellt ist, wird der Inhalt des nächsten Lesevorgangs der VM von d1 aus dem Sicherungsabbild bezogen, als würde der neue d1-Inhalt im ODS-Abbild nicht bestehen. Dieses Verhalten ist korrekt und entspricht einem Stromausfall beim Ursprungsabbildformat nach RAW-W1. Dadurch wird erzielt, dass der Schreibvorgang einfach verloren geht, was ein zulässiges, korrektes Verhalten ist, da der Treiber den Abschluss des Schreibvorgangs gegenüber der VM noch nicht bestätigt hat.
    • • Ausfall nach ODS-W3. Ähnlich wie oben bezieht der nächste Lesevorgang der VM von d1 oder d2 nach Wiederherstellung der Stromzufuhr den alten Inhalt aus dem Sicherungsabbild, als würde der neue Inhalt im ODS-Abbild nicht bestehen. Dieses Verhalten ist korrekt und entspricht einem Stromausfall beim Ursprungsabbildformat nach RAW-W1. Ausfall nach ODS-W4. Nachdem die Stromzufuhr wiederhergestellt ist, bezieht der nächste Lesevorgang der VM von d1 dessen neuen Inhalt aus dem ODS-Abbild, während der nächste Lesevorgang der VM von d2 dessen alten Inhalt aus dem Sicherungsabbild bezieht (weil bit(d1) = Sin_ods und bit(d2) = Sin_backing). Dieses Verhalten ist korrekt und entspricht einem Stromausfall beim Ursprungsabbildformat nach RAW-W2.
    • • Ausfall nach ODS-W5. Nachdem die Stromzufuhr wiederhergestellt ist, bezieht der nächste Lesevorgang der VM von d1 oder d2 den neuen Inhalt aus dem ODS-Abbild (weil bit(d1) = Sin_ods und bit(d2) = Sin_ods). Dieses Verhalten ist korrekt und entspricht einem Stromausfall beim Ursprungsabbildformat nach RAW-W3, d. h., der Schreibvorgang wird abgeschlossen, aber noch nicht bestätigt.
    • • Ausfall nach ODS-W6. Nachdem die Stromzufuhr wiederhergestellt ist, bezieht der nächste Lesevorgang der VM von d1 oder d2 den neuen Inhalt aus dem ODS-Abbild (weil bit(d1) = Sin_ods und bit(d2) = Sin_ods). Dieses Verhalten ist korrekt und entspricht einem Stromausfall beim Ursprungsabbildformat nach RAW-W4.
  • Die obige Analyse belegt, dass das ODS der vorliegenden Offenbarung gemäß einer Ausführungsform die Datenintegrität während eines Vorganges des Erstellens einer Kopie beim Schreiben bewahren kann. Mit einem ähnlichen Verfahren kann belegt werden, dass das ODS der vorliegenden Offenbarung bei einer Ausführungsform auch die Datenintegrität während eines Vorganges des Erstellens einer Kopie beim Lesen bewahren kann, indem die korrekte Aktualisierungsabfolge eingehalten wird – zuerst wird der Festplattendaten-Abschnitt und danach der Bitmap-Abschnitt des ODS-Abbilds aktualisiert.
  • Eine Umsetzung des ODS der vorliegenden Offenbarung kann gemäß einer Ausführungsform den Festplatten-Eingabe-/Ausgabe-(E/A-)Verarbeitungsaufwand verringern. Beispielsweise kann eine unbefangene Umsetzung des ODS im Vergleich zum Ursprungsabbildformat Verarbeitungsaufwand im Zusammenhang mit dem Lesen und Schreiben der Bitmap erzeugen. Im Worst-Case-Szenario kann ein Satz sequentieller Schreibanfragen der VM die nachstehende Schreibabfolge im Dateisystem des Host bewirken: Schreiben von s1, Schreiben von s2, Schreiben von bit(s2), Schreiben von s3, Schreiben von bit(s3) ... usw. Hier sind s1, s2 und s3 Sektoren mit einer aufeinanderfolgenden logischen Blockadresse, und bit(si) ist das entsprechende Bit von si in der Bitmap. Bei diesem Beispiel kann sich der Festplattenkopf zwischen dem Festplattendaten-Abschnitt und dem Bitmap-Abschnitt des ODS-Abbilds hin- und her bewegen. Gemäß einer Ausführungsform der vorliegenden Offenbarung wird eine Technik dargeboten, mit der der Verarbeitungsaufwand im Zusammenhang mit dem Aktualisieren der Bitmap in den meisten Fällen umgangen wird, ohne die Datenintegrität zu beeinträchtigen.
  • In einer Cloud-Umgebung ist die Größe der Abbildvorlage einer VM für gewöhnlich um einiges kleiner als der flüchtige Speicherplatz, der der VM zugewiesen ist. Beispielsweise sind 10 GB die maximal zulässige Abbildvorlagengröße für eine bekannte, im DAS ausgeführte VM, während sich der für diese VM bereitgestellte flüchtige Speicherplatz auf 170 GB oder mehr beläuft. Der zusätzliche flüchtige Speicherplatz kann für die VM entweder durch Erweitern der Stammfestplatte der VM auf Grundlage der Abbildvorlage oder durch Anschließen von zusätzlichen virtuellen Festplatten an die VM bereitgestellt werden. Eine weitere bekannte Cloud zielt auf Unternehmenskunden ab und bietet flexiblere Konfigurationen. Sie ermöglicht einer VM, eine Stammfestplatte mit einer Größer von viel mehr als 10 GB zu verwenden.
  • Im Folgenden wird das Verfahren zum Erstellen einer Linux-Abbildvorlage in einer Cloud beschrieben. Die Abbildvorlage verwendet das Ursprungsabbildformat. Es wird von einer anfänglichen Abbildvorlagengröße von 50 GB ausgegangen. Zunächst wird sie mit der erforderlichen Software installiert und vollständig getestet. Danach wird die Größe des ext3-Dateisystems in der Abbildvorlage mithilfe des resize2fs-Tools auf dessen Mindestgröße geändert (z. B. von 50 GB auf 12 GB). Die Abbildvorlage wird schließlich gekürzt, um der Mindestgröße des Dateisystems zu entsprechen (z. B. von 50 GB auf 12 GB). Beim Größenänderungs- und Kürzungsschritt werden überflüssige Daten entfernt, die während der Installation und des Testvorgangs erzeugt wurden, und es wird eine Abbildvorlage in Mindestgröße produziert. Eine kleine Abbildvorlage hilft dabei, die Menge an vom NAS in den DAS übertragenen Daten beim Erstellen von neuen VMs auf Grundlage der Abbildvorlage zu verringern.
  • Gemäß dem obigen Beispiel kann die 12-GB-Abbildvorlage verwendet werden, um VMs zu erstellen, deren Stammfestplattengröße variieren kann, abhängig davon, wie viel der Kunde bezahlt. Beispielsweise erstellt der folgende QEMU-Befehl ein 100-GB-ODS-Abbild im DAS auf Grundlage der im NFS gespeicherten 12-GB-Abbildvorlage.
    qemu-img create -f ods -b /nfs/template.raw vm.ods 100G
  • Nachdem die Partitionsgröße der virtuellen Festplatte mit fdisk von 12 GB auf 100 GB erweitert wurde, kann resize2fs verwendet werden, um das ext3-Dateisystem im ODS-Abbild von 12 GB auf 100 GB zu erweitern, das zum großen Stammdateisystem der VM wird. Es sei angemerkt, dass das Verwenden von resize2fs zur Erweiterung eines Dateisystems ein schneller Vorgang ist, da dabei keine Neuanordnung von Blöcken erforderlich ist.
  • Beim in Tabelle 1 gezeigten ODS-Abbildformat ist die Festplattendatengröße die Größe des ODS-Abbilds, die von der VM wahrgenommen wird, und die effektive Sicherungsabbildgröße ist die Größe des Sicherungsabbilds. Beim obigen Beispiel ist die Festplattendatengröße = 100 GB und die effektive Sicherungsabbildgröße = 12 GB.
  • 2 zeigt das Konzept, bei dem das ODS-Abbild größer als das Sicherungsabbild sein kann. Im Fall eines Datensektors, dessen logische Blockadresse (LBA) über die Größe des Sicherungsabbilds hinaus geht, kann dessen Inhalt nicht im Sicherungsabbild, sondern nur im ODS-Abbild vorhanden sein. Da der Status des Sektors von vornherein bekannt ist, muss der Status des Sektors nicht im Bitmap-Abschnitt des ODS-Abbilds erfasst werden. Folglich ist die Größe der Bitmap proportional zur Größe des Sicherungsabbilds und nicht zur Größe des ODS-Abbilds.
  • Bei einem 2-TB-ODS-Abbild, das auf ein 10-GB-Sicherungsabbild zeigt, beläuft sich die Größe der Bitmap lediglich auf 2,5 MB. Die gesamte Bitmap kann aufgrund ihrer geringen Größe leicht im Arbeitsspeicher zwischengespeichert werden, wodurch der Verarbeitungsaufwand im Zusammenhang mit dem wiederholten Lesen der Bitmap aus der Festplatte vermieden wird. Bei einer bekannten Cloud sind 10 GB die maximal zulässige Abbildvorlagengröße für eine VM, die in einem DAS ausgeführt wird. Bei Bearbeitung einer Leseanfrage von der VM für einen Sektor S, dessen logische Blockadresse (LBA) über die Größe des Sicherungsabbilds hinaus geht, weiß der ODS-Treiber lediglich auf der Grundlage der LBA, dass dieser Sektor nicht im Sicherungsabbild vorhanden sein kann und liest ihn folglich aus dem Festplattendaten-Abschnitt des ODS-Abbilds. Bei Bearbeitung einer Schreibanfrage von der VM für den Sektor S schreibt der ODS-Treiber die Daten direkt in den Festplattendaten-Abschnitt und die Bitmap muss nicht aktualisiert werden (tatsächlich gibt es nicht einmal die entsprechenden Bits für Sektor S in der Bitmap).
  • Da die Abbildvorlage mithilfe von resize2fs auf ihre Mindestgröße verringert wurde und die Daten in der Abbildvorlage, weil es sich um eine Vorlage handelt, vorwiegend Nur-Lese-Zugriff bieten (z. B. programmausführbar sind), zielen die meisten Festplatten-Schreibanfragen der VM auf jene Sektoren ab, deren Adressen über die Größe des Sicherungsabbilds hinaus gehen. Bei diesen Schreibanfragen schreibt der ODS-Treiber die Daten direkt auf eine lokale Festplatte (z. B. DAS) und es entsteht kein Verarbeitungsaufwand im Zusammenhang mit der Aktualisierung der Bitmap.
  • Im Folgenden wird eine Optimierung für Abbildvorlagen mit freien Bereichen, bei denen viele Datensektoren mit Nullen gefüllt sind, gemäß einer Ausführungsform der vorliegenden Offenbarung beschrieben. Für eine -Ursprungsabbildvorlage image.raw kann das qemu-img-Tool verwendet werden, um eine ODS-Abbildvorlage image.ods zu erstellen, deren Sicherungsabbild image.raw ist. Die Größe von image.ods entspricht der Größe von image.raw. Beim Erstellen von image.ods kann qemu-img nach mit Nullen gefüllten Sektoren S suchen und deren Status in der Bitmap auf Sin_ods setzen. Die Status für Sektoren ohne Nullen werden auf Sin_backing gesetzt. Zur Laufzeit, wenn die VM den Sektor S liest, dessen Status Sin_ods ist, liest der ODS-Treiber aus dem Festplattendaten-Abschnitt des ODS-Abbilds und erhält einen mit Nullen gefüllten Sektor zurück, wobei dies das gewünschte Verhalten ist. Dies geschieht, weil das ODS-Abbild im Dateisystem des Host als Datei mit freien Bereichen gespeichert wird und der Sektor S noch nie geschrieben wurde, und somit gibt das Betriebssystem (BS) des Host einen mit Nullen gefüllten Sektor zurück.
  • Die ODS-Abbildvorlage image.ods wird gemeinsam mit image.raw im NAS gespeichert. Beim Erstellen einer neuen VM auf einem Host kopiert es image.ods von einem Speicher-Server (z. B. NAS) auf eine lokale Festplatte (z. B. DAS) und ändert die Größe von image.ods auf die größere Zielgröße. Das Kopieren von image.ods geht schnell, da dessen Festplattendaten-Abschnitt leer und die Größe von image.ods somit klein ist. Insbesondere ist image.ods für ein 10-GB-image.raw nur ungefähr 2,5 MB groß. Das Ändern der Größe von image.ods in eine größere virtuelle Festplatte kann nur das Aktualisieren des disk_data_size-Felds in Tabelle 1 auf einen größeren Wert beinhalten. Wenn die VM bootet, kürzt der ODS-Treiber den Festplattendaten-Abschnitt automatisch auf die im disk_data_size-Feld angegebene Größe.
  • Wenn eine VM bootet, lädt der ODS-Treiber den Bitmap-Abschnitt der ODS-Abbilder von der Festplatte in den Arbeitsspeicher, der die Ausgangsstatus der Datensektoren enthält. Bei der vorliegenden Offenbarung werden diese beiden Bitmap-Kopien als On-Disk-Status bzw. In-Memory-Status bezeichnet. Zur Laufzeit hält der ODS-Treiber den In-Memory-Status stets auf dem neuesten Stand, kann den On-Disk-Status hingegen allmählich aktualisieren, um den Festplatten-E/A-Verarbeitungsaufwand zu verringern. Bei einem Stromausfall ist jedoch gewährleistet, dass veraltete Informationen im On-Disk-Status die Datenintegrität niemals beeinträchtigen.
  • Wenn die VM einen Sektor liest, dessen In-Memory-Status Sin_ods ist, liest der ODS-Treiber den Sektor aus dem ODS-Abbild und gibt ihn an die VM zurück. Es ist kein weiterer Verarbeitungsaufwand damit verbunden. Wenn die VM einen Sektor liest, dessen In-Memory-Status Sin_backing ist, liest der ODS-Treiber den Sektor aus dem Sicherungsabbild und gibt ihn an die VM zurück. Nachdem die VM die Verarbeitung der zurückgegebenen Daten im Hintergrund fortgesetzt hat (d. h. asynchron), schreibt der ODS-Treiber den Inhalt des Sektors in den Festplattendaten-Abschnitt des ODS-Abbilds und aktualisiert den In-Memory-Status des Sektors von Sin_backing auf Sin_ods. Der On-Disk-Status des Sektors wird jedoch nicht aktualisiert und bleibt Sin_backing, wodurch der Festplatten-E/A-Verarbeitungsaufwand verringert wird. Die ”genutzten” Bits des In-Memory-Status können gelöscht werden, um den On-Disk-Status allmählich zu aktualisieren, entweder periodisch (z. B. einmal stündlich) oder wenn die VM herunterfährt. Wenn die Stromzufuhr des Host unterbrochen wird, bevor der On-Disk-Status aktualisiert wurde, lädt der ODS-Treiber nach Wiederherstellung der Stromzufuhr den veralteten On-Disk-Status erneut in den Arbeitsspeicher und der Status des Sektors wird als Sin_backing beibehalten. Bei Bearbeitung des nächsten Lesevorgangs der VM dieses Sektors wiederholt der ODS-Treiber den Vorgang des Erstellens einer Kopie beim Lesen erneut: Lesen des Sektors aus dem Sicherungsabbild, Zurückgeben des Sektors an die VM, asynchrones Schreiben des Sektors in das ODS-Abbild und Aktualisieren des In-Memory-Status von Sin_backing auf Sin_ods. Ohne den On-Disk-Status während des Vorgangs des Erstellens einer Kopie beim Schreiben sofort zu aktualisieren, bezieht die VM nach Wiederherstellung dennoch den korrekten Sektorinhalt, auch wenn sie den bereits in das ODS-Abbild kopierten Inhalt des Sektors ignorieren kann.
  • Wenn die VM in einen Sektor schreibt, überprüft der ODS-Treiber den On-Disk-Status (im Gegensatz zum In-Memory-Status), um die adäquate Aktion zu ermitteln. Wenn der On-Disk-Status des Sektors Sin_ods ist (der In-Memory-Status des Sektors ist ebenfalls Sin_ods), schreibt der ODS-Treiber den Sektor direkt in das ODS-Abbild und bestätigt gegenüber der VM, dass der Schreibvorgang abgeschlossen ist. Es fällt kein Verarbeitungsaufwand im Zusammenhang mit der Bitmap-Aktualisierung an. Wenn der On-Disk-Status des Sektors Sin_backing ist (der In-Memory-Status des Sektors kann entweder Sin_backing oder Sin_ods sein), schreibt der ODS-Treiber den Sektor in das ODS-Abbild, aktualisiert den On-Disk-Status auf Sin_ods (und aktualisiert auch den In-Memory-Status auf Sin_ods, wenn er derzeit Sin_backing lautet) und bestätigt gegenüber der VM, dass der Schreibvorgang abgeschlossen ist. In diesem Fall kann es zu einem Verarbeitungsaufwand im Zusammenhang mit der Aktualisierung des On-Disk-Status kommen.
  • Bei einer weiteren Ausführungsform kann eine asynchrone Umsetzung bereitgestellt werden, die den Arbeitsspeicher-Verarbeitungsaufwand verringert. Alle Blockeinheitentreiber in QEMU setzen die BlockDriver-Schnittstelle um, die APIs für sowohl eine synchrone E/A als auch eine asynchrone E/A bereitstellt. Erstere ermöglicht der Blockeinheit lediglich, jeweils nur eine ausstehende E/A-Anfrage zu bearbeiten. Letzere ermöglicht der Blockeinheit, mehrere ausstehende E/A-Anfragen gleichzeitig zu bearbeiten, indem der Blockeinheitentreiber die VM mithilfe von Callback-Funktionen über den Abschluss der E/A-Vorgänge informiert.
  • Das ODS der vorliegenden Offenbarung setzt gemäß einer Ausführungsform die asynchrone Schnittstelle um. Bei wenigen Ausnahmefällen wird die Durchführung von Vorgängen des Erstellens einer Kopie beim Schreiben und des Erstellens einer Kopie beim Lesen im gleichen Datensektor mit Vorsicht gehandhabt. Man nehme an, dass die VM eine Leseanfrage Rd für einen Datensektor d sendet, dessen In-Memory-Status Sin_backing ist, und dann eine Schreibanfrage Wd für den gleichen Sektor d sendet, bevor der Lesevorgang abgeschlossen ist. Man nehme an, dass der ODS-Treiber bei Bearbeitung dieses Falls die Operationen in der nachstehenden Reihenfolge beendet:
    • 1. Lesen des alten Inhalts des Sektors aus dem Sicherungsabbild im Rahmen des Vorganges des Erstellens einer Kopie beim Lesen für Rd.
    • 2. Schreiben des neuen Inhalts des Sektors in das ODS-Abbild im Rahmen des Vorganges des Erstellens einer Kopie beim Schreiben für Wd.
    • 3. Schreiben des alten Inhalts des Sektors in das ODS-Abbild im Rahmen des Vorganges des Erstellens einer Kopie beim Lesen für Rd.
  • Es kann zu einer Konkurrenzsituation kommen, wenn ein Vorgang des Erstellens einer Kopie beim Schreiben und ein Vorgang des Erstellens einer Kopie beim Lesen für den gleichen Datensektor ausgeführt werden. Im ODS-Abbild bleibt sodann der alte Inhalt des Sektors zurück, was ein falsches Ergebnis ist. Um diese und andere ähnliche Konkurrenzsituationen richtig handhaben zu können, überprüft der ODS-Treiber, bevor er einen Vorgangs des Erstellens einer Kopie beim Lesen für einen Datensektor d ausführt, ob für d ein ausstehender Vorgang des Erstellens einer Kopie beim Schreiben vorliegt. Ist dies der Fall, wird der Vorgang des Erstellens einer Kopie beim Lesen eingestellt. Gleichermaßen überprüft der ODS-Treiber, bevor er einen Vorgang des Erstellens einer Kopie beim Schreiben für einen Datensektor d ausführt, ob für d ein ausstehender Vorgang des Erstellens einer Kopie beim Lesen vorliegt. Ist dies der Fall, wird der Vorgang des Erstellens einer Kopie beim Schreiben verzögert, bis der ausstehende Vorgang des Erstellens einer Kopie beim Lesen abgeschlossen wurde, wodurch gewährleistet wird, dass der neue Inhalt auf der Festplatte zurückbleibt.
  • Das ODS der vorliegenden Offenbarung kann gemäß einer Ausführungsform die folgenden Optimierungen bereitstellen:
    • • Die Größe des Bitmap-Abschnitts eines ODS-Abbilds ist proportional zur Größe des Sicherungsabbilds und nicht zur Größe des ODS-Abbilds. Bei einem 2-TB-ODS-Abbild, das auf ein 10-GB-Sicherungsabbild zeigt, beläuft sich die Größe der Bitmap lediglich auf 2,5 MB. Es sei angemerkt, dass 10 GB die maximal zulässige Abbildvorlagengröße für eine bekannte Cloud-VM ist, die in einem DAS ausgeführt wird.
    • • Aufgrund der kleinen Größe der Bitmap kann eine vollständige Kopie der Bitmap im Arbeitsspeicher behalten werden, um Verarbeitungsaufwand im Zusammenhang mit wiederholtem Lesen der On-Disk-Bitmap zu vermeiden.
    • • Nachdem der Vorablesezugriff abgeschlossen wurde, arbeitet das ODS-Abbild beinahe wie ein Ursprungsabbild. Festplatten-Lese- oder Festplatten-Schreibanfragen von der VM werden direkt im Vergleich zu dem Festplattendaten-Abschnitt des ODS-Abbilds ausgeführt, ohne dass Verarbeitungsaufwand im Zusammenhang mit dem Prüfen der In-Memory-Bitmap oder dem Aktualisieren der On-Disk-Bitmap entsteht.
    • • Bei Bearbeitung einer Lese- oder Schreibanfrage einer VM für einen Sektor, dessen logische Blockadresse über die Größe des Sicherungsabbilds hinaus geht, liest oder schreibt der ODS-Treiber den Festplattendaten-Abschnitt des ODS-Abbilds direkt, ohne dass Verarbeitungsaufwand im Zusammenhang mit dem Prüfen der In-Memory-Bitmap oder dem Aktualisieren der On-Disk-Bitmap entsteht.
    • • Bei Bearbeitung einer Leseanfrage einer VM für einen Sektor, dessen In-Memory-Status bereits Sin_ods lautet, wird der Sektor direkt aus dem ODS-Abbild gelesen, ohne dass Verarbeitungsaufwand im Zusammenhang mit dem Aktualisieren der On-Disk-Bitmap entsteht.
    • • Bei einem Vorgang des Erstellens einer Kopie beim Lesen wird nur die In-Memory-Bitmap aktualisiert und die On-Disk-Bitmap wird nicht sofort aktualisiert.
    • • Ein Vorgang des Erstellens einer Kopie beim Lesen ist nicht Teil des kritischen Pfads des Zurückgebens der Daten an die VM. Die Daten werden asynchron im Hintergrund im ODS-Abbild gespeichert, während die VM die Verarbeitung der aus dem Sicherungsabbild gelesenen Daten fortsetzt.
    • • Bei Bearbeitung einer Schreibanfrage einer VM für einen Sektor, dessen On-Disk-Status bereits Sin_ods lautet, entsteht kein Verarbeitungsaufwand im Zusammenhang mit der Aktualisierung der On-Disk-Bitmap.
    • • Wenn ein Sektor im Sicherungsabbild zur Gänze mit Nullen gefüllt ist, kann dessen Ausgangsstatus in der On-Disk-Bitmap des ODS-Abbilds auf Sin_ods gesetzt werden, so dass das Lesen oder Schreiben des Sektors so behandelt wird, als wäre der Sektor bereits im ODS-Abbild, und es entsteht kein Verarbeitungsaufwand im Zusammenhang mit dem Aktualisieren der On-Disk-Bitmap.
    • • Das Ändern der Größe eines ODS-Abbilds ist eine konstante Zeitoperation, bei der nur das Feld disk_data_size im in Tabelle 1 gezeigten Layout aktualisiert werden muss.
  • Die Konzepte des ODS der vorliegenden Offenbarung beinhalten gemäß einer Ausführungsform die Vorgänge des Erstellens einer Kopie beim Schreiben, des Erstellens einer Kopie beim Lesen sowie des Vorablesezugriffs. Theoretisch kann es möglich sein, die Vorgänge des Erstellens einer Kopie beim Lesen und des Vorablesezugriffs bei bestehenden Formaten des Erstellens einer Kopie beim Schreiben umzusetzen, die vom QEMU (z. B. CoW und QCOW2) bereits unterstützt werden, wodurch die Erschwernis des Einführens eines neuen Abbildformats vermieden wird. Das neue ODS-Abbildformat der vorliegenden Offenbarung erzielt gemäß einer Ausführungsform in den häufigsten Fällen eine hohe Leistung. Das Format des Erstellens einer Kopie beim Schreiben. Das COW-Format ist zum ODS-Format beinahe identisch. Es beinhaltet ebenfalls eine Kopfzeile, einen Bitmap-Abschnitt und einen Festplattendaten-Abschnitt. Bei der aktuellen Umsetzung des COW-Treibers werden die cache=none-Option und cache=writethrough-Option des QEMU ignoriert. Folglich können Festplattendaten bei einem Stromausfall korrumpiert werden. Diese Umsetzungsprobleme können potenziell behoben werden, aber das COW-Format selbst ist mit einer wesentlichen Einschränkung verbunden – sein Festplattendaten-Abschnitt ist nicht an der 4-KB-Seitenbegrenzung ausgerichtet. Sogar wenn die Lese- oder Schreibanfrage der VM an der 4-KB-Seitenbegrenzung der virtuellen Festplatte ausgerichtet ist, ist sie, nachdem die Anfrage übersetzt wurde, um im Festplattendaten-Abschnitt des COW-Abbilds zu arbeiten, womöglich nicht länger an der 4-KB-Seitenbegrenzung des Host-Dateisystems ausgerichtet. Da der Seiten-Cachespeicher des Host auf 4-KB-Seiten arbeitet, kann eine fehlausgerichtete Anfrage zu mehreren Festplatten-E/As im Host führen. Beispielsweise kann ein von der VM ausgegebener, gut ausgerichteter 4-KB-Schreibvorgang in einem fehlausgerichteten 4-KB-Schreibvorgang im Host übersetzt werden, wodurch ein ineffizientes Lesen-Ändern-Schreiben-Verhalten bewirkt wird, d. h., es werden 8 KB gelesen, 4 KB geändert und 8 KB zurückgeschrieben. Das ODS-Format der vorliegenden Offenbarung berücksichtigt dieses Problem bei einer Ausführungsform durch das Hinzufügen der in Tabelle 1 gezeigten Auffüllabschnitte, um zu gewährleisten, dass der Bitmap-Abschnitt und der disk_data-Abschnitt korrekt an der 4-KB-Seitenbegrenzung ausgerichtet sind.
  • QCOW2 ist das „native Format” des QEMU. Es unterscheidet sich dahingehend wesentlich von COW und ODS, dass es, anstatt die Unterstützung der Host-Dateisysteme in Bezug auf Dateien mit freien Bereichen zu nutzen, seinen eigenen 2-Ebenen-Index umsetzt, um Abbild-Dateien mit freien Bereichen zu unterstützen. Der Index bildet eine logische Blockadresse in eine Position in der Abbild-Datei ab, in der der Inhalt des Blocks tatsächlich gespeichert ist. Dank dieser Flexibilität bei der Adressabbildung kann QCOW2 moderne Funktionen wie Schnappschuss und Komprimierung bereitstellen.
  • Andererseits führt der 2-Ebenen-Index von QCOW2 auch zu Verarbeitungsaufwand, insbesondere zu zusätzlichen Festplattenzugriffen im Zusammenhang mit dem Lesen oder Aktualisieren des Index. Im Vergleich zu den Optimierungen bei ODS weist eine potenzielle Umsetzung von QCOW2, die um einen Vorgang des Erstellens einer Kopie beim Lesen und einen Vorablesezugriff erweitert ist, die folgenden Einschränkungen auf:
    • • Die Größe des Index ist proportional zur Größe des (großen) QCOW2-Abbilds und nicht zur Größe des (kleinen) Sicherungsabbilds. Folglich kann der Index nicht zur Gänze im Arbeitsspeicher zwischengespeichert werden.
    • • Sogar nach abgeschlossenem Vorablesezugriff muss sie den On-Disk-Index immer noch lesen, um eine von der VM ausgegebene Leseanfrage zu bearbeiten, was zusätzliche Festplatten-E/A-Vorgänge bedeutet.
    • • Sogar nach abgeschlossenem Vorablesezugriff muss sie den On-Disk-Index immer noch lesen (und potenziell schreiben), um eine von der VM ausgegebene Schreibanfrage zu bearbeiten.
    • • Bei Bearbeitung einer Lese- oder Schreibanfrage einer VM für einen Sektor, dessen logische Blockadresse über die Größe des Sicherungsabbilds hinaus geht, muss sie den Index immer noch lesen oder schreiben.
    • • Bei Vorgängen des Erstellens einer Kopie beim Lesen und Vorablesezugriffen besteht die Wahrscheinlichkeit, dass der On-Disk-Index häufiger aktualisiert wird, da sie nicht den gesamten Index im Arbeitsspeicher halten kann.
  • Die Optimierungen beim ODS der vorliegenden Offenbarung umgehen den Verarbeitungsaufwand im Zusammenhang mit der Aktualisierung der On-Disk-Bitmap in den häufigsten Fällen. Im Gegensatz dazu kann mit dem 2-Ebenen-Index des QCOW2 nicht die gleiche Optimierungshöhe erzielt werden. Da die modernen Funktionen von QCOW2 (d. h. Schnappschuss, Komprimierung und Verschlüsselung) in einer Cloud nicht verwendet werden, kann die vorliegende Offenbarung bei einer Ausführungsform ein einfacheres Abbildformat vorsehen, das eine bessere Leistung bietet, d. h. das ODS-Format. Die Schnappschuss-Funktion von QCOW2 bietet die besten Voraussetzungen, um in einer Cloud nützlich zu sein. Eine Cloud stellt für gewöhnlich zwei schnappschussähnliche Funktionen bereit: 1) zuverlässiges Backup, und 2) abbildgetreues Zusammenpacken, d. h., Schießen eines Schnappschusses des Stammdateisystems, Umwandeln in eine Abbildvorlage und Verzeichnen der Abbildvorlage in der Cloud zur künftigen Wiederverwendung. Ein Schnappschuss von QCOW2 wird jedoch im QCOW2-Abbild im DAS gespeichert und ist somit kein zuverlässiger Backup-Mechanismus und kann nicht als Abbildvorlage zur Erstellung einer neuen VM auf einem anderen Host verwendet werden.
  • Die vorliegende Offenbarung kann bei einer Ausführungsform sowohl die schnelle Erstellung von virtuellen Maschinen (VM) als auch eine gute Laufzeitleistung in der Cloud unterstützen. Die bestehenden Lösungen weisen zumindest ein, zwei Beschränkungen auf: 1) langsame VM-Erstellung, da das gesamte Abbild vor Erstellung kopiert wird (z. B. Ursprungsabbildformat-Treiber bei KVM); 2) hoher Netzwerkdatenverkehr und schlechte Leistung zur Laufzeit, da Daten wiederholt aus dem Remote-Speicher-Server gelesen werden (z. B. qcow2-Abbildformat-Treiber bei KVM).
  • Bei einer Ausführungsform kann das bedarfsgesteuerte Streaming der vorliegenden Offenbarung sowohl eine schnelle VM-Bereitstellung als auch eine gute Laufzeitleistung vorsehen. Das ODS der vorliegenden Offenbarung kann einen Hypervisor um das neue „ods”-Abbildformat und den entsprechenden Treiber erweitern. Im Vergleich zum Ursprungsabbildformat, das bei einigen bestehenden Clouds verwendet wird, führt das ODS zu weniger Netzwerkdatenverkehr und einer geringeren Eingabe-/Ausgabe-(E/A-)Last im Speicher-Server, und das nicht nur während der Bereitstellung, sondern allgemein während der gesamten Lebensdauer der VM. Im Gegensatz zum Ursprungsabbildformat, das bei einigen bestehenden Clouds verwendet wird, kann das ODS eine VM über das Netzwerk booten, ohne dass eine vollständige Kopie der Abbildvorlage erstellt wird. Es kann eine VM sofort booten und danach Datenblöcke nach Bedarf aus dem Speicher-Server vorab lesen, wenn die VM auf die Datenblöcke zugreift.
  • Im Gegensatz zum QCOW2-Abbildformat, bei dem nur ein Vorgang des Erstellens einer Kopie beim Schreiben, aber kein Vorgang des Erstellens einer Kopie beim Lesen durchgeführt wird und somit der gleiche Datenblock wiederholt aus einem Speicher-Server gelesen werden kann, kann das ODS der vorliegenden Offenbarung gemäß einer Ausführungsform einen Datenblock höchstens einmal aus einem Speicher-Server lesen und diesen Block dann zur späteren Wiederverwendung auf einer lokalen Festplatte speichern. Ein weiterer Vorteil des ODS der vorliegenden Offenbarung gegenüber QCOW2 kann sein, dass sich das Daten-Layout von QCOW2 auf einer lokalen Festplatte von jenem des Ursprungsabbildformats unterscheidet; andererseits kann das Datenblock-Layout des ODS der vorliegenden Offenbarung in Bezug auf jenes des Ursprungsabbildformats identisch sein. Folglich kann die Laufzeitleistung des ODS besser als jene von QCOW2 sein.
  • Experimente zeigen, dass 1) das ODS der vorliegenden Offenbarung einen bekannten Betriebssystem-Server innerhalb von 14 Sekunden booten kann und dabei Daten in der Größe von weniger als 17 Megabyte (MB) über das Netzwerk überträgt; und 2) die Laufzeitleistung des ODS genauso gut wie das Ursprungsabbildformat ist.
  • Bei einer weiteren Ausführungsform kann das ODS der vorliegenden Offenbarung darüber hinaus eine moderne Funktion beinhalten, die das gesamte VM-Abbild im Hintergrund aus einem Speicher-Server vorab liest, wenn oder während sich die Ressourcen wie die Festplatte, das Netzwerk und die CPU ansonsten im Leerlauf befinden. Diese Funktion verdeckt Netzwerklatenz und verteilt die Ressourcennutzung gleichmäßig anstatt zu warten und das gesamte VM-Abbild während der VM-Erstellung zu kopieren.
  • Das ODS der vorliegenden Offenbarung kann in einer Cloud-Umgebung verwendet werden. Das ODS kann darüber hinaus in einer Nicht-Cloud-Umgebung verwendet werden. Ferner kann das ODS verwendet werden, wobei nur die Funktion des Erstellens einer Kopie beim Schreiben aktiviert ist, beispielsweise um als Hochleistungs-CoW-Format zu dienen. Außerdem kann die Umsetzung des ODS für die Gast-VM (ausgewählte VM, die auf einem Hypervisor oder dergleichen ausgeführt wird) transparent und somit umfassend anwendbar sein.
  • Das ODS der vorliegenden Offenbarung kann als Teil eines Hypervisors oder als eine Erweiterung einer Funktion eines Hypervisors oder dergleichen umgesetzt sein, der bzw. die beispielsweise alle Funktionen eines Hypervisors bereitstellt, ohne dass Änderungen an der Gast-VM vorgenommen werden. Die Fähigkeit des ODS, d. h. der Vorgang des Erstellens einer Kopie beim Schreiben, der Vorgang des Erstellens einer Kopie beim Lesen und Vorablesezugriff, wird von keinem bestehenden Server bereitgestellt.
  • Die Größe des Bitmap-Abschnitts eines ODS-Abbilds ist proportional zur Größe des Sicherungsabbilds und nicht zur Größe des ODS-Abbilds. Ferner kann aufgrund der geringen Größe der Bitmap eine vollständige Kopie der Bitmap im Arbeitsspeicher aufbewahrt werden, wodurch Verarbeitungsaufwand im Zusammenhang mit dem wiederholten Lesen der On-Disk-Bitmap vermieden wird. In einem Aspekt besteht die Möglichkeit, dass im Rahmen des Vorgangs des Erstellens einer Kopie beim Lesen nur die In-Memory-Bitmap aktualisiert wird und die On-Disk-Bitmap nicht sofort aktualisiert werden muss, wodurch der Festplatten-E/A-Verarbeitungsaufwand verringert werden kann.
  • Beim Bearbeiten einer Lese- und/oder Schreibanfrage einer VM für einen Sektor, dessen logische Blockadresse über die Größe des Sicherungsabbilds hinaus geht, liest und/oder schreibt der ODS-Treiber den Festplattendaten-Abschnitt des ODS-Abbilds direkt, ohne dass Verarbeitungsaufwand im Zusammenhang mit dem Prüfen der In-Memory-Bitmap und/oder dem Aktualisieren der On-Disk-Bitmap entsteht. Ferner werden Festplatten-Lese- und/oder Festplatten-Schreibanfragen von der VM nach Abschluss des Vorablesezugriffs direkt im Vergleich zu dem Festplattendaten-Abschnitt des ODS-Abbilds ausgeführt, ohne dass Verarbeitungsaufwand im Zusammenhang mit dem Prüfen der In-Memory-Bitmap und/oder dem Aktualisieren der On-Disk-Bitmap entsteht.
  • In einem weiteren Aspekt besteht die Möglichkeit, dass der Vorgang des Erstellens einer Kopie beim Lesen nicht Teil des kritischen Pfads des Zurückgebens der Daten an die VM ist, und die Daten können asynchron im Hintergrund in das ODS-Abbild gespeichert werden, während die VM die Verarbeitung der aus dem Sicherungsabbild gelesenen Daten fortsetzt.
  • In einem noch weiteren Aspekt wird der Ausgangsstatus eines Datensektors, wenn der Datensektor im Sicherungsabbild zur Gänze mit Nullen gefüllt ist, in der On-Disk-Bitmap des ODS-Abbilds so eingestellt, als würde sich der Sektor bereits im ODS-Abbild befinden, wodurch der Verarbeitungsaufwand im Zusammenhang mit dem Aktualisieren der On-Disk-Bitmap und dem Lesen des Datensektors aus dem Speicher-Server vermieden wird.
  • Wie der Fachmann verstehen wird, können Aspekte der vorliegenden Erfindung in Form eines Systems, eines Verfahrens oder eines Computerprogrammprodukts umgesetzt sein. Demgemäß können Aspekte der vorliegenden Erfindung die Form einer ausschließlich aus Hardware bestehenden Ausführungsform, einer ausschließlich aus Software bestehenden Ausführungsform (Firmware, residente Software, Microcode usw. mit eingeschlossen) oder einer Ausführungsform annehmen, die Software- und Hardware-Aspekte kombiniert, die hier allesamt allgemein als „Schaltung”, „Modul” oder „System” bezeichnet werden können. Ferner können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das als ein oder mehrere computerlesbare Medien umgesetzt ist, die einen computerlesbaren Programmcode aufweisen.
  • Es kann eine beliebige Kombination aus einem oder mehreren computerlesbaren Medien verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann beispielsweise ein/e elektronische/s, magnetische/s, optische/s, elektromagnetische/s, Infrarot- oder Halbleitersystem, -vorrichtung oder -einheit oder eine geeignete Kombination des Vorstehenden sein, ohne jedoch darauf beschränkt zu sein. Spezifischere Beispiele (nichterschöpfende Liste) für das computerlesbare Speichermedium sind unter anderem: eine elektrische Verbindung mit einem oder mehreren Kabeln, eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein elektronisch löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compact Disk-Nur-Lese-Speicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder eine geeignete Kombination des Vorstehenden. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes konkrete Medium sein, das ein Programm zur Verwendung durch ein Anweisungsausführungssystem, eine -vorrichtung oder eine -einheit oder in Verbindung damit enthalten oder speichern kann.
  • Ein computerlesbares Signalmedium kann ein weitergeleitetes Datensignal beinhalten, das einen computerlesbaren Programmcode aufweist, beispielsweise im Basisband oder als Teil einer Trägerwelle. Ein solches weitergeleitetes Signal kann eine Vielzahl von Formen annehmen, beispielsweise elektromagnetisch, optisch oder eine geeignete Kombination davon, ohne jedoch darauf beschränkt zu sein. Ein computerlesbares Signalmedium kann ein beliebiges computerlesbares Medium sein, bei dem es sich nicht um ein computerlesbares Speichermedium handelt und das ein Programm zur Verwendung durch ein Anweisungsausführungssystem, eine -vorrichtung oder eine -einheit oder in Verbindung damit übertragen, weiterleiten oder transportieren kann.
  • Der in einem computerlesbaren Medium enthaltene Programmcode kann mithilfe eines geeigneten Mediums übertragen werden, beispielsweise drahtlos, kabelgebunden, Lichtwellenleiterkabel, HF usw. oder eine Kombination des Vorstehenden, ohne jedoch darauf beschränkt zu sein.
  • Ein Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in irgendeiner Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, beispielsweise objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder dergleichen und herkömmliche prozedurale Programmiersprachen wie die „C”-Programmiersprache oder ähnliche Programmiersprachen, eine Skriptsprache wie Perl, VBS oder ähnliche Sprachen und/oder funktionelle Sprachen wie Lisp und ML und logikorientierte Sprachen wie Prolog. Der Programmcode kann zur Gänze auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem Remote-Computer oder zur Gänze auf dem Remote-Computer oder -Server ausgeführt werden. Bei letzterem Szenario kann der Remote-Computer über einen beliebigen Netzwerktyp, beispielsweise Local Area Network (LAN) oder Wide Area Network (WAN), mit dem Computer des Benutzers verbunden sein oder die Verbindung zu einem externen Computer kann hergestellt werden (z. B. über einen Internet-Diensteanbieter über Internet).
  • Aspekte der vorliegenden Erfindung sind unter Bezugnahme auf die Ablaufplandarstellungen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufplandarstellungen und/oder Blockschaubilder und Kombinationen von Blöcken in den Ablaufplandarstellungen und/oder Blockschaubildern durch Computerprogrammanweisungen umgesetzt werden können. Diese Computerprogrammanweisungen können für einen Prozessor eines Universalcomputers, eines spezifischen Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu produzieren, so dass die Anweisungen, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel für das Umsetzen der in dem einen oder den mehreren Ablaufplan- und/oder Blockschaubildblöcken angegebenen Funktionen/Aktionen zu erstellen.
  • Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert werden, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, auf eine bestimmte Weise zu arbeiten, so dass die im computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel produzieren, der Anweisungen beinhaltet, die die in den einen oder mehreren Ablaufplan- und/oder Blockschaubildblöcken angegebene Funktion/Aktion umsetzen.
  • Die Computerprogramminstruktionen können auch in einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Geräte geladen werden, um zu bewirken, dass eine Reihe von Betriebsschritten im Computer, auf der anderen programmierbaren Vorrichtung oder auf anderen Einheiten durchgeführt wird, um ein computerausgeführtes Verfahren zu produzieren, so dass die Anweisungen, die auf dem Computer oder auf der anderen programmierbaren Vorrichtung ausgeführt werden, Verfahren zum Umsetzen der in dem einen oder den mehreren Ablaufplan- und/oder Blockschaubildblöcken angegebenen Funktionen/Aktionen bereitstellen.
  • Der Ablaufplan und die Blockschaubilder in den Figuren zeigen die Architektur, die Funktionalität und den Betrieb möglicher Umsetzungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. In dieser Hinsicht kann jeder Block des Ablaufplans oder der Blockschaubilder ein Modul, ein Segment oder einen Teil eines Codes darstellen, das bzw. der eine oder mehrere ausführbare Anweisungen für die Umsetzung der einen oder mehreren angegebenen logischen Funktionen aufweist. Es sei darüber hinaus angemerkt, dass die in den Blöcken ausgewiesenen Funktionen bei einigen alternativen Umsetzungen in einer anderen Reihenfolge als in den Figuren gezeigt auftreten können. Beispielsweise können zwei aufeinanderfolgen Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal in umgekehrter Reihenfolge ausgeführt werden, je nach Funktionalität. Es sei ferner angemerkt, dass jeder Block der Blockschaubilder und/oder der Ablaufplandarstellung und Kombinationen von Blöcken in den Blockschaubildern und/oder in der Ablaufplandarstellung durch spezifische hardwarebasierte Systeme umgesetzt sein können, die die angegebenen Funktionen oder Aktionen oder Kombinationen von spezifischen Hardware- und Computeranweisungen durchführen.
  • Die Systeme und Methodiken der vorliegenden Offenbarung können in einem Computersystem durchgeführt oder ausgeführt werden, das eine Verarbeitungseinheit beinhaltet, die eine oder mehrere Prozessoren und/oder Kerne, Speicher- oder andere Systemkomponenten (in der Zeichnung nicht ausdrücklich gezeigt) aufweist, die ein Computerverarbeitungssystem oder einen Computer umsetzen, das bzw. der ein Computerprogrammprodukt ausführen kann. Das Computerprogrammprodukt kann Medien aufweisen, beispielsweise eine Festplatte, ein Kompaktspeichermedium wie eine Compact Disk oder andere Speichereinheiten, die von der Verarbeitungseinheit mithilfe von dem Fachmann bekannten oder künftig bekannt werdenden Verfahren für die Bereitstellung des Computerprogrammprodukts an das Verarbeitungssystem zu Ausführungszwecken gelesen werden können.
  • Das Computerprogrammprodukt kann alle jeweiligen Funktionen aufweisen, die die Umsetzung der hier beschriebenen Methodiken ermöglichen, und kann die Verfahren, wenn es in ein Computersystem geladen ist, ausführen. Unter Computerprogramm, Software-Programm, Programm oder Software versteht sich im vorliegenden Kontext jeder Ausdruck eines Satzes von Anweisungen in einer beliebigen Sprache, einem beliebigen Code oder einer beliebigen Schreibweise, der bewirken soll, dass ein System mit einer Informationsverarbeitungsfunktion eine bestimmte Funktion entweder direkt oder nach einem oder beiden des Folgenden durchführt: (a) Umwandlung in eine andere Sprache, einen anderen Code oder eine andere Schreibweise; und/oder (b) Reproduktion in einer anderen materiellen Form.
  • Das Computerverarbeitungssystem, das das System und das Verfahren der vorliegenden Offenbarung ausführt, kann auch eine Anzeigeeinheit, beispielsweise einen Monitor oder einen Anzeigebildschirm für das Darstellen von Ausgabeanzeigen und für das Bereitstellen einer Anzeige beinhalten, über die der Benutzer Daten eingeben und mit dem Verarbeitungssystem interagieren kann, beispielsweise im Kombination mit Eingabeeinheiten wie Tastatur und Mauseinheit oder Zeigeeinheit. Das Computerverarbeitungssystem kann auch direkt oder mittels Remote-Verbindung mit einer oder mehreren Peripherieeinheiten wie Drucker, Scanner, Lautsprecher und andere Einheiten verbunden oder gekoppelt sein. Das Computerverarbeitungssystem kann über eine oder mehrere von lokalem Ethernet, WAN-Verbindung, Internet usw. oder über andere Vernetzungsmethodiken, die unterschiedliche Rechensysteme verbinden und einen Datenaustausch zwischen diesen ermöglichen, mit einem oder mehreren anderen Verarbeitungssystemen, beispielsweise einem Server, einem anderen Remote-Computerverarbeitungssystem oder Netzwerkspeichereinheiten, verbunden oder gekoppelt sein. Die verschiedenen Funktionalitäten und Module der Systeme und Verfahren der vorliegenden Offenbarung können auf unterschiedlichen Verarbeitungssystemen verteilt oder auf einer einzelnen Plattform umgesetzt sein oder ausgeführt werden, die beispielsweise auf lokal oder im Netzwerk verteilt gespeicherte Daten zugreift.
  • Die hier verwendete Terminologie dient lediglich zum Beschreiben bestimmter Ausführungsformen und soll die Erfindung nicht einschränken. Wie hier verwendet, sollen die Singularformen von Artikeln wie „ein” und „der” auch die Pluralformen mit einschließen, außer wenn der Kontext es eindeutig anders vorgibt. Es sei ferner verstanden, dass die Ausdrücke „aufweisen” und/oder „aufweisend”, wie in dieser Schrift verwendet, das Vorhandensein von angegebenen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen und/oder Komponenten festlegen, das Vorhandensein oder das Hinzufügen von einem/r oder mehreren anderen Merkmalen, ganzen Zahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen davon jedoch nicht ausschließen.
  • Die entsprechenden Strukturen, Materialien, Aktionen und sämtliche Mittel oder Schritt-plus-Funktion-Elemente, falls vorhanden, in den folgenden Ansprüchen sollen jedwede Struktur, jedwedes Material oder jedwede Aktion für das Durchführen der Funktion in Kombination mit anderen beanspruchten Elementen, wie spezifisch beansprucht, beinhalten. Die Beschreibung der vorliegenden Erfindung ist zum Zwecke der Veranschaulichung und Beschreibung dargeboten, soll jedoch nicht als ausschöpfend oder die Erfindung in der offenbarten Form einschränkend verstanden werden. Für den Fachmann sind viele Änderungen und Variationen ersichtlich, ohne sich vom Umfang und Geist der Erfindung zu entfernen. Die Ausführungsform wurde gewählt und beschrieben, um die Grundsätze der Erfindung und die praktische Anwendung bestmöglich zu erläutern und um anderen Fachleuten zu ermöglichen, die Erfindung in verschiedenen Ausführungsformen mit verschiedenen Änderungen, wie sie sich für die bestimmte angedachte Verwendung eignen, zu verstehen.
  • Verschiedene Aspekte der vorliegenden Offenbarung können als Programm, Software oder Computeranweisungen umgesetzt sein, die in einem computer- oder maschinenlesbaren oder -nutzbaren Medium umgesetzt sind, das den Computer oder die Maschine veranlasst, die Schritte des Verfahrens durchzuführen, wenn es auf dem Computer, dem Prozessor und/oder der Maschine ausgeführt wird. Ferner wird eine von einer Maschine lesbare Programmspeichereinheit bereitgestellt, die konkret als Programm mit Anweisungen umgesetzt ist, das von der Maschine ausführbar ist, um diverse in der vorliegenden Offenbarung beschriebene Funktionalitäten und Verfahren durchzuführen.
  • Das System und das Verfahren der vorliegenden Offenbarung können auf einem Universalcomputer oder einem speziellen Computersystem umgesetzt sein und ausgeführt werden. Das Computersystem kann ein beliebiger Typ von bekannten oder bekannt werdenden Systemen sein und kann für gewöhnlich einen Prozessor, eine Arbeitsspeichereinheit, eine Speichereinheit, Eingabe-/Ausgabeeinheiten, interne Busse und/oder eine Datenübertragungsschnittstelle zum Austausch von Daten mit anderen Computersystemen in Verbindung mit Datenübertragungs-Hardware und -Software usw. beinhalten.
  • Die Ausdrücke „Computersystem” und „Computernetzwerk”, wie sie bei der vorliegenden Anmeldung verwendet werden können, können eine Vielzahl von Kombinationen aus ortsfester/n und/oder tragbarer/n Computer-Hardware, Software, Peripheriegeräten und Speichereinheiten beinhalten. Das Computersystem kann eine Vielzahl von einzelnen Komponenten beinhalten, die zur Zusammenarbeit vernetzt oder anderweitig verbunden sind, oder kann eine oder mehrere eigenständige Komponenten beinhalten. Die Hardware- und Software-Komponenten des Computersystems der vorliegenden Anmeldung können ortsfeste und tragbare Einheiten wie Desktop-PC, Laptop und/oder Server beinhalten und in diesen enthalten sein. Ein Modul kann eine Komponente einer Einheit, einer Software, eines Programms oder eines Systems sein, die eine gewisse „Funktion” ausführt, die als Software, Hardware, Firmware, elektronischer Schaltkreis oder usw. umgesetzt sein kann.
  • Die oben beschriebenen Ausführungsformen sind veranschaulichende Beispiele, und die vorliegende Erfindung sollte nicht als auf diese bestimmten Ausführungsformen beschränkt ausgelegt werden. Somit kann der Fachmann diverse Änderungen und Modifikationen vornehmen, ohne sich vom Geist oder Umfang der Erfindung, wie in den beiliegenden Ansprüchen definiert, zu entfernen.

Claims (25)

  1. Verfahren zum bedarfsgesteuerten Streaming von Abbildern virtueller Maschinen, aufweisend: Kopieren von mit einer ausgewählten virtuellen Maschine verknüpften Abbild-Metadaten von einem Speicher-Server, auf dem eine oder mehrere Abbildvorlagen gespeichert sind, die jeweils einer oder mehreren virtuellen Maschinen entsprechen, in einen lokalen Speicher eines Host-Computers, wobei der lokale Speicher des Host-Computers zunächst kein Abbild der ausgewählten virtuellen Maschine enthält; Booten der ausgewählten virtuellen Maschine im Host-Computer unter Verwendung der kopierten Abbild-Metadaten; Ermöglichen, dass die ausgewählte virtuelle Maschine Daten aus der Abbildvorlage im Speicher-Server liest, die erforderlich sind, um das Ausführen der ausgewählten virtuellen Maschine im Host-Computer fortzusetzen, wenn die benötigten Daten nicht im lokalen Speicher des Host-Computers gespeichert sind; Kopieren der gelesenen Daten der Abbildvorlage vom Speicher-Server in den lokalen Speicher des Host-Computers, wenn die gelesenen Daten der Abbildvorlage nicht im lokalen Speicher des Host-Computers gespeichert sind, wobei nachfolgende Lesevorgänge der gleichen Daten aus dem lokalen Speicher des Host-Computers durchgeführt werden; Setzen eines Bits in einer Bitmap, um anzuzeigen, dass die gelesenen Daten im lokalen Speicher des Host-Computers gespeichert sind; und Nutzen der Ressourcen-Leerlaufzeit, um mit der ausgewählten virtuellen Maschine verknüpfte Daten der Abbildvorlage aus dem Speicher-Server in den lokalen Speicher des Host-Computers vorab zu lesen.
  2. Verfahren nach Anspruch 1, wobei die Abbild-Metadaten zunächst einen Verweis auf die Abbildvorlage und die Bitmap, die ein Bit einem entsprechenden Sektor der Abbildvorlage zuordnet, beinhaltet.
  3. Verfahren nach Anspruch 1, wobei die Reaktionszeiten während des Abbild-Vorablesezugriffs überwacht werden, und wobei der Vorablesezugriff vorübergehend angehalten wird, wenn eine Reaktionszeit einen Grenzwert überschreitet.
  4. Verfahren nach Anspruch 1, wobei die Größe der Bitmap proportional zur Größe der Abbildvorlage im Speicher-Server und nicht zur Größe des entsprechenden Abbilds ist, das im lokalen Speicher des Host-Computers gespeichert ist.
  5. Verfahren nach Anspruch 1, wobei eine vollständige Kopie der Bitmap im Arbeitsspeicher aufbewahrt werden kann.
  6. Verfahren nach Anspruch 1, wobei die Lese- und/oder Schreibanfragen der ausgewählten virtuellen Maschine für einen Sektor, dessen logische Blockadresse über die Größe der Abbildvorlage im Speicher-Server hinaus geht, durch Lesen und/oder Schreiben des Sektors direkt in den lokalen Speicher des Host-Computers bearbeitet wird, ohne dass die Bitmap überprüft und/oder die Bitmap aktualisiert wird.
  7. Verfahren nach Anspruch 1, wobei eine oder mehrere, von der ausgewählten virtuellen Maschine ausgegebene Festplatten-Lese- und/oder Festplatten-Schreibanfragen nach abgeschlossenem Vorablesezugriff unter Verwendung von Abbilddaten ausgeführt werden, die direkt im lokalen Speicher des Host-Computers gespeichert sind, ohne dass die Bitmap überprüft und/oder die Bitmap aktualisiert wird.
  8. Verfahren nach Anspruch 1, wobei die Bitmap im Arbeitsspeicher und auf der Festplatte im Host-Computer aufbewahrt wird, und wobei ein Vorgang des Erstellens einer Kopie beim Lesen nur die In-Memory-Bitmap aktualisiert und die On-Disk-Bitmap nicht sofort aktualisiert.
  9. Verfahren nach Anspruch 1, wobei ein Vorgang des Erstellens einer Kopie beim Lesen nicht Teil des kritischen Pfads des Zurückgebens der Daten an die VM ist, und wobei die Daten asynchron im Hintergrund in das ODS-Abbild gespeichert werden, während die VM die Verarbeitung der aus dem Sicherungsabbild geladenen Daten fortsetzt.
  10. Verfahren nach Anspruch 1, wobei ein Ausgangsstatus eines Datensektors, wenn der Datensektor in der Abbildvorlage im Speicher-Server zur Gänze mit Nullen gefüllt ist, in der im lokalen Speicher des Host-Computers gespeicherten Bitmap so eingestellt wird, als wäre der Datensektor bereits in den lokalen Speicher des Host-Computers kopiert.
  11. Verfahren nach Anspruch 1, wobei das Verfahren in einem Hypervisor umgesetzt ist, wobei Funktionalitäten des Hypervisors ohne Änderungen an der ausgewählten virtuellen Maschine bereitgestellt werden.
  12. Verfahren zum bedarfsgesteuerten Streaming von Abbildern virtueller Maschinen, aufweisend: Kopieren von mit einer virtuellen Maschine verknüpften Abbild-Metadaten von einem Quell-Computer, auf dem eine der virtuellen Maschine entsprechende Abbildvorlage gespeichert ist, auf einen Ziel-Computer, wobei der Ziel-Computer die Abbildvorlage der virtuellen Maschine zunächst nicht enthält; Booten der virtuellen Maschine im Ziel-Computer unter Verwendung der kopierten Abbild-Metadaten; Ermöglichen, dass die virtuelle Maschine im Ziel-Computer Daten der Abbildvorlage im Quell-Computer liest, die erforderlich sind, um das Ausführen der virtuellen Maschine im Ziel-Computer fortzusetzen, wenn die erforderlichen Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind; Kopieren der gelesenen Daten der Abbildvorlage vom Quell-Computer auf den Ziel-Computer, wenn die gelesenen Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind, wobei bei nachfolgenden Lesungen der gleichen Daten die kopierten Daten im Ziel-Computer gelesen werden; und Setzen eines Bits in einer Bitmap, um anzuzeigen, dass die gelesenen Daten im Ziel-Computer gespeichert sind.
  13. Verfahren nach Anspruch 12, wobei die Abbild-Metadaten zunächst einen Verweis auf die Abbildvorlage und die Bitmap, die ein Bit einem entsprechenden Sektor der Abbildvorlage zuordnet, beinhaltet.
  14. Verfahren nach Anspruch 12, ferner beinhaltend das Bestimmen, ob die zur Ausführung der virtuellen Maschine erforderlichen Daten im Ziel-Computer gespeichert sind, indem das Bit in der Bitmap überprüft wird, wobei die virtuelle Maschine je nach Bit in der Bitmap Daten aus dem Quell-Computer oder dem Ziel-Computer liest.
  15. Verfahren nach Anspruch 12, ferner beinhaltend das Nutzen von Ressourcen-Leerlaufzeit, um mit der virtuellen Maschine verknüpfte Daten der Abbildvorlage aus dem Quell-Computer in den Ziel-Computer vorab zu lesen.
  16. Verfahren nach Anspruch 12, wobei die Schritte für eine Live-Migration der virtuellen Maschine vom Quell-Computer auf den Ziel-Computer durchgeführt werden, wobei kein separater Speicher-Server verwendet wird.
  17. Computerlesbares Speichermedium, auf dem ein Programm mit Anweisungen gespeichert ist, das von einer Maschine ausführbar ist, um ein Verfahren für das bedarfsgesteuerte Streaming von Abbildern virtueller Maschinen durchzuführen, aufweisend: Kopieren von mit einer ausgewählten virtuellen Maschine verknüpften Abbild-Metadaten von einem Speicher-Server, auf dem eine oder mehrere Abbildvorlagen gespeichert sind, die jeweils einer oder mehreren virtuellen Maschinen entsprechen, in einen lokalen Speicher eines Host-Computers, wobei der lokale Speicher des Host-Computers zunächst keine Abbildvorlage der ausgewählten virtuellen Maschine enthält; Booten der ausgewählten virtuellen Maschine im Host-Computer unter Verwendung der kopierten Abbild-Metadaten; Ermöglichen, dass die ausgewählte virtuelle Maschine Daten aus der Abbildvorlage im Speicher-Server liest, die erforderlich sind, um das Ausführen der ausgewählten virtuellen Maschine im Host-Computer fortzusetzen, wenn die benötigten Daten nicht im lokalen Speicher des Host-Computers gespeichert sind; Kopieren der gelesenen Daten der Abbildvorlage vom Speicher-Server in den lokalen Speicher des Host-Computers, wenn die gelesenen Daten der Abbildvorlage nicht im lokalen Speicher des Host-Computers gespeichert sind, wobei nachfolgende Lesevorgänge der gleichen Daten aus dem lokalen Speicher des Host-Computers durchgeführt werden; und Setzen eines Bits in einer Bitmap, um anzuzeigen, dass die gelesenen Daten im lokalen Speicher des Host-Computers gespeichert sind.
  18. Computerlesbares Speichermedium nach Anspruch 17, wobei die Abbild-Metadaten zunächst einen Verweis auf die Abbildvorlage beinhalten.
  19. Computerlesbares Speichermedium nach Anspruch 18, wobei die Abbild-Metadaten ferner die Bitmap beinhalten, die ein Bit einem entsprechenden Sektor der Abbildvorlage zuordnet.
  20. Computerlesbares Speichermedium nach Anspruch 17, ferner beinhaltend das Bestimmen, ob die zur Ausführung der ausgewählten virtuellen Maschine benötigten Daten der Abbildvorlage im lokalen Speicher des Host-Computers gespeichert sind, indem das Bit in der Bitmap überprüft wird, wobei die ausgewählte virtuelle Maschine je nach Bit in der Bitmap die Abbildvorlage im Speicher-Server oder die kopierte Abbildvorlage im lokalen Speicher des Host-Computers liest.
  21. Computerlesbares Speichermedium nach Anspruch 17, ferner beinhaltend das Nutzen von Ressourcen-Leerlaufzeit, um mit der ausgewählten virtuellen Maschine verknüpfte Daten der Abbildvorlage aus dem Speicher-Server in den lokalen Speicher des Host-Computers vorab zu lesen.
  22. System zum bedarfsgesteuerten Streaming von Abbildern virtueller Maschinen, aufweisend: einen Ziel-Computer, der funktionsfähig ist, um mit einer virtuellen Maschine verknüpfte Abbild-Metadaten von einem Quell-Computer, auf dem eine der virtuellen Maschine entsprechende Abbildvorlage gespeichert ist, zu kopieren, wobei der Ziel-Computer die Abbildvorlage der virtuellen Maschine zunächst nicht beinhaltet; und eine Speichereinheit, die lokal im Ziel-Computer angeschlossen ist, wobei der Ziel-Computer darüber hinaus funktionsfähig ist, um die virtuelle Maschine im Ziel-Computer unter Verwendung der kopierten Abbild-Metadaten zu booten und es der virtuellen Maschine im Ziel-Computer zu ermöglichen, Daten der Abbildvorlage im Quell-Computer zu lesen, die erforderlich sind, um das Ausführen der virtuellen Maschine im Ziel-Computer fortzusetzen, wenn die benötigten Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind, wobei der Ziel-Computer darüber hinaus funktionsfähig ist, um die gelesenen Daten der Abbildvorlage aus dem Quell-Computer in die lokal im Ziel-Computer angeschlossene Speichereinheit zu kopieren, wenn die gelesenen Daten der Abbildvorlage nicht im Ziel-Computer gespeichert sind, wobei nachfolgende Lesevorgänge der gleichen Daten aus der lokal im Ziel-Computer angeschlossenen Speichereinheit durchgeführt werden, wobei der Ziel-Computer darüber hinaus zum Setzen eines Bits in einer Bitmap funktionsfähig ist, um anzuzeigen, dass die gelesenen Daten im Ziel-Computer gespeichert sind.
  23. System nach Anspruch 22, wobei die Abbild-Metadaten zunächst einen Verweis auf die Abbildvorlage beinhalten.
  24. System nach Anspruch 23, wobei die Abbild-Metadaten ferner die Bitmap beinhalten, die ein Bit einem entsprechenden Sektor der Abbildvorlage zuordnet.
  25. System nach Anspruch 22, ferner beinhaltend das Nutzen von Ressourcen-Leerlaufzeit, um mit der virtuellen Maschine verknüpfte Daten der Abbildvorlage aus dem Quell-Computer in den Ziel-Computer vorab zu lesen.
DE112011103026.6T 2010-09-10 2011-06-06 Bedarfsgesteuertes Streaming von Abbildern virtueller Maschinen Active DE112011103026B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/879,594 2010-09-10
US12/879,594 US8490088B2 (en) 2010-09-10 2010-09-10 On demand virtual machine image streaming
PCT/US2011/039209 WO2012033554A1 (en) 2010-09-10 2011-06-06 On demand virtual machine image streaming

Publications (2)

Publication Number Publication Date
DE112011103026T5 true DE112011103026T5 (de) 2013-06-13
DE112011103026B4 DE112011103026B4 (de) 2022-03-03

Family

ID=45807931

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112011103026.6T Active DE112011103026B4 (de) 2010-09-10 2011-06-06 Bedarfsgesteuertes Streaming von Abbildern virtueller Maschinen

Country Status (6)

Country Link
US (1) US8490088B2 (de)
JP (1) JP5657121B2 (de)
CN (1) CN103098043B (de)
DE (1) DE112011103026B4 (de)
GB (1) GB2498129B (de)
WO (1) WO2012033554A1 (de)

Families Citing this family (159)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US8352490B2 (en) 2009-10-22 2013-01-08 Vmware, Inc. Method and system for locating update operations in a virtual machine disk image
US20110126197A1 (en) * 2009-11-25 2011-05-26 Novell, Inc. System and method for controlling cloud and virtualized data centers in an intelligent workload management system
US9086892B2 (en) * 2010-11-23 2015-07-21 International Business Machines Corporation Direct migration of software images with streaming technique
CN102073462B (zh) * 2010-11-29 2013-04-17 华为技术有限公司 虚拟存储迁移方法、系统和虚拟机监控器
US8566496B2 (en) * 2010-12-03 2013-10-22 Lsi Corporation Data prefetch in SAS expanders
CN102567042B (zh) * 2010-12-14 2015-04-15 国际商业机器公司 利用引导块重定位来管理多个软件镜像的方法和系统
US9223605B2 (en) * 2011-07-01 2015-12-29 V3 Systems Holdings, Inc. Virtual machine allocation internal and external to physical environment
US9326001B2 (en) * 2011-03-22 2016-04-26 International Business Machines Corporation Scalable image distribution in virtualized server environments
US9058196B2 (en) * 2011-04-12 2015-06-16 Red Hat Israel, Ltd. Host machine level template caching in virtualization environments
US20120272236A1 (en) * 2011-04-20 2012-10-25 Ayal Baron Mechanism for host machine level template caching in virtualization environments
EP2737398A4 (de) * 2011-07-29 2015-01-07 Hewlett Packard Development Co Migration virtueller maschinen
US9367453B1 (en) * 2011-09-30 2016-06-14 Emc Corporation System and method for migrating cache data
US9367452B1 (en) 2011-09-30 2016-06-14 Emc Corporation System and method for apportioning storage
TWI539296B (zh) * 2011-12-12 2016-06-21 和沛科技股份有限公司 虛擬機器的搬移位置計算程序的觸發方法及其應用程式
US8938550B2 (en) * 2011-12-15 2015-01-20 Microsoft Corporation Autonomous network streaming
US8832296B2 (en) * 2011-12-15 2014-09-09 Microsoft Corporation Fast application streaming using on-demand staging
US9021096B2 (en) * 2012-01-23 2015-04-28 International Business Machines Corporation Performing maintenance operations on cloud computing node without requiring to stop all virtual machines in the node
US8880687B1 (en) * 2012-02-06 2014-11-04 Netapp, Inc. Detecting and managing idle virtual storage servers
TWI507891B (zh) * 2012-03-23 2015-11-11 Egis Technology Inc 具雲端儲存空間管理功能之電子裝置、雲端儲存系統、其方法及其電腦程式產品
US9342537B2 (en) 2012-04-23 2016-05-17 Commvault Systems, Inc. Integrated snapshot interface for a data storage system
US9805197B2 (en) * 2012-06-11 2017-10-31 Ent. Services Development Corporation Lp Secure host operating system running a virtual guest operating system
US20140050407A1 (en) 2012-08-17 2014-02-20 International Business Machines Corporation Virtual Machine Image Access De-Duplication
US9858095B2 (en) 2012-09-17 2018-01-02 International Business Machines Corporation Dynamic virtual machine resizing in a cloud computing infrastructure
US9507586B2 (en) * 2012-10-05 2016-11-29 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Virtual machine based controller and upgrade mechanism
US9110762B2 (en) 2012-12-04 2015-08-18 Microsoft Technology Licensing, Llc Virtual machine-preserving host updates
US9058299B2 (en) * 2013-01-08 2015-06-16 Red Hat Israel, Ltd. Efficient copying between storage devices
US9886346B2 (en) 2013-01-11 2018-02-06 Commvault Systems, Inc. Single snapshot for multiple agents
US9633027B1 (en) * 2013-03-14 2017-04-25 EMC IP Holding Company LLC High speed backup
US9098322B2 (en) 2013-03-15 2015-08-04 Bmc Software, Inc. Managing a server template
WO2014195957A1 (en) 2013-06-03 2014-12-11 Hewlett-Packard Development Company, L.P. Restoring a file system object
CN103324446A (zh) * 2013-06-07 2013-09-25 曙光信息产业(北京)有限公司 一种高性能弹性容量虚拟机磁盘的实现方法
US10489175B2 (en) * 2013-06-10 2019-11-26 Amazon Technologies, Inc. Pre-configure and pre-launch compute resources
US20150067283A1 (en) * 2013-08-27 2015-03-05 International Business Machines Corporation Image Deduplication of Guest Virtual Machines
US9563385B1 (en) * 2013-09-16 2017-02-07 Amazon Technologies, Inc. Profile-guided data preloading for virtualized resources
US9841927B2 (en) * 2013-09-23 2017-12-12 Red Hat Israel, Ltd Remote direct memory access with copy-on-write support
CN103631903B (zh) * 2013-11-22 2017-09-01 曙光信息产业股份有限公司 一种数据库同步数据的系统
US20150154042A1 (en) * 2013-12-04 2015-06-04 Hitachi, Ltd. Computer system and control method for virtual machine
US10503531B2 (en) 2013-12-24 2019-12-10 Red Hat, Inc. Loading runtime configuration files into virtual machine instances which when executed transform a stored virtual machine image into a customized configuration
KR102237566B1 (ko) * 2014-01-23 2021-04-07 한국전자통신연구원 완전 복제된 가상 머신의 디스크 이미지 파일 캐싱 시스템 및 방법
US9639426B2 (en) 2014-01-24 2017-05-02 Commvault Systems, Inc. Single snapshot for multiple applications
US9851918B2 (en) * 2014-02-21 2017-12-26 Red Hat Israel, Ltd. Copy-on-write by origin host in virtual machine live migration
US9672165B1 (en) * 2014-05-21 2017-06-06 Veritas Technologies Llc Data management tier coupling primary storage and secondary storage
CN105446827B (zh) * 2014-08-08 2018-12-14 阿里巴巴集团控股有限公司 一种数据库故障时的数据存储方法和设备
US9774672B2 (en) 2014-09-03 2017-09-26 Commvault Systems, Inc. Consolidated processing of storage-array commands by a snapshot-control media agent
US10048974B1 (en) 2014-09-30 2018-08-14 Amazon Technologies, Inc. Message-based computation request scheduling
US9323556B2 (en) 2014-09-30 2016-04-26 Amazon Technologies, Inc. Programmatic event detection and message generation for requests to execute program code
US9715402B2 (en) 2014-09-30 2017-07-25 Amazon Technologies, Inc. Dynamic code deployment and versioning
US9830193B1 (en) 2014-09-30 2017-11-28 Amazon Technologies, Inc. Automatic management of low latency computational capacity
US9600312B2 (en) 2014-09-30 2017-03-21 Amazon Technologies, Inc. Threading as a service
US9146764B1 (en) 2014-09-30 2015-09-29 Amazon Technologies, Inc. Processing event messages for user requests to execute program code
US9678773B1 (en) 2014-09-30 2017-06-13 Amazon Technologies, Inc. Low latency computational capacity provisioning
US9448731B2 (en) 2014-11-14 2016-09-20 Commvault Systems, Inc. Unified snapshot storage management
US9804965B2 (en) * 2014-12-03 2017-10-31 Electronics And Telecommunications Research Institute Virtual machine host server apparatus and method for operating the same
US9413626B2 (en) 2014-12-05 2016-08-09 Amazon Technologies, Inc. Automatic management of resource sizing
US9495189B2 (en) * 2014-12-30 2016-11-15 Vmware, Inc. Live replication of a virtual machine exported and imported via a portable storage device
CN104598170B (zh) 2015-01-30 2017-12-05 华为技术有限公司 确定读写路径的方法和装置
US10459802B2 (en) 2015-01-30 2019-10-29 Hewlett-Packard Development Company, L.P. Backup image restore
US9733967B2 (en) 2015-02-04 2017-08-15 Amazon Technologies, Inc. Security protocols for low latency execution of program code
US9588790B1 (en) 2015-02-04 2017-03-07 Amazon Technologies, Inc. Stateful virtual compute system
US11061705B2 (en) 2015-03-16 2021-07-13 Bmc Software, Inc. Maintaining virtual machine templates
US9984088B1 (en) 2015-03-31 2018-05-29 Maginatics Llc User driven data pre-fetch
US9785476B2 (en) 2015-04-08 2017-10-10 Amazon Technologies, Inc. Endpoint management system and virtual compute system
US9930103B2 (en) 2015-04-08 2018-03-27 Amazon Technologies, Inc. Endpoint management system providing an application programming interface proxy service
US9900386B2 (en) * 2015-04-09 2018-02-20 International Business Machines Corporation Provisioning data to distributed computing systems
US11294657B2 (en) 2015-05-15 2022-04-05 Hewlett-Packard Development Company, L.P. Data copying
WO2016201589A1 (en) * 2015-06-17 2016-12-22 Intel Corporation Computing apparatus and method with persistent memory
US10284433B2 (en) 2015-06-25 2019-05-07 International Business Machines Corporation Data synchronization using redundancy detection
US9910906B2 (en) 2015-06-25 2018-03-06 International Business Machines Corporation Data synchronization using redundancy detection
CN105335253B (zh) * 2015-10-28 2019-01-15 北京百度网讯科技有限公司 创建虚拟机系统盘快照的方法和装置
CN105278999A (zh) * 2015-11-19 2016-01-27 国云科技股份有限公司 一种安全高效虚拟机软件部署的方法
CN105426216B (zh) * 2015-12-11 2019-01-15 中南大学 一种基于透明计算的智能终端软件更新方法
CN105468541B (zh) * 2015-12-11 2019-01-08 中南大学 一种面向透明计算智能终端的缓存管理方法
US9811434B1 (en) 2015-12-16 2017-11-07 Amazon Technologies, Inc. Predictive management of on-demand code execution
US10754701B1 (en) 2015-12-16 2020-08-25 Amazon Technologies, Inc. Executing user-defined code in response to determining that resources expected to be utilized comply with resource restrictions
US10067801B1 (en) 2015-12-21 2018-09-04 Amazon Technologies, Inc. Acquisition and maintenance of compute capacity
US9910713B2 (en) 2015-12-21 2018-03-06 Amazon Technologies, Inc. Code execution request routing
US10230785B1 (en) * 2015-12-28 2019-03-12 Amazon Technologies, Inc. Post data synchronization for domain migration
CN105677256A (zh) * 2016-01-08 2016-06-15 中电科华云信息技术有限公司 基于本地缓存的虚拟磁盘系统及调度方法
US10503753B2 (en) 2016-03-10 2019-12-10 Commvault Systems, Inc. Snapshot replication operations based on incremental block change tracking
CN107203480B (zh) * 2016-03-17 2020-11-17 华为技术有限公司 一种数据预取方法以及装置
US10891145B2 (en) 2016-03-30 2021-01-12 Amazon Technologies, Inc. Processing pre-existing data sets at an on demand code execution environment
US11132213B1 (en) 2016-03-30 2021-09-28 Amazon Technologies, Inc. Dependency-based process of pre-existing data sets at an on demand code execution environment
US9880872B2 (en) 2016-06-10 2018-01-30 GoogleLLC Post-copy based live virtual machines migration via speculative execution and pre-paging
US10416892B2 (en) 2016-06-24 2019-09-17 International Business Machines Corporation Fileset-based data locality enablement in distributed file systems
US10282229B2 (en) 2016-06-28 2019-05-07 Amazon Technologies, Inc. Asynchronous task management in an on-demand network code execution environment
US10102040B2 (en) 2016-06-29 2018-10-16 Amazon Technologies, Inc Adjusting variable limit on concurrent code executions
US10218811B1 (en) 2016-06-29 2019-02-26 Oath (Ameericas) Inc. Systems and methods for utilizing unused network capacity for prefetch requests
US10277708B2 (en) 2016-06-30 2019-04-30 Amazon Technologies, Inc. On-demand network code execution with cross-account aliases
WO2018011881A1 (ja) * 2016-07-12 2018-01-18 株式会社日立製作所 ストレージ装置及び計算機システム
US10089135B2 (en) 2016-08-09 2018-10-02 International Business Machines Corporation Expediting the provisioning of virtual machines based on cached repeated portions of a template
CN106293535B (zh) * 2016-08-12 2020-04-03 浪潮(北京)电子信息产业有限公司 一种nas的性能优化方法及装置
US10884787B1 (en) 2016-09-23 2021-01-05 Amazon Technologies, Inc. Execution guarantees in an on-demand network code execution system
US10061613B1 (en) 2016-09-23 2018-08-28 Amazon Technologies, Inc. Idempotent task execution in on-demand network code execution systems
US11119813B1 (en) 2016-09-30 2021-09-14 Amazon Technologies, Inc. Mapreduce implementation using an on-demand network code execution system
US20180095975A1 (en) * 2016-09-30 2018-04-05 Hewlett Packard Enterprise Development Lp Managing file formats
US10303486B2 (en) * 2017-03-03 2019-05-28 Microsoft Technology Licensing, Llc Capturing pre-fetch blocks of an operating system to improve boot performance in a cloud environment
US10482632B2 (en) * 2017-04-28 2019-11-19 Uih America, Inc. System and method for image reconstruction
US20190079788A1 (en) * 2017-09-08 2019-03-14 Cisco Technology, Inc. Predictive image storage system for fast container execution
EP3502877B1 (de) 2017-09-29 2021-03-03 Huawei Technologies Co., Ltd. Verfahren und vorrichtung zum datenladen für virtuelle maschinen
WO2019104061A1 (en) * 2017-11-22 2019-05-31 Vital Images, Inc. Automatic detection and generation of medical imaging data analytics
US10564946B1 (en) 2017-12-13 2020-02-18 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US10733085B1 (en) 2018-02-05 2020-08-04 Amazon Technologies, Inc. Detecting impedance mismatches due to cross-service calls
US10831898B1 (en) 2018-02-05 2020-11-10 Amazon Technologies, Inc. Detecting privilege escalations in code including cross-service calls
US10353678B1 (en) 2018-02-05 2019-07-16 Amazon Technologies, Inc. Detecting code characteristic alterations due to cross-service calls
US10540112B2 (en) 2018-02-06 2020-01-21 Nutanix, Inc. System and method for migrating virtual machines with storage while in use
US10725752B1 (en) 2018-02-13 2020-07-28 Amazon Technologies, Inc. Dependency handling in an on-demand network code execution system
US20210334003A1 (en) * 2018-02-14 2021-10-28 Commvault Systems, Inc. Private snapshots based on sparse files and data replication
US10732885B2 (en) * 2018-02-14 2020-08-04 Commvault Systems, Inc. Block-level live browsing and private writable snapshots using an ISCSI server
US10776091B1 (en) 2018-02-26 2020-09-15 Amazon Technologies, Inc. Logging endpoint in an on-demand code execution system
US10853115B2 (en) 2018-06-25 2020-12-01 Amazon Technologies, Inc. Execution of auxiliary functions in an on-demand network code execution system
US10649749B1 (en) 2018-06-26 2020-05-12 Amazon Technologies, Inc. Cross-environment application of tracing information for improved code execution
US11146569B1 (en) 2018-06-28 2021-10-12 Amazon Technologies, Inc. Escalation-resistant secure network services using request-scoped authentication information
US10949237B2 (en) 2018-06-29 2021-03-16 Amazon Technologies, Inc. Operating system customization in an on-demand network code execution system
US11099870B1 (en) 2018-07-25 2021-08-24 Amazon Technologies, Inc. Reducing execution times in an on-demand network code execution system using saved machine states
US11099917B2 (en) 2018-09-27 2021-08-24 Amazon Technologies, Inc. Efficient state maintenance for execution environments in an on-demand code execution system
US11243953B2 (en) 2018-09-27 2022-02-08 Amazon Technologies, Inc. Mapreduce implementation in an on-demand network code execution system and stream data processing system
WO2020096561A1 (en) * 2018-11-05 2020-05-14 Hewlett-Packard Development Company, L.P. Recovery image downloads via data chunks
US11943093B1 (en) 2018-11-20 2024-03-26 Amazon Technologies, Inc. Network connection recovery after virtual machine transition in an on-demand network code execution system
US10884812B2 (en) 2018-12-13 2021-01-05 Amazon Technologies, Inc. Performance-based hardware emulation in an on-demand network code execution system
US10802813B2 (en) 2018-12-19 2020-10-13 Atlassian Pty Ltd. Systems and methods for updating virtual machines
JP7197783B2 (ja) 2019-01-11 2022-12-28 富士通株式会社 情報処理システム、管理装置および管理プログラム
US11163614B1 (en) * 2019-01-26 2021-11-02 Evolute, Inc. Systems and methods for migrating virtual machines to containers
US11010188B1 (en) 2019-02-05 2021-05-18 Amazon Technologies, Inc. Simulated data object storage using on-demand computation of data objects
US11861386B1 (en) 2019-03-22 2024-01-02 Amazon Technologies, Inc. Application gateways in an on-demand network code execution system
US11119809B1 (en) 2019-06-20 2021-09-14 Amazon Technologies, Inc. Virtualization-based transaction handling in an on-demand network code execution system
US11190609B2 (en) 2019-06-28 2021-11-30 Amazon Technologies, Inc. Connection pooling for scalable network services
US11159528B2 (en) 2019-06-28 2021-10-26 Amazon Technologies, Inc. Authentication to network-services using hosted authentication information
US11115404B2 (en) 2019-06-28 2021-09-07 Amazon Technologies, Inc. Facilitating service connections in serverless code executions
US11360948B2 (en) 2019-09-27 2022-06-14 Amazon Technologies, Inc. Inserting owner-specified data processing pipelines into input/output path of object storage service
US10908927B1 (en) 2019-09-27 2021-02-02 Amazon Technologies, Inc. On-demand execution of object filter code in output path of object storage service
US10996961B2 (en) 2019-09-27 2021-05-04 Amazon Technologies, Inc. On-demand indexing of data in input path of object storage service
US11250007B1 (en) 2019-09-27 2022-02-15 Amazon Technologies, Inc. On-demand execution of object combination code in output path of object storage service
US11416628B2 (en) 2019-09-27 2022-08-16 Amazon Technologies, Inc. User-specific data manipulation system for object storage service based on user-submitted code
US11394761B1 (en) 2019-09-27 2022-07-19 Amazon Technologies, Inc. Execution of user-submitted code on a stream of data
US11550944B2 (en) 2019-09-27 2023-01-10 Amazon Technologies, Inc. Code execution environment customization system for object storage service
US11023311B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. On-demand code execution in input path of data uploaded to storage service in multiple data portions
US11263220B2 (en) 2019-09-27 2022-03-01 Amazon Technologies, Inc. On-demand execution of object transformation code in output path of object storage service
US11023416B2 (en) 2019-09-27 2021-06-01 Amazon Technologies, Inc. Data access control system for object storage service based on owner-defined code
US11656892B1 (en) 2019-09-27 2023-05-23 Amazon Technologies, Inc. Sequential execution of user-submitted code and native functions
US11106477B2 (en) 2019-09-27 2021-08-31 Amazon Technologies, Inc. Execution of owner-specified code during input/output path to object storage service
US11386230B2 (en) 2019-09-27 2022-07-12 Amazon Technologies, Inc. On-demand code obfuscation of data in input path of object storage service
US11055112B2 (en) 2019-09-27 2021-07-06 Amazon Technologies, Inc. Inserting executions of owner-specified code into input/output path of object storage service
US11119826B2 (en) 2019-11-27 2021-09-14 Amazon Technologies, Inc. Serverless call distribution to implement spillover while avoiding cold starts
US10942795B1 (en) 2019-11-27 2021-03-09 Amazon Technologies, Inc. Serverless call distribution to utilize reserved capacity without inhibiting scaling
US11714682B1 (en) 2020-03-03 2023-08-01 Amazon Technologies, Inc. Reclaiming computing resources in an on-demand code execution system
US11188391B1 (en) 2020-03-11 2021-11-30 Amazon Technologies, Inc. Allocating resources to on-demand code executions under scarcity conditions
US11775640B1 (en) 2020-03-30 2023-10-03 Amazon Technologies, Inc. Resource utilization-based malicious task detection in an on-demand code execution system
US11409619B2 (en) 2020-04-29 2022-08-09 The Research Foundation For The State University Of New York Recovering a virtual machine after failure of post-copy live migration
CN113835822A (zh) * 2020-06-23 2021-12-24 中兴通讯股份有限公司 跨云平台虚拟机迁移方法、装置、存储介质及电子装置
US11550713B1 (en) 2020-11-25 2023-01-10 Amazon Technologies, Inc. Garbage collection in distributed systems using life cycled storage roots
US11593270B1 (en) 2020-11-25 2023-02-28 Amazon Technologies, Inc. Fast distributed caching using erasure coded object parts
CN112988077B (zh) * 2021-04-27 2021-07-23 云宏信息科技股份有限公司 一种虚拟磁盘复制方法和计算机可读存储介质
US11388210B1 (en) 2021-06-30 2022-07-12 Amazon Technologies, Inc. Streaming analytics using a serverless compute system
US11880282B2 (en) 2021-09-15 2024-01-23 Trilio Data, Inc. Container-based application data protection method and system
CN113885808B (zh) * 2021-10-28 2024-03-15 合肥兆芯电子有限公司 映射信息记录方法以及存储器控制电路单元与存储装置
US11968280B1 (en) 2021-11-24 2024-04-23 Amazon Technologies, Inc. Controlling ingestion of streaming data to serverless function executions
US12015603B2 (en) 2021-12-10 2024-06-18 Amazon Technologies, Inc. Multi-tenant mode for serverless code execution
US11979454B2 (en) * 2022-08-29 2024-05-07 Vertiv It Systems, Inc. Writeback to a virtual media mapped image in HTML5

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7062517B2 (en) 2002-08-14 2006-06-13 Hitachi, Ltd. Method and apparatus for centralized computer management
US7849462B2 (en) 2005-01-07 2010-12-07 Microsoft Corporation Image server
US7506071B2 (en) 2005-07-19 2009-03-17 International Business Machines Corporation Methods for managing an interactive streaming image system
US7653794B2 (en) * 2006-05-08 2010-01-26 Microsoft Corporation Converting physical machines to virtual machines
KR20070111603A (ko) * 2006-05-18 2007-11-22 이상규 클라이언트 및 서버의 보안시스템
WO2008115012A1 (en) 2007-03-20 2008-09-25 Sanggyu Lee Movable virtual machine image
US8069341B2 (en) 2007-06-29 2011-11-29 Microsoft Corporation Unified provisioning of physical and virtual images
EP2238535A4 (de) 2007-12-20 2011-03-09 Virtual Computer Inc Verwaltungssysteme und -verfahren für virtuelle datenverarbeitung
WO2009145274A1 (ja) * 2008-05-29 2009-12-03 株式会社シー・オー・コンヴ ネットワークブートシステム
US20090328030A1 (en) 2008-06-27 2009-12-31 Microsoft Corporation Installing a management agent with a virtual machine
CN101419535B (zh) * 2008-11-19 2010-07-14 北京航空航天大学 虚拟机的分布式虚拟磁盘系统
US8341620B2 (en) 2009-06-25 2012-12-25 Microsoft Corporation Streaming optimized virtual application images
US8356149B2 (en) * 2009-10-30 2013-01-15 Hewlett-Packard Development Company, L.P. Memory migration
US8438564B2 (en) * 2010-03-30 2013-05-07 Lenovo (Singapore) Pte. Ltd. Systems and methods for minimizing client computer system set-up time

Also Published As

Publication number Publication date
DE112011103026B4 (de) 2022-03-03
GB2498129B (en) 2017-11-08
CN103098043B (zh) 2015-04-22
US8490088B2 (en) 2013-07-16
GB201305422D0 (en) 2013-05-08
GB2498129A (en) 2013-07-03
JP5657121B2 (ja) 2015-01-21
CN103098043A (zh) 2013-05-08
JP2013542486A (ja) 2013-11-21
US20120066677A1 (en) 2012-03-15
WO2012033554A1 (en) 2012-03-15

Similar Documents

Publication Publication Date Title
DE112011103026B4 (de) Bedarfsgesteuertes Streaming von Abbildern virtueller Maschinen
US10817333B2 (en) Managing memory in devices that host virtual machines and have shared memory
AU2007248886B2 (en) Converting machines to virtual machines
DE112012002241T5 (de) Migration eines transparenten Dateisystems zu einem neuen physischen Speicherort
DE69604734T2 (de) Client-Server-Computersystem und Verfahren zum Verwenden eines lokalen Plattenlaufwerks als Daten-Cache
DE112010003554B4 (de) Symmetrische Direktmigration von Virtuellen Maschinen
DE102004038649B4 (de) Dauerspeichervorrichtung für Sicherungsprozess-Prüfpunktzustände
CN107209683B (zh) 备份映像恢复
DE112011104356B4 (de) Aktualisieren von Software-Images auf der Grundlage von Streaming-Technik
DE112012000693B4 (de) Ausführen einer Vielzahl von Instanzen einer Anwendung
US20160179419A1 (en) Storage system, storage management apparatus, and storage management method
DE112012004893B4 (de) Implementieren eines Software-Abbildes auf mehreren Zielen unter Verwendung einer Datenstromtechnik
US20090144515A1 (en) Method and system thereof for restoring virtual desktops
CN103699496A (zh) 分级存储器管理
DE112011100323T5 (de) Architekturübergreifende Migration virtueller Maschinen
US20130318301A1 (en) Virtual Machine Exclusive Caching
DE112015000430T5 (de) Einheitliche Speichersysteme und -verfahren
DE112012005209T5 (de) Brückenfunktion zwischen Virtual Machine Monitor und Bare-Metal-Bootvorgang
DE112020004181T5 (de) Bereitstellen eines direkten datenzugriffs zwischen beschleunigern und speicher in einer datenverarbeitungsumgebung
DE112018005768B4 (de) Copy-source-to-target-verwaltung in einem datenspeichersystem
DE112020003929T5 (de) Verwaltung von metadaten von virtuellen speichern
DE112020000498T5 (de) Migrieren von daten aus einem grossen extent-pool in einen kleinen extent-pool
DE102012221261A1 (de) Verfahren zum Zwischenspeichern und System zum Ausführen des Verfahrens zum Zwischenspeichern zum Betreiben eines mindestens einen Host-Computer aufweisenden Computerserversystems
DE112016005868T5 (de) Starten von Anwendungsprozessoren einer virtuellen Maschine
CN111367472A (zh) 虚拟化方法和装置

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0015160000

Ipc: G06F0009440000

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0015160000

Ipc: G06F0009440000

Effective date: 20150323

R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0009440000

Ipc: G06F0015160000

R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R084 Declaration of willingness to licence
R020 Patent grant now final