Nextcloud External Storage: OpenStack Object Storage jenseits des Dateipfads

Nextcloud lässt sich nicht auf einen simplen Dateiserver reduzieren. Die Plattform will ein zentraler Ort für Zusammenarbeit sein: Upload-Links, Online-Editoren, abgestufte Berechtigungen und Synchronisation über mehrere Endgeräte hinweg. Was aber passiert, wenn die Daten nicht mehr auf einer lokalen Festplatte liegen, sondern in einem OpenStack-Objektspeicher? In Rechenzentren von Hochschulen, Forschungseinrichtungen und öffentlichen Verwaltungen ist diese Kombination keine Seltenheit. OpenStack ist dort oft die Standard-Cloud-Schicht, Nextcloud die beliebteste Self-Hosted-Ablage. Beides zusammenzuführen klingt nach einem elegantes Schachzug, wirft aber einige Fragen auf, die über die reine Mount-Konfiguration hinausgehen.

Dabei zeigt sich: Die technische Anbindung ist in der Regel einfacher, als viele befürchten. Die eigentliche Herausforderung liegt im Betrieb – und in der Bereitschaft, sich von liebgewonnenen Vorstellungen über Dateisysteme zu verabschieden.

Ein Speicher für alles, aber keiner wie ein Dateisystem

OpenStack Object Storage, im OpenStack-Universum meist „Swift“ genannt, funktioniert grundlegend anders als ein klassisches NAS oder ein Dateiserver mit XFS-Dateisystem. Wer schon einmal in OpenStack-Dokumentationen geblättert hat, stößt auf Begriffe wie „Account“, „Container“ und „Object“. Es gibt keine Verzeichnisse im herkömmlichen Sinn, kein cd, kein ls, kein Einbinden per CIFS oder NFS. Stattdessen gibt es eine HTTP-API, über die Objekte mit eindeutigen Namen geholt und abgelegt werden. Ein Objekt kann durchaus groß sein, aber es ist im Kern ein einziger Datenblock mit Metadaten.

Ein hilfreiches Bild: ein Objektspeicher verhält sich wie ein gigantisches Hochregallager ohne Gänge und Regalbeschriftung. Jede Kiste trägt eine Inventarnummer, die theoretisch auch wie ein Pfad aussehen kann: projekte/musterstadt/vertraege/2025/baumaßnahme-12.pdf. Doch die Schrägstriche sind nur Konvention. Für den Speicher selbst ist das ein einziger Name, keine Verschachtelung. Die Ordnung entsteht durch Namensgebung, nicht durch die Struktur des Mediums.

Nextcloud macht sich diese Eigenheit zunutze, indem es die Ordnerstruktur in die Objektnamen übernimmt. Container werden zu Wurzelverzeichnissen, verschachtelte Ordner zu Pseudo-Pfaden in den Objektnamen. Das funktioniert erstaunlich gut, solange alle Zugriffe über Nextcloud laufen. Schwierig wird es, wenn man meint, direkt auf dem Objektspeicher herumlaufen zu müssen, um Dateien zu verschieben oder Verzeichnisse umzubenennen. Ein Umbenennen eines „Ordners“ ist in Swift nichts anderes als das Kopieren und Löschen hunderter einzelner Objekte. Das dauert und lässt sich wunderbar übersehen, wenn man mit klassischen Werkzeugen hantiert.

Für die Anbindung an Nextcloud ist dieses Grundverständnis wichtiger als jede konkrete Konfigurationsanleitung. Wer den Speicher nur als eine Art Wolkenfestplatte betrachtet, wird spätestens bei den ersten Lasttests unangenehme Überraschungen erleben. Wer jedoch die Eigenheiten des Unterbaus akzeptiert und die Prozesse darauf einstellt, kann mit OpenStack Object Storage eine sehr robuste und skalierbare Datenablage bekommen.

So hängt man Swift in Nextcloud ein

In der Nextcloud-Administration lauert ab einer gewissen Installation das Modul „External Storage Support“. Es ist Teil des Standardangebots, muss aber in der App-Verwaltung aktiviert werden. Danach findet sich im Admin-Bereich der Punkt „Externe Speicher“. Dort lassen sich Storages anlegen – mit Typ, Mount-Punkt und Zugriffsberechtigung. Ein externer Speicher dieser Art ist nichts anderes als ein zusätzliches Wurzelelement, das in die Nextcloud-Dateistruktur eingehängt wird. Für die Benutzer sieht es aus wie ein ganz normaler Ordner, der je nach Konfiguration nur für bestimmte Gruppen oder für alle sichtbar ist.

Als Typ steht „OpenStack Object Storage“ in der Liste. Was folgt, ist ein Formular, das auf den ersten Blick recht übersichtlich daherkommt: Endpunkt, Benutzername, Passwort, Tenant beziehungsweise Projekt und Container. Dazu kommt der Mount-Punkt, unter dem der Speicher in Nextcloud erscheinen soll. Wer die Begriffe aus der OpenStack-Welt schon kennt, findet sich schnell zurecht. Wer nicht, sollte sich bewusst machen, dass der „Tenant“ in modernen OpenStack-Installationen fast immer „Projekt“ heißt. Der Container ist das Gegenstück zu einem S3-Bucket – ein physisch getrennten Ablagebereich innerhalb des Swift-Speichers, in dem alle Objekte des externen Speichers liegen. Nextcloud mountet übrigens genau einen Container. Wer mehrere Container anbinden will, muss auch mehrere externe Speicher anlegen.

Eine berechtigte Frage lautet, ob der Container bereits existieren muss. Die Antwort lautet: Je nach Berechtigung des OpenStack-Benutzers kann Nextcloud den Container selbst anlegen. In restriktiven Umgebungen, in denen der OpenStack-Admin die Kontrolle nicht aus der Hand geben möchte, wird der Container vorab über das Dashboard oder einen Swift-Client erstellt. Nextcloud benötigt dann nur noch Lese- und Schreibrechte auf diesen einen Container.

Spätestens hier ist die Versuchung groß, in der Dokumentation zu blättern und nach einem Feld für die Region zu suchen. In manchen Versionen der Nextcloud-Oberfläche gibt es dieses Feld, in anderen nicht. OpenStack-Umgebungen mit mehreren Regionen neigen dazu, einen Service Catalog auszuliefern, in dem die Swift-Endpunkte je Region separat gelistet sind. Einige Nextcloud-Versionen wählen automatisch den ersten verfügbaren Endpunkt, andere erlauben die Angabe einer Region. Wer in einer Multi-Region-Umgebung arbeitet, sollte sich vor der Einrichtung vergewissern, welche Region die Daten beheimaten soll und ob sich der gewählte Dienstaccount dort wirklich aufhalten darf. Andernfalls kann die Anbindung funktionieren, wird aber auf eine ferne, langsame Region zeigen – und das bekommt jeder Benutzer schmerzhaft zu spüren.

Keystone verstehen ist die halbe Miete

Die Authentifizierung an OpenStack läuft über den Identity-Dienst Keystone. Das ist kein simpler Login, sondern eine komplexe Token-Geschichte: Der Client sendet die Zugangsdaten an Keystone und erhält ein zeitlich begrenztes Token, das er für alle weiteren Anfragen an Swift vorweist. Nextcloud übernimmt diese Arbeit automatisch. Allerdings muss das Tool wissen, an wen es sich wenden soll: an die Keystone-URL, nicht die Swift-URL. Viele Einsteiger verwechseln die Endpunkte und tipppen lieblos die IP-Adresse des Swift-Proxys ein, die sie in der OpenStack-Dokumentation gefunden haben. In manchen Fällen funktioniert das sogar, weil OpenStack-Setups die Authentifizierung direkt am Proxy akzeptieren. Im Normalbetrieb läuft es aber über Keystone, und die korrekte Angabe des Identity-Endpunkts ist der erste Schritt zu einer stabilen Einbindung.

