DE10134492B4

DE10134492B4 - Ausfallübernahme des Dateimanagementsystems in einem Rechnercluster

Info

Publication number: DE10134492B4
Application number: DE10134492A
Authority: DE
Inventors: Christian Bolik; Peter Gemsjaeger; Klaus Schroiff
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-07-28
Filing date: 2001-07-10
Publication date: 2006-02-09
Anticipated expiration: 2021-07-11
Also published as: KR20020010490A; JP2002091938A; DE10134492A1; US6990606B2; CN1190733C; CN1336589A; US20020073354A1; KR100423687B1; JP4204769B2; SG99917A1; US20060010338A1; US7523345B2

Abstract

Verfahren zur Übernahme der Funktion eines hierarchischen Dateimanagementsystems (DMApi) in einem Rechnercluster von einem ausgefallenen Knoten (Ausfallknoten) des Rechnerclusters, mit den Schritten:
Laden des DMApi in ausgewählte Knoten des Rechnerclusters, die für eine Übernahme vorgesehen sind;
Speichern von Konfigurationsinformationen für das Dateimanagementsystem und den Rechnercluster in einer zentralen Speichereinheit innerhalb des Rechnerclusters;
Empfangen von Zustandsnachrichten der Knoten des Rechnerclusters in einer zentralen Übertragungsschnittstelle des Rechnerclusters zur Verteilung dieser Nachrichten an die ausgewählten Knoten des Rechnerclusters;
Analysieren der verteilten Zustandsnachrichten in den ausgewählten Knoten, um in jedem ausgewählten Knoten zu ermitteln, ob der ausgewählte Knoten die Übernahme für einen als ausgefallen signalisierten Knoten durchführen kann;
Aktualisieren der Konfigurationsinformationen für den Fall, dass mindestens ein ausgewählter Knoten die Übernahme durchführt.

Description

GRUNDLAGEN DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zur Übernahme der Funktion eines hierarchischen Dateimanagementsystems (DMApi) in einem Rechnercluster von einem ausgefallenen Knoten (Ausfallknoten) des Rechnerclusters.

Moderne leistungsfähige Datenverarbeitungssysteme mit mehreren Rechnern stellen auch Verfahren zur Verfügung, mit denen bei Ausfall eines Rechners oder bei seiner Überlastung andere Rechner herangezogen werden können. Ein Beispiel eines derartigen Systems beschreibt WO 98/26553, dessen Rechner in Dienstgruppen eingeteilt sind, so dass die Aufgaben innerhalb einer Dienstgruppe bei Bedarf neu verteilt werden können. Die spezifischen Probleme beim Ausfall eines Dateiverwaltungssystems in einem lose gekoppelten Rechnercluster sind dort nicht angesprochen.

Unternehmen mit großen oder vernetzten Rechnerumgebungen benutzen oftmals verteilte Dateisysteme. In den letzten Jahren hat die Notwendigkeit, hochauflösende Bilder, wissenschaftliche Daten usw. zu speichern, ein ernstes Ungleichgewicht zwischen dem Leistungsvermögen und der Funktionsweise von Systemen zur Dateneingabe/-ausgabe (E/A) und zum Speichern geschaffen. Daher muss sich die Leistungsfähigkeit und das Fassungsvermögen von derzeitigen Massenspeichersystemen um Größenordnungen verbessern.

Um kostengünstigen Zugriff auf Daten in derartigen speicherintensiven Rechnerumgebungen bereitzustellen, müssen Massenspeichersysteme mit den zugrunde liegenden verteilten Dateisystemen eingebaut werden. Dabei stellt das Verbinden von Massenspeichersystemen mit diesen Speichersystemen eine nahtlose Sicht des Speichersystems bereit.

Der ständig wachsende Bedarf an Datenspeicherkapazität schließt Kosten ein, die mit der Verwaltung des verteilten Speichersystems verbunden sind, wobei diese wesentlich höher sind als die Kosten des Speicherns an sich. Damit gibt es einen steigenden Bedarf an intelligenter und leistungsfähiger Speicherverwaltung mit Hilfe einer Datenverwaltungsanwendung (DM).

Die DM-Anwendung verschiebt die Daten zwischen einem schnellen Direktspeicher mit begrenzter Speicherkapazität und einem tertiären Speicherarchiv. Zusätzlich stellt es für alle Daten, die in dem tertiären Archiv gespeichert sind, direkte Semantik bereit, d.h., der Benutzer muss keinerlei verwaltungstechnische Vorgänge ausführen, um auf die Daten zuzugreifen. Darüber hinaus erkennt die DM-Anwendung jeden beliebigen Zugriff auf die archivierten Daten und überträgt die Daten automatisch an den Benutzer. Aus diesem Grund müssen einige Überwachungseinrichtungen bereitgestellt werden, so dass die DM-Anwendung benachrichtigt werden müsste, wenn ein Benutzer versucht, einen Datenblock aus einem Datei mit Daten zu lesen.

Das vorstehend beschriebene Konzept, nämlich örtlichen Speicherplatz freizumachen, indem Daten in eine entfernte Speichervorrichtung verschoben werden, ist allgemein als Hierarchische Speicherverwaltung (HSM) bekannt. Die Speicherverwaltung ist für den Benutzer transparent, d.h., er hat noch die gleiche Ansicht, als ob die Daten lokal angeordnet sind.

