Institute for Software Science – University of ViennaP.Brezany Parallele und verteilte Systeme Peter Brezany Institut für Softwarewissenschaften Universität Wien

Institute for Software Science – University of ViennaP.Brezany 2 Klassifikation paralleler und verteilter Systeme Für Rechensysteme mit mehreren CPU's gibt es die unterschiedlichsten Möglichkeiten der Organisation vor allem der Verbindungsstruktur. Für verteilte Systeme wurden unterschiedliche Klassifikationsschemata entwickelt, von denen sich jedoch keines allgemein durchsetzen konnte. Das wahrscheinlich am häufigsten angewendete Schema ist von Flynn (1972). Flynn unterscheidet zwei Merkmale: die Anzahl der Befehlsströme und die Anzahl der Datenströme. Damit ergeben sich die folgenden Klassen: SISD (Single Instruction Stream, Single Data Stream): Der Rechner hat einen Befehls- und einen Datenstrom. Alle herkömmlichen Einprozessorsysteme fallen unter diese Kategorie. SIMD (Single Instruction Stream, Multiple Data Stream): Hier werden mit einem einzigen Befehlsstrom gleichzeitig mehrere Datenströme verarbeitet. Hierbei handelt es sich um Prozessoren mit einer Befehlseinheit, die eine Anweisung holt und diese Anweisung dann auf mehrere Datenströme anwendet (z.B. sog. Feld, oder Vektorrechner, die eine Anweisung auf alle Komponenten eines Vektors anwenden). Einige Supercomputer gehören zu dieser Klasse. MSID (Multiple Instruction Stream, Single Data Stream): Hier würden mehrere Befehlsströme auf einen Datenstrom angewendet. Es gibt keine Rechner, die nach diesem Prinzip arbeiten. MIMD (Multiple Instruction Stream, Multiple Data Stream): Hier werden mehrere Befehlsströme parallel auf mehrere Datenströme angewendet. Zu dieser Klasse gehören alle verteilten Systeme, so dass diese Klassifikation für die Betrachtung unterschiedlicher Strukturen im Bereich der verteilten System wenig hilfreich ist.

Institute for Software Science – University of ViennaP.Brezany 3 Typische Monoprozessorarchitektur (SISD Architektur)

Institute for Software Science – University of ViennaP.Brezany 4 Feldprozessor (SIMD Architektur)

Institute for Software Science – University of ViennaP.Brezany 5 Schleifenparallelisierung für SIMDSs A typical scientific program spends approx. 90% of its execution time in loops. Example in Java: float A[1000], B[1000]; for (int i = 1; i < 1000; i++) { A[i-1] = B[i]; } The above loop can be expressed in Fortran 95 in the following way: A(0:998) = B(1:999) This statement can be directly mapped onto a SIMD processor. There is an initiative to extend Java by similar constructs.

Institute for Software Science – University of ViennaP.Brezany 6 Parallele Mehrprozessor-Hardware (MIMD Architekturen) Distributed-memory machines (DM Multiprocessors, DM MIMDS) –Each processor has local memory and disk –Communication via message-passing –Hard to program: explicit data distribution –Goal: minimize communication Shared-memory machines (SM Multiprocessors, SM MIMDs, SMPs) –Shared global address space and disk –Communication via shared memory variables –Ease of programming –Goal: maximize locality, minimize false sharing Current trend: Cluster of SMPs

Institute for Software Science – University of ViennaP.Brezany 7 Distributed Memory Architecture (Shared Nothing) Local Memory Local Memory Local Memory Local Memory CPU Interconnection Network CPU

Institute for Software Science – University of ViennaP.Brezany 8 DMM: Shared Disk Architecture Local Memory Local Memory Local Memory Local Memory CPU Interconnection Network Global Shared Disk Subsystem

Institute for Software Science – University of ViennaP.Brezany 9 Schleifenparallelisierung für DM MIMDs Example in Java: float A[10], B[10]; for (int i = 1; i < 10; i++) { A[i] = B[i-1]; } For two processors, P1 and P2, a straightforward solution would be:

Institute for Software Science – University of ViennaP.Brezany 10 Schleifenparallelisierung für DM MIMDs

