Déménagement d’un datacenter

Quelle que soit la situation, une difficulté technique majeure apparaît.
Comment maintenir la production et migrer les données avec un minimum de contraintes ?
L’enjeu concerne autant les équipes d’exploitation que les clients. Et il faut éviter toute modification dans les configurations des applications.

Cas d’usage

Un grand acteur de l’hébergement en France a choisi de rationaliser ses infrastructures. Son objectif était de consolider puis de démanteler un petit datacenter edge au profit de sites plus importants.

Ce datacenter hébergeait une grande quantité de données et des applications critiques. Pour ces dernières, tout arrêt de production était presque impossible à envisager.

Le but de l’opération était de concevoir une architecture capable de migrer les données en toute sécurité. Elle devait aussi préserver les adresses IP privées et publiques entre les sites. Enfin, l’objectif était de réduire au minimum les interventions techniques.

Pour des raisons de confidentialité, toutes les informations de cet article sont fictives.
Seuls les concepts techniques et les notions génériques réseau ont été conservés pour illustrer le sujet.

Contexte technique

Les deux datacenters sont équipés de technologies Cisco (Nexus, Catalyst et ASR). Pour simplifier, nous les appellerons DC A et DC B. Tous deux sont LIR et possèdent leurs propres préfixes IP, ASn et transitaires Internet.

La distance entre eux reste raisonnable. Le projet n’imposait aucune contrainte particulière de latence. Nous avons donc pu exploiter les technologies disponibles pour concevoir une architecture de transition adaptée.

Cahier des charges

Le projet devait répondre à plusieurs contraintes clés :

• Préserver les configurations existantes : adresses IP (publiques et privées) ainsi que les identifiants VLAN.
• Permettre une migration progressive : les workloads devaient pouvoir être déplacés au fil de l’eau, avec un fonctionnement en mode multi-sites pendant la transition.
• Simplicité opérationnelle : les manipulations réseau devaient rester accessibles à un administrateur non expert en infrastructures multi-sites.
• Temps d’arrêt minimal : la continuité de service devait être assurée avec un down time très réduit.
• Redéfinition du point de transit Internet : le datacenter B devait devenir le transit principal, afin de permettre la résiliation des abonnements sur le datacenter A.
• Gestion des ressources RIPE : les ressources devaient être transférées vers l’organisation LIR du datacenter A.

Première étape: connecter les deux sites

La première action a consisté à relier les deux datacenters par deux liaisons Lan-to-Lan distinctes, chacune empruntant un parcours différent. Ces liens devaient supporter à la fois l’encapsulation VLAN et le passage des trames LACP.

Pour répondre à ces exigences, l’opérateur d’infrastructures Covage a été retenu, offrant les garanties nécessaires en termes de qualité et de résilience.

Deuxième étape: échanger les prefix IP publics

La préservation des VLANs et des segments IP internes est la plupart du temps relativement simple à mettre en œuvre. En revanche, le véritable enjeu résidait dans la migration des adresses IP publiques avec leurs workloads, tout en garantissant la continuité du routage entre deux ASn distincts.

Pour répondre à cette problématique, le choix s’est naturellement porté sur le protocole de routage BGP, parfaitement adapté à ce type de topologie multi-sites.

Les deux AS échangent désormais leurs préfixes respectifs à travers les deux liaisons Lan-to-Lan.
Les routeurs du datacenter B annoncent une full table aux routeurs du datacenter A, tandis que ce dernier diffuse son préfixe X/22 vers Internet via le datacenter B.
À partir de ce moment, DC B est devenu le fournisseur principal de transit IP pour le datacenter A.

Ensuite, à chaque migration de workload, une route /32 est créée dans le backbone du datacenter B. Grâce au principe de sélection des routes les plus spécifiques, les routeurs des deux datacenters peuvent ainsi aiguiller le trafic directement vers la bonne cible.

Le datacenter B est également configuré pour agréger les préfixes X/32 en un /22, en prévision du démantèlement de DC A.
Cette approche permet d’annoncer directement le /22 sur Internet, sans interruption de service.

Cependant, un inconvénient apparaît : la commande d’agrégation génère automatiquement une route Null0 pour le préfixe concerné, avec un poids par défaut de 32768. Cela aurait pour effet d’écraser le /22 déjà annoncé par DC A.

La solution consiste à ajuster le poids de la route annoncée par DC A (par exemple en le fixant à 40000). Ainsi, l’agrégation ne prendra le relais que lorsque les routeurs de DC A seront arrêtés, garantissant une bascule transparente.

Conclusion

Cette topologie a permis à l’hébergeur de déménager simplement l’ensemble de ses serveurs d’une infrastructure à une autre, tout en préservant aussi bien les adresses IP privées que publiques.

Un atout majeur pour les équipes techniques lors d’un déménagement d’un datacenter: éviter d’avoir à modifier les configurations sensibles (pare-feu, VPN, enregistrements DNS), des changements qui peuvent avoir des impacts considérables lors d’une migration.

Contactez nous