39 votes

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 toutes les autres AMI?

51voto

reach4thelasers Points 7375

Il y a un bon article sur s3fs ici, qui après lecture, j'ai eu recours à une EBS Partager.

Il met en évidence quelques considérations importantes lors de l'utilisation de s3fs, notamment sur les limites inhérentes au S3:

  • aucun fichier ne peut être plus de 5 GO
  • vous ne pouvez pas partiellement mise à jour d'un fichier de sorte qu'un changement d'un seul octet sera re-télécharger le fichier en entier.
  • opération sur un grand nombre de petits fichiers sont très efficaces (chacun est séparé S3 objet, après tout), mais les gros fichiers sont très inefficace
  • Si S3 prend en charge partielle/chunked téléchargements, s3fs ne pas prendre avantage de cela, donc si vous voulez lire un octet d'un fichier de 1 go, vous devrez télécharger l'ensemble de la GB.

Il dépend donc de ce que vous êtes stockage si s3fs est une option réalisable. Si vous êtes le stockage de dire, de photos, où vous voulez écrire un fichier ou lire le fichier en entier jamais progressivement la modification d'un fichier, puis son amende, bien que l'on peut se poser, si vous faites cela, alors pourquoi ne pas simplement utiliser S3 Directement l'API?

Si vous parlez d'inscription des données, (dire des fichiers de base de données, fichiers de journalisation) où vous voulez faire de petits changements progressifs ensuite ses un non catégorique - S3 ne fonctionne tout Simplement pas de cette façon, vous ne pouvez pas progressivement la modification d'un fichier.

L'article mentionné ci-dessus parle d'une application similaire - s3backer - qui permet de contourner les problèmes de performances par la mise en œuvre d'un système de fichiers virtuel sur S3. Cela permet de contourner les problèmes de performances, mais lui-même a quelques problèmes de son propre:

  • Haut risque de corruption de données, en raison du retard de l'écrit
  • trop de petites tailles de bloc (par exemple, la 4K par défaut) peut ajouter beaucoup de des coûts supplémentaires (par exemple, 130 $pour 50 go avec des blocs de 4K de dollars de stockage)
  • trop de grandes tailles de bloc peut ajouter beaucoup de transfert de données et de stockage les frais d'.
  • l'utilisation de la mémoire peut être prohibitif: par défaut il met en cache 1000 blocs.
    Avec la valeur par défaut 4K taille de bloc n'est pas un problème, mais la plupart des utilisateurs
    voudrez probablement pour augmenter la taille du bloc.

J'ai eu recours à l'EBS Monté a Mené partagé à partir d'une instance EC2. Mais vous devez savoir que, bien que les plus performantes en option, il a un gros problème EBS Monté Partage NFS a ses propres problèmes - un point de défaillance unique; si la machine qui partage le Volume EBS va vers le bas, puis vous perdez l'accès sur toutes les machines accéder au partage.

C'est un risque que j'ai pu vivre avec et est l'option que j'ai choisi à la fin. J'espère que cette aide.

8voto

aleemb Points 12138

C'est une vieille question, donc je vais partager mon expérience au cours de la dernière année avec S3FS.

Initialement, il avait un certain nombre de bugs et les fuites de mémoire (j'ai eu un cron job de le redémarrer toutes les 2 heures), mais avec la dernière version 1.73 c'est très stable.

La meilleure chose à propos de S3FS est que vous avez un moins de choses à s'inquiéter et obtenir certains avantages de performance pour gratuit.

La plupart de votre S3 demandes vont être MIS (~5%) et GET (~95%). Si vous n'avez pas besoin de post-traitement (la 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 de télécharger directement à S3 (à l'aide de la SCRO).

En supposant que vous avez sur le serveur signifie probablement que vous avez besoin de faire un peu de post-traitement sur les images. Avec un S3 API, vous serez en téléchargement sur le serveur, puis de télécharger les S3. Si l'utilisateur le veut la culture, vous aurez besoin de télécharger à nouveau à partir de S3, puis re-télécharger vers le serveur, la culture et ensuite télécharger sur S3. Avec S3FS et locaux de la mise en cache activée sur cette orchestration est pris en charge pour vous et enregistre le téléchargement de fichiers à partir de S3.

Sur la mise en cache, si vous êtes à la mise en cache pour une éphémère lecteur sur EC2, vous obtenez les avantages de performances qui viennent avec et pouvez vider votre cache, sans avoir à vous soucier de quoi que ce soit. Sauf si vous manquez d'espace disque, vous devez avoir aucune raison de purger votre cache. Cela rend la traversée des opérations comme la recherche et de filtrage beaucoup plus facile.

La seule chose que je ne souhaite cela a été synchronisation complète avec S3 (RSync style). Ce qui en ferait un enterprise version de DropBox ou Google Drive pour les S3, mais sans avoir à composer avec les quotas et les taxes qui vont avec.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by: