KE 1

Zentrale Merkmale:

1. Sammlung von mehreren autonomen Rechner-Komponenten

   • geografisch getrennt

   • auf verschiedenen Rechnern (nodes)

   • könnten getrennt von einander handeln

     
     

2. Koordination der Aktionen durch Austausch von Nachrichten über Kommunikationskanäle

   • Nachricht rein

   • Verarbeitung

   • Nachricht raus

weitere Merkmale:

• sehr dynamisch

  • Geräte können kommen und gehen

• Größe weniger relevant

  • eine Handvoll vs. mehrere Milltionen

4 Konsequenzen:

1. Transparenz

   • Nodes erscheinen Nutzer als kohärentes System

     • kohärent = verhält sich wie vom Nutzer erwartet

     • verhält sich immer gleich unabhängig von der Zeit oder Art des Zugriffs

2. Nebenläufigkeit

   • Programme laufen parallel

   • gemeinsame Verwendung von Ressourcen

3. Keine globale Uhr

   • Aktionen per Nachrichten koordiniert

   • Zeit hilfreich, gibt aber keine globale Uhr

4. Unabhängige Fehler

   • jede Komponenten im VS kann unabhängig Fehler verursachen

= Software-Schicht oberhalb der OS der beteiligten Nodes

• zwischen Anwendungen und Service-Routines

• Menge von Prozessen und Objekten

vereinfacht Kommunikation

maskiert Heterogenität

= verschiedene Betriebssysteme, Netzwerke, Programmiersprachen, Entwickler

• wie OS auf einzelnem Rechner

  • verwaltet Ressourcen

  • ermöglicht Kommunikation zwischen Anwendungen

  • sorgt für Sicherheit

  • behandelt und versteckt Fehler

• Unterschied zu OS:

  • angeboten in Netzwerk-Umgebung

• auch Container für Funktionen, die verschiedene Anwendungen häufig brauchen

  • müssen diese sie nicht mehr gesondert Implementieren

1. Transparenz

2. Offenheit

   • Schnittstellen veröffentlichen und ihre Dokumentation

   • Ziel: Interoperatbilität udn Portabilität (= Programme können auf verschiedenen Systemen ausgeführt werden)

3. Skalierbarkeit

   • Anzahl Nutzer

   • geographische Entfernung

   • administrative Kontrolle

4. Sicherheit

   • Vertraulichkeit

   • Integrität

   • Verfügbarkeit

= verbirgt Verteilung von Komponenten im VS

1. Access/ Zugriff

   • Art der Repräsentation und des Zugriffs auf Prozesse/ Ressourcen

   • man kann identische Operationen verwenden

2. Location/ Ort

   • man braucht nicht wissen, wo Ressource ist

1. Relocation

   • Verschieben von Prozessen/ Ressourcen (z.B. Webseiten von einem Datenzentrum zu einem anderen)

   • durch das VS

2. Migration

   • überhaupt verschieben

   • durch den User

   • z.B. Bewegen mit Mobiltelefonen ohne dass Kommunikation beeinträchtigt wird

3. Replication

   • mehrere Instanzen von Objekten benutzen

   • Kopieren von Objekten für bessere Performanz

4. Concurrency

   • unabhängige Nutzer teilen gleiche Ressource/ Prozess

   • geteilte Ressource muss konsistent bleiben

5. Failure

   • Ausfälle verbergen

   • korrekte Wiederherstellung

= Komponenten sollen einfach verwendet und in andere Systeme integriert werden

• Standard-Regeln für Syntax und Semantik der Angebote der Komponenten

  • z.B. Interfaces mit Interface Definition Language (IDL)

    • für Syntax

  • Semantik zu spezifizieren ist schwer

    • meist mit natürlicher Sprache

Anforderungen für Spezifikationen:

• vollständig

  • alles für Implementierung Benötige wurde spezifiziert

• neutral

  • nicht vorschreiben, wie Implementierung aussehen sollte

• beide wichtig für:

  • Interoperabilität

  • Portabilität

  • Extensibilität

• extrem: Source Code zur Verfügung stellen und alle arbeiten daran

• weiteres Problem: Parameter-Einstellungen (z.B. für Caching)

• Ausmaß in der zwei Implementierungen miteinander arbeiten können

• indem sie nur auf die Services sich verlassen, die durch einen gemeinsamen Standard spezifiziert wurden

• Ausmaß in dem eine Anwendung für VS A auf einem VS B verwendet werden kann, wenn B die gleichen Interfaces wie A implementiert

• Komponenten ersetzen oder austauschen, hinzufügen

• andere Komponenten sollten nicht betroffen werden

1. Größe

   • mehr Nutzer oder Ressourcen

   • ohne Performanz einzubüßen

     
     

2. Geographisch

   • Nutzer und Ressourcen weit entfernt

   • keine Verzögerung bemerkbar während Benutzung

   • Problem wegen synchroner Kommunikation

     • brauchen dann reiche Interaktionsmuster zwischen client und server

3. Administrativ

   • einfach zu verwalten

     • beinhaltelt:

       • Resourcen-Nutzung und Bezahlung

       • Verwaltung

       • Sicherheit

     • Nodes in einem VS können anderen nodes darin vertrauen

   • selbst wenn viele unabhängige Verwaltungsorganisationen drin sind

1. Rechnerkapazität (CPUs)

2. Speicherkapazität (inkl. I/O rate)

3. Netzwerk (zwischen User and zentralem Service)

1. Hiding communication latencies

   • bei geograpischer Skalierung

   • asynchrone Kommunikation

     • andere Arbeit verrichten, wenn man auf Antwort wartet

   • Teil der Arbeit vom Server zum Client verlegen

1. partitioning and distribution

• Komponente in kleinere Teile zerlegen und die im VS verteilen

• Bsp. DNS Aufteilung

  • hierarchisch aufgeteilt in Baum mit nicht-überlappenden Zonen

  • in jeder Zone ein einzelner DNS server

1. Replication

   • Komponenten im VS replizieren

   • Caching als spezielle Form

     • führt zu Konsistenzproblemen

   • Synchronisationsmechanismen hart/ unmöglich skalierbar zu implmentieren

2. Kapazität erweitern

1. scaling up

   • mehr Speicher, CPUs, ...

2. scaling out

   • VS erweitern durch mehr Maschinen

• Netzwerk sei reliabel

• Netzwerk sei sicher

• Netzwerk sei homogen

• Topologie ändere sicht nicht

• Latenz sei 0

• Bandbreite sei unendlich

• Transportkosten seien 0

• es gäbe nur einen Admin

• Transaktionen beginnen mit BEGIN_TRANSACTION

• enden mit END_TRANSACTION

• Prozeduren dazwischen werden entweder alle ausgeführt oder keine

Eigenschaften von Transaktionen:

• Atomic

  • Transaktionen scheinen unteilbar

• Consistent

  • Transaktionen erhalten System Invarianten

• Isolated

  • Gleichzeitige Transaktionen behindern sich nicht gegenseitig

• Durable

  • wird eine Transaktion ausgeführt (commited) sind die Änderungen permanent

  • gilt nur für Top Level Transaktionen (bei nested transactions)

1. Software Architecture

   = logischer Organisation der Software-Komponenten

   • welche gibt es

   • ihre Organisation

   • wie sie miteinander interagieren

2. System architecture

   = eine Instanz der physischen Realisierung

   • Menge von Komponenten

   • Konnektoren, die Interaktion zwischen Komponenten definieren

• Komponenten

  • modulare einheiten

  • bieten Interface

  • ersetzbar in der Umgebung

• Connector = Verbindung zwischen Komponenten

  • Mechanismus

  • Kommunikationsprotokolle

  • Streams

• Datenaustausch zwischen Komponenten

• gemeinsame Konfiguration in einem System

1. Layered architectures

   
   

2. Object-based architectures

3. Resource-centered architectures (auch resource-based)

4. Event-based architectures/ publish-subscribe architectures

• Service Oriented Architecture

• nur noch Services verbinden

• nicht trivial, weil Interfaces passen müsse

• VS als riesige Kollektion von Ressourcen, die individuell von Komponenten verwaltet werden

