Arbeitsweise von Sciebo

DRAFT!

Das Dokument ist noch in der Erstellungsphase… subject to change without notice…

Wie arbeitet Sciebo eigentlich? Wo liegen die Daten?

Auf dieser Seite gehen wir ein wenig auf die Funktionsweise von Sciebo ein, um Ihnen ein wenig Hintergrundwissen zu vermitteln. Wenn Sie verstehen, wie das System arbeitet, lassen sich etwaige Fehler eher vermeiden, denn Fehler in der Bedienung können auch mit einem Datenverlust einher gehen.

Wo liegen die Daten?

Physikalisch gesehen liegen die Daten gespiegelt an 2 Standorten der Uni Münster. Es handelt sich bei diesem Speichersystem um eine eigene Server-Infrastruktur mit hunderten einzelner Festplatten, auf denen die Daten gespeichert werden. Ein spezieller Algorithmus verteilt die Datenblöcke auf verschiedene Festplattenlaufwerke, so dass der Ausfall einzelner Platten vom System kompensiert werden kann und damit keine Daten verloren gehen. Im Fehlerfall werden defekte Laufwerke zeitnah ersetzt. Ein weiterer Vorteil dieser Datenverteilung ist auch, dass der Datendurchsatz sehr hoch ist, obwohl es sich nach wie vor um herkömmliche magnetische Festpattenlaufwerke handelt. Wird eine Datei geschrieben, findet der Schreibvorgang verteilt und parallelisiert auf mehrere Festplattenlaufwerke statt. Statt der üblichen ca. 120MByte/s können wir mit insgsamt mehreren GByte pro Sekunde Daten speichern. Mit einer sehr geringen Latenz werden diese Daten dann auch auf dem Speichersystem am zweiten Standort abgespeichert.
Dadurch, dass diese Speichersystem, wie auch die Sciebo Server selbst, auf Uni-Gelände stehen, können wir verhindern, dass ausländische Regierungen und deren Organisationen unberechtigt auf die Daten unserer Anwender zugreifen. Diese Datensouveränität ist für uns ein sehr hohes Gut!

Von der logischen Warte aus betrachtet, liegen die Daten zunächst in den Konten der einzelnen Anwender. D.h. nach dem derzeitigen Konzept hat jeder Nutzer ein eigenes Daten-Verzeichnis. Die Struktur ist hierarchisch aufgebaut. Besitzer der Daten ist dann der Anwender, in dessem jeweiligen Ordner diese Daten gespeichert sind. Das bedeutet konkret, dass, wenn dieser Anwender einen Ordner mit Ihnen teilt und Sie Daten dort abspeichern, diese Daten dann ebenfalls in dem Ordner landen, der mit Ihnen geteilt wurde. Sciebo (also auch ownCloud/Nextcloud) speichern nicht, wer diese Daten dort abgelegt hat. Das bedeutet in der Konsequenz aber auch, dass eine eventuelle Wiederherstellung von Daten auch die (schriftliche) Zustimmung der Person erforderlich macht, die diesen Ordner mit Ihnen geteilt hat. Sofern diese Freigabe noch aktiv ist, ist eine Daten-Wiederherstellung an exakt derselben Stelle recht unproblematisch. Sollte die Freigabe aber erloschen sein, weil die teilende Person Sciebo nicht mehr nutzt, kommen wir um gewisse Formalitäten nicht herum. Sonst öffnen wir einem eventuellen Missbrauch Tür und Tor. Auf der einen Seite dürfen wir das nicht, auf der anderen Seite ist uns das Vertrauen unserer Anwender in diese Prinzipien sehr wichtig.

Wenn Sie nun auf die Daten zugreifen möchten, gibt es verschiedene Wege. Über das Web-Interface können Sie einfach und direkt auf die Daten zugreifen. Die verschiedenen Client Apps sollen den Zugriff auf diese Daten vereinfachen. Im Gegensatz zu den Mobil-Clients sind die Desktop-Clients auch dazu in der Lage, eine lokale Kopie Iher Daten abzuspeichern. Das ist insbesondere nützlich, wenn der Internet-Zugriff, aus welchen Gründen auch immer, mal nicht funktioniert. Dazu muss allerdings die VFS-Option, deaktiviert sein. Ist VFS aktiv, verhält sich der Client ähnlich wie die mobile Version. Daten werden erst dann temporär heruntergeladen, wenn ein Zugriff auf die jeweilige Datei erfolgt. Eine lokale, dauerhafte Speicherung der Datei muss vom Nutzer explizit ausgewählt werden.

