DE60201077T2

DE60201077T2 - Verfahren um einen Computer aus einem Cluster zu entfernen

Info

Publication number: DE60201077T2
Application number: DE60201077T
Authority: DE
Inventors: Joseph W. Armstrong
Original assignee: Fujitsu Siemens Computers Inc
Current assignee: Fujitsu Siemens Computers Inc
Priority date: 2002-06-13
Filing date: 2002-06-13
Publication date: 2005-09-15
Anticipated expiration: 2022-06-14
Also published as: ATE274721T1; DE60201077D1; EP1372075A1; EP1372075B1; US20030233597A1

Description

Die Erfindung betrifft ein Verfahren zum Eliminieren eines Computers aus einem Cluster zweier oder mehrerer Computer, um Datenintegrität und Anwendungswiederherstellung auf einem anderen Computer zu garantieren.
Das nachfolgend beschriebene Verfahren ist aus dem deutschen Patent DE 198 37 008 C2 bekannt. Ein Cluster besteht normalerweise aus einem Cluster-Host und Cluster-Knoten. Die Cluster-Knoten werden durch eine als Cluster-Foundation bezeichnete Software verwaltet, die auf dem Cluster-Host installiert ist. Die Cluster-Foundation liefert die grundlegenden zentralen Dienste. Zu diesen Diensten gehört zum Beispiel Lebenszeichenüberwachung zwischen Cluster-Knoten. Zusätzlich zu diesen Diensten können abhängig von dem Anwendungsgebiet Dienste wie zum Beispiel ein Failover-Manager für hohe Verfügbarkeit und Dienste für parallele Datenbanken hinzugefügt werden. Durch Dienste für dynamischen Lastausgleich wird der Weg für Internet-Anwendungsgebiete, wie zum Beispiel E-Commerce und Anwendungs-Hosting, geöffnet. Die Grundlage für fast alle Hochverfügbarkeitslösungen ist ein leistungsstarker und flexibler Failover-Manager im Hintergrund. Im Fall des Primärclusters des Anmelders wird der Failover-Manager als Reliant Monitor Software (RMS) bezeichnet. RMS ist eine generische Überwacherbeobachtung von Knoten in einem Cluster und für die Failover-Steuerung der Anwendungen.
Für die Lebenszeichenüberwachung zwischen den Cluster-Knoten muß erkannt werden, ob ein echter Ausfall einer der Cluster-Knoten besteht oder ob ein Problem bei der Kommunikation zwischen den geclusterten Knoten besteht. Wenn ein Problem bei der Kommunikation zwischen dem Cluster-Knoten besteht, muß sein Ort gefunden werden, und es muß entschieden werden, welcher der Computer heruntergefahren werden muß.
Die RMS hat als der Failover-Manager Zugang zu allen Computern in dem Cluster und zu allen Verbindungen zwischen den Computern in dem Cluster. Die Single Console (SCON) hat die Fähigkeit, jeden Computer in dem Cluster anzuhalten oder herunterzufahren oder neu zu starten. Alle RMS-Instanzen in dem Cluster senden eine Nachricht zu dem SCON, wenn eine Lebenszeichennachricht eines anderen Computers in dem Cluster fehlt. Mit einer fehlenden Lebenszeichennachricht eines Computers in dem Cluster kann die Datenintegrität nicht garantiert werden, so daß dieser Computer aus dem Cluster eliminiert werden muß. Deshalb wird die Nachricht von der RMS zu der SCON als eine Herunterfahranforderung oder eine Kill-Anforderung bezeichnet. Wenn n Computer mit einem Cluster verbunden sind und ein Knoten oder Computer keine Lebenszeichennachricht sendet, empfängt die SCON n – 1 Herunterfahranforderungen. Bei diesem existierenden System sammelt und bewertet die SCON die Herunterfahranforderungen und eliminiert die defekte Maschine bzw. den defekten Computer aus dem Cluster.
Das Problem besteht darin, daß mit der existierenden Technologie die SCON ein einziger Ausfallpunkt für die Knoteneliminationsverarbeitung ist, keine redundanten Herunterfahrmethoden unterstützt werden, keine Interaktion mit der Cluster Foundation unterstützt wird, die Existenz eines Failover-Managers erforderlich ist und daß die SCON zusätzliche Kosten für einen Kunden einführt, da er eine zusätzliche Maschine anschaffen muß, auf der die SCON-Software abläuft.
Aus EP1117039A ist eine Cluster-Herunterfahrsteuerung bekannt, die Teil eines auf jedem Knoten in einem Cluster installierten Integritätsschutzsoftwarepakets ist. Die Herunterfahrsteuerung leitet ein Herunterfahren jedes Knotens in einem gegebenen Subcluster ein, wenn es notwendig ist (z. B. im Fall eines Problems des Typs "Split Brain").
Die Aufgabe der Erfindung ist deshalb die Bereitstellung einer Knoteneliminationseinrichtung, die in Clustern mit oder ohne Failover-Manager und mit oder ohne Cluster Foundation verfügbar ist. Die Knoteneliminationseinrichtung läuft auf jedem Knoten in dem Cluster ab, so daß sie keinen einzigen Ausfallpunkt für die Knoteneliminationsverarbeitung darstellt. Die Einrichtung unterstützt außerdem redundante Knoteneliminationsverfahren, um die Wahrscheinlichkeit einer erfolgreichen Knotenelimination zu vergrößern. Schließlich erfordert die Einrichtung nicht die Anschaffung einer zusätzlichen Maschine, auf der ihre Software abläuft, wodurch die Kosten des Clusters für den Kunden reduziert werden.
Diese Aufgabe wird gemäß der Erfindung, die durch die Ansprüche definiert wird, mit einer Anzahl unabhängiger Herunterfahragenten gelöst, die in einer Herunterfahreinrichtung registriert sind, die auf jedem Computer in dem Cluster installiert ist.
Die Herunterfahreinrichtung liefert einen allgemeinen Rahmen zum Aufrufen redundanter, unabhängiger Herunterfahrmethoden für diesen Zweck. Die Herunterfahrmethoden werden durch die Herunterfahragenten implementiert. Wenn eine Herunterfahranforderung verarbeitet wird, hat die Herunterfahreinrichtung die Möglichkeit, falls notwendig durch die Liste registrierter Herunterfahragenten zu iterieren und kann deshalb eine höhere Wahrscheinlichkeit einer erfolgreichen Hostelimination bereitstellen.
Die Herunterfahreinrichtung und die Herunterfahragenten sind außerdem auf dem Cluster-Host mit dem Failover-Manager (falls einer existiert) installiert.
Die Herunterfahreinrichtung verfolgt den Status jedes Herunterfahragenten, so daß ein Bediener benachrichtigt werden kann, wenn ein Herunterfahragent unverfügbar wird.
Die Erfindung liefert eine Liste von Herunterfahragenten in einer Konfigurationsdatei, die eine geordnete Liste der Herunterfahragenten definiert, dergestalt, daß der erste Herunterfahragent in der Liste ein bevorzugter Herunterfahragent ist, dem zuerst die Herunterfahranforderung ausgegeben wird, und wenn seine Antwort ein erfolgloses Herunterfahren anzeigt, wird der nächste Herunterfahragent ausgegeben, bis entweder ein Herunterfahragent mit einem erfolgreichen Herunterfahren antwortet oder alle Herunterfahragenten versucht wurden.
Ein Ausführungsbeispiel der Erfindung wird nachfolgend ausführlicher mit Bezug auf eine Zeichnung erläutert.
Die Figur zeigt schematisch ein Cluster aus vier Computern oder Servern (die als Cluster-Knoten bezeichnet werden), die durch einen Failover-Manager verwaltet werden, der zum Beispiel der existierende RMS-Failover-Manager sein könnte. Der Failover-Manager ist optional und für die Erfindung nicht notwendig.
Jeder Computer gibt dem Failover-Manager und allen anderen Computern in dem Cluster eine Lebenszeichennachricht. Falls eine Lebenszeichennachricht fehlt, muß der Computer mit der fehlenden Lebenszeichennachricht eliminiert werden. Zu diesem Zweck ist auf jedem Computer eine Herunterfahreinrichtung SF installiert. Die Herunterfahreinrichtung umfaßt einen Herunterfahr-Daemon SD und mehrere Herunterfahragenten SA. Jeder Herunterfahragent ist ein Programm, in dem eine Herunterfahrmethode implementiert ist.
Die Herunterfahragenten der Herunterfahreinrichtung sind unabhängige Befehle, die durch die Herunterfahr- Daemons oder durch die SCON abgerufen werden können.
Der Herunterfahr-Daemon wird entweder durch eine Befehlszeilenanforderung, eine Cluster-Maschine herunterzufahren, von dem Bediener oder ein als ENS bezeichnetes Ereignis aus der Cluster Foundation ausgelöst.
Die Herunterfahranforderung wird erfüllt, indem ein oder mehrere Herunterfahragenten, die in der Herunterfahr-Daemon-Konfigurationsdatei definiert sind, aufgerufen werden. Nachdem das Herunterfahren verifiziert wurde, transferiert der Herunterfahr-Daemon den Knotenzustand zu Knoten-heruntergefahren, wenn ein Failover-Manager oder eine Cluster Foundation CF installiert ist und läuft.
Wenn kein Failover-Manager oder keine Cluster Foundation installiert sind und laufen, reagiert der Shutdown-Daemon nur auf die Befehlszeilenanforderung des Bedieners.
Wenn die Cluster Foundation installiert und auf dem Cluster-Host konfiguriert ist, registriert sich der Herunterfahr-Daemon bei ENS, um folgendes zu empfangen:

