close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

Einfuehrung - Linux Cluster in Theorie und Praxis

EinbettenHerunterladen
Zentrum f¨
ur Informationsdienste und Hochleistungsrechnen – TU Dresden
Linux Cluster in Theorie und Praxis
Cluster Computing – Einf¨
uhrung
Thomas William
16. Oktober 2014
WIL A35
Zellescher Weg 12
01069 Dresden
Telefon: +49 351 - 463 32446
E-Mail: thomas.william@tu-dresden.de
Inhalt
1
Entstehung und Ziele von LCTP
2
Grundlagen paralleler Architekturen und der Parallelverarbeitung
3
Cluster
4
Literatur
2/59
1
Entstehung und Ziele von LCTP
3/59
Entstehung und Ziele von LCTP I
Teilnahme an der Clusterchallenge auf der Supercomputing’08
Rahmenbedingungen des Wettbewerbs:
Aufsetzen eines Clusters durch Studenten
Leistungsaufnahme auf 3kW begrenzt
Vorgegebener Workload
Bewertung der Anzahl verarbeiteter Jobs innerhalb von 44 Stunden
4/59
Entstehung und Ziele von LCTP II
5/59
Entstehung und Ziele von LCTP III
Abbildung des Systems Engineering Prozesses auf eine u
¨berschaubare
Lernumgebung
Theoretische Betrachtungen mit praktischen Erfahrungen untermauern
Kooperative Bearbeitung komplexer Aufgaben
Selbstst¨andiges Erkennen, Analysieren und L¨
osen von Problemen f¨ordern
Grundlagen des Projektmanagements vermitteln
6/59
2
Grundlagen paralleler Architekturen und der Parallelverarbeitung
7/59
Parallelrechner und parallele Architektur
Parallelrechner
A collection of processing elements that communicate and cooperate to solve
large problems fast. (Almasi und Gottlieb, 1989)
Parallele Architektur
It extends the usual concepts of a computer architecture with a
communication architecture. (Culler, Singh und Gupta, 1998)
8/59
Parallelrechner und parallele Architektur
Parallelrechner
A collection of processing elements that communicate and cooperate to solve
large problems fast. (Almasi und Gottlieb, 1989)
Parallele Architektur
It extends the usual concepts of a computer architecture with a
communication architecture. (Culler, Singh und Gupta, 1998)
Definitionen treffen heute auf nahezu alle Rechnersysteme zu!
8/59
Multiprozessorsysteme
Definition
Bei einem Multiprozessorsystem handelt es sich um ein Rechnersystem, welches
als wesentliches Merkmal u
ugt. Die
¨ber mehr als einen physischen Prozessor verf¨
Prozessoren von durchaus unterschiedlicher Komplexit¨at k¨onnen
unabh¨angig voneinander verschiedene Jobs verarbeiten
miteinander kommunizieren
und teilweise auch kooperieren
um verschiedene Aufgaben gemeinsam zu bearbeiten. Dies impliziert auch
asynchrone Parallelverarbeitung.
9/59
Klassifikation von Multiprozessorsystemen
Klassifikation nach Flynn
Speicherorganisation und Adressraum
Verbindungsstruktur zwischen den Verarbeitungseinheiten
Verarbeitungsprinzip
Speicher-/nachrichtengekoppelte Multiprozessorsysteme
10/59
Architekturen innerhalb der Top500-Liste
Abbildung: Parallele Architekturen innerhalb der Top500-Liste [Top500]
11/59
Cluster
Definition
Als Cluster werden Multiprozessorsysteme bezeichnet, die sich aus
Standardkomponenten zusammensetzen. Dabei stellt jeder Knoten in sich
wiederum ein eigenst¨andiges System dar. Somit k¨
onnen die Knoten auch
unabh¨angig voneinander arbeiten und es kann Software eingesetzt werden,
welche f¨
ur Arbeitsplatzsysteme entwickelt wurde.
12/59
Massive Parallel Processing (MPP)
Definition
Massive Parallel Processing (MPP) bezieht sich auf Systeme mit einer großen
Anzahl voneinander unabh¨angiger Funktionseinheiten. Die Bedeutung des
Terms ”massive” ist abh¨angig vom technischen Fortschritt und kann nicht
exakt definiert werden. Daher erfolgt die Einordnung i.d.R. anhand der
verwendeten Komponenten. In MPP-Systemen kommt - im Gegensatz zu
Clustern - propriet¨are Hard- und Software zum Einsatz.
13/59
Parallelverarbeitung nach Sterling (2007) I
Capacity Computing
A strategy for employing distributed computing resources to achieve high
throughput processing among decoupled tasks. Aggregate performance of the
total system is high if sufficient tasks are available to be carried out concurrently
on all separate processing elements. No single task is accelerated.
14/59
Parallelverarbeitung nach Sterling (2007) II
Capability Computing
A strategy for employing tightly couple structures of computing resources to
achieve reduced execution time of a given application through partitioning in
to concurrently executable tasks.
15/59
Parallelverarbeitung nach Sterling (2007) III
Cooperative Computing
A strategy for employing moderately coupled ensemble of computing resources
to increase size of the data set of a user application while limiting its execution
time.
16/59
Capacity vs. Capability Computing
Fr¨
uhzeitige Entscheidung f¨
ur Capacity oder Capability Computing
Analyse des zu l¨
osenden Problems (Workload)
Auswahl des Systems anhand des auszuf¨
uhrenden Workloads
17/59
3
Cluster
Geschichte des Cluster Computings
Hardware
Systemsoftware
Anwendungssoftware
18/59
3
Cluster
Geschichte des Cluster Computings
Hardware
Systemsoftware
Anwendungssoftware
19/59
Entstehung des Cluster Computings
Superrechner waren teuer aufgrund hoher Entwicklungskosten und
geringer St¨
uckzahlen
Entwicklung von Parallelrechnern aus Standardkomponenten erstmals
1994 von Donald Becker und Thomas Sterling im ,,Center of Excellence
in Space Data and Information Sciences (CEDIS)”
Pr¨agung des Begriffs ,,Beowulf-Cluster”
Abbildung: Erstes Beowulf-Cluster ,,Avalon” innerhalb der Top500-Liste [Top500]
20/59
Entwicklung des Cluster Computings
Abbildung: Architekturentwicklung innerhalb der Top500-Liste [Top500]
21/59
Cluster heute
Verwendung von COTS-Hardware mit erh¨
ohten Qualit¨atsanforderungen
Erh¨
ohung der Packungsdichte dank professioneller Servergeh¨ause
Engere Kopplung mit Hilfe neuer Netzwerktechnologien
Unterschiede zwischen Cluster- und MPP-Systemen werden geringer
Abbildung: SuperMUC Petascale System des LRZ M¨
unchen
22/59
3
Cluster
Geschichte des Cluster Computings
Hardware
Systemsoftware
Anwendungssoftware
23/59
Hardware / Aufbau eines Clusters
Node
Node
Node
RAM
RAM
RAM
CPU
CPU
Core Core
Core Core
GrafikKarte
Input / Output
HDD
CPU
Core Core
Core Core
Node
Core Core
GrafikKarte
Core Core
Input / Output
GrafikKarte
Input / Output
HDD
HDD
RAM
CPU
Core Core
Core Core
GrafikKarte
Input / Output
HDD
Interconnect Fabric
Storage
Storage
Abbildung: Schematische Darstellung des Aufbaus eines Cluster-Systems
24/59
Hardware / Homogenit¨at und Heterogenit¨at
Definition
Sind sowohl Hardware als auch Betriebssystem aller Rechnerknoten
(weitestgehend) identisch, so spricht man von einem homogenen Cluster,
andernfalls ist das Cluster heterogen.
25/59
Hardware / CPU
x86: i7, Xeon, Opteron, Core, Phenom ...
Preiswert aufgrund hoher St¨
uckzahlen
Ausreichende Performance
Softwarekompatibilit¨
at
Sparc: Oracle Niagara oder Fujitsu
Teurer, spezialisiert
F¨
ur (Web)server-Cluster (SSL, Mail, Datenbanken, ...)
Integer-lastige Anwendungen k¨
onnen von Sparc profitieren
Power:
Preisintensiv
Hoher Fließkommadurchsatz bei gleichzeitig hoher Packungsdichte
Hochverf¨
ugbarkeitssysteme, Mainframes, MPP-Systeme ([BlueGene])
26/59
Hardware / Festplatten
Zwei Gr¨
unde die f¨
ur Festplatten in jedem Knoten sprechen:
Swap File System f¨
ur Jobs mit hohen Resourcenanforderungen
Scratch File System zum Abspeichern von Zwischenergebnissen
27/59
Hardware / Festplatten
Zwei Gr¨
unde die f¨
ur Festplatten in jedem Knoten sprechen:
Swap File System f¨
ur Jobs mit hohen Resourcenanforderungen
Scratch File System zum Abspeichern von Zwischenergebnissen
Zwei Gr¨
unde dagegen:
Verbraucht zus¨atzlich Strom
Verschleißteil
27/59
Hardware / Grafikkarten
Prinzipiell u
ussig
¨berfl¨
ABER: M¨
ogliche Verwendung als Beschleuniger
Abw¨agung: Kosten vs. Nutzen vs. Programmierbarkeit
28/59
Hardware / Verbindungsnetzwerk
Gigabit Ethernet:
Performance f¨
ur feingranulare parallele Anwendungen unzureichend
G¨
unstiges Administrationsnetzwerk aufgrund der Mainboardintegration
40GBASE:
Aktuell verbreiteter Ethernet-Standard mit h¨
oherem Durchsatz
Mit optimierten Protokoll-Stack auch f¨
ur feingranulare Anwendungen
geeignet
InfiniBand:
Weite Verbreitung innerhalb der Top500-Liste (≈ 47% der Systeme)
Aktuell bis zu 56 Gbit/s Datenrate und 1 µs Latenz
Myrinet:
Auf Protokoll- und Hardware-Ebene kompatibel zu 10GBase
Geringere Verz¨
ogerungszeiten bei Verwendung des MX-Protokolls
Quadrics:
Ausgelegt auf minimale Latenz mit Hilfe vollst¨
andiger Crossbars
QSNetIII noch entwickelt, jetzt aber insolvent
29/59
3
Cluster
Geschichte des Cluster Computings
Hardware
Systemsoftware
Anwendungssoftware
30/59
Systemsoftware / Betriebssystem
Bis jetzt ist das Cluster
Eine Anzahl einzelner, eigenst¨andiger Rechner (nur Hardware)
Die bereits mit einem oder mehreren Netzwerken verbunden sind
Im n¨achsten Schritt wird ein Betriebssystem auf jedem einzelnen Knoten
ben¨
otigt. Dabei stellen sich drei Fragen:
1
Wie soll das Betriebssystem installiert/gestartet werden?
2
Wird die vorhandene Hardware unterst¨
utzt?
3
Laufen die sp¨ateren Anwendungen auf dem gew¨ahlten Betriebssystem?
31/59
Systemsoftware / Compiler
GCC ist f¨
ur Linux Systeme unerl¨asslich
Produktivsoftware sollte mit dem optimalen Compiler f¨
ur die jeweilige
Systemarchitektur kompiliert werden (z.B. ICC f¨
ur Intel CPUs)
Durchf¨
uhrung von Testreihen sinnvoll
H¨aufig erzielen kommerzielle Produkte eine bessere Auto-Optimierung
32/59
Systemsoftware / Datenhaltung I
Bisher: Stark vernetzte Rechner mit jeweils eigenem, von einander
unabh¨angigem Dateisystem
Binarys, Eingangsdatens¨atze, u.¨a. m¨
ussen auf jedem Knoten der diese
benutzt verf¨
ugbar gemacht werden
Schlechte L¨
osung: Daten vor jedem Job auf die ausf¨
uhrenden Knoten
kopieren
Bessere L¨
osung: Dateisystem auf welches alle Knoten Zugriff haben
(Verteiltes Dateisystem)
33/59
Systemsoftware / Datenhaltung II
Node 1
Headnode / NAS System
/
/bin
/boot
/dev
/etc
nfs:///home
/lib
/mnt
/opt
/proc
/root
/sbin
nfs:///cluster
/sys
/tmp
/usr
/var
FileserverDaemon
/
/bin
/boot
/dev
/etc
/home
/lib
/mnt
/opt
/proc
/root
/sbin
/cluster
/sys
/tmp
/usr
/var
Node n
/
/bin
/boot
/dev
/etc
nfs:///home
/lib
/mnt
/opt
/proc
/root
/sbin
nfs:///cluster
/sys
/tmp
/usr
/var
Abbildung: Zentrale Datenhaltung u
¨ber ein Netzwerkdateisystem
34/59
Systemsoftware / Datenhaltung III
Verteiltes Dateisystem
Ein verteiltes Dateisystem erlaubt den Zugriff auf Dateien eines oder
mehrerer entfernter, u
¨ber ein Rechnernetz verbundener Server.
Hinweis: Obwohl Clients die verteilten Dateisysteme wie lokale Resourcen
benutzen k¨
onnen m¨
ussen die Dateien auf dem Server noch auf lokalen
Dateisystemen (Ext3, ReiserFS, XFS, . . . ) vorliegen. Dies ist f¨
ur die Clients
transparent.
35/59
Systemsoftware / Datenhaltung IV
Unterscheidung verteilter Dateisysteme in
Distributed Filesystems (single source):
Zentraler Server auf dem die Daten liegen
Bsp: AFS, NFS, SMB
Fehlertolerante: Coda, DFS
Distributed Parallel Filesystems (multi source):
Mehrere Server halten die Daten
Abbildung auf ein gesamtheitliches virtuelles Dateisystem
Bsp: Lustre, PVFS
Fehlertolerante: Ceph, GFS, GlusterFS
36/59
Systemsoftware / Tools zur Wartung & Pflege I
Stand jetzt: Netzwerk unabh¨angiger Rechner mit gemeinsamer
Datenhaltung
Anforderung an die Verwaltung paralleler Systeme:
Knoten sollten bequem von einer Stelle aus verwaltet werden k¨
onnen
Automatisierung wiederkehrender Aufgaben
¨
Behalten des Uberblicks
bei vielen Knoten
Unterst¨
utzung verschiedener Nutzerumgebungen
Werkzeuge k¨
onnen die f¨
ur die Verwaltung aufzuwendende Arbeitszeit
signifikant verringern
37/59
Systemsoftware / Tools zur Wartung & Pflege II
Distributed Shell
Wrapper f¨
ur rsh/ssh/remsh-Kommandos
Ausf¨
uhrung eines Befehls auf mehreren Knoten
Erm¨
oglicht gleichzeitige Verwaltung aller Knoten
Beispiele: DSH oder PDSH
38/59
Systemsoftware / Tools zur Wartung & Pflege III
Environment Modules
Erm¨
oglicht Ver¨anderung der Linux-Environment zur Laufzeit
Erlaubt somit einen dynamischen Wechsel zwischen verschiedenen
Versionen einer Anwendung
Einsatz nicht nur auf Parallelrechnern sinnvoll
Link: http://modules.sourceforge.net/
39/59
Systemsoftware / Tools zur Wartung & Pflege IV
Beispiel: Environment Modules & Binaries
40/59
Systemsoftware / Batchsystem I
Batchsystem
Softwarel¨
osung zur Stapelverarbeitung (oder Batchverarbeitung)
Batchverarbeitung ist die sequentielle, nicht-interaktive Abarbeitung von
Aufgaben.
Beispiele:
PBS (Portable Batch System), OpenSource
Torque, OpenSource
SLURM (Simple Linux Utility for Resource Managment), OpenSource
LSF (Load Sharing Facility), kommerziell
41/59
Systemsoftware / Batchsystem II
Batch
Gruppen
Platzieren der Jobs
nach Plan
Cluster
"unendliche" Warteschlange
Job von
Nutzer
Anforderungen
der Jobs
Job
Scheduler
Abbildung: Verteilung der Jobs auf begrenzte Ressourcen
42/59
Systemsoftware / Batchsystem III
Befehl: bjobs
Befehl: bjobs -a
43/59
Systemsoftware / Monitoring I
¨
Entfernte Uberwachung
mehrerer Rechnersysteme
Bestimmung der Systemzust¨ande durch auslesen von Sensoren
¨
Ausf¨
uhrung von definierten Routinen bei Uberschreitung
von
Schwellwerten
Beispiele: Nagios, Ganglia, Munin, ...
44/59
Systemsoftware / Monitoring II
45/59
Systemsoftware / Message Passing Interface I
Bis jetzt: “Farm von Rechnern”
Gut wartbar
Enge Vernetzung (High-Speed-Interconnect)
Daten von jedem Knoten transparent zugreifbar (Verteiltes Dateisystem)
Mehrbenutzerbetrieb m¨
oglich (durch Batchsystem)
ABER: Bisher besteht nur die M¨
oglichkeit auf jedem Knoten separate
Programme zu starten
46/59
Systemsoftware / Message Passing Interface II
Ziel: Mehrere Knoten als einen Rechner verwenden
Erfordert Kommunikation von Programmteilen auf verschiedenen Knoten
u
¨ber das Verbindungsnetzwerk
Insofern kein gemeinsamer Speicher vorhanden ist m¨
ussen dazu explizit
Nachrichten versendet/empfangen werden
47/59
Systemsoftware / Message Passing Interface III
Message Passing Interface
Standardisierte Programmierschnittstelle f¨
ur den Nachrichtenaustausch
zwischen verschiedenen Prozessen
Aktuelle Version des Standards: 3.0
Stellt alle notwendigen Kommunikationsroutinen bereit (Senden,
Empfangen, Gruppenkommunikationen, ... usw.)
Implementierungen: OpenMPI, MPICH1, MPICH2, MVAPICH
Verf¨
ugbar f¨
ur C/C++,Fortran, Java, Python
48/59
Systemsoftware / MPI Beispiel - Token Ring I
1
2
# include < stdio .h >
# include < mpi .h >
3
4
5
# define NRING 100
# define TAG
4711
6
7
8
int main ( int argc , char * argv []){
int rank , size , next , prev , message ;
9
10
11
12
13
/* start up MPI */
MPI_Init (& argc , & argv );
MPI_Comm_rank ( MPI_COMM_WORLD , & rank );
MPI_Comm_size ( MPI_COMM_WORLD , & size );
14
15
16
17
/* errechne rank des naechsten prozesses im ring */
next = ( rank + 1) % size ;
prev = ( rank + size - 1) % size ;
18
19
20
21
22
23
/* rank 0 ist start */
if (0 == rank ) {
message = NRING ;
MPI_Send (& message , 1 , MPI_INT , next , TAG , M PI_COMM_ WORLD );
}
49/59
Systemsoftware / MPI Beispiel - Token Ring II
24
/* sende token immer im ring */
while (1) {
MPI_Recv (& message , 1 , MPI_INT , prev , TAG , MPI_COMM_WORLD ,
M P I _ S T A T U S _ I G N O R E );
25
26
27
28
29
if (0 == rank ) -- message ;
30
31
MPI_Send (& message , 1 , MPI_INT , next , TAG , M PI_COMM_ WORLD );
32
33
if (0 == message ) break ;
34
}
35
36
/* token als letztes zu rank 0 zurueck */
if (0 == rank ) {
MPI_Recv (& message , 1 , MPI_INT , prev , TAG , MPI_COMM_WORLD ,
M P I _ S T A T U S _ I G N O R E );
}
37
38
39
40
41
42
MPI_Finalize ();
return 0;
43
44
45
}
50/59
3
Cluster
Geschichte des Cluster Computings
Hardware
Systemsoftware
Anwendungssoftware
51/59
Parallele Anwendungen
Idee der Lastverteilung
Resourcenintensive Anwendungen benutzen verteilte Hardware
Resourcen: CPUs, Hauptspeicher, persistenter Speicher...
Vorteile:
Kann schneller zu Ergebnissen f¨
uhren
Erm¨
oglicht Erh¨
ohung der Problemgr¨
oße
Erh¨
oht den Durchsatz
52/59
Anwendungssoftware / Parallele Debugger
Kommunikation ist grundlegender Bestandteil paralleler Programme und
muss zus¨atzlich betrachtet werden
Komplexit¨at steigt exponentiell mit der Anzahl der Prozesse
(Fast) ausschließlich kommerzielle Produkte verf¨
ugbar:
Alinea DDT
Totalview
53/59
Anwendungssoftware / Wissenschaftliche Anwendungen
Beispiele f¨
ur wissenschaftliche Anwendungen welche auf Clustern eingesetzt
werden:
GAMESS (http://www.msg.ameslab.gov/GAMESS/GAMESS.html)
GROMACS (http://www.gromacs.org/)
OpenFOAM (http://www.opencfd.co.uk/openfoam/)
POP (http://climate.lanl.gov/Models/POP/)
POV-Ray (http://www.povray.org/)
POY (http://research.amnh.org/scicomp/projects/poy.php)
RAxML
(http://icwww.epfl.ch/~stamatak/index-Dateien/Page443.htm)
WPP (https://computation.llnl.gov/casc/serpentine/)
54/59
Anwendungssoftware / Optimierung & Analyse I
Profiling:
gprof
F¨
ur jeden MPI Prozess ein Output
Zeichnet die Anzahl der Funktionsaufrufe und die darin verbliebene Zeit
auf
Tracing:
Vampirtrace
Zeichnet definierte Ereignisse aller Prozesse mit dazugeh¨
origem
Zeitstempel auf
Somit entsteht eine Programmspur welche mit Hilfe einer GUI visualisiert
werden kann (Vampir)
Lizenz: GPL
Mittlerweile der Standard f¨
ur das Tracen paralleler Anwendungen
Scalasca
Intel Thread Analyser
55/59
Anwendungssoftware / Optimierung & Analyse II
56/59
Literatur I
[Top500] Top500-Liste, 09/2012.
http://www.top500.org/
[JD03] Dongarra, Sterling, Simon Strohmaier
High Performance Computing, Jun 2003
IEEE Educational Activities Department
[TaschInf] Uwe Schneider, Dieter Werner
Taschenbuch der Informatik
Fachbuchverlag Leipzig – ISBN 3-446-21753-3
[BlueGene] Blue Gene Website
http://domino.research.ibm.com/comm/research_projects.nsf/
pages/bluegene.index.html
57/59
Literatur II
[THoeffIBR08] T. Hoefler and T. Schneider and A. Lumsdaine
Multistage Switches are not Crossbars: Effects of Static Routing in
High-Performance Networks
Proceedings of the 2008 IEEE International Conference on Cluster
Computing
http://www.unixer.de/~htor/publications/ – ISBN
978-1-4244-2640
[ZIHPubl] Diplomarbeiten, PhD Thesis, Studienarbeiten am ZIH
http://tinyurl.com/c3zts8
[CC08] Cluster Challenge 08: Optimizing Cluster Configuration and
Applications to Maximize Power Efficiency
J. M¨
uller, T. Schneider, J. Domke, R. Geyer, M. H¨asing, T. Hoefler, St.
H¨
ohlig, G. Juckeland, A. Lumsdaine, M. S. M¨
uller, W. E. Nagel
In Linux Cluster Institute Conference, 2009
58/59
Literatur III
[HennPattQA4] John L. Hennessy, David A. Patterson
Computer Architecture, Fourth Edition: A Quantitative Approach
Morgan Kaufmann 2006 – ISBN 978-0123704900
[THoeffIC09] T. Hoefler and T. Schneider and A. Lumsdaine
A Power-Aware, Application-Based, Performance Study Of Modern
Commodity Cluster Interconnection Networks
Proceedings of the 23rd IEEE International Parallel & Distributed
Processing Symposium (IPDPS), CAC Workshop
http://www.unixer.de/publications//?pub=87
59/59
Document
Kategorie
Technik
Seitenansichten
15
Dateigröße
1 872 KB
Tags
1/--Seiten
melden