Der neue Hessische Hochleistungsrechner HHLR

Transkript

1 Der neue Hessische Hochleistungsrechner HHLR Erste Erfahrungen Norbert Conrad, ZKIHessen Darmstädter Hochleistungsrechner 1987: IBM 3090 VF ( 2 x 0,12 GFLOPS Vektor Peak ) 1992: Fujitsu S400/40 ( 2 x 2,5 GFLOPS Vektor Peak ) 1994: Fujitsu VPP 500/4 ( 4 x 1,6 GFLOPS Vektor Peak ) zusätzlich 1996: Fujitsu VPP 300/6 ( 6 x 2,2 GFLOPS Vektor Peak parallel ) 2002: IBM p690 ( 96 x 5,2 GFLOPS Peak parallel ) ZKIHessen

2 Die Beschaffung April 2001: Europaweite Ausschreibung nach neuem EU-Recht und neuer Vergabeverordnung 31. Mai 2001 Einsendeschluß: 5 Firmen haben Angebote abgegeben Bewertung der Angebote: - Objektive Bewertung (Punkte) - Bewertungskriterien sind Teil des Ausschreibungstextes : Zuschlag an die Fa. IBM für 3 p690 (Regatta) : Zusammenbau der Maschinen in Montpellier : Lieferung mit 1.1 GHz CPUs März 2002: Upgrade auf 1.3 GHz CPUs ZKIHessen Konfiguration des HHLR 3 IBM eserver pseries 690 Regatta H Je 32 CPUs 1,3 GHz 64 GB Hauptspeicher 1 RIO 8 x 36 GB lokale Platten 2 x GigaBit Ethernet 1 Hardware Management Console HMC ZKIHessen

3 IBM 7040 am HRZ der TH Darmstadt (1) ZKIHessen IBM 7040 am HRZ der TU Darmstadt (2) ZKIHessen

4 Technische Daten der 7040 Hauptspeicher Plattenspeicher Rechengeschwindigkeit Worte à 36 Bits 10 Bandgeräte je 20 Mbytes 1 KFLOPS Gbytes 280 Gbytes 5,2 GFLOPS Programmiersprache Fortran Fortran ZKIHessen Logical Partitioning LPAR LPAR: Unterteilen eines Frames in mehrere Maschinen Frame1: Frame2: Frame3: hlr1, hlr2, hlr3 : hlr4: hlr1 full system partition (32 CPUs, 64 GB, 20 PCI) hlr2 full system partition (32 CPUs, 64 GB, 20 PCI) hlr3 logical partition (28 CPUs, 56 GB,10 PCI) hlr4 logical partition (4 CPUs, 7GB, 10 PCI) Batch (LoadLeveler) Dialog Steuerung mit der Hardware Management Console HMC ( = Linux-PC ) über serielle Verbindungen ZKIHessen

5 HMC-BILD ZKIHessen LPAR-conf ZKIHessen

6 Konfiguration des Fileservers 2 x eserver pseries 6H0 mit je 4 CPUs RS MHz 2 GB Hauptspeicher 2 GigaBit Ethernet 5 SSA RAID-Adapter 80 x 36 GB SSA-Platten Je ein Fileserver für den HHLR und für das Unix-Cluster des HRZ bilden zusammen ein gemeinsames hochverfügbares System ZKIHessen Schaltplan des HHLR ZKIHessen

7 Große Rechner Mechanisch: - Formfaktor 24 Zoll - Gewicht je Frame 850 Kg Elektrisch: - Anschlußleistung 10 KW je Frame - Luftkühlung! Rechnen: - 64 GBytes Hauptspeicher = Pages zu 4 KB - 2 TBytes lokaler Plattenspeicher ZKIHessen Große Programme program big parameter (N=32*1024*1024*1024/8) integer i real*8 a(n) do 10 i=1,n,512 a(i)=0.0d0 10 continue end xlf O4 q64 qintsize=8 o big... time./big real 2m21.43s user 0m8.77s sys 1m25.15s ZKIHessen

