Entwerfen des Fehler-Monitor-Dämons

Die Ressourcentypimplementierungen, die die DSDL verwenden, weisen in der Regel einen Fehler-Monitor-Dämon auf, der folgende Aufgaben übernimmt:

• Überwacht den Zustand der verwalteten Anwendung in regelmäßigen Zeitabständen. Diese besondere Aufgabe eines Monitor-Dämons hängt größtenteils von der jeweiligen Anwendung ab und kann von Ressourcentyp zu Ressourcentyp erheblich variieren. Die DSDL enthält einige integrierte Dienstprogrammfunktionen, die Zustandsprüfungen für einfache TCP-basierte Dienste ausführen. Sie können diese Dienstprogramme verwenden, um Anwendungen zu implementieren, die ASCII-basierte Protokolle verwenden, z.B. HTTP, NNTP, IMAP und POP3.

• Verfolgt die Probleme, die von der Anwendung ermittelt werden, durch Verwendung der Ressourceneigenschaften Retry_interval und Retry_count . Wenn die Anwendung komplett fehlschlägt, muss der Fehler-Monitor ermitteln, ob das PMF-Aktionsskript den Dienst neu starten soll oder ob sich die Anwendungsfehler so schnell angehäuft haben, dass ein Failover ausgeführt werden muss. Die DSDL-Dienstprogramme scds_fm_action() und scds_fm_sleep() sollen Sie bei der Implementierung dieses Mechanismus unterstützen.

• Wird aktiv, in der Regel in Form eines Anwendungsneustarts oder eines Failover-Versuchs der enthaltenen Ressourcengruppe. Das DSDL-Dienstprogramm scds_fm_action () implementiert diesen Algorithmus. Dieses Dienstprogramm berechnet zu diesem Zweck die aktuelle Anhäufung von Stichprobenfehlern innerhalb der letzten Retry_interval-Sekunden.

• Aktualisiert den Ressourcenzustand so, dass der Anwendungszustand dem scstat-Befehl sowie der Cluster-Verwaltungs-GUI zur Verfügung steht.

Die DSDL-Dienstprogramme sind so entworfen, dass die Hauptschleife des Fehler-Monitor-Dämons am Ende dieses Abschnitts als Pseudo-Code dargestellt werden kann.

Berücksichtigen Sie die folgenden Faktoren bei der Implementierung eines Fehler-Monitors mit der DSDL:

• scds_fm_sleep() entdeckt den Tod eines Anwendungsprozesses schnell, da die Benachrichtigung darüber asynchron über PMF geschieht. Deshalb wird die Fehlerermittlungszeit erheblich reduziert und die Verfügbarkeit des Dienstes erhöht. Ein Fehler-Monitor kann andernfalls unter Umständen häufig geweckt werden, um den Zustand eines Dienstes zu prüfen und um festzustellen, ob der Anwendungsprozess abgebrochen wurde.

• Wenn der RGM den Failover-Versuch des Dienstes mit der scha_control-API ablehnt, setzt scds_fm_action() das aktuelle Fehlerprotokoll zurück oder vergisst es. Diese Funktion setzt das aktuelle Fehlerprotokoll zurück, da es den Wert von Retry_count bereits überschreitet. Wenn der Monitor-Dämon in der nächsten Iteration aufwacht und die Zustandsprüfung des Dämons nicht erfolgreich durchführen kann, versucht der Monitor-Dämon erneut, die scha_control()-Funktion aufzurufen. Dieser Aufruf wird wahrscheinlich erneut abgelehnt, da die Situation, die bei der letzten Iteration zur Ablehnung führte, weiterhin gültig ist. Das Zurücksetzen des Protokolls stellt sicher, dass der Fehler-Monitor zumindest versucht, die Situation bei der nächsten Iteration lokal zu korrigieren (zum Beispiel durch den Neustart der Anwendung).

• scds_fm_action() setzt das Fehlerprotokoll im Falle von Neustartfehlern nicht zurück, da Sie scha_control() in der Regel kurz danach ausführen möchten, falls die Situation nicht von selbst behoben wird.

• Das Dienstprogramm scds_fm_action() aktualisiert den Ressourcenstatus je nach Fehlerprotokoll zu SCHA_RSSTATUS_OK, SCHA_RSSTATUS_DEGRADED oder SCHA_RSSTATUS_FAULTED. Dieser Status steht folglich der Cluster-Systemverwaltung zur Verfügung.

In den meisten Fällen können Sie die anwendungsspezifische Zustandsprüfung in einem separaten eigenständigen Dienstprogramm (z.B. svc_probe()) implementieren. Sie können sie mit der folgenden generischen Hauptschleife integrieren.

for (;;) {
   /* sleep for a duration of thorough_probe_interval between
   *  successive probes.
   */
   (void) scds_fm_sleep(scds_handle,
   scds_get_rs_thorough_probe_interval(scds_handle));
   /* Now probe all ipaddress we use. Loop over
   * 1. All net resources we use.
   * 2. All ipaddresses in a given resource.
   * For each of the ipaddress that is probed,
   * compute the failure history. 
   */
   probe_result = 0;
   /* Iterate through the all resources to get each
   * IP address to use for calling svc_probe()
   */
   for (ip = 0; ip < netaddr->num_netaddrs; ip++) {
   /* Grab the hostname and port on which the
   * health has to be monitored.
   */
   hostname = netaddr->netaddrs[ip].hostname;
   port = netaddr->netaddrs[ip].port_proto.port;
   /*
   * HA-XFS supports only one port and
   * hence obtaint the port value from the
   * first entry in the array of ports.
   */
   ht1 = gethrtime();
   /* Latch probe start time */
   probe_result = svc_probe(scds_handle, hostname, port, timeout);
   /*
   * Update service probe history,
   * take action if necessary.
   * Latch probe end time.
   */
   ht2 = gethrtime();
   /* Convert to milliseconds */
   dt = (ulong_t)((ht2 - ht1) / 1e6);
   /*
   * Compute failure history and take
   * action if needed
   */
   (void) scds_fm_action(scds_handle,
   probe_result, (long)dt);
   }       /* Each net resource */
   }       /* Keep probing forever */