Suchen

HA-HDFS in Hadoop 2.2.x und: Yahoo testet YARN Hadoop sorgt nun auch für die Hochverfügbarkeit von Big Data

Autor / Redakteur: Filipe Pereira Martins und Anna Kobylinska / Ulrike Ostler

Mit „HA-HDFS“ adressiert in der zweiten, gründlich überarbeiteten Generation des quelloffenen Frameworks „Hadoop“ das Bedürfnis nach Hochverfügbarkeit (HA) verteilter Datenbestände. Wie macht sich das bei Yahoo und 465 Petabyte an Daten bemerkbar?

Firmen zum Thema

Mithilfe von HDFS und YARN ertstrahlt Hadoop in Hochverfügbarkeit.
Mithilfe von HDFS und YARN ertstrahlt Hadoop in Hochverfügbarkeit.
(Bild: © Mike Kiev - Fotolia)

Hadoop, ein quelloffenes Framework der Apache Software Foundation für die verteilte Verarbeitung unstrukturierter Daten, macht wieder von sich reden. Ein umfassendes Redesign der Software-Architektur und eine HA-fähige Implementierung des Dateisystems HDFS haben die Karten neu aufgemischt.

Jürgen Urbanski, der ehemalige Vize-Präsident von IT-Architekturen und neuen Technologien bei T-Systems, einem Tochterunternehmen der Deutschen Telekom, und jetzt Mitglied des Bitkom, sagt dazu: „Der Einsatz einer Hadoop-Lösung (...) erlaubt es Unternehmen jeder Größe, schnell eine kostengünstige Landezone für alle ihre Daten aufzusetzen, welche automatisch mit den wachsenden Daten hoch skaliert“.

Big Data überflutet Datensilos

Für viele interessierte Anwender konnte ein Redesign der Hadoop-Architektur nicht schnell genug kommen. Denn: Viele Unternehmen haben ein Daten-Managementproblem. Wer aus der Datengrube verteilter, isolierter Datensilos umsetzbare Erkenntnisse gewinnen möchte, muss seinen Anwendungen zur Datenanalyse ein verteiltes Cluster-Dateisystem zur Seite stellen, welches mit den wachsenden Anforderungen Schritt hält.

Hadoop mit HDFS sollte eben dieses Bedürfnis erfüllen, nur galt das Duo bisher als zu kompliziert und kaum zu zähmen. Zahlreiche kommerzielle Mitbewerber wollen die Schwächen von Hadoop und HDFS ausgleichen. So zum Beisipel MapR, eine kommerzielle Distribution von Hadoop, koppelt das Framework an ein eigenes proprietäres Dateisystem.

Einen anderen Ansatz als MapR befolgt GridGain, eine Java-Plattform für Grid-Computing. GridGrain bietet unter anderem In-Memory HDFS. Mit HA-HDFS in Hadoop 2.x kann nun die Apache Software Foundation selbst einige relevante Unzulänglichkeiten der ersten Generation des verteilten Dateisystems beseitigen.

Die Architektur von Hadoop 2x

Die Modularisierung der Hadoop-Engine in der 2. Generation des Frameworks hat weitreichende Implikationen für die Zukunft der Plattform. Sie soll es Entwicklern ermöglichen, das Hadoop-Ökosystem um nützliche Plug-ins zu erweitern.

Als optionalen Ersatz für „MapReduce“ wurde „YARN“ (Yet Another Resource Negotiator) aka MapReduce Version 2 (kurz: MRv2) eingeführt. YARN setzt direkt auf HDFS auf und übernimmt die Rolle eines verteilten Betriebssystems zur Ressourcenverwaltung für Big Data-Applikationen. Dank YARN können Anwender mit Hadoop 2.2.x interaktive Workloads, Echtzeit-Workloads und automatisierte Workloads ineinander verweben.

YARN ist rückwärtskompatibel zu MapReduce auf der API-Ebene (hadoop-0.20.205) und verbessert die Kompatibilität von Hadoop mit anderen Projekten der Apache Software Foundation. Das „alte“ MapReduce lässt sich jetzt als ein Modul laden. Das sollte allerdings nicht nötig sein, denn MapReduce-Applikationen sind binärkompatibel zwischen beiden Generationen von Hadoop. (siehe auch: Vergleich der Hadoop-Distributionen von MapR Technologies)

Namen und Daten in getrennten Nodes

HDFS sieht zwei obligatorische Typen von Servern, sogenannte Cluster-Knoten (Clusternodes), vor: Namensknoten (NameNodes) und Datenknoten (DataNodes). Die Namensknoten verwalten die Medataden des Clusters; die Datenknoten zeichnen für die Aufbewahrung der Daten verantwortlich.

