Het Probleem
Mensen vroegen om een veilige manier om bestanden uit te wisselen. Vandaag zijn we trots om de nieuwe open source bestandsservermodule aan te kondigen. Als de nieuwste component in het ecosysteem van Psono lost het meerdere problemen op:
- Bestanden die per e-mail worden gedeeld, worden te groot. Gewoonlijk wordt alles boven de 20 MB geweigerd.
- Het uploaden van bestanden naar andere partijen via SFTP, GPG-mails, enzovoort is te complex voor normale gebruikers.
- Het uploaden van bestanden met behulp van Google Drive of Dropbox kan problematisch zijn voor gevoelige gegevens.
- Bescherming van HR- of managementinformatie tegen interne medewerkers, bijv. bestandsserverbeheerders.
- Hacker die toegang krijgt tot je bestandsserver.
- Bandbreedteproblemen wanneer je werkt in een externe kantooromgeving en iedereen downloadt van je kleine kantoorbestandsserver.
En daar komt Psono om de hoek kijken. Psono is ontworpen met al deze problemen in gedachten en is uiterst flexibel.
De Gebruiksvriendelijkheid
Oké, dus hoe ziet het eruit voor de gebruiker vraag je? Simpel.
- Een gebruiker opent de webclient
- selecteert het bestand
- klikt op de "upload"-knop
- ... en als hij wil, deelt hij het met een rechtermuisklik
Dat is hopelijk eenvoudig genoeg.
Onder de motorkap
Onder de motorkap voert de client nog wat meer complexe stappen uit, maar die zijn allemaal verborgen voor de gebruiker:
- De client vraagt de server naar alle beschikbare bestandsservers
- De server evalueert het verzoek en beslist volgens verschillende gebruikerskenmerken (machtigingen, IP, toegangsrechten) welke scherven (bestandlocaties) en bestandsservers geschikt zijn
- De server maakt een bestandsuploadticket aan
- De client leest de grootte van het bestand
- De client kondigt de upload van het bestand en de scherf aan de server aan
- De client splitst het bestand op in stukken van maximaal 128 MB als het bestand te groot is
- De client versleutelt het stuk
- De client berekent de controlegetallen van het stuk
- De client uploadt het stuk naar de bestandsserver samen met het bestandsuploadticket
- De bestandsserver stuurt het uploadticket naar de server
- De server valideert het ticket
- De bestandsserver accepteert de upload van het stuk
- De client gaat door met het volgende stuk totdat alle stukken zijn verwerkt
- De client werkt zijn datastore bij, versleutelt het en stuurt het naar de server
Met dit mechanisme kunnen we elk bestandsformaatprobleem oplossen, aangezien bestanden worden opgesplitst in stukken. We kunnen uploads zelfs voor één enkel bestand over servers verdelen. Alle bestanden worden (zoals alles bij Psono) versleuteld voordat ze de client verlaten en naar de server worden verzonden.
Typische Psono-bestandsserversetup
Het bovenste deel toont een typische setup. Een relay-server (een eenvoudige reverse proxy) serveert enkele statische bestanden (de webclient). De webclient wordt naar de browser gestuurd, die vervolgens REST API-eindpunten oproept op de server. De server gebruikt een Postgres-database om alle persistente gegevens op te slaan. De Psono-webclient en Psono-server kunnen als stateless worden beschouwd; alle gegevens worden opgeslagen in de Postgres-database.
Als je nu een bestandsserver wilt toevoegen, moet je eerst een scherf- en clusterconfiguratie op de server maken, die je vervolgens kunt gebruiken om de werkelijke bestandsserver te configureren. Zodra de bestandsserver opstart, registreert deze zich automatisch en blijft hij elke 10 seconden zijn beschikbaarheid aankondigen. Mocht een bestandsserver uitvallen, dan herkent de server dit en stopt hij met het versturen van clients naar de dode server. Zodra deze terugkomt, registreert hij zich opnieuw automatisch en begint hij verzoeken van clients te ontvangen. In de afbeelding hierboven slaan we alle stukken op in lokale opslag en hebben we een relay-server (kan dezelfde zijn als voor de normale server, webclient in kleine omgevingen) voor de SSL-offload.
Naast lokale opslag kun je verschillende opslagbackends gebruiken en zelfs mixen.
Mix van verschillende opslagbackends
Momenteel ondersteund (naast lokale opslag) zijn Amazon S3, GCP Cloud Storage en Azure Blob Storage.
Je kunt meerdere bestandsservers gebruiken om bijvoorbeeld prestatieproblemen op te lossen als gevolg van een bandbreedtebeperking. Je zou kunnen hebben dat mensen op afstand werken, maar slechts een zeer dunne internetverbinding in je kantoor hebben. Een ander gebruiksvoorbeeld zou kunnen zijn dat je lokale bestanden nog beter wilt beschermen en
- geen interne bestanden naar een externe opslag toestaan
- externen toestaan bestanden te delen met internen zonder een ander hulpmiddel
Een setup die het prestatien probleem oplost en je een betere isolatie geeft, zou er als volgt uit kunnen zien:
Externe locatie
Deze setup deelt al het verkeer van de "externe" scherf tussen sites bidirectioneel, waardoor externen bestanden kunnen uploaden die daarna kunnen worden gedownload door werknemers en vice versa.
De on-premise scherf daarentegen wordt nooit gesynchroniseerd naar de externe locatie en blijft beter beschermd. Omdat bestanden in de "externe" scherf slechts eenmaal worden gesynchroniseerd, telkens wanneer ze veranderen, zou je kunnen hebben dat 100 medewerkers toegang hebben tot het bestand van deze scherf zonder dat het 100 keer hoeft te worden gedownload van de externe locatie. Of als je een bestand uploadt, kun je het delen met 100 externen, zonder dat het 100 keer hoeft te worden geüpload.
Het bandbreedtevoordeel kan ook worden gebruikt om externe locaties met elkaar te verbinden met een setup die lijkt op deze.
Met twee externe kantoren
In deze setup heeft elke site een eigen bestandsserver en worden alle bestanden gedeeld tussen de sites. Schrijfbewerkingen gaan alleen naar een specifieke scherf, wat een unidirectionele synchronisatie van elke scherf mogelijk maakt. Deze setup zou mensen in New York in staat stellen om zonder enige vertraging toegang te krijgen tot bestanden.
Het volgende grote punt is load balancing. Dit alles is mooi als je slechts een paar medewerkers hebt die je bandbreedte niet verzadigen. Als je 1000 medewerkers hebt, die allemaal regelmatig toegang hebben tot de bestandsserver, dan zal dit bandbreedtelimieten voor een enkele server veroorzaken. Gelukkig kan Psono dit aan. Hier zijn twee opties die worden aangeboden door Psono's bestandsserver voor load balancing.
Je hebt misschien al een load balancer die je wilt gebruiken, dan zou je setup eruit kunnen zien als:
Load balanced bestandsserver met load balancer
In deze setup wordt een load balancer gebruikt voor de SSL-offload. Twee bestandsservers die erachter zitten, worden gebruikt om de eigenlijke verzoeken af te handelen. Beide kondigen dezelfde scherf aan, dus moeten ze ofwel de scherf synchroniseren of een gedeelde opslag hebben. Je zou GlusterFS of een eenvoudige rsync kunnen gebruiken.
Het alternatief zou zijn om de client alles te laten load balancen en wat setup en kosten te besparen. Een setup zonder een extra load balancer zou er zo uit kunnen zien:
Load balanced bestandsserver zonder load balancer
Al deze setups kunnen worden gestapeld, bijvoorbeeld 3 clusters van elk 2 servers. Met elk cluster dat dezelfde scherf dient en een gesynchroniseerde (of gedeelde) opslag eronder heeft,
Ik hoop dat ik je een goed beeld heb kunnen geven van de mogelijkheden van Psono's nieuwe en krachtige bestandsservermodule.
