1. Hadoop aus IT-Operations Sicht – Teil 2
Hardware- und Netzwerk-Grundlagen
Vesperbox am Freitag, den 09.08.2013
Daniel Bäurer
inovex GmbH
Systems Engineer
Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und uns selbst.

2. Inhalt
●
●
15.10.13
Auswahl und Konfiguration der Hardware
Auswahl und Konfiguration der Netzwerktopologie

3. Auswahl und Konfiguration der Hardware
Snappy
MapR
Hortonworks
Sqoop
Zookeeper
HDFS
Whirr
NameNode
DataNode
HADOOP
Mahout
Chukwa
Hive
MapReduce
Oozie
HCatalog
TaskTracker
JobTracker
Pig
Cloudera
15.10.13
Flume
Hue
HBase

4. Auswahl und Konfiguration der Hardware
●
●
Hadoop ist für den Betrieb mit Standard-Hardware („commodity
hardware“) ausgelegt.
Hadoop stellt über Software sicher, dass
●
●
●
●
15.10.13
große Datenvolumen zuverlässig verwaltet werden.
Daten über mehrere Knoten zuverlässig verteilt und repliziert
werden.
Hadoop verteilt Daten auf Knoten die Rechenoperationen
ausführen.
Hadoop führt Rechenoperationen auf den Knoten aus auf
denen die Daten liegen.

