D3.1 Wissensanalyse. Modellierung und Erfassung des Administratorwissens. Isenmann, Götz Tirtasana, Mathias Volk, Eugen.

Transkript

1 D3.1 Wissensanalyse Modellierung und Erfassung des Administratorwissens Arbeitspaket/Task: Fälligkeit: <Nummer.Nummer> <M06> Abgabetermin: Verantwortlich: Versionsnummer/Status: Autoren: Interne Gutachter: Vertraulichkeitsstatus Buchholz, Jochen Isenmann, Götz Tirtasana, Mathias Volk, Eugen Mickler, Holger Grunzke, Richard HLRS 130 Abgeschlossen Öffentlich Projektintern Sonstiges: X HLRS S+C S+C HLRS ZIH ZIH Version Datum Änderungen Autor Template-Erstellung Buchholz, Jochen (HLRS) Entwurf Buchholz, Jochen (HLRS) Viele Korrekturen, Vorschläge Isenmann, Götz (S+C) Tirtasana, Mathias (S+C) Update Volk, Eugen (HLRS) D3.1 Wissensanalyse v130 1/

2 Aktualisierung Buchholz, Jochen (HLRS) Internes Review Mickler, Holger (ZIH) Grunzke, Richard (ZIH) Korrekturen Buchholz, Jochen (HLRS) Abschluss Buchholz, Jochen (HLRS) D3.1 Wissensanalyse v130 2/

3 Inhaltsverzeichnis 0. Zweck des Dokuments Der Administrator Aufgaben eines Administrators Informationsquellen Dokumentation des Wissens durch den Administrator Das Wissen des Administrators Administrative Maßnahmen Art der Maßnahmen Managementmaßnahmen Maßnahmen zur Fehlerbehandlung Ablauf der Fehlerbehandlung Beschreibung der Maßnahmen Real existierende Maßnahmen Weitere gewünschte Maßnahmen Kategorisierung der Maßnahmen Modellierung der administrativen Maßnahmen Ereignisse Informationsgewinnung Entscheidungen Aktionen Zusätzliche Anforderungen Typisierung der verwendeten Daten Hardware-Beschreibung Seriennummern Physikalische Struktur Logische Struktur Software-Verteilung Konfigurationsmanagement Darstellung und weitere Anforderungen Zusammenfassung...32 D3.1 Wissensanalyse v130 3/

4 0. Zweck des Dokuments Dieses Dokument soll die Ergebnisse der Analyse des Administratorwissens zur Planung, Installation, Konfiguration, Wartung, Betrieb und insbesondere Fehlerbehandlung von/in großen Rechnersystemen beschreiben und eine Modellierung des Wissens ermöglichen. Um dies zu erreichen, werden zunächst die Arbeit des Administrators, seine Informationsquellen sowie die am weitesten verbreitete Art zu dokumentieren untersucht. Darauf aufbauend wird versucht, seine typischen Handlungsabläufe anhand real existierender Maßnahmen zu erfassen und im Hinblick auf eine Kategorisierung auszuwerten. Dies ist die Grundlage, um sowohl eine klare und einfache Systemarchitektur und ein Datenmodell entwickeln zu können, gleichzeitig jedoch viele Freiheiten bei den spezifischen Maßnahmen zu erlauben. Beides ist nötig, um sowohl die Anforderungen sehr großer Systeme erfüllen zu können als auch die Einführung eines solchen Systems zu erleichtern, da die Realität der Administration derzeit noch wenig Automatisierung und sehr viele unterschiedliche Problemlösungsstrategien und Dokumentationstypen umfasst, wodurch eine exakte und unmittelbare Abbildung in ein Datenmodell nicht möglich ist. Aus diesem Grund werden danach generische Aktionen definiert, mit denen die Vorgänge zum intelligenten Management von großen Rechnersystemen beschrieben werden können. Dieses Dokument enthält keine Angaben zu: Architekturvorentscheidungen: Wie sollen Daten/Dienste verteilt werden um z. B. eine hohe Skalierbarkeit zu erreichen? Dies bleibt den entsprechenden Arbeitspaketen vorbehalten, da hier nur ein Teilaspekt der Anforderungen untersucht wird. Darstellungsdetails: Wie sollen die Daten/Zusammenhänge und Regeln zur Fehlerkorrektur gegenüber dem Administrator/Kunden dargestellt werden? Wie/ob das zu entwickelnde System selbstständig Korrekturvorschläge erzeugen kann, wenn zu einem Problem keine Lösung hinterlegt ist. 1. Der Administrator Um das Wissen des Administrators und der anfallenden administrativen Maßnahmen für das Management und insbesondere die Fehlerbehandlung von Rechnersystemen extensiv erfassen und modellieren zu können, reicht es nicht aus, alleine diese Maßnahmen zu untersuchen. Vielmehr ist ein Blick auf das gesamte Aufgabenspektrum des Administrators nötig, um seine Sicht auf die Systeme besser verstehen und die Zusammenhänge finden zu können. Aus dem erfassten Zusammenhang können dann im Idealfall Strategien zur Lösung von Problemen in der Administratordomäne abgeleitet werden. Des Weiteren ist es nötig zu wissen, woher ein Administrator Informationen zur Problemlösung bezieht, da ihm hier häufig keine konkrete Anleitung zur Lösung vorliegt, bzw. er zunächst herausfinden muss, um welchen Fehler es sich handelt und dies nur für häufig auftretende Fehler gut dokumentiert ist. Die Art und Weise, wie Administratoren ihr Wissen niederschreiben, ist der entscheidende Punkt, das Wissen an Kollegen und Nachfolger weiterzugeben und im Laufe der Zeit zu verfeinern oder zu korrigieren. D3.1 Wissensanalyse v130 4/