Vergleich mit Netzwerk-Laufwerken

Somit ist Sciebo nicht vergleichbar mit Netzwerk-Laufwerken. Bei einem Netzwerk-Laufwerk gibt es nur einen zentralen Datenbestand auf dem Server, auf den alle Anwender zugreifen. Somit kann immer nur eine Person gleichzeitig schreibend auf eine Datei zugreifen. An alle anderen Anwender wird eine Dateisperre durchgereicht, so dass diese dann nur lesen dürfen.
Im Gegensatz dazu werden die Daten beim Zugriff mit Client-Software temporär oder dauerhaft (je nach Einstellung) auf den Client kopiert. Somit hat jeder Anwender seine eigene Datei-Kopie und jeder kann diese Datei (auch schreibend) lokal öffnen, da Dateisperren derzeit nicht durchgereicht werden können. Das kann insbesondere bei der Bearbeitung von Office-Dokumenten zum Problem werden. Derjenige, der zuletzt schreibt, gewinnt. Finden mehrere Schreibzugriffe quasi parallel statt, gibt es Dateikonflikte, die manuell behoben werden müssen.

Und jetzt?

Die Dateisperren, die von Office-Produkten erstellt werden, sind im Prinzip nichts anderes als Lock-Dateien, die man prinzipiell auch auf die lokalen System herunter synchronisieren könnte. Wir haben vor einigen Jahren damit experimentiert, aber das hat sich leider als sehr unzuverlässig herausgestellt. Das Problem ist die Latenz. D.h. wenn der erste Anwender die Datei öffnet, wird die Lock-Datei erstellt. Diese müsste dann erst auf den Server hoch-synchronisiert und dann wieder an alle anderen Clients verteilt werden. Dieser Vorgang ist aber nicht zuverlässig. Einige Anwender haben evtl. ein langsames Client-System oder eine langsame Internet-Anbindung. Somit kann die Verteilung einer Lock-Datei in eingen Sekunden erfolgen, es kann aber auch wesentlich länger dauer. Ein Feature, das so unzuverlässig ist, ist kein Feature, sondern es gaukelt den Anwender eine falsche Sicherheit vor.

Somit ist die derzeit einzig gute Alternative, dass man die kollaborative Bearbeitung von Dokumenten ins Web verlagert. Wir hosten dafür eine entsprechende Office-Suite. Dort wird zentral auf den Datenbestand zugegriffen, so dass das Auftreten von Konflikten so weit wie irgend möglich vermieden wird.

Wieso kein Samba?

Rein theoretisch könnte man die Daten auch als Samba-Share zu Verfügung stellen. Leider funktioniert das mit Sciebo und den anderen verwandten Cloud-Systemen nicht problemlos. Der Hauptgrund hierfür ist die Meta-Datenbank, die die Datenbestände in Sciebo verwaltet. Wenn über einen Client oder über das Web-Interface Daten bearbeitet werden, werden diese Änderungen (Datei-Pfad, Besitzer, Zeitstempel, Prüfsumme etc.) in einer Datenbank gespeichert. Ein Samba-Server kann aber mit dieser Datenbank nicht kommunizieren. D.h. Sciebo bekäme Änderungen nicht mit und die Prüfsummen und anderen Einträge zu der jeweiligen Datei würden korrumpiert. Hintergrund-Jobs, die zeitnah solche Änderungen nachverfolgen und die Datenbank aktualisieren könnten, benötigen aber extrem viele Resourcen. Das System würde sehr stark ausgebremst bzw. würde zudem sehr unzuverlässig.

Aber es gibt doch WebDAV?!

Ja, das stimmt. Das ist ein Protokoll, das von Sciebo prinzipiell unterstützt wird. Es ist vom Handling aber nicht trivial. Die Wahrscheinlichkeit von Datenverlusten ist relativ hoch, wenn man nicht genau weiß, was man tut. Wir raten daher unseren Anwendern davon ab, diese Schnittstelle zu nutzen und wir bieten dafür auch keinen offiziellen Support an. Wer genau weiß, was er tut, kann über Tools wie rclone per WebDAV auf Sciebo zugreifen. Aber wir sehen das nicht gerne, da auch hier viele System-Resourcen gebunden werden (können). Das ist dann einfach unfair gegenüber allen anderen Anwendern. Wenn wir bsp. sehen, dass solch ein Zugriff die Server zu stark beansprucht, sind wir gezwungen, das Konto der entsprechenden Anwenders zu deaktivieren.