Einsatz von GPFS an der JGU HPC@JGU Markus Tacke Leiter HPC ZDV Johannes Gutenberg-Universität Mainz
Was Kommt? Umfeld JGU Historie HPC@JGU und seine Daten Aufgabe ATLAS I/O Lösung GPFS!! Ergebnisse.(wird gleich erst verraten) Ausblick und Diskussion? Fragen gerne.
Johannes Gutenberg-Universität 37000 Studenten 4150 Wissenschaftler 540 Professoren Exzellenzcluster PRISMA Exzellenz-Graduiertenschule MAINZ Großforschungseinrichtungen MAMI und TRIGA Größte Campusuniversität 11 Fachbereiche (davon 5 bereits HPC Kunden) HPC stark auf dem Vormarsch: 1,89/12 Monate statt 2/18 Monate (Moores Law)
HPC@JGU Ende 1995 48 CPU Convex SPP1200 Mitte 2012: MOGON TOP500 6/1012: Platz 81 Aktuell: Platz 110, Platz 6 in Deutschland 555 Knoten mit 4 x 16Core CPUs=35520 CPUs Anstieg der Rechenleistung um den Faktor 30000 1 core heute leistet mehr als ganze Maschine damals Trotzdem relativ zum Bedarf nicht besser als früher Immer mehr Nutzergruppen brauchen HPC Zum Teil mit anderen Anforderungen: I/O Relative I/O Leistung sinkt Kapazität und I/O/sek viel langsamer billiger als CPU Leistung Zentrale Herausforderung: I/O ( und Preis desselben)
HPC Rechenleistungsentwicklung JGU 1000000 100000 10000 Peak/system Linpack/system Campus Peak summe 1000 100 10 1 01.01.1994 01.01.1998 01.01.2002 01.01.2006 01.01.2010 01.01.2014
GPFS Vorgeschichte Bis 2003 HPC im ZDV durch SMPs: single Filesystem Danach Cluster: multiple (erst 5 später 8 parallelle NFS Server) Wartungsalptraum LC1 (2004): 600 Gflops mit 5x50MB/sek LC2 (2009): 10TFlops mit 8x100MB/sek Aggregierte Datenrate nicht voll nutzbar: I/O trifft punktuell Paralleles Filesystem für regulären Haushalt zu teuer (Klientenlizenzen) 2 kleine GPFS trotzdem betrieben Zukauf zu Schenkung von IBM an Professorin System blieb immer klein und wird jetzt geschluckt Als erweiterbarer Fileserver für Gentechnisches Institut Kleines System mit 2 Servern, aber kräftig wachsend: mittlerweile 100TB Teilweise export via NFS Backup via mmbackup auf TSM : lokale gpfs sowie Service für MPI
MOGON IO In 2010 Start einer Beschaffungsphase für neues Großsystem: Klasse jenseits von 3 M. Mehrere Berufungen mit sehr großem Rechnerbedarf, darunter Professur mit Mitarbeit bei ATLAS (LHC) Extreme Herausforderung ATLAS Datenfilterung Aufgabe: 2000 Filterprogramme sequentiell lesen mit 5MB/sek 10GB/sek Bei NFS: 2000 Datenströme parallel = Random I/O GPFS hat Vorteil: lokalen und zentralen Read ahead Außerdem große Blocksize Echte Programme brauchen VIEL (WIRKLICH) Kontext Eigene Benchmark nach Userangaben entwickelt (Später: Leider Userangaben zu simplifizierend)
MOGON FS 1. Versuche mit GPFS (und Lustre) vielversprechend Ausschreibung mit Maximalbetrag und Mindestanforderung Misslingt => normale Vergabe mit Randbedingung Vergabe nach Angebotseinholung, GPFS durch Kombination von IBM Software mit Fremdhardware preiswerteste Lösung Preiswerte Erweiterbarkeit um mehrere 100 TB Sonderwunsch Lösung: 8 Server mit GPFS SOW Vertrag mit IBM Kein SAN sondern SAS Inseln 2 Gruppen: 4 HOSTS mit 3 SAS, 4 Storage an je 3 HOSTS Nur 7 Dell MD3260 (alias netapp 2660) netapp 5460(dcs3700P) rechnet sich nicht Gruppe auf 2x8 Raidcontroler erweiterbar IB RDMA als Standardnetz, dazu 2x 10GBit/Server (intern+campus) Schmankerl: Homefilesystem mit Metadaten auf Serverbased SSDs 3fach repliziert, Zukunftsplanung
Mog on FS Realität 1 Gruppe 4 Server mit 2x10Gb IB QDR, 6x SAS 2Port 4 SAS Raid 60x 3 TB Disk 4 Diskpools mit 1 HS
Mog on FS Realität 1 Gruppe 4 Server mit 2x10Gb IB QDR, 6x SAS 2Port 4 SAS Raid 60x 3 TB Disk 4 Diskpools mit 1 HS 3 (x2) Host Verbindungen/Raid Immer an Server direkt über sich und die 2 darunter
Mog on FS Realität 1 Gruppe 4 Server mit 2x10Gb IB QDR, 6x SAS 2Port 4 SAS Raid 60x 3 TB Disk 4 Diskpools mit 1 HS 3 (x2) Host Verbindungen/Raid Immer an Server direkt über sich und die 2 darunter kleines Kabelchaos
Mog on FS Realität 1 Gruppe 4 Server mit 2x10Gb IB QDR, 6x SAS 2Port 4 SAS Raid 60x 3 TB Disk 4 Diskpools mit 1 HS 3 (x2) Host Verbindungen/Raid Immer an Server direkt über sich und die 2 darunter kleines Kabelchaos Aber handelbar Clusterbackbones sind ein anders Kaliber
MOGON FS Performance Eigener Benchmark Benclusio entwickelt Insbesondere um ATLAS I/O Verhalten zu simulieren Blocks mit ca. 1MB, kleine Pausen Fairness Test und Bandbreitenmessung Erreichter Datenrate auf Filesystem mit 28 NSDs bei 2048 Prozessen: 15.4 GB/sek Filesystem mit 4MB Blocksize und einigem anderen Tuning Filesystem Meta data DATA LUNs 1024 Procs READ Write OWC80 pro client 2048 Procs 1024 Procs 2048 Procs 16 Procs 64 Procs Alle Tests auf 32 Clients [GB/sec] [GB/sec] [GB/sec] [GB/sec] [1000/sek] [1000/sek ] HOME SSD 1 0,3 0,7 0,4 0,4 49,6 32,0 PROJECT SSD 13 8,0 8,0 6,2 6,1 50,1 30,6 ATLAS data 14 8,7 8,7 6,5 6,3 49,7 30,5 Summe 28 17,0 17,4 13,1 12,7
MOGON Performance Befunde ATLAS Mindestwert 5GB/sek, Wunsch7-8 erfüllt, aber Erreicht mit 1500 Prozessen: 4.5 GB/sek Evtl. ROOT anpassen oder Preload Lib oder Tuning an GPFS - Reales ROOT Programm hat andere I/O Charakteristik Wert für (Open-Write 80Bytes-Close)(OWC80) ist fantastisch und skaliert (zumindest über weite Bereiche) mit Knotenanzahl Architekturvorteil GPFS, Löst Problem sehr vieler Protokolldateien - 1 FS mit 28 LUNS langsamer als 2 FS mit 14 Filesystem Meta data DATA LUNs READ I/O per Verlust 2048Proc LUN 32 Klientenrechner [GB/sek] [GB/sek] 3 FS parallel ssd 28 17,4 0,62143 1fs ssd 28 15,4 0,55 11,49% 1fs nossd 28 13,7 0,48929 21,26% TIP: Kann an GPFS Parametrisierung liegen Falsche Anzahl Prefetch threads, Buffer etc
Ausblick Trotz der obigen Probleme sehr zufrieden Minimalanforderung schon nach 1 Woche bis auf 10% erreicht! Zusätzliche Protokolle in Planung: SAMBA, NFS und FTP Erweiterung (Speicher und Datenrate) schon von Nutzern angefragt Bis zu 9 weitere Raidcontroler möglich ohne Architekturänderung Auch für Service zum Campus (SMB+NFSv4) Kunde muss HPC (Fileserver) Verfügbarkeit akzeptieren Erster Stillstand nach 1 Stunde vom Support gelöst Bug in unserer config, nicht auf 600 Klienten angepasst unser Fehler, nicht IBMs
HPC@JGU Fragen?