Teil 2 der Serie: Big Data Labor – Cluster aufsetzen

In dieser Blog Serie bauen wir schrittweise eine kostengünstige Labor-Umgebung für Big Data Experimente auf.

Ist die Umgebung einmal aufgebaut, dann können wir mit den ersten Gehschritten starten. Das in der Labor-Umgebung erworbene Wissen lässt sich nahtlos in eine kostenintensivere und produktiv einsetzbare Umgebung übertragen. Siehe dazu auch die einleitenden Ausführungen zu dieser Artikel-Serie.

Wir starten mit einer Labor-Umgebung, die auf einem Laptop Platz findet und doch verteiltes Rechnen mit Big-Data-Technologien erlaubt. In diesem Artikel stellen wir die Unterschiede zwischen einem Big Data Cluster basierend auf virtuellen Maschinen und einem Big Data Cluster basierend auf Containern vor. In den nächsten Artikeln werden wir einen Big Data Cluster mit virtuellen Maschinen aufbauen.

Ein Blick auf die grundsätzliche Architektur von Big Data fähigen Systemen.

Grundlegende Darstellung eines Big Data Clusters mit drei Nodes

Die Stärke moderner Big Data Systemen liegt im kostengünstigen Scale-Out: Handelsübliche Server (oft als Commodity Hardware bezeichnet), werden zu einem Cluster (Verbund) zusammengeschlossen. Sie bilden dann ein Netzwerk von Servern. In diesem Fall spricht man von einem Node und meint einen Server innerhalb eines Clusters.

Große Big-Data-Installationen, wie etwa bei den Internet-Riesen anzutreffen, umfassen Tausende von Nodes. Auf unserem Bild illustrieren wir das Prinzip mit drei Nodes.

Die Nodes sind miteinander vernetzt – im Bild als Linien dargestellt. Jeder Node hat eine eigene IP Adresse.

Auf jedem Node ist ein Betriebssystem (OS) installiert. Normalerweise dasselbe OS auf allen Nodes, üblicherweise ein Linux-System. Damit einher geht ein Filesystem, in der Linux-Welt treffen wir oft Ext4 an.

Mit zu einem Big-Data-Cluster gehören jetzt die passenden Big-Data-Tools und Apps, die auf den Nodes installiert werden. Auf diese Tools und Apps werden wir in späteren Artikeln eingehen.

Ziel ist es ja, sehr große Mengen an Daten zu verwalten. Üblicherweise handelt es sich dabei um sehr große Files, im Terabyte-Bereich und größer. Auf unserem Bild ist das File F1 schematisch dargestellt.

In einer Big-Data-Installation wird dieses Riesenfile auf mehrere Nodes aufgeteilt. Auf einem Node liegt also nur ein Teil des Files. Aus Sicht des Ext4-Systems auf einem einzelnen Node ist jeder Teil von F1 ein in sich geschlossenes Ext4-File. Nur durch die Big-Data-Tools werden die verschiedenen File-Teile als ein logisches Ganzes erkannt und behandelt.

Das Big Data Labor soll diese Umgebung auf einem Laptop miniaturisieren:

Ein Miniatur-Cluster auf einem Laptop als Big Data Labor

Aktuell gibt es ja zwei Möglichkeiten, um einen Server auf einem Laptop zu “miniaturisieren”

  1. Virtuelle Maschinen
  2. Container

Im Folgenden widmen wir uns den Vor- und Nachteilen der beiden Möglichkeiten gerade in Bezug auf unser Laptop Big Data Labor. Dazu holen wir etwas aus und betrachten die grundlegenden Gemeinsamkeiten und Unterschiede der beiden Möglichkeiten.

Virtuelle Maschinen

Dank Virtualisierungstechnologien können wir auf dem Laptop zusätzlich zu allen Apps eine Umgebung installieren, die die Hardware und das Betriebssystem des Laptops nutzen, jedoch einsetzbar sind, wie ein eigenständiger Rechner mit einem separaten Betriebssystem.

Hier eine schematische Darstellung, die sich auf das Big-Data-Labor bezieht:

Ein Cluster basierend auf virtuellen Maschinen. Die drei mit F1 bezeichneten Blöcke sind drei Teile eines verteilten Big-Data-Files.

Der Laptop dient als Gastgeber, also also Host. Und so ist die Rede vom Host-Betriebssystem.

Darauf installieren wir die Virtualisierungssoftware – genauer den Hypervisor. Innerhalb dieses Hypervisors installieren wir anschließend virtuelle Maschinen mit einem eigenen Betriebssystem. Man spricht vom “Gast”, englisch “Guest”. So kann man die beiden Betriebssyste unterscheiden: Host und Gast. Ein Host kann mehrere Gäste haben. Vorausgesetzt, unser unser Laptop verfügt über genügend Rechenkapazität.

Auf der schematischen Darstellung oben, sind drei virtuelle Maschinen, also “Gäste” dargestellt. Für das Big-Data-Labor werden wir für jede virtuellen Maschine eine eigene statische IP-Adresse konfigurieren.

Der Hypervisor virtualisiert auf Hardware-Ebene. Die virtuellen Maschinen sind vollständig voneinander isoliert und der Hypervisor enthält unter anderem als eine Art “Router”, weist den virtuellen Maschinen IP-Adressen zu und stellt die TCP-IP-Verbindung dazwischen her.

Jede virtuelle Maschine hat also ein eigenes Betriebssystem, ein eigenes Filesystem und eine eigene Installation der Tools und Apps, die wir kennenlernen wollen.

Wie jeder Computer, kann auch eine virtuelle Maschine gestartet und gestoppt werden. Es wird dann jeweils das betreffende Gast-Betriebssystem gestartet resp. gestoppt.

Images von virtuellen Maschinen können auch von einem Laptop auf einen anderen kopiert oder verschoben werden, mehrheitlich unabhängig vom Host-Betriebssystem der Laptops.

Wir werden mit Laptops arbeiten, um das Big-Data-Labor aufzubauen. Virtualisierung ist nicht auf Laptops beschränkt, sondern findet sehr viel Verbreitung bei Cloud-Providern. Dort werden virtuelle Server aufgebaut, verwaltet, vermietet.
P

Einige bekannte Hersteller von Technologien für virtuelle Maschinen:

Container

Containers werden im Vergleich zu virtuellen Maschinen als leichtgewichtiger dargestellt.

Einige bekannte Hersteller von Container Technologien:

Wir stellen hier die Eigenschaften in Bezug auf Docker dar. Andere Container Provider funktionieren ähnlich.

Hier eine schematische Darstellung, die sich auf das Big-Data-Labor bezieht:

Ein Cluster basierend auf Containern.

Gleich wie virtuelle Maschinen kann auch diese Variante auf verschiedenen Host Betriebssystemen auf Laptops und auf Servern installiert werden.

Docker (oder eine andere Container Technologie) übernimmt die Rolle des Hypervisors. Docker ist anders konzipiert. Anstatt wie bei der Virtualisierung für jeden Container das ganze Betriebssystem neu zu installieren, teilen sich die Container den Betriebssystem Kernel und oft auch die Binaries. Die Virtualisierung erfolgt also auf Betriebssystem-Ebene, wobei gemeinsame (shared) Komponenten read-only sind.

Das hat ist sehr platzsparend und ressourcensparend und hat auch zur Folge, dass ein Container sehr viel schneller gestartet werden kann, als eine virtuelle Maschine. Zudem können auf demselben Laptop mehr Container gleichzeitig laufen können, als gleichzeitige virtuelle Maschinen möglich wären.

Doch wo bleibt jetzt unser Big-Data-File? Hier eine schematische Darstellung in Bezug auf unser Big-Data-Labor:

Ein Cluster basierend auf Containern. Die drei mit F1 bezeichneten Blöcke sind drei Teile eines verteilten Big-Data-Files.

Eine weitere Eigenschaft der Container Technologie ist die, dass in einem Container wohl Daten im Filesystem gespeichert werden können, diese aber verloren gehen, wenn der Container gestoppt wird. Container sind dazu gedacht, bei Bedarf sehr schnell gestartet zu werden, ihre Aufgabe auszuführen, die Ergebnisse beispielsweise in eine Datenbank zu schreiben und wieder gestoppt zu werden, wenn sie nicht mehr benötigt werden. Files die in Container geschrieben werden, sind also temporärer Natur und nicht für Persistierung (also die dauerhafte Aufbewahrung) gedacht.

