Aus der Sperre wird die Platzierung

Einen Server von einer Rackeinheit in eine andere umzusetzen ist körperlich eine kurze Arbeit mit einem Schraubendreher und einem zweiten Paar Hände. Die Verwaltung darum herum ist der Ort, an dem der interessante Fehlschlag wohnt, und er wohnt in einem einzigen Augenblick: dem Moment, in dem das Ziel nicht mehr reserviert und noch nicht belegt ist.

Landet in diesem Augenblick der Schreibvorgang eines anderen, stehen zwei Maschinen im selben Slot. In einer Datenbank liest sich das als Verletzung eines Constraints, über die man streiten kann. Auf der Fläche liest es sich als Techniker, der mit einer Maschine in den Händen vor einem Rack steht und keinen Platz dafür hat.

Das Fenster, und wie man keines hat

Die naheliegende Abfolge hat drei Schritte. Die alte Buchung freigeben, die Umzugssperre auf dem Ziel freigeben, die neue Platzierung schreiben. Innerhalb einer Transaktion ist dieses Fenster für andere Sitzungen unsichtbar, und genau deshalb lässt man es leicht stehen: Es besteht jeden Test, den Sie schreiben. Ein Fenster ist es trotzdem, denn die Anweisung danach arbeitet auf einem Slot, den die Anweisung davor freigegeben hat, und eine falsche Reihenfolge bei einer späteren Umarbeitung genügt.

Wir machen etwas Einfacheres. Die Umzugssperre wird hochgestuft statt ersetzt. Die Zeilen, die festhalten, welche Units belegt sind, bleiben genau dort, wo sie sind; nur die Kopfzeile wechselt die Art, von einer Umzugssperre zu einer Platzierung, und ihr Verfall wird in derselben Aktualisierung auf leer gesetzt. Die alte Platzierung schließt in derselben Transaktion. Es gibt keinen Zeitpunkt, an dem das Ziel frei ist, es gibt also keine zweite Gelegenheit zur Kollision, und das Ganze ist eine Aktualisierung und kein Einfügen, das gelingen muss.

Die Buchungskennung bleibt über die Hochstufung hinweg unverändert, und das ist der Weg zu prüfen, dass wirklich das geschehen ist und nicht etwas, das von außen nur so aussieht.

Den Verfall auf leer zu setzen ist keine Ordnungsliebe. Ein Check in der Datenbank lehnt eine Platzierung ab, die einen trägt, denn eine Platzierung, die an einem Dienstag still aufhört mitzuzählen, während die Maschine noch festgeschraubt ist, ist ein Rack, in dem die Software eine freie Unit vermutet. Eine verfallende Reservierung ist eine Funktion; eine verfallende Platzierung ist eine Lüge mit einem Zeitschalter daran.

Der Schiedsrichter ist weiterhin ein Index

Nichts davon ist das, was eine Doppelbelegung verhindert. Das bleibt ein partieller eindeutiger Index auf Rack, Seite und Slot, begrenzt auf Zeilen, die nicht freigegeben sind, und eine Umzugssperre liegt genauso darunter wie eine Platzierung.

Zwei Techniker, die in derselben Sekunde dieselbe Unit wählen, sehen sie beide in der Planungsfunktion frei, die vor dem Schreiben läuft, und genau einer von beiden kommt durch die Datenbank. Der Schreibvorgang des anderen scheitert am Index, und der einzige Weg, der Belegung schreibt, fängt diese Verletzung ab und macht daraus eine lesbare Ablehnung, die die Units benennt, die kollidieren. Welcher Satz daraus wird, wählt der Name des Constraints, das gegriffen hat, denn „diese Unit ist belegt“ und „diese Maschine steht schon woanders“ schicken einen Menschen zu zwei verschiedenen Racks. Ein direktes Einfügen, das diesen Weg überspringt, bekommt stattdessen die rohe Verletzung. Beides gemessen, denn über Isolationsstufen nachzudenken ist kein Beweis.

Die Planungsfunktion ist eine Meldung und keine Abwehr. Der Index ist die Abwehr. Diese beiden Rollen auseinanderzuhalten ist das, was die Meldung hilfreich sein lässt, ohne dass jemand in Versuchung gerät, ihr zu vertrauen.

Neun Zustände, und zwei Ausgänge, die aufhören zu bestehen

Ein Umzug hat neun Zustände: Entwurf, geplant, genehmigt, in Arbeit, wartet auf Prüfung, braucht Abgleich, abgeschlossen, abgebrochen und fehlgeschlagen. Welche Übergänge zulässig sind, ist ein Datensatz über alle neun und keine Fallunterscheidung. Eine Fallunterscheidung mit Standardzweig lässt einen neu hinzugefügten Zustand nach erlaubt durchfallen, und die gefährliche Richtung ist hier genau diese: Ein Zustand, den jemand hinzufügt, weil etwas Ungewöhnliches vorgeht, wäre der erste Zustand, der alles dürfte.

Die interessante Zeile ist die, die in_progress verlässt, denn zwei Ausgänge, die jeder frühere Zustand hat, fehlen ihr: Es gibt keinen Weg zurück nach genehmigt und keinen Weg nach abgebrochen. Jemand hat die Maschine an diesem Punkt in den Händen, und die einzigen ehrlichen Ausgänge sind „als erledigt gemeldet“, „wir wissen es nicht“ und „es ist fehlgeschlagen“. Abbrechen ist eine Entscheidung, die vorher getroffen wird; nachdem körperliche Arbeit gemeldet wurde, ist ein Rollback in der Datenbank eine Behauptung über die physische Welt, die niemand überprüft hat.

Die drei Endzustände, abgeschlossen, abgebrochen und fehlgeschlagen, tragen leere Listen und nicht gar keinen Eintrag. Das ist der Unterschied zwischen „von hier geht nichts weiter“ und „darüber hat niemand nachgedacht“, und nur das Erste ist eine Entscheidung.

Eine zweite Tabelle sagt je Zustand, ob das Ziel gesperrt bleiben soll. Der Eintrag, der eine Verteidigung verdient, ist needs_reconcile, der sie behält. Niemand weiß an diesem Punkt, wo die Maschine ist, das Ziel freizugeben könnte also eine zweite Maschine auf eine Unit stellen, die vielleicht schon belegt ist.

Umziehen ist nicht unterwegs sein

Anlagen tragen einen Vorgangszustand, und diese Arbeit hat moving neben das bestehende in_transit gestellt. Sie klingen wie Synonyme und sind keine. moving bedeutet, dass die Maschine innerhalb dieses Rechenzentrums verlegt wird und ihr Zielplatz reserviert ist. in_transit bedeutet, dass sie zwischen zwei Standorten unterwegs und deshalb nirgends ist. Beide sperren die Auslieferung an einen Kunden, aber sie beantworten verschiedene Fragen, wenn jemand fragt, wo eine Maschine ist, und sie zusammenzulegen machte die Antwort auf die zweite Frage falsch. Die Trennung wird erzwungen und nicht bloß beschrieben: Ein Check in der Datenbank verlangt, dass der Ursprungsstandort und der Zielstandort eines Umzugs derselbe Standort sind, ein Umzug ist also konstruktionsbedingt etwas, das innerhalb eines Gebäudes geschieht, und der Weg zwischen zwei Standorten ist ein anderer Vorgang mit einem anderen Wort dafür.

Welchen Zustand die Maschine vor dem Umzug hatte, steht in der eingefrorenen Vorprüfung und wird nicht angenommen. Gerade eingetroffene Hardware liegt in staging, und hinterher alles auf normal zurückzusetzen meldet jede verlegte Maschine still aus dem Wareneingang ab.

Zwei Wege aus dem Nichtwissen, und keiner ist ein Rollback

Wenn das körperliche Ergebnis unsicher ist, geht der Umzug nach needs_reconcile und jemand muss hingehen und nachsehen. Es gibt zwei Antworten, und beide werden als Beobachtungen festgehalten.

