Partager via

Fiabilité dans Azure NetApp Files

Azure NetApp Files est une solution de stockage de fichiers native de niveau entreprise qui s’intègre en toute transparence dans Azure et permet le partage de fichiers entre les clients via des protocoles NFS (Network File System) et Server Message Block (SMB). Azure NetApp Files est conçu pour des performances élevées et fournit un stockage de fichiers évolutif et sécurisé géré en tant que service.

Lorsque vous utilisez Azure, reliability 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 NetApp 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 (SLA) Azure NetApp Files.

Recommandations concernant le déploiement de production

Pour en savoir plus sur le déploiement de Azure NetApp Files 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 Architecture pour les Azure NetApp Files dans le Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Pour utiliser Azure NetApp Files, vous devez configurer un compte NetApp qui contient des pools capacité qui hébergent volumes. Vous pouvez configurer la capacité et le débit indépendamment et gérer les options de protection des données qui répondent à divers besoins. Vous pouvez activer la réplication entre les volumes, même s'ils se trouvent à des emplacements différents.

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

En plus des types d’erreurs temporaires qui peuvent affecter n’importe quelle solution basée sur le cloud, une maintenance occasionnelle planifiée, comme les mises à jour de plateforme, les mises à jour de service et les mises à niveau logicielles, peut également affecter Azure NetApp Files.

Du point de vue des protocoles de fichiers, tels que NFS et SMB, les défaillances transitoires ne sont pas perturbatrices si l'application est capable de gérer les pauses d'entrée/sortie (E/S) qui peuvent survenir lors de ces événements. Les pauses d’e/s sont généralement courtes, allant de quelques secondes à 30 secondes. Certaines applications peuvent nécessiter un réglage pour gérer les pauses d'E/S.

Le protocole NFS est robuste et les opérations de fichiers client-serveur se poursuivent généralement normalement. Certaines applications peuvent nécessiter un réglage pour gérer les pauses d'E/S d'une durée allant jusqu'à 30 à 45 secondes. Assurez-vous de connaître les paramètres de résilience de l’application pour faire face aux événements de maintenance du service de stockage.

Pour les applications interactives qui utilisent le protocole SMB, les paramètres standard du protocole sont généralement suffisants. Azure NetApp Files prend également en charge la disponibilité continue de SMB, qui permet le basculement transparent de SMB. Le basculement transparent SMB élimine les interruptions causées par les opérations de maintenance des services. Cela améliore également la fiabilité et l’expérience utilisateur.

La disponibilité continue SMB n'est disponible que pour des applications spécifiques.

Pour plus de recommandations, consultez Faq sur la résilience des applications pour Azure NetApp Files.

Résilience aux échecs de zone de disponibilité

Zones d’indisponibilité 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 NetApp Files prend en charge les déploiements de volumes zonal. Utilisez la fonctionnalité de placement de volume de la zone de disponibilité dans Azure NetApp Files pour déployer chaque volume dans une seule zone de disponibilité de votre choix. Vous ne pouvez utiliser cette fonctionnalité que si Azure NetApp Files est présent dans cette zone de disponibilité et dispose d’une capacité suffisante. Si vous avez des applications sensibles à la latence, vous pouvez déployer un volume dans la même zone de disponibilité que vos Azure ressources de calcul et d’autres services.

Dans le diagramme suivant, les flèches orange avec des pointes de flèches solides représentent la façon dont toutes les machines virtuelles au sein de la région dans les réseaux virtuels appairés peuvent accéder à toutes les ressources Azure NetApp Files. Les flèches vertes représentent comment les VM qui accèdent aux volumes Azure NetApp Files dans la même zone partagent le domaine de défaillance de la zone de disponibilité. Il n’existe aucune réplication entre les différents volumes au niveau de la plateforme.

Diagramme montrant le placement des volumes d'Azure NetApp Files dans la zone de disponibilité.

Un déploiement sur une seule zone n’est pas suffisant pour répondre aux exigences de fiabilité élevées. Pour répliquer de manière asynchrone des données entre des volumes dans différentes zones de disponibilité, vous pouvez utiliser la réplication interzone. Vous devez configurer la réplication interzone séparément du placement du volume de zone de disponibilité.

Si une zone de disponibilité tombe en panne, vous êtes responsable de la détection de la panne et du passage à un volume alternatif dans une zone différente.

