Fiabilité dans les zones privées Azure DNS

Les zones DNS privées Azure offrent une résolution de noms sécurisée au sein des réseaux virtuels Azure. Vous pouvez étendre des zones DNS privées à un ou plusieurs réseaux virtuels, et les organisations les utilisent généralement pour les applications internes. Les noms d’hôte que vous résolvez sont des noms DNS locaux qui ne sont pas accessibles publiquement via Internet. Les adresses IP résolues sont souvent des adresses IP privées qui ne sont pas accessibles à partir d’Internet. Azure DNS est un service global qui n'est lié à aucune zone de disponibilité spécifique ou à une seule région.

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

Cet article explique comment rendre Azure DNS zones privées résilientes à diverses pannes et problèmes potentiels, notamment les erreurs temporaires et les défaillances à l’échelle de la région. Il fournit également des informations clés sur le contrat de niveau de service (SLA) des zones privées Azure DNS.

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de suivre ces recommandations :

Vue d’ensemble de l’architecture de fiabilité

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

Architecture logique

La ressource principale que vous déployez est une zone, qui représente un ensemble d’enregistrements DNS qui mappent les noms d’hôte (noms de domaine) aux adresses IP. Les noms d’hôte résolus par la zone sont généralement des noms DNS locaux qui ne sont pas accessibles publiquement via Internet.

Vous créez des zones DNS privées en tant que ressources autonomes et les liez à des réseaux virtuels spécifiques en créant des liens de réseau virtuel. Lorsque les requêtes DNS proviennent de clients au sein de ces réseaux virtuels, les zones DNS privées participent au processus de résolution. Vous pouvez créer manuellement des entrées dans une zone DNS ou configurer l’inscription automatique de machines virtuelles sur des liens de réseau virtuel. Les zones DNS privées Azure prennent en charge la résolution DNS entre des réseaux virtuels situés dans différentes régions Azure, même sans établir explicitement un peering entre les réseaux virtuels. Cependant, tous les réseaux virtuels doivent être liés à la zone DNS privée.

Le processus de résolution de noms DNS implique plusieurs composants, notamment les résolveurs DNS et les couches intermédiaires qui traitent les demandes avant d’atteindre les serveurs DNS faisant autorité. Les zones privées utilisent les mêmes protocoles et comportements DNS que les zones publiques, notamment les valeurs de durée de vie et les mécanismes de mise en cache.

Architecture physique

Azure DNS est un service non régional. Microsoft déploie son infrastructure dans plusieurs zones de disponibilité dans plusieurs régions Azure dans le monde entier. Cette conception permet aux Azure DNS de rester résilientes lors d’une panne de zone de disponibilité ou de région, car l’infrastructure d’une autre zone ou région continue de répondre aux demandes de résolution.

Les protocoles Internet globaux tels que Anycast, DNS et Border Gateway Protocol (BGP) routent automatiquement les requêtes de résolution DNS entrantes vers l’infrastructure Azure DNS saine la plus proche.

Résilience aux erreurs temporaires

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

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

Azure DNS gère les erreurs temporaires via son infrastructure DNS globale.

Si une erreur temporaire se produit pendant la résolution DNS, le client ou le programme de résolution intermédiaire doit réessayer la requête. Configurez les valeurs de délai d’expiration de manière appropriée. Un délai d’expiration de 2 à 5 secondes est généralement suffisant pour un client DNS.

Le temps de vie de chaque enregistrement DNS affecte également la façon dont votre solution gère les erreurs. Si le TTL est très bas, les clients adressent davantage de requêtes à Azure DNS, ce qui augmente le risque d’erreurs transitoires. Si le TTL est très élevé, en cas de panne réelle d’un serveur back-end nécessitant de rediriger le trafic vers une autre adresse IP, les clients risquent de subir un retard de basculement jusqu’à l’expiration du TTL. Configurez soigneusement les TTL pour équilibrer la disponibilité, la latence et la réactivité.

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 DNS fonctionne en tant que service non régional. Microsoft distribue son infrastructure entre plusieurs zones de disponibilité dans plusieurs régions Azure et réplique les modifications apportées à vos zones DNS privées dans cette infrastructure. Vous ne sélectionnez pas de zones de disponibilité ni ne configurez la redondance de zone. Pendant une panne de zone de disponibilité, l’infrastructure d’une autre zone ou région continue de répondre aux demandes de résolution.

Si une ressource que vous déployez sur une seule zone de disponibilité, telle qu'une machine virtuelle, devient indisponible pendant une défaillance de zone, Azure DNS continue de retourner l'adresse IP configurée de la ressource, car elle ne surveille pas l'intégrité du point de terminaison. Si vous basculez vers une ressource dans une zone saine, vous êtes responsable de la mise à jour de l’enregistrement DNS afin que les clients utilisent la ressource saine. Vous pouvez également placer les ressources derrière un équilibreur de charge redondant interzone qui dirige le trafic vers des machines virtuelles dans des zones saines.

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