– NODE_AVAILABLE
– LEAVINGCLUSTER
– LEFTCLUSTER
– NODE_DOWN

Diese Ereignisse sind die existierenden Ereignisse, die von der Cluster Foundation erzeugt werden.
Der Herunterfahr-Daemon verfolgt den Zustand der Cluster-Knoten, so daß bestimmt werden kann, wann ein Computer eliminiert werden muß.
Der Herunterfahr-Daemon weist eine Konfigurationsdatei auf, die eine geordnete Liste von Herunterfahragenten definiert, dergestalt, daß der erste Herunterfahragent in der Liste ein bevorzugter Herunterfahragent ist. Diesem bevorzugten Herunterfahragenten wird eine Herunterfahranforderung ausgegeben, und wenn seine Antwort ein erfolgloses Herunterfahren anzeigt, wird die Herunterfahranforderung dem zweiten Herunterfahragenten ausgegeben. Diese Anforderung/Antwort wird wiederholt, bis entweder ein Herunterfahragent mit einem erfolgreichen Herunterfahren antwortet oder alle Herunterfahragenten versucht wurden. Wenn kein Herunterfahragent erfolgreich einen Cluster-Knoten herunterfahren kann, dann ist ein Eingriff durch den Bediener erforderlich und der Knoten wird in dem Zustand left Cluster gelassen.
Jegliche Konfigurationsinformationen, die der Herunterfahragent benötigt, müssen durch den Verfasser des Herunterfahragenten definiert und in einer unabhängigen Konfigurationsdatei konfiguriert werden. Die Herunterfahragenten sind so ausgelegt, daß sie unabhängige Prozesse sind. Die erforderliche Betriebsumgebung eines Herunterfahragenten besteht darin, daß

a. Installationsanforderungen befolgt werden müssen,
b. die erforderlichen Befehlszeilenoptionen unterstützt sein müssen und
c. die erforderliche Laufzeitaktion durchgeführt werden muß.

Wenn ein neuer Herunterfahragent entwickelt wird, müssen der Herunterfahr-Daemon und die "SCON", falls eine existiert, nicht umqualifiziert werden, nur der neue Herunterfahragent muß qualifiziert werden.
Die Vorteile der Herunterfahreinrichtung SF gegenüber existierenden RMS/SCON-Systemen sind die folgenden:

a. Möglichkeit, einen Cluster-Knoten mit oder ohne Betrieb eines Failover-Managers (RMS) herunterzufahren.
b. Möglichkeit, einen Cluster-Knoten mit oder ohne Betrieb einer SCON herunterzufahren.
c. Möglichkeit, einen Cluster-Knoten von einem beliebigen Produkt der Cluster-Service-Schicht aus herunterzufahren.
d. Das existierende Failover-Manager-System (RMS und SCON) ist auf allen Clustern, ungeachtet der Anzahl von Knoten und der Plattformmischung optional.
e. Auf Clustern mit SCON sind redundante Herunterfahrmethoden verfügbar, weil die SCON ihre existierende Methode sowie die in den Herunterfahragenten implementierten Methoden verwendet.
f. Auf Clustern ohne SCON sind redundante Herunterfahrmethoden verfügbar, weil mehrere Herunterfahragenten verfügbar sind und jeder Herunterfahragent eine Herunterfahrmethode implementiert.
g. Schnellere Qualifikationszyklen bei der Einführung eines neuen Herunterfahragenten, weil der Herunterfahr-Daemon und der Failover-Manager (RMS/SCON), falls einer existiert, nicht umqualifiziert werden müssen.
h. Aktive Überwachung konfigurierter Herunterfahragenten, so daß ein Bediener über einen Ausfall benachrichtigt werden kann, bevor dieser Agent benutzt werden muß.