• Name des Ansatzes: Rpresentational State Transfer (REST)

  • vs. service-specific Interfaces

• weniger Operationen aber mehr Parameter

  • Amazon S3 für Storage bietet zusätzlich SOAP Interface mit bis zu 50 Operationen (die haben viel weniger Parameter)

• Fehler werden weniger während Compilierung als während der Runtime entdeckt

1. ein einziges Benennungsschema identifiziert Ressourcen

2. Alle Dienste bieten die gleiche Schnittstelle mit 4 Operationen

   • 1. PUT

     • Ressource ändern durch Übermitteln eines neuen Zustands

   • 2. POST

     • neue Ressource erstellen

   • 3. GET

     • Zustand einer Ressource durch irgendeine Repräsentation erhalten

   • 4. DELETE

     • Resource löschen

3. Nachrichten zu oder von einem Dienst sind vollständig selbstbeschreibend

4. nach dem Ausführen einer Operation vergisst die Komponente alles über den Aufrufer

   = stateless execution

• so wenig wie möglich Abhängigkeiten zwischen Prozessen

• System als Sammlung unabhängiger Prozesse

• Koordination als Kommunikation und Kooperation zwischen den Prozessen

Arten von event-based Systemen

• published = Ereignis wird für andere Prozesse verfügbar gemacht

• subscribe = Ereignisse beschreiben, die Abonnent haben will

• Beschreibung ähnlich SQL

1. topic-based publich-subscribe Systemen

   • Beschreibung enthält (attribute, value) Paare

2. content-based publish-subscribe Systemen

   • Beschreibung enthält (attribute, range)-Paare

   • Attribut soll Werte innerhalb eines Bereichs annehmen

• kann man große VS bauen, weil die Prozesse lose verbunden sind

oder

1. event-based Koordination

   • nur räumlich entkoppelt

2. shared data space

   • zusätzlich zeitlich entkoppelt

3 Eigenschaften:

• Entkopplung von Räumlichkeit (Referenz)

  = Publisher und Subscriber brauchen sich nicht zu kennen

• Entkopplung von Zeit

  = P und S können asynchron laufen

• Entkopplung von Synchronisation

  = P und S brauchen nicht auf Bestätigung von einander warten

Dimensionen:

• Temporally coupled vs. Temporally decoupled

  • zeitlich = beide Prozesse müssen gleichzeitig laufen

• Referentially coupled vs. Referentially decoupled

  =explizite Referenz während der Kommunikation

  • Prozess muss Namen des Kommunikationspartners kennen

-> 4 Arten:

1. direct coordination

   • temporally and referentially coupled

   • Bsp. Telefonat über Mobilphon

2. mailbox

   • referentially coupled and temporally decoupled

   • man tut Brief in Box - muss aber wissen, welche

3. event-based

   • referentially decoupled and temporally coupled

   • man muss nur Benachrichtigung (publish notification) über das Auftreten des Ereignissen schicken

   • Prozesse können sich für Arten von Ereignissen einschreiben (subscribe)

   • Prozesse werden beschrieben, aber nicht Sender oder Empfänger

4. shared data space

   • referentially decoupled and temporally decoupled

   • Kommukation über Tupel

     = strukturierte Datenfelder (wie Zeile in Datentabelle)

   • Prozesse suchen nach Tupel mit Mustern

   • häufig mit publish-subscribe architecture verbunden

   
   

1. Client/ Server-Modell

2. Peer-to-Peer-System

3. Hybride Architekturen

• zentralisierte Architektur

  = vertikale Verteilung/ Architektur

• verschiedene Komponenten auf verschiedene Maschinen

  
  

2 Gruppen von Maschinen:

• Server - implementieren Dienste

• Client - nutzt Dienste durch Schicken von Anfragen

client-server-interaction = request-reply behavior

• Kritik: keine klare Trennung, wer client und wer server ist

Software beim Client oder Server (die 3 Schichten)

• alle Verteilungen möglich

