Entwerfen des Fehler-Monitor-Dämons

Ressourcentypimplementierungen, welche die DSDL verwenden, verfügen in der Regel über einen Fehler-Monitor-Dämon mit folgenden Aufgaben:

• Periodische Überwachung der Fehlerfreiheit der verwalteten Anwendung. Dieser besondere Aspekt eines Monitor-Dämons hängt stark von der jeweiligen Anwendung ab und kann bei den einzelnen Ressourcentypen erhebliche Unterschiede aufweisen. Die DSDL verfügt über einige integrierte Dienstprogrammfunktionen, um Gesundheits-Checks für einfache, TCP-basierte Dienste auszuführen. Anwendungen mit ASCII-basierten Protokollen wie HTTP, NNTP, IMAP und POP3 können mithilfe dieser Dienstprogramme implementiert werden.

• Verfolgen der in der Anwendung aufgetretenen Probleme mithilfe der Ressourceneigenschaften Retry_interval und Retry_count. Bei Totalfehlschlag der Anwendung entscheiden, ob das PMF-Aktionsskript den Dienst neu starten soll oder ob die Anwendungsfehler so schnell aufeinander folgten, dass ein Failover in Betracht kommt. Die DSDL-Dienstprogramme scds_fm_action() und scds_fm_sleep () sollen Ihnen bei der Implementierung dieses Mechanismus helfen.

• Ausführen der angemessenen Aktionen (in der Regel das Neustarten der Anwendung oder der Versuch, ein Failover der betroffenen Ressourcengruppe auszuführen). Das DSDL-Dienstprogramm scds_fm_action() implementiert einen solchen Algorithmus. Er berechnet zu diesem Zweck die aktuelle Akkumulation von Testsignalfehlschlägen in den letzten Retry_interval Sekunden.

• Aktualisieren des Ressourcenzustands, damit der fehlerfreie Zustand der Anwendung dem scstat-Befehl und der Cluster-Verwaltungs-GUI zur Verfügung steht.

Die DSDL-Dienstprogramme sind so ausgelegt, dass die Hauptschleife des Fehler-Monitor-Dämons durch den folgenden Pseudocode dargestellt werden kann.

Für Fehler-Monitore, die unter Verwendung der DSDL implementiert wurden, gilt:

• Die Erkennung eines Anwendungsprozessversagens durch scds_fm_sleep() erfolgt relativ schnell, da die Prozessausfallbenachrichtigung über PMF asynchron erfolgt. Im Vergleich zu einem Fall, in dem ein Fehler-Monitor immer wieder aktiv wird, um die Fehlerfreiheit des Dienstes zu prüfen und Anwendungsversagen festzustellen, wird die Fehlererkennungszeit deutlich reduziert, was die Verfügbarkeit des Dienstes steigert.

• Wenn RGM den Versuch, ein Failover des Dienstes über die scha_control(3HA)-API auszuführen, zurückweist, wird durch scds_fm_action() die aktuelle Fehlschlaghistorie zurückgesetzt (gelöscht). Der Grund dafür ist, dass die Fehlschlaghistorie bereits über Retry_count liegt. Wenn der Monitor-Dämon im nächsten Durchlauf aktiv wird und den Gesundheits-Check des Dämons nicht erfolgreich beenden kann, versucht er erneut, scha_control() aufzurufen. Dieser Aufruf würde wahrscheinlich erneut zurückgewiesen, da die Situation, die zur Zurückweisung im letzten Durchlauf führte, noch gültig ist. Das Zurücksetzen der Fehlschlaghistorie stellt sicher, dass der Fehler-Monitor zumindest versucht, die Situation im nächsten Durchlauf lokal zu beheben (zum Beispiel über Anwendungsneustart).

• scds_fm_action() setzt die Anwendungsfehlschlaghistorie nicht zurück, wenn Neustartfehler auftreten, da normalerweise bald scha_control() versucht wird, wenn die Lage nicht behoben werden kann.

• Das Dienstprogramm scds_fm_action() aktualisiert den Ressourcenstatus zu SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED oder SCHA_RSSTATUS_FAULTED, entsprechend der Fehlschlaghistorie. Dadurch steht dieser Status der Cluster-Systemverwaltung zur Verfügung.

In den meisten Fällen kann die anwendungsspezifische Gesundheits-Checkaktion in einem eigenständigen Dienstprogramm (zum Beispiel svc_probe()) implementiert und in diese generische Hauptschleife integriert werden.

for (;;) { 

   / * Für die Dauer von thorough_probe_interval zwischen den
   *  einzelnen Testsignalen ruhen. */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));

   /* Jetzt alle verwendeten IP-Adressen testen. Schleife über:
   * 1. Allen verwendeten Netzwerkressourcen.
   * 2. Allen IP-Adressen in einer bestimmten Ressource.
   * Für jede getestete IP-Adresse
   * Fehlschlaghistorie berechnen. */
   probe_result = 0;
   /* Für alle Ressourcen wiederholen, um jede IP-Adresse
    * für den Aufruf von svc_probe() abzurufen */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Hostname und Port für Überwachung der
   * Fehlerfreiheit erfassen.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS unterstützt nur einen Port. Daher den
   * Port-Wert aus dem ersten Eintrag im
   * Port-Array abrufen.
   */
   ht1 = gethrtime(); /* Testsignal-Startzeit festhalten */
   probe_result = svc_probe(scds_handle, 

   hostname, port, timeout);
   /*
   * Testsignalhistorie des Dienstes aktualisieren,
   * bei Bedarf Aktionen ausführen.
   * Testsignal-Endzeit festhalten.
   */
   ht2 = gethrtime();
   /* In Millisekunden konvertieren */
   dt = (ulong_t)((ht2 - ht1) / 1e6);

   /*
   * Fehlschlaghistorie berechnen und
   * bei Bedarf Aktionen ausführen
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Jede Netzwerkressource */
   }       /* Endlos weitertesten */