Rédiger des transferts de production

Présentation

Si vous utilisez gsutil dans des tâches de production importantes (telles que l'importation ou le téléchargement de nombreux Gio de données chaque nuit), vous pouvez effectuer un certain nombre d'opérations pour garantir votre réussite. Plus précisément, cette section explique comment rédiger des tâches de production volumineuses autour du mécanisme de transfert avec reprise de gsutil.

Informations sur les transferts avec reprise

Tout d'abord, il est utile de comprendre le mécanisme de transfert avec reprise de gsutil et de savoir comment votre script doit être mis en œuvre autour de ce mécanisme pour fonctionner de manière fiable. gsutil utilise la fonctionnalité de transfert avec reprise dès que vous tentez de télécharger un fichier d'une taille quelconque ou d'importer un fichier dépassant un seuil configurable (par défaut, ce seuil est de 8 Mio). Si un transfert échoue en cours de traitement (par exemple, en raison d'un problème de réseau intermittent), gsutil utilise alors une stratégie d'intervalle exponentiel binaire randomisé et tronqué entre les tentatives. Par défaut, le transfert sera retenté jusqu'à 23 fois en l'espace de 10 minutes (pour en savoir plus, consultez l'aide gsutil sur les nouvelles tentatives). Si le transfert échoue à chacune de ces tentatives sans aucune progression intermédiaire, gsutil abandonne le transfert, mais conserve un fichier de suivi dans un emplacement configurable (l'emplacement par défaut est ~/.gsutil/, dans un fichier dont le nom est une combinaison du hachage SHA1 du nom du bucket et de l'objet transféré, et des 16 derniers caractères du nom de fichier). Lorsque les transferts échouent de cette manière, vous pouvez relancer gsutil ultérieurement (par exemple, une fois le problème réseau résolu) pour que le transfert avec reprise reprenne là où il s'est arrêté.

Créer des scripts pour les tâches de transfert de données

Pour rédiger des tâches de transfert de données de production volumineuses qui suivent ce mécanisme, vous pouvez mettre en œuvre un script qui s'exécute régulièrement, détermine les transferts de fichiers qui n'ont pas encore abouti et exécute gsutil pour les copier. Vous trouverez ci-dessous un certain nombre de suggestions pour la mise en œuvre de ce type de script :

  1. Lorsque les transferts avec reprise échouent sans aucune progression 23 fois de suite en l'espace de 10 minutes, une nouvelle tentative de transfert immédiate n'aboutira généralement pas. Il devrait s'avérer plus efficace d'avoir une tâche Cron qui s'exécute toutes les 30 minutes et détermine les transferts à exécuter, puis qui les exécute. Si le réseau rencontre des problèmes occasionnels, le script reprendra là où il en était et finira par aboutir (une fois le problème réseau résolu).

  2. Si votre entreprise mise sur un transfert ponctuel des données, envisagez de mettre en place une surveillance réseau. Par exemple, vous pouvez mettre en œuvre une tâche qui tente un petit téléchargement toutes les deux ou trois minutes et déclenche une alerte si la tentative échoue plusieurs fois de suite (ou plus ou moins souvent selon vos exigences), permettant ainsi à votre personnel informatique d'analyser les problèmes rapidement. Comme c'est habituellement le cas avec les mises en œuvre de surveillance, vous devez tester les seuils d'alerte afin d'éviter que de fausses alertes répétées ne poussent votre personnel à ignorer les alertes.

  3. Il existe différentes manières vous permettant de déterminer les fichiers à transférer. Nous vous déconseillons de chercher à obtenir une liste complète d'un bucket contenant de nombreux objets (par exemple, des dizaines de milliers ou plus). Une stratégie consiste à structurer vos noms d'objets d'une manière qui représente votre processus de transfert, et à demander des listes de buckets partiels en utilisant des caractères génériques de préfixe gsutil. Par exemple, si votre processus périodique implique le téléchargement des objets de la journée en cours, vous pouvez nommer les objets au format année-mois-jour-ID-objet, puis rechercher les objets du jour en utilisant une commande telle que gsutil ls "gs://bucket/2011-09-27-*". Notez qu'il est plus efficace d'avoir un préfixe non générique comme celui-ci plutôt que d'utiliser gsutil ls "gs://bucket/*-2011/09-27". La dernière commande demande en effet une liste complète des buckets qu'elle filtre ensuite dans gsutil, tandis que la première demande à Google Storage de renvoyer le sous-ensemble d'objets dont le nom commence par "*".

    Pour les importations de données, vous pouvez suivre une autre technique consistant à déplacer les fichiers locaux d'une zone "à traiter" vers une zone "terminée" à mesure que votre script copie avec succès les fichiers sur le cloud. Vous pouvez effectuer cette opération par lots parallèles à l'aide d'une commande telle que :

    gsutil -m cp -r to_upload/subdir_$i gs://bucket/subdir_$i
    

    où i est une variable de boucle d'interface système. Vérifiez bien que la variable d'état ($status) d'interface système est 0 après chaque commande gsutil cp pour détecter si certaines copies ont échoué, et réexécutez les copies concernées.

    Avec cette stratégie, le système de fichiers conserve une trace de tous les travaux restants à effectuer.

  4. Si vous avez un très grand nombre d'objets dans un seul bucket (des centaines de milliers ou plus, par exemple), envisagez d'en faire un suivi dans une base de données au lieu d'utiliser des listes de buckets pour les énumérer. Cette base de données pourrait par exemple suivre l'état de vos téléchargements. Vous pourriez ainsi déterminer quels objets doivent être téléchargés par votre script de téléchargement périodique en interrogeant la base de données localement au lieu de dresser une liste des buckets.

  5. Assurez-vous de ne pas supprimer les fichiers temporaires partiellement téléchargés après un échec de transfert. En effet, gsutil reprend là où il s'était arrêté (et effectue un hachage du contenu final téléchargé pour garantir l'intégrité des données) ; en supprimant des fichiers partiellement transférés, vous perdriez votre progression et utiliseriez votre réseau de façon inefficace.

  6. Si vous disposez d'une connexion réseau rapide, vous pouvez accélérer le transfert d'un grand nombre de fichiers à l'aide de l'option gsutil -m (multithread/multitraitement). Sachez toutefois qu'en cas d'échec du téléchargement de certains fichiers, gsutil n'essaie pas de savoir quels fichiers ont été téléchargés. Par exemple, si vous utilisez des transferts multithread pour télécharger 100 fichiers et que 3 n'ont pas pu être téléchargés, c'est à votre processus de script de déterminer les transferts qui ont échoué et d'effectuer une nouvelle tentative. Une approche périodique telle que décrite plus haut, qui procède à la vérification et au traitement des transferts nécessaires, conviendrait à ce cas d'utilisation.

    Si vous utilisez des transferts parallèles (gsutil -m), vous pourrez tester le nombre de threads utilisés (via le paramètre parallel_thread_count dans le fichier de configuration .boto). Par défaut, gsutil utilise 10 threads pour Linux et 24 threads pour les autres systèmes d'exploitation. En fonction de la vitesse de votre réseau, de la mémoire disponible, de la charge du processeur et d'autres conditions, ce processus peut s'avérer plus ou moins optimal. Faites des tests avec un nombre de threads plus ou moins élevé pour trouver le nombre de threads optimal pour votre environnement.