Slave-Knoten im Hadoop Distributed File System (DFS) - Dummies

In einem Hadoop-Cluster führt jeder Datenknoten (auch als Slave-Knoten bezeichnet) ein Hintergrundprozess namens DataNode. Dieser Hintergrundprozess (auch bekannt als Daemon ) verfolgt die Datensegmente, die das System auf seinem Computer speichert. Er kommuniziert regelmäßig mit dem Masterserver für HDFS (bekannt als NameNode), um über die Integrität und den Status der lokal gespeicherten Daten zu berichten.

Datenblöcke werden als Rohdateien im lokalen Dateisystem gespeichert. Aus der Sicht eines Hadoop-Benutzers haben Sie keine Ahnung, welcher der Slave-Knoten die Teile der Datei enthält, die Sie verarbeiten müssen. In Hadoop sehen Sie keine Datenblöcke oder wie sie über den Cluster verteilt sind - Sie sehen nur eine Auflistung von Dateien in HDFS.

Die Komplexität der Verteilung der Dateiblöcke im Cluster ist vor Ihnen verborgen - Sie wissen nicht, wie kompliziert das alles ist, und Sie benötigen nicht , um kennt. Tatsächlich wissen die Slave-Knoten selbst nicht einmal, was sich in den Datenblöcken befindet, die sie speichern. Der NameNode-Server kennt die Zuordnungen, aus welchen Datenblöcken die in HDFS gespeicherten Dateien bestehen.

Besser leben durch Redundanz

Ein zentrales Konstruktionsprinzip von HDFS ist das Konzept der Minimierung der Kosten der einzelnen Slave-Knoten durch Verwendung von Standard-Hardware-Komponenten. Bei massiv skalierbaren Systemen ist diese Idee sinnvoll, da die Kosten schnell ansteigen, wenn Sie Hunderte oder Tausende von Slave-Knoten benötigen. Die Verwendung von kostengünstigerer Hardware hat jedoch zur Folge, dass einzelne Komponenten nicht so zuverlässig sind wie teurere Hardware.

Berücksichtigen Sie bei der Auswahl von Speicheroptionen die Auswirkungen von Standardlaufwerken anstelle von teureren Laufwerken in Enterprise-Qualität. Stellen Sie sich vor, Sie haben einen 750-Knoten-Cluster, in dem jeder Knoten über 12 Festplatten für HDFS-Speicher verfügt.

Basierend auf einer jährlichen Ausfallrate (AFR) von 4 Prozent für Commodity-Festplattenlaufwerke (eine gegebene Festplatte hat eine Wahrscheinlichkeit von 4 Prozent, in einem bestimmten Jahr zu versagen) wird Ihr Cluster wahrscheinlich eine Festplatte erfahren. Ausfall jeden Tag des Jahres.

Da es so viele Slave-Knoten geben kann, ist ihr Ausfall auch in größeren Clustern mit Hunderten oder mehr Knoten üblich. Mit dieser Information im Hinterkopf wurde HDFS unter der Annahme entwickelt, dass alle Hardwarekomponenten selbst auf der Slave-Knotenebene unzuverlässig sind.

HDFS überwindet die Unzuverlässigkeit einzelner Hardware-Komponenten durch Redundanz: Das ist die Idee hinter diesen drei Kopien jeder Datei, die in HDFS gespeichert ist und im gesamten System verteilt ist.Genauer gesagt hat jeder in HDFS gespeicherte Dateiblock insgesamt drei Replikate. Wenn ein System mit einem bestimmten Dateiblock bricht, den Sie benötigen, können Sie sich den anderen beiden zuwenden.

Entwurf des Slave-Knotenservers entwerfen

Um so wichtige Faktoren wie Gesamtbetriebskosten, Speicherkapazität und Leistung auszugleichen, müssen Sie den Entwurf Ihrer Slave-Knoten sorgfältig planen.

Normalerweise sehen Sie jetzt Slave-Knoten, bei denen jeder Knoten normalerweise zwischen 12 und 16 lokal angeschlossene 3-TB-Festplattenlaufwerke hat. Slave-Knoten verwenden mäßig schnelle Dual-Socket-CPUs mit jeweils sechs bis acht Kernen - also keine Geschwindigkeits-Dämonen. Dies wird von 48 GB RAM begleitet. Kurz gesagt, dieser Server ist für einen dichten Speicher optimiert.

Da es sich bei HDFS um ein Dateisystem auf Benutzerebene handelt, ist es wichtig, das lokale Dateisystem auf den Slave-Knoten für die Arbeit mit HDFS zu optimieren. Eine wichtige Entscheidung beim Einrichten Ihrer Server ist in diesem Zusammenhang die Auswahl eines Dateisystems für die Linux-Installation auf den Slave-Knoten.

Ext3 ist das am häufigsten verwendete Dateisystem, da es seit einigen Jahren die stabilste Option ist. Werfen Sie einen Blick auf Ext4. Es ist die nächste Version von Ext3, und sie ist lange genug verfügbar, um als stabil und zuverlässig angesehen zu werden.

Noch wichtiger für unsere Zwecke ist, dass es eine Reihe von Optimierungen für die Handhabung großer Dateien bietet, was es zu einer idealen Wahl für HDFS-Slave-Knotenserver macht.

Verwenden Sie nicht den Linux Logical Volume Manager (LVM) - es stellt eine zusätzliche Schicht zwischen dem Linux-Dateisystem und HDFS dar, wodurch verhindert wird, dass Hadoop seine Leistung optimiert. Insbesondere aggregiert LVM Festplatten, was die Ressourcenverwaltung, die HDFS und YARN ausführen, behindert, je nachdem, wie Dateien auf den physischen Laufwerken verteilt sind.