Autonomic Computing - IT-Sicherheitsinfrastrukturen (Informatik 1)

— Autonomic Computing —
Einführung und Überblick über aktuelle Forschung
Andreas Ganser ∗
RWTH Aachen
Kurzdarstellung
Zunehmend wird die Zuverlässigkeit von Computersystemen in speziellen Anwendungsbereichen wichtiger. Jedoch
fehlen in diesen Bereichen oft die Erfahrungen oder Mittel
für reine Hochverfügbarkeits-Systeme. Deshalb wird dort
gerne auf das, häufig günstigere, Autonomic Computing gesetzt. Darunter subsummieren sich Computersysteme, die
hauptsächlich aus Standardkomponenten bestehen und im
Verbund betrachtet meist sehr heterogen sind. Trotzdem
setzt sich das Autonomic Computing als Ziele selbstkonfigurierend, selbstoptimierend, selbstheilend und selbstschützend zu sein. Folglich müssen Fehler von solchen Computersystemen selbständig erkannt und klassifiziert oder gar in
gewisser Weise vorausgesehen werden können. Dann sollten sie anhand von Wissensbasen weitestgehend „intelligent“ eine Entscheidung zugunsten einer Aktion treffen können. Diese Aktionen des Systems können je nach Fehlerfall
sog. rückwärtige, vorwärts gerichtete oder rekonfigurierende Maßnahmen sein.
Beginnend mit einer Klassifizierung von Fehlern, über
die Erklärung der obigen Begriffe des Autonomic Computing, bis hin zu einen Einblick, wie Entscheidungen getroffen werden, soll im Folgenden ein kurzer Überblick über die
aktuelle Forschung gegeben werden.
1. Motivation
Bei der Entwicklung des Arpanet spielte angeblich die
Ausfallsicherheit für den Fall eines atomaren Erstschlags
eine wesentliche Rolle (tatsächlich sollte diese Eigenschaft
nur für das zugehörige Telefonnetz gelten [15]). Trotzdem
sind heute die Routen im Internet meist mehrfach redundant
ausgelegt. Somit ist beim Ausfall eines oder mehrerer Netzwerkknoten weiterhin die Kommunikation unter den restlichen Netzwerkknoten weitgehend sichergestellt. Auf Pro∗ Dieser
Beitrag entstand im Rahmen des Konferenzseminars „Verlässliche Verteilte Systeme“, das im Wintersemester 2005/2006 vom Lehrund Forschungsgebiet Informatik 4 der RWTH Aachen durchgeführt wurde.
tokollebene ist diese Ausfallsicherheit heute als die Routingeigenschaft der TCP/IP-Protokollfamilie bekannt; genau
genommen handelt es sich um das Border Gateway Protocol, kurz BGP. Interessant ist daran, dass das Internet dadurch in seiner heutigen Struktur eine selbstheilende Eigenschaft erlangt. Denn: fällt ein Netzwerkknoten aus, werden
die Datenpakete einfach über einen anderen Netzwerkknoten geroutet. Darüber hinaus beinhaltet das Internet auch eine selbstschützende Eigenschaft. Denn Sackgassen existierten schon auf Protokollebene nicht.
Mitte der Neunziger entstanden Peer-to-Peer Netzwerke.
Dabei wurde eine weitere selbst-X Eigenschaft geboren, da
bei solchen Netzwerken die Daten redundant gehalten werden. D.h. sobald gewisse Daten innerhalb des peer-to-peer
Netzwerkes verteilt sind, gehen sie selbst dann nicht verloren (mit einer hohen Wahrscheinlichkeit), wenn der Quellhost das Netzwerk verläßt. Diese Daten sind somit gegen
Defekte im Sinne von Ausfall geschützt, also selbstreparierend; ebenso sind sie selbstschützend.
Auch das SETI@home Projekt entstand Mitte der Neunziger und demonstriert die Idee des verteilten Rechnens.
Dabei teilt ein zentraler Dienst besonders große Rechenaufgaben in verhältnismäßig kleine Aufgaben auf. Clients
mit freien Resourcen können diese Pakete anfordern und
leisten dann die Rechenarbeit. Anschließend schicken sie
das Ergebnis zurück. Natürlich ist hierbei nicht gewährleistet, dass die Pakete zurückgeliefert werden. Die wesentliche Idee ist allerdings, dass mit einer bestimmten Protokollbasis die Möglichkeit geschaffen wurde, Rechenaufgaben
aufzuteilen. Diese Idee ist um 2000 weiterentwickelt worden und seit dem unter dem Begriff Grid Computing geläufig.
Als zur selben Zeit aufgrund von XML der Hype um die
WebServices entstand, wurde die Grid Computing Idee auf
ein XML basierendes Protokoll portiert. Als Standard gibt
es heute dazu die Open Grid Services Architecture, kurz
OGSA.
Werden nun all diese Ideen zusammengefasst, ein wenig
kombiniert und um einfache Schlüsse ergänzt, so sind die
Grundlagen für Autonomic Computing gelegt, wie es 2002
von IBM erklärt und definiert wurde. Hinzu kommen aller-
2.2. Typen von Fehlern
dings noch ein paar zusätzliche Techniken [17].
IBM sieht auch dringenden Bedarf für Autonomic Computing Computersysteme. Denn in der IT-Industrie wird
komplexeren Anforderungen traditionell durch komplexere Computersysteme begegnet [9]. Das funktioniert solange
die Komplexität der Computersysteme selber überschaubar
bleibt. Heutzutage ist das bei großen Computersystemen jedoch nicht mehr der Fall; und dennoch wächst die Komplexität der Computersysteme weiter. Der Grund von Seiten
der Hardware liegt beim Moore’schen Gesetz, dass noch eine Zeit lang steigende Rechenleistung für Hardware voraussieht.
Zudem wächst aufgrund des ständig breiteren Anwendungsfeldes von Computersystemen, die Verschiedenartigkeit der Computersysteme und Komponenten exponentiell
[2]. Schon heute wird deshalb eine „complexity crisis“ [9]
befürchtet. Damit ist eine Zeit gemeint, in der die Komplexität der Computersysteme selber das Problem ist – womit noch nicht die Zusammenarbeit von verschiedenartigen
Computersystemen gemeint ist. In großen Firmen existieren schon heute viele Computersysteme, die aufgrund ihrer
Komplexität schwer zu konfigurieren sind. Entsprechend
hoch sind die Betriebskosten, da die Mitarbeiter teilweise überfordert sind. Folglich kommt es immer häufiger zu
Fehlern in der Administration, die bei Servern schnell teure
Ausfallzeit nach sich ziehen können – im Falle einer Bank
würde ein 72 Stunden dauernder Totalausfall den Bankrott
bedeuten.
Gemäß ihrer Art stehen den einzelnen Fehlertypen entsprechende Wissenschaftler Pate für den Namen. So werden
reproduzierbar auftretende Fehler als Bohr-Fehler bezeichnet, deren Namensgeber Niels Bohr [1] durch das Bohr’sche
Atommodell [1] bekannt ist. Die Idee in diesem Atommodell ist, dass die Elektronen in einem Atom fest vorgeschriebene Bahnen verfolgen und somit zu jedem Zeitpunkt ihr
Aufenthaltsort bestimmbar ist. Im Sinne der Fehlertypen
sind Bohr-Fehler somit reproduzierbar.
Darüber hinaus werden zufällig auftretende Fehler als
Heisenberg-Fehler bezeichnet. Hier wurde Werner Heisenberg [1] zum Namensgeber, da die Heisenberg’sche Unschärferelation [1] bei Atomen folgendes aussagt: Zu einem Zeitpunkt, zu dem die Position eines Elektrons in einem Atom gemessen wird, ist sie schon durch die Messung
verändert; Heisenberg-Fehler sind somit nicht reproduzierbar.
Der Chaostheoretiker Benoît Mandelbrot [1] wurde zum Paten der reproduzierbar und scheinbar zufällig auftretenden
Fehler, der Mandel-Fehler. Der Grund für die Namenwahl
ist in seinen Arbeiten zur Chaostheorie [1] zu finden.
Zuletzt gibt es noch Fehler, die eigentlich nur bei einer
Code-Inspektion gefunden werden und in dead-Code [10]
vorhanden sind. Folglich werden die Codestellen zur Laufzeit niemals ausgeführt und produzieren keine Fehler. Diese Fehler wurden nach Erwin Schrödinger [1] benannt. Er
hat in dem Gedankenexperiment die „tote Katze“ [1] gezeigt, dass eine Katze sozusagen tot und lebendig sein kann;
analog existiert der Schrödinger-Fehler und existiert doch
nicht.
Für die Belange des Autonomic Computings sind die Bohrund die Mandelbrot-Fehler relevant — eine Übersicht der
Fehlertypen liefert Tabelle 1.
2. Fehlerarten und deren Klassifizierung
Für die Diskussion von Autonomic Computing ist es
sinnvoll, sich zunächst Gedanken über mögliche Fehlerarten und deren Klassifizierung zu machen; denn diese Klassifizierung ermöglicht später Entscheidungen oder nicht.
2.1. Motivation
Tabelle 1. Fehlertypen
Bezeichnung
Auftreten
Bohr-Fehler
reproduzierbar
Heisenberg-Fehler
nicht reproduzierbar
Mandel-Fehler
reproduzierbar, scheinbar zufällig
Schrödinger-Fehler tritt nicht auf
Zunächst lohnt ein Blick auf die möglichen Typen von
Fehlern sowie deren Klassifizierung. Insbesondere ist diese
Klassifizierung von Relevanz, sollen doch Autonomic Computing Computersysteme später auch auf unvorhergesehene
Fehler angemessen reagieren können. Das ist ganz besonders dann einfach möglich, wenn die auftretenden Fehler
von einem gewissen Typ sind.
Leider sind viele Fehler durch falsche Konfigurationen verursacht. Entsprechend groß erscheint das Optimierungspotential in diesem Bereich. In einzelnen Schätzungen [9]
wird gar behauptet, dass bis zu 40 Prozent der auftretenden Fehler mangelhafter Konfiguration zuzuordnen sind.
Dementsprechend könnten diese Fehler zu einem großen
Teil durch geeignete Konfigurationswerkzeuge und Automatisierung vermieden werden.
2.3. Fehlermodelle
Fehler können in Computersystemen verschiedene Auswirkungen erzielen. Bei stop-Fehlern [3] wird eine Exception ausgegeben und die Anwendung arbeitet weiter, sofern
es möglich ist. Insbesondere ist es bei diesen Fehlern oft
möglich die System- und Laufzeitparameter zu bestimmen
und eine detaillierte Fehlerdiagnose durchzuführen. Bei
F-2
crash-Fehlern [3] stürzt die Anwendung soweit ab, dass sie
nicht mehr reagiert. In diesem Falle kann nur sehr schwer
eine weitere Diagnose erfolgen. Ein Beispiel für crashFehler sind die blue-screens der MS-Windows Betriebsystemfamilie. Außerdem gibt es noch die byzantinischenFehler [3], die zufällig auftreten. Hier wird der Fehler im
ersten Moment nicht bemerkt. Allerdings treten mit der Zeit
unerwünschte Nebenwirkungen auf, die durch diesen Fehler verursacht werden; entsprechend schwer sind diese Fehler zu finden.
Bei Rückwärtsbehebung wird nach einem festgestellten
Fehler zum letzten gültigen Punkt zurückgekehrt. Von dort
aus werden dann die Berechnungen erneut durchgeführt.
Dieses Vorgehen ist bei Datenbanken üblich, wo ein Rollback zum letzten Checkpoint möglich ist. Dann können auf
diese Daten aufsetzend die anschließenden, protokollierten
Transaktionen wiederholt werden.
2.5. Fehlervorhersage und Vorbeugung
Teilweise sind durch Trendanalysen von Prozessen Fehlervorhersagen möglich. Per Betrachtung von Abhängigkeiten zwischen System- und Laufzeitparametern lassen
sich Schlüsse über das Verhalten des betrachteten Prozesses
ziehen. Besonders wichtig sind bei diesen Trendanalysen
die jüngere Vergangenheit und die Abhängigkeiten zu anderen Prozessen. Diese können per Abhängigkeitsgraphen
modelliert werden. Diese Aspekte können zusammen mit
der Betrachtung der Kommunikationsabhängigkeiten gute
Fehlervorhersagen liefern.
Wird dann ein Fehler vorausberechnet, so tritt die Fehlerprävention ein. Je nach Anwendung und Computersystem
können verschiedene Maßnahmen zur Abwendung getroffen werden. Z.B. kann die Speicherbereinigung aktiviert
werden oder ein Fallbacksystem genutzt werden, ebenso
könnte das Load Balancing geändert werden.
2.4. Fehlerbehandlung
Vor der Fehlerbehandlung steht die Fehlerdiagnose, die
einen Fehler möglichst einem Modell zuordnet. Auf die
Fehlerdiagnose soll hier nicht weiter eingegangen werden,
da dieser Aspekt beim Autonomic Computing eine besondere Rolle einnimmt.
Bei der Fehlerbehandlung hingegen ist es günstig, wenn als
Basis im Computersystem ein gewisser Grad an Redundanz
vorhanden ist. Hier läßt sich Redundanz in zwei Dimensionen unterscheiden [16]. Einerseits gibt es die physikalische
Redundanz. Sie liegt wor, wenn Hardware oder Software
mehrfach vorhanden ist. Andererseits gibt es zeitliche Redundanz. Sie liegt vor, wenn Berechnungen mehrfach durchgeführt werden.
Beim Begegnen von Fehlern ist der erste Schritt die Fehlerkompensierung, wobei die bekannten Fehlertoleranzverfahren eingesetzt werden. Dazu zählen u.a. Korrekturcodes,
Fehlermaskierung durch Mehrheitsentscheidungen usf. [7],
desweiteren kann sog. Fehlerausgrenzung betrieben werden. Eine einfache Möglichkeit wäre, die fehlerhafte Komponente durch Rekonfiguration des Systems zu entfernen.
Problematisch kann das Verlagern eines Prozesses auf ein
anderes Computersystem sein. Denn meist sind verteilte Systeme von heterogener Struktur. Deshalb kann schon die
Architektur des anderen Computersystems ein Problem darstellen. Falls nicht, so ist es dennoch recht wahrscheinlich,
dass die Systemumgebung von dem ursprünglichen System
abweicht.
Wurden bislang hauptsächlich Fehler betrachtet, die durch
Hardware bedingt sind, so lassen sich softwarebedingte
Fehler durch Vorwärtsbehebung [7] (Kap. 7) oder Rückwärtsbehebung [7] (Kap. 6) behandeln. Im ersten Fall wird
bei einem festgestellten Fehler u.U. nur eine Interpolation aus bisherigen Ergebnissen errechnet. Das kann sinnvoll
sein, weil evtl. keine Zeit für aufwendige Neuberechnungen ist. So kann die Positionsbestimmung eines Flugzeugs
bei kurzzeitig fehlerhaften Berechnungen aus der bisherigen Position, der Flugbahn und der Geschwindigkeit die aktuelle Position ermittelt werden. Aus offensichtlichen Gründen sollte diese Interpolation nicht lange fortgesetzt werden.
3. Grundlagen des Autonomic Computing
Als Anforderungen an Hochverfügbarkeitssysteme werden i.a. die Reaktionszeit, die Sicherheit, die Verfügbarkeit und die Zuverlässigkeit genannt. Diese Anforderungen
sind nicht allgemein definierbar und werden deshalb entsprechend den Anforderungsspezifikationen individuell für
ein Projekt festgelegt. Häufig ist dabei ein gewisser Kompromiss zwischen diesen Faktoren vonnöten.
3.1. Die Vision des Autonomic Computing
Trotzdem geht die Vision des Autonomic Computings
von diesen Begriffen aus und beläßt sie als Grundlage abstrakt – immerhin handelt es sich beim Autonomic Computing um ein Modell für Eigenschaften von Computersystemen, das von IBM entwickelt wurde. Der Begriff Autonomic Computing ist von IBM mit Bedacht gewählt und
soll sich an den Begriff des autonomen Nervensystems anlehnen. Der Hintergrund ist, dass der menschliche Körper
gewisse Vorgänge, wie das Atmen, den Herzschlag, den
Lidschlag usf. dem Bewußtsein weitgehend entkoppelt hat.
Stattdessen kann sich das Bewußtsein den wesentlichen
Herausforderungen einer Situation widmen. So ist es dem
Menschen einerseits möglich das Bewußtsein explizit der
Atmung zu widmen und „tief durchzuatmen“; dadurch wird
F-3
1.2
6
das Atmen zur Handlung. Andererseits ist es ihm möglich
äquate Lösungen mit Prioritäten versehen. Beispielsweise
bei sportlichen Aktivitäten die Atmung zu steigern, ohneist es gewöhnlich unakzeptabel ein Computersystem zu eidass
die Aufmerksamkeit
Sportlers
erfordert.
less es
vulnerable
to attacks on its des
runtime
infrastructure
and business data.ner
A Zeit neuzustarten, in der die Last traditionell hoch ist.
self-protecting
IT environment
can detect
or intrusive
behavior as Deshalb
it
Auf
Computersysteme
übertragen
sollhostile
sich ein
Administrawird diese Aktion möglichst in Zeiten geringer
occurs and take autonomous actions to make itself less vulnerable to
tor
nicht mehr um die alltäglichen Probleme eines ComLast verlegt. Damit das Computersystem bis dahin weiunauthorized access and use, viruses, denial-of-service attacks, and general
putersystems
kümmern müssen. Speicherengpässe, Geterhin akzeptabel arbeitet, kann zusätzlich vorgeschrieben
failures.
schwindigkeitsprobleme o.ä. sollen Computersysteme aufsein, dass ein Speicherbereich vergrößert, ein Teildienst
bauend auf einer Wissensbasis selber lösen können. Ist ein
ausgelagert oder ein ganzer Prozess auf ein anderes ComProblem nicht
von dem Computersystem
putersystem verlagert wird.
Autonomic
computing
concepts lösbar, so wird es
an den Administrator weitergeleitet.
In an autonomic environment, components work together, communicating with
Entsprechend
Autonomic
Computing
Computersy3.2. Definition des Autonomic Computings
each other and sollen
with high-level
management
tools. They
can manage or control
steme
die Administratoren
themselves
and each other. entlasten, indem sie sie durch
Tools unterstützen und Routineaufgaben sogar komplett
Components can manage themselves to some extent, but from an overall Um Autonomic Computing definieren zu können, muss
übernehmen.
Diese Anstrengungen sind durchaus gerechtsystem standpoint, some decisions need to be made by higher-level components
es genauer in den wissenschaftlichen Kontext eingebettet
fertigt,
doch bei trade-offs
Routineaufgaben
nicht that
selten
that canpassieren
make the appropriate
based on policies
are in place.
werden. Dort wird das Autonomic Computing in den BeFehler. Doch die Vision des Autonomic Computing geht
Let us start by looking at how a single entity is managed in an autonomicreich der self-managing Computersysteme und der selfüber
die Routineaufgaben hinaus und setzt das Ideal auch
environment. Figure 1-2 represents the control loop that is the core of thegoverning Computersysteme eingeordnet; eben genau in
auf
unerwartete
Probleme Lösungen zu finden.
autonomic architecture.
den Bereich, der durch künstliche Intelligenz gesteuerten
Computersysteme und somit in den Kontext von Projekten
wie ELIZA [18]. Autonomic Computing sollte dabei nicht
Autonomic Manager
verwechselt werden mit Autonomous Computing oder Systemen die KI einsetzen.
Analyze
Plan
Im einzelnen fordert Autonomic Computing nach [12] (Seite
4) an ein Computersystem, dass es vier Kernmerkmale erfüllt: es muss self-configuring, self-healing, self-optimizing
und self-protecting sein. Häufig wird in diesem Fall dann
Knowledge
Monitor
Execute
von einem self-CHOP Computersystem gesprochen.
3.3. Bedeutung der Kernmerkmale
Managed Resource Touchpoint
Sensors
Effectors
Gewöhnlich bestehen Computersysteme aus vielen Teilbausteinen. Entsprechend übertragen sich die Eigenschaften
des Autonomic Computings in einem bottom-up Prozess
von Autonomic Elementen (je gemäß Abbildung 1) zu Autonomic Computing Computersystemen, falls alle Elemente die Kernmerkmale erfüllen. Dazu ist es wichtig, dass sich
die Elemente selbst „kennen“ (know-itself Eigenschaft), also über ihren eigenen Status genügend Informationen besitzen (Sensors in Abbildung 1).
Ein Computersystem ist nach [12]
Managed Resource
Figure 1-2 Autonomic computing control loop
Abbildung 1. Zusammenhaenge nach [12]
Die grundlegenden Ideen zum Autonomic Computing
haben sich aus den Ideen aus Abschnitt 1 entwickelt
oder wurden
abstrahiert.
SoTechnology
sind aus der AusfallProblem Determination
Usingdaraus
Self-Managing
Autonomic
sicherheit des Internets die Eigenschaften self-healing und
self-protecting geworden; wohingegen die Eigenschaften
des peer-to-peer Netzwerkes zu self-repairing und selfprotecting abstrahiert wurden. Weiterhin entwickelte sich
aus dem SETI@home Projekt die OGSA – und gerade die
OGSA ist fundamental für das Autonomic Computing, da
sie die Basis für heterogenes verteiltes Rechnen auf Grundlage von WebServices bietet.
Das Fundament von Autonomic Computing Computersystemen hingegen besteht aus einer Wissensbasis (Knowledge in Abbildung 1), die Entscheidungen ermöglicht. Dazu
wird eine Menge von Regeln (Policies) erstellt, die dem System Abhängigkeiten verdeutlichen und verschiedene, ad-
• self-configuring, wenn sich jede neue Komponente
automatisch in eine bestehende Umgebung einfügen
kann, ohnedass eine spezielle, manuelle Installation
nötig ist. Dieses Merkmal erfüllen heute bereits viele Komponenten: beginnend mit Plug ’n Play Erweiterungskarten über Hotplugging bei SCSI oder PCI Express, bishin zu PCMCIA, FireWire und USB.
• self-healing, wenn es selbständig Fehler entdecken
(Sensors und Monitor in Abbildung 1), diagnostizieren (Analyze in Abbildung 1) und beheben (Plan, und
Execute in Abbildung 1) kann. Dieses Merkmal erfüllt
F-4
z.B. das Internet im Bereich des Routings von Datenpaketen: fällt ein Netzwerkknoten aus, sucht sich ein
Paket einen anderen Weg zum Ziel.
• self-optimizing, wenn es seinen Kontext so anpassen
kann, dass die einzelnen Arbeitsprozesse besser ablaufen und dies auch regelmäßig versucht. Dieses Merkmal läßt sich z.B. durch dynamisches Speicherauslagern erfüllen. Wird der Speicher einer Anwendung
knapp, bekommt sie vom Betriebssystem zusätzlichen
Speicher zugewiesen. Ein weiteres Beispiel sind dynamische Dateisysteme.
Eine notwendige Voraussetzung für self-optimizing
Computersysteme ist die self-configuring Eigenschaft.
• self-protecting, wenn es selbständig Angriffe und
Schäden von Angriffen erkennen und beheben kann.
Methoden, wie Angriffe erkannt werden können, sind
z.B. Intrusion Detection o.ä. Schäden können hingegen
von Malwareeffekten bishin zu bösartigen Einbrüchen
in das Computersystem reichen.
Voraussetzung für self-protecting Computersysteme sind die Eigenschaften self-healing und selfconfiguring.
Eine Übersicht über die vier Kernmerkmale liefert die Abbildung 2.
SelfConfiguring
SelfHealing
SelfOptimizing
SelfProtecting
Figure 1-1 Autonomic computing attributes
Abbildung 2. Kernmerkmale
Self-configuring
Bis ca. 2002 hatten viele Hersteller ihre eigenen Standards
für Log-Dateien. Aus diesem Grund entwickelten IBM und
Cisco die CBEs (common base events). Ein Jahr später
schlugen IBM und Cisco der OASIS (Organization for the
Advancement of Structured Information Standards) vor die
CBEs zum Standard für Log-Dateien zu erheben. Da nun im
Rahmen des Autonomic Computing mit WebServices gearbeitet wird, wurde hieraus das WSDM 1.0 (WebService
Distributed Management) entwickelt, das seit März 2005
ein OASIS Standard ist. Zwischenzeitlich haben sich viele
große Hersteller von Hard- und Software diesen Standards
angeschlossen, darunter Microsoft, Oracle und SAP.
Aufbauend auf diese Standards, kann eine Wissensbasis nun
Entscheidungen über das System fällen. Die dafür notwendigen Policies, werden per UML modelliert und dann in
DLR transferiert. Bei DLR handelt es sich um eine Teilmenge von FO (first-order-logic), die mehrstellige Relationen zuläßt und im Gegensatz zu FO entscheidbar ist. Wichtig ist, dass sich alle UML-Modelle in DLR transformieren
lassen; das stellt [8] sicher. Die Entscheidungen aufgrund
einer Wissensbasis in DLR können dann mit verschiedenen
Verfahren (FaCT oder RACER, Details in [11]) getroffen
werden. Im Modell des Autonomic Computings wird einfach von „automated reasoning procedures“ gesprochen.
Somit können für sich autonomic Elements in ein größeres
Computersystem eingebunden werden und mit ihrem Anteil
zu den Policies weiterhin sicherstellen, dass die zusammengefügten Elemente ein Autonomic Computing Computersystem bilden.
3.5. Reifegrade zum Autonomic Computing
Vom heutigen Standpunkt aus stellt Autonomic Computing bei Computersystemen einen Idealfall dar. Deshalb
wurden von Beginn an von IBM Abstufungen an Reifegraden (maturity level) vorgeschlagen [9], bis tatsächliches
Autonomic Computing erreicht ist. Beginnend mit dem
Basic Level und dem Managed Level über Predicted Level
und Adaptive Level bishin zum Autonomic Level kann
demnach ein Computersystem fünf Reifegerade annehmen:
With the ability to dynamically configure itself, an IT environment can adapt
immediately, with minimal intervention, to the deployment of new•components
or kommerziellen Computersysteme befinDie meisten
3.4. Autonomic
Elements
changes in the IT environment.
den sich heute im Basic Level, d.h. alle Komponenten
werden voneinander getrennt administriert. EntspreDa das Self-healing
Autonomic Computing zur Umsetzung autonochend komplex und aufwendig wird die AdministraSelf-healing
IT environments
can detectzwischen
problematic
operations (either
mic Elements
benötigt,
ist Kommunikation
den
through
predictions
or otherwise) and kann
then initiate corrective
action
tion bei
steigender Anzahl von verschiedenen KompoElementen proactively
erforderlich.
Denn
ein Computersystem
without disrupting system applications. Corrective action could mean
that
nenten.a
nur dann self-configuring
sein,
wenn
es
ausreichende
Inproduct alters its own state or influences changes in other elements of the
formationen
über die Gegebenheiten
vorfinden
kann.
environment.
Day-to-day operations
do not
falterSomit
or fail because •of Werden
events at bereits
the
System-Management Tools eingesetzt,
component
IT environment
as a whole
more resilient as
ist eine weitere
Basislevel.
des The
Autonomic
Computings
derbecomes
Inum
Informationen der Computersysteme zentral zu
changes
are
made
to
reduce
or
help
eliminate
the
business
impact
of
failing
formationsaustausch zwischen Computersystemen in Form
sammeln, so wird vom Managed Level gesprochen.
components.
von Log-Dateien. Gewöhnlich werden jedoch verschiedene
Komponenten
verschiedenster Hersteller eingesetzt. Des• Bei zusätzlicher Auswertung der Informationen mit
Self-optimizing
halb ist fürSelf-optimization
die Analyse einheitliches
notwendig.
Hilfe
von Analysetools und dem Versuch aus den Inrefers to the Logging
ability of the
IT environment to efficiently
maximize
resource allocation and utilization to meet end users’ needs with minimal
intervention. In the near term, self-optimization primarily addresses the
complexity of managing system performance. In the longF-5
term, self-optimizing
components might learn from experience and automatically and proactively tune
themselves in the context of an overall business objective.
Self-protecting
A self-protecting environment allows authorized people to access the right data
• Verschiedene Typen von Dynamik führen zu verschiedenen Handlungsgeometrien
formationen mögliche Szenarien zu errechnen, ist der
Predictive Level erreicht. Eine übliche Beschreibung
findet sich auch in der Formulierung von „Was wäre Wenn“-Szenarien.
• Dynamik wird als Frequenz / Häufigkeit des Auftretens interpretiert
• Können die Computersysteme außerdem noch automatisiert auf die Szenarien reagieren, indem sie eine
Symptomdatenbank nutzen, handelt es sich um den
Adaptive Level.
• time-delay Graphen, in denen unterschiedliche Verhaltensmuster gesucht werden
• basierend auf Lyapunov-Exponenten werden Stärke
und Häufigkeit des Auftretens gewichtet
• Wird letztlich diese Symptomdatenbank schon während der Systemspezifikation komplett als Wissensbasis spezifiziert und sind Schlussfolgerungen daraus
möglich, so ist das Autonomic Level erreicht.
• Poincaré Graphen zur Messung der sog. fraktalen Dimension
4.3. dezentralisierte Kontrolle
4. Forschungsbereiche
Bei dezentralisierter Kontrolle (decentralized control)
wird versucht, eine optimale Struktur für große Computersysteme zu finden. Die Motivation dazu liegt darin, dass eine globale Wissensbasis nicht immer vorhanden sein kann
oder muss. Deshalb geht es in diesem Forschungsbereich
darum, wie Wissen redundant gehalten werden muss und
wie es aufgeteilt werden kann. Folglich müssen anhand der
jeweiligen Teilwissensbasis die folgenden drei Kernfragen
für ihre Komponenten beantwortet werden können:
Gerade beim Zusammenfügen jeweils für sich autonomic Elemente, tauchen Probleme auf, die gelöst werden
wollen. Aber nicht nur in diesem Bereich gibt es noch akuten Forschungsbedarf. Insgesamt läßt sich das aktuelle Forschungsinteresse in drei Gebiete unterteilen [5]. Das sind
die multi-agent Systeme, die Theorie dynamischer Systeme
und die denzentralisierte Kontrolle.
4.1. multi-agent Systeme
• Wie ist das erwünschte Verhalten?
Die Idee bei multi-agent Systemen ist es, einen alternativen Ansatz zur Modellierung des Computersystems zu finden. Dabei werden die Policies agentenbasiert (objektorientiert) modelliert, statt gleichungsbasiert. Das entspricht
der Vorstellung, sich die Interaktionen anzusehen, statt der
Algorithmen – abkürzend wird hier von agend-based model (ABM) und equation-based model (EBM) gesprochen.
Durch das Konzept der multi-agent Systeme können Sachverhalte modelliert und analysiert werden, die Algorithmen
nicht darstellen können. Das wird insbesondere klar, wenn
die self-adapting Eigenschaft beim Autonomic Computing
in Betracht gezogen wird.
• Welche Parameter erzielen das gewünschte Verhalten?
• Durch welchen Kontrollmechanismus wird es erzielt?
Um die dezentralisierte Kontrolle nun als minimal und
ausreichend zu erachten, werden fünf Kriterien herangezogen, die alle zu erfüllen sind [4]. Zunächst wird nach der
Kontrollierbarkeit des Computersystems gefragt. Das kann
insbesondere bei großen Computersystemen eine komplexe
Fragestellung sein. Außerdem wird nach den Grenzen
gefragt, da gewisse Systemparameter das gewünschte
Verhalten beeinflussen können. Desweiteren steht die Stabilisierung des Systemverhaltens zur Disposition, wie sie
auch bei der Theorie dynamischer Systeme [20] betrachtet
wurde. Hier kommen allerdings noch Störungen und lokale
Handlungen hinzu, die das Systemverhalten beeinflussen
können.
Als konkreter Ansatz läßt sich z.B. ein marktorientiertes
Modell realisieren, wobei die Zusammenhänge der Marktwirtschaft auf die dezentralisierte Kontrolle übertragen
werden. So wird den einzelnen Komponenten eine speziell
definierte Gesundheit zugeordnet, die in direktem Zusammenhang zu ihrer internen Struktur steht. Entsprechend
verkörpern sie eine gewisse Energie auf dem virtuellen
Marktplatz. Anhand dieser werden sie als Dienstleister
ausgewählt oder nicht.
Alternativ gibt es einen „blue-print“ Ansatz, der sich
4.2. Theorie dynamischer Systeme
In der Theorie dynamischer Systeme (dynamical systems
theory) wird versucht die Ordnung und die Dynamik der
Computersysteme zu modellieren und zu analysieren. Die
Computersysteme werden anhand der sog. system model
theory [19] modelliert und dann analysiert. Als Grundlage
der Analyse dienen Erkenntnisse aus der Chaostheorie (z.T.
Quantenphysik) und der Komplexitätstheorie. Ein zentrales Problem in diesem Teilbereich ist die Frage nach einer
geeigneten Metrik. Derzeit gibt es diverse Techniken, die
Ergebnisse zu analysieren. Darunter befinden sich folgende
Ansätze, die hier nur genannt sein sollen (Details jeweils in
[19]):
F-6
wiederum in drei verschiedene Ansätze unterteilt. Zunächst
gibt es den Ansatz der expliziten Präsenz, d.h. ein „Dienst“
bestimmt selber sein Vorhandensein auf dem virtuellen
Markt. Als nächstes gibt es einen Ansatz, bei dem ein
zentraler Koordinator explizit die Zuweisung übernimmt
- und als letztes einen Ansatz, bei dem die Propagation
von Informationen die zentrale Rolle spielt. Hier ist jeweils
bekannt, wie es um den eigenen „Nachbarn“ steht.
Darüber hinaus läßt sich dezentralisierte Kontrolle noch
mit vielen weiteren Ansätzen realisieren. Dazu gehören:
auf Beschränkungen basierende dezentralisierte Kontrolle,
genetische bzw. evolutionäre dezentralisierte Kontrolle,
dezentralisierte Kontrolle über künstliche physikalische
Kräfte und Gesetze und dezentralisierte Kontrolle über sich
anpassende Organisationen.
Autoren als BCT (behaviour capture and test) [13] bezeichnet.
Auf die BCT Methode aufbauend, läßt sich die ARV (adaptive runtime verification) [6] entwickeln, die die obigen
Annahmen bzgl. unvorhersehbarer Fehler fallen läßt. Das
wird möglich, indem die möglichen Fehler in die Kommunikationsstruktur eingebettet werden. Dadurch ist nun das
Modellieren der endlichen Automaten adaptiert und somit
zur Laufzeit das Erstellen der Modelle möglich. Das Testen
verläuft dann analog zu BCT.
Ein wesentliches Problem bei diesen beiden Verfahren ist,
dass teilweise mit genauer Betrachtung von Referenzen gearbeitet werden muss. Dementsprechend sind diese Ansätze
nicht black-box und erfordern deshalb genauere Untersuchungen bzgl. der Sicherheit der einzelnen Komponenten.
Grundlage für die Methoden ist, dass die Log-Dateien einheitlich, also z.B. als CBE, vorliegen.
Insgesamt ergibt sich somit folgende Übersicht über die
aktuellen Forschungsgebiete:
6. NASA Missionen
Tabelle 2. Forschungsgebiete
Bezeichnung
Anwendungsbereich
multi-agent Systeme
Modellierung des Systems
Theorie dyn. Systeme
Analyse des Systems
dezentralisierte Kontrolle Kontrolle des Systems
Autonomic Computing stellt in der Raumfahrt einen
dringenden Bedarf dar. Denn dort ist es nicht immer
möglich, Kontakt zu Raumschiffen, Satelliten o.ä. zu
halten. Trotzdem müssen diese auch ohne Kontakt zum
Kontrollzentrum funktionsfähig bleiben. Sind bei einem
Raumschiff noch die Besatzungsmitglieder vorhanden, die
einen Teil der Entscheidungen übernehmen können, so
ist das z.B. bei der Raumsonde Voyager etwas anderes.
Schon alleine die Übertragung der Informationen zwischen
der Sonde und dem Kontrollzentrum dauert so lange, dass
kurzfristige Entscheidungen nicht vom Kontrollzentrum
aus gegeben werden können. Trotzdem können unerwartete
Fehler auftreten, die behandelt werden müssen.
Entsprechend hoch ist das Interesse der NASA [14] an
der Forschung im Bereich der self-governing und selfmanaging Computersysteme also Autonomic Computing.
Am Beispiel der Raumfahrt lassen sich zudem die vier
Kerneigenschaften des Autonomic Computings erläutern:
5. Laufzeitverifikation
Um eine Laufzeitverifikation von Elementen eines Computersystems zu erzielen, wird zunächst ein Modell für eine
feste Anzahl an möglichen Fehlern betrachtet. Somit können während der Laufzeit keine unvorhergesehenen Fehler
auftreten. Deshalb kann bereits vorab analysiert und modelliert werden, wie sich alle möglichen Fehler auswirken können. Dazu werden ausgehend von gesammelten Log-Daten
Invarianten im I/O- und Interaktionsverhalten gesucht. Die
Invarianten für das I/O-Verhalten können durch Beschreiben der Referenzen einer Komponente per boolescher Variablen erfolgen. Beim Interaktionsverhalten ist die Analyse hingegen schwieriger. Da allerdings per Annahme keine
unvorhergesehenen Fehler auftreten, läßt sich das Interaktionsverhalten zwischen Komponenten durch endliche Automaten beschreiben. Diese werden in einem rekursiven Ansatz erstellt – in [13] wird dafür ein Algorithmus namens
kBehaviour vorgeschlagen.
Sind nun die Invarianten formuliert, läßt sich beim Austausch von Komponenten einfach durch duales Verfolgen
der Läufe auf den Automaten feststellen, ob die neuen Komponenten das gewünschte Verhalten zeigen. Da dieser Test
in zwei Phasen, dem Protokollieren von Log-Dateien und
dem Ableiten des Verhaltens der Komponente sowie dem
anschließenden Test besteht, wird dieses Verfahren von den
• self-configuring: In der Raumfahrt ändern sich die Bedingungen ständig und somit müssen sich die Gerätschaften ständig anpassen.
• self-optimizing: Die Satellitenpositionen werden automatisch aufeinander abgestimmt und liefern zusammen genauere Ergebnisse.
• self-healing: Funktioniert Software aufgrund von
Strahlung nicht mehr richtig wird sie neugestartet.
• self-protecting: Strahlung von Sonnenerruptionen wird
vorausberechnet und sensible Systeme werden zum
Schutz heruntergefahren und ausgeschaltet.
F-7
7. Fazit
[4] De Wolf, Tom , Samaey, Giovanni, Holvoet, Tom, and Roose, Dirk. Decentralised Autonomic Computing: Analysing
Self-Organising Emergent Behaviour using advanced numerical Methods. In Proceedings of the First International
Workshop on Autonomic Computing Principles and Architectures, 2005.
[5] De Wolf, Tom and Holvoet, Tom. Towards Autonomic Computing: agent-based modelling, dynamical systems analysis,
and decentralised control. In Proceedings of the First International Workshop on Autonomic Computing Principles and
Architectures, page 10, 2003.
[6] Denaro, Giovanni, Mariani, Leonardo, Pezze, Mauro,
and Tosi, Davide.
Adaptive Runtime Verification
for Autonomic Communication Infrastructures.
citeseer.ist.psu.edu/729269.html, 2005.
[7] Echtle, Klaus. Fehlertoleranzverfahren. Springer-Verlag,
1990.
[8] Franconi, Enrico.
Description Logics for Conceptual
Design, Information Access, and Ontology Integration.
http://www.ontoquery.dk/phd-course/franconi.pdf, 2002.
[9] Ganek, A. G. and Corbi, T. A. The Dawning of the Autonomic Computing Era. IBM Systems Journal, 42 Vol 1:5–18,
2003.
[10] Indermark, Klaus. Programmanalyse und Compileroptimierung, 2004.
[11] Lanfranchi, G., Della-Peruta, P., Perrone, A., and Calvanese,
D. Toward a new Landscape of Systems Management in an
Autonomic Computing Cnvironment. IBM Systems Journal,
42 Vol 1:119–128, 2003.
[12] Manoel, Edson, Nielsen, Morten Jul, Salahshour, Abdi,
Sampath, Sai K.V.L., and Sudarshanan, Sanjeev. Problem
Determination Using Self-Managing Autonomic Technology. IBM, 2005.
[13] Mariani, Leonardo and Pezze, Mauro. Behavior Capture and
Test: Automated Analysis of Component Integration, 2005.
[14] Rouff,
Christopher,
Hinchey,
Michael,
Rash,
James,
Truszkowski,
Walter,
and
Sterritt,
Roy.
Autonomicity
of
NASA
Missions.
http://csdl.computer.org/comp/proceedings/icac/2005/2276
/00/22760387.pdf, 2005.
[15] Tannenbaum, Andrew S. Computer Networks. Prentice Hall
PTR, 2002.
[16] Tannenbaum, Andrew S. Distributed Systems - Principles
and Paradigms. Prentice Hall PTR, 2002.
[17] D. M. M. Waldrop. Autonomic Computing - The Vision of
Self-Management, 7 2003.
[18] Weizenbaum, Joseph. ELIZA - A Computer Program for the
Study of Natural Language Communication between Man
and Machine, volume 9. Communications of the ACM,
1966.
[19] Whisnant, K., Kalbarczyk, Z. T., and Iyer, R. K. A System
Model for dynamically reconfigurable Software. IBM Systems Journal, 42 Vol 1:45–59, 2003.
[20] Wischy, M. A. (Siemens) and Roller, D. , (University
of Stuttgart). Cybernetics and General Systems Theory
(GST) Principles for Autonomic Computing Design.
http://csdl.computer.org/comp/proceedings/icac/2005/2276
/00/22760389.pdf, 2005.
Wie der Überblick zeigt, ist Autonomic Computing einerseits eine phantastische Vision [17], aber andererseits
bedarf es noch sehr viel Forschung, um es bzw. sie zu verwirklichen. Sind die Ansätze zur künstlichen Intelligenz
Anfang der 80er Jahre noch gescheitert, weil die Ideale zu
ehrgeizig waren, erscheint die Vision des Autonomic Computing, auf die Ideen der Zeit aufbauend, letztlich doch realisierbar.
Insgesamt ist es auch nicht Ziel des Autonomic Computings die Administratoren vollständig zu ersetzen, wie es
bei Ideen der künstlichen Intelligenz beabsichtigt war. Vielmehr sollen sie sich auf die wesentliche Arbeit konzentrieren können und die Routineaufgaben, die die Tools erledigen, nur noch überprüfen.
Doch genau da entsteht ein neues Problem. Denn der
Mensch ist ein sehr schlechter passiver Beobachter. Was
allgemein als das „Autonomation Paradoxon“ bezeichnet
wird, bedeutet nichts anderes, als dass die Fehlerrate beim
Überprüfen automatisch generierter Ergebnisse schlechter
sind, als hätte derjenige aktiv an dem Ergebnis mitgearbeitet – und letztlich erscheint ein Pilot, der vom Kontrollieren
gelangweilt, die entscheidende Warnmeldung übersieht als
wenig erstrebenswert.
Darüber hinaus wird, trotz aller Maßnahmen, das Autonomic Computing fehlender Hardware nicht entgegenwirken
können. So wird es auch bei optimal realisiertem Autonomic Computing noch zum traditionellen Ausfall der Handynetze in Deutschland und BeNeLux um die Jahreswende kommen, weil einfach zu viele SMS verschickt werden
und dadurch die SMS-Proxy-Server der Mobilfunkanbieter
hoffnungslos überlastet sind.
8. Danksagung
Ich möchte den drei Reviewern für ihre Mühe, Anmerkungen und Hinweise sehr danken. Ein ganz besonderer
Dank geht an Matthias Botzen und Christian Brüffer für
ihre schier endlose Mühe, ihre zahlreichen Hinweise,
Kritikpunkte und endlose Diskussionen über Sprache und
Ausdruck.
Literatur
[1] Brockhaus. Enzyklopädie in 24 Bänden, 20. neubearbeitete
Auflage. F.A. Brockhaus AG, Mannheim, 2001.
[2] Chess, D. M., Palmer, C. C., and White, S. R. Security in an
Autonomic Computing Environment. IBM Systems Journal,
42 Vol 1:107–118, 2003.
[3] Coulouris, George, Dollimore, Jean, and Kindberg, Tim.
Distributed Systems: Concepts and Design, Third Edition.
Pearson Education, 2001.
F-8