Partage via

Résoudre les problèmes de disponibilité dans les comptes de stockage Azure

  • Article

Cet article vous aide à examiner les modifications apportées à la disponibilité (par exemple, le nombre de demandes ayant échoué). Ces changements de disponibilité peuvent souvent être identifiés en supervisant des métriques de stockage dans Azure Monitor. Pour obtenir des informations générales sur l’utilisation des métriques et des journaux dans Azure Monitor, consultez les articles suivants :

Supervision de la disponibilité

Vous devez surveiller la disponibilité des services de stockage dans votre compte de stockage en surveillant la valeur de la métrique Disponibilité . La métrique De disponibilité contient une valeur de pourcentage. Elle est calculée en prenant la valeur totale des demandes facturables et en la divisant par le nombre de requêtes applicables, y compris celles qui ont généré des erreurs inattendues.

Toute valeur inférieure à 100 % indique que certaines demandes de stockage échouent. Vous pouvez voir pourquoi ils échouent en examinant la dimension ResponseType pour les types d’erreurs tels que ServerTimeoutError. Vous devez vous attendre à ce que la disponibilité tombe temporairement en dessous de 100 % pour des raisons telles que des délais d’expiration de serveur temporaires pendant que le service déplace les partitions pour améliorer la charge des demandes ; la logique de nouvelle tentative dans votre application cliente doit gérer ces conditions intermittentes. La métrique de disponibilité est disponible uniquement pour les périodes où les transactions se produisent également sur le compte.

Vous pouvez utiliser des fonctionnalités dans Azure Monitor pour vous avertir si la Disponibilité d’un service tombe en dessous d’un seuil que vous spécifiez.

Les métriques indiquent une augmentation des erreurs de limitation

Les erreurs de limitation se produisent lorsque vous dépassez les valeurs cibles d’évolutivité d’un service de stockage. Le service de stockage connaît des limitations afin de s’assurer qu’aucun client ni locataire ne peut utiliser le service au détriment des autres utilisateurs. Pour plus d’informations sur les objectifs de scalabilité des comptes de stockage et les objectifs de performances des partitions dans les comptes de stockage, consultez Cibles de scalabilité et de performances pour les comptes de stockage standard.

Si la valeur PercentThrottlingError ou ServerBusyError de la dimension ResponseType indique une augmentation du pourcentage de demandes qui échouent avec une erreur de limitation, vous devez enquêter sur un des deux scénarios suivants :

  • Augmentation provisoire de la valeur PercentThrottlingError
  • Augmentation permanente de l’erreur PercentThrottlingError

Une augmentation des erreurs de limitation se produit souvent en même temps qu’une augmentation du nombre de demandes de stockage ou lorsque vous testez initialement votre application. Elle peut également se manifester dans le client sous forme de messages d’état HTTP « 503 Server Busy » ou « 500 Operation Timeout » à partir des opérations de stockage.

Augmentation temporaire des erreurs de limitation

Si vous constatez des pics d’erreurs de limitation qui coïncident avec des périodes d’activité élevée pour l’application, vous implémentez une stratégie exponentielle (non linéaire) pour les nouvelles tentatives dans votre client. Les nouvelles tentatives de sauvegarde réduisent la charge immédiate sur la partition et aident votre application à atténuer les pics de trafic. Pour plus d’informations sur la façon d’implémenter des stratégies de nouvelle tentative à l’aide de la bibliothèque cliente de stockage, consultez la propriété RetryOptions.MaxRetries.

Note

Vous pouvez également voir des pics d’erreurs de limitation qui ne coïncident pas avec les périodes d’activité élevée pour l’application. La cause la plus probable est le déplacement des partitions du service de stockage pour améliorer l’équilibrage de charge.

Augmentation permanente des erreurs de limitation

Si vous voyez une valeur élevée de manière cohérente pour limiter les erreurs après une augmentation permanente de vos volumes de transactions ou lorsque vous effectuez vos tests de charge initiaux sur votre application, vous devez évaluer la façon dont votre application utilise des partitions de stockage et si elle approche des cibles d’extensibilité pour un compte de stockage. Par exemple, si vous voyez des erreurs de limitation sur une file d’attente (qui comptent comme une partition unique), vous envisagez d’utiliser des files d’attente supplémentaires pour répartir les transactions entre plusieurs partitions. Si vous voyez des erreurs de limitation sur une table, envisagez d’utiliser un autre schéma de partitionnement pour répartir vos transactions entre plusieurs partitions à l’aide d’une plage plus large de valeurs de clé de partition. L’une des causes courantes de ce problème est l’anti-modèle prépend/append, où vous sélectionnez la date comme clé de partition, puis toutes les données d’un jour particulier sont écrites sur une partition (sous charge, cela peut entraîner un goulot d’étranglement d’écriture). Envisagez une conception de partitionnement différente ou évaluez si l’utilisation du stockage d’objets blob peut être une meilleure solution. Vérifiez également si la limitation se produit en raison de pics dans votre trafic et examinez les méthodes de lissage de votre modèle de requêtes.

Si vous distribuez vos transactions à travers plusieurs partitions, vous devez tenir compte des limites d'évolutivité définies pour le compte de stockage. Par exemple, si vous avez utilisé 10 files d’attente, chaque traitement du maximum de 2 000 messages de 1 Ko par seconde, vous serez à la limite globale de 20 000 messages par seconde pour le compte de stockage. Si vous devez traiter plus de 20 000 entités par seconde, envisagez d’utiliser plusieurs comptes de stockage. Vous devez également garder à l’esprit que la taille de vos requêtes et entités a un impact sur le moment où le service de stockage limite vos clients. Si vous avez des requêtes et des entités plus volumineuses, vous pouvez être limité plus tôt.

Une requête mal conçue peut également vous amener à atteindre les limites d'évolutivité pour les partitions de table. Par exemple, une requête avec un filtre qui ne sélectionne qu'un pour cent des entités dans une partition, mais recherche toutes les entités dans une partition devra accéder à chaque entité. Chaque lecture d’entité compte vers le nombre total de transactions dans cette partition. Par conséquent, vous pouvez facilement atteindre les cibles d’extensibilité.

Note

Vos tests de performances doivent mettre à jour toutes les requêtes mal conçues dans votre application.

Les métriques indiquent une augmentation des erreurs de délai d’attente

Les erreurs de délai d’expiration se produisent lorsque la dimension ResponseType est égale à ServerTimeoutError ou ClientTimeout.

Vos métriques indiquent une augmentation des erreurs de délai d’attente pour un de vos services de stockage. En même temps, le client reçoit un grand nombre de messages d'état HTTP « 500 Operation Timeout » à partir des opérations de stockage.

Notes

Il se peut qu’apparaissent des erreurs de délai d’expiration provisoires lorsque le service de stockage équilibre les demandes en déplaçant une partition vers un nouveau serveur.

Les délais d'expiration du serveur (ServerTimeOutError) sont provoqués par une erreur sur le serveur. Les délais d’expiration du client (ClientTimeout) se produisent, car une opération sur le serveur a dépassé le délai d’expiration spécifié par le client. Par exemple, un client utilisant la bibliothèque cliente de stockage peut définir un délai d’expiration pour une opération.

Les délais d'expiration du serveur indiquent un problème au niveau du service de stockage, qui exige une enquête plus approfondie. Vous pouvez utiliser les métriques pour savoir si vous atteignez les limites d'évolutivité pour le service et identifier les pics de trafic susceptibles d'être la cause de ce problème. Si le problème est intermittent, il peut être dû à une activité d'équilibrage de charge dans le service. Si le problème persiste et n'est pas provoqué par le fait que votre application a atteint les limites d'évolutivité du service, vous devez signaler le problème au support. Pour les délais d’expiration du client, vous devez décider si le délai d’attente est défini sur une valeur appropriée dans le client et modifier la valeur de délai d’expiration définie dans le client ou examiner comment vous pouvez améliorer les performances des opérations dans le service de stockage, par exemple en optimisant vos requêtes de table ou en réduisant la taille de vos messages.

Les métriques indiquent une augmentation des erreurs réseau

Les erreurs réseau se produisent lorsque la dimension ResponseType est égale à NetworkError. Cela se produit lorsqu’un service de stockage détecte une erreur de réseau associée à une demande de stockage du client.

La cause la plus fréquente de cette erreur est une déconnexion du client avant l'expiration d'un délai dans le service de stockage. Examinez le code dans votre client afin de comprendre pourquoi et quand le client se déconnecte du service de stockage. Vous pouvez également utiliser les outils d’analyse réseau tiers pour enquêter sur les problèmes de connectivité réseau à partir du client.

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.