© Andriy Popov, 123RF

Die dezentrale Datenverarbeitung außerhalb von Rechenzentren nimmt immer mehr an Fahrt auf. Mit Akraino Edge Stack gibt es einen quelloffenen Weg für die entsprechenden Anwendungsszenarien. Das Linux-Magazin hat sich das Projekt und sein Umfeld genauer angesehen.

Neben dem Dauerbrenner Cloud Computing heißen die neuen Stars am IT-Himmel Internet der Dinge und Edge Computing [1]. Aber was steckt hinter diesem “Rechnen am Rande”? Einfach ausgedrückt, geht es um das Platzieren der Verarbeitung, des Transports und der Speicherung von Daten möglichst nahe an den Datensammelstellen. Letztere werden oft als Endgeräte bezeichnet; dazu gehören Mobiltelefone, Kameras, Tablet-PCs, Sensoren und vieles mehr. Der Weg zwischen Endgerät und Infrastrukturelementen wie Rechner, Netzwerk und Datenspeicher soll sich durch Edge Computing erheblich verkürzen.

Nebel, Wölkchen und Mobil

Damit gehen noch ein paar andere Versprechen einher. Der schnellere und stark reduzierte Datentransfer verspricht kürzere Latenzen, schnellere Bearbeitung und kürzere Antwortzeiten. Dazu kommen unter anderem eine optimierte Infrastruktur, erhöhte Sicherheit und bessere Anpassung an lokale Gegebenheiten.

Die Arbeitsdefinition von Edge Computing, das Nahebringen von Endgerät und Infrastruktur, ist aber recht vage und lässt sich auf verschieden Weisen umsetzen. Tatsächlich unterscheidet die Fachwelt drei große Implementierungsansätze. Da ist einmal das Fog Computing [2], was sich als nebulöses Berechnen übersetzen lässt. Der Begriff repräsentiert die Ungenauigkeit dieser Implementierung. Es ist dabei nicht festgelegt, wo zwischen dem Endgerät und dem Rechenzentrum die neuen Rechenknechte platziert sind. Daraus resultiert ebenfalls eine gewisse Unschärfe der Datenqualität.

Nummer zwei ist das Multi-Access Edge Computing [3]. Der frühere Name enthielt den Begriff “Mobile” und gab einen Hinweis auf das entscheidende Merkmal des Ansatzes, die Verbindung zu den Endgeräten über das mobile Netzwerk. Präziser formuliert, residieren hier die ausgelagerten Infrastrukturen in oder in der Nähe einer Funk-Basisstation.

Die dritte – gern referenzierte – Implementierung hört auf den Namen Wölkchen oder im angelsächsischen Sprachraum auf Cloudlet. Das Wölkchen steht hier für ein komplettes Rechenzentrum, aber herunterskaliert auf eine Größe, die quasi in eine Schachtel passt. Dieser Ansatz ist vielleicht die offensichtlichste Variante von Edge Computing: Es gilt, einfach das Rechenzentrum stark zu verkleinern. Das Resultat dient dann als Zwischenstation zwischen dem Endgerät und der klassischen IT-Landschaft.

Zum gegenwärtigen Zeitpunkt gibt es keinen klaren Favoriten unter diesen drei Implementierungen. Je nach Anwendungsfall eignet sich eines mehr als das andere. Typische Merkmale sind Leistungsaufnahme, Server-Dichte, notwendige Nähe zum Endgerät, Kosten und auch das Zugriffsmedium.

Quelloffen am Rande

Unabhängig von der gewählten Implementierung stellt sich die Frage, welche Software für die verschiedenen Komponenten zum Einsatz kommt. Welche Firmware oder welches Betriebssystem läuft “on the edge”? Wie sind die notwendigen Protokolle, Warteschlangensysteme und Anwendungen implementiert? Welche Mechanismen dienen zum Absichern und Isolieren von Daten und Prozessen?

