Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Der Corpus des Resource Agents

Bisher definiert der Agent im Wesentlichen Funktionen, die seine diversen Aufgaben wahrnehmen. Es fehlt noch der Teil, der diese Funktionen aufruft, wenn der Agent mit einem entsprechenden Target gestartet wird. In genau diesen Corpus gehören auch die zuvor schon erwähnten Definitionen von »ASTRUNDIR« und »ASTLOGDIR« – jedenfalls gehören sie hinter den Aufruf der Validate-Funktion (denn wenn »validate« scheitert, lassen sie sich möglicherweise gar nicht setzen). Der Rest entspricht im Wesentlichen der Syntax, die beispielsweise auch viele Init-Skripte verwenden – das Listing 11 enthält ein vollständiges Beispiel, das in der Agent-Datei ganz an das Ende gehört.

Listing 11

Der Korpus des Agenten

 

Den Resource Agent testen

Es ist nicht zwingend notwendig, einen Pacemaker aufzusetzen, um zu testen (Abbildung 4), ob der Agent so funktioniert, wie er soll. Weil OCF-Agents Shellskripte sind, lassen sie sich auch von der Kommandozeile aus aufrufen. Wichtig ist dafür, dass die Umgebungsvariable »OCF_ROOT« gesetzt ist; auf den allermeisten Linux-Distributionen muss die Variable auf »/usr/lib/ocf« zeigen.

Abbildung 4: Der fertige Resource Agent lässt sich auch händisch auf der Kommandozeile testen, ohne einen Pacemaker aufzusetzen.

Daneben sollten die OCF-spezifischen Umgebungsvariablen für die Parameter ebenfalls in der Shell gesetzt sein, beispielsweise »OCF_RESKEY_realtime« – besonders dann, wenn ein Parameter als »required« markiert ist oder kein Defaultwert dafür existiert. Dann lässt sich der Agent, der im Beispiel »asterisk« heißt und in »/usr/lib/ocf/resource.d/heartbeat« liegt, in diesem Ordner mit »./asterisk monitor« aufrufen, um den Status der Ressource zu testen. Freilich empfiehlt es sich, einen lauffähigen Asterisk (beziehungsweise das Programm, für das der Agent geschrieben ist) zu haben. Die Befehle »start« , »stop« und alle anderen festgelegten Kommandos funktionieren äquivalent. Wenn der Agent sich in bestimmten Aspekten nicht wie erwartet verhält, führt sein Aufruf mit vorangestelltem »sh -x« vermutlich zu weiterem Erkenntnisgewinn.

Sollte ein funktionierender Pacemaker verfügbar sein, kann in diesem auch eine Ressource mit dem Agenten definiert werden (die Bezeichnung des Agents ist im Beispiel »ocf:heartbeat:asterisk« ), um sie danach mit »ocf-tester« zu testen. Unter der Prämisse, dass die Asterisk-Ressource »p_asterisk« heißt, wäre der vollständige OCF-Tester-Aufruf »ocf-tester -n p_asterisk /usr/lib/ocf/resource.d/heartbeat/asterisk« (Abbildung 5). Sollte »ocf-tester« eine Fehlermeldung ausgeben, weiß der Agent-Autor, dass mit dem Werk noch etwas nicht stimmt.

Abbildung 5: Der
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2022