Contexte #
Une entreprise qui souhaite mettre en place un Plan de Reprise d’Activité peut se poser la question de l’accessibilité de ses applications publiques. En effet, si un site marchand n’a plus de site web accessible publiquement, alors le plan de reprise d’activité n’atteint pas son but.
Dans le contexte de Nuabee avec OTC, nous proposons une approche DNS en deux phases :
- Phases de tests de PRA : nous mettons en place une méthode non-disruptive, afin que les clients ne soient pas impactés.
- Activation réelle : transition des clients de l’infrastructure sinistrée vers l’infrastructure redémarrée dans le cloud se fait de manière transparente.
Ces deux méthodes exploitent la même technologie : DNS.
Tests de PRA #
Principe : Délégation de sous-domaine
Le protocole DNS supporte une fonction appelé délégation de zone. En pratique, cela permet de déléguer la gestion d’un sous-domaine vers un tout autre serveur DNS.
Partant de ce principe, il est aisé pour l’entreprise de déléguer un sous domaine de type pra.entreprise.fr vers les serveurs DNS d’OTC. Les enregistrement à ajouter dans la zone DNS principale sont les suivants :
-
pra.entreprise.fr. IN NS ns1.open-telekom-cloud.com. -
pra.entreprise.fr. IN NS ns2.open-telekom-cloud.com.
Par la suite, Nuabee créé dans OTC une zone DNS pra.entreprise.fr.
Activation des tests de PRA
Lors de l’activation du PRA en test, Nuabee insère dans ce sous-domaine les différents enregistrements correspondants aux sites web de l’entreprise, en les faisant pointer vers le serveur redémarré dans le Cloud. L’arbre DNS résultant est le suivant :
Ainsi, pour tester le bon fonctionnement du site web redémarré, il suffit de visiter site.pra.entreprise.fr dans son navigateur pour être redirigé vers le nouveau serveur. Le site web d’origine, toujours disponible sur site.entreprise.fr, n’est jamais impacté.
Activation réelle du PRA #
Lors de l’activation réelle du PRA en cas de sinistre, la problématique est différente. En effet, les utilisateurs doivent pouvoir joindre les services de manière transparente. Dans ce cas, deux options se présentent.
Option 1 : Modification des enregistrements existants #
Principe : Mise à jour des enregistrements DNS dans la zone principale pour rediriger vers les nouvelles adresses IP.
Avantages :
- Contrôle total de la zone DNS
- Granularité fine des modifications
Inconvénients :
- Processus chronophage pour les zones complexes
- Risque d’erreurs proportionnel au nombre d’enregistrements
- Intervention manuelle extensive
Option 2 : Délégation complète de zone (Recommandée) #
Principe : Redirection de l’ensemble de la zone vers les serveurs DNS d’OTC via modification des enregistrements NS.
Configuration :
entreprise.fr. IN NS ns1.open-telekom-cloud.com.
entreprise.fr. IN NS ns2.open-telekom-cloud.com.Avantages :
- Rapidité d’exécution : Modification unique
- Préservation de la zone originale : Aucune altération des enregistrements source
- Simplicité opérationnelle : Réduction du risque d’erreur
Contraintes :
- Communication préalable à Nuabee pour toute modification DNS pendant la période d’activation
- Dépendance temporaire aux équipes Nuabee pour les changements DNS
Procédure de retour à la normale
Une fois le PRA terminé, restauration des NS originaux :
entreprise.fr. IN NS dns15.tvh.net.
entreprise.fr. IN NS ns15.tvh.net.Après propagation, la résolution DNS reprend son fonctionnement nominal.
Recommandations #
- Privilégier la délégation complète pour sa rapidité et sa fiabilité
- Anticiper les délais de propagation dans les procédures d’urgence
- Tester régulièrement les deux mécanismes pour valider leur efficacité
- Documenter les contacts d’urgence pour les modifications DNS critiques