Nirgendwo ist ein Ort: Umzug ins andere Haus

Einen Server innerhalb desselben Gebäudes von einem Rack in ein anderes zu setzen ist eine physische Handlung mit einer Unsicherheit: steht er dort. Das haben wir vor einer Weile modelliert, und interessant war der Augenblick, in dem das Ziel weder reserviert noch belegt ist.

Einen Server in eine andere Stadt zu bringen ist nicht dasselbe Problem in einem größeren Mantel. Es ist eine Folge von Handlungen an zwei Orten, mit einem Zeitraum dazwischen, in dem die Maschine in keinem Rechenzentrum steht, dazu eine Netzwerkseite, eine Adressseite und eine Agentenseite, die am anderen Ende erneut wahr werden müssen. Die Versuchung besteht darin, den vorhandenen Umzug wiederzuverwenden und die Prüfung fallen zu lassen, die Herkunft und Ziel auf denselben Standort zwingt. Wir haben es nicht getan, und dies ist der Grund.

Warum es ein zweites Objekt ist und keine Kennzeichnung

Der vorhandene Umzug hat bereits eine Herkunft, ein Ziel, eine eingefrorene Vorprüfung, eine Reservierung am Ziel, einen Vergleichszähler und eine nur anfügende Spur. Was zu fehlen scheint, ist eine einzige Datenbankprüfung.

Eine Kennzeichnung hinzuzufügen würde zwei Zustandsmaschinen zu einer verschmelzen, die zu keiner von beiden passt. Ein Umzug innerhalb eines Standorts hat neun Zustände; ein Umzug zwischen Standorten hat fünfzehn. Der erste hat zwei Ausgänge aus dem „wir wissen es nicht“, der zweite drei, und dieser dritte lautet, dass die Maschine unterwegs verloren gegangen ist, was zwischen zwei Racks im selben Raum gar nicht passieren kann. Und die Prüfung zu entfernen würde jeden vorhandenen Umzug, auch einen letzte Woche geplanten, stillschweigend über die Standortgrenze lassen.

Geteilt wird alles, was wirklich dasselbe ist: dieselbe Belegungsgrundlage mit ihrem teilweisen eindeutigen Index, dieselbe nur anfügende Standortspur und dieselbe Betriebsnaht aus Starten, Fortschreiben und Abschließen. Die Arten der Spureinträge sind getrennt, damit eine Leserin in einem Jahr erkennen kann, ob eine Maschine innerhalb eines Saals verrückt wurde oder ob sie einen Nachmittag in einem Transporter lag. Ein gemeinsamer Eintrag „verschoben“ würde diesen Unterschied dauerhaft auslöschen.

Fünfzehn Zustände, und einer davon ist nirgendwo

Drei verwaltende Zustände, bevor etwas Physisches geschieht (Entwurf, geplant, freigegeben), neun Phasen echter Arbeit und drei Endzustände. Die Phasen sind: Herunterfahren, Ausbau, Transport, Ankunft am Ziel, Einbau, Neuverkabelung, erneutes Messen, Bestätigen und der Zustand, in dem niemand Bescheid weiß.

Der Zustand, der den ganzen Entwurf trägt, ist in_transit. Er ist der einzige laufende Zustand, in dem der Standort der Maschine tatsächlich leer ist, und der Code schreibt diese Leere, statt sie zu beschreiben: die Standortspalte wird wirklich leer. Leer bedeutet bei einem Standort sonst „nicht festgestellt“, und hier bedeutet es etwas Stärkeres und Wörtlicheres. Es gibt kein Rechenzentrum, in dem sie steht. Sie ist auf der Straße.

Ihre Nachbarn sind das bewusst nicht. unracked heißt aus dem Rack, aber noch im Gebäude, auf einem Wagen, der Standort bleibt also die Herkunft. destination_claimed heißt am anderen Ende angekommen, aber noch nicht im Rack, und ab da gehört sie verwaltungsseitig zum Zielstandort. Zwei Grenzen, eine Stunde auseinander, und sie zu verschmelzen machte die Antwort auf „wo steht Maschine 41 gerade“ für eine von beiden falsch.

Ab dem Herunterfahren gibt es keinen Weg zurück

Die Übergänge stehen als Tabelle über alle fünfzehn Zustände und nicht als Verzweigung, aus demselben Grund wie überall in dieser Codebasis: eine Verzweigung mit Standardzweig macht aus einem neu hinzugefügten Zustand einen erlaubten, und ein Zustand, den jemand hinzufügt, weil etwas Ungewöhnliches geschieht, wäre der erste, der alles darf.