Danach kommt die Sache mit dem Projekt. Keystone v2, das viele Jahre lang als Standard galt, arbeitete mit „Tenants“. In Keystone v3, das inzwischen in praktisch allen aktuellen OpenStack-Distributionen verwendet wird, heißt das Konstrukt „Projekt“. Zusätzlich gibt es noch „Domains“, die für den Betrieb großer Multi-Tenant-Clouds gedacht sind. Wer einen normalen OpenStack-Benutzer mit Zugriff auf ein einzelnes Projekt hat, kommt meist mit Projektname, Benutzername und Passwort aus. Das UI von Nextcloud hat diese Entwicklung nicht überall vollständig nachvollzogen – je nach Version erscheinen weiterhin alte Feldbezeichnungen. Das ist kein Beinbruch, aber eine Erklärung dafür, warum sich manche Konfigurationsanleitungen aus dem Internet gegenseitig widersprechen.

Ein weiterer Aspekt, der oft unterschätzt wird, ist die Lebensdauer der Tokens. OpenStack-Administratoren stellen die Token-Gültigkeit selten auf unendlich; üblich sind einige Stunden oder ein Tag. Nextcloud muss also in der Lage sein, das Token im Hintergrund zu erneuern. Das funktioniert zuverlässig, solange Server und Keystone-Uhr synchron laufen. Klingt trivial, ist es aber nicht. In Umgebungen ohne NTP-Anbindung können bereits wenige Sekunden Abweichung dazu führen, dass die Authentifizierung sporadisch fehlschlägt. Nicht zuletzt deshalb gehört die Kontrolle der Systemzeit zu den ersten Maßnahmen, wenn die Verbindung nach ein paar Stunden unvermittelt abreißt.

Was der Mount in Nextcloud anrichtet

Wenn der OpenStack Object Storage erfolgreich als externer Speicher eingerichtet ist, sehen die Benutzer in der Nextcloud-Oberfläche einen zusätzlichen Ordner. Ihnen ist meist nicht bewusst, dass die darin liegenden Dateien nicht auf dem Nextcloud-Server gespeichert sind, sondern in einer entfernten Objektwolke. Solange die Leitung zwischen Nextcloud-Server und Swift-Speicher gut ist, bleibt diese Unterscheidung unsichtbar. Sobald es aber zu Verzögerungen kommt, wirkt es so, als wäre Nextcloud insgesamt langsam.

Nextcloud legt für jeden externen Mount eine Art Cache in der eigenen Datenbank an. Dateinamen, Größen und Zeitstempel werden in den Metadaten-Tabellen von Nextcloud gehalten, nicht im Objektspeicher. Das ist gut, denn so muss eine Ordnerauflistung nicht bei jeder Anfrage den gesamten Swift-Container durchsuchen. Die Liste wird aus der lokalen Datenbank bedient. Der Haken: Wenn im Objektspeicher Änderungen passieren, die Nextcloud nicht über die eigene API vorgenommen hat, weicht der Cache ab. Jemand, der direkt am Swift-Container Dateien anlegt, ändert oder löscht, muss dafür sorgen, dass Nextcloud davon erfährt. Der Klassiker ist ein Administrator, der aus Bequemlichkeit ein rclone-Kommando gegen den Container abfeuert und sich später wundert, warum Nextcloud die Datei nicht anzeigt. Nextcloud ist eben nicht nur Server, sondern auch Datenbank; es nimmt nicht einfach an, dass eine Datei existiert, nur weil ein Objekt im Container liegt.

Für solche Fälle bietet Nextcloud das Kommandozeilenwerkzeug occ. Mit occ files:scan --path lässt sich der betroffene Bereich neu einlesen. Das ist keine elegante Dauerlösung, aber ein notwendiges Werkzeug für den Betrieb. Wer öfter manuelle Eingriffe am Container vornehmen muss, sollte einen Prozess etablieren, der die Nextcloud-Datenbank anschließend konsistent hält. Dazu gehört auch, dass ein externer Mount nicht einfach vom Netz genommen werden darf, während Nextcloud darauf schreibt. Zwar hält Nextcloud etliche Schutzmechanismen bereit, aber eine geordnete Administration sieht anders aus.