5 1.1 Aufgaben eines Administrators Tools for Intelligent System Management of Zu den Aufgaben von Administratoren sehr großer Rechnersysteme gehören im Allgemeinen deren Planung, Hardware-/Software-Installation, Konfiguration, Betrieb, Nutzermanagement, Wartung und insbesondere Behandlung von auftretenden Fehlern. Aus technischer Sicht sind es viele unterschiedliche Bereiche: Hardware-Arbeiten, beginnend mit der Aufstellung der Systeme über den Austausch defekter Geräte bis hin zum Abbau der Altsysteme ebenso wie Arbeiten an der Stromversorgung und der Klimaanlage. Planung und Realisierung von Änderungen an der physikalischen Struktur, z. B. der Netzwerkanbindung, aber auch Umgruppierungen von Rechnersystemen. Erstellung der logischen Struktur des Gesamtsystems, insbesondere die Netzwerkstruktur betreffend, aber auch die zentrale Speicherverwaltung. Anpassen der logischen Struktur an neue Anforderungen, z. B. bei Neuerwerbungen von Geräten oder bei der Einführung von neuen Funktionalitäten für das Gesamtsystem bzw. Rechenzentrum. Anpassungen der einzelnen Systeme an neue Anforderungen, z. B. Anwendungssoftware, Zugangssysteme, Abrechnungssysteme, Lizenzmanagement, Firewallanpassungen, um einen möglichst reibungslosen Übergang zu gewährleisten. Erkennung von spontan auftretenden Fehlern, ebenso wie Auswirkungen von Fehlkonfigurationen, Hardwareproblemen, Notwendigkeit von Optimierungen und Kapazitätsanpassungen. Hilfestellung für Benutzer im Umgang mit dem System sowie den verbreiteten Anwendungsprogrammen und deren Anpassung auf die jeweilige Umgebung. Dazu zählen sowohl Probleme, die regelmäßig bei vielen Benutzern entstehen und durch entsprechende Anleitungen minimiert werden können, als auch solche Probleme, die nur unter ganz speziellen Rahmenbedingungen entstehen und den Benutzer bei der selbständigen Lösung überfordern. Diagnose und Behebung von selbst erkannten Fehlern ebenso wie von Fehlern, die von den Benutzern berichtet werden, aber oftmals mangels Expertenwissen nur unzureichend beschrieben werden. Dieser Vorgang sollte zeitnah geschehen damit der betroffene Benutzer rasch weiter arbeiten kann und um nicht weitere Benutzer zu behindern, da die Fehler häufig auch andere Benutzer betreffen. Eskalation von Fehlern falls eine Behebung durch den Administrator nicht möglich ist, z. B. Hardware-Austausch durch den Hersteller, Einspielen eines Backups durch den Backup- Spezialisten, Reparatur der Klimaanlage oder Stromversorgung durch externe Techniker. Umkonfiguration des Rechenzentrums zur Lastanpassung. Einfügen neuer Benutzer in die Nutzerdatenbanken und Verteilen der notwendigen Rechte, was meist zu einem Großteil automatisiert ist. Änderungen am Gesamtsystem erzwingen jedoch häufig Anpassungen an dieser Verteilung. Dokumentation zu allen zuvor genannten Themen erstellen, um: D3.1 Wissensanalyse v130 5/

6 - Kollegen den aktuellen Stand sowie Änderungen mitzuteilen, - Nachfolgern den Einstieg zu erleichtern, - bekannte Probleme beim nächsten Mal schneller zu lösen, - Benutzern Anleitungen zu geben. 1.2 Informationsquellen Um dieses breite Spektrum an Aufgaben im Umfeld sehr großer Rechnersysteme erfüllen zu können, greifen Administratoren auf verschiedene Informationssammlungen zu: Anleitungen und Beschreibungen von den Herstellern der Rechnersysteme. Anleitungen von Software-Herstellern. Pläne der physikalischen und logischen Struktur des Gesamtsystems eines Rechenzentrums bzw. Clusters. Soll-Zustand der Verteilung von Diensten und Dateien auf die vorhandenen Ressourcen. Selbst erstellte Anleitungen für häufig auftretende Fälle, z. B. Datenrettung, Rechnerabbild erstellen, die meist nicht durch die Anleitung eines einzigen Herstellers abgedeckt werden. Externe Informationsquellen wie bspw. Foren, Herstellerwebseiten, Suchmaschinen. Ansammlungen von Wissen in unstrukturierter Form: Codestücke, einzelne Konfigurationsbausteine, Befehle, usw. Persönliches Wissen, das nicht niedergeschrieben ist und damit nur dem einzelnen Administrator zur Verfügung steht, sowohl allgemein bekanntes Fachwissen als auch die persönliche Erfahrung im Umgang mit den Systemen. Für die Fehlererkennung zusätzlich noch Monitoring-Werkzeuge, die an die jeweilige Umgebung angepasst sind oder vom Hersteller bereits angepasst geliefert wurden. Herstellerspezifische Managementwerkzeuge und Informationssysteme für die einzelnen Rechnersysteme. 1.3 Dokumentation des Wissens durch den Administrator Solange ein Administrator nur Systeme betreut, für die er allein verantwortlich ist, wird meist auf eine ausführliche Dokumentation verzichtet, da diese sehr viel Zeit kostet. Dies wirkt sich jedoch dann gravierend negativ aus, wenn der Administrator vertreten werden muss oder die Systeme einem Nachfolger übergeben werden. Bei größeren Systemen, die von einer Gruppe von Administratoren betreut werden, ist eine fehlende Dokumentation mit wesentlich mehr Nachteilen verbunden: Kollegen kennen die aktuelle Konfiguration nicht und können dadurch gewisse Zusammenhänge nicht nachvollziehen. Eventuelle Fallstricke, welche durch Sonderkonstrukte entstanden sind, können zu Fehlbedienungen führen. D3.1 Wissensanalyse v130 6/

