Partager via

La fiabilité du stockage Blob Azure

Le Stockage Blob Azure est une solution de stockage d’objets pour le cloud de Microsoft. Il est conçu pour stocker de grandes quantités de données non structurées telles que du texte, des données binaires, des documents, des fichiers multimédias et des sauvegardes d’applications. En tant que service de stockage Azure de base, Le stockage Blob fournit plusieurs fonctionnalités de fiabilité pour vous assurer que vos données restent disponibles et durables pendant les événements planifiés et non planifiés.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour 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 le stockage Blob résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence certaines informations clés sur le contrat de niveau de service Stockage Blob (SLA).

Remarque

Le stockage Blob fait partie de la plateforme Stockage Azure. Certaines des fonctionnalités de Stockage Blob sont courantes dans de nombreux services stockage Azure. Dans cet article, nous utilisons Stockage Azure pour faire référence à ces fonctionnalités.

Recommandations concernant le déploiement de production

Pour en savoir plus sur le déploiement du stockage Blob pour prendre en charge les exigences de fiabilité de votre solution et sur la façon dont la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour le stockage Blob dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Stockage Azure fournit plusieurs options de redondance pour vous aider à protéger vos données contre différents types d’échecs. Chaque option fournit un niveau spécifique de redondance des données. Vous pouvez donc choisir le niveau qui correspond le mieux aux exigences de votre application.

Le stockage localement redondant (LRS) réplique les données de vos comptes de stockage vers une ou plusieurs zones de disponibilité Azure situées dans la région principale de votre choix. Bien qu’il n’existe aucune option permettant de choisir votre zone de disponibilité préférée, Azure peut déplacer ou développer des comptes LRS entre les zones pour améliorer l’équilibrage de charge. Il n’existe aucune garantie que vos données seront réparties entre les zones. Pour plus d’informations sur les zones de disponibilité, consultez Qu’est-ce que les zones de disponibilité ?.

Diagramme montrant comment les données sont répliquées dans des zones de disponibilité à l’aide de LRS.

Le stockage redondant interzone (ZRS), le stockage géo-redondant (GRS) et le stockage géo-redondant interzone (GZRS) offrent des protections supplémentaires. Cet article décrit ces options en détail.

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, consultez Recommandations pour la gestion des erreurs temporaires.

Pour gérer efficacement les erreurs temporaires lorsque vous utilisez le stockage Blob, implémentez les recommandations suivantes :

  • Utilisez les bibliothèques clientes de stockage Azure, qui incluent des stratégies de nouvelle tentative intégrées avec un backoff exponentiel et du jitter. Les kits SDK .NET, Java, Python et JavaScript gèrent automatiquement les nouvelles tentatives pour les défaillances temporaires. Pour plus d’informations sur les options de configuration de nouvelle tentative, consultez Implémenter une stratégie de nouvelle tentative avec .NET.

  • Configurez les valeurs de délai d’expiration appropriées pour vos opérations d’objet blob en fonction de la taille de l’objet blob et des conditions réseau. Les objets blob plus volumineux nécessitent des délais d’attente plus longs, mais les opérations plus petites peuvent utiliser des valeurs plus courtes pour détecter rapidement les défaillances.

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 Stockage Blob fournit une prise en charge robuste des zones de disponibilité via des configurations ZRS qui distribuent automatiquement vos données entre plusieurs zones de disponibilité au sein d’une région. Contrairement au stockage localement redondant (LRS), ZRS garantit qu’Azure réplique de manière synchrone vos données d’objet blob sur plusieurs zones de disponibilité. ZRS garantit que vos données restent accessibles même si une zone subit une panne.

La redondance de zone est activée au niveau du compte de stockage et s’applique à tous les conteneurs blob au sein de ce compte. Vous ne pouvez pas définir de niveaux de redondance différents pour des conteneurs individuels. La configuration de redondance est appliquée à l’ensemble du compte de stockage. Lorsqu’une zone de disponibilité rencontre une panne, le stockage Azure achemine automatiquement les requêtes vers des zones saines sans intervention de vous ou de votre application.

