Lokationsunabhängiges hierarchisches Storage Management HPCN Workshop, 25./26. Mai 2011 in Braunschweig Michael Sattler, T-Systems Solutions for Research Konzepte / Vergleich

Motivation Trend im DLR zur Vermehrung von Standorten Kooperationen mit Industriepartnern Zusammenarbeit mit anderen Forschungseinrichtungen und Universitäten Gleichzeitige Abnahme der Anzahl an Mitarbeitern je Standort IT-seitig ist ein umgekehrter Trend zu beobachten Kapazitäten der notwendigen Systeme übertreffen die mögliche Nutzung selbst an größeren Standorten Zunahme von Standorten führt zu einer Vermehrung nicht ausgelasteter Ressourcen Gleichzeitig geht eine Zunahme des Betreuungsaufwandes einher (Vor-Ort Services) Abwägung von Wirtschaftlichkeit gegenüber Verfügbarkeit und Qualität

WAN - Landschaft

Anforderungen DLR weiter einheitlicher Namensraum Alternativen: Zentrale Datenspeicherung, oder nur zentrale Datensicherung (Backup/Archivierung) Benutzer soll möglichst keinen Unterschied in der Performance spüren (lokale Caches) Soll den reisenden Mitarbeiter bestmöglich unterstützen (heute hier, morgen da …) Standortwechsel (Umzug) ohne Aufwand möglich Geringer administrativer Aufwand Leistungsfähiges WAN (10 Gb/s) als Basis

Alternative Konzepte DDN – WOS mit iRODS WOS – Web Object Scaler iRODS – integrated Rules Oriented Datamanagement System NetApp – StorageGRID mit FlexCache StorageGRID – Solution to manage petabyte-scale globally distributed repositories FlexCache – Tiered Storage Infrastructure IBM – GPFS mit Panache GPFS – General Parallel File System Panache – A parallel WAN Cache for Remote File Clusters

DDN – WOS mit iRODS „Web Object Scaler“ mit „integrated Rules Oriented Datamanagement System“ Appliance (Vendor Lock-in) Schnittstelle NFS v3 (POSIX), voraussichtlich ab Q3/2011 Nicht dynamisch: Bis zu 4 Replikationen möglich (Standortbezug möglich), aber keine Caches Regelbasierte Replikationen möglich Regeln können Datentyp (Extension?, Dateigröße?, …) bezogen sein? System besteht aus: Einzelnen, unabhängigen Appliances Diese können sehr einfach zur Kollaboration konfiguriert werden Redundante Trays für Metadaten Bis zu 10-fache Performance gegenüber herkömmlichen (sequentiellen, nicht skalierbaren) Filesystemen WOS Buckets und WOS Object Slots um Speicherplatzverschwendung zu vermeiden Hohe Ausfallsicherheit Einfache Erweiterbarkeit (zusätzliche Appliances) Datendurchsatz zwischen den Standorten derzeit nicht parallel (pNFS auf Roadmap) WOS Buckets / Slots – siehe übernächste Folie

DDN – WOS mit iRODS System-Architektur

DDN – WOS mit iRODS WOS: Buckets + Slots

NetApp – StorageGRID mit FlexCache „Management of globally distributed repositories“ with „Tiered Storage Infrastructure“ Proprietäres System (Vendor Lock-in) Schnittstelle NFS v3, CIFS, SMB1 Statisch und Dynamisch: Replikation (konfigurierbar für mehrere gleichzeitig auftretende Fehler, auch Ausfall einer Site sowie regionale Desaster), lokales Caching. System besteht aus: NetApp Appliances Objektbasierte Storage Lösung Metadaten basiertes Datenmanagement Massiv parallele Transaktions Engine Integriertem Load Balancing Verbindet Plattformen über verschiedene Standorte hinweg Globale und ständige Verfügbarkeit (24*7, global, always-on availability) Metadata-based management Automates data lifecycle management, permitting management of billions of objects by multiple criteria over multiple technology generations

NetApp – StorageGRID System-Architektur

NetApp – FlexCache System-Architektur

IBM – GPFS mit Panache „General Parallel File System“ with „A parallel WAN Cache for Remote File Clusters“ Software kann prinzipiell unabhängig von Hardware verwendet werden Schnittstelle GPFS-Client (Linux, MacOS, Windows, AIX) oder NFS Export (POSIX) Dynamisch oder statisch: Caching und Replikation innerhalb GPFS möglich System besteht aus: Zentrales, performantes, paralleles Storage-System (GPFS) Standortbasierte lokale „Panache Cache Cluster“ Verbindung lokal – zentral über pNFS Synchrones Lesen von nicht gecacheten Daten Asynchrones Schreiben von Daten möglich Betrieb bei unterbrochener Verbindung möglich Policy Engine von GPFS ermöglicht vielfältige Einstellungen für den Cache welche Daten werden prefetched wann werden Daten im lokalen Cache wieder gelöscht Hoher Datendurchsatz mittels pNFS möglich (Netzwerkabhängig) Voraussichtlich ab Q4/2011 verfügbar

IBM – GPFS mit Panache System-Architektur

Offene Punkte Fragen / Nebeneffekte Mengengerüst Standorte (Bandbreite, Latenz) Anzahl Benutzer Datenänderungsraten … Vergrößerung der notwendigen Speicher Kapazität (Zentral + Cache(s) => wesentlich höhere Kosten) Eventuell werden sehr große Datenmengen (sinnvoll?) bewegt (IBM, DDN: Block-Level, NetApp?) Jeder Standort braucht lokalen Cache (File-Server, kaum kleiner zu dimensionieren als ein File-Server der den Dienst einfach lokal ausführen würde) Wie soll die Anbindung kleiner Außenstellen aussehen? Ausbau, bzw. Beschleunigung des gesamten WAN-Zugriffs notwendig! Erfahrungen aus 100 Gbit/Testbed Dresden-Freiberg in Bezug auf GPFS-Leistung und Latenzverhalten können eingebracht werden.

Where we are: Results of the 100 Gbit/s Testbed. Network-Performance Achievable Bandwidth Latency (ping) LAN based on 1 GE 0.9 Gbit/s 0.5 – 1 ms DFN X-WIN (1 Gbit/s access, Göttingen-Braunschweig, Cisco/Huawei Eqpmnt.) varying, no dedicated link 4.7 ms 100 Gbit/s Testbed Freiberg-Dresden, ALu Eqpmnt.) 98.4 Gbit/s 0.6 ms 100 Gbit/s Testbed 400km 4.1 ms

Where we are: Results of the 100 Gbit/s Testbed Where we are: Results of the 100 Gbit/s Testbed. GPFS Performance „Out of the Box“ little tuning Performance Read MiB/s Network Read Gibit/s Write MiB/s Write Gibit/s Dresden Local 9057 72.45 7985 63.88 Freiberg Local 8033 64.26 8798 70.83 Dresden -> Freiberg 8804 70.43 8498 67.98 Freiberg-> Dresden 9694 77.55 9662 77.92

Vielen Dank!