7 Kollegen wissen nicht, welche Fehler aufgefallen sind und wie sie gelöst wurden. Mehrere Administratoren versuchen, das gleiche Problem zu lösen, obwohl es evtl. schon gelöst wurde oder durch eine Änderung eines anderen Administrators die Fehlerfindung beeinflusst wird (z. B. geänderte Netzwerkeinstellungen und dadurch bedingt eine andere Fehlermeldung). Durch eine fehlende Dokumentation werden somit viele Arbeiten unnötigerweise getätigt bzw. jedes Mal von neuem durchgeführt. Auf der anderen Seite wird es vor allem bei häufig auftretenden und schnell zu behebenden Problemen für unnötig empfunden, eine Dokumentation zu schreiben, da der Aufwand in keinem Verhältnis zur Problemlösung steht. Erschwerend kommt hinzu, dass die Dokumentation erfahrungsgemäß vor allem dann vernachlässigt wird, wenn gerade sehr viel Arbeit zu erledigen ist und damit auch sehr viel am System verändert wird. Dadurch entsteht eine Dokumentation, die sporadisch geführt wird, sehr unterschiedlich in der Detailtiefe ist, unterschiedliche Schreibweisen enthält, nicht immer aktuell ist, usw. Sie ist oftmals nur teilweise und lückenhaft vorhanden und zudem noch unstrukturiert. Ein nachträgliches Dokumentieren scheitert meist daran, dass nicht mehr alle Details bekannt sind. Zusätzlich sieht der einzelne Administrator immer nur seinen Aufgabenbereich und kann entsprechend die Dokumentation auch nur daraufhin ausgerichtet niederschreiben, worunter die Gesamtstruktur leidet, solange kein übergeordnetes Konzept vorliegt. Ein weiteres Problem der Verwirklichung einer konsistenten Dokumentation liegt darin, dass die Art zu Dokumentieren sich bspw. durch personelle Veränderungen oder Änderungen an den fachlichen Schwerpunkten fortlaufend ändert und somit im Laufe der Zeit die Pflege der Gesamtdokumentation deutlich erschwert wird. 1.4 Das Wissen des Administrators Das gesamte Wissen eines Administrators wird sehr stark von der Erfahrung des Einzelnen geprägt, dies betrifft sowohl seinen Umgang mit den Systemen als auch seine Kenntnis über Informationsquellen wie diese genutzt werden können. Denn nur wenn er genau weiß, wo welche Information abgelegt wurde und wie detailliert und zuverlässig diese Information ist, kann er schnell und kompetent seine Arbeit durchführen. Es gibt derzeit keine Möglichkeit, das gesamte Wissen des Administrators direkt und übersichtlich darzustellen wie dies für die Nutzung in Managementumgebungen wünschenswert wäre. Vielmehr ist das Wissen sehr stark zersplittert, was eine Erfassung des Wissens oft nur in Teilbereichen umfassend erlaubt. Es muss also eine Möglichkeit geschaffen werden, ein System zu entwickeln, das dem Administrator erlaubt, auf einfache Art und Weise seine Arbeit für häufig auftretende Probleme basierend auf Informationen über die gewünschte Rechnerlandschaft zu automatisieren. Dadurch kann er sich um die vielen anderen Probleme kümmern, die seltener vorkommen und deren Automatisierung deshalb nur schwer möglich ist, weil wegen der geringen Anzahl an Fehlerfällen oft zu wenig Detailwissen bekannt ist, um das Problem eindeutig zu beschreiben. Bei regelmäßig auftretenden Fehlern wird entweder irgendwann eine sehr detaillierte Untersuchung durchgeführt oder es sammeln sich im Laufe der Zeit ausreichend Informationen an, um eine genaue Beschreibung zu ermöglichen. D3.1 Wissensanalyse v130 7/

8 2. Administrative Maßnahmen 2.1 Art der Maßnahmen Tools for Intelligent System Management of So breit gefächert wie die Aufgaben und Informationsquellen eines Administrators sind, so unterschiedlich sind auch die Maßnahmen, die ein Administrator ergreifen kann, um seine Systeme zu verwalten und auftretende Fehler zu beheben. Sie reichen von einem einfachen Neustart eines Prozesses/Dienstes oder dem Anlegen eines Benutzers über Anpassungen einzelner Dienste bis hin zur Umkonfiguration eines Rechners oder des gesamten Rechenzentrums. Die Maßnahmen können grob in zwei Bereiche Managementmaßnahmen und Fehlerbehandlung eingeteilt werden, die jedoch häufig miteinander verbunden sind. Managementmaßnahmen dienen vorrangig dazu, die Systeme an neue oder geänderte Anforderungen anzupassen, sie zu erweitern oder bei Fehlern die noch funktionierenden Teile des Systems von den Auswirkungen der Fehler abzuschirmen. Außerdem zählt auch die Inbetriebnahme von neuen Rechnern dazu, die sich von den anderen Maßnahmen aber dahingehend unterscheidet, dass die Managementwerkzeuge auf den neuen Systemen noch nicht vorhanden sind. Meist sind diese Maßnahmen geplant oder die Maßnahmen sind vorher bereits bekannt und schon mehrfach durchgespielt. Demgegenüber sind die Maßnahmen zur Fehlerbehandlung durch das unvorhergesehene Auftreten von Fehlern und die Notwendigkeit einer zeitnahen Lösung nicht planbar und nur sehr schwer umfassend zu beschreiben. In die Fehlerbehebung können je nach Granularität ggf. Managementmaßnahmen eingebaut werden bzw. die komplette Fehlerbehandlung aus Bausteinen aus den Managementmaßnahmen aufgebaut werden. Dies stellt den Idealfall dar, der aber wegen der großen Zahl an unterschiedlichen Fällen nicht vollständig zu erreichen ist Managementmaßnahmen Die Managementmaßnahmen sind prinzipiell im Voraus planbar und können entsprechend gut durchdacht und auf evtl. auftretende Auswirkungen auf andere Systeme hin untersucht werden. So können Änderungen am System wie das Hinzufügen von neuen Rechnern, das Installieren neuer Anwendungen oder das Abschalten von Teilen der Systeme so geplant werden, dass sowohl die Auswirkungen auf andere Systeme gering sind als auch die betroffenen Systeme sich danach in einem definierten Zustand befinden, aus dem sie im Falle einer Abschaltung kontrolliert wieder in den Soll-Zustand überführt werden können. Hierbei kann davon ausgegangen werden, dass die Administratoren die möglichen Auswirkungen mit ausreichender Sorgfalt berücksichtigt haben und umfassende Informationen (Hardware, Software, Konfigurationsparameter, Dokumentation, usw.) vorliegen. Die trotz aller Vorsicht auftretenden bzw. nicht planbaren Fehler halten sich meist in Grenzen und sind durch entsprechende Puffer in der Zeitplanung normalerweise leicht abzufangen. Die Behebung dieser Störungen folgt im Allgemeinen dem Vorgehen für die Fehlerbehandlung. Lässt man bei einer Betrachtung das Eintreten von Fehlern außen vor, so befindet sich das System immer in einem bekannten und gewollten Zustand. Durch diese Vorteile reiner Managementmaßnahmen können diese prinzipiell auch sehr gut strukturiert und aufeinander abgestimmt werden. Für die Umsetzung auf große Systeme können dadurch auch sehr gut existierende Werkzeuge eingesetzt werden. D3.1 Wissensanalyse v130 8/