Institute for Software Science – University of ViennaP.Brezany 11 Schleifenparallelisierung für DM MIMDs Code on P1: float A[5], B[5]; float temp; for (int i = 1; i < 6; i++) { if ( i == 5 ) { receive message from P2 into temp; A[i-1] = temp; { else A[i-1] = B[i]; } Code on P2: float A[5], B[5]; float temp; for (int i = 0; i < 5; i++) { if ( i == 0 ) { temp = B[0]; send temp to P1; { else A[i-1] = B[i]; }

Institute for Software Science – University of ViennaP.Brezany 12 Shared Memory Architecture (Shared Everything, SMP) CPU Interconnection Network CPU Global Shared Memory

Institute for Software Science – University of ViennaP.Brezany 13 Schleifenparallelisierung für SMPs Example in Java: float A[1000], B[1000]; for (int i = 1; i < 1000; i++) { A[i-1] = B[i]; } If we have, e.g. two processors, P1 and P2, a straightforward (non-optimal) solution would be: Code on P1: for (int i = 1; i < 500; i++) { A[i-1] = B[i]; } Code on P2: for (int i = 500; i < 1000; i++) { A[i-1] = B[i]; } Data elements of A and B are stored in the shared memory.

Institute for Software Science – University of ViennaP.Brezany 14 Cluster of SMPs CPU Interconnection Network CPU 4-CPU SMP CPU 4-CPU SMP CPU 4-CPU SMP CPU 4-CPU SMP

Institute for Software Science – University of ViennaP.Brezany 15

Institute for Software Science – University of ViennaP.Brezany 16 Abstraktes Maschinenmodell

Institute for Software Science – University of ViennaP.Brezany 17 Cluster von PCs

Institute for Software Science – University of ViennaP.Brezany 18

Institute for Software Science – University of ViennaP.Brezany 19 Pipeline No Pipeline

Institute for Software Science – University of ViennaP.Brezany 20 Towards Parallel Databases

Institute for Software Science – University of ViennaP.Brezany 21

Institute for Software Science – University of ViennaP.Brezany 22

Institute for Software Science – University of ViennaP.Brezany 23 A Step Towards Parallelization

Institute for Software Science – University of ViennaP.Brezany 24

Institute for Software Science – University of ViennaP.Brezany 25 Grid Idea

Institute for Software Science – University of ViennaP.Brezany 26 Eigenschaften verteilter Systeme In der Literatur finden sich verschiedene Definitionen verteilter Systeme, die teilweise unterschiedliche Aspekte beleuchten. Für die folgenden Betrachtungen soll von einer sehr allgemeinen Definition ausgegangen werden. Ein verteiltes System ist eine Sammlung voneinander unabhängiger Rechner, die dem Benutzer des Systems den Eindruck vermitteln, es handle sich um einen einzigen Rechner. Die Definition hat zwei Aspekte. Der erste Aspekt betrifft die Hardware und bedeutet, dass es sich um autonome Rechner handelt. Der zweite Aspekt betrifft die Software und legt fest, dass die Benutzer eine gemeinsame Schnittstelle sehen.

Institute for Software Science – University of ViennaP.Brezany 27 Vorteile verteilter Systeme gegenüber einem zentralen System Triebkraft der Dezentralisierung der Rechnersysteme waren in der Vergangenheit überwiegend wirtschaftliche und strategische Aspekte. Für zentrale Mainframe-Systeme (der Zeit vor den Mikroprozessoren) wurde von Herb Grosch das sog. "Grosche Gesetz" formuliert, das besagt, dass die Leistungsstärke einer CPU proportional zum Quadrat ihres Preises ist. Wenn doppelt soviel ausgegeben wird, erhält man die vierfache Leistung. Für die Mikroprozessoren trifft dieses Gesetz nicht mehr zu, da man für den doppelten Preis i. a. nur eine etwas höher getaktete CPU erhält. Meist ist es kostengünstiger, eine größere Anzahl billiger CPU's in einem System zu verbinden. Mit den heutigen Mikroprozessoren ist es möglich, ein System mit z.B Prozessoren aufzubauen und so eine Gesamtleistung zu erreichen, die von einem einzigen Prozessor nicht erreicht werden kann.

Institute for Software Science – University of ViennaP.Brezany 28 Vorteile verteilter Systeme (2) Beispiel –Ein Rechner mit CPU's, die jeweils 100 Mips leisten, hätte eine Gesamtleistung von Mips. Wenn ein einzelner Prozessor (ohne interne Parallelität) diese Leistung erbringen sollte, so müsste er eine Anweisung in 1 psec (1x sec) ausführen. Die maximale Ausbreitungsgeschwindigkeit von Signalen wird durch die Lichtgeschwindigkeit begrenzt und das ist 0,3 mm in 1 psec. Eine CPU mit einer Kantenlänge von 0,3 mm wurde bei dieser Taktrate eine so hohe Temperatur erzeugen, dass sie schmelzen würde. Ein weiterer Grund für die Entwicklung verteilter Systeme sind Anwendungsbereiche, die inhärent verteilt sind, wie z.B. Warenhausketten mit vielen Verkaufsstellen und mehreren Warenlagern, das Filialsystem von Banken oder die Zusammenarbeit verteilter Entwicklungsgruppen an einem Projekt.

Institute for Software Science – University of ViennaP.Brezany 29 Vorteile verteilter Systeme (3) Ein weiterer Vorteil eines verteilten Systems ist die gegenüber einem zentralen System gesteigerte Verfügbarkeit, z.B. bei einem Ausfall eines Rechners). Daneben ist schließlich die Möglichkeit des inkrementellen Wachstums ein weiterer Pluspunkt. Oft müssen Daten gemeinsam genutzt werden. So benötigen Reisebüros Zugriff auf Datenbanken für die Flugreservierung oder für Hotelbelegungen. Entwicklungsteams arbeiten auf gemeinsamen Projektdaten. Oft sollen nicht nur Daten sondern auch teuere Peripherie wie z.B. Farblaserdrucker oder große Archiv-Speichergeräte gemeinsam genutzt werden. Verteilte Systeme ermöglichen einen flexiblen Lastausgleich, falls rechenaufwendige Arbeiten verteilt werden können.

Institute for Software Science – University of ViennaP.Brezany 30 Nachteile verteilter Systeme und Lösungen Das verteilte System im Vergleich zu einem zentralisierten System zusätzliche Komplexität für den Anwendungsprogrammierer im Umgang bedeutet. Es ist wünschenswert, diese Komplexität zu verbergen - diese Eigenschaft wird in der Literatur als Transparenz bezeichnet. Transparenzkriterien: –Ortstransparenz: Sie ermöglicht den Zugriff auf eine Komponente ohne Wissen um ihre physische Lokation. –Zugriffstransparenz: Die Art und Weise, wie auf lokale und entfernte Komponenten zugegriffen wird, ist identisch. –Ausfalltransparenz: Der Ausfall einer Komponente ist für den Anwender transparent. –Technologie-Transparenz: Unterschiedliche Technologien, wie beispielsweise Programmiersprachen oder Betriebssysteme, werden vor dem Anwender verborgen. –Concurrency-Transparenz: Dem Anwender bleibt verborgen, dass er sich die Komponenten mit anderen Anwendern teilt.

Institute for Software Science – University of ViennaP.Brezany 31 Prozessstruktur eines vert. Systems Nachricht Prozess/ Rechner

Institute for Software Science – University of ViennaP.Brezany 32 Software-Konzepte Die Software ist in verteilten Systemen entscheidend dafür, wie sich das System an der Benutzerschnittstelle präsentiert. Prinzipiell können zwei Arten von Betriebssystemen für System mit mehreren CPU's unterschieden werden: Lose gekoppelte und eng gekoppelte Systeme. Lose gekoppelte Software ermöglicht es den Rechnern und den Anwendern eines verteilten Systems grundsätzlich unabhängig voneinander zu agieren und dennoch in dem notwendigen Maße zu interagieren. –Beispiel für ein solches System ist eine Gruppe von PC's (oder Workstations), die alle ihr eigenes BS haben, die aber über ein LAN miteinander verbunden sind und die z.B. gemeinsame Netzwerk-Drucker verwenden.

Institute for Software Science – University of ViennaP.Brezany 33 Software Konzepte (2) Bei eng gekoppelten Systemen soll z.B. auf allen CPU's an einer gemeinsamen Aufgabe gearbeitet werden, z.B. ein Schachprogramm, bei dem den CPU's jeweils die Auswertung einer Stellung zugewiesen wird. Wenn die Auswertung beendet ist, gibt der Knoten das Ergebnis zurück und erhält eine neue Stellung zugewiesen.

Institute for Software Science – University of ViennaP.Brezany 34 Aspekte der Kommunikation Das Client-Server-Modell ist eine Möglichkeit, ein verteiltes System zu organisieren. Im Gegensatz zu einem üblichen lokalen System, in dem Services häufig über Unterprogrammaufrufe zur Verfügung gestellt werden, baut das Client-Server-Modell explizit (und für die Anwendung nicht transparent) auf Nachrichten auf. Das Konzept des Remote Procedure Calls (RPC) ermöglicht es Programmen, Prozeduren aufzurufen, die auf anderen Rechnerknoten laufen. Wenn ein Prozess auf einem Rechnerknoten A eine Prozedur auf einem Rechnerknoten B aufruft, dann wird der Prozess auf A solange blockiert, bis die Prozedur auf Rechner B ausgeführt und das Ergebnis zurückgeliefert wurde. Die Probleme, die dabei berücksichtigt werden müssen, sind: Aufrufende und aufgerufene Prozedur laufen in getrennten Adressräumen ab. Parameter und Ergebnis müssen zwischen unterschiedlichen Rechnern übergeben werden.

Institute for Software Science – University of ViennaP.Brezany 35 Client/Server-Model Klient Server Klient Auftrag Antwort

Institute for Software Science – University of ViennaP.Brezany 36 RPC Local vs. remote procedure RPC is an extension of the same type of communication to programs running on different computers; there is still a single thread of execution and the transfer of data between the involved components.

Institute for Software Science – University of ViennaP.Brezany 37 RPC (2) Abbildung 2: Ablauf eines RPC-Aufrufs

Institute for Software Science – University of ViennaP.Brezany 38 RPC (3)

Institute for Software Science – University of ViennaP.Brezany 39 Architektur eines verteilten Systems