In einer auf Dateien beruhenden HSM erzeugt die DM-Anwendung so genannte "Abrissdateien" (stub files) als Platzhalter, die einfach die Dateiattribute festhalten. Wenn auf die Abrissdateien oder auf entsprechend gelochte(n) Plattenbereich e) zugegriffen wird, werden die Daten der Datei (oder eines Plattenbereiches) wieder von der entfernten Speichervorrichtung zurückgerufen. Üblicherweise wird HSM an einem Dateiserver installiert, der eine große Anzahl von Daten speichert, auf die selten zugegriffen wird (z.B. archivierte Wetterkarten, Videodarstellungen).

Es ist weiterhin bekannt, dass die Verfügbarkeit eines vorstehend beschriebenen verteilten Massenspeichersystems, d.h. die Verfügbarkeit der Kombination der zugrunde liegenden Datenspeichereinrichtungen und DM-Anwendung(en) verbessert werden kann, wenn ein Teil des Speichersystems Dienste eines ausgefallenen Speichersystems übernehmen kann, was üblicherweise als "Übernahme" bezeichnet wird.

Dabei sind Dateisysteme bekannt, die das gemeinsame Benutzen von Platten innerhalb mehrerer Hauptrechner verwalten, wie etwa das Allgemeine Parallele Dateisystem (GPFS), das auf AIX SP (einem auf UNIX beruhenden Parallelrechner mit skalierbarer Leistung) läuft, das vom gegenwärtigen Anmelder entwickelt wurde und von ihm vertrieben wird. Um es zu gestatten, dass DM-Anwendungen eher mehr in Form üblicher Softwareanwendungen entwickelt werden, ist eine Schnittstelle zur Datenverwaltungsanwendung (DMApi) (vorgegeben vom Konsortium der Data Management Interfaces Group (DMIG)) vorgeschlagen worden, die durch das Dateisystem eingerichtet wird und von einer Datenverwaltungs- (DM)Anwendung benutzt wird, um die folgenden Funktionen auszuführen

– Hierarchische Speicherverwaltung (HSM)
– Datensicherung und -wiederherstellung.

Die DMApi hat zum Ziel, eine Umgebung bereitzustellen, die für das Einrichten robuster DM-Anwendungen in handelsüblicher Qualität geeignet ist. In einer gemeinsam genutzten Plattenumgebung kann die DMApi insbesondere Einrichtungen für die Wiederherstellung nach einem Absturz der DM-Anwendung und statusbezogene Steuerung der Dateisystemobjekte enthalten.

In einer Gruppierung von lose verbundenen Rechnerknoten (Rechnercluster), auf welche die vorliegende Erfindung insbesondere gerichtet ist, umfasst jeder Knoten eine DM-Anwendung, die Unterstützung bei der Speicherverwaltung bereitstellt, was sogenannte "DMApi-Ereignisse" erforderlich macht, die synchron oder asynchron sein können. DMApi-Ereignisse sind Mechanismen, die es einer DM-Anwendung gestatten, immer dann benachrichtigt zu werden, wenn in einem zugrunde liegenden Betriebssystem bestimmte Vorgänge eintreten, das an einem bestimmten Knoten der Gruppierung eingerichtet worden ist. Durch diese Mechanismen können DMApi-Sitzungen von einem anderen Knoten übernommen werden, der einen einzigen Ausfallpunkt erzeugt. Die DMApi-Sitzungen sind die primären Übertragungskanäle zwischen einer DM-Anwendung und einer Kern-Komponente der DMApi, die in dem zugrunde liegenden Betriebssystem eingerichtet worden ist.

In einer klassischen Umgebung mit einem Knoten/Rechner enden im Falle eines Systemausfalles die Dateisystemdienste. In einer Gruppierungs-Umgebung (Rechnercluster) ist es am wahrscheinlichsten, dass ein Ausfall eines einzelnen Knotens andere (unabhängige) Knoten innerhalb des Systems nicht beeinflusst. Wenn sich die DM-Anwendung an dem Ausfallknoten befindet, ist der Zugriff auf Abrissdateien nicht mehr verfügbar, was möglicherweise laufende Vorgänge an aktiven Knoten der Gruppierung unterbricht. Daher ist es wünschenswert, die DM-Anwendung an einen aktiven Gruppierungsknoten zu verschieben, um die HSM-Funktion wiederherzustellen, damit andere Knoten vom Ausfall des anfänglichen Knotens nicht betroffen werden.

ZUSAMMENFASSUNG DER ERFINDUNG

