840 likes | 1.02k Views
Parallele E/A auf Clustern. Joachim Worringen Lehrstuhl für Betriebssysteme RWTH Aachen. Agenda. Cluster, verteilte & parallele E/A Anwendungen, Eigenschaften und Entwicklung paralleler E/A Verfahren und Implementationen Fallstudien: Cplant & PVFS Parallele E/A via SCI Zusammenfassung.
E N D
Parallele E/A auf Clustern Joachim Worringen Lehrstuhl für Betriebssysteme RWTH Aachen
Agenda • Cluster, verteilte & parallele E/A • Anwendungen, Eigenschaften und Entwicklung paralleler E/A • Verfahren und Implementationen • Fallstudien: Cplant & PVFS • Parallele E/A via SCI • Zusammenfassung Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Was sind Cluster ? • Eine Zahl eigenständiger, vernetzter Rechnersysteme zur Lösung einer oder mehrerer gleichartiger Aufgaben. • Aspekte: • Dedizierte Systeme – kein NOW • „off-the-shelf“ Standardkomponenten – billig! • Evtl. leistungsfähiges Verbindungsnetz • 2 bis tausende Knoten • Häufig: frei verfügbare Software Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Verteilte vs. Parallele E/A • Verteilte E/A: • Ein gemeinsamer Datenbestand steht einer Gruppe verteilter Systeme gleichartig zur Verfügung • Typische Nutzung: ein Prozess pro Datei • Typische Architektur: Zentrales Speichersystem • Parallele E/A: • Paralleles Programm mit P > 1 Prozessen • Gleichzeitige Nutzung mehrerer Speichergeräte für eine Datei • Typische Nutzung: P Prozesse pro Datei gleichzeitig • Notwendige Architektur: Parallel arbeitende Speichersysteme Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Parallele E/A auf Clustern • Parallele E/A: aufkommendes Thema Anfang 90er • SMP-Server: Erweiterung existierender Technologie • MPP: Spezialtechnologie und Algorithmik • Scalable IO-Initiative • Vielzahl von Applikationsbibliotheken • Neue Schnittstellen (MPI-IO) • Cluster: Mischung von SMP- und MPP-Technologie • Neue Entwicklungs- und Einsatzbedingungen • Übertragen von Erkenntnissen auf neue Umgebung Prinzipien bleiben gleich! Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Anwendungsfelder • Datenbanken • Multimedia • Ingenieursanwendungen: • Strömungssimulation • EM-Feld-Berechnungen • ... SFB Numerik ... • Wissenschaftliche Simulationen: • Quantendynamische Molekülsimulation (Uni Münster): • 6 x 580 MB/Molekül • Nicht-sequentielle Lese- & Schreibzugriffe Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Fälle paralleler E/A • Wann ist E/A in einem parallelen Programm erforderlich? • Ausgabe der Ergebnisse • Einmalig oder wiederholt • Online- oder Offline-Visualisierung • Einlesen von Parametern / Initialisierung • Temporäres Auslagern von Daten • Fehlersuche / Validierung • Checkpointing • Out-of-Core Berechnungen Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Eigenschaften paralleler E/A • N-facher Zugriff auf eine Datei • Burst-Charakteristik; zeitgleich von allen Prozessen • Zugriffsmuster: • Typisch: Verschachtelt, aber regulär • Mitunter irregulär • 90 : 10 Regel: 90% der Zugriffe betreffen nur 10% der Daten • Vielfach Schreibzugriffe • i.d.R. auf disjunkte Dateibereiche • Lesezugriffe von externen Systemen • Häufig möglich: Überlappung von E/A / Berechnung • Viel Hauptspeicher erforderlich ! Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
E/A-Anforderungen: Abschätzung • Hypothetisches System: F = 1 TFLOP/s Peak • Effektive Leistung: 10% Peak = 100 GFLOPS/s • FLOP-to-byte Verhältnis 500 : 1 • Datenrate: 200 MB/seffektive, kontinuierliche E/A-Bandbreite • Datenrate: Nach einer Woche: 120 TB • Problem: • Daten sind verteilt • Datenausgabe nicht kontinuierlich Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
E/A-Anforderungen: Entwicklung (1) • RAM-Kapazität: M / F ~ 0.5 ... 1 • E/A-Kapazität: Ctotal / M ~ 10 ... 20 • Heute: 1 TFLOP/s-System • Ctotal = 20 TB • Mit Cdisk = 40 GB ist Ndisk = 500 • Mit Rdisk = 20 MB/s ist Rtotal = 10 GB/s • F/ Rtotal = 100 • Wachstum: • E/A-Datenrate: 40% pro Jahr • E/A-Kapazität: 100% pro Jahr • CPU-Leistung: 60% pro Jahr Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
E/A-Anforderungen: Entwicklung (2) • 5 Jahre später – neuer Rechner: • F = 10 TFLOP/s (60% pro Jahr) • entsprechend: Ctotal = 200 TB • Mit Cdisk = 1200 GB und Rdisk = 100 MB/s: Rtotal = 166 * Rdisk = 16,6 GB/s • F / Rtotal = 625 Dieser Rechner hat ein 6-fach schlechteres Verhältnis von E/A-Rate zu CPU-Leistung ! Engpaß ist E/A-Rate, nicht E/A-Kapazität Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Kostenfaktoren • Was sind die Kostenfaktoren ? • Flaschenhälse • Optimierungspotential • Zugriffszeiten Speichersystem (Platten) • Zahl der Anforderungen • Suchzeiten & Bandbreite • Kommunikationszeit • Zahl und Größe der Datenpakete / Nachrichten • Überlastungseffekte • Zahl der Clients, die gleichzeitig eine Ressource nutzen Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Verfahren & Implementationen • Aufbau von Systemen mit paralleler E/A • Verfahren zur Nutzung dieser Systeme • Implementationen • Hardware • Software • Schnittstellen Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Stripetiefe Striping • Basisverfahren zur Bandbreitenerhöhung: • Nutzung von N parallelen Speichersystemen • bis zu N-fache Bandbreite Stripefaktor Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
RAID (1) • Redundant Array of Inexpensive Disks • RAID 0: Striping ohne Redundanz • N-fache Bandbreite bei N Platten • softwaremäßig möglich • RAID 3: Striping mit Redundanz • Jeder Zugriff erfolgt auf alle Platten • gut für wenige, große Zugriffe • RAID 5: Striping mit Redundanz • Separate Plattenverwaltung, verteilte Paritätsspeicherung • bei kleinen, hochfrequenten Zugriffen besser als Level 3 • schlechter bei bei (langen) Schreibzugriffen Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
RAID (2) • Kombinationen einzelner RAID-Modi: • RAID 10: Modi 0 und 1 (Spiegelung) • Striping über gespiegelte Platten • Schnell & sicher, aber verschwenderisch • RAID 53: Modi 0 (sic!) und 3 • Striping über redudante Arrays • Schneller als entspr. RAID 3 • Platz-effizienter als RAID 10 Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
P P P P Speicher Shared Memory (1) Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
cc-NUMA Speicher P P P P P P P P cc-NUMA Bridge Speicher Bridge Shared Memory (2) Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
P P P P P P P P P P P P Distributed Memory (1) • Rechen- und E/A-Knoten Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
P P P P P P P P P Distributed Memory (2) • Separates E/A Netz für SAN-System Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
P P P P P P P P P Distributed Memory (3) • Homogene Universalknoten Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Dateisysteme: Architektur • Schnittstelle: Zugriff über • Bibliothek • Betriebssystemschnittstelle • Dateistruktur • Verteilung der Daten über die Speichersysteme • Steuerbar durch den Benutzer ? • Implementationsaspekte: • Zuverlässigkeit (RAID ?) • Zugreifbarkeit – intern und extern • Caching – Ort und Größe des Caches, Konsistenzmodell • Andere Optimierungen (Prefetching) • Dedizierte E/A-Knoten ? Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Intel PFS • Einsatz in Intel Paragon: • Verteiltes Betriebssystem OSF/1 AD • Strikte Trennung der Knotenfunktionen: • E/A, Compute, Service • E/A-Knoten = Compute-Knoten + RAID-3 • PFS setzt auf UFS auf • Striping über mehrere UFS-Dateisysteme • E/A-Knoten für Paging in Baumstruktur organisiert • Caching auf E/A-Knoten deaktivierbar • Einsparung (mindestens) eines Kopiervorgangs • Prefetching Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Sun MC • Solaris MC: Sun Forschungsprojekt • Basierend auf Solaris • Ziel: Multi-Computer mit Single-System-Image • virtuelles SMP System • Kernel-Dateisystem PXFS (Proxy File System): • Kohärentes Caching der Clients: • Daten, Attribute, Verzeichniseinträge • Granularität: VM page oder Cacheline (cc-NUMA) • Hochverfügbarkeit und Replikation • CORBA-basierte Schnittstellen / Kommunikation • Ersatz für vnode-Schnittstelle Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Sun MC: Integration Standard Solaris Solaris MC Kernel Kernel vnode/VFS Caches pxfs client IDL vnode/VFS pxfs Server Provides vnode/VFS vnode1 vnode2 vnode1 vnode2 Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Sun MC: Hochverfügbarkeit • Server-Replikation mit Shared Mirrored Disks • Client- und Serverausfälle sind transparent pxfs Client pxfs Client pxfs Server pxfs Server Checkpoint messages logging UFS logging UFS Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Sun PFS: Kennzeichen • Client/Server Prinzip • dedizierte oder nicht-dedizierte E/A-Knoten möglich • Kommunikation über MPI • Schnittstellen: • Standard-VFS Dateisystem • Laufzeitbibliothek • Optimiert auf große Dateien • Einfachere Dateiindizierung (als bei UFS) • größere Datenblöcke (als bei UFS) • Server-seitiges Caching • Konsistenz: sequentiell oder „entspannt“ Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Userspace Userspace Kernel Kernel Sun PFS: Architektur Client Server Unix Commands MPI-IO Job I/O-Daemon RTL Proxy-Daemon Raw I/O Device VFS PFS Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Sun PFS: Leistung • 32 x HPC 450, 4 CPUs @ 300MHz, 4 GB RAM • Dedizierte PFS-Platte, ATM-Netz (16MB/s) • 32 Prozesse, verteilte Matrix, Spaltengröße variiert Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Sun PFS vs. UFS • Warum nicht immer PFS statt UFS ? • PFS optimiert auf typisches paralleles Lastprofil • Schlechtere Leistung bei Standard-Lastprofil: • kein client-side caching & große Blöcke! • Ineffizient für viele kleine Dateien: Platz & Overhead • Verfügbarkeit: • Keine Redundanz zwischen den Servern • Replikation / Software-RAID kostet Leistung • Integrität: • Beschädigung auf einem Server betrifft gesamtes FS Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
IBM PIOFS / Vesta • Einsatz auf SP2 unter AIX: • Keine dedizierten E/A-Knoten • Alle Knoten haben mindestens eine Platte • Zuweisung via Software (E/A, Compute, oder beides) • Striping über JFS Dateisysteme • Stripe-Faktor pro Datei setzbar • Caching des JFS auf E/A-Knoten • 2-Dimensionales Dateilayout möglich • Einrichtung von Sub-Dateien • Standard-mäßiges mounten • Kommunikation über UDP/IP via SP2-Switch Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
IBM GPFS / Tiger Shark • Shared-Disk Dateisystem für SP2-Cluster: • Platten senden/empfangen Datenblöcke direkt über SP-Switch • Skalierbarkeit: • verteilte Verarbeitung der Metadaten • Aber: tokenbasierte Synchronisation mit einzelnem Server! • Tokensynchronisation für Schreibzugriffe • feingranulare gemeinsame Zugrife: thrashing! • Pagepool für Caching/Prefetching (typ. 20MB) • Prefetching nur bei sequentiellen Zugriffen • Sequentialisierung von versetzten Zugriffen • MPI-IO für irreguläre Zugriffe empfohlen! Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Weitere Systeme • CXFS (SGI) - Komplexes SAN-FS • Fibre-Channel Interconnect, Hochverfügbar • Client-Side Caching • Standardschnittstelle • nicht (primär) für parallele E/A entworfen • xFS (Berkeley NOW) – Software RAID • Datenreplikation • Jeder Rechen-Knoten ist auch E/A Knoten • ein Knoten als Manager pro Datei • kein zentraler Server • Andere E/A-Modelle: • River (Berkeley): Datenflußmodell (Producer-Consumer) • Kopplung auf Device-Ebene (Honkkong) Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
PVFS • Siehe Fallstudie Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
POSIX • Standard-Unix-Dateioperationen: • open(), read(), write(), flush(), fcntl(), close() • synchron • Übermittelte Informationen: • Kontinuierlicher Datenblock (mit Länge) • Position in der Datei • Erweiterungen: • Asynchrone Ausführung • Nicht-kontinuierliche Datenblöcke • Kein Ausdruck für Parallelität! Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Getrennte Dateizeiger Gemeinsame Dateizeiger Ungeordnet Knotenordnung M_RECORD sync‘iert M_SYNC Nicht sync‘iert Atomar M_UNIX Nicht atomar M_ASYNC Gleiche Daten M_GLOBAL Versch. Daten M_LOG Intel OSF/1 mit PFS • Erweiterungen von POSIX: • Synchrone und asynchrone Aufrufe • Neue I/O-Modi: PFS I/O Modi Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
MPI-IO • Ziel: Anwendungen mit hohem E/A-Anteil portabel und effizient zu machen • Analogie zu Message Passing: • Daten schreiben / lesen = Nachricht senden / empfangen • Unterstützung von collective buffering und disk-directed I/O durch Anwendungs-Schnittstelle • Partitionierung der Datei zwischen Prozessen • Kollektive Zugriffe • (benutzerdefinierte) Datentypen • Asynchrone Zugriffe • Kontrolle der physikalischen Lage der Daten • Teil des MPI-2 Standards, verschiedene Implementierungen Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
etype filetype Löcher view: ... displacement Sichtbare, zugreifbare Daten MPI-IO: etype & filetypes • etype: elementary datatype = MPI Datentyp • Grundeinheit des Datenzugriffs • filetype: aufgebaut aus etypes • Partitionierung der Datei auf die Prozesse Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
etype filetype Prozess 0 filetype Prozess 1 filetype Prozess 2 view: ... displacement MPI-IO: file partitioning • Mehrere Prozesse greifen auf eine Datei zu • Datenverteilung via filetypes & views Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
View 1 View 2 Offset 1 Offset 2 MPI-IO: API - Dateimanipulation • Common Prefix: MPI_File_... • open(), close(), delete(), ... • set_info(), get_info() • Striping Parameter • E/A-Knoten spezifizieren • Felddimensionen („chunks“) • set_view(), get_view() Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Positionierung blockierend? Aufruf read write iread / MPI_Wait iwrite / MPI_Wait read_at write_at iread_at / MPI_Wait iwrite_at / MPI_Wait read_shared write_shared iread_shared / MPI_Wait iwrite_shared / MPI_Wait Lokaler Zeiger Expliziter Offset Gemeinsamer Zeiger blockierend nicht-blockierend blockierend nicht-blockierend blockierend nicht-blockierend MPI-IO: API – Individueller Zugriff Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Positionierung blockierend? Aufruf read_all write_all read_all_begin / ...end write_all_begin / ...end read_at_all write_at_all read_at_all_begin / ...end write_at_all_begin / ...end read_ordered write_ordered read_ordered_begin / ...end write_ordered_begin / ...end Lokaler Zeiger Expliziter Offset Gemeinsamer Zeiger blockierend nicht-blockierend blockierend nicht-blockierend blockierend nicht-blockierend MPI-IO: API – Kollektiver Zugriff Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Fallstudie: Cplant@Sandia • MPP-Hintergrund • Ehemals größte Intel Paragon-Installation • ASCI Red / Intel TFLOPS • Umstellung auf Off-the-shelf-Technologie • Konzept: Maximale Skalierbarkeit (1000e Knoten) • Unabhängige, „skalierende“ Komponenten • Generische Technologie • Kontinuierlicher Aus- und Umbau des Systems • Partitionierung des Systems in Funktionsbereiche • Trennung durch klare Schnittstellen • Einfache Umkonfiguration • Ausreichend Ressourcen zur Systembeobachtung/wartung Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Cplant: Architektur Prinzipieller Aufbau: • Realisation: vielstufige Entwicklung • mehrere Clustergenerationen (z.Z. bis 1024 Knoten) Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Cplant: I/O, Stufe 1 • I/O-Dienst yod auf I/O-Knoten • Round-Robin-Scheduling Compute – I/O Knoten • „parallele“ I/O auf unabhängige, getrennte Dateien • POSIX-Schnittstelle:pf_open(), pf_seek(), pf_read(), ... • Jeder Prozeß arbeitet auf individueller Datei: • Brauchbar für temporäre Dateien etc. • fixierte Zahl von Prozessen für Anwendung • Administration der Dateien: Albtraum Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
ENFS ENFS ENFS ENFS VizNFS gigE switch Cplant: I/O, Stufe 2 • ENFS-Dienst: • NFS ohne locking • Keine Sychronisation • Skalierbarkeit: • Mehrere Pfade zum Server • I/O-Knoten als Proxy • Server muß Leistung bringen: • 119 MB/s von 8 I/O-Knoten auf eine SGI O2K mit XFS • Einsatz: Visualisierung Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Cplant: I/O, Stufe 3 • Evaluierung: • PVFS ? • Compaq’s Petal/Frangipani ? • Anderes kommerzielles SAN-System ? • Fortsetzung unter www.cs.sandia.gov/cplant Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
Fallstudie: PVFS • Vielzahl von frei verfügbaren Lösungen für parallele E/A: • Galley FS • Panda • PIOUS • PPFS • .... • Forschungsprojekte mit bestimmten Schwerpunkt • PVFS: • Entwicklung & Zielgruppe • Architektur • Evaluation Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
PVFS: Entwicklung & Zielgruppe • Open-Source Entwicklung der Clemson University • Zielgruppe: • Linux-Cluster mit TCP/IP Interconnect • Designziele: • Hohe Bandbreite für typische parallele E/A • Vielfältige API Unterstützung: • Native PVFS, Unix/POSIX, MPI-IO • Integration: • Nutzbar mit Standard-Unix-Werkzeugen • Allgemein: durch jede Anwendung ohne Neucompilierung • Robust, skalierbar, einfach zu installieren, ... Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme
PVFS: Architektur • Frei konfigurierbare Knotentopologie: • Compute, I/O, Compute & I/O • TCP/IP-Kommunikation • Zentraler Metadaten-Server • Aufsatz auf lokales Dateisystem: • ext2, ReiserFS, ... • Server-seitiger Cache • Client-seitiger Cache? Prefetching? • Stripe-Konfiguration pro Datei • Nicht aufregend – aber einsatzfähig! Parallele E/A auf Clustern – Chemnitz 2001 Lehrstuhl für Betriebsysteme