Für die herkömmliche IT gibt es hier schon eine Reihe von Lösungen, auch aus dem Bereich der quelloffenen Software. Das freie Projekt Kubeedge [4] etwa erweitert die bekannte Containerorchestrierung Kubernetes [5] von Google auf den Rand. StarlingX [6] benutzt Openstack-Komponenten [7], um die notwendige Infrastruktur für Edge Computing aufzubauen und zu verwalten. Das Projekt Edgent [8] der Apache-Foundation fokussiert auf den Anwendungsfall Analytics.

Auch die bekannten Schirmherren von quelloffener Software haben Arbeitsgruppen oder ähnliche Konstrukte ins Leben gerufen. Bei Openstack findet man die Edge Computing Group [9]. Die Linux Foundation hat eine Art Unterstiftung namens LF Edge (Foundation) gegründet [10]. Diese beherbergt gleich sieben Projekte [11], wozu auch das Projekt Akraino [12] gehört.

Abbildung 1: Die grundlegende Architektur von Akraino.

Von Auslieferungspunkten und Blaupausen

Unter den quelloffenen Projekten für das Edge Computing nehmen einige sogar in Anspruch, einen vollständigen Technologie-Stack bereitzustellen. Sprich: Benutzt man diesen Ansatz, hat man alles beisammen, was nötig ist. Neben dem bereits genannten Edgent sind Iofog [13], CORD [14] und EdgeX Foundry [15] bekannt. Bei Letzterem handelt es sich um ein Projekt der bei der Linux Foundation angesiedelten Edge Foundation. Da stellt sich die Frage, was Akraino anders oder gar besser macht. Um es vorwegzunehmen: Beide Projekte sehen sich nicht als Konkurrenten, sondern als Ergänzungen zueinander. Es ist also nicht ungewöhnlich, dass beide im Zusammenspiel zum Einsatz kommen.

Was genau verbirgt sich hinter dem Akraino Edge Stack? In erster Linie ist es eine Sammlung von fertigen Rezepten für verschieden Anwendungsfälle von Edge Computing. Bei diesen Blaupausen handelt es sich um deklarative Konfigurationen eines kompletten Technologiestapels, der alle Schichten aus Abbildung 1 beschreibt. Dabei bedient sich Akraino aus dem reichen Fundus quelloffener Software.

Je nach Blaupause oder Anwendungsfall können dabei unterschiedliche Projekte für die Bereitstellung einer bestimmten Funktion zum Einsatz kommen. Die Blueprints befinden sich zunächst im Status “Vorgeschlagen”. Nach erfolgreicher Prüfung und Validierung durch das Projekt ändert sich dieser in “Genehmigt”. Dann kann diese Vorlage – zusammen mit anderen – als Teil einer neuen Version von Akraino Edge Stack erscheinen.

Ende Januar hat Akraino mit dem Erscheinen der Version R2 [16] Blueprints für das Einbinden von Fahrzeugen über die freie Plattform für Multi Access Edge Computing (MEC) aufgenommen. Entwickler sollen damit Navigationsfunktionen, Verkehrsmeldungen in Echtzeit und einiges mehr ansteuern können.

Auf aktuelle Technologien zielt auch ein für Anwendungen im Umfeld von Augmented Reality und virtuelle Realität (AR/VR) gedachter Stack. Der passende Blueprint bildet dazu ein virtuelles Klassenzimmer samt der nötigen Infrastruktur ab. Das Klassenzimmer lässt sich dann für Unterrichtssimulationen nutzen.

Eine weitere Neuerung stellt der integrierte Cloud Native NFV/Application Stack (ICN) dar. Mit dem ICN sollen sich die allgemeinen Herausforderungen von Edge-Deployments durch ein einziges Deployment-Modell lösen lassen. Dazu zählt dann etwa Zero Touch Provisioning, also die automatische Installation einer lokalen Netzwerkkomponente. Der ICN-Stack integriert Kubernetes sowie ONAP4K8s und ist auf Bare Metal und in virtuellen Umgebungen einsetzbar.

Die im Juni 2019 erschienene Ausgabe (Release 1) umfasste knapp 20 Blaupausen [17]; mit dem Release 2 sind fünf weitere hinzugekommen, nebst Updates für bestehende (Abbildung 2). Die Blueprints unterteilen sich wiederum in mehr als zehn Kategorien. Sieht man genau hin, fällt auf, dass die Akraino-Macher die Untermenge “Network Cloud” der herausgegebenen Blaupausen besonders protegieren. Akraino soll prinzipiell auf drei Plattformen anwendbar sein: in der Cloud, auf physikalischen Geräten und virtualisiert.

