Fiabilité dans Azure DNS

Cet article contient des informations détaillées sur la prise en charge de la continuité d’activité et récupération d’urgence inter-région pour Azure DNS.

Récupération d’urgence et continuité d’activité inter-région

La récupération d’urgence (DR) consiste à récupérer après des évènements à fort impact, comme des catastrophes naturelles ou des échecs de déploiements, qui entraînent un temps d’arrêt et une perte de données. Quelle qu’en soit la cause, la meilleure solution en cas de sinistre est d’avoir un plan de DR bien défini et testé, et une conception d’application qui prend activement en charge la DR. Avant de commencer à réfléchir à la création de votre plan de récupération d’urgence, consultez Suggestions pour la conception d’une stratégie de récupération d’urgence.

En ce qui concerne la récupération d’urgence (DR), Microsoft utilise le modèle de responsabilité partagée. Dans un modèle de responsabilité partagée, Microsoft garantit que l’infrastructure de référence et les services de plateforme sont disponibles. En même temps, de nombreux services Azure ne répliquent pas automatiquement les données ou reviennent d’une région défaillante pour effectuer une réplication croisée vers une autre région activée. Pour ces services, vous êtes responsable de la configuration d’un plan de récupération d’urgence qui fonctionne pour votre charge de travail. La plupart des services qui s’exécutent sur des offres PaaS (Platform as a Service) Azure fournissent des fonctionnalités et des conseils pour prendre en charge la récupération d’urgence et vous pouvez utiliser fonctionnalités spécifiques au service pour prendre en charge la récupération rapide pour vous aider à développer votre plan de récupération d’urgence.

La solution de basculement Azure DNS pour la récupération d’urgence utilise le mécanisme DNS standard pour effectuer le basculement vers le site de secours. L’option manuelle via Azure DNS fonctionne de manière optimale lorsqu’elle est utilisée conjointement avec l’approche Reprise progressive ou Veilleuse.

Le serveur DNS étant situé en dehors de la zone de basculement ou d’incident, il est protégé d’un éventuel temps d’arrêt. Vous pouvez concevoir un scénario de basculement simple tant que l’opérateur dispose d’une connectivité réseau lors d’un sinistre et peut effectuer le basculement. Si la solution est basée sur un script, vous devez veiller à ce que le serveur ou service exécutant le script soit également isolé du problème affectant l’environnement de production. En outre, une durée de vie faible pour la zone empêche la mise en cache du résolveur sur de longues périodes, ce qui permet au client d’accéder au site dans les limites du RTO. Pour les méthodes Reprise progressive et Veilleuse, un préchauffage et une autre activité administrative pouvant être nécessaires, vous devez également prévoir suffisamment de temps pour effectuer le changement.

Remarque

La zone DNS privée Azure prend en charge la résolution DNS entre les réseaux virtuels de différentes régions Azure, même sans appairage explicite des réseaux virtuels. Cependant, tous les réseaux virtuels doivent être liés à la zone DNS privée.

Pour découvrir comment créer une zone DNS privée Azure à l’aide du portail Azure, consultez Démarrage rapide : Créer une zone DNS privée Azure à l’aide du portail Azure.

Pour créer un Azure DNS Private Resolver à l’aide du portail Azure, consultez Démarrage rapide : Créer un résolveur privé Azure DNS en utilisant le portail Azure.

Récupération d’urgence dans la zone géographique multi-région

Deux aspects techniques sont à prendre en considération lors de la configuration de votre architecture de récupération d’urgence :

• Utiliser un mécanisme de déploiement pour répliquer les instances, les données et les configurations entre les environnements primaire et de secours. Ce type de récupération d’urgence est possible en mode natif par le biais d’Azure Site Recovery voir la Documentation d’Azure Site Recovery via des appliances/services de partenaires Microsoft Azure comme Veritas ou NetApp.

• Développer une solution afin de transférer le trafic réseau/web du site principal vers le site de secours. Ce type de récupération d’urgence peut être mis en œuvre via Azure DNS, Azure Trafic Manager (DNS) ou des équilibreurs de charge globaux tiers.

