Fiabilité dans stockage Azure Actions

stockage Azure Actions est une plateforme entièrement managée qui automatise les tâches de gestion des données pour Stockage Blob Azure et Azure Data Lake Storage. Vous planifiez des tâches de stockage à exécuter sur vos comptes de stockage. Vous pouvez configurer des tâches pour supprimer des objets blob, définir des balises d’objet blob et modifier les niveaux d’accès en fonction de l’âge de vos données.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft offre une gamme de fonctionnalités permettant de prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre stockage Azure Actions résilient aux erreurs temporaires, aux problèmes de configuration, aux défaillances de zone de disponibilité, aux défaillances à l’échelle de la région et à la maintenance du service. Il décrit également les options de sauvegarde et de restauration ainsi que les informations clés sur le contrat de niveau de service (SLA) d’stockage Azure Actions.

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de :

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

Lorsque vous utilisez stockage Azure Actions, vous créez une ou plusieurs ressources storage task. Chaque tâche de stockage contient des conditions qui sélectionnent des objets et des opérations à effectuer sur les objets qui correspondent à ces conditions. Pour exécuter une tâche de stockage sur un compte de stockage, vous créez une attribution de tâche de stockage. L’attribution est stockée dans le cadre de la ressource de compte de stockage et identifie les objets à cibler, quand et à quelle fréquence la tâche s’exécute et où les rapports d’exécution sont stockés. Lorsqu’une exécution de tâche atteint l’état Completed, le service écrit un rapport d’exécution à l’emplacement spécifié dans l’attribution.

Vous êtes responsable de la configuration de chaque affectation et de l'attribution d'un rôle Azure approprié à l'identité managée de la tâche de stockage.

Architecture physique

stockage Azure Actions comporte deux plans pertinents pour la fiabilité :

• Plan de contrôle : Les demandes transitent par Azure Resource Manager vers le fournisseur de ressources stockage Azure Actions, qui gère les opérations de gestion et les flux de travail d’approvisionnement asynchrones pour les tâches de stockage et les affectations.

• Plan de données : inclut le programmateur, les workers qui évaluent les conditions de tâche de stockage et effectuent les opérations configurées sur les comptes de stockage cibles et les composants de création de rapports. Ces composants s’exécutent sur l’infrastructure stockage Azure.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, voir Recommandations concernant le traitement des pannes transitoires.

Les erreurs temporaires peuvent affecter stockage Azure Actions de deux façons principales :

• Opérations de gestion : Si vous automatisez la gestion des actions de stockage, telles que le déploiement ou la modification des tâches de stockage, vous êtes responsable de la gestion des erreurs temporaires dans votre automatisation. Utilisez un nombre limité de tentatives avec un délai approprié entre les tentatives.

• Exécution de tâche : Lorsqu’un compte de stockage cible limite les opérations, stockage Azure Actions temporise et réessaie après un délai. Tant que l’attribution continue de progresser, Storage Actions continue de réessayer pendant la durée de vie du workflow. Si l’attribution ne progresse pas dans le listage ni le traitement des blobs pendant quatre heures, Storage Actions termine l’exécution afin qu’une autre attribution puisse être lancée.

stockage Azure Actions traite une seule affectation à la fois pour chaque compte de stockage cible. Il règle automatiquement l’exécution des tâches afin que les charges de travail d’application sur le compte de stockage cible soient prioritaires. L’ampleur d’exécution dépend de la capacité de traitement des transactions disponible sur le compte. Lorsque moins de capacité de transaction est disponible, une exécution de tâche peut être limitée et prendre plus de temps. Pour plus d’informations, consultez Dépendance de la mise à l’échelle à la capacité de transaction disponible pour le compte de stockage.

Les échecs d’exécution des tâches ne sont pas tous transitoires. Par exemple, une tâche peut échouer, car son identité managée ne dispose pas des autorisations requises, le nombre de demandes dépasse une limite d’échelle ou le compte de stockage cible bloque l’accès réseau. Vous êtes responsable de la surveillance de l’état des tâches, des métriques et des tableaux de bord et de la correction de ces erreurs. Un rapport d’exécution est créé uniquement pour une exécution qui atteint l’état Completed . Les exécutions ayant échoué et ignorées ne produisent pas de rapport d’exécution. Comparez les temps d’exécution réels avec la planification d’affectation pour identifier les exécutions qui n’ont pas eu lieu. Pour plus d’informations sur l’identification et la résolution des erreurs de tâche, consultez résolution des problèmes de tâche de stockage.

Résilience aux problèmes de configuration

Les conditions de tâche de stockage déterminent les objets sur lesquels une tâche fonctionne, et une condition ou une opération incorrecte peut affecter des objets inattendus. Microsoft exécute chaque attribution en fonction de sa configuration. Vous êtes responsable de la validation de l’attribution avant de l’autoriser à modifier des données, en particulier lorsqu’elle inclut des opérations destructrices ou irréversibles.

Utilisez les méthodes de validation suivantes :

• Aperçu de condition : Pendant que vous composez des conditions de tâche, utilisez la fonctionnalité d’aperçu dans le portail Azure ou l’API REST Actions en préversion pour évaluer un échantillon d’un maximum de 5 000 objets blob. Un aperçu retourne des résultats immédiats et ne génère pas de rapport d’exécution.

• Exécution fictif : Avant d’activer l’affectation pour effectuer des opérations, créez une exécution fictive pour la validation finale. Une exécution fictive évalue chaque objet blob dans l’étendue d’affectation sans effectuer les opérations configurées. Elle s’exécute de façon asynchrone comme une attribution standard et produit un rapport d’exécution CSV. Passez en revue le rapport pour vérifier quels objets blob correspondent aux conditions et quelles opérations la tâche effectuerait.

La validation réduit le risque d’opérations involontaires, mais elle ne remplace pas la protection des données. Avant d’utiliser des tâches de stockage pour supprimer des objets blob, activez la suppression réversible pour les objets blob sur chaque compte de stockage cible. La suppression réversible vous permet de récupérer des objets blob supprimés pendant la période de rétention configurée.

Passez en revue les attributions de tâches de stockage avec d’autres stratégies de gestion des données qui fonctionnent sur les mêmes blobs. Ne configurez pas les tâches ou stratégies qui se chevauchent pour effectuer des opérations en conflit. Par exemple, une opération de suppression par une tâche de stockage peut échouer si une stratégie de gestion du cycle de vie Stockage Blob tente de supprimer le même objet blob.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Le plan de contrôle actions stockage Azure est redondant interzone. Microsoft gère automatiquement sa distribution entre plusieurs zones de disponibilité et vous ne sélectionnez pas les zones. Lors d’une défaillance d’une zone de disponibilité, vous pouvez continuer à gérer les tâches et affectations de stockage.

La résilience de l’exécution des tâches dépend de la configuration de redondance de chaque compte de stockage cible, car les tâches fonctionnent sur les données de ces comptes. Si l’exécution de tâche doit se poursuivre lors d’un échec de zone, configurez chaque compte cible avec une option de stockage redondant interzone (ZRS, GZRS ou RA-GZRS).

L’exemple suivant montre le plan de contrôle de Storage Actions et une tâche qui cible un compte redondant interzone dans une région à trois zones. Le plan de contrôle et le compte cible peuvent continuer à fonctionner si une zone devient indisponible :

En revanche, un compte cible LRS n’est pas redondant interzone. Dans l’exemple suivant, le plan de gestion s’étend sur les trois zones, et le compte cible est affiché dans la zone de disponibilité 1 pour illustrer un compte qui ne s’étend pas sur plusieurs zones. Si la zone qui héberge le compte cible devient indisponible, le plan de contrôle reste disponible, mais la tâche ne peut pas s’exécuter sur le compte cible tant que le compte n’est pas rétabli :

Requirements

• Prise en charge de la région : Lorsque vous configurez une attribution de tâche de stockage, la tâche de stockage et le compte de stockage cible doivent se trouver dans la même région. Pour rendre l’exécution des tâches résiliente aux défaillances de zone, choisissez une région qui prend en charge à la fois stockage Azure Actions et les zones de disponibilité.

• Configuration du compte de stockage : Configurez chaque compte cible avec une option de stockage redondant interzone. Le stockage localement redondant (LRS), le stockage géoredondant (GRS) et le stockage géoredondant à accès en lecture (RA-GRS) ne fournissent pas de redondance de zone dans la région primaire.

Considerations

La redondance de zone du plan de contrôle ne rend pas l’exécution des tâches résiliente aux pannes de zone lorsqu’un compte de stockage cible n’est pas disponible. Évaluez la configuration de redondance de chaque compte cible séparément.

Cost

La redondance de zone pour le plan de contrôle de Storage Actions est automatique et il n’y a pas de frais supplémentaires de Storage Actions pour l’activer. Les frais d’utilisation standard pour les exécutions de tâches, les objets ciblés et les opérations appelées s’appliquent toujours. Pour plus d’informations, consultez la tarification stockage Azure Actions.

L’option de redondance que vous sélectionnez pour chaque compte de stockage cible affecte vos frais de stockage Azure. Pour plus d’informations, consultez Tarification du Stockage Blob.

Configurez la prise en charge des zones de disponibilité

La redondance de zone est automatique pour le plan de contrôle Storage Actions. Vous ne configurez pas la redondance de zone séparément pour les tâches de stockage ou les affectations.

Pour rendre l’exécution des tâches résiliente aux défaillances de zone de disponibilité, sélectionnez une option de stockage redondante interzone lorsque vous créez chaque compte de stockage cible ou modifiez la configuration de redondance d’un compte existant.

Comportement lorsque toutes les zones sont saines

Cette section décrit à quoi s’attendre lorsque le plan de contrôle de Storage Actions est disponible, les comptes de stockage cibles utilisent une option de stockage à redondance zonale et toutes les zones de disponibilité sont opérationnelles.

• Opération interzone : Microsoft distribue l’infrastructure de plan de contrôle des actions de stockage entre les zones de disponibilité. Les exécutions de tâches fonctionnent sur chaque compte de stockage cible et stockage Azure distribue en toute transparence les requêtes sur l’infrastructure qui héberge le compte.

• Réplication des données interzones : Storage Actions ne stocke ni ne réplique les données d’objet blob que les tâches traitent.

  Le stockage Azure réplique de manière synchrone des données dans des comptes qui utilisent une option de stockage redondant interzone sur plusieurs zones de disponibilité de la région primaire. Le stockage Azure ne finalise pas une opération d’écriture tant que les données n’ont pas été répliquées entre les zones utilisées par le compte.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi s’attendre lorsque le plan de contrôle de Storage Actions est disponible, les comptes de stockage cibles utilisent une option de stockage redondant interzone et une panne se produit dans une zone de disponibilité.

• Détection et réponse : Microsoft détecte et répond aux défaillances qui affectent le plan de contrôle de Storage Actions.

  Pour les comptes cibles qui utilisent une option de stockage redondant interzone, le stockage Azure achemine automatiquement l’exécution des tâches et les opérations de stockage vers des zones saines. Vous n’avez pas besoin de lancer le basculement.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Les tâches de stockage qui ciblent des comptes avec redondance de zone disponibles continuent de progresser. Les tâches qui ciblent un compte indisponible peuvent échouer.

  Les affectations à exécution unique en attente peuvent toujours être récupérées. Les exécutions qui ont été interrompues ou ayant échoué peuvent vous obliger à les replanifier manuellement, en fonction de l’endroit où le traitement s’est arrêté.

• Perte de données attendue : Storage Actions ne stocke pas de copie distincte de vos données blob. Les niveaux de perte de données attendus dépendent de la configuration de redondance de chaque compte cible. Lorsqu'un compte utilise une option de stockage redondant interzone, stockage Azure réplique de manière synchrone ses données entre les zones de disponibilité de la région primaire. Par conséquent, une défaillance de zone n'est pas censée entraîner une perte de données pour les écritures terminées avec succès.

• Temps d’arrêt attendu : Le plan de contrôle Storage Actions reste disponible lors d’une défaillance de zone.

  L’exécution des tâches se poursuit tant que le compte de stockage cible reste accessible. Si le compte devient indisponible, tel qu’un compte de stockage LRS dans une zone affectée, les exécutions affectées peuvent échouer.

• Redistribution : Microsoft gère la prise en charge et la redistribution du plan de contrôle de Storage Actions.

  stockage Azure achemine automatiquement les opérations pour les comptes qui utilisent une option de stockage redondant interzone vers des zones saines. Aucune action du client n’est nécessaire.

Récupération de la zone

Lorsque la zone ayant échoué se récupère, Microsoft restaure la distribution normale du plan de contrôle. stockage Azure restaure une opération normale pour les comptes redondants interzone. Les affectations de tâches planifiées continuent en fonction de leurs planifications.

Les affectations périodiques reprennent selon leur calendrier configuré. Les affectations à exécution unique en attente peuvent toujours être récupérées. Vérifiez l’état des exécutions affectées par la panne. Selon l’endroit où le traitement s’est arrêté, vous devrez peut-être replanifier les exécutions interrompues ou ayant échoué.

Tester les pannes de zone

Microsoft gère la distribution, le basculement et la récupération de zones pour le plan de contrôle Storage Actions et pour les comptes de stockage redondant interzone. Vous n’avez pas besoin de tester les défaillances des zones de plateforme. Testez vos procédures opérationnelles en vérifiant que vous pouvez identifier les opérations de tâche ayant échoué et les réexécuter en toute sécurité.

Résilience aux défaillances à l’échelle de la région

La résilience de l’exécution des tâches de stockage lors d’une défaillance à l’échelle de la région dépend de la configuration de redondance de chaque compte de stockage cible. Si un compte cible utilise une option de stockage géoredondante (GRS, GZRS, RA-GRS et RA-GZRS), le compte de stockage peut basculer vers sa région jumelée et les futures exécutions de tâches de stockage peuvent continuer dans la nouvelle région primaire.

Comptes de stockage cibles géoredondants

Pour un compte de stockage géoredondant, la région qui accepte actuellement les opérations d’écriture est la région primaire. stockage Azure réplique de façon asynchrone les données dans la région jumelée du compte, qui est la région secondaire.

Les tâches de stockage s’exécutent sur le compte dans sa région principale. Après le basculement du compte, la région secondaire précédente devient la nouvelle région primaire et les futures exécutions de la tâche de stockage s’exécutent automatiquement dans cette région. stockage Azure Actions ne nécessite pas d'action de basculement distincte.

Requirements

• Prise en charge de la région : Le compte de stockage cible doit se trouver dans une région Azure qui a une région jumelée.

• Configuration du compte de stockage : Configurez le compte cible pour utiliser une option de stockage géoredondante.

Cost

Les configurations de stockage géoredondant entraînent des frais pour la réplication et le stockage dans la région secondaire. Pour plus d’informations, consultez Tarification du Stockage Blob.

Configurer la prise en charge de la multirégion

Sélectionnez une option de stockage géoredondante lorsque vous créez le compte de stockage cible ou modifiez la configuration de redondance d’un compte existant.

Si vous créez une attribution de tâche de stockage alors que le compte cible utilise une option non géoredondante et convertissez ultérieurement le compte en GRS, GZRS, RA-GRS ou RA-GZRS, mettez à jour l’affectation avant de lancer le basculement de compte géré par le client. Vous pouvez modifier n’importe quelle propriété d’affectation. La mise à jour permet au plan de contrôle de Storage Actions de détecter la nouvelle configuration géoredondante du compte.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un compte de stockage cible utilise une option de stockage géoredondante et que les régions primaires et secondaires sont opérationnelles.

• Opération interrégion : Pendant l’opération normale, la définition de tâche de stockage, l’affectation et le compte de stockage cible se trouvent dans la région primaire. La région secondaire ne traite pas les opérations de tâche de stockage.

• Réplication des données interrégions : stockage Azure Actions ne réplique pas indépendamment les données d'objet blob traitées par les tâches.

  stockage Azure réplique de façon asynchrone les données de la région primaire vers la région secondaire. Étant donné que la réplication est asynchrone, les modifications récentes peuvent ne pas encore exister dans la région secondaire.

Comportement lors d’une défaillance de région

Cette section décrit à quoi s’attendre lorsque la région primaire d’un compte de stockage cible qui utilise une option de stockage géoredondant n’est pas disponible.

• Détection et réponse : Le basculement de compte de stockage peut être géré par le client ou géré par Microsoft. Le basculement géré par Microsoft est réservé à des circonstances exceptionnelles et peut se produire uniquement après une panne étendue. Par conséquent, ne vous appuyez pas dessus pour votre plan de récupération d'urgence. Suivez le guide de basculement de Stockage Blob pour déterminer si et quand lancer un basculement géré par le client.

  stockage Azure Actions ne nécessite pas d'action de basculement distincte. Toutefois, si vous avez créé l’attribution alors que le compte cible utilisait LRS, puis que vous avez ultérieurement converti le compte en GRS ou GZRS, mettez à jour l’attribution avant de lancer le basculement de compte géré par le client. Pour plus d’informations, consultez Configurer la prise en charge multirégion.

• Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de région, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

• Demandes actives : Pendant le basculement du compte de stockage, les points de terminaison du compte de stockage principal et secondaire sont temporairement indisponibles. Les exécutions de tâches de stockage en cours peuvent échouer. Après le basculement, vérifiez l’état des exécutions de tâches affectées et réexécutez les opérations ayant échoué ou incomplètes en fonction des besoins.

  Pour une affectation périodique, si l’itération précédente reste en cours lorsque l’itération suivante est planifiée, Storage Actions ignore la nouvelle itération. L’itération suivante s’exécute à l’heure de déclenchement prévue une fois l’itération précédente terminée.

• Perte de données attendue : stockage Azure Actions ne conserve pas une copie distincte de vos données d'objet blob.

  Lors d’un basculement non planifié, les modifications récentes peuvent être perdues si elles n’ont pas été répliquées dans la région secondaire. Une tâche qui échoue en cours peut également avoir terminé des opérations sur certains de ses objets cibles. Après le basculement, vérifiez l’état des exécutions de tâches affectées et réexécutez les opérations ayant échoué ou incomplètes en fonction des besoins. Pour plus d’informations sur les points de récupération de compte de stockage et la perte de données, consultez La perte de données attendue lors d’une défaillance régionale de Stockage Blob.

• Temps d’arrêt attendu : Avant le basculement, les tâches de stockage ne peuvent pas progresser pendant que le compte de stockage cible n’est pas disponible.

  Pendant le basculement, les points de terminaison du compte de stockage restent indisponibles, de sorte que les exécutions de tâches ne peuvent pas progresser et peuvent échouer.

  Une fois le basculement terminé, les composants du plan de données Storage Actions dans la nouvelle région primaire du compte de stockage traitent les futures exécutions d’attribution de tâches. La ressource de tâche de stockage reste dans sa région d’origine, de sorte que la création de rapports pour la définition de tâche peut rester affectée pendant que cette région n’est pas disponible. La création de rapports pour d’autres sections de la ressource continue de fonctionner.

  L’interruption totale inclut le temps nécessaire pour détecter la panne, décider s’il faut lancer le basculement et terminer le basculement du compte de stockage.

  Si aucun basculement ne se produit, l’exécution des tâches reste indisponible tant que la région primaire d’origine ne se rétablit pas.

  Les opérations de gestion restent disponibles lors d’une défaillance de région.

• Redistribution : le stockage Azure met à jour les points de terminaison du compte de stockage à mesure que le basculement se termine. Les futures exécutions d’attribution de tâches s’exécutent automatiquement sur le compte dans la nouvelle région primaire. Vous n’avez pas besoin de reconfigurer la tâche de stockage ou l’affectation.

Récupération de région

Le processus de restauration automatique dépend du type de basculement du compte de stockage. Suivez les instructions de récupération de région de stockage Blob pour restaurer automatiquement le compte de stockage cible. stockage Azure Actions ne nécessite pas de configuration supplémentaire après la restauration automatique du compte de stockage.

Tester les défaillances régionales

Pour tester votre processus de récupération sans perte de données associée à un basculement non planifié, créez des affectations de tâches de stockage représentatives sur un compte de stockage hors production qui utilise une option de stockage géoredondante, puis lancez un basculement planifié géré par le client. Passez en revue toutes les exécutions en cours et vérifiez qu’une exécution planifiée ultérieure s’exécute sur le compte dans la nouvelle région primaire. Pour obtenir des conseils sur les tests de basculement, consultez Tester les défaillances régionales dans le stockage Blob Azure.

Solutions multirégions personnalisées pour la résilience

La prise en charge du basculement de région intégrée pour stockage Azure Actions est disponible uniquement lorsque le compte de stockage cible se trouve dans une région jumelée et utilise une option de stockage géoredondante.

Si votre solution de stockage multirégion utilise des comptes de stockage indépendants dans chaque région au lieu du basculement du compte de stockage, vous pouvez déployer une tâche de stockage dans la même région que chaque compte cible et créer une affectation pour chaque compte. Vous êtes responsable de la réplication des données entre les comptes, de la conservation des définitions de tâches et des affectations synchronisées et du contrôle des affectations qui s’exécutent pendant le fonctionnement normal et le basculement. Assurez-vous que les attributions dans différentes régions n’effectuent pas d’opérations en conflit sur les données répliquées.

Sauvegarde et restauration

Pour récupérer votre configuration d’stockage Azure Actions après suppression accidentelle, définissez vos tâches et attributions de stockage en tant que code (IaC) et stockez les définitions dans le contrôle de code source. Incluez les conditions et opérations des tâches, les planifications, les étendues de compte de stockage cible, les paramètres du conteneur de rapports, les identités managées et les attributions de rôles requises. Vous pouvez déployer une tâche de stockage à l’aide de Bicep, et vous pouvez définir des affectations de tâches de stockage dans Bicep.

Les tâches de stockage et les affectations se composent de la configuration et ne contiennent pas les données client que les tâches traitent. Utilisez l’approche IaC décrite précédemment pour récupérer cette configuration. Vous êtes responsable de la protection et de la récupération des données dans vos comptes de stockage cibles séparément. Pour plus d’informations sur les options de protection des données d’stockage Azure, consultez la vue d’ensemble de la protection des données.

Testez votre procédure de récupération dans un environnement hors production. Avant d’activer les affectations recréées, utilisez des aperçus de condition et des exécutions fictifs pour vérifier que la tâche cible les objets blob prévus. Pour plus d’informations, consultez Les meilleures pratiques pour l’utilisation des tâches de stockage.

Résilience à la maintenance du service

Microsoft applique régulièrement des mises à jour de service et effectue d’autres maintenances. La plateforme Azure gère automatiquement ces activités, ce qui garantit que la maintenance est fluide et transparente pour vous. Aucun temps d'arrêt n'est prévu pendant les événements de maintenance, sauf si vous avez été informé via la maintenance planifiée d'Azure Service Health.

Contrat de niveau de service

stockage Azure Actions ne propose pas de contrat de niveau de service de disponibilité (SLA).

Contenu connexe

• Vue d’ensemble d’stockage Azure Actions
• Meilleures pratiques pour l’utilisation des tâches de stockage
• Surveiller stockage Azure Actions
• Fiabilité dans Stockage Blob Azure
• Fiabilité dans Azure