Speichersysteme am LRZ

Transkript

1 Speichersysteme am LRZ

2 Wir bieten Speicherplatz für... Endbenutzer Fileservices und Dateiablagen für Studenten und Mitarbeiter des LRZ, der TUM und LMU Benutzer können mit ihrer LRZ Kennung Daten am LRZ speichern Vom LRZ betriebene Dienste E Mail, WWW, Datenbanken, VMware,... Hintergrundspeicher für Anwendungen Hochleistungsrechnen (HPC) Linux Cluster und Höchstleistungsrechner HLRB2 Speicherplatz für Projekte und temporäre Daten

3 Datenhaltung im Rechenzentrum Früher: Direct AWached Storage FestplaWen in jedem Server (oder direkt angeschlossen) Integrierter RAID Kontroller Verwaltung durch Serveradministrator

4 Network AWached Storage Heute: Speichersystem getrennt vom Server Anbindung über LAN oder SAN Hochverfügbare Konfigura[onen möglich Verwaltung durch spezialisiertes Personal O] zusätzliche Funk[onen wie Snapshots oder Replika[on Zentralisierung erfordert höhere Verfügbarkeit!

5 Architekturvergleich Server Festplatte Direct Attached Storage Server Network Attached Storage LAN Speichersystem Festplatte Server Festplatte Server SAN Festplatte Server Storage Area Network

6 Zugriffsprotokolle Blockbasiert Dateneinheit: Datenblock (à 512 byte) Verwaltungseinheit: LUN (virtuelle FestplaWe) SCSI, Fibrechannel, SAS, SATA, iscsi, FCoE,... Rechner verwaltet Dateisystem selbst Dateibasiert Dateneinheit: Datei Verwaltungseinheit: Dateisystem NFS, CIFS, AFS, Lustre... Speichersystem stellt Dateisystem bereit Mehr Informa[onen über die Daten verfügbar Dateityp, Größe, Änderungszeit, Besitzer, Zugriffssrechte,...

7 LRZ Umgebung Speichersysteme 2x2 Primär Speichersysteme 2 Replika[onssysteme 2 Speichersystem Cluster (8 bzw. 2 Knoten) Test /Stagingsysteme Netzanbindung über Gigabit und 10G Ethernet 1220 FestplaWen 870 Fibre Channel, 350 SATA, >300 TB bruwo 14 ausgetauschte FestplaWen in 2008 (1,15%)

8 Beispiel für Storage Kontroller Netapp FAS 3050 (Baujahr 2005) Zwei Kontroller als HA Paar 12 Disk Shelves mit je 14 FestplaWen BruWo 26,2 TB newo 19,4 TB Versorgt alle E Mail Systeme des LRZ, 100 weitere Server und 450 Arbeitsplätze Eigenscha]en NFS, CIFS, iscsi, Snapshots, Dateisysteme vergrößern und verkleinern, Replika[on, NDMP, Quality of Service, RAID DP Rollende So]ware und Firmware Updates Automa[sche FestplaWen Diagnose Failover Zeit: ca. 15 Sekunden Bootzeit nach Kaltstart: ~60 Sekunden Up[me: momentan 576 Tage und 248 Mrd. NFS, 80 Mrd. CIFS und 7 Mrd. iscsi Opera[onen

9 Speichersysteme im Hochleistungsrechnen Charakteris[k Große Datenmengen (viele Dateien und/oder Daten) Hohe Skalierungsanforderungen o] 1000 von Clients! Parallele Dateisysteme Dateien und Dateiteile werden über mehrere Server verteilt Besserer Durchsatz und höhere Kapazität Hohe Komplexität Exis[erende Dateisysteme Durchsatz >100 GB/s Kapazität >1 PB In Planung Durchsatz GB/s Kapazität PB Im Prinzip nur durch Hardware limi[ert

10 Fallstudie: Linux Cluster Node pools for serial jobs Node pools for parallel jobs Interactive & Login nodes Management nodes... Legacy filesystem AFS servers Router to external networks GigE X 10 GigE Gigabit / 10 Gigabit Ethernet network (10 GigE core) 4x GigE 10 GigE 10 GigE 10 GigE GigE OSS OSS... OSS 10 GigE Lustre: 180 TB 600+ FestplaWen Benchmarks only NAS-filer FAS 6070 NAS-filer FAS 3050 NFS server MDS Lustre parallel filesystem

11 HLRB2 Disksubsysteme

12 Fallstudie: HLRB2 SGI Altix 4700 CXFS SAN Storage 64 RAID Controllers 3072 disks RAID Common NUMAlink interconnect 8x FC 10 GigE FibreChannel Storage Area Network (384 ports) 10-Gigabit- Ethernet 4x FC RAID RAID RAID... CXFS Metadata servers (HA-Cluster) 512 cores 2 TB RAM per partition 1x login/interactive, 18x batch partition 2x GigE NAS- Filer NAS- Filer NAS- Filer... NAS- Filer Ontap GX clustered NFS server (8 nodes) Internal cluster GigE network

13 Gefahren für Daten Hardware Defekte FestplaWen, Kontroller, Netzkomponenten Physikalische Beschädigung: Feuer, Wasser, Naturgewalten, Diebstahl,... So]ware Fehler in System So]ware (Firmware) Fehler in Applika[onen Bösar[ge Applika[onen (Viren) Benutzer Absichtliches oder versehentliches Löschen oder Verändern von Daten

14 Schutzmechanismen Hardware Probleme Redundanz bei Datenspeicherung (z.b. RAID) Prüfsummen (welche Daten sind rich[g?) Mehrfache Auslegung von Kabeln, Kontrollern, Netzteilen etc. Daten Replika[on Kein Schutz vor defekter So]ware oder Benutzern! Benutzer oder Applika[onsfehler Kopien von Daten oder Snapshots Storage So]warefehler Kopien von Daten Anderes Medium, anderer Standort Kriterien: Kosten, Sicherungs und Wiederherstellungszeit

15 FestplaWen Enterprise SATA 3,5 FibreChannel 3,5 SAS 2,5 Kapazität 1 TB 450 GB 146 GB Umdrehungsgeschwindigkeit UpM UpM UpM Zugriffszeit 9 ms 3,5 ms 3,1 ms Stromverbrauch (Ruhe/Betrieb) Nichtkorrigierbare Lesefehlerrate 8 / 11 WaW 12 / 17 WaW 4,1 / 7 WaW 1 Sektor pro 10^15 Bits (Desktop 10^14!) 1 Sektor pro 10^16 Bits 1 Sektor pro 10^16 Bits

16 Fehlertoleranz I Faustregel 100% aller FestplaWen gehen (irgendwann) kapuw Black Out vs. defekte Sektoren vs. Totalausfall Schutz durch Redundanz (RAID): Level 0 (Verteilung) Level 1 (Spiegelung) Level 4/DP (einfache/doppelte Parität) Level 5/6 (verteilte einfache/doppelte Parität) RAID 4/5 (einfache Parität) reicht nicht mehr Bei 8+1 FestplaWen mit 1 TB (SATA) werden bei einer Rekonstruk[on nach PlaWenausfall 8*1TB=8*8*10^12=6.4*10^13 Bits gelesen SATA Fehlerrate: 1 auf 10^15 Bits (10^14 bei Desktop Modellen) Hohe Wahrscheinlichkeit eines weiteren defekten Sektors! Einsatz von RAID 6 / RAID DP ist heu[ger Stand der Technik

17 Fehlertoleranz II Prüfsummen Bei vorhandener Redundanz die korrekten Daten finden! Regelmäßige, autaoma[sche Prüfungen ( Scrubbing ) Fehler finden, solange die Redundanz noch vorhanden ist Disk Ebene vs. Dateisystem Ebene Snapshots Effiziente Kopien eines gesamten Dateisystems Platzverbrauch propor[onal zu den Änderungen, nicht zu den Daten Es gibt unterschiedliche Implemen[erungen Copy On Write (z.b. Linux LVM, VMware) Integriert im Dateisystem (z.b. ZFS, WAFL,...) Können schnell erstellt und (meist) schnell gelöscht werden Kein Schutz vor Datenkorrup[on ?

18 Snapshots brief.txt Vor Snapshot brief.txt brief.txt* Nach Snapshot brief.txt brief.txt* Nach einer Änderung

19 Replika[on + Deduplika[on Replika[on zeitnahe Kopie eines Speichersystems an einem weiteren Standort Schnelle Wiederherstellung durch Umschalten auf das Replikat! Synchron Alle Schreibzugriffe werden sofort übertragen, Latenz! Asynchron Abgleich in wählbaren Intervallen (z.b. 1x pro Stunde) Diverse Verfahren: Dateibasiert (rsync), Log basiert, Snapshots,... Wie findet man die Änderungen? Deduplika[on Mehrfach vorhandene Daten finden Hash auf Dateisystem Block (4 kb) Ideal für VMware Jede virtuelle Maschine (VM) hat eine virtuelle FestplaWe (=Datei) Neue VMs werden durch Kopieren einer Vorlage erstellt Damit o] nahezu iden[sch! Bis 75 90% Ersparnis in realen Umgebungen

20 Fallstudie: Dateidienste MWN Active Directory (LRZ / IntegraTUM / LMU) Operations Manager (Managementkonsole) "Externe" Benutzer (über VPN) NAS-Filer (Replikationssystem) Authentifikation X-WIN (+Internet) TSM Server (Library Manager) Snapmirror TUM Campus (Garching) LRZ Garching TUM (Weihenstephan) NAS-Filer (Primärsystem) NDMP Lanless Backup TUM Stammgelände (München) LMU Stammgelände (München) M-Net (Internet Backup) Storage Area Network TUM Klinikum (M.-Grosshadern) "Interne" Benutzer (CIFS) Münchner Wissenschaftsnetz (MWN) (Backbone-Infrastruktur) TSM Bandarchivsysteme Steuerung LRZ interne Netze