DE102021107655A1 - Protokollverwaltung für ein mehrknotendatenverarbeitungssystem - Google Patents

Protokollverwaltung für ein mehrknotendatenverarbeitungssystem Download PDF

Info

Publication number
DE102021107655A1
DE102021107655A1 DE102021107655.2A DE102021107655A DE102021107655A1 DE 102021107655 A1 DE102021107655 A1 DE 102021107655A1 DE 102021107655 A DE102021107655 A DE 102021107655A DE 102021107655 A1 DE102021107655 A1 DE 102021107655A1
Authority
DE
Germany
Prior art keywords
node
cluster
nodes
leader
console
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.)
Pending
Application number
DE102021107655.2A
Other languages
English (en)
Inventor
Erik Jacobson
Cornel Mihai Boac
Pradeep Kumar Armugam
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.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
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 Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102021107655A1 publication Critical patent/DE102021107655A1/de
Pending legal-status Critical Current

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/2023—Failover techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
    • 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
    • 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/2035—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 without idle spare hardware
    • 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/2043—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 a common memory address space
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • 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/805—Real-time

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Ein computerlesbares Medium umfasst Anweisungen, die bei Ausführung durch einen Knoten in einem Datenverarbeitungssystem mit mehreren Knoten den Knoten in die Lage versetzen, als erster Führungsknoten zu dienen, indem er Systemprotokolldaten von mehreren Rechenknoten in einem ersten Cluster des Datenverarbeitungssystems mit mehreren Knoten empfängt und indem er die Systemprotokolldaten in einem gemeinsam genutzten Speicher speichert, der auch von zweiten und dritten Führungsknoten verwendet wird, um Systemprotokolldaten für Rechenknoten in zweiten und dritten Clustern des Datenverarbeitungssystems mit mehreren Knoten zu speichern. Die Anweisungen ermöglichen es dem Knoten außerdem, auf den Ausfall des zweiten oder dritten Führungsknotens zu reagieren, indem er automatisch die Systemprotokollierungsaufgaben für die Rechenknoten in dem Cluster übernimmt, der mit dem ausgefallenen Führungsknoten verbunden war. Die Anweisungen können den Knoten auch in die Lage versetzen, als Konsolenbrücke zu dienen und Konsolenprotokolldaten im gemeinsamen Speicher zu speichern.

