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 offrir des performances élevées et fournit un stockage de fichiers évolutif et sécurisé, géré en tant que service.

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

Recommandations concernant le déploiement de production

Pour en savoir plus sur la manière de déployer Azure NetApp Files afin de prendre en charge les exigences de fiabilité de votre solution et sur la manière dont la fiabilité affecte d’autres aspects de votre architecture, consultez Bonnes pratiques d’architecture pour Azure NetApp Files dans 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 de capacité qui hébergent des 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 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.

Outre les types de pannes transitoires pouvant affecter toute solution basée sur le cloud, les opérations de maintenance planifiées occasionnelles, telles que les mises à jour de la plateforme, les mises à jour des services et les mises à niveau logicielles, peuvent é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 SMB, ce qui permet le basculement transparent 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 la FAQ sur la résilience des applications pour Azure NetApp Files.

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 NetApp Files prend en charge les déploiements zonaux de volumes. Utilisez la fonctionnalité de placement de volume de 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 ressources de calcul Azure et d’autres services.

Dans le diagramme suivant, les flèches orange à pointe pleine représentent la manière dont toutes les machines virtuelles (VM) 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 la manière dont les machines virtuelles 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 positionnement du volume de zone de disponibilité Azure NetApp Files.

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.

Soutien régional

La réplication interzone est disponible dans toutes les régions prenant en charge la zone de disponibilité avec la prise en charge d’Azure NetApp Files.

Considérations

  • Le placement du volume de zone de disponibilité dans Azure NetApp Files fournit un placement de volume zonal. 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 est autorisée entre différents abonnements Azure à condition qu’ils se trouvent dans le même locataire Microsoft Entra.

  • Pour d’autres considérations relatives aux zones de disponibilité dans Azure NetApp Files, consultez Exigences et considérations relatives à l’utilisation de la réplication interzone et Gérer le placement des volumes de zone de disponibilité.

Coûts

L’activation du placement du volume de zone de disponibilité dans Azure NetApp Files n’entraîne aucun frais supplémentaire. 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.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce à quoi vous pouvez vous attendre lorsque plusieurs volumes Azure NetApp Files sont déployés dans des zones de disponibilité distinctes, que la réplication inter-zones 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.

  • Réplication des données entre les zones : La réplication interzone 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 à quoi il faut s'attendre lorsque plusieurs volumes Azure NetApp Files sont déployés dans des zones de disponibilité distinctes, que la réplication inter-zones est activée et qu'une zone de disponibilité est hors service.

  • 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 les 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 Gérer la reprise après sinistre à l’aide d’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 de haut niveau pour tester votre configuration de réplication interzone, consultez Tester la reprise après sinistre 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 en cas de panne régionale, Azure NetApp Files prend en charge la réplication interrégionale. Vous pouvez répliquer de manière asynchrone les données d'un volume Azure NetApp Files (la source) dans une région vers un autre volume Azure NetApp Files (la destination) dans une autre région présélectionnée par Microsoft. Cette fonctionnalité vous permet de basculer votre application critique en cas de panne ou d’incident touchant l’ensemble de la région.

Remarque

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 dans Azure NetApp Files.

Soutien régional

La région secondaire vers laquelle vous pouvez répliquer vos volumes dépend de la région principale. 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 à condition qu’ils se trouvent dans le même locataire Microsoft Entra.

Pour d'autres considérations relatives à la réplication interrégionale dans Azure NetApp Files, consultez Exigences et considérations relatives à l'utilisation de la réplication interrégionale..

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

Comportement lorsque toutes les régions sont saines

Cette section décrit ce à quoi vous pouvez vous attendre lorsque les volumes Azure NetApp Files sont configurés pour utiliser la réplication interrégionale et que 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.

  • Réplication des données entre les régions : La réplication interrégionale 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 à quoi s’attendre lorsque les volumes Azure NetApp Files sont configurés pour utiliser la réplication interrégionale activée et qu’une panne se produit dans la région principale.

  • 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 les métriques Azure Monitor. Azure Monitor détecte toutes les anomalies qui indiquent un scénario de région vers le bas 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 Gérer la reprise après sinistre à l’aide d’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 de haut niveau permettant de tester votre configuration de réplication interrégionale, consultez Tester la reprise après sinistre pour Azure NetApp Files..

Sauvegarde et restauration

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

Pour plus de sécurité, les instantanés Azure NetApp Files ajoutent stabilité, évolutivité et capacité de 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 les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit remplir pour atteindre cette disponibilité attendue. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Contenu connexe

  • Last updated on