Il Problema
Le persone chiedevano un meccanismo sicuro per scambiare file. Oggi siamo orgogliosi di annunciare il nuovo modulo fileserver open source. Come il componente più nuovo nell'ecosistema di Psono, risolve vari problemi:
- I file condivisi tramite posta diventano troppo grandi. Di solito tutto ciò che supera i 20 MB viene rifiutato.
- Il caricamento di file ad altre parti tramite SFTP, email GPG e così via è troppo complesso per gli utenti normali
- Il caricamento di file con l'aiuto di Google Drive o Dropbox può essere problematico per dati sensibili.
- Protezione delle informazioni HR o di gestione dai dipendenti interni, ad esempio gli amministratori del fileserver.
- Hacker che guadagnano accesso al tuo fileserver
- Problemi di larghezza di banda quando lavori in un ambiente di ufficio remoto e tutti scaricano dal tuo piccolo fileserver d'ufficio.
Ed è qui che entra in gioco Psono. Psono è stato progettato con tutti questi problemi in mente ed è estremamente flessibile.
L'Usabilità.
Ok, così come appare per l'utente ti stai chiedendo. Semplice.
- Un utente accede al client web
- seleziona il file
- clicca il pulsante "carica"
- ... e se vuole lo condivide con un clic destro
Spero sia abbastanza semplice.
Sotto al cofano
Sotto al cofano, il client esegue alcuni passaggi più complessi, tutti nascosti all'utente:
- Il client chiede al server tutti i fileserver disponibili
- Il server valuta la richiesta e decide, in base a vari attributi dell'utente (permessi, IP, diritti di accesso) quali shard (posizioni dei file) e fileserver sono adatti
- Il server crea un ticket di caricamento file
- Il client legge la dimensione del file
- Il client annuncia il caricamento del file e dello shard al server
- Il client divide il file in pezzi di massimo 128 MB se il file è troppo grande
- Il client cripta il pezzo
- Il client calcola il checksum del pezzo
- Il client carica il pezzo sul fileserver insieme al ticket di caricamento file
- Il fileserver invia il ticket di caricamento al server
- Il server convalida il ticket
- Il fileserver accetta il caricamento del pezzo
- Il client continua con il pezzo successivo fino a che tutti i pezzi sono stati processati
- Il client aggiorna il proprio datastore, lo cripta e lo invia al server
Con questo meccanismo possiamo risolvere qualsiasi problema di dimensione del file, poiché i file sono suddivisi in pezzi. Possiamo distribuire i caricamenti tra server anche per un singolo file. Tutti i file sono (come tutto il resto su Psono) criptati prima di lasciare il client e vengono inviati al server.
Configurazione Tipica di un Fileserver Psono
La parte superiore mostra una configurazione tipica. Un server relay (un semplice proxy inverso) serve alcuni file statici (il client web). Il Webclient viene servito al browser, che poi chiama gli endpoint API REST sul server. Il server utilizza un database Postgres per memorizzare tutti i dati persistenti. Il Psono Webclient e il Psono Server possono essere considerati senza stato, tutti i dati sono memorizzati nel database Postgres.
Se vuoi allegare ora un fileserver, devi prima creare una configurazione di shard e cluster sul server, che poi puoi utilizzare per configurare il fileserver effettivo. Una volta che il fileserver si avvia, si registrerà automaticamente e continuerà a comunicare la sua disponibilità a intervalli di 10 secondi. Se un fileserver muore, il server lo riconoscerà e smetterà di inviare i client al server morto. Una volta che ritorna, si registrerà automaticamente di nuovo e inizierà a ricevere richieste dai client. Nell'immagine sopra, stiamo memorizzando tutti i pezzi nella memoria locale e abbiamo un server Relay (potrebbe essere lo stesso del server normale, client web in ambienti piccoli) per il carico SSL.
Oltre alla memoria locale, è possibile utilizzare vari backend di archiviazione e persino mescolarli.
Mix di vari backend di archiviazione
Attualmente supportati (oltre alla memoria locale) sono Amazon S3, GCP Cloud Storage e Azure Blob Storage.
È possibile utilizzare più fileserver per risolvere, ad esempio, problemi di prestazioni dovuti alla limitazione della larghezza di banda. Potresti avere persone che lavorano da remoto ma con solo una connessione internet molto sottile nel tuo ufficio. Un altro caso d'uso potrebbe essere che desideri proteggere ancora meglio i file locali e
- non consentire che i file interni vengano caricati su uno storage esterno
- consentire agli esterni di condividere file con gli interni senza un tool diverso
Una configurazione che risolve il problema delle prestazioni e fornisce un miglior isolamento potrebbe apparire così:
Posizione remota
Questa configurazione condivide tutto il traffico dello shard "esterno" tra i siti bidirezionalmente, consentendo agli esterni di caricare file che possono essere successivamente scaricati dai dipendenti e viceversa.
Lo shard on-premise, d'altro canto, non viene mai sincronizzato con la posizione remota e rimane meglio protetto. Poiché i file nello shard "esterno" vengono sincronizzati solo una volta, ogni volta che cambiano potresti avere 100 dipendenti che accedono al file da questo shard senza la necessità di scaricarlo 100 volte dalla posizione remota. Oppure se carichi un file, puoi condividerlo con 100 esterni, senza la necessità di caricarlo 100 volte.
Il vantaggio della larghezza di banda può essere utilizzato anche per collegare posizioni remote con una configurazione simile a questa:
Con due uffici remoti
In questa configurazione ogni sito ha il proprio fileserver e tutti i file sono condivisi tra i siti. Le scritture vanno solo a uno shard specifico, il che consente una sincronizzazione unidirezionale di ogni shard. Questa configurazione permetterebbe alle persone a New York di accedere ai file senza alcun ritardo.
Il prossimo grande punto è il bilanciamento del carico. Tutto questo è utile se hai solo pochi dipendenti che non saturano la tua larghezza di banda. Se hai 1000 dipendenti, tutti abitualmente accedono al fileserver, ciò produrrà limiti di larghezza di banda per un singolo server. Fortunatamente Psono può gestirlo. Ecco due opzioni offerte dal fileserver di Psono per il bilanciamento del carico.
Potresti avere già un bilanciatore di carico che desideri utilizzare, allora la tua configurazione potrebbe apparire così:
Fileserver bilanciato con bilanciatore di carico
In questa configurazione un bilanciatore di carico viene utilizzato per il carico SSL. Due fileserver dietro sono utilizzati per gestire le richieste effettive. Entrambi annunciano lo stesso shard, quindi devono sincronizzare lo shard o avere una memoria condivisa. Si potrebbe utilizzare GlusterFS o un semplice rsync.
L'alternativa sarebbe consentire al client di bilanciare tutto il carico e risparmiare qualche configurazione e costo. Una configurazione senza un bilanciatore di carico extra potrebbe apparire così.
Fileserver bilanciato senza bilanciatore di carico
Tutte queste configurazioni possono essere impilate, ad esempio 3 cluster di 2 server ciascuno. Con ogni cluster che serve lo stesso shard e ha un storage sincronizzato (o condiviso) sotto,
Spero di averti dato una buona impressione delle capacità del nuovo e potente modulo fileserver di Psono.
