Le Problème
Les gens demandaient un mécanisme sécurisé pour échanger des fichiers. Aujourd'hui, nous sommes fiers d'annoncer le nouveau module de serveur de fichiers open source. En tant que dernier composant de l'écosystème de Psono, il résout plusieurs problèmes :
- Les fichiers partagés par mail deviennent trop gros. Généralement, tout ce qui dépasse 20 Mo est rejeté.
- Le téléchargement de fichiers vers d'autres parties via SFTP, mails GPG, etc., est trop complexe pour les utilisateurs normaux.
- Le téléchargement de fichiers avec l'aide de Google Drive ou Dropbox peut poser des problèmes pour les données sensibles.
- Protection des informations RH ou de gestion contre les employés internes, par exemple les administrateurs de serveurs de fichiers.
- Piratage accédant à votre serveur de fichiers.
- Problèmes de bande passante lorsque vous travaillez dans un environnement de bureau à distance et que tout le monde télécharge depuis votre petit serveur de fichiers de bureau.
C'est là que Psono entre en jeu. Psono a été conçu en tenant compte de tous ces problèmes et est extrêmement flexible.
L'Utilisabilité
D'accord, à quoi cela ressemble pour l'utilisateur, demandez-vous. Simple.
- Un utilisateur accède au client web
- sélectionne le fichier
- clique sur le bouton "télécharger"
- ... et s'il le souhaite, il le partage d'un clic droit
C'est assez simple j'espère.
Sous le capot
Sous le capot, le client effectue des étapes plus complexes, mais toutes sont cachées de l'utilisateur :
- Le client demande au serveur tous les serveurs de fichiers disponibles
- Le serveur évalue la demande et décide, en fonction de divers attributs utilisateur (permissions, IP, droits d'accès), quels shards (emplacements de fichiers) et serveurs de fichiers sont appropriés
- Le serveur crée un ticket d'upload de fichier
- Le client lit la taille du fichier
- Le client annonce le téléchargement du fichier et du shard au serveur
- Le client divise le fichier en morceaux d'un maximum de 128 Mo si le fichier est trop gros
- Le client chiffre le morceau
- Le client calcule le checksum du morceau
- Le client télécharge le morceau sur le serveur de fichiers avec le ticket d'upload de fichier
- Le serveur de fichiers envoie le ticket d'upload au serveur
- Le serveur valide le ticket
- Le serveur de fichiers accepte le téléchargement du morceau
- Le client continue avec le morceau suivant jusqu'à ce que tous les morceaux soient traités
- Le client met à jour son datastore, le chiffre et l'envoie au serveur
Avec ce mécanisme, nous pouvons résoudre tout problème de taille de fichier, car les fichiers sont divisés en morceaux. Nous pouvons distribuer les téléchargements sur plusieurs serveurs, même pour un seul fichier. Tous les fichiers sont (comme tout le reste chez Psono) chiffrés avant de quitter le client et envoyés au serveur.
Configuration typique du serveur de fichiers Psono
La partie supérieure montre une configuration typique. Un serveur relais (un simple proxy inverse) sert quelques fichiers statiques (le client web). Le client web est servi au navigateur, qui appelle ensuite les points d'API REST sur le serveur. Le serveur utilise une base de données Postgres pour stocker toutes les données persistantes. Le client web Psono et le serveur Psono peuvent être considérés comme sans état, toutes les données étant stockées dans la base de données Postgres.
Si vous souhaitez maintenant ajouter un serveur de fichiers, vous devez d'abord créer une configuration de shard et de cluster sur le serveur, que vous pouvez ensuite utiliser pour configurer le serveur de fichiers réel. Une fois le serveur de fichiers démarré, il s'enregistrera automatiquement et continuera à annoncer sa disponibilité à des intervalles de 10 secondes. Si un serveur de fichiers tombe en panne, le serveur le reconnaîtra et cessera d'envoyer des clients au serveur en panne. Lorsqu'il revient, il s'enregistre automatiquement à nouveau et commence à recevoir des requêtes de clients. Dans l'image ci-dessus, nous stockons tous les morceaux dans le stockage local et avons un serveur relais (qui pourrait être le même que pour le serveur normal, client web dans les petits environnements) pour le déchargement SSL.
En plus du stockage local, vous pouvez utiliser divers backends de stockage et même les mélanger.
Mélange de divers backends de stockage
Actuellement pris en charge (en plus du stockage local) sont Amazon S3, GCP Cloud Storage et Azure Blob Storage.
Vous pouvez utiliser plusieurs serveurs de fichiers afin de résoudre par exemple des problèmes de performance dus à une limitation de la bande passante. Vous pourriez avoir des personnes travaillant à distance avec une connexion internet très limitée dans votre bureau. Un autre cas d'utilisation pourrait être que vous souhaitez protéger encore mieux les fichiers locaux et
- ne pas autoriser les fichiers internes à être téléchargés sur un stockage externe
- permettre aux externes de partager des fichiers avec des internes sans outil différent
Une configuration qui résout le problème de performance et vous offre une meilleure isolation pourrait ressembler à ceci :
Localisation à distance
Cette configuration partage tout le trafic du shard "externe" entre les sites de manière bidirectionnelle, permettant aux externes de télécharger des fichiers qui peuvent ensuite être téléchargés par les employés et vice-versa.
Le shard sur site, en revanche, n'est jamais synchronisé avec l'emplacement distant et reste mieux protégé. Comme les fichiers dans le shard "externe" ne sont synchronisés qu'une fois, chaque fois qu'ils changent, vous pourriez avoir 100 employés accédant au fichier depuis ce shard sans avoir besoin de le télécharger 100 fois depuis l'emplacement distant. Ou si vous téléchargez un fichier, vous pouvez le partager avec 100 externes, sans avoir besoin de le télécharger 100 fois.
L'avantage de la bande passante peut également être utilisé pour connecter des emplacements distants avec une configuration similaire à celle-ci :
Avec deux bureaux distants
Dans cette configuration, chaque site dispose de son propre serveur de fichiers, et tous les fichiers sont partagés entre les sites. Les écritures ne vont qu'à un shard spécifique, ce qui permet une synchronisation unidirectionnelle de chaque shard. Cette configuration permettrait aux gens à New York d'accéder aux fichiers sans aucun délai.
Le prochain gros point est l'équilibrage de la charge. Tout cela est bien si vous avez juste quelques employés qui ne saturent pas votre bande passante. Si vous avez 1000 employés accédant régulièrement au serveur de fichiers, cela produira des limites de bande passante pour un seul serveur. Heureusement, Psono peut gérer cela. Voici deux options offertes par le serveur de fichiers de Psono pour l'équilibrage de la charge.
Vous avez peut-être déjà un équilibrage de charge que vous souhaitez utiliser, alors votre configuration pourrait ressembler à ceci :
Serveur de fichiers équilibré avec équilibrage de charge
Dans cette configuration, un équilibrage de charge est utilisé pour le déchargement SSL. Deux serveurs de fichiers derrière sont utilisés pour gérer les requêtes réelles. Tous deux annoncent le même shard, ils doivent donc soit synchroniser le shard, soit avoir un stockage partagé. On pourrait utiliser GlusterFS ou un simple rsync.
L'alternative serait de permettre au client d'équilibrer la charge de tout et d'économiser sur la configuration et les coûts. Une configuration sans un équilibrage de charge supplémentaire pourrait ressembler à ceci.
Serveur de fichiers équilibré sans équilibrage de charge
Toutes ces configurations peuvent être empilées, par exemple 3 clusters de 2 serveurs chacun. Chaque cluster servant le même shard et ayant un stockage synchronisé (ou partagé) en dessous,
J'espère avoir pu vous donner une bonne impression des capacités du nouveau et puissant module de serveur de fichiers de Psono.
