Questions fréquemment posées sur le stockage Blob Azure

Une fois que vous avez configuré une stratégie, sa prise d’effet peut prendre jusqu’à 24 heures. Une fois la stratégie en vigueur, le temps nécessaire à l’exécution des actions peut varier en fonction de la taille du compte de stockage et des opérations effectuées.

Cela peut prendre jusqu’à 24 heures avant que la stratégie mise à jour ne soit appliquée. Une fois la stratégie en vigueur, le temps nécessaire à l’exécution des actions varie en fonction de la taille du compte de stockage et des opérations effectuées. Si la mise à jour consiste à désactiver ou à supprimer une règle et que enableAutoTierToHotFromCool a été utilisé, la hiérarchisation automatique vers le niveau chaud se produira quand même. Par exemple, définissez une règle incluant enableAutoTierToHotFromCool basée sur le dernier accès. Si la règle est désactivée ou supprimée, et qu’un blob est actuellement dans le niveau sporadique ou froid et qu’il fait l’objet d’un accès, il va repasser au niveau chaud, car la règle est appliquée à l’accès en dehors de la gestion de cycle de vie. Le blob ne passera alors pas du niveau chaud à sporadique ou froid, car la règle de gestion du cycle de vie est désactivée ou supprimée. La seule façon d’empêcher autoTierToHotFromCool consiste à désactiver le suivi de l’heure du dernier accès.

Selon la taille et le nombre d’objets qui se trouvent dans un compte de stockage, plusieurs exécutions peuvent être nécessaires pour traiter tous les objets. Vous pouvez également vérifier les journaux des ressources de stockage pour voir si les opérations sont effectuées par la stratégie de gestion du cycle de vie.

Vérifiez si les fonctionnalités de protection des données telles que la suppression réversible ou le contrôle de version sont activées sur le compte de stockage. Même si la stratégie supprime les objets blob, ceux-ci peuvent toujours exister dans un état supprimé de manière réversible ou en tant que version antérieure, selon la façon dont ces fonctionnalités sont configurées.

Si une stratégie de gestion de cycle de vie est en vigueur pour le compte de stockage, la réhydratation d’un objet blob en changeant son niveau peut donner lieu à un scénario dans lequel la stratégie de cycle de vie replace l’objet blob dans le niveau archive. Cela peut se produire si l’heure de la dernière modification, de la dernière création ou du dernier accès dépasse le seuil défini pour la stratégie. Il existe trois façons d’éviter ce problème :

• Ajoutez la condition daysAfterLastTierChangeGreaterThan à l’action tierToArchive de la stratégie. Consultez Utiliser des stratégies de gestion de cycle de vie pour archiver des objets blob.

• Désactivez la règle qui affecte temporairement cet objet BLOB pour empêcher son archivage. Réactivez la règle lorsque le BLOB peut être renvoyé en toute sécurité au niveau archive.

• Si le blob doit rester de façon permanente au niveau chaud, sporadique ou froid, copiez-le vers un autre emplacement où la stratégie de gestion de cycle de vie n’est pas en vigueur.

Le champ de correspondance de préfixe d’objet blob d’une stratégie est un chemin d’objet blob complet ou partiel, qui est utilisé pour mettre en correspondance les objets blob auxquels vous souhaitez appliquer les actions de stratégie. Le chemin doit commencer par le nom du conteneur. Si aucune correspondance de préfixe n’est spécifiée, la stratégie s’applique à tous les objets blob dans le compte de stockage. Le format de la chaîne de correspondance de préfixe est [container name]/[blob name].
Gardez à l'esprit les points suivants concernant la chaîne de correspondance du préfixe :

• Une chaîne de correspondance de préfixe comme container1/ s’applique à tous les objets blob du conteneur nommé container1. Une chaîne de correspondance de préfixe de container1, sans caractère de barre oblique de fin (/), s’applique à tous les objets blob dans tous les conteneurs où le nom du conteneur commence par le conteneur1 de chaîne. Le préfixe correspond aux conteneurs nommés container11, container1234, container1ab, et ainsi de suite.
• Une chaîne de correspondance de préfixe de container1/sub1/ s’applique à tous les objets blob du conteneur nommé container1 qui commencent par la chaîne sub1/. Par exemple, le préfixe correspond aux objets blob nommés container1/sub1/test.txt ou container1/sub1/sub1/sub2/test.txt.
• L’astérisque * est caractère valide dans un nom de blob. Si le caractère astérisque est utilisé dans un préfixe, le préfixe correspond aux objets blob avec un astérisque dans leurs noms. L’astérisque ne fonctionne pas comme un caractère générique.
• Le point d’interrogation ? est un caractère valide dans un nom de blob. Si le caractère de point d’interrogation est utilisé dans un préfixe, le préfixe correspond aux objets blob avec un point d’interrogation dans leurs noms. Le point d’interrogation ne fonctionne pas comme un caractère générique.
• La correspondance de préfixe considère uniquement les comparaisons logiques positives (=). Les comparaisons logiques négatives (!=) sont ignorées.
• La correspondance de préfixe fonctionne en respectant la casse.

Malheureusement, il n’existe aucun moyen de suivre le moment auquel la stratégie s’exécutera, car il s’agit d’un processus de planification en arrière-plan. Toutefois, la plateforme exécute la stratégie une fois par jour.

La règle d’inventaire quotidienne est conçue pour s’exécuter une fois par jour. De plus, l’exécution d’une règle d’inventaire hebdomadaire est prévue chaque dimanche.

Bien que nous nous efforcions de fournir une expérience cohérente, nous ne pouvons pas garantir l’heure à laquelle chaque exécution se produit. L’heure d’exécution de la règle d’inventaire peut varier. Par exemple, si la stratégie du jour est prévue pour 00:05, elle peut démarrer à 00:07, à 00:15 ou à toute autre heure le lendemain.

Le rapport d'inventaire d'objets blob produit trois types de fichiers. Consultez Fichiers d’inventaire. Les clients existants utilisant l'inventaire d'objets blob peuvent voir un changement dans le nombre de fichiers d'inventaire, d'un fichier à plusieurs fichiers. Aujourd'hui, nous avons déjà un fichier manifeste qui fournit la liste des fichiers. Ce comportement reste inchangé, ces fichiers sont donc répertoriés dans le fichier manifeste.

La modification a été mise en œuvre pour améliorer le niveau de performance de l’inventaire d’objets blob, en particulier pour les grands comptes de stockage contenant plus de cinq millions d’objets. Désormais, les résultats sont écrits en parallèle dans plusieurs fichiers, éliminant ainsi le goulot d’étranglement lié à l’utilisation d’un seul fichier d’inventaire. Ce changement a été motivé par les commentaires des clients, car ils ont signalé des difficultés à ouvrir et à travailler avec le fichier d’inventaire unique excessivement volumineux.

En tant qu'utilisateur, ce changement a un impact positif sur votre expérience avec les exécutions d'inventaire d'objets blob. On s'attend à ce qu'il améliore les performances et réduise le temps de fonctionnement global. Cependant, pour bénéficier pleinement de cette amélioration, vous devez vous assurer que votre code est mis à jour pour traiter plusieurs fichiers de résultats au lieu d'un seul. Cet ajustement aligne votre code sur la nouvelle approche et optimise la gestion des données d'inventaire.

Non, les données existantes ne sont pas affectées. Seuls les nouveaux résultats d'inventaire blob ont plusieurs fichiers d'inventaire.

Non, le changement se fait de manière transparente.

Les actions requises dépendent de la manière dont vous traitez actuellement les résultats de l'inventaire d'objets blob :

• Si votre traitement actuel suppose un seul fichier de résultats d'inventaire, vous devez modifier votre code pour prendre en charge plusieurs fichiers de résultats d'inventaire.

• Toutefois, si votre traitement actuel implique la lecture de la liste des fichiers de résultats à partir du fichier manifeste, il n'est pas nécessaire de modifier la manière dont vous traitez les résultats. L'approche existante continue de fonctionner de manière transparente avec la fonctionnalité mise à jour.

Ce n'est pas recommandé, mais c'est possible. Veuillez utiliser vos canaux d'assistance pour demander la désactivation de cette fonctionnalité.

Veuillez passer par votre équipe de compte actuelle et vos canaux de support.

Ce changement commencera un déploiement progressif à partir du 1er septembre 2023.

Nombre Azure Compute prend en charge les métriques sur les disques. Pour obtenir davantage d’informations, consultez Métriques par disque pour les disques managés et non managés.

Certains graphiques de métriques Azure, comme ceux qui affichent des données de disponibilité et de latence, utilisent une ligne en pointillés pour indiquer qu’il manque une valeur (également appelée valeur null) entre deux points de données de fragment de temps connus. Par exemple, si, dans le sélecteur de temps, vous avez choisi la granularité 1 minute, mais que la métrique a été signalée à 07:26, 07:27, 07:29 et 07:30, une ligne en pointillés connecte 07:27 et 07:29, car il manque une minute entre ces deux points de données. Une ligne pleine connecte tous les autres points de données. La ligne en pointillés descend à zéro quand la métrique utilise une agrégation Nombre et Somme. Pour les agrégations Moy., Min. ou Max., une ligne en pointillés relie les deux points de données connus les plus proches. En outre, lorsque des données sont manquantes sur le côté le plus à droite ou le plus à gauche du graphique, la ligne en pointillés s’étend dans la direction du point de données manquant.

Vous pouvez configurer une alerte d’intégrité des ressources en fonction du service Azure Resource Health pour suivre la disponibilité de votre compte de stockage. S’il n’y a pas de transactions sur le compte, l’alerte se déclenche en fonction de l’intégrité du cluster de stockage où se trouve votre compte de stockage.

Les métriques de capacité du service Blob et du nombre d’objets blob sont émises toutes les heures. Un processus en arrière-plan calcule ces métriques et les met à jour plusieurs fois par jour.

Les journaux d’analytique contiennent des enregistrements sur toutes les opérations de lecture, d’écriture, d’énumération et de suppression, avec une indication de réussite ou d’échec de requête pour toutes les opérations. Les journaux d’analytique sont régis par le principe du « meilleur effort », et aucun classement n’est garanti.

Le flux de modification est une solution qui fournit un journal transactionnel des mutations réussies ou des modifications apportées à votre compte, telles que la création, la modification et la suppression de blobs. Le flux de modification garantit l’enregistrement et l’affichage de tous les événements dans l’ordre des modifications réussies par blob. Vous n’avez donc pas besoin de filtrer le bruit d’un énorme volume d’opérations de lecture ou de requêtes ayant échoué. Le flux de modification est essentiellement conçu et optimisé pour le développement d’applications exigeant certaines garanties.

Vous pouvez tirer parti des deux, car le flux de modification et les événements Stockage Blob fournissent les mêmes informations avec la même garantie de fiabilité de remise. Leurs principales différences sont la latence, le classement et le stockage des enregistrements d’événements. Le flux de modification publie des enregistrements dans le journal dans les quelques minutes qui suivent la modification, et garantit l’ordre des opérations de modification par objet blob. Les événements de stockage sont envoyés (push) en temps réel et peuvent ne pas être classés. Les événements de flux de modification sont stockés durablement dans votre compte de stockage en tant que journaux stables en lecture seule avec vos propres paramètres de conservation définis, tandis que les événements de stockage sont temporaires et consommés par le gestionnaire d’événements, sauf si vous les stockez de façon explicite. Avec le flux de modification, toutes vos applications peuvent utiliser les journaux à leur convenance à l’aide d’API Blob ou de Kits de développement logiciel (SDK).

Oui. Les règles de sécurité réseau du compte de stockage, y compris les pare-feu basés sur IP et sur réseaux virtuels, sont prises en charge pour le point de terminaison de site web statique et peuvent être utilisées pour protéger votre site web.

Nombre Les sites web statiques ne prennent en charge l’accès en lecture public et anonyme des fichiers que dans le conteneur $web.

Vous pouvez configurer un domaine personnalisé avec un site web statique en utilisant Azure Content Delivery Network (Azure CDN). Azure CDN fournit une latence faible et cohérente à votre site web partout dans le monde.

Vous pouvez configurer un certificat SSL personnalisé avec un site web statique en utilisant Azure CDN. Azure CDN fournit une latence faible et cohérente à votre site web partout dans le monde.

Vous pouvez configurer l’en-tête d’hôte pour un site web statique à l’aide d’Azure CDN-Verizon Premium. Nous aimerions avoir votre avis ici.

Une erreur 404 peut se produire si vous faites référence à un nom de fichier à l’aide d’une casse incorrecte. Par exemple, Index.html au lieu de index.html. Les noms de fichiers et les extensions de l’URL d’un site web statique respectent la casse, même s’ils sont traités sur HTTP. Cela peut également se produire si votre point de terminaison Azure CDN n’est pas encore approvisionné. La propagation peut nécessiter jusqu’à 90 minutes après le provisionnement d’un nouveau CDN Azure.

Dans le portail Azure, ouvrez la page de configuration du site web statique de votre compte et recherchez le nom et l’extension définis dans le champ Nom du document d’index. Assurez-vous que ce nom est exactement le même que le nom du fichier situé dans le conteneur $web du compte de stockage. Les noms de fichiers et les extensions de l’URL d’un site web statique respectent la casse, même s’ils sont traités sur HTTP.

Non, si vous devez effectuer une recherche dans vos données blob, utilisez l’accélération des requêtes ou Recherche Azure.

Les étiquettes d'index d'objet blob ne prennent en charge que les types de données de chaîne, et l'interrogation renvoie les résultats dans l'ordre lexicographique. Pour les nombres, ajoutez un zéro au chiffre. Pour les dates et les heures, enregistrez-les dans un format conforme à la norme ISO 8601.

Non, les étiquettes Resource Manager aident à organiser les ressources de plan de contrôle telles que les abonnements, les groupes de ressources et les comptes de stockage. Les balises d’index fournissent la gestion et la découverte des blobs sur le plan de données.

La capacité de stockage du service Stockage Blob est facturée en unités de la quantité quotidienne moyenne de données stockées, en gigaoctets (Go), sur une période mensuelle. Par exemple, si vous avez utilisé 10 Go de stockage en continue au cours de la première moitié du mois et rien lors de la seconde moitié, vous êtes facturé pour votre utilisation moyenne de 5 Go de stockage.

Étapes suivantes

Vous pouvez en apprendre plus sur le stockage Blob Azure en consultant les liens suivants :

• Introduction à Azure Storage
• Qu’est-ce que Stockage Blob Azure