Cet article est axé spécifiquement sur la planification de la récupération d’urgence Azure DNS.

Configurer la reprise d’activité et la détection des pannes

La solution de basculement manuel Azure DNS pour la récupération d’urgence utilise le mécanisme DNS standard pour effectuer le basculement vers le site de sauvegarde. L’option manuelle via Azure DNS fonctionne de manière optimale lorsqu’elle est utilisée conjointement avec l’approche Reprise progressive ou Veilleuse.

Figure - Basculement manuel à l’aide d’Azure DNS

Les hypothèses formulées pour la solution sont :

• Les points de terminaison principal et secondaire ont des adresses IP statiques qui ne changent pas souvent. Par exemple, l’adresse IP du site principal est 100.168.124.44 et celle du site secondaire 100.168.124.43.
• Il existe une zone Azure DNS pour le site principal et pour le site secondaire. Par exemple, le point de terminaison pour le site principal est prod.contoso.com et pour le site de sauvegarde dr.contoso.com. Il existe également un enregistrement DNS pour l’application principale appelé www.contoso.com.
• La durée de vie est égale ou inférieure à la valeur RTO du SLA définie dans l’organisation. Par exemple, si une entreprise définit le RTO de réponse à l’incident de l’application sur 60 minutes, la durée de vie doit être inférieure à 60 minutes, de préférence la plus faible valeur possible. Vous pouvez configurer Azure DNS de la façon suivante pour le basculement manuel :
  • Création d’une zone DNS
  • Création d’enregistrements de zone DNS
  • Mise à jour de l’enregistrement CNAME

1. Procédez comme suit pour créer une zone DNS (par exemple, www.contoso.com) :

   

   Figure - Création d’une zone DNS dans Azure

2. Dans cette zone, créez trois enregistrements (par exemple, www.contoso.com, prod.contoso.com et dr.consoto.com), comme illustré ci-dessous.

   

   Figure - Création d’enregistrements de zone DNS dans Azure

   Dans ce scénario, le site www.contoso.com a une durée de vie de 30 minutes, ce qui est bien inférieur au RTO annoncé, et pointe vers le site de production prod.contoso.com. Cette configuration est vraie pour les opérations commerciales normales. La durée de vie de prod.contoso.com et de dr.contoso.com a été définie sur 300 secondes soit 5 minutes. Vous pouvez utiliser un service de surveillance Azure, tel que Azure Monitor ou Azure App Insights, ou toute solution de surveillance partenaire telle que Dynatrace. Vous pouvez même utiliser vos propres solutions capables de surveiller ou détecter les défaillances des applications ou de l’infrastructure virtuelle.

3. Une fois la défaillance détectée, modifiez la valeur de l’enregistrement pour qu’elle pointe vers dr.contoso.com, comme illustré ci-dessous :

   

   Figure - Mise à jour de l’enregistrement CNAME dans Azure

   Dans les 30 minutes, pendant lesquelles la plupart des programmes de résolution vont actualiser le fichier de zone mis en cache, toute demande sur www.contoso.com sera redirigée vers dr.contoso.com. Vous pouvez également exécuter la commande d’interface de ligne de commande Azure suivante pour modifier la valeur CNAME :

     az network dns record-set cname set-record \
     --resource-group 123 \
     --zone-name contoso.com \
     --record-set-name www \
     --cname dr.contoso.com
   

   Cette étape peut être exécutée manuellement ou de manière automatique. Elle peut être effectuée manuellement via la console ou par l’interface de ligne de commande Azure. Le Kit de développement logiciel (SDK) et l’API Azure peuvent être utilisés pour automatiser la mise à jour du CNAME de sorte qu’aucune intervention manuelle ne soit nécessaire. L’automatisation peut être créée à l’aide de fonctions Azure ou au sein d’une application de supervision tierce, ou même localement.

Étapes suivantes

• Fiabilité dans Azure
• En savoir plus sur Azure Traffic Manager.
• En savoir plus sur Azure DNS