Informatik
Theoretische
Informatik
Verteilte Systeme
Technische
Informatik
- Methoden u.
Werkzeuge
- System- u.
Anwendungskomponenten
- Qualitätssicherung
etc.
- Betriebs- Kaufmännische
systeme
Informations- Datenbank- systeme
systeme
- Technische
- KommuInformationsnikationssysteme
systeme
etc.
etc.
Grundlagen
Hardware
Methodenlehre
Basissoftware
Anwendungen
Abb2 in Informatik-Spektrum, Heft 25/1, S. 39-51, 2002: Erich Ortner, Sprachingenieurwesen, Empfehlung zur inhaltlichen Weiterentwicklung der (Wirtschafts-)Informatik
2
Lernziele
Laut Modulhandbuch für das Semester (16 Wochen):
– Vorlesung:
42h
– Praktika:
16h
– Eigenstudium:
126h
Anwendungen
der Informatik
- Rechnertechnologie
- Netze
etc.
Arbeitsaufwand
Praktische
Informatik
- Formale
Sprachen
- Abstraktionstheorie
etc.
Organisation
1
Konstruktionslehre
der Informatik
Grundlagen verteilter Systeme (VS) beherrschen (1. 2. 3.)
Eine System-Infrastruktur eines VS entwerfen und realisieren
können (5. 6.)
Eine Middleware eines VS entwerfen und realisieren können
(5. 6.)
Real (Feiertags bedingt) für das Semester (15 Wochen):
– Vorlesung/Woche:
3h (11 Termine)
– Praktika/3Wochen:
3h ( 4 Termine)
– Eigenstudium/Woche:
6,3h (15 Termine)
Hier 1h ≡ 60 Minuten, Im Modulhandbuch 1h ≡ 45 Minuten
Ein Konzept für replizierte Daten entwerfen und realisieren
können (5. 6.)
Verteilte Algorithmen entwerfen und realisieren können (5. 6.)
Möglichkeiten, Grenzen und Risiken verteilter Systeme
verstehen (4.)
3
Organisation der Veranstaltung
Inhalt der Vorlesung
www.informatik.haw-hamburg.de/~klauck/verteiltesysteme.html
1. Einführung und Systemmodelle
2. Interprozesskommunikation (IP, Client/Server,...,RMI)
3. Namensdienste
4. Zeit, Synchronisation und globale Systemzustände
5 Übereinstimmung und Koordination
5.
6. Verteilte Transaktionen
7. Replikation
8. Sicherheit: Angriff
9. Sicherheit: Verteidigung
4 Stunden (2 Viertel) pro Woche
– 4 Stunden Vorlesung (11 Termine)
Raum Stiftstr69 R304a
Donnerstag 1230-1545
– 4 Stunden (2 Viertel) Praktikum (4 Termine)
5
Raum 0765
Mittwoch 1230-1545, je nach Gruppenzugehörigkeit
– Prüfungsform: Klausur (90 min)
Wie üblich
– Vorlesung zur Vermittlung der theoretischen Grundlagen
– Praktikum zur praktischen Erfahrung
6
7
1
Terminplan
Datum
VL
08:15-11:30
Thema
25.03.
VL1
Organisatorisches, Einführung
26.03.
VL2
P-Aufgabe 1, Systemmodelle, IPC
01.04.
VL3
IPC
02.04.
VL4
Namensdienst
09.04.
VL5 P01
Zeit, Synchronisation und globale Zustände
16.04.
VL6 P01
Logische Uhren
23.04.
VL7 P01
P-Aufgabe 2, Globale Systemzustände
30.04.
VL8
Wahlen, Wechselseitiger Ausschluss
07.05.
VL9 P02
P-Aufgabe 3, Verteilte Transaktionen, Replikationen
21.05.
VL10 P02
Replikationen
28.05.
VL11 P03
P-Aufgabe 4, Sicherheit
Anforderungen
Betriebssysteme (BS/BSP)
da in diesen Umgebungen die Verteilten Systeme arbeiten
Rechnernetze (RN/RNP)
da dies die notwendigen
g Basisstrukturen sind auf/in denen
Verteilte Systeme ablaufen
Kenntnisse der Lehrveranstaltungen des 1-ten bis 4 -ten
Semesters
da Verteilte Systeme die Informatik vereint
9
10
Anforderungen
Anforderungen
Kompetenzen aus Algorithmen und Datenstrukturen (AD/ADP)
Kompetenzen aus Betriebssysteme (BS/BSP)
… können Algorithmen und Datenstrukturen entwerfen
… können das Verhalten von Computersystemen analysieren und
beschreiben
… können Grundkonzepte der nebenläufigen Programmierung
anwenden
K
Kompetenzen
t
aus Rechnernetze
R h
t (RN/RNP)
Kompetenzen aus Software Engineering I (SE1/SEP1)
… können Ausschnitte aus der Realwelt mit Hilfe geeigneter, aktueller
Methoden modellieren
… beherrschen Standardsituationen im Bereich der Modellierung
(Architekturen, Entwurfsmuster)
… können einen Systementwurf in eine produktiv einsetzbare
Systemimplementierung überführen
… können die ökonomischen Randbedingungen und deren Auswirkungen
sicher beurteilen und dementsprechend die Projekte planen
Kompetenzen aus Software Engineering II (SE2/SEP2)
… verstehen die Konzepte und die Funktionsweise von Rechnernetzen
… können auf der Socket-Schnittstelle basierende Client- /ServerAnwendungen erstellen
… können ausgewählte Vorgehens- und Prozessmodelle anwenden
11
12
Kompetenzen lernen
Praktikum / PVL
Gruppenaufteilung: 2 Studierende in
einem Team (Meldung bis zum 31.03.15 1600 Uhr!)
PVL-Bedingungen
– Baut stark auf vorbereitende Arbeit auf!
– Empfehlung: vor dem Praktikumstermin:
Ziele festlegen, Arbeitsplan erstellen etc.; das Praktikum als
Präsentation/Anwendung nutzen
– Details siehe Aufgabenstellungen!
Bis Freitag Abend 2000 Uhr vor dem Praktikumstermin: Entwurf zusenden.
Während des Praktikumstermins: Befragung/ Disputation von/mit Gruppen
Die Frage ist nicht ob die Anforderungen erfüllt sind, sondern wie!
Am Ende des Praktikumstermins (ca. 40 min): Gemeinsame Vorführung
Am gleichen Tag bis 1600 Uhr: Abgabe der geforderten Unterlagen (digital!)
– Anwesenheitspflicht (gesamte Praktikumszeit!)
– Erfolgreiche Bearbeitung aller Aufgaben
– Einhaltung aller Termine
13
14
2
Wozu Aufgaben?
Praktikumsaufgaben
Machst du es richtig?
(Geschlossene Aufgabe: Wie viel ist 49 * 51?
Defizitperspektive)
oder
Wie machst du es?
(Offene Aufgabe: Wie rechnest du 49 * 51?
Entwicklungsperspektive)
Was will man erfahren, wenn eine
Aufgabe gestellt wird?
Programmiersprache
Aufgabe 1 & 2: Erlang/OTP;
Aufgabe 3: Java;
Aufgabe 4: frei wählbar (innerhalb der durch das Labor vorgegebenen
Rahmenbedingungen!);
Teams (je zwei) verantwortlich für den gesamten Code der Aufgabe:
Architektur und Programmcode müssen gut (frei) erklärbar sein.
4 Praktikumsaufgaben:
– RMI mittels Erlang/OTP: message of the day (bereits online!)
– Verteilte Algorithmen: Kontrolle und Verwaltung (bereits online!)
– Middleware: Ein kleiner Blick hinter die Kulissen (bereits online!)
– Zeit intensiv: ein Zeitmultiplexverfahren (bereits online!)
Übernahme von Code Dritter: Ist maximal bei einer Aufgabe mit
entsprechender Begründung (siehe Dokumentationskopf) und nur nach
Ankündigung im Entwurf zulässig. Es dürfen maximal 50% des gesamten
Codes dieser Aufgabe Fremdcode sein und dieser darf nicht die
Kernkonzepte betreffen. Diese müssen stets selbst implementiert werden.
15
Dokumentationskopf
Team: <Teamnummer>, <Namen der Teammitglieder>
Aufgabenaufteilung:
1.
2.
16
Clean Code Developer
Details siehe Vorlage
<Aufgaben, für die Teammitglied 1 verantwortlich ist>
<Aufgaben, für die Teammitglied 2 verantwortlich ist>
Quellenangaben: <Angabe von wesentlichen Quellen>,<Namentliche Nennung von
Studierenden der HAW, von denen Quellcode übernommen wurde>
Begründung für Codeübernahme: <Wurde Quellcode übernommen,
übernommen ist hier ausführlich zu
begründen, warum dies gemacht wird, warum diese Quelle ausgewählt wurde und wie der
dadurch verlorene Lerneffekt auf andere Art und Weise sichergestellt wird.>
Bearbeitungszeitraum: <Datum und Dauer der Bearbeitung an der Aufgabe von allen
Teammitgliedern>
Aktueller Stand: <Welche Teile der Software sind fertig inklusive Tests, welche sind fertig,
aber noch nicht getestet, welche müssen noch implementiert werden>
Änderungen im Entwurf: <Vor dem Praktikum auszufüllen: Welche Änderungen sind bzgl.
dem Vorabentwurf vorgenommen worden.>
Entwurf: <Entwurf nach den bekannten SE-Richtlinien und den Vorgaben gemäß
Aufgabenstellung.>
Sollte vielleicht auf Entwurf verzichtet werden, wenn letztlich in der Implementation die
„Strukturwahrheit“ liegt? Nein, sicher nicht. Entwurf muss sein. Ohne Planung gibt es
keine Zielvorstellung. Aber Entwurf und Implementation müssen dem „Don't Repeat
Yourself“-Prinzip gerecht werden. Deshalb sollten Entwurf und Implementation sich so
wenig überlappen wie möglich. […] Wenn das der Fall ist, stellen sie keine
Wiederholungen mehr dar, sondern beschreiben unterschiedliches. Das bedeutet:
Entwurf/Architektur kümmert sich nicht um die Implementation und Implementation
kümmert sich nicht um Architektur.
Und wo verläuft diese Trennlinie? Bei den so genannten Komponenten. Architekten
kümmern sich nicht um den internen Aufbau von Komponenten. Für sie sind es Black
Boxes, deren Klassenstruktur nicht architekturrelevant ist. Umgekehrt ist für einen
Komponentenimplementierer die Architektur irrelevant. Was er zu implementieren hat,
ergibt sich aus den Komponentenkontrakten, die seine Komponente importiert und
exportiert. Einen größeren Zusammenhang muss er nicht kennen.
Die Aufgabe der Architektur ist es mithin, Software in Komponenten zu zerlegen, deren
Abhängigkeiten zu definieren und Leistungen in Kontrakten zu beschreiben. […] Und die
Aufgabe der Implementation ist es, die von der Architektur definierten Komponenten zu
realisieren. Wie sie das tun, ist nicht architekturrelevant. Ihre innere Struktur ist für die
Architektur unsichtbar.
17
Warum erfüllen diese
ihre Aufgabe?
Entwurf?
Entwurf:
ADTs:
Holdbackqueue: dict(NachrichtenNummer, Nachricht)
Deliveryqueue: dict(NachrichtenNummer, Nachricht)
ClientList: dict(PID,{LetzteNachrichtenNummer,TimeStamp})
in der Holdbackqueue können dank der eindeutigen
nachrichtennummern, die nachrichten an jeder stelle
eingefügt werden.
werden Nach jedem einfügen wird anhand des
keysets geprüft ob zu min(n) ein eintrag n+1 vorhanden ist. In
der Deliveryqueue kann schnell auf eine beliebige nachricht
zugegriffen werden. Nach jedem hinzufügen einer neuen
nachricht wird die maximale nachrichten anzahl in Holdback
und Delivery geprüft. Schneller Zugriff erfolgt auch bei der
ClientList durch die eindeutige PID. Client Timeouts werden
nach jedem receive des Servers geprüft. Auf Lücken in der
Holdbackqueue wird nach jeden Empfangen einer neuen
textzeile geprüft und entsprechend reagiert. Auch das passiert
sehr performant, da nur der kleinste schlüssel gelöscht und die
Differenz zum nächst größeren als Lücke ausgegeben werden
kann.
was soll das heißen?
die stehen unsortiert in
der hbq, weil sie über
die nummer identifiziert
werden können?
18
Entwurf?
Was ist mit der
Nachrichtennummer?
Wer ist min(n) bzw. n?
welche maximale
anzahl an Nachrichten
hat die hbq und
warum? vorgegeben
ist ja nur eine für die
dlq.
Wer läuft bis…?
Und was wird pro
Nachricht übertragen?
Wieso schnell/
performant?
Welches
Verhalten ist
entsprechend?
Können Sie nach dem Entwurf die Aufgabe korrekt implementieren?
Werden Sie bei dem Entwurf konzeptuelle Fehler im Nachhinein entdecken können?
19
20
3
Konstruktionsprinzip
Praktikumsaufgaben
Von innen nach außen:
Sony Präsident Norio Ohga: CD muss die Neunte Symphonie Bethovens in der Fassung
von Karajan mit 72 Minuten speichern können. Daher hat diese den Durchmesser von
12cm, statt der ursprünglich geplanten 11,5cm.
Erfolgreiche Bearbeitung aller Aufgaben:
Ausführliche Dokumentation des Codes und rechtzeitige Abgabe (als
*.zip < 3MB):
– Eine korrekte Implementierung, die der formalen Beschreibung
entspricht (keine Warnings/Errors beim Start)
– Kommentierung der zentralen Eigenschaften/Ereignisse etc. im Code
– Ausführliche Beschreibung zum Start der Software (ausführbare Datei
ist mitzuliefern), zur Architektur (z.B. Klassendiagramme,
Sequenzdiagramme etc.)
Anwesenheitspflicht (180 Minuten bzw. 3 Zeitstunden)
Erfolgreiche Besprechung der Aufgabe
Weitere Details: siehe jeweilige Aufgabenstellung
Innen mindestens 72 Minuten, daher hat es außen 12cm Durchmesser.
Software: Vorgaben an die innere Struktur, z.B. bestimmte Datenstrukturen oder
Programmiersprachen oder eine Middleware
Programmiersprachen,
Middleware, die keinem Standard unterliegt (J2EE etc)
etc).
Von außen nach innen:
Projektleiter Kozo Ohsone: CD-Spieler muss die äußeren Maße von 12,7 x 12,7 x 3,8 cm
haben. Die Hauptflächen des zugehörigen Blocks wurden von ihm unterschrieben und
waren nicht diskutabel.
Außen 12,7 x 12,7 x 3,8 cm, daher sieht es innen so aus, wie es heute dort aussieht.
Software: Vorgaben von Schnittstellen, z.B. ADTs oder entfernte Schnittstelle
(RPC/RMI), oder eine Middleware, die einem Standard unterliegt (CORBA etc).
21
22
Basis-Literatur
G. Coulouris, J. Dollimore, T. Kindberg:
Verteilte Systeme,
Pearson Studium
Andrew S. Tanenbaum, Maarten van Steen:
Verteilte Systeme: Grundlagen und Paradigmen,
Pearson Studium
Hinweis zu den Folien
Zum Kauf
empfohlen!
G. Bengel et al: Masterkurs Parallele und Verteilte Systeme, Vieweg
J. Armstrong: Programming Erlang - Software for a Concurrent World,
Pragmatic Bookshelf
F. Cesarini, S. Thompson: Erlang Programming, O'Reilly
P. Mandl: Masterkurs Verteilte betriebliche Informationssysteme, Vieweg
D. Dörner: Die Logik des Misslingens. Strategisches Denken in komplexen
Situationen, Rowohlt Verlag
23
Die Folien sind kein vollständiges Skript und genügen normalerweise
nicht zur Prüfungsvorbereitung oder als Nachschlagewerk!
Sie sollten sich deshalb auf jeden Fall zumindest mit der aufgeführten
Basis-Literatur beschäftigen und sich von Zeit zu Zeit auch
weiterführende Literatur und aktuelle Zeitschriftenartikel anschauen.
Bemerkung
g am Rande: Diese Folien sind zum g
großen Teil aus
Folien/Skripten anderer Kollegen (auch anderer Hochschulen)
zusammengestellt!
Zur Klausur: Die Aufgaben prüfen
– Reproduktion/Kennen („Auswendiglernen“; 1.,2.),
– Reorganisation/Verstehen („Selbständige Verarbeitung und
Strukturierung“; 2., 3., 4.),
– Transfer/Anwendung („Übertragung auf neue, ähnliche Aufgaben“; 3.,
4., 5., 6.)
24
Warum bilden „Verteilte Systeme“ ein eigenständiges Thema ?
Verteilte Systeme
Einführung
25
Es gibt keinen gemeinsamen Speicher
(Interaktion durch Nachrichtenaustausch)
Es gibt nebenläufige/parallele Aktivitäten
(Koordination, Synchronisation)
Fehler und Ausfälle sind wahrscheinlich
(Transparenz)
Komponenten (Hardware und Software) sind heterogen
(Standardisierung von Schnittstellen)
Systeme können sehr groß sein
(Großsystemeffekte, Umschlag von der Qualität in die Quantität)
26
4
Verteilte Welt und Probleme
Nebenläufigkeit
Regeln
R1: ab → aa
R2: ba → bb
•Viele gleichzeitige („parallele“) Aktivitäten
•Exakte globale Zeit nicht erfahrbar/vorhanden
•Keine konsistente Sicht des Gesamtzustandes
•Kooperation durch Kommunikation
•Ursache und Wirkung zeitlich getrennt
>Räumliche Separation
Separation,
autonome Komponenten
>Heterogenität
>Dynamik, Offenheit
Wort
abcba
–Synchronisation
schwieriger
+Nebenläufigkeit
–Programmierung
komplexer
R1
aacba
R2
abcbb
Parallel
Nebenläufig
R1&R2
aacbb
R1
R2
aacba abcbb aacbb
27
28
Nebenläufigkeit
Wort
abab
aaab
Software Fehler in Verteilten Systemen
Hier sind R1 und R2 anwendbar, aber nicht nebenläufig
anwendbar; daher besteht keine Nebenläufigkeit.
Sequentiell
R1
R2
R1
abbb abaa
b
Parallel
R1&R1
aaaa
Nebenläufig
R1
R2
R1
R1&R1
aaab abbb abaa
aaaa
b
Das die Nebenläufigkeit als direkte Folgezustände der Vereinigung aus den
Folgezuständen der sequentiellen und parallelen Verarbeitung entspricht, liegt an der
Verwendung von nur zwei Regeln. Bei drei oder mehr Regeln wäre dem nicht so, weil bei
der parallelen Verarbeitung alle anwendbaren Regeln gleichzeitig angewendet werden,
wogegen bei der nebenläufigen Verarbeitung eine beliebige Untermenge davon zunächst
nur angewendet werden kann!
1971 Eole1, französischer Satellit zur Koordination von 141 Wetterballons; 72
1971:
Ballons erhalten den Befehl vom Satelliten, Daten zu senden, interpretieren dies
aber als Befehl zur Selbstzerstörung.
1990: Geldautomat, Person will Geld an einem Geldautomaten in Honolulu abheben,
1990
der zentrale Rechner zur Überprüfung steht in New Jersey, durch Zeitverzögerung
des Satelittensignals und einen Protokollfehler wird Geld nicht ausgezahlt und
trotzdem abgebucht.
g
1995: Telefonnetz Singapur; 65% der Leistung sind fünf Stunden nicht nutzbar, die
1995
restlichen stark überlastet, da sich Software-Fehler eines Vermittlungsknotens auf
weitere Systeme fortpflanzte.
1996: Ariane 5; Hauptrechner sendet unsinnige Befehle an Triebwerk, Rakete
1996
zerstört sich selbst, Problem war die ungeprüfte Übernahme von Software der Ariane
4, die für die auftretende Beschleunigungen der Ariane 5 nicht konzipiert war.
2009: Bei der Umstellung der Bearbeitung der „Abwrackprämie“ werden durch
2009
Überlast verschiedenen Anträgen die gleichen Bearbeitungsnummern zugeteilt, so
dass Bestätigungsmails private Daten willkürlich verteilen.
29
30
Was ist ein verteiltes System ?
Verteilte Informationssysteme
Eine allgemeinere Beschreibung:
Ein verteiltes System ist ein System, in dem
– Hard-und Softwarekomponenten,
– die sich auf miteinander vernetzten Computern befinden,
– miteinander kommunizieren und ihre Aktionen koordinieren,
koordinieren
– indem sie Nachrichten austauschen.
R1&R2
Bei der Nebenläufigkeit entstehen also (direkte Folge-)Zustände, die bei einem
sequentiellen System oder auch parallelem System nicht entstehen können!
Z.B. bei Verwendung von Threads auf einem Rechner können bestimmte Zustände nicht
erreicht werden, die unter Verwendung von Prozessen auf verschiedenen Rechnern
möglich sind!
–Testen
aufwendiger
+Zustandsverteilung
>Sicherheit
Hier sind R1 und R2 anwendbar und auch nebenläufig
anwendbar; daher besteht eine echte Nebenläufigkeit.
Sequentiell
+Probleme sequentieller
Systeme
+Nichtdeterminismus
>Komplexität
Es wird ein *-Termersetzungssystem betrachtet und
nur die direkten, möglichen Nachfolgezustände auf
das Eingabewort.
Eine verteilte Anwendung ist eine Anwendung, die ein verteiltes
System zur Lösung eines Anwendungsproblems nutzt. Sie
besteht aus verschiedenen Komponenten, die mit den
Komponenten des VS sowie den Anwendern kommuniziert.
31
Verteilte Informationssysteme sind komplizierte verteilte
Systeme
Typische Merkmale:
•
Oft sehr groß (500.000 LinesOfCode und größer)
•
„Sehr“ datenorientiert: Datenbanken im Zentrum der Anwendung
•
Extrem interaktiv: GUI, aber auch Batch
•
„Sehr“ nebenläufig: Große Anzahl an gleichzeitig arbeitenden Benutzern
32
5
Klassifizierung nach Tanenbaum
Sichten verteilter Systeme
Rechnernetz mit
Rechnerknoten
Verteilte Computersysteme
„Sehr“ viele ähnlich aufgebaute und vernetzte Rechnersysteme
Algorithmen u.
Protokolle
Objekte
– Cluster-Systeme
– Grid-Systeme: Nutzung der Ressourcen des Internets, Projekte wie
Klimaforschung, …
Verteilte Informationssysteme
Verteilte pervasive Systeme
P1
Transaktionsanwendungen für betriebliche Aufgabenstellungen
P2
- Kleine, „sehr kleine“ Systeme, auch mobil
Physisch
verteilt
- Ubiquitous Computing (Ubicomp): Unauffällig arbeitende und
unsichtbare Computersysteme
Logisch
verteilt
P3
Zeit
33
Beispiel: Verteiltes Informationssystem (logisch)
Endbenutzer / Clients
Business-Logik
34
Beispiel: Verteiltes Informationssystem (physisch)
Datenhaltung
ERP-System
Auftragsabwicklung
Auftragsbearbeiter
ERP-Server 1 und 2
Auftragsbearbeiter
Bestellungsystem
Einkäufer
ERPDB
ERPDB
Einkäufer
LagerDB
...
DB-Server 1 und 2
Bestandsverwaltung
Disponent
LVS-Server 1 und 2
Disponent
Lagerverwaltung
LagerDB
Lagerverwalter
Lagerverwalter
MFR
Materialflusssteuerung
ShopDB
W W W -Browser
W W W -Browser
W ebshop
ShopDB
Kunde
Kunde
W ebserver
Shop-Server inkl. DB
DB = Datenbank
ERP = Enterprise Resource Planung
MFR = Maerialflussrechner
LVS = Lagerverwaltungsrechner
35
36
Wünschenswerte Eigenschaften
Wozu braucht man ein „Verteiltes System“?
Kommunikationsverbund (Übertragung von Daten, insbesondere
Nachrichten, an verschiedene, räumlich getrennte Stellen; z.B. E-Mail)
Informationsverbund (Verbreiten von Information an interessierte
Personen/Systeme; z.B. WWW)
Datenverbund (Speicherung von Daten an verschiedenen Stellen:
bessere Speicherauslastung, erhöhte Verfügbarkeit, erhöhte Sicherheit)
Lastverbund (Aufteilung stoßweise anfallender Lasten auf verschiedene
Rechner: gleichmäßige Auslastung verschiedener Ressourcen)
Leistungsverbund (Aufteilung einer Aufgabe in Teilaufgaben: Verringerte
Antwortzeiten)
Wartungsverbund (Zentrale Störungserkennung und –behebung:
schnellere und billigere Wartung verschiedener Rechner)
Funktionsverbund (Verteilung spezieller Aufgaben auf spezielle Rechner;
Bereitstellung verschiedener Funktionen an verschiedenen Orten)
Kapazitätsverbund (Ausnutzung sämtlicher zur Verfügung stehender
Rechenkapazität)
37
Gemeinsame Ressourcennutzung: Hardware, Daten,
Dienste etc. gemeinsam nutzen
Offenheit: Schlüsselschnittstellen (einheitlich) offen legen
Nebenläufigkeit: Mehrere gleichzeitig existierende Prozesse
Skalierbarkeit: auch mit vielen Komponenten gut
funktionieren können
Sicherheit: Verfügbarkeit, Vertraulichkeit, Integrität,
Authentizität, etc
Fehlertoleranz: Fehler erkennen, maskieren, tolerieren
Transparenz: hier im Sinne, etwas nicht sehen bzw. durch
etwas hindurch sehen können
38
6
Transparenz
Transparenz
Transparenz wird definiert als das Verbergen der Separation der einzelnen
Komponenten in einem verteilten System vor dem Benutzer und dem
Applikationsprogrammierer, so dass das System als Ganzes wahrgenommen
wird, und nicht als Sammlung voneinander unabhängiger Komponenten.
4. Replikationstransparenz erlaubt, dass mehrere Instanzen von Ressourcen
verwendet werden, um die Zuverlässigkeit und die Leistung zu verbessern,
ohne dass die Benutzer oder Applikationsprogrammierer wissen, dass
Repliken verwendet werden.
ISO (International Standards Organization) und ANSA (Advanced Network
Systems Architecture) identifizieren acht Formen der Transparenz:
5. Fehlertransparenz erlaubt das Verbergen von Fehlern, so dass Benutzer
und Applikationsprogrammierer ihre Aufgaben erledigen können, auch wenn
Hardware- oder Softwarekomponenten ausgefallen sind.
1. Zugriffstransparenz ermöglicht den Zugriff auf lokale und entfernte
Ressourcen unter Verwendung identischer Operationen.
2. Positionstransparenz (Ortstransparenz) erlaubt den Zugriff
Ressourcen, ohne dass man ihre Position/ihren Ort kennen muss.
auf
die
3. Nebenläufigkeitstransparenz erlaubt, dass mehrere Prozesse gleichzeitig
mit denselben gemeinsam genutzten Ressourcen arbeiten, ohne sich
gegenseitig zu stören.
6. Mobilitätstransparenz erlaubt das Verschieben von Ressourcen und Clients
innerhalb eines Systems, ohne dass die Arbeit von Benutzern oder
Programmen dadurch beeinträchtigt wird.
7. Leistungstransparenz erlaubt, dass das System neu konfiguriert wird, um
die Leistung zu verbessern, wenn die Last variiert.
8. Skalierungstransparenz erlaubt, dass sich System und Applikationen
vergrößern, ohne dass die Systemstruktur oder die Applikationsalgorithmen
geändert werden müssen.
39
40
Systemmodelle
Verteilte Systeme
Systemmodelle
Beschreibung der allgemeinen Eigenschaften und des Designs eines
Systems
Das Modell sollte abdecken:
– Die wichtigsten Komponenten des Systems
– Die Art ihrer Interaktion
– Wie deren individuelles und kollektives Verhalten beeinflusst werden
kann
Ein Architekturmodell
– vereinfacht und abstrahiert zunächst die Funktionen der individuellen
Komponenten eines verteilten Systems, um dann
– die Verteilung der Komponenten auf ein Netzwerk von Computern und
– die Beziehung der Komponenten (Rolle in der Kommunikation mit
anderen, Kommunikationsmuster) untereinander zu beschreiben.
Weitere Modelle: Interaktionsmodell, Fehlermodell, Sicherheitsmodell
41
42
Hardware- und Software-Serviceschichten
Client/Server Modell
•Plattformunabhängig
•Middlewareabhängig
Applikationen, Dienste
Middleware
Betriebssystem
Computer- und Netzwerkhardware
Client
Middleware (Verteilungsplattform) :
Transparenz der
•Heterogenität existierender
Hardware und Betriebssysteme
•Verteilung
Auftrag
Antwort
Client
Plattform: „unterste“ Hardware- und
Softwareschichten (Low-Level)
werden häufig als Plattform bezeichnet.
Beispiele: Intel x86/{Windows|Linux},
PowerPC/MacOS,
SunSPARC/SunOS
43
Auftrag
Server
Server
Antwort
Reagierender Prozess
•bearbeitet Anfragen
•erfüllt Aufträge
Initiierender Prozess
•stellt Anfragen
•erteilt Aufträge
Legende:
Prozess:
Computer:
44
7
Proxy-Server und Cache
Spontane Netzwerkverbindungen
Musikdienst
Gateway
Web
server
Client
Internet
Proxy
server
Web
server
Client
Weckdienst
Funknetzwerk des
Hotels
Erkennungsdienst
Kamera
Proxy-Server: Gemeinsamer Cache
Zweck von Proxy-Servern: erhöhte Leistung und Verfügbarkeit
TV/PC
Laptop
45
Applikation
Applikation
Koordinierungscode
Geräte des
Gastes
46
Thin Client/Fat Server
Gleichrangige Prozesse (Peer Processes)
Koordinierungscode
PDA
Applikation
Koordinierungscode
Oft bessere Leistung als Client-Server
mit vielen ähnlichen Prozessen und
vorwiegend lokaler Kommunikation.
Beispiel: Whiteboard
47
Drei Ebenen Architektur: „three-tier“
Präsentation
Businessebene
Datenmanagement
48
Beispiel: Suchmaschine
Kommuniziert mit dem Anwender
Führt die Geschäftsregeln aus,
verwaltet Prozessinformationen
Datenzugriff und Datenspeicherung
49
50
8
Beispiel: Suchmaschine
Anforderungen an die Auswahl eines Modells
51
Welches sind die Einflussfaktoren
– bei der Auswahl des Modells
– bei der Platzierung der Komponenten
Wichtig u.a.
– Performance (Antwortverhalten,
(Antwortverhalten Durchsatz,
Durchsatz Lastbalancierung,
Lastbalancierung
etc.)
– Quality of Service (Zuverlässigkeit, Sicherheit, Echtzeit, etc.)
– Inwieweit sollen Caching und Replikation eingesetzt werden
(mit welchem Konsistenzmodell?)
– Benötigter Grad der Verlässlichkeit des Systems (Korrektheit,
Sicherheit, Fehlertoleranz, etc.)
– Kosten (Anschaffung, Schulung, Lizenzen, etc.)
52
9
© Copyright 2024 ExpyDoc
