SlideShare ist ein Scribd-Unternehmen logo
1 von 29
Downloaden Sie, um offline zu lesen
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.
Inhalt

●

●

15.10.13

Auswahl und Konfiguration der Hardware
Auswahl und Konfiguration der Netzwerktopologie
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
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.
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).
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.
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“).
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).
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.
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“).
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.
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
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.
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.
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.
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.
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.
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
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 (+++)
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.
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.
Auswahl und Konfiguration der Netzwerktopologie

Vertikaler-Netzwerkvekehr
Horizontaler-Netzwerkverkehr

Baum-Topologie und Netzwerkverkehr
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 70

15.10.13
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.
Auswahl und Konfiguration der Netzwerktopologie

3-Schichten Baum-Topologie
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 71

15.10.13
Auswahl und Konfiguration der Netzwerktopologie

„Spin-Fabric“ Topologie mit zwei Core-Switchen
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 72

15.10.13
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.
Auswahl und Konfiguration der Netzwerktopologie

„Spin-Fabric“ Topologie mit vier Core-Switchen
Sammer, Eric: Hadoop Operations. Sebastopol 2012, S. 73

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

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (10)

CPU Update Juni 2017
CPU Update Juni 2017CPU Update Juni 2017
CPU Update Juni 2017
 
NoSQL with MySQL
NoSQL with MySQLNoSQL with MySQL
NoSQL with MySQL
 
Hazelcast
HazelcastHazelcast
Hazelcast
 
GPUs — Vom spezialisierten Coprozessor zum Numbercruncher
GPUs — Vom spezialisierten Coprozessor zum NumbercruncherGPUs — Vom spezialisierten Coprozessor zum Numbercruncher
GPUs — Vom spezialisierten Coprozessor zum Numbercruncher
 
Tech Talk Cassandra
Tech Talk CassandraTech Talk Cassandra
Tech Talk Cassandra
 
Hochleistungsspeichersysteme für Datenanalyse an der TU Dresden (Michael Kluge)
Hochleistungsspeichersysteme für Datenanalyse an der TU Dresden (Michael Kluge)Hochleistungsspeichersysteme für Datenanalyse an der TU Dresden (Michael Kluge)
Hochleistungsspeichersysteme für Datenanalyse an der TU Dresden (Michael Kluge)
 
MySQL Cluster with Galera Cluster for MySQL
MySQL Cluster with Galera Cluster for MySQLMySQL Cluster with Galera Cluster for MySQL
MySQL Cluster with Galera Cluster for MySQL
 
Weltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-ReplikationWeltweite Produktionsdatenverwaltung mit MySQL-Replikation
Weltweite Produktionsdatenverwaltung mit MySQL-Replikation
 
Was genau macht eigentlich Erasure Coding, und wozu braucht man das?
Was genau macht eigentlich Erasure Coding, und wozu braucht man das?Was genau macht eigentlich Erasure Coding, und wozu braucht man das?
Was genau macht eigentlich Erasure Coding, und wozu braucht man das?
 
MySQL Performance Tuning für Entwickler
MySQL Performance Tuning für EntwicklerMySQL Performance Tuning für Entwickler
MySQL Performance Tuning für Entwickler
 

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

FROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance TuningFROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance Tuning
FromDual GmbH
 
DOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance TuningDOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance Tuning
FromDual GmbH
 
Bacula Workshop - Teil 2
Bacula Workshop - Teil 2Bacula Workshop - Teil 2
Bacula Workshop - Teil 2
inovex GmbH
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
Daniel Schneller
 
Zukunftstrends: was bringt 2013 für die IT?
Zukunftstrends: was bringt 2013 für die IT?Zukunftstrends: was bringt 2013 für die IT?
Zukunftstrends: was bringt 2013 für die IT?
Werner Fischer
 

Ähnlich wie Hadoop aus IT-Operations-Sicht - Teil 2 (Hardware- und Netzwerkgrundlagen) (20)

Analyse und Evaluierung von Parameterabhängigkeiten anhand der Laufzeit von M...
Analyse und Evaluierung von Parameterabhängigkeiten anhand der Laufzeit von M...Analyse und Evaluierung von Parameterabhängigkeiten anhand der Laufzeit von M...
Analyse und Evaluierung von Parameterabhängigkeiten anhand der Laufzeit von M...
 
FROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance TuningFROSCON 2011: MySQL Performance Tuning
FROSCON 2011: MySQL Performance Tuning
 
DOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance TuningDOAG 2011: MySQL Performance Tuning
DOAG 2011: MySQL Performance Tuning
 
Josua Braun, Senior Marketing Manager Storage @ Netgear
Josua Braun, Senior Marketing Manager Storage @ NetgearJosua Braun, Senior Marketing Manager Storage @ Netgear
Josua Braun, Senior Marketing Manager Storage @ Netgear
 
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im ÜberblickBig Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
Big Data Community Webinar vom 16. Mai 2019: Oracle NoSQL DB im Überblick
 
AnyARK Gluster Brick 270TB (198TB netto) Datenblatt
AnyARK Gluster Brick 270TB (198TB netto) DatenblattAnyARK Gluster Brick 270TB (198TB netto) Datenblatt
AnyARK Gluster Brick 270TB (198TB netto) Datenblatt
 
Fujitsu Storage Days 2017 - Rudolf Klassen - "Erfahrungsbericht ETERNUS DX200...
Fujitsu Storage Days 2017 - Rudolf Klassen - "Erfahrungsbericht ETERNUS DX200...Fujitsu Storage Days 2017 - Rudolf Klassen - "Erfahrungsbericht ETERNUS DX200...
Fujitsu Storage Days 2017 - Rudolf Klassen - "Erfahrungsbericht ETERNUS DX200...
 
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer AnwendungBack to Basics - Webinar 6: Produktivsetzung einer Anwendung
Back to Basics - Webinar 6: Produktivsetzung einer Anwendung
 
Hadoop in modernen BI-Infrastrukturen
Hadoop in modernen BI-InfrastrukturenHadoop in modernen BI-Infrastrukturen
Hadoop in modernen BI-Infrastrukturen
 
MySQL HA and Security
MySQL HA and SecurityMySQL HA and Security
MySQL HA and Security
 
Dateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud ComputingDateisysteme und Datenbanken im Cloud Computing
Dateisysteme und Datenbanken im Cloud Computing
 
Bacula Workshop - Teil 2
Bacula Workshop - Teil 2Bacula Workshop - Teil 2
Bacula Workshop - Teil 2
 
MySQL Hochverfügbarkeitslösungen
MySQL HochverfügbarkeitslösungenMySQL Hochverfügbarkeitslösungen
MySQL Hochverfügbarkeitslösungen
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
 
Innobit.storage spaces.
Innobit.storage spaces. Innobit.storage spaces.
Innobit.storage spaces.
 
20190604_DOAGDatabase2019_OracleNoSQLDB_for_DBAs
20190604_DOAGDatabase2019_OracleNoSQLDB_for_DBAs20190604_DOAGDatabase2019_OracleNoSQLDB_for_DBAs
20190604_DOAGDatabase2019_OracleNoSQLDB_for_DBAs
 
Zukunftstrends: was bringt 2013 für die IT?
Zukunftstrends: was bringt 2013 für die IT?Zukunftstrends: was bringt 2013 für die IT?
Zukunftstrends: was bringt 2013 für die IT?
 
IPv6 Integration im Datacenter - wie komplex ist es wirklich?
IPv6 Integration im Datacenter - wie komplex ist es wirklich?IPv6 Integration im Datacenter - wie komplex ist es wirklich?
IPv6 Integration im Datacenter - wie komplex ist es wirklich?
 
Nagios Conference 2007 | Aufbau eines hochverfügbaren Nagios Clusters by Mart...
Nagios Conference 2007 | Aufbau eines hochverfügbaren Nagios Clusters by Mart...Nagios Conference 2007 | Aufbau eines hochverfügbaren Nagios Clusters by Mart...
Nagios Conference 2007 | Aufbau eines hochverfügbaren Nagios Clusters by Mart...
 
Doag 2104 manuskript_hadoop_oracle_integration_gunther_pipperr_v02
Doag 2104 manuskript_hadoop_oracle_integration_gunther_pipperr_v02Doag 2104 manuskript_hadoop_oracle_integration_gunther_pipperr_v02
Doag 2104 manuskript_hadoop_oracle_integration_gunther_pipperr_v02
 

