NetApp StorageGRID ist ein softwaredefiniertes, objektbasiertes Speicherprodukt, das die verbreiteten Industriestandard-Objekt-APIs unterstützt, inklusive der API für Amazons Simple Storage Service (S3) und der für Open­Stack Swift. Darüber hinaus spricht es mit einer optionalen NAS-Bridge-Appliance auch die Protokolle NFS und SMB. Flexibel sind die Optionen zum Betrieb wahlweise als physische Appliance, virtuelle Maschinen unter VMware sowie als Docker-Container auf Linux-Hosts. Ebenso vielfältig sind die Einsatzmöglichkeiten als Platten-, Cloud- oder Archivspeicher entweder komplett getrennt im eigenen Datacenter oder in einer Hybrid-Cloud-Variante mit einer regelbasierten Auslagerung von Daten in öffentliche Clouds inklusive AWS und Azure. Im Fokus stehen Enterprise-Kunden, die große Mengen an unstrukturierten Daten als unveränderbare Objekte speichern wollen. Beispielsweise archiviert ProSieben­Sat.1 Media seine Inhalte auf einem mehrere PByte großen StorageGRID.

Um es gleich vorwegzunehmen: NetApps StorageGRID ist nicht dazu gedacht, wenige hundert GByte Objektspeicher bereitzustellen. Vielmehr bewegt sich alles im mindestens zweistelligen TByte-Bereich, auch bei der virtuellen Variante für VMware. Wie die Bezeichnung Grid (Gitter, Raster) vermuten lässt, besteht das Produkt aus einem Verbund mehrerer Einheiten. Erforderlich sind mindestens ein Admin-Knoten und drei Speicherknoten. Optional gibt es noch Gateway- und Archiv-Knoten sowie als Zusatz eine NAS-Bridge. Bei einem Aufbau unter VMware vSphere beansprucht jeder Knoten acht vCPU und 24 GByte vRAM. Jeder Speicherknoten benötigt mindestens drei logische Laufwerke (LUN) zu je 4 TByte, das Maximum sind 16 LUNs, die vom Hersteller getestete LUN-Größe beträgt 39 TByte. In der Minimalkonfiguration mit drei Speicherknoten à drei LUNs zu je 4 TByte bedarf es also bereits 36 TByte Plattenkapazität. In Produktionsumgebungen empfiehlt NetApp für jeden Speicherknoten einen eigenen ESX-Host, die anderen Knotentypen können sich einen Host teilen.

In einer Installation an einer Lokation (Site) hat NetApp Konfigurationen mit bis zu 200 Speicherknoten getestet, eine fixe Grenze gibt es nicht. Für noch größere Anforderungen und eine Verteilung über mehrere Standorte gibt es ein Multi-Site-Design. Für zusätzliche Redundanz kann eine Site mehrere Admin-Knoten enthalten, wobei einer immer als Master fungiert. Ebenso sind mehrere Gateway-Knoten möglich. Letztere finden für ein Loadbalancing Verwendung, um den Datenverkehr gleichmäßig auf die Speicherknoten zu verteilen. Getestet hat der Hersteller das Zusammenspiel von bis zu 16 Sites mit einer Kapazität von bis zu 560 PByte.

Beim Netzwerkmodell arbeitet der Verbund mit drei Netzwerken: Grid, Admin und Client – die beiden letzten sind allerdings optional. Wie die Bezeichnungen vermuten lassen, dient das Grid-Netzwerk für die Kommunikation zwischen den Knoten, das Admin-Netzwerk für die Systemadministration und das Client-Netzwerk für die Kommunikation mit anderen Subnetzen, in denen sich die Clientapplikationen befinden.

Bei der Realisierung eines Grids mit physischen Knoten von NetApp startet das kleinste Modell SG5612 mit zwölf NL-SAS-Laufwerken zu je 4 TByte, also insgesamt 48 TByte Rohkapazität. Das größte Modell SG6060 lässt sich auf bis zu 178 Laufwerken und zwei SSDs ausbauen, mit Modellen mit 4, 8, 10 oder 12 TByte Kapazität. Die Maximalkapazität je Knoten beträgt damit 696 TByte. Das SGF6024 ist speziell auf Performance getrimmt und mit 24 SSDs bestückt. Je nach Modell lassen sich pro Knoten 500 bis 750 Millionen Objekte speichern, die eine Cassandra Datenbank verwaltet. Neue StorageGRID-Versionen erhöhen diese Limits sukzessive. Als virtuelle Variante existiert neben der VMware-Unterstützung der Betrieb als Docker-Container unter Linux (RHEL, CentOS, Ubuntu und Debian).

Was unseren Test anbetrifft, wollten wir diesen ursprünglich auf unserer vSphere-Umgebung durchführen, mussten aber schnell erkennen, dass die benötigten Ressourcen den Laborrahmen sprengten. Stattdessen stellte uns NetApp in deren Labor in den USA exklusiv eine vorkonfigurierte Umgebung zur Verfügung, auf der wir agieren konnten.

Unsere Testumgebung bestand aus fünf physischen Systemen in Form eines Admin-Knotens und vier Speicherknoten SG5712. Auch wenn wir aufgrund der Bereitstellung durch NetApp nicht sämtliche Einrichtungsschritte selbst durchführen konnten, haben wir uns trotzdem im Nachhinein mit dem Aufbau beschäftigt und nicht nur das fertige StorageGRID betrachtet. Durch die Einrichtung von NetApp konnten wir zudem davon ausgehen, dass alles optimal konfiguriert war. Schnell mussten wir feststellen, dass die Einrichtung deutlich komplizierter ist als bei der ersten Betrachtung angenommen. Dabei sind diverse NetApp-Features mit eingeflossen mit dem Ziel, die verfügbaren Platten hinsichtlich Kapazität und Performance optimal zu nutzen.

Jeder unserer Speicherknoten SG5712 war mit zwölf Nearline-SAS-Festplatten zu je 8 TByte bestückt. Alle Knoten verfügten intern über je zwei Controller. Der eine übernimmt das Platten-Handling mit der NetApp-eigenen Software "SANtricity Storage Manager", auf dem anderen Controller läuft die StorageGRID-Software. SANtricity ist für den Zweck der Speicherbereitstellung Performance-optimiert bei gleichzeitig einfacher Administration und stellt quasi eine erste Konfigurationsebene dar. Die Software nutzt die NetApp-Technologie Dynamic Disk Pools (DDP), die unter anderem den Zweck verfolgt, alle verfügbaren Festplatten gleichmäßig einzusetzen, sodass sich die Datentransfers für eine bestmögliche Performance entsprechend verteilen. Außerdem sorgt sie für Redundanz, um einen Festplattenausfall ohne Datenverlust zu überstehen und einen Rebuild möglichst schnell durchführen zu können.

Im vorliegenden Fall hatte NetApp die zwölf Platten zu einem Pool konfiguriert und darauf 18 Volume-Gruppen definiert, 16 davon zu je 4,2 TByte für die Datenspeicherung, sodass jeder Knoten eine Nutzkapazität von 68 TByte lieferte. Von der Redundanz her ist die Konfiguration vergleichbar mit einem RAID-6 mit Hot Spare. Letztlich können zwei Festplatten zeitgleich ausfallen und eine dritte zeitlich versetzt, ohne dass es im Host zu einem Datenverlust kommt. Jeder Speicherknoten stellt somit für sich betrachtet einen gegen einzelne Plattenausfälle geschützten und durch Lastverteilung optimierten, performanten Datenspeicher zur Verfügung.

