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 */ |