Diagramme montrant comment les données sont répliquées dans la région primaire avec un stockage redondant interzone (ZRS).

Spécifications

  • Types de comptes de stockage : La redondance de zone est disponible pour les comptes de stockage général v2 Standard et pour les comptes de stockage Blob Premium en blocs. Les objets blob de blocs, les objets blob d’ajout et les objets blob de pages prennent tous en charge les configurations redondantes interzone, mais le type de compte de stockage que vous utilisez détermine les fonctionnalités disponibles. Pour plus d’informations, consultez Types de comptes de stockage pris en charge.

Coûts

Lorsque vous activez le stockage redondant interzone (ZRS), vous n’êtes pas facturé au même tarif que le stockage localement redondant (LRS) en raison du supplément de réplication et de stockage.

Pour plus d’informations, consultez Tarification du Stockage Blob.

Configurez la prise en charge des zones de disponibilité

  • Créez un compte de stockage d’objets blob avec redondance de zone. Pour créer un compte de stockage avec ZRS, consultez Créer un compte de stockage et sélectionner ZRS, stockage géoredondant interzone (GZRS) ou stockage géoredondant à accès en lecture (RA-GZRS) comme option de redondance lors de la création du compte.

  • Changer de type de réplication. Pour savoir comment changer un compte de stockage existant en stockage redondant interzone (ZRS) et connaître les options de configuration et les conditions requises, consultez Modifier la manière dont un compte de stockage est répliqué.

  • Désactivez la redondance de zone. Redéfinissez les comptes ZRS pour revenir à une configuration sans zone, comme le stockage localement redondant (LRS), à l’aide du même processus de changement de configuration de redondance.

Comportement lorsque toutes les zones sont saines

Cette section décrit à quoi s'attendre lorsqu'un compte de stockage Blob est configuré pour la redondance de zone et que toutes les zones d'implantation sont opérationnelles.

  • Routage du trafic entre les zones : Le Stockage Azure avec un stockage redondant interzone (ZRS) distribue automatiquement les requêtes entre les clusters de stockage de plusieurs zones de disponibilité. La distribution du trafic est transparente pour les applications et ne nécessite aucune configuration côté client.

  • Réplication des données entre les zones : Toutes les opérations d’écriture dans un stockage ZRS sont répliquées de manière synchrone sur toutes les zones de disponibilité de la région. Lorsque vous chargez ou modifiez des données, l’opération n’est pas considérée comme terminée tant que les données n’ont pas été répliquées sur toutes les zones de disponibilité. Cette réplication synchrone garantit une cohérence forte et une perte de données nulle pendant les défaillances de zone.

Comportement lors d’une défaillance de zone

Cette section décrit à quoi s'attendre lorsqu'un compte de stockage Blob est configuré pour ZRS et qu'il existe une panne de zone de disponibilité.

  • Détection et réponse : Microsoft détecte automatiquement les défaillances de zone et lance les processus de récupération. Aucune action du client n’est requise pour les comptes de stockage redondant interzone (ZRS).

    Si une zone devient indisponible, Azure procède à des mises à jour du réseau, telles que le repointage DNS (Domain Name Service).

  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Resource Health pour surveiller l’intégrité d’une ressource individuelle, et vous pouvez configurer des alertes Resource Health pour vous avertir des problèmes. Vous pouvez également 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 demandes en vol peuvent être abandonnées pendant le processus de récupération et doivent être retentées. Les applications doivent implémenter une logique de nouvelle tentative pour gérer ces interruptions temporaires.

  • Perte de données attendue : Aucune perte de données ne se produit pendant les échecs de zone, car les données sont répliquées de manière synchrone sur plusieurs zones avant la fin des opérations d’écriture.

  • Temps d’arrêt attendu : Un petit temps d’arrêt, généralement quelques secondes, peut se produire pendant la récupération automatique, car le trafic est redirigé vers des zones saines. Lorsque vous concevez des applications pour le stockage ZRS, suivez les pratiques de gestion des erreurs temporaires, notamment l’implémentation de stratégies de nouvelle tentative avec backoff exponentiel.

  • Réacheminement du trafic : Si une zone de disponibilité est hors connexion, Azure lance des modifications réseau telles que le repointage dns (Domain Name System). Ces mises à jour garantissent que le trafic est redirigé vers les zones de disponibilité restantes saines. Le service gère toutes les fonctionnalités à l’aide des zones survivantes et ne nécessite pas d’intervention du client.

Récupération de la zone

Lorsque la zone de disponibilité ayant échoué est récupérée, le stockage Azure restaure automatiquement les opérations normales sur toutes les zones de disponibilité. Le service garantit automatiquement la cohérence des données en synchronisant toutes les opérations qui se sont produites pendant la période de panne.

Tester les pannes de zone

Lorsque vous utilisez le stockage redondant interzone (ZRS), le Stockage Azure gère automatiquement la réplication, le routage du trafic et les réponses d’échec de zone. Cette fonctionnalité étant complètement managée, vous n’avez pas besoin de lancer ou de valider les processus de défaillance de zone de disponibilité.

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

Le Stockage Azure, y compris Stockage Blob Azure, Azure Files, Stockage Table Azure et Stockage File d’attente Azure, fournit une gamme de fonctionnalités de géo-redondance et de basculement pour répondre à différents besoins.

Important

Le stockage géo-redondant (GRS) fonctionne uniquement dans les régions jumelées Azure. Si la région de votre compte de stockage n’est pas jumelée, envisagez d’utiliser les solutions multirégions personnalisées pour la résilience.

Stockage géo-redondant pour les régions jumelées

Le Stockage Azure fournit plusieurs types de stockage GRS dans des régions jumelées. Quel que soit le type de stockage GRS que vous utilisez, les données de la région secondaire sont toujours répliquées à l’aide du stockage localement redondant (LRS). Cette approche offre une protection contre les défaillances matérielles au sein de la région secondaire.

Stockage géo-redondant

Types de basculement

Le Stockage Azure prend en charge trois types de basculement pour différents scénarios.

  • Basculement non planifié géré par le client : Vous êtes responsable du lancement de la récupération en cas de défaillance du stockage à l’échelle régionale dans votre région primaire.

  • Basculement planifié géré par le client : Vous êtes responsable du lancement de la récupération si une autre partie de votre solution a un échec dans votre région primaire et que vous devez basculer votre solution entière vers une région secondaire. Utilisez un basculement planifié lorsque le stockage reste opérationnel dans la région primaire, mais vous devez basculer l’ensemble de votre solution vers une région secondaire, par exemple pour les exercices de récupération d’urgence conçus pour garantir la conformité et les exigences d’audit.

  • Basculement géré par Microsoft : Dans des circonstances exceptionnelles, Microsoft peut lancer le basculement de tous les comptes de stockage géo-redondant (GRS) d’une région. Toutefois, le basculement géré par Microsoft est un dernier recours et doit être effectué uniquement après une période de panne prolongée. Vous ne devez pas dépendre du basculement géré par Microsoft.

Les comptes GRS peuvent utiliser l’un de ces types de basculement. Vous n’avez pas besoin de préconfigurer un compte de stockage pour utiliser les types de basculement à l’avance.

Spécifications

  • Prise en charge de la région : Les configurations géoredondantes Azure Storage utilisent les régions jumelées d'Azure pour la réplication de la région secondaire. La région secondaire est automatiquement déterminée en fonction de la sélection de votre région primaire et ne peut pas être personnalisée. Pour obtenir la liste complète des régions jumelées Azure, consultez la liste des régions Azure.

    Si la région de votre compte de stockage n’est pas jumelée, envisagez d’utiliser les solutions multirégions personnalisées pour la résilience.

  • Types de comptes de stockage : Le stockage géoredondant (GRS) et le basculement et le retour arrière initiés par le client sont disponibles dans toutes les régions jumelées Azure qui prennent en charge les comptes de stockage Azure à usage général v2.

Considérations

Lorsque vous implémentez le stockage Blob multirégion, tenez compte des facteurs clés suivants :

  • Latence de réplication asynchrone : La réplication des données vers la région secondaire est asynchrone, ce qui signifie qu’il existe un décalage entre le moment où les données sont écrites dans la région primaire et lorsqu’elles sont disponibles dans la région secondaire. Ce décalage peut entraîner une perte de données potentielle si une défaillance de région primaire se produit avant la réplication des données récentes. La perte de données est mesurée via l’objectif de point de récupération (RPO). Ce décalage de réplication sera probablement inférieur à 15 minutes, mais cette durée est une estimation et n’est pas garantie.

    Vous pouvez vérifier la propriété Heure de la dernière synchronisation pour savoir quelle quantité de données est susceptible d’être perdue si votre compte de stockage fait l’objet d’un basculement non planifié.

  • Accès à la région secondaire : Avec les configurations de stockage géo-redondant (GRS) et de stockage géo-redondant interzone (GZRS), la région secondaire n’est pas accessible en lecture tant qu’un basculement n’a pas lieu.

    Les configurations de stockage géo-redondant avec accès en lecture (RA-GRS) et de stockage géo-redondant interzone avec accès en lecture (RA-GZRS) fournissent un accès en lecture à la région secondaire pendant les opérations normales, mais en raison de la latence de réplication asynchrone, elles peuvent retourner des données légèrement obsolètes.

  • Limites de fonctionnalités : Certaines fonctionnalités du Stockage Azure ne sont pas prises en charge ou présentent des limites lorsque vous utilisez le stockage géo-redondant (GRS) ou le basculement géré par le client. Consultez la compatibilité des fonctionnalités avant d’implémenter la géo-redondance.

Coûts

Les configurations de comptes Stockage Azure dans plusieurs régions entraînent des coûts supplémentaires pour la réplication interrégionale et le stockage dans la région secondaire. Le transfert de données entre les régions Azure est facturé en fonction des taux de bande passante interrégion standard.

Pour plus d’informations, consultez Tarification du Stockage Blob.

