Hadoop aus IT-Operations-Sicht - Teil 2 (Hardware- und Netzwerkgrundlagen)

Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und uns selbst.

Hadoop aus IT-Operations Sicht – Teil 2

Hardware- und Netzwerk-Grundlagen

Vesperbox am Freitag, den 09.08.2013

Daniel Bäurer

inovex GmbHSystems Engineer

15.10.13

Inhalt

● Auswahl und Konfiguration der Hardware

● Auswahl und Konfiguration der Netzwerktopologie

15.10.13

Auswahl und Konfiguration der Hardware

HADOOP

HDFS

MapReduce

Flume

Sqoop

HCatalog

Hue

Hive

Pig

HBase

Zookeeper

Oozie

Whirr

Snappy

Mahout

Chukwa

Cloudera

HortonworksMapR

NameNode DataNode

JobTrackerTaskTracker

15.10.13


● Hadoop ist für den Betrieb mit Standard-Hardware („commodity hardware“) ausgelegt.

● Hadoop stellt über Software sicher, dass

● 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.

15.10.13

Auswahl und Konfiguration der Hardware – Kriterien

● Hardware für Hadoop kann in zwei Kategorien unterteilt werden:

● Master-Hardware (NameNode, JobTracker, Secondary NameNode)

● Slave, oder auch Worker, -Hardware (DataNodes, TaskTracker)

● Master-Hardware darf (soll) nicht Ausfallen (schwerwiegende Auswirkungen auf den Cluster).

● Slave-Hardware kann Ausfallen (keine Auswirkung auf den Cluster).

15.10.13

Auswahl und Konfiguration der Hardware – Kriterien

● Die von einem Hadoop-Cluster auszuführenden Jobs können folgende Anforderungen haben:

● Rechenintensiv („CPU-Bound“)

● Computerlinguistik● Text-Mining

● Lese-/Schreibintensiv für Festplatten und Netzwerk („I/O-Bound“)

● Indizieren● Suchen

● Ausgewogen

● Die Anforderungen können über Teststellungen ermittelt werden.

15.10.13


● Master-Hardware:

● 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“).

15.10.13


● Besonderheiten der NameNode-Hardware:

● 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).

15.10.13


● Besonderheiten der JobTracker-Hardware:

● 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.

15.10.13


● Slave-Hardware I:

● 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“).

15.10.13


● Slave-Hardware II:

● Ein wesentlicher Faktor bei der Auswahl des Prozessors, Arbeitsspeichers und der Anzahl der Festplatten spielt das Anforderungsprofil:

● 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.

15.10.13


Loddengaard, Alex: Cloudera’s Support Team Shares Some Basic Hardware Recommendations, März 2010, Clouderas Blog

Dimensionen von „CPU-Bound“ und „I/O-Bound“ Anforderungen

15.10.13


● Slave-Hardware III:

● 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.

15.10.13


● Slave-Hardware IV:

● Bei der Wahl der Festplatten ist folgendes zu Beachten:

● 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.10.13


● 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?

● 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.

15.10.13


● Slave-Hardware VI:

● Gegen den Einsatz von RAID auf den DataNodes (als HDFS-Store) spricht weiterhin:

● 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.

15.10.13


● Größe des Clusters:

● 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.

15.10.13

Auswahl und Konfiguration der Netzwerktopologie

HADOOP

HDFS

MapReduce

Flume

Sqoop

HCatalog

Hue

Hive

Pig

HBase

Zookeeper

Oozie

Whirr

Snappy

Mahout

Chukwa

Cloudera

HortonworksMapR

NameNode DataNode

JobTrackerTaskTracker

15.10.13


● 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:

● Block-Report und Heartbeat der DataNodes (--)● Metadaten-Anfragen an den NameNode (-)● Block-Transfer und -Verteilung der DataNodes (++)

● MapReduce-Verkehr:

● Heartbeat der TaskTracker (--)● Map-Task-Ergebnisse der TaskTracker (+++)

15.10.13


● HDFS-Verkehr:

● 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.

15.10.13


● MapReduce-Verkehr:

● Der einzig, dafür aber auch erhebliche, Netzwerk-Verkehr der durch MapReduce erzeugt wird, sind die Zwischenergebnisse der Map-Tasks.

● Diese werden einerseits im HDFS geschrieben und entsprechen repliziert.

● Andererseits müssen diese Zwischenergebnisse allen Reduce-Tasks zur Verfügung stehen und entsprechend über das Netzwerk übertragen werden.

15.10.13


Horizontaler-Netzwerkverkehr

Vertikaler-Netzwerkvekehr

Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 70

Baum-Topologie und Netzwerkverkehr

15.10.13


● Vertikaler-Netzwerkverkehr“ vs. Horizontaler-Netzwerkverkehr:

● 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.

15.10.13



3-Schichten Baum-Topologie

15.10.13



„Spin-Fabric“ Topologie mit zwei Core-Switchen

15.10.13


● Für horizontalen Netzwerk-Verkehr besser geeignet als Baum-Topologien sind „Spine-Fabric“ (Rückgrat-Struktur) Topologien.

● Jeder Knoten erreicht über seine Distribution-Switch alle Core-Switche.

● Ü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.

15.10.13



„Spin-Fabric“ Topologie mit vier Core-Switchen

15.10.13


● Die Verwendung von durchgängig 10GBit-Ethernet-Komponenten kann in Betracht gezogen werden, verursacht aber sehr hohe Kosten.

● 10GBit-Ethernet wird meist nur auf der Ebene Distribution-Switch/Core-Switch Verwendung finden.

● 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.

15.10.13

Vielen Dank für Ihre Aufmerksamkeit!

inovex GmbH

Pforzheim

Karlsruher Straße 71

D-75179 Pforzheim

München

Valentin-Linhof-Straße 2

D-81829 München

Köln

Schanzenstraße 6-20

D-51063 Köln

Hadoop aus IT-Operations-Sicht - Teil 2 (Hardware- und Netzwerkgrundlagen)

Documents

Transcript of Hadoop aus IT-Operations-Sicht - Teil 2 (Hardware- und Netzwerkgrundlagen)