Quel est le moyen le plus rapide pour copier 400G de fichiers d'un volume de stockage de bloc élastique ec2 vers s3?

Je dois copier 400G de fichiers d'un volume de stockage de blocs élastiques vers un compartiment s3 ... Ce sont environ 300k fichiers de ~ 1Mb

J'ai essayé s3cmd et s3fuse , les deux sont vraiment, vraiment lents .. s3cmd a fonctionné pendant une journée complète, a déclaré qu'il avait terminé la copie, et quand j'ai vérifié le seau, rien ne s'était passé (je suppose que quelque chose s'est mal passé, mais au moins s3cmd ne s'est jamais plaint de rien)

S3Fuse travaille pour une autre journée complète et a copié moins de 10% des fichiers ...

Existe-t-il une meilleure solution pour cela?

J'utilise Linux (Ubuntu 12.04) bien sûr

Il existe plusieurs facteurs clés qui déterminent le débit de EC2 à S3:

• Taille du fichier - les fichiers plus petits nécessitent un plus grand nombre de demandes et plus de surcharge et de transfert plus lent. Le gain avec la taille de fichier (lorsqu'il provient d'EC2) est négligeable pour les fichiers supérieurs à 256 Ko. (Alors que le transfert à partir d'un emplacement distant, avec une latence plus élevée, a tendance à continuer à montrer des améliorations appréciables jusqu'à entre 1 Mo et 2 Mo).
• Nombre de threads parallèles - un seul thread de téléchargement a généralement un niveau assez faible - souvent inférieur à 5 Mo / s. Le débit augmente avec le nombre de threads simultanés et tend à culminer entre 64 et 128 threads. Il convient de noter que les instances plus importantes sont capables de gérer un plus grand nombre de threads simultanés.
• Taille de l'instance - Conformément aux spécifications de l' instance , les instances plus grandes disposent de ressources plus dédiées, notamment une allocation plus large (et moins variable) de la bande passante du réseau (et des E / S en général - y compris la lecture à partir de disques éphémères / EBS - qui sont connectés au réseau. les valeurs numériques pour chaque catégorie sont:
  • Très élevé: théorique: 10 Gbit / s = 1250 Mo / s; Réaliste: 8,8 Gbps = 1100 Mo / s
  • Élevé: théorique: 1 Gbit / s = 125 Mo / s; Réaliste: 750 Mbps = 95 Mo / s
  • Modéré: théorique: 250 Mbps; Réaliste: 80 Mbps = 10 Mo / s
  • Faible: théorique: 100 Mbps; Réaliste: 10-15Mbps = 1-2MB / s

En cas de transfert de grandes quantités de données, il peut être économiquement pratique d'utiliser une instance de calcul de cluster, car le gain effectif en débit (> 10x) est supérieur à la différence de coût (2-3x).

Bien que les idées ci-dessus soient assez logiques (bien que le plafond par thread ne le soit pas), il est assez facile de trouver des repères pour les sauvegarder. Vous en trouverez un particulièrement détaillé ici .

L'utilisation de 64 à 128 téléchargements parallèles (simultanés) d'objets de 1 Mo devrait saturer la liaison montante 1 Gbit / s qu'un m1.xlarge a et devrait même saturer la liaison montante 10 Gbit / s d'une instance de calcul de cluster (cc1.4xlarge).

Bien qu'il soit assez facile de modifier la taille de l'instance, les deux autres facteurs peuvent être plus difficiles à gérer.

• La taille des fichiers est généralement fixe - nous ne pouvons pas joindre les fichiers ensemble sur EC2 et les séparer sur S3 (donc nous ne pouvons pas faire grand-chose pour les petits fichiers). Cependant, les fichiers volumineux peuvent être séparés du côté EC2 et remontés du côté S3 (en utilisant le téléchargement en plusieurs parties de S3). En règle générale, cela est avantageux pour les fichiers dont la taille est supérieure à 100 Mo.
• Les threads parallèles sont un peu plus difficiles à gérer. L'approche la plus simple revient à écrire un wrapper pour un script de téléchargement existant qui en exécutera plusieurs copies à la fois. De meilleures approches utilisent directement l'API pour accomplir quelque chose de similaire. En gardant à l'esprit que la clé est des requêtes parallèles, il n'est pas difficile de localiser plusieurs scripts potentiels, par exemple:
  • s3cmd-modification - un fork d'une première version de s3cmd qui a ajouté cette fonctionnalité, mais n'a pas été mis à jour depuis plusieurs années.
  • s3-parallel-put - script python raisonnablement récent qui fonctionne bien

Ainsi, après de nombreux tests, le s3-parallel-put a fait l'affaire de manière impressionnante. Clairement la solution si vous avez besoin de télécharger un grand nombre de fichiers sur S3. Merci à cyberx86 pour les commentaires.

Ajustez les valeurs de configuration AWS CLI S3 selon http://docs.aws.amazon.com/cli/latest/topic/s3-config.html .

Ce qui suit a augmenté la vitesse de synchronisation S3 d'au moins 8x!

Exemple:

$ more ~/.aws/config
[default]
aws_access_key_id=foo
aws_secret_access_key=bar
s3 =
   max_concurrent_requests = 100
   max_queue_size = 30000

J'ai écrit une application console optimisée en C # ( CopyFasterToS3 ) pour ce faire. J'ai utilisé dans EBS vol, dans mon cas, il avait 5 dossiers avec plus de 2 millions de fichiers pour un montant de 20 Go. Le script exécuté en moins de 30 minutes.

Dans cet article, j'ai montré comment utiliser une fonction récursive avec parallèle. Vous pouvez le transcrire dans une autre langue.

Bonne chance!

Il y a aussi: s3funnel , qui semble très ancien (2008) et quelques bugs ouverts, mais qui est toujours répertorié sur Amazon lui - même: amzn-lnk

Essayez plutôt s4cmd, c'est vraiment plus rapide que s3cmd. Son adresse: https://github.com/bloomreach/s4cmd

Essayez d'utiliser s3-cli au lieu de s3cmd. Je l'ai utilisé au lieu de s3cmd pour télécharger des fichiers dans mon compartiment s3 et cela a rendu mon déploiement plus rapide de près de 17 minutes (de 21 à 4 minutes)!

Voici le lien: https://github.com/andrewrk/node-s3-cli