Erfahrungen mit LSF an der RWTH. Eine kurze Geschichte der LoadSharingFacility

Transkript

1 Erfahrungen mit LSF an der RWTH Eine kurze Geschichte der LoadSharingFacility

2 Zeitlinie 2011 Wechsel SGE -> LSF, Bull Cluster, GPU-Cluster 2012 JARA-HPC 2014 Projektbewirtschaftung RWTH 2016 NEC Cluster CLAIX I 2018 Wechsel LSF -> SLURM, Cluster CLAIX II 2 von 18

3 Zeitlinie 2011 Wechsel SGE -> LSF, Bull Cluster, GPU-Cluster 2012 JARA-HPC 2014 Projektbewirtschaftung RWTH 2016 NEC Cluster CLAIX I 2018 Wechsel LSF -> SLURM, Cluster CLAIX II 3 von 18

4 Bull Cluster, GPU-Cluster, Wechsel SGE -> LSF Einführung LSF BULL-Cluster 4 Knotentypen (MPI, SMP, BCS, GPU) x86 (QDR Infiniband) MPI-Partition, 1350 Knoten, 12 cores, GB Memory SMP-Partition, 90 Knoten, cores, GB Memory 2-4 Maschinen, Bull Coherent Switch GPU-Cluster (Ethernet) 24 Knoten, 12 cores, 24 GB Memory, 2 * NVIDIA Quadro 6000 Sonstiges (Ethernet) Installation aus 2007, Maschinen diverser couleur Integratives Hosting Stufenweise Migration SGE-> LSF 4 von 18

5 1 Cluster Konzept 1-Cluster-Konzept Submittieren von allen Frontendknoten für alle Maschinen möglich Alle Filesysteme auf allen Knoten an gleicher Stelle verfügbar (HOME, WORK, HPCWORK) Lediglich ein Workload Management System, LSF 8.1 Bestmögliche Transparenz für den Nutzer Ermöglicht Integratives Hosting (Projekte) Best Effort Steuerung der Jobs für den Nutzer Keine Angaben durch Nutzer -> bestmögliche Maschine(-ngruppe) finden Angaben des Nutzers werden berücksichtigt, aber auch korrigiert, falls nötig Warnung und Ablehnung des Jobs esub Skript zur Steuerung/Modifikation der Jobs 5 von 18

6 Standort RWTH Compute Cluster Viele unterschiedliche Nutzer der Frontends und Batchsysteme Frontend ~ 1000 Backend ~ 200 Verpflichtende Angabe der Runtime Automatisch exklusiv ab 32 cores Boardwise Scheduling BCS-Systeme manuell implementiert (cgroups), keine Unterstützung durch LSF GPU-Cluster Nutzung im Batch nachts, tagsüber CAVE Compute Units Einteilung in Infiniband-Inseln, Maschinentypen, Racks, Chassis 6 von 18

7 Zeitlinie 2011 Wechsel SGE -> LSF, Bull Cluster, GPU-Cluster 2012 JARA-HPC 2014 Projektbewirtschaftung RWTH 2016 NEC Cluster CLAIX I 2018 Wechsel LSF -> SLURM, Cluster CLAIX II 7 von 18

8 2012 JARA-HPC 60 % des Clusters exklusiv in eigener Queue JEDER Job exklusiv Beschränkung auf 24h (single node 120h) Zwei Rechenzeit-Perioden, beginnend jeweils Mai und November In LSF mittels Projekten realisiert, ähnlich Integratives Hosting Aufbau des Reportings Kaum Unterstützung durch die eingesetzte LSF Version Accounting in Textfiles, field separator Leerzeichen Parser für Textfiles, Azubi-Projekt in JAVA, Eintragung in SQL Datenbank Weiterverarbeitung der Daten Projektbewirtschaftung r_batch_usage 8 von 18

9 Zeitlinie 2011 Wechsel SGE -> LSF, Bull Cluster, GPU-Cluster 2012 JARA-HPC 2014 Projektbewirtschaftung RWTH 2016 NEC Cluster CLAIX I 2018 Wechsel LSF -> SLURM, Cluster CLAIX II 9 von 18

