Zum Jahresende dreht sich im IT-Administrator alles rund um das Thema 'Client- und Applikations-Virtualisierung'. So lesen Sie in der Dezember-Ausgabe, welche ... (mehr)

HA-HDFS in Hadoop 2.2.x

Das Hadoop Distributed File System (HDFS) [5] ist ein verteiltes Dateisystem der Apache Software Foundation für Hadoop. Die aktuelle Version stellt einen großen Fortschritt gegenüber ihrem Vorgänger dar. Die HDFS-Implementierung in Hadoop v1.x hatte nämlich einen eingebauten Single-Point-of-Failure: den Namensknoten. Er verwaltete die Zugriffe auf Daten mit Hilfe von Metadaten und erledigte diese Aufgabe aus Performancegründen primär im Arbeitsspeicher, nur einige Metadaten wurden im Dateisystem gesichert. Beim Ausfall eines aktiven Namensknotens ging also der Inhalt seines Arbeitsspeichers verloren; der Administrator musste den Schaden manuell reparieren, denn es gab kein automatisches Failover. So konnte der Ausfall eines Namensknotens das ganze HDFS zum Erliegen bringen; laufende Schreibprozesse sowie Jobs in der Warteschlange wurden dann mit einer Fehlermeldung abgebrochen. In Hadoop 2.x wurde das Problem mit dem Hochverfügbarkeits-Namensknoten (HA-Namensknoten) behoben.

Bild 3: Die Funktionsweise von FedFS mit NFSv4-Verweisen (Referrals) am Beispiel von RHEL 7.

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, beo-bachtet den aktiven Namensknoten und lauscht dem Herzschlag seiner Datenknoten. Das Abgleichen der Metadaten zwischen beiden HA-Namensknoten erfolgt entweder über gemeinsam genutzten NFS-Speicher oder via HDFS-Quorum der JournalNodes. Sollte der aktive Namensknoten ausfallen, können Sie ein manuelles Failover wie folgt auslösen:

hdfs haadmin failover Neuer-Standby-NN Neuer-aktiver-NN

Ein automatisches Failover bedarf zusätzlicher Software wie etwa Apache Zookeeper mit ZKFailoverController. Die horizontale Skalierung des Namensdienstes in Hadoop 2.2.x erfolgt durch die Partitionierung des Namensraums über mehrere unabhängige Namensknoten, die sogenannte Föderation.

Alle Namensknoten greifen unabhängig voneinander auf eine gemeinsame Sammlung von Datenknoten zu. Jeder dieser Datenknoten registriert sich bei allen Namensknoten des eigenen Clusters; er sendet an sie periodisch ein Herzschlag-Signal sowie Block-Berichte und kann von jedem der Namensknoten Befehle entgegennehmen. 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 Cluster-Neustart fällig.

Snapshots des HDFS-Dateisystems sind ebenfalls eine willkommene Neuerung in Hadoop 2. Bei HDFS-Snapshots handelt es sich um nicht-beschreibbare Kopien des Dateisystems, die seinen Zustand zu einem definierten Zeitpunkt erfassen (point-in-time copy). 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). Änderungen werden in umgekehrter chronologischer Reihenfolge aufgezeichnet, sodass auf die aktuellen Daten direkt zugegriffen werden kann. Den Zustand der Daten für einen 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 Superusers zum Einsatz:

hdfs dfsadmin -allowSnapshot Pfad zum snapshotfähigen Verzeichnis

Den betreffenden Verzeichnisbaum erfassen Sie dann mit den Benutzerrechten des betreffenden Besitzers in einem Snapshot zum Beispiel wie folgt:

hdfs dfs -createSnapshot Pfad zum snapshotfähigen Verzeichnis [Snapshotname]

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

 

Lustre

Bei Lustre handelt es sich um ein paralleles, verteiltes Dateisystem, das sich einen festen Platz unter den weltweiten Top-100-Supercomputern erobern konnte und auch im Unternehmensumfeld auf eine treue Benutzergemeinde verweisen kann.

Lustre erblickte 1999 das Licht der Welt an der Carnegie Mellon Universität. Im September 2007 bekam es mit Sun Microsystems einen neuen Besitzer und sollte in das ZFS-Dateisystem einfließen. Mit der Übernahme von Sun Microsystems durch Oracle kam die Lustre-Entwicklung vorübergehend zum Stillstand und wurde im Dezember 2010 offiziell eingestellt. Als Reaktion darauf sind die Entwickler von Oracle zu Xyratex abgewandert und im Februar 2013 gingen auch alle Rechte an Lustre von Oracle an Xyratex über. Am 8. April 2014 gab schließlich Xyratex (eine Tochter von Seagate) alle Rechte an Lustre und lustre.org an die Open Source-Gemeinde ab.

Zu den bemerkenswerten Features der aktuellen Version 2.6 zählt die horizontale Skalierbarkeit der Metadaten-Performance durch die Parallelisierung der Metadaten-Verarbeitung auf mehreren Knoten des Clusters, eine einfache Integration mit ZFS und ein Lustre-spezifisches Werkzeug namens LFSCK zum Überprüfen der Dateisystemkonsistenz (verfügbar seit der Version 2.4 und in 2.6 deutlich verbessert). Die für Februar 2015 geplante Version 2.7 soll den Anwendern unter anderem asynchron verteilte Updates bescheren.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023