Limites d’Azure Data Box

Tenez compte de ces limites quand vous déployez et utilisez votre solution Microsoft Azure Data Box. Le tableau suivant décrit ces limites pour Data Box.

Limites du service Data Box

  • Si vous utilisez plusieurs comptes de stockage avec le service Data Box, ils doivent tous appartenir à la même région Azure.
  • Nous vous recommandons de ne pas utiliser plus de trois comptes de stockage. L’utilisation de plus de comptes de stockage peut affecter les performances.

Limites du service Data Box

  • Le service Data Box peut stocker jusqu’à 500 millions de fichiers à des fins d’importation et d’exportation.
  • Data Box prend en charge un maximum de 512 conteneurs ou partages dans le cloud. Les répertoires de niveau supérieur au sein du partage utilisateur deviennent des conteneurs ou des partages de fichiers Azure dans le cloud.
  • La capacité d’utilisation de Data Box peut être inférieure à 80 To en raison de la consommation d’espace de métadonnées ReFS.
  • Data Box prend en charge un maximum de 10 connexions client simultanées sur un partage NFS.

Limites du stockage Azure

Cette section décrit les limites du service Stockage Azure et les conventions de nommage en vigueur pour les fichiers Azure, les objets blob de blocs Azure et les objets blob de pages Azure, telles qu’applicables au service Data Box. Examinez soigneusement les limites de stockage et suivez toutes les recommandations.

Pour les informations les plus récentes sur les limites du service de stockage Azure et les bonnes pratiques pour nommer les partages, les conteneurs et les fichiers, accédez à :

Important

S’il existe des fichiers ou des répertoires qui dépassent les limites du service Stockage Azure, ou qui ne sont pas conformes aux conventions de nommage des fichiers/objets blob Azure, ces fichiers ou répertoires ne sont pas ingérés dans Stockage Azure par le biais du service Data Box.

Avertissements liés à la copie et au chargement des données

Pour un ordre d’importation