8 Software AIX 5.1 D + aktuelle PTFs Parallel Environment PE 3.2 LoadLeveler 3.1 XLF VAC ESSL 3.3, PESSL 2.3, MASS,... Bald: PSSP bit Kernel 64bit Kernel -qarch=pwr4 ZKIHessen Performance - Peak performance: 5.2 GFLOPS ( = 4 x 1.3 GHz ) - DGEMM (ESSL Matrixmultiplikation): 3,3 GFLOPS - Matrixmultiplikation xlf 7.1.1: 1,1 GFLOPS - LINPACK: 90 GFLOPS (32 CPUs ESSLsmp) - MPI Bandbreite:2,0 GBytes/s ( shared memory ) - MPI Bandbreite:0,063 GBytes/s ( Gigabit Ethernet ) - MPI Latenz: 98 µs ( Gigabit Ethernet ) - TOP500 Liste 6/2002 : Platz 234 ZKIHessen

9 LINPACK Performance 32 CPUs SMP GFLOPS N ZKIHessen MPI Ping/Pong Bandbreite SMP MBytes/s log2 (Blockgröße) ZKIHessen

10 Ausbau mit einem Switch2 Die 4 HHLR-Knoten und die beiden Fileserver werden mit einem Switch2 verbunden. Das System wird dadurch zu einer SP mit den Regattas und den Fileservern als Knoten. Vorteile: - Vernünftige MPI-Performance auch bei mehr als 32 Tasks MPI-Bandbreite: 133 MBytes/s, Latenz 17 µs - Paralleles Filesystem und MPI-IO - Verbesserte Administrierbarkeit des Gesamtsystems (CWS) - Vorteile beim weiteren Ausbau mit (kleinen) Knoten ZKIHessen Weiterer Ausbau mit kleinen Knoten Ein Frankfurter Benutzer ist so sehr zufrieden mit dem HHLR, dass er eine eigene kleine Regatta haben möchte. Idee: Die Frankfurter Instituts-Maschine steht in DA und wird in den HHLR integriert. Sie übernimmt die Aufgabe der interaktiven Komponente hlr4. Vorteil für das Frankfurter Institut: Einsparung des Rechnerbetriebs Vorteil für den HHLR: Es stehen drei komplette Frames ohne LPAR für alle Benutzer zur Verfügung. Zukunft: Integration weiterer Institutsrechner in den HHLR ZKIHessen

11 Kontingentierung Die Rechenzeitkontingente ergeben sich aus den Anteilen der 5 Standorte an den Investitionen. Landesmittel werden gleich auf die Standorte verteilt. Darmstadt Marburg Frankfurt Gießen Kassel Investition Kontingent 50 % 29 % 7 % 7 % 7% Alle Zahlen sind ungefähre Angaben! ZKIHessen Verteilung der verbrauchten Rechenzeit CPU-Stunden Darmstadt Frankfurt Gießen Marburg Kassel 0 April Mai Juni Juli August ZKIHessen

12 Verbrauchte Anteile am Kontingent 300 % vom Standortkontingent Darmstadt Frankfurt Gießen Marburg Kassel 0 April Mai Juni Juli August ZKIHessen Lokale Kontingentierung Darmstadt Viele Darmstädter Institute haben mit eigenen Institutsmitteln zur Finanzierung des HHLR beigetragen. Das Darmstädter Kontingent wird im Verhältnis der Beiträge auf diese Institute verteilt. Benutzer, die ihr Kontingent überschritten haben, können mit sehr niedriger Priorität rechnen, sofern niemand anderes will. Das DZWR finanziert eine zusätzliche Stelle zur Unterstützung der Benutzer. Die Finanzierung erfolgt durch die Institute: 1000 Grundgebühr und ca. 0,15 pro CPU-Stunde. ZKIHessen