Einsatz von GPFS an der JGU

Größe: px

Ab Seite anzeigen:

Download "Einsatz von GPFS an der JGU"

Stephan Blau
vor 8 Jahren
Abrufe

1 Einsatz von GPFS an der JGU Markus Tacke Leiter HPC ZDV Johannes Gutenberg-Universität Mainz

2 Was Kommt? Umfeld JGU Historie und seine Daten Aufgabe ATLAS I/O Lösung GPFS!! Ergebnisse.(wird gleich erst verraten) Ausblick und Diskussion? Fragen gerne.

3 Johannes Gutenberg-Universität 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)

Großforschungseinrichtungen MAMI und TRIGA Größte Campusuniversität 11

4 Ende 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 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)

damals Trotzdem relativ zum Bedarf nicht besser als früher Immer mehr Nutzergruppen brauchen HPC Zum Teil mit anderen Anforderungen:

5 HPC Rechenleistungsentwicklung JGU Peak/system Linpack/system Campus Peak summe

Campus Peak summe 1000 100 10 1 01.01.1994 01.

6 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

(Klientenlizenzen) 2 kleine GPFS trotzdem betrieben Zukauf zu Schenkung von IBM an Professorin System blieb immer klein und wird jetzt geschluckt Als erweiterbarer Fileserver

7 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)

Datenfilterung Aufgabe: 2000 Filterprogramme sequentiell lesen mit 5MB/sek 10GB/sek Bei NFS: 2000 Datenströme parallel = Random I/O GPFS hat

8 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

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

9 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

10 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

11 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

12 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

Verbindungen/Raid Immer an Server direkt über sich und die 2

13 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

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

14 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, fs ssd 28 15,4 0,55 11,49% 1fs nossd 28 13,7 0, ,26% TIP: Kann an GPFS Parametrisierung liegen Falsche Anzahl Prefetch threads, Buffer etc

(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

15 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

weitere Raidcontroler möglich ohne Architekturänderung Auch für Service zum Campus (SMB+NFSv4) Kunde muss HPC (Fileserver)

16 Fragen?

Ähnliche Dokumente

MOGON. Markus Tacke HPC ZDV. HPC - AHRP Markus Tacke, ZDV, Universität Mainz

MOGON. Markus Tacke HPC ZDV. HPC - AHRP Markus Tacke, ZDV, Universität Mainz MOGON Markus Tacke HPC ZDV HPC - AHRP Was ist Mogon allgemein? Das neue High Performance Cluster der JGU Ein neues wichtiges Werkzeug für Auswertung von Messdaten und Simulationen Beispiele Kondensierte