Il y a un bon article sur s3fs ici, qu'après avoir lu, j'ai eu recours à un partage EBS.
Il met en évidence quelques considérations importantes lors de l'utilisation de s3fs, notamment liées aux limitations inhérentes à S3 :
- aucun fichier ne peut dépasser 5 Go
- vous ne pouvez pas mettre à jour partiellement un fichier, donc la modification d'un seul octet réimportera le fichier entier.
- les opérations sur de nombreux petits fichiers sont très efficaces (chacun est un objet S3 distinct après tout), mais les gros fichiers sont très inefficaces
- Bien que S3 prenne en charge les téléchargements partiels/fragmentés, s3fs n'en profite pas. Par conséquent, si vous souhaitez lire un seul octet d'un fichier de 1 Go, vous devrez télécharger l'intégralité du Go.
Cela dépend donc de ce que vous stockez si s3fs est une option réalisable. Si vous stockez, par exemple, des photos, où vous voulez écrire un fichier entier ou lire un fichier entier, ne modifiez jamais un fichier de manière incrémentielle, alors c'est bien, bien que l'on puisse se demander, si vous faites cela, alors pourquoi ne pas simplement utiliser S3 API directement ?
Si vous parlez de données d'application (par exemple, des fichiers de base de données, des fichiers de journalisation) où vous souhaitez effectuer de petites modifications incrémentielles, alors c'est définitivement non - S3 ne fonctionne tout simplement pas de cette façon, vous ne pouvez pas modifier un fichier de manière incrémentielle.
L'article mentionné ci-dessus parle d'une application similaire - s3backer - qui contourne les problèmes de performances en implémentant un système de fichiers virtuel sur S3. Cela contourne les problèmes de performances, mais a lui-même quelques problèmes :
- Risque élevé de corruption des données, en raison des écritures retardées
- des tailles de bloc trop petites (par exemple, le 4K par défaut) peuvent entraîner des coûts supplémentaires importants (par exemple, 130 $ pour 50 Go avec des blocs de 4K de stockage)
- des tailles de bloc trop importantes peuvent entraîner des frais de transfert et de stockage de données importants.
- l'utilisation de la mémoire peut être prohibitive :par défaut, il met en cache 1 000 blocs.
Avec la taille de bloc 4K par défaut, ce n'est pas un problème, mais la plupart des utilisateurs
voudra probablement augmenter la taille des blocs.
J'ai eu recours à EBS Mounted Drived partagé à partir d'une instance EC2. Mais vous devez savoir que bien qu'il s'agisse de l'option la plus performante, elle présente un gros problème. Un partage NFS monté sur EBS a ses propres problèmes - un point de défaillance unique ; si la machine qui partage le volume EBS tombe en panne, vous perdez l'accès à toutes les machines qui accèdent au partage.
C'est un risque avec lequel j'ai pu vivre et c'est finalement l'option que j'ai choisie. J'espère que cela vous aidera.
C'est une vieille question, je vais donc partager mon expérience de l'année dernière avec S3FS.
Au départ, il y avait un certain nombre de bogues et de fuites de mémoire (j'avais un cron-job pour le redémarrer toutes les 2 heures) mais avec la dernière version 1.73, il a été très stable.
La meilleure chose à propos de S3FS est que vous avez une chose de moins à vous soucier et que vous bénéficiez gratuitement de certains avantages en termes de performances.
La plupart de vos requêtes S3 seront PUT (~5%) et GET (~95%). Si vous n'avez pas besoin de post-traitement (génération de vignettes par exemple). Si vous n'avez pas besoin de post-traitement, vous ne devriez pas accéder à votre serveur Web en premier lieu et télécharger directement sur S3 (à l'aide de CORS).
En supposant que vous atteignez le serveur, cela signifie probablement que vous devez effectuer un post-traitement sur les images. Avec une API S3, vous téléchargerez sur le serveur, puis vous téléchargerez sur S3. Si l'utilisateur veut recadrer, vous devrez télécharger à nouveau depuis S3, puis re-télécharger sur le serveur, recadrer, puis télécharger sur S3. Avec S3FS et la mise en cache locale activées, cette orchestration est prise en charge pour vous et évite le téléchargement de fichiers depuis S3.
Lors de la mise en cache, si vous mettez en cache sur un lecteur éphémère sur EC2, vous bénéficiez des avantages de performances qui en découlent et pouvez purger votre cache sans avoir à vous soucier de quoi que ce soit. À moins que vous ne manquiez d'espace disque, vous ne devriez avoir aucune raison de purger votre cache. Cela facilite grandement les opérations de déplacement telles que la recherche et le filtrage.
La seule chose que je souhaite qu'il ait, c'est une synchronisation complète avec S3 (style RSync). Cela en ferait une version d'entreprise de DropBox ou de Google Drive pour S3, mais sans avoir à faire face aux quotas et aux frais qui l'accompagnent.