Configurer la prise en charge multirégion

  • Créez un compte de stockage géo-redondant (GRS). Pour créer un compte GRS, consultez Créer un compte de stockage et sélectionnez GRS, stockage géo-redondant avec accès en lecture (RA-GRS), stockage géo-redondant interzone (GZRS) ou stockage géo-redondant interzone avec accès en lecture (RA-GZRS) lors de la création du compte.

  • Activez la géo-redondance sur un compte de stockage existant. Pour convertir un compte de stockage existant en stockage géoredondant (GRS), consultez Modifier la façon dont un compte de stockage est répliqué.

    Avertissement

    Une fois votre compte reconfiguré pour la géo-redondance, il peut s’écouler beaucoup de temps avant que les données existantes de la nouvelle région primaire ne soient entièrement copiées dans la nouvelle région secondaire.

    Pour éviter une importante perte de données, vérifiez la valeur de la propriété Heure de la dernière synchronisation avant de lancer un basculement non planifié. Pour évaluer la perte de données potentielle, comparez l’heure de la dernière synchronisation à la dernière fois que les données ont été écrites dans la nouvelle région primaire.

  • Désactivez la géoredondance. Redéfinissez les comptes GRS pour revenir à des configurations à une seule région, comme le stockage localement redondant (LRS) ou le stockage redondant interzone (ZRS), en utilisant le même processus de changement de configuration de redondance.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un compte de stockage est configuré pour la géoredondance et que toutes les régions sont opérationnelles.

  • Routage du trafic entre les régions : Le Stockage Azure utilise une approche active-passive où toutes les opérations d’écriture et la plupart des opérations de lecture sont dirigées vers la région primaire.

    Pour les configurations de stockage géo-redondant avec accès en lecture (RA-GRS) et de stockage géo-redondant interzone avec accès en lecture (RA-GZRS), les applications peuvent éventuellement lire depuis la région secondaire en accédant au point de terminaison secondaire. Cette approche nécessite une configuration d’application explicite et n’est pas automatique. En outre, en raison du décalage de réplication asynchrone, les données de la région secondaire peuvent être légèrement obsolètes.

  • Réplication des données entre les régions : Les opérations d’écriture sont tout d’abord validées dans la région primaire à l’aide des types de redondance configurés suivants :

    • Stockage localement redondant (LRS) pour le stockage géo-redondant (GRS) et le stockage RA-GRS
    • Stockage redondant interzone (ZRS) pour le stockage géo-redondant interzone (GZRS) et le stockage RA-GZRS

    Une fois que l’opération a réussi dans la région primaire, les données sont répliquées de manière asynchrone dans la région secondaire où elles sont stockées en utilisant le stockage LRS.

    La nature asynchrone de la réplication interrégionale signifie qu’il existe généralement un décalage entre le moment où les données sont écrites dans la région primaire et lorsqu’elles sont disponibles dans la région secondaire. Vous pouvez surveiller l’heure de réplication à l’aide de la propriété Heure de la dernière synchronisation.

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