Wird jetzt ein Container gestoppt dann sind diese Daten verloren. Hier die schematische Darstellung:


Ein Cluster basierend auf Containern. Die drei mit F1 bezeichneten Blöcke sind drei Teile eines verteilten Big-Data-Files. Ein Block fehlt, sobald der zugehörende Container gestoppt wird.

Es kann wohl ein neuer Container gestartet werden und ihm kann auch die vorherige statische IP-Adresse zugeordnet werden. Doch die Daten bleiben verloren. Hier eine schematische Darstellung in Bezug auf das Big-Data-Labor:


Ein Cluster basierend auf Containern. Die drei mit F1 bezeichneten Blöcke sind drei Teile eines verteilten Big-Data-Files. Ein Block fehlt, sobald der zugehörende Container gestoppt und neu gestartet wird.

Dass die Daten eines Nodes beim Shutdown verloren gehen, ist überhaupt nicht im Sinn eines Big-Data-Filesystems.

Es ist möglich, einen Container so zu konfigurieren, dass die Files außerhalb des Containers und zwar auf dem Filesystem des Hosts persistiert werden. Im Container mounted man ein logisches Volumen auf dem Host Filesystem.

Hier eine schematische Darstellung in Bezug auf das Big-Data-Labor:

Ein Cluster basierend auf Containern. Die drei mit F1 bezeichneten Blöcke sind drei Teile eines verteilten Big-Data-Files. Im Unterschied zu den vorherigen Darstellungen, befinden sich die Blöcke jetzt in speziell zugeordneten (mounted) Verzeichnissen auf dem Gast-System.

Für unsere Miniaturisierung bedeutet das jetzt, dass jedem Container ein eigenes Volumen auf dem Host-Filesystem zugewiesen wird.

Wird jetzt der Container gestoppt, dann gehen dessen lokale Daten verloren, die auf dem Host-Filesystem persistierten Daten bleiben jedoch vorhanden.

Wird jetzt ein Container gestoppt, dann bleiben die zugehörenden Daten vorhanden. Sie stehen dem Gesamtsystem jedoch nicht zur Verfügung.

Das Big-Data-Filesystem, beispielsweise Hadoop, verwaltet die File-Blöcke auf den einzelnen Nodes, weiss genau, auf welchem Node welche Blöcke sind. Die Nodes werden von Hadoop durch ihre IP-Adresse identifiziert. Das Big-Data-Filesystem wird auch dafür sorgen, dass die Blöcke geschickt über den Cluster verteilt sind.

Beim starten eines Containers muss dafür gesorgt werden, dass zum gemounteten Volumen ein Container mit der ursprünglichen statische IP-Adresse gestartet wird. Denn sonst wird das Big-Data-Filesystem das Riesenfile nicht mehr korrekt aus den Blöcken zusammensetzen können. Hier eine schematische Darstellung in Bezug auf das Big-Data-Labor.

Wir der Container korrekt neu gestartet, dann stehen die Daten dem Gesamtsystem wieder zur Verfügung.

Was bei Containers schlank ist und als Vorteil erscheint, wird für deren Einsatz im Big-Data-Labor  jetzt plötzlich schwerfällig und fehleranfällig.

Wird ein Container heruntergefahren, was wir ja tun, spätestens wenn wir den Laptop ausschalten, dann verschwindet er, verliert seine Identität IP-Adresse und seine Daten. Als Big-Data-Filesystem jedoch verwaltet Hadoop die Files in Blöcken und geht davon aus, dass ein Node eine statische IP-Adresse hat. Startet man jetzt den Laptop wieder, dann muss man auch Docker wieder starten und die einzelnen Container hochfahren. Diese müssen dann so konfiguriert werden, dass sie eine statische IP-Adresse erhalten und genau dasjenige Volumen auf dem Host-OS gemounted wird, das zu dieser statischen IP-Adresse gehört.

Das ist alles machbar, jedoch ziemlich erklärungsbedürftig und für einen Kennenlernbetrieb unnötig fehleranfällig. Aus dem Grund, beginnen wir die Labor-Umgebung mit Hilfe von virtuellen Maschinen zu bauen. Wir werden uns schneller aufs Wesentliche konzentrieren können und in einem späteren Schritt die Docker-Variante vorstellen.