Die Aufgabe der vorliegenden Erfindung ist es daher, ein Verfahren und eine Vorrichtung der eingangs genannten Art bereitzustellen, um die Übernahme einer Datenverwaltungsanwendung für ein gemeinsam genutztes Plattenspeichersystem in einer verteilten Rechnerumgebung abzuwickeln.
Diese Aufgabe wird durch die Merkmale der unabhängigen Ansprüche gelöst. vorteilhafte Ausführungsformen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Bei diesem Verfahren wird ein bestimmter Knoten der Gruppierung (Rechnerclusters) als Übernahmekandidatenknoten definiert, Konfigurationsinformationen für alle Übernahmekandidatenknoten gespeichert, Nachrichteninformationen verteilt, die Ausfallinformationen mindestens eines Übernahmekandidatenknotens unter den Übernahmekandidatenknoten enthalten, aber nicht darauf beschränkt sind, die verteilten Nachrichteninformationen und die gespeicherten Konfigurationsinformationen analysiert um zu ermitteln, ob der Dienst eines Ausfallknotens durch einen Übernahmekandidatenknoten übernommen wird, und die Konfigurationsinformationen für den Fall aktualisiert, dass mindestens ein Übernahmekandidatenknoten den Dienst eines Ausfallknotens übernimmt.
Im Allgemeinen gibt es in einer Gruppierungsumgebung zwei Arten von Ausfällen. Die erste Art ist diejenige, dass ein Knoten erkennt, dass er nicht länger in der Lage ist, Datenzugriffsdienste bereitzustellen und daher eine Übernahmeanforderung auslösen muss, um den Datenzugriffsdienst an einem unterschiedlichen Knoten wiederherzustellen. Im Falle eines vollständigen Ausfalles eines Knotens verteilt der Gruppierungsdienst an die Übernahmekandidatenknoten Ausfallereignisse. Die Erfindung richtet sich an beide Arten von Ausfällen und stellt nur einen Mechanismus bereit.
Das besondere Konzept, das die Grundlage der vorliegenden Erfindung bildet, besteht darin, in Verbindung mit einem Dateisystem einen Mechanismus bereitzustellen, der es beim Ausfall erlaubt, eine DMApi-Sitzung zu verschieben, womit eine stufenweise Übernahme einer DMA-Anwendung aktiviert wird. Dieser Mechanismus stellt auf eindeutige Weise dem/den Benutzer(n) des verteilten Massenspeichersystems ein größeres Maß an Verfügbarkeit bereit.
Lose verbundene Systeme sind durch eine ausgeprägte Unabhängigkeit der Gruppierungs-Knoten gekennzeichnet, die durch das Fehlen eines gemeinsam genutzten Hauptspeichers (RAM) verursacht wird. Die Funktionsfähigkeit der Gruppierung beruht auf einer Art von hardwareseitigen Hochgeschwindigkeitsverbindungen und einer Gruppierungs-Software (Clustersoftware), die Funktionen bereitstellt, wie etwa Übertragung von Knoten zu Knoten und gemeinsam genutzte Datenspeicher.
Im Vergleich zu einem monolithischen (mit mehreren Prozessoren ausgestatteten) System gibt es im Hinblick auf die Synchronisation zwischen lose verbundenen Gruppierungsknoten zwei Probleme:

– das Fehlen eines synchronisierten Verriegelungsmechanismus ähnlich den Systemmutexen
– der Verlust der lokalen Konfigurationsinformation an einem Ausfallknoten.

