Nulle part est un lieu : déménager entre sites

Déplacer un serveur d’une baie à une autre dans le même bâtiment est un acte physique unique avec une seule incertitude : y est-il ? Nous avons modélisé cela il y a quelque temps, et l’intéressant s’est révélé être l’instant où la destination n’est ni réservée ni occupée.

Emmener un serveur dans une autre ville n’est pas le même problème dans un manteau plus grand. C’est une suite d’actes en deux endroits, avec un intervalle pendant lequel la machine n’est dans aucun centre de données, plus un côté réseau, un côté adressage et un côté agent qui doivent redevenir vrais à l’autre bout. La tentation est de réutiliser le déplacement existant et de laisser tomber la contrainte qui force l’origine et la destination sur le même site. Nous ne l’avons pas fait, et voici pourquoi.

Pourquoi c’est un second objet et non un drapeau

Le déplacement existant possède déjà une origine, une destination, une vérification préalable figée, une réservation à destination, un compteur de comparaison et une trace qui ne fait qu’ajouter. Ce qui semble manquer, c’est une seule contrainte de base de données.

Ajouter un drapeau fusionnerait deux automates en un seul qui ne convient à aucun des deux. Un déplacement à l’intérieur d’un site a neuf états ; un déménagement entre sites en a quinze. Le premier a deux sorties du « nous ne savons pas », le second en a trois, et cette troisième est que la machine a été perdue en route, ce qui ne peut pas arriver entre deux baies de la même salle. Et retirer la contrainte laisserait tout déplacement existant, y compris un planifié la semaine dernière, franchir en silence la frontière de site.

Ce qui est partagé, c’est tout ce qui est réellement identique : la même primitive d’occupation avec son index unique partiel, le même historique d’emplacement en ajout seul et la même couture d’opération faite de démarrer, avancer et clore. Les sortes d’entrées de trace sont distinctes, afin qu’un lecteur puisse voir dans un an si une machine a glissé dans une salle ou si elle a passé un après-midi dans une camionnette. Une entrée commune « déplacée » effacerait cette différence pour toujours.

Quinze états, et l’un d’eux est nulle part

Trois états administratifs avant que rien de physique n’arrive (brouillon, planifié, approuvé), neuf phases de travail réel et trois états finaux. Les phases sont : extinction, démontage, transport, arrivée à destination, montage, recâblage, nouvelle mesure, vérification et l’état où personne ne sait.

L’état qui porte toute la conception est in_transit. C’est le seul état en cours dans lequel le site de la machine est véritablement vide, et le code écrit ce vide au lieu de le décrire : la colonne de site devient réellement vide. Sur un site, vide signifie d’ordinaire « non établi », et ici cela signifie quelque chose de plus fort et de plus littéral. Il n’existe aucun centre de données où elle se trouve. Elle est sur la route.

Ses voisins ne le sont pas, et c’est volontaire. unracked veut dire hors de la baie mais encore dans le bâtiment, sur un chariot ; le site reste donc l’origine. destination_claimed veut dire parvenue à l’autre bout mais pas encore en baie, et à partir de là elle appartient administrativement au site de destination. Deux frontières séparées d’une heure, et les fusionner rendrait fausse, pour l’une des deux, la réponse à « où est la machine 41 en ce moment ».

À partir de l’extinction, il n’y a pas de retour

Les transitions forment une table sur les quinze états et non un aiguillage, pour la même raison que partout dans cette base de code : un aiguillage avec branche par défaut transforme un état nouvellement ajouté en état autorisé, et un état que quelqu’un ajoute parce qu’il se passe quelque chose d’inhabituel serait le premier à avoir tous les droits.

La ligne qui compte quitte approved. Jusque-là inclus, un déménagement peut être annulé et il n’est rien arrivé à personne. À partir de shutting_down, l’annulation disparaît. Quelqu’un a commencé à démonter un service en marche chez un client ; une mise à jour en base ne défait pas cela, et prétendre le contraire est une affirmation sur le monde physique que personne n’a vérifiée.

Ce qui reste depuis chaque phase physique, c’est la phase suivante, le « nous ne savons pas » et le « cela s’est mal passé ». Toute phase physique peut mener à l’ignorance, ce qui diffère du déplacement dans un site, où cela n’arrive qu’à partir d’un état. La raison tient à la portée : dans un site il y a un instant où personne n’est sûr, dans un déménagement entre sites il y en a six. Est-elle encore dans l’ancienne baie ? Est-elle sur le chariot ? Est-elle dans la camionnette ? Est-elle sur le nouveau plancher ? Est-elle en baie ? Est-elle branchée ?

Quatre choses qu’il remarque et ne répare jamais

Un déménagement écrit exactement deux choses : le site et l’emplacement de la machine, et la réservation de baie. Aucune adresse, aucune appartenance d’agent, aucun VLAN, aucun tissu, aucune arête de topologie.

Cette retenue est la véritable exigence, et c’est précisément là que la mauvaise réponse paraît évidente. La machine est partie sur l’autre site, donc son préfixe d’adresses devrait sûrement suivre. Il ne doit pas. Une adresse issue d’un préfixe routé sur le site d’origine ne fonctionne pas sur celui de destination, et quelle adresse devrait s’y trouver à la place, la plateforme l’ignore. Quel agent dessert la nouvelle salle est la décision d’un humain. Seule une preuve confirmée peut faire de la topologie une vérité.