Die entscheidende Zeile verlässt approved. Bis einschließlich dort lässt sich ein Umzug abbrechen, und niemandem ist etwas geschehen. Ab shutting_down ist der Abbruch fort. Jemand hat begonnen, einen laufenden Dienst eines Kunden abzubauen; eine Datenbankänderung macht das nicht rückgängig, und so zu tun ist eine Behauptung über die physische Welt, die niemand geprüft hat.

Was aus jeder physischen Phase bleibt, ist die nächste Phase, „wir wissen es nicht“ und „es ist schiefgegangen“. Jede physische Phase kann in das Unwissen führen, und das ist anders als beim Umzug innerhalb eines Standorts, wo das erst ab einem Zustand geht. Der Grund ist die Reichweite: innerhalb eines Standorts gibt es einen Augenblick, in dem niemand sicher ist, bei einem Umzug zwischen Standorten sind es sechs. Steht sie noch im alten Rack. Liegt sie auf dem Wagen. Ist sie im Transporter. Steht sie auf dem neuen Boden. Hängt sie im Rack. Ist sie angeschlossen.

Vier Dinge, die er bemerkt und nie behebt

Ein Umzug schreibt genau zwei Dinge: Standort und Ort der Maschine sowie den Rackanspruch. Keine Adresse, keine Agentenzugehörigkeit, kein VLAN, kein Fabric, keine Topologiekante.

Diese Zurückhaltung ist die eigentliche Anforderung, und genau dort sieht die falsche Antwort naheliegend aus. Die Maschine ging an den anderen Standort, also müsste doch ihr Adresspräfix mitziehen. Muss es nicht. Eine Adresse aus einem Präfix, das am Herkunftsstandort geroutet wird, funktioniert am Zielstandort nicht, und welche Adresse dort stattdessen gehört, weiß die Plattform nicht. Welcher Agent den neuen Saal bedient, ist die Entscheidung eines Menschen. Nur bestätigte Belege dürfen Topologie zur Wahrheit machen.

Jedes dieser Dinge wird daher zu einer offenen Prüfung: gemessen, festgehalten und angezeigt, niemals ausgeführt.

Die letzten beiden sind ehrlich über ihre dauerhafte Offenheit, statt still auf „in Ordnung“ zu stehen. „In Ordnung“ ist eine Aussage, und niemand hat sie getroffen.

Diese Zurückhaltung wird über die Form abgesichert und nicht über Disziplin. Ein Test läuft den Syntaxbaum der sechs Dateien dieses Ablaufs ab und schlägt bei jedem Einfügen oder Ändern in einer Adress-, Agenten-, Netzwerk-, Fabric-, Dienst- oder Servertabelle fehl. Er wurde zuerst mit einem eingebauten Schreibvorgang rot bewiesen. Ein zweiter, älterer Test stellt eine andere Frage, nämlich ob ein Standortwert aus einer Berechnung stammt, und er würde einen Umzug, der einen Zielstandort sauber durchreicht, bereitwillig durchwinken. Zwei Fragen, zwei Tests, und nur zusammen decken sie die Regel ab.

Drei Wege aus dem Unwissen

Wenn das physische Ergebnis unsicher ist, muss jemand nachsehen. Alle drei Antworten werden als Beobachtung festgehalten und nicht als Rücknahme.

Am Ziel gesehen. Der Umzug wird abgeschlossen, und die Spur trägt „am Ziel beobachtet“ statt „abgeschlossen“, damit lesbar bleibt, dass es Zweifel gab.

An der Herkunft gesehen. Die Reservierung am anderen Ende wird freigegeben, und der Umzug endet als gescheitert und nicht als abgebrochen, denn jemand hat physische Arbeit geleistet und der Umzug ist nicht zustande gekommen. Der alte Einbauort wird bewusst nicht wieder geöffnet. War die Maschine bereits aus dem Rack, sind jene Einheiten freigegeben, und inzwischen hängt dort vielleicht etwas anderes; sie erneut zu beanspruchen könnte zwei Maschinen auf eine Einheit setzen, genau der Fehler, für den der teilweise eindeutige Index existiert. Die Maschine gehört zum Herkunftsstandort und steht in keinem Rack, und das ist die Wahrheit: sie steht auf einem Wagen. Sie zurückzusetzen ist ein neuer Einbau und damit eine eigene Handlung.

