-
HINTERGRUND
-
Technisches Gebiet
-
Die vorliegende Erfindung betrifft die effiziente Zusammenarbeit von Computertechnologien und genauer Systeme und Verfahren zum Neuordnen von Speicherebenen für die virtuelle und dynamische Ressourcenzuweisung für speicherintensive Anwendungen.
-
Beschreibung des Standes der Technik
-
Aufkommende Dienstanwendungen im Internetumfeld arbeiten an großen Datenmengen, die im Speicher aufrecht erhalten werden, um einen hohen Durchsatz zu erreichen und Benutzern Garantien über kurze Reaktionszeiten bieten zu können. Hauptkatalysatoren dieser Entwicklung waren der erhebliche Verfall der Speicherkosten, der Anstieg der Speicherkapazität in Maschinen sowie die Entwicklung und Einführung von arbeitsspeicherinternen verteilten Speichertechnologien wie memcached, XAP und ObjectGrid™. In der Folge wurden arbeitsspeicherinterne Datengitter (in-Memory Data Grids, IMDGs) zu kosten- und leistungswirksamen Lösungen für eine derartige umfangreiche und verteilte Datenbereitstellung. Somit stützen sich viele Unternehmen im Internetbereich wie Facebook™ und Twitter™ auf irgendeine Form solcher arbeitsspeichergestützter Datengitter für einen Betrieb bei gleichzeitigem Skalieren an eine große Anzahl von Benutzern.
-
Facebook™ speichert zum Beispiel seine gesamten Indexierungsinformationen auf einem memcached, um den Zugriff auf große Objekte von nachgelagerten Speicherservern rechtzeitig zu beschleunigen. Andere nicht herkömmliche datenorientierte Anwendungen, z.B. die Betrugserkennung, stützen sich auf IMDG, um Betriebsdaten online zu sammeln und zu analysieren.
-
Virtualisierungstechnologien werden in umfangreichen Datenzentren und Cloud-Infrastrukturen immer wichtiger. Über die vereinfachte Verwaltung und Bereitstellungsvorteile hinaus ermöglichen diese virtualisierten Umgebungen dynamische Optimierungen am Cloud-Betrieb, indem verteilte Ressourcen dynamisch den laufenden virtualisierten Einheiten zugewiesen werden. Durch Neupositionieren und Neubereitstellen virtueller Maschinen (VMs) bieten virtualisierte Umgebungen flexible Laufzeitreaktionen auf sich dynamisch verändernde Anforderungen von Datenzentren. Dies verringert die Ineffizienzen des bestehenden Infrastrukturmodells statistisch zugewiesener Informationstechnologie (IT) aufgrund starker Überbereitstellung und ineffizienter Unternutzung von Computerressourcen.
-
Während sich diese beiden Entwicklungen ausschließlich in ihren Bereichen als wirksam erwiesen haben und weiterhin zunehmend an Dynamik gewinnen, zeigen sie einen offenkundigen Konflikt in ihren Eigenschaften, der ihre Wirksamkeit bei gemeinsamem Betrieb in einer Cloud-Umgebung beeinträchtigen kann. Genauer profitieren IMDG-Lösungen einerseits von der Nutzung großer Mengen an Speicher mit wahlfreiem Zugriff (RAM), um Daten zu verwalten, und neigen daher für einen wirksamen Betrieb zu starker Speichernutzung.
-
Andererseits funktioniert dynamische VM-Zuweisung bei der Virtualisierung am besten, indem während der VM-Neuzuweisung so wenig Live-Zustände wie möglich zwischen den physischen Einheiten übertragen werden. Es ist bekannt, dass eine starke positive Korrelation besteht zwischen der Menge von Live-Zuständen, die eine VM besitzt, und dem Migrationsaufwand, der auftreten kann. Die Hauptbeiträge zum Live-Zustand stellen die Menge „aktiven Speichers“ oder die Arbeitssatzgröße der VM, die Geschwindigkeit, mit der die Seiten im Speicher verschmutzt werden und der Gesamtressourcenbedarf der VM dar. Daher wird die dynamische Reaktionseffizienz negativ beeinträchtigt, während VMs mit starker Speichernutzung zugewiesen werden. Dies hat mindestens zwei negative Auswirkungen: (1) ein höherer durch die IMDG verwendenden Anwendungen wahrgenommener Leistungsaufwand, da die Reaktionszeiten unter dynamischen Zuweisungsbedingungen ansteigen; und (2) Energieaufwand aufgrund ausgedehnten Kopierens und Neukopierens des Live-Zustands sowie eine höhere Ressourcen- und Verbindungsauslastung.
-
Das Dokument von Voolslurys, W. et al.: Cost of Virtual Machine Life Migration: A Performance Evaluation, In: Proceedings of the First Internationals Conference, CloudCom 2009, Bejing, China, December 2009, LNCS5931, Springer-Verlag Berlin Heidelberg, S.254 - 265, das sich mit den oben genannten Gegebenheiten auseinandersetzt, beschreibt Effekte von Life-Migrationen von virtuellen Maschinen in Bezug auf die Performance von Anwendungen, die in XEN VMs laufen.
-
Folglich besteht eine Aufgabe der vorliegenden Erfindungen darin, die genannten Nachteile zu überwinden und ein effektiveres Live-Migrationsverfahren und ein entsprechendes System vorzuschlagen.
-
ZUSAMMENFASSUNG
-
Migrationslatenzzeiten hängen von einem aktiven Ressourcenbedarf einer virtuellen Maschine (VM) ab, zum Beispiel führt eine 16fache Steigerung des aktiven Speichers zu einer nahezu 32fachen Steigerung des gesamten Migrationsaufwandes. Die entsprechende CPU- und Speicherauslastung während dieser Migrationen zeigen einen durchschnittlichen Einzelkern-CPU-Aufwand von 40 % beim Migrieren einer VM von einem Quell-Host sowie einen CPU-Aufwand von ungefähr 20 % beim Migrieren einer VM zu einem Ziel-Host. In beiden Richtungen kann während der Migration durch den Migrationsdatenverkehr eine Sättigung von 1-Gbit/s-Verbindungen eintreten. Ziemlich deutliche Verschlechterungen können zudem in der Anwendungsleistung, wie beispielsweise den Bearbeitungszeiten, abhängig von den Eigenschaften der Anwendung und dem Ausmaß der Überfestschreibung auf dem Host beobachtet werden. Daher wird eine effiziente, die Migration berücksichtigende Zustandsverwaltung sowohl aus Sicht der Ressourcenverwaltungstechnologie als auch der Anwendungsleistungs-Verwaltungstechnologie benötigt. Die vorliegenden Grundgedanken stellen für die hochwirksame Zusammenarbeit dieser beiden wachsenden Technologien ein Verfahren zur die Virtualisierung und die dynamische Ressourcenzuweisung berücksichtigenden Speicherebenenneuordnung (virtualization- and dynamic-resource-allocation-aware storage level reordering VSLR) für speicherintensive Anwendungen wie ein arbeitsspeicherinternes Datengitter (IMDGs) bereit. Da beide Technologien in ähnlichen umfangreichen Computer- und Cloud-gestützten Infrastrukturen zunehmend verbreitet sind, stellt eine solche Zusammenarbeit eine Kooperation zwischen diesen Technologien und anderen bereit.
-
Die oben genannte Aufgabe wird durch die unabhängigen Ansprüche gelöst. Weitere Ausgestaltungen ergeben sich aus den jeweils abhängigen Ansprüchen.
-
Diese und andere Merkmale und Vorteile werden anhand der folgenden detaillierten Beschreibung veranschaulichender Ausführungsformen davon ersichtlich, die in Verbindung mit den angehängten Zeichnungen zu lesen ist.
-
Figurenliste
-
Die Offenbarung stellt Einzelheiten in der folgenden Beschreibung bevorzugter Ausführungsformen unter Bezugnahme auf die folgenden Figuren bereit, wobei:
- 1 ein Blockdiagramm/einen Ablaufplan zeigt, das/der eine Computerumgebung mit einer veranschaulichenden Migration einer virtuellen Maschine (VM) gemäß den vorliegenden Grundgedanken darstellt;
- 2 ein Blockdiagramm/einen Ablaufplan zeigt, das/der ein System/Verfahren zum Neupositionieren von VMs gemäß den vorliegenden Grundgedanken darstellt; und
- 3 ein Blockdiagramm/einen Ablaufplan zeigt, der ein System/Verfahren zur Zusammenarbeit zwischen Technologien zum Ausführen einer Veränderung in einer virtualisierten Umgebung gemäß einer weiteren Ausführungsform zeigt.
-
DETAILLIERTE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
-
Die vorliegenden Grundgedanken stellen ein System mit einer Datenspeicherung mit mehreren Ebenen bereit, das ein Speichermedium mit niedrigen Latenzzeiten/einer hohe Bandbreite, z.B. RAM, und ein Speichermedium mit höheren Latenzzeiten/einer niedrigeren Bandbreite, z.B. eine Festplatte, aufweist, die in hierarchischer Weise betrieben werden. Im Kontext von zum Beispiel Anwendungen arbeitsspeicherinterner Datengitter (IMDG) wird eine Speicherebene mit dem besten Verhältnis von Latenz zu Größe als primär angesehen und besitzt daher die höchste Priorität in der Hierarchie. Zum Beispiel arbeiten IMDG-Technologien wie ObjectGrid™ hauptsächlich auf dem RAM und stützen sich auf Festplattenspeicher, um auf Überlaufsituationen zu reagieren.
-
Ein Modul zur die Virtualisierung und die dynamische Ressourcenzuweisung berücksichtigenden Speicherebenenneuordnung (VSLR) erlaubt es Anwendungen wie IMDGs, mit einem virtuellen Ressourcenverwalter (VRM) des Systems zusammenzuarbeiten, um den von der Migration virtueller Maschinen (VMs) stammenden Aufwand zu verringern, indem die Live-Zustands-Daten einer beherbergenden, zu migrierenden VM wirksam verringert werden. Das Verringern des aktiven Zustands dieser Anwendungen kann zu mehreren Ordnungen beim Verringern des Aufwandes der dynamischen Ressourcenzuweisung führen.
-
Hierzu ordnen IMDG-Knoten die Speicherhierarchieebenen bei Migration der beherbergenden VM neu, indem RAM auf sekundären Speicher zurückgestuft wird und niedrigere Speicherebenen in der Hierarchie heraufgestuft werden. Mit anderen Worten, IMDG-Knoten sind in der Lage, während ihrer Lebensdauer entsprechend den Vorgaben durch ein VSLR-Verwaltungssystem mit unterschiedlichen Ebenen der Speicherhierarchie zu interagieren. Weiterhin wird im VSLR durch die Anwendung (IMDG) und den Ressourcenverwalter gemeinsam die Ordnung ermittelt, so dass die Anforderungen von Anwendung und System beide erfüllt sind.
-
Durch Einführen von VSLR kann ein Cloud-Anbieter zum Beispiel das Bereitstellen und Neupositionieren von Ressourcen wirksam verwalten und dabei die Anforderungen von Cloud-Diensten erfüllen, die sich stark auf IMDG-Lösungen stützen, um verteilte Daten unter Beschränkungen hoher Reaktionszeiten zu verwalten. Das Problem des Verwaltens von Diensten wie IMDG in einer virtuellen Umgebung wird von keiner bekannten Lösung behoben.
-
Wie für den Fachmann ersichtlich ist, können Aspekte der vorliegenden Erfindung als System, Verfahren, oder Computerprogrammprodukt ausgebildet werden. Dementsprechend können Aspekte der vorliegenden Erfindung in Form einer vollständigen Hardware-Ausführungsform, einer vollständigen Software-Ausführungsform (darunter Firmware, residente Software, Mikrocode usw.) oder in einer Ausführungsform ausgebildet werden, die Software- und Hardware-Aspekte kombiniert, was hierin sämtlich allgemein als „Schaltung“, „Modul“ oder „System“ bezeichnet sein kann. Weiterhin können Aspekte der vorliegenden Erfindung in Form eines Computerprogrammprodukts ausgebildet werden, das in einem oder mehreren computerlesbaren Medien mit darauf befindlichem computerlesbaren Programmcode enthalten sein kann.
-
Jede beliebige Kombination aus einem oder mehreren computerlesbaren Medien kann verwendet werden. Bei dem computerlesbaren Medium kann es sich um ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium handeln. Bei einem computerlesbaren Speichermedium kann es sich zum Beispiel, ohne darauf beschränkt zu sein, um ein System, eine Vorrichtung oder eine Einheit elektronischer, magnetischer, optischer, elektromagnetischer, Infrarot verwendender oder Halbleiter verwendender Art sowie eine beliebige geeignete Kombination des zuvor Genannten handeln. Zu spezielleren Beispielen für das computerlesbare Speichermedium kann Folgendes gehören (nicht erschöpfende Liste): eine elektrische Verbindung mit einer oder mehreren Leitungen, eine transportable Computerdiskette, eine Festplatte, ein Speicher mit wahlfreiem Zugriff (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein transportabler Compact-Disk-Nur-Lese-Speicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder eine beliebige geeignete Kombination des zuvor Genannten. Im Kontext dieses Dokuments kann es sich bei einem computerlesbaren Speichermedium um jedes gegenständliche Medium handeln, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Ausführung von Anweisungen beinhalten oder speichern kann.
-
Ein computerlesbares Signalmedium kann ein ausgebreitetes Datensignal beinhalten, bei dem der computerlesbare Programmcode zum Beispiel in einem Basisbandsignal oder als Teil eines Trägerwellensignals ausgebildet ist. Solch ein ausgebreitetes Signal kann in jeder beliebigen einer Vielzahl von Formen ausgebildet werden, wie beispielsweise, jedoch nicht beschränkt auf elektromagnetische, optische oder jede geeignete Kombination davon. Bei einem computerlesbaren Signalmedium kann es sich um ein beliebiges computerlesbares Medium handeln, das kein computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Ausführung von Anweisungen übertragen, verbreiten oder transportieren kann.
-
Der in einem computerlesbaren Medium ausgebildete Programmcode kann mittels jedes beliebigen geeigneten Mediums übertragen werden, darunter, jedoch nicht beschränkt auf, kabellose, kabelgebundene, Lichtwellenleiterkabel, HF usw., oder einer beliebigen geeigneten Kombination des zuvor Genannten. Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in jeder Kombination einer oder mehrerer Programmiersprachen, darunter eine objektorientierte Programmiersprache wie Java, Smalltalk, C++ oder Ähnliches und herkömmliche verfahrensorientierte Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen geschrieben sein. Der Programmcode kann vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Softwarepaket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers über jede beliebige Art von Netzwerk, darunter ein Nahbereichsnetzwerk (LAN) oder ein Weitbereichsnetzwerk (WAN) verbunden sein, oder es kann eine Verbindung zu einem externen Computer (zum Beispiel mittels eines Internetdienstanbieters über das Internet) hergestellt werden.
-
Aspekte der vorliegenden Erfindung werden nachfolgend unter Bezugnahme auf Abbildungen von Ablaufplänen und/oder Blockdiagrammen von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß den Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Abbildungen von Ablaufplänen und/oder der Blockdiagramme sowie Kombinationen von Blöcken in den Abbildungen von Ablaufplänen und/oder den Blockdiagrammen durch Computerprogrammanweisungen realisiert werden kann. Diese Computerprogrammanweisungen können einem Prozessor eines universellen Computers, eines zweckbestimmten Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine so zu erzeugen, dass die Anweisungen, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, ein Mittel zum Realisieren der im Block oder in den Blöcken des Ablaufplans und/oder Blockdiagramms angegebenen Funktionen/Handlungen erzeugen.
-
Diese Computerprogrammanweisungen können auch in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anleiten kann, auf eine bestimmte Weise zu funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Anweisungen einen Herstellungsartikel einschließlich Anweisungen erzeugen, welche die im Block oder in den Blöcken des Ablaufplans und/oder des Blockdiagramms angegebenen Funktionen/Handlungen ausführen. Die Computerprogrammanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten geladen werden, um eine Reihe von auf dem Computer, der anderen programmierbaren Vorrichtung oder den anderen Einheiten auszuführenden Operationsschritten hervorzurufen, um einen auf dem Computer realisierten Prozess so zu erzeugen, dass die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführten Anweisungen Prozesse zum Realisieren der im Block oder in den Blöcken des Ablaufplans und/oder Blockdiagramms angegebenen Funktionen/Handlungen bereitstellen.
-
Die Ablaufpläne und Blockdiagramme in den FIG. veranschaulichen die Architektur, Funktionalität und die Arbeitsweise möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß vielfältigen Ausführungsformen der vorliegenden Erfindung. In dieser Hinsicht kann jeder Block im Ablaufplan oder den Blockdiagrammen für ein Modul, ein Segment oder einen Codeabschnitt stehen, der eine oder mehrere ausführbare Anweisungen zum Realisieren der angegebenen logischen Funktion oder Funktionen aufweist. Es soll zudem angemerkt werden, dass bei einigen alternativen Realisierungen die im Block angegebenen Funktionen in anderer Reihenfolge als der in den Figuren angegebenen auftreten können. Zum Beispiel können zwei aufeinanderfolgend abgebildete Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können manchmal abhängig von der betreffenden Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es wird ebenfalls angemerkt, dass jeder Block der Blockdiagramme und/oder Abbildung von Ablaufplänen und Kombinationen von Blöcken in den Blockdiagrammen und/oder Abbildung von Ablaufplänen durch zweckbestimmte hardwaregestützte Systeme oder Kombinationen von zweckbestimmter Hardware und Computeranweisungen realisiert werden kann, welche die angegebenen Funktionen oder Handlungen durchführen.
-
Unter Bezugnahme auf die Zeichnungen, in denen gleiche Bezugszeichen für dieselben oder ähnliche Elemente stehen, und zunächst unter Bezugnahme auf 1, wird nun ein System 100 und ein Verfahren für eine Umgebung mit zusammenarbeitender Technologie veranschaulichend dargestellt. Das System 100 weist veranschaulichend eine virtuelle Umgebung mit fünf Hauptkomponenten auf: physische Maschinen 102, 104, virtuelle Maschinen 106, einen virtuellen Ressourcenverwalter (VRM) 110, ein Modul zur die Virtualisierung und die dynamische Ressourcenzuweisung berücksichtigenden Speicherebenenneuordnung (VSLR) 112 und einen Speicherressourcenverwalter (SRM) 114. Anwendungen 116 werden durch einzelne VMs 106 beherbergt und die physischen Maschinen 102, 104 können mehrere VMs 106 beherbergen. Jede VM 106 besitzt einen Anteil an Ressourcen (Netzwerk, Speicher und CPU), welcher der VM 106 zur Startzeit zugewiesen wurde, und teilt Ressourcen mit anderen VMs 106, die in derselben physischen Maschine 102, 104 mit beherbergt werden. Das VSLR-System 100 zeigt veranschaulichend zwei physische Maschinen: eine Ausgangsmaschine 102 und eine Zielmaschine 104, die mehrere VMs 106 beherbergen. Die Ausgangsmaschine 102 beherbergt eine VM 106 (VM1) mit einem IMDG-Knoten 118, der auf das Ziel 104 migriert werden soll.
-
Der SRM 114 ist für das Überwachen der Speichernutzung in der Speicherhierarchie im System 100 verantwortlich. Der SRM 114 baut Profiinformationen für die Speicherung und Speichereinheiten auf und stellt die Profilinformationen dem VRM 110 zur Verfügung. Der VRM 110 ist verantwortlich für das Treffen von Entscheidungen hinsichtlich des Neupositionierens (Migration) und Neubereitstellens virtueller Maschinen 106, das Koordinieren mit dem VSLR-Modul 112 und dem SRM 114, falls erforderlich, und das Ermitteln einer neuen Speicherebenenordnung für einen IMDG (118), der zu verwenden ist, wenn seine beherbergende VM (106) für ein mögliches Neupositionieren ausgewählt wurde. Der VRM 110 und Hypervisors 120 sind die einzigen Komponenten, die Entscheidungen zur dynamischen Ressourcenverwaltung berücksichtigen müssen. Die VSLR-Module 112 und die VMs 106 müssen lediglich die dynamischen Speicherebenen-Neuordnungsempfehlungen empfangen, ohne notwendigerweise Kenntnis der zugrundeliegenden Virtualisierungsschicht zu haben.
-
Das VSLR-Modul 112 spielt eine Vermittlerrolle zwischen den IMDG-Knoten 118 und dem VRM 110. Das VSLR-Modul 112 kann als Agent oder als Hilfs-VM 106 in jedem Host 102 oder 104 realisiert werden. Das VSLR-Modul 112 ist verantwortlich für das Informieren der IMDG-Knoten 118 über die Speicherebenen-Neuordnungsempfehlungen und das Berichten der durch jeden Knoten verwendeten Speicherebenenordnungen an den VRM 110.
-
Während einer Migration führt das System 100 die folgenden veranschaulichenden Funktionen durch, die in 1 durch eingekreiste Zahlen gekennzeichnet sind: (1) der VRM 110 informiert das VSLR-Modul 112 darüber, dass die VM1 für die Migration ausgewählt wurde, und schlägt eine neue Speicherebenenordnung für den in der VM1 (in diesem Fall nur Festplatte) beherbergten IMDG-Knoten 118 vor. (2) das VSLR-Modul 112 übermittelt die neue Speicherebenen-Ordnungsempfehlung an den IMDG-Behälter 122 in der VM1; (3) das IMDG 118 befolgt die neue Ordnung und geht in den die Zuweisung berücksichtigenden Modus über und schreibt für alle zukünftigen eingehenden Transaktionen auf eine Festplatte 126; (4) die Migration der VM1 beginnt und endet; (5) das IMDG 118 geht optional in einen Wiederherstellmodus über und synchronisiert die Ausgangsmaschine 102 und die Zielmaschine 104, falls erforderlich, indem sie während der Migration festgeschriebene Transaktionen ausführt; der VRM 110 empfiehlt ein Rückkehren der Speicherebenenordnung in den Normalmodus über das VSLR-Modul 112.
-
Die vorliegenden Ausführungsformen sind insbesondere für arbeitsspeicherinterne intensive Anwendungen, z.B. memcached, ObjectGrid™ usw. nützlich. Die vorliegende Realisierung variiert jedoch abhängig von der Anwendung. Die vorstehende Realisierung beruht auf dem Kontext von ObjectGrid™ (IBM IMDG). ObjectGrid™ besitzt integrierte Fähigkeiten, mit verschiedenen Speichereinheiten 130 über ein Ladermodul 124 zu interagieren, das in die physischen Einheiten 102, 104 (z.B. Server) eingebettet ist, weshalb es eine ideale veranschaulichende Wahl für diese Offenbarung darstellt. Andere Ausgestaltungen und Kontexte werden ebenfalls betrachtet.
-
Wann immer eine VM für eine Neupositionierung gekennzeichnet wurde, informiert der VRM 110 das VSLR-Modul 112 in der Ausgangsmaschine 102 und schlägt eine neue Speicherebenenordnung vor, die Profilinformationen folgt, die vom SRM 114 erhalten wurden (siehe eingekreiste 1). Das VSLR-Modul 112 informiert dann den in der ausgewählten VM beherbergten IMDG-Knoten 118 über die empfohlene Speicherordnung.
-
Sobald der VRM 110 eine gegebene VM 106, die eine IMDG-Anwendung 116 beherbergt, für eine Neupositionierung auswählt, erhält der VRM 110 Speicherprofilinformationen vom SRM 114. Zum Beispiel kann der VRM 110 die aktuelle Lese/Schreib-Anfragerate der lokalen Festplatte 126 oder die aktuelle Auslastung der mit der Ausgangsmaschine 102 verbundenen Flash-Speicherkarte erhalten. Der VRM 110 schlägt mithilfe dieser Informationen dem entsprechenden VSLR-Modul 112 eine neue durch den IMDG-Knoten 118 zu verwendende Speicherebenenordnung vor. Wird zum Beispiel angenommen, dass die Ausgangsmaschine 102 Zugriff auf einen entfernt angeordneten gemeinsam genutzten Speicher 130 und einen lokalen Speicher 126 besitzt, kann der VRM 110 den entfernt angeordneten Speicher als Primärspeicher vorschlagen, wenn seine effektive Bandbreite oberhalb eines bestimmten Schwellenwerts liegt, und die lokale Festplatte 126 oder den Hauptspeicher (nicht gezeigt) verwenden, um mit Überlaufsituationen umzugehen.
-
Eine Stärke der vorliegenden Grundgedanken rührt vom Durchführen dieses Speicherebenenneuordnens in einer die Virtualisierung berücksichtigenden Weise her. Bei vielen vorhandenen virtualisierten Infrastrukturen wird ein gemeinsam genutzter externer Speicher in Form eines Speicherbereichsnetzwerks (storage area network SAN) oder netzwerkverbundenen Speichers (network-attached storage NAS) verwendet, um die virtuellen Festplatten der VMs 106 zu unterstützen. Eine virtuelle Festplatte der zu migrierenden IMDG-VM 118 kann sich wahrscheinlich auf einem derartigen externen Speicher (130) befinden. In diesem Fall erleichtert das Heraufstufen der Festplatte der VM zum Primärspeicher die Anforderung, jeden Live-Zustand zu transferieren, da alle weiteren Aktualisierungen nach der Migration für die VM direkt sichtbar sind, da der Festplattenspeicherort der VM unverändert bleibt und von Hosts gemeinsam genutzt wird. Bei diesem Vorgang trägt das VSLR-Modul 112 dazu bei, die IMDGs 118 in virtualisierten Umgebungen effizient zu verwalten, indem der Aufwand von Maßnahmen der dynamischen Ressourcenzuweisung der zugrundeliegenden Virtualisierungsverwaltungsschicht erheblich verringert wird. Der gesamte IMDG-Betrieb wird im Gegensatz zum Neuordnen von Speicherebenen mit minimaler Unterbrechung fortgesetzt. Wie von den vorliegenden Erfindern gezeigt, stellt gemeinsam genutzter Speicher nichtsdestoweniger keine begrenzende Notwendigkeit für die dynamische Ressourcenzuweisung dar. Es ist wichtiger, dass Anwendungen mit hohen Datenortanforderungen - wie Mapreduce™ und Datenanalysen - stark von der Verwendung von VMs mit verbundenem Speicher profitieren. Unter solchen Bedingungen können VMs mit getrenntem Speicher zwischen Hosts migriert werden.
-
Um diese Fälle allgemein mit einzubeziehen, führen die vorliegenden Ausführungsformen einen separaten IMDG-Betriebsmodus für die Wiederherstellung nach einer Ressourcenzuweisung ein. Für ein dynamisches Neuordnen von Speicherebenen kann davon ausgegangen werden, dass der IMDG-Knoten 118 die vom VSLR-Modul 112 vorgeschlagene Ordnung übernimmt. Nichtsdestoweniger kann diese Voraussetzung leicht gelockert werden, um intelligentere anwendungsgestützte Ressourcenverwaltungstechniken aufzunehmen. Während seiner Lebensdauer kann ein IMDG-Knoten zwischen mehreren Moden umschalten, z.B.: Normalmodus, Übergangsmodus und Wiederherstellmodus. Bei Bedarf können weitere Modi entwickelt und realisiert werden.
-
Im Normalmodus arbeitet ein IMDG 118 mit der zum Startzeitpunkt festgelegten Speicherebenenordnung. Mit anderen Worten, Benutzertransaktionen werden nur im IMDG-Hauptspeicher ausgeführt und der Sekundärspeicher bei Überlaufsituationen verwendet. Dies entspricht dem normalen Betrieb eines IMDG-Knotens. Sobald er die neue Speicherebenenordnung vom VSLR-Modul 112 erhält, geht der IMDG-Knoten 118 in den Übergangsmodus über. Während dieses Modus ist der IMDG-Knoten 118 in der Lage, eine andere - durch den VRM 110 vorgeschlagene - Speicherebenenordnung zu befolgen, um wirksam auf eine Speichereinheit durchzuschreiben, die im Normalmodus eine niedrigere Ordnung einnimmt. Dies führt zu einer Verringerung der Anzahl von Live-Zustands-Daten in der den IMDG-Knoten 118 beherbergenden VM und verringert somit deutlich den Aufwand der dynamischen Ressourcenzuweisung.
-
Ein IMDG-Knoten 118 kann nach einem während der VM-Migration ausgelösten Übergangsmodus, d.h. nachdem die Live-Zustands-Daten der VM zur Zielmaschine 104 migriert wurden, in den Wiederherstellmodus wechseln. Dieser Modus beinhaltet ein Anwenden aller Transaktionen, die festgeschrieben wurden, während sich der IMDG 118 im Übergangsmodus befand, auf den dem IMDG-Knoten in der Zielmaschine 104 zugewiesenen Speicherplatz. Wenn die im Übergangsmodus festgeschriebenen Transaktionen wie im Falle des Modells eines gemeinsam genutzten Speichers bereits für die VM 106 persistent sind, ist dieser Modus nicht allgemein notwendig. Insgesamt beschreiben die vorliegenden Grundgedanken ein einzigartiges und wirksames Verfahren zur effizienten Zusammenarbeit der Virtualisierungsressourcenverwaltung mit speicherintensiven Anwendungen bei besonderem Augenmerk auf IMDGs, obwohl auch andere Systeme verwendet werden können. Durch Einbeziehen des beschriebenen VSLR-Moduls 112 in deren gemeinsamen Betrieb und das Ermöglichen der dynamischen Neuordnung der Speicherebenen stellen die vorliegenden Ausführungsformen einen wirksamen Ansatz zum Verwalten zweier wichtiger Cloud-Computing-Techniken bereit, die ansonsten miteinander im Wettstreit liegende Eigenschaften aufweisen. Die beschriebenen Systeme und Verfahren wandeln solche im Wettstreit liegenden Eigenschaften in einen klar definierten zusammenarbeitenden Betrieb um.
-
Insbesondere wird die effiziente, die Migration berücksichtigende Zustandsverwaltung sowohl aus Sicht der Ressourcenverwaltung als auch der Anwendungsleistungsverwaltung bereitgestellt, indem das VSLR-Modul 112 gemäß den vorliegenden Grundgedanken verwendet wird. Das VSLR-Modul 112 ist für die hochwirksame Zusammenarbeit zwischen unterschiedlichen Technologien bei speicherintensiven Anwendungen besonders nützlich.
-
Unter Bezugnahme auf 2 wird ein Verfahren zum Realisieren einer Veränderung mittels Speicherebenenordnungen gemäß einem veranschaulichenden Beispiel gezeigt. In Block 202 kennzeichnet ein VRM VMs für das Neupositionieren. In Block 204 erhält der VRM Speicherprofilinformationen vom SRM. Der SRM baut Profilinformationen bezüglich der Auslastung/Verfügbarkeit der mehreren Speicherebenen und Einheiten im System auf, um Profilinformationen von der Speicherschicht zu erhalten. Zum Beispiel kann er die effektive Bandbreite lokaler Festplatten und Netzwerkspeicher, die Speicherauslastung von Flash-Speicherkarten in physischen Maschinen usw. erhalten. Verfahren zum Erhalten dieser Art von Informationen können eine Vielzahl von Formen annehmen. Zum Beispiel können bestehende Produkte wie VMware eingebaute Module beinhalten, um diese Profilinformationen mit minimalem Aufwand zu erhalten.
-
In Block 206 stellt der VRM eine neue Speicherebenen-Ordnungsempfehlung für IMDG-VMs bereit. In Block 208 informiert der VRM die IMDGs in VMs über ein VSLR-Modul über die neue Speicherebenenordnung. In Block 210 wenden die IMDGs die neue Speicherebenenordnung an. In Block 212 führt der VRM Neupositionierungsmaßnahmen durch. Ein Neupositionieren von VMs kann aus vielen Gründen ausgelöst werden. Zum Beispiel Wartungsaufgaben, z.B. Herunterfahren einer physischen Maschine, um Abhilfemaßnahmen und Aktualisierungsaufgaben durchzuführen, Maßnahmen der dynamischen Ressourcenverwaltung, um dynamisch auftretende Probleme bei Ressourcenzugangskonflikten zu verringern usw. Für das Neupositionieren von VMs gibt es mehrere Techniken.
-
In Block 214 kann der VRM über das VSLR-Modul das Zurückkehren zu einer ursprünglichen Speicherebenenordnung empfehlen. In Block 216 wartet der VRM bis zu einer nächsten Ressourcenverwaltungsperiode. In Block 218 berechnet der VRM eine optimale Ressourcenzuweisung für einen aktuellen Cluster-Zustand oder eine aktuelle Speicherhierarchie. In Block 220 wird eine Feststellung getroffen, ob eine VM-Neupositionierung notwendig ist. Falls ja, wird mit Block 202 fortgefahren, und falls nein, mit Block 216.
-
Unter Bezugnahme auf 3 wird ein Verfahren zum Neuordnen von Speicherebenen in einer virtualisierten Umgebung gemäß einer beispielhaften Ausführungsform gezeigt, welches das Neupositionieren von VMs insbesondere für speicherintensive Anwendungen effizienter durchführt. Zu der speicherintensiven Anwendung können speicherintensive Anwendungen in der Form von arbeitsspeicherinternen (engl.: in-memory) Daten-Grids (IMDGs) gehören.
-
In Block 302 wird eine an einem neuen Speicherort neu zu positionierende oder neu bereitzustellende virtuelle Maschine (VM) identifiziert oder ausgewählt. In Block 304 wird eine neue Speicherebenenordnung für die VM ermittelt, die einen Live-Zustand einer VM während eines Migrationstransfers verringert und gemeinsam genutzten Speicher, virtuelle Festplattenorte der VM und durch eine Anwendung auferlegte Anforderungen von Dienstgütevereinbarungen (SLAs) usw. berücksichtigt, um die Wiederherstellvorgänge nach dynamischen Ressourcenzuweisungsaktionen zu verringern. Andere Erwägungen können ebenfalls verwendet werden, um die Empfehlung zu geben. In einer Ausführungsform werden in Block 307 Speicherebenenbedingungen durch einen Virtualisierungsressourcenverwalter (VRM) mithilfe eines Speicherressourcenverwalters (SRM) bewertet, wodurch Profilinformationen für verschiedene Speicherebenen bereitgestellt werden. In Block 308 entscheidet der VRM über Maßnahmen zur dynamischen Ressourcenzuweisung und erstellt Speicherebenen-Neuordnungsempfehlungen für unterschiedliche VMs.
-
In Block 310 wird die neue Speicherebenen-Ordnungsempfehlung den VMs übermittelt, und die neue Speicherebenenordnung wird in den VMs angewandt. In Block 312 vermittelt ein Modul zur die Virtualisierung und die dynamische Ressourcenzuweisung berücksichtigenden Speicherebenenneuordnung (VSLR) zwischen Anwendungsknoten (z.B. den IMDG-Knoten) und dem VRM, um jedem Knoten VRM-Empfehlungen zu übermitteln, Knotenaktionen zu überwachen und dem VRM das aktuelle Verhalten zu berichten.
-
In Block 314 beinhalten Anwendungsknoten (z.B. IMDGs) bestimmte Operationsmodi für einen Normalbetrieb, einen Übergangsmodus, wenn eine Speicherebene neugeordnet wird, und einen Wiederherstellmodus, um nach dem Übergangsmodus zum normalen Betrieb zurückzukehren. Die Modi werden bereitgestellt, um wirksame Übergangsmaßnahmen sicherzustellen (z.B. Neupositionieren oder Neubereitstellen). In Block 316 können die Knoten (z.B. IMDGs) mindestens einen zusätzlichen intelligenten Selbstregelungsmechanismus verwenden, um eine Speicherebenenordnung auf der Grundlage von VSLR-Empfehlungen und lokalen Optimalitätskriterien dynamisch auszuwählen. Der IMDG-Knoten oder der andere Knoten kann die Empfehlung des VRM übernehmen oder die Empfehlung gemäß festgelegter Kriterien übergehen. Zum Beispiel kann der VRM den Knoten empfehlen, den RAM-gestützte Speicher auf die höchste Ebene zu setzen (d.h. primär), gemäß der lokalen CPU- oder Speicherauslastungsüberwachung kann der Knoten jedoch festplattengestützten Speicher auswählen. Mittels einfacher Rückmeldungssteuerungsmechanismen kann der Knoten auch Informationen bezüglich der durch die Anwendung wahrgenommen Leistung (z.B. Reaktionszeit, Durchsatz) einsetzen. Zum Beispiel kann der VRM den Knoten eine Speicherhierarchie mit 2 Ebenen empfehlen, was Flash-gestützten und festplattengestützten Speicher als Primär- bzw. Sekundärebene einschließt. Wenn die Anwendung einen schwachen Durchsatz gemeldet hat, können die Knoten eine reaktivere Speicherordnung bevorzugen, wie beispielsweise diejenige, die RAMgestützten bzw. Flash-gestützten Speicher aufweist.
-
In Block 318 wird nach Neupositionierungsmaßnahmen eine andere Speicherebenenordnung empfohlen. Dazu kann nach den Neupositionierungsmaßnahmen ein Zurückkehren zur ursprünglichen Speicherebenenordnung oder ein Übernehmen einer neuen Speicherebenenordnung gehören. In Block 320 wird eine nächste zu überführende VM berücksichtigt, bis alle ausgewählten oder für Übergänge identifizierten VMs erreicht sind.
-
Nachdem bevorzugte Ausführungsformen für eine die Virtualisierung und die dynamische Ressourcenzuweisung berücksichtigende Speicherneuordnung beschrieben wurden (die veranschaulichend und nicht einschränkend anzusehen sind), wird festgehalten, dass durch den Fachmann Modifikationen und Variationen in Hinblick auf die vorstehende Lehre vorgenommen werden können. Es ist daher offensichtlich, dass Änderungen an den speziellen offenbarten Ausführungsformen vorgenommen werden können, die innerhalb des Umfangs der Erfindung liegen, wie sie in den angehängten Ansprüchen dargelegt ist. Nachdem somit Aspekte der Erfindung mit den gemäß der Patentgesetzgebung erforderlichen Einzelheiten und Besonderheiten beschrieben wurden, wird der beanspruchte Inhalt, für den Patentschutz gewünscht wird, in den angehängten Ansprüchen zum Ausdruck gebracht.
