Der SMACK-Stack zum Anfassen!

Wer sich dieser Tage mit dem Themengebiet Big- oder Fast-Data beschäftigt, kommt am sogenannten SMACK-Stack nicht vorbei. Dieser Artikel demonstriert, wie einfach es ist, den kompletten Stack in der AWS aufzubauen. Im ersten Schritt setzen wir ein DC/OS-Mesos-Cluster auf. Dieses Cluster dient uns als Grundinfrastruktur, in die wir Kafka, Cassandra und Spark installieren. Zum Abschluss starten wir einfache Ingestion- und Digestion-Jobs, die Live-Daten durch den Stack pumpen. SMACK ist zwar ein griffiges Akronym, aus logischen Gründen wird die Reihenfolge allerdings MCKSA(S) lauten.

Schritt 0: Vorbedingungen

Um die folgenden Beispiele selbst ausführen zu können, benötigt Ihr folgendes:

• Vagrant und Virtualbox
• Ansible
• Einen AWS-Account. Seid gewarnt: Es fallen Nutzungsgebühren an
• Ein EC2-Schlüsselpaar dcos-intro
• Einen Twitter-Zugangsschlüssel

Der Quellcode ist auf https://github.com/ftrossbach/intro-to-dcos verfügbar.

Schritt 1: sMack steht für Mesos

DC/OS ist ein verteiltes Betriebssystem für Rechenzentren und basiert auf dem Apache-Projekt Mesos. Seit Version 1.7 ist DC/OS Open Source . Unter https://downloads.dcos.io/dcos/EarlyAccess/aws.html stellt das Projekt Vorlagen für AWS CloudFormation bereit, mit denen man einfach ein DC/OS-Cluster erstellen kann. Das folgende Diagramm gibt einen Überblick über die AWS-Ressourcen, die für dieses Beispiel erstellt werden:

Das öffentliche Subnetz ist vom Internet aus erreichbar. Es enthält einen Mesos-Master sowie einen öffentlichen Mesos-Agenten. Für dieses Beispiel reicht ein Master aus, da wir keine Hochverfügbarkeit des Clusters benötigen. DC/OS bietet aber auch Vorlagen für Hochverfügbarkeitsszenarien. Das private Subnetz ist nur aus dem öffentlichen Subnetz erreichbar. Es enthält 5 Mesos-Agenten, auf die sämtliche Applikationen ausgerollt werden können, die nicht über das Internet verfügbar sein müssen. CloudFormation-Vorlagen werden schnell unübersichtlich. Der Blogartikel meines Kollegen Bernd Zuther beschreibt, wie man statt CloudFormation Terraform benutzen kann.

Um den Stack aufzubauen, müsst Ihr zunächst das Beispielprojekt auf Github klonen. Zusätzlich ist es notwendig, dass Ihr folgende Umgebungsvariablen setzt:

• DCOS_INTRO_AWS_REGION
• DCOS_INTRO_AWS_ACCESS_KEY
• DCOS_INTRO_AWS_SECRET_KEY

Der Befehl vagrant up erstellt ein virtuelles Ubuntu, dass als Tor zu unserem Cluster dienen wird. Während der Provisionierung der virtuellen Maschine erzeugt Ansible das Cluster in AWS. Dieser Prozess ist synchron und kann einige Minuten dauern. Im Anschluss können wir uns unsere neuen EC2-Instanzen in AWS ansehen:

Ansible schreibt zusätzlich die URL des Master-Loadbalancers auf die Konsole:

TASK [dcos-cli : This is the URL of your master ELB] ****************
ok: [default] => {
    "msg": "http://dcos-test-ElasticL-***.elb.amazonaws.com"
}

Die wichtigsten Einstiegspunkte in euer Cluster sind:

• DC/OS-Dashboard: http:///
• Der Scheduler Marathon: http:///marathon
• Mesos-WebUI: http:///mesos

Somit können wir uns nun unser brandneues DC/OS-Dashboard ansehen:

Da wir noch keine Anwendungen in unserem Cluster installiert haben, stehen sämtliche Ressourcen zur Verfügung.

Unser DC/OS-Cluster dient als Basisinfrastruktur, auf der wir im Folgenden die noch fehlenden SMACK-Komponenten installieren werden.

Schritt 2: smaCk steht für Cassandra

Ansible war bereits so nett, die DC/OS CLI in unserer Vagrant-Box zu installieren. Die DC/OS CLI ist ein Kommandozeilenprogramm, mit dem wir Applikationen in unserem Cluster verwalten können. Innerhalb der Vagrant-Box (Zugriff über vagrant ssh) können wir das Cassandra-Mesos-Framework nun mit nur einem einfachen Befehl installieren:

dcos package install cassandra