Die vorliegende Erfindung überwindet diese Probleme durch das Simulieren dieser Funktion unter Verwendung sekundärer Speicher und eines alternativen Verriegelungsmechanismus von Objekten.
Zusätzlich stellt die Erfindung vorteilhafterweise eine Zugriffsgarantie für Abrissdateien bereit.
In einer bevorzugten Ausführungsform der Erfindung wird eine Übernahmeanforderung an mindestens einen zweiten Übernahmekandidaten ausgeführt, wenn nur eine Untermenge des Dateisystems vom Ausfallknoten durch einen ersten Übernahmekandidaten übernommen wird. Dieser stufenweise Mechanismus verbessert die Robustheit der Fehlerbeseitigung in einer lose verbundenen Rechnerumgebung beträchtlich.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung wird besser aus der folgenden ausführlichen Beschreibung verstanden, wenn sie in Verbindung mit den zugehörigen Zeichnungen angenommen wird, aus denen weitere Merkmale und Vorzüge der Erfindung offenkundig werden. In den Zeichnungen ist
1 ein schematisches Datenflussdiagramm, das den Datenfluss des DMApi-Modells für das Lesen einer nichtresidenten Datei nach dem Stand der Technik veranschaulicht;
2 ein schematisches Blockdiagramm, das einen anfänglichen Zustand einer Knotengruppierung nach der Erfindung zeigt;
3 ein Zeitplan, der eine erste Ausführungsform der Erfindung darstellt, die synchrone Synchronisierung zwischen mehreren Übernahmekandidatenknoten bereitstellt, um die Dienste eines Ausfallknotens zu übernehmen;
4 ein Zeitplan ähnlich 3, der eine Ausführungsform darstellt, die asynchrone Synchronisierung bereitstellt;
5 ein Blockdiagramm, das die Übernahme einer Rückrufanforderung nach entfernten Daten gemäß der Erfindung veranschaulicht; und
6 ein weiteres Blockdiagramm, das eine beispielhafte Realisierung der Erfindung darstellt.
AUSFÜHRLICHE BESCHREIBUNG DER ZEICHNUNGEN
1 zeigt einen Datenfluss eines DMApi-Modells zum Lesen einer nicht residenten Datei über der Zeit ("Zeitachse") nach Stand der Technik. Ein dargestellter Knoten 100 in einer verteilten und aus Gruppierungen bestehenden Rechnerumgebung (Rechnercluster) umfasst einen Hauptrechner, auf dem eine DM-Anwendung 110 läuft, die mehrere Wege bietet, um den Benutzerzugriff zu Dateidaten zu steuern, die örtlich (hier nicht gezeigt) gespeichert sind, z.B. auf einer lokalen Platte oder einem Sekundärspeicher, der eine Magnetplatte sein kann, die mit dem gezeigten Knoten verbunden ist. Am Knoten 100 läuft ein Kernbetriebssystem 120 mit einer DMApi-Realisierung 130.
An einem entfernten Knoten 140 wird ein tertiärer Speicher 150 bereitgestellt, der eine Speichereinrichtung mit einer hohen Speicherkapazität, aber einer niedrigen Zugriffs- oder Speicherleistung umfasst, die für Daten benutzt wird, auf die nicht häufig zugegriffen wird. Der tertiäre Speicher 150 ist oft eine robotergesteuerte Bandbibliothek oder ein selbsttätiger CD-Wechsler und ist oftmals mit einem beliebigen anderen Hauptrechner auf dem Netzwerk verbunden. Der Vorgang 160 des Verschiebens der Daten zwischen sekundärem und tertiärem Speicher 150 wird oft als Datenumlagerung bezeichnet.
Daten des Dateisystems (residente Daten) sind auf der lokalen Platte vorhanden und sind möglicherweise auf dem tertiären Speicher 150 dupliziert. Jegliche lokalen Veränderungen an den residenten Daten müssen, falls vorhanden, die tertiäre Kopie ungültig machen. Nichtresidente Daten sind nur auf dem tertiären Speicher 150 vorhanden und müssen auf die lokale Platte kopiert werden, ehe die Benutzer darauf zugreifen können. Es sollte angemerkt werden, dass das DMApi-Modell für den Datenfluss keinen Zugriff auf die Daten gestattet, wenn sie nicht zuerst auf die lokale Platte kopiert worden sind.
Um die Daten vom tertiären Speicher 150 in die Datei auf dem lokalen Speicher zu übertragen, ist die DM-Anwendung 110 in der Lage, Daten in die Datei zu schreiben, während verwaltete Bereiche festgelegt werden. Die DMApi bietet spezielle Schnittstellen (hier nicht gezeigt), um auf die "abgedeckten" Daten zuzugreifen, indem der Code für die Ereigniserzeugung umgangen wird. Diese Schnittstellen werden oftmals als unsichtbare E/A bezeichnet. Ihre Semantik gleicht den regelgerechten Systemaufrufen zum Lesen(2) und Aufzeichnen(2), ausgenommen, dass sie keine Datenereignisse erzeugen und Zeitmarkierungen von Dateien nicht verändern.
Um Dateidaten an den tertiären Speicher 150 zu schicken, muss die DM-Anwendung 110 Zugriffsrechte zur Zieldatei erwerben. Unter Verwendung der speziellen DMApi-Aufrufe können sowohl die Dateiattribute als auch die Dateidaten gelesen werden und an einen entfernten Datenserver geschickt werden. Danach können Datensegmente freigemacht werden (indem ein Datenloch gestanzt wird), um lokalen Speicher zu gewinnen. Das "Datenloch" ist ein sogenannter verwalteter Bereich. Die DM-Zugriffsrechte werden nach diesem Vorgang aufgehoben.
Um Nachrichten vom Dateisystem zu erhalten, muss die DM-Anwendung 110 eine Gruppe von DM-Ereignissen definieren, die sie für ein gegebenes Dateisystem empfangen möchte. Unter Anderem können derartige Ereignisse Lese-/Schreib-/Abschneide-Zugriff auf eine Datei oder Statusereigenisse eines Dateisystem im Hinblick auf Einbau- oder Speicherplatz sein (Benachrichtigung über fehlenden Speicherplatz).
Wenn eine Benutzeranwendung 170 eine ausgestanzte Datei liest (→ ihren verwalteten Bereich), unterbricht die DMApi die Anwendung und schickt ein Ereignis in eine Nachrichtenwarteschlange. Eine DM-Anwendung mit dem geeigneten Verarbeitungsmerkmal für das DM-Ereignis kann das Ereignis herauslesen und die Dateidaten aus dem entfernten Speicher wiederherstellen. Danach wird das Ereignis beantwortet, wodurch die ursprüngliche Anwendung erneut aktiviert (nicht mehr blockiert) wird, die das Leseereignis veranlasst hat.
HSM-Realisierungen, wie etwa der Tivoli-Platzverwalter, verwalten üblicherweise den lokalen Speicherplatz automatisch. So beginnt, wenn ein Dateisystem eine definierte Ausnutzungsrate überschreitet, sagen wir 70 %, oder ein Ereignis für das Ende des verfügbaren Speicherplatzes erzeugt, ein DM-Dämon auf der Grundlage von erzeugten Kandidatenlisten mit dem Umlagern auswählbarer Dateien an entfernte Server, bis eine definierte niedrigere Schwelle erreicht worden ist.
2 zeigt den anfänglichen Status einer Gruppierung von 4 Knoten 200 nach der Erfindung. Knoten 2 stellt für ein vorgegebenes Allgemeines Paralleles Dateisystem (GPFS), das mit "/gpfs1" bezeichnet wird, DM-Dienste bereit. Die Knoten 1 und 3 sind mögliche Kandidaten (Übernahmekandidatenknoten), um die Dienste von Knoten 2 zu übernehmen. An Knoten 4 ist das gemeinsam genutzte Dateisystem nicht eingerichtet und daher nicht auswählbar. Die Konfigurationsdaten sind in einem AIX SP-weiten "Systemdatenbehälter" (SDR) 210 von IBM gespeichert. Die Übertragung zwischen den Knoten wird über SP-Gruppendienste (GS) 220 bewerkstelligt, die Knotenausfälle verfolgen und ein Übertragungsprotokoll bieten, um innerhalb einer definierten Gruppe von Knoten (hier den Knoten, die an der Gruppierung beteiligt sind) Nachrichten zu verteilen.
Eine gleichförmige Konfiguration innerhalb der Gruppierung 200 wird durch das Speichern der Konfigurationsdaten für alle Übernahmeknoten 230 bis 250 in der SDR 210 garantiert, die sich innerhalb der Gruppierung 200 befindet.
Die gemeinsam genutzte Umgebung muss Folgendes wissen:

– Liste der Dateisysteme, die innerhalb der Gruppierung 200 verwaltet werden, die bestimmte Einstellungen der Dateisysteme enthält
– Knoten, der derzeit ein oder mehrere Dateisysteme verwaltet
– Zusätzliche Konfigurationsinformationen, wie z.B. die Zugriffsinformationen auf Server mit entfernter Speicherung

Zusätzlich wird eine Übertragungsschnittstelle bereitgestellt, um Nachrichten (z.B. einen Ausfallbericht eines Knotens) an die teilnehmenden Knoten der Übernahmeumgebung zu verteilen (siehe 3 für ein angemessenes Übertragungsprotokoll zur Ausfallwiederherstellung).
Die Übertragungsinstanz (wie etwa die AIX SP Gruppendienste) stellt eine API bereit, die es teilnehmenden Gruppierungsknoten gestattet, eine Verwaltungsgruppe zu bilden. In der Übertragungsarchitektur ist jeder Knoten ein Client (ein sogenannter Dienst-"Versorger" in der Welt von SP GS) der Gruppendienstinstanz (Server). Nachrichten von Clients, die an die Schnittstelle geschickt werden, werden automatisch an die teilnehmenden Gruppenmitglieder verteilt. Die Nachrichtenverbreitung von AIX SP GS ist ereignisgesteuert (Rückruf-Funktion).
Wenn die DM-Anwendung an einem Knoten nicht mehr in der Lage ist, ihren Dienst bereitzustellen, müssen die anderen Mitglieder der Übernahmegruppe von dem Ausfall benachrichtigt werden. Dies kann entweder aktiv vom Ausfallknoten her oder im Falle eines vollständigen Knotenausfalles (Absturz) durch einen Übertragungsdienst in der Gruppierung (z.B. SP GS) berichtet werden.

Auf der Grundlage der Ausfallbenachrichtigung müssen die möglichen Übernahmeknoten in der Ausfallumgebung ihre Anstrengungen synchronisieren, um die DM-Dienste für das Dateisystem wiederherzustellen, das früher durch den Ausfallknoten verwaltet worden ist. Jeder Knoten muss die gemeinsam genutzten Konfigurationsdaten analysieren, die in dem zentralen Datenbehälter 210 enthalten sind, um zu entscheiden, ob die Wahl besteht, den Dienst des Ausfallknotens zu übernehmen. Das Ergebnis dieser Verfahrensweise kann wie folgt sein:

1. Kein Kandidat:	nichts zu machen – der Dienst kann nicht wiederhergestellt werden
2. Ein Kandidat:	Dienst kann ohne zusätzlichen Aufwand zum Synchronisieren wiederhergestellt werden
3. mehr als ein Kandidat:	Dienst kann wiederhergestellt werden, aber Synchronisieren ist erforderlich

Im Hinblick auf das aus Option 3 bestehende Ergebnis ist, wenn die Gruppierung 200 von Knoten nicht über einen gemeinsam genutzten Speicher kommuniziert (z.B. eine Gruppierung unabhängiger Rechner, wie etwa ein SP von IBM), zusätzlicher Aufwand erforderlich, die unterschiedlichen Knoten zu synchronisieren. Die Synchronisation zwischen mehreren Kandidaten zur Übernahme des Dateisystems eines Ausfallknotens kann entweder

a) synchron oder
b) asynchron erfolgen.

