Dans quelle mesure s3fs est-il stable pour monter un compartiment Amazon S3 en tant que répertoire local
Dans quelle mesure s3fs est-il stable pour monter un compartiment Amazon S3 en tant que répertoire local sous Linux? Est-il recommandé/stable pour les environnements de production à forte demande?
Existe-t-il des solutions meilleures/similaires?
Mise à jour: Serait-il préférable d'utiliser EBS et de le monter via NFS sur tous les autres AMI?
Il y a un bon article sur s3fs ici , après avoir lu, j'ai eu recours à un partage EBS.
Il souligne quelques considérations importantes lors de l’utilisation de s3fs, notamment en ce qui concerne les limitations inhérentes à S3:
- aucun fichier ne peut dépasser 5 Go
- vous ne pouvez pas mettre à jour partiellement un fichier; par conséquent, modifier un seul octet permettra de télécharger à nouveau le fichier entier.
- les opérations sur de nombreux petits fichiers sont très efficaces (chaque objet est un objet S3 distinct), 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 devez 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 dans lesquelles vous souhaitez écrire un fichier entier ou lire un fichier entier, ne modifiez jamais de manière incrémentielle un fichier. API directement?
Si vous parlez de données d'application (fichiers de base de données, fichiers de journalisation, par exemple) où vous souhaitez apporter de petites modifications incrémentielles, alors c'est un non catégorique.
L'article mentionné ci-dessus parle d'une application similaire, s3backer , qui résout 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 de données, en raison du retard d'écriture
- des tailles de bloc trop petites (par exemple, la valeur par défaut de 4 Ko) peuvent engendrer des coûts supplémentaires importants (par exemple, 130 USD pour 50 Go de stockage avec des blocs de 4 Ko)
- une taille de bloc trop grande peut 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 1000 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 du bloc.
J'ai eu recours à EBS Mounted Drived partagé à partir d'une instance EC2. Mais vous devez savoir que même si l’option la plus performante a 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 sur toutes les machines qui accèdent au partage.
C’est un risque que j’ai pu vivre et c’est l’option que j’ai finalement choisie. J'espère que ça aide.
C'est une vieille question, je vais donc partager mon expérience de l'année passée avec S3FS.
Au départ, il y avait un certain nombre de bugs et de fuites de mémoire (je devais le redémarrer toutes les 2 heures), mais avec la dernière version 1.73, le système était très stable.
La meilleure chose à propos de S3FS est que vous devez vous préoccuper de moins de choses et obtenir des avantages en termes de performances gratuitement.
La plupart de vos demandes S3 vont être 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 frapper votre serveur Web en premier lieu et le télécharger directement sur S3 (en utilisant CORS).
En supposant que vous frappiez le serveur, cela signifie probablement que vous devez effectuer un post-traitement sur les images. Avec une API S3, vous téléchargez sur le serveur, puis sur S3. Si l'utilisateur souhaite rogner, vous devrez le télécharger à nouveau à partir de S3, puis le télécharger à nouveau sur le serveur, le rogner puis le télécharger vers S3. Avec S3FS et la mise en cache locale activée, cette orchestration est prise en charge pour vous et enregistre les fichiers téléchargés à partir de 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 en termes de performances qui viennent avec out et vous pouvez purger votre cache sans vous soucier de rien. Sauf si vous manquez d'espace disque, vous ne devriez avoir aucune raison de purger votre cache. Cela facilite beaucoup les opérations telles que la recherche et le filtrage.
La seule chose que je souhaiterais, c’est la synchronisation complète avec S3 (style RSync). Cela en ferait une version d'entreprise de DropBox ou de Google Drive pour S3, sans avoir à faire face aux quotas et aux frais qui vont avec.