1. fat clients

   • meiste Software beim Client

   • viele verschiedene Versionen nötig (für unterschiedliche Client OS)

   • Verwaltung schwieriger

     • in letzter Zeit weniger valides Arguement

     • durch weniger Abhängigkeiten von idiosynkratischen Umgebungen auf Client-Seite -> mehr einheitliche OS

2. thin clients

   • einfacher zu verwalten

   • weniger schöne Benutzer-Oberflächen

   • langsamer

• Server dient zugleich als client (für Data base)

• Bsp. Webserver als Eingangspunkt, der Anfragen weiter an Anwendungsserver gibt, der wiederum ist Client für Datenbank

• dezentrale Architekturen

  = horizontale Verteilung

  • keine Unterscheidung Client/ Server

  • Client/ Server ist in äquivalente Teile aufgeteilt

  • jeder Teil arbeitet mit seinem Bereich der Daten

  • für bessere Verteilung der Arbeit

• Bsp. Bit-Torrent (FileSharing)

• servant

  • Interaktionen zwischen Prozessen sind symmetrisch

  • Komponente dient als Client und Server zur gleichen Zeit

• nutzt overlay-network

• jeder Prozess kann mit jedem kommunizieren

• jeder Prozess hat volle Funktionalität

• System organisiert sich selbst

• logisches Netzwerk über einem physischen Netzwerk

• Prozesse bilden die Nodes

• Kommunikation nur zwischen im Overlay verbundene Nodens

• Bsp. Chord-System

2 Arten:

1. stukturiert

   • deterministisches overlay-network

   • z.B. Bäume, RInge, Netze (grid)

   • Topologie wird für effiziente Datensuche genutzt

   • basiert auf semantic-free index

     • jedes Daten-Item ist mit einzigartigem Schlüssel verbunden

     • Schlüssel wird als Index genutzt

     • Hashfunktion verwendet, die aus dem Daten-Item den Key berechnet

   • peer-to-peer System speichert (key, value) Paare

   • jede Node speichert Teilmenge der Daten für entsprechende Keys

     -> System implementiert DHT

   • distributed hash table

   • gibt Funktion lookup, die Daten nach ihrem key findet

   • Bsp. Chord system

     
     

2. unstrukturiert

   • jede node hat eine ad-hoc Liste von Nachbarn

   • overlay network ist ein random graph

     • Kanten zwischen zwei nodes nur mit bestimmter Wahrscheinlichkeit

     • Nodes ändern ihre Nachbarschaftslisten kontinuierlich

   • Suche nach Daten - 2 Extreme

3. hierarchisch organsiert (bei unstrukturiert dabei)

   • e.g. broker in content delivery systems (>CDN)

     • Nodes bieten Speicherplatz für Webinhalte

     • Web clients benutzen nahe Seiten

     • broker schauen, wo die Seiten gespeichert werden sollen

       • sammeln Daten zu Resourcennutzung

   • superpeers

1. Flooding

   • node sendet Datenanfrage an alle Nachbarn

   • kennt Nachbar Anfrage, ignoriert sie sie

   • sonst sucht sie lokal oder leitet Anfrage weiter

   • teuer

     • TTL - time to live für Request

       • \= festgelegte Anzahl hops

     • ggf. inkrementelle TTL

       
       

2. Random Walks

   • anfragen zu willkürlich gewählten Nachbarn

   • ggf. n Random Walks starten

     
     

3. policy-based search methods

   • zwischen a und b

   • preferred neighbors, die positiv geantwortet haben

• in hierarchischen Peer-to-Peer-Netzwerken genutzt

• super peers sind Nodes die Daten zur Nutzung sammeln

  • Namen aller verwalteten weak peers

• reguläre Nodes sind "weak peers"

  • zu client über superpeer verbunden

  • tritt weak peer ins Netzwerk ein, teilt er seinem super peer die von ihm zur Verfügung gestellten Daten mit

  • geht er raus, muss super peer alle Informationen über ihn entfernen

• nicht immer feste Zuordnung zu weak zu super peers

  • zum Beispiel bei File-Share System: gerade mit dem super verbinden, dessen Dateien man gerade braucht

• neues Problem: leader election problem (in 6.4 behandelt)