Les mises en garde Data Box pour un ordre d’importation incluent :

  • Conteneurs, partages et dossiers :
    • Ne copiez pas les fichiers directement sur les partages précréés. Vous devez créer un dossier dans le partage, puis copier les fichiers dans ce dossier.
    • Un dossier sous StorageAccount_BlockBlob et StorageAccount_PageBlob est un conteneur. Par exemple, les conteneurs sont créés sous la forme suivante StorageAccount_BlockBlob/container et StorageAccount_PageBlob/container.
    • Chaque dossier créé directement sous StorageAccount_AzureFiles est traduit dans un Partage de fichiers Azure.
    • Le stockage Blob Azure ne prend pas en charge les répertoires. Si vous créez un dossier sous le dossier StorageAccount_BlockBlob, des dossiers virtuels sont alors créés dans le nom de l’objet blob. Pour Azure Files, la structure du répertoire est conservée.
  • Fusion du contenu du dossier :
    • Chaque fichier écrit dans les partages StorageAccount_BlockBlob et StorageAccount_PageBlob est chargé respectivement en tant qu’objet blob de blocs et objet blob de pages.
    • Si un dossier porte le même nom qu’un conteneur existant, le contenu du dossier est fusionné avec le contenu du conteneur. Les fichiers ou les objets blobs qui ne se trouvent pas déjà dans le cloud sont ajoutés au conteneur. Si un fichier ou un objet blob porte le même nom qu’un fichier ou un objet blob qui se trouve déjà dans le conteneur, le fichier ou l’objet blob existant est remplacé.
    • Un chargement vers un objet blob au niveau Archive échoue si le conteneur a un objet blob archivé existant portant le même nom. Tant qu’un objet blob se trouve dans le niveau archive, il ne peut être ni lu ni modifié. Si vous devez remplacer un objet blob, assurez-vous que celui-ci n’est pas configuré sur archiver. Pour plus d’informations, voir Niveau d’accès archive.
    • Une hiérarchie de répertoires vides (sans fichiers) créée sous les dossiers StorageAccount_BlockBlob et StorageAccount_PageBlob n’est pas chargée.
  • L’importation de données dans des partages de fichiers Azure NFS n’est pas prise en charge par Azure Data Box. La copie de données de Data Box dans un partage de fichiers Azure NFS existant avec un nom identique à celui de votre dossier source crée un conflit. Pour résoudre ce conflit, Data Box renomme le partage source en databox-<GUID> et le charge dans le compte de stockage cible en tant que partage de fichiers Azure SMB.
  • Si vous utilisez les protocoles SMB et NFS pour les copies de données, nous vous recommandons ce qui suit :
    • Utilisez différents comptes de stockage pour SMB et NFS.
    • Ne copiez pas les mêmes données vers la même destination finale dans Azure en utilisant SMB et NFS. En effet, le résultat final ne pourrait pas être déterminé.
    • Même si la copie via SMB et NFS en parallèle peut fonctionner, nous vous déconseillons de le faire, car elle est sujette aux erreurs humaines. Attendez la fin de la copie des données SMB avant de démarrer une copie de données NFS.
  • Gestion des chargements :
    • Pour améliorer les performances lors des chargements de données, nous vous recommandons d’activer les partages de fichiers volumineux sur le compte de stockage et d’augmenter la capacité de partage à 100 Tio.
    • S’il se produit des erreurs lors du chargement des données sur Azure, un journal des erreurs est créé dans le compte de stockage cible. Le chemin menant à ce journal des erreurs est disponible à l’issue du chargement ; vous pouvez consulter ce journal afin de procéder aux corrections. Ne supprimez pas les données de la source sans avoir préalablement vérifié les données chargées.
    • Les métadonnées de fichier et les autorisations NTFS peuvent être conservées lorsque les données sont chargées vers Azure Files en utilisant les instructions de conservation des listes de contrôle d’accès, des attributs et des horodateurs de fichiers avec Azure Data Box.
    • La hiérarchie des fichiers est conservée durant le chargement vers le cloud pour les objets blob et Azure Files. Par exemple, vous avez copié un fichier à ce chemin d’accès : <container folder>\A\B\C.txt. Ce fichier est chargé vers le même chemin d'accès virtuel dans le cloud.
    • Si le champ CreateTime ou LastWriteTime d’un fichier dépasse la taille autorisée pendant un chargement, « Ven 31 déc 9999 23:59:59” remplace la date originale dans la propriété du fichier Azure. Le chargement du fichier a réussi et aucune erreur n’est générée.

Pour un ordre d’exportation

Les mises en garde Data Box pour un ordre d’exportation incluent :

  • Data Box est un appareil Windows et ne prend pas en charge les noms de fichiers sensibles à la casse. Par exemple, vous pouvez disposer de deux fichiers différents dans Azure avec des noms dont seule la casse diffère. N’utilisez pas Data Box pour exporter de tels fichiers, car ils seront remplacés sur l’appareil.
  • En présence de balises en double dans les fichiers d’entrée ou de balises faisant référence aux mêmes données, l’exportation Data Box peut ignorer ou remplacer les fichiers. Le nombre de fichiers et la taille des données affichés sur le portail Azure peuvent différer de la taille réelle des données sur l’appareil.
  • Data Box exporte des données vers un système Windows sur SMB et est soumis aux limitations SMB pour les fichiers et les dossiers. Les fichiers et dossiers dont les noms ne sont pas pris en charge ne sont pas exportés.
  • Il existe un mappage de 1:1 entre le préfixe et le conteneur.
  • La taille maximale du nom de fichier est de 1 024 caractères. Les noms de fichiers qui dépassent cette longueur ne sont pas exportés.
  • Les préfixes dupliqués dans le fichier xml (chargé lors de la création de l’ordre) sont exportés. Les préfixes dupliqués ne sont pas ignorés.
  • Les objets blob de pages et les noms de conteneur respectent la casse. Si la casse ne correspond pas, les objets blob et/ou les conteneurs sont introuvables.

Limites de la taille du compte de stockage Azure

Voici les limites de la taille des données qui sont copiées dans un compte de stockage. Assurez-vous que les données que vous chargez sont conformes à ces limites. Pour obtenir les informations les plus récentes sur ces limites, consultez Objectifs de performance et d’extensibilité du stockage Blob et Objectifs de performance et d’extensibilité pour Azure Files.

Taille des données copiées dans le compte de stockage Azure Limite par défaut
Objet blob de blocs et objet blob de pages La limite maximale est identique à la limite de stockage définie pour l’abonnement Azure, et elle inclut les données de toutes les sources, y compris Data Box.
Azure Files
  • Data Box prend en charge les partages de fichiers volumineux (100 Tio) s’ils sont activés avant la création de la commande Data Box.
  • Data Box prend en charge les partages de fichiers Azure Premium qui autorisent un total de 100 Tio pour tous les partages dans le compte de stockage.
    • La capacité maximale utilisable est légèrement inférieure en raison de l’espace utilisé par les journaux de copie et les journaux d’audit. Un minimum de 100 Gio est réservé pour chaque journal de copie et chaque journal d’audit. Pour plus d’informations, consultez Journal d'audit pour les événements Azure Data Box.
    • Tous les dossiers sous StorageAccount_AzFiles doivent respecter cette limite. Pour plus d’informations, consultez Créer un partage de fichiers Azure.

Limites de taille des objets Azure

Voici les tailles des objets Azure qui peuvent être écrits. Assurez-vous que tous les fichiers chargés sont en conformité avec ces limites.

Type d’objet Azure Limite par défaut
Objet blob de blocs 14 Tio
Objet blob de pages 4 Tio
Chaque fichier chargé dans le format d’objet blob de pages doit être de 512 octets alignés (un multiple entier), sinon le chargement échoue.
Les disques VHD et VHDX sont de 512 octets alignés.
Azure Files 4 Tio
Disques managés 4 Tio
Pour plus d’informations sur la taille et les limites, consultez :
  • Objectifs d’évolutivité des disques SSD Standard
  • Objectifs d’évolutivité des disques SSD Premium
  • Objectifs d’évolutivité des disques HDD Standard
  • Tarification et facturation des disques managés
  • Conventions de nommage des objets blob de blocs,des objets blob de pages et des fichiers Azure

    Entité Conventions
    Noms de conteneur pour les objets blob de blocs et les objets blob de pages Doit être un nom DNS valide dont la longueur est comprise entre 3 et 63 caractères.
    Doit commencer par une lettre ou un chiffre.
    Ne peut contenir que des lettres minuscules, des chiffres et le trait d’union (-).
    Chaque trait d’union (-) doit être immédiatement précédé et suivi d’une lettre ou d’un chiffre.
    Les traits d’union consécutifs ne sont pas autorisés dans les noms.
    Noms de partage pour les fichiers Azure Identique à ce qui précède
    Noms de répertoires et de fichiers pour les fichiers Azure
  • Conservent et respectent la casse, et ne doivent pas dépasser 255 caractères.
  • Ne peuvent pas se terminer par une barre oblique avant (/).
  • Si renseignée, elle sera automatiquement supprimée.
  • Les caractères suivants ne sont pas autorisés : " \ / : | < > * ?
  • Les caractères d’URL réservées doivent être correctement placés dans une séquence d’échappement.
  • Les caractères de chemin d’URL illégal ne sont pas autorisés. Les points de code comme \uE000 ne sont pas des caractères Unicode valides. Certains caractères Unicode ou ASCII, comme les caractères de contrôle (0x00 to 0x1F, \u0081, etc.) ne sont pas autorisés. Pour les règles concernant les chaînes Unicode dans HTTP/1.1, consultez RFC 2616, Section 2.2 : Règles de base et RFC 3987.
  • Les noms de fichiers suivants ne sont pas autorisés : LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, le point (.) et les deux points (..).
  • Noms d’objet blob pour les objets blob de blocs et les objets blob de pages
  • Les noms d’objet blob respectent la casse et peuvent contenir une combinaison de caractères.
  • Le nom d’objet blob doit comprendre entre 1 et 1 024 caractères.
  • Les caractères d’URL réservées doivent être correctement placés dans une séquence d’échappement.
  • Le nombre de segments de ligne comprenant le nom d’objet blob ne peut pas dépasser 254. Un segment de chemin représente la chaîne située entre des caractères délimiteurs consécutifs (par exemple, la barre oblique « / ») qui correspond au nom d’un répertoire virtuel.