Exigences

  • Region support : La réplication interzone est disponible dans toutes les régions avec prise en charge de zones de disponibilité qui prennent en charge Azure NetApp Files.

  • Le placement des volumes dans une zone de disponibilité dans Azure NetApp Files fournit un placement zonal des volumes. Vous verrez une faible latence lorsque vous vous connectez à des machines virtuelles dans la même zone de disponibilité. Cependant, le placement des volumes dans les zones de disponibilité n'assure pas la proximité avec les machines virtuelles ou d'autres ressources, et le volume peut se trouver dans une partie physique différente du centre de données.

  • La réplication entre différents abonnements Azure n'est autorisée que s'ils appartiennent au même locataire Microsoft Entra.

  • Pour plus d’informations sur les zones de disponibilité dans Azure NetApp Files, consultez Requirements et considérations relatives à l’utilisation de la réplication interzone et Placement du volume de zone de disponibilité de gestion.

Coûts

Il n'y a pas de frais supplémentaires pour activer le placement de volumes dans une zone de disponibilité avec Azure NetApp Files. Vous ne payez que pour les pools de capacité et les ressources que vous déployez dans ces zones.

Les volumes répliqués sont hébergés sur un pool de capacité. Le coût de la réplication interzone est basé sur la taille et le niveau du pool de capacité approvisionnés. Il n’y a aucun coût supplémentaire pour la réplication des données.

Configurez la prise en charge des zones de disponibilité

Vous devez configurer séparément le placement du volume et la réplication interzone.

  • Placement du volume :

    • Créez un nouveau volume ou configurez un volume existant avec prise en charge de la zone de disponibilité. Pour configurer des zones de disponibilité pour les volumes dans Azure NetApp Files, consultez Gérer le placement des volumes dans les zones de disponibilité pour Azure NetApp Files.

      Si vous déployez des volumes gérés par Terraform avec des zones de disponibilité, d’autres configurations sont requises. Pour plus d'informations, consultez Remplir la zone de disponibilité pour les volumes gérés par Terraform.

      Si vous utilisez un contrôle d'accès basé sur les rôles, assurez-vous de configurer les autorisations appropriées.

    • Migrez un volume entre les zones de disponibilité. Après avoir configuré un volume pour le placer dans une zone de disponibilité, la zone de disponibilité spécifiée ne peut pas être modifiée. Vous ne pouvez pas déplacer de volumes entre les zones de disponibilité.

    • Désactiver la prise en charge de la zone de disponibilité pour un volume. Une fois que vous avez configuré un volume pour le placer dans une zone de disponibilité, vous ne pouvez plus désactiver la prise en charge de la zone de disponibilité.

  • Réplication interzone :

    • Créer une réplication interzone Pour améliorer la résilience de votre solution, configurez la réplication interzone pour un autre volume.

    • Désactivez une réplication interzone. Vous pouvez désactiver la réplication interzone en cassant le jumelage de réplication. Pour plus d’informations, consultez Manage de récupération d’urgence à l’aide de Azure NetApp Files.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque plusieurs volumes Azure NetApp Files sont déployés dans des zones de disponibilité distinctes, que la réplication interzone est activée et que toutes les zones de disponibilité sont opérationnelles.

  • Acheminement du trafic entre les zones : les requêtes entrantes sont acheminées vers le volume spécifique, situé dans la zone de disponibilité que vous avez sélectionnée.

  • La réplication des données entre les zones : la réplication interzone d'Azure NetApp Files signifie que toutes les modifications apportées au volume source sont répliquées de manière asynchrone vers les volumes de destination. Vous pouvez décider de la fréquence à laquelle la réplication doit avoir lieu. La réplication interzone prend en charge trois planifications de réplication : toutes les 10 minutes, toutes les heures et tous les jours.

    Important

    Le calendrier de réplication de 10 minutes n’est pas pris en charge pour les grands volumes qui utilisent la réplication interzone.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu'il faut attendre lorsque plusieurs volumes Azure NetApp Files sont déployés dans des zones de disponibilité distinctes, que la réplication interzone est activée et qu'il existe une panne de zone de disponibilité.

  • Détection et réponse : Vous êtes responsable de la détection de la perte d'une zone de disponibilité et du lancement d'un basculement.

    Le basculement est un processus manuel. Lorsque vous devez activer le volume de destination, par exemple lorsque vous souhaitez basculer vers la zone de disponibilité de destination, vous devez interrompre le peering de réplication, puis monter le volume de destination. Pour plus d’informations, consultez Basculer vers le volume de destination.

  • Notification : Pour surveiller l’intégrité de votre volume Azure NetApp Files, vous pouvez utiliser des métriques Azure Monitor. Azure Monitor détecte toutes les anomalies qui indiquent un scénario de zone vers le bas via des métriques en temps réel, telles que les opérations d’entrée/sortie par seconde (IOPS), la latence et l’utilisation de la capacité. Vous pouvez configurer des alertes et des notifications à envoyer aux administrateurs afin qu’ils puissent immédiatement répondre en rééquilibrant les partages de fichiers ou en lançant le basculement ou d’autres protocoles de récupération d’urgence.

  • Requêtes actives : Lors d'un événement de zone morte, les requêtes actives peuvent subir des interruptions ou des latences accrues.

  • Perte de données attendue : la quantité de données perdues, ou objectif de point de récupération (RPO), à laquelle vous pouvez vous attendre lors d'un basculement de zone dépend du calendrier de réplication inter-zones que vous configurez.

    Calendrier de réplication RPO typique
    Toutes les 10 minutes 20 minutes
    Toutes les heures Deux heures
    Quotidien Moins de 48 heures

  • Temps d'arrêt prévu : Le basculement vers une autre zone nécessite que vous rompiez la relation de peering pour activer le volume de destination et fournir un accès aux données en lecture et en écriture sur le deuxième site. Après avoir déclenché la rupture du peering, vous pouvez vous attendre à ce que le basculement soit effectué en moins d'une minute.

    Cependant, la durée totale d'indisponibilité, ou objectif de temps de récupération (RTO), à laquelle vous pouvez vous attendre lors d'un basculement de zone dépend de plusieurs facteurs, notamment le temps nécessaire à vos systèmes ou processus pour détecter la perte de la zone et lancer les processus de basculement. Il est également important de décider si vous souhaitez automatiser votre réponse ou si des étapes manuelles sont nécessaires. Pour des configurations bien préparées, le processus global nécessite généralement entre quelques minutes et jusqu'à une heure pour terminer.

  • Redirection du trafic : Vous êtes responsable de la redirection du trafic de votre application pour vous connecter au volume de destination nouvellement actif. Pour plus d’informations, consultez Basculer vers le volume de destination.

