Adaptierung durch dynamische Bereitstellung von Ressourcen Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Adaptierung durch dynamische Bereitstellung von Ressourcen Dependable adaptive Systems Sven Breuner

Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Inhaltsübersicht Vorüberlegungen Load balancing ...durch Softwarearchitektur ...durch zentrale Instanz ...durch nachträglichen Ausgleich Virtualisierung Techniken Anwendungen Eine dynamische globale Infrastruktur Extremere Arten von Last Systeme zur dynamischen Freigabe und Nutzung von Ressourcen

Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Vorüberlegungen Vor dem eigentlichen Einstieg erstmal Problem bewusst machen Problem: Last zu viel Last für einzelne Rechner/Instanz => Adaptierung notwendig Was bedeutet Last, wie kann man sich die Last vorstellen? 

Das klassische Client/Server-Modell Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Das klassische Client/Server-Modell Ein Server bedient mehrere Clients Lokales Netzwerk Internet Bevorzugtes/klassisches Modell bei verteilten Systemen: n Clients <-> 1 Server Gründe sind Einfachheit, klare Strukturierung/Aufgabentrennung usw. Funktionierte gut bei überschaubarer Anzahl Clients im LAN Dann kam das Internet und die Zahl der Clients stieg drastisch an Außerdem wurde das Leistungsverhältnis zwischen Client und Server wesentlich ausgeglichener => Leistungsfähige Clients mit schnellen Internetanbindungen stellen komplexe Anfragen (Datenbanksuchen, dynamische Websites usw.) Bsp.: eBay hat bis zu 889 Mio. Zugriffe am Tag => Das kann ein einzelner Server nicht bewältigen + einzelner Server ist Single-Point-of-Failure Client n+mWelt Client n

Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Load balancing Wenn ein einzelner Server mit Last überfordert ist, muss die Last verteilt werden Da Client/Server-Modell offenbar nicht gut skaliert, ist Wahl eines alternativen Modells naheliegend Nebenbei gleich Single-Point-of-Failure vermeiden

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

Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Lastverteilung durch besondere Softwarearchitektur: Peer-to-Peer-Netzwerke (2) 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 Bsp.: P2P für Dateisystem mit veränderbaren Dateien kaum vorstellbar

Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Lastverteilung durch besondere Softwarearchitektur: Peer-to-Peer-Netzwerke (3) Fazit: Derartiges Modell nicht für z.B. kommerzielles System mit hohen Qualitätsansprüchen geeignet Aufteilung der Last zwar richtig, aber mehr Struktur/Hierarchie wird benötigt, um: Fehler nachvollziehbar zu machen Informationen vor nicht autorisiertem Zugriff zu schützen => das war bereits einen Schritt zu weit, also zunächst wieder zurück zum LAN

Lastverteilung durch zentrale Instanz: Gateways Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Lastverteilung durch zentrale Instanz: 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

Lastverteilung durch zentrale Instanz: Gateways (2) Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Lastverteilung durch zentrale Instanz: 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

Lastverteilung durch zentrale Instanz: Gateways (3) Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Lastverteilung durch zentrale Instanz: 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 Abschluss: Fortgeschrittene Lastbalancierung v.a. bei rechenintensiven Anfragen effektiv; hier kann man aber auch auf anderer Ebene ansetzen 

Lastverteilung durch nachträglichen Ausgleich: openMosix Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Lastverteilung durch nachträglichen Ausgleich: 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 Load-BALANCING im eigentlichen Sinne des englischen Wortes und nicht nur LastVERTEILUNG wie im Deutschen

Lastverteilung durch nachträglichen Ausgleich: openMosix (2) Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Lastverteilung durch nachträglichen Ausgleich: 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

Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Virtualisierung Erkenntnis: Last besteht nicht permanent (Bsp. nationales Internet-Auktionshaus) Systeme mit hoher Last haben in der Regel hohen Stellenwert, erfordern also Zuverlässigkeit Zuverlässigkeit durch Gesamtkonfiguration, insgesamt erprobtes Environment abstrakter Server Trennung des akstrakten Server-Environments von konkreter Hardware

Virtualisierungstechniken Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM 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 Xen erfordert Änderung des Guest-OS Jeder Guest hat eigene virtuelle Netzwerkkarte, Festplatte usw., aber in Wirklichkeit natürlich nur Scheduling auf einer einzelnen Ressource Fazit Eignet sich nur für Betriebssysteme, deren Rechte-Inhaber Änderungen zulassen Änderungen müssen für jedes Betriebssystem erstmal implementiert werden, bevor man es benutzen kann Aber immerhin sehr performant

Virtualisierungstechniken (2) Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM 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

Anwendungen der Virtualisierung Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM 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 - Vorteilhaft bei Bsp.: Gemeinsames Netzwerk-Dateisystem

Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Eine dynamische globale Infrastruktur Bisherige Lösungsansätze nur für mäßige, regelmäßig wiederkehrende Last Zwei weitere Arten Selten wiederkehrende, zeitlich begrenzte Last Andauernde extreme Last Nächste Folien Zeigen spezielle Lösungsmöglichkeiten Bieten Anforderungshinweise für ein allgemeiner einsetzbares System

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

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

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

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

Grids: Infrastruktur zur dynamischen Freigabe & Nutzung von Ressourcen Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Grids: Infrastruktur zur dynamischen Freigabe & Nutzung von Ressourcen Vision: Nutzung so einfach wie beim Stromnetz („power grid“) Allgemeines Konzept, aber kein Versuch _allen_ Anforderungen gerecht zu werden Konzepte Virtuelle Organisationen Virtuelle Ressourcen Hierarchische Struktur Möglichkeit zur Nutzung nach Bedarf mit genauer Kosten/Nutzen-Relation Vorrangige Anwendungsmöglichkeit momentan: massiv verteilte Berechnungen

Das Globus Toolkit: Eine allgemeine Basis für Grids Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Das Globus Toolkit: Eine allgemeine Basis für Grids Komponenten anhand eines Beispiel-Jobs Was ist ein Job? (Job-Description) Autorisation GridFTP (Problem: Ziel/Quelle muss spezifiziert werden), File-Transfer Scheduling (verschiedene Arten: Zuweisender Scheduler, lokale Scheduler mit globaler Job-Queue, advance Reservation) Geeignete Ressourcen finden (MDS) Ausführung überwachen Evtl. Kostenabrechnung Ergebnisse ablegen, aufräumen Job-Sender benachrichtigen (Trigger)

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)

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