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 solution en deux temps :
- Lors des tests de PRA, nous mettons en place une méthode non-disruptive, afin que les clients ne soient pas impactés.
- Lors de l’activation réelle de PRA, la transition des clients de l’infrastructure en sinistre 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 #
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.
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 #
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.
Modification des enregistrements de la zone principale #
L’entreprise modifie les enregistrements DNS de sa propre zone pour rediriger vers les nouvelles adresses IP des services
- Cette méthode permet à l’entreprise de garder le contrôle sur l’intégralité de sa zone mais implique des modifications importantes, et si cette dernière a un grand nombre d’enregistrement, la modification peut être longue et créer des erreurs.
Délégation de toute la zone principale vers OTC #
L’entreprise modifie les enregistrements NS de sa zone pour la déléguer en entier sur le serveur DNS d’OTC
- Cette méthode est plus rapide du point de vue de l’entreprise, il suffit de modifier les NS comme suit :
entreprise.fr. IN NS ns1.open-telekom-cloud.com.
entreprise.fr. IN NS ns2.open-telekom-cloud.com.
Une fois cette modification faite, les requêtes des utilisateurs vers les sous domaines de entreprise.fr seront redirigés vers les serveurs DNS d’OTC. De là, les autres sous-domaines et enregistrements seront servis normalement.
Cette méthode est préférable car elle est moins destructive sur la zone d’origine, mais elle implique de communiquer à Nuabee si des changements d’enregistrement DNS doivent intervenir pendant la durée de l’activation du PRA.
Une fois le PRA terminé, l’entreprise remplace les NS OTC par ceux d’origine, par exemple pour le registrar OVH :
entreprise.fr. IN NS dns15.ovh.net.
entreprise.fr. IN NS ns15.ovh.net.
Après la durée de propagation, les réponses DNS seront de nouveau issues de la zone d’origine.