Storage-Trends am LRZ. Dr. Christoph Biardzki

Transkript

1 Storage-Trends am LRZ Dr. Christoph Biardzki 1

2 Über das Leibniz-Rechenzentrum (LRZ) Seit 50 Jahren Rechenzentrum der Bayerischen Akademie der Wissenschaften IT-Dienstleister für Münchner Universitäten und Forschungseinrichtungen Daten- und Archivzentrum Europäisches Tier-0 Supercomputing-Zentrum SuperMUC : derzeit #10 in Top PB online auf Disks Leibniz-Rechenzentrum 2

3 Vor vielen, vielen Jahren Leibniz-Rechenzentrum 3

4 Themen Benutzeranforderungen und Trends Architekturen Suchmaschinen Mit Beispiel NoSQL Implementieren Cloud vs. Storage Leibniz-Rechenzentrum 4

5 Benutzeranforderungen (altes Modell) Leibniz-Rechenzentrum 5

6 Anforderungen Kann ich vom Supercomputer auf meine Datenbank zugreifen? Können weltweite Benutzer meine Simulationssoftware über ein Webportal nutzen? Wie kann ich Millionen von Digitalisaten in ein anderes Format konvertieren? Wie kann ich interaktiv eine Milliarde Sterne untersuchen? Leibniz-Rechenzentrum 6

7 Benutzeranforderung: vollständige Workflows Leibniz-Rechenzentrum 7

8 Storage steht im Mittelpunkt von Workflows Aber unterschiedliche Modelle je nach Gebiet... Dateisysteme NFS Parallele Dateisysteme: Lustre, GPFS,... (Relationale) Datenbanken MySQL, Postgres, Oracle,... NoSQL Key-Value, Document-Stores, Object-Stores,... Suchmaschinen Lucene & co Leibniz-Rechenzentrum 8

9 Trends Klassische Schichtung Storage-Server-Applikation wird aufgebrochen Software-RAID (WAFL, ZFS, BTRFS, GPFS Storage Server,...) Replikation und Failover auf Applikationsebene (Exchange, diverse NoSQL-Lösungen,...) Exploration des CAP-Raums Traditionell Fokus auf Konsistenz und Verfügbarkeit Leibniz-Rechenzentrum 9

10 Trends II: Suchmaschine statt Datenbank Einsatzgebiet: Analytische Anwendungen auf großen Datenmengen Ich muss 1000 X pro Sekunde erfassen Ich habe eine Milliarde von X und möchte in Echtzeit suchen X = Buch, Stern, Event, Fahrzeugposition,... Potentielle Probleme bei relationalen Datenbanken Antwortzeiten bei großen Queries Horizontale Skalierbarkeit Nicht benötigt: Transaktionsgarantien Benötigt: Antwortzeiten im ms-bereich, Scale-out Leibniz-Rechenzentrum 10

11 Interessante Open-Source-Suchmaschinen Solr Cloud und Elasticsearch Beide basierend auf Lucene-Engine Speichereinheit ist ein Index, in dem Objekte (z.b. Bücher) abgelegt werden Standardmäßig werden alle Attribute des Objekts im Volltext indexiert Index kann aus mehreren Shards bestehen Shards können auf unterschiedlichen Servern liegen (Skalierbarkeit) Shards können repliziert werden (Verfügbarkeit) Leibniz-Rechenzentrum 11

12 Nutzungsmuster für Suchmaschinen Indexieren Aus einer anderen Quelle (Datei, Datenbank,...) Alternativ: Suchmaschine ist einziger Datenspeicher Kurze Verzögerung bis auffindbar (~1s) Ändern / Löschen Ändern ist möglich, aber langsam Löschen: Pattern neuer Index pro Tag, Index löschen ist einfach als einzelne Objekte löschen Suchen Komplexe Queries möglich inkl. Ranking Parallele Suche in Shards vs. Routing Mehrere Indizes können durchsucht werden Leibniz-Rechenzentrum 12

13 Big Data: Problemanalyse SuperMUC-Jobs Was ist ein Job? Paralleles Benutzerprogramm In der Regel 32 bis 2048 aus ~10000 Servern und bis zu 48h Dauer Gelegentlich funktioniert etwas nicht - Fehlersuche Aufgabe Für einen gegebenen Job alle Informationen über die jeweiligen Server während der Laufzeit finden und aufbereiten Logeinträge, Statistiken usw. Tool: Splunk (kommerzielle Suchmaschine ) Leibniz-Rechenzentrum 13

14 Jobanalyse: Server vs. Zeit Leibniz-Rechenzentrum 14

15 Integrierte Event- und Statistikerfassung ~10 Mio. pro Tag gesamt Job auf 500 Knoten mit 24h Laufzeit in den letzten 7 Tagen: 500k Events aus 70 Mio. Events Leibniz-Rechenzentrum 15

16 Leibniz-Rechenzentrum 16

17 Belegungs- und Energieeffizienz Klassisches RAID Beispiel RAID6 / DP Netto-Speicherplatz theoretisch: >87% (bei 14+2 Disks) NoSQL / Replikation 1-fache Replikation <50% 2-fache Replikation <33% Häufig wird empfohlen, kein RAID untendrunter zu nutzen Bei 4 TB Disks braucht ein Petabyte (geschätzt) auf RAID6: 286 Disks Mit 2-facher Replikation: 750 Disks + viele Server! Abwägung: Kapazität vs. Performance vs. Verfügbarkeit vs. mehrere Standorte vs. Stromverbrauch vs. Kosten für die jeweilige Lösung Leibniz-Rechenzentrum 17

18 NoSQL-Fallstricke Freies Sizing von Hardware: Fluch oder Segen? Lastvariationen, Timeout-Toleranz RAM- / Puffer-Tuning, Java Garbage Collector-Tuning Periodische Jobs oft schwer einschätzbar Hintergrund-Tasks wie Merges oder Replikation Fehlerhandling in Applikationen SQL: Verbindungsfehler und Timeouts sind eher selten NoSQL: Timeouts können jederzeit vorkommen Intelligente NoSQL-Clients Haben Bewusstsein für Zustand des Clusters Intelligentes Routing von Anfragen Leibniz-Rechenzentrum 18

19 Testen und Betreiben von NoSQL Wie testet und betreibt man NoSQL-Lösungen? Viele Server werden benötigt Konsistente Performance ist wichtig (Timeouts, again) Optionen am LRZ Dedizierte Hardware Teuer und oft nicht ausgelastet Virtuelle Plattform / Cloud Performance trickreich Als Supercomputer-Job NoSQL on demand Leibniz-Rechenzentrum 19

20 Storage vs. Cloud Cloud auf dem Storage Derzeitiges Betriebsmodell z.b. für VMware Virtualisierung auf skalierbarem NFS-Storage Schwerpunkt: Zuverlässigkeit Storage in der Cloud NoSQL-Applikationen wollen eigenen Storage Shared / HA-Storage ist nicht nötig (Verschwendung?) Cluster bestehen aus VMs mit lokalen Disks Je nach Abwägung Größe vs. I/O-Intensität liegen diese auf NFS-Storage oder lokalen SSDs (Testbetrieb) Leibniz-Rechenzentrum 20

21 NoSQL als Service Können Anwender NoSQL selbst betreiben? Ein vorsichtiges nein aus heutiger Sicht Tuning derzeit zu komplex Enttäuschungsmanagement? NoSQL a la carte als Service im Rechenzentrum Elasticsearch, Hadoop, Splunk etc. on demand Basis: Cloud oder als Job auf HPC-Plattform Integration in die Workflow-Palette Leibniz-Rechenzentrum 21