9 2.1.2 Maßnahmen zur Fehlerbehandlung Tools for Intelligent System Management of Im Gegensatz zu Managementmaßnahmen befindet sich das System im Fehlerfall in einem unbekannten Zustand, da der erkannte Fehler die Ursache nur verdecken könnte. Es sind meist nur rudimentäre Informationen vorhanden, die beschreiben was passiert ist; meist besteht der erste Hinweis lediglich aus den Symptomen der Fehlfunktion. Erst nach einer Fehleranalyse mittels Log- Dateien, dem Vergleich von Ist- und Soll-Zustand oder anderen Maßnahmen kann die Ursache identifiziert und das Problem gelöst werden. Dies kann anhand passender Managementmaßnahmen geschehen oder vor allem bei kleinen und schnell zu lösenden Problemen durch manuellen Eingriff anhand des eigenen Wissens. Da TIMaCS sich insbesondere mit den Maßnahmen zur Behandlung von Fehlern beschäftigt, muss das Administratorwissen zur Behandlung von Fehlern auf das zu schaffende Wissensmodell abgebildet werden. Dies wird in D3.2 Design und Implementierung des logischen Systems - welches im Laufe des Projektes erstellt wird - näher erläutert Ablauf der Fehlerbehandlung Das folgende Bild veranschaulicht die Ausgangssituation der Fehlerbehandlung, sofern es sich um eine größere Gruppe von Administratoren handelt, die das zugrunde liegende System betreuen. VO Person Administrator Fachbereich Hardware Account Netzwerk Tools Speicher Anwendungen Wissensbasis Kundendienst 1st Level Support Monitoring Anwendung Gerät Fachbereich Netzwerk D3.1 Wissensanalyse v130 9/

10 Die Wissensbasis sollte alle Fehlerbehandlungsroutinen sowie Wissen über den Aufbau und die Konfiguration des Gesamtsystems beinhalten. Sie ist in der Realität oft nicht in strukturierter Form vorhanden, dies sollte jedoch das Ziel sein. Das allgemeine Wissen über Hardware, Software, Befehle, Funktionen sowie Handbücher usw. ist hier explizit nicht enthalten. Dies liegt in der Unschärfe dieses Wissens begründet, da z. B. Befehle vielfältig kombinierbar und Handbücher natürlichsprachlich sind und so nur schwer maschinenlesbar gemacht werden können. Somit bleibt die Anwendung dieses Wissens auch bei dem Einsatz eines Management-Frameworks dem Administrator vorbehalten. Der 1 st Level Support erhält aus einer großen Zahl an Quellen (Benutzer, Administratoren von virtuellen Organisationen oder anderer Rechenzentren, Anwendungen, Geräte) eine Fehlermeldung (Ereignis) mit einer mehr oder weniger genauen Fehlerbeschreibung auf unterschiedlichen Wegen mitgeteilt (Telefon, Mail, persönlich). Der Bearbeiter versucht durch Betrachtung des aktuellen Systems und seiner persönlichen Erfahrung eine problemspezifische Lösung in der Wissensbasis zu finden um eine Entscheidung treffen zu können. Wenn es eine hinterlegte Lösung gibt, so führt er die entsprechenden Schritte aus, um das Problem zu lösen (Aktion). Findet er hingegen keine Lösung, so gibt er das Problem an eine entsprechende Fachgruppe weiter, die das Problem genauer untersucht und eine Lösung erarbeitet. Hat die Fachgruppe eine Lösung gefunden, so führt sie diese aus und ergänzt die Wissensbasis um die neu entwickelte Lösung. Spätestens sobald das Problem gelöst ist, wird sofern die Anfrage von einer Person stammt, eine passende Antwort verfasst und versandt, es ist bei größeren und länger dauernden Problemen durchaus sinnvoll, den Nutzer durch zusätzliche Status-Updates auf dem Laufenden zu halten. Bei kleineren Administratorgruppen kann es durchaus sein, das der 1 st Level Support auch die Funktionen einer Fachgruppe wahrnimmt bzw. selbst versucht, Lösungen zu finden und diese dann ggf. in die Wissensbasis eingibt. Im Folgenden wird ohne die Architektur des Management-Frameworks zu beschreiben dargestellt, wie sich die Fehlerbehandlung durch das TIMaCS Framework verändern kann. D3.1 Wissensanalyse v130 10/

