Partager via

Résoudre les problèmes dans AzCopy v10

  • Article

Cet article traite des problèmes courants que vous pouvez rencontrer lorsque vous utilisez AzCopy. Cet article vous aide également à identifier les causes des problèmes et suggère comment les résoudre.

Identification des problèmes

Vous pouvez déterminer si un travail réussit en examinant le code de sortie.

Si le code de sortie est , le travail s’est 0-successterminé avec succès.

Si le code de sortie est 1-error, examinez le fichier journal. Une fois que vous avez compris le message d’erreur exact, vous pouvez plus facilement rechercher les mots clés appropriés et déterminer la solution. Pour en savoir plus, consultez Rechercher des erreurs et reprendre des travaux à l’aide des fichiers journaux et de plan dans AzCopy.

Si le code de sortie est 2-panic, vérifiez si le fichier journal existe. Si le fichier n’existe pas, signalez un bogue ou contactez le support.

Tout autre code de sortie différent de zéro (par exemple OOMKilled) peut être généré par le système. Consultez la documentation de votre système d’exploitation pour connaître les codes de sortie spéciaux.

Erreurs « 403 »

Les erreurs « 403 » sont courantes. Parfois, ils sont bénins et ne provoquent pas d’échec de transfert. Par exemple, dans les journaux AzCopy, vous pouvez voir qu’une demande a reçu des HEAD erreurs « 403 ». Ces erreurs apparaissent lorsque AzCopy vérifie si une ressource est publique. Dans la plupart des cas, vous pouvez ignorer ces instances.

Dans certains cas, les erreurs « 403 » peuvent entraîner un transfert ayant échoué. Si ce problème se produit, d’autres tentatives de transfert de fichiers risquent d’échouer jusqu’à ce que vous résolvez le problème. Les erreurs « 403 » peuvent être provoquées par des problèmes d’authentification et d’autorisation. Ils peuvent également se produire si les demandes sont bloquées par la configuration du pare-feu du compte de stockage.

Problèmes d’authentification et d’autorisation

Les erreurs « 403 » qui empêchent le transfert de données se produisent en raison de problèmes impliquant des jetons SAP, des rôles de contrôle d’accès en fonction du rôle (Azure RBAC) et des configurations de liste de contrôle d’accès (ACL).

Jetons SAS

Si vous utilisez un jeton de signature d’accès partagé (SAP), vérifiez que les instructions suivantes sont vraies :

  • Les heures d’expiration et de début du jeton SAP sont appropriées.

  • Vous avez sélectionné toutes les autorisations nécessaires pour le jeton.

  • Vous avez généré le jeton à l’aide d’un SDK ou d’un outil officiel. Essayez l’Explorateur Stockage si vous ne l’avez pas déjà fait.

Azure RBAC

Si vous utilisez des rôles RBAC Azure via la azcopy login commande, vérifiez que vous disposez des rôles Azure appropriés attribués à votre identité (par exemple, le rôle Contributeur aux données blob de stockage).

Pour en savoir plus sur les rôles Azure, consultez Attribuer un rôle Azure pour l’accès aux données d’objet blob.

listes de contrôle d'accès

Si vous utilisez des listes de contrôle d’accès (ACL), vérifiez que votre identité apparaît dans une entrée de liste de contrôle d’accès pour chaque fichier ou répertoire auquel vous avez l’intention d’accéder. Vérifiez également que chaque entrée de la liste de contrôle d’accès reflète le niveau d’autorisation approprié.

Pour en savoir plus sur les listes et les entrées ACL, consultez Listes de contrôle d’accès (ACL) dans Azure Data Lake Storage Gen2.

Pour en savoir davantage sur l’incorporation de rôles Azure avec les listes de contrôle d’accès et sur la façon dont le système les évalue pour prendre des décisions d’autorisation, consultez la section Modèle de contrôle d’accès dans Azure Data Lake Storage Gen2.

Problèmes liés au pare-feu et au point de terminaison privé

Si la configuration du pare-feu de stockage n’autorise pas l’accès à partir du composant d’hébergement sur lequel AzCopy est en cours d’exécution, les opérations AzCopy retournent un code d’erreur HTTP « 403 ».

Note

Dans cet article, le composant d’hébergement désigne un ordinateur physique, une machine virtuelle ou un conteneur.

Étendue autorisée pour les opérations de copie

La AllowedCopyScope propriété d’un compte de stockage est utilisée pour spécifier les environnements à partir desquels vous pouvez copier des données vers le compte de destination. Cette propriété s’affiche dans la Portail Azure comme étendue autorisée pour le paramètre de configuration des opérations de copie (préversion). Par défaut, la propriété n’a pas de valeur. La propriété ne retourne pas de valeur tant que vous ne l’avez pas définie explicitement. La AllowedCopyScope propriété a trois valeurs possibles, comme indiqué dans le tableau suivant.

