Adaptierung durch dynamische Bereitstellung Adaptierung durch dynamische Bereitstellung von Ressourcen von Ressourcen

(1)

Adaptierung durch dynamische Bereitstellung Adaptierung durch dynamische Bereitstellung von Ressourcen

von Ressourcen

Dependable adaptive Systems

Sven Breuner

(2)

Seite 2

Inhaltsübersicht Inhaltsübersicht

1.

Vorüberlegungen

2.

Load balancing

 ...durch Softwarearchitektur

 ...durch zentrale Instanz

 ...durch nachträglichen Ausgleich

3.

Virtualisierung

 Techniken

 Anwendungen

4.

Eine dynamische globale Infrastruktur

 Extremere Arten von Last

 Systeme zur dynamischen Freigabe und Nutzung von Ressourcen

(3)

Vorüberlegungen

(4)

Seite 4

Das klassische Client/Server-Modell Das klassische Client/Server-Modell

Ein Server bedient

mehrere Clients

Client n

Lokales NetzwerkInternet

Client n+m_Welt

(5)

Load Load balancing balancing

(6)

Seite 6

Lastverteilung durch besondere Softwarearchitektur:

Peer-to-Peer-Netzwerke Peer-to-Peer-Netzwerke

 Jeder Peer ist zugleich Client und Server

 nicht mehr „einer bedient alle“-Szenario

 Je mehr Clients, desto mehr Server, die die Last unter sich aufteilen

 Peers nehmen üblicherweise nicht permanent am Netzwerk teil

 Wegfall/Hinzukommen von Peers wird gleich beim Design berücksichtigt (redundante Daten, fehlertoleranter Zugriff)

 Dedizierte Server können zusätzlich zur Performancesteigerung verwendet werden

 „Internettauschbörsen“ sind erfolgreiche Beispiele

(7)

Seite 7

 Keine Strukturierung, keine klare Aufgabentrennung

 Zu komplex, nicht für allgemeine Zwecke geeignet

 Zurückverfolgung und Behebung von Fehlern sehr schwer

 Üblicherweise offene Protokolle, die von diversen Programmen benutzt werden

 Keine Garantie, dass Peers auch Server-Aufgaben übernehmen

 Ungleichgewicht zwischen „ordentlichen“ und „unordentlichen“ Peers mit entsprechend langen Warteschlangen

 Mangelnde Anonymität, Aktionen der Peers können überwacht werden

Lastverteilung durch besondere Softwarearchitektur:

Peer-to-Peer-Netzwerke (2)

(8)

Seite 8

Lastverteilung durch besondere Softwarearchitektur:

Peer-to-Peer-Netzwerke (3)

(9)

Seite 9

Lastverteilung durch zentrale Instanz:

Gateways Gateways

 Zentrale Instanzen existieren bereits in Netzwerken

 z.B. Firewalls

 Datenaustausch im Internet verläuft häufig nach dem einfachen

Request/Response-Schema über HTTP

 HTTP ist zustandslos

(10)

Seite 10

Lastverteilung durch zentrale Instanz:

Gateways (2) Gateways (2)

 Häufig reicht serverseitige Zustandslosigkeit nicht aus (z.B. Warenkorb)

 Sessiondaten können in Datenquelle gespeichert werden,

aber: verstärkte Belastung der Datenquelle

 Gateways benutzen bereits temporäre Zuordnungen

 z.B. IP <-> MAC-Adresse, MAC-Adresse <-> Port

 Gateway könnte Anfragen desselben Clients immer an denselben Server weiterleiten,

aber: kann zu ungleicher Lastverteilung führen

 Gateway könnte Kommunikation analysieren, aber: erhöhte Latenz

(11)

Seite 11

Lastverteilung durch zentrale Instanz:

Gateways (3) Gateways (3)

 Fazit: Auch Gateways sind nicht die perfekte Lösung, eigenen sich aber gut für bestimmte Einsatzzwecke

 z.B. dynamische Websites mit einem gewissen CPU-Aufwand (PHP etc.)

 Könnten noch weiter ergänzt werden um

 Heartbeats zur Vermeidung der Weiterleitung an ausgefallene Server

 Protokoll zur Lastabfrage der einzelnen Server zur automatischen Weiterleitung an weniger ausgelastete Server

 Relativ statischer Aufbau, beschränkt auf LAN, Zugriff auf Datenquelle kann Bottleneck sein

(12)

Seite 12

Lastverteilung durch nachträglichen Ausgleich:

openMosix openMosix

 Problem bei anderen Verfahren zur Lastverteilung:

Vorher ist nicht bekannt, wieviel Last die Anfrage zur Bearbeitungszeit tatsächlich verursachen wird

 also: Ausgleich zur Bearbeitungszeit

(13)

Seite 13

Lastverteilung durch nachträglichen Ausgleich:

openMosix (2) openMosix (2)

 Prozesse müssen immer Zugriff auf ihr ursprüngliches Environment haben

 I/O-intensive Prozesse müssen auf ihren ursprünglichen Node zurück verschoben werden

 Bei geeigneten Prozessen (gleichbleibend CPU- oder

Arbeitsspeicherintensiv, wenig

Festplatten-I/O) bietet openMosix einen optimalen Ausgleich

(14)

Virtualisierung

(15)

Seite 15

Virtualisierungstechniken Virtualisierungstechniken

 Virtualisierung erfordert Hardware- unabhängige Zwischenschicht

 Zwei Möglichkeiten: Veränderung des Betriebssystems oder vollständig virtuelle Umgebung (Virtualisierung zur Laufzeit des Guest-OS)

 Bsp. Xen:

 Betriebssystem in virtueller Umgebung, also Host ohne konkreten Hardwarebezug, ist