Aufgrund der vier Speicherknoten zu je 68 TByte Nutzkapazität hatte unser StorageGRID eine Gesamtgröße von rund 270 TByte, was in einer WebGUI, dem StorageGRID Manager, auf dem Dashboard angezeigt wurde. Dieser Manager ist das zentrale Verwaltungstool eines Verbunds aus mehreren Datenknoten mit Mandantenverwaltung, Protokollkonfiguration, Berechtigungsvergabe und dem wichtigen Information Lifecycle Management (ILM). Das ILM ist nach dem Speicherknoten-bezogenen SANtricity eine weitere Ebene, um die Knoten- sowie Site-übergreifende Datenablage zu steuern und die gewünschten Redundanzen festzulegen. Darauf gehen wir weiter unten noch im Detail ein.

Der zentrale StorageGRID Manager läuft auf dem Admin-Knoten und beim Aufruf gelangt der Administrator auf ein Dash-board, das die wichtigsten Betriebsdaten auf einen Blick anzeigt. Das sind der Status zur Gesundheit der Systeme mit eventuellen Alarmmeldungen, die aktuelle Speicherbelegung, die S3-/Swift-Protokollnutzung und Informationen zu den aktuellen ILM-Operationen. Über kleine Schaltflächen auf dem Dashboard lassen sich grafische Verläufe aufrufen. Dabei ist jede Schaltfläche mit einer Darstellung vorbelegt, es handelt sich aber in allen Fällen um eine Ansicht mit einem Pull-Down-Menü mit knapp 50 vorbereiteten Auswertungen. Für jede kann der Administrator ein vorbereitetes Zeitintervall wählen oder ein individuelles Start- und Ende-Datum angeben.

In der Kopfzeile der GUI befinden sich neben der Dashboard-Ansicht sieben weitere Reiter. Hier kann der Administrator die Alarme genauer einsehen und filtern sowie einen E-Mail-Versand einrichten. Unter dem Reiter "Nodes" findet er eine Topologie der eingerichteten Knoten mit diversen Grafiken zur Auslastung sowie zum Datenverkehr. "Configuration" enthält eine Vielzahl an Untermenüs gegliedert in System Settings, Monitoring und Access Control zur Verwaltung der administrativen Benutzer. Unter "Maintenance" finden sich Punkte zur Erweiterung des Grids, zur Wiederherstellung und zur Dekommissionierung einzelner Knoten, weiterhin einige Netzwerkeinstellungen und die Möglichkeit zum Einspielen von Updates sowie die Lizenzverwaltung. Der Reiter "Support" enthält diverse Tools, die bei Problemen und für Analysen zum Einsatz kommen. Er zeigt viele technische Detailinformationen an. Außerdem ist die Open-Source-Software Grafana für detaillierte Metriken integriert. Auf die beiden verbleibenden Reiter "Tenants" zum Anlegen von Mandanten sowie "ILM" für die ILM-Einrichtung gehen wir noch genauer ein.

Im laufenden Betrieb dürfte der StorageGRID Manager nur selten zum Einsatz kommen. Bei der Einrichtung ist es wichtig, das ILM richtig zu konfigurieren, im Normalbetrieb sollten sich die Arbeiten dann in erster Linie auf die Mandantenverwaltung beschränken. Berichte kann sich der Administrator zusenden lassen, außerdem lässt sich eine Call-Home-Funktion einrichten, genannt AutoSupport, sodass StorageGRID bei Problemen direkt bei NetApp Tickets eröffnet. Standardmäßig sendet das System einen wöchentlichen Statusbericht sowie anlassbezogen bei signifikanten Ereignissen.

Die volle Funktionsvielfalt der Konsole zeigt sich vor allem bei einer Problembearbeitung. Für eine Auswertung ist eine Vielzahl an Übersichten und tiefgreifender Analysemöglichkeiten integriert, viele davon sehr speziell für die Nutzung durch den NetApp-Support. Der Hersteller legt offensichtlich sehr viel Wert auf umfassende Informationen über die GUI. So kann auch der Administrator viel über den Systemzustand erfahren und die Performance prüfen, ohne sich mit der Kommandozeile beschäftigen zu müssen.

