Die Entwickler von DataCore haben wesentliche Elemente der im Vorspann angesprochenen Storage-Abstraktion bei Swarm auf einen Objektspeicher übertragen. Dieser unterscheidet sich von den traditionellen Dateispeichern über NFS oder SMB dahingehend, dass es sich um die bewusste Ablage im unstrukturierten Format handelt und eine flache Hierarchie zur Anwendung kommt. Während Dateiablagen meist über Verzeichnisse und Ordner strukturiert sind, arbeiten Objektspeicher mit großen Speicherbereichen, den sogenannten "Buckets". Alle erforderlichen Merkmale, wie beispielsweise eine Zugriffsberechtigung, speichert das System als Metainformation.

Strukturell betrachtet besteht ein Swarm aus drei verschiedenen Ebenen. Ganz unten in dem Konstrukt befinden sich die Speicherknoten. Hierbei handelt es sich um die Server, die den eigentlichen Speicherplatz zur Verfügung stellen. Konzeptionell handelt es sich um beliebige x86/x64-Maschinen, auf denen ein kleines Linux-Betriebssystem zur Anwendung kommt. Ob diese einzeln rotierende Festplatten, NVMe/SSDs oder RAID-Plattenverbünde bieten, ist für Swarm unerheblich. Die Speicherknoten weist die übergeordnete Ebene als "Hardware" einem Cluster zu. Enthält ein Cluster nur einen einzigen Hardwareserver, liegt bei einem Ausfall dieser Maschine folglich auch der gesamte Speicherbereich brach.

In der zweiten Ebene befindet sich die Management- und Zugriffsstruktur. Dies ist typischerweise eine virtuelle Maschine und besteht aus einem oder mehreren Elastic-Search-Servern. Diese Maschinen speichern, auf welchen Speicherknoten sich welche Daten befinden. Die "Content Gateway"-Maschinen realisieren den Datenzugriff für Nutzer und Anwender über HTTP, HHTPS oder S3 und stellen gleichzeitig das "Content Portal" und die Storage-UI bereit. Ein wenig Plattform drumherum ist noch erforderlich – hierfür arbeiten die SCS (Swarm Cluster Services) für PXE, Konfigurationsmanagement, Logging, DHCP und NTP.

Auch ohne eine leistungsstarke und umfangreiche Storage-Testumgebung ist es möglich, sich mit DataCore Swarm zu beschäftigen und die Grundkonzepte und Bedienungselemente selbst anzuwenden. Im einfachsten Fall nutzt der Administrator hierzu eine speziell zur Demonstration vorbereitete Docker-Umgebung, die sich ohne viel Aufheben auf Ubuntu oder CentOS einrichten lässt.

Wir wählten für unseren Test CentOS und installierten gemäß der Dokumentation "Swarm2Go: Workbook Hands-on Lab for CentOS" die Version 7.9 der Distribution auf einem PC mit VMware Workstation. Mit vier CPU-Kernen und 16 GByte RAM und 100 GByte Storage war die Installation kein Hexenwerk. Nach der Installation von Linux folgte die Eingabe einiger Kommandos, die ein Windows-naher Administrator idealerweise per PowerShell-Fenster oder über Putty auf der Konsole zur Ausführung bringt. Schlussendlich wurde das System aktualisiert, Docker eingerichtet, der Parameter "vm.max_map_count" erhöht und die Swarm-Container direkt über AWS auf den lokalen PC heruntergeladen. Nach zwei Reboots und Prüfungen war alles fertig – der Gesamtvorgang dauerte rund eine Stunde.

Das Hauptwerkzeug des Administrators bei der Steuerung von DataCore Swarm ist der Browser. Wir nutzten für unsere Betrachtung Google Chrome und konnten zu keiner Zeit irgendwelche Anomalien bei der Darstellung oder der Bildaktualisierung feststellen. Meldet sich der Administrator über den Browser-Zugriff auf der IP-Adresse oder dem DNS-Namen der Maschine an, erscheint ein Zwischenmenü, das entweder in die Menüs für "Storage Management" oder in das "Content Management" verzweigt.