„virtual machine“

 Xen ist „virtual machine monitor“

(auch: „Hypervisor“)

 Mehrere virtuelle Maschinen können auf einem realen Host laufen

(16)

Seite 16

Virtualisierungstechniken (2) Virtualisierungstechniken (2)

 Weitere Möglichkeiten

 Hypervisor mit vollständiger Virtualisierung (Bsp. VMware ESX-Server in Verbindung mit VirtualCenter erlaubt Migration ohne

Downtime)

 Host-OS mit Virtualisierungsplattform als Programm

(Bsp. GSX-Server, aber keine Migration ohne Downtime mehr)

 Virtualisierung der CPU-Architektur

 Performance verschlechtert sich zwangsläufig mit höheren Stufen der Virtualisierung

(17)

Seite 17

Anwendungen der Virtualisierung Anwendungen der Virtualisierung

 Durch Virtualisierung werden Computer zu einer Ressource, die nach belieben reserviert (bei Bedarf sogar mehrfach) und wieder

freigegeben werden kann

 Bsp. Unternehmen mit Tageszeit-abhängiger Auslastung der Server

 Migration ohne Downtime

 Keine Änderung der Server-Anzahl

 Einfaches Management durch VirtualCenter oder auch automatisiert

 Zusätzliche Ausfallsicherheit durch Verfügbarkeit der abstrakten Server auf theoretisch beliebigen Hosts im Netz inkl. Environment

 Optimal wären Dienste, die sich flexibel einer dynamischen Anzahl von Hosts anpassen können

(18)

Eine dynamische globale Eine dynamische globale

Infrastruktur

(19)

Seite 19

Extremere Arten von Last:

Sporadisch auftretende Last Sporadisch auftretende Last

 Bsp.: Kleine Unternehmen, wissenschaftliche Einrichtungen (detailgetreue Simulationen, komplexe Probleme)

 Problem: Ergebnisse nicht wertvoll genug zur Anschaffung eines Clusters

• Häufig gemeinsame Anschaffung und Nutzung

 Ideal wäre Dienst, der Freigabe von überschüssigen Ressourcen erlaubt

• Ungenutzte Ressourcen existieren in fast jedem Unternehmen

(20)

Seite 20

Extremere Arten von Last:

Andauernde große Last Andauernde große Last

 Personal Computer sind häufig nicht ausgelastet (vgl. P2P-

Netze)

 Ungenutzte PCs sind in sehr großer Zahl vorhanden

 Bsp. zur Nutzung: SETI@home

(21)

Seite 21

Extremere Arten von Last:

Andauernde große Last (2) Andauernde große Last (2)

 SETI@home realisiert simples, hierarchisches, Client/Server-artiges Modell mit großer Teilnehmerzahl ohne P2P-Nachteile

 Benutzerdaten für andere Nutzer nicht zugänglich

 Data-Server als Proxy zu gemeinsam genutztem Speicher

 Scheduling und gezielte Verteilung von Jobs möglich durch Erfassung statistischer Daten

 Abrechnung möglich durch Anzahl der analysierten Pakete

 Benutzer können Freigabe vollkommen dynamisch starten und beenden

 Projekt erfordert Akzeptanz der Teilnehmer

(22)

Seite 22

Das allgemeine System für beliebige Einsatzzwecke…

 …wäre viel zu komplex, um noch benutzbar zu sein

 …müsste widersprüchliche Anforderungen erfüllen

 Einfache Bedienung <-> komplexe Einstellungsmöglichkeiten

 Performance <-> Sicherheit/Zuverlässigkeit

 …existiert nicht und wäre auch nicht sinnvoll

 Spezialisierung erforderlich

(23)

Seite 23

Grids: Infrastruktur zur dynamischen Freigabe &

Nutzung von Ressourcen

(24)

Seite 24

Das Globus Toolkit: Eine allgemeine Basis für Grids

(25)

Seite 25

Günstige Anwendungsfälle für Grids Günstige Anwendungsfälle für Grids

 Divide-and-Conquer bzw. massiv verteilbare Berechnungen (vgl. SETI@home)

 Jobs mit komplexen Workflows

 Problem Solving Environments zur Generierung der Workflows

 z.B. Analyse von Sensordaten

 Vielleicht irgendwann Unternehmen mit Grid-Nutzung statt eigener Internetserver

 Vielleicht irgendwann „mal eben“ ein paar TB Grid-Speicherplatz nutzen oder 50 Nodes zur Berechnung der KI in einem Echtzeit-Strategiespiel...

 Grids erfordern allerdings sowohl Akzeptanz der Anbieter (Ressourcen für

unbekannte Zwecke zur Verfügung zu stellen) als auch der Verbraucher (Jobs und Daten in unbekannte Hände zu geben)

(26)

Seite 26

Fazit Fazit

 Unterschiedliche Problem-Szenarien erfordern unterschiedliche Lösungen

 Setzen von Prioritäten hilft bei Auswahl der Lösung

 Zuverlässigkeit eines Systems erfordert zuverlässiges Gesamtkonzept

 Fehlerfreiheit eines Programms bedeutet nicht Fehlerfreiheit des Systems (Betriebssystem und andere verwendete Komponenten können Fehler haben)

 In Grids steckt ein großes Potential für viele Arten der Nutzung – Ob und wann es jedoch voll ausgeschöpft werden kann, lässt sich im Moment noch nicht genau

sagen