Mehr von inovex GmbH

Interpretable Machine Learning
Interpretable Machine LearningInterpretable Machine Learning
Interpretable Machine Learning
inovex GmbH
 
Deep Learning for Recommender Systems
Deep Learning for Recommender SystemsDeep Learning for Recommender Systems
Deep Learning for Recommender Systems
inovex GmbH
 
Representation Learning von Zeitreihen
Representation Learning von ZeitreihenRepresentation Learning von Zeitreihen
Representation Learning von Zeitreihen
inovex GmbH
 
Performance evaluation of GANs in a semisupervised OCR use case
Performance evaluation of GANs in a semisupervised OCR use casePerformance evaluation of GANs in a semisupervised OCR use case
Performance evaluation of GANs in a semisupervised OCR use case
inovex GmbH
 

Mehr von inovex GmbH (20)

lldb – Debugger auf Abwegen
lldb – Debugger auf Abwegenlldb – Debugger auf Abwegen
lldb – Debugger auf Abwegen
 
Are you sure about that?! Uncertainty Quantification in AI
Are you sure about that?! Uncertainty Quantification in AIAre you sure about that?! Uncertainty Quantification in AI
Are you sure about that?! Uncertainty Quantification in AI
 
Why natural language is next step in the AI evolution
Why natural language is next step in the AI evolutionWhy natural language is next step in the AI evolution
Why natural language is next step in the AI evolution
 
WWDC 2019 Recap
WWDC 2019 RecapWWDC 2019 Recap
WWDC 2019 Recap
 
Network Policies
Network PoliciesNetwork Policies
Network Policies
 
Interpretable Machine Learning
Interpretable Machine LearningInterpretable Machine Learning
Interpretable Machine Learning
 
Jenkins X – CI/CD in wolkigen Umgebungen
Jenkins X – CI/CD in wolkigen UmgebungenJenkins X – CI/CD in wolkigen Umgebungen
Jenkins X – CI/CD in wolkigen Umgebungen
 
AI auf Edge-Geraeten
AI auf Edge-GeraetenAI auf Edge-Geraeten
AI auf Edge-Geraeten
 
Prometheus on Kubernetes
Prometheus on KubernetesPrometheus on Kubernetes
Prometheus on Kubernetes
 
Deep Learning for Recommender Systems
Deep Learning for Recommender SystemsDeep Learning for Recommender Systems
Deep Learning for Recommender Systems
 
Azure IoT Edge
Azure IoT EdgeAzure IoT Edge
Azure IoT Edge
 
Representation Learning von Zeitreihen
Representation Learning von ZeitreihenRepresentation Learning von Zeitreihen
Representation Learning von Zeitreihen
 
Talk to me – Chatbots und digitale Assistenten
Talk to me – Chatbots und digitale AssistentenTalk to me – Chatbots und digitale Assistenten
Talk to me – Chatbots und digitale Assistenten
 
Künstlich intelligent?
Künstlich intelligent?Künstlich intelligent?
Künstlich intelligent?
 
Dev + Ops = Go
Dev + Ops = GoDev + Ops = Go
Dev + Ops = Go
 
Das Android Open Source Project
Das Android Open Source ProjectDas Android Open Source Project
Das Android Open Source Project
 
Machine Learning Interpretability
Machine Learning InterpretabilityMachine Learning Interpretability
Machine Learning Interpretability
 
Performance evaluation of GANs in a semisupervised OCR use case
Performance evaluation of GANs in a semisupervised OCR use casePerformance evaluation of GANs in a semisupervised OCR use case
Performance evaluation of GANs in a semisupervised OCR use case
 
People & Products – Lessons learned from the daily IT madness
People & Products – Lessons learned from the daily IT madnessPeople & Products – Lessons learned from the daily IT madness
People & Products – Lessons learned from the daily IT madness
 
Infrastructure as (real) Code – Manage your K8s resources with Pulumi
Infrastructure as (real) Code – Manage your K8s resources with PulumiInfrastructure as (real) Code – Manage your K8s resources with Pulumi
Infrastructure as (real) Code – Manage your K8s resources with Pulumi
 

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

  • 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