10 Projektbewirtschaftung RWTH Compute Cluster Einführung LSF 9.1 SLA (Service Level Agreement), Affinity Scheduling (CPU und Memory binding) Security enhancements in Bezug auf Sichtbarkeit von Jobs gegenüber anderen Nutzern Task-Konzept vs. altem Slot-Konzept Anzeige und Accounting (LSF-seitig) von exklusiven, bzw. hybriden Jobs endlich möglich External post submission script Erlaubt z.b. das Sichern des Jobscripts zu Supportzwecken 10 von 18

11 Projektbewirtschaftung RWTH Compute Cluster Zu große, unfaire Nutzung des freien Kontingents Ähnlich JARA müssen Projekte beantragt und bewilligt werden, unkontingentiertes Rechnen wird eingeschränkt, keine Rechenzeitperiode, jederzeit beantragbar low-queue Einführung von SLAs für JARA, RWTH-Projekte, Lehre und Thesis-Arbeiten, unkontingentiert DISTRIBUTION: [sla_edu, 3%] [sla_rwth, 30%] [sla_jara, 60%] [sla_default, 5%] [sla_low, 2%] Sehr gute Auslastung des Clusters nach der Einführung, im Schnitt ca. 92% im Jahr von 18

12 12 von 18

13 Zeitlinie 2011 Wechsel SGE -> LSF, Bull Cluster, GPU-Cluster 2012 JARA-HPC 2014 Projektbewirtschaftung RWTH 2016 NEC Cluster CLAIX I 2018 Wechsel LSF -> SLURM, Cluster CLAIX II 13 von 18

14 NEC Cluster CLAIX I NEC Cluster (Omnipath) MPI-Partition, 24 cores, 128GB Memory, 601 Knoten SMP-Partition, 144 cores, 1024GB Memory, 3.7 TB NVME, 8 Knoten 2 Knoten mit 1 * NVIDIA Tesla P100 GPU-Partition, 24 cores, 128 GB Memory, 2 * NVIDIA Tesla P100, 10 Knoten NVME-Partition, 24 cores, 128 GB Memory, 1.9 TB NVME, 8 Knoten Einführung von LSF 10.1 Verbesserte Anlaufzeitvorhersage (Simulator) mehrere GPU-Jobs auf einer Maschine möglich, mittels cgroups getrennt, vereinfachte Anforderung Strategiewechsel Exclusive Scheduling Herabsetzen der Exklusivitätsgrenze auf single node 14 von 18

15 Zeitlinie 2011 Wechsel SGE -> LSF, Bull Cluster, GPU-Cluster 2012 JARA-HPC 2014 Projektbewirtschaftung RWTH 2016 NEC Cluster CLAIX I 2018 Wechsel LSF -> SLURM, Cluster CLAIX II 15 von 18

16 Rückblick auf 7 Jahre mit LSF, Wechsel LSF -> SLURM holpriger Start Viele Features, mit Sicherheit nicht alle ausgereizt Mit der Zeit immer besser und stabiler geworden Sinnvolle Erweiterungen Die letzten Jahre stabiler Betrieb ohne Störungen/Ausfälle des Schedulers Warum der Wechsel zu SLURM Kosten breiter Einsatz von SLURM in der universitären HPC-Landschaft 16 von 18

17 Cluster CLAIX II November 2018 neuer Cluster (aktuell in der Ausschreibung) Einführung SLURM mit neuem Cluster Schmerzlich vermisst werden hostgroups und Compute units (eventuell möglich mit Features, zumindest teilweise) Kein time based scheduling Vielleicht per cronjob oder aber Serie von advance reservations Schrittweise Migration von LSF zu SLURM CLAIX II und Tier 3 (November 2018) Integratives Hosting CLAIX I (Mai 2019) 17 von 18

18 Vielen Dank für Ihre Aufmerksamkeit