Azure DNS zones privées sont résilientes aux pannes de région, car les données de zone sont disponibles globalement. Si une région a une panne, ses réseaux virtuels et ses ressources, comme les machines virtuelles, peuvent être indisponibles, mais la résolution de noms continue de fonctionner.

L’exemple suivant montre comment les données de zone privée restent disponibles dans plusieurs régions. La zone azure.contoso.com privée est liée aux réseaux virtuels dans trois régions : la région A, la région B et la région C. L’inscription automatique est activée dans les régions A et B. Le diagramme montre la région A qui rencontre une panne :

Supposons qu’une panne temporaire se produit dans la région A. Les machines virtuelles des régions B et C peuvent toujours interroger des noms DNS dans la zone privée, y compris les noms qui sont enregistrés automatiquement à partir de la région A. Ils peuvent continuer à résoudre l’adresse IP de VM1 dans la région A, même si VM1 n’est pas disponible. L’interruption de service dans la région A n’affecte pas la résolution de noms dans les autres régions.

L’exemple précédent n’affiche pas de scénario de récupération d’urgence dans lequel votre solution bascule vers un remplacement de VM1 dans une autre région. Toutefois, étant donné que les zones privées sont globales, vous pouvez recréer VM1 dans le réseau virtuel d’une autre région pour prendre en charge la charge de travail.

Si vous créez des réseaux virtuels et des ressources réseau dans plusieurs régions, vous devez planifier et implémenter votre stratégie de multirégion pour les applications nécessitant un basculement interrégion.

Résilience aux menaces de sécurité et à la mauvaise configuration

Les attaques de sécurité et les erreurs de configuration sont deux des risques de fiabilité les plus importants pour les zones DNS. Plusieurs types d’attaques visent spécifiquement la résolution DNS, et une erreur de configuration accidentelle peut perturber vos charges de travail tout aussi gravement.

Pour obtenir des conseils de sécurité complets spécifiques aux zones DNS privées, consultez Protection des zones et enregistrements DNS privés.

Résilience aux pannes de service

Azure DNS est un service hautement résilient, avec un contrat SLA de disponibilité de 100% lorsque votre application répond à certaines conditions. Les pannes de service sont extrêmement inhabituelles, mais le réseau ou d’autres problèmes d’infrastructure peuvent perturber la connectivité au service Azure DNS.

Surveiller les pannes de service

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

Tester les pannes de service

Azure Chaos Studio fournit un ensemble d’erreurs pour simuler des problèmes avec la résolution DNS. Par exemple, l’agent Chaos Studio fournit le type d’erreur d’échec DNS et Azure Kubernetes Service (AKS) Chaos Mesh fournit la fonctionnalité Chaos DNS. Vous pouvez utiliser ces types d’erreurs pour tester la façon dont vos applications et votre infrastructure répondent lorsque les demandes de résolution DNS échouent, ce qui peut se produire lors d’une défaillance réseau partielle.

Résilience aux pannes des outils de gestion et du portail

Si vous gérez votre zone DNS dans le portail Azure, préparez-vous aux scénarios où vous ne pouvez pas y accéder, en particulier si vous devez reconfigurer votre zone DNS lors d'une panne de plateforme.

Vous pouvez utiliser différents outils pour déployer et gérer Azure DNS zones privées. Découvrez comment utiliser Azure CLI ou Azure PowerShell pour gérer votre zone privée. Vous pouvez également utiliser l’infrastructure en tant que code (IaC), comme Bicep ou Terraform, pour déployer et configurer votre zone privée. Ces outils restent opérationnels même si le portail Azure est détérioré.

Sauvegarde et restauration

Azure DNS est un service sans état. Il ne fournit pas de sauvegardes managées ni de restauration à un point dans le temps pour les zones DNS privées.

Pour conserver la configuration complète des ressources Azure, définissez vos zones DNS privées à l’aide d’IaC, telles que Bicep ou Terraform, et stockez les définitions dans le contrôle de code source. Testez régulièrement les définitions pour pouvoir les utiliser pour redéployer votre configuration.

Résilience à la maintenance du service

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

Contrat de niveau de service

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 respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Azure DNS fournit un contrat SLA de disponibilité de 100% pour les réponses de requête DNS valides lorsque vous remplissez certaines conditions. Ces conditions incluent le fait de réessayer les requêtes ayant échoué pendant au moins 60 secondes consécutives. Passez en revue le document SLA pour connaître les conditions détaillées.

Contenu connexe

• Documentation sur les zones Azure DNS privées
• FAQ sur Azure DNS
• Protection des zones et enregistrements DNS privés - Azure DNS
• fiabilité des zones publiques Azure DNS