ACT / PMAC

ACT / PMACACT / PMACVortrag zum Seminar

„Aspekte und Werkzeuge der Datenbankadministration und deren

Automatisierung“

Martin Schmidt

Vortrag ACT / Vortrag ACT / PMACPMAC

GliederungGliederung

1. Einleitung

2. Autonomic Computing Toolkit1. Grundlagen und Konzepte

2. Architektur des ACT

3. Problem Determination 1. Standartisierung durch Common Base Events

2. Generic Log Adapter

3. Log and Trace Analyzer

4. Ressource Models

5. Autonomic Managment Engine

6. Zusammenspiel der Komponenten


Gliederung (II)Gliederung (II)4. Solution Installation & Deployment

1. Installable Units2. Komponenten für den Umgang mit IU´s3. Installation Registration & Database4. Zusammenspiel der Komponenten

5. Common System Administration6. Szenarios- mitgelieferte Testumgebungen

3. PMAC1. Begriffsklärung – Was ist PMAC?2. Funktionsweise

1. Policies – Aufbau und Verwendung2. Tools im Umfeld von Policies3. Der Autonomic Manager4. Zusammenspiel und Prozesse


Gliederung (III)Gliederung (III)

3. Erstellung und Bearbeitung von Policies1. Autonomic Policy Language

2. Policy Templates / Simplified Policy Language

4. Vergleich von ACT und PMAC


1. Einleitung1. Einleitung

Vorstellung zwei aktueller Forschungsergebnisse von IBM auf dem

Gebiet des Autonomic Computing

Konkrete Umsetzungen der IBM - Referenzarchitketur

IBM

ACT PMAC

•gehört zur IBM Computing Initiative

•3 nötige Installations - Einheiten

•Download auf alphaworks

•Aufteilung in viele versch. seperate Bundles

•Download auf den IBM developer - Seiten


2.1 Grundlagen und Konzepte2.1 Grundlagen und Konzepte

• Basiert auf dualem Konzept von „Managed Resources“ und „Autonomic Managers“

• Kontrollschleife• Touchpoints


2.2 Architektur des ACT (I)2.2 Architektur des ACT (I)

• Autonomic Computing Toolkit– Aktuelles Ergebniss der Forschung von IBM

(seit 1991) im Bereich Autonomic Computing– Sammlung von „self managing“ - Technologien– 3 Hauptbereiche

• Problem Determination(Self-Healing & Self-Optimizing)

• Solution Installation & Deployment(Ziel: Self-Configuring)

• Common System Administration(Userinterface)


2.2 Architektur des ACT (II)2.2 Architektur des ACT (II)

ACT kann unterteilt werden in:• Technologien

• Tools

• Szenarios

• Dokumentation und Information

Übersicht Komponenten:


2.3. Problem Determination 2.3. Problem Determination

2.3.1 Standartisierung durch Common Base Events

– kein einheitliches Logfile - Format– CBE-Format: allgemeines, vereinheitlichtes Format für

Logging im Umfeld des Autonomic Computing; aus XML-Strukturen

– Einteilung in 3 Attributkategorien.• Identifizierung der fehlermeldenden Komponente

• Identifizierung der Komponente bei der der Fehler auftrat

• Beschreibung des Problems selbst


2.3. Problem Determination2.3. Problem Determination

2.3.1 Standartisierung durch Common Base Events (II)



2.3.2 Generic Log Adapter

– Konvertierung von Logfiles ins Common Base Event Format

– Regeln zur Konvertierung müssen festgelegt werden

– 2 Komponenten:• Rule Editor: Festlegung der Regeln

• Laufzeitumgebung

– Vorteil:Bereits bestehende Logfile – Formate

können verwendet werden Ressource muß nicht angepasst werden



2.3.3 Log and Trace Analyzer

– Einfache Implementierung eines Autonomic Managers

– Empfängt Common Base Events Informationen vom Touchpoint der Ressource Überwachung und Analyse

– Beinhaltet „log-analysis engine“ welche durch Zugriff auf eine Symptom-Datenbank (die aus XML-Files besteht) mögliche Lösungswege für bestimmte Events bereithält

– Erstellung eigener Symptom-Datenbanken durch Tool



2.3.4 Ressource Models

– Definition wie Ressource überwacht wird Kapselung von Informationen

– Beschreibung der Ressource mit Attributen, welche Verfügbarkeit & Performanz charakteriesieren

– Festlegung von Grenzwerten Generierung eines Events bei Überschreitung

– Müssen in Autonomic Management Engine installiert werden

– Erstellung neuer Ressource Models im Ressource Model Builder (Entwicklung von Tivoli ) siehe späteren Vortrag



2.3.5 Autonomic Management Engine (I)

• Implementierung eines Autonomic Managers• Enthält die 4 Teile der Kontrollschleife (MAPE)• „handelt“ anfallende Events• Ausführungsumgebung für

Entscheidungsfindungsalgorithmen, führt auf Grund von Events Aktionen an Ressourcen durch

• Algorithmen werden in Intervallen gestartet



2.3.5 Autonomic Management Engine (II)

Verwendung eines Ressource Models in der AME



2.3.6 Zusammenspiel der Komponenten


2.4. Solution Installation und Deployment2.4. Solution Installation und Deployment

2.4.1 Installable Units (I)

IU

DeskriptorDeskriptor Artefakt(e)Artefakt(e)

Einheit, die in einem System installiert wird um ihm neue Eigenschaften zu geben

