Remote Service Agent

Der Remote Service Agent dient zur Fernwartung von Servern. Anders als der Service Control Monitor wird hier der Funktionsumfang nicht von vorne herein festgelegt, sondern es können damit Probleme gelöst werden, die erst später, nach der Auslieferung der Software, auftreten. Man ist so nicht an das starre Auslieferungsraster der Software gebunden, wenn man sich mit der Notwendigkeit eines raschen Handelns konfrontiert sieht.

Situation: Der Auftraggeber ist eine Dachorganisation über etwa 100 rechtlich selbständige Untereinheiten, die im folgenden "Kunden" genannt werden. Der Auftraggeber erstellt Software für die Kunden. Die Installation der Software und der Betrieb der Server obliegt den Kunden. Bei Bedarf kann sich die Dachorganisation aber nach Freisschaltung durch die Kunden zur Fehleranalyse und -behebung über ein intern abgeschottetes Netzwerk per telnet und ftp auf den Servern anmelden.

Dieses Vorgehen ist aber mit hohen Reibungsverlusten verbunden. Der Auftraggeber muß den Kunden anrufen und sich dort den Zugang zum Server freischalten lassen. Dieses Vorgehen ist bei Einzelproblemen durchaus angemessen, schließlich sind die Kunden ja rechtlich autonom.

Dieses Vorgehen ist aber nicht tragbar, wenn eine Maßnahme auf hunderten von Servern gleichzeitig durchgeführt werden muß. Etwa, weil ein Problem erkannt wurde, welches auf einzelnen Servern bereits Schaden angerichtet hat und nun dringend entschärft werden muß. Leider alles schon da gewesen (Beispiel).

Der Remote Service Agent eignet sich besonders für
  1. Stichtagsumstellungen
  2. Notfall-Wartungsmaßnahmen
  3. Bestandsaufnahmen / Versionsüberprüfungen

Vorbereitung: Bevor man einen Fernwartungsjob verschicken kann, muß man ihn erstellen. Dazu stellt man alle für die Wartungsmaßnahme benötigten Daten und Programme in ein Verzeichnis, packt das in ein komprimiertes Archiv zusammen, versieht es mit einer elektronischen Signatur und lädt es dann zusammen mit einigen Verwaltungsinformationen in eine Hostdatenbank. Mehr: Vorbereitung eines Jobs.

Auf allen Servern läuft ein Programm, welches regelmäßig in der Hostdatenbank nachschaut, ob ein Fernwartungsjob für diesen Server bereitgestellt worden ist. In der Regel ist die Antwort "nein", es geht normal weiter.
Sagt der Host jedoch "ja, doch, ich habe folgenden Fernwartungsjob" ...

Name: Maint-Ejournal-0203.tgz.pgp
Freischaltung ab: 10.02.2003 04:00
Beschreibung: Wartung: Behebe Index-Problem im Ejournal
Group-Id: Unix&Ejournal

... dann überprüft das Datenübertragungsprogramm ...

  1. Aha, der Job "Maint-Ejournal-0203", ist der vielleicht von meinem Administrator gesperrt worden? Die Kunden sind schließlich alle rechtlich autonom und müssen daher die Möglichkeit haben, einen Fernwartungsjob zu sperren, auf eigenes Risiko, versteht sich.
    Falls keine Einzelfreischaltung oder -sperre für diesen Job vorliegt, so wird als nächstes die Jobklasse geprüft. "Maint" steht dabei für "Maintenance", Wartung also. Falls auch hier keine Sperre gefunden wird, so geht es weiter...
  2. habe ich den Job vielleicht schon heruntergeladen? Einmal reicht!
  3. ist der überhaupt schon freigeschaltet? Für Stichtagsumstellungen wird der Job ja frühzeitig in die Hostdatenbank hochgeladen, aber erst zum Stichtag freigeschaltet
  4. interessiert mich der Job überhaupt? Bin ich denn ein UNIX-Server mit dem Package Ejournal? Sonst hilft mir der Job nichts, dann lade ich ihn auch nicht herunter.

Sind alle diese Prüfungen erfolgreich verlaufen, so lädt das Datenübertragungsprogramm den Fernwartungsjob aus der Hostdatenbank herunter und wirft ihn dem Remote Service Agent vor die Füße. Das Datenübertragsprogramm kann selber nicht viel ausrichten, denn es läuft mit minderen Privilegien, als "Indianer".

Nun endlich kommt der Remote Service Agent zum Zuge. Der überprüft nun erst mal, ob dieser Fernwartungsjob eine gültige elektronische Signatur von einem der wenigen, dazu Berechtigten trägt. Wegen des Risikos ist dieser Personenkreis sehr beschränkt. Je schärfer ein Werkzeug ist, desto mehr Unheil kann man leider auch damit anrichten.
Fehlt diese elektronische Signatur, so wird der Fernwartungsjob nicht ausgeführt, sondern nur unter heftigem Geschrei in das Archiv verlagert. Er wird nicht gelöscht, denn alles, was dieses Werkzeug auf dem Server anstellt muß nachvollziehbar bleiben, sogar ein etwaiger Anschlag.

Ist eine gültige Signatur vorhanden, so wird das Archiv ausgepackt und es entsteht nun genau das Verzeichnis, welches bei der Vorbereitung des Fernwartungsjobs auf dem master server angelegt wurde, nun aber auf dem Kundenserver.

Der Remote Service Agent sucht nun mit seiner Suchstrategie nach einem automatisch auszuführenden Datei namens AutoAction. Dieses wird dann ausgeführt. Danach wird geprüft, ob...

  • AutoAction erfolgreich gelaufen oder gescheitert ist. Sollte AutoAction gescheitert sein, so sucht der Remote Service Agent mit der gleichen Suchstrategie nach einer Datei namens FailureRevert, um den Server bis zur manuellen Wartung in einen stabilen Zustand zurückzuversetzen.
  • AutoAction das Reporting selber übernommen hat. Sonst kümmert sich der Remote Service Agent um das Reporting. Wenn man einen solchen Fernwartungsjob erstellt und verschickt, dann muß man ja erkennen können, ob der auch wirklich überall problemlos funktioniert hat!

Der Remote Service Agent bietet also ein erstklassiges Werkzeug, um eine Vielzahl von Servern zu warten. Man arbeitet "unter voller Sicht". An den Rückmeldungen kann man sofort erkennen, auf welchen Servern die Maßnahme problemlos verlaufen ist, um die braucht man sich nicht weiter kümmern. Und man erkennt sofort die — hoffentlich ganz wenigen — Server, die Schwierigkeiten gemacht haben. Die muß man sich dann einzeln vornehmen. Bei denen muß man den Administrator um Freischaltung des Zugriffs auf den Server bitten. Bei der Vielzahl der Server aber, bei denen die Aktion auf Anhieb hingehauen hat, hat man diesen Aufwand gespart.

zurück nach oben
Letzte Änderung: 19.05.2019 17:51