Linux Cluster in Theorie und Praxis

Zentrum für Informationsdienste und Hochleistungsrechnen TU Dresden Linux Cluster in Theorie und Praxis Cluster Computing Einführung 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 überschaubare Lernumgebung Theoretische Betrachtungen mit praktischen Erfahrungen untermauern Kooperative Bearbeitung komplexer Aufgaben Selbstständiges Erkennen, Analysieren und Lösen von Problemen fördern 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 über mehr als einen physischen Prozessor verfügt. Die Prozessoren von durchaus unterschiedlicher Komplexität können unabhängig 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ändiges System dar. Somit können die Knoten auch unabhängig voneinander arbeiten und es kann Software eingesetzt werden, welche für 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ängiger Funktionseinheiten. Die Bedeutung des Terms massive ist abhängig 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äre 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ühzeitige Entscheidung für Capacity oder Capability Computing Analyse des zu lösenden Problems (Workload) Auswahl des Systems anhand des auszuführenden Workloads 17/59

3 Cluster Geschichte des Cluster Computings Hardware Systemsoftware Anwendungssoftware 18/59

Entstehung des Cluster Computings Superrechner waren teuer aufgrund hoher Entwicklungskosten und geringer Stückzahlen 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ägung 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öhten Qualitätsanforderungen Erhöhung der Packungsdichte dank professioneller Servergehäuse Engere Kopplung mit Hilfe neuer Netzwerktechnologien Unterschiede zwischen Cluster- und MPP-Systemen werden geringer Abbildung: SuperMUC Petascale System des LRZ München 22/59

Hardware / Aufbau eines Clusters Node Node Node Node RAM RAM RAM RAM CPU Core Core Core Core Grafik- Karte CPU Core Core Core Core Grafik- Karte CPU Core Core Core Core Grafik- Karte CPU Core Core Core Core Grafik- Karte Input / Output Input / Output Input / Output Input / Output HDD HDD HDD HDD Interconnect Fabric Storage Storage Abbildung: Schematische Darstellung des Aufbaus eines Cluster-Systems 24/59

Hardware / Homogenität und Heterogenität 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ückzahlen Ausreichende Performance Softwarekompatibilität Sparc: Oracle Niagara oder Fujitsu Power: Teurer, spezialisiert Für (Web)server-Cluster (SSL, Mail, Datenbanken,...) Integer-lastige Anwendungen können von Sparc profitieren Preisintensiv Hoher Fließkommadurchsatz bei gleichzeitig hoher Packungsdichte Hochverfügbarkeitssysteme, Mainframes, MPP-Systeme ([BlueGene]) 26/59

Hardware / Festplatten Zwei Gründe die für Festplatten in jedem Knoten sprechen: Swap File System für Jobs mit hohen Resourcenanforderungen Scratch File System zum Abspeichern von Zwischenergebnissen 27/59

Hardware / Festplatten Zwei Gründe die für Festplatten in jedem Knoten sprechen: Swap File System für Jobs mit hohen Resourcenanforderungen Scratch File System zum Abspeichern von Zwischenergebnissen Zwei Gründe dagegen: Verbraucht zusätzlich Strom Verschleißteil 27/59

Hardware / Grafikkarten Prinzipiell überflüssig ABER: Mögliche Verwendung als Beschleuniger Abwägung: Kosten vs. Nutzen vs. Programmierbarkeit 28/59

Hardware / Verbindungsnetzwerk Gigabit Ethernet: Performance für feingranulare parallele Anwendungen unzureichend Günstiges Administrationsnetzwerk aufgrund der Mainboardintegration 40GBASE: Aktuell verbreiteter Ethernet-Standard mit höherem Durchsatz Mit optimierten Protokoll-Stack auch für 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ögerungszeiten bei Verwendung des MX-Protokolls Quadrics: Ausgelegt auf minimale Latenz mit Hilfe vollständiger Crossbars QSNetIII noch entwickelt, jetzt aber insolvent 29/59

Systemsoftware / Betriebssystem Bis jetzt ist das Cluster Eine Anzahl einzelner, eigenständiger Rechner (nur Hardware) Die bereits mit einem oder mehreren Netzwerken verbunden sind Im nächsten Schritt wird ein Betriebssystem auf jedem einzelnen Knoten benötigt. Dabei stellen sich drei Fragen: 1 Wie soll das Betriebssystem installiert/gestartet werden? 2 Wird die vorhandene Hardware unterstützt? 3 Laufen die späteren Anwendungen auf dem gewählten Betriebssystem? 31/59

Systemsoftware / Compiler GCC ist für Linux Systeme unerlässlich Produktivsoftware sollte mit dem optimalen Compiler für die jeweilige Systemarchitektur kompiliert werden (z.b. ICC für Intel CPUs) Durchführung von Testreihen sinnvoll Häufig erzielen kommerzielle Produkte eine bessere Auto-Optimierung 32/59

Systemsoftware / Datenhaltung I Bisher: Stark vernetzte Rechner mit jeweils eigenem, von einander unabhängigem Dateisystem Binarys, Eingangsdatensätze, u.ä. müssen auf jedem Knoten der diese benutzt verfügbar gemacht werden Schlechte Lösung: Daten vor jedem Job auf die ausführenden Knoten kopieren Bessere Lösung: Dateisystem auf welches alle Knoten Zugriff haben (Verteiltes Dateisystem) 33/59

