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

  • Article

Cet article vous aide à examiner les changements de disponibilité (tels que le nombre de demandes ayant échoué). Ces changements de disponibilité peuvent souvent être identifiés en surveillant les 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 :

Surveillance 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 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 demandes applicables, y compris celles qui ont produit 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’erreur 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 temporaires du serveur pendant que le service déplace les partitions pour mieux équilibrer la charge des demandes ; la logique de nouvelle tentative dans votre application cliente doit gérer ces conditions intermittentes.

Vous pouvez utiliser les fonctionnalités d’Azure Monitor pour vous avertir si la disponibilité d’un service est inférieure à un seuil que vous spécifiez.

Les métriques montrent une augmentation des erreurs de limitation

Des erreurs de limitation se produisent lorsque vous dépassez les objectifs d’extensibilité d’un service de stockage. Le service de stockage limite pour garantir qu’aucun client ou locataire ne peut utiliser le service au détriment d’autres utilisateurs. Pour plus d’informations, consultez Objectifs d’extensibilité et de performances pour les comptes de stockage standard pour plus d’informations sur les objectifs de scalabilité pour les comptes de stockage et les objectifs de performances pour les partitions au sein des comptes de stockage.

Si la valeur ClientThrottlingError ou ServerBusyError de la dimension ResponseType indique une augmentation du pourcentage de requêtes qui échouent avec une erreur de limitation, vous devez examiner l’un des deux scénarios suivants :

  • Augmentation temporaire de 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 la charge initiale de votre application. Cela peut également se manifester dans le client sous la forme de messages HTTP status d’opérations « 503 Server Busy » ou « 500 Operation Timeout ».

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 d’interruption exponentielle (non linéaire) pour les nouvelles tentatives dans votre client. Les nouvelles tentatives d’arrêt 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 .

Remarque

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

Augmentation permanente des erreurs de limitation

Si vous voyez une valeur constamment élevée pour les erreurs de limitation suite à une augmentation permanente de vos volumes de transactions ou lorsque vous effectuez vos tests de charge initiaux sur votre application, vous devez évaluer comment votre application utilise les partitions de stockage et si elle s’approche des cibles de scalabilité d’un compte de stockage. Par exemple, si vous voyez des erreurs de limitation dans une file d’attente (qui compte comme une seule partition), vous envisagez d’utiliser des files d’attente supplémentaires pour répartir les transactions sur plusieurs partitions. Si vous voyez des erreurs de limitation sur une table, envisagez d’utiliser un schéma de partitionnement différent pour répartir vos transactions sur plusieurs partitions à l’aide d’un plus large éventail de valeurs de clé de partition. L’une des causes courantes de ce problème est l’anti-modèle ajouté/ajouté, où vous sélectionnez la date comme clé de partition, puis toutes les données d’un jour particulier sont écrites dans une partition (en cas de chargement, cela peut entraîner un goulot d’étranglement en écriture). Envisagez une conception de partitionnement différente ou évaluez si l’utilisation du stockage d’objets blob peut être une meilleure solution. En outre, case activée si la limitation se produit en raison de pics dans votre trafic et examinez les moyens de lisser votre modèle de requêtes.

Si vous distribuez vos transactions sur plusieurs partitions, vous devez toujours connaître les limites d’extensibilité définies pour le compte de stockage. Par exemple, si vous avez utilisé 10 files d’attente, chacune traitant le maximum de 2 000 messages de 1 Ko par seconde, vous êtes à 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 lorsque le service de stockage limite vos clients. Si vous avez des requêtes et des entités plus volumineuses, vous risquez d’être limité plus tôt.

Une conception de requête inefficace peut également vous amener à atteindre les limites de scalabilité 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 qui analyse toutes les entités d’une partition doit accéder à chaque entité. Chaque lecture d’entité est comptabilisée dans le nombre total de transactions dans cette partition. Par conséquent, vous pouvez facilement atteindre les cibles d’extensibilité.

Remarque

Vos tests de performances doivent révéler toute conception de requête inefficace dans votre application.

Les métriques montrent une augmentation des erreurs de délai d’expiration

Des 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’expiration pour l’un de vos services de stockage. En même temps, le client reçoit un volume élevé de messages http status « 500 délai d’expiration de l’opération » provenant des opérations de stockage.

Remarque

Vous pouvez voir des erreurs de délai d’expiration temporaires lorsque le service de stockage équilibre la charge des requêtes en déplaçant une partition vers un nouveau serveur.

Les délais d’expiration du serveur (ServerTimeOutError) sont causé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 avec le service de stockage qui nécessite une investigation plus approfondie. Vous pouvez utiliser des métriques pour voir si vous atteignez les limites d’extensibilité du service et identifier les pics de trafic susceptibles d’être à l’origine de ce problème. Si le problème est intermittent, il peut être dû à l’activité d’équilibrage de charge dans le service. Si le problème est persistant et n’est pas dû au fait que votre application atteint les limites de scalabilité du service, vous devez soulever un problème de support. Pour les délais d’expiration du client, vous devez déterminer si le délai d’expiration 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 montrent une augmentation des erreurs réseau

Des erreurs réseau se produisent lorsque la dimension ResponseType est égale à NetworkError. Elles se produisent lorsqu’un service de stockage détecte une erreur réseau lorsque le client effectue une demande de stockage.

La cause la plus courante de cette erreur est qu’un client se déconnecte avant l’expiration d’un délai d’expiration dans le service de stockage. Examinez le code de votre client pour comprendre pourquoi et quand le client se déconnecte du service de stockage. Vous pouvez également utiliser des outils d’analyse réseau tiers pour examiner 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.