Psono filserver

Problemet

Folk spurgte efter en sikker mekanisme til at udveksle filer. I dag er vi stolte af at annoncere det nye open source filservermodul. Som den nyeste komponent i Psono-økosystemet løser det flere problemer:

• Filer, der deles via mail, bliver for store. Typisk bliver alt over 20mb afvist.
• Upload af filer til andre parter via SFTP, GPG mails og så videre er for komplekst for normale brugere
• Upload af filer ved hjælp af Google Drive eller Dropbox kan være problematisk for følsomme data.
• Beskyttelse af HR- eller ledelsesoplysninger mod interne medarbejdere, f.eks. filserveradministratorer.
• Hacker får adgang til din filserver
• Båndbreddeproblemer, når du arbejder i et fjernkontor miljø, og alle downloader fra din lille kontorserver.

Og det er her, Psono kommer ind i billedet. Psono er designet med alle disse problemer i tankerne og er ekstremt fleksibel.

Brugervenlighed

Ok, så hvordan ser det ud for brugeren, spørger du. Simpel.

• En bruger åbner webklienten
• vælger filen
• klikker på "upload"-knappen
• ... og hvis han vil, deler han den med et højreklik

Det er simpelt nok, håber jeg.

Under motorhjelmen

Under motorhjelmen udfører klienten nogle mere komplekse trin, men alle er skjult for brugeren:

• Klienten beder serveren om alle tilgængelige filservere
• Serveren evaluerer anmodningen og beslutter i henhold til forskellige brugerattributter (tilladelser, IP, adgangsrettigheder) hvilke shards (fillokationer) og filservere, der er egnede
• Serveren opretter en filupload-billet
• Klienten læser filens størrelse
• Klienten annoncerer upload af filen og shard til serveren
• Klienten splitter filen op i chunks af maks. 128mb, hvis filen er for stor
• Klienten krypterer chunket
• Klienten beregner checksum af chunket
• Klienten uploader chunket til filserveren sammen med filupload-billetten
• Filserveren sender upload-billetten til serveren
• Serveren validerer billetten
• Filserveren accepterer upload af chunket
• Klienten fortsætter med næste chunk, indtil alle chunks er behandlet
• Klienten opdaterer sin datastore, krypterer den og sender den til serveren

Med denne mekanisme kan vi løse ethvert filstørrelsesproblem, da filer er opdelt i chunks. Vi kan distribuere uploads over servere selv for en enkelt fil. Alle filer er (ligesom alt andet hos Psono) krypteret, før de forlader klienten og sendes til serveren.

Typisk Psono filserver opsætning

Den øverste del viser en typisk opsætning. En relay-server (en simpel reverse proxy) serverer nogle statiske filer (webklienten). Webklienten sendes til browseren, som derefter kalder REST API-endepunkter på serveren. Serveren bruger en Postgres Database til at gemme alle vedvarende data. Psono Webklient og Psono Server kan betragtes som statsløse, alle data gemmes i Postgres-databasen.

Vil du nu tilslutte en filserver, skal du først oprette en shard- og klyngekonfiguration på serveren, som du derefter kan tage for at konfigurere selve filserveren. Når filserveren starter op, vil den automatisk registrere sig selv og fortsætte med at annoncere sin tilgængelighed i 10 sekunders intervaller. Hvis en filserver skulle dø, vil serveren registrere dette og stoppe med at sende klienter til den døde server. Når den kommer tilbage, vil den automatisk registrere sig igen og begynde at modtage anmodninger fra klienter. I billedet ovenfor gemmer vi alle chunks i lokal storage og har en relay-server (kan være den samme som for den normale server, webklient i små miljøer) for SSL offload.

Udover lokal storage kan du bruge forskellige lagringsbackends og endda blande dem.

Blanding af forskellige lagringsbackends

I øjeblikket understøttes (ved siden af lokal storage) Amazon S3, GCP Cloud Storage og Azure Blob Storage.

Du kan bruge flere filservere for at løse for eksempel ydelsesproblemer på grund af en båndbreddebegrænsning. Du kan have folk, der arbejder remote, men kun en meget tynd internetforbindelse på dit kontor. En anden brugssag kunne være, at du vil beskytte lokale filer endnu bedre og

• ikke tillade interne filer at blive uploadet til en ekstern storage
• tillade eksterne at dele filer med interne uden et andet værktøj

En opsætning, der løser ydelsesproblemet og giver dig en bedre isolation, kan se sådan ud:

Fjernplacering

Denne opsætning deler al trafik på "ekstern" shard mellem stederne bidirektionalt, hvilket tillader eksterne personer at uploade filer, som derefter kan downloades af medarbejdere og omvendt.

Den on-premise shard på den anden side synkroniseres aldrig til fjernplaceringen og forbliver bedre beskyttet. Da filer i "ekstern" shard kun synkroniseres én gang, når de ændres, kan du have 100 medarbejdere, der får adgang til filen fra denne shard uden at skulle downloade den 100 gange fra fjernplaceringen. Eller hvis du uploader en fil, kan du dele den med 100 eksterne, uden at skulle uploade den 100 gange.

Båndbreddefordelen kan også bruges til at forbinde fjernplaceringer med en opsætning, der ligner denne:

Med to fjernkontorer

I denne opsætning har hver placering sin egen filserver, og alle filer deles mellem placeringerne. Skrivninger går kun til en specifik shard, hvilket tillader en ensrettet synkronisering af hver shard. Denne opsætning ville tillade folk i New York at få adgang til filer uden nogen forsinkelse.

Det næste store punkt er loadbalancing. Alt dette er fint, hvis du kun har nogle få medarbejdere, der ikke sætter pres på din båndbredde. Hvis du har 1000 medarbejdere, der alle regelmæssigt får adgang til filserveren, så vil dette producere båndbreddebegrænsninger for en enkelt server. Men heldigvis kan Psono klare dette. Her er to muligheder, der tilbydes af Psono's filserver til loadbalancing.

Du har måske allerede en loadbalancer, som du gerne vil bruge, så din opsætning kunne se sådan ud:

Loadbalanceret filserver med loadbalancer

I denne opsætning bruges en loadbalancer til SSL offload. To filer servere, der sidder bagved, bruges til at håndtere de faktiske anmodninger. Begge annoncerer den samme shard, så de enten skal synkronisere shard eller have en delt storage. Man kunne bruge GlusterFS eller en simpel rsync.

Alternativet ville være at lade klienten loadbalance alt og spare noget opsætning og omkostninger. En opsætning uden en ekstra loadbalancer kunne se sådan ud.

Loadbalanceret filserver uden loadbalancer

Alle disse opsætninger kan stables, f.eks. 3 klynger med 2 servere hver. Med hver klynge, der serverer den samme shard og har en synkroniseret (eller delt) storage nedenunder.

Jeg håber, jeg kunne give dig et godt indtryk af kapabiliteterne af Psono's nye og stærke filservermodul.