Isoler un datacenter VoIP en journée, sans couper un appel

Un opérateur a deux datacenters. Un jour, il faut intervenir sur l'un des deux : un reboot de SBC, une montée de firmware, une maintenance de vingt minutes, en pleine journée, pendant que les clients téléphonent. Avant, cette opération n'existait pas. On attendait la fenêtre de 2h du matin, ou on prenait le risque de couper des appels.

J'ai construit le levier manquant avec n8n et le DNS. Une intervention de courte durée, en journée, sans qu'un seul client perde son appel.

Le problème : deux datacenters, une résolution partagée

Deux datacenters, DC-A et DC-B. Chacun présente le service Microsoft Teams Direct Routing avec un SBC d'accès, et les clients résolvent teams.example.net (plus un record <pbx_id>.teams.example.net par client) vers des A records qui pointent sur les deux DC. Sortir DC-A du service, c'est un cycle propre : arrêter les nouvelles sessions qui atterrissent dessus, laisser les appels en cours s'éteindre, intervenir, puis le remettre.

À la main dans la console DNS, record par record, sous la pression du temps, c'est comme ça qu'on coupe un client par erreur.

Pourquoi le DNS, et pas le SBC

Je suis API-first. Le levier auquel je fais confiance, c'est celui qui a une API propre, déterministe et réversible derrière. Le fournisseur DNS l'a. Manipuler le SBC directement, refuser les nouveaux appels sur DC-A côté équipement, je l'ai jugé moins fiable et plus intrusif.

Il y a aussi une question de responsabilité. La donnée sensible, et l'opération qui la manipule, je les veux chez un professionnel dont c'est le métier, sur une infrastructure mutualisée et durcie, pas sur un équipement non mutualisé qui n'a pas les bons réflexes. Le fournisseur DNS est fait pour ça. Le SBC, non.

Le drain se passe donc au niveau DNS. On retire l'IP de DC-A de la résolution. Les nouveaux appels partent sur DC-B. Les appels en cours continuent sur DC-A jusqu'à ce qu'ils raccrochent. C'est du connection draining, le geste qu'un load-balancer applique à une instance qu'on retire : couper le nouveau, laisser l'ancien finir. Un réseau anycast fait la même chose en retirant une route BGP. Moi, je le fais à la couche que je pilote par API, le DNS.

Le modèle tient en deux gestes : delete-by-content puis mirror-restore. Pour isoler, je ne touche pas les records par leur nom. Il y a l'apex, le wildcard, et un record par client. Je supprime tous les A dont le content est l'IP de DC-A. Pour restaurer, je ne rejoue pas un snapshot. Je recrée en miroir : pour chaque A qui pointe aujourd'hui vers DC-B, le survivant, j'ajoute le même nom vers DC-A.

Le mirror-restore est idempotent. Rejoué, il converge vers le même état, ce qui compte le jour où un restore se relance après un incident. Le prix est assumé : il fait confiance au DC survivant comme référence, donc il aligne DC-A sur l'état de DC-B, dérives comprises. Tant que les deux DC sont censés être symétriques, c'est exactement ce qu'on veut.

# Isoler : lister tous les A records qui pointent vers l'IP de DC-A
GET /client/v4/zones/{zone_id}/dns_records?type=A&content=<DC_A_IP>&per_page=1000
Authorization: Bearer $CF_TOKEN

# Puis, pour chaque record retourné, supprimer par son id
DELETE /client/v4/zones/{zone_id}/dns_records/{record_id}
Authorization: Bearer $CF_TOKEN

Le restore ne relit pas une sauvegarde. Il se calque sur le DC survivant :

// n8n Code Node - Restore : recréer les A de DC-A en miroir de DC-B
// Entrée : les A records qui pointent aujourd'hui vers l'IP survivante (DC-B).
const survivors = $input.all();
const dcAip = $('Normalize & Config').first().json.dc.public_ip; // IP de DC-A

return survivors.map((r) => ({
  json: {
    type: "A",
    name: r.json.name,   // même nom : apex, wildcard, <pbx_id>.teams...
    content: dcAip,      // on repointe ce nom vers DC-A
    ttl: 120,            // TTL bas permanent, cf. plus bas
    proxied: false,
  },
}));

Le drain, et la décision qui fait tiquer

Retirer l'IP arrête les nouvelles résolutions. Ça ne raccroche pas les appels déjà établis sur le SBC de DC-A. Avant d'intervenir, il me faut donc le nombre de sessions actives qui restent sur ce SBC. Le SBC expose un compteur d'appels actifs via RESTCONF. Le workflow le lit et me l'affiche.

// n8n - Helper "Get SBC Session Count" : compteur d'appels actifs d'un SBC.
// Le node HTTP est en onError=continue : un chemin RESTCONF faux
// dégrade en "indisponible", il ne casse jamais l'isolation.
const res = $input.first().json;
if (!res || res.error) {
  return [{ json: { ok: false, active_calls: null, reason: "SBC injoignable" } }];
}
// Parser le compteur exposé par le SBC (à adapter au modèle et à la version).
const active = Number(res?.callCountStatus?.activeCalls ?? 0);
return [{ json: { ok: true, active_calls: active } }];

Voici la décision qui fait tiquer un opérateur. Le workflow est report-only. Il m'affiche le compteur et me laisse juger : assez bas, j'y vais. Il ne bloque pas tant que le compteur n'est pas à zéro.

C'est volontaire, mais c'est une étape, pas un idéal. La cible, c'est un hard gate automatique qui draine jusqu'à zéro avant de basculer. Aujourd'hui, ce gate reste imaginé : il attend un vrai retour, interrogé sur un FQDN en live, la preuve que le signal de drain est fiable en production. Et il attend une deuxième chose, structurelle : que je maîtrise toutes les entrées de DC-A. La zone Teams est sous mon DNS managé. Les zones des trunks SIP ne le sont pas. DC-A continue donc de porter du trafic trunk après que j'ai retiré ses records Teams. Un gate « zéro session Teams » mentirait sur l'état réel du datacenter.

On ne gate pas sur un signal qu'on ne maîtrise pas de bout en bout. Le report-only est la posture honnête tant que toutes les entrées ne sont pas sous le même DNS et que le compteur n'est pas fiable partout.

Bloquer dur, ou seulement avertir

Deux garde-fous, deux postures.

Un blocage dur sur la double-isolation : si DC-A est déjà isolé, le workflow refuse d'isoler DC-B. Isoler les deux, c'est une panne auto-infligée, un état toujours faux. L'automate dit non, point.

Un simple warning, pas un blocage, quand j'isole le datacenter qui héberge l'unique cluster AS (Application Server). Retirer le SBC d'accès de ce DC ne protège pas l'AS, et le workflow ne peut pas isoler un AS qui n'a pas de jumeau. C'est une limite contextuelle, à peser contre le besoin de maintenance. L'automate prévient et me laisse décider.

Ma règle : bloquer dur les états qui sont toujours faux, avertir sur les limites qui dépendent du contexte.

Le vrai piège : le TTL

Le prérequis qui fait ou défait tout, c'est le TTL permanent. Un drain DNS ne va pas plus vite que le TTL ne l'autorise. À 3600 par défaut, retirer les records de DC-A laisse quand même les resolvers et les clients taper dessus pendant une heure. Le drain est inutile sur toute la durée de la maintenance.

Les records doivent donc rester à un TTL bas en permanence, autour de 120s, pas abaissés le matin même. J'ai posé 120s comme prérequis infra permanent, et le workflow recrée à 120 sur restore. Même là, le TTL est un plafond, pas une promesse : la RFC 8767 autorise un resolver à servir un record déjà expiré pour encaisser une panne, et les caches clients ne sont pas toujours polis. Le drain n'est donc jamais ni instantané ni total. Il faut prévoir quelques minutes de traîne, et ne jamais confondre « records retirés » avec « datacenter silencieux ».

Quand c'est le bon outil, quand c'est un piège

Le drain par DNS est le bon outil quand deux conditions sont réunies : une entrée centralisée, sous un seul DNS, et ce DNS piloté par API. Alors c'est déterministe et réversible, et ça ne coûte rien sur l'équipement lui-même.

C'est un piège quand tu as besoin d'un effet immédiat. Le délai de propagation, le TTL plus le cache resolver et client, fait qu'il y a toujours une latence avant que le DC devienne réellement silencieux. Si ton opération ne tolère pas cette latence, le DNS est le mauvais levier.

Il y a donc un périmètre à respecter. Le drain DNS vaut pour une intervention que le DC survivant absorbe et qui tolère une traîne de quelques minutes : un changement de config, un firmware sur une paire N+1. Ce n'est pas un substitut à une bascule dure pour une opération qui couperait les sessions encore établies. Pour celles-là, il faut le vrai zéro.

Ce qu'il en reste

Ce workflow transforme une capacité qui n'existait pas, intervenir en journée sur un datacenter vivant, en un formulaire à deux clics. La suite, c'est le hard gate drain-to-zéro. Ce n'est pas une question de code en plus : c'est le jour où toutes les entrées, Teams comme trunks, passeront sous le même DNS que je pilote, où « zéro session » deviendra un signal que je possède de bout en bout. D'ici là, le seul acteur qui voit ce que l'automate ne voit pas, c'est l'humain. Report-only plus jugement, c'est la version honnête, pas la version paresseuse.

Si tu exploites plus d'un datacenter et que tu attends encore la fenêtre de nuit, la pièce manquante n'est probablement pas plus d'infrastructure. C'est un DNS centralisé que tu peux piloter par API. La brique d'automatisation sous-jacente, je l'ai décrite dans mon article sur l'automatisation des opérations VoIP avec n8n.

Notes et sources

• Cloudflare, API DNS Records (list, create, delete par zone), documentation développeur.
• n8n, nodes HTTP Request et Code, gestion d'erreur onError.
• RFC 8767 (serve-stale) et RFC 1035, TTL et cache DNS : un resolver peut servir un record expiré, un drain n'est jamais instantané même sous le TTL.
• Connection draining et deregistration delay (couche load-balancer) : le même geste, couper le nouveau et laisser l'ancien finir, une couche au-dessus.

Une maintenance datacenter qui doit passer en journée, une bascule Teams Direct Routing à automatiser, un drain SBC à fiabiliser ? Prendre contact.