Dateioperationen: alles over HTTP

Bei der Arbeit mit OpenStack Object Storage über Nextcloud laufen sämtliche Dateioperationen über HTTP. Werden Dateien hochgeladen, schickt sie der Nextcloud-Server in der Regel in einem Rutsch an Swift, sofern sie nicht in den Genuss eines Segmentierungsmechanismus kommen. Bei sehr großen Dateien greift Nextcloud auf das Konzept der „Static Large Objects“ beziehungsweise „Dynamic Large Objects“ zurück, das Swift selbst für große Objekte bietet. Ein einzelnes Swift-Objekt darf je nach Konfiguration mehrere Gigabyte groß sein, aber für den sicheren Austausch über unsichere Netze ist die Aufteilung in kleinere Segmente sinnvoll. Ob und wie das die jeweilige Nextcloud-Installation nutzt, hängt von der verwendeten Bibliothek und der Konfiguration ab.

Für den Administrator bedeutet das vor allem eines: Wer die Infrastruktur plant, sollte sich die Netzwerkwege zwischen Nextcloud-Server und Swift-Knoten genau ansehen. Ein Nextcloud-Server in einem anderen Rechenzentrum als der OpenStack-Cluster mag in Zeiten von Glasfaser vertretbar sein, kann aber bei vielen kleinen Dateien zu einer spürbaren Zusatzlatenz führen. Anders als bei einem lokalen Dateisystem gibt es keinen Kernel-Filesystem-Cache. Jede Datei, die Nextcloud lesen will, wird über HTTP geholt. Der Hauptspeicher des Servers puffert zwar die Verbindung, aber die Latenz der Übertragung bleibt.

Daraus folgt, dass sich viele kleine Dateien weniger gut verhalten als wenige große. Eine Nextcloud-Instanz mit Tausenden von Textdateien und Office-Dokumenten funktioniert auf einem Swift-Backend, aber sie erzeugt eine höhere Last auf dem API-Endpunkt als auf einer lokalen Disk. Das mag manchen überraschen, weil Objektspeicher oft als „unbegrenzt skalierbar“ vermarktet werden. Skalierbar ist die Kapazität, nicht aber die Geschwindigkeit für den Einzelzugriff auf einen bestimmten Container. Ein Container bleibt am Ende ein Ausschnitt aus einer verteilten Datenstruktur, dessen Partitionierung sich nicht nach den Zugriffsmustern eines Nextcloud-Servers richtet.

Dafür glänzt Swift bei einer anderen Sache: beim Archivieren großer unveränderlicher Daten. Sobald Dateien einmal abgelegt sind und nur noch selten verändert werden, ist der Overhead durch HTTP vernachlässigbar. Nextcloud kann dann als Frontend für ein Datenarchiv dienen, das in seiner Größenordnung klassische SAN-Lösungen deutlich übertrifft. Viele Project-Teams haben genau diesen Bedarf: eine Ablage, die wächst und wächst, ohne dass man ständig neue Festplatten in ein Serversystem schieben muss.

Verschlüsselung, Rechte und Compliance

Ein heikles Thema bei jeder Cloud-Anbindung ist die Verschlüsselung. OpenStack Swift kann transportverschlüsselt über TLS betrieben werden, und es verfügt auf Ebene der Speicherknoten über Mechanismen zur Datenverschlüsselung. Für Nextcloud entscheidend ist aber die Serverseitige Verschlüsselung, die direkt in der Plattform eingebaut ist. Sie hat das Ziel, Daten bereits auf dem Anwendungsserver zu verschlüsseln, bevor sie an den Objektspeicher übertragen werden. Auf diese Weise kann selbst ein Administrator des OpenStack-Clusters die Inhalte nicht im Klartext lesen, sondern nur verschlüsselte Objekte sehen.