Dieser Befehl startet drei Cassandra-Knoten mit Standardeinstellungen bezüglich zugewiesener Prozessoren und Hauptspeicher. Weitere Optionen sind unter https://dcos.io/docs/1.7/usage/tutorials/cassandra/ zu finden.

Es ist möglich, dass das DC/OS-Dashboard unmittelbar nach diesem Befehl anzeigt, dass Cassandra „unhealthy“ sei. Dieser Zustand ist normal und legt sich nach einigen Minuten. Ihr könnt nun auch sehen, dass erste Ressourcen Eures Cluster nun vergeben sind.

Die Initialisierung eines Cassandra-Schemas ist leider noch nicht über die DC/OS-CLI möglich. Hierzu müssen wir uns per SSH und dem privaten Schlüssel des Schlüsselpaars „dcos-intro“ auf dem Master-Knoten (nicht Loadbalancer!) einloggen:

ssh core@<mesos_master_ip> -i dcos-intro.pem

Nun nutzen wir Docker zum Start einer cqlsh-Kommandozeile:

docker run -ti cassandra:2.2.5 cqlsh node-0.cassandra.mesos

Innerhalb der cqlsh können wir den erforderlichen Keyspace und die einzige Tabelle des Beispiels anlegen:

CREATE KEYSPACE IF NOT EXISTS dcos WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '3'};
CREATE TABLE IF NOT EXISTS dcos.tweets(date timestamp, text text, PRIMARY KEY (date, text));

Ja, es handelt sich um ein Twitter-Beispiel.

Schritt 3: smacK steht für Kafka

Analog zu Cassandra können wir auch Kafka über die DC/OS-CLI installieren. Das Kommando

dcos package install --package-version=0.9.4.0 kafka

installiert den DC/OS-Kafka-Service. Wir verwenden Version 0.9.4.0 des Services, da die mit DC/OS 1.7 ausgerollte Version Probleme in der Interaktion mit den im Beispiel genutzten Frameworks hat.

Im Gegensatz zu Cassandra führt die Installation des Kafka-Mesos-Dienstes nicht automatisch zum Start von Kafka-Brokern. Hierzu dient folgender DC/OS-CLI-Befehl:

dcos kafka broker add 0..2 --port 9092

Hierdurch werden drei Broker – broker-0, broker-1 und broker-2 – erzeugt und auf Port 9092 fixiert. Weitere Konfigurationsoptionen sind unter https://docs.mesosphere.com/usage/services/kafka/ verfügbar.

Broker hinzuzufügen führt noch nicht automatisch zu ihrem Start. Hierfür ist folgender Befehl zuständig:

dcos kafka broker start 0..2

Nun nutzen wir die DC/OS-CLI, um ein Kafka-Topic mit dem sehr kreativen Namen „topic“ anzulegen, dass zehn Partitionen und einen Replikationsfaktor von 3 aufweist:

dcos kafka topic add topic --partitions 10 --replicas 3

Schritt 4: Smack steht für Spark

Ihr könnt mittlerweile vermutlich raten, wie man Spark installiert. Der Vollständigkeit halber:

dcos package install spark

Mit diesem Befehl wird Spark im sogenannten Cluster-Mode gestartet. Spark-Jobs werden an den MesosClusterDispatcher geschickt. Dieser Dispatcher verteilt die Jobs und Tasks dynamisch an im Cluster zur Verfügung stehende Ressourcen. Es gibt keine dedizierten Spark-Exekutoren!

Dieser Schritt bildet den Abschluss der Installation der SMACK-Infrastruktur. Ein Blick auf die Mesos-WebUi offenbart alle laufenden Tasks:

Das Beispiel

Da nun die SMACK-Infrastruktur steht, folgt als nächster logischer Schritt die Ausführung einer SMACK-Anwendung.

Die Beispielanwendung schiebt kontinuierlich Tweets über Kafka und Spark in die angelegte Cassandra-Tabelle. Sie ist logisch in zwei Teile unterteilt:

• Ingestion (Aufnahme)
• Digestion (Verarbeitung)

Die folgenden Abschnitte beschäftigen sich mit diesen beiden Themen.

Schritt 5: smAck steht für Akka – Ingestion

Die Anwendung empfängt Tweets über die Twitter4j-Bibliothek und schreibt sie unter Nutzung von Akkas „reactive streams“ und der Kafka-Erweiterung in das angelegte Kafka-Topic.

Der Code ist im oben genannten Github-Repository verfügbar. Da es sich um eine Standard-Implementierung ohne große Überraschungen handelt, gehen wir hier nicht viel weiter ins Detail. Viel spannender ist der Deployment-Aspekt. Die Anwendung ist als Docker-Container im öffentlichen Repository https://hub.docker.com/r/ftrossbach/dcos-intro/ abgelegt.