XML-Datei

Informationen über Inhalt der IU

Abhängigkeiten

Softwareprodukte

Java Applikationen

Datenbank-kommandos

oder


2.4. Solution Installation und Deployment2.4. Solution Installation und Deployment

2.4.4 Zusammenspiel der Komponenten

DeploymentDescriptor

DependencyChecker

Registration

InstallationDatabase

Touchpoints

-Definition von IU´s

-Definition von Voraussetzungen + Abhängigkeiten

Registriert IU´s + listet Abhängigkeiten auf


2.5. Common System Administration2.5. Common System Administration

– Notwendigkeit des Interagierens mit dem System Integrated Solutions Console

– Integrated Solutions Console Toolkit Entwicklungsumgebung um Integrated Solutions Console Plugins zur erstellen

• Hauptplattform für administrative Funktionen

• browser-basierte Konsole

• basiert auf IBM WebSphere Portal


2.6 Szenarios- mitgelieferte Testumgebungen2.6 Szenarios- mitgelieferte Testumgebungen

– Typische Anwendungsszenarien– Demonstration der Zusammenarbeit der Komponenten

– Problem Determination Scenario:• Zeigt Möglichkeiten der Selbstheilung in autonomer

Umgebung

• Überwachung eines Application Servers von AME

• Ausfall und Neustart des Servers wird simuliert

– Solution Installation & DeploymentScenario

• Installation einer simplen Applikation wird demonstriert

• Ziel: möglichst wenige Benutzereingriffe beim Installationsprozess


3.1 Was ist PMAC?3.1 Was ist PMAC?

– Managment Infrastruktur für Autonomic Computing

– Standardmodell für die Definition von Policies– System um Policies zu erstellen und zu

bearbeiten – Ziele:

• Strukturierung eines konsistenten Policy – Systems• Erstellung von Policies• Verwaltung• Steuerung der Verteilung• Einhaltung überwachen• Kontinuierliche Verbesserung der Policies


3.2 Funktionsweise3.2 Funktionsweise

3.2.1 Policys – Aufbau und Verwendung (I)(Richtlinie, Methode, Taktik)

– Policies legen das Verhalten von Managed Ressources fest

– Sammlung von Überlegungen zur Entscheidung über Handlungsabläufe einfache oder komplexe Serie von Events

– Arten:• Action –• Goal –• Result – • Configuration -



3.2.1 Policies – Aufbau und Verwendung (II)

• Co-Existenz von mehreren Policies in jedem System Konflikte können auftreten

• Verschiedene Standards zur Definition:• DMTF PCIM standard• OASIS eXtensible Access Control Markup Language

(XACML)• Web Services Agreement Specification (WS-

Agreement)• The Web Services Policy Framework (WS-Policy)

-> IBM hat aus diesen Standarts 4 Hauptelemente identifiziert



3.2.1 Policies – Aufbau und Verwendung (III)

• The standard-4-tuple– Themenbereich (Scope)– Bedingung (Condition)– Priorität (business value)– Entscheidung (desicion)



3.2.2 Tools im Umfeld von Policies

– Policy Editor Storage

– Editing Tools

– Policy Object Builder



3.2.3 Der Autonomic Manager

– implementiert MAPE – Managed die Ressourcen

– Bestandteile:• Autonomic Manager Libary • Rules Exression Engine • Event Monitoring Subcomponent • Policy Actuator Subcomponent • Data Gathering Subcomponent


3.2 Funktionsweise3.2 Funktionsweise3.2.3 Der Autonomic Manager (II)Verschiedene Arten der Kommunikation mit managed ressources



3.2.4 Zusammenspiel und Prozesse


3.3 Erstellung und Bearbeitung von Policys3.3 Erstellung und Bearbeitung von Policys

3.3.1 Die Autonomic Policy Language

– XML-basiert– Baut auf „Autonomic Computing Expression

Language“ auf– Erweiterungsfähig– Datentypen, Operatoren und Funktionen– Aufgebaut nach dem „4-tuple“

(Condition, Decision, Business Value, Scope)


3.3 Erstellung und Bearbeitung von Policys3.3 Erstellung und Bearbeitung von Policys3.3.2 Policy Templates / Simplified Policy Language

Templates vordefiniertes Policy-Model / Policy - Rahmen

Simplified Policy Language • Erstellung von Templates• Vorgefertigte, für den Menschen besser lesbare Syntax

Template { Header { General template information } Variable { Substitution variable information } Policy { Policy information } }


3.3 Erstellung und Bearbeitung von Policys3.3 Erstellung und Bearbeitung von Policys


4. Vergleich von ACT und PMAC4. Vergleich von ACT und PMAC

Großes Sammlung von ineinandergeifenden Komponenten mit mächtigem Funktionsumfang

Wenig Tools, beschränkter Funktionsumfang

Nicht alle Komponenten werden für jeden Anwendungsfalls benötigt, kein geschlossenes System

Komponenten bilden relativ geschlossenes System

Verwendung vieler untersch. Techniken beschränkt auf den Umgang mit Policies

Self-configuring, self-optimizing, self-healing Hauptaugenmerk: self-optimizing

Aufwendige Installation, schwierige Implementierung

Relativ einfach zu implementieren

Offene StandardsKomponenten können leicht verändert u. erweitert werden

hohe Flexibilität

Bildet „starres“ System

eingeschränkte Flexibilität

ACT PMAC

ACT / PMAC

Documents

Transcript of ACT / PMAC