Parallele und verteilte Systeme Peter Brezany Institut fr
Parallele und verteilte Systeme Peter Brezany Institut für Softwarewissenschaften Universität Wien P. Brezany Institute for Software Science – University of Vienna
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. P. Brezany Institute for Software Science – University of Vienna 2
Typische Monoprozessorarchitektur (SISD Architektur) P. Brezany Institute for Software Science – University of Vienna 3
Feldprozessor (SIMD Architektur) P. Brezany Institute for Software Science – University of Vienna 4
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. P. Brezany Institute for Software Science – University of Vienna 5
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 global address space and disk Communication via shared memory variables Ease of programming Goal: maximize locality, minimize false sharing • Shared-memory machines (SM Multiprocessors, SM MIMDs, SMPs) • Current trend: Cluster of SMPs P. Brezany Institute for Software Science – University of Vienna 6
Distributed Memory Architecture (Shared Nothing) Interconnection Network P. Brezany CPU CPU Local Memory Institute for Software Science – University of Vienna 7
DMM: Shared Disk Architecture Interconnection Network CPU CPU Local Memory Global Shared Disk Subsystem P. Brezany Institute for Software Science – University of Vienna 8
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, P 1 and P 2, a straightforward solution would be: P. Brezany Institute for Software Science – University of Vienna 9
Schleifenparallelisierung für DM MIMDs P. Brezany Institute for Software Science – University of Vienna 10
Schleifenparallelisierung für DM MIMDs Code on P 1: float A[5], B[5]; float temp; for (int i = 1; i < 6; i++) { if ( i == 5 ) { receive message from P 2 into temp; A[i-1] = temp; { else A[i-1] = B[i]; } Code on P 2: float A[5], B[5]; float temp; for (int i = 0; i < 5; i++) { if ( i == 0 ) { temp = B[0]; send temp to P 1; { else A[i-1] = B[i]; } P. Brezany Institute for Software Science – University of Vienna 11
Shared Memory Architecture (Shared Everything, SMP) Interconnection Network CPU CPU Global Shared Memory P. Brezany Institute for Software Science – University of Vienna 12
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, P 1 and P 2, a straightforward (non-optimal) solution would be: Code on P 1: for (int i = 1; i < 500; i++) { A[i-1] = B[i]; } Code on P 2: for (int i = 500; i < 1000; i++) { A[i-1] = B[i]; } Data elements of A and B are stored in the shared memory. P. Brezany Institute for Software Science – University of Vienna 13
Cluster of SMPs Interconnection Network P. Brezany CPU CPU CPU CPU 4 -CPU SMP Institute for Software Science – University of Vienna 14
P. Brezany Institute for Software Science – University of Vienna 15
Abstraktes Maschinenmodell P. Brezany Institute for Software Science – University of Vienna 16
Cluster von PCs P. Brezany Institute for Software Science – University of Vienna 17
P. Brezany Institute for Software Science – University of Vienna 18
No Pipeline P. Brezany Institute for Software Science – University of Vienna 19
Towards Parallel Databases P. Brezany Institute for Software Science – University of Vienna 20
P. Brezany Institute for Software Science – University of Vienna 21
P. Brezany Institute for Software Science – University of Vienna 22
A Step Towards Parallelization P. Brezany Institute for Software Science – University of Vienna 23
P. Brezany Institute for Software Science – University of Vienna 24
Grid Idea P. Brezany Institute for Software Science – University of Vienna 25
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. P. Brezany Institute for Software Science – University of Vienna 26
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 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. 10. 000 Prozessoren aufzubauen und so eine Gesamtleistung zu erreichen, die von einem einzigen Prozessor nicht erreicht werden kann. P. Brezany Institute for Software Science – University of Vienna 27
Vorteile verteilter Systeme (2) Beispiel – Ein Rechner mit 10. 000 CPU's, die jeweils 100 Mips leisten, hätte eine Gesamtleistung von 1000. 000 Mips. Wenn einzelner Prozessor (ohne interne Parallelität) diese Leistung erbringen sollte, so müsste er eine Anweisung in 1 psec (1 x 10 -12 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. P. Brezany Institute for Software Science – University of Vienna 28
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. P. Brezany Institute for Software Science – University of Vienna 29
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. P. Brezany Institute for Software Science – University of Vienna 30
Prozessstruktur eines vert. Systems Nachricht Prozess/ Rechner P. Brezany Institute for Software Science – University of Vienna 31
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. P. Brezany Institute for Software Science – University of Vienna 32
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. P. Brezany Institute for Software Science – University of Vienna 33
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. P. Brezany Institute for Software Science – University of Vienna 34
Client/Server-Model Klient Auftrag Klient P. Brezany Server Antwort Institute for Software Science – University of Vienna Klient 35
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. P. Brezany Institute for Software Science – University of Vienna 36
RPC (2) Abbildung 2: Ablauf eines RPC-Aufrufs P. Brezany Institute for Software Science – University of Vienna 37
RPC (3) P. Brezany Institute for Software Science – University of Vienna 38
Architektur eines verteilten Systems P. Brezany Institute for Software Science – University of Vienna 39
- Slides: 39