Valeur Description
(null) (Valeur par défaut) Autorise la copie à partir de n’importe quel compte de stockage vers le compte de destination.
Microsoft Entra ID Autorise la copie à partir de comptes qui se trouvent dans le même locataire Microsoft Entra que le compte de destination.
PrivateLink Autorise la copie à partir de comptes de stockage uniquement qui ont des liens privés vers le même réseau virtuel que le compte de destination.

Pour plus d’informations sur cette propriété et son paramètre de configuration associé, consultez Restreindre la source des opérations de copie à un compte de stockage.

Transférer des données depuis ou vers un composant d’hébergement local

Si vous chargez ou téléchargez des données entre un compte de stockage et un composant d’hébergement local, assurez-vous que le composant d’hébergement qui exécute AzCopy peut accéder au compte de stockage source ou de destination. Vous devrez peut-être utiliser des règles de réseau IP dans les paramètres de pare-feu des comptes source ou de destination pour autoriser l’accès à partir de l’adresse IP publique du composant d’hébergement.

Transférer des données entre des comptes de stockage

Les erreurs d’autorisation « 403 » peuvent vous empêcher de transférer des données entre des comptes à l’aide du composant d’hébergement du client sur lequel AzCopy est en cours d’exécution.

Si vous copiez des données entre des comptes de stockage, assurez-vous que le composant d’hébergement qui exécute AzCopy peut accéder à la fois à la source et au compte de destination. Vous devrez peut-être utiliser des règles de réseau IP dans les paramètres de pare-feu des comptes source et de destination pour autoriser l’accès à partir de l’adresse IP publique du composant d’hébergement. Le service utilise l’adresse IP du composant d’hébergement du client AzCopy pour autoriser la source au trafic de destination. Pour savoir comment ajouter une adresse IP publique aux paramètres de pare-feu d’un compte de stockage, consultez Accorder l’accès à partir d’une plage d’adresses IP Internet.

Si votre machine virtuelle n’a pas ou ne peut pas avoir d’adresse IP publique, envisagez d’utiliser un point de terminaison privé. Consultez Utiliser des points de terminaison privés pour Stockage Azure.

Private Link est au niveau du réseau virtuel/du sous-réseau. Si vous souhaitez que les demandes AzCopy passent par Private Link, AzCopy doit effectuer ces demandes à partir d’une machine virtuelle qui s’exécute dans ce réseau virtuel/sous-réseau. Par exemple, supposons que vous configurez Private Link dans VNet1/Subnet1, mais que la machine virtuelle sur laquelle AzCopy s’exécute se trouve dans VNet1/Subnet2. Dans ce scénario, les requêtes AzCopy n’utilisent pas Private Link et les requêtes sont censées échouer.

Si vous rencontrez des erreurs TCP telles que « dial tcp : lookup proxy.x.x : aucun hôte de ce type », cela signifie que votre environnement n’est pas configuré pour utiliser le proxy correct ou que vous utilisez un proxy avancé que AzCopy ne reconnaît pas.

Vous devez mettre à jour les paramètres du proxy pour refléter les configurations correctes. Consultez Configurer les paramètres de proxy.

Vous pouvez également contourner le proxy en définissant la variable NO_PROXY="*"d’environnement.

Voici les points de terminaison requis par AzCopy :

Points de terminaison de connexion Points de terminaison stockage Azure
login.microsoftonline.com (Azure global) (blob | file | dfs).core.windows.net (Azure global)
login.chinacloudapi.cn (Azure Chine) (blob | file | dfs).core.chinacloudapi.cn (Azure Chine)
login.microsoftonline.de (Azure Allemagne) (blob | file | dfs).core.cloudapi.de (Azure Allemagne)
login.microsoftonline.us (Azure Gouvernement américain) (blob | file | dfs).core.usgovcloudapi.net (Azure Gouvernement américain)

x509 : certificat signé par une autorité inconnue

Cette erreur est souvent liée à l’utilisation d’un proxy qui utilise un certificat SSL (Secure Sockets Layer) qui n’est pas approuvé par le système d’exploitation. Vérifiez vos paramètres et assurez-vous que le certificat est approuvé au niveau du système d’exploitation.

Nous vous recommandons d’ajouter le certificat au magasin de certificats racine de votre composant d’hébergement, car c’est là que les autorités approuvées sont conservées.

Paramètres non reconnus

Si vous recevez un message d’erreur indiquant que vos paramètres ne sont pas reconnus, vérifiez que vous utilisez la version correcte d’AzCopy. AzCopy v8 et les versions antérieures sont déconseillées. AzCopy v10 est la version actuelle, et il s’agit d’une réécriture complète qui ne partage aucune syntaxe avec les versions précédentes. Reportez-vous au Guide de migration AzCopy pour v8 vers v10.