11 Person VO Kundendienst 1st Level Support Fachbereich Netzwerk Events Administrator Ist- Zustand Soll- Zustand Web-Interface Events Gerät Monitoring/ Management Events Policies Account Netzwerk Tools Speicher Fachbereich Hardware Wissensbasis Anwendung Management Engine Im Unterschied zu der herkömmlichen Darstellung ist in der Wissensbasis nur eine maschinenlesbare Form des Wissens abgespeichert, die um eine natürlichsprachliche Beschreibung ergänzt ist, damit es für den Administrator leichter ist, die einzelnen Maßnahmen zu unterscheiden, ohne jeweils alle Details beachten zu müssen Wie im vorigen Fall wenden sich Personen und Organisationen weiterhin an den 1 st Level Support, eine Ausnahme bilden hier einzelne Nutzer oder externe Administratoren, denen ein direkter Zugang zum Management Framework gestattet werden kann. Der Bearbeiter führt nun jedoch eine gefundene Lösung nicht selbst aus, sondern veranlasst das System, die hinterlegte Lösung abzuarbeiten. Dadurch kann sichergestellt werden, dass die Aktion wiederholt identisch ausgeführt wird, was bei einem Administrator nicht notwendigerweise der Fall ist. Ist keine Lösung vorhanden, wird wiederum die Fachgruppe involviert, welche eine Lösung erarbeitet und in die Wissensbasis eingibt, damit das System in Zukunft den Fehler selbst beheben kann. Zusätzlich werden genaue Fehlerindikatoren für die neue Maßnahme hinterlegt, die dazu führen, dass das System diese laufend überwacht. Die Management-Umgebung erhält dazu Benachrichtigungen von den Monitoring- Komponenten über Fehler bzw. Abweichungen der Ist-Werte von den Soll-Werten. D3.1 Wissensanalyse v130 11/

12 Auf diese Ereignisse hin sucht die Management-Umgebung in der Wissensbasis eine Lösung und führt diese aus bzw. schlägt diese dem Administrator vor, falls er die Maßnahme noch nicht für die automatisierte Behandlung freigegeben hat. Zusätzlich kann die Management-Umgebung bei auftretenden Fehlern die Einhaltung von Policies überprüfen und im Fehlerfall Gegenmaßnahmen einleiten, um diese weiterhin zu erfüllen. 2.2 Beschreibung der Maßnahmen Real existierende Maßnahmen Die folgende Liste von real am HLRS existierenden Maßnahmen für sehr große Rechnersysteme ist bei weitem nicht vollständig, da dies je nach Rechenzentrum und Einsatzzweck variiert und zu umfangreich wäre. Zu den aufgeführten Maßnahmen ist meist eine gewisse Dokumentation vorhanden da es sich um recht umfangreiche Maßnahmen handelt, darüber hinaus gibt es viele undokumentierte Maßnahmen, die von den Administratoren umgesetzt werden. Die Liste soll jedoch veranschaulichen, wie groß die Bandbreite an Maßnahmen ist, um durch deren Abstraktion die Bildung des Wissensmodells zu ermöglichen. Nr. Maßnahme Beschreibung Betroffene Rechner 1 Hängenden Job killen Wie geht man vor wenn sich ein Batch-Job nicht terminieren lässt, z. B. nach Knotenabsturz 2 Crashdump der NEC Vector 3 Batch-Jobs modifizieren 4 Booten der NEC Vector Systeme 5 Lustre Dateisystem Ethernet / IB 6 Fehlersuche SUN Lustre 7 Konfiguration diskless Cluster 8 Installation von Software-Paketen auf diskless Systemen Vorgehen nach Systemcrash eines NEC Vector Knotens. Info bereitstellen für OS Ing. von NEC Vorgehen bei dringenden Batch-Jobs Anleitung wie ein NEC Vector System gebootet wird Installation und Konfiguration des Lustre FS für diverse Systeme Problemlösung bei Lustre Abstürzen Cluster Konfiguration und Kernel Installation von zusätzlichen Pakten (RPM) in das read-only Dateisystem Knoten/ Frontend Knoten Frontend/ Cluster Knoten/ Cluster Knoten/ Cluster Cluster Grund der Maßnahme Setup Setup Fehlerbehebung Fehlerbehebung Nutzeranfrage Fehlerbehebung Setup Setup/ Update D3.1 Wissensanalyse v130 12/

13 Nr. Maßnahme Beschreibung Betroffene Rechner 9 Kernel-Update bei diskless Systemen 10 SCSI Festplatte tauschen 11 Passworte im gesamten Netz ändern 12 SUSE-Update durch Firewall 13 Tausch defekter Festplatte an EasyRaid 14 Tausch defekte Festplatte im SW RAID 15 Boot-Loader installieren 16 Retten von Daten einer defekten Festplatte 17 BIOS-Update von x Knoten 18 Integration neuer Knoten in Compute Partition 19 Einstellung der NFS- Tuning-Parameter 20 Konfiguration der RAID-Systeme 21 Administration der MegWare-Cluster Knoten 22 Nachträglich Software- Pakete installieren 23 MegWare Knoten neu installieren Vorgehen zum Kernel-Update, z. B. bei sicherheitskritischen Problemen Tauschen einer defekten Festplatte im RAID-Betrieb Passwort für Benutzer Umsetzen ohne DB-Update Zugriff auf SUSE-Repositories zum Betriebssystem-Update Was ist zu tun wenn eine Festplatte in einem easyraid ausfällt Defekte Festplatte in einem Software RAID ersetzen Was tun wenn ein System seinen Boot- Loader nicht mehr findet (Linux) Falls kein Backup vorhanden ist kann man so u. U. noch auf die Daten zugreifen Knoten im Cluster müssen gleiche BIOS Version in haben. Hier steht wie die richtige Version eingespielt wird Schritte für die Integration zusätzlicher Knoten im Cluster TCP-Parameter Einstellungen für NFS Server. Wie erfolgt permanente Änderung? Konfiguration und Tuning der Server bzgl. IO-Verhalten und RAID- Konfiguration Konfiguration des D-Grid-Clusters (MegWare) für den Fehlerfall sind hier die Dienste beschrieben Wenn zusätzlich Software-Pakete benötigt wurden steht hier wie es geht. Hier steht wie ein Knoten neu zu installieren ist, z. B. defekte Festplatte Cluster Hardware Cluster Benutzeranfrage Knoten/ Knoten/ Frontend Knoten Knoten Knoten/ Cluster Knoten/ Cluster Knoten Grund der Maßnahme Update/ Setup Defekt Rechenzentrum Update Defekt Defekt Fehlerbehebung Knoten/ Fehlerbehebung Update Erweiterung Tuning Setup/ Tuning Setup/ Fehlerbehebung Update Setup D3.1 Wissensanalyse v130 13/