Diese Funktion lässt sich pro externem Speicher aktivieren. Allerdings sollten sich Administratoren der Konsequenzen bewusst sein: Wenn die Schlüssel einmal verloren gehen, sind die Daten unwiederbringlich weg. Nextclouds Verschlüsselung ist stark in die Plattform eingewoben, aber sie ersetzt keine eigenständig gepflegte Backup- und Schlüsselarchitektur. Bei einem externen Objektspeicher, der ohnehin als sicherer Speicher gilt, mag man auf eine zusätzliche Verschlüsselung verzichten können. Aber dann verlässt man sich darauf, dass der OpenStack-Betreiber die Daten auf seinen Festplatten ausreichend schützt. Das ist nicht per se falsch, aber eine Architekturentscheidung, die dokumentiert gehört.

Ein interessanter Aspekt ist in diesem Zusammenhang die Frage nach den Zugriffsrechten. Nextcloud bildet Berechtigungen in der Datenbank ab; sie existieren nur innerhalb der Plattform. Der externe Objektspeicher selbst kennt weder Nextcloud-Benutzer noch Gruppen. Wer direkt auf den Container zugreifen kann, umgeht also sämtliche Nextcloud-Rechte. Das ist bei vielen Storage-Anbindungen so, wird aber bei Object Storage gern übersehen, weil der Zugang nicht über einen vertrauten Dateifreigabe-Mechanismus läuft, sondern über eine unscheinbare API. Ein OpenStack-Benutzer mit vollen Rechten auf den Container könnte sämtliche Dateien herunterladen, ohne sich um Nextcloud-Kontingente zu kümmern. Deshalb ist es wichtig, Dienstkonten für Nextcloud strikt zu begrenzen und den direkten Containerzugang auf wenige Spezialisten zu beschränken.

Für den Datenschutz und die Einhaltung von Compliance-Vorgaben ist außerdem die Frage relevant, wo der Objektspeicher tatsächlich physisch steht. Die nächste OpenStack-Cloud muss nicht im selben Land sein wie der Server, auf dem die Nextcloud-Instanz läuft. Bei einem externen Storage dieser Art sollten die Verträge klar regeln, in welchem Rechenzentrum und in welcher Rechtsordnung die Daten liegen. Klingt selbstverständlich, ist aber in Projekten mit mehreren Standorten ein häufiger Streitpunkt.

Wann die Kombination sinnvoll ist – und wann nicht

Die Entscheidung für einen externen OpenStack-Speicher sollte nicht allein aus technischer Begeisterung fallen. Es gibt ideale Anwendungsfälle, aber auch Konstellationen, in denen besser eine klassische Lösung passt.

Ein typisches Szenario ist eine Hochschule, die ihren Angehörigen eine Nextcloud-Instanz als Dateiablage anbietet. Im Hintergrund läuft eine OpenStack-Cloud, die der IT-Betrieb ohnehin betreibt. Anstatt zusätzliche NetApp-Speicher oder lokale Platten in die Nextcloud-Server einzubauen, wird ein Swift-Container angelegt. Das erleichtert die Kapazitätsplanung erheblich: Der Speicher ist Teil einer größeren virtualisierten Ressourcen-Pools, der für alle Projekte genutzt wird. Die Nextcloud zeigt sich nach außen als gewohnte Oberfläche mit eigenen Verzeichnissen, aber im Hintergrund können die Daten in demselben Cluster liegen, der auch für andere Cloud-Dienste verwendet wird. Das spart Kosten und vermeidet Insellösungen.

Ein anderes Szenario betrifft langfristige Archivierung von Behörden oder Forschungseinrichtungen. OpenStack Swift eignet sich für unveränderliche Archivdaten, und Nextcloud kann mit seinen Ordnern und Suchergebnissen als komfortables Frontend dazu dienen. Wichtig ist dabei, dass die Daten nicht ständig hin- und hergeschoben werden, sondern überwiegend in Ruhe liegen. In solchen Umgebungen tritt die Latenz in den Hintergrund. Vor allem aber braucht es keine aufwendigen Backup-Strategien mehr, weil Swift die Daten mehrfach über mehrere Knoten repliziert und damit einen gewissen Schutz vor Hardwareausfällen bietet.

