WISSEN > GLOBAL FILESYSTEM -> GLOBAL FILE SYSTEMS IM VERGLEICH
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Global File Systems im Vergleich
CTERA, Nasuni und Panzura
Das sollten Sie mitnehmen:
- Der Datenpfad ist eine Konfigurationsentscheidung, kein Produktmerkmal.
Ob ein direkter Pfad zum Storage tatsächlich Zeit spart, entscheidet die vorhandene Netzwerktopologie, nicht das Datenblatt.
- Cache-Vorgaben werden zu Infrastrukturkosten.
Oberhalb dokumentierter Schwellen schreiben Hersteller Medienklassen vor, und das verändert Hardware, Leistungsaufnahme und Kühlbedarf an jedem einzelnen Standort.
- Locking unterscheidet die Architekturen stärker als Caching.
Zentrale Lock-Instanz, dateibezogene Autorität am erzeugenden Node und protokollabhängige Sperrmodi führen zu völlig verschiedenen Abhängigkeiten.
- Offline-Fähigkeit ist keine Ja/Nein-Eigenschaft.
Lesbarkeit, Schreibbarkeit und globale Konsistenz müssen bei einem WAN-Ausfall getrennt betrachtet werden.
- Unveränderbar heißt nicht administrativ unangreifbar.
Entscheidend ist, welche Identität die Retention kontrolliert und ob sie den Schutz umgehen kann.
Global File System im Vergleich
Inhaltsverzeichnis
- CTERA trennt Edge, Portal und Storage, und der Datenpfad ist konfigurierbar
- Global sichtbar, lokal vorhanden und nutzbar sind drei verschiedene Zustände
- Nasuni bindet die Cache-Größe an eine Medienklasse und damit an Strom und Kühlung
- Die Cache-Dimensionierung entscheidet sich am Working Set, nicht am Gesamtbestand
- Panzura verankert die Lock-Autorität pro Datei am erzeugenden Node
- Beim Global File Locking unterscheiden sich die drei Architekturen fundamental
- Ein WAN-Ausfall ist kein Ja/Nein-Ereignis
- Cyber Resilience ist eine Frage der Trust Domain, nicht der Featureliste
- Lock-in hat zwei Ebenen, und nur eine davon lässt sich konfigurieren
- Die Architekturmerkmale im Überblick
- Was ASSISTRA-Projekte über die Auswahl gelehrt haben
- Fazit
- Quellen
Global File Systems verfolgen ein gemeinsames Ziel: Anwender an verteilten Standorten sollen auf einen gemeinsamen Dateibestand zugreifen, ohne dass jeder Standort eine vollständige Kopie vorhält und ohne klassische File-Server-Replikation. CTERA, Nasuni und Panzura lösen diese Aufgabe mit lokalen Edge-Komponenten, einem globalen Namespace und einer persistenten Storage-Schicht. Auf dieser Abstraktionsebene ähneln sich die Systeme so stark, dass ein Featurevergleich kaum etwas erklärt. Die Grundlagen dieses Modells haben wir in [Querverweis: Edge-basierte Global File Systems – Architektur und Betrieb] ausführlich behandelt und setzen sie hier voraus.
Interessant wird es eine Ebene tiefer. Wie werden Daten und Metadaten zwischen Edge und Storage bewegt? Was passiert bei einem Cache Miss? Wie werden konkurrierende Schreibzugriffe koordiniert, und welche Komponenten müssen dafür erreichbar sein? Welche Hardware entsteht daraus an den Standorten, und was kostet deren Betrieb über die Nutzungsdauer? Diese Architekturentscheidungen bestimmen Performance, WAN-Abhängigkeit, Failure Handling und Cyber Resilience deutlich stärker als die Anzahl der Produktfeatures.
Eine Einordnung vorweg, die für die Bewertung dieses Artikels wichtig ist. Wir vergleichen dokumentierte Architektureigenschaften auf Basis der jeweiligen Herstellerdokumentation. Wo eigene Betriebserfahrung einfließt, stammt sie ausschließlich aus CTERA-Umgebungen; ASSISTRA hat keine vergleichbare Projekterfahrung mit Nasuni oder Panzura. Diese Erfahrung wird deshalb nicht auf die anderen Plattformen übertragen, und die daraus abgeleiteten Aussagen gelten nicht als Vergleichsmaßstab. Umgekehrt bedeutet das: Wo für CTERA mehr Detailtiefe erscheint, ist das ein Unterschied der verfügbaren Quellen und nicht der Architekturqualität.
CTERA trennt Edge, Portal und Storage, und der Datenpfad ist konfigurierbar
CTERA teilt die Plattform in drei Komponenten: den Edge Filer als lokalen File Service, das Portal für Metadaten, Verwaltung und Koordination sowie die persistente Storage-Schicht in Form von Storage Nodes. Diese Trennung ist der Grund für die vergleichsweise große Freiheit bei der Storage-Auswahl, denn die Architektur ist nicht auf ein bestimmtes Object-Storage-System festgelegt.
Für den Datenpfad ist Direct Mode die entscheidende Konfigurationsoption. Ohne Direct Mode läuft der File-Datenpfad vom Edge Filer über das Portal zum Storage. Mit aktiviertem Direct Mode werden die Dateidaten direkt zwischen Edge Filer und Storage Node übertragen, während nur die Metadaten weiterhin an das Portal gehen. CTERA dokumentiert dafür bis zu 100 parallele Verbindungen pro Endpoint, eine Übertragung per HTTPS und ab Edge Filer 7.8.x per TLS 1.3 sowie den Zusammenhang, dass größere Dateien stärker profitieren als kleine.
Bemerkenswert ist, wie deutlich CTERA die Grenzen der eigenen Performanceaussage benennt. Als Einflussfaktoren nennt der Hersteller den Disk-Typ, die Netzwerklatenz und die Frage, ob auf dem Portal Antivirensoftware läuft. Wer aus einer Faktorangabe eine Erwartungshaltung ableitet, ignoriert genau die Variablen, die der Hersteller selbst als bestimmend bezeichnet.
Diese Einschränkung deckt sich mit unserer Projekterfahrung. In den von uns begleiteten CTERA-Umgebungen war der direkte Datenpfad in der Mehrzahl der Fälle vorteilhaft, aber der Effekt hängt an der Netzwerktopologie. In einer Stern- beziehungsweise Hub-and-Spoke-Architektur bleibt die eigentliche Transferstrecke zum zentralen Storage weitgehend identisch. Direct Mode entfernt dort den Portal Server aus dem File-Data-Path und damit eine Verarbeitungs- und Weiterleitungsstufe, aber die WAN-Strecke selbst wird nicht kürzer. Ein signifikanter Gewinn durch einen wesentlich kürzeren Netzwerkweg entsteht in dieser Konstellation nicht. In Topologien, in denen der Standort tatsächlich einen näheren Storage-Endpunkt erreichen kann, fällt der Unterschied deutlich größer aus.
Das ist ein Beispiel für ein Muster, das sich durch diesen ganzen Vergleich zieht: Aus der Existenz eines Architekturmerkmals folgt noch kein Betriebsvorteil.
Global sichtbar, lokal vorhanden und nutzbar sind drei verschiedene Zustände
Bei CTERA gibt es keinen direkten Dateitransfer zwischen zwei Edge Filern. Die Bereitstellung läuft immer über die persistente Storage-Schicht: Was an einem Standort geschrieben wird, erreicht den zweiten Standort über den Storage. Auf dem zweiten Edge Filer kann die Datei im Namespace bereits sichtbar sein, obwohl ihr Inhalt lokal noch nicht existiert; CTERA legt dort einen Stub ab, der lediglich die Metadaten trägt.
Damit sind drei Zustände zu unterscheiden, die im Alltag gerne zusammenfallen: eine Datei kann global vorhanden, lokal im Namespace sichtbar oder tatsächlich im lokalen Cache materialisiert sein. Erst der dritte Zustand bedeutet, dass ein Zugriff ohne WAN-Verbindung möglich ist.
Pinning verschiebt Daten gezielt in den dritten Zustand. CTERA kann definierte Datenbereiche auf einem Edge Filer pinnen; deren Inhalte werden heruntergeladen und lokal vorgehalten. Das ist überall dort relevant, wo bestimmte Daten auch bei einer Unterbrechung der Verbindung unmittelbar verfügbar sein müssen. Nasuni verwendet denselben Begriff mit anderer Bedeutung: Dort schützt Pinning bereits vorhandene Daten vor der Verdrängung aus dem Cache, lädt aber nicht selbst nach. Laden und Schützen sind bei Nasuni getrennte Vorgänge. Wer Produktvergleiche entlang von Featurenamen führt, übersieht diesen Unterschied vollständig.
Für große Dateien ist Streaming die praktisch wichtigere Funktion. CTERA streamt Dateien über 10 MB nach Möglichkeit aus der Cloud, sodass der Zugriff beginnen kann, bevor der Download abgeschlossen ist. Wahlfreier Zugriff wird dabei ebenfalls unterstützt: Über eine temporäre Datei werden Blöcke ab der angeforderten Position geladen, und das funktioniert sowohl über SMB als auch über NFS. Im direkten S3-Pfad verhält sich das anders. Dort werden Dateien sequenziell gestreamt, und wahlfreier Zugriff greift erst, wenn der angeforderte Punkt mehr als 500 MB vom aktuellen Streaming-Punkt entfernt liegt.
Entscheidend ist eine Einschränkung, die CTERA ausdrücklich formuliert: Streaming hängt nicht vom Dateityp ab, sondern davon, ob die öffnende Anwendung Streaming unterstützt. Das deckt sich mit unserer Erfahrung aus Projekten mit großen Mediendateien, in denen abhängig von der Applikation bereits mit einer Datei gearbeitet werden konnte, während weitere Inhalte im Hintergrund nachgeladen wurden. Für die Bewertung von Large-File-Workloads folgt daraus, dass die vollständige Downloadzeit und die Zeit bis zur Arbeitsfähigkeit zwei verschiedene Größen sind und dass nur die zweite mit den real eingesetzten Anwendungen ermittelt werden kann.
Nasuni bindet die Cache-Größe an eine Medienklasse und damit an Strom und Kühlung
Nasuni verfolgt ebenfalls ein Edge-Cache-Modell, setzt aber Object Storage als persistente Datenebene voraus. Eine Nasuni Edge Appliance stellt den lokalen File Service bereit und cacht aktive Daten, während UniFS Daten, Metadaten und Versionen im Object Storage persistiert. Der Object Storage kann dabei aus einer kundeneigenen Public- oder Private-Cloud-Umgebung stammen.
Interessanter als die Architektur sind die dokumentierten Betriebsvorgaben, weil sie unmittelbar in Hardware umschlagen. Nasuni nennt für neue Deployments ab Version 10.2 eine maximal getestete Cache-Größe von 400 TiB beziehungsweise 439 TB und verweist für größere Caches auf das Product Management. Für alle übrigen Deployments gilt weiterhin ein getestetes Maximum von 36 TiB. Diese zweite Angabe wird in Vergleichen regelmäßig übersehen, obwohl sie für Bestandsumgebungen die relevantere ist.
Hinzu kommen zwei Vorgaben, die die Auslegung des Virtualisierungshosts bestimmen. SSDs sind für alle Caches bevorzugt und oberhalb von 36 TiB erforderlich; Nasuni formuliert die Anforderung an anderer Stelle als performante Storage-Klasse, also SSD oder besser. Und Cache- und COW-Disks zusammen sollen höchstens 75 Prozent der Gesamtkapazität des VM Hosts belegen, wobei die COW-Disk mit 25 Prozent der Cache-Größe bis maximal 250 GB dimensioniert wird.
CTERA kennt bei den Medien keine vergleichbare generelle Vorgabe, hat aber eine eigene Obergrenze: Die nutzbare Kapazität eines Edge Filers ist lizenzgestaffelt und endet bei 256 TB für eine EV256-Lizenz. Unter ESXi kommt hinzu, dass einzelne Disks auf 62 TB begrenzt sind und größere Kapazitäten über mehrere virtuelle Disks abgebildet werden müssen. Beide Plattformen haben also eine harte Grenze, nur unterschiedlich begründet: bei CTERA über die Lizenzstufe, bei Nasuni über den getesteten Betriebsbereich plus Medienauflage.
Daraus folgt keine Aussage darüber, welche Plattform günstiger ist. Es folgt aber eine Kostenkette, die in Lizenzvergleichen nicht auftaucht. Das erforderliche lokale Working Set bestimmt die benötigte Cache-Kapazität, diese bestimmt die zulässige oder vorgeschriebene Medienklasse, daraus ergibt sich die Edge-Hardware, und aus dieser entstehen Anschaffungs- und Betriebskosten. Bei einem kleinen Cache ist der Unterschied wirtschaftlich nebensächlich. Bei einem Standort mit 100 oder 200 TB aktivem Working Set verändert die Medienvorgabe die Hardwareauslegung erheblich.
An dieser Stelle gehört ein Aspekt in die Rechnung, der in Storage-Vergleichen fast immer fehlt. Eine Global-File-System-Entscheidung ist eine Entscheidung über Hardware an jedem einzelnen Standort. Bei 4 Standorten ist das eine Randgröße, bei 150 Standorten ist es der eigentliche Hebel. Jeder Standort benötigt einen Virtualisierungshost mit ausreichender Kapazität, gegebenenfalls in HA-Auslegung, und dieser Host läuft durchgehend. Die Leistungsaufnahme über eine Nutzungsdauer von fünf Jahren übersteigt bei dieser Multiplikation regelmäßig die Anschaffungskosten der Cache-Medien.
Die naheliegende Vermutung, eine SSD-Vorgabe verschlechtere die Energiebilanz, greift dabei zu kurz. Bezogen auf die nutzbare Kapazität ist Flash gegenüber rotierenden Medien üblicherweise im Vorteil, sowohl bei der Leistungsaufnahme als auch bei der Abwärme und beim benötigten Bauraum. Die Medienvorgabe erhöht also primär die Anschaffungskosten, nicht zwangsläufig den Verbrauch. Der eigentliche energetische Unterschied zwischen den Plattformen entsteht dort, wo die Architektur größere lokale Working Sets erzwingt und damit größere Hosts an mehr Standorten.
Bemerkenswert ist die regulatorische Seite dieser Verschiebung. Das Energieeffizienzgesetz adressiert Rechenzentren mit spezifischen Pflichten, unter anderem zur Energieeffizienz und zur Abwärmenutzung; eine Novelle befindet sich seit dem Kabinettsbeschluss im Juni 2026 im parlamentarischen Verfahren. Edge-Infrastruktur in Niederlassungen fällt typischerweise nicht unter die Rechenzentrumsdefinition. Wer Kapazität aus dem zentralen Rechenzentrum an die Standorte verlagert, verbessert damit möglicherweise den gemessenen PUE-Wert des Rechenzentrums, während der absolute Verbrauch des Unternehmens steigt und in keiner regulierten Kennzahl mehr auftaucht. Für eine ehrliche Bewertung sollte die Edge-Infrastruktur deshalb in der Energiebilanz mitgeführt werden, auch wenn sie außerhalb der Berichtspflicht liegt.
Die Cache-Dimensionierung entscheidet sich am Working Set, nicht am Gesamtbestand
Die maximal unterstützte Cache-Größe beantwortet die wichtigste Sizing-Frage nicht: Wie viel Cache benötigt ein Standort tatsächlich?
ASSISTRA hat CTERA-Umgebungen mit 4 bis etwa 150 Standorten und Datenbeständen zwischen ungefähr 200 TB und 1 PB begleitet. Dabei hat sich gezeigt, dass eine einfache Prozentregel für das Cache-Sizing nicht zuverlässig auf jede Umgebung übertragbar ist. Ein Standort innerhalb eines globalen 1-PB-Bestands kann regelmäßig nur einen kleinen Bruchteil dieser Daten benötigen, während ein anderer Standort mit deutlich kleinerem Gesamtbestand einen großen Anteil davon aktiv bearbeitet und entsprechend mehr lokalen Cache braucht. Seit dem Einsatz entsprechender Discovery-Funktionen lässt sich das reale Working Set in CTERA-Projekten nach unserer Erfahrung deutlich belastbarer abschätzen als über Schätzregeln.
Hinzu kommt eine Nutzbarkeitsschwelle, die die verfügbare Kapazität unterhalb des Nennwerts hält. CTERA beginnt mit der Verdrängung von Dateien, sobald 75 Prozent der Edge-Filer-Kapazität belegt sind, und räumt so lange auf, bis 65 Prozent oder weniger erreicht sind. Nasuni begrenzt Cache und COW-Disk zusammen auf 75 Prozent der Hostkapazität. Beide Plattformen haben also eine Schwelle, unterhalb derer die nominelle Kapazität nicht vollständig als Working Set zur Verfügung steht. Wer mit Nennwerten plant, plant zu knapp.
Für den Produktvergleich folgt daraus eine Reihenfolge: Erst das reale Working Set bestimmen, dann die Kapazitätsgrenzen der Produkte bewerten. Umgekehrt führt der Vergleich zu Aussagen über Maximalwerte, die für die konkrete Umgebung bedeutungslos sind.
Panzura verankert die Lock-Autorität pro Datei am erzeugenden Node
Panzura CloudFS setzt ebenfalls auf Object Storage als persistente Datenbasis, trennt Daten und Metadaten aber besonders konsequent. Panzura beschreibt diese Entkopplung als physisch und leitet daraus zwei Eigenschaften ab: Das Dateisystem ist flexibel darin, welche physischen Blöcke eine Datei bilden, und jeder Node kann eine vollständige Kopie der Metadaten des gesamten Dateisystems halten, ohne die Dateien selbst zu speichern. Häufig verwendete Daten werden lokal gecacht, Änderungen werden blockorientiert übertragen.
Deutlich interessanter als das Caching ist das Eigentumsmodell, weil es CloudFS von den anderen beiden Plattformen unterscheidet und in Vergleichen häufig falsch dargestellt wird. Panzura nennt drei Prinzipien. Bei der Erstellung einer Datei wird der erzeugende Node als Origin gekennzeichnet und dies in den Metadaten festgehalten. Der Origin weiß jederzeit, welcher Node den Lock hält, unabhängig davon, ob die Datei gerade zur Bearbeitung gesperrt ist. Der Node mit dem Lock ist der Data Owner, und auch diese Information liegt in den Metadaten der Datei. Ein Node, der Data Ownership übernehmen will, ermittelt aus den Metadaten den Origin und kommuniziert direkt mit diesem, um den Lock anzufordern und Authoritative Write Node zu werden.
CloudFS besitzt also sehr wohl eine Lock-Autorität. Sie ist nur nicht global an einen Dienst gebunden, sondern pro Datei an den Node, auf dem die Datei entstanden ist. Die Beschreibung als reines Peer-to-Peer-Modell ohne Autorität trifft die Architektur nicht. Ergänzend wichtig für das Verständnis des Fehlerverhaltens: Der Data-Owner-Zustand wird über Metadaten-Snapshots transportiert. Die Lock-Information reist damit auf demselben Weg wie die Metadaten, nicht über einen davon unabhängigen Echtzeitkanal.
Die Standortkopplung beschreibt Panzura als Hub-, Spoke- und Mesh-Architektur, in der sich lokale Nodes sowohl mit der Cloud als auch mit jedem anderen lokalen Node verbinden, und nennt einen Synchronisationszyklus von 60 Sekunden, in dem geänderte Daten von jedem Node zur Cloud und zu jedem anderen Node übertragen werden.
Aus blockbasiertem Caching allein lässt sich dabei nicht ableiten, wie schnell eine konkrete Anwendung nach einem Cache Miss arbeitsfähig ist. Dafür sind zusätzlich die Zugriffssemantik der Anwendung, die tatsächlich benötigten Dateibereiche, das Locking und die WAN-Latenz maßgeblich.
Beim Global File Locking unterscheiden sich die drei Architekturen fundamental
Lokale Caches lösen das Problem konkurrierender Schreibzugriffe nicht. Wenn Benutzer an zwei Standorten dieselbe Datei bearbeiten, muss entschieden werden, wer schreiben darf und wie die anderen Standorte davon erfahren. Hier trennen sich die drei Architekturen am deutlichsten.
CTERA koordiniert Global File Locking über das Portal. Die Konfiguration erfolgt auf Ordnerebene: Ist Locking für einen Cloud Folder aktiviert, kann eine geöffnete Datei weder auf demselben noch auf einem anderen verbundenen Edge Filer bearbeitet werden. Die Voraussetzungen sind eng gefasst. Erforderlich sind Edge Filer ab Version 7.11.4900.11, Zugriff über SMB, ein nicht deaktiviertes oder suspendiertes Syncing sowie ein entsprechend lizenziertes Portal. Sperrbar ist außerdem nicht jeder Dateityp, sondern eine feste Liste, die im Wesentlichen Office- und AEC-Formate umfasst, darunter dwg, rvt, indd und die gängigen Microsoft-Office-Endungen.
Der architektonisch interessanteste Punkt bei CTERA wird selten genannt: Wird auf einem Cloud Folder Locking aktiviert, deaktiviert das den Konfliktmechanismus. CTERA arbeitet pro Ordner also entweder mit Sperren oder mit nachgelagerter Konfliktauflösung, nicht mit beidem. Das ist eine bewusste Entscheidung pro Datenbereich und keine globale Eigenschaft der Plattform. Wird eine gesperrte Datei verschoben, gelöscht, umbenannt oder wiederhergestellt, gelingt die Operation lokal, wird aber erst nach Freigabe des Locks zum Portal synchronisiert.
Nasuni verwendet einen zentralen, cloudbasierten Lock-Service und dokumentiert dessen Betriebsbedingungen ungewöhnlich konkret. Es gibt sechs Lock-Server-Standorte, darunter Frankfurt, Irland, Oregon, Virginia, Sydney und Singapur, jeweils mit definierten Redundanzpaaren. Ein Lock-Check dauert nach Herstellerangabe typischerweise unter einer Sekunde, und pro Volume soll der Lock Server gewählt werden, der zum Anwendungsfall passt, in vielen Fällen der mit der niedrigsten Latenz.
Für kollaborative CAD-Workloads veröffentlicht Nasuni eine Latenzeinordnung, die in dieser Präzision bei keinem der drei Anbieter eine Entsprechung hat. Bis 60 ms Round Trip Time zum Lock Server gilt die Performance als gut, zwischen 60 und 100 ms sind moderate Verzögerungen möglich, aber für den Produktivbetrieb typischerweise akzeptabel. Zwischen 100 und 150 ms bleibt produktives Arbeiten möglich, besonders bei kleinen Dateien, mit spürbaren Verzögerungen und höherer Fehlerwahrscheinlichkeit, wenn mehrere Benutzer gleichzeitig synchronisieren. Oberhalb von 150 ms rät Nasuni von der gleichzeitigen Zusammenarbeit an gemeinsam genutzten CAD-Dateien ab und verweist auf Alternativen wie verlinkte Dateien oder ein zeitlich gestaffeltes Vorgehen. Diese Werte stammen aus dem CAD- und AEC-Leitfaden und gelten für kollaborative Konstruktionsworkloads; sie sind keine allgemeine Betriebsgrenze der Plattform.
Ebenfalls relevant und im Vergleich meist unterschlagen: Nasuni kennt zwei Sperrmodi mit gegenläufigem Trade-off. Im Optimized Mode werden alle Locks zu lesbaren Write Locks erhoben, und nur eine Edge Appliance kann eine Datei gleichzeitig sperren; dieser Modus funktioniert mit SMB und NFS und bietet die beste Performance bei geringerer Protokollkompatibilität. Im Advanced Mode können mehrere Edge Appliances abhängig von den Share Access Modes gleichzeitig Locks halten; dieser Modus setzt SMB voraus, bietet die höchste Kompatibilität und kann die Performance beeinträchtigen. NFS-Volumes unterstützen ausschließlich den Optimized Mode. Nasunis zentrales Locking ist damit kein einzelnes Modell, sondern eine Modusentscheidung pro Umgebung.
Panzura koordiniert die Sperren, wie beschrieben, über den Origin Node der jeweiligen Datei. Zusätzlich unterstützt CloudFS Byte-Range Locking für Anwendungen, die es unterstützen; Panzura nennt Microsoft Excel und CAD-Anwendungen wie Autodesk Revit. Damit können mehrere Benutzer in unterschiedlichen Bereichen derselben Datei arbeiten, sofern die Anwendung dieses Modell nutzt. Die Einschränkung ist wesentlich: Byte-Range Locking wirkt nur dort, wo die Applikation Range Locking implementiert. CTERA beschreibt in nicht öffentlich zugänglicher Herstellerdokumentation ebenfalls eine globale Koordination von Byte-Range-Locks über das Portal; da diese Angabe in der öffentlichen Produktdokumentation keine Entsprechung hat, führen wir sie hier nicht als vergleichbare belegte Funktion. [CTERA-intern]
Die Grundmodelle unterscheiden sich damit in der Frage, welche Komponente erreichbar sein muss. Bei CTERA ist es das Portal, bei Nasuni der zuständige Lock Server, bei Panzura der Origin Node der konkreten Datei. Keine Variante ist abstrakt überlegen. Eine zentrale Instanz reduziert die Anforderungen an die direkte Kommunikation zwischen allen Standorten, macht dafür Erreichbarkeit und Latenz dieser Instanz zum Bestandteil des I/O-Verhaltens. Eine dateibezogene Autorität vermeidet den zentralen Dienst, macht dafür die Kommunikation zwischen den beteiligten Nodes zum Bestandteil des Konsistenzmechanismus. Die vorhandene WAN-Topologie und die Frage, ob Standorte direkt miteinander kommunizieren dürfen, werden damit zu Auswahlkriterien.
Ein Punkt gilt für zwei der drei Plattformen gleichermaßen: Global File Locking ist sowohl bei CTERA als auch bei Nasuni lizenzgebunden. Bei CTERA muss das Portal entsprechend lizenziert sein, bevor Locking auf Cloud Folders aktiviert werden kann; bei Nasuni muss Global Locking in der Kundenlizenz freigeschaltet sein. Die Kollaborationsfähigkeit ist bei beiden keine Basisfunktion.
Ein WAN-Ausfall ist kein Ja/Nein-Ereignis
Ein lokal vorhandener Cache bedeutet nicht automatisch, dass bei einem WAN-Ausfall unverändert weitergearbeitet werden kann. Drei Fragen müssen getrennt beantwortet werden: Ist der Dateiinhalt bereits lokal vorhanden, kann die Datei weiterhin gelesen werden, und darf sie weiterhin verändert werden, ohne die globale Konsistenz zu gefährden?
Die erste Frage ist die einfachste. Eine nicht lokal materialisierte Datei kann ohne Verbindung zur persistenten Storage-Schicht nicht nachgeladen werden. Genau hier liegt der praktische Wert von Pinning: Es überführt geschäftskritische Datenbereiche in einen Zustand, in dem sie unabhängig von der WAN-Verfügbarkeit lesbar bleiben.
Die dritte Frage hängt vom Locking-Modell ab, und hier verhalten sich die Plattformen unterschiedlich. Bei CTERA bleiben in den von uns betriebenen Umgebungen bestehende Locks bei Verlust der Portal-Verbindung erhalten; neue Locks können in diesem Zustand nicht mehr vergeben werden. Der lokale Betrieb läuft für bereits gesperrte und gecachte Dateien also weiter, während der Zugriff auf bisher nicht gesperrte Dateien der sperrbaren Typen eingeschränkt ist. Verwaiste Sperren verhindert CTERA über zeitlich begrenzte Locks, die periodisch erneuert werden müssen. [CTERA-intern] Davon zu unterscheiden ist der Fall der suspendierten Synchronisation: Ist das Syncing suspendiert, wird der Zugriff auf sperrbare Dateitypen verhindert. Ein Ausfall der Verbindung und eine bewusst suspendierte Synchronisation führen also zu unterschiedlichem Verhalten.
Bei Nasuni wird die Latenz zur Lock-Komponente zum Bestandteil des Schreibpfads, was das Verhalten bei Störungen der Verbindung zum Lock Service unmittelbar betrifft. Nasuni dokumentiert für die Auswahl des Lock Servers Redundanzbeziehungen zwischen den Standorten, sodass beim Ausfall einer Region eine zweite zur Verfügung steht. Wie sich die Schreibfähigkeit in Situationen verhält, in denen kein Lock Server erreichbar ist, lässt sich aus den öffentlich zugänglichen Unterlagen nicht mit der Genauigkeit ableiten, die für einen Vergleich nötig wäre. Diese Lücke sollte in einem Auswahlprozess durch eine gezielte Herstellerfrage geschlossen werden.
Bei Panzura verschiebt das Origin-Modell die Fragestellung. Entscheidend ist nicht, ob irgendeine Mesh-Verbindung besteht, sondern ob der Origin Node der konkret benötigten Datei erreichbar ist. Da der Data-Owner-Zustand über Metadaten-Snapshots transportiert wird, ist zusätzlich relevant, wie aktuell der Metadatenstand der beteiligten Nodes ist. Aus den öffentlich geprüften Unterlagen lässt sich nicht seriös ableiten, dass bei beliebigen Netzwerkpartitionen beide Seiten unabhängig Schreibrechte vergeben können. Diese Einschränkung bleibt bewusst stehen, weil eine technisch plausible Annahme an dieser Stelle kein Beleg wäre.
Offline Access sollte deshalb nie als Produkteigenschaft verglichen werden, sondern als Ergebnis aus Cache-Zustand, Lock-Modell und der konkret ausgefallenen Komponente.
Cyber Resilience ist eine Frage der Trust Domain, nicht der Featureliste
Alle drei Plattformen besitzen heute Mechanismen für Ransomware-Erkennung und Wiederherstellung. Die Frage, ob ein Produkt Ransomware Protection hat, taugt deshalb nicht mehr zur Unterscheidung. Interessanter ist die Kette aus Erkennung, Reaktion, geschützter Historie und Wiederherstellung, und vor allem die Frage, welche administrative Identität diese Kette kontrolliert.
CTERA analysiert mit Ransom Protect File-Aktivitäten direkt am Edge Filer und kann auf erkannte Angriffe reagieren. Ergänzend stehen Versionierung und Snapshots sowie WORM- und Vault-Mechanismen zur Verfügung, und bei geeigneten Object-Storage-Backends kann die Retention bis auf die Backend-Ebene propagiert werden. Genau diese Propagation ist der relevante Punkt, weil sie normale Dateiversionierung von einer administrativ stärker geschützten Ebene trennt.
Nasuni beschreibt UniFS ausdrücklich als unveränderbares Write-Once-Read-Many-Dateisystem für alle Daten, Metadaten und Versionen, das im Object Storage des Kunden liegt. Die Formulierung des Herstellers ist dabei aufschlussreich: Die Unveränderbarkeit bedeutet, dass Ransomware keine Daten ändern oder löschen kann, die eine Edge Appliance in den Object Storage geschrieben hat. Das ist eine Aussage über Angriffe auf Dateiebene und ausdrücklich keine Aussage über einen kompromittierten Administrator des darunterliegenden Storage Accounts. Nasuni selbst weist darauf hin, dass die Absicherung des Buckets beziehungsweise Storage Accounts Teil des Sicherheitsmodells bleibt.
Zwei Details verdienen bei Nasuni besondere Aufmerksamkeit, weil sie in Featurelisten nicht auftauchen. Erstens ist Ransomware Protection ein separat lizenzierter Add-on-Service, der die Plattformversion 9.9 voraussetzt. Dazu gehört auch Targeted Restore, das statt eines gesamten Volumes nur die betroffenen Dateien wiederherstellt, deren Namen einem vorgegebenen Muster entsprechen. Die Musterbindung ist eine reale Einschränkung, die den Wert der Funktion vom konkreten Angriffsmuster abhängig macht. Zweitens dokumentiert Nasuni eine Lücke im Mitigation-Verhalten: Wird in DFS- oder vergleichbaren Konstellationen ein Client durch die Mitigation Policy auf einer Appliance blockiert, kann er sich mit einer anderen Appliance verbinden, die denselben Share bereitstellt. Solche dokumentierten Grenzen sind für eine Bewertung wertvoller als jede Erkennungsrate.
Panzura kombiniert eine unveränderbare Datenhaltung mit Snapshots und nennt für die Wiederherstellung ein maximales globales Recovery Point Objective von 60 Sekunden. Diese Angabe ist als Herstellerangabe zu behandeln, zumal Panzuras eigene Veröffentlichungen an anderer Stelle abweichende Intervalle nennen. Sie ist außerdem weniger distinktiv, als sie wirkt: Nasuni dokumentiert unbegrenzte unveränderbare Snapshots mit Intervallen bis hinunter zu einer Minute als Bestandteil der Basisplattform. Für die Erkennung setzt Panzura auf Threat Control mit ML-basierten Verhaltensprofilen je Benutzer. Auch das sind dokumentierte Produkteigenschaften und keine unabhängigen Messungen der Erkennungsqualität; ohne nachvollziehbare Werte zu Falsch-Positiven und Falsch-Negativen lässt sich daraus keine Aussage über bessere Erkennung ableiten.
Damit bleibt die entscheidende Frage bei allen drei Plattformen dieselbe, und sie zielt nicht auf ein Feature. Zu unterscheiden sind mindestens drei Angreiferklassen: ein kompromittierter Benutzer, ein kompromittierter Administrator der GFS-Plattform und ein kompromittierter Administrator des darunterliegenden Object Storage. Ein unveränderbares Dateisystem adressiert zuverlässig die erste Klasse. Ob es die dritte adressiert, hängt vom Retention- und Berechtigungsmodell des Object-Storage-Systems ab und nicht von der GFS-Plattform. Wer Cyber Resilience vergleichen will, muss deshalb die Trust Domains untersuchen und beantworten, welche administrative Identität die Retention kontrolliert und ob sie den Schutz umgehen kann. Die zugrunde liegenden Mechanismen auf Objektebene haben wir in [Querverweis: Cyber Resilience im Object Storage] und [Querverweis: S3 als zentrale Datenplattform] ausführlich behandelt.
Lock-in hat zwei Ebenen, und nur eine davon lässt sich konfigurieren
Beim Vendor Lock-in werden regelmäßig zwei Fragen vermischt, die unterschiedliche Konsequenzen haben.
Die erste lautet, ob der Kunde zwischen verschiedenen Storage- oder Cloud-Anbietern wählen kann. Hier besitzen alle drei Plattformen erhebliche Freiheitsgrade. CTERA unterstützt unterschiedliche Storage Nodes und ist nicht auf Object Storage festgelegt. Nasuni und Panzura sind Object-Storage-zentriert, unterstützen innerhalb dieses Modells aber Public- und Private-Angebote verschiedener Anbieter. Dieser Infrastructure Lock-in ist bei allen dreien vergleichsweise gering.
Die zweite Frage lautet, ob der im Backend gespeicherte Datenbestand ohne die jeweilige Plattform unmittelbar als normales Dateisystem nutzbar ist. Das ist eine andere Problemklasse. Die Objekte und Metadaten im Backend bilden die interne persistente Repräsentation des jeweiligen Global File Systems, und diese Repräsentation ist optimiert, nicht dateiäquivalent. Bei CTERA organisiert das Portal Cloud Drive Folders in Folder Groups, wobei jede Folder Group als Deduplizierungsdomäne wirkt und zugleich festlegt, auf welchen Storage Node ein Edge Filer schreibt; über Dateien hinweg geteilte Datenblöcke sind keine direkt lesbare Dateistruktur. Bei Nasuni liegt der Bestand als UniFS im Object Storage. Ein Wechsel des S3-Anbieters ist deshalb eine grundlegend andere Aufgabe als ein Wechsel der Plattform, und für eine Exit-Strategie ist dieser zweite Lock-in in aller Regel der relevantere.
Eine Differenzierung ist an dieser Stelle allerdings nötig, weil sie in der pauschalen Formulierung untergeht. CTERA bietet mit Fusion Direct eine Betriebsart für Cloud Drive Folders, in der derselbe Datenbestand parallel als Datei über SMB und NFS sowie als Objekt über S3 zugänglich ist, sodass Anwendungen und Datenverarbeitungsumgebungen mit denselben Datensätzen arbeiten können. Das ist die konkrete Antwort auf die Frage nach dem Zugriff ohne die File-Services-Schicht, und sie ist für Analyse- und KI-Szenarien praktisch relevant. Entscheidend ist die Einordnung: Fusion Direct ist eine bewusst konfigurierte Option für dafür vorgesehene Ordner und keine generelle Eigenschaft des CTERA-Backends. Die pauschale Aussage, CTERA speichere Daten grundsätzlich in einem offen lesbaren Format, ist damit nicht zutreffend; die präzise Aussage lautet, dass CTERA für definierte Datenbereiche einen dualen Zugriffspfad anbietet.
Eng damit verwandt ist die Frage, welche Komponenten überhaupt in der eigenen administrativen Domäne betrieben werden können. CTERA erlaubt die private Bereitstellung von Edge Filern, Portal und Storage. Nasuni kann die Unternehmensdaten vollständig in kundeneigenem Object Storage halten, behält aber cloudbasierte Koordinationsdienste, insbesondere für Global File Locking; die pauschale Aussage, Nasuni sei ausschließlich SaaS, ist deshalb ebenso unpräzise wie die Behauptung, die Plattform lasse sich vollständig On-Premises betreiben. Panzura verteilt Teile der Koordination zwischen den Nodes und stützt sich für die Persistenz auf Object Storage.
Für eine Architekturentscheidung ist deshalb weniger die Frage relevant, ob ein Produkt den vorhandenen Object Storage unterstützt, als die Frage, welche Komponenten außerhalb der eigenen Trust Domain liegen. Bei üblichen Enterprise-Deployments ist das nebensächlich. Bei vollständig isolierten Netzen, Dark Sites oder entsprechenden regulatorischen Anforderungen wird es zum Ausschlusskriterium.
Die Architekturmerkmale im Überblick
Kriterium
CTERA
Nasuni
Panzura
Grundmodell
Edge Filer, Portal, Storage Node
Edge Appliance, Object Storage, Cloud-Koordination
Nodes, Object Storage
Object Storage zwingend
nein
ja
ja
Maximale Kapazität je Edge/Node
lizenzgestaffelt, EV256 bis 256 TB
400 TiB getestet für Neu-Deployments ab 10.2, sonst 36 TiB
abhängig von Node- und Deployment-Modell
Medienvorgabe bei großem Cache
keine generelle Vorgabe
SSD oder besser ab 36 TiB
separat zu dimensionieren
Nutzbarkeitsschwelle
Eviction ab 75 Prozent, Ziel 65 Prozent
Cache und COW höchstens 75 Prozent der Hostkapazität
nicht in vergleichbarer Form dokumentiert
On-Demand Cache und Pinning
ja, Pinning lädt nach
ja, Pinning schützt vor Eviction
ja
Streaming großer Dateien
ab 10 MB, applikationsabhängig, SMB und NFS
nicht in vergleichbarer Form dokumentiert
blockorientiertes Caching dokumentiert
Lock-Autorität
Portal
zentraler Lock Service, sechs Regionen
Origin Node je Datei
Protokoll für Global Locking
SMB
SMB und NFS je nach Modus
anwendungsabhängig
Global Locking lizenzpflichtig
ja
ja
nicht als separate Lizenz dokumentiert
Latenzvorgaben zur Lock-Instanz
nicht dokumentiert
dokumentiert für CAD-Workloads
kein zentrales Modell
Control Plane vollständig privat
ja
nein
Deployment-abhängig zu prüfen
Ransomware Detection
Ransom Protect am Edge Filer
Add-on-Service
Threat Control
Unveränderbare Ebene
WORM und Vault, Object Lock propagierbar
UniFS als WORM-Dateisystem
unveränderbare Objekte und Snapshots
Granularer Restore
Versionierung und Snapshot-Recovery
Targeted Restore, musterbasiert
granularer Restore laut Hersteller
Die Tabelle ist keine Rangliste. Mehrere Eigenschaften sind nur unter bestimmten Betriebsbedingungen relevant, und mehrere Felder beschreiben den Stand der öffentlichen Dokumentation und nicht notwendigerweise die technische Fähigkei
Was ASSISTRA-Projekte über die Auswahl gelehrt haben
Aus den begleiteten CTERA-Umgebungen mit 4 bis etwa 150 Standorten, Datenbeständen zwischen ungefähr 200 TB und 1 PB und Backends von AWS S3 über Ceph, NetApp und EMC bis zu Azure Blob und Cloudian ergeben sich mehrere Auswahlkriterien, die in Featurematrizen untergehen. Aus der Heterogenität der Storage-Plattformen selbst sind dabei keine grundsätzlichen Probleme entstanden.
Die Netzwerktopologie gehört vor die Bewertung des Datenpfads. Direct Mode entfernt das Portal aus dem File-Data-Path, verkürzt aber in Sternnetzen nicht die eigentliche WAN-Strecke. Wer den Nutzen bewerten will, muss zuerst wissen, welchen Weg die Daten nehmen.
Große Dateien brauchen eine eigene Betrachtung mit den real eingesetzten Anwendungen. Da Streaming von der Streaming-Fähigkeit der Applikation abhängt und wahlfreier Zugriff im direkten S3-Pfad an eine Distanzschwelle gebunden ist, sagen Bandbreite und synthetischer Durchsatz wenig über das wahrgenommene Verhalten aus.
Berechtigungen sind in Migrationen häufig die größere Herausforderung als der Datentransfer. Komplexe ACL-Strukturen, gewachsene Gruppenmodelle und Vererbungsregeln gehören deshalb bereits in die Assessment-Phase, gemeinsam mit der Namespace-Struktur und den Identitätsquellen. Kapazität, Bandbreite und Kopierdauer allein bilden ein GFS-Projekt nicht ab.
Synchronisationsprobleme vollständig ausschließen zu wollen, ist unrealistisch. Auch bei etablierten Architekturen treten sie auf, mit unterschiedlichen Ursachen. Die betrieblich entscheidende Frage lautet deshalb nicht, ob ein Produkt synchronisieren kann, sondern wie gut Abweichungen erkannt, analysiert und korrigiert werden können.
Diese Erfahrungen stammen aus CTERA-Projekten und werden ausdrücklich nicht auf Nasuni oder Panzura übertragen.
Fazit
CTERA, Nasuni und Panzura lösen dasselbe Grundproblem, aber nicht mit derselben Architektur. Unterhalb der gemeinsamen Idee eines globalen Datenbestands mit lokalem Working Set liegen Unterschiede, die im Betrieb sichtbar werden.
CTERA ist besonders dann interessant, wenn eine vollständig private Plattform erforderlich ist, unterschiedliche Storage-Technologien eingebunden werden sollen oder große Edge-Caches ohne generelle Medienvorgabe dimensioniert werden müssen. Direct Mode, Streaming und Fusion Direct schaffen zusätzliche Freiheitsgrade beim Datenpfad. Zu berücksichtigen sind die lizenzgestaffelte Kapazitätsgrenze, die auf SMB und eine feste Typenliste beschränkte Sperrfunktion und die Entscheidung zwischen Locking und Konfliktauflösung je Ordner.
Nasuni bietet eine konsequent Object-Storage-basierte Architektur mit sehr großen Edge-Caches und zentraler Koordination, verbunden mit einer bemerkenswert transparenten Dokumentation der eigenen Betriebsgrenzen. Genau zu betrachten sind die cloudbasierte Koordinationsebene, die Round Trip Time zum Lock Server, die Medienvorgabe oberhalb von 36 TiB und der Umstand, dass sowohl Global File Locking als auch der granulare Ransomware-Restore Zusatzlizenzen sind.
Panzura unterscheidet sich vor allem durch die dateibezogene Lock-Autorität am Origin Node und durch Byte-Range Locking für Anwendungen, die es unterstützen. Das kann bei kollaborativen CAD- und BIM-Workloads erheblich sein. Im Gegenzug wird die Kommunikation zwischen den Nodes selbst Teil des Konsistenzmodells, und die Erreichbarkeit des jeweiligen Origin Node wird zur relevanten Größe im Fehlerfall.
Eine belastbare Auswahl setzt deshalb voraus, dass mindestens folgende Fragen beantwortet sind: Wie groß ist das reale Working Set je Standort, und wie wurde es ermittelt? Welche Daten müssen bei einem WAN-Ausfall lokal verfügbar bleiben? Welche Anwendungen benötigen Global File Locking, über welches Protokoll greifen sie zu, und werden Byte-Range-Sperren gebraucht? Wie hoch ist die Latenz zur zuständigen Koordinationsinstanz, und dürfen Standorte direkt miteinander kommunizieren? Welche Komponenten müssen innerhalb der eigenen Trust Domain liegen? Welche administrative Identität soll die Recovery-Kopien schützen? Welche Edge-Hardware entsteht daraus an jedem Standort, und welche Leistungsaufnahme, Kühlleistung und Stellfläche folgen daraus über die geplante Nutzungsdauer? Und welche der benötigten Funktionen sind Basisfunktion, welche kostenpflichtige Erweiterung?
Erst wenn diese Kette aus Datenpfad, Cache-Verhalten, Locking, Netzwerktopologie, Failure Handling, Trust Domains und Infrastrukturkosten für die konkrete Umgebung verstanden ist, lässt sich beurteilen, welche Global-File-System-Architektur tatsächlich passt. Pauschale Aussagen über schneller, skalierbarer oder sicherer helfen dabei nicht weiter.
Quellen
CTERA Networks: What is CTERA Direct Mode. https://kb.ctera.com/docs/what-is-ctera-direct-mode (abgerufen am 27. August 2026)
CTERA Networks: Managing Caching, CTERA Edge Filer Administrator Guide. https://kb.ctera.com/docs/managing-caching-5-1-1 (abgerufen am 27. August 2026)
CTERA Networks: Configuring a Folder with File Locking. https://kb.ctera.com/docs/configuring-a-folder-with-file-locking (abgerufen am 27. August 2026)
CTERA Networks: Managing the Global File System (Folder Groups, Deduplizierungsdomänen, Fusion Direct). https://kb.ctera.com/docs/managing-portal-folders-and-folder-groups-4-1 (abgerufen am 27. August 2026)
CTERA Networks: Increasing Available CTERA Edge Filer Storage. https://kb.ctera.com/docs/increasing-available-ctera-edge-filer-storage-except-for-h-series-edge-filers-2 (abgerufen am 27. August 2026)
Nasuni: Chapter 1: Introducing Nasuni. https://docs.nasuni.com/docs/chapter-1-introducing-nasuni (abgerufen am 27. August 2026)
Nasuni: Configure and Size the NEA Cache. https://docs.nasuni.com/docs/cache-configuration (abgerufen am 27. August 2026)
Nasuni: CAD and AEC Collaboration Best Practices for Nasuni, Stand 31. Juli 2026. https://docs.nasuni.com/docs/cad-best-practices (abgerufen am 27. August 2026)
Nasuni: Recovering from Ransomware. https://docs.nasuni.com/docs/recovering-from-ransomware (abgerufen am 27. August 2026)
Nasuni: Nasuni Ransomware Protection. https://docs.nasuni.com/docs/nasuni-ransomware-protection (abgerufen am 27. August 2026)
Nasuni: Nasuni File Data Platform Security Architecture. https://docs.nasuni.com/docs/nasuni-platform-security-model (abgerufen am 27. August 2026)
Panzura: Distributed File Locking. https://panzura.com/technology/distributed-file-locking (abgerufen am 27. August 2026)
Panzura: CloudFS Hybrid Cloud File Services Platform, Whitepaper. https://panzura.com/hubfs/whitepapers/whitepaper_PanzuraCloudFS8.pdf (abgerufen am 27. August 2026)
Panzura: Panzura Technology – Hybrid Cloud Global, Distributed File System. https://panzura.com/technology (abgerufen am 27. August 2026)
Panzura: Panzura CloudFS. https://panzura.com/products/cloudfs (abgerufen am 27. August 2026)
Gesetz zur Steigerung der Energieeffizienz und zur Änderung des Energiedienstleistungsgesetzes (Energieeffizienzgesetz – EnEfG), in Kraft seit 18. November 2023; Novelle seit Kabinettsbeschluss Juni 2026 im parlamentarischen Verfahren.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
