Verteilte Systeme - HTWG Konstanz - AIN 5
Karteikarten für das Fach Verteilte Systeme von Prof. Dr. Haase
Karteikarten für das Fach Verteilte Systeme von Prof. Dr. Haase
-
- 1 / 104
-
Flashcards
-verteilte Aufgabe (Videokonferenz,internettelefonie)
-Robustheit,Zuverlässigkeit,Verfügbarkeit (redundante Datenkopien,..)
-Teile müssen auf bestimmten Rechnern laufen(spezielle HW,..)
-Wirtschaftlichkeit: mehere schwache Rechner billiger als ein starker
-Nutzung brachliegender Ressourcen
-Lastverteilung
-verrignerte Antwortzeiten bei Aufteilung iner Aufgabe in parallele Teilaufgaben
-Verteilungstransparenz:
--Verteiltes System aussehen lassen wie lokales
--Transparent bzgl Eigenschaftwenn die für Benutzer unsichtbar ist
--verschiedene Transparenzaspekte
-Skalierbarkeit:
-fähigkeit zu wachsen ohne wesentliche Anpassung der Algorithmen/Protokolle
--Größe(Hinzufügen neuer Komponenten)
--geographische Verteilung(verteilt in institution,stad,land, vollkommen banane
--administrative Verteilung(system funkt auch bei verteilung über administrative Domänen hinweg)
-Erhöht den Parallelitätsgrad durch Vermeiden von blockieremdem Warten, selbst auf 1 Prozessorkernsystem
-Verringert durchschnittliche Bearbeitungszeit fallls Threads parallel ausgeführt werden/blockierendes Warten enthalten
POOL_SIZE = Kerne / CPU-Intensität
-um sich gegenseitig zu synchronisieren
-um ergebisse miteinander auszutauschen
(über Kooperation -> gemeinsame DAten oder Kommunikation .> Nachrichtenaustausch)
-führt kritische Abschnitte in Transaktionen aus die im Konfliktfall zurückgesetzt und neu durchgeführt werden
-kommt aus DBMS Bereich
-optimistische Konfliktstrategie
-typische Sprache: Clojure
Einsatzgebiet: Bei Threadinteraktion mit Kooperation(gemeinsame Daten)
-Inkonsistenzen aufgrund konkurrierenden Zugriffs auf gemeinsame Daten
Schützen durch: Sperren, Software Transactional Memory(STM)
-verteiltes Betriebssystem(DOS):lokale mechanismen implementieren systemweit verfügbare Dienste, Ortstransparenz
-Netzwerkos(NOS):benutzer verwendet explizit Dienste von anderern Rechnern, keine Orttransparenz,skalierbarer,offener,heute in allen gängigen OS
-Middleware: weitere Softwareschickt eingeführt,kombiniert Vorteile von DOS(transparenz, einfachheit) und NOS(offenheit,Skalierbarkeit)
Die aufteilung der Funktionalität auf Komponenten
für verteilte systeme relevant:
-->geschichtete Architekturen
-->objektbasierte Architekturen
-->datenzentrierte ARchitekturen
-->ereignisbasierte Architekturen
-schichtweise Anordung der Komponenten
-höhere Sschicht = komplexere Dienste
-Immer nur Komponenten von Schicht drunter verwenden
-Anforderungen von oben nach unten, Antworten von unten nach oben
-Häufig verwendet, bestehd aus Präsentations-,Anwendungs-,Persistenzschicht
-Innerhalb der schichten meistens weiter geschichtet
-Objekte entsprechen Komponenten
-Interaktion erfolgt in Form von Methodenaufrufen
-häufig Kombination von SChichten und objektbasierter ARchitektur
-->Objekte scichten zugeordnet, aufrufe nur innerhalb derselben oder in niedererer Schicht
-Komponenten kommunizieren über gemeinsames Repo miteinander
-zeitliche Entkopplung der Komponenten voneinander
-Kommunikation über Weitergabe von Ereignissen
-Publish/Subscribe: Komponenten können EReignisse veröffentlichen, Middleware(Ereignisbus) sorgt für Weiterleitung an Komponenten die Ereignisse zuvor abonniert haben
-Kombinierbar mit datenzentrierter Arch. (gemeinsame Datenräume)
-Bilden Komponenten auf Rechner ab
-konkrete Instantiierung von Softwarearchitekturen
-Client-Server
-Peer to Peer
-Schicht Li+1 ist Client der tierferliegenden Schicht, in Bezug auf deren Dienst
(nTierArchitektur,..)
Dienst jeder Schicht so partitionieren dass jeder Client der Schicht Li eine Partiton als Server übernehmen kann
(z.b. Verteilte Datenspeicherung: jeder Client stellt Speicherplatz für Teil des gesamten Datenraums bereit)
Verteiltes Architekturmuster mit Zweck geschäftslogig von Kommunikation zu entkopel, so dass Kommunikationsmechanismus austauschbar wird
Forwarder: logische namen auf physische abbilden, Parametermarshalling, versenden über konkreten Kommunikationsmechanismus
Receiver: empfangen über konkreten Kommunikationsmechanismus,Parameterunmarshalling(konvertieren in internes Foramt)
Universal Coordinated time
--basiert auf TAI(Temps Atomique international)
-Angenommen: Existenz eines UTCempfängers im System(Zeitserver)
-andere Maschinen senden regelmäßig timerequest an Server der so schnell wie geht mit aktueller utc antwortet
-wenn anfragender schnell uhr hat müsste uhr zurückgesetzt werden(zeitpunkt darf nicht zweimal auftreten!)
-->Uhr graduell anpassen in dem sie eine Weile langsamer läuft
-Wegen signallaufzweit ist zeit veraltet
-->signallaufzeit messen/schätzen
Network Time Protocol
-möglichst genau mit utc sncrhonisieren, trotz schwankender Übertragungsverz
-zurverlässiger Dienst mittels Redundanz
-Clienst sollen sich oft synchronisieren können(skalierbarkeit!)
-von Netwerk von Servern erbracht
-Primary servers direkt mit utc quelle verbunden
-secondary servers syncrhonisieren sich mit primar servers
-servernetzwerk rekonfigurierbar um auf fehler reagieren zu können
-server tauschen oft nachrichten aus(Netzewrkverzügerungen,Uhrungenauigkeiten)
-Clients synchroniseren sich mit Server mit geringster gemessener Signallaufzeit
-Sinnvoll wenn kein UTCserver zur Verfügungs steht
-ein Rechner als Zeitserver
-Zeitserver frag regelmäßig bei allen RAchnern nach aktueller Zeit, bildet AVG
-AVG allen Rechnern mitteilen, passen Uhren danach an
Jeder Proz hat logische Uhr Ci die bei auftreten eines Ereignisses a abgelesen wird und Wert Ci(a) liefert
-Jeder proz wendet Algorithmus an um seine Uhr anzupassen
-->Ci vor jedem neuen Ereignis in Proz um 1 erhöhen
-->wenn Pi Nachricht sendet schickt er aktuellen WErt von Ci mit
-->bei erhalt von nachricht setzt Proz seine uhr auf t falls t>Ci, dann +1
-einer der Prozesse wird zum koordinator für kritische Region bestimmt
-alle anderen wenden sich erst an koordinator
-wenn kritische region frei: proz erhält ok vom server. nach abarbeitung igbt prozess das token zurück
-region nicht frei: prozess in warteschlange aufnehmen
Vorteile:
-->gegenseitger Ausschluss
-->fair
-->einfach
-->nur 3 nachrichten pro Zugang zu krit Region
Nachteile:
-->koordinator ist single point of failure
-->mangelnde skalierbarkeit
-->keine antwort kann lange Warteschlange/toten Koordinator bedeuten
-kein ausgewiesener Koordinator
-jeder prozess hat logische Uhr
-will proz in krit Region sendet er request an alle prozesse
-erst wenn alle prozesse ok geben kann er eintreten
-Beispiel: Ricart und Agrawala
-->Jeder Knoten single Point of Failure
-->Jeder Prozess muss bei entscheidung mitwirken (Skalierbarkeit!)
-->mehr Nachrichten, größere Netzwerklast
-->Knoten mit langsamster Zeit gewinnt -->niht fair
-Prozesse werden in logischem Ring angeordnet
-Token kreist durch Ring
-bekommt Proz token kann er einmal eintreten und token weitergeben oder direkt weitergeben
Vorteile:
-->korrektheit leicht zu sehen
-->fair
Nachteile:
-->tote Prozesse müssen erkannt werden
-->verlorene Token schwer zu erkennen
-->Koordinator muss verlorenes Token neu einspielen
Manche anwendungen üssen über Gesamtzustand des verteilten Systems Bescheid wissen
-Einzelkomponenten dürfen ihre lokalen Snapshots zu unterschiedlichen zeitpunkten machen, solange die Happens-Before-Realtionship nicht verletzt ist
-Voraussetzung:alle Prozesse paarweise über FIFO-Kanäle miteinander verbunden
-Ein oder mehre Prozesse starten Algo zur Festellung eines Systemzustands sodass gleichzeitig immer mehre Snapshot serstellt werden können
-System läuft ungehindert weiter
-Prozesse verständigen ssich über Markierungsnachrichten über Notwendigkeit der Speicherung eines Systemzustands
-->Snapshot ggfs. nie genau so existiert, ist aber konsistent
-in vielen verteilten Algorithmen braucht man Proz. der besondere Rolle spielt, z.B. Koordinator, intiaror,..
-Aufgabe auswahlalgo: prpzess bestimmen der die Rolle übernimmt
-->Ziel: am ende sind sich alle drüber einig wer neuer koordinator ist
-jeder Proz hat nummer die allen anderen Proz bekannt ist
-keiner weiß welcher andere gerade funktioniert oder nicht läuft
-alle algorithmen wählen proz mit höchster nummer aus
-->bullyalgorithmus
-->ringalgorithmus
-->wahlalgorithmus für adhocnetze
-Wenn Proz P feststellt dass augenblicklicher Koordinator nicht mehr reagiert startet er Auswahlprozess
-->P schicht auswahlnachricht an alle Prozesse mit höherer Nummer
-->keine Antwort: er ist neuer Koordinator
-->antwort: aufgabe erledigt
-->alle prozesse die geantwortet haben machen dasselbe
-Prozesse logisch in Form eines Rings organisiert -->jeder forgänger/nachfolger entsprechend aufsteigender Prozessnummern
-Stellt proz fesst das koordinator nicht funktioniert, auswahlnachricht an nächsten erreichbaren Nachfolger
-jeder weiter aktive proz fügt sich selber in liste ein
-trifft nachricht beim initiator ein wandelt er diese in koordinatornachricht um die neuen koordinator und aktive mitglieder enthält
-Situation:netztopologie ändert sich schnell
-->bester Anführer suchen
-->annahme:knoten bewegen sich nicht
-->idee:baum aufspannen, bis zur wurzel
Phase1: Knoten(quelle)sendet Wahlnachricht an alle direkten Nachbarn
-empfängt knoten erste Wahnachricht: sender as elternknoten bestimmen,wahlnachricht weiter an alle nachbarn auser eltern
-.>nicht erste, lediglich empfang quittieren
Phase2:Ergebnis zur Wurzel propagieren
-->wen knoten Q nur quittierungen erhält ist er blattknoten,gibt wahlrelevante eigenschaften(ressourcen,..)zurück an elternknoten, sonst wählt q besten anführer aus allen seinen kindern und gibt ihn an elternknoten zurück
-Halten mehrerer Kopieen eines Datums
-will prizess auf daten zugreifen kann er auf beliebige Replika zugreifen
-ideallfall: immer gleiches Ergebnis
-->Konsistenz der Kopieen
-Schutz gegebn zerstörte/gefälschte daten(gleichzeitig auf mehere zugreiffen)
-leistungssteigerung
-müssen konsistet gehalten werden
-insbesondere wenn viele Replikats/weit verstreut
-Problem: bessere Skalierbarkeit,bessere Leistung aber notwendige meachismen verschlechtern Performance
-->Lösung: keine strikte Konsistenz