Systemsoftware / Datenhaltung II / /bin /boot /dev /etc /home /lib /mnt /opt /proc /root /sbin /cluster /sys /tmp /usr /var Headnode / NAS System Fileserver- Daemon Node 1 / /bin /boot /dev /etc nfs:///home /lib /mnt /opt /proc /root /sbin nfs:///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 über ein Netzwerkdateisystem 34/59

Systemsoftware / Datenhaltung III Verteiltes Dateisystem Ein verteiltes Dateisystem erlaubt den Zugriff auf Dateien eines oder mehrerer entfernter, über ein Rechnernetz verbundener Server. Hinweis: Obwohl Clients die verteilten Dateisysteme wie lokale Resourcen benutzen können müssen die Dateien auf dem Server noch auf lokalen Dateisystemen (Ext3, ReiserFS, XFS,... ) vorliegen. Dies ist für 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ängiger Rechner mit gemeinsamer Datenhaltung Anforderung an die Verwaltung paralleler Systeme: Knoten sollten bequem von einer Stelle aus verwaltet werden können Automatisierung wiederkehrender Aufgaben Behalten des Überblicks bei vielen Knoten Unterstützung verschiedener Nutzerumgebungen Werkzeuge können die für die Verwaltung aufzuwendende Arbeitszeit signifikant verringern 37/59

Systemsoftware / Tools zur Wartung & Pflege II Distributed Shell Wrapper für rsh/ssh/remsh-kommandos Ausführung eines Befehls auf mehreren Knoten Ermöglicht gleichzeitige Verwaltung aller Knoten Beispiele: DSH oder PDSH 38/59

Systemsoftware / Tools zur Wartung & Pflege III Environment Modules Ermöglicht Veränderung 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ösung 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 "unendliche" Warteschlange Batch Gruppen Platzieren der Jobs nach Plan Cluster 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 Überwachung mehrerer Rechnersysteme Bestimmung der Systemzustände durch auslesen von Sensoren Ausführung von definierten Routinen bei Überschreitung 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öglich (durch Batchsystem) ABER: Bisher besteht nur die Möglichkeit 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 über das Verbindungsnetzwerk Insofern kein gemeinsamer Speicher vorhanden ist müssen dazu explizit Nachrichten versendet/empfangen werden 47/59

Systemsoftware / Message Passing Interface III Message Passing Interface Standardisierte Programmierschnittstelle für 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ügbar für C/C++,Fortran, Java, Python 48/59

Systemsoftware / MPI Beispiel - Token Ring I 1 # include <stdio.h> 2 # include <mpi.h> 3 4 # define NRING 100 5 # define TAG 4711 6 7 int main ( int argc, char * argv []){ 8 int rank, size, next, prev, message ; 9 10 /* start up MPI */ 11 MPI_Init (& argc, & argv ); 12 MPI_Comm_rank ( MPI_COMM_WORLD, & rank ); 13 MPI_Comm_size ( MPI_COMM_WORLD, & size ); 14 15 /* errechne rank des naechsten prozesses im ring */ 16 next = ( rank + 1) % size ; 17 prev = ( rank + size - 1) % size ; 18 19 /* rank 0 ist start */ 20 if (0 == rank ) { 21 message = NRING ; 22 MPI_Send (& message, 1, MPI_INT, next, TAG, MPI_COMM_WORLD ); 23 } 49/59

Systemsoftware / MPI Beispiel - Token Ring II 24 25 /* sende token immer im ring */ 26 while (1) { 27 MPI_Recv (& message, 1, MPI_INT, prev, TAG, MPI_COMM_WORLD, 28 MPI_STATUS_IGNORE ); 29 30 if (0 == rank ) -- message ; 31 32 MPI_Send (& message, 1, MPI_INT, next, TAG, MPI_COMM_WORLD ); 33 34 if (0 == message ) break ; 35 } 36 37 /* token als letztes zu rank 0 zurueck */ 38 if (0 == rank ) { 39 MPI_Recv (& message, 1, MPI_INT, prev, TAG, MPI_COMM_WORLD, 40 MPI_STATUS_IGNORE ); 41 } 42 43 MPI_Finalize (); 44 return 0; 45 } 50/59

Parallele Anwendungen Idee der Lastverteilung Resourcenintensive Anwendungen benutzen verteilte Hardware Resourcen: CPUs, Hauptspeicher, persistenter Speicher... Vorteile: Kann schneller zu Ergebnissen führen Ermöglicht Erhöhung der Problemgröße Erhöht den Durchsatz 52/59

Anwendungssoftware / Parallele Debugger Kommunikation ist grundlegender Bestandteil paralleler Programme und muss zusätzlich betrachtet werden Komplexität steigt exponentiell mit der Anzahl der Prozesse (Fast) ausschließlich kommerzielle Produkte verfügbar: Alinea DDT Totalview 53/59

Anwendungssoftware / Wissenschaftliche Anwendungen Beispiele für 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: Tracing: gprof Für jeden MPI Prozess ein Output Zeichnet die Anzahl der Funktionsaufrufe und die darin verbliebene Zeit auf Vampirtrace Zeichnet definierte Ereignisse aller Prozesse mit dazugehörigem Zeitstempel auf Somit entsteht eine Programmspur welche mit Hilfe einer GUI visualisiert werden kann (Vampir) Lizenz: GPL Mittlerweile der Standard für 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üller, T. Schneider, J. Domke, R. Geyer, M. Häsing, T. Hoefler, St. Höhlig, G. Juckeland, A. Lumsdaine, M. S. Müller, 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