Das Problem
Die Leute fragten nach einem sicheren Mechanismus zum Austausch von Dateien. Heute sind wir stolz, das neue Open-Source-Dateiservermodul anzukündigen. Als neueste Komponente im Psono-Ökosystem löst es mehrere Probleme:
- Dateien, die per E-Mail geteilt werden, werden zu groß. Normalerweise wird alles über 20 MB abgelehnt.
- Das Hochladen von Dateien an andere Parteien per SFTP, GPG-Mails usw. ist für normale Benutzer zu komplex.
- Das Hochladen von Dateien mit Hilfe von Google Drive oder Dropbox kann problematisch für sensible Daten sein.
- Schutz von HR- oder Management-Infos vor internen Mitarbeitern, z.B. Fileserver-Admins.
- Hacker, die Zugriff auf Ihren Fileserver erhalten
- Bandbreitenprobleme, wenn Sie in einer Remote-Büroumgebung arbeiten und jeder von Ihrem kleinen Büro-Fileserver herunterlädt.
Und genau hier kommt Psono ins Spiel. Psono wurde mit all diesen Problemen im Hinterkopf entwickelt und ist extrem flexibel.
Die Benutzerfreundlichkeit
Ok, wie sieht es für den Benutzer aus, fragen Sie. Einfach.
- Ein Benutzer greift auf den Webclient zu
- wählt die Datei aus
- klickt auf die Schaltfläche "Hochladen"
- ... und wenn er möchte, kann er sie mit einem Rechtsklick teilen
Das hoffe ich ist einfach genug.
Unter der Haube
Unter der Haube führt der Client einige kompliziertere Schritte aus, die jedoch alle vor dem Benutzer verborgen sind:
- Der Client fragt den Server nach allen verfügbaren Fileservern
- Der Server bewertet die Anfrage und entscheidet je nach verschiedenen Benutzerattributen (Berechtigungen, IP, Zugriffsrechte), welche Shards (Dateistandorte) und Fileserver geeignet sind
- Der Server erstellt ein Datei-Upload-Ticket
- Der Client liest die Größe der Datei
- Der Client kündigt den Upload der Datei und des Shards beim Server an
- Der Client teilt die Datei in Stücke von maximal 128 MB, wenn die Datei zu groß ist
- Der Client verschlüsselt das Stück
- Der Client berechnet die Prüfsumme des Stücks
- Der Client lädt das Stück zusammen mit dem Datei-Upload-Ticket auf den Fileserver hoch
- Der Fileserver sendet das Upload-Ticket zum Server
- Der Server validiert das Ticket
- Der Fileserver akzeptiert den Upload des Stücks
- Der Client fährt mit dem nächsten Stück fort, bis alle Stücke verarbeitet sind
- Der Client aktualisiert seinen Datenspeicher, verschlüsselt ihn und sendet ihn an den Server
Mit diesem Mechanismus können wir jedes Dateigrößenproblem lösen, da Dateien in Stücke geteilt werden. Wir können Uploads auf Server verteilen, sogar für eine einzelne Datei. Alle Dateien werden (wie alles andere bei Psono) verschlüsselt, bevor sie den Client verlassen und an den Server gesendet werden.
Typisches Psono Dateiserver Setup
Der obere Teil zeigt ein typisches Setup. Ein Relaisserver (ein einfacher Reverse Proxy) dient einigen statischen Dateien (dem Webclient). Der Webclient wird dem Browser bereitgestellt, der dann REST-API-Endpunkte auf dem Server aufruft. Der Server nutzt eine Postgres-Datenbank, um alle persistenten Daten zu speichern. Der Psono-Webclient und der Psono-Server können als zustandslos betrachtet werden, alle Daten werden in der Postgres-Datenbank gespeichert.
Wenn Sie jetzt einen Fileserver anhängen möchten, müssen Sie zuerst eine Shard- und Clusterkonfiguration auf dem Server erstellen, die Sie dann zur Konfiguration des eigentlichen Fileservers verwenden können. Sobald der Fileserver hochfährt, wird er sich automatisch registrieren und seine Verfügbarkeit in 10-Sekunden-Intervallen weiter bekannt geben. Sollte ein Fileserver ausfallen, wird der Server dies erkennen und keine Clients mehr an den toten Server senden. Sobald er zurückkommt, wird er sich automatisch wieder registrieren und Anfragen von Clients empfangen. Im obigen Bild speichern wir alle Stücke im lokalen Speicher und haben für die SSL-Entladung einen Relaisserver (könnte der gleiche sein wie für den normalen Server, Webclient in kleinen Umgebungen).
Neben dem lokalen Speicher können Sie verschiedene Speicher-Backends verwenden und sogar mischen.
Mischung aus verschiedenen Speicher-Backends
Derzeit unterstützt (neben dem lokalen Speicher) werden Amazon S3, GCP Cloud Storage und Azure Blob Storage.
Sie können mehrere Fileserver verwenden, um beispielsweise Leistungsprobleme aufgrund von Bandbreitenbeschränkungen zu lösen. Sie könnten Leute haben, die remote arbeiten, aber nur eine sehr dünne Internetverbindung in Ihrem Büro haben. Ein weiterer Anwendungsfall könnte sein, dass Sie lokale Dateien noch besser schützen möchten und
- keine internen Dateien auf einen externen Speicher hochladen lassen
- Externen erlauben, Dateien mit Internen zu teilen, ohne ein anderes Tool zu verwenden
Ein Setup, das das Leistungsproblem löst und Ihnen eine bessere Isolierung bietet, könnte so aussehen:
Remote-Standort
Dieses Setup teilt den gesamten Traffic des "externen" Shards bidirektional zwischen den Standorten, sodass Externe Dateien hochladen können, die danach von Mitarbeitern heruntergeladen werden können und umgekehrt.
Der On-Premise-Shard hingegen wird nie mit dem Remote-Standort synchronisiert und bleibt besser geschützt. Da Dateien im "externen" Shard nur einmal synchronisiert werden, wann immer sie sich ändern, könnten 100 Mitarbeiter auf die Datei von diesem Shard zugreifen, ohne sie 100 Mal vom Remote-Standort herunterladen zu müssen. Oder wenn Sie eine Datei hochladen, können Sie sie mit 100 Externen teilen, ohne sie 100 Mal hochladen zu müssen.
Der Bandbreitenvorteil kann auch genutzt werden, um Remote-Standorte mit einem ähnlichen Setup wie diesem zu verbinden:
Mit zwei Remote-Büros
In diesem Setup hat jeder Standort einen eigenen Fileserver, und alle Dateien werden zwischen den Standorten geteilt. Schreibvorgänge gehen nur an ein bestimmtes Shard, was eine unidirektionale Synchronisation jedes Shards ermöglicht. Dieses Setup würde es den Leuten in New York ermöglichen, Dateien ohne Verzögerung abzurufen.
Der nächste große Punkt ist das Loadbalancing. All dies ist schön, wenn Sie nur ein paar Mitarbeiter haben, die Ihre Bandbreite nicht auslasten. Wenn Sie 1000 Mitarbeiter haben, die alle regelmäßig auf den Fileserver zugreifen, wird dies Bandbreitenbeschränkungen für einen einzelnen Server verursachen. Doch zum Glück kann Psono dies handhaben. Hier sind zwei Optionen, die von Psono's Fileserver für das Loadbalancing angeboten werden.
Sie haben möglicherweise bereits einen Loadbalancer, den Sie verwenden möchten, dann könnte Ihr Setup so aussehen:
Loadbalancierter Fileserver mit Loadbalancer
In diesem Setup wird ein Loadbalancer für die SSL-Entladung verwendet. Zwei Fileserver, die dahinter sitzen, werden genutzt, um die eigentlichen Anfragen zu bearbeiten. Beide kündigen dasselbe Shard an, daher müssen sie entweder das Shard synchronisieren oder einen gemeinsamen Speicher haben. Man könnte GlusterFS oder ein einfaches rsync verwenden.
Die Alternative wäre, dem Client zu erlauben, alles zu loadbalancieren und einige Setups und Kosten zu sparen. Ein Setup ohne zusätzlichen Loadbalancer könnte so aussehen.
Loadbalancierter Fileserver ohne Loadbalancer
All diese Setups können gestapelt werden, z.B. 3 Cluster mit je 2 Servern. Jedes Cluster bedient dasselbe Shard und hat einen synchronisierten (oder gemeinsamen) Speicher darunter.
Ich hoffe, ich konnte Ihnen einen guten Eindruck von den Fähigkeiten des neuen und mächtigen Fileserver-Moduls von Psono vermitteln.
