Universität Leipzig, Institut für Informatikhttp://dbs.uni-leipzig.de
Cloud Data ManagementKapitel 3: Verteilte Dateisysteme (Teil 2)
Dr. Eric Peukert Sommersemester 2019
CDM SS 19, Dr. Eric Peukert
Data Lake & HDFS
https://solutionsreview.com/data-integration/the-emergence-of-data-lake-pros-and-cons/
CDM SS 19, Dr. Eric Peukert
Read & WriteBlock Replication ManagementHDFS FederationHDFS High Availability (HA)
Titelzeile alle Folien3
CDM SS 19, Dr. Eric Peukert
HDFS Operationen – Write
NameNode DataNode 0 DataNode 1 DataNode 2
HDFS Client/user/bob/file.txt
AB
1. Create file.txt [ ]
1. Erzeugung einer Datei (NN prüft, ob Datei existiert und Nutzer die erforderlichen Rechte hat)2. NN sendet ‘file lease‘ und DNs, auf die 1. Block geschrieben werden soll (dfs.replication (3))3. Leitet Write des Blocks A an DN1 → DN0 → DN2 unter Verwendung eines Stroms von Paketen4. DNs senden Block-Report an NN (Update Mapping)5. Write B …
2. Lease + DNs for A
3. Write A=>{DN0, DN1, DN2}
=>{DN0, DN1, DN2}3.
3.4. Success
A B
AB
AB
AB
CDM SS 19, Dr. Eric Peukert
HDFS Operationen – Read
NameNode DataNode 0 DataNode 1 DataNode 2
HDFS Client/user/bob/file.txt
AB
=>{DN0, DN1, DN2}
=>{DN0, DN1, DN2}
AB
AB
AB
1. Open file.txt
1. Öffnen einer Datei Open für read2. Erhält Block Locations vom NN sortiert nach Distanz zum Client3. Liest ersten Block (A) vom nächsten, erreichbaren DataNode, verifiziert Checksum4. Liest zweiten Block (B) vom nächsten, erreichbaren DataNode, verifiziert Checksum
2. Block locations for A
3. read A 4. read B
2. Get Block Locations for A
4. Get Block Locations for B
4. Block locations for B
CDM SS 19, Dr. Eric Peukert
HDFS Cluster Topologie
NameNodeDataNode 1DataNode 2DataNode 3
Rack 1
DataNode 5DataNode 6DataNode 7
Rack 2
DataNode 4
Rack Switch Rack Switch
DataNode 6DataNode 7DataNode 8
Rack 4
DataNode 5
Rack Switch
NW Switch NW Switch
/
DataNode 2DataNode 3DataNode 4
Rack 3
DataNode 1
Rack Switch
Datacenter 1 Datacenter 2
distance(/d1/r1/n1, /d1/r1/n1) = 0 (same node)distance(/d1/r1/n1, /d1/r1/n2) = 2 (different nodes, same rack)distance(/d1/r1/n1, /d1/r2/n5) = 4 (different racks, same dc)distance(/d1/r1/n1, /d2/r4/n5) = 6 (different racks, different dc)
Annahme: Distanz zum Vorfahr = 1Distanz zwischen zwei Nodes = Summe der Distanzen zum kleinsten gemeinsamen Vorfahr
CDM SS 19, Dr. Eric Peukert
Tradeoff zwischen Zuverlässigkeit (reliability), Verfügbarkeit(availability), Schreib- und LesebandbreiteDefiniert durch Block Placement Policy
Default Policy (dfs.replication = 3)1. Replica auf dem gleichen Knoten wie Client 2. Replica in anderem Rack3. Replica auf dem gleichen Rack wie 2. aber anderer Knoten4. bis n-tes Replica Random-Zuordnung (mit Constraints)
Block Placement
NameNode
DN 1
DataNode 2
DataNode 3
Rack 1
DataNode 5
DataNode 6
DataNode 7
Rack 2
DataNode 4
Rack Switch Rack Switch
NW Switch
1. Create file.txt [ ]2. Write 3. NN replies {DN1, DN5, DN7}4. Write5. NN replies {DN1, DN4, DN6}
A B
Client
A
AA
A
B
BB
B
CDM SS 19, Dr. Eric Peukert
NameNode verwaltet Replikationsstatus der Blöcke (Block Reports)„over-replicated“ Block
Rack wird re-aktiviert nach Netzwerkpartitionierung; Änderung von dfs.replicationNN wählt zu entfernende Replica aus (versucht nicht die Anzahl der Racks zu minimieren, bevorzugt „sehr volle“ DNs)
„under-replicated“ BlockDisk / Server / Rack Ausfall; Änderung von dfs.replicationBlock wird Replication Priority Queue hinzugefügt (nur 1 Replica = höchste Priorität)Queue wird periodisch gescannt und Blöcke werden entsprechend Block Placement Policy verteilt
Alle Replicas sind auf einem Rack (Rack Ausfall)Behandlung des Blocks wie „under-replicated“
Balancer ToolAdministratives Tool, das Über- und Unterauslastung der DNs ermittelt und zum Erreichen einer guten Balance die Blöcke umverteilt
Block Replication Management und Balancierung
CDM SS 19, Dr. Eric Peukert
HDFS1Cluster Speicher skaliert horizontal - der Namespace (NS) nichtProblematisch für große Installationen mit vielen (kleinen) DateienDateisystem-Operationen begrenzt durch NN PerformanzKeine Isolation in Mehrbenutzerumgebung
HDFS2NS wird in mehrere Namespaces aufgeteiltHinzufügen von NameNodes (NN-1, …, NN-n), die je einen Teil des NS (NS-1, …, NS-n) verwaltenNS volume = NS und Block Pool (= Blöcke für NS)NS Volumes sind unabhängigDNs speichern Blöcke aus allen Pools und senden HB/BR an alle NNs
HDFS – FederationÜberblick
NS-1 NS-k NS-n
Block Pools
Pool 1 Pool 2 Pool 3
DataNode 0 DataNode 1 DataNode 2
NN-1 NN-k NN-n
HBBR
CDM SS 19, Dr. Eric Peukert
Hinzufügen von DataNodes -> Speicherkapazität erhöhenEin NameNode verwaltet Namespace des ganzen Clusters
Dateibaum+Metadaten und Block Locations aus Performanzgründenkomplett im RAMYahoo!
Blockgröße: 128MBDurchschnittliche Datei ≈ 600Bytes Metadata (1 File+1-2 Blockobjekte)100Mio Dateien ≈ 60GB Metadata1PB Daten ≈ 1GB Metadata
HS des Namenodes begrenzt horizontale Skalierbarkeit des ClustersVertikale Skalierung des Namenodes
Durchsatz von Lese/Schreiboperationen durch 1 Knoten bestimmtMehr Clusterknoten
Mehr Block ReportsMehr TaskTracker (agieren selbst als HDFS clients)
HDFS – Federation: Motivation
Quelle: [Federation]
CDM SS 19, Dr. Eric Peukert
Mehrere unabhängige NamenodesKeine Kommunikation, jeder NN verwaltet einen eigenen Namespace1 Block Pool pro NamespaceDNs speichern Blöcke aller Namesspaces
Vorteile“Echte” Horizontale SkalierbarkeitPerformanz
Höherer Clusterdurchsatz ermöglicht höheren Parallelitätsgrad
Multi-tenancy & IsolationVerschiedene Mandanten können sich ein Cluster teilenVerschiedene Anwendungen (z.B. Produktivanwendungen wie HBase) haben verschiedene Anforderungen ® “eigener” NameNode
Block Pool Abstraktion ermöglicht Realisierung anderer verteilter Dateisysteme
HDFS Federation: Grundidee
http://hortonworks.com/blog/an-introduction-to-hdfs-federation/
CDM SS 19, Dr. Eric Peukert
Aufteilung des globalen Namespacesauf mehrere NNs soll für Clientsweitestgehend transparent sein
NN verwaltet nur Ausschnitt des NSDN speichern Blöcke verschiedener NSAbwärtskompatibilität
Client-side Mount-tablesBereitstellung einer globalen SichtVerwenden Client-seitiger Mount Tablesähnlich /etc/fstab in unixartigen OS
Es können auch andere Dateisysteme (S3, Local) “gemounted” werden
HDFS Federation: Mount Tables
Quelle: [Federation]
CDM SS 19, Dr. Eric Peukert
HDFS1: NameNode ist SPOFHDFS2 HA
zwei redundante NameNodes in aktiv/passiv Konfiguration
HDFS2 (NFS)HDFS2 HA (QJM)
NFS Share ist SPOFNeu: Quorum Journal ManagerJournal Nodes anstatt NFS share
HDFS – High Availability (HA)Überblick
DataNode 0
A
B
NameNode
HB
I
NameNode
NFS MountCP J
Active Standby
BR HBBR
W R
CDM SS 19, Dr. Eric Peukert
NameNode ist Single Point of Failure (SPOF)Hält FS Tree, Metadaten und Block Locations im HauptspeicherZusätzlich 2 Dateien im lokalen FS
fsimage: Schnappschuss des FS beim Start des NNs (ohne Block Locations)edits log: Protokollierung aller Änderungen gegenüber fsimage (WAL)
Beim Neustart des NN wird fsimage mit edits log gemergedNN wird selten neugestartet à großer edits log à Merge dauert lange
Vor HDFS HA: Secondary NameNode (“Checkpoint Node”)Secondary NN kopiert in regelmäßigen Abständen fsimage und edit log vom NNMergen von fsimage und edits logZurückkopieren der aktualisierten und Ersetzen der alten fsimage DateiIm Fall eines geplanten Neustarts muss NN trotzdem auf Block Reports der Data-Nodes warten à mehrere Stunden für große Cluster (2000 nodes)
Defekt des NNs Änderungen seit letztem Checkpoint verlorenVor HDFS HA: redundante Speicherung von fsimage und edits log (versch. Platten/NFS)
HDFS High Availability: Motivation
CDM SS 19, Dr. Eric Peukert
Verwenden von 2 NN pro Cluster (Namespace bei Federation)Active NameNode bearbeitet Client-AnfragenStandby NameNode für schnelles Failover (“Hot Standby”)Secondary NameNode (“Checkpoint Node”) nicht mehr benötigtDataNodes senden Block Reports periodisch an beide Knoten
Synchronisation von fsimage und edits logActive NN schreibt/aktualisiert edits log synchron in gemeinsam zugänglichen, hochverfügbaren Speicher à 2 Varianten
NFSQuorum-based
Standby NN überwacht diesen Speicher kontinuierlich und wendet Änderungen auf eigenem Filesystem-Abbild im HS an
FailoverNur wenige Änderungen nachzufahren, Block Locations aktuellManuell (Wartung): <3s, automatisch: 30-40s
HDFS HA: Grundidee
CDM SS 19, Dr. Eric Peukert
HDFS HA: Grundidee (2)
Titelzeile alle Folien17
DataNode 0
A
B
NameNode
HB
I
NameNode
NFS MountCP J
Active Standby
BR HBBR
W R
CDM SS 19, Dr. Eric Peukert
Client Failover“Umrouten” der HDFS Clients zum Active NNKonfiguration eines Paares von NameNode-Adressen bei ClientsVerwenden der Adressen in konfigurierter Reihenfolge
Timeout: Retry anderer NN (vormals Standby jetzt Active)Kontaktiert Client den Standby NN ® Antwort-Code ® Retry Active NN
HDFS HA: Client Failover
CDM SS 19, Dr. Eric Peukert
Automatisches FailoverVerwendet Apache ZooKeeper-Quorum
Hochverfügbarer KoordinationsserviceVerteilte Synchronisation von Konfigurationen, Mitgliedschaft, Leader Election
Jeder NN hat dauerhafte Verbindung zu ZooKeeper-ClusterActive NN Crash ® ZooKeeper-Session Timeout ® ZooKeeper informiert Standby NN, dass Failover initiiert werden muss
Dazu ZooKeeper Failover Controller-Prozess (ZKFC) auf jedem NN
Active NN Election, ZooKeeperSession Management, Health Monitoring
HDFS HA: Automatic Failover
Quelle: [HDFSHA]
CDM SS 19, Dr. Eric Peukert
FencingSplit Brain-Szenario
Beide NNs nehmen an sie sind Active NNWidersprüchliche Änderungen am FS TreeEs darf zu einem Zeitpunkt nur einen NN geben
LösungStandby NN verhindert, dass anderer NN Änderungen am gemeinsamen Speicher machtNur ein NN darf active seinJeder Node kann anderem den Zugriff entziehen (aber sich nicht selbst wieder erlauben)
sshfence: Kill des Active NN durch SSH Befehlshell: Beliebiges Shell Script (STONITH: Shoot The Other Node In The Head)
HDFS HA: Fencing
CDM SS 19, Dr. Eric Peukert
Zwei NameNodes: A und B -> beide mit assoziierten ZKFCZKFC-A process crash -> znode auf Zookeeper entferntNameNode A process läuft weiterZKFC B erfährt das znode entfernt wurdeZKFC B möchte NameNode B zu Active machen
ohne Fencing wären beide NameNodes gleichzeitig aktiv!
Fencing Beispiel Split-Brain
Quelle: [HDFSHA]
CDM SS 19, Dr. Eric Peukert
Hochwertiges NASAuf Rechnern beider NNs ist ein bestimmtes Verzeichnis auf einem Dateiserver gemounted (Lese- und Schreibzugriff für die NN-Prozesse)Hochverfügbarkeit
Mehrere NetzwerkanbindungenRedundante StromversorgungMehrere Platten / RAID
HDFS HA: NFS
Quelle: [HDFSHA]
DataNode 1
NameNode
HB
NameNode
NFS MountCP J
Active Standby
BR HBBR
W R
DataNode 0 DataNode 2
CDM SS 19, Dr. Eric Peukert
Nachteile NAS-VarianteTeure SpezialhardwareKomplexe Administration (Redundante Netzwerkverbindungen, Mount-Optionen, …)NAS ist noch immer SPOF
Design-Ziele Quorum-basedVerteilter replizierter Speicher (≠HDFS) für edits logAusfall/Nichtverfügbarkeit mehrerer Knoten tolerabel, solange die Mehrheit der Knoten erreichbar ist
“Anzahl der tolerierbaren Fehler konfigurierbar”Verwenden der im Hadoop-Cluster verfügbaren Ressourcen
HDFS HA: NFS Nachteile
CDM SS 19, Dr. Eric Peukert
Jeder NN kommuniziert mit einer Gruppe von JournalNodes (JNs)
Ungerade Anzahl von n JNs auf n Cluster-KnotenÄnderungen am edits log werden durch Active NNsynchron zur Mehrheit der JNs geloggtStandby NN überwacht JNs kontinuierlichIm Falle eines Failovers liest Standby NN alle“ausstehenden” Änderungen von den Journal Nodesbevor er zum Active NN wird
HDFS HA: Quorum-based
[Quelle: HDFSHA]
CDM SS 19, Dr. Eric Peukert
Implizites Fencing - JNs erlauben zu einem Zeitpunkt nur einem NN Schreibzugriff
Vermeidet split brain (NN darf sich nicht selbst active setzen)Jeder Quorum JournalManager hat eine eindeutige epoch number, (tot. Ordnung)Jede Schreiboperation an JN trägt epoch numberJeder JN speichert die größte zuletzt gesehene epoch numberSchreibanforderungen von NNs mit kleinerer epoch number werden ignoriertWenn NameNode zum Active NN wird generiert er mit Zustimmung der Mehrheit der JNs eine neue epoch number ® implizites Fencing
Explizites Fencing zur Vermeidung der Beantwortung von Leseanfragen durchvorherigen Active NN
HDFS HA: Quorum-based(2)
[Quelle: HDFSHA]
CDM SS 19, Dr. Eric Peukert
Verteilte, fehlertolerante DateisystemeSpeicherschicht des Hadoop EcosystemsFür Streaming großer DateienFehlertoleranz durch Block-ReplikationBlock Placement Policy und Balancierung
HDFS2High Availability zur Vermeidung /Reduzierung von AusfallzeitenFederation zur Vermeidung von NS Skalierbarkeitsproblemen
HDFS Zusammenfassung
CDM SS 19, Dr. Eric Peukert
Auf GFS/HDFS abgestimmte Programmiermodelle (z.B. MapReduce)
“Moving Computation is Cheaper than Moving Data” Ziel: Berechnung auf gleichem (oder nahem) Knoten wie Daten
GFS/HDFS: Zusammenfassung
Eigenschaft Technologie / IdeeWie werden Metadaten im HDFS verwaltet
Warum 64 oder 128 Blockgröße?
Wie werden Instanzdaten im HDFS verwaltet
Wie wird Verfügbarkeit sichergestellt?
Lese-OperationWer liest von wo?
Schreib-Operation
CDM SS 19, Dr. Eric Peukert
GFS/HDFS: Zusammenfassung
Eigenschaft Technologie / IdeeWie werden Metadaten im HDFS verwaltet
zentraler Master/Namenode Speicher Namespace + INodes
Warum 64 oder 128 Blockgröße?
kontinuierliches Lesen von der Festplatte großer Blöckegrosse Chunk/Blocksize (64MB) reduziert #Chunks/Blöcke (=Größe Metadaten) + Interaktion mit Master
Wie werden Instanzdaten im HDFS verwaltet
verteilte Datenknoten (commodity hardware, scale out)
Wie wird Verfügbarkeit sichergestellt?
Replikation n=3, HDFS HA
Lese-OperationWer liest von wo?
Client liest Daten direkt von ChunkServer/Datanode
Schreib-Operation Write once, read many; concurrent writes (offsets), nur append
CDM SS 19, Dr. Eric Peukert
[GGL03] Ghemawat, Gobioff, and Leung: The Google File System. Symposium on Operating Systems Principles, 2003[W12] White, Tom. Hadoop: The Definitive Guide. 3rd Edition. O‘Reilly. 2012.[S10] Shvachko et al. The Hadoop Distributed File System. MSST. 2010.http://hadoop.apache.org
[HDFS] http://hadoop.apache.org/hdfs/
[HDFSHA]: http://de.slideshare.net/cloudera/ha-phase-2-with-atm-updates[Federation]: http://de.slideshare.net/AdamKawa/apache-hadoop-yarn-namenode-ha-hdfs-federation
Quellen und Literatur
Top Related