El problema
Hi havia gent que demanava un mecanisme segur per intercanviar fitxers. Avui estem orgullosos d'anunciar el nou mòdul de servidor de fitxers de codi obert. Com a component més recent de l'ecosistema de Psono, resol diversos problemes:
- Els fitxers compartits per correu sovint són massa grans. Normalment tot el que supera els 20mb és rebutjat.
- Pujar fitxers a altres persones mitjançant SFTP, correus electrònics GPG, etc. és massa complex per als usuaris normals.
- Pujar fitxers amb l'ajuda de Google Drive o Dropbox pot ser problemàtic per a dades sensibles.
- Protecció d'informació de Recursos Humans o directius contra empleats interns, per exemple, administradors del servidor de fitxers.
- Un hacker que aconsegueixi accés al teu servidor de fitxers.
- Problemes d'ample de banda quan treballes en un entorn d'oficina remot i tothom descarrega des del teu petit servidor de fitxers d'oficina.
I aquí és on entra en joc Psono. Psono va ser dissenyat tenint en compte tots aquests problemes i és extremadament flexible.
Usabilitat
Bé, i com pinta per a l'usuari? Senzill.
- Un usuari accedeix al client web
- selecciona el fitxer
- fa clic al botó "puja"
- ... i si vol el comparteix amb un clic dret
Espero que sigui prou senzill.
Sota el capó
Sota el capó el client realitza alguns passos més complexos, tot i que tots queden ocults per l'usuari:
- El client demana al servidor tots els servidors de fitxers disponibles
- El servidor avalua la sol·licitud i decideix segons diversos atributs de l'usuari (permisos, IP, drets d'accés) quins shards (ubicacions dels fitxers) i servidors de fitxers són adients
- El servidor crea un "ticket" per a la pujada del fitxer
- El client llegeix la mida del fitxer
- El client anuncia la pujada del fitxer i del shard al servidor
- El client divideix el fitxer en fragments d'un màxim de 128mb si el fitxer és massa gran
- El client xifra el fragment
- El client calcula la suma de verificació del fragment
- El client puja el fragment al servidor de fitxers juntament amb el ticket de pujada de fitxer
- El servidor de fitxers envia el ticket de pujada al servidor
- El servidor valida el ticket
- El servidor de fitxers accepta la pujada del fragment
- El client continua amb el següent fragment fins que tots estan processats
- El client actualitza el seu magatzem de dades, el xifra i el torna a enviar al servidor
Amb aquest mecanisme podem resoldre qualsevol problema de mida de fitxer, ja que els fitxers es divideixen en fragments. Podem distribuir pujades entre diversos servidors fins i tot per a un sol fitxer. Tots els fitxers (igual que la resta a Psono) s'encripten abans de sortir del client i s'envien al servidor.
Configuració típica d'un servidor de fitxers Psono
La part superior mostra una configuració típica. Un servidor "relay" (un simple proxy invers) serveix alguns fitxers estàtics (el client web). El client web s'entrega al navegador, que després crida als punts d'API REST del servidor. El servidor fa servir una base de dades Postgres per emmagatzemar totes les dades persistents. El Psono Webclient i el servidor Psono es poden considerar estatus-less, ja que totes les dades es guarden a la base de dades Postgres.
Si vols afegir ara un servidor de fitxers, primer has de crear una configuració de shard i clúster al servidor, que després utilitzaràs per configurar el servidor de fitxers. Un cop el servidor de fitxers s'engega, s'autoregistra i continua anunciant la seva disponibilitat en intervals de 10 segons. Si un servidor de fitxers mor, el servidor ho detecta i deixa d'enviar clients a aquest servidor. Quan torni, es tornarà a registrar automàticament i començarà a rebre sol·licituds dels clients. A la imatge de dalt, estem emmagatzemant tots els fragments en emmagatzematge local i tenim un servidor relay (podria ser el mateix que per al servidor normal o client web en entorns petits) per a l'offload SSL.
A més de l'emmagatzematge local, pots utilitzar diversos backends d'emmagatzematge i fins i tot combinar-los.
Barreja de diversos backends d'emmagatzematge
Els actualment acceptats (a més de l'emmagatzematge local) són Amazon S3, GCP Cloud Storage i Azure Blob Storage.
Pots fer servir múltiples servidors de fitxers per resoldre, per exemple, problemes de rendiment deguts a una limitació d'ample de banda. Podries tenir gent treballant remotament però només una connexió a internet molt limitada a la teva oficina. Un altre cas podria ser que vols protegir millor els fitxers locals i
- no permetre que fitxers interns es pugin a un emmagatzematge extern
- permetre als externs compartir fitxers amb els interns sense una eina diferent
Una configuració que resolgui el problema de rendiment i t'ofereixi una millor aïllament podria semblar així:
Ubicació remota
Aquesta configuració comparteix tot el trànsit del "shard extern" entre localitzacions de manera bidireccional, permetent als externs pujar fitxers que es podran descarregar posteriorment pels empleats i viceversa.
El shard "on-premise" per altra banda mai es sincronitza amb la ubicació remota i queda millor protegit. Com que els fitxers al "shard extern" només es sincronitzen una vegada cada cop que canvien, podries tenir 100 empleats accedint al fitxer des d'aquest shard sense necessidade de descarregar-lo 100 vegades des de la ubicació remota. O si puges un fitxer, pots compartir-lo amb 100 usuaris externs sense haver-lo de pujar 100 vegades.
L'avantatge d'ample de banda també es pot utilitzar per connectar ubicacions remotes amb una configuració similar a aquesta:
Amb dues oficines remotes
En aquesta configuració, cada ubicació té el seu propi servidor de fitxers i tots els fitxers es comparteixen entre ubicacions. Les escriptures només van a un shard específic, el que permet una sincronització unidireccional de cada shard. Aquesta configuració permetria a la gent a Nova York accedir als fitxers sense cap retard.
El següent punt important és el balanceig de càrrega. Tot això està molt bé si només tens pocs empleats que no saturen la teva amplada de banda. Si en tens 1000, tots accedint al servidor de fitxers regularment, això provocarà límits d'ample de banda per a un únic servidor. Però afortunadament Psono ho pot gestionar. Aquí tens dues opcions que ofereixen els servidors de fitxers de Psono per al balanceig de càrrega.
Potser ja tens un equilibrador de càrrega que vols utilitzar, llavors la teva configuració podria ser així:
Servidor de fitxers balancejat amb equilibrador de càrrega
En aquesta configuració s'utilitza un equilibrador de càrrega per descarregar l'SSL. Dos servidors de fitxers darrere seu gestionen les sol·licituds reals. Tots dos anuncien el mateix shard, així que han de sincronitzar el shard o tenir un emmagatzematge compartit. Es podria utilitzar GlusterFS o un simple rsync.
L'alternativa seria permetre que sigui el mateix client qui balancegi tota la càrrega i així estalviar configurar i costos. Una configuració sense equilibrador de càrrega extra podria ser així:
Servidor de fitxers balancejat sense equilibrador de càrrega
Totes aquestes configuracions es poden apilar, per exemple 3 clústers de 2 servidors cadascun. Cada clúster servint el mateix shard i amb un emmagatzematge sincronitzat (o compartit) per sota.
Espero haver estat capaç de transmetre una bona impressió de totes les capacitats del nou i potent mòdul de servidor de fitxers de Psono.