Das ILM spielt eine überaus wichtige Rolle bei der Organisation der Datenablage. Dies umfasst sowohl Redundanzen als auch die Möglichkeit, Daten aufgrund von Eigenschaften des StorageGRID beispielsweise auf einen Archivspeicher auszulagern. Die Festlegung, wie die Daten über die Knoten verteilt und mit welcher Redundanz sie gespeichert werden, läuft unter dem Begriff Erasure Coding (EC). EC ist mit einer RAID-Definition bei Festplatten vergleichbar und ein geläufiges Verfahren in derartigen Speicherumgebungen, also nicht allein auf StorageGRID beschränkt. Dennoch wollen wir genauer darauf eingehen. Wir hatten schon oben erwähnt, dass jeder Knoten gegen einen Datenverlust beim Ausfall einzelner Datenträger geschützt ist, beim EC geht es nun um den Ausfall ganzer Hosts oder gar einer kompletten Site in einer Multi-Site-Installation.

Eine StorageGRID-Site erfordert mindestens drei Speicherknoten, empfohlen werden vier. Erst bei vier Knoten ist es möglich, einzelne Knoten beispielsweise bei einem Systemupdate temporär in Wartung zu nehmen, ohne dass die Funktion des Grids eingeschränkt ist. Hintergrund ist, dass bei Änderungen die Metadaten mindestens dreimal in die dazu genutzte Cassandra-Datenbank geschrieben werden müssen. Würde bei nur drei Knoten einer nicht verfügbar sein, wäre dies nicht mehr möglich und das System ließe nur noch einen lesenden Zugriff zu.

Was das EC anbetrifft, bekamen wir unser StorageGRID mit der Einstellung "Baseline 2 Copies Policy" übergeben. Das bedeutet, dass sämtliche Objekte redundant auf zwei Knoten gespeichert werden, was wiederum in einem Speicher-Overhead von 100 Prozent resultiert. Um diesen Overhead zu reduzieren, gibt es nun unterschiedliche EC-Schemata wie etwa das Schema 2+1, geeignet für unsere Site mit vier Knoten. Das bedeutet, dass jedes zu speichernde Objekt in zwei gleich große Datensegmente geteilt und durch ein drittes Parity-Segment ergänzt wird. Diese drei Segmente werden dann auf drei unterschiedlichen Knoten abgelegt. Fällt einer dieser Knoten aus, lässt sich das Objekt immer aus den beiden verbleibenden Segmenten rekonstruieren. Der Speicher-Overhead beträgt in diesem Fall nur noch 50 Prozent.

Im Fall von mehr verfügbaren Knoten lassen sich diverse andere Schemata definieren. Ein EC von 4+2 beispielsweise benötigt mindestens sechs Speicherknoten, hat ebenfalls einen Overhead von 50 Prozent, verkraftet aber den gleichzeitigen Ausfall von zwei Knoten. Bei einem EC von 6+2 können ebenfalls zwei Knoten wegbrechen, der Overhead liegt hier aber nur bei 33 Prozent. Bei einem EC von 8+2 lässt sich der Overhead schließlich auf 25 Prozent reduzieren. Es werden dazu aber auch acht beziehungsweise zehn Knoten benötigt. Im Administrationshandbuch sind die möglichen EC-Schemata genau aufgelistet, nicht nur für den Einsatz bei einer Site, sondern auch für Installationen mit drei oder mehr Sites, wo dann eine ganze Site ausfallen darf, ohne dass ein Datenverlust entsteht. Die komplexesten Schemata sind 9+3 sowie 7+5 und verteilen die Daten damit auf zwölf Knoten. Das EC 7+5 hat einen relativ hohen Overhead von 71 Prozent, erlaubt aber gleichzeitig den Ausfall einer kompletten Site sowie eines weiteren Knotens in einer anderen Site.