3 zeigt eine erste Ausführungsform des Verfahrens nach der Erfindung in einer Gruppierung mit 4 Knoten, wie sie in 2 dargestellt ist. Es bietet synchrone, d.h. auf Übertragung beruhende Synchronisation zwischen mehreren Übernahmekandidatenknoten zum Übernehmen der Dienste eines Ausfallknotens 300.
Um zwischen unterschiedlichen Knoten einer Gruppierung Übernahmefunktionen bereitzustellen, muss die DM-Anwendung auf allen Knoten installiert worden sein, die an dem Wiederherstellungsvorgang nach dem Ausfall beteiligt sein sollten. In der anfänglichen Konfiguration stellt mindestens einer dieser Knoten Datenverwaltungdienste (DM) für ein bestimmtes Dateisystem bereit. Mögliche Übernahmekandidaten 310, 320 bleiben schlafend im Hintergrund oder stellen Dienste für unterschiedliche Dateisysteme bereit.
Die auswählbaren Knoten 310, 320 senden über einen Übertragungsmechanismus in der Gruppierung eine Nachricht aus, die von einem zugewiesenen Gruppierungsübertragungsdienst 330, wie etwa die vorstehend beschriebenen Gruppendienste, verarbeitet wird, um sie an die anderen Mitglieder 310, 320, 350 der Gruppe zu verteilen. Diese Nachricht enthält einen Prioritätsschüssel 340 (z.B. auf der Grundlage der Auslastung 360 des Knotens).
Das Verfahren stellt vorzugsweise einen Blockiermechanismus bereit, der auf einer Befehlsschnittstelle beruht, die vom Systemdatenbehälter (SDR) bereitgestellt wird, wie er in AIX SP benutzt wird. Der SDR gestattet es, dauerhafte Datenobjekte für eine gegebene Art von Datensatz zu erzeugen und zu verändern. Es ist möglich, ein Datenobjekt in einem Bausteinvorgang zu prüfen und zu verändern, so dass an einem gemeinsam genutzten HSM-Betriebsmittel eine Verriegelung eingestellt wird (ähnlich einer Systemmutex), die in der vorliegenden Ausführungsform als der folgende WENN-DANN-Schritt realisiert wird
Wenn (Verriegelung == 0) dann {Verriegelung = 1}
Wenn diese Prüfung fehlschlägt, nicht erfüllt wird, wartet der Aufrufer eine Zeit lang, ehe er es wieder versucht. Zusätzlich zu der Verriegelung muss ein nachfolgender Knoten auch eine die Verriegelung kennzeichnende Zeitmarke aktualisieren (auf der Grundlage des über die Gruppierung wirkenden synchronisierten Taktes). Wenn ein Knoten, der die Verriegelung festhält, einen Absturz hat, würde der wartende Knoten versuchen, unablässig auf die Verriegelung zuzugreifen, was offenkundig nicht erwünscht ist.
Eine Dienstübernahme kann etwa 60 Sekunden dauern. Wenn nun eine Zeitmarke für eine Verriegelung älter als diese 60 Sekunden ist, kann ein Kandidatenknoten annehmen, dass der Knoten, der die Verriegelung festhält, keine Wiederherstellung erfährt und ist damit frei, die Übernahme der Verriegelung zu erzwingen (indem er die Zeitmarke wieder aktualisiert). Nachdem der Zugriff des gemeinsam genutzten HSM-Betriebsmittels beendet ist, wird die Verriegelung auf null zurückgesetzt.
Der Prioritätsschlüssel, wie er vorstehend beschrieben wird, beruht auf dem UNIX-Befehl "uptime". Neben anderen Daten zeichnet "uptime" die Systemauslastung über die letzten 15 Minuten auf. Je höher die aufgezeichnete Auslastung ist, desto niedriger ist der Wert des Prioritätsschlüssels.
Die Knoten, die eine Nachricht erhalten, können den ankommenden Schlüssel mit dem eigenen vergleichen. Der beste Schlüssel 380 erwirbt das Recht, den Dienst zu übernehmen. Die Anzahl der möglichen Sicherungsknoten, die einen Schlüssel aussenden, ist im System unbekannt, so dass die Abstimmungsphase nach Ablauf einer bestimmten Zeit 370 beendet werden muss.
Der Knoten, der gewonnen hat, fügt entweder ein oder mehrere Dateisysteme zu seiner derzeit aktiven HSM-Konfiguration hinzu oder beginnt mit dem HSM-Dienst 380. Üblicherweise muss er für auf DMApi beruhenden Anwendungen die Ereignismaske einstellen, um alle ankommenden Ereignisse zu übernehmen, die für das/die Ziel-Dateisystem(e) erzeugt worden sind. Der Knoten, der einen Dienst übernimmt, muss die Konfigurationsdateien innerhalb des zentralen Datenbehälters aktualisieren, damit die Konsistenz sichergestellt wird. Der Aktualisierungsmechanismus muss durch den Verriegelungsmechanismus vorhanden sein (siehe vorstehend), damit Konkurrenzbedingungen vermieden werden. Der Rest verbleibt entweder als schlafende Sicherung oder setzt den Dienst an ihren eigenen HSM-Dateisystemen fort. Wenn sich ein Knoten in der Abstimmungsphase verspätet, kann er einen Vergleich mit dem aktiven Knoten vornehmen, der in der Eigentümerdatei mit dem ausgefallenen Knoten definiert ist. Wenn es keine Übereinstimmung gibt, lässt er den Versuch fallen, die Steuerung zu übernehmen, weil die Übernahme schon erfolgt ist.
Das Verwalten der Situation durch einen synchronen mehrphasigen Quittungsaustausch, wie er vorstehend beschrieben worden ist, erfordert es, Statusinformationen eine gewisse Zeit lang aufrechtzuerhalten, und es kommt ein gehöriger Übertragungsaufwand hinzu. Es ist ebenfalls notwendig, per Dateisystem abzustimmen, weil der anfängliche Übernahmeknoten nicht in der Lage sein könnte, alle Dateisysteme des Ausfallknotens zu verwalten (z.B. Dateisystem nicht angehängt).
4 zeigt eine unterschiedliche Ausführungsform, bei der die Synchronisation zwischen Übernahmekandidatenknoten über ein asynchrones (auf Datenverriegelung beruhendes) Protokoll erfolgt. Diese Ausführungsform wird in einer Situation mit 3 Knoten veranschaulicht. Jeder Knoten kann sich darum bewerben, ein Dateisystem einfach durch Verriegeln, Aktualisieren und Entriegeln der Konfigurationsdateien zu übernehmen. Der Knoten, der in der Lage war, die Konfigurationsdateien in dem Datenbehälter der Gruppierung zu verriegeln und zu verändern, erwirbt das Recht, von dem Ausfallknoten Dateisysteme zu übernehmen. Die Übernahmeanforderung wird in Stufen zu verspäteten Knoten weitergehen, die noch in der Lage sein können, restliche Dateisysteme zu übernehmen, die durch vorherige Übernahmeknoten nicht bedient werden können. Im Gegensatz zu der synchronen Verfahrensweise, die in 3 dargestellt ist, erfordert der beschriebene asynchrone Übernahmemechanismus keine expliziten Nachrichten zwischen den Knoten der Übernahmegruppe.
Zum Zeitpunkt des Ausfalls kann der ausfallende Knoten dabei sein, Datenverwaltungsereignisse (DM) aus dem Dateisystem zu verarbeiten. Vorgänge, die derartige Ereignisse erzeugen, werden durch die DMApi-Umgebung blockiert, bis die DM-Anwendung das Ereignis freigibt, nachdem die Daten einer Datei aus einem entfernten Speicherserver zurückgerufen worden sind. Der Knoten, der den Dienst übernimmt, benutzt eine vorhandene DMApi-Sitzung oder – wenn keine vorhanden ist – erzeugt er eine neue. Zusätzlich nimmt er die Sitzung des ausgefallenen Knotens auf. Wartende Ereignisse vom ausgefallenen Knoten werden in eine zeitweilige DMApi-Sitzung verschoben und auf unterschiedliche Weisen verwaltet, was von der Art des Ereignisses abhängt. Dies stellt sicher, dass blockierte Vorgänge wieder frei gemacht werden.
Die in 5 dargestellte Veranschaulichung zeigt die Übernahme von Anforderungen nach entfernten Wiederaufrufen von Daten. Bei GPFS HSM unterstützt die DMApi diese Art von Übernahme von Ereignissen, wenn der GPFS-Dämon zugrunde gegangen ist, aufgrund eines Knotenabsturzes durch eine Benutzeranforderung auf ungewöhnliche Art und Weise).
In Abhängigkeit von der Verarbeitungsart des Übertragungsereignisses kann die DM-Anwendung auch eine Art von Warteschlangenbildung benötigen, um Probleme mit konkurrierenden Pfaden zu vermeiden. Grundsätzlich werden durch ein verriegeltes Datenobjekt in dem zentralen Datenbehälter alle Vorgänge/Pfade blockiert, aber dies ruft Warten wegen Belegung hervor, was nicht wünschenswert ist. In einer Umgebung mit einem einzigen Pfad könnten ankommende Anforderungen in einer einfachen FIFO-Liste gespeichert werden. In einer Umgebung mit vielen Pfaden könnte die Synchronisation durch Systemmutexen oder Bedingungsvariable erreicht werden.
Abschließend stellt 6 eine Realisierung von Gruppendiensten der Erfindung in einer GPFS HSM für AIX auf SP von IBM dar.
Die gezeigten Merkmale der SP-Umgebung sind