Abbildung 2: Das Projekt Akraino stellt in der Release 2 neue Blaupausen und Updates vor.

Beim Einstieg in die Dokumentation stößt man immer wieder auf den Begriff POD [18]. In einer Kubernetes-affinen Welt verwirrt das zunächst. Es geht hier aber nicht um eine Zusammenfassung von Containern. POD steht vielmehr für die wohl ursprüngliche Abkürzung von “Point of Delivery”. Dieser Auslieferungspunkt beschreibt eine Stelle, wo verschiedene Komponenten zusammenkommen, um letztlich eine Dienstleistung bereitzustellen. Je nach Abstraktionsgrad oder Ausrichtung kann ein solcher POD komplett auf Software basieren – bei Akraino ist das aber nicht so.

Noch einmal zur Erinnerung: Das Projekt möchte ein vollständiges Rezept für das Edge Computing liefern, inklusive physikalischer Hardware. Bei Akraino gehören PODs genau in diesen Bereich. Das Projekt definiert sie als Methode, um Edge Computing zu installieren. Die Bandbreite reicht hier von einem Rechner bis zu mehreren Racks mit Servern und weiteren Komponenten. Dazu definiert Akraino fünf verschiedene Kategorien vom Cruiser bis zum Rover (siehe Tabelle 1).

Zum gegenwärtigen Zeitpunkt stammen die in den Blaupausen dokumentierten Server vorrangig aus dem x86-Bereich; bei den Herstellern dominieren Dell und HPE. Listing 1 zeigt eine Konfiguration für das POD-Modell Rover von Dell. Rover heißt bei Akraino die kleinste Hardware-Variante – nur ein Server, keine Switches, keine Racks.

Die Konfiguration enthält Informationen für die pure Hardware (BIOS, Verwaltungsschnittstelle) sowie das Betriebssystem. Dazu gehören die Konfiguration des Netzwerks, der Betriebssystemkern und das Admin- beziehungsweise Root-Passwort. Im Listing sind die jeweiligen Schritte kommentiert.

# Servername
SRV_NAME=aknode24
#
# Konfiguration fuer Admin-Schnittstelle (IP-Adresse, Zugangsdaten)
SRV_OOB_IP=10.54.35.145
SRV_OOB_USR=root
SRV_OOB_PWD=calvin
# MAC-Adresse
# SRV_MAC=3c:fd:fe:b8:10:60
#
# Boot-Parameter wie Datentraeger, Kernel, Kernel-Parameter
SRV_BOOT_DEVICE=sda
SRV_BLD_SCRIPT=hwe-16.04.6-amd64
SRV_KERNEL_PARAMS=
#
# Vorlagen fuer die Konfiguration (BIOS/UEFI, RAID, Netzwerk-Boot)
SRV_BIOS_TEMPLATE=dell_r740_g14_uefi_base.xml.template
SRV_BOOT_TEMPLATE=dell_r740_g14_uefi_httpboot.xml.template
SRV_HTTP_BOOT_DEV=NIC.Slot.7-1-1
#
# Vorlage fuer Erstkonfiguration des Betriebssystems
SRV_FIRSTBOOT_TEMPLATE=firstboot.sh.template
#
# Netzwerk-Parameter fuer Installation und
#  Betriebssystem wie IP, VLAN, DNS, ...
SRV_VLAN=408
SRV_MTU=9000
SRV_IP=10.54.34.231
SRV_SUBNET=10.54.34.224
SRV_NETMASK=255.255.255.224
SRV_GATEWAY=10.54.34.225
SRV_DNS=10.34.63.200
SRV_DOMAIN=vran.k2.ericsson.se
SRV_DNSSEARCH=vran.k2.seidelnet.de.
SRV_NTP=seki20-ntp1.k2.seidelnet.de
#
# Konfiguration eines NIC-Verbunds (bond)
SRV_BOND=bond0
SRV_SLAVE1=enp134s0f0
SRV_SLAVE2=enp134s0f1
#
# Admin-/Root-Passwort auf Betriebssystemebene
SRV_PWD=akraino,d
#

