Frederik Wagner Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften

Transkript

1 Erfahrungen mit Single-Namespace NFS im HPC-Umfeld Frederik Wagner Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschaften

2 Das Linux-Cluster am LRZ 2

3 Speichersysteme am Linux-Cluster Homeverzeichnisse und Software Netapp-NAS-Cluster mit 6 Filern, 70 TB Gemeinsam mit Hochleistungsrechner HLRB 2 Snapshots + Replikation + Bandsicherung als Backup Stabiler Betrieb seit 2006 PTMP-Bereich und Projektbereiche Bis 02/2010: Lustre (6+12 Server, TB) Ab 02/2010: Netapp-NAS-Cluster mit 6 Filern, 150 TB Backup / Archivierung durch Benutzer Schwieriger Workload Viele gleichzeitig laufende, unterschiedliche Programme Viele kleine Dateien (Durchschnitt unter 800 kb) 3

4 Ablösung von Lustre am LRZ Lustre im Betrieb seit 2005, letzte Version 1.6.* Keine zufriedenstellende Betriebsstabilität Diverse Bugs in Lustre (inkl. Datenkorruption) Insgesamt wenig Liebe zum Detail bei der QA in 1.6.* Schwieriges Lastprofil für ein paralleles Dateisystem Management-Tools und Features nicht zeitgemäß Datei -System ist leider nur ein Teil von Speicher -System Monitoring, HA, Datenintegrität, Support,... Kernel-Abhängigkeit behindert Sicherheitsupdates HPC-Hosting / Housing am Cluster für externe Kunden Anfang 2010: Umwidmung der Lustre-Hardware und Ersatz durch NAS-System 4

5 Neues System Technische Daten Cluster aus sechs NAS-Filern Netapp x 1 TB SATA - Disks pro Filer, insgesamt 288 Disks RAID DP (=analog zu RAID 4 und 6) Sechs 10 GigE-Interfaces zum Cluster Zwölf interne 10 GigE-Interfaces mit 2 Switches Stromverbrauch: ca. 2,2 kw pro Paar - insg. 6,6 kw Zum Vergleich bisheriges Lustre 12 Server mit 12x10 GigE-Interfaces Sechs RAID-Kontroller mit GB FC-Disks jeder = 624 Disks Stromverbrauch ca. 18 kw 5

6 Netapp Ontap 8 Cluster Mode Klassische Netapp NAS-Filer Features WAFL-Dateisystem, NVRAM für geringe NFS-Latenz beim Schreiben + Ein Cluster mit Single Namespace und gemeinsamen Mgmt. Zuverlässiges HA-Failover mit jeweils zwei Filern als Paar Failover-Zeit ~60 Sekunden Datenintegrität Checksummen im Dateisystem, Disk- und Memory-Scrubbing Snapshots, asynchrone Replikation möglich Datenmigration von Volumes im laufenden Betrieb Auch zwischen verschiedenen Hardware-Modellen Thin-Provisioning 6

7 Single-Namespace NFS Single-Namespace Alle Datenbereiche ( Volumes ) im NAS-Cluster unter einem Einstiegspunkt sichtbar Analog wie Microsoft-DFS oder AFS Clientsicht NFS v3, keine Client-Software nötig Ein Clientrechner mountet genau einen Filer Round-Robin DNS für Lastverteilung Weiterleitung der Daten intern im NAS-Cluster Dediziertes Netzwerk Kostet etwas Performance 7

8 Single Namespace 8

9 Striped Volumes Normales Volume Daten liegen auf genau einem NAS-Filer Striped Volume Daten werden über mehrere Filer verteilt Jeweils eigenes Metadaten-Volume Ähnlich wie ein paralleles Dateisystem, aber Komplexität vollständig innerhalb des NAS-Clusters Ziel: Bessere Performance und mehr Kapazität Basis-Features wie Snapshots oder Replikation bleiben erhalten Werden aber für PTMP nicht genutzt Performance: 1.4 GB/s Schreiben, 2.2 GB/s Lesen unter Benchmarkbedingungen 9

10 Striped Volumes 10

11 Verteilte Metadaten-Server ( Acro ) Der Heilige Gral der verteilten Dateisysteme In Lustre seit Jahren auf der Roadmap Netapp hat eine Implementierung in Ontap 8.0 RC3 Ähnlich wie striped volume, aber verteilte Metadaten Leider kein offizielles Feature (mehr) Erstellen von Dateien (Dateien / Sekunde) 20 Clients Acro -Volume über NAS-Filer verteilt Create Files/s Linear 11

12 Zusammenfassung Linux-Cluster des LRZ ist derzeit vollständig NFS-basiert NFS v3 mit einheitlichem Namespace Lustre war nicht ausgereift genug für ein serviceorientiertes Linux-Cluster Grundlegende Management-Features fehlen (Bisher) wenig überzeugende Qualität Vielleicht in Zukunft wieder? Ausblick Kerberos NFS v4 Flash-basierte Caches (>512 GB pro Node) 12