Récupération de la zone

La reprise après défaillance est un processus manuel qui nécessite d'effectuer une opération de resynchronisation, de rétablir la réplication et de remonter le volume source pour que le client puisse y accéder. Pour plus d’informations, consultez Manage de récupération d’urgence à l’aide de Azure NetApp Files.

Tester les pannes de zone

Vous pouvez tester votre configuration de réplication interzone en toute sécurité en utilisant des instantanés de votre volume. Pour en savoir plus sur une approche générale pour tester votre configuration de réplication interzone, consultez Test de récupération d’urgence pour Azure NetApp Files.

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

Par défaut, Azure NetApp Files est un service à région unique. Si la région devient indisponible, les volumes stockés dans cette région sont également indisponibles. Pour améliorer la résilience si une panne régionale se produit, Azure NetApp Files prend en charge la réplication interrégion. Vous pouvez répliquer de manière asynchrone des données à partir d’un volume Azure NetApp Files (la source) dans une autre région vers un autre volume Azure NetApp Files (la destination) dans une autre région que Microsoft préélectionne. Cette fonctionnalité vous permet de basculer votre application critique en cas de panne ou d’incident touchant l’ensemble de la région.

Note

Vous pouvez également répliquer un volume unique vers une autre zone de disponibilité et vers une autre région. Pour plus d’informations, consultez Comprendre la réplication Azure NetApp Files.

Exigences

Prise en charge de la région : La région secondaire à laquelle vous pouvez répliquer vos volumes dépend de la région primaire. Pour plus d'informations, consultez les paires de régions prises en charge.

Considérations

La réplication est autorisée entre différents abonnements Azure uniquement s'ils appartiennent au même locataire Microsoft Entra.

Pour d’autres considérations relatives à la réplication interrégion dans Azure NetApp Files, consultez Requirements et considérations relatives à l’utilisation de la réplication interrégion.

Coûts

Les frais de réplication interrégion sont basés sur la quantité de données que vous répliquez. Pour plus de détails et quelques exemples de scénarios, consultez Modèle de coût pour la réplication interrégionale.

Configurer la prise en charge multirégion

  • Activer la réplication interrégionale : pour améliorer la résilience de votre solution, configurez la réplication interrégionale.

  • Désactiver la réplication interrégionale : vous pouvez désactiver la réplication interrégionale en rompant le couplage de réplication. Pour plus d’informations, consultez Manage de récupération d’urgence à l’aide de Azure NetApp Files.

Comportement lorsque toutes les régions sont saines

Cette section décrit ce qu’il faut attendre quand Azure NetApp Files volumes sont configurés pour utiliser la réplication interrégion et les deux régions sont opérationnelles.

  • Acheminement du trafic entre les régions : Les requêtes entrantes sont acheminées vers le volume spécifique, situé dans la région principale.

  • La réplication des données entre les régions : la réplication inter-régions Azure NetApp Files signifie que toutes les modifications apportées au volume source sont répliquées de manière asynchrone vers les volumes de destination. Vous pouvez décider de la fréquence à laquelle la réplication doit avoir lieu. La réplication interrégionale prend en charge trois programmes de réplication : toutes les 10 minutes, toutes les heures et tous les jours.

    Important

    La planification de réplication de 10 minutes n'est pas prise en charge pour les volumes importants qui utilisent la réplication interrégionale.

  • Surveiller l’état de la réplication : Vous pouvez surveiller l’état de la relation de peering et configurer des alertes pour vous avertir si le décalage de réplication augmente au-delà du seuil prévu. Pour en savoir plus, consultez Afficher l'état de santé et surveiller l'état de la relation de réplication.

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

