Cloud Data Management - uni-leipzig.deTeil2).pdf · HDFS Cluster Topologie NameNode DataNode1 DataNode2 DataNode3 Rack 1 DataNode5 DataNode6 DataNode7 Rack 2 DataNode4 Rack Switch

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/


Read & WriteBlock Replication ManagementHDFS FederationHDFS High Availability (HA)

Titelzeile alle Folien3


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


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


HDFS Cluster Topologie

NameNodeDataNode 1DataNode 2DataNode 3

Rack 1

DataNode 5DataNode 6DataNode 7

Rack 2

DataNode 4

Rack Switch Rack Switch


Rack 4

DataNode 5

Rack Switch

NW Switch NW Switch

/


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


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


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


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


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]


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/


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]


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


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


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


HDFS HA: Grundidee (2)

Titelzeile alle Folien17

DataNode 0

A

B

NameNode

HB

I

NameNode

NFS MountCP J

Active Standby

BR HBBR

W R


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


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]


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


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]


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


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


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]


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]


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


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


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


[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

http://hadoop.apache.org/hdfs/

http://de.slideshare.net/cloudera/ha-phase-2-with-atm-updates

http://de.slideshare.net/AdamKawa/apache-hadoop-yarn-namenode-ha-hdfs-federation

Documents

Cloud Data Management - uni-leipzig.deTeil2).pdf · HDFS Cluster Topologie NameNode DataNode1 DataNode2 DataNode3 Rack 1 DataNode5 DataNode6 DataNode7 Rack 2 DataNode4 Rack Switch