Gut nachvollziehbar ist, dass das EC mit zunehmender Komplexität immer mehr Rechenleistung erfordert, um die Parity-Informationen zu ermitteln, was wiederum Performance kostet. Nachdem sich unter dem Aspekt eines geringen Overheads beispielsweise in unserer Umgebung ein EC 2+1 für Objekte kleiner 200 KByte nicht lohnt, bietet StorageGRID die Möglichkeit, verschiedene EC-Schemata parallel zu nutzen und mit Regeln zu verknüpfen. Wir richteten unser System etwa so ein, dass Dateien kleiner als 200 KByte weiterhin als zwei Kopien gespeichert wurden und nur größere Dateien gemäß 2+1 geteilt und mit einem Parity-Segment ergänzt wurden.

Je nach Performance-Anforderung kann der Administrator den Zeitpunkt der EC-Berechnung vorgeben. Wahlweise kann diese sofort beim Schreiben erfolgen oder nachgelagert. Im letzteren Fall wird zuerst mit zwei Kopien gespeichert und erst anschließend entsprechend des EC verteilt. Über ein mächtiges Regelwerk mit Policies und Rules gibt der Administrator die Arbeitsweise des ILM genau vor, nicht nur anhand von Dateigrößen, sondern auch in Abhängigkeit von Dateityp, genutztem Bucket, Mandant, Zugriffszeit, Tags und Benutzer-Metadaten. Diverse Beispiele sind im Administrationshandbuch zu finden. Insgesamt sind die Möglichkeiten sehr vielfältig und erfordern eine entsprechende Einarbeitung oder Unterstützung durch NetApp, um hier die jeweils optimalen Einstellungen zu wählen.

Für den Nutzerzugriff auf StorageGRID muss der Administrator einen oder mehrere Mandanten mit entsprechenden Credentials anlegen. Die Mandanten sind strikt getrennt und sehen sich nicht gegenseitig. StorageGRID eignet sich daher auch für Serviceprovider, die ihren Kunden einen S3- oder Swift-Speicher anbieten wollen. Wie oben beschrieben ist für jeden Mandanten eine eigene ILM-Regel definierbar, über eine Quota lässt sich die zugewiesene Kapazität steuern.

Jeder Mandant sieht wiederum eine eigene Web-GUI, in der er die benötigten S3-Credentials (Access Key und der Secret Access Key) anlegt. Hier erstellt er auch Buckets mit den gewünschten Einstellungen und hat eine eigene, Mandanten-bezogene Verwaltung mit Benutzern und Gruppen zur Verfügung, über die er die Zugriffe steuert. Pro Benutzer lassen sich wiederum eigene S3-Credentials anlegen, optional mit Gültigkeitsablauf. Beim Anlegen von derartigen Credentials ist es sehr wichtig, sich diese zu notieren beziehungsweise zu speichern, da sie später nicht mehr in der GUI einsehbar sind. Jeder Mandant kann einen Zugriff auf einen externen Endpunkt einrichten, um beispielsweise Daten von StorageGRID auf einen externen Cloudspeicher auszulagern. Er ist damit nicht allein an die Ablage auf StorageGRID gebunden.

Bei der Protokollnutzung liegt der Schwerpunkt bei StorageGRID laut NetApp eindeutig auf S3, weil dies bei den Kunden am meisten nachgefragt ist. OpenStack Swift spielt dagegen aktuell eher eine untergeordnete Rolle. Bezüglich der verfügbaren S3-Funktionen gibt es einen Developers Guide. Ziel ist verständlicherweise eine absolute Komptabilität. Aktuell fehlt die Möglichkeit für einen Object Lock, also eine objektbezogene WORM-Funktion, um dafür zu sorgen, dass einzelne Objekte für einen bestimmten Zeitraum oder dauerhaft gegen Löschen und Überschreiben geschützt sind. Allerdings ist diese Funktion bereits in der Entwicklung und soll mit einer den nächsten Upgrades kommen.