Veillez également à utiliser des messages d’aide intégrés à l’aide du -h commutateur avec n’importe quelle commande (par exemple). azcopy copy -h Consultez Obtenir de l’aide sur les commandes. Pour afficher les mêmes informations en ligne, consultez azcopy copy.

Pour vous aider à comprendre les commandes, nous fournissons un outil d’éducation situé dans le guide de commande AzCopy. Cet outil illustre les commandes AzCopy les plus populaires ainsi que les indicateurs de commande les plus populaires. Pour rechercher des exemples de commandes, consultez Transférer des données. Si vous avez une question, essayez d’abord de rechercher dans des problèmes GitHub existants pour voir s’il a déjà été répondu.

Erreur de stratégie d’accès conditionnel

Vous pouvez recevoir l’erreur suivante lorsque vous appelez la azcopy login commande :

Échec de l’exécution de la commande de connexion : échec de connexion avec tenantID « common », point de terminaison d’annuaire Azure «https://login.microsoftonline.com" ;, autorest/adal/devicetoken : -REDACTED- AADSTS50005 : l’utilisateur a essayé de se connecter à un appareil à partir d’une plateforme (inconnu) qui n’est actuellement pas pris en charge par le biais de la stratégie d’accès conditionnel. Les plateformes d’appareils prises en charge sont les suivantes : iOS, Android, Mac et Windows. ID de trace : -REDACTED- ID de corrélation : -REDACTED- Timestamp : 2021-01-05 01:58:28Z

Cette erreur signifie que votre administrateur a configuré une stratégie d’accès conditionnel qui spécifie le type d’appareil à partir duquel vous pouvez vous connecter. AzCopy utilise le flux de code de l’appareil. Le flux de code de l’appareil ne peut pas garantir que le composant d’hébergement sur lequel vous utilisez l’outil AzCopy est également à partir duquel vous vous connectez.

Si votre appareil figure parmi la liste des plateformes prises en charge, vous pouvez utiliser Explorateur Stockage. Explorateur Stockage intègre AzCopy pour tous les transferts de données (il transmet des jetons à AzCopy via le magasin de secrets), mais fournit un flux de travail de connexion qui prend en charge la transmission d’informations sur l’appareil. AzCopy prend également en charge les identités managées et les principaux de service comme alternative de connexion.

Si votre appareil ne figure pas dans la liste des plateformes prises en charge, contactez votre administrateur pour obtenir de l’aide.

Serveur occupé, erreurs réseau ou délais d’attente

Si vous voyez un grand nombre de requêtes ayant l’état « 503 Serveur occupé », le service de stockage limite vos demandes. Si vous voyez des erreurs réseau ou des délais d’attente, vous essayez peut-être d’envoyer trop de données à votre infrastructure pour gérer. Dans tous les cas, la solution de contournement est similaire.

Si vous voyez qu’un fichier volumineux échoue à plusieurs reprises, car certains blocs échouent chaque fois, essayez de limiter les connexions réseau simultanées ou la limite de débit en fonction de votre cas spécifique. Nous vous suggérons de réduire considérablement les performances au début, d’observer si cette action a résolu le problème initial, puis de relancer les performances jusqu’à ce que vous obteniez un équilibre global.

Pour plus d’informations, consultez Optimiser l’analyse des performances d’AzCopy avec le Stockage Azure.

Si vous copiez des données entre des comptes à l’aide d’AzCopy, la qualité et la fiabilité du réseau à partir de laquelle vous exécutez AzCopy peuvent affecter les performances globales. Même pour les transferts de données de serveur à serveur, AzCopy lance des appels pour chaque fichier à copier entre les points de terminaison de service.

Contraintes connues dans AzCopy

  • La copie de données de clouds gouvernementaux vers des clouds commerciaux n’est pas prise en charge. Toutefois, la copie de données de clouds commerciaux vers des clouds gouvernementaux est prise en charge.

  • La copie côté service asynchrone n’est pas prise en charge. AzCopy effectue uniquement une copie synchrone. En d’autres termes, à la fin du travail, les données ont été déplacées.

  • Lorsque vous copiez vers un partage de fichiers Azure, si vous avez oublié de spécifier l’indicateur --preserve-smb-permissions et que vous ne souhaitez pas transférer à nouveau les données, envisagez d’utiliser Robocopy pour transférer les autorisations.

  • Azure Functions a un autre point de terminaison pour l’authentification MSI. AzCopy ne prend pas encore en charge l’authentification MSI.

Voir aussi

Contactez-nous pour obtenir de l’aide

Pour toute demande ou assistance, créez une demande de support ou posez une question au support de la communauté Azure. Vous pouvez également soumettre des commentaires sur les produits à la communauté de commentaires Azure.