– Gruppendienste (GS) 600, die ein über die Gruppierung wirkendes Übertragungsprotokoll plus einen Verfolgungsmechanismus für Knotenabstürze bereitstellen
– Systemdatenbehälter (SDR) 610, um über die Gruppierung Konfigurationsdateien zu speichern.

Die SP-Gruppendienste stellen einen Mechanismus bereit, um eine Übertragungsgruppe zu bilden, die aus Vorgängen besteht, die verteilt an einem beliebigen SP-Knoten laufen. Die teilnehmenden Vorgänge können an alle Mitglieder der Gruppe Nachrichten verteilen. Zusätzlich können Gruppendienste angewiesen werden, den Ablaufstatus der Mitgliedsvorgänge zu überwachen – ein Merkmal, das dafür benutzt werden kann, den Mitgliedern der Gruppe Vorgangsausfälle (⎕ gesamter Knoten) zu berichten, die den Übernahmemechanismus auslösen.
Die Aufgaben von GPFS HSM auf AIX SP sind in 3 Dämonen aufgeteilt:

– dsmwatchd 620, 630, 640, was der Sammelpunkt für alle Aktivitäten zur Übernahme/Wiederherstellung ist
– dsmrecalld 680, 690, 700, die dafür verantwortlich sind, umgelagerte Daten aus dem entfernten Speicherserver wieder aufzurufen
– dsmmonitord 650, 660, 670 achtet auf den Zustand des aufgebrauchten Speicherplatzes bei einem Dateisystem und sorgt für die automatische Datenumlagerung an den entfernten Speicherserver

Der dsmwatchd erfüllt grundlegend zwei Tasks (Aufgaben):

– Wiederherstellung eines abgestürzten dsmmonitord und dsmrecalld, das durch den Hauptvorgang (DM-Pfad) 720 erfolgt
– Verwalten der Übernahmeumgebung, ausgelöst durch Rückrufpfade der GS 730, die Folgendes enthalten
– aktive Übernahme im Falle einer beschädigten lokalen Umgebung (Absturz % Abschaltung von GPFS-Dämon, Knotenabsturz, HSM-Dämon beschädigt)
– aktive Übernahme von Dateisystemen eines entfernten Ausfallknotens.

Nach der ersten Aufgabe stößt der dsmwatchd über einen DM-Aufruf den dsmrecalld an um zu prüfen, ob DM-Dienste in Betrieb sind und um sicherzustellen, dass der dsmrecalld tatsächlich läuft. Wenn der dsmwatchd den dsmrecalld nicht mehr anstoßen kann, wird er versuchen, den dsmrecalld einmal neu zu starten, und wenn er keinen Erfolg hat, wird er die Übernahme an einen unterschiedlichen Knoten unter der Annahme auslösen, dass die DM-Umgebung beschädigt worden ist. Zusätzlich verfolgt er die Vorgangs-ID, um den Zieldämon neu zu starten, wenn die PID nicht mehr vorhanden ist.
Nach der zweiten Aufgabe werden die Vorgänge der SP-Gruppendienste (GS) wie vorstehend beschrieben eingerichtet. Der Übernahmemechanismus arbeitet vorzugsweise asynchron, da ein synchroner Betrieb auf Grund bestimmten GS-Einschränkungen oftmals nicht stattfinden kann. Mehrere Anforderungen auf Übernahmen werden über Pfad-Mutexen in einer Warteschlange angeordnet.

Claims

Verfahren zur Übernahme der Funktion eines hierarchischen Dateimanagementsystems (DMApi) in einem Rechnercluster von einem ausgefallenen Knoten (Ausfallknoten) des Rechnerclusters, mit den Schritten: Laden des DMApi in ausgewählte Knoten des Rechnerclusters, die für eine Übernahme vorgesehen sind; Speichern von Konfigurationsinformationen für das Dateimanagementsystem und den Rechnercluster in einer zentralen Speichereinheit innerhalb des Rechnerclusters; Empfangen von Zustandsnachrichten der Knoten des Rechnerclusters in einer zentralen Übertragungsschnittstelle des Rechnerclusters zur Verteilung dieser Nachrichten an die ausgewählten Knoten des Rechnerclusters; Analysieren der verteilten Zustandsnachrichten in den ausgewählten Knoten, um in jedem ausgewählten Knoten zu ermitteln, ob der ausgewählte Knoten die Übernahme für einen als ausgefallen signalisierten Knoten durchführen kann; Aktualisieren der Konfigurationsinformationen für den Fall, dass mindestens ein ausgewählter Knoten die Übernahme durchführt.
Verfahren nach Anspruch 1, wobei mindestens ein zweiter ausgewählter Knoten die Übernahme für eine Untermenge des Dateisystems vom Ausfallknoten durchführt.
Verfahren nach Anspruch 1 oder 2, wobei die ausgewählten Knoten die verteilten Nachrichten in einem Synchronisationsprozess innerhalb einer festgelegen Zeitspanne verarbeiten.
Verfahren nach Anspruch 1 oder 2, wobei die ausgewählten Knoten die verteilten Nachrichten in einem asynchronen Prozess mit Hilfe eines Verriegelungsmechanismus verarbeiten.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die ausgewählten Knoten einen Prioritätsschlüssel berechnen, der sich auf die Auslastung jedes der ausgewählten Knoten bezieht und der Teil der verteilten Nachrichten ist.
Verfahren nach Anspruch 4, wobei jeder ausgewählte Knoten durch Vergleich des empfangenen Prioritätsschlüssels mit dem eigenen Prioritätsschlüssel über die Übernahme entscheidet.
Rechnercluster mit einem hierarchischen Dateimanagementsystem (DMApi), das auf einem Knoten des Rechnerclusters ausgeführt wird und mit Vorrichtungen zur Übernahme ausgefallener Funktionen eines Knotens, gekennzeichnet durch die Merkmale: in ausgewählte Knoten des Rechnerclusters ist des DMApi geladen und steht für eine Übernahme der Funktion des hierarchischen Dateimanagementsystems zur Verfügung; ein zentraler Datenspeicher (220) im Rechnercluster zum Speichern von Konfigurationsinformationen des Dateimanagementsystems und der ausgewählten Knoten; eine zentrale Übertragungsschnittstelle im Rechnercluster zum Empfang und zum Verteilen von Nachrichten zwischen den ausgewählten Knoten; Mittel in den ausgewählten Knoten zum Analysieren der empfangenen Nachrichten, um zu entscheiden, ob die Übernahme des ausgefallenen DMApi durch den Knoten erfolgen soll; Mittel zum Aktualisieren der Konfigurationsinformationen für den Fall, das mindestens ein ausgewählter Knoten die Funktion des ausgefallenen Knotens übernimmt.
Rechnercluster nach Anspruch 7, mit Mitteln zum stufenweisen Abwickeln der Übernahmen, wobei mindestens ein zweiter ausgewählter Knoten eine Übernahme für eine Untermenge des Dateisystems durchführt.
Rechnercluster nach Anspruch 7 oder 8, wobei die Mittel zum Aktualisieren der Konfigurationsinformationen in dem ausgewählten Knoten enthalten sind, der eine Funktion eines ausgefallenen Knotens übernimmt.