Unser erster Weg führte in den Verwaltungsbereich für den Storage. Die Menüstruktur ist hier wie im gesamten Produkt klar gegliedert und klassisch aufgebaut. Auf der linken Seite findet sich eine Baumstruktur, die jeweils in die Untermenüs verzweigt. Durch einen Klick auf das "Hamburger-Menü" konnten wir die Menübezeichnung ausblenden, um Platz zu sparen. Oben am rechten Bildschirmrand ist der Name des Benutzers zu sehen. Dahinter verbirgt sich das Menü für den Wechsel der Bildschirmsprache zwischen Deutsch, Englisch, Spanisch, Französisch und Chinesisch sowie die Möglichkeit zur Abmeldung und der Zugriff auf die Support- und Dokumentationsseiten. Die Produktdokumentation ist, aufgrund ihres Umfangs und ihrer technischen Tiefe, als besonders gut hervorzuheben.

In unserer kleinen Demoumgebung fanden sich bereits drei Speicherknoten im Cluster. Die drei Maschinen haben jeweils drei Platten und bieten jeweils 9,4 GByte Speicherplatz, der für unterschiedliche "Streams" genutzt wird. Die Verteilung dieser Streams übernimmt die Software selbständig. Sollte der Administrator einmal gezwungen sein, einen Speicherknoten in den Wartungsmodus zu versetzen oder gar in den Ruhestand zu schicken, prüft Swarm die Kapazität der verbleibenden Speicherknoten und überführt die Daten dorthin. Die Dokumentation spricht hier von "Selbstheilungsfähigkeit" – klingt zwar ein wenig großspurig, ist aber auch irgendwie passend. Durch eine räumliche Verteilung von Speicherknoten und eine sinnvolle Steuerung der Synchronisation waren wir in der Lage, eine äußerst sichere Speicherumgebung aufzubauen.

Alle Darstellungen auf der Seite sind mit grafischen Elementen von Grafana aufgewertet und erlaubten ein Durchklicken auf die jeweiligen Menüs. Alle typischen Befehle, wie das Setzen des Loglevels, das Zurücksetzen der Logging-Einträge, um den Status auf "Grün" zu bekommen, oder erforderliche Befehle, beispielsweise um einen Speicherknoten über "Retire" aus dem Cluster-Verbund zu entfernen, fanden wir direkt in der Oberfläche – zumeist hinter einem "Zahnrad"-Symbol. Wenn es um detaillierte Einstellungen und Parameter geht, enden Komfort und hübsche Darstellung jedoch. Die Settings des Clusters umfassen hunderte von Konfigurationswerten, die eher an die Variablenbenennung eines Entwicklers erinnern denn an eine Konfigurationsoberfläche – "health. neonatalExamThreads" mit dem Wert "4" wäre hierfür in der Rubrik "Health" ein passendes Beispiel. Bei "health.verifyAfterWrite", mit den Optionen "true" und "false", kann sich der IT-Profi ganz sicher vorstellen, um was es sich handelt. Hier, in diesen Tiefen, mit rund 250 Parametern enteht der eigene Swarm erst wirklich. Natürlich finden sich hier auch selbstsprechende Merkmale, wie beispielsweise der RO-SNMP-Community-String.

Der Lese- und Schreibzugriff auf den Objektspeicher gelingt im einfachsten Fall über den Menüpunkt "Storage Content" direkt über die Weboberfläche von Swarm. Der Administrator oder eingerichtete Benutzer kann sich über die Oberfläche auf den gewünschten Cluster und Bucket durchklicken und Dateien hoch- oder herunterladen. Typischerweise geschehen diese Arbeitsschritte automatisiert über die S3/HTTPS-Kompatibilität der API. Entsprechende Kenntnisse der jeweils genutzten Automatisierungssprache sind somit erforderlich.

Dank der weiteren Abstraktionsebenen, die Swarm mit sich bringt, war das Einhängen weiterer Speicherserver in einen Cluster denkbar einfach. Wie bereits erwähnt, verspricht der Hersteller, dass dies in 90 Sekunden erledigt ist und dies konnten wir auch verifizieren. Es kommt darauf an, welchen Teil des Vorgangs wir bei den 90 Sekunden berücksichtigen. Es geht wirklich sehr schnell – auch mit einem ganzen Server. Nicht unerwähnt bleiben sollte jedoch, dass hierzu gewisse Vorarbeiten erforderlich sind, die gewiss nicht in den wenigen Sekunden erledigt sind.