Installation am Rande

Ist die Entscheidung für eine Blaupause von Akraino gefallen, stellt sich die Frage der Installation. Ein typischer Anwendungsfall umfasst viele Orte außerhalb der zentralen Infrastruktur. Das Projekt benutzt ein System aus drei Schichten (Abbildung 3), die Installation erfolgt kaskadierend.

Abbildung 3: Topologie für Installation und Verwaltung bei Akraino.

Den Anfang machen zentrale Instanzen. Typischerweise befinden sich diese in den vorhandenen Rechenzentren. Deren Anzahl kann im Bereich von eins bis zu zehn variieren. Sie steuern den Aufbau und die Verwaltung sogenannter regionaler Instanzen. Deren Anzahl darf dann schon dreistellig ausfallen. Die letzte Kaskade bilden die Instanzen “am Rande”. Deren Installation und Wartung erfolgt durch die erwähnten regionalen Gegenstücke.

Dieser Aufbau lässt sich hervorragend anhand einer aktuellen Blaupause nachvollziehen. Das Beispiel gehört zur Kategorie Netzwerk-Cloud [19]. Dort findet man die entsprechende Dokumentation der regionalen Instanz und des Gegenstücks “am Rande”; als PODs sind Rover und Unicycle beschrieben. Die regionale Instanz kann sowohl auf einem physikalischen Rechner als auch in einer virtuellen Maschine laufen [20]. Das dazugehörige Portal besteht aus mehreren Komponenten: Webserver, Verzeichnisdienst und Datenbank. Diese laufen sauber getrennt in verschiedenen Containern (Abbildung 4).

Abbildung 4: Eine regionale Instanz für die Netzwerk-Cloud läuft in Containern.

Akraino als Teil des Ökosystems

Akraino Edge Stack ist etwas anders als die anderen Projekte im Bereich Edge Computing. Das Fundament bilden detaillierte Anleitung – die Blaupausen – zur Installation von Hard- und Software für die verschiedensten Anwendungsfälle. Es gibt also nicht den einen Technologiestapel, sondern viele. Im Extremfall wären es mindestens so viele, wie es Anleitungen gibt. Im Idealfall lassen sich aus den Arbeiten von Edgent, Iofog, CORD und Co. weitere Blaupause erzeugen.

Analoges gilt für das Nachbarprojekt von LF Edge, EdgeX Foundry. Laut Eigenaussage sieht sich Akraino als viel umfassender. Es deckt nicht nur einen oder wenige Anwendungsfälle ab. Dies ist allerdings kein Alleinstellungsmerkmal, ähnliche Ambitionen finden sich inzwischen auch bei den anderen Projekten. Akraino überzeugt jedoch besonders durch die genauen Installationsanleitungen bis hinunter zur Hardware. Vorgefertigte, sofort anwendbare Rezepte erleichtern den Einstieg in das Edge Computing ungemein.

Fazit und Ausblick

Der Ansatz von Akraino gefällt. Direkt anwendbare Konfigurationen und Installationsanleitungen verringern die Einstiegshürde beim Edge Computing. Die Durchschlagskraft im Vergleich mit anderen Projekten ließe sich durch mehr Blaupausen inklusive anderer Hardware-Hersteller verbessern. Die ursprünglich bereits für Oktober 2019 erwartete Version R2 erweitert jetzt die Einsatzmöglichkeiten um Blueprints für das Anbinden vernetzter Fahrzeuge, künstlicher Intelligenz und Augmented Reality.

Im Ökosystem von quelloffener Software für Edge Computing hat Akraino einen integrativen Charakter. Mit seinen Blaupausen verknüpft es quasi die anderen Projekte. Dies gilt ganz besonders für die stark spezialisierten Anwendungsfälle. Wer tiefer einsteigen möchte, sollte sich viel Zeit nehmen und die umfangreiche Dokumentation genau studieren. Die Chancen stehen gut, dass sich ein verwendbares Rezept findet.