Manta in Aktion

Der Beitrag ist im Oktober 2016 erschienen

Da die Manta-Installation in meinem Lab jetzt tatsächlich benutzbar zu sein scheint, wollte ich hier alle Beispiele zu Anwendungen für Manta sammeln, die ich im Netz so gefunden habe. Vielleicht ist es aber sinnvoll, zunächst nochmal kurz darauf einzugehen, was Manta eigentlich ist. Joyent stellt Manta als Object Storage vor, welches ähnlich wie S3 von Amazon zur Speicherung von verschiedensten Daten genutzt werden kann. Wie bei S3 erfolgt der Abruf der gepeicherten Daten per http oder https. Um Daten in Manta abzulegen, gibt es verschiedene Möglichkeiten. Die einfachste ist die Installation der nodejs Client-Werkzeuge für Manta:

$ npm install -g manta
$ npm install -g json 
$ npm install -g bunyan

Wenn man dann noch die Zugangsdaten in den entsprechenden Umgebungsvariablen hinterlegt (z. B):

export MANTA_USER=hbloed
evtl. export MANTA_SUBUSER
export MANTA_KEY_ID=c7:6d:b4:e9:f9:33:44:7d:cb:6e:58:41:b6:b6:7f:c7
export MANTA_URL=https://manta.de-gt.tgos.de

kann man auch schon loslegen. Standarmässig sieht das dann so aus:

root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# mls /$MANTA_USER
jobs/
public/
reports/
stor/

Upload und "Download" funktionieren dann z. B. so:

root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# mput /$MANTA_USER/public/fr8.jpg -f fr8.jpg
/hbloed/public/fr8.jpg             [=================================================================>] 100%  43.05KB                 
root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# wget https://manta.de-gt.tgos.de/$MANTA_USER/public/fr8.jpg
--2016-10-17 17:51:41--  https://manta.de-gt.tgos.de/hbloed/public/fr8.jpg
Resolving manta.de-gt.tgos.de (manta.de-gt.tgos.de)... 10.64.243.98, 10.64.243.99, 10.64.243.97
Connecting to manta.de-gt.tgos.de (manta.de-gt.tgos.de)|10.64.243.98|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 44083 (43K) [image/jpeg]
Saving to: 'fr8.jpg.1'

fr8.jpg.1                         100%[===============================================================>]  43.05K  --.-KB/s   in 0s    

2016-10-17 17:51:41 (127 MB/s) - 'fr8.jpg.1' saved [44083/44083]
root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~#

Soweit so unspektakulär. Natürlich kann man auch auf andere Weise Daten in Manta speichern. Es gibt SDKs für Python, Ruby, Java, PHP und primär für nodejs. Durch die besondere Architektur von Manta gibt es aber auch noch andere Funktionen. So können z. B. hochgeladene Dateien bearbeitet werden, ohne sie vorher erst herunterladen zu müssen:

root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# mfind /$MANTA_USER/public | mjob create -w -m 'convert $MANTA_INPUT_FILE -resize 100x jpeg:- | mpipe ${MANTA_INPUT_OBJECT%.*}-100x.jpg'
81e40938-d33c-42da-ab61-33527360e366
added 1 inputs to 81e40938-d33c-42da-ab61-33527360e366
root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# wget https://manta.de-gt.tgos.de/$MANTA_USER/public/fr8-100x.jpg
--2016-10-17 18:25:29--  https://manta.de-gt.tgos.de/hbloed/public/fr8-100x.jpg
Resolving manta.de-gt.tgos.de (manta.de-gt.tgos.de)... 10.64.243.98, 10.64.243.97, 10.64.243.99
Connecting to manta.de-gt.tgos.de (manta.de-gt.tgos.de)|10.64.243.98|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3805 (3.7K) [image/jpeg]
Saving to: 'fr8-100x.jpg'

fr8-100x.jpg                      100%[===============================================================>]   3.72K  --.-KB/s   in 0s    

2016-10-17 18:25:29 (1022 MB/s) - 'fr8-100x.jpg' saved [3805/3805]

root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~#

Mit dieser einen Zeile hätte man also alle Bilder im public-Verzeichnis skalieren und wieder abspeichern können. Wenn die Konvertierung etwas aufwändiger sein soll, kann man z. B. folgendes Skript nach Manta hochladen und dann dort für einen weiteren Manta-Job verwenden:

#!/usr/bin/env bash

sizes=( 128 256 512 )

for i in "${sizes[@]}" ; do
    convert $MANTA_INPUT_FILE -resize ${i}x jpeg:- | mpipe ${MANTA_INPUT_OBJECT%.*}-${i}x.jpg
done

Dabei wird das Skript in den nicht-öffentlichen Bereich unter "stor" hochgeladen:

root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# mput -f thumb.sh /$MANTA_USER/stor/thumb.sh

Und so wird es dann angewendet (vorher habe ich mit mrm /hbloed/public/fr8-100x.jpg das zuerst konvertierte Bild wieder gelöscht).

root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# mfind /$MANTA_USER/public | mjob create -w -s /$MANTA_USER/stor/thumb.sh -m 'bash /assets/$MANTA_USER/stor/thumb.sh'
03292964-cf99-6238-abf7-f42e97f61f7f
added 2 inputs to 03292964-cf99-6238-abf7-f42e97f61f7f
root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~# mls /$MANTA_USER/public
fr8-128x.jpg
fr8-256x.jpg
fr8-512x.jpg
fr8.jpg
root@ec057038-51aa-ed39-ffc9-dd88a5a20198:~#