5. Auswahl und Konfiguration der Hardware – Kriterien
●
Hardware für Hadoop kann in zwei Kategorien unterteilt werden:
●
●
●
●
15.10.13
Master-Hardware
NameNode)
Slave, oder
TaskTracker)
(NameNode,
auch
Worker,
JobTracker,
-Hardware
Secondary
(DataNodes,
Master-Hardware darf (soll) nicht Ausfallen (schwerwiegende
Auswirkungen auf den Cluster).
Slave-Hardware kann Ausfallen (keine Auswirkung auf den
Cluster).

6. Auswahl und Konfiguration der Hardware – Kriterien
●
Die von einem Hadoop-Cluster auszuführenden Jobs können
folgende Anforderungen haben:
●
Rechenintensiv („CPU-Bound“)
●
●
●
Lese-/Schreibintensiv
(„I/O-Bound“)
●
●
●
●
15.10.13
Computerlinguistik
Text-Mining
für
Festplatten
und
Netzwerk
Indizieren
Suchen
Ausgewogen
Die Anforderungen können über Teststellungen ermittelt werden.

7. Auswahl und Konfiguration der Hardware
●
Master-Hardware:
●
●
●
●
●
15.10.13
Ausfälle
sind
kritisch,
weswegen
redundante
Hardware-Komponenten (Netzteile und Netzwerkkarten)
nötig sind.
Ein aktueller Prozessor (Quad-Core) in zweifacher Ausführung
ist ausreichend.
Für den Arbeitspeicher sollten ECC-Module verwendet werden
und mindestens 24 GB.
Die Betriebssystem-Partitionen sollten auf einem separaten
RAID-Container (RAID-1) liegen.
1 GBit Netzwerk ist ausreichend, sollte aber gebündelt sein
(„active-backup bonding“).

8. Auswahl und Konfiguration der Hardware
●
Besonderheiten der NameNode-Hardware:
●
●
●
●
15.10.13
Der NameNode ist eine der kritischsten Komponenten in
einem Hadoop-Cluster und dementsprechend ist hierfür die
Hardware zu wählen.
Der NameNode hält alle Metadaten im Arbeitsspeicher vor,
und die Größe der Metadaten hängt im wesentlichen von der
Länge der Dateinamen sowie der Anzahl der Dateien ab.
Deswegen muss der Arbeitsspeicher an die Größe des
Clusters angepasst werden. Als grobe Hausnummer kann man
annehmen, dass 1 Mio. Blocks 1 GB RAM konsumieren.
Die Persistierung der Metadaten sollte auf mindestens zwei
separaten Festplatten (JBOD) oder hochverfügbarem
RAID-Container erfolgen (minimale Größe).

9. Auswahl und Konfiguration der Hardware
●
Besonderheiten der JobTracker-Hardware:
●
●
●
15.10.13
Der JobTracker hält den Status und Fortschritt aller Jobs und
Tasks sowie die Historie der letzten n-Jobs im Arbeitsspeicher
vor.
Die hierfür notwendige Größe hängt im wesentlichen von der
Anzahl der möglichen Jobs/Tasks ab und lässt sich nur schwer
berechnen.
Bei kleineren und mittleren Hadoop-Clustern ist der JobTracker
mit auf dem NameNode untergebracht. Entsprechend ist auch
die Hardware ausgelegt.

10. Auswahl und Konfiguration der Hardware
●
Slave-Hardware I:
●
●
●
●
15.10.13
Ausfälle sind nicht kritisch, weswegen nicht zwingend
redundante Hardware-Komponenten nötig sind. Meist
kommt sehr günstige Server-Hardware zum Einsatz.
Allerdings sollte berücksichtigt werden, dass durch die nicht
vorhandene Redundanz höhere Entstörungskosten (auch
abhängig vom Automatisierungsgrad) entstehen können. Diese
sollten gegen die Anschaffungskosten redundanter Hardware
abgewägt werden.
Die Betriebssystem-Partitionen sollten auf einer separaten
Festplatte oder einem RAID-Container (RAID-1) liegen.
Je nach Anforderungsprofil ist ein 1 GBit Netzwerk
ausreichend. Es können gebündelte Netzwerke zum Einsatz
kommen („active-backup bonding“ oder „802.3ad bonding“).

11. Auswahl und Konfiguration der Hardware
●
Slave-Hardware II:
●
Ein wesentlicher Faktor bei der Auswahl des Prozessors,
Arbeitsspeichers und der Anzahl der Festplatten spielt das
Anforderungsprofil:
●
●
●
15.10.13
Rechenintensive
(„CPU-Bound“)
Anforderungen
benötigen stärkere oder mehr Prozessoren und
Arbeitsspeicher sowie weniger Festplatten.
Lese-/Schreibintensive („I/O-Bound“) Anforderungen
benötigen schwächere oder weniger Prozessoren und
Arbeitsspeicher sowie mehr Festplatten.
Ausgeglichene Anforderungen sind sowohl Rechen- als
auch Lese-/Schreibintensiv, bzw. werden daraufhin
ausgelegt.

12. Auswahl und Konfiguration der Hardware
Dimensionen von „CPU-Bound“ und „I/O-Bound“ Anforderungen
Loddengaard, Alex: Cloudera’s Support Team Shares Some Basic Hardware Recommendations, März 2010, Clouderas Blog
15.10.13

13. Auswahl und Konfiguration der Hardware
●
Slave-Hardware III:
●
●
●
●
15.10.13
Die Größe des Arbeitsspeichers ist abhängig von der Anzahl
der parallelen Tasks die ein Knoten ausführt.
Die Anzahl der Tasks die ein Knoten ausführt ist wiederum
Abhängig von der Anzahl der CPUs (Cores) pro Knoten.
Ein grober Richtwert ist, dass pro CPU-Core ca. 2-4 GB an
Arbeitsspeicher erforderlich ist.
Ebenfalls sollten ECC-Speichermodule verwendet werden.

14. Auswahl und Konfiguration der Hardware
●
Slave-Hardware IV:
●
Bei der Wahl der Festplatten ist folgendes zu Beachten:
●
●
●
●
●
15.10.13
In Frage kommen meist nur SATA- oder SAS-Festplatten
mit maximal 7.200 U/Min.
Bei der Datendichte wird man aktuell auf 2-3 TB Platten
zurückgreifen.
Generell sollte man auf ein ausgeglichenes Verhältnis
zwischen Kosten und Leistung achten.
Bei der Wahl des Festplatten-Controller sollte darauf
geachtet werden, dass dieser JBOD unterstützen.
Bei vielen Festplatten pro Knoten können auch zwei Controller
verbaut werden um die I/O-Last auf die CPUs zu verteilen.

15. Auswahl und Konfiguration der Hardware
●
Slave-Hardware V:
●
●
Sämtliche Festplatten die für das HDFS auf den DataNodes
bestimmt sind, müssen als JBOD verwendet werden.
Warum nicht als RAID-Container?
●
●
●
●
15.10.13
Ein RAID-Container tritt als ein Gerät (eine Festplatte) auf.
Wenn nun mehrere Tasks gleichzeitig sequentielle Blöcke
mit einer Mindestgröße von 64 MB einlesen wollen, so
werden die Leseoperationen aufgeteilt („I/O-Scheduling“).
Durch die Aufteilung der Leseoperationen auf ein Gerät,
werden faktisch wahlfreie („random“) Leseoperationen
erzeugt, was die Leistung erheblich mindert.
Bei JBOD hingegen bleibt auch nach dem Aufteilen der
Leseoperation das sequentielle Lesen erhalten.

16. Auswahl und Konfiguration der Hardware
●
Slave-Hardware VI:
●
Gegen den Einsatz von RAID auf den DataNodes (als
HDFS-Store) spricht weiterhin:
●
●
●
15.10.13
Hadoop ist für die Redundanz und Verteilung der Daten
zuständig.
Jeder DataNode muss nach dem Ausfall einer Festplatte
(=> Replikationsfaktor ist nicht mehr sichergestellt) dies
umgehend dem NameNode melden, so dass der
Replikationsfaktor im Cluster wiederhergestellt werden
kann.
Ebenfalls ungeeignet sind NAS/SAN-Speichersysteme oder
oder virtuelle Maschinen.

17. Auswahl und Konfiguration der Hardware
●
Größe des Clusters:
●
●
●
●
15.10.13
Die Größe eines Hadoop-Clusters kann anhand der zu
speichernden Datenmenge sowie den prognostizierten
Zuwachsraten berechnet werden.
Die sich hieraus ergebende Zahl an erforderlichem Speicher
kann nun auf weniger große, leistungsstarke Knoten verteilt
werden oder aber auf viele kleine, leistungsschwächere
Knoten.
Hierbei ist allerdings zu beachten, dass mehr Knoten
eventuell höhere Investitionskosten erfordert, mehr Strom
verbrauchen, stärker gekühlt werden müssen und die
Netzwerkinfrastruktur entsprechend ausgelegt sein muss.
Die Größe eines Hadoop-Clusters kann auch anhand
bestimmter Jobs erfolgen, die in einer definierten Zeit
erfolgreich durchgeführt werden müssen.

18. Auswahl und Konfiguration der Netzwerktopologie
Snappy
MapR
Hortonworks
Sqoop
Zookeeper
HDFS
Whirr
NameNode
DataNode
HADOOP
Mahout
Chukwa
Hive
MapReduce
Oozie
HCatalog
TaskTracker
JobTracker
Pig
Cloudera
15.10.13
Flume
Hue
HBase

19. Auswahl und Konfiguration der Netzwerktopologie
●
●
Auch im Netzwerkbereich ist Hadoop darauf ausgelegt mit
Standard-Netzwerktechnik und -Protokollen zu arbeiten.
Das Datenaufkommen in einem Hadoop-Cluster besteht aus
HDFS- und MapReduce-Verkehr.
●
HDFS-Verkehr:
●
●
●
●
MapReduce-Verkehr:
●
●
15.10.13
Block-Report und Heartbeat der DataNodes (--)
Metadaten-Anfragen an den NameNode (-)
Block-Transfer und -Verteilung der DataNodes (++)
Heartbeat der TaskTracker (--)
Map-Task-Ergebnisse der TaskTracker (+++)

20. Auswahl und Konfiguration der Netzwerktopologie
●
HDFS-Verkehr:
●
●
●
●
●
15.10.13
Block-Report, Heartbeat und Meatadaten-Anfragen sind eine
zu vernachlässigende Größe im Netzwerk.
Der größte Teil des Netzwerk-Verkehrs wird durch die
Replikation und Reorganisation der Blöcke verursacht.
Hadoop versucht so gut es geht Leseoperationen an den
Orten auszuführen an denen die Blöcke vorgehalten werden.
In allen anderen Fällen müssen die Blöcke übertragen werden.
Hadoop
versucht
ebenfalls
Schreiboperationen
dort
auszuführen an denen die Daten entstehen. Hierdurch wird die
erste Replik auf dem lokalen Knoten geschrieben.
Alle anderen Schreiboperationen werden entsprechend dem
Replikationsfaktor oft über das Netzwerk übertragen.

21. Auswahl und Konfiguration der Netzwerktopologie
●
MapReduce-Verkehr:
●
●
●
15.10.13
Der einzig, dafür aber auch erhebliche, Netzwerk-Verkehr der
durch MapReduce erzeugt wird, sind die Zwischenergebnisse
der Map-Tasks.
Diese werden einerseits
entsprechen repliziert.
im
HDFS
geschrieben
und
Andererseits müssen diese Zwischenergebnisse allen
Reduce-Tasks zur Verfügung stehen und entsprechend über
das Netzwerk übertragen werden.

22. Auswahl und Konfiguration der Netzwerktopologie
Vertikaler-Netzwerkvekehr
Horizontaler-Netzwerkverkehr
Baum-Topologie und Netzwerkverkehr
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 70
15.10.13

23. Auswahl und Konfiguration der Netzwerktopologie
●
Vertikaler-Netzwerkverkehr“ vs. Horizontaler-Netzwerkverkehr:
●
●
●
15.10.13
Klassische
Anwendungen,
beispielsweise
eine
Web-Applikation, verursachen einen Netzwerk-Verkehr der von
außen über Core- und Distribution-Switch an die einzelnen
Server geleitet wird (und wieder zurück). Dies wird als
Vertikaler-Netzwerkverkehr bezeichnet.
Bei Hadoop findet der meiste Netzwerk-Verkehr zwischen
einzelnen Knoten statt. Der Netzwerk-Verkehr wird hierbei
über die Distribution-Switch und meist auch die Core-Switch
und einer weiteren Distribution-Switch geleitet. Dies
bezeichnet man als Horizontaler-Netzwerkverkehr.
Klassische Netzwerktopologie (Baum-Topologie) ist für kleinere
und mittlere Hadoop-Installationen geeignet, stößt bei größeren
Installationen aber an seine Grenzen.

24. Auswahl und Konfiguration der Netzwerktopologie
3-Schichten Baum-Topologie
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 71
15.10.13

25. Auswahl und Konfiguration der Netzwerktopologie
„Spin-Fabric“ Topologie mit zwei Core-Switchen
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 72
15.10.13

26. Auswahl und Konfiguration der Netzwerktopologie
●
●
●
●
●
15.10.13
Für horizontalen Netzwerk-Verkehr besser geeignet als
Baum-Topologien
sind
„Spine-Fabric“
(Rückgrat-Struktur)
Topologien.
Jeder Knoten
Core-Switche.
erreicht
über
seine
Distribution-Switch
alle
Über geeignete Routing-Protokolle (beispielsweise OSPF) stehen
dem Netzwerkverkehr mehrere Optionen offen, um den kürzesten
Pfad zwischen zwei Knoten zu wählen.
Ausfälle einzelner Core-Switche haben einen nur geringen
Einfluss auf die Verfügbarkeit des Hadoop-Clusters.
Auch sind alle Knoten exakt drei Hops voneinander entfernt.

27. Auswahl und Konfiguration der Netzwerktopologie
„Spin-Fabric“ Topologie mit vier Core-Switchen
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 73
15.10.13

28. Auswahl und Konfiguration der Netzwerktopologie
●
●
●
●
15.10.13
Die
Verwendung
von
10GBit-Ethernet-Komponenten kann in
werden, verursacht aber sehr hohe Kosten.
durchgängig
Betracht gezogen
10GBit-Ethernet
wird
meist
nur
auf
der
Distribution-Switch/Core-Switch Verwendung finden.
Ebene
Um Ausfälle von einzelnen (Slave-)Knoten vorzubeugen oder die
Bandbreite zu erhöhen, können auch zwei Distribution-Switche
pro Knoten verwendet werden.
Ein „Überbuchen“ der Switche ist im Faktor 2:1 in Ordnung. Alle
Werte die darüber hinaus gehen sollten vermieden werden.

29. Vielen Dank für Ihre Aufmerksamkeit!
inovex GmbH
Pforzheim
Karlsruher Straße 71
D-75179 Pforzheim
15.10.13
München
Valentin-Linhof-Straße 2
D-81829 München
Köln
Schanzenstraße 6-20
D-51063 Köln