Im Storage-Netzwerk, in dem die Speicherserver für Swarm aktiv sind, sollte, um sich in dem oben benannten Zeitrahmen zu bewegen, ein DHCP/PXE-Boot-server-Gespann vorgehalten sein, das beim Start eines neuen Servers mit der Bereitstellung des speziell vorbereiteten Boot-Images für Swarm reagiert. In unserem Test handelte es sich um eine leere VM, der das passende Netzwerk, zwei vCPUs und 8 GByte RAM zugewiesen wurde. 64 GByte Storage gaben wir dem Beispielserver mit auf den Weg. Nach dem Einschalten installierte sich das vorbereitete CentOS. Der Plattformserver – der Swarm Cluster Service – hat durch das Zusammenspiel mit dem PXE somit Kenntnis von der neuen Maschine.

Wer nur ein wenig Speicherplatz zur Verfügung stellen will oder eine geringe Datenmenge in einen S3-artigen Bucket speichern möchte, für den ist Swarm sicherlich nicht das passende Produkt. Insgesamt zeigen sich die wahren Fähigkeiten von Swarm erst im konkreten An- wendungsfall, in dem es typischerweise darum geht, dass eher statische, also unveränderliche Daten für einen kostengünstigen Preis stets kontrolliert und überwacht im Dauerzugriff bleiben. Anders als beispielsweise bei Bändern ist ein Dauerzugriff gewährleistet. Letztendlich funktionier Swarm wie ein öffentlicher S3-Cloudspeicher, jedoch im eigenen Rechenzentrum und unabhängig von unvorhersehbaren Preisanstiegen, die es bei den großen Cloudanbietern ja auch schon gab.

Im Zusammenspiel mit dem Tool "FileFly" können Administratoren Dateien von ihren Windows File-Servern, NetApp- oder Dell-Ems-Isilon-Systemen anhand von Regelwerken auf den Objektspeicher verschieben, um die Primärspeicher zu entlasten. Die Software stellt dabei sicher, dass der Verweis, der so genannte File Stub, auf dem Primärspeicher dem Anwender das lokale Vorhandensein vorgaukelt, sodass sich aus der Nutzerperspektive nichts verändert außer der Zugriffsgeschwindigkeit.

Ansonsten eignet sich Swarm für alle Archivanwendungen, bei denen große Datenmengen mit relativ wenig Lesezugriffen vorgehalten werden müssen. Beispielsweise zu nennen wären hier medizinische Befunddaten wie PACS-Bilder, Scan-Dokumente oder auch Produktionsdokumentationen. Auf der Liste der explizit genannten Backupwerkzeuge, die mit Swarm zusammenarbeiten, finden sich Namen wie Veeam, Veritas, Commvault, Catalogic, Rubrik und Atempo.

Anders als bei unserem Test üblich, reicht es bei Swarm nicht, den Preis nur im Produktkasten offenzulegen, denn die Kosten eines solchen selbstdefinierten Objektspeichers mit Swarm beeinflussen viele Faktoren. Dabei liegt der Großteil der Variabilität nicht in den Gebühren für die Software selbst, sondern darin, welche möglichen Ausfälle der Administrator durch eine entsprechende Hardwarekonfiguration auffangen möchte. Der Preis der Software richtet sich ausschließlich nach der nutzbaren Kapazität in TByte. Dies ist völlig unabhängig davon, welches Erasure-Coding-Schema angewandt wird oder wie viele Kopien aus Verfügbarkeitsgründen der IT-Profi vorhalten will. In einem Zahlenbeispiel ausgedrückt: Ein Administrator hat Dateien, die 100 TByte Speicherplatz benötigen. Sollen zusätzlich zu den 100 TByte aus Verfügbarkeitsgründen drei Kopien vorgehalten werden, ist die Software-Lizenz für 100 TByte erforderlich, jedoch Hardware für 400 TByte vorzuhalten.

