Vienna Scientific Cluster Die Hochleistungsrechner der Wiener Universitäten Universität Wien, BOKU, TU Wien Herbert Störi Betreiber der Systeme
Wir messen die Rechenleistung Instruktionen /Sekunde IPS, kips, MIPS F Taktfrequenz M Takte/Instruktion Q[ IPS]= F M P Faktor für parallele Ausführung von Instruktionen (inklusive Pipelining) Es startet 1 Instruktion /Zyklus wenn P =M Instruktionen laufen bereit parallel ab, selbst für P=1! P Faktor für Parallele Ausführung ohne Pipelining P = P*M P = N pipeline * N core * N node Q[ IPS]= F M P Q [ IPS ]= FgP
Parallele Ausführung Pipeline: Je Takt startet eine Instruktion, benötigt aber mehrere Takte Die folgende Instruktion startet, bevor die erste fertig wird. P=1, P =M Parallele Pipelines in einem Prozessor-Kern Bei jedem Takt starten mehrere Instruktionen P>1, typisch 4 10
Intra-Core-Parallelisierung Pipelining Mehrere Pipelines /Core Viele Instruktionen gleichzeitig in Arbeit Es ist schwierig, das zu nutzen Optimierung im Compiler Hardwareoptimierung Hyperthreading Technische Grenzen F < 5 GHz Eher F<3,5 GHz wegen Energieverbrauch Anzahl der Pipelines <=10 Praktisch vorkommende Programme können mehr nicht nutzen Q=F*N pipeline < 35 GIPS Es gibt eine Grenze für die Rechenleistung, die einem Thread zur Verfügung steht. Die Leistung eines Cores ist seit ca. 2005 nicht mehr gewachsen.
Multi-Core-Systeme Wir bauen mehrere Cores in ein Computersystem Symmetric Multi Processing, SMP Die Cores greifen auf denselben Hauptspeicher zu. Wir müssen unser Programm in parallel bearbeitbare Threads zerteilen. Threads sollten gleich lang rechnen. openmp als Softwareumgebung Auto-Parallelisierung verschiedener Compiler Aber: Wir müssen die Daten nicht zerteilen! Problem: Bandbreite des Hauptspeichers Grenze 4 6 Cores Echtes SMP Alle Cores haben auf alle Speicheraddressen dieselbe Zugriffszeit 2 3 GHz, 2 3x DDR3, 1333 MHz RAM
Problemzone Hauptspeicherzugriff Bus führt nur einen Transfer gleichzeitig aus Viele schnelle CPUs überlasten den Bus Cache hilft bis zu einem bestimmten Punkt Problem: Caches der einzelnen CPUs müssen konsistente Inhalte haben (cache coherency, cc) Alle CPUs sehen den gleichen Speicher (uniform memory architecture UMA) ein Datenelement hat aus Sicht aller CPUs dieselbe Adresse CPU1 Haupt- Speicher1 CPU2 Memory-Bus Haupt- Speicher2 CPU3 Master/ Slave Bridge Bus-Contr. Disk- Netzwerk Controller Master/ Master/ Slave Slave I/O-Bus (PCI-Bus) Master/ Slave Slave I/O- Device
Lösungen für HS-Zugriff Extrem leistungsfähiger Speicherbus Beispiel IBM Power3 2048 Bit Breite (sehr teuer) Mehrere getrennte Speicherbusse mit Cross-Bar-Switch Hilft statistisch nicht alle CPUs greifen gleichzeitig auf denselben Speicherbus zu (Aufwand?) Mehrere getrennte Speicher für jeweils eine oder einige CPUs (non uniform memory architecture NUMA) Variante A: Kopplung über Netzwerk, jede CPU sieht nur ihren Speicher (Cluster, Kommunikation explizit in Software) Adressraum separat je CPU/Knoten Variante B: Kopplung über spezielles Netzwerk, jede CPU sieht alle Speicher Zugriffszeit auf fremde Speicherbereiche ist erhöht Cache-Ladung aus fremden Speichern ist transparent aber langsam (cache coherent non uniform memory architecture (ccnuma) Kernel sorgt dafür, dass jede CPU oft Gebrauchtes im lokalen Speicher hat Einheitlicher Adressraum
Cross-Bar-Switch Anzahl der gleichzeitigen Zugriffe Max(N CPU, N Speicher ) Aufwand: N CPU X N speicher Frage: Was machen wir mit dem I/O-Bus? CPU1 CPU2 CPU3 Haupt- Speicher1 Haupt- Speicher2
Verteilter Hauptspeicher CPU1 CPU2 CPU3 Knoten 1 CPU1 CPU2 CPU3 Knoten 4 Memory-Bus Memory-Bus Haupt- Speicher1 Haupt- Speicher2 Inter- Connect Haupt- Speicher1 Haupt- Speicher2 Inter- Connect Moderne Lösung z. B. 1 Knoten VSC-2 Knoten 2 Knoten 3 CPU1 CPU2 CPU3 CPU1 CPU2 CPU3 Memory-Bus Memory-Bus Haupt- Speicher1 Haupt- Speicher2 Inter- Connect Haupt- Speicher1 Haupt- Speicher2 Inter- Connect
2 Sockel 12 core Intel Westmere System
Mehr-Sockel Systeme Der 4. HT-Link je Prozessor-Chip dient für I/O Chipsets oder Verbindung zu weiteren CPUs
Cluster Einzelne Knoten werden zu einem Clustersystem verbunden. Ein Knoten ist ein vollwertiger Computer mit CPUs, Hauptspeicher, Disks, etc. Kann auch ein SMP-System mit verteiltem Hauptspeicher sein Die Knoten werden mit einem Netzwerk verbunden Ethernet in vielen Fällen zu langsam, lange round-trip-time InfiniBand relativ teuer, sehr schnell, deterministisch Beispiel QDR4x (4 Kanäle, quad data rate) 32 Gbit/sec Topologie meist ein Baum 36 port nonblocking switches weitere... Die Daten sind verteilt Code und Daten werden verteilt Zugriff nur auf Daten auf demselben Node Software: Message Passing Interface MPI Keine automatische Parallelisierung
InfiniBand 1 Ebene: 1 switch max 36 Knoten (einfach) 2 Ebenen: max 54 (36+18) switches max 624 (18x36 Knoten) 3 Ebenen: max 1596 (54x18+624) switches max 11232 Knoten Alternativen Überbuchtes Netzwerk obere Ebenen haben nicht die volle Bandbreite Andere Topologie und Netzwerktechnologie Grosse switches (2 Ebenen in 1 Kasten)
InfiniBand (2) Switch 1 Ebene, 36 Knoten maximal K1... K36 Uplinks: Jede Linie entspr. 6 Verbindungen 2 Ebenen Beispiel: 9 Switches, 108 Knoten (6x18) maximal Volle Bandbreite. Jeder Switch 1. Ebene hat 18 down- und 18 uplinks Switch2.1 Switch2.2 Switch2.3 Switch1 Switch2... Switch6 K1.1... K1.18 K2.1... K2.18 K6.1... K6.18 Wir könnten auch einen Switch 2. Ebene einsparen. Dann hätte jeder Switch 1. Ebene nur 12 uplinks und 24 ports für downlinks. Dann hätten wir 8 Switches und 6x24=144 Knoten. Das Netzwerk wäre dann 2fach überbucht, was meist kein Problem ist.
Leistungsmessung für Hochleistungsrechner Wir zählen nur Gleitkomma-Operationen (DOUBLE) engl.: floating point OK für Physik, Chemie, Meteorologie, Ingenieurwissenschaften Instruktionen mit mehreren Gleitkomma-Operationen zählen mehrfach Vektor, Fused Multiply-Add (FMA) Der Wert anderer Instruktionen ist zu variabel Frage: Bioinformatik, Bildverarbeitung, Parallelverarbeitungsfaktor für Gleitkomma PF=NF*Ncore*Nnode NF Zahl der Gleitkomma-Operationen /Takt/Core NF=4 für alle gängigen Cores NF=8 IBM Power7 und Hitachi Sparc8 R peak [FLOPS] = F*PF theoretisch maximale Gleitkommaleistung R max [FLOPS] < R peak praktisch erreichbare Gleitkommaleistung wird mit Testprogammen (Benchmarks) gemessen
Benchmarks - Testprogramme Leistungs-Benchmark: Absolute Zeit um ein Problem zu lösen Meist mehrere verschiedene Probleme Punkte = 1/Zeit Beispiele: SPECint2006, SPECfp2006 http://www.spec.org LINPACK-Benchmark für HPC: Invertiert eine Matrix, auch parallel http://www.netlib.org/benchmark/hpl/. Durchsatz-Benchmark Wie oft kann das Problem in einer bestimmten Zeit gelöst werden, auch parallel Meist eine Mischung von Problemen Beispiele: SPECint_rate2006, SPECfp_rate2006 http://www.spec.org Unser Benchmark für HPC-Ausschreibungen Testet auch, ob die wichtigsten Programme laufen. Resultate sehr ähnlich SPECfp_rate2006
TOP500-Liste 2mal jährlich neu 500 leistungsfähigste Computer Verwendung des Linpack-Benchmarks Man löst A Matrix n*n x,b Vektoren ε Genauigkeit der Gleitkomma-Operationen 10-53 für DOUBLE R max = FLOP/Zeit VSC-2: n 2.000.000 Gleichung: Test : FLOP : A r x = r b A r x r b A g r x 2 3 n3 + 2n 2 < nε
Vienna Scientific Cluster U Universität für Bodenkultur Wien
Vienna Scientific Cluster Universität für U Bodenkultur Wien Sommer 2008: Anforderungen: Ziele: Das HPC-Projekt der drei Wiener Universitäten Compute-Nodes (X86 Architektur, min. 2GB mem/core) Zugangs- und Managementknoten InfiniBand-Netzwerk Gbit-Netzwerk, Clustermanagement max. 180KW Anschlussleistung (inkl. Interner Kühlung) Platz ~200 in der TOP500-Liste (Nov.2009) EU-weite Ausschreibung: Auftragsvolumen: max. 1.6 Mio Veröffentlichung: 28. 02. 2009 Zuschlag: 08. 05. 2009
Vienna Scientific Cluster Installationsbeginn: Ende Juni 2009 Ergebnis der Ausschreibung 13 Angebote von 10 Firmen (2x AMD, 9x Intel) Zuschlag an IPS/SUN für folgende Komponenten: - 436 Compute-Nodes SUN Fire X2270 (2x Intel X5550 QC, 2.66 GHz) je 24 Gbyte Memory (6x 4 GB DDR3, 1333) - 5 Zugangs- und Managementknoten (SUN Fire X4245) - InfiniBand-Netzwerk von QLogic (DDR und QDR) - Gbit-Netzwerk, - Clustermanagement (Serviceprozessor pro Node) - 16 x 19 Serverschränke + 6 CoolLoops (Knuerr) - Betriebsystem: Linux CentOS - Batch-System: Sun Open Source Grid Engine - Parallelisierung: QLogic MPI
Vienna Scientific Cluster Abnahme Leistungstest (Benchmarks): bessere Werte als im Angebot Dauertest (14 Tage) Linpack-Benchmark auf 3650 cores, 35.5 Tflops TOP500: 156 Green500: 94 Abnahme der Cluster-Infrastruktur, Messung der Stromaufnahme (180 KW) 16 x 19 Serverschränke + 6 CoolLoops (Knuerr) Benutzer-Testbetrieb ab 19.10.09, Produktionsbetrieb ab 01.01.2010 - Betriebsystem: Linux CentOS AWS: - Gaussian 09 - Batch-System: Sun Grid Engine - OpenFOAM - HDF5 - R - Global Arrays
Vienna Scientific Cluster Blockdiagramm SUN Fire X2270
Netzwerkstruktur VSC Vienna Scientific Cluster
Vienna Scientific Cluster U Universität für Bodenkultur Wien
Vienna Scientific Cluster
Vienna Scientific Cluster
Vienna Scientific Cluster
Vienna Scientific Cluster Zugang: Begutachtete Projekte Förderprojekte: Sind Projekte von externen Forschungsfinanzierern (etwa: EU, ERC, FWF, FFG, WWTF,...) begutachtet und finanziert, verlassen wir uns auf das Begutachtungsverfahren der Fördergeber. Wir legen die Rechenzeit gewissermaßen drauf. Interne Projekte: Wir lassen begutachten. Das macht das Vizerektorat für Forschung, kommt aber selten vor. Andere Projekte Externe Projekte: Rechenzeit wird bezahlt. Bisher nicht vorgekommen. Testprojekte: 30.000 core-h innerhalb von 2 Monaten werden von den Systembetreuern vergeben, typischerweise innerhalb von 1-2 Tagen.
Vienna Scientific Cluster Anwendungen (ca 60 aktive Projekte): Materialwisssenschaften Ab-initio Festkörperphysik und -chemie (VASP, WIEN2k,..) Moleküldynamik, Phasenübergänge, Quanten-Monte-Carlo Weiche Materie Physik, Astronomie Quantenchromodynamik Quark-Gluon-Plasma Quantenphysik Wechsewirkung Strahlung mit Atomen Relativitätstheorie Sternmodelle (ANTARES) Chemie Quantenchemie (GAUSSIAN) Ionische Flüssigkeiten Verfahrenstechnik, Strömung (openfoam)
Vienna Scientific Cluster Anwendungen (2): Meteorologie, Klima Kleinräumige Klimamodelle (MM5,...) Hydrologie, Schneetransport Strahlungstransport im gebirgigen Gelände Boden, Grundwasser, Transport von Schadstoffen Bioinformatik Analyse von DNA-Sequenzen (BLAST) Genom-Analyse: Erstellung von Vererbungsbäumen Problem: Große Datensätze brauchen großes virtuelles Memory Mathematik, Informatik, Statistik MATLAB, Mathematica,...
Vienna Scientific Cluster Parallelisierungsgrad
Weitere Entwicklung: Vienna Scientific Cluster Erweiterung VSC-1 4 Knoten mit je 2 GPUs, weitere Knoten Zykluszeit (Plan): Neues System alle 18 Monate (eher 24 M) im stationären Zustand 3 Systeme parallel Neuer Standort Arsenal (Nähe neuer Hauptbahnhof) Science Center der TU Wien (Standort für Großlabors) Mehr Leistung, mehr Kühlung, mehr Platz Umbau ab Herbst 2010 (Tatsächlich März 11) Personal-Aufstockung Zusätzlich 2 Personen (Kvasnicka, Stöhr) VSC-2 Ausschrebung im Sommer 2010 Kosten ca 4 Mio. incl MWSt. Betrieb ab März 2011 (September 11)
Vienna Scientific Cluster VSC-2: Ausschreibung (veröffentlicht 30. September 2010): Architectur: offen, keine GPU s Finanzrahmen: 4,2 M (plus optional file servers) Site: Arsenal, ScienceCenter der TUW Kriterien: 60% Durchsatz., 30% Energieeff, 10% Preis Resultat 14 Angebote von 10 Firmen Sieger: MEGWARE 1314 compute nodes mit zwei 8-core Opteron 6132HE, 2,2 GHz und je 32 Gbyte Infiniband QDR 3-level fabric with 2- and 7-fold oversubsription R peak =185 Tflop/s 30 Racks mit cool doors (passive Wasserkühlung) Start der Installation: 3. Mai, 2011 Zur Zeit: Abnahme
March 2011 Vienna Scientific Cluster VSC-2
Vienna Scientific Cluster VSC-2 20. Mai
Vienna Scientific Cluster VSC-2
Infrastruktur System Disks 16 Gbyte SSD (oft Benötigtes) 2 NFS-Server (seltener Benötigtes) Head Nodes Sun Grid Engine (Queing System) Fabric Manager Cluster Management Software Login Nodes 3 Stück, einer je Universität Im LAN der entsprechenden UNI (VLAN) /home 2 NFS-Server, ca 60 TByte /scratch 12 Fileserver, ca 250 Tbyte Paralleles Filesytem: Fraunhofer FHGFS Metadaten: Verteilt auf Fileserver, je Server 128GByte SSD Durchsatz ca. 6 Gbyte/sec Vergabeasistent: Webbasiertes Projektmanagement Netzwerkanbindung: 2x 10Gbit/s redundant nach aussen Interne Netzwerke Infiniband Gbit LAN zu allen Nodes Gbit Management LAN zu den Serviceprozessoren
Vienna Scientific Cluster VSC-2 Power and cooling
Vienna Scientific Cluster Energie Aspeckte (VSC-2) Zusammenstellung Energieverbrauch: System Fileservers Total Computer Pumpen, Raumkühler Total 1 430 kw 20 kw 450 kw 50 kw (Nennleistungen) 500 kw Kompressoren (Abhängig von der Kühlwassertemperatur) 50 kw (18 C Kühlwasser, teilweise freie Kühlung) Ventilatoren außen 40 kw (Nennleistung) Grand Total 600 kw = 1,33 x Total Computer Größere Kühler mit geringer Luftgeschwindigkeit und noch höhere Kühlwassertemperatur würden helfen
Vienna Scientific Cluster VSC-2 Status: Baustelle Infrastruktur System noch immer nicht ganz fertig temporäres Kühlaggregat kein Raumklima nur Cool Doors temporäre elektrische Anspeisung Benutzertestbetrieb Top-500 Test: Rmax=135,6Tflops Platz 56 (Juni 2011) Green-500: 315,35 Mflops/Watt Platz 71 Nach dem Wechsel aller Memories Rmax=152,9 Tflops (82% Rpeak) 354 Mflops/Watt (Blue Gene P 363-378)
Vienna Scientific Cluster Projektkosten (VSC-2) Vollkosten für 4 Jahre: Hardware 50% Energie 30% Industriepreis, keine Erhöhungen inkludiert Gebäude 10% Personal 10%
Verlässlichkeit Mean time between failure MTBF MTBF für 1 Knoten 100.000 Stunden (12 Jahre) MTBF für 1314 Knoten 100.000/1314 = 76 Stunden (ca. 3 Tage) Problem: stirbt 1 Knoten den ein Programm verwendet, bricht das Programm ab. Speicherinhalt des kaputten Knotens ist verloren. Über redundante Software-Techniken wird nachgedacht
Vienna Scientific Cluster Vergleich VSC-1 VSC-2 Nacktes Sytem, ohne File Server, etc. System VSC-1 VSC-2 Ratio R max Tflop/s 35,5 152.1 4,28 Preis M 1,6 4,2 2,63 Anschlussleistung kw 180 430 2,38 Preis/Leistung Tflop/s/M 22,2 36,2 1,63 Energie effizienz MFlop/s/W 200 353 1,77 R peak /core Gflop/s 10,66 8,8 0,83 Conclusion: VSC-2 hat nach knapp 2 Jahren nahezu doppelte Energie und Preis- Effizienz Aber: VSC-1 hat schnellere Prozessor-Kerne!
Vienna Scientific Cluster Vergabepoliitk 2 Prioritäten: regular: Projekte mit verfügbarem Kontingent idle: Projekte mit verbrauchtem Kontingent System VSC-1 VSC-2 Min job size Max job size without operator 1 core 512 cores 16 cores 1 node 4096 cores 256 nodes Max run time 72 hours 72 hours Accounting and scheduling unit 1 core 1 node
Vienna Scientific Cluster U Universität für Bodenkultur Wien
Vienna Scientific Cluster Ausblick: Ende Oktober 11: Jänner 2012: Februar 2012: Herbst 2012: Anfang 2013: Fertigstellung Energie, Klima Regulärer Benutzerbetrieb (wird verrechnet) Benutzerworkshop Fragen: Architektur und Auslegung VSC-3 Start Vorbereitung Ausschreibung VSC-3 Anlieferung VSC-3 Betrieb VSC-3