Upload
maja-straub
View
213
Download
0
Embed Size (px)
Citation preview
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