Jede Datei und jedes Verzeichnis haben jeweils eine Entsprechung auf dem zugehörigen Namensknoten in Form von „inodes“; diese speichern Attribute der betreffenden Objekte wie die Zugriffsrechte, das Erstellungs- und Änderungsdatum und Speicherkontingente. Die eigentlichen Daten werden in Datenblöcke aufgeteilt und über mehrere Datenknoten repliziert gesichert.

Über die Anzahl und Konsistenz der Kopien wacht der zugehörige Namensknoten. Sollte eine Kopie beschädigt werden, veranlasst der Namensknoten die Erstellung einer Replikation.

Der Hadoop 2.x-Stack mit Apache TEZ: Er ergibt sich eine Performance-Steigerung dank der Datenverarbeitung im Arbeitsspeicher des Cluster.
Der Hadoop 2.x-Stack mit Apache TEZ: Er ergibt sich eine Performance-Steigerung dank der Datenverarbeitung im Arbeitsspeicher des Cluster.
(Bild: McKinley Denali Inc.)

Für jeden Knoten des Clusters (also eine einzelne Maschine) zeichnet sein eigener Node-Manager verantwortlich. Dieser überwacht die Verwendung der Ressourcen der Container und berichtet an den Resource-Manager/Scheduler, was auf dem jeweiligen Knoten gerade vor sich hin geht.

Die neue Architektur ermöglicht erhebliche Kosteneinsparungen. Yahoo schätzt die erzielten Verbesserungen der Node-Auslastung auf 60 bis 150 Prozent pro Tag. Yahoo testete YARN mit 365 Petabyte an Daten und 400.000 Jobs auf über 40.000 Cluster-Nodes mit einer Gesamtrechenzeit von 10 Millionen Stunden. Eine Hochverfügbarkeitsimplementierung des YARN ResourceManager ist allerdings für eine künftige Version geplant.

HA mit HDFS2 radiert Single Point of Failure aus

In Hadoop 2.x debütiert die erste Hochverfügbarkeitsimplementierung des eigenen Cluster-Dateisystems HDFS (Hadoop Distributed File System). Die HDFS-Implementierung in Hadoop v1 hatte einen klaren Single Point of Failure: den Namensknoten.

Ein Namensknoten, die Schaltzentrale zum Verwalten von Zugriffen auf Daten mithilfe von Metadaten, erledigt diese Aufgabe im Arbeitsspeicher (nur einige Metadaten werden im Dateisystem gesichert). Beim Ausfall eines aktiven Namensknoten ging der Inhalt seines Arbeitsspeichers verloren; der Administrator musste den Schaden zudem manuell reparieren (kein automatisches Failover).

Die Schwachstelle

So konnte der Ausfall eines Namensknoten das ganze HDFS zum Erliegen bringen; aktuell laufende Schreibprozesse sowie Jobs in der Warteschlange wurden mit einer Fehlermeldung abgebrochen.

Die Implementierung geschäftskritischer Workloads, die interaktiv in Echtzeit ablaufen müssen, gestaltete sich dadurch sehr problematisch. Für Hadoop 2.x haben sich die Entwickler eine Lösung einfallen lassen: Hochverfügbarkeits-Namensknoten (HA-Namensknoten).

Die HA-Namensknoten

Die HA-Konfiguration von HDFS sieht jeweils zwei redundant angelegte Namensknoten in einer Aktiv-Passiv-Node-Architektur mit einem „warmen“ Namensknoten im Standby-Modus vor. Der passive HA-Namensknoten wartet auf der sprichwörtlichen Reservebank („Standby“), beobachtet den aktiven Namensknoten und lauscht dem Herzschlag seiner Datenknoten.

Die Funktionsweise von HA-HDFS unter Verwendung von einem Journal-Quorum
Die Funktionsweise von HA-HDFS unter Verwendung von einem Journal-Quorum
(Bild: McKinley Denali Inc.)

Das Abgleichen der Metadaten zwischen den beiden HA-Namensknoten erfolgt entweder über gemeinsam genutzten NFS-Speicher oder via HDFS-Quorum der so genannten JournalNodes. Sollte der aktive Namensknoten ausfallen, kann der Administrator manuelles Failover wie folgt auslösen:

hdfs haadmin failover <der-neue-Standby-NN> <der-neue-aktive-NN>

Automatisches Failover bedarf zusätzlicher Software, zum Beispiel „Apache Zookeeper“ mit dem „ZKFailoverController“.

Federation in HDFS2

Die horizontale Skalierung des Namensdienstes in Hadoop 2.2.x erfolgt durch die Partitionierung des Namensraums über mehrere unabhängige Namensknoten, die sogenannte Federation. Alle Namensknoten greifen unabhängig voneinander auf eine gemeinsame Sammlung von Datenknoten.

