Partager via

Fiabilité dans Azure Files

Cet article décrit la prise en charge de la fiabilité dans Azure Files. Azure Files fournit des partages de fichiers entièrement managés dans le cloud accessibles via des protocoles SMB (Server Message Block) et NFS (Network File System).

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 Azure Files 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 Azure Files (SLA).

Note

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

Recommandations concernant le déploiement de production

Pour savoir comment déployer Azure Files pour prendre en charge les exigences de fiabilité de votre solution et comment la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour Azure Files dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

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 du 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.

Azure Files est disponible dans deux niveaux multimédias :

  • Le niveau Premium utilise des disques SSD pour des performances élevées. Ce niveau est recommandé pour les charges de travail nécessitant une faible latence.

  • Le niveau Standard prend en charge les disques durs (HDD). Les partages de fichiers HDD fournissent une option de stockage économique pour les partages de fichiers à usage général.

Pour plus d’informations, consultez Planifier le déploiement des niveaux Azure Files - Stockage.

Azure Files implémente la redondance au niveau du compte de stockage, et les partages de fichiers héritent automatiquement de cette configuration de redondance. Le service prend en charge plusieurs modèles de redondance qui diffèrent dans leur approche de la protection des données.

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 Azure Files, configurez les valeurs de délai d’expiration appropriées pour vos opérations de fichier en fonction de la taille de fichier et des conditions réseau. Les fichiers plus volumineux nécessitent des délais d’expiration plus longs, tandis que les opérations plus petites peuvent utiliser des valeurs plus courtes pour détecter rapidement les défaillances.

Pour vous assurer que seules les connexions sécurisées sont établies sur votre partage NFS, nous vous recommandons de configurer un point de terminaison privé pour votre compte de stockage. Un point de terminaison privé utilise Azure Private Link pour affecter une adresse IP statique à votre compte de stockage à partir de l’espace d’adressage privé de votre réseau virtuel. Un point de terminaison privé permet d’empêcher les interruptions de connectivité des modifications d’adresses IP dynamiques. Pour plus d’informations sur la sécurité de vos partages NFS, consultez partages de fichiers NFS - Sécurité et mise en réseau.

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.

Azure Files fournit une prise en charge robuste des zones de disponibilité par le biais de configurations ZRS qui distribuent automatiquement vos données entre plusieurs zones de disponibilité au sein d’une région. Contrairement à LRS, ZRS garantit qu’Azure réplique de façon synchrone vos données de fichier dans plusieurs zones de disponibilité. ZRS garantit que vos données restent accessibles même si une zone subit une panne.

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

Spécifications

ZRS est pris en charge dans :

Coûts

Lorsque vous activez le stockage redondant interzone (ZRS), vous êtes facturé à un taux différent de celui du stockage localement redondant (LRS) en raison de la surcharge supplémentaire de réplication et de stockage.

Pour obtenir des informations détaillées sur la tarification, consultez la tarification d’Azure Files.

Configurez la prise en charge des zones de disponibilité

  • Créez un partage de fichiers avec redondance de zone. Pour créer un partage de fichiers avec ZRS, consultez Créer un partage de fichiers Azure et sélectionnez ZRS ou GZRS comme option de redondance lors de la création du compte.

  • Modifier le type de réplication. Pour convertir un compte de stockage existant en ZRS et en savoir plus sur les options de migration et les exigences, consultez Modifier la configuration de redondance pour Azure Files.

  • Désactivez la redondance de zone. Convertissez des comptes ZRS en une configuration nonzonale, telle que LRS, via le même processus de modification de configuration de redondance.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsqu’un compte de stockage de fichiers est configuré pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

  • Routage du trafic entre les zones : le Stockage Azure avec stockage redondant interzone (ZRS) distribue automatiquement les requêtes entre les clusters de stockage dans 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 le ZRS sont répliquées de manière synchrone dans toutes les zones de disponibilité au sein 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 ce qu’il faut attendre lorsqu’un compte de stockage de fichiers est configuré pour la redondance de zone 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 temps d’arrêt peu important, 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 ZRS, suivez les pratiques de gestion des erreurs temporaires, notamment l’implémentation de stratégies de nouvelle tentative avec temporisation exponentielle.

  • Réacheminement du trafic : Azure redirige automatiquement le trafic vers les zones de disponibilité saines restantes. Le service conserve pleinement ses fonctionnalités en utilisant les zones survivantes sans intervention du client. Aucun remontage des partages de fichiers Azure des clients connectés n’est nécessaire.

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érentes exigences.

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 GRS dans les régions jumelées. Quel que soit le type de 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.

Important

Azure Files prend uniquement en charge la géoredondance (GRS ou GZRS) pour les partages de fichiers standard (HDD).

Azure Files ne prend pas en charge le stockage géo-redondant avec accès en lecture (RA-GRS) ni le stockage géo-redondant interzone avec accès en lecture (RA-GZRS). Si un compte de stockage est configuré pour utiliser RA-GRS ou RA-GZRS, les partages de fichiers standard (HDD) sont configurés et facturés en tant que GRS ou GZRS.

Types de basculement

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

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

  • 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 managé par Microsoft : dans des circonstances exceptionnelles, Microsoft peut lancer le basculement pour tous les comptes de stockage géo-redondant (GRS) dans 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 principale 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.

  • Partages de fichiers standard uniquement : Azure Files prend uniquement en charge la géoredondance (GRS ou GZRS) pour les partages de fichiers standard (HDD). Les partages de fichiers Premium (SSD) doivent utiliser LRS ou ZRS. Si vous avez des partages de fichiers Premium et que vous souhaitez répliquer les données entre les régions pour une résilience plus élevée, consultez les solutions multirégions personnalisées pour la résilience.

  • GRS et GZRS uniquement : Azure Files ne prend pas en charge le stockage géoredondant avec accès en lecture (RA-GRS) ou le stockage géoredondant interzone avec accès en lecture (RA-GZRS). Si un compte de stockage est configuré pour utiliser RA-GRS ou RA-GZRS, les partages de fichiers standard (HDD) sont configurés et facturés en tant que GRS ou GZRS.

Considérations

Lorsque vous implémentez Azure Files multirégion, tenez compte des facteurs importants 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 principale 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 principale se produit avant la réplication des données récentes. La perte de données est mesurée par 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 comprendre la quantité de données susceptible d’être perdue si votre compte de stockage subit un basculement non planifié.

  • Heure de la dernière synchronisation : Pour Azure Files, l’heure de la dernière synchronisation est basée sur la dernière capture instantanée système dans la région secondaire.

    Le calcul de l’heure de la dernière synchronisation peut expirer s’il y a plus de 100 partages de fichiers dans un compte de stockage. Nous vous recommandons de déployer 100 partages de fichiers ou moins pour chaque compte de stockage afin d’éviter les délais d’expiration.

  • Accès à la région secondaire : la région secondaire n’est pas accessible pour les lectures jusqu’à ce qu’un basculement ait lieu.

  • Limitations des fonctionnalités : Certaines fonctionnalités d’Azure Files ne sont pas prises en charge ou présentent des limitations lorsque vous utilisez grS ou un basculement géré par le client. Ces limitations incluent des types de partages de fichiers spécifiques, des niveaux d’accès et des outils et opérations de gestion. Passez en revue la documentation de compatibilité des fonctionnalités avant d’implémenter la géoredondance.

Coûts

Les configurations de compte de stockage Azure multi-régions entraînent des coûts supplémentaires pour la réplication interrégion 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 obtenir des informations détaillées sur la tarification, consultez la tarification d’Azure Files.

Configurer la prise en charge multirégion

  • Créer 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éoredondance sur un compte de stockage de fichiers existant. Pour convertir un compte de stockage de fichiers existant en GRS, consultez Modifier la configuration de redondance pour Azure Files.

    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 principale 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 où les données ont été écrites dans la nouvelle région primaire.

  • Désactivez la géoredondance. Convertissez les comptes GRS en configurations à région unique (LRS ou ZRS) via le même processus de modification 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 : Azure Files utilise une approche active-passive où toutes les opérations de lecture et d’écriture sont dirigées vers la région primaire.

  • Réplication des données entre les régions : Les opérations d’écriture sont d’abord validées dans la région primaire à l’aide du type de redondance configuré (LRS pour GRS ou ZRS pour GZRS). Une fois l’achèvement 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 à l’aide de LRS.

    La nature asynchrone de la réplication interrégion signifie qu’il existe généralement un décalage entre le moment où les données sont écrites dans la région principale et lorsqu’elles sont disponibles dans la région secondaire. Vous pouvez surveiller l’heure de réplication en utilisant 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 managé par le client (non planifié) : utilisez un basculement non planifié lorsque le stockage dans la région principale 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 principale

      • 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 managé par le client, déterminez si la restauration du service justifie le risque de 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 la réplication asynchrone, ce qui signifie que les écritures récentes peuvent ne pas être répliquées. Vous pouvez vérifier la propriété Heure de la dernière synchronisation pour comprendre la quantité de données susceptible d’ê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 être nécessaire d’effacer le cache pour vous assurer que l’application envoie le trafic vers la nouvelle région principale.

    • Configuration après 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 le 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 managé par le client, consultez Fonctionnement du basculement managé par le client (non planifié) et Lancer un basculement de compte de stockage.

  • Basculement managé par le client (planifié) : utilisez un basculement planifié lorsque le stockage reste opérationnel dans la région principale, mais que vous devez basculer toute votre solution vers une région secondaire pour une 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 être nécessaire d’effacer le cache pour vous assurer que l’application envoie le trafic vers la nouvelle région principale.

    • 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 managé par le client, consultez Fonctionnement du basculement managé par le client (planifié) 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 managé 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 le basculement managé 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 managés par Microsoft et managés par le client.

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

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

  • Basculement managé par Microsoft : si Microsoft lance un basculement, il est probable qu’une catastrophe importante s’est produite dans la région principale et que celle-ci ne soit pas récupérable. Toutes les chronologies ou plans de récupération dépendent de l’étendue des efforts liés au sinistre régional et à la reprise d’activité. Vous devez surveiller les communications Azure Service Health pour plus d’informations.

Tester les défaillances régionales

Pour les comptes de GRS, vous pouvez effectuer des opérations de basculement planifiées pendant les fenêtres de maintenance pour tester le processus complet 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.

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

Les fonctionnalités de basculement inter-régions 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.

  • Vous utilisez des types de partage de fichiers qui ne prennent pas en charge la géoredondance.

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.

Tenez compte des approches générales courantes suivantes :

  • Plusieurs comptes de stockage : Azure Files peut être déployé 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 la réplication des données inter-régions, implémenter l’équilibrage de charge et les stratégies de basculement, et garantir la cohérence des données entre les régions.

  • Réplication au niveau de l’application : Implémentez une logique de réplication personnalisée à l’aide d’Azure Data Factory ou d’AzCopy pour synchroniser des données entre des partages de fichiers dans différentes régions. Cette approche nécessite des mécanismes de développement et de résolution des conflits personnalisés.

  • Utilisez Azure File Sync pour répliquer des fichiers dans un partage de fichiers dans une autre région Azure. Vous pouvez utiliser Azure File Sync pour synchroniser un partage de fichiers SMB Azure (point d'accès cloud), un serveur de fichiers Windows local, et un partage de fichiers monté qui s’exécute sur une machine virtuelle dans une autre région Azure (serveur de reprise après sinistre).

    Cette approche vous oblige à déployer plusieurs partages de fichiers et une machine virtuelle pour coordonner le processus de synchronisation.

    Si vous utilisez cette approche pour la réplication de fichiers multirégions :

    • Désactivez la hiérarchisation cloud pour vous assurer que toutes les données sont présentes localement sur le serveur de fichiers.

    • Provisionnez suffisamment de stockage sur la machine virtuelle Azure pour contenir l’intégralité du jeu de données.

    • Accédez et modifiez des fichiers sur le point de terminaison du serveur, et non dans Azure, pour vous assurer que les modifications sont répliquées rapidement dans la région secondaire.

Sauvegarde et restauration

La sauvegarde Azure Files est une intégration native entre Azure Files et Sauvegarde Azure conçue pour protéger les données contre les attaques accidentelles de suppression, de corruption et de ransomware.

La sauvegarde Azure Files crée des instantanés au niveau du partage stockés dans le même compte de stockage. Cette fonctionnalité permet la récupération rapide des fichiers individuels et des partages de fichiers entiers. Vous pouvez également utiliser des stratégies de sauvegarde pour fournir de longues périodes de rétention avec une fréquence de sauvegarde personnalisable.

Vous pouvez créer vos instantanés et les stocker de deux façons différentes :

  • Stockage au niveau du partage : Pour les scénarios de récupération opérationnels et à court terme, vous pouvez créer des instantanés au niveau du partage et les stocker dans le même compte de stockage. Les instantanés au niveau du partage de fichiers permettent une récupération rapide de fichiers individuels ou de partages de fichiers entiers vers l’emplacement d’origine ou un autre emplacement.

  • Stockage de sauvegarde en coffre : En utilisant la sauvegarde en coffre, vous pouvez copier vos instantanés quotidiens dans un coffre Azure Recovery Services. Pour améliorer la sécurité, ce coffre est isolé et déconnecté par rapport au compte de stockage principal.

    Lorsque vous utilisez une région Azure jumelée et configurez le coffre pour utiliser GRS, le coffre réplique les données dans la région jumelée. Cette réplication prend en charge la récupération inter-régions et les flux de travail de récupération d’urgence.

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