Denkbar ist auch die Anbindung an einen externen Dienstleister, der OpenStack-as-a-Service anbietet. Davon gibt es zwar weniger als noch vor einigen Jahren, aber einzelne Provider vermarkten weiterhin verwaltete OpenStack-Clouds. Für ein Unternehmen, das auf eine eigene Cloud-Infrastruktur verzichten möchte, kann es sinnvoll sein, Nextcloud als Hybridlösung zu betreiben: die Anwendung bleibt in der eigenen Hand, die Speicherung erfolgt beim Provider. Das erfüllt häufig auch die Vorgabe, Daten in einem bestimmten Land zu halten.

Auf der anderen Seite gibt es klare Warnsignale. Wer Nextcloud vor allem für Echtzeit-Kollaboration mit vielen kleinen Dateien nutzt und das Gefühl hat, dass der Server ohnehin schon grenzwertig performant arbeitet, wird mit einem Swift-Backend nicht glücklich. Die zusätzliche Netzwerkstrecke und der Verzicht auf den lokalen Seagate/SSD-Cache machen sich bemerkbar. Es gibt sogar Konstellationen, in denen die Anbindung von OpenStack Object Storage zu einer spürbar langsameren Bedienung führt, obwohl die eigentliche Nextcloud-Instanz auf einem potenten Server läuft. Das liegt meist daran, dass der Objektspeicher-Cache in der Nextcloud-Datenbank nicht gut konfiguriert oder die Netzwerkstrecke zum Swift-Endpunkt nicht ausreichend dimensioniert ist.

Ein weiteres Manko ist die fehlende Transparenz bei Operationen, die aus Nutzersicht wie Umbenennen oder Verschieben aussehen. In einem klassischen Dateisystem sind das atomare Operationen: Der Eintrag im Verzeichnis ändert sich. In Swift wird aus einem Verschieben ein Kopieren plus Löschen. Nextcloud versteckt das weitgehend, aber im Hintergrund können bei riesigen Ordnern deutlich mehr HTTP-Requests anfallen als gedacht. Wer also plant, regelmäßig zehntausende Dateien zwischen Ordnern hin- und herzubewegen, sollte sich besser für S3-Kompatibilität oder einen lokalen Speicher entscheiden.

Typische Fehler in der Praxis

Die häufigsten Probleme bei der Nextcloud-OpenStack-Anbindung haben wenig mit Nextcloud selbst zu tun. Sie liegen in der Konfiguration der OpenStack-Seite oder im Zusammenspiel der Systemzeiten. Einer der Klassiker ist die Verwechslung von öffentlicher und interner Swift-URL. OpenStack unterscheidet den Zugriff über den öffentlichen Endpunkt für die Benutzer und den internen Endpunkt für die Dienste im selben Netzwerk. Der Nextcloud-Server sollte, wenn er im selben Netzwerk steht, die interne URL verwenden. Sie ist nicht nur sicherer, sondern meist auch schneller, weil sie nicht durch die externe Firewall und möglicherweise durch einen Load Balancer führt. In der Nextcloud-Konfiguration lässt sich diese URL nicht immer separat festlegen, aber wenn der Endpunkt im OpenStack-Servicekatalog nicht der richtige ist, sind die Fehlerbilder vielfältig.

Ein ähnlich häufig genannter Stolperstein ist der falsche Projektname. Wer in einer OpenStack-Umgebung mit mehreren Projekten arbeitet und den Benutzernamen in einem anderen Projekt kennt, erhält ein Token, das nur für dieses eine Projekt gültig ist. Wenn Nextcloud dann den Container des falschen Projekts anspricht, gibt es eine Fehlermeldung wie „404 Not Found“ oder gleich „Unauthorized“. Die Lösung ist meist schnell gefunden, aber nur, wenn man versteht, dass Benutzername und Passwort allein nicht ausreichen – Projektinformationen sind ebenso wichtig wie die Kombination aus Bank, Kontonummer und Kartennummer.