Da tanzt der Haddoop-Elefant - das HDFS-Logo
Da tanzt der Haddoop-Elefant - das HDFS-Logo
(Bild: Apache.org)

Jeder dieser Datenknoten registriert sich bei allen Namensknoten des eigenen Cluster; er sendet an sie periodisch ein Herzschlag-Signal sowie Block-Berichte und kann von jedem der Namensknoten Befehle entgegen nehmen. Im Gegensatz dazu „reden“ die Namensknoten überhaupt nicht miteinander; jeder verwaltet nur seinen eigenen Ausschnitt des Namensraums. Beim Hinzufügen oder Entfernen von Namensknoten ist ein Neustart des gesamten Clusters fällig.

HDFS-Snapshots

Snapshots des HDFS-Dateisystems sind ebenfalls eine willkommene Neuerung. Bei HDFS-Snapshots handelt es sich um nicht-beschreibbare Kopien des Dateisystems, die seinen Zustand zu einem definierten Zeitpunkt erfassen (point-in-time copy). Was diesem Feature seinen Reiz verleiht, ist die äußerst gelungene Implementierung.

Ein HDFS-Snapshot entsteht momentan, denn es werden dabei keine DataNodes kopiert. Das Snapshot erfasst lediglich die Liste aller Datenblöcke und die Größe der Dateien. Der Vorgang hat keinen negativen Effekt auf sonstige I/O-Operationen und benötigt in der Regel auch keinen zusätzlichen Arbeitsspeicher (außer wenn das Dateisystem gleichzeitig Schreibzugriffe umsetzt).

Super-User können ...

Änderungen werden in umgekehrter chronologischer Reihenfolge aufgezeichnet, sodass auf die aktuellen Daten direkt zugegriffen werden kann. Der Zustand der Daten für ein Snapshot errechnet HDFS2 durch die Subtraktion betreffender Änderungen von dem aktuellen Zustand des Dateisystems.

Um Snapshots zu erlauben, kommt der folgende Befehl mit Berechtigungen des Super-User zum Einsatz:

hdfs dfsadmin -allowSnapshot <Pfad-zum-snapshotbaren-Verzeichnis>

Der betreffende Verzeichnisbaum lässt sich dann mit den Benutzerrechten des betreffenden Besitzers in einem Snapshot zum Beispiel wie folgt erfassen:

hdfs dfs -createSnapshot <Pfad-zum-snapshotbaren-Verzeichnis> [<snapshotName>]

Alternativ können Admins das Java-API nutzen.

Um den Pfad zu Snapshots zu kennzeichnen, wurde der Objektname .snapshot reserviert. Sollte in dem HDFS-Dateisystem Ihrer bestehenden Hadoop-1.x-Installation diese Zeichenkette vorkommen, müssen sie die betreffenden Objekte vor dem Upgrade unbedingt umbenennen.

Eine angespannte Beziehung

Von Anbietern proprietärer Big-Data-Lösungen wird Hadoop mit HA-HDFS zugleich genutzt und gefürchtet. Mike Olson, der Chief Strategy Officer von Cloudera, macht es ganz klar deutlich, warum Softwarehäuser auf der Basis von proprietären Standards sich besser keine Hoffnungen machen sollten, erfolgreich mit quelloffenen Lösungen zu konkurrieren: „Die wirtschaftlichen Skaleneffekte kostenloser Downloads, einer kostenlosen Installation und kostenlosen Benutzung sind in Kombination mit dem hohen Innovationstempo der Open-Source-Gemeinde durch einen einzelnen (kommerziellen) Anbieter einfach nicht zu schlagen.“

Die größte Herausforderung beim Einsatz von Hadoop mit HA-HDFS ist nicht ein dickes Finanzpolster, sondern das (noch) fehlende Know-how. Die Lösung laut Urbanski: klein anfangen.

Im ersten Schritt gilt es, sich die günstige Datenverarbeitung und robuste Datensicherung mit HDFS zunutze zu machen. Nachdem man damit begonnen habe, die Früchte dieser Kostensenkungen zu ernten, könne man dann die Datenanalyse ausbauen. Erst in dieser Phase würde es Sinn machen, Datenwissenschaftler zu beschäftigen, damit sie mithilfe von Datenanalyselösungen auf der Basis von Hadoop anspruchsvolleren Fragen nachgingen.

Die Autoren:

Filipe Martins und Anna Kobylinska sind von der McKinley Denali Inc. (USA). Sie ziehen folgendes Fazit: „In der zweiten Generation von Hadoop wurde HDFS ziemlich ,aufgebohrt'. Die aktuelle Hochverfügbarkeitsimplementierung mischt die Karten ganz schön neu auf.“

(ID:42544712)