Chacune de ces choses devient donc une vérification ouverte : mesurée, consignée et affichée, jamais exécutée.

Les deux dernières sont honnêtes sur leur ouverture permanente au lieu de rester discrètement sur « conforme ». Dire que quelque chose est conforme est une affirmation, et personne ne l’a faite.

Cette retenue est gardée par la forme et non par la discipline. Un test parcourt l’arbre syntaxique des six fichiers de ce flux et échoue devant toute insertion ou mise à jour dans une table d’adresses, d’agents, de réseau, de tissu, de service ou de serveurs. Il a d’abord été prouvé rouge avec une écriture plantée. Un second test, plus ancien, pose une autre question, celle de savoir si une valeur de site vient d’un calcul, et il approuverait volontiers un déménagement qui transmet proprement un site de destination. Deux questions, deux tests, et seules ensemble elles couvrent la règle.

Trois sorties de l’ignorance

Quand le résultat physique est incertain, quelqu’un doit aller voir. Les trois réponses sont consignées comme observations et non comme retours en arrière.

Vue à destination. Le déménagement se termine, et la trace porte « observée à destination » plutôt que « terminée », afin qu’il reste lisible qu’il y a eu un doute.

Vue à l’origine. La réservation à l’autre bout est libérée et le déménagement se termine en échec et non en annulation, car quelqu’un a fait du travail physique et le déplacement n’a pas eu lieu. L’ancien emplacement n’est délibérément pas rouvert. Si la machine était déjà hors baie, ces unités ont été libérées et autre chose y pend peut-être ; les revendiquer pourrait mettre deux machines sur une unité, exactement la faute pour laquelle existe l’index unique partiel. La machine appartient au site d’origine et n’est dans aucune baie, et c’est la vérité : elle est sur un chariot. La remettre est un nouvel emplacement et donc un acte à part.

Introuvable. La réservation à destination est libérée, car garder de l’espace en baie pour du matériel qui ne viendra pas bloque quelqu’un d’autre pour rien. La machine reste en transport sans site, et l’opération se termine en échec avec son propre blocage. Elle n’est surtout ni réformée ni mise en quarantaine. Ce sont des décisions sur la machine, et « perdue » est une observation. Du matériel qui refait surface la semaine prochaine ne devrait pas avoir disparu entre-temps de toutes les listes.

L’ordre de la vérification préalable, et une chose sur les sites

La planification refuse dans un ordre fixe : l’équipement existe, il n’y a ni déplacement ni second déménagement en cours (deux tables avec deux index partiels qui ne savent rien l’un de l’autre), il est réellement placé quelque part, les deux sites diffèrent, le site de destination est actif, aucun service ne fait obstacle, et la place convient.

Seule la destination doit être active. Une origine en cours de démantèlement n’est pas un obstacle, c’est justement la raison pour laquelle on déménage du matériel. Inverser cela interdirait exactement la migration pour laquelle la fonction existe.

La vérification de service refuse aussi sur reserved et provisioning, et pas seulement sur actif, ce qui nous a d’abord surpris puis plus du tout. Une machine sur laquelle pèse une réservation est promise ; ce qu’il faut annuler là, c’est la commande et non le voyage de la machine.

Ce que nous noterions

1. 01Une forme différente mérite un objet différent. Si le nouveau cas a six états de plus, une sortie de plus et une période de non-lieu, un drapeau sur l’ancien produit un automate qui ne décrit aucun des deux cas.
2. 02Écrivez « nulle part » littéralement. Une valeur vide qui signifie « dans une camionnette » est plus utile qu’un état qui prétend que la machine est encore quelque part.
3. 03Après un travail physique rapporté, ne revenez jamais en arrière. Ajoutez un état signifiant « inconnu » et donnez-lui des sorties documentées, toutes des observations.
4. 04Ne rouvrez pas un emplacement libéré. L’espace que vous avez lâché peut être occupé. Revenir est un nouvel emplacement, avec la même vérification de collision que tout autre.
5. 05Remarquer sans réparer. Une vérification ouverte qu’un humain traite vaut mieux qu’une supposition automatique sur les adresses, les VLAN et le câblage.
6. 06Gardez la retenue par un test sur la forme. « Ce flux n’écrit jamais dans ces tables » est vérifiable ; « nous penserons à ne pas le faire » ne l’est pas.
7. 07Vérifiez le sens de votre règle de site. Exiger que l’origine soit en bonne santé interdirait justement le déménagement dont tout le monde a besoin.

Pour être clair sur ce dont il s’agit : le travail de logistique de centre de données se trouve derrière un interrupteur de déploiement éteint par défaut, avec un réglage par organisation par-dessus ; rien de tout cela n’est donc achetable aujourd’hui. Quatre choses ne sont pas démontrées. La migration a été appliquée à la main sur la base de développement puis annulée, jamais via le migrateur. La fiche de rapprochement et le bouton d’annulation n’ont pas été conduits dans un navigateur. Une requête brute contre les actions avec l’interrupteur fermé n’a pas été mesurée. Et une réservation de destination n’a jamais été réellement observée en train d’expirer.

Issu du travail de plateforme de Provibr. La version au sein d’un seul site, et pourquoi une réservation devient l’emplacement au lieu d’être libérée puis réécrite, est expliquée dans la réservation devient l’affectation. Pourquoi des unités libres dans une baie ne valent pas de la capacité est expliqué dans l’espace en rack n’est pas de la capacité.