Claims

Verfahren zum Eliminieren eines Computers aus einem Cluster mit zwei oder mehr Computern, um Datenintegrität und Anwendungswiederherstellung auf einem anderen Computer zu garantieren, wobei auf allen Computern in dem Cluster eine Herunterfahreinrichtung installiert ist, dadurch gekennzeichnet, daß eine Vielzahl unabhängiger Herunterfahragenten bei der Herunterfahreinrichtung registriert sind und daß die Herunterfahragenten auf allen Computern in dem Cluster installiert sind.
Verfahren nach Anspruch 1, wobei die Herunterfahreinrichtung und die Herunterfahragenten auch auf einer Single Console (SCON) installiert sind, wenn eine existiert.
Verfahren nach Anspruch 1 oder 2, wobei die Herunterfahreinrichtung einen Herunterfahr-Daemon umfaßt.
Verfahren nach Anspruch 3, wobei die Herunterfahragenten unabhängige Befehle sind, die durch den Herunterfahr-Daemon oder SCON, falls ein solcher bzw. eine solche existiert, aufgerufen werden können.
Verfahren nach einem der Ansprüche 3 oder 4, wobei der Herunterfahr-Daemon durch eine Befehlszeilenanforderung oder ein Ereignis der Cluster Foundation, falls eine existiert, ausgelöst wird.
Verfahren nach einem der Ansprüche 3 bis 5, wobei eine Herunterfahranforderung durch Aufrufen eines oder mehrerer in einer Konfigurationsdatei des Herunterfahr-Daemon definierter Herunterfahragenten erfüllt wird.
Verfahren nach Anspruch 6, wobei die Konfigurationsdatei eine geordnete Liste von Herunterfahragenten definiert, dergestalt, daß der erste Herunterfahragent in der Liste ein bevorzugter Herunterfahragent ist, der zuerst ausgegeben wird, wenn eine Herunterfahranforderung verarbeitet wird, und wenn seine Antwort ein erfolgloses Herunterfahren anzeigt, der nächste Herunterfahragent ausgegeben wird, bis entweder ein Herunterfahragent mit einem erfolgreichen Herunterfahren antwortet oder alle Herunterfahragenten ersucht wurden.
Verfahren nach Anspruch 3, wobei der Herunterfahr-Daemon den Status jedes Herunterfahragenten verfolgt, so daß ein Bediener benachrichtigt werden kann, wenn ein Herunterfahragent unverfügbar wird.