Zum Deployment nutzen wir das DC/OS-Scheduling-Framework Marathon und die DC/OS-CLI. Ein Marathon-Deployment wird in JSON beschrieben. Für die Ingestion verwenden wir folgende Konfiguration:

{
 "id": "ingestion",
 "container":{
   "docker":{
     "forcePullImage":true,
     "image":"ftrossbach/dcos-intro",
     "network":"BRIDGE"
     "privileged":false
   },
   "type":"DOCKER"
 },
 "cpus":1,
 "mem":2048,
 "env":{
   "KAFKA_HOSTS":"broker-0.kafka.mesos",
   "KAFKA_PORT":"9092",
   "twitter4j.debug":"true",
   "twitter4j.oauth.accessToken":"****",
   "twitter4j.oauth.accessTokenSecret":"****",
   "twitter4j.oauth.consumerKey":"****",
   "twitter4j.oauth.consumerSecret":"****"
 }
}

Wir spezifizieren hierbei den zu installierenden Docker-Container, Variablen wie die Anzahl an CPUs oder Hauptspeicher sowie einige Umgebungsvariablen für die Ausführung der Anwendungen.

Das Deployment wird durch den Befehl

dcos marathon app add /vagrant/provisioning/ingestion.json

angestoßen. Das JSON muss gültige Twitter-Credentials enthalten.

Der Status des Deployments kann auf http:///marathon eingesehen werden. Die Mesos-WebUI unter http:///mesos enthält die Informationen ebenfalls. In beiden Oberflächen hat man Zugriff auf Log-Dateien.

Das Deployment ist erfolgreich abgeschlossen, wenn die Applikation im Status „running“ ist. Falls dies nicht der Fall ist, prüft Ihr am besten das Error-Log.

Schritt 6: Smack steht schon wieder für Spark – Digestion

Im letzten Schritt starten wir nun die Digestion. Die Daten liegen im Kafka und somit auf einem verteilten Message Broker mit extrem hoher Performance bereit. Da Kafka jedoch keinerlei Möglichkeiten für eine effizienten Datenanalyse bietet, müssen wir uns hierfür etwas anderes einfallen lassen.

Wir nutzen einen Spark-Streaming-Job, der ebenfalls im GitHub-Repository verfügbar ist (de.codecentric.dcos_intro.spark.SparkJob). Um das Beispiel möglichst einfach zu halten, macht dieser Job keinen Gebrauch der vielfältigen Möglichkeiten von Spark. Er schreibt die Daten einfach 1:1 in die angelegte Cassandra-Tabelle.

Um einen Spark-Job über die DC/OS-CLI zu starten, muss das entsprechende Jar öffentlich verfügbar sein (https://dcos.io/docs/1.7/usage/tutorials/spark/ ). Wir nutzen hierzu AWS-S3. Ist das Jar einmal hochgeladen, kann der Job mit folgendem Kommando gestartet werden:

dcos spark run --submit-args=' \ 
--class de.codecentric.dcos_intro.spark.SparkJob \
https://s3.eu-central-1.amazonaws.com/dcos-intro/dcos-intro-assembly-1.0.jar \ 
topic node-0.cassandra.mesos 9042 \ 
broker-0.kafka.mesos:9092'

Die WebUI des Spark-Mesos-Dispatchers liefert Auskunft über den Status des Jobs. Sie ist unter
http:///service/spark erreichbar.

Nachdem der Job angelaufen ist, können wir uns ein weiteres Mal in die Cassandra einloggen und die Tabelle abfragen:

Zusammenfassung und Ausblick

Herzlichen Glückwunsch, Ihr seid nun Herrscher(-innen) über ein voll funktionsfähiges SMACK-Cluster und habt auch schon die erste Anwendung zum Laufen gebracht.

Dieser Artikel hat Euch durch die hierzu notwendigen Schritte geführt. Das entstandene Cluster eignet sich hervorragend dazu, um die komplette Toolchain zu erproben. Natürlich ist dies nur ein Anfang – die Beispielanwendung kann nicht wirklich als Big- oder Fast-Data-Anwendung bezeichnet werden.

Vor einem Produktiveinsatz empfehle ich folgende weitere Schritte und Quellen:

• die neue DC/OS-Webseite
• die Dokumentation des Schedulers Marathon
• die Konzepte zur Service-Discovery mit Mesos DNS
• die Schärfung der Einstellungen für Kafka und Cassandra
• die Einführung von Zugangsbeschränkungen – das genutzte Template erlaubt jedermann Zugriff
• eine Erkundung der Optionen der DC/OS CLI (dcos --help innerhalb der Vagrant-Box)
• die Verschaffung eines Überblicks über die offiziellen DC/OS-Pakete im Mesosphere Universe

Um den Stack nach der Erprobung mit wenigen Klicks wieder abzureißen, kann die CloudFormation-Konsole in AWS genutzt werden.