9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim

Transkript

1 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 1/31 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim Christian Baun, Viktor Mauch Karlsruher Institut für Technologie Steinbuch Centre for Computing [baun

2 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 2/31 Wiederholung vom letzten Mal Grid-Computing Definitionen Klassifikation Unterscheidungen Middleware-Systeme UNICORE Globus Toolkit glite XtreemOS dcache Grid-Projekte EGEE EGI D-Grid Grid-Computing vs. Cloud-Computing

3 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 3/31 Heute (P2P) Grundlagen Einsatzgebiete Zentralisiertes P2P Napster Pures bzw. Reines P2P Gnutella Version 0.4 Hybrides P2P Gnutella Version 0.6 FastTrack BitTorrent BOINC

4 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 4/31 Grundlagen Ein -System ist ein Verbund gleichberechtigter Knoten Knoten werden als Peers bezeichnet Knoten machen sich gegenseitig Ressourcen zugänglich Jeder Knoten ist gleichzeitig Client und Server Geeignet, um dezentral organisierte Arbeitsumgebungen aufzubauen Andy Oram A system is a self-organizing system of equal, autonomous entities (peers) which aims for the shared usage of distributed resources in a networked environment avoiding central services. Schreibweise Eine einheitliche Schreibweise existiert nicht. Häufig wird auch P2P oder Peer-2-Peer (mit oder ohne Bindestriche) geschrieben

5 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 5/31 Einsatzgebiete von Austausch von Daten (File Sharing) Überwiegender Einsatz als Tauschbörsen Ziel: Verteilung großer Datenmengen möglichst schnell an viele Benutzer Problem von Urheberrechtsverletzungen Zukünftige Verbesserungen sind besonders im Bereich der Anonymisierung zu erwarten Anwendungen: BitTorrent, Napster, Gnutella, Kazaa, Overnet Kommunikation und Zusammenarbeit Instant Messaging Systeme für Textnachrichten und Chat Sichere und anonyme Kommunikation (Freenet) Kostengünstige und hochverfügbare Groupware (Groove) Anwendungen: ICQ, AIM, MSN, Jabber, Freenet, Groove, usw.

6 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 6/31 Napster Napster war der Pionier des File-Sharing Entwickelt von Shawn Fanning (Student in Boston) Aktiv von Juni 1999 bis Juli 2001 Napster war zentralisiertes P2P Napster enthielt ein zentralisiertes Indexing Clients laden ihre Dateiliste auf den Napster-Server Clients befragen den Index-Server und erhalten eine vollständige Anbieterliste Datenaustausch erfolgte unmittelbar zwischen den Peers Ab Dezember 1999: Massive juristische Probleme mit der Musikindustrie und Künstlern 2001: Napster erreicht seinen Peak mit 77 Millionen Benutzern Juli 2001: Napster schaltet seinen Dienst ab

7 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 7/31 Napster Protokoll

8 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 8/31 Napster (Häufiges Bild aus jenen Tagen... )

9 Client-Server im Vergleich zu zentralisiertem P2P Was sind die Vor-/Nachteile von zentralisiertem P2P im Vergleich zu Client-Server? Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS2011 9/31

10 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Vor- und Nachteile von zentralisiertem P2P Vorteile: Peers kommunizieren direkt miteinander Server hat nur wenige Aufgaben Sehr gute Erweiterbarkeit Jeder weitere Peer verursacht nur wenig Last auf dem Server Ausfall einzelner oder mehrerer Peers kann dem Netzwerk und der Verfügbarkeit der Dienste nichts anhaben Zentralisierte Dienste bieten eine hohe Leistung Zentralisierter Dienst ist ein bekannter Einstiegspunkt Neue Peers können leicht Teil des Systems werden Nachteile: Server verursachen Kosten (Strom, Stellfläche, Administration,... ) Ohne die zentralisierten Dienste funktioniert das System nicht Zentralisierte Dienste sind immer ein Angriffspunkt Juristische Angriffsfläche

11 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Gnutella Entwickelt von Justin Frankel und Tom Pepper bei der Firma Nullsoft (Winamp) Quellcode unter der GNU General Public License (GPL) März 2000: Erste Version Grund für die Entwicklung Steigende Probleme von Napster 1999/2000 Klagen der Musikindustrie Napster verwendete Server zur zentralisierten Indexierung Zentrale Server machen angreifbar! Ziel: Entwicklung einer Alternative, die ohne Server auskommt AOL Eigentümer von Nullsoft zog die Software zurück Aber wenn der Quellcode schon mal unter der GPL freigegeben ist... Bekannte Clients: LimeWire, Morpheus, Shareaza, BearShare Gnutella ist heute ein Synonym für das Protokoll und weniger für eine spezielle Software

12 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Gnutella Protokoll Version Alle Peers sind gleichberechtigte Teilnehmer im Netzwerk Es gibt keine zentralisierten Dienste (Server) = Reines/Pures P2P Jeder Peer muss mindestens einen weiteren Knoten kennen Jeder Peer verwaltet eine Liste von ihm bekannten Peers Jeder Peer ist mit maximal 5 weiteren Peers aktiv verbunden Hat ein Peer einen Suchauftrag, sendet er ihn an alle mit ihm aktiv verbunden Peers Die Weiterleitungen werden als Hops bezeichnet Jeder Suchauftrag macht maximal 7 Hops Nachteile: Suchanfragen dauern sehr lange Das Netzwerk wird mit Suchanfragen geflutet

13 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Gnutella Protokoll

14 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Reines P2P im Vergleich zu Reinem P2P P2P ohne dedizierte Server bezeichnet man als Reines oder Pures P2P Was sind die Vor-/Nachteile von Reinem P2P?

15 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Vor- und Nachteile von Reinem/Purem P2P Vorteile: Keine Abhängigkeit von Servern. Peers kommunizieren direkt miteinander Keine zentralen Angriffspunkte System (Netzwerk) ist kaum zu zerstören Ausfall einzelner oder mehrerer Peers kann dem Netzwerk und der Verfügbarkeit der Dienste nichts anhaben Höhere Selbstbestimmung der Benutzer Bei Client-Server muss bei steigender Anzahl von Clients auch die Serverleistung steigen Kein Administrationsaufwand, da keine Server Nachteile: Schwieriger Einstieg Es muss mindestens ein Peer bekannt sein Suchanfragen sind eine starke Belastung für das Netzwerk Listen von Daten und Peers müssen verteilt werden (hoher Overhead) Beispiele für Reines P2P: Gnutella (Version 0.4) und Freenet

16 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Technische Dateils von Gnutella 0.4 Das Protokoll von Gnutella 0.4 arbeitet mit TCP/IP-Verbindungen Gnutella-Pakete haben folgenden Aufbau: Message ID (16 Byte) zur Identifikation Function ID (1 Byte). Kann eines der folgenden sein: Ankündigung (Advertisement) Suchanfrage (Query) Download-Anforderung (Push-Request) TTL (1 Byte). Gibt an wie viele Hops ein Paket machen darf Hops (1 Byte). Zähler für die Hops Payload length (4 Byte). Länge der Nutzdaten in Bytes

17 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Reines P2P hat Grenzen Netzwerkbelastung von Reinem P2P lässt das System bei einer hohen Anzahl von Peers unbenutzbar werden Langsam Netzwerkoverhead zu hoch Alternative: Zentralisierte Dienste mit dedizierten Servern Nicht erwünscht Alternative: Hybrides

18 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Hybrides P2P: Gnutella Protokoll Version 0.6 Unterscheidung der Knoten in Blattknoten (Leaf Nodes) und Ultrapeers Jeder Blattknoten ist mit maximal 3 Ultrapeers verbunden Jeder Ultrapeer ist mit maximal 16 weiteren Ultrapeers und 16 Blattknoten verbunden Jeder Suchauftrag macht nur maximal 4 Hops Neues Protokoll: Query Routing Protocol (QRP) Suchanfragen Leitungsprotokoll Kurzfassung des QRP Jeder Blattknoten schickt seinem Ultrapeer eine Liste der Namen innerhalb der Dateinamen der angebotenen Dateien Suchanfragen werden nur an Peers weitergeleitet, bei denen die Liste der Namen erfolgversprechend ist Die Ultrapeers tauschen die Namenslisten untereinander aus Hybrides P2P realisiert eine Art dynamischen, zentralisierten Dienst Vorteile von Reinem P2P bleiben erhalten

19 Gnutella: Ultrapeers und Blattknoten Quelle: Jörg Eberspächer und Rüdiger Schollmeier. First and Second Generation of Systems (2005). LNCS 3485 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31

20 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 FastTrack (Protokoll von KaZaA) Das FastTrack-Protokoll basiert auf dem Gnutella Protokoll 0.6 Supernodes agieren als vorübergehende Indexserver für langsamere Peers Die Skalierbarkeit des Netzwerks wird dadurch erhöht Ablauf: In der Client-Software ist eine Liste von IPs einiger Supernodes enthalten Die Client-Software versucht eine Verbindung diesen bekannten Supernodes herzustellen Wurde ein Supernode erreicht, ruft die Client-Software die Liste von derzeit aktiven Supernodes ab Client sucht sich einen Supernode aus, dem er eine Liste der angebotenen Dateien hochlädt und über den er sämtliche Suchanfragen stellt Der Supernode kommuniziert mit weiteren Supernodes, um Suchanfragen der Clients zu erfüllen Wurde eine gesuchte Datei gefunden, baut die Client-Software eine direkte Verbindung zur Quelle auf, und die Datei wird über HTTP übertragen

21 (File-Sharing) Netzwerke kleine Auswahl Quelle: explanation.asp Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31

22 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Aktuellste Entwicklung: BitTorrent System zur schnellen Verteilung großer Datenmengen Entwickelt von Bram Cohen Juli 2001: Erste Version Im System selbst kann man nicht nach Daten suchen Will ein Peer eine oder mehr zusammenhänge Dateien herunterladen, benötigt er die passende Torrent-Datei Enthält die IP-Adresse des Trackers, Dateigröße und eine Liste von Prüfsummen von Segmenten Torrent-Dateien sind nur wenige KB groß und werden überwiegend auf speziellen Web-Seiten gesammelt und angeboten Ein Tracker verwaltet für jeden Torrent eine Liste von Peers, die Teile der Datei besitzen Ein BitTorrent-Client erhält vom Tracker diese Liste Mit der Liste kann der Client (Peer) nun direkt bei den anderen Peers mit Teilen der gesuchten Datei anfragen

23 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Aktuellste Entwicklung: BitTorrent (2) Segmente einer Datei bezeichnet man als Chunks Menge aller Peers, die am gleichen Torrent interessiert sind: Schwarm Peers, die im Besitz des kompletten Torrents sind und somit nichts mehr von anderen Peers herunterladen, sondern lediglich verteilen, heißen Seeds Peers, die noch nicht im Besitz des kompletten Torrents sind und somit von anderen Peers herunterladen, heißen Leechs Ist der Tracker nicht mehr verfügbar, ist die Torrent-Datei nutzlos Ohne funktionierenden Tracker kann keine aktuelle Liste mit Seeds/Leechs bezogen werden Will man selbst etwas anbieten, muss man einen Tracker betreiben und die passende Torrent-Datei anbieten/verteilen

24 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 BitTorrent Protokoll

25 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 BitTorrent in Cloud-Infrastrukturen BitTorrent ist eine hocheffiziente Lösung zur Verteilung großer Datenmengen Ein Beispiel, wo große Datenmengen möglichst rasch übermittelt werden müssen, ist das Verteilen von Images auf die physischen Knoten in Cloud-Infrastrukturen Das CERN betreibt einen virtuellen Cluster auf Basis von OpenNebula Cluster wird mit bis zu virtuellen Maschinen dynamisch erweitert Maximal Rechenjobs können in annehmbarer Zeit vom LSF-Scheduler verarbeitet werden Verteilung der Images und Daten im Cluster am besten via BitTorrent

26 P2P Zusammenfassung Quelle: Jörg Eberspächer und Rüdiger Schollmeier. First and Second Generation of Systems (2005). LNCS 3485 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31

27 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 P2P-Weg der verteilten Datenhaltung in Clouds Der P2P-Gedanke ist u.a. hilfreich um einen virtuellen Cluster mit gemeinsamem Datenbestand in einer EC2-kompatiblen Cloud-Infrastruktur zu realisieren 3 Möglichkeiten der Cloud-basierten Datenspeicherung Instanzspeicher (blockbasiert, nicht persistent) EBS-Volumen (blockbasiert, persistent) S3-Buckets (objektbasiert, persistent) Ein EBS-Volumen kann immer nur an genau eine Instanz in EC2 angehängt sein EBS-Volumen können mit verteilten Dateisystemen wie Ceph, GlusterFS, PVFS2 oder HDFS verbunden werden Diese Dateisysteme arbeiten vollständig verteilt (= P2P) Ceph, GlusterFS und HDFS bieten sogar interne Redundanz

28 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Abgrenzungen zwischen den Technologien Cluster sind keine Grids, können aber Ressourcen in einem Grid sein Cluster gehören in der Regel einer einzigen Organisation Ressourcen in Grids gehören verschiedenen Organisationen und werden von diesen administriert Knoten bei P2P gehören den Benutzern und werden von diesen selbst verwaltet Distributed Computing-Projekte sind keine Computational Grids File Sharing Netzwerke (P2P) sind keine Data Grids Distributed Computing-Projekte, die auf einem offenen, flexibel einsetzbaren Standard wie BOINC basieren und die Kriterien eines Grid erfüllen, können als Grids bezeichnet werden P2P kann auch in Kombination mit Clouds hilfreich sein

29 Wuala Kombination aus P2P und Cloud (1) Wuala ist ein Dienst, der Onlinespeicher anbietet Entwicklung der ETH Zürich Seit März 2009 gehört Wuala zum Unternehmen LaCie Wuala nutzt eigene Server und ein P2P-Netzwerk aus Rechnern freiwilliger Benutzer, die lokalen Speicherplatz gegen Onlinespeicher tauschen möchten Über diese Ressourcen legt Wuala eine Art Speicher-Cloud Jeder Benutzer erhält kostenlos 1 GB Speicherplatz Möchte ein Benutzer mehr Speicherplatz, kann er diesen käuflich erwerben oder lokalen Speicherplatz im Tausch zur Verfügung stellen Bedingung für den Tausch: Der Computer, auf dem Wuala läuft, muss mindestens 4 Stunden pro Tag online sein Formel: lokaler Speicher Onlinezeit-Faktor = Onlinespeicher Beispiel: Ein Benutzer bietet 10 GB lokalen Speicher und sein Rechner ist 6 Stunden online, also 25% der möglichen täglichen Zeit = 10 GB 0, 25 = 2, 5 GB Onlinespeicher Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31

30 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Wuala Kombination aus P2P und Cloud (2) Benutzer können lokalen Speicherplatz von mehreren Rechnern freigeben, um selbst mehr Onlinespeicher zu erhalten Alle Daten werden vor dem Upload in die Wuala-Cloud fragmentiert und mit einem 128-Bit AES-Algorithmus verschlüsselt Fragmente werden redundant in der Wuala-Cloud verteilt Wuala sichert alle Fragmente mindestens einmal auf eigenen Servern in Europa Daten bleiben immer erreichbar, auch wenn alle P2P-Knoten offline sind Wer keinen lokalen Speicherplatz tauschen kann oder will, kann Onlinespeicher kaufen. Ab 10 GB für e19 pro Jahr Client-Software ist Freeware (nicht Open Source) und verfügbar für Linux, Mac OS X und Windows Neben der Java-Client-Software gibt es eine REST API

31 Christian Baun, Viktor Mauch 9.Vorlesung Cluster-, Grid- und Cloud-Computing Hochschule Mannheim SS /31 Nächste Vorlesung Nächste Vorlesung: