Adaptierung durch dynamische BereitstellungAdaptierung durch dynamische Bereitstellungvon Ressourcenvon Ressourcen

Dependable adaptive Systems

Sven Breuner

Seite 2

InhaltsübersichtInhaltsübersicht

1. Vorüberlegungen2. 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

VorüberlegungenVorüberlegungen

Seite 4

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

Ein Server

bedient

mehrere Clients

Client n

Lokales NetzwerkInternet

Client n+mWelt

LoadLoad balancingbalancing

Seite 6

Lastverteilung durch besondere Softwarearchitektur:Lastverteilung durch besondere Softwarearchitektur:Peer-to-Peer-NetzwerkePeer-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

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:Lastverteilung durch besondere Softwarearchitektur:Peer-to-Peer-Netzwerke (2)Peer-to-Peer-Netzwerke (2)

Seite 8

Lastverteilung durch besondere Softwarearchitektur:Lastverteilung durch besondere Softwarearchitektur:Peer-to-Peer-Netzwerke (3)Peer-to-Peer-Netzwerke (3)

Seite 9

Lastverteilung durch zentrale Instanz:Lastverteilung durch zentrale Instanz:GatewaysGateways 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

Seite 10

Lastverteilung durch zentrale Instanz: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

Seite 11

Lastverteilung durch zentrale Instanz: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

Seite 12

Lastverteilung durch nachträglichen Ausgleich:Lastverteilung durch nachträglichen Ausgleich:openMosixopenMosix Problem bei anderen Verfahren zur Lastverteilung:Vorher ist nicht bekannt, wieviel Last die Anfrage zur Bearbeitungszeit tatsächlich verursachen wird

also: Ausgleich zur Bearbeitungszeit

Seite 13

Lastverteilung durch nachträglichen Ausgleich: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

VirtualisierungVirtualisierung

Seite 15

VirtualisierungstechnikenVirtualisierungstechniken

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

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

Seite 17

Anwendungen der VirtualisierungAnwendungen 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

Eine dynamische globale Eine dynamische globale InfrastrukturInfrastruktur

Seite 19

Extremere Arten von Last:Extremere Arten von Last:Sporadisch auftretende LastSporadisch 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

Seite 20

Extremere Arten von Last:Extremere Arten von Last:Andauernde große LastAndauernde 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

Seite 21

Extremere Arten von Last: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

Seite 22

Das allgemeine System für beliebige Einsatzzwecke…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

Seite 23

Grids: Infrastruktur zur dynamischen Freigabe & Grids: Infrastruktur zur dynamischen Freigabe & Nutzung von RessourcenNutzung von Ressourcen

Seite 24

Das Globus Toolkit: Eine allgemeine Basis für GridsDas Globus Toolkit: Eine allgemeine Basis für Grids

Seite 25

Günstige Anwendungsfälle für GridsGü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 oder50 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)

Seite 26

FazitFazit

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