Im Lauf unseres Tests hatten wir die Möglichkeit zu einigen Performancemessungen mit einem Tool namens S3tester, das wir in der Testumgebung auf einem Linux-System installiert hatten. Damit erzielten wir bei Put-Operationen um die 1200 MByte pro Sekunde, bei Get-Operationen gut 1000 MByte pro Sekunde. Der Durchsatz hängt wie erwähnt von der aktiven ILM-Regel ab und skaliert mit der Anzahl der Speicherknoten. Ein einzelner Speicherknoten erzielt laut NetApp einen Durchsatz von um die 400 MByte pro Sekunde. Bezüglich der erforderlichen Leistung ist es auf jeden Fall zu empfehlen, den Durchsatz in einem Pflichtenheft zu definieren, damit NetApp ein passendes Sizing ausarbeiten kann, um dieses dann in einem Proof of Concept zu verifizieren.

Als uns NetApp StorageGRID für den Test bereitstellte, hatte der Anbieter bewusst einen Hotfix nicht mitinstalliert, damit wir die Updatefunktion ausprobieren konnten. Denn jegliche Upgrades und Hotfixes lassen sich komfortabel über den StorageGRID Manager einspielen. Zum Einstieg sind der Pfad zur Installationsdatei anzugeben und eine Passphrase, die bei der Ersteinrichtung festgelegt wurde. Anschließend übernimmt der Manager den gesamten Ablauf. Nachdem unser StorageGRID vier Speicherknoten besaß, konnten wir den Hotfix im laufenden Betrieb ohne Funktionseinschränkung einspielen. Zuerst wurde der Admin-Knoten aktualisiert und war kurzzeitig nicht erreichbar, was aber keinen Einfluss auf die Datenerreichbarkeit hatte.

Anschließend aktualisierte das System einen Speicherknoten nach dem anderen, wobei wir den Fortschritt auf der GUI genau verfolgen konnten. Abschließend mussten wir noch einige Fehlermeldungen quittieren, weil die Knoten kurzzeitig nacheinander nicht erreichbar waren und wir den Hinweis ignoriert hatten, die Alarme vor so einer Aktion auf "silent" zu stellen. Insgesamt lief das Einspielen des Hotfixes erfreulich unspektakulär ab, so wie sich ein Administrator das im Idealfall wünscht.

Sehr gut gefallen hat uns im Test die zu StorageGRID erhältliche, überaus umfangreiche Dokumentation. Die Anleitung spricht die einzelnen Bereitstellungsarten als physische Appliances an, als VMs sowie als Docker Container. Weiterhin gibt es einen Abschnitt zu den Optionen wie der NAS-Bridge für die Nutzung mit dem NFS- und SMB-Protokoll. Grob beschrieben sind das Erasure Coding und das gesamte Datenmanagement sowie der Grid Manager. Deutlich tiefer in die Materie steigt der 330 Seiten starke Administrations-Guide ein.

Gut gefallen hat uns an StorageGRID der insgesamt redundante Aufbau mit der Möglichkeit zur Anpassung an den individuellen Bedarf. Dies beginnt bei jedem Speicherknoten inklusive einer guten Lastverteilung über die genutzten Speichermedien und wird durch das integrierte Erasure Coding übergreifend fortgeführt, sodass sich beim Ausfall einzelner Speicherknoten oder auch einer ganzen Site ein Datenverlust verhindern lässt.

Die Handhabung im laufenden Betrieb empfanden wir als erfreulich übersichtlich, allerdings ist es dringend zu empfehlen, mit einem Konzept mit Unterstützung des Herstellers zu starten, damit das Produkt die gestellten Anforderungen an die Performance und Verfügbarkeit erfüllt. Das ist unserer Meinung nach im Alleingang kaum zu bewerkstelligen. Im Betrieb liefert die GUI umfassende Informationen zum Systemstatus und ermöglicht mit integriertem Grafana detaillierte Lastanalysen.

StorageGRID ist mandantenfähig und eignet sich damit auch hervorragend als Plattform für Serviceprovider, die ihrerseits den Kunden einen S3- oder Swift-Speicher anbieten wollen. Auch eine Kombination mit Speicher in der Cloud ist möglich, wobei sich die Datenauslagerung durch Regeln gut einrichten lässt. Durch die genannte Protokollunterstützung ist StorageGRID sehr breit einsetzbar und mit vielen Apps nutzbar.