Aller au contenu

AWS Mis à jour le 2026-07-04

Du local vers AWS : fermer la salle de serveurs sans désastre de fin de semaine

Une migration vers AWS depuis le local échoue sur ce qui entoure les serveurs — AD, DNS, partages de fichiers, VPN, le calcul de bande passante. Voici comment fermer la salle de serveurs dans le bon ordre.

Une migration du local vers AWS échoue rarement sur les serveurs — elle échoue sur tout ce qui est branché autour : Active Directory, le DNS, les partages de fichiers, les tâches de sauvegarde, le pare-feu du bureau, et l’hypothèse que le réseau entre le bureau et le nuage se comportera comme un réseau local. Fermer une salle de serveurs sans dégâts, c’est déménager la plomberie d’abord, les charges de travail ensuite, et la couche d’identité avec un soin extrême, pendant que la vieille salle reste allumée comme plan de retour arrière jusqu’à ce que le nouvel environnement ait survécu à un cycle d’affaires complet.

Ce qui se passe

Une salle de serveurs n’est pas une liste de serveurs; c’est un graphe de dépendances à trois couches. En bas, la plomberie : la résolution DNS, le DHCP, le NTP, le pare-feu, la connectivité site à site dont vous vous apprêtez à dépendre. Au milieu, l’identité : Active Directory ou ce qui authentifie les personnes et les machines. Au-dessus, les charges de travail dont tout le monde parle — l’ERP, le serveur de fichiers, les applications métier. Les migrations qui tournent au désastre de fin de semaine ont presque toujours déménagé la couche trois pendant que les couches un et deux étaient encore à moitié locales, à moitié dans AWS, et discrètement incohérentes.

L’autre force en jeu, c’est la physique. Au bureau, le serveur d’application et le serveur de fichiers se parlaient avec une latence sous la milliseconde sur de l’Ethernet gigabit. Après la migration, chaque utilisateur du bureau atteint ces charges à travers un VPN ou un lien Direct Connect avec 10 à 40 ms de latence et une fraction de la bande passante. Les protocoles bavards — les partages SMB avant tout — se dégradent bien plus que les chiffres bruts le laissent croire. C’est pourquoi la conception réseau et le plan d’amorçage des données méritent autant d’attention que la réplication des serveurs, et pourquoi la copie initiale de téraoctets de fichiers se fait parfois mieux par transfert hors ligne (AWS offre la famille Snow exactement pour ça) que par le lien montant du bureau.

Quoi vérifier en premier

  • Le calcul du lien montant. Le volume total de données à déplacer, divisé par la bande passante montante réellement utilisable, multiplié par un facteur de sécurité de deux. Si la réponse se mesure en semaines, planifiez des transferts amorcés ou un appareil hors ligne dès maintenant.
  • Ce que la salle fait à part héberger des applications. DHCP, services d’impression, systèmes de cartes d’accès, téléphonie, stockage de caméras — les services que personne ne liste parce que personne ne les voit comme des serveurs.
  • Les dépendances d’identité. Ce qui casse si AD est injoignable pendant une heure : ouvertures de session, ACL des partages, comptes de service dans les applications.
  • Les adresses codées en dur. Les numériseurs qui envoient des courriels via une IP fixe, les applications configurées avec 192.168.x.x au lieu de noms d’hôtes. Chacune est une surprise du jour de bascule.
  • Le plan de connectivité. Un VPN site à site suffit pour la plupart des petits parcs; un trafic sensible à la latence ou volumineux peut justifier Direct Connect. Décidez avant, pas après, que les utilisateurs se plaignent.

Comment vérifier

Avant toute bascule, prouvez que la plomberie fonctionne des deux côtés du lien :

# Depuis une machine du bureau : le tunnel rejoint-il le VPC, et à quelle latence?
ping -c 20 10.20.1.10
traceroute 10.20.1.10

# Depuis AWS : le VPN est-il actif, et les routes se propagent-elles?
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[].[VpnConnectionId,State,VgwTelemetry[].Status]'

# Le DNS résout-il de façon cohérente des deux côtés?
dig app01.corp.example.com @10.20.0.2       # résolveur côté AWS
dig app01.corp.example.com @192.168.1.5     # contrôleur de domaine local

Mesurez le débit réel à travers le tunnel avec une grosse copie de test et chronométrez-la — un transfert de 10 Go qui prend une heure vous dit que votre partage de fichiers de 4 To a besoin d’un autre plan. Dans la console, VPC > Site-to-Site VPN Connections montre l’état des tunnels par point de terminaison; deux tunnels actifs, c’est la base, un seul tunnel actif, c’est un compte à rebours. Pour les fichiers déplacés avec DataSync, DataSync > Tasks montre le débit et les résultats de vérification par tâche.

Le plan d’exécution

  1. Monter la connectivité et le DNS d’abord. VPN site à site (ou Direct Connect), routage dans les deux sens, et transfert DNS conditionnel pour que les machines du bureau résolvent les noms hébergés dans AWS et que les instances AWS résolvent les noms locaux. Rien d’autre ne bouge tant que ce n’est pas ennuyant.
  2. Étendre l’identité avant de la déménager. Pour Active Directory, bâtissez de nouveaux contrôleurs de domaine sur EC2 dans une vraie disposition multi-AZ (voyez la conception de sous-réseaux multi-AZ), laissez la réplication se stabiliser, et mettez à jour Sites and Services pour que les clients trouvent le contrôleur le plus proche. Le dernier contrôleur quitte l’édifice à la fin du projet, pas au début.
  3. Amorcer les données volumineuses tôt. Partages de fichiers, archives, historique de sauvegardes. Utilisez DataSync sur le lien pour ce qui passe, un transfert hors ligne pour ce qui ne passe pas, puis laissez les synchronisations incrémentales garder la copie à jour pendant que vous avancez dans les vagues applicatives.
  4. Déménager les charges en ordre de dépendance. Les bases de données avec ou avant leurs applications, les services partagés avant leurs consommateurs — la même logique de vagues que tout cahier d’exécution de migration de serveurs, avec un ajout : après chaque vague, retestez depuis le bureau, parce que le chemin bureau-AWS fait maintenant partie de chaque transaction.
  5. Basculer les points d’entrée des utilisateurs en dernier. Repointez le DNS, l’accès à distance et l’impression une fois les charges derrière eux stabilisées. TTL abaissés et retour arrière écrit par enregistrement.
  6. Vivre la période de rodage. Gardez la salle de serveurs allumée mais inactive au moins jusqu’à une fin de mois. Les problèmes qui survivent à la première semaine sont les problèmes planifiés.
  7. Décommissionner méthodiquement. Sauvegardes finales archivées dans AWS (interrégion si les données le justifient), licences récupérées, disques effacés avec preuve de destruction, et l’espace en armoire, le contrat de climatisation et l’entretien de l’onduleur réellement annulés — les économies promises vivent dans cette dernière étape.

Quand c’est la mauvaise approche

Si la connectivité Internet du bureau se résume à un seul lien grand public, tout déménager dans AWS fait de ce lien un point de défaillance unique pour toute l’entreprise — réglez la connectivité d’abord ou gardez les services critiques en latence sur place. Les charges qui dépendent de matériel local (contrôleurs de plancher de production, systèmes de portes, caméras qui écrivent de la vidéo en continu) devraient généralement rester sur une petite empreinte locale. Et si le parc est surtout du service de fichiers Windows pour une équipe qui pourrait vivre dans une plateforme documentaire, le SaaS ferme la salle de serveurs à meilleur prix qu’EC2.

Erreurs fréquentes

  • Déménager les applications avant la plomberie. La moitié du parc dans AWS, un DNS incohérent et l’authentification qui traverse le WAN à chaque ouverture de session — le mode de défaillance « tout est lent » que les utilisateurs résument par « le nuage est lent ».
  • Traiter le serveur de fichiers comme un serveur ordinaire. Du SMB à travers 30 ms de latence, c’est un autre produit. Testez-le avec de vrais utilisateurs avant la bascule, et considérez un service de fichiers géré ou une stratégie de cache plutôt qu’un serveur de fichiers déménagé tel quel.
  • Reporter l’histoire des sauvegardes à après. La vieille salle avait ses sauvegardes; le nouvel environnement a besoin des siennes, validées par une vraie restauration, avant d’éteindre les anciennes tâches.
  • Décommissionner sur une bonne nouvelle. La première semaine se passe bien, le matériel est effacé, et la tâche de paie de fin de mois qui roulait sur une tâche planifiée oubliée refait surface au jour 30, sans retour arrière possible.

Prévention

  • Maintenez une seule carte de dépendances — plomberie, identité, charges de travail — et annotez-la à mesure que chaque pièce déménage; c’est le document qui empêche les dépendances orphelines.
  • Définissez « terminé » par charge de travail comme testé depuis le réseau du bureau, pas seulement en marche dans AWS.
  • Surveillez le lien VPN ou Direct Connect comme la dépendance de production qu’il est devenu : état des tunnels, débit, alarmes de latence.
  • Planifiez la période de rodage pour inclure la fin de mois et tout pic saisonnier avant la disposition du matériel.
  • Rédigez la liste de décommissionnement au début du projet, quand les gens se souviennent encore de ce que la salle contient.

La salle de serveurs est fermée le jour où la dernière tâche planifiée a roulé correctement depuis AWS à travers un cycle d’affaires complet — pas le jour où les serveurs démarrent dans le nuage. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.