Dann gibt es das Problem der schnell wachsenden Container. OpenStack Swift hat eine Grenze für die Anzahl der Objekte in einem Container, die zwar sehr hoch liegt, aber bei intensiver Nutzung mit Millionen kleiner Dateien doch erreicht werden kann. Nextcloud verhält sich dabei anders als reine Archivlösungen: Selbst eine private Nextcloud-Nutzung mit vielen Benutzern produziert Unmengen von Dateien, insbesondere wenn Synchronisationsclients überall kleine temporäre Dateien ablegen. Zwar räumt Nextcloud normal auf, aber man sollte die Entwicklung im Auge behalten.

Auch das Thema Quota kann schnell zu Verwirrung führen. Auf einem externen Swift-Speicher gelten keine Nextcloud-Quoten. Wenn also ein Benutzer seine 100-GB-Grenze in Nextcloud erreicht hat, aber über einen anderen Zugriff auf denselben Speicher weitere Daten ablegt, kann die Belegung trotzdem wachsen. Nextcloud kann das nicht verhindern. Manche Administratoren umgehen das, indem sie dem OpenStack-Benutzer von Nextcloud nur eine begrenzte Rolle auf einem eingeschränkten Container geben – eine saubere, wenn auch nicht immer komfortable Lösung.

Der Blick über den Tellerrand: S3 und andere Objektspeicher

Nextcloud kann nicht nur mit OpenStack Object Storage umgehen, sondern auch mit Amazon S3 und fast allen seinen Klonen. S3 ist zum Quasi-Standard für Objektspeicher geworden. Viele OpenStack-Distributionen haben inzwischen ein S3-API-Gateway, sodass man sogar einen Swift-Speicher über die S3-Schnittstelle anbinden kann, wenn man das möchte. Die Frage, ob man für die Nextcloud-Anbindung eher die native Swift-API oder den S3-Weg wählt, hängt von den Gegebenheiten ab. In manchen großen Cloud-Projekten ist S3 aus Compliance-Gründen unerwünscht, weil es ein proprietäres API-Design ist, das sich vor allem an Amazon orientiert. OpenStack-Anhänger bevorzugen die elegante Swift-API, die ursprünglich von Rackspace kam. Praktisch sind beide Welten überbrückbar. Nextcloud unterstützt S3 schon seit Langem als externen Speicher und inzwischen auch als Primärspeicher. Die Swift-Anbindung ist dagegen etwas spezieller und nicht ganz so häufig anzutreffen, aber sie ist voll funktionsfähig, wenn man ein paar Punkte beachtet.

Ein interessanter Aspekt ist in diesem Zusammenhang die Frage der „Native“ Integration: Nextcloud behandelt S3 als „Amazon S3″ beziehungsweise „s3 compatible“, während OpenStack Swift seinen eigenen Treiber besitzt. Die Unterschiede liegen vor allem in den Authentifizierungsmechanismen. S3 setzt auf Signaturen mit Zugriffsschlüssel und Secret Key, Swift auf die Keystone-Token mit ihren zeitlich begrenzten Ablaufdaten. Für Administratoren, die bereits OpenStack kennen, ist Swifts Modell durchaus nachvollziehbar, für Neueinsteiger kann es eine zusätzliche Lernkurve bedeuten.

Wer eine Nextcloud-Instanz nur für ein kleines Team betreibt, kann sich überlegen, ob ein Objektspeicher überhaupt nötig ist. Es gibt viele Szenarien, in denen ein normaler Netzwerkordner mit RAID-Verbund oder ein NAS die pragmatischere Wahl bleibt. Der Betrieb eines OpenStack-Swift-Clusters ist nichts für schwache Nerven. Er erfordert eine besondere Betriebsdisziplin, ein gutes Monitoring und ein Verständnis für die verteilte Architektur. Wenn die OpenStack-Infrastruktur bereits existiert, ist der zusätzliche Schritt zur Nextcloud-Anbindung klein. Ohne diese Basis sollte man nicht anfangen, einen Objektspeicher nur wegen der Nextcloud-Anbindung aufzubauen. Dann investiert man am Ende mehr in die Speicherinfrastruktur als in die eigentliche Collaboration-Plattform.

Bemerkenswert ist, dass sich Nextcloud auch in die entgegengesetzte Richtung nutzen lässt: als Gateway für externen Speicher, der wiederum von mehreren Frontends genutzt wird. Wer ohnehin eine zentrale Nextcloud-Instanz hat, kann damit eine Speicher-Abstraktionsschicht aufbauen. Die Nextcloud zeigt den Benutzern nur einen virtuellen Ordner, während dahinter beispielsweise ein OpenStack-Container, ein S3-Bucket und ein WebDAV-Server gleichzeitig arbeiten. Das kann in Konzernen die Vielfalt der alten Speicherinseln mildern. Allerdings wächst damit die Verantwortung der Nextcloud-Administration: Sie wird zum zentralen Dreh- und Angelpunkt für den Zugriff auf viele unterschiedliche Speichertechnologien.

External Storage als Dauerlösung oder Übergang?

Wer External Storage nutzt, um OpenStack Object Storage einzubinden, sollte sich darüber im Klaren sein, dass dies eine Komfortlösung ist, keine Optimallösung für den Massendatenverkehr. Die eigentliche Stärke von Nextcloud liegt in der Zusammenarbeit und in der konsistenten Metadatenverwaltung. Die Kombination mit einem externen Objektspeicher erweitert diese Stärke um die Kapazität einer skalierbaren Infrastruktur. Gleichzeitig bleibt der Objektspeicher ein eigenwilliger Unterbau, der seine Gesetze vorgibt. Daran ändert auch die beste Nextcloud-Integration nichts.

Deshalb ist eine sorgfältige Planung unerlässlich. Wer ein solches Projekt angeht, sollte nicht direkt alle Benutzer auf den externen Speicher umziehen. Besser ist es, zunächst einen Mount für eine Pilotgruppe zu erstellen, die Last zu beobachten und die Monitoring-Werkzeuge von OpenStack und Nextcloud zu konsultieren. Im Vorfeld sollte man klären, welche Daten tatsächlich in den Objektspeicher wandern und welche vielleicht doch besser lokal bleiben. Ein sinnvoller Ausgangspunkt sind Archivordner, große Mediendateien oder strukturierte Ablagen, die von Anwendungen über eine API geschrieben werden. Für Datenbanken, Echtzeit-Kollaboration oder häufig wechselnde Synchronisationsordner ist nicht jeder Objektspeicher das richtige Zuhause.

Wenn diese Abwägung getroffen ist, erweist sich die Kombination aus Nextcloud und OpenStack Object Storage als verlässliche Basis. Die Integration ist tief genug, um die Plattform wie gewohnt zu nutzen, aber flexibel genug, um auch ungewöhnliche Ablagen abzubilden. Der Preis dafür ist ein Stück Komplexität, die nicht in der Nextcloud-Oberfläche sichtbar ist, sondern in den Tiefen der Systemarchitektur wartet. Wer sich darauf einlässt, bekommt eine Lösung, die sich nicht verbiegt, wenn die Datenmengen wachsen.

Und genau das ist am Ende die wichtigste Erkenntnis: Nextcloud External Storage mit OpenStack Object Storage ist kein Selbstläufer, aber auch kein gefährlicher Exot. Es ist eine Architekturentscheidung, die zu den eigenen Strukturen passen muss. Wenn sie passt, steht einer skalierbaren, einigermaßen eleganten Ablage nichts im Wege – solange man im Hinterkopf behält, dass das Dateisystem nur eine Illusion ist, die Nextcloud mithilfe eigener Datenbanken und Disziplin im Betrieb aufrechterhält.