Das zweite ist bewusst fehlgeschlagen und nicht abgebrochen. Jemand hat körperliche Arbeit geleistet und die Maschine hat sich nicht bewegt; das ist ein Ergebnis und keine Wahl. Und es ist kein Rollback: Die Datenbank wird nicht in einen Zustand zurückversetzt, der so tut, als wäre nichts geschehen. Die Standorthistorie wird nur angefügt, Korrekturen sind neue ausgleichende Einträge, und der Unterschied zeigt sich einen Monat später, wenn jemand fragt, warum eine Maschine einen Tag lang stillstand. Ein Rollback lässt nichts zurück. Ein ausgleichender Eintrag zeigt, dass es eine Unsicherheit gab und wie sie geklärt wurde.

Diese Historienzeilen tragen Standort- und Rackkennungen ohne Fremdschlüssel, mit Absicht. Ein Rack, das nächstes Jahr stillgelegt wird, ändert nicht, was im vergangenen März darin stand.

Zwei kleine Entscheidungen, die später zählen

Der Umzug zeigt mit einem Verweis auf seinen Hintergrundvorgang, der auf SET NULL steht, wenn der Vorgang gelöscht wird, statt auf CASCADE. Vorgänge werden nach neunzig Tagen aufgeräumt. Die Hardwareverwaltung nicht, und ein Weiterreichen hieße, dass die Aufbewahrungsregel für Fortschrittsbalken still den Nachweis löscht, wohin eine Maschine gegangen ist.

Und ein partieller eindeutiger Index erlaubt einen offenen Umzug je Anlage. Ohne ihn können zwei Menschen zwei verschiedene Ziele für dieselbe Maschine planen, und beide sehen auf ihrem eigenen Bildschirm richtig aus.

Was wir aufschreiben würden

1. 01Stufen Sie hoch, legen Sie nicht neu an. Haben eine Reservierung und eine Zuteilung dieselbe Form, wechseln Sie die Art, statt freizugeben und zu schreiben, und prüfen Sie, dass die Kennung überlebt hat.
2. 02Lassen Sie den Schiedsrichter in der Datenbank und die Erklärung im Code. Der Index entscheidet, wer gewinnt; die Planungsfunktion sagt, welche Units kollidieren.
3. 03Schreiben Sie die Übergangstabelle über jeden Zustand. Ein Standardzweig macht aus einem neuen Zustand einen erlaubten.
4. 04Rollen Sie nach gemeldeter körperlicher Arbeit nie zurück. Fügen Sie einen Zustand hinzu, der „unbekannt“ bedeutet, und geben Sie ihm zwei dokumentierte Ausgänge, beide Beobachtungen.
5. 05Lassen Sie die Historie nur wachsen und Korrekturen neue Zeilen sein, denn dass etwas einmal unsicher war, ist selbst eine Information.
6. 06Prüfen Sie, woran Ihre Aufbewahrungsregel hängt. Ein Weiterreichen aus einer kurzlebigen Tabelle in eine langlebige ist ein Datenverlustfehler mit Zeitplan.

Zur Klarheit darüber, was das ist: Die Arbeit an der Rechenzentrumslogistik liegt hinter einem Rollout-Schalter, der standardmäßig aus ist, mit einer Einstellung je Organisation darüber, nichts davon ist also heute käuflich. Vier Dinge sind unbewiesen. Das Fortschrittsereignis eines Umzugs wurde ohne seinen Nachrichtenbus ausgeübt. Einen Umzug vom Betriebsbildschirm aus abzubrechen wurde nicht im Browser durchgespielt. Eine wirklich verfallene Sperre wurde nie beobachtet, und es gibt absichtlich keinen Durchlauf, der eine solche aufräumt, denn eine Sperre, die sich selbst aufräumt, während jemand am Rack steht, ist genau der Widerspruch, den der Index verhindern soll. Und derselbe Standort-Check, der oben beschrieben ist, hat nie wirklich gegriffen, denn es wurde kein zweiter Standort angelegt, mit dem er hätte greifen können.

Aus der Rechenzentrumsarbeit bei Provibr. Warum ein partieller eindeutiger Index die einzige echte Grenze der Belegung ist, steht in die einzige echte Grenze der Rackbelegung, und warum die fünf Kapazitätsfragen über einem Rack nicht addiert werden dürfen, steht in Rackplatz ist keine Kapazität.