DE102012221814A1

DE102012221814A1 - Neuanordnung von Software-Abbildern auf der Grundlage von deren vorhergesagter Verwendung

Info

Publication number: DE102012221814A1
Application number: DE102012221814A
Authority: DE
Inventors: Claudio Marinelli; Paolo Scotton; Scot MacLellan; Jacques Fontignie
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2011-12-13
Filing date: 2012-11-29
Publication date: 2013-06-13
Also published as: GB2499290B; US8943291B2; US20130151805A1; GB2499290A

Abstract

Es wird eine Lösung zum Verwalten eines Software-Abbilds vorgeschlagen, das in einer Vielzahl von physischen Blöcken eines Speichersystems gespeichert wird. Ein entsprechendes Verfahren (A1 bis A15) weist die Schritte des Überwachens (A4 bis A5) eines jeden Zugriffs auf die physischen Blöcke, das Berechnen (A12 bis A13) einer vorhergesagten Abfolge des Zugriffs auf die physischen Blöcke gemäß den überwachten Zugriffen und das Neuanordnen (A14 bis A15) der physischen Blöcke gemäß der vorhergesagten Abfolge auf.

Description

Technisches Gebiet
Die Lösung gemäß einer oder mehrerer Ausführungsformen der vorliegenden Erfindung betrifft allgemein das Gebiet der Datenverarbeitung. Insbesondere betrifft diese Lösung die Verwaltung von Software-Abbildern.
Hintergrund
Die Verwaltung von Software-Abbildern ist die wichtigste Aktivität in modernen Datenverarbeitungszentren. Allgemein gesagt handelt es sich bei einem Software-Abbild um eine Struktur, die Dateien kapselt, welche sich auf einer (physischen oder virtuellen) Datenverarbeitungsmaschine befinden – die zum Beispiel ihr Betriebssystem, ihre Anwendungsprogramme und/oder ihre Daten speichert. Jedes Datenverarbeitungszentrum kann dann einfach als ein Satz von tragbaren Software-Abbildern gesehen werden. Die Software-Abbilder können auch auf ganz einfache Weise verschoben, kopiert, repliziert und geschützt werden und eignen sich auch zur Profilerstellung; folglich kann die Leistungsfähigkeit des Datenverarbeitungszentrums beträchtlich gesteigert werden. Diese Vorteile werden deutlich erkannt, wenn die Software-Abbilder in virtuellen Maschinen (d. h. mittels Software vorgenommenen Nachbildungen von physischen Maschinen) verwendet werden; in diesem Fall kann jede Art von virtueller Maschine tatsächlich nach Bedarf bereitgestellt werden, indem einfach eine neue virtuelle Maschine erzeugt und diese dann von einem gewünschten Software-Abbild (das in diesem Fall auch als virtuelles Abbild bezeichnet wird) gebootet wird. Dies ist zum Beispiel besonders bei der Datenverarbeitung in einer Rechnerwolke (Cloud-Computing) hilfreich (wobei für Client-Computer, die deren physische Ausführung nicht kennen, mehrere Datenverarbeitungsdienste bereitgestellt werden).
Die Verwaltung der Software-Abbilder kann jedoch eine Herausforderung darstellen, insbesondere in großen Datenverarbeitungszentren mit einem Abbild-Archiv, das einen zentralisierten Zugriff auf eine sehr große Anzahl von Software-Abbildern (bis zu mehreren tausend) ermöglicht.
Ein Problem, das zum Nachteil gereichen kann, wenn die Anzahl der Software-Abbilder zunimmt, besteht in deren Verbrauch an Ressourcen in Form von Speichereinheiten des Datenverarbeitungszentrums (zum Beispiel Festplatten), auf denen sie gespeichert werden. Um dieses Problem anzugehen, schlägt US-A-2006/0155735 vor, die Software-Abbilder in Segmente aufzuteilen, die in dem Abbild-Archiv nur einmal gespeichert werden (um die Duplizierung von gleichen Segmenten in verschiedenen Software-Abbildern zu vermeiden); zu diesem Zweck wird jedes Software-Abbild durch einen Vektor dargestellt, der in der Reihenfolge auf die Segmente des Software-Abbilds zeigt, in der sie in dem Software-Abbild erscheinen.
Ein weiteres Problem kann auf eine Latenzzeit des Abbild-Archivs zurückzuführen sein. Tatsächlich werden die Dateien eines jeden Software-Abbilds in den Speichereinheiten üblicherweise in Blöcken gespeichert, auf die einzeln zugegriffen werden kann – zum Beispiel Sektoren einer Festplatte. Eine Zugriffszeit auf jeden Block auf der Festplatte ist jedoch verhältnismäßig hoch (im Vergleich zu seiner Verarbeitungszeit). Um dieses Problem zu bewältigen, werden gewöhnlich Vorabrufverfahren eingesetzt; in diesem Fall wird immer, wenn auf einen Block zugegriffen wird, gleichzeitig ein Satz nächster Blöcke von der Festplatte gelesen und in einem Cachespeicher abgelegt, damit er jederzeit zur Verfügung steht, wenn er kurz darauf angefordert wird.
In jedem Fall hängen die Blöcke einer jeden Datei des Software-Abbilds auf der Festplatte im Allgemeinen nicht zusammen; insbesondere werden die Blöcke, die einen tatsächlichen Inhalt der Datei speichern, üblicherweise mit den Blöcken anderer Dateien gemischt (da ihre Position auf der Festplatte von einer entsprechenden Schreibzeit abhängt). Der nacheinander stattfindende Zugriff auf Blöcke des Software-Abbilds, die nicht zusammenhängen, beeinträchtigt ihre Zugriffszeit erheblich. Aufgrund der mechanischen Natur einer sich drehenden Platte und eines sich bewegenden Kopfes der Festplatte erhöht dies in der Tat entweder die Zeit, die der Kopf braucht, um eine konzentrische Spur der Platte zu erreichen, die einen nächsten Block speichert, oder die Zeit, die der nächste Block auf der Spur braucht, um den Kopf zu erreichen; überdies arbeitet der Cachespeicher nicht ordnungsgemäß, da die vorab abgerufenen Blöcke möglicherweise unbrauchbar sind.
Um dieses Problem zu mildern, ist es gegebenenfalls möglich, die Festplatte mit Hilfe von Standard-Werkzeugen zu defragmentieren. Auf diese Weise würde die Festplatte neu geordnet werden, indem die Blöcke einer jeden Datei komprimiert werden.
Dieses Verfahren ist jedoch vollkommen unwirksam beim Umgang mit der Latenzzeit, die entsteht, wenn Service-Informationen für den Zugriff auf die Dateien erforderlich sind (da sie üblicherweise in einem reservierten Teil der Festplatte gespeichert werden); dasselbe gilt ferner auch, wenn nacheinander auf verschiedene Dateien zugegriffen wird (da die entsprechenden Blöcke im Allgemeinen auf der Festplatte nicht zusammenhängen).
Kurzdarstellung
Im Allgemeinen beruht die Lösung zur Verwaltung von Software-Abbildern gemäß einer oder mehreren Ausführungsformen der vorliegenden Erfindung auf dem Gedanken, die Software-Bilder entsprechend ihrer Verwendung neu anzuordnen.
Insbesondere sind ein oder mehrere Aspekte der Lösung gemäß bestimmten Ausführungsformen der Erfindung in den unabhängigen Ansprüchen und vorteilhafte Merkmale derselben Lösung in den abhängigen Ansprüchen beschrieben, wobei der Wortlaut aller Ansprüche durch Bezugnahme als Bestandteil hiervon gilt (wobei jedes beliebige vorteilhafte Merkmal, das in Bezug auf einen bestimmten Aspekt der Lösung gemäß einer Ausführungsform der Erfindung bereitgestellt wird, auf jeden anderen Aspekt davon entsprechend Anwendung findet).
Genauer gesagt, stellt ein Aspekt der Lösung gemäß einer Ausführungsform der Erfindung ein Verfahren zum Verwalten eines Software-Abbilds bereit, wobei dessen Blöcke gemäß einer vorhergesagten Abfolge des Zugriffs auf die Blöcke neu angeordnet werden.
Ein weiterer Aspekt der Lösung gemäß einer Ausführungsform der Erfindung stellt ein entsprechendes Computerprogramm bereit.
Noch ein weiterer Aspekt der Lösung gemäß einer Ausführungsform der Erfindung stellt ein entsprechendes Computerprogrammprodukt bereit.
Ein anderer Aspekt der Lösung gemäß einer Ausführungsform der Erfindung stellt ein entsprechendes System bereit.
Kurze Beschreibung der Zeichnungen
Die Lösung gemäß einer oder mehrerer Ausführungsformen der Erfindung sowie weitere Merkmale und die Vorteile der Erfindung lassen sich am besten unter Bezugnahme auf die folgende ausführliche Beschreibung verstehen, die lediglich in Form einer nicht als Einschränkung zu verstehenden Angabe erfolgt und in Verbindung mit den beigefügten Zeichnungen gelesen werden soll (in denen der Einfachheit halber übereinstimmende Elemente mit gleichen oder ähnlichen Bezugszeichen versehen sind und ihre Erklärung nicht wiederholt wird und der Name einer jeden Einheit im Allgemeinen zur Bezeichnung ihres Typs sowie ihrer Attribute – wie Wert, Inhalt und Darstellung – verwendet wird). Im Einzelnen:
zeigt 1 eine bildliche Darstellung eines Datenverarbeitungszentrums, das verwendet werden kann, um die Lösung gemäß einer Ausführungsform der Erfindung in die Praxis umzusetzen,
2 zeigt ein Blockdiagramm einer beispielhaften virtualisierten Umgebung, in der die Lösung gemäß einer Ausführungsform der Erfindung angewendet werden kann,
3A bis 3B zeigen ein beispielhaftes Anwendungsszenario für die Lösung gemäß einer Ausführungsform der Erfindung,
4A bis 4B zeigen eine beispielhafte Realisierung der Lösung gemäß einer Ausführungsform der Erfindung, und
5 zeigt ein Diagramm der Zusammenarbeit, das die Rollen der Software-Hauptmodule darstellt, die zur Realisierung der Lösung gemäß einer Ausführungsform der Erfindung verwendet werden können.
Beschreibung der Ausführungsform(en)
Es wird insbesondere auf 1 verwiesen, in der ein Datenverarbeitungszentrum 100 bildlich dargestellt ist, das verwendet werden kann, um die Lösung gemäß einer Ausführungsform der Erfindung in die Praxis umzusetzen.
Das Datenverarbeitungszentrum 100 weist einen Satz von Verarbeitungssystemen 105 (zum Beispiel Servercomputer), einen Satz von Speichersystemen 110 (zum Beispiel Festplatten) und eine Konsole 115 zu deren Steuerung auf – wobei die Konsole 115 auch mit einem Laufwerk zum Lesen von DVDs oder CDs 120 ausgestattet sein kann. Ein Router-(oder Vermittlungsstellen-)System 125 verwaltet Übertragungen zwischen den Verarbeitungssystemen 105, den Speichersystemen 110 und der Konsole 115 sowie zur externen Umgebung des Datenverarbeitungszentrums 100 (zum Beispiel über das Internet); zu diesem Zweck sind die Verarbeitungssysteme 105, die Speichersysteme 110, die Konsole 115 und das Routersystem 125 über ein Verkabelungssystem 130 verbunden.
Jedes Verarbeitungssystem 105 wird aus mehreren Einheiten gebildet, die mit einem Übertragungsbus 135 parallel verbunden sind. Im Einzelnen steuert ein Satz von (einem oder mehreren) Mikroprozessoren (μP) 140 den Betrieb des Verarbeitungssystems 105; ein RAM 145 wird von den Mikroprozessoren 140 direkt als Arbeitsspeicher verwendet und ein ROM 150 speichert Basiscode zum Booten des Verarbeitungssystems 105. Überdies weist das Verarbeitungssystem 105 einen Netzwerkadapter 155 auf, der dazu dient, das Verarbeitungssystem 105 mit dem Verkabelungssystem 130 zu verbinden.
Ein Blockdiagramm einer beispielhaften virtualisierten Umgebung, in der die Lösung gemäß einer Ausführungsform der Erfindung angewendet werden kann, ist in 2 gezeigt.
Die virtualisierte Umgebung wird auf einer Hardware 205 realisiert, die aus einer physischen Struktur gebildet wird, welche mehrere Einheiten der vorstehend beschriebenen Verarbeitungssysteme und Speichersysteme aufweist. Ein Betriebssystem 210 eines Hostcomputers, das direkt auf der Hardware 205 ausgeführt wird, legt eine Software-Plattform fest, auf der ein beliebiges anderes Programm laufen kann. In diesem bestimmten Fall emuliert eine Virtualisierungsebene 215, die auf dem Betriebssystem 210 des Hostcomputers läuft, eine oder mehrere virtuelle Maschinen 220, die jeweils von einer abstrakten Struktur gebildet werden, die eine Hardware emuliert, über die die virtuelle Maschine 220 die alleinige Kontrolle hat. Jede virtuelle Maschine 220 weist ein Gast-Betriebssystem 225 auf, das jetzt auf ihrer emulierten Hardware ausgeführt wird. Das Gast-Betriebssystem 225 legt ebenfalls eine Software-Plattform der virtuellen Maschine 220 fest, auf der ein oder mehrere Anwendungsprogramme 230 laufen.
Ein beispielhaftes Anwendungsszenario für die Lösung gemäß einer Ausführungsform der Erfindung ist in 3A bis 3B gezeigt.
Es wird bei 3A begonnen. Die permanenten Daten (die auch nach ihrer aktuellen Verwendung weiterhin zur Verfügung stehen sollen) in jeder virtuellen Maschine 220 werden logisch in virtuelle Dateien 305 gegliedert (gesteuert von einem Dateisystem des Gast-Betriebssystems 225). Jede virtuelle Datei 305 ist ein logischer Behälter mit zusammengehörenden (permanenten) Daten, der auf einer virtuellen Platte 310 der virtuellen Maschine 220 gespeichert wird (d. h. eine abstrakte Struktur, die eine physische Platte emuliert). Zu diesem Zweck wird die virtuelle Platte 310 in virtuelle Blöcke 315 unterteilt, wobei das Gast-Betriebssystem (für Lese- und/oder Schreiboperationen) auf jeden einzeln zugreifen kann – jeder besteht beispielsweise aus 520 Byte. Ein Inhalt der virtuellen Datei 305 wird in einem Satz von virtuellen Blöcken 315 gespeichert (deren Position auf der virtuellen Platte 310 von ihrer Schreibzeit abhängt). Der virtuellen Datei 305 wird auch ein Deskriptor (in der Figur nicht gezeigt) zugeordnet, der in weiteren virtuellen Blöcken 315 gespeichert wird; der Deskriptor weist Einzelheiten der virtuellen Datei 305 (zum Beispiel ihren Namen, ihre Größe, Zugriffsberechtigungen, Zeitpunkt der Erstellung, Zeitpunkt der letzten Änderung, Zeitpunkt des letzten Zugriffs und dergleichen) sowie Angaben für den Zugriff auf die virtuellen Blöcke 315 auf, die ihren Inhalt speichern. Ein Teil der virtuellen Platte 310 ist für das Gast-Betriebssystem 225 reserviert, das dort Service-Informationen speichert, unter anderem ein Verzeichnis für den Zugriff auf die Deskriptoren aller virtuellen Dateien 305.
Die virtuellen Blöcke 315 werden de facto in entsprechenden physischen Blöcken 320 der Speichersysteme gespeichert, was von der Virtualisierungsebene 215 gesteuert wird (wobei jeder beispielsweise aus einem Sektor einer physischen Platte besteht, die von einer bestimmten Festplatte der Speichersysteme realisiert wird). Im Einzelnen wird jede virtuelle Platte 310 in einem entsprechenden Software-Abbild 325 gespeichert, das aus einer Struktur besteht, die den Inhalt von einer oder mehreren Festplatten (zum Beispiel ihr Betriebssystem, ihre Anwendungsprogramme und ihre möglichen Daten) kapselt; das Software-Abbild 325 wird üblicherweise in einer oder mehreren physischen Dateien einer entsprechenden physischen Platte (vom Betriebssystem 210 des Hostcomputers gesteuert) gespeichert. Zu diesem Zweck bildet die Virtualisierungsebene 215 die virtuellen Blöcke 315 einer jeden virtuellen Platte 310 auf die entsprechenden physischen Blöcke 320 ihres Software-Abbilds 325 ab. Die Position der physischen Blöcke 320 in dem Software-Abbild 325 hängt von ihrer Schreibzeit ab, so dass sie möglicherweise nicht miteinander zusammenhängen (und sogar über die gesamte entsprechende physische Platte verteilt sein können, wenn diese stark fragmentiert ist).
Während des Betriebs der virtuellen Maschine 220 wird laufend auf die virtuellen Dateien 305 zugegriffen – zum Beispiel durch das Gast-Betriebssystem 225 und die Anwendungsprogramme, die darauf ausgeführt werden (in der Figur nicht gezeigt). Dies umfasst den Zugriff auf die entsprechenden virtuellen Blöcke 315 auf den virtuellen Platten 310 (vom Gast-Betriebssystem 225 gesteuert), der wiederum den Zugriff auf die entsprechenden physischen Blöcke 320 in den Software-Abbildern 325 (von der Virtualisierungsebene 215 gesteuert) umfasst; der nacheinander stattfindende Zugriff auf drei verschiedene virtuelle Dateien 305 zum Beispiel, die mit VF₁, VF₂ und VF₃ bezeichnet sind, kann den nacheinander stattfindenden Zugriff auf entsprechende virtuelle Blöcke 315, die mit (VB₁₁, VB₁₂, VB₁₃, VB₁₄, VB₁₅), (VB₂₁, VB₂₂) beziehungsweise (VB₃₁, VB₃₂, VB₃₃) bezeichnet sind, und dann auf die entsprechenden physischen Blöcke 320 desselben Software-Abbilds 325 umfassen, das mit (FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅), (FB₂₁, FB₂₂) beziehungsweise (FB₃₁, FB₃₂, FB₃₃) bezeichnet ist.
Üblicherweise ruft die Virtualisierungsebene 215 einen Satz von nächsten physischen Blöcken 320 (zum Beispiel 2 bis 10) vorab ab, wenn auf jeden physischen Block 320 zugegriffen wird – wie zum Beispiel die vorab abgerufenen physischen Blöcke, die in der Figur für den physischen Block FB₁₁ mit dem Bezugszeichen 320f versehen sind. Die vorab abgerufenen physischen Blöcke 320f werden in einem Cachespeicher 330 gespeichert; auf die vorab abgerufenen physischen Blöcke 320f kann dann sehr schnell im Cachespeicher 330 direkt zugegriffen werden (ohne erneut auf das Software-Abbild 325 zuzugreifen), wenn sie kurz darauf angefordert werden.
Wie zu sehen ist, ist der Zugriff auf die benötigten physischen Blöcke 320 (d. h. die physischen Blöcke FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂, FB₃₁, FB₃₂ und FB₃₃ in dem betreffenden Beispiel) mit großen Bewegungen in dem Software-Abbild 325 verbunden, wenn die physische Platte, die das Software-Abbild 325 speichert, stark fragmentiert ist; aufgrund der typischen Latenzzeit der physischen Platte, auf der sie gespeichert sind, erhöht dies die Zugriffszeit auf die physischen Blöcke 320 erheblich. In diesem Fall arbeitet der Cachespeicher 330 überdies nicht ordnungsgemäß; tatsächlich liegen die physischen Blöcke 320, auf die nacheinander zugegriffen werden soll (in jeder virtuellen Datei 305 und von dem einen zum anderen), in dem Software-Abbild 325 fast nie nebeneinander, so dass sie nicht vorab abgerufen werden können.
Es geht nun mit 3B weiter. Bei der Lösung gemäß einer Ausführungsform der Erfindung wird jeder Zugriff auf die physischen Blöcke 320 überwacht (zum Beispiel während eines Boot-Vorgangs auf dem Software-Abbild 325 einer jeden virtuellen Maschine 220 und/oder später während der Ausführung einer jeden Software-Anwendung in derselben virtuellen Maschine 220). Eine vorhergesagte Abfolge des Zugriffs auf die physischen Blöcke 320 wird gemäß den überwachten Zugriffen berechnet (zum Beispiel anhand eines Zugriffsgraphen, der ein entsprechendes Muster des Zugriffs auf die physischen Blöcke 320 darstellt). Die physischen Blöcke 320 werden in dem Software-Abbild 325 dann gemäß dieser vorhergesagten Abfolge neu angeordnet. In dem betreffenden Szenario, in dem beispielsweise nacheinander auf die physischen Blöcke FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂, FB₃₁, FB₃₂ und FB₃₃ zugegriffen wird, werden diese physischen Blöcke 320 in derselben Reihenfolge an den Anfang der physischen Platte verschoben, welche das Software-Abbild 325 speichert. Wenn zu einem späteren Zeitpunkt in derselben Reihenfolge auf dieselben virtuellen Blöcke VB₁₁, VB₁₂, VB₁₃, VB₁₄, VB₁₅, VB₂₁, VB₂₂, VB₃₁, VB₃₂ und VB₃₃ zugegriffen wird (zum Beispiel, wenn eine andere virtuelle Maschine 220 von demselben Software-Abbild 325 bootet), hängen die entsprechenden physischen Blöcke FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂, FB₃₁, FB₃₂ und FB₃₃ in dem Software-Abbild 325 dann also zusammen.
Die vorstehend beschriebene Lösung verringert die Latenzzeit des Software-Abbilds 325 beträchtlich. Tatsächlich ist es auf diese Weise sehr wahrscheinlich, dass auf zusammenhängende physische Blöcke 320 nacheinander zugegriffen wird. Dies wirkt sich vorteilhaft auf ihre Zugriffszeit aus; darüber hinaus erlaubt es den Vorababruf der nächsten physischen Blöcke 320, so dass der Cachespeicher 330 bestmöglich genutzt werden kann.
Das gewünschte Ergebnis wird erzielt, indem man die zu erwartende tatsächliche Nutzung des Software-Abbilds 325 berücksichtigt. Diese Lösung ist folglich bei der Verringerung der Zugriffszeit auf die physischen Blöcke 320 sowohl in jeder virtuellen Datei 305 als auch zwischen nacheinander folgenden virtuellen Dateien 305 äußerst wirksam.
Das vorgeschlagene Verfahren ist besonders bei der vorstehend beschriebenen Ausführungsform vorteilhaft (bei der virtuelle Maschinen 220 auf die Software-Abbilder 325 zugreifen); in diesem Fall ist es tatsächlich möglich, die Zugriffszeit auf die physischen Blöcke 320 sowohl auf der Ebene des Inhalts als auch auf der Ebene der Service-Informationen der virtuellen Dateien 305 zu verringern.
Eine beispielhafte Realisierung der Lösung gemäß einer Ausführungsform der Erfindung ist in 4A bis 4B gezeigt.
Es wird bei 4A begonnen, in der ein Zugriffsgraph 400A gemäß den überwachten Zugriffen auf die physischen Blöcke 320 ermittelt wird. Der Zugriffsgraph 400A hat einen Satz von Knoten; jeder Knoten stellt einen entsprechenden physischen Block 320 dar (zumindest für die physischen Blöcke 320, auf die einmal oder mehrmals zugegriffen worden ist). In dem betreffenden Beispiel weist der Zugriffsgraph 400A zehn Knoten auf, die die physischen Blöcke FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂, FB₃₁, FB₃₂ und FB₃₃ darstellen (die der Einfachheit halber mit denselben Bezugszeichen versehen sind).
Der Zugriffsgraph 400A hat darüber hinaus einen Satz von geordneten Kanten, wobei sich jede zwischen einem entsprechenden Paar von Knoten FB₁₁ bis FB₃₃ befindet (die durch Verknüpfung ihrer beiden Bezugszeichen gekennzeichnet sind); jede Kante (FB₁₁-FB₁₂)-(FB₃₂-FB₃₃) stellt eine Wahrscheinlichkeit eines nachfolgenden Zugriffs auf die entsprechenden physischen Blöcke 320 dar (zumindest zwischen den physischen Blöcken 320, auf die einmal oder mehrmals nacheinander zugegriffen worden ist). In dem betreffenden Beispiel beträgt die Wahrscheinlichkeit des nachfolgenden Zugriffs zwischen den verschiedenen Paaren von physischen Blöcken 320:
FB₁₁-FB₁₂ = 80%
FB₁₁-FB₂₂ = 20%
FB₁₂-FB₁₃ = 100%
FB₁₃-FB₁₄ = 100%
FB₁₄-FB₁₅ = 65%
FB₁₅-FB₂₁ = 100%
FB₂₁-FB₂₂ = 70%
FB₂₂-FB₃₁ = 100%
FB₂₁-FB₃₃ = 30%
FB₃₁-FB₃₂ = 100%
FB₃₂-FB₃₃ = 100%.
Es geht nun mit 4B weiter. Aus dem vorstehend beschriebenen Zugriffsgraphen wird ein Dendrogramm 400B erzeugt. Das Dendrogramm 400B ist ein Baumgraph, der ein gruppenweises Zusammenfassen der Knoten des Zugriffsgraphen in Communities entsprechend der Wahrscheinlichkeit des nacheinander stattfindenden Zugriffs auf die entsprechenden physischen Blöcke (was durch ihre Kanten festgelegt wird) darstellt – d. h. mit der Wahrscheinlichkeit des nacheinander stattfindenden Zugriffs auf die physischen Blöcke, die auf jeder Stufe des Baumes innerhalb einer jeden Community hoch und zwischen verschiedenen Communities gering ist. Das Dendrogramm 400B kann mit beliebigen bekannten Algorithmen zum Auffinden von Communities (zum Beispiel dem Girvan-Newman-Algorithmus) erzeugt werden.
Das Dendrogramm 400B hat einen Satz Blätter; jedes Blatt stellt einen entsprechenden Knoten des Zugriffsgraphen und dann den entsprechenden physischen Block dar (und dieser ist der Einfachheit halber mit demselben Bezugszeichen FB₁₁ bis FB₃₃ versehen). Das Dendrogramm 400B hat darüber hinaus einen Baum mit internen Scheitelpunkten, die von den Blättern FB₁₁ bis FB₃₃ aus von unten nach oben zu einer Wurzel führen, die eine Community aus allen Knoten des Zugriffsgraphen darstellt (und mit deren Bezugszeichen (FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂, FB₃₁, FB₃₂, FB₃₃) versehen ist); jede interne Kante stellt eine entsprechende Community aus physischen Knoten und dann die kombinierte Wahrscheinlichkeit des nachfolgenden Zugriffs auf sie dar (und sie ist mit deren Bezugszeichen versehen). In dem betreffenden Beispiel stellt eine erste Stufe von internen Scheitelpunkten (knapp oberhalb der Blätter FB₁₁ bis FB₃₃) die Communities (FB₁₁, FB₁₂), (FB₁₃, FB₁₄), (FB₂₁, FB₂₂) und (FB₃₁, FB₃₂) dar. Eine zweite Stufe von internen Scheitelpunkten stellt die Communities (FB₁₁, FB₁₂, FB₁₃, FB₁₄) und (FB₃₁, FB₃₂, FB₃₃) dar. Eine dritte Stufe von internen Scheitelpunkten stellt die Community (FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅) dar. Eine vierte Stufe von internen Scheitelpunkten (knapp unterhalb der Wurzel (FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂, FB₃₁, FB₃₂, FB₃₃)) stellt die Community (FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂) dar.
Die Anordnung der Blätter FB₁₁ bis FB₃₃ in dem Dendrogramm 400B legt direkt die vorhergesagte Abfolge des Zugriffs auf die entsprechenden physischen Blöcke, d. h. FB₁₁, FB₁₂, FB₁₃, FB₁₄, FB₁₅, FB₂₁, FB₂₂, FB₃₁, FB₃₂ und FB₃₃ in dem betreffenden Beispiel, fest.
Es wird nun auf 5 Bezug genommen, in der ein Diagramm der Zusammenarbeit gezeigt ist, das die Rollen der Software-Hauptmodule darstellt, die zur Realisierung der Lösung gemäß einer Ausführungsform der Erfindung verwendet werden können. Diese Softwaremodule sind als Ganzes mit dem Bezugszeichen 500 versehen. Die Informationen (Programme und Daten) werden üblicherweise in den Speichersystemen des vorstehend beschriebenen Datenverarbeitungszentrums gespeichert und (zumindest teilweise) in den Arbeitsspeicher eines generischen Verarbeitungssystems des Datenverarbeitungszentrums geladen (zum Beispiel eines Servercomputers, der einen Satz von Software-Abbildern verwaltet, die zur Verwendung in dem Datenverarbeitungszentrum zur Verfügung stehen), wenn die Programme ausgeführt werden. Die Programme werden zunächst auf den Speichersystemen installiert, zum Beispiel von DVDs (über die Konsole des Datenverarbeitungszentrums). Die Figur beschreibt insbesondere sowohl die statische Struktur der Softwaremodule als auch ihr dynamisches Verhalten (anhand einer Reihe von ausgetauschten Nachrichten, von denen jede einen entsprechenden Vorgang darstellt, der mit Abfolgenummern, denen das Symbol ”A” vorausgeht, versehen ist).
Im Einzelnen verwaltet eine Abbildverwaltungseinheit 505 – die zum Beispiel in einem Bereitstellungs-Tool wie dem IBM Tivoli Provisioning Manager for Images (oder TPMfI) des IBM Tivoli Provisioning Manager for OS Deployment (oder TPM for OSD) der IBM Corporation realisiert ist (IBM und Tivoli sind Warenzeichen der IBM Corporation) – die Software-Abbilder (die als Ganzes mit dem Bezugszeichen 510 versehen sind), welche in einem entsprechenden Archiv gespeichert werden.
Zu diesem Zweck weist die Abbildverwaltungseinheit 505 eine Service-Schnittstelle 515 auf; die Service-Schnittstelle 510 zeigt einen Satz von Anwendungsprogrammierschnittstellen (Application Program Interfaces (APIs)) zum Durchführen einer Reihe von Service-Operationen (zum Beispiel der Konfiguration der Abbildverwaltungseinheit 505 und des Erfassens von Statistiken der Abbildverwaltungseinheit). Immer wenn die Service-Schnittstelle 515 einen entsprechenden Service-Befehl empfängt (der zum Beispiel von einem Systemadministrator über die Konsole vorgelegt wird), gibt sie den Service-Befehl an eine Serviceverwaltungseinheit 520 weiter (Vorgang ”A1.Empfangen”). Als Reaktion darauf führt die Serviceverwaltungseinheit 520 die Service-Operation durch, die in dem Service-Befehl angegeben ist (zum Beispiel die entsprechende Konfiguration der Abbildverwaltungseinheit 505 oder das Erfassen der angeforderten Statistiken), und sendet bei Bedarf ein entsprechendes Ergebnis zurück (Vorgang ”A2.Zurücksenden”).
Ferner weist die Abbildverwaltungseinheit 505 eine Zugriffsschnittstelle 525 auf; die Zugriffsschnittstelle 525 stellt einen Satz von weiteren APIs für den Zugriff auf einen ausgewählten physischen Block eines ausgewählten Software-Abbilds 510 zur Verfügung (zum Beispiel zum Lesen oder Schreiben darauf). Immer wenn die Zugriffsschnittstelle 525 einen entsprechenden Zugriffsbefehl empfängt (der zum Beispiel von einer virtuellen Maschine, die von dem ausgewählten Software-Abbild 510 aus bootet, oder von dem Betriebssystem oder einem Anwendungsprogramm vorgelegt wird, das auf einer virtuellen Maschine läuft, welche das ausgewählte Software-Abbild 510 bereitstellt), gibt sie den Zugriffsbefehl an eine Zugriffsverwaltungseinheit 530 weiter (Vorgang ”A3.Empfangen”). Als Reaktion darauf gibt die Zugriffsverwaltungseinheit 530 den Zugriffsbefehl an eine Überwachungsverwaltungseinheit 535 weiter, die für die Überwachung der Zugriffe auf die Software-Abbilder 510 zuständig ist (Vorgang ”A4.Überwachen”). Der Überwachungsagent 535 steuert ein Archiv, das eine Darstellung des Zugriffsgraphen eines jeden Software-Abbilds 510 speichert (das als Ganzes mit dem Bezugszeichen 540 versehen ist); als Reaktion auf jeden Zugriffsbefehl aktualisiert die Überwachungsverwaltungseinheit 535 den entsprechenden Zugriffsgraphen 540 entsprechend. Genauer gesagt fügt die Überwachungsverwaltungseinheit 535 bei Bedarf einen Knoten für den ausgewählten physischen Block zu dem Zugriffsgraphen 540 hinzu (d. h., wenn auf den ausgewählten physischen Block erstmalig zugegriffen wird), und sie fügt bei Bedarf eine Kante von dem Knoten eines zuvor ausgewählten physischen Blocks (der von der Überwachungsverwaltungseinheit 535 zuvor entsprechend markiert wurde) zu dem Knoten des ausgewählten physischen Blocks hinzu (d. h., wenn auf den zuvor ausgewählten physischen Block und den ausgewählten physischen Block erstmalig nacheinander zugegriffen wird). In jedem Fall führt die Überwachungsverwaltungseinheit 535 dann eine Neuberechnung der Wahrscheinlichkeit des Zugriffs auf einen jeden physischen Block durch, dessen Knoten mit dem Knoten des zuvor ausgewählten physischen Blocks verbunden ist (Vorgang ”A5.Aktualisieren”).
Die Überwachungsverwaltungseinheit 530 steuert auch ein Archiv, das eine Zuordnungstabelle für jedes Software-Abbild 510 speichert (die als Ganzes mit dem Bezugszeichen 545 versehen ist). Für jeden physischen Block eines jeden Software-Abbilds 510 (der durch seine Adresse darin gekennzeichnet ist) gibt die Zuordnungstabelle 545 an, ob der physische Block tatsächlich in dem Archiv der Software-Abbilder 510 oder in einem Arbeitsbereich 550 (der nachstehend ausführlich beschrieben wird) gespeichert wird; für jeden in dem Arbeitsbereich 550 gespeicherten physischen Block gibt die Zuordnungstabelle 545 auch seine Adresse darin an (Zuordnung seiner Adresse in dem Software-Abbild 510). Als Reaktion auf denselben Zugriffsbefehl prüft die Zugriffsverwaltungseinheit 530 darüber hinaus, ob der ausgewählte physische Block in dem ausgewählten Software-Abbild 510 oder in dem Arbeitsbereich 550 gespeichert wird (was in der Zuordnungstabelle 545 angegeben wird); im letzteren Fall ordnet die Zugriffsverwaltungseinheit 530 die Adresse des ausgewählten physischen Blocks in dem ausgewählten Software-Abbild 510 (das in dem Zugriffsbefehl angegeben wird) seiner Adresse in dem Arbeitsbereich 550 zu (die in der Zuordnungstabelle 545 angegeben ist) – Vorgang ”A6.Zuordnen”. Wenn der ausgewählte physische Block in dem ausgewählten Software-Abbild 510 gespeichert wird, gibt die Zugriffsverwaltungseinheit 530 den Zugriffsbefehl an eine Archivverwaltungseinheit 555 weiter, die ihn auf dem ausgewählten Software-Abbild 510 ausführt – zum Beispiel durch Lesen oder Schreiben in dem ausgewählten physischen Block (Vorgang ”A7.Ausführen”). Die Archivverwaltungseinheit 555 sendet bei Bedarf ein entsprechendes Ergebnis an die Zugriffsverwaltungseinheit 530 zurück (Vorgang ”A8.Zurücksenden”). Wenn umgekehrt der ausgewählte physische Block im Arbeitsbereich 550 gespeichert wird, ändert die Zugriffsverwaltungseinheit 530 den Zugriffsbefehl, indem sie die Adresse des ausgewählten physischen Blocks in dem ausgewählten Software-Abbild 510 durch seine Adresse im Arbeitsbereich 550 ersetzt; die Zugriffsverwaltungseinheit 550 gibt den (geänderten) Zugriffsbefehl dann an eine Arbeitsverwaltungseinheit 560 weiter, die ihn wie vorstehend im Arbeitsbereich 550 ausführt (Vorgang ”A9.Ausführen”). Die Arbeitsverwaltungseinheit 560 sendet bei Bedarf ebenso ein entsprechendes Ergebnis an die Zugriffsverwaltungseinheit 530 zurück (Vorgang ”A10.Zurücksenden”). In beiden Fällen sendet die Zugriffsverwaltungseinheit 530 das Ergebnis der Ausführung des Zugriffsbefehls (sofern vorhanden) über die Zugriffsschnittstelle 525 zurück (Vorgang ”A11.Zurücksenden”).
Ein Abbild-Optimierungsprogramm 565 wird vollständig asynchron (zum Beispiel in regelmäßigen Abständen alle 1 bis 7 Tage) aufgerufen. Das Abbild-Optimierungsprogramm 565 ruft jeden Zugriffsgraphen 540 ab und erzeugt das entsprechende Dendrogramm; alle so erhaltenen Dendrogramme (die als Ganzes mit dem Bezugszeichen 570 versehen sind) werden in einem entsprechenden Archiv gespeichert (Vorgang ”A12.Erzeugen”). Aus jedem Dendrogramm 570 berechnet das Abbild-Optimierungsprogramm 565 die vorhergesagte Abfolge des Zugriffs auf die physischen Blöcke des entsprechenden Software-Abbilds 510; die vorhergesagte Abfolge weist die physischen Blöcke auf, die den Blättern des Dendrogramms 570 entsprechen, wobei die anderen physischen Blöcke des Software-Abbilds 510 (d. h., die physischen Blöcke, die kein entsprechendes Blatt in dem Dendrogramm 570 haben, da auf sie noch nicht zugegriffen worden ist) an dessen Ende hinzugefügt werden (Vorgang ”A13.Berechnen”). Mit einer deutlich höheren Periodizität (zum Beispiel einmal jedes 4. bis 20. Mal, dass das Abbild-Optimierungsprogramm 565 aufgerufen wird – d. h. alle 1 bis 2 Monate) ruft das Abbild-Optimierungsprogramm 656 ein Speicherbereinigungsprogramm (garbage collector) 575 auf; das Speicherbereinigungsprogramm 575 ermittelt die (nicht benutzten) physischen Blöcke, auf die seit seinem letzten Aufruf nicht zugegriffen wurde (was zum Beispiel durch den Zeitpunkt des entsprechenden letzten Zugriffs auf sie angegeben wird). Das Speicherbereinigungsprogramm 575 begrenzt jede vorhergesagte Abfolge, indem es die nicht benutzten physischen Blöcke der Abfolge entfernt, und es löscht die entsprechenden Knoten (bei Bedarf) aus dem entsprechenden Zugriffsgraphen 540 (Vorgang ”A14.Begrenzen”). In jedem Fall prüft das Abbild-Optimierungsprogramm 565 dann für jedes Software-Abbild 510, ob die (möglicherweise begrenzte) vorhergesagte Abfolge deutlich von der aktuellen Anordnung der physischen Blöcke in dem Software-Abbild 510 (das zuvor gespeichert wurde) abweicht – zum Beispiel, wenn ein Defragmentierungsprozentsatz von der aktuellen Anordnung im Vergleich zur vorhergesagten Abfolge einen Schwellwert übersteigt (wie zum Beispiel 10 bis 20%). Wenn ja, gibt das Abbild-Optimierungsprogramm 565 die vorhergesagte Abfolge an ein Abbild-Neuanordnungsprogramm 580 weiter. Als Reaktion darauf ordnet das Abbild-Neuanordnungsprogramm 580 das Software-Abbild 510 gemäß der vorhergesagten Abfolge neu an. Zu diesem Zweck kopiert das Abbild-Neuanordnungsprogramm 580 die physischen Blöcke (nacheinander in der vorhergesagten Abfolge) aus dem Software-Abbild 510 in nachfolgende Speicherplätze des Arbeitsbereichs 550; gleichzeitig aktualisiert das Abbild-Neuanordnungsprogramm 580 die entsprechenden Informationen in der Zuordnungstabelle 545. Sobald das ganze Software-Abbild 510 in den Arbeitsbereich 550 kopiert worden ist (unter dem möglichen Ausschluss seiner nicht benutzten physischen Blöcke), werden die beiden Strukturen ausgelagert und der entsprechende Teil des Arbeitsbereichs 550 gelöscht; gleichzeitig aktualisiert das Abbild-Neuanordnungsprogramm 580 die entsprechenden Informationen in der Zuordnungstabelle 545. Auf diese Weise werden die physischen Blöcke des Software-Abbilds 510 nun gemäß der vorhergesagten Abfolge angeordnet; gleichzeitig ist es möglich, sämtliche unbenutzten physischen Blöcke aus dem Software-Abbild 510 zu entfernen, um seine Größe zu verringern (Vorgang ”A15.Neu anordnen”).
Um lokale und ganz bestimmte Anforderungen erfüllen zu können, kann ein Fachmann an der vorstehend beschriebenen Lösung natürlich viele logische und/oder physische Ab- und Veränderungen vornehmen. Genauer gesagt wurde diese Lösung in Bezug auf eine oder mehrere Ausführungsformen der Lösung zwar mit einem bestimmten Grad an Genauigkeit beschrieben, doch versteht es sich, dass verschiedene Weglassungen, Ersetzungen und Änderungen an der Form und an den Einzelheiten sowie andere Ausführungsformen möglich sind. Insbesondere können verschiedene Ausführungsformen der Erfindung sogar ohne die bestimmten Einzelheiten (wie zum Beispiel die numerischen Werte), die in der vorausgehenden Beschreibung dargelegt wurden, um sie verständlicher zu machen, in die Praxis umgesetzt werden; umgekehrt wurden bekannte Merkmale gegebenenfalls weggelassen oder vereinfacht, damit unnötige Einzelheiten keine Unklarheit bei der Beschreibung aufkommen lassen. Überdies ist ausdrücklich beabsichtigt, dass bestimmte Elemente und/oder Verfahrensschritte, die in Verbindung mit einer beliebigen Ausführungsform der offengelegten Lösung beschrieben wurden, aus Gründen der generellen Ausgestaltungswahl in jede beliebige andere Ausführungsform integriert werden können. In jedem Fall sind die Begriffe ”beinhalten”, ”aufweisen”, ”haben” und ”enthalten” (und sämtliche Formen dieser Begriffe) in einer offenen, nicht ausschließenden Bedeutung (d. h. nicht auf die aufgeführten Ansprüche beschränkt), die Begriffe ”beruhen(d) auf”, ”abhängig von”, ”gemäß”/”entsprechend”, ”Funktion von” (und sämtliche Formen dieser Begriffe) als eine nicht ausschließliche Beziehung (d. h. mit möglichen weiteren eingeschlossenen Variablen) und der Begriff ”ein”/”eine” als ein oder mehrere Positionen oder Gegenstände (soweit nicht ausdrücklich anders angegeben) zu verstehen.
Eine Ausführungsform der Erfindung stellt zum Beispiel ein Verfahren zum Verwalten eines Software-Abbilds (eines beliebigen Typs) bereit; das Software-Abbild wird in einer Vielzahl von physischen Blöcken (beliebiger Größe und beliebigen Formats) eines Speichersystems (eines beliebigen Typs, zum Beispiel optischer Platten) gespeichert. Das Verfahren weist die folgenden Schritte auf. Jeder Zugriff auf die physischen Blöcke wird überwacht (auf beliebige Weise, zum Beispiel mit Hook-Verfahren). Eine vorhergesagte Abfolge des Zugriffs auf die physischen Blöcke wird gemäß den überwachten Zugriffen (mit einem beliebigen Algorithmus) berechnet. Die physischen Blöcke werden dann gemäß der vorhergesagten Abfolge (mit einer beliebigen Häufigkeit, zum Beispiel nach einer vorher festgelegten Anzahl von Zugriffen auf die physischen Blöcke, und auf beliebige Weise, zum Beispiel auch offline) neu angeordnet.
Dieselbe Lösung kann jedoch auch mit einem gleichwertigen Verfahren (indem ähnliche Schritte mit denselben Funktionen oder mehr Schritte oder Teile von Schritten verwendet werden, einige Schritte, die nicht unbedingt nötig sind, entfernt oder weitere optionale Schritte hinzugefügt werden) realisiert werden; überdies können die Schritte in einer anderen Reihenfolge, gleichzeitig oder ineinander verschachtelt (zumindest teilweise) durchgeführt werden.
Bei einer Ausführungsform der Erfindung weist das Verfahren des Weiteren den Schritt des Zugreifens auf die physischen Blöcke durch eine Vielzahl von virtuellen Maschinen auf.
Die virtuellen Maschinen können jedoch auch auf beliebige andere Weise realisiert werden (zum Beispiel von einem Hypervisor gesteuert, der direkt auf der Hardware ohne Betriebssystem des Hostcomputers läuft); in jedem Fall ist dasselbe Verfahren auch für die Anwendung bei physischen Maschinen geeignet.
Bei einer Ausführungsform der Erfindung weist der Schritt des Zugreifens auf die physischen Blöcke durch eine Vielzahl von virtuellen Maschinen das Booten einer jeden virtuellen Maschine von dem Software-Abbild auf.
Die Software-Abbilder können jedoch einfach auch auf virtuellen Maschinen bereitgestellt werden, die bereits gebootet worden sind.
Bei einer Ausführungsform der Erfindung weist der Schritt des Überwachens eines jeden Zugriffs auf die physischen Blöcke das Überwachen eines jeden Zugriffs auf die physischen Blöcke während des Bootens einer jeden virtuellen Maschine von dem Software-Abbild auf.
Die virtuellen Maschinen können jedoch auf jede beliebige Weise von dem Software-Abbild aus booten (zum Beispiel mit einer Streaming-Methode).
Bei einer Ausführungsform der Erfindung weist der Schritt des Überwachens eines jeden Zugriffs auf die physischen Blöcke das Überwachen eines jeden Zugriffs auf die physischen Blöcke durch jede Software-Anwendung auf, die auf den virtuellen Maschinen läuft.
Die Überwachung kann jedoch in nur einer der vorstehend erwähnten Betriebsarten, in beiden der vorstehend erwähnten Betriebsarten oder auf eine beliebige andere Weise erfolgen (zum Beispiel nur für die physischen Blöcke, die nicht für das Betriebssystem des Hostcomputers reserviert sind).
Bei einer Ausführungsform der Erfindung weist der Schritt des Überwachens eines jeden Zugriffs auf die physischen Blöcke das Ermitteln eines Musters des Zugriffs auf die physischen Blöcke gemäß den überwachten Zugriffen auf; der Schritt des Berechnens einer vorhergesagten Abfolge weist dann das Ermitteln der vorhergesagten Abfolge aus dem Zugriffsmuster auf.
Die vorhergesagte Abfolge kann jedoch auch direkt aus den überwachten Zugriffen ermittelt werden, sogar ohne dass eine Zwischenstruktur erzeugt werden muss (zum Beispiel mit Methoden der unscharfen Logik).
Bei einer Ausführungsform der Erfindung weist der Schritt des Ermittelns eines Zugriffsmusters das Aktualisieren eines Zugriffsgraphen auf, der einen Satz von Knoten und einen Satz von Kanten (jede zwischen einem entsprechenden Paar von Knoten) hat; jeder Knoten stellt einen physischen Block und jede Kante eine Wahrscheinlichkeit eines nachfolgenden Zugriffs auf die entsprechenden physischen Blöcke dar.
Der Zugriffsgraph kann jedoch auch eine beliebige andere Struktur haben (zum Beispiel eine Struktur, bei der jede Kante den nachfolgenden Zugriff zwischen den entsprechenden physischen Blöcken in beiden Richtungen darstellt); in jedem Fall kann das Zugriffsmuster auf eine beliebige andere Weise festgelegt werden (zum Beispiel mit einem neuronalen Netzwerk).
Bei einer Ausführungsform der Erfindung weist der Schritt des Ermittelns der vorhergesagten Abfolge aus dem Zugriffsmuster das gruppenweise Zusammenfassen der Knoten zu Communities gemäß den entsprechenden Kanten und das Ermitteln der vorhergesagten Abfolge aus den Communities auf.
Die Communities können jedoch auch mit einem beliebigen anderen Algorithmus (zum Beispiel dem Min-Cut-Verfahren, dem hierarchischen Clustering, der Maximierung der Modularität, der Louvain-Methode oder der auf Clique beruhenden Methode) ermittelt werden.
Bei einer Ausführungsform der Erfindung weist der Schritt des Ermittelns der vorhergesagten Abfolge aus dem Zugriffsmuster das Erzeugen eines Dendrogramms aus dem Zugriffsgraphen auf; das Dendrogramm hat eine Vielzahl von Blättern, die die Knoten des Graphen darstellen, und eine Vielzahl von internen Scheitelpunkten, die die Communities darstellen. Die vorhergesagte Abfolge wird gemäß den Blättern des Dendrogramms ermittelt.
Das Dendrogramm kann jedoch auch auf eine beliebige andere Weise erzeugt werden, sogar ohne dass ein Zugriffsgraph erzeugt wird (zum Beispiel entweder mit einer Vorgehensweise von unten nach oben (bottom-up) oder von oben nach unten (top-down)); in jedem Fall kann die vorhergesagte Abfolge auch ermittelt werden, ohne dass ein Dendrogramm erzeugt wird.
Bei einer Ausführungsform der Erfindung weist das Verfahren des Weiteren die Schritte des Ermittelns eines Satzes von nicht benutzten physischen Blöcken gemäß den überwachten Zugriffen und das Entfernen der nicht benutzten physischen Blöcke aus dem Software-Abbild auf.
Die nicht benutzten physischen Blöcke können jedoch auch auf eine beliebige andere Weise ermittelt werden (zum Beispiel indem nur die physischen Blöcke berücksichtigt werden, auf die noch nie zugegriffen worden ist); in jedem Fall wird auch eine Realisierung derselben Lösung ohne Speicherbereinigung in Erwägung gezogen.
Eine Ausführungsform der Erfindung stellt ein Computerprogramm bereit, das ein Code-Mittel aufweist, welches ein Datenverarbeitungssystem (zum Beispiel das vorstehend beschriebene Datenverarbeitungszentrum) zur Durchführung der Schritte des vorgeschlagenen Verfahrens veranlasst, wenn das Computerprogramm auf dem System ausgeführt wird.
Das Programm kann jedoch auch als ein eigenständiges Modul, als Zusatzprogramm (Plug-in) für das Bereitstellungs-Tool oder sogar direkt in dem Bereitstellungs-Tool selbst realisiert werden. Es dürfte ohne Weiteres erkennbar sein, dass es auch möglich ist, dieselbe Lösung als Dienst einzusetzen, auf den über ein Netzwerk (wie zum Beispiel das Internet) zugegriffen wird. In jedem Fall gelten ähnliche Überlegungen, wenn das Programm anders strukturiert ist oder wenn zusätzliche Module oder Funktionen zur Verfügung gestellt werden; ebenso kann es andere Arten von Speicherstrukturen geben, oder die Speicherstrukturen können durch gleichwertige Einheiten (die nicht unbedingt aus physischen Speichermedien bestehen müssen) ersetzt werden. Das Programm kann eine beliebige Form annehmen, die zur Verwendung durch ein beliebiges Datenverarbeitungssystem oder in Verbindung damit (zum Beispiel in einer virtuellen Maschine) geeignet ist, wobei das System dabei so konfiguriert wird, dass es die gewünschten Operationen durchführt; insbesondere kann das Programm die Form von externer oder residenter Software, Firmware oder externen oder residenten Mikrocodes (entweder in Form von Objektcode oder Quellcode, der beispielsweise kompiliert oder interpretiert werden muss) vorliegen. Überdies ist es möglich, das Programm auf einem beliebigen von einem Computer nutzbaren Medium (und insbesondere als Herstellungsartikel auf einem übergangslosen Medium) bereitzustellen; bei dem Medium kann es sich um ein beliebiges Element handeln, das geeignet ist, das Programm aufzunehmen, zu speichern, zu übertragen, weiterzugeben oder zu übermitteln. Das Medium kann zum Beispiel vom elektronischen, magnetischen, optischen, elektromagnetischen, Infrarot- oder Halbleitertyp sein; Beispiele für solche Medien sind Festplatten (auf die das Programm vorab geladen werden kann), austauschbare Datenträger, Bänder, Karten, Leitungen, Glasfasern, drahtlose Verbindungen, Netzwerke, Rundfunkwellen und dergleichen. In jedem Fall bietet sich die Lösung gemäß einer Ausführungsform der vorliegenden Erfindung selbst für die Realisierung mit einer Hardware-Struktur (zum Beispiel in einen Chip aus Halbleitermaterial integriert) oder mit einer Kombination aus Software und Hardware an, die in geeigneter Weise programmiert oder auf andere Weise konfiguriert ist.
Eine Ausführungsform der Erfindung stellt ein Datenverarbeitungssystem (zum Beispiel das vorstehend beschriebene Datenverarbeitungszentrum) bereit, das ein Mittel zur Durchführung der Schritte desselben Verfahrens aufweist.
Ähnliche Überlegungen gelten jedoch, wenn das Datenverarbeitungssystem eine andere Struktur hat oder gleichwertige Komponenten aufweist oder wenn es andere operative Merkmale hat. In jedem Fall kann jede Komponente davon in weitere Elemente aufgeteilt oder zwei oder mehr Komponenten können zu einem einzigen Element zusammengeführt werden; überdies kann jede Komponente repliziert werden, um die parallele Ausführung der entsprechenden Operationen zu unterstützen. Es wird auch darauf hingewiesen, dass (sofern nichts anderes angegeben ist) jedwede Wechselwirkung zwischen verschiedenen Komponenten im Allgemeinen nicht fortlaufend sein muss und dass sie entweder direkt oder indirekt über einen oder mehrere Vermittler stattfinden kann. Genauer gesagt kann dasselbe Verfahren auch in einem Datenverarbeitungssystem ausgeführt werden, das auf einer anderen Architektur (zum Beispiel einem lokalen Netzwerk, einem Weitverkehrsnetz, einem globalen Netzwerk, einem Funk- oder Satellitennetzwerk) beruht und jede beliebige Art von (verdrahteten und/oder drahtlosen) Verbindungen verwendet; überdies ist auch seine Realisierung auf einem eigenständigen Computer nicht ausgeschlossen. In jedem Fall kann jeder Computer des Datenverarbeitungszentrums eine andere Struktur haben oder ähnliche Elemente aufweisen (wie zum Beispiel Cachespeicher, die die Programme oder Teile davon vorübergehend speichern); ferner ist es möglich, den Computer durch eine beliebige Code-Ausführungseinheit, die entweder auf einer physischen Maschine oder auf einer virtuellen Maschine beruht (wie zum Beispiel ein persönlicher digitaler Assistent (PDA), ein Mobiltelefon und dergleichen), oder durch eine Kombination aus mehreren Einheiten (wie zum Beispiel eine mehrschichtige Architektur, eine Grid-Computing-Infrastruktur und dergleichen) zu ersetzen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2006/0155735 A [0004]