Für eine konkrete Preisangabe bedarf es zweier Beispielkonfigurationen – einer kleinen Swarm-Umgebung mit 20 TByte nutzbarer Kapazität und einer größeren Variante mit 500 TByte. Die Serverhardware wurde mit marktüblichen Standardkaufpreisen ermittelt, die Software mit einer Lizenz für ein Jahr. Ein Server mit Swarm und 20 TByte nutzbarer Kapazität, die für 60 Prozent dieser Kapazität ein Erasure-Coding-Schema von 4:2 bietet und für die verbleibenden 40 Prozent der Daten zwei zusätzliche Replikate anlegt, kostet rund 20.000 Euro. Mit dieser Konfiguration kann bei voller Ausnutzung der 20 TByte eine beliebige Platte ausfallen und die Daten würden entsprechend der zuvor angeführten Schutzmechanismen automatisch auf die verbleibenden Festplatten verteilt. Anders formuliert kostet so eine Konfiguration im ersten Jahr 5,66 Cent pro GByte pro Monat.

Bei einer größeren Swarm-Infrastruktur mit 500 TByte nutzbarer Kapazität sind wir exemplarisch von demselben Era-sure-Coding-Schema (4:2) für 75 Prozent der Daten ausgegangen. Die verbleibenden 25 Prozent nutzt der IT-Profi in diesem Beispiel für zwei weitere Replikate. Das Beispiel basiert auf sechs separaten Servern und geht davon aus, dass einige Management-VMs in der vorhandenen VMware-Umgebung zur Ausführung kommen. In dem Fall liegen die Gesamtkosten bei zirka 139.706 Euro. Bei voller Belegung mit 500 TByte an Dateien kann hier ein beliebiger Server komplett ausfallen oder fängt den Ausfall von bis zu 13 Festplatten wieder auf. Das dazu erforderliche Mehr an Hardware ist bereits berücksichtigt und bei einem Ausfall von Komponenten stellt Swarm auch hier die Daten entsprechend den vorgenannten Schutzmechanismen automatisch wieder her. Mit dieser größeren Swarm-Konfiguration entstehen im ersten Jahr Kosten von 2,33 Cent pro GByte pro Monat.

Bei beiden Beispielrechnungen ist zu berücksichtigen, dass die Hardwarekosten einmalig anfallen, die Laufzeit der Hardware jedoch deutlich länger als das erste Jahr ist, was den Preis pro GByte und Monat merklich senkt. Im direkten Vergleich mit Amazon, Google oder Microsoft für Cloudspeicher ergeben sich im ersten Jahr somit vergleichbare Werte, jedoch ohne die stete Sorge, dass durch Zugriffe die Kosten unkontrolliert wachsen.

Swarm ist eines dieser Systeme, bei denen die umfassende Bewertung schwerfällt. Im Test überzeugte das Zusammenspiel der Softwarekomponenten ohne jeden Zweifel und alles lief genau so, wie es soll. Ganz salopp ließe sich feststellen, dass mit Swarm der Aufbau und das Management eines S3-kompatiblen Objektspeichers im eigenen Netzwerk problemlos gelingt. Wie beim Original-S3 von Amazon haben IT-Verantwortliche einen flexiblen und leistungsfähigen Speicherbereich, mit dem sie ihre Storage-Anforderungen umsetzen können.

Wie das Gesamtkonstrukt am Ende aussieht, kommt einzig auf den Anwendungsfall an. Der eine IT-Profi will "kalte Daten" mithilfe einer Software vom teuren Hochleistungs-Storage entfernen und benötigt hierfür einen günstigeren Speicherplatz, den er mit Swarm aufbauen kann. Ein anderer Administrator ist es leid, sich immer wieder von LTO-Generation zu LTO-Generation mit dem Umkopieren von Bändern zu kasteien, und stößt bei der Suche nach einem günstigeren Speichersystem auf die S3-Kompatibiltiät. Letztendlich eignet sich das System grundsätzlich für alle objektorientierten Speichervorgänge. Aus unserer Sicht sind das Archiv oder Ablage von unveränderlichen Daten ein primäres Einsatzgebiet.