Cette section décrit ce qu’il faut attendre lorsqu’un compte de stockage est configuré pour la géoredondance et qu’il existe une panne dans la région primaire.

  • Basculement géré par le client (non planifié) : Utilisez un basculement non planifié lorsque le stockage dans la région primaire n’est pas disponible.

    • Détection et réponse : Dans le cas peu probable où votre compte de stockage n’est pas disponible dans votre région primaire, vous pouvez envisager de lancer un basculement non planifié géré par le client. Pour prendre cette décision, tenez compte des facteurs suivants :

      • Indique si Azure Resource Health présente des problèmes d’accès au compte de stockage dans votre région primaire

      • Indique si Microsoft vous conseille d’effectuer un basculement vers une autre région

      Avertissement

      Un basculement non planifié peut entraîner une perte de données. Avant de lancer un basculement géré par le client, déterminez si la restauration du service justifie le risque d’une perte de données.

    • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois:

    • Demandes actives : Pendant le processus de basculement, les points de terminaison du compte de stockage principal et secondaire deviennent temporairement indisponibles pour les lectures et les écritures. Toutes les demandes actives peuvent être supprimées et les applications clientes doivent réessayer une fois le basculement terminé.

    • Perte de données attendue : La perte de données est courante lors d’un basculement non planifié en raison du décalage de réplication asynchrone, ce qui signifie que les écritures récentes risquent de ne pas être répliquées. Vous pouvez vérifier la propriété Heure de la dernière synchronisation pour savoir quelle quantité de données peut être perdue pendant un basculement non planifié. La perte de données attendue est souvent appelée objectif de point de récupération (RPO). Vous pouvez généralement vous attendre à ce que le RPO soit inférieur à 15 minutes, mais cette durée n’est pas garantie.

    • Temps d’arrêt attendu : Le temps d’arrêt attendu est souvent appelé objectif de temps de récupération (RTO). Le basculement géré par le client s'effectue généralement en moins de 60 minutes, selon la taille et la complexité du compte.

    • Réacheminement du trafic : Une fois le basculement terminé, Azure met automatiquement à jour les points de terminaison du compte de stockage afin que les applications n’ont pas besoin d’être reconfigurées. Si votre application conserve les entrées DNS (Domain Name System) mises en cache, il peut s’avérer nécessaire d’effacer le cache pour vous assurer que l’application envoie le trafic vers la nouvelle région primaire.

    • Configuration post-basculement : Une fois le basculement non planifié terminé, votre compte de stockage dans la région de destination utilise le niveau de stockage localement redondant (LRS). Si vous avez besoin de la géo-répliquer, vous devez réactiver le stockage géo-redondant (GRS) et attendre que les données soient répliquées dans la nouvelle région secondaire.

    Pour plus d’informations sur la façon de lancer un basculement géré par le client, consultez Fonctionnement du basculement (non planifié) géré par le client et Lancer un basculement de compte de stockage.

  • Basculement géré par le client (planifié) : Utilisez un basculement planifié lorsque le stockage reste opérationnel dans la région primaire, mais vous devez basculer toute votre solution vers une région secondaire pour toute autre raison. Par exemple, un autre service Azure peut rencontrer un problème et vous devez passer à l’utilisation d’une région secondaire pour toute votre solution. Vous pouvez également utiliser un basculement planifié pour effectuer un exercice de récupération d'urgence (DR) à des fins de conformité et d'audit.

    • Détection et réponse : vous êtes responsable de la décision de basculer. Vous prenez généralement cette décision si vous devez passer d'une région à l'autre, même si votre compte de stockage fonctionne correctement. Par exemple, vous pouvez déclencher un basculement en cas de panne majeure d’un autre composant d’application que vous ne pouvez pas récupérer dans la région primaire.

      • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois:

    • Demandes actives : Pendant le processus de basculement, les points de terminaison du compte de stockage principal et secondaire deviennent temporairement indisponibles pour les lectures et les écritures. Toutes les demandes actives peuvent être supprimées et les applications clientes doivent réessayer une fois le basculement terminé.

    • Perte de données attendue : Aucune perte de données n’est attendue, car le processus de basculement se termine uniquement après la synchronisation de toutes les données, ce qui entraîne un RPO de zéro.

    • Temps d'indisponibilité prévu : le basculement s'effectue généralement en moins de 60 minutes, ce qui signifie que le RTO prévu est de 60 minutes, en fonction de la taille et de la complexité du compte. Pendant le processus de basculement, les points de terminaison du compte de stockage principal et secondaire deviennent temporairement indisponibles pour les lectures et les écritures.

    • Réacheminement du trafic : Une fois le basculement terminé, Azure met automatiquement à jour les points de terminaison du compte de stockage afin que les applications n’ont pas besoin d’être reconfigurées. Si votre application conserve les entrées DNS mises en cache, il peut s’avérer nécessaire d’effacer le cache pour vous assurer que l’application envoie le trafic à la nouvelle région primaire.

    • Configuration après basculement : Une fois le basculement planifié terminé, votre compte de stockage dans la région de destination continue d’être géorépliqué et reste au niveau GRS.

    Pour plus d’informations sur la façon de lancer un basculement géré par le client, consultez Fonctionnement du basculement (planifié) géré par le client et Lancer un basculement de compte de stockage.

  • Basculement géré par Microsoft : En cas de sinistre majeur où Microsoft détermine que la région primaire est définitivement irrécupérable, un basculement automatique vers la région secondaire peut être lancé. Microsoft gère l’ensemble du processus et aucune action client n’est requise. La durée qui s’écoule avant le basculement dépend de la gravité de la catastrophe et du temps nécessaire pour évaluer la situation.

    • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une région est en panne. Toutefois:

    Important

    Utilisez les options de basculement managé par le client pour développer, tester et implémenter vos plans de récupération d’urgence. Ne comptez pas sur le basculement géré par Microsoft, car il n’est utilisé que dans des situations extrêmes. Un basculement géré par Microsoft est probablement lancé pour une région entière. Il ne peut pas être lancé pour des comptes de stockage, des abonnements ou des clients individuels. Le basculement peut se produire à différents moments pour différents services Azure. Nous vous recommandons d’utiliser un basculement géré par le client.

