DE112012004893B4

DE112012004893B4 - Implementieren eines Software-Abbildes auf mehreren Zielen unter Verwendung einer Datenstromtechnik

Info

Publication number: DE112012004893B4
Application number: DE112012004893.8T
Authority: DE
Inventors: c/o IBM Italia SpA Marinelli Claudio; c/o IBM Research GmbH Fontignie Jacques; c/o IBM Italia SpA Pastorelli Bernardo; c/o IBM Italia SpA Pichetti Luigi
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-12-13
Filing date: 2012-12-04
Publication date: 2021-05-12
Anticipated expiration: 2032-12-05
Also published as: JP2015501995A; GB2512006B; GB2512006A; US20130151834A1; DE112012004893T5; CN104011677A; CN104011677B; WO2013088302A1; US20130151835A1; GB201412336D0; US8930685B2; US9104431B2

Abstract

Verfahren (400) zum Implementieren eines Software-Abbildes von einem Quellen-Datenverarbeitungssystem auf einer Vielzahl von Ziel-Datenverarbeitungseinheiten eines Ziel-Datenverarbeitungssystems, wobei das Software-Abbild eine Vielzahl von Speicherblöcken aufweist, auf die einzeln zugegriffen werden kann, wobei eine vordefinierte Teilmenge der Speicherblöcke ein Bootstrap-Modul definieren und das Verfahren die Schritte aufweist:Herunterladen (406) des Bootstrap-Moduls von dem Quellen-Datenverarbeitungssystem auf eine Haupteinheit der Ziel-Datenverarbeitungseinheiten,Booten (407 bis 409) der Haupt-Ziel-Datenverarbeitungseinheit von dem Bootstrap-Modul und dadurch Laden eines in dem Bootstrap-Modul enthaltenen Datenstromtreibers,Erfüllen (410 bis 422) jeder Anforderung für das Zugreifen auf einen ausgewählten Speicherblock des Software-Abbildes auf der Haupt-Datenverarbeitungseinheit durch den Datenstromtreiber, indem der Datenstromtreiber als Reaktion auf eine erste der Anforderungen für das Zugreifen auf den ausgewählten Speicherblock den ausgewählten Speicherblock von dem Quellen-Datenverarbeitungssystem herunterlädt (413 bis 414) und den ausgewählten Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit speichert (415 bis 416) oder, wenn dies nicht der Fall ist, auf den ausgewählten Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit zugreift (417),Bereitstellen (423 bis 427) des Bootstrap-Moduls für jede einzelne aus einer Gruppe sekundärer Ziel-Datenverarbeitungseinheiten,Booten (428 bis 429) jeder sekundären Ziel-Datenverarbeitungseinheit von dem Bootstrap-Modul und dadurch Laden des Datenstromtreibers, und Erfüllen (430 bis 448) jeder Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock des Software-Abbildes auf der sekundären Datenverarbeitungseinheit durch den Datenstromtreiber, indem der Datenstromtreiber als Reaktion auf eine erste der Anforderungen für das Zugreifen auf den weiteren ausgewählten Speicherblock den weiteren ausgewählten Speicherblock von der Haupt-Ziel-Datenverarbeitungseinheit abruft und den weiteren ausgewählten Speicherblock in der sekundären Ziel-Datenverarbeitungseinheit speichert (441 bis 442) oder, wenn dies nicht der Fall ist, auf den weiteren ausgewählten Speicherblock in der sekundären Ziel-Datenverarbeitungseinheit zugreift (443),Empfangen (449) einer Anforderung für ein Entfernen der Haupt-Ziel-Datenverarbeitungseinheit aus dem Ziel-Datenverarbeitungssystem,Auswählen (450 bis 452) einer der sekundären Ziel-Datenverarbeitungseinheiten,Festlegen (453 bis 456) der ausgewählten sekundären Ziel-Datenverarbeitungseinheit als neue Haupt-Ziel-Datenverarbeitungseinheit, undEntfernen (457) der Haupt-Ziel-Datenverarbeitungseinheit aus dem Ziel-Datenverarbeitungssystem,wobei der Schritt des Auswählens (450 bis 452) einer der sekundären Ziel-Datenverarbeitungseinheiten aufweist:Auswählen (452) der ältesten der sekundären Ziel-Datenverarbeitungseinheiten.

Description

Technisches Gebiet
Die Lösung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung betrifft das Gebiet der Datenverarbeitung. Insbesondere betrifft diese Lösung ein Implementieren von Software-Abbildern.
Zugrunde liegende Technik
Software-Abbilder stellen ein entscheidendes Merkmal moderner Datenverarbeitungssysteme dar. Allgemein ist unter einem Software-Abbild eine Struktur zu verstehen, die auf einer (physischen oder virtuellen) Datenverarbeitungsmaschine vorhandene Dateien kapselt - indem sie zum Beispiel ihr Betriebssystem, Anwendungsprogramme und/oder Daten speichert. Die Software-Abbilder eignen sich dazu, auf sehr einfache Weise verschoben, kopiert, repliziert, geschützt und mit einem Profil versehen zu werden. Diese Vorteile treten besonders deutlich zutage, wenn Software-Abbilder in virtuellen Maschinen verwendet werden (d.h. Emulationen von physischen Maschinen durch Software); tatsächlich kann in diesem Fall jede Art von virtuellen Maschinen auf Wunsch bereitgestellt werden, indem einfach eine neue virtuelle Maschine erzeugt und diese dann von einem gewünschten Software-Abbild aus gebootet wird. Dies ist zum Beispiel besonders beim Cloud-Computing von Nutzen (wobei Client-Computern, die sich über ihre physische Implementierung völlig im Unklaren sind, mehrere Datenverarbeitungsdienste bereitgestellt werden).
Die Software-Abbilder sind im Allgemeinen in einem Quellen-Datenverarbeitungssystem (zum Beispiel in einem Quellen-Server) gespeichert, von dem aus sie auf mehreren Ziel-Datenverarbeitungseinheiten (zum Beispiel auf virtuellen Zielmaschinen, die auf einem Zielserver verwaltet werden) implementiert werden. Bei dem Ziel-Server handelt es sich im Allgemeinen um den Quellen-Server; deshalb stellt das Implementieren der Software-Abbilder auf deren virtuellen Zielmaschinen einen relativ langen Prozess dar.
Zur Lösung dieses Problems ist auch vorgeschlagen worden, bestimmte virtuelle Zielmaschinen zum Bereitstellen des Software-Abbildes (oder zumindest eines Teils davon) auf anderen virtuellen Zielmaschinen zu verwenden - was zum Beispiel in der US-Patentanmeldung A-2011/0231844, der US-Patentschrift B-7788713 und der US-Patentanmeldung A-2011/0219372 beschrieben wird (deren vollständige Offenbarung durch Bezugnahme hierin aufgenommen ist). Darüber hinaus kann das Software-Abbild auch entlang eines Netzwerkpfades vom Quellen-Server zu den Ziel-Servern zwischengespeichert werden, damit andere Ziel-Server darauf zugreifen können - wie zum Beispiel beschrieben wird in „Datacast: A Scalable and Efficient Group Data Delivery Service for Data Centers, Chuanxiong Guo et al. (Microsoft Ltd.), Microsoft Technology report (MSR-TR-2011-76)“ (dessen vollständige Offenbarung durch Bezugnahme hierin aufgenommen ist).
In jedem Fall ist jede neue virtuelle Zielmaschine erst verfügbar, nachdem das gesamte Software-Abbild darauf implementiert worden ist (im Allgemeinen nach mehreren Stunden).
Anstatt das gesamte Software-Abbild auf jeder virtuellen Zielmaschine zu implementieren, können stattdessen auf Anforderung nur einzelne seiner Speicherblöcke heruntergeladen werden; die heruntergeladenen Speicherblöcke können auch vorübergehend in einem lokalen Speicher gespeichert und möglicherweise für ihre nächste Verwendung vorabgerufen werden. Insbesondere wird in „Optimizing Multi-Deployment On Clouds By Means Of Self-Adaptive Prefetching, Nicolae, Bogdan et al; Cappello, Franck et al., Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), Band 6852 LNCS, n TEIL 1, S. 503 bis 513, 2011, Euro-Par 2011 Parallel Processing - 17th International Conference, Tagungsband, Springer Verlag“ (dessen gesamte Offenbarung durch Bezugnahme hierin aufgenommen ist) beschrieben, dass, wenn gleichzeitig mehrere Instanzen desselben Software-Abbildes auf demselben Ziel-Server verwendet werden, deren Speicherblöcke gemäß einem früheren Zugriffsmuster der schnelleren virtuellen Zielmaschinen durch die langsameren virtuellen Zielmaschinen vorabgerufen werden können (da deren Zugriffsmuster sehr ähnlich sein dürften).
Bei der oben beschriebenen Technik werden die Speicherblöcke des Software-Abbildes jedoch nur zur sofortigen Verwendung auf jede virtuelle Zielmaschine heruntergeladen. Deshalb verschwinden diese Speicherblöcke, nachdem diese verwendet worden sind sowie immer nach dem Abschalten der virtuellen Zielmaschine, sodass sie für ihre erneute Verwendung (durch den Ziel-Server, der nie vom Quellen-Server getrennt werden kann) immer wieder heruntergeladen werden müssen. Selbst wenn die Speicherblöcke im lokalen Speicher gespeichert werden (möglicherweise nach deren Vorabruf), verbleiben im lokalen Speicher zur erneuten Verwendung nur wenige Speicherblöcke (jedenfalls von den längere Zeit nicht verwendeten Speicherblöcken im lokalen Speicher, die dann letztlich zum Speichern neuer Speicherblöcke entfernt werden).
Die akademische Veröffentlichung „OS Streaming Deployment“ betrifft ein Verfahren zur Verfügbarmachung von Betriebssystemen zur Verwendung während ihrer Bereitstellung. Das Verfahren beruht auf dem Ausführen eines Streaming-Deployments, bei dem Sektoren bei der ersten Anforderung übertragen werden. Im Vergleich zu einem herkömmlichen Netzwerk-Deployment verringert sich dadurch die Zeit, in der die Maschine nicht verfügbar ist, um eine Größenordnung (CLERC, D.; GARCES-ERICE, L.; ROONEY, S.: OS Streaming Deployment. In: Proc. 2010 IEEE 29th International Performance Computing and Communications Conference (IPCCC 2010). New York: IEEE, 2010. S. 169- 179. - ISBN 978-1-4244-9330-2).
Die US 2011 / 0 264 776 A1 betrifft ein Verfahren zum Bereitstellen eines Betriebssystems auf einem Client-System. Das Verfahren umfasst das Empfangen, mit dem Client-System, eines Bootloader-Images von einem externen Gerät in Reaktion auf eine Anforderung für das Bootloader-Image und das Installieren des Bootloaders. Der installierte Bootloader ist so konfiguriert, dass er eine Streaming-Funktion vom Client-System sowohl für ein Client-Repository des Client-Systems als auch für ein entferntes Daten-Repository bereitstellt und Anforderungen für einen Datenblock selektiv umleitet, und zwar entweder an das Client-Repository oder das entfernte Daten-Repository. Das Verfahren umfasst ferner das Erstellen, mit dem Client-System, einer Anforderung für einen Datenblock des Betriebssystems während des Betriebs einer Funktion des Betriebssystems das Erstellen, wobei der Datenblock die Funktion umfasst, und das Empfangen des Datenblocks von einem von: dem Client-Repository und dem entfernten Repository auf Grundlage der Verfügbarkeitsinformationen.
Kurzdarstellung
Grundsätzlich beruht die Lösung gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung auf der Idee, das Software-Abbild zu implementieren, indem seine Speicherblöcke von dort abgerufen werden, wo sie bereits heruntergeladen worden sind.
Insbesondere werden in den Hauptansprüchen ein oder mehrere Aspekte der Lösung gemäß einzelnen Ausführungsformen der Erfindung und in den Unteransprüchen vorteilhafte Merkmale derselben Lösung dargelegt, wobei der Text aller Ansprüche im Wortlaut durch Bezugnahme hierin aufgenommen ist (wobei sich jedes vorteilhafte Merkmal auf einen bestimmten Aspekt der Lösung gemäß einer Ausführungsform der Erfindung bezieht, der sich sinngemäß auf jeden ihrer anderen Aspekte bezieht).
Genauer gesagt stellt ein Aspekt der Lösung gemäß einer Ausführungsform der Erfindung ein Verfahren zum Implementieren eines Software-Abbildes von einem Quellen-Datenverarbeitungssystem auf einer Vielzahl von Ziel-Datenverarbeitungseinheiten eines Ziel-Datenverarbeitungssystems bereit, wobei es sich bei einer davon um eine Haupt-Ziel-Datenverarbeitungseinheit (in der Speicherblöcke des Software-Abbildes von dem Quellen-Datenverarbeitungssystem heruntergeladen und bei ihrem ersten Zugriff lokal gespeichert werden) und bei den anderen um sekundäre Ziel-Datenverarbeitungseinheiten handelt (in denen Speicherblöcke des Software-Abbildes von der Haupt-Ziel-Datenverarbeitungseinheit abgerufen und bei ihrem ersten Zugriff lokal gespeichert werden).
Gemäß einem weiteren Aspekt der Lösung gemäß einer Ausführungsform der Erfindung wird ein entsprechendes Computerprogramm bereitgestellt.
Gemäß noch einem weiteren Aspekt der Lösung gemäß einer Ausführungsform der Erfindung wird ein entsprechendes Computerprogrammprodukt bereitgestellt.
Gemäß einem anderen Aspekt der Lösung gemäß einer Ausführungsform der Erfindung wird ein entsprechendes Datenverarbeitungssystem bereitgestellt.
Figurenliste
Die Lösung gemäß einer oder mehreren Ausführungsformen der Erfindung sowie weitere ihrer Merkmale und Vorteile werden am besten unter Bezugnahme auf die folgende detaillierte Beschreibung, die nicht als Einschränkung zu verstehen ist, in Verbindung mit den beiliegenden Zeichnungen verständlich (in denen zur Vereinfachung entsprechende Elemente durch gleiche oder ähnliche Bezugszeichen bezeichnet sind, deren Erläuterung nicht wiederholt wird und deren Bezeichnung allgemein zum Kennzeichnen deren Typs und Eigenschaften verwendet wird - beispielsweise als Wert, Inhalt und Darstellung). Insbesondere:

zeigt 1 eine bildliche Darstellung einer Implementierungs-Infrastruktur, die zur praktischen Umsetzung der Lösung gemäß einer Ausführungsform der Erfindung verwendet werden kann,
zeigen die 2A bis 2I eine Prinzipdarstellung einer Anwendung der Lösung gemäß einer Ausführungsform der Erfindung,
zeigt 3 ein Blockschaubild der Haupt-Softwaremodule, die zum Umsetzen der Lösung gemäß einer Ausführungsform der Erfindung verwendet werden können, und
die 4A bis 4E zeigen ein Funktionsschaubild der Arbeitsschritte beim Implementieren der Lösung gemäß einer Ausführungsform der Erfindung.

Detaillierte Beschreibung
1 zeigt eine Implementierungs-Infrastruktur 100, die zur praktischen Umsetzung der Lösung gemäß einer Ausführungsform der Erfindung verwendet werden kann.
Die Implementierungs-Infrastruktur 100 weist eine verteilte Architektur auf, die auf einem Netzwerk 105 - zum Beispiel einem lokalen Netzwerk - beruht. Mehrere Datenverarbeitungssysteme (zum Beispiel Server-Computer) sind durch das Netzwerk 105 miteinander verbunden. Insbesondere wird die Implementierung von Software-Abbildern (zum Beispiel eines Software-Abbildes, das ein Betriebssystem und verschiedene Anwendungsprogramme aufweist) auf einem oder mehreren Ziel-Server-Computern (oder einfach Ziel-Servern) 115 durch einen Quellen-Server-Computer 110 gesteuert.
Jeder (Quellen- oder Ziel-) Server 110, 115 weist mehrere Einheiten auf, die parallel mit einem Systembus 120 verbunden sind. Im Einzelnen steuern ein oder mehrere Mikroprozessoren (µP) 125 den Arbeitsablauf der Server 110,115; ein RAM 130 dient als Arbeitsspeicher für die Mikroprozessoren 115, und in einem ROM 135 ist ein Standardcode als Bootprogramm für den Server 110, 115 gespeichert. Um einen lokalen Bus 140 herum sind (mittels entsprechender Schnittstellen) mehrere Peripherieeinheiten konzentriert. Insbesondere ein Massenspeicher, der eine oder mehrere Festplatten 145 aufweist, und Laufwerke 150 zum Lesen/Schreiben von optischen Speicherplatten 155. Darüber hinaus weist der Server 110, 115 Eingabeeinheiten 160 (zum Beispiel eine Tastatur und eine Maus) und Ausgabeeinheiten 165 (zum Beispiel einen Monitor und einen Drucker) auf. Ein Netzwerkadapter 170 dient dazu, den Server 110,115 mit dem Netzwerk 105 zu verbinden. Eine Brückeneinheit 175 verbindet den Systembus 120 mit dem lokalen Bus 140. Jeder Mikroprozessor 125 und die Brückeneinheit 175 können als Masteragenten fungieren, um einen Zugriff auf den Systembus 120 zum Übertragen von Daten anzufordern. Eine Zuteilungseinheit 180 verwaltet die Gewährung des Zugriffs auf den Systembus 120 unter gegenseitigem Ausschluss.
Die 2A bis 2I zeigen eine Prinzipdarstellung einer Anwendung der Lösung gemäß einer Ausführungsform der Erfindung.
Zu Anfang wird in 2A ein typisches Software-Abbild, das von dem Quellen-Server 105 auf mehreren virtuellen Zielmaschinen implementiert werden soll, die auf einem der Ziel-Server 110 betrieben werden, mit dem Bezugszeichen SI bezeichnet.
Das Software-Abbild SI weist eine Vielzahl von Speicherblöcken auf, auf die (zum Lesen und/oder Schreiben) jeweils einzeln zugegriffen werden kann; die Speicherblöcke können jegliche Art von Daten enthalten, beispielsweise einen oder mehrere Sektoren, Dateien, Bibliotheken, Verzeichnisse, Kombinationen oder Teile derselben (zum Beispiel kann jeder von ihnen aus 520 Byte bestehen). Durch eine Teilmenge der Speicherblöcke ist ein Bootstrap-Modul Bt definiert, das die Speicherblöcke (an ihren richtigen Speicherplätzen, aber nicht unbedingt einander benachbart) aufweist, die zum Booten der virtuellen Zielmaschinen erforderlich sind, um einen (im Folgenden beschriebenen) Datenstromtreiber zu laden.
Weiterhin wird in 2B aus den virtuellen Zielmaschinen eine (als virtuelle Hauptmaschine VMm bezeichnete) Hauptmaschine ausgewählt, um das Software-Abbild SI zu implementieren (zum Beispiel eine erste virtuelle Zielmaschine, die auf dem Ziel-Server 110 erzeugt wurde, um darauf eine erstmalige Implementierung des Software-Abbildes SI vorzunehmen). Das Bootstrap-Modul Bt wird von dem Quellen-Server 105 auf die virtuelle Hauptmaschine VMm heruntergeladen; sodann wird die virtuelle Hauptmaschine VMm von dem Bootstrap-Modul Bt gebootet, wodurch der darin enthaltene (in der Figur nicht gezeigte) Datenstromtreiber geladen wird.
Gemäß 2C wird nunmehr jede Anforderung für das Zugreifen auf einen ausgewählten Speicherblock (mit dem Bezugszeichen MBs) des Software-Abbildes SI während des Betriebs der virtuellen Hauptmaschine durch den Datenstromtreiber erfüllt. Insbesondere wenn der Speicherblock MBs auf der virtuellen Hauptmaschine VMm zum ersten Mal angefordert wird, lädt der Datenstromtreiber den Speicherblock MBs vom Quellen-Server 105 herunter und speichert ihn in der virtuellen Hauptmaschine VMm.
Wenn hingegen gemäß 2D ein nächstes Mal auf einen ausgewählten Speicher zugegriffen wird (wie später bei demselben Speicherblock MBs verfahren wird), ist dieser bereits in der virtuellen Hauptmaschine VMm gespeichert; deshalb kann nunmehr direkt in der virtuellen Hauptmaschine VMm auf den Speicherblock MBs zugegriffen werden (ohne diesen erneut von dem Quellen-Server 105 herunterladen zu müssen).
Durch die oben beschriebenen Datenstromtechnik wird jede virtuelle Zielmaschine innerhalb sehr kurzer Zeit betriebsbereit - unmittelbar, nachdem das Bootstrap-Modul auf diese heruntergeladen worden ist, selbst wenn die Implementierung des restlichen Software-Abbildes noch andauert (zum Beispiel nach 1 bis 2 Minuten für einen typischen Umfang des Bootstrap-Moduls von 10 bis 200 MByte); der Betrieb der virtuellen Zielmaschine läuft dann unabhängig davon, ob die anderen Speicherblöcke des Software-Abbildes darin verfügbar sind, normal ab - wobei es nur zu einem geringfügigen Leistungsabfall der virtuellen Zielmaschine kommt, wenn diese auf noch vom Quellen-Server herunterzuladende Speicherblöcke zugreift. Darüber hinaus ist die Zeitspanne, die benötigt wird, um die virtuelle Hauptmaschine betriebsbereit zu machen, von der Größe des Software-Abbildes unabhängig. Mit der Zeit nimmt die Nutzung des Netzwerks zum Herunterladen des Software-Abbildes auf die virtuelle Hauptmaschine ab (zum Beispiel logarithmisch), da in der virtuellen Hauptmaschine immer mehr Speicherblöcke des Software-Abbildes verfügbar sind, nachdem einmal auf diese zugegriffen worden ist.
Gemäß 2E wird eine zweite (als sekundäre virtuelle Maschine VMs bezeichnete) virtuelle Zielmaschine zum Implementieren desselben Software-Abbildes SI ausgewählt (zum Beispiel eine nächste virtuelle Zielmaschine, die auf dem Ziel-Server 100 für eine nächste Implementierung des Software-Abbildes SI darauf erzeugt wird). Das Bootstrap-Modul Bt wird der sekundären virtuellen Maschine VMs zugeführt (zum Beispiel durch erneutes Herunterladen von dem Quellen-Server 105); die sekundäre virtuelle Maschine VMs wird wie oben von dem Bootstrap-Modul Bt gebootet, wodurch der darin enthaltene (in der Figur nicht gezeigte) Datenstromtreiber geladen wird.
Gemäß 2F wird jede Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock in dem Software-Abbild SI (ebenso wie oben bei demselben Speicherblock MBs) während des Betriebs der sekundären virtuellen Maschine VMS durch den Datenstromtreiber erfüllt.
Wenn der Speicherblock MBs ein erstes Mal auf der sekundären virtuellen Maschine VMs angefordert wird, ruft bei der Lösung gemäß einer Ausführungsform der Erfindung der Datenstromtreiber nunmehr jedoch den Speicherblock MBs von der virtuellen Hauptmaschine VMm ab und speichert diesen in der sekundären virtuellen Maschine VMs zusammen mit dem Speicherblock MBs, der direkt von der virtuellen Hauptmaschine VMm gelesen oder von dem Quellen-Server 105 heruntergeladen und wie oben darin gespeichert wurde.
Wenn hingegen gemäß 2G ein nächstes Mal auf einen ausgewählten Speicherblock zugegriffen wird (wie später im Fall desselben Speicherblocks MBs), ist dieser bereits in der sekundären virtuellen Maschine VMs gespeichert; deshalb kann jetzt auf den Speicherblock MBs direkt in der sekundären virtuellen Maschine VMs zugegriffen werden (ohne ihn noch einmal von der virtuellen Hauptmaschine VMm abrufen zu müssen).
Dadurch wird die Notwendigkeit, die Speicherblöcke von dem Quellen-Server herunterzuladen, stark verringert, da jeder Speicherblock nunmehr nur einmal auf die virtuelle Hauptmaschine heruntergeladen wird.
Da die virtuellen Zielmaschinen (Hauptmaschine und sekundäre Maschine) einander sehr ähnlich sind (da sie auf demselben Software-Abbild beruhen), weisen sie darüber hinaus höchstwahrscheinlich auch ein ähnliches Verhalten auf (d.h., im Wesentlichen in derselben Reihenfolge im Wesentlichen auf dieselben Speicherblöcke zuzugreifen); deshalb ist die Wahrscheinlichkeit, dass die durch jede sekundäre virtuelle Maschine angeforderten Speicherblöcke bereits in der virtuellen Hauptmaschine gespeichert sind (und dann schnell direkt abgerufen werden können), sehr hoch.
Die Auswirkung der oben beschriebenen Lösung auf die virtuelle Hauptmaschine ist in den meisten praktischen Fällen vernachlässigbar; in der Tat beeinträchtigt der Systemaufwand der virtuellen Hauptmaschine zum Erfüllen der Anforderungen von den sekundären virtuellen Maschinen deren Betrieb nur unwesentlich (da sie für die sekundären virtuellen Maschinen nur wenige zusätzliche Speicherblöcke herunterladen muss, die noch nicht in der virtuellen Hauptmaschine gespeichert sind, wobei die virtuelle Hauptmaschine später selbst auf diese Speicherblöcke zugreifen kann).
Zu beachten ist, dass die oben beschriebene Lösung mit einer Standard-Zwischenspeichertechnik nichts zu tun hat. Tatsächlich werden die Speicherblöcke bei der Zwischenspeichertechnik auf Anforderung heruntergeladen und zur (möglichen) folgenden Verwendung temporär lokal gespeichert. Die virtuelle Hauptmaschine hingegen lädt die Speicherblöcke herunter und speichert diese permanent zur eigenen Verarbeitung (sodass dies automatisch geschieht, ohne dass die Speicherblöcke durch die sekundären virtuellen Maschinen angefordert werden müssen); mit anderen Worten, die durch die sekundären virtuellen Maschinen angeforderten Speicherblöcke sollten in der virtuellen Hauptmaschine gespeichert sein, da die virtuelle Hauptmaschine bereits selbst auf sie zugegriffen hatte (da die Speicherblöcke, auf die jede sekundäre virtuelle Maschine bereits zugegriffen hatte, darin gespeichert sind, brauchen diese vielmehr überhaupt nicht mehr durch die virtuelle Hauptmaschine angefordert zu werden).
Infolgedessen wird die oben beschriebene Datenstromtechnik verbessert, indem die Arbeitslast des Quellen-Servers und der Netzwerkverkehr stark verringert werden.
Dadurch wird die Datenstromtechnik einfach skalierbar (zum Beispiel, um Cloud-Computing-Infrastrukturen zu unterstützen).
Gemäß 2H können bei einer bestimmten Ausführungsform der Erfindung die Speicherblöcke in der virtuellen Hauptmaschine VMm auch aktualisiert werden, beispielsweise der Speicherblock MBu, der in der Figur heller schraffiert ist. Wenn der (aktualisierte) Speicherblock MBu das erste Mal in der sekundären virtuellen Maschine VMs angefordert wird, kann dieser deshalb nicht von der virtuellen Hauptmaschine VMm abgerufen werden (da der Speicherblock MBu von seiner Originalversion in dem Software-Abbild SI verschieden ist). In diesem Fall wird die Originalversion des Speicherblocks MBu von dem Quellen-Server 105 auf die virtuelle Hauptmaschine VMm heruntergeladen und an die sekundäre virtuelle Maschine VMs zurückgegeben (ohne sie in der virtuellen Hauptmaschine VMm zu speichern).
Alternativ zeigt 21, dass die Originalversionen aller aktualisierten Speicherblöcke in einer speziellen Blockablage BR der virtuellen Hauptmaschine VMm gespeichert werden können. Wenn ein aktualisierter Speicherblock in der sekundären virtuellen Maschine VMs (ebenso wie oben derselbe Speicherblock MBu) das erste Mal angefordert wird, kann in diesem Fall dessen Originalversion nunmehr der Blockablage BR entnommen und direkt an die sekundäre virtuelle Maschine VMs weitergeleitet werden.
Durch die Blockablage wird die Notwendigkeit umgangen, die aktualisierten Speicherblöcke erneut von dem Quellen-Server herunterzuladen (wobei die Arbeitslast des Quellen-Servers und der Netzwerkverkehr entsprechend verringert werden, was jedoch zu Lasen des Speichervolumens in der virtuellen Hauptmaschine geht).
3 zeigt ein Blockschaubild der wichtigsten Softwaremodule, die zum Umsetzen der Lösung gemäß einer Ausführungsform der Erfindung verwendet werden können. Die Daten (Programme und Daten) sind üblicherweise in der Festplatte der verschiedenen Server-Computer gespeichert und werden (zumindest teilweise) in ihre Arbeitsspeicher geladen, wenn die Programme ausgeführt werden. Die Programme werden zu Anfang zum Beispiel von optischen Speicherplatten auf Festplatten installiert.
Insbesondere führt der Quellen-Server 105 ein Implementierungs-Verwaltungsprogramm 305 aus - zum Beispiel IBM Tivoli Provisioning Manager for Images (oder TPMfl) des IBM Tivoli Provisioning Manager for OS Deployment (oder TPM für OSD) von der IBM Corporation (Warenzeichen von IBM Corporation); das Implementierungs-Verwaltungsprogramm 305 dient dazu, die Implementierung von Software-Abbildern auf den Ziel-Servern 110 zu automatisieren (von denen in der Figur nur einer gezeigt ist); die Software-Abbilder sind in einer entsprechenden Ablage 310 gespeichert - jedes einzelne als eine oder mehrere Dateien mit einem vordefinierten Format (das zum Beispiel den VMDK- oder VHD-Vorschriften genügt). Zu diesem Zweck betreibt der Quellen-Server 105 auch einen fernen Zugriffs-Server 315r (der zum Beispiel das iSCSI- (Internet Small Computer System Interface) Protokoll nutzt, das zum Zugreifen auf die in der Ablage 310 gespeicherten Software-Abbilder von außen verwendet wird.
Im Ziel-Server 110 definiert ein Host-Betriebssystem 317 (das direkt auf seiner Hardware ausgeführt wird) eine Software-Plattform, auf der jedes andere Programm ausgeführt werden kann. Insbesondere wird auf dem Host-Betriebssystem 317 ein Implementierungsagent 320 ausgeführt, der mit dem Implementierungs-Verwaltungsprogramm 305 zusammenarbeitet. Auf dem Host-Betriebssystem 317 wird auch eine Virtualisierungsschicht 325 zum Implementieren einer Virtualisierung des Ziel-Servers 110 betrieben; auf dem Markt verfügbare Beispiele der Virtualisierungsschicht 325 sind VMware von VMware Inc. (Warenzeichen von VMware Inc.) und Xen von Citrix Systems, Inc. (Warenzeichen von Citrix Systems, Inc.). Die Virtualisierungsschicht 325 betreibt mehrere virtuelle Maschinen, wozu die virtuelle Hauptmaschine VMm und eine oder mehrere sekundäre virtuelle Maschinen VMs gehören (von denen in der Figur nur eine gezeigt ist), in denen dasselbe Software-Abbild SI implementiert ist.
Jede virtuelle Maschine VMm, VMs (Hauptmaschine und sekundäre Maschine) besteht aus einer abstrakten Struktur, die die Hardware einer physischen Maschine emuliert (welche nur durch die virtuelle Maschine VMm, VMs gesteuert wird). Insbesondere weist diese emulierte Hardware eine virtuelle Festplatte 330m, 330s auf (die eine physische Festplatte emuliert), die zum Speichern der Speicherblöcke des auf der virtuellen Maschine VMm, VMs implementierten Software-Abbildes SI dient (von den Speicherblöcken seines Bootstrap-Moduls bis hin zu den anderen Speicherblöcken, sobald auf diese zugegriffen wird).
In jeder virtuellen Maschine VMm,VMs wird auf ihrer emulierten Hardware ein Gast-Betriebssystem 335m, 335s ausgeführt, um dafür eine Software-Plattform zu definieren, auf der jedes andere Programm ausgeführt werden kann (von den zu Anfang durch das Bootstrap-Modul bereitgestellten Mindestfunktionen bis hin zu den anderen Funktionen, sobald diese verwendet werden). Insbesondere betreibt die virtuelle Hauptmaschine VMm einen weiteren Server 3151 für den Fernzugriff (zum Beispiel auf der Grundlage desselben iSCSI-Protokolls), der zum Zugreifen auf seine virtuelle Festplatte 330m von außen dient (auf der ein Teil des Software-Abbildes SI gespeichert ist). In jedem Fall führt jede virtuelle Maschine VMm, VMs den entsprechenden Datenstromtreiber (der mit den Bezugsnummern 340m, 340s bezeichnet ist) zum Steuern aller Zugriffe (zum Lesen und/oder Schreiben) auf die Speicherblöcke der virtuellen Festplatte 330m, 330s aus. Insbesondere ist der Datenstromtreiber 340m in der virtuellen Hauptmaschine VMm so konfiguriert, dass er mit dem Server 315r für den Fernzugriff zusammenarbeitet (die Speicherblöcke des Software-Abbildes SI von dem Quellen-Server 105 herunterzuladen); der Datenstromtreiber 335s in der sekundären virtuellen Maschine VMs hingegen ist so konfiguriert, dass er mit dem Server 3151 für den Fernzugriff zusammenarbeitet (die Speicherblöcke des Software-Abbildes SI von der virtuellen Hauptmaschine VMm abzurufen). Zu diesem Zweck pflegt der Datenstromtreiber 340m, 340s eine Zuordnungstabelle 345m, 345s; für jeden Speicherblock des Software-Abbildes SI weist die Zuordnungstabelle 345m, 345s eine Zugriffsmarkierung auf, die anzeigt, ob bereits auf den Speicherblock zugegriffen worden ist und dieser dann in der virtuellen Speicherplatte 330m, 330s gespeichert wurde (Zugriffsmarkierung bestätigt) oder nicht (Zugriffsmarkierung unbestätigt).
Zum Verwalten der in der virtuellen Maschine VMm, VMs aktualisierten Speicherblöcke (was im Folgenden ausführlich beschrieben wird) weist die Zuordnungstabelle 345m, 345s für jeden Speicherblock auch eine Aktualisierungsmarkierung auf; die Aktualisierungsmarkierung zeigt an, ob der Speicherblock in der virtuellen Maschine VMm, VMs aktualisiert worden ist und sich dann von seiner Originalversion in dem Software-Abbild SI unterscheidet (Aktualisierungsmarkierung bestätigt) oder nicht (Aktualisierungsmarkierung unbestätigt). Wahlweise kann jede virtuelle Maschine VMm, VMs auch die mit den Bezugszeichen BRm, BRs bezeichnete Blockablage aufweisen; die Blockablage BRm, BRs speichert für jeden aktualisierten Speicherblock dessen Originalversion (wie im Software-Abbild SI) an aufeinander folgenden Speicherplätzen. In diesem Fall weist die Zuordnungstabelle 345m, 345s für jeden aktualisierten Speicherblock auch eine Adresse seiner Originalversion in der Blockablage BRm, BRs auf.
Die 4A bis 4E zeigen ein Funktionsschaubild, das den Ablauf der Arbeitsschritte zum Implementieren der Lösung gemäß einer Ausführungsform der vorliegenden Erfindung darstellt. Insbesondere stellt das Funktionsschaubild einen beispielhaften Prozess dar, der zum Implementieren eines bestimmten Software-Abbildes auf einer Vielzahl virtueller Zielmaschinen mittels des Verfahrens 400 umgesetzt werden kann.
Das Verfahren 400 beginnt am schwarzen Startpunkt 401 in der Spalte Quellen-Server und wird in Block 402 fortgesetzt, wo ein Systemadministrator dieses Software-Abbild und einen Ziel-Server auswählt, auf dem das Software-Abbild durch das Implementierungs-Verwaltungsprogramm implementiert werden soll (zum Beispiel über eine seiner Webschnittstellen). Als Reaktion darauf weist das Implementierungs-Verwaltungsprogramm in Block 403 den Implementierungsagenten des Ziel-Servers an, eine entsprechende virtuelle Zielmaschine (mit einer virtuellen Speicherplatte zum Speichern des Software-Abbildes) zu erzeugen; gleichzeitig werden durch das Implementierungs-Verwaltungsprogramm entsprechende Daten gespeichert (zum Beispiel in einer Implementierungstabelle, in die ein Datensatz eingetragen wird, der diese virtuelle Zielmaschine auf dem Ziel-Server und das zu implementierende Software-Abbild kennzeichnet). Dann verzweigt der Ablauf der Arbeitsschritte in Block 404 entsprechend der Anzahl der Instanzen des Software-Abbildes, die bereits auf dem Ziel-Server implementiert sind (was aus der Implementierungstabelle hervorgeht); insbesondere werden die Blöcke 405 bis 422 ausgeführt, wenn es sich hierbei im Augenblick um die erste Implementierung des Software-Abbildes auf dem Ziel-Server handelt (d.h., wenn in der Konfigurationstabelle für dasselbe Software-Abbild auf dem Ziel-Server noch kein anderer Datensatz enthalten ist), während die Blöcke 423 bis 448 ausgeführt werden, wenn es sich hierbei im Augenblick um eine nächste Implementierung des Software-Abbildes auf dem Ziel-Server handelt (d.h., wenn in der Konfigurationstabelle für dasselbe Software-Abbild auf dem Ziel-Server bereits mindestens ein weiterer Datensatz enthalten ist).
Nunmehr wird in Block 405 (erste Implementierung des Software-Abbildes) die virtuelle Zielmaschine als virtuelle Hauptmaschine für das Implementieren des Software-Abbildes festgelegt (zum Beispiel durch Bestätigen einer entsprechenden Markierung seines Datensatzes in der Zuordnungstabelle). Der Implementierungsmanager lädt dann in Block 406 das Bootstrap-Modul auf den Ziel-Server hoch und weist den Implementierungsagenten an, dessen Speicherblöcke in der virtuellen Speicherplatte der virtuellen Hauptmaschine zu speichern (an Speicherorten, an denen sie während ihres Bootens vermutet werden). An dieser Stelle weist der Implementierungsmanager in Block 407 den Implementierungsagenten an, die virtuelle Hauptmaschine einzuschalten.
In der Spalte der virtuellen Hauptmaschine wird diese in Block 408 von dem Bootstrap-Modul gebootet und dadurch der entsprechende Teil des Gast-Betriebssystems und der Datenstromtreiber mit seiner Zuordnungstabelle geladen; bei Microsoft Windows (Warenzeichen von Microsoft Corp.) weist zum Beispiel das Bootstrap-Modul Bt einen Master-Boot-Datensatz (MBR), einen Bootsektor, eine Datei bootmgr.exe, eine Datei boot\bcd, eine Systemregistrierung, eine Datei winload.exe und Treiber auf, die in einer Systemregistrierung aufgeführt sind (darunter ein Treiber für den Fernzugriff, um mit entsprechenden Servern für den Fernzugriff und dem Datenstromtreiber zusammenzuarbeiten); die Zuordnungstabelle des Datenstromtreibers wird initialisiert, wobei die Zugriffsmarkierungen der Speicherblöcke des Bootstrap-Moduls bestätigt und die Zugriffsmarkierungen der anderen Speicherblöcke unbestätigt und die aktualisierten Markierungen aller Speicherblöcke unbestätigt sind. Der Datenstromtreiber überschreibt einen Dateisystem-Standardtreiber des Gast-Betriebssystems (welches das gesamte Software-Abbild erkennt, da dieses in der virtuellen Speicherplatte gespeichert wurde), um jede Anforderung für das Zugreifen auf einen ausgewählten Speicherblock desselben zu erfüllen. Insbesondere ist das Bootstrap-Modul standardmäßig so konfiguriert, dass der Datenstromtreiber mit dem Server für den Fernzugriff des Quellen-Servers zusammenarbeiten soll. Darüber hinaus ist das Bootstrap-Modul standardmäßig auch so konfiguriert, dass es in Block 409 seinen Server für den Fernzugriff startet (dies ist in dem Software-Abbild enthalten).
Sobald in Block 410 eine Zugriffsanforderung für das Zugreifen auf einen ausgewählten Speicherblock an den Dateisystemtreiber übermittelt wird (um zu Anfang den Treiber für den Fernzugriff zu laden und anschließend die virtuelle Hauptmaschine zu betreiben), wird die Anforderung an den Datenstromtreiber übermittelt. Der Prozess verzweigt dann in Block 411 entsprechend einem Modus der Zugriffsanforderung; insbesondere werden die Blöcke 412 bis 418 ausgeführt, wenn die Zugriffsanforderung ein Lesen des ausgewählten Speicherblocks beinhaltet, während die Blöcke 419 bis 422 ausgeführt werden, wenn die Zugriffsanforderung ein Schreiben des ausgewählten Speicherblocks beinhaltet.
In Block 412 (Lese-Zugriffsanforderung) wird ein Test durchgeführt, um zu prüfen, ob (allgemein) zum ersten Mal auf den ausgewählten Speicherblock in der virtuellen Hauptmaschine zugegriffen wird (was aus der Zuordnungstabelle hervorgeht). Wenn dies der Fall ist (d.h., wenn die Zugriffsmarkierung des ausgewählten Speicherblocks unbestätigt ist), leitet der Datenstromtreiber die Zugriffsanforderung an den Treiber für den Fernzugriff weiter; der Treiber für den Fernzugriff wiederum (der in dem vorliegenden Beispiel als iSCSI-Initiator fungiert) übermittelt in Block 413 eine entsprechende Anforderung zum Herunterladen an den Server für den Fernzugriff des Quellen-Servers. In Block 414 lädt der Server für den Fernzugriff des Quellen-Servers den ausgewählten Speicherblock auf die virtuelle Hauptmaschine herunter. In Block 415 speichert der Datenstromtreiber den (von dem Treiber für den Fernzugriff empfangenen) ausgewählten Speicherblock in der virtuellen Speicherplatte. In Block 416 aktualisiert der Datenstromtreiber dann die Zuordnungstabelle durch Bestätigen der entsprechenden Zugriffsmarkierung. Wenn dies nicht der Fall ist (d.h., wenn in Block 412 die Zugriffsmarkierung des ausgewählten Speicherblocks bestätigt ist), liest der Datenstromtreiber den ausgewählten Speicherblock in Block 417 direkt von der virtuellen Speicherplatte. In beiden Fällen fährt das Verfahren 400 mit Block 418 fort (entweder von Block 416 oder von Block 417), wobei der Datenstromtreiber den ausgewählten Speicherblock an den Dateisystemtreiber und dieser wiederum an den Anfordernden zurückgibt.
In Block 419 (Schreib-Zugriffsanforderung) verzweigt der Prozess gemäß der Implementierung des Datenstromtreibers. Insbesondere wenn der Datenstromtreiber die Blockablage unterstützt und der ausgewählte Speicherblock noch nicht aktualisiert worden ist (d.h., wenn seine aktualisierte Markierung unbestätigt ist), geht das Verfahren weiter zu Block 420. In dieser Phase wird das Originalexemplar des ausgewählten Speicherblocks von der virtuellen Speicherplatte auf einen ersten freien Speicherplatz der Blockablage kopiert; gleichzeitig wird eine Adresse dieses Speicherplatzes der Blockablage dem ausgewählten Speicherblock in der Zuordnungstabelle zugeordnet. Dann fährt das Verfahren 400 mit Block 421 fort; dieselbe Stelle wird auch direkt von Block 419 erreicht, wenn der Datenstromtreiber die Blockablage nicht unterstützt oder der ausgewählte Speicherblock bereits aktualisiert worden ist. In jedem Fall schreibt der Datenstromtreiber den gewünschten Wert des ausgewählten Speicherblocks in die virtuelle Speicherplatte (entweder durch erstmaliges Speichern oder durch Ändern seiner vorhergehenden Version). Dann aktualisiert der Datenstromtreiber in Block 422 die Zuordnungstabelle durch Bestätigen der entsprechenden Zugriffsmarkierung und (falls erforderlich) der entsprechenden Aktualisierungsmarkierung.
In beiden Fällen geht der Prozess zurück zu Block 410 (von Block 418 oder von Block 422), um auf eine Anforderung zum Zugreifen auf einen nächsten ausgewählten Speicherblock zu warten.
In Block 423 wiederum (nächste Implementierung des Software-Abbildes) wird die virtuelle Zielmaschine als sekundäre virtuelle Maschine für das Implementieren des Software-Abbildes festgelegt (zum Beispiel, indem die entsprechende Markierung ihres Datensatzes in der Zuordnungstabelle unbestätigt bleibt). Dann verzweigt der Prozess in Block 424 gemäß der Implementierung des Datenstromtreibers. Insbesondere wenn der Datenstromtreiber die Blockablage nicht unterstützt, lädt der Implementierungsmanager in Block 425 wie oben das Bootstrap-Modul auf den Ziel-Server hinauf. Wenn dies nicht der Fall ist (wenn der Datenstromtreiber die Blockablage unterstützt), weist der Implementierungsmanager in Block 426 den Implementierungsagenten an, die Originalversion des Bootstrap-Moduls aus der virtuellen Hauptmaschine wiederherzustellen; zu diesem Zweck wird jeder Speicherblock des Bootstrap-Moduls von seiner virtuellen Speicherplatte gelesen (wenn die entsprechende aktualisierte Markierung unbestätigt ist) oder seiner Blockablage entnommen.
In beiden Fällen wird das Verfahren 400 mit Block 427 fortgesetzt (von Block 425 oder von Block 426); an dieser Stelle weist der Implementierungsmanager den Implementierungsagenten an, das (heruntergeladene oder wiederhergestellte) Bootstrap-Modul zu konfigurieren, um den Datenstromtreiber zur Zusammenarbeit mit dem Server für den Fernzugriff der virtuellen Hauptmaschine zu veranlassen (für dasselbe Software-Abbild auf demselben Ziel-Server, wie in der Zuordnungstabelle angegeben), anstatt den eigenen Server für den Fernzugriff zu starten. Dann weist der Implementierungsmanager den Implementierungsagenten an, die Speicherblöcke des (aktualisierten) Bootstrap-Moduls in der virtuellen Speicherplatte der sekundären virtuellen Maschine zu speichern. In Block 428 weist der Implementierungsmanager den Implementierungsagenten an, die sekundäre virtuelle Maschine einzuschalten.
In Block 429 in der Spalte Sekundäre virtuelle Maschine wird diese normalerweise von dem Bootstrap-Modul gebootet, wodurch der entsprechende Teil des Gast-Betriebssystems und der Datenstromtreiber mit seiner (wie oben initialisierten) Zuordnungstabelle geladen wird, der wiederum den Dateisystem-Standardtreiber des Gast-Betriebssystems überschreibt, um jede Anforderung für das Zugreifen auf einen (weiteren) ausgewählten Speicherblock der virtuellen Ziel-Speicherplatte zu erfüllen.
Sobald eine Zugriffsanforderung für das Zugreifen auf einen ausgewählten Speicherblock an den Dateisystemtreiber (zum Betreiben der sekundären virtuellen Maschine) übermittelt ist, wird die Anforderung wie oben in Block 430 an den Datenstromtreiber weitergeleitet. Dann verzweigt der Prozess in Block 431 entsprechend einem Modus der Zugriffsanforderung; insbesondere werden die Blöcke 432 bis 444 ausgeführt, wenn die Zugriffsanforderung ein Lesen des ausgewählten Speicherblocks betrifft, während die Blöcke 445 bis 448 ausgeführt werden, wenn die Zugriffsanforderung ein Schreiben des ausgewählten Speicherblocks betrifft.
In Block 432 (Lese-Zugriffsanforderung) wird ein Test durchgeführt, um zu prüfen, ob in der sekundären virtuellen Maschine (allgemein) das erste Mal (was aus der Zuordnungstabelle hervorgeht) auf den ausgewählten Speicherblock zugegriffen wird. Wenn dies der Fall ist (d.h., wenn die Zugriffsmarkierung des ausgewählten Speicherblocks unbestätigt ist), leitet der Datenstromtreiber die Zugriffsanforderung an den Treiber für den Fernzugriff weiter; der Treiber für den Fernzugriff (der wiederum als iSCSI-Initiator fungiert) übermittelt daraufhin in Block 433 eine entsprechende Abrufanforderung an den Server für den Fernzugriff der virtuellen Hauptmaschine.
In der Spalte Virtuelle Hauptmaschine führt der Datenstromtreiber (der die Abrufanforderung von dem Server für den Fernzugriff empfängt) in Block 434 einen Test durch, um zu prüfen, ob der ausgewählte Speicherblock in der virtuellen Hauptmaschine aktualisiert worden ist (was aus der Zuordnungstabelle hervorgeht). Wenn dies der Fall ist (d.h., wenn die Aktualisierungsmarkierung des ausgewählten Speicherblocks bestätigt ist, um anzuzeigen, dass der ausgewählte Speicherblock vor dem Herunterladen geschrieben oder danach geändert worden ist), verzweigt der Prozess in Block 435 gemäß der Implementierung des Datenstromtreibers. Insbesondere wenn der Datenstromtreiber die Blockablage nicht unterstützt, geht das Verfahren 400 weiter zu Block 436; in dieser Phase leitet der Datenstromtreiber die Zugriffsanforderung an den Treiber für den Fernzugriff weiter, der seinerseits eine entsprechende Anforderung für das Herunterladen an den Server für den Fernzugriff des Quellen-Servers übermittelt. Daraufhin lädt der Server für den Fernzugriff des Quellen-Servers in Block 437 den ausgewählten Speicherblock auf die virtuelle Hauptmaschine herunter. Wenn der Haupt-Datenstromtreiber hingegen in Block 435 die Blockablage unterstützt, entnimmt dieser in Block 438 die Originalversion des ausgewählten Speicherblocks direkt von dem in der Zuordnungstabelle angegebenen Speicherplatz der Blockablage. Wenn hingegen in Block 434 der ausgewählte Speicherblock in der virtuellen Hauptmaschine nicht aktualisiert worden ist (d.h., wenn seine Aktualisierungsmarkierung unbestätigt ist), geht das Verfahren 400 weiter zu Block 439; in dieser Phase wird der ausgewählte Speicherblock auf der virtuellen Hauptmaschine gelesen, indem dieselbe oben beschriebene Operation wiederholt wird (d.h., Herunterladen des ausgewählten Speicherblocks von dem Quellen-Server und Speichern desselben in der virtuellen Speicherplatte, wenn das erste Mal auf ihn zugegriffen wird, oder, wenn dies nicht der Fall ist, Lesen des ausgewählten Speicherblocks von der virtuellen Speicherplatte). In jedem Fall wird das Verfahren 400 (ausgehend von Block 437, Block 438 oder Block 439) in Block 440 zusammengeführt, wo der Datenstromtreiber den ausgewählten Speicherblock an den Server für den Fernzugriff weiterleitet, der diesen wiederum an den Treiber für den Fernzugriff der sekundären virtuellen Maschine übergibt. In der Spalte Sekundäre virtuelle Maschine speichert der Datenstromtreiber in Block 441 den (von dem Treiber für den Fernzugriff empfangenen) ausgewählten Speicherblock in der virtuellen Speicherplatte. Dann aktualisiert der Datenstromtreiber in Block 442 die Zuordnungstabelle durch Bestätigen der entsprechenden Zugriffsmarkierung.
Wenn in Block 432 bereits auf den ausgewählten Speicherblock in der sekundären virtuellen Maschine zugegriffen worden ist (d.h., wenn seine Zugriffsmarkierung bestätigt ist) liest der Datenstromtreiber den ausgewählten Speicherblock in Block 443 direkt von der virtuellen Ziel-Speicherplatte.
In beiden Fällen geht das Verfahren 400 weiter zu Block 444 (entweder von Block 442 oder von Block 443), wo der Datenstromtreiber den ausgewählten Speicherblock an den Dateisystemtreiber zurückgibt, der ihn seinerseits an den Anfordernden zurückgibt.
In Bezug auf Block 445 (Schreib-Zugriffsanforderung) werden in den Blöcken 445 bis 448 genau dieselben Operationen ausgeführt wie oben unter Bezugnahme auf die Blöcke 419 bis 422 beschrieben (sodass deren Erläuterung nicht wiederholt wird).
In beiden Fällen kehrt der Prozess (von Block 444 oder von Block 448) zurück zu Block 430 und wartet auf eine Anforderung für das Zugreifen auf einen nächsten ausgewählten Speicherblock.
In der Spalte Quellen-Server wählt der Systemadministrator in Block 449 völlig asynchron eine der virtuellen Zielmaschinen (die im Folgenden als alte virtuelle Maschine bezeichnet wird), in der vorher ein entsprechendes Software-Abbild zumindest teilweise (wie in der Implementierungstabelle angezeigt) implementiert worden ist, um durch den Implementierungsmanager entfernt zu werden. Als Reaktion darauf wird in Block 450 ein Test durchgeführt, um den Typ der alten virtuellen Maschine (der in der Implementierungstabelle angezeigt ist) zu prüfen. Insbesondere wenn es sich bei der alten virtuellen Maschine um die virtuelle Hauptmaschine auf dem entsprechenden Ziel-Server für deren Software-Abbild handelt, geht das Verfahren 400 weiter zu Block 451; in dieser Phase wird ein weiterer Test durchgeführt, um die Anzahl der sekundären virtuellen Maschinen für dieses Software-Abbild (wie in der Implementierungstabelle angegeben) auf demselben Ziel-Server zu prüfen. Wenn auf dem Ziel-Server eine oder mehrere sekundäre virtuelle Maschinen verfügbar sind, wird in Block 452 eine davon ausgewählt (um anstelle der alten virtuellen Maschine zur neuen virtuellen Hauptmaschine zu werden); genauer gesagt, die ausgewählte sekundäre virtuelle Zielmaschine ist die Zielmaschine des Ziel-Servers, auf der das Software-Abbild (zumindest teilweise) implementiert worden ist. Auf diese Weise weist die ausgewählte sekundäre virtuelle Maschine höchstwahrscheinlich die größte Anzahl in ihrer virtuellen Speicherplatte bereits gespeicherter Speicherblöcke auf. In Block 453 wird die ausgewählte sekundäre virtuelle Maschine nunmehr als neue virtuelle Hauptmaschine für das Software-Abbild auf dem Ziel-Server festgelegt (durch Bestätigen der entsprechenden Markierung ihres Datensatzes in der Zuordnungstabelle). Dann weist der Implementierungsmanager den Implementierungsagenten an, das Bootstrap-Modul in der neuen virtuellen Hauptmaschine so zu konfigurieren, dass der Datenstromtreiber mit dem Server für den Fernzugriff des Quellen-Servers zusammenarbeitet und in Block 455 sein Server für den Fernzugriff gestartet wird. Dann weist der Implementierungsmanager in Block 455 den Implementierungsagenten an, den Server für den Fernzugriff der neuen virtuellen Hauptmaschine zu starten. Darüber hinaus weist der Implementierungsmanager in Block 456 den Implementierungsagenten an, gegebenenfalls das Bootstrap-Modul der anderen sekundären virtuellen Maschinen zu konfigurieren (die in der Implementierungstabelle angezeigt sind), damit ihr Datenstromtreiber mit dem Server für den Fernzugriff der neuen virtuellen Hauptmaschine zusammenarbeitet.
Dann fährt das Verfahren 400 mit Block 457 in der Spalte Quellen-Server fort; dieselbe Stelle wird auch direkt von Block 450 (wenn es sich bei der alten virtuellen Maschine nicht um die virtuelle Hauptmaschine auf dem Ziel-Server für das Software-Abbild handelt) oder von Block 451 erreicht (wenn es sich bei der alten virtuellen Maschine um die virtuelle Hauptmaschine auf dem Ziel-Server für das Software-Abbild handelt, aber auf dem Ziel-Server für dasselbe Software-Abbild keine sekundäre virtuelle Maschine verfügbar ist). In allen Fällen weist der Implementierungsmanager den Implementierungsagenten an, die alte virtuelle Maschine abzuschalten und von dem Ziel-Server zu entfernen; gleichzeitig wird der entsprechende Datensatz aus der Implementierungstabelle gelöscht.
Dann ist das Verfahren 400 an den schwarz-weißen konzentrischen Stopp-Kreisen 458 abgeschlossen.
Zum Beispiel stellt eine Ausführungsform der Erfindung ein Verfahren zum Implementieren eines Software-Abbildes (eines beliebigen Typs - das zum Beispiel nur das Betriebssystem ohne jegliche Anwendungsprogramme aufweist) von einem Quellen-Datenverarbeitungssystem (eines beliebigen Typs - siehe unten) auf einer Vielzahl von Ziel-Datenverarbeitungseinheiten (in beliebiger Anzahl und eines beliebigen Typs, siehe unten) eines Ziel-Datenverarbeitungssystems (eines beliebigen Typs, siehe unten) bereit. Das Software-Abbild weist eine Vielzahl von Speicherblöcken (in beliebiger Anzahl und von beliebiger Größe) auf, auf die einzeln zugegriffen werden kann; eine vordefinierte Teilmenge von Speicherblöcken (in beliebiger Anzahl und an beliebigen Speicherplätzen) definiert ein Bootstrap-Modul (für ein beliebiges Betriebssystem und von beliebigem Typ - das zum Beispiel das MBR mit dem GRUB-Boot-Ladeprogramm, das /Boot-Verzeichnis mit dem Kern und das Dateisystem initrd in Linux (Warenzeichen von Linus Torvalds) aufweist). Das Verfahren weist die folgenden Schritte auf. Das Bootstrap-Modul wird (auf eine beliebige Weise) von dem Quellen-Datenverarbeitungssystem auf eine Haupteinheit der Ziel-Datenverarbeitungseinheiten heruntergeladen. Die Haupt-Ziel-Datenverarbeitungseinheit wird von dem Bootstrap-Modul gebootet, wodurch ein in dem Bootstrap-Modul enthaltener Datenstromtreiber geladen wird. Jede Anforderung für das Zugreifen auf einen ausgewählten Speicherblock des Software-Abbildes auf der Haupt-Datenverarbeitungseinheit wird durch den Datenstromtreiber erfüllt; der Datenstromtreiber lädt den ausgewählten Speicherblock von dem Quellen-Datenverarbeitungssystem herunter und speichert den ausgewählten Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit als Reaktion auf eine erste Anforderung für das Zugreifen auf den ausgewählten Speicherblock; wenn dies nicht der Fall ist, greift der Datenstromtreiber stattdessen auf den ausgewählten Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit zu. Das Bootstrap-Modul wird auch jeder einzelnen einer Gruppe von (einer oder mehreren) sekundären Ziel-Datenverarbeitungseinheiten (auf beliebige Weise - zum Beispiel durch Herunterladen von dem Quellen-Datenverarbeitungssystem, Kopieren von einer anderen Ziel-Datenverarbeitungseinheit oder lokales Wiederherstellen derselben) bereitgestellt. Jede sekundäre Ziel-Datenverarbeitungseinheit wird von dem Bootstrap-Modul gebootet, wodurch der Datenstromtreiber geladen wird. Jede Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock des Software-Abbildes auf der sekundären Datenverarbeitungseinheit wird durch den Datenstromtreiber erfüllt. Der Datenstromtreiber ruft den weiteren ausgewählten Speicherblock von der Haupt-Ziel-Datenverarbeitungseinheit ab und speichert den weiteren ausgewählten Speicherblock in der sekundären Ziel-Datenverarbeitungseinheit als Reaktion auf eine erste der Anforderungen für das Zugreifen auf den weiteren ausgewählten Speicherblock; wenn dies nicht der Fall ist, greift der Datenstromtreiber stattdessen auf den weiteren ausgewählten Speicherblock in der sekundären Ziel-Datenverarbeitungseinheit zu.
Dieselbe Lösung kann jedoch mit einem gleichwertigen Verfahren implementiert werden (durch Verwenden ähnlicher Schritte mit den gleichen Funktionen oder mehrerer Schritte oder Teile davon, durch Entfernen bestimmter unwesentlicher Schritte oder Hinzufügen beliebiger weiterer Schritte); darüber hinaus können die Schritte in einer anderen Reihenfolge, gleichzeitig oder (zumindest teilweise) ineinander verschachtelt ausgeführt werden. Zum Beispiel können die Speicherblöcke von dem Quellen-Datenverarbeitungssystem auf die Haupt-Ziel-Datenverarbeitungseinheit heruntergeladen werden und/oder die Speicherblöcke können durch die sekundären Ziel-Datenverarbeitungseinheiten im Hintergrund von der Haupt-Ziel-Datenverarbeitungseinheit abgerufen werden (zum Beispiel bei einer entsprechend niedrigen Arbeitslast); darüber hinaus kann der Datenstromtreiber auch deaktiviert werden, wenn in der entsprechenden Ziel-Datenverarbeitungseinheit bereits alle Speicherblöcke des Software-Abbildes gespeichert worden sind.
Gemäß einer Ausführungsform der Erfindung handelt es sich bei den Ziel-Datenverarbeitungseinheiten um virtuelle Zielmaschinen, die auf dem Ziel-Datenverarbeitungssystem beherbergt werden.
Die virtuellen Maschinen können auf jede andere Weise implementiert werden (zum Beispiel durch einen Hypervisor gesteuert, der direkt auf der Hardware des Ziel-Servers ausgeführt wird; auf keinen Fall ist die Anwendung desselben Verfahrens auf physischen Maschinen (zum Beispiel auf Computern ein und desselben Rechenzentrums, das von dem Quellen-Server entfernt ist) ausgeschlossen.
Gemäß einer Ausführungsform der Erfindung weist der Schritt des Bootens der Haupt-Ziel-Datenverarbeitungseinheit ein Starten eines Zugriffs-Servers auf, der in dem Software-Abbild auf der Haupt-Datenverarbeitungseinheit enthalten ist. Der Schritt des Erfüllens jeder Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock weist auf: Senden einer Anforderung für ein Abrufen des weiteren ausgewählten Speicherblocks durch den Datenstromtreiber der sekundären Datenverarbeitungseinheit an den Zugriffs-Server der Haupt-Datenverarbeitungseinheit als Reaktion auf die erste Anforderung für das Zugreifen auf den weiteren ausgewählten Speicherblock, und Zurückgeben des weiteren ausgewählten Speicherblocks von dem Zugriffs-Server der Haupt-Datenverarbeitungseinheit an den Datenstromtreiber der sekundären Datenverarbeitungseinheit.
Der Zugriffs-Server kann jedoch von einem beliebigen anderen Typ sein (zum Beispiel auf der Grundlage des AoE-Protokolls; in jedem Fall können die Speicherblöcke auf beliebige Weise durch die sekundären Datenverarbeitungseinheiten von der Haupt-Ziel-Datenverarbeitungseinheit abgerufen werden, (zum Beispiel mittels eines speziellen Dienstes).
Gemäß einer Ausführungsform der Erfindung weist der Schritt des Herunterladens eines Bootstrap-Moduls auf eine Haupteinheit der Ziel-Datenverarbeitungseinheiten ein Konfigurieren des Datenstromtreibers zum Herunterladen jedes ausgewählten Speicherblocks von dem Quellen-Datenverarbeitungssystem als Reaktion auf die erste Anforderung für das Zugreifen auf den ausgewählten Speicherblock auf; der Schritt des Bereitstellens des Bootstrap-Moduls für jede einzelne Einheit einer Gruppe von sekundären Ziel-Datenverarbeitungseinheiten weist ein Konfigurieren des Datenstromtreibers zum Abrufen jedes weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit als Reaktion auf die erste Anforderung für das Zugreifen auf den weiteren ausgewählten Speicherblock auf.
Das Bootstrap-Modul kann jedoch auf eine beliebige Weise konfiguriert werden (zum Beispiel mit entgegengesetztem oder ohne Standardverhalten); in jedem Fall ist die Möglichkeit, dass zwei verschiedene Bootstrap-Moduls verwendet werden (für die Haupt-Ziel-Datenverarbeitungseinheit und die sekundären Datenverarbeitungseinheiten) nicht ausgeschlossen.
Gemäß einer Ausführungsform der Erfindung weist das Verfahren ferner die folgenden Schritte auf. Eine erste der Ziel-Datenverarbeitungseinheiten wird für eine erste Implementierung des Software-Abbildes auf dem Ziel-Datenverarbeitungssystem bereitgestellt. Die erste Ziel-Datenverarbeitungseinheit wird als Haupt-Ziel-Datenverarbeitungseinheit festgelegt. Eine Gruppe von (einer oder mehreren) nächsten Ziel-Datenverarbeitungseinheiten wird für eine nächste Implementierung des Software-Abbildes auf dem Ziel-Datenverarbeitungssystem bereitgestellt. Jede nächste Ziel-Datenverarbeitungseinheit wird als sekundäre Ziel-Datenverarbeitungseinheit festgelegt.
Die Haupt- und die sekundären Ziel-Datenverarbeitungseinheiten können jedoch auch auf andere Weise festgelegt werden (zum Beispiel dynamisch gemäß der entsprechenden Anzahl darin gespeicherter Speicherblöcke).
Gemäß einer Ausführungsform der Erfindung weist das Verfahren die folgenden Schritte auf. Eine Anforderung zum Entfernen der Haupt-Ziel-Datenverarbeitungseinheit von dem Ziel-Datenverarbeitungssystem wird empfangen. Eine der sekundären Ziel-Datenverarbeitungseinheiten wird ausgewählt. Die ausgewählte sekundäre Datenverarbeitungseinheit wird als neue Haupt-Ziel-Datenverarbeitungseinheit festgelegt. Die Haupt-Ziel-Datenverarbeitungseinheit wird von dem Ziel-Datenverarbeitungssystem entfernt.
Es ist jedoch auch eine Standardimplementierung denkbar, bei der die Haupt-Ziel-Datenverarbeitungseinheit nicht dynamisch geändert werden kann.
Gemäß einer Ausführungsform der Erfindung weist der Schritt des Auswählens einer der sekundären Ziel-Datenverarbeitungseinheiten ein Auswählen der ältesten der sekundären Ziel-Datenverarbeitungseinheiten auf.
Die Auswahl der sekundären Ziel-Datenverarbeitungseinheiten kann jedoch auch auf beliebigen anderen zusätzlichen oder alternativen Kriterien beruhen (zum Beispiel auf der Anzahl der darin gespeicherten Speicherblöcke).
Gemäß einer Ausführungsform der Erfindung weist der Schritt des Erfüllens einer Anforderung für das Zugreifen auf einen ausgewählten Speicherblock ein Speichern einer Anzeige jedes ausgewählten Speicherblocks in der Haupt-Ziel-Datenverarbeitungseinheit, der aktualisiert worden ist; der Schritt des Abrufens des weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit weist auf: Prüfen, ob der weitere ausgewählte Speicherblock in der virtuellen Hauptmaschine aktualisiert worden ist, und Herunterladen des weiteren ausgewählten Speicherblocks von dem Quellen-Stromversorgungssystem auf die Haupt-Datenverarbeitungseinheit, wenn der weitere ausgewählte Speicherblock in der virtuellen Hauptmaschine aktualisiert worden ist, oder, wenn dies nicht der Fall ist, Lesen des weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit.
Die Informationen über die aktualisierten Speicherblöcke können jedoch auf eine beliebige andere Weise bereitgestellt werden (zum Beispiel in Form einer separaten Liste der aktualisierten Speicherblöcke); in jedem Fall ist eine Standardimplementierung, in der das Software-Abbild in den Ziel-Datenverarbeitungseinheiten nicht aktualisiert werden kann, nicht ausgeschlossen.
Gemäß einer Ausführungsform der Erfindung weist der Schritt des Erfüllens jeder Anforderung für ein Zugreifen auf einen weiteren ausgewählten Speicherblock eine Anzeige jedes weiteren ausgewählten Speicherblocks auf, der in der sekundären Ziel-Datenverarbeitungseinheit aktualisiert worden ist.
Diese Informationen können jedoch nur in der Haupt-Ziel-Datenverarbeitungseinheit gesammelt werden (zum Beispiel, wenn sie nicht dynamisch geändert werden kann).
Gemäß einer Ausführungsform der Erfindung weist des Schritt des Erfüllens jeder Anforderung für das Zugreifen auf einen ausgewählten Speicherblock ein Speichern einer Originalversion jedes ausgewählten Speicherblocks auf, der in der Haupt-Ziel-Datenverarbeitungseinheit aktualisiert worden ist. Der Schritt des Abrufens des weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit weist auf: Prüfen, ob der weitere ausgewählte Speicherblock in der virtuellen Hauptmaschine aktualisiert worden ist, und Zurückgeben des weiteren ausgewählten Speicherblocks, wenn der weitere ausgewählte Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit nicht aktualisiert worden ist, oder, wenn dies nicht der Fall ist, dessen Originalversion.
Die Blockablage kann jedoch eine beliebige Struktur aufweisen (zum Beispiel zum Speichern einer Kopie des bereits heruntergeladenen Gesamtumfangs des Software-Abbildes) und auch zum Erzeugen einer neuen sekundären Ziel-Datenverarbeitungseinheit verwendet werden.
Gemäß einer Ausführungsform der Erfindung weist der Schritt des Erfüllens jeder Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock ein Speichern einer Originalversion jedes weiteren ausgewählten Speicherblocks auf, der in der sekundären Ziel-Datenverarbeitungseinheit aktualisiert worden ist.
Diese Operation kann jedoch nur in der Haupt-Ziel-Datenverarbeitungseinheit ausgeführt werden (zum Beispiel, wenn diese nicht dynamisch geändert werden kann).
Gemäß einer Ausführungsform der Erfindung wird ein Computerprogramm bereitgestellt, das ein Codemittel aufweist, um ein Datenverarbeitungssystem (zum Beispiel jeden der Ziel-Server, den Quellen-Server und/oder die gesamte Implementierungs-Infrastruktur) zum Ausführen der Schritte des vorgeschlagenen Verfahrens zu veranlassen, wenn das Computersystem auf dem System ausgeführt wird.
Das Programm kann jedoch aus jedem der Software-Abbilder bestehen oder als eigenständiges Modul, oder als Plug-in für den Implementierungsmanager oder sogar direkt in dem Implementierungsmanager selbst implementiert sein. In jedem Fall gelten ähnliche Überlegungen auch, wenn das Programm auf andere Weise strukturiert ist oder wenn weitere Module oder Funktionen bereitgestellt werden; desgleichen können die Speicherstrukturen eines anderen Typs sein oder durch gleichwertige Einheiten ersetzt werden (die nicht unbedingt aus physischen Speichermedien bestehen müssen). Das Programm kann eine beliebige Form annehmen, die für die Verwendung durch ein beliebiges Datenverarbeitungssystem oder in Verbindung mit diesem geeignet ist (zum Beispiel innerhalb einer virtuellen Maschine) und dadurch das Datenverarbeitungssystem zum Ausführen der gewünschten Operationen konfiguriert; insbesondere kann das Programm die Form von externer oder residenter Software, Firmware oder Mikrocode (sowohl als Objektcode oder Quellcode - der zum Beispiel kompiliert oder interpretiert werden muss) aufweisen. Darüber hinaus kann das Programm auf einem beliebigen durch Computer nutzbaren Medium (und insbesondere als Fertigungsprodukt auf einem nichtflüchtigen Medium) bereitgestellt werden; bei dem Medium kann es sich um ein beliebiges Element handeln, das geeignet ist, das Programm zu enthalten, zu speichern, zu übertragen, zu übermitteln oder weiterzuleiten. Bei dem Medium kann es sich zum Beispiel um ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitermedium handeln; als Beispiele für ein solches Medium kommen Festplatten (auf die das Programm zuvor geladen werden kann), austauschbare Speicherplatten, Magnetbänder, Speicherkarten, Kabel, Lichtwellenleiter, drahtlose Verbindungen, Netzwerke, Funkwellen und dergleichen infrage. In jedem Fall ist die Lösung gemäß einer Ausführungsform der vorliegenden Erfindung geeignet, auch in Verbindung mit einer Hardwarestruktur (zum Beispiel in einen Halbleiter-Chip integriert) oder einer Kombination von Software und Hardware implementiert zu werden, die in geeigneter Weise programmiert oder anderweitig konfiguriert sind.
Gemäß einer Ausführungsform der Erfindung wird ein Datenverarbeitungssystem bereitgestellt, das Mittel zum Ausführen der Schritte dieses Verfahrens aufweist (zum Beispiel jeder der Ziel-Server, der Quellen-Server oder die gesamte Implementierungs-Infrastruktur).
Ähnliche Überlegungen gelten jedoch auch, wenn das Datenverarbeitungssystem eine andere Struktur, gleichwertige Komponenten oder andere Funktionseigenschaften aufweist. In jedem Fall kann jede Komponente desselben in mehrere Elemente aufgeteilt werden, oder zwei oder mehr Komponenten können zu einem einzigen Element zusammengefasst werden; darüber hinaus kann jede Komponente vervielfacht werden, um die parallele Ausführung der entsprechenden Operationen zu unterstützen. Ferner wird darauf hingewiesen, dass jedes Zusammenwirken zwischen verschiedenen Komponenten im Allgemeinen nicht ununterbrochen erfolgen muss und entweder direkt oder indirekt über einen oder mehrere Vermittler erfolgen kann. Genauer gesagt, dasselbe Verfahren kann auf einem Datenverarbeitungssystem, dem eine andere Architektur zugrunde liegt (zum Beispiel ein lokales, Weitverkehrs-, globales, Mobilfunk- oder Satelliten-Netzwerk) und das einen beliebigen Typ von (leitungsgebundenen und/oder drahtlosen) Verbindungen nutzt, oder sogar auf einem eigenständigen System ausgeführt werden. In jedem Fall kann das Datenverarbeitungssystem eine andere Struktur oder ähnliche Elemente aufweisen (beispielsweise Cachespeicher, in denen Programme oder deren Teile temporär gespeichert werden); darüber hinaus kann das Datenverarbeitungssystem durch eine beliebige Einheit zum Ausführen eines Codes, sowohl auf der Grundlage einer physischen Maschine oder einer virtuellen Maschine (beispielsweise eines PDA, eines Mobiltelefons und dergleichen), oder durch eine Kombination mehrerer Einheiten (beispielsweise eine Architektur mit mehreren Ebenen, eine Raster-Datenverarbeitungsinfrastruktur und dergleichen) ersetzt werden.

Claims

Verfahren (400) zum Implementieren eines Software-Abbildes von einem Quellen-Datenverarbeitungssystem auf einer Vielzahl von Ziel-Datenverarbeitungseinheiten eines Ziel-Datenverarbeitungssystems, wobei das Software-Abbild eine Vielzahl von Speicherblöcken aufweist, auf die einzeln zugegriffen werden kann, wobei eine vordefinierte Teilmenge der Speicherblöcke ein Bootstrap-Modul definieren und das Verfahren die Schritte aufweist: Herunterladen (406) des Bootstrap-Moduls von dem Quellen-Datenverarbeitungssystem auf eine Haupteinheit der Ziel-Datenverarbeitungseinheiten, Booten (407 bis 409) der Haupt-Ziel-Datenverarbeitungseinheit von dem Bootstrap-Modul und dadurch Laden eines in dem Bootstrap-Modul enthaltenen Datenstromtreibers, Erfüllen (410 bis 422) jeder Anforderung für das Zugreifen auf einen ausgewählten Speicherblock des Software-Abbildes auf der Haupt-Datenverarbeitungseinheit durch den Datenstromtreiber, indem der Datenstromtreiber als Reaktion auf eine erste der Anforderungen für das Zugreifen auf den ausgewählten Speicherblock den ausgewählten Speicherblock von dem Quellen-Datenverarbeitungssystem herunterlädt (413 bis 414) und den ausgewählten Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit speichert (415 bis 416) oder, wenn dies nicht der Fall ist, auf den ausgewählten Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit zugreift (417), Bereitstellen (423 bis 427) des Bootstrap-Moduls für jede einzelne aus einer Gruppe sekundärer Ziel-Datenverarbeitungseinheiten, Booten (428 bis 429) jeder sekundären Ziel-Datenverarbeitungseinheit von dem Bootstrap-Modul und dadurch Laden des Datenstromtreibers, und Erfüllen (430 bis 448) jeder Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock des Software-Abbildes auf der sekundären Datenverarbeitungseinheit durch den Datenstromtreiber, indem der Datenstromtreiber als Reaktion auf eine erste der Anforderungen für das Zugreifen auf den weiteren ausgewählten Speicherblock den weiteren ausgewählten Speicherblock von der Haupt-Ziel-Datenverarbeitungseinheit abruft und den weiteren ausgewählten Speicherblock in der sekundären Ziel-Datenverarbeitungseinheit speichert (441 bis 442) oder, wenn dies nicht der Fall ist, auf den weiteren ausgewählten Speicherblock in der sekundären Ziel-Datenverarbeitungseinheit zugreift (443), Empfangen (449) einer Anforderung für ein Entfernen der Haupt-Ziel-Datenverarbeitungseinheit aus dem Ziel-Datenverarbeitungssystem, Auswählen (450 bis 452) einer der sekundären Ziel-Datenverarbeitungseinheiten, Festlegen (453 bis 456) der ausgewählten sekundären Ziel-Datenverarbeitungseinheit als neue Haupt-Ziel-Datenverarbeitungseinheit, und Entfernen (457) der Haupt-Ziel-Datenverarbeitungseinheit aus dem Ziel-Datenverarbeitungssystem, wobei der Schritt des Auswählens (450 bis 452) einer der sekundären Ziel-Datenverarbeitungseinheiten aufweist: Auswählen (452) der ältesten der sekundären Ziel-Datenverarbeitungseinheiten.
Verfahren (400) nach Anspruch 1, wobei es sich bei den Ziel-Datenverarbeitungseinheiten um virtuelle Zielmaschinen handelt, die auf dem Ziel-Datenverarbeitungssystem betrieben werden.
Verfahren (400) nach Anspruch 1 oder 2, wobei der Schritt des Bootens (407 bis 409) der Haupt-Ziel-Datenverarbeitungseinheit aufweist: Starten (409) eines in dem Software-Abbild auf der Haupt-Datenverarbeitungseinheit enthaltenen Zugriffs-Servers, wobei der Schritt des Erfüllens (430 bis 448) jeder Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock aufweist: Übergeben (433) einer Anforderung für ein Abrufen des weiteren ausgewählten Speicherblocks durch den Datenstromtreiber der sekundären Datenverarbeitungseinheit an den Zugriffs-Server der Haupt-Datenverarbeitungseinheit als Reaktion auf die erste Anforderung für das Zugreifen auf den weiteren ausgewählten Speicherblock, und Zurückgeben (434 bis 440) des weiteren ausgewählten Speicherblocks von dem Zugriffs-Server der Haupt-Datenverarbeitungseinheit an den Datenstromtreiber der sekundären Datenverarbeitungseinheit.
Verfahren 400 nach Anspruch 3, wobei der Schritt des Herunterladens (406) des Bootstrap-Moduls auf eine Haupteinheit der Ziel-Datenverarbeitungseinheiten aufweist: Konfigurieren (406) des Datenstromtreibers zum Herunterladen jedes ausgewählten Speicherblocks von dem Quellen-Datenverarbeitungssystem als Reaktion auf die erste Anforderung zum Zugreifen auf den ausgewählten Speicherblock, und wobei der Schritt des Bereitstellens (428 bis 429) des Bootstrap-Moduls für jede einzelne aus einer Gruppe von sekundären Ziel-Datenverarbeitungseinheiten aufweist: Konfigurieren (427) des Datenstromtreibers zum Abrufen jedes weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit als Reaktion auf die erste Anforderung für das Zugreifen auf den weiteren ausgewählten Speicherblock.
Verfahren (400) nach einem der Ansprüche 1 bis 4, das ferner die Schritte aufweist: Bereitstellen (403) einer ersten der Ziel-Datenverarbeitungseinheiten für eine erste Implementierung des Software-Abbildes auf dem Ziel-Datenverarbeitungssystem, Festlegen (405) der ersten Ziel-Datenverarbeitungseinheit als Haupt-Ziel-Datenverarbeitungseinheit, Bereitstellen (403) einer Gruppe nächster Ziel-Datenverarbeitungseinheiten für eine nächste Implementierung des Software-Abbildes auf dem Ziel-Datenverarbeitungssystem, und Festlegen (423) jeder nächsten Ziel-Datenverarbeitungseinheit als sekundäre Ziel-Datenverarbeitungseinheit.
Verfahren (400) nach einem der Ansprüche 1 bis 5, wobei der Schritt des Erfüllens (410 bis 422) jeder Anforderung für das Zugreifen auf einen ausgewählten Speicherblock aufweist: Speichern (422) einer Anzeige jedes ausgewählten Speicherblocks, der in der Haupt-Ziel-Datenverarbeitungseinheit aktualisiert worden ist, und wobei der Schritt des Abrufens (433 bis 440) des weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit aufweist: Prüfen (434), ob der weitere ausgewählte Speicherblock in der virtuellen Hauptmaschine aktualisiert worden ist, und Herunterladen (436 bis 437) des weiteren ausgewählten Speicherblocks von dem Quellen-Datenverarbeitungssystem auf die Haupt-Datenverarbeitungseinheit, wenn der weitere ausgewählte Speicherblock in der virtuellen Hauptmaschine aktualisiert worden ist, oder, wenn dies nicht der Fall ist, Lesen (439) des weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit.
Verfahren (400) nach Anspruch 6, wobei der Schritt des Erfüllens (430 bis 448) jeder Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock aufweist: Speichern (448) einer Anzeige jedes weiteren ausgewählten Speicherblocks, der in der sekundären Ziel-Datenverarbeitungseinheit aktualisiert worden ist.
Verfahren (400) nach einem der Ansprüche 1 bis 5, wobei der Schritt des Erfüllens (410 bis 422) jeder Anforderung für das Zugreifen auf einen ausgewählten Speicherblock aufweist: Speichern (420) einer Originalversion jedes ausgewählten Speicherblocks, der in der Haupt-Ziel-Datenverarbeitungseinheit aktualisiert worden ist, und wobei der Schritt des Abrufens (433 bis 440) des weiteren ausgewählten Speicherblocks von der Haupt-Ziel-Datenverarbeitungseinheit aufweist: Prüfen (434), ob der weitere ausgewählte Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit aktualisiert worden ist, und Zurückgeben (438 bis 439) des weiteren ausgewählten Speicherblocks, wenn der weitere ausgewählte Speicherblock in der Haupt-Ziel-Datenverarbeitungseinheit nicht aktualisiert worden ist, oder, wenn dies nicht der Fall ist, der Originalversion desselben.
Verfahren (400) nach Anspruch 8, wobei der Schritt des Erfüllens (430 bis 448) jeder Anforderung für das Zugreifen auf einen weiteren ausgewählten Speicherblock aufweist: Speichern (446) einer Originalversion jedes weiteren ausgewählten Speicherblocks, der in der sekundären Ziel-Datenverarbeitungseinheit aktualisiert worden ist.
Computerprogramm (300), das Codemittel aufweist, um ein Datenverarbeitungssystem (100) zum Ausführen der Schritte des Verfahrens (400) nach einem der Ansprüche 1 bis 9 zu veranlassen, wenn das Computerprogramm auf dem Datenverarbeitungssystem ausgeführt wird.
Datenverarbeitungssystem (100), das Mittel (300) aufweist, die zum Ausführen der Schritte des Verfahrens (400) nach einem der Ansprüche 1 bis 9 konfiguriert sind.