Nirgends gefunden. Die Reservierung am Zielstandort wird freigegeben, denn Rackfläche für Hardware zu halten, die nicht kommt, blockiert jemand anderen für nichts. Die Maschine bleibt unterwegs und ohne Standort, und der Umzug endet gescheitert mit einer eigenen Blockade. Sie wird ausdrücklich nicht ausgemustert oder in Quarantäne gesetzt. Das sind Entscheidungen über die Maschine, und „verloren“ ist eine Beobachtung. Hardware, die nächste Woche doch auftaucht, sollte inzwischen nicht aus jeder Liste verschwunden sein.

Die Reihenfolge der Vorprüfung, und eine Sache zu Standorten

Die Planung lehnt in fester Reihenfolge ab: das Gerät existiert, es läuft weder ein Umzug noch ein zweiter Standortwechsel (zwei Tabellen mit zwei teilweisen Indizes, die nichts voneinander wissen), es steht tatsächlich irgendwo, die beiden Standorte unterscheiden sich, der Zielstandort ist aktiv, kein Dienst steht im Weg, und der Platz passt.

Nur der Zielstandort muss aktiv sein. Ein Herkunftsstandort, der abgebaut wird, ist kein Hindernis, sondern gerade der Grund, warum Menschen Hardware umziehen. Das umgekehrt zu prüfen würde genau die Verlagerung verbieten, für die es die Funktion gibt.

Die Dienstprüfung lehnt auch bei reserved und provisioning ab und nicht nur bei aktiv, was uns zuerst überraschte und dann nicht mehr. Eine Maschine mit einer Reservierung ist vergeben; abzubrechen ist dort die Bestellung und nicht die Reise der Maschine.

Was wir aufschreiben würden

1. 01Eine andere Gestalt verdient ein anderes Objekt. Hat der neue Fall sechs Zustände mehr, einen Ausgang mehr und eine Zeit des Nirgendwoseins, dann beschreibt eine Kennzeichnung am alten keinen der beiden Fälle.
2. 02Schreiben Sie „nirgendwo“ wörtlich auf. Ein leerer Wert, der „im Transporter“ bedeutet, ist nützlicher als ein Zustand, der so tut, als stünde die Maschine noch irgendwo.
3. 03Nach gemeldeter physischer Arbeit niemals zurückrollen. Fügen Sie einen Zustand für „unbekannt“ hinzu und geben Sie ihm dokumentierte Ausgänge, allesamt Beobachtungen.
4. 04Öffnen Sie einen freigegebenen Platz nicht erneut. Fläche, die Sie losgelassen haben, kann belegt sein. Zurück ist ein neuer Einbau, mit derselben Kollisionsprüfung wie jeder andere.
5. 05Bemerken ohne zu beheben. Eine offene Prüfung, die ein Mensch löst, schlägt eine automatische Vermutung über Adressen, VLANs und Verkabelung.
6. 06Sichern Sie Zurückhaltung über die Form ab. „Dieser Ablauf schreibt nie in jene Tabellen“ ist prüfbar; „wir werden daran denken“ nicht.
7. 07Prüfen Sie die Richtung Ihrer Standortregel. Zu verlangen, dass die Herkunft gesund ist, verbietet genau den Umzug, den alle brauchen.

Zur Klarheit darüber, was das ist: die Rechenzentrumslogistik liegt hinter einem standardmäßig ausgeschalteten Ausrollschalter mit einer Einstellung je Organisation darüber, davon ist heute also nichts käuflich. Vier Dinge sind unbewiesen. Die Migration wurde von Hand auf der Entwicklungsdatenbank angewandt und zurückgenommen, nie über den Migrator. Der Abgleichsdialog und die Abbruchschaltfläche wurden nicht im Browser gefahren. Eine rohe Anfrage an die Aktionen bei geschlossenem Schalter wurde nicht gemessen. Und eine Zielreservierung wurde nie wirklich beim Ablaufen beobachtet.

Aus der Plattformarbeit von Provibr. Die Fassung innerhalb eines Standorts, und warum aus einer Reservierung der Einbauort wird, statt sie freizugeben und neu zu schreiben, steht in aus der Reservierung wird der Einbauort. Warum freie Einheiten in einem Rack nicht dasselbe wie Kapazität sind, steht in Rackfläche ist keine Kapazität.