Claims

Verfahren (A1 bis A15) zum Verwalten eines Software-Abbilds, das in einer Vielzahl von physischen Blöcken eines Speichersystems gespeichert wird, wobei das Verfahren die Schritte aufweist: Überwachen (A4 bis A5) eines jeden Zugriffs auf die physischen Blöcke, Berechnen (A12 bis A13) einer vorhergesagten Abfolge des Zugriffs auf die physischen Blöcke gemäß den überwachten Zugriffen und Neuanordnen (A14 bis A15) der physischen Blöcke gemäß der vorhergesagten Abfolge.
Verfahren (A1 bis A15) nach Anspruch 1, das des Weiteren den Schritt aufweist: Zugreifen (A3) auf die physischen Blöcke durch eine Vielzahl von virtuellen Maschinen.
Verfahren (A1 bis A15) nach Anspruch 2, wobei der Schritt des Zugreifens (A3) auf die physischen Blöcke durch eine Vielzahl von virtuellen Maschinen aufweist: Booten (A3) einer jeden virtuellen Maschine von dem Software-Abbild.
Verfahren (A1 bis A15) nach Anspruch 3, wobei der Schritt des Überwachens (A4 bis A5) eines jeden Zugriffs auf die physischen Blöcke aufweist: Überwachen (A4) eines jeden Zugriffs auf die physischen Blöcke während des Bootens einer jeden virtuellen Maschine von dem Software-Abbild.
Verfahren (A1 bis A15) nach einem der Ansprüche 2 bis 4, wobei der Schritt des Überwachens (A4 bis A5) eines jeden Zugriffs auf die physischen Blöcke aufweist: Überwachen (A4) eines jeden Zugriffs auf die physischen Blöcke durch jede Software-Anwendung, die auf den virtuellen Maschinen ausgeführt wird.
Verfahren (A1 bis A15) nach einem der Ansprüche 1 bis 5, wobei der Schritt des Überwachens (A4 bis A5) eines jeden Zugriffs auf die physischen Blöcke aufweist: Ermitteln (A5) eines Musters des Zugriffs auf die physischen Blöcke gemäß den überwachten Zugriffen, und wobei der Schritt des Berechnens (A12 bis A13) einer vorhergesagten Abfolge aufweist: Ermitteln (A12 bis A13) der vorhergesagten Abfolge aus dem Zugriffsmuster.
Verfahren (A1 bis A15) nach Anspruch 6, wobei der Schritt des Ermittelns (A4 bis A5) eines Zugriffsmusters aufweist: Aktualisieren (A5) eines Zugriffsgraphen, der einen Satz von Knoten und einen Satz von Kanten hat, von denen sich jede zwischen einem entsprechenden Paar von Knoten befindet, wobei jeder Knoten einen physischen Block und jede Kante eine Wahrscheinlichkeit eines nachfolgenden Zugriffs auf die entsprechenden physischen Blöcke darstellt.
Verfahren (A1 bis A15) nach Anspruch 7, wobei der Schritt des Ermittelns (A12 bis A13) der vorhergesagten Abfolge aus dem Zugriffsmuster aufweist: gruppenweises Zusammenfassen (A12) der Knoten zu Communities gemäß den entsprechenden Kanten und Ermitteln (A13) der vorhergesagten Abfolge aus den Communities.
Verfahren (A1 bis A15) nach Anspruch 8, wobei der Schritt des Ermittelns (A12 bis A13) der vorhergesagten Abfolge aus dem Zugriffsmuster aufweist: Erzeugen (A12) eines Dendrogramms aus dem Zugriffsgraphen, wobei das Dendrogramm eine Vielzahl von Blättern hat, die die Knoten des Graphen darstellen, und eine Vielzahl von internen Scheitelpunkten, die die Communities darstellen, und Setzen (A13) der vorhergesagten Abfolge gemäß den Blättern des Dendrogramms.
Verfahren (A1 bis A15) nach einem der Ansprüche 1 bis 9, das des Weiteren die Schritte aufweist: Ermitteln (A14) eines Satzes von nicht benutzten physischen Blöcken gemäß den überwachten Zugriffen und Entfernen (A15) der nicht benutzten physischen Blöcke aus dem Software-Abbild.
Computerprogramm (500), das ein Code-Mittel aufweist, welches ein Datenverarbeitungssystem (100) dazu veranlasst, die Schritte des Verfahrens (A1 bis A15) nach einem der Ansprüche 1 bis 10 durchzuführen, wenn das Computerprogramm in dem System ausgeführt wird.
Datenverarbeitungssystem (100), das ein Mittel (500) aufweist, welches die Schritte des Verfahrens (A1 bis A15) nach einem der Ansprüche 1 bis 10 durchführt.