Wie geht das? Wo genau wird dieser convert-Job eigentlich gestartet? In Manta die zweite war ich ja schon kurz auf die Architektur eingegangen. Wenn ein Job innerhalb von Manta gestartet wird, geschieht dies in einem extra dafür existierenden Container resp. in einer SmartOS-Zone. In diese wird das Manta-Objekt, welches bearbeitet werden soll, quasi "eingeblendet". Diese speziellen SmartOS-Zonen heissen Marlin. Sie werden auf jedem Storage-Knoten erzeugt und vorgehalten, um Manta-Jobs abzuarbeiten. Dabei enthalten sie ein reichhaltiges Softwareangebot. Aber - wie oben gesehen - man kann natürlich auch eigene Software als asset hochladen und ausführen. Hier wird gezeigt, wie man spezielle Bibliotheken für R hochladen kann.

Interessant ist auch die Option, mit mlogin eine interaktive Session "auf" dem zu bearbeitenden Objekt zu starten:

root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# mls ~~/stor
01-2010.csv
02-2010.csv
03-2010.csv
04-2010.csv
05-2010.csv
root@e3b75fc5-3621-cdd8-f9dd-c9acbf4a37e9:~# mlogin ~~stor/04-2010.csv 
 * created interactive job -- da1408e9-0dac-ed17-f8fe-ff756cde2c44
 * waiting for session... | established
mhbloed@manta # ls -la /manta/mhbloed/stor/
total 94
drwxr-xr-x 2 root root    185 Mar 21 10:31 .
drwxr-xr-x 3 root root    178 Mar 21 10:31 ..
-rw-r--r-- 1 root root 266547 Mar 21 10:31 04-2010.csv
mhbloed@manta # ls /opt/local/      
DWB         cgi-bin              eclipse    go                 java      neo4j                  pyutil  tests
FHE         contrib              enstratus  go14               joos      netdisco               qt3     tools
GNUstep     cross                etc        gopkg              lib       osbf-lua               qt4     var
MesaLib7    cross-arm-none-eabi  features   graphite           libdata   ossec                  qt5     vipec
SPTK        cross-freemint       fml        heirloom           libexec   pkg                    root    wheel
amazon-ec2  cross-h8300-elf      gcc-aux    heirloom-doctools  libressl  pkg.refcount           rt      www
avr         cyrus                gcc47      include            lkm       pvm3                   rtty    x86_64-sun-solaris2.11
awstats     dict                 gcc48      info               man       py27-google-cloud-sdk  sbin    xcb-util036
bin         doc                  gcc49      jasmin             my.cnf    py35-google-cloud-sdk  share
mhbloed@manta # exit
exit

 * remote process exited
 * cleaning up resources...
 * session complete

Unter /opt/local findet sich dann die gesamte zur Verfügung stehende Software der Marlin-Zone. Man kann/sollte also zunächst interaktiv die Bearbeitung des gewünschten Objekts ausprobieren, um dies dann für sämtliche Objekte in einem Manta-Job durchzuführen.

Dazu muss man wissen, dass Manta keine Replikation im herkömmlichen Sinne kennt. Von hochgeladenen Objekten werden automatisch zwei Kopien erzeugt (man kann beim Hochladen aber auch mehr Kopien erzwingen), die auf verschiedenen Storage-Nodes abgelegt werden. Loadbalancer sorgen für eine möglichst günstige Verteilung über möglichst viele Storage-Nodes. Die Speicherung wird erst als erfolgreich zurückgemeldet, wenn sowohl die Kopien auf der Platte also auch die Metadaten im Postgres-Cluster gespeichert sind. Damit ist Manta "strongly consistent" und nicht "eventual consistent" wie andere Object Stores. Manta sollte in drei Availability Zones (AZ) pro Region aufgebaut werden - dabei sollten die AZs natürlich keine Komponenten von anderen AZs derselben Region mitverwenden. Bei einem solchen Aufbau sollte Manta alle Netzwerkpartitionierungen zwischen AZs bis zum Verlust einer kompletten AZ überleben können.

Natürlich macht auch Manta starken Gebrauch von ZFS (RAIDZ2 mit Hotspares), um die einzelnen Nodes so ausfallsicher wie möglich zu machen. Fault Tolerance in Manta beschreibt die zugrundeliegenden Überlegungen und Entscheidungen im Detail.

Aber Joyent gibt neben Bild- und Videokonvertierungen auch noch klassische Map/Reduce-Anwendungen als ideal für Manta an. Durch die stark verteilte Architektur sollte es sich auch als Object Storage für Sensor Networks oder andere Anwendungen aus dem "Internet der Dinge (IoT)" eignen. Dabei wirkt sich die Speicherung auf vielen Storage-Nodes sowohl bei der Ablage als auch bei der Verarbeitung äußerst positiv auf die Performance aus, da die Auswertungsjobs dort quasi parallel laufen. Selbstverständlich kann man auch einfach seine MySQL-Backups nach Manta hochladen.

Im Marlin-Dashboard sieht man dann, wie die verschiedenen Marlin-Zonen für die Ausführung des Jobs parallel auf den verschiedenen Marlin-Nodes benutzt und wieder in den Ursprungszustand gebracht werden: