Nextcloud und Nimble: Wenn die private Cloud auf Enterprise-Storage trifft

Wer heute eine Nextcloud für mehr als ein paar Dutzend Nutzer betreibt, landet früher oder später bei einer Frage, die sich nicht mehr mit Konfigurationsdateien allein beantworten lässt: Wo liegen die Daten – und wer garantiert, dass sie dort auch morgen noch liegen? Die erste Hälfte dieser Frage führt in die Anwendungslogik, die zweite in die Speicherschicht. Und in der Speicherschicht taucht in mittelständischen Rechenzentren seit Jahren immer wieder ein Name auf, der offiziell eigentlich gar nicht mehr existiert: Nimble Storage.

Die Kombination klingt zunächst ungewöhnlich. Auf der einen Seite eine quelloffene Collaboration-Plattform, die von einem deutschen Unternehmen mit Wurzeln in der ownCloud-Community entwickelt wird. Auf der anderen Seite ein All-Flash-Array, das 2017 für rund eine Milliarde Dollar an HPE ging und heute unter dem Label Alletra weiterlebt – während der Name Nimble in Administratorenkreisen hartnäckig überdauert. Nicht zuletzt, weil das Betriebssystem NimOS, die Snapshot-Logik und die Anbindung an die Telemetrieplattform InfoSight bis heute in den aktuellen Geräten stecken.

Ein interessanter Aspekt ist dabei: Die beiden Welten teilen mehr, als die Marketingabteilungen beider Seiten zugeben würden. Nextcloud ist im Kern ein dateibasiertes System, das metadatenlastige Zugriffsmuster erzeugt. Nimble ist ein Blockspeichersystem, das genau für solche Muster gebaut wurde – viele kleine, zufällig verteilte I/O-Operationen, die intern in sequenzielle Schreibvorgänge umgeformt werden. Das passt zusammen. Es passt aber nicht automatisch. Und es gibt eine ganze Reihe von Details, an denen der schönste Storage-Cluster nichts mehr rettet, wenn die Anwendungsschicht nicht mitspielt.

Nextcloud: Was die Plattform heute leistet – und was sie verlangt

Nextcloud begann 2016 als Fork von ownCloud, ausgelöst durch einen Streit über die Ausrichtung des Projekts und die Rolle der Community. Gut acht Jahre später ist daraus eine Plattform geworden, die deutlich mehr ist als ein Dateiaustausch. Neben Files gehören heute Kalender, Kontakte, Aufgaben, Deck, Talk und eine Reihe weiterer Anwendungen zum festen Bestandteil des sogenannten Hub. Die Office-Integration läuft typischerweise über Collabora Online oder OnlyOffice, beides ebenfalls Open Source, beides mit eigenen Anforderungen an Speicher und Latenz.

Für den Betrieb entscheidend ist die Erkenntnis, dass Nextcloud kein monolithisches Stück Software ist, das man einfach auf einen Webserver legt und dann vergisst. Eine produktive Instanz besteht heute in der Regel aus mindestens vier Komponenten: einem Webserver (üblich sind nginx oder Apache), einer PHP-Laufzeit mit Opcache und einem process manager, einer Datenbank und einem In-Memory-Cache. Hinzu kommen optionale Bausteine wie Elasticsearch für die Volltextsuche, Redis für File-Locking und Session-Handling, ein Virenschutz über ClamAV sowie ein Reverse Proxy für TLS-Terminierung und Lastverteilung.

Die Wahl der Datenbank ist dabei keineswegs beliebig. SQLite mag für eine Testinstanz auf dem Raspberry Pi ausreichen, im Produktivbetrieb ist sie ein Fehler, den man meist erst merkt, wenn zwanzig Clients gleichzeitig synchronisieren. MariaDB und PostgreSQL sind die realistischen Optionen. PostgreSQL hat in größeren Umgebungen leichte Vorteile bei Nebenläufigkeit, während MariaDB oft einfacher zu administrieren ist. Wer sich für eine der beiden entscheidet, sollte die Datenbank nicht auf demselben Server wie die Anwendung laufen lassen, wenn mehr als ein paar Hundert Nutzer zu erwarten sind.

Ein Punkt, der in Einführungsprojekten gerne unter den Tisch fällt: Nextcloud ist nicht bandbreitenhungrig, sondern metadatenhungrig. Ein einzelner Upload eines 4-GB-Videos ist für die Speicherschicht völlig unspektakulär – es entstehen wenige, dafür große Schreibvorgänge. Der eigentliche Stress entsteht, wenn hunderte Clients gleichzeitig ihre Änderungslisten abgleichen, für jede Datei ein ETag geprüft wird, die Datenbank tausende kleine Leseoperationen fährt und im Hintergrund Thumbnails, Vorschaubilder und OCR-Ergebnisse erzeugt werden. Genau diese Muster sind es, die einen Storage differenzieren, nicht die sequenzielle Bandbreite.

Die Architektur hinter der Oberfläche

Nextcloud speichert Dateien nicht als Blobs in der Datenbank, sondern im Dateisystem – jedenfalls im klassischen Setup. Daneben existiert die oc_filecache, eine mächtige Tabelle, die den kompletten Verzeichnisbaum mit Pfaden, Größen, Änderungszeitpunkten, ETags und File-IDs spiegelt. Wer einmal erlebt hat, wie lange ein occ files:scan --all auf einer Instanz mit mehreren Millionen Dateien läuft, weiß, warum diese Tabelle in der Fachliteratur gerne als das eigentliche Herz der Plattform beschrieben wird.

Für den Speicher hat das eine wichtige Konsequenz: Nextcloud schreibt viele kleine Dateien, aber es liest vor allem Metadaten. Das Verzeichnislayout ist bewusst so gestaltet, dass pro Nutzer ein eigener Ordner entsteht, in dem die eigentlichen Daten liegen. Vorschauen werden getrennt abgelegt, ebenfalls nutzerspezifisch, und können bei aktivierter Vorschaugenerierung erheblichen Platz einnehmen – je nach Nutzungsprofil zwischen fünf und fünfzehn Prozent des Datenbestands.

Als Primärspeicher kennt Nextcloud im Wesentlichen drei Optionen. Am einfachsten ist das lokale Dateisystem, also eine Partition oder ein Logical Volume auf einem Server oder einer VM. Etwas klassischer ist ein NFS-Mount von einem NAS oder einer Storage-Appliance. Und seit einigen Jahren gewinnt Object Storage nach S3-API an Bedeutung – Nextcloud kann ein S3-Bucket als primären Speicher nutzen, optional mit einem lokalen Cache-Verzeichnis, um die Latenz bei häufigen Zugriffen zu reduzieren. Jede dieser Optionen hat ihre Berechtigung, keine ist universell überlegen. Wer mit Enterprise-Storage arbeitet, landet in der Regel bei einer Mischung aus Block und NFS, und genau hier kommt Nimble ins Spiel.

Nimble Storage: Herkunft, Technik, Gegenwart

Nimble Storage wurde 2008 in San José gegründet, von Ingenieuren mit Wurzeln bei Data Domain und NetApp. Die zentrale Idee war die sogenannte CASL-Architektur – Cache Accelerated Sequential Layout. Sie kombiniert NAND-Flash als Lese- und Schreibcache mit klassischen Festplatten im Backend und sorgt dafür, dass zufällige Schreiboperationen aus Sicht des Backends zu großen sequenziellen Strömen werden. Das war zu einer Zeit, als reine All-Flash-Arrays noch unbezahlbar waren, ein cleverer Trick. Als Flash-Preise fielen, wurde aus dem Hybridkonzept schnell ein reines Flash-Produkt – die AF-Serie.

Viel wichtiger als die Medienfrage ist aber, was Nimble drumherum gebaut hat. Da wäre zum einen das Snapshot-Modell: Snapshots sind grundsätzlich pointer-basiert, kosten kaum Platz, wenn sich Daten nicht ändern, und lassen sich in Sekundenbruchteilen anlegen. Sie sind nicht als Ersatz für Backup gedacht, sondern als Betriebswerkzeug, und genau so sollte man sie einsetzen. Zum anderen wäre da InfoSight, eine Telemetrie-Plattform, die ursprünglich alle Arrays nach Hause telefonieren ließ und aus den gesammelten Daten Fehlerbilder erkannte, bevor sie auftraten. HPE hat das System nach der Übernahme auf das eigene Portfolio ausgedehnt; es gilt bis heute als eines der stärksten Argumente für die Plattform.

Auf der Habenseite stehen außerdem eine ausgereifte Multipath-Unterstützung über iSCSI und Fibre Channel, Verschlüsselung im Ruhezustand und eine Replikationsfunktion, die Snapshots asynchron auf ein zweites Array spiegelt. Eine klassische Inline-Deduplizierung, wie sie mancher Wettbewerber prominent bewirbt, sucht man bei Nimble vergebens – die Kompression sitzt dafür tief im I/O-Pfad und arbeitet unauffällig im Hintergrund.

Seit 2020 heißt das Ganze dann HPE Alletra 5000 und 6000, wobei die 6000er Serie den All-Flash-Nimble-Nachfolger darstellt. Das Betriebssystem, die Kommandozeile und die Snapshot-Semantik sind geblieben. Administratoren, die seit Jahren mit snapshot-Befehlen und volume-Kommandos arbeiten, werden sich also nicht umgewöhnen müssen. HPE selbst positioniert die Geräte heute als Teil der GreenLake-Strategie, inklusive Storage-as-a-Service-Modellen, bei denen man die Hardware nicht mehr kauft, sondern mietet.

Warum Blockstorage und Nextcloud nicht automatisch Freunde sind

Hier wird es technisch. Nextcloud erwartet im klassischen Setup ein gemeinsam genutztes Dateisystem, wenn mehrere Webserver auf dieselben Daten zugreifen sollen. Ein Blockgerät per iSCSI lässt sich aber nicht einfach von mehreren Hosts gleichzeitig beschreiben – jedenfalls nicht ohne ein Cluster-Dateisystem wie GFS2 oder OCFS2, das in der Praxis nur wenige Administratoren wirklich betreiben wollen. Also bleibt man bei einem Modell, in dem ein Host das LUN hält und alle anderen über NFS darauf zugreifen. Das ist die klassische Konstellation: Nimble präsentiert ein Volume per iSCSI an einen dedizierten Storage- oder Anwendungsserver, dieser formatiert es mit XFS oder ext4, und stellt es per NFS im Netz bereit.

Wer stattdessen auf virtuelle Maschinen setzt – und das ist heute der Regelfall –, präsentiert das Nimble-Volume per iSCSI an die ESXi- oder Proxmox-Hosts und legt darüber ein VMFS- oder LVM-Volume an. Aus Sicht der Nextcloud-VM ist das dann ein ganz normales lokales Blockgerät, das sich mit XFS formatieren und als datadirectory nutzen lässt. Dieser Weg ist administrativ am einfachsten und in vielen Umgebungen die pragmatische Wahl.

Ein dritter Weg führt über Kubernetes. Nextcloud lässt sich containerisiert betreiben, und mit dem HPE-CSI-Treiber können Nimble- und Alletra-Volumes dynamisch an Pods gebunden werden. Allerdings liefert der CSI-Treiber primär RWO-Volumes – also „read write once“, für einen Node gleichzeitig. Für eine mandantenfähige Nextcloud-Instanz mit mehreren Pods braucht man daher zusätzlich einen RWX-fähigen Speicher, in der Praxis häufig einen NFS-Server-Provisioner, der die Block-Volumes wieder als NFS-Export bereitstellt. Wer hier naiv rangeht, baut sich schnell eine Lösung, die im Lasttest auseinanderfliegt.

Man muss es deutlich sagen: Der Umweg über NFS kostet Performance, und das nicht zu knapp. Wer auf einer Nimble-All-Flash-Kiste 200.000 IOPS zur Verfügung hat und dann alles über einen NFS-Server mit einzelnen 10-GbE-Links schleust, verschenkt einen großen Teil des Potenzials. In der Praxis ist das häufig trotzdem akzeptabel, weil Nextcloud selbst der Flaschenhals ist – aber es lohnt sich, die NFS-Schicht sorgfältig auszulegen: Anzahl der Threads, Read-Ahead, TCP-Puffer, NFS-Version (Version 4.1 oder 4.2, mit pNFS nur in Ausnahmefällen) und ein saubere MTU-Konfiguration bis hin zu Jumbo Frames.

Drei Wege, Nextcloud auf Nimble zu betreiben

Faustregel: Je größer die Instanz, desto eher lohnt sich der direkte Weg. Für kleine und mittlere Umgebungen mit wenigen Hundert Nutzern ist die klassische Variante sinnvoll – Nimble-Volume als VMFS-Datastore, darauf die Nextcloud-VM mit XFS. Das ist wartbar, ohne Spezialexpertise zu betreiben, und nutzt die Snapshot-Funktionen über vSphere oder direkt im Array.

Für größere Umgebungen empfiehlt sich ein dediziertes Storage-Gateway: ein Linux-Server, der per Multipath-iSCSI direkt mit dem Nimble verbunden ist, darauf LVM mit XFS, und Nextcloud greift lokal zu, während weitere Webserver per NFS angebunden sind. Hier greifen Snapshot-Konsistenz und File-Locking in einer Weise, die man kontrollieren kann, wenn man weiß, was man tut.

Und dann gibt es die Kubernetes-Fraktion, die mit HPE CSI und einem NFS-Provisioner arbeitet. Das funktioniert, ist aber die Variante mit dem höchsten Betriebsaufwand und dem geringsten Verzeihen von Fehlern. Wer diesen Weg geht, sollte unbedingt mit Lasttests beginnen, bevor die ersten echten Nutzer ihre Clients synchronisieren. Sonst entsteht genau das Szenario, das man vermeiden wollte: eine Storage-Plattform, die nominell überdimensioniert ist, in der Praxis aber durch falsche Konfiguration ausgebremst wird.

Unabhängig vom Weg gilt: Nextcloud sollte seine Daten nicht auf einem einzigen NFS-Mount halten, wenn die Instanz wächst. Die Aufteilung von Datenverzeichnis, Datenbank, Redis-Persistenz und Vorschau-Cache auf getrennte Volumes erlaubt nicht nur bessere Snapshots, sondern auch gezieltere Backups. Ein Vollbackup der 15 TB Nutzerdaten ist nicht dasselbe wie ein Backup der Datenbank, und beides muss man getrennt planen können.

Snapshots als Betriebswerkzeug – mit Vorsicht

Snapshots sind der Punkt, an dem Nimble seine Stärke ausspielt. Ein Snapshot auf einem Nimble-Array dauert Sekundenbruchteile, unabhängig von der Volume-Größe, und belastet das laufende System praktisch nicht. Für einen Nextcloud-Betrieb bedeutet das konkret: Man kann vor einem Update der Plattform einen Snapshot ziehen, das Update durchlaufen lassen, und bei Problemen in wenigen Minuten zurückrollen. Das ist ein enormer Vorteil gegenüber tape-basierten oder rsync-basierten Verfahren.

Allerdings ist ein Nimble-Snapshot immer crash-konsistent, das heißt, er entspricht dem Zustand, den ein plötzlicher Stromausfall hinterlassen würde. Bei modernen Journaling-Dateisystemen wie XFS oder ext4 ist das in der Regel unproblematisch – das Dateisystem wird nach dem Zurückrollen konsistent sein, aber die Datenbank kann durchaus Schreibvorgänge verloren haben, die zum Zeitpunkt des Snapshots gerade im Cache lagen.

Für die Datenbank empfiehlt sich daher ein anderer Ansatz: Entweder man quiesciert die Datenbank vor dem Snapshot mit einem kurzen FLUSH TABLES WITH READ LOCK bei MySQL oder einem pg_start_backup() bei PostgreSQL, oder man sichert die Datenbank getrennt mit einem logischen Dump. In der Praxis hat sich die zweite Variante bewährt: Der Files-Snapshot wird ereignisgesteuert ausgelöst, die Datenbanksicherung läuft als eigener Job, und nach einem Restore gleicht man mit occ files:scan und occ db:add-missing-indices den Zustand wieder ab.

Was Snapshots hingegen nicht leisten, sind langfristige Aufbewahrung und Schutz gegen Katastrophen. Wer eine echte Backup-Strategie braucht, kommt um eine zweite Kopie nicht herum, und das führt uns zum nächsten Abschnitt.

Backup, das nicht in die Falle tappt

Der Satz „Snapshots sind kein Backup“ ist ein Gemeinplatz, und trotzdem wird er permanent ignoriert. Ein Snapshot liegt auf denselben physischen Disks wie das Original. Fällt das Array aus, sind beide weg. Was es braucht, ist eine 3-2-1-Strategie: drei Kopien der Daten, auf mindestens zwei unterschiedlichen Medien, mit mindestens einer Kopie außerhalb des primären Standorts.

Nimble unterstützt diese Strategie auf zwei Wegen. Erstens durch Replikation auf ein zweites Array, idealerweise in einem anderen Brandabschnitt oder Rechenzentrum. Die Replikation ist asynchron, arbeitet auf Basis der Snapshots und lässt sich mit einer Aufbewahrungsrichtlinie versehen, die stündliche, tägliche und wöchentliche Kopien unterscheidet. Zweitens über PEERING-Beziehungen zu anderen Systemen oder – in neueren HPE-Setups – über Cloud-Backup-Dienste.

Für die Nextcloud selbst braucht es zusätzlich ein anwendungsnahes Backup. Klassische Werkzeuge wie rsync, BorgBackup oder Restic haben sich hier bewährt. Wichtig ist die Trennung zwischen Daten- und Metadatenpfad: Während das Datenverzeichnis durchaus inkrementell gesichert werden kann, muss die Datenbank in einem konsistenten Zustand erfasst werden. Die Kombination aus einem maschinellen Dump der Datenbank und einem Dateisystem-Backup der Nutzerdaten ist der Standard, den erfahrene Betreiber fahren.

Nicht zuletzt der Punkt der Wiederherstellung. Ein Backup ist erst dann nützlich, wenn man es getestet hat. In der Praxis empfiehlt es sich, mindestens einmal pro Quartal eine Wiederherstellung in einer Testinstanz zu üben – das deckt genau die Probleme auf, die in der Theorie nie auftreten: fehlende Berechtigungen, abweichende File-IDs, inkonsistente Datenbank-Indizes. Ein Nimble-Snapshot eines Volume-Klons ist hier ein wunderbares Werkzeug: Man klont das Volume, hängt es in eine Test-VM, spielt den Datenbank-Dump ein und schaut, ob alles läuft. Das kostet keinen Speicherplatz in relevantem Umfang und kann in wenigen Stunden erledigt werden.

Performance: Wo die IOPS wirklich gebraucht werden

Man täuscht sich häufig über die tatsächlichen Lastprofile. Ein Nextcloud-Server, der 500 Nutzer bedient, mag nominell wenig Traffic erzeugen – ein paar Dutzend Megabyte pro Sekunde im Schnitt. Die Spitzenwerte sehen anders aus. Wenn morgens um acht Uhr viele Clients gleichzeitig ihre Synchronisation anstoßen, entstehen für ein paar Minuten zehntausende kleine Lese- und Schreiboperationen, gemischt mit Datenbankzugriffen. Wer in dieser Phase mit einem langsamen Storage arbeitet, sieht einen Anstieg der Antwortzeiten, der sich bis in die Oberfläche fortpflanzt.

Die Datenbank ist dabei in der Regel der kritischste Teil. Sie sollte auf dem schnellsten verfügbaren Volume liegen, und im Idealfall auf einem eigenen, dedizierten Nimble-LUN. Eine Festspeicherbelegung des Datenbank-Volumes auf einem All-Flash-Array ist einer gemeinsamen Nutzung mit dem Files-Volume klar vorzuziehen. Wer die Möglichkeit hat, kann die WAL- beziehungsweise redo-Logs von der Datenbank trennen, um Schreib- und Leselast weiter zu entzerren.

Neben der Datenbank ist Redis der zweite Kandidat für eine schnelle Anbindung. Es speichert Sessions, Locks und kurzlebige Zustände und sollte grundsätzlich mit aktivierter Persistenz und möglichst im selben Netzwerksegment wie die Webserver laufen. Der Zugriff läuft über TCP, weshalb die Netzwerklatenz zwischen Redis und Applikation wichtiger ist als die reine IOPS-Zahl des Servers.

Beim Files-Storage hingegen ist die reine IOPS-Zahl meist weniger entscheidend als die Reaktionszeit bei Metadatenoperationen. Ein Array, das 100.000 IOPS mit 0,2 Millisekunden Latenz liefert, ist für Nextcloud wertvoller als eines mit 300.000 IOPS und 2 Millisekunden Latenz. Genau hier liegt die Stärke der Nimble-Architektur: Sie liefert niedrige Latenzen auch bei gemischter Last, weil der Flash-Tier als Read-Cache wirkt und der Schreibpfad durch die CASL-Logik serialisiert wird. In Praxistests schlagen sich Alletra-6000-Systeme in Nextcloud-Workloads oft besser als ihre theoretischen Spezifikationen vermuten lassen.

Sizing, Kosten und der ehrliche Blick auf den TCO

Zum Sizing gibt es keine Formel, die man einfach anwenden kann. Grob gilt: pro 100 aktive Nutzer mittlerer Intensität sollte man mit einem Nutzdatenvolumen von ein bis fünf Terabyte rechnen, Tendenz steigend. Vorschaudaten und Dateisystem-Overhead kommen hinzu. Auf der Performance-Seite reichen für die meisten Umgebungen bis 1.000 Nutzer SSD-basierte Arrays der Einstiegsklasse, solange die Datenbank nicht mit Files konkurriert.

Interessanter ist die Kostenbetrachtung. Ein Nimble oder Alletra 6000 mit 30 TB nutzbarer Kapazität liegt im fünfstelligen Bereich, je nach Ausstattung und Vertragsmodell auch deutlich darüber. Dazu kommen Lizenzen für den Nextcloud-Enterprise-Support – der ist optional, aber für viele Organisationen genau der Grund, warum sie sich für Nextcloud und nicht für eine Eigenbaulösung entscheiden. HPE bietet die Arrays zunehmend als Service über GreenLake an, mit monatlicher Abrechnung nach Kapazität. Ob das günstiger ist, hängt stark vom Nutzungsprofil ab; wer konstantes Wachstum hat, fährt mit dem Kauf häufig besser.

Ein Aspekt, der gerne vergessen wird: Der Wechsel auf Enterprise-Storage löst nicht das Problem des Datenwachstums. Wer vorher mit einem NAS und Erweiterungsgehäuse gearbeitet hat, wird auch mit einem All-Flash-Array irgendwann an die Kapazitätsgrenze kommen. Der Vorteil ist, dass Expansion bei Nimble und Alletra in der Regel ohne Unterbrechung funktioniert und die Konfiguration vereinfacht – aber die Kosten müssen im Betriebsbudget geplant werden, nicht nur im Investitionsbudget.

Und schließlich der Personalfaktor. Nextcloud auf Enterprise-Storage zu betreiben, ist keine Wochenendbastelei. Es braucht jemanden, der die Plattform versteht, die Zusammenhänge zwischen Datenbank, Cache und Storage erkennt und im Fehlerfall nicht raten muss. Diese Person kostet Geld, aber sie ist in vielen Umgebungen der entscheidende Faktor zwischen einer stabilen Instanz und einem Dauerprojekt. Wer an dieser Stelle spart, sollte den Rest der Investitionsrechnung lieber gleich vergessen.

Fallstricke aus der Praxis

Es gibt eine Handvoll Probleme, die in Projekten mit Nextcloud und Nimble immer wieder auftauchen. Das erste betrifft das File-Locking. Nextcloud nutzt für die Sperrung von Dateien entweder das Dateisystem selbst oder einen Redis-Server. Bei NFS-gestützten Setups ist das Dateisystem-Locking notorisch unzuverlässig, weshalb Redis fast schon Pflicht ist. Wer das nicht konfiguriert, darf sich über Sync-Konflikte wundern, die auf den ersten Blick wie Anwendungsfehler aussehen.

Das zweite Thema ist die Konsistenz von File-IDs. Nextcloud identifiziert Dateien nicht über ihren Pfad, sondern über einen internen Schlüssel. Wenn man einen Snapshot eines Volumes klont und die Daten dann in eine andere Umgebung einspielt, kann das zu Duplikaten führen – die Anwendung sieht dieselbe Datei unter zwei IDs und legt sie doppelt ab. Wer mit Volume-Klonen arbeitet – was auf Nimble besonders einfach ist –, sollte diesen Punkt immer im Hinterkopf haben und nach einem Wiederherstellungsvorgang konsequent einen occ files:scan durchführen.

Das dritte Thema ist die Größe der Vorschautabellen. Nextcloud legt Vorschauen in einem eigenen Verzeichnis ab und referenziert sie in der Datenbank. Bei aktiver Vorschaugenerierung für alle Dateitypen wächst dieser Bestand schnell in den zweistelligen Prozentbereich des Hauptdatenbestands. Auf einem Storage-Array bedeutet das nicht nur Kapazität, sondern auch zusätzliche I/O-Last beim Synchronisieren. Ein gezieltes occ preview:repair sowie das Beschränken der Vorschau-Generierung auf bestimmte Ordner kann hier spürbar entlasten.

Schließlich der Bereich Backup-Tools. Viele klassische Backup-Suiten verstehen einen Nextcloud-Container oder eine Nextcloud-VM nicht als Anwendung, sondern behandeln sie als Blackbox. Das führt dazu, dass Dateien und Datenbank unabhängig voneinander gesichert werden und bei einem Restore nicht mehr zusammenpassen. Wer ein solides Backup will, muss die Datenbank separat erfassen und den Restore-Prozess dokumentieren. Ein Nimble-Snapshot ist zwar nützlich, aber er ist kein Ersatz für eine verstandene Backup-Kette.

Ausblick: Alletra, GreenLake und offene Fragen

Der Markenname Nimble wird in Administratorenkreisen langfristig verschwinden, das ist absehbar. HPE kommuniziert die Alletra-Serie bereits als vollwertigen Nachfolger, und die nächsten Hardware-Generationen werden keine klassische Nimble-Positionierung mehr tragen. Was bleibt, ist die Technik-Linie: CASL, Snapshot-Logik, InfoSight und die Kommandozeilen-Schnittstelle werden bis auf weiteres gepflegt, weil sie in tausenden Installationen aktiv genutzt werden.

Gleichzeitig verschiebt sich der Fokus der Speicherbranche. Objekt-Storage über S3-API gewinnt an Bedeutung, auch für Nextcloud – Primärspeicher auf S3-Buckets ist bei einigen Anwendern bereits Realität. HPE hat mit der Alletra Storage MP ein System im Portfolio, das genau diese Welt bedient, und mit GreenLake lassen sich Block- und Objektressourcen unter einem gemeinsamen Betriebsmodell buchen. Ob das die klassische All-Flash-Array-Story in den nächsten Jahren ablöst, ist offen. Sicher ist, dass die Anforderungen der Anwendungen sich verschieben, und die Storage-Hersteller müssen nachziehen.

Im Nextcloud-Umfeld deutet sich ebenfalls Bewegung an. Die All-In-One-Variante mit Docker und integriertem Reverse Proxy wird immer populärer, gerade in Umgebungen ohne dediziertes Kubernetes. Equalizer-On-Board, also die automatische Skalierung von Komponenten wie PHP-FPM und Redis, ist in einigen Deployment-Werkzeugen bereits angekommen. Für Admins, die bislang mit manuell getunten Konfigurationen gearbeitet haben, ist das eine echte Erleichterung – aber nur, wenn die darunterliegende Storage-Schicht die nötige Stabilität liefert.

Fazit: Storage ist nicht das Problem, aber ohne guten Storage geht nichts

Nextcloud und Nimble sind kein Traumpaar im Marketing-Sinn, aber sie passen technisch gut zusammen, wenn man die Details respektiert. Die Plattform erzeugt genau die Art von Lastprofil, für die Nimble gebaut wurde: viele kleine I/O-Operationen, gemischte Lese- und Schreibraten, ein stetiger Metadatenstrom. Wer die Anbindung sauber plant – Block statt NFS wo möglich, Redis für Locking, Datenbank auf eigenem Volume, Snapshots nur als Betriebswerkzeug – bekommt eine Plattform, die über Jahre stabil läuft und deren Betrieb keine ständigen Feuerlöschaktionen erfordert.

Wer hingegen meint, Storage sei nur ein Kostenfaktor, der mit dem günstigsten NAS erledigt ist, wird irgendwann vor einer Instanz stehen, deren Nutzer über langsame Synchronisation klagen, deren Backups nicht konsistent sind und deren Wachstum schwer zu prognostizieren ist. Genau hier wird der Unterschied zwischen einer Hobbyinstanz und einer unternehmensfähigen Plattform sichtbar. Die günstigere Investitionsentscheidung ist nicht immer die bessere, und im Kontext einer souveränen Datenhaltung ist der Speicher kein Nebenschauplatz.

Letztlich gilt für beide Seiten: Komplexität ist kein Wert an sich. Wer die Funktionen eines All-Flash-Arrays nur zu zehn Prozent nutzt, hätte oft günstiger eine schlankere Lösung gewählt. Wer Nextcloud nur für die Ablage von PDFs einsetzt, braucht keine Enterprise-Snapshots. Aber wer die Plattform in einer Organisation mit hunderten Nutzern verantwortet, der tut gut daran, die Speicherschicht genauso ernst zu nehmen wie die Datenbankkonfiguration oder das TLS-Zertifikat. Das ist kein Hexenwerk – aber es ist Arbeit, die sich lohnt.