Conception d'un DAG multi-sites pour un groupe franco-asiatique
Contoso Réseaux exploite Exchange 2016 pour 8 400 boîtes aux lettres réparties entre deux salles parisiennes (3 100 et 3 100 BAL) et un site de Singapour (2 200 BAL). Les deux salles parisiennes sont dans le même site Active Directory et reliées par 10 Gbit/s. Le lien Paris–Singapour affiche 45 ms de RTT, 30 Mbit/s utiles et subit des coupures de 20 à 90 minutes plusieurs fois par mois. La direction impose un RPO de zéro message perdu, un RTO de 30 minutes en cas de perte d'une salle parisienne, et une copie redondante de chaque base. Une copie retardée de 7 jours est exigée pour les bases parisiennes. Le parc compte 10 serveurs Mailbox (4/4 à Paris, 2 à Singapour) et 8 bases de 1 050 BAL. Aucun stockage partagé. Les sauvegardes sur bande dépassent la fenêtre de 8 heures. Le service réseau refuse d'ouvrir de nouveaux flux WAN et demande de justifier chaque flux avant toute modification.
1. Quelle topologie de DAG et quel emplacement de témoin retenez-vous pour tenir le RTO de 30 minutes sur la perte d'une salle parisienne ? Justifiez le calcul de quorum et précisez ce qui se passe si les deux salles parisiennes sont perdues.
Read the worked answer
La topologie actuelle compte 10 nœuds, donc un nombre pair : un témoin de partage de fichiers est obligatoire. Avec 10 nœuds et 1 témoin, le cluster a 11 votants et la majorité est de 6.
- Perte d'une salle parisienne (4 nœuds) : il reste 6 nœuds, soit exactement la majorité. Le DAG survit sans dépendre du témoin. Le RTO de 30 minutes est tenable si les bases ont une copie saine dans l'autre salle parisienne et si le basculement est automatisé.
- Perte des deux salles parisiennes (8 nœuds) : il ne reste que 2 nœuds à Singapour. Même avec le témoin, on obtient 3 voix sur 11, donc pas de majorité. Le DAG ne peut pas rester en ligne. Le RTO demandé ne couvre qu'une salle, mais il faut écrire noir sur blanc que la perte simultanée des deux salles parisiennes n'est pas couverte.
Le témoin doit être placé dans un troisième emplacement (site tertiaire ou machine Azure dédiée) et non dans une des salles parisiennes, sinon sa perte coïncide avec celle des nœuds. Activez le mode DAC pour éviter un split-brain entre Paris et Singapour.
Si le métier exige de survivre aux deux salles parisiennes, la conception 4/4/2 est insuffisante : il faut au moins 4 nœuds à Singapour, ou un troisième site portant des nœuds et le témoin, avec un quorum recalculé.
2. Dimensionnez les copies de bases et la copie retardée. Le lien Paris–Singapour ne peut pas être élargi : quelles précautions prenez-vous pour le seeding, le transport des logs et la capacité disque ?
Read the worked answer
Pour un RPO de zéro, chaque base doit avoir au moins deux copies actives en continu : une dans chaque salle parisienne, plus une copie à Singapour pour la résilience géographique. Soit trois copies par base, dont une seule active à la fois.
Le seeding initial ne doit jamais traverser le WAN de 30 Mbit/s : créez la copie à Singapour à partir d'une sauvegarde ou d'une copie locale exportée, puis reprenez la réplication des logs. Sinon, le seeding de 8 bases de 1 050 BAL sature le lien pendant des heures et retarde les logs des autres bases.
Pour les coupures de 20 à 90 minutes, calculez le volume de logs produit pendant 90 minutes et vérifiez qu'il tient dans la file du transport et dans l'espace disque de chaque serveur. Si le volume dépasse la capacité du lien après reprise, la copie Singapour prend du retard ; surveillez la file de logs et envisagez de ne répliquer à Singapour que les bases prioritaires, avec un RPO documenté différent.
La copie retardée de 7 jours doit être sur un volume distinct, avec un replay lag de 7 jours et un truncation lag suffisant pour conserver les logs au-delà du point de rejeu. Estimez le volume de logs sur 7 jours pour 8 bases : si le disque ne le permet pas, réduisez le nombre de bases couvertes ou la durée, mais ne réduisez pas le truncation lag sans accepté de perdre la possibilité de rejouer jusqu'au point avant corruption.
3. Concevez l'espace de noms et les certificats pour les utilisateurs de Paris et de Singapour. Faut-il un seul nom externe ou un nom par site ? Justifiez.
Read the worked answer
Un seul nom externe unique pour tout le groupe oblige les utilisateurs de Singapour à revenir sur le load balancer parisien pour MAPI/HTTP et Autodiscover, ce qui ajoute 45 ms à chaque connexion et crée une dépendance au WAN pour l'authentification. Ce n'est acceptable que si le métier privilégie la simplicité au prix de la latence.
Je retiens un espace de noms par site : mail.paris.contoso.fr et mail.singapore.contoso.fr, avec Autodiscover qui renvoie le nom du site de la boîte aux lettres. Les bases des utilisateurs de Singapour sont actives à Singapour ; leurs copies passives peuvent être à Paris. Ainsi, un utilisateur de Singapour ne traverse pas le WAN pour ouvrir Outlook.
Le certificat doit être un certificat public multi-domaines (SAN) contenant les deux noms de messagerie, autodiscover.contoso.fr, ainsi que les noms des serveurs si nécessaire. Un certificat unique par site est aussi possible, mais complique la gestion ; un SAN couvrant les deux sites est plus simple et reste valide après bascule.
Les load balancers de chaque site doivent être configurés sans affinité de session pour MAPI/HTTP et avec les sondes de santé appropriées. Le nom externe historique peut rester publié en DNS vers le site principal pour les clients nomades, mais les clients internes utilisent le nom de leur site.