14 Nr. Maßnahme Beschreibung Betroffene Rechner 24 Konfiguration des -Servers zum IBM Blade Center (Cell) 25 Installation der IBM Cell Blades 26 Modul-Dateien BW- Grid Wie ist der -Server zum Betrieb der IBM Cell Knoten im BW- Grid-Cluster zu installieren Aufsetzen der automatischen Installation der IBM Cell Knoten Wie sind Modul-Dateien für das BW- Grid Cluster zu erstellen 27 BW-Grid Updates Wie werden Software-Updates in das BW-Grid Cluster Image eingespielt 28 HP Lustre reparieren Was tun wenn das HP Lustre Dateisystem abgestürzt ist 29 Initrd Nehalem Wie werden zusätzliche Treiber in die initiale Ramdisk für den Bootprozess integriert 30 Virtuelle Betrieb der per XEN virtualisierten -Server 31 UNICORE-Betrieb Benutzer in UNICORE eintragen, Fehlersuche der UNICORE Dienste 32 LDAP Client Wie wird ein LDAP Client eingerichtet. Automatisches User Management 33 Umgang mit Backups Vorgehensweise zum Erstellen und Einspielen von Backups. (Auch verschlüsselt) 34 Systemüberwachung Systemüberwachung mit Nagios aufsetzen. 35 Automatisches USER- Management 36 Management der Cisco- Switche 37 Filterlisten-Verwaltung (FW) 38 DNS- und DHCP- Einträge verwalten Wie werden die Direktiven aus der DB in die Systeme eingespielt Konfigurieren, aktualisieren u. sichern der Cisco-Switche Administrieren der CISCO ACLs Geht immer zusammen mit dem Verwalten von IP-Adressen Knoten Cluster Cluster Knoten/ Cluster Knoten/ Frontend Allgemein Fehlerbehebung Rechenzentrum Rechenzentrum Rechenzentrum Rechenzentrum Rechenzentrum Grund der Maßnahme Setup Setup Setup Update Update Setup Setup Fehlerbehebung Rechenzentrum Benutzeranfrage Setup Setup Setup/ Update Setup/ Update Setup/ Update D3.1 Wissensanalyse v130 14/

15 Nr. Maßnahme Beschreibung Betroffene Rechner 39 Verwalten von IP- Adressen 40 Verwaltung der Subnetze u. Rechner 41 Pflege und Installation unterschiedlicher Software-Pakete und Unterstützung der Benutzer 42 Alle Projekte Eintrag von Diskquotas Verwalten der vergebenen IP-Adressen für Server Plan für Netzwerkdosenbeschaltung Pflege der installierten Software (Parallele Debugger, Performance- Analyzer, parallele Kommunikationsbibliotheken, Programmierumgebungen etc.) und der entsprechenden Webseiten. Software- Support bei Nutzeranfragen. Manueller Eintrag der Diskquotas für die Abrechnung 43 IP-Freischaltung Für alle Nutzer Änderung der IP- Freischaltung für die Hardware- Firewall 44 Einspielen der Accounting-Daten 45 Problembehandlung an der Schnittstelle DB Produktionssystem 46 Systemüberwachung und Pflege Datenbankserver 46 HPSS Nutzer- Management 47 HPSS Erfassung und Meldung der Abrechnungsdaten 49 HPSS Systemüberwachung Bearbeitung der Accounting-Daten von der Accounting-Datei der System- Datenbank Lösen der Probleme im Zusammenhang mit Direktiven und Einträgen auf den Systemen Überwachung der Backups, Eintrag neuer Accounts, Überwachung der Systemstabilität und der administrativen Prozesse Eintragen, Abmelden, Datenänderungen der Nutzer. Erfolgt automatisch über die Datenbank Erfassen der Dateiserver- und Archivbelegung durch die Industrie und Meldung der Daten an die Verwaltung zur Rechnungsstellung Überwachung der Systemfunktionalität, Überwachung der Systemauslastung bzw. der Belegung Rechenzentrum Rechenzentrum / Rechenzentrum Cluster/ Knoten Rechenzentrum Cluster/ Rechenzentrum Benutzeranfrage Grund der Maßnahme Setup/ Update Setup/ Update Setup/ Update Update Accounting Cluster/ Rechenzentrum Fehlerbehebung Allgemein Accounting Monitoring D3.1 Wissensanalyse v130 15/

