Ein Expertensystem für die Backupsteuerung in DCL

Bei abgebrochenen Jobs wird der Log-File auf bekannte Fehler untersucht. Falls der Fehler bei einem neuen Versuch behoben sein kann, wird der Job einfach nachgestartet. Falls keine Bänder mehr im Pool sind, wird ein nicht zugeteiltes Band gesucht, der Pool erweitert und dann der Job erneut gestartet. Bei Konfigurationsproblemen eines Rechners (z.B. Keine Lizenz gefunden) kommt eine entsprechende Mail an die Systemgruppe und alle Backups auf diesem Client werden gestoppt. Ist eine Fehlermeldung unbedeutet und eigentlich kein echter Fehler wird der Jobstatus auf ok gesetzt. Für neue oder größere Fehler wird per SMS eine Alarmierung ausgelöst. Auch ausserhalb der normalen Öffnungszeiten wird so sofort die Bereitschaft der Systemgruppe oder bei technischen Problemen ein Techniker alarmiert. Neue Fehler werden eingegrenzt und sofort entsprechend abgefangen, so dass beim nächsten mal der Job entscheidet was zu tun ist. Durch Releasewechsel kommen auch wieder ganz neue Fehlermeldungen. Aber auch Softwarefehler können wir so umgehen.

Entstanden ist das ganze dadurch, dass Archive Backup System (ABS) keinen Überblick bietet, welcher Client macht gerade auf welchem Server seinen Backup. Ausserdem sieht ABS keinerlei Steuerung vor, wenn Clients auf Bandstationen warten, wer dann die nächste freie Bandstation bekommt. Alle Jobs laufen einfach an und fragen regelmäßig, ob nun eine Station frei ist. Gibt nun ein Job sein Tape frei, bekommt der erste der wieder gefragt hat die Station, egal ob er schon seit 2 Tagen wartet oder eben erst angelaufen ist. Dadurch kann es auch passieren, dass ein Rechner alle Tapes belegt hat, während andere nie sichern. Mit einem Scheduling der Jobs kann man da was steuern, aber wenn es Probleme gibt, laufen doch wieder alle.

Um möglichst wenig Netzwerkverkehr zu erzeugen läuft dazu auf allen Clients ein Prozess, der regelmäßig seine Maschine ansieht und bei Veränderungen gegenüber dem letzten Zustand dieses sofort per Filecopy an den Expertenprozess meldet. Er schaut auch ob von dort aus Aufträge für den Client vorliegen und führt diese dann aus.

Zentral wird pro Roboter überwacht, wie viele Jobs laufen. Wenn Bandstationen frei sind, steht auf jedem Client das Joblimit einen Job höher als im Moment Jobs laufen. Wird die Anzahl der laufenden Jobs gleich der Anzahl des Laufwerke gehen alle Clients auf einen Job niedriger, als im Moment Jobs laufen. Es wird ermittelt welcher Rechner als nächstes ein Band bekommen müsste und für diesen Rechner wird die Anzahl der Jobs gleich der laufenden Jobs gesetzt. Falls dort ein Job fertig wird, startet der nächste gleich.

Wer dran ist, hängt davon ab, wieviele Jobs auf einem Knoten pending sind und wieviele dort im Moment laufen. Klingt kompliziert, aber es ist gelungen, das ganze automatisch so zu verteilen, dass kein manuelles Eingreifen nötig ist.

Bei Interesse an weiteren Details bitte eine entsprechende Mail an Mail@RolfKruspe.de