DE112011103666B4 - Speicherverwaltung in Cluster-Datenverarbeitungssystemen - Google Patents

Speicherverwaltung in Cluster-Datenverarbeitungssystemen Download PDF

Info

Publication number
DE112011103666B4
DE112011103666B4 DE112011103666.3T DE112011103666T DE112011103666B4 DE 112011103666 B4 DE112011103666 B4 DE 112011103666B4 DE 112011103666 T DE112011103666 T DE 112011103666T DE 112011103666 B4 DE112011103666 B4 DE 112011103666B4
Authority
DE
Germany
Prior art keywords
vios
monitor
server
lpm
cluster
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE112011103666.3T
Other languages
English (en)
Other versions
DE112011103666T5 (de
Inventor
Greg Mewhinney
James Pafumi
David Nevarez
Jacob Jason Rosales
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE112011103666T5 publication Critical patent/DE112011103666T5/de
Application granted granted Critical
Publication of DE112011103666B4 publication Critical patent/DE112011103666B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/203—Failover techniques using migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/142—Reconfiguring to eliminate the error
    • G06F11/1425—Reconfiguring to eliminate the error by reconfiguration of node membership
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Hardware Redundancy (AREA)

Abstract

Verfahren zum Betreiben eine Datenverarbeitungssystems, wobei das Datenverarbeitungssystem einen Prozessor, einen Speicher, der mit dem Prozessor verbunden ist, wenigstens einen Eingabe/Ausgabe- (E/A-) Adapter, der eine Verbindung mit einem externen Netzwerk mit einem gemeinsam genutzten Speicher-Repository ermöglicht, und eine Vielzahl von virtuellen E/A-Servern (VIOSes), die ein VIOS-Cluster mit einer gemeinsam genutzten Datenbank bilden, aufweist, wobei jeder VIOS cluster-bewusst ist, wobei das Verfahren aufweist:Aktivieren eines ersten Monitor-Threads in einem ersten VIOS eines ersten Servers, um einen Zustand eines Live Partition Mobility- (LPM-) Ereignisses zu verfolgen;Aufzeichnen von Informationen über das LPM-Ereignis in der gemeinsam genutzten Datenbank unter Verwendung des ersten Monitor-Threads;in Reaktion darauf, dass der erste VIOS in einem Fehlerzustand bleibt, Identifizieren eines oder mehrerer funktionierender Monitor-Threads, die in einem Quellenserver weiterhin funktionieren, wobei der Fehlerzustand einen Verlust der Überwachung des LPM-Ereignisses durch den ersten Monitor-Thread zur Folge hat;Feststellen, ob es sich bei dem einen oder den mehreren funktionierenden Monitor-Threads um einen einzigen letzten Monitor-Thread handelt; undin Reaktion darauf, dass ein erster VIOS in dem ersten Server im Fehlerzustand ist, Ausführen von Lösch- und Aktualisierungsoperationen in der gemeinsam genutzten Datenbank über den letzten Monitor-Thread, wobei das Löschen und Aktualisieren in Reaktion auf das Empfangen einer Angabe, dass in dem ersten Server ein oder mehrere Knoten vorhanden sind, die sich in dem Fehlerzustand befinden, ausgeführt werden.

Description

  • HINTERGRUND
  • Technisches Gebiet
  • Die vorliegende Erfindung bezieht sich im Allgemeinen auf Cluster-Datenverarbeitungssysteme und insbesondere auf die Verwaltung und Nutzung von gemeinsam genutzten Speichereinrichtungen in einem Cluster-Datenverarbeitungssystem. Die vorliegende Erfindung bezieht sich noch genauer auf ein verbessertes Verfahren und System für eine Wiederherstellung nach einem Knotenfehler anhand der Nutzung von gemeinsam genutzten, verteilten Speichereinrichtungen in einem Cluster-Datenverarbeitungssystem.
  • Beschreibung des Standes der Technik
  • Eine Konfiguration eines virtualisierten Datenverarbeitungssystems, die die Virtualisierung von Prozessor-, Speicher- und Betriebssystem- (OS-) Ressourcen gewährleistet, wird in der Computerindustrie (und insbesondere in der Computerserverindustrie) immer gebräuchlicher. In geringerem Umfang ist die Speicher-Virtualisierung ebenfalls bekannt und wird in beschränkten Umgebungen bereitgestellt. Bei der Virtualisierung der Datenverarbeitungsumgebung werden Speicher-Virtualisierung und -Verwaltung jedoch als ein von der Virtualisierung und Verwaltung eines Servers getrenntes Virtualisierungsmodell umgesetzt. Daher können logische Partitionen von verschiedenen Clients (LPARs), die unterschiedlichen virtualisierten Serversystemen zugehörig sind, auf denselben Speicherzugriffsnetzwerk- (SAN-) Speicher zugreifen. Die Client-LPARs an einem Server haben jedoch keinerlei „Kenntnis“ darüber, ob die Platte des Speicherzugriffsnetzwerks (SAN), auf die die Client-LPAR zuzugreifen versucht, durch irgendeine andere Client-LPAR verwendet wird, die zu einem anderen Server gehört. Die herkömmliche Umsetzung von verteilten Serversystemen, die eine Speicher-Virtualisierung in einem gemeinsam genutzten SAN-Speicher gewährleistet, kann Probleme der Datenintegrität und möglicherweise Datenverfälschung und Abstürze einer Client-Partition bewirken.
  • Live Partition Mobility (LPM) ist die Praxis zum Verschieben einer virtualisierten Client-Partition von einem Server zum anderen scheinbar ohne Operationen bei dem Client zu unterbrechen. Während dieser LPM-Ereignisse treten jedoch gelegentlich Fehler auf. Unglücklicherweise sind herkömmliche Ansätze nicht wirkungsvoll bei der Abwicklung von Hardware-Fehlern während LPM-Operationen. Das ist ein sehr komplexes Problem, da die Zustandspermutationen beträchtlich sind und es keinen einzigen Knoten gibt, auf den bei der Fehlerbeseitigung vertraut werden kann. Der herkömmliche Ansatz funktioniert nicht in der Cluster-Umgebung, da es zusätzlich zum Löschen von Speicher-Ressourcen, die durch den Fehler verwaist sind, keine Synchronisation von Vergleichsinformationen für die verschiedenen Knoten gibt. Bei gegenwärtigen Ansätzen würde eine Fehlerwiederherstellung einen langsamen knotenweisen Abrechnungs- und Löschvorgang erfordern, der die Funktion des Clusters für eine bestimmte Zeitspanne einschränken (und möglicherweise einen Dienstverlust für die Client-Partition beinhalten) würde.
  • Die US 2008 / 0 155 169 A1 betrifft eine Implementierung von Operationen für virtuelle Maschinen unter Verwendung von Speichersystemfunktionalität. Eine Ausführungsform der US 2008 / 0 155 169 A1 beinhaltet ein Verfahren, das umfasst: (a) Darstellen mindestens von Zustandsdaten einer virtuellen Maschine in einer Einheit eines Netzwerkspeichers eines Netzwerkspeichersystems; und (b) Verwenden der Datenmanipulationsfunktionalität des Netzwerkspeichersystems, um eine Operation der virtuellen Maschine zu implementieren, die mindestens die Zustandsdaten der virtuellen Maschine manipuliert.
  • Die US 7 434 022 B1 betrifft eine verteilte Kopiertechnik, die bei der Migration großer Datenmengen von einem oder mehreren Quellgeräten auf ein oder mehrere Zielgeräte verwendet werden kann. Die Datenquelle wird in Partitionen aufgeteilt. Wenn Fibre Channel-Adapter (FAs) verfügbar werden, kann jeder der FAs eine Partition der Daten kopieren. Ein Kopierindikatorwert gibt die letzte Partition an, die an einen FA zum Kopieren delegiert wurde. Der letzte FA, der den Kopiervorgang abgeschlossen hat, ist dafür verantwortlich, dass alle anderen Datenpartitionen, die an einen FA delegiert wurden, der während der Rückmeldung der anderen Datenpartitionen gestorben ist, vollständig kopiert werden. Wenn der letzte FA vor dem Abschluss seiner Verarbeitung stirbt, werden zusätzliche Schritte von anderen verbleibenden FAs ausgeführt, um alle Datenpartitionen zu kopieren, von denen nicht bekannt ist, dass sie erfolgreich migriert wurden.
  • KURZDARSTELLUNG
  • Der Erfindung liegt die Aufgabe zugrunde ein Verfahren, System und Computerprogrammprodukt für eine Nutzung einer Cluster-Bewusstheit bereitzustellen zu schaffen, um ein Live Partition Mobility-Ereignis (LPM-Ereignis) wirkungsvoll zu unterstützen und eine Wiederherstellung von einem Fehler eines Knotens/Virtual Input/Output-(I/O)-Servers (VIOS) innerhalb eines VIOS-Clusters bereitzustellen. Die der Erfindung zugrunde liegende Aufgabe wird durch die Merkmale der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
  • Ein Live Partition Mobility-Dienstprogramm (LPM-Dienstprogramm) erzeugt einen Monitor-Thread in einem ersten VIOS bei Auslösung eines entsprechenden LPM-Ereignisses. Der Monitor-Thread verfolgt den Zustand eines LPM-Ereignisses und zeichnet Statusinformationen in der Mobility-Tabelle einer Datenbank auf. Das LPM-Dienstprogramm erzeugt andere Monitor-Threads in anderen VIOSes, die auf dem (demselben) elektronischen Quellen-Datenverarbeitungskomplex (CEC) ablaufen. Wenn ein erster VIOS einer von mehreren Fehlerbedingungen widersteht (z.B. kann der VIOS keine weiteren E/A-Operationen ausführen, geht offline oder wird aus dem Cluster entfernt), liefert das LPM-Dienstprogramm eine Benachrichtigung an andere funktionierende Knoten/VIOSes. Das LPM-Dienstprogramm ermöglicht einem funktionierenden Monitor-Thread das Aktualisieren des Zustands des LPM-Ereignisses. Im Einzelnen kann ein letzter Monitor-Thread anhand einer Angabe, dass es in dem ersten Server Knoten gibt, die in einem Fehlerzustand sind, Operationen in der Datenbank aktualisieren.
  • Figurenliste
  • Ausführungsformen der vorliegenden Erfindung werden nun lediglich beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen beschrieben, in denen:
    • 1A eine erste Ansicht eines Cluster- (cluster-bewussten) Datenverarbeitungssystems veranschaulicht, in dem verschiedene Funktionsmerkmale der beschriebenen Ausführungsformen gemäß einer Ausführungsform umgesetzt sind;
    • 1B eine zweite Ansicht des Cluster-Datenverarbeitungssystems (DPS) von 1 veranschaulicht, die zusätzliche Funktionskomponenten in den Datenverarbeitungskomplexen und gemeinsam genutzten Speichereinrichtungen gemäß einer Ausführungsform darstellt;
    • 2A eine interne Konfiguration eines elektronischen Datenverarbeitungskomplexes (CEC) in dem Cluster-DPS mit virtualisierten OS-Partitionen, einschließlich Partitionen eines Virtual I/O-Servers (VIOS) gemäß einer Ausführungsform veranschaulicht;
    • 2B eine Blockschaubild-Darstellung von Funktions-Komponenten/Modulen eines cluster-bewussten Betriebssystems ist, das in einem VIOS verwendet wird, gemäß einer Ausführungsform;
    • 3 ein Ablaufplan des Verfahrens, durch welches der Vorgang von Client-Erzeugung und Registrierung in einem CA_DPS ausgeführt wird, gemäß einer Ausführungsform ist;
    • 4A eine Blockschaubild-Darstellung eines Speicherpools, der einem VIOS-Cluster zugehörig und durch dieses verwendet wird, in einem CA_DPS gemäß einer Ausführungsform ist;
    • 4B eine Blockschaubild-Darstellung von Strukturen gespeicherter Daten und anderer Funktionskomponenten in einer VIOS-DB mit Quellenknoten- und Zielknoten-Komponenten, die ein Informations-/Datenmanagement auf Clusterebene und einen Austausch zwischen einem Management-Tool, einem Quellenknoten, einem zweiten/Zielknoten, und der gemeinsam genutzten Datenbank ermöglichen, gemäß einer Ausführungsform ist;
    • 5A eine Blockschaubild-Darstellung eines Datenverarbeitungssystems, das die Funktionalität einer Managementkonsole mit Hardware- und Software-Komponenten bereitstellt, die verwendet werden können, um Live Partition Mobility in einem VIOS-Cluster auszulösen und zu unterstützen, gemäß einer Ausführungsform ist;
    • 5B eine VIOS-Cluster-Umgebung mit zwei CECs und mehreren VIOSes, die eingerichtet sind, um ein Live Partition Mobility- (LPM-) Ereignis effektiv zu unterstützen, gemäß einer Ausführungsform veranschaulicht;
    • 6 eine Mobility-Tabelle, die durch einen Monitor-Thread während eines LPM-Ereignisses aktualisiert wird, gemäß einer Ausführungsform veranschaulicht;
    • 7 ein logischer Übersichts-Ablaufplan eines beispielhaften Verfahrens, durch welches ein VIOS-Cluster ein LPM-Ereignis überwacht, eine Mobility-Tabelle aktualisiert und eine Wiederherstellung nach einem Knotenfehler gewährleistet, gemäß einer Ausführungsform ist; und
    • 8 ein logischer Übersichts-Ablaufplan eines beispielhaften Verfahrens, durch welches das VIOS-Cluster einen Monitor-Thread nutzt, der funktionsfähig (aktiv) bleibt, nachdem ein erster Monitor-Thread ausgefallen ist, um eine Datenbank aktuell zu halten und eine Datenbank-Konsistenz zu gewährleisten, gemäß einer weiteren Ausführungsform ist.
  • GENAUE BESCHREIBUNG
  • Die veranschaulichenden Ausführungsformen beschreiben ein Verfahren, Datenverarbeitungssystem und Computerprogrammprodukt zum Ausnutzen der Cluster-Bewusstheit, um ein Live Partition Mobility- (LPM-) Ereignis effektiv zu unterstützen und eine Wiederherstellung nach einem Knotenfehler in einem Cluster mit Virtual Input/Output (I/O) Server (VIOS) zu gewährleisten. Ein Live Partition Mobility- (LPM-) Dienstprogramm erzeugt einen Monitor-Thread in einem ersten VIOS bei Auslösung eines entsprechenden LPM-Ereignisses. Der Monitor-Thread verfolgt den Status eines LPM-Ereignisses und zeichnet Status-Informationen in der Mobility-Tabelle einer Datenbank auf. Das LPM-Dienstprogramm erzeugt weitere Monitor-Threads in anderen ersten VIOSes, die in dem (demselben) elektronischen Quellen-Datenverarbeitungskomplex (CEC) laufen. Wenn der erste VIOS einen von mehreren Fehlerzuständen erleidet (der VIOS kann z.B. keine weiteren E/A-Operationen ausführen, geht offline oder wird aus dem Cluster entfernt), stellt das LPM-Dienstprogramm eine Benachrichtigung an andere funktionierende Knoten/VIOSes bereit. Das LPM-Dienstprogramm ermöglicht, dass ein funktionierender Monitor-Thread den LPM-Ereignis-Status aktualisiert. Im Einzelnen kann ein letzter Monitor-Thread anhand einer Angabe, dass in dem ersten Server Knoten vorhanden sind, die im Fehlerzustand sind, in der Datenbank Aktualisierungsoperationen ausführen.
  • In der folgenden genauen Beschreibung beispielhafter Ausführungsformen der Erfindung werden spezifische beispielhafte Ausführungsformen, in denen die Erfindung angewendet werden kann, mit ausreichender Genauigkeit beschrieben, um einen Fachmann zu befähigen, die Erfindung anzuwenden, und es sollte klar sein, dass andere Ausführungsformen genutzt werden können und logische, architekturtechnische, programmtechnische, mechanische, elektrische und andere Änderungen ausgeführt werden können, ohne vom Umfang der vorliegenden Erfindung abzuweichen. Die folgende genaue Beschreibung sollte deswegen nicht in einem einschränkenden Sinn aufgefasst werden, wobei der Umfang der vorliegenden Erfindung durch die angefügten Ansprüche und deren Ersetzungen definiert ist.
  • In den Beschreibungen der unterschiedlichen Ansichten der Figuren erhalten ähnliche Elemente ähnliche Bezeichnungen und Bezugszeichen wie jene in der/den vorhergehenden Figur(en). Die spezifischen Nummerierungen, die den Elementen zugehörig sind, werden lediglich bereitgestellt, um die Beschreibung zu unterstützen und sollen keine (strukturellen oder funktionellen oder anderweitigen) Einschränkungen an der beschriebenen Ausführungsform implizieren.
  • Es ist klar, dass die Verwendung von spezifischen Komponenten-, Einheiten- und/oder Parameter-Bezeichnungen (wie jene der hier beschriebenen ausführenden Dienstprogramm/Logik/Firmware) lediglich beispielhaft erfolgt und keine Einschränkungen an der Erfindung implizieren soll. Die Erfindung kann somit mit unterschiedlicher Nomenklatur/Terminologie umgesetzt werden, die verwendet wird, um die darin enthaltenen Komponenten/Einheiten/Parameter ohne Einschränkung zu beschreiben. Bezugnahmen auf ein spezifisches Protokoll oder eine proprietäre Bezeichnung beim Beschreiben eines oder mehrerer Elemente, Merkmale und Konzepte der Ausführungsformen werden lediglich als Beispiele einer Umsetzung bereitgestellt und derartige Bezugnahmen beschränken nicht die Erweiterung der Erfindung auf Ausführungsformen, in denen andere Element-, Merkmal- oder Konzeptbezeichnungen verwendet werden. Somit sollte jedem hier verwendeten Ausdruck in dem Kontext, in dem diese Ausdrücke verwendet werden, seine umfangreichste Interpretation gegeben werden.
  • Wie nachfolgend beschrieben, wird die Umsetzung der Funktionsmerkmale der Erfindung in Verarbeitungseinheiten/Strukturen bereitgestellt und schließt die Verwendung einer Kombination aus Hardware, Software sowie verschiedener Konstrukte auf Software-Ebene ein (z.B. Programmcode). Die dargestellten Figuren veranschaulichen sowohl Hardware-Komponenten als auch Software-Komponenten in einer beispielhaften Datenverarbeitungsarchitektur, die eine spezielle Anzahl von Verarbeitungsknoten aufweist (z.B. elektronische Datenverarbeitungskomplexe). Bei den veranschaulichenden und beschriebenen Ausführungsformen wird angenommen, dass die Systemarchitektur auf eine viel größere Anzahl von Verarbeitungsknoten skaliert werden kann.
  • In den folgenden Beschreibungen sind Überschriften oder Abschnittsbezeichnungen vorgesehen, um Funktionsbeschreibungen von Teilen der Erfindung, die in speziellen Abschnitten gegeben werden, zu trennen. Die Überschriften sind vorgesehen, um einen besseren Ablauf bei der Darstellung der veranschaulichenden Ausführungsformen zu ermöglichen und sind nicht gemeint, um irgendeine Einschränkung an der Erfindung oder in Bezug auf eine der allgemeinen Funktionen, die in einem bestimmten Abschnitt beschrieben werden, zu implizieren. Material, das in einem Abschnitt präsentiert wird, kann auf einen nächsten Abschnitt anwendbar sein und umgekehrt. Die folgende Sequenz von Überschriften und Unterüberschriften werden in der Spezifikation präsentiert:
    1. A. Allgemeine Architektur
    2. B. Cluster-bewusster VIOS
    3. C. CA VIOS-Datenübertragungsprotokoll
    4. D. Gemeinsam genutzte VIOS-DB für Cluster-Management
    5. E. VIOS-Cluster Mobility
    6. F. Fehlerwiederherstellung während Cluster Partition Mobility
  • Allgemeine Architektur
  • Unter spezieller Bezugnahme auf 1A ist ein Blockschaubild einer Architektur 100 eines beispielhaften cluster-bewussten verteilten Datenverarbeitungssystems (DPS) dargestellt, in der die funktionalen Aspekte der beschriebenen Ausführungsformen vorteilhaft umgesetzt werden können. Zur Einfachheit soll die cluster-bewusste verteilte DPS-Architektur 100 nur als DPS 100 bezeichnet werden. Das DPS 100 weist eine Vielzahl von Datenverarbeitungsknoten auf, wobei hier jeder als ein elektronischer Datenverarbeitungskomplex (CEC) bezeichnet wird, von denen die CECs 110A und 110B dargestellt sind. Die Anzahl von CECs im DPS 100 kann variieren, wobei sie von einem einzelnen CEC in einem kleineren System bis zu Hunderten oder Tausenden von CECs in größeren skalierten Systemen reicht. Zur Einfachheit sollten die Ausführungsformen aus der Perspektive eines einzelnen CEC (CEC 110A) oder zweier CECs (CEC 110A, 110B) beschrieben werden. Jeder CEC 110A bis 110B weist wenigstens einen Virtual Input/Output Server 112 (und in den meisten Fällen eine Vielzahl hiervon) auf (die hier auch als VIO-Server oder VIOS bezeichnet werden), deren Funktionalität im Folgenden beschrieben ist. Die tatsächliche Anzahl von VIOSes 112 in jedem CEC 110 des DPS 100 ist ein Entwurfsmerkmal und kann variieren. Außerdem werden in jedem CEC 110A bis 110B logische Client-Partitionen unterstützt (die austauschbar als Client-LPARs oder „Clients“ bezeichnet werden), von denen die ersten beiden Clients, nämlich ClientA 114a und ClientB 114b dargestellt sind. Wie nachfolgend unter Bezugnahme auf 2 beschrieben, sind Client-LPARs 114 logische Partitionen eines virtualisierten Datenverarbeitungssystems (oder Betriebssystems, das partitioniert ist). Die tatsächliche Anzahl von Clients in jedem CEC 110 kann variieren und könnte (ohne Einschränkung) von einem einzigen Client bis Hunderten oder Tausenden von Clients reichen. Zur effektiven Darstellung des hier vorliegenden erfinderischen Konzepts sind in jedem CEC 110 der verschiedenen veranschaulichenden und beschriebenen Ausführungsformen lediglich zwei Clients dargestellt.
  • Das DPS 100 weist außerdem eine verteilte Speichereinrichtung auf, auf die von jedem der CECs 110 und jeder der Komponenten in den CECs 110 zugegriffen werden kann. In den beschriebenen Ausführungsformen wird die verteilte Speichereinrichtung als ein verteilter Datenspeicher 150 bezeichnet und der verteilte Datenspeicher 150 ermöglicht mehrere der Funktionsmerkmale auf Client-Ebene, die durch die hier beschriebenen Ausführungsformen bereitgestellt werden. Der verteilte Datenspeicher 150 ist eine verteile Speichereinrichtung, die eine einzelne Ansicht des Speichers bereitstellt, der durch jeden CEC 110 und für jeden Client 114 jedes CEC 110 in einem cluster-bewussten verteilten System verwendet wird. Der verteilte Datenspeicher 150 weist einen lokalen physischen Speicher 160 und einen Netzwerk-Speicher 161 auf, die beide mehrere physische Speichereinheiten 162 (z.B. Platten, Festkörperlaufwerke usw.) aufweisen. Die physischen Platten, die einen verteilten Datenspeicher 150 bilden, können über ein Speichernetzwerk (z.B. ein SAN) verteilt sein. Der verteilte Datenspeicher 150 stellt außerdem ein Repository bereit, in dem das Software-Dienstprogramm, Befehlscode, OS-Abbilder, Client-Abbilder, Daten (auf System-, Knoten- und Client-Ebene) und/oder andere Funktionsinformationen gespeichert sind, die zum Aufrechterhalten der auf der Client-Ebene bestehenden Operationen/Merkmale, des System-Managements sowie der Operationen/Merkmale auf der Speicherebene des DPS 100 verwendet werden. Zusätzlich zum verteilten Datenspeicher 150 weist das DPS 100 außerdem eine VIOS-Datenbank (DB) 140 auf, die ebenfalls eine verteilte Speichereinrichtung sein kann, die über ein Speichernetzwerk physische Platten aufweist. Die VIOS-DB (oder DB) 40 ist ein Repository, das verschiedene Cluster-Konfigurationsdaten speichert und den Zugriff darauf sowie auf andere Funktionskomponenten/Module und Datenstrukturen bereitstellt, die die hier beschriebene verschiedenartige cluster-bewusste Funktionalität ermöglichen. In einer Ausführungsform können Teile des verteilten Datenspeichers 150 zugewiesen sein, um Speicherpools für ein Cluster bereitzustellen. Jeder VIOS 112 des Clusters unterhält eine lokale Ansicht der DB 140 und aktualisiert die Informationen/Daten/Datenstrukturen auf Clusterebene in der DB 140, so dass Informationen/Daten erzeugt oder aktualisiert werden.
  • Ein Datenaustausch zwischen allen VIOSes 112 jedes CEC 110 sowie mit den VIOSes wenigstens eines anderen CEC 110 wird im Allgemeinen über eine Vielzahl von Zwischen-CEC-Verbindungen unterstützt, die als bidirektionale gestrichelte Linien dargestellt sind, die Paare von VIOSes 112 verbinden. Die Pfeile geben einen Zweiwege-Datenaustausch oder eine Zweiwege-Datenübertragung zwischen Komponenten an. Zusätzlich zu den Zwischen-CEC-Verbindungen ist jeder VIOS 112 außerdem mit dem verteilten Datenspeicher 150 über CEC-Speicher-Verbindungen verbunden, die als durchgezogene bidirektionale Pfeile ebenfalls dargestellt sind. Außerdem ist jeder VIOS 112 mit der DB 140 über VIOS-DB-Verbindungen verbunden, die als Strichpunktlinien dargestellt sind. Mit Ausnahme des Zwischen-CEC-Verbinders, der von einem ersten VIOS (z.B. VIOS 112a) eines ersten CEC zu einem zweiten VIOS (z.B. VIOS 112b) in demselben CEC verläuft, stellen die verschiedenen Verbindungen eine Konnektivität auf Netzwerkebene zwischen den VIOS-Knoten des Clusters und der DB 140 und dem verteilten Datenspeicher 150 dar. Es wird angenommen, dass die in diesem Zusammenhang verwendeten Bezugnahmen auf einen oder mehrere „Knoten“ sich speziell auf einen VIOS in dem Cluster beziehen. Das DPS 100 weist außerdem eine Managementkonsole 175 auf, in der ein (nicht gezeigtes) Management-Tool betrieben wird.
  • In 1B ist eine andere Ansicht des DPS 100 dargestellt, die die netzwerkgestützte Verbindung der CECs 110 mit dem verteilten Daten-Repository 150 und der DB 140 veranschaulicht. 1B veranschaulicht genauer die Netzwerk-Konnektivität von VIOSes 150 und CECs untereinander und mit dem verteilten Daten-Repository 150. Bei dieser Ansicht weisen CEC_A (Node_A) 110A und CEC_B (Node_B) 110B ähnliche Konstrukte auf wie in 1A dargestellt. Jeder CEC 110 im DPS 100 verbindet mit dem verteilten Daten-Repository 150 über ein oder mehrere Netzwerke und/oder ein(e) E/A-Verbindung/Switch-Fabric (allgemein dargestellt als Verbindung/Netzwerk-Fabric 170). Bei den Beschreibungen und Darstellungen wird angenommen, dass wenigstens einige der CECs 110 des DPS 100 und das verteilte Daten-Repository 150 voneinander entfernt angeordnet sind, wozu gehört, dass sie z.B. in unterschiedlichen Ländern angeordnet sind, so dass zwischen den entsprechenden Einheiten keine direkte physische Konnektivität besteht. Zur Einfachheit werden die Ausführungsformen so beschrieben, dass sie eine Primärverbindung/Netzwerk 170 aufweisen, das ein privates Weitbereichsnetz (WAN) oder ein öffentliches WAN (wie etwa das Internet) beinhaltet, obwohl andere Netzwerktypen (z.B. ein Lokalbereichsnetzwerk) möglich sind und unterstützt werden.
  • Wie dargestellt, ist in einer oder in mehreren Ausführungsformen jeder CEC 110 außerdem mit einem oder mehreren benachbarten CECs 110 verbunden, um eine wirksame Fehler- und/oder Mobility-Unterstützung und andere Funktionen bereitzustellen, wie im Folgenden beschrieben wird. Der hier verwendete Ausdruck „benachbart“ bezieht sich auf einen angeschlossenen zweiten CEC, mit dem ein erster CEC Daten austauschen kann, und Bezugnahmen auf einen benachbarten CEC sind nicht beschränkt auf einen zweiten CEC in geografischer Nähe zu dem ersten CEC. CEC_A 110A und CEC_B 110B sind so dargestellt, dass sie über ein Verbindungsmedium miteinander verbunden sind, zu dem ein anderes Netzwerk (wie etwa ein Lokalbereichsnetzwerk) 172 oder ein bestimmter Typ von Direktverbindung (z.B. eine Verbindung über einen Lichtwellenleiterkanal), wenn sie physisch nahe beieinander angeordnet sind, gehören. Die Verbindung zwischen benachbarten CECs 110A und 110B ist als eine direkte Verbindungslinie oder eine sekundäre Netzwerkverbindung (172) zwischen CECs 110A und 110B dargestellt. Es ist jedoch klar, dass die Verbindungen nicht unbedingt direkt erfolgen und tatsächlich durch dieselbe allgemeine Verbindung/Netzwerk 170 geleitet werden kann wie bei anderen CEC-Verbindungen mit dem verteilten Speicher-Repository 150. In einer oder mehreren alternativen Ausführungsformen können die Verbindungen zwischen CECs über ein anderes Netzwerk (z.B. das Netzwerk 172, 1B) wie etwa ein Lokalbereichsnetzwerk (LAN) erfolgen.
  • Wie dargestellt, weist jeder CEC 110 eine oder mehrere Netzwerkschnittstellen 134 und einen oder mehrere E/A-Adapter 132 auf, um zu ermöglichen, dass der CEC 110 und somit die anderen Komponenten (d.h. Client-Partitionen) des CEC 110 an dem Datenaustausch auf Netzwerkebene teilnehmen. Jeder VIOS 112 emuliert virtuelle Client-E/A-Adapter 226a bis 226c, um Datenübertragungen durch speziell zugewiesene Client-LPARs 114a bis 114c mit dem verteilten Speicher-Repository 150 und/oder anderen Clients in demselben CEC oder in einem anderen CEC zu ermöglichen. Die VIOSes 112 emulieren diese virtuellen E/A-Adapter 226a bis 226c und tauschen Daten mit dem verteilten Speicher-Repository 150 aus, indem sie mit den entsprechenden virtuellen Server-E/A-Adaptern (SVA) 152a bis 152c in dem verteilten Speicher-Repository 150 eine Verbindung herstellen. CEC-interne Datenübertragungen zwischen VIOS 112 und Client-LPARs 114a bis 114c sind durch durchgezogene Verbindungslinien dargestellt, die über die Virtualisierungs-Managementkomponente geleitet sind, während VIOS-Server-Datenübertragungen durch gestrichelte Linien angegeben sind, die über das Netzwerk/Verbindungs-Fabric 172 verbinden. Die Managementkonsole 175 wird verwendet, um das Setup und/oder die Initialisierung der Sicherungs- und Wiederherstellungsoperationen, die hier für die einzelnen VIOSes 112 und/oder in verschiedenen Ausführungsformen das VIOS-Cluster als Ganzes beschrieben werden, auszuführen. Die VIOSes 112 in jedem CEC 110 sind somit in der Lage, auf Client-Ebene einen Zugriff auf den verteilten Speicher 150 zu unterstützen und den Austausch von Informationen der Systemebene und der Client-Ebene mit dem verteilten Speicher-Repository 150 zu ermöglichen.
  • Zusätzlich weist jeder VIOS 112 außerdem die Funktionskomponenten/Module und Daten auf, um zu ermöglichen, dass die VIOSes 112 im DPS 110 sich der anderen VIOSes überall in dem Cluster (DPS 100) bewusst sind. Aus dieser Perspektive werden die VIOSes 112 in diesem Zusammenhang als cluster-bewusst bezeichnet und ihre untereinander verbundene Struktur in dem DPS 100 ermöglicht somit, dass das DPS 100 ebenfalls austauschbar als cluster-bewusstes DPS 100 bezeichnet wird. Als ein Teil der Cluster-Bewusstheit verbindet jeder VIOS 112 außerdem über das Netzwerk 170 mit der DB 140 und tauscht Daten auf Cluster-Ebene mit der DB 140 aus, um die hier beschriebenen Cluster-Managementfunktionen zu unterstützen.
  • 1B ist ebenfalls eine anfängliche Ansicht des Komponentenaufbaus eines beispielhaften verteilten Speicher-Repository 150 und eine anfängliche Auflistung einiger Komponenten der DB 140. Um die virtuellen E/A-Operationen mit den VIOSes 112 und den zugehörigen virtuellen Client-E/A-Adaptern zu unterstützen, weist das verteilte Speicher-Repository 150 eine Datenübertragungs-Infrastruktur 151 auf. Die Datenübertragungs-Infrastruktur 151 weist eine oder mehrere NetzwerkSchnittstellen 153 und eine Vielzahl von Server-E/A-Adaptern 152 auf, die für Datenübertragungen auf Cluster-Ebene verwendet werden und einen Zugriff auf Daten/Code/Software-Dienstprogramm ermöglichen, die auf dem verteilten Speicher-Repository 150 gespeichert sind, um daran E/A-Operationen auszuführen. Im Einzelnen werden diese Server-E/A-Adapter außerdem als virtuelle Server-E/A-Adapter dargestellt, die mit virtuellen E/A-Adaptern 132 paarweise vorhanden sind, die Clients 114 der CECs 110 zugehörig sind.
  • Wie gezeigt, weist der verteilte Datenspeicher 150 im Allgemeinen einen allgemeinen Speicherraum 160 (die verfügbare lokale und Netzwerk-Speicherkapazität, die in Speicherpools unterteilt werden kann), der einen zugewiesenen Client-Speicher 165 bereitstellt (der in entsprechende Speicherpools für eine Gruppe von Clients unterteilt werden kann), nicht zugewiesenen Ersatz-Speicher 167 und Sicherungs/Redundanz-CEC/VIOS/Client-Konfigurationsdatenspeicher 169 auf. In einer Ausführungsform ist der zugewiesene Client-Speicher als Speicherpools zugeordnet und mehrere der Merkmale, die die gemeinsame Nutzung einer Speicherressource betreffen, gewährleisten einen sicheren Zugang auf den gemeinsam genutzten Speicher und ermöglichen, dass eine Steuerung auf Cluster-Ebene des Speichers unter den VIOSes in einem Cluster mit der Verwendung von Speicherpools unterstützt wird. Wenn in einem VIOS-Cluster umgesetzt, gewährleisten Speicherpools ein Verfahren zum logischen Organisieren eines oder mehrerer physischer Volumina für eine Verwendung durch die Clients, die durch die VIOSes unterstützt werden, die das VIOS-Cluster bilden. 4A veranschaulicht eine beispielhafte Konfiguration eines Speicherpools, der in einem cluster-bewussten DPS 100 verwendet wird. Im Einzelnen stellt 4A Einzelheiten bereit, wie diese physischen Volumina in dem Speicherpool verwendet werden. Wie gezeigt, enthält der Speicherpool 460 in dem Cluster eine oder mehrere Plattengruppen 462. Plattengruppen 462 geben Administratoren die Fähigkeit, Zugangsrichtlinien für eine gegebene Teilmenge von physischen Volumina 162 in dem Speicherpool 460 bereitzustellen. Nachdem eine Plattengruppe 462 definiert wurde, können Administratoren die Teilmenge gestützt auf Plattencharakteristiken weiter in Speicherkategorien 464 kategorisieren. Nachdem eine Plattengruppe 462 und Speicherkategorie 464 definiert wurden, zerlegen Administratoren logische Einheiten (LU) 466 für einen Export in Client-Partitionen (114).
  • Bei der hier bereitgestellten Fähigkeit der virtuellen Poolbildung weist ein Administrator Speicher für einen Pool zu und verwendet mehrere VIOSes aus diesem einzigen Speicherpool. Bei dieser Umsetzung sind die SAN-Administrationsfunktionen von den System-Administrationsfunktionen entkoppelt und der Systemadministrator kann Kunden versorgen (insbesondere Clients 114 von Kunden) oder einen zusätzlichen VIOS anfügen, wenn ein VIOS benötigt wird, um einen Datenspeicherdienst für Kunden bereitzustellen. Auf den Speicherpool kann außerdem clusterübergreifend zugegriffen werden, wodurch der Administrator VIOS-Arbeitslasten verwalten kann, indem die Arbeitslast bei Bedarf zu anderer Hardware verschoben wird. Bei der cluster-bewussten VIOS-Umsetzung von Speicherpools, wird eine zusätzliche Funktionalität bereitgestellt, um zu ermöglichen, dass die VIOSes den Zugriff auf verschiedene Speicherpools steuern, so dass alle Clients/Kundendaten/Informationen vor einem Zugriff durch andere Clients/Kunden sicher sind.
  • Wie dargestellt, weist das DSR 150 darüber hinaus eine Vielzahl von Software-, Firmware- und/oder Software-Dienstprogramm-Komponenten auf, einschließlich eines DSR-Konfigurations-Dienstprogramms 154, DSR-Konfigurationsdaten 155 (z.B. Dateiindices für einen Basisdateisystemzugriff, Metadaten-, Berechtigungs- und andere Vorgänge) und ein DSR-Management-Dienstprogramm 156.
  • Um die Merkmale der Cluster-Bewusstheit des DPS 100 zu unterstützen und gemäß der veranschaulichenden Ausführungsform weist das DPS 100 außerdem eine VIOS-Datenbank (DB) 140 auf, in der verschiedene Datenstrukturen gespeichert sind, die während des Setup und/oder während der nachfolgenden Verarbeitung der mit dem VIOS-Cluster verbundenen Verarbeitungskomponenten erzeugt werden (z.B. VIOSes und Management-Tool). Die DB 140 weist eine Vielzahl von Software- oder Firmware-Komponenten und/oder Daten, Datenmodule oder Datenstrukturen auf, wobei einige von diesen zur Erläuterung in 1B präsentiert werden. Unter diesen Komponenten gibt es u.a. ein Cluster-Management- (CM-) Dienstprogramm 182, eine VIO-AdapterID-Datenstruktur 183, Cluster-Konfigurationsdaten 184, Clientidentifizierende Daten (ID-Daten) 185, eine Liste 186 aktiver Knoten und E/A-Redundanzdaten. Diese verschiedenen Komponenten unterstützen die umfangreiche Clusterbildungs-Funktionalität und die cluster-bewussten E/A-Operationen eines oder mehrerer VIOSes 112 wie hier beschrieben. In der vorliegenden Ausführungsform weist die VIOS-DB 140 außerdem eine Mobility-Tabelle 510 auf, durch die die Knoten von VIOS-Partitionen in der Lage sind, die Bewegung und/oder Verlagerung von VIOS-Partitionen und/oder Client-Partitionen in dem VIOS-Cluster zu verfolgen und zu unterstützen. Zusätzliche Merkmale der DB 140 und des verteilten Speicher-Repository 150 sowie die speziellen Komponenten oder Teilkomponenten, die die zahlreichen Clusterbildungs-Funktionalitäten ermöglichen, werden in der Beschreibung der restlichen Figuren und in der gesamten Beschreibung der verschiedenen dargestellten Ausführungsformen präsentiert.
  • Die verschiedenen Datenstrukturen, die in den Figuren dargestellt und/oder hier beschrieben sind, werden erzeugt, geführt und/oder aktualisiert und/oder gelöscht durch eine oder mehrere Operationen eines oder mehrerer der hier beschriebenen Verarbeitungskomponenten/Module. In einer Ausführungsform wird der anfängliche Aufbau aus Speicherpools, VIOS-DB 140 und entsprechenden Datenstrukturen durch Ausführung eines cluster-bewussten Betriebssystems durch ein Management-Tool 180 und/oder einen oder mehrere VIOSes 112 aktiviert. Nachdem die Infrastruktur eingerichtet wurde, wird jedoch die Aufrechterhaltung der Infrastruktur bei Bedarf einschließlich der Erweiterung der Anzahl von Knoten durch die VIOSes 112 im Datenaustausch mit der DB 140 und dem Management-Tool 180 ausgeführt.
  • Dem DPS 100 zugehörig und mit dem verteilten Speicher-Repository 150 und der DB 140 und VIOSes 112 zum Datenaustausch verbunden ist eine Managementkonsole 175, die von einem Administrator des DPS 100 (oder des verteilten Speicher-Repository 150 oder der DB 140) verwendet werden kann, um auf die DB 140 und das verteilte Speicher-Repository 150 zuzugreifen und Ressourcen und die Funktionalität der DB 140 und des verteilten Speicher-Repository 150 für einen Zugriff/Verwendung durch die VIOSes 112 und die Clients 114 der angeschlossenen CECs 10 in dem Cluster zu konfigurieren. Wie in 1B gezeigt und in der Spezifikation durchgehend beschrieben, ist das Management-Tool 180 in der Managementkonsole 175 umgesetzt. Es ist jedoch klar, dass ein Knoten in dem DPS 100 (bzw. Ressourcen hiervon) ausgewählt/gewählt werden kann, um die Funktionen des Management-Tools 180 auszuführen, und der ausgewählte Knoten würde dann die nachfolgend beschriebene Cluster-Erzeugung und/oder die anderen Cluster-Überwachungs- und Management-Funktionen ausführen, wobei die Verfügbarkeit der durch die DB 140 und das verteilte Speicher-Repository 150 bereitgestellten Ressourcen genutzt wird.
  • In einer alternativen Ausführungsform ist das Management-Tool 180 ein ausführbares Modul, das in einer Client-Partition in einem der CECs in dem DPS 100 betrieben wird. In einer Ausführungsform steuert das Management-Tool 180 die Operationen des Clusters und ermöglicht, dass jeder Knoten in dem Cluster aktuelle/aktualisierte Informationen, die das Cluster betreffen, führt, einschließlich der Bereitstellung einer Benachrichtigung über Änderungen, die an einem oder mehreren Knoten in dem Cluster ausgeführt werden. In einer Ausführungsform meldet sich das Management-Tool 180 bei einem einzelnen VIOS 112b an und ist dadurch in der Lage, Daten auf Cluster-Ebene vom VIOS abzurufen/zu empfangen, einschließlich FFDC-Daten (191) des gesamten Clusters.
  • In 2A ist eine dritte Ansicht eines beispielhaften DPS 100 dargestellt, wobei die Architektur 200 eines Verarbeitungssystems hervorgehoben ist (d.h. die Architektur der einzelnen CECs und insbesondere des CEC_A 110A). Der CEC_A 110A (CEC 110A) dient als beispielhafter CEC, der in 2A und durchgehend in der Spezifikation genauer beschrieben ist. Der CEC 110A ist als ein Server dargestellt, der Hardware-Komponenten und Software/Firmware/OS-Komponenten aufweist, die logisch partitioniert sind, um eine Vielzahl von virtualisierten Maschinenpartitionen zu erzeugen, die als logische Partitionen des Client (LPARs) und virtueller I/O-Server (VIOSes) zugewiesen sind. Hardware-Komponenten 230 des beispielhaften CEC 110A weisen einen oder mehrere Prozessoren 231A bis 231P, einen oder mehrere Speicher 233A bis 233M und einen lokalen Speicher 234 auf. Die Prozessoren 230A bis 230P sind über einen Bus, ein Interconnect/Switch oder ein Interconnect-Fabric (nicht speziell gezeigt) mit einem oder einer Vielzahl von Speichern 233A bis 233M und mit dem lokalen Speicher 234 verbunden. Die spezielle interne Verbindung von Komponenten, die über ein umfangreiches Interconnect-Fabric verteilt sein kann, ist für die beschriebenen Ausführungsformen nicht relevant und in Bezug auf den speziellen Typ der Zusammenschaltung von System-Hardware-Komponenten ist keine weitere Einzelheit dargestellt.
  • Zu den Hardware-Komponenten 230 gehören außerdem eine oder mehrere physische Netzwerkschnittstellen 134, durch die der CEC_A 110A mit einem externen Netzwerk wie etwa u.a. dem Netzwerk 170 verbunden ist. Zusätzlich weisen Hardware-Komponenten 230 eine Vielzahl von E/A-Adaptern 232A bis 232E auf, die die E/A-Schnittstelle für den CEC_A 110A bereitstellen. Die E/A-Adapter 232A bis 232E sind physische Adapter, die ermöglichen, dass der CEC_A 110A E/A-Operationen über eine E/A-Schnittstelle sowohl mit lokal angeschlossenen als auch mit entfernt (über ein Netzwerk) angeschlossenen E/A-Einheiten, zu denen ein SF-Speicher 150 gehört, unterstützt. Zu Beispielen der E/A-Adapter gehören u.a. Peripheral Component Interface (PCI), PCI-X- oder PCI-Express-Adapter und Small Computer System Interconnect- (SCSI-) Adapter. Der CEC 110 ist logisch partitioniert, so dass unterschiedliche E/A-Adapter 232 virtualisiert werden und die virtuellen E/A-Adapter dann unterschiedlichen logischen Partitionen eindeutig zugewiesen werden können. In einer oder mehreren Ausführungsformen werden Konfigurationsdaten in Bezug auf die virtualisierten Adapter und andere Komponenten, die den VIOSes (oder den Clients, die durch den speziellen VIOS unterstützt werden) zugehörig sind, in jedem VIOS gehalten und können durch das VIOS-OS gehalten und aktualisiert werden, wenn an diesen Konfigurationen Änderungen ausgeführt werden und wenn Adapter hinzugefügt und/oder entfernt und/oder zugewiesen werden.
  • Logisch über der Hardware-Ebene (230) ist eine Virtualisierungs-Management-Komponente angeordnet, die in einer Ausführungsform als ein Power-Hypervisor (PHYP) 225 (Handelsmarke der IBM Corporation) bereitgestellt wird. Während er in den verschiedenen Ausführungsformen durchgehend als PHYP 225 dargestellt und beschrieben wird, ist vollkommen klar, dass andere Typen von Virtualisierungs-Management-Komponenten verwendet und bei der Umsetzung der verschiedenen Ausführungsformen gleichwertig eingesetzt werden können. Der PHYP 225 weist einen zugehörigen Service-Prozessor 227 auf, der in dem CEC 110 damit verbunden ist. Der Service-Prozessor 227 kann verwendet werden, um verschiedene Dienste für eine oder mehrere logische Partitionen bereitzustellen. Der PHYP 225 ist außerdem mit dem Hardware-Management-Controller (HMC) 229 verbunden, der außerhalb des physischen CEC 110 vorhanden ist. Der HMC 229 ist eine mögliche Umsetzung der Managementkonsole 175, die in den 1A bis 1B dargestellt ist, und die Verwendung des HMC 229 speziell in dieser Veranschaulichung dient lediglich zur Veranschaulichung einer tatsächlichen Ausführungsform unter mehreren zur Verfügung stehenden Optionen. Operationen der unterschiedlichen logischen Partitionen können durch den HMC 229 gesteuert werden, der ein separates Datenverarbeitungssystem ist, von dem ein Systemadministrator verschiedene Funktionen ausführen kann, wie etwa die Neuzuweisung von Ressourcen an unterschiedliche logischen Partitionen. Es ist wichtig, dass Merkmale in Bezug auf Sicherung und Wiederherstellung von OS-Partitionen und insbesondere der VIOSes und des VIOS-Clusters in der vorliegenden Ausführungsform durch den HMC 229 gesteuert werden, diese Merkmale werden jedoch unter Bezugnahme auf die Managementkonsole 175 in den verschiedenen anderen Ausführungsformen, die hier dargestellt werden, allgemeiner beschrieben.
  • Der CEC_A 110A weist ferner eine Vielzahl von logischen Partitionen der Benutzerebene (LPARs) auf, von denen die ersten beiden gezeigt sind, dargestellt als einzelne Client-LPARs 114A bis 114B im CEC 110A. Gemäß den verschiedenen erläuternden Ausführungsformen unterstützt der CEC 110A mehrere Clients und andere funktionsmäßig betriebene OS-Partitionen, die in einer virtualisierten Umgebung „erzeugt“ werden. Jede LPAR, z.B. die Client-LPAR 114A, empfängt eine Zuweisung von speziell virtualisierten Hardware- und OS-Ressourcen, zu denen virtualisierte CPU 205A, Speicher 210A, OS 214A, lokale Firmware 216 und lokaler Speicher (LStore) 218 gehören. Jede Client-LPAR 114 enthält ein entsprechendes Host-Betriebssystem 214, das einen Zugang auf niedriger Ebene auf die Hardware-Ebene (230) des CEC 110A und/oder auf virtualisierte E/A-Funktionen und/oder Dienste, die durch VIOSes 112 bereitgestellt werden, steuert. In einer Ausführungsform kann das Betriebssystem (die Betriebssysteme) unter Verwendung von OS/400 umgesetzt sein, das eingerichtet ist, um mit einer Partition-Management-Firmware wie etwa PHYP 225 zu verbinden, und von International Business Machine Corporation verfügbar ist. Es ist klar, dass z.B. andere Typen von Betriebssystemen (wie etwa Advanced Interactive Executive- (AIX-) Betriebssystem, ein Warenzeichen von IBM Corporation, Microsoft Windows®, ein Warenzeichen von Microsoft Corp oder GNU®/Linux®, eingetragene Warenzeichen von Free Software Foundation und The Linux Mark Institute) in Abhängigkeit von einer speziellen Umsetzung verwendet werden können, wobei OS/400 lediglich als ein Beispiel verwendet wird.
  • Gemäß der veranschaulichenden Ausführungsform weist der CEC 110A außerdem einen oder mehrere VIOSes auf, von denen zwei, VIOS 112A und 112B dargestellt sind. In einer Ausführungsform ist jeder VIOS 112 in einem der Speicher 233A bis 233M konfiguriert und weist virtualisierte Versionen von Hardware-Komponenten auf, zu denen u.a. CPU 206, Speicher 207, Lokalspeicher 208 und/oder E/A-Adapter 226 gehören. Gemäß einer Ausführungsform ist jeder VIOS 112 als eine logische Partition (LPAR) umgesetzt, die spezielle Netzwerk- und Platten- (E/A-) Adapter besitzt. Jeder VIOS 112 repräsentiert außerdem eine spezielle Einzweck-LPAR. Der VIOS ermöglicht die gemeinsame Nutzung von physischen E/A-Ressourcen zwischen logischen Partitionen des Client. Jeder VIOS 112 ermöglicht, dass andere OS-LPARs (die als VIO-Clients oder Clients 114 bezeichnet werden können) die physischen Ressourcen des VIOS 112 über ein Paar virtueller Adapter nutzen. Somit stellt der VIOS 112 ein virtuelles Small Computer System Interface- (SCSI-) Ziel und eine Fähigkeit eines gemeinsam genutzten Netzwerkadapters für Client-LPARs 114 in dem CEC 110 bereit. Wie hier vorgesehen, unterstützt der VIOS 112 die Funktionalität des virtuellen Echtspeichers und der virtuellen gemeinsam genutzten Speicherung (mit Zugriff auf das verteilte Speicher-Repository 150) sowie die Funktionalität der Clusterbildung. Relevante VIOS-Daten und Daten auf Cluster-Ebene werden im lokalen Speicher (L_ST) 208 jedes VIOS 112 gespeichert. Zum Beispiel sind das in einer Ausführungsform VIOS-Konfigurationsdaten der lokalen VIOS-Hardware, virtueller und logischer Komponenten. Der Lokalspeicher (L_ST) 208 weist zusätzlich Cluster-Konfigurationsdaten 184, Cluster-Zustandsdaten 185 und eine Liste 186 aktiver Knoten auf.
  • Im CEC 110A verwenden VIOSes 112 und Client-LPARs 114 ein internes virtuelles Netzwerk zum Datenaustausch. Dieser Datenaustausch wird durch API-Anrufe zu dem Speicher des PHYP 225 umgesetzt. Der VIOS 112 verbindet dann das virtuelle Netzwerk mit dem physischen (E/A-) Adapter, um zu ermöglichen, dass die Client-LPARs 114 extern Daten austauschen. Die Client-LPARs 114 können dadurch verbunden werden und vollständig in einer VLAN-Umgebung zusammenwirken.
  • Für einen Fachmann ist klar, dass das Hardware-, Firmware/Software-Dienstprogramm und Software-Komponenten und ihre Basiskonfiguration, die in den 1A, 1B, 2A und 2B dargestellt sind, variieren können. Es ist nicht vorgesehen, dass die erläuternden Komponenten des DPS 100 und insbesondere jene im CEC 110A erschöpfend sind, sondern repräsentativ sind, um einige der Komponenten hervorzuheben, die zum Umsetzen bestimmter der beschriebenen Ausführungsformen verwendet werden. Zum Beispiel können unterschiedliche Konfigurationen von Datenverarbeitungssystemen/CEC-Einheiten bereitgestellt werden, die andere Einheiten/Komponenten enthalten, die zusätzlich oder anstelle der dargestellten Hardware verwendet werden und in anderer Weise konfiguriert sein können. Das dargestellte Beispiel ist nicht so gemeint, dass es architekturbezogene oder andere Einschränkungen in Bezug auf die gegenwärtig beschriebenen Ausführungsformen und/oder die allgemeine Erfindung impliziert. Der CEC 110, der in den verschiedenen Figuren dargestellt ist, kann z.B. ein IBM eServer pSeries-System sein, ein Produkt der International Business Machines Corporation in Armonk, N.Y., das das Advanced Interactive Executive- (AIX-) Betriebssystem oder LINUX-Betriebssystem verwendet.
  • Cluster-bewusster VIOS
  • Bestimmte Merkmale, die der Umsetzung eines cluster-bewussten VIOS (z.B. des VIOS 112 der 1A, 1B und 2) zugeordnet sind, wurden oben unter Bezugnahme auf die vorhergehenden Figuren und insbesondere 2 eingeführt. Beschreibungen der speziellen Funktionalität des VIOS erfolgen weiterhin unter Bezugnahme auf die Darstellungen der 1A, 1B und 2. Wie in 2 dargestellt, ist jeder VIOS 112 eine Instanz einer virtuellen Maschine, die Hardware in einer virtualisierten Umgebung emuliert. Der VIOS 112 hat die Aufgabe zum Emulieren von SCSI-Speichereinheiten und gewährt Zugang zum verteilten Datenspeicher 150 in Zusammenwirkung mit dem PHYP 225. Eine Konfiguration des VIOS wird durch die Hardware-Management-Tools des HMC 229 ausgeführt. SCSI-Speichereinheiten unterstützen einen Satz von Befehlen, die SCSI-Initiatoren die Fähigkeit der Steuerung des Zugangs zum Speicher ermöglichen. Datenbank-Programme können z.B. den Zugang auf den verteilten Datenspeicher 150 durch einen Satz von SCSI-Befehlen verwalten, der allgemein als persistente Reserve bezeichnet wird. Andere Typen von Reserven werden ebenfalls durch VIOS 112 unterstützt und die kollektive Gruppe derartiger Befehle wird hier als Reservebefehle bezeichnet.
  • Jeder hier bereitgestellte VIOS 112 ermöglicht die gemeinsame Nutzung physischer E/A-Ressourcen zwischen Client-LPARs, wozu die gemeinsame Nutzung der virtuellen Small Computer Systems Interface (SCSI) und virtuelle Vernetzung gehören. Diese E/A-Ressourcen können als interne oder externe SCSI oder SCSI mit RAID-Adaptern oder über Faserkanal-Adapter zum verteilten Datenspeicher 150 dargestellt werden. Die Client-LPAR 114 verwendet jedoch die virtuellen SCSI-Einheitentreiber. In einer Ausführungsform gewährleistet der VIOS 112 außerdem eine Platten-Virtualisierung für die Client-LPAR, indem eine entsprechende Datei auf dem verteilten Datenspeicher 150 für jede virtuelle Platte erzeugt wird. Der VIOS 112 ermöglicht eine wirksamere Nutzung physischer Ressourcen durch die gemeinsame Nutzung zwischen Client-LPARs und unterstützt eine einzelne Maschine (z.B. CEC 110), mehrere Betriebssystem- (OS-) Abbilder gleichzeitig und voreinander isoliert zu betreiben.
  • Wie im VIOS 112 des CEC 110A vorgesehen, weist der VIOS 112 einen cluster-bewussten (CA) OS-Kern 220 (oder einfach CA_OS 220) auf sowie LPAR-Funktionscode 224 zum Ausführen von den OS-Kern betreffenden Funktionen für die VIOS-LPARs 114. In einer oder mehreren Ausführungsformen ist das VIOS-Betriebssystem bzw. sind die VIOS-Betriebssysteme ein erweitertes OS, das eine Funktionalität der Cluster-Bewusstheit aufweist und deswegen als ein cluster-bewusstes OS (CA_OS) bezeichnet wird. Eine Ausführungsform nutzt z.B. das cluster-bewusste AIX (CAA) als Betriebssystem. Das CA_OS 220 verwaltet die VIOS-LPARs 112 und ermöglicht, dass die VIOSes 112 in einem Cluster cluster-bewusst sind. 2B veranschaulicht einen beispielhaften CA_OS-Kern 220 mit mehreren Funktionsmodulen gemäß einer Ausführungsform. In der veranschaulichenden einen Ausführungsform weist der CA OS-Kern 220 ein Cluster-Management- (CM-) Dienstprogramm 222 auf, das die VIOS-Konfiguration für eine Funktionalität auf Cluster-Ebene unterstützt. Im CA_OS-Kern 220 sind außerdem u.a. ein Primärknoten-Auswahl/Operations-Dienstprogramm 182, ein Knoten-Überwachungs- und Berichts-Dienstprogramm 183 und Ereignis-Modul 181 dargestellt. Jede dieser zusätzlichen Software-Komponenten kann in einer Ausführungsform ein Funktionsmodul im CM-Modul sein und ist in dieser Weise im Rest dieser Spezifikation beschrieben. In einer Ausführungsform kann das CM-Dienstprogramm 222 ein separates Dienstprogramm sein, das als Erweiterung eines vorhandenen OS in einem CEC 110 lokal installiert oder (z.B. von der DB 140) heruntergeladen wird. Das CM-Dienstprogramm wird dann ausgeführt, wenn ein VIOS konfiguriert wird, um einem Cluster beizutreten und ein cluster-bewusster Knoten in dem Cluster wird, wobei das CM-Dienstprogramm ermöglicht, dass das OS die unterschiedliche Cluster-Bewusstheit und andere Merkmale und Funktionalitäten auf Cluster-Ebene unterstützt. In einer alternativen Ausführungsform enthält das CA_OS 222 alle Clusterbildungs-Merkmale und Funktionalitäten und führt die verschiedenen Merkmale ein, wenn der CEC 110/VIOS 112 dem Cluster beitritt und/oder während der Konfiguration des VIOS 112, um cluster-bewusst zu werden.
  • Gemäß einer Ausführungsform ermöglicht die Cluster-Bewusstheit, dass mehrere unabhängige physische Systeme als ein einziges System betrieben und verwaltet werden. Wenn es in einem oder mehreren Knoten ausgeführt wird, ermöglicht das CA_OS 222 verschiedene Cluster-Bildungsfunktionen wie etwa das Bilden eines Clusters, das Hinzufügen eines Elements zu einem Cluster und das Entfernen von Elementen aus einem Cluster, wie später genauer beschrieben wird. In einer Ausführungsform kann das CM-Dienstprogramm 222 außerdem das Abrufen und die Präsentation einer umfassenden Ansicht der Ressourcen des vollständigen Clusters ermöglichen. Es ist klar, obwohl verschiedene funktionale Aspekte der Clusterbildungsoperationen als separate Komponenten, Module und/oder Dienstprogramm und zugehörige Datenkonstrukte beschrieben werden, kann die vollständige Gruppierung aus unterschiedlichen Komponenten/Dienstprogramm/Daten als ein einzelnes ausführbares Dienstprogramm/Anwendung wie etwa das CA-OS 220 bereitgestellt werden. Deswegen wird in einer Ausführungsform das CA_OS in einem VIOS 112 ausgeführt und erzeugt eine Vielzahl von Funktionskomponenten im VIOS 112 und in der DB 140 bzw. bringt diese hervor. Mehrere dieser Funktionskomponenten sind in 1B eingeführt und andere werden in den verschiedenen hier bereitgestellten Ausführungsformen beschrieben. Zur Einfachheit der nachfolgenden Beschreibungen wird angenommen, dass sich die Bezugnahmen auf das Cluster-Management-Dienstprogramm und das CA_OS 220 auf die gleiche allgemeine Komponente beziehen (d.h. das CM-Dienstprogramm 222 als Teilkomponente des CA_OS 220) und die Ausdrücke in der gesamten Spezifikation austauschbar verwendet werden können.
  • Wie weiter in den veranschaulichenden Ausführungsformen dargestellt (z.B. 2A), enthält der VIOS 112 ein(e) oder mehrere zusätzliche Funktionsmodule/Komponenten wie etwa VIO-Adapter (Schnittstelle) 226 und virtuelles E/A-Treiber/Dienstprogramm 228, die für den VIOS 112 eine E/A-Funktionalität bereitstellen und ermöglichen, dass der VIOS 112 Datenverkehr zu und von Datenstrukturen und Speichereinrichtungen in dem verteilten Datenspeicher 150 und/oder der DB 140 lenkt. Virtuelle E/A-Adapter 226 und das CM-Dienstprogramm 222 ermöglichen außerdem, dass der VIOS 112 für jede Client-LPAR 114 einen Zugriff auf den vollständigen Speicherbereich, der in dem verteilten Datenspeicher 150 zugänglich ist, und die anderen cluster-unterstützten Funktionalitäten wie hier beschrieben bereitstellt.
  • In der veranschaulichenden Ausführungsform tauscht jeder Client-LPAR 114 Daten mit einem VIOS 112 über den PHYP 225 aus. VIOS 112 und Client-LPAR 114A bis 114B sind mit dem PHYP 226 logisch verbunden, was einen Datenaustausch zwischen beiden virtualisierten Strukturen ermöglicht/unterstützt. Jede Komponente leitet Informationen an den PHYP 225 weiter und der PHYP 225 lenkt Daten dann zwischen den unterschiedlichen Komponenten im physischen Speicher (233A bis 233M). In einer Ausführungsform ist eine virtualisierte Schnittstelle von E/A-Adaptern außerdem mit dem PHYP 225 verbunden, so dass E/A-Operationen zwischen den unterschiedlichen logischen Partitionen und einer oder mehreren lokalen und/oder entfernten E/A-Einheiten übertragen werden können. Wie bei einer lokalen E/A-Lenkung wird Datenverkehr, der an der Schnittstelle des E/A-Adapters oder der Netzwerkschnittstelle von einer entfernten E/A-Einheit eintrifft und/oder hiervon abgeht, über den PHYP 225 zu dem speziellen VIOS 112 geleitet.
  • Bei der oben eingeführten Systemkonfiguration der 1A, 1B und 2A gewährt ein erster VIOS 112a (über einen Datenübertragungskanal, der über den PHYP 225 eingerichtet ist) über einen oder mehrere virtuelle Adapter den Zugang zu einem anderen VIOS 112b. Der VIOS 112 enthält die Funktionalität zum Abfragen des PHYP 225 nach der Kennung für den Client-LPAR 114 in dem CEC 110, in der der VIOS 112 gegenwärtig betrieben wird.
  • CA-VIOS-Datenübertragungsprotokoll
  • Eine Ausführungsform stellt ein Datenübertragungsprotokoll bereit, das einen effizienten Datenaustausch zwischen den Clients 114 und dem verteilten Datenspeicher 150 über den entsprechenden VIOS 112 und virtuelle E/A-Adapter, die in den VIOSes 112 dem speziellen Client 114 zugehörig sind, ermöglicht. Die Ausführungsform stellt weiterhin Speicher-Virtualisierung und Management über die spezifischen Datenübertragungsmechanismen/Protokolle bereit, die in Bezug auf die Verwendung der Cluster-Bewusstheit und des verteilten Datenspeichers 150 umgesetzt sind, so dass die Virtualisierung im Kontext von Virtualisierung und Management des Servers (CEC 110) präsentiert wird. Bei dem präsentierten Protokoll greifen verschiedene VIOSes 112, die unterschiedlichen CECs 110 zugehörig sind, auf dieselbe einzelne verteilte DB 140 zu und Informationen auf Cluster-Ebene werden bei jedem Client-E/A-Vorgang gemeinsam genutzt/übertragen, so dass ein erster Client in einem ersten CEC sich bewusst ist, auf welche SAN-Plattenressourcen durch einen zweiten Client in einem zweiten CEC (oder in demselben CEC) zugegriffen wird. Bei dieser Bewusstheit, die in den E/A-Austausch mit dem verteilten Datenspeicher 150 einbezogen ist, kann der erste Client vermeiden, auf dieselbe Speicherressource zu zugreifen, die gleichzeitig von dem zweiten Client verwendet wird, wodurch Datenintegritätsprobleme vermieden werden, die möglicherweise eine Datenverfälschung und Abstürze der Client-Partition bewirken würden.
  • Das Datenübertragungsprotokoll gewährleistet eine stark integrierte servergestützte Speicher-Virtualisierung sowie einen über Cluster-VIOS-Partitionen verteilten Speicher. Dieses Protokoll weist ein oder mehrere Abfragemerkmale auf, die eine dynamische Verfolgung der Speicherressourcen-Nutzung über das vollständige Cluster ermöglicht. In der gesamten folgenden Beschreibung soll das Datenübertragungs- und Management-Protokoll als ein VIOS-Protokoll beschrieben werden. Das VIOS-Protokoll gewährleistet einen verteilten Speicher über Cluster-VIOS-Partitionen. Bei dem VIOS-Protokoll wird der Speicher als ein großer Speicherpool mit Speichersegmenten (d.h. logischen Einheiten oder LUs) betrachtet, die jedem Client 114 zugewiesen sind. Die VIOSes in dem Gesamtsystem (DPS 100) werden nun als Teil des Clusters strukturiert, wobei jeder VIOS ein Knoten in dem Cluster ist. Jeder VIOS-Knoten tauscht mit anderen VIOS-Knoten unter Verwendung des VIOS-Protokolls Daten aus. Wenn bei dieser Konfiguration von VIOSes zwei oder mehrere Client-LPARs 114, die zu unterschiedlichen CECs 110 gehören, den Speicher in dem SAN gemeinsam nutzen (d.h. zwei Clients sind überlappenden LUs zugewiesen), ermöglicht das VIOS-Protokoll, dass jeder Knoten (jeden Cluster in dem Cluster) abfragt, um die aktuelle Nutzung der Speichereinheit zu ermitteln. Wenn diese Information empfangen wird, kann der VIOS anschließend diese Information zu anderen VIOSes verbreiten. Dadurch ist sich jeder Client darüber bewusst, ob die SAN-Speichereinheit, auf die der Client zuzugreifen versucht, gegenwärtig von einem anderen Client verwendet wird.
  • Gemäß der beschriebenen Umsetzung sind in dem gesamten Cluster die unterschiedlichen Paarungen ClientlD-vioAdapterlD einzigartig, so dass keine zwei Clients in dem gesamten Cluster denselben virtuellen Adapter gemeinsam nutzen und keine zwei vioAdapterlDs in einem einzelnen Client dieselben sind. 3 ist ein Ablaufplan, der das Verfahren veranschaulicht, durch welches ein VIOS 112 in einem CEC 110 im DPS 110 Datenübertragungen auf Cluster-Ebene zwischen einem Client-LPAR 114 und einem verteilten Datenspeicher 150 gemäß einer Ausführungsform ermöglicht. Der Vorgang beginnt im Block 302, in dem der VIOS 112 den PHYP 225 nach der Kennung der Client-LPAR 114 abfragt. Im Block 304 erzeugt der VIOS 112 eine eindeutige Kennung (ID) für den Client (d.h. eine ClientID). Der VIOS 112 speichert dann die eindeutige ClientID in der ClientID-Datenstruktur 159 (1B) in der DB 140 (Block 306). Die DB 140 und durch Erweiterung ist die ClientID-Datenstruktur 159 für jede VIOS-Partition in dem mitwirkenden Cluster (DPS 100) zugänglich. Im Block 308 erzeugt der VIOS 112 außerdem eine Kennung für jeden virtuellen IT-Nexus (virtuelle E/A-AdapterID), die für jeden virtuellen Adapter verwendet wird, der der Client-LPAR 114 zuwiesen ist. In einer Ausführungsform kann eine Client-LPAR 114 mehrere virtuelle Adapter aufweisen, die ihr zugewiesen sind. Diese vio-AdapterlDs sind in der AdapterID-Datenstruktur 158 (Block 310) gespeichert und ihren entsprechenden ClientlDs (Block 312) zugeordnet. Das durch 3 veranschaulichte Verfahren endet im Abschlussblock 314, wobei dann jede ClientID dem entsprechenden einen oder den mehreren vio-AdapterlDs bei der DB 140 zugeordnet ist. 4B, die im Folgenden beschrieben wird, veranschaulicht diese Datenstrukturen sowie mehrere der anderen Komponenten, die in der DB 140 gespeichert sind.
  • VIOS-SCSI-Emulationscode (ein ausführbares Modul, das von dem VIO-Software-Dienstprogramm 228 bereitgestellt wird) verwendet die vio-AdapterID, um Reservebefehle zu emulieren. Ein sicherer Zugang zu Speicherpools wird durch die eindeutige ClientID verwaltet, die in einer Zugangsliste bereitgestellt wird, die jedem Speicherpool zugehörig ist. In einer Ausführungsform unterstützt der VIOS 112 Befehle, die als Teil der Verschiebung einer Client-LPAR 114 von einem ersten (Quellen-) CEC (110A) zu einem zweiten (Ziel-) CEC (110B) in einer Cluster-Umgebung aufgerufen werden. Die Befehle erzeugen Datenströme, die die virtuellen Einheiten beschreiben, die die vio-Adapter-Informationen enthalten. Diese Informationen werden verwendet, um die ClientID-Datenbank 159 zu modifizieren, so dass die Identität des Client in dem Ziel-CEC (110B) der eindeutigen ClientID dieses Client zugeordnet ist, und die eindeutigen Kennungen der VIOS-Adapter (VIO-AdapterlDs) in dem Quellen-CEC (110A) werden von den E/A-Adaptern in dem Ziel-CEC (110B) übernommen.
  • Gemeinsam genutzte VIOS-DB für Cluster-Management
  • Wie hier beschrieben, ermöglicht die Umsetzung der Cluster-Bewusstheit bei den VIOSes des Clusters, dass die VIOSes Cluster-Speicherdienste für virtuelle Clients (114) bereitstellen. Der VIOS-Softwarestapel stellt u.a. die folgenden erweiterten Möglichkeiten bereit: Zusammenlegung und Bereitstellung von Speicherraum; Thin-Bereitstellung; Klonen des virtuellen Client; Speicherauszug des virtuellen Client; Migration des virtuellen Client; verteiltes Speicher-Repository; Spiegeln des virtuellen Client; und Integration der Server-Management-Infrastruktur. Allgemeiner ausgedrückt ermöglicht das VIOS-Protokoll, dass eine verteilte Speicherung als zentralisierte strukturierte Speicherung mit einem Namenraum, Lagetransparenz, Serialisierung und feinmaschiger Sicherheit betrachtet wird. Das VIOS-Protokoll gewährleistet eine Speicher-Poolbildung, verteilte Speicherung und konsistente Schnittstellen der Speichervirtualisierung und Möglichkeiten über heterogenes SAN und netzwerkzugänglichen Speicher (NAS). Um Blockspeicherdienste unter Verwendung des verteilten Repository bereitzustellen, konfiguriert jeder VIOS virtuelle Dienste, die zu virtuellen Clients zu exportieren sind. Nachdem jede virtuelle Einheit erfolgreich konfiguriert wurde und auf einen Adapter eines virtuellen Host (VHOST) abgebildet wurde, können die Clients beginnen, die Einheiten bei Bedarf zu nutzen. In einer Ausführungsform wird die Virtualisierung unter Verwendung einer POWER™ Virtualisierungstechnologie für eine virtuelle Maschine (VM) ausgeführt, die ermöglicht, dass der Vorgang der Einheitenkonfiguration nahtlos erfolgt, da der physische Blockspeicher von der OS-Partition stets zugänglich ist. Wenn eine virtuelle Zieleinheit entfernt wird, werden die entsprechenden ODM-Einträge gelöscht. In der Cluster-Umgebung wird das Entfernen einer der LUs an die anderen VIOSes berichtet. Gemäß dem beschriebenen Verfahren werden ein verteiltes Speicher-Repository und ein lokaler Repository-Cachespeicher verwendet, um sicherzustellen, dass die Knoten in dem Cluster von jedem Knoten (VIOS) in dem Cluster auf Einheitenebene synchronisiert werden.
  • Gemäß einer Ausführungsform werden Informationen, die zum Konfigurieren einer virtuellen Zieleinheit (VTD) benötigt werden, in der DB 140 gespeichert. Auf diese Datenbank (DB 140) kann von allen Knoten in dem VIOS-Cluster zugegriffen werden unter Verwendung von Diensten, die durch ein cluster-bewusstes OS bereitgestellt werden, wie etwa cluster-bewusstes AIX (CAA), die jedoch nicht auf diese beschränkt sind. Zusätzlich werden bestimmte kleine Mengen von Cluster-Daten in einer lokalen Datenbank (ODM) gespeichert (z.B. virtualisierte Abschnitte des Speicherraums 234, 2) in jedem Knoten für die Einheiten, die in diesem Knoten vorhanden sind. Dieser lokale Speicher ist erforderlich, damit die Vorgänge, die in den lokalen Knoten ablaufen, in der Lage sind, die VIOS-Einheit an die korrekten Informationen in der verteilten Datenbank anzupassen.
  • Mit Informationen über jede Einheit, die in der DB 140 gespeichert sind, können Operationen an diesen Einheiten von irgendeinem VIOS-Knoten in dem Cluster ausgeführt werden, jedoch nicht gerade von dem Knoten, in dem sich die Einheit befindet. Wenn eine Operation in einer Einheit an einem „fernen“ (nicht lokalen) Knoten ausgeführt wird (d.h. ein anderer Knoten als der, in dem sich die Einheit physisch befindet), kann die Operation bei Bedarf beliebige Änderungen an den Informationen der Einheit in der DB 140 ausführen. Wenn entsprechende Änderungen in der lokalen Datenbank der Einheit erforderlich sind, ermöglicht das entsprechende CM-Dienstprogramm 222, dass der entfernte Knoten eine Nachricht (unter Verwendung von Cluster-Diensten) an den lokalen Knoten sendet, um den lokalen Knoten zu benachrichtigen, die geforderten Änderungen auszuführen. Zusätzlich wird dann, wenn ein Knoten in dem Cluster gebootet wird oder wenn der Knoten wieder in das Cluster eintritt, nachdem er für eine Zeitperiode verloren war, der Knoten autonom auf die DB 140 Bezug nehmen, um die dortigen Daten auf die lokalen Daten des Knotens zu synchronisieren.
  • Wenn zum Beispiel eine Operation zum Löschen einer VIOS-Einheit aus dem lokalen Knoten an einem entfernten Knoten ausgeführt wird, wird die Operation die dieser Einheit zugehörigen Informationen aus der DB 140 entfernen und eine Nachricht zu dem lokalen Knoten senden, um den lokalen Knoten anzuweisen, die Einheit aus der lokalen Datenbank zu entfernen. Wenn der lokale Knoten abgeschaltet ist oder gegenwärtig nicht Teil des Clusters ist, wird, wenn der lokale Knoten erstmalig gebootet wird oder wieder in das Cluster eintritt, der lokale Knoten automatisch auf die DB 140 zugreifen, aktuelle Daten/Informationen abrufen, die angeben, dass die Informationen für eine der lokalen Einheiten entfernt wurden, und diese Einheit aus den Datensätzen der lokalen Datenbank löschen.
  • 4B ist eine Blockschaubild-Darstellung von Funktionskomponenten eines Quellenknotens, eines Zielknotens und eines gemeinsam genutzten Speichers (DB 140), um eine Speicherung von Informationen/Daten auf Cluster-Ebene, Management und Austausch zwischen den Knoten und einem gemeinsam genutzten Speichers des VIOS (DB 140) während Operationen auf Cluster-Ebene zu ermöglichen, zu denen eine Operation Live Partition Mobility gehört. In einer Ausführungsform wird eine lokale Kopie der DB 140 von allen VIOSes in dem Cluster gemeinsam genutzt. Jeder VIOS ist dann verantwortlich für Speichern, Führen und Aktualisieren der Datenstrukturen in der DB 140 in einer Ausführungsform. Wie durch 4B dargestellt, kann auf die DB 140 von den verschiedenen VIOS-Knoten 112 und dem Management-Tool 405 zugegriffen werden. Die DB 140 weist mehrere unterschiedliche Module von Daten auf, die in einer Vielzahl von Formaten angeordnet sein können (z.B. Tabellen, Rohdaten, sequenzielle Daten usw.). Gemäß der Figur enthält die DB 140 eine Datenstruktur 425 eines virtuellen Adapters, die eine Liste der virtuellen Adapter und Konfigurationsinformationen über diese pflegt. Die DB 140 enthält außerdem eine zweite Datenstruktur 430, die die eindeutigen Adapterkennungen (AdapterlDs) speichert und deshalb hier als AdapterID-Datenstruktur 430 bezeichnet wird. Die DB 140 pflegt eine Liste von VIOSes und von Informationen über diese in einer VIOS-Datenstruktur 435. In einer Ausführungsform kann jede der beschriebenen Datenstrukturen 425 bis 435 eine Tabelle in der DB 140 sein oder enthalten. Die VIOS-DB 140 enthält außerdem eine Mobility-Tabelle 510. In einer Ausführungsform kann eine Kopie der Mobility-Tabelle im verteilten Speicher-Repository 150 geführt werden.
  • Wenn ein virtueller Adapter erstmalig entdeckt wird, erzeugt das Cluster-Management- (CM-) Dienstprogramm 122 (1B) eine Zeile in der Datenstruktur 425 des virtuellen Adapters und eine Zeile in der Datenstruktur 430 der eindeutigen Adapterkennung. Diese beiden Zeilen in den verschiedenen Datenstrukturen sind einander zugehörig und die Kennung (ID) ist garantiert eindeutig. In einer oder mehreren Ausführungsformen sind Adapternamen pro CEC 110 eindeutig und wenn VIOS-Partitionen nicht „mobil“ sind (d.h. sie werden nicht von einem ersten CEC zu einem zweiten CEC verschoben), können die Adapternamen unter Verwendung eines Namen-Tupels des CEC identifiziert werden. Der Kern-Erweiterung wird die Adapterkennung zugeleitet und sie verwendet die Adapterkennung, um den IT-Nexus zu identifizieren, wodurch ermöglicht wird, dass das VIOS-Cluster den Zugriff auf den Speicher anhand der Reservebefehle einschränkt. Dieses Schema ermöglicht, dass Software, die so eingerichtet ist, dass sie auf physische Einheiten (z.B. SCSI-Einheiten) zugreift, sicher betrieben wird, ohne dass eine Modifikation erforderlich ist. Dieses Schema ermöglicht des Weiteren, dass der Kunde Zugriff auf eine breite Palette von existierenden Softwarelösungen hat, die Systemadministratoren bekannt sind. Die Kernerweiterung hat außerdem die Aufgabe, eine Nachricht über ein Socket zu senden, nachdem der Kern die Identität eines VIOS beim Login des VIOS erkannt hat. Der VIOS verwendet einen Login-Befehl der SCSI-Norm, der Teil eines als SRP bekannten Protokolls ist. Das SRP-Protokoll wird über die PHYP-Transport-Schicht durch den VIOS emuliert. Der SRP-Login kann als Auslöser verwendet werden, um einen Befehl über ein Socket mit der relativen Kennung des CEC an den VIOS zu senden. Eine Nachricht wird zurück zur Kernerweiterung gesendet, nachdem die Nachricht verarbeitet wurde. Die Nachricht löst einen Zugriff auf die DB 140 aus, der überprüft, ob der VIOS bekannt ist. Wenn der VIOS in dem Cluster nicht bekannt ist, wird dem VIOS eine eindeutige Kennung zugewiesen und in die VIOS-Datenstruktur 435 in der DB 140 wird eine Zeile eingefügt. Die erzeugte Adapterzeile der Adapter-Datenstruktur 425 in der DB 140 ist dieser Zeile in der VIOS-Datenstruktur 435 zugehörig. Das Management-Tool bestätigt, dass der VIOS durch den Adapter Zugangsrechte auf die in Verwendung befindlichen Speicherpools hat, um logische Einheiten zu emulieren. In den beschriebenen Ausführungsformen ermöglicht die Kernerweiterung keinen E/A-Zugriff auf logische Einheiten, wobei eingeschränkte Speicherpools verwendet werden, bis die VIOS-Kennung bestätigt wird.
  • Unter den grundlegenden Funktionsmerkmalen der veranschaulichenden Ausführungsformen ist die Fähigkeit, die VIOSes 112 der verschiedenen CECs 110 in dem DPS 100 (1A bis 1B) in Clustern zu gruppieren. Der VIOS stellt außerdem Clusterbildungs-Dienste bereit, die beansprucht werden können, so dass Operationen nicht nur in dem lokalen VIOS, sondern in entfernten Knoten aufgerufen werden, ohne dass sich der Verbraucher über derartige Aktionen bewusst ist. Die Einführung dieser Technologien erfordert, dass ein Verbraucher, und zwar ein Management-Tool, in der Lage ist zu verstehen, welche Möglichkeiten ein VIOS hat, der bei ihm gegenwärtig abläuft, wenn der VIOS Teil eines Clusters ist, und das der VIOS möglicherweise betreiben kann. 4B veranschaulicht den Datenaustausch zwischen einem Management-Tool 18 wie etwa dem Systemdirektor der IBM Corporation gemäß einer Ausführungsform und den VIOS-Knoten in dem DPS 100.
  • VIOS-Cluster-Mobility
  • Gemäß einer oder mehreren Ausführungsformen gelten die Algorithmen/Funktions-Software-Module, die durch das CM-Dienstprogramm 222 bereitgestellt werden, auch für die Verschiebung von VIOS von einem ersten CEC, der hier als Quellen-CEC bezeichnet wird, zu einem zweiten CEC, der hier als Ziel- oder Soll-CEC bezeichnet wird. Eine der Rollen, die durch den VIOS eingenommen wird, um die Effizienz einer Mobility-Operation in dem cluster-bewussten DPS 100 zu ermöglichen, besteht darin, den Speicher, der in dem Quellen-CEC in Verwendung ist, für den VIOS in dem Ziel-CEC zu beschreiben. Die durch den ersten VIOS 112a bereitgestellte Beschreibung enthält einen Schlüssel zu einer Adaptertabelle für den Quellenadapter. Der Schlüssel wird verwendet, um den Client (114) und eindeutige Adapterkennungs-Informationen anhand der Datenbankbeziehung (z.B. die Zuordnung von Datenstrukturen (z.B. Tabellen) in der Datenbank) zu finden. Die eindeutige Adapterkennung wird zur Kernerweiterung geleitet, die einen Speicherzugriff bestätigt. Der PHYP signalisiert die Beendigung der Mobility-Operation und als Teil dieser Vollendung wird die Zeile in der VIOS-Tabelle mit der neuen relativen Kennung des CEC aktualisiert. Während die Verschiebung der bestimmten LPAR abgeschlossen wird, wird somit die eindeutige Adapterkennung, die dieser OS-Partition zugewiesen ist, in der Datenbank (verteiltes Speicher-Repository 150) nicht geändert. Die relative Kennung des CEC ermöglicht, dass der VIOS entdeckt wird, obwohl die eindeutige Adapterkennung eine sichere Umsetzung von Speicherpool-Zugangsrechten ermöglicht. Dieses Schema ermöglicht eine Flexibilität bei der Umsetzung von Management-Tools für eine Poolsicherheit, wodurch eine bequeme Verwendung durch den Systemadministrator möglich ist.
  • Wiederherstellung nach einem Fehler während Cluster Partition Mobility
  • In einer Ausführungsform sind bestimmte Funktionskomponenten des CM-Dienstprogramms 222 in lokalen Speichereinheiten codiert, die für einen entsprechenden VIOS 112 zugänglich sind, so dass sich der VIOS 112 in dem Cluster sofort anmelden kann und die erforderliche CM-Software, Informationen und/oder Daten abrufen/herunterladen kann oder von der DB 140 weitergeleitet bekommt (bei erfolgreicher Anmeldung in dem Cluster), um cluster-bewusst zu werden, wenn der VIOS in dem CEC 110 erstmalig aktiviert wird. Zusätzlich zu den lokal gespeicherten Software-Dienstprogramm-Komponenten des CM-Dienstprogramms 222 können weitere Funktionskomponenten des CM-Dienstprogramms 222 von der DB 140 heruntergeladen werden, wenn der CEC eingeschaltet wird oder wenn ein oder mehrere VIOSes 112 und/oder eine oder mehrere neue Client-LPARs 114 in dem CEC 110 freigegeben werden. Außerdem wird gemäß den gegenwärtig beschriebenen Ausführungsformen ein zusätzliches Dienstprogramm in dem CEC bereitgestellt, um eine Wiederherstellung nach einem Fehler während Live Partition Mobility zu ermöglichen. Das Live Partition Mobility-(LPM-) Dienstprogramm wird in einem CEC ausgeführt, von dem eine Client-Partition einer Live Mobility-Operation von einem Quellen-VIOS in dem ersten CEC zu einem Ziel-VIOS in einem zweiten CEC unterzogen wird. Das LPM-Dienstprogramm aktiviert ein LPM-Modul (des CM-Dienstprogramms des CA_OS) in dem Quellen-VIOS und einem oder mehreren weiteren VIOSes des Clusters, zu denen der Ziel-VIOS gehört.
  • Gemäß einer oder mehreren Ausführungsformen und wie in den 5A und 5B veranschaulicht, ist das LPM-Dienstprogramm 550 als ein Teil des Management-Tools 180 und/oder der Managementkonsole 175 umgesetzt. Weitere Ausführungsformen können vorsehen, dass das LPM-Dienstprogramm in dem PHYP 225 angeordnet oder diesem zugeordnet ist. In 5A ist ein Datenverarbeitungssystem mit Hardware- und Software-Komponenten dargestellt, das verwendet werden kann, um eine Live Partition Mobility in einem VIOS-Cluster gemäß einer oder mehreren Ausführungsformen auszulösen und zu unterstützen. Das veranschaulichte Verarbeitungssystem gewährleistet/unterstützt die Funktionalität einer beispielhaften Managementkonsole und wird deswegen zur Konsistenz hier als Managementkonsole 175 bezeichnet. Es ist klar, dass die physische Konfiguration der Managementkonsole 175 von der in 5A veranschaulichten verschieden sein kann, und dass die hier dargestellte spezielle Konfiguration lediglich für Erläuterungszwecke bereitgestellt wird.
  • Wie dargestellt, weist die Managementkonsole 175 einen Prozessor 502 auf, der zum Datenaustausch über den Systembus/Interconnect 504 mit dem lokalen Speicher 506 und der E/A-Controller/Brücke 510 verbunden ist. Die E/A-Controller/Brücke 510 weist einen zugehörigen E/A-Bus auf, mit dem eine oder mehrere E/A-Einheiten verbunden sind, von denen eine Tastatur 514 und eine Zeigeeinheit 516 (z.B. Maus) und eine Anzeige 520 dargestellt sind. Die Anzeige 520 verbindet über einen Grafik/Anzeigeadapter 518 mit dem E/A-Bus 512. Außerdem sind eine Netzwerk-Schnittstelle 522 und ein E/A-Adapter 524 mit dem E/A-Bus 512 verbunden. Die Netzwerk-Schnittstelle ermöglicht eine Verbindung mit einem externen Netzwerk, wie zum Beispiel durch das Netzwerk-Fabric 170 (1A bis 1C) dargestellt. Der E/A-Adapter 524 kann ein beliebiger E/A-Adapter sein, der eine E/A-Verbindung mit einer E/A-Einheit und/oder einem anderen Datenverarbeitungssystem wie etwa der CEC 110 (1A bis 1C und 2) ermöglicht. Die Managementkonsole 175 enthält ferner eine Speichereinheit 530, in der Befehle/Code/Daten in Bezug auf Vorgänge in der Managementkonsole gespeichert sein können.
  • Zusätzlich zu diesen Hardware-Komponenten sind in dem Lokalspeicher 506 eine Vielzahl von Software-Komponenten angeordnet, die der Managementkonsole 175 ermöglichen, als eine Managementeinheit in einer VIOS-Cluster-Umgebung zu funktionieren. Unter diesen Software-Komponenten sind ein lokales OS 508 und ein Management-Tool 180 vorhanden. Wie zuvor beschrieben, unterstützt/gewährleistet das Management-Tool 180 bestimmte Funktionen in Bezug auf das Management eines VIOS-Clusters, darunter das Auslösen des Setup der einzelnen Client-LPARs, die speziellen Clients zugewiesen sind, und Gesamt-Managementfunktionen, die den Client-LPARs und den VIOSes in einem CEC oder in dem VIOS-Cluster zugehörig sind. Spezifisch zu den gegenwärtig beschriebenen Ausführungsformen stellt das Management-Tool 180 das LPM-Dienstprogramm 550 bereit bzw. weist dieses auf, das im Prozessor 502 ausgeführt wird, um eine Vielzahl von Funktionen bereitzustellen, die den Operationen Live Partition Mobility in einem VIOS-Cluster zugehörig sind. Funktionen der Datenübertragung des Management-Tools 180 (und/oder des LPM-Dienstprogramms 550) zu den VIOSes können in einer Ausführungsform über die Virtualisierungs-Management-Komponente 225 realisiert werden. In den gegebenen Ausführungsformen können einige der Merkmale des LPM-Dienstprogramms 180 ebenso in den VIOSes bereitgestellt werden und die Ausführungsformen werden ohne spezielle Einschränkung beschrieben, ob die Merkmale in der Managementkonsole 175 oder in einem VIOS 112, mit dem das Management-Tool zum Datenaustausch verbunden ist, umgesetzt sind.
  • In einer Ausführungsform stellt das LPM-Dienstprogramm 550 Code/Programmbefehle bereit, die auf einem oder mehreren virtuellen Prozessorressourcen eines oder mehrerer VIOSes 112 im CEC 110 und/oder auf dem Prozessor 502 der Managementkonsole 175 ausgeführt werden, um spezielle Funktionen bereitzustellen. Unter der beim Ausführen des LPM-Dienstprogramms 550 bereitgestellten Funktionalität, die hier genauer beschrieben wird, ist die folgende nicht ausschließliche Liste: (a) Erzeugen eines ersten Monitor-Threads in einem ersten VIOS, um den Status eines LPM-Ereignisses zu verfolgen; Aufzeichnen von Informationen über das LPM-Ereignis in einer Datenbank unter Verwendung des ersten Monitor-Threads; (b) Identifizieren einer ersten Menge von funktionierenden Monitor-Threads, die weiterhin in einem ersten Quellenserver funktionieren, wenn der erste VIOS und der erste Monitor-Thread abgestürzt sind; (c) Feststellen, ob es sich bei der ersten Menge von funktionierenden Monitor-Threads um einen einzelnen letzten Monitor-Thread handelt; und (d) wenn Knoten in dem ersten Server vorhanden sind, die eine oder mehrere im Voraus identifizierte Fehlerbedingungen (aus der nicht ausschließenden Liste aus (a) der VIOS kann keine E/A-Operationen mehr ausführen, (b) der VIOS geht offline oder (c) der VIOS ist aus dem Cluster entfernt) aufweisen, Ausführen von Aktualisierungsoperationen in der Datenbank über den letzten Monitor-Thread anhand der Angabe, dass in dem ersten Server Knoten vorhanden sind, die in einem abgestürzten Zustand sind.
  • In 5B ist ein beispielhafter VIOS-Cluster (d.h. eine cluster-bewusste Sammlung von VIOSes) dargestellt, der so konfiguriert ist, dass er ein Live Partition Mobility-(LPM-) Ereignis gemäß einer Ausführungsform wirkungsvoll unterstützt. Gemäß einer oder mehrerer Ausführungsformen berücksichtigen die Algorithmen/Funktions-Software-Module, die durch das LPM-Dienstprogramm 550 bereitgestellt werden, ebenfalls die Migration einer LPAR (z.B. LPAR 114A) vom Quellen-CEC 110A zum Ziel/Soll-CEC 110B. Jeder VIOS in dem VIOS-Cluster (DPS 100) kann als ein Knoten in dem Cluster betrachtet werden.
  • In Reaktion auf das Erfassen des Beginns eines LPM-Ereignisses löst das LPM-Dienstprogramm 550 die Erzeugung eines ersten Monitor-Threads (z.B. durch die Verwendung des Monitor-Thread-Moduls 504) in dem ersten VIOS 112A in Übereinstimmung mit dem LPM-Ereignis aus. Das LPM-Ereignis bezieht sich insbesondere auf den Transfer des LPAR 114A in CEC 110A (d.h. ein erster Server, ein Quellenserver) zum CEC 110B (d.h. zu einem zweiten Server, einem Zielserver) in demselben VIOS-Cluster (DPS 100). Der erste VIOS 112A läuft in dem Quellenserver (z.B. CEC 110A), von dem aus der Client/LPAR 114A gegenwärtig auf den Speicher zugreift. Außerdem löst das LPM-Dienstprogramm 550 die Erzeugung anderer Monitor-Threads (z.B. über das Monitor-Thread-Modul 506) in jedem anderen VIOS (einschließlich VIOS 112B) aus, der auf dem (demselben) Quellenserver läuft. Des Weiteren löst das LPM-Dienstprogramm 550 die Erzeugung von Monitor-Threads im zweiten VIOS im Ziel-Server (z.B. CEC 110B) aus, von dem der Client anschließend auf den Speicher zugreift (d.h. es wird erwartet, dass der Zugriff anschließend erfolgt), nachdem der (migrierte) Client in dem Ziel-Server läuft (z.B. CEC 110B). Ähnlich wie die Erzeugung anderer Monitor-Threads in dem Quellenserver erzeugt das LPM-Dienstprogramm 550 eine Sammlung anderer Monitor-Threads in jedem anderen VIOS (z.B. einschließlich VIOS 112D) in dem Zielserver. Das LPM-Dienstprogramm 550 stellt aktuelle/aktualisierte Informationen über ein bestimmtes LPM-Ereignis bereit, indem ermöglicht wird, dass ein geeigneter Monitor-Thread eine entsprechende Zeile in der „Mobility-Tabelle“ (z.B. Tabelle 510) in der Datenbank 520 der VIOS-DB 140 erzeugt oder aktualisiert. In einer Ausführungsform kann die Mobility-Tabelle 510 einer Datenbank zugehörig sein, die in dem verteilten Speicher-Repository 150 gespeichert ist. Monitor-Threads prüfen ständig den Zustand der LPM durch einen Datenaustausch mit dem Hypervisor 125. Wenn ein bestimmter VIOS (z.B. VIOS 512A) in einem Fehlerzustand ist (oder in einem von mehreren im Voraus definierten Fehlerzuständen ist), gewährleistet das LPM-Dienstprogramm 550 eine Benachrichtigung über den Partitionsfehler an andere funktionierende Knoten/VIOSes. Das LPM-Dienstprogramm 550 ermöglicht, dass ein funktionierender Monitor-Thread den LPM-Status in der Tabelle 510 aktualisiert. Im Einzelnen kann ein letzter Monitor-Thread Aktualisierungsoperationen in der Datenbank anhand einer Angabe ausführen, dass in dem ersten Server Knoten vorhanden sind, die in einem Fehlerzustand sind. Die Nutzung der Mobility-Tabelle 510, um bei Cluster Partition Mobility eine Mehrknoten-Wiederherstellung nach einem Fehler bereitzustellen, wird ferner in 6 beschrieben.
  • 6 veranschaulicht eine beispielhafte Mobility-Tabelle, die durch einen Monitor-Thread während eines LPM-Ereignisses gemäß einer Ausführungsform aktualisiert wird. Die Tabelle 510 stellt Informationen über drei beispielhafte LPM-Ereignisse in drei Zeilen der Tabelle 510 bereit. In Tabelle 510 erzeugt ein erster Monitor-Thread, der dem Monitor-Thread-Modul 504 zugehörig ist, die Zeile 602, wenn ein LPM-Ereignis, das der LPAR 114A zugehörig ist, ausgelöst wird. In einer Ausführungsform ermöglicht das LPM-Dienstprogramm 550, dass eine (relationale) Datenbank auf eine Client-Partitionstabelle zeigt, um die Client-Partition zu beobachten und Informationen über den Client (z.B. „Client1“) bereitzustellen. Des Weiteren ermöglicht das LPM-Dienstprogramm 550, dass die Datenbank auf mehrere Client-Partitionstabellen abgebildet wird, jeweils eine für jeden VIOS, der an dem LPM-Ereignis beteiligt ist und/oder in dem Quellenserver läuft. In dem Datenbank-System für Cluster-VIOSes können diese Client-Partitionstabellen gemeinsam als die Client-Mobility-Tabelle bezeichnet werden. In einer Ausführungsform erfasst das LPM-Dienstprogramm 550 den Beginn eines LPM-Ereignisses und ermöglicht, dass ein bestimmter Monitor-Thread die Zeile in der Mobility-Tabelle 510 erzeugt. In einer Ausführungsform stellt das LPM-Dienstprogramm 550 fest, ob ein bestimmtes LPM-Ereignis bereits eine Zeile in einer Mobility-Tabelle reserviert hat. Wenn das bestimmte LPM-Ereignis noch nicht in die Mobility-Tabelle aufgenommen wurde, ermöglicht das LPM-Dienstprogramm 550, dass der erste Monitor-Thread des VIOS, in dem der LPM-Vorgang ausgelöst wurde, die geeignete Zeile in der Mobility-Tabelle 510 erzeugt. Wenn das bestimmte LPM-Ereignis bereits zuvor in die Mobility-Tabelle aufgenommen wurde, ermöglicht das LPM-Dienstprogramm 550, dass der erste Monitor-Thread oder ein anderer geeigneter (z.B. ein letzter) Monitor-Thread die entsprechende Zeile der Mobility-Tabelle aktualisiert.
  • In der aktualisierten/erzeugten Zeile 502 ermöglicht das LPM-Dienstprogramm 550 die Speicherung von Informationen über (a) den Server (z.B. CEC 110A), auf dem der Monitor-Thread basiert, (b) den Client (z.B. „Client1“, der die LPAR 114A steuert/nutzt), für den das zugehörige LPM durch den Monitor-Thread überwacht wird, und (c) den aktuellen Zustand des Knotens/VIOS (d.h. ob der Knoten/VIOS läuft oder abgestützt ist) in Übereinstimmung mit dem überwachten LPM-Vorgang. Die Zeile 502 gibt z.B. an, dass die LPAR1 gegenwärtig „läuft“.
  • Da ein erster Monitor-Thread in dem Fall, dass die Partition (z.B. VIOS 512A und zugehörige LPAR) ausfällt, aufhört zu existieren, hält das LPM-Dienstprogramm 550 das Zustandsfeld in der Datenbank (z.B. VIOS-DB 140) durch die durch das cluster-bewusste DPS 100 bereitgestellten Funktionen aktuell. Das heißt, wenn das Cluster einen Knotenausfall erkennt, aktualisiert das Cluster das Zustandsfeld in der geeigneten Zeile der VIOS-Tabelle, so dass es „ausgefallen“ angibt. Monitor-Threads prüfen fortwährend den Zustand des LPM durch Datenübertragung mit dem Hypervisor 125. Wenn eine Migration abgeschlossen wird, führt der erste Monitor-Thread bestimmte Aktionen aus, die möglicherweise das Löschen von Speicherressourcen und das Entfernen einer entsprechenden Zeile aus der Mobility-Tabelle 510 beinhalten. Der erste Monitor-Thread führt diese erwarteten und erforderlichen Funktionen aus, bis ein Knoten (VIOS) während eines LPM-Vorgangs ausfällt (und folglich der erste Monitor-Thread ebenfalls ausfällt).
  • Wenn der erste Monitor-Thread (z.B. wegen eines VIOS-Fehlerzustands) ausfällt, verwendet das LPM-Dienstprogramm 550 andere Monitor-Threads, die in demselben CEC funktionsfähig bleiben, um die Arbeit, die der ausgefallene Monitor-Thread nicht ausführen kann, wie folgt zu erledigen: wenn ein Monitor-Thread benachrichtigt wird, dass die LPM-Operation vorüber ist (abgeschlossen oder fehlgeschlagen), wird der Monitor-Thread außerdem mit einem Zählwert darüber versorgt, wie viele andere Threads in dem Server gegenwärtig die Migration überwachen. Wenn der benachrichtigte Monitor-Thread der letzte ist, ermöglicht das LPM-Dienstprogramm 550, dass der „letzte“ Monitor-Thread die Mobility-Datenbanktabelle 510 abfragt, um festzustellen, ob in demselben Server Knoten vorhanden sind, die im ausgefallenen/abgestützten Zustand sind. Für alle Einträge, die der (letzte) Monitor-Thread im abgestützten Zustand findet (z.B. LPAR2 der (zweiten) Zeile 504), führt der Monitor-Thread Operationen aus, die erforderlich sind, um die Datenbank aktuell/konsistent zu halten, und entfernt anschließend die Zeile aus der Tabelle 510.
  • Demzufolge werden mehrere Knotenausfälle toleriert, vorausgesetzt, dass wenigstens ein einziger Knoten, der an der LPM-Operation beteiligt ist, überlebt (und einen „letzten“ Monitor-Thread bereitstellt). In einer Ausführungsform kann das LPM-Dienstprogramm 550 die Migration bis zu einer bestimmten Stufe in dem Migrationsvorgang rückgängig machen. Somit kehrt das Dienstprogramm z.B. in Reaktion darauf, dass die LPM-Operation als ein Ergebnis eines Fehlerzustands beendet wurde, zu einer bestimmten Stufe eines entsprechenden Migrationsvorgangs zurück, um die Mobility-Operation wiederaufzunehmen und abzuschließen. Wenn der LPM-Vorgang fehlschlägt, kann das LPM-Dienstprogramm 550 eine Beendigung der Verwendung von Ressourcen in dem Zielserver auslösen. Wenn der LPM-Vorgang andererseits erfolgreich ist, kann das LPM-Dienstprogramm 550 die Verwendung von Ressourcen in dem Quellenserver beenden. Als ein Ergebnis der Merkmale der Cluster-Bewusstheit und Charakteristiken des DPS 100 gibt der Eintrag der dritten Zeile 506 in der Tabelle 510 derselben gemeinsam genutzten VIOS-DB 140 an, dass eine bestimmte Partition (d.h. LPAR3), die an einem LPM-Ereignis beteiligt ist und auf einem anderen Server (z.B. CEC 110B) basiert, ebenfalls durch einen Monitor-Thread in dem Cluster (d.h. DPS 100) überwacht wird.
  • Die 7 bis 8 sind Ablaufpläne, die verschiedene Verfahren darstellen, durch die die obigen Vorgänge der veranschaulichenden Ausführungsformen abgeschlossen werden. Obwohl die in den 7 bis 8 dargestellten Verfahren unter Bezugnahme auf Komponenten und eine Funktionalität, die durch die 1 bis 6 und unter Bezugnahme auf diese dargestellt und beschrieben wurden, beschrieben werden können, sollte klar sein, dass das lediglich der Zweckmäßigkeit dient und alternative Komponenten und/oder Konfigurationen hiervon verwendet werden können, wenn die verschiedenen Verfahren umgesetzt werden. Bestimmte Teile der Verfahren können durch das LPM-Dienstprogramm 550 abgeschlossen werden, das in einem oder mehreren (virtuellen) Prozessoren (CPU 206A) im VIOS 112 (1 oder 2) oder in Verarbeitungsressourcen des Management-Tools 180 (in der Managementkonsole 175) oder in der DB 140 ausgeführt wird. Die ausgeführten Vorgänge steuern dann spezifische Operationen der oder in den CECs 110, Client-LPARs 114, VIOSes 112, DB 140 und/oder im verteilten Datenspeicher 150. Zur Einfachheit bei der Beschreibung der Verfahren werden alle Verfahrensvorgänge aus der Perspektive des LPM-Dienstprogramms 550 und/oder des VIOS/Knotens 112 beschrieben.
  • 7 veranschaulicht das Verfahren, durch welches ein VIOS-Cluster ein LPM-Ereignis überwacht, eine Mobility-Tabelle aktualisiert und eine Wiederherstellung nach einem Fehler gemäß einer Ausführungsform gewährleistet. Das Verfahren beginnt im Auslöseblock 702 und geht vor zum Block 704, in dem das LPM-Dienstprogramm 550 die Auslösung eines LPM-Ereignisses erfasst. Im Block 706 löst das LPM-Dienstprogramm 550 die Erzeugung eines ersten Monitor-Threads in dem VIOS, der dem LPM-Ereignis entspricht, und anderer Monitor-Threads in VIOSes in dem Quellenserver, von dem der Client gegenwärtig auf den Speicher zugreift, aus. Im Block 708 ermöglicht das LPM-Dienstprogramm 550, dass der erste Monitor-Thread eine Zeile der Mobility-Tabelle 510 aktualisiert/erzeugt. Im Block 710 löst das LPM-Dienstprogramm 550 durchgängige Prüfungen des LPM-Zustands durch einen Datenaustausch mit dem PHYP über einen oder mehrere Monitor-Threads aus. Im Block 712 erfasst das LPM-Dienstprogramm 550 Fehler des Knotens/VIOS, der dem LPM-Ereignis entspricht. Im Block 714 benachrichtigt das LPM-Dienstprogramm 550 den Cluster über den Knotenfehler. Das LPM-Dienstprogramm 550 ermöglicht, dass der Cluster und insbesondere die anderen Monitor-Threads in den VIOSes in dem Quellenserver den LPM-Zustand auf abgestützt aktualisieren, wie im Block 716 gezeigt. Im Entscheidungsblock 718 stellt das LPM-Dienstprogramm 550 fest, ob die LPAR-Migration erfolgreich abgeschlossen oder abgebrochen wurde. Wenn das LPM-Dienstprogramm 550 feststellt, dass die LPAR-Migration abgebrochen oder erfolgreich abgeschlossen wurde, entfernt das LPM-Dienstprogramm 550 die entsprechende Zeile aus der Mobility-Tabelle 510 wie im Block 720 gezeigt. Wenn das LPM-Dienstprogramm 550 feststellt, dass die LPAR-Migration nicht abgebrochen oder erfolgreich abgeschlossen wurde, geht der Vorgang zurück zum Block 722, wobei der Vorgang in diesem Block endet.
  • 8 veranschaulicht das Verfahren, durch welches der VIOS-Cluster einen Monitor-Thread verwendet, der funktionsfähig/aktiv bleibt, nachdem ein erster Monitor-Thread ausgefallen ist, um gemäß einer Ausführungsform eine Datenbank aktuell zu halten und eine Datenbank-Konsistenz zu gewährleisten. Das Verfahren beginnt im Block 802 und geht vor zum Block 804, in dem das LPM-Dienstprogramm 550 ein LPM-Ereignis über einen (ersten) Monitor-Thread überwacht. Im Entscheidungsblock 806 stellt das LPM-Dienstprogramm 550 fest, ob das LPM-Ereignis beendet ist (d.h. entweder abgebrochen oder abgeschlossen). Wenn das LPM-Dienstprogramm 550 feststellt, dass das LPM-Ereignis beendet ist, empfängt das LPM-Dienstprogramm 550 einen Zählstand, der die Anzahl von anderen Threads angibt, die gegenwärtig das LPM-Ereignis überwachen, wie im Block 808 gezeigt. Wenn das LPM-Dienstprogramm 550 feststellt, dass das LPM-Ereignis nicht beendet ist, kehrt der Vorgang zum Block 804 zurück. Im Block 810 löst das LPM-Dienstprogramm 550 eine Prüfung aus, um festzustellen, ob es sich bei einem bestimmten Monitor-Thread, der Zählstand-Informationen empfängt, um den letzten Monitor-Thread handelt. Im Entscheidungsblock 812 stellt das LPM-Dienstprogramm 550 fest, ob die Zählstand-Informationen von einem einzigen/letzten verbleibenden (und funktionierenden) Monitor-Thread empfangen wurden. Wenn das LPM-Dienstprogramm 550 im Entscheidungsblock 812 feststellt, dass die Zählstand-Informationen von dem letzten Monitor-Thread empfangen wurden, ermöglicht das LPM-Dienstprogramm 550, dass der letzte Monitor-Thread die Datenbank/Tabelle abfragt, um festzustellen, ob im Server Knoten in einem fehlerhaften/abgestürzten Zustand vorhanden sind, wie im Block 814 gezeigt. Wenn das LPM-Dienstprogramm 550 in einer Ausführungsform im Entscheidungsblock 812 feststellt, dass die Zählstand-Informationen nicht von dem letzten Monitor-Thread empfangen wurden (d.h. mehr als ein funktionierender Monitor-Thread verbleiben), wählt das LPM-Dienstprogramm 550 einen bestimmten Monitor-Thread zum Abfragen der Datenbank/Tabelle aus, um festzustellen, ob im Server Knoten im abgestürzten Zustand vorhanden sind, wie im Block 815 gezeigt. Im Entscheidungsblock 816 stellt das LPM-Dienstprogramm 550 fest, ob in dem Server VIOSes/Knoten im ausgefallenen/abgestürzten Zustand vorhanden sind. Wenn das LPM-Dienstprogramm 550 feststellt, dass in dem Server VIOSes/Knoten im ausgefallenen/abgestürzten Zustand vorhanden sind, entfernt das LPM-Dienstprogramm 550 die Zeile (über den letzten oder ausgewählten Monitor-Thread), die dem einen oder mehreren ausgefallenen/abgestürzten VIOSes entspricht, aus der Mobility-Tabelle 510, wie im Block 818 gezeigt. Wenn das LPM-Dienstprogramm 550 feststellt, dass keine VIOSes/Knoten in dem Server im abgestürzten Zustand sind, geht der Vorgang zum Block 820, wobei der Vorgang in diesem Block endet.
  • Die hier in den verschiedenen Figuren dargestellten und beschriebenen Ablaufpläne und Blockschaubilder veranschaulichen die Architektur, die Funktionalität und den Betrieb von möglichen Umsetzungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in dem Ablaufplan oder Blockschaubildern ein Modul, Segment oder Abschnitt von Code, das/der einen oder mehrere ausführbare Befehle zum Umsetzen der spezifizierten logischen Funktion(en) aufweist, repräsentieren. Es sollte außerdem angemerkt werden, dass in einigen alternativen Umsetzungen die in dem Block angegebenen Funktionen in einer anderen als in der in den Figuren angegebenen Reihenfolge auftreten können. Zum Beispiel können zwei Blöcke, die nacheinander gezeigt sind, tatsächlich im Wesentlichen gleichzeitig ausgeführt werden oder die Blöcke können gelegentlich in Abhängigkeit von der beteiligten Funktionalität in der umgekehrten Reihenfolge ausgeführt werden. Es wird außerdem angemerkt, dass jeder Block der Blockschaubilder und/oder Ablaufplan-Darstellung und Kombinationen von Blöcken in den Blockschaubildern und/oder der Ablaufplan-Darstellung durch auf spezielle Hardware gestützte Systeme, die die spezifizierten Funktionen oder Wirkungen ausführen, oder Kombinationen aus spezieller Hardware und Computerbefehlen umgesetzt werden können.
  • In dem obigen Ablaufplan werden das eine oder die mehreren Verfahren in einem computerlesbaren Medium ausgeführt, das computerlesbaren Code enthält, so dass eine Reihe von Schritten ausgeführt werden kann, wenn der computerlesbare Code (durch eine Verarbeitungseinheit) in einer Datenübertragungseinheit ausgeführt wird. Bei einigen Umsetzungen werden bestimmte Vorgänge der Verfahren kombiniert, gleichzeitig oder in einer anderen Reihenfolge ausgeführt oder möglicherweise weggelassen, ohne vom Umfang der Erfindung abzuweichen. Während die Verfahrensvorgänge in einer bestimmten Abfolge beschrieben und dargestellt werden, ist deswegen die Verwendung einer speziellen Abfolge der Vorgänge nicht so gemeint, dass sie irgendwelche Einschränkungen an der Erfindung implizieren. Änderungen können im Hinblick auf die Abfolge von Vorgängen gemacht werden, ohne vom Umfang der vorliegenden Erfindung abzurücken. Die Verwendung einer bestimmten Abfolge sollte deswegen nicht in einschränkenden Sinn aufgefasst werden und der Umfang der vorliegenden Erfindung erstreckt sich auf die beigefügten Ansprüche und ihre Entsprechungen.
  • Wie dem Fachmann klar sein wird, können Aspekte der vorliegenden Erfindung als System, Verfahren oder Computerprogrammprodukt ausgeführt werden. Dementsprechend können Aspekte der vorliegenden Erfindung die Form einer reinen Hardware-Ausführungsform, einer reinen Software-Ausführungsform (die Firmware, residente Software, Mikrocode usw. enthält) oder einer Ausführungsform, die Software- und Hardware-Aspekte kombiniert, annehmen, die hier alle allgemein als „Schaltung“, „Modul“ oder „System“ bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien verkörpert ist, die computerlesbaren Programmcode, der darauf verkörpert ist, aufweisen.
  • Jede Kombination aus einem oder mehreren computerlesbaren Medien kann verwendet werden. Das computerlesbare Medium kann ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium sein. Ein computerlesbares Speichermedium kann z.B. ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem, -vorrichtung oder -einheit oder jede geeignete Kombination des Vorhergehenden sein, ist jedoch nicht auf diese beschränkt. Zu spezifischeren Beispielen (eine nicht erschöpfende Liste) des computerlesbaren Speichermediums würde Folgendes gehören: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Festwertspeicher (ROM), ein löschbarer programmierbarer Festwertspeicher (EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compactdisk-Festwertspeicher (CD-ROM), eine optische Speichereinheit, eine magnetische Speichereinheit oder jede geeignete Kombination des Vorhergehenden. Im Kontext dieses Dokuments kann ein computerlesbares Speichermedium jedes materielle Medium sein, das ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung enthalten oder speichern kann.
  • Ein computerlesbares Signalmedium kann ein verbreitetes Datensignal mit einem computerlesbaren Programmcode, der darin z.B. im Basisband oder als Teil einer Trägerwelle ausgeführt verkörpert ist, enthalten. Ein derartiges verbreitetes Signal kann jede von einer Vielzahl von Formen annehmen, zu denen elektromagnetische, optische Formen oder jede geeignete Kombination hiervon gehören, die jedoch nicht auf diese beschränkt sind. Ein computerlesbares Signalmedium kann jedes computerlesbare Medium sein, das kein computerlesbares Speichermedium ist und ein Programm zur Verwendung durch oder in Verbindung mit einem System, einer Vorrichtung oder einer Einheit zur Befehlsausführung kommunizieren, verbreiten oder transportieren kann.
  • Programmcode, der auf einem computerlesbaren Medium verkörpert ist, kann unter Verwendung jedes geeigneten Mediums übertragen werden, wozu drahtlose, leitungsgestützte, Lichtwellenleiterkabel-, HF-Medien oder jede geeignete Kombination aus dem Vorhergehenden gehören, die jedoch nicht auf diese beschränkt sind. Computerprogrammcode zum Ausführen von Operationen für Aspekte der vorliegenden Erfindung kann in jeder Kombination aus einer oder mehreren Programmiersprachen geschrieben sein, einschließlich einer objektorientierten Programmiersprache wie Java, Smalltalk, C++ oder dergleichen und herkömmlicher prozeduraler Programmiersprachen wie etwa die Programmiersprache „C“ oder ähnliche Programmiersprachen. Der Programmcode kann nur auf dem Computer eines Benutzers, teilweise auf dem Computer eines Benutzers, als ein selbstständiges Software-Paket, teilweise auf dem Computer eines Benutzers und teilweise auf einem fernen Computer oder nur auf dem fernen Computer oder Server ausgeführt werden. In dem zuletzt genannten Szenario kann der ferne Computer mit dem Computer des Benutzers durch jeden Netzwerktyp verbunden sein, einschließlich eines Lokalbereichs-Netzwerks (LAN) oder eines Weitbereichs-Netzwerks (WAN), oder die Verbindung kann zu einem externen Computer (z.B. über das Internet unter Verwendung eines Internet-Dienstanbieters) hergestellt werden.
  • Aspekte der vorliegenden Erfindung sind hier unter Bezugnahme auf Ablaufplan-Darstellungen und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es ist klar, dass jeder Block der Ablaufplan-Darstellungen und/oder Blockschaubilder und Kombinationen von Blöcken in den Ablaufplan-Darstellungen und/oder Blockschaubildern durch Computerprogrammbefehle umgesetzt werden können. Diese Computerprogrammbefehle können einem Prozessor eines Mehrzweck-Computers, eines speziellen Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu bilden, so dass Befehle, die über den Prozessor des Computers oder der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Umsetzen der Funktionen/Wirkungen, die in dem Block oder den Blöcken des Ablaufplans und/oder Blockschaubilds spezifiziert sind, erzeugen.
  • Diese Computerprogrammbefehle können außerdem in einem computerlesbaren Medium gespeichert sein, das einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder andere Einheiten anweisen kann, in einer bestimmten Weise zu funktionieren, so dass die in dem computerlesbaren Medium gespeicherten Befehle einen Herstellungsgegenstand produzieren, wozu Befehle gehören, die die Funktion/Wirkung umsetzen, die in dem Block/den Blöcken des Ablaufplans und/oder Blockschaubilds spezifiziert sind. Die Computerprogrammbefehle können außerdem in einen Computer, andere programmierbare Datenverarbeitungsvorrichtungen oder andere Einheiten geladen werden, um eine Reihe von Operationsschritten zu bewirken, die auf dem Computer, der anderen programmierbaren Datenverarbeitungsvorrichtung oder anderen Einheiten ausgeführt werden sollen, um einen mittels Computer umgesetzten Prozess zu erzeugen, so dass die Befehle, die auf dem Computer oder der anderen programmierbaren Vorrichtung ausgeführt werden, Prozesse zum Umsetzen der Funktionen/Wirkungen, die in dem Block oder Blöcken des Ablaufplans und/oder Blockschaubilds spezifiziert sind, bereitstellen.
  • Wie ferner klar ist, können die Vorgänge in Ausführungsformen der vorliegenden Erfindung unter Verwendung einer beliebigen Kombination aus Software, Firmware und Hardware umgesetzt sein. Als ein Vorbereitungsschritt zum Realisieren der Erfindung in Software wird der Programmcode (ob nun Software oder Firmware) üblicherweise in einem oder mehreren maschinenlesbaren Speichermedien wie etwa feststehende Laufwerke (Festplattenlaufwerke), Disketten, optische Platten, Magnetband, Halbleiterspeicher wie z.B. ROM, PROM usw. gespeichert, um dadurch einen Herstellungsgegenstand gemäß der Erfindung zu bilden. Der Herstellungsgegenstand, der den Programmcode enthält, wird verwendet, indem der Code direkt von der Speichereinheit ausgeführt wird, der Code von der Speichereinheit in eine andere Speichereinheit wie z.B. eine Festplatte, ein RAM usw. kopiert wird oder der Code für eine Fernausführung unter Verwendung von Medien des Übertragungstyps wie z.B. digitale und analoge Datenübertragungsverbindungen übertragen wird. Die Verfahren der Erfindung können realisiert werden, indem eine oder mehrere maschinenlesbare Speichereinheiten, die den Code gemäß der vorliegenden Erfindung enthalten, mit einer geeigneten Verarbeitungshardware kombiniert werden, um den darin enthaltenen Code auszuführen. Eine Vorrichtung zum Realisieren der Erfindung können eine oder mehrere Verarbeitungseinheiten und Speichersysteme sein, die ein oder mehrere Programme enthalten, die erfindungsgemäß codiert sind, bzw. einen Netzwerkzugang auf diese aufweisen.
  • Während eine veranschaulichende Ausführungsform der vorliegenden Erfindung im Kontext eines voll funktionsfähigen Computer- (Server-) Systems mit installierter (oder ausgeführter) Software beschrieben ist, ist es somit wichtig, dass es für einen Fachmann klar sein wird, dass die Software-Aspekte einer veranschaulichenden Ausführungsform der vorliegenden Erfindung als ein Programmprodukt in vielfältigen Formen verteilt sein können und dass eine veranschaulichende Ausführungsform der vorliegenden Erfindung unabhängig von dem bestimmten Typ von Medien, der tatsächlich zum Ausführen der Verteilung verwendet wird, gleichermaßen gilt.
  • Während die Erfindung unter Bezugnahme auf beispielhafte Ausführungsformen beschrieben wurde, sollte es einem Fachmann klar sein, dass verschiedene Änderungen ausgeführt werden können und für ihre Elemente Entsprechungen eingesetzt werden können, ohne vom Umfang der Erfindung abzuweichen. Außerdem können viele Modifikationen ausgeführt werden, um ein bestimmtes System, eine Einheit oder Komponenten hiervon an die Lehren der Erfindung anzupassen, ohne von deren wesentlichen Umfang abzuweichen. Es ist deshalb vorgesehen, dass die Erfindung nicht auf die bestimmten Ausführungsformen, die zum Ausführen dieser Erfindung offenbart wurden, beschränkt sein soll, sondern dass die Erfindung alle Ausführungsformen enthält, die in den Umfang der angefügten Ansprüche fallen. Darüber hinaus bezeichnet die Verwendung der Ausdrücke erste, zweite usw. keine Reihenfolge der Wichtigkeit, sondern die Ausdrücke erste, zweite usw. werden verwendet, um ein Element von einem anderen zu unterscheiden.
  • Die in diesem Zusammenhang verwendete Terminologie dient lediglich dem Zweck der Beschreibung bestimmter Ausführungsformen und ist nicht vorgesehen, die Erfindung zu beschränken. Die hier verwendete Singularformen „ein“ und „der/die/das“ sollen außerdem die Pluralformen enthalten, falls im Kontext nicht anders angegeben. Es ist ferner klar, dass die Ausdrücke „weist auf“ und/oder „aufweisend“, wenn sie in dieser Spezifikation verwendet werden, das Vorhandensein von festgestellten Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen und/oder Komponenten spezifizieren, jedoch nicht das Vorhandensein oder die Hinzufügung eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte Operationen, Elemente, Komponenten und/oder Gruppen hiervon ausschließen.
  • Die entsprechenden Strukturen, Materialien, Wirkungen und Ersetzungen aller Mittel oder Schritte plus Funktionselemente in den nachfolgenden Ansprüchen sollen alle Strukturen, Materialien oder Wirkungen zum Ausführen der Funktion in Kombination mit anderen Elementen, die speziell beansprucht werden, enthalten. Die Beschreibung der vorliegenden Erfindung wurde für Zwecke der Erläuterung und Beschreibung dargestellt, es ist jedoch nicht vorgesehen, dass sie in der offenbarten Form für die Erfindung erschöpfend oder einschränkend sein soll. Viele Modifikationen und Variationen werden einem Fachmann erscheinen, ohne vom Umfang und Erfindungsgeist der Erfindung abzuweichen. Die Ausführungsform wurde gewählt und beschrieben, um die Grundgedanken der Erfindung und der praktischen Anwendung am besten zu erläutern und um Nicht-Fachleute zu befähigen, die Erfindung in Bezug auf verschiedene Ausführungsformen mit zahlreichen Modifikationen zu verstehen, wie sie für die vorgesehene praktische Verwendung geeignet sind.

Claims (19)

  1. Verfahren zum Betreiben eine Datenverarbeitungssystems, wobei das Datenverarbeitungssystem einen Prozessor, einen Speicher, der mit dem Prozessor verbunden ist, wenigstens einen Eingabe/Ausgabe- (E/A-) Adapter, der eine Verbindung mit einem externen Netzwerk mit einem gemeinsam genutzten Speicher-Repository ermöglicht, und eine Vielzahl von virtuellen E/A-Servern (VIOSes), die ein VIOS-Cluster mit einer gemeinsam genutzten Datenbank bilden, aufweist, wobei jeder VIOS cluster-bewusst ist, wobei das Verfahren aufweist: Aktivieren eines ersten Monitor-Threads in einem ersten VIOS eines ersten Servers, um einen Zustand eines Live Partition Mobility- (LPM-) Ereignisses zu verfolgen; Aufzeichnen von Informationen über das LPM-Ereignis in der gemeinsam genutzten Datenbank unter Verwendung des ersten Monitor-Threads; in Reaktion darauf, dass der erste VIOS in einem Fehlerzustand bleibt, Identifizieren eines oder mehrerer funktionierender Monitor-Threads, die in einem Quellenserver weiterhin funktionieren, wobei der Fehlerzustand einen Verlust der Überwachung des LPM-Ereignisses durch den ersten Monitor-Thread zur Folge hat; Feststellen, ob es sich bei dem einen oder den mehreren funktionierenden Monitor-Threads um einen einzigen letzten Monitor-Thread handelt; und in Reaktion darauf, dass ein erster VIOS in dem ersten Server im Fehlerzustand ist, Ausführen von Lösch- und Aktualisierungsoperationen in der gemeinsam genutzten Datenbank über den letzten Monitor-Thread, wobei das Löschen und Aktualisieren in Reaktion auf das Empfangen einer Angabe, dass in dem ersten Server ein oder mehrere Knoten vorhanden sind, die sich in dem Fehlerzustand befinden, ausgeführt werden.
  2. Verfahren nach Anspruch 1, wobei das Aktivieren des ersten Monitor-Threads ferner aufweist: Erfassen der Auslösung eines LPM-Ereignisses; und in Reaktion auf das Erfassen der Auslösung des LPM-Ereignisses, Erzeugen: (a) des ersten Monitor-Threads in dem ersten VIOS in dem ersten Server in dem cluster-bewussten Datenverarbeitungssystem; und/oder (b) einer ersten Menge von Monitor-Threads in anderen VIOSes in dem ersten Server; und/oder (c) einer zweiten Menge von Monitor-Threads in VIOSes in einem zweiten Server, einem Zielserver.
  3. Verfahren nach Anspruch 1 oder Anspruch 2, wobei das Aufzeichnen ferner aufweist: Aufzeichnen von Informationen über das LPM-Ereignis in einer Mobility-Tabelle unter Verwendung des Monitor-Threads, wobei die aufgezeichneten Informationen Informationen enthalten über: (a) einen Client; und/oder (b) den Server; und/oder (c) den Zustand eines entsprechenden VIOS, der an dem LPM-Ereignis beteiligt ist; Feststellen, wann das LPM-Ereignis abgebrochen wird; und in Reaktion darauf, dass das LPM-Ereignis abgebrochen wird, Gewährleisten folgender Aktionen über den ersten Monitor-Thread: (a) zugehörige Aktualisierungen zu Speicherressourcen; und/oder (b) Entfernen eines zugehörigen Eintrags in einer Mobility-Tabelle der Datenbank; und/oder (c) andere Wartungsoperationen.
  4. Verfahren nach einem der vorhergehenden Ansprüche, das ferner aufweist: Erfassen, wenn ein bestimmter VIOS, der einer dem LPM-Ereignis entsprechenden virtualisierten Client-Partition zugehörig ist, einen Fehlerzustand eingenommen hat; in Reaktion auf das Erfassen, dass der bestimmte VIOS den Fehlerzustand eingenommen hat und ein entsprechender Monitor-Thread nicht mehr vorhanden ist, Bereitstellen einer Benachrichtigung über den Fehlerzustand des VIOS an andere VIOSes in demselben Server in dem cluster-bewussten DPS; und Ermöglichen, dass ein oder mehrere der anderen VIOSes in geeigneter Weise den Status des LPM-Ereignisses in der Datenbank aktualisieren.
  5. Verfahren nach einem der vorhergehenden Ansprüche, das ferner aufweist: Auslösen durchgehender Prüfungen des Status des LPM-Ereignisses durch andere Monitor-Threads über einen Datenaustausch der anderen Monitor-Threads mit einem Hypervisor; Feststellen, ob das LPM-Ereignis (a) abgebrochen; oder (b) abgeschlossen; oder (c) in einem Fehlerzustand ist; in Reaktion auf die Beendigung des LPM-Ereignisses, Bereitstellen an die anderen Monitor-Threads von: (a) Informationen, die angeben, dass das LPM-Ereignis beendet ist; und (b) Informationen über einen Zählwert der Menge von anderen Monitor-Threads, die gegenwärtig das LPM-Ereignis überwachen; in Reaktion darauf, dass es sich bei der Menge aus anderen Monitor-Threads um einen einzigen letzten Monitor-Thread handelt, Auslösen einer Abfrage der Datenbank über den letzten Monitor-Thread, um festzustellen, ob in einem geeigneten Server Knoten vorhanden sind, die in einem Fehlerzustand sind; und in Reaktion darauf, dass sich in dem geeigneten Server Knoten in einem Fehlerzustand befinden, Ausführen von Aktualisierungsoperationen über den letzten Monitor-Thread an einer entsprechenden Mobility-Tabelle, zu denen gehören: (a) Operationen, die erforderlich sind, um die Datenbank konsistent und aktuell zu halten; und/oder (b) Entfernen einer entsprechenden Zeile/eines entsprechenden Eintrags aus der entsprechenden Mobility-Tabelle; und/oder (c) andere Wartungsoperationen.
  6. Verfahren nach Anspruch 5, das ferner aufweist: in Reaktion darauf, dass das LPM-Ereignis infolge einer Fehlerbedingung beendet wurde, Zurückkehren zu einer bestimmten Stufe eines entsprechenden Migrationsvorgangs, um die Mobility-Operation wiederaufzunehmen und abzuschließen.
  7. Datenverarbeitungssystem, das aufweist: einen Prozessor; einen verteilten Datenspeicher; eine Eingabe/Ausgabe- (E/A-) Schnittstelle, die mit einem externen Netzwerk verbunden ist; und einen Speicher, der mit dem Prozessor verbunden ist, wobei der Speicher enthält: einen Hypervisor; eine Vielzahl von Betriebssystem- (OS-) Partitionen; und ein Dienstprogramm, das bei Ausführung auf dem Prozessor bereitstellt: ein Mittel zum Aktivieren eines ersten Monitor-Threads in einem ersten VIOS eines ersten Servers, um den Status eines Live Partition Mobility- (LPM-) Ereignisses zu verfolgen; ein Mittel zum Aufzeichnen von Informationen über das LPM-Ereignis in der gemeinsam genutzten Datenbank unter Verwendung des ersten Monitor-Threads; ein Mittel, das in Reaktion darauf, dass der erste VIOS dauerhaft eine Fehlerbedingung aufweist, einen oder mehrere funktionierende Monitor-Threads identifiziert, die in einem Quellenserver weiterhin funktionieren, wobei die Fehlerbedingung aus einem Verlust einer LPM-Ereignis-Überwachung durch den ersten Monitor-Thread resultiert; ein Mittel zum Feststellen, ob es sich bei dem einen oder den mehreren funktionierenden Monitor-Threads um einen einzigen letzten Monitor-Thread handelt; und in Reaktion darauf, dass ein erster VIOS in dem ersten Server im Fehlerzustand ist, ein Mittel, um über den letzten Monitor-Thread Lösch- und Aktualisierungsoperationen in der gemeinsam genutzten Datenbank auszuführen, wobei die Lösch- und Aktualisierungsoperationen in Reaktion auf den Empfang einer Angabe ausgeführt werden, dass ein oder mehrere Knoten in dem ersten Server in dem Fehlerzustand sind.
  8. Datenverarbeitungssystem nach Anspruch 7, wobei das Mittel zum Aktivieren eines ersten Monitor-Threads ferner aufweist: ein Mittel zum Erfassen einer Auslösung eines LPM-Ereignisses; und ein Mittel, um in Reaktion auf das Erfassen der Auslösung des LPM-Ereignisses zu erzeugen: (a) den ersten Monitor-Thread in dem ersten VIOS in dem ersten Server in dem cluster-bewussten Datenverarbeitungssystem; und/oder (b) einer ersten Menge von Monitor-Threads in anderen VIOSes in dem ersten Server; und/oder (c) einer zweiten Menge von Monitor-Threads in VIOSes in einem zweiten Server, einem Zielserver.
  9. Datenverarbeitungssystem nach Anspruch 7 oder Anspruch 8, wobei das Mittel zum Aufzeichnen ferner aufweist: ein Mittel zum Aufzeichnen von Informationen über das LPM-Ereignis in einer Mobility-Tabelle unter Verwendung des Monitor-Threads, wobei die aufgezeichneten Informationen Informationen enthalten über: (a) einen Client; und/oder (b) den Server; und/oder (c) den Status eines entsprechenden VIOS, der an dem LPM-Ereignis beteiligt ist; ein Mittel zum Feststellen, ob das LPM-Ereignis beendet ist; und ein Mittel, um in Reaktion darauf, dass das LPM-Ereignis beendet ist, über den ersten Monitor-Thread bereitzustellen: (a) zugehörige Aktualisierungen an Speicherressourcen; und/oder (b) Entfernen eines entsprechenden Eintrags in einer Mobility-Tabelle der Datenbank; und/oder (c) andere Wartungsoperationen.
  10. Datenverarbeitungssystem nach einem der Ansprüche 7 bis 9, wobei das Dienstprogramm ferner aufweist: ein Mittel zum Erfassen, wenn ein bestimmter VIOS, der einer dem LPM-Ereignis entsprechenden virtualisierten Client-Partition zugehörig ist, dauerhaft eine Fehlerbedingung aufweist; ein Mittel, um in Reaktion auf das Erfassen, dass der bestimmte VIOS dauerhaft eine Fehlerbedingung aufweist und ein entsprechender Monitor-Thread nicht mehr vorhanden ist, eine Benachrichtigung über den Fehlerzustand des VIOS an andere VIOSes in demselben Server in dem cluster-bewussten DPS bereitzustellen; und Ermöglichen, dass ein oder mehrere der anderen VIOSes den LPM-Ereignis-Status in der Datenbank in geeigneter Weise aktualisieren.
  11. Datenverarbeitungssystem nach einem der Ansprüche 7 bis 10, wobei das Dienstprogramm ferner aufweist: ein Mittel zum Auslösen durchgehender Prüfungen des Zustands des LPM-Ereignisses durch andere Monitor-Threads über einen Datenaustausch der anderen Monitor-Threads mit einem Hypervisor; ein Mittel zum Feststellen, ob das LPM-Ereignis (a) abgebrochen; oder (b) abgeschlossen; oder (c) in einem Fehlerzustand ist; ein Mittel, um in Reaktion darauf, dass es sich bei der Menge von anderen Monitor-Threads um einen einzigen letzten Monitor-Thread handelt, eine Abfrage der Datenbank über den letzten Monitor-Thread auszulösen, um festzustellen, ob in einem geeigneten Server Knoten vorhanden sind, die sich in einem Fehlerzustand befinden; und ein Mittel, um in Reaktion darauf, dass sich Knoten in dem geeigneten Server in einem Fehlerzustand befinden, Aktualisierungsoperationen an einer entsprechenden Mobility-Tabelle über den letzten Monitor-Thread auszuführen, zu denen gehören: (a) Operationen, die erforderlich sind, um die Datenbank konsistent und aktuell zu halten; und/oder (b) Entfernen einer entsprechenden Zeile/eines entsprechenden Eintrags aus der entsprechenden Mobility-Tabelle; und/oder (c) andere Wartungsoperationen.
  12. Datenverarbeitungssystem nach Anspruch 11, wobei das Dienstprogramm ferner aufweist: ein Mittel, um in Reaktion darauf, dass das LPM-Ereignis als ein Ergebnis einer Fehlerbedingung beendet wurde, zu einer bestimmten Stufe eines entsprechenden Migrationsvorgangs zurückzukehren, um die Mobility-Operation wiederaufzunehmen und abzuschließen.
  13. Computerprogrammprodukt, das aufweist: ein Computerspeichermedium; und Programmcode in dem Computerspeichermedium, der, wenn er durch einen Prozessor in einem Datenverarbeitungssystem ausgeführt wird, die Funktionen bereitstellt zum: Aktivieren eines ersten Monitor-Threads in einem ersten VIOS eines ersten Servers, um einen Status eines Live Partition Mobility- (LPM-) Ereignisses zu verfolgen; Aufzeichnen von Informationen über das LPM-Ereignis in der gemeinsam genutzten Datenbank unter Verwendung des ersten Monitor-Threads; in Reaktion darauf, dass der erste VIOS dauerhaft eine Fehlerbedingung aufweist, Identifizieren eines oder mehrerer Monitor-Threads, die weiterhin in einem Quellenserver funktionieren, wobei die Fehlerbedingung einen Verlust der LPM-Ereignis-Überwachung durch den ersten Monitor-Thread zur Folge hat; Feststellen, ob es sich bei dem einen oder den mehreren funktionierenden Monitor-Threads um einen einzigen letzten Monitor-Thread handelt; und in Reaktion darauf, dass ein erster VIOS in dem ersten Server in einem Fehlerzustand ist, Ausführen von Lösch- und Aktualisierungsoperationen in der gemeinsam genutzten Datenbank über den letzten Monitor-Thread, wobei das Löschen und die Aktualisierung in Reaktion auf den Empfang einer Angabe, dass ein oder mehrere Knoten in dem ersten Server vorhanden sind, die in dem Fehlerzustand sind, ausgeführt werden.
  14. Computerprogrammprodukt nach Anspruch 13, wobei der Programmcode zum Aktivieren eines ersten Monitor-Thread ferner Programmcode aufweist zum: Erfassen einer Auslösung eines LPM-Ereignisses; und in Reaktion auf das Erfassen der Auslösung des LPM-Ereignisses, Erzeugen: (a) des ersten Monitor-Thread in dem ersten VIOS in dem ersten Server in dem cluster-bewussten Datenverarbeitungssystem; und/oder (b) einer ersten Menge von Monitor-Threads in anderen VIOSes in dem ersten Server; und/oder (c) einer zweiten Menge von Monitor-Threads in VIOSes in einem zweiten Server, einem Zielserver.
  15. Computerprogrammprodukt nach Anspruch 13, wobei der Programmcode zum Aufzeichnen ferner Programmcode aufweist zum: Aufzeichnen von Informationen über das LPM-Ereignis in einer Mobility-Tabelle unter Verwendung des Monitor-Thread; wobei die aufgezeichneten Informationen Informationen enthalten über: (a) einen Client; und/oder (b) den Server; und/oder (c) den Status eines entsprechenden VIOS, der an dem LPM-Ereignis beteiligt ist; Feststellen, ob das LPM-Ereignis abgebrochen wurde; und in Reaktion darauf, dass das LPM-Ereignis abgebrochen wurde, Bereitstellen über den ersten Monitor-Thread von: (a) zugehörigen Aktualisierungen für Speicherressourcen; und/oder (b) Entfernen eines entsprechenden Eintrags in einer Mobility-Tabelle der Datenbank; und/oder (c) anderen Wartungsoperationen.
  16. Computerprogrammprodukt nach Anspruch 13, der ferner Programmcode aufweist zum: Erfassen, ob ein bestimmter VIOS, der einer virtualisierten Client-Partition zugehörig ist, die dem LPM-Ereignis entspricht, dauerhaft eine Fehlerbedingung aufweist; in Reaktion auf das Erfassen, dass der bestimmte VIOS dauerhaft die Fehlerbedingung aufweist und ein entsprechender Monitor-Thread nicht mehr vorhanden ist, Bereitstellen einer Benachrichtigung über den Fehlerzustand des VIOS an andere VIOSes in demselben Server in dem cluster-bewussten DPS; und Ermöglichen, dass ein oder mehrere der anderen VIOSes den LPM-Ereignis-Status in der Datenbank in geeigneter Weise aktualisieren.
  17. Computerprogrammprodukt nach Anspruch 13, das ferner Programmcode aufweist zum: Auslösen durchgehender Prüfungen des Zustands des LPM-Ereignisses durch andere Monitor-Threads über einen Datenaustausch der anderen Monitor-Threads mit einem Hypervisor; Feststellen, ob das LPM-Ereignis (a) abgebrochen wurde; oder (b) abgeschlossen wurde; oder (c) in einem Fehlerzustand ist; in Reaktion darauf, dass es sich bei der Menge von anderen Monitor-Threads und einen einzigen letzten Monitor-Thread handelt, Auslösen einer Abfrage der Datenbank über den letzten Monitor-Thread, um festzustellen, ob in einem geeigneten Server Knoten vorhanden sind, die sich in einem Fehlerzustand befinden; und in Reaktion darauf, dass Knoten in dem geeigneten Server in einem Fehlerzustand sind, Ausführen von Aktualisierungsoperationen an einer entsprechenden Mobility-Tabelle über den letzten Monitor-Thread, zu denen gehören: (a) Operationen, die erforderlich sind, um die Datenbank konsistent und aktuell zu halten; und/oder (b) Entfernen einer entsprechenden Zeile/eines entsprechenden Eintrags aus der entsprechenden Mobility-Tabelle; und/oder (c) andere Wartungsoperationen.
  18. Computerprogrammprodukt nach Anspruch 17, das ferner Programmcode aufweist zum in Reaktion darauf, dass das LPM-Ereignis als ein Ergebnis einer Fehlerbedingung beendet wurde, Zurückkehren zu einer bestimmten Stufe eines entsprechenden Migrationsvorgangs, um die Mobility-Operation wiederaufzunehmen und abzuschließen.
  19. Computerprogramm, das ein Programmcodemittel aufweist, das eingerichtet ist, um alle Schritte der Ansprüche 1 bis 6 auszuführen, wenn das Programm auf einem Datenverarbeitungssystem läuft.
DE112011103666.3T 2010-11-05 2011-10-24 Speicherverwaltung in Cluster-Datenverarbeitungssystemen Active DE112011103666B4 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/940,468 2010-11-05
US12/940,468 US8521703B2 (en) 2010-11-05 2010-11-05 Multiple node/virtual input/output (I/O) server (VIOS) failure recovery in clustered partition mobility
PCT/EP2011/068565 WO2012059355A1 (en) 2010-11-05 2011-10-24 Storage management in clustered data processing systems

Publications (2)

Publication Number Publication Date
DE112011103666T5 DE112011103666T5 (de) 2013-08-01
DE112011103666B4 true DE112011103666B4 (de) 2021-05-20

Family

ID=44925504

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112011103666.3T Active DE112011103666B4 (de) 2010-11-05 2011-10-24 Speicherverwaltung in Cluster-Datenverarbeitungssystemen

Country Status (5)

Country Link
US (2) US8521703B2 (de)
CN (1) CN103189847B (de)
DE (1) DE112011103666B4 (de)
GB (1) GB2499533B (de)
WO (1) WO2012059355A1 (de)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8726274B2 (en) * 2010-09-10 2014-05-13 International Business Machines Corporation Registration and initialization of cluster-aware virtual input/output server nodes
US8707083B2 (en) * 2010-12-03 2014-04-22 Lsi Corporation Virtualized cluster communication system
US8661089B2 (en) * 2010-12-08 2014-02-25 International Business Machines Corporation VIOS cluster alert framework
US20120151265A1 (en) * 2010-12-09 2012-06-14 Ibm Corporation Supporting cluster level system dumps in a cluster environment
US8949828B2 (en) 2011-01-11 2015-02-03 International Business Machines Corporation Single point, scalable data synchronization for management of a virtual input/output server cluster
US10185582B2 (en) * 2012-11-28 2019-01-22 Red Hat Israel, Ltd. Monitoring the progress of the processes executing in a virtualization environment
WO2014108933A1 (en) * 2013-01-10 2014-07-17 Hitachi, Ltd. Resource management system and resource management method of a computer system
US9548940B2 (en) 2013-06-09 2017-01-17 Apple Inc. Master election among resource managers
US9229825B2 (en) 2013-06-28 2016-01-05 International Business Machines Corporation Quick failover of blade server
US9280371B2 (en) 2013-07-10 2016-03-08 International Business Machines Corporation Utilizing client resources during mobility operations
US9274853B2 (en) 2013-08-05 2016-03-01 International Business Machines Corporation Utilizing multiple memory pools during mobility operations
US9563481B2 (en) * 2013-08-06 2017-02-07 International Business Machines Corporation Performing a logical partition migration utilizing plural mover service partition pairs
CN103458055A (zh) * 2013-09-22 2013-12-18 广州中国科学院软件应用技术研究所 一种云计算平台
US9571585B2 (en) 2013-11-26 2017-02-14 International Business Machines Corporation Using alternate port name for uninterrupted communication
US9367562B2 (en) 2013-12-05 2016-06-14 Google Inc. Distributing data on distributed storage systems
US9965363B2 (en) 2013-12-14 2018-05-08 Netapp, Inc. Techniques for LIF placement in SAN storage cluster synchronous disaster recovery
CN103746829B (zh) * 2013-12-20 2017-04-05 中国科学院计算技术研究所 一种基于集群的故障感知系统及其方法
CN104077199B (zh) * 2014-06-06 2016-03-16 中标软件有限公司 基于共享磁盘的高可用集群的隔离方法和系统
CN104410698B (zh) * 2014-12-03 2019-03-08 天津南大通用数据技术股份有限公司 一种share nothing集群下的发起节点异常处理方法及装置
US9489274B2 (en) * 2014-12-17 2016-11-08 American Megatrends, Inc. System and method for performing efficient failover and virtual machine (VM) migration in virtual desktop infrastructure (VDI)
US20160232353A1 (en) * 2015-02-09 2016-08-11 Qualcomm Incorporated Determining Model Protection Level On-Device based on Malware Detection in Similar Devices
US10572443B2 (en) * 2015-02-11 2020-02-25 Spectra Logic Corporation Automated backup of network attached storage
CN109522154B (zh) * 2015-09-10 2023-02-03 华为技术有限公司 数据恢复方法及相关设备与系统
US10320703B2 (en) * 2015-09-30 2019-06-11 Veritas Technologies Llc Preventing data corruption due to pre-existing split brain
US9846602B2 (en) * 2016-02-12 2017-12-19 International Business Machines Corporation Migration of a logical partition or virtual machine with inactive input/output hosting server
US10042720B2 (en) * 2016-02-22 2018-08-07 International Business Machines Corporation Live partition mobility with I/O migration
US10002018B2 (en) 2016-02-23 2018-06-19 International Business Machines Corporation Migrating single root I/O virtualization adapter configurations in a computing system
US10042723B2 (en) 2016-02-23 2018-08-07 International Business Machines Corporation Failover of a virtual function exposed by an SR-IOV adapter
US10025584B2 (en) 2016-02-29 2018-07-17 International Business Machines Corporation Firmware management of SR-IOV adapters
SG10201601838TA (en) * 2016-03-09 2017-10-30 Trakomatic Pte Ltd Method and system for visitor tracking at a pos area
US9720863B1 (en) 2016-10-21 2017-08-01 International Business Machines Corporation Migrating MMIO from a source I/O adapter of a source computing system to a destination I/O adapter of a destination computing system
US9720862B1 (en) 2016-10-21 2017-08-01 International Business Machines Corporation Migrating interrupts from a source I/O adapter of a computing system to a destination I/O adapter of the computing system
US10579437B2 (en) * 2016-12-01 2020-03-03 International Business Machines Corporation Migrating a logical partition with a native logical port
CN110100283B (zh) * 2016-12-21 2023-07-04 甘布罗伦迪亚股份公司 包括具有支持外域的安全集群域的信息技术基础架构的医疗设备系统
US10599527B2 (en) 2017-03-29 2020-03-24 Commvault Systems, Inc. Information management cell health monitoring system
US10740157B2 (en) * 2018-06-05 2020-08-11 International Business Machines Corporation Cache load balancing in a virtual input/output server
US10924538B2 (en) * 2018-12-20 2021-02-16 The Boeing Company Systems and methods of monitoring software application processes
CN112818059B (zh) * 2021-01-27 2024-05-17 百果园技术(新加坡)有限公司 一种基于容器发布平台的信息实时同步方法及装置
CN112910981B (zh) * 2021-01-27 2022-07-26 联想(北京)有限公司 一种控制方法及装置
US11960917B2 (en) 2021-06-14 2024-04-16 International Business Machines Corporation Live migration and redundancy for virtualized storage
US20230030168A1 (en) * 2021-07-27 2023-02-02 Dell Products L.P. Protection of i/o paths against network partitioning and component failures in nvme-of environments
CN113946624A (zh) * 2021-10-11 2022-01-18 北京达佳互联信息技术有限公司 分布式集群、信息处理方法、装置、电子设备及存储介质
CN116339958B (zh) * 2023-05-30 2023-09-08 支付宝(杭州)信息技术有限公司 一种任务执行方法、装置以及设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080155169A1 (en) * 2006-12-21 2008-06-26 Hiltgen Daniel K Implementation of Virtual Machine Operations Using Storage System Functionality
US7434022B1 (en) * 2004-06-29 2008-10-07 Emc Corporation Distributed workflow techniques

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7484208B1 (en) 2002-12-12 2009-01-27 Michael Nelson Virtual machine migration
US7047337B2 (en) * 2003-04-24 2006-05-16 International Business Machines Corporation Concurrent access of shared resources utilizing tracking of request reception and completion order
AU2004280976A1 (en) * 2003-10-08 2005-04-21 Unisys Corporation Computer system para-virtualization using a hypervisor that is implemented in a partition of the host system
US7617257B2 (en) 2004-12-03 2009-11-10 Oracle International Corporation System for persistent caching of LDAP metadata in a cluster LDAP server topology
US7730486B2 (en) 2005-02-28 2010-06-01 Hewlett-Packard Development Company, L.P. System and method for migrating virtual machines on cluster systems
US8375386B2 (en) * 2005-06-29 2013-02-12 Microsoft Corporation Failure management for a virtualized computing environment
US9418040B2 (en) * 2005-07-07 2016-08-16 Sciencelogic, Inc. Dynamically deployable self configuring distributed network management system
US20070203882A1 (en) * 2006-02-10 2007-08-30 Akira Koseki Method for efficiently retrieving entity beans in an EJB container
US20070260910A1 (en) * 2006-04-04 2007-11-08 Vinit Jain Method and apparatus for propagating physical device link status to virtual devices
US7673181B1 (en) * 2006-06-07 2010-03-02 Replay Solutions, Inc. Detecting race conditions in computer programs
JP4969258B2 (ja) * 2007-01-30 2012-07-04 株式会社日立製作所 仮想計算機システムのｉ／ｏデバイス障害処理方法
US8554981B2 (en) 2007-02-02 2013-10-08 Vmware, Inc. High availability virtual machine cluster
JP4744480B2 (ja) * 2007-05-30 2011-08-10 株式会社日立製作所 仮想計算機システム
US7966517B2 (en) * 2008-03-20 2011-06-21 Hitachi, Ltd. Method and apparatus for virtual network attached storage remote migration
US7886183B2 (en) * 2008-08-07 2011-02-08 Symantec Operating Corporation Providing fault tolerant storage system to a cluster
KR101748448B1 (ko) * 2009-03-18 2017-06-16 터치튠즈 뮤직 코포레이션 엔터테인먼트 서버 및 관련 소셜 네트워킹 서비스
US8219990B2 (en) * 2009-05-28 2012-07-10 Novell, Inc. Techniques for managing virtual machine (VM) states
JP5427574B2 (ja) * 2009-12-02 2014-02-26 株式会社日立製作所 仮想計算機の移動管理方法、前記移動管理方法を用いた計算機、前記移動管理方法を用いた仮想化機構および前記移動管理方法を用いた計算機システム
US8145945B2 (en) * 2010-01-04 2012-03-27 Avaya Inc. Packet mirroring between primary and secondary virtualized software images for improved system failover performance
US8726274B2 (en) * 2010-09-10 2014-05-13 International Business Machines Corporation Registration and initialization of cluster-aware virtual input/output server nodes

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7434022B1 (en) * 2004-06-29 2008-10-07 Emc Corporation Distributed workflow techniques
US20080155169A1 (en) * 2006-12-21 2008-06-26 Hiltgen Daniel K Implementation of Virtual Machine Operations Using Storage System Functionality

Also Published As

Publication number Publication date
US8521703B2 (en) 2013-08-27
US8996477B2 (en) 2015-03-31
GB201306798D0 (en) 2013-05-29
DE112011103666T5 (de) 2013-08-01
GB2499533B (en) 2017-08-23
CN103189847B (zh) 2016-01-06
GB2499533A (en) 2013-08-21
CN103189847A (zh) 2013-07-03
US20130024718A1 (en) 2013-01-24
WO2012059355A1 (en) 2012-05-10
US20120303594A1 (en) 2012-11-29

Similar Documents

Publication Publication Date Title
DE112011103666B4 (de) Speicherverwaltung in Cluster-Datenverarbeitungssystemen
DE112016001295T5 (de) Neusynchronisieren auf ein erstes Speichersystem durch Spiegeln des ersten Speichersystems nach einem Failover zu einem zweiten Speichersystem
DE112014006605B4 (de) Speichersystem
DE112014006156B4 (de) Speichersystem und Datenmigrationsverfahren
DE112018003084B4 (de) Asynchrones lokales und entfernt angeordnetes erzeugen von konsistenten zeitpunkt-momentkopien in konsistenzgruppen
DE602004005344T2 (de) Verfahren, system und programm zur handhabung eines failover zu einem fernspeicherort
DE112011100112B4 (de) Pufferspeicher-platte in blitzkopie-kaskade
DE60317383T2 (de) Datenwiederherstellungsvorrichtung unter Verwendung von Journaldaten und Identifikationsinformation
DE102012212511B4 (de) Betriebsverfahren eines Datenverarbeitungssystems, Datenverarbeitungsvorrichtung und Computerprogrammprodukt zum Bereitstellen einer Checkpoint-basierten Hochverfügbarkeit mit Netzwerkpaketpufferung in der Hardware
DE102012206207B4 (de) Online-Datenträgermigration unter Verwendung von Multipath-Input/Output-Maskierung
DE112019002609T5 (de) Wechseln zwischen Fehlerreaktionsmodellen für ein Speichersystem
DE102021113808A1 (de) Handhabung von Replikationen zwischen verschiedenen Netzwerken
DE602005003490T2 (de) Verteiltes System mit Quorumredundanz und Verfahren dafür
DE102013209528A1 (de) Benutzergesteuerte Replikation in einem System für synchronisierte Objektreplikationen
DE60313468T2 (de) Speicherdienste und -systeme
DE102012215918A1 (de) Spiegeln virtueller Maschinen von einem primären auf einen sekundären Host
DE112013002014T5 (de) Bereitstellen von anwendungsgestützter Überwachung und Wiederherstellung für einen Hypervisor eines HA-Clusters
DE102013101863A1 (de) Hochverfügbares Hauptspeicher-Datenbanksystem, Arbeitsverfahren und deren Verwendungen
DE102004027672A1 (de) Speicherplattenarraysystem
DE112012000693T5 (de) Ausführen einer Vielzahl von Instanzen einer Anwendung
DE112013005758T5 (de) Verfahren und Vorrichtung zur Notfallwiederherstellungsvirtualisierung
DE112012000282B4 (de) Anwendungswiederherstellung in einem Dateisystem
DE112012003695T5 (de) Aufrechterhalten mehrerer Zielkopien
CN105281949B (zh) 混合存储模式中主机的隔离方法和隔离装置
DE102021109227A1 (de) Weiterleitung von speicheroperationsanfragen an speichersysteme unter verwendung der zugrunde liegenden datenträgerkennungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R084 Declaration of willingness to licence
R020 Patent grant now final