16 Nr. Maßnahme Beschreibung Betroffene Rechner 50 Überwachung der RAID-Systeme (DDN) 51 Festplattentausch in den RAIDs (DDN) Semi-automatisch, Überwachen der Log-Dateien und Systemmeldungen Vorgang zur Anmeldung und Tausch von Platten in den verschiedenen RAID-Systemen z. T. mit anschließender Datenträgervernichtung Knoten/ 53 Überwachung Systemstatus GRAU Bibliothek Überwachung der Funktionalität des Bandroboters und der zugehörigen Laufwerke 52 Systemüberwachung Überwachung der Systemfunktionalität Knoten/ Grund der Maßnahme Monitoring Defekt Monitoring Monitoring Erläuterungen: Betroffene Rechner: Knoten: Betrifft nur einzelne Knoten eines Clusters Frontend: Betrifft nur die Frontends und ggf. als Auswirkung davon weitere Komponenten Cluster: Betrifft alle Knoten eines Clusters oder die Funktion des gesamten Clusters : Betrifft komponenten wie Batch-System, Dateiserver, Datenbank Rechenzentrum: Cluster-übergreifend, z. B.: Nutzermanagement, Storage Allgemein: Allgemeine Probleme, die nicht auf ein System bezogen sind Hardware: Kann sich auf jedes Gerät beziehen Grund der Maßnahme: Fehlerbehebung: Diese Maßnahmen werden im Fehlerfall durchgeführt im Idealfall, um diesen beheben zu können Setup: Dient der (einmaligen) Einrichtung eines Rechner, Dienstes, Komponente im Idealfall vom Auslieferungszustand zum Soll-Zustand Update: Einzelne Aktionen um das System anzupassen, meist von außen angestoßen, z. B. Treiber-/Sicherheitsupdates Benutzeranfrage: Alle Maßnahmen, die nicht aus dem Betrieb des Rechners selbst resultieren, sondern von Benutzerseite angestoßen werden, z. B. neue Benutzer, dringende Jobs, neue Software-Wünsche Tuning: Ausschließlich Maßnahmen zur Verbesserung der Performance, wenn das System schon stabil läuft D3.1 Wissensanalyse v130 16/

17 Erweiterungen: Spezialfall einer Erweiterung des laufenden Systems Accounting: Maßnahmen im Bezug zur Abrechnung Defekt: Hardware-Defekte, sie können nicht von einem Managementwerkzeug gelöst werden, lediglich die Abschottung der betroffenen Komponenten ist möglich Monitoring: Vorbeugende Überwachungsmaßnahmen, um Fehler schneller erkennen zu können und ggf. umfassendere Informationen für die Behebung zu erhalten. Die aufgeführten Maßnahmen sollen von dem zu entwickelten Framework dahingehend unterstützt werden, dass der Administrator wesentlich entlastet wird, bei der parallelen Installation mehrerer Rechner unterstützt wird oder im Fehlerfall gar nicht erst aktiv werden muss, sondern lediglich über das Auftreten und Korrigieren des Fehlers informiert wird Weitere gewünschte Maßnahmen Die folgende Liste enthält Maßnahmen, die mit den durch TIMaCS zu entwickelnden Werkzeugen unterstützt werden sollen, derzeit jedoch nur manuell durchgeführt werden oder noch gar nicht vorbereitet sind. Nr. Maßnahme Beschreibung Betroffene Rechner 1 Frontend ersetzen Ersatz-Frontend aufsetzen falls das primäre Frontend nicht schnell genug gerettet werden kann. 2 Knoten einer Queue ersetzen 3 Anpassen der Knoten/Queue 4 Fehlerquellen auf verschiedenen Knoten finden 5 Kapazitätsverteilung ändern Knotenersatz bei Ausfall eines Knotens aus einer kleinen Gruppe, z. B. einen von zwei interaktiven Knoten durch einen Knoten aus einer großen Gruppe Änderung der Knoten/Queue Zuordnung, falls eine Queue übervoll ist und eine andere fast leer ist. Wenn ein inkrementeller Fehler, durch z. B. Plattenfehler, RAM erkannt ist, diesen für andere Systeme prognostizieren. Partitionierung der gesamten Ressourcen für unterschiedliche Anforderungen (Wirtschaft, Wissenschaft, usw.) und Verschiebung von Ressourcen zwischen diesen bei ungleicher Auslastung. Änderung von Firewalls, Dateisystemen, Konfigurationen, usw. Frontend Knoten/ Knoten/ Frontend Knoten Grund der Maßnahme Defekt Defekt Tuning Knoten/ Fehlervorhersage Lastverteilung D3.1 Wissensanalyse v130 17/

18 2.2.3 Kategorisierung der Maßnahmen Tools for Intelligent System Management of Die in den Tabellen beschriebenen Maßnahmen lassen sich relativ leicht dahingehend einordnen, wann sie durchgeführt werden, wie groß der Wirkungskreis ist (Knoten, Cluster, Rechenzentrum), ob weitere Informationen benötigt werden oder nur ein vordefiniertes Kommando abgesetzt werden muss, was für die Architektur insbesondere der Managementkomponenten sehr wichtig ist, um entscheiden zu können, welche Informationsflüsse für die Auswahl der Maßnahmen unter Berücksichtigung der Skalierbarkeit auf der jeweiligen Ebene notwendig sind. Für die Modellierung des Wissens ist dieser Ansatz jedoch nicht ideal, da vielen Maßnahmen unabhängig von diesen Kategorien die selbe Struktur zugrunde liegt. Viel wichtiger ist hier die Erkenntnis, inwiefern die Maßnahmen verallgemeinert und parametrisiert werden können, um allgemein und unabhängig vom jeweiligen System die Auswahl und Ausführung der notwendigen Maßnahmen möglichst automatisieren zu können. Die folgende Liste verallgemeinert die Maßnahmen und listet mögliche Parameter auf, die dann zum Tragen kommen, wenn mehrere unterschiedliche Implementierungen der Maßnahme (z. B. verschiedene Hardware, Dateisysteme, Firewalls, usw.) vorhanden sind bzw. benötigt werden. Diese Parameter können automatisiert verwendet werden und der Administrator muss lediglich die abstrakte Maßnahme für die Beschreibung der Aktionen verwenden. Nr. Abstrakte Maßnahme Mögliche Parameter 1 Starten eines Knotens Knoten-ID (Betriebssystemumgebung), Clustername, Dateisystem zum booten 2 Ändern einer Dienst- Konfiguration Diensttyp, Speicherart (lokal, Netz, Kommandoparameter), Knoten-ID 3 Neustart eines Dienstes Dienstname/-typ, Knoten-ID/Frontend-Name 4 Anpassen der Firewall Firewall Modell, Dienst/Port, Ziel, Quelle 5 Verschieben eines Dienstes Knoten-ID (Betriebssystemumgebung), Diensttyp, Clustertyp 6 Knoten verschieben Netzkennung, Netzzuordnung 7 Knoten neu starten Knotentyp, Hard-/Soft-Reboot Der Administrator kann somit das System beispielsweise beauftragen nach mehrmaligen erfolglosen Versuchen einen Dienst neu zu starten stattdessen nun den gesamten Knoten neu zu starten, unabhängig davon welche Aktionen hierfür notwendig sind. Im Managementsystem ist dann hinterlegt, ob das Absetzten eines Reboot Kommandos direkt auf dem lokalen Knoten möglich ist, oder ggf. ein Neustart über die Managementkonsole des übergeordneten Racks notwendig ist, über das mehrere Knoten angesprochen werden können. In gleicher Weise können auch andere Informationen auf unterschiedlichen Wegen ermittelt werden, auch wenn nicht bei allen eine Alternative zum direkten Abfragen des Knotens vorhanden ist. D3.1 Wissensanalyse v130 18/

19 2.3 Modellierung der administrativen Maßnahmen Tools for Intelligent System Management of Um weiter von den Maßnahmen abstrahieren zu können, werden die aufgeführten Maßnahmen in ihre Einzelelemente zerlegt, so ist jedes dieser Elemente eindeutig zuzuordnen: Reine Informationsgewinnung: Ist-/Soll-Zustand der Konfiguration, Messwerte, Tests oder Generieren von Informationen zur weiteren Verarbeitung, die jedoch keine Veränderung an den Systemen auslösen Entscheidung: Welche Aktionen stehen zur Verfügung bzw. sollen ausgeführt werden Aktion: Was soll wo und wie ausgeführt werden, um den Soll-Zustand zu erreichen Prinzipiell können auch sämtliche Maßnahmen zur Informationsgewinnung als Aktionen verstanden werden, aber es sprechen einige Gründe dafür, dies voneinander zu trennen: Vermutlich werden für das Monitoring bzw. Management unterschiedliche bereits existierende Werkzeuge verwendet, was durch eine gemeinsame Betrachtung erschwert werden würde, da dann die Anforderungen beider Seiten zu berücksichtigen sind und somit möglicherweise nicht die besten Werkzeuge gewählt werden können. Bei einer Trennung kann in der Designphase die Komplexität der einzelnen TIMaCS- Bausteine möglichst gering gehalten werden, was wiederum vorteilhaft für die Skalierbarkeit sein dürfte. Es ist jedoch durchaus denkbar, dass es existierende Werkzeuge gibt, die für gewisse Aspekte sowohl für Monitoring- als auch Managementfunktionen in TIMaCS verwendet werden können. Monitoring und Management haben insbesondere bzgl. Skalierbarkeit stark unterschiedliche Anforderungen. Das Monitoring läuft dauerhaft und muss in höchstem Maße skalieren, um überhaupt eine gesicherte Informationsbasis zu ermöglichen, während es bei der Managementkomponente vor allem auf die Korrektheit der Entscheidung ankommt, um negative Folgen zu vermeiden. Gewisse Performance-Einbußen im Falle vieler gleichzeitiger Fehler sind da durchaus vernachlässigbar, solange die Fehlerbehebung trotz allem noch wesentlich früher und schneller geschieht als bei einem manuellen Eingriff des Administrators. Eine Betrachtung dieser drei elementaren Maßnahmen scheint zunächst kaum ausreichend zu sein, aber sämtliche Maßnahmen lassen sich auf diese drei Typen abbilden. Die Schwierigkeit besteht nur darin, herauszufinden, welche Informationen benötigt werden, um eine zufriedenstellende Entscheidung treffen zu können. Denn der menschliche Administrator entscheidet nach jedem Informationsgewinn, ob er nun ausreichendes Wissen hat oder noch mehr wissen muss. Eine Abbildung dieses Vorgangs in ein automatisiertes System ist dadurch möglich, indem der Administrator die gewünschte Informationsmenge detailliert beschreibt und in feste Regeln abbildet, was getan werden soll. Denkbar ist jedoch, diese gewünschten Informationen dahingehend aufzuwerten, dass beschrieben wird, ob diese unabdingbar sind oder wie viele dieser Informationen vorliegen müssen um eine Aktion auszulösen. Dies könnte vor allem dahingehend verwendet werden, um im Fehlerfall bei fehlenden eindeutigen Regeln dem Administrator Vorschläge zu machen, welche der hinterlegten Regeln möglicherweise interessant sein könnten. Auch könnte so mit Hilfe historischer Daten D3.1 Wissensanalyse v130 19/

20 erkannt werden, ob man oftmals nur knapp einem Ausfall größerer Systemteile entkommen ist oder welche Komponenten am häufigsten ausfallen bzw. den größten Schaden nach sich ziehen und somit am dringendsten verbessert werden sollten. Wenn man davon absieht, dass der Administrator während einer manuellen Fehlerbehebung immer wieder Informationen sammelt um zu einer Entscheidung zu gelangen und diese im Verlauf auch ändern oder präzisieren kann, was bei einem automatisierten System nur schwer vorstellbar ist, sondern stattdessen alle notwendigen Informationen für eine Entscheidung bzw. Aktion in einem Schritt zusammenfasst, so kann der Ablauf einer automatisierten Fehlerkorrektur wie im folgenden Bild dargestellt aussehen. Dabei können sowohl die Bedingungen als auch die Aktionen in Gruppen organisiert sein, wobei die Aktionen geordnet sein müssen. Dadurch wird es erleichtert, Managementbausteine zu erzeugen die wiederverwendet werden können. D3.1 Wissensanalyse v130 20/