Récupération de la région

Le processus de restauration automatique diffère considérablement entre les scénarios de basculement géré par Microsoft et géré par le client.

  • Basculement géré par le client (non planifié) : Après un basculement non planifié, le compte de stockage est configuré avec un stockage localement redondant (LRS). Pour effectuer une restauration automatique, vous devez rétablir la relation de stockage géo-redondant (GRS) et attendre que les données soient répliquées.

  • Basculement géré par le client (planifié) : Après un basculement planifié, le compte de stockage reste géo-répliqué. Vous pouvez lancer un autre basculement géré par le client pour effectuer une restauration automatique vers la région primaire d’origine. Les mêmes considérations de basculement s’appliquent.

  • Basculement géré par Microsoft : Si Microsoft lance un basculement, il est probable qu’un sinistre important se soit produit dans la région primaire et que celui-ci ne soit pas récupérable. L’ensemble des chronologies ou plans de récupération dépend de l’étendue du sinistre régional et des efforts consacrés à la reprise d’activité. Vous devez surveiller les communications Azure Service Health pour plus d’informations.

Tester les défaillances régionales

Vous pouvez simuler des défaillances régionales pour tester vos procédures de récupération d’urgence.

  • Test d’un basculement planifié : Pour les comptes de stockage géo-redondant (GRS), vous pouvez effectuer les opérations d’un basculement planifié pendant les fenêtres de maintenance pour tester l’ensemble du processus de basculement et de restauration automatique. Un basculement planifié n’implique pas de perte de données, mais un temps d’arrêt pendant le basculement et la restauration automatique.

  • Test du point de terminaison secondaire : Pour les configurations de stockage géo-redondant avec accès en lecture (RA-GRS) et de stockage géo-redondant interzone avec accès en lecture (RA-GZRS), testez régulièrement les opérations de lecture sur le point de terminaison secondaire pour vous assurer que votre application peut lire correctement les données depuis la région secondaire.

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

Les fonctionnalités de basculement interrégional du Stockage Azure peuvent ne pas convenir pour les raisons suivantes :

  • Votre compte de stockage se trouve dans une région non appariée.

  • Vos objectifs de temps d’activité métier ne sont pas satisfaits par le temps de récupération ou la perte de données que les options de basculement intégrées fournissent.

  • Vous devez basculer vers une région qui n’est pas jumelée à votre région principale.

  • Il vous faut une configuration active/active entre les régions.

Cette section fournit une vue d’ensemble générale de certaines approches à prendre en compte. Une vue d’ensemble complète des topologies de déploiement multirégion pour stockage Azure est en dehors de l’étendue de cet article.

Vous pouvez déployer le Stockage Azure dans plusieurs régions à l’aide de comptes de stockage distincts dans chaque région. Cette approche offre une flexibilité dans la sélection des régions, la possibilité d’utiliser des régions non jumelées et un contrôle plus précis sur la chronologie de la réplication et la cohérence des données. Lorsque vous implémentez plusieurs comptes de stockage dans plusieurs régions, vous devez configurer une réplication de données interrégionale, mettre en œuvre un équilibrage de charge et des stratégies de basculement, et garantir une cohérence des données entre les régions.

La réplication d’objets fournit une option supplémentaire pour la réplication des données inter-régions qui fournit une copie asynchrone d’objets blob de blocs entre les comptes de stockage. Contrairement aux options de stockage géoredondantes intégrées qui utilisent des régions jumelées fixes, la réplication d’objets vous permet de répliquer des données entre des comptes de stockage dans n’importe quelle région Azure, y compris les régions non souhaitées. Cette approche vous donne un contrôle total sur les régions source et de destination, les stratégies de réplication et les conteneurs et préfixes d’objets blob spécifiques à répliquer.