Cette section décrit ce qu'il faut attendre quand Azure NetApp Files volumes sont configurés pour utiliser la réplication inter-régions et qu'il existe une panne de la région primaire.

  • Détection et réponse : Vous êtes responsable de la détection de la perte d'une région et du lancement d'un basculement. Le basculement est un processus manuel. Lorsque vous devez activer le volume de destination, par exemple lorsque vous souhaitez basculer vers la région de destination, vous devez interrompre le peering de réplication, puis monter le volume de destination. Pour plus d’informations, consultez Basculer vers le volume de destination.

  • Notification : Pour surveiller l’intégrité de votre volume Azure NetApp Files, vous pouvez utiliser des métriques Azure Monitor. Azure Monitor détecte toutes les anomalies qui indiquent un scénario de baisse de région via des métriques en temps réel telles que les E/S par seconde, la latence et l’utilisation de la capacité. Vous pouvez configurer des alertes et des notifications à envoyer aux administrateurs afin qu’ils puissent immédiatement répondre en rééquilibrant les partages de fichiers ou en lançant le basculement ou d’autres protocoles de récupération d’urgence.

  • Requêtes actives : Lors d'un événement de panne de région, les requêtes actives peuvent subir des interruptions ou des latences accrues.

  • Perte de données attendue : la quantité de perte de données ou de RPO que vous pouvez attendre pendant un basculement de région dépend de la planification de réplication inter-régions que vous configurez.

    Calendrier de réplication RPO typique
    Toutes les 10 minutes Moins de 20 minutes
    Toutes les heures Moins de deux heures
    Quotidien Moins de 48 heures

  • Temps d'arrêt prévu : Le basculement vers une autre région nécessite que vous rompiez la relation de peering pour activer le volume de destination et fournir un accès aux données en lecture et en écriture sur le deuxième site. Après avoir déclenché la rupture du peering, vous pouvez vous attendre à ce que le basculement soit effectué en moins d'une minute.

    Cependant, la durée totale du temps d'arrêt, ou RTO, à laquelle vous pouvez vous attendre lors d'un basculement de zone dépend de plusieurs facteurs, notamment du temps nécessaire à vos systèmes ou processus pour détecter la perte de la zone et lancer les processus de basculement. Il est également important de décider si vous souhaitez automatiser votre réponse ou si des étapes manuelles sont nécessaires. Pour des configurations bien préparées, le processus global nécessite généralement entre quelques minutes et jusqu'à une heure pour terminer.

  • Redirection du trafic : Vous êtes responsable de la redirection du trafic de votre application pour vous connecter au volume de destination nouvellement actif. Pour plus d’informations, consultez Basculer vers le volume de destination.

Récupération de région

Une fois la région primaire récupérée, vous êtes responsable de la restauration automatique. La reprise après défaillance est un processus manuel qui nécessite d'effectuer une opération de resynchronisation, de rétablir la réplication et de remonter le volume source pour que le client puisse y accéder. Pour plus d’informations, consultez Manage de récupération d’urgence à l’aide de Azure NetApp Files.

Tester les défaillances régionales

Vous pouvez tester votre configuration de réplication interrégionale en toute sécurité en utilisant des instantanés de votre volume. Pour en savoir plus sur une approche générale pour tester votre configuration de réplication interrégion, consultez Test de récupération d’urgence pour Azure NetApp Files.

Sauvegarde et restauration

Azure NetApp Files sauvegarde étend les fonctionnalités de protection des données de Azure NetApp Files en fournissant une solution de sauvegarde entièrement managée pour la récupération, l’archivage et la conformité à long terme. Les sauvegardes créées par le service sont stockées dans Azure stockage, indépendamment des instantanés de volume disponibles pour la récupération ou le clonage à court terme. Les sauvegardes effectuées par le service peuvent être restaurées sur de nouveaux volumes Azure NetApp Files dans la région. Azure NetApp Files sauvegarde prend en charge les sauvegardes basées sur des stratégies (planifiées) et les sauvegardes manuelles (à la demande).

Pour renforcer la sécurité, Azure NetApp Files snapshots ajouter la stabilité, la scalabilité et la récupération rapide sans affecter les performances. Ils fournissent la base d’autres solutions de redondance, notamment la sauvegarde, la réplication interrégion et la réplication interzone.

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 Azure services décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Contenu connexe

  • Last updated on