Autonomic Computing - Distributed Systems Group

Ausarbeitung - Grundlagen Methodischen Arbeitens (GMA)
Jan El-Berry
Autonomic Computing
Kurzfassung
Die stetig wachsende Komplexität von modernen Computersystemen macht eine manuelle
Überwachung und Konfiguration zunehmend schwieriger. Die gravierend gestiegenen
Wartungskosten der letzten Jahrzehnte, sowie ein zunehmender Einsatz von Rechnernetzen
in sehr sensiblen wirtschaftlichen und öffentlichen Bereichen des Alltags, hat den noch recht
neuartigen Begriff des „Autonomic Computing“ ins Bewusstsein des technischen
Managements gebracht. Auf den folgenden Seiten werden Konzepte von autonomen
Computersystemen erläutert sowie eine Bewertung zur Einsetzbarkeit, Reifegrad der
Technologie und wirtschaftlichen Relevanz solcher Systeme beschrieben. Weiters werden
konkrete Ansätze zur Verwirklichung von „Autonomic Computing“ vorgestellt und kritisch
hinterfragt.
Inhaltsverzeichnis
Inhaltsverzeichnis.................................................................................................................. 3
1.
2.
3.
Einleitung....................................................................................................................... 4
Related Work................................................................................................................. 4
Grundlagen.................................................................................................................... 5
3.1.
Geschichte............................................................................................................. 5
3.2.
Anforderungen ....................................................................................................... 5
4. Generelle Architektur ..................................................................................................... 8
5. Entwicklungen & Produkte ............................................................................................. 9
5.1.
IBM .......................................................................................................................10
5.2.
SUN ......................................................................................................................11
5.3.
HP.........................................................................................................................12
6. Ausblick ........................................................................................................................13
7. Fazit .............................................................................................................................13
Abbildungsverzeichnis..........................................................................................................14
Literaturverzeichnis ..............................................................................................................14
1. Einleitung
Auf Grund zunehmender Vernetzung und Computerisierung unserer Gesellschaft nehmen
hochkomplexe Computersysteme auf der ganzen Welt Einzug in wesentliche Bereiche des
Alltags. Eine zunehmend wissensbasierte und dienstleistungsorientierte Gesellschaft zieht
ihre Berechtigung vor allem aus ihrer Arbeitseffizienz und stetiger Verfügbarkeit von
Information und Arbeitsleistung.
Bis zum jetzigen Zeitpunkt wurden wichtige Effizienzsteigerungen des Workflows durch den
Einsatz neuer Technologien und ausgefeilter Softwaresysteme erreicht. Die im Laufe der Zeit
immer komplexer gewordenen Rechnernetze, denen diese Entwicklungen zu Grunde liegen,
entwickeln sich jedoch zunehmend zu einem Problem, das den scheinbar
uneingeschränkten Entwicklungsmöglichkeiten natürliche Grenzen setzt. Diese Grenzen
werden vor allem durch die oft aufwändig und daher kostenintensiv gewordene
Administration und Wartung der Systeme gesetzt. Die Einarbeitung in die Funktion und die
Logik großer Netze oder verteilter Softwarestrukturen, wie auch deren Adaption und
Fehlerkorrektur übersteigt nunmehr oftmals die Kosten einer Systemerneuerung bzw. eines
kompletten Systemersatzes. Ehemals effizienzsteigernde IT-Komponenten werden nun zu
einem Hindernis bei der Erhaltung eines stabilen und hochverfügbaren Systems. Diese
natürlichen Grenzen sind vor allem dort anzutreffen wo die geistige Kapazität eines
Individuums oder eines Teams nicht mehr ausreicht um entstandene Fehler rasch
nachvollziehen und weitsichtig, also ohne eventuelle Auswirkungen auf andere
Komponenten, korrigieren zu können.
Ohne den massiven Einsatz und der „Entdeckung“ neuer Technologien durch eine Unzahl
von Unternehmen hätte dieser recht neue Denkansatz bzw. die Vision von weitgehend
autonomen Computersystemen wohl nie dermaßen an Bedeutung gewonnen. Erst durch das
Erlangen wirtschaftlicher Relevanz und den Einsatz neuer Technologie unter realen
Bedingungen wurden in der Entwicklung noch nicht vorhersehbare Probleme erkannt.
Das Konzept des „Autonomic Computing“ wird zur Veranschaulichung oftmals mit dem
menschlichen Körper, im Speziellen dem zentralen Nervensystem (engl. „autonomic central
nervous system“) verglichen, das zur selbstständigen Regulierung und Kontrolle teils
hochkomplexer Vorgänge fähig ist. Es erscheint selbstverständlich dass keine bewusste
Anpassung an äußere Umstände lebensnotwendiger Funktionen wie z.B. dem Herzschlag,
der Verdauung oder der Virenabwehr erfolgen muss. Äquivalent hierzu sollte nun ein neuer
Weg des Selbstmanagements in der IT-Branche zur Vereinfachung komplexer Systeme und
zur Fokussierung menschlicher Ressourcen auf die eigentlichen unternehmensrelevanten
Arbeitsprozesse eingeschlagen werden.
Der englische Begriff des „Autonomic Computing“ der hauptsächlich von IBM geprägt wurde,
wird uns in weiterer Folge als Überbegriff für sämtliche Konzepte mit weitgehend
äquivalenten Zielen dienen. Im Rahmen dieser Ausarbeitung wird die grundsätzliche
Architektur eines Autonomic Computing Systems vorgestellt und produktspezifische
Konzepte erläutert und hinterfragt, die das Ziel haben eine derartige Architektur im
Grundzügen zu verwirklichen.
2. Related Work
[Manoel et al, 2005] – beleuchtet sämtliche allgemeinen und speziellen Aspekte des
Autonomic Compuntings inklusive technischer Details, aktueller IBM-Produkte und
Konfigurations- sowie Einsatzmöglichkeiten.
[IBM, 2001] – Erste konkret formulierte Idee zum Thema Autonomic Computing aus den IBM
Labors. Aufstellung wesentlicher, zukunftsweisender Grundprinzipien.
Seite 4 von 14
[IBM, 2005] – Architektonische Überlegungen und Entwicklung eines Leitfadens zur
Implementiernug eines Autonomic Computing Systems.
[Sterritt & Hinchey, 2005] – Beschreibt die grundsätzliche Entwicklung von Autonomic
Computing sowie den aktuellen Stand. Einschätzung der Möglichkeit einer Umsetzung im
Rahmen von Softwaresystemen.
[Ganek & Corbi, 2003] – Zeigt unterschiedliche Einsatzmöglichkeiten und Bedarf von
Autonomic Computing auf. Zusammenfassung der Grundprinzipien und Beschreibung der
weiterführenden AC-Kategorisierung bestehender Systeme.
3. Grundlagen
3.1. Geschichte
Die Geschichte von Autonomic Computing ist bis zum heutigen Zeitpunkt eine
vergleichweise Junge. Das Groß der Weiterentwicklung und die eigentliche Idee entsprang
den Entwicklungslabors von IBM. Entsprechend machte IBM den Beginn mit seiner
Autonomic Computing Initiative und der Veröffentlichung des „Autonomic Computing
Manifesto“ welches die prinzipielle Idee der Technologie populärwissenschaftlich umreißen
und einen Denkanstoß für zukünftige Entwicklungen geben sollte. Es folgten internationale
Konferenzen wie der „Autonomic Computing Workshop“ auf dem Annual International
Workshop on Active Middleware Services (AMS) im Jahr 2003 sowie 2004 die Einrichtung
einer jährlichen Konferenz des IEEE – der International Conference on Autonomic
Computing (ICAC).
Betrachtet man nun den Zeitraum in welchem die Thematik des Autonomic Computing an
Relevanz gewonnen hat, lässt dieser recht neuartige Denkansatz auf vielversprechende und
zukunftsweisende Technologien hoffen. Diese Hoffnung wird durch den Beitritt wichtiger ITUnternehmen wie HP, Sun und Microsoft zur Autonomic Computing Initiative sowie durch die
Ausweitung der Thematik auf eine wissenschaftliche Ebene, welche im Rahmen der jährlich
stattfindenden IEEE Konferenz bereits einige akademische Arbeiten hervorgebracht hat,
bestärkt. Vor allem letzterer Punkt bietet eine vielversprechende und solide Basis für weitere
Entwicklungen.
3.2. Anforderungen
Ein erster grober Entwurf welcher die prinzipiellen Eigenschaften eines als autonom
betrachteten Systems beschreibt, wurde im Jahr 2001 von IBM als „Autonomic Computing
Manifesto“ [IBM, 2001] veröffentlicht. Das Manifest beschreibt folgende Vorraussetzungen:
1. „Selbsterkennung“ – Ein autonomes System kennt sich selbst und weiß über
seinen Status und damit verknüpfte Eigenschaften bescheid. Es muss sämtliche an
das System angefügte Komponenten oder Zusatzsysteme erkennen und in seine
Systemidentität aufnehmen können.
2. „Selbstkonfiguration“ – Ein autonomes System muss in der Lage sein sich selbst
zu konfigurieren und sich an unterschiedliche, unvorhersehbare Bedingungen
anzupassen. Der Gedanke der Selbstkonfiguration geht dabei weit über eine simple
Anpassung von Serveroptionen hinaus. Das Gesamtsystem, bestehend aus unter
Umständen mehreren tausend Servern muss den Bedingungen entsprechend
untereinander synchronisiert seine Eigenschaften (z.B. Durchsatzrate, Error-Logging,
Sicherheitslevels,...) adaptieren um den bestmöglichen Arbeitsfluss zu gewährleisten.
Seite 5 von 14
3. „Selbstoptimierung“ – Einem autonomen System muss es möglich sein
suboptimale Prozesse zu erkennen und diese zu optimieren um ein möglichst
effizientes Gesamtsystem zu gewährleisten. Einen Status-Quo im herkömmlichen
Sinn darf nicht existieren, da sich die oft komplexen Anforderungen und Bedingungen
eines modernen Unternehmens in gewisser Regelmäßigkeit ändern. Alle an das
System angeschlossenen Komponenten, unabhängig davon wie Speziell die Aufgabe
des Gerätes oder der Software auch sein mag, müssen über einheitliche
Schnittstellen angepasst und reguliert werden können.
4. „Selbstheilung“ – Ein autonomes System muss potentielle Fehler und Probleme
erkennen und korrigieren bzw. umgehen können ohne den Arbeitsfluss zu behindern.
Ist ein Teil des Systems beschädigt oder nicht verfügbar muss es kurzfristig für Ersatz
sorgen können um die Gesamtfunktionalität möglichst vollständig aufrecht zu
erhalten. Besonders dieses Verhalten ist dem menschlichen Gehirn nachgeahmt,
welches versucht bei irreparabler Beschädigung eines Bereichs die benötigten
Prozesse in ähnlich strukturierte Teile des Gehirns zu verlagern. Grundsätzliche
Regeln zur Definition des Heilungsprozess sollten anfangs von IT-Experten definiert
werden. Mit fortschreitender Entwicklung von Autonomic Computing sollte das
System selbstständig in das vorgegebene Schema passende neue Regeln zur
Selbstheilung erzeugen.
5. „Selbstschutz“ – Ein autonomes System muss in der Lage sein seine Ressourcen
vor internen und externen Angriffen zu schützen sowie die Systemintegrität- und
Sicherheit in seiner Gesamtheit zu gewährleisten. Das letztendliche Ziel ist also eine
Art „digitales Immunsystem“ dem ein ausgefeiltes Network Intrusion System zu
Grunde liegt. Dieses sollte bei Gefahr nicht nur den Systemadministrator über ein
Eindringen informieren, sondern vor allem die Problemanalyse und Reparatur
selbstständig durchführen.
6. „Kontextsensitivität“ – Ein autonomes System muss in der Lage sein sich in einer
gegebenen Systemlandschaft zu integrieren und zu interagieren. Das Verhalten
inkludiert dabei die Auffindung bestmöglicher Wege mit seiner Umgebung zu
kommunizieren was den Kontext der jeweiligen Transaktion sehr Wesentlich macht.
Ein anschauliches Beispiel ist der Aufruf einer komplexen Website über ein einfaches
Handy. Ein autonomes System ordnet den Kommunikationspartner richtig ein und
stellt eine sinnvolle Menge an Informationen der Website zur Verfügung.
7. „Offenheit“ - Ein autonomes System muss in einer heterogenen Systemlandschaft
im Rahmen unterschiedlicher Hardware- und Softwarearchitekturen funktionieren
wodurch eine Verwendung offener Standards unumgänglich ist. Ein solches System
kann also per Definition nicht proprietär sein und muss sich der Doktrin der Open
Source Gemeinschaft unterwerfen aus welcher Innovationen wie Linux, Apache und
UDDI entstanden sind.
8. „Vielschichtigkeit“ (Selbstmanagement) – Das wahrscheinlich wichtigste Ziel eines
autonomen Systems von der Anwenderseite betrachtet ist es, seine eigentliche
Komplexität optimal zu verbergen. Eine vom User angeordnete Aufgabe muss vom
Autonomic Computing System in Eigenmanagement gelöst werden ohne dass sich
der Benutzer mit der Lösungsmethode oder der Implementation auseinandersetzen
muss.
Dieser „Leitfaden“ zur Entwicklung eines autonomen Systems ist zum jetzigen Zeitpunkt vor
allem auf Grund der hohen Dichte von proprietären Lösungen innerhalb einer großen ITInfrastruktur noch weitgehend unverwirklichbar. Doch bereits der grundsätzliche Gedanke
sowie die ersten Verwirklichungsversuche ambitionierter IT-Unternehmen sind ein wichtiger
Schritt in Richtung eines neuen Zeitalters. Die genannten Regeln lassen sich zur leichteren
Seite 6 von 14
Abbildung bestehender Systeme und zur besseren Einschätzung der Autonomiestufe auf
vier Kerneigenschaften (CHOP – Eigenschaften) reduzieren:
•
•
•
•
self-configuring
self-healing
self-optimizing
self-protecting
Die vollständige Umsetzung eines autonomen Systems ist zwar noch in weiter Ferne, die
Integration von bereits umsetzbaren Eigenschaften und Features in abgeschlossenen
Systemen oder Softwarekomponenten geschieht jedoch in einer Vielzahl von Produkten
[Sterritt & Hinchey, 2005] Zur Einordnung des Grades der Autonomie bestehender ITInfrastruktur und Systeme dienen die „Levels of Autonomic Computing Maturity“.
Abbildung 1: Levels of Autonomic Computing Maturity [Manoel et al, 2005]
Das Modell unterteilt den Reifegrad eines Systems in fünf unterschiedliche Stufen [Ganek &
Corbi, 2003]
•
Basic (Level 1) – Repräsentiert im Wesentlichen den Zustand der meisten im
Moment eingesetzten Informationssysteme. Grundsätzliche Anforderungen die an
das System gestellt werden, können mit Hilfe von ständiger Bereitschaft des ITFachpersonals erfüllt werden. Bei Problemen oder notwendig gewordenen
Adaptierungen müssen die Anpassungen von den Verantwortlichen getroffen werden.
•
Managed (Level 2) – Ermöglicht einem Administrator durch weitgehend zentralisierte
Management Tools wichtigsten zur Problemanalyse und Problembehebung
benötigten
Informationen
an
wenigen
Stellen
zu
betrachten.
Die
Informationssammlung und Filterung erfolgt im Wesentlichen automatisch was bereits
eine wichtige Kostenersparnis im „human resource“ Bereich zur Folge haben kann.
•
Predictive (Level 3) – Mit der Einführung offener Schnittstellen und Technologien
welche einen gemeinsamen Nenner unterschiedlicher Systemkomponenten
ermöglichen, beginnt das System mittels Mustererkennung möglichst optimale
Konfigurationen und Kommunikationswege zu ermitteln. Vorschläge zur
Seite 7 von 14
Vorgehensweise und Adaptierung des Systems werden dem Administrator über ein
die Administrationstools mitgeteilt.
•
Adaptive (Level 4) – Das System kann auf Basis der ihm zur Verfügung stehenden
Informationen über seine Umgebung und sich selbst die richtigen Entscheidungen
über prinzipielle Einstellungen selbstständig treffen. Ab diesem Level werden gewisse
Adaptierungen des Systems auch ohne Bestätigung durch eine administrative Instanz
getroffen.
•
Autonomic (Level 5) – Level 5 repräsentiert ein autonomes System welches mit
Hilfe von wohldefinierten Zielen und Business Policies Entscheidungen trifft.
Geschäftsprozesse können vom Benutzer beobachtet und Ziele neu definiert werden.
4. Generelle Architektur
Die Architektur eines herkömmlichen technischen Systems orientiert sich vor allem an den
letztendlich zur Verfügung gestellten applikationsspezifischen Funktionalitäten und ist
normalerweise in eine Laufzeitumgebung welche sich um die Fehlerbehandlung und
Ausführung des Programms kümmert, eingebettet (Bsp.: Java Runtime Environment in
Verbindung mit einer Java-Applikation). Ein autonomes System besitzt Komponenten die
über diesen Kontext hinaus mit dem umgebenden System kommunizieren sowie sich das
System als Ganzes überwachen. Diese sind wie folgt spezifiziert [IBM, 2003] :
•
Negotiation – Interagiert mit der Umwelt und kommuniziert jene Anforderungen
welche die Umwelt an das AC-System hat und umgekehrt. Das Ziel der Komponente
ist die Generierung von Verhaltensspezifikationen und Regeln mit Hilfe deren optimal
mit
der
Systemumwelt
zusammengearbeitet
werden
kann.
Diese
Verhaltensspezifikation wird in die „Shared Knowledge“ - Basis (siehe Abbildung 2)
eingefügt.
•
Deliberation – Wird eine neue Spezifikation eingefügt die dem aktuellen
Verhaltensmuster nicht entspricht, wird der Deliberation Prozess aufgerufen welcher
aus der Spezifikation das entsprechende Verhalten konstruiert. Dieses wird wieder an
die Negotiation Komponente weitergeleitet welche über die Ausführung des
Verhaltens entscheidet. Dieser auf den ersten Blick unnötige Schritt geschieht unter
Anderem
deswegen um sicherzustellen dass das Verhalten während des
beschriebenen Prozesses auf Grund geänderter Parameter noch nicht obsolet
geworden ist.
•
Observation – Diese Komponente erhält Statusinformationen aus der Systemumwelt
mit Hilfe derer die Auswirkungen eines durch die Execution Komponente
ausgeführten Verhaltens beobachtet werden kann, ohne zu wissen was einen unter
Umständen geänderten Status ausgelöst hat. Aus den Informationen wird eine zur
Analyse brauchbare Repräsentation der Daten gewonnen und von der Failure
Recovery ausgewertet.
•
Failure Recovery – Erhält zur Auswertung und zur Evaluierung der weiteren
Vorgehensweise Informationen von zwei voneinander unabhängigen Komponenten.
Execution liefert den durch die Ausführung der Aktion vorraussichtlich zu
erwartenden Zustand der Umwelt. Über Observation erhält die Komponente indirekt
den tatsächlichen Zustand. Zur Fehlerbehebung wird die Anzahl und die Art der
Unterschiede der Informationen verglichen. Je nachdem wie gravierend die Differenz
ausfällt werden entsprechende Gegenmaßnahmen eingeleitet. Bei geringen
Abweichungen wird zur Korrektur lediglich ein recovery behavior an die Execution
Komponente weitergeleitet. Bei größeren Abweichungen wird das Verhalten neu
Seite 8 von 14
spezifiziert und über den Deliberation Prozess an die Negotiation Komponente
weitergeleitet welche das fehlerauslösende Verhalten in Execution unter den
entsprechenden Umständen ersetzt.
•
Execution – Führt das ihm übergebene Verhalten aus und Informiert Failure
Recovery über die zu erwartenden Auswirkungen.
Abbildung 2: Allgemeine AC-Architektur [IBM, 2003]
Die auf drei Komponenten eingeschränkte Interaktion zwischen System und Umwelt soll vor
allem der Verwirklichung der Eigenschaften Selbstschutz und Vielschichtigkeit dienen. Ein
System mit einigen wenigen kontrollierten Kommunikationswegen und Schnittstellen ist
weniger anfällig auf Attacken und bietet bessere Möglichkeiten seine interne Komplexität vor
dem Benutzer zu verstecken. Die Deliberation – Komponente repräsentiert die
Eigenschaften
der
Selbstoptimierung
und
Kontextsensitivität
wobei
eine
zufriedenstellende Implementierung dieses Systemteiles ausschließlich mit Hilfe
fortgeschrittener Mechanismen künstlicher Intelligenz verwirklicht werden. Die Komponente
Failure Recovery ergänzt das System vor allem um Fähigkeiten zur Selbstheilung und zum
Selbstschutz, Negotiation dient per Definition der weiterführenden Selbstkonfiguration.
Das oben umrissene Modell dient jedoch ausdrücklich nur als grundsätzlicher DesignLeitfaden. Bei der Implementierung eines spezifischen Systems wird eine weitere
Verfeinerung des Modells vor allem dann von Nöten sein, wenn sich die Systemteile in lokale
und globale Komponenten unterteilen. Auch könnten sich einige Komponenten in der
Umsetzung als dermaßen komplex herausstellen, dass eine weitere Gliederung in
funktionsspezifische Bereiche erfolgen muss oder diese sogar selbst als AC-System
umgesetzt werden müssen.
5. Entwicklungen & Produkte
Im folgenden Kapitel soll ein konkreter Implementierungsansatz eines Autonomic Computing
Systems erläutert, sowie einige bereits existierende Produkte exemplarisch beschrieben
werden, welche bereits Teile dieser Vision verwirklichen. Der Fokus wurde dabei auf
Entwicklungen der Firma IBM gelegt. IBM repräsentiert in diesem Bereich quasi den
technologischen Vorreiter und unternimmt die wohl vielversprechensten Anstrengungen in
Richtung eines ausgereiften und weitgehend autonomen Gesamtsystems.
Seite 9 von 14
5.1. IBM
Einen ersten konkreten Implementierungsansatz gibt IBM in seinem „Architectural blueprint
for autonomic computing“ [IBM, 2005] welcher sich an den bereits beschriebenen Leitfaden
orientiert. Hervorzuheben ist dabei, dass dieser Lösungsansatz die aktuellen technischen
Gegebenheiten und Möglichkeiten berücksichtigt. Das System bietet weder einen
Lösungsansatz für Problemstellungen der künstlichen Intelligenz noch ausgeprägte
Fähigkeiten zur selbstständigen Entscheidungsfindung, sondern basiert auf Erkenntnissen
und Erfahrungswerten im Gebiet der verteilten Systeme. Wie in Abbildung 3 zu erkennen,
wird ein erstes Autonomic Computing System in mehrere hierarchisch organisierte und
miteinander verbundene Komponenten unterteilt.
Abbildung 3: Architektur eines Autonomic Systems [IBM, 2005]
•
Managed Ressource – Stellt wie der Name schon sagt eine managebare Resource
dar. Diese umfasst theoretisch jede Hard- und Softwarekomponente eines Netzwerks
und kann bis zu einem gewissen Grad auch die Fähigkeit des Selbstmanagements
besitzen.
•
Manageability endpoints (Touchpoints) – Definieren die ManagementSchnittstellen zu den als „Managed Ressources“ bezeichneten Endpunkten. Ein
Manageability endpoint besteht aus einem sensor zum Empfang von Daten aus der
gemanageten Ressource und einem effector zum Ausführen der angeordneten
Operationen. Besonders wichtig ist hier die Verwendung von offenen Standards wie
WSDM (Web Service Distributed Management).
•
Autonomic manager – Sind die komplexesten und gleichzeitig wichtigsten
Komponenten der Architektur. Auf Grund der vielfältigen Aufgaben der Komponente
setzt sich diese aus den Teilen Monitor, Analyze, Plan und Execute zusammen.
Analog zu diesen bereits beschriebenen Komponenten formen diese ein
dynamisches System welches das Verhalten der ihnen zugeordneten Ressourcen
bestimmt. Übergeordneten Elemente (Orchestrating Autonomic Manager) spannen
ähnliche Strukturen nochmals über die Einzelsysteme um dem Netzwerk den
ausschlaggebenden Charakter eines Autonomic Computing Systems zu verleihen.
•
Knowledge source – Repräsentiert eine Datenbank oder ein ähnliches
Speichermedium in dem unterschiedliche Vorgaben und Verhaltensregeln
Seite 10 von 14
gespeichert werden. Wird permanent durch den „Autonomic Manager“ aktualisiert
und erweitert.
•
Manual manager – Ist die Implementierung einer grafischen Benutzerschnittstelle
über die ein Benutzer (IT-Spezialist) mit anderen Benutzern kommunizieren und
Vorgaben bzw. Policies für übergeordnete „Autonomic Manager“ spezifizieren kann.
Eine konkrete Implementierung der beschriebenen Architektur in Form eines
Gesamtsystems existiert bis heute nicht. Es gibt jedoch eine Vielzahl an Produkten die die
Eigenschaften einzelner Komponenten umsetzen und in der Lage sind in einem
gemeinsamen Netzwerk miteinander zu arbeiten und sich gegenseitig zu ergänzen. IBMs
„Tivoli“ – Softwareinitiative ist ein Überbegriff für eine Vielzahl an Produkten welche dem
Kunden die Möglichkeit von durchgängigem Netzwerk- und Systemmanagements bietet.
Beispiele für konkrete Anwendungen der Software wären Datensicherung, Netzwerk- und
Rechnerüberwachung
sowie
automatische
Inventarisierung
und
automatische
Softwareverteilung. Da eine detaillierte Beschreibung der Produkte den Rahmen der Arbeit
sprengen würde, werden in weiterer Folge drei Produkte der Tivoli – Reihe exemplarisch
umrissen:
•
Tivoli Availability Process Manager – Stellt Eigenschaften zur Verfügung, mit deren
Hilfe man den Einfluss von Ereignissen auf kritische Geschäftsabläufe oder
Serviceleistungen ermitteln und auswerten kann. Im Rahmen dessen bietet das
Produkt also die Möglichkeit zur Klassifizierung von Servicestörungen aus Sicht des
Unternehmens. Ein derartiges System repräsentiert am ehesten die Eigenschaften
der Selbstoptimierung und Selbstheilung eines Autonomic Computing Systems.
•
Tivoli Change and Configuration Management Database – Ist ein integriertes Tool
zur Management, Überwachung und Koordination sämtlicher Unternehmensprozesse
welche das Change- und Configurationmanagement betreffen. Zur Erhaltung der
Systemintegrität sowie zur Unterstützung des Entscheidungsfindungsprozesses
werden zahlreiche Informationen über IT-Infrastruktur Ressourcen, Konfigurationen
sowie physikalische und logische Abhängigkeiten zwischen mehreren Ressourcen
gespeichert. Entsprechend dem Namen des Produkts kann es den Bereichen
Selbsterkennung und ansatzweise Selbstkonfiguration auf Autonomic Level 3
(siehe Abbildung 1) zugeordnet werden.
•
Tivoli Capacity Process Manager – Ermöglicht dem Anwender die zentrale
Verwaltung aller kapazitätsorientierten Aktivitäten über eine grafische
Benutzeroberfläche. Das umfasst die Erstellung, Zuordnung und Überwachung von
Kapazitätstasks sowie eine regelmäßige Statusrückmeldung auf Basis
voreingestellter Muster. Entspricht einem Automomic Level (siehe Abbildung 1)
zwischen Stufe 2 und 3 und dient der Selbstoptimierung.
5.2. SUN
Sehr ähnlich wie IBM’s Softwere Tivoli zeigt sich der grundsätzliche Ansatz von SUN mit
seiner N1-Softwarereihe. Mit einer Vielzahl von Softwaremodulen welche dazu in der Lage
sind jeweils einen Teilaspekt des Autonomic Computing Gedankens in einem Netzwerk
umzusetzen, versucht sich SUN am Markt zu etablieren. Die einzelnen Produkte lassen sich
auf Grund von weitgehender Betriebssystemunabhängigkeit (Windows, Linux, Mac OS) bis
zu einem gewissen Grad in eine bereits bestehende heterogene Systemlandschaft
integrieren. Exemplarisch soll ein Kernelement des Systems umrissen werden [SUN, 2007]:
•
N1 System Manager – Bietet zentrale Administrations-, Monitoring- und
Überwachungsmöglichkeiten von SUN – Serversystemen. Interessant erscheint vor
allem die automatische Erkennung bestehender sowie zugeschalteter Komponenten
Seite 11 von 14
und die Möglichkeit der fein granulierten Kontrolle von Utility Computing
Mechanismen (entsprechende Modulen vorausgesetzt).
Sun’s N1 System erscheint recht funktionell und aus technischer Sicht sehr ausgereift. Die
Hauptproblematik liegt hier aber vor allem in der Verwendung von praktisch ausschließlich
proprietären Technologien was die Einsatzmöglichkeit der einzelnen Komponenten in einem
heterogenen System mehr oder weniger stark einschränkt.
5.3. HP
Eine der größten Entwicklungsinitativen der letzten Jahre stellte die Entwicklung des HP
Utility Data Center dar. Mit einem aus technologischer Sicht recht großen Schritt vorwärts
wollte sich HP bis 2004 an die Spitze des Autonomic Computing Marktes katapultieren. Das
System (bestehend aus einer Kombination von Hard- und Software) sollte ein weitgehend
zentrales und teils automatisiertes Systemmanagement von unterschiedlichsten
Komponenten (Server, Datenbanken, Netzwerkkomponenten, Sicherheitssystemen) in einer
hochgradig heterogenen Systemlandschaft auf Utility Computing – Basis ermöglichen
[ZDNet, 2003]
Abbildung 4 zeigt den grundsätzlichen Aufbau des HP Uility Data Centers. Den für die
Datenverarbeitung sowie für die Datenspeicherung verantwortlichen Elementen (z.B. Server)
ist es möglich unter einer Vielzahl an unterschiedlichen (Betriebs-)Systemen zu operieren.
Die integrierte Utility Kontrollsoftware managed dabei sämtliche Systeme inklusive aller
verbindenden Netzwerkelemente und erlaubt es einem Datacenter Manager über eine
zentrale Konsole neue Ressourcen zu aktivieren und bestehende Ressourcen neu zu
ordnen. Die OpenView Technologie bietet sogenanntes Enterprise Level Management unter
Anderem für die Bereiche Ressourcen- und Sicherheitsmanagement [HP, 2003]
Abbildung 4: Aufbau des HP Utility Data Center [HP, 2003]
Die Einstellung des Projekts erfolgte im Jahr 2004 auf Grund von mangelnder Rentabilität.
Wegen der horrenden Einstiegskosten von ca. 1.000.000 US-Dollar konnten in den ersten
Jahren nach Veröffentlichung des Systems nur eine handvoll Kunden aquiriert werden.
Neben den extrem hohen Basiskosten wurden dem System ebenfalls zu hohe Consulting –
Kosten zur reibungslosen Funktion innerhalb einer heterogenen Netzlandschaft zum
Verhängnis. Das Utility Data Center stellt definitiv eines der gewagtesten und aus Sicht des
Automomic Computing – Gedankens, fortschrittlichsten Unternehmungen der letzten Jahre
dar. Die Pleite des Projekts unterstreicht den Eindruck, dass die Zeit für ein solches
Gesamtsystem noch nicht reif zu sein scheint. Der Umweg einer Vereinheitlichung von von
Grund auf unterschiedlicher Systeme durch eine übergeordnete Struktur ist ein Weg welcher
wie am UDC deutlich zu sehen war, zum scheitern verurteilt ist. Viel eher muss die gesamte
IT-Landschaft durch verstärkte Zusammenarbeit und durch den massiven Einsatz offener
Standards homogener werden.
Seite 12 von 14
6. Ausblick
Der derzeitige Stand der Dinge im Bereich Autonomic Computing Development zeigt sich
sehr differenzierter Form. Es existiert eine hohe Anzahl an Produkten welche primär einzelne
Teile des Autonomic Computing Konzepts umsetzen. Ein umfassendes System dass diese
vielen teilweise bereits sehr guten Einzellösungen zu einem Ganzen zusammenfasst, wird in
nächster Zukunft vor allem von IBM anvisiert. Die Frage ist jedoch ob ein derartiges System
von einer zufriedenstellenden Anzahl an Kunden finanziert werden kann, sich also eine
dermaßen risikoreiche Investition von Seiten der Entwicklungsunternehmen überhaupt lohnt.
Die Pleite des HP Data Utility Center, das Kunden eine in Ansätzen funktionierende
Gesamtlösung bieten sollte, zeigt deutlich dass die Zeit noch nicht reif und die derzeitige ITLandschaft bei weitem zu heterogen für ein solches Unterfangen ist. Die größten
Anstrengungen in der Entwicklung von Autonomic Computing Systemen werden derzeit
dahingehend unternommen die einzelnen Produkte effizient untereinander kommunizieren
zu lassen. Vor allem durch die Übersetzung proprietärer Datenformate und
Kommunikationsprotokolle auf offene Standards wie WSDM (Web Services Distributed
Management) soll die Interoperabilität unterschiedlicher Systeme gewährleistet werden.
Unter den Vorraussetzungen dass sich dieser positive Trend fortsetzt und das
„technologische Zugpferd“ IBM finanziell gesund bleibt, ist in den nächsten fünf bist zehn
Jahren bereits mit ersten für Großunternehmen leistbare und lohnende Gesamtlösungen zu
rechnen.
7. Fazit
Die Entwicklung und der Einsatz autonomer Systeme wie sie Paul Horn in seinem Autonomic
Computing Manifesto beschreibt, wird in naher Zukunft kaum zu realisieren sein. Die meisten
Anforderungen die an ein autonomes System gestellt werden, stellen Entwickler nach wie
vor vor eine Vielzahl technischer Probleme. Besonders Komponenten deren Funktion auf
Mustererkennung und dem Treffen dynamischer Entscheidungen beruhen, benötigen bis zur
Marktreife noch viele Jahre an Forschung und Entwicklung. Indirekt ist hier vor allem das
sehr breit gefächerte Forschungsfeld der künstlichen Intelligenz gefordert, welches
Strukturen und Systeme bereitstellen muss die mit derartig komplexen Herausforderungen
effizient umgehen können. Neben den technischen Herausforderungen muss auch ein
prinzipielles Umdenken in der Arbeitsweise führender Unternehmen erfolgen. Ausschließlich
durch eine Definition gemeinsamer Standards und Schnittstellen sowie eine massive
Fokussierung auf den Open Source Gedanken kann verhindern, dass ein derart
ambitioniertes und großartiges Unterfangen bereits im Keim erstickt wird. Autonomic
Computing steckt noch in den Kinderschuhen, doch bereits Systeme welche mit heutigem
Wissen und unter zahlreichen Einschränkungen entwickelt worden sind erzielen beachtliche
Ergebnisse - zukünftige Entwicklungen können also mit Spannung erwartet werden.
Seite 13 von 14
Abbildungsverzeichnis
Abbildung 1: Levels of Autonomic Computing Maturity [Manoel et al, 2005] .......................... 7
Abbildung 2: Allgemeine AC-Architektur [IBM, 2003] ............................................................. 9
Abbildung 3: Architektur eines Autonomic Systems [IBM, 2005]...........................................10
Abbildung 4: Aufbau des HP Utility Data Center [HP, 2003] .................................................12
Literaturverzeichnis
[Sterritt & Hinchey, 2005] Roy Sterritt, Mike Hinchey: Autonomic Computing Panacea or
Poppycock?, Proceedings of the 12th IEEE International Conference
and Workshops on the Engineering of Computer-Based Systems (ECBS05).
[Manoel et al, 2005] Edson Manoel, Morten Jul Nielsen, Abdi Salahshour, Sai Sampath,
Sanjeev Sudarshanan: Problem Determination Using SelfManaging Autonomic Technology, IBM Redbook, (2005).
[Ganek & Corbi, 2003] A.G. Ganek, T.A. Corbi: The dawning of the autonomic
computing era, IBM Systems Journal, 42(1), (2003).
[IBM, 2003] zurich.ibm.com: Jana Koehler, Chris Giblin, Dieter Gantenbein, Rainer Hauser:
On Autonomic Computing Architectures, (2003). Zu finden unter
http://www.zurich.ibm.com/pdf/ebizz/idd-ac.pdf (Mai, 2007)
[IBM, 2001] ibm.com: Autonomic Computing, (2001). Zu finden unter
http://www.research.ibm.com/autonomic/manifesto/autonomic_computing.pdf (Mai, 2007)
[IBM, 2005] ibm.com: An architectural blueprint for autonomic
computing, (2005). Zu finden unter http://www03.ibm.com/autonomic/pdfs/AC_Blueprint_White_Paper_4th.pdf (Mai, 2007)
[HP, 2003] hp.com: HP Utility Data Center: Enabling Enhanced Datacenter Agility, (2003). Zu
finden unter http://h71028.www7.hp.com/enterprise/downloads/udc_enabling.pdf (Mai, 2007)
[ZDNet, 2003] news.zdnet.com: Dan Faber: Utility computing: What killed HP's UDC?
, (2004). Zu finden unter http://news.zdnet.com/2100-9584_22-5388523.html (Mai, 2007)
[SUN, 2007] sun.com: Sun N1 System Manager Overview.
http://www.sun.com/software/products/system_manager (Mai, 2007)
Zu
finden
unter
Seite 14 von 14