Vous pouvez configurer la réplication d’objets pour répliquer tous les objets blob dans un conteneur ou des sous-ensembles spécifiques en fonction des préfixes et des balises d’objets blob. La réplication est asynchrone et se produit en arrière-plan. Vous pouvez configurer plusieurs stratégies de réplication et même la réplication de chaîne sur plusieurs comptes de stockage pour créer des topologies multirégions sophistiquées.

La réplication d’objets n’est pas compatible avec tous les comptes de stockage. Par exemple, il ne fonctionne pas avec les comptes de stockage qui utilisent des espaces de noms hiérarchiques (également appelés comptes Azure Data Lake Storage Gen2).

Pour plus d’informations, consultez réplication d’objet pour les objets blob de blocs et Configurer la réplication d’objets.

Sauvegarde et récupération

Le Stockage Blob fournit plusieurs mécanismes de protection des données qui complètent la redondance pour des stratégies de sauvegarde complètes. La redondance intégrée du service protège contre les défaillances d’infrastructure et les fonctionnalités de sauvegarde supplémentaires protègent contre la suppression accidentelle, la corruption et les activités malveillantes.

La restauration à un point dans le temps (PITR) vous permet de restaurer des données d’objet blob de blocs dans un état précédent dans une période de rétention configurée allant jusqu’à 365 jours. Microsoft gère entièrement cette fonctionnalité. Il fournit également des fonctionnalités de récupération granulaires au niveau du conteneur ou de l’objet blob. Les données PITR sont stockées dans la même région que le compte source et sont accessibles même pendant les pannes régionales si vous utilisez des configurations géoredondantes.

Le contrôle de version d’objets blob gère automatiquement les versions précédentes des objets blob lorsqu’ils sont modifiés ou supprimés. Chaque version est stockée en tant qu’objet distinct et est accessible indépendamment. Les versions sont stockées dans la même région que l’objet blob actuel et suivent la même configuration de redondance que le compte de stockage.

La suppression réversible fournit un filet de sécurité pour les objets blob et conteneurs supprimés accidentellement en conservant les données supprimées pendant une période configurable. Les données supprimées de manière réversible restent dans le même compte de stockage et la même région, ce qui le rend immédiatement disponible pour la récupération. Pour les comptes géo-redondants, les données supprimées de manière réversible sont également répliquées dans la région secondaire.

Les instantanés d’objets blob créent des copies en lecture seule et ponctuelles d’objets blob que vous pouvez utiliser pour les scénarios de sauvegarde et de récupération. Les instantanés sont stockés dans le même compte de stockage et suivent les mêmes paramètres de redondance et de géoréplication que l’objet blob de base.

Pour les exigences de sauvegarde inter-régions, envisagez d’utiliser Sauvegarde Azure pour les objets blob, qui fournit une gestion centralisée des sauvegardes et peut stocker des données de sauvegarde dans des régions différentes des données sources. Ce service fournit des options de sauvegarde opérationnelles et coffretées qui ont des stratégies de rétention configurables et des fonctionnalités de restauration. Pour plus d’informations, consultez La vue d’ensemble de la sauvegarde pour les objets blob.

Pour la plupart des solutions, vous ne devez pas vous appuyer exclusivement sur les sauvegardes. Utilisez plutôt les autres fonctionnalités décrites dans ce guide pour prendre en charge vos exigences de résilience. Toutefois, les sauvegardes protègent contre certains risques que d’autres approches ne le font pas. Pour plus d’informations, consultez Que sont la redondance, la réplication et la sauvegarde ?.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour stockage Azure décrit la disponibilité attendue du service et les conditions qui doivent être remplies pour atteindre cette attente de disponibilité. Le contrat SLA de disponibilité auquel vous êtes éligible dépend du niveau de stockage et du type de réplication que vous utilisez. Pour plus d’informations, consultez Contrats SLA pour les services en ligne.

Contenu connexe

  • Last updated on