Description

  • HINTERGRUND
  • Ein Datenverarbeitungssystem mit mehreren Knoten und herkömmlicher hierarchischer Verwaltung kann Tausende von Rechenknoten sowie mehrere Leitknoten und einen Hauptknoten umfassen. Die Rechenknoten können auf der untersten Ebene in Clustern organisiert sein. Die Zwischenebene kann die Leitknoten umfassen, wobei jeder Leitknoten einen Cluster verwaltet. Der Hauptknoten kann auf der höchsten Ebene arbeiten.
  • Figurenliste
    • ist ein Blockdiagramm eines Mehrknoten-Datenverarbeitungssystems mit einer Technologie zur belastbaren Protokollierung von Systemprotokolldaten gemäß einer Beispielimplementierung.
    • ist ein Flussdiagramm, das einen Prozess für die elastische Protokollierung von Systemprotokolldaten gemäß einer Beispielimplementierung zeigt.
    • ist ein Blockdiagramm eines Mehrknoten-Datenverarbeitungssystems mit Technologie für belastbares Konsolenmanagement gemäß einer Beispielimplementierung.
    • ist ein Flussdiagramm, das einen Prozess für die Verwaltung einer robusten Konsole gemäß einer Beispielimplementierung zeigt.
    • ist ein Blockdiagramm eines computerlesbaren Mediums, das Anweisungen enthält, die bei Ausführung durch einen Knoten in einem Datenverarbeitungssystem mit mehreren Knoten den Knoten befähigen, als Führungsknoten zu dienen.
    • ist ein Blockdiagramm eines Systems mit einer Technologie zur elastischen Protokollierung von Systemprotokolldaten.
    • ist ein Flussdiagramm, das ein Verfahren zur Verwaltung von Protokollen in einem Datenverarbeitungssystem mit mehreren Knoten zeigt.
  • DETAILLIERTE BESCHREIBUNG
  • Diese Offenbarung beschreibt ein effizientes Verfahren zur Ausfallsicherung für Leitknoten innerhalb eines Datenverarbeitungssystems mit mehreren Knoten. Für die Zwecke dieser Offenlegung kann ein Datenverarbeitungssystem mit mehreren Knoten als „Mehrknotensystem“ bezeichnet werden.
  • Zu den Verwaltungsvorgängen, die von einem Leader-Knoten durchgeführt werden, kann das Speichern von Systemprotokollen und Konsolenprotokollen für jeden der Rechenknoten unter diesem Leader-Knoten gehören. Beim herkömmlichen Ansatz ist jeder führende Knoten direkt mit einer Reihe von Knoten verknüpft und verwaltet diese Konsolenprotokolle und Systemprotokolle direkt. Ein Systemadministrator kann sich dann bei einem führenden Knoten anmelden, um auf die Konsolenprotokolle und die Systemprotokolle zuzugreifen, die von diesem führenden Knoten gespeichert wurden.
  • Die von einem Führungsknoten durchgeführten Verwaltungsvorgänge können auch die Weiterleitung von Konsolenverbindungen umfassen. Ein Führungsknoten führt die Weiterleitung von Konsolenverbindungen durch, indem er als Vermittler dient, damit der Hauptknoten über den Führungsknoten auf die Systemkonsole eines Rechenknotens zugreifen kann. Insbesondere kann der Hauptknoten eine Verbindung mit dem Führungsknoten herstellen, und der Führungsknoten kann diese Verbindung an die Systemkonsole eines Rechenknotens weiterleiten. Ein Führungsknoten kann eine Weiterleitung der Konsolenverbindung vorsehen, indem er den Hauptknoten anweist, eine Verbindung mit dem Führungsknoten als Vermittler herzustellen, anstatt eine direkte Verbindung mit dem Rechenknoten herzustellen.
  • Eine der Herausforderungen, mit denen hierarchische Datenverarbeitungssysteme mit mehreren Knoten konfrontiert sind, ist das Risiko, dass ein führender Knoten ausfällt. Failover für die Protokollierung und für die Weiterleitung von Konsolenverbindungen ist möglicherweise nicht implementiert, oder wenn es implementiert ist, basiert es auf einem System mit zwei Leitknoten für jeden Cluster, was teuer und restriktiv ist. Um beispielsweise eine hohe Verfügbarkeit von Rechenressourcen zu gewährleisten, kann jeder Cluster einen primären Leader-Knoten haben, der normalerweise die Protokollierung und die Weiterleitung von Konsolenverbindungen für einen Cluster übernimmt, sowie einen Backup-Leader-Knoten, der nur die Protokollierung und die Weiterleitung von Konsolenverbindungen durchführt, wenn der primäre Leader-Knoten ausgefallen ist. Ein solcher Backup-Leader-Knoten kann als „redundanter Leader-Knoten“ bezeichnet werden. Es kann jedoch kostspielig sein, ein Datenverarbeitungssystem mit mehreren Knoten mit redundanten Leader-Knoten auszustatten. Wenn z. B. ein System mit zehn Clustern und zehn primären Leader-Knoten redundante Leader-Knoten verwendet, kann dieses System zehn Backup-Leader-Knoten erfordern.
  • Einem Beispiel zufolge ist ein System mit mehreren Knoten innerhalb eines Netzwerks hierarchisch organisiert, mit einem Hauptknoten an der Spitze, einer Reihe von Leitknoten in der Mitte und vielen Rechenknoten am unteren Ende. Der Hauptknoten konfiguriert die Leitknoten, um Konsolenverwaltungs- und Protokollierungsfunktionen für die Rechenknoten bereitzustellen. Die Rechenknoten, auf denen die benutzerseitigen Aufträge ausgeführt werden, sind in Clustern organisiert. Der Hauptknoten weist jedem Rechenknoten eine Protokollierungsadresse zu, um das Ziel für die Protokollierungsdaten anzugeben, die dieser Rechenknoten über das Netzwerk sendet. Eine Protokollierungsadresse kann z. B. eine Internetprotokolladresse (IP) oder ein Hostname sein. Außerdem führt jeder Rechenknoten ein Betriebssystem (OS) aus, das Betriebssystem-Protokolldaten über diese Protokollierungsadresse an einen führenden Knoten sendet. Die Protokolldaten des Betriebssystems können als „Systemprotokolldaten“ oder „Syslog-Daten“ bezeichnet werden. Die führenden Knoten speichern diese Systemprotokolldaten in einem gemeinsamen Speicher, auf den die führenden Knoten und der Hauptknoten zugreifen können.
  • Für die Zwecke dieser Offenlegung bezieht sich der Begriff „Systemprotokolldaten“ auf die Daten, die von einem Protokollierungsdienst des Betriebssystems eines Knotens erzeugt werden, um Ereignisse zu dokumentieren, die während des Betriebs dieses Knotens aufgetreten sind. Verschiedene Betriebssysteme können unterschiedliche Namen für den Protokollierungsdienst verwenden. Ein Unix-Betriebssystem kann zum Beispiel einen Daemon namens „syslog“ verwenden. Ein Unix-ähnliches Betriebssystem wie Linux kann auch einen Daemon namens „syslog“ oder ähnliche Daemons wie einen Daemon namens „syslogd“ oder einen Daemon namens „syslogr“ verwenden. Zusätzlich oder alternativ kann ein Unix-ähnliches Betriebssystem eine Protokollierungsfunktion innerhalb eines anderen Daemons namens „systemd“ verwenden. Andere Typen von Betriebssystemen können jedoch Protokollierungsdienste mit anderen Namen verwenden. Auch die Daten, die protokolliert werden (d. h. die Daten, die vom Protokollierungsdienst des Betriebssystems erzeugt werden), können vom Betriebssystem stammen, oder sie können von einer anderen Komponente stammen, die dann die Daten zur Protokollierung an das Betriebssystem sendet. So kann das Betriebssystem beispielsweise während des Bootvorgangs Protokolldaten erzeugen, um Boot-Ereignisse zu dokumentieren (z. B. um zu dokumentieren, dass verschiedene Dienste gestartet wurden oder nicht gestartet wurden). Das Betriebssystem kann auch während der Post-Boot-Operationen Protokolldaten erzeugen, um vom Betriebssystem erkannte Ereignisse zu dokumentieren. Diese Ereignisse können erkannte Hardwarezustände oder - fehler, Authentifizierungsereignisse usw. umfassen. Zu den erkannten Hardware-Bedingungen können Speicherfehler, Festplattenausfälle, Überhitzung usw. gehören. Die Protokolldaten für Authentifizierungsereignisse können jeden Anmeldeversuch mit Informationen wie der beteiligten Benutzerkennung (ID), der Uhrzeit und der Angabe, ob der Versuch erfolgreich war oder fehlschlug, dokumentieren. Die vom Betriebssystem während der Post-Boot-Operationen erzeugten Protokolldaten können auch Protokolldaten von Betriebssystemdiensten enthalten. Beispielsweise kann ein DHCP-Server (Dynamic Host Configuration Protocol) im Betriebssystem Anforderungen für IP-Adressen (Internet Protocol) von Hardware-Komponenten im Knoten empfangen, und der DHCP-Server kann Protokolldaten erzeugen, um jede solche Anforderung und deren Bearbeitung zu dokumentieren. Zum Beispiel kann ein DHCP-Server in Verbindung mit der erfolgreichen Verarbeitung einer Anforderung für eine IP-Adresse Syslog-Daten wie die folgenden erzeugen:
    • • 22. Mai 15:23:50 tatsächlich dhcpd[8756]: DHCPACK auf 172.24.0.9 an 52:54:00:62:cd:f5 via bond0
  • Und in Verbindung mit der Ablehnung einer Anfrage für eine IP-Adresse kann der DHCP-Server Syslog-Daten wie die folgenden erzeugen:
    • • dhcpd-20191219:Dec 18 18:31:54 indeed dhcpd[16611]: DHCPDISCOVER von 52:54:00:62:cd:f5 über bondO: Netzwerk cluster-networks: keine freien Leases
  • Wie oben erwähnt, können die protokollierten Daten auch von außerhalb des Betriebssystems stammen. Zum Beispiel kann eine Anwendung Daten an das Betriebssystem senden, die in die Systemprotokolldaten aufgenommen werden. Ebenso kann ein Benutzer eine Befehlszeilenschnittstelle (CLI) des Betriebssystems verwenden, um Daten an das Systemprotokoll zu senden. Wenn also Probleme auftreten (einschließlich Umgebungsproblemen, Hardware-Problemen, Systemdienstproblemen und Software-Problemen), erzeugt das Betriebssystem Systemprotokolldaten, um diese Probleme zu beschreiben. Die Systemprotokolldaten können dann zum Debuggen von Problemen und zur Wiederherstellung nach Problemen, zur Durchführung von Sicherheitsüberprüfungen usw. verwendet werden.
  • In einem Beispiel ist das Betriebssystem in einem Rechenknoten so konfiguriert, dass es die Protokolldaten, die von diesem Rechenknoten erzeugt werden, an ein bestimmtes Ziel sendet. In einem Beispiel ist der Rechenknoten z. B. so konfiguriert, dass er seine Protokolldaten an eine bestimmte Netzwerkadresse sendet, wie oben angegeben. Außerdem ist ein entsprechender Führungsknoten so konfiguriert, dass er diese Adresse abhört und die Protokolldaten, die über diese Adresse empfangen werden, in einem gemeinsamen Speicher speichert. Wie unten ausführlicher beschrieben, können führende Knoten beispielsweise die Systemprotokolldaten für jeden Rechenknoten in einer separaten Datei speichern.
  • Jeder Knoten verfügt über eine Systemkonsole. Die Systemkonsole (oder kurz „Konsole“) ist eine Schnittstelle, die von einem Systemadministrator verwendet werden kann, um mit dem grundlegenden Eingabe-/Ausgabesystem (BIOS) des Knotens zu interagieren und um auf einer grundlegenden Ebene mit dem Betriebssystem des Knotens zu interagieren. Die Konsole kann z. B. eine Befehlszeilenschnittstelle (CLI) bereitstellen, die Befehle annimmt und Ergebnisse anzeigt. In einer Ausführungsform oder einem Szenario bietet die Konsole eine Möglichkeit, auf die BIOS-Einstellungen vor dem Start des Betriebssystems zuzugreifen, und die Konsole zeigt alle Meldungen des Betriebssystem-Startvorgangs an. Sobald das System hochgefahren ist, bietet die Konsole eine Möglichkeit, auf den Knoten zuzugreifen und sich auf niedriger Ebene anzumelden. Wenn andere Methoden für den Zugriff auf das System unzugänglich werden (z. B. aufgrund von Netzwerk- oder Software-Problemen), kann die Konsole auch zur Fehlersuche verwendet werden. Die Systemprotokolldaten können auch Eingaben und Ausgaben der Systemkonsole enthalten. Debugging- und Fehlermeldungen können jedoch auch dann auf der Konsole erscheinen, wenn sie aufgrund von Netzwerkproblemen oder Hardware-Problemen, wie z. B. einem Festplattenausfall, nicht in das Systemprotokoll gelangen.
  • In einem Beispiel kann ein Systemadministrator (E/A-)Geräte verwenden, die mit einem Knoten verbunden sind, um mit der Konsole dieses Knotens zu interagieren. In einem anderen Beispiel verwendet ein Systemadministrator einen Knoten, um mit der Konsole eines anderen Knotens zu interagieren. Zum Beispiel kann ein Systemadministrator einen Hauptknoten verwenden, um mit der Konsole eines Rechenknotens zu interagieren. Wenn ein erster Knoten verwendet wird, um mit der Konsole eines zweiten Knotens zu interagieren, kann der erste Knoten als „Konsolenserver“ und der zweite Knoten als „verwalteter Knoten“ bezeichnet werden. Um eine Konsolenverbindung herzustellen, kann der Konsolenserver eine Verbindung mit einem Verwaltungsprozessor des verwalteten Knotens herstellen.
  • In einem anderen Beispiel verwendet ein Client-Knoten einen Zwischenknoten, um mit der Konsole eines verwalteten Knotens zu interagieren. Insbesondere kann ein Hauptknoten ein Client sein, der einen Führungsknoten verwendet, um mit der Konsole eines Rechenknotens zu interagieren. In einem solchen Beispiel sind sowohl der Hauptknoten als auch der Führungsknoten Konsolenserver, da beide (direkt oder indirekt) zur Interaktion mit der Konsole des Rechenknotens verwendet werden. Der Führungsknoten kann jedoch auch spezifischer als „Konsolenbrücke“ bezeichnet werden, da der Führungsknoten als Vermittler dient, damit der Kopfknoten mit der Konsole des Rechenknotens interagieren kann. Mit anderen Worten, eine „Konsolenbrücke“ ist ein Führungsknoten, der so konfiguriert ist, dass er vom Kopfknoten eine Anforderung für eine Konsolenverbindung zu einem Rechenknoten annimmt und auf eine solche Anforderung reagiert, indem er eine Verbindung zu diesem Rechenknoten herstellt, damit der Kopfknoten über den Führungsknoten mit der Konsole des Rechenknotens interagieren kann. Sobald der Brückenknoten eine Verbindung zur Konsole des Rechenknotens hergestellt hat, kann der Hauptknoten beispielsweise den Brückenknoten verwenden, um mit einer CLI eines Betriebssystems auf dem Rechenknoten zu interagieren. Damit der Hauptknoten mit der Konsole eines Rechenknotens interagieren kann, stellt der Hauptknoten also eine Verbindung zu einer Konsolenbrücke her, und die Konsolenbrücke leitet diese Verbindung dann an den Rechenknoten weiter. Wie unten ausführlicher beschrieben, werden der Hauptknoten und/oder die Konsolenbrücke mit Konfigurationsdaten konfiguriert, um eine Konsolenbrücke mit bestimmten Rechenknoten zu verknüpfen und dem Hauptknoten zu ermöglichen, eine Verbindung mit der entsprechenden Konsolenbrücke für einen gewünschten Rechenknoten herzustellen.
  • Die von den Führungsknoten auszuführenden Konsolenverwaltungsfunktionen können die Weiterleitung von Konsolenverbindungen und die Konsolenprotokollierung umfassen. Für die Zwecke dieser Offenlegung bezeichnet „Konsolenverbindungsweiterleitung“ einen Dienst, der von einem führenden Knoten bereitgestellt wird und der es einem Hauptknoten ermöglicht, über diesen führenden Knoten mit der Konsole eines Rechenknotens zu interagieren. Konsolenbrücken sind also Knoten, die Konsolenverbindungsweiterleitung bereitstellen.
  • In einem Beispiel kann ein Systemadministrator, wenn ein Hauptknoten die Weiterleitung von Konsolenverbindungen bereitstellt, einen einzigen Befehl auf dem Hauptknoten verwenden, um eine Verbindung zur Konsole auf einem beliebigen Rechenknoten herzustellen, unabhängig davon, welcher Hauptknoten diese Konsole gerade verwaltet. Die Führungsknoten können dem Hauptknoten Konfigurationsdaten bereitstellen, die es dem Hauptknoten ermöglichen, solche Verbindungen herzustellen. Mit anderen Worten: Die Führungsknoten konfigurieren den Kopfknoten mit Konfigurationsdaten, um die Verbindungsweiterleitung zu ermöglichen. Diese Konfigurationsdaten können als „Console Connection Forwarding Configuration Data“ (CCFCD) bezeichnet werden. Die Leitknoten können auch Konsolenprotokolldaten von den Rechenknoten abrufen und diese Protokolldaten ebenfalls im gemeinsamen Speicher speichern. Wenn die Leitknoten beispielsweise eine Konsolenverbindungsweiterleitung bereitstellen, können die Leitknoten auch die entsprechenden Konsolenprotokolldaten im gemeinsamen Speicher speichern. Der Hauptknoten kann ebenfalls am gemeinsamen Speicher teilnehmen, sodass die Konsolenprotokolle und Systemprotokolle alle lokal für den Systemadministrator über den Hauptknoten verfügbar sind.
  • Jeder Führungsknoten verwaltet normalerweise einen Cluster von Rechenknoten. Jeder Leader-Knoten kann jedoch auch Verwaltungsaufgaben wie Protokollierung und Konsolenverwaltung von jedem ausgefallenen Leader-Knoten übernehmen. Mit anderen Worten: Jeder Leader-Knoten kann als Failover-Knoten dienen. Nachdem ein ausgefallener Knoten wieder in Betrieb genommen wurde, kann der wiederhergestellte Knoten auch seine ursprünglichen Aufgaben vom Failover-Knoten übernehmen. Zu den Bedingungen eines Knotens, die als Ausfall betrachtet werden können, gehören das Einfrieren oder Herunterfahren des Knotens, eine Fehlfunktion des Speichers im Knoten, das unerwartete Anhalten von Diensten usw.
  • In einem Beispiel führt jeder Leader-Knoten ein Hochverfügbarkeits(HA)-Verwaltungsprogramm oder („HA-Manager“) aus, das erkennen kann, wenn ein anderer Leader-Knoten ausgefallen ist, und das darauf reagieren kann, indem es die Verwaltungsaufgaben des ausgefallenen Knotens übernimmt. Insbesondere ermöglicht der HA-Manager den Leader-Knoten, untereinander zu entscheiden, welcher Leader-Knoten als Failover-Knoten für einen ausgefallenen Leader-Knoten dienen soll. Sobald ein ausgefallener Leader-Knoten wieder in Betrieb genommen wurde, kann dieser wiederhergestellte Knoten seine ursprünglichen Aufgaben vom Failover-Knoten übernehmen.
  • Führende Knoten können Listen von Protokollierungsadressen verwenden, die als „Abhörlisten“ bekannt sind, um Verwaltungsaufgaben dynamisch zwischen führenden Knoten zu verschieben. Für die Zwecke dieser Offenlegung ist eine Abhörliste in einem Führungsknoten eine Liste von Protokollierungsadressen, die von diesem Knoten gewartet oder behandelt werden sollen. Dementsprechend kann jeder Leader-Knoten Syslog-Daten auf der Grundlage der Listenliste in diesem Leader-Knoten bedienen.
  • In einem Beispiel weist der Hauptknoten jedem Rechenknoten in einem Cluster die gleiche Protokollierungsadresse zu. In diesem Beispiel können alle Rechenknoten in einem Cluster ihre Systemprotokolle an die gleiche Protokollierungsadresse senden. Der Hauptknoten kann auch eine andere Protokollierungsadresse für jeden Cluster verwenden. Folglich kann jeder Cluster seine Systemprotokolle an eine andere Protokollierungsadresse senden.
  • Außerdem kann jeder Führungsknoten normalerweise die Protokollierungsadresse bedienen, die von einem Cluster verwendet wird. Zum Beispiel kann eine anfängliche Konfiguration für ein System mit mehreren Knoten vorsehen, dass jeder führende Knoten eine Listenliste hat, die eine Protokollierungsadresse enthält. Eine solche Konfiguration kann auch als „Standardkonfiguration“ oder „normale Konfiguration“ bezeichnet werden, eine solche Listenliste kann als „Standard-Listenliste“ oder „normale Listenliste“ bezeichnet werden, und die Protokollierungsadresse in einer Standard-Listenliste eines Führungsknotens kann als „primäre“ Protokollierungsadresse für diesen Führungsknoten bezeichnet werden. Eine Standardkonfiguration für ein System mit mehreren Knoten kann zum Beispiel vorsehen, dass jeder führende Knoten eine Standard-Abhörliste hat, die eine primäre Protokollierungsadresse enthält.
  • Wenn ein führender Knoten ausfällt, kann die Protokollierungsadresse in der Listenliste dieses führenden Knotens als „verwaiste Protokollierungsadresse“ bezeichnet werden. In ähnlicher Weise können die Rechenknoten, die die verwaiste Protokollierungsadresse verwenden, als „verwaiste Knoten“ oder gemeinsam als „verwaister Cluster“ bezeichnet werden. Bei einem Failover kann ein führender Knoten, der als „Failover-Leader-Knoten“ bezeichnet werden kann, die Verantwortung für die Handhabung der Systemprotokolle für den verwaisten Cluster übernehmen. Der Failover-Knoten kann diese Verantwortung übernehmen, indem er die verwaiste Protokollierungsadresse zur Listenliste des Failover-Knotens hinzufügt. Der Failover-Leader-Knoten kann dann eine primäre Protokollierungsadresse, die von einem ersten Cluster verwendet wird, und eine verwaiste Protokollierungsadresse, die von dem verwaisten Cluster verwendet wird, bedienen.
  • Wie oben erwähnt, kann eine Protokollierungsadresse z. B. eine IP-Adresse sein. Eine solche IP-Adresse kann auch als „IP-Alias“ bezeichnet werden, da diese Adresse mehr oder weniger als Name für den Leitknoten dient, der aktuell für die Speicherung der Systemprotokolldaten verantwortlich ist, die an diese Adresse gesendet werden, und da sich die Verantwortung für die Handhabung von Protokollierungsadressen im Laufe der Zeit zwischen den Leitknoten verschieben kann.
  • Ein Mehrknotensystem gemäß der vorliegenden Offenlegung kann eine hohe Verfügbarkeit bieten, ohne dass für jeden primären Leader-Knoten ein redundanter Leader-Knoten erforderlich ist. Stattdessen können alle Leader-Knoten typischerweise aktiv sein, und jeder Leader-Knoten kann als Failover-Leader-Knoten für jeden anderen Leader-Knoten dienen. Daher kann ein solches System für eine hohe Verfügbarkeit sorgen, ohne dass so viele Leader-Knoten erforderlich sind, wie für jeden Cluster mit einem primären Leader-Knoten und einem dedizierten Backup-Leader-Knoten erforderlich wären.
  • ist ein Blockdiagramm eines Mehrknotensystems 100 mit Technologie zur belastbaren Protokollierung von Systemprotokolldaten gemäß einer Beispielimplementierung. Das Mehrknotensystem 100 ist hierarchisch organisiert, mit einem Kopfknoten 110 an der Spitze, mehreren Führungsknoten (z. B. Führungsknoten 120A, Führungsknoten 120B usw.) in der Mitte und mehreren Clustern (z. B. Cluster A, Cluster B usw.) am unteren Ende. Jeder Cluster umfasst mehrere Rechenknoten. Cluster A umfasst beispielsweise die Rechenknoten 130AA, 130AB usw., und Cluster B umfasst die Rechenknoten 130BA, 130BB usw.
  • Das Mehrknotensystem 100 umfasst auch einen gemeinsamen Speicher 140, auf den der Hauptknoten 110 und die Führungsknoten zugreifen können. Darüber hinaus bleibt der gemeinsam genutzte Speicher 140 für die anderen führenden Knoten und den Hauptknoten 110 zugänglich, selbst wenn einer der führenden Knoten ausfällt (und selbst wenn der Hauptknoten ausfällt). Der gemeinsam genutzte Speicher 140 kann beispielsweise mit Technologien wie dem Dateisystem, das allgemein mit dem Namen oder der Marke Gluster bezeichnet wird, dem Dateisystem, das allgemein mit dem Namen oder der Marke Oracle Cluster File System (OCFS) oder OCFS2 bezeichnet wird, usw. implementiert werden. In anderen Beispielen können die Leitknoten und der Hauptknoten jedoch einen gemeinsam genutzten Speicher verwenden, der sich außerhalb des Mehrknotensystems befindet. Der gemeinsam genutzte Speicher kann z. B. von einem externen Speichergerät bereitgestellt werden, das über eine Netzwerkverbindung, eine Fibre-Channel-Verbindung, eine Verbindung mit SCSI-Standards (Small Computer System Interface), wie z. B. eine SAS-Verbindung (Serial Attached SCSI), usw. mit dem Mehrknotensystem verbunden ist.
  • In einem Beispiel führt der Hauptknoten 110 ein Serververwaltungsprogramm aus. Das Serververwaltungsprogramm kann auch als „Servermanager 114“ bezeichnet werden. Der Hauptknoten 110 kann den Server-Manager 114 verwenden, um das Multiknoten-System 100 für den HA-Betrieb zu konfigurieren. Zum Beispiel kann der Server-Manager 114 eine Liste von IP-Adressen erstellen, die von den Rechenknoten für die Systemprotokollierung verwendet werden sollen. Diese Liste von IP-Adressen kann als „Adresspool“ bezeichnet werden. zeigt zum Beispiel eine Konfigurationsdatenbank 116 im Hauptknoten 110, die einen solchen Adresspool 118 enthält.
  • Der Hauptknoten 110 kann auch jeden Rechenknoten veranlassen, sein Systemprotokoll an eine bestimmte IP-Adresse aus dem Adresspool 118 zu senden. Insbesondere kann der Server-Manager 114 im Hauptknoten 110 jedem der Rechenknoten in einem ersten Cluster eine erste IP-Adresse aus dem Adresspool 188 zuweisen, jedem der Rechenknoten in einem zweiten Cluster eine zweite IP-Adresse aus dem Adresspool 118 usw., wobei jeder Rechenknoten seine zugewiesene IP-Adresse für die Systemprotokollierung verwenden soll.
  • In einem Beispiel weist der Server-Manager 114 jedem Rechenknoten eine Protokollierungsadresse zu, indem er diese Protokollierungsadresse in die Betriebssystemkonfigurationsdaten für diesen Rechenknoten aufnimmt. Beispielsweise kann der Server-Manager 114 Betriebssystemkonfigurationsdaten 132AA für den Rechenknoten 130AA erstellen, und die Betriebssystemkonfigurationsdaten 132AA können die Protokollierungsadresse enthalten, die vom Rechenknoten 130AA für die Systemprotokollierung verwendet werden soll. Beispielsweise kann der Server-Manager 114 einen Rechenknoten mit einer Protokollierungsadresse konfigurieren, indem er diese Adresse als Option an die Kernel-Parameterliste dieses Knotens übergibt.
  • In ist die zugewiesene Protokollierungsadresse für den Rechenknoten 130AA als Protokollierungsadresse 134AA dargestellt. Der Server-Manager 114 kann diese Protokollierungsadresse auch den anderen Rechenknoten in Cluster A zuweisen. Und wie oben angegeben, kann der Server-Manager 114 den Rechenknoten in den anderen Clustern unterschiedliche Protokollierungsadressen zuweisen. So kann der Server-Manager 114 beispielsweise den Rechenknoten in Cluster A eine erste Protokollierungsadresse (z. B. IP-Adresse A) zuweisen, den Rechenknoten in Cluster B eine zweite Protokollierungsadresse (z. B. IP-Adresse B), usw.
  • Jeder Rechenknoten bootet in einer bestimmten Konfiguration, basierend auf den Betriebssystemkonfigurationsdaten für diesen Rechenknoten, und die Betriebssystemkonfigurationsdaten veranlassen diesen Rechenknoten, seine Systemprotokolldaten an die zugewiesene Protokollierungsadresse zu senden. In einem Beispiel konfiguriert der Server-Manager 114 die Netzwerk-Boot-Dateien für die Rechenknoten so, dass für jeden Rechenknoten eine Protokollierungsadresse definiert wird. In einem anderen Beispiel können die Rechenknoten lokale Boot-Dateien verwenden, und der Server-Manager 114 kann diese lokalen Boot-Dateien mit den Protokollierungsadressen konfigurieren. Das Betriebssystem in jedem Rechenknoten kann Protokollierungssoftware enthalten, und der Server-Manager 114 kann auch sicherstellen, dass diese Protokollierungssoftware so konfiguriert ist, dass sie alle Protokollmeldungen an die zugewiesene Protokollierungsadresse sendet.
  • In anderen Beispielen kann ein Hauptknoten andere Techniken verwenden, um jeden Rechenknoten mit einer zugewiesenen Protokollierungsadresse zu konfigurieren. Beispielsweise kann ein Hauptknoten alle Rechenknoten mit derselben Protokollierungsadresse konfigurieren, und ein Knoten, der diese Adresse abhört, kann als Lastausgleichsknoten arbeiten, indem er Protokollierungsdaten für verschiedene Rechenknoten an verschiedene Leitknoten verteilt. Ein solcher Lastausgleichsknoten kann auch dynamisch anpassen, welche Leitknoten welche Rechenknoten behandeln.
  • Wenn der Server-Manager 114 jedem Cluster von Rechenknoten eine andere Protokollierungsadresse zuweist, kann der Server-Manager 114 gleiche oder ähnliche Clustergrößen verwenden, damit die Last der Systemprotokollierung relativ gleichmäßig auf die Leitknoten verteilt werden kann. Wenn es beispielsweise 10 führende Knoten und 10.000 Rechenknoten in einem System mit mehreren Knoten gibt, kann der Hauptknoten einen Protokollierungsadressen-Pool mit 10 Protokollierungsadressen definieren, der Hauptknoten kann die Rechenknoten in Cluster der Größe 1.000 gruppieren, und der Hauptknoten kann jedem Cluster eine andere Protokollierungsadresse zuweisen, wobei jeder Knoten innerhalb eines Clusters die gleiche Protokollierungsadresse erhält. Diese Art von Ansatz kann als „statischer Ausgleich“ bezeichnet werden. Im Allgemeinen kann der Hauptknoten für ein Mehrknotensystem mit X Leitknoten und Y Rechenknoten ungefähr X verschiedene Protokollierungsadressen verwenden, und der Hauptknoten kann die Rechenknoten in Clustern mit einer Größe von ungefähr Y/X Rechenknoten pro Cluster gruppieren.
  • Wie oben angegeben, enthält das Mehrknotensystem 100 mehrere Leitknoten (z. B. Leitknoten 120A, Leitknoten 120B usw.). Wie unten ausführlicher beschrieben, enthält der Führungsknoten 120A ein Protokollverwaltungsprogramm (oder „Protokollmanager“) 122A, einen HA-Manager 124A, lokale HA-Einstellungen 126A und globale HA-Einstellungen 128A. Der HA-Manager 124A enthält Programme wie z. B. einen Zustandsmonitor 125A. Zu den lokalen HA-Einstellungen 126A gehören Daten, um insbesondere den Leader-Knoten 120A zu konfigurieren, wie z. B. eine Listenliste 127A. Mit anderen Worten, die lokalen HA-Einstellungen in einem Führungsknoten umfassen die Einstellungen, die auf diesem Knoten aktiv sind. Die globalen HA-Einstellungen umfassen Daten, die von allen Leitknoten verwendet werden, um den HA-Betrieb zu gewährleisten, wie z. B. eine Kopie des Adresspools 118. Dementsprechend können die globalen HA-Einstellungen als eine systemweite, gemeinsam genutzte Datenbank betrachtet werden, die von den Führungsknoten verwendet wird, um die Verwaltung der Rechenknoten zu koordinieren.
  • Jeder Führungsknoten im Mehrknotensystem 100 (z. B. Führungsknoten 120B usw.) kann die gleichen Arten von Funktionen enthalten, wie sie im Führungsknoten 120A dargestellt sind. Beispielsweise kann der Führungsknoten 120B einen Protokollmanager 122B, einen HA-Manager 124B mit Programmen wie einem Zustandsmonitor, lokale HA-Einstellungen 126B mit einer Listenliste 127B und globale HA-Einstellungen 128B enthalten.
  • Der Server-Manager 114 konfiguriert jeden führenden Knoten, um Aufgaben wie den Empfang von Systemprotokolldaten von Rechenknoten und das Speichern dieser Daten im gemeinsamen Speicher 140 zu bewältigen. In einem Beispiel tut der Server-Manager 114 dies, indem er das Betriebssystem-Image für jeden führenden Knoten mit der erforderlichen Software, z. B. dem Protokoll-Manager, konfiguriert und dann dieses Betriebssystem-Image auf dem Stamm laufwerk für jeden führenden Knoten speichert. Darüber hinaus kann der Server-Manager 114 anschließend Konfigurationsdaten für den führenden Knoten auf dieses Stamm laufwerk übertragen. Der Server-Manager 114 kann beispielsweise ein Secure Shell (SSH)-Protokoll verwenden, um Dateien auf Root-Laufwerke für führende Knoten zu übertragen.
  • Die Konfigurationsdaten, die der Hauptknoten 110 an jeden Führungsknoten sendet, können die globalen HA-Einstellungen enthalten. Wie oben erwähnt, können die globalen HA-Einstellungen den Adresspool 118 enthalten. Die globalen HA-Einstellungen können auch zusätzliche Daten enthalten, die es den Führungsknoten ermöglichen, die Systemprotokollierung und die Konsolenverwaltung kooperativ zu handhaben. Diese zusätzlichen Daten können z. B. eine Liste zur Identifizierung aller Leader-Knoten und Daten zur Identifizierung einer Datei im gemeinsamen Speicher 140 enthalten, die als Leader-Ressourcensperre 146 dient und von den Leader-Knoten für die Zusammenarbeit verwendet wird. Beispielsweise können die Leader-Knoten die Leader-Ressourcensperre 146 verwenden, um atomare Operationen zu gewährleisten und um sicherzustellen, dass alle aktiven Leader-Knoten allen Konfigurationsänderungen zustimmen.
  • So kann der Hauptknoten 110 alle Führungsknoten so konfigurieren, dass sie Systemprotokoll- (oder „Syslog-“) Listener für jeden möglichen Rechenknoten sind und alle empfangenen Syslog-Daten in den gemeinsamen Speicher 140 schreiben. Wie weiter unten genauer beschrieben, können die Leitknoten dann zusammenarbeiten, um der Listenliste in jedem Leitknoten eine andere der Protokolladressen zuzuweisen. In anderen Beispielen kann ein Hauptknoten jedoch auch andere Techniken verwenden, um jeden Führungsknoten zu konfigurieren. Beispielsweise kann jeder Führungsknoten einen Server-Management-Daemon enthalten, der den Führungsknoten für die Handhabung der Protokollierung für Rechenknoten konfiguriert.
  • Wie in dargestellt, führt jeder Führungsknoten eine Instanz des Protokollmanagers und eine Instanz des HA-Managers aus. Der Protokollmanager enthält Anweisungen, die, wenn sie in einem Führungsknoten ausgeführt werden, diesen Führungsknoten in die Lage versetzen, Vorgänge wie den Empfang von Systemprotokolldaten von Rechenknoten und das Speichern dieser Systemprotokolldaten im gemeinsamen Speicher 140 durchzuführen.
  • Die HA-Manager ermöglichen es den Führungsknoten, die Protokollierungsaufgaben beim Start kooperativ untereinander zu verteilen und kooperativ und dynamisch für Failover zu sorgen, indem sie die Protokollierungsaufgaben als Reaktion auf den Ausfall und die Wiederherstellung von Führungsknoten anpassen. Um die Protokollierungsaufgaben beim Start des Mehrknotensystems 100 zu verteilen, verwenden die Führungsknoten ihre HA-Manager, um sich für eine Standard- oder Normalkonfiguration zu entscheiden, in der jeder Führungsknoten die Systemprotokollierung für einen Cluster übernimmt. Insbesondere können die Führungsknoten diese Konfiguration übernehmen, indem sie zusammenarbeiten, um eine andere Protokollierungsadresse zur Listenliste in jedem Führungsknoten hinzuzufügen. Wie oben erwähnt, kann die anfängliche oder standardmäßige Protokollierungsadresse in der Abhörliste für einen Führungsknoten als die primäre Protokollierungsadresse angesehen werden, die von diesem Führungsknoten bedient wird.
  • Die HA-Manager ermöglichen es den Führungsknoten auch, für eine Ausfallsicherung zu sorgen. Beispielsweise kann der HA-Manager in jedem Leader-Knoten die globalen HA-Einstellungen verwenden, um zu verfolgen, welche Leader-Knoten betriebsbereit sind und welche Protokollierungsadressen von welchen Leader-Knoten bearbeitet werden. Der HA-Manager in jedem Leader-Knoten kann auch den Ausfall eines anderen Leader-Knotens erkennen. Die HA-Manager können dann reagieren, indem sie automatisch (d. h. ohne menschliches Eingreifen) einen Führungsknoten auswählen, der als Failover-Knoten für den ausgefallenen Knoten dient. Wenn zum Beispiel der Führungsknoten 120B ausfällt, kann der HA-Manager 124A den Führungsknoten 120A so konfigurieren, dass er als Failover-Knoten für den Führungsknoten 120B dient. Oder wenn der Führungsknoten 120A ausfällt, kann der HA-Manager 124B den Führungsknoten 120B so konfigurieren, dass er als Failover-Knoten für den Führungsknoten 120A dient. Insbesondere kann der HA-Manager in einem ersten Leader-Knoten diesen Leader-Knoten so konfigurieren, dass er als Failover-Knoten für einen zweiten Leader-Knoten dient, indem er den Failover-Leader-Knoten so konfiguriert, dass er mehrere Protokollierungsadressen verwaltet, einschließlich der primären Protokollierungsadresse des Failover-Knotens sowie der verwaisten Protokollierungsadresse, die von dem ausgefallenen Knoten verwaltet wurde. Außerdem können die Leader-Knoten die Leader-Ressourcensperre 146 verwenden, um gemeinsam zu entscheiden, welcher Leader-Knoten als Failover-Knoten dienen soll.
  • Der HA-Manager kann auch die globalen HA-Einstellungen in jedem Leader-Knoten aktualisieren, wenn sich die globale Konfiguration geändert hat (z. B. als Reaktion darauf, dass ein Leader-Knoten so konfiguriert wurde, dass er als Failover-Knoten dient, oder als Reaktion darauf, dass ein ausgefallener Leader-Knoten wiederhergestellt wurde und die Protokollierungsaufgaben von einem Failover-Knoten zurückerhält).
  • Wie oben erwähnt, identifiziert die Listenliste in einem Führungsknoten die IP-Adresse(n), die von diesem Führungsknoten behandelt werden sollen. Mit anderen Worten: Der Protokoll-Manager in jedem Führungsknoten empfängt Systemprotokolldaten von Rechenknoten basierend auf der Abhörliste in diesem Führungsknoten. zeigt beispielsweise die Listenliste 127A in den lokalen HA-Einstellungen 126A im Führungsknoten 120A, und zeigt die Listenliste 127B in den lokalen HA-Einstellungen 126B im Führungsknoten 120B. Wie oben angedeutet, können die Führungsknoten eine solche Konfiguration, bei der jeder Führungsknoten eine Protokollierungsadresse behandelt, als normale oder Standardkonfiguration einrichten. In ist eine solche Standardkonfiguration für ein Beispiel dargestellt, bei dem die Listenliste 127A die Protokollierungsadresse enthält, die von den Rechenknoten in Cluster A verwendet werden soll (d. h. die Protokollierungsadresse „IP-Adresse A“), und die Listenliste 127B die Protokollierungsadresse enthält, die von den Rechenknoten in Cluster B verwendet werden soll (d. h. die Protokollierungsadresse „IP-Adresse B“). Folglich veranlasst die Listenliste 127A den Führungsknoten 120A, Systemprotokolldaten für Cluster A zu verarbeiten, und die Listenliste 127B veranlasst den Führungsknoten 120B, Systemprotokolldaten für Cluster B zu verarbeiten. Wie jedoch weiter unten ausführlicher beschrieben wird, könnte der Führungsknoten 120A bei einem Ausfall des Führungsknotens 120B (zum Beispiel) automatisch die Protokollierungsaufgaben für Cluster B übernehmen, indem er die IP-Adresse B zur Listenliste 127A im Führungsknoten 120A hinzufügt.
  • In einem Beispiel speichern die Leitknoten die Systemprotokolldaten für jeden Rechenknoten in einer separaten Datei. Beispielsweise kann der Führungsknoten 120A die Systemprotokolldaten für die Rechenknoten 130AA und 130AB in den jeweiligen Systemprotokolldateien 142AA und 142AB speichern, und der Führungsknoten 120B kann die Systemprotokolldaten für die Rechenknoten 130BA und 130BB in den jeweiligen Systemprotokolldateien 142BA und 142BB speichern. Dementsprechend kann der Log-Manager als „Syslog-Server“ bezeichnet werden.” Der Log-Manager kann mit dem Programm implementiert werden, das z. B. unter dem Namen oder Warenzeichen „rsyslog“ bekannt ist. Darüber hinaus kann der Protokollmanager so konfiguriert sein, dass er Syslog-Daten unter Verwendung eines bestimmten Pfads im gemeinsamen Speicher 140 speichert (z. B. ein Pfad wie „/var/log/HOSTS/hostname“, wobei „hostname“ eine Kennung für den Rechenknoten ist, der die Syslog-Daten erzeugt hat). In anderen Beispielen können die Leitknoten die Systemprotokolldaten anders behandeln. Zum Beispiel können die führenden Knoten die Systemprotokolldaten für jeden Rechenknoten in separate Dateien aufteilen.
  • In einem Beispiel nimmt der Hauptknoten 110 als Client am gemeinsamen Speicher 140 teil, wodurch ein Systemadministrator den Hauptknoten 110 verwenden kann, um alle Systemprotokolle für alle Rechenknoten aus einer einzigen Quelle zu lesen, auch wenn mehrere Hauptknoten Syslog-Daten für mehrere Rechenknoten in diese Quelle schreiben können.
  • Wie weiter unten ausführlicher beschrieben, können Leitknoten auch die Konsolenverwaltung von Rechenknoten ermöglichen (z. B. durch Speichern von Konsolenprotokolldateien 144 für die Rechenknoten im gemeinsamen Speicher 140).
  • ist ein Flussdiagramm, das einen Prozess zur elastischen Protokollierung von Systemprotokolldaten gemäß einer Beispielimplementierung veranschaulicht. In dieser Offenbarung wird im Kontext des Mehrknotensystems 100 beschrieben, wie in dargestellt. Wie in den Blöcken 210 und 212 gezeigt, kann der Prozess von damit beginnen, dass der Servermanager 114 im Hauptknoten 110 die Führungsknoten und die Rechenknoten mit Software- und Konfigurationseinstellungen für die Systemprotokollierung konfiguriert, wie oben beschrieben.
  • Wie in Block 214 gezeigt, können die Leader-Knoten dann kooperativ eine normale oder Standardkonfiguration annehmen. Insbesondere können die Leader-Knoten ihre HA-Manager und globalen HA-Einstellungen verwenden, um zu überprüfen, ob alle Leader-Knoten in Betrieb sind. Die Leitknoten können dann ihre HA-Manager und den Adresspool 118 verwenden, um jedem Leitknoten eine Protokollierungsadresse zuzuweisen. Mit anderen Worten, die Leitknoten können zusammenarbeiten, um jedem Leitknoten eine andere der Protokollierungsadressen zuzuweisen. Als Teil der Übernahme der normalen Konfiguration kann jeder Führungsknoten seine zugewiesene Protokollierungsadresse in seiner Listenliste speichern. Die Leitknoten legen damit eine Standardkonfiguration fest, in der jeder Leitknoten für die Handhabung der Systemprotokollierung für einen Cluster von Rechenknoten verantwortlich ist.
  • Als Teil der Einrichtung der Standardkonfiguration können die Leader-Knoten außerdem ihre HA-Manager verwenden, um einen der Leader-Knoten als Master-Knoten auszuwählen, der dabei hilft, das dynamische Failover und die Wiederherstellung unter den Leader-Knoten zu koordinieren. Der Master-Knoten kann z. B. den Zustandsmonitor in seinem HA-Manager verwenden, um den Zustand der übrigen Leader-Knoten zu überwachen. Wenn der Masterknoten ausfällt, können die anderen Masterknoten einen Masterknoten auswählen, der als neuer Masterknoten fungiert. In jedem Führungsknoten kann der HA-Manager eine Kennung für den aktuellen Masterknoten in den globalen HA-Einstellungen pflegen.
  • Wie in Block 216 gezeigt, kann das Mehrknotensystem 100 dann mit den Führungsknoten arbeiten, die die Systemprotokollierung für die Rechenknoten verwalten, basierend auf den Protokollierungsadressen in den Listenlisten in den Führungsknoten. Mit anderen Worten: Jeder Führungsknoten kann Syslog-Daten empfangen, die an die Protokollierungsadresse in der Listenliste dieses Knotens adressiert sind, und diese Syslog-Daten im gemeinsamen Speicher 140 speichern. Der Fluss kann bei Block 216 bleiben, wobei die Leader-Knoten Syslog-Daten von ihren jeweiligen Clustern verarbeiten, bis einer der Leader-Knoten ausfällt.
  • Wie in Block 220 gezeigt, können die anderen Leader-Knoten diesen Ausfall erkennen, wenn einer der Leader-Knoten ausfällt. Wenn zum Beispiel, wie oben angegeben, ein Master-Knoten den Ausfall eines Leader-Knotens erkennt, kann der Master-Knoten die anderen Leader-Knoten über diesen Ausfall informieren.
  • Wie in Block 222 gezeigt, können die verbleibenden Leitknoten als Reaktion auf den Ausfall eines Leitknotens automatisch die Protokollierungskonfiguration des Mehrknotensystems 100 ändern. Insbesondere können die HA-Manager in den Führungsknoten kooperativ einen Führungsknoten auswählen, der als Failover-Knoten für den ausgefallenen Knoten dient, und dieser Failover-Knoten kann die verwaiste Protokollierungsadresse zur Listenliste des Failover-Knotens hinzufügen. Und wie oben erwähnt, können die HA-Manager bei solchen kooperativen Entscheidungen und Änderungen die Leader-Ressourcensperre 146 im gemeinsam genutzten Speicher 140 verwenden, um atomare Operationen zu gewährleisten und um sicherzustellen, dass alle aktiven Leader-Knoten allen Konfigurationsänderungen zustimmen.
  • Der Prozess kann dann zu Block 216 zurückkehren, wobei die Leitknoten die Systemprotokollierung gemäß der neuen/aktuellen Konfiguration handhaben.
  • Wenn ein ausgefallener Leader-Knoten wieder in Betrieb genommen wird, können die anderen Leader-Knoten diese Wiederherstellung erkennen (siehe Block 230). Beispielsweise kann der Zustandsmonitor im Master-Knoten den wiederhergestellten Knoten erkennen, und der HA-Manager im Master-Knoten kann darauf reagieren, indem er die HA-Manager in den anderen Leader-Knoten über die Wiederherstellung benachrichtigt.
  • Wie in Block 222 gezeigt, können die Führungsknoten als Reaktion auf die Wiederherstellung eines ausgefallenen Führungsknotens die Protokollierungskonfiguration des Mehrknotensystems 100 ändern, um die Protokollierungsaufgaben für eine Protokollierungsadresse vom Failover-Knoten auf den wiederhergestellten Knoten zu verschieben. Wenn beispielsweise der Führungsknoten 120A als Failover-Knoten für den Führungsknoten 120B diente und dann der Führungsknoten 120B wiederhergestellt wurde, kann der HA-Manager 124A im Führungsknoten 120A die IP-Adresse B aus der Listenliste 127A entfernen, und der HA-Manager 124B im Führungsknoten 120B kann die IP-Adresse B zur Listenliste 127B hinzufügen. Der Prozess kann dann zu Block 216 zurückkehren, wobei die Führungsknoten die Systemprotokollierung gemäß der neuen/aktuellen Konfiguration behandeln. Die Leitknoten können dann weiterhin Systemprotokolldaten verarbeiten und dynamisch auf Änderungen des Zustands der Leitknoten reagieren, wie oben angegeben.
  • ist ein Blockdiagramm eines Mehrknotensystems mit Technologie für belastbares Konsolenmanagement gemäß einer Beispielimplementierung. Insbesondere zeigt ein Beispiel, in dem das Mehrknotensystem 100 die Systemprotokollierung, wie oben in Bezug auf die 1 und 2 beschrieben, und gleichzeitig Konsolenverwaltungsaufgaben wie die Weiterleitung von Konsolenverbindungen und die Konsolenprotokollierung vorsieht. Während jedoch in die an der Systemprotokollierung beteiligten Komponenten dargestellt sind, konzentriert sich mehr auf die an der Konsolenverwaltung beteiligten Komponenten. Dementsprechend sind einige Komponenten des Mehrknotensystems 100 in nicht oder in anderer Weise dargestellt. Beispielsweise werden die Systemprotokolldateien im gemeinsamen Speicher 140 gemeinsam als Systemprotokolldateien 142 dargestellt.
  • Im Beispiel von führt jeder Führungsknoten ein Konsolenverwaltungsprogramm (oder „Konsolenmanager“) aus, das den verwalteten Zugriff auf die Konsolen von Rechenknoten und die Protokollierung aller entsprechenden Konsolendaten ermöglicht. Der Konsolenmanager in einem Leader-Knoten ermöglicht es diesem Leader-Knoten, als Vermittler zu fungieren, damit der Head-Knoten 110 mit der Konsole eines Rechenknotens interagieren kann. Mit anderen Worten, der Konsolenmanager in einem Führungsknoten ermöglicht dem Hauptknoten 110 die Interaktion mit der Konsole eines Rechenknotens über diesen Führungsknoten. Wie unten ausführlicher beschrieben, verwendet ein Konsolenmanager in einem Führungsknoten in einem Beispiel Konfigurationsdateien, um Verbindungen zu Rechenknoten herzustellen, und diese Konfigurationsdateien sind Teil der lokalen HA-Einstellungen in diesem Führungsknoten.
  • Darüber hinaus können die HA-Manager in den Führungsknoten den Hauptknoten 110 für die Weiterleitung von Verbindungen konfigurieren, und die HA-Manager können ein automatisches Failover der Konsolenverwaltungsaufgaben von einem ausgefallenen Führungsknoten zu einem Failover-Führungsknoten vorsehen. Die HA-Manager können auch für eine automatische Wiederherstellung der Konsolenverwaltungsaufgaben nach der Wiederherstellung eines ausgefallenen Führungsknotens sorgen.
  • Beispielsweise können die HA-Manager den Hauptknoten 110 anfänglich mit CCFCD 117 bereitstellen, damit ein Systemadministrator den Hauptknoten 110 verwenden kann, um mit der Konsole auf einem beliebigen Rechenknoten zu interagieren, ohne dass der Systemadministrator wissen muss, welcher Hauptknoten die Verbindung zur Konsole auf diesem Rechenknoten bereitstellen wird. Die HA-Manager können CCFCD 117 z. B. in der Konfigurationsdatenbank 116 speichern. CCFCD 117 kann eine Liste oder Tabelle enthalten, die angibt, welche Leader-Knoten als Konsolenbrücken zu welchen Rechenknoten konfiguriert sind. Mit anderen Worten, als Teil der Einrichtung der Konsolenverbindungs-Weiterleitungskonfiguration kann der HA-Manager in jedem Führungsknoten mit dem Hauptknoten 110 kommunizieren, um CCFCD 117 im Hauptknoten 110 mit einer Liste der Rechenknoten zu füllen, die von diesem Führungsknoten verwaltet werden. Der Hauptknoten 110 kann anschließend diese Listen verwenden, um jede Anforderung für den Konsolenzugriff auf einen bestimmten Rechenknoten an den Hauptknoten zu leiten, der diesen Rechenknoten verwaltet. Dateisperren, getrennte Konfigurationsdateien unter Verwendung von Include-Anweisungen oder andere Mechanismen können eingesetzt werden, um zu verhindern, dass mehrere Führungsknoten die CCFCD 117 beschädigen, weil mehrere Führungsknoten versuchen, gleichzeitig zu schreiben. In einem Beispiel kann ein führender Knoten eine Sperrdatei auf dem Hauptknoten 110 mithilfe von SSH erstellen und dann mithilfe von SSH einen Teil der CCFCD 117 neu schreiben. Andere Beispiele können Include-Dateien oder andere Mechanismen verwenden, um Korruption zu verhindern.
  • Wie oben erwähnt, sorgen die HA-Manager auch für eine Ausfallsicherung der Konsolenverwaltungsaufgaben. Wie unten ausführlicher beschrieben, kann der HA-Manager in einem Failover-Leader-Knoten beispielsweise ein Event-Handler-Skript verwenden, um diesen Knoten neu zu konfigurieren, damit er die Konsolenverwaltungsaufgaben (z. B. Weiterleitung von Konsolenverbindungen und Konsolenprotokollierung) übernimmt, die vom ausgefallenen Knoten übernommen wurden. Diese Verwaltungsaufgaben können auch die Aktualisierung von CCFCD 117 entsprechend der neuen Konfiguration umfassen.
  • Im Beispiel von stellen Konsolen-Manager 152A und Konsolen-Manager 152B verschiedene Instanzen des Konsolen-Managers dar, die auf den Leitknoten 120A bzw. 120B laufen.
  • Die Konsolenmanager ermöglichen es den Leitknoten auch, ein Protokoll jeder Konsolensitzung im gemeinsamen Speicher 140 zu speichern. In einem Beispiel speichern die Konsolenmanager die Konsolenprotokolldaten für jeden Rechenknoten in einer separaten Datei. Beispielsweise kann der Konsolenmanager 152A die Konsolenprotokolldaten für die Rechenknoten 130AA und 130AB in den jeweiligen Konsolenprotokolldateien 144AA und 144AB speichern, und der Konsolenmanager 152B im Führungsknoten 120B kann die Konsolenprotokolldaten für die Rechenknoten 130BA und 130BB in den jeweiligen Konsolenprotokolldateien 144BA und 144BB speichern.
  • In einem Beispiel enthält jeder Rechenknoten einen Verwaltungsprozessor (MP), und die Leitknoten verwenden diese Verwaltungsprozessoren, um auf die Konsolen auf den Rechenknoten zuzugreifen. Im Beispiel von enthält der Rechenknoten 130AA einen MP 136AA, der Rechenknoten 130AB enthält einen MP 136AB usw. Ebenso enthält der Rechenknoten 130BA einen MP 136BA, der Rechenknoten 130BB enthält einen MP 136BB usw.
  • Ein Verwaltungsprozessor kann als Mikrocontroller, als System auf einem Chip (SoC), als eingebetteter Prozessor oder als jeder andere geeignete Prozessortyp implementiert sein. In einigen Beispielen dient ein Verwaltungsprozessor für einen Knoten als Knoten-Controller oder als Baseboard-Management-Controller (BMC), der für das Lights-Out-Management (LOM) oder das integrierte Lights-Out-Management (iLO) des Knotens sorgt. In anderen Beispielen können sich mehrere Knoten einen einzigen Verwaltungsprozessor teilen.
  • Wie hier verwendet, bezieht sich der Begriff „BMC“ auf einen spezialisierten Serviceprozessor, der den physikalischen Zustand eines Computersystems mithilfe von Sensoren überwacht und über eine unabhängige „Out-of-Band“-Verbindung mit einem Managementsystem kommuniziert. Ein „Computersystem“ kann sich auf einen Server-Computer, einen Benutzer-Computer oder ein beliebiges elektronisches Gerät oder eine Sammlung von elektronischen Geräten beziehen. Die BMC kann auch mit Anwendungen kommunizieren, die auf Betriebssystemebene ausgeführt werden, und zwar über einen IOCTL-Schnittstellentreiber (Input/Output Controller), ein SSH, eine REST (Representational State Transfer)-Anwendungsprogrammschnittstelle (API) oder einen anderen Systemsoftware-Proxy, der die Kommunikation zwischen der BMC und Anwendungen erleichtert. Die BMC kann auf Hardware-Ebene Zugriff auf Hardware-Komponenten im Computersystem haben. Die BMC kann in der Lage sein, die Hardware-Komponenten direkt zu modifizieren. Die BMC kann unabhängig vom Betriebssystem des Computersystems arbeiten, in dem sich die BMC befindet. Die BMC kann sich auf dem Motherboard oder der Hauptplatine des zu überwachenden Computersystems befinden. Die Tatsache, dass eine BMC auf einer Hauptplatine des zu überwachenden Computersystems montiert oder anderweitig mit dem zu überwachenden Computersystem verbunden oder daran angebracht ist, verhindert nicht, dass die BMC als getrennt von einer Verarbeitungsressource betrachtet wird, die das Betriebssystem ausführt. Eine BMC verfügt über Verwaltungsfunktionen zur Verwaltung von Komponenten des Computersystems. Beispiele für Verwaltungsfunktionen des BMC können eine oder eine Kombination der folgenden Funktionen umfassen: Stromversorgungssteuerung, thermische Überwachung und Steuerung, Lüftersteuerung, Überwachung des Systemzustands, Fernzugriff auf das Computersystem, Fernneustart des Computersystems, Systemeinrichtung und -bereitstellung, Systemsicherheit usw.
  • In einigen Beispielen kann ein BMC eine sogenannte „Lights-Out“-Funktionalität für Computergeräte bereitstellen. Die „Lights-Out“-Funktionalität kann es einem Benutzer, z. B. einem Systemadministrator, ermöglichen, Verwaltungsvorgänge auf dem Computersystem durchzuführen, auch wenn kein Betriebssystem auf dem Computersystem installiert ist oder nicht funktioniert. Darüber hinaus kann die BMC in einigen Beispielen mit Hilfsenergie (z. B. Batteriestrom) betrieben werden; daher muss das Computersystem nicht eingeschaltet sein, damit die BMC ihre Operationen durchführen kann. Die von der BMC bereitgestellten Dienste können als „Out-of-Band“-Dienste betrachtet werden, da das Betriebssystem möglicherweise nicht läuft und in einigen Fällen das Computersystem ausgeschaltet ist oder nicht ordnungsgemäß funktioniert (z. B. wenn das Computersystem einen Fehler oder einen Hardwareausfall aufweist).
  • Die BMC kann eine Kommunikationsschnittstelle, wie z. B. eine Netzwerkschnittstelle, und/oder eine serielle Schnittstelle enthalten, über die ein Administrator oder eine andere Instanz aus der Ferne mit der BMC kommunizieren kann. Ein „Out-of-Band“-Dienst kann von der BMC über einen dedizierten Verwaltungskanal (z. B. die Kommunikationsschnittstelle) bereitgestellt werden, und der „Out-of-Band“-Dienst kann unabhängig davon verfügbar sein, ob sich das Computersystem in einem eingeschalteten Zustand befindet oder nicht.
  • ist ein Flussdiagramm, das einen Prozess für die elastische Konsolenverwaltung gemäß einer Beispielimplementierung zeigt. Der Prozess von kann jedoch parallel zu dem Prozess von ablaufen. Wie in Block 410 gezeigt, beginnt der Prozess von beispielsweise damit, dass der Servermanager 114 die Leader-Knoten für die Konsolenverwaltung konfiguriert. Und der Server-Manager kann diesen Vorgang als Teil des Vorgangs zum Konfigurieren von Führungsknoten für das Clustermanagement durchführen, wie in Block 210 von gezeigt. Das Konfigurieren des Führungsknotens für die Konsolenverwaltung kann das Schieben von Konsolenverwaltungsdaten vom Hauptknoten 110 zu den Führungsknoten umfassen, damit die Führungsknoten die Weiterleitung von Konsolenverbindungen zu den Rechenknoten bereitstellen können. Die Konsolenverwaltungsdaten können beispielsweise eine Tabelle enthalten, die jeden Rechenknoten identifiziert und die angibt, welche Protokollierungsadresse jedem Rechenknoten zugewiesen ist, und der Server-Manager 114 kann die Konsolenverwaltungsdaten in die globalen HA-Einstellungen aufnehmen, die an die Führungsknoten übertragen werden.
  • Wie in Block 414 gezeigt, können die führenden Knoten dann ihre HA-Manager verwenden, um kooperativ eine Standard-Konsolenmanagementkonfiguration zu übernehmen. Dieser Vorgang kann z. B. als Teil des Vorgangs zur kooperativen Übernahme einer Standard-Cluster-Verwaltungskonfiguration durchgeführt werden, wie in Block 214 von dargestellt. In einer Ausführungsform sind die HA-Manager so ausgelegt, dass sie eine Standard-Konsolenverwaltungskonfiguration einrichten, die die Systemprotokollierungskonfiguration widerspiegelt, wobei jeder führende Knoten als Konsolenmanager für die Rechenknoten im Cluster dient, für die dieser führende Knoten die Systemprotokollierung übernimmt. In Bezug auf können die HA-Manager beispielsweise eine Standardkonfiguration einrichten, in der der Führungsknoten 120A als Konsolenmanager für die Rechenknoten in Cluster A und der Führungsknoten 120B als Konsolenmanager für die Rechenknoten in Cluster B dient. Wenn ein Führungsknoten als Konsolenmanager dient, kann der Führungsknoten Konsolenverwaltungsaufgaben wie die Weiterleitung von Konsolenverbindungen und die Konsolenprotokollierung durchführen.
  • Ein Teil der Übernahme der Standard-Cluster-Management-Konfiguration kann darin bestehen, dass jeder führende Knoten Konfigurationsdateien für seinen Konsolenmanager erstellt, damit der Konsolenmanager eine Verbindung mit der Konsole jedes Rechenknotens unter diesem führenden Knoten herstellen kann. Für die Zwecke dieser Offenlegung kann eine Konfigurationsdatei, die es einem Führungsknoten ermöglicht, eine Verbindung mit einer Konsole eines Rechenknotens herzustellen, als „Konsolenmanager-Konfigurationsdatei“ (CMCF) bezeichnet werden. Ein Leader-Knoten kann seine CMCFs in den lokalen HA-Einstellungen speichern. Wenn beispielsweise der führende Knoten 120A als Konsolenbrücke zu den Rechenknoten in Cluster A dienen soll, kann der HA-Manager 124A eine erste CMCF erstellen, um dem Konsolenmanager 152A eine Verbindung zur Konsole des Rechenknotens 103AA zu ermöglichen, eine zweite CMCF, um dem Konsolenmanager 152A eine Verbindung zur Konsole des Rechenknotens 130AB zu ermöglichen, usw. Der HA-Manager 124A kann diese CMCFs 119 in den lokalen HA-Einstellungen 126A speichern.
  • Der HA-Manager in jedem Leader-Knoten kann auch die Konfigurationsdatenbank 116 im Head-Knoten mit CCFCD 117 aktualisieren. Wie oben angegeben, handelt es sich bei CCFCD 117 um Konfigurationsdaten, die es dem Kopfknoten 110 ermöglichen, über die Leitknoten mithilfe der Konsolenverbindungsweiterleitung auf Konsolen auf den Rechenknoten zuzugreifen.
  • Wie in Block 416 von gezeigt, können die Führungsknoten dann als Konsolenbrücken dienen und alle zugehörigen Konsolenprotokolldaten speichern, je nach Bedarf. Beispielsweise kann der Konsolenmanager 152A einem menschlichen Systemadministrator ermöglichen, über den Hauptknoten 110 auf die Konsole des Rechenknotens 130AA über den Führungsknoten 120A zuzugreifen. Und der Konsolenmanager 152A kann die zugehörigen Konsolenprotokolldaten im gemeinsamen Speicher 140 speichern. Und die Vorgänge von Block 416 können parallel zu dem Vorgang zur Handhabung der Systemprotokollierung für Rechenknoten ausgeführt werden, wie in Block 216 von gezeigt.
  • Wie in Block 420 von gezeigt (der auch Block 220 von entsprechen kann), können die HA-Manager den Ausfall eines Leitknotens erkennen. Wenn dies der Fall ist, können die HA-Manager, wie in Block 422 gezeigt (der parallel zu Anspruch 22 von ausgeführt werden kann), reagieren, indem sie kooperativ eine neue Konfiguration für die Konsolenverwaltung annehmen. Wenn die HA-Manager z. B. einen Failover-Knoten für die Systemprotokollierung auswählen, kann der HA-Manager denselben Failover-Knoten für die Konsolenverwaltung auswählen.
  • In einem Beispiel enthält der HA-Manager in jedem Führungsknoten ein Event-Handler-Skript, das automatisch ausgeführt wird, wenn eine Protokollierungsadresse zur Abhörliste in diesem Führungsknoten hinzugefügt oder daraus entfernt wird, und die HA-Manager verwenden diese Event-Handler-Skripts, um die neue Konfiguration zu übernehmen. In einem Szenario, in dem beispielsweise der Führungsknoten 120A als Failover-Knoten für einen ausgefallenen Führungsknoten 120B ausgewählt wird, fügt der HA-Manager 124A die IP-Adresse B zur Abhörliste 127A hinzu. Daraufhin ruft das Event-Handler-Skript 154A im HA-Manager 124A eine Liste der Rechenknoten im Cluster B aus den globalen HA-Einstellungen 128A ab. (Wie oben erwähnt, können die globalen HA-Einstellungen Konsolenverwaltungsdaten enthalten, um zu identifizieren, welche Rechenknoten zu welchem Cluster gehören.) Das Event-Handler-Skript 154A erstellt dann neue CMCFs, damit der Konsolenmanager 152A eine Verbindung zu den Konsolen der Rechenknoten in Cluster B herstellen kann. Und das Event-Handler-Skript 154A kann diese CMCFs in den lokalen HA-Einstellungen 126A speichern.
  • Wie in Block 424 gezeigt, kann der HA-Manager im Failover-Knoten dann den Kopfknoten 110 über die Änderungen an der Konsolenverwaltungskonfiguration benachrichtigen, um den Kopfknoten 110 in die Lage zu versetzen, den Failover-Knoten für die Weiterleitung von Konsolenverbindungen an Rechenknoten zu verwenden, die unter dem ausgefallenen Knoten lagen. Mit anderen Worten: Wenn eine neue Konfiguration angepasst wird, aktualisiert der Führungsknoten die CCFCD 117 im Kopfknoten 110, um die neue Konfiguration wiederzugeben. Mit anderen Worten: Der HA-Manager rekonfiguriert den Hauptknoten 110, um den Hauptknoten 110 zu veranlassen, den Failover-Knoten für den Zugriff auf Konsolen auf den Rechenknoten zu verwenden, die jetzt vom Failover-Knoten verwaltet werden. Ein menschlicher Administrator kann dann den Konsolenbefehl für einen beliebigen Rechenknoten vom Kopfknoten 110 aus ausführen, auch wenn dieser Rechenknoten von einem beliebigen Leader-Knoten bedient werden könnte.
  • Der Prozess kann dann zu Block 416 zurückkehren, wobei die Leitknoten als Konsolenbrücken dienen und Konsolenprotokolldaten entsprechend der aktuellen Konfiguration des Mehrknotensystems 100 speichern.
  • Wenn die Leader-Knoten jedoch die Wiederherstellung eines Leader-Knotens erkennen, kann der Prozess über Block 430 zu Block 422 übergehen, wobei die Leader-Knoten dann eine neue Konfiguration annehmen, die die Konsolenverwaltungsaufgaben vom Failover-Knoten zurück auf den wiederhergestellten Knoten verlagert. Folglich kann der ehemalige Failover-Knoten eine Protokollierungsadresse aus seiner Listenliste entfernen, was das Event-Handler-Skript auslösen kann, das die lokalen HA-Einstellungen durch Löschen der CMCFs für die Rechenknoten, die zurück zum wiederhergestellten Knoten übertragen werden, aktualisieren kann. Und wie in Block 424 gezeigt, können die Leader-Knoten den Head-Knoten 110 über diese neue/wiederhergestellte Konfiguration informieren.
  • Darüber hinaus können Leader-Knoten bei der kooperativen Übernahme von Konfigurationen die Leader-Ressourcensperre 146 verwenden, um atomare Operationen für Änderungen an Listenlisten usw. sicherzustellen.
  • Weitere Implementierungen:
  • ist ein Blockdiagramm eines computerlesbaren Mediums 510, das Anweisungen 520 umfasst, die bei Ausführung durch einen Knoten in einem Datenverarbeitungssystem mit mehreren Knoten den Knoten befähigen, als Führungsknoten zu dienen. Insbesondere ermöglichen Anweisungen 520 dem Knoten, als ein erster Führungsknoten zu dienen, indem er Systemprotokolldaten von mehreren Rechenknoten in einem ersten Cluster des Mehrknoten-Datenverarbeitungssystems empfängt, die Systemprotokolldaten in einem gemeinsamen Speicher speichert, der auch von einem zweiten Führungsknoten verwendet wird, um Systemprotokolldaten für Rechenknoten in einem zweiten Cluster des Mehrknoten-Datenverarbeitungssystems zu speichern, und von einem dritten Führungsknoten, um Systemprotokolldaten für Rechenknoten in einem dritten Cluster des Mehrknoten-Datenverarbeitungssystems zu speichern, und als Reaktion auf den Ausfall des zweiten oder des dritten Führungsknotens die automatische Übernahme von Systemprotokollierungsaufgaben für die Rechenknoten in dem Cluster, der dem ausgefallenen Führungsknoten zugeordnet war.
  • In einigen Beispielen, die mit dem vorhergehenden Beispiel kombiniert sein können, ermöglichen die Anweisungen dem ersten Führungsknoten, Systemprotokolldaten von den Rechenknoten im ersten Cluster basierend auf einer Abhörliste im ersten Führungsknoten zu empfangen, und die Abhörliste umfasst eine IP-Adresse, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden.
  • In einigen Beispielen, die mit einem der vorstehenden Beispiele kombiniert sein können, umfasst die IP-Adresse, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten zu senden, eine erste IP-Adresse, und die Anweisungen ermöglichen es dem ersten Führungsknoten, automatisch Systemprotokollierungsaufgaben für den zweiten Cluster zu übernehmen, indem eine zweite IP-Adresse zur Abhörliste im ersten Führungsknoten hinzugefügt wird, wobei die zweite IP-Adresse von Rechenknoten im zweiten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den zweiten Cluster zu senden.
  • In einigen Beispielen, die mit jedem der vorangegangenen Beispiele kombiniert sein können, ermöglichen die Anweisungen dem ersten Führungsknoten außerdem, als Teil eines Initialisierungsprozesses mit anderen Führungsknoten in dem Datenverarbeitungssystem mit mehreren Knoten zusammenzuarbeiten, um die Systemprotokollierungsaufgaben unter den Führungsknoten zu verteilen.
  • In einigen Beispielen, die mit einem der vorstehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem ersten Führungsknoten, Systemprotokolldaten von Rechenknoten basierend auf einer Abhörliste im ersten Führungsknoten zu empfangen. Das Verteilen von Systemprotokollierungsaufgaben unter den Führungsknoten umfasst auch das Hinzufügen einer IP-Adresse zur Abhörliste im ersten Führungsknoten, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden.
  • In einigen Beispielen, die mit jedem der vorangehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem ersten Führungsknoten, nachdem er Systemprotokollierungsaufgaben für den zweiten Cluster übernommen hat, automatisch zu bestimmen, ob der zweite Führungsknoten wiederhergestellt wurde, und als Reaktion auf eine Bestimmung, dass der zweite Führungsknoten wiederhergestellt wurde, automatisch Systemprotokollierungsaufgaben für den zweiten Cluster an den zweiten Führungsknoten abzugeben.
  • In einigen Beispielen, die mit einem der vorstehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem ersten Führungsknoten außerdem, als Konsolenbrücke zu dienen, damit ein Hauptknoten in dem Datenverarbeitungssystem mit mehreren Knoten über den ersten Führungsknoten auf eine Konsole eines Rechenknotens im ersten Cluster zugreifen kann. Die Anweisungen ermöglichen es dem ersten Führungsknoten außerdem, Konsolenprotokolldaten für den Rechenknoten im gemeinsamen Speicher zu speichern.
  • In einigen Beispielen, die mit einem der vorstehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem ersten Führungsknoten außerdem, als Reaktion auf den Ausfall des zweiten Führungsknotens automatisch Konsolenbrückenaufgaben für den zweiten Cluster zu übernehmen.
  • ist ein Blockdiagramm eines Systems 610 mit einer Technologie zur elastischen Protokollierung von Systemprotokolldaten. Das System 610 umfasst einen Prozessor 620, ein computerlesbares Medium 630, das mit dem Prozessor 620 verbunden ist, und Anweisungen 640 in dem computerlesbaren Medium. Wenn sie von Prozessor 620 ausgeführt werden, ermöglichen Anweisungen 640 dem System 610, als erster Führungsknoten eines Mehrknoten-Datenverarbeitungssystems zu dienen, indem es Systemprotokolldaten von mehreren Rechenknoten in einem ersten Cluster des Mehrknoten-Datenverarbeitungssystems empfängt, Speichern der Systemprotokolldaten in einem gemeinsam genutzten Speicher, der auch von einem zweiten Führungsknoten verwendet wird, um Systemprotokolldaten für Rechenknoten in einem zweiten Cluster des Mehrknoten-Datenverarbeitungssystems zu speichern, und von einem dritten Führungsknoten, um Systemprotokolldaten für Rechenknoten in einem dritten Cluster des Mehrknoten-Datenverarbeitungssystems zu speichern, und als Reaktion auf einen Ausfall des zweiten oder des dritten Führungsknotens automatisch Systemprotokollierungsaufgaben für die Rechenknoten in dem Cluster zu übernehmen, der mit dem ausgefallenen Führungsknoten verbunden war.
  • In einigen Beispielen, die mit dem vorherigen Beispiel kombiniert sein können, ermöglichen die Anweisungen dem System, Systemprotokolldaten von den Rechenknoten im ersten Cluster basierend auf einer Abhörliste im System zu empfangen, wobei die Abhörliste eine erste IP-Adresse umfasst, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden, und die Anweisungen das System in die Lage versetzen, automatisch Systemprotokollierungsaufgaben für den zweiten Cluster zu übernehmen, indem eine zweite IP-Adresse zu der Abhörliste in dem System hinzugefügt wird, wobei die zweite IP-Adresse von Rechenknoten in dem zweiten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den zweiten Cluster zu senden.
  • In einigen Beispielen, die mit jedem der vorangehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem System, Systemprotokolldaten von Rechenknoten basierend auf einer Listenliste im System zu empfangen. Außerdem ermöglichen die Anweisungen dem System als Teil eines Initialisierungsprozesses, mit anderen Führungsknoten in dem Datenverarbeitungssystem mit mehreren Knoten zusammenzuarbeiten, um Systemprotokollierungsaufgaben unter den Führungsknoten zu verteilen, wobei das Verteilen von Systemprotokollierungsaufgaben unter den Führungsknoten das Hinzufügen einer IP-Adresse zur Abhörliste im System umfasst, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden.
  • In einigen Beispielen, die mit jedem der vorhergehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem System, nachdem es Systemprotokollierungsaufgaben für den zweiten Cluster übernommen hat, automatisch zu bestimmen, ob der zweite Führungsknoten wiederhergestellt wurde, und als Reaktion auf die Bestimmung, dass der zweite Führungsknoten wiederhergestellt wurde, automatisch Systemprotokollierungsaufgaben für den zweiten Cluster an den zweiten Führungsknoten abzugeben.
  • In einigen Beispielen, die mit einem der vorstehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem System außerdem, als Konsolenbrücke zu dienen, damit ein Hauptknoten in dem Datenverarbeitungssystem mit mehreren Knoten über das System auf eine Konsole eines Rechenknotens in dem ersten Cluster zugreifen kann. Die Anweisungen ermöglichen es dem System außerdem, Konsolenprotokolldaten für den Rechenknoten in dem gemeinsamen Speicher zu speichern.
  • In einigen Beispielen, die mit einem der vorstehenden Beispiele kombiniert sein können, ermöglichen die Anweisungen dem System außerdem, als Reaktion auf den Ausfall des zweiten Leitknotens automatisch Konsolenbrückenaufgaben für den zweiten Cluster zu übernehmen.
  • In einigen Beispielen, die mit jedem der vorangegangenen Beispiele kombiniert sein können, ermöglichen die Anweisungen dem System, einen Verwaltungsprozessor des Rechenknotens zu verwenden, um auf die Konsole des Rechenknotens für den Kopfknoten zuzugreifen.
  • ist ein Flussdiagramm, das ein Verfahren 710 zur Verwaltung von Protokollen in einem Datenverarbeitungssystem mit mehreren Knoten zeigt. Wie in Block 720 gezeigt, umfasst das Verfahren die Verwendung einer Abhörliste in einem ersten Führungsknoten des Mehrknoten-Datenverarbeitungssystems, um an dem ersten Führungsknoten Systemprotokolldaten von mehreren Rechenknoten in einem ersten Cluster des Mehrknoten-Datenverarbeitungssystems zu empfangen, wobei die Abhörliste eine erste IP-Adresse umfasst, die von den Rechenknoten in dem ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden. Wie in Block 730 gezeigt, umfasst das Verfahren auch das Speichern der Systemprotokolldaten in einem gemeinsam genutzten Speicher, der auch von zweiten und dritten Führungsknoten verwendet wird, um Systemprotokolldaten für Rechenknoten in zweiten und dritten Clustern des Mehrknoten-Datenverarbeitungssystems zu speichern. Wie in Block 740 gezeigt, umfasst das Verfahren als Reaktion auf den Ausfall des zweiten Führungsknotens auch die automatische Übernahme der Systemprotokollierungsaufgaben für den zweiten Cluster durch den ersten Führungsknoten, indem eine zweite IP-Adresse zur Listenliste im ersten Führungsknoten hinzugefügt wird. Wie in Block 750 gezeigt, umfasst das Verfahren als Reaktion auf die Wiederherstellung des zweiten Führungsknotens auch die automatische Abgabe von Systemprotokollierungsaufgaben für den zweiten Cluster durch Entfernen der zweiten IP-Adresse aus der Abhörliste im ersten Führungsknoten. Wie in Block 760 gezeigt, umfasst das Verfahren auch, als Reaktion auf den Ausfall des dritten Führungsknotens, die automatische Übernahme der Systemprotokollierungsaufgaben für den dritten Cluster im ersten Führungsknoten.
  • In einigen Beispielen, die mit dem vorhergehenden Beispiel kombiniert sein können, umfasst das Verfahren ferner, dass der erste Führungsknoten als Konsolenbrücke dient, um einem Kopfknoten in dem Datenverarbeitungssystem mit mehreren Knoten zu ermöglichen, über den ersten Führungsknoten auf eine Konsole eines Rechenknotens in dem ersten Cluster zuzugreifen. Und das Verfahren umfasst ferner das Speichern von Konsolenprotokolldaten für den Rechenknoten in dem gemeinsamen Speicher.
  • In einigen Beispielen, die mit jedem der vorstehenden Beispiele kombiniert sein können, umfasst das Verfahren ferner, dass der erste Führungsknoten als Reaktion auf den Ausfall des zweiten Führungsknotens automatisch die Konsolenbrückenaufgaben für den zweiten Cluster übernimmt.
  • In einigen Beispielen, die mit jedem der vorstehenden Beispiele kombiniert sein können, umfasst der Vorgang, als Konsolenbrücke zu dienen, um dem Kopfknoten den Zugriff auf die Konsole des Rechenknotens zu ermöglichen, die Verwendung eines Verwaltungsprozessors des Rechenknotens, um für den Kopfknoten auf die Konsole des Rechenknotens zuzugreifen.
  • In einigen Beispielen, die mit jedem der vorstehenden Beispiele kombiniert sein können, umfasst das Verfahren ferner die Bestimmung am ersten Führungsknoten, ob irgendein anderer Führungsknoten in dem Datenverarbeitungssystem mit mehreren Knoten ausgefallen ist; und als Reaktion auf die Bestimmung, dass irgendein anderer Führungsknoten in dem Datenverarbeitungssystem mit mehreren Knoten ausgefallen ist, die automatische Übernahme von Systemprotokollierungsaufgaben für den ausgefallenen Führungsknoten.
  • Fazit
  • Wie oben beschrieben, enthalten Leader-Knoten in einem System mit mehreren Knoten HA-Manager, die für ein Failover sorgen, indem sie sicherstellen, dass IP-Aliase von ausgefallenen Leader-Knoten auf funktionierende Leader-Knoten verschoben und Dienste neu verteilt werden.
  • Der HA-Manager enthält einen Ereignis-/Benachrichtigungsmechanismus. Dieser Mechanismus wird vom Serververwaltungsprogramm konfiguriert, wenn die Leitknoten erstmalig eingerichtet werden. Dieser Mechanismus wird verwendet, um Komponenten wie den Konsolenmanager zu benachrichtigen, dass Konfigurationsdateien neu berechnet werden müssen, da ein Leader-Knoten jetzt möglicherweise mit einem anderen Satz von Rechenknoten arbeitet als zuvor.
  • Darüber hinaus kann das Mehrknotensystem auch bei Ausfall des Hauptknotens (z. B. durch Ausfall des Hauptknotens, Neustart des Hauptknotens zu Wartungszwecken usw.) weiterarbeiten und eine automatische Ausfallsicherung vorsehen. Alle Rechenknoten können weiterarbeiten, selbst wenn der Hauptknoten verloren geht, selbst wenn ein Führungsknoten verloren geht, und selbst wenn der Hauptknoten und ein Führungsknoten (oder mehrere Führungsknoten) verloren gehen. Die Sicht auf die Rechenknoten vom Hauptknoten aus kann verloren gehen, aber die Aufträge auf den Rechenknoten können weiterhin ausgeführt werden. Wenn z. B. der Hauptknoten ausgefallen ist, schlagen die Konfigurationsvorgänge fehl, die von den Führungsknoten versucht werden, um den Hauptknoten für die Weiterleitung von Konsolenverbindungen zu konfigurieren. Wenn der Hauptknoten jedoch wieder hochfährt, kann er beim Booten ein Skript oder Programm ausführen, das alle Hauptknoten anweist, die CCFCD im Hauptknoten zu aktualisieren, damit sie mit der aktuellen Zuordnung von Hauptknoten zu Rechenknoten für die Konsolenverwaltung übereinstimmt. Während des Ausfalls des Hauptknotens wären keine Konsolenprotokolle verloren gegangen, da sie von den Führungsknoten auch während des Ausfalls des Hauptknotens weiterhin in den gemeinsamen Speicher geschrieben wurden.
  • Ein Hauptknoten kann ein Serververwaltungsprogramm verwenden, um die Leader-Knoten und die Rechenknoten anfänglich einzurichten. Der Hauptknoten kann das Serververwaltungsprogramm auch verwenden, um die Konfiguration als Reaktion auf Änderungen in der Zusammensetzung des Mehrknotensystems anzupassen (z. B. wenn sich der Zustand des Systems ändert, z. B. wenn Geräte von einem Systemadministrator hinzugefügt oder entfernt werden). Sobald die Initialisierung abgeschlossen ist, kann das Mehrknotensystem jedoch auch ohne den Hauptknoten laufen, und die Hauptknoten können zusammenarbeiten, um den Zustand der Hauptknoten zu verfolgen und sich bei Bedarf an Ausfälle anzupassen.
  • Wie oben erwähnt, kann ein Gerät einen Prozessor sowie Anweisungen und andere Daten enthalten, die, wenn der Prozessor darauf zugreift, das Gerät veranlassen oder befähigen, bestimmte Operationen durchzuführen. Für die Zwecke dieser Offenlegung können Anweisungen, die ein Gerät veranlassen oder befähigen, Operationen durchzuführen, allgemein als „Software“ bezeichnet werden. Software kann auch als „Steuerlogik“ bezeichnet werden. Software, die während eines Bootvorgangs verwendet wird, kann als „Firmware“ bezeichnet werden. Software, die in einem nichtflüchtigen Speicher gespeichert ist, kann ebenfalls als „Firmware“ bezeichnet werden. Software kann mit jeder geeigneten Struktur oder Kombination von Strukturen organisiert werden. Dementsprechend können Begriffe wie „Programm“ allgemein verwendet werden, um ein breites Spektrum von Softwarekonstrukten abzudecken, einschließlich und ohne Einschränkung Anwendungsprogramme, Unterprogramme, Routinen, Funktionen, Prozeduren, Treiber, Bibliotheken, Prozesse, Mikrocode und andere Arten von Softwarekomponenten. Es sollte auch verstanden werden, dass ein Softwaremodul (z. B. ein Programm) mehr als eine Komponente enthalten kann, und diese Komponenten können zusammenarbeiten, um die Operationen des Moduls zu vervollständigen. Außerdem können die Operationen, die die Software ein Gerät ausführen lässt, das Erstellen eines Betriebskontexts, das Instanziieren einer bestimmten Datenstruktur usw. umfassen. Eine Beispielimplementierung kann Software zur Ausführung auf einem programmierbaren System umfassen, das einen Prozessor umfasst, der mit einem Speichergerät gekoppelt ist, das die Software enthält.
  • Während die vorliegende Offenbarung in Bezug auf eine begrenzte Anzahl von Implementierungen oder Beispielen beschrieben wurde, wird der Fachmann, der die Vorteile dieser Offenbarung kennt, zahlreiche Modifikationen und Variationen davon erkennen. Es ist beabsichtigt, dass die beigefügten Ansprüche alle derartigen Modifikationen und Variationen abdecken.

Claims (20)

  1. Nicht-transitorisches computerlesbares Medium, das Befehle enthält, die bei Ausführung durch einen Knoten in einem Mehrknoten-Datenverarbeitungssystem den Knoten in die Lage versetzen, als ein erster Führungsknoten zu dienen, indem: Empfang von Systemprotokolldaten von mehreren Rechenknoten in einem ersten Cluster des Mehrknoten-Datenverarbeitungssystems; Speichern der Systemprotokolldaten in einem gemeinsamen Speicher, der auch von einem zweiten Führungsknoten zum Speichern von Systemprotokolldaten für Rechenknoten in einem zweiten Cluster des Mehrknoten-Datenverarbeitungssystems und von einem dritten Führungsknoten zum Speichern von Systemprotokolldaten für Rechenknoten in einem dritten Cluster des Mehrknoten-Datenverarbeitungssystems verwendet wird; und als Reaktion auf den Ausfall eines der zweiten und dritten Leitknoten automatisch die Systemprotokollierungsaufgaben für die Rechenknoten in dem Cluster übernimmt, der mit dem ausgefallenen Leitknoten verbunden war.
  2. Nicht-transitorisches computerlesbares Medium nach Anspruch 1, wobei: die Anweisungen den ersten Führungsknoten in die Lage versetzen, Systemprotokolldaten von den Rechenknoten in dem ersten Cluster basierend auf einer Listenliste in dem ersten Führungsknoten zu empfangen; und die Listenliste eine Internetprotokoll (IP)-Adresse umfasst, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden.
  3. Nicht-transitorisches computerlesbares Medium nach Anspruch 2, wobei: die IP-Adresse, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten zu senden, eine erste IP-Adresse umfasst; und die Anweisungen den ersten Führungsknoten in die Lage versetzen, automatisch Systemprotokollierungsaufgaben für den zweiten Cluster zu übernehmen, indem eine zweite IP-Adresse zu der Listenliste in dem ersten Führungsknoten hinzugefügt wird, wobei die zweite IP-Adresse von Rechenknoten in dem zweiten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den zweiten Cluster zu senden.
  4. Nicht-transitorisches computerlesbares Medium nach Anspruch 1, wobei die Anweisungen den ersten Führungsknoten ferner in die Lage versetzen, als Teil eines Initialisierungsprozesses mit anderen Führungsknoten in dem Mehrknoten-Datenverarbeitungssystem zusammenzuarbeiten, um Systemprotokollierungsaufgaben unter den Führungsknoten zu verteilen.
  5. Nicht-transitorisches computerlesbares Medium nach Anspruch 4, wobei: die Anweisungen den ersten Führungsknoten in die Lage versetzen, Systemprotokolldaten von Rechenknoten basierend auf einer Listenliste im ersten Führungsknoten zu empfangen; und Systemprotokollierungsaufgaben unter den Führungsknoten zu verteilen, umfasst das Hinzufügen einer Internetprotokoll-(IP)-Adresse, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden, zur Abhörliste im ersten Führungsknoten.
  6. Nicht-transitorisches computerlesbares Medium nach Anspruch 1, wobei die Anweisungen den ersten Leader-Knoten in die Lage versetzen, nachdem er die Systemprotokollierungsaufgaben für den zweiten Cluster übernommen hat, zu: automatisch feststellen, ob der zweite Führungsknoten wiederhergestellt wurde; und als Reaktion auf die Feststellung, dass der zweite Führungsknoten wiederhergestellt wurde, automatisch die Systemprotokollierungsaufgaben für den zweiten Cluster an den zweiten Führungsknoten abgeben.
  7. Nicht-transitorisches computerlesbares Medium nach Anspruch 1, wobei die Anweisungen den ersten Leader-Knoten ferner in die Lage versetzen,: als Konsolenbrücke dienen, um einem Kopfknoten in dem Datenverarbeitungssystem mit mehreren Knoten den Zugriff auf eine Konsole eines Rechenknotens in dem ersten Cluster über den ersten Führungsknoten zu ermöglichen; und Konsolenprotokolldaten für den Rechenknoten im gemeinsamen Speicher speichern.
  8. Nicht-transitorisches computerlesbares Medium nach Anspruch 7, wobei die Anweisungen ferner den ersten Leader-Knoten in die Lage versetzen, als Reaktion auf einen Ausfall des zweiten Leader-Knotens automatisch Konsolenbrückenaufgaben für den zweiten Cluster zu übernehmen.
  9. System, das Folgendes umfasst: einen Prozessor; ein computerlesbares Medium, das mit dem Prozessor verbunden ist; und Anweisungen in dem computerlesbaren Medium, die, wenn sie vom Prozessor ausgeführt werden, das System in die Lage versetzen, als erster Führungsknoten eines Datenverarbeitungssystems mit mehreren Knoten zu dienen, indem: Empfang von Systemprotokolldaten von mehreren Rechenknoten in einem ersten Cluster des Mehrknoten-Datenverarbeitungssystems; Speichern der Systemprotokolldaten in einem gemeinsamen Speicher, der auch von einem zweiten Führungsknoten zum Speichern von Systemprotokolldaten für Rechenknoten in einem zweiten Cluster des Mehrknoten-Datenverarbeitungssystems und von einem dritten Führungsknoten zum Speichern von Systemprotokolldaten für Rechenknoten in einem dritten Cluster des Mehrknoten-Datenverarbeitungssystems verwendet wird; und als Reaktion auf den Ausfall eines der zweiten und dritten Leitknoten automatisch die Systemprotokollierungsaufgaben für die Rechenknoten in dem Cluster übernimmt, der mit dem ausgefallenen Leitknoten verbunden war.
  10. System nach Anspruch 9, wobei: die Anweisungen ermöglichen es dem System, Systemprotokolldaten von den Rechenknoten im ersten Cluster basierend auf einer Listenliste im System zu empfangen; die Listenliste eine erste Internetprotokoll (IP)-Adresse umfasst, die von Rechenknoten im ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden; und die Anweisungen das System in die Lage versetzen, automatisch Systemprotokollierungsaufgaben für den zweiten Cluster zu übernehmen, indem eine zweite IP-Adresse zur Listen-Liste im System hinzugefügt wird, wobei die zweite IP-Adresse von Rechenknoten im zweiten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den zweiten Cluster zu senden.
  11. System nach Anspruch 9, wobei: die Anweisungen das System in die Lage versetzen, Systemprotokolldaten von Rechenknoten basierend auf einer Listenliste im System zu empfangen; und die Anweisungen das System ferner in die Lage versetzen, als Teil eines Initialisierungsprozesses mit anderen Führungsknoten in dem Mehrknoten-Datenverarbeitungssystem zusammenzuarbeiten, um Systemprotokollierungsaufgaben unter den Führungsknoten zu verteilen, wobei das Verteilen von Systemprotokollierungsaufgaben unter den Führungsknoten das Hinzufügen einer Internetprotokoll (IP)-Adresse zu der Abhörliste in dem System umfasst, die von Rechenknoten in dem ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden.
  12. System nach Anspruch 9, wobei die Anweisungen das System befähigen, nach der Übernahme von Systemprotokollierungsaufgaben für den zweiten Cluster, zu: automatisch feststellen, ob der zweite Führungsknoten wiederhergestellt wurde; und als Reaktion auf die Feststellung, dass der zweite Führungsknoten wiederhergestellt wurde, automatisch die Systemprotokollierungsaufgaben für den zweiten Cluster an den zweiten Führungsknoten abgeben.
  13. System nach Anspruch 9, wobei die Befehle das System außerdem in die Lage versetzen: als Konsolenbrücke dienen, um einem Kopfknoten in dem Mehrknoten-Datenverarbeitungssystem zu ermöglichen, über das System auf eine Konsole eines Rechenknotens in dem ersten Cluster zuzugreifen; und Konsolenprotokolldaten für den Rechenknoten im gemeinsamen Speicher speichern.
  14. System nach Anspruch 13, wobei die Anweisungen das System ferner in die Lage versetzen, als Reaktion auf den Ausfall des zweiten Leitknotens automatisch Konsolenbrückenaufgaben für den zweiten Cluster zu übernehmen.
  15. System nach Anspruch 13, wobei die Anweisungen das System in die Lage versetzen, einen Verwaltungsprozessor des Rechenknotens zu verwenden, um auf die Konsole des Rechenknotens für den Kopfknoten zuzugreifen.
  16. Verfahren zum Verwalten von Protokollen für ein Datenverarbeitungssystem mit mehreren Knoten, wobei das Verfahren Folgendes umfasst: Verwenden einer Abhörliste in einem ersten Führungsknoten des Mehrknoten-Datenverarbeitungssystems, um an dem ersten Führungsknoten Systemprotokolldaten von mehreren Rechenknoten in einem ersten Cluster des Mehrknoten-Datenverarbeitungssystems zu empfangen, wobei die Abhörliste eine erste Internetprotokoll (IP)-Adresse umfasst, die von den Rechenknoten in dem ersten Cluster verwendet werden soll, um Systemprotokolldaten an einen aktuellen Führungsknoten für den ersten Cluster zu senden; Speichern der Systemprotokolldaten in einem gemeinsam genutzten Speicher, der auch von zweiten und dritten Leitknoten verwendet wird, um Systemprotokolldaten für Rechenknoten in zweiten und dritten Clustern des Mehrknoten-Datenverarbeitungssystems zu speichern; als Reaktion auf den Ausfall des zweiten Führungsknotens, automatische Übernahme der Systemprotokollierungsaufgaben für den zweiten Cluster am ersten Führungsknoten durch Hinzufügen einer zweiten IP-Adresse zur Listenliste im ersten Führungsknoten; als Reaktion auf die Wiederherstellung des zweiten Führungsknotens, automatisches Aufgeben der Systemprotokollierungsaufgaben für den zweiten Cluster durch Entfernen der zweiten IP-Adresse aus der Listenliste im ersten Führungsknoten; und als Reaktion auf den Ausfall des dritten Leitknotens, automatische Übernahme der Systemprotokollierungsaufgaben für den dritten Cluster am ersten Leitknoten.
  17. Verfahren nach Anspruch 16, ferner umfassend: am ersten Führungsknoten, der als Konsolenbrücke dient, um einem Kopfknoten in dem Mehrknoten-Datenverarbeitungssystem den Zugriff auf eine Konsole eines Rechenknotens in dem ersten Cluster über den ersten Führungsknoten zu ermöglichen; und Speichern von Konsolenprotokolldaten für den Rechenknoten im gemeinsamen Speicher.
  18. Verfahren nach Anspruch 17, ferner umfassend: am ersten Leitknoten, der automatisch die Konsolenbrückenaufgaben für den zweiten Cluster übernimmt, als Reaktion auf den Ausfall des zweiten Leitknotens.
  19. Verfahren nach Anspruch 18, wobei der Vorgang, als Konsolenbrücke zu dienen, um dem Kopfknoten den Zugriff auf die Konsole des Rechenknotens zu ermöglichen, umfasst: Verwendung eines Verwaltungsprozessors des Rechenknotens, um auf die Konsole des Rechenknotens für den Kopfknoten zuzugreifen.
  20. Verfahren nach Anspruch 16, ferner umfassend: Bestimmen, am ersten Führungsknoten, ob irgendein anderer Führungsknoten in dem Mehrknoten-Datenverarbeitungssystem ausgefallen ist; und als Reaktion auf die Feststellung, dass ein beliebiger anderer Führungsknoten in dem Datenverarbeitungssystem mit mehreren Knoten ausgefallen ist, automatisch die Systemprotokollierungsaufgaben für den ausgefallenen Führungsknoten übernimmt.
DE102021107655.2A 2020-06-02 2021-03-26 Protokollverwaltung für ein mehrknotendatenverarbeitungssystem Pending DE102021107655A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/889,898 US11119872B1 (en) 2020-06-02 2020-06-02 Log management for a multi-node data processing system
US16/889898 2020-06-02

Publications (1)

Publication Number Publication Date
DE102021107655A1 true DE102021107655A1 (de) 2021-12-02

Family

ID=77665641

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102021107655.2A Pending DE102021107655A1 (de) 2020-06-02 2021-03-26 Protokollverwaltung für ein mehrknotendatenverarbeitungssystem

Country Status (3)

Country Link
US (1) US11119872B1 (de)
CN (1) CN113765697B (de)
DE (1) DE102021107655A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7133000B2 (ja) * 2020-12-17 2022-09-07 エヌ・ティ・ティ・アドバンステクノロジ株式会社 シナリオ実行システム、ログ管理装置、ログ記録方法及びプログラム
US11818021B2 (en) * 2022-01-13 2023-11-14 Dell Products L.P. Resilient consensus-based control plane

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040153558A1 (en) * 2002-10-31 2004-08-05 Mesut Gunduc System and method for providing java based high availability clustering framework
US20050283658A1 (en) * 2004-05-21 2005-12-22 Clark Thomas K Method, apparatus and program storage device for providing failover for high availability in an N-way shared-nothing cluster system
US7721152B1 (en) * 2004-12-21 2010-05-18 Symantec Operating Corporation Integration of cluster information with root cause analysis tool
US7653682B2 (en) * 2005-07-22 2010-01-26 Netapp, Inc. Client failure fencing mechanism for fencing network file system data in a host-cluster environment
US7890626B1 (en) 2008-09-11 2011-02-15 Gadir Omar M A High availability cluster server for enterprise data management
US8327186B2 (en) * 2009-03-10 2012-12-04 Netapp, Inc. Takeover of a failed node of a cluster storage system on a per aggregate basis
US8145838B1 (en) * 2009-03-10 2012-03-27 Netapp, Inc. Processing and distributing write logs of nodes of a cluster storage system
US9288177B2 (en) 2011-12-14 2016-03-15 International Business Machines Corporation Inventory updating of an internet protocol (IP) alias within a highly available computing cluster
JP2014081811A (ja) 2012-10-17 2014-05-08 Hitachi Solutions Ltd ログ管理システム、および、ログ管理方法
US10069677B2 (en) * 2013-04-06 2018-09-04 Citrix Systems, Inc. Systems and methods to collect logs from multiple nodes in a cluster of load balancers
US10013318B2 (en) * 2013-04-16 2018-07-03 Entit Software Llc Distributed event correlation system
US9251017B2 (en) * 2014-03-25 2016-02-02 International Business Machines Corporation Handling failed cluster members when replicating a database between clusters
US10177994B2 (en) * 2014-08-13 2019-01-08 Microsoft Technology Licensing, Llc Fault tolerant federation of computing clusters
US9807154B2 (en) * 2014-09-26 2017-10-31 Lenovo Enterprise Solutions (Singapore) Pte, Ltd. Scalable logging control for distributed network devices
US20170220431A1 (en) * 2016-02-01 2017-08-03 International Business Machines Corporation Failover of a database in a high-availability cluster
US10783046B2 (en) * 2016-11-22 2020-09-22 Nutanix, Inc. Executing resource management operations in distributed computing systems
US11347774B2 (en) * 2017-08-01 2022-05-31 Salesforce.Com, Inc. High availability database through distributed store
CN109729129B (zh) * 2017-10-31 2021-10-26 华为技术有限公司 存储集群系统的配置修改方法、存储集群及计算机系统
CN108108466A (zh) * 2017-12-29 2018-06-01 咪咕文化科技有限公司 一种分布式系统日志查询分析方法及装置

Also Published As

Publication number Publication date
CN113765697A (zh) 2021-12-07
CN113765697B (zh) 2022-10-28
US11119872B1 (en) 2021-09-14

Similar Documents

Publication Publication Date Title
JP6514308B2 (ja) 複製されたデータインスタンスのためのフェイルオーバーおよび復旧
DE60224274T2 (de) Wiederherstellungsrechner für eine mehrzahl von vernetzten rechnern
DE602004008028T2 (de) Verfahren zum dynamischen Transferieren zwischen Servern für virtuelle Dateiserver
DE102012210914B4 (de) Switch-Fabric-Management
DE69021122T2 (de) Verfahren und Gerät zur ununterbrochenen Versorgung von Anwendungen in einem Rechnernetzwerk.
DE602004002858T2 (de) Vorrichtung und Verfahren zur Datenarchivierung in einem Clustersystem
DE102004052270B4 (de) Verarbeitungsvorrichtungs-Managementsystem
DE60106467T2 (de) Verfahren zum Installieren Überwachungsagenten, System und Computerprogramm von Objekten in einem IT-Netz Überwachung
US7441024B2 (en) Method and apparatus for applying policies
US8200746B2 (en) System and method for territory-based processing of information
DE60205539T2 (de) Verfahren und Vorrichtung zum Verwalten von mehreren Netzwerkgeräten
DE10014448B4 (de) Speicherverwaltungssystem
DE112011103666B4 (de) Speicherverwaltung in Cluster-Datenverarbeitungssystemen
DE10124482B4 (de) Fehlertolerante Systemressource mit niedriger Latenzzeit, mit übergeordneter Protokollierung von Systemressourcentransaktionen und serverübergreifend gespiegelter Protokollierung von übergeordneten Systemressourcentransaktionen
DE102004027672A1 (de) Speicherplattenarraysystem
JP2008517358A (ja) ストレージ管理を容易にするための装置、システム、および方法
DE112006002531T5 (de) Anwendung virtueller Server für Lösungen mit hoher Verfügbarkeit und für Lösungen bei der Wiederherstellung nach Fehlern
DE60313468T2 (de) Speicherdienste und -systeme
DE19836347A1 (de) Fehlertolerantes Computersystem
DE102021107655A1 (de) Protokollverwaltung für ein mehrknotendatenverarbeitungssystem
DE102015015196A1 (de) Verwaltungssystem und Steuerungsverfahren für Verwaltungssystem
DE69927223T2 (de) Ausfallsicherheit eines Mehrrechnersystems
DE102022108458A1 (de) Disaggregierter speicher mit mehreren clusterebenen
DE112021001517T5 (de) Abschirmen von nicht reagierenden anschlüssen in einer netzwerkstruktur
DE102022108867A1 (de) Verfahren und system zum einsatz eines produktionssystems in einer virtualisierten umgebung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TX, US

R082 Change of representative

Representative=s name: HL KEMPNER PATENTANWALT, RECHTSANWALT, SOLICIT, DE

Representative=